IRC channel logs

2023-09-26.log

back to list of logs

<rekado>I just built a system image with ‘guix system image -t qcow2’, but I cannot actually boot the system
<rekado>I use the command mentioned in the Guix manual
<rekado>the system configuration is the same as the lightweight desktop template, but with a few packages added.
<rekado>it’s stuck at ‘Booting from Hard Disk…’
<rekado>the image at https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2 works
<rekado>same results with an unchanged doc/os-config-lightweight-desktop.texi from the guix repo
<rekado>(I also cannot overhear the fan spinning at full speed while it’s stuck at ‘Booting from Hard Disk’)
<rekado>does anyone know what’s up with ‘guix system image -t qcow2’?
<rekado>I’m on Guix 273709932fa47f6ae56c96564a9415fdbff4a169.
<PotentialUser-47>Hey there, i am making minor changes to my home config ( i believe i called `guix pull` as well) and wish to see results however webkitgtk is now being rebuilt despite being already installed.
<PotentialUser-47>Would this be because a new version has released?
<PotentialUser-47>if not nescessarily then is there a method of telling the system to not rebuild?
<PotentialUser-47>if this is definitely due to a new version being released then is there a method of `pinning` a package at a specific version until i am ready to rebuild?
<PotentialUser-47>( version of webkitgtk)
<jackhill>janneke: maybe. I'd have to look at the build scripts more closely, especially since they're hand-spun and not using autotools or anything. I have come across other software where DESTDIR definitly seemed like the right option. e.g. https://git.hcoop.net/jackhill/guix/guix.git/blob/0561e5761e1cf74cbe64c8170f8f4ee22b36c7da:/gnu/packages/afs.scm#l52
<sneek>jackhill, you have 2 messages!
<sneek>jackhill, antipode says: about CC=gcc: that hypothetical linter stopped being hypothetical a month ago: https://issues.guix.gnu.org/65426! Though perhaps CC=gcc was used in a place the new linter can't detect yet.
<sneek>jackhill, antipode says: Also, that DESTDIR and PREFIX need to be swapped (see: staged installations)
<jackhill>sneek: later tell antipode thanks! I actually hadn't run the linter on it since I thought there was enough to work on for a first pass. I'll have to check!
<sneek>Will do.
<jackhill>will definitly have to update my knowledge for PREFIX adn DESTDIR. with my kafs package I definitely tested it and DESTDIR looked like it produced better paths. rpath maybe. It's been a while
<euouae>hi
<avalos>I added ~/.guix-home/profile/lib to LD_LIBRARY_PATH, and I could get the binary to link to libgcc_s.so.1, which I feel should have happened automatically, but it didn't.
<avalos>Now, ldd shows all libraries as linked, but whenever I run the binary, bash keeps saying "No such file or directory."
<avalos>Why would bash refuse to run a binary?
<avalos>It is set as executable.
<avalenn>avalos: what executable are you trying to run ?
<euouae>I get that error when I try to run 32-bit apps in a 64-bit installation e.g.
<euouae>(not guix specific) but that bash error can be misleading like that. I think it's referring to the runtime library
<avalos>avalenn: Android Studio.
<avalos>s/Studio/SDK.
<avalos>I can't run the built-in Android Studio SDK binaries.
<avalos>euouae: how do I install 32-bit libraries in Guix?
<ulfvonbelow>has anyone else managed to get curl's --ciphers option to work at all? It seems to be having no effect whatsoever here.
<euouae>avalos, check with the `file` command, what's the result on the binary?
<euouae>ulfvonbelow: how so?
<avalos>euouae: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, stripped
<avalos>I found the problem. The interpreter for the binary is `/lib64/ld-linux-x86_64.so.2`, whereas in Guix, it is installed under `/lib/ld-linux-x86_64.so.2`, so it can't find it.
<ulfvonbelow>euouae: e.g. `curl --verbose -tls-max 1.2 --ciphers 'TLS_AES_256_GCM_SHA384' https://www.howsmyssl.com/a/check' gives a list of 29 ciphers where presumably only one should be given
<ulfvonbelow>(wireshark also confirms this)
<avalos>If I do `~/.guix-home/profile/lib/ld-linux-x86-64.so.2 ~/Android/Sdk/emulator/emulator`, the binary runs successfully.
<avalos>I need to symlink lib to lib64, but how do I do that in a Guixy way?
<euouae>avalos: the android SDK is not installed as a guix package, right?
<avalos>No, it's the one that Android Studio installs.
<euouae>android studio is nto a guix package, right?
<avalos>No, it's a Flatpak package.
<avalos>There's no Guix package that I'm aware of.
<avalos>The SDK is not part of the package; it is downloaded and installed by Android Studio on runtime.
<euouae>ulfvonbelow: I get a 301 error with that command
<euouae>avalos: you might be able to patch the interp with <https://github.com/NixOS/patchelf>
<avalos>It's just so complicated. https://github.com/shegeley/gundroid
<avalos>Indeed, it is necessary to patchelf stuff, but it's also necessary to do a lot more, and I already spent the whole day fighting with Guix, so I might as well just run it on a VM.
<avalos>(run Android Studio on a VM)
<avalos>And why do packages get redownloaded every time I run `guix home`? Aaaah.
<euouae>no the question is, why do you want to run android studio on guix?
<avalos>Because I'm an Android developer, and I need Android development in my laptop.
<avalos>Otherwise I wouldn't bother.
<euouae>Of course, but do you need the reproducibility features of guix for your android development?
<avalos>Are you talking about the system or the package manager?
<euouae>either
<avalos>I just wanted to try Guix in my laptop, not only for Android development, but for everything I would need my laptop for.
<avalos>I would go back to Parabola, but I just thought using Guix for my normal stuff would be easier.
<avalos>Than it is turning out to.
<euouae>well, you are venturing outside of the guix packages world
<euouae>properly android studio needs to be packaged by some maintainer, starting point is <https://android.googlesource.com/platform/manifest>
<avalos>Android Studio itself works fine, it's just the SDK what's giving me headaches.
<jackhill>avalos: you might be interested in the --emulate-fhs option to `guix shell`?
<jackhill>would of course be nice if the studio and SDK were easier to package for Guix of course!
<avalos>I need to get familiar with `guix shell` first, lol, noob pro max here.
<jackhill>sorry I should help more, but got other things pulling at my attention, but I did want to make you aware that it possible to create an environment where things are in the more expected places. Not sure about lib v. lib64 in particular though
<avalos>It's okay, I'll make sure to check out that possibility, as well as the hundreds of others that Guix has to offer, but it will take me time.
<jackhill>indeed. Welcome and enjoy your journey!
<avalos>Thanks. :D
<RavenJoad>Could someone take a look at #64778? It has been sitting around for a while now.
<euouae>RavenJoad: this? <https://issues.guix.gnu.org/64778>
<RavenJoad>euouae: Yes, that is the one.
<euouae>OK, I'm not related to guix but I was wondering if I understood you correctly
<RavenJoad>Yeah. It was a small set I submitted because someone else wanted wally-cli available.
<lilyp>thanks
<sneek>Welcome back lilyp, you have 1 message!
<sneek>lilyp, antipode says: I read your p.s. about the state of antioxidation. AFAICT the latest work is <https://issues.guix.gnu.org/64904>, but the actual patches don't appear to have been sent.
<avalos>In guix home, what determines whether packages are redownloaded or not?
<avalos>If I run `guix gc`, will existing packages be redownloaded in the next home reconfigure?
<janneke>avalos: as you have probably experienced, an unbounded guix gc (in space or time) will almost certainly remove dependencies necessary to re-create any installed profile, such as source tarballs
<janneke>guix home creates a profile in ~/.guix-home, afaik there's nothing special about it as compared to other ways of creating profiles
<efraim>hello guix!
<janneke>o/
<attila_lendvai>is there a place where people's guix channels are collected? if not, why?
<jpoiret>attila_lendvai: there's https://toys.whereis.みんな/
<attila_lendvai>thanks jpoiret! i'll look into adding my channel... but first:
<avalos>janneke: does a guix pull also delete everything?
<attila_lendvai>if i was to move away from github with my channel, is there a consensus which one is preferred? is it sr.ht?
<jpoiret>of course not, it's up to you
<attila_lendvai>hrm, my channel is already there, but the package i picked to search for was not found
<rekado>has anyone been able to build a VM image with ‘guix system image -t qcow2’ recently?
<rekado>I’ve built a new VM image with the lightweight desktop template and the very latest Guix and it too is stuck at ‘Booting from Hard Disk’
<rekado>interestingly, the bare-bones template does boot. Must be the EFI bootloader then.
<efraim>could it be related to the mbr-hybrid-raw change?
<rekado>I opened bug 66207 to keep track of it
<adanska>hi guys, is anyone having trouble building mutter when they reconfigure>
<adanska>?
<adanska>I just spend my entire day recovering my guix system, since im using some other channels i had to go and build my own install iso so i could boot into my install (running 6.4.16), and since mutter wasnt building i had to adhoc change my system to use xfce haha
<adanska>it was so odd, i didnt even do a reconfigure and my grub just broke. really weird and unfortunate. lost a whole day working on fixing it
<efraim>adanska: which commit are you on that mutter won't build? on x86-64?
<adanska>yeah, lastest commit
<adanska>*latest
<adanska>x86
<efraim>I had a couple of packages which didn't like the high load when rebuilding, I'll see if mutter builds successfully
<adanska>it was failing on a test, and i was chrooted into a broken system. could easily be that the environment was strange, but thought i should ask since guix weather was showing mutter not avaliable
<adanska>it looks like its working on an operational guix install, must have been some issue with being in a chrooted system. sorry to waste your time efraim :) thanks for looking for me anyway
<adanska>do all emacs versions packaged on guix use native comp now ?
<rekado>In a Guix generated VM with the %desktop-services I cannot login via GDM
<rekado>login on the console works fine
<rekado>there doesn’t seem to be anything interesting in /var/log/gdm/greeter.log
<efraim>adanska: glad to hear it worked out for you :)
<adanska>thanks :)
<adanska>has been a tumultuous day for me i must say
<adanska>reviving a linux install is always stressful but with guix you're on your own
<rekado>yikes, gnome-shell is crashing (because of a segfault in colord)
<adanska>the bleeding edge has its consequences haha
<rekado>gnome-shell also prints a warning: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
<efraim>I've been manually creating packages with glibc-hwcaps directories, I bet I could reuse a bunch of guix/transformations to accept '--tune=glibc-hwcaps' to produce the packages for me
<efraim>rekado: with current gnome or with a newer version?
<civodul>i see those memfd_create warnings with QEMU, too
<efraim>or it might be better to add a property like tuned-for or reuse cpu-tuning to have the package autotune for a psABI
<ekaitz>apteryx: did you push the changes to guix?
<ekaitz>apteryx: I mean those related with arm
<ekaitz>i think I can't pull because of them
<ekaitz>but I think to review further
<blablabla>hi
<blablabla>thx for the Emacs release
<blablabla>it's great
<blablabla>i mean just look at the release note
<blablabla>it's huge
<blablabla>long lines displaying doesn't hang anymore WOW it's christmas
<mrvdb>hi guix, I noticed this morning on updating that the avr-toolchain package is no longer available. It's not clear to me how to resolve that. Any hints?
<civodul>mrvdb: hi! it’s still available, but not at the command line: https://issues.guix.gnu.org/66063
<civodul>it’s a suboptimal situation for sure
<civodul>were you used to running ‘guix shell avr-toolchain’ or similar?
<rekado>efraim: with current gnome. I’m using the latest Guix commit on the master branch.
<rekado>civodul: okay, so the memfd_create warnings might not be the cause for the eventual crash then.
<mrvdb>civodul: it was in some of my manifests, seems i need (make-avr-toolchain) as replacement
<rekado>(it’s also in my home config’s manifest)
<rekado>oh, there’s an old bug report for my VM problem: https://issues.guix.gnu.org/29934
<civodul>mrvdb: yes, exactly
<civodul>feel free to chime in in the bug above if you feel something should be improved
<ekaitz>apteryx: forget my previous message I just fixed everything, it was my channel that was using the previous arm thingie
<rekado>I think the reason for the segfault is that I didn’t add gnome-desktop-service-type to the services
<rekado>it’s obvious that it can’t launch gnome when there is no gnome, but the failure mode is … disappointing.
<civodul>yeah indeed
<civodul>i wonder how we could improve on that
<civodul>in a way it sounds more like a GNOME issue
<rekado>yeah, it does
<civodul>but OTOH we’re doing things GNOME isn’t prepared for
<rekado>but it’s also obviously *not* a gnome issue because it’s absent :)
<rekado>exactly
<civodul>like it’s not supposed to be possible to have GDM without GNOME i guess
<rekado>I suppose the assumption with gdm and gnome is that things have been set up exactly right by the distro.
<rekado>and every deviation is a distro problem
<civodul>yeah
<efraim>141.80.167.171 is out of space, I'm clearing some up
<rekado>I wonder why gdm allows for login at all when there’s no available desktop
<rekado>efraim: thanks
<rekado>did the gc cron job not clean up enough space…?
<efraim>not sure, it says its at 100% full
<efraim>i'll check the logs in a second
<mrvdb>civodul: for this particular situation I just missed some "upgrade info" and had to dive into the scheme file itself to see what had changed. A note on the commit would already have helped.
<civodul>mrvdb: maybe we should add a news entry; WDYT, apteryx?
<nckx>I had to 'manually' gc multiple berlin build nodes last week. I noted it here but don't have the bandwidth to investigate (in hospital).
<nckx>(That sounds dramatic; I'm fine.)
<nckx>So whatever was scheduled has clearly broken.
<civodul>uh
<nckx>?
<civodul>nckx: it’s sign of surprise and discomfort (both for non-working GC and for your situation)
<civodul>a terse one
<mekeor>nckx: get well soon!
<mekeor>i hope the garbage in the hospital is collected well.
<nckx>Oh, I'm very sorry, I didn't mean to add discomfort to your surprise.
<nckx>I didn't mean to over-share either, just point out I wasn't faking my excuse for not fixing it :-p
<nckx>Thanks mekeor.
<nckx>Oh, the bot's back.
<lechner>hospital?
<nckx>hawaiian-bun: Did you enjoy the ISO?
<lechner>she said yes
<lechner>i hope you are fixing some equipment (that's not your own) in the hospital
<lechner>Hi, is Proba the only SRFI-64 test runner we have?
<hawaiian-bun>"SRFI 64: A Scheme API for test suites" https://srfi.schemers.org/srfi-64/srfi-64.html
<lechner>Also, in the context of Guix when is it appropriate to use --no-auto-compile in Guile scripts as part of the pound-pling (aka the hashbang) please?
<mekeor>ACTION is currently experimenting with (setq geiser-guile-binary (list geiser-guile-binary "--no-auto-compile")) in emacs
<lechner>Hi, is the current Git HEAD in good condition?
<mirai>lechner: if you're talking about the guix reconfigure error of something something commit, yes
<civodul>mirai: that one was fixed yesterday though, no?
<mirai>yea
<nckx>What was the story there? That sounded like a 'fun' one.
<nckx>lechner: I don't expect an answer, but since people sometimes miss PMs: I sent one.
<civodul>nckx: recent changes in (guix git)
<mekeor>is it just me or does installing any emacs-package-package with --with-input=emacs-minimal=emacs-next not work (since the merge of emacs-team branch)?
<mekeor>(failure regarding native-compilation)
<nckx>OK, that's actually reassuring, that it was a code change.
<lechner>mirai / yeah, i worry about errors small and big. thanks!
<lechner>Hi, as a project do we care about testing via SRFI-64 versus TAP? Is the latter more universal?
<hawaiian-bun>"SRFI 64: A Scheme API for test suites" https://srfi.schemers.org/srfi-64/srfi-64.html
<tylerm>anyone have a package for caddy? Ive tried packaging it myself but it doesnt compile.
<sevan>Hi, Is there any chance the patches to bring gnutls, openssl, openssl3 up to date can be merged? https://issues.guix.gnu.org/66195 https://issues.guix.gnu.org/66197 https://issues.guix.gnu.org/66198
<amoxicillin>"[PATCH] gnu: gnutls: Replace with 3.8.1." https://issues.guix.gnu.org/66195
<amoxicillin>"[PATCH] gnu: openssl-1.1: replace with 1.1.1w." https://issues.guix.gnu.org/66197
<amoxicillin>"[PATCH] gnu: openssl-3.0: replace with 3.1.3." https://issues.guix.gnu.org/66198
<mekeor>ACTION feels annoyed by the bots
<avalenn>hello
<mekeor>hi avalenn! :)
<zimoun>mirai, lechner: do you still observe an error about Git with “guix system reconfigure”? It should be fixed so if there is an error, it means I have still missed a corner case. :-)
<Altadil>Well, I do get a different error for guix system reconfigure today :)
<Altadil>guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.
<Altadil>That seems to be something else entirely ?
<lechner>zimoun / thanks for asking! my concern actually goes beyond simple errors. i think the development HEAD is generally unsuitable for a large proportion of our intended users. in a declarative system only one package has to fail to build for an upgrade to fail
<civodul>sevan: it would be good yes; i hope one of the committers can take a look soon
<zimoun>Altadil, yes different. This error is not yet my business. ;-)
<zimoun>lechner: yeah, well some “stable” Guix is a recurrent topic :-)
<Altadil>zimoun: ok, thanks. ^.^
<lechner>Hi, should we propagate all inputs in a 'guix shell"? I think it might simply development
<lechner>simplify
<efraim>there's now a manifest.scm in the root directory of the guix tree, so `guix shell -m manifest.scm` should give you what you need
<efraim>assuming that's what you meant
<lechner>i meant for any list of packages on the command line
<efraim>so it'd be the equivelant of `guix shell foo -D foo`?
<efraim>there's also guix environment, where `guix shell -D foo` would be the equivalent of `guix environment foo`
<efraim>I don't remember if we're deprecating guix environment though
<avalenn>efraim: `guix shell -D foo` have sometimes missing inputs, I don't know why
<mekeor>any example?
<avalenn>I should minimally reproduce this to understand it better.
<avalenn>mekeor: cannot reproduce, I may have dreamt it
<avalenn>The Manual states clearly that `guix environment` is deprecated https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-environment
<amoxicillin>"GNU Guix Reference Manual" https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-environment
<civodul>we’re past 1st May 2023 BTW :-)
<avalenn>whate is the proper way to do `date > my/file` in Guile. I tried `(with-output-to-file "my/file" (system* "date"))` but it does not work
<mekeor>ACTION is buffled by a "guix gc" of 138GB
<efraim>you're missing a lambda
<efraim>try something like: (lambda _ (system* "date"))
<efraim>although IIRC there's a date function in guile
<mekeor>fyi, there's also #guile channel :)
<avalenn>it is not for date, it is for capturing the output of a Go program used to generate code
<efraim>srfi-19 has lots of date options https://www.gnu.org/software/guile/manual/html_node/SRFI_002d19-Date.html
<amoxicillin>"SRFI-19 Date (Guile Reference Manual)" https://www.gnu.org/software/guile/manual/html_node/SRFI_002d19-Date.html
<amoxicillin>"SRFI 19: Time Data Types and Procedures" https://srfi.schemers.org/srfi-19/srfi-19.html
<efraim>you could do (with-output-to-file "my/file" (invoke "go-program"))
<avalenn>efraim: I tried that at first but I see the output on stdout. Will check my syntax.
<avalenn>mekeor: I should go to #guile, they would explain me what is a "thunk" because I still don't have it
<bjc>a thunk is just a lambda that takes no arguments
<bjc>it's primarily used to delay evaluation
<efraim>looks like I forgot the lambda
<efraim>avalenn: check out the doctl package in gnu/packages/admin, it uses with-output-to-file to generate the shell completions
<mekeor>(with-output-to-string (lambda () (system* "date"))) ;; evaluates to "" for me
<avalenn>with the lambda it works, thanks efraim and mekeor
<minima>sneek: later tell antipode thanks for link to the `make authenticate' bug report!
<sneek>Got it.
<apteryx>our mesa doesn't have a libvulkan.so.1 library (it has gpu specific named ones), is this exected?
<apteryx>expected*
<apteryx>instead it has libvulkan_intel.so or libvulkan_radeon.so
<apteryx>I'd like if these implementations were abstracted through a libvulkan.so.1
<apteryx>ah, libvulkan.so.1 comes from the vulkan-loader package
<apteryx>oh, 'guix locate libvulkan.so.1' would have told me so
<apteryx>neat
<apteryx>civodul: a news entry could be useful I guess; or do we have a means to express a package was turned into a procedure in our deprecation toolkit?
<civodul>apteryx: maybe we could define an “avr-toolchain” package with ‘trivial-build-system’ just doing (mkdir #$output), propagating all the relevant inputs, and marked as superseded (?)
<civodul>ACTION thinks out loud
<civodul>no we can’t mark it as superseded because there’s no replacement
<civodul>but the rest of the plan should work
<mirai>zimoun: nope, just did a guix pull + reconf on both home & system
<mirai>no problems here
<apteryx>civodul: I think we can also mark something as deprecated with no replacement
<apteryx>that's of little more value than outright removing a package though
<apteryx>unless we can attach a useful message
<RavenJoad>Could someone take a look at https://issues.guix.gnu.org/64778? It has been sitting around for a while now.
<amoxicillin>"[PATCH 0/5] Add wally-cli" https://issues.guix.gnu.org/64778
<RavenJoad>I also added a tree-sitter lang in #66206 (but I submitted that last night).
<amoxicillin>"[PATCH] gnu: Add tree-sitter-scala" https://issues.guix.gnu.org/66206
<mirai>what's the purpose of the `file-systems' service?
<shcv>hello, I recently subscribed to the guix-devel mailing list and tried to reply to a message, but it doesn't seem to have worked. Is it waiting for moderator approval, or do messages need to be sent only to the list? (I think my default reply was to the previous sender, CC the list)
<gnucode>hello friends.
<somenickname>What is the purpose between the .guix-profile and .guix-home dir?  I installed a package with guix home and thought the binary would be in .guix-home/bin but it is still in .guix-profile/bin
<zamfofex>shcv: It does require moderator approval, I’m pretty sure. You don’t eed to join the mailing list to submit messages to it either, though.
<zamfofex>somenickname: You can remove it from ‘.guix-profile’ with ‘guix remove’.
<zamfofex>‘guix install’ and ‘guix remove’ (a.k.a. ‘guix package’) operate on ‘.guix-profile’, whereas ‘guix home’ operates on ‘.guix-home’. They work separately.
<somenickname>Ah nvm.  It is in guix-home/profile/bin  just a little different file structure
<zamfofex>Right, you can have packages isntalled to either/both.
<zamfofex>When you use ‘guix package’, it is orthogonal to ‘guix home’. You can use both if you’d like.
<somenickname>Yeah I was just a bit irritated.  Forgot that I installed it manually some time ago for testing.
<avalos>How do I specify the package, let's say `qtwayland@5` on a config file?
<avalos>I can do that using the Guix command, but I don't know how to set it on my home config.
<zamfofex>avalos: ‘specification->package’ ?
<zamfofex>Conversely, you can just use the variable ‘qtwayland-5’.
<avalos>Cool, thanks.
<Guest85>I did this https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html but I have permissions problem
<stethoscope>"[HOWTO] Start X server manually instead of using a login manager" https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html
<Guest85>I also have  systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration although I Set that flag Just Like IT IS done in the ML
<Guest85>IT works now. Missed abwhiteepace...
<attila_lendvai>any hope for applying this patch series that fixes actual, long-standing build failures? https://issues.guix.gnu.org/65037
<stethoscope>"Fix python-daemon, Trezor support" https://issues.guix.gnu.org/65037
<cwebber>hello hello
<cwebber> https://octodon.social/@cwebber/111132437405185343 a tiny guix fanart
<stethoscope>"Christine Lemmer-Webber: "My favorite operating system / distro" - the Octodon" https://octodon.social/@cwebber/111132437405185343
<ieure>Hi cwebber :)
<cwebber>hi!
<hglbrg>Anyone here have experience with dwl-guile? Really struggling with home configuration...
<PotentialUser-47>Just looked for a while through the source looking for how to hash a git clone, just found the `guix hash` flags docs
<PotentialUser-47>hope everyone is well
<somenickname>I want to autologin to tty.  I saw this https://lists.gnu.org/archive/html/help-guix/2018-07/msg00106.html which means I created this https://paste.debian.net/1293184/ but now I get guix system: error: more than one target service of type 'udev'
<stethoscope>"Re: [HOWTO] Start X server manually instead of using a login manager" https://lists.gnu.org/archive/html/help-guix/2018-07/msg00106.html
<stethoscope>"debian Pastezone" https://paste.debian.net/1293184
<intermet>Hi! I manage emacs with guix home. I downgraded emacs from 29 to 28 and I have issues with the native compilation. elc files in my home profile are not compatible with the old version of emacs. How can I clear them out? Thanks!
<nckx>somenickname: I'd use modify-services, if only because there are at least 2 DELETEs and I always forget which one is the one you used here.
<somenickname>intermet: I am not 100% sure but this should be the eln-cache dir
<nckx>intermet: Not trivial. You can't 'clear them', you have to rebuild those packages with the old emacs using transformations.
<somenickname>but for me it is in 28.2 dir so shouldn't it create a  new dir for 29.1?
<bjc>yes. emacs is supposed to have it not just per-version, but per-build
<bjc>28 shouldn't even be looking at 29's eln files
<nckx>(I'm taking your 'in my home profile' at face value, not a cache directory etc.)
<intermet>Thoses files are in .guix-home/profile/share/emacs/site-lisp. I guess both versions of emacs look at this place
<bjc>my eln-cache dir (on guix) has like 15 separate subdirectories for various versions and builds
<bjc>the default eln-cache is in .emacs.d
<somenickname>nckx: Not sure what you mean. https://paste.debian.net/1293185/ this is my complete service definition
<stethoscope>"debian Pastezone" https://paste.debian.net/1293185
<intermet>It is what I tought, not trivial problem. I guess I have to remove the packages and re-install them
<bjc>you can check ‘native-comp-eln-load-path’ for the various cache directories. the first one is where new eln files are written
<mirai>*sigh* Is anyone here using DKIM with opensmtpd or has some SMTP contraption configured that can do DKIM before passing it to the “real” MTA
<bjc>i use opendkim, but that's with postfix. and on freebsd
<PotentialUser-47>somenickname my guess is that %desktop-services and %base-services both contain udev
<nckx>somenickname: Never mind, the original 'modify-services' got cut off my ('phone) screen for some reason. There are 2 'delete' procedures built into Guile. Sorry for the noise.
<PotentialUser-47>or one is derived from udev causing the clash
<nckx>And yes, don't mix 2 service %lists like this. Doesn't make sense.
<nckx>In particular, %desktop implies %base.
<somenickname>ah
<somenickname>because desktop is basically on top of base
<intermet>@bjc My issue comes from elc files
<bjc>ah, ok. those still shouldn't be causing an issue, though. you can delete the ones you're installing by hand, and the ones provided by guix packages shouldn't conflict
<mirai>bjc: can your SMTP setup deliver mail to the others or does it pass on to another SMTP provider for delivery
<bjc>try using ‘M-x toggle-debug-on-error’ and seeing what's causing problems, then just delete that elc and recompile
<somenickname>okay is this better https://paste.debian.net/1293188/? but now I have guix system: error: service 'term-tty1' provided more than once
<stethoscope>"debian Pastezone" https://paste.debian.net/1293188
<bjc>mirai: it delivers and recieves mail itself
<nckx>You're still appending a separate list to a modify-services. Is that necessary? Doesn't modify-services support appending them?
<bjc>modify-services only deletes and modifies
<bjc>you still need ‘cons*’ or ‘append’ or whatever
<nckx>Boo.
<PotentialUser-47>?hey there, is there a faster packaging workflow than:
<PotentialUser-47>\---------------------------------------------------------------------------------------------------------------------/
<PotentialUser-47>no critique on devs if not, just curious if i am missing something as the pull derivation takes a little bit
<PotentialUser-47>well that didnt print correctly
<bjc>nckx: yeah, i agree, but i'm not ready to touch that routine again for a bit =)
<PotentialUser-47>```
<PotentialUser-47>( alter package scheme)--> ( guix pull)--> ( installation attempt)--> < repeat>
<PotentialUser-47>```
<somenickname> https://paste.debian.net/1293189/ okay so like this? Results in same error
<stethoscope>"debian Pastezone" https://paste.debian.net/1293189
<somenickname>PotentialUser-47: This is not Discord :D
<PotentialUser-47>it is general markdown though so thought id try
<PotentialUser-47>:D
<somenickname>and don't paste multiline text or the bot mutes you
<nckx>Plz no Markdown on the Internet.
<bjc>yeah, do it in yaml)
<bjc>!
<nckx>somenickname: Nono, the placement of m-s-t was (probably) fine and certainly not wrong.
<nckx>PotentialUser-47: Just use pre-inst-env, there's no reason to commit or pull at all.
<PotentialUser-47>nckx thanks!
<nckx>When the modified files (warnings) start piling up (because of many edits, or a rebase, etc.), things will slow down, then just run make again.
<nckx>Running make each time for one file doesn't really save time.
<somenickname>That error message could really be more precise.  No clue where that other udev is.
<somenickname>I mean it basically is this https://guix.gnu.org/manual/en/guix.html#auto_002dlogin-to-TTY
<stethoscope>"GNU Guix Reference Manual" https://guix.gnu.org/manual/en/guix.html#auto_002dlogin-to-TTY
<somenickname>though it uses base services
<nckx>(IRC predates Markdown by 16 years.)
<nckx>Ah, 'basically', the silent killer :-(
<nckx>somenickname: Comment out services until it builds? 🤷‍♂️
<nckx>Presumably the culprit is above the mod-serv line.
<somenickname>I think I got it
<somenickname>brb rebooting
<PotentialUser-47>nckx oh i wouldnt have .pre-inst-env as im building in my own repo first
<somenickname>Well, close.  It works and does automatic console login but I get "Error in service module" immediately after and can't use the tty
<somenickname>Also, grub has an entry "OLD generations or something".  But that also includes latest or not?
<somenickname>so it should be more of ALL generations and not old if the latest is included in the list.
<nckx>PotentialUser-47: Then, assuming it is a package, I would temporarily add the package variable name to the bottom of the file and use guix build -f if it's self-contained, or try with guix build -L ~/my-channel my-package (untested example).
<nckx>somenickname: Hence 'old'.
<PotentialUser-47>thank you
<somenickname> https://paste.debian.net/1293190/ this is my current config.  Basically I removed the (tty "tty1") thing since I want auto login for all consoles anyways.  It reconfigures but as I said.  It shows console auto login and I get the hello gnu system but after that error in service module and can't do anything
<stethoscope>"debian Pastezone" https://paste.debian.net/1293190
<somenickname>nckx: But if my current gen is 15, and I go to old gens and it lists 15, this doesn't make sense to me since 15 is current and not old
<nckx>It shouldn't list 15.
<somenickname>nckx: It shoud list everything before 15
<nckx>somenickname: Can you capture any more error output? Is there any?
<nckx>somenickname: Yes.
<somenickname>nckx: Okay good.  I need to verify that.  Since it seems it is not how it should.
<somenickname>nckx: No that is all I got from the TTY (only some deblobbled msg) and I can't use the tty
<somenickname>nckx: Also how is the status of that BTRFS thing with the daemon.  Did you found out why it happens?
<nckx>Like you, I don't remember my GRUB menu by heart, but I'm pretty sure I remember an old discussion 'old' was chosen deliberately. Guix generally takes naming seriously.
<nckx>somenickname: I haven't even touched a computer since we last spoke :)
<nckx>No... these... things are not computers 💀
<nckx>somenickname: Can you reproduce this in a vm?
<somenickname>nckx: Yeah I guess I need to check again.  Maybe I am just highly confused.  But will do tomorrow.
<nckx>If it is wrong, thanks for reporting.
<somenickname>nckx: I don't know.  I will check tomorrow and report back to you.  Going offline.  Bye everyone and thanks for the help
<nckx>OK, just s/reconfigure/vm/. Bye!
<PotentialUser-47>bye
<somenickname>nckx: Couldn't resist running that one simple cmd.  Yes it is the same behavior in the vm running guix system vm system.scm
<nckx>OK, if you share your full configuration I should be able to reproduce it (not today) and maybe debug it, but even if not it speeds up your debugging.
<nckx>Now go have fun without computers, it is the best. o/
<somenickname>nckx: https://paste.debian.net/1293191/
<stethoscope>"debian Pastezone" https://paste.debian.net/1293191
<somenickname>Now for real though, bye :D
<lechner>mirai / Hi, some systems use 'network-file-systems in addition to regular 'file-systems, i think
<mirai>'network-file-systems exists?
<sharlatan>Hi
<Kabouik>Any idea what could be the error here? https://0x0.st/HVee.txt
<sharlatan>Emacs can' be built
<cbaines>I presume it's a problem with the https://github.com/babariviere/guix-emacs channel Kabouik
<band-aid>"GitHub - babariviere/guix-emacs: Guix channel for automatically generated emacs packages." https://github.com/babariviere/guix-emacs
<Kabouik>Thanks cbaines, I'll try disabling it then
<sharlatan>What do you think about this patch set? https://issues.guix.gnu.org/65814
<band-aid>"[PATCH 00/19] gnu: Astronomy 2023/08 updates." https://issues.guix.gnu.org/65814
<Kabouik>Hum, upgrading my packages after disablinb babariviere/guix-emacs seems to be a no-go, because I have too many of those packages installed already, so the updates does not work. I guess my only hope is for babariviere to fix their channel.
<nckx>The advantage of not using manifests :)
<rekado>In my home config I split the big package list into separate services that extend home-profile-service-type.
<rekado>so I can more easily disable parts of my profile(s)
<rekado>(I also have it generate a separate profile just for emacs stuff)
<zamfofex>PotentialUser-47: You do realise IRC predates Markdown by decades, right? 😄
<PotentialUser-47>zamfofex maybe the clients implemented rendering or the protocol got updated
<nckx>zamfofex: Not quite, 4 years to go.
<nckx>IRC is line-oriented, so any client forking the protocol would be relegating itself to a world of jank where others are unlikely to want to follow (let alone users).
<nckx>It's easy for me to send a message somewhere between your ```, and now this hypothetical client is stuck faking history by grouping your lines together, or doing something else unintuitive.
<nckx></IRC nerdery>
<rekado>ACTION searches for the matching opening tag
<nckx>It's rendered as ‘nckx has joined’.
<nckx>ACTION predates IRC but just barely.
<zamfofex>nckx: My client renders text between (single/inline) backticks as monospaced by default, though I have disabled that.
<nckx>See 😛
<nckx>Sounds like a great idea in a bubble where people don't constantly discuss lisps.
<nckx>By the way, the protocol is still/finally being extended: https://ircv3.net/irc/ (including a multi-line proposal, but I really wouldn't bet on Markdown being well-received by IRC users any time soon.)
<nckx>Pun totally intended in hindsight.
<nckx>ACTION .oO now how did that tag get re-opened.
<the_tubular>Any release date nckx ?
<apteryx>the dvorak-emacs layout for the ergodox is much nicer than the ergodox-ez base one
<nckx>the_tubular: The spec? There will be no ‘IRC 3.0’ release, servers and clients implement (ideally: shared) parts of the spec. Think Wayland, not X11. But for example Libera's sable (IRC! In Rust! Coming 2024! Maybe! Maybe not!) will do so.
<the_tubular>Got it, that makes sense!
<nckx>I wonder how the ‘IRC is obsolete lol’ edgelords will deal with a Rust IRCd.
<nckx>It's got meme power™.
<rekado>on a fresh checkout “make” fails on “contributing.de.texi”
<rekado>and guix.de.texi as well
<bjc>you probably need to ‘guix pull’ to update your texinfo tools
<rekado>I’m on Guix 4dfdd822102690b5687acf28365ab707b68d9476
<band-aid>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4dfdd822102690b5687acf28365ab707b68d9476
<rekado>that’s from June 2023
<bjc>yeah, the change happened in the last month or so. it bit me too
<rekado>(inside this newly created VM using the latest Guix)
<rekado>ah
<rekado>I guess the commit of the “guix” package should be updated then
<apteryx>is it possible to have multiple toolchains in a same profile?
<apteryx>rekado: this is not currently possible because of at least one test failure I need to look into
<rekado>apteryx: we have an old bug report about this. There are different packages providing a “gcc” executable, but it contains different subsets of compilers, even when the same version of GCC is used.
<rekado>(e.g. one gcc is built only with support for objective C, whereas another may have support for C and C++)
<rekado>bjc: so far it didn’t help
<rekado>I even ran “make clean”
<rekado>even “make distclean”
<bjc>you also have to manually clean up the *.$lang.texi files so they can be regenerated
<rekado>ah
<rekado>thanks
<nckx>ACTION https://lists.debian.org/debian-legal/2023/09/msg00001.html 👀
<band-aid>"License violations for dependencies of Rust and Go programs?" https://lists.debian.org/debian-legal/2023/09/msg00001.html
<rekado>I’ve been spending quite some time building a virtual machine containing a git checkout of the Guix repo, compiling it, and turning it into a somewhat comfortable environment for contributing to Guix without any prior setup.