IRC channel logs


back to list of logs

<lechner>do i need the #f in my serializers, though?
<lechner>up top in the first paste
<lechner>the small custom serializers
<lechner>you were talking about the stuff that was commented out, right?
<mirai>(format #t "~a ~d\n" field-name value))
<mirai>maybe format #f?
<lechner>no idea where that came from
<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
<mirai>I've no idea at this point
<mirai>it looks correct to me
<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>re debugging 'guix pack -f rpm nss-certs'; the result seem to have to do with something in the (guix cpio) produced cpio:
<macaroon>"debian Pastezone"
<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)
<lechner>hi, what does this match-record do, please?
<macaroon>"guix/audio.scm at efa091f9f4e77068353dff24f0ccd2d0613c3f48 · guix-mirror/guix · GitHub"
<haugh>lechner, are you asking about match-record generally or this specific extraction?
<lechner>i have a relatively simple service that does not accept options properly in the system config.
<macaroon>"debian Pastezone"
<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>this helps somewhat, for (guix cpio) and multibyte file names:
<macaroon>"debian Pastezone"
<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>not a C string (byte string)
<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>it definitely can
<macaroon>"debian Pastezone"
<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>bjc: I'm looking
<apteryx>I see.
<apteryx>Perhaps something to do with the way (guix cpio) works then...
<apteryx>here's my reproducer/bug:
<bjc>oh, is it not just shelling out?
<macaroon>"(guix cpio) produces corrupted archives when there are non-ASCII filenames"
<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>(where FILE is the file name)
<lechner>in which software?
<apteryx>there's a Scheme cpio generator at (guix cpio)
<lechner>that's not right, i do not think
<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
<lechner>it's called normalization
<lechner>or lack thereof, that is
<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
<lechner>so it would be put all the way
<apteryx>guile strings are not utf8, they are unicode (code points), IIUC
<bjc>ok, but it's the same problem
<lechner>it's a crucial difference
<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>I'll sleep on it
<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?
<apteryx>in place of _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)
<apteryx>*the number of
<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>no in characters
<apteryx>so perhaps that's the issue, if the logic assumes these are all bytes
<apteryx>seems you're on something
<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>i'm getting 21
<apteryx>what's your locale?
<bjc>LANG == en_US.utf8
<bjc>are you in 8859-1?
<apteryx>me too... hm
<bjc>how are you checking this? through the guix repl?
<apteryx>in Geiser's Guile REPL
<bjc>me too
<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
<apteryx>returns 1 for me
<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
<lechner>for (string-length "👆")
<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
<apteryx>I don't have it
<lechner>for a file?
<bjc>daviid: i will once i dig into it a bit more
<apteryx>the input is a list of file names, provided as strings
<lechner>from where?
<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>yes, you have to encode them.
<lechner>Fedora can do this because they require all filenames to be valid UTF-8 bytecode sequences
<lechner>i guess they should also require that they are normalized UTF-8
<macaroon>"FAQ - Normalization"
<apteryx>bah, didn't change a thing
<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
<apteryx>thanks for the discussions!
<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
<surpador>A bit unrelated, but makes some interesting observations re: encodings and code points vs characters:
<macaroon>"UTF-8 Everywhere"
<the_tubular>Is timing out
<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
<unmatched-paren>hello guix :)
<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.
<civodul>Hello Guix!
<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)?
<gabber>howdy y'all
<AwesomeAdam54321>hello gabber
<opty>gabber: hello, i asked on #gentoo :)
<gabber>opty: did you get help there?
<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
<opty>gabber: not yet
<gabber>ACTION crosses fingers
<AwesomeAdam54321>another one is adding support for substitute distribution via GNUnet
<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 :)
<AwesomeAdam54321>Guix doesn't require copyright assignment to the FSF, but feel free to
<AwesomeAdam54321>*Contributing to Guix
<opty>gabber: thanks but i'm afraid i'll have to ask my vps provider
<pkal>Is the hackage import broken?
<pkal>I was trying to import haskell-language-server, but i get this stack trace:
<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
<civodul>we should fix it
<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>yes actually that sounds reasonable
<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
<attila_lendvai>oh, right!
<civodul>but "native" compilation can go through qemu-binfmt
<attila_lendvai>ACTION retries using --target=aarch64-linux-gnu
<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>graywolf: hmm, interesting idea
<civodul>i guess it could be useful if there's a bunch of machines you'd all like to manage at once
<civodul>it had never occurred to me
<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]>Hey guix!
<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]>> <> Hey guix!
<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]> "> <> 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`
<attila_lendvai>bjc, i have a patch that builds shepherd from git, and with that applied `guix shell -D shepherd` should be enough. it has fewer inputs than your manifest, though.
<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)?
<gnucode>morning guix!
<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
<civodul>not great
<ellysone[m]>> <> 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
<mirai>see gnu/tests/
<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.
<attila_lendvai>ACTION tries to make do without running 32 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).
<civodul>ellysone[m]: BTW, note that to run the system tests you'll need "make check-system TESTS=xyz":
<macaroon>"Running the Test Suite (GNU Guix Reference Manual)"
<ellysone[m]>yeah I was reading that page :)
<civodul>alright :-)
<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
<civodul>ok to remove it?
<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?!
<AwesomeAdam54321>sneek: botsnack
<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 =/
<lechner>Hi, this is an absolutely minimal version of my cachefilesd service, which works except that i can't configure 'cache-directory' from inside the service-stanza in my operating system definition. What is wrong, please? Here is the backtrace
<macaroon>"debian Pastezone"
<macaroon>"debian Pastezone"
<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 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)
<civodul>ngz: i don't have that commit
<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>No, just `su - USER' triggers this warning after I set it up via guix home reconfigure; I'm not at the point trying the remote deploy just yet.
<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?
<civodul>was it already built on qa.guix?
<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.
<civodul>what "this"?
<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
<civodul>not before
<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"
<sneek>Will do.
<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
<macaroon>"[PATCH] services: dbus-service: Deprecate 'dbus-service' procedure."
<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
<civodul>heh, true :-)
<mirai>I assume the rationale in #61693 is acceptable as well as criteria for the "big-sweep"?
<macaroon>"[PATCH] services: Remove etc-service procedure."
<mirai>aka not-documented = remove straight away
<mitchell>thats probably a good policy
<mirai>"if it ain't documented then it don't exist"
<mitchell>undocumented code is worthless code
<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!
<mirai>internally it is
<mirai>its just not on the manual
<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
<mirai>even for etc-service?
<civodul>(there was a time when fewer things were documented)
<mirai>ok, I'll v2 that patch
<unmatched-paren>hello guix :)
<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>Hullo Guix.
<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.
<singpolyma>nckx: nice. That's good to know about thanks
<nckx>lol @ development history:
<macaroon>"Commits · DanielBatteryStapler/Guix2AppImage · GitHub"
<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>is it just --export > name.key ?
<unmatched-paren>mitchell: i think it might be --export --armor KEY-ID > name.key
<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>I mean `guix git-authenticate`
<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>how can I search which system service provides a specific thing?
<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
<PotentialUser-5>on my system config
<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
<mitchell>nckx: I see
<nckx>civodul: My pleasure. Should have checked IRC first, but glad it was OK.
<civodul>glad you liked it :)
<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>You underestimate me
<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]>this test is failing
<ellysone[m]>ACTION sent a code block:
<ellysone[m]>and I have no idea why
<ellysone[m]> * ```... (full message at <>)
<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
<ellysone[m]>well I did
<ellysone[m]>see some examples
<ellysone[m]>i nthe tests directory
<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 ?
<mirai>how does it fail
<ellysone[m]>ACTION sent a code block:
<lechner>mirai / great idea! thanks!
<lechner>it really is our bot, i hope
<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/ :)
<ellysone[m]>mirai: this is what I currently have
<macaroon>"debian Pastezone"
<mitchell>nckx: All good points
<ellysone[m]>macaroon: is there a guix pastezone?
<unmatched-paren>ellysone[m]: macaroon isn't a human :)
<unmatched-paren>it's a bot that posts the titles of links and issues, like this: #60000
<macaroon>"[PATCH] gnu: Add lxappearance-gtk3-wayland"
<unmatched-paren>ellysone[m]: there isn't a guix pasteland, by the way.
<ellysone[m]>good bot
<unmatched-paren>(pasteland? why'd i write "pasteland"!?)
<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)
<ellysone[m]>yeah this is the default config file... (full message at <>)
<ellysone[m]>mirai: shouldn't it be the forwarded port?
<ellysone[m]>I think I tried both anyways
<mirai>you're waiting for a port within marionette?
<mirai>within the vm that is
<ellysone[m]>that rspamd
<ellysone[m]>bins 11334
<mirai>you then perform a http request on the forwarded port from the host
<ellysone[m]>sthat's the idea
<mirai>you're waiting for the forwarded port inside vm
<mirai>and maybe try to get it running on a plain vm first
<ellysone[m]>I'll have to go, I'll answer laeter
<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.
<attila_lendvai>antipode, oh! i'll try that, thanks!
<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.
<lechner>antipode / i believe it!
<PotentialUser-5>is there any examples with greetd and sway system configs? I am trying to set it up but I am stuck with this error:
<macaroon>"debian Pastezone"
<unmatched-paren>PotentialUser-5: there is no (gnu services console-fonts) module
<unmatched-paren>neither is there a (gnu services greetd), in fact
<unmatched-paren>you need to import (gnu services base) instead
<unmatched-paren>ACTION thinks we should remove USE-SERVICE-MODULES and USE-PACKAGE-MODULES
<mirai>I agree
<mirai>though not so soon
<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
<unmatched-paren>and change them to print a deprecation warning
<unmatched-paren>then remove them a few months later
<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?
<unmatched-paren>PotentialUser-5: i think that's the better way, yeah
<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
<unmatched-paren>mirai: how so?
<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
<unmatched-paren>wait, it does???
<mirai>I don't know
<mirai>but given how the manual is laid out it's not unreasonable to think so
<unmatched-paren>it doesn't
<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>I am running into a different error now:
<macaroon>"debian Pastezone"
<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...
<attila_lendvai>seems to be "cancelled":
<macaroon>"Build 460315"
<PotentialUser-5>never mind my mistake
<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>You need to do it conditionally.
<antipode>(if (%current-target-system) (list this-package) '())
<attila_lendvai>ACTION tries
<mirai>PotentialUser-5: that's mingetty but it comes with the system already
<nckx>PotentialUser-5: One of the *getty services (agetty, mingetty). The intention is not to set the font too early <>. Unfortunately, the Shepherd still lacks a ‘start me after foo, but don't require foo’ concept like, e.g., systemd has always had.
<mirai>I think
<macaroon>"base.scm\services\gnu - guix.git - GNU Guix and GNU Guix System"
<nckx>Slow bot!
<nckx>Slow nckx!
<PotentialUser-5>nckx the thing is I have removed mingetty
<macaroon>"debian Pastezone"
<nckx>I know.
<PotentialUser-5>ah. so its generally doesnt get to that point
<PotentialUser-5>so what is the solution?
<nckx>I'm saying you need to add it back *or* provide your own no-op service that ‘provides’ that.
<nckx>Yeah :-/
<PotentialUser-5>side question
<nckx>(I guess for completeness you could also modify/write your own consolefont service.)
<PotentialUser-5>wut. Do I need to?
<nckx>It's an alternative ‘solution’. Either your provide 'term-tty2, or you remove the requirement.
<PotentialUser-5>Also here in the manual it says about a sway-greetd.conf
<PotentialUser-5>is that needed? I have it to false for now
<PotentialUser-5>because there is no file
<macaroon>"GNU Guix Reference Manual"
<nckx>It is not.
<nckx>Examples are just that, examples.
<nckx> (bottom)
<macaroon>"IRC channel logs"
<PotentialUser-5>ah ok thanks as I thought :)
<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.
<PotentialUser-5>yeah it seems I am going into deep waters already :P
<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?
<macaroon>"debian Pastezone"
<mitchell>here is the back trace
<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.
<mitchell> here is the .guix-authorizations in the main branch which I am starting to authenticate from
<macaroon>"debian Pastezone"
<nckx>That bytevector is weird.
<mitchell> here is the repo
<macaroon>"GitHub - paperclip4465/guix-zephyr: ZephyrRtos Guix integration"
<nckx>Is this repository public?
<mitchell>it is for now
<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
<PotentialUser-5>it seems that it requires the config file after all:
<macaroon>"debian Pastezone"
<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.
<PotentialUser-5>no worries. I can send corrections when it is done
<PotentialUser-5>will see just experimenting now :)
<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 😉
<mitchell>I was indeed using "mitchell" XD
<nckx>But that typo was not the cause of your error (which I never got).
<nckx>Ah :)
<nckx>More documentation improvement ideas! \o/
<antipode>nckx: mitchell:
<mitchell>I get the git credentials error when I run guix pull -C channels.scm with this channel
<antipode>(accidentally pressed enter, ignore)
<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.
<antipode>* above
<mitchell>Spelling is an important ability
<nckx>antipode: I see. And hi!
<ellysone[m]>why is texi ugly
<lechner>the input or the output?
<ellysone[m]>it reminds me of the syntax of the old batch files on windows
<ellysone[m]>with the @ everywhere
<mitchell>It's true
<nckx>While XML was inspired by bash, with the <, > everywhere.
<lechner>i think it's convert to from org to texi, if that helps
<ellysone[m]>there is a backend for emacs?
<lechner>pandoc, i think
<lechner>actually, it's in org-mode
<ellysone[m]>i mean exporter
<morganw>The exporter is built-in:
<macaroon>"Texinfo Export (The Org Manual)"
<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?
<nckx>You're such a macaroon.
<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."
<mitchell>The typo did fix my problems
<nckx>macaroon: botisseriesnack.
<nckx>mitchell: Yay!
<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.
<lechner>yeah, he was picky
<nckx>Not now, sorry. I assume (hope?) that this might make its way upstream?
<nckx>mitchell: ☝
<nckx>ACTION away.
<mitchell>nckx: That would be ideal! I wasn't sure how much of this was worth integrating into guix proper
<XADE[m]>Any help will be appreciated
<mitchell>Seems like you have too many bootloaders
<mitchell>I think one of those `bootloader`s should have a (target "/path")
<XADE[m]>Tried, still same
<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.
<unmatched-paren>wdkrnls: -L PATCH-DIRECTORY
<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>I'll let it think for a while.
<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>(e.g. my scheme file)
<unmatched-paren>wdkrnls: just use SEARCH-PATCHES
<unmatched-paren>(search-patches "patch-file.patch")
<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>No apply, no map.
<nckx>You are over-thinking :)
<wdkrnls>guix build: error: search-patches: source expression failed to match any pattern
<mitchell>search patches is a lisp code
<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.
<mitchell>not a cli code
<nckx>wdkrnls: Can you share the code in context?
<mitchell>I do indeed (kind of)
<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?
<tres-leches>"debian Pastezone"
<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
<mitchell>i got them this time those bastards!
<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>It could be the python version.
<wdkrnls>I think I should have stuck with python 3.6.5
<cla13>Hello and sorry for my english! The "iptables-example" on dont work for me.
<tres-leches>"Networking Services (GNU Guix Reference Manual)"
<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?
<nckx>Or is that it?
<ellysone[m]>nckx: pssst I'm rebuilding my infra and that includes a mail server, care to share your smtpd.conf?
<tres-leches>"debian Pastezone"
<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?
<mitchell>beyond suspicious?
<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.
<mitchell>No this is committed and verified work
<nckx>I meant, even (or especially) then.
<mitchell>but how can a git commit hash change?
<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
<wdkrnls>Sorry, was pretty confused.
<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’.
<nckx>wdkrnls: No problem!
<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>")'.
<ellysone[m]>cla13: paste of your entire config?
<ellysone[m]>which revision are you on?
<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.
<ellysone[m]>* you on? guix system describe
<ellysone[m]>I just tried the example and it works for me
<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
<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 ). 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-modules (gnu))
<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>                       (file-system
<cla13>                         (mount-point "/")
<cla13>                         (device (uuid
<cla13>                                  "81efaef5-e3ed-43b2-863b-0fe463b9a175"
<cla13>                                  'ext4))
<cla13>                         (type "ext4")) %base-file-systems)))
<lechner>wdkrnls / the blog post is all you need
<lechner>cla13 / please use a paste service
<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. 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?
<mirai>does it use git submodules
<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.
<mirai>what's the problem ?
<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>on the new machine
<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.
<mitchell>nckx: I think you are correct.
<mitchell>Thank you
<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>tres-leches: Hun.
<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>nckx: That is indeed what happened!
<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
<mitchell>fair enough!
<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
<nckx>mitchell: Sweet.
<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?
<apteryx>it's not been availabl efor days
<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
<gnucode>apteryx: I keep trying to try alternative 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.
<nckx>ACTION …‘good cat.’
<lechner>ACTION wishes more folks would share their store contents
<lechner>maps of store contents
<gnucode>rdrg109_: I am not remembering...what was the problem?
<lechner>they may have meant me
<lechner>off and happy!
<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>always jumping the gun...
<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.
<rdrg109_>In which directory?
<nckx>I used ‘find $(guix build ibus-rime)’. lechner used, 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.
<lechner>it only runs in user space
<nckx>That is… not as reassuring as it was supposed to sound?
<lechner>also, i have all your bitcoin already
<lechner>better than root, ain't it?
<nckx>‘I haven't implemented the kernel module yet, it's still slow.’
<lechner>mine or yours?
<lechner>i have one coming up, but it's a surprise
<nckx>Ideally, no one's.
<nckx>Oh noes.
<lechner>it will rock you
<lechner>it will install Guix on Mars
<nckx>Is it written in Rust?
<lechner>I'd like to, but right now i can't even find init.h in C
<lechner>and the headers are in my database
<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>i know. i am still reading up on it
<nckx>Oh, OK!
<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.
<nckx>Oh, oops:
<nckx>ACTION away o/
<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>*almost considered
<apteryx>s/almost// ... eh
<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>ok, getting 404 on
<mirai>but the variable in question is %nscd-default-configuration
<mirai>(define %nscd-default-configuration ; deprecated
<mirai> ;; Default nscd configuration.
<mirai> (nscd-configuration))
<mirai>oh neat, didn't notice that #f works as well
<civodul>so: (define-deprecated %nscd-default-configuration #f (nscd-configuration))
<civodul>should work?
<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.
<mitchell>wdkrnls: emacs
<lechner>love it!
<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.
<gorgeousbateye>HELLO GUIX
<wdkrnls>Unless you can send a nice manifest for a guix container which takes arbitrary python 3.x sources and constructs a working package?
<mitchell> I wrote a thing that will use guix to ensure use-package definitions
<tres-leches>"GitHub - paperclip4465/use-package-ensure-guix: emacs use-package ensure implementation which uses GNU Guix"
<wdkrnls>Maybe the trick is M-x butterfly :)
<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?