<vivien>So, I rebooted. I had no more funny files in /tmp, but still nautilus, epiphany and the system preferences dialog all froze, and I had no network connection this time (I’m connected via a wire). I had to manually run dhclient to report to you :(
<vivien>I’ve got a few new warnings: when I run dconf-editor, I get: "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by" and then a bunch of libraries: libproxy, gnutls, libgvfsdbus, libgvfscommon)
<nckx>jpoiret: Same re: zs. I'm not against adding uswsp, just about downgrading to it for *all* set-ups, even the IMO common/‘normal’ ones that don't need it. Involving user space at all is extra fragility and hibernation of all things should be stupid, simple, and reliable.
<nckx>There's no reason to leave the kernel when there's no reason to leave the kernel :)
<nckx><you can lose data if you mess up> This, but the ‘you’ who loses data is very likely not the ‘you’ who messed up, and now you have two people feeling terrible instead of one just feeling sheepish.
<nckx>Anyway, let's both go chase those zs. Night jpoiret; all.
<breatheoutbreath>I solved the gpg issue I ran into earlier. In `~/.gnupg/gpg-agent.conf`, I had specified `pinentry-program pinentry`, when it was necessary for me to specify the full path to the program.
<breatheoutbreath>so with `pinentry-program /home/joseph/.guix-extra-profiles/base/base/bin/pinentry`, pass and all my other goodies are working fine :)
<jab>breatheoutbreath: yeah. That is a slight annoyance with guix. many programs assume /usr/bin/program-name, which doesn't work in guix system.
<apteryx>breatheoutbreath: for what it's worth, it's supposed to work OOTB without specifying pinentry-program since commit c7af9d0b5ebaa1fdb08ff5d8a56004998bcd8103 (Mar 26 2020).
<apteryx>gnu: gnupg: Use ~/.guix-profile/bin/pinentry by default.
<apteryx>so I guess either you must specify the full path if you use pinentry-program; else not specify it at all
<apteryx>I personally have the former, since my setup predates said commit
<apteryx>uh: guix: offload: command not found\n hint: Did you mean `offload'?
<apteryx>could be that I'm running my own daemon locally with sudo -E ./pre-inst-env ./guix-daemon --build-users-group=guixbuild --max-silent-time 0 --timeout 0 [...]
<apteryx>vivien: the qtwebengine is used by jami-qt for the 'chat view'; mainly for rendering URL previews. Since URL preview is optional, I think it should be possible to make the dependency on qtwebengine optional too. That'd greatly shrink down the closure size of jami.
<podiki[m]>vivien: also seeing some odd GLIBC errors on core-updates-frozen (and not on Gnome) like `/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/pir0fgniik2ca63fmh8qq9piinz19k5k-libproxy-0.4.17/lib/libproxy.so.1)
<podiki[m]>Failed to load module: ~/.config/guix/profiles/desktop/desktop/lib/gio/modules/libgiolibproxy.so`
<apteryx>mbakke: I've refreshed the cufbc branch if you'd like to try e8a843a265 gnu: elogind: Update to 246.10.
<bdju>which browsers on guix work for video conferencing? I might need to do it soon for an interview. I've avoided having to figure it out until now
<bdju>qutebrowser audio is broken for me so I'll have to at least use icecat or something, but I don't know if webrtc and such work in icecat
<bdju>I'll grab ungoogled-chromium-wayland and experiment with stuff later
<rekado_>I see that LD_LIBRARY_PATH is still set even on Gnome 40.
<rekado_>podiki[m], vivien: have you upgraded your user profile to core-updates-frozen as well?
<rekado_>since yesterday I’m trying to build ungoogled-chromium…
<davidl>I am preparing a patch series and I am adding a package in python-web.scm but also dependencies in python-xyz.scm and databases.scm, however, the dependencies are not recognized when I try to build with ./pre-inst-env guix build -K ... even though the dependency modules are loaded from python-web.scm. This is the backtrace Im getting: https://paste.debian.net/1217024/
<davidl>I started from commit 0a42998a50e8bbe9e49142b21a570db00efe7491 from yesterday and have added 3 packages in individual commits since then, but cant add the final package python-flask-combojsonapi
<davidl>(which otherwise builds fine if all the dependencies would be put in the same module)
<efraim>davidl: I don't think you need the -L $(pwd) with ./pre-inst-env
<davidl>efraim: true. I added it for testing things when stuff didn\t work. I solved it now though: I have a separate guix channel with a package of the same name that I was trying to add, so after changing the package variable name it started working.
<dragestil>i just installed guix on a debian system, and i can't get rid of the warning about locales even though i installed glibc-utf8-locales and exported GUIX_LOCPATH
<vivien>rekado_, I’m trying, but there are quite a few packages that are failing to build and that I must disable.
<thorwil>dragestil: well, i gave up on trying to get rid of that warning long ago. to no ill effect. :)
<dragestil>thorwil: ah ok, well i thought the warning has something to do with the error when i try to guix install nss-certs: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'.
<dragestil>thorwil: yup, i tried all of that, but the problem persists
<dragestil>ah, ok, editing guix-daemon.service fixed it. it was Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8, and i changed it to Environment=GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
<thorwil>so foo-yc20 in the 1.3 release packaged aparently doesn’t implement LV2 like it is now. plugin won’t even be listed in ardour and ingen.
<thorwil>foo-yc20 git doesn’t build with faust-1. faust-2 itself fails to build here.
<thorwil>is the universe trying to tell me to forget about that one plugin? :)
<efraim>civodul: I almost have python-aiohttp test suite working. Adding python-pytest-6.1 brought the test failures down to 12
<jpoiret>what do we think about renaming root-file-system to file-system-/? I'm currently finishing the touches to the swap rework, and noticed that I naturally added the root file system to the list of dependencies of my swap file *twice*, so that might be something that people will mistakenly do
<jpoiret>since the root file system service doesn't follow the convention, this will prevent the service from starting up, but with the renaming it would work
<jpoiret>mhmmmm, just noticed that mapped devices needed for boot don't get their own stub shepherd service entry, so might need to add that as well...
<wonko-tmp>I've got a bunch of broken things that I suspect all come from bad/weird permissions on the filesystem. Things are not readable for "other" in /etc for example: hosts, hostname, timezone, shells
<wonko-tmp>I ran a system reconfigure, but that didn't change anything
<wonko-tmp>where could this come from? how can I reset those permissions?
<wonko-tmp>maybe my umask as root during the initial installation from a foreign distro?
<vivien>rekado_, and others, it seems that I have identified some packages that I can’t install on core-updates-frozen, because they don’t build or a dependency fails: deja-dup, deluge, gnunet, unison, yt-dlp (it has not been merged from master yet), frescobaldi, gnome-builder (it needs to be updated too), emacs-tuareg.
<pinoaffe>hi guix! I'm looking into packaging emacs-mentor (a torrent client for emacs based on rtorrent) - it can connect to "external" rtorrent processes, or it can launch and manage it's own rtorrent process - in the latter case it needs an rtorrent binary, in the former it does not
<pinoaffe>should rtorrent be a dependency of emacs-mentor?
<pinoaffe>and if so: by default, emacs-mentor looks for the rtorrent binary in PATH, should this be patched out so that the rtorrent binary location is hardcoded in the lisp source, or should rtorrent be a propagated input?
<vivien>What do you mean, external? If it is expected to run on the same machine, then I guess emacs-mentor can’t work without an rtorrent, so it is a dependency.
<pinoaffe>vivien: it can connect to rtorrent via a socket, via http, etc
<jpoiret>hmmmm, are there any disadvantages to %guile-static-stripped instead of guile-3.0?
<jpoiret>i'm wondering if we could simply launch shepherd in early userspace and let it handle everything 🤔 that'd be a nice experiment I guess
<ajarara>new to mailing lists, if I email the debbugs ID, does that 'bump' the thread?
<apteryx>sneek later tell mothacehe thank you for unlocking cufbc on the CI! What was it related to? Was it a Cuirass issue, or something else? I've recreated the branch, and Cuirass has yet to rebuild it it seems (~9 hours ago)
<vivien>I’m back from my core-updates-frozen excursion. I noticed a few failing packages, the impossibility to run a new guix system with a guix home from the other branch, and a weird thing where network manager creates a new interface for wired connections, but I don’t know if that is reproducible.
<apteryx>my substitute server started throwing: "guix: offload: command not found" errors as of late. I guess it needs an updated guix-daemon, but I'm puzzled as to what causes it. ideas?
<roptat>I think the problem is that we don't build with latex, and in that case, the temporary directory is set to whatever @TMPSPACE@ is set to, which seems to default to the current directory, but the directory doesn't exist after the build on guix
<roptat>BlackMug[m], if you choose the address yourself, it's unrelated to your MAC address
<roptat>your concern is about the address suffix when you switch network, which I think is fixed in many DHCPv6 implementations, and in Linux (when using RA)
<roptat>but that's not compatible with a static IP anyway, so your concerns are not valid for that case :)
<BlackMug[m]>i see, cant agree or deny been 10 years since last time i viewed ipv6 , it was piece garbage in all the ways
<BlackMug[m]>thats why i asked if they fixed it then yeah why not using it
<dissent>hey guys, currently unable to get past the tty. i'm attempting to go without gdm or any other display manager and log straight in through the tty. unfortunately when I invoke startx with xmonad it just goes to a black screen without anyway to backout or switch to another tty. any idea what could be the issue?
<apteryx>when building locally, the files sent are: ;;; (files-to-send/local-build: ("/gnu/store/0m0vd873jp61lcm4xa3ljdgx381qa782-guile-3.0.2" "/gnu/store/1q9118pw4d18ihj91csfilbg6x2x29am-module-import-compiled" "/gnu/store/ljs768gwp9dbd7y4y0ncyz4pdvsi8r92-remote-exp.scm" "/gnu/store/gai5i4ba2xf084big8h56q6pc0vwx2sj-module-import"))
<apteryx>so instead of sending the derivations, it sends the prebuilt items (...-remote-exp.scm instead of ...-remote-exp.scm.drv for example)
<Guest5195>Hi guix, I'm working on some home services. Some programs like oneko and workrave require the desktop environment to be running when they are started. How can I check for that?
<roptat>Guest5195, I think it's always the case? at least my understanding is that home services are started at user login, not at computer startup
<roptat>otherwise, it's probably in too early a dev phase to support that kind of thing
<roptat>(but help is always welcome, of course ;))
<gbrlwck>is there an easy and guixy way to resolve this?
<excalamus>I'm trying to wrap a new build of Plover with the QT_PLUGIN_PATH. It's failing on "In procedure string-append: Wrong type (expecting string): #f". I copied the modify-phases code from obs and updated the bin path.
<nckx>jonsger: Good question. AFAIK, and reading CUPS's load_ppds(), layout is entirely arbitrary as far as CUPS itself is concerned. It just scans all of model/ recursively.
<roptat>gbrlwck, from what I see, you have mes in your profile initially but not nyacc; you try to install it but it fails because of a conflict; you print mes's version; you try to remove nyacc but it's not present since it failed to install
<roptat>gbrlwck, did you try the hint? "guix install nyacc mes"
<roptat>gbrlwck, I think what happens is you installed mes in the past, and that propagates nyacc from the past; then you ran guix pull, updating the available packages (but crucially not your user profile), so you still have the old nyacc that you can't install with the newer nyacc
<roptat>gbrlwck, mh, nevermind, mes propagates an old nyacc even in the current version
<roptat>so I think you're not supposed to install nyacc, since it's already made available by mes
<gbrlwck>:) i only tried it, because mescc couldn't find it
<roptat>I was suggesting to keep guile 3.0 in your profile, and use a shell/environment for mes
<gbrlwck>i'll do that; for that's the way to do it
<philip>When running e.g. `guix build libgit2 --root=foo`, foo-0 gets linked to the :debug output and foo-1 to the :out output. Is there a good way to specify just the :out output and have the name used exactly? It would be much more convienient for scripting.
<podiki[m]>vivien: did you narrow down or resolve the GLIBC errors on c-u-frozen? (I'll investigate on my end later tonight)
<vivien>podiki[m], they happen if and only if I have a core-updates-frozen guix system with a master guix home
<podiki[m]>was that the only thing you had from master?
<vivien>Now I only have a guix system and a guix home, I don’t have packages installed.
<podiki[m]>maybe the same with me then (but not guix home, a package that must pull glibc?)
<podiki[m]>okay. probably core-updates-frozen is due to pull in master, though also c-u-f-batched-changes it looks like
<podiki[m]>(looking forward to getting to the full new guix release!)
<vivien>podiki[m], there’s no rush, I’d like to migrate when unison and guile-gi are fixed ^^
<vivien>At home, I have 2 machines: one with a large spinning disk, but too weak for heavy compilations, and one fast machine with a small SSD. The local network is fast, but connecting to the internet is slow. When I run guix gc on my fast small machine, I’d like to copy the deleted element of the store to the slow machine with lots of storage, so that I can download them again without connecting to the guix substitutes. Is it possible?
<DigitalKiwi>could you just set the large machine as a binary cache and skip the "copy when i delete" requirement and just 'always check big machine'
<vivien>DigitalKiwi, that could work if I could find a way to copy everything I build locally there automatically.
<apteryx>civodul: ,run-in-store (remote-eval (trampoline #~(uname)) s #:build-locally? #f) worked, too
<vivien>For instance, suppose I want to have the full texlive in the small-fast machine. If it’s not already present on slow-large, I will download it from guix substitutes, and that’s it. If I guix gc the small-fast machine, it will never get into the slow-large machine.
<civodul>vivien: you could manually invoke "guix copy", though that's not convenient
<civodul>there's no way to say "copy things i built locally"
<vivien>civodul, I tried to invoke guix copy with a bash glob (/gnu/store/*), but it fails because the command-line is too large. I have to do /gnu/store/aa*, then /gnu/store/ab*, etc.
<roptat>I don't remember who reported that but thanks, I just updated kicad's home-page