IRC channel logs

2020-12-07.log

back to list of logs

<raingloom>heyy, so, i'm refactoring my machine configs to use declarative modules, and for some reason this doesn't work: guix system vm --load-path="/whatever" --expression="(use-modules (raingloom machines some-hostname)) some-hostname"
<raingloom>some-hostname **is** defined as a public symbol and i can see it in a REPL and it **is** an operating-system object
<raingloom>(also it kinda sucks that (use-modules) doesn't work now. i had some conditionally loaded modules. but eh, i won't miss it too much.)
<raingloom>well, the module file also returns some-hostname at the end, so i guess i can just use it like that, but it sucks big time that now i can't parameterize my OS.
<jeko>How did I end up with many nginx processes running ?!
<schemescrub> https://gist.github.com/radamar/b41f251d91cfdfe389585c0dceb1de8e#file-etc_slash_config-scm-L70
<schemescrub>3 old gist, and i'm a scheme scrub, but this user was able to modify %desktop-services and %base-services in the same config
<schemescrub>i get "duplicate field initializer" when i try
<schemescrub>i'd be highly grateful for just a bit of spoonfeed on this one
<ces>Hey, can anyone ls their /boot/efi and tell me if it is normal to only have EFI here
<mbakke>ces: yes, that is normal
<mbakke>schemescrub: what are you trying to achieve? The error is because of the duplicate (services ...) field.
<mbakke>%desktop-services is a superset of %base-services, i.e. %desktop-services includes all the %base-services and some more
<schemescrub>oh snap
<schemescrub>i was trying to configure ssh and a desktop environment on the same machine but had failed to realize desktop is a superset of base
<schemescrub>i've got what i want now; thank you!
<ces>I get a wierd error when i try to reconfigure, =grub-install: error: efibootmgr failed to register the boot entry: Input/output error.=. Anyone have a clue about this?
<helaoban>hello guix: hello guix: I feel like I'm missing something obvious, but where do I get libstdc++? Shouldn't "gcc-toolchain" give it to me in "${GUIX_ENVIRONMENT}/lib"?
<c4droid>Hi, swap-devices is support lvm device? I change my guix installation from original partation to lvm, when I set swap-devices to lvm mapped devices, guix report "Wrong type" error
***sturm is now known as Guest32245
***luke-jr- is now known as luke-jr
<helaoban>sorry, I should clarify: why isn't there a symlink to libstdc++ in $GUIX_ENVIRONMENT/lib ?
<PotentialUser-44>Hello to all! Why do I get this error when trying to boot to new installation? https://imgur.com/QOChHPn
<PotentialUser-44>it just freezes there and nothing happens. I also got same issue when booting GuixSD install from USB but it worked after a few reboots.
<PotentialUser-44>Hardware is AMD Ryzen Pro 1300, RX560 GPU, ASrock A320M HDV R4 and I'm booting through UEFI
<helaoban>ok so I understand that I need to specify the "lib" output of gcc in order to have that link. Why is libstdc++ factored out into a separate output?
<bdju>is anyone else using quaternion on guix system? clicking links doesn't open them in the default browser I have configured for xdg-open. also, I don't know how to set a dark theme.
<mroh>bdju: I thought, I have fixed this xdg-open issue maybe a week ago or so. Is this on a recent system?
<bdju>mroh: (fyi, I'm the one from the matrix channel) I don't think xdg-utils missing as a dependency was the problem since that was already on my system. it seems more like the normal xdg config isn't being applied.
<bdju>btw, which browser do you use? I wonder if what you use is in the list of default browsers to try, whereas I'm using qutebrowser which definitely isn't (but it *is* configured as my default and working with other programs)
<bdju>oh, and as for the recency of my system, I maybe haven't updated in a few days
<bdju>guix (GNU Guix) 6cf7b5e2adcd48b804a108931de46a791d56cb87
<abcdw>hi guix
<abcdw>Is there some good template project for guile? Want to write a simple cli utility, would like to have some basic example. Interested in project structure and dependency management.
<efraim>Guilehall?
<PotentialUser-35>Hello, I just installed the 32bit version and instead of a login screen I get. "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please contact a system administrator."
<PotentialUser-35>When I looked at the logs /var/log/gdm/greeter.log There's this error that spawns others. (.gnome-shell-real:338): Clutter-Critical **: Unable to initialize Clutter: Unable to initialize the clutter backend: no available drivers found
<luhux`>please use sddm .
<PotentialUser-35>luhux: me?
<luhux`>yes
<PotentialUser-35>luhux: how do I substitute gdm for sddm?
<abcdw>efraim, ok, will try, thank you.
<luhux`>remove (gdm-service-type ...) and add (sddm-service-type ...) in config.scm
<PotentialUser-35>There's GNOME desktop service type not gdm
<PotentialUser-35>Is that the one?
***hji- is now known as hji
<luhux`>The reason I recommend sddm is that gdm has never run correctly on my machine
<luhux`>I don't understand this, I am a wm user..
<PotentialUser-35>luhux`: please share your config file. I wanna see where sddm fits
<luhux`>ok
<luhux`> https://github.com/1luhux1/os/blob/b6ca0e13d08265dd0dd5809edafa93b56d228ab1/guix-config/notebook/lenovo-g470.scm
<mange>If you want to use %desktop-services (which includes gdm) you can use something like the example in "(guix) Using the Configuration System" in the manual, at the end of the "System Services" section.
<mange>You can remove the gdm-service-type from your system, so then you can add sddm without any potential for conflict.
<bdju>do any other qutebrowser users here have issues with sites using those cloudflare checks? they seem to loopp forever instead of completing after "5 seconds", so a bunch of sites are inaccessible
<civodul>Hello Guix!
***Jin[m] is now known as Coyo[m]
<jeko>Hello Guixters !!
<civodul>o/
<jeko>Hey civodul ! Yesterday I checked my port numbers, my host name (same I use to ssh to the machines) but still can't deploy.
<jeko>Oops… how're you? ^^
<jeko>I restarted ssh daemon, checked if any other process were using the port...
<jeko>Also I upgraded Guix on the host
<civodul>hey jeko!
<civodul>i'd check the hosts and ports in the deploy config file
<civodul>and then try to connect to those from the same host
<jeko>everything is fine when I connect to it
<jeko>in /etc/ssh/authorized_keys.d there is the right key
<jeko>if I do `guix system delete-generations` then `guix gc --list-live | grep ssh` I should see only one sshd-config, isn't it?
<kisaja[m]>slim cant configure display server?
<civodul>jeko: to see the sshd_config file in use, you should run "herd status ssh-daemon" and then "cat /proc/PID/cmdline | xargs -0 echo"
<civodul>kisaja[m]: it's possible to use Slim instead of GDM; that's what you had in mind?
<civodul>mothacehe: hey!
<mothacehe>hey civodul :)
<civodul>mothacehe: it just occurred to me: for the discovery code, can't we use call-with-output-file/atomic instead of resorting to file locks and all?
<mothacehe>oh didn't know about this one
<mothacehe>looks like we could!
<mothacehe>I'll see what I can do :)
<civodul>cool :-)
<civodul>that may simplify things a bit
<mothacehe>sure
<jeko>civodul: Ha! I was looking for such command, thank you ! And the config is OK. I will continue the investigation later ^^ Thank you for your help !
<crazyfrog>Hello to all! I already tried to get help a six hours ago but didn't get any respone. Does anyone know why GuixSD freezes at this point?
<crazyfrog> https://i.imgur.com/QOChHPn.jpg
<crazyfrog>CPU: AMD Ryzen 3 PRO 1300, Motherboard ASRock A320M HDV R4, GPU AMD RX560 2GB
<civodul>leoprikler: thumbs up for closing a 2016 bug! :-)
<civodul>reported by younger rekado_
<jeko>yay \o/
<jeko>crazyfrog: I have no clue
<crazyfrog>I would provide more information if I could :(
<crazyfrog>I tried disabling CSM, enablind/disabling fast boot and nothing helps
<crazyfrog>I tried disabling CSM, enabling/disabling fast boot and nothing helps
<kisaja[m]><civodul "kisaja: it's possible to use Sli"> to choose wayland or xorg
<cbaines>crazyfrog, you could try removing "quiet" from the boot options in grub, and see if that gets you more information
<crazyfrog>I'll try it, thanks
<mothacehe>cbaines: hey! thanks for the Cuirass/SQLite analysis, I just replied!
<cbaines>mothacehe, you're welcome, I'm just replying to your reply :)
<mothacehe>note that on Berlin I managed to have a very small WAL file
<mothacehe>following mozilla recommendations
<cbaines>Does it stay very small?
<mothacehe>I think so but my monitoring is based on running a ls once in a while
<mothacehe>At the time I found that complex queries with large WAL files behaved bad
<mothacehe>causing inconsistent query times
<kisaja[m]>civodul can i configure slim to use wayland or xorg
<cbaines>Indeed, I've been tracking the WAL size for the Guix Build Coordinator, and you can clearly see a correlation between WAL size and read performance
<cbaines>This graph shows my fighting against the WAL size in the Guix Build Coordinator http://mago.cbaines.net:9090/graph?g0.range_input=1w&g0.expr=guixbuildcoordinator_datastore_wal_bytes&g0.tab=0 I think I've won finally
<mothacehe>good job!!
<mothacehe>I also noticed that we had a ~1GiB WAL file for Guix itself
<mothacehe>which is pretty bad
<cbaines>Ah, the guix-daemon?
<mothacehe>yup
<cbaines>Yeah, that's probably not great
<mothacehe>-rw-r--r-- 1 root root 6.0G Dec 7 10:31 db.sqlite-wal
<mothacehe>
<mothacehe>not getting any better
<civodul>kisaja[m]: i think slim is X11-only
<crazyfrog>so I loaded without quiet option in grub and there seems to be no errors https://imgur.com/59BVoN1
<cbaines>crazyfrog, hmm, although searching the internet for amdgpudrmfb or "amdgpudrmfb freeze" seems to give some results
<crazyfrog>ah I see, seems that it is related to linux-libre kernel build?
<crazyfrog>I wonder if I can chroot into GuixSD system from installation media and then rebuild kernel
<cbaines>crazyfrog, potentially, I've heard AMD GPU's have some dependency on non-free firmware. I don't know how dependent they are on it though
<cbaines>crazyfrog, is this something that's just broken, or a new installation?
<crazyfrog>just a new installation
<jonsger>cbaines: usually they should run in 2D without hw acceleration even if no firmware gets loaded
<cbaines>jonsger, cool, good to know
<cbaines>crazyfrog, there's maybe some option you can pass to Linux so it doesn't try loading the broken graphics stuff
<cbaines>that at least might allow the system to boot
<jonsger>I think, but I think you need to do some dance on the cmdline for the kernel or so
<crazyfrog>well I can build my own kernel and it might work fine
<jonsger>I think I didn't get my AMD GPU really working with linux-libre
<crazyfrog>hmm is there any command in guix to do easy chroot into system?
<crazyfrog>if not then how do I chroot into GuixSD system?
<crazyfrog>will /mnt/dev/<partition> /mnt/guixsd && chroot /mnt/guixsd /bin/bash work?
<cbaines>mothacehe, I've pushed those Cuirass commits now
<mothacehe>cbaines: nice, thanks! I like to deploy on berlin right after changing important stuff in Cuirass, to discover issues as soon as possible.
<mothacehe>that means updating Cuirass package in maintenance basically
<mothacehe>cbaines: I also see that there are other sqlite-finalize statements we could turn into sqlite-reset
<mothacehe>oh sorry ignore the last sentence, I was read an older version of database.scm
***guix-vits is now known as vits-phone
<cbaines>cool, I was wondering why I couldn't find any
<mothacehe>hehe sorry :)
<cbaines>it seems I removed the last of them!
<crazyfrog>Hmm I chrooted to my GuixSD install and when I try to run guix pull it says that connection refused to var/guix/daemon-socket/socket
<crazyfrog>Okay this problem solved, now to building kernel...
<jonsger>at least 18 builds of icedove in the last month with only 3 new releases ^^
<leoprikler>civodul: thanks
<civodul>jonsger: ever more than that! https://data.guix.gnu.org/repository/1/branch/master/package/icedove/output-history
<jonsger>oh, I manually counted successful builds :P
<civodul>heh
<civodul>someone could crunch all that data and draw conclusions about scheduling etc.
<mothacehe>civodul: looks like we are missing some "build-succeeded" notifications. https://ci.guix.gnu.org/jobset/guix-modular-master reports almost no builds whereas all those derivations are built.
<mothacehe>(or most of them)
<mothacehe>mmh cuirass doesn't seem to start them at all, which means something else is triggering those builds
<mothacehe>maybe some mcron task
<mothacehe>cbaines: there's something doing huge amounts of requests to the Cuirass API, causing database workers starvation. Would it be the Data service?
<mothacehe>(see /var/log/cuirass-web.log on berlin)
<civodul>mothacehe: i have a script building ~ludo/critical-packages.scm on berlin...
<mothacehe>is guix-modular part of them?
<civodul>no
<civodul>but, guix-modular is just the derivations leading to guix
<paali>Hello, have this problem {https://upload.disroot.org/r/gTz4hctH#W9Kd79Xk6Xzz0bR+ufhFoNJRVgnKTD1UdE+E8eKUEXE=} in configuring Shadowsocks profile:
<civodul>so they can be built as a side effect of other things, for x86_64-linux
<mothacehe>civodul: ok that's probably what's happening
<paali>What is the solution?
<cbaines>mothacehe, I can stop the Guix Data Service polling just in case. I'd check the NGinx logs though, as they'll include user agents, it's probably bots that are the significant factor
<civodul>mothacehe: that doesn't explain guix-modular on non-x86_64 though
<mothacehe>cbaines: the ideal would be that Cuirass could swallow those huge bursts
<mothacehe>but right now it causes temporart (~2 minutes) 504 errors
<mothacehe>civodul: true, I'm investigating that!
<jlicht>hey guix!
<paali>Hello!
<paali>I have this problem (https://upload.disroot.org/r/Anx9xFc7#T/WPKkGP8kG5L+irM8qXHm0QDJPNNB2t9rpY3MXl4zQ=) configuring Shadowsocks profile.
<paali>What is the solution?
<jonsger>hi jlicht :)
<paali>😞️
<jlicht>o/
<jonsger>paali: my guess would be missing dependencies
<jonsger> https://github.com/shadowsocks/shadowsocks feels empyt
<paali>jonsger: what should I do?
<paali>😞️
<paali>...
<jonsger>one has to fix the package, I guess
<kisaja[m]>civodul: "The SliM project has been abandoned (last release was 2014)" i get why wayland isn't an option
<jonsger>kisaja[m]: I use sddm for my wayland session
<kisaja[m]>is sddm using less ram than gdm? i mean is 'simple' really simplejonsger:
<paali>Please please help, I am in censorship prison...
<lemes>hi guix
<lemes>I was looking through some files from guix/scripts and noticed that a few of them use cons* when defining %options and some others use list. Is there a reason behind this?
<paali>luhux
<paali>luhux:
<paali>luhux: .
<jonsger>kisaja[m]: RSS for sddm is 180M
<paali>luhux: You made suggestions that I do not remember, if possible, comment:
<kisaja[m]>so manual should suggest same 'remove' option of gdm for sddm, as is for slim already (to replace gdm)?
<civodul>hi lemes!
<civodul>lemes: i think it's just convenience, dependending on how many options are being added to the list
<civodul>(cons* a b c lst) is equivalent to (append (list a b c) lst)
<civodul>*depending
<civodul>so it's purely cosmetic!
<lemes>civodul I see.. thank you!
<paali>I have this problem (https://upload.disroot.org/r/Anx9xFc7#T/WPKkGP8kG5L+irM8qXHm0QDJPNNB2t9rpY3MXl4zQ=) configuring Shadowsocks profile.
<paali>What is the solution?
<kisaja[m]>switched to sddm, entered sway from menu, systray isn't shown in 13status
<civodul>paali: hi! the link doesn't seem to work for me, it says "please wait" but i never get the file
<kisaja[m]>i see only "Notification is not defined"
<kisaja[m]>on that link
<paali>civodul: But it works for me!
<rekado_>FWIW I also only see "Notification is not defined"
<rekado_>maybe try a different paste service?
<civodul>hmm on Guix System, why do we have 6 entries in GUILE_LOAD_PATH instead of 2?
<civodul>(should be just ~/.guix-profile/share/... and /run/current-system/profile/share/...)
<civodul>in the console we have only 4
<paali> https://unix.stackexchange.com/questions/623324/shadowsocks-profile-configuring-in-guixsystem
<jeko>When `guix deploy` to a target machine, I should see an ssh connection attempt in the logs of the target machine (ie /var/log/secure), right ?
<civodul>sneek later tell paali that looks like a shadowsocks packaging bug, probably worth reporting to bug-guix@gnu.org
<sneek>Got it.
<civodul>jeko: yes
<jeko>civodul: cool so I am getting closer to my problem haha
<civodul>:-)
*jeko should learn how to use emacs-guix to explore guix's source code
<jeko>or the guix repl
<bavier[m]>civodul: I'm having trouble using a `gcc-toolchain` package from `guix pack` on a foreign system. Are there tricks involved, or maybe just bug?
<civodul>bavier[m]: did you source the pack's etc/profile?
<civodul>that's about all it should take, i think
<bavier[m]>yes. It's a `-R` pack. Do the wrappers warn if `-RR` would be needed?
<bavier[m]>there are a few symlink jumps that `gcc` has to go through to find `cc1` in the libexec dir, and that's not working right now.
<civodul>bavier[m]: -R is userns only; the wrapper errors out if userns aren't supported
<civodul>hmm
<civodul>dunno maybe you should send details to bug-guix :-)
<civodul>i haven't tried gcc-toolchain in a pack
<bavier[m]>sure, I'll try to untangle these symlinks and then send a message.
<bavier[m]>I made a package for an up-to-the-minute "gcc-dev" package so I could try out the latest aarch64 support, but still need `guix pack` to run it on this system :)
<civodul>oh nice, so you're building GCC straight from Git?
<bavier[m]>yup, it worked great.
<civodul>nice
<civodul>would be worth sharing, including with the GCC folks
<bavier[m]>did we settle on a loose convention of a "guix.scm" file in the top directory? or something like that?
<civodul>yes, like you write: that's the loose convention :-)
<bavier[m]>:)
<nly>openzfs 2.0 released: https://zfsonlinux.org/
<mroh>our new `(define true-but-soon-false ...)` is often called in a political environment after voting ;)
<rande>Is the answer on this page (https://unix.stackexchange.com/questions/623324/shadowsocks-profile-configuring-in-guixsystem) correct?
<jorge[m]>Hola,puedo actualizar un solo paquete?
<civodul>mroh: heheh :-)
<rande>Is the answer on this page (https://unix.stackexchange.com/questions/623324/shadowsocks-profile-configuring-in-guixsystem) correct?
<civodul>rande: it looks good, yes
<civodul>perhaps the person asking didn't expect to modify the package definition, though
<rande>civodul: Thank you
<civodul>jorge[m]: sí, puedes ejecutar "guix upgrade PAQUETE"
<jorge[m]><civodul "jorge: sí, puedes ejecutar "guix"> Gracias estaba colocando update.
<civodul>bavier[m]: if you can stop by #guix-hpc, i'd like to discuss https://gitlab.inria.fr/guix-hpc/function-multi-versioning :-)
<civodul>well not necessarily now, but sometime
<bavier[m]>ooo
<kozo[m]> https://github.com/Shirakumo/radiance
<vagrantc>civodul: i bumped up the verbosity on guix's test suites ... but i don't see a similar mechanism for gnutls ... any idea how hard that would be?
<civodul>vagrantc: both use Automake; the output is saved in individual .log files and the summary is in test-suite.log
<vagrantc>civodul: with guix there's a --brief=no|yes flag that i found helpful ... e.g. it displays each individual test fail/pass rather than a summary for each file ... but no such thing in gnutls
<vagrantc>though with hanging tests, not particularly helpful
<civodul>vagrantc: ah yes, --brief is for the srfi-64 test suite driver, but GnuTLS doesn't use that
<civodul>hmm lemme see
<civodul>in reauth.scm, there's a "Debugging" comment; you can uncomment the following lines
<vagrantc>civodul: when i set --brief=no it gives me much more useful output for (nearly?) all the tests
<civodul>i think --brief=no lists all the individual srfi-64 tests no?
<civodul>i don't use it :-)
<vagrantc>all the .scm tests, anyways
<civodul>anyway uncommenting these two lines in reauth.scm should help
<vagrantc>wow, the reproducer for that appears to actually work ... i was admittedly a bit skeptical about the /dev/shm /tmp symlink steps to set up the environment
<PotentialUser-99>Hello friends,
<PotentialUser-99>I'm new to Guix; And I, like some people, have trouble connecting to Shadowsocks.
<PotentialUser-99>Until I could find this solution with a lot of searching,
<PotentialUser-99> https://unix.stackexchange.com/questions/623324/shadowsocks-profile-configuring-in-guixsystem
<PotentialUser-99>But I do not understand anything about this solution, help!
<mdevos>basically, the Guix package definition is apparently somewhat incorrect, so it needs to be changed slightly
*mdevos starts emacs etc ...
<PotentialUser-99>mdevos: Please help me
<mdevos>give me some time (:
<mdevos>the stackover entry seems somewhat incomplete, the package input definition isn't listed
<PotentialUser-99>😞️ ...
<PotentialUser-99>...
<leoprikler>`guix edit shadowsocks` ;)
<mdevos>PU-99: just wait a little! I'm writing a patch to Guix
<mdevos>I'm trying to avoid copy-pasting the stackexchange code, contributions there are CC BY SA apparently
<leoprikler>Well, the solution is not complete anyway, but couldn't BY-SA be relicensed as GPL v3 after making a modification?
<mdevos>leoprikler: I'll check that out
<PotentialUser-99>Thank you very much friends
<mdevos>leoprikler: wouldn't that be GPL3.0-only, and no GPL3.0-and-later?
<leoprikler>Ah, yeah, you're right.
<mdevos>I think I have an alternative solution: create a config.json with correct paths
<vagrantc>you can't relicense something without the author's permission, though you can add a different license for additional code as long as the licenses are compatible
<vagrantc>at least, that's my amateur take on licensing :)
<vagrantc>well, you can also license things incompatibly, but that does nobody any good
<mdevos>I've abandoned the config.json path, config.json.example is also used for configuration
<mdevos>not just for locating libraries etc.
<leoprikler>In this case, it appears the author themselves noticed and added a clause allowing their code to be reused under GPLv3+.
<leoprikler>Gentlemen, there is an imposter among us.
<mdevos>leoprikler:I just noticed the update
<leoprikler>/s/men/guix/
<vagrantc>did someone mis-sign git commits?
<cbaines>vagrantc, I'm not seeing guix pull issues. Maybe you're encountering an out of date keyring branch issue?
<mdevos>(about shadowsocks) it builds, let's see if it works
<mdevos>ok, it builds, does anyone know how to test it? I don't use shadowsocks myself
<leoprikler>I think there's a reason this thing went unnoticed since 2018.
<leoprikler>You could paste your package description for PotentialUser-99 to try out, but you'd probably have to write it in a way that they can `guix build -f` it.
<vagrantc>cbaines: i was referring to leoprikler's comment about an imposter amoung us
<cbaines>ah, OK
<vagrantc>as in ... that's the main place i'd really worry about an imposter :)
<leoprikler>Well, TIL I can't meme :(
<bavier[m]>it's all good
<vagrantc>leoprikler: or i'm out of the loop :)
<mdevos> https://paste.debian.net/1175977/
<mdevos>I'm running a slightly out-of-date guix, there is a theoretical chance it won't build
<mdevos>or I made a copy-paste paste mistake
<cbaines>vagrantc, did anything interesting happen in the #reproducible-builds meeting?
<mdevos>If someone can confirm it works, I'll send it to the list
<mdevos>(I know nothing about shadowsocks)
<cbaines>I think the next thing to do on the Guix side is to actually implement client side support, I tried a little while back https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html
<vagrantc>cbaines: a little underwhelming, but we've been setting up occasional topic-specific meetings.
<vagrantc>cbaines: still some people hanging around if you want to follow-up on anything: http://meetbot.debian.net/reproducible-builds/2020/reproducible-builds.2020-12-07-17.58.html
<PotentialUser-99>leoprikler: What exactly should I do now? I am a novice!
<leoprikler>Well, given that they've only posted a patch, you will have to check out Guix from source and apply that.
<mdevos>then build guix, then ./pre-inst-env guix install shadowsocks
<zimoun>hi
<leoprikler>PotentialUser-99: If you want to do it quick and dirty, though: Download https://paste.debian.net/1175979/ into some file and then `guix build -f that-file`
<zimoun>why usernamespace is not working on Guix System? <https://yhetil.org/guix/87tusxwncj.fsf@ambrevar.xyz> I am missing something… and I am not able to find relevant information to understand. Any pointer?
<zimoun>leoprikler: thanks for the patch about very old #23874 :-)
<cbaines>I think vagrantc explains here https://yhetil.org/guix/87eek1sdpo.fsf@yucca/
<leoprikler>It was the least I could do for this year's advent calendar :)
<cbaines>"The /proc/sys/kernel_unprivileged_userns_clone file is specific to
<cbaines>Debian and Ubuntu packaged linux kernel"
<leoprikler>Sadly, there aren't too many old bugs that I feel confident solving.
<PotentialUser-99>leoprikler: Can you simply tell me the good way?
<leoprikler>Do you have your git checkout of guix yet?
<PotentialUser-99>I know almost nothing about Guix!
<leoprikler>Well, there is `info guix`, but to abridge it a little, the git repo lives at "http://git.savannah.gnu.org/git/guix.git"
<zimoun>cbaines, thanks. I have not yet received the vagrantc answer. Time to fetch my emails. :-)
<PotentialUser-99>leoprikler: Can you tell me step by step what command to enter in the terminal? Sorry 😅️
<zimoun>leoprikler: I am sure you could close one more :-p Kidding, thank you for your patches.
<leoprikler>zimoun: I've replied to a few, currently waiting on input.
<leoprikler>PotentialUser-99: I'm not too big a fan of copying shell commands to/from IRC, but
<vagrantc>why oh why is the /proc/sys/kernel/unprivileged_userns_clone thread continuing /o\
<vagrantc>i guess we're in the post-fact era
<vagrantc>someone early on in that thread pointed out it was debian-specific, and people keep recommending to check it ... multiple times ...
<vagrantc>so i figured i'd point out in greater detail how specific it was ... but still
<leoprikler>PotentialUser-99: https://paste.gnome.org/pfjkz37gr
<lfam>vagrantc: The thread doesn't make it (adequately) clear whether or not the sysctl knob is Debian-specific, or if unprivileged user namespaces are Debian-specific
<leoprikler>that being said, I've already confirmed, that this won't work.
<zimoun>leoprikler: thanks.
<vagrantc>lfam: i guess i'm just more aware of the specificity...
<vagrantc>:)
<lfam>Yeah :)
<zimoun>vagrantc, lfam: I am confused. The commit introducing the “issue” is trying to fix #31977 on foreign distro (CentOS).
<zimoun>So it does not seem Debian-specific.
<vagrantc>zimoun: well, it's not upstream
<lfam>The fix for 31977 changed a conditional check in our code. But I think that the conditional itself is "not even wrong"
<zimoun>vagrantc: you mean included in linux-libre, right?
<vagrantc>zimoun: it is not in linux-libre, no
<vagrantc>Guix System has the feature enabled
<lfam>The string 'unprivileged_userns_clone' doesn't exist in the linux source code
<zimoun>ah, ok. Weird.
<vagrantc>or rather, doesn't have patches to disable it
<zimoun>So why Guix System says: «please set /proc/sys/kernel/unprivileged_userns_clone to "1"»
<zimoun>?
<lfam>It's likely a mistake
<zimoun>ah
<lfam>Based on a misunderstanding
<zimoun>:-)
<lfam>Now we are learning about it :)
<zimoun>hehe :-)
<zimoun>now, all makes sense (to me) :D
<vagrantc>it should only say that if the file is present
<zimoun>what is the best? Add a Debian-like patch to linux-libre allowing the thing or only fix the Guix error message?
<vagrantc>guix has the feature enabled out-of-the-box ... in Debian the file is always present, disabled by default (the patches are to make it enableable at run-time rather than kernel build time) ... not sure about CentOS
<vagrantc>but i would only have guix mention that file if it is present and set to 0
<vagrantc>feel free to quote me on any bug report; i'm not following them directly
<vagrantc>if the file is not present, it is either running a kernel that supports it out of the box, or a kernel that has it disabled and there's no reason to enable it ... or CentOS's patches are different from Debian/Ubuntu and need to detect some other way
<vagrantc>s,no reason,no way short of recompiling,
<zimoun>vagrantc, thanks. I am not sure to come with something but now the issue appears clear. :-)
<civodul>lfam: i'm pretty sure /proc/sys/kernel/unprivileged_userns_clone used to exist
<civodul>but i doesn't exist in the 5.9.10-gnu kernel i'm running
<lfam>Could be, civodul. That would explain why people are having new problems
<lfam>Idk
<lfam>We could boot an old installer to check
<vagrantc>i'm pretty sure debian has been carrying that patch for 5-10 years ... so unless guix was also carrying that patch ...
<leoprikler>PotentialUser-99: I've sent an updated patch as 45106.
<civodul>vagrantc: aaah, it could be that we only checked on Debian back then?...
<civodul>hmm
<vagrantc>apparently debian has carried the patch since 2013 ...
<civodul>i checked on a Debian derivative with 3.13.0-165-generic and it has that file
<vagrantc>similar timeframe
<civodul>i think perhaps the hint referring to that file was written by davexunit in the early days
<civodul>it could be that davexunit and the rest of us were only looking at Debian when we wanted to see what "foreign distros" are doing
<civodul>there might be a bias!
<vagrantc>oh, that's roughly the first year or two of guix?
<vagrantc>so i would guess a lot of foreign-distro users at that time
<civodul>yes, that line is from 2015
<civodul>we were young and fearless
<civodul>(we still are?)
<jeko>Good evening !
<civodul>o/
<davexunit>civodul: what file?
<jonsger>davexunit: /proc/sys/kernel/unprivileged_userns_clone I guess
<davexunit>oh I see
<davexunit>that file existed and still exists on Ubuntu
<davexunit>I'm using their latest LTS right now
<vagrantc>looking at the patch in debian, it probably originated in ubuntu
<davexunit>is something in the container code assuming it exists on all systems or something?
<lfam>There's a test that assumes it exists, IIUC: <https://bugs.gnu.org/31977>
<civodul>and there's a hint in linux-container.scm
<civodul>ah no, it's the same thing, nvm
<zimoun`>davexunit: yes, the fix of bug#31977 leads to bug#45069
<davexunit>I guess at the time I didn't realize that this was an Ubuntu patch and not a mainline kernel feature
<davexunit>but if it were just an ubuntu patch then containers wouldn't work on guix system...
<zimoun`>davexunit: see ’unprivileged-user-namespace-supported?’ in gnu/build/linux-container.scm, I guess.
<davexunit>I am
<vagrantc>well, the patch from 2013 claims it should be a temporary fix :)
<jonsger>openSUSE doesn't have it, only unprivileged_userns_apparmor_policy
<davexunit>oh, that procedure is *only* used in tests.
<davexunit>been awhile since i've looked at this.
<davexunit>I guess this procedure could fallback to another test, like calling clone with the user ns flag and seeing if it succeeds.
<zimoun`>At the end, I am happy to dig in this old bug#31977 :-) Positive collateral. :-)
<cbaines>is anyone available to set me a password on berlin?
<nckx>Morning Guix.
<zimoun`>davexunit: thanks to look at this.
<davexunit>np
<jeko>zimoun`: hey! few weeks ago you made a demo of guix.el for emacs-doctor mailing list. do you know if there is a record available ?
<nckx>Why does the userns topic refuse to die? What's wrong with my suggestion to just *try creating* one, instead of sniffing (non-Debian-specific but non-mainline) files? What'm I missing?
<nckx>(The file's actually present on my Guix System through some random patchset on the Internet. Strange times.)
<zimoun`>jeko, I do not know. I have an item to make a small email with details but… you know. :-)
<jeko>zimoun`: kind of haha
<vagrantc>nckx: so you have some random patchset on your Guix System build that doesn't behave like the Debian/Ubuntu patch?
<zimoun`>it seems you are interested, I will do an effort to do it asap. :-)
<vagrantc>nckx: it seems like trying to create a file that isn't actually used by the kernel just to make guix container work seems ... not quite right? :)
*jonsger wants to discuss about wayland packages...
<zimoun`>I have a machine with 64 cores and “guix build -m bioconductor.scm” with 300+ packages… but only 1 core is really working. Do I have misconfigured something or the guix-daemon is as lazy as I am ?
<lfam>zimoun`: What's the value of --max-jobs?
<lfam>It defaults to 1
<vagrantc>what does --cores default to?
<nckx>vagrantc: No, I mean it's the same patch (presumably). It creates /proc/sys/kernel/unprivileged_userns_clone; that never existed in Linux proper.
<zimoun`>These values need to be chosen with care, otherwise «all build users are currently in use;»
<zimoun`>thanks, it is about the default.
<lfam>You could make more build users too, of course. 10 is probably not enough for 64 cores
<nckx>vagrantc: It seems like container support was added using trial & error. ‘Oh, I had to do X to get it to work, let's throw an error if X can't be done.’
<davexunit>nckx: my proposal is to try calling clone with just the user ns flag
<davexunit>if you can fork that way and exit 0, return #t
<vagrantc>that seems better; test for the feature ...
<davexunit>when I originally wrote that procedure I thought this file was present everywhere and thus was a canonical way to test for the feature
<nckx>I'm rebuilding my kernel with NS support to do some trial & error (& hopefully get a patch out of it beyond ‘why don't we just’) but I'm on iteration 3 and losing patience. Now I had to enable CONFIG_POSIX_MQUEUE or ‘guix environment -C’ throws a fit... why?
<vagrantc>davexunit: i think it was more of a Canonical, Ltd. way ... heh. :)
<nckx>I'm sure it doesn't use POSIX message queues. Who does.
<zimoun`>lfam: yeah especially with bug#42371.
*nckx files it in the ‘file a bug, maybe, later’ box.
<davexunit>vagrantc: yes, seems so. didn't realize that back in 2015 or whenever.
*vagrantc nods
<vagrantc>and the reason it's cropping up now is someone "fixed" it by making it break on guix system?
<nckx>I think that's the gist of it.
<vagrantc>oh, wonder if this is one of the tests i had to disable for the guix builds in Debian
<jonsger>is it possible to copy a file from an input?
<nckx>Yes. But your question is quite broad.
<jonsger>nckx: so how would I copy bin/foo from an input to the output of a new package?
<jonsger>where bin/foo is just a wrapper script not an actual binary
<lfam>I wonder, what would be the easiest way to send a "failing test suite reproducer" to an upstream project?
<nckx>jonsger: (copy-file ...) or its variant (install-file ...) + (assoc-ref inputs "foo").
<nckx>(install-file (string-append (assoc-ref inputs "grep") "/bin/grep") (string-append (assoc-ref outputs "out") "/bin")); something like that.
<nckx>Wrapper scripts created with wrap-program should be self-contained (no relative paths) so it should just work.
<nckx>If someone else wrote the wrapper, you might have to get out the substitute* cannon.
<jonsger>oke, thx
<jeko>Day 3… I still can't figure out why guix deploy can't connect to the target. 😭️
<nckx>jeko: I've only used guix offload, not guix deploy, but my first step is always checking whether ‘sudo -i ssh <remote user>@host’ works. If it prompts you interactively for anything, that was the/a problem.
<jeko>nckx: i'm going to try that right now !
<nckx>I don't have anything to deploy to or I'd have more useful suggestions :)
*nckx guix deploys guix to their laptop running guix, because system reconfigure is too boring & reliable.
<jeko>nckx: asking for password is the king of interactive prompts you are talking about ?
<jeko>haha!
<jeko>kind*
<nckx>Hm, no. More things like populating (root's) known_hosts, which Guix doesn't do by default but does rely on.
<nckx>I guess you could try explicity passing -i <identity file> to skip the password prompt, and maybe trying without sudo -i (if deploy doesn't run as root like offloading does).
<nckx>jeko: It was just a wild sugguesstion. What happens when deployment fails? Any error message?
<jeko>nckx: the only thing I get is "guix deploy: error: SSH connection to 'yournextmeal.tech' failed: Connexion refusée" not much verbose
<jeko>I successfuly deployed as a regular user in the past
<nckx>jeko: And you've configured your machine-ssh-configuration with (port 2222), not 22? (Yes, I peeked.)
<nckx>jeko: And now you're deploying as...?
<jeko>yep, I can easily "ssh root@yournextmeal.tech -p 2222 -i ~/.ssh/id_rsa.pub"
<jeko>I am still trying to deploy as a regular user I mean doing `$ guix deploy …` (not # guix deploy …)
<nckx>You don't have any custom cypher suite settings or anything that could interfere with Guix's slightly-less-capable-than-OpenSSH-no-it's-not-OpenSSH libssh client?
<nckx>jeko: That should work.
<jeko>I remember having installed openssh-server and then it felt not working
<nckx>jeko: I recommend sending a bug report to bug-guix at gnu dot org if you haven't done so already.
<nckx>I'd love to help but can't do much.
<nckx>A quick test deploying to a VM here works.
<jeko>could you share your config file ?
<nckx>Uhm, I just deleted it, but it was just a shameful copy-paste from the info manual.
<jeko>oh ok I will try that
<nckx>Be sure to include your configuration file if you file a bug. If you redact it, try to do so in a way that keeps it working without modifications.
<nckx>Then I'll try to reproduce that.
*nckx → 😴
<jeko>sure, thank you for your help! good night !