!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

209 Members
66 Servers

Load older messages


SenderMessageTime
5 Oct 2025
@pyrox:pyrox.devdish [Fox/It/She]also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs by the end of this) , but I would rather do that then break something and not know where to start. Also this means that it something breaks i know where and when which will help me a lot.01:14:45
@pyrox:pyrox.devdish [Fox/It/She]* also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs by the end of this) , but I would rather do that then break something and not know where to start. This means that it something breaks i know where and when which will help me a lot.01:14:55
@pyrox:pyrox.devdish [Fox/It/She]* also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs by the end of this) , but I would rather do that then break something and not know where to start. This means that it something breaks i know where and when which will help me a lot while i cherry-pick these01:15:02
@pyrox:pyrox.devdish [Fox/It/She]each rebuild is like 20 minutes though so it's slow going01:15:10
@pyrox:pyrox.devdish [Fox/It/She]* each rebuild is like 20 minutes though so it's slow going, however its only like 20 commits and once I'm done then i can keep going more smoothly01:15:23
@pyrox:pyrox.devdish [Fox/It/She]* also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs(4.6.4 -> 4.6.4 with c++ -> 8.5.0 -> 13.2.0 before getting to static binaries, potentially every time) by the end of this) , but I would rather do that then break something and not know where to start. This means that it something breaks i know where and when which will help me a lot while i cherry-pick these01:16:53
@dramforever:matrix.orgdramforeveris this like, automated01:17:02
@dramforever:matrix.orgdramforever i've done stuff like this just going git rebase -x 'do the thing' and went to get lunch or something, 20 minutes per commit is, a bit slow but not the worst 01:18:06
@pyrox:pyrox.devdish [Fox/It/She]no, there's merge conflicts every commit01:19:05
@pyrox:pyrox.devdish [Fox/It/She]so i have to do it manually01:19:08
@pyrox:pyrox.devdish [Fox/It/She]but as a free time project i don't mind01:19:21
@pyrox:pyrox.devdish [Fox/It/She]* but as a free time project i don't mind doing these rebuilds slowly01:19:29
@dramforever:matrix.orgdramforeveroh, yeah, if there's a lot to tweak then doing it manually makes sense01:20:18
@dramforever:matrix.orgdramforeverthanks, they're in the requested review list but i've pinged to more explicitly say that bootstrap will need fixing01:26:57
@lt1379:matrix.orgLun dish [Fox/It/She]: i wanna try to rescue the original version of the musl flush patch so it just flushes before exit instead of turning off buffering, is it ok if i pr against your pr's branch if i get it working? 01:42:44
@pyrox:pyrox.devdish [Fox/It/She] PRing against my branch would be fine, I'm also fine just cherry-picking it across if you make your own branch. Whichever works best for you!@ 01:47:07
@pyrox:pyrox.devdish [Fox/It/She]* PRing against my branch would be fine, I'm also fine just cherry-picking it across if you make your own branch. Whichever works best for you!01:47:08
@pyrox:pyrox.devdish [Fox/It/She] okay its going much quicker now that its basically new "leaf" packages lol 01:57:18
@pyrox:pyrox.devdish [Fox/It/She]not modifying older ones like getting new static builds of old binaries or anything01:57:34
@pyrox:pyrox.devdish [Fox/It/She]okay that took a lot less time than I thought. I've applied all of emily's commits, fixed them up(a few package updates, reformatting everything, and ensuring each successive step builds), and am now building the final bash-static derivation from emily's branch. Next steps are detailed in her PR description02:52:21
@lt1379:matrix.orgLunhttps://github.com/NixOS/nixpkgs/commit/67eec45505b79dd38d7abf4d18ec037bcc3ea94002:58:42
@lt1379:matrix.orgLun* https://github.com/NixOS/nixpkgs/commit/d7cb7aba4a0a60664ea0a4f599660fe0443acb8103:01:26
@pyrox:pyrox.devdish [Fox/It/She] cherry-picked to my branch and pushed! Thank you so much, super helpful! 03:05:16
@pyrox:pyrox.devdish [Fox/It/She]gotten all the way to the end of emily's commits. Next step is gcc that links against our built gcc, then I need to see if I can build a bootstrap-tools tarball04:05:57
@pyrox:pyrox.devdish [Fox/It/She]* gotten all the way to the end of emily's commits. Next step is gcc that links against our built glibc, then I need to see if I can build a bootstrap-tools tarball04:06:05
@pyrox:pyrox.devdish [Fox/It/She]also at the moment I've left glibc at 2.38(the version emily had) as there are some weird issues with later versions that I don't want to worry about at the moment. It shouldn't be an issue, as we just need a gcc built against glibc that we can use to have stdenv bootstrap its own gcc+glibc, but i'm still not taking the risk. A lot of other software has been upgraded and builds fine though.04:07:25
@pyrox:pyrox.devdish [Fox/It/She]again of course, these are only for use in the bootstrap tarball, and are not designed for use outside of that. stdenv needs to build its own environment from this set of tools.04:07:49
@pyrox:pyrox.devdish [Fox/It/She]* again of course, these are only for use in the bootstrap tarball, and are not designed for use outside of that. stdenv needs to build up its own environment from this set of tools.04:07:56
@pyrox:pyrox.devdish [Fox/It/She]but the next steps are for tomorrow lmao04:08:49
@pyrox:pyrox.devdish [Fox/It/She]its just past midnight here lol04:09:06

Show newer messages


Back to Room ListRoom Version: 9