Gentoo Development Reports

posted by Roy Schestowitz on Jul 05, 2023

• [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 specify LLVM_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 setting CC=true to 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.