<Festerdam>GNUtoo: I do. The problem is not the disk space now. It's the early EOFs. But it seems to be going now. But I really do not understand why python needed 5 tries to download, if all the other packages downloaded fine.
<Festerdam>I'm currently copying to /mnt. It seems to be taking an unexpected long time. Does that step in guix system initially do anything else other than just copying as the message suggests?
<the_tubular>Where can I read up on that news : Improved static networking support on Guix System ?
<podiki[m]>Festerdam: I don't remember it taking long time, but will obviously be limited by whatever is slowest (reading/writing devices)
<podiki[m]>the_tubular: I'm not sure, was certainly discussed here (you can check the logs), otherwise recent git activity maybe?
<Festerdam>podiki:It's reading from a USB flash drive and writing to another USB flash drive. Only one of them is in a USB 3 port. But I don't think it should make it take that long. (in 20 minutes it got to a half)
<nckx>From (lack of) context, I guess the answer to that last line is ‘probably’.
<podiki[m]>nckx: I guess the bridge does not respect bans/mutes? I'm on my own homeserver and can do that manually on my end
<podiki[m]>as for the python sanity check, at least in guix build it shows the module, though you have to look carefully sometimes; I would think that all ends up in the build log, if not that should be a bug?
<nckx>Hm, no, I'll just restore the kickban then. I thought +q was more humane but it seems quite the opposite and a total shitshow across bridges.
***ChanServ sets mode: +b *!*M6piz7wk*@*
***M6piz7wk[m] was kicked by ChanServ (User is banned from this channel)
<cehteh>i am pretty sure its just the zillions of seeks its doing and maybe fragmentation or at least things are extremelys scattered acros the disks (i seen similar problems with the backup servers here) .. did the filesystem filled up more than 90% once?
<cehteh>possibly not, the things might be not even fragmentated but just scattered
<cehteh>and e2defrag (i have a quartery job at low pri) takes ages, your deletion time is nothing against that :D
<cehteh>dunno if it helps any, it wont hurt, but it runs for days and takes some io bandwidht on its own
<cehteh>first thing you can really do is doing this deletion in background/atomic by moving the to-be deleted trees out of the way .. but because of deduplication significant space is only freed when the last hardlink of a file is freed, i try to address that with the rmrfd
<civodul>it's the plain "rm -rf" phase that's taking time
<cehteh>anyway i am going on .. managed to reduce the inventory scan in ram from 25GB to 4GB already ... working on reducing it more which means no database is necessary, just in ram datastructures (mind you i am testing with my whole backup set of 200Mio files here, i think you have less)
<cehteh>mv foo foo.delete; rm -rf foo.delete & ... and call it a day
<cehteh>as stopgap for now then foo becomes available again and you dont need to lock it
<mothacehe>what about rebooting? is there some cleanup when the fs is mounted? sorry for the fs newbie questions
<cehteh>fsck will collect any not properly deleted files and wil ltake long time by that as well
<cehteh>rekado: did you read my descrition .. when you can bacground deletion in a atomic way, then you can run it at low io prio and just dont care how long it takes
<cbaines>I do wonder if latency here is an issue, and if running rm -rf in parallel would speed things up
<cbaines>might be possible to test with manually running rm -rf, perhaps with the parallel command?
<cehteh>the only thing i put efforts in is now sorting files to delete the ones which free the most space at first
<rekado>cehteh: well, we’re not only looking at this in isolation. The daemon deletes things on GC. We want to fix GC, so that we don’t have to do a manual deletion going forward.
<cehteh>maybe 2 delete processes may work in parallel .. fill some gaps in the io bandwidh, but too much would cause even more seeking and slowdowns, its really the 3-5ms head positioning time and spindle rotation until it hits the place where data has to be written which kills the throughput here. meet the physical world :)
<cehteh>rekado: thats why i am doing the rmrfd now, the gc run may use it eventually finding roots and live objects is one thing, but deleting dead object should not lock the gc/guixd/store that could be done lazily in the background, by definition when objects are dead then nothing needs them anymore
<rekado>another option for the future: separate volume on /gnu/store/trash; trash the whole volume.
<cehteh>dont do that .. moving things to trash will be expensive
<cehteh>yeah i read somewhere that deelting by rsync is slightly faster but i think it wont matter, what matters most is that you get rid of the lock and background the deletion (possibly ioniced otherwise normal operations of the server may slow down too much)
<civodul>cbaines: "rm -rf" in parallel doesn't seem to speed things up, on the contrary, from what i tried a few days ago
<civodul>rekado: /gnu/store/trash is meant to be on the same fs as /gnu/store: that way, the main GC phase can rename(2) things instead of actually deleting them, thereby reducing the time spent with the GC lock held
<civodul>IOW, it defers "rm -rf" until after the GC "mark" phase
<cbaines>but the idea is that this approach can also be used for mirrors as well, just download the database, which means you can serve narinfo requests, then reverse proxy nar requests to bordeaux.guix.gnu.org (with caching)
<civodul>is there a way to sync the database without donwloading it all every time?
<cbaines>yep, at least I've designed one, and it's mostly implemented
<cbaines>(it should be able to handle additions, I still need to implement removing nars)
<AwesomeAdam54321>goops-error(#f "No applicable method for ~S in call ~S" (#<<generic> provided-by (1)> (provided-by #:oneshot?)) ())
<AwesomeAdam54321>It turns out there was an extra parenthesis that I missed that shouldn't have been there
<cbaines>mothaceh`, PurpleSym 604880ae2 did change something in that area, but I doubt that change has actually made it to where substitute downloads are handled yet (I think that requires updating the guix package)
<cbaines>PurpleSym, if you do report a bug, it would be useful to know what package/store item you're using for the guix-daemon
<PurpleSym>Submitted as bug#52464, cbaines. I included the commit, is that enough?
<Festerdam>I made a notable USB guix drive, with the configuration file generated by the graphical installer when doing full disk guided partioning. It seems now however that I'm unable to boot the new USB drive (it isn't listed in the boot manager).
<jpoiret>Festerdam: let me explain some efi bootloader basics. efi booting differs from legacy in that you don't just boot from a device, like in the old days when a bootloader was embedded in a specific gap inside the MBR partition structure. Instead, EFI firmware can read actual partitions, and boot EFI applications from there
<jpoiret>so, when you install EFI bootloaders, you simply install an EFI application inside of an EFI partition.
<jpoiret>that's where removable storage is annoying: you don't have access to the different devices you will want to boot from, and so cannot change the EFI variables of those to have a new bootloader entry for them
<civodul>rekado: can you reach berlin.guix.gnu.org from the inside?
<civodul>i get ECONNREFUSED when connecting to bp7o7ckwlewr4slm.onion, as if sshd was not running
<jpoiret>there are workarounds for this: EFI can actually boot into a device without having a specific bootloader entry for a specific application, if it is exactly named /EFI/BOOT/bootx64.efi (fat partitions are case-insensitive iirc)
<jpoiret>that's what the --removable option of grub-install does
<jpoiret>now, for our own use-case (guix, that is), there's no easy way to specifiy --removable for grub-install with a `guix system init` command, but the `guix system image` command takes into account the fact that it'll be booted by removable storage, so that's what you want to use
<rekado>I also lost connection to all our servers.
<jpoiret>completely unrelated: do we want to move service-ish things that should be run as user into (guix home) and encourage users to use it? it would be the cleaner option but has the drawback of being one more guix subcommand to run and manage,
<jpoiret>think pulseaudio/pipewire for example, which ought to run session-wide rather than system-wide
<jpoiret>that would mean that oob support after using the graphical installer will be significantly reduced, unless we also add a (guix home) step for all added users (which could be a possibility as well)
<jpoiret>context: for now pulseaudio runs fine system-wide, but the more supported and widely run configuration is session-wide, and pipewire/wireplumber will not run system-wide unless we carry our own non-default configuration that disables all session-related stuff
<mothaceh`> jpoiret: pushing (guix home) for user services such as pipewire could make sense I guess but that's a major decision and we should maybe discuss it on devel instead.
<jpoiret>right. I'll send something along those lines this afternoon
<mothaceh`>in the installer context that would indeed probably mean an extra step to initialize the homes of created users
<civodul>efraim: "guix style" makes syntactic transformations like ("glib" ,glib) -> glib
<civodul>so i think this kind of surprise is very unlikely
<dissent>hey guix. i've noticed two things while using icecat these past few months. first is that sometime audio comes out slowed and distorted. secondly, i am unable to paste anything while using discord. has anyone else run into these issues?
<civodul>efraim: what i'll do is run "guix style" (without args), push it, and check on ci.guix that it didn't trigger any rebuild
<jpoiret>another thing: does anyone know if including support for wsl/wsl2 in the guix repo would be ok, license-wise?
<civodul>later i'll try "guix style --input-simplification=safe" and see what can be done with little rebuild
<civodul>jpoiret: what would it take? my understanding is that WSL2 means that we don't have anything to do on our side, no?
<civodul>(fun fact: a colleague reported just today that an intern is running Guix on WSL2)
<vdv>don't think that it would be a problem license wise
<jpoiret>although i encountered some reproducible segfaults while compiling some things, that i blamed on wsl
<Festerdam>jpoiret: --grub-install doesn't seem to be a recognized option. Full command is now «guix environment --ad-hoc grub-efi --grub-install --boot-directory=/mnt/boot --efi-directory=/mnt/boot/EFI --removable»
<jpoiret>let's just say that in the whole desktop stack, many things took a bit of time to support elogind, even though it's a drop-in replacement for logind. libseat would be an other beast entirely, given how many things depend on logind :(
<jpoiret>although I agree that the seatd approach is saner
<jpoiret>i'd advise reproducing the problem with LD_DEBUG on (no backtrace needed) and seeing what LD says about gstreamer
<jpoiret>davidl: personal opinion only, but I think that the patches that guix should include in its world packages should only be related to integration with guix itself, or to backport upstream fixes before a new release. I don't know how others feel about this though
<jpoiret>the line blurs when we need package patches to make software comply with the `guix system` workflow, eg the patch I did for GDM that makes it pass additional env variables to the sessions.
<jpoiret>apteryx: as an example, when screensharing on icecat, libwebrtc needs to load pipewire libs, but when it cannot find them it fails silently. The difference is that it has stubs for the pipewire functions that handle it not being present, while it doesn't seem to be the case for you
<jpoiret>and by 'cannot find them' I mean 'cannot load them' of course :)
<Festerdam>Ok, mamães to mais a bootable guix USB flash drive.
<davidl>jpoiret: I agree with that in general. This case with guile-bash> an outdated package that don't have a real maintainer anymore but which can be made significant improvement by a small patch - what are the options? Well, should it be added to guix in the current package or should someone fork the original source, add the patch there and guix add a new package called guile-bash-fork or something else?
<Festerdam>*Ok, I finally made a bootable guix USB flash drive.
<jpoiret>davidl: i think that'd be the best way, but that would imply committing to maintaining a fork :)
<davidl>jpoiret: right, which Im not able to other than the small patch. So should the patched version just not be available in guix?
<jpoiret>middle ground: make your patch available somewhere, document that it exists, and users in guix will be able to just `guix package -i --with-patch=guile-bash=yourpatch.patch guile-bash` if they want to do so!
<jpoiret>it's not an upstream patch, and it isn't a security/guix compatibility fix, so i'm not sure it should be
<davidl>jpoiret: another option perhaps - can the patch be added in gnu/packages/patches but not applied by default?
<jpoiret>generally, you want to avoid patching upstream code as much as possible, because in the case something goes wrong, it would most likely be reported to upstreamed who will not have the same codebase to investigate
<jpoiret>davidl: i'm not sure guix would want to be responsible for such a patch in any case. I think it's outside the project's scope, but again, someone more involved with guix may have a different opinion
<taterbase>I am trying to flash the latest libreboot and I am running into an issue where the documentation recommends setting "iomem=relaxed" on the kernel parameters. I am still a relatively new user and unfamiliar with how I might do that for guix
<jpoiret>and to be frank, guix already supports what you want: you can apply patches on software you install very easily
<jpoiret>you can just have (kernel-arguments (cons* "iomem=relaxed" %default-kernel-arguments))
<taterbase>I am so sorry, someone was just giving advice on how to set kernel parameters for "iomem=relaxed" and I got confused with my irc client and disconnected, could you please repeat what you said (sorry :( )
<Festerdam>Xorg didn't store my keyboard layout so logging in in gdm also fails. How do I change the layout?
<AwesomeAdam54321>< jpoiret> you can just have (kernel-arguments (cons* "iomem=relaxed" %default-kernel-arguments))
<taterbase>Thank you, where would that particular string go? I have yet to configure anything in guix yet
<jpoiret>kernel-arguments is a field of the operating-system record type :)
<taterbase>oh so is (locale "whatever") considered a kernel-argument?
<ns12>Hello, in the custom phases of a package, what is the difference between (assoc-ref %build-inputs "...") and (assoc-ref inputs "..."), where "inputs" comes from (lambda* (#:key inputs #:allow-other-keys) ...)?
*raghavgururajan reacted "Oh mamma mia" on reading about `guix home` in the manual
<taterbase>Does guix system reconfigure rebuild my whole guix setup? Like redownload everything even?
<ns12>jpoiret: For example: #:make-flags (list (string-append "PREFIX=" %output)). Is the use of %output going to be deprecated for #:make-flags too?
<ns12>Or is the use of %... deprecated only for #:phases?
<taterbase>oh wow, it sounds like reconfigure is used for upgrading too? That's awesome
<taterbase>This reconfiguration is taking a while so I'm just gonna let it do its thing, I am wondering however, if I had put s-expr inside the operating-system incorrectly, would reconfigure fail early so I would know?
<jlicht>taterbase: if it's such a significant error that the last expression in your config.scm does not evaluate to a valid operating-system record, you would notice pretty early
<jlicht>If you are waiting for a while, it means that guix was able to make sense of what you are asking it to do; it might still run into issues much later in the process in actually working through its to-do list of course :-)
<AwesomeAdam54321>taterbase: I also think you can do guix upgrade when you want to upgrade, rather than guix reconfigure
<taterbase>Another wonderful tip thank you! I admit, I was terrified to give guix a try because it felt less populated than other distros, but the documentation is phenomenal and this irc chat has been very helpful
<jpoiret>if your system can do it, i suggest using -vga virtio (but that's unrelated) :)
<jpoiret>can you try by removing the `-nic user....` parameter?
<sozuba>i guess it could, I will do that:) It's been more than a year since i used qemu. I used to qemu boot into my dual installed windows for work, i guess i used something like that. The machine is the same though, just that i swapped HDD for testing
<sozuba>jpoiret, sure I even tried this, just fyi -> sudo qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -device virtio-net,netdev=network0 -netdev tap,id=network0,ifname=tap0,script=no,downscript=no,vhost=on -boot menu=on,order=d -drive file=guix-system.img -drive media=cdrom,file=guix-system-install-1.3.0.x86_64-linux.iso
<sozuba>oh yeah i did try removing the -nic user too, i remember. But will do it again for the sake of clarity
<jpoiret>nah, you don't need to sudo qemu (i wouldn't advise it at all even, you never know what exploits VMs are)
<jpoiret>alright, for me, `-nic user,virtio-net-pci` requires `-enable-kvm` which is understandable
<jpoiret>in general, iiuc, if you have anything virtio related, you *need* kvm
<sozuba>jpoiret this is just a test machine, so i am not worried about exploits at the moment. I had to sudo to create the tap device, other wise it would end up in permission error. When i use tap devices in the script, i first create tap devices using sudo and then use qemu without sudo :)
<sozuba>i think the problem is with my network connection... or the way i am connected. I am using Iwd to connect to wifi.
<sozuba>jpoiret i always use -ebnable-kvm, though it was the sane thinkg to do performance wise or functionality wise, never bothered to check for actual document :D. But thanks, now i know its requirement for -nic ...
<jpoiret>it's also a requirement for the -device virtio-net i think
<sozuba>jpoiret oh okay. i tried creating a long file using the -D switch, emoty log file.
<sozuba>may be i will copy my windows qemu file and modify it for guix, incase the entire issue is related to soemthing that i've mmessed up with installation as this is purely a test system now
<jpoiret>if what i suggested doesn't work, you may have to wait for someone else to help you, i don't know much about how qemu handles networking
<jpoiret>i don't think you've messed up the installation (unless you compiled qemu from source)
<raghavgururajan>So when using guix-home, what would be different between having packages in ~/.guix-profile and in ~/.guix-home/profile ???
<apteryx>civodul: one place we can't use 'guix shell' is when hacking on guix with 'guix shell guix' -> there's a guix.scm file that is not about an environment (source code of guix itself ;-))
<sozuba>nope, didn;t compile at all. Sorry i looked again. I can't seem to figure out what you suggested after, removing -net,user
<lfam>I have a WIP patch to add a package for 'opustags'. The program does work as packaged. However, the test suite fails to find the Perl dependency perl-list-moreutils, like this: <https://paste.debian.net/1223272/>
<guixy>Weird. Ran `guix system shepherd-graph` almost simultaneously. One was scripted to run after `guix pull`, the other just from scratch. The one after `guix pull` complained like before the pull, but the one I called from scratch didn't complain.
<guixy>I piped results of grep to xdot. That's why it complained.
<guixy>Where does `guix system search` get the description field? It'
<florhizome[m]><f1refly> "is it normal that my X server is..." <- I actually was never sure if it ran or not when using xfce when i tried(it appeared it just crashed midsession) and Overall my graphical experience on manjaro had been smoother but i can't say why (my guix ssd is slower but idk If that matters that much) or if it's a general thing...
<AwesomeAdam54321>Grafts aren't necessary if you're willing to rebuild what's necessary, right?
<unmatched-paren>because so many things depend on libc (most things, i'd guess) the entire distro would be rebuilt on the CI and on anyone who's unlucky enough to catch the update before substitutes are produced on the guix server
<mbakke>nckx: I've fought a bit with sanity checks and can probably look into that package after dinner
<florhizome[m]>Well i don't have these packaged (only previous versions which will now become obsolete :)), and i don't think that's a good first package(-moment) :D though i don't really expect wl stuff to break much. Just wanted to give the hint ;)
<florhizome[m]><f1refly> "florhizome: I installed xf86-..." <- It wouldn't be firmware like that that ship with the kernel....
<florhizome[m]>For some things i'm pretty sure the upcoming update will help, f.e. webkitgtk 4.0 should help my nyxt experience, and i have a different Power Management/Fan Setup and building a lot of stuff over a session seems to drain the system but idk If that's all
<nckx>I might have a different opinion if ‘guix style’ weren't happening but I think it's necessary now.
<florhizome[m]>nckx what is guix style again? Your making it super interesting :D
<apteryx>civodul: I'm ready to push c-u-f as it is into master; if that's OK with you
<unmatched-paren>according to ~~pop science authors~~ chaos theory mark zuckerberg dropping a pen at the facebook office could cause a tornado in brazil! omitting that tornado might cause a package to build differently!
<civodul>apteryx: wait wait, i'd like to do that extra input simplification round :-)
<nisha>Hi folks! I am trying to install guix on an Ubuntu Vagrant box (hint - I'm new). When running guix install hello I get booted out of my vagrant box. When I ssh in and try again I get this error: guix install: error: fport_read: Connection reset by peer