IRC channel logs

2021-11-24.log

back to list of logs

<podiki[m]>I'll send the patch
<jackhill>thanks! Happy eating!
*jackhill -> afk
<podiki[m]>you too!
<ArneBab>is gstreamer-gl packaged? https://gstreamer.freedesktop.org/documentation/gl/index.html?gi-language=c
<ArneBab>(I have a program here that fails due to missing libgstgl-1.0.so.0)
***spk121_ is now known as spk121
<ArneBab>why do we have -Dgl=disabled in gst-plugin-base?
<ArneBab>gst-plugins-base
<lfam>ArneBab: I think it was done in commit 738923b6e3ac85c78b1e97a9a85979495ed8ba51, as a way of keeping gst-plugins-base from depending on mesa
<lfam>Maybe mbakke can shed some light on it
<ArneBab>thank you!
<ArneBab>I created a gst-plugins-base-gl that adds it again
<podiki[m]>jackhill and any other c-u-f flatpak users: https://issues.guix.gnu.org/52068
<ArneBab>lfam: I filed a bug. I’m not sure whether it should be merged as is, but at least like this the info is out there/here.
<lfam>Okay. We'll have to figure out why it considered desirable to avoid this dependency
<lfam>Thanks for opening the discussion
<apteryx>sneek: later tell civodul re offloading, ah, indeed parsing my ~/.ssh/config is rather the job of guile-ssh, not guile-git. sorry for the thinko
<sneek>Will do.
<apteryx>lfam: I think there's a comment somewhere saying it needs investigation because it'd pull gst-plugins-bad or something
<apteryx>and that's deemed undesirable/potentially unsafe (true)
<apteryx>but given GTK 4 pulls gst-plugins-bad, already... well, hum.
<lfam>gst-plugins-bad isn't part of mesa's dependency graph
<lfam>I wonder how they would be related
<apteryx>sneek: later tell zimoun the networking seems broken in our julia 1.6.3? ./julia -> import Sockets -> Sockets.ipaddr() -> ERROR: UndefVarError: ipaddr not defined
<sneek>Will do.
<apteryx>I get this even when not in a container
<apteryx>nevermind; it works outside of 'guix shell -C ...'
<apteryx>lfam: ah, sorry if i just added noise to the conversation, but the comment I remembered is about enabling gstreamer-gl in webkitgtk; you can git grep for '-DUSE_GSTREAMER_GL=OFF' to find it
<lfam>I see how the memory would get conflated!
<apteryx>eh :-)
<apteryx>how can I get the julia debugger in a container?
<apteryx>julia> using Debugger -> ERROR: ArgumentError: Package Debugger not found in current path [...]
<apteryx>I guess it's not packaged...
*apteryx steps out of the networkless container, runs ./julia -e 'import Pkg; Pkg.add("Debugger")', then re-enters it
<apteryx>bah, still fail
<apteryx>not having much luck with this identifier-syntax hack for polkit
<bdju>I saw the swap config format changed. I tried to update mine and I get an error now saying `rename-file: No such file or directory`
<bdju>I put (swap-devices (list (swap-space (target "/dev/sda2")))) in my file
<bdju>the example in the manual used a swapfile and I think I use a swap partition on this install so that's likely part of the problem
<bdju>ah I found more examples in the manual now. I was looking at the whole system config example instead of the section on swap-space
<bdju>I changed to using a uuid and it seems to work now
<jgart> https://github.com/kitnil/dotfiles/blob/5e77a6fae23290d1627401fc2c7b1a53ea2a9b3f/bin/executable_twitch.scm#L12
<apteryx>I've run ./pre-inst-env guix system vm gnu/system/examples/desktop.tmpl on core-updates-frozen; looks cool!
<podiki[m]>sneek later tell jackhill the libostree patch was pushed, we should be all set!
<sneek>Okay.
<jackhill>podiki[m]: super work, thanks
<sneek>jackhill, you have 1 message!
<sneek>jackhill, podiki[m] says: the libostree patch was pushed, we should be all set!
<jackhill>I guess I should really get to bed. Goodnight from North Carolina!
<podiki[m]>haha same! g'night
***LispyLights is now known as Aurora_v_kosmose
<mbakke>ArneBab, lfam: no particular reason gst-plugins-base has GL disabled; I just could not get it working easily but did not spend a lot of time on it ... perhaps things have changed in the mean time :)
<user___>something's broken gnome :/
***user___ is now known as unmatched-paren
<unmatched-paren>if i reconfigure, gnome breaks
<unmatched-paren>has there been an update to it?
***unmatched-parent is now known as unmatched-paren
<jpoiret>on master?
<jpoiret>good monrning guix by the way
<unmatched-paren>yeah, on master
<jpoiret>And how is it broken? unmatched-paren
<unmatched-paren>when i login gnome just says 'there was a problem' and offers a button to log out and try again, which does not work
<unmatched-paren>this only happens after i reconfigure. obviously roll-back in grub makes it usable again
<jpoiret>alright let me try on latest master
<unmatched-paren>for some reason i can never C-M-Fx to switch to ttys
<unmatched-paren>even in the brief moment before gdm starts
<jpoiret>hmmm, GDM can block switching VTs
<unmatched-paren>what
<unmatched-paren>why would it do that
<jpoiret>i'm building a gnome system right now
<jpoiret>well, GDM can lock the screen, right? it's better if it prevents anyone from switching to an open session on another VT
<jpoiret>although by default on guix it shouldn't
<unmatched-paren>right that makes sense
<unmatched-paren>i have to go, can you please keep saying stuff as if i was here so i can just check the logs later?
***ns129 is now known as ns12
***fcw9 is now known as fcw
<jpoiret>unmatched-paren: It launches fine for me in a vm, it might be an issue with your configuration
<abrenon>good morning guix !
<ss2>good morning too!
<abrenon>thanks
<vivien>Hello :)
<jpoiret>anyone know what maxim's irc handle is? my mapping of mailing list people <-> irc handles isn't complete
<jonsger>jpoiret, apteryx: I think
<jpoiret>well if that's the case: i cannot reproduce your slim issue, I can login fine in a vm
<wingo>cbaines: is guile 3.0.7 being hard to build a guile problem or a bordeaux problem ?
<cbaines>wingo, I think it's a Guile problem, bugs #43521 and #45788 might be related (or I could be confusing different issues)
<vivien>I migrated my server to core-updates-frozen, it was rather painless.
<wingo>who are the guile maintainers, they are very irresponsible
<utis>isn't full-disk encryption with encrypted swap a common desire? might be nice to include that in the installer. also, i after making an encrypted root from the installer, i had to type my password twice.
<abrenon>utis: I guess it was once in grub and once during early boot ?
<utis>yeah
<utis>i know it can be fixed . .
<utis>just complaining about the installer :)
<abrenon>yeah, that surprized me too the first time I tried the root-encryption installation
<abrenon>I don't really know how it could be fixed though, what do you have in mind ?
<abrenon>I don't know of a way for grub to pass information to the init process that isn't readable by any process later on
<utis>i've done this in arch and void
<utis>you have to use dd to generate a random key and add it to the luks volume
<utis>then point to that file. i think there are instructions in the arch and void documentations
<utis>but i'm not sure what is specific to them
<attila_lendvai>what's the current situation with AppImage's? is there a reasonabe way to run them?
<abrenon>utis: that's a cool and clever way to do it : )
<abrenon>so it's just an init script to write to implement this method ?
<abrenon>but I don't know how they are implemented in guix
<utis>abrenon: i don't know, i haven't gotten started with guix yet
<abrenon>I'm still discovering things too
<rekado>attila_lendvai: not in general.
<rekado>I had some AppImages that worked after using patchelf, and others that made outrageous assumptions about the runtime environment, so I never managed to get them to run.
<nckx>abrenon, utis: Guix doesn't have early-boot services (yet). You can't add snippets of code to the boot process without forking & editing Guix.
<nckx>Good morning, also, Guix.
<nckx>abrenon: You can't pass information directly/securely, hence the pregenerated key-in-initramfs hack that most distroes use.
<nckx>It's gross but it works.
<zimoun>hi!
<sneek>zimoun, you have 1 message!
<sneek>zimoun, apteryx says: the networking seems broken in our julia 1.6.3? ./julia -> import Sockets -> Sockets.ipaddr() -> ERROR: UndefVarError: ipaddr not defined
<zimoun>hi!
<zimoun>apteryx: about Julia, thanks for pushing forward.
<zimoun>Now it builds on Cuirass but 2 tests randomly fail.
<zimoun>apteryx, I commented on https://github.com/JuliaLang/julia/issues/43205
<zimoun>the bug seems upstream and maybe this fix should work https://github.com/JuliaLang/julia/pull/40348/commits/728b7f449386fe0cc441f1ab1e97b33d75a0d343
<zimoun>I will try it later today.
<pseudonymous>Tried installing Geary (mail client, GTK3 and Vala). Got an error. On Ubuntu 20.04 LTS, Guix 1.3.0 sourcing /etc/profile.d/guix.sh in my shell. ( https://pastebin.com/tneYw7YT -- too long for debian paste). Any ideas ?
<pseudonymous>And on a more general note - I'm getting the sense that it's early days for GUIX, is it ? Is it normal for builds to break etc in a foreign distro setup ?
<rekado>early days? I wouldn’t say so.
<rekado>but when using it on a foreign distro you need to be careful with environment variables and global state that might mess with programs
<rekado>the pastebin is gone, so I can’t check it.
<pseudonymous>very odd, I didn't retract it. But it exceeds 150KB apparently so the debian paste link wouldn't accept it. Anywhere else to store ?
<rekado>could you just paste the relevant parts?
<nckx> https://pastebin.com/tneYw7YT — ‘This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff.’
<nckx>Be sure to tweak expiry settings if you can.
<nckx>Or don't include illegal torrent links in your error logs I guess.
<pseudonymous> http://paste.debian.net/1220649/ -- tried to trim the output. Mostly focused on removing file unpacking lines and such.
<rekado>pseudonymous: looks like geary has been broken for a while: https://ci.guix.gnu.org/search?query=geary+spec%3Amaster
<rekado>it’s just a permission error while testing
<rekado>so I guess this can easily be fixed
<guixnewcomer>Hello Everyone, I hope you all are doing great! I really love the work you guys are doing with functional and reproducible package management. I wish to to be part of it and want to try out guix. I am having a month long holiday from the Second Week of December 2021 to First Week of January 2022. So, My laptop is not needed for productivity work
<guixnewcomer>and can be left unattended except for a few hours in night. I wish to utilize this time to setup a guix system for me. I am fairly determined and have done a Linux From Scratch build and a gentoo linux install. So I can say I can read and follow the document. I am not a developer or a programmer though having taken a weekend python workshop in
<guixnewcomer>college. I have a few questions before i jump to guix: 1.) How much storage will it consume. (I have a 250GB SSD, an External HDD and USB drive to backup my data). I can spare 70-80GB for guix system easily. 2.) How much time does cyclic compilations will take if I am using Pandoc, LibreOffice, firefox, chromium, transmission and sway or i3, mpv on
<guixnewcomer>the base install(Packages from Arch Base). I can spare maybe a week and some hours on later days for compilation to finish.  My system is LG GRAM 14Z990 Ultrabook with core i5 8th gen CPU and 8 GB of RAM. I am currently running Arch Linux on it. Thanks in advance to everyone.
<rekado>guixnewcomer: if you’re using binary substitutes you generally won’t have to compile things at all.
<rekado>Guix will automatically download binaries from ci.guix.gnu.org (unless you didn’t authorize it)
<rekado>the specs looks sufficient to me
<guixnewcomer>I will love to customize the package and remove unneeded dependencies.
<rekado>I used a 250GB SSD for a long time and it’s just fine. If you remember to run ’guix gc’ once in a while you can do just fine with 80G.
<rekado>“unneeded” ey?
<rekado>you can do that with package input rewriting, but you’d end up building stuff all the time
<rekado>compiling libreoffice and chromium will each take several hours.
<guixnewcomer>I have heard distributions target multiple architectures and thus have extra dependencies. That is why i was asking.
<rekado>Guix doesn’t add dependencies that aren’t useful for the target architecture.
<guixnewcomer>I am not averse to building if it will be done in the day.
<rekado>it doesn’t try to have *minimal* packages, though.
<guixnewcomer>I don't get it what you are trying to say.
<guixnewcomer>Maybe i am confused with void and arch packaging policy. They say void splits the package whereas Arch do not so arch pull extra packages. I do not want that. I want to have packages i need.
<pseudonymous>guixnewcomer: it sounds like the difference between a binary distro (Arch, Ubuntu etc) and a source-distro like Gentoo. When you compile packages, they typically probe for libraries to figure out whether a feature should be enabled or not. Typically, you can explicitly request a feature be disabled if you want to. But all of this supposes you compile yourself. Binary distros have to make those choices for you, and so tend to enable
<pseudonymous>most features, meaning packages are a bit larger and have more dependencies. I don't know how to avoid that outside of Gentoo, for instance.
<ss2>How does one stick an inferior package to a service definition? I've tried it so far as such: https://paste.rs/zkN.
<guixnewcomer>Yeah that is my concern. Maybe i will pull in extra dependencies while compiling and the cycle of recompilation may start. That is my main fear.
<ss2>So far I've understood that usually the name of the package is put there. Is it correct that an inferior lookup returns a string?
<rekado>ss2: no, it returns an <inferior-package> value
<rekado>you look up a specification, which is a string
<guixnewcomer>I thanks for all the help. Have a nice day you all.
<nckx>ss2: Many (most?) services don't accept <inferior-package>s in place of <package>s yet. I have a patch that fixes this but it hasn't been pushed yet.
<ss2>ah, that'd be cool actually. :)
<nckx>Another niggle is that inferior packages seem to be built at evaluation time (before the <operating-system> is returned). I haven't checked yet if that's accurate (they are definitely built sooner than you'd expect) and if there's a way to avoid it.
<ss2>So I can only place a definition to a package?
<nckx>For now, yes.
<nckx>Actually, it's not most services ss2. You might be in luck. Try it.
<nckx>Only those using define-configuration gave an error if you passed a non-<package> ☺
<ss2>unfortunately libvirt's service pulls in qemu with each checkout, which is filling up my store very fast. Then I'll just keep it as it is. But good to know now.
<nckx> https://paste.debian.net/plainh/a38b4324
<nckx>OK!
<ss2>oh, yes, I noticed it too that inferior was doing extra work, since reconfigure was taking much much longer now, and then it failed.
<rekado>fixed geary, will push in a moment
<abrenon>nckx: hi ! Thanks for the answers
<abrenon>you find it gross ? I think it's kind of elegant to have the key known "from within"
<rekado>pseudonymous: it’s fixed with commit bd53703e4e2f4ea6dd32123fa8be8c3540d77fbaa.
<abrenon>that's a shame for early-boot services, this stuff is fun
<jpoiret>utis, abrenon: the problem is that the initrd is stored in the stored, and every file in the store has r-xr-xr-x permissions by default. That would mean that your key is world-readable
<abrenon>ahhh, yes, the store. I forgot about that : )
<jpoiret>"stored in the stored" 🤦
<abrenon>hehe
<abrenon>yes, "stored", the store daemon
<abrenon>why ? ^^
<muradm>hello guix
<muradm>guix pull broken for me? https://paste.rs/9w8
<muradm>may be connection issue
<ngz>muradm: It looks like a transient error, indeed.
<muradm>ngz: seems so, 3rd time worked, thanks
<apteryx>zimoun: I'm testing the nixpkgs patch applied to julia
<zimoun>apteryx: I am also doing :-)
<zimoun>the test suite passes now
<zimoun>I gues :-)
<zimoun>and I think the pattern «haskey ? parse : default» is unnecessary here because JULIA_CPU_CORES is always set, IIUC.
<amirography>Hey all. I'm curious, does guix offer any *quality-of-life* advantages over nixos for *user*?
<zimoun>apteryx, I think that will make efraim happy :-)
<rekado>amirography: I don’t know how to answer this question. It’s so vague.
<rekado>(I never used nix and I find it much less appealing than Guix.)
<utis>jpoiret: i don't know what the stored is. do you mean that there is a real problem?
<rekado>it looks like the 'sanity-check phase doesn’t really work for all Python 2 packages
<apteryx>zimoun: seems something needs to be adjusted for guix indeed, it didn't have an effect
<rekado>not because inputs are missing, but because too many non-existent modules are tested
<nckx>utis: It was just a typo for ’store’.
<zimoun>apteryx, I am working on it.
<apteryx>thank you!
<M6piz7wk[m]>Is there something like GUR (Guix User Repository) database?
<zimoun>argh whyt paste.debian.net always returns Invalid format for name (no special chars, max 10 chars)
<M6piz7wk[m]>basically list of available guix channels
<zimoun>apteryx: have you tried if net_on || haskey(ENV, "JULIA_CPU_THREADS"
<zimoun>x = haskey(ENV, "JULIA_CPU_THREADS") ? parse(Int, ENV["JULIA_CPU_THREADS"]) : Sys.CPU_THREADS
<zimoun>
<zimoun>because on my machine it seems to works :-)
<zimoun>I am sending the fix upstream even ;-)
<jpoiret>utis: the store is where guix stores all built derivations. The problem would be that any application running on your computer would be able to read your luks key, not the ones running as root
<apteryx>zimoun: good! it'll work in our case since we set JULIA_CPU_THREADS
<apteryx>trying it
<zimoun>apteryx: yep! I think it works for the general cases. In our case, x = parse() should be enough.
<apteryx>oh yes, I meant the patch wouldn't work on NixOS or elsewhere (to enable tests in a minimal container) unless they set JULIA_CPU_THREADS
<apteryx>I'm trying it
<zimoun>I sent to guix-patches
<zimoun>apteryx: see patches #52078.
<zimoun>apteryx: now I have other errors… it is endless
<zimoun>sprint(show, Dates.Date(1, 1, 1)) == "Date(\"0001-01-01\")"
<apteryx>zimoun: https://paste.debian.net/1220661/
<zimoun>apteryx: yeah!
<apteryx>it should be done in about 15x less time on that machine
<zimoun>yep! And it will help when building all julia-* packages.
<zimoun>but this fix triggers another failure about Dates. I am working on it. I will send v2 once I understand what’s going on.
<zimoun>disable 18 tests is maybe too much ;-)
<roptat>hi guix!
<utis>jpoiret: the normal hack isn't to put the key in the initramfs; the initramfs just contains a reference to a file on the root fs that contains the key
<utis>(or anywhere on the encrypted partition)
<jpoiret>utis: ? if they key is inside the root fs, the initrd will have to open the encrypted root fs to find it, defeating its purpose
<jpoiret>you actually embed it inside the initramfs usually
<jpoiret>the *
<utis>that's not what i do
<utis>oh
<utis>sorry
<vivien>What if the drive fails with the decryption key still on disk? Doesn’t that completely defeats encryption?
<vivien>defeat*
<nckx>The key is permanently on disc, not during a brief window, as your question seems to imply.
<jpoiret>vivien: wdym by drive fail? the data is encrypted in place, there's never any unencrypted data on a luks partition
<utis>regardless of the details, is this a problem peculiar to guix?
<apteryx>zimoun: yeah, now the failing tests phase `check' failed after 1057.3 seconds
<apteryx>1057 s is much better than 2-3 hours though ;-)
<nckx><the initramfs just contains a reference to a file on the root fs> Yeah that's pointless.
<utis>i may have misunderstood how this works
<jpoiret>utis: yes, because `guix system` will build the initramfs and store it in /gnu/store
<nckx>I think so.
<zimoun>apteryx, yeah. :-) Well, th failure is really weird. Do you also have 18 tests about Dates/io?
<zimoun>How many cores do you use?
<jpoiret>the same problem holds for other software: you shouldn't embed passwords inside software that's built with guix, as it will also end up in the world-readable store
<utis>so there's simply no way to avoid having to type the password twice on guix?
<apteryx>not currently, but it's technically possible (nix does something about it)
<nckx>utis: As long as the initramfs is a regular Guix build product, without special hacks to create an unreadable initramfs outside of the store: yes.
<utis>maybe if one put an encrypted key on an external device
<apteryx>zimoun: 24 on that offload machine
<jpoiret>yes, you could also use grub patches with support for usb smartcards
<nckx>utis: Yep, that's one way to do it, but you can't expect everyone to boot with an external device. To fix this particular problem a root-readable file in / is already fine.
<nckx>‘In /’ meaning on the root fs, not necessarily at the top level.
<zimoun>apteryx, thanks and the failure is also about 18 tests of Dates/io, right?
<apteryx>yes
*apteryx tries upgrading to 1.6.4
<utis>what do people do to get an encrypted swap as well? is lvm on luks the simplest solution?
<vivien>utis, I use a swap file
<rekado>I received the new SSDs for the aarch64 honeycomb boards. Trying to install Ubuntu Server on them to then run “guix system init config.scm /”, but I keep running into problems :(
<nckx>utis: If simple is the goal, why add LVM to it?
<nckx>Should not be needed.
<rekado>“soft lockup - CPU#2 stuck for 920s”
<rekado>bah
<nckx>:-/
<nckx>In what?
<zimoun>apteryx, upgrading to 1.6.4 and then it is possible that many julia-* break. )-:
<apteryx>even for a patch version bump?
<rekado>Workqueue: efi_rts_wq efi_call_rts
<rekado>I’ll try installing from sdcard, using the official solidrun image
<utis>i thought with two encrypted partition it might be difficult to unlock both in one go, but i hadn't thought about a swap file, i'll try that
<apteryx>at any rate it'd be better than a broken julia if the test suite is fixed ;-)
<jpoiret>utis: with the new swap-devices patch syntax™, you'll be up and running in no time :) be sure to check the latest manual, rather than the last stable one, for that info to show up (either info "(guix) Swap Space" or at https://guix.gnu.org/manual/devel/en/html_node/Swap-Space.html#Swap-Space)
<nckx>rekado: You can also try module_blacklist=efi_rts_wq,efi_call_rts since you don't actually care about either.
<nckx>rekado: Alternatively, can you disable UEFI at all on these things?
<nckx>Probably not.
<rekado>I have no idea
<rekado>I wouldn’t know where
<nckx>Nah, never mind. Unlike PCs there's no standard thing preceding UEFI so there's nothing for a ‘CSM’ to emulate. IIUARMC.
<jpoiret>load an EFI program that itself emulates CSM that then loads your OS
<nckx>jpoiret: What would that look like though?
<nckx>There's no historical ‘ARM BIOS’ it could emulate.
<nckx>I thought UEFI was the first cross-vendor standard.
<jpoiret>heh, I don't know much (if anything) about ARM. Just chainload into QEMU then
<nckx>lol.
<jpoiret>that QEMU should then load OVMF, which should load an EFI CSM emulator which-- let me stop here
<jpoiret>time to write some small patches instead of dilly-dallying
<nckx>‘Let's add aarch64 boxes to the build farm so we don't have to emulate slow ARM machines on huge x86 systems.’
<nckx>*932 minutes later*
<nckx>‘OK, I got the boards to boot into qemu-system-x86_64 without an OS now what.’
*dstolfa notices a bunch of guix + ZFS emails that are extremely lengthy...
<dstolfa>another licensing discussion i presume?
<zimoun>apteryx, the patch seems to tweak something but I miss why. For instance sprint(show, Dates.Date(1, 1, 1)) return the string "Date(\"0001-01-01\")" instead of "Dates.Date(\"0001-01-01\")". Somehow, it comes from «sprint(show». Hum!?
<zimoun>apteryx, if instead of ’using Dates’, I do ’import Dates’, it works. Double hum! :-)
<apteryx>it at least fails the same with 1.6.4
<nckx>dstolfa: I wouldn't call it a discussion. There does not seem to be any new information.
<apteryx>zimoun: is this new with the parallel test patch?
<zimoun>I do not know. I guess no, because 9d37002 from master, same behaviour it seems.
<dstolfa>nckx: ah, fair. i'll save time by perhaps not reading it this time :)
<dstolfa>thanks!
<zimoun>Well, I am going to send a v2 fixing this remaing thing.
<nckx>dstolfa: Well, feel free to draw your own conclusions, and even point me to any new info I missed if you're feeling generous.
<nckx>Personally, I'm starting to consider that thread a waste of my time.
<dstolfa>nckx: well, IANAL and all that... agreed on waste of time. if we had lawyers that could cite specific portions of the law with prior cases, etc, sure
<dstolfa>but like this it's a bit of just armchair lawyering
<apteryx>perhaps wasting of time would have been saved by erring on the cautious side of things and not including ZFS in Guix proper. Other places can offer it and deal with the fallout.
<dstolfa>apteryx: it's already included and makes life easy for those that use it. it's free software under a copyleft license and only sources are distributed by guix proper.
<dstolfa>don't really see a problem with it at all
<nckx>Yeah.
<zimoun>apteryx: arf, https://github.com/JuliaLang/julia/issues/34655
<nckx>‘People against including ZFS send a lot of mail, hence we shouldn't include it’ is a terrible precedent to set.
<zimoun>already a fix but not enough
<nckx>If a good case could be made against including it they would have by now managed to do so in far fewer messages, IMO.
<apteryx>well, when you know the history of the zfs licensing story (designed to be incompatible with the GPL), it's only natural that people would question the move of adding it to a GNU-endorsed distribution.
<zimoun>apteryx, rebuilding to check everything is fine :-)
<nckx>Sure, but it doesn't need a seasonal reboot from scratch.
<dstolfa>apteryx: that's also a rumor from 1 person, which is disputed by everyone else involved
<rekado>I installed Ubuntu successfully with the official SD card image, following the instructions here: https://developer.solid-run.com/knowledge-base/honeycomb-clearfog-cx-installation-and-tips
*apteryx goes off to watch past seasons episodes
<rekado>next up: do a “guix system init”
<nckx>\o/
<zimoun>nckx: all the answers are in https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ so I also miss what is the issue. :-)
<zimoun>and the thread seems to ignore this link )-:
<apteryx>dstolfa: the rumor about what?
<nckx>dstolfa: It's not really a rumor, or at least not one concocted by one person.
<dstolfa>apteryx: it being designed to be incompatible with the GPL. from people who were directly involved, everyone but that one person claims that the CDDL is the way it is due to contributed vendor code
<dstolfa>nckx: it comes from a single person
<nckx>I thought you meant person in said thread but now I think you didn't.
<dstolfa>others involved (bryan cantrill, matt ahrens, etc) all strongly disagree on this particular topic
<nckx>Bryan Cantrill was involved in ZFS? Hokay.
<dstolfa>zimoun: also yeah... IMO the free software ecosystem has much bigger problems than bikeshedding about differently licensed free software source distribution
<nckx>dstolfa: Which ‘single person’ would that be, then?
<dstolfa>nckx: as far as i remember, Danese Cooper is the only person that ever claimed this
<nckx>I'm pretty sure they're not alone.
<mjw>She is the one who said it out loud.
<dstolfa>the statement is parroted by others that weren't involved, but i've yet to hear it from anyone else that's ex-Sun and was involved in opening up solaris
<nckx>Like, this is also the position of the SFC, they are quite explicit about it, and their argument was not, IIRC, ‘Danese said so’. I'm not saying it's uncontroversial (hah) but this seems like an oversimplification also.
<mjw>I do believe there are others who truly believe the CDDL wasn't explicitly designed to be GPL incompatible.
<mjw>But it doesn't really matter if it was deliberately designed to be GPL incompatible or that it was just a happy/sad "coincident" that it turned out to be.
<nckx> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux : ‘We believe Sun was aware when drafting CDDLv1 of the incompatibilities; in fact, our research into its history indicates the GPLv2-incompatibility was Sun's design choice. At the time, Sun's apparent goal was to draw developers away from GNU and Linux development into Solaris.’
<nckx>That is vague but explicit.
<nckx>Oh, zimoun already posted that.
<M6piz7wk[m]>Like there is software that is just not sustainable on GPLv3 you know
<dstolfa>nckx: and unsubstatinated other than "we believe"
<M6piz7wk[m]>like innovations requiring X amount of resources to develop
<nckx>dstolfa: That doesn't matter, it disproves the ‘single person’ argument.
<nckx>I'm not saying they are right or wrong.
<zimoun>dstolfa, yes. Maybe. I miss the final point. ZFS is free software so it possible to distribute source code. It is not possible to distribute binaries. That’s all.
<dstolfa>nckx: it doesn't. i never said it's one person saying it. i said it's only one person out of those involved in creating the license saying it :)
<M6piz7wk[m]>i wish more ppl in FLOSS realized that or had background in economy to adjust GPLv3 for those things as without it they just use full proprietary and are not influences to respect FLOSS values
<dstolfa>there are many people reiterating that statement, but i've only ever heard it from 1 person actually involved in the process
<rekado>hmpf. The fancy apt progress bar keeps messing up my serial connection.
<nckx>No, you said ‘a single person’ without qualifiers.
<nckx>It's not what you meant, fine, point taken.
<zimoun>dstolfa, I miss what could prevent us to not distribute the source code of ZFS?
<dstolfa>ah, my bad then!
<dstolfa>nckx: FWIW Simon Phipps is a good person to talk to about this
<apteryx>dstolfa: why does it matter though? it's clear that Sun wasn't GNU/Linux friendly, so it's not an unreasonable thing to say
<dstolfa>apteryx: does that mean that a GNU system should then be unfriendly to all differently licensed free software and not distribute their sources though?
<apteryx>in the end the problem is that Oracle refuses to relicense to something GPL-compatible
<M6piz7wk[m]>what sun
<rekado> https://en.wikipedia.org/wiki/Sun_Microsystems
<M6piz7wk[m]>apteryx: Is oracle (the for-profit company) even **ABLE** to relicense on GPL-compatible economically?
<mjw>which is odd, because they did with dtrace in the end (change the license from cddl to gpl)
<mjw>so I don't see why they couldn't also for zfs if they wanted to
<dstolfa>ZFS/DTrace from oracle and ZFS/DTrace that people actually use today in FLOSS systems are different things
<dstolfa>unless you count oracle linux
<dstolfa>they diverged quite a bit
<zimoun>ouch it is so boring to push code to GitHub because their TOKEN authentication. Just for sending a PR. Arf!
<nckx>We could make the case that Oracle is so hostile that we don't package their thing out of spite^Wprinciple, but then that has to be made explicit and we can discuss it. Now it's ‘there might be legal issues! beware!’ which talks like FUD and has done very little walking so far.
<apteryx>dstolfa: that's just my opinion, but a FSDG distro shouldn't go out of its way to make life easy, trading political points in exchange
<M6piz7wk[m]>does anyone even care of economy in this scenario here.. If you want company to use FLOSS license then enable them economically to do so.. Companies just want more profit so if they gain more from being FLOSS they will jump on it
<M6piz7wk[m]>they won't switch on FLOSS if they can't afford it economically
<dstolfa>apteryx: it's free software. what exactly is the problem with distributing sources of free software under a copyleft license?
<dstolfa>we could then make the argument to remove rust because it's a single implementation with a trademark owned by mozilla. suppose i have a problem with that and keep spamming emails about it, does that make my point any more valid?
<M6piz7wk[m]>and it's very possible to earn more profit on FLOSS license e.g. gitpod case
<mjw>dstolfa, working on that (gccrs) but it will take a bit.
<jpoiret>M6piz7wk[m]: the CDDL licensed ZFS code doesn't make them any money any way
<M6piz7wk[m]>jpoiret: how do you know
<jpoiret>it is a free and open source license
<nckx>dstolfa: <talk to Simon Phipps> Thanks! About what exactly? The first quotes I find are about the original intent of choosing CDDL, which I don't really care about, it's not relevant to (not) redistributing ZFS today.
<nckx>Why Sun chose it is irrelevant.
<M6piz7wk[m]>bcs creating something like ZFS needs resources both financial and qualified personnel
<nckx>They can claim it wasn't to thwart the GPL and still be lying anyway.
<jpoiret>relicensing to GPL would not change anything on how much money they make off it (if they even do)
<dstolfa>nckx: oh just about history of these things if you find it interesting, nothing relating to the topic at hand today
<M6piz7wk[m]>you don't know that bcs their financing is not transparent
<nckx>dstolfa: Ah, OK, thanks
<M6piz7wk[m]>oracle gets lot of gov contracts last time i checked so they can't do that economically most likely
<M6piz7wk[m]>fix the issues that prevent what you want instead of complain about them without sufficient solution, politics 101
<rekado>
<dstolfa>M6piz7wk[m]: oracle can't use CDDL licensed changes in their ZFS implementation, so OpenZFS and Oracle ZFS are not compatible IIRC
<apteryx>dstolfa: I was just stating a general opinion I hold (don't navigate licensing grey areas, especially if they don't align with the overall vision of offering a GPL free software system)
<M6piz7wk[m]>also looking at the CDDL license it seems to me that oracle is committed to FLOSS, but they aren't given the opportunity to be a FLOSS company like from what i was reseaching in that when there was this whole issue with it in linux kernel they would have a significant losses on GPLv3
<M6piz7wk[m]>bcs GPLv3 is not optimized for innovative techn
<M6piz7wk[m]>also case for FSF to be more politically and economically competent to do investments to enable such innovations
<apteryx>M6piz7wk[m]: you are right, it's "optimized" to protect your user freedoms
<M6piz7wk[m]>Like take scenario: you need 50K USD to develop a software, it's very complicated to make that FLOSS and lot of people just give up even trying to make it FLOSS.. that oracle even went through and made CDDL-1.0 is a step in the right direction in this area that FSF evidently don't care about
<mjw>M6piz7wk[m] I think you are discussing in the wrong channel.
<ss2>is there a way to direct the messages from the application ths shepherd service is trying to spawn? It is is failing, and I never see an error.
<M6piz7wk[m]>apteryx: apteryx: i am not saying that it's impossible to develop something that even needs 200K USD to develop as FLOSS i am saying that it's demanding to develop the business plan and you often get into areas that make it impossible to do so at the time
<dstolfa>ss2: similar to what journald does?
<ss2>yes.
<dstolfa>unfortunately i'm not aware of that functionality in shepherd yet :(
<dstolfa>it would be really useful though!
<jpoiret>i'm sure there is some way to do that
<dstolfa>you probably need to do it manually when starting a service i'd imagine?
<apteryx>ss2: there's a log-file argument to the shepherd constructor that'd do it, I believe
<dstolfa>as in, dup2 the fds from guile and then spawn it
<apteryx>I've done something like this for mcron
<Gooberpatrol_66>if you need to make money from developing software, then make it as copyleft as possible and sell exceptions to the license.
<apteryx>it's not merged yet though. Testers welcome, the maintainer of mcron had mentioned issues (I only tested with Guile 3.0.7).
<jpoiret>ss2: see https://www.gnu.org/software/shepherd/manual/html_node/Service-De_002d-and-Constructors.html#Service-De_002d-and-Constructors
<dstolfa>jpoiret: ah, handy. good to know!
<jpoiret>as apteryx said, it's an argument to make-forkexec-constructor
<apteryx>for the mcron patch adding log capture and error reporting: https://lists.gnu.org/archive/html/bug-mcron/2021-08/msg00008.html
<apteryx>it'd be nice to have it in the next release
<apteryx>I'm running with it applied for months, haven't had time to research about issues on non-3.0.7 Guiles
<jpoiret>well if it's merged in master it'll be enough, right?
<zimoun>apteryx, see https://github.com/JuliaLang/julia/pull/43211
<ss2>that'd be two things I've knocked at today that is waiting to come soon.
<apteryx>jpoiret: right
<apteryx>so it's not critical, but it'd be nice
<jpoiret>by the way, have you been able to reproduce the slim bug?
<ss2>jpoiret: thanks!
<jpoiret>(i know i said sddm in the mail, but my brain was still sleeping it seems)
<apteryx>jpoiret: I haven't reproduced it with GDM (bare-bones.tmpl or desktop.tmpl are OK); I'll try making a minimal example out of the lightweight-desktop.tmpl template.
<rekado>on this aarch64 machine I get this when running “guix pull” (right after installing with https://guix.gnu.org/install.sh): c8005b63fa092a6177a0fab1125760ec698da03b
<jpoiret>thanks! i've been meaning to close the remaining big blockers for c-u-f
<rekado>oops
<rekado>guix pull: error: cloning builder process: Invalid argument
<apteryx>jpoiret: yes, I believe after this we can merge to master?
<apteryx>or is there something else which should block
<jpoiret>well, apart from the Julia issues which i'm not familiar with, I don't recall seeing any other blocker
<jpoiret>oh, the libva update
<apteryx>wasn't libva already broken though? I seem to recally it was missing patching in the past
<jpoiret>it'll cause a big rebuild again, but otherwise it would be broken on wayland compositors
<apteryx>not that it's a good reason to not fix it now
<jpoiret>well, i'm happily using it on my laptop right now
<apteryx>OK! Let's merge it then.
<jpoiret>otherwise i wouldn't be able to watch 4K videos on my laptop :)
<apteryx>Oh, there's a pesky xkbcomp warnings issue that annoys me
<apteryx>but it's perhaps only there in the build container (lacking an environment variable?)
<jpoiret>it's working fine on master, and i don't understand the wayland stack well enough to know which update broke that
<apteryx>you'll see the warnings spamming while running xvfb-run'd test suites
<apteryx>OK
<jpoiret>yes, i've seen them for gnome-shell tests too
<apteryx>I've asked upstream for hintsights here: https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/merge_requests/6#note_1156769
<zimoun>dstolfa: I agree about bikeshedding. It appears to me weird how people without any legal background have such strong opinion about speculative case never pleaded in Court.
<jpoiret>i'm worried that it'll cause a big rebuild though
<apteryx>but so far I still don't have a clue, outside that perhaps xkbcomp-intermediate plays a role in it
<apteryx>jpoiret: I can have it pre-built on berlin if that helps
<apteryx>zimoun: sorry if I didn't follow closely; is #52078 fixing the Dates problem?
<apteryx>date tests*
<jpoiret>i get Building the following 1443 packages would ensure 3091 dependent packages are rebuilt, ouchies
<apteryx>that's not so bad
<utis>how would one boot from an external device? (to avoid having to type the fde password twice)?
<utis>would this be fairly simple or complicated?
<jpoiret>utis: boot from an external device, as in, have the kernel + initramfs available from outside the store?
<jpoiret>i don't think there's an easy way to do this currently.
<podiki[m]>looks like the polkit/duktape patch went in and gotten closer for wine building
<podiki[m]>now it fails because plotutils has more tests failing on i686
<nckx>jpoiret, utis: You could write something custom like https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n104
<zimoun>apteryx, not yet. v2 is in preparation. I am checking all is fine.
<utis>jpoiret: yeah, that's what i meant
<zimoun>each time I fix an issue, another shows up :-)
<dstolfa>zimoun: that means guix has plenty of eager users to report bugs! technically a good thing, though i can see how it may be a bit frustrating :)
<apteryx>zimoun: could you place it in paste.debian.net in the meantime, I'll validate it here as well
<apteryx>(takes 20 minutes to build about)
<jpoiret>nckx: that's a great solution! to use something like this, you'd have to patch guix a bit to run after system activation in `guix system reconfigure`, right?
<jpoiret>the only downside is that if you want to boot an older generation, you'll have to input the password twice, but it should be very occasional
<drakonis>duktape?
<drakonis>ah its a performance thing
<jpoiret>drakonis: it's a javascript engine, used instead of the default one in polkit (because of course a program such as polkit needs a js engine)
<nckx>drakonis: No, size thing.
<apteryx>drakonis: more like a polkit without rust on anything but x86_64
<jpoiret>because the default one needs rust, and rust only works on x86_64 on c-u-f
<nckx>Gets rid o' Rust.
<drakonis>i see
<nckx>jpoiret: I don't think it requires any patches. At least berlin doesn't run a forked Guix.
<nckx>As far as I know etc.
<jpoiret>nckx: so is it run as a script separately after guix system reconfigure?
<zimoun>apteryx: place what?
<nckx>jpoiret: No, it's an activation service.
<apteryx>your wip diff fixing the dates test :-)
<nckx> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n218
<zimoun>argh why paste.debian.net always returns Invalid format for name (no special chars, max 10 chars)
<jpoiret>oh, of course! but then, isn't it run at each system boot?
<apteryx>zimoun: you can leave it blank
<apteryx>it's still picky though, apparently to combat spam
<nckx>And on reconfigure, but just not ‘externally’, is what I meant.
<jpoiret>maybe we could add a 'post-reconfigure-script-service-type' to satisfy those needs, no?
<nckx>rek ado will know more about how this came to pass. Something shitty Dell HBA something.
<nckx>jpoiret: Why?
<nckx>Off hand, I don't think that's a good idea.
<jpoiret>well, isn't copying the whole kernel and initrd at every boot a bit useless?
<podiki[m]>(starting a build of i686 wine with plotutils without tests....)
<nckx>jpoiret: That's no excuse to introduce something as fragile and wrong as 'post-reconfigure-script-service-type's I think.
<jpoiret>i'd agree with you though that it'd be a bit hackish
<jpoiret>i still have that email draft for more operating-system/bootloader modularity somewhere from before c-u-f things :)
<nckx>I wonder if we can make the hack less hacky instead, push it towards being conceptually sound, instead of solidifying its hackiness.
<jpoiret>i think that would fit right in
<nckx>Hm.
<apteryx>zimoun: also, about "These tests randomly fails because they depend on CPU." -> is this reported upstream? we should link to the issue so we know when to undo the patching.
<nckx>jpoiret: Sounds cool.
<zimoun>apteryx: https://paste.debian.net/1220674/
<zimoun>apteryx, one foot, then another foot. :-)
<nckx>No no shoot both at once for efficiency.
<zimoun>I have only one screen and 10 fingers ;-)
<nckx>:)
<jlicht>glad to see I missed out on the WANL (we are not lawyers) session on ZFS :-)
<zimoun>apteryx: the path contains mistakes
<zimoun>apteryx, this one should be good https://paste.debian.net/1220675/
<podiki[m]>(glib-networking also fails a test on i686)
<podiki[m]>wow and now lib2geom also....is i686 bad with tests in general usually?
<rekado>I suppose this “cloning builder process” error has been fixed in a more recent version of the daemon.
<rekado>I’ll try to download a new one
<rekado>the reason for that service is indeed because of using external disks.
<rekado>when booting GRUB looks for /store on the root disk, so that’s where we make the kernel and initrd available.
<rekado>the disks hosting /gnu only become available once linux boots
<apteryx>zimoun: testing
*rekado tries “guix build /gnu/store/cxndd9szal6z1pnzj5zcy4gc3x7da91m-guix-daemon-1.3.0-12.9bbbac6.drv” to get a more recent daemon
<podiki[m]>....and gtk+-3 tests on i686
<apteryx>podiki[m]: it has less precision for floats which tests often stumble on
<apteryx>IIUC
<podiki[m]>gotcha
<apteryx>and since few people care about i686 anymore, it goes mostly unnotice upstream
<podiki[m]>do you know of any changes in c-u-f that might affect tests in general? or likely just new versions and such?
<podiki[m]>I only care for the rare usage of Wine
<apteryx>new versions I'd say
<apteryx>perhaps some patching we have need to be updated
<apteryx>you could check in Debian's salsa git repository, it's a good source of patches for this kind of thing
<podiki[m]>a few patches I saw for disabling certain tests already, but may need more
<podiki[m]>I'm just trying to see right now how many packages' tests I need to disable to get all the way to wine i686 (needed for wine on 64)
<podiki[m]>the end result being fixing an x86-64 package :)
<jpoiret>apteryx: I see an easy fix: just silence the invocation of "Xvfb :1 &" in all those tests
<jpoiret>but maybe that's too much
<apteryx>I'd be afraid to miss something important when it does fail
<csantosb>Hi #guix, I'd need some support ... I'm running the command
<jpoiret>maybe we could just filter out lines that contain "could not resolve keysym"
<csantosb>guix time-machine -C channels.scm -- shell --container -m manifest.scm -- python3
<csantosb>with no issue: I start python
<apteryx>jpoiret: yeah, that feels unsatisfying though (not understanding the root cause)
<csantosb>The command: guix time-machine -C channels.scm -- shell --container -- python3
<csantosb>Gives an error
<csantosb>Howerver, when I: guix time-machine -C channels.scm -- shell --container
<csantosb>and then I run python3 ... everything works as expected ... any idea why ?
<jpoiret>can you do `guix time-machine -C channels.scm -- shell --check`? (if of course your time-machining to a commit that has this command)
<csantosb>I get first 'guix shell: loading environment from .../manifest.scm'...
<csantosb>Then "guix shell: checking the environment variables visible from shell '$HOME/.guix-profile/bin/zsh'..."
<csantosb>And gets stuck at this point
<podiki[m]>(when I tried check recently it seemed to hang and I gave up, also with zsh, but maybe I didn't wait long enough or was something else)
<csantosb>I let it run for a while ... in the meantime, I try using bash instead of zsh
<jpoiret>weird, it's instantaneous for me (on c-u-f though, not master)
<jpoiret>your zshrc doesn't do any env sourcing, right?
<csantosb>Same behaviour under bash.
*rekado compiles Linux on aarch64
<csantosb>:jpoiret no, no sourcing
<jpoiret>can you check your PATH env variable in `guix time-machine -C channels.scm -- shell --container`? does it only contain the profile's bin dir?
<zimoun`>apteryx, something still fails.
<csantosb>echo $PATH gives /gnu/store/8yficjqh5fbzvmdsd3yhl5gixxgxra55-profile/bin:/gnu/store/8yficjqh5fbzvmdsd3yhl5gixxgxra55-profile/sbin
<jpoiret>looks good.
<csantosb>Maybe guix time-machine and removing the '-m manifest' are incompatible ?
<apteryx>zimoun`: #:tests? #f ? joking...
<M6piz7wk[m]>what's the nmap command to show available ssh connections on local networks
<M6piz7wk[m]>u.u
<M6piz7wk[m]>i am mangling it
<cbaines>this is not an IRC channel for help with nmap M6piz7wk[m]
<jpoiret>csantosb: that's weird though. Is there any guix.scm file in the directory as well?
<csantosb>No, just the manifest.scm and channels.scm files.
<M6piz7wk[m]>cbaines: grrr
<jpoiret>let me try to reproduce this on master
<csantosb>I just guix pull; guix version gives 1172fa8cc44e62475de42bf9be3cafabdd2900f0
<M6piz7wk[m]>what's the channel for nmap things
<M6piz7wk[m]>oh #nmap
<jpoiret>csantosb: since you're using time-machine, you may be using an older guix version (unless you're not using an older guix version)
<M6piz7wk[m]>gutgut
<csantosb>jpoiret: yes, exactly
<jpoiret>if this is reproducible that's definitely a bug
<csantosb>Let me try without the -C channels.scm flag ...
<civodul>apteryx: we're providing a release candidate of glib-networking, is that safe?
<jpoiret>csantosb: I can reproduce this error too
<csantosb>Ok, it's a bug then ?
<jpoiret>yes
<jpoiret>let me see if it's just an easy omission
<csantosb>Not a big deal to me. Just wanted to make it explicit in case a fix is possible.
<zimoun`>apteryx, now th test suite take ~30min on my machine \o/
<rostranj>hi, I need help... this is an old issue but I'm not sure it's been fixed since. I have issues installing plugins when using GUI apps in foreign distros
<rostranj>the first time I noticed this issue was when using GIMP on Ubuntu (v 20). I tried installing plugins by moving the plugins to the plugins folder and it would not work
<rostranj>this time I'm seeing that same issue when installing an OBS plugin, I moved the plugin folders, just as indicated in the instructions, to the plugins folder in ~/.config/obs-studio/plugins
<rostranj>and it won't install the plugin, or make it visible when launching OBS, I've tried to restart the app and open again and still does not work
<zimoun`>apteryx, I will be back later. Once the tests pass, I send v2 containing fixes about failing tests and parallel tests (as I said haskey ? parse : default is not useful. Confirmed by upstream ;-) https://github.com/JuliaLang/julia/pull/43211#discussion_r756248773 )
<f1refly>So I tried installing guix to a partition on my laptop. my laptop has a bios-grub partition, a /boot for my current system (arch) and a /boot for the new system (guix). the fourth partition is a luks volume that contains my logical volume group on which the root filesystems for arch, guix and my /home reside
<f1refly>obviously, with such a setup, grub.cfg cannot contain references to /gnu/store, but after installing it does. I pretty much followed the example setup where they explained how to define the mappers for lvm and luks, but somehow guix didn't figure out it needs to actully put stuff on /boot
<f1refly>is there a special step or entry that needs to be done in order to tell guix it needs to copy the things to /boot?
<podiki[m]>okay got wine to build with `guix build wine -s i686-linux --without-tests=plotutils --without-tests=glib-networking --without-tests=lib2geom --without-tests=gtk+@3.24.30`
<podiki[m]>disabling/fixing tests on those would probably help improve the i686 coverage as well as fixing the wine build
<jpoiret>f1refly: there isn't a built-in way for now for guix to put things in /boot
***ns124 is now known as ns12
<jpoiret>the way that it works with LUKS devices for now is that GRUB itself will unlock the root partition
<podiki[m]>I'm not sure if I'll have the chance to disable or fix each of those failing tests, but I'll report this on our tracker with links to the relevant logs to see the failing tests
<rostranj>hello, any clues as to what is causing the issue with GUI apps in a foreign distro?
<f1refly>jpoiret: Oh, I did not know grub could do that. Coming from arch, I'm used to the unencrypted kernel + initramfs -> decrypt root-> mount root
<f1refly>I'll try to reboot then (Honestly I didn't try after seeing nothing in /boot, but I'll give it a shot now)
<jpoiret>GRUB has been able to do that for a bit with LUKS1 partitions, and recently with LUKS2
<jpoiret>wait
<rostranj>the issue: install plugins but not loading the plugin in the app
<jpoiret>did you format your partition with LUKS2? if so, it will not work yet
***stryan_ is now known as stryan
<jpoiret>you can do cryptsetup luksDump /dev/whateverisyourlukspartition
<jpoiret>it will tell you if it's LUKS1 or 2
<utis>why am i told: warning: cannot determine provenance for current system ?
<unmatched-paren>since i'm still having gnome crash on login after reconfigure, can someone more experienced please verify that my /etc/config.scm is valid and correct? this is it: https://paste.debian.net/1220677/
<f1refly>jpoiret: Version: 2
<f1refly>So it won't work then
<f1refly>?
<unmatched-paren>utis: this happens before you do your first reconfigure i think
<jpoiret>utis: this is a harmless warning, which should not impact anything. It should go away next time if you reconfigure with a recent guix
<jpoiret>f1refly: no, not currently
<utis>all right, thanks
<rekado>unmatched-paren: does /var/lib/gdm exist? Does it contain any logs?
<jpoiret>is it using PBKDF2 as its PBKDF?
<unmatched-paren>it exists but contains nothing :/
<jpoiret>if not, you have to reformat anyway, but if it does, you could use the patch I wrote that's pending a merge
<unmatched-paren>rekado: neither does /var/log/gdm
<jpoiret>unmatched-paren: what does `guix describe` tell you is the commit you're using?
<jpoiret>i'll try reproducing on a vm
<unmatched-paren>146c35ca8124d47075f7623044e1bfae5620ceed
<jpoiret> /var/log/gdm is only used when the debug? flag is set
<unmatched-paren>i just pulled and the issue does not go away
<f1refly>jpoiret: luks2 should be supported according to this path: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755
<f1refly>Is there a reason this isn't applicable to guix?
<unmatched-paren>jpoiret: debug? in the /etc/config.scm?
<jpoiret>f1refly: see https://issues.guix.gnu.org/51514
<jpoiret>also, GRUB 2.06 only supports the PBKDF2 key derivation function, not the argon ones, which is the default for cryptsetup
<jpoiret>unmatched-paren: yes, in gdm-configuration, but don't worry about it for now
<unmatched-paren>okay
<jpoiret>we'll first try to see if i can reproduce it
<jpoiret>if not then it's likely a driver problem and the gdm logs will tell us a bit more i think
<unmatched-paren>didn't we do this earlier though, and you couldn't reproduce it?
<jpoiret>oh, is that the same issue
<unmatched-paren>yeah
<jpoiret>i'm sorry if I 100% forgot about it (but at least I have your config)
<unmatched-paren>no it's fine :)
<unmatched-paren>i do not expect you to remember every single interaction with random strangers on the internet :)
<unmatched-paren>my config is fine, right?
<jpoiret>then, can you do replace the %desktop-services with this https://paste.debian.net/1220679/ ?
<unmatched-paren>okay...
<podiki[m]>is there anyway to build a package with guix build and use --without-tests for certain packages of different build architecture?
<jpoiret>then, you should have gdm and gnome-session related things in /var/log/messages /var/log/debug and /var/log/gdm/greeter.log
<unmatched-paren>i might disconnect for a moment while everything goes up in smoke as i reconfigure :)
<f1refly>jpoiret: maybe the documentation should be updated to tell users to use luks1 until this is fixed, the setup currently described there is not working:
<f1refly> https://guix.gnu.org/en/manual/devel/en/guix.html#Disk-Partitioning
<jpoiret>yes, I agree
<jpoiret>that issue also includes an update to the documentation
<jpoiret>we've been quite busy with bugfixing many new packages on another branch recently, so it's expected that these issues are taken a bit longer to be resolved
<apteryx>civodul: it should be bumped to 2.70 perhaps? I'm not sure why I missed that when I updated it; ISTR it wasn't available, or so I thought.
<unmatched-paren>gnome stuff is being updated, so it might just be an update problem
<unmatched-paren>but i guess we'll see when i get the logs
<darth-cheney>hey all, when I have a package def I'm making for, say, some Guile modules, but I also want to install some guile shell scripts on my path after they are available, how do I go about doing that?
<darth-cheney>Are there examples online for post-install scripting?
<f1refly>jpoiret: I could fix the german and english version, would that help?
<jpoiret>darth-cheney: there is no post-install scripting support in guix currently (and maybe ever). However, making things available to the user when they use a package is something that is completely doable currently
<jpoiret>if you put them in PATH with proper shebangs it should work out of the box
<darth-cheney>jpoiret: yeah is there a way to, say, copy the script to some location on the users path
<jpoiret>f1refly: well, the english one should be ok with the patch, but the german one will need a translation :) i'm not sure how translations of the manual work though
<darth-cheney>from the package definition
<jpoiret>no
<jpoiret>but, you can make it available in the /gnu/store/xxxx-package/bin/ folder, which will then be available for any user who installs your package
<unmatched-paren>ok before i log out and everything dies, is this normal:
<unmatched-paren>shepherd: Service swap-9e5a4e has been stopped. (expected, since i changed the swap to the new syntax)
<unmatched-paren>but then shepherd: Service swap-9e5a4ef1-6d5d-48b7-bbff-d26ec59dbc0b has been started.
<unmatched-paren>they have different names, why?
<darth-cheney>jpoiret: how do you make it available in that folder? You mean do it manuallyon whatever machine I'm on?
<unmatched-paren>even though they have the same uuid
<jpoiret>unmatched-paren: no idea. Maybe the old syntax stripped things for the shepherd name
<unmatched-paren>is it harmless?
<apteryx>civodul: or perhaps it was 'guix refresh -u' not detecting it? it doesn't as we speak (glib-networking 2.70 release)
<jpoiret>darth-cheney: well, it depends, are the scripts available in the source tarball? which build-system are you using for the package?
<jpoiret>unmatched-paren: yes, it is harmless
<civodul>apteryx: yeah but it has "rc" in the version string :-)
<unmatched-paren>right ok i'll just log out, make the issue happen, then reboot and rollback. the log should still be there after rollback, right?
<darth-cheney>jpoiret: I'm using the git method (rather than tarball) amd the scripts would be available there. Also using the guile build system since the modules the scripts use are what is being installed
<civodul>comrades, the PackagingCon videos are on-line! https://www.youtube.com/channel/UCGjb8FEgGAfMaQ98bVjNVJg
<jpoiret>can you switch VTs when the error happens? if so, try copying it from there directly. I think there's some log rotation, but I'm not 100% sure for the gdm greeter log
<unmatched-paren>no, i can't
<unmatched-paren> haven't been able to since i installed...
<apteryx>civodul: there's no 2.70 release on the GNOME ftp it seems
<apteryx>we could probably pull it from git
<unmatched-paren>when the error happens, because of the apparent lack of vt switching, the system is essentially bricked
<apteryx>weird, it's there though: https://download.gnome.org/sources/glib-networking/2.70/
<unmatched-paren>i wish there was some 'emergency exit' option in gdm so you could get into the console if you needed to...
<jpoiret>well, we'll see first what the /debug and /messages files contain, they're rotated at least
<apteryx>civodul: https://paste.debian.net/1220684/
<unmatched-paren>okay... bye ;)
<civodul>apteryx: let's not change it anytime soon because it has too many dependents and we're supposed to have merged yesterday :-)
<jpoiret>darth-cheney: i'd suggest adding a phase after 'build, that would move the scripts to PKG_OUT/bin
<civodul>i just noticed it by chance and wondered if it was intended
<darth-cheney>jpoiret: Okay thanks, that should be enough info to get me started!
<jpoiret>i wanted to find an example for guile packages but haven't been able to do so
<unmatched-paren>ok there's a log, let's have a look...
<apteryx>civodul: yeah I had it on my personal todo to bump it after it's out (seems it was out all that time, duh)
<apteryx>the url scheme just changed
<unmatched-paren>there's several, and i'm not sure which is the log from the problematic session... should i paste.debian.net them all?
<jackhill>Is anyone else having problems with browsing some package in webkit browsers like gnome-web (née epiphary) and nyxt? For me package like https://en.wiktionary.org/wiki/edification work, but not https://en.wiktionary.org/wiki/edify
<jpoiret>well, you can paste them all (debug and messages), while being careful to redact any sensitive information if there is any
<jackhill>This is on core-updates-frozen. The other webkit browsers, luakit, vimb, surf, and midori, fail to build, but those are separate bugs
<unmatched-paren>i don't think there's any sensitive information
<unmatched-paren>just stuff about my model of computer
<zimoun`>civodul, apteryx: could you apply to master https://issues.guix.gnu.org/51870 before merging? It will simplify the janitor work after the merge (python2- broken because upstream or because new sanity check)
<unmatched-paren>i deliberately choose nicknames for my username in case i need to share logs :)
<jackhill>I think the error message from nyxt is “<WARN> [12:53:56] Warning: JavaScript error: GError: Domain: "WebKitJavascriptError", Code: 699, Message:” (yes, with an empty message)
<jpoiret>unmatched-paren: sorry, brb, making food
<unmatched-paren>this may sound stupid but i can't figure out how to paste the log :/
<unmatched-paren>xclip doesn't work as root, and the cat and less output is too long to select
<unmatched-paren>i'll try sudo cp to somewhere in my home
<jackhill>unmatched-paren: I often copy the file or use sudoedit to get the file in a graphical editor that can then interact with the clibboard
<unmatched-paren>actually it turns out xclip doesn't work at all :P
<jackhill>:(
<jackhill>oh, I guess there are tools like wgetpaste as well
<unmatched-paren>kak is able to yank the file but i'm not sure how to put a yank into the clipboard in kak
<zimoun`>apteryx: yeah maybe I will endup with #:tests? #f. It is so fragile. Each time, one thing is fixed, another one raised. Anyway, I am doing a break. The test suite is almost fixed, julia test-suite is parall, and julia-build-system now run test in parallel (if I am correct but not well tested yet)
*jackhill uses emacs, sorry!
<lfam>I notice that <https://ci.guix.gnu.org/workers> doesn't seem to be working
<unmatched-paren>is it possible to put a yank into clipboard in vim, anyone?
<apteryx>zimoun`: alright, enjoy the well deserved break :-)
<apteryx>lfam: here too
<unmatched-paren>jackhill: i don't actually use kak regularly, i'm using it until i can figure out how to package tree-sitter and get nvim or helix working...
<unmatched-paren>vis behaves funny with non-bash shells, sadly
<lfam>unmatched-paren: Do you mean, paste into vim?
<lfam>Or copy from vim?
<unmatched-paren>no
<jackhill>unmatched-paren: cool! Best of luck with that. nvim keeps tempting me :)
<unmatched-paren>get yank from vim into xorg clipboard
<unmatched-paren>jackhill: sadly tree-sitter is proving difficult
<unmatched-paren>it's a C package that builds itself using rust's cargo
<lfam>Sorry I don't know what that means
<unmatched-paren>because it has rust bindings and a rust cli
<lfam>If it's only a few lines of text you can always select it with the mouse to make add it to the clipboard
<jackhill>unmatched-paren: yeah :/ does it have some js as well?
<unmatched-paren>problem is it isn't a few lines of text :(
<unmatched-paren>jackhill: yes, the optional wasm bindings
<jackhill>unmatched-paren: are you in terminal or graphical vim?
<lfam>I'm surprised that xclip isn't working for you
<unmatched-paren>why aren't all of these in different repos #£$*2!
<unmatched-paren>terminal vim
<jackhill>unmatched-paren: and did you see my wgetpaste suggestion?
<rekado>zimoun`: I’ve been trying to fix some python2-* packages.
<unmatched-paren>i was going to set up graphical goneovim, but that needs latest nvim, which needs....
<rekado>the sanity-check phase seems to break a few of them; it’s not their fault.
<unmatched-paren>i'll try wgetpaste
<unmatched-paren>this feels unnecessarily complex for something that seems so simple...
<unmatched-paren>i mean both problems, neovim and the copy-and-paste :P
<f1refly>jpoiret: I think i figured out how to downgrade to luks1, would booting from luks1 be fully supported?
<jackhill>haha, at least you haven't started in on one of the rust guis for nvim like https://github.com/neovide/neovide yet!
<unmatched-paren>jackhill: i used to use that but there were some annoying papercuts
<unmatched-paren>i haven't actually tried goneovim yet :P
<unmatched-paren>i might actually try helix-editor, which seems to be a lot more modern, but that requires latest rust, which is a whole other story
<unmatched-paren>actually i could try upgrading rust once this gdm thing is fixed
<unmatched-paren>since i do know rust
<unmatched-paren>and i'm fairly sure i know why the previous attempt to upgrade it failed
<unmatched-paren>before anyone suggests i try emacs, i have and i hated it
<unmatched-paren>even with evil
<unmatched-paren>ok this is /var/log/gdm/greeter.log: https://bpa.st/VZ7Q
<unmatched-paren>jpoiret
<unmatched-paren>there's a bunch more logs
<unmatched-paren>here's /var/log/gdm/greeter.log.1: https://bpa.st/6T5A
<unmatched-paren>greeter.log.2: https://bpa.st/HJ4A
<unmatched-paren>3: https://bpa.st/OWDQ
<unmatched-paren>and 4: https://bpa.st/GZ4A
<unmatched-paren>see, i'm not sure which one was from the session after i reconfigured
<jackhill>lfam: re: mailing list post about gvfs and webkit I think the originally complaint was about the closure size which was made worst by the person not liking the services needed webkit to support. At least that's how I read it.
<unmatched-paren>re. tree-sitter, nix do have it, so i'm going to have to learn nix and figure out how they do it :P
<unmatched-paren>nix feels really weird to me... instead of guix install pkg, you do nix-env -i pkg???
<unmatched-paren>why are there all these different commands
<nckx>Well, until recently you installed Guix packages with ‘guix package -i’.
<unmatched-paren>guix only has `guix`, which is much saner
<unmatched-paren>fair
<unmatched-paren>but why the -env bit
<lfam>The simpler command-line user interface has always been a win for Guix. It's a big part of why I ended up with Guix
<nckx>Nix-modify-my-environment-please. Didn't Nix migrate to a single (or primary) ‘nix’ command?
<unmatched-paren>if they insist on -env, they should have gone with nix env -i instead of nix-env -i imo
<unmatched-paren>Ifam: agree
<nckx>I do agree that the guix CLI is generally more intuitive, no contest.
<lfam>Things are always clear when looking back
<apteryx>hum: guix build: package 'widelands' has been superseded by 'widelands'
<nckx>It's one of the main reasons I switched to Guix as well.
<unmatched-paren>i had never used nix except briefly, but both looked quite nice, guix just looked nicer
<unmatched-paren>and i wanted to use a pure-libre distro too
<unmatched-paren>and of course i didn't reeaaallly want to have to learn a whole new language, either
<nckx>apteryx: widelands@21 was followed by widelands@1.0, so this is a hacky way to force an upgrade that Guix (and anyone who can count) would consider a downgrade.
<jackhill>what's the best practice for reporting build failures in the bugtracket? I can attache the bz2-compressed log, include the log in my email, or link to the log from ci.guix.gnu.org?
<nckx>The error message is unfortunately generic though, obviously not made for this use case.
<nckx>jackhill: Always prefer attachments over fragile external links as long as they are ~1-2 MiB.
<nckx>.bz2 is fine.
<jackhill>nckx: super, thanks!
<nckx>If it's a few hundreds of KiB I think uncompressed is fine.
<nckx>That's more subjective.
<nckx>I get ‘transactional e-mail’ that is ridiculously bigger than that ☺
<jackhill>ha! I actually wonder how the zstd compression my filesystem does compares to the bz2
<jackhill>especially after the bz2 get base64 encoded in the email
<unmatched-paren>nckx: is there a reason why an (upgrade-from) field in a package declaration couldn't be added to guix?
<jackhill>right, must focus, I'm supposed to be reporting a bug, not going down a curiosity rabbit hole!
<nckx>Not fundamentally. The only reason would be if the code overhead / usage ratio were too high.
<unmatched-paren>so you'd do (package #|blahblah|# (upgrade-from 21) #|blahblah|#)
<unmatched-paren>or maybe in the version field
<unmatched-paren>(version "1.0" #:upgrade-from "21")
<nckx>jackhill: zstd outperforms bzip2 both in speed and compression. The relatively low level used by most transparent uses like file systems will not reach bzip2 sizes (but it will be close, and *much* faster). If you can set the level by hand, you can get better compression than bzip2 that's still faster.
<nckx>unmatched-paren: No, it would just be a property like superseded is.
<nckx>s/uses/users/, I guess.
<guixy>Generated .bashrc doesn't check if /etc/bashrc exists before sourcing it. The resulting script is broken in derivatives of Debian like raspberry pi os and armbian.
<guixy>generated with guix home
<nckx>Broken how?
<guixy>-bash: /etc/bashrc: No such file or directory
<nckx>But what breaks?
<guixy>And I think it prevents phosh from loading
*nckx looks up phosh.
<guixy>the "desktop environment" used by armbian
<unmatched-paren>'phone shell', right?
<guixy>yes
<nckx>Aha.
<unmatched-paren>based on gnome?
<guixy>yes
<unmatched-paren>it's used on purism's phone's iirc
<unmatched-paren>*phones
<guixy>Yes. Both PureOS and Mobian use it.
<unmatched-paren>right
<nckx>This should not break anything. This sounds like a bug in phosh.
<guixy>I'll check that it's the problem. But it also bugs me a little that the script generated by guix home tries to source a file that doesn't always exist without checking if it exists. It isn't good form.
<guixy>Replacing the dotfiles with what's in /etc/skel and rebooting fixes phosh. I'll try to send a bug report to the phosh developers.
<unmatched-paren>actually i have a question about (s)mac(k)os; does guix care about it? because the tree-sitter package declaration in nix has an if that checks if darwin is the OS, which i'm assuming is important to make the package work on mac...
<nckx>That's already been fixed on master. Failing when a shell emits something on stderr (or whatever is causing phosh to fail) is far worse form.
<nckx>WTH is smackos?
<unmatched-paren>macos
<guixy>crapple's os
<nckx>Oh. I got hungry there for a minute.
<unmatched-paren>as in (s)mac(k)os
*nckx wants Smackos®.
<apteryx>nckx: I see! thanks for the precision
<nckx>unmatched-paren: I have no idea what that means, sorry. But no, we don't care, at all.
<unmatched-paren>so if i were to make a tree-sitter package, would i need to copy over said check, or do we just not care about macs
<guixy>Do we even care about *BSD?
<unmatched-paren>it's a check in the nix package for treesitter that does some patch thing if the OS is mac
<nckx>Again, no.
<unmatched-paren>so i'll just ignore that bit
<unmatched-paren>:)
<nckx>guixy: Not at the moment, but unlike Macintosh it's just pragmatic. Guix doesn't, I believe, currently run on any BSDs.
<guixy>Isn't there a linux/bsd compatibility layer that can theoretically run guix?
<nckx>If it can be made to run on a free BSD-alike, and the maintenance costs aren't excessive, it could be supported. Of course we should all be working on the Hurd instead ☺
<civodul>rekado: were you looking at lib2geom?
<civodul>i pushed a couple of i686 fixes, that one could be my next target if nobody beats me at it
<dstolfa>guixy: yes, FreeBSD's is most up to date, though i'm not sure if it can run guix or not
<dstolfa>it can certainly run ubuntu, EL, alpine, void and arch
<dstolfa>i would assume it can run guix, but i haven't tried
<nckx>Interesting, thanks.
<ArneBab>mbakke: thank you for your answer!
<unmatched-paren>it would be interesting to see guix ported to hyperbolabsd when that comes out, although they probably wouldn't want it given how much they despise rust :)
<dstolfa>unmatched-paren: hyperbolabsd is based on openbsd which can't service linux syscalls
<unmatched-paren>ah ok
<Noisytoot>Hurd can't either.
<apteryx>we just need a linux-syscalls translator
<nckx>unmatched-paren: Good thing they have no say in the matter 😛 But yeah, maintaining a Linuxy emulation layer for a (hypothetically) hostile upstream is a poor use of limited hands.
<unmatched-paren>at least Replicant won't be lonely in that free non-gnu operating systems table :)
<unmatched-paren>*anymore
<nckx>Is HyperbolaBSD anywhere near usable?
<unmatched-paren>i'm not sure it's even released yet
<nckx>Last I checked (long ago) it was a weird git repo with many seds & renames run on OpenBSD. Nothing more. I left.
<nckx>I hope they've made progress.
<Franciman>I wish, nckx
<Noisytoot>OpenBSD is usable, and anything that runs there should run on HyperbolaBSD
<Franciman>but nope
<lfam>While trying to use `guix weather` to check for substitutes from our build farm, it fails with this: https://paste.debian.net/1220703/
<nckx>
<lfam>What am I missing?
<nckx>lfam: I did see your CONFIG_GCC_PLUGINS message but I'm as stumped as you.
<lfam>Yeah, who knows
<nckx>It obviously exists in the code.
<nckx>🤷
<lfam>It's not hard to reproduce
<unmatched-paren>a free BSD is an interesting idea but is probably significantly more difficult to do than a free gnu/linux
<lfam>Find our 5.9 config in the Git history, copy it into the source tree, and do `make oldconfig`
<nckx>Yes OK subtle point taken. I did that.
<lfam>It's more an encouragement to others to help :)
<lfam>How to enable CONFIG_GCC_PLUGINS for 5.10 kernel?
<lfam>It's there in 5.4, and after 5.11, but I can't figure out how to make the kernel configuration offer it for 5.10
<unmatched-paren>urgh i'm reading nix pills and that path-as-a-fundumental-datatype thing is horrifying
<lfam>It would be nice to figure out
<dstolfa>unmatched-paren: the BSDs are already free, or do you mean fully deblobbed?
<unmatched-paren>fully deblobbed. according to hyperbola, some of openbsd itself is technically proprietary since those parts don't have a license. not sure if that's actually true.
<unmatched-paren>plus they're removing bits under the old gpl-incompatible original BSD license
<guixy>If a component isn't fully deblobbed it isn't free. That's why linux-libre exists.
<dstolfa>openbsd, just like any BSD, happily loads firmware blobs into devices. they are probably referring to that, as i'd be really surprised if their actual OS code was missing a license (unless explicitly pulled from something in public domain)
<lfam>No true scotsman...
<Noisytoot>dstolfa, OpenBSD installs nonfree firmware without even asking the user: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.653&r2=1.654&f=h
<dstolfa>Noisytoot: yes, that's literally what i said
<Noisytoot>It used to ask the user.
<lfam>It wouldn't make a different from the GNU point of view if it asked
<Myrcy>I use to be a huge fan of the LibertyBSD project until it became no longer maintained
<rekado>oops, this is not good: [12779.241820] thermal thermal_zone6: critical temperature reached (95 C), shutting down
<dstolfa>rekado: that is indeed not good
<rekado>I guess these aarch64 boards need more fans
<nckx>Goodbye build nodes.
<nckx>…or that.
<Myrcy>I have been told Hyperbola is becoming a good source for users who liked OpenBSD and GNU philosophy
<nckx>Both of those users will enjoy it tremendously.
<utis>i tried making a swap file, but echo disk >/sys/power/state gives `PM: Swap header not found!'
<nckx>Did you swap it on?
<nckx>Oh, file.
<nckx>Make a partition, not a file.
<utis>i think so
<Noisytoot>but it would make it easier to have a fully free installation of OpenBSD.
<utis>that's a bit hard if it's to be encrypted, isn't it?
<nckx>Swap file hibernation isn't supported.
<utis>in that case, should i use lvm on luks, or will something else be simpler?
<unmatched-paren>ah i've found the bit about some parts of openbsd not having a license, it's in this interview: https://itsfoss.com/hyperbola-linux-bsd/
<unmatched-paren>The non-free files in OpenBSD include files without an appropriate license header, or without a license in the folder containing a particular component.
<unmatched-paren>again, not sure how true that is exactly
<roptat>any java expert who would know what "Scope org.apache.maven.execution.scope.internal.MojoExecutionScope@1a193b10 is already bound to org.apache.maven.execution.scope.MojoExecutionScoped" means? :)
<easbarbosa>yep, im about to move on to Guix System after reading that they are really after flatpaking EVERYTHING!
*roptat is trying to update maven
<easbarbosa>Debian will eventually have to give up too
<apteryx>I get frequent lag with SSH in screen; I wonder if it comes from screen, or just the network. perhaps I should try mosh.
<lfam>apteryx: To berlin?
<apteryx>also to my own offload machine
<lfam>Hm
<dstolfa>easbarbosa: flatpak actively makes me sad with its terribly unusable "sandboxing" model
<dstolfa>every time i give it the benefit of the doubt, i get horribly disappointed
<lfam>I use mosh wherever possible to ease the latency annoyance of interactive work
<apteryx>lfam: I'll try without screen for a while to see if there's an improvement
<easbarbosa>dstolfa: everything about it is lame, sandboxing aint real, disk and memory are horrible, a runtime to run a fcking calculator! TERRIBLE
<easbarbosa>*usage
<easbarbosa>more on it: https://ludocode.com/blog/flatpak-is-not-the-future
<apteryx>civodul: one thing I wasn't sure about was leaving polkit* a public, after seeing a comment in pkg-config.scm about %pkg-config doing the same, supposedly for fold-packages
<jab>So I managed to bork my guix system laptop.  Guix is still installed, but I must have messed up grub somehow.  When I boot the laptop, grub says that it cannot find some file.  Which I'm not certain how that would be happening...I'm using osboot, so it should have grub bundled in there anyway....Anyway and pointers for how I could go about
<jab>fixing this w/o having to just reinstall?
<utis>is hibernating to an encrypted swap partition a problem?
<zimoun`>rekado: thanks for python2-*
<apteryx>I'm getting this while substituting: guix build: error: integer expected from stream
<rekado>apteryx: this sounds familiar… wasn’t there a bug report about this?
<apteryx>rekado: oh yes, from nckx: #51983
<rekado>re aarch64 build nodes: I’ll first try to give the components more space. The silverstone milo 10 has two heights.
<apteryx>nckx: I LGTM'd that patch of yours
<rekado>I picked the lower height because we only have a single SSD. But I guess having a bit more space above the CPU fan would help.
<apteryx>nckx: perhaps the "integer expected from stream" occurs when the host (berlin) runs out of inodes?
<apteryx>I've seen the "too many files opened error" today a few times on it
<apteryx>just a wild guess though
<rekado>I could mount up to three case fans that blow air from the side. I just don’t have any that would fit.
<rekado>guess I’ll have to throttle the CPUs for the time being
<apteryx>jpoiret: haven't been able to reproduce in QEMU yet. Perhaps related to my use of the nouveau driver.
<apteryx>I'll test my actual config instead of a minimal example in 'guix system vm' next.
<apteryx>(about my failure to login)
<f1refly>I just changed my luks2 keyslot to use pbkdf2 instead of argon2i, so it should be supported by grub now. I ran guix system init with the configuration i adapted from the windowmanager sample and it ran through without issues, but after rebooting grub couldn't find the lvm volume my root resides on
<f1refly>is there more to it than to define the luks volume and the lvm volume as mappers and the root and home filesystems in the filesystem declarations to get grub to decrypt the root?
<f1refly>All my experience stems from arch where it's common to have a unencrypted /boot, so I don't really know where to begin debugging this
<jackhill>f1refly: here's my encrypted lvm setup (with EFI partition outside of LVM) https://paste.debian.net/1220707/
<jackhill>f1refly: can grub do luks2 even with ppkdf2 or does it still only support luks1?
<f1refly>Thank you, I'll check it out. My setup is on legacy bios though, I don't know if that's going to be a problem
<jackhill>f1refly: I don't think it should, as long as you're getting the grub menu with guix-y looking options, then that part should be good.
<f1refly>jackhill: https://issues.guix.gnu.org/51514
<f1refly>according to this luks2 should be supported when ppkdf2 is uesd
<f1refly>I did not get any options since grub.conf cannot be loaded i think
<f1refly>which makes sense, since it's in /boot/grub/grub.cfg which is still encrypet
<jackhill>f1refly: oh, aweomse I'll have to give that a spin, thanks fo pointing it out. I suppose there could still be a bug lurking jpoiret is in the channel sometimes :)
<jab>By the way I did find this:  https://www.hackerearth.com/practice/notes/akshaypai94/grub-rescue/
<tom42>Straw poll... I'm running out of RAM due to lots of VMs on my desktop. Should I upgrade from 2x8GB RAM to 4x8GB or 2x8,2x16?
<jackhill>f1refly: er, I see I pasted the my wrong config, that one doesn't have luks, let me try again…
<tom42>Latter is more future proof, but more expensive.
<f1refly>jackhill: i just wanted to complain :)
<jackhill>f1refly: ah, ok, a good activity :)
<utis>jackhill: are you able to hibernate to an encrypted swap with your setup?
<jpoiret>f1refly: the patch is not yet merged into master
<f1refly>ohh, so that makes sense then
<jackhill>utis: hibernating is easy, it's resuming that's hard. The order we do thing in the initramfs needs to be changed to unlock first before resuming: https://issues.guix.gnu.org/49475
<jpoiret>sorry if that misled you
<jpoiret>you can still use it with a local checkout if you want
<f1refly>I don't think I can downgrade luks headers easily, can I?
<jpoiret>I don't think so
*jackhill pages nckx ☝
<jpoiret>there's a luks1 -> luks2 converter but not the other way around i think
<f1refly>luks1->luks2 is built in
<f1refly>Maybe I get the motivation to copy 2tb yet again to change luks headers tomorrow :|
<jpoiret>utis: hibernating to encrypted swaps will not work right now
<jpoiret>our initrd doesn't try to unlock swap dependencies before trying to resume. It is on my to-do list
<jackhill>jpoiret: have you seen https://issues.guix.gnu.org/49475 ?
<jpoiret>jackhill: the grub menu itself is configured in the esp partition, but the assets are in the store. So if you see a blue background on GRUB, that means that it couldn't open the store partition
<utis>all right. i'll come back in a couple of years, then
<jackhill>I just moved resume call, but potentially it could be made smarter to track the dependencies :)
<f1refly>thank you for your hard work anyways jpoiret
<jpoiret>jackhill: oh, no, I had not seen this patch. Tbf though i'd like to rework the initrd into something more modular in the long run
<f1refly>jackhill: can you share your encrypted setup config, for reference?
<jackhill>jpoiret: yeah, that was definitley we talked what would be minimally requiered here and it tried it, so decided to post it.
<jackhill>f1refly: sure, coming up shortly…
<unmatched-paren>jpoiret: i think i've found the error in the gdm log
<unmatched-paren>Gdk-Message: 17:49:34.246: .gnome-shell-real: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
<jpoiret>oh nic, i was just looking at them
<jpoiret>yes, that's what i got too
<unmatched-paren>oh you were? thanks :D
<jackhill>f1refly: https://paste.debian.net/1220713/ not yet converted to the new swap stuff
<f1refly>thanks mate, I'll figure the swap out after i got my system to boot anyways
<jackhill>+1
<unmatched-paren>jpoiret: i just thought you were away doing something else when i posted them, so i thought you might have missed them
<jpoiret>i scrolled back up :) can you change VTs before logging in?
<unmatched-paren>no, unfortunately
<unmatched-paren>no idea why
<unmatched-paren>there's a moment where the console login displays before gdm starts, but even there i can't switch
<unmatched-paren>sorry i disconnected for a moment because i tried to C-M-F2, which apparently disables wifi in GNOME
<unmatched-paren>there's this:
<unmatched-paren>(II) AIGLX: Suspending AIGLX clients for VT switch
<unmatched-paren>(EE) modeset(0): failed to set mode: Permission denied
<lfam>On core-updates-frozen, gst-plugins-bad fails to build, with "gst-plugins-bad-1.18.5/meson.build:1:0: ERROR: Unknown options: "transcoder""
<lfam>This breaks the build of GNOME
<unmatched-paren>isn't there some user group you can add to allow changing VTs? "terminal" or something?
<jpoiret>well, if you are in the wheel group, you can switch VTs, but you're not logged in yet in gdm so it won't work iiuc
<apteryx>I'm getting build failures for agg
<unmatched-paren>right that makes sense
<jpoiret>(that's because we have a catch-all polkit rule that sets users in the wheel group to administrative)
<unmatched-paren>but
<jpoiret>what's weird is that I can VT switch without any problems with your configuration in a vm
<jpoiret>hang on, do you see the GDM login screen? does it crash right after logging into GDM?
<unmatched-paren>even on the error screen, which appears to be a window in some sort of minimal GNOME of Death, i can't vt switch
<unmatched-paren>no, it happens after i log in to gnome
<apteryx>lfam: what? that's new
<lfam>I'm feeling confused apteryx. Digging in... there might be multiple derivations for gst-plugins-bad? Please stand by
<jpoiret>just checked, i can vt switch using your config. This is pretty weird
<unmatched-paren>gdm itself works fine, but as soon as i enter my pass and press enter, the GNOME Window of Death appears
<unmatched-paren>OH
<unmatched-paren>OF COURSE
<unmatched-paren>I'M AN IDIOT
<lfam>apteryx: Oh, it's a case where the package is instantiated with gst-plugins-selection
<unmatched-paren>my function keys are set to 'Media' in my BIOS!
<lfam>In the pitivi package
<apteryx>lfam: is pitivi bundling its own version?
<jpoiret>aha, classic. I switched them to Fns day one
<unmatched-paren>(this is a computer that apparently thinks it's ok to corrupt my GNU/Linux installation and reset my BIOS every once in a while. It's very annoying.)
<lfam>No, it's instantiating a special variant of gst-plugins-bad
<unmatched-paren>Yeah, i had them set to Fn, but my computer likes to reset it
<unmatched-paren>but the GNOME issue still applies
<lfam>sneek: later ask lilyp: Can you take a look at pitivi on core-updates-frozen? Specifically, the special gst-plugins-bad package variant is failing to build there
<sneek>Got it.
<unmatched-paren>at least i'm able to get to a VT and do debugging now :D
<jpoiret>great!
<unmatched-paren>once this computer is Well and Truly broken, i'm going to get one of the more... cooperative brands of computer ;)
<unmatched-paren>Sadly all the librebooted ones are from the stone age :(
<jpoiret>can you try `XDG_SESSION_TYPE=x11 GDK_BACKEND=x11 dbus-run-session startx /gnu/store/jhhv8cj4j4c8dp0cfxhahvbrkmm9iwh5-gnome-shell-3.34.5/bin/gnome-shell`?
<unmatched-paren>ok... i'll note that down and try it
<jpoiret>i guess i could try on the VM to see if it produces the correct result
<jpoiret>(that's completely off the top of my head)
<unmatched-paren>right ok
<lfam>From master to core-updates, the soversion of webkitgtk changed from 4.0 to 4.1, although the package version remains the same, at 2.34.1. Shotwell requires 4.0
<jpoiret>while logged into paren of course
<unmatched-paren>I wish I could buy a Librem, but they're really expensive, and the pinebook is an ARM, so stuff made for x86 wouldn't work...
<lfam>The pinebook is also going to be slow as molasses
<unmatched-paren>Yes, that too
<jpoiret>unmatched-paren: you'll need the `xinit` package I think, so you may need to do `guix shell xinit` beforehand
<unmatched-paren>why shell not install?
<unmatched-paren>Hardware is the... well, hard part of using free software :(
<jpoiret>you can install if you want, but that'll just pollute your user profile. We only need it temporarily, hence the shell
<unmatched-paren>I'll do that
<unmatched-paren>*then
<civodul>apteryx: re polkit*, i think it's fine to leave it public
<civodul>apteryx: however i realized that the macro trick doesn't work for situations like <polkit-configuration> records
<unmatched-paren>jpoiret: should i do it now?
<jpoiret>erm, no, it won't work
<unmatched-paren>ah
<jpoiret>sorry, let me whip up a working command real quick, to launch gnome-shell manually
<unmatched-paren>thank you for all the help :)
<apteryx>civodul: oh no; why is that?
<apteryx>doesn't it expand to a package by the time is is consumed by the API?
<unmatched-paren>Ifam: if the pinebook is slow as molasses, then all the ancient librebooted thinkpads are as slow as molasses cooled to absolute zero and stored in a totally heat-free vacuum chamber
<unmatched-paren>which, granted, may be an effective way to allow you to overclock them 1000x without them melting ;)
<lilyp>lfam: From the looks of it, the transcoder option was renamed to transcode
<apteryx>jpoiret: couldn't reproduce in QEMU
<sneek>Welcome back lilyp, you have 1 message!
<sneek>lilyp, lfam says: Can you take a look at pitivi on core-updates-frozen? Specifically, the special gst-plugins-bad package variant is failing to build there
<apteryx>I guess my problem is driver-related... but I'll try again shortly on real hardware
<lfam>unmatched-paren: Agreed, I have an x200 and it's also quite slow. But I suspect it's still faster than the A53 chip in the pinebook
<nckx>unmatched-paren: Pretty sure it's significantly slower than old Thinkpads.
<unmatched-paren>really? surprising
<lfam>It would be interesting to compare
<nckx>It's ARM.
<nckx>apteryx: Thanks! Especially considering I didn't add [PATCH].
<nckx>jackhill: About what exactly? Although I'm leaving again, but I'll be back later.
<unmatched-paren>anyway, looks like the librem is pretty much the only realistic option, and it isn't even that realistic because of the price
<lilyp>lfam: though interestingly, the same holds for 1.18.2
<lfam>It's not just ARM. It's a first generation chip for their new architecture, optimized for lower power consumption and without many architectural tricks (such as out-of-order execution) meant to speed things up
<lfam>We are at the point where ARM is competitive with x86_64 at the top end
<lilyp>perhaps a change in meson makes it so that typos are no longer corrected
<lfam>Huh
<lilyp>in any case, try rewriting "transcoder" to "transcode"
<lfam>Okay I'll try that
<lfam>Going back, maybe the Pinebook Pro, with a much more powerful CPU, would make a decent middle option. Although it's not for sale currently
<unmatched-paren>it's still ARM though...
<lfam>So?
<lfam>Oh, you want good compatibility
<unmatched-paren>not everything works on ARM
<lfam>I mean, you already have a computer right?
<unmatched-paren>Yeah
<lfam>It's easy to get hooked on the idea of acquiring new things
<unmatched-paren>I'm just contemplating future possibilities, especially since my laptop isn't particularly friendly to GNU/Linux
<unmatched-paren>For when it eventually dies, basically
<lfam>Thinkpads are a good bet
<lfam>I always buy Thinkpads that are between 3 and 6 years old
<lfam>At least in the USA, you get a lot of computer for not a lot of money
<lfam>They aren't as good as they used to be but nothing is perfect
<unmatched-paren>I'm in the UK :/
<lfam>I'd imagine it's the same there
<unmatched-paren>I mean, I'm not too low on money. I _might_ be able to buy a librem by the time this acer aspire dies.
<unmatched-paren>Not too likely though.
<lfam>I do think that, if you use your computer a lot, it's worth saving up for a good one
<unmatched-paren>yeah, exactly :)
<lfam>Or, the one you want
<lfam>And you can usually get some money back by parting out the dead laptop
<lfam>Not a lot but some
<unmatched-paren>especially as i do enjoy playing (libre, don't worry, no steam here!) games, and wish to make at least one in my lifetime
<lfam>lilyp: I tried changing "transcoder" to "transcode", and now the build fails with "../source/data/meson.build:9:0: ERROR: Function does not take positional arguments."
<henk_guix>HI guix
<lfam>Howdy
<henk_guix>I have a question I can't find the answer to: my guix pull is stuck on a channel, so I want to get rid of the channel..
<henk_guix>is that possible?
<lfam>lilyp: Sorry, that error comes from the Pitivi build, not gst-plugins-bad. Changing the "transcode[r]" string does fix the build of gst-plugins-bad
<unmatched-paren>The Librem does look extremely appealing though: neutralized ME, _nearly_ completely free, decent size, 2 NVMe slots, etc.
<unmatched-paren>Anyway, I don't think my Aspire is going to die anytime soon. We'll see.
<lilyp>which meson version is this? 0.60?
<lfam>Yeah. I'm trying with 0.59
<podiki[m]>henk_guix: yup, just remove it from your channels file
<ngz>henk_guix: channels are stored in ~/.config/guix/channels.scm IIRC. You may want to comment them there.
<lfam>I found apteryx's bug report upstream
<lfam>Upstream with Meson, that is
<podiki[m]>yes, the location ngz said unless you pass it manually with -C (i think)
<henk_guix>@ngz, thanks! unfortunately that's what I did, my commenting is just ignored
<ngz>henk_guix: That's surprising. Did you save the file properly?
<henk_guix>ngz I think so
<ngz>I don't understand, then. =/
<henk_guix>now I just removed the channels, maybe it's a dependent channel ;)
<henk_guix>now it's only pulling guix - yay!
<henk_guix>ngz thanks a lot
<lilyp>lfam on the webkitgtk 4.0 vs 4.1 thing, 4.0 is webkitgtk-with-libsoup2
<lfam>Oh
<lfam>So, we need to swap out the dependency in shotwell?
<lilyp>probably yes
<lilyp>most stuff doesn't build with libsoup3 yet, there's an upstream tracker
<podiki[m]>the webkit change has hit a few projects
<lilyp>and with that I'm off to sleep
<podiki[m]>I added a comment above the package def with the bug tracker
<podiki[m]> https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 (though I don't quite follow the table)
<henk_guix>ngz it turns out some element of guix itself was outdated and made another channel somehow not build - first pulling guix itself worked, then all channels worked again
<vagrantc>wow, i'm so confused. i submitted a guix lint patch regarding patch file length (which probably needs updating now) but i can't find reference to it now
<ngz>henk_guix: ok
<jpoiret>vagrantc: 51985?
<vagrantc>jpoiret: thanks!
<podiki[m]>hrm, geeqie error on c-u-f around clutter
<podiki[m]>if you run with GDK_SYNCHRONIZE=1 geeqie you get
<podiki[m]>or rather I get "Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found."
<podiki[m]>geeqie --disable-clutter works though (i'm not on Gnome or GDM)
<jpoiret>unmatched-paren: did that configuration ever work before?
<unmatched-paren>no
<jpoiret>i'm inclined to say it is a driver bug, but nothing beyond that unfortunately
<unmatched-paren>sorry, i have to go now
<unmatched-paren>o/
<jpoiret>you could try the core-updates-frozen branch, it may work
<jpoiret>that's just a wild suggestion though
<jpoiret>see you
<apteryx>podiki[m]: interesting, I get that too
<podiki[m]>any ideas why?
<podiki[m]>some version mismatch somewhere? I'm on X, btw
<bbsl>hi!
<bbsl>I am a bit lost wrt to where to start and I am hoping someone can point me in the right direction.
<bbsl>Here is my usecase:
<bbsl>I want to set up an environment with `guix environment --ad-hoc ffmpeg` but I want ffmpeg to have Fraunhofer/libfdk enabled. Reading the source of the package I can see that it is a defined a possible `#:configure-flag`
<bbsl>if this was on nix I would reach for an `overlay` but as I understand it there are no equivalents in guix?
<bbsl>so then I am wondering where to look? :) what is what I want to do called in guix?
<vivien>bbsl, you would define a package that inherits ffmpeg, while passing additional configure flags, and use that one package. See substitute-keyword-arguments in (guix utils), to just change the configure flags.
<ss2>That's a better answer. Just had something else prepared.
<vivien>For instance, see how mygui-gl in (gnu packages development) changes configure flags
<vivien>Or libnode in (gnu packages node)
<bbsl>ok will have a look. PS is there a command to look up the package source from the cli? (Iv been using the browser :))
<ss2>guix edit package
<vivien>guix edit <package> will put you right at where it is defined
<bbsl>aha ok ty :) same as nix then without the fluff
<vivien>For your use case, you might want to create a simple file ending with the package (write "(package ...)" and not "(define-public package (package ...))") and do guix shell -f file.scm
<vivien>(guix environment --ad-hoc is now guix shell)
<terramorpha>Hi everyone, is it possible to use os-prober to autodetect other distributions in grub?
<zimoun`>apteryx: I think julia builds fine and with parallel. \o/
<zimoun`>I am checking if julia-build-system also enjoy the new parallel build
<apteryx>zimoun`: awesome!
<apteryx>we'd have to set JULIA_CPU_THREADS at the julia-build-system level for it to work, no?
<apteryx>(for other julia packages)
<zimoun`>yep, I did it. I am checking it works as expected. :-)
<zimoun`>apteryx: I should send this v2 later this evening (for me) or tomorrow (for me); depending on how many hack it needs to work. ;-)
<apteryx>neat!
<apteryx>thank you for working on it!
<apteryx>podiki[m]: seems like it can't init clutter: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found
<podiki[m]>right, unfortunately I never even heard of clutter until recently...
<apteryx>isn't clutter required to run GNOME?
<podiki[m]>but maybe clutter wasn't built with some option? no other complaints about clutter errors that I remember seeing here
<zimoun`>apteryx:
<zimoun`>yw, you did the hard part
<zimoun`>how does GitHub work for sending a v2 for a PR?
<podiki[m]>apteryx: yes, somewhere in the Gnome system I believe (I think I'd see it come up when building GDM through some dependency)
<apteryx>zimoun`: you rewrite your branch and push to your fork
<apteryx>(git push -f)
<apteryx>not to be confused with mutter
<rekado>(finished building Linux + the system, then noticed that partitions aren’t numbered correctly, adjusted with fdisk, rebooted, kernel panic, dumb dumb, starting over…)
<zimoun`>apteryx, thanks.
<apteryx>rekado: ah! thanks a for the hard work of bringing these devices to life
<podiki[m]>apteryx: I don't see any obvious problems in the clutter package def, has the X inputs, configure flag that sounds helpful, no related changes in clutter NEWS file
<apteryx>podiki[m]: while we are looking at geeqie, do you also see a lot of check boxes in the browsing left pane?
<apteryx>I've always seen them, and it doesn't make sense.
<apteryx>there are 10 of thems left of each thumbnail
<podiki[m]>no I don't see any checkboxes
<apteryx>running from GNOME or something else?
<podiki[m]>not Gnome (xmonad directly)
<podiki[m]>but there are a bunch of options in geeqie, maybe it is some view for selecting multiple? or thinks it is a touch interface (makes me think of phone file selection)?
<apteryx>and if I left click in that browsing pane (show as icons), it segfaults
<apteryx>looks like some kind of 0-9 rating
<podiki[m]>hrm
<podiki[m]>I do see glitches in its display as I mouse through the menus
<podiki[m]>oh okay, if I try to display as icons it segfaults
<podiki[m]>just before that (not sure on what): (geeqie:1806): Gtk-CRITICAL **: 17:34:33.863: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkNotebook
<drakonis>apoorv569[m]: you're thinking of mutter not clutter here
<drakonis>oops
<drakonis>apteryx:
<drakonis>it is a library for gnome though
<drakonis>clutter, that is.
<Krey_LM>ping
*Krey_LM ain't sure if he needs reg
<nckx>You do not.
<Krey_LM>... and registering on IRC is painn
<Krey_LM>oh good
<Krey_LM96>tor dc
<Krey_LM96>u.u
<Krey_LM96>nckx, any idea why it doesn't work? Or is this a question for the forsksaken
<nckx>I have no idea what ‘it’ you're talking about?
<vivien>What’s tor dc?
<nckx>The Tor datacentre? Through which Tor routes all traffic.
<nckx>They route you through 3 randomly chosen racks for privacy.
<jpoiret>it's a process called orange routine
<jpoiret>routing *
<jpoiret>libera might scan for tor exit nodes iirc
<nckx>Iff you use Tor registration is mandatory.
<nckx>This is the deal.
<nckx>I happen to think it is a very fair deal.
<bbsl>vivien: I cant make my "overlay" work. getting some error message I cannot understand :o) would you mind having a look? https://0bin.net/paste/U0M+XbL1#ndddx2lNFALzlKMFIeEzcA1LcfE1pLr7xW0McXOtIad I even tried pasting one of the "hello" things into my file but I got the same output so Im thinking I am invoking this wrong.
<Krey_LM>tor dc = tor disconenct
<Krey_LM>which was wifi disconnect instead
<Krey_LM>bcs that wifi thing has a limit for wifi things and i just found it the hard way >.<
<nckx>I'm not familiar with Tor Disconnect.
<jpoiret>bbsl: you need to add (gnu build utils) to your use-modules i think
<Krey_LM>and not orange, but onion hmph
<jpoiret>or (guix build utils) i can't remember
<nckx>bbsl: (guix utils)
<Krey_LM>aaaaa i meant that i have problem with audio >.<
<Krey_LM>and no idea how to fix it on guix bcs this thing should work with pulseaudio
<Krey_LM>O.o
<vivien>How do you read the file? I get some JSON
<nckx>vivien: Enable moar javascripts.
<nckx>(Or don't, but it's one of those self-decrypting pastebin thingies.)
<bbsl>aha because `substitute-keyword-arguments` is in guix utils? :) well then "unboud variable" makes sense :o
<nckx>Yep!
*Krey_LM :(
<vivien>Oh right!
<Krey_LM>wait you can't see my messages?
<Krey_LM>o.o
<Krey_LM>u can bcs i can see them on log
<vivien>I can’t hear you I have my audio over tor ^^
<Krey_LM>it don't work without tor too u.u
<Krey_LM>just shows dummy output
<vivien>And that’s disconnecting so often
<Krey_LM>pfff tor-racist~