IRC channel logs
2024-02-12.log
back to list of logs
<ieure>misc-error #fvector->list: expected vector, got ~S#f#f <ieure>How can I make guix stop trying to colorize output? It's not smart enough to disable it when TERM=dumb or TERM=emacs. <ieure>Specifically, `guix home describe' is crapping up my shell with escapes. <apteryx>jpoiret: eudev fails to build after migrating to pkgconf; wants zstd and zip (or is eudev already broken?) <apteryx>eudev 3.2.14 built on my local branch, moving toward my test target (mpv) <gerogaga>Hello, I'm having a spot of trouble installing Guix. I have an RTL8822CE network card, the drivers for which should be upstream since kernel 5.2 but the installer can't connect to the internet. <rekado>ieure: it should respect NO_COLOR <sneek>adanska, you have 2 messages! <sneek>adanska, snape says: instead of returning the package you return (list package "the output") <sneek>adanska, snape says: e.g. guix shell -f <(cat gnu/packages/bittorrent.scm <(echo '(list transmission "gui")')) <adanska>i think the lem package is in a good enough state that we can start writing a patch series. I still want to look at a couple of things, maybe set up a vm so i can test the non-guix version of lem against my packaged version and see if theres any regressions. <adanska>but the main ones have been dealt with, and the act of packaging it for guix uncovered some bugs upstream! which was pretty cool <allana>Hi! I submitted a patch a few weeks ago (vpn-slice, bug#68683) and have not seen any movement. It essentially includes some inputs that should have been included originally. What might be the appropriate thing to do to get someone to review the patch? It's not a dea breaker for me if it gets rejected because I maintain a package variant for myself but I think most people would want the patched vpn-slice. <allana>vpn-slice is also packaged for Nix and includes the same inputs that the submitted patch would add. <allana>adanska: I have been interested in trying out Lem for some time. Glad to hear that it might be coming to Guix soon. <adanska>yeah! theres one problem i have left but otherwise its looking pretty rock solid! <adanska>allana: if you get the time, would you able to see if `M-x slime` causes any errors to display? I'm having some inconsistencies between machines (me and the person im collaborating with), and want to see if its just a me issue. <adanska>currently building a guix vm to minimise environment <rekado>allana: I’ll apply it in a moment. <adanska>yep. thats the one i experience too. btw, you can still use slime perfectly well after this, try using the repl <allana>when I run it again, I see this error: "Couldn't execute "which": No such file or directory" <allana>I am running within guix shell: "guix shell --pure -f package.scm" <adanska>ah yes that would be it. I will need to add coreutils as part of the inputs then <rekado>the “which” package provides “which” <sneek>civodul, you have 1 message! <sneek>civodul, rlb says: -- either way, updated the branch with the smob cleanup and a bug fix. I also wondered what's actually allowed in on_thread_exit, since I think we're outside with_guile at that point... <adanska>hmmmm. i cant get uiop:run-program to see `which` without adding it to propagated inputs :( <janneke>adanska: can't you substitute which (which "which"), eg see the catfish package <adanska>i can forsee a hack to get it to work: add the path to which at build time to the uiop:run-program invokation <adanska>its just annoying that uiop:run-program can find it on its own. <doriru>hello. will testing testing builds be available for download any time soon? <viperML>hello, more of a guile question... is there any way to check the names of the symbols exported by a module? <doriru>asking because i keep running into an error during installation of 1.4.0. tried multiple things after asking for help here, but nothing seems to work <adanska>is there a way to get a development shell using a package with -f? <adanska>guix shell -D -f package.scm doesnt seem to work <rekado>weird core-updates thing: with the patch to look for objdump by a different name I was able to build the first glibc just fine, but a later cross build of glibc (after gcc was built) again fails to find objdump <snihil>viperML: in a Guile REPL, if you ,m (my module) and then run ,b (for ,bindings), you will probably get what you want <civodul>rekado: i removed “glibc-cross-objdump.patch” because it was no longer needed (i believe i tested it) <civodul>in d5242a562e089c6520aab2eebb743efc1d222d94 <snihil>viperML: oops, it is ",binding" (and not ",bindings") <efraim>objcopy-for-target then? Maybe it's time to turn those into (foo-for-target "foo" (or (%current-target-system)(%current-system)) <rekado>that gets me past the first build of glibc, but not the second <rekado>./pre-inst-env guix build --target=i586-pc-gnu -K -e '((@@ (gnu packages make-bootstrap) %glibc-bootstrap-tarball))' <civodul>the lesson i learned re cross-objdump is that the build system, when cross-compiling, is supposed to pick ‘objdump’ from $PATH <rekado>it is /gnu/store/w8rwwpf1ljf60y068gy004frai1cf89a-glibc-cross-i586-pc-gnu-2.38.drv that’s failing <civodul>this, in turn, means that TOOLCHAIN/…/TRIPLET/bin must come before TOOLCHAIN/bin <civodul>ah yes, that was 5cf6c96ad9ffafccf180ec2d44c740b6999c02ac <civodul>so maybe there’s something in make-bootstrap.scm that overrides that logic? <viperML>but then I have a problem: guix repl --listen=unix:$PWD/.socket "hides" the repl (guile --listen keeps the repl), so I don't know how to either: <viperML>- Connect neovim+conjure / emacs+geiser to a guix repl socket, or <viperML>geiser-connect-local seems to hang when connecting to the socket <rekado>I noticed yesterday that Cuirass contains a bunch of minified JavaScript files. I’ve started some work to get rid of jqueryisms (so we can drop that library at least). <civodul>viperML: hi! geiser-connect-local should definitely be able to connect to that socket <civodul>the protocol that (guix inferiors) speaks <civodul>so you would want to use ‘guile --listen’ instead <ekaitz>hi, anyone knows how to build the hidden gcc 4.7 package? <rekado>ekaitz: you can build any expression that evaluates to a package with “-e” <ekaitz>oh wait, the problem is not to call it to be built <ekaitz>i guess there are glibc versioning issues or so <ekaitz>i was trying to use it for my backported gcc as a reference but... <ekaitz>just tried in x86_64 and it doesn't build <viperML>civodul: then I can load guix within a guile repl? <futurile>(realising it's not really the morning any more) <avalenn>futurile: it is always morning somewhere :-) <ekaitz>./md-unwind-support.h:145:18: error: field ‘uc’ has incomplete type <rekado>ekaitz: have you tried using a different GCC (other than GCC 11) to build it? <ekaitz>that's why I asked, which one is the one I should use? <ekaitz>should I just add it to inputs to make the build system find it, right? <rekado>I don’t know. I just wonder if maybe that’s because of GCC 11. <futurile>avalenn: definitely got that 'morning feeling' - can't quite wake-up even though it's mid-day! <rekado>yes, though in some cases you may have to perform extra work to make sure GCC 11 stuff isn’t accidentally picked up. <rekado>(it doesn’t seem to be quite as easy to just *replace* the GCC package) <ekaitz>rekado: let's try to use an old gcc or something and see what happens <chsasank5>have been trying to use guix inh india and I have been getting very bad speeds - I changed substitutes and stuff. Still slow. Any recommendations? <futurile>chsasank5: 'speeds' meaning it's slow to download and install substitutes? <futurile>chsasank5: where are you/your-systems based? <ekaitz>rekado: do you have any example of how to replace the gcc effectively? <civodul>viperML: yes, with (use-modules (guix)) or smiilar <ekaitz>or any package you know that does this? <futurile>unfortunately, I think you're stuck using the European ones, and for some reason (we are not sure why) they seem to have slow peering with some places <civodul>viperML: you also need to make sure Guix is on GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH (that’s the case by default on Guix System) <viperML>civodul: thank you, that seems to work <viperML>(at some point my guile path was empty, but after some reboots later it seems to be ok) <viperML>;;; WARNING: loading compiled file /home/ayats/.guix-home/profile/lib/guile/3.0/site-ccache/guix/describe.go failed: <viperML>;;; In procedure load-thunk-from-memory: incompatible bytecode version <viperML>;;; compiling /home/ayats/.guix-home/profile/share/guile/site/3.0/guix/describe.scm <rekado>very odd: “guix deploy --no-grafts deploy.scm” (to an i686-linux system) builds rust, but just “guix system build --system=i686-linux config.scm” does not. <ekaitz>oh rekado i tried to use another compiler to build gcc-4.7.4 but if I add the gcc package to the inputs it says it's a circular dependency <sham1>AAA, I'm in a moment where even more elbow grease is needed. guix import doesn't understand maven. So that's gonna be a not-fun thing <viperML>as I understand, "guix pull" downloads guix into /var/guix/profiles/per-user/$USER/current-guix, but that path in never added into the GUILE_LOAD_{PATH,COMPILED_PATH} <efraim>ekaitz: define a new gcc-4.7.4 before you go to build it and build that one with your changes <ekaitz>also efraim how is gcc-4.7.4 built? i can't build it manually so it must be built with some inputs that are not the ones that are set when running by hand <efraim>I don't think it's built successfully for a while, probably due to changes in glibc <efraim>I'd consider first using the time-machine to find a time when it did build <rekado>ekaitz: I tried building it with gcc-8 (just added it to the native-inputs), but that failed. <rekado>I may just have run out of memory as I’m also building tensorflow right now. <ekaitz>i don't think it's a memory issue <apteryx>I had guile-fibers fail on my computer due to being silent for more than 1 h <apteryx>is the test suite expected to take this long? <efraim>apteryx: slow machine? some of the tests take an exceptionally long time <efraim>I disabled the loop-to-1e4 test on all the non-x86_64 machines (at least I assume it was me) <rekado>well, my failure is rather unusual: guix build: error: getting status of `/tmp/guix-build-gcc-4.7.4.drv-0/top': No such file or directory <apteryx>efraim: seems it hung on assert run-fiber-return-vals equal to (75025): <efraim>1.2.0 released with glibc-2.31, probably not old enough <andreas-e>Hello! Could anyone help me with creating a Guix docker image? I took a small system image and "guix system image -t docker os.scm"; then importing the image; then "docker run guix -it /run/current-system/profile/bin/bash". But this only results in entropy being gathered for creating a key pair (and not being found for hours until I stop the thing), although I have no ssh service in the configuration. Do you know what I could do? <sneek>andreas-e, you have 1 message! <efraim>I have no idea how long ago I sent that <andreas-e>Is it solved? Yes! I wanted to answer that we do not have a logo, but apparently we do since FOSDEM. <andreas-e>And it sits inside assets/. The code of the website has changed. <civodul>andreas-e: hi! what’s the purpose? for GitLab-CI, i found it to be complicated <andreas-e>For Openshift... To add more power to the Bordeaux build farm. <efraim>perhaps we should add one in images/ too? I think it might be needed for a favicon <efraim>apteryx: uh, back to fibers, I'm not sure what to suggest other than building it once with --timeout=0 --max-silent-time=0 or something like that <andreas-e>To start with, I would just like a basic docker container in which I could start bash, for instance. And later the Guix daemon and a guix build agent. But I do not actually need shepherd. <andreas-e>If I remember correctly, zimoun had a container for gitlab.com, which strangely did not work in our local gitlab installation. <civodul>andreas-e: right, re shepherd, that’s why i ended up doing this: guix pack guix bash-minimal coreutils-minimal grep net-base --save-provenance -S /bin=bin -S /share=share -S /etc=etc -f docker --max-layers=100 <civodul>that way you don’t get shepherd as the “entry point” <efraim>ekaitz: 1.2.0 failed to build, trying gcc-4.7 on version-1.1.0 <civodul>but then, more work’s needed, at least for GitLab-CI <civodul>another problem: in containers, you most likely have to run “guix-daemon --disable-chroot” <civodul>and that’s not acceptable for the build farm <andreas-e>civodul: Thanks, I will try it out. In Openshift, there is some additional provisioning around the containers - the plan would be to have two containers, one for the build daemon and one for the build agent, but these could share a common socket, for instance. <efraim>generally I thought that guix containers that you want to build inside of need to be run in privileged mode <viperML>after guix pull, and exporting GUILE_LOAD_PATH=$HOME/.config/guix/current/share/guile/site/3.0:...., same for compiled <viperML>scheme@(guile-user)> (use-modules (guix)) <andreas-e>Are you not just missing guile-gcrypt? Maybe running inside "guix shell -D guix" would help? <yelninei>civodul: i am not sure if you saw my soltuion to the childhurd problem yesterday. The issue was the order of service activations (hurd-vm activation running before guix activation) which depends on the order of the services in the the os declaration. So your change was not responsible :) <viperML>andreas-e: thanks, that seemed to be the case <efraim>ekaitz: 1.1.0 failed to build, error about dereference pointer to incomplete type <viperML>still a problem (?) that ~/.config/guix/current is not added to the guile path automatically. Also ~/.config/guix/current/etc/profile doesn't contain any reference to the guile load path, just PATH <efraim>although it also might have been too many cores <andreas-e>civodul: Your "guix pack" trick worked, at least insofar as I can call bash etc. <ekaitz>efraim: that's the same error it appears now <ekaitz>it's because linux-headers are changed and needs to use ucontext_t instead of struct ucontext <efraim>IIRC we changed it with other gcc packages <efraim>that was for glibc-2.26 according to the code comments <efraim>doesn't look like we added that snippet for 4.7 <andreas-e>civodul: I can start the daemon in the background, but it complains that it would like to see --build-users-group. "guix build" then fails as follows: "guix perform-download: error: refusing to run with elevated privileges (UID 0)". <andreas-e>And before this it cannot do downloads because the ACL is empty, and because it cannot resolve host names for the substitute servers. So maybe "guix pack" is too weak as a primitive for such a container? <Arman>DBeaver is not in guix packages. What client can I use to manage my dabase? <apteryx>Arman: hello! we prefer 'people' over 'guys' around here, as an inclusive gesture :-) <apteryx>I do not not DBeaver, but if it's free software, you could consider writing a package definition for it <apteryx>else perhaps someone already wrote one in a Guix channel, you'd have to search the intertubes <jpoiret>efraim: in general i don't think it's super helpful for us to pretend we can support very old gcc versions <civodul>andreas-e: well, you need to initialize the ACL and stuff like that from your .gitlab-ci.yml file or whatever it is you’re using <civodul>apteryx: oh, i hadn’t seen this merge request; i believe this is fixed by recent changes <civodul>(Sören contributed a nice ABI-check script) <andreas-e>civodul: I have found my old README for the docker images. Otherwise said, it used to work at some point in time, but stopped doing so. There is even a bug report about it: https://issues.guix.gnu.org/65847 Is there a way to disable sshd to work around the entropy gathering problem? I do not see in the Guix source code where this enters the container. <civodul>andreas-e: yup, you can (and should) remove openssh-service-type from your OS config <andreas-e>peanuts: Exactly! "Some point in time" when it worked was 2020. <andreas-e>lechner: Nice bot! But it has taken quite some time. <apteryx>but unconditionally, so we don't support pre 1.2 git anymore (not a big deal in 2024 I guess) <apteryx>also the pointer type is declared as void instead of uint8 for some reasons in master <andreas-e>civodul: But where do these services come from? I have an (operating-system) with a (services) field containing a 1-element list with (service guix-service-type) in it. <ekaitz>efraim: any older version working? <ekaitz>efraim: also, did you manage to make the pbp work? <civodul>apteryx: cool; apologies for duplicating work <civodul>i should set up email notifications for guile-git MR <civodul>but then again, i’d rather not be responsible :-) <pkill9>i'm getting a segfault when running 'moc' from the qtbase package, anyone know what might cause this? <rekado>pkill9: you can run it in gdb to see where it’s failing <rekado>you likely won’t get a lot of detail, but it could be enough to find the library at fault. <pkill9>it fails right at the beginning, thing is it doesn't segfault when building hedgewars with the guix packag <pkill9>I think it's a tiny utiility that isn't supposed to ever be called directly, so they didn't handle it that way <pkill9>or only as part of some other QT build by another QT buidl program, idk <pkill9>thing is it segfaults when compiling using `guix shell --development --container hedgewars` <pkill9>but doesn't when building the package with `guix build --no-grafts --check hedgewars` <viperML>I create a trivial package with the copy-build-system and local-file as a source, and the resulting derivation contains a "environment-variables" file, why is that? <rekado>viperML: that’s a generated file containing environment variables set in the build environment <rekado>civodul: I’d like to test some changes to Cuirass; is there a test database I could work with? <civodul>rekado: i usually test against a volatile database using the ‘examples/random.scm‘ spec <rekado>excellent, thank you. I’ll try that. <andreas-e>civodul: I have a working docker container! But indeed something in its creation process adds "--disable-chroot" to guix-daemon. How do I get rid of it? (Assuming that things can still be run under docker without it...) <civodul>andreas-e: yes, that’s from ‘containerized-operating-system’, and that’s because that’s the only way you can run guix-daemon in a non-privileged Docker container <andreas-e>civodul: And if I want to run it in a priviledged docker container (of which I am not sure whether it is possible in my environment), how can I create this container? <civodul>andreas-e: currently you can’t really do that <civodul>the best option would be a VM though <andreas-e>civodul: That does not seem possible with openshift, which is container based. So I could modify my guix checkout to remove this addition of "--disable-chroot". Or try to completely bypass the shepherd and run the daemon on my own. <lispmacs[work]>somebody once showed me a one liner to build a hurd VM, but I've lost track of it. Can somebody remind me what that is? <snape>is there a way to download the irc logs? <snape>I mean, in text readable way <snape>ekaitz, I mean download it as a text file <snape>I could use an xml parser, but ... <snape>the goal is to search for stuff there <ekaitz>can you use a different accept header and see what happens? <ekaitz>i don't think it will work here hmmm <snape>I could use the search engine, but I've never figured out (in years) how to search for special chars in a web search engine like Duckduckgo or Google <snape>adamnr yeah but it doesn't work <snape>adamnr: try searching for "snape" <adamnr>snape: works for me on firefox - using a simple search for 'hurd' <snape>adamnr, it's nothing to do with firefox <snape>it's their backend that is 4 years outdated or somethign like that <snape>hurd doesn't give 2024 results either <apteryx>jpoiret: seems to work well, made it to pstoedit thus far, trying to build mpv on core-updates <theotherone>Hi, quick question, for some audio stuff I want to change the realtime priority in /etc/security/limits.conf. I've added the service type to my configuration and went to reconfigure my system. Since I haven't updated my system in a while Guix pulls in the newest kernel which takes time. Is there a way to prevent the build of a new kernel when doing minor edits to a configuration file? Thanks in advance :) <jpoiret>theotherone: you'd have to use an older guix for that, you can roll-back your guix using `guix pull --roll-back` or --switch-generation <jpoiret>otherwise there's no way to selectively update your system config <theotherone>Ah, thanks. Yeah, I guess selective upgrades are a bit against the guix philosophy :D <rekado>theotherone: Guix records the version of Guix that was used to build a system. You can use the same version to reconfigure your system with the updated config. <rekado>snape: someone’s gotta fix it. The code is very simple, but someone needs to take the time to figure out where it goes wrong. <pkill9>apteryx: maybe try `guix shell qtbase -- moc` (i assume guix shell uses -- for commands like guix environment) <psyleft>Hey all, does anyone know how to get dnsmasq working with basic dhcp networking? <psyleft>I can write `nameserver 127.0.0.1` to /etc/resolv.conf but dhcp-client overwrites it <rekado>something about desktop-services-for-system isn’t working when using “guix deploy” <rekado>when deploying to a i686-linux machine I keep getting librsvg, gnome-shell, and thus rust. <rekado>the derivations say it’s for i686-linux <rekado>when I just “guix system build --system=i686-linux config.scm” this doesn’t happen <vagrantc>not sure about gnome-shell, but the default grub theme pulls in librsvg and thus rust <rekado>vagrantc: thanks for the reminder! I did see this message but didn’t think much of it. Now I remember that in the past this had bit me on aarch64. <terru>hi everyone! new guix user here (installed the guix system on my laptop two days ago). works great so far, but hikari (my usual wayland compositor) seems to currently be broken on guix master; it can't be built with wlroots 0.16, but needs the older wlroots 0.15 — i guess the thing to do is define a package variant for wlroots called wlroots-0.15, and use that for hikari? is it worth submitting <ieure>terru, IMO, fixing hikari to compile with current wlroots is a better solution. <vagrantc>alternately, are there updates for hikari? <terru>unfortunately there seem to be no newer versions of hikari, and i'm not enough of a C person to update & maintain a patchset for it myself <ieure>Seems like every Linux standalone compositor is doomed to buggy unmaintainedness. On the X side, xcompmgr fell into disrepair, so compton forked from that and was abandoned in a buggy state, so picom was forked from that. picom is more actively maintained but (in my experience) just as buggy as the rest. <terru>yes, i am aware this has been the state of things for a while with hikari <ieure>Just surprised that this particular strain of rot doesn't discriminate between X11 and Wayland. :) <terru>so, what to do about that package? it seems a little confusing to have it, but then it fails to compile if you actually try to use it (as i'm otherwise used to nix: is there a way to at least mark it as broken, if having an older wlroots in the guix system is not wanted?) <rekado>terru: I’ve long wanted to have a mechanism to tell clients that the build farm has repeatedly failed to build a package, so that a client can choose not to waste time. <rekado>it’s made up of lots of Rust components. Can our Rust build system abstractions deal with something like this, or would I have to package each directory separately? <ulfvonbe`>the approach I've been taking with such projects is to package each directory separately, but cargo-build-system requires that a rust package's source be a tarball, so I've been having to use computed-origin to repack subdirectories <dariqq>ulfvonbe: If you don't want to write computed-origins i found that the following also works: Adding your rust-package with git-fetch to both cargo-inputs and inputs and fixing the package-phase such that cargo-package generatets a tarball for you <lilyp>civodul: it was pushed, then reverted, then pushed to emacs-team <rekado>the “guix deploy” story is weird. Guix keeps deciding at some point that my i686-linux system needs to use gdm-service-type. <ulfvonbe`>my understanding is that when a dependent cargo-build-system package uses a given package in its cargo-inputs, pretty much everything about the package being used except its 'package-source' field is ignored <rekado>it’s odd, because I’m printing the value of %desktop-services, and initially it contains sddm-service-type <rekado>perhaps I’d rather wait for eventual changes to the cargo-build-system. This looks a little too complicated for me. <rekado>the gdm-service-type appears around the time when switch-to-system.scm.drv is computed <dariqq>you'll need to add it to cargo-inputs such that all the rust dependencies of your package (which would need to be as tarballs) are also pulled in and there is a phase in cargo-build-system which will add all *.crate files in the input/share/cargo/registry also to the vendor dir. <rekado>hah, when upgrade-shepherd-services runs %current-system is back to x86_64 <dariqq>ulfvonbe: yes. But if your source is not a tarball it is not getting vendored. Thats why I use the trick to also add the package to the inputs <apteryx>shouldn't the Guix Guile modules be made available when guix is installed on the system? 
