IRC channel logs
2024-12-03.log
back to list of logs
<ddaglenn>Sorry, where would I go to ask these types of questions? <vagrantc>ACTION and surely many others wonder about this awkward policy <Kolev>vagrantc, nah, you gotta draw the line somewhere. I'm in favor of the policy. <vagrantc>Kolev: i am in favor of the policy to be strict about non-free software, but the the "don't speak of it" part of it is astoundingly awkward. though i get why it is that way and do not see a definitely better way without lots of other problems. <civodul>there is no “don’t speak about it” policy :-) <civodul>ddaglenn: you can check #nonguix to get more info about the nonguix channel <vagrantc>civodul: so it is fine to post links or describe exactly where to get non-free software? :/ <x8dcc>Hello, how do I allow "non-forward updates" (temporarily)? <vagrantc>ACTION never really understood where the line is drawn <civodul>vagrantc: sure, it’s just that past a point, people should go to #nonguix or similar, because that’s a separate project <unmush>(the name is a little misleading; it also includes allowing "sidegrades") <ddaglenn>Ahhhh, I see that now at the top. I guess my question more broadly is, how would I handle installing "free software" that may not be in the guix repository but still use the guix software system? <newguixuser>Hi, I am brand new to the Guix system. It was working fine for the first few days, but now, whenever I try to do anything like upgrading packages, I get a 504 error and a message saying "error: corrupt input while restoring archive from socket" is this a common issue? If so, how can it be fixed? <vagrantc>yes, that is the clever way to rethink it :) <unmush>ddaglenn: channels, see chapter 6 of the guix manual <Kolev>civodul, vagrantc - I didn't know I was allowed to say nonguix here. Thanks for the clarification. <vagrantc>there are also a few ways to do one-off packages, though channels are probably the most flexible <ddaglenn>Years from now, when I've become a guix expert, I will look back at my first interaction with the guix chat and laugh at how my first question blatantly violated the spirit of the group :] <unmush>newguixuser: sounds like your substitute servers are having issues, if you're okay building from source instead you could pass --fallback <vagrantc>ddaglenn: it is a reasonable question :) <Kolev>ddaglenn, you're welcome here! Glad to have you. <newguixuser>Is there a link that I can use to change my substitute servers? <ieure>newguixuser, Substitute servers are part of your operating-system configuration. You need to edit the configuration and `sudo guix system reconfigure'. Do you know which server is giving you 504s? <vagrantc>you can also pass --substitute-urls="server1 server2 server3" <ieure>newguixuser, Your specific issue isn't common, as far as I know, but Guix servers being flaky, in my experience, is. <apteryx>so hm, I have a (guix build parsers rfc) module that I added to the #:imported-modules of python-build-system; I also have a #:use-module for it in (guix build python-build-system.scm), but for reasons that escape me, its public API is not available during a build (sanity-check phase fails with: Unbound variable: parse-rfc2822-file). <sneek>apteryx, you have 1 message! <apteryx>w.r.t the above unbound variable, is there some obvious I'm missing? <apteryx>rekado: hi! great that you could fix it. I have lined up a few package upgrade/fixes on python-team trying to build my way to python-biopython (it now builds on my local branch). <apteryx>infusing some more value in the Python build systems while I'm at it, should hit guix-patches soonish, after I've rebuilt lots of stuff. <apteryx>re my silly unbound error; I had defined parse-rfc-2822-file but exported parse-rfc2822-file. <apteryx>another bite from guile's gleefully exporting unbound symbols I guess ^^ <vagrantc>ACTION tries "guix build --dependents" for the first time <wakyct>hi, this might not be a guix issue, but is anyone using a bluetooth headset with mic successfully? I'm at a loss because everything connects and my headset is showing headset and handsfree in the BT profile, and I even see the capture sink in pipewire (using Helvum). But I can't get the mic to work in any program. <wakyct>the output goes to the headset OK though <wakyct>is there some trick or plugin I'm missing? <wdkrnls>Dear Guix, can I run guix system reconfigure from time-machine? <raghavgururajan>In the past weeks, IceCat has been crashing out of the blue with the error "Exiting due to channel error." on Guix System. <Rutherther>sneek: later tell wdkrnls: you can run everything from guix using time machine, including system reconfigure <wakyct>wow it works. It's nice when that happens. <mccd>Is there any kind of sandbox-capability built into guix? Something akin to enter repository and guix shell, but don't allow the shell to touch anything outside the repo? <Rutherther>mccd guix shell has container flag that will do that. You can mount other paths if you needed as well <fanquake>Hi. Trying to guix pull this morning, and it looks like the sha256sum for guile-bootstrap-hash might have been incorrectly changed in 4d9c5984fee481d74c2f504094b4797bbb4104d4 ? <civodul>so! ‘guix publish’ keeps respawning on ci.guix, which makes things unreliable <dariqq>hi, tried to reconfigure my system and it is failing to build the ath9k firmware with -Wimplicit-function-declaration erros. Also why is this using gcc-14? <efraim>we've switched the cross-gcc to gcc-14 <csantosb>I'm unable to reproduce in my laptop ... <csantosb>Running `guix system image --verbosity=0 --image-type=qcow2 --image-size=16GB --save-provenance system.scm` gives <apteryx>I'm using (define-deprecated/public-alias %python-build-system-modules %default-python-imported-modules), but users of the deprecated %python-build-system-modules throw syntax-transform unexpected type, e.g.: In procedure filter: Wrong type argument in position 2: ((guix build cargo-build-system) (guix build cargo-utils) . #<syntax-transformer %pyproject-build-system-modules>). Ideas? <csantosb>I guess this is related to hardware where they build images under sr.ht, right ? <apteryx>anyone else using librewolf on gnome? <apteryx>when I click on a link, I get some notification 'page is ready' or similar; I'd rather the browsers open directly instead <apteryx>csantosb: are you trying to reproduce from the same exact guix commit that sr.ht is using? <Deltafire>apteryx: i get that with Gnome Files, if the directory is already open somewhere. It's quite annoying, it should bring the window to the front instead <csantosb>I understand the problem comes from `guix build ath9k-htc-ar9271-firmware` <dariqq>efraim: I see, this seems to break the %base-firmware packages <apteryx>Deltafire: ah! some it's a global behavior in GNOME. Probably configurable, let's see <Deltafire>links seem to open okay in IceCat, not really used Librewolf <apteryx>I've read if one single application has the 'stay on top property', even if it's minimized, it would cause that behavior <csantosb>For the record, in case anyone manages to reproduce, former system image is run in a virtual environment <csantosb>With virtualization features: virtualization: AMD-V, Hypervisor vendor: KVM, Virtualization type: full <janneke>ACTION works around SIZE_MAX problem for gcc-cross-boot0 <civodul>anyone looking into the guix.gnu.org certificates? <janneke>ACTION pushes workaround to core-packages-team <apteryx>that sounds like the next nice thing to investigate and fix for good on the CI... it's reoccuring at an annoying rate <z572>It appears that the elfutils cross-compilation has now failed <civodul>Carlo submitted a patch for DNS-based challenges on guix-sysadmin <civodul>but i’m not super qualified to apply/test it <apteryx>I think none of us are, which explains the current situation, haha :-) <apteryx>IIRC, it was working around the issue rather than really addressing it. Well, if it works, it's an improvement. <apteryx>the real underlying issue (according to them, IIRC) being there are two competing machines trying to get the same cert, failing the http challenge or something something <mjw>z572, I maintain elfutils upstream, but didn't know it could be cross compiled (but why not, might be useful) <civodul>apteryx: yes, it addresses this particular issue <civodul>and would allow us to have redundancy for the web site <civodul>like guix.gnu.org pointing to both machines <apteryx>the website keeps running when berlin goes down <apteryx>changing topic, is it worthwhile throwing srfi-35 conditions instead of using 'error' in the build code? Does it get shown any nicer in the ouptut? <apteryx>ACTION tries with srfi-35 conditions <z572>mjw: error: ‘__pread_alias’ writing 58 or more bytes into a region of size 10 overflows the destination <z572>I think it's because our elfutils are a little old <mjw>z572, which version, which src/line? It does sound slightly familiar <efraim>it looks like 'guix build syncthing --system=armhf-linux --tune=armv6' works <mjw>ah, 0.187, yeah, that is old, latest is 0.192. <mjw>If you want to just fix that error, the above commit probably will <mjw>z572, btw. It is missing bzip2 and zstd support, you probably want the devel packages as inputs. <mjw>elfutils Version 0.189 "Don't deflate!" will support zstd also for libelf <mjw>But really, you want 0.192 :) <janneke>ACTION reshuffels commits on core-packages-team and fies typos <janneke>ACTION uses a new, nice and "fast" keyboard -- but typos... :( <apteryx>(and the visible type has a meaning) <apteryx>pretty verbose on the coding side though, which I'm not too big of a fan (yet?) <apteryx>ACTION now to fix all the problems found with that new validate-version python phase ^^' <z572>mjw: i think this needs to be updated in core-packages-team <mjw>z572, another advantage of upgrading the version, we stopped using ChangeLog files but put the ChangeLog entry in the commit message now :) <janneke>ACTION sends long overdue mail for teams/hurd team <civodul>i’ve seen reports about the failing ath9k-* package builds (cross-compilation) <civodul>also: uncaught throw to %exception: (#<&inferior-exception arguments: (match-error "match" "no matching pattern" "powerpc64le-linux") inferior: #<inferior pipe (0 1 1) 7f6bd777ad80> stack: ((#f ("ice-9/boot-9.scm" 1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) (raise-exception ("ice-9/boot-9.scm" 1684 16)) (arguments ("gnu/packages/hurd.scm" 633 28)) <janneke>civodul: yeah -- and i managed again to do a brown-paper-bag commit -- accidental touch of aarch64 %bootstrap-guile-hash :(, oh well... <janneke>civodul: ah, yeah that could very well be the switch to cross gcc-14 <janneke>i guess we need some default for non-hurd arches? <civodul>for the firmware, it’s “implicit declarations” error <civodul>not sure why we’d get them with gcc 14 <janneke>they even suggest creating a wrapper for it -- in the end that's what i did for gcc-final <civodul>janneke: i tried -DCMAKE_C_STANDARD=99, which translates to -std=gnu99 <civodul>hopeing that “implicit declaration” wouldn’t be an error <janneke>yeah, i believe you really need something like "CFLAGS=-g -O -Wno-implicit-function-declaration", (or even -fpermissive, but yeah) <janneke>but thanks for trying nicer solutions, i've tried a number of things too <janneke>patching configure might be another option -- assuming that configure fails <civodul>looking forward to a qa.guix kind of tool that would truly guide us pre-merge <fanquake>Seem to be running into a different issue running guix pull on aarch64 <csantosb>civodul: please ! I think this is more than necessary <csantosb>`guix time-machine --commit=58a134224e -- build ath9k-htc-ar9271-firmware` is broken <csantosb>whereas `guix time-machine --commit=ef15b48379 -- build ath9k-htc-ar9271-firmware` is not <civodul>csantosb: fixed in 6d34e751b545120fd4455cb6d718d02c9188d874 <civodul>csantosb: speaking of which, did yo look into fj.el? (i think we mentioned it the other day but i didn’t see your reply) <civodul>csantosb: speaking of which, did yo look into fj.el? (i think we mentioned it the other day but i didn’t see your reply) <csantosb>civodul: not by now, as I'm not planning to use codeberg more than this at this point <csantosb>I'm an addict to sr.ht, I'm afraid; if someone knows of a good client, please ! <csantosb>We have sr.ht/~akagi/srht.el as a frontend to hut, but this is rather basic <z572>security-updates: Last repository check: 27 hours ago. <csantosb>civodul: I confirm that ath9k-htc-ar9271-firmware is fixed, thanks ! <z572>Why does cuirass always forget to check the repository? <csantosb>And sr.ht guix image is back to life again 🥳: builds.sr.ht/~csantosb/job/1380288 <civodul>z572: it does not forget: this jobset is set up to be checked once per day <civodul>though you can trigger it with a magic POST request <civodul>csantosb: curious about your usage and feedback about sr.ht <civodul>i looked at tickets at sr.ht and was unimpressed <csantosb>civodul: I'll try to write something about <noe>is glibc available to use in tests or does that break other platforms than x86? <janneke>fanquake: and sorry about all the fallout <civodul>noe: it is, but only in tests that require access to a full-blown install, like most in tests/pack.scm <noe>great, just sent the fix for the AppImage tests <noe>thank you for reviewing :) <z572>Should we use (raise (condition (&package-unsupported-target-error (package pkg) (target target)))) instead "UNSUPPORTED_SYSTEM" ? <civodul>if it’s caught from (gnu ci), then yes <fanquake>janneke: no worries. Thanks for the quick fixes <csantosb>This is probably an old topic but, do we have any policy about releases ? <csantosb>Releases eases users' life ... and are a good strategy to communicate <civodul>csantosb: yes, there’s consensus that this should be done, but structurelessness causes each one of us to look at the others in the hope someone will step up <civodul>we need to break out of that vicious circle :-) <csantosb>(my use case is running tests on a guix image; would help a lot to do it on a release image instead) <gabber`>would it make sense to tag a commit as a release around - let's say - every 10000 commits? <gabber`>v1.3.0 was at 76971 commits, v1.4.0 was at 105808, we're now around 150k <janneke>ACTION builds gcc-final on core-packages-team <ray1729>gabber: is there a pre-release freeze period where stuff gets widely tested before a release is tagged? <gabber`>ray1729: not the expert in this round but IIRC there were some "signals" (like big branches being merged when they finally built successfully) before tagging commits as releases <csantosb>emacs's releases model seems good to me (semver looks like the path to go) <gabber`>janneke: yesterday i failed installing GNU/Hurd due to netdde failing, i figure this has been taken care of? <gabber`>nice! i'm gonna give the installer another try then! <gabber`>ACTION super stoked to finally enjoy the HURD on hardware <janneke>gabber`: no promises, but netdde was updated to latest <janneke>what kind of problem did you encounter? <dthompson>hope this isn't *too* off topic but spritely just launched its first supporter drive. we're big users/promoters of guix and we're also involved in projects to advance guix such as the goblins+shepherd initiative. if you like what we do, please consider a donation! https://spritely.institute/donate/ <gabber`>janneke: the installer was interrupted due to netdde failing to build <janneke>gabber`: hmm, i haven't done anything in that area... <gabber`>i think civodul did with commit d897f1b4 <gabber`>and ci.g.g.o reports a successful build from a couple of hours ago <PotentialUser47>I assume this is just an issue with server and nothing I need to address on my end? <ieure>PotentialUser47, Yes, substitute server fell over and died again. This happens often. <efraim>rekado: I hope your hands didn't get tired typing ~2600 commit messages ;P <trofi>sepeth: ^ . _LDFLAGS are usually for things like -L paths, and not library names themselves. i think _LIBS is a preferred way to add libraries to link list. <rho`n>hello nutcase, did you figure out your home shepherd service issue? <trofi>On top of that I still see `nix/local.mk: $(SQLITE3_LIBS) $(LIBGCRYPT_LIBS)` using `LIBGCRYPT_LIBS` without a corresponding AC_SUBST. <janneke>gabber`: that would be nice, in that case we're still an effective team :) <rekado>efraim: I actually did write a few hundreds of them. <rekado>my hands are fine (thanks to Emacs registers), but it was rather tedious to hunt down build failures in ci.guix.gnu.org. <efraim>ouch. that's actually why I ended up buying a split keyboard, was starting to feel some RSI pains from a standard keyboard and rapid typing <Kimapr>i'm trying to run docker on Guix System, but `docker start` says `Error response from daemon: Unknown runtime specified runc` <Kimapr>could the fact that i copied /var/lib/docker and /var/lib/containerd from a different distro be the problem <nutcase>rho`n no, I didn't try again. And to be honest, I don't have an idea, how to debug the issue or what to try. <Kimapr>Oh, yeah, that seems to be the issue. apparently every docker container remembers the runtime it was started with ? <Rutherther>makx: does it happen on retries as well? if so, I am not sure, but it could be corrupt store, so you can try guix gc to verify contents <Rutherther>you need to run "guix gc --verify=contents" to verify contents, so you ran that? <makx>sorry i am not a massively experienced guix user (yet) <rho`n>nutcase, on which OS are you running Guix? <rho`n>nutcase -- oh ok, running a guix system on a home server myself, but running user jobs through the main system config. I will configure some service in my home directory and see if I have the same issue <lilyp>before I do something stupid: is there a way to leak files to a build container without interning them? <Rutherther>lilyp: I am not sure what interning means. It's possible to leak files with --chroot-directory option to guix-daemon, but it shouldn't really be used as it destroys reproducibility. Is this what you meant? <lilyp>"interning" as in "moving it to the store" <Rutherther>okay. Then I think my answer covers it, and I don't think there is any other way, everything else has to come from the store as far as I know <Kimapr>i'm trying to use i3lock but it doesn't accept my password.. <Rutherther>Kimapr: i3lock needs a pam service. Did you add a pam service for it? <janneke>ACTION finds out about gexp->approximate-sexp, neat <lilyp>hmm, I guess the question is whether it's possible to specify an input that isn't a store path 🤔 <Rutherther>Kimapr: yes, but I would suggest to add (using-setuid? #f) to the configuration. Setuid shouldn't be necessary, and it's always additional security risk <csantosb>Someone else experiencing networking issues upon `guix pull` or did I break my system ? <ieure>csantosb, Yes, few others over the last couple days. <jlicht>ACTION is reading up on the latest and greatest contributing info pages <homo>hi, does hugs depend on something that modern compilers don't have? gcc 4.9 fails to build <jlicht>my pending patch series that will remove the old, insecure and probably never-should-have-been public Node.js@10 _technically_ seems to deserve a one month deprecation notice; should I send this notice to guix-devel explicitly? <janneke>jlicht: that's how i read it; possibly cc your cover letter to guix-devel? <jlicht>janneke: thanks for the sanity check: I'll be sending a v2 and CC guix-devel indeed :-) <raghavgururajan>Hmm! IceCat crashes with "Exiting due to channel error." more frequently on Guix System. I think started at n-1 or n-2 update. <csantosb>raghavgururajan: unrelated, but you made me wonder about the advantage of icecat-115 over librewolf-132 ? <stochastic>When I do guix pull, a very long error pops up with meson <csantosb>Apparently, pulling has to wait for a moment