IRC channel logs

2021-07-02.log

back to list of logs

<jonsger>zap: which arm board do you have?
<zap>odroid xu4
<vagrantc>zap: cross-compiling has some recurring bugs now and again, but it "should" work for some things
<na2th>what should I do when guix build simply hangs for a long time?
<na2th>I am trying to run "guix build xpdf -v 3" and nothing happens
<na2th>at first I thought it was my computer that was not too impressive, but I am now having the same issue in a considerably better machine
<nckx>na2th: Is it realy hung? No I/O, no CPU usage, no other visible (network) activity? What's its last output?
<na2th>nckx: htop shows me 16 processes, just one which is using CPU
<nckx>Rather a lot hinges on what that process is.
<nckx>And, if it's Guix, what it's building.
<na2th>and the only output is a warning that the source file gnu/packages/tex.scm is newer than its compiled version
<na2th>all the processes are from Guix
<na2th>I have no idea what it is doing
<na2th>all of them say the same thing
<na2th>and are simply running guix/scripts/guix build
<zap>seems like building libgcrypt requires special handling for some triplets
<na2th>if I use --debug, I see a lot of "acquiring write lock on `/var/guix/temproots/12345`"
<na2th>and "downgrading to read lock on `/var/guix/temproots/12345`"
<na2th>is guix master broken, and should I work on top of the last release?
<nckx>na2th: It should certainly not be broken.
<nckx>I'm not sure whether it's frozen or busy.
*nckx has never used --debug.
<na2th>nckx: well, me neither. Guix has idk 16 processes, one using 100% of a CPU, all the other ones idle
<nckx>Passing --debug=3 to an otherwise successful guix build just broke it with a backtrace.
<na2th>now it aborted!
*nckx not super impressed
<na2th>nckx: well that sucks lol
<na2th>I am less excited about my build aborting
<na2th>it says "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS"
<nckx>‘guix build xpdf --{no-grafts,check,debug=3}’ == reliable broken times. Can anyone else reproduce?
<nckx>OK, that (and with that knowledge, the long silence you experienced before) sounds like a circular module reference causing Guix to eventually run out of memory.
<nckx>How much ram & swap do you have, and which commit are you on?
<nckx>Is this a pulled Guix or a local checkout?
<na2th>local checkout; after failing to build on my 8Gb machine went to a server with 64gb
<nckx>Oh, <warning that the source file> so I gather the latter.
<nckx>Have you made any changes?
<na2th>I added xpdf as a dependency to texlive-bin
<na2th>cuz that looked necessary
<na2th>so
<na2th>you are telling me that maybe xpdf uses texlive-bin
<nckx>I suspect that introduces a circular reference somehow. You mean (inputs `(("xpdf" ,xpdf) …))?
<na2th>and this is why I broke things?
<nckx>It can be more subtle.
<nckx>Unfortunately.
<na2th>lemme remove the xpdf dependency from texlive-bin and see if things work at least for xpdf
*nckx adds it.
<na2th>yes, I added it as input to texlive-bin, precisely in this way
*zap going to zz goodnight guix
<nckx>Good night zap.
<nckx>na2th: OK, it is not more subtle ☺ guix graph --path xpdf texlive-bin
<nckx>→ shows that it does cause a straightforward cyclic input loop.
<nckx>Read each newline as ‘has as input’, or ‘requires’, or whatever.
<na2th>and sure enough, removing the xpdf dependency from texlibe-bin made things work for xpdf
<na2th>how to fix that? should I have two texlive-bin?
<na2th>one without xpdf and one with?
<nckx>‘Guix freezing is the error message for cyclic inputs’ is a known wart. Low priority but would be nice to fix.
<nckx>That's one option, yes.
<na2th>the current code for texlive-bin does seems odd to me, to be honest
<nckx>The ideal spot to ‘break’ the chain depends on the nature of their dependency, which you know better than I do.
<na2th>because it says it requires xpdf, but it does not use it as input
<nckx>Oh?
<nckx>--with-system-xpdf?
<na2th>yes
*vagrantc wonders what texlive is doing that specifically needs xpdf
<na2th>I just added xpdf as input because when I told it to build, it complained it could not find xpdf
<nckx>--with-system-foo usually means only ‘don't use the bundled foo’, which could fall back to autodetection, although xpdf seems like a very odd thing to bundle.
<nckx>Wait, texlive-bin is broken on master and says it needs xpdf?
<nckx>Is this what you are saying??
*nckx wtfs.
<PotentialUser-71>About Xen in the Gui, I couldn't find the documentation and manuals yet, but I found an interesting Github page, if someone is interested here: https://github.com/glisze/xen-0-guix
<nckx>Interesting, PotentialUser-71!
<nckx>OK, so guix build texlive-bin works fine, phew.
<vagrantc>xen-0-boot ... sounds like a bootstrap toolcain :)
<nckx>So <when I told it to build, it complained it could not find xpdf> means told it to build a TeX document?
<na2th>nckx: no. texlive-bin has a --with-system-xpdf, so when I bumped the version and it told me it could not find xpdf, I simply added it as input
<nckx>Bah.
<nckx>They probably ‘fixed’ the ‘--with-system-xpdf without xpdf is not fatal’ behaviour that we were relying on.
<nckx>You'll have to convince the build system to tolerate it again, because I'm not sure that whatever it wants xpdf for it's important enough to warrant a bootstrap xpdf or texlive-bin.
<nckx>s/it's/is
<nckx>/
<na2th>I will look closely into the patches present before I changed the texversion I downloaded
<nckx>Or maybe they added a --{without,disable}-xpdf option…
<PotentialUser-71>vagrantc: This is true, because by default, after installing xen, it runs together with the kernel in grub, but this does not happen in guix, so the main task is to start xen, and then it becomes the main one. I don't know how the system works after launch, I'll check it now
<vagrantc>haven't used xen since i was running servers without kvm support...
<na2th>nckx: Lemme just understand what you are saying: I should look into why texlive-bin needs xpdf and try to remove this dependency
<nckx>‘needs’, but yes.
<nckx>It was fine not finding xpdf before, the chance that someone changed the build system to be more rigid seems greater than that it suddenly grew a legitimate need for xpdf.
<nckx>I mean, come on, xpdf.
<nckx>That's going to be some hard-coded fallback for ‘the default PDF viewer’, no? Just a guess though.
<na2th>nckx: that makes sense; also, perhaps my assumption that "well, 2 years laters I can simply assume the patches were incorporated" was too strong
<na2th>nckx: by the way, thank you!
<nckx>For what, exactly? ☺ But whatever it was: you're welcome.
<vagrantc>hrm. oom_reaper: reaped process 30220 (gawk), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB ... no linux-libre guix tarball for me!
<na2th>nckx: lol, for teaching me that "hang = cyclic dependency", for helping me understand the issue and pointing me at possible solutions
<nckx>na2th: OK, so I couldn't help myself (I really tried) and fetched the texlive-20190410 sources. The help text for --system-xpdf is actually: use installed poppler headers and library instead of xpdf library from TL
<nckx>So maybe it's a very misleading/historical option name, and it's failing to find poppler instead? Just an idea.
<na2th>nice, so that means that the dependency was broken before
<na2th>perhaps, but I just found something that does not seem too good on the release notes of texlive
<nckx>na2th: No problem, that's what I'm here for.
<na2th>Source: poppler support removed, as it was too hard to keep in sync with upstream. In native TL, pdfTeX has always used libs/xpdf, which is cut-down and adapted code from xpdf.
<nckx>Oh dear. Yeah, I was just looking up what ‘TL xpdf’ meant.
<na2th> https://tug.org/texlive/doc/texlive-en/texlive-en.html#x1-880009.2
<nckx>So, the only supported option is to use the bundled code. I think that's OK.
<na2th>I still do not understand what they mean by TL
<nckx>TexLive?
*nckx is not a TeXer.
<nckx>It's just so… huge.
<na2th>well, that looks like a great guess
<nckx>So, my guess is that you'll have to add xpdf to the whitelist in the snippet, maybe remove that suspiciously named poppler patch above it, and remove the --system option…
<nckx>Guesses because I don't want to get sucked in, even though I've just dipped my toes in :)
*nckx rm -rfs texlive.
<na2th>I have already removed the poppler patches
<na2th>what do you mean by whitelist?
<nckx>preserved-directories
<nckx>I thought I saw xpdf in libs/, which that code aggressively prunes.
<nckx>Thought because I don't want to get sucked in, even though I've just dipped my feet in :)
<na2th>nckx: OH you are looking at the script
<na2th>I was looking for whitelist or preserved-directories at the manpages
<na2th>lemme see if things work out
<na2th>nckx: while things build, how did you find out what --with-system-xpdf meant? You donwloaded the code and looked around ./configure?
<nckx>Yes.
<nckx>I ran ‘guix build texlive-bin --source’, extracted it and just ran its ./configure --help, although I did look at the code later to see what it actually meant.
<na2th>nckx: nice, it caught my attention that you looked into the file before I could even download the tar.gz
<na2th>so, I got an error, but it is about LuaTex. I am happy about it, as it is something further down the road
<na2th>it seems that removing Poppler and using the bundled xpdf in libs just worked
<nckx>Er, I'm a fast typist, I guess? Dunno :)
<nckx>Didn't happen here, but guix build --source has the advantage that it will simply print the store item without redownloading anything if Guix has previously fetched it.
<na2th>that sounds pretty good, as I usually start working by using guix download to obtain the shas
<nckx>If the only upstream-supported way to build is using a modified bundled subset of xpdf, well, it's not the best design but it's acceptable for Guix. Try hard to unbundle things, but don't let it drive you made.
<nckx>*mad
<na2th>nckx: don't worry, of all things, it is not Guix or TeX that will drive me mad
<na2th>politics and academia would sure get there first; some would say they have even done that already
<na2th>jokes aside, that makes sense. I will first see if I can build it at all, and then see how to improve it
<nckx>Academic politics or politics-politics?
<na2th>well, politic-politics, but academic politics already got into my skin a few times
<na2th>My plan for tomorrow is to disable lua-jit and see if I can compile things, and perhaps do similar things for other problems
*nckx was in political-sciences academia for a while which's why they asked.
<na2th>then I can look back and better appreciate which things are critical
<nckx>na2th: Sounds like a plan!
<nckx>I'll see how you fared later; AFK a while.
<PotentialUser-71>In general, xen still works very poorly with guix, and at least for my purposes, that is, creating an analog of qubes os based on guix is difficult, since qubes has a lot of its own developments, for example, redirecting usb to a virtual machine from an isolated virtual machine for usb, in fact, starting this idea will have to re-write qubes, altho
<PotentialUser-71>ugh its source code is open, it will have to be adapted for guix and for shepherd, and this is already incredibly difficult. I will use the usual qemu/kvm :(
<na2th>nckx: nice. Once again, thank you very much!
<The_tubular>Will nmap be deleted of the official repos ?
<nckx>No.
<The_tubular>I'm confused about what is going to happen with it, as it is now "non-FOSS"
<nckx>Not really; it's merely pedantry from ‘FOSS’ people; it will probably get resolved; and only applies to newer versions than the one in Guix anyway.
<nckx>If it's not resolved, we'll just keep shipping the latest version under the previous hacky licence.
<shoshin>hello #guix! forgive me if this is documented somewhere, but i could not find it. is it possible to run guix on top of MacOS? i'd like to introduce guix to some colleagues but most happen to use non-free OSes as their base.
<The_tubular>Understood nckx, but what if I want the new version myself ?
<The_tubular>Could I inherit it on a channel and check for the latest commit or something like that ?
<nckx>I'm going to update nmap in Guix to the latest version, 7.91, under the same licence as the 7.80 we already have.
<nckx>So just wait a little longer I'd say ☺
<lispmacs[work]>I wonder why webkitgtk throttles my PC so badly? You would think 8 GB of RAM would be plenty to compile anything
<The_tubular>Wait, they change their license back?
<The_tubular>I though the newer license didn't let you use nmap in a buisness without paying or something like this
<nckx>The_tubular: Yes.
<lispmacs[work]>shoshin: I vaguely recall overhearing this discussion before, and there was some problem with licensing of a core system dependency
<lispmacs[work]>Cocoa maybe?
<lispmacs[work]>I can't remember now
<The_tubular>Apparently I have some more reading to do, thanks nckx!
<lispmacs[work]>shoshin: https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00118.html
<shoshin>lispmacs[work]: thank you. thats good enough for a rough answer. i'm thinking of setting up a shared server and/or using a vm
<lispmacs[work]>here is the whole thread: https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00113.html
<shoshin>wow, great :)
<lispmacs[work]>Xcode I think was the issue
<nckx>And (the complete lack of) glibc.
<nckx>I didn't read the links; maybe that was mentioned.
<shoshin>i see. i recall some horrible thing about how glibc was excised from macos
<shoshin>i'm reading right now that there's no usuable port of the gnu c library
***rt is now known as robin
<shoshin>welp. its disappointing, but i intend to find another way to help folks experience guix. i'm merely a beginner myself, but i've found its promise to be very intriguing.
<nckx>The_tubular: nmap 7.91 is a guix pull away. <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1b313032943db85e0d6b8550d02671036f3a5d36>
<The_tubular>Thanks, pulling :)
<The_tubular>I need to learn how to package stuff for guix, there's only 2-3 package missing that is holding me back to take the dive 100%
<nckx>Learning and doing aren't really two separate things you can do in order, IME, so I'd just dive on in whenever you have the time.
<nckx>When it comes to Guix packaging, I mean.
<nckx>Other things in life: please act responsibly.
<pkill9>like nckx said, guix is like surgery in my experience, you can learn it while you do it
<hrnz>lol
***Mysterio- is now known as MysteriousSilver
<mason>The_tubular: If you've only got a couple packages holding you back, there's always GNU Stow for quick fix.
<tpefreedom>Where are the guix system images for ARM?
<The_tubular>I'll have to read up on that
<The_tubular>What is GNU stow in a few words ?
<mason>The_tubular: It's a simple way to manage otherwise unpackaged software so you can install and uninstall it cleanly.
<mason>The_tubular: As an example, you'll have, perhaps, /usr/local/stow and directories in there. The stow package will manage symlinks such that /usr/local looks like it's populated by the things that really live in /usr/local/stow/foo
<mason>The_tubular: https://www.gnu.org/software/stow/
<nckx>tpefreedom: There are no official Guix System images for ARM.
<nckx>By which I don't mean to imply I know of any unofficial ones either.
*The_tubular suspicious
<nckx>What's worked well for me is booting another distribution (I think it was Debian?), installing Guix with guix_install.sh, and running guix system init from there.
<nckx>‘Installing’ to the live system, of course.
<tpefreedom>Guix says guix system supports some arm platforms, but lacks the install images. That is weird.
<nckx>I guess. Maybe the gross hacks used to create a bootable ISO/USB hybrid don't work on ARM. Or maybe there is no reason.
<apteryx>I guess the reason was the lack of ARM compute power for the build farm
<apteryx>this is expected to change
<apteryx>shoshin: welcome!
<lispmacs>nckx: hi, I am trying to fix that issue with guix pull being broken. I ran the repair cmd like you said but in the end just got an error "/gnu/store/ycc8vzg684glrnvmayaa0h0ik4la9si2-guix-26117c6"
<lispmacs>I meant, "error: cannot repair path `/gnu/store/ycc8vzg684glrnvmayaa0h0ik4la9si2-guix-26117c6'"
<lispmacs>I tried doing a guix pull --roll-back, but that doesn't seem to have helped.
<nckx>lispmacs: You need to enable substitutes, if just for that.
<nckx>Otherwise Guix won't download the undamaged store item from ci.guix.
<nckx>(I checked the CI and it's there.)
*raghavgururajan couldn't sleep
<nckx>Welcome 2 da club.
*nckx looks at clockings; 05:30.
<raghavgururajan>xD
<daviid>hello! I don't remember who kindly updated g-golf guix pkg 'last time', but if/when time allows, it would be nice to do so again - I made a few important changes, so g-golf allows and properly handles detailed signal naming convention, updated the connect and connect-after methods api accordingly, among other things, and added two examples
<raghavgururajan>Am thoughts on #49210?
<lispmacs>nckx: I'm just running guix pull
<raghavgururajan>*Any
<lispmacs>`guix pull`
<lispmacs>no --no-substitutes option or anything
<lispmacs>is there a way to delete the old one that is damaged?
<nckx>You can try guix gc -D FILE…
<lispmacs>i was able to delete the file that couldn'
<lispmacs>t be repaired, but that didn't help
<lispmacs>it keeps trying to build module-import-compiled
<lispmacs>and dying because ./gnu/packages/bootstrap.scm is corrupt
<lispmacs>but i'm not sure exactly what file that is in
<daviid>g-golf's examples require gtk-4, i know guix doesn't have gtk-4 yet - that contributors are working on it ... - in the mean time, those who'd like to see what they look like, i've uploaded a short description and a screenshot for each here - https://www.gnu.org/software/g-golf/learn.html
<apteryx>sneek: later tell civodul it seems the commit c5fd1b0bd362f8b8578a76a26a65ba5d00d48992 on master re-implemented what 104151f4f45f4bc3a816e3ad42256452932e0d8d already did on staging. Oops!
<sneek>Got it.
<lispmacs>help!
<lispmacs>maybe I can try to pull a different commit of guix...?
<apteryx>nckx: did you not have too much problems merging the qt stuff on the 13th of April (master -> staging?)
<nckx>lispmacs: Try pulling with other /gnu/store/*/bin/guix.
<nckx>apteryx: Since I'm drawing a blank, I guess not.
<lispmacs>okay
<apteryx>OK!
<lispmacs>I picked a random one, but same error
<apteryx>nckx: I'm looking at these changes; and I'm thorougly confused: https://issues.guix.gnu.org/45784
<lispmacs>build of /gnu/store/x3ss3v86nll4dixzb86wmlwdv63c3rrz-module-import-compiled.drv failed
<apteryx>they appear to be on contained on staging, yet their changes seem to have been reverted
<apteryx>or altered
<nckx>I didn't explicitly resolve any Qt-related conflicts… let's see.
<apteryx>or maybe it is there after all
<apteryx>yeah I think it's OK on staging. And I got confused by comparing with what was in master. Sorry for the noise.
<nckx>I'm not seeing any missing hunks either apteryx.
<apteryx>good! thanks for the sanity check!
<nckx>apteryx: For my own sanity: is e.g. ‘git show b13ef6ee7489b78be7f700489792ea672de13d36’ not a full description of a merge commit?
<nckx>Maybe not, since ‘git show 9dea3f101f252331c049c03f501398a5ec837ba9’ doesn't contain the cups.scm from the commit message. But no, I definitely resolved no Qt-related conflicts lately, I'd remember that.
<apteryx>looks like some inevitable conflict in qt-build-system would have been resolved in favor of c5fd1b0bd36
<apteryx>oh, I think it's because 2214b7b78d34a0e4d574b743dbeb8457356f6cff moved the procedures to another module
<apteryx>and when merging master, we brought those back in
<apteryx>(variants of these) hence, no conflict
<apteryx>the conflict will have to be handled manually. I'll look into it.
<iskarian>quick packaging question: if there is an AUTHORS or PATENTS file, should that be installed just like LICENSE?
<apteryx>I'd say no, since they have no bearing in the GNU FSDG, IIUC.
<iskarian>excellent, thanks
*nckx concurs.
<nckx>soheilkhanalipur: Say something.
*nckx → 😴💤, good day.
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: it seems the commit c5fd1b0bd362f8b8578a76a26a65ba5d00d48992 on master re-implemented what 104151f4f45f4bc3a816e3ad42256452932e0d8d already did on staging. Oops!
<civodul>oops
<civodul>so staging had been idle for 4 months?
<civodul>bye, Matrix :-)
<boeg>If I "guix search" does it search all channels I have configured, or?
<boeg>It must do so, right?
<viivien>boeg, it does for me
<boeg>viivien: i thought so, thank you
<mfg>boeg: yes it does search all channels. there isn't a visual hint as to what package belongs to which channel though. You have to look into the location field to see from which channel it originated and even there it might not be obvious :|
<mfg>would be nice to have a channel: field in guix search output
<ss2>Hello.
<MysteriousSilver>Hello ss2!
<ss2>Matrix' quite busy today.
<ss2>I setup databases to use mariadb, but I can't find the config anywhere? I'm sure it is in the store.
<boeg>mfg: alright thanks
<maximed>ss2: Guix usually generates the configuration for you, and passes it to the daemon with "-c /gnu/store/..../config" or the like (I don't know the option for mariadb)
<sneek>Welcome back maximed, you have 1 message!
<sneek>maximed, civodul says: here's a glibc patch that fixes cross-compilation for me, yay! https://sourceware.org/pipermail/libc-alpha/2021-July/128333.html
<maximed>if you want to change arbitrary things, there's the "extra-content" field
<maximed>I don't know how to find the generated configuration
<maximed>maybe use a tool like "gnome-system-monitor" to see what the command line is?
<ss2>ah, thanks, for the tip to look at the process name. Found it.
<maximed>sneek: later tell civodul: nice! Can it already be applied in guix? Or do you want to wait for confirmation by glibc people first?
<sneek>Will do.
<civodul>maximed: hi! i'd like to wait a bit for their feedback; if it takes too long, we can apply it
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, maximed says: nice! Can it already be applied in guix? Or do you want to wait for confirmation by glibc people first?
<civodul>we have quite a few other things to fix on core-updates in the meantime anyway :-)
<civodul>anyway thanks a lot for your help debugging this yesterday!
<maximed>I should check if that patch also fixes the "i686-linux-gnu" toolchain
<maximed>(& test some other arches, and hurd)
<civodul>maximed: the i686-linux-gnu cross-compilation target is uninteresting IMO :-)
<civodul>it cannot really be "tested" because you could end up running target binaries natively without noticing
<maximed>would be nice if it works though. And cross-compiling from an aarch64- system to x86_64- seems a valid use cas
<maximed>*use case
<civodul>yes, but not a supported one
<civodul>currently, we only "support" cross toolchains from x86_64-linux
<civodul>and only for the triplets listed in (gnu ci)
<civodul>as in, one can try a different combination, but they're on their own
<famubu>Hi. Is it possible to install guix in a computer running ubuntu **without** root?
<civodul>famubu: hi! unfortunately no, the initial installation needs root (after than you don't need it when install things)
<maximed>famubu: Guix has an option to select a different store dir
<civodul>but see https://hpc.guix.info/blog/2017/10/using-guix-without-being-root/
<maximed>./configure --storedir=$HOME/gnu/store --localstatedir=$HOME/gnuvar or something like that
<maximed>(--storedir is incorrect though I think)
<maximed>You won't get substitutes that way though
<civodul>maximed: that's not practical though: you'd have to rebuild everything, and many builds would fail due to file name length limitations
<maximed>If you're careful, storedir=/tmp/store could work. But be aware /tmp is typically world-readable and world-writable
<maximed> /tmp should not be temporary file system then though
<maximed>rather unpractical, I'd think
<famubu>Shucks.. got access to school computer with nothing much in it. Was trying to get other packages without having to build all packages (and their dependencies!) manually...
<famubu>Thanks for the directions, folks.
<civodul>"guix pack -RR" is probably a good approach in such a situation
<apapsch>maximed: hi, you reviewed a patch of mine, thanks (regarding wondershaper). for the follow up can I send patches building on the existing patches or should I send a completely new patch series? For the latter I imagine going through the commits, applying them in a freshly created branch one by one and edit before commit if there was comments
<maximed>I'd send a new patch series as a v2, but send it to the same @debbugs.gnu.org address
<maximed>apapsch: "git rebase -i HEAD^^^" is your friend, where the number of "^^^" is the number of patches in the series
<apapsch>maximed: Great, thanks!
<maximed>make sure the subject of the mail is prefixed: [PATCH v2], so the different versions of the patch series are easily separated
*civodul tries to build core-updates for non-x86_64, now that --system actually works...
<civodul>it's not clear why https://ci.guix.gnu.org/eval/56101 shows failures
<maximed>FAIL: test-fnmatch
<maximed> <https://ci.guix.gnu.org/build/637596/details>
<maximed>for findutils ('/tmp/guix-build-findutils-boot0-4.8.0.drv-0/...')
<zimoun>hi!
<civodul>o/
<MysteriousSilver>\o
<civodul>maximed: oh right
<zimoun>“guix gc -D <item>” is really slow because of the phase “deleting unused links”. Reading the associated bug report <http://issues.guix.gnu.org/issue/24937>, is it possible to simply have an option to turn off this phase?
<zimoun>Especially it would be handy when removing only one item on huge store
***rt is now known as robin
<cbaines>morning o/
<civodul>hey cbaines!
<maximed>hi cbaines
<civodul>zimoun: i think the question is why/when is it useful to remove a single item
<civodul>perhaps we can take a step back and look at the use case
<cbaines>it took longer than I'd have liked, but the Honeycomb LX2 board is finally running Guix and connected to the build coordinator on bayfront
<civodul>yay, neat!
<zimoun>civodul: I do that all the time (remove one item) when I check stuff; for instance playing with SWH fallback
<civodul>i see
<zimoun>in fact, now I run “guix gc -D <item>” …wait…enter in the slow phase and paf! ^C^C
<civodul>heh
<civodul>i686-linux should now be fixed on core-updates, twas a typo
***Kimapr7 is now known as Kimapr
<maximed>from git send-email:
<maximed>(mbox) Adding cc: Maxime Devos <maximedevos@telenet.be> from line 'From: Maxime Devos <maximedevos@telenet.be>'
<maximed>4.1.1 too many mails from <maximedevos@telenet.be>
<maximed>heh
<jonsger>maximed: you need to increase the timeout between sending the mails in chunks
<jonsger>--batch-size= will help you maximed
<zimoun>civodul: and I would like to quickly GC profile without waiting after this phase (that I almost always kill by hand)
<maximed>jonsger: thanks, I'll use that next time
***avoidr_ is now known as avoidr
<mekeor[m]>efraim: you seem to be sophisticated with guix on embedded, arm- or riscv-devices. do you have a recommendation for a cheap single-board computer with at least 8GB memory, being able to run guix system (and thus linux-libre)?
***pie_bnc is now known as pie_
<viivien>Hi, does guix provide https://en.wikipedia.org/wiki/Log_rotation? How can a program invoked in a shepherd service use it?
<maximed>viivien: rottlog-service-type
<mfg>viivien: http://guix.gnu.org/manual/en/html_node/Log-Rotation.html
<mfg>it is enabled by default though :-)
<maximed>but if you write a service, its logs won't be rotated by default.
<viivien>Thank you both. I‘m indeed writing a service, and I’d like to rotate my logs
<maximed>(unless the service tells rottlog-service-type to, with an appropriate service extension)
<viivien>Do you have an example of such service extension?
<maximed>looking at the definition of guix-daemon, it appear to be sufficient to use #:log and extend rottlog-service-type
<viivien>Also, do I need to re-open the port to the log file every time I log something, so that the file can be renamed or deleted?
<viivien>port or file descriptor
<viivien>Or do I need to lock it?
<maximed>this is for a system service, right? THen I don't see what ‘every time I log in’ means here
<viivien>Sorry
<viivien>Every time I write something to the log file
<maximed>I have no idea how rottlog is able to compress & move the logs when the file port is open. Dunno
<viivien>OK I’ll take a look at the manual :)
<maximed>(I still see some rotation happening though in /var/log/...)
***apteryx_ is now known as apteryx
<apteryx>civodul, mothacehe, mbakke, nckx moin'
<apteryx>it's July 2nd, 2 P.M. CEST ;-)
<civodul>apteryx: hey!
*civodul gets ready
<viivien>maximed, rottlog does not say. However, logrotate has an option, "copytruncate", that helps if the port is never closed, but it’s discouraged because you could lose some logs. So, I guess the answer is to re-open the log file each time I need to append a message.
<maximed>viivien: if all that re-opening turns out to be too inefficient, you could re-open, say, every 500 messages
<viivien>That works only the first day, because the file is renamed, but after that the file is compressed and deleted. So, if there are less than 500 messages in a day, I will write to a deleted file.
<viivien>(so, the logs will be lost)
<apapsch>how about time based reopening?
<maximed>viivien: does rottlog have any recommendations on how programs should write to log files?
<maximed>(without losing messages)
<viivien>maximed, I haven’t found any
<viivien>apapsch, I’ll think about it when I have thousands of users :)
<apapsch>viivien: rottlog is modeled after logrotate and they operate very similar. maybe there are advices for logrotate
<apapsch>all this local file based logging and rotating is a hassle though. I was thinking maybe package loki (https://github.com/grafana/loki) to aggregate the logs
<viivien>The general impression I get from the few discussions that duckduckgo has archived is to reopen the file.
<viivien>How guix combines bits of service extensions into a service configuration is still a mystery to me. Like, how does the certbot service know the list of sites defined in the whole configuration so that it can set up automatic redirections?
<viivien>Same for rottlog.
<leoprikler>viivien: extensions
<viivien>There must be some reference cycle in the config, because the service belongs to the config, but the definition of the service depends on the whole configuration.
<viivien>I’m happy that it works :)
<civodul>viivien: https://guix.gnu.org/manual/devel/en/html_node/Defining-Services.html provides an intro to all that
<zimoun>civodul: this “deleting unused links” is really boring. Does it make sense to add an CLI option to skip this part?
<zimoun>it seems the intensive IO locks the machine and sometimes I cannot simply run ^C^C… and then I am grumpy.
<cbaines>I don't think the underlying need for guix gc is entertainment
<viivien>civodul, I must admit I stopped reading at the dot diagram
<cbaines>I would imagine not deleting unused links would often reduce the amount of space freed
<maximed>is there any particular reason BDW-GC is compiled without disclaim procedures? (--enable-disclaim, <gc/gc_disclaim.h>)
<viivien>Yet it makes a lot of sense now
<zimoun>cbaines, for instance I am playing with SWH, and I need to remove only a couple of items and then redo some stuff. The deleting unused phase takes ages. By ages, I mean, removing one item takes me maybe half-hour to complete.
<civodul>zimoun: i sympathize but... i think an option to skip it would be weird
<civodul>it's not an implementation detail one should think about
<cbaines>zimoun, I appreciate the problems, the Guix Build Coordinator has the same issue. When it wants to build something, to ensure it's actually built, it garbage collects the outputs if they're already in the store
<zimoun>and worse, the session hangs and it is hard to do other stuff
<cbaines>which as you say, can be slow
<civodul>cbaines: why does it need to do that?
<cbaines>civodul, it wouldn't be a very good build tool if you asked it to build a derivation 10 times, and it just built it once
<civodul>cbaines: there's --round and --check for that, no?
<zimoun>civodul: I have read all the thread <<http://issues.guix.gnu.org/issue/2493> and it seems improvements are waiting :-)
<cbaines>zimoun, I think the actual needs here are around how the guix-daemon works, like in your case, you want to say build this again and replace the outputs in the store, for example
<civodul>in the case of zimoun it's a bit special because zimoun typically wants to build a *different* derivation, but it's a fixed-output derivation
<civodul>--check cannot be used in that case
<cbaines>civodul, I have thought a little about investigating whether --check could be used to build things that are already in the store, but I'm not confident about how things like the outputs and logs will be handled
<cbaines>maybe I've overestimated how difficult using --check would be though, I haven't looked in to it much
<civodul>cbaines: --check rebuilds something that's already in the store, but it errors out if the result differs
<zimoun>yes
<civodul>also, it overrides the build log in /var/log/guix
<civodul>(we could easily address this)
<roptat>--check also builds twice if the result is not yet in the store
<roptat>but only once if the result is already in the store
<civodul>hmm i think it refuses to do anything if the result is not yet in the store, no?
<civodul>ah no
<civodul>weird
<roptat>I made it work like that, and even found a reproducibility issue on a store item I didn't have yet
<roptat>maybe it's not intended, but that's how it works now :)
<zimoun>well, if an option does not make sense, I can still use ^C^C for the corner cases. But, the bug#24937 <http://issues.guix.gnu.org/issue/24937> should be addressed :-)
<civodul>oh that's a recent change then?
<civodul>i think it used to be different
<zimoun>roptat, no. I do not think so. At least by default.
<leoprikler>when?
<civodul>i agree that bugs in general should be addressed :-)
<roptat>I don't know, last time I tried that was last month
<zimoun>civodul, heh! :-) Especially when it is almost done, as in this case. ;-)
<civodul>i wouldn't say it's almost done, despite several people spending many hours :-/
<civodul>it's sort of a nightmare
<zimoun>civodul, which kind of “sort”? GNU’s one ;-)
<zimoun>(related to the discussion about sorting inodes)
<civodul>heh
<nckx>Morning Guix.
<MysteriousSilver>morning nckx
<nckx>Sorry I couldn't make it to the meeting. I was deep in the middle of nowhere and just got home for lunch.
<nckx>It's 16:00.
*nckx mehs.
<nckx>maximed, apapsch: In case you're unaware, you might be interested in HEAD~26 etc. for larger numbers where counting ^s becomes impractical.
<darth-cheney>Hey all, how can I use packages from a specific channel (described in my own channels.scm) in a system configuration?
<darth-cheney>Currently I use a channel called "flat" to get the native-comp version of emacs, and I'd like to use that in an updated system config I'm making so it's there from the get-go
<apteryx>nckx: no worries! I confused you for Marius, never having seen any of you in person ;-)
<maximed>(1) inferiors, or (2) use "guix pull" on your channels.scm, import (channel module) like usual in system configuration and do "guix system reconfigure" as usual
<darth-cheney>I tried (use-modules (flat packages emacs-native-comp))
<darth-cheney>is that incorrect?
<maximed>If (flat packages emacs-native-comp) is the name of the module, then that's correct.
<maximed>do you have some kind of error message?
<darth-cheney>I guess I'm not sure of two things. (1) Does my channels.scm file somehow automatically get used during a reconfigure, and (2) how to import a package from a channel defined in channels.scm
<darth-cheney>yeah it's just saying unbound variable emacs-native-comp, so it's not fifinding it
<maximed>(1) after the "guix pull", yes
<maximed>It says "unbound variable", and not "non-existent module" or something like that?
<nckx>darth-cheney: Yes to both, but I'm looking at the channel and there's no flat/packages/emacs-native-comp.scm file, which means your import is incorrect.
<nckx>It should be (flat packages emacs).
<darth-cheney>aha
<darth-cheney>it's interesting because if I run --list-packages the only emacs I have installed currently is a package called emacs-native-comp
<darth-cheney>maybe this is just inconsistent naming?
<nckx>Module names aren't package names.
<nckx>They are collections.
<nckx>Like we have a (gnu packages text-editors) module, but no ‘text-editors’ package.
<darth-cheney>aha ok
<nckx>There's a (gnu packages vim) module because vim bribed someone to get its own module, but it's ‘coincidence’.
<nckx>And contains more than just the vim package.
<darth-cheney>nckx yeah exactly, seeing stuff like that was giving me the wrong impression
<nckx>darth-cheney: If you run ‘guix show emacs-native-comp’ you'll see a ‘location’ field. You still need to translate that to (foo bar) syntax but it's the same thing.
<darth-cheney>aha, thanks so much that's the exact command I need
<nckx>apteryx: Rectify that next year?
<PsixisP>Hi, I have a laptop that requires CONFIG_VMD (Intel's software RAID) in order for the kernel to see the internal NVMe drive. This is not present in the default Guix kernel. What would be the procedure to request for it to be added? Thanks.
<darth-cheney>Thanks again nckx, gonna log off and try to reconfigure
<nckx>PsixisP: Asking here is fine, or on the guix-devel at gnu dot org mailing list if nobody responds. Do you know if VMD has any ‘freedom’ problems, such as working only with proprietary software/firmware? Do you know whether other GNU-approved distributions like Trisquel run on this hardware?
<PsixisP>I've looked into this and there don't appear to be any issues. https://cateee.net/lkddb/web-lkddb/VMD.html But I haven't checked wheter Trisquel has support. I will check.
<nckx>Thanks! In the meantime I've downloaded Trisquel's kernel package (by just typing random things on my keyboard, it was not pretty) and they set CONFIG_VMD=m, so I think we're good to go.
<PsixisP>Awesome. Appreciate the quick check. Yes, it's compiled as a module in most of the non-free distributions I've installed.
<apteryx>nckx: I hope so!
<zimoun>civodul, cbaines: for instance, I killed “guix gc -D one-item” after 1h of “deleting unused links”.
<PsixisP>nckx: Should I make a request on guix-devel?
<nckx>PsixisP: No, I'll take care of it.
<PsixisP>nckx: Perfect. Thanks very much.
<nckx>PsixisP: Is this a common requirement? I've never had one, but have wondered before why NVMe's are reportedly so hard to boot from when I'd expect them to just be SCSI block devices. This could explain part of it.
<nckx>‘Sucky Intel RAID.’
<PsixisP>nckx: It's something I've seen in newer Intel 11th gen systems. Lenovo and HP from a brief web search. I would have disabled it in the BIOS if I could.
<nckx>Joy.
<PsixisP>nckx: Indeed
<PsixisP>nckx: But I love the laptop otherwise :)
<nckx>Why? :) (Not that I'm looking for a laptop.)
<nckx>(Or love.)
<PsixisP>Lol, it's got a fantastic 3:2 Oled and keyboard and I got it on the cheap :) And no NVIDIA.
<nckx>Those are all nice things.
<nckx>Thanks!
<PsixisP>nckx: Indeed, but Linux support has been a bit iffy. I'm getting there though. Thanks once again for your help.
<nckx>Almost done.
<maximed>fwiw, I have a laptop with nvme, but I could select between two modes in the BIOS. The non-intel-specific mode worked fine
<nckx>PsixisP: Done. Pull away.
<maximed>though I lost the previous contents of the disk, but I wasn't interested in it anyway
<PsixisP>nckx: Thanks!
<dstolfa>nckx: do you run guix on your laptop? how do you deal with the amount of sheer heat produced during the update?
<dstolfa>i feel like i always get boiled alive
<PsixisP>maximed: Unfortunately HP disabled the option to disable Intel VMD. Else that'd be my first option.
<nckx>It's not that bad, but when I'm actually lappin' (as opposed to bed-side tablin', where most reconfigurations are done) I lower the maximum frequency to 1.8 GHz which means ‘tolerable’ in °C.
<nckx>When I know I'll be reliably connected to the Internet I offload to a VPS, but that's just for speed, not heat.
<nckx>maximed is not reliably connected to the Internet.
*dstolfa wishes he had a VPS to offload things to
<PsixisP>lol
<nckx>PsixisP: Now that you say the H-word, I totally understand. I have never had an HP laptop that wouldn't have been better had it not had the HP treatment :-/
<nckx>It's like their mission is to subtract value.
<dstolfa>dell is much the same
<dstolfa>after i undell'd my dell laptop, it became miles better
<nckx>Possible, no experience.
<nckx>HP burns PCIe whitelists into you BIOS though, no undoing that :-/
<nckx>*r
<dstolfa>ah yes, it's one of those
<dstolfa>lenovo used to do that, but i broke it back in the day and plugged in whatever i wanted :)
<nckx>Same.
<nckx>I guess the problem is that HP is better at it, because nobody ever broke mine 😉
<dstolfa>dell worked around that problem quite easily btw
<dstolfa>they just uh... soldered everything on there
<dstolfa>so even if you want to plug something in, good luck with that
<PsixisP>nckx: I normally go Thinkpad, but I couldn't resist the screen on this one :)
<nckx>Yes, I would have bought an XPS if it wasn't for that.
<dstolfa>nckx: i tolerate it because this is technically a work laptop
<tricon>Did Nvidia ever start contributing to nouveau? They hinted that they would.
<PsixisP>I miss the days when things were upgradeable
<dstolfa>we can just run whatever we want on the laptops
<dstolfa>so i choose to run guix
<nckx>Now I run an 11-year-old thinkpad with 16 GiB of RAM. ‘Oh well.’
<tricon>Yeah.
<nckx>People around me are still buying new ones with less.
<nckx>PsixisP: Let me know if that fixed all your boot problems.
*nckx AFK.
<tricon>My home PC is an Intel i7 2nd gen., my laptop a 2019 Lenovo Flex Ryzen, and my new machine is the PineBook Pro. Hoping I can switch to ARM for all of my main machines, primarily to escape Intel ME and AMD PSP.
<PsixisP>nckx: I'd need to wait for a new boot image to be built right?
<PsixisP>nckx: I mean install image
<nckx>PsixisP: Right… and the installation images are updated only daily :-/
<nckx>Well, the last one was 22h ago, so you're lucky.
<nckx>If you have Guix installed anywhere else you can build you own. There's no upstream magic CI sauce (by design).
<nckx>(Section 3.9, Building the Installation Image)
<PsixisP>nckx: No worries. I'll try later and update you over here. Thanks once again. I could install to an external drive and then 'guix pull' to see if it works. But I would rather wait and do a full install once and for all.
***xgqt_ is now known as xgqt
***niko is now known as o
<cbaines>should static binaries for things like guile depend on glibc?
<civodul>cbaines: they might embed glibc's store file name
<civodul>that's why for the initrd and bootstrap binaries we call remove-store-references
<civodul>comrades, i posted the draft of a web page listing active branches and their status! https://issues.guix.gnu.org/49334
<cbaines>for some reason, building static guile on powerpc seems to produce a non-static binary https://paste.debian.net/plain/1203159
<civodul>indeed, that looks very non-static
<civodul>it actually works on other arches, right?
<civodul>then we'd need to check the powerpc build log
<cbaines>yeah, seems to on x86_64-linux
<cbaines>I'm not sure if I'm using the exact same revision
<cbaines>I'm rebuilding it now, and will see what that yields
<bricewge>Hey Guix!
<bricewge>Does one of you managed to configure a local DNS resolver with Conditional Forwarding ?
<podiki[m]>Hi guix-ers! I've been in and out of the room by various names the last week or so, but here for good
<podiki[m]>!help
<podiki[m]>Hi guix-ers! I've been in and out of the room by various names the last week or so, but here for good
<podiki[m]>(sorry for the multiple messages, looks like the Matrix bridge was slow)
<Noisytoot>!help doesn't do anything
<Noisytoot>I don't think there are any bots in here other than bayfront-log
<podiki[m]>irfus: I had no problem building your updated mesa from the patch, thanks! And I think previous versions of mesa also had different builds (you can see via guix challenge that the 2 current substitutes don't match)
<podiki[m]><Noisytoot "!help doesn't do anything"> got it. was just the connection hadn't fully joined, so I was in some limbo. seems all good now
<irfus>podiki[m]: ah, that's good to know :)
<sneek>irfus, you have 1 message!
<sneek>irfus, podiki[m] says: I had no problems with Mesa build, thanks! previous builds of mesa also don't match each other (see guix challenge for current substitutes), and I also had non-matching builds with your version on same and different machines
<podiki[m]>so I think the patch looks good to me at least. I'll try building more things with the newer mesa and trying it out
<podiki[m]>Is there any list of known packages with non-deterministic builds? or is it just checking via challenge or manual build rounds?
<irfus>I went ahead and mailed the patch. Hopefully didn't f-up the format.
<podiki[m]>nice! and I even applied the patch on the main branch, with minimal changes, also worked fine
<Noisytoot>and sneek
<DynastyMic>Hi, I'm trying to make my first guix package, by packaging the protege ontology editor
<DynastyMic>However, I want to know wheter I should package the JRE included version or the so called "platform independent" version
<DynastyMic>which one is the "Guix way"
<leoprikler>the Guix way is packaging whichever causes the lower effort :P
<leoprikler>and there's much effort to be had with packages of that size
<leoprikler>IIRC one was Java and the other also Java right?
<DynastyMic>the platform independent version requires a Java Runtime Environment
<DynastyMic>the standard version already has a JRE included in it
<leoprikler>then the "platform independent" version it is
<DynastyMic>thank you!
<DynastyMic>i'll reach the channel if i get stuck
<DynastyMic>so, see you in 5 minutes
<leoprikler>heh
<leoprikler>if you want to know my reasoning: having a jre is a lower requirement than unbundling one :P
<DynastyMic>If i push the package to guix, should i name it as "...-platform-independent-version"?
<nckx>‘Unbundle things’ in an implicit requirement in Guix. Otherwise, it would be extremely ‘low effort’ to package random crap 😉
<nckx>DynastyMic: Hell now.
<nckx>*no, even.
<nckx>Just ‘protege’.
<leoprikler>nah, if "platform independant" means "the only reasonable" as in this case, you don't need to distinguish at all 😉️
<nckx>Which reminds me of ‘virtuoso-ose’, but maybe there's a reason for that name.
<DynastyMic>all right, I'm new to guix and lisp, so sorry for the noob questions
<nckx>Questions are good.
<DynastyMic>right, then theres another one
<DynastyMic>is fetching from git preferable?
<DynastyMic>specifically github
<leoprikler>if upstream has a release website that doesn't just publish auto-generated tarballs, no
<leoprikler>but normally yes
<leoprikler>especially if you can point to tags
<DynastyMic>I think they actually reference to a github release on their download page
<DynastyMic>so github it is.
<nckx>The auto-generated tarballs leoprikler's talking about are these on GitHub: https://github.com/protegeproject/protege/releases/tag/v5.5.0
<nckx>‘Source Code (tar.gz)’, linking to an /archive/ URL.
<nckx>They are not stabel.
<nckx>*le, ffs.
<nckx>Some projects use the GitHub releases page to publish proper static tarballs that they generated themselves in addition to these. You can use them, but git-fetch is just as fine.
*nckx wonders if ‘guix install protégé’ would work…
<leoprikler>you mean given the accents or what would be the problem?
<nckx>Yeah.
<nckx>Don't care; just curious.
<DynastyMic>i guess it would be a PITA for people to download it
<DynastyMic>even though they could just copy-paste it
<leoprikler>hmm, it might work given it's still latin1, but guix install プロテジェ probably wouldn't – then again, idk if guix restricts us to just ascii or latin1 or actually gives us full utf8 permissions
<DynastyMic>idc
<DynastyMic>idk*
<DynastyMic>so, since I'm fetching it on this url: https://github.com/protegeproject/protege-distribution/releases/download/v5.5.0/Protege-5.5.0-platform-independent.zip
<DynastyMic>I should just use the url-fetch method
<DynastyMic>rather than the git-fetch
*nckx guix installs ッ
<nckx>DynastyMic: That's up to you. Note that ‘unzip’ isn't a default implicit input. It's been so long since I've dealt with a .zip that I don't remember whether it's enough to add it as a native-input, or whether you also need to replace the 'unpack phase to invoke it.
<nckx>In that sense, using ‘git-fetch’ is less work, and may also be closer to working with upstream's version of the code.
<DynastyMic>right
<DynastyMic>i go to go eat, brb
<Noisytoot>What are url-fetch's default implicit inputs?
<apteryx>I don't get how dpkg decides to fire triggers or not
<zacchae[m]>What's GUIX's journalctl equivalent?
<nckx>cat
<nckx>Specifically, cat /var/log/{messages,whatever}
<zacchae[m]>thx
<nckx>DynastyMic: It does invoke "unzip" automatically, so adding it to native-inputs should suffice.
<nckx>Noisytoot: It doesn't really have any, nor does it handle unpacking by default (unless you apply patches; then the hacky patch-and-repack code kicks in).
<nckx>Unpacking is done by the build system which uses whatever implicit inputs are availabe. Hence the oddity that gnu-build-system will invoke either "tar" or "unzip" based on file name extension, but tar will just work whilst unzip won't by default.
<zacchae[m]>nckx: Oh wow, there are a lot of logs there. I want to investigate my EXWM crashing, any tips on which log to look at in there? I launch it through gdm, but the gdm log dir is empty
<nckx>I'm afraid (1) the logging situation rather sucks: not everything is logged (2) exwm/gdm might log anywhere including nowhere or $HOME (3) I don't use GDM so can't help you further.
<zacchae[m]>thanks again
<civodul>leoprikler: store file names are ASCII-only, but we could/should fix that
<civodul>then package names could be Unicode even store file names are ASCII
<civodul>food for thought :-)
<nckx>And remove the restriction on dotfiles? ☺
<civodul>oh you can't have dots either?
<nckx>Weird eh.
<nckx>‘Disallow names starting with a dot for possible security reasons (e.g., "." and "..").’
<nckx>I mean
<nckx>OK.
<nckx>We have the technology to compare strings, I'd say.
*nckx got bit by this when interning .config. It's not urgent, but since we're discussing packages called 💩 now it seemed like the right time to bring it up.
<civodul>nckx: yeah, that comment is weird
<nckx>Like, what'm I missing here…
<civodul>weird thing is that slash is okay
*nckx wonders what this code looks like today but isn't going to check out Nix to check.
<civodul>it no longer exists!
<civodul>uh
<Noisytoot>nckx: What is "💩"? it's a box on my computer
<Noisytoot>Can you have newlines/tabs/spaces in store file names?
<civodul>nope
<nckx>Noisytoot: Don't open the box. https://www.tobias.gr/thanks.jpg
<bricewge>Where is the equivalent to /etc/default/keyboard ?
<mroh>bricewge: to configure the keyboard see: https://guix.gnu.org/manual/en/guix.html#Keyboard-Layout
<nckx>If that doesn't address your question, it helps if you describe what you're trying to do, not ‘what's the Guix equivalent to $some_obscure_feature’.
<bricewge>mroh: Thank you, I know. I'm wondering what piece of guix code replace that feature
<nckx>What feature?
<bricewge>/etc/default/keyboard if that's is a "feature"
<bricewge>Stepping back
<nckx>What does /etc/default/keyboard do?
<nckx>Yes.
<bricewge>I have a keyboard for which XkbOptions aren't applied to
<bricewge>Another keyboard does get this option applied to the Xorg instance
<bricewge>I'm trying to debug that
<bricewge>I'm not sure it's a Guix issue or a keyboard firmware issue
<bricewge>Here is my keyboard configuration for X https://paste.debian.net/1203182/
<nckx>/etc/default/keyboard is a Debian thing, right? How would you configure Debian to debug this?
<bricewge>And there a log of X https://paste.debian.net/1203183/ with the "good" keyboard Luddite and the "bad" keyboard m60
<nckx>Have you used keyboard-layout instead of that X snippet?
<nckx>s/X/Xorg.conf/
<bricewge>nckx: Yes that's the generated xorg.conf bu Guix
<nckx>Gotcha.
<bricewge>s/bu/by/
<nckx>Hm, ZMK Project m60 Keyboard: Applying InputClass "evdev keyboard catchall"
<nckx>bricewge: If you run the equivalent ‘setxkbmap […] -options "lv3:ralt_switch,caps:hyper"’ command manually using the m60, does it work?
<bricewge>Yes
<mroh>bricewge: maybe try something like '(keyboard-layout "us" "altgr-intl" #:options '("lv3:ralt_switch" "caps:hyper"))' in your operating-system conf.
<nckx>bricewge: What does you Guix keyboard-layout field actually look like? Specifically the #:options field.
<nckx>Option "XkbLayout" "us" Option "XkbVariant" "altgr-intl" Option "XkbOptions" "lv3:ralt_switch,caps:hyper"
<bricewge> https://paste.debian.net/1203185/
<nckx>bricewge: Is that correct? Shouldn't those be muliple Option lines?
<bricewge>mroh: That's what I'm doing
<nckx>Yes that is correct.
<bricewge>nckx: I wondered too, but the code from civodul looks like that fromat was the wanted output
<bricewge>s/too/to/
<nckx>Which code from civodul?
<bricewge>The code generating that file
<nckx>Problem is, I don't even seem to have an Xorg.conf anywhere in my store any more.
<bricewge>Note that this configuration work fine with my other keyboard (Luddite)
<bricewge>(gnu services xorg) around line 230
<bricewge>For the code I was talking about
<southerntofu>hello, is there a tutorial on how to get started packaging a rust program, for a complete guix newbie? :)
<stikonas>I'm not aware of the tutorial but there are definitely examples in guix code
<southerntofu>i've started to manually guix import crate --recursive dependencies i find in Cargo.toml, not sure if that's the best way to start?
<stikonas>e.g. exa
<nckx>bricewge: Yeah, that's probably not the problem then, it's just surprising.
<southerntofu>thanks i'll take a look
<leoprikler>yall be thinking about unicode package names, but have you considered unicode hashes?
<Exa>stikonas: yes exa is nice
<stikonas>username checks out
*nckx has kicked leoprikler from #guix (🔫)
<nckx>bricewge: So I do have an xserver.conf (not xorg.conf) and it looks very similar to yours. Unfortunately I don't have a USB keyboard to test.
<southerntofu>ok so from what i can see #:features() inside arguments is how to pass feature requests to cargo
<southerntofu>i didn't see it in the Build Systems manual page https://guix.gnu.org/manual/en/html_node/Build-Systems.html
<nckx>I don't know why my X server is happy to chat about the xkb_options it found whilst yours doesn't: https://paste.debian.net/plainh/6ce9203a
<bricewge>nckx: Which display manager are you using?
<southerntofu>i don't see a CLI flag like '--features' so that means i'll have to do the recursive imports for the featured-gated dependencies myself?
<nckx>bricewge: Sway.
<nckx>So this is a legacy XWayland server.
<bricewge>I'm starting to wonder if it's bug in the Lightdm service patch https://issues.guix.gnu.org/35305
<nckx>Oh, possible! I use sddm.
<nckx>You could try that to rule out a bug lightdm.
<bricewge>I'll try sddm then
<nckx>🤞
<Noisytoot>Why does only sddm support wayland on guix?
***raspbeguy is now known as guy
***guy is now known as raspbeguy
<nckx>Doesn't GDM?
<dstolfa>nckx: nope
<dstolfa>sddm is the only one
<dstolfa>(i don't know why)
<Noisytoot>GDM does on other distributions, but not on Guix
<nckx>Haha.
<nckx>I'm going with standard answer #2: ‘probably because nobody has done the work to make it do so.’
<nckx>GDM is also quite buggy and actively resists debugging, so there's that.
<Noisytoot>Why is it the default then?
<Noisytoot>(for GNOME)
<Noisytoot>and Xfce
<nckx>Doesn't it run just fine, just not Wayland? Wayland is also not the default.
<dstolfa>nckx: -ish
<Noisytoot>It does, but you said it is quite buggy
<nckx>Or if you mean ‘…if it's so unpleasant to maintain’: because it's still what most users expect, I guess.
<dstolfa>i'd say gdm runs mostly alright, until you try to suspend one too many times
<dstolfa>then it runs very poorly
<nckx>I really don't know; this wasn't officially decided in a meeting. I didn't even know it was the default.
<nckx>Well, I knew it, but I wouldn't have bet €50 on that knowledge.
<nckx>dstolfa: You're not the first to report that…
<nckx>
<dstolfa>nckx: it has nothing to do with guix i think, though
<dstolfa>i've experienced this on other distros and laptops
<dstolfa>for example, gdm will show up, but the keyboard will just not work in it for a good 10 seconds
<Noisytoot>I think I also had similar issues on Guix and Debian with GDM
*nckx heartily recommends the use-LUKS-and-set-sddm-to-autologin-so-you-don't-even-know-what-it-looks-like-TBH ‘DM’.
<nckx>Don't need a DM to lock your screen.
<nckx>Speaking somewhat of which: does anyone use LUKS2 with Guix System yet?
<jab>nckx: is LUKS2 an encryption standard?
<jab>Is it related to LVM? I'm guessing no.
<nckx>A header standard.
<nckx>No.
<nckx>Sometimes used together but not related.
<bricewge>nckx: sddm don't fix my issue unfortunatly, and it doesn't add additional info to the log as yours
<nckx>Well, s/header/tooling/ standard really.
<nckx>bricewge: Are these both pluggable keyboards? Does the m60 never work whether its first or second to be plugged in at start?
<jab>nckx: I actually don't use SSDM. I just set up mingetty to auto login...but because I don't really know what I am doing I have it auto login to all my consoles...I need to fix that. :)
<bricewge>Both pluggable. It always work, but the option aren't applied until the second one (Luddite) is plugged in
<nckx>o_O
<bricewge>Exactly!
<Noisytoot>I don't use LUKS2 because libreboot from 2016's GRUB is too old to support it
<nckx>bricewge: So going back to your starting question: what would you do with /etc/keyboard that you think might help here? Maybe there's a way to do so in Guix.
<bricewge>I just noticed the debug port on the bad in active, will' try disabling it
<nckx>Okido.
<nckx>Because I don't really have any ideas, sorry ☺
<stikonas>even latest GRUB does not properly support LUKS2. It now understands the header but only works with LUKS1 hashes, doesn't work with default LUKS2 hash
<nckx>Latest being 2.06.
<nckx>OK, that's what I wanted to know, thanks.
<nckx>stikonas: So my comment ‘GRUB 2.06 supports LUKS2, but does it reliably support all set-ups…?’ isn't too cautious, as I'd hoped, but in fact barely cautious enough. Pity.
<stikonas>yeah, GRUB 2.06 also broke my self-signed secure boot... Had to disable it
<maximed>is there any particular reason BDW-GC is compiled without disclaim procedures? (--enable-disclaim, <gc/gc_disclaim.h>)/quit
<maximed>nevermind