Gentoo Development Reports
-
[Gentoo] Week 5 – Modernization of Portage
I wanted to work on the dependency resolution system of portage. It is a scary codebase and so Sam suggested I start with bugs related to the dependency resolution system. We decided on bug 528836. The bug is relatively simple (though it took me relatively long time to understand). In gentoo, there are virtual packages. If multiple packages can provide the same functionality / library, then there is a virtual package that depends on either one of them. Any package needing that functionality / library can depend on the virtual package and not worry about the specifics. The problem in this bug is that a package has two dependencies (let’s say) and one depends on a package and the other depends on the corresponding virtual package. Now portage tries to emerge both sides of the virtual package, which leads to conflicts. Ideally, the ebuild maintainers should have made both dependencies depend on the virtual package rather than the actual, but nonetheless portage should have been able to figure it. The first task was to reproduce the bug in a gentoo system.
-
Week 5 Report, Automated Gentoo System Updater
Week started off by receiving some feedback from the community in the forums. Here are some nice ideas that community have suggested to implement: [...]
Parser has turned out to be much harder than I anticipated. First of all, I had to make some changes to both Python and Bash code to create simpler log output, which reduced number of if/else statements in the parser.
Secondly, there were some motivation issues. It was a bit hard to focus on the parser, because a much better approach is to add machine readable output from Portage instead of parsing logs. I talked to my mentor about it and we decided to continue working on the parser, mainly because modifying Portage in any significant way take waay too much time.
Plans for Week 6
On week 6 the plan is to add error parsing and comprehension to the parser. This means I will have to find some different ways to cause Portage to break, and then try to make parser understand the errors that have occurred. Should be really fun!
After that is done, I can focus on using this information to create nice-looking update reports.
-
Weekly report 5, LLVM libc
Hey! This week I’ve spent most of my time figuring out how to bootstrap
a LLVM cross compiler toolchain targeting a hosted Linux environment. I
have also resolved the wint_t issue from last week. Both of these things
took way longer than expected, but I also learned a lot more than
expected so it was worth it.I’ll start with discussing the LLVM cross compiler setup. My initial
idea on how to bootstrap a toolchain was to simply specifyLLVM_TARGETS
for the target architecture when building LLVM, then compile compiler-rt
for the target triple, and then the libc. This is indeed true, but the official
cross compilation instructions tells you to specify a sysroot where the
libc is already built, and that’s not possible when bootstrapping from
scratch.As the compiler-rt cross compilation documentation only tells you to use
an already set up sysroot, which I didn’t have, I had to try my way
forward. This actually took me a few days, and I did things like trying
to bootstrap with a barebones build of compiler-rt, mixing in some GCC
things, and a lot of hacks. I then studied
mussel for a while until finding out about
headers-only “builds” for glibc and musl. It turns out that the only
thing compiler-rt needs the sysroot for is libc headers, and those can
be generated without a functioning compiler for both musl and
glibc. This is done by settingCC=trueto pass all the configure tests
and then run ‘make headers-install‘ (for musl) into a temporary install
directory to generate the headers needed for bootstrapping
compiler-rt.