<GNUtoo>Festerdam: I guess you still have some free space on the computer you install Guix on? <jpoiret>Noisytoot: the btrfs file-system that holds the swapfile <nckx>Festerdam: What's its URL? <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. <GNUtoo>So maybe it's what it seems to be: the network connection breaks somehow <Festerdam>nckx: default server and Bourdeaux. Don't know how to see which it is downloading from. <nckx>Do you know if it's downloading a substitute or a source tarball (which are not hosted by Guix)? <nckx>I guess it doesn't matter now, since it'd just succeeded when I asked. <jpoiret>source tarballs should have filenames ending in .tar.xz or similar <nckx>All else is just chaotic neutral. <Festerdam>nckx: I don't know how to see that, but if it is a source tar ball it would explain why all other packages are doing fine but python wasn't. <nckx>So I think I managed to ‘fix’ my corrupt db.sqlite by ‘guix system init /etc/guix/system.scm /tmp/guix’, then copying that database to /var/guix/db. <nckx>This operating system distribution, if I hadn't mentioned it before, is really cool. <civodul>that said, the trick doesn't really gives you a "correct" db; you're still missing store items, right? <KE0VVT>I talk to Andrew Tropin about Guix Home, and he wants me to install RDE. <nckx>The organism is slowly rebuilding itself. <nckx>Mainly through overly nested bash loops. <nckx>There seems to be a valid path from ‘what I have’ to ‘what I need’ for everything, although I can't formally prove it, I just want my work laptop back ideally without downtime :) <nckx>Running the final GC will be nerve-wracking. <podiki[m]>jpoiret: with that don't need needed-for-boot in that filesystem/subvol? I wasn't sure where it goes in new system, so I kept in filesystems and kept swap space just a target ***ChanServ sets mode: +b *!*M6piz7wk*@*
***M6piz7wk[m] was kicked by ChanServ (User is banned from this channel)
***ChanServ sets mode: +o litharge
***litharge sets mode: -o litharge
<lispmacs>is there anywhere here using Guix system and a pci-express x16 graphics card? I'm trying to find out what graphics card work for other people on Guix <singpolyma>lispmacs: I don't imagine any discrete card will work awesome with pur guix system <lispmacs>Is everybody just using intel chipsets, then...? <lispmacs>singpolyma: what are you using for a graphics system? <singpolyma>lispmacs: I use guix on Debian, I'm not a system user ***ChanServ sets mode: +o litharge
***litharge sets mode: +q *!*M6piz7wk*@*
***litharge sets mode: -o litharge
***ChanServ sets mode: -b *!*M6piz7wk*@*
<lispmacs>I guess back to my original question then, slighty modified: any Guix system users have a working graphics setup? What are you using for graphics system? <nckx>I feel like ‘graphics system’ is likely a loaded term in this question? *nckx has ‘bitmap graphics’, yes. <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) <Festerdam>About half an hour ago it was on half. Now it's 3 quarters. <nckx>I have USB drives that manage <1 MiB sustained write. <nckx>Not really something we can answer from afar, but implausible? No. <podiki[m]>yeah, just takes one slow device (or slow controller), and always seems faster/optimistic when it starts, to exponentially decaying <nckx>Yeah, caching is magic, until it isn't. <nckx>I'm sure the new 'sanity-check phase is a great leap forward in reliable Python packaging, but there is absolutely no error reporting. Just a backtrace. I don't speak Python so I'm stuck. <nckx>%exception #<&invoke-error program: "python" arguments: ("/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py" "/gnu/store/8hai29vd2ca23r997mcxpngc8shiwa6r-python-setuptools-scm-git-archive-1.0/lib/python3.9/site-packages") exit-status: 1 term-signal: #f stop-signal: #f> <nckx>Backtrace was too generous. <nckx>Interestingly, the Python code actually looks like it *should* generate copious backtraces if something goes wrong. <nckx>Maybe this error wasn't planned? <nckx>ERROR: setuptools-scm-git-archive==0 The 'setuptools-scm-git-archive==0' distribution was not found and is required by the application <nckx>There we go. That wasn't in the log file. <podiki[m]>didn't make it into the build log? odd; though I tend to use guix build when I see them <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)
***ChanServ sets mode: +o litharge
***litharge sets mode: -o litharge
<nckx>The log file was incomplete in general, I'll just chalk that up to ‘unrelated weirdness’ because the build was offloaded and weirdness seems to accompany that sometimes. <nckx>I have now learnt a new lesson about managing a Matrix-bridged channel. Sorry about that. <nckx>I never saw the sequels so my teen memories remain relatively unspoilt. <nckx>Which Matrix client do you use, podiki[m]? <podiki[m]>Element (via Flatpak) currently. but being all emacs all the time I should try out one of those <nckx>I tried it presumably before the update to which you refer. I guess I can try it again. <nckx>Oh, and it's in Guix! Thanks <ryanprior[m]>I also use Fractal sometimes, a Matrix client for GNOME. Not in Guix yet but it <nckx>Are there non-emacs/CLI Matrix clients where every single message doesn't take up at least 3 lines like it's an e-mail? <nckx>IRC manages to do this and it bugs me. <nckx>(Looking at Fractal screenshots ☝) <nckx>Element and Nheko have this exact same Author|Message|Blank formatting, I wonder why. <KE0VVT>Thinking about playing with RDE. <nckx>That's new, thanks! Do you have a Guix package? <jgart>nckx, not yet, I've been procrastinating gomuks for a while now <jgart>weechat matrix client is in guix <pinoaffe>oh i gues you wanted non-emacs and non-cli, rather than non-emacs or cli <nckx>Yes, that's what I meant to say. <robin>lispmacs[work], maybe noveau + an nvidia card? (i only have amd gpus so i don't know how usable it is) <robin>if intel dGPUs don't require firmware that might be a solution (apparently they released a card called dg1 already, supposedly higher-performance gpus are coming early next year) <lfam>Thanks robin! I think that's it <lfam>Packaged as perl-test-harness <lfam>Hm, it's a Perl-based test suite in a CMake package that doesn't set up the Perl environment <sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, luis-felipe says: thanks for pushing my patch :) <jpoiret>is today the day I finally tackle writing a proper home configuration, so that I can integrate pipewire/wireplumber into guix? <jpoiret>I think the (less-supported) way will be to make it a system-wide shepherd service, even though ideally we'd run it via a user session shepherd <jpoiret>we still don't have a good replacement for systemd --user <jpoiret>and since it also has udev rules, it's not really feasible to only install it for a user anyway <efraim>camlboot failed after 55 hours on aarch64 on c-u-f :/ <efraim>I don't think I'm going to debug that <jpoiret>eh, actually I can't even imagine running a build for this long <civodul>the GC process from yesterday 4AM is still in the final "rm -rf trash" phase <mothacehe>nah that's the one I started manually on saturday <civodul>so yeah, it's been running for a loong time <civodul>maybe there's a "turbo boost" button on the drive or something? <mothacehe>and since then it's trying to remove 220K directories from /gnu/store/trash <efraim>civodul: camlboot failed after 55 hours on aarch64 on c-u-f, probably not going to investigate, it just said Error 137 <rekado>civodul mothacehe There isn’t anything I can do about this, right? <rekado>sadly there’s no turbo boost button on the enclosure. <efraim>looks like I am trying it again, but with more swap this time <jpoiret>efraim: builds that oom make me wish there was a way to checkpoint builds <civodul>rekado, mothacehe: i guess we should fine better ways to profile things so we can see if it's a software issue <efraim>it rebooted after a power outage, currently at 2gb ram, 2gb swap <mothacehe>rekado: next step could be to run a small hard drive benchmark to understand what's taking so long <efraim>I added the second swap file, I'll try again with 6gb of swap <cehteh>mothacehe / rekardo: i giving the file deletion daemon a try here, testing some things with good results <civodul>efraim: might be worth opening a bug to track the status of this <rekado>cehteh: could you post a link to your code and tests to the bug discussion? <rekado>mothacehe: heh, I was *just* about to run the same :) <cehteh>rekado: reason i am doing that is because i have use of that by myself, but might become useful for guix too <civodul>mothacehe: but hdparm is competing with guix-daemon here, no? <cehteh>it will not be faster than normal deletion but it will free space much faster <rekado>but still: it’s way faster than what we’re observing <cehteh>i just recently subscribed to bug-guix .. i may reply when i get an email related to that bug <rekado>so if it’s not raw disk access it might be something wrong with the file system <civodul>what's the expected performance for raw disk access, roughly? <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>guix does a lot protentially small writes when building things in parallel, which leads to things become more scattered across the disks, which implies huge slowdowns on spinning platters <efraim>I dump my bug-guix emails into my guix-devel folder since there's sometimes overlap <efraim>it might not be fragmented files as much as the contents of the folders which are fragmented <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 <rekado>is it safe to delete /gnu/store/.links? <civodul>mothacehe: i didn't know such a thing existed <civodul>rekado: it's harmless, but it would cause disk space usage to grow <cehteh>rekado: you wont gain much by it, deleting it will take ages as well *rekado fondly remembers spending evenings watching the colorful defragmentation GUI on windows <civodul>these days i look at guix-daemon straces <rekado>I didn’t mean *right now*, but long term. When we no longer have to worry about hardlink counts perhaps future deletions will be faster. <civodul>i don't think so because we're not even at the "deleting unused links" phase <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 <rekado>I read on StackOverflow that it’s possible to unlink asynchronously, but it just leads to spawning lots of deletion requests, which ends up slowing down the deletion… <rekado>mothacehe: only if the fs was dirty <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 <rekado>though it would be split over many separate deletions <cehteh>as i saied first you may fill up trash then mv trash trash.delete; rm -rf trash.delete & in the background <rekado>yes, I do think we should do that now <cehteh>that will works resonably well (prolyl ioniced) the only problem remains is that it wont free much space initially <rekado>stop the daemon, mv trash trash.delete, start the daemon, delete trash.delete slowly <mothaceh`>what's the gain compared to the plain rm -rf /gnu/store/trash that running right now? <rekado>so that the daemon sees the empty trash and happily moves on <rekado>while we’re taking our sweet time to actually delete <cehteh>can you delete trash while the daemon is running? <cehteh>besides mv trash trash.delete wont cost and make things atomic <rekado>and we can stop it as often as we want to compare different deletion strategies <cehteh>hint ionice -c 3 rm -rf trash.delete <rekado>e.g. rsync -r --delete /empty /gnu/store/trash.delete <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 <civodul>rekado: how do we access the zabbix web ui again? <civodul>i tend to set up SSH tunnels for that <civodul>it's more within the real of why i comprehend :-) <rekado>civodul: maybe you can access it via 127.0.0.1:15412 <civodul>i can't really make sense of what i see tho :-) <civodul>how frustrating; we'll have to escalate to support level 2 <civodul>changing topics: is there any blocker left on core-updates-frozen? <rekado>apteryx still had problems with elogind IIRC <PurpleSym>I’m currently checking guix-science for compatibility with c-u-f. <jpoiret>hmmm, there's an oom killer daemon in systemd too? <viivien>core-updates-frozen is the coolest guix branch <jpoiret>rekado: the problem is that it isn't really reproducible for anyone except apteryx, so the debugging process would take a while <cbaines>by the way, I'm starting today to try and get the new setup for shuffling nars around working on bayfront, it'll probably take some trial and error before I get the configuration right *rekado works on making custom channels ready for the c-u-f merge today. <PurpleSym>civodul: Hm, unless we find more packages that are broken because of that I wouldn’t block the merge. It requires a full world rebuild – not sure we wanna do that at this stage. <civodul>cbaines: that's nice, we really need that <PurpleSym>Can we somehow scan all python packages for .pth files? <rekado>PurpleSym: as a change to the python-build-system? <jpoiret>civodul: expanding on your findings about dbus, it's also possible that the new_connection_function has unref'd the connection, thus leading it to being closed as well <rekado>PurpleSym: uhm, no. I didn’t know of that issue. I just meant: do you want to have the python-build-system scan for .pth files, or do you want to do something to installed packages. <PurpleSym>rekado: It would help to assess the impact of that issue by scanning all build outputs on c-u-f for .pth files just once. I could do that, but I’d have to download all substitutes. <jlicht>on a bit of a tangent: {will we,do we,can we} support python packages that need to be built with poetry, after the c-u-f merge? <PurpleSym>jlicht: Not natively, afaik. You’ll still have to replace 'build and 'install. I have a wip branch to switch to PEP 517 locally. But that’s another world rebuild. <civodul>maybe we could have poetry-build-system? <jlicht>exactly; python has standardized for usage, not for implementation ;) <civodul>anyway, i'm all for topical branches for such things, rather than wait for core-updates to be merged <PurpleSym>Yeah, my plan was to propose a wip-python branch once c-u-f is merged. <jpoiret>me as well, having to choose to work on master or c-u-f isn't very practical <rekado>so… will someone merge master into c-u-f today? <cbaines>right... narinfos for bordeaux.guix.gnu.org are now being served differently, it should work exactly the same, but please let me know if anyone notices any problems <cbaines>it should be fine, providing the Guile process doesn't crash... <cbaines>I'm now looking at setting up machines to download that database, and then start downloading all the nars as well <cbaines>then bayfront can switch to forwarding most nar requests to some other machine, and caching the results (so it doesn't have to store all the nars) <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) <mothaceh`>PurpleSym: sure. cbaines could it be related to 604880ae2 ? <AwesomeAdam54321>I'm preparing to use GNU Shepherd on a non-Guix system but I have this error from my config file <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? <cbaines>for some reason, even when looking at progress.scm at commit efd4d36a283acf5441159d4babf25d2054776579, I don't see a call to display-download-progress on line 223 <cbaines>that could just be me not matching the right things up though <PurpleSym>I’m guessing this is code executed by the client, i.e. from c-u-f. <cbaines>I believe it's actually on the daemon side <rekado>tensorflow is broken on c-u-f. Will try to fix it. <vdv>will be c-u-f merged before new year? <rekado>looks like it might happen today <vdv>ah what? :) so many work <jonsger>today would be nice, so I could take care of downstream channels :) <vdv>installation succeed Festerdam? <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). <donofrio>anyone here use nix (cannot find a channel for them here as of yet) when I give it a -verify I get default.nix no such file but I believe it is still working. <rekado>donofrio: this is a channel about Guix, not Nix. *civodul almost done with the merge <jpoiret>does that mean that we're closer than ever to a c-u-f merge? <civodul>i think we just need to agree on what to do with the elogind and the python issues <jpoiret>the elogind issue is an upstream one imho, so i think it'd be fine to merge without a fix for now <Festerdam>But the computer I'm on doesn't seem to allow enabling legacy boot. Not sure though if guix even needs legacy boot. <jpoiret>although from my light investigations this morning, the pid file should be written after the dbus server has registered a new connection function but alas <civodul>mothaceh`, efraim, rekado, apteryx & all: if there are no objections, i'll run "guix style" on the branch today <mothaceh`>civodul: great!! i'm merging master in c-u-f atm <civodul>aoikonomopoulos: yeah, looks like something's wrong *mothaceh` is running "m a" in magit :) <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>but, the EFI firmware needs to know what to boot, so you also need to add a boot option for it inside the EFI variables. <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. <rekado>looks like a proper outage. Can’t even reach mdc-berlin.de <jpoiret>tl;dr Festerdam: do `guix system image gnu/system/install.scm` for a bootable removable image with efi <jpoiret>ah. maybe i shouldn't have gone into the specifics <jpoiret>ouch. the world doesn't want the c-u-f merge to happen <rekado>looks like the MDC network is down <rekado>(that’s where we host guix.gnu.org and all that jazz) <rekado>of course I also can’t receive any email about this because the mail server can’t be reached either. <civodul>the good news is that there'll certainly be people around to help fix it :-) <rekado>yes, I’m sure they’re already inundated with phone calls… <jpoiret>Festerdam: i hope i didn't scare you with all the specifics, but in the end you can just do `guix system image yourconfig.scm` to generate an image <efraim>civodul: I don't think I have any objections <efraim>I'm concerned about breakage compared to not running it, but other than that I don't have objections <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: concerned about breakage "guix style" might introduce? <jpoiret>and I'm not sure how we could manage the system->session handoff properly with non-custom DMs, which wouldn't detect (guix home)-configured sessions <jpoiret>i was thinking about expanding on the greetd service and creating our own DM that could simply load different (guix home) generations <jpoiret>but that would definitely make GDM support way more complicated :( <mothaceh`>jpoiret: right, i need to think more about it but thanks for bringing up that topic! <Festerdam>jpoiret: Can't I just reconfigure grub? It took a few hours to get the system on the USB flash disk, so I really want to avoid repeating that process. <reily>Looks like guix.gnu.org is down? I'm having some issues pulling due to ci.gnu.guix.org being unreachable, and am unable to access this site from multiple networks. <jpoiret>Festerdam: you can try an easier thing though I'm not 100% sure it'll work <jpoiret>just mount the EFI partition, move EFI/Guix/grubx64.efi to EFI/BOOT/bootx64.efi <jpoiret>or, from the installer as a superuser, run `guix shell grub -- grub-install --boot-directory=/mnt/boot --efi-directory=/mnt/boot/efi --removable` (with EFI being mounted on /mnt/boot/efi) <Festerdam>OK, will try that if the first one doesn't work. <efraim>civodul: suprise! now we're refering to a different version of a package <efraim>glib and glib-with-documentation <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 <vdv>just bootstrapping it inside a mini busybox image <jpoiret>well, yeah it takes care of most things, but from most of the scripts i'm seeing there's some shenanigans with needing to run the init manually <efraim>I'll start doing things like pushing the riscv64 patches after the c-u-f merge <jpoiret>and also, all of them replace the bootloader by a dummy bootloader with nothing in it, maybe we could simply add #f as a supported bootloader value <vdv>the bootloader thing is true jpoiret <efraim>oh boo, go-1.14 doesn't recognize ppc <vdv>the gist that i posted (mine) uses an init script that starts the shepard service for system services <vdv>you can just start your shell everytime with this script wsl.exe -d guix /bin/busybox sh -c "/mnt/c/sys/misc/guix-init.sh" <jpoiret>i think most of the difficulties come with wsl vms having an unusual lifecycle <vdv>and multiple shells uses te same daemon <jpoiret>vdv: i'll look up how the "official" wsl2 images install themselves, so that we can have a clean oob experience as well :) <jpoiret>donofrio: one example, i have a great windows tower that i want to offload builds to, but don't really want to install guix on <vdv>sometimes i need to use windows for some adobe software and such, vm is too slow on my laptop <vdv>and having my full guix system on windows is sometime neat :) <vdv>and with the newest wayland implementations its even better :) <vdv>but for 95% of the time i'm on my linux distro ;) <jpoiret>vdv: are you able to run wayland programs properly on wsl2? that'd be really cool <Festerdam>jpoiret: «guix shell» doesn't seem to be a thing. <jpoiret>ah, replace `guix shell grub` with `guix environment --ad-hoc grub` <jpoiret>i'm in the process of compiling an android rom on WSL2 with Debian, would be great if i could also run the whole android studio inside it <vdv>mh it's a few months ago that i used it but no problems so far <jpoiret>Festerdam: oops, also replace `grub` with `grub-efi` <jpoiret>it should still be `grub-install` in the command though <civodul>jpoiret: you're talking about Guix System on WSL? <jpoiret>i'm currently using guix on debian on wsl2, but guix on wsl2 would be better imho <jpoiret>i successfully managed to offload my builds to it, and it started hogging all system resources properly :) <vdv>berlin.guix.gnu.org is back online <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>it's not an option, it tells guix environment to stop processing options and execute the following command <Festerdam>Ah, sorry. I'm on mobile so the I thought the linebreak was just my phone not caring about keeping words together. <Festerdam>Seems like it needs to connect to ci.guix.gnu.org to do this, which is currently down, so I guess I have to wait. <rekado>(I’m trying to figure out what happened, but nobody picks up the phone, and I’m still waiting for a response on the chat.) <raghavgururajan>jpoiret, civodul, apteryx: May we could make seatd-service-type as a replacement for elogind? <jpoiret>no, i think that would break more software <vdv>that'll be cool for sway @ raghav <jpoiret>i agree that it's a good thing to have, but it cannot replace elogind <jpoiret>seatd doesn't implement any logind apis <jpoiret>and i don't think you'll see any big DEs like GNOME depending on libseat rather than logind/elogind <jpoiret>but, maybe for a default minimal configuration with a minimal wayland compositor it could be nicer than pulling all of gnome-shell and friends <jpoiret>(which pulls in gnome-data-server, which pulls in zillions of unrelated things) <AwesomeAdam54321>It's actually possible to use the systemd-logind program without systemd, I tried it <jpoiret>but we should expect dbus to behave badly, among others <jpoiret>yes, but then you're not replacing logind by seatd <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 <AwesomeAdam54321>jpoiret: Me too, it looks so much nicer compared to systemd-logind's API monstrosity <gnoo>it's possible to use guix without elogind right? what about dbus? <jpoiret>well, it's less clear-cut than what the seatd author implies: i don't really think the logind api is that bloated, just that it doesn't support simply seats, but also additional things <Festerdam>jpoiret: The guix environment command seems to download a bunch of stuff, which I don't think makes sense if only gnu grub is needed. <jpoiret>Festerdam: if you rebooted the installer, that's expected <jpoiret>you can ctrl+c and `herd start cow-store /mnt` <jpoiret>maybe that'll suffice for it to use the one on /mnt <AwesomeAdam54321>gnoo: Yeah, you don't need elogind or dbus, but unfortunately the options to choose from are reduced <jpoiret>gnoo: I'd say that's untested territory. dbus is needed for a bunch of things <gnoo>cool, i'm thinking of installing guix on my pc, if i can get rid of dbus, i'd be great :) <gnoo>mostly i hate how dbus starts services by itself <jpoiret>if you want to use desktop apps, you'll run into an issue without dbus sooner or later. <gnoo>and how hard it is to make it not do that <jpoiret>i agree, that's just incredibly annoying <apteryx>civodul: another (perhaps not blocker, but worrying) issue affecting c-u-f is this one bug#52375: webkitgtk page crashes on core-updates-frozen <vdv>i'm using sway without dbus-launch for almost 2 years now without a problem <jpoiret>vdv: i mean, you can. But you won't be able to use things like NetworkManager for example <vdv>but maybe thats just my package and programcocktail <gnoo>is the glib package patched for removing dbus? on my current system, it's linked against dbus <AwesomeAdam54321>The one issue that I've yet to fix when using systemd-logind without systemd is that the polkit-agent doesn't work <vivien>Apteryx, I can browse both the edify and edification pages with epiphany on core-updates-frozen <jpoiret>AwesomeAdam54321: elogind should work properly with polkit <jpoiret>and yes, that's because logind delegates that to systemd, whereas elogind takes care of it itself (and you can configure how to shutdown/reboot) <AwesomeAdam54321>jpoiret: I should really use elogind, I'm pretty sure systemd-logind without systemd is uncharted territory <jpoiret>yes. Well, it's not really uncharted territory: a lot of people do that with a patched systemd-logind which happens to be elogind :) <jpoiret>well, on gentoo and guix it's the default <jpoiret>davidl: have you sent the patch upstream? <chris-l>Is there anyone who has created a recipe to install Guix System on WSLG (Win11 - gasp)? <jpoiret>if only i could run W11 with my 2018 AMD CPU. eh <chris-l>or WSL Win10 also possible without GUI <chris-l>this will lower the threshold for wannabe hackers tremendously <apteryx>has anyone else tried using ungoogled-chromium with jitsi on c-u-f ? <apteryx>It was crashing last time I tried video. <davidl>jpoiret: upstream appear to not be developing the package anymore but this patch makes a big difference for how usable it is so I hope I can get it merged into guix master. <apteryx>vivien: oh! Perhaps it's related to the GPU driver used then? Do you think you could add your GPU driver information/environment (WM/DE) to the bug report as a 2nd data point? <vdv>a lot of wsl'er out there <vivien>apteryx, what relevant information should I gather, and how? <jpoiret>apteryx: about the webkitgtk bug, the backtrace doesn't really help since it just goes to libc while trying to call a gstreamer function. Maybe it couldn't dynamically load the dynlib? <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>by document that it exists, i mean, you could make a blog post about it somewhere, post on the guile mailing lists <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>(the ideal suckless package manager 🤭) <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 <davidl>jpoiret: ok. I will probably go with some cli-option to the install and suggest it to the current issue and close it. <jpoiret>taterbase: you have a config.scm for your guix system installation, right? <jpoiret>there should be one at /etc/config.scm <jpoiret>then, inside it, you can find an operating-system declaration (something that looks like "(operating-system (some ...) (fields ...))" <jpoiret>you'd just need to insert the parenthesized expression i gave you (a s-expression in lisp parlance) inside of the (operating-system ) block, along all the other fields <jpoiret>then, a `guix system reconfigure /etc/config.scm` will reconfigure your system :) (if you're already booted on guix system that is) <taterbase>Ok, so I'll add that s-expr outside of the operation-system scope (not sure if scope is the right word, still learning lisp) and run that reconfigure and try rebooting <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) ...)? <jpoiret>no, it's another field, named "locale" <jpoiret>basically, record declaration look like this "(record-name (field-name1 field-value1) (field-name2 field-value2) ...)" <ns12>Also: what is the difference between (lambda* (#:key outputs #:allow-other-keys) (assoc-ref outputs "out")) and (lambda _ (assoc-ref %outputs "out"))? <jpoiret>ns12: the second version is being phased out for the #:phases declaration <jpoiret>both are supported for now but will not once the c-u-f merge is done iirc. You need to use keyword arguments to be future-proof <old>Anybody has problems with emacs org-babel-tangle of scheme source (geiser) since e0e9aa116e ? <ns12>jpoiret: But how will that work for #:configure-flags, where there is no lambda to provide the "inputs" and "outputs" keyword arguments? *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 :-) <taterbase>guix system: error: symlink: Permission denied: "/var/guix/profiles/system-2-link.new" <taterbase>I didn't run with sudo, I think that might indicate I need to <jlicht>just FYI, I always run `guix system build config.scm' (without sudo) first, so a potentially truly long wait is easily killed as well <jpoiret>sozuba: weird, it just works oob for me. What ISO are you running? <jpoiret>are you running qemu directly, or some wrapper like libvirt <jpoiret>taterbase: it could possibly fail at the very end when installing the bootloader, but as jlicht said most of the errors are detected before downloading anything <taterbase>I see a bunch of shepherd logs about services having been restarted, looks like I can probably reboot? <jlicht>taterbase: see you on the other side ;)! <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 <sozuba>I am running qemu directly, I guess, I haven't used any wrapper manually <jpoiret>hmmm, where did that link come from? <jpoiret>i just don't know if that is a recent version of guix or not <sozuba>may be an older version might work? <sozuba>I'll try an older version just to verify <sozuba>this was the name of the iso once downloaded - lzsv7l04rc3k640av69dg2vj60x54686-image.iso <jpoiret>what exact command line are you using? <sozuba>should i paste it here or, you want me to pastebin it? <jpoiret>if it fits in a single line here, otherwise paste.debian.net <sozuba>qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -nic user,model=virtio-net-pci -boot menu=on,order=d -drive file=guix-system.img -drive media=cdrom,file=guix-system-install-1.3.0.x86_64-linux.iso <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 <sozuba>i tried that and the result is the same, in case i forgot to report the outcome <jpoiret>well, either using -nic user,virtio-net-pci with -enable-kvm, or removing any net configuration <jpoiret>otherwise, you could possibly boot up the VM, get into vt3, and set up the internet connection manually <jpoiret>it should just be a matter of bringing the interface up, and dhcpcd'ing <sozuba>guess that's probably is what i have to do at the end <jpoiret>but i don't recall ever having to set up anything like that manually in qemu <rekado>apteryx: I submitted a bug report about this <sozuba>jpoiret will try again and report back here <f1refly>jgart: I saw that you began packaging crystal-lang for guix. As I write most of my tools in crystal I'd like to know if there's anything I can do to help you? <f1refly>Replicating all steps in the bootstrap package is a lot of work, so maybe you could have some use for one more worker on it <sneek>Welcome back apteryx, you have 1 message! <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/> <lfam>I don't know much about how to make it so that the Perl programs can be found. I did try to set PERL5LIB but I don't know if I did that correctly <apteryx>another thing I've noticed on core-updates-frozen: EMMS (emacs-emms) seems to fail playing .flac music files since I upgraded my profile; I haven't investigated why. <lfam>Maybe we could skip the test suite but at least we can try <lfam>apteryx: Can anything else play FLAC? Such as mpv? <lfam>I just realized that my messages about opustags were mistaken. It's failing in a new way now... I must have fixed the perl-list-moreutils lookup issue <vivien>Regarding 52375, I sent a mail to 52375@debbugs.gnu.org, debbugs recieved it but it does not appear in the issue discussion. <vivien>It was a little over 2 hours ago <civodul>i've ran "guix style", rechecking everything <lfam>That site is where the messages are really kept. <issues.guix.gnu.org> is something like a front-end to that site. So our own tooling may be lagging behind <lfam>Also, I know that the code behind <issues.guix.gnu.org> is being worked on today. So perhaps it's currently being tweaked or something <lfam>I see that the <issues.guix.gnu.org> program ("mumi") is running and that the debbugs issues are currently being synced. So I'm confident your message will appear eventually <vivien>I was afraid I sent it to the wrong address, or that my mail server was not configured properly. <vivien>(to be honest, the latter is probably true anyway ^.^) <lfam>In any case, your message did get delivered to its actual destination :) <lfam>I wonder if there is Guix-y a way to answer "Why did the ffmpeg derivation change since commit XXX?" <lfam>It's just an idle curiosity. No pressing need to answer this question <guixy>I received a USB bluetooth adapter as a gift recently. When I plugged it in the linux-libre kernel log acknowledged its existence and didn't complain about blobby drivers. <apteryx>it's also my emms backend of choice: (setq-default emms-player-list (list emms-player-mpv)) <guixy>What tools does Guix provide to utilize bluetooth? <jgart>f1refly, Hi, yes there is a lot of work to do with crystal. Would you like to meet up at some point and discuss it with Ryan Prior and I? <jgart>In the mean time we should like to package all the depencencies needed to reproduce the bootstrap stages of crystal <lfam>guixy: `guix search bluetooth` has some suggestions, such as blueman, emacs-bluetooth and gnome-bluetooth <jgart>I haven't been able to work on it since we packaged the old ruby version in one of the packaging meetups <f1refly>so there is the old ruby version thats available and that's it currently? <apteryx>lfam: it says emms-player-mpv ipc-error: error running command <f1refly>alright, I'll see what I can do starting with the text file you put on github <lfam>apteryx: Googling "emms ipc-error" does have some promising discussions <lfam>"Does have"??? I mean, "does find" <lfam>apteryx: Maybe some stale configuration or cache? <guixy>I see `guix system search bluetooth` reveals a "bluetooth" service that runs bluetoothd. I suspect that will be necessary. Is that a default service on a desktop configuration? <civodul>rekado: tests/guix-pack-relocatable.sh fails due to numpy 1.20+1.21 <guixy>lfam: I tried grepping the results of shepherd-graph... no results, so I'll assume I need to install the service myself... <lfam>Yeah, that's my guess guixy. Maybe somebody else who has experience using bluetooth can give more specific advice <lfam>I'm curious what model of bluetooth chip you have? If it's not listed in h-node as "working with free software" then it would be great to add it <civodul> 460 files changed, 37699 insertions(+), 49782 deletions(-) <apteryx>civodul has discovered some new compression algorithm <guixy>lfam: Bus 001 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) <guixy>I asked for the one from ThinkPenguin. <apteryx>are we planning to merge the branch today to master? <guixy>lfam: I think it's Penguin USB Bluetooth 4.0 Micro Adapter (TPE-USBBLUV4). FSF certified distros supported include Trisquel, Parabola. <lfam>Gotcha. Glad to hear there's a well-known supported chip <lfam>I don't really like to use bluetooth but it's wildly popular so we need to have options :) <guixy>lfam: Maybe I can prompt them to add Guix to the list :) <sneek>unmatched-paren, you have 1 message! <guixy>unmatched-paren: With guix? Do you need to have the bluetooth service in your config for it to work? <unmatched-paren>although i'm fairly sure that guix isn't listed on the wifi stick either <mbakke>civodul: oh my, that will be an "interesting" merge :-) <lfam>Probably nobody has tried to have Guix added, unmatched-paren <lfam>Guix is kind of obscure and maybe a bit outside of the fold *mbakke has a fix for 'python-distributed', which involved patching 'python-versioneer' <jpoiret>f1refly: to be honest, i only have "(bluetooth-service)" in my services field and i can use everything with bluetoothctl <guixy>`guix system shepherd-graph` might be broken. I pipe it to `xdot -` and see xdot complain about the syntax. I'm pulling now to make sure it isn't an issue addressed in the last week. <jpoiret>although you might want to use blueman or affiliates <guixy>jpoiret: I practically live on a VT unless I'm gaming. I can learn bluetoothctl. <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' <guixy>it's missing for sysctl. Might be useful. <f1refly>jpoiret: it's fine, I wanted to know how to use bluetooth anyways <f1refly>is it normal that my X server is lagging like hell when using picom? It worked just fine on arch without any noticable performance loss whatsoever using the same config <f1refly>Hmm, I'll try playing with the config a bit, maybe theres a single thing that breaks it <nckx>I see exciting times are afoot. <nckx>I was going to push some minor c-u-f fixes of my own today. I guess I'll wait. <mbakke>nckx: I have a couple patches lined up too, is anyone currently merging? <mbakke>I guess we should merge ASAP as the conflict rate will increase by the hour :) <lfam>It's a Git branch where we put high-impact changes to avoid rebuilding every Guix package again for each major change <lfam>Kind of like preparing for big new release of a traditional distro <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 <lfam>AwesomeAdam54321: Right. Grafts are basically a hack to avoid recompilation, because that would take too long <lfam>Security updates and the most critical bug fixes <lfam>The issue with grafts is they can mask problems that would have appeared during compilation <lfam>Like, incompatibilities between a program and its dependencies <florhizome[m]><mbakke> "I guess we should merge ASAP..." <- There are new wayland +wayland-protocols updates not in c-u-f btw, if that's the case it might be worth pushing them now ? <lfam>So we reserve their use for cases where the alternative (not fixing a bug) is too bad <nckx>mbakke: I just skimmed the backlog but that's what it seemed like? <nckx>Also with the upcoming ‘guix style’ flag day, I am not going anywhere near a potential merge conflict today. <lfam>civodul said he would be back later. We should coordinate with him and apteryx <nckx>Ah, civodul isn't around. <lfam>Or rather, those who want to push things should coordinate :) <lfam>I don't have anything pending for core-updates <nckx>My fixes were just leaf-package fixes to stuff I needed to finish my upgrade (i7z, etc., nothing at all urgent). <nckx>python-setuptools-scm-git-archive fails the 'check-sanity phase, that'll be a tough one for me, speaking not Python… <f1refly>florhizome[m]: I installed xf86-video-intel, but it didn't seem to have much effect :/ <jpoiret>f1refly: you don't need to install those drivers, they're used by guix automatically <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 ;) <apteryx>the 'guix style' push makes it more pressing, to avoid endless conflicts <f1refly>jpoiret: where is the best place to view that file? is there an easy way to show it on my installed system? <nckx>mbakke: Thanks! I look forward to learning to do so myself, I just don't even know where to start. <apteryx>I suggest we merge what we have *now*, branch to a release prep branch, and do any world rebuild changes there, if needed <nckx>I think that makes sense. <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>nckx mbakke I can give it a try, unless someone can think of a good reason against it <f1refly>florhizome[m]: I was just told that it's part of the default guix install, so yeah, logically it doesn't change things <nckx>florhizome[m]: It's just an automated semantic style checker & modifier, but here I'm using it as shorthand for ‘running it on the entire tree’. <nckx>guix lint is a different thing entirely. <mbakke>apteryx: sounds good! pro tip: enable git rerere in case you have to re-do the merge for whatever reason :) <florhizome[m]>In what it could be used for. I don't think packages that haven't been built worked *apteryx wonders why git rerere is not turned on by default <florhizome[m]>I wanted to use it Like "elint" in Emacs but that didn't work <podiki[m]>to be concrete, the just pushed guix style related changes made inputs just a simple list rather than the ("package" ,package) we had before <podiki[m]>now it is just (list package ...), so much easier to write (though you have to add some keystrokes to do things like different outputs) <lfam>RIP ("libuiid" ,util-linux) <lfam>We hardly knew which package you were in <podiki[m]>and it shouldn't have caused rebuilds, so subs should all be good still (looks to be the case) <podiki[m]>from my memory the only potential blocker left is maybe that webkit issue? <podiki[m]>(I could be wrong, but hope that is it; I've been good on c-u-f for a while personally at least) <lfam>I guess I should try out epiphany, regarding that webkit bug <rekado>tests/guix-pack-relocatable.sh can be fixed by renaming python-numpy@1.21 to python-numpy-next, or by renaming things in the test <lfam>It's a somewhat common occurence that Guix tests break because package's are named with their version numbers <lfam>It happened with postgresql somewhat recently <lfam>It's like Wine but for MacOS <apteryx>what: make[2]: *** [Makefile:7186: make-core-go] Segmentation fault <unmatche1-paren>lfam: looks interesting, there are a couple of neat-looking cocoa/swift apps out there <f1refly>florhizome[m]: on the upside, guix is the first system on which my browser doesn't lag while scrolling <lfam>You joined with that name at 14:16:34 GMT-5 <lfam>So, about 35 minutes ago <apteryx>because there's an unmatched-parent user already <apteryx>if it's yours and registered, you might have to 'ghost' it; refer to libera.chat docs <vdv>mhh don't know whos now sus ***w1 is now known as xvlc0
***unmatched-paren is now known as Guest7722
***unmatche1-paren is now known as unmatched-paren
<jpoiret>apteryx: about the webkitgtk thing, have you tried with LD_DEBUG=all? *apteryx runs 'make as-derivation' to make sure they ain't breaking 'guix pull' <apteryx>patch not found! cups-CVE-2020-10001.patch <apteryx>guess just needs cleaning up in local.mk <apteryx>hmm, nevermind, `git reset --hard` I needed <vdv>will the merge be done today? <vdv>sorry if the question was asked a trillion times xD <apteryx>brace yourself, core-updates-frozen is coming to a main branch near you *nckx returns fully dinned; just in time for the launch it seems. *nckx dons protective eyewear. <apteryx>'make as-derivation' succeeded... 'git push' incoming... <unmatched-paren>i guess gnome 41 will need to be in core-updates-frozen for another cycle? or is there a reason why it wouldn't be <jpoiret>it should be a simple update comparing to the switch to 4 <apteryx>unmatched-paren:I think the foundation is fresh enough to enable updating the remaining parts alone <jpoiret>it won't be directly pushed to master I think, but a small wip-gnome should suffice <jpoiret>any plans to switch the name of the branch to 'main' by the way? <apteryx>I think civodul had been pondering about it, said it needs some adjustments <vdv>we need a blog post :D *vagrantc would welcome the change from "master" to "main" as well <jpoiret>or maybe to 'the-latest-and-greatest' <drakonis>oh heck, nice, there's a secrets service now <vagrantc>well, that gets tricky with core-updates and company :) <vdv>maybe just main.. :D <jpoiret>vagrantc: you mean the 'danger' branch? <podiki[m]>(insert jurassic park hold on to your butts gif?) <apteryx>"[ 22%] LOAD gnu/packages/abiword.scm" is taking unusually long (there were 2 new commits to rebase on) <nckx>‘Be sure to run ‘guix refresh -l’ to find out which branch is right for you: “zzz”, “uhoh”, or “danger”.’ <podiki[m]>"i-like-things-breaking" or "it-is-winter-compile-more-please" :) *apteryx will need 15 more minutes to build repo on slow but main machine before they can push <podiki[m]>c-u-f users can just switch back to main, or is there any other steps involved? <vdv>the hype of breaking new things *unmatched-paren prepares for system breakage and a lot of rollback-option selecting *unmatched-paren wonders whether he is being too paranoid <nckx>These goggles better do something. *nckx is already on c-u-f but it's fun to hype along. <podiki[m]>same; excited to hopefully see no difference 🤞 <vdv>c-u-f with substitutes :) <podiki[m]>subs have been good on x86-64 for a while; other archs less so <nckx>Well, a lot of ‘minor’ updates are on master, so there's plenty of opportunity for unforseen incompatibilities. <podiki[m]>oh actually I see master was merged to c-u-f a mere 9 hours ago (I haven't guix pull-ed in a few days though) <vdv>i'm just hyped because of sway and the wayland merge :) <vagrantc>bordeaux ran out of disk space and has essentially stopped building? that seemed to be the only place to get reliable aarch64 substitutes <lilyp>real pros use neither as-is, but git rebase one on the other hourly :) <vdv>wayland version bump <podiki[m]>I'll have to stop procrastinating on submitting a bunch of new packages I've been holding off on <nckx>lilyp: You're saying you did all the work already but didn't share it with the class? <podiki[m]>i have....openrgb (but needs debundling I think), rofi-calc, autotype, some other sys monitors <nckx>podiki[m]: <haven't pulled> Oh, same. <unmatched-paren>i'm planning to do newsflash-gtk in the same patch once i overcome the lazy <nckx>I'm still on the ‘CVEs, probably’ version of c-u-f. <lilyp>unmatched-paren: thematic series separated into one patch per mail please <unmatched-paren>luckily someone appears to have done libnewsflash already, not sure what it's used for at present tho <lilyp>nckx: I did not say that any of those hourly rebases would build :P <nckx>‘Continuous integration doesn't mean successful integration. Just tick the box.’ <jpoiret>pipewire, wireplumber, xdg-desktop-portal{-friends} here :) <lilyp>We've had enough of continuous integration. <jpoiret>i was waiting for the c-u-f merge of the pipewire bump to have it build properly <lilyp>It's a new decade, let's start continuous disintegration 😎 <podiki[m]>after the big merge will be time for getting 1.4.0 ready? <vdv>the hype sounds like 1.4.0 :) <apteryx>podiki[m]: I'll branch to version-1.4.0 just after merge <podiki[m]>apteryx: and that branch will be for making sure installer is good, that sort of thing before a release? (my first new release since I went guix) <apteryx>podiki[m]: issuing RCs and fixing anything that needs fixing <podiki[m]>(took me a while to understand the rolling but releases structure) <civodul>oh, looks like the big commit triggered a little bit more than zero rebuilds <apteryx>civodul: what was the coverage before? it's at 53% now <civodul>i'm just surprised that "guix style" led to rebuilds <nckx>A significant number of failures, too, although they could be new old failures. <unmatched-paren>i don't see any changes on savannah; does it take a moment to update? <vagrantc>i686 hasn't been doing so well on Debian's guix package ... currently not available in debian's testing suite because of it :/ <civodul>nckx: i don't think they're new failures <civodul>we miss a "compare evaluations" feature <nckx>Oh: (list glib mit-krb5 openldap polkit) <nckx>civodul: We really do, but I'm not complaining. <civodul>it's prolly just that the previous failure was transient <podiki[m]>maybe some just needed a restart/rebuild from previous failures, since we've seen that plenty <civodul>but yeah, eval 54201 already has more successes than 54117 <civodul>i'm going to try "guix style --input-simplification=safe", which will trigger rebuilds, but only "safe" rebuilds (different derivation but result is known good) <apteryx>civodul: the rebuild doesn't seem too bad? Only 2.7 k remaining to build. Maybe you don't need to worry too much about it. <GNUHacker>wich use-modules I need to mumble/murmur server? (gnu services voip) ? maybe (gnu services voice) ? <sneek>Welcome back GNUHacker, you have 1 message! <sneek>GNUHacker, apteryx says: -X should be fixed on the core-updates-frozen branch <unmatched-paren>what we need is a virtual universe that simulates the exact air pressure, ocean currents and solar flares as the universe at the time of creation <lilyp>Ahh, but does your simulation have Facebook in it? <florhizome[m]><GNUHacker> "wich use-modules I need to..." <- for the system config? The one that it’s in usually. you can use guix system search or guix-services-by-name in emacs <unmatched-paren>omitting them would break reproduciblity with the real world, so yes *apteryx finally finished building Guix on their main machine. <mbakke>civodul: most rebuilds come from ("python2-foo" ,python2-foo) -> (list python2-foo) transformation <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 :-) <civodul>no, i'm running "guix style --input-simplification=safe", which simplifies more packages <civodul>but i'm filtering out any changes that would trigger rebuilds below gtk+ <apteryx>OK. I'll wait a bit then! Please ping when you're done. <apteryx>or feel free to do the merge when you're done, there's no conflict ATM so it should be trivial <florhizome[m]>arbitrary question: is wayland still propagated input in c-u-f? <unmatched-paren>is guix style a formatter? a formatter sounds good to me because i do not use the electronic macintosh editor <vdv>linter + formatter @unmatched-paren <nckx>We already have indent-code.el, which uses emacs even if you don't. <jonsger>will we get a core-updates-frozen merge today? <vdv>maybe in a few minutes/hours @jonsger :) <mbakke>civodul: oh, it's the other way around: some (early) python 2 packages had labels changed "python-foo" -> "python2-foo" <civodul>packages created by package-with-python2 maybe? <drakonis>gonna set up guix again after 1.4.0 lands <civodul>there's going to be a number of rebuilds, but presumably mostly leaf packages <civodul>there's ~3K packages still using the "old style" <civodul>per: grep '`(("' gnu/packages/*.scm | wc -l <podiki[m]>great! (so happy to have the new style inputs) <jonsger>I'm not sure if I like more then one input per line... <nckx>M-hm. It's rather arbitrary. <jonsger>yeah, but I'm a traditionalist and I got used to it <nckx>jonsger: I mean the new style. *apteryx reattempts merge with master <jonsger>ah, yeah especially when to do a line break <luis-felipe>nckx: Hey, thanks for taking the time to push my patch :) <civodul>jonsger: "guix style" puts everything on one line when there are 5 or fewer inputs <civodul>i find it makes diffs easier to read that way <civodul>and still achieves a good compression ratio :-) <jonsger>ah, I was a bit away from core-updates the last weeks :) <mbakke>civodul: python2-importlib-resources have different input labels after the big style change <jonsger>but I guessed that you don't do a -50048/+37965 diff manually :P <apteryx>jgart: you were asking what benefits a monorepo had ^^ <mbakke>I don't get why though, the inputs themselves did not change <civodul>mbakke: so that triggers rebuilds but it doesn't break anything, does it? <mbakke>civodul: I doubt anything uses those labels <civodul>it has (list python-setuptools-scm python-toml) <mbakke>civodul: you're looking at the python3 variant <nckx>I find diffs harder to read when multiple inputs change on a single line, but that's what (accurate) change logs are for, after all. <rekado>oh, etc/committer.scm probably needs to be changed now <civodul>mbakke: no i think i'm looking at python2-importlib-resources :-) <mbakke>civodul: "my" python2-importlib-resources has "(list python2-pathlib2 python2-typing)" <civodul>mbakke: ah true! so i was looking at the right package, but at the wrong hunk <civodul>the labels were wrong, yet things were changed <rekado>yes, I think in change-commit-message the get-values procedure needs to be adjusted. Nothing too serious.. <apteryx>did someone fix 'make check -jN' ? Because it's the first time it has worked (minus that known-to-fail tests/guix-pack-relocatable.sh test) <rekado>about that test: should we rename python-numpy@1.21 to python-numpy-next? Or should we change the test? <apteryx>parallel tests needed to be turned off for a few tests <civodul>mbakke: oh i see, that's because of the special case in 'label-matches?' in (guix scripts style) <civodul>rekado: i'm fine either way, but it may be hard to find another pair of packages that exercise what the test is looking at <apteryx>they should have lots on their plates <civodul>that also depends on the shape of the DAG <civodul>i find it hard to tell for sure that they're lazy *apteryx has 20% more GUILEC'ing to go before they ca push <apteryx>'make check' tested fine on another machine, so did 'make check-system TESTS=basic' and 'make as-derivation' <jgart>apteryx, thnx for pointing that out <nckx>sneek: later tell luis-felipe: Thank you for making it. *unmatched-paren is somewhat surprised <apteryx>core-updates-frozen is officially merged! <lfam>Big thanks to you apteryx for driving it home <lfam>I saw you doing a lot of management in recent weeks! It's real work <jpoiret>but the button is labeled: "Danger, please know what you are doing" <podiki[m]>and to all of you that dealt with the pain that is rust pacaging <lfam>A lot of other people put a lot of work into it as well <drakonis>well, never had a pull fill in my terminal buffer <apteryx>let's not steal the 1.4.0 release's thunder ;-) <apteryx>that's just master getting updated :-) we still need to go the 'make dist' dance, write a blog post, write NEWS, all that <civodul>i'm halfway through a blog post on simplified inputs *apteryx now branches off to version-1.4.0 <podiki[m]>do we get fancy artwork? loved the 1.3.0 one (very moebius/incal) <mbakke>apteryx: maybe let the dust settle a bit first? I still have some fixes for broken packages <civodul>yes, we could wait a few days before branching maybe? <jpoiret>so is it business as usual on master for now? <apteryx>OK! I was planning to use that branch as a place to have heavy/lengthy rebuilds happen (such as will cause the sitecustomize.py fix) <civodul>also, what color for the shed? "1.4.0", or "2.0.0", or...? <lfam>Let it depend on how much testing the installer receives ;) <apteryx>haha, I'd say... 1.4.0. We didn't break that much APIs, did we? <lfam>2.0.0 will attract even more newcomers than 1.4.0, and we usually find some bugs in the installer... after release <jpoiret>change the version scheme entirely. Guix release codename "Apteryx" <apteryx>I'm not much of a 'release 93' "just because" type of person. <jpoiret>(i'm sorry all other a.* users in the chat, this was the first that came to mind. no offence) <rekado>something worth checking: packages that unpack patched native-inputs in a build phase <lfam>rekado: Like git-manpages? <rekado>these inputs used to be tarballs, now they might be directories <lfam>Oh, maybe we don't patch git-manpages <apteryx>so there's this 'version-1.4.0' branch that I pushed, but we can recreate it from master if too much fixing happens there, or if there's consensus for another version number ;-) *unmatched-paren holds their breath as they guix pull <civodul>the_tubular: publishing six month worth of work :-) <the_tubular>Authenticating channel 'guix', commits 9edb3f6 to 6dffced (2,833 new commits) <lfam>Maybe if you had already pulled core-updates, then some subset was already authenticated <lfam>Just a guess, not sure of how it all works exactly <podiki[m]>also going to switch back to the main branch <rekado>another thing to clean up: wherever we have a phase that just runs make-file-writable, it could probably be removed now. <podiki[m]>but ought to finish a little work before playing <ss2>uhh, feeling lucky. Just decided early on to install a machine a fresh Guix. Gonna see how this goes. :) <jpoiret>let me check if that actually happens <jpoiret>i've got some python2 packages rebuilding <jgart>include the vis-lspc source as an input and copy it all in? <jgart>I'd like to do this without maintaining my own source tree with the plugin included <ss2>podiki[m]: I actually hoped that I'd get it done before the merger. <jpoiret>jgart: yes, seems like the cleaner solution <podiki[m]>ss2: great timing :P you murphy lawed us into the big merge finallyhappening <jgart>so, I'd include vis-lspc as input in the vis package and then I'd need to copy the sources to vis/lua/plugins within the guix package definition <apteryx>jpoiret: yeah, coverage is down to 47% about with the latest style bits. probably going to take a couple hours to go back to the level it was, unless the GC invites itself to the party. <jgart>essentially, I'm trying to create a fork of vis that supports lsp out of the box while retaining the vis-lspc plugin in upstream's repo and just pulling it in <civodul>jackhill: it means that the route or address already exists <civodul>"17" is the magic number for that (EEXIST) <jpoiret>actually, why am i rebuild gtk and mutter, CI didn't pick up those new changes with the latest evaluation? <mbakke>apteryx: I suppose the branch will merge master occasionally until it "freezes" (if that word still has meaning) <jpoiret>civodul: /gnu/store/ypvpdfp7j6igxj5k6r7n74sgc5lm7ivv-gtk-4.2.1.drv <civodul>ci.guix is still building things due to e3196755e60ba7f1ed9d432e73f26a85e0c8893c <jpoiret>oh okay! it wasn't showing up in the the last master evaluation <apteryx>mbakke: yes, that's how it went last time with 1.3.0 <jackhill>civodul: ah, I beleive I saw that even while rebooting, but I'll try some more :) <civodul>jackhill: then of course, it could be that you found a bug <jpoiret>well then, i'll delay reconfiguring until tomorrow morning then. I'm not one to stare at gtk building until I fall asleep <jackhill>civodul: ok. I think dinner is ready here, but I'll keep poking at it, and try different hosts and report back/file a ticket if it persists <jackhill>civodul: where did you look up the errors? I assume that's coming from Linux? <guixy>`gcc` in my home isn't working properly. When I try compiling code, it says I'm missing stddef.h <civodul>jackhill: i did (strerror 17) at the REPL :-) <guixy>Even when the first line is #include <stddef.h> <vdv>is it possible to use cuirass on a foreign distro? <jackhill>civodul: cool, I was hoping for a protip like that <guixy>jpoiret: It is gcc-toolchain. <guixy>jpoiret: readlink $(which gcc) <guixy>/gnu/store/h1l6c5rvz1831ggrj6a1gz4h172kq0y7-gcc-toolchain-11.2.0/bin/gcc <guixy>It doesn't complain in a container. <jpoiret>what's the exact error guixy ? are you using guix shell, or is it installed? <vdv>19,451 packages woop woop <guixy>Following directions in old book I purchased recently. `Beginning Linux Programming, 4th edition`. Has very little to do with the kernel so far... <lfam>I think that we removed quite a lot of it, but we didn't remove everything <lfam>Like, I think we can feel free to remove "leaf packages" for which the Python 3 variant is used, but the Python 2 variant is not <lfam>It used to be a matter of policy to create both, but not anymore <nckx>guixy: linux-libre-headers? <nckx>Otherwise, I have no idea who provides a stddef.h. Maybe a built-in thing. <guixy>nckx: I thought it was glibc. The samples don't say stddef.h. Rather they say stdio.h <nckx>Gotcha. (Nope, not glibc.) <nckx>So glibc provides a stdio.h that implicitly refers to a stddef.h that is then not found? <guixy>Sounds like it. I think I have some ideas of how to fix it, but it requires reconfiguring my home. <lfam>So, how do we feel about a golang-updates branch? There's about 382 packages using go-build-system, and most of them are very cheap to build. I'd like to update the default Go compiler soon. <nckx>Meaning ‘guix home’, guixy? <lfam>Or could this work be done on master? <nckx>I still need to try that out. <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 <nisha>Any ideas on how to fix this? <guixy>nisha: Welcome. New to gnu/linux/etc or new to guix? <lfam>To summarize, when you try to install a Guix package, you are logged out of your SSH session? <nisha>lfam it appears to be the case <lfam>Does anyone have any ideas? <nisha>I've tried killing the guix-daemon and trying again but I get the same issue <guixy>Did you install guix with install script? <lfam>And if that doesn't work, then also try `guix --version` <lfam>Yes, another important question <drakonis>civodul: is it time to establish a policy for major version bumps?