<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 :( <nckx>OK but have you seen ,bournish. <drakonis>you can invoke guile functions with it but not a lot in the way of advanced shell functionality yet <nckx>It's far worse^Wunbloated. <nckx>Unencumbered by features. <drakonis>unencumbered by the ability to do anything <drakonis>getting gash and gash-utils up to snuff for usage inside guix would be a killer app :V <nckx>I'm being unfair; it's better than nothing, and sometimes it's all there is besides a whole lot of nothing. <nckx>But yes ‘gash in initrd when’ absolutely yes. <jonsger>ah command back, its not XFS fault. Its just mine ^^ -> (flags '((create-mount-point? #t))) is a bad idea. you will see on your next boot... <nckx>I will happily stare uncomfortably long at random other people to help make this happen. <vivien>The sad thing is I can graphically log in as root and open nautilus, no problem. <jonsger>the best thing I corrected this syntax error for one mountpoint but overseen it for another ^^ <nckx>jonsger: It's a funny error (how did you get… there?) but worth a bug. These aren't strings passed to the kernel so there's no excuse for any run-time error. <jonsger>ehm. don't know. I looked into the manual, didn't read it really and thought thats how one should do it. no errors during reconfigure -> all right. reboot 5 days later -> uff... <nckx>Yeah. It's perfectly possible to validate all flags at reconfigure time (unlike mount options, where the best we can do is ‘is it a string? great’). <jpoiret>nckx: im gonna catch some zs but expect patch v2 tomorrow with some changes <jpoiret>only one swap-space record with priority and discard? fields, the rest is pretty much the same (will write doc tomorrow too) <jpoiret>hibernation support is the next goal <jpoiret>but that'll be a bit more *dangerous* as i'll have to change how the early userspace does its things + you can lose data if you mess up <ajarara>wait, you mean luks2 support for grub? Exciting! <bdju> http://ix.io/3CZP hit this issue during updates with openjdk. never seen it before. "Error decoding the received TLS packet." <bdju>network issue on my end maybe? I'll try updates again <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. <jab>drakonis: and nckx would it be worthwhile to port the scheme-shell back to guile again? <jab>it seems to be one of the "better" scheme shells... <breatheoutbreath>I have installed gnupg and pinentry declaratively in one of my profiles. <breatheoutbreath>Then, if I go ahead and run `guix install pinentry`, everything works as expected <breatheoutbreath>From the mailing list and IRC logs, I learned that I must specify `pinentry-program` in .gnupg/gpg-agent.conf <jab>breatheoutbreath: I wish I knew how to help you. I have up using gpg a while ago. I could get it to work for a while, and then not so much... <jab>sweet action, my opensmtpd service works for (service opensmtpd-service-type (opensmtpd-configuration)) now I've got to try stress testing it... <vivien>Maybe my problem is I’m running a guix home from master in a guix system from core-updates-frozen, I’ll bring the home to core-updates-frozen too to see if it persists... <vivien>(oh no I have to recompile qtwebengine for jami) <GNUHacker>how i update all my packages? guix package -u ? need I do guix pull before ? <raghavgururajan>rekado: Glad! I only updated and added new core libraries. mothacehe updated the main packages. Also, couldn't have done without the help from lilyp and maximed. <raghavgururajan>GNUHacker: FYI, `guix package -u` upgrades the packages in your user profile. To upgrade/reconfigure your system, you need to do `guix system reconfigure /path/to/config.scm`. <jab>vivien: why does it require qtwebengine? <jab>GNUHacker: awesome! welcome to the exclusive club! <jab>GNUHacker: I seem to recall that you need to do a "sudo -E guix pull" ... at least once... <vivien>jab, I don’t know, maybe the devs prefer it. <jab>vivien: ok. is the whole thing built on a web browser? Is that how it's displayed? <vivien>I don’t have that feeling, there’s no URL bar, back button, refresh, … or other web browser UI elements. <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>sneek: later tell civodul thanks for the better ergonomics of 'guix shell' ;-) <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 <dragestil>the warning is: hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and <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 <dragestil>hmm, after installing nss-certs, guix pull still complains about ssl cert being invalid <jpoiret>I think I had some certs problem when using guix for the first time on debian <rekado_>vivien: could you please share the list of packages that fail? It’s good to have a public record so we know what packages need our attention before the merge. <rekado_>I fixed all packages in my profile already, and a lot of bioinfo tools, but there are still some packages (dependencies of pigx) that are failing. <davidl>I sent in a patch series but accidentally sent it to bug-guix instead of guix-patches - does it matter or should I resend it? <mothacehe>apteryx: i fixed the core-updates-frozen-batched-changes evaluation in the CI <mothacehe>running make cuirass-jobs gives much more info than the Cuirass evaluation logs, something to fix here probably <thorwil>can anyone here build faust@2.5.23 successfully? <breatheoutbreath>apteryx: thank you - my setup is new, and I think I was getting the same issue even without `pinentry-program` specified in .gnupg/gpg-agent.conf ***wjc is now known as wonko-tmp
<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? <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: thanks for the better ergonomics of 'guix shell' ;-) <jpoiret>wonko-tmp: that is very possible, it's all a+r for me <jpoiret>wonko-tmp: is the umask on the foreign distro default? <efraim>civodul: well that was a rabbit hole, python-pytest-mock was propagating python-pytest-asyncio and that was causing the remaining test failures. tests pass! <wonko-tmp>how should I rebuild a system with correct permissions? system reconfigure didn't change anything <jpoiret>i think you're right, most directories created by init don't have an enforced mode <jpoiret>wonko-tmp: maybe we can patch this quickly and you could guix system init again? or i can give you the list of dirs that should have their perms changed <jpoiret>if they have a mode then it should be all good, but be sure to change the permissions of the others <jpoiret>although is the mode inherited by the directory it's in? <wonko-tmp>jpoiret: I can test init after a patch if that helps <jpoiret>if you can afford to that would be great <jpoiret>uhm but you mention umask is 0027 on guix and 0022 on foreign, that means that foreign grants by default *more* permissions than guix <jpoiret>how is umask 0027 on guix i wonder, mine is 0022 <jpoiret>logging in with root also grants 0022 <jpoiret>that might be it, rather than the foreign distro <jpoiret>wonko-tmp: are 'umask' and 'sudo umask' the same on your user account? <wonko-tmp>su -> umask is 0022, sudo su -> umask is 0027 <jpoiret>sudo looks at the current umask and ORs it with the default one <jpoiret>so when you sudo guix system reconfigure, it has the wrong umask <jpoiret>should we set a default umask when calling guix system commands? <jpoiret>or we could print an error and exit when umask is not 0022, instead of silencing the warning <jpoiret>i'll go eat something and look at that afterwards <bost>Hi. Does anybody know how to install pdflatex? Searching with `guix package --search=pdflatex` returns no usable information. <sneek>bost, bdju says: did you have audio when you tried qutebrowser? <bost>jpoiret: Indeed! The pdflatex *is* in the texlive-bin. Thanks! <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>i don't think it should be a dependency <jpoiret>if the user wants to run their own rtorrent, then they should install it alongside in their profile ***brettgilio7 is now known as brettgilio
***herlocksholmes1 is now known as herlocksholmes
<excalamus>hooray! FINALLY got icons to show up in the Plover gui. Looks like Qtsvg was missing <excalamus>so, I guess that would need to be listed as a propagated-input? <mbakke>excalamus: it's better to 'wrap' the executable with the required variables (QT_PLUGIN_PATH?) instead of propagating <mbakke>if the package uses cmake-build-system, you can switch to 'qt-build-system' to make the wrapping happen automatically <excalamus>export QT_PLUGIN_PATH= and restarting Plover, there are no icons, so I assume that's what needs wrapping <excalamus>so, my question is, how do I wrap the executable with the environment variable? <davidl>excalamus: there is a procedure simply called wrap-program <excalamus>okay, I see it in some other definitions. Thanks <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) <ajarara>no, the mailing list to contribute patches <DynastyMic>Hi, I'm trying to fix the latex2html package that is already in gnu packages <DynastyMic>However when trying to actually use it (i.e., latex2html file.tex) <DynastyMic>it brings the following error: Error: '/tmp/guix-build-latex2html-2021.2.drv-0' not usable as temporary directory. <roptat>DynastyMic, that's an interesting error message <roptat>looks like it records a temporary directory name at build time? <roptat>DynastyMic, maybe try to run with "-tmp" option? <roptat>mine is even less happy: "Error: No such image type ''." :/ <apteryx>uh openssl@1.1.1l: can be upgraded to 3.0.0; is there a reason we stick to 1.1.1 on core-updates? <DynastyMic>roptat, yeah that was the mistake I'm trying to fix <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. <DynastyMic>when using -tmp, drops the following: Error: 'try.tex' not usable as temporary directory. <vivien>I have yet to report guile-gi failing and frescobaldi, but I want to try and patch them first. <roptat>DynastyMic, you need to say something like -tmp=/tmp <roptat>(well that's my vague understanding of the code ^^') <talos>Hi guix! Is there any official Guix dev here? Just a quick social media related question... does Guix use Mastodon any? <vivien>Also, I’d like to have gnome-builder, but it is a pain to update because it requires the latest version of glib. <apteryx>3.0.0 will probably break many things that'll need to be ironed out in time <roptat>talos, there's no official mastodon account, but a lot of us are on mastodon <talos>As in, do they have an account on there I can follow lol <talos>Well, that answers that! Just wondering lol <roptat>apteryx, this morning I saw some CVE on webkitgtk, tried to fix it and in the end we need a newer version of glib that on master or wip-gnome <roptat>talos, #guix receives one or two toots a day <vivien>talos, I think you can set up a CI server and notify you on mastodon, if you want to socialize with bugs. <vivien>Otherwise, look at #guix on big servers, there are a few people talking about it :) <roptat>DynastyMic, maybe we can add a phase to fix that; looks like we want to fix $TMP in bin/latex2html <roptat>I have no idea why they think the build directory is a good temporary directory instead of $TPMDIR or similar... <roptat>that would be ideal if you can make and send a patch <roptat>maybe we should discuss it with upstream too <talos>I'm on 3 mastodon instances, might as well follow the #guix hashtag on all 3 lol <roptat>DynastyMic, ideally you would create a patch for latex2html, to read $TMPDIR (the environment variable) by default and put it in $TMP (the perl variable) <roptat>but looking at the code, we could as well set TMPSPACE at configure time, though I'm not sure how <jonsger>nckx: do you know if the path under which PPDs for cups are saved is arbitrary? or is cups expecting something like share/cups/model/MANUFACTURE/name.ppd ? <roptat>so maybe just add #:configure-flags '("TMPSPACE=/tmp") in the package arguments <apteryx>and it has webkitgtk@2.34.0 (updating to 2.34.1 just now) <roptat>is it on savannah? I don't see it <apteryx>my git push yesterday late night must have failed or something <DynastyMic>still the same error (i.e., Error: '/tmp/guix-build-latex2html-2021.2.drv-0' not usable as temporary directory.) <roptat>yeah, it doesn't seem like you can set TMPSPACE in any way from the configure script <roptat>I think it's our best option; maybe also send a bug report to bug-guix, and link to your issue with upstream <roptat>don't feel embarrassed, it's ok :) <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 <silicius[m]>Is there a list of all the env variables that a Guix user should declare in their shell profile? <DynastyMic>oh yeah, since guix uses the /gnu/store and all that jazz, right? <roptat>DynastyMic, well not necessarily, it's just that it builds in /tmp/guix-build-... and that's only a temporary directory that disappears after the tool is installed <roptat>so, most distros would have the same issue ***cbaines_ is now known as cbaines
<roptat>unless we're doing something completely wrong, which can also happen ^^' <DynastyMic>thank YOU, you're smartest guix user I've ever met :p <apteryx>roptat: fyi, I also have a python-3.10 local branch but it won't make it for the next release -- it causes a couple silly issues with a deprecated namespace, got stuck on mozjs <roptat>ok, I didn't plan to work on this anyway <roptat>I want to focus on OCaml for a bit, I'd like to get rid of most ocaml4.07-* packages, and add ocaml 4.13 <civodul>lemme know if the interface makes sense <civodul>also on the "links" thing, which i don't know how to use <roptat>I don't think the links thing is necessary <roptat>well, you probably need it to set them up <apteryx>weird, while building a guix in a derivation for 'guix deploy' is outputing: In procedure load-thunk-from-memory: ELF file does not have native word size <civodul>the code already does (link-set device #:up? #t) <roptat>so one issue I can see is that it probably won't work on the hurd <civodul>but i thought maybe there are some cool secret things to be done with links? <roptat>unless they implement netlink too <civodul>but that's okay, we can still provide that interface <roptat>yeah, you can create a veth pair, and switch one end to another network namespace <roptat>then you can get two network namespaces to communicate through the veth interface <roptat>that's how we should reimplement networking in containers <civodul>ah, see? i knew there were cool things of that kind to be done :-) <civodul>does this interface allow us to do that? <roptat>you can create the veth pair, but I don't have anything to manipulate network namespaces <roptat>unfortunately my server is down again :/ <roptat>civodul, the example I have in the manual is (link-add "v0p0" "veth" #:type-args '((peer . "v0p1"))) <apteryx>seems to be building for i586-pc-gnu of my remote machine, although I haven't specified anything for that: warning: [...]: program "i586-pc-gnu-strip" exited with non-zero exit status 1 <roptat>this creates a veth pair v0p0 and v0p1 that communicate with each other <BlackMug[m]>BlackMug[m]: anybody facing this error when upgrading? <roptat>BlackMug[m], can you share the log file it created? (guix should have printed a message telling you where to find it) <apteryx>uh, nevermind, that must be for my child-hurd service :-) <civodul>roptat: nice; could you turn that into a commented example for the manual? it'd be great to have that! <roptat>civodul, it's already in the manual, what do you need more? <roptat>civodul, about the patch to allow cross-compilation, is there anything I can do in my repository? <BlackMug[m]>@civodul IPv6 has privacy issues, did they solved? or not important <zimoun>civodul, this moring I came with the idea to add an option to “guix describe” (for instance --archive) to send a save request to SWh for all the channels. WDYT? <BlackMug[m]>roptat: the process killed due to signal 9 , 1 dependency couldnt be built <roptat>BlackMug[m], in the context of a static IP anyway, there's no more privacy concerns with IPv6 than IPv4 <roptat>zimoun, I think you can achieve the same with guix lint -c archival <roptat>oh you mean channels, not packages in them? <roptat>BlackMug[m], weird, maybe try again, or maybe it's an oom issue? <zimoun>now, one has to open my browser blabla. <zimoun>The workflow for scientific folk would be: “guix lint -c archival” and “guix describe --archive”, then publish manifest.scm and channels.scm. Bang! Reproducibility for ever (on principles :-)) <BlackMug[m]>they solved them? MAC address and many stuff where horribly linked to the uniqueness of the IPv6 <jpoiret>hmmm, does anyone know how to add scissors lines in emacs when writing mails? <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>BlackMug[m]: you could try adding some swap, and after that's resolve configuring some zram. <apteryx>you'll need to be very patient for the build though <BlackMug[m]>i thought guix use substitute when using its own distro for its own packages <vagrantc>anyone else notice python-numpy failing on core-updates-frozen? <lfam>I think it's totally fine, but I don't want to push it without a consensus <civodul>zimoun: re "guix describe --archive", why not; "guix describe" is not the best place for it, but i don't have any other idea <civodul>lfam: b2sum isn't yet in master, right? <vagrantc>lfam: wouldn't that still cause issues with offloading? <vagrantc>lfam: the issue is building for the local CPU? and if you offload to a machine with a different CPU ... wouldn't that ... cause issues? <lfam>So, I guess the patch would also need to do '#:local-build? #t' <lfam>I've never offloaded so it's not easy for me to answer questions about offloading <podiki[m]>rekado_: I have updated my main profiles, but something weird in one of them (some package I need to remove maybe); I do have one set I bring from master though <zimoun>civodul: initially, I thought “guix pull” but it is worse. Then “guix describe”. Otherwise, a special under “guix git”. For insance “guix git archive-channels”. WDYT? <podiki[m]>if batched-changes is built on the CI tonight, I will try that as well <civodul>lfam: just replied; and yes, you need to disable offloading as well <GNUHacker>hi, Ive installed #icecat in guix system from guix package manager, how can I install locales/translations <civodul>zimoun: maybe "guix git archive"? could apply to any Git repo <lfam>I will benchmark `guix hash` and `cksum` :) <lfam>Really, I'll probably use b3sum, which is incredibly fast <lfam>What takes b2sum 12 seconds, b3sum needs ~1.5 seconds <civodul>and does it actually compute the same thing? :-) <lfam>It's a different algorithm <lfam>But b3sum is a Rust program, which is still kinda poorly-supported in Guix <lfam>I think efraim would understand what I mean :) <lfam>I guess it's kind of aspiration hyperlinking? <lfam>`guix build guile-gcrypt` ftw <civodul>but they're not actually all listed :-) <civodul>so you really have to check (gcrypt hash) <civodul>(i went to Geiser, which helpfully shows available options for (hash-algorithm ...)) <lfam>Berlin is garbage collecting <zimoun>civodul, you mean “git archive <url>”. For instance, it would become “guix git archive $(guix describe -f recutils | recsel -C -P url)” for saving the current channels. <apteryx>arf... guix deploy: sending 298 store items (4,110 MiB) (because it won't know to copy /gnu/store/kbghqa2sgy630bi2p6y575kwz0v4lr08-remote-exp.scm.drv when using #:build-locally? #t) <apteryx>that gexp is basically just: (primitive-load "/gnu/store/6nhnk471027c6wdd2v0ygcv3in4g0219-switch-to-system.scm") <apteryx>s/#:build-locally? #t/#:build-locally? #f) <efraim>ah, rust. I planned on overhauling all the inputs before packagecon but that's probably a bad idea <lfam>You mean, overhaul how inputs are specified? <efraim>I was going to shove cargo-inputs -> inputs and cargo-development-inputs -> native-inputs and then go around removing things and skipping tests until I made it work again <lfam>It would be nice... I seem to remember that it's the way it is because there were a lot of dependency cycles <lfam>But, we've worked around cycles before, within the regular dependency specification system <efraim>and we had no way setup yet to use the sources, but now we're generating our own crates pre-patched with references to our jemalloc and stuff so it should just work <efraim>I still have to try it, but using $GUIX_ENVIRONMENT/share/cargo/something as a local cache is something I'm aiming toward <civodul>apteryx: re #46756, do you have a backtrace showing current line numbers? <apteryx>but it seems somewhere in (guix ssh) it forgets on filter out the switch-to-system gexp file <apteryx>civodul: could it be that export-paths in (guix ssh) need its #:recursive? argument set to true? <apteryx>haven't pk'd anything yet, but that's one thing I want to look at <lfam>efraim: Sounds promising! <mikolajw>Please update project URLs of packages kicad, kicad-doc, kicad-footprints, kicad-packages3d, kicad-symbols, kicad-templates to kicad.org <mikolajw>The project has moved to a new site kicad.org in 2020 <mikolajw>Dick Hollenbeck, former project leader, has betrayed the community and sold kicad-pcb.org to a third party <mikolajw>The site is fake and probably used to host malware <vivien>I don’t know anything at all, but are we sure it’s not the opposite? <mikolajw>You can confirm that by checking our mailing list and forums. Several independent sources: digikey, hackaday, adafruit, also wrote about that <vivien>Why do you say, "betrayed the community"? Reading that email, it looks like he forgot to renew the domain name. <vivien>Same for both gitlab.com and github.com <pkal>Hi, does anyone know how far back does time-machine works? <pkal>In the sense of can I build packages from 2013 or something or has something changed since then? <jab>roptat: I was born in 1991...what does that say about me? :) <pkal>roptat: Is there any other way to use older package versions besides time-machine? <roptat>pkal, no easy way, but you could copy the package graph from back then and build it with a recent guix <roptat>or create your own packages, use transformation options... <vivien>I thought guix past was made to do that <pkal>I am asking because I'd like to use Guix via sourcehut CI system to test Emacs packages on older versions. I am not sure if copying packages would work well in that case? <mikolajw>vivien: he did not, the domain was due to renewal in 2023 to my best knowledge <Olivetree>Also, dvtm is broken for me: dvtm.info is not anywhere in my system <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 ;)) <jpoiret>did anyone receive my mail to bug-guix? <roptat>jpoiret, if it's your first message it can take up to 24 hours for moderation to validate it <roptat>I don't think we've received it yet, unless your name is very different from your nick <jpoiret>oh yeah, i forgot bug and patch weren't the same list <Guest5195>roptat My oneko services don't render to the desktop when I log in, I don't see them until I restart them. I suspect sleeping for a little may help. <Guest12>I'm back. Sleeping for a second works. <apteryx>civodul: the derivation sent is actually buildable; so it looks like something depends on it before it actually is built/finished building ***iyzsong- is now known as iyzsong
***potatoal- is now known as potatoalienfo13
***potatoalienfo13 is now known as potatoalienof13
<apteryx>appears related to the trampoline procedure in (guix remote) <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. <excalamus>I'm not sure how to introspect the code, so it's not clear where it's failing and what precisely is going wrong. <vivien>excalamus, if QT_PLUGIN_PATH is unset, then maybe getenv returns #f and wrap-program concatenates it with something else. <vivien>I see no reason to believe QT_PLUGIN_PATH is set. You might need to set it up yourself. <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" <gbrlwck>roptat: don't you think guix finds two different versions in my (user) profile? <roptat>maybe we could make the hint a little more obvious, because understandable "upgrading mes" when "mes --version" says it's the latest version is confusing :) <vivien>excalamus, the syntax is (format #t "Hiiii\n") <nckx>excalamus: (format #t …) to print, (format #f …) to not. <vivien>The #t is for "print to standard output) <gbrlwck>roptat: the hint doesn't help (i get the same hint again) <nckx>(format "…") is deprecated. <apteryx>a pity; what beauty is there to (format #f ...) ;-) <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 <vivien>excalamus, maybe you need to add Qt to your inputs, and compute the plugin-path by appending the correct suffix to it. <roptat>I see that this old nyacc uses guile 2.2 and not 3.0, so I'd install guile-2.2 in the profile, then guix should set some new environment variables for you, and it might be able to find nyacc <roptat>ideally, you'd create a separate environment for that, if you already have guile 3.0 in your user profile <gbrlwck>oh dang. `guix install guile@2.2` downgrades my guile :( <roptat>using the new guix shell, I think you want something like "guix shell guile@2.2 mes", that'll drop you in a shell with the right environment variables and hopefully a working mes <nckx>apteryx: Agreed, (display (format …)) was far more readable than a completely arbitrary yes!/no! (…to what?). <roptat>if you don't have guix shell yet, then that's "guix environment --ad-hoc mes guile@2.2" <gbrlwck>it even works with just `--ad-hoc mes` <roptat>--ad-hoc mes doesn't work for me though <roptat>I get the same error message as you <roptat>so I bet you can even use mescc from your profile now :) <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 ^^ <apteryx>any idea what could be wrong with trampoline in (guix remote) in the context of remote-eval (when it is actually remote) ? ;-) <podiki[m]>civodul: will read! been meaning to chime in on that thread as a newer user/contributor <civodul>apteryx: nope; could you show the (possibly redacted) contents of "/gnu/store/rdzgpp9vq6mbvih3q12m8sq3qy50861z-remote-exp.scm" ? <apteryx>perhaps caused by the use of local-file in the config? <apteryx>a strange thing is that the remote-eval seems to occur twice <civodul>that expression comes from machine-boot-parameters in (gnu machine ssh) <apteryx>e.g. guix deploy: sending 0 store items (0 MiB) [...] gets output twice <apteryx>I've commented out allthe local-file usages from my system config, retrying <civodul>AFAICS, that remote-exp.scm should be sent <civodul>you added pk calls in remote-eval, right? <civodul>can we reduce the problem to a remove-eval call? that'd be sweet <civodul>if i do: ,run-in-store (remote-eval #~(uname) s) <civodul>building path(s) `/gnu/store/7sg8rx4xzff28j242rb7fqq10f4g9hwk-remote-exp.scm' <civodul>sending 1 store item (0 MiB) to 'xyz'... <civodul>could it be GC was running on the target machine? <apteryx>i can reproduce at will with my config <civodul>built-locally? = #f is kinda untested, don't do that <civodul>oh but that's precisely what you're donig? <civodul>i didn't know one could actually choose :-) <apteryx>(build-locally? #t) at the level of the machine definition <apteryx>otherwise it shuffles 4 GiB on the network <apteryx>(probably most of it attributable to the hurd-vm-service-type) <civodul>so (build-locally? #t) is fine, it's the default; #f is not <apteryx>ah, yes, that's what I meant of course <apteryx>I'd like to use (build-locally? #f), so that my powerful offload machine builds its config itself <civodul>i'd need to wrap my head around it because i'm not sure why (build-locally? #f) doesn't work <apteryx>yep, that's what doesn't currently work <apteryx>but the code seems to be ready for it <apteryx>so it's probably something small, or so I hoped :-) <breathe>Hello! I set up some mcron jobs in ~/.config/cron/ and I am able to execute them by invoking `mcron -d`. <breathe>What's the recommended way to invoke `mcron -d` on startup? Should I put that line in my .bash_profile? <civodul>apteryx: at first sight ",run-in-store (remote-eval #~(uname) s #:build-locally? #f)" works ***breathe is now known as breatheout
<drakonis>this update cycle is turning out to be quite fruitful ***pkill9_ is now known as pkill9
<apteryx>civodul: what is the 's' in your expression? <civodul>a session as returned by open-ssh-session ***breatheout is now known as breathe
<apteryx>civodul: the snippet works here as well <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 <drakonis>the guix cli can detect the presence of such servers on the network and instead pull from them