IRC channel logs
2024-01-24.log
back to list of logs
<efraim>with the updated guile-git on debian I'm down to 4 test failures on powerpc-linux for guix-1.4.0 <efraim>they're all using (gpg+git-available?) so it looks like I have another package I need to rebuild <rekado>apteryx: well done! I hope I can make some time to review this today <rekado>I wonder if we should purge queued up evaluations on the master branch <rekado>the past few evaluations (from two days ago) are all bad <rekado>the most recent one started 39 hours ago and failed <rekado>can we zoom right past commit 3aa60e4096e5a9e880c9545cd28ec4aab610753f? <efraim>probably also a good idea to adjust the ci script to be more explicit about what to build and not just be "everything! except for that" <rekado>I’ve killed all the running “evaluate” processes on ci <rekado>this aborted the following evaluations: 1052744, 1067520, 1067361, 1052505, 1065446, 1052522, 1052665, 1065183 <rekado>master is now continuing with 1067582, commit 497780ad25faf71d3ace39efe7451ef01e353d5b. <rekado>until we get to 3aa60e4096e5a9e880c9545cd28ec4aab610753f <rekado>also aborted 1067581, 1067586 1067590 1067588 1067589 1067593 1067594 1067662 <rekado>also aborted 1067809 1067810 1067822 1067826 1067827 1067828 1067832 1067831 <rekado>I aborted many more evaluations; now it evaluates the master branch at 3aa60e4, which is the commit that should have fixed the problem. <rekado>sorry about all the other aborted evaluations that had to go to make room for more master evaluations <janneke>core-updates has been `evaluating' for ~15h without any apparent progress anyway <efraim>is it like time-machine where it needs to build guix for core-updates before it can continue to whatever you asked of it? <jpoiret>apteryx: after the patchelf and libgpg-error on c-u patchelf doesn't build and libassuan can't find libgpg-error <jpoiret>and that means bootstrapping everything since it hasn't been built on ci yet for some reason <efraim>IMO libgpg-error should produce gpg-error-config also on not-cross compile <jpoiret>huh, glibc 2.39 is going to release before we merge cu <efraim>I did ac_cv_path_GPG_ERROR_CONFIG=gpgrt-config for libbdplus to find libgpg-error, but since everything expects gpg-error-config we should just provide that <jpoiret>we should keep kludges to a minimum on c-u, even if that means more rebuilds <efraim>I'll add --enable-install-gpg-error-config for system-hurd and for "else" on libgpg-config <efraim>I've added it to system-hurd and 'else', testing with libbdplus and with --target <efraim>I haven't touched libgcrypt and its use of gpgrt-config <jpoiret>efraim: could you localize the cond a bit more? <jpoiret>I don't think we should guard the whole argument list by the current target <jpoiret>like the phase fix-gen-lock-obj.sh, it's not immediately clear to me why that is only needed for xcompile <jpoiret>ouch, seems like EAT is choking on weird build logs and it's destroying my emacs <rekado>ACTION uses M-x shell with coterm now (also because of somewhat weird eat behavior) <mekeor>jpoiret: can you share such a build log? <jpoiret>heh, actually it might have been another issue, C-g'ing out of it worked in the end <janneke>jpoiret: this morning i saw `evaluating' since 15h on c-u, no idea what that means <yelninei>hi i remember seeing a video of a talk a while ago on guix where a guile script got added as a guix subcommand but I can't find the video anymore and also nothing in the manual/cookbook an that. <jpoiret>janneke: evaluation is basically `guix pull` <jpoiret>yelninei: there's simon's talk from 10 years of guix i think? <rekado>yelninei: you probably mean GUIX_EXTENSIONS_PATH <purifiedwater>does an installation of the guix system come with X windowing? <rekado>purifiedwater: that depends on your system configuration <efraim>jpoiret: patches pushed for libgpg-error <purifiedwater>So, I could select to install X server and window manager and everything with the install? <Altadil>purifiedwater: you can choose for instance GNOME or XFCE (or others) and it will install the dependencies automatically. <mekeor>ACTION does not know if the current graphical installer allows to select different DEs <efraim>rekado: can you tell if any of them are for core-updates? <yelninei>jpoiret: thanks i think that was excatly the talk I was remembering <rekado>the i686 evaluation failed with: “GC Warning: Out of Memory! Heap size: 3351 MiB. Returning NULL!” <janneke>ACTION had already built a hurd system, but building the image to test it still had many unbuilt packages <efraim>rekado: is that for a guix evaluation or for guile? <janneke>efraim: no, even without grafts some ~260 new builds for hurd system with the new c-u patches <civodul>rekado: evaluations are performed in parallel for each system <civodul>if one of them fails, the whole thing is marked as failed <civodul>yet, it’s possible that it succeeded and produced valid builds for other systems <janneke>seems c-u still isn't really being picked-up <janneke>but when building locally, its substitute isn't downloaded <janneke>The following derivation will be built: <janneke> /gnu/store/wh28brd01af4zqihwb1n6agch2b9k6cp-guix-1.4.0-16.aeb4943.drv <apteryx>hello! do we have some guideline for Texinfo enumerate in package descriptions? should there be no newlines between its start and the rest of the text? <rekado>I put newlines after @enumerate and after each @item <rekado>and when an @item is too long I indent the following lines <rekado>oh, sure, I put the @enumerate on its own line <apteryx>I meant ...has the following features:\n\n@enumerate ... <apteryx>jpoiret: I had updated libuassan to fix that, perhaps I forgot to push? <apteryx>jpoiret: nope it's there in 9cc6e6f643 <apteryx>I'm not at looking at rust 1.73, some phases is not correctly ordered or something <apteryx>(ordered after nonexistent phase, perhaps) <janneke>hmm, although it's supposed to be built, the nar doesn't seem to be there <apteryx>rekado: would you like to see "Add a button to copy a message Message-ID to the clipboard." in action? I could deploy it to berlin <apteryx>I've spent 2 days on that tiny feature, I think it's polished ;-) <jpoiret>apteryx: I didn't have that commit yet <jpoiret>also 8219ab0443129c71eef83ee4bd3aae0a0a12b6f9 does not build anymore because the enable-codegen-tests doesn't exist <jpoiret>apteryx: wrt yasnippet see gnu/packages/patches/emacs-yasnippet-fix-tests.patch <janneke>ah, there was some delay wrt nar availability, or so it seems <apteryx>updated to master and removed that old patC <futurile1>hmm looks like packages.guix.gnu.org can't reach gds so there's no package search on the web site a the moment <apteryx>our 'git format' autoconf has "useAutoBase = true" so that shouldn't happen <janneke>hmm, cups-filters does not build on core-updates <apteryx>I've updated it to latest locally, I think that helped <apteryx>let me check again, i'll push it if fixes it <janneke>ah, /me tried updating to 1.28.16 (and had to add libexif) but that didn't help <janneke>possibly qpdf needs an update (or downgrade?) <janneke>why don't configure check for its dependencies? <janneke>yeah, we prolly need the previous one <apteryx>looks like a standard thing, so it's probly building with too old C++ standard <apteryx>std::strting_view was added to C++17 <janneke>using the older qpdf-11.3.0 works, of course; but if you have a better fix i won't push <apteryx>checking with a CXXFLAGS=-std=gnu++17 <janneke>ACTION resurrects building of man-doc on core-updates <civodul>that packages.guix.gnu.org contacts data.guix for each request is suboptimal <civodul>i added nginx caching to mitigate that but the design is problematic <janneke>ACTION updates python-pyelftools to 0.30, fixing the build <jpoiret>so we're all building c-u locally, eh? <janneke>webrtc-audio-processing has a failing patch, ring any bells? <apteryx>I've updated it without testing. I can look into it <janneke>yeah, you're the usual suspect in this case <apteryx>jpoiret: looks like pkgconf behaves better than pkg-config <apteryx>e.g. "./pre-inst-env guix shell --pure pkgconf pkg-config mpv -- pkgconf --print-errors --exists mpv" succeeds if I revert "gnu: mpv: Propagate most libraries." <apteryx>but meson -Ddefault_library=shared conf flag on mpv would have the Requires.private line omitted as well <apteryx>oh, some distributions have switched to pkgconf over pkg-config (RHEL 8) <apteryx>must work well enough; perhaps we could consider doing that <apteryx>jpoiret: if you want to see if that helps, you could try having pkgconf obsolete pkg-config on core-updates (being used in its place) <apteryx>pkgconf optimizes linker dependencies to avoid overlinking; that could reduce closure size of some packages as well, perhaps <apteryx>janneke: webrtc-audio-processing build fixed <janneke>ACTION notices the rust boostrap rust-1.{54..73}.0 being part of the hurd vm dependency <janneke>weren't people working on a mitigation for the librsvg disaster? <janneke>ie, a more bootstrappable implementation? <efraim>vagrant noticed rust got pulled in with... guix-icons I think, or with the grub theme <efraim>I think the "fix" was to pre-generate the png or something so it didn't need any librsvg <efraim>or we could force librsvg-2.40 for that <pinoaffe>is there a way to list all the packages (including propagated inputs) in a profile <pinoaffe>(as well as the respective package versions)? <pinoaffe>never mind, I figured out how to do it from the guix repl <janneke>efraim: using librsvg-2.40 might be nice, but i wouldn't dare to just (try to) make that change <janneke>i could try to do that locally, or on hurd-team, to build my vm faster <janneke>hmm, rust also sneeks in via qemu-minimal -> python-sphinx-rtd-theme -> python-urllib3 -> python-cryptography -> python-cryptography-rust <janneke>maybe qemu-minimal could be more minimal? <nmeum>how do I best update a debbugs issue with multiple patches? do I just send a new revision for the patch in the patch series that changed or do I resend all patches? <nlongitude>but using the guix command it gives, it fails to run because it can't find libgcc_s.so.1 <janneke>bah, there's also samba -> python-cryptography -> python-cryptography-rust <apteryx>interesting, 'guix lint' seems to get line info wrong when reporting double space issue <apteryx>possible infraction at 538, but that was on line 107 <janneke>ACTION wrote 5 commits to remove rust dependency from the hurd vm...but gtk+ is also a dependency so this is never gonna fly :( <janneke>okay, so everyone is bootstrapping rust on core-updates :) <janneke>apteryx: but nar's are not available, so it seems? <janneke>ACTION just restarted a build and is now building rust-1.55 <apteryx>hydra-guix-129 does not directly publish substitutes <apteryx>perhaps if I run 'guix build rust' on berlin it'd fetch them <janneke>racing against the build farm, bad idea :) <efraim>I started qemu-minimal because it was a pain to build on powerpc <apteryx>maybe qemu-minimal can do without the doc <efraim>probably, it was originally meant to be used to be used for the native architecture to build images and such <efraim>not sure about the samba part, that gets into seeing what actually uses qemu-minimal <efraim>i'm getting a build failure on clang-13 and on gcc-9. I dropped gcc-9 from range-v3 (for telegram-desktop) but clang-13 we actually need to build correctly <apteryx>shouldn't we have a 'lua' variable ? <efraim>I think the language isn't consistent between the versions, so probably not <janneke>hmm, gtk+ comes via ibus, maybe we can use ibus-minimal? <apteryx>efraim: lutok seems to check for lua >= 5.1 (unbound) <janneke>hmm, sdl2 should be dropped from qemu-minimal, what's going on? <apteryx>we should at least have a default version, and that could be 'lua' <apteryx>to avoid packages depending on 5.1, 5.2, 5.3 all at onces <apteryx>hm, I think lutok doesn't actually support 5.4, just 5.1 or 5.2 <efraim>did we get that patch to fix llvm-15 on i686 into core-updates? <janneke>hah! rust dependency is gone from qemu-minimal <efraim>I got a too-many-cores build failure on rust-1.54 <janneke>wow, the qemu rust dependency comes from building the docs -- wtf? <efraim>I've tried wrapping some of the packages which want python-cryptography with supported-system? but they actually need them <efraim>yeah, rip out the docs from qemu-minimal <apteryx>janneke: it's from python-sphinx, I reckon <rekado>our python importer also pulls it in for many packages that don’t *really* need it <apteryx>why is our python importer doing a poor job of figuring the right inputs? is it a garbage in -> garbage out situation, or are we doing something suboptimal? <janneke>so now rust is gone from qemu-minimal, but it's still coming in via sdl2 -> ibus-"minimal" -> gtk+ <rekado>when the importer arrived at the scene setup.py ruled supreme <rekado>now we have a mix of pyproject.toml and setup.py <rekado>there are different sources of truth; some are pretty awful (e.g. a single requirements.txt file with tools for documentation, commit hooks, runtime dependencies, etc), others have nicely annotated sections in the pyproject.toml <rekado>the right thing to do is not entirely clear <apteryx>I guess we should prefer pyproject.toml and then fall back to what we're doing <bienjensu>Could someone try reproducing `guix shell --pure emacs-minimal emacs-citar -- emacs -nw` as giving a "value as variable is void" error? <lilyp>Which value is void as a variable? <lilyp>with -Q, I can at the very least get to (require 'citar) without issues <lilyp>hmm, that's a function as far as I can see <lilyp>if you're using it elsewhere in your own code, try quoting it as #' <bienjensu>Oh, will a pure shell still pull in other config? <rekado>apteryx: many projects use a pyproject.toml that defers to setup.py <rekado>and setup.py often is not data but code <vagrantc>janneke: fwiw, i ended up just excluding the grub theme from my aarch64 VM to avoid building rust ... but sounds like you have other rusty dependencie <lilyp>bienjensu: your $HOME is still visible, as is your emacs config <rekado>bienjensu: I’ve seen that error, too. I ended up removing emacs-citar from my config (I had never used it before, but wanted to try it). <lilyp>if you want to hide it, you need --container with some extra tricks :) <lilyp>it is weird to have two people reporting that error, though <lilyp>I'm not using citar myself, so I can't really say what's wrong <bienjensu>It doesn't happen with emacs-citar 1.3.1. I was assuming something was messed up with autoloads. <vagrantc>janneke: i am guessing you do not need a graphical theme for your hurd VM either :) <lilyp>good point, let's try sourcing the autoloads instead <vagrantc>janneke: but if it is helpful: (bootloader (bootloader-configuration (theme (grub-theme (image #f))) ... <vagrantc>janneke: also had to remove guix-icons from %base-packages ... or rather explicitly define %base-packages-* excluding %base-packages-artwork (i think?) <bienjensu>lilyp: My elisp is pretty terrible. There's already an issue upstream (from another guix user) but it might be to do with our autoloads. <bienjensu>It seems like cl-defstruct is acting strange for some reason in the autoloads. <darwinsfinch>hopefully there are no surprises on this old pc with this <bienjensu>lilyp: I think it might be because cl-lib isn't required in the autoloads file. I'm not sure what the best way to test/fix this would be. <lilyp>bienjensu: I'm pretty sure that cl does not exist when loading the autoloads, so the syntax is misunderstood <lilyp>anyway, this can be fixed by changing the autoload cookie <darwinsfinch>Is there a way to upgrade the system to current or to latest from standard? <sarg>hey guix, anyone running other distros in chroot? I want to run some deb-packaged app and don't want to spend too much time on tweaking guix shell -CNF <lilyp>normally you'd do a guix pull followed by guix system reconfigure <lilyp>(also guix package -u/-m for user packages) <lilyp>(or guix home reconfigure if you use that) <sarg>I've tried fakechroot + debootstrap, but it segfaults when entering the chroot <lilyp>sarg: patchelf might help you, but there's probably lots to patch <vagrantc>hrm. i have done debian chroots on guix, but it has been a while ... <janneke>vagrantc: image #f is a nice trick, but yeah, more rustness going on <janneke>guess i'll wait for the build farm to build rust, while i'm sleeping <bienjensu>lilyp: Would `(eval-when-compile (require 'cl-macs))` work? <efraim>looks like there's a lot of python packages which want the en_US.UTF-8 locale <vagrantc>janneke: trick? I assumed that was how it was supposed to work. :) <vagrantc>though, i flailed around just to get that far <vagrantc>when i do some package related operation, e.g. guix shell somepackage ... why does it not necessarily know how much it needs to download until after it has downloaded something? e.g. often get download 0.4MB ... it downloads something, then downloading 60MB ... it downloads some things ... downloading 100MB ... <vagrantc>shouldn't guix be able to know what it has available after checking the substitute servers in the first pass? <rekado>vagrantc: is it the same behavior when you use “--no-grafts”? <vagrantc>rekado: not sure ... i just see it occasionally and wonder <vagrantc>e.g. if i tried to do it again with the one that just succeeded, obviously it wouldn't download anything :) <vagrantc>but i guess i can try with no-grafts next time to check my curiosity <bienjensu>Haha, so emacs-citar has the specific test suppressed which would fail the build because of... citar-indicator-create's value as variable being void. I'm going to try doing a require in a build phase. <hatim>Hi.. how do I set the locale and keyboard to be a UK one, when I am running Wayland? <bienjensu>hatim: If you're using sway, put `input * { xkb_layout gb }` in your config file. <hatim>bienjensu Thank you, I'm using dwl-guile... it has a similar config set-xkb-rules.... <Kolev>mekeor I gave up and switched to Fedora. <lilyp> Can we make a commitment to graft webkitgtk the next time it gets a version bump? 10h compile is not fun for anyone. <lilyp>(Well, we'd still have the 10h compile but it also causes lots of rebuilds) <jackhill_>I wondered about that, but I guess compared to webkit the other builds are lighter at least. <jackhill>how does grafting work with the package varients? <lilyp>If everything's set up correctly, they should pick up the grafts naturally <lilyp>if not, we'd have to swap out our inherit <jackhill>hmm, looks like a wpewebkit update is in order at some point <jackhill>lilyp: I guess it should be pakcage/inherit rather than inherit, is that right? <lilyp>yep that's what I was hinting at <lilyp>and yeah, wpe is not getting any love either <jackhill>thanks for confirming. I'm learning … slowly! Well, at least there's noting in guix that depends on wpewebkit yet. Still should show it some love.