<rekado>sss2: are you sure you want to build all the rusts from source? <zimoun>civodul: why command-name in <command> is list and not simply a string? <sss2>rekado, no, i just done "guix pull ; guix package -u" <Sharlatan>sss2: did you have Rust installed, and which version? <sss2>guix package -l |grep rust <sss2> rust 1.49.0 out /gnu/store/9d2zx966lzd3dkyac35n2hffnp9j7mx4-rust-1.49.0 <sss2> rust-cbindgen 0.16.0 out /gnu/store/yhapdvz47cn6ajga3y79rgllgj21bp7k-rust-cbindgen-0.16.0 <Sharlatan>sss2: but in your example you are building version 1.47 right? <sss2>this is dep of some other package <sss2>command above show nothing <Sharlatan>could help as well `guix gc --list-failures` <sss2>Sharlatan, it's possible what problem caused by some unofficial channel ...., but i guess what rust is from main guix channel ? <Sharlatan>sss2: I see a lot of old version rust in your profile, it could cause a conflict I guess <cbaines_>sss2, what problem are you actually having? <cbaines_>(my connection broke, so I may have missed your message) <sss2>cbaines_, guix package -u failing to build rust <cbaines_>I don't recognise /gnu/store/rqff4k69sflslvwjzfvwv4i9qnzxnlhh-rust-1.47.0.drv <Sharlatan>chaines_: could have a look on my build please? <cbaines_>I've done guix pull and I see the same derivation locally, which is a start <cbaines_>data.guix.gnu.org doesn't have it for some reason though ***cbaines_ is now known as cbaines
<cbaines>I don't get the derivation if I disable grafts, which I don't quite understand <cbaines>sss2, sorry, I think this just means rust (at least rust@1.47.0 and later) is just broken at the moment <cbaines>Sharlatan, assuming your build is the buildapp package, why are you patching the Makefile? <justinmoon>Is there any simple explanation of all the steps to (eventually being able to) build guix from hex0? <lfam>justinmoon: Not sure, but if you don't get a good answer here, you could also try in the #bootstrappable channel <lfam>I wonder if there is anything I can do tonight to help with the staging branch. The only significant blocker I can see is the mesa build failure on i686-linux, which has been reported upstream, and I don't have any ideas about what's wrong: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091 <lfam>The rust failure is surprising to me, cbaines. Is that on x86_64? <lfam>Wouldn't we have noticed the failure of all packages depending on rust? <lfam>Oh, I see that the canonical rust is rust-1.45 <jgart[m]>Hi guix! `local-file` is a record that is then shadowed by the macro `local-file` (using define-syntax). Is my thinking correct on that? I'm reading the code in gexp.scm <justinmoon>lfam: thanks. i did get some good answers over there! <jgart[m]><jgart[m] "Hi guix! `local-file` is a recor"> to answer my question above and for anyone else that might benefit understanding this: the macro local-file in the gexp module is the public interface for creating <local-file> record objects. Thanks #scheme <nij>Any idea on why guix was chosen to be written in Scheme, not CL? <raghavgururajan>> leoprikler: raghavgururajan: the issue is this->_sprites being empty <raghavgururajan>> nij: Any idea on why guix was chosen to be written in Scheme, not CL? <nij>raghavgururajan: so.. why is the official extension language of the GNU project based on Scheme but not CL? <raghavgururajan>nij: That I don't know. It used to be EmacsLisp, then changed to Guile. <nij>raghavgururajan: sure! <raghavgururajan>nij: I think it could be due to minimalistic and functional nature of scheme. <apteryx>nij: IIRC RMS didn't think CL as elegant, so it must have played a role. <apteryx>Guile was brought to GNU (it already existed before) to compete with TCL (Tool Command Language), which was increasingly popular at the time, used to script and extend software (it's still common with electronic design automation tools bfor example). <mroh>And also it was/is much easier to extend C code/libraries in/with guile than with TCL and RMS really didn't like TCL that much... <apteryx>Also, Tcl was controlled by Sun Microsystems at the time and there were concerns about the license (e.g., it could become proprietary). <liltechdude>Hello! I want to highlight GNU lilypond files, but with install `guix install lilypond` guix does not install according elisp files in `lisp-site` dir (( <tecosaur>FWIW this is in an effort to package dendrite, which has 17 direct dependencies <lfam>tecosaur: Did you mean to send any other messages? <tecosaur>lfam: no. Is there any elaboration that you think could be helpful? <lfam>The only message I saw was "FWIW this is in an effort to package dendrite, which has 17 direct dependencies" but it reads as if it's referring to something else <lfam>Can you re-send them? I don't think they made it <_tecosaur>I'm trying to package a Go src package, but other packages using it still complain that sub-packages are missing. Might there be something obvious I'm missing? <lfam>By "sub-packages", do you mean dependencies of the thing you're packaging? <_tecosaur>take github.com/jcmturner/gokrb5 as an example <_tecosaur>Oh, another thing with another dependency: reset-gzip-timestamps complains "In procedure open-fdes: Permission denied" from reading http://logs.guix.gnu.org/guix/2019-12-19.log it seems the fix is to modify #:phases to change the file perms, with a linked (expired) paste from roptat. I'm not sure how I'd go about this, so if anyone might be able <lfam>Ah, too bad that link expired <lfam>There are examples of what to do in 'gnu/packages/golang.scm', specifically search for "'make-files-writable" <lfam>Regarding the other thing, I'm thinking... <lfam>I feel like it should work with the right #:import-path (and maybe #:unpack-path) <_tecosaur>Well, I was doing each 'sub-package' one by one <_tecosaur>but this is for a 2nd level dependency, and it's quite tedious <_tecosaur>I'll grab what I've got and put it on ix.io :) <lfam>I might not be able to reply tonight. If you don't get an answer, I recommend sending your query to <help-guix@gnu.org> and we will get around to it <_tecosaur>The last message I send to help-guix got 0 replies 😅 so I've kind of been put off it <_tecosaur>The top n-1 are all me manually doing the sub-packages and gradually getting fed up <_tecosaur>the last one is me looking at the definition of go-golang-org-x-net and trying to do something similar <lfam>I would try packaging the gokrb5 repo as one package <lfam>Does that last one not work? <lfam>If so, please share the error messages <_tecosaur>Yep, however I now get ....gokrb5/<thing> missing errors when I try to build other packages with go-github-com-jcmturner-gokrb5 as a propagated input <lfam>(The line numbers change over time) <_tecosaur>ice-9/boot-9.scm:1669:16: In procedure raise-exception: <_tecosaur>Invalid keyword: (add-before (quote reset-gzip-timestamps) (quote make-files-writable) (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out"))) (for-each make-file-writable (find-files out "\\.gz$")) #t))) <_tecosaur>I think I've just made a rookie mistake somehow <lfam>The add-before part should be included in modify-phases <lfam>Basically, the shopify code expects to find the gokrb5 code at "gopkg.in/jcmturner/gokrb5.v7", but instead it is coming from that github URL <lfam>In Go, software is named and referenced by the URL it is fetched from <lfam>Not just the .v7, but also the URL gopkg.in <lfam>It's one of the techniques used in Go to invent versioned dependencies <lfam>So, yes, if a website goes down, all the code that used it is borken <_tecosaur>I can't say I'm a fan of how Go seems to do dependencies <lfam>It can be worked around but... yikes <lfam>Yeah, it's really annoying! <lfam>Anyways, is there still a gokrb5.v7 at that URL? <lfam>If so, I would rework the gokrb5 package to use that instead <lfam>Go dependencies actually seem great if you are writing and deploying Go directly, like for a business application. But for distros, it's not ideal <lfam>There are also some deficiencies with Go in Guix at the moment. The system needs to be reworked to adjust to changes in Go <lfam>But it does work, in general <_tecosaur>still getting that error though, have I made another rookie mistake? <lfam>Did you change the hash for the new package? <lfam>If not, Guix won't try fetching the new source code, because it sees that it already has the thing named by that hash <_tecosaur>... also has the "In procedure open-fdes: Permission denied" issue <_tecosaur>Hmmm. Still getting "cannot find package "gopkg.in/jcmturner/gokrb5.v7/..." <lfam>I would build it with --keep-failed, go to the leftover directory of the failed build, and check if the missing thing is there or not in the src/ directory <lfam>All the source code of the dependencies should be there <lfam>Are you sure the package definition of go-github-com-shopify-sarama is not using the github.com variant? <_tecosaur>and I /do/ have gopkg-in-jcmturner-gokrb5-v7 as a propagated-input for go-github-com-shopify-sarama *raghavgururajan makes some gagnam-style moves 🕺 <_tecosaur>raghavgururajan: so guix now runs the nextcloud desktop client? What about the server? <lfam>_tecosaur: The only thing I see that is amiss is that the URL of your new package is still fetching from github. But, I don't believe that should matter, since the #:import-path is what creates that filesystem structure <raghavgururajan>_tecosaur: I don't think server package is available in guix yet. That's on my target list. <_tecosaur>Nice! I want to setup guix as my new personal VM <_tecosaur>For which I want 3 things: Dendrite, Gitea, Nextcloud (server) <_tecosaur>I'm currently struggling with a dependency of the first, so I don't have much hope of getting through them all myself :P <_tecosaur>great to hear this is something you're giving attention! <_tecosaur>I have something better, $10 as much resources as I want hosting :D <raghavgururajan>_tecosaur: For nextcloud-server, defining package is one thing and defining service for it is another thing. <raghavgururajan>_tecosaur: You can still run Gitea, Nextcloud etc., on guix VM (now), via docker-service-type. <_tecosaur>I may be a bit stubborn, and I prefer the sound of packaging <_tecosaur>lfam: so ... email guix-help about the pkg location/url ? <lfam>Send the code you have and the errors <_tecosaur>any preference for inline vs. linked code on the ML? <lfam>No, whatever works for you <Bitt>hello! is it normal for the shell to respond with no such file or directory, when trying to run downloaded executables in guix? for example I downloaded the latest blender build from their website and wanted to run it with ./blender, but then even though it exists, bash said it doesn't <rekado_>Bitt: yes, it’s normal, because those executables refer to a global executable (the loader), which is not available at the expected location. <rekado_>for those cases you can create a link /lib64/ld-linux-x86-64.so.2 to /lib/ld-linux-x86-64.so.2 from the glibc package. <rekado_>some applications may contain a reference to a different loader location, so you’d have to use something other than /lib64/ld-linux-x86-64.so.2 to satisfy theim <rekado_>this is just the first hurdle, though. <Bitt>hmm, I see, do I do that with ln? <Bitt>I was thinking it was maybe something like this but then I figured I would get an error message saying something more along those lines <rekado_>the error is at a lower level. The binary says to use this loader, but the file it mentions doesn’t exist, so the error you get is ‘no such file or directory’. <rekado_>you can use ln or the special file service ***rekado_ is now known as rekado
<Bitt>hm I am new to guix so I am not yet familiar with the special file service <Bitt>it also looks like I have a bunch of glibc packages in the store so I'm not sure how to pick the right one <Bitt>(btw is there a page about this in the manual? I was looking but didn't manage to find anything) <raghavgururajan>leoprikler: By any chance you got an idea for how to go about fixing the telegram issue. I have no clue. <leoprikler>One idea, that would come to mind is somehow disabling Emoji support for now. <leoprikler>Other than that, we would have to investigate why Qt resources don't seem to work at all. <leoprikler>Prior to asking for _sprites, UniversalImages *are* being initalized by loading from :something, which is a Qt resource path. <rekado>_tecosaur: you don’t have network access in the build environment. That’s by design. <_tecosaur>rekado: thanks, I thought it may have been something like that. In that case, do you have any ideas for how I might successfully build gitea? <rekado>you’ll have to add all source code as native inputs. <_tecosaur>I can't say I've done that before - do you know where I could look for an example? <leoprikler>raghavgururajan: Dunno about QtQuick, but yeah, disabling Emojis would require patching them out <Sharlatan>chaines: the build if failing without pathcing the make file contains legacy steps to produce binary out of asdf and sbcl <leoprikler>raghavgururajan: I doubt I'll be able to put in enough effort to demand that amount of credit, but I certainly won't mind aiding you. <cbaines>Sharlatan, that seems to be a different issue though, do you know why it's trying to write to the home directory? <cbaines>perhaps try (setenv "HOME" "/tmp") prior to the build phase to see if that avoids it crashing <nefix>Hello! Is there a way to package Racket packages? Thanks! <cbaines>Do the store tests fail for anyone else? Specifically, I see these two fail: FAIL: tests/store.scm - substitute, corrupt output hash <cbaines>FAIL: tests/store.scm - substitute, corrupt output hash, build trace <cbaines>nefix, probably, but it doesn't look like Guix has any yet <nefix>cbaines: I meant Guix xD. I'll see if it's complicated to create a build system <raghavgururajan>leoprikler: Any thoughts on which file(s) and line(s) to patch? After a while going through files, I started pulling my hair out. xD <leoprikler>raghavgururajan: try changing bool _unsupported = false; to = true in ui/emoji_config.cpp first <leoprikler>also comment out all occurences of generateCache(); (note the semicolon) *raghavgururajan thought he was disconnected as the channel too quiet today <alextee[m]>I'm gonna start a guix packager's guide blog entry to mention all these things <cbaines>alextee[m], you're probably rebuilding the grafting derivation then, try adding --no-grafts <leoprikler>In that case you'll have to garbage-collect the package and then rebuild. <leoprikler>Is that not the same one that gets shared around everywhere? <apteryx>there's another driver for the shell script test files <apteryx>In particular, I'm trying to understand what the --test-name is supposed to be: the file name of the test, or its actual srfi-64 test name? It's seems the former, although I find it confusing. <apteryx>and I can't seem to find the right invocation to call such test driver directly, e.g.: guile -e main -s build-aux/test-driver.scm --test-name=tests/packages.scm --log-file=log --trs-file=trs tests/packages.scm <leoprikler>I've personally always found it easier to `make check TESTS="test selection"`, but I don't know how well that works in Guix <apteryx>that works for 'make check-system'; for 'make check' you have to specify the test file names as in 'make check TESTS=tests/packages.scm' <apteryx>I haven't investigated why the discrepancy yet. <leoprikler>raghavgururajan: don't escape the brackets and semicolon in the substitution <leoprikler>also, does the semicolon even need to be escaped? <leoprikler>you might additionally want to use a more descriptive name, like "disable-emoji-support" <leoprikler>apteryx: that's exactly what a meant with "test selection" however <apteryx>yes, that works. I want to understand how to call directly to the undelying test driver as I'm trying to augment it with a --select and --exclude options that'd allow selecting individual test cases, as running 'make check TESTS=tests/packages.scm' takes too much time when I'm interested in a single test case result. <apteryx>I guess the answer lies in autotools; if I know how it calls any test driver I'll have my answer. <apteryx>the SCM custom test driverseems to be registered with the SCM_LOG_DRIVER variable in Makefile.am; it's nothing special outside of setting the environment with test-env before calling the script. ***venkateshpitta[m is now known as ven[m]
<raghavgururajan>error: no declaration matches ‘void Ui::Emoji::{anonymous}::Instance::checkUniversalImages()’ <alextee[m]>weirdly this picks up the pkgconfig entry if I build the project manually without guix <cbaines>alextee[m], pkg-config silently fails if dependencies of the dependency are missing <leoprikler>raghavgururajan: in that case, you'll have to substitute* more cleverly or patch manually <cbaines>alextee[m], I can see Requires: cairo >= 1.0.0, x11 in the ztoolkit pkg-config file <alextee[m]>cbaines: aren't those pulled in from ztoolkit-rsvg? <alextee[m]>cairo and x11 and librsvg are specified as inputs there <cbaines>they're inputs, but not propagated inputs <alextee[m]>I guess they either need to be propagated-inputs on ztoolkit-rsvg or specify them manually in my new package <cbaines>it's only for propagated inputs that Guix makes them available where you're using/installing the package <cbaines>alextee[m], I think the inputs for ztoolkit could do with being propagated inputs, with the logic that they're pkg-config requirements <cbaines>I haven't looked at ztoolkit-rsvg, but I'd apply the same logic <cbaines>this might not be what's causing your problem, but it is something that can be improved <alextee[m]>is it a general rule of thumb that if a package has pkg-config requirements, then those requirements should be propagated inputs? <cbaines>I think so, propagated inputs are generally something to try and do without, but in the case of libraries with requirements it's a good approach of making other packages available <cbaines>it's good to put a comment in the package definition to make it obvious that that's why particular packages are propagated as well <alextee[m]>ok that makes sense, I guess the way the zlfo package is packaged is wrong too then (it lists ztoolkit-rsvg and librsvg both as inputs) <alextee[m]>this new package I'm making will replace/deprecate zlfo anyway so I'll address these issues in a patch sequence <alextee[m]>ok I see librsvg does this correctly by listing cairo and a few other libs as propagated-inputs <Sharlatan>I've got binary for Buildapp... but it's not in profile after install. https://bpa.st/EC7Q it's an ugly patching from my side could be a reason <leoprikler>raghavgururajan: now for the real test: does it crash if you're trying to send emojis? <apteryx>I think test-runner-gnu in test-driver.scm is called with test-name being the name of the test case; so it's called as many times as there are test cases in one test file. <apteryx>although its docstring says otherwise... <Sharlatan>and my shit holyy for packing buildapp, pgloader is the last one in chain :) <raghavgururajan>leoprikler: Nope, no crash. Btw, can you do the honor of pushing it. :-) I have sent v9 to #45721. <leoprikler>I haven't done a proper review yet, but I'll have a look at it. <mdevos>Is it just my bad Internet connection, or is ci.guix.gnu.org down? ‘ping 141.80.181.40’ (ci.guix.gnu.org) tells ‘100% packet loss’ <leoprikler>Is there a tool to quickly extract all attachments from an mbox? <leoprikler>there are some mirrors, but none of them official <atw>is Savannah unhealthy? <mroh>leoprikler: ripmine maybe. <raghavgururajan>alextee[m]: Cool! It automatically syncs with main repo, every 8hrs. <rekado>ci.guix.gnu.org doesn’t respond to pings. ***roptat_ is now known as roptat
<jeko>I have trouble to properly wire a custom profile with Gnome <jeko>If I activate it from .bashrc, applications are available from command line but not from Gnome menu <jeko>I try to activate it from .profile but it seems to do nothing <_tecosaur>I've just spent several hours packaging Go packages <_tecosaur>Ok, after >60 go packages I'm ready to give up <_tecosaur>Is it possible for me to bake a dockerfile into my config.scm? <civodul>_tecosaur: it's not possible but... you're welcome to contribute what you've already packaged :-) <civodul>that way, the next person will have less work to do <_tecosaur>I'm going to share it on guix-devel (seems like the right place) <_tecosaur>Well, I haven't got any patches, but I'll keep that in mind for the future <_tecosaur>Important question though - is it possible for me to set the docker image to be installed and configured from my config.scm in guix? <civodul>i don't think so but i don't use Docker <apfel>hi, git.savannah.gnu.org seems to be down, is anything know whats going on? i tried to find some status webpage or something which tells me when it will be up again, but i did not find anything. <rndd>hi everyone! is there way to build guix bootable iso in another gnu/linux distro? <alextee[m]>just sent my first patch series using git-send-email! \o/ <cbaines>rndd, yes, guix system disk-image is probably the way to go <alextee[m]>so first I send the cover letter, then wait for the guix tracker email and then send the rest of the patches there right? <rndd>cbaines: you mean, i install guix on, for example ubuntu and then use "guix system disk-image"? <rndd>cbaines: ohhhhhhhh, thank you. that's nice/ <cbaines>alextee[m], yep, that sounds right :) <rndd>i found guix is really awesome distro. and this way of writing apps which are independant is awesome! <cbaines>looks like Savannah might be back :) <bandali>yeah i think we're back for savannah vcs (git, hg, ...). running a few tests <rndd>oh, i can use system definition <cbaines>rndd, I think running that command works for me, I'd maybe check the your guix and the Guix git repository are up to date (or at least from around the similar time) <rndd>cbaines: oh it work after git pull. so i need to have same version of installed guix and guix src? <cbaines>rndd, probably not exactly the same version, but I guess there could be issues if they are far apart *civodul sends patches for "guix package --export-manifest" <apteryx>does 'make recheck' works with our test suite? <apteryx>nevermind, it's just that it reran all the tests <apteryx>I meant, it reran the complete test (file) that failed, while I was hoping it'd rerun only the test cases that failed. ***Kimapr_ is now known as Kimapr
<apteryx>The doc to learn what Automake passes on to the custom test driver (test-driver.scm) is info '(Automake) Command-line arguments for test drivers'; but it's rather spartan. <roptat>I'm having a duplicate group issue with php-fpm <cbaines>something I spotted with that is several of the system tests seem to trip up that code looking for duplicate groups <roptat>I see in php-fpm-accounts that we add two groups: php-fpm and the group defined in configuration, which defaults to php-fpm <cbaines>roptat, I think more recent versions of Guix make it a warning, rather than an error <roptat>it's better if we can fix it I think <roptat>and I don't want to pull, it's an armhf system :/ <roptat>we also have a user, whose name and group are taken from configuration, but which also specified php-fpm as a supplementary group <cbaines>looks like it's always been that way, I'd guess that the user-group hardcoded to be php-fpm can be removed <cbaines>or it should only be included if group != php-fpm <mzbm>hi, does anyone know why i keep getting "file or directory not found" when i try to run java from a openjdk version i've downloaded from the openjdk site? <mzbm>it's totally strange... the java i've installed via guix runs perfectly fine <lfam>It's probably missing the loader (ld-linux.so) <lfam>Binaries compiled for other operating systems won't work on Guix without some finessing <lfam>The "file or directory not found" error message doesn't say which file or directory is not found, but it's usually the loader <mzbm>ok thanks i'm reading it now :) <mzbm>can i find out where it expects the loader? <lfam>I would run the program with `strace -f` <lfam>It's likely at the location mentioned in that earlier discussion, though <lfam>It's a well-known location, which is why binaries can be distributed like that. It can be expected to work on most old-school GNU / Linux systems <mzbm>it says "access("/etc/ld.so.preload", R_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) <mzbm>hmm seems to not find a lot of stuff... ill try the suggestion in the chat log <nij>What's the actual packaging workflow like? I understand how to package =hello= and =suckless-terminal=, by directly editing the scheme file. But I imagine this isn't how people really do it. <nij>In practice, do you first enter a guix environment? And then start editing the scheme file that defines the package? And then you try to build based on that file? What happen if it fails? Do you have to restart a new environment? What happen if it succeeds? Do you have to manually input all the dependencies of the env? Or there's a quick way to dump the information? <cbaines>nij, I normally don't bother with trying to build the software outside of building the package, unless I'm really stuck with trying to get the package to build <nij>What do you mean by "build the software outside of building the package?" <cbaines>nij, I thought that was what you were getting at by using guix envionment <mzbm>and ./bin/java definitely exists... <cbaines>nij, Guix package definitions define the environment within which the package is built, so using guix environment to build software can only make sense if you're building the software without using a package <nij>How does the package definition got written? Do you do it manually? <cbaines>There's a number of ways, you can write one from scratch, you can copy a different package and adapt it, there are also importers to generate package definitions <civodul`>also the link to "guix import" on that page ***civodul` is now known as civoudl
***civoudl is now known as civodul
<nij>civodul: thank you! Yes I did read the manual again and again. <nij>I'm just wondering if we have to type them up, or to use import <nij>thanks for confirming :D <nij>What if the building process fails? <nij>Do I change the file a bit, and try it one more time? <nij>Or do I have to clean up the environment a bit.. <nij>err.. I suppose if I build something wrongly, the directory is somehow polluted? <nij>So I have to go back to a certain time when I haven't run that building command? <cbaines>nij, assuming the guix-daemon is running without --disable-chroot which is the default behaviour, there should be no pollution, everything is automatically cleaned up <cbaines>on Linux at least, the build is done by the guix-daemon, in a temporary and isolated environment, which prevents any state from interfering with other builds <nij>Too great :D that clears up my confusion and concerns <nij>thank you, cbaines ! <cbaines>there's an option --keep-failed when building packages, which leaves behind the directory where the build was taking place <cbaines>that's useful when you're debugging things <nij>So the actual workflow is.. <nij>People start from a template package definition. <nij>Do some manual changes.. and attempt to build. <nij>If fails, try to figure out and change the def manually.. LOOP <nij>If succeeds, finish it and send it to the Guix repo? <cbaines>there's also guix lint, which is good to run before submitting patches <nij>coolio! Hopefully I'll be at that level soon. <pineapples>Hello. When zstd compression will be used by the official substitution server if at all? <lfam>pineapples: The work has already begun <pineapples>Awesome! Any ETA or do we just wait until it's done? <lfam>It's a process of compressing substitutes as they are created, and waiting for old Guix clients that don't support zstd to be upgraded <lfam>The support has been added to `guix publish` and the substituter <civodul>pinoaffe: no ETA for ci.guix.gnu.org providing zstd-compressed substitutes though <civodul>difficulty is that we can't just drop lzip or gzip <pinoaffe>civodul: I think you meant to ping pineapples <pineapples>civodul, lfam: Thanks! I'm unknowledgable as far as compression algorithms and the difficulties of deploying them in production are concerned, but I guess the thread on guix-devel contains all the information I need to know. Now I can only presume the inability to drop lzip or gzip must have something to do with CPU architectures <lfam>It has to do with existing Guix deployments not yet supporting zstd. It's a chicken and egg situation <pineapples>lfam: Ah, I see. civodul's pronounced reply read like there's a far more critical reason due to which the support for them cannot be dropped, although you made it clear it's about not all g <pineapples>I wrongly assumed that every instance of Guix and Guix System must be already running the newest version of guix-daemon if it performs any updates at all, but this is, of course, plain wrong now that I'm thinking about it <n1to>Hi. I recently began using Guix and am now trying myself at packaging. I managed to create a working package definition for 'libnitrokey'. Right now as I am testing it though, it seems that the udev rules, which are provided by the package (in ~/.guix-profile/lib/udev/rules.d), don't take effect. Thus I can't access the device as a normal user. As root it just works fine. Is this just a configuration error on my part or do I need to consider this <n1to>in the package definition? <pinoaffe>n1to: in order to make udev rules take effect, you need to add the corresponding package to your system definition, that might do the trick <n1to>pinoaffe: ah, I see. So guix finds these rules itself just from the package definition? <n1to>as long as I specify it in the udev-service-type, I mean. <pinoaffe>n1to: I don't know for sure, but I think that as long as the package puts the udev rules in the right directory, adding the package in the udev-service-type should ensure that they're added to the system <pinoaffe>if it's putting them in the wrong directory, you might need to modify the package definition a bit <n1to>pinoaffe: ok, thank you!