<pkill9>how do i convert a list into a single string in guile? i.e. pass a list to string-append and have the contents of the list be the arguments <pkill9>specifically, it's the output of 'map' <pkill9>i'm putting a "\n" on the end of each list item (which are all strings) and i want to combine them all into a string <pkill9>I found out the solution: I needed to set the keyword "#:stat" to "stat", as by default it is set to "lstat" which doesn't follow symlinks ***jonsger1 is now known as jonsger
<apteryx>dongcarl: (without any research) maybe by defining your custom gcc package for that container, taking out what is specific to Guix doings with rpaths? ***jonsger1 is now known as jonsger
***Piece_Maker is now known as Acou_Bass
***buffet_ is now known as buffet
<civodul>roptat: i noticed a translation typo: "105 nouveau paquets" (missing 'x') <roptat>are you going to send the new translations to the TP soon? or should I do it? <roptat>I just didn't understand you wanted me to do it ^^' <civodul>roptat: np, and sorry for the confusion! <civodul>i guess if we submit it today and aim to release end of April, that leaves a reasonable amount of time to translate the important bits (the installer in particular) <efraim>I tried to package poedit but it looks like our boost package is missing something <linarcx>Hi guys. I install guixsd on my machine. After installation completed, I only see guixsd in grub. I have arch, windows, Debian, nixos. And none of them not detected with guixsd. Why? <wednesday>You might have to add menu entries for them, but other people may know for sure <nckx>linarcx: Because Guix doesn't do any detection, period. While os-prober is packaged, there's no code to use any of it. <linarcx>At the end of this page they said that wee should add them via:`menu-entries`: <nckx>You'll have to manually add menu entries to chainload Windows and ‘configfile’ the other grub.cfgs. <nckx>Nor do I off the top of my head, but I assume it's documented. <roptat>nckx, can we use chainload in a grub entry now? <nckx>roptat: Hm? Why not? (Not sure if UEFI still supports it but GRUB itself still has it.) <linarcx>For example : what is this: `(linux "/boot/old/vmlinux-2.6.32` <nckx>If you're talking about the Schemey menu-entry wrappers, no idea, I avoid all that stuff. <linarcx>How to find corresponding values for different distros? <wednesday>thats where the kernel is, its usually somewhere in /boot with named vmlinux or vmlinuz or similar <nckx>linarcx: For other Linux distros you're much better off using ‘configfile /foo/bar/arch/linux/grub.cfg’. Then Arch will take care of updating kernel versions etc. <nckx>roptat: The command is literally called ‘chainloader’ so I think I'm misunderstanding your question. <nckx>Otherwise, see 5.1.2 in the GRUB manual. <linarcx>nckx: any example? I don't have any idea how do that. :( <nckx>linarcx: Not really, I've never used Guix to boot anything but Guix, I'm afraid. *lfam wishes for a wireguard server service <roptat>nckx, how do you not use the schemey wrappers? <nckx>Oh, MENU-ENTRY doesn't even support anything besides basic LINUX and INITRD booting. <nckx>roptat: I write my grub.cfg by hand and flash it to my BIOS chip. I don't think Guix supports that :p <nckx>In general, I use native configuration file syntax for everything, much less lossy. Tried to configure dovecot with the wrappy interface once and was unconvinced. <nckx>None of this is helping linarcx :-( Surely there must be a way to do this. Surely nobody is booting their other distributions using linux+initrd. <nckx>Hm. Wow. I didn't know Guix grub.cfg generation was so spartan. Sorry for bringing up solutions that it doesn't support. <roptat>I don't have other distros beside guix :p <roptat>but I guess you can pass --no-bootloader at init/reconfigure time and use the grub from another of your distros <nckx>roptat: Neither do I, but I keep several rescue ISOs ready to loopboot and am *very* familiar with GRUB for irrelevant reasons. <nckx>(What else to do with such a waste of space as an EFI partition?) <nckx>Erm. On my new X230, Guix's X maps backspace to *checks notes* ‘XF86ScreenSaver’. <brendyyn>Cant grub automatically find these other systems? <nckx>Pipe/backstroke under it is ‘XF86MenuKB’. This is a (my first) pc104 US keyboard coming from a pc105-key one, but this looks... drastic. <wednesday>I saw yesterday someone else had the issue of sddm starting without an x config, still need to get around to making that bug report heh <nckx>You can use os-prober to poke around your partitions for OSes and generate some menu entries for grub.cfg, but GRUB itself (IMO rightly) does not do this itself. <nckx>I wrote a grub.cfg once that basically did this kind of full scan (for OSes, ISOs, ...) at boot time and dynamically created all menus, but doing so from GRUB itself is sloooow. Cool, but slow. <vixus>would it be possible to `guix system reconfigure` into GuixSD from another distro without replacing the kernel? <nckx>vixus: It is certainly possible if the kernel provides all the features Guix System expects. *nckx sed -i 's/GuixSD/Guix System/g' /dev/scrollback *jonsger is not really happy about Guix System... <vixus>but will `system reconfigure` try and replace the kernel by default (presumably via the bootloader)? *nckx is. Diff'rent strokes, I guess. <nckx>vixus: It won't replace any files on disc, but yeh, by default it will install a bootloader which will boot the Guix kernel which is probably what you meant. <nckx>Luckily for you there is something like --no-bootloader that will skip that. You'll have to manually pass the Guix System initrd to your custom kernel though. <nckx>I presume that something like (untested) (bootloader #f) in your system configuration will work too. <vixus>my main issue with Guix System is, stereotypically, lack of hardware support and custom kernel builds taking ages <vixus>otherwise I really enjoy the declarative system config <nckx>vixus: Yeh, I throw away Guix's .config (which is just ‘make defconfig’ + *very* few tweaks) entirely and use my own. <vixus>how long does a build take for you? <nckx>vixus: So you're using another distributions binary kernel to skip the build time? <nckx>vixus: I never pay attention but it can't be more than half an hour. <nckx>My CPU's busy or I'd test it now. <vixus>Maybe I'll give it another shot <vixus>do you have a link to your custom kernel package, out of interest? I've hacked one together which seems to work but it's not using a custom config. *nckx made sure to get an i7 in their new laptop because Guix. <nckx>vixus: No, it's not on-line and I can't get to it at the moment. <nckx>It's also not linux-libre. <nckx>I guess I'm just patient ;-) <vixus>hmm, I swear it was still going well over half an hour <lfam>The kernel build time will also depend on the speed of your storage and RAM interfaces <nckx>And make sure that Guix is actually using all your cores; I don't know whether it does by default. *nckx should set up ‘stock Guix’ on a system so they can give good advice in this channel again, not that heavily-customised crap... <vixus>yeah not using all my cores is what I suspected to be the problem <vixus>but I'm not sure where to configure that <nckx>vixus: I use the EXTRA-OPTIONS field of the GUIX-SERVICE-TYPE to set --cores and --max-jobs. Again, there might be native fields for that nowadays. What it really should do is default to `nproc` in the daemon itself. *nckx can't wait to be ambulant so they can sit back down and hack on Guix. <vixus>nckx: do you build your kernel config into the package definition or keep it as an external file? <dongcarl>apteryx: I think that might be what's actually needed. <nckx>vixus: The latter. It's a stand-alone .config that I make-xconfigged a decade ago and keep up to date, not defconfig + some changes. <nckx>Then I use (native-inputs `(("kconfig" ,(local-file ...)))) to point to it. <nckx>aarch64 kernel build says no: “error: conflicting types for 'int64_t' ” <vixus>I think I asked this yesterday but what is the conceptual difference between ~/.guix-profile and ~/.config/guix/current? <nckx>vixus: .guix-profile (the default value for $GUIX_PROFILE, can be changed) contains your user-installed packages, .config/guix/current contains (only) the latest guix built by ‘guix pull’. <vixus>nckx: ok that makes sense, thanks <civodul>the 'staging' branch is at 62% of substitutes for x86_64 <civodul>there's no serious build failure left ***rekado_ is now known as rekado
<rekado>do you suggest we merge? I’d like to encourage people to test the newer GNOME. <civodul>yeah it would be good to test first :-) <rekado>I’ll reconfigure one of my machines later tonight. <civodul>i did "guix pull -p test-staging --branch=staging" and then "./test-staging/bin/guix weather -c10" *rekado is debugging an OpenMPI problem <civodul>rekado: do take advantage of bavier's expertise! :-) <rekado>bavier: ORTE does not seem to work. <rekado>we have a very simple test and ORTE fails to start daemons. <rekado>I’m building openmpi with --enable-orterun-prefix-by-default now, and I also use hwloc2 <rekado>I hope that will make a differenc. <vixus>nckx: huh, you were right, the build took like 10 minutes (not using the guix kernel config :p) <rekado>bavier: do you think it would be safe to build openmpi with hwloc2 instead of 1? *kmicu LOL at ‘newer GNOME’ cuz that sounds like ‘bigger Luke’. <rekado>unfortunately, with --enable-orterun-prefix-by-default ORTE still fails. <jonsger>rekado: I triggered a guix system vm desktop.tmpl on staging. Tomorrow I can do some quick check :) *nckx looks up ‘bigger Lu--what the hell. <rekado>no wonder ORTE can’t reliably start daemons. But why does it segfault at all…? <sunmaster>Was there ever a discussion about using the package name as a folder with the version as a subfolder then with (configure or build) option as sub-subfolder instead of the SHA checksum? <nckx>sunmaster: Very likely. What do you mean by ‘configure or build option’? <nckx>(‘Very likely’ since just about anything has been proposed at this point ☺ <nckx>) damn smileys eating my brackets. <g_bor>and something seems to be out of sync. <nckx>sunmaster: Remember that your model would have to accomodate not just *all* relevant attributes of the packages, but *all* attributes of *all*its dependencies. <sunmaster>nckx: I mean that I read that into the checksum name the options to build are also calculated <g_bor>this is referenced at the manual, but there is no such file at that location <nckx> /gnu/store/grep/--with-bitcoin won't cut it. You'll have to put the options to glibc in there somewhere. And the hash of GCC's source. And the patches applied to ld. <rekado>the URL is wrong because it’s derived from the commit of whatever Guix version is used to build the website. <rekado>for the gnu.org website it’s always going to be a proper release <nckx>sunmaster: Well, yes, as a side-effect of throwing just about everything relevant (=besides metadata like the description) into the hash-blender. So much more goes in than just a few configure options. <nckx>Every single bit (literally) of information about the package and all its dependencies. <sunmaster>nckx: Okay, you gave me an idea there, how to accomplish my thoughts about "clear name" package database <nckx>I think the current scheme is close to (if not) ideal. It minimises collisions without being ridiculously wasteful. The only possible optimisation that might make sense is /gnu/store/h/a/sh-foo/, but that's already file system-specific and probably not worth it. <nckx>If your goal is attaching human-meaningful metadata to store items, the store path is probably the worst place to put it. *nckx meant ‘if not’ above as ‘and probably’. <vixus>hmm, would it be possible to "preload" a Guix System install USB with some packages? <vixus>I've been trying to put together a disk-image from a gnu/system/install.scm that runs my custom kernel but that's bringing about a whole host of issues with modules and such <nckx>vixus: Yas. Trivially. Problem is the non-trivial size of the non-preloaded one; it's already over a GB. And that's for something that 99% of users will have to use as a netinstaller. <vixus>that's ok, I've got a large USB stick <nckx>...unless you mean that as a means to solve your module problem because then I'm not following. *nckx thought you meant ‘preload’ as in ‘include icecat on the installer DVD for off-line installation even though nobody will run it there’. <vixus>so the issue is the custom kernel I've built is using the Ubuntu kernel config which seems to not include things like ahci and usb-storage (the latter gets dynamically loaded, I guess) <vixus>but the %base-initrd-modules expects those to be there <vagrantc>i think the disk failure on the hydra build farm some months ago and the absurdly long and ram-consuming fsck times would be mitigated somewhat by using /gnu/store/h/a/sh-foo/ <vagrantc>granted, that's an extreme case ... but also an important one <nckx>vixus: You're certainly taking the long road to hard towne with your approach. Not that I have a drop-in alternative. <vixus>(apart from buying different hardware) <vagrantc>putting every single build into a single directory ... has it's cost ... and while ext4 can technically handle billions (trillions?) of files in a single directory ... in practice there are other considerations <nckx>vagrantc: Maybe. Rather hard to benchmark that 😛 <nckx>I've never seen any of those symptoms and have had more than my share of graceless shutdowns. <vagrantc>could also create a symlink tree alongside it, at the cost of an additional inode per item ... e.g. /gnu/human-store/package/version/hash or something <vagrantc>nckx: yes, but how many terrabytes is your store? <nckx>vagrantc: Heh. /gnu/bikeshed/package/version/hash is my favourite too. <nckx>vagrantc: Just 1 on average. <nckx>It went up to ~2 once when I wasn't looking. <vagrantc>i remember talking to ... ruben from fsf about the hydra failure, and fsck was the bulk of why it was down for so long <nckx>Performance is fine (ext4 hashes directories, or does here) but there's no chance that an ls will return. Ever. <vagrantc>eventually this will become a problem if someone wants to maintain a historical archive of all the store items (or even just "released" versions) <nckx>I spend a *lot* of time waiting for grafts so I'm very sensitive to the ‘scheme x would slow down grafting’ argument too. But I don't know how CPU bound it is now. <nckx>Hash collision might come into play at that extreme. <nckx>Just to be clear: 🤷. I don't have romantic feelings towards any scheme but haven't met one that seemed worth the switch. <nckx>I prefer the current one for tab-completion but others argue oppositely. <nckx>vagrantc: Any idea how big Hydra's store was? <nckx>vagrantc: The problem I have with the symlink tree idea is a) people/build scripts will use both paths, so both effectively become API b) it's just a parallel shove-stuff-into-paths scheme with its own trade-offs where c) a separate database is what is probably desired. <nckx>vagrantc: Whoops. Missed that line. <nckx>vagrantc: Yah. Apparently this makes me ‘weird’ and ‘weird’ and ‘unfit to babysit children’. <vagrantc>yeah, i can see the parallel symlink tree having some weird user-presenting issues <vagrantc>e.g. accessing paths by multiple locations ... <vagrantc>but isn't that already the case with the profiles being a huge pile of symlinks? *vagrantc never knew tab-completion came up in babysitting! <nckx>vagrantc: But those address store items at a different, er, ‘level’? /home/nckx/.guix-profile/bin/ls means give me the ls that nckx installed into their default profile. It's not a reference to a single build in time. Does that make sense? *nckx once got kicked out of a Chuck-E-Cheese's for preferring emacs over vi. *nckx isn't really up to discussing the hardest problem in computer science today. Too fuzzy. <nckx>I mean I'm up for it, just not very clear in my thinking. <ison111>Using GuixSD, is it normal on startup to see timeout errors coming from dbus-daemon, saying that it fails to start services like org.freedesktop.Accounts? I also see a red CRITICAL error that accounts-daemon fails to start because a timeout was reached trying to start org.freedesktop.PolicyKit1 <vagrantc>nckx: sure, the difference between profiles and the store are meaningful ... but it doesn't seem implausible to have another view of the same filesystem <vagrantc>heh. could implement it as a fuse backend :) <nckx>vagrantc: I'd personally prefer something like that that doesn't even touch Guix itself. Then everyone can make their own! 😛 <vagrantc>though i still think partitioning off into more subdirs somehow will eventually be necessary *nckx wonders if btrfsck could even *handle* the store. <nckx>No next-gen file system of the future for us. <kmicu>ison111: yep, quite normal on any distro. GNOME likes leaking. *kmicu uses Vi inside Emacs to bring tribes together. <nckx><kmicu> yep, quite normal on any distro. <nckx>...seriously? That's not fixed? ‘Cool.’ <kmicu>vagrantc: no issues in Nix land. They have much bigger farms and some of them are on btrfs. I suspect FSF has issues mainly cuz they use old (but respecting freedom) hardware. *nckx wants to kick someone every time they hear ‘storage/RAM/... is cheap’. <nckx>Like, no, in any possible dimension, it is not. *kmicu assumed FSF’s farm was on a plain old ext4 not a fancy CephFS and that’s why they had issues with a store that’s smaller than some users have next to their laptops 🤭 <nckx>Is CephFS actually that performant? 😛 <kmicu>Folks in HPC field use CephFS or CernVM-FS so I guess the answer is yes when we have petabytes of data. #notmylevel (10TB is my limit). <civodul>kmicu: hydra.gnu.org is a VM that used to have a terrrrible i/o setup (it's still not good but improved at some point) <vagrantc>i guess this is the sort of thing one could "do science to it" to figure out the practical limitations of sticking all the store items in a single directory with various storage options <nckx>We already know that performance on NFS sucks, but then we already know performance on NFS sucks. *kmicu wanted to point out that Nix has order of magnitude bigger farms than Guix; current store format still works there so it’s too soon to optimize it. hydra.gnu.org kerfuffle was more about terrible IO setup as pointed by Ludo. <vagrantc>terrible i/o involving lack of lots of ram <kmicu>Nix farms don’t have lots of RAM though. (Where lots of RAM ≈ 32GB) <lfam>It wasn't just a lack of RAM. The storage array that used to host <hydra.gnu.org> was a VM with virtualized software RAID on spinning disks. When shared with other VMs, it was extraordinarily slow <lfam>Or rather, on one spinning disk <lfam>So, multiple VMs were sharing a disk, and the disk itself had been split with soft RAID <kmicu>RAID on a one spinning disk‽ <lfam>That was my understanding at the time <kmicu>No wonder I see so many updates on fsf.status mastodon account 😺 <lfam>It's been a couple years since <hydra.gnu.org> was running on that setup, however <lfam>I missed the earlier part of this conversation. No opinion on the store layout :) <kmicu>I’m so gratful our top heads recognized the issue and created more local build farm. ʕノ•ᴥ•ʔノ ︵ λ𝛌𝚲𝝀 <lfam>Anyways, the slowness of that system is what motivated the creation of <mirror.hydra.gnu.org> <civodul>rekado: i tested GNOME in a VM from 'staging': it works :-) <civodul>Web works, Files works, all these things <civodul>lfam: do you have an opinion about the VM image? <lfam>civodul: I think we should either drop it or improve it. The limitations it currently has are an artifact of a particular project and don't give a good first impression <lfam>I noticed that people are using it as a "test run" rather for a hosted VM service <lfam>The tricky thing in my experience is that all the VM hosters need different tweaks... <lfam>Maybe Daniel Jiang is interested in helping :) <civodul>lfam: or people are using it locally to give Guix a try <lfam>Yes, that's what I meant by "test run" <lfam>It's not great for that :/ <lfam>Unless it's improved for the next release I think we should drop it for now <civodul>so your initial use case won't be served anymore, right? <civodul>OTOH, one could always build it, but that's a bit more involved <lfam>No but that's okay, it didn't really catch on as far as I can tell. I don't think we need to offer this quirky image just for that one use case, especially when it can be replicated by building <civodul>would you like to write that to the email thread? <civodul>so people who're not around can follow <lfam>We should aim to make a Guix service that is like 'cloud-init'. If we'd like to offer an installed image that is more "ready to use" we can also do that <civodul>and for test runs, we could provide a "Live Guix" image or something <civodul>that'd be desktop.tmpl, more or less <nckx>The daemon ‘disallow[s] names starting with a dot for possible security reasons’. Hum. <nckx>civodul: nix/libstore/store-api.cc <nckx>I tried to point to my kernel .config directly (instead of using a copy) and got ‘guix system: error: illegal name: `.config'’. <nckx>That's the only place with that string. <nckx>(So that's ,(local-file "/beep/boop/.config")). <lfam>I recommend checking if Nix still does this <lfam>Maybe the author knew there was some unsanitized filesystem accesses in the daemon somewhere <civodul>it already ensures you don't put a slash in there <civodul>so i fail to see why a leading dot could be an issue <civodul>well, literally "." or ".." are an issue <nckx>civodul: The comment mentions those, but I'll assume some competence and that the author couldn't have been that confused...? <nckx>I mean, that's a pretty big difference there, bud. <lfam>nckx: It *is* POSIX so you know that files and strings are complicated ;) <lfam>efraim: Yes, but something like it would be nice :) When I start a VM on Amazon EC2 I don't have to do any partitioning, rsync my SSH key, or anything like that. <ArneBab>My maven does not recognize mirror settings in ~/.m2/settings.xml — does someone else see that? <civodul>lfam: oh i didn't know "cloud-init" was the name of a real thing <apteryx_>rekado: I decided to persist with the 'guix pack -f docker' approach, as guix system docker-image seemed heavy (it includes guix itself, the kernel, etc). So far I was able to get useradd and groupadd to work, but I'm still working out on 'su': https://paste.debian.net/1076903/ <apteryx_>(also I couldn't get my very barebone config to boot when using docker-image, but I must have done something wrong) <apteryx_>su is the last missing bit to enable 'guix pack -f docker' to be super lightweight (lighter than official debian images) container which can do work as your own user so as to not foobar the permissions of files in bindmounted volumes.