IRC channel logs

<podiki[m]>sneek: later tell nckx seems the container can't read the appimage it mounts, but you can read it outside or in a new container....not sure what is wrong but almost there

<cumunculus>Where do I learn guile scheme?

<podiki[m]>cumunculus: the cookbook has https://guix.gnu.org/en/cookbook/en/html_node/A-Scheme-Crash-Course.html as a starting point and more references at the end

<podiki[m]>scheme primer being a new one

<cumunculus>I don't like the scheme primer, as it seems to have a lot of hidden, out of order pedagogy going on

<cumunculus>this crash course seems much better; thank you

<podiki[m]>welcome

<lechner>podiki[m] / is the EPERM related to setuid?

<podiki[m]>just guessing now, but I think the appimage first sees if it can just mount, when that doesn't work it uses fusermount

<podiki[m]>i've gotten that to work from the container now, using the wrapper I linked to

<podiki[m]>but somehow in that container you can't read the mounted appimage; you can outside or in another container, no idea why

<podiki[m]>(it mounts to /tmp/.mount_Appimagename-withrandomstuff)

<lechner>podiki[m] / is the fusermount called to ensure unmounting after a mount failure?

<podiki[m]>that's just my guess. strace shows a mount() call then tries fusermount

<lechner>it's not fusermount -u?

<lechner>maybe mount fails because you are not in the 'fuse' group?

<lechner>i am not sure i am making any sense

<podiki[m]>fusermount -o ro,nosuid,nodev and so on, with the appimage. the key thing I was missing in the wrapper was some env for the FD

<podiki[m]>well it does mount now, via fusermount

<lechner>yeah, thats a mounting call.

<lechner>the latter is setuid

<lechner>so it's working, after all?

<podiki[m]>so I think that is all expected now, just don't understand why the container which mounts the appimage can't actually see it where it is mounted

<podiki[m]>well if I open a second container I can then run the mounted appimage (just like doing extract-and-run but in two steps and it is mounted)

<podiki[m]>the mounting works yes; just not visible in the container that does the mounting

<zacchae->My PureOS install broke (can't launch DE from GDM). Trying to bootstrap guix install from tty in PureOS. I want to inherit from an OS def in another file. Is there a (load-file ...) equivalent for guile?

<zacchae->C-s load- and eval- come up empty in the guile library info page

<zacchae->I know I've seen someone do similar. Is there some other info page I should be looking at?

<lechner>podiki[m] / okay, that doesn't really sound like a FUSE issue anymore

<podiki[m]>lechner: nope. something with the container setup probably

<podiki[m]>I see something in the strace about a bad file descriptor, but no idea

<lechner>podiki[m] / FUSE uses two file descriptors per open file (at least for Gocryptfs). that causes me to run out unless I modify the system limits. Do you have to make the second file descriptor available to the container (if that's possible)?

<podiki[m]>is that the pam open file limit? I have that set very high (useful for wine)

<podiki[m]>what do you mean second file descriptor?

<lechner>podiki[m] / it is, but i don't think that's your issue here.

<lechner>don't you have to make resources like files available explicitly in the container?

<podiki[m]>yes

<podiki[m]>you think it has a file limit per container and that mounting eats them all up?

<lechner>no, i do not think you are hitting the limit at all.

<lechner>i think that fuse issues a second file descriptor that somehow may not be accessible in the container

<lechner>it's a wild guess, though

<podiki[m]>hmm

<lechner>i might see how our version of FUSE or later versions operate with containers.

<lechner>but i also know very little about containers

<podiki[m]>but outside of the container or a different container, it can reaad it (but I guess then it just looks like a regular file system)

<lechner>right

<lechner>how did the second container find it?

<podiki[m]>well it is then just mounted in /tmp looks regular to me

<podiki[m]>but the container that does the mounting sees an empty directory

<lechner>right

<lechner>it could also be a matter of timing. did you open the second container later?

<podiki[m]>ah you are on to something

<podiki[m]>a container opened before the mounting also just sees an empty directory created

<podiki[m]>something the container needs access to? or because of how the mounts are setup creating a container?

<lechner>my son just read that out loud. thanks for making me look good!

<lechner>i am not sure

<podiki[m]>haha I live to serve

<lechner>what's happening in /tmp

<lechner>please?

<lechner>what is being mounted, and where please?

<lechner>either way, this will be an easy patch for the container upstream

<podiki[m]>a directory is created where the app image is mounted on; the directory is .mount_<part of the appimage name with random charcters>

<podiki[m]>but /tmp is also where the guix container file system is made

<podiki[m]>oh so I am using --share=/tmp but that maybe is not a good idea. without that though fuse won't mount in the countainer

<lechner>i think you have to --share=/tmp

<podiki[m]>fusermount: failed to access mountpoint /tmp/.mount_GVim-v7nJpQt: No such file or directory

<lechner>you ran it manually?

<podiki[m]>and Unable to read struct signalfd_siginfo: Bad file descriptor

<podiki[m]>ACTION had better finally eat

<podiki[m]>will check in later, but I think you've gotten us towards the root, something with guix containers, /tmp, and fuse

<lechner>please enjoy your meal!

<podiki[m]>no, I ran the appimage which tries to use fusermount (I have a wrapper so it can call out to the host; lookup flatpak-spawn)

<lechner>no what?

<graywolf>Hi :) When I follow the steps of "guix pull; guix package -u" the second command tells me to consider running "guix pull; guix package -u". I've tried twice now and the warning does not seem to go away. Is that expected?

<graywolf>Also, second question, it seems I need to run "guix pull" under each user that uses the guix command? So I need to run it under at least root and my regular user, is that correct?

<lechner>podiki[m] / sorry, i understand now

<lechner>graywolf / you are correct, although in most setups you can get around the pulling as root part by using sudo or guix deploy

<lechner>the point is that everyone can use different versions of guix, with different channels!

<lechner>as for the warning, i am not sure. i use guix home

<graywolf>lechner: Yeah that sounds cool, just wanted to make sure I understood the tutorial right.

<graywolf>Oh, "hash guix" makes the warning goes away. This will get some getting used to :)

<lechner>graywolf / your shell ran the old version of guix. that is possible because both co-exist in different absolute paths under /gnu/store/ that are the secret behind the inner workings of guix (and the secret to falling in love with it). someone else here will have to fill in on the rehashing part. it's possible that your environment variables are not set right, but i am not sure

<graywolf>lechner: Yeah I just did not get from notice "After setting PATH run `guix hash` ..." that doing "guix pull" is the same as setting the PATH.

<graywolf>I mean, it kinda makes sense, but I did not realize it.

<lechner>the warning may only happen when there is a minimum age of your guix, so the absence does not mean you are running the one from the most recent pull

<podiki[m]>lechner: any ideas on what might be going in with the container? out of my element when it comes to file descriptors and containers

<lechner>podiki[m] / i am only guessing, but it seems that the creation of the new file descriptors in the kernel is not being relayed to the appImage. there needs to be some rescan of /tmp or maybe a reassignment of ownership of those file descriptors to the appImage inside the container. by default, FUSE does not grant access to the mounted files to anyone other than to whomever mounted them

<lechner>podiki[m] / in a pinch, i might modify the fuse config on the host system (and maybe also in the container) to include "user_allow_other" https://unix.stackexchange.com/a/17423

<lechner>i think one also has to modify the mount command

<lechner>to include "allow_other"

<lechner>i am not convinced that the command-line option alone, as mentioned here, is sufficient https://unix.stackexchange.com/a/618889

<lechner>podiki[m] / please also have a look at some of the potential pitfalls here https://unix.stackexchange.com/questions/37168/unable-to-use-o-allow-other-with-sshfs-option-enabled-in-fuse-conf

<podiki[m]>thanks, will look

<podiki[m]>but it is all the same user (and uid)

<lechner>yeah, i am not sure. there may also be some debugging opportunities for the kernel module https://stackoverflow.com/questions/1871830/how-to-debug-fuse-filesystem-crash-in-linux

<podiki[m]>I think it is more something with how guix containers work

<podiki[m]>(unless our fuse does something different for some reason)

<apteryx>has someone tried booting Guix System on an i.MX6 yet? I had success with our linux-libre-arm-generic kernel when using it with a buildroot image, but when booting Guix System, it fails early while running /init: https://paste.debian.net/1263384/

<unmatched-paren>morning guix :)

<apteryx>has someone managed to run Guix System on an armhf machine?

<yarl>Hello guix!

<civodul>Hello Guix!

<pat_n>I created a new package for python-ogr2osm. First attempt at packaging so some feedback would be nice. File at: https://paste.debian.net/1263395

<sepi>I'm trying to get a guix development env going in order to test my newly packaged wordpress package in my system config. For this I cloned the guix repo, bootstrapped and configured it in a guix environment and now try to ./pre-inst-env guix build hello. I get the following error: /pre-inst-env: line 55: exec: guix: cannot execute: Is a directory

<sepi>any ideas if this makes sense and why the error comes up?

<sneek>Yey! zamfofex is back!!

<zamfofex>sneek: 🎉 🎉 botsnack

<sneek>:)

<civodul>sepi: hi! did you run ./bootstrap etc. in the checkout, as per https://guix.gnu.org/manual/devel/en/html_node/Running-Guix-Before-It-Is-Installed.html ?

<civodul>or rather https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html

<nckx>sepi: You mention configure, but not ‘make’. Did you run the latter? If so, does scripts/guix exist?

<sneek>nckx, you have 2 messages!

<sneek>nckx, podiki[m] says: upon better looking at the strace, before fusermount is a mount call and EPERM; not sure the approach to work around that

<sneek>nckx, podiki[m] says: nevermind, a better wrapper gets me further, I think it mounts but then doesn't run the actual program for unknown reasons (file not found) https://github.com/flathub/com.borgbase.Vorta/blob/master/dependencies/fusermount-wrapper.sh

<sepi>nckx: nope, I'll try make :)

<mrvdb>I am getting an error on guix pull, "... `/gnu/store/5iz8...-guix-package-cache.drv' failed to produce output path `/gnu/store/ya80...-guix-package-cache', log is here: https://dpaste.org/TLFAP Any ideas on where to look ?

<apteryx>would someone have an idea about how to go to debug the Guix System init that crashes on early boot? https://paste.debian.net/1263384

<apteryx>perhaps I can boot on a system that works for now, and try to run Guix's boot script?

<apteryx>(on that ARM board)

<civodul>apteryx: hi! you can try adding "gnu.repl" on the kernel command line

<civodul>mrvdb: hi! hmm looks like a bug related to the linux-libre package

<civodul>ACTION tries "guix time-machine -- describe"

<mrvdb>ACTION tries that time-machine thing as well

<civodul>according to https://ci.guix.gnu.org/jobset/master?border-high=25887 it broke between 705dc94 and dfc6957

<civodul>ah

<reyman>hi guix!

<civodul>apteryx: that points to dfc6957a5af7d179d4618eb19d4f555c519bc6f2, ideas?

<reyman>i have something that compile for my deno package in rust, but the phase "package" of cargo-build-system fail saying "invalid inclusion of reserved file name Cargo.toml.orig in package source"

<reyman>any idea of the problem ?

<civodul>it's the use of 'local-file' + the fact that 'kernel-config' is now called eagerly

<reyman>is there some option to give to cargo build system to remove this file ?

<civodul>anyway, i'm not a firefighter

<civodul>mrvdb: "guix time-machine -- describe" works for me though, for f49682a09e081789edb4dc3f65c35e9d800a702b

<civodul>so not sure what happened

<apteryx>what is broken? I've seen some local-file problem once after the change, but it disappeared

<mrvdb>civodul: i should mention i am on powerpc64le

<civodul>ah

<apteryx>I think it was triggered when I ran something like 'guix shell --system=armhf-linux -D linux-libre', but that now works

<apteryx>if you have a reproducer, I can look

<civodul>maybe first revert the offending commit?

<apteryx>oh, the master evaluations on the CI

<apteryx>ACTION would like to understand exactly what is broken first

<civodul>?

<apteryx>'guix pull' has been broken since?

<civodul>not on x86_64 apparently

<civodul>but it's quite clear that ci.guix has been unhappy for a couple of days

<taoqy>hello

<apteryx>the main change that I see is the introduction of local-file

<apteryx>previously the bare source file would be passed as an input, and that somehow got turned into a store file

<apteryx>the configuration-file call both happened at the top level

<apteryx>ah, perhaps the call is delayed when used as an input

<apteryx>not sure how to mimick that when it's used directly as a gexp

<apteryx>mrvdb: I reverted commit dfc6957a5af7d179d4618eb19d4f555c519bc6f2; could you try to pull again to see if it now works?

<apteryx>civodul: re gnu.repl, good idea! I somehow thought if the init failed that wouldn't run, but it replaces the init, right?

<mrvdb>apteryx: pulling now

<apteryx>perhaps a sanity check I could do is build a qcow2 image of the armhf-linux OS and see if QEMU is happy with it

<civodul>apteryx: /init in the initrd is a Guile program that calls 'boot-system'

<civodul>and boot-system honors "gnu.repl"

<apteryx>I had forgotten QEMU can't emulate the zillion of ARM boards simply; it needs a machine definition

<apteryx>civodul: even with gnu.repl I still get the kernel panic, eh

<civodul>so maybe /init is not even invoked?

<civodul>or maybe there's no enough RAM?

<civodul>*not

<apteryx>normally there's 2 GiB of RAM available to use

<civodul>ok, that's enough RAM :-)

<civodul>is the initrd a valid gzipped cpio archive with "/init" in it?

<devmsv>apteryx: I'm having exact same problem as mrvdb after guix pull on debian runningn in a raspberry (arm64) log here: https://paste.debian.net/1263433/ I'm retrying guix pull again its going to take some time but will report if it works or not

<apteryx>looks like this: https://paste.debian.net/1263435/

<apteryx>I was testing with the stock kernel of the board to make sure it's not the kernel itself

<apteryx>civodul: according to file, initird.cpio.gz is of the right type: https://paste.debian.net/1263437/

<civodul>it's gzipped, but is it a valid gzipped cpio archive with "/init" in it?

<civodul>if it was built through Guix, then it is

<civodul>but you mentioned you wanted to try other things

<apteryx>yes it was built by 'guix system image' or 'guix system init'

<civodul>ah ok, so it should be fine

<civodul>actually you get the libgc warnings, so at least Guile is started

<apteryx>booting that same kernel but without an initrd straight into a buildroot image, it works, so the kernel + dtb is known good

<civodul>now if it stops before command-line parsing, then there's very little happening

<civodul>Buildroot?

<civodul>ah ok

<apteryx>an alternative image build system

<civodul>yes

<apteryx>perhaps I can boot that buildroot thing, and exercise some guile loads from userspace to see if it at least runs? I had guix running on it before, so it should, but that was with Guile 3.0.7

<apteryx>I'm curious as to if others successfully run 'guix system' on an ARM board

<apteryx>Guix System, I mean

<civodul>what board is it?

<civodul>we have Guix System running on OverDrives, Honeycombs, and several others

<apteryx>it's a Technologic System TS-7970 board

<civodul>ok, never heard of that one, but then again i know little about ARM boards

<apteryx>it looks like: https://www.embeddedts.com/products/TS-7970, has an ARM Cortex A9 CPU (i.MX6)

<civodul>perhaps you take the generated initrd, unpack it, throw pk calls before the boot-system call, repack it, and boot that?

<civodul>i don't see how it could fail before boot-system is even called

<civodul>but that way you'll know

<apteryx>civodul: that's some idea! thanks

<mrvdb>apteryx: pull works fine now after the revert.

<apteryx>good to know, thanks for the heads-up!

<mrvdb>thanks for your time

<apteryx>civodul: actually sounds easier to add these pk in the source and rebuild the image :-)

<civodul>:-)

<apteryx>I'm happy to see that going forward the ARM boards will standardize the boot process with u-boot being able to handle UEFI (thus bootloader-grub-efi will do).

<nckx>podiki[m]: Is ‘Portal call failed: The name org.freedesktop.Flatpak was not provided by any .service files’ something you've addressed? I added both the portal and the xdg-utils to my system profile, which is needed for #59825, but still get this error.

<nckx>(I mean, xdg-utils probably isn't needed for #59825, but I didn't test without it.)

<podiki[m]>nckx: for the portal you need xdg-desktop-portal-gtk (for X only? not sure) or -wlr (wayland, but I have no experience there)

<podiki[m]>at least the -gtk variant will propagate xdg-desktop-portal if I remember, as installing x-d-p on its own doesn't do much/anything

<podiki[m]>seems any container made before the appimage is mounted by fuse will only see an empty directory, any idea why? i do indeed get a container to mount the appimage though, it just sees nothing where it mounted it

<nckx>I'm using Wayland, maybe that's the deal.

<nckx>However, I am running Xwayland.

<podiki[m]>I don't know if there's any additional setup there for portals, should need the -wlr variant, not sure about -gtk

<nckx>ACTION reconfigures with s/-gtk/-wlr/

<podiki[m]>I also have the portal just in a regular profile, though I need to add xdg_config_dirs manually

<podiki[m]>any thoughts on why a container can't see a newly mounted directory? I'll have to try with some other mount from outside the container for comparison

<podiki[m]>nckx: btw I see the -wlr readme has some notes about env in sway

<podiki[m]>on a foreign distro: mounting an appimage on host side the container can read the directory. hrm.

<podiki[m]>maybe wayland needs both -gtk and -wlr? I'm not sure, what each provides

<nckx>Eh, same error :-/

<civodul>no Guix stand at FOSDEM it seems: https://fosdem.org/2023/news/2022-12-08-accepted-stands-fosdem-2023/

<podiki[m]>nckx: what is $XDG_DESKTOP_PORTAL_DIR for you?

<mirai>is it possible to adjust the permissions for user-account directories?

<mirai>even with chmod, they seem to reset after a reboot

<nckx>sneek: later tell mirai: What's the significance of ‘even’ here? Or am I reading too much into that? You could write a system service to chmod them afterwards.

<sneek>Will do.

<nckx>sneek: Go on. Tell 'em.

<nckx>ACTION pokes sneek with a botsnack.

<nckx>Guix deliberately defers to services to change the permissions from the defaults.

<mirai>by even I mean that I did a chmod on the directory before rebooting

<sneek>mirai, you have 1 message!

<sneek>mirai, nckx says: What's the significance of ‘even’ here? Or am I reading too much into that? You could write a system service to chmod them afterwards.

<mirai>and it reverted to what it was (rwx-------)

<nckx>mirai: But how else would you change permissions?

<mirai>uhhh, maybe I didn't phrase it correctly

<nckx>I just wanted to make sure I wasn't misunderstanding you.

<mirai>I meant to say that the directory permission changes for user home directories aren't permanent

<nckx>mirai: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/activation.scm#n204

<nckx>Nope, they aren't.

<nckx>You'll need a separate service (no upstream changes required) or to extend the user-account record to contain home-directory-mode or something (upstream changes & discussion required).

<nckx>podiki[m]: /gnu/store/2rhv5zmkws5yfd1scps38ssilzm999y6-profile/share/xdg-desktop-portal/portals

<nckx>Side bug: there's no README in the xdg-desktop-portal-wlr package; I had to ‘guix build --source’ it :-/

<civodul>apteryx: just noticed this patch for the linux-libre issue: https://issues.guix.gnu.org/59913

<apteryx>oh! well done to Pierre!

<apteryx>so we could revert the revert and apply the fix.

<civodul>could be! i haven't reviewed it

<podiki[m]>nckx: but the env variable was set to just that one directory then? just checking since I've had similar errors that you reported when that was being set incorrectly (I fixed the packages, just checking)

<nckx>That is the full and exact value, yes, and the directory exists (and contains gtk.portal and wlr.portal).

<nckx>No spurious duplication or anything, if that was your suspicion.

<podiki[m]>okay so that should all work. allegedly. I assume otherwise dbus does dbus stuff for you, other than portals not working

<nckx>I mean… sure, yes, but that's the hand-wavy part I can't get to work.

<nckx>ACTION waves hands at dbus again … ‘do dbus stuff’ … nope.

<nckx>To be clear, I'm borderline ignorant about dbus stuff.

<nckx>This clearly belongs in the kernel, where it belongs.

<nckx>podiki[m]: Do you think your permission error comes before or after my d-bus one?

<podiki[m]>dbus....ugh I've tried to debug before and was hopelessly lost

<nckx>It's not great.

<podiki[m]>which permission error? on my end I can get fusermount to be called from the container to the host and mount something (the appimage). but the container just sees an empty mountpoint

<nckx>Sorry, I was misremembering, it was ENOENT wasn't it.

<nckx>But with a nonstandard error string IIRC.

<podiki[m]>I wonder if this is either something with how fuse works or our containers. other containers created before the mounting also see an empty directory. ones created after or the host see stuff in the directory

<nckx>Makes sense if namespaces are inherited like I think they are.

<podiki[m]>there was EPERM from calling mount, as expected. the fusermount needed to be passed some file descriptor stuff: https://github.com/flatpak/xdg-desktop-portal/issues/695

<podiki[m]>namespaces...so once created for the container a new mount...something new namespace and not available to an already created container? (i know nothing here)

<lechner>podiki[m] / nckx / Hi, would it be worthwhile to explore the 'bind-propagation' flag to mount? https://stackoverflow.com/a/53632103

<lechner>i know it's not the same problem

<nckx>That's some weird Docker branding of the --make-FOO option to mount, not a mount flag in itself.

<nckx>I recognise some of those as MS_ flags.

<nckx>What does it do, exactly, leaving off any Docker® branding, please?

<lechner>i'm not sure. we are tapping in the dark

<podiki[m]>I think we did have some fixes recently with recursive bindmounts (or something like that?) which fixed e.g. --share=/dev not working before (you had to do individual directories from dev)

<nckx>Yes.

<nckx>We could certainly throw random MS_SHARED at everything and see what sticks, but there's some danger if we don't fully understand why. Since, you know, contain-ers.

<lechner>podiki[m] / Hi, can you run 'mkdir' on the directory you cannot see inside the affected container? https://github.com/GoogleCloudPlatform/gcsfuse/blob/master/docs/semantics.md#implicit-directories

<unmatched-paren>afternoon guix :)

<nckx>ACTION 's going to sit this one out, since their error is very different and very user space.

<nckx>Yo.

<user_oreloznog>o/

<podiki[m]>lechner: can indeed mkdir in the mountpoint, visible within the container, but not outside of the container

<podiki[m]>intrigue

<lechner>podiki[m] / you are not alone https://www.reddit.com/r/docker/comments/5psju9/docker_and_fuse_mount/

<podiki[m]>nckx: I can run commands, but I'm even out of completely random guesses at this point

<podiki[m]>nckx: how do you feel about being able (mostly) to mount from inside a container, calling out to the host? interesting? worrisome?

<podiki[m]>ah good find. so I guess it has to do with how containers are implemented with namespaces? not something particular to guix's containers

<nckx>podiki[m]: Can't say it sounds reassuring. Calling out how?

<podiki[m]>via the portal dbus service. that's how fusermount gets called on the host

<nckx>To me it's like asking ‘would it make sense to change environment variables so a change in the parent's is visible to subprocesses’. Maybe that's an extreme example, but it's how it sounds.

<nckx>Ah.

<podiki[m]>I guess the conclusion is that simply doing ./some.appimage will not work in containers pretty generally

<nckx>If the portal takes care of it, fine, I thought you were suggesting Guix provide this feature.

<podiki[m]>no, just using what others have made (flatpak people in this case). mainly I find use for the portals in calling out to the host to open a file or usually a url, so that I see it on my host browser

<podiki[m]>but in the end looks like a container won't see what it was able to mount anyway

<nckx>Consider that my opinion here might be coloured by these magical d-bus portals not actually working a whit.

<podiki[m]>what was your test case that was giving the error, was it with the appimage attempt?

<nckx>Sec.

<nckx>podiki[m]: XDG_CURRENT_DESKTOP=sway ~/guix/pre-inst-env guix shell -NCF glib:bin zlib fuse@2 xdg-desktop-portal-{gtk,wlr} flatpak-xdg-utils dbus --share=/{run,tmp} --expose=/etc/{machine-id,mtab} -E ^DISPLAY$ -E ^DBUS_SESSION_BUS_ADDRESS$ -E ^XDG_ -- /tmp/crap/crapper.sh /tmp/crap/VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage

<nckx>crapper.sh is that flatpak github thingy you posted earlier/yesterday.

<podiki[m]>I enjoy your naming scheme

<podiki[m]>a simpler case would be to run the command I had in the patch: guix shell -NC flatpak-xdg-utils --preserve='^DBUS_SESSION_BUS_ADDRESS$' -- xdg-open "<https://guix.gnu.org>"

<nckx>You should see my local branch names.

<nckx>I'm suspicious because omitting DISPLAY still gives a DISPLAY-related error.

<nckx>Which is not very modern, much Wayland.

<nckx>podiki[m]: No, that works fine.

<nckx>I think the <> are bogus but it worked fine when I tested it earlier today.

<nckx>Let me dig up the command…

<podiki[m]>okay so then portals do work for you. I don't include any of the portals in the container though, that should all be on the host as the container should call dbus

<nckx>Here we go: guix shell -NC flatpak-xdg-utils --preserve='^DBUS_SESSION_BUS_ADDRESS$' --expose=/etc/machine-id -E DISPLAY dbus -- xdg-open "https://guix.gnu.org"

<nckx>The <>s are bogus and I have to add some stuff, so it works, just very unreliably & fragile.

<nckx>podiki[m]: With or without portals in the container doesn't make a difference.

<podiki[m]>oh the <>s for the url? I think that's just an artifact of my copy/pasting between the issues front end and here

<nckx>The command above is the opposite of a minimal test case, I'm just throwing stuff in the tub to see what floats.

<podiki[m]>yeah, you should see my various guix shell/container commands in my history

<nckx>Dead rats, toasters, … don't take it too seriously.

<podiki[m]>I add everything I can think of and sometimes remember to remove things later

<nckx>(The rats were alive until the toaster, now they float, which is actually how debugging this feels.)

<nckx>podiki[m]: That's what I assumed DISPLAY was, until I tried removing it :-/ Sigh.

<podiki[m]>here is a not-quite-minimal example that should run, if you could test

<podiki[m]>guix shell -CNFD ungoogled-chromium glib:bin gcc:lib --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --preserve='^DBUS_' --share=$XAUTHORITY --share=/sys/dev --share=/sys/devices --share=/tmp --expose=/dev/dri --expose=/var/run/dbus -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage --appimage-extract-and-run

<nckx>Happy to.

<nckx>Ah, cheating, but OK, can do.

<lechner>Hey, both of you are troopers. It will be a beautiful patch!

<nckx>podiki[m]: Any idea why you don't need to expose /etc/machine-id?

<nckx>I mean for xdg-open. The --exctract-and-run shell is still downloading toots.

<podiki[m]>let me see if I remember...I did see it complain about accessing that when I was testing yesterday, but in the end it was the file descriptor env stuff that made it work

<nckx>So you're running <https://logs.guix.gnu.org/guix/2022-12-09.log#183947> with extra variable(s) set?

<nckx>--appimage-extract-and-run line sez: guix shell: error: statfs: : No such file or directory

<podiki[m]>huh. haven't seen that

<podiki[m]>my testing that got fusermount called and led to finding out this mount visibility issue was

<podiki[m]>pre-inst-env guix shell -CNF glib:bin gcc:lib --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --preserve='^DBUS_' --share=$XAUTHORITY --share=/sys/dev --share=/sys/devices --share=/tmp --expose=/dev --share=/var/run fuse@2 flatpak-xdg-utils strace --preserve='^XDG_RUNTIME_DIR$' --share=/run

<nckx>We're both exposing a perverse amount of local state to our ‘containers’ at this point.

<podiki[m]>lechner: thanks for finding good info. it does seem this runs into how containers are ultimately implemented though. meaning mounting isn't visible to the container that does it and wants to use it :(

<nckx>So if your PC was kissed by a unicorn, I have no hope of reproducing that.

<podiki[m]>nckx: haha yes, it is more holes than cheese at this point

<fiesh>is there a way to make paypal work with icedove on the fly?

<nckx>I love how we both keep getting different errors :)

<lagash>I'm trying to get this compile-ffi script working (see https://www.nongnu.org/nyacc/ffi-help.html). I ran `guix install nyacc` and then `guix shell nyacc`, but `guild compile-ffi` says it's an unknown script - is this a known problem? I searched the logs and it seemed as though it was fixed.

<podiki[m]>nckx: well I better send out the examples for the FHS container blog post to get more testing then

<fiesh>I'm literally stuck in a family emergency, need to pay this ESTA fee for the US application, cannot use a different computer because I started it here, and paypal won't work with icedove

<nckx>Oof.

<fiesh>yes :-(

<podiki[m]>nckxand lechner: thanks for playing with containers. Have to run now but let me get back to the bigger picture of FHS container examples for testing. Coming to -devel later

<nckx>Did you try disabling all the extensions it comes with? Maybe also disable all ‘resistFingerprinting’ options in about:config.

<nckx>Those are just desparate guesses, not quality support sorry. I use Firefox…

<lechner>fiesh / how much money?

<nckx>Yeah, I was considering that. :)

<fiesh>lechner: ?? it's just $21, or what do you mean?

<nckx>Social solutions to technical problems.

<lechner>fiesh / my paypal works fine

<fiesh>nckx: hmm thanks, tried that, still won't work

<nckx>fiesh: I don't know if it's what lechner means, but I'd be willing to pay that for you if it's really vital.

<fiesh>lechner: that's so strange

<nckx>I see it is.

<lechner>fiesh / i am offering

<fiesh>thanks for the offer guys, I can't see how to do that, it redirects me directly to my own paypal login etc.

<lagash>I can't get `guild compile-ffi` to work on Debian Stable, even.

<lechner>does it open a new browser window?

<fiesh>yes

<nckx>Could you copy the link?

<lechner>lagash / compile-ffi works fine

<fiesh>let me see, I'm stuck in an error data retrieval thingy

<nckx>podiki[m]: Happy to. Maybe some day I'll win.

<fiesh>if I can copy it to a different computer, I could use my ubuntu box and do it there

<lechner>lagash / what error do you see?

<fiesh>ok that's a great idea, I'll try that

<lagash>lechner: guild: unknown script "compile-ffi"

<lechner>lagash / your paths are not set right. let me try to remember what i did during testing of https://codeberg.org/lechner/guile-pam

<nckx>It might be a European thing, but apparently there's a dodgy business named ‘IceCat’ that makes any ‘icecat paypal’ search useless.

<lagash>lechner: how do I find where compile-ffi.scm even is?

<lechner>lagash / it's in nyacc https://codeberg.org/lechner/guile-pam/src/branch/history/guix.scm#L61

<lagash>That's precisely what I installed..

<lechner>lagash / in guix, your environment also has to find it

<unmatched-paren>lagash: try ``source ~/.guix-profile/etc/profile''

<fiesh>lechner, nckx: thanks for the hint with copying the paypal link, this worked, was able to pay -- thanks guys, really really appreciated

<unmatched-paren>agh, too late

<lagash>lechner: `guix shell nyacc` ? I'm using GuixSD

<nckx>fiesh: Phew! 🎉

<unmatched-paren>lagash: it's called "Guix System" now btw, and has been for several years :)

<lechner>lagash / we are using the same setup

<lechner>lagash / do you use guix home or emacs?

<lagash>lechner: I'm using Guix System in a VM, Emacs on the host, and no, I don't think I have Guix home..

<lechner>lagash / i had your issue once and need a moment to relive that traume

<lagash>How do I find where in /gnu/store/ is my installed nyacc package?

<unmatched-paren>lagash: source your profile

<unmatched-paren>``source ~/.guix-profile/etc/profile''

<lechner>lagash / any of them will do ls /gnu/store/*-nyacc*

<unmatched-paren>lagash: ``guix build nyacc''

<lechner>lagash / you should listen to unmatched-paren. i am a renegade

<lagash>weird, I literally just installed nyacc and now I'm doing it again.. says dependencies or whatnot changed..?

<nckx>There's a bug where Guix sometimes prints that followed by ‘lol just kidding nothing to do’.

<lagash>April Fools?

<lechner>lagash / more like december

<lechner>lagash / my problem went away after i added those lines to configure.ac https://codeberg.org/lechner/guile-pam/src/commit/65fef0971761f5b70191350884429da5bddcb4fa/configure.ac#L49-L52

<lechner>i cannot remember my manual fix before that, but it was likely adding the nyacc/scm folder (or similar) to GUILE_LOAD_PATH

<unmatched-paren>Silly lechner. We modified everything near you that can display the date to show 2022-12-09. Happy April Fools' Day.

<lechner>sneaky!

<lechner>i tend to live in my own universe

<lagash>The script is at /gnu/store/6m97b6a0m618pk7llyhczc584i2v53mi-nyacc-1.07.4/share/guile/site/3.0/scripts/compile-ffi.scm but still doesn't show up for guild

<lechner>lagash / the macros are described here https://www.gnu.org/software/guile/manual/html_node/Autoconf-Macros.html#Autoconf-Macros

<unmatched-paren>lagash: again, please try sourcing the profile

<lagash>unmatched-paren: I just did that, again, and no good

<unmatched-paren>lagash: oh :(

<lechner>unmatched-paren / they are using guix shell

<unmatched-paren>ahh

<unmatched-paren>aha! i think i know the problem

<unmatched-paren>lagash: try changing ``guix shell nyacc'' to ``guix shell guile nyacc''

<lagash>unmatched-paren: aha! that worked!

<lechner>much better than GUILE_LOAD_PATH=/gnu/store/6m97b6a0m618pk7llyhczc584i2v53mi-nyacc-1.07.4/share/guile/site/3.0/scripts/compile-ffi.scm:$GUILE_LOAD_PATH guild ffi-compile ...

<unmatched-paren>so, the reason you need to add guile is because guile provides a guix "search path"

<lagash>Figures as much

<lechner>lagash / Hi, as an FFI afficionado, may I ask what you are working on, please?

<unmatched-paren>a search path specifies a path and a variable to add it to when a package adding that path is installed

<lagash>lechner: trying to figure out how to do FFI bindings in Guile :)

<unmatched-paren>guile provides search paths for GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH that correspond to share/guile/site/3.0 and lib/guile/3.0/site-ccache respectively

<lagash>I'm following this guide here: https://oscarnajera.com/2020/12/managing-my-email-with-guile-interfacing-to-notmuchs-c-library/

<lechner>lagash / i can't wait to see you work!

<lechner>lagash / you are almost there. it's downhill from here on out, except all your preprocessor defines are in a funky alist https://codeberg.org/lechner/guile-pam/src/commit/65fef0971761f5b70191350884429da5bddcb4fa/scm/pam/entry-point.scm#L45

<lagash>Hmmm. It's complaining it can't find notmuch.h - how do I provide the path?

<lechner>lagash / do you know which package ships that header?

<lagash>lechner: notmuch, naturally

<lechner>lagash / please add it to 'guix shell'

<lagash>What command do I run to find, in a guix shell, where its directory is?

<lagash>And yes, I already added it.

<lechner>still not working?

<lagash>Yes, it still cannot find it.

<lechner>i use autoconf macros to find headers and am fuzzy on direct specifications of -I in Guix. unmatched-paren ?

<lechner>lagash / in a pinch -I /gnu/store/DEADBEEF-notmuch/usr/include/ ...

<unmatched-paren>lagash: i think there might be a C_INCLUDE_PATH variable

<unmatched-paren>s/variable/search path/

<unmatched-paren>i *think*

<lagash>Yes, there's an -I argument

<unmatched-paren>indeed there is a C_INCLUDE_PATh

<lagash>But how do find the /gnu/store/*notmuch path that's currently loaded in the guix shell?

<unmatched-paren>lagash: perhaps add gcc-toolchain to your shell invocation

<unmatched-paren>then you might not need -I

<lagash>Hmmm. I'll try that. My net speeds are a bit slow today, though..

<lechner>even with (build-system gnu-build-system) i think i still need pkg-config to find my headers https://codeberg.org/lechner/guile-pam/src/branch/history/configure.ac#L47

<lechner>but i am not sure'

<unmatched-paren>yeah pkg-config is probably the wisest solution if you're actually writing a proper library

<lagash>OK it found it!

<unmatched-paren>yey

<lechner>lagash / how did you do it, please?

<lagash>lechner: just added gcc-toolchain ^^

<lechner>great! did i already say to listen to unmatched-paren ?

<lagash>You did. Apparently notmuch has a test corpus...

<PotentialUser-71>Hello everyone! I tried to install GNU Guix, but came across the following error: https://issues.guix.gnu.org/44872

<PotentialUser-71>Is that expected?

<lechner>PotentialUser-71 / Hi and welcome! That looks like an invalid disk stanza. can you share your configuration?

<lechner>pastebin please

<PotentialUser-71>Ah, I fixed it myself already. The issue was that the installer detected both the /boot/efi from my harddrive and the install USB

<PotentialUser-71>But to be it sounded like that was already fixed - hence my question whether it is expected

<PotentialUser-71>In other words - should I try to install GNU Guix Standard (1.3.0) or latest?

<lechner>PotentialUser-71 / latest is better and 1.4.0 has a release candidate, but it really does not matter that much. just run a guix pull at your earliest opportunity after the installation. the preferred syntax in modern config files has changed, so you may see a few warnings along the way.

<lechner>PotentialUser-71 / what is your equipment, please?

<lechner>I am not sure if the warning has been fixed

<PotentialUser-71>lechner Laptop: Dell P92G001

<lechner>PotentialUser-71 / i think you are good either way. please keep us updated about how much you like Guix (or not)

<PotentialUser-71>@lec

<PotentialUser-71>lechner You mentioned that 1.4.0 has a release candidate - is it already public?

<PotentialUser-71>On the website I can only find 1.3.0 (https://guix.gnu.org/en/download/), and latest doesn't seem to have a .sig to verify it with

<euandreh>PotentialUser-71: there are some threads in the mailing list by civodul

<euandreh>They're tags on the Git repository, but with no public release yet

<euandreh>I mean they're public, but not "official" releases

<PotentialUser-71>I see, thanks!

<euandreh>PotentialUser-71: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00000.html

<lechner>PotentialUser-71 / https://lists.nongnu.org/archive/html/guix-devel/2022-12/msg00000.html

<lechner>whoops, same thing!

<PotentialUser-71>Well then, let me try 1.4.0 ;)

<euandreh>lechner: I had faster keyboard fingers XD

<lechner>euandreh / thanks for that. i can't believe we don't publish the isos

<PotentialUser-71>It is kind of refreshing to install something different than Arch, Ubuntu and Manjaro

<PotentialUser-71>Feels nostalgic

<euandreh>well, the jump from ubuntu/arch to guix is quite a big one :)

<euandreh>that''d be a lot of refreshness

<PotentialUser-71>It started with a friend telling me play around with emacs and recommending me https://youtube.com/@SystemCrafters

<PotentialUser-71>I am curious whether a FSF approved GNU distro would actually be usable

<PotentialUser-71>which sounds kinda mean

<euandreh>for me personally its been good

<PotentialUser-71>I don't plan on doing crazy stuff with it; as long as WiFi works + I can use Firefox, Anki and some IDEs (and their associated tools), I am happy

<Kolev>PotentialUser-71: it works for all that

<PotentialUser-71>Well let's hope

<Kolev>I use special wifi card tho

<PotentialUser-71>Anki on Fedora was a bigger pain then it should have been; and even Arch had some nasty issues with my WiFi

<lechner>PotentialUser-71 / i used Debian for twenty-five years and switched cold turkey on some day in April. the first week was terrible but i became a huge fan of this channel

<PotentialUser-71>Kolev I think the next time I buy a system I will try to buy hw with good open source support

<PotentialUser-71>The only issue that currently presents itself is nvidia and cuda

<lechner>it's all emacs here. we don't use graphics

<lechner>just kidding

<PotentialUser-71>can emacs accelerate matrix multiplications? :p

<lechner>one day, i am sure

<euandreh>Sure it can: M-x el--ido-matrix-multiplication-accel-minibuffer

<PotentialUser-71>of course it can

<PotentialUser-71>Well, what I already like about 1.4.0 is that it tells me that my WiFi card is unsupported

<apteryx>rekado: hi! have you ever seen a kernel panic at the time of loading a Guix-produced initrd on one of your ARM boards?

<apteryx>correction: at the time of running the init script of the initrd

<PotentialUser-71>"Intel Corporation Cannon Point-LP CNVi" - "Unfortunately, it means those devices will not be usable". Not usable at all, or not usable without proprietary drivers?

<lechner>PotentialUser-71 / what is the PCI ID? https://linux-hardware.org/index.php?id=pci:8086-9df0-8086-0034

<PotentialUser-71>I'll check as soon as it is done with the installation

<lechner>which model inspiron is it?

<PotentialUser-71>Its a Dell Vostro

<lechner>which number?

<PotentialUser-71>5481

<lispmacs[work]>do I have to be subscribed to guix-patches to send a patch to it?

<lispmacs[work]>I just sent e-mailed one but I didn't subscribe first

<lechner>you don't but it can take a few minutes

<lechner>PotentialUser-71 / your wifi may work with the 'linux' kernel, which includes proprietary blobs, instead of 'linux-libre' which is all we promote in this channel. https://linux-hardware.org/?id=pci:8086-9df0-8086-42a4

<PotentialUser-71>lechner Thanks for looking it up for me! Do you have any good references on how to switch the linux kernel (in GUIX/general)?

<lechner>PotentialUser-71 / please have a look at my config and also at the unfamiliar use-packages declaration at the very top https://codeberg.org/lechner/system-config/src/branch/history/host/lechner-desktop/operating-system.scm#L182-L184

<lechner>PotentialUser-71 / more info may be available in #nonguix

<PotentialUser-71>That's useful, thanks!

<PotentialUser-71>Out of curiosity - how would I got about choosing a system that is supported well by linux-libre?

<lilyp>PotentialUser-71: see h-node.org

<PotentialUser-71>Thanks

<PotentialUser-71>Is a channel in guix something like custom PPAs in Ubuntu?

<unmatched-paren>PotentialUser-71: sort of, yep