IRC channel logs

<apoorv569[m]>@ncix Oh! so guix has /usr/bin/env now? So I don't have to that extra-special-file thing?

<nckx>Not if you use %base-services, unless something's changed.

<nckx>But ‘now’ is ‘years’.

<apoorv569[m]>I see.

<nckx>Was it missing for you?

<apoorv569[m]>I didn't check I just always had extra-special-file. I will check though and let you know.

<nckx>I added it in 2019, so it better not have run away.

<nckx>It was a bit controversial at the time…

<apoorv569[m]>Why controversial?

<nckx>Beats me, we have /bin/sh ‘for POSIX’ (and because it breaks stuff if you remove it 😉), so providing the ‘modern’ portable version seems obvious to me. The argument was that it was impure.

<nckx>apoorv569[m]: Did rebooting help? I think I hope it didn't because WTF if so.

<bjc>"impuuuuuuuure," i shriek, pointing my knobbed finger at the heretic /usr/bin/env. "impuuuuuuuure!"

<bjc>ACTION → the shadows

<nckx>ACTION puts out some snacks and tea → the shadows.

<Wurt>How can I exclude an input from a specific output defining a package? For example the package have to outputs: out and gui, and you want to exclude de gtk dependency on the out output.

<mitchell`>you can refer to specific outputs using package:out or package:gui

<mitchell`>so if you don't want the gui output try `guix install some-package:out`

<nckx>Outputs are built all at once (often split only at 'install time, or even later), so you can't exclude or otherwise modify inputs between different outputs of one package.

<nckx>But when installing an output and deciding which other packages it depends on, Guix doesn't look at inputs at all, only at references. So the way to make sure :out doesn't depend on GTK is by not having the string "/gnu/store/xxx-gtk-3.2.1" occur anywhere in /gnu/store/xxx-my-package (= my-package:out).

<mitchell`>It would be pretty silly to split those outputs if the non gui was referencing those things anyway

<nckx>True, but Guix will happily let you do silly things.

<Wurt>Thanks, I am updating Transmission and the last version was build using glib-or-gtk-build-system (using the #:glib-or-gtk-wrap-excluded-outputs), but currently the proyect use Cmake.

<mitchell`>nckx: That's my favorite thing about it

<nckx>💪

<mirai>nckx: I'll give the patch a try 'soon-ish'

<nckx>Thanks!

<mitchell`>I take great comfort from the knowing look of disappointment the GNU bison gives me when i'm exercising my software freedom to shoot myself in the foot

<apoorv569[m]>Ok its working after reboot.

<nckx>I don't understand why but yay.

<apoorv569[m]>BTW I also removed the one I installed via guix install and installed it via guix home and manifest file.

<apoorv569[m]>perl I mean.

<acrow>Braving a QA reevaluation I've posted improvements on issue 60976 for ditaa. Hopefully the suggested improvement is obvious despite breaking it into patch pieces. If not send blame here.

<fruit-loops>"[PATCH] gnu: Add ditaa." https://issues.guix.gnu.org/60976

<acrow>Not sure how to take the fruit-loops; but probably apropos. :)

<acrow>ACTION waves at vagrantc

<vagrantc>ACTION waves

<lechner>mirai / are you sure multiple X-Debbugs-CC do not work? One of the two methods should work

<lechner>nckx / mirai / i do not understand why the bot sent the srfi link three times the first time around. the url only had it twice

<lechner>ACTION is researching the UTF thing

<Christoph[m]><nckx> "‘What u typed, how u knew?’." <- I searched for 'guix' in the FDroid Element app after adding libera.chat to the list of servers.

<apteryx>nckx: that'll still be bogus if used inside $(./etc/teams.scm ...) command substitution

<apteryx>(because of the space)

<apteryx>but see https://issues.guix.gnu.org/58813 for more discussion and a patch suggesting to wrap it with patman instead

<fruit-loops>"can't substitute etc/teams.scm command as doc suggests" https://issues.guix.gnu.org/58813

<apteryx>the patch message is titled "[PATCH] doc: Document how to use Patman for patches submission."

<apteryx>curiously updating guile-3.0 to guile-3.0.9 breaks u-boot's cross-compilation

<apteryx>it must propagate something?

<Aurora_v_kosmose>Weird situation. Lots of my VMs suddenly have an unsupported manifest format?

<apteryx>Aurora_v_kosmose: what's the context?

<Aurora_v_kosmose>Pulled guix, now it considers manifest unsupported.

<apteryx>I updated the guix package today, so it seems it could be related

<apteryx>do you have guix in your profile, perhaps?

<apteryx>could you paste the error you see?

<Aurora_v_kosmose>apteryx: On at least one of the two I'm testing, no. (Other is currently busy & IO is slow)

<haugh>I'm running a system install against a new machine using a pre-baked ISO. Trying to get wifi online, but shepherd shows a wpa_supplicant service already running, most likely interfering with my attempts to run it manually... can I reconfigure the existing service without pulling down a whole new iteration of the system?

<apteryx>did you actually already download anything, if you're still at configuring the network step?

<haugh>using a pre-baked ISO

<haugh>no network interfaces online, but networking services running according to herd

<apteryx>oh, I think I get it. I'm not sure how the installer will react to that, but you could try stopping the networking service (herd stop networking)

<apteryx>then try to configure the network manually

<haugh>yeah currently doing so

<Aurora_v_kosmose>Yeah, so a few months of no updates suddenly means manifest no longer works.

<Aurora_v_kosmose>Yeah I didn't turn on that VM much lately...

<haugh>identical nl80211 kernel report after stopping wpa-supplicant, networking, and avahi-daemon.

<haugh>knenel reports: Match already configured

<haugh>s/knenel/kernel

<Aurora_v_kosmose>I'm restarting that VM to see if something just needed restarting...

<Aurora_v_kosmose>...Well. I'm not sure but this looks promising. Restarting /did/ apparently bring everything back.

<Aurora_v_kosmose>So something did need stopping & restarting properly.

<apteryx>Aurora_v_kosmose: glad it wasn't a full stop

<Aurora_v_kosmose>Yeah, that would have been unfortunate.

<haugh>anybody else pulling a 502 off the official download?

<haugh> https://ci.guix.gnu.org/search/latest/ISO-9660?query=spec:images+status:success+system:x86_64-linux+image.iso

<bumble[m]>hello, is there a recommended way to make halt and restart commands available to the user so waybar, for example, could shut the system down?

<apteryx>haugh: yep, I reproduce the 502 :-/

<haugh>\o/

<lechner>bumble[m] / i think you want to modify the sudoers file https://linuxhandbook.com/sudo-without-password/

<lechner>bumble[m] / for security reasons, i recommend to restrict the permitted apps as described there

<apteryx>openssl 1.1.1l time bomb fixed with datefudge :-)

<lechner>yay!

<apteryx>see the patch in #56137

<fruit-loops>"OpenSSL 1.1.1n test failures due to expired certificates (time bomb)" https://issues.guix.gnu.org/56137

<lechner>bot testing https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00042.html

<pecan-pie>"Bogus ‘etc/teams.scm’ usage recommendations?" https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00042.html

<bumble[m]><lechner> "bumble深く傷を / i think you want to..." <- thanks

<apteryx>nevermind the time bomb fix, I was building a graft

<chrislck>ooh guix is now using fancy block graphics instead of |####|

<irfus>bumble[m]: I'm able to run `loginctl reboot` as a user to restart. Requires elogind.

<irfus>presumably `loginctl poweroff` also works, though I've never tried that.

<n8100>Hey! Just got guix installed on my first home server build, trying to get everything going, but I could use some help.

<n8100>I'm trying to install hugo - https://github.com/gohugoio/hugo. Running `guix shell go -- go install -tags extended github.com/gohugoio/hugo@latest` works fine, except that I dont know where / if the binary is kept. I then tried to create a package definition and feel like I'm way in over my head. I copied from a similar? go package in guix and this

<n8100>is what I got: https://pastebin.com/crdT8Rvy

<n8100>I want to keep everything in guix's control, so I want to avoid just downloading the binary and running that.

<winter><apteryx> nevermind the time bomb fix, I was building a graft <-- instead of your actual copy, you mean?

<AwesomeAdam54321>n8100: There's already a work in progress for packaging Hugo, maybe you can start from there: https://issues.guix.gnu.org/43784

<irfus>n8100: have you tried `guix import go github.com/gohugoio/hugo`. That should start you off with a package definition to fiddle with.

<n874>Also new to irc evidently, thanks AwesomeAdam54321

<irfus>though better to go with AwesomeAdam54321's sugegstion for this particular package.

<winter>It looks like it may be easier to just use the recursive flag of guix import in this case, as I'm not sure how many dependencies are still missing in-tree.

<ae_chep>How could I refer to a package definition that is awaiting an update; from elsewhere in my system where I'm developing new software that I also want to install locally?

<ae_chep>(the up-to date definition of the package exists within my copy of guix source code)

<AwesomeAdam54321>ae_chep: You could try package transformation options, or guix refresh

<AwesomeAdam54321>To refer to a package definition file you can use the -f option

<ae_chep>the -f is pointing at the pkg definition of my tool that I want to install locally. I'll try --load-path

<ulfvonbelow>are some email addresses blocked from the mailing list? I sent some patches over a day ago now and I still don't see them in the archives

<AwesomeAdam54321>ulfvonbelow: Is it your first time sending patches?

<ulfvonbelow>yes

<jpoiret>ulfvonbelow: then you'll probably have to wait for moderation

<ae_chep>I still don't see the C_INCLUDE_HEADERS updated with the additions I made in the new package definition. I'll stick to an impure guix-shell for the moment until the new version of cbqn package is released

<apoorv569[m]>When using guix shell --container --emulate-fhs is there a way to specify which shell to use inside container and also pass all the current shell's environment variables inside the container?

<lilyp>"all the current shell's environment" – use --preserve sparingly rather than totally

<apoorv569[m]>so specify the one's I need?

<lilyp>yes, you can use regexp tho

<apoorv569[m]>What about specifying which shell to use?

<lilyp>IIRC it ought to automatically pull up $SHELL

<lilyp>that being said if it doesn't work simply add your shell to the container and invoke it normally

<apoorv569[m]>My I have my user shell defined as zsh but the container for some reason uses /gnu/store/HASH-bash/bin/sh

<parazyd>Hey, I installed Guix on my distro, and have been trying to run the hello example.

<parazyd>However I'm stuck on grep's make check: https://termbin.com/7nqn8

<parazyd>It's just been looping for hours with a: gawk BEGIN { while(1); print(x) } | grep x

<parazyd>Is this a bug, and/or can it be skipped?

<apoorv569[m]>Is the clear command not in coreutils? I wanna have a proper shell inside guix shell.

<lilyp>ncurses

<unmatched-paren>hello guix :)

<lilyp>parazyd: perhaps there's something wrong with /dev/null ?

<parazyd>lilyp: In what sense?

<apoorv569[m]>lilyp: `ncurses` work also had to preserve `$TERM` env var but works.

<apoorv569[m]>now I have proper shell.

<Guest16>I just got a DisplayPort cable that allows me to use an extra monitor... but its causing issues on both windows and guix... (mentioning windows issue cause it likely applies to both) on windows when the monitor is turned off it acts like the monitor is totally disconnected, moving all windows and rearranging desktop layout in a sezure like

<Guest16>fashion... on guix it has randomly crashed the monitor display and afaik prevents key input, tho i got a bit of mouse movement... feels similar to when you run out of memory... ctl+alt+f2,etc. aren't working... currently in a frozen state, msging from phone

<Guest16>the apps displayed on the other monitor are visually updating...

<Guest16>do displayport cables normally have issues like this?

<apoorv569[m]>Hmm so I packaged my custom build of suckless tools like dwm, st and dmenu. I inherited the package from the one in gnu/packages/suckless. But it looks like the package I installed from my custom channel for dwm and dmenu especially are not really my custom builds.. I mean I do have correct keybinds but some things are off like the bar on top has wrong colors its not using my Xresources file which I have patched all suckless tools to.

<apoorv569[m]>dmenu is completely wrong it doesn't seem to have any of my patch when invoked from shell.. the keybind I have in dwm to open dmenu as run launcher works I think but colors are wrong.

<apoorv569[m]>st seems to work though follow colors and seem to have all my patches.

<lilyp>Guest16: sounds like a cable from hell

<lilyp>apoorv569[m]: how did you install your packages – did you make sure they come from your channel?

<Guest16>I've seen people report similar issues from displayport cables... problem is i just don't know how to diagnose this... what cable problem could freeze linux?

<Guest16>apoorv569[m] i haven't done any custom packaging... but guessing it installed from main channel if the names are the same... you could check with `which dmenu` etc. to see the location of the commands, maybe dwm is calling it differently so it finds it correctly... if you fully remove the normal dmenu, etc. and it doesn't work... see if

<Guest16>attempts to install your custom version results in the same /gnu/store/ hash, etc.

<Guest16>lilyp do you use a displayport cable (with displayport on both ends)

<lilyp>well, yes, but mine works fine

<lilyp>could also be a monitor issue, though, idk

<Guest16>i have a dp to hdmi cable i was using before that had no issues... don't have another monitor that uses dp but it might be that (tho its an expensive monitor so i doubt it)

<apoorv569[m]>lilyp: Yes I installed them my channel and the package names are prefixed with `apoorv-{dwm,st,dmenu,slock}`

<apoorv569[m]>I do have my keybinds working so it should be correct only some things are not.

<Guest16>apoorv569[m] where does `which dmenu` link to? can you find your custom dmenu in /gnu/store/ ?

<apoorv569[m]>which dmenu just returns /run/current-system/profile/bin/dmenu

<apoorv569[m]>let me check store

<sepi>Is there any way to get at logs printed during booting? I'm trying to figure out why my RAID1 is not assembled and why I land in the debugger during boot. Also is it possible to continue from the debugger without kernel panicking?

<apoorv569[m]>Autocomplete shows only these in the store https://0x0.st/Hs5O.txt

<Guest1675>check for st in /gnu/store/ since you said that was working

<apoorv569[m]>Hmm... it looks like dwm and st in the store are only seen as apoorv- but dmenu and slock which I installed my custom packages for have both apoorv-{dmenu,slock} and the default dmenu and slock package

<apoorv569[m]>Could it be that password-store installed dmenu as a dependency? But what could install slock..

<apoorv569[m]>weird..

<apoorv569[m]>I only have this in my system config.scm https://0x0.st/Hs54.txt

<cdo256>I often have to do something like `readlink $(which dmenu)`

<cdo256>And then poke around in that dir

<cdo256>did you rename dmenu in your channel?

<sepi>I managed to boot with a raid1 device mapped. I had to specify the raid1 kernel module in initrd-modules of operating-system however.

<bumble[m]>hey everyone where can one find the ascee artwork seen here? https://blog.desdelinux.net/wp-content/uploads/2020/12/guix-tutorial-instalacion-herramienta-gestion-paquetes-imagen-instalacion-paso3-blog-desdelinux.png

<bumble[m]>I think maybe the same artwork is featured in the iso installation media

<bumble[m]>s/ascee/ascii/

<apoorv569[m]>cdo256: `readlink` shows my package

<apoorv569[m]>I think passmenu installs dmenu as dependency and uses that instead.

<apoorv569[m]>bumble深く傷を: You can check the `guix-install` script to see what they use.

<bumble[m]>@apoorv569 thank you I found it here https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh

<rekado>rust fails to build on i686

<rekado>this blocks librsvg on i686

<rekado>actually, this could also be a “guix deploy” bug

<apoorv569[m]>bumble深く傷を: Welcome.

<rekado>because “guix system build --system=i686-linux config.scm” does not attempt to build librsvg with rust

<bumble[m]>I was going to PR a request to update the guix logo at neofetch, because the current logo looks wrong, the neofetch logo was added in 2016 https://github.com/dylanaraps/neofetch/pull/321 and I noticed the repo has many ignore PRs and the repo went completely silent about two years ago

<bumble[m]>according to this reddit thread he disappeared https://www.reddit.com/r/linux/comments/m4pwix/what_happened_to_k1ss_linux_and_dylan_araps/

<jonsger>nice GNU was accepted for GSoC :)

<apoorv569[m]>Where do I find the stuff that is usually found in /usr/share?

<rekado>apoorv569[m]: in every package’s $out/share directory

<rekado>apoorv569[m]: note that none of these directories are meant to be modified

<apoorv569[m]>don't want to modify, I want source come .zsh files from fzf that I installed using guix home and manifest files

<apoorv569[m]>What is the $out directory?

<cdo256>the result of `guix build PACKAGE`

<apoorv569[m]>I think guix home installs packages under ~/.guix-home/profile

<apoorv569[m]>there is nothing in ~/.guix-home/profile/share for fzf

<rekado>how did you install fzf?

<apoorv569[m]>guix home -L PATH_TO_MY_CUSTOM_MODULE reconfigure PATH_TO_MY_CUSTOM_MODULE/apoorv/home/environment.scm

<apoorv569[m]>the environment.scm file just loops over a bunch of manifest files and installs the stuff listed in them.

<tux_life>Hi! I'm unable to upgrade the system

<tux_life>building /gnu/store/bkg8pbgbmbi4n67p6hsiy15gj7f52dzn-parameters.drv...

<tux_life>building /gnu/store/vqkf22yzqh57vkl0irjbadfwf362flip-pam.d.drv...

<tux_life>\builder for `/gnu/store/vqkf22yzqh57vkl0irjbadfwf362flip-pam.d.drv' failed with exit code 1

<tux_life>build of /gnu/store/vqkf22yzqh57vkl0irjbadfwf362flip-pam.d.drv failed

<tux_life>View build log at '/var/log/guix/drvs/vq/kf22yzqh57vkl0irjbadfwf362flip-pam.d.drv.gz'.

<tux_life>cannot build derivation `/gnu/store/3lisgi363bsqikgzn01bclydyn793r78-etc.drv': 1 dependencies couldn't be built

<tux_life>applying 10 grafts for pango-next-1.50.4 ...

<apoorv569[m]>tux_life: Check output of this file `/var/log/guix/drvs/vq/kf22yzqh57vkl0irjbadfwf362flip-pam.d.drv.gz`

<apoorv569[m]>check with vim or something don't cat it won't work.

<mfg[m]>you can zless or zcat that file. I wouldn't recommend zcat though as the amount of text may be really huge. If you use zless shift+g jumps to the end.

<tux_life>zcat /var/log/guix/drvs/vq/kf22yzqh57vkl0irjbadfwf362flip-pam.d.drv.gz

<tux_life>Backtrace:

<tux_life> 2 (primitive-load "/gnu/store/xk74kk2cvfjy0pz5aqz9ld8aric?")

<tux_life>In srfi/srfi-1.scm:

<tux_life> 634:9 1 (for-each #<procedure 7ffff6ebd3c0 at ice-9/eval.scm:3?> ?)

<tux_life>In unknown file:

<tux_life> 0 (symlink "/gnu/store/863krh0mbapfl7jddjyixi9ad8ngrims-?" ?)

<mfg[m]>please paste a snippet of the end of this log to a pasting service like paste.debian.net

<mfg[m]>the last 100-150 lines should suffice to see the complete backtrace i think

<mfg[m]>you can then send the link to the paste here

<tux_life>zcat /var/log/guix/drvs/vq/kf22yzqh57vkl0irjbadfwf362flip-pam.d.drv.gz: https://paste.debian.net/1272183/

<apoorv569[m]>I have this in my system config https://0x0.st/Hs5h.txt

<mfg[m]>tux_life: that's the whole file? oof not much information there :|

<tux_life>this is the whole file... ):

<mfg[m]>tux_life: so the situation is: you have a guix installation and wanted to upgrade with guix pull, right?

<apoorv569[m]>But I can't use virt-manager https://0x0.st/Hs5F.png

<tux_life>mfg[m]: guix pull succeded but not sudo guix system reconfigure /etc/config.scm

<apoorv569[m]>and I have installed these packages https://0x0.st/Hs5C.txt

<mfg[m]>tux_life: i haven't seen such error before. Can you boot an older generation and try to reconfigure from there? Maybe this solves itself then...

<mfg[m]>apoorv569: I have never used virt-manager. But i see that you specified a particular group (the libvirt group)

<mfg[m]>Is your user a member of that group?

<tux_life>mfg[m] ok... I try with an older generation. Thank you!

<apoorv569[m]>Yes I added that group to my users groups reconfiguring system now.

<leirda>Hi,

<leirda>It's my first time posting anywhere on IRC, I'm sorry if I do anything wrong :)

<leirda>I noticed that with dune installed, “$(guix build dune)/share/emacs/site-lisp” is not in "$EMACSLOADPATH" nor "~/.guix-home/profile/share/emacs/site-lisp" (with Guix Home for instance) when Emacs is also installed in the current profile.

<leirda>I can easily add it to EMACSLOADPATH myself, however wouldn't it be best to fix it in the dune package definitions?

<leirda>Is that possible? If so, how would I go about that (I'm willing to do the patch myself)?

<leirda>Thank you for your time,

<Reventlov>hey

<Reventlov>so with a guix binary installation, guix installs a /etc/profile.d/guix.sh file

<Reventlov>do guix support the fish shell ?

<leirda>fish is at

<leirda>version 3.5.1 (sry)

<Reventlov>(i'm not talking about installing fish with guix, i'm talking about making guix available in a fish shell)

<leirda>It does work but I think it might be simpler to start it with `exec fish` at the end of your bashrc

<Reventlov>because /etc/profile.d/guix.sh is bash, and not fish, so…

<leirda>Yea, that's why I would suggest to use bash as login shell, then start fish with the bash inherited envvar

<Reventlov>also, to make guix available in user based shells, i'm getting bash: /var/guix/profiles/per-user/remy/current-guix/bin/guix: No such file or directory

<Reventlov>Do I have to take the steps described in https://guix.gnu.org/manual/en/html_node/Binary-Installation.html#Binary-Installation for the "manual" installation, for the root users, but for my own user ?

<Reventlov>I mean, there is no directory for my user in /var/guix/profiles/per-user, so, I can't really follow the instructions anyway

<leirda>does `guix pull` works as your current user?

<Reventlov>Well, I launch bash manually, source /etc/profile.d/guix.sh manually, then if I guix pull, I get a bash: /var/guix/profiles/per-user/remy/current-guix/bin/guix: No such file or directory

<mfg[m]>Well at least zsh also works as a login shell (i use it with guix since a few years and haven't noticed anything not working)

<Reventlov>It works as root though

<mfg[m]>How did you install guix?

<mfg[m]>I have the feeling something is missing

<Reventlov>I used the shell installer script

<mfg[m]>What is your host distro?

<Reventlov>nixos :p

<mfg[m]>:D

<Reventlov>guix-daemon is running, guix pull works as root after sourcing the thing

<mfg[m]>i think if you don't want to manually source the /etc/profile.d/guix.sh file everytime you need to launch a new login shell, so logout and login again. This should source that file automatically.

<mfg[m]>Maybe this is also enough to use guix as a user

<Reventlov>nope

<Reventlov>please note my shell is fish

<mfg[m]>afaik fish isn't supported

<mfg[m]>bash works, zsh also. I haven't used other shells myself tho

<nckx>lechner: Why would the bot not reply to the full URL, only to its substrings? 3 makes more sense than 2.

<nckx>Christoph[m]: Thanks!

<apoorv569[m]>Ok so I can add a connect for QEMU to virt-manager.

<apoorv569[m]>But every time I close virt-manager and re-open it I have to add that connection again. Any way to fix this?

<mfg[m]>apoorv569: depends on how virt-manager is actually saving such things. Do you know if virt-manager just writes to $HOME/.config or what it does to persist it's configuration?

<mfg[m]>Ah okay, so google tells me it saves the config under /etc/libvirt

<apoorv569[m]>Actually I never thought about because in traditional GNU distribution it just works.

<mfg[m]>Yeah, breaking with tradition has advantages and disadvantages :D

<apoorv569[m]>Yes I do have something under /etc/libvirt

<apoorv569[m]>not accessible by my root user perhaps that is the issue. Because I have installed virt-manager in my user profile.

<apoorv569[m]>by me* I mean to so

<apoorv569[m]>had to do sudo ls -la /etc/libvirt

<mfg[m]>that's normal, the livirt daemon runs as root

<mfg[m]>it should be able to read and write there

<nckx>apteryx: …then what is the point of ‘etc/teams.scm cc’!? Were people manually copy/pasting the output (unlikely, since they would have noticed the ‘missing‘ newline in that case).

<mfg[m]>do you happen to have the folder ~/.gconf/apps/virt-manager/

<apoorv569[m]>nope..

<mfg[m]>or ~/.config/gconf/apps/virt-manager ?

<mfg[m]>cause that's where virt-manager should place it's own configuration

<apoorv569[m]>not under .config/ either

<mfg[m]>hmm

<mfg[m]>maybe this is why your connection doesn't get saved

<mfg[m]>i don't know gconf though

<apoorv569[m]>Hmm..

<mfg[m]>Maybe it's also dconf instead of gconf, i don't know about all those config things. I just run qemu directly :|

<apoorv569[m]>no dconf either

<apoorv569[m]>what do you use? virt-viewer?

<mfg[m]>No, i literally just run qemu-system-x86_64 with the corresponding arguments, no additional software.

<mfg[m]>But i do see that virt-manager is actually much more pleasant to use

<mfg[m]>So according to this centos bug report: https://listman.redhat.com/archives/virt-tools-list/2014-September/msg00252.html

<mfg[m]>dconf is necessary for virt-manager and it may not be installed/running in your case

<mfg[m]>maybe dbus is also needed

<mfg[m]>apoorv569: you use guix system right? What services do you have configured?

<dearg>hi guix, is there a way for guix system image to create a luks encrypted partion?

<mfg[m]>apoorv569: well if you have %desktop-services then dbus is included, dconf seems to not be there though. There is a dconf-service-type, you may try to activate it and see if this solves the problem :)

<nckx>lechner: Commas do work (so a single header, multiple addresses). It's documented.

<irajane>hi

<irajane>could we install budgie desktop on guix linux?

<mfg[m]>Hi irajane, the budgie desktop has not been packaged yet for Guix.

<irajane>package web page is down. anyone?

<nckx>irajane: Thanks.

<nckx>Hum, did somebody reconfigure bayfront before andreas-e added me back? My password is… not. I cannot sudo, so I can't do anything about packages.guix.gnu.org either.

<nckx>Nope.

<nckx>Could someone set me up the passwd? (cbaines, apteryx?)

<lechner>nckx / okay, i got it. the srfi url as a whole also triggers a response. i only thought about the two url components. that would need a tokenizer to be solved. the folk in #scheme already tried to push me toward PEG parsing but I haven't gotten around to it.

<nckx>Yep.

<nckx>I don't really follow your ‘hence, tokenizer’ diagnosis but adding PEG would probably make parsing more pleasant *in general*, so why not.

<nckx>But deduplication of responses in general would be good to have, and would address this, without PEG.

<lechner>currently all detectors run over the same string. a url processed by one does not, as you noticed, prevent a response to the substring "srfi-209".

<lechner>nckx / that's a gray area. when strings are repeated by the message author, the bot does not feel responsible for duplication. i just checked\

<lechner>nckx (or anyone else, reaslly) / meanwhile, i would appreciate some help as to what stopped the bot earlier today in the hugo Github URL. the title contains a single left quote but as a higher codepoint https://paste.debian.net/1272197/ i am unsure about the string/bytevector behavior in Guile and nothing i try is working

<nckx>I don't see why it's a grey area, someone using the same bug number 3 times in a long response doesn't need 3 identical bot replies to that one message.

<nckx>I guess you don't *want* https://srfis.io/srfi-420-a-cool-new-srfi-inspired-by-srfi-69 to linkify+titleify ‘srfi-69’ as well, but it's not wrong.

<nckx>Doing so for srfi-209 three times was.

<nckx>A simple delete-duplicates addresses that.

<nckx>I wasn't around for the hugo thing… *scrolls up*

<lechner>sorry, try that again, please. i ran an experimental version by mistake

<nckx>I used a fake URL on purpose.

<lechner>yeah, but the bot did not respond

<nckx>But OK! https://srfis.io/srfi-420-a-cool-new-srfi-inspired-by-srfi-69

<nckx>Boom.

<lechner>i see

<nckx>lechner <hugo>: Did the bot not print a backtrace?

<lechner>coming

<lechner>nckx / the "delete duplicates" sounds simple but is hard in practice. the bot suffers from acute amnesia. the srfi detector does not monitor the url detector or vice versa.

<nckx>Understood.

<nckx>I'm not surprised or disappointed, it's a natural way to write a simple bot.

<lechner>it'll get better. i hope the thing is still helpful in other ways

<lechner> https://paste.debian.net/1272199/

<lechner>here is what i changed last night https://codeberg.org/lechner/guix-helper-bot/src/commit/b62b328fa336aa680b842a566e7b1e9143fd768d/scm/scan/generic-urls.scm#L55-L58

<nckx>As a fix?

<nckx>Because https://github.com/gohugoio/hugo doesn't crash the bot here.

<mirai>is there an option for guix refresh --list-dependant to only list a count?

<lechner>nckx / is that because guix shell -f did not rebuild?

<mirai>I've noticed I've been getting bogus counts all the time with my home grown bash function: guix refresh --list-dependent $* | tr ' ' '\n' | wc -l

<lechner>what's bogus?

<nckx>lechner: It's a brand-new checkout, but I'll delete the cache just in case…

<mirai>$ guix refresh --list-dependent autokey

<mirai>No dependents other than itself: autokey@0.95.10

<mirai>$ guix-count-deps autokey

<mirai>6

<mirai>=)

<lechner>nckx the guix.scm is not up to date

<nckx>Oh!

<lechner>it never is, in development

<nckx>Let me ask a better question: how do *you* run it?

<lechner>i'd go crazy

<nckx>Sure, but that's not proof.

<lechner>you'd go crazy

<lechner>GUILE_LOAD_PATH=/lcl/lechner/guix/guix-helper-bot/git/scm:$GUILE_LOAD_PATH scm/guix-helper-bot.scm --nick=your-cereal --channel='#your-channel'

<lechner>that's until my kernel module starts working

<mirai>ACTION just thought up that having a hexchat plugin to search for guix issues would be useful

<lechner>in a -D shell please

<foomar>mirai: I think you need to cut off the part before the ':' in the output, something like: $ guix refresh --list-dependent autokey | sed 's/^.*: //;s/ /\n/g' | wc -l

<lechner>nckx / this is the url that prompted the latest change https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00042.html

<lechner>foomar / mirai / sed gives me goose bumps https://www.perl.com/article/perl-one-liners-part-1/

<mirai>foomar: oh right, I've noticed that it prints a sentence at the beginning

<mirai>thought it was just a bare list of packages

<foomar>mirai: You could also fallback to counting the '@'s, since there is a 1 to 1 correspondence between '@'s and packages in the list

<foomar>lechner: might learn perl this summer :)

<mirai> guix refresh --list-dependent $* | cut -f2- -d':' | cut -c2- | tr ' ' '\n' | wc -l

<mirai>foomar: that's a good idea too

<lechner>foomar / there has been a full-on renaissance at the perl foundation by a few renegades and friends of mine, but i now recommend guile for most scripting applications

<mirai>I never did perl oneliners

<mirai>usually sed or awk suffices

<mirai>lechner: were you enlightened by SICP ?

<mirai>ACTION hasn't read beyond the first chapter yet

<mirai>are build logs ever read by (package) maintainers / submitters / _ ?

<mirai>occasionally I see messages like: https://paste.centos.org/view/cd23b4dd

<patched[m]>Is it possible to completely rebuild ones profile? For some reason I cannot rid myself of gcc, which is in the store as per `realpath $(which gcc)`.

<patched[m]>I have tried `guix package --export manifest`. With `guix package -m`, gcc is still present. With `guix shell --container -m`, it is not.

<patched[m]>* package --export -manifest`. With

<mirai>TLDR; messages of the kind: patch-shebang: ./tests/regex/regex.pl: warning: no binary for interpreter `perl' found in $PATH

<patched[m]>s//-/

<lechner>mirai / one of the many oddities resulting from our handling of prerequisites

<nckx>lechner: Sorry, I got called away by the siren song of ‘doing laundry’.

<nckx>mirai: Some people do, some people don't. Some notice those messages, some don't, some might think they are irrelevant. Are they?

<nckx>Not every last shebang needs to be patched, but if it would run more tests, please do.

<nckx>lechner: Oh, this should be simple.

<nckx>By the way, I gave up fighting guix shell + Guile load paths and just modified guix.scm to use ‘git-checkout’ for the bot package.

<nckx>26 Feb 16:47:45<nckx> https://github.com/gohugoio/hugo

<nckx>26 Feb 16:45:38<nckx-but-a-bot> "GitHub - gohugoio/hugo: The world?s fastest framework for building websites." https://github.com/gohugoio/hugo

<nckx>Because this doesn't challenge the assumption of using ISO-8859-1.

<nckx>lechner: https://paste.debian.net/plainh/ddabe7e6

<nckx>patched[m]: What's the list of installed packages?

<nckx>I don't see the point in rebuilding the same thing.

<nckx>Also, ‘which -a gcc’?

<patched[m]>which -a gcc: $HOME/.guix-home/profile/bin/gcc

<nckx>Ah. So no use in messing about with ‘guix package’.

<nckx>Whatever is pulling in (propagating) GCC is in your guix home configuration.

<lechner>nckx / please also send the patch for the git=checkout part

<patched[m]>Ahh... Thanks for the pointer, I'll inspect my home package list then

<lechner>nckx / i think gitplug serves correctly. i think i should revert my latest change and instead fix the bug at lists.gnu.org <title>Bogus ‘etc/teams.scm’ usage recommendations?</title>

<nckx>lechner: OK, but the ‘proper’ patch version is a bit noisy because of the ‘let’ removal. https://paste.debian.net/plainh/280c9433

<lechner>we need a diff format for sexps

<nckx>Yes.

<nckx>Probably exists TBH.

<lechner>also, a bit noisy was an understatement

<nckx>\o/

<nckx>It is the dubstep of patch.

<ocix[m]>will the chroot-script of guix be added into the guix-boot-iso? it take some time for me to reconfigure system after swap disk drive position, (reinstall guix after all)

<lechner>reinstall because of swap?

<lechner>nckx / what is your position on the title served by https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00042.html please?

<lechner>nckx / hi, how would you apply the latest patch you sent, please? patch unexpectedly ends in middle of line

<nckx>lechner: I am not a Web dev, but I guess you think the <meta> tag should precede <title>? If so I agree. The charset should also be sent by the server and isn't.

<nckx>lechner: Probably an artefact of my advanced patch-over-pastebin protocol. echo >> a newline into it.

<lechner>is lists.gnu.org sending UTF-8?

<lechner>nckx / i thought we word "advanced" was now non-grata at Guix

<nckx>Valid UTF-8? Yes, according to iconv.

<lechner>unless used sarcastically, of couse

<lechner>how about gitchuck?

<nckx>Everything I say is to be interpreted sarcastically. Saves time.

<lechner>i like that

<nckx>Git Bubba seems to do everything correctly, but again I am not a charset nerd nor a Web dev.

<nckx>ocix[m]: I don't know which chroot script you're talking about. If it's something Guix supports, I think it makes good sense to include it on the ISO. But I'm also confused about why you're chrooting in the first place.

<lechner>from my perspective there is a difference. maybe Guile's web client looks at the meta/charset tag (or in the case of lists.g.o doesnt)?

<nckx>Let me get my

<nckx>¯\_(ツ)_/¯

<lechner>is that an airplane?

<nckx>An aeroplane without a clue yes.

<nckx>lechner: Note my ‘precede’ point above.

<lechner>yeah, i caught that but it left a few things unsaid

<nckx>If the meta tag trails title, clients are not expected to backtrack and re-parse the entire file as UTF-8. Whatever precedes it should be ASCII. l.g.o's title isn't.

<nckx>Is that better?

<nckx>Since there's no HTTP header charset either, Guile should not (to my limited knowledge) be expected to handle that quote.

<lechner>i would like you to give up and say that lists.g.o has a bug, please

<nckx>It would be ‘modern’ of it to try but it's not buggy.

<nckx>lechner: I am implying it does as strongly as my lack of domain knowledge allows.

<lechner>such as soft opinion? around here?

<nckx>s/‘modern’/charitable/

<nckx>Yes, it's a Sunday, I do those then.

<lechner>i read the exchange about blobs yesterday, but i guess it wasn't sunday

<lechner>actually, you were moderate then too

<lechner>what could you do, with barbarians at the gate?

<nckx>I was trying *to* moderate then. Glad to hear I succeeded.

<nckx>lechner: Offer them coffee. Barbarians love coffee. Then, we can talk.

<lechner>the revolution was merely postponed. the people demand more power from the quadrumvirate

<lechner>or faster patch approval

<nckx>The quadrumvirate politely declines.

<nckx>Ooh snap.

<lechner>it's that or system change

<nckx>Let's do the coffee thing first.

<nckx>ACTION away, work waits not for Sundays.

<nckx>Oh, one last thing: you probably noticed, but I forgot to change the /home/nckx in the git-checkout to use (getcwd), lechner. Unless you also use the user name nckx, this will not work.

<mirai>is --fallback option bogus for guix build?

<mirai>--no-fallback doesn't exist

<mirai>and by default guix build will fallback to local build if substitutes fail

<futurile>Hola Guixers

<mirai>though guix/scripts/build.scm doesn't look like it sets fallback? to #t unless I'm overlooking something

<lechner>nckx / you sent me the strangest patch of all time. i cannot apply it. (but i can copy four lines by hand.) did you reformat my file?

<lechner>futurile / hola compadre

<nckx>lechner: No, it's atop your b62b328. Emacs even kept the weird alternating-line tabs indenting ‘inputs’ intact. Maybe https://tobias.gr/tmp.patch (now with bonus getcwd) is more robust.

<nckx>mirai: I don't think the assumption that ‘guix build will fallback to local build if substitutes fail’ is true, though, but I'll gladly stand corrected.

<nckx>It's certainly not expected to.

<lechner>yeah, sorry. i have never had this problem with tabs in emacs until i started working with paredit/scheme/guile/whatever

<nckx>Anyway, noise aside the patch is simple enough to apply yourself, I don't need credit.

<mirai>./pre-inst-env guix build will try to build locally if it can't get substitute

<mirai>for whatever reason

<lechner>nckx / was that for mirai or i?

<mirai>manual says "Specifically, if --fallback was omitted, then no local build will be performed, and the derivation is considered to have failed."

<mirai>but why would I build wxwidgets then?

<mirai>when the package isn't named that

<nckx>mirai: *…and a substitute for a derivation is available* is important, no?

<nckx>Guix should error out if a server advertises a substitute [or Guix is somehow convinced it did, mumble mumble caching] but then fails to return one.

<mirai>guix weather shows it as available

<mirai>> or no substitute is available for the derivation in question, a local build will always be performed, regardless of whether or not --fallback was given.

<nckx>Yes, that's the part I was quoting from.

<mirai>this sentence is far from the previous one

<nckx>Unavailable != expected but failed.

<nckx>It's in the same paragraph.

<nckx>Also, I bet grafts somehow bugger this up, because they bugger everything up.

<nckx>lechner: For you.

<nckx>ACTION distracted.

<alx[m]>> <@alxev:matrix.org> guix weather ungoogled-chromium-wayland

<alx[m]>> computing 1 package derivations for x86_64-linux...

<alx[m]>> looking for 1 store items on http://ci.guix.gnu.org...

<alx[m]>...(truncated)

<alx[m]>guix weather ungoogled-chromium-wayland... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6bc76cd2c9fa97d4f25cb335fc392ec2e86270fa>)

<lechner>nckx / i think we need something better to run local builds. can guix pick up the source directly from the local file system instead of going through git checkout?

<nckx>mirai: Is there a way I could reproduce what you're seeing? That would help me understand what you're expecting. It's certainly possible a bug has snuck in, but it's going to be pretty subtle and we might be talking past each other.

<alx[m]> * Hi all. For some reason ungoogled-chromium is not loading from substitute servers. And guix weather shows that build exists, https://ci.guix.gnu.org/build/432629/details .

<alx[m]>Actual hash of package now is different, or idk what is reason, why weather shows build, but reconfigure builds this package

<alx[m]>maybe this problem has already been discussed above, I can't find it

<nckx>alx[m]: Yes, but you're not expected to have found it :) https://logs.guix.gnu.org/guix/2023-02-25.log#201059 — the search index generation has stalled again, grmbl. Why does everything break. It's like ops isn't trivial!

<nckx>So the CI is broken for unknown reasons, at least for ungoogled-chromium, and the IRC search to find out about that is broken for unknown reasons, also packages.g.g.o is broken for unknown reasons. If we're not careful, Elon Musk will try to buy us soon.

<nckx>And I can't log into the machine that hosts the latter two.

<mirai>nckx: I was attempting to build autokey

<nckx>From upstream Guix master? Thanks.

<mirai>not upstream guix, I'm trying to update it here (haven't nailed the tests right yet)

<nckx>s/log into/get any useful privs/

<mirai>but it should pull wxwidgets

<nckx>Ah. I'll try.

<nckx>So you're seeing it (1) try to download a substitute for wxwidgets (2) get an error from the substitute server (3) fall back to building wxwidgets locally?

<nckx>Because I get a substitute for /gnu/store/jbymrwyvk7fp41xkbfij450xj19s8jak-wxwidgets-3.2.1.

<mirai>wxwidgets is not the only thing, it happened with webkit with soup ?

<mirai>it's erratic

<mirai>one run tries to build it, the next run doesn't

<apteryx>nckx: I noticed about ungoodle-chromium too

<lechner>Hi, do we have a special group for usb access? I cannot find plugdev on my system

<lilyp>at least when using udev it doesn't appear necessary to have one?

<lechner>lilyp / help-guix hasn't updated the html yet but https://paste.debian.net/1272224/

<lechner>"attempt to scan in Guix"

<cel7t>Is it possible to build icecat with libressl instead of openssl on guix?

<tux_life>I have a weird problem with updates. I have to run "sudo guix system reconfigure /etc/config.scm" hundreds of times, because building the packages fails. When one package build finally succeeds, the next package build fails and I have to repeat the command. Sometimes I get a kernel panic. I just installed Guix System 1.4.0 and encountered the

<tux_life>problem already during the installation.

<lilyp>lechner: what does sane-find-scanner (from sane-backends) say?

<nckx>mirai: What I reproduce sounds like the opposite of what you see? I ‘localhosted’ out both substitute servers in /etc/hosts, but Guix still has the availability of wxwidgets cached. ‘guix build autokey’ fails immediately, and suggests using ‘--fallback’. But ‘guix build autokey --fallback’ fails in the exact same way, modulo the suggestion. https://paste.debian.net/plainh/aba371a2

<nckx>Disabling grafts does not help.

<lechner>lilyp / dunno, it's for our friend gottfried via email

<lilyp>cel7t: try --with-input=openssl=libressl and see how it goes

<nckx>lechner: Do they have the sane-service-type? It uses the ‘scanner’ group, although I am not in this group and can scan. I don't have a scanner handy.

<cel7t>lilyp: Thank you

<cel7t>By the way, I had a question regarding the gsoc page (https://libreplanet.org/wiki/Group:Guix/GSoC-2023)

<cel7t>Can I apply for projects listed under earlier years (2018, 2019 etc) too? Since the listed mentors might not necessarily be available again

<nckx>tux_life: We'd have to know more about these failures to help. Either the build failures (these should be printed by Guix, or be in a gzipped file near the end of what's printed), or the panic message.

<nckx>cel7t: I'd ask the mentors, IMO there's a good chance they're still willing.

<nckx>Or apply for new mentors on guix-devel@.

<apteryx>how can I stop/start the samba server on guix?

<apteryx>it's supposed to provision 'samba-samba, but 'herd restart samba-samba' says no such service

<mirai>nckx: strange

<nckx>Yes. :(

<mirai>apteryx: is that a shepherd service?

<apteryx>yep, samba-service-type

<apteryx>it stopped working after an upgrade, or I don't know when

<cel7t>nckx: In that case, should I send an e-mail to the guix-devel mailing list asking if there's someone willing to mentor for the same?

<cel7t>I'm unsure of mailing list etiquette since I mostly stick around IRCs/forums ^_^"

<nckx>cel7t: s/or/and/ actually, no need to waste time stuck on one.

<mirai>apteryx: does herd not show any samba-... ?

<nckx>cel7t: Just send a message to guix-devel at gnu dot org with a clear subject line and friendly body. We don't bite.

<nckx>We're grateful for your help!

<nckx>You can CC the mentors too.

<tux_life>nckx: unfortunately I can't post from my laptop with Guix. But it is strange that the builder fails one time and not the next time. Can this be hardware related? I have a Thinkpad t400 with Libreboot

<apteryx>mirai: it shows samba-smbd, samba-winbindd and samba-nmbd

<apteryx>but but not samba-samba, for some reason

<mirai>is this after a system reconfigure ?

<apteryx>not sure when it stopped, I use it rarely, but yes I've reconfigured since I last used it

<apteryx>I get some permission failure in /var/log/messages: Feb 26 12:21:09 localhost rpcd_classic[3635]: reopen_one_log: Unable to open new log file '/var/log/samba/log.rpcd_classic': Permission denied

<mirai>could be one of those issues that resolves itself with a reboot?

<cel7t>nckx: Thank you very much. As someone who's been on the user side of free software for most of my life, organizations are a bit intimidating, so I really appreciate the amicability

<nckx>tux_life: It could be, but there's really no way to say more without info. You might be running out of RAM (how much do you have?), overheating, failing drive, … None of these are very likely [running out of RAM shouldn't™ panic your kernel] but there are so many options. Many of us run Guix System just fine on machines of similar vintage though, although most ‘old ThinkPads’ are slightly newer at this point.

<nckx>I use an X230T that still has 4G of RAM because I can't be bothered to put in more. With (z)swap, works fine.

<nckx>The RAM is literally in my drawer at home. It's quite sad.

<apteryx>mirai: ah, the nmbd component was stopped

<apteryx>restarting it fixed it

<mfg[m]>tux_life: which packages are being built? What is the exact error message?

<nckx>cel7t: Welcome!

<mfg[m]>Ideally you could substitute most of them via network

<nckx>tux_life: Can you take a picture?

<nckx>If sending text is out of the question, that is.

<mfg[m]>true

<tux_life>I have 4GB of RAM. Swap is unused. Ok.... I'll try with pictures, thanks!

<nckx>mfg[m] is right, but I do build packages locally (Firefox is the only exception) locally. Just want to clarify that these older machines aren't substitute-only.

<nckx>s/one locally//

<mfg[m]>Does guix put /tmp on a tmpfs per default?

<mirai>mfg[m]: no

<nckx>mfg[m]: Good question, but no for this exact reason.

<rdrg109_>[Q] I'm learning how to write my own packages using define-public. I'm doing some computations in (arguments (#:builder ...)) and I would like to debug it. What are some alternatives to do this?

<nckx>mfg[m]: It can (and does) lead to surprises on foreign distroes though.

<mfg[m]>yeah, i use guix on arch and forgot that arch puts /tmp as a tmpfs with 50% the size of available RAM.

<mfg[m]>took me some time to get that

<mirai>and until #60756 is merged, you'll have to set (needed-for-boot? #t)

<mirai>unless you want a nasty surprise with GDM and possibly other things

<nckx>Mostly GDM. I've never set that. In fact it's explicitly #f for whatever reason.

<tux_life59>First picture: https://postimg.cc/21v3RVr1

<nckx>I wonder why I did that, since that would be relevant for 60756 :-/

<mirai>does git-fetch nuke .git from the package source?

<nckx>Yes.

<mirai>so if a test requires .git to exist?

<nckx>It's not reproducible. Also, huge.

<mirai>patch it out?

<nckx>Yes.

<nckx>You could get supremely clever, add git as a native input, and check in the entire build directory before running the test suite, but if that works it's a silly test anyway :)

<nckx>tux_life59: Thanks! Could you ‘zcat’ that ‘View build log’ file next?

<nckx>Or ‘zless’ if you know what to look for and want to scroll to the most interesting-looking part.

<tux_life59>Well...the build finally succeded. I'll post the next log, If I have problema with the next package

<mirai>what's this /homeless-shelter directory anyway

<nckx>tux_life59: The file would still exist though.

<nckx>But OK!

<nckx>If this happens again, don't restart the build.

<winter>Why is there both `make-linux-libre` and `make-linux-libre*`? The former doesn't seem to be used at all.

<mirai>is /homeless-shelter read-only?

<winter>it doesn't exist at all

<mirai>some tests want to create .config/ to test if XDG_CONFIG_DIR works

<mirai>~/.config

<winter>you can set it to something to get those tests to run, though i'm admittedly not sure to what, any example I can find in-tree just sets it to the... prefix?

<winter>which i guess is not for test related things

<winter>(you'd want a tmpdir)

<tux_life59>nckx ok... 2 more pictures of the log: https://postimg.cc/gallery/4N85c6d

<nckx>mirai: It's the default $HOME, and yes, it's unwritable. 'T was done to minimise the chance of builds encoding /tmp/guix-build-blah/blah/home in the output, I believe, and has to be explicitly opted out from with (setenv "HOME" (getcwd)) or similar.

<nckx>Also pretty sure it's forever-API so not going anywhere, ever.

<nckx>tux_life59: Oh boy.

<winter>segfault in the compiler? oh boy indeed

<nckx>Who had ‘internal compiler error: Segmentation fault’ on their shit bingo card; you win an egg.

<winter><nckx> Also pretty sure it's forever-API so not going anywhere, ever. <-- (was this to the linux-libre question or the homeless-shelter question?)

<nckx>Sorry, /homeless-shelter.

<nckx>tux_life59: This strongly implies hardware instability of some kind. I'd start by running memtest86+(https://www.memtest.org/, they have ISOs you can download, unzip, & dd) first if this were my machine.

<winter>figured, just wanted clarification since i wasn't sure how that counted as a "forever-api" (it's just a nonexistent folder, after all) ^^

<nckx>tux_life59: Mostly because it's an easy first step that will at least give you *some* confidence that your machine isn't changing random bits, making all other bets off. Ideally, it's run over night.

<winter>ah looks like the asterisk is just some naming convention

<nckx>winter: The value of HOME. civodul is (rightly IMO) quite adamant that the base build environment provided by the daemon (as opposed to the Guile code that's run inside that) will never change.

<winter>nckx: What I meant is that it really could be changed to any name, as long as it has the same properties, which means it doesn't really matter in the end. (Though I suppose you're talking about the properties, and not the name.)

<nckx>Both.

<nckx>We really want the daemon's build environment to be bit-identical.

<winter>Bit-identical to any past, present, and future revision of it, you mean?

<nckx>If the name changed and became, say, longer, that *could* be an observable change if it now overflows some buffer. Silly example, but it's a hard principle.

<nckx>Yes.

<winter>I see, so it's just to minimize catastrophes.

<winter>s/just/:

<winter>*//

<nckx>(Please don't point out that the kernel is completely exposed and can differ wildly in more fundamental ways; you'd be right but terribly inconvenient and I'm just about to have dinner. Can't have that.)

<winter>:)

<winter>cheers

<nckx>o/

<winter>wonder how hard getting a custom kernel tree/kconfig on Guix could be. doesn't look too bad at a glance

<winter>this will either be fun or it'll be a disaster

<tux_life>nckx Sometimes I have "Machine Error" by streaming. This is a Libreboot-related problem, when microcode isn't installed. I don't know if this help...

<tux_life>Finally upgraded....i have a now a new generation

<lilyp>How do people manage to release software that doesn't compile?

<bjc>docker

<bjc>(a joke. sort of)

<winter>lol

<mfg[m]>tux_life: Yay :)

<mirai>lilyp: Works for me™

<lilyp>Becomes less of an excuse the more mes there are

<nckx>Are these the mes used to bootstrap Guix? …imsorryillgetmycoat.

<lilyp>no, that'd be a mess

<nckx>I'll get your coat too.

<nckx>tux_life: Congrats… sort of :)

<tux_life>mfg[m] ok, then...whit this setup the problem remains forever, I think... ?

<nckx>Likely.

<lechner>504 Gateway Time-out for package.ggo

<nckx>I'm not familiar enough with this generation of machines to know about common problems like a blursed microcode version, but merely using Libreboot != instability per se, at all. Was yours configured & flashed by someone reputable?

<nckx>lechner: https://logs.guix.gnu.org/guix/2023-02-26.log#150717 :(

<pecan-pie>"IRC channel logs" https://logs.guix.gnu.org/guix/2023-02-26.log#150717

<the_tubular>Which packages provides dig or nslookup or host ?

<nckx>tux_life: If you do get memtest86+ errors, the fix could be as trivial as securely reseating the RAM after blowing for dust, and running it another night. That would be the best case. LibreBoot (CoreBoot, …) *are* known to be more sensitive to that, but run fine if you respect this.

<the_tubular>I'm having DNS issues :(

<nckx>the_tubular: dig is bind:utils

<nckx>Never use the others.

<nckx>* I never… Was not advice.

<the_tubular>Got it

<tux_life>nckx My Thinkpad T400 was flashed years ago. Now I have flashed internally to upgrade Libreboot. The problem by streaming whithout microcode is know.

<nckx>Oh :(

<tux_life>nckx ok, I'll try memtest86+

<nckx>Just to rule it out.

<nckx>mirai: What's the propagated-input removal based on?

<nckx>Both seem to be use'd in the code.

<nckx>I agree that propagating a deprecated alias of perl itself is pretty poop, though. I assume that's safe to remove.

<lechner>ACTION likes kdig from knot:tools

<nckx>ACTION likes drill from ldns:drill, it's got electrolytes & DNSSEC

<nckx>It's not drop-in comptabile though, e.g., no +short but -Q.

<lechner>actually, i like that one too, maybe even better than kdig

<lechner>nckx / will you respond with a recommendation for sane-service-type? https://lists.gnu.org/archive/html/help-guix/2023-02/msg00130.html

<nckx>kdig was my go-to for years :)

<pecan-pie>"Re: attempt to scan in Guix" https://lists.gnu.org/archive/html/help-guix/2023-02/msg00130.html

<the_tubular>I've heard about drill nckx, should I try it ?

<the_tubular>Also, I see I have dnsmask on my machine could I use that ? How do i see it depends of which package ?

<lechner>dnsmasq?

<lechner>that's a local resolver

<the_tubular>Ohh, oops

<nckx>the_tubular: drill can pull more bits of info out of the DNS if you ask it to, and do more with it (like local DNSSEC validation). If you need that, you'll probably know, and I recommend trying drill. But if you're happy with the info dig gives you, it matters little which one you use. Try them all if you like, and use whichever you prefer.

<nckx>Another disgustingly diplomatic answer.

<lechner>ACTION thinks dig is already too complex for most users

<nckx>Maybe!

<the_tubular>Can it do zone transfer ?

<lechner>nslookup!

<nckx>the_tubular: No, all these are query tools. nsupdate does that.

<the_tubular>Pretty sure dig also does that no ?

<lechner>yes, he misunderstood

<nckx>Well, you can send an AXFR with dig…

<nckx>but it's like…

<nckx>eh?

<nckx>My bias is showing but it's like saying you can use netcat in my book.

<lechner> https://www.acunetix.com/blog/articles/dns-zone-transfers-axfr/

<the_tubular>I use socat all the time

<nckx>For zone transfers?

<the_tubular>No, just generally

<nckx>It's not that I misunderstood, it's that I'm surrounded by masochists.

<nckx>Oh.

<nckx>Good.

<mirai>nckx: Exporter is included in perl core

<mirai>or some similar message to the effect

<nckx>(If you like discussing drill over dig, you'll love trying ncat over netcat 😉)

<nckx>mirai: Thanks. Same for Storable?

<mirai>yes

<nckx>ACTION applies the patch.

<nckx>the_tubular: What are you building?

<tux_life_>Memtest...... https://postimg.cc/gallery/RZ0j7KH

<apteryx>I've got lots of noise in my /var/log/messages from NetworkManager; it seems to attempt to run /sbin/modprobe, which doesn't exist: Feb 26 14:09:16 localhost NetworkManager[29252]: <error> [1677438556.3225] modprobe: '/sbin/modprobe --use-blacklist iptable_nat' failed: Failed to execute child process “/sbin/modprobe” (No such file or directory)

<mfg[m]>tux_life_: interesting it seems all ways the second hex digit form the right side is wrong by 4?

<mfg[m]>At least when I read that correctly 😅

<nckx>tux_life_: Sorry to see that… At this point you might want to [also] look for more specific LibreBoot help. I think #libreboot here is still official. Or at least Leah's opped :)

<nckx>mfg[m]: Sentient cosmic rays.

<nckx>Ooh…

<mirai>lmao

<nckx>lechner, the_tubular: …you were right, I misread the dig question. My bad.

<mirai>(define ignorance blis)

<mirai>nice easter egg

<the_tubular>Sorry, which one nckx ?

<nckx>The dig transfer mess, the confusion was mine.

<the_tubular>Got it.

<nckx>Still interested in what you're building though.

<the_tubular>Ohh, trying to automate recon and just looking for new tools in general

<mirai>apteryx: perhaps it needs to be wrapped?

<the_tubular>Not anything really exciting

<nckx>mirai: Nope, patched, it's explicitly calling /sbin/modprobe.

<Arjanhehim[m]>I just deployed a ROCKPro64 system from an x86_64 host, I love how that just works

<nckx>Since NM runs as root, it might be OK just to patch the store path rather than /run/setuid?

<mirai>hardcoded?

<nckx>Yup…

<nckx>I mean, I just grepped, but the … --use-blacklist string is there. Would be an awful coincidence.

<apteryx>nckx: not sure what it expects, but if it expects a setuid binary I'd rather give it that

<apteryx>it may be dropping privileges even if it starts as root

<nckx>Well, I wanted to sound all clever and say for sure rather than guessing, but my NM isn't doing that. :) Are you using some VPN?

<nckx>My NM is spammy but not in that way.

<nckx>You could put a non-setuid modprobe in /sbin as a quick check… I'd actually like to avoid hard-coding a Guix System-specific name, if at all possible.

<tux_life>mfg[m] yes....the second hex digit form the right side is wrong by 4

<nckx>Just don't use those then.

<nckx>apteryx: Missed the ‘dropping privileges’ bit: it's running as root here…

<nckx>Could have some exec helper but, at least in this specific case, it would be pointless.

<apteryx>I see

<apteryx>then just patching the store ref should be fine

<nckx>I mean, I definitely agree you should test it, but I can't reproduce it myself.

<nckx>What do you use that needs NAT?

<nckx>Could be my kernel too. I use nftables. Maybe it has what NM thinks it needs, or NM doesn't even know how to ask for it.

<nckx>ACTION considers setting up a persistent ‘stock Guix System VM’ to be automatically started when they join #guix. It's starting to get annoying.

<mirai>is console-keymap-service-type deprecated?

<mirai> "@emph{This service is deprecated in favor of the

<mirai>@code{keyboard-layout} field of @code{operating-system}.} Load the given list

<mirai>of console keymaps with @command{loadkeys}."

<mfg[m]><tux_life> "mfg yes....the second hex..." <- Do the libreboot folks know something about that? Maybe nckx is right and your ram slot has some dust at exactly *that one* pin. (Dunno how likely that is though)

<winter> <nckx> winter: Wonderful! Here's my suggested fix for that compression bug: https://paste.debian.net/plainh/c1400ff3 <-- Did you ever submit this, btw? If you did, I can't find it on debbugs. (Wanted to make sure it works :)

<winter>I'd check now but the paste expired.

<mirai>since 2021 but no define-deprecated was used

<tux_life>mfg[m] I'll open an issue on Libreboot... I wonder if the older version of Libreboot has the same problem. Thank you for understanding my english that is very bad! =D

<nckx>It's… really not.

<rdrg109_>[Q] newbie user here. When executing "guix package -I", 4 columns are shown. I want to know the formal names for the information presented in those columns? Where can I read this information? By common sense, I can say that the first column is the package name, the second column is the package version, but what about the 3rd and 4th column?

<nckx>tux_life: In case you missed my previous message, there's #libreboot (I guess that would be #libreboot:libera.chat for you).

<sharlatan>Hello, is CI down-down?

<nckx>winter: It's very clever, and it works… but doesn't compile :( Pulling in system-linux-image-file-name triggers a module import cycle.

<winter>Ow. Why, if that's an individual function?

<tux_life>nckx Thank you! Yes...but I am the only person on #libreboot

<mfg[m]>tux_life: Alright. Haha, don't worry; english also isn't my native language 😉

<winter>(Though if that can't be worked around, I'd say it's best to just add all 3-4 possible names to the list :D)

<nckx>tux_life: Hm, no, then you're in the wrong channel/room.

<winter>yeah, #libreboot definitely has people

<nckx>There are dozens in #libreboot, and I see winter just joined :)

<winter>nckx: Maybe the function can be moved to linux.scm?

<nckx>Even if they were blocking Matrix somehow (Leah can be grumpy) I think you'd still get an error, not an empty room.

<nckx>winter: That's what I'll probably do. I'm not great at debugging these cycles.

<nckx>Are you? (◍•ᴗ•◍)

<winter>I have never touched Guile until days ago, so...

<nckx>No problem.

<winter>I'n gonna go with no :)

<winter>I do wonder why it's being caused though, are cycles calculated at the module level and not the function one?

<nckx><I'd say it's best to just add all> That's not a bad solution, but I'd really like to try harder to DRY first, and c'mon, this just feels so much cleverer.

<winter>(So if the modules are importing itself but none of the functions cause a cycle, it'd still cause a cycle.)

<tux_life>nckx ok...Then... I wait. But in the meanwhile I'll try with an older version of Libreboot. Maybe it is better

<nckx>Well, I don't know what the empty room you're in is (I know next to nothing about Matrix), but I assume that it's the wrong one so nobody will show up no matter how long you wait.

<nckx>I was trying to save you time but if it's not working, file that issue, I guess.

<nckx>Or use <https://web.libera.chat/gamja/>.

<nckx>Then just /join #libreboot .

<nckx>rdrg109_: That's a good question! The columns are documented in the manual (‘info guix’, ‘Invoking guix package’ — or <https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-package.html#Invoking-guix-package>) under ‘--list-installed’. But it's not documented by the command itself. Doing so now is probably not a good idea, even if we try to be clever and retain backwards compatibility with isatty/stderr/etc.

<nckx>sharlatan: It's not down-down, and most build succeed <https://ci.guix.gnu.org/search?query=system%3Ax86_64-linux>, but some aren't being run for some unknown reason. ungoogled-chromium being a notorious example.

<mirai>civodul: gnu/system.scm has procedures maybe-string->file and maybe-file->monadic that might be worth a look, dates back to 2015-06-05 and look deprecated

<mirai>same for gnu/system/file-systems.scm regarding title

<mirai>and mapped-devices.scm

<civodul>mirai: maybe-string->file and maybe-file->monadic seem to be private & unused, no?

<civodul>we should compile with -Wunused-toplevel sometimes

<lilyp>wouldn't that give us a bunch of false positives though?

<civodul>yes, that's why we don't do it by default

<civodul>it's annoying that this warning cannot be fully accurate

<mirai>the gnu/system/filesystem & friends look deprecated to me though I left that part untouched

<mirai>for now

<mirai>s/look/seem to contain deprecated/

<mirai>nckx: can you give me a heads-up when #61821 makes it upstream? I'll have to rebase a branch that depends on it before sending to ML

<nckx>It would have done so already if I hadn't had other things to do.

<nckx>Will do.

<civodul>mirai: in file-systems.scm, 'title has been deprecated since 2018-05, so yes, i think we can remove it now

<civodul>quite a bunch of code to handle that deprecation :-)

<civodul>in mapped-devices (the 'targets' field), we can wait a bit longer

<nckx>civodul: Hi. If you have a moment (and a clue), could you explain why importing (gnu system) into (gnu build image) to use system-linux-image-file-name causes a cycle? (gnu build image) already imports (gnu system uuid), so I don't think I violated a layering…

<civodul>nckx: as a rule of thumb, (gnu build ...) shouldn't include (gnu non-build ...)

<civodul>there are exceptions: uuid, file-systems, and mapped-devices IIRC

<nckx>So uuid was always a bit cheeky?

<nckx>Ah.

<nckx>Why?

<civodul>because these define little more than record types

<nckx>I can store only so much lore in my RAM.

<nckx>OK.

<civodul>they don't pull in all the service stuff etc.

<nckx>Then I think system-linux-image-file-name is ill at home in (gnu system) if it's useful elsewhere. Is that correct?

<civodul>yes, i think it can stay in (gnu system)

<civodul>or do you need it elsewhere?

<nckx>(And is any of this written down in not-a-mailing-list? I have an impressive amount of this random lore knocking around in my brain, but I can't keep adding stuff and it bitrots, too… :)

<civodul>right!

<nckx>civodul: Here's the change (sorry about the comment noise): https://paste.debian.net/plainh/0421a94c

<civodul>i don't think it's written

<civodul>jpoiret did a great job at explaining some of these things in their 10 years talk

<nckx>Aha.

<nckx>Thanks (both).

<nckx>Will watch.

<civodul>so in this case, i would either kinda duplicate system-linux-image-file-name (!), or move it to a (gnu build ...) module that can be used both by (gnu system) and (gnu build image)

<civodul>(gnu build linux-boot) maybe?

<civodul>but then make sure (gnu system) uses #:autoload

<nckx>Heh. I've duplicated it here (just to test the blame) but that completely defeats the point.

<nckx>(Of avoiding yet another ‘;; Please manually keep this in sync with foo!’ comment. :)

<nckx>OK, thanks for mentioning that: there's no point (or otherwise a bad idea) to try to autoload myself into (gnu system) then? I was considering that.

<nckx>But at that point I was just trying random things and that's a bad sign.

<civodul>you want to autoload yourself?

<civodul>then who am i to judge

<nckx>Unintuitively, it sounds like a lot of work, so probably not.

<nckx>So using #:autoload to load (gnu system) from (gnu build …) would have been… what exactly? Fine? Pointless? Bad?

<nckx>Stupid?

<jpoiret>basically build code should not refer to general guix code

<jpoiret>unless it's something that's specifically made to be usable by build code and general guix code

<jpoiret>build code consists of things that are "embeddable in build situations, where you don't interact with guix itself"

<jpoiret>gnu system contains or relies on a lot of guix-specific code, like g-exps, so is a no go for build code

<jpoiret>the exceptions are when you have some record definitions that can be relied upon by both build code and guix itself, like (gnu system uuid)

<nckx>Thanks. I intuitively knew of this boundary and do avoid it, but I could not have explained why (gnu system uuid) suddenly showed up and was fine. And if you can't explain something…

<jpoiret>the boundary is sometimes quite tenuous :)

<nckx>Had it not been there I think I would have simply said, hah, of course this won't work, We Don't Do That Here, and left it at that.

<nckx>It is good I have been forced to stare into the boundary :)

<nckx>jpoiret: I've sent you to my phone, to watch at my leisure.

<cbaines>nckx, are you still looking to get root on bayfront?

<nckx>Yes!

<nckx>Just a password should suffice. I should have root.

<cbaines>nckx, cool, I've set your account password, and you can find it in your home directory

<nckx>Ta.

<nckx>‘sudo rm’ still works indeed. Thanks again.

<cbaines>I've also found where I put the packages.guix. log ( /var/log/guix-packages-website.log ) now

<nckx>Found? It was so intuitive I was already reading it! Pity it contains nothing of interest.

<nckx>What is missing is a rottlog rule, I think, which is why you might have missed one puny file name.

<nckx>File itself, not so puny.

<cbaines>I'm not sure why it seems stuck, but I guess restarting it is the thing to try

<nckx>But… I did. Did it freeze again?

<cbaines>ah, I was assuming it was still stuck

<cbaines>I see it working now :)

<nckx>Not related to this, but from the logs: seems like a robots.txt might be handy, either way. If we can handle the load it seems like it might even be useful to allow indexing.

<nckx>Is there some Guile REPL I could connect to for guix-packages-website?

<cbaines>I don't know, it uses artanis so if that's something it enables, then it should be possible

<nckx>If that's the same thing logging fancy ANSI colour codes I expect nothing less.

<nckx>Apparently not.

<winter>what's the difference between the "guix" and "gnu" module namespaces in-tree?

<winter>seems like they're tightly coupled either way you slice it (e.g. guix is just for the primitives/CLI)

<jpoiret>guix is the internals, gnu is the distribution (roughly, exceptions apply)

<jpoiret>among the exceptions: commands are in guix/scripts/, but may rely on things in gnu

<winter>right, that's what i figured, but got tripped up by that coupling

<winter>thanks

<civodul>winter: highly recommended guided tour of the source tree: https://10years.guix.gnu.org/video/guixy-guile-the-derivation-factory-a-tour-of-the-guix-source-tree/

<nckx>I wouldn't call it tight but it's cozy, if you're used to strict layering.

<nckx>mirai: If the mail wasn't sufficient heads up, there's this.

<ellysone[m]>anyone knows what to do when you encounter that?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ce3c517e09449462336d65b9751e58023e75f71e>)

<nckx>I don't, but maybe you'll like learning about the ‘errno’ utility from the moreutils package. If you're lucky enough not to know most by heart (bless it). E.g., ‘guix shell moreutils -- errno 17’. Which file (really: object)? I don't know.

<nckx>Some duplicate interface?

<ellysone[m]>Well.... I'm trying to setup enp3s0, I bootstraped guix from a debian system, I don't know if this caused leftovers

<ellysone[m]>ACTION sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/306d0ab8bf57365d485725dfb69bd62c08c760d6

<nckx>ACTION → 😴💤, good luck.

<winter>thanks, civodul, i'll give it a watch.

<ellysone[m]>good night

<winter>how often are grafts removed, if at all? (as in, the replace directive removed, letting the entire tree rebuild.)

<winter>i ask because i've seen e.g. one package have 17 grafts applied 😅 so was just curious

<mirai>nckx: thanks

<lechner>mirai / hi, have not had any time to read it. please send chapters i should look at

<lechner>yay, Haskell's cabal-install version 3.6.2 arrived in Guix!

<ellysone[m]>Ok so what happened

<ellysone[m]>is that I commented the ipv6 route and address fro mthe static networking

<ellysone[m]>rebooted and pouf error gone

<ellysone[m]> * is that I commented the ipv6 route and address fro mthe static networking block

<ellysone[m]>rebooted and pouf error gone

<lechner>yeah, it does not deal well with both, possibly contrary to the docs, does it?

<ellysone[m]>yeah I don't know

<ellysone[m]>the link-local address causing some problems?

<ellysone[m]>now I just need to debug why libvirt isn't doing anything :(