<rockandska>rekado: but having a search engine and command parameters for will be nice
<rockandska>we had a conversation sometimes ago to have the possibility to use the "generated" manifest with all the informations needed to rebuild an env from it with the exact same versions (profile construct in the time)
<rockandska>is there any following regarding this possibility ?
<rekado>re command line for searching past versions: it’s not clear how this would be implemented, nor is it clear how this should behave.
<rekado>do you have a suggestion as to how this would be implemented?
<nckx>rockandska: Sure, host a version of the service on a big beefy public box. Just make it part of guix proper. (Much like ‘ci.guix.info’ is really just ‘guix publish’, available at your fingertips too. Cuirass is just scheduling sugar.)
<pinoaffe>nckx: command -v guix prints /run/current-system/profile/bin/guix
<nckx>Aha. So your shell was *still* running the wrong ‘guix’ even after ‘hash guix’.
<nckx>lsl88: I still have the old logo on my laptop and still managed to convert someone while sitting in my hotel at FOSDEM :-) But yes, our logo is great. It helped convince me that Guix was a serious thing back when I was still a Nixer.
<nckx>lsl88: I have one of your stickers, but my laptop is full.
<nckx>lsl88: Where'd you get that shirt, by the way? Custom order?
<lsl88>nckx: mine's too. I want more computers. Maybe if I add a sticker to my teen she accepts her new OS -she had it since last year, I guess before starting the internship, but remaned a bare bones intallation). I really want to have it there to be able to play :). And my T shirt was a gift from one of my mentors :)
<nckx>Oh well. We knew that was coming. With output?
<lsl88>I will debianpaste the output, but it complains about quemu derivation but afterwards about grub, which is quite understandable I guess, because I made a mistake with the initial configuration and changed the partition
<lsl88>why do you so many servers? and I am doing it the hard way because I want to learn and I want it to work, but if I had to be practical, my machine has no data, I would have done a fresh install in this case
*lsl88 tells nckx that shouldn't feel overwhemeed by their explanation
<nckx>(But that won't work if you haven't told Guix ‘I trust some.other.server’, which is what ‘guix archive --authorize’ does. But you only need to do that once. Even if you never use some.other.server again, it won't hurt.)
*lsl88 brb, my dinner is getting cold and there is a gas shutdown in the block of flats
<lsl88>nckx: in my case if I don't sleep at least 6,5h per day zombie mode
<lsl88>a bad zombie mode. And i can ask you things that I already know, or make a horrible mistake.
<lsl88>when I was at university, I studied hard due to impostor syndrome that I keep having, but i always chose to sleep well. Studied long hours, but even when I had classes in the morning the first years, I had a nap before starting studying
<nckx>I have close to zero tolerance for missing or disturbed sleep. If I miss 1 hour of sleep I'm probably more of a zombie than you after 5h.
<nckx>lsl88: Good. I learned that a year too late…
<nckx>buenouanq: Yes! >24h cycles are so much better.
<lsl88>nckx: and buenouanq but how do you do with your work? I mean, if you have a fixed schedule then you can't do that
<nckx>lsl88: I study and work (mostly) from home. It's a luxury I won't have much longer.
<nckx>(In case you're wondering: the -E keeps most environment variables intact, so the guix running as root is the guix that you ‘guix pull’ed as a regular user. Otherwise you'd use root's Guix, which might be out of date or otherwise broken, and would have to be maintained separately which is at best a burden. So we use lsl88 's guix for everything, even as root.)
*lsl88 also forget commands, I know that "there is a command that allows me to ..." thought that I was the only one. And that worries me and made my impostor syndrome worse
<kmicu>nckx: lfam: ^^ and that’s how ‘always use sudo -E’ or ‘You almost never want plain sudo’ was crashed xD
<efraim>i figured I could work on it by playing with the package definitions and seeing if it want to rebuild that driver or if my list works
<efraim>so far explicit list works, 'fold remove %default-xorg-modules' doesn't
<kmicu>(There is also Guix System manual’s 6.1.5 saying directly that ‘From then on, you can update GuixSD whenever you want by running guix pull as root’.)
<rekado>Blackbeard[m]: we have the huge texlive package, but you may also find the modular texlive packages to be sufficient.
*kmicu would appriciate consitent guidlines for newcomers how to canonically update Guix System. Then we should stick to that when helping newcomers on IRC.
<rekado>kmicu: I believe there used to be a bug which made “sudo -E” necessary.
*rekado pushed some fixes to 389-ds-base and managed to configure a little LDAP server
<rekado>next step: write a simple LDAP directory server service; then revive the nslcd authentication service changes that I had stashed away for months.
<kmicu>Should we, users, follow civodul’s (core developer) recommendation above and ‘guix pull’ as regular user or should we follow the manual recommending running guix pull as root? Should we use ‘sudo -E guix system reconfigure’ or ‘sudo guix system reconfigure’? Consistency = less confusion for newcomers.
<kmicu>That first step in ‘First, retrieve and decompress the GuixSD installation image as described previously (see USB Stick and DVD Installation).’ asks about regular ISO image. I see how that can be confusing. Manual could link directly to needed images.
<apteryx>I think it has to do with how the build system passes the arguments around, I see (configure-flags ''()) in (guix build-system cmake) as well
<htsr>The manual should give command to resize the virtual size of the qemu image (I can't guix pull because it's too small)
<apteryx>but still my understanding is naive ;-). I have to run.
<roptat>htsr, from the motd of the system, you already have some hints (but no full command, sorry): 0) deleting and recreating the partition with fdisk, 1) reloading the partition table with partprobe, and then 2) resizing the filesystem with resize2fs.
<htsr>roptat: I think it's possible to do it before launching the vm with the virt-resize command
<rekado>htsr: if you think that there’s a better way, I’d like to encourage you to submit a patch or to discuss the possibility of a patch on firstname.lastname@example.org. You might be right and we missed an obviously better suggestion.
<civodul>kmicu: re "sudo guix pull", commit 796a4491fdaa4a0a3d669457b89356f9fbfc966e hopefully clarified things
<rekado>it would be nice if the “name-service-switch” field in the operating-system record could be replaced with a system service instead.
<rekado>this would allow us to automatically extend it.
*rekado writes documentation for the nslcd-service-type
<vagrantc>hrm. so i tried to add DM_CRYPT and freinds to the aus-c201/veyron-speedy kernel i've been working on, and for some reason on armhf it pretty much hangs indefinitely when doing any significant work on a crypted device
<vagrantc>that seems like that should be easy enough to patch...
<apteryx>mbakke: I'm not sure it's possible to pull all the configure arguments out of 'arguments' for cmake, as we are using "out" which AFAICT is only made available on the builder side (inside build phases).
<roptat>It happened again! The sd card seems to be corrupt again after guix pull :/
<anadon_>I'd like a point of clarification: two packages installed with mutually incompatible runtime libraries do or do not work with guix under the same user at the same time. Which?
<nckx>htsr: If you don't know, I must be mistaken. guix describe.
<nckx>anadon_: s/user/profile/. Do they have the same file names?
<anadon_>The two hypothetical packages would have different names, but their runtime dependancies would have the same name.
<nckx>anadon_: But file names, as in two incompatible libraries both named /lib/libfoo.so.3.2? [Setting aside for how this is a huge red flag about the software itself, and it's not Guix you should be worried about.]
<anadon_>Oh yeah, python is a peice of work. It only makes sense for a single user single project approach from what I get. There are ways to force it to work in various other convoluted ways, but they are not perfect. See: Python Poetry.
<anadon_>Also virtual environments. If Guix could meet those kind of runtime isolation requirements, it would be utterly perfect.
<anadon_>Like, toss out my companie's entire package management systems perfect.
<nckx>anadon_: In general, I'd say: if it can be made to work on non-Guix systems (using virtual envs or whatever, look I know a Python word) it has to be able to work on Guix. But you'll have to talk to a more Pythonic Guixer than I am.
<vagrantc>was toying with the idea of partitioning a dm_crypt device, but might have to put a loopback device on top of the encrypted device to get that ... i guess i'd also need to figure out/enable loopback device support
<nckx>vagrantc: dannym posted something to do with loopback booting to the ML very recently. It was for another purpose (booting from ISO images) but might overlap?
<civodul>rekado: re nss, i agree we should make it extensible (currently we can extend nscd but not nss)
<rekado>I just added the nslcd-service-type with a system test. I’m not 100% happy with it, though, because things like “id” don’t work without setting LD_LIBRARY_PATH.
<rekado>I hope I can tweak this some more and then use it on the workstation in the office to finally replace Fedora.
<roptat>I'm installing a guixsd system from a foreign distro installed on another distro, so I don't have cow-store. What should I do to ensure it can boot?