<nckx>I got that scary-lookin' thing twice whilst I was somewhere in the process of testing & switching to c-u-f. It hasn't occured since I completed that, and I assumed it was some ABI mismatch $somewhere. <nckx>Are you in such a situation, roptat? <nckx>I can't say what ‘fixed’ it (maybe nothing!) but enough cleaning & re-making & pulling eventually got me out of it. <nckx>Oh, I think I also updated guile-gcrypt for good measure, another untested variable :) <roptat>nckx, yeah I guess I'll try cleaning stuff <roptat>I didn't switch to c-u-f, but I suppose the new environment was created from a commit after the merge, while the previous environment I used was from a commit before the merge <nckx>But it's really just a Guile concept further exposed by Guix. ***ChanServ sets mode: +o nckx
***nckx sets mode: +b $a:raspbeguy*$##fix-your-connection
***ChanServ sets mode: -o nckx
<nckx>No problem, hope it helped. <edgarvincent[m]>It certainly did. It's exactly the flag I was looking for, but I'm new to Guix and Guile. <nckx>Let us know if there's anything missing or unclear in the manual (or linked resources). <edgarvincent[m]>Thank you. So far, the documentation looks very clear to me, but there's a lot to grasp :) <nckx>Yay! Thanks for reporting back. For future reference: do you know which part exactly? <nckx>I wish I'd investigated now, but 🤷 <roptat>nckx, no, I suppose something to do with guile-gcrypt <jackhill>I seem to not understand something about how to use gexps. I'm trying to use one to wrap a program like so https://paste.debian.net/1224360/ but I've done something wrong and get the inscrutable (to me) error: unbound-variable #f "Unbound variable: ~S" (gexp) #f <roptat>jackhill, I'm not sure this is the right place to start a gexp <nckx>Gexp the whole modify-phases expression. <nckx>The unbound-variable error is because you're invoking gexp on the build side. <luis-felipe>nckx, apteryx: Hi, just to confirm that now I can log in to a system configured with the wip branch for a #52051 fix :) <nckx>jackhill: Remove the #:modules, import it at the top level (i.e., the top of the file). <luis-felipe>(Although when I log in, GNOME tells me the system can't recover from some error and I must relog in, but that's probably a different thing) *luis-felipe is upgrading his profile to see if that has something to do with it... <nckx>Is ‘some error’ qualified? <luis-felipe>nckx: I gotta check, it's just an uninformative dialog box. <nckx>I probably won't be able to help either way. <nckx>But that won't stop me from trying. <nckx>I was just about to reset the box I can't SSH into to. Let's see how that goes. <KarlJoad>Quick check, how well does Sway & Wayland work on NVIDIA GPUs in Guix? <luis-felipe>Profile upgraded flawlessly, rebooted, and the GNOME issue is gone. ***lukedashjr is now known as luke-jr
<nckx>Please paste your evil offending code. <nckx>jackhill: You're still evaluating gexp ‘build-side’ because of the '(#:tests? quote. <nckx>#~(list (string-append "CC=" #$(cc-for-target)) accordingly. <nckx>At a glance (didn't test) you should be good to go then… <nckx>Oh, and %output → #$output <nckx>#~(list #:tests? is definitely wrong <nckx>(list #:tests? is correct! But is missing the #~ after #:configure-flags. <nckx>Sorry, my bad, #:make-flags. <nckx>(See snippet above with ‘gcc’ in it.) <jackhill>nckx: thanks for your patient help. I have a building package now. Next is to see if it helped with my theory :) <nckx>I forgot what that was… 😛 <nckx>Happy to help, and I promise this will become as natural (and IMO, *more* natural/fun) as quotes soon. <nckx>Glad to hear that; not a fan of the suggested propagation &c. <nckx>I don't like that webkitgtk upstream is strong-arming distroes into ignoring gstreamer upstream's own assessment of this junk. <jackhill>It is nice taht we have the gst-plugins/selection proc. things like webrtc is in -bad so I see why they want it. I just, yeah, wish the web weren't so terrible and that wich plugins they want were better documented. <nckx>Right, I don't mean leave webkitgtk broken, just give it the minimum it needs. Seems like that's exactly your plan. Great. <jackhill>Speaking of gst-plugins/selection, its docstring says "… Optionally, if CONFIGURE-FLAGS are given …", but it's defined as "lambda* (pkg #:key plugins configure-flags)" so something must be passed as configure-flags. I gave the empty list above, but perhaps that could be improved 🤔 <nckx>Almost certainly a bug/oversight. <nckx>Would it be too much trouble to ask you for a simple patch? <nckx>I am, and especially should be, working. <jackhill>sure, fortunately it's only used by pitivi currently and that passes #:configure-flags <nckx>This is triggering extreme déjà vu, and yet I don't think I dealt with gstreamer lately. Must have been something very similar. Probably not the last such subtle bug with only 1 user waiting to be exposed. <jackhill>I'm still suspicious of the ",@(or configure-flags flags)" in the body of the procedure, but it woks for pitivi and my experiment now, so yay? <jackhill>or rather, I'm suspicious of the ",@(or configure-flags '())" the other one seems ok <rekado>nckx: I restarted mumi when it wouldn’t update any more. <podiki[m]>are there some package I can look at for synopsis/description for autogenerated packages? meaning packages that are just some language's bindings to an ffi or such <podiki[m]>(I have the huge Haskell gobject introspection packages I want to polish to submit patches for, but it is like 1300 lines of packages) <rekado>podiki[m]: most of the R packages are generated, but I still fix up the synopsis and description. <lilyp>some rust GTK bindings are too <podiki[m]>thanks, maybe I'll look at the rust gtk bindings as that sounds similar <podiki[m]>I was also thinking this would make sense for a new module, haskell-gi (the name of the main package that generates all the bindings) ***ChanServ sets mode: +o litharge
***litharge sets mode: +b $a:epony
***epony was kicked by litharge (You are banned from this channel (by nckx))
***litharge sets mode: -o litharge
***ChanServ sets mode: +o nckx
***nckx sets mode: -b $a:raspbeguy*$##fix-your-connection
***nckx sets mode: +b $a:raspbeguy*$#guix-fix-your-connection
***nckx sets mode: -b $a:betelgeus*$##fix-your-connection
***nckx sets mode: +b $a:betelgeus*$#guix-fix-your-connection
***ChanServ sets mode: -o nckx
<lilyp>probably no, unless it gets too unmanageable in whatever module it currently is <podiki[m]>these packages don't exist in guix currently <podiki[m]>was thinking since they all will be upgraded together and are autogenerated packages (library bindings) <lilyp>we still tend to go for larger things like rust-graphics :) <apteryx>python2 packages are expensive to keep working... let's get rid of it soon ***lukedashjr is now known as luke-jr
<jackhill>nckx, apteryx: progress, I've determined that the minium plugin from gst-plugins-bad needed to solve my tab crashing problem is debuguitls. Next: clean up my proof of concept and start a conversation on guix-devel@. For now though, sleep! <nckx>That's some nice work, thanks again. <AIM[m]>How do I get a list of installed packages to stdout? <antlers>And on GuixSD you can see the system package-set too, by pointing it at the system profile: `--profile=/run/current-system/profile` <mekeor[m]>hi guix. how can i tell "guix upgrade" to only upgrade packages with substitutes? <nckx>Not to one-up that, but you can extend that to ‘all users' packages’ by looping over all $HOME/.guix-profile. <nckx>mekeor[m]: There is no built-in way to do so. <nckx>One approach is to, assuming you use a manifest: pull, then wait until guix weather -m FILE returns an acceptable number, then upgrade. <mekeor[m]>nckx: "guix upgrade" fails for me with a memory allocation error (while building rust analyzer). no chance for me to upgrade at the moment? <nckx>Or, if that isn't ugly^Wgranular enough for you, you could consider looping over <nckx>guix package -I | cut -f1-3 | sed -E -e 's/[[:space:]]+/@/' -e 's/[[:space:]]+/:/' <nckx>and doing unspeakable things to the output, like checking the weather and installing it if it contains the string "100%". <nckx>There is probably a better way, I'm just riffing. <nckx>Hi tissevert (and, belatedly, mekeor[m]). <nckx>mekeor[m]: Are you building with --cores=1 already? <antlers>Can you not approach it like forcing offloading with --max-jobs=0? <tissevert>I had to reconfigure my system from root yesterday because I forgot to add the nss-certs in the original configuration <nckx>Talk me through it, antlers. <tissevert>and then guix wouldn't let me reconfigure as my normal user <tissevert>so I had to guix pull and all, I suppose it's messy since guix shouldn't be used from root <tissevert>can I clean up the mess in /root ? like, everything ? or isn't that safe ? <nckx>That sounds familiar, did you mention that previously? Otherwise someone had the same issue or was concerned about it. <tissevert>in any case no it's the first time it happens <nckx>What's the mess? It should be limited to .config/guix, .cache/guix, .guix-profile. Then the dead symlinks in /var/guix/gcroots should be collected by the GC next it runs. <antlers>I'm probably just confused, it's frankly time for bed :p <antlers>Thx for being here and being so helpful for everyone <tissevert>I usually let the installer write my config but since it wasn't working on that particular box I was installing, I wrote the config and forgot it <nckx>I wanted to search the logs, but search is broken. Someone definitely mentioned ‘forgot nss-certs, now guix broke, how fix’. I don't remember the details though. <nckx>They existed before you used guix as root. <tissevert>sounds vaguely familiar, I may have seen it and thought that would never happen to me <nckx>You're free to delete them (it's your system) but they are not ‘mess’ in the sense you used above. <nckx>I'd leave them if unsure. <tissevert>is there a recommended way out of this instead of running as root should the case occur again <tissevert>well I am unsure and they're not eating up a lotta space, so, yeah, I suppose I'll leave them <nckx>They were there from the first boot, if it's any consolation. I have them too; never guixed as root. <nckx>You might want them some day. <tissevert>and I still get weird graphical glitches when switching between Qt windows <eyJhb>Day two of trying to install Guix :p <mekeor[m]>nckx: btw, there's also guix package --list-installed <nckx>mekeor[m]: -I is shorter. <eyJhb>Want to see what it's all about, currently running NixOS. So I guess it's only reasonable to check out the other alternatives :P <nckx>Found the proportional font user 😉 <tissevert>btw any font recommended with a decent UTF-8 coverage ? <nckx>(No judgment, I also use proportional fonts — oh noes the IRC ascii arts — but at least I and l ar different.) <nckx>tissevert: font-google-noto is 1.5 GiB of ridiculous coverage. <nckx>It's a bit outdated but otherwise the most complete we have. <tissevert>it still lacks a glyph for the ball of yarn though 🧶 <nckx>I tried splitting it into :ttf (‘only’ ~350MiB IIRC) and :otf but it doesn't seem to work. <nckx>tissevert: That's what I mean by ‘outdated’. <nckx>The latest ‘Apple M1 user yeeting at COVID’ emojis are not included. <tissevert>I'm pretty sure I got that yarn to display but I can't remember what font was used <nckx>Let me know if you find out. <tissevert>meanwhile, some actual languages used by actual people on earth, and a good proportion of them, still lack glyphs for their languages… : S <mekeor[m]>how can i list all dependencies of a package per cli? <mekeor[m]>tissevert: spoken languages are valid too. are you shaming them? <mekeor[m]>tissevert: ah right, direct deps are listed. thanks. i guess thats enough for me <eyJhb>Finally got it installed. Now I just need to update it :) <tissevert>my install (from yesterday) is still far from being ok <tissevert>I've got this weird "vesa"-ish feel in i3 and Qt windows <tissevert>like the characters are huge even though the font size looks ok <tissevert>and I have this random glitches on the windows when they open before I move the cursor inside them <tissevert>the resolution is better in my tty windows that in qterminal's ^^ <tissevert>would that mean that chromium can somehow ignore X's dpi ?? <nckx>It wouldn't surprise me if they did. <nckx>I'm sure they reimplement a lot of layers on top of X/Waytever themselves. <tissevert>the font inside regular web pages is smaller that the title of my i3 windows (default config: pango monospace size 8) ^^ <ss2>fonts are smaller thanks to xorg'r recent update? My fix: ‘xrander --dpi 96’ <nckx>I thought they were bigger. <ss2>which isn't actually, it just forces a dpi and maybe your usually font size. <tissevert>yeah, I found that 96 was the appropriate parameter <nckx>ss2: ‘Isn't actually’? As in, bug? <tissevert>(also, gdm is entirely unaffected by the issue…) <ss2>I concluded many years that this is no bug, only a way to force a fontsize over a screen you want to have. <ss2>And this upgrade doesn't affect my laptop, which has a small screen, but does on my slightly bigger screen (they have a slightly higher dpi), so the fonts wen't smaller. <tissevert>or if I should have a lxsession task for that or if that would come too late <ss2>went, I've got to fix my grammer somehow.. -.- <ss2>sorry, good morning everyone. <jpoiret>yeah, many programs/toolkits actually ignore X's dpi <ss2>more than you'd think. The DEs themselves know how to override the defaults anyway, and they come with their own concept of doing things. <tissevert>so anyway I simply reused .xsession and everything is fine again <tissevert>strangely (!) that got rid of the weird glitches too ? <tissevert>so I suppose the 142 DPI used by default didn't please my hardware somehow <ss2>fonts, and especially font rendering is an art form that has been around since the dawn of computer systems "trying" to render fonts. <jpoiret>the issue is that in the end, it's up to each client to render the fonts properly, there's no way to enforce some specific font rendering system-wide <jpoiret>unless they all conform to a specification <ss2>that's right. And there is no one specification. <tissevert>wait, people should just make a new specification to unify them and… ^^ <tissevert>and font-openmoji provides it too, it looks a bit better though still black and white <nckx>tissevert: GNU Unifont is great but it's a bitmap font. <nckx>I'd forgot about openmoji. <nckx>tissevert: Are they discernible? <nckx>Legibility was my only issue with it when I tried it, otherwise it's a great project. <nckx>Giving GRUB impressive i18n capabilities for a boot loader etc. <jpoiret>phf-1: if you `echo $GUIX_LOCPATH` in the shell that just printed out the warning, does it echo the right path? <jpoiret>it might be that you put all of that in your .bash_profile (or equivalent) and didn't logout->login again <tissevert>I don't really know, I don't know enough about fonts <phf-1>jpoiret: Thank you for the reply. `$ echo $GUIX_LOCPATH => $HOME/.guix-profile/lib/locale' <phf-1>so it looks good to me: I sourced the env and `systemctl restart guix-daemon.service' <phf-1>maybe that's the problem? it should be in `.bash_profile' ? <jpoiret>GUIX_LOCPATH isn't something that guix-daemon should have to worry about <jpoiret>generally, env vars should be set inside the .profile file, otherwise you run the risk of setting them twice in specific cases <jpoiret>exemple: you login from a vt, it sets them once, then you start whatever compositor you want and start a terminal with a shell in it, setting them a second time <nckx>I'm a bit surprised that (guix)Application Setup doesn't mention that fact. OK, ‘we’ know this, and it's technically not our job (isn't it though?) but it's quite arcane unix lore. <jpoiret>is $HOME actually your /home/<> dir or is it literally $HOME? <nckx>s/job/& to document unix/ <nckx>Here it just feels unhelpful not to say what ‘set’ means in practice. <phf-1>yes for the .bash_profile/.bashrc distinction. This machine is just... very old. <jpoiret>and if you `ls $GUIX_LOCPATH`, it's not an empty directory, right? <jpoiret>tbh i've never had these problems since I run guix system, but these are the easiest troubleshooting steps teehee <jpoiret>nckx: thanks for pushing the local.mk patch by the way <nckx>Uhhh whatever that was, you're welcome. <eyJhb>mothacehe: Graphical installer doesn't work on stable, but it works on the latest you linked, BUT in that one it can't build some drv. So I ended up with using the stable, and instead not using the graphical installer ***nckx is now known as nckxmas
<jpoiret>eyJhb: do you know which derivation it wasn't able to build? <mothacehe>jpoiret: i guess the latest installer points to guix-1.3.0-15.f98edfa that had a test failure <mothacehe>because the installer point to the N-1 guix package <jpoiret>how? In `gnu/installer/final.scm` I only see a `run-command` invocation with a usual `guix system init ...` <mothacehe>yes but that guix is current-guix from (gnu guix package-management) <zamfofex>Hello, Guix! I have recently been reading about Mes and bootstrapping, and it felt really interesting to me! I spent some time thinking, and I came up with an approach for boostrapping Guix using a minimal set of binaries and an existing operating system installation. No code yet, but I wrote my idea in a GitHub Gist and I wanted to be able to know what y’all might think about it, and whether it seems sensible or not. <zamfofex>(Any kinds of thoughts would be really appreciated!) <nckxmas>Thanks zamfofex! #bootstrappable might be interested in this as well (I think… I can't always gauge their reaction to things). <zamfofex>I might try to ask there, but I feel like I’m always frightened of joining new communities! 😬 <janneke>zamfofex: yes, i think what you writes makes (some) sense, it would be nice to create a next step that can do things like that, mainly: run bits of gash and guix on mes <janneke>the former, running gash on mes will be worked on the coming year by samplet and myself (hopefully) <zamfofex>janneke: What parts do you feel like don’t make sense? And could I be able to help with it somehow? <janneke>zamfofex: i do not see things that do not make sense, it's just that i cannot predict how things will go <mothacehe>attila_lendvai: sure, at first glance the gnupg part should probably be extracted in a dedicated commit <janneke>zamfofex: the thing is, in the very next step we will still use guile+gash and guile+guix, but remove the mes binary seed; in the next steps as you lay them out, the mes binary is re-introduced but now as a replacement for guile <janneke>that makes sense, but it's an interesting puzzle <rekado>phf-1: you need to have the locales available in the daemon’s environment and in the current environment. <zamfofex>janneke: I feel like it makes more sense to use Mes rather than Guile because it is a simpler project, and thus its binary is (supposedly) smaller. <phf-1>that looks like a good idea!! <jpoiret>mothacehe: well, i still don't see where the installer gets its N-1 guix from. If you fix this, could you ping me with the commit, so that I can understand it better? <phf-1>A GUIX_LOCPATH is actually defined there. ll $GUIX_LOCPATH gives 2.31 which is different from the 2.33 of the `phf' user. <mothacehe>jpoiret: if you run qemu on the latest installation image, and run "guix build guix" you will see that it tries to build the 15 guix revision. That's because the guix package 16 is a snaphsot of guix that embeds the guix 15 revision. So when running guix init ..., you are using the 16th revision to install the 15th <phf-1>But still, the locals seems to be accessible for the daemon <phf-1>*But still, the locales seem to be accessible to the daemon. <mothacehe>which means that when the guix package is broken it needs to be updated twice, which sucks <jpoiret>oh! i get it. that's a quirk if i've ever seen one :) <mothacehe>hehe yeah quite terrible. The installer tests use current-guix to work around that and install the checkouted guix <attila_lendvai>[git] i can't seem to find the answer anywhere: how can i do the equivalent of this (which doesn't work): git send-email foo@bar.com 4a9e702a86..8f7ffdf36a, or any other way to specify a range of commits that are below the HEAD <nckxmas>attila_lendvai: *If* it's the same as format-patch: -NUMBER NEWEST-COMMIT *attila_lendvai double checks <phf-1>rekado: "$ strace guix" shows that it cannot find locales for 2.33 of glibc: https://paste.debian.net/1224405/ (I've done a `$ sudo guix pull') in the hope to update the root version of guix. Then, locales should be updated to 2.33. <attila_lendvai>nckxmas, scratch that, it works indeed. (i was in the wrong directory) thanks! <rekado>phf-1: have you installed glibc-locales and set GUIX_LOCPATH? <nckxmas>We can't easily investigate what happened on the GNU side. <nckxmas>It's not related to the outage; totally separate infra. <jpoiret>is the very file it's trying to access there? <nckxmas>phf-1: We don't ship the Debian ‘C’ locale. <nckxmas>Try with your locale set to e.g. en_US. <phf-1>jpoiret: no, it's not. I thought it should have been. <phf-1>since locales were installed <phf-1>since it's expected c.f. nckxmas, then changing my locales en_US should to the trick <nckxmas>s/C/C.UTF8/, of course we ‘ship’ the C locale in every programme 😉 <nckxmas>C.UTF-8 is… I'm not sure if it's controversial or just non-standard, but it's not in our glibc. <tissevert>that's it I finally got a satisfying guix install on one of my computers <nckxmas>Great! Note that C is pretty Spartan compared to the (extant) .utf8 locales. <phf-1>What would you recommend instead? <nckxmas>Great! Note that Guix is pretty addictive and a gateway drug to using Guile in front of friends. <the_tubular>nckxmas sorry, reading old logs, what are proportional font ? <the_tubular>I mean can they print character that looks the same in other fonts ? <nckxmas>phf-1: [your_language].utf8, in general, but C is not ‘wrong’ either. <phf-1>Ok thanks, LC_ALL=en_US.utf8 and LANGUAGE=en_US.ut8 should suffice then. <nckxmas>the_tubular: The opposite of monospace. It's not directly related, of course, but *in practice* techy monospace fonts put more emphasis on unique glyph shapes like I and l than many proportional fonts used for prose where it's less important. <civodul>rekado: i've restarted mumi, which was apparently stuck in an infinite loop or something, with things like this in the log: Throw to key `match-error' with args `("match" "no matching pattern" (HEAD "52051"))'. *nckxmas steals that emoji. <nckxmas>civodul: Before I forget: how do you substitute-keyword-arguments a gexpificated package? Couldn't get it to work. <jpoiret>the official name is `en_US.UTF-8` though. using `utf8` can lead to some issues <nckxmas>Please, because that answer confuses me :) <nckxmas>jpoiret: And I thought it was the exact opposite. <jpoiret>i myself search on the internet every single time <civodul>nckxmas: you can look at petsc-{complex,openmpi} for instance <nckxmas>But I'm sure this area is fraught with competing ‘standards’. <nckxmas>I was positutely positive that I tried exactly what petsc-openmpi is doing here. <nckxmas>civodul: FMI, are there any existing packages that *can't* be rewritten as gexps at this time? <nckxmas>Just wondering how ‘complete’ the illusion is. <civodul>plus i mean you can always keep refering to the input alist on the build side <civodul>but rekado found a case in Java packages where we refer to implicit inputs by label (for "jdk") <civodul>that one cannot be translated to (this-package-input "jdk") <civodul>but maybe that's not a problem, dunno <nckxmas>I defaulted to that in a (local) package because I don't think what I wrote could be sanely done without labels, but I'm pretty sure a rewrite will solve that, it's not a fundamental issue. <civodul>but i'm interested in seeing things that are not easily translatable <nckxmas>-builder:1:6417: Unknown # object: "#<" <nckxmas>(That's when the builder contains #<gexp oops nope nono> as I'm sure you know.) <nckxmas>OK! Fixed it, I was fixated on the wrong bit :) *nckxmas feels like there's a story-of-my-life joke waiting to be made, but would rather not, and goes to work. Thanks again! <mroh>is there a way to get --skip-tests to the target host on guix deploy? <civodul>mroh: to skip tests of a package? nope <mroh>sorry, I mean --skip-checks for reconfigure, not --skip-tests <eyJhb>jpoiret: I did not take notice, sorry. I should have. <florhizome[m]>Anybody else been having emacs freezes when running guix.el commands? <mroh>civodul: that would be cool! I'm building a kernel for one machine that need's --skip-checks, but can't deploy it because of this (deploy has no --skip-checks). <civodul>mroh: could you open a bug report so we don't forget? <attila_lendvai>florhizome[m], i've seen freezes recently, but my emacs config is a mess currently. <awb99>I am having troubles in creating a shephed service. <awb99>Essentially I want to run "clj -X:goldly-docs" in a specific directory. <awb99>but herd is stopping it immediately <awb99>unfortunately I cannot find out what goes wrong. <civodul>rekado, nckxmas, mothacehe, cbaines: i'd like to reconfigure berlin and bayfront now that i've managed to bundle guix.gnu.org as a single service type <eyJhb>Is it normal that `guix system reconfigure` takes a _long_ time for just adding ie. ssh networking module? Like, 10 minutes? <civodul>eyJhb: it depends on what you did; if you pulled right before, then it'll not just add your ssh service, but also update the whole system <eyJhb>I did nothing besides adding that service, no pull beforoe. Even though it looks like I did <florhizome[m]><attila_lendvai> "florhizome, i've seen freezes..." <- No it’s only about the guix.el (guix–emacs) related commands... <florhizome[m]>Like guix–packages–by–name. It freezes for a few min, then reports it couldn’t get a connection. <bricewge>On a foreign distro, what package (in addition to adwaita-icon-theme) do I need to have a nice cursor on GUI application? <cbaines>civodul, cool, how are you getting on? I'd also like to reconfigure bayfront at some point to deploy the guix-build-coordinator update I just pushed. <awb99>eyhb: I had the same problem. For me with the guix versions in the last 3 days this delays were dramatically reduced. core-update-frozen merge has fixed a lot of problems. <fiesh>is there no way of defining elogind-configuration without ditching %desktop-services and listing them all manually? <eyJhb>It took 35 minutes to get the ssh-daemon added as a service. It must have done something else as well <bricewge>fiesh: Have you tried to use the modify-services procedure? <florhizome[m]><bricewge> "On a foreign distro, what..." <- I think i saw a gist sometime about adjusting guix to foreign distros. <florhizome[m]>but i remember i had that Problem, too including the gsettings of my packages not showing up <efraim>the go test failures on aarch64 are a solved issue, but for some reason GOARCH isn't picked up in the build environment :/ <fiesh>bricewge: no, that was precisely what I was looking for, thank you! <f1refly>I'm trying follow the guix manual for declaring my own package as a modification of another one with import, this is what I did so far: http://ix.io/3J84 <f1refly>But when I run guix-pull and include my own repo in the channels.scm it tells me "(value "no code for module ~S") (value ((picom))) (value #f)" <f1refly>does this mean it can't find the original picom? <jpoiret>aren't you missing a `define-module` for your code? <jpoiret>also, you shouldn't use git-fetch with github-generated zip files, either you point to the git repo and change the commit hash, or use url-fetch <f1refly>i was trying around a bit, i think i just forgot to change it back <f1refly>so i'd define-module and in that define i'd #:use-module the stuff i currently have in my use-module? <jpoiret>yes. Also, you'd need the module name to actually follow the file tree <jpoiret>if you're just modifying one package because you need a different version, i'd suggest using a manifest instead <jpoiret>so that you don't need to create a whole new channel <f1refly>I was planning to use the channel anyways for some personal tools I use, but I wanted to try something "easier" before packaging my own stuff <f1refly>so if my picom.scm is in $repo/modules/picom.scm (define-module (modules picom)) would be right? <jpoiret>i'd suggest namespacing your modules too, ie having "$repo/modules/f1refly/picom.scm" and (f1refly picom) (or whatever you might want to call it), since channel modules are actually merged with the guix tree <jpoiret>i see you're trying to use the latest available picom commit, for that use case i'd really suggest using `guix install --with-latest=picom picom` or equivalent <jpoiret>actually, --with-latest won't work since there's no new tag, sorry. `--with-commit=picom=<commit-sha>` will though <f1refly>okay, I'll do it like that. And I'll put the next package definitio in a proper namespace <f1refly>the package built went well but unfortunatly xorg still lags like crazy with the newest version :) <jpoiret>heh. One more reason to switch to Wayland <f1refly>herbstluftwm has yet to be rewritten to be workable with wayland I'm afraid <civodul>cbaines: you can go ahead then (i haven't reconfigured yet) <civodul>note that we'll need to copy certs from berlin or nginx will fail to start <cbaines>ok, I've already gone ahead and reconfigured, but I only restarted the guix-build-coordinator service <civodul>should we copy LE certs over rsync (on the VPN), until there's a "proper" solution? <civodul>alright, i restarted nginx on both machines, and everything seems to be fine <yewscion>Hello all, could someone point me somewhere that (wrap-program) might be documented? I'm attempting to modify a package definition to ensure a python library can find $GUIX_PYTHONPATH, but unfortunately I am unfamiliar with how that works. I'm combing through the sources now to find a good example, but I was hoping asking here might point me in a <roptat>yewscion, I'm afraid it's not documented <yewscion>roptat: Copy that (something I could help with eventually, once I really understand it? I enjoy documenting software). <yewscion>Is the best way to find the source for a built-in like that just grepping under /guix/guix in the repo? Or is there another way that might be more efficient? <roptat>sure! I see only one mention in the manual, in an example on section 8.6.4 <roptat>I think section 8.6 only has very basic documentation, it could be improved by a lot <yewscion>Copy that, is the process for patching the docs the same as for patching the package defs? Edit the source, open an issue, send a patch? <attila_lendvai>yewscion, if you use emacs, and set up geiser, and load the code into the inferior guile, then M-. and M-, should work, too <roptat>yewscion, yes, the file to modify is doc/guix.texi <yewscion>attila_lendvai: Oh! I hadn't thought to do that. That would help me a lot, actually. Thanks for the suggestion! <yewscion>roptat: Thanks! Sorry for asking so many questions; Just wanna make sure I do things in the right way. <mekeor[m]>hello guix. did anyone succeed in installing guix-system on pine64's single-board-computer quartz64? <mekeor[m]>phodina: do you have experience with guix on quartz64? <attila_lendvai>can i configure the niceness (priority) of the guix builder service? i can't seem to find anything. <attila_lendvai>i have just found max-1min-load-average, but what i want is process priority, not load-average *attila_lendvai is patching shepherd's exec-command, even though he has no clue how to actually test it <civodul>attila_lendvai: that looks like the right approach; you could test it with a service that spawns "sleep", say <attila_lendvai>civodul, but i have no clue how to start my own standalone shepherd, and then how to configure that with a custom service. *attila_lendvai is staring at the shepherd docs <attila_lendvai>i wish the shepherd docs had a chapter about running/testing shepherd. i'll record this patch into a branch and continue hacking on other stuff. <jlicht>attila_lendvai: I might be mistaken, but shouldn't `make check' run tests? <jlicht>which you might find in the tests directory <roptat>some ocaml packages have not been switched to the new style yet, probably because the labels are not exactly the same as the package name. I'd like to change that. Should I make it one commit per package, or a single commit? there's no functional change, except for ocaml-4.07, and the changes unfortunately affect the derivation <attila_lendvai>these shepherd tests print all kinds of stuff, including error messages. no clue what is expected. <civodul>roptat: if there's no functional change, and once you've made sure nothing breaks, i think it's fine to make a single commit <roptat>ok, I think I'll make ocaml-4.07 a separate commit, just because I changed a (assoc-ref inputs ...) with (search-input-file ...) <roptat>the rest is just changing the style of inputs <roptat>is there a way to change the input style when the input is an origin record that I use in a phase? <attila_lendvai>daaaaamn! the shepherd tests are running shepherd from the PATH, not the actual checked out codebase... the last thing i would have expected <jlicht>attila_lendvai: how are you running the tests? If you get this behaviour /w `make check`, that seems like a mistake <attila_lendvai>jlicht, i was just running them. i'm installing the autotools now. only now have realized that there's only a Makefile.am. i'm not very familiar with the auto* stuff (nor fond of them). <yewscion>Quick Question: If a file with a package definition is pulling in python.scm, which exports (customize-site guix-pythonpath-search-path), how can I use that export in the aforementioned package definition? I want to avoid propagating python unnecessarily, but I need $GUIX_PYTHONPATH to be set to include the local libraries. *attila_lendvai is waiting for local rebuilds now <unmatched-paren>error: failed to select a version for the requirement `trybuild = "^1.0.49"` <unmatched-paren>required by package `anyhow v1.0.46 (/tmp/guix-build-rust-anyhow-1.0.46.drv-0/anyhow-1.0.46)` <unmatched-paren>which is bizarre, since i do not define rust-anyhow; it's a package in `guix`, not `paren` <unmatched-paren>i'll fix that with a local package, then maybe submit it to guix proper <unmatched-paren>how can i do a ./pre-inst-env sort of thing in my channel's working environment? is it even possible without cloning the guix makefile? <robin>hm, 'guix upgrade texlive' dies with an 'integer expected from stream' error from the daemon. this should be fun to debug (initially i thought it was some more general problem communicating with the substitute servers) <vivien>My keyboard layout is supported by GNOME but not the TTYs (I get to use qwerty). Which package is responsible for that failure? I’d like to try and patch it. <robin>vivien, or possibly a bug in (@ (gnu system keyboard) keyboard-layout->console-keymap) or related functions <unmatched-paren>Rust is an example; anything that depends on Rust will not work; mrustc, which is the bootstrap, has inline asm that currently only works on x86 <jacereda>what about static linking? is there a variant for that? <taterbase>I don't have a libre arm laptop but I was hoping to try running it on qemu on my m1 macbook <jpoiret>what's the difference between gpl3 and gpl3+? can't seem to find anything about gpl3+ <taterbase>gpl+ just means if a gpl4 comes out it will use that license <jpoiret>oh, right. How do people usually write this down in eg LICENSE? <vivien>robin, kbd supports my keymap, but the name is unexpected, how can I specify the console keymap name in the config file (overriding keyboard-layout->console-keymap)? <unmatched-paren>jpoiret: generally, each file has a `Under license foo` header that points to the LICENSE file for the contents of a license <unmatched-paren>I'm fairly sure that the LICENSE file on its own does not mean that the code is under the license in it, technically <jpoiret>yeah, that's what I can gather as well. Welp, seems that what I'm packaging doesn't have anything other than the LICENSE file :/ <unmatched-paren>So you'd say `this code is under gpl3-or-later, see the /LICENSE file for details of this license` <unmatched-paren>even if it isn't technically legally under the license, basically everyone treats it like that <robin>vivien, ah, i guessed wrong about kbd; guix appears to *always* use ckbcomp from console-setup to generate a console keymap based on xkb keymaps, even for basic layouts like 'us' and 'dvorak' <unmatched-paren>Often the project puts the license note in their readme, which is probably more than adequate <robin>vivien, so maybe it's a bug in ckbcomp, or the way guix invokes it <lfam>It's completely typical for free software projects to omit license headers <vivien>In fact, I don’t think the exact variant I want is supported, but I would rather use a closer variant than qwerty <lfam>You don't have to worry about it <unmatched-paren>yeah, it's pretty hard to tell what _technically_ applies and what _technically_ doesn't <lfam>However, if there's no actual use of the "or later" clause, then we do not interpret the license as being "N or later" <lfam>Technically, you will only find out for sure after a lawsuit over the subject is completed <vivien>If guix were using goops, I could overload keyboard-layout->console-keymap and there wouldn’t be any problen <unmatched-paren>Probably the best way to do license headers now is an SPDX identifier, I guess, since it gets your point across unambiguously without a large annoying comment block <lfam>None of this is settled law, at least in the US <lfam>Just do your best to interpret what the authors intend, and if you are unsure, then ask them <unmatched-paren>I've seen some projects do `(your language's comment symbol) SPDX-License-Identifier: (license identifier)` <lfam>Remember, the law is not the same as software / code. It doesn't happen automatically, nor are there "bugs" in the law <lfam>It's interpreted by humans in a human way <lfam>So, if a program includes a license file, and no other information, it's reasonable to assume that the software is given to you under that license <lfam>And like I said, if you are still unsure, then ask the authors <civodul>if not, i could merge it before going +/- "on vacation" <mothacehe> hey! the micro architectures are still duplicated in (guix cpu) and (gnu ci) right? Fine with me if we fix it later on <civodul>mothacehe: ah yes, it's duplicated, but that's because i chose an arbitrary subset in (gnu ci) <civodul>on the grounds that it we don't want to build for every CPU <jpoiret>lfam: about the xorg-server patch, I don't use Xorg at all, sorry <attila_lendvai>is gettext an assumed dependency everywhere, or the shepherd package is missing it in native-inputs? <attila_lendvai>i can't compile shepherd. i'd appreciate if someone could update the README. it requires at least `guix shell gettext guile -D shepherd` and `autoreconf --install`, or somesuch. i'm clueless about these tools. <robin>attila_lendvai, for gnu-build-system at least, iirc the implicit inputs are the %final-inputs in (gnu packages commencement), and don't include gettext (or autoconf, automake, ...) <attila_lendvai>robin, based on my experience in a shell, i'm not sure how/why the guix package compiles. <robin>attila_lendvai, well, the package is building the contents of a tarball, presumably prepared with 'make dist' or similar so it doesn't depend on autotools and such <lfam>Or, should I write the commit message myself and go ahead and push <unmatched-paren>uh, what does Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <lfam>Does `guix describe` report the thing you expect? <unmatched-paren>lilyp: the `guix` process uses 3.0GB of memory... I'll try guix describe <lfam>Anyways, it means you ran out of memory <lfam>Typically, it is because either 1) You don't have enough memory or 2) There's a bug in the code causing an import cycle <lfam>Yes, if you are using 3rd party code, I would look there first <lfam>It does happen in Guix sometimes, but it's more likely to happen when mixing in 3rd party channels <unmatched-paren>is there a better workflow for channel work? something like `guix`'s ./pre-inst-env thing? <awb99>does anyone know in which package I can find "netstat" ? <lfam>Are these packages that exist in GNU Guix? <lfam>I was asking because if they were, the workflow would be simpler <unmatched-paren>I name my files after ones already in guix; i think where they would go if they were submitted into the main channel <unmatched-paren>Yep, looks to be... guix package -f on a file with a recently added package does the same memory creep thing <fnurkla>awb99: netstat is a part of net-tools ***lukedashjr is now known as luke-jr
<lfam>Thanks avp. Because Guix itself depends on guile-ssh, I'm wondering if you did any testing of the guile-ssh update? <avp>No, I haven't tested Guix with the new Guile-SSH version. <lfam>Okay, thanks for letting us know avp. Can you mention it in the thread on the patch tracker? <lfam>That info will help with review <unmatched-paren>the reason i'm having to deal with this in the first place is because an untested patch was merged in to guix itself <avp>As I mentioned in the new release announcement I'd appretiate if anyone could test it properly. <avp>s/appretiate/appreciate/ <unmatched-paren>rust-addr2line depends on rust-backtrace, but rust-backtrace depends on rust-addr2line! <awb99>how can I add a configuration file to /etc? I managed to get files to /etc/static, but I have some apps that require config file to be in /etc directly. <KarlJoad>Does the linux-libre kernel that Guis ships with have support for the ipmi kernel modules? I see documentation on kernel.org/doc, but want to be sure. <unmatched-paren>i would be surprised if there wasn't some way to add those from your config.scm <avp>lfam: Sure, I just sent an update email to the bugtracker with this information. Thanks for the hint! <unmatched-paren>...ah. it's because i thought you were now able to lump together #:cargo-inputs and #:cargo-development-inputs in the inputs field. <KarlJoad>awb99: It should be possible. There is probably a setting somewhere in the manual that details how to do it. <opalvaults[m]>Getting this error when trying to quickload a handful of packages in sly <opalvaults[m]>any package that provides those? or do I need to point sbcl somewhere in particular? <jlicht>does guix's emacs-eldev work for anyone? It can't seem to find eldev.el when invoking 'eldev' <lfam>opalvaults[m]: libcrypto is provided by OpenSSL <opalvaults[m]>lfam: it appears that sly/sbcl doesn't know about it through installation of the package alone. i have openssl installed <lfam>I suppose you'll have to figure out how to tell sly where to look <lfam>Probably somebody else can give more specific advice ***lukedashjr is now known as luke-jr
<opalvaults[m]>lfam: guix has a package called cl-cl+ssl that providesthe correct directory/points sly to the correct location of libcrypto.so <the_tubular>I don't want to start an holy war, but is there somewhere I can read on the differences on the lisp family language ? <unmatched-paren>in scheme, functions are just variables assigned to lambdas, but in common lisp, they're their own thing <jackhill>of course kawa scheme runs on the JVM too, and clojure has other interesting/unique design choices, but yeah, manybe a better question for #lisp :) <unmatched-paren>emacs lisp... idk, i've never really used emacs; after a few minutes of using it i went back to vim <unmatched-paren>there's quite a lot of lisps, its simplicity means it's generally comparatively easy to implement <unmatched-paren>actually, many languages compile themselves to a lisp-like ir for easier analysis, iirc <the_tubular>Yeah, I'm still trying to learn emacs unmatched-paren <the_tubular>Also I think you can't configure emacs with guix-home yet, I guess when that happens, that would make porting my emacs config way easier <unmatched-paren>yeah, i don't like the way that you need to press control for everything <AIM[m]>unmatched-paren: You do know they're different suites of software, right? <AIM[m]>emacs has an editor inside it but that doesn't mean it's an editor <opalvaults[m]>the_tubular: Common Lisp: standardized lisp, lots of enterprise libs. <opalvaults[m]>Scheme: Before Common Lisp -- minimalist and encourages building abstractions by hand instead of relying on libraries <opalvaults[m]>Clojure: Runs on Java's virtual machine, and thus can interop with Java libraries -- it's purely functional (afair) <opalvaults[m]>Racket: An offspring of scheme, born ~2010. could arguably be called the Python of Schemes. Lots of metaprogramming functionality and learning materials. <AIM[m]>Org mode and magit are some of the reasons people use emacs <opalvaults[m]>Emacs Lisp: An offshoot of common lisp made for extending emacs <unmatched-paren>AIM[m]: there are several org mode plugins for nvim, and one (neorg) that betters it (imo) <AIM[m]>Emacs has a Gui editor, like it's no terminal interface <opalvaults[m]>emacs can literally do everything vim can do and like 9000x more with little effort. <unmatched-paren>i still feel like BOTH emacs and vim are handicapped by their text-based-ness <AIM[m]> Let's take it to the streets, then! <AIM[m]>You can't install normal tar files right? <AIM[m]>Can I do some guix environment and package it and send it to /gnu/store ? <AIM[m]>Like how do I compile and install normal programs? <AIM[m]>They don't store in /gnu/store, no? <the_tubular>I'm not sure I understand your question, isn't that how guix works fundamentally? <zamfofex>Hello, Guix! Quick question: Would it be sensible to use the bit‐by‐bit identity of built packages on the store to determine compatibility? So imagine a package at ‘/gnu/store/aaa-hello-2.10’ has a dependency on GCC 10, and its definition is then updated to depend on GCC 11. <zamfofex>But if the new ‘/gnu/store/bbb-hello-2.10’ is bit‐by‐bit equal to the previous ‘aaa-’ one, then dependencies of the new ‘hello’ package would’t be rebuilt, and instead simply copied over from the previous store path (if they are already available in the store). <zamfofex>I feel like this would alleviate the need to keep package definitions intact (specially those with a lot of dependents), as long as dependent don’t change because of that. <zamfofex>the_tubular: I think AIM[m] wants to e.g. ‘git clone’ a repository and ‘sudo make install’ it like they would in other systems, without needing to package it. <AIM[m]>I wanna implement something like that <zamfofex>Normally in those cases (which I try to limit), I just run plain ‘make’ and add a Bash alias to the exectuable in my home directory. <civodul>zamfofex: yes i think so, that's something we should be able to implement <zamfofex>civodul: Has that been considered before? ***lukedashjr is now known as luke-jr
<lfam>zamfofex: Yes, it's been considered, if I understand your suggestion correctly <lfam>It sounds like the difference between an "extensional" (what we use) and "intensional" model, as describe in Eelco Dolstra's thesis where Nix was first presented <fiesh>is there any way to execute shell code during the boot process to fix permissions / values that I can't seem to address otherwise? (sysfs) <lfam>fiesh: Are you trying to set some sysfs values at boot? <fiesh>lfam: write them, and change some permissions in /sys/..., yes <KarlJoad>Sorry, I may have missed the answer, but does Guix's linux-libre kernel support Linux's IPMI modules? <lfam>KarlJoad, it's also worth asking in the gnu-linux-libre channel <fiesh>lfam: looking into it, thank you <lfam>Maybe somebody else has a specific answer for you KarlJoad <lfam>Personally I don't know where that support comes from so I can't look it up <fiesh>lfam: but this is purely sysctl, not sysfs, or am I mistaken? <zamfofex>lfam: That’s pretty much exactly what I suggested. I think an elegant solution would have been to consider the hashes of the built outputs of a dependency (rather than the dependency definition itself), but I feel like that would be a far more drastic change. <lfam>zamfofex: So, Nix actually implemented this recently. I guess it's a hybrid of the two paradigms now? I don't really know the details <lfam>If you search our mailing list archives for the terminology, I think there is some recent-ish discussion <zamfofex>Also, another (perhaps more computationally difficult) thing that would also be really neat would be to infer grafts instead of explicitly defining them. So that if the output of a package only change by dependency path (in the same position within the binaries/outputs), a graft can be applied automatically. Though in that case, I suppose it would be useful to allow for the build farm to communicate that with clients somehow. <lfam>zamfofex: Something to consider is that, at the time the thesis was published (2006), an intensional model was not useful at all. It was unreasonable to count on bit-identical outputs of builds, even when nothing had changed at all <lfam>So, it's only through the efforts of Nix, Guix, and the reproducible builds movement that the intensional model is a viable option <lfam>I'm not sure I understand your suggestion about grafts *fiesh just realized there's no podman, only docker, in guix :( <fiesh>jackhill: oh that's awesome, thanks, I'll look into it <fiesh>(podman is so much better than docker, it should be called the-dockest) <fiesh>well that leaves me with my seemingly unsurmountable sysfs problem... I can't believe I'm the only one facing it <zamfofex>lfam: I mean if two outputs only differ by the store path of a dependency in their binaries, then the dependency could be considered interchangeable, and thus the build farm could let clients know that a graft can be made. <zamfofex>When I say “the dependency could be considered interchangeable”, I mean the two paths of the dependency. <jackhill>fiesh: what's your systfs problem (sorry, I wasn't paying attention earlier)? <lfam>fiesh: It's definitely not insurmountable. But nobody has a "ready to use" example for you. Once can define custom services that can do anything you like <lfam>I mean, "One can define ..." <zamfofex>I feel like that would make more sense than requiring package mantainers to specify grafts explicitly. <fiesh>jackhill: changing permissions / values in /sys during / after boot <lfam>With the current model, it makes sense to specify grafts explicitly, because they are a kludge and can mask serious bugs <lfam>A vital kludge, but a kludge <fiesh>lfam: ok, I suppose that surpasses my current understanding of Guix, I'll have to get myself somewhat more educated in it first <lfam>fiesh: Stick around, somebody will probably be able to help you with it <lfam>It's definitely unusual to change permissions of sysfs, but changing values is normal <jackhill>fiesh: oh yeah, I would use that to, I've just been lazy about looking into it :) For a minute you had me worried that there was something broken. It's sad to be missing a feature but less worrysome <lfam>In general, you'll get the best advice if you say exactly what you are trying to do, rather than beating around the bush <fiesh>lfam: idk, that was the only non-awful solution I found to adjusting my laptop's backlight -- by using xbindkeys and having a script that alters /sys/class/backlight/intel_backlight/brightness <fiesh>and for that to work, chgrp'ing to video and setting g+w was a reasonable approach <lfam>Are you using Xorg, or Wayland? Or the console? <lfam>Did you look into the xbacklight package? <fiesh>lfam: yeah it somehow didn't work for me at all -- which may be my fault, but it seemed it shouldn't be too hard to use <lfam>There is also brightnessctl <lfam>Apparently it includes some udev rules that set up permissions correctly <lfam>So, you might have to set up some udev service thing <lfam>I'm *sure* that somebody else has a controllable backlight on Guix System <lfam>And they will eventually offer to help <fiesh>well there are other values in /sys that I'd like to alter as well (no permission change necessary though) <fiesh>I gave brightnessctl a try as well <lfam>It makes me wonder what my computers do. The brightness keys "just work" on them <fiesh>was alas not the case for me <lfam>A benefit of using Thinkpads with linux, I suppose <fiesh>I ditched mine for the librem 14 <fiesh>in every way a good decision, except for the brightness keys ;) <fiesh>I didn't take a look at how the PureOS that shipped with it handled the brightness... that might be a good resource, but either way I'll be stuck with trying to alter values in sysfs <samplet>lfam: That timeout patch is okay by me. Like you said, it fixes a rather serious issue for some people, and I think Maxime is right about the security considerations. <samplet>I’m pretty sure it is only masking a symptom of some other issue, though. <lfam>samplet: I admit I didn't follow the issue closely. Are the commit message and code comment that I wrote accurate? <lfam>Maybe samplet, maybe not. I've experienced similar "new timeouts" after big upgrades, and my hunch is that the storage layout changed in a way that seeking took much longer. <lfam>But, whether it's a real fix or not, it's a fix <lfam>As for security considerations, are you referring to Maxime's point about a local DOS, and the difficulty of protecting against it <samplet>lfam: I would only change “60 second timeout” -> “60 second authentication timeout”, just to be a little clearer. <lfam>fiesh: You might also ask upstream in xbacklight or brightnessctl <samplet>lfam: Yeah. Upstream lowered the timeout from 30s to 5s in response to a DoS CVE. They increased back to 30s because it was breaking logins. <fiesh>lfam: you got me thinking... how's that work, installing brightnessctl as a user cannot possibly allow a permission change via udev? do I have to install via my config.scm for it to work? <lfam>fiesh: You would install brightnessctl however you like, and use the example udev rules it includes in your config.scm. The latter part requires privileges <lfam>samplet: Right. I guess that nobody in their right mind would still be using a Thinkpad X200 with an HDD <lfam>Especially not developers <fiesh>oh and these udev rules are basically exactly what I need to do, so I suppose udev makes it possible to change permissions :) <lfam>I wonder if the X200 has exceptionally low I/O bandwidth, or if it's the only 13 year old laptop Guix users are using with HDDs <samplet>lfam: I tested two other older laptops with the same HDD, and they all had the same problem. <lfam>I'm curious samplet, also Core2Duo CPUs? <samplet>civodul: Yeah, but I forgot to update ‘(guix self)’, so it’s not working! :( <samplet>Also, I think there’s another regression with Disarchive fallback (from before my commit). I’m looking into it now. <lfam>samplet: I didn't realize that you have commit access. Can you please push the #52051 patch? <civodul>samplet: not working because you need to add guile-lzma in (guix self)? <samplet>civodul: Yes, plus whatever else is wrong. (I think it’s a SWH download issue.) <samplet>lfam: Possibly. One definitely. I don’t remember the other. <KE0VVT>fiesh: lfam: Still gawking at the ancient X200 and its ancient disks. <ns12>I noticed that some packages have a "release-monitoring-url" property in the package's "properties" field. What is release-monitoring-url used for? <fiesh>KE0VVT: I tried installing a new display into my X220 and screwed up the soldering, hardware just isn't for me, so I threw it away and got a new laptop ;) <civodul>ns12: hi! this is used by the 'generic-html' updater, for "guix refresh" <PotentialUser-34>Has anyone ever encountered qtile not creating a .desktop file for the display manager? For context, all I did is put (specifiation->package "qtile") in my config.scm, and I did the same with a couple of other wms and had no problems with them <KarlJoad>lfam: Just checked with the linux-libre log, no IPMI modules are removed. Good to know. Maybe my computer will shut off this time. <ns12>civodul: Thanks. When is that property needed? I noticed that only some packages have/need it. <civodul>ns12: it's needed for packages that (1) rely on generic-html to determine their latest version, and (2) where the default choice of URL is incorrect