IRC channel logs
2023-12-14.log
back to list of logs
<cnx>pretty well, how about you? <cnx>btw is there any release cycle for guix stable? <cnx>fair enough, i mean the versioned one, as opposed to the master devel <araujo>hello , any good documentation to use the guix pkg manager in a different distribution? <podiki>cnx: those versions are sort of snapshots for an installer version basically, no plans as far as I know for the next one <podiki>cnx: but guix is a rolling distro, the snapshots are sort of a good place to polish things and improve installer as a new starting point for installing, though often people will use the latest (post snapshot) installer anyway <podiki>cnx: so you are never meant to stay on a "version", though we have cool things like pinning and time-travel :) <araujo>podiki, Thanks, yeah, I am going through the manual now ....and I was wondering if there was something more concise explaining only how to setup the package manager <isaneran>in my list of services in my home config is this right? <isaneran>(service home-mcron-service-type (home-mcron-configuration (jobs (list mbsync-job)))) <isaneran>mbsync-job is a g-exp like #~(job '(next-hour) "<cmd>") <isaneran>however after instantiating this and running mcron -s it says there was error reading my .config/cron or .cron file <isaneran>reason why I thought it's maybe wrong is because in the system mcron example it is using a simple-service <isaneran>looks like I needed to restart mcron manually after running reconfigure <isaneran>Hmm herd schedule mcron seems to give good output but I can't figure out how to see the logs of when it actually ran the job <isaneran>Idk why I look for answers for so long and then I feel like ok now it is finally ok to ask the question since I am not finding it, and then immediately after asking I find the answer lol <efraim>should I use define-json-type or define-json-mapping? it looks like define-json-type takes care of most of the options <adanska>made a mastodon account the other day, seems pretty cool! theres a lot more niche tech news on there which i suppose speaks to its userbase, doesnt it? haha <efraim>it looks like we use define-json-mapping everywhere else in guix <sarg>hi guix, for a couple days I try to reconfigure my system, but it wants to build glibc/mesboot which I'm afraid means a world rebuild. Does it happen to you as well? https://paste.rs/JbS9u <janneke>sarg: remove gnu/packages/bootstrap.go <sarg>woah, that works. But why? <janneke>sadly, there's no dependency management/tracking for .go files yet <sarg>not sure I understand. Do you mean the file should've been recompiled because some of its deps changed? <janneke>yes, probably because of the avr-toolchain/cross-compile effort <efraim>I guess I get to use read-json and write-json for use in guix/build-system <bumble>I am interested in the patch because I hope to use the current version of qutebrowser, where currently guix installs the older qt5-using version <civodul>hmm ‘guix publish’ had gone wrong on ci.guix, i had to restart it <civodul>weird because it’s been stable for years i think <bdju>when I try to skip upgrading kubo (because it fails to build) it doesn't work, it still tries to build it again, fails, and halts my upgrades <efraim>valgrind/interactive uses the wrong libc on the hurd <efraim>if anyone's looking for something to poke :) <sarg>I also vote for the pyqt6/qutebrowser patches <sarg>maybe peanuts can keep track of votes? <bdju>civodul: ah nice, thanks for the link. any idea why I wasn't able to skip upgrading it? usually don't have issues with that. maybe something dependency related <civodul>bdju: ‘guix package --do-not-upgrade=kibo -u’ should do (or ‘--do-not-upgrade=go-ipfs’, its former name) <efraim>looks like it needs more work, heck isn't working <efraim>oh, we skip building heck. that tracks <bdju>civodul: I had run `time guix pull && time guix package --upgrade . --do-not-upgrade pfetch rgbds yt-dlp kubo` but then it still tried to build kubo for whatever reason. didn't try with the old name but it might be worth a shot I guess <civodul>bdju: there’s a trap: ‘--do-not-upgrade’ takes a single argument, a regexp <civodul>that’s why the command above did not have the intended effect <bdju>I swear I've successfully done this before though, and I usually am just modifying commands in my shell history. hm. <isaneran>here I thought file-append was guile and not guix <bdju>so what is it doing then? does it ksip upgrading pfetch but not the rest? <bdju>I have a newer pfetch commit to get support for the env var to remove colors so I always notice right away if I accidentally upgrade (downgrade) that but I guess the rest would be less obvious <bdju>I did somehow end up on an older version of rgbds again once <bdju>if packages were more up to date and not broken so often I probably wouldn't even need this command :( <bdju>wait so is there a way to skip multiple things that actually works or no? <bdju>might just be easiest to remove kubo since I don't actually use it I guess <nckx>bdju: You just made a typo above, no? (--do-not-upgrade a b c ("please uugrade b and c but not a") rather than e.g. --do-not-upgrade={a,b,c} ("do not upgrade a, b, or c").) <nckx>With the caveat that they're regexps indeed. <bdju>I originally copied the command from someone else months ago and don't necessarily understand how it works and have just been modifying it slightly so it's probably too generous to call it a typo <bdju>nothing in my shell history has `--do-not-upgrade=` sadly <bdju>but I will give that a go, thanks <nckx>--foo=bar is equivalent to --foo bar, at least by GNU standards, but using = allows using Bash's {brace expansion} feature as it will expand --foo={bar,bonk} to --foo=bar --foo=bonk. <nckx>Which given the length of typing --do-not-upgrade 4 times, is nice :-) <attila_lendvai>bash has such a fascination level of complexity for... calling a function... :) (the argc/argv mechanism is effectively passing arguments to a function call, only in a rather crude way) <civodul>nckx: hi! did you already get in touch with #savannah re debbugs? <bdju>ugh. maybe I'm sitll doing it wrong. it once again tried and failed to build kubo. I ran this: guix package --upgrade . --do-not-upgrade={pfetch,rgbds,kubo} <bdju>I'm using zsh in case that matters. since it sounded like maybe this is taking advantage of a bash built-in <bdju>BTW why is our yt-dlp version so out of date? I notice if I try the latest release commit the build fails so maybe they changed something that requires reworking the recipe <efraim>I can't find a way to tell cargo to use local crates if they're available, otherwise to search online <PotentialUser-23>would it be acceptable to use a binary blob to bootstrap gnu gnat? (there is no bootstrappable ada compiler) <gabber>can i limit the wait time of U-Boot and GRUB in the Guix boot process? the former waits for 2s while the latter waits for 3 or more - and i'd be ok with them not waiting at all <araujo>podiki, Thanks!, that's what I was looking for <nckx>PotentialUser-23 potentially using logs.guix.gnu.org or whatever: Whenever this has come up in the past the consensus was we'd prefer not to. <nckx>Oh, my comments are aimed squarely at you. <graywolf>Hi, after I reconfigure system (guix system reconfigure), all files in /etc are set to 0400 pretty much preventing normal use of the system. It is fixed with a reboot, however rebooting after every reconfigure is slightly annoying. Two questions: 1. is that normal? 2. is there a way to fix the permissions without reboot? <gabber>this seems to be a rather underdocumented section in the Reference Manual <nckx>graywolf: 1. Never heard of or noticed this. 2. I mean, chmod -R, but you didn't need me to tell you that :-) I'm not aware of a Guixier way because this just sounds like a bug. Messed up umask for Shepherd? Seems unlikely, but it's all I can think of right now. <gabber>ACTION is used to browse the reference in Emacs using (Info-index ..) which doesn't list most of the things i look for <nckx>Oh. Dear. (Yeah, I also don't use the Web site myself, it's just easy to link to.) <nckx>Is this a bug compared to other manuals? I don't browse them with emacs. <graywolf>nckx: Ok, thanks for confirmation. Will try to reproduce in a VM and bug report if I manage to do so. <gabber>i don't think so. but it's a really convenient feature and i think this could use some improvement in Guix <nckx>Is this the same index created by @cindex? I try to add those when writing doxx but it's terribly ad hoc. IWBN if each service field, say, could be automatically indexed. <nckx>Also, I know nothing about Texinfo, did you notice. <attila_lendvai>why is there no assert operator in the guix codebase? is is frowned upon, and i should do something else? <gabber>i haven't noticed and i honestly don't know. but i am (at least theoretically) willing to craft some patches addressing the issue. <gabber>yes, that was directed at you, nckx (: <efraim>can I refer to the profile from a profile hook? <bdju>okay I redid the upgrades again while also adding go-ipfs to the list of things to skip in addition to kubo and it seemed to work. not sure why that was necessary but oh well <bdju>thanks for the help with the proper command nckx <attila_lendvai>civodul, about that match-error coming from shepherd's service-controller: it seems like it's due to (current-process-monitor) being #f in monitor-service-process. is that due to something i broke, or could that be a bug lurking in vanilla shepherd? <attila_lendvai>civodul, it's somewhat tedious for me to check this using vanilla shepherd. if it doesn't ring a bell, then that will be my next step. <civodul>attila_lendvai: something you broke :-) <civodul>i mean, unless ‘make check’ fails on master <civodul>‘current-process-monitor’ is normally initialized early on in (shepherd) <attila_lendvai>civodul, any ideas what could result in this? maybe something with fibers? maybe i inadvertently introduced a continuation barrier? <attila_lendvai>ACTION tries to reproduce it with vanilla shepherd plus an assert <efraim>yay for silly mistakes! I had commented out a line I needed in .cargo/config <civodul>attila_lendvai: without looking at the code, it’s hard to tell, but i’d check the initialization code, making sure each new fiber is created in a context where ‘current-process-monitor’ has the right value <civodul>hoping it will sometimes “hide” the 3–5 second delay on /packages pages <attila_lendvai>civodul, the only place that uses with-process-monitor is where the daemon is started. i assume spawned fibers inherit the fluids. i don't see how such a fiber could be created... but let's populate some assert's into the code then. <efraim>File exists (os error 17) when hard linking /home/efraim/.cargo/registry/src/-5286182263f64851/libc-0.2.148/CONTRIBUTING.md to /home/efraim/.cargo/registry/src/-5286182263f64851/libc-0.2.148/CONTRIBUTING.md <attila_lendvai>civodul, could it be a problem that (start-service root-service) is outside the with-process-monitor block? none of the root service actions spawn fibers that then use the process-monitor? <attila_lendvai>either way, it'd look more sane if that was also inside the with-process-monitor block <efraim>command "/gnu/store/fh47wcwbkpqzjhjkminpfd5pha31ixhx-racket-vm-bc-8.11.1/opt/racket-vm/bin/racket" "../rktboot/main.rkt" failed with signal 6 <theotherone> Hello, I am trying to use the firefox-decrypt package which is a <theotherone> python program. Where is that python program installed? How can <theotherone> I run it? On the github page it wants me to clone the repo and <theotherone> execute "python firefox_decrypt.py". Any help is appreciated :) <janneke>civodul: trying your patch series triggers a world rebuild, is that known/intentional? <theotherone> Hello, I am trying to use the firefox-decrypt package which is a python program. Where is that python program installed? How can I run it? On the github page it wants me to clone the repo and execute "python firefox_decrypt.py". Any help is appreciated :) <jonsger>theotherone: it should show up in your path, see find $(guix build firefox-decrypt) <civodul>janneke: yup, that’s ‘core-updates’, so world-rebuild party! <jonsger>theotherone: it has firefox_decrypt.py in its bin/ folder. So do something like: guix shell firefox-decrypt -- firefox_decrypt.py <civodul>janneke: that’s also why i wanted to check with you whether some of the things in commencement.scm could be #:parallel-build? #t <theotherone>jonsger: It worked, thanks for the quick response :) <janneke>civodul: good; yeah if #parallel-build? #t works, i'm all for it :-P <civodul>i’m guessing it won’t work for old versions of GCC <civodul>because back then every computer was single-core <janneke>i'm hoping me (and/or others) didn't start by adding #:parallel-build? #t "just to be safe", but i really don't know <jonsger>ACTION works on icedove@115. icedove-minimal already building. Still working on the l10n version... <efraim>civodul: I'd like to skip strip and ldconfig on some of the packages in commencement. strip gives the output of 'strip --help' which doesn't help and ldconfig isn't available in some of the early packages <civodul>janneke: i’ll give it a spin on my next rebuild <civodul>efraim: for commencement.scm, i’m all for optimizing package definition size <civodul>so if the extra work doesn’t cause troubles, i’d leave it <civodul>(rather than add lines + comments to fiddle with phases) <janneke>civodul: great; re c-u and world rebuilds: sure, but (your) earlier patch set(s) didn't trigger such a wide rebuild so np...but always best to check <podiki>speaking of, is core-updates being built/moving to merging? <podiki>I might go for another quick mesa update and to get the xwayland updates in (security fixes but depends on newer xorgproto and thus lots of rebuilds) <janneke>civodul: re parallel-builds, did i show/tell/ask you about this nixos derivation for mes that supposedly would create a separate derivation for most/each C file in mes so that the mes build could be parallelized ca 100x? <janneke>ACTION is not sure where they heard about it... <civodul>we could resort to that, but only if the complexity/performance gain ratio is very low <civodul>podiki: it’s slooowwly moving to merging IMO <civodul>that is, i’d like to finish glibc-related changes and then move on <janneke>civodul: i think it's about 20-30min on x86_64, but it could be 24h on riscv <podiki>civodul: ok! I'll send out a quick message to guix-devel then too; my preference would be for a quick build on mesa-updates for mesa+xorgproto+xwayland (the last the main motivation with CVEs) <civodul>podiki: makes sense; i guess ‘mesa-updates’ may be ready sooner than ‘core-updates’, esp. if these are only “reasonable updates” <podiki>the question will be xorgproto as it has the most dependents (required for xwayland update) but I guess only one way to find out.... <podiki>so just those 3 patches but I'll ask around and search; but yes, limited scope just to get to xwayland update <attila_lendvai>civodul, Assertion failed: (current-process-monitor); i.e. i've managed to reproduce the match-error with a vanilla shepherd + an assert. i'll try to extract a test case now. <civodul>lilyp, apteryx, raghavgururajan: what’s the status of ‘gnome-team’? mergin’ soon? <civodul>i’m asking because we have a glib test failure on ‘core-updates’ <civodul>so i wonder if we should fix it/work around it ourselves or wait until we get updates from ‘gnome-team’ <civodul>PotentialUser-70: hi! there are two ‘services’ field in the config, hence the error <civodul>to address that, you have to keep a single ‘services’ field <civodul>its value would become: (append (list (simple-service 'my-cron-jobs …) …) %desktop-services) <PotentialUser-70>thanks, looks like it worked, I thought that desktop and base services are independent and couldnt understand what causes the problem <PotentialUser-70>Also I heard that cons are faster than append list, is this true and if yes why? <reedm>Hi All. I'm trying to ssh into a VM I created with "guix system vm". When I do the ssh command, nothing happens (i.e. no error). Here is some info: <attila_lendvai>civodul, shepherd's fork+exec-command should redirect both stdout and stderr into #:log-file, right? stderr is not showing up for me. <attila_lendvai>err, no, it's not that. somehow guix --help fails to output anything when run in that env, while the output of ls shows up as expected <vivien>civodul, we’re waiting for a final approval of apteryx to merge the world-rebuilding changes in gnome-team, then we can check that QA builds the leaf applications, then merge. That’s what I understood. <attila_lendvai>strange: all i'm doing is replace /run/current-system/profile/bin/guix --help to .../ls --help, and the output shows up as expected. it's in a fork+exec-command in a service's start lambda. <vivien>There are other world rebuilds than #67473 #67582 but I’m not sure the others are ready <attila_lendvai>FTR, i had to add a sleep to the start lambda, so that the fork has enough time to run, and the output to show up in the log <efraim>janneke: I built mes on riscv for ekaitz, a successful build IIRC was just shy of 4 days <janneke>civodul: so I lied, and it's even worse^^^ <efraim>I don't think there are any other 4 day builds on riscv64 <janneke>efraim: didn't someone have a million riscv cores available or something like that ;) <janneke>efraim: yeah, stikonas told me as much <janneke>he believes it's [probably?] caused by how mes handles memory, mes' memory management, iiuc <cow_2001>hello. i just noticed that when i run `. ~/.config/guix/current/etc/profile', info does not look for files in the system /usr/share/info directory. it is guix installed on another distro <cow_2001>INFOPATH is just the guix stuff, not the system stuff <cow_2001>when i `unset INFOPATH', it looks for files in /usr/share/info <janneke>hmm, so a logical question to stikonas or efraim would be: how troublesome, or how much faster, is building mes with guile, any idea? <efraim>I think that was with guile, I'll have to check the mes repo to see what the default was when I was running the builds <janneke>the default should be to build it with mes <janneke>unless you use MES=guile somewhere, which is meant for debugging only <janneke>efraim: yeah, could be; if there's guile it will even compile .go files; but not use it for running mescc <cow_2001>oh well, i'll just add an INFOPATH="/usr/share/info:$INFOPATH" at the top <efraim>configure: error: Valgrind is operating system specific. Sorry. <ekaitz>janneke: do you have any idea about how to make mes faster? maybe we can play around with it a little <janneke>ekaitz: no, i don't; not an easy way, tho <janneke>ekaitz: i suspect that macro expansion should be handled better/cached harder <ekaitz>janneke: i didn't really read how it is done, so I can't really suggest anything <janneke>also, the garbage collector sucks, but i don't think it's the bottle-neck, although it might be <ekaitz>if we have too much indirection (lists do have many) it will make a heavy use of memory <ekaitz>if it's intended only for compilers, we could just switch the GC off :) ? <janneke>if replacing/rewriting the garbage collector would help, that could be a relatively non-intrusive effort <janneke>ekaitz: the first versions of mes didn't have a garbage collector, mostly inspired by SICP's suggestion that garbage collectors would probably be obsolete for non-durative programs "a few decades from now" <janneke>but to compile mes/tcc, you need more than 16GB of memory <ekaitz>janneke: but I do have more than 16 GB of memory :) <janneke>you can set MES_ARENA and MES_MAX_ARENA to delay garbage collection <ekaitz>the riscv hardware doesn't have that much of ram sadly <janneke>being able to build mes without garbage collector (and comparing it to a regular build) could give a nice indication of how problematic it is <stikonas>well, mes is an interpreter, so naturally it might be quite a bit slower than compiled programs... <janneke>yeah, pre-scheme/guile-steel should help us with all that! <ekaitz>in any case, if we want to improve this with a little effort we need to know what affects the hot path <stikonas>at some point I tried running it in valgrind <ekaitz>the GC obviously takes part, but something else could be <stikonas>and significant amount of time was spent it <stikonas>(in eval_apply() function to be more precise) <ekaitz>but that probably does everything <stikonas>so maybe using switch could make it faster... <janneke>yes, long ago i did quite some work on performance (measurement) <ekaitz>5% doesn't really make sense to try to improve <janneke>it only doesn't perform any AST transformations <ekaitz>it reads directly the AST, right? <janneke>well, most functions are executed several times in one mescc run; some for each statement <ekaitz>if someone is really motivated, making a small stack machine and ast->vm transformation could help <ekaitz>i may take a look into it though <attila_lendvai>civodul, moving the root-service inside with-process-monitor seems to fix the issue. i'm double checking now, because there are too many moving parts here (i couldn't extract a unit test). <attila_lendvai>civodul, hrm. is (current-process-monitor) valid when (guix scripts system reconfigure) calls into shepherd? i'm looking at upgrade-services-program, which is eval'ed... not sure how it gets hooked into the shepherd process, though. <reedm>Hi All, when I create a VM with "guix system vm", should the disk names in the VM match the names in the config file? Currently, when I put (device "/dev/vda2") for the config file, I still only see vda1 when I run lsblk in the VM <attila_lendvai>civodul, my previous hope i think is wrong, it's not fixed by that. and i suspect that reconfigure has something to do with this. <lilyp>civodul: fix it on core-updates if it's headed for master; I make sure to pull semi-regularly <lilyp>re "soon" I sadly don't have an ETA yet for gnome-team <attila_lendvai>hrm. herd.scm eval-there calls the 'eval action of 'root. it goes through the daemon listening on the socket, so (current-process-monitor) should be valid even in vanilla shepherd... but i'm exploring a foreign land here. <attila_lendvai>civodul, i'm pretty certain now that reconfigure is playing a role in triggering this assert <attila_lendvai>civodul, so, to sum it up: (current-process-monitor) is #f when i enable and start a disabled service after a reconfigure. it's disabled because it keeps failing. <bdju>hm got back to my PC and swaylock didn't show the typing notifier thing so I pkilled it from ssh but now it turned red <civodul>attila_lendvai: ooh; do you think you could come up with a test that triggers it? <civodul>janneke: on master i’m getting “qemu-system-x86_64: CPU model 'host' requires KVM or HVF” on “make check-system TESTS=childhurd” <bdju>okay it was actually a keyboard/usb switch problem, my inputs werne't going through. ran swaylock again over ssh and then unlocked it after I got the keyboard working <janneke>civodul: no haven't seen it just yet <peterpolidoro>when using the gnu-build-system is there any way to tell it to use only a single directory within a larger git repository? <sneek>samplet was last seen in #guix 13 days ago, saying: janneke: I remember you saying that, and my working is not making it better, exactly. It would be nice to settle down and work on speed and legibility. Modules was a disruptive change, and ‘syntax-case’ is going to be rough, too.. <peterpolidoro>or should unpack be modified to only unpack a single directory? <apteryx>uh, the qemu info doc has silently vanished <lispmacs[work]>Hi, is anyone using Guix with TPE-n150USB wireless adapter from thinkpenguin? <attila_lendvai>civodul, i don't know enough to write a test yet, and i suspect that by the time i know enough, i'll know the fix, too. i'll keep digging. <attila_lendvai>ACTION groans when realizes that his log line was truncated by syslog, and with that it steals 10+ minutes of his life <psyleft>Does anyone have experience hacking on wlroots in guix <psyleft>The default package doesn't seem to have to x11 backend header file