IRC channel logs


back to list of logs

<podiki[m]>oh could be
<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.
<justkdng>this is the complete log. This is the pesign.scm file I have so far
<maximed_>justkdng: ' is not equivalent to 'list'
<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
<nckx>Which hardware exactly?
<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
<podiki[m]>nckx: dell xps 9550
<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>ok ok
<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?
<maximed_>justkdng: it's not an error
<nckx>justkdng: That's… not an error, and printed by make, and not something you can change.
<maximed_>It's a warning.
<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?
<nckx>podiki[m]: ☝
<GNUverkty[m]>is the GNU build system really that bad? :(
<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
<maximed_>justkdng: probably openssl or gnutls
<nckx>justkdng: nss
<nckx>nss:bin, to be precise.
<nckx>Also not what I'd have guessed.
<nckx>By what?
<nckx>You asked which packages provide the pk12util and certutil binaries.
<justkdng>> Also not what I'd have guessed
<justkdng>but anyway, nss:bin does provide those binaries
<justkdng>but now more errors :(
<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
<nckx>podiki[m]: Okie.
<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
<maximed_>judstkdng: needs context
<maximed_>Is this while building a package?
<maximed_>Or outside?
<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.
<maximed_>Probably nss people know more.
<justkdng>that command supposedly creates the databases
<maximed_>Then I dunno.
<justkdng>but it's ok, I just had to create the folder
<maximed_>I don't know any nss.
<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_>justkdng: No.
<maximed_>But you can directories(=folders) in $HOME
<justkdng>ohh, you mean the database creation
<justkdng>according to the service file they should be created by a pesign user
<justkdng>and owned by them
<maximed_>justkdng: what service file?
<justkdng>just noticed rhboot means red hat boot :)
<maximed_>why is this a service
<maximed_>pesign is just for signing things, I don't see the point of doing any service things here.
<justkdng>you'd have to ask mr David Runge
<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>guix isn't redhat ;P
<nckx>Gee, thanks:
<justkdng>pesign expects the database to be in /etc/pki/pesign though
<justkdng>thought thatn can be changed
<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
<nckx>podiki[m]: Thanks!
<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]>yes, that's a good point
<podiki[m]>I'll make a note for a more proper patch
<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_>But you could implement that.
<justkdng>indeed I could
<justkdng>after I learn more scheme
<justkdng>this is the script I currently have for creating efistub images.
<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.
<justkdng>some scheme trickery
<maximed_>Maybe see gnu/bootloader/grub.scm?
<justkdng>but pesign is for secure-boot
<maximed_>I suppose it could be extended to optionally allow signing with "pesign" etc as well.
<maximed_>justkdng: I'm not following
<maximed_>‘but pesign is for secure-boot’ <- what does the but apply too?
<justkdng>hmm, I guess it means its optional
<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"
<lechner>bdju: herd status ?
<bdju>lechner: thank you
<lechner>bdju: thank you for using Guix!
<tribals>Hello! ^_^
<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`?
<lechner>bdju: sorry, i am new and in love
<bdju>glad you're enjoying it
<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)
<tribals>bdju: thanks
<tribals>lechner: thanks
<tribals>Now it's clear :D
<bdju>does anyone else here use qutebrowser? I wonder if I'm the only one with broken sound
<bdju>issue #45280
<bdju>which package provides amixer and aplay?
<bdju>checked on an arch machine and it seems like it's probably alsa-utils
<lechner>bdju: yes
<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> such as here
<bdju>no clue what to do with this info now that I can see it. hm
<lechner>bdju: are you in the 'audio' group?
<lechner>bdju: did you accidentally mute qutebrowser with Alt-m?
<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
<lechner>bdju: maybe it's a device problem. can you initiate playback directly on ALSA, which is what QB may be using, with aplay?
<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
<lechner>bdju: aplay takes a filename
<lechner>bdju: this has a bunch more debugging ideas
<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> found this to 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!
<bdju>I think I have sound
<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*’
<lechner>bjc`: does thos help?
<bjc`>oh, it was there after all
<bjc`>but man, the documentation for guile is terribad
<lechner>they probably accept patches
<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
<justkdng>and where are those build results?
<bjc`>i can't remember off the top of my head. /tmp somewhere? i think it tells you when it breaks
<nckx>bjc`: ?
<bjc`>perfect. thank you!
<nckx>‘The documentation is terribad’ is honestly not unfair, ‘therefore I will assume it lacks X’ is.
<bjc`>was that in the toc?
<bjc`>sorry, table of contents
<bjc`>i rely on ddg a bit too much, maybe. and "guile function index" was a useless query
<nckx>It's the top result for ‘guile procedure index’. But no, it's not part of the ToC, it sits outside of it because books (remember, you'll want to sell manuals to fund your free software development one day!! You'll make… multiple dollars!!) see <>.
<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’.
<bjc`>that's exactly correct
<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.
<lechner>it's close
<nckx>It's cosplay.
<nckx>lechner: Either you ask that a lot, or a lot of people ask that.
*nckx doesn't know.
<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."
<nckx>Oh, I didn't even try.
<podiki[m]>also found an indentation error :-P
<podiki[m]>I guess "classic" = -dri-drivers?
<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
<the_tubular>I am bj
<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?
<the_tubular>Did it the dumb way and manually created it
<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
<lechner>About Haskell, is there a tool to convert Nix deployment specs to Guix?
<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?
<the_tubular>The package as a whole need a bit of work.
<bjc`>yeah, it seems a bit behind
<the_tubular>No clue, maybe he didn't knew,
<the_tubular>It's behind and it's broken
<the_tubular>Well it needs manuall work for it to work
<bjc`>that's not encouraging
<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]>guix is using 3.72
<podiki[m]>did you do a fresh install and not do a guix pull? (and/or guix system reconfigure)
<the_tubular>Yeah you'll also have to mount stuff.
<podiki[m]>oh whoops switched the numbers sorry
<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>I'm sadly getting assert errors
<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?
<the_tubular>No, couldn't get it to work
<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
<justkdng>as 3.79
<justkdng>so I guess 3.78 is the official release
<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?
<justkdng>I was trying to package pesign
<justkdng>and it requires nss
<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>well, pesign works under arch
<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
<podiki[m]>if you want to try with newer nss and learn some more packaging tools, look at
<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
<justkdng>so I keep arguments intact?
<podiki[m]>no, remove that from your nss-next
<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)
<justkdng>I tried this
<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)
<justkdng>nope, it's not building
<podiki[m]>you could add in an "(arguments `(#:tests? #f))" to disable tests
<podiki[m]>what does it say?
<justkdng>I get this error
<justkdng>added the no tests argument and now I get a new error
<podiki[m]>I assume you are building using -f file.scm
<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
<justkdng>I'll leave this one to the pros
<justkdng>I'm a scheme noob
<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]>I'll try your file later though
<podiki[m]>good luck in the meantime!
<justkdng>it needs a flags.patch file, here it is just in case
<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]>will require more modules explictly, but anyway, here:
<podiki[m]>justkdng: ^
<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)
<sneek>Will do.
***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?
<lechner>jackhill: do you also care about PAM?
<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: I'm afraid that I can't do give a better bootstrappable explaination than
<jackhill>oh, and of course
<jackhill>lechner: anyway, I know there was someone iterested in improving the PAM services in Guix. Is that you?
<jackhill>(bedtime for me though)
<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.
<unmatched-paren>of course, minor polish improvements go a long way ;)
<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>Christoph[m]: there was also a more recent part 2 but i can't find it
<unmatched-paren>( is rekado's website)
<rekado>this one is more recent:
<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
<rekado>then close the gap later
<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)
<unmatched-paren>seems like hare-iobus's tests fail on the latest hare{,c}
<unmatched-paren>wrong channel :P
<Christoph[m]>unmatched-paren: Could there simply be a `papercut` tag on the issue tracker?
<unmatched-paren>Christoph[m]: i suppose so
***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>> full of new features
<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>nckx: i guess so :)
<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>hah :)
<fps>maybe it's time to update the installer image ;)
<unmatched-paren>fps: veeeeerry soon now We Promise(R)
<nckx>guix show: error: promise: package not found
<unmatched-paren>`promise` sounds like the name of some scheduling tool
<unmatched-paren>ʃ promise rm /var/log/somedaemon/*.log --at 14:20 --every monday
<unmatched-paren>or something
<nckx>Basically at(1) but it feels *very* bad if it misses a run.
<nckx>(Using AI.)
<unmatched-paren>You have a new message from promise-daemon@localhost: "I'm so sorry!!! Please forgive me, master!"
<unmatched-paren>The message body is just "I am a failure" repeated over and over.
<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>I don't speak a lick of D, sorry, but I wanted to package <>.
<unmatched-paren>nckx: I didn't report that bug :)
<unmatched-paren>I replied to it, though.
<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.
<unmatched-paren>anyway, i'm fixing up dub
<unmatched-paren>right now :)
<unmatched-paren>"build failed" :(
<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.
<unmatched-paren>We had v1.7 dub. The latest version is 1.23 :P
<unmatched-paren>which explains the build failure, certainly
<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?
<unmatched-paren>jobor: it's probably just hellish to package
<unmatched-paren>remember, CMake is Real Enterprise Software!
<unmatched-paren>I once looked in its codebase; never again.
<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>"guix import texlive tabularray"
<unmatched-paren>fnstudio: looks like a perfectly straightforward tex package :)
<fnstudio>oh ok
<fnstudio>the above import fails but then i must be doing something wrong?
<unmatched-paren>oh? let's see the log please
<unmatched-paren>i mean it has a build.lua, not sure if that's normal or not
<fnstudio>the importer says "guix import: error: failed to import package 'tabularray'"
<fnstudio>am i supposed to find a full log anywhere in particular?
<unmatched-paren>i don't think the importer dumps any logs
<unmatched-paren>hmm, maybe it isn't a well-behaved tex package.
<fnstudio>also, suspiciously... this returns no match: "guix shell texlive-base -- tlmgr info tabularray"
<unmatched-paren>sorry, i'm not a tex expert (or even an intermediate user)
<fnstudio>so i started wondering what texlive database guix's /tlmgr reads from
<unmatched-paren>seems like it requires you to use luatex for building it
<fnstudio>unmatched-paren: hey, no worries! thanks for helping!!
<unmatched-paren>not sure how you'd do that though, sorry
<nckx>I somehow missed this (trigger warning: YAML):
<unmatched-paren>ice-9/eval.scm:293:34: error: tcc: unbound variable
<unmatched-paren>hint: Did you forget a `use-modules' form?
<unmatched-paren>from `make` in the guix repo
<nckx>Local changes?
<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>You can try.
<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.
<unmatched-paren>nope, stillj
<unmatched-paren>still happens
*nckx away, sorry.
***wielaard is now known as mjw
***jesopo is now known as jess
<unmatched-paren>Anyone been able to execute Valgrind on Guix without it blowing up?
<nckx>I don't think so.
<civodul>unmatched-paren: what do you mean? was fixed a while back
<unmatched-paren>civodul: huh, maybe the last time i used it was before then. Seems to work now :)
<civodul>good :-)
<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...
<unmatched-paren>idea, i can use (standard-packages) instead
<civodul>it's not supposed to be imported, indeed
<nckx>civodul: Re: SAN: ext4: deliberate? (btrfs?) (discuss)
<civodul>nckx: yes, 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
<rekado>btrfs on SAN might be just fine
<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
<civodul>i think that's a good summary?
<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.
<rekado>civodul: all correct
<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>Not btrfs per se.
<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?
<unmatched-paren>would that improve anything?
<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
<unmatched-paren>s/berlin/the berlin ones/
<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)
<unmatched-paren>like idk `guix-daemon --split-store1
<unmatched-paren>that might be better than using a slightly unorthodox fs like xfs
<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?
*civodul -> afk
<nckx>rekado: ☝
<nckx>rekado: 10T / + 100T /gnu/store?
<nckx>civodul: o/
<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.
<nckx>OK. That's good.
<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>maybe once in two months or so
<rekado>but it could happen with little advance notice, and I don’t want to deal with downtime any more.
<rekado>we *have* multipathd
<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 doesn’t know
<unmatched-paren>jorge[m]: the boot partition?
<unmatched-paren>it's FATsomethingsomething
<rekado>on Friday we should be able to have the SAN hooked up to another node — maybe 130?
<unmatched-paren>but the rest is ext4 by default
<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
<apteryx>seems a task for xelatex
<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>is this the source? downloading from
<apteryx>texlive-texmf-20210325 3.24GiB
<nckx>No :(
<apteryx>seems the bug "41602 important texlive-texmf is actually subtitutable" is still open
***bandali_ is now known as bandali
<nckx>Also, scary.
***tox is now known as littleme
<nckx>podiki[m]: Can you build Wayland with ?
*nckx can't.
<podiki[m]>let me try...
*nckx → spaghetti.
<podiki[m]>I must have built it before, it just grafted now; but I'm with mesa 22.1.1
<podiki[m]>let me try building from scratch
<podiki[m]>nckx: yes, it built; let me paste you my current patch version (which might be nearly final anyway)
<podiki[m]>nckx: here's my working diff (I'm building on master, in case that makes a difference)
<justkdng>is it possible to not install bloat from %desktop-services ?
<justkdng>I'd like to use sway instead of gnome
<unmatched-paren>justkdng: you can remove the gnome-related services, one moment
<podiki[m]>you don't have to use %desktop-services either, you can create your own service list, or start from %base-services
<unmatched-paren>and you can just remove the gnome-service-type from that list
<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>justkdng: gnome-service-type isn't a member of desktop-services :)
<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
<unmatched-paren>justkdng: in the manual, another moment...
<justkdng>for example, which service sets XDG_RUNTIME_DIR ?
<justkdng>guix home and sway need it
<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>ty for the dots
<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?
<podiki[m]>demo to try:
<justkdng>is editing scheme code with vim considered heresy? :)
<unmatched-paren>justkdng: that's what i do...
<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>There are the occasional --heretics-- outliers.
<unmatched-paren>But for the most part, yes.
<podiki[m]>there are heretics among us
<roptat[m]>I do that too :)
<vagrantc>there are even secular users of emacs
<unmatched-paren>roptat[m], podiki[m]: you know any good paredit-like plugins for vim?
*civodul abhors churches
<unmatched-paren>ah, just found something
<podiki[m]>I'm an emacs user! :-)
<unmatched-paren>podiki[m]: oh, i thought you were commenting on yourself :)
<podiki[m]>possibly related to the u2f issue I have, this was never merged ...
<podiki[m]>unmatched-paren: no worries! i'm a heretic in many other things I am sure
<justkdng>what is paredit?
<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
<rekado>justkdng: you may find this useful:
<unmatched-paren>i've found another imitation that hopefully will work better...
<justkdng>what are 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)
<podiki[m]>all the (...) parens
<podiki[m]>(to be simple about it)
<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 `#~...`.
<justkdng>and that transfers to guile
<unmatched-paren>justkdng: yeah.
<unmatched-paren>but even reader macros get translated to sexprs
<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.
<nckx>So yes.
<unmatched-paren>the two major dialects of Lisp are Common Lisp (occasionally just referred to as Lisp) and Scheme
<unmatched-paren>there is vim-parinfer, but last time i tried it it messed up files
<unmatched-paren>s/files/the formatting of existing files/
<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
<unmatched-paren>moved sexps to all kinds of bizarre places
<nckx>Bizarre no less.
<nckx>So it wasn't just clobbering the guix-specific rules in that file?
<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>s/well/well for you/
<roptat[m]>great, thanks
<civodul>apteryx: weird, i'll take a look
<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
<justkdng>or should that be in guix home
<unmatched-paren>justkdng: i've heard you can just manually launch it in sway/config
<unmatched-paren>but i think we eventually will have a guix home service for it
<apteryx>civodul: thanks
<podiki[m]>u2f problem fixed, doing what others have done `(udev-rules-service 'u2f libu2f-host #:groups '("plugdev"))` in my config
<podiki[m]>odd that I didn't need that before
<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 [...]
<unmatched-paren>roptat[m]: vim-sexp seems to work well so far :)
<podiki[m]> needs a minor update and otherwise looks good to me, since libu2f is deprecated we should make sure libfido2 is in good shape
<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>We wouldn't.
<unmatched-paren>...until it doesn't.
<nckx>I think we currently do use raid1, the least worst, but yes.
<lechner>please run btrfs on top of mdadm
<nckx>No, I don't think so.
<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
<nckx>How even Dhall?
<lechner>it was before i discovered Guile
<nckx>Oh, that long :)
<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
<civodul>apteryx: this patch allows me to obtain a different failure:
<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>podiki[m] believe me, I have tried again and again to use it :)
<podiki[m]>true, it is a special kind of beast
<unmatched-paren>I dislike almost everything about it _except_ the superb lisp support
<mekeor[m]>is rust edition 2021 available in guix?
<unmatched-paren>mekeor[m]: i think so. what version was it added again?
<unmatched-paren>mekeor[m]: yeah, we have 1.57, and 2021 was added in 1.56
<unmatched-paren>(although we really should update it to 1.61...)
<lechner>nckx: maybe this helps with your decision
<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
<maximed>(so no executable bit)
<nckx>Yes and no.
<lechner>it's part of mount
<nckx>They don't, hence a default (‘fake’ above) mode is applied by Linux to fill in the missing information.
<nckx>lechner: What is?
<nckx>Without any extra arguments, FAT is mounted with all files -rwxr-xr-x by default.
<justkdng>ohhh, I think I now what the issue is
<justkdng>the shebang
<justkdng>#!/bin/bash doesn't exist right?
<nckx>You tell us.
<nckx>Not by default.
<justkdng>so how could I use the shebang?
<nckx>#!/usr/bin/env bash
<lechner>#!/bin/sh ?
<nckx>Not Guix-specific, bestest practice anywhere.
<nckx>lechner: More Guix-specific and won't work everywhere, I think.
<justkdng>ohhh, now it works
<justkdng>ty nckx
<nckx>We got there together in the end.
<nckx>The real mode mask was the shebangs we made along the way.
*nckx → ice cream.
<justkdng>haha, elogind has refused
<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?
<unmatched-paren>Guile clearly gives special treatment to its fellow Schemes :)
<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 (@@ ...)
<lechner>Christoph[m]: for one, we should be on this page. i believe haskellers will come here freely
<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: ^
<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>What kind of config?
<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/"))` 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
<unmatched-paren>kennyballou: you have (guix gexp) imported, right?
<lechner>Christoph[m]: i meant the selection screen in GHCup
<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
<kennyballou>unmatched-paren: here's the output from `guix home build`:
<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
<maximed>(TBC: #~ and #$ and #+ are G-exps)
<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>basically, replace #$ by ,
<maximed>(that's literally a ',', not punctuation)
<kennyballou>maximed: Before, slurm-drmaa was not adding 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?
<kennyballou>maximed: s/.guix-home/.guix-profile/
<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
<apteryx>or $TEX
<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 to ~/....’?
<kennyballou>maximed: oh cool, there it is. I must have missed the updated man page, thank you!
<maximed>kennyballou: What man page?
<maximed>Guix doesn't have documentation in man pages.
<unmatched-paren>*sadly :)
<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
<unmatched-paren>nckx: \o/
<unmatched-paren>well, it seems to work. i'll send a patch now, i guess :)
<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>pretty much just here, far as i know :)
<vagrantc>Christoph[m]: feel free to ask questions and we'll try to answer them :)
<Christoph[m]>vagrantc: Thank you!
***mark__ is now known as mjw
<Christoph[m]>Is there anyone here to take lechner by the hand? :-)
<unmatched-paren>i could :)
<unmatched-paren>usual disclaimer that i'm not generally a trustworthy source of information.
<justkdng>yeah just spam your questions
<justkdng>I've been doing that for a while
<justkdng>even got kicked ;P
<maximed>justkdng: The issue was not asking questions, but not using something like 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: Here's the patchset, once it arrives :)
<unmatched-paren>sneek: botsnack (extra large)
<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.
<sneek>Will do.
<unmatched-paren>sneek: botsnack (enourmous)
<unmatched-paren>how would i subscribe to the guix-patches and bug-guix mls?
<maximed>Does someone know why the Apple Public Source License is in guix/licenses.scm?
<unmatched-paren>and guix-devel probably
<unmatched-paren>or whatever it was called
<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.
<unmatched-paren>seems to be counted as free
<lechner>apple can sue anyone 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?
<unmatched-paren>i'm sure they have enough patents to sue anyone in the US, yeah.
<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’
<unmatched-paren>hmm. maybe you could bring it up with <>?
<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
<efraim>eigen FTBFS on riscv64
<lechner>vagrantc: thanks! my hope was for "automatic"
<jpoiret>lechner: there isn't
<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
<unmatched-paren>lechner: cron
<lechner>doesn't it have to run in the user profiles, as well, in order to be effective?
<unmatched-paren>lechner: pretty sure you can run mcron as a home service
<lechner>no, i mean that disk space is a system-wide concern
<lechner>can the admin do it for a user?
<unmatched-paren>lechner: in _all_ the user profiles, you mean?
<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
<vagrantc>one way to find out!
<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?
<unmatched-paren>mekeor[m]: you can't, i'm afraid, unless you package it
<unmatched-paren>rustup doesn't work on guix or nix
<efraim>you can use `guix package --list-profiles` as root to see all the profiles
<lechner>efraim: everyone's profiles?
*vagrantc has doubts
<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
<unmatched-paren>lechner: if you want to keep some packages, you can add a gcroot
<efraim>lechner: yep, I have 2, vs the 169 across everyone on that system
<unmatched-paren>i think
<vagrantc>or yeah, a gcroot
<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
<lechner>efraim: thanks!
<lechner>vagrantc: thanks!
<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.
<lechner>What does the word "drop" mean here, please? (It does not apply to me, as I use SD)
<maximed>lechner: WDYM with SD?
<maximed>lechner: It means that the build process isn't run as root but as guixbuildN.
<maximed>SD = SystemD?
<lechner>maximed: sorry, old terminology
<lechner>just Guix System
<maximed>It is relevant on Guix System.
<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?
<lechner>'drop' means delete, as in sql?
<unmatched-paren>maximed: decided not to :)
<maximed>lechner: No. As I wrote previously:
<maximed>lechner: It means that the build process isn't run as root but as guixbuildN.
<maximed>unmatched-paren: ok
*maximed afk in #guix
*maximed -> #fsfe
<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?
<maximed>* lechner
<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>mekeor: Set RUSTC_BOOTSTRAP=1.
<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
<unmatched-paren>*add pkg-config to native-inputs
<unmatched-paren>oh, maybe you won't need pkg-config, only rust-pkg-config
<lechner>maximed: thanks! Guix docs do not always do well with search engines, but i love the hyperlinks here
<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>yeah, i know but i am spoiled
<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
<unmatched-paren>actually, you've reminded me to fix it :)
<unmatched-paren>lechner: iirc
<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 videos.
<unmatched-paren>yeah, i have sound.
<lechner>do you use desktop services or ask for sound there separately?
<lechner>isn't eww the emacs browser?
<unmatched-paren>lechner: eww is the emacs browser, but it's hardly suitable for most modern websites, right?
<nikola_>Pretty much
<unmatched-paren>nyxt uses webkit or something
<unmatched-paren>lechner: i use desktop-services, but i don't need to explicitly ask for sound
<tinybronca[m]>emacs-webkit is a thing, no?
<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)
<unmatched-paren>i'm just using pulse i think
<jackhill>er, qute
<efraim>I used jitsi in qutebrowser last week
<unmatched-paren>nope, i don't have any pipewires running
<lechner>bdju: ^
<bdju>what's happening?
<lechner>they have sound
<unmatched-paren>in qute
<bdju>ah good to know
<unmatched-paren>without pipewire
<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?
<lechner>ice cubes
<unmatched-paren>industrial freezer
<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
<mekeor[m]>so yes, i should probably clean the fan :)
<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
<mekeor[m]>bdju: what does undervolting mean?
<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
<mekeor[m]>efraim: good tip :)
<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
<mekeor[m]>ukraine-russia-war seems off-topic to me
<nckx>lechner: Fixed, thanks:
<sneek>Welcome back nckx, you have 2 messages!
<sneek>nckx, unmatched-paren says: Here's the patchset, once it arrives :)
<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.
<lechner>nckx: thanks for taking a look!
<unmatched-paren>nckx: do you have commit access to push those patches?
<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.
<unmatched-paren>nckx: well, i ran `dub build` on and it worked
<unmatched-paren>(actually `dub build --root=lit/tangle`)
*nckx has now actually clicked the issue link.
<nckx>OK, I thought this was a change to the -build-system.
<unmatched-paren>it's basically like cargo for d.
<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.
<unmatched-paren>so, as i said, i might have broken it :)
<nckx>And it's not like anyone was using the broken package. 🤷
*civodul sends v2 of the Home ssh service:
<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
<unmatched-paren>but it was broken too, so it shouldn't be a problem
<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
<unmatched-paren>seems like it's linking wrong
<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>seems like pinfo v0.6.13 is very old
<unmatched-paren>should we update it, even if it means using a commit instead of a tag?
<lechner>unmatched-paren: where are the sources?
<unmatched-paren>latest commit 2021-11-19, v0.6.13 is from 2019-02-16
<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
<apteryx>but the entries changed
***tex_milan1 is now known as tex_milan
<rekado>civodul apteryx what kind of tex problems do you have?
<rekado>something I can help you with?
<apteryx>civodul: I think I could make it work at least as good as the full texlive with this GUIX_TEXMF addition:
<apteryx>rekado: I was trying to restore doc/build.scm using a more minimal texlive
<unmatched-paren>oh, huh, info has --vi-keys
<unmatched-paren>suddenly i don't hate it anymore :)
<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
<rekado>I filed it away as “solved”
*apteryx checks the ToC for missing chars
<lechner>unmatched-paren: i woule drop one of the 'extern int use_manual;' declarations in either datatypes.h or parse_config.h. both files are included everywhere via common_includes.h
<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?
<rekado>are there any errors?
<apteryx>looks like no:
<unmatched-paren>i've fixed pinfo now :)
<apteryx>the german is also having problems, already:
<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/ ==> Fatal error occurred, no output PDF file produced!
<apteryx>after printing /gnu/store/q6h5r9an5znqd8mxsyzqcqiq3v4wp7dc-texinfo-manual-source/ TeX capacity exceeded, sorry [input stack size=5000]
<unmatched-paren>are there any other easy issues i could have a go at?
<unmatched-paren>this issue could be closed, right?
<unmatched-paren>this one too...?
<rekado>apteryx: texlive-base propagates texlive-bin. Is that not enough?
<rekado>oh, a stack overflow…?
<unmatched-paren>also, could someone please merge the pinfo fix here <>?
<apteryx>rekado: it's not enough unfortunately
<unmatched-paren>this one may be closable too?
<apteryx>apparently there's this for processing handling texinfo authored in cyrillic
<apteryx>rekado civodul I pushed the fix as 1cde647cc0; thanks!