IRC channel logs
2023-02-23.log
back to list of logs
<lechner>do i need the #f in my serializers, though? <lechner>you were talking about the stuff that was commented out, right? <mirai>(format #t "~a ~d\n" field-name value)) <wdkrnls>What does this -L flag do in things like guix edit and guix repl? <wdkrnls>Can it be used to edit in a copy of guix repository instead of the module union? <wdkrnls>I guess, I'm confused to what extent these things can be edited atleast for the current session. <lechner>mirai / okay, i changed it everywhere, but still the same error <lechner>mirai / bummer. thank you for your suggestions so far! <lechner>i think i have some kind of gexp problem. now it also does not deploy even without the explicit config <apteryx>it warns about "bytes of junk" at some places, and this is exactly where things seem to go wrong (after the 98th file, ./gnu/store/1klwvqm3njp070h982ydcix1gzf2zmdl-nss-certs-3.81/etc/ssl/certs/988a38cb.0) <haugh>lechner, are you asking about match-record generally or this specific extraction? <lechner>whenever i try to set cache-directory in the usual way, i get Invalid keyword: "/var/cache/fscache" <lechner>this is my first service, and i am a beginner <lechner>it is also a reduced version. the full version works if i set the string in the configuration record, but i cannot modify it. the cache directory should really be given explicity because it will take up a lot of space <lechner>i guess you only offered a finger, and i took the whole hand <apteryx>what are strings in Guile? Does string-length return the right thing for multi-byte characters? <apteryx>ah, it's really a string, e.g. a higher level representation: "Guile stores each string in memory as a contiguous array of Unicode code points along with an associated set of attributes." <apteryx>I think the limitation is from the cpio format <apteryx>it can't cope with non-ascii strings <bjc>i'm pretty sure pax can do utf8, which means gnu's cpio should as well <bjc>my filesystem is zfs with utf8 form d normalization <lechner>apteryx / i think you have it right. Guile strings are decoded UTF-8 bytevectors. <apteryx>Perhaps something to do with the way (guix cpio) works then... <bjc>oh, is it not just shelling out? <lechner>what are the symptoms you are seeing? <apteryx>basically the file name is written to the archive via (put-bytevector port (string->utf8 file)), which should be fine <apteryx>there's a Scheme cpio generator at (guix cpio) <apteryx>and the rpm format of guix pack relies on (guix cpio); that's how I got into the issue <apteryx>(because the payload of a .rpm is a cpio archive) <bjc>it does sound like a bug. but there are a bunch of different cpio implementations (along with tar, which is basically the same). which is what gave rise to pax <bjc>maybe the guix/guile one is just old? is there a compelling reason not to just shell out to gnu's implementation? <apteryx>it works fine outside of this corner case so far <lechner>as far as i know, filenames are always bytevectors and should probably remain that way. i have been tempted to treat them as Unicode, but one has to do so in parallel because the same string can have two different bytevector encodings, which would refer to two different files on disk <bjc>the problem in my mind is that handling non-ascii text isn't a corner case to me, and is becoming less and less of one with each passing day <bjc>unicode normalization doesn't matter in this instance. it's used for comparison, collation, and other such things <apteryx>bjc: one reason is that we already have it, so if it's broken we should fix it. the second reason we try to have as much of the logic implemented in Scheme, because that's more hackable <lechner>two files are different when those representations are different, even if they compare as the same <bjc>but yes, it shouldn't be interpreted as utf8 arbitrarily <bjc>apteryx: i don't find those compelling reasons, but i'll admit i'm the odd one in this group for having that opinion. =) <bjc>i thought maybe it was a case of bootstrapping, since we need cpio at a pretty fundamental level, so introducing a dependency on gnu's would be problematic <apteryx>the ports are configured via (set-port-encoding! port "ISO-8859-1") in (guix cpio), which is synonymous to "binary mode", IIUC <apteryx>but anyway we don't write text, we write byte vectors, so that should be immune to any encoding? <bjc>in general i don't think that's true, but it could be true <apteryx>e.g., (put-bytevector port (string->utf8 file)) <bjc>if ‘file’ is iso-8859-1, then converting it to utf8 and then writing that bytevector out will corrupt it <bjc>the filename should come in as a byte vector and leave as a byte vector and never be anything else <lechner>i think guile may also do some input and output encoding, but i have not verified what i read in the manual recently <bjc>if guile's strings are internally utf8, then ‘file’ should probably not be a string <apteryx>guile strings are not utf8, they are unicode (code points), IIUC <bjc>ok, but it's the same problem <bjc>not all latin-1 sequences are valid unicode, and the reverse is even more true, so conversion via reinterpretation of bytes, rather than translation, is going to fail in a number of cases <apteryx>bjc: having bytevectors for file names could make sense in narrow situations where you don't need to know their string representation, but that's probably not very general <bjc>yeah, it's a real pain. i agree <apteryx>e.g. the moment you need to compare a file name or manipulate it, the encoding problem's head is back <bjc>i don't have a good answer for you there. it's a complex problem <apteryx>as you'll then have to choose, out of random, an encoding likely to work, and you'll probably pick UTF-8 <apteryx>(to decode the bytevector into a string you could work with) <bjc>i don't think there's a way to take an arbitrary string in some encoding and compare it to a sequence of bytes with no encoding, in a way that will work 100% of the time <apteryx>perhaps looking at the cpio in hexl-mode (emacs) could yield clues <apteryx>not sure if I'd see the correct characters if it was well encoded, but currently I see: _F?tan.s.tv.ny.pem <bjc>what's got me scratching my head is that cpio is complaining about junk bytes. i don't know why cpio would care about encoding, so maybe this is byte counts being off in the header? <apteryx>it seems to make sense with the amount of accentuated characters (potentially corrupted ones) <bjc>i would think the worst degenerate case would be that guix's cpio would write out a bad filename due to encoding issues, which cpio would happily replicate <apteryx>in the above file there's 4 characters (4 bytes for cpio, if it considers 1 char = 1 byte) <bjc>so this could be a codepoint-count vs. byte-count issue? <apteryx>I don't know that the real cpio does to list the files, but on guile side I've verified that string-length returns the correct thing <bjc>it's the length of the string in bytes? <apteryx>so perhaps that's the issue, if the logic assumes these are all bytes <bjc>i just checked: guile is returning the length in bytes, not code points, for a string: (string-length "👆") ⇒ $5 = 4 <apteryx>(string-length "Főtanúsítvány.pem") returns 17 <bjc>how are you checking this? through the guix repl? <bjc>oh, from just “guix repl” i'm getting 17 for that string <bjc>i cannot fathom what the difference is <apteryx>I'm trying to recover from the manual how locale affects this <daviid>bjc: scheme@(guile-user)> (string-length "👆") => $3 = 1 <bjc>yeah, i don't know what's going on. i get 1 from guix repl for that, but not from geiser <bjc>anyway, that's definitely going to cause problems, because that sequence is 4 bytes, not 1 <apteryx>yes, I think you've found the likely source of problems <apteryx>thanks for entertaining the debugging! <daviid>bjc: string-length must return the length in chars, not in byte, that is by scheme spec <bjc>now i can go to bed wondering what eldritch horrors lurk between my geiser repl and my command line one ;) <bjc>yeah, chars makes sense. but old unicode implementations have been known to use bytes instead <daviid>bjc: i use geiser, which simply offers a nice elisp based interface, it does not change any of the guile core procs, methods ... fwiw <bjc>i must have something in my config i forgot about somewhere <bjc>(not that i know why i would ever want to change this behavior) <lechner>i get 1 in the Guile REPL and in Geiser <apteryx>so I'll replace string-length with bytevector-length and use the bytevector representation instead of the string <daviid>bjc: you may ask for some help to diagnose on #geiser <lechner>you have to use the original bytevector representation, not a new encoding <bjc>daviid: i will once i dig into it a bit more <apteryx>the input is a list of file names, provided as strings <bjc>you list them in the rpm build script <apteryx>so I gamble with (string->utf8 filename) <apteryx>I mean the 'write-cpio-archive' from (guix cpio) current API takes FILES, which is a list of strings <lechner>i guess they should also require that they are normalized UTF-8 <lechner>your bug may be elsewhere, or one of the tools did the encoding for you. they are smarter than you think. there are a lot of layers <apteryx>I'll keep looking a it, but for now... bed is calling <lechner>by the way, i think the last thing i said about UTF-8 and Unicode not having a one-to-one mapping may be wrong. bedtime for me also <apoorv569[m]>Does the emacs package in the original Guix repository uses native-comp branch? <AwesomeAdam54321>apoorv569[m]: Yes, since the native-comp branch has already been merged in Emacs 28 <apoorv569[m]><AwesomeAdam54321> "apoorv569: Yes, since the native..." <- I see. Thanks. <nckx>lechner: Does that mean the Feds postprocess zany packages like nss-certs themselves? Or is their build environment such that it gets magically UTF'd? Or something else? <nckx>I don't think mandating an encoding in Guix-the-PM is desirable. Guix needn't accept any old garbage (rules like what's an acceptable store item name are, if anything, too strict), but imposing 'distro policy' rules on not only *all* channels/users but the installed *contents* for the PM to even work is a red flag IMO. <sneek>civodul, you have 1 message! <sneek>civodul, ArneBab says: is it OK if I create a WIP branch in the guile repo for different multi-language handling (i.e. being able to import elisp-code from Guile without adding -x to the commandline)? <opty>gabber: hello, i asked on #gentoo :) <cel7t>Hi, apologies if this is the wrong channel to ask this, but are there any GSoC projects for Guix that use Guile? <AwesomeAdam54321>cel7t: Yep, one of them is implementing a replacement build daemon for Guix in Guile <cel7t>AwesomeAdam54321: Those both sound super interesting, are there any skills you would recommend acquiring before applying for them? I've been using Scheme and Lisp for about 3 years, but I'm rusty at other languages except C/C++ <cel7t>Additionally, does Guix have a prior contribution requirement? <AwesomeAdam54321>cel7t: I think the only skills needed is experience with Guile Scheme, Guix can be learnt along the way <cel7t>Oh, no worries about that. I've been a Guix user for a while, albeit on a foreign distribution :) <opty>gabber: thanks but i'm afraid i'll have to ask my vps provider <pkal>Is the hackage import broken? <civodul>is the list of accepted GSoC orgs public yet? <Arjanhehim[m]>Is there a way to specify file permissions in home-files-service-type extensions? <Arjanhehim[m]>specifically permissions of the directories that are potentially created by extensions <civodul>Arjanhehim[m]: hi! looks like we can't specify permissions <bjc>i do it with ‘computed-file’ <bjc>it could do to be easier, though <civodul>bjc: that lets you choose between executable and non-executable, right? <civodul>because it's always going to be world-readable and read-only anyway <bjc>i use it to set the x bit, yeah <bjc>but it's just calling ‘chmod’, so the sky's the limit <bjc>are you saying if i set the file 400, guix will make it 644? does it use umask? <bjc>sorry, 444. 644 wouldn't make sense <attila_lendvai>bjc, i think he means that it'll sit in the store world-readable <bjc>the entity in your home dir is a link to the store, though, so realistically, the only thing it *should* change is the x bit. or maybe the the s/t bits <bjc>i just haven't checked if that's true or not <apteryx>hm, 'guix deploy some-machine.scm' -> error: %system: invalid field specifier, where %system is bound to my operating-system definition <Arjanhehim[m]>my use case is that I am generating .gnupg/gpg-agent.conf, but I want .gnupg to not be world readable <bjc>i don't think that's possible, since the guix demon has to be able to access it in the store <Arjanhehim[m]>the directories seem to be created by home-symlink-manager-service-type at activation <bjc>ohhh. the directory, not the file. sorry i missed that detail. that may be possible <graywolf>Hi :) How can I guix deploy home-environment configuration? It seems the guix deploy command is only for operating-system? <civodul>graywolf: yes, it's only for OSes; what would it do for home environments? :-) <attila_lendvai>if i have the qemu-binfmt-service-type service, and i'm running `guix build --system=aarch64-linux ...` to test cross compilation, then am i fooling myself? i mean, it seemingly works, but could it be that it's not a true cross compilation, but rather running the arm binaries in qemu? <civodul>attila_lendvai: --system is native compilation, not cross compilationm <civodul>but "native" compilation can go through qemu-binfmt <graywolf>civodul: Well it would run guix home reconfigure over the network, same way guix deploy does for guix system reconfigure. At least that was my thinking of what I would like it to do. <civodul>i guess it could be useful if there's a bunch of machines you'd all like to manage at once <Arjanhehim[m]>regarding permissions in home: would it make sense to have a separate home-permission-manager-type or to try to make home-symlink-manager-type handle that? <florhizome[m]>seems like the environment variables of my emacs profile aren't activated anymore automatically. Did something change that could have motivated that? <graywolf>So for the time being best I can do is shell script that would scp the required files and run guix home reconfigure over the ssh? <apteryx>what do you use to configure multi-display before a live presentation? I don't want to mess with xrandr in that setting. <florhizome[m]>> seems like the environment variables of my emacs profile aren't activated anymore automatically. Did something change that could have motivated that? <florhizome[m]>PATH, EMACSLOADPATH, etc used to be set by the script i put in my .bash-profile to activate my emacs profile on startup... they seem to be omitted now <attila_lendvai>civodul, i'm working on building shepherd from git. when i cross compile, then it fails on "help2man: can't get `--help' info from ./shepherd". any hints how to proceed? or is this failure kind of a showstopper? <civodul>attila_lendvai: "guix build shepherd --target=aarch64-linux-gnu" works for me though <attila_lendvai>building it natively only for capturing the output of ./shepherd --help, is kinda overkill. <civodul>ah but wait, that's because man pages are in the tarball <attila_lendvai>civodul, yes, because (i assume) the doc is not built when working from the tarball <civodul>so that's the thing: you can cross-compile it, but only from the tarball <civodul>apteryx: hi! you still need randr one way or another to set things up; then we EXWM i arrange to have the browser on one monitor and the shared screen on another one <attila_lendvai>civodul, let's sync assumptions: 1) do you think it would be a welcome improvement to compile shepherd from git? and if so, then 2) do you think that it's worth fixing cross-compilation? <apteryx>civodul: OK! thanks for the tip. I was hoping for some XFCE or similar display setup utility <civodul>yes, it still talks randr under the hood :-) <apteryx>ah heavy option seems gnome-control-center -> displays <bjc>civodul: if only someone had put together a guix manifest for building shepherd from source in #60636 ;) <florhizome[m]><florhizome[m]> "> <@florhizom:matrix.org> Hey..." <- hm curiously my .bash_profile script got deleted. reconfigured guix home; hope things will be fine now... <gabber>i get this somewhat strange error: "a `aarch64-linux' is required to build foo, but I am a `x86_64-linux'", after trying a `guix build --system=aarch64-linux` https://termbin.com/938g <attila_lendvai>ACTION is working on that patch though, and planning to send it as a standalone debbugs issue <bjc>my manifest is stand alone, so it doesn't get any of the gnu build system goodness. i'd be happy with either going in <graywolf>Is there a way to force elogind to create XDG_RUNTIME_DIRs for a list of users on boot instead of waiting for their login to happen? <graywolf>Or other way around, is there a way to force it to not manage XDG_RUNTIME_DIRs at all (and I would create them manually)? <civodul>attila_lendvai: in general there's some consensus that we should be building from checkouts rather than tarballs in the long run <civodul>but, it's tricky, as this example shows <civodul>so the first step would be to see if we can arrange to have man page compilation work in the cross-compilation context <civodul>off the top of my head, i don't see how to do that <civodul>which is why the status quo is so tempting :-) <ellysone[m]><lechner> "ellysone / what kind of terminal..." <- Hi! I tested the format,display ocmmand when i Was in bash <attila_lendvai>civodul, hehh :) how about running help2man by hand and checking in the result in the git repo? or... help2man is not much more useful than not having a man page at all. maybe just eliminate it? <gnucode>civodul: would using openBSD's man page software help to have "man page compilation work in the cross-complation context"? <attila_lendvai>gnucode, help2man simple turns ./my-binary --help into a man page. but you can't run the binary when you're cross compiling... <gnucode>attila_lendvai bummer. I thought I might be a little my head. :) <opty>can i disable an optional pam module or do i have to uninstall it? <gnucode>I'm going to go back to learning how to use conman... <civodul>attila_lendvai: running by hand and checking in the result sounds bad <civodul>we could add if CROSS_COMPILING around the relevant bit though <ellysone[m]>> <@lechner:libera.chat> ellysone / what kind of terminal are you in, please? <ellysone[m]> * Hi! I tested the command when i was in bash, your command does works for me, the problem was that I was expecting a plain (display "\\033)[1;4m FOO \\033 \n") to work <attila_lendvai>civodul, but... do you think that man page, in its current form, has enough value to even bother with any of these? <ellysone[m]> * Hi! I tested the command when i was in bash, your command does works for me, the problem was that I was expecting a plain (display "\\033)\[1;4m FOO \\033 \\n") to work, thanks for the tests <ellysone[m]><nckx> "ellysone <guix system image..." <- I did try with the -e flag it did not work, probably because of syntax reasons, but in the end I chose to write a guile wrapper around guix system image. <gnucode>how does one use connman with iwd? does iwd need to be installed in my user's path? <gnucode>I guess I could just use wpa-supplicant instead. <ellysone[m]>how do you test a service for guix ? I have writtend a rspamd-service-type and it works on my local channel, now I want to try it with the real thing <ellysone[m]>./pre-inst-env guix time-machine -C /home/user/.config/guix/channels.scm -- system reconfigure /home/user/dotfiles/guix/config.scm <ellysone[m]>is what I did but of course it needs sudo, can I just ru nthis outside of the guix shell env ? <gnucode>ellysone[m]: I don't think you want to use time machine...I think it would be better for you to set up the developmental environment as described in the contributing section of the guix manual. <gnucode>then add in your rspamd-service-type to /gnu/services/spam.scm (or maybe misc.scm). <gnucode>then you could do a ../configure --local-state-dir=/var && make && ./pre-inst-env guix system reconfigure config.scm <gnucode>if that works, send a patch to guix patches. <ellysone[m]>okay and how do you like add custom channels for the reocnfigure command? Because I have code that depends on some other chnnels in my config.scm <ellysone[m]>and I did not see a --channels flags for reconfigure? <civodul>ellysone[m]: i recommend testing services in a VM: ./pre-inst-env guix system vm ... <mirai>you can write a system test for the service as well <gabber>sooo, i've built some images for aarch64 yesterday, got reminded that my Guix was almost 3 weeks old, pulled today but now the images won't build anymore. i've rolled back my Guix generation, but now i get "guix perform-download: error: <hash>-linux-lihbre-6.1.8.tar.xz.drv is not a fixed-output derivation". how can i go back to building these images again? <ellysone[m]>I'm getting a completely unrelated error when I do make check <ellysone[m]>guix/import/cpan.scm:357:2: Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<syntax-transformer <upstream-updater>>) ())'. <civodul>ellysone[m]: try "make clean-go && make" <attila_lendvai>can i run 32bit binaries on my x86_64 guix system? the binary has been produced on the same system using `clang -m32` <attila_lendvai>err, wait... i guess i'll need to specify the i686 targets from some of the inputs. this will be complicated... as the project can produce both 32 and 64 bit binaries. <graywolf>Hm, I'm bit stuck. Could someone point me an example of how to create a directory via the services field? I guess I want something like extra-special-file, but for directories (with chown and chmod support). <lechner>ellysone[m] / Hi, the escape sequence may not be specified correctly in your display usage. i am very new to #guile and recommend asking about that over there <lechner>ellysone[m] / i may like to use your rspamd service as well. thanks for working on it <civodul>mirai: hi! i think %host should not have been exposed; that was my intent anyway <mirai>civodul: btw, #61888 does some documentation clearups regarding host-service-type <mirai>from observations done in help-guix <gabber>wait, where's the snackin' bot?! <mirai>if %host is unexported, perhaps the snippet describing the "true constructor" can be demoted to a comment in the texi manual OR the text can be transplanted into system.scm <ngz>Uh oh. It seems I started a world rebuild at the build farm =/ <civodul>mirai: yup, i was looking at these patches <graywolf>Uff, I finally managed to figure out how to create /run/user/UID, now I only need to convince elogind not to remove it on logout <gabber>AwesomeAdam54321: i meant the one posting links to issue numbers :) <bjc>graywolf: the xdg specifies that the runtime dir can only exist during a login session and must be removed on logout <bjc>that said, systemd has a linger option, so as an opt-in thing it may be valuable <graywolf>bjc: Well that is great, I did not know. I guess my system will not be compliant then. <patched[m]>Is anybody here a user of blesh? I have installed it but have no clue how to properly source it. Sourcing the ble.sh file in the store does not work. <graywolf>But I'm confused how this is supposed to work. When I do `su - USER', the XDG_RUNTIME_DIR is *not* created for me. But guix-home's on-first-login requires it to exist. <bjc>iirc elogind/greetd create it on login <mirai>graywolf: its not a login shell <ngz>civodul: Touching texlive-latex-fancyvrb in commit 7a01586afe9b65acc0a298b699a66fb187dd7b4f triggered a 17k packages rebuild (from all platforms). I think we need to stop the build, and revert that commit. It will break texlive-minted, but it is possible to add a fixed texlive-fancyvrb in master and use it. WDYT? <mirai>under systemd you'd use machinectl -q shell <graywolf>mirai: `su - USER' is a login shell, no? At least based on the man page. <mirai>ok, maybe I said the wrong thing <mirai>but I mean to say that su doesn't start a session <mirai>it doesn't go through elogind <bjc>on full systemd systems it goes through pam_systemd, so ‘su -’ should work (though i can't test that atm) <bjc>this may be an oversight in elogind <graywolf>Yeah I assume that is the reason. But I'm unsure how am I supposed to get the XDG_RUNTIME_DIR in that case. If I create it manually, elogind just nukes it on log out. <civodul>ngz: oh got it; you can revert that commit as the first step <bjc>what are you using XDG_RUNTIME_DIR for? <civodul>then the 'replacement' field makes no sense for texlive packages <graywolf>bjc: Nothing (at this moment), but scripts created by guix-home do require it to exist. <bjc>oh, is this for your deploy guix-home stuff? <ngz>civodul: I just meant to create another (forward-looking) variable, named texlive-fancyvrb side to texlive-latex-fancyvrb. <bjc>i would think it's ok to create it for the duration of the deploy. nuking it afterwards seems fine to me <graywolf>Funny is that the `guix home reconfigure' itself does not require XDG_RUNTIME_DIR, that works just fine, but `su - USER' then has that nice warnign every time when I run it. <ngz>civodul: Reverting done. <bjc>‘guix home reconfigure’ is done while logged in, though, so i'm not sure how you'd get that warning without jumping through hoops <graywolf>guix home reconfigure is done after `ssh root@...' and `su - user' and `guix home reconfigure'. Since it is cleanly installed system, there is nothing to produce the warning. After the reconfigure finishes, and I ^D and `su - USER` again, I get the warning. <bjc>i'm also not sure that warning is a problem. isn't the ‘on-first-login’ script executed the first time someone actually logs in? so if you're not, who cares? <civodul>ngz: actually possibly i didn't understand; this is part of a patch series, right? <gabber>what's the easiest way to test Guix services in a vm? i've set up a user (with group wheel) but the password is not settable (or i don't know how) and sudo asks for a password.. <graywolf>bjc: I'm not sure either if that is a problem :) By I often use my machines by ssh-ing into root and then user-hopping via su, so it is annoying if nothing else. <ngz>civodul: It is a part of a patch series indeed; its sole use is in commit adc0e3b4853fa0a9c12e19ad5febc6656722e855. <bjc>i'd say it's a problem that ‘su - user’ doesn't set up XDG_RUNTIME_DIR, even if it's not a common case <graywolf>bjc: The variable *is* set up, but the directory *itself* is not created. <bjc>but in terms of just running a ‘home reconfigure’ from deploy, i don't even think you should be using a login shell for that from su <bjc>i mean creating the directory. xdg allows for the variable to not exist and default to /run/user/uid <ngz>civodul: Apparently, it hadn't been built on qa.guix, or this would not have happened. <ngz>the 17k rebuild landing on the CI. <graywolf>bjc: At this point I'm not trying to run the home reconfigure from deploy, I'm just trying to use it normally. But since this is headless machine, I often use it (when actually using it) by ssh-ing in as a root and then switching (using su -) to multiple user (each's home I would like to have managed by guix home). So actual login via elogind on that machines only ever happens for a root. <civodul>ngz: qa.guix and ci.guix are two different things; so it may be that substitutes are available at bordeaux.guix (which is roughly the same as qa.guix) but not at ci.guix <civodul>ci.guix will always build things once they've been pushed <graywolf>Hm, I guess simply not having elogind is an option. Not like I need power management on the server. <ngz>civodul: I cannot remember if it was built on qa.guix already. <gabber>is there an easy way to see which exact command `herd` invokes when starting a service? the logs only say "bad command line options, try --help" <bjc>graywolf: i see your problem. i'm curious how ssh works correctly when su doesn't though. maybe whatever ssh is doing can be mimcked in su? <graywolf>I would assume ssh goes via pam so it would work. I don't have enough knowledge about su to know if it could be mimicked. <graywolf>It looks like loginctl --enable-linger USER does work (someone mentioned the linger thing), so I'll just stuff that into one-shot shepherd service and call it a day. <civodul>sneek: later tell gabber you can view what command a service run with "guix system edit SERVICE" <ellysone[m]><gabber> "is there an easy way to see..." <- I'd like to know that too ;( only way I found so far is to lookup the service definition in the source <mirai>civodul: I'm intending to deprecate service returning procedures like #61692 to (service ....-service-type) as part of a plan to improve the consistency of the manual (and do away with our @deffn texi commands), is there a preference for patches to be sent individually by service or should I bunch them up for a big patch series <civodul>mirai: good idea! while at it, you can also remove procedures that have been deprecated since, say, before 1.3.0 <civodul>there are quite a few of them i think <mirai>they're numerous so the whole enterprise will take a while <mirai>I assume the rationale in #61693 is acceptable as well as criteria for the "big-sweep"? <mirai>aka not-documented = remove straight away <mirai>"if it ain't documented then it don't exist" <mirai>though in honesty the situation above is about "guix internal code" <mirai>not really meant to be used as "public" API <mitchell>I think that code should be documented too! <mitchell>Indeed i've learned a lot from the comments littered through the code base <mirai>I think the manual should mostly be about user facing procedures <mirai>or developer, doesn't matter <mitchell>Or perhaps take the emacs approach and have two manuals, one for the user and one for the elisp side <civodul>mirai: well, removing right away, even if not documented, can be problematic <civodul>better have a deprecation period first <civodul>(there was a time when fewer things were documented) <singpolyma>Has anyone played with generating AppImage using guix? It seems like it could maybe be a mode of guix pack similar to the existing squashfs one but I'm not sure how different the AppImage format is <nckx>ngz, civodul: I took the liberty of cancelling those 17k builds (well, that was before I knew someone was already on it :) on berlin. <nckx>singpolyma: Vague, but I remember $omeone wrote a script that took a Guix profile(?) and turned it into an AppImage. It didn't do so using Guix, but using AppImage's SDK or whatever they call it, but at least it proves that what Guix produces is AppImagable. <nckx>So I guess it didn't go anywhere after being birthed fully formed. Pity. <mitchell>What's the gpg incantation used to generate .key files guix authenticate can understand? <mitchell>Ok! These words are all mentioned in the manual but perhaps a full example command could be useful. Or perhaps I am not as familiar with gpg as i should be <nckx>Is ‘guix authenticate’ a typo? <nckx>Oh good. I was confused. <mitchell>Which should probably be it's own project. It's a pretty useful tool and there aren't any others like it that i've seen <nckx>You're referring to the ‘and store them in’ text in the manual, right? <nckx>mitchell: Oh, interesting. <nckx>I've never considered its usefulness outside of Guix. <civodul>nckx: thanks for cancelling those builds! i never know how to do that actually <mitchell>Yea. `gpg --export --armor key-id > channel/name.key` is what I was looking for which is not that difficult to come up with but I wasn't sure if `.key` was a special format that gpg needed another flag to make <PotentialUser-5>I am getting this error: guix system: error: service 'console-font-tty2' requires 'term-tty2', which is not provided by any service <civodul>mitchell: it accepts both ASCII-armored and binary <civodul>mitchell: and yes, it's definitely useful in other contexts! <mitchell>civodul: I do not appreciate the difference <nckx>mitchell: It means that ‘--armor’ is optional. <mitchell>what is the benefit of one over the other? <apoorv569[m]>What is the best way to find which variable is in which module? I am trying to create my own module for some package and some variable is unbound. <nckx>mitchell: cattability, being ASCII-safe. For the core use case, there is no difference. It's like base64-encoding your binaries. <mitchell>"securing the software supply chain" was a great read <nckx>civodul: My pleasure. Should have checked IRC first, but glad it was OK. <nckx>mitchell: Specifically, GPG is commonly (primarily?) used for mail, so it's nice to have an inline-safe representation that won't immediately get destroyed in transit. For things like Guix, binary is arguably better, since it's the same data more efficiently/naturally encoded. <nckx>Now you know more than you wished to know. My pleasure. <mitchell>What about when other architectures try to read these keys? Is there any danger of the binary representation being subjected to endianess problems? <unmatched-paren>nckx: oh, that reminds me: is there any news on my commit access application? :) <ellysone[m]>* idea why, anything that jumps at you by lookings at this snippet ? <mirai>ellysone[m]: see gnu/tests/audio.scm mympd test <mirai>it should serve as a fairly simple example for http testing <mirai>lechner: btw, your bot should be using HEAD requests if it isn't already <mirai>to help sift out non-html responses <mirai>ellysone[m]: what do you see ? <nckx>mitchell: Only in the sense that BE platforms are often neglected and buggy code assumes LE. This happens for all file formats: someone running Guix on POWER in BE mode reported wrongly-coloured images because the software assumed LE RGB. But the bug is just that, a bug, in the implementation, that can be fixed. The spec isn't vague. <nckx>s/vague/ambiguous on that point anyway/ :) <unmatched-paren>it's a bot that posts the titles of links and issues, like this: #60000 <ellysone[m]>can't I just keep the test vm so I can shh into it to see what's going on? <nckx>unmatched-paren: I… I like it :3 <unmatched-paren>nckx: Well, it sounds a bit derisive, but it's not that terrible, I suppose :) <mirai>ellysone[m]: I don't know how, I'd love to know if you find a way <nckx>unmatched-paren: It conjured an image of a bus full of school children carted off to PasteLand® council-funded educational pastezone to learn about the exciting world of glue-making. So, it was vivid, at least. <mirai>are you sure you're waiting for the right ports <mirai>shouldn't it be (wait-for-tcp-port 11334 marionette) <mirai>you're waiting for a port within marionette? <mirai>you then perform a http request on the forwarded port from the host <mirai>you're waiting for the forwarded port inside vm <mirai>and maybe try to get it running on a plain vm first <mirai>make a dummy config.scm for it and step it through <mirai>what's the equivalent for define-deprecated but with NO replacement? <mirai>that is, the variable is redundant and slated to be deleted <antipode>civodul, attila_lendvai: You can add 'this-package' to native-inputs and copy the man page from the natively compiled package to the cross-compiled package. <antipode>(Sometimes the man page includes store file names, so some care may be needed) <antipode>lechner,apteryx:,bjc: I think what's happening, is that when you type (string-length "👆"), it is encoded as UTF-8 by your terminal and send to Guile, and Guile reads the bytes, then decodes them as UTF-8 or wrongly decodes them as some other coding. <unmatched-paren>ACTION thinks we should remove USE-SERVICE-MODULES and USE-PACKAGE-MODULES <unmatched-paren>first we should remove it from the installer-generated template and the manual <mirai>I'd like to sort out how the services are documented in the manual first <mirai>otherwise it's going to be a git-merge nightmare <mirai>< is clearing the old-style service definition augean stables <PotentialUser-5>so I should remove the use-service-modules and use-package modules and put everything in modules? <mirai>it is more uniform that way yes <mirai>unmatched-paren: what I'm somewhat concerned with nuking use-service-modules is how our services are organized <mirai>does the 'service module' desktop actually pull (gnu services desktop) or does it also rope in (gnu services sddm/lightdm/dbus/...) <mirai>it could be that service-modules makes sense to think of as a "category" of modules <mirai>but given how the manual is laid out it's not unreasonable to think so <mirai>and our service module files at some point may become huge enough that it makes sense to split them <mirai>instead of a monolithic desktop.scm, we could have xfce.scm, kde.scm, ... <mirai>or reorder them into directories <gnucode>unmatched-paren: I'm coming into the conversation late. Why do we want to remove (use-service-modules ? and (use-package modules ? <mirai>whilst keeping a (use-service-modules desktop) as a neat "organizer" <unmatched-paren>mirai: you could just have a (gnu services desktop) module that #:RE-EXPORTs the relevant stuff <unmatched-paren>gnucode: it's confusing; it makes it look like service and package modules are something distinct and special (imo) <mirai>we don't necessarily need to do it that way though <mirai>a repurposed (gnu services desktop) serves just as well <mirai>it just becomes a module that imports other modules <gnucode>hmmmm. I guess I like not having to type out (gnu packages package1) (gnu packgaes package2) ... But if it helps new users get used to the system, i guess that makes sense. <PotentialUser-5>Shouldnt the code for the console-fonts service work because its part of the base services? and that is already imported <attila_lendvai>ACTION is staring at cuirass with ungoogled-chromium written on his iris... <PotentialUser-5>actually what service provides 'term-tty2'? Apparently it is still asking for it. And if I add (gnu services console-fonts) it complains there is no code for module. <attila_lendvai>antipode, are you sure adding this-package to native-inputs works? it seems to put guix build into an endless loop <antipode>(if (%current-target-system) (list this-package) '()) <mirai>PotentialUser-5: that's mingetty but it comes with the system already <nckx>I'm saying you need to add it back *or* provide your own no-op service that ‘provides’ that. <nckx>(I guess for completeness you could also modify/write your own consolefont service.) <nckx>It's an alternative ‘solution’. Either your provide 'term-tty2, or you remove the requirement. <nckx>Examples are just that, examples. <nckx>I don't use greetd so I don't know if it's recommended, but as far as Guix is concerned it's optional. <mitchell>I am trying to make git authenticate work for a channel but I keep getting "Git error: could not find appropriate mechanism for credentials". My public key is in the orphaned keyring branch... <mitchell>I get a pretty ugly backtrace that ends with "In procedure bytevector-u16-ref: Value out of range: 0" <nckx>I've never seen that error before. Is there any more? <nckx>Did you create a .guix-authorizations in the master/primary branch? <nckx>Also, this part is very old, but: git-authenticate *used* to hard-code ‘origin/keyring’, nothing else. I ran into that since I don't use ‘origin’. <nckx>That might have been fixed though, I can't promise that's still needed. <nckx>That bytevector is weird. <nckx>Is this repository public? <nckx>Yeah, I sent that before receiving your message :) <mitchell>i'll tear it all down and start from scratch when i figure this thing out <nckx>PotentialUser-5: Sorry then, I was going off the docs. That should be documented. <nckx>I don't know what that file does or should contain, sorry. <lechner>Thank you all for working so hard on Guix! It is my favorite OS <nckx>mitchell: I think you might be invoking ‘guix git authenticate’ with invalid arguments. When I invoke it with ‘4d144225ce861dbe06e564099bc560a0d9808530 "089F 0E56 0087 9656 C463 691A 3811 C00D C428 5E27"’ (for example: were you using "mitchell"?) it works fine, up to the point that it fails to authenticate my own unauthorised commit 😉 https://paste.debian.net/plainh/c7e5db20 <nckx>But that typo was not the cause of your error (which I never got). <nckx>More documentation improvement ideas! \o/ <mitchell>I get the git credentials error when I run guix pull -C channels.scm with this channel <nckx>ACTION wonders what you were going to say. <nckx>mitchell: I see. If you fix the typo, I'll try that next. <antipode>Nothing. The cursor was about the chat and apparently I accidentally copied some nicks. <nckx>antipode: I see. And hi! <ellysone[m]>it reminds me of the syntax of the old batch files on windows <nckx>While XML was inspired by bash, with the <, > everywhere. <lechner>i think it's convert to from org to texi, if that helps <nckx>mitchell: By the way, unless I'm missing an unsigned commit, you shouldn't have needed to bump the make-channel-introduction commit that often. 4d144225ce861dbe06e564099bc560a0d9808530 should work? <mitchell>nckx: Oh? I thought the parent commit needed to have a valid `.guix-authorizations` <lechner>macaroon just messaged me, and says "Same to you, sir." <nckx>macaroon: botisseriesnack. <mitchell>I would not mind code review on this channel if someone knows anything about it <lechner>macaroon resigned due to profound sadness <nckx>Sadness? After a tasty snack? What a Proustian bot. <nckx>Not now, sorry. I assume (hope?) that this might make its way upstream? <mitchell>nckx: That would be ideal! I wasn't sure how much of this was worth integrating into guix proper <mitchell>Seems like you have too many bootloaders <mitchell>I think one of those `bootloader`s should have a (target "/path") <wdkrnls>Dear guix, how do you go about testing package builds with patches? <wdkrnls>e.g. how do you get them in the store or some place the builder can see? <wdkrnls>In my case I have a directory of patches I want to apply. <wdkrnls>I hoped maybe I could check with find-files pointing at my home directory, but I think that is not available inside of the builder. <mitchell>you can either define a new package with source which references that patch (either in the channel root or the gnu/packages/patch directory if you are building from the guix sources. Or you can do `cp -r $(guix build my-package --source) .`, apply the patch manually and use `guix build my-package --with-source=my-package=.` <mitchell>or that much better suggestion from unmatched-paren <wdkrnls>Thanks, I had been wondering about the uses of the -L argument. <unmatched-paren>wdkrnls: it's also useful for installing packages from non-channel modules <mitchell>In guix patches are usually applied when the source is built so `guix build --source` returns patched sources <wdkrnls>I'm not quite sure how to call this yet. <mitchell>you might add it as a native input and add a phase which applies it at build time but you would not them with --source that way <wdkrnls>can't find file to patch at input line 7 <wdkrnls>I think the problem is that passing -L adds the patches in a way I'm not sure how to references them from my build script. <wdkrnls>that scares me a bit since guix already has patches with that name. <wdkrnls>I guess it's a good idea to rename :) <wdkrnls>I tried (map search-patches (list "python-3.6-deterministic-build-info.patch" "python-3.6-fix-tests.patch" "python-3.6-search-paths.patch" "python-fix-tests-3.6.patch")) <wdkrnls>But it failed: guix build: error: search-patches: source expression failed to match any pattern <nckx>(search-patches "a" "b" …) <nckx>mitchell: ‘Obscure’ but useful build systems are welcome. Guix has Minetest, Dub, … build systems. <mitchell>I have a theoretical question. Is it possible for guix git-fetch to successfully checkout/verify a hash one day but successfully checkout that same commit but the hash is no longer the same? <mitchell>It has happened to me twice now and I am extremely suspicious <mitchell>It is my understanding that guix deletes the .git folder after checking out a commit therefore the hash should never change for that commit <wdkrnls>nckx: That didn't work either. Well, atleast substituting apply for map didn't work. <nckx>You are over-thinking :) <wdkrnls>guix build: error: search-patches: source expression failed to match any pattern <nckx>mitchell: That's the idea. Is there any chance you have the ‘old’ source around to compare? Probably not or you wouldn't have asked, but very hard to debug otherwise. <nckx>wdkrnls: Can you share the code in context? <mitchell>It is a package whos source is simply copied <nckx>search-patches is a ‘syntax rule’, not a procedure, so you can't apply or map it, but you should never need to — the whole point is to be a varargs helper that just does what you mean. <nckx>And is the ‘guix hash -rx .’ of both directories is truly different? <nckx>mitchell: If I saw this I'd diff -Naur the two to see what exactly changed, with the assumption that it will be ‘obvious’ what caused it when you see it. <mitchell>I have recovered the sources and the original hash <wdkrnls>nckx: I'm not sure how to share the patches, but they are the four patches listed for python-3.6 in th guix git repository for d66146073d. <wdkrnls>But I slighly renamed them to avoid collisions. <nckx>wdkrnls: Your code works fine here… <wdkrnls>Of course, that might not be necessary. <nckx>(‘Fine’ being starts building, applies some patches, then fails because one fails to apply. No mysterious syntax errors though.) <nckx>I also renamed the packages in your code back to …-3-… and ran with ‘-L .’ in upstream's gnu/packages/patches for speed. <nckx>But that should not explain it. <wdkrnls>I think I should have stuck with python 3.6.5 <cla13>herd: exception caught while executing 'start' on service 'iptables': <cla13>Throw to key `%exception' with args `("#<&invoke-error program: \"/gnu/store/xz1arf5cd7ssck431wmfz5y1kgr5vptables.rules\") exit-status: 2 term-signal: #f stop-signal: #f>")'. <nckx>wdkrnls: No, the ‘guix build: error: search-patches: source expression failed to match any pattern’ you reported would have nothing to do with things like Python version… <nckx>Are you sure the code you pasted is the code that produces this error? <nckx>I've happily debugged things only to notice I was editing the wrong file minutes later… <gnucode>nckx: I do intend to try to get your smtpd.conf working with my service definition. I will find time eventually... <nckx>No presh. In fact I greatly appreciate the fact you bother at all. <wdkrnls>I thought so... I entered `guix build -L python-3.6-patches/ -K -f python-3.6.8.scm` <nckx>And what's the full backtrace, just in case I'm missing something? <ellysone[m]>nckx: pssst I'm rebuilding my infra and that includes a mail server, care to share your smtpd.conf? <nckx>gnucode: Could you share the ‘sanitised’ version? ellysone[m]: It's nothing particularly special or enlightened, it just happened to challenge some record-based assumptions. <mitchell>Ok I have confirmed they are in fact different! It doesn't look malicious but it's fucked up for that to happen right? <nckx>wdkrnls: Uhm, the last error you reported was that syntax one, and it's the one I was hunting all this time. <nckx>mitchell: Too many unknowns. IME, ‘omg I have found a bug in the universe itself’ always turns out to be ‘oh right my fallible fleshbrain forgot it did something silly 10 minutes ago’, like not committing something or forgetting to update a hash. Although I can't say either way. <nckx>I meant, even (or especially) then. <nckx>Is it shareable in a useful way? <nckx>mitchell: A commit hash describing the same contents can trivially change, for example by changing the date. I thought you were describing the opposite (content hash changing for same commit hash). <wdkrnls>nckx: I'm confused. I definitely removed the apply call. <mitchell>yea in that channel i shared you can try to build hal-cmsis and it will fail with a hash mismatch. I have this project on another machine and have delivered software using these commits/hashes so I know it was definitely correct at one point <mitchell>The output paths are the same in both cases but the sources are different <nckx>wdkrnls: Which is why you're no longer getting any syntax errors. That bug is fixed, you just didn't mention it. No? What you pasted last is ‘just’ a patch failing to apply—I agree that's not great, but it's not a mystery, and indeed you need to update your patch or downgrade your Python to match each other. <mitchell>nckx: That is exactly what im' describing. The content hash for a commit changed <nckx>mitchell: I'll check it out. <gnucode>nckx: if you are asking me the latest code for a proper s-exp based opensmtpd-service is, my blog post has all the details: <mitchell>which means the contents of the commit changed, and I verified they did indeed <nckx>mitchell: Then I mis(well :)interpreted your phrase ‘git commit hash’. <mitchell>the package built one day, and breaks the next day because of source hash mismatches <cla13>I can't start the iptables service. Copy-pasted the example with rules, but herd give me an exception: herd: exception caught while executing 'start' on service 'iptables': <cla13>Throw to key `%exception' with args `("#<&invoke-error program: \"/gnu/store/xz1arf5cd7ssck431wmfz5y1kgr5vptables.rules\") exit-status: 2 term-signal: #f stop-signal: #f>")'. <nckx>mitchell: You've delivered Guix packages using the old hash to third parties who never received substitutes from you, only the channel/package Scheme source, and they independently checked out the git repository on their machine, and it matched the old hash? Are you *sure*? I'm not asking because I doubt your honesty or competence, but almost everyone has been tricked by Guix's content-addressed nature, especially with git-fetch, and especially if the file-name <nckx>field does not encode (part of) the commit. <nckx>mitchell: It is quite easy to get into the situation you describe by misremembering some detail. <nckx>Still, I'll (groan) check it out… <lechner>this is such a helpful channel. let's keep up the good work! <lechner>i also sell these on posters, by the way <nckx>inspirational-quote-bot.scm <gnucode>lechner: I second that. We have a lot of great leadership that is quick to point out inappropriate language and ban rude users! <gnucode>also, I installed guix on my pinephone the other day. I figured guix would crawl, but actually it is running seemingly smoothly on postmarketOS. I haven't played with it much yet. <gnucode>guix would crawl --> guix would be too resource hungry and slow down the pinephone <lechner>gnucode / you ever started using Dovecot with your OpenSMTPd? I can't wait to do the same <rdrg109_>[Q] Hello everyone! Newbie user here. I've installed ibus-rime with => $ guix install ibus-rime <=. I can see the ibus-setup binary in my filesystem which was installed by that package (see http://0x0.st/HstT.org ). However, when I try to execute => $ ibus-setup <= in bash, I get "bash: ibus-setup: command not found" <= Again, I'm new to Guix so I could have omitted something obvious. <gnucode>lechner: Actually yes. When I put up my blog post about opensmtpd, I had a full email server working. :) Then I accidentally deleted the dkim signing key... <cla13>anonymous@guix ~$ cat config.scm <cla13>;; Indicate which modules to import to access the variables <cla13>;; used in this configuration. <cla13>(use-service-modules cups desktop networking ssh xorg) <lechner>rdrg109_ / did you load the new profile? <wdkrnls>gnucode: very excited by that! I hope that by the time I actually understand Guix I will be able to do the same. <cla13> "81efaef5-e3ed-43b2-863b-0fe463b9a175" <cla13> (type "ext4")) %base-file-systems))) <lechner>wdkrnls / the blog post is all you need <rdrg109_>lechner: No, could you mention the command that I should run so that I can read more on t hat? <lechner>did the suggestion not appear after you installed? <gnucode>wdkrnls: take a look at the blog post above in the chat history. gnucode.me I explain in propably too much detail about how I set up my email server. Also do a internet search for opensmtpd server on openBSD. There's a really great blog post that holds your hand through setting the whole thing up. <nckx>cla13: Not everything you pasted arrived in the channel, there's (very primitive) flood protection. <rdrg109_>lechner: I think it appeared the first time I installed it, but not in the following ones, because I uninstalled the package and installed it again, but that message didn't appear again, so I didn't consider it relevant for solving this issue. <mitchell>nckx: These are libraries for embedded systems which are statically linked. I am using guix to build them and have built/tested/delivered the firmware i've built using these recipies. I have the old source around because luckly it is a source based package so I copied the old sources from the store and reran guix hash and got the original hash from the recipie. Suddenly today as I'm writting the blog post about how this build system <mitchell>works the hash is wrong. This is a fresh machine which has never built these recipies before so it went and fetched the repo, checkout the commit, and failed the hash check. <mitchell>This is the second time this has happened to me when dealing with the zephyr project and this time I actually have the original sources to prove it <nckx>What you describe sounds exactly like you were never using the commit you thought you were using. <nckx>Building it on a new machine exposed this. <nckx>What's the /gnu/store name of the source checkout? <lechner>rdrg109_ / in guix, all executables are stored in separate, dedicated paths under /gnu/store. the profile adjusts your paths so that the programs you need can also be located (sometimes, by each other), but the system not perfect and we sometimes find bugs. that being said, all of us here believe that the benefits of that setup outweigh the inconvenience <rdrg109_>lechner: I installed another package "transmission" (I haven't installed it before in this system), and I didn't get a suggestion, but the binaries "transmission-daemon" and "transmission-remote" were visible for bash. <nckx>ACTION wonders why GPG takes several seconds to check each commit by mitchell, making ‘git log’ borderline unusable. Rabbit holes everywhere. <mirai>it's part of the transmission package <lechner>rdrg109_ / yeah, it tried to understand the fine points of that algorithm but switched to Guix Home before i found out. Guix Home obviates the reload. i hope that's a word <rdrg109_>Understood! How could I instruct guix to adjust the paths so that ibus-setup is visible to my shell? <mitchell>the original store path from the old derivations is /gnu/store/1shr04g00xbr5mrivs61ix7q5m61hnww-hal-cmsis-5.8.0-checkout which is the same as it is now <mitchell>the old machine has not built these recently so it only has the old working derivations <rdrg109_>mirai: Read my message sent in 02/23 21:03:44 above <nckx>mitchell: Since ‘guix pull’ is taking ages on this overloaded machine, could you share the ‘old’ (expected) and ‘new’ (actual) hashes? <mitchell> expected hash: 0f7cipnwllna7iknsnz273jkvrly16yr6wm4y2018i6njpqh67wi <mitchell> actual hash: 0354fz5lb2vg3zj0ciwjmz4slh3s5rnvkmixikn36m51wk8vcq1j <lechner>rdrg109_ / unfortunately, i am a little bit pressed for time right now, but many folks here can help you. basically, there is a question whether your software was not patched to refer to the absolute path instead of the command alone (many other operating systems rely exclusively on the PATH environment variable) or what else the reason is for the error. fixes are usually easy <mitchell>The last time this happened it was with their compiler. GCC patches that applied one day were suddenly breaking the next <rdrg109_>lechner: No problem! Thanks for the help <nckx>mitchell: Right, so that /gnu/store/1shr04g00xbr5mrivs61ix7q5m61hnww-hal-cmsis-5.8.0-checkout does *not* encode the commit. Meaning, you probably changed the commit field from commit C to commit D, without updating the hash field from hash H (the hash matching commit C). Since sources are content-addressed, that's a no-op. Guix will continue to use the source described by the *hash*, H, which it already downloaded earlier. It will not try to download it again. <nckx>Only on a new machine that never downloaded C, will Guix try do download D, and it will not match H. <apteryx>antipode: hi! thanks for the pointer regarding string-length and unicode discrepancy <lechner>rdrg109_ / actually, looking at the error above i think bash can simply not find the program. you can probably just log out and then log in again to fix it <apteryx>civodul: hi! did you see my report about non-ascii characters and (guix cpio) doing something odd? I thought you may have a clue about what's going on. <nckx>The ‘expected’ hash matches commit 5f86244bad4ad5a590e084f0e72ba7a1416c2edf, the commit preceding the commit matching the ‘actual’ hash that is currently specified in the hal-cmsis package. <nckx>Since the history wasn't preserved in this channel (and you might not even have committed the 5f86244bad4ad5a590e084f0e72ba7a1416c2edf → 093de61c2a7d12dc9253daf8692f61f793a9254a change at all), I can't say more, but this is my diagnosis :) <nckx>mitchell: Now for the constructive part! Using (file-name (git-file-name name version)) as you did was a good move. But if you're packaging an ‘arbitrary’ commit like this, it's better to add (part of) the commit to the version & hence store file name: (version (git-version "5.8.0" revision commit)). <mitchell>I found the history and i bumped the commit but didn't get the hash <lechner>i also like that better then version alone. versions are for dinos <nckx>Then, when you change the commit and ‘forget’ to update the hash (or negate its first digit to force an error 😉), Guix will still check out the source to a new /gnu/store directory, and you'll get an error. <lechner>mitchell / i meant to support your packaging of arbitrary commits <nckx>Like url-fetch URLs, git-reference URLs + commits are *hints* to where Guix can find source H. But H is the only identifier here: if Guix already has H, it will not look at your hint. It already ‘has’ H after all. <mitchell>lechner: It is not arbitrary but it is what was specified by the upstream project <mitchell>The versioned base has arbitrary commits as its dependencies which is annoying but what can you do <lechner>well, i like arbitrary more than begging for a release <nckx>Ah, I only checked for a tag (there was none), hence my use of ‘arbitrary commit’. <nckx>I didn't mean that you were being arbitrary. <mitchell>One day i will write a zephyr importer which can read the west.yml's and come up with appropriate packages <rdrg109_>I found the root cause of my problem. The binary ibus-setup is not found because the directory that contains the generation for the package I installed (i.e. ibus-rime) doesn't have a bin directory. When I installed the mpv and transmission packages, a bin directory was created in their generation directory. This was not the case for the package ibus-rime (therefore ibus-rime is not found by my <rdrg109_>The question is: What should I do now? I'm now that experienced to edit a package definition so that it creates the "bin" directory properly. <apteryx>what's up with ungoogled-chromium substitutes? <lechner>rdrg109_ / the ibus-setup binary ships in the 'ibus' package. that's what you need. you can check for yourself by entering '%/ibus-setup' here on juix.org <gnucode>apteryx: I keep trying to try alternative browsers...like netsurf....and failing miserably. I feel your pain. <apteryx>icecat works fine for me, but some things still work better in ungoogled-chromium (jitsi audio) <nckx>ACTION opens up berlin… finds a tiny icecat sneakily booping the chromium builds out the back… <rdrg109_>gnucode: I solved the problem! I installed the package "ibus" and "ibus-setup" is not found. I had previously just installed "ibus-rime" without having installed "ibus". Perhaps that was the real root cause of the problem. <lechner>ACTION wishes more folks would share their store contents <gnucode>rdrg109_: I am not remembering...what was the problem? <rdrg109_>gnucode: The problem is that I've installed the ibus-rime package. That package contains the ibus-setup binary. However, after installing the package, the binary "ibus-setup" is not found by any shell. <rdrg109_>The "ibus-setup" which I mentioned that was executed was actually from the "ibus" package, not the "ibus-rime" package, so it is not the solution to my problem. I want my shell to find the "ibus-setup" binary from the "ibus-rime" package, not the "ibus" package (which I already uninstalled because I noticed that the one I need is from the "ibus-rime" package). <lechner>rdrg109_ / you can use the absolute path into the store <wdkrnls>I feel like Sisyphus trying to use any other python but the latest one. <rdrg109_>lechner: I tried that, the problem is that it doesn't use the libraries that I should use since it seems it doesn't locate them, so using the absolute doesn't help that much. Ideally, the executable should be visible under PATH. <rdrg109_>I think the problem has to do with the package, because it is the only package that doesn't create a "bin" directory. The packages "mpv" "transmission" "gedit" did create a "bin" directory, "ibus-rime" didn't. <lechner>rdrg109_ / Where do you see the ibus-setup executable that's shipped in the ibus-rime package, please? <nckx>(There is none, I'd just checked.) <lechner>i was just going to write that the absolute path would be fine <nckx>I would have beaten you, too, if I could afford a better CPU! ✊ <lechner>actually, you just need a login to my Postgres database <nckx>rdrg109_: None of those are from ibus-rime. <nckx>I would also not expect ibus-rime to provide that binary, that's not its job. <rdrg109_>Oh, sorry, so all this fuss was because my misunderstanding. Is there any way I can list all the files owned by a package? <rdrg109_>Answering that question would have helped me realized that I was wrong. <nckx>I used ‘find $(guix build ibus-rime)’. lechner used juix.org, but the problem is it can't distinguish ‘I found it in package A & B’ from ‘it doesn't exist in package C’ if it doesn't yet know about C. <nckx>AIUI that is, but it seems both the case and logical. <lechner>nckx must have checked for something from ibus-rime <nckx>No, I checked for xhost the other day, as a test. <lechner>just send me your store map already! <nckx>I'd need to audit yer codez. <nckx>It might infect my box with old-testament themed malware. <nckx>That is… not as reassuring as it was supposed to sound? <lechner>also, i have all your bitcoin already <nckx>‘I haven't implemented the kernel module yet, it's still slow.’ <lechner>i have one coming up, but it's a surprise <lechner>I'd like to, but right now i can't even find init.h in C <lechner>i am not sure Rust can do it yet, by the way. I initially wrote my PAM trick in Rust, but it was 2 megs due to the Rust profiler. <nckx>I don't think you ever shared your use case for that. My answer then was that it's not exposed as a package [except (package-source linux-libre)] but the l-m-b-s should make it available, and anything needing init.h should be using the l-m-b-s in Guix. <lechner>so many layers, though. even the kernel folks now say "use kbuild". no more gcc <nckx>I might begrudgingly try my hand at adding Rust ’support’ (should be easy, right?) to linux{-libre,}, since bcachefs upstream is pretty wild about it. <civodul>apteryx: hey! just noticed that "guix install icecat-l10n:fr" would download all the locales due to grafting shenanigans; did you consider making them separate packages instead? <nckx>lechner: Hmm, not quite sure what you mean, but using Linux's standard build system has always been the right way, and it's why building random Linux modules from a forgotten Git repo is often so damn *pleasant*. The ones that NIH their Makefiles are rare but always completely broken. <lechner>the kernel module will shadow the exec() family of syscalls and set the environment just right. no more explicit wrapping <apteryx>civodul: I didn't! I almost made these hidden, as 'icecat' bundles them anyway <apteryx>icecat-minimal comes without any locale data <mirai>civodul: is there a define-deprecated for variables/procedures that have no replacement? (i.e. slated for removal) <mirai>**something similar to define-deprecated <mirai>since that one insists on replacements <civodul>well, actually you can set #f as the replacement <civodul>and it'll just say that it's deprecated <mirai>but the variable in question is %nscd-default-configuration <mirai>(define %nscd-default-configuration ; deprecated <mirai> ;; Default nscd configuration. <mirai>oh neat, didn't notice that #f works as well <civodul>so: (define-deprecated %nscd-default-configuration #f (nscd-configuration)) <wdkrnls>How did python ever get packaged in the first place? <wdkrnls>Was it just a labor of love over countless months? <wdkrnls>I want to know what the mental and software toolset should be to allow a mere mortal to port their workflow to Guix. <wdkrnls>The trouble with emacs is that it's not reproducible either :p <wdkrnls>It depends on the person using emacs. <wdkrnls>And what they know and who their friends are. <wdkrnls>Unless you can send a nice manifest for a guix container which takes arbitrary python 3.x sources and constructs a working package? <wdkrnls>that makes sense. I did a similar thing for R before the Guix team made a better one. <mitchell>I don't use it personally because it makes the emacs start up really slow but someone on the mailing list was looking for a use-package importer in guix and I thought it made more sense to implement it this way <wdkrnls>Does guile have an interactive prompt for selecting from choices? <wdkrnls>I suppose it should atleast be possible to call a shell interface library packaged in guix. <wdkrnls>And maybe there is a way to use Emacs for that feature. <mirai>civodul: how does pam-limits-service work? Is the argument only used by security-limits within pam-limits-service-type ? <mirai>that service compared to the rest is... strange <mirai>and the terminology pam-service pam-extension isn't helping much since they seem to be records? (gnu/system/pam.scm) <mirai>it looks to me that the plain-file .... snippet can be moved into where ,limits-file is?