IRC channel logs
2023-06-02.log
back to list of logs
<rekado>this is a known bug with a simple solution <efraim>pjals: libx265 has been due for a rewrite for a while. I've been meaning to follow Debian's build plan to do that.... eventually <efraim>Different build outputs would also probably be good <next4th>evilsetg[m]: thank you for the patch. my email provider is down, unable to sent mail to close the issue though.. <evilsetg[m]>next4th: Should/can I do that? I don't know what kind of email to send to close an issue though. <iyzsong[m]>evilsetg[m]: np, you can close the issue with send a email to 62293-done@debbugs.gnu.org, or i can close it later. <janneke>jpoiret: commencement is done, now trying to build hello (with its dependencies) <janneke>that wasn't easy, the libc-for-target fixes of course had some impact on passing/failing tests here and there (coreutils, grep, sed), triggering rebuild after rebuild <apteryx>hm, new bug? guix shell coreutils -C --symlink=/usr/bin/env=bin/env -> error: evaluate-populate-directive: unbound variable <apteryx>can someone reproduce just to make sure? <apteryx>will first create an issue for it, no time to fix it atm <evilsetg[m]>next4th: I wrote a mail to mark the issue as done. Thank you for your help :) <janneke>omg, findutils needs to be patched...world rebuild ;-( <janneke>thes commencement.scm -> bbase.scm dependencies are really killing <civodul>apteryx: oh i think i see where that comes from (and i think i'm guilty!) <janneke>will need to rebuild 3 glibc's two gcc's and a guile and lots of other stuff to get one little step further... %-/ <apteryx>civodul: perhaps already captured by the tests? I haven't checked <pjals>efraim: ah, that's good to know, maybe i could do it if i have time <civodul>(given that "guix pack -RR" has been broken because of that since the merge) <apteryx>is there a way to have C-c (SIGINT) passed to the Guix containerized process? <pjals>how are you getting into the containerized shell? <apteryx>then launching some Python GUI; C-c from the shell doesn't interrupt it. <pjals>SIGINT is indeed passed in the containerized shell, is the Python GUI freezing or something? <pjals>It may be that SIGINT is not enough to terminate the process, SIGKILL may be needed. <pjals>Then do bg, and then echo $!, and then kill --signal KILL <pid reported by $!> <pjals>Of course, this will forcefully terminate the program, throwing away any unsaved changes. <apteryx>another problem with containers: I cannot share /etc, either via --share or --expose. It throws a mkstemp error in both cases. <pjals>Well, /etc very well exists in the container. <pjals>What are you actually trying to do? What do you wish to do when you share /etc? Is it a solution to a problem? <apteryx>kill -sKILL 15339 (the python app process) does not kill it <apteryx>the application can be interrupted when not running inside the container <apteryx>seems to be something with that custom application though, because I can't reproduce with another Python GUI application: guix shell -CN --preserve=XAUTHORITY --expose=$XAUTHORITY --preserve=DISPLAY deluge <apteryx>that one is properly interrupted on C-c, from the containerized shell <apteryx>ah, it only happens when using -- to execute the command I think <apteryx>it's a custom wxPython one for a project I'm working on <pjals>well, does it have signal ignoring code? <pjals>it's hard to know what is the issue without any context <apteryx>yeah, I guess it has to with how its main loop works, hard to say. it doesn't do anything with signals <jpoiret>civodul: that test is failing because of an actual bug in proot <jpoiret>from what I can gather from the test, cwd-related functions and pthreads don't interact well <civodul>jpoiret: ok; any idea whether it breaks only multi-threaded applications? <rgherdt>Hi. I'm trying to create my first package and having a problem during the configure phase. Basically it's a guile library `guile-lsp-server` that relies on another library `guile-json-rpc`. `guile-lsp-server` has in configure.ac a check for the availability of the module `json-rpc` (provided by `guile-json-rpc`). The build fails with: "configure: error: required guile module not found: (json-rpc)" <rgherdt>`guile-json-rpc` is listed in the `inputs` field <rgherdt>and I see in the logs, that GUILE_LOAD_PATH is set to the path of `json-rpc` as expected <rgherdt>do I have to manipulate the phases somehow, so that `json-rpc` is available? <jpoiret>archive[m]: I can try to look at it today <rgherdt>ignore the fact that guile-json-rpc was already packaged by someone as guile-scheme-json-rpc, I saw it later <jpoiret>sneek, later tell civodul: I'm looking at the bug right now, I think i have some clues <attila_lendvai>sneek later tell civodul: i got an error at the end of a guix system reconfigure: guix system: warning: exception caught while executing 'eval' on service 'root': error: remove: unbound variable <mirai>is the person who wrote define-maybe around? <mirai>or whoever happens to understand the choice of using the %unset-value symbol? <rgherdt>answering myself: I figured out another library was missing. Sorry for the noise <mirai>I was wondering if we could replace the custom symbol we use there for #<unspecified> instead <rdrg109>[Q] Newbie: I have two version (1.1.1 and 1.2.1) of Inkscape installed in /gnu/store (see last two lines in http://0x0.st/HbfJ.org ). My system is currently using 1.2.1 , but I want to run 1.1.1 . How to switch to a previous version? <mirai>the same object used in when <attila_lendvai>mirai, that's what i have proposed originally, but my patch got modified to the current solution. unfortunately i don't remember why. just my emotional response of dissatisfaction, that then settled down with the current solution. <elevenkb>rdrg109: i'd think you'd have to use inferiors (look up that index in the info manual). <attila_lendvai>mirai, just use maybe-value-set? and maybe-value to deal with the case of defaults. <elevenkb>rdrg109: watch out though, I tried them for a similar reason and had to rebuild w/o substitutes. <mirai>attila_lendvai: oh those won't be going away soon even if #<unspecified> is used <mirai>it's more or less straightforward to replace them behind the scenes without breaking anything <attila_lendvai>mirai, i think i even proposed to use srfi-189 instead of a custom maybe stuff, but it didn't get used <mirai>it's more or less straightforward to replace them behind the scenes without breaking anything <mirai>I'm prototyping a generic INI serializer for define-configuration using SRFI-171 <mirai>though guile might have it baked in, haven't carefully checked yet <attila_lendvai>sneek, later tell civodul: FYI, i'm seeing behavior with shepherd that suggests shepherd bug(s). one thing is with `herd stop x`: i see no sign of the TERM signal in the daemon logs, and after the grace period (1 min here) it gets killed. could be a daemon bug. <lispmacs[work]>hi, I don't seem to have enough memory (a measley 8GB) to link together telegram-desktop <lispmacs[work]>I was wondering about getting the substitute from the last successfully build, but can't remember how to look that up and what guix commit to use <lispmacs[work]>or if there is something I can do to modify telegram-desktop build to bring linking memory usage down to sane levels <anemofilia>herd: error: /tmp/runtime-radio/shepherd/socket: No such file or directory <attila_lendvai>anemofilia, probably shepherd wasn't started for your login. maybe some login init file is not evaluated? is this a normal login? or through e.g. ssh? <redan>Check the perms on the socket and your users groups. ย can insto something earlier where sudo worked and non-sudo required me to logout and bakc in due to an added group. <redan>Got something similar trying to follow error: kmonad-service-type: unbound variable. <jpoiret>redan: can you post a snippet of your work on paste.debian.net? <jpoiret>anemofilia: what's your herd service invocation? <anemofilia>attila_lendvai: it's a normal login. What do you mean by evaluating the init file? <attila_lendvai>anemofilia, dunno, something like not sourcing .profile (that may start shepherd). i don't know how this works, sorry. <jpoiret>guix uses XDG_RUNTIME_DIR/shepherd/socket i think <jpoiret>that's why then :) are you modifying it yourself? <jpoiret>redan: does (my services kmonad) export kmonad-service-type? <jpoiret>you need to have #:export (kmonad-service-type) in the define-module form <jpoiret>and you still get kmonad-service-type: unbound variable? <jpoiret>how do you manage to get your other modules into the load path? do you use local-guix as a channel, or the `-L` option? <redan>`sudo guix system -L ~/local-guix reconfigure /etc/config.scm` <noobly>hi, I'm getting an error when installing a generic / barebones guix. I get to the point where I run 'guix system init '/mnt/etc/config.scm' '/mnt'', but the command fails with: 'guix system: error: fport_read: Input/Output error copying to '/mnt' <noobly>dmesg is clear after running the command as well <noobly>ok, /dev/sda3 which is mounted on /mnt has 208GB available, so i would think it's got room <noobly>jpoiret: not sure where else to look, i assume this wouldn't be caused by non-free firmware <jpoiret>no, probably not. did you start the cow-store service? <noobly>i get the same error when doing graphical install and manual, by the way <noobly`>is there anywhere i can look for more informative error messages? <jpoiret>nope, and this is a pretty low-level error <jpoiret>are you on bare metal or VM? what are you booting off of? <noobly`>bare metal, just my regular ol' desktop on a new SSD <jpoiret>do you have enough RAM? 8 gigs should be enough <noobly`>jpoiret: that's given with 'free -h'? total says 7.7 <jpoiret>starting to exhaust my ideas. is your install image recent? <noobly`>jpoiret: screenfetch says RAM: 645MiB / 7920MiB, kinda weird? <noobly`>jpoiret: yeah just downloaded it fresh a couple days ago, let me check to make sure it was x86_64 <noobly`>just to double check, how can I check the guix version that's on my usb drive? I'm using it right now to access this channel so don't want to unplug it <dthompson>has anyone dealt with locale issues in guix packs before? <vagrantc>jackhill: i would say armhf really should not block progress... but who am i? :) <jackhill>vagrantc: :) I mean, it would warm my heart for sortware to work on that platorm, but we probably need to tackle aarch64 first. <vagrantc>wow, that's confusing ... why would qa block testing of x86_64 when armhf/i686/powerpc64le are blocking... <vagrantc>jackhill: it has been a long time since i've tested any of the armhf boards, but i had tested a few with guix <vagrantc>worked well enough, as long as substitutes were available <vagrantc>and then the fastest one i had started having kernel panics around linux-libre 5.4.x if i recall <jackhill>awww. Yeah, I need to get back to doing arm stuff. Last time I tried, I caught it at a bad time for buildability, but I think many of those issues have since been fixed. <jpoiret>dthompson: what kind of locale issues? <civodul>jpoiret: woow, excellent, thank you! <sneek>Welcome back civodul, you have 4 messages! <sneek>civodul, jpoiret says: I'm looking at the bug right now, I think i have some clues <sneek>civodul, attila_lendvai says: i got an error at the end of a guix system reconfigure: guix system: warning: exception caught while executing 'eval' on service 'root': error: remove: unbound variable <sneek>civodul, attila_lendvai says: FYI, i'm seeing behavior with shepherd that suggests shepherd bug(s). one thing is with `herd stop x`: i see no sign of the TERM signal in the daemon logs, and after the grace period (1 min here) it gets killed. could be a daemon bug. <jackhill>jpoiret: very cool, thank you for tracking that down!