<nckx>Right; read your messages on -hpc now. <Guest67>Hi, I tried to install guix in an old laptop but failed. It trowed an error a substitution error I think near the end of the process when downloading somethig related to gnome... any clue? <Guest60>hi, I'm back.... I tried the 32bit sistem with the shell installation, and also tried the manual instalation. Any clue? <Daniel[m]1>hello, I'm trying to create a Guix package definition for a program that depends on a certain profile tar (like from guix pack) existing within the store. Is there anyway to explicitly get that dependency in the package definition? right now I have all the of scheme code to create the derivation for the profile tar but adding a derivation to the inputs of the package causes an type error. Thank you for any help. <Daniel[m]1>to answer my question after messing around some more and looking at packages.scm: it looks like inputs can be derivations and it's working now, so I guess there was some other unrelated problem that was causing the error, so never mind <Guest80>hello! I'm trying to verify this guix iso "guix-system-install-1.3.0.x86_64-linux.iso" with the sig I downloaded from the website. I tried to verify using gpg4win(kleopatra) and it says the id of the cert is 0x27D586A4F8900854329FF09F1260E46482E63562 <Guest80>but on the security page it says releases should be signed with fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 <apteryx>sneek: later tell civodul about the hook, it seems quite zippy; haven't measured though. <apteryx>sneek: later tell civodul I'm not sure we can get rid of hooks entirely, just as we can't get rid of search paths or wrappers; it's good to try to minimize them and have them blazing fast or precomputed though, as you had mentioned. <drakonis>did you get the signature file for your iso? <apteryx>Guest80: seems we forgot to update that page <apteryx>the 1.3.0 release was signed by my key, which is the one with the 27D586A4F8900854329FF09F1260E46482E63562 fingerprint <Guest80>apteryx: ah good to know - I'll wait for the page update then? <Guest80>also I'm sure this has been brought up, but it would be great if there was a search function on the packages page <Zambyte>Guest80: I think most people use guix from the command line to search for packages, but I agree it would be nice to have on the site. You could also use the website "repology" to search for packages if you don't have the guix cli handy. <Guest80>@Zambyte ya makes sense. I wanted to check if the packages I use were supported since guix only contains free software <Guest80>Also would you happen to know if radeon gpus are supported by default in linux-libre? <Guest80>I'm not sure if there were some non free blobs that were required to run radeon gpus even tho their drivers are open source? <Guest80>and by supported i mean having simple 2d support (no acceleration) <apteryx>Guest80: sure, although if you'd like to proceed already, you could check the install.sh script, it already has the key listed in <podiki[m]>Guest80: probably depends on what GPU, but newer ones seem to need the nonfree firmware blob for full usage, but with nomodeset had basic functionality <podiki[m]>maybe only up to a lower resolution (1024x768?) though I didn't try anything to work around it (mesa version? other settings?) <apteryx>Guest80: recent AMD == expect to need blobs just to get video output; at least that's my dated experience using a tonga class AMD GPU a couple years back. <apteryx>I personally think it's a better investment to pay a cheap price to an aging GPU that will give you a solid desktop experience and decent 3D acceleration using free drivers and no blobs <apteryx>I'm not sure about intel integrated GPU in recent years; do these still work without blobs? <Guest80>@apteryx might as well have a dedicated linux pc then i guess <Guest80>@apteryx do you know which gpus are good for that? <char>Is there a good reason why some packages that interface with services like mysql skip tests (because the tests require a running mysql server)? <GNUtoo>apteryx: this is probably fixable <rekado>core-updates-frozen still seems to be stuck <rekado>50k builds are pending, none have been completed. *GNUtoo has guix that doesn't build anymore on i686 since days <GNUtoo>Use of uninitialized value in hash element at /gnu/store/0n07srrsfkh6mpzq9m78p18674bci39r-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm line 639. <GNUtoo>./doc/guix-cookbook.ko.texi:565: @node `??????' previously defined <GNUtoo>Though maybe I need to guix pull <rekado>GNUtoo: this bug has already been reported. I had the same problem. <rekado>I got around it with “rm doc/guix-cookbook.*.texi” <rekado>this forces regeneration of these broken texi files <raghavgururajan>Was the stable version of installation image generated before or after introduction of LVM support? ***Exagone313 is now known as Exa
***nckx_ is now known as nckx
<vivien>Hello Guix! I finished compiling rust, yay! So, I tried to upgrade to core-updates-frozen, and openttd breaks (grfcodec can’t build because of a case -1 that triggers -Wnarrowing). <vivien>Oh maybe I should have waited for the matrix storm to end ^^ <attila_lendvai>any hints/ideas why the order of the output of the go importer is not stable? some packages get reordered, and i don't see any obvious use of hashtables, or other unordered containers. <attila_lendvai>another issue is that reset-gzip-timestamps tries to write a read-only file. the current go packages are full of manual messing with reset-gzip-timestamps, either deleting it, or adding a phase that makes the files writable. any ideas for an automated resolution of this? i have dozens of imported go packages... shall i just delete that phase? <attila_lendvai>why are those files read only to begin with? these are files in the out dir while building <attila_lendvai>hrm... it's probably applied somewhere already, because when i apply this locally, i get 500+ MB of downloaded packages from substitutes <PurpleSym>The entire CI seems to be stuck, not just core-updates-frozen. There’s 140k pending builds listed on the global metrics page, but none of the hydra workers are doing anything. ***atw` is now known as atw
<robin_>here's a fun one: my workstation seems to boot properly only on *every other* reboot -- 50% of the time it accepts the boot passphrase properly but doesn't make it past the "Slot 0 loaded" message to the main grub menu ***robin_ is now known as robin
<robin>starting to wonder if it's a hardware problem (it probably should have more fans than it does -- although for now i'm leaving the cases sides off (this is a giant caselabs cube-of-aluminum case) -- and the nvme slots are beneath the pcie slots, two of which have gpus installed that can get rather hot, and it's 3/4 years old) <robin>the system also just (afaict) locks up once in a while, although that might be a keyboard/mouse problem (kinesis keyboard *occasionally* just stops working, possibly due to repairing the chewed-through usb cable inadequately -- lesson: don't let pet rats play around computers ;) -- and i'm temporarily using a crappy "gaming" mouse that needs to be unplugged/replugged every few hours, as i haven't decided whether to overpay for a new cirque touchpad to sit on the <robin>kinesis or switch to a trackball...) <jonsger>robin: I guess its hard to debug, because failed attempts do not log anywhere :( <bost>Hi. I did `guix pull; guix upgrade` about an hour ago. The `guix pull` went fine, however the `guix upgrade` failed with: <bost>uild of /gnu/store/l5flcq83pg5n9pa6r9cbyv3nv365y249-qtwebengine-5.15.2.drv failed <bost>View build log at '/var/log/guix/drvs/l5/flcq83pg5n9pa6r9cbyv3nv365y249-qtwebengine-5.15.2.drv.bz2'. <bost>building /gnu/store/clhg6dmfh9lb5mj704xp5k9g7nz7xz4k-kbookmarks-5.70.0.drv... <bost>cannot build derivation `/gnu/store/n97w21gjik0192wj62anrccjpgj586c4-qutebrowser-2.3.1.drv': 1 dependencies couldn't be built <bost>guix upgrade: error: build of `/gnu/store/n97w21gjik0192wj62anrccjpgj586c4-qutebrowser-2.3.1.drv' failed <bost>Should I send a bug report? <robin>yeah. i'll try plugging in a cheap wireless keyboard/trackpad to make sure it's not related to i/o <bost>Oh BTW my machine was pretty much frozen for about half an hour. And then it started to work again. That was a rather strange thing to experience. <robin>and it looks like lm-sensors can read the nvme temperature, so i'll log that to check that it's not just a weird overheating issue (i'd expect grub not to start at all if that were the case, but maybe it's a weird situation where the nvme stick is sometimes operating at the very threshold of its thermal limits or something) <robin>could also just be a dying mainboard *shrugs* (though it was pretty expensive when i bought it, albeit that was just after 32-core threadripper cpus were released, so hopefully not) <robin>i *do* have a vt420 serial terminal for kernel debugging if it comes to that :p <jpoiret>bost: do you have swap on? i forgot that my swap doesn't turn on itself on boot because of filesystem dependencies not implemented in swap-devices <jpoiret>bootstrapping rust on core-updates-frozen rn, love my life <bost>jpoiret: I don't know. How / where can I see if the swap is on or off? Should I look in the /run/current-system/configuration.scm ? There's nothing about swapping there. <bost>jpoiret: I'm running Guix OS. <jpoiret>then do you have a swap-devices field in your operating-system configuration? <jpoiret>if so you can just `sudo herd status` and check if the swap-something service is started or not <jpoiret>there's no way to specify dependencies for swap devices (yet), only rudimentary support for mapped partitions, so if you have ie a swapfile on a luks filesystem then it's not going to mount at the right time <bost>jpoiret: `sudo herd status | grep swap` shows nothing. <jpoiret>mhmmm, then you didn't configure any swap <jpoiret>it's recommended to have swap especially if you need to compile something, otherwise you're going to freeze a bunch <bost>jpoiret: well then it would be better to have swap configured in the default installation already. <jpoiret>it's true that the example in the manual doesn't have swap <bost>which example? Send me a link please. <jpoiret>you need to add a (swap-devices '("the-swap-device")) field to your operating-system configuration then `guix system reconfigure`. You shouldn't need to reboot, only start the shepherd service if it didn't already start (although since you guix pulled you might want to reboot anyways) <bost>Anyway the upgrade failed on qutebrowser. And I wonder what's the purpose of having qutebrowser after all. I mean there's the icecat by default. And since I installed firefox from the nonguix channel. I guess I don't need the qutebrowser at all, I'd say. Or am I missing something? <jpoiret>it's up to you but yes, you might not need qutebrowser. although a bug report about that build failure would help in any case <bost>BTW there's nothing about swap in the manual, under the link you sent. <jpoiret>i was talking about the first example you see in the manual of a configuration not having any swap <bost>I just sent a bug report to bug-guix@gnu.org <qzdlns[m]>can I ‘guix challenge’ my kernel directly like a package? <qzdlns[m]>provided I have a definition as a package, yes! amazing <jpoiret>til guix record fields can refer to fields declared before them <robin>istr reading something about a gcc rust frontend, hopefully we can use that someday <robin>i've spent some time attempting to update mrustc, but it was...nontrivial back when i tried to work on it <robin>(bot idea: translate (info ...) "links" to online manual links; i'd say info: too but apparently that's an official URL scheme now) <jpoiret>currently installing guix on debian on wsl 2 to offload builds to my beefy computer <bdju>anyone else occasionally get a guix mailing list email twice in a row? I wonder if it's a bug somewhere <bdju>.tell bost did you have audio when you tried qutebrowser? <bdju>hm what's the command again? <robin>jpoiret, and yeah, guix records are "lazy" like that <bdju>sneek: later tell bost did you have audio when you tried qutebrowser? <razor[m]1>hi, my screen brightness resets to maximum value after reboot <razor[m]1>in systemd init system ``` systemd-backlight service ```restores the previous backlight brightness level at boot. whats the shepherd equivalent <nckx>razor[m]1: There isn't one. You could write your own using, for example, the ‘light’ package, which can save and restore a brightness value. <robin>although i had a related question: if i inherit from a package (say quux inherits from baz), and refer to 'name'/'version'/etc. within it, presumably 'name' references in the quux package def would resolve to "quux". but which values would be used for *inherited* fields, e.g. if baz's 'source' field used 'name' and quux didn't replace the 'source' field, would that 'name' reference still evaluate to "baz" within quux's inherited 'source' field? <robin>(...provided that quux had a (name "quux") field, ofc) <nckx>robin: Yes, the values are computed before you inherit. Hence some packages will replace the inherited source field with one that is textually identical just so the new ,name and/or ,version values can take effect. <nckx>I think the term is ‘lexical scoping’. <robin>nckx, thanks! that's what i expected but i wasn't sure <jpoiret>and reciprocally, i don't think quux could reference to baz's fields <nckx>Well, you can do so explicitly, with (package-field quux). <davidl>Im confused that I don't get the actual <mypackage> in my environment profile when I use guix environment --pure -l mypackage.scm -- bash <robin>nckx, yeah, i guess fields would be kind of analogous to 'let*' then <davidl>when I install it with guix package -f mypackage.scm it works just fine <jpoiret>guix environment -l installs all dependencies of the package <jpoiret>maybe --ad-hoc -l package.scm works though <nckx>Aside, I think my first-ever message in this channel when I was still a brash young Nixer was ‘but how can you do any of this if your language isn't lazy?’. We seem to make it work regardless :) <nckx>Yep, --ad-hoc means ‘give me THING, not the build inputs to THING’. <jpoiret>although i must say i can't really read syntax code that well yet <nckx>In retrospect not the obvious mode of operation, so there's a ‘guix shell’ RFC floating around that will make the ad-hoc behaviour the default. *nckx very much prefers writing Guile in any context to even reading Nix now, to be clear. <robin>i think i was imagining that guix records used laziness (delay/force) and define-syntax magic for field references, but let*-style behavior is obviously much easier to implement <jpoiret>when offloading builds, will the local machine also try to build or will it offload everything? <vivien>jpoiret, it will offload everything and wait if no other machine is available. <robin>nckx, oh, that'd be very handy. then i can delete "with () { guix environment --ad-hoc $@ }" from my .zshrc :) <nckx>Heh, my mental name for this functionality has always been ‘$ guix with PACKAGE…’ but I didn't want to bikeshed guix shell… <nckx>jpoiret: And it used to be that trying to work around that by adding localhost to the offload list didn't work, but you can always try it again. <robin>(note to self: global aliases being the only reason i still use zsh instead of bash, maybe i should try patching bash to support them...) <vivien>I’m worried that people might confuse guix repl and guix shell <nckx>I'm not worried per se, but that is a good point. <nckx>robin: Does zsh not require quoting $@? <nckx>Not a practical question here, just curious. <apteryx>got a test failure with elogind: 147/158 test-event TIMEOUT 30.04s killed by signal 15 SIGTERM <apteryx>on core-update-frozen-batched-changes <vivien>I’d like to create a docker-image, but I would like to add files directly to it without putting them in a store (certificate private keys). Can I do that with guix? <apteryx>I'll peek at their patches or changelog <robin>nckx, nope. foo () { echo $# }; bar () { foo $@ }; bar "1 2" "3 4" => 2 <robin>i though bash had an option for that <robin>wouldn't be a dealbreaker though; i'm just too used to global aliases, e.g. M="| less", G="| grep" etc. then "cat foo M"="cat foo | less" <vivien>I see there’s a (guix docker) module that provides build-docker-image, it looks like something I want, but I don’t know how to call it. What should I put in PATH? <robin>a lisp-based shell with hooks for the various expansion phases, etc. might be nifty, actually <jpoiret>alright, it's actually super easy to setup guix on debian on wsl2, i'm currently offloading all build processes to my bigger computer <cybersyn>hiya guix, i'm trying to package a C++ program and it fails 95% of the way in with the following: fatal error: 'filesystem' file not found #include <filesystem> <sneek>Welcome back cybersyn, you have 1 message! <sneek>cybersyn, nckx says: Was it a 458-line Guile backtrace? <cybersyn>which is odd, because that appears to be std::filesystem from the standard library <cybersyn>does anyone know how to overcome this issue? <nckx>Still a good guess, sneek, a good guess in any situation. <nckx>cybersyn: Try building the package with a newer GCC like ("gcc" ,gcc-8). Master still uses 7, which requires (IIRC) #include <experimental/filesystem>. <nckx>Maybe jump straight to 10. <nckx>Or whatever the default will be on core-updates. <cybersyn>ah ok, that sounds right I'll give it a go <dstolfa>cybersyn: filesystem is mildly annoying. there are releases of toolchains that require what nckx said (<experimental/filesystem>), there are those that require <filesystem> but passing -lstdc++fs, and there are those that require either of those two. <dstolfa>if you have the liberty to select the compiler, just pick a new clang <nckx>Oh, godwin, I forgot about -lstdc++fs. <nckx>I need a facepalm emojo. <nckx>Keeping with the theme, aws-sdk-c++'s cc1plus is using 10.7 GiB. <nckx>‘Everything is fine’ is another emojo I need. <cybersyn>dstolfa: what is the best way to pass -lstdc++fs to the compuler from a package definition? I tried it earlier as a #:make-flags, but was unsuccessful (I think something to do with the linker) <nckx>cybersyn: Did you use LDFLAGS? <robin>"a lisp-based shell"...which could be gash of course :p <rekado>in the past few months more and more websites do not display properly in icecat. In the console I see JS exceptions (e.g. NS_ERROR_FILE_CORRUPTED). <rekado>I don’t know how to debug this, so I wanted to use ungoogled-chromium instead. <rekado>but I need to connect over a proxy (I use ssh -D) and for some reason I cannot use the proxy with chromium. Works fine with icecat. <rekado>in the icecat console I get the same error when I run “localStorage.clear()” <rekado>I guess this means I need to delete/rebuild the sqlite file of this profile <cybersyn>nice, success! will have notcurses on guix soon <rekado>oh, nice: the SolidRun order from spring is now on the way to me. Three aarch64 boards. (They had supply problems for months.) <rekado>the NS_ERROR_FILE_CORRUPTED problem is solved: had to delete a corrupt sqlite file from the icecat profile. The error reporting is terrible. <apteryx>rekado: thanks for reporting the solution! <rekado>dongcarl: these are for the build farm. I’ve been sitting among boxes of computer stuff, waiting for the boards to install everything. <rekado>looking forward to extra shelf space soon <rekado>apteryx: unfortunately, I still have not found a solution for the chromium + SSH SOCKS proxy problem. <rekado>I think it’s related to DNS lookups. Looks like they are not going through the proxy. <dongcarl>rekado: Hehe building new boxes always gives me immense joy, I just gotta remember to wash hands afterwards to avoid the lead poisoning <apteryx>rekado: but perhaps it's not needed anymore? :-) in my experience, ungoogled-chromium lacks features compared to icecat <rekado>I hope I can stick with icecat, but I already need to use chromium for all the various video chat sites. <rekado>I generated a qcow2 disk image and uploaded it to an ovirt instance at work. <rekado>the machine does not boot because it keeps looking for a particular partition. <rekado>is there a fool-proof way to set this up? I guess I should not be using file-system-label, nor uuid in the “file-systems” field of the operating-system configuration. <GNUtoo>Hi, is there a way to not build the manuals? <GNUtoo>if I do make make-go -j2 then ./pre-env build doesn't work <roptat>you mean ./pre-inst-env guix build? <GNUtoo>./pre-inst-env: line 55: exec: guix: cannot execute: Is a directory <GNUtoo>and the return code of 'make make-go -j2' is 0 <roptat>ah maybe you need to build something else too <GNUtoo>./pre-inst-env: /home/gnutoo/work/projects/guix/guix/scripts/guix: /home/gnutoo/work/projects/guix/guix/guile: bad interpreter: No such file or directory <GNUtoo>./pre-inst-env: line 55: /home/gnutoo/work/projects/guix/guix/scripts/guix: Success <GNUtoo>That looks a bit better but we're not there yet, maybe I need to look in the autotools stuff <roptat>I would bootstrap and configure again <roptat>it looks like your environment is messed up <GNUtoo>I did that several times already <GNUtoo>Though here I've the patch in doc/local.mk deactivated but I also tried with it before <GNUtoo>Or maybe I should probably wait for that bug to be fixed and wait for sending patches <roptat>maybe try from a fresh checkout, with the patch? <nckx>To answer your previously forgotten question: I have taken a page from my cat's plan for world domination, which appears to be ‘take lots of naps’. I'm not sure what step 2 is but I'm sure she'll deliver. <GNUtoo>I'm also updating everything along the way to be 100% sure <rekado>re fool-proof way to use Guix-generated VM images with ovirt: switch from “VirtIO-SCSI” to “Virtio” in the disk settings in ovirt. <rekado>GNUtoo: re 51259: what error do you get? If it’s just “bad interpreter” you just need to configure the build. <apteryx>civodul: thanks for having a look at the gdk-pixbuf loaders cache file stuff <apteryx>I've been battling my way through non-deterministic test failures on the core-updates-frozen-batched-changes branch, but I think I'm seeing the light at the end of the tunnel <nckx>That's what I'm looking at. <vivien>nckx, I’m trying to test core-updates-frozen but I’m compiling a lot of stuff ^^ <nckx>apteryx: Do you mean the fact that builds stay on 100% for a long time? It's been doing that all day (and only because I'd never given that page much attention until today :) <nckx>Or the high rate of idleless amongst the workers? ☭ <apteryx>nckx: oh no, I had to refresh; for the last days it was mostly iddling, but not anymore <apteryx>it also failed evaluating the core-updates-frozen-batched-changes branch for some reason (no clear failures from the raw logs) <rekado>vivien: there must have been a really big change a few days ago <rekado>just a few days ago it was pretty usable, then I saw a huge merge and since then I’m building nothing but rust <rekado>it took a *very* long time to start building anything at all. For hours it was just stuck at 50k jobs scheduled. <rekado>and before then it didn’t successfully evaluate, so I manually cleared a cached failure (some ruby-* package) and restarted the evaluation. <apteryx>rekado: you may want to try the core-updates-frozen-batched-changes if you have to build rust from scratch; it starts at 1.39 instead of 1.29 <vivien>(for me it’s too late, I’m already compiling 1.50) <rekado>I wonder why core-updates-frozen received world-rebuilding commits. <rekado>wasn’t it the point of branching off -frozen to only apply (minor) fixes? <apteryx>not sure too, the other core-updates branch exists for this purposes <apteryx>rekado: yep, but at least some fixes required a world rebuild, hence core-updates-frozen-batched-changes <rekado>let’s hope we won’t need a core-updates-frozen-batched-changes-frozen and core-updates-frozen-batched-changes-frozen-batched-changes after that :) <vivien>I would propose that packages would be annotated with how much memory per compilation cores it uses, so that guix could reduce the number of cores to build heavy packages like the C++ stuff. <apteryx>vivien: I'd propose to instead start by using gold or even lld instead of ld.bfd. <vivien>apteryx, you think it makes a difference? <apteryx>for large C++ projects it does; link time is often prohibitevely expensive (e.g. up to 3 GiB per core for webkitgtk); lld usually can do with about half <apteryx>gold is in between but already a nice improvement <apteryx>vivien: I've also added ld-wrappers for gold and lld that should make it straightforward to experiment on the core-updates-frozen-batched-changes branch <apteryx>(not suggesting to do these changes now, but the experimentation :-)) <vivien>Well, with your permission, I’ll finish pulling this particular core-updates-frozen commit and then I’ll wait for the CI to catch up :) <apteryx>sure :-) it should be merged back in a couple days anyway <apteryx>ld: /tmp/guix-build-cdparanoia-10.2.drv-0/cdparanoia-III-10.2/cachetest.c:393: undefined reference to `paranoia_free' <apteryx>perhaps parallel build should be disabled <apteryx>rekado: I just repushed the core-updates-frozen-batched-changes-frozen branch, and I'm building it manually on berlin, should you want to try it <rekado>now… what’s the policy for these branches? Where should fixes be pushed to? <podiki[m]>I'm happy to test out c-u-f-b-c(-f) if it builds on the CI <podiki[m]>already running my main computer on core-updates-frozen, so could try out the latest once it is substitute ready <jab>nckx: I like the lots of naps plan. I just got up from mine. <apteryx>podiki[m]: I'm building ungoogle-chromium from it, it'll cache a good part of the world on berlin <podiki[m]>apteryx: great! I'll give it a shot in the near future and let you know how it goes <apteryx>rekado: if you think it's important enough to go in the next release and are comfident, core-updates-frozen/core-updates-frozen-batched-changes depending on the number of rebuilds it entails, else core-updates <apteryx>comfident being comfortable + confident, of course <jpoiret>i was just about to ask about the mrustc bootstrap to 1.39 <rekado>it’s fixes of leaf packages: pdfpc, gerbv, pcb, lepton-eda, geda-gaf, qpdfview, peek, gxtuner, lilypond, and maybe also diffoscope and blender. <rekado>though I’d prefer to not do *all* of these by myself <jpoiret>i'd love to test it before (even though it's pretty simple) <jpoiret>but alas, rust-1.29 is currently building <rekado>the list above is just packages that I couldn’t upgrade when I last pulled from core-updates-frozen. <jpoiret>i don't know why i'm pulling in rust though. texlive was also a surprise, but qt now requires gtk+ (for cohesive theming apparently), which needs tex for building <rekado>tex is an input to many low level things. <rekado>a little annoying because there have been a few bugs in my modular texlive-* packages. <rekado>rust is needed at least for librsvg <rekado>and I think that’s needed by gtk+ <jpoiret>wdym by the modular texlive packages? <jpoiret>yeah, wouldn't that be mitigated by some output splitting (ie out and doc) <rekado>output splitting only helps users who download substitutes <rekado>but to build the thing from scratch you’ll need to build all outputs <rekado>there’s no way to only build one output <rekado>often we build everything and then move the documentation to its own output <rekado>there’s no way to build this separately — whenever that *is* possible we split the whole package <rekado>e.g. python-matplotlib-documentation <jpoiret>ohhh, alright! i haven't messed around with multiple outputs <rekado>re modular: back then we only had one big texlive package <rekado>even slower downloads from the build farm and huge package closures motivated the effort to package every component separately. <jpoiret>damn. texlive looks like a mess to maintain too. it was a blocker for me when switching to guix system since i need texlive for work <rekado>you can always just use the huge texlive package <rekado>but it’s kinda gross, in my opinion <apteryx>mariadb failed a test: Performance_schema_cond_instances_lost 1 in table_io_aggregate_global_4u_2t <jpoiret>i'd agree too, but well, i won't need it for a bit (and also want to move away from tex) <rekado>the modular texlive packages are combined to a working installation in a complicated profile hook. <rekado>for the subset of LaTeX that I need it works pretty well. But it’s far from complete. <podiki[m]>I've unfortunately run into some smaller texlive packages missing (that I would package, but got confused by the tex build system and haven't had a chance) <jpoiret>back to the rust shenanigans, is the mrustc -> rust-1.29 very slow compared to the rust upgrades? <rekado>it’s also not trivial to build all this TeX stuff from source. It seems that most distros just install pre-built stuff. <jpoiret>true, i've looked at how tex handles things internally like formats and stuff. pretty gross imo <rekado>podiki[m]: could you show us what texlive* packages you have installed? <jpoiret>which is why i would love to switch to something HTML+CSS-based <rekado>as robin wrote, the texlive package (when installed alone) has a working lualatex. <buo>How could i get public key for guix iso ? <jpoiret>with some pre-processor in front but i'm not sure yet <rekado>but it should also work with just the modular packages. <podiki[m]>rekado: not at my Guix computer right now, but I ended up using the full texlive (plus maybe some other little package, can't remember) <rekado>I’d advise against combining the big package with the modular stuff. <podiki[m]>rekado: on core-updates-frozen? that's where it wasn't working even with texlive full <rekado>the modular stuff works by building a config file and pointing an env variable to that file; so the assumption is that you use the modular packages exclusively. <podiki[m]>yeah, would prefer to use modular only, but some small package wasn't available separately <GNUtoo>roptat: rekado: after git clean -dfx it seems to pass the documentation build <GNUtoo>I also did guix pull and guix package -u and disabled all my extra scm files <rekado>podiki[m]: I can reproduce the error on core-updates-frozen. Damn. <rekado>fixing this would likely lead to another full rebuild <GNUtoo>Given that I already tries the rest before it might be guix pull and/or guix package -u that fixed it for me <podiki[m]>rekado: I didn't have a chance to look for what change did it or how to fix it. xelatex works. somewhere not including/building the .fmt file for lualatex? <GNUtoo>I'll also reply on the bugreport when It'll have finished building <jpoiret>to note is that now there are two engines: luatex and luahbtex <jpoiret>maybe the error stems from that? i think luahbtex is becoming the default, maybe messing with some things <rekado>hmm, texlive.tlpdb does not even mention lualatex.fmt <rekado>oh, it mentions no fmt files at all <rekado>in any case: texlive-latex-base has that file. Gotta check exactly how it’s built. <rekado>we disable a whole bunch of formats that we cannot build that early in the process, and then we run fmtutil-sys on the patched file, which should do the right thing. <rekado>the cause for trouble lies in texlive-kpathsea, which contains share/texmf-dist/web2c/fmtutil.cnf <rekado>the previous file said this for lualatex: <rekado>lualatex luatex language.dat,language.dat.lua lualatex.ini <rekado>lualatex luahbtex language.dat,language.dat.lua lualatex.ini <rekado>i.e. it will try to build the lualatex fmt file with luahbtex instead of luatex. <rekado>and I suppose at this point in the build we don’t actually have a working luahbtex. <rekado>not sure how to fix this, but I guess we can avoid a world rebuild by adding an extra package that installs a working lualatex fmt file ¯\_(ツ)_/¯ <jpoiret>it'd be pretty straightforward to add proper shepherd dependency for swap- services, adding a swap-device record type with just (path "/path/to/swapfile-or-device") (dependencies list-of-file-sys-deps), would a stringp? suffice to check for old-style and provide compatibility? <podiki[m]>it got me to try out xelatex (probably no difference for my usage, maybe faster?) <podiki[m]>jpoiret: take a look also at the thread on btrfs swap, that seems to need an extra flag (if you are makign swap nicer anyway) <jpoiret>xetex and pdftex are the faster engines <jpoiret>lualatex does a bunch of things on the lua side <podiki[m]>I haven't used plain pdftex in a long time, fonts are too annoying to handle <podiki[m]>gotta run all, glad stuff is getting figured out! <jpoiret>i'll be looking at this, but i don't think there's any need for swap-file or swap-device to handle anything hibernation related, the issue lies in the fact that what it's stored on needing to be mounted at boot (and we can't propagate that "up the dependencies") <jpoiret>although we could just write something to figure out which file-system is needed for hibernation <jpoiret>ohhh, that'd be a good application of this whole thing to figure out the exact parameters for hibernation with a swapfile on btrfs (a famously annoying thing to find) <buo>That is great, Thanks a million nckx :) <jpoiret>why do we need to write (define-record-type* <thing> thing ...), repeating ourselves? is there any use for those two to be different? <vivien>The <thing> can be used with pattern matching