<raghavgururajan>civodul Cool! I have also reported to Snopyta. We are discussing whether to restrict webirc.snopyta.org and irc.snopyta.org to Snopyta users. <civodul>raghavgururajan: great, thanks for taking care of it! <sys2>hi #guix, can I find out why a specific package was installed? like what depends on it? it's not in my user profile or system profile... and it's failing to build <lfam>There are a few approaches <lfam>Give me a minute to gather my thoughts on the subject <sys2>I haven't set up the deps for guix graph to display graphically yet... so I think that's out.. also I'd like to check the system profile (and no sudo access, but I do have root access), so it'll need to be text based <sys2>sure. thanks for getting back! <joshuaBPMan>civodul: and mroh You can actually watch me increase emacs' memory and then stop it with this video: <lfam>sys2: There's a few options. A handful do require the visual graphing to be useful, unless you are a wizard of graphviz <lfam>It would be nice if you could do `guix graph --path package-name /gnu/store/...-system-profile` or something like that, but the command expects two packages <lfam>You can install recutils and use that like this: <lfam>`guix package --search=. | recsel -e 'dependencies ~ "libcap"' -p name,synopsis` <lfam>That will list the Guix packages that depend on libcap, for example <lfam>I feel like I used to have a better answer for this question but it eludes me <lfam>If you tell us what package it is, we might be able to make a good guess <lfam>Especially since we'll need to address the build failure <sys2>it's qemu-minimal 5.0.0. has been failing for awhile <sys2>my system config is minimal (only packages are base, nss-certs, tmux, zsh, cryptsetup)... I'm guessing one of those requires it? <sys2>will see if I can guix graph and check the output <lfam>I find that it has built for me — I assume I got a substitute on this machine <lfam>How does it fail? Did you inspect the build log <sys2>occassionally get a failure... usually fixed by a pull.. hit a snag once... forget what the fix was <sys2>yeah I think it was in the verify step? will rerun <sys2>tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) <sys2>ERROR - too few tests run (expected 17, got 0) <sys2>that's from an old run though... it's still compiling <lfam>We'd need to see more, ideally the entire log <lfam>It's a weird error, not expected at all <lfam>How much RAM do you have and which CPU architecture are you using? <sys2>(total/used/free): 7.7Gi 1.3Gi 1.5Gi <sys2>cpu: AMD Phenom(tm) II X4 965 Processor <sys2>have to leave :(... but I will check the irc logs tonight and be back tomorrow. I can make a bug for this if needed as well. Thanks for the help so far! <lfam>sneek: later tell sys2: I noticed one of the reporters also had it fail on an AMD chip. I wonder if the bug is specific to AMD somehow <grubles>it appears the signing key for guix-system-install-1.1.0.x86_64-linux.iso has expired <grubles>Primary key fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 <nckx>‘[expires: 2020-12-21] Key fingerprint = 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5’ <nckx>Sounds like you need to update your keys. <nckx>Possibly using sudo -i gpg depending on who's checking. <nckx>(I'm sure it's on a well-known key server too but I tend not to mess with those anymore.) <grubles>i got my keys from keyserver.ubuntu.com <nckx>The copy there is old (expired 2020-09-06T20:53:43Z). <nckx>I guess anyone could upload the newer key to any server. Dunno if it's polite to do so. ***catonano_ is now known as catonano
<pancak3>I submitted a pretty important emacs-next patch like 3 days ago in a bug report (43277) but I'm not sure if the right people have been notified :/ Is there someone is specific I should let know? <pancak3>yep. currently emacs-next won't even start. But I've been running it with that patch with no issue for 3 days now <lfam>I'm not an Emacs user so I can't give the kind of review it deserves <lfam>Am I correct that it downgrades the package from 28.0.50.1 to 28.0.50? <pancak3>Ya. Never should have been 28.0.50.1. The 1 on the end means it's the first build in that folder. It gets incremented everytime make is called <lfam>I recommend adding a note to your submission to explain that <lfam>I have to go afk for a bit but I'll reply with some more detail <nalaginrut>hi folks, how can I install guile3 with readline? <nalaginrut>pancak3: well, if I install guile from guix directly, there's no (ice-9 readline), my question is how to install guile-with-readline-version <pancak3>I'm on guixsd, no guile or readline in my profile, and it works. Maybe the solution is to not install them? <pancak3>Which of course is not great advice if you're on a foreign distro :P <pancak3>my guile is our guile 3.0.4 package. And readline just works with it. I'm fairly certain you shouldn't have to do anything fancy to use the readline feature <mroh>nalaginrut: after `guix install guile-readline`, you should have (ice-9 readline) in your profile. <pancak3>ah I see now. I guess you're on a foreign distro. guile-readline is in %base-packages <pancak3>my bad. I assumed I wouldn't have a fancy guile setup since I hadn't installed anything <nalaginrut>I installed guile-readline, and 'guix environment guile', however, it still complains no (ice-9 readline) <pancak3>check GUILE_LOAD_PATH? idk if that's useful but some problems are easily found by doing "env | grep problem" <pancak3>guix show guile-readline = 3.0.2 for me <pancak3>it looks like in the past there was a guile3.0-readline <pancak3>I don't think so. I have guile2.2-readline avaliable to me <pancak3>but of course it doesn't show up when you guix search guile-readline which is really annoying :/ <pancak3>I've got to sleep. Take care guys. I still care about what you where going to say lfam so I'll make sure to read the logs tomorrow <apteryx>we'll soon have the full QEMU documentation as an info manual :-) ***amfl__ is now known as amfl
<civodul>what's up with all these disconnections? :-) <bdju>what's the solution for running gdb on a program when it says it's not an executable file? seems dino is technically a bash script that exports some env vars before launching .dino-real <bdju>but if I use .dino-real directly I'm not signed in or anything <civodul>ah yeah, those wrappers can be annoying <civodul>maybe you can start the program and then attach gdb to it? <civodul>or if it crashes, just wait for the core dump :-) <bdju>hm the trouble then is that it freezes the program and if I let it start it over then it doesn't have my data again <bdju>yeah, maybe will have to go the core dump route <civodul>the program freezes until you type "c" ("continue") in gdb, no? <bdju>ah, I'm new to gdb. the only instructions I saw said to use r <cbaines>civodul, I'm making some progress on writing some services for the Guix Build Coordinator, what do you think about deploying it to bayfront? <cbaines>bayfront is building things, but just keeps running out of space <civodul>cbaines: you can even deploy on berlin: the build nodes are idle most of the time <civodul>as long as the coordinator itself doesn't put too much presure on berlin itself, we're fine <civodul>i'd you can add the "coordinee" (?) service on half of the build machines <cbaines>there's one coordinator service, and agent services that do the builds <cbaines>but yeah, I'll hopefully have some initial patches done at some point today <mothacehe>Hello! Did someone already had a look to Nix flakes and how it could translate for Guix? <civodul>i had a quick look and it seems kinda similar to our "guix.scm" files no? <civodul>there's the whole registry + GitHub integration thing in addition <civodul>actually it's maybe closer to a Guix channel <cbaines>I thought it looked similar to channels <civodul>yeah, and the "nix shell" examples remind me of time-machine <civodul>the "lock files" are liked pinned channels it seems <cbaines>and while lock files do provide "reproducibility", it does deviate from the typical way Guix would do that, via being explicit upfront, and instead start trying to record the environment so that it can be reproduced <civodul>it's not very different from storing the output of "guix describe" <cbaines>the most useful way to look at nix flakes is probably from the perspective of the problems that are mentioned when justifying the work <cbaines>and then thinking about how those could be addressed with Guix <civodul>the post seems to imply Nix can distinguish between "packages" and derivations <civodul>looks like at least some of the problems mentioned in the intro are addressed by channels (like 3rd paragraph) <civodul>others less so, in particular "no easy way to deliver Nix-based projects to users." <mothacehe>One use case that seem attractive is to provide a way to build a Git{hub,lab} by specifying the needed channels and their minimal version. <mbakke>mothacehe: I think the OpenBLAS update can not go to 'master' because it has a lot of dependents <raghavgururajan>civodul: Would you be restore yesterday's IRC logs, to its original? Snopyta's admins were investigating but the original logs disappeared. We they are unable to report and discuss with DisMail and ProtonMail team. <pancak3>So 4 days ago I submitted a patch that fixes 43277 (emacs-next not working) but it does some pretty serious changes (like downgrading the version because the previous version was wrong). Is there someone who deals with Emacs changes that I should CC? I want to make sure it gets looked at <raghavgururajan>pancak3 Most guix-heads are emacs-heads. I am pretty sure that emacs stuff won't get over-looked. 😀 <pancak3>Well I'm not sure if any guix-heads are following that bug report. I just feel like I put it in a spot that's not likely to get looked at <pancak3>I feel like I'd be much less concerned about my patches getting lost if there where just less bugs :P unfortunately, it's much more fun to do my own thing than to try closing old bugs <pancak3>oh I totally forget who suggested it to me. I should really be more grateful :P wasn't my idea though <pancak3>I'm kicking myself for submitting the emacs-next package with the version "28.0.50.1". The 1 on the end is the build number. It just get incremented locally every time you run make. "28.0.50" is the real version number <pancak3>but 28.0.50.1 > 28.0.50. Does Guix handle this well? <mothacehe> mbakke: oops missed it, I'm going to revert. <civodul>raghavgururajan: i don't think we touched the IRC logs actually ***pancak3 is now known as morgan`
***morgan` is now known as morgansmith
<morgansmith>might as well use my real name I guess. No more pancakes for me <xelxebar>Man, guix is slowly seeping into every part of my dev process. I find myself creating little environment manifests for various dev tasks. <xelxebar>Now I'm starting to question what to even put in my default user profile. <xelxebar>It might make sense to simply define a collection of profiles for different roles. <rekado_>civodul: I’ll edit the logs to remove the URL <xelxebar>Still haven't fully grasped the implications of guix environment. <morgansmith>xelxebar: I never managed to get multiple profiles working how I liked it :/. Did you just follow guix-cookbook? Maybe I should try again :P <xelxebar>morgansmith: I just have been creating different "manifest.scm" files for the various profiles I want. <xelxebar>Several of my projects now have a .dev.scm in them, and I have a few more general ones under .config/guix/manifests/ <morgansmith>xelxebar: I only started using a manifest after my last attempt. Maybe that's the trick to making it nice :D <rekado_>I’ve been thinking about moving all my Emacs stuff to a separate profile <nckx>raghavgururajan: I'd created a ‘.orig’ back-up of yesterday's log but it simply showed up at the top of logs.guix.gnu.org, so that's how that works... I'll send you the original. <morgansmith>xelxebar: I probably shouldn't be so proud but some of the first scheme I wrote was this for my manifest: (map (lambda (x) (string-append "emacs-" x)) '("all-the-icons" ... <xelxebar>morgansmith: Yeah, specifications->manifest is your friend. It's a bit annoying to build/rebuild the first time (or after a guix pull) but that's a fairly minor up front cost for the benefit of clear and executable build documentation. <civodul>rekado_: cool; you can also send the raw logs to raghavgururajan so Snopyta can handle it <nckx>I already scrubbed logs.guix of all the free speech yesterday. <nckx>I have 0 qualms about memholing these folks. <morgansmith>did the irc logs get messed up? Does this mean lfam got back to me? I didn't see any reply in the logs <nckx>[16:37:28] *** guiyrte was kicked by lfam (guiyrte) <nckx>☝ not good! Has this been fixed yet? <morgansmith>xelxebar: How do you store your profiles? If you have a .dev.scm do you also make a profile folder there? <morgansmith>xelxebar: actually what's in the .dev.scm? Is it just a manifest? <nckx>Ah, they used +b, not ChanServ, so the blanket ban's still on. <xelxebar>morgansmith: Really simple. The *.scm files are just specifications->manifest calls listing the packages needed for each "profile". <xelxebar>The intent is to use each with guix environment [--pure]. <rekado_>morgansmith: I used to recommend the following convention: add a guix.scm file to the project and always instantiate the profile in $PWD/.guix-profile <morgansmith>Dude!! I didn't know manifests worked with guix environment!! That's freaking awesome! <rekado_>morgansmith: our users here would then be able to do this with a few shell functions and aliases. <rekado_>so we’d also offer an “enter” function to automatically load $PWD/.guix-profile/etc/profile <rekado_>there’s none. It’s just something we did at the institute where I support Guix users. <morgansmith>oh, so it was like something people but in their bashrc's or something? How did the automatic loading work? <morgansmith>Also, what's the different between loading a profile and just using guix environment to load a manifest? Profiles only contain packages right? So they should be the same? <rekado_>morgansmith: loading etc/profile may be faster <rekado_>if you’ve run “guix pull” since the last time you used the profile “guix environment” may have to do some more work <rekado_>loading etc/profile on the other hand is instant. <morgansmith>rekado_: Ah, that makes sense. So guix environment will try to generate a profile for you which is different from trying to load a pre-existing profile. Makes sense. Thank you! <morgansmith>I think I'm going to try and set up a secondary profile which has all my main software so I can use the default profile just for trying out new software. If I go crazy maybe I'll set up a profile just for installing modified packages I'm currently hacking on in the guix source :P ***ChanServ sets mode: +o nckx
***nckx sets mode: -b *!*@xmpp.snopyta.org
***ChanServ sets mode: -o nckx
<morgansmith>I just noticed the guix manual suggests doing "sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild" before doing "./pre-inst-env guix build package" but I've never done this. Is the manual outdated? Should I be doing this? (section 15.2) ***roptat_ is now known as roptat
<roptat>morgansmith, only if you have modified the daemon or don't have a daemon running <sys2>sneek: tell lfam thanks :) <sneek>Welcome back sys2, you have 2 messages! <sneek>sys2, lfam says: I noticed one of the reporters also had it fail on an AMD chip. I wonder if the bug is specific to AMD somehow *civodul found another bug in the fakechroot wrapper <wleslie>oh it's the message report, I thought sneek had become a bug management system <morgansmith>is there and different between sourcing /etc/profile and using guix package --search-paths=prefix? I'm asking because I want to activate a profile with --search-paths=suffix but I want to make sure it's a valid way to activate a profile <civodul>--search-paths is little known but i find it pretty cool <morgansmith>Isn't it recent? A while ago guix pull didn't suggest --search-paths but now it does <civodul>it's been there since the beginning, before etc/profile <civodul>but maybe the message for those suggestions changed a bit <morgansmith>just to double check, I should put it in my .profile as: eval "$(guix package --search...)" right? <morgansmith>It seems to work, but environment variables are always where I seem to mess up :P <civodul>note that .profile is for login shells only <civodul>so to test it you should do "bash --login" or similar <morgansmith>nothing is wrong with my env vars right now (that I know of) but in the past I've had no shortage of troubles. Most of those troubles where getting ssh-agent and gpg-agent working (but that was on arch-linux and the config still works flawlessly on Guix so I've got no Guix specific complaints) <morgansmith>hmm... what file is run for every single shell? I don't want to use bashrc since my login shell doesn't read that :P <morgansmith>do you have any suggestions for where to start shepherd for user services? That's currently in my .profile, but then a new syncthing instance happens everytime I login to a new tty :P <morgansmith>Sometimes I run x on multiple ttys and sometimes I don't run x at all though :/ <wleslie>an abstract session, floating in the aether <civodul>usually at that point in the discussion, someone shows up and says that we really need user services on Guix System :-) <morgansmith>{ps -a | grep shepherd && command -v shepherd} || shepherd ?? <civodul>morgansmith: actually you can run "herd status" and see if it fails <morgansmith>if I log out of tty1, would a shepherd that has been started in tty1 stop? <civodul>like "herd status > /dev/null 2>&1 || shepherd &" <mothacehe>raghavgururajan: civodul: Yes it's annoying, I'll see what I can do about that :) <nckx>rekado_: I deleted the ~ back-up because everything shows up on logs.guix. <nckx>raghavgururajan: I sent you a message earlier. ***ChanServ sets mode: +b *!*@xmpp.snopyta.org
***perflyst was kicked by ChanServ (Banned: abuse-prone provider)
<nckx>I'd like to drop that ban if it's OK <nckx>If nobody (lfam?) objects. ***ChanServ sets mode: -b *!*@xmpp.snopyta.org
<raghavgururajan>mothacehe: Thanks! Btw, why there is different things like stable and latest? Guix is rolling-model right? So, i think there should be only latest? <PotentialUser-60>I have a problem. I wanted to instal guix on my machine but the istaller desn't see my network card. Can you please help me to solve this issue? My network card is working with tisqurell linux. <mothacehe> raghavgururajan: Even though Guix can be seen as a rolling release distribution, we sometimes release some stable version (last one is 1.1.0). <morgansmith>Would it be possible for the system shepherd to start my user shepherd? <mothacehe>As releases can be distant from several months, it can be useful to have "latest images" which are no more that installation images built on top of master by the CI. <raghavgururajan>mothacehe But, even if a user install guix installs from iso of stable webpage, when the user does guix pull, the guix gonna update to latest one right? <mothacehe>Yes right, but if there's a bug in the installer (happens sadly), having a new installation image released can be useful <rekado_>nckx: oh, thanks. Emacs defaults on a new system… <nckx>PotentialUser-60: That card's driver's firmware is non-free. We don't support non-free software here, sorry. <raghavgururajan>mothacehe Cool! I was thinking if we could just have one webpage to download images and which is always latest. Because, currently the stable has no point as it would be updated to latest guix after guix pull anyway. <roptat>isn't trisquell an fsdg distro? if it works with them, isn't there an issue? <nckx>raghavgururajan: The release installer is supposed to be better tested than a random latest commit. <raghavgururajan>roptat: Yeah, Trisquel is FSDG. Might be the older kernel that would have supported that hardware. <raghavgururajan>nckx: Ah In that case, cool! I thought the stable image was generated from the commit, that was the release of Guix 1.1.0 <nckx>And having known bugs (‘the wi-fi freeze’, ‘the NVME oopsy’) makes it easier to support in a way. <nckx>raghavgururajan: It is. That's the commit that was tested. <morgansmith>I figured out a better way to start a user shepherd that doesn't get killed when you logout: command -v shepherd && { herd status || setsid shepherd } <raghavgururajan>nckx: I meant to say that I didn't know it was well-tested. I thought it was automated CI generated image on every guix's release. <nckx>raghavgururajan: Defaulting to latest would expose users & support staff to a constant stream of exciting new bugs instead of a handful of familiar ones. <nckx>Note that I don't have a strong opinion, I'm just pointing out the rationale. <nckx>raghavgururajan: No, it's *supposed* to be frozen, tested, bugs fixed, then released. <nckx>Everything likely to cause problems during of immediately after installation (i.e. before the user has had a chance to guix pull && upgrade their new system). <nckx>AFAIK we still don't recommend pulling during the installation itself. <mothacehe>but as they are running in a VM, some HW related issues are of course always found when testing the "stable" image. <nckx>The test suite (and Guix's testability in general) is great but it can't do much to emulate a diverse bunch of people trying to break something on hard metal. <nckx>We met briefly & confusingly in #snopyta. <raghavgururajan>The webirc and irc-transport are gonna be restricted only to snopyta registered users. 🙂 <perflyst>that is correct, thanks for unblocking and sorry for the spam issue yesterday <nckx>raghavgururajan, perflyst: Thank you! <lfam>Huh, I noticed that a message I sent last night never appeared on bug-guix <lfam>Not a huge deal because the bug has been closed now, but very strange <nckx>lfam: The moderation queue is empty :-/ <lfam>I sent it to <43344@debbugs.gnu.org>, Mark, Mathieu, and Marius <lfam>My mail host (fastmail) does show that it was sent <nckx>I never got a moderation request. <nckx>bug- and -patches are now moderated like help- and -devel already were. <lfam>I mean, it's not weird that they are being moderated. It's weird that my message was not delivered <nckx>Well, I just got one for Ludo' (I approved it but will keep an eye on them, they seem louche), but they're not subscribed. Are you? <lfam>Yes, I'm subscribed to all of them <nckx>Then I guess you're grandfathered in and not subject to moderation which doesn't clarify things. <lfam>I wonder how widespread the problem is <civodul>funny that "louche" is a thing in English <lfam>Many people would not know that word <civodul>WordNet knows it, WordNet is English, so louche is a thing :-) <lfam>Yes, it's technically a thing :) <civodul>"wn louch -famla" says it's very rare <nckx>I think it's *slightly* more common this side of the sea, but it's not an everyday word. <civodul>the kind of word to use if you wanna sound posh (or French) *nckx AFK to eat frites, because sometimes clichés are just true. <civodul>now you're pushing too far: frites is not a thing <lfam>Ahem. They are called freedom fries <apteryx>nckx: if you ate them with chop sticks, you wouldn't need stepping away from the keyboard <lfam>It's almost totally forgotten here <lfam>Another absurd disingenous panic <minall>Hello Guix Community!... does the guix ISO work?, I could install guix without a problem a few versions earlier but, not I dd'd into my USB 2 times and my laptop still doesn't detect the installation <lfam>Hm, that should definitely work minall <lfam>minall: Can you share the full dd command you used? <minall>sudo dd if=guix-system.....iso of=/dev/sdb status=progress, it stopped at '589158400 bytes (589 MB, 562 MiB) copied, 163.124 s, 3.6 MB/s' <lfam>I would try it again with the addition of "conv=fdatasync", to ensure the data is fully written <lfam>Otherwise, dd will exit before the data is written and you might pull the USB flash drive out too soon <lfam>Or maybe even "conv=fsync". I'm not sure what's the best recommendation for this <minall>Very well, I'm gonna try that option <minall> No luck... Maybe there are previous ISO's for me to install guix? <Winux>HIRealtek RTL810xE PCI Express Fast Ethernet <lfam>minall: Sure, you could try one of the older installers, but it won't be an easy path. You'll likely have to build *everything* from source <lfam>I think it would be simpler to figure out why your flash drive isn't working or isn't being recognized <nckx>civodul: I expressly wanted to avoid fries/chips politics. So that failed. <nckx>apteryx: We eat them with cutlery and mayonnaise, as our good lord intended. <nckx>minall: Have you tried the ‘latest’ ISO already? <minall>The strange thing is that, it's the same USB I used in previous installers that worked perfectly <civodul>nckx: fries/chips politics are a hot topic, not to mention crisps (i'm sure lfam has never seen crisps) <nckx>civodul: I think that's what those people call a crumble. Madness reigns. <nckx>Eat fritters not critters. Did you get my mail? And were you having trouble joining #guix yesterday (RG[web], IIRC)? ***jess is now known as j
<nckx>Actually, you're still having trouble, since I sent you 2 /msgs today. <raghavgururajan>nckx: Ah yeah, i forgot that webirc.snopyta.org was blocked and tried it accidentally. <raghavgururajan>I am on the web, using ConverseJS. That might be the reason for your /msgs not showing up on my end. <raghavgururajan>I will soon be reinstalling Guix on my new SSD and getting back on Gajim. <raghavgururajan>nckx: I see your /msgs now. Had to open nckx%irc.freenode.net@irc.disroot.org <mroh>Hello #guix^Wbaguette smokers! <nckx>brettgilio: You're the first to ask. <nckx>Well, I think we should discuss it, but sure. <brettgilio>But unrelated. I installed Guix system on my t430, and it is... Painfully slow. Like, what usually takes 30 seconds to boot Debian and get to gnome desktop takes Guix almost 3 minutes. <nckx>My x230t takes several minutes to boot but I've always blamed bcachefs (and it is a significant factor). What kind of (last) output do you see during the pause(s)? <brettgilio>Usually about drivers for my WiFi card not being found, which is expected <nckx>‘Error in finalization thread: success’ is French for ‘Booting Guix. Welcome!’ <nckx>Right. But nothing about (fscking) file systems? That takes at least ~30s here. <brettgilio>Will get back to you on that. Not near that book right now <lfam>Booting with the shepherd is much slower than with systemd <civodul>you get to think of all the parens in action as you see it boot <brettgilio>It's even that things like Network manager won't spawn until like 2 minutes after boot either <lfam>Just saying that the slowness is expected in comparison to standard Debian <lfam>This is how things used to be on Debian before systemd, in my experience <lfam>I remember when booting took 10 minutes. Sometimes even 15! <civodul>slower yes, but it shouldn't take 2m to start NM like brettgilio writes :-) <lfam>It's why systemd's service startup parallelization is such a big deal <lfam>I think we have all the information we need to do something similar <lfam>That is, we model the services as a graph, right? <lfam>Booting Guix on an HDD is like the worst case, due to the storage layout of /gnu/store <lfam>After things are cached it gets much better <lfam>The storage becomes highly fragmented and there's not really any way to defragment it in a way that is meaningful for Guix <nckx>I used to boot Guix off of a 5400 RPM HDD. Wild. I was used to Nix by then, which ha{s,d} the same problem of multi-minute boot times. <nckx>I wonder if they've improved over the year and how much systemd's parallelism helps them. <lfam>I imagine it helps a bit, but the extremely random filesystem layout must still hurt a lot for spinning disks <brettgilio>I have another computer that is SSD that boots guix basically instantly <civodul>lfam: i think physical layout is independent from directory layout <civodul>it could be just as bad on an FHS system after a bunch of install/remove/upgrade cycles <civodul>but there are things that lead to more I/O, and in particular lengthy search paths (RUNPATH, etc.) <lfam>I think our layout still doesn't help. On FHS the system can open /usr and the kernel could start paging everything <lfam>Oh yes, our lengthy RUNPATHs <lfam>Watching those lookups in strace, I can imagine how bad it is on spinning disks <nckx>I'm not a file system designer, but compare readdir("/usr/bin"); readdir("/usr/sbin"); done; to what a Guix system needs to do. Symlinks are just text files that need to be looked up from scratch. ‘Caching is magic’ only kicks in once caches exist. <nckx>How can that not be orders of magnitude slower? <brettgilio>I don't want to alarm anybody, but I put my Debian and guix machines in front of my 9 month old and he chose the guix machine. So we have been approved <brettgilio>Re cloaks. if the GNU project doesn't already have a cloak assignment to it, I think we should go forward with the idea of discussing getting our own project cloak <apteryx>brettgilio: what are cloacks useful for? <nckx>They have no technical function. <brettgilio>apteryx: showing project affiliation. I think maintainers should get gnu/guix/maintainer and committers get gnu/guix/committer <nckx>They do not mask your host/IP. <nckx>If you ask for a cloak in Freenode they will refuse to cloak you if you answer differently. <apteryx>meh. Then I don't see much value in them. <brettgilio>apteryx: it's mostly useful for the freenode staffers to know who you're affiliated with <nckx>They are purely a team-building T-shirt. I think those have value, but they're not needed. <brettgilio>Like the fsf member cloak may just be to show off a bit <nckx>raghavgururajan: OK, then you've had to answer the question 😉 <nckx>Teensy bit, in that staffers will initially assume it's unlikely you printed your own T-shirt at home, sure. <brettgilio>Technologically they are equivalent, but the freenode staffers wont give a cloak without assignment <brettgilio>My connection IP will just take you to my website <brettgilio>I have a reverse proxy for znc.brettgilio.com didn't know I could rDNS my hostname/ip <nckx>raghavgururajan: Absolutely. I was only talking of guix/contributor/foo-style cloaks. *brettgilio is looking up how to rdns <lfam>I don't mind having my IP show up. It's a good reminder that this is real life, too <nckx>Don't feel obligated on my account, just seems like the kind of thing someone who's interested in a cloak would like too. ‘Your’ IP is there anyway, might's well make it purdy. <nckx>lfam: Exactly. The fact that whoising me returns what's basically a working e-mail address keeps me alert. <nckx>Not that it's ever received mail. *brettgilio whois tobias.gr <nckx>Ah, I meant /whois. GDPR killed $ whois. It's OK. <brettgilio>We need a guix mumble too... I want to yell profanities whenever somebody sends pr0n to our mailing list <nckx>brettgilio: You've got that droplet... <nckx>(Does it run Guix System?) <nckx>Mumble's packaged for Guix. I'm sure it's not packaged for this ‘Debian’ yet. Time to switch. <brettgilio>I'd like to use guix on my webserver. But it's going to be a bit of work to get everything switched over <brown121407>brettgilio: it only took me an entire day to set mine up <brown121407>If you know NGINX it should be at most a quarter of that time cause most of it I was just cursing at the configuration <nckx>Oh, not just the init, OK. <brown121407>brettgilio: that should work too. I used NGINX just cause the first tutorials for setting up ZNC for a subdomain were with NGINX. I don't know either NGINX or Apache, but the Guile config made it a bit easier to work with this stuff <nckx>Does anyone use Guix's php(-fpm)? What's the right way to tweak php.ini? <brettgilio>[13:19] brettgilio: So apparently new Firefox versions downloaded from their website block you from browsing when it has an update. <lfam>It looks like all the recent CI evaluations are stuck "in progress" <catinabox>Also, is there a way to upgrade an existing GNU/Linux install to GuixSD? (i.e. replace the install while leaving data directories like /home in-place on the existing root filesystem) <lfam>catinabox: Yes, you can use the `guix system init` tool for that. You'll probably want to take a backup first, but it does work <nckx>‘guix system init / your/system.scm’ <nckx>It will leave a lot of old-distro cruft behind but it works surprisingly well. <catinabox>ahh lovely, thanks; yeah, I figured, because one time when I borked a GuixSD install really badly I used guix system init on the existing root filesystem to repair it; just wanted to check that it was still a working idea even if the root filesystem was a foreign distro :) <lfam>catinabox: Yes, it still is expected to work and is even the recommended way in certain cases <cbaines>wooho! I think I've finally cracked the "calling (backtrace) in Guile actually raises another exception" issue I've been trying to resolve for months now <cbaines>and I can finally see what's going wrong in my code <cbaines>Rather than Guile (backtrace) erroring with: <cbaines>In procedure string->number: Wrong type argument in position 1 (expecting string): #f <civodul>cbaines: so there was an exception raised from 'backtrace'? <civodul>(i use 'display-backtrace', didn't know 'backtrace' was a thing) <cbaines>It works some of the time, but I think it's having problems because sqlite is involved <cbaines>what I can see is that (backtrace) is called, and then code after it doesn't execute, and I get that output about: In procedure string->number: Wrong type argument in position 1 (expecting string): #f <cbaines>I've spent a long time looking for where string->number is called, and I'm pretty sure now it's in Guile itself... <cbaines>printing out the exception works though, I was just doing that after trying to print the backtrace, which didn't work, as printing the backtrace crashed <cbaines>printing out the exception details before risking calling (backtrace) is much better <cbaines>I can now see: worker-thread: exception: #<&compound-exception components: (#<&error> #<&origin origin: sqlite-exec> #<&message message: 1555> #<&irritants irritants: "UNIQUE constraint failed: build_results.build_id"> #<&excepti <cbaines>on-with-kind-and-args kind: sqlite-error args: (sqlite-exec 1555 "UNIQUE constraint failed: build_results.build_id")>)> <cbaines>which is great, as I can guess at why that's going wrong :) <civodul>it'd be no fun it the source of the problem was displayed <cbaines>I've played with them in a VM, but that's all the testing I've done so far <civodul>guix-build-coordinator-queue-builds-service-type -> 48 <civodul>call-with-current-continuation -> 30 <Gooberpatrol66>Is there a way to print the currently-used system configuration? <cbaines>you obviously haven't got to guix-build-coordinator-queue-builds-configuration-processed-commits-file which comes in at 72 characters... <bavier[m]1>Gooberpatrol66: `guix system list-generations` will print a file-name for the current configuration <cbaines>maybe guix-build-coordinator needs replacing with a snappier name, or abbreviating <andreas-e>cbaines: Yes, marketing wise, I think there is still some room for improvement... <civodul>it has the merit of being very clear about what it does :-) <cbaines>I exercised some restraint and didn't write guix-build-coordinator-queue-builds-from-guix-data-service-configuration-processed-commits-file <civodul>i'm currently using my screen vertically but if need be i can rotate it <civodul>but maybe now's not a good time to rename :-) <cbaines>yeah, that might work, then you'd just have guix-dispatch-service-type <cbaines>but yeah, it's probably not something to rush in to <civodul>but you know, it's always easier to discuss the name of the bikeshed, so here i am <cbaines>andreas-e, while you're here, I'm trying to catch up on email, and just reading the thread about milano and bayfront <cbaines>Cuirass in it's current configuration on bayfront seems to easily use up all the space <cbaines>the only thing that'll help with that is offloading to a slower machine, so it fills up slower, which probably won't be the case with milano <andreas-e>And what is the difference with berlin? A smaller disk? <cbaines>berlin has a much bigger array of disks I think <cbaines>I think Cuirass uses a TTL for the gc-roots it creates for outputs it has built <cbaines>I'm just trying to work out what the value configured for bayfront is currently... <andreas-e>And/or buy more disks? It shows how far we have come. When we bought bayfront, 4TB seemed like a lot. <nckx>berlin has a 37-TB array. <nckx>Well, my point is it's 93% full, so don't look there for magic configuration solutions. <rekado_>it’s been a while and I didn’t do the initial setup <nckx>I thought you built these things with your bare hands. <andreas-e>Bayfront has a raid10. So two 4TB disks give 4TB. <PotentialUser-51>hey guys, I installed the disto with the grapical interface and I want to update the packages that were installed with the desktop environment I chose but no updates get done whether I do "guix pull && guix package -u". how can I update the packages that were installed via the graphical installer? <rekado_>I keep forgetting what the numbers mean <cbaines>I don't think many people look at the system test results on bayfront, so it could be that much of the space is taken up with disk images that aren't very useful <rekado_>so I have a guy who wikipedias the numbers and picks the right configuration <andreas-e>If we bought a third disk, we could get 8TB in raid5. Or maybe 12TB in raid0? What is the point of redundancy for our reproducibly built packages? <nckx>PotentialUser-51: sudo guix system reconfigure <your system. .scm> <catinabox>PotentialUser-51: did you also do guix system reconfigure with your chosen system configuration? the desktop environment may be part of the system configuration and not your user profile <nckx>If you used the installer, that's probably /etc/config.scm. <rekado_>andreas-e: the redundancy also helps with the OS, which lives in /gnu/store <nckx>(The only reason for RAID.) <andreas-e>We do not have space for many more disks in the bayfront case. <cbaines>dropping the configured TTL is pretty easy, that just requires editing the #:nar-ttl (* 15 24 3600) value <cbaines>getting bayfront not to build as many disk images may be a bit harder <cbaines>I think keep trying things until the machine stops running out of space may be the approach to take, given I'm not sure how to calculate how much space should be required <rekado_>“guix-build-coordinator-queue-builds-service-type” — the “-service-type” suffix has always irked me. I imagine a world where this would be part of the value itself, some sort of … “type” perhaps <andreas-e>I never understood why these things are called "type". They are more like "values", no? Not a type in the programming sense. ***rekado_ is now known as rekado
<rekado>(service guix-build-coordinator-queue-builds-service-type) is a value <cbaines>Thinking about system tests, if there's new system tests for each evaluated commit, and those come with big disk images, then 7.5 days of evaluations multiplied by disk images per evaluation could add up <andreas-e>While we are chatting, the space on bayfront has dropped from 2.5GB to 1.3GB. I just stopped cuirass. But it may already be too late since there is a partition.img being built. <andreas-e>It would be good if we could drop building the images on bayfront indeed. <andreas-e>How about just dropping the "-type" suffix? Then "(service openssh-service-type)" becomes "(service openssh-service)", which looks entirely reasonable. <andreas-e>Or even "(service openssh)", but I suppose that would clash with packages. <rekado>oh, but we still have old-style values like “openssh-service” <rekado>yes, that would be problematic, but only because there are no types <cbaines>(define openssh-service (service openssh-service-type)) ; the naming here makes sense to me <rekado>I wonder, though, if a macro (like the enum macro) could help <nckx>andreas-e: There are 3 GiB to be gained with a risk-free ‘sudo rm -rf /home/*/.cache/’, if it's really close. <catinabox>hmmm, I haven't used guile much, is there something already called "templates" like there is "types"? what if it was called e.g. openssh-service-template? <rekado>what I mean is a validator like the one define-enumeration defines. <rekado>(define-enumeration field (username password whatever) make-field) <rekado>that allows us to use (field username) but not (field foo); validated at compile time <andreas-e>There is also a failed build in /tmp of 6GB: an iso image, dating from the end of August. <nckx>I mean, terrible that is was suffered to live, but nice. <andreas-e>There is a gc job running for 6 hours now. How do I know if it is still doing anything? <nckx>stracing the daemon says it is. <andreas-e>Mcron launches it at 4 in the morning for -F800GB, and then at 4 in the afternoon for -F400GB. <andreas-e>There are lots of "[0%] deleting '/gnu/store/" printed in strace. <andreas-e>So it looks like it is desperately deleting small packages one by one. <rekado>on berlin we have a setting to delete gc-roots relating to disk images to increase the likelihood of them being collected <nckx>Yes, that's what I got from sudo strace -s1000 -p 29148 2>&1 | grep deleting <nckx>dunno if that's desperate. GC always seems pretty desperate to me. <nckx>But it was never written to do anything else. <andreas-e>Why not, but that is rather something it could do in its spare time, not when we need space. <nckx>Guix (Nix) GC is (was?) just ‘look for dead things, delete them randomly, stop when free space < foo’. <andreas-e>It is nice also to get rid of small files, since their number clogs the file system. <nckx>People tend to assume it's clever. No. <andreas-e>rekado, is it part of the mcron settings? Could we copy it over to bayfront? I remember you once posted a script to invoke manually. <rekado>it’s cleanup-cuirass-roots in (sysadmin services) <rekado>so it seems that it’s already enabled for bayfront <andreas-e>From what I understand, we can just kill "guix gc", and run it by hand? For instance with "-C 0" to really reclaim the space of deleted files, now? <nckx>andreas-e: If you like desperate, how about something like: find /gnu/store -maxdepth 1 -size +1G -exec guix gc --delete {} \; <andreas-e>First question, is it safe to stop. I think it is, but wanted to be sure. <andreas-e>rekado: Thanks. I agree it should be enabled to run through mcron. <rekado>nckx: this may be slow because “guix gc” has some overhead <rekado>and you may very well hit an item that’s not dead yet <nckx>You certainly will, hence \; *rekado read the find man page… <andreas-e>I am trying a "guix gc -C 0", to go through "deleting `/gnu/store/trash'" and "deleting unused links". <nckx>rekado: Invokes ‘foo <file>’ for each file, ignoring failure, instead of ‘foo <files...>’ which would be +. I didn't check but assume that guix would be to eager and stop if one is live. <rekado>yes, it will stop immediately when one of the items passed to “guix gc -D” are live. <nckx>But yeah, spawning guix gc is slow, it's just faster to sit through it waiting to get lucky than actually deleting .drvs to get to that gig. <andreas-e>Is there a command line tool to show disk throughput, like gkrellm? <andreas-e>guix gc: error: statting `/gnu/store/.links/00s2i28m0ygp0kh7mv2y6d4yqvhgldhn6ccjm5kjdna3cv6hn7f2': No such file or directory <nckx>dstat (general totals; -d for disc); iotop. <nckx>Using finde: [0 MiB] deleting '/gnu/store/iz230cby2nhydwhc53c2gql74hqyvrdl-iso9660-image' <nckx>andreas-e: Hm, is that because I'm GC'ing with find? <nckx>Of course now it's stuck ‘deleting unused links’ which is probably still full of tiny files from the previous run. <nckx>andreas-e: I'm running the find command above. <andreas-e>Well then, this is a good check if the semantics of "guix gc" is robust! <nckx>Well, I'm running it in a loop ignoring failures so I don't care. <nckx>Let me know if you want me to stop, but this is actually deleting stuff at an acceptable pace. <andreas-e>I think the real problem is that even "guix gc" does not reach the target of 800GB/400GB. So it runs up to the least .drv file. <andreas-e>I tried it recently, and ended up with only 50GB of free space. <nckx>Well no, since it just deleted its second >1 GiB image. <nckx>OK, I thought you meant it was there now. <civodul>rekado: "service-type" is in fact quite different from a type as in type systems <civodul>should have chosen a different, one-word name <catinabox>what if you `find /gnu/store -maxdepth 1 -size +1G -print0 | xargs -0 guix gc --delete`, that way it deletes them in one "guix gc" run <jlicht>nckx: you seem to have moved on to more fun thing by now, but I recently pushed an "escape hatch" for php.ini to the php-fpm service. It should be on master bba053311. <nckx>catinabox: ‘Needless use of xargs’ (🙂 in the spirit of ‘cat’), but it won't work because ‘guix gc’ eagerly returns an error before deleting things. <catinabox>ahh ouch. so it won't delete the things it actually can? <andreas-e>jlicht: Yes, housekeeping is fun! I am the Marie Kondo type. <catinabox>also, wait, needless use of xargs? can `find` actually do them all in one command execution? <nckx>Yeah, if A is live, ‘guix gc -D A B C’ will always fail, IIRC. <nckx>catinabox: find foo -bar -exec flurp {} + <nckx>Wow. There are a ridiculous number of still-alive top-level >1 GiB files in /gnu/store. This can't be right. <catinabox>nckx: and yep, I just tried `guix gc --delete $(readlink -f ~/.config/guix/current) $(guix build hello)` and it didn't delete $(guix build hello), welp <nckx>jlicht: My saviour! Thanks. <bandali>zimoun, hey! dropping by to say i got your email, and will try to respond over the weekend <jlicht>np, please keep dem substitutes flowing freely ;-) <catinabox>nckx: I've seen mention of "useless use of cat" before, I figured it was related lol <nckx>So I've delete a few 2-GiB files by now with no effect on df /. These monsters were (de)duplicated at some point? No wonder Guix does I/O all day. <nckx>Hard to believe since they should be full of store references, but df doesn't lie oh wait it does all the time but this is ext4 hm who knows. *nckx backflips into another dojo to fight PHP for a while. <andreas-e>nckx, that sounds strange. You are not saying that the same disk images are created several times with a different input hash? <nckx>I find that implausible. But guix gc has deleted ~10G of files now, those files are gone, .trash is empty, and df -h still says only 21G are free. Should be (much) more. <nckx>I might be missing an obvious. <rekado>civodul: it’s the same … discomfort I feel with monads in Guix. Where the context is so unique and clear that it seems wrong not to have some sort of type check. <nckx>I know btrfs does creative (efficient, I'm sure) accounting that makes df ‘stabilise’ for a while but I don't think ext4 has any of that. <nckx>‘finding garbage collector roots...’ → Terminated 😳 <nckx>andreas-e: Are you killing things? <civodul>rekado: for monads i definitely agree; for "service types", it's a bit different though, because what they encode is not really a "type" <civodul>nckx: it the "deleting unused links" space at the end that really frees space <rekado>yes, what I mean is that we know in advance that only certain values (those with the “-service-type” suffix) are permissible for (service …) <nckx>These are complete per-file ‘guix gc’ calls. <andreas-e>removing stale temporary roots file `/var/guix/temproots/7584' <andreas-e>removing stale temporary roots file `/var/guix/temproots/18992' <andreas-e>removing stale temporary roots file `/var/guix/temproots/10078' <andreas-e>note: currently hard linking saves 136528.55 MiB <zimoun>rekado: especially when Store generally refers to a CoMonad :-) <nckx>(andreas-e: Please use a pastebin.) <nckx>I'd been running ‘watch --differences=permanent df -m /’ out of pure desperation and noticed the same. Megabyte per megabyte... <darkpsi>hey guys any one else getting async_test errors when trying to compile python-3.7.4 <darkpsi>just did guix pull and fails the async_tests when building python <darkpsi>yea first one. i am running it in a chroot boot from the installsion iso, since i could not get past initramfs it complained about trying to populate /etc/ from the guix store, so i thought i would try reconfiguring the sytem from a guix pull to see if that would fix the issue. <darkpsi>@nckx got it to work did not bind pts on the chroot sorry. <nckx>Glad you got it to work. 🙂 I'm still waiting on ‘guix pull’ myself. <nckx>‘838 new packages, 1,219 packages upgraded’. <nckx>Let's never be apart again... <nckx>bearclaw: Isn't that a GitHub? We're not exactly, to put it mildly, a GitHub thang. <nckx>And it doesn't accept PRs, sorry. <andreas-e>There is quite some stuff in /var/cache on bayfront. 5GB in subdirectory cuirass, 86GB in guix. <nckx>Correxion: it does, because we can't disable that, right. <darkpsi>doing a guix pull makes me wish i had more then 4 cores :/ <nckx>bearclaw: Would a PR that's not merged through GitHub still count as a Hacktoberfest contribution? *nckx is very happy that guixes pull are substitutable. <bearclaw>I don't think so ... but it's been a while <andreas-e>Yes, substitutable guix pull was a step forward. <andreas-e>So our "guix publish" process has a --ttl of 15 days, which seems quite long. Filling a cahce of 86GB is reasonable, but could become a problem if there are actually people accessing bayfront as a substitute server. Presumably the Guix Data Service does? <nckx>Does it pull actually nars? <nckx>Are narinfos cached by nginx? <andreas-e>About half of the cache is gzip compressed, these should disappear; a quarter is lzip compressed, a quarter not at all. Where do these come from? <andreas-e>I am speaking about the "guix publish" cache; it contains nars and narinfos. <nckx> /var/cache/nginx also contains a ‘nar’ directory that's ~2G. <andreas-e>nginx caches nars as well; is there a point in chaining caches? <andreas-e>Compared to the guix cache, that nginx cache is almost empty. <nckx>andreas-e: Look at the file names of the uncompressed items, specifically the extension. guix publish is reasonably clever & won't compress e.g. compressed tarball. <nckx>I don't really understand the double cache but I'm looking only at the directory layout, not the nginx.conf. <nckx>I'm writing my own nginx.conf; if I dive into another I'll clobber my own caches. <nckx>jlicht: Sorry, now you're my go-to PHPerson: do you know if Guix easily supports different php-fpm worker pools? I'd love to set different limits for, e.g., my webmail and other things. <andreas-e>I see, "find | grep nmap" shows an uncompressed tarball.