IRC channel logs
2026-06-09.log
back to list of logs
<yelninei>bjc: For gcc-13 do things end up in lib64 vs lib? There is a snippet in gcc-14 to fix it (gcc/config/i386/t-linux64/ gcc/config/i386/t-gnu64) <trev>does anyone have a notmuch/mbsync service? <divya>trev: I have it setup as a cron job <trev>divya: i see, thanks. i have something similar <divya>You can setup a shepherd home service, but I felt this is a bit simpler. <stephen2>also using a script for mbsync/notmuch -- on a related note, anyone have a workaround for hydroxide getting blocked by capcha checks when trying to fetch protonmail? <trev>maybe i just got pranked by an AI slop article (sorry author if you are here) <bjc>yelninei: i will check. why would that have changed, though? i guess i'm mostly surprised that this has only just now started failing <bjc>the moste annoying thing about this is that it's the final phase that breaks. ie, after i've already built gcc <bjc>so every test is many hours <yelninei>i think the resulting install tree might still be there <yelninei>bjc: The fix is only in gcc-14, gcc-15. I encountered it when building gcc-11 for x86_4 for my gdc porting <bjc>well, i'm halfway through a built now, and i'm a real big fan of sunk costs, so i'll try the fix in a few hours =) <yelninei>i was not aware that gcc-13 works on x86_64-gnu (without patches) <bjc>i don't know if it does. i just assumed it was always being pulled in and only recently broke <bjc>maybe i need to look at my dependency graph <yelninei>oh it does. I guess you need to remove the lib64 from gcc/config/i386/t-linux64 . What do you have that depends on gcc-13? <Chwoka>just worked my way through the gentoo install process in a vm. it's neat, it was educational... and i think guix might just be better hehe <Chwoka>looking at the logs from before i joined: that guix nix-package-parser the writer made with claude code, isn't that literally what "guix import" is made to do? <ieure>Chwoka, Similar, but not the same, `guix import' creates a package from the source. <trev>Chwoka: i hope one day we will have a useflags style thing...someone wrote a blog on it somewhere <Chwoka>also on a second pass this is meant to be nix-to-guix rather than the other way around. which seems of marginal use? nix has a larger collection of packages than guix, i'm not sure what would be in the guix repositories that wouldn't already be in nix <Chwoka>trev: yeah, you can more or less get use flags by passing the right flags to the compiler and just manipulating the list of flags with scheme (lisp is all lists after all) but afiak there's not currently any way to set global use flags <Chwoka>also, wouldn't all packages have to be rewritten to differentiate between mandatory dependencies and optional ones? sounds like a pain in the neck <trev>Chwoka: right. it is a silly experiment, just for PoC i guess. i'm still curious if they can get bootstrapability for free that way though <ieure>Yeah, there's no Guix support for optional dependencies. <trev>guix is already a pain in the neck 😏 <ieure>You could do optional dependencies as-is, by writing a gexp that inspects the inputs and sets flags based on if a library is present or not. <ieure>Could make some syntaxy thing to make that easier, but you don't *need* special support. <Chwoka>similarly one can imagine a hack to just parse the same list of flags to every package download request you make, that doesn't sound that hard <untrusem>firefox 151.0.4 is out, and librewolf will very soon release a new version, I will directly update to that