IRC channel logs
2025-07-19.log
back to list of logs
<bdju>Anyone else noticing the insanely high # of build failures recently?! <Kolev>I installed emacs-auto-dark but I cannot require it in Emacs. <human_equivalent>Hello. I have what I think is a simple question. I'm configuring nginx in operating-system but I'm having issues knowing how to properly get the path for fastcgi_param for the config location body. For example (nginx-location-configuration (uri "/") (body '("conffoo;" "confbar;"))) works, but I want something closer to (nginx-location-configuration (uri "/") (body '("conffoo;" (file-append nginx <human_equivalent>"foo/fastcgi_param") "confbar;"))). Versions of what I've tried taught me that '() means it won't be evaluated there and... yeah I've tried a bunch of stuff but I'm stuck. When I get past this I'm almost done with a writeup of how to get Nextcloud up and running using Guix. Going to bed now, I'll check in in the morning! <Kolev>I got auto-dark to work now. <nomike>The commit is moving some stuff from (guix build guile-build-system) to (guix build-system guile). And since (package libfive) imports the build phase of the former, it doesn't like that stuff to be moved around. <nomike>This breaks libfive and this it's dependent inspekt3d and my package pythonscad which I haven't submitted yet. <nomike>The error message produced by `guix build libfive` is "In procedure make-regexp: Wrong type argument in position 1 (expecting string): #f ". <nomike>I'm having a look at the issue right now, but I'm not very experienced with neither guix nor guile and was hoping that someone could help me have a look. <podiki>can you share a more full log? what phase is it failing in <robin>human_equivalent, in that situation you can use quasiquotation, to unquote elements of the list: `("conffoo;" ,(file-append nginx ...) "confbar;"), where the comma instructs scheme to evaluate that expression <robin>human_equivalent, but with functions like file-append, returning file-like objects, you should quote it as a G-expression (#~ to quote, #$ to unquote): #~(list "conffoo;" $#(file-append ...) "confbar;") <robin>(in guix repl you can evaluate (use-modules (guix gexp) (gnu packages web)) then (file-append (@ (gnu packages web) nginx) "/bin/nginx") to see that it doesn't return a file name directly) <Kolev>Is it possible to have all my user scripts in one repo, and have them packaged with Guix? Like scripts/src/hello.scm and scripts/src/ahoy.sh? <meaty>Kolev: if you are still there, have you taken a look at home-file-service-type? <Kolev>meaty, my problem is shebangs. Guix shebangs are ugly as sin. Packaging the scripts will get rid of the shebangs. <Kolev>And Guix shebangs only work on Guix. They don't work on other systems. <hiecaq>Has any one noticed Emacs being extremely slow recently when moving the cursor? I did a profiling and it shows 60% automatic GC and 25% redisplay_internal ... which seems not right. I've never set gc-cons-threshold/gc-cons-percentage manually, and they are 800000/0.1 right now. <hiecaq>I think it starts to happen after I updated my Guix recently. But anyway, setting gc-cons-threshold/gc-cons-percentage to big numbers fixes it for me right now. <human_equivalent>robin: Thank you! I'll give it a try later today. I had a feeling I needed to do something like that but couldn't figure it out. <andreas-e>This looks like a consequence of the core-packages-team merge; apparently a missing include file. What is libmcrypt used for? <gabber>how many dependent packages are still ok for a package upgrade patch to be merged onto master directly? <gabber>is 786 dependent packages being rebuilt a lot? <andreas-e>Kabouik: It should be possible to repair this, but at the same time, a crypto library that has not been updated since 2007 is rather suspicious. So my stance would rather be to remove it instead of repairing it. <andreas-e>786 is a lot. QA has a limit at 600, I think; otherwise it does not check it. <andreas-e>The documentation speaks of 400, if I remember well. <gabber>andreas-e: could you mind creating an `audio' branch on codeberg so i can tell people to start opening PRs against that one? <Kabouik>andreas-e: thanks. I don't remember exactly what I'm using libmcrypt for, but surely it's a dependency to something I need and did not develop myself. <Kabouik>I'm assuming it might be used by password-store or pass-tomb, in which case there are many users. Will check if I can find confirmation. <gabber>a patch should be relatively easy: just add the relevant header to the file in question, like d8900954cf86f94a1e5452acc3a8c4e0a7eb246b <gabber>does QA start building for that branch automatically or is it necessary to trigger that process somewhere? <andreas-e>It needs to be added to CI. But it would also be helpful if some member of the audio team could commit to the branch :) <luca>Hi, anyone got any tips on autoconf/automake trying to mkdir localstatedir? (which should be /var but on guix packages can't do anything outside of the store at build time) <Kabouik>Thanks gabber. I have tried doing it myself but all my attempts have failed, I probably am not understanding correctly. <gabber>Kabouik: the error stems from a gcc upgrade in guix. the new version does not automatically include some C standard headers. just follow GCC's error output (the one you posted above) and solve the problems pragmatically, adding the needed headers to each file necessary. <andreas-e>Kabouik: I am working on the package; gabber: The solution is much easier :) <janneke>andreas-e: congrats on your final rebase and push of core-packages-team, and lotsa thanks for it and for all the earlier ones \o/ <andreas-e>janneke: Thanks! And same to you, thanks for all your initial work! <andreas-e>Now we see the bug reports and pull requests flowing in for all the broken packages :) <andreas-e>Kabouik: I just pushed fixed for the mcrypt and libmcrypt packages, you can do a "guix pull". <gabber>andreas-e: easier, yes. but is suppressing compiler error messages ... better? especially with respect to future package updates? <andreas-e>gabber: The easier part is to define STDC_HEADERS, since there already are lines including the standard headers, just masked by a check for this preprocessor constant. Suppressing the warnings is needed on top. <andreas-e>Future package updates will not happen, these date from 2007 and 2008. This is why I thought it would be better to remove them altogether, but apparently some useful package(s) depend on them. <andreas-e>tcctest.c:2033:12: error: type defaults to ‘int’ in type name [-Wimplicit-int] <andreas-e>Should this not prevent bootstrapping? But then, how did we go that far? <identity>inferno also broke it seems, “create.c:26:20: error: implicit declaration of function ‘mkdir’” <janneke>andreas-e: tcc? haha, that's interesting/funny. I'll have a look. <andreas-e>Ah, maybe it works in bootstrapping since there it is not compiled with gcc@14. <janneke>in bootstrapping, we build tcc-boot, and it takes a whole lot of time until we reach gcc-14 ;) <andreas-e>gabber: When updating packages that disable turning warnings into errors, we should always try to drop these CFLAGS first. One can hope that people improve their C code in a new release. <janneke>andreas-e: there's no bug open for that right? I'll push a fix <andreas-e>I do not think so. I just noticed it when trying to update my professional profile. <andreas-e>janneke: The fix is interesting! Previously we had always rewritten all the C flags by setting the CFLAGS environment variable. Here you use --extra-cflags as a configure flag. Is this a general feature of autoconf, or a speciality of tcc? <janneke>andreas-e: tcc uses a home-grown configure script that offers this feature <janneke>so for autoconf, we need to set CFLAGS (and repeat the default "-g -O") <andreas-e>Ah, it would be nice to have this everywhere! <janneke>yeah, someone needs to send a patch to autoconf :) <andreas-e>I have a problem with perl-dbd-mysql. It contains C files and also needs the -Wno-error CFLAGS, but setting the environment variable does not work, since it is not picked up. Does anyone have experience with perl modules to propose a standard solution? <Kolev>How do I get GNOME on Fedora to see my Guix-installed programs? I logged in and logged out. <janneke>andreas-e: is there a way that codeberg picks up bug fixes, like using Fixes #nnnn. ? in a commit message? <janneke>(where is peanuts when you need them? ;) <andreas-e>Maybe peanuts has been turned off? Or it is still on debbugs. <janneke>that can be in the body (third line) of the commit message, right? <janneke>ACTION goes to waste time elsewhere, this is not funny <andreas-e>It is a good sign! It also just happened to me. People are active! <andreas-e>I am not sure where people put the Fixes: line. I see it in the third line generally, but also right before Change-Id, where personally I would rather put it. <janneke>andreas-e: sounds good, as long as it's not the first line/subject <janneke>ACTION won't start any bikshedding on this and see where it goes <Kolev>Do I need to move stuff from .bash_profile to .profile, to get GNOME to see Guix-installed Emacs? <sham1>gnome-session *should* look at whatever your login shell sets in environment variables in order to set up your environment <sham1>Is the problem that you don't see the application launcher in the overview? <Kolev>sham1, correct. I search for Emacs and it's not there. <sham1>What does your XDG_DATA_DIRS look like? <Kolev>sham1, not good: /home/caleb/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/ <sham1>Yeah, you need to also point to your guix profile (and Guix Home if you also use that) <sham1>IIRC the profile script should set that up for you <Kolev>sham1, . "$GUIX_PROFILE/etc/profile" <sham1>Although I'd check if it does set XDG_DATA_DIRS first <sham1>You'll need to do that anyway though, so it's good to have it in there <sham1>Kolev: hm. Does $GUIX_PROFILE/share exist? <cow_2001>the current one is behind by two patch versions <sham1>I don't currently have a guix install handy so I can't check how it's supposed to look <sham1>Kolev: right. When you might be able to do `export XDG_DATA_DIRS="${GUIX_PROFILE}/share${XDG_DATA_DIRS:+:}${XDG_DATA_DIRS}"` <sham1>Basically you need to tell GNOME here to look for your application .desktop-files <sham1>Which in this case would be ~/.guix-profile/share/applications, which is why you need to add the ~/.guix-profile/share to the XDG_DATA_DIRS <Kolev>sham1, thanks. I'll see if it works once my laptop is charged. <lh>trying to understand how substitutes are built with the recent core-packages-team merge <lh>that’s a core-packages-team evaluation. is it because the public-inbox derivation on master didn’t change from when the job was queued on core-packages-team, and cuirass knows not to queue another? <lh>if that’s the case, why are there still hundreds of jobs in the master jobset? I would think almost everything would be substitutable before merging to master <lh>and it looks like the core-packages-team jobs get priority 8 (very low), which normally would make sense, but in the post-merge case where that jobset “owns” jobs that affect substitute availability on master, it seems like it will take a very long time for some of those substitutes to become available <lh>lmk if I am even in the ballpark here 😅 <andreas-e>lh: On CI the evaluations currently fail because there is some inconsistency with respect to the Guix daemon database. <andreas-e>You see it from the red crosses. So I think no packages are actually built. <andreas-e>Bordeaux should have most of the substitutes from the core-packages-team before the merge. <andreas-e>After it, the data service advances very slowly with its evaluations, but it is making progress. <lh>why do you mention the data service, is it relevant to substitutes? <andreas-e>Yes, the data service is used to submit build jobs to the bordeaux build farm. <andreas-e>And normally both are activated bordeaux and ci (also known as berlin). <andreas-e>Why a failed evaluation would lead to builds, I have no idea. <umanwizard>has a major change happened to core packages recently? I'm noticing that a reconfigure wants to rebuild a huge amount of stuff <umanwizard>(and, of course, it's failing in something relatively deep in the dependency chain... to wit: BDB) <lh>yeah, core-packages-team got merged. shouldn’t be a huge amount of rebuilds unless you have many custom packages though <lh>umanwizard: guix weather says bdb is available for me on guix 7fb90150f3d2ca10ba7385d7a704cc1a7d4b532c (post-merge) <lh>andreas-e: thanks, I will have to read up on the data service, I assumed it was downstream of cuirass <andreas-e>No, the two build farms are completely separated. <andreas-e>umanwizard: Which bdb is it? We have three of them. And can you open an issue or pull request on codeberg? <lh>andreas-e: you mean bordeaux uses the data service but berlin does not? <umanwizard>andreas-e: yes I will do that once I understand better what is happening <andreas-e>lh: Exactly. There is one cross-link, that the data service also captures what is built by berlin. <umanwizard>so, let me try applying the same patch debian folks did and see if it works. If so I'll send a patch <umanwizard>we can open PRs on Codeberg now instead of sending patches to the mailing list? <lh>interesting, so bordeaux consumes data from the data service but also produces data consumed by the data service? <andreas-e>It consumes the derivations, and produces substitutes. <lh>makes sense. why does berlin not do this? I would have assumed they were running the same software <andreas-e>No, we just have two independently written build farms... <andreas-e>umanwizard: It would be nice if we had fewer packages that depend on bdb@4! Having to lug around old software is annoying. <andreas-e>Hm, bdb@5. For bdb@4, there is almost nothing left. <lh>oh haha, I assumed cuirass handled everything <andreas-e>umanwizard: Great! I am looking forward to the patch. Bonus points if you can apply it conditionally only on aarch64, to avoid rebuilding tons of packages on x86. <umanwizard>is there a way I can try reconfiguring my system with my patch? guix system reconfigure doesn't seem to accept the --with-patch flag. <andreas-e>You can modify your git checkout, and then "./pre-inst-env guix system reconfigure ..." from within. <andreas-e>I do not know how this collaborates with sudo, however. <umanwizard>maybe `./pre-inst-env guix pull` followed by `sudo guix system reconfigure ...` would work? <andreas-e>No, "guix pull" would pull from the current HEAD of master and not contain your local changes. <ekaitz>andreas-e: or maybe ./pre-inst-env sudo ...? <andreas-e>Or "sudo -i", then "cd /home/user/.../guix", then "./pre-inst-env ...". <ekaitz>i normally guix system reconfigure with `sudo -E` <umanwizard>andreas-e: neither of those work, because it can't find stuff from my personal channels <umanwizard>guix system: error: failed to load '/home/brennan/guix-home/config-desktop.scm': <umanwizard>ice-9/boot-9.scm:3330:6: In procedure resolve-interface: <andreas-e>Then I do not know... Maybe submit your patch to codeberg as is :) <umanwizard>I don't know how to apply patches conditionally based on arch. I'll submit what I have and someone more expert can modify it before applying, I guess. <andreas-e>Yes, good. It cannot be done on the source code level, but you can have conditional phases. There is a nice example in commit 4cb2e664bde0e419f2f7d3231d64474f7c9006de , where it is even a patch file that is applied. A substitute* would be easier. <andreas-e>I mean, I think patches cannot be applied in the origin field depending on the architecture. <umanwizard>I will fix it later to only apply the patch on aarch64 and also fill in the PR description checklist, if nobody else fixes it and applies it by then. Don't have time to do so now. <meaty>How can I run a docker container as a service? There seems to be services for docker itself, but not a generic "run this docker container as a service" <meaty>oh, wait, i think it's oci-container <andreas-e>lh: Well, it was relatively easy: It was the first (and only, I think) evaluation that had actually started. <andreas-e>CI is back, at least for the master branch. Excellent! <gabber>did we see some build failures due to "error: assignment of read-only member" since the core-packages merge? any ideas on how i could resolve it? <andreas-e>Yes, this has occurred somewhere today. But I do not remember where, and how it was resolved... <gabber>that's a bummer :( sooo, maybe it was in the same place? and/or definitely among today's commits? <andreas-e>I went back to gcc@13, which is not a very good solution, but I did not know what else to do. <andreas-e>Did you try to update the package? I have also seen another case today where the changelog of a recent version explicitly mentioned adaptations to gcc@14. <vagrantc>it is hidden by the fact that substitutes are somehow available <gabber>`guix shell -D guix -- make` errors: "automake-1.16: command not found". is it me? <vagrantc>gabber: you probably need to re-run "sh -c './bootstrap && ./configure ... && make'" <vagrantc>if you gc'ed the automake that the last bootstrap/configure hard-coded <gabber>andreas-e: that seems to help - at least i'm now at "foo has not been declared" and missing includes. should i now turn off the errors or add the includes? <andreas-e>gabber: Strange. Normally with gcc@13 I have not seen the missing includes and warnings turned errors. <gabber>ah, i bumped the package version <gabber>did not try the gcc@13 route (yet) <gabber>bumping and adding the include builds, but now tests fail :( <Kolev>How do I package Bash scripts (or other scripts)? <andreas-e>Ah okay, yes, with gcc@14 adding the includes and CFLAGS is okay. <gabber>Kolev: i think even the simplest copy-build-system patches shebangs <gabber>andreas-e: unfortunately it seems not *that* easy <andreas-e>That would be preferable to staying at gcc@13, which I think amounts to postponing the problem instead of solving it. <gabber>flatbuffers@2.0.0 seems to be the legacy version of the software anyways. but as long as kodi depends on it.... <andreas-e>Lesson of the day: It just happened ramdomly that I did a Big Merge(TM) on a Friday evening, but this is good timing; it leaves the weekend for repairing things. <andreas-e>It has been an intensive day, for many people if I look at the activity on codeberg! <gabber>andreas-e: are problems with the merge/sprint recorded somewhere? <gabber>unfortunately, changing the route (first using gcc-13, then bump, then include the headers) does not work either (on any of the steps) <gabber>Kolev: not sure if i understand your question, but i am sure you can. what could hold you back? <Kolev>gabber, I'm not sure if it's just for one script, and if it woudl have to be modified a bit to work for mult. scripts. <andreas-e>gabber: You can just submit individual issues, as you just did. Now that the branch is merged, build failures have become a general problem ;-) <andreas-e>gabber: You could also patch, by removing a "const" somewhere, I suppose. <gabber>hmmm.. "error: ‘size’ is used uninitialized [-Werror=uninitialized]" and neither setting CFLAGS to "-Wno-error=uninitialized" nor adding the <cstdint> include help <andreas-e>I am building kodi with flatbuffers@24, and so far it is advancing. <graywolf>Hi, any commiter bored enough to take a look at #78858 ? I have simplified the tests for the curl package a bit. <Kolev>gabber, I notice I can't do `(let ((script-name "my-script"))` twice. <andreas-e>curl is a world rebuild, nobody wants to look at that :| <gabber>Kolev: i guess you could have more luck with define-syntax and the like..? <gabber>andreas-e: i'll leave you to it (i got to go) <graywolf>Hence the comment in the patch that it should go do core-updates-or-whatever-the-branch-name-for-these-changes-is-currently :) <andreas-e>graywolf: This is the kind of change that only makes sense when updating the package version; it is mainly cosmetic and does not warrant a world rebuild per se. So the challenge is to not forget it at the moment when one updates curl. <graywolf>I am, I can add curl update as well, current version is 8.15, so we are behind. <andreas-e>I just looked it up, our version dates from January 2024. <graywolf>I assume we do backport the security patches, so it is probably fine. <andreas-e>curl does not belong to any team. It would make sense to update it and add it to a branch that regroups a few big changes. <andreas-e>It would be easier if you could add it to codeberg. <graywolf>I do not have codeberg account, that is why I keep sending patches for now. <Kolev>graywolf, what account do you have? <andreas-e>You should create one :) I have started working on codeberg, and find it quite pleasant altogether. So there may be noone left to look at debbugs... <graywolf>I do not like the Terms of Use. I still did not make my mind what is the morally right way to handle that. <Kolev>graywolf, what do you find objectionable? <graywolf>I do not want to promise to keep looking at the web site every 3 months to check the Terms for changes. I do not want to promise to keep my email address up to date. I do not like that I am mandated to check the Terms of Use (or, access the web site to see the banner) but they cannot be bothered to send me an email when the change them (despite insisting on keeping the address up to date). <graywolf>I do not like that they do not expose the Terms of Use via API, so using the web site is mandatory. <graywolf>I cannot in a good conciense promise to not upload things that violate German law, because I do not know the German law. <graywolf>andreas-e: And I just want to say I appreciate all the reviews :) Thanks a lot <graywolf>Now I am back to drinking, enjoy the evening everyone <Kolev>graywolf, so am I! Have a good one!