<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 :)
<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_>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.
<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)
<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]>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)
<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.
***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.
<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.
<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)
<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?
<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)
<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
<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.
<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.
<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>(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?
<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.
<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?
<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
<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.
<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