IRC channel logs


back to list of logs

<apteryx>rekado: feature done!
<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 a good idea
<rekado>(I don’t know how)
<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.
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<rekado>I’ll kill that one too
<rekado>until we get to 3aa60e4096e5a9e880c9545cd28ec4aab610753f
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<rekado>also aborted 1067581, 1067586 1067590 1067588 1067589 1067593 1067594 1067662
<rekado>also aborted 1067809 1067810 1067822 1067826 1067827 1067828 1067832 1067831
<adanska>Hi Guix!
<futurile1>morning all
<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?
<sneek>Welcome back apteryx!!
<efraim>little late sneek
<jpoiret>apteryx: after the patchelf and libgpg-error on c-u patchelf doesn't build and libassuan can't find libgpg-error
<jpoiret>efraim: yes
<jpoiret>and that means bootstrapping everything since it hasn't been built on ci yet for some reason
<jpoiret>the bootstrap is very long
<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
<efraim>one glibc bump at a time :)
<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
<jpoiret>isn't it alread enabled on c-u?
<efraim>only when cross building
<jpoiret>ah, didn't see the enclosing cond
<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
<efraim>sure, I'll poke it a bit
<jpoiret>like the phase, 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)
<jpoiret>does coterm work better than eat?
<mekeor>jpoiret: can you share such a build log?
<mekeor>jpoiret: did you try vterm?
<mekeor>i never used coterm
<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
<jpoiret>yeah, I think the second part of contains some of that
<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
<jpoiret>ah, thanks
<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.
<purifiedwater>I will download the iso immediately
<mekeor>ACTION does not know if the current graphical installer allows to select different DEs
<rekado>five of the possible 8 evaluations are tied up in the “guix” jobset, but none of them have completed:
<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>efraim: none of them are
<rekado>the i686 evaluation failed with: “GC Warning: Out of Memory! Heap size: 3351 MiB. Returning NULL!”
<janneke>oh my, another wave of rebuilds
<janneke>ACTION had already built a hurd system, but building the image to test it still had many unbuilt packages
<efraim>janneke: grafts?
<efraim>sometimes I test without grafts
<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
<peanuts>"debian Pastezone"
<peanuts>"debian Pastezone"
<rekado>I don’t understand this. is “in progress” but there are no scheduled jobs.
<rekado>two jobs succeeded, one failed.
<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
<civodul>this is admittedly hard to read
<janneke> :(
<janneke>seems c-u still isn't really being picked-up
<janneke>huh, guix built on core-updates about an hour ago --
<peanuts>"Build 3349121"
<janneke>but when building locally, its substitute isn't downloaded
<janneke>./pre-inst-env guix build guix
<janneke>The following derivation will be built:
<janneke> /gnu/store/wh28brd01af4zqihwb1n6agch2b9k6cp-guix-1.4.0-16.aeb4943.drv
<janneke>the hash of the .drv is identical
<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?
<apteryx>or are newlines fine?
<rekado>I put newlines after @enumerate and after each @item
<rekado>and when an @item is too long I indent the following lines
<apteryx>not before it starts?
<rekado>oh, sure, I put the @enumerate on its own line
<rekado>same with @end enumerate
<apteryx>I meant ...has the following features:\n\n@enumerate ...
<apteryx>vs one \n
<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)
<apteryx>which would now throw a match error
<janneke>hmm, although it's supposed to be built, the nar doesn't seem to be there
<janneke>(always guessing a bit here...)
<apteryx>does oleg/sharlatan hang out here?
<efraim>sneek: seen sharlatan
<sneek>sharlatan was last seen in #guix 3 months ago, saying: What do you think about this patch set?
<peanuts>"[PATCH 00/19] gnu: Astronomy 2023/08 updates."
<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 ;-)
<apteryx>that is mysterious:
<peanuts>"delete-numberless-inner-snippet-issue-562 test failure (non-deterministic) ? Issue #1185 ? joaotavora/yasnippet ? GitHub"
<jpoiret>apteryx: I didn't have that commit yet
<jpoiret>also 8219ab0443129c71eef83ee4bd3aae0a0a12b6f9 does not build anymore because the enable-codegen-tests doesn't exist
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<jpoiret>apteryx: wrt yasnippet see gnu/packages/patches/emacs-yasnippet-fix-tests.patch
<apteryx>yes, I got that n ow
<janneke>ah, there was some delay wrt nar availability, or so it seems
<apteryx>updated to master and removed that old patC
<apteryx>jpoiret: thanks
<futurile1>hmm looks like can't reach gds so there's no package search on the web site a the moment
<apteryx>why is it that many patches submission are missing the ancestor information? e.g.
<peanuts>"[PATCH] Clarify definition of channel files in the cookbook."
<apteryx>our 'git format' autoconf has "useAutoBase = true" so that shouldn't happen
<apteryx>this in turns cause QA to fail to apply many patches:, I think
<peanuts>"Issue 68419 Guix Quality Assurance"
<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
<apteryx>nope, wants libexif
<janneke>possibly qpdf needs an update (or downgrade?)
<janneke>why don't configure check for its dependencies?
<apteryx>it's been upgraded on c-u yes
<janneke>yeah, we prolly need the previous one
<janneke>ACTION tries adding qpdf-11.3.0
<apteryx>ah std::string_view
<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
<apteryx>but its building with -std=gnu11
<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
<apteryx>it built!
<apteryx>i'll push in a bit
<janneke>nice, ty!
<janneke>ACTION continues hurd vm build
<janneke>ACTION resurrects building of man-doc on core-updates
<rekado>futurile1: in a pinch you could use
<peanuts>"Guix-HPC ? Search"
<civodul>that 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
<janneke>on core-updates
<futurile1>thanks rekado - didn't know aboutthat
<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
<apteryx>(now that we have substitutes!)
<janneke>yeah, you're the usual suspect in this case
<janneke>ACTION goes to prepare some dinner
<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>apteryx: yay, ty!
<janneke>ACTION notices the rust boostrap rust-1.{54..73}.0 being part of the hurd vm dependency
<efraim>janneke: guix-icons?
<janneke>probably, librsvg in any case
<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>what is the "replacement" for gcc:lib? i'm trying to run tor browser, following this old blog post
<nlongitude>but using the guix command it gives, it fails to run because it can't find
<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 :)
<apteryx>hydra-guix-129 is at rustc-1.62.1
<peanuts>"Commits ? wip-sans-rust ? janneke / guix ? GitLab"
<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 ?
<apteryx>which is latest lua
<apteryx>on top of these lua-5.x ones
<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>(unless there's a good reason)
<apteryx>hm, I think lutok doesn't actually support 5.4, just 5.1 or 5.2
<apteryx>yeah, it doesn't detect 5.4
<efraim>did we get that patch to fix llvm-15 on i686 into core-updates?
<janneke>hah! rust dependency is gone from qemu-minimal
<janneke>let's see if it still builds
<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>ugh, that’s awful
<rekado>sphinx ends up everywhere
<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>apteryx: right
<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 ruled supreme
<rekado>now we have a mix of pyproject.toml and
<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?
<bienjensu>with a recent-ish guix-pull (citar 1.4.0).
<lilyp>Which value is void as a variable?
<lilyp>with -Q, I can at the very least get to (require 'citar) without issues
<bienjensu>lilyp: `citar-indicator-create`
<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
<rekado>and 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>well I installed guix with exwm
<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
<darwinsfinch>okay thank you
<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
<darwinsfinch>I assume that their are mailing lists for GNU Guix.
<civodul>darwinsfinch: yes, check out
<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
<janneke>vagrantc: exactly
<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>lilyp: Setting #:emacs to emacs-no-x in the build args fixes the issue. There seems to be some sort of problem with using the default build emacs and it not expanding cl-lib macros while compiling the autoloads (seems to be a problem resembling this ).
<peanuts>"Re: autoload cl-defstruct constructor?"
<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.
<mekeor>i know :) (from #emacs)
<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
<lilyp>-for-gtk3 looks borked imho
<jackhill>how so?
<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.