<podiki[m]>the only things in there were the stuff removed anyway <nckx>Although that would be unconfusing, and hence not in keeping with the theme, so I'm not ready to bet on it. <podiki[m]>my inference is that since Arch does not specify i915 or i915g anywhere in latest mesa, but doesn't say users need anything special on their wiki page, that they dropped any support for the older hardware unless it is in gallium (e.g. iris) <nckx>justkdng: No need to apologise, it happens to plenty of people. It's usually ~10 lines at most, this one was special :) <maximed_>as such, you'll need (arguments (list #:phases #~(modify-phases ...) #:make-flags #~(list ...))) <justkdng>was the kick necessary though :/ oh well <podiki[m]>also, as my laptop I write from right now is on Arch with the i915 kernel module and mesa 22....well at least ~6 year old hardware is ok <maximed_>(It's technically possible to make something like what you're doing possible with quasiquote and unquote, but it's a complicated construct, hence I recommend list) <podiki[m]>justkdng: it was nothing personal, but some lag made it come through after all your lines rather than interrupting it <nckx>Yes, my connection is teh suk. Very sorry. Also the reason I sometimes seem to repeat other people like a blithering dolt. <podiki[m]>I don't know what intel code name processor gen that is, but ~2015-16ish <nckx>lscpu would tell you that, but that laptop seems to be 6th gen Intel. <nckx>My 2013 X230T is 3rd gen. The Intel chips affected by the removal should be 1st gen, or 2nd gen according to how deep you delve into (possibly wholly uninformed) comments. <justkdng>I keep getting this error, warning: jobserver unavailable: using -j1. Add '+' to parent make rule. <nckx>So this is not the end of the world that some thought it was. <justkdng>how could I use all cores when building? <nckx>justkdng: That's… not an error, and printed by make, and not something you can change. <podiki[m]>nearing 10year hardware support for graphics by default is pretty decent <maximed_>Is harmless, at worst the package will compile slower due to using less parallelism <nckx>I think it means the upstream makefile is not written in a way that safely supports -j, but I'm not sure. <nckx>I'm not sure which rule or heuristic is used I mean. The build should build fine. <podiki[m]>when core-updates gets subs before a pending merge, we could put out a call for those with older hardware to try, or just pipe up if you use graphics and nearing 10 year old hardware <nckx>I'm sure the Arch package has the same problem. <maximed_>This would all have been less complicated if something like meson was used instead of ad-hoc makefiles. <nckx>More like 20, no? Or are the R200 cards much newer? <podiki[m]>oh I don't know, I was just using your thinkpad as a "known" reference point <nckx>But if you use it wrong it eats your face. <nckx>podiki[m]: Well, I'll let you know if it actually works in practice, to be certain. <podiki[m]>plus is this just for opengl? does it fallback to software rendering for general usage anyway? <nckx>GNUverkty[m]: This isn't the GNU build system. It's a bunch of Makefiles. <podiki[m]>as you say, thinkpads are well represented here, so a good thing to check just in case <maximed_>And the configuration phase can take long (you could compile a few small Rust crates in the time it takes to 'autoreconf -vif && ./configure') <podiki[m]>given how long it takes to remove something from a project like Mesa, I would think it is very old hardware; and the alternative branch with the old DRI drivers is still around <podiki[m]>nckx: and thanks for helping navigate this! a year from my first mesa/core-updates adventure and it begins again :) <nckx>podiki[m]: I think the first Guix meet-up I attended was 100% Thinkpads, at least when I walked in. 20 people or so. Nowadays there are Purism hipsters and PowerBook jocks, but still only, like, 3. <nckx>podiki[m]: We're reading through very confusing (and lacking) docs together, it's the least I could do. <justkdng>finally, had to replace instead of using the PREFIX variable <podiki[m]>hahaha I like your clique-fication of the laptop choice <podiki[m]>it is like everyone tries to make codenames, consumer names, model numbers...more and more confusing as time goes on <justkdng>but I guess that's enough for today, now I have to figure out how to package systemd-boot <justkdng>and after that what packages provide the pk12util and certutil binaries <nckx>Also not what I'd have guessed. <nckx>You asked which packages provide the pk12util and certutil binaries. <justkdng>but anyway, nss:bin does provide those binaries <nckx>Like Maxime I expected it to be one of the big bois, not the one that makes me mutter ‘oh right, that exists’ every 2 years. <podiki[m]>I can check that mesa 22.1.1 builds and send a (core-updates) patch later, I think just removing the dri-drivers flag is all that is necessary <justkdng>sudo certutil -N -d sql:/etc/pki/pesign --empty-password returns certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad database. <nckx>podiki[m]: If you have a (possibly suboptimal but building) mesa@22 patch I'll gladly test it now. <podiki[m]>nckx: and I'll check what flags other distros use for drivers while I'm at it <podiki[m]>oh, I do, based on master I think from some weeks ago (includes libdrm and wayland-protocols bump) <maximed_>Also, ‘bad database’ sounds like you need to create a database first or something. <justkdng>that command supposedly creates the databases <justkdng>but it's ok, I just had to create the folder <maximed_>I'm not seeing why sudo, why create a database as root. <justkdng>can I create folders in /etc as a regular user? <maximed_>But you can directories(=folders) in $HOME <justkdng>according to the service file they should be created by a pesign user <justkdng>just noticed rhboot means red hat boot :) <maximed_>pesign is just for signing things, I don't see the point of doing any service things here. <maximed_>.. Apparently there's a ‘Pesign signing daemon’ <justkdng>pesign has a daemon mode but I haven't used it <justkdng>and I don't think I want to package a service to support it <maximed_>I'd guess that, as long as you don't use the daemon mode, you don't need a pesign user <maximed_>and don't need to put the directories in /etc/pki/pesign <justkdng>pesign expects the database to be in /etc/pki/pesign though <podiki[m]>(my laptop heard talk of graphics and decided to get weird) <podiki[m]>patch is for 22.0.2, but is nonetheless a v22 <maximed_>podiki: nitpick (present in the previous version): (%current-system) looks suspicious there <podiki[m]>also the i686 failing test patch wasn't updated <maximed_>From a distance (only looking at the patch itself), looks like an use for %current-target-system to me <podiki[m]>actually that whole section will be changed since it is all for dri-drivers basically (and enable llvm for all) <podiki[m]>but there are other flags that all use %current-system <justkdng>ok, I think I finally have a working efistub setup <justkdng>but every time I do a reconfigure I'll need to change the cmdline and other files that could change (kernel, initrd) <justkdng>is there a way to sort of obtain the new cmdline values that is sent to grub after every reconfigure? <maximed_>justkdng: Guix System alllows for configuring the bootloader <maximed_>Currently, systemd's bootloader is not supported. <maximed_>kustkdng: linux.efi sounds like something that could easily be produced with (computed-file "linux.efi #~(invoke #$(file-append objcopy "/bin/objcopy") "--addd-section" [...] (string-append #$output)) <maximed_>pesign will have to be run outside the store, though maybe not a big problem because gnu/bootloader/grub.scm runs grub-install somehow. <maximed_>I suppose it could be extended to optionally allow signing with "pesign" etc as well. <maximed_>‘but pesign is for secure-boot’ <- what does the but apply too? <bdju>glad to see qutebrowser was updated. the sound still doesn't work, unfortunately. I wonder if I'll ever figure that out. <lechner>Hi, what's a good strategy to change a package definition while retaining its name (or somehow taking the place of the stock version) please? <bdju>how do I list shepherd services? sudo herd list services just tells me "services" is not a valid service, and removing it gives me a generic usage line that isn't very helpful <kaelyn>nckx: I like the idea of adding gcc:lib to gcc-toolchain. I've found it quite odd that there's no way to expose libstdc++ and libgcc_s using "guix shell" <bdju>I've actually been using it for years, just never seem to know enough to do what I want :( <tribals>Does guix pull actually updates *already installed* packages? Or I'm required to `guix package -u` each time after `guix pull`? <bdju>guix pull is like an apt update but not like an apt upgrade afaik. just changes which packages will show up in a search and which ones will be installed / upgraded to if you do those other actions <bdju>so yes you'll need to do guix package -u or similar <lechner>tribals: for an update of your user's packages, you have to run guix package -u <lechner>tribals: 'guix pull' updates the installer (and build daemon) <bdju>does anyone else here use qutebrowser? I wonder if I'm the only one with broken sound <bdju>which package provides amixer and aplay? <bdju>checked on an arch machine and it seems like it's probably alsa-utils <lechner>bdju: which sound daemon are you using? <bdju>pulseaudio. everything but qutebrowser works and qutebrowser has never had working audio as long as I can remember using it on guix system <bdju>nothing shows for qutebrowser in pavucontrol at all when sound is playing <bdju>I'm finding similar issues on other distros and I wanted to try to follow steps people suggested but was missing a lot of programs being used <bdju>no clue what to do with this info now that I can see it. hm <mitchell>I am trying to run guix pull on my pinebook-pro but the daemon is complaining that it can't parse the derivations guix is giving it. "expected string `Derive(['" is what it is saying <bdju>lechner: no. and again this has been a non-stop issue for over a year, nothing that just happened recently. I just hoped maybe it would be fixed by an update <bdju>muting a tab is temporary also <bdju>I have never managed to run into another qutebrowser user around here so I don't know if everyone's sound is broken or if it's just me <bdju>sometimes I fear I'm the only one even using it <bdju>aplay doesn't seem to actually play sound, just lists some text output <bdju>at least with that command from that thread <bdju>thanks for trying to help so far. it could just be a configuration problem I suppose <bdju>ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave <bdju>aplay: main:830: audio open error: No such file or directory <bdju>you might be on to something here <bdju>is there a way to find out who updates the qutebrowser package and contact them? <bdju>I've been informed that pulseaudio support in qutebrowser is optional at buildtime. so maybe it could be added to the recipe <bdju>okay I'm getting somewhere <bdju>lack of asound.conf... I believe I need an alsa service running <bdju>error: alsa-service-type: unbound variable <bdju>anyone have a config.scm with an alsa service I can look at? <bdju>needed to add "sound" to service-modules <bdju>oh god aplay plays sound now but it's some horrible loud screeching noise and not the sound I tried to play <lechner>bdju: it could be a sampling rate mismatch, or you are possibly competing with PulseAudio. did you restart your computer? <bdju>restarted qutebrowser and it shows in pavucontrol now! <lechner>congratulations! it only took a year <bdju>thank you for the assistance <bjc`>does anyone know of a guile function index? i'm trying to find the definition of ‘system*’ <bjc`>oh, it was there after all <bjc`>but man, the documentation for guile is terribad <bjc`>it's a bigger issue than a simple patch, unfortunately <bjc`>generating an index would be a start, though, and that seems possible <justkdng>is there a way to view the Make.defaults.rej file after a bad patch? <justkdng>a patch keeps failing and I don't know why <bjc`>use ‘-K’ on the build, to keep the failed build results, which you can inspect <bjc`>i can't remember off the top of my head. /tmp somewhere? i think it tells you when it breaks <nckx>‘The documentation is terribad’ is honestly not unfair, ‘therefore I will assume it lacks X’ is. <bjc`>sorry, table of contents <bjc`>i rely on ddg a bit too much, maybe. and "guile function index" was a useless query <bjc`>i should have tried "procedure" instead of "function". i know thats what schemers call it, but for some reason i can't help but use the term "function" <nckx>I think in the context of Guile ‘functions’ is C, and I guess DDG isn't clever enough to think ‘you probably meant procedures’. <nckx>I think it took me a full year to stop saying function and offending delicate company. <bjc`>i find it particularly odd because how much lisp people tend to go on about "functional languages", and here's guile calling everything a procedure <bjc`>it feels very 1980s, if i'm being honest. like pascal or something 🙂 *nckx wonders how much the procedure → function naming shift was purely marketing (not corporate, just memetic) because ‘procedures’ were what — yes, exactly what I was going to say. <nckx>‘lol, you're still using procedures? Man, get a whiff of these fUnCtIoNs! Yes they are just procedures shut up.’ ***Xenguy_ is now known as Xenguy
<nckx>And knowing lispers, they probably looked upon this with disdain, if they bothered to peek down between the clouds at all. <lechner>Hi, what is the easiest way to patch the symbols in xkeyboard-config to include a custom layout, please? <nckx>bjc`: Conversely, I'm always a bit on edge when a programming language makes a big deal of functions, like Haskell. Like they're pretending to be mathematics. <nckx>lechner: Either you ask that a lot, or a lot of people ask that. <lechner>it's a conceptual question since the package variable is used elsewhere. <bjc`>my biggest issue with haskell is that it i have to read it like math and it makes my brain throb *podiki[m] builds mesa 22.1.1 <podiki[m]>for the record, if you try to build mesa with our current configuration options: "ERROR: Problem encountered: Mesa's main branch no longer has any "classic" drivers, use the "amber" branch instead." <podiki[m]>anyway, builds fine on x86_64, now to do x86 <bjc`>is anyone here using podman on guix? it seems like it's not installing all the files in /etc/containers? <podiki[m]>there was discussion of podman in not distant past, here (see logs) and/or the mailing lists <podiki[m]>so someone is using it, might also check the package definition, there may be a comment about something related to this? <bjc`>the_tubular: how are you installing the stuff that's supposed to go in /etc/containers (eg, policy.json) <bjc`>did you just copy stuff there, or is there an activation somewhere i missed? <podiki[m]>btw, guix refresh <package> -u doesn't output anything useful if the updater doesn't work (like it can't auto fetch a version), while without -u it does output a message <the_tubular>I'm just waiting for someone to fix the package I guess <bjc`>the_tubular: i wonder why it's like this in the first place. there's gotta be a reason. maybe making the config records and activations was daunting? <bjc`>yeah, it seems a bit behind <justkdng>is the nss package too important? I'm getting some errors due to what I think its old version <justkdng>current nss is 3.79 and guix's nss is 3.72 <podiki[m]>did you do a fresh install and not do a guix pull? (and/or guix system reconfigure) <podiki[m]>ah it appears guix refresh doesn't pick up the newer versions of nss <justkdng>it seems the new nss needs to be packaged <podiki[m]>mesa built for --system=i686-linux successfully; next I'll have to investigate the configuration options and some tidying <justkdng>Assertion failure: item->data == NULL, at secitem.c:34 <podiki[m]>nss is borderline staging/core-updates material; let's see if it is a quick patch at least... <bjc`>the_tubular: are you using podman rootless, by any chance? <bjc`>i figured as much, but was worth asking ;) <podiki[m]>justkdng: thanks for noticing, but unfortunately nss 3.79 is failing to build and I'm not sure what the error means <podiki[m]>I'll report it and let someone else take over <podiki[m]>let me try 3.78 first, which is what mozilla says is most recent on releases page <jab>Hey Guix! Who else is starting to get conscerned that their old librebooted ThinkPads are no longer secure from all the silly Hardware vulnerabilities? <podiki[m]>actually 3.78 may be fine, justkdng where did you get 3.79 from? I do see sources but not release notes <mitchell>how do i install the c library man pages? <justkdng>podiki[m]: it seems arch is considering nss from commit 3463596523bee515266f572dc73e6724e68f6afd <podiki[m]>waiting for the tests for 3.78 to finish, but should be okay for an easy patch <podiki[m]>not sure when it can be merged to master as it has just over 1800 dependents <podiki[m]>there's some discussion I saw of core-updates merge this summer <podiki[m]>anyway, if you just need newer nss for something, you can use package transformations to point manually to the version of the source you want <podiki[m]>unfortunately --with-latest won't work here I dont' think (since guix isn't picking up the new version),but you can use --with-source <podiki[m]>or for a package, inherit nss and change the source fields *podiki[m] forgot how long nss tests take, no wonder riscv has them disabled since they take >30 hours there <justkdng>I don't know how to do any of what you just said <podiki[m]>what do you need to use nss for? do you need the package installed or as part of writing a package definition? <podiki[m]>and you are sure the problem you have is solved with nss > 3.72? <podiki[m]>let me find an example for you of how you would use newer nss in your package <justkdng>and arch's nss is 3.79 (or what the consider 3.79) <justkdng>right now pesign builds and runs, but signing doesn't work for some reason <justkdng>it could be something completely unrelated to nss but I have to start somewhere <podiki[m]>you'll see a "p11-kit-next", ignore the arguments section and you see it just inherits the regular p11-kit package and puts its own version and source (overwriting the p11-kit) <podiki[m]>do the same for nss, say "nss-next" and then use that instead of "nss" in your package (pesign) inputs <podiki[m]>and if you want to save some time, you could disable tests in nss-next since that is still running for me <podiki[m]>or if you want to disable tests, add in arguments with just a #tests? #f <podiki[m]>(feel free to use a paste to send what you have, though I have to run soon) <podiki[m]>I think that's fine, the hash should be "0048lqnxfx0qd94adpb6a1cpsmcsggvq82p851ridhc7wx0z6mgl" (it'll complain if you don't ahve it and tell you that's what it got) <podiki[m]>you could add in an "(arguments `(#:tests? #f))" to disable tests <justkdng>added the no tests argument and now I get a new error <podiki[m]>maybe change the bottom to nss-next to try that... <justkdng>seems there is no longer a ./configure file <justkdng>their PKGBUILD doesn't have ./configure anywhere <podiki[m]>it is something strange, nss is fine (just built 3.78) but maybe messed up the inherit or something else... <podiki[m]>sorry not seeing it right away and gotta run <podiki[m]>the patch you gave doesn't apply, but fixed the weird nss thing you were seeing <podiki[m]>I didn't realize nss has a more complicated source origin (with patches), so better to copy that, or best the whole thing <podiki[m]>sneek: later tell justkdng the problem was not copying all of the origin for nss (there were patches and such), see the log for a paste of a corrected version, but your pesign patch didn't apply so I didn't build pesign <podiki[m]>sneek: later tell justkdng the paste is with all of nss copied since I was lazy, but minimal is to copy all of the source field (change the hash) and then can add to the arguments to disable tests (can't overwrite all of arguments since there is more in there) ***daviwil_ is now known as daviwil
<Christoph[m]><lechner> "About Haskell, is there a tool..." <- My impression is that Haskell support is not well developed in guix in general. GHC is not bootstrapped yet, maybe that makes people hesitant? Is there a Haskell-in-guix subcommunity? <jackhill>Christoph[m]: there are definitely soem haskellers and ex-haskellers around, but yeah, there are some bumps to overcome like the bootstrapping thing. <jackhill>on the other hand, we have enough of it to support elm which makes web-dev with Guix possible without solvving the javascript probably, so maybe that will infuse energy ***lukedashjr is now known as luke-jr
***janneke_ is now known as janneke
<foo-dogsquared>hello! im trying to update one of the rust apps (hexyl) but one of the dependencies (rust-clap-3) needs an update; one other package (zoxide) needs it to be in a specific beta version and it fails to build with the newer version <foo-dogsquared>should i proceed with submitting the patches or should i add fixes to those patches? <lechner>Christoph[m] jackhill: Hi, why is the bootstrapping thing so important, please? <jackhill>lechner: haha, I forgot about that idea. Like many of my ideas, I got distracted before I could implement it, and didn't really need my custom module after all. I did learn some additional challenges of using the FFI, is that the way C APIs are constructed is different than Haskell, so there's some impedence matching to do. <jackhill>lechner: anyway, I know there was someone iterested in improving the PAM services in Guix. Is that you? <unmatched-paren>maybe we could have a `guix papercuts` list of specific minor but annoying issues, for example "guix gives a confusing message when the internet connection cuts off" ("guix has confusing errors" would be too general). then when someone finds something minor that annoys them, they can update the list, and if someone has some free time, they could look through the list to find a minor polish improvement to make. <f1refly>i sent a bug report regarding thunar not seeing gvfs and thus not making thunar-volman available some time ago, but I still don't see it in the issue tracker. has it gotten lost on the way, should i resend it? <Christoph[m]>lechner: I was trying to understang why Haskell doesn't really work in guix, and bootstrappablility is importent for guix. On the other hand, Nix and Haskell seem to be in a kind of symbiosis, and maybe that combination works so good that guix is somehow out of the game? <rekado>Christoph[m]: bootstrapping GHC is terribly difficult. In all these years we’ve tried different routes and each time we fell short. <unmatched-paren>rekado: that's the one. i couldn't find it since it's in your pastebin :) <unmatched-paren>seems like the blynn compiler might be our best option, but it's incomplete and seems dormant <rekado>i think it would already be an improvement to build GCC 4 from the generated C files and build up the rest from there <attila_lendvai>rekado, for Idris2 i have set up a git repo that contains each consecutive stage of the language in a *branch* that is needed to bootstrap the next one. that way it's possible to patch old versions for bootstrap purposes. (it's yet to be merged with my build system refactor that can bootstrap Idris2 all the way from GHC) <Christoph[m]>unmatched-paren: Could there simply be a `papercut` tag on the issue tracker? ***caleb__ is now known as KE0VVT
<Christoph[m]>rekado: I'm well aware that it's not for lack of trying. But I'm also worried about the other end. GHC 9.2 is <Christoph[m]>out, it's full of new features, and it's being used, but it's not packaged in guix yet. <unmatched-paren>well, that's half the reason we haven't been able to bootstrap ghc yet :) <rekado>Christoph[m]: packaging new GHCs is generally not too difficult. Do you have a patch for it already? <Christoph[m]>No. I started reading the cookbook for that. Give me some more time. :-) <fps>[guix being older than a few days.. it was fresh from the installer] <nckx>Oh boy, more than a year. <nckx>So the good news it that it shouldn't be possible to do that anymore :) <fps>maybe it's time to update the installer image ;) <nckx>guix show: error: promise: package not found <nckx>Basically at(1) but it feels *very* bad if it misses a run. <unmatched-paren>You have a new message from promise-daemon@localhost: "I'm so sorry!!! Please forgive me, master!" <unmatched-paren>And then you reprimand it for filling up your inbox with such a gigantic message, and it sends you another one to apologise. <nckx>unmatched-paren: Thank you for reporting the Dub bug that I forgot to report. Go me. <nckx>Weird, I don't have the original mail. <unmatched-paren>nckx: I spent a while learning the basics of D until I realized the extent to which it suffered from the second-system syndrome. <nckx>And the world's most lenient spam filter. <nckx>s/for reporting/for actually working on/ <unmatched-paren>I'm trying to make an effort to help with the huuuuge amount of issues that come in to the tracker :) <unmatched-paren>nckx: should i include gcc-toolchain as an input to my updated dub package, since it's failing with "ld not found"? <nckx>I guess so. It might be overkill but get it working first. <jobor>What's the reason for the cmake package being at 3.21.4? Latest release is 3.24.0. Is staying on that version some safety consideration? <efraim>jobor: it has enough dependencies to go into core-updates <efraim>so it only gets bumped yearly or so <jobor>efraim: ah that makes sense, thanks <jobor>unmatched-paren: I've seen worse :) <nckx>We don't hold back working updates ‘just in case there's a new bug’ (which is what I assume ‘safety considerations’ to be). If it doesn't break anything, in it goes. <nckx>Sometimes even if it does break anything 👍 <fnstudio>hi, i was keen to install tabularray, a latex environment; i don't seem to see it packaged already, so i thought it could be a matter of guix <fnstudio>the above import fails but then i must be doing something wrong? <fnstudio>the importer says "guix import: error: failed to import package 'tabularray'" <fnstudio>am i supposed to find a full log anywhere in particular? <fnstudio>also, suspiciously... this returns no match: "guix shell texlive-base -- tlmgr info tabularray" <fnstudio>so i started wondering what texlive database guix's /tlmgr reads from <fnstudio>unmatched-paren: hey, no worries! thanks for helping!! <nckx>Esp. importing modules like (gnu packages commencement) that are… resistant to importing. <unmatched-paren>ah, i am importing commencement. should i (@ (gnu packages commencement) gcc-toolchain) then? <nckx>There are modules that get away with importing commencement, but they are few. <nckx>Maybe ((gnu packages commencement) #:select gcc-toolchain) would work, and it's a bit nicer. <nckx>In your use-modules section. ***wielaard is now known as mjw
***jesopo is now known as jess
<unmatched-paren>civodul: huh, maybe the last time i used it was before then. Seems to work now :) <civodul>this is proof that bugs actually get fixed, sometimes <unmatched-paren>(gnu packages commencement) doesn't seem to like being fully imported, @-accessed, OR #:selected... <civodul>it's not supposed to be imported, indeed <nckx>civodul: Re: SAN: ext4: deliberate? (btrfs?) (discuss) <civodul>nckx: on May 23rd there was this thread where we had to recognize that the btrfs had not been fruitful <civodul>meaning we're in the same situation as in January <civodul>the btrfs setup looks promising, but i don't think now's the time to pursue the experiment <rekado>the problem AIUI is mostly due to btrfs + software raid <cbaines>on a slightly different thread, is the idea with this new storage that it's going to solve "the problem", or just defer problems until later <civodul>cbaines: the initial issue we had in Jan. (and still have) is that the storage device we're using is slow <civodul>that's the main problem we're trying to address <civodul>the second one is storage space: we have a 100T at our disposal <rekado>we know that ext4 gives us trouble with inode limitations at large sizes, so whichever file system is less pain to configure well wins. <cbaines>right, so is the idea that this new storage is fast enough, that garbage collection will keep the store size stable, while not blocking builds for too much time? <civodul>rekado: agreed; i'm not sold to ext4, just to whichever solution can be made to work in a matter of days, not months <rekado>we’d start with a new system, new (small) store <rekado>cbaines: storage can be filled up with an ever-growing cache <unmatched-paren>wasn't there talk about using xfs because it's good for large directories like /gnu/store? <cbaines>rekado, right, but I didn't think that was the issue, I though it's been the garbage collection performance and store size <rekado>cbaines: the store is too big, yes <rekado>so we’re going to throw it all away when moving to the new storage <rekado>and keep whatever caches we already have <nckx>civodul: Hey, back, thanks for ‘discussing’ ☺ I'm with you on not wanting any ‘experiments’ for the hell of them, but we seem to get one shot at configuring ext4 definitely good this time, and that's daunting. I also read the previous discussion of btrfs as exposing problems with berlin's software RAID ⋂ our naive initrd btrfs scanning. <nckx>Btrfs has failed to deliver on many promises but we shouldn't be using those. <cbaines>rekado, right, and that will maybe help, but if the store is not kept in check, I think it would be wise to estimate when these problems would return <civodul>nckx: yes, sorry for misrepresenting the issue <unmatched-paren>I have no idea what i'm talking about, but: would it be possible to modify the daemon to include an option to split /gnu/store into multiple subdirectories, like /gnu/store/a for all items with hashes beginning with a? <nckx>civodul: I did not mean to imply that. <nckx>It's complex, spread over much time and very e-mails… <unmatched-paren>obviously the change would be opt-in, for machines that have to have massive stores like berlin <justkdng>whilst we are talking about file systems, how can I enable fstrim for an ssd? <nckx>I asked you about it because I didn't want to rehash what might've been hashed before. <sneek>justkdng, you have 2 messages! <sneek>justkdng, podiki[m] says: the problem was not copying all of the origin for nss (there were patches and such), see the log for a paste of a corrected version, but your pesign patch didn't apply so I didn't build pesign <sneek>justkdng, podiki[m] says: the paste is with all of nss copied since I was lazy, but minimal is to copy all of the source field (change the hash) and then can add to the arguments to disable tests (can't overwrite all of arguments since there is more in there) <nckx>unmatched-paren: That would probably reduce performance, but probably not noticably, but it would be a $pain to migrate… <rekado>unmatched-paren: reference matching would have be aware of these different schemes <unmatched-paren>nckx: i see, just throwing out nonsense in the hope that some of the nonsense is good nonsense :) <civodul>nckx, rekado: if you think btrfs-sans-RAID can do the job (and not have an inode limit!), i'm fine with that <civodul>i'm actually rather incompetent when it comes to file systems :-) <civodul>so we "just" need to come to a decision and implement it *nckx will NOT make a btrfs joke, look at their personal growth and despair. <civodul>thing is, we need to roll our sleeves so the migration can happen soon <nckx>What's the reason for the 10T slice? <nckx>rekado: 10T / + 100T /gnu/store? <rekado>nckx: that was an early test slice <rekado>we used it when things got really tight; had some of our caches on there <nckx>I feel way out of my depth here, too :-/ <nckx>Slices are purely virtualised and can be allocated / given back at (MDC) will? Or should we use that 10T slice now because it's hard to get rid of? <rekado>my colleague will hook up another node of our choosing to the SAN, so we can run boot tests there. <rekado>nckx: I don’t know about the status of the 10TB <rekado>if you want to play with it (e.g. for perf tests) feel free to do that <rekado>the 100TB is officially allocated for us; that remains and could be grown in the future if needed. <nckx>Maxim already ran fio on it and I believe were satisfied with the results, but I never saw them myself. <rekado>open question from me is multipath in the initrd <rekado>you see several 100TB devices on the server right now <rekado>these are all the same SAN slice, but different paths to it. <nckx>…which I know nothing about. <nckx>Right. That was well explained in your mail, thanks for that. <rekado>we should use multipathd to unify them and take advantage of the redundancy this provides <rekado>when the SAN goes into maintenance only one path is cut at a time <rekado>if we mount just one of the devices we *will* suffer an interruption at some point <nckx>How frequent is this? Frequent enough to make ‘get it working without multipathd, then add it later’ nonsense? <nckx>The system will deal horribly with that. <rekado>but it could happen with little advance notice, and I don’t want to deal with downtime any more. <rekado>we *don’t* have it in the initrd <nckx>Stupid question: does it have to be? <jorge[m]>Hello, the file system for the installation of Guix system is Fat or NTFS? <rekado>on Friday we should be able to have the SAN hooked up to another node — maybe 130? <nckx>jorge[m]: Guix doesn't use NTFS anywhere. <nckx>So it's either FAT or something else. <nckx>Can you explain what exactly you mean by ‘the file system for the installation of Guix system’? <nckx>rekado: Great. If I'm available on Fri I'll check in here. <jorge[m]>Ready thanks, it is the information for the boot in rufus. <nckx>Ah. That doesn't really have anything to do with Guix, but I'm guessing FAT32 is safer. <apteryx>hmm, building our manual uses the monolitic texlive-texmf (downloading 3.24 GiB) ? <apteryx>I tried: ./pre-inst-env guix build -f doc/build.scm <apteryx>also, I thought this texlive was not supposed to be substitutable <nckx>apteryx: It isn't. Is it substituting the package or the source? <nckx>Isn't substitutable, that is. <nckx>The sourceball, however, is. <apteryx>seems the bug "41602 important texlive-texmf is actually subtitutable" is still open ***bandali_ is now known as bandali
***tox is now known as littleme
<podiki[m]>I must have built it before, it just grafted now; but I'm with mesa 22.1.1 <podiki[m]>nckx: yes, it built; let me paste you my current patch version (which might be nearly final anyway) <justkdng>is it possible to not install bloat from %desktop-services ? <podiki[m]>you don't have to use %desktop-services either, you can create your own service list, or start from %base-services <apteryx>how do I get PDF manuals out of guix build -f doc/build.scm? It produced an output containing only HTML manuals <justkdng>unmatched-paren: add (delete gnome-service-type) ? <unmatched-paren>you can just remove its entry from your service list and reconfigure <justkdng>oh, is there a list of services that are included in %desktop-services <justkdng>for example, which service sets XDG_RUNTIME_DIR ? <nckx>apteryx: make doc/guix.pdf <unmatched-paren>i think i ran into that issue at one point. can't remember how i fixed it though. <nckx>apteryx: Maybe build.scm needs to be modified to do it there? <nckx>(It needs all of tex, so I'm not going to mess with it.) <unmatched-paren>justkdng: you'll also probably want to make swaylock setuid if you're going to use it <justkdng>hope you don't mind me borrowing stuff from it <unmatched-paren>justkdng: consider it all GPL-3.0-only :) i really should add a license notice <podiki[m]>any yubikey (or other fido2/u2f key) users here? the u2f/fido2 (tap to verify) used to work but has stopped <podiki[m]>I was behind on updates for a month so now I can't be sure what changed, possibly from staging merge? <justkdng>is editing scheme code with vim considered heresy? :) <unmatched-paren>the only problem is that vim-paredit is rubbish, and i haven't found a better solution :( <justkdng>huh, I thought all guix users were part of the church of emacs <unmatched-paren>roptat[m], podiki[m]: you know any good paredit-like plugins for vim? <podiki[m]>unmatched-paren: no worries! i'm a heretic in many other things I am sure <civodul>apteryx: re doc/build.scm, there's a comment: last i looked we could *almost* build the manual with the modular texlive; there were issues with languages other than English <unmatched-paren>justkdng: it's a plugin for Emacs (with a really bad imitation for Vim) that helps you edit s-expressions <podiki[m]>justkdng: one of the popular parenthesis modes for emacs, forces balancing, lets you manipulate sexps (it is one of the older ones too, there are newer variations of this idea too) <unmatched-paren>the (foo ...) style, whereas m-expressions (i think that's the name?) are the foo(...) style <podiki[m]>everything in a lisp is an s-expression, surrounded by comforting () <unmatched-paren>Except, you could argue, for reader macros. Like `'...` and `#~...`. <nckx>Even ‘guix pull --dry-run’ builds texlive-bin. <nckx>justkdng: Guile is an implementation of Scheme is a minimalistic dialect in the Lisp family. <unmatched-paren>the two major dialects of Lisp are Common Lisp (occasionally just referred to as Lisp) and Scheme <nckx>unmatched-paren: By not parsing .dir-locals.el ? <apteryx>civodul: yes, I uncommented that texlive updmap.cfg variable; it worked, but there's no PDFs in the output to verify <unmatched-paren>nckx: no, when i opened files i'd already written it completely destroyed their formatting <nckx>So it wasn't just clobbering the guix-specific rules in that file? <nckx>s,clobbering,ignoring/undoing, <unmatched-paren>nope, just clobbering the entire thing (not even reformatting it to adhere to "vanilla" lisp formatting) <roptat[m]>same happened to me, it got lost with parenthesis in strings and comments I think <nckx>unmatched-paren: Yet this is a product that people use. Curious. <roptat[m]>and paredit for vim didn't let me re-balance the parenthesis after that <unmatched-paren>roptat[m]: i'll share that vim-sexp package once i've made it, and you can see if it works well :) <unmatched-paren>i've added a number of vim and neovim plugins to guixrus's vim.scm, so i'll put it there <justkdng>and what service should I use if I want pipewire <podiki[m]>u2f problem fixed, doing what others have done `(udev-rules-service 'u2f libu2f-host #:groups '("plugdev"))` in my config <podiki[m]>we should use libfido2 (libu2f was deprecated I think?) and udev rules from that <podiki[m]>and thanks, from I forget who, that made udev rules be updated without needing to restart, just a reconfigure <civodul>apteryx: guix-manual.drv builds the English manuals and silently fails to build the other ones (it was on purpose that failure would be silent) <civodul>the error is: You don't have a working TeX binary (tex) installed [...] <lechner>civodul nckx rekado: not sure about your storage options, but i'd like to recommend against using any of the RAID features in btrfs, as attractive as they sound in theory <nckx>I think we currently do use raid1, the least worst, but yes. <civodul>uh texlive-updmap.cfg leads a thing without /bin <lechner>jackhill: I have a draft PAM module that calls Guile but am still figuring out how to integrate it into Guix in a meaningful way. it's a super long obsession of mine that previously led to round-trips into Rust and Dhall <lechner>the idea is to replace the "PAM stack" with a more powerful language whose logic is also easier to validate <lechner>rekado Christoph[m] jackhill: Thanks for the refresher on bootstrapping. Does it really hamper Haskell use in Guix, though? Distrust of the compiler and quality of the tooling (which should rival Nix anyway) seem like two different things <maximed>hyperfine, tectonic and fd now compile with antioxidant <unmatched-paren>seems like vim-sexp is just as buggy if not more so than vim-paredit :( *podiki[m] whispers sweet nothings about the joy of emacs <unmatched-paren>I dislike almost everything about it _except_ the superb lisp support <justkdng>why can't I run scripts on /boot? is the filesystem mounted with noexec? <nckx>lechner: Appreciated, but I'm not so much in dubio as you seem to think. <nckx>justkdng: Not by default. One way to find out. Could also depend on the file system type (e.g., a non-unix file system mounted without fake executable bits). <mekeor[m]>unmatched-paren: alright thank you. then i'll have check my rust version and also i probably need to further investigate why building a rust package fails for me. (i think it was stating that a certain version of a certain dependency-package is not available...) <nckx>justkdng: Apologies, I was looking for noexec, not ‘no-exec’ that the Scheme side uses. Lots of occurrences of the latter; it probably is. <nckx>Still don't find /boot though. <maximed>justkdng: e.g., IIRC the FAT filesystem (variants of which are typically used for /boot) doesn't have permission bits <nckx>They don't, hence a default (‘fake’ above) mode is applied by Linux to fill in the missing information. <nckx>Without any extra arguments, FAT is mounted with all files -rwxr-xr-x by default. <nckx>Not Guix-specific, bestest practice anywhere. <nckx>lechner: More Guix-specific and won't work everywhere, I think. <nckx>We got there together in the end. <nckx>The real mode mask was the shebangs we made along the way. <justkdng>elogind[583]: Missing fields in os-release data from unified kernel image /boot/efi/EFI/Linux/guix.efi, refusing. <justkdng>wonder what is elogind is refusing, can't even see it in dmesg <unmatched-paren>how is chicken.scm allowed to use commencement when dlang.scm isn't? <Christoph[m]>lechner: You're right, it seems different. How can we improve the Haskell experience on guix? <unmatched-paren>aha! I needed to (module-ref (resolve-interface ...) ...) instead of (@@ ...) <apteryx>rekado: I'm resuming my experiment with Rocky Linux PXE (cobbler) boot on node 129 -- can't seem to boot Rocky-8.6-x86_64. Which Cobbler OS is known good? <lechner>Christoph[m]: also, i'd love to see a guix (tool) backend to GHCup, or vice versa <ternary>So I'm trying to get docker running on my Guix server, and the docker service requires the elogind service. But as soon as I add the elogind service any ssh connection is instantly dropped after auth <ternary>I get a bunch of messages like this is /var/log/secure <ternary>pam_elogind(sudo:session): Failed to create session: Access denied <Christoph[m]>The Haskell-download page should wait just a little until Haskell support is better on guix. Otherwise, guix will build a bad reputation in Haskell communities. <Christoph[m]>lechner: A tool backend to GHCup, how would that work? GHCup is not packaged in guix, but that's not what you mean, is it? <mekeor[m]>ternary: maybe u need some config for your sshd service? <ternary>The only thing that seems related would be use-pam? but I don't know really know what that would do <kennyballou>This may be an easy one, how can I use a gexp within a home-vars service? Let's say I want to add `("GUILE_DRMAA_LIBRARY" . #$(file-append slurm-drmaa "/lib/libdrmaa.so"))` to my home-environment-vars-service? Currently, however, when I attempt to build this, guix home complains it has an unbound variable `ungexp`. Am I missing some gexp'r magic? <ternary>And I can now confirm that setting use-pam? to #f doesn't change anything <apteryx>rekado: do we *have* to use cobbler for the PXE boot? it seems something more stupid/basic could work better for us <kennyballou>unmatched-paren: yes, still unbound variable `ungexp'. <kennyballou>unmatched-paren: I suppose it could be trying to un gexp later in the process and it's not found somewhere else? <apteryx>rekado: hmm, I'll stop for now, stuck on trying to boot from PXE (none of the images I've tried worked, they all get stuck on e.g. "Loading initial ramdisk ( /images/Rocky-8.5-x86_64/initrd.img ) ..." <apteryx>civodul: I guess it's because GUIX_TEXMF is not set or something <lechner>Christoph[m]: As for improving the tooling, I rewrote the Haskell build system in Debian not too long ago and would be happy to contribute here if someone took me by the hand https://bugs.debian.org/1002296 <maximed>kennyballou: I don't particularly know Guix Home, but why are you using G-exps here? <maximed>Going by the example in the guix manual, home-environment-variables-service does not accept gexps <apteryx>civodul: the texinfo manual suggests we can use pdflatex directly <maximed>and TBC: (file-append ...) is _not_ a G-exp <apteryx>which means we could probably also use xelatex directly, which usually copes much better with non-ascii characters... food for thoughts. <maximed>(that's literally a ',', not punctuation) <kennyballou>maximed: Before, slurm-drmaa was not adding libdrmaa.so to `~/.guix-home/lib/`, so I needed to hard-code the path to the store, which the gexp would provide. But since is is adding it now (I updated recently), I may not need to do it this way <kennyballou>maximed: wait, so I can get the store path of the package with the unquote? <maximed>kennyballou: the unquote does _not_ give you the store file name <maximed>Yet, it will probably work for your purposes. <apteryx>civodul: texi2dvi looks tex from PATH <maximed>The 'unquote' is to put a value returned by a procedure or such in a list constructed with 'quasiquote'. <maximed>This is entirely orthogonal to Guix' notion of G-exps, lowering and file-like objects. quasiquote/unquote come from Guile, not Guix. <maximed>kennyballou: See the example in the manual. <maximed>‘(guix)Essential Home Services’ shows how to do it (look for (file-append zsh "/bin/zsh") and "SHELL") <maximed>kennyballou: WDYM with ‘slurm-drmaa was not adding libdrmaa.so to ~/....’? <kennyballou>maximed: oh cool, there it is. I must have missed the updated man page, thank you! <maximed>Guix doesn't have documentation in man pages. <kennyballou>maximed: I was adding slurm-drmaa to my package set, but I wasn't seeing the library in the `~/.guix-home/profile/lib` directory. It's there now. <kennyballou>maximed: re man page, I'm conflating terms. Last time I read about the home-environment-variables service, it wasn't quasiquoted, IIRC <unmatched-paren>nckx: successfully built /gnu/store/klsc265r3mx61zi7bkp9y7cakhydjzi4-dub-1.23.0.drv <Christoph[m]>lechner: Unfortunately, I'm learning guile and guix myself and feel in no way able to take you by the hand. <Christoph[m]>Is there a guix beginner chatroom? Or are there special interest chatrooms for e.g. Haskell in guix? <vagrantc>Christoph[m]: feel free to ask questions and we'll try to answer them :) ***mark__ is now known as mjw
<unmatched-paren>usual disclaimer that i'm not generally a trustworthy source of information. <maximed>justkdng: The issue was not asking questions, but not using something like paste.debian.net for backtrace dumps <unmatched-paren>maximed: btw, i've sent a third aerc patchset to address your concerns with the pty package :) and thanks for that review :D <unmatched-paren>(not pressuring you to review it, of course, just letting you know :) <unmatched-paren>sneek: later tell nckx: pls tell me if i've broken the dub-build-system once you get packaging that d program you wanted. i don't have an easy way to test it, since there's no dub-build-system packages yet. <maximed>Does someone know why the Apple Public Source License is in guix/licenses.scm? <unmatched-paren>maximed: didn't array programming language company revise it so that it could be counted as free and open? <maximed>It has a ‘Dispute resolution’ clause, which seems to state that Apple can sue you in the US. <lechner>Hi, is there a way to configure guix to automatically delete some old generations, such as those older than the past ten? <maximed>lechner: I meant sueing people outside the US. <maximed>people that are outside the US, and sueing them in the US, <maximed>with a clause in the license that states that ‘no, don't go to $local_court, go to $foreign_court’ <vagrantc>lechner: there's guix gc --delete-generations ... though i've mostly seen it used with time periods <vagrantc>lechner: not sure what other PATTERNs it takes *maximed goes to #fsf with licensing question <lechner>vagrantc: thanks! my hope was for "automatic" <jpoiret>you could run the various guix --delete-profiles commands periodically if that's what you're looking for <jpoiret>i usually do that when i'm running low on disk space <efraim>I've used `guix package --delete-generations 2,3,5,8` and the like before, but mostly 1m for 1 month <lechner>doesn't it have to run in the user profiles, as well, in order to be effective? <lechner>no, i mean that disk space is a system-wide concern <vagrantc>it would seem dangerous to have a user able to run "guix gc --delete-generations" and have it remove system generations or other user's generations <unmatched-paren>lechner: i guess you could iterate over the users, su as each of them, and run guix gc inside su... <lechner>Well, in my encrypted home setup I rely on the root login, too, so I have to expire generations in three places, don't I? <mekeor[m]>(how) can i use the nightly rust-toolchain on guix system? <efraim>you can use `guix package --list-profiles` as root to see all the profiles <efraim>lechner: pretty sure, let me check on one of my work systems <lechner>on a similar topic, i think 'guix gc' is too aggressive for my uses <vagrantc>there's also guix gc --free-space ... though does that remove profiles? <vagrantc>guix gc normally shouldn't delete anything actually referenced by a profile <efraim>lechner: yep, I have 2, vs the 169 across everyone on that system <lechner>why does 'gc' remove prerequisites for software currently in use. those are clearly not "garbage" <vagrantc>lechner: build prerequisites, or runtime? <vagrantc>you can tell guix-daemon to keep that stuff <efraim>check for --gc-keep-outputs and --gc-keep-derivations <maximed>unmatched-paren: #fsf doesn't seem to have answers about APSL, will go to #fsfe to see if they have thought about such matters. <maximed>lechner: It means that the build process isn't run as root but as guixbuildN. <maximed>On guix System, the dropping happens too. <maximed>unmatched-paren: I see you joined and left #fsfe again, are you planning to listen or participate? <maximed>lechner: It means that the build process isn't run as root but as guixbuildN. <unmatched-paren>civodul: i presume you have admin access to the issue tracker; what do you think about the idea of creating a `papercut` tag for minor but annoying issues like the cryptic network failure message? <lechner>maximed: are people supposed to add the file? <maximed>lechner: What file, and adding what? <maximed>unmatched-paren: Maybe civodul has admin access to the issue tracker, but it's very permissionless <maximed>YOu don't need admin access to make a tag. <maximed>You can create tags by yourself by using the ‘usertag’ system. <maximed>There's a little documentation on usertags in the Guix manual. <unmatched-paren>maximed: oh, cool. i guess i'll check if there is an issue for that error message, and create one if there isn't :) <lechner>maximed: the files mentioned in footnote 5 for systemd or upstart, respectively <lechner>Hi, how may I add "--gc-keep-outputs=yes" to guix-daemon with Shepherd, please? <maximed>lechenr: Are you using systemd or upstart? <mekeor[m]>i'm trying to build a rust project which should work with the stable rust-toolchain but i get "error: the option `Z` is only accepted on the nightly compiler […] could not compile `clap_lex`". any ideas? <maximed>lechner: (on gc-keep-outputs) Have a look at the 'extra-options' field of tuix-configuration <maximed>That allows you to use non-stable things with a stable rust-toolchain. <lechner>maximed: no, i am merely confused whether "drop" means delete or "drop into," i.e. add <maximed>lechner: "drop" means that the "root" authorisation is deleted from the build process, it is then replaced by "guixbuildN" <maximed>Effectively, a combination of the ttwo I suppose. <maximed>mekeor: (I've only tested RUSTC_BOOTSTRAP=1 in antioxidant, I don't know if it works via Cargo) <mekeor[m]>maximed: it looks promising. it seems like i further need some guix-environment with pkg-config <unmatched-paren>mekeor[m]: you'll want to add it to native-inputs, and probably add rust-pkg-config <maximed>Probably #:cargo-build-dependencies or #:cargo-dev-dependencies instead because of cargo-build-system <mekeor[m]>maximed: oh, now i get "error[E0554]: `#![feature]` may not be used on the stable release channel" during the compilation of anyhow xD <maximed>lechner: I recommend reading it via info: "info guix". <lechner>Hi, how does anyone consistently find the latest 'devel' docs on the web? <unmatched-paren>lechner: there's also `pinfo`, which provides vi keybindings for info, but it's currently failing to build <lechner>unmatched-paren: no worries, i am a die-hard Emacs user. my bane is the right-click "open" in your favorite browser *unmatched-paren does qutebrowser so has no need for right-click :) <unmatched-paren>lechner: if you want an emacs-like browser, i guess you could try nyxt, but it always felt clunky to me <lechner>unmatched-paren: someone ventured here yesterday that they were the only user of qutebrowser in this channel. they also had no sound. do you? <unmatched-paren>lechner: i'm pretty sure i have sound in qute. lemme run one of the guix.gnu.org videos. <lechner>do you use desktop services or ask for sound there separately? <unmatched-paren>lechner: eww is the emacs browser, but it's hardly suitable for most modern websites, right? <unmatched-paren>lechner: i use desktop-services, but i don't need to explicitly ask for sound <jackhill>I can confirm sound it quite as well. My sound is provided by (at the moment) manually starting pipewire-pulse (as well as pipewire and wireplumber) <efraim>I used jitsi in qutebrowser last week <bdju>my problem was that it's using alsa instead of pulse and my alsa was broken <mekeor[m]>new question: `guix pull` makes my cpu overheat. i tried `--max-jobs=1` but it didn't help. any other ideas? <vagrantc>mekeor[m]: do you have substitutes available? <vagrantc>or do you want to build everything from source... <lechner>mekeor[m]: sorry about the joke. what's the last time you cleaned your CPU fan. <mekeor[m]>lechner: never did. i bought the laptop in 2016. it's a model from 2008-2010 <efraim>can you remove the battery? I've found in the past that it helps a bit <bdju>mekeor[m]: I would suggest undervolting, but the package for that (that I used on NixOS in the past anyway) is not yet packaged for guix <mekeor[m]>vagrantc: i have some non-official, non-substituting channels for at least emacs and emacs packages, so... <bdju>in the past a -70mV undervolt was enough to prevent thermal throttling with no perceivable difference in performance <bdju>no negative difference I should say. by preventing throttling you are in fact improving performance <maximed>I've found removing the battery and the power cord to be very effective in reducing temperature and CPU fan noise :p <bdju>mekeor[m]: you very slightly reduce the voltage sent to the CPU which results in lower temperature <maximed>Though a warning: if you undervolt it too much, below the specifications of the CPU, then potential problems. <mekeor[m]>bdju: interesting. now waiting for the package ;) <bdju>it's also specific to Intel CPUs I think <bdju>I put it on the wishlist years ago so don't expect me to do the packaging at least <mekeor[m]>i could also disable cpu frequency changes which would also prevent hertzbleed <mekeor[m]>maximed: i'm still running into "error: the option `Z` is only accepted on the nightly compiler" (although for a different crate now, probably coincidentally). hm. <apteryx>civodul: seems makeinfo still doesn't support non-Latin scripts well; but at least PDFs for the latin scripts should be produced <lilyp>Option Z is only available for Russian tanks in Ukraine. *mekeor[m] discovers the C in RUSTC_BOOTSTRAP <lilyp>Good evening ladies, someone wanna launch some more supply chain attacks <sneek>Welcome back nckx, you have 2 messages! <sneek>nckx, unmatched-paren says: pls tell me if i've broken the dub-build-system once you get packaging that d program you wanted. i don't have an easy way to test it, since there's no dub-build-system packages yet. <nckx>lechner: IMO that wasn't entirely English. <nckx>unmatched-paren: Perfect, I'll give it anoher go. I don't think I even saved my WIP, so frustrated with D was I. <nckx>I would like to hope that *someone* in the Guix community actually understands or at least uses Dub? <nckx>My LGTM isn't worth that much here. <nckx>But yes, I do, if literally nobody shows up I'll do my best. *nckx has now actually clicked the issue link. <nckx>OK, I thought this was a change to the -build-system. <civodul>apteryx: makeinfo does nothing: texinfo.tex is implemented entirely in raw TeX <civodul>the weird thing is that this works well with the monolithic texlive <unmatched-paren>there's nothing particularly special about it, just another fixed-function language-specific build system/package manager <nckx>unmatched-paren: …which I'd prefer to hold to a higher standard of review than mere packages. That's why I was hesitant. If it's just a package I'm much less so. <unmatched-paren>nckx: well, i haven't been able to test the build system since there are no packages that use it. <nckx>And it's not like anyone was using the broken package. 🤷 <nckx>‘Hey you fixed my workflow, now I have to work, how dare you.’ <apteryx>civodul: ~/src/guix/doc$ guix shell --pure texlive-tex-texinfo texlive-base texlive-bin texinfo texlive-fonts-ec texlive-epsf coreutils grep sed tar gawk diffutils -- tex guix.texi -> {epsf.tex not found, images will be ignored} odd <nckx>unmatched-paren: I will gladly test it. <unmatched-paren>i did rename `rdmd` to `d-tools` to reflect the fact that it installs more than just rdmd <civodul>apteryx: it needs help to find images; i think we set TEXINPUTPATH or something for that, no? *unmatched-paren goes back to figuring out what's wrong with pinfo <apteryx>civodul: seems to complain not finding epsf.tex, unless the error is misleading <unmatched-paren>why would that happen? it's using autotools, so surely it should gcc correctly? <unmatched-paren>should we update it, even if it means using a commit instead of a tag? <lechner>unmatched-paren: where are the sources? <rekado>apteryx: we can only use cobbler. There’s no other PXE server on the network. <apteryx>OK. We should add one to Guix System :-) <rekado>the PXE server needs to broadcast on the network, and so it would conflict with the existing cobbler setup that my colleagues use for network booting. <rekado>odd, though, that none of the selections work for you. I thought we were past that problem already. <apteryx>yeah, last time I had managed to get one Rocky Linux entry working ***tex_milan1 is now known as tex_milan
<rekado>civodul apteryx what kind of tex problems do you have? <apteryx>rekado: I was trying to restore doc/build.scm using a more minimal texlive <apteryx>seems GUIX_TEXMF was the missing component for it to work. And on the way I got lost in understanding why it fails on non-Latin script (tl;dr: a current limitation of Texinfo, as hinted by a comment in build.scm) <rekado>texlive-bin is not needed; texlive-base contains texlive-bin <apteryx>Oh right, this was added while experimenting; thanks for catching it <rekado>I remember debugging the escaped characters long ago *apteryx checks the ToC for missing chars <unmatched-paren>lechner: ah, i see. wasn't even trying to look for the problem, because it seems bizarre that a tagged version would have such issues <unmatched-paren>(I've aliased `vinfo` to `info --vi-keys` in fish now, but i'll still be trying to fix pinfo :) <apteryx>rekado: the French PDF didn't get built; did we have it currently? <apteryx>rekado: actually texlive-bin is needed it seems... for the GUIX_TEXMF I suppose. <apteryx>it's the one carrying the search path specification <apteryx>for the german manual, it fails with: /gnu/store/q6h5r9an5znqd8mxsyzqcqiq3v4wp7dc-texinfo-manual-source/guix.de.texi:21295: ==> Fatal error occurred, no output PDF file produced! <apteryx>after printing /gnu/store/q6h5r9an5znqd8mxsyzqcqiq3v4wp7dc-texinfo-manual-source/guix.de.texi:21295: TeX capacity exceeded, sorry [input stack size=5000] <rekado>apteryx: texlive-base propagates texlive-bin. Is that not enough? <apteryx>rekado: it's not enough unfortunately <apteryx>rekado civodul I pushed the fix as 1cde647cc0; thanks!