IRC channel logs

2024-02-02.log

back to list of logs

<jpoiret>alright, built back up to sway, we'll see about gnome tomorrow. probably going to add at least the mesa gallium fix since it breaks some mutter tests
<spiderbit>I try to update to a branch version of guix changed this 2 things:
<spiderbit>can I post here 4 lines?
<spiderbit>    (channel (name 'guix)
<spiderbit>         (url "https://git.savannah.gnu.org/git/guix.git")
<spiderbit>         (branch "gnome-team"))
<spiderbit>       ;; %default-channels
<spiderbit>well changed that it my channels.scm
<spiderbit>did a guix pull but now I get strange errors when I try to recorfigure
<spiderbit>unrecognised boot parameter
<villageidiot>What's the simplest way to test out a small change to a package definition? Need I create my own local channel or is there some way to install a one-off package definition from outside the known channels?
<villageidiot>e.g. I want to bump a version of blender because 3.5 seems to not have Wayland support even though I thought it was added in 3.4. Anyway I want to up the version to test it.
<iyzsong>villageidiot: 'guix build' could does it, with package transformation or a package (maybe inherited) in a file via '--file=FILE'
<alextee2>lilyp, thanks. any time frame on when gnome-team will be merged?
<villageidiot>iyzsong: Oh, that looks promising. So I could build it with `--file` then get into a `guix shell` seeing as it should be in the store?
<iyzsong>villageidiot: i think it can, via 'guix shell --file' or 'guix package --install-from-file ... --profile ... ; guix shell --profile ...'
<villageidiot>iyzsong: Thanks a bunch! I'm going to revise the package and try `guix shell --file ...`
<iyzsong>good luck :)
<oriansj>there is a crashing bug on sway for endgame-singularity, the fix is just upgrading the python-pygame to 2.5.2. Here is a file one can verify that will fix the bug and add an updated build definition for python-pygame to be version 2.5.2 https://paste.debian.net/1306069/
<rdrg109_>[Question] I'm using Guix in Ubuntu. I accidentally deleted all files in /var/guix/profiles/per-user/rodrigo/. When I try to execute "guix package -i <<package>>", I get the following error: bash: /home/rodrigo/.config/guix/current/bin/guix: No such file or directory. How to fix this?
<rdrg109>^ I fixed it by executing $ /usr/bin/guix package -i <<package>>
<apteryx>how does gnu-make-final depend on pkg-config and pkg-config depend on gnu-make-final without a cycle?
<apteryx>ah, it has its own pkg-config variant
<lilyp>alextee2: not yet, but it's getting closer™
<lilyp>jpoiret: good point, but I don't think it matters as much
<lilyp>if you really want to cut out dbus from your system, you're gonna have other troubles (elogind,…)
<lilyp>plus, both pipewire and pulseaudio rely on blessed alsa configurations – perhaps it's time to make that clear in code as well
<ulfvonbelow>is there a way to get 'guix import' to accept a list of names? I know that I could just invoke it several times, but there would likely be many duplicate dependencies
<olimex>hi
<DarwinsFinch>ACTION running guix pull on my armhf singleboard computer
<adanska>Hi Guix! I have a question regarding writing files that evaluate to a guix package: how do you make the file return a specific output of my package? i have an sdl (out) and ncurses (ncurses) version, and i want to pick the ncurses version to use in a container shell. how would i go about that? is there a procedure i can use to return the output i want?
<snape>sneek: later tell adanska: instead of returning the package you return (list package "the output")
<sneek>Got it.
<snape>sneek: later adanska: e.g. guix shell -f <(cat gnu/packages/bittorrent.scm <(echo '(list transmission "gui")'))
<snape>sneek: later tell adanska: e.g. guix shell -f <(cat gnu/packages/bittorrent.scm <(echo '(list transmission "gui")'))
<sneek>Will do.
<lechner>Hi, I get 504 from packages.ggo. Is the Data Service down again?
<snape>does anyone know how I can bind privileged ports in a 'guix system container' ?  Like a simple nginx listening on port 80
<snape>it says nginx: [emerg] bind() to 0.0.0.0:80 failed (13: permission denied)
<snape>the strange thing is that it works on 'guix system vm' but not on 'guix system container'
<dariqq>hi i am trying to reconfigure and get an error when building the profile: In procedure symlink: No space left on device even though at least 50G are free. Any ideas?
<cdo256>snape: the usual way for general linux containers is to set a capability when you create it with setcap for example. I think it's something like CAP_NET_BIND_SERVICE. I don't know if there's a declaritive way of doing it yet. It's not in the cookbook or manual.
<snape>cdo256, thanks, I think it's what I'm going to do indeed
<cdo256>snape: If that doesn't work, you should be able to set something up with nftables and network namespaces but I don't know how to do that yet.
<cdo256>dariqq: What does `df -h` give you?
<dariqq>Found this mail thread https://lists.gnu.org/archive/html/help-guix/2020-02/msg00085.html. Checking df -i says / has 100% inode usage. Hmm
<cdo256>dariqq: Looks like you're going to have to reformat https://unix.stackexchange.com/questions/26598/how-can-i-increase-the-number-of-inodes-in-an-ext4-filesystem
<dariqq>wild. Was able to clean up some files and now i am back at 35% inode usage.
<jpoiret>snape: did you enable shared networking?
<snape>-N yes
<snape>cdo256, jpoiret, now it works.  Maybe rebooting my kernel helped
<snape>weird
<jpoiret>that shouldn't work though, unless you start your system container as root
<snape>I did, but before that I used to do it as well and yet it didn't work
<jpoiret>if you share networking, you need either root or a specific capability to open a low port
<apteryx>why would replacing pkg-config with pkgconf, which has zero dependents and is uses url-fetch the same as pkg-config, cause some loop?
<jpoiret>did you recompile all .go files if there are some macro shenanigans?
<msavoritias>im trying to setup a prosody service. the example from the manual fails
<msavoritias>specifically http://paste.debian.net/1306113/
<msavoritias>i get this ^
<msavoritias>trying this example here https://guix.gnu.org/en/manual/devel/en/guix.html#index-prosody_002ecfg_002elua
<lechner>msavoritias / not sure about opaque- but this works for me https://codeberg.org/lechner/system-config/src/commit/a6962d1414d11040072f0e79ffde354fa523137a/host/wallace-server/operating-system.scm#L1269-L1279
<msavoritias>lechner: raw content that i see there is basically just adding the string to prosody.cfg.lua right?
<lechner>well, it should be. what's in here? "/home/fannys/mutable/Engineering/Contributing/XMPP/JoinJabber/Infra/System Declaration/system.scm" line: 105
<msavoritias>opaque-prosody-configuration
<apteryx>jpoiret: I recompiled all overnight yes (it takes 1 h)
<apteryx>after make clean-go
<jpoiret>ah, it's a guile-level loop?
<lechner>msavoritias / also, what's in here, please? gnu/packages/messaging.scm:1481
<lechner>msavoritias / i have a different code base, I think
<msavoritias>that prosody probably
<msavoritias>your thing worked anyway the raw-content
<msavoritias>so im going to keep it like that for now
<apteryx>it's the kind of hanging loop that eats memory, so I think a package needs pkg-config and pkg-config needs that package too
<apteryx>but if it's fine with pkg-config == current one, I don't see why it's not fine with pkg-config == pkgconf
<msavoritias>i think that specific part of the prosody service has something buggy
<lechner>msavoritias / glad to hear it! not sure what this missing-field thing does https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/messaging.scm#n640
<lechner>i agree
<lechner>msavoritias / please file a bug
<jpoiret>apteryx: what's pkgconf's build system?
<apteryx>gnu-build-system
<apteryx>I've pushed the wip branch as wip-cu-switch-to-pkgconf, in case you'd like to take a peek
<apteryx>everything works except the last commit
<apteryx>which causes pkg-config to become an alias to pkgconf-as-pkg-config
<snape>msavoritias, I think it has never worked
<snape>weird nobody saw it before
<jpoiret>apteryx: heh, that (define pkg-config pkgconf-as-pkg-config) also needs to be a define-syntax with the identifier syntax
<jpoiret>otherwise you're actually evaluating what the pkgconf-as-pkg-config syntax represents at the top-level, which is a function call :(
<snape>sorry about that
<snape>maybe we should just remove the opaque conf
<snape>or add a pid field
<snape>yeah probably a pid field sounds like a good idea
<snape>but that would mean the person must write the pid-file manually into the raw config
<snape>annoying
<apteryx>jpoiret: oh!
<apteryx>I'll know it 30 minutes after rebuilding following grep -Rl pkg-config --include='*.go' | xargs rm
<apteryx>(if it works) :-) thanks for looking at it!
<jpoiret>so zink actually doesn't work on master
<jpoiret>if my testing is right, `guix shell mesa-utils -- env MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo` should error out
<ulfvonbelow>what's our policy on hybrid rust-python packages as far as naming, positioning, and build-system go?
<ulfvonbelow>it seems like they can't usually really be split into two packages that can be used meaningfully in an independent fashion
<jpoiret>why do we even keep such ancient llvms
<jab>we are talking cool Hurd stuff if ya'll want to join
<jab> https://jitsi.member.fsf.org/AlpineHurd
<janneke>jpoiret: just been discussing hurd with a group of 16 people, glibc-2.39 was mentioned; wondering how that goes :)
<janneke>@guix days
<snape>re container: it worked, not because of my reboot, but because I typed sudo sysctl net.ipv4.ip_unprivileged_port_start=0
<jpoiret>janneke: i'm building to gnome for now :)
<jpoiret>will have to patch clang at some point, and we have like 10 versions of it, not looking forward to that
<podiki>jpoiret: maybe cuirass should be building all of core-updates? or at least for x86 for quicker testing?
<jpoiret>I'm testing local patches for now
<jpoiret>like the 2.39 update, mesa patch, etc.
<jpoiret>don't want to push if it doesn't work
<podiki>well if glibc builds at least...
<podiki>i just don't know if it is worth it to build everything on your own over and over, at some point will need to see how it shakes out and then more people can easily help
<podiki>(coming from someone that did build a lot of branches locally as well sometimes, but i'm also impatient :) )
<jpoiret>the main issue is that I don't want to push incorrect commits on c-u just to see if they work
<jpoiret>and I think that my machine is probably as fast as CI
<podiki>ok!
<podiki>just saying you don't have to worry about it being perfect, if there's a reasonable expectation that things are okay (at least close in the dependency graph) we may just have to live with it
<podiki>personally, when i see the entire rust chain come up locally i quit :)
<jpoiret>yeah
<jpoiret>but it's just that I had the unpleasant surprise to discover that quite a lot of patches that were merged were faulty
<podiki>unless maybe if it is really cold here....
<jpoiret>don't want to repeat that myself
<podiki>yeah i understand
<podiki>and it is appreciated!
<jpoiret>(or so I say but I pushed a matplotlib patch that is completely broken 🙄)
<podiki>oh, while I have you, did you try (or are trying) to patch the zink vulkan issue?
<jpoiret>yes, that's what I meant by mesa patch above
<jpoiret>can you try `guix shell mesa-utils -- env MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo` on master btw?
<jpoiret>if you have it lying around
<jpoiret>it should error out
<jpoiret>it works with my patch so I think we're good
<podiki>yeah fails to load libvulkan
<podiki>i can test your mesa patch locally if you want as well, mesa is quick to build
<podiki>or if you want any other random patches to check vs master on my end, just let me know
<podiki>jpoiret: and thanks for leading the c-u charge! guix appreciates you
<jpoiret>podiki: https://paste.debian.net/1306125/
<jpoiret>really, ulfvonbelow did the investigation, the patch was trivial to write
<podiki>right, props to ulfvonbelow also!
<ulfvonbelow>how does vulkan-loader end up finding mesa, anyway? The control flow goes mesa (opengl) --> vulkan-loader --> mesa (vulkan), and vulkan-loader doesn't have mesa as an input or anything (of course that'd cause a circular dependency now). Is there some environment variable at play?
<jpoiret>hm, I bet it's something more sinister…
<jpoiret>vulkan-loader might dlopen mesa, but since it's already loaded it doesn't have to find it anywhere
<jpoiret>just a hunch
<podiki>there was a patch someone sent about adding a search path (one of the XDG_ ones) but i never got a response
<podiki>they had added it to mesa but i don't think it was going to do anything there
<ulfvonbelow>mesa doesn't have any generic vulkan soname to dlopen though, when I looked in lib/ it only had libvulkan_{intel,radeon,etc}
<podiki> https://issues.guix.gnu.org/65155 but maybe i read it wrong
<ulfvonbelow>unrelated but we should consider setting RUST_BACKTRACE=full before running tests in cargo-build-system
<apteryx>rekado: do you know if #59181 is still actual?
<apteryx> https://issues.guix.gnu.org/59181
<podiki>jpoiret: with the patch i get an error about not having dri3 (to load zink) but not the libvulkan error. but i have no idea if i'm set up for zink
<jpoiret>well, I don't know exactly how its finding it for me but it worked 🤔
<jpoiret>amdgpu though
<jpoiret>libglvnd and vulkan-loader are opaque to me, i'm just glad they work
<podiki>amd as well here
<podiki>xdpyinfo says dri3 available. huh
<apteryx>jpoiret: like this? (define-syntax pkg-config (identifier-syntax pkgconf-as-pkg-config))
<jpoiret>probably? maybe just (define-syntax pkg-config pkgconf-as-pkg-config) should work
<apteryx>that didn't work
<apteryx> Wrong type to apply: #<package pkgconf-as-pkg-config@2.1.0 gnu/packages/pkg-config.scm:134 7f0de9887580> while loading gnu/packages/adns.scm
<jpoiret>well, does your identifier-syntax work?
<jpoiret>otherwise you could just do a bare (define-syntax pkg-config (lambda _ #'pkgconf-as-pkg-config))
<apteryx>the identifier-syntax also didn't work
<apteryx>same error
<apteryx>I feel like the (define-public old new) was probably fine for an alias? otherwise I'd have gotten this kind of error, but instead I was getting a cycle
<jpoiret>i do think that's the source of the issue
<jpoiret>but defining such an alias seems quite annoying, save for just copy-pasting pkgconf-as-pkg-config's definition
<apteryx>wait, I could successfully run make with (define-syntax pkg-config (identifier-syntax pkgconf-as-pkg-config)); i think my previous report of a failure there was misguided
<apteryx>it built, but I'm now facing the same cycle
<apteryx>next I'll try just copying: (define-syntax pkg-config (identifier-syntax pkgconf-as-pkg-config))
<Peat>Hi everyone, I might have done something wrong, but when I try to verify  guix-system-vm-image-1.4.0.x86_64-linux.qcow2.sig I get "BAD signature". Is this reproducible on your side?
<msavoritias>lechner: ah just saw the message. yeah i filed a bug already was told in the xmpp room too :P its 68894
<vagrantc>huh. updated diffoscope and trydiffoscope on guix master ... and now "guix system reconfigure" is failing.
<vagrantc>i don't see how those could possibly break guix system ...
<vagrantc>backtrace: https://paste.debian.net/1306141/
<jpoiret>vagrantc: you're running from a local check-out, correct?
<jpoiret>if so you need `sudo -E` to keep the Guile load paths intact
<vagrantc>no
<vagrantc>from guix pull ...
<jpoiret>are you sure that `command -v guix` is the guix pulled one?
<vagrantc>well, rebooted and everything is fine now ...
<jpoiret>huh
<vagrantc>but this was not a fresh install ... e.g. there were previous pull generations and it correctly pulled the new version last time ...
<vagrantc>so the PATH should have been correct
<vagrantc>but who knows...
<jpoiret>a local checkout can run guix pull
<vagrantc>oh. maybe i was still in guix shell
<vagrantc>that would explain it
<jpoiret>imagine the following situation: you forgot you're in a ./pre-inst-env shell (if that's what you usually do), then guix pull and guix whatever
<vagrantc>i was in "guix shell --development guix guix emacs-no-x git less"
<vagrantc>not using pre-inst-env ... but still using old guix
<vagrantc>although ... guix upgrade and guix system build both seemed to work fine
<vagrantc>i've been doing this too long to still be confused pretty often :)
<lechner>Hi, packages.g.g.o shows 504 Gateway Time-out
<jpoiret>ghc's test suite takes wayyy too long
<apteryx>jpoiret: I confirm, the problem is not (define-public alias some-syntax); I get the same hang/loop with (define-syntax pkg-config (identifier-syntax (pkgconf-as-pkg-config-for-target (%current-target-system)))), after make clean-go && make
<jpoiret>eh :(
<jpoiret>I really don't know where that loop could come from
<Tedium>Does anyone know why guix system reconfigure will throw the error "guix system: error: failed to load 'config.scm': No such file or directory" even though config.scm does in fact exist in the current directory?
<jpoiret>none of the inputs of gnu-build-system should depend on pkg-config 🤔
<apteryx>there's some usage of pkg-config in %final-inputs, for gnu-make-final, but it's inherited, so at worst it should cause a module cycle, not a dependency cycle
<old>is there a quick way of testing latest glibc?
<old>without recompiling the world. Just want to test a program with new glibc
<apteryx>I'd try a graft
<apteryx>guix build x --with-graft=glibc=your-newer-glibc
<old>okay will try
<old>first starting with: guix build --with-latest=glibc glibc
<old>is there a way to tell guix to add pgp key? I often get an error when trying to build latest because I do not have the signature
<apteryx>if you 'guix refresh some-package' it'll use gpg to prompt for it usually
<apteryx>the UI is opaque but you need to provide 'y RET' as input when it pauses
<apteryx>as in, yes, fetch the key
<takev>Are all guix services extendable? Or just some of them?
<apteryx>just some of them
<takev>ACTION nods
<takev>Oh, I think I see, there is an "extend" field in the service types.
<takev>Trying to make sure I understand how extensions work. I am specifically looking at the oci-container-service-type. It has an extension method of append and a compose of concatinate. So, that means that if I were to extend it with a simple service, it appends the simple service's list of oci-container-configurations on the main oci-container-service-type, right?
<takev>Or, more accurately, what is happening behind the scenes is that it iterates over each simple service which is extending the oci service, and concats each entry of the simple service's list to a new list. After that list is created, it is appended to the oci service's value.