Tux Machines

Gentoo Development Reports

Posted by Roy Schestowitz on Jul 05, 2023

=> today's leftovers | Latest Microsoft Troubles

[Gentoo] Week 5 – Modernization of Portage

=> ↺ [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.

=> ↺ 528836

=> ↺ 528836

Week 5 Report, Automated Gentoo System Updater

=> ↺ 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: [...]

=> ↺ forums

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.
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.

=> ↺ forums

Weekly report 5, LLVM libc

=> ↺ 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 studiedmussel 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.

=> ↺ mussel

=> ↺ mussel

=> gemini.tuxmachines.org

Proxy Information
Original URL
gemini://gemini.tuxmachines.org/n/2023/07/05/Gentoo_Development_Reports.gmi
Status Code
Success (20)
Meta
text/gemini;lang=en-GB
Capsule Response Time
140.325914 milliseconds
Gemini-to-HTML Time
1.189307 milliseconds

This content has been proxied by September (ba2dc).