<Bumblehorse>Has anyone got an error like " Use of AM_GNU_GETTEXT without [external] argument is no longer supported." or "warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd" when trying to make a package? If so, how did you fix it? <Bumblehorse>Would I just patch the configure.ac or would I have to mess with autoconf itself or an m4 file? <wleslie>my solution so far has been to try to use the versions of autoconf and aclocal that the project uses to generate configure <wleslie>it seems a lot of that stuff is version sensitive <Bumblehorse>wleslie: Do I need to update my own packages or somehow write the versions within the package definition? <maav>Bumblehorse: hmmm, it shouldn't be so much sensitive... which versions of autoconf, automake and gettext are you using? <Bumblehorse>maav: Well in my profiles I actaully don't have them installed <maav>ohhhh, you mean packaging <maav>hehehe, i should be sleeping... <maav>what package is? to take a look at the configure.ac <Bumblehorse>I noticed it doesn't have the [external] argument, but I'm not sure whether I'm just supposed to patch that in or if I'm doing something else wrong <maav>hmmm, interesting discovery... :) <maav>it's quite old, so... maybe that's the problem <Bumblehorse>maav: Is this maybe something I should give up on? This is my first time trying to package something. <maav>no, no, let me check, they updated it this year, so maybe this is something they didn't noticed, or they used an old gettext version <maav>after looking at it, i think you should patch it for guix <maav>probably it's just matter of adding that [external] parameter, the thing is that they use intl as an internal module <maav>but we should rely on libc's gettext <maav>well, configure.ac and Makefile.am (you should remove intl there) <Bumblehorse>And this is all done from within the package definition? <maav>it could be a phase or you could use an snippet, but you have to ensure that autoreconf (autogen.sh does it) is called <maav>if it's already been called (therefore the error) you shouldn't do anything then <maav>to call autoreconf, i mean <Bumblehorse>It does get called, before I was trying to fix an issue with it not executing and fixed it with adding autoconf to the native-inputs <maav>nonetheless, it isn't an issue not to call autoconf <Bumblehorse>So when you say phase I would have to change the build system (or edit the way it works) correct? <maav>that's one option, yes, but before that, why did you add the autoconf call then? <Bumblehorse>I was getting an error because it didn't have acces to the autoreconf command <Bumblehorse>I didn't add the call, I only added ("autoconf" ,autoconf) to native-inputs <maav>ahh, ok, so it was being called then, i get now the picture <maav>you have to add gettext to the inputs too <maav>and automake too in that case <Bumblehorse>When you say snippet, what kind of snippet could I use? I don't see anything obvious in the package reference. <maav>snippets is a field of the origin, as it modifies the stored code <Bumblehorse>in the origin reference there is an actual snippet part <maav>e.g. if you look into gnu/packages/glib.scm and check the glib package, it has a simple snippet <maav>'(begin (substitute* "tests/spawn-test.c" (("/bin/sh") "sh")) #t) <Bumblehorse>I was reading the packing tutorial blog and thought that the snippet part was a header for the next parts like input, output and buil arguments <maav>there is a manual section explaining the main differences and usage of snippets vs phases <maav>the tldr is: snippets should only modify the code in a non-guix related way, like changing this configure.ac and Makefile.am, which should be also reported to upstream, phases are guix-related and modify things like store paths and so on <maav>i think is in Contributing section <maav>let's hope they apply it for the next version... you could take that patch instead of an snippet, btw <maav>the patch is from today?? did you sent it? ;) <lfam>In general, remember that snippets are applied when "building" the package's source code. That is, they are used to create the result of `guix build --source foo`. So you want to limit their use to things that make sense in that context <Bumblehorse>I've actualled had a pretty lack-luster programming history. <lfam>That is, the thing you get from `guix build --source` should be useful outside of Guix <Bumblehorse>I've made a few simple C programs and have dabbled in Common Lisp <lfam>I agree this is a case where a snippet seems useful <maav>lfam: having already a patch on their mailing list shouldn't we take that instead? patches apply to guix build --source, don't they? <lfam>Yes maav, they do. And yes, we prefer to stick to upstream, which usually means using their patches rather than writing our own, "all else being equal" <maav>lfam: thanks a lot for both clarifications :) <lfam>But sometimes, the otions aren't equal. For example, a patch file might be gigantic, while we could use a brief snippet with (substitute*) to achieve the same effect. Trust your judgement :) <maav> 2 files changed, 3 insertions(+), 4 deletions(-), it's mostly trivial :) <maav>let's drive the robots into an infinite recursion ;) <lfam>Weird that doesn't work, Bumblehorse! <lfam>OriansJ: I think you have to escape the ? or else the shell tries to interpret it <lfam>I usually just quote the URLs in cases like this <OriansJ>lfam: I tried both single quotes, double quotes and prefixing \ <Bumblehorse>Well maav I'm going to reread all this and the related manual pages when I have more time to try and finish this. I'll be sure to give you credit in a comment or something if that's how it's done. <OriansJ>lfam: the wget is not the problem; it is guix download that file <lfam>I'm sorry I didn't read more carefully <OriansJ>as if I change the file name guix refuses to recognize it and tries to download it again <OriansJ>(Trying to do an offline guix install) <lfam>I'm not sure how to proceed :/ Of course it should be made to work <lfam>I wonder if this type of bug has been reported before, OriansJ <OriansJ>also trying to harvest the source files from an existing installation doesn't work as I need to rename them to their original names and then use guix download to import them to be recognized <OriansJ>So just taring up /gnu/store ends up not working either. <maav>Bumblehorse: no need for credit, really, and you're welcome :) <lfam>I don't recall exactly which context this kind of download is performed in — if it's in the context of the daemon, or something else <lfam>I wonder if there is some locale or language related thing that isn't set up correctly there <lfam>I don't really know why a '?' would be considered "special", but... <lfam>Otoh, this could be a bug that's been fixed in my version of Guix, which is only a couple days old <OriansJ>or guix is truncating its name to something I haven't guessed yet and I would just need to match that <lfam>In my store, the file is saved with the '?' character in place <lfam>(Shouldn't these files be named more descriptively???) <maav>lfam: it should be running on the daemon (with-store call) <OriansJ>lfam: close to the bootstrap, no one wants to touch anything <lfam>Yeah, too late to rename them now <maav>early for the next release then :) <lfam>OriansJ: Can you transcribe the error message for us? <OriansJ>guix download: error: bash\?id=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e: failed to parse URI <OriansJ>and guix download: error: lstat: No such file or directory: "/home/oriansj/send/bash" <lfam>And what is the host OS? How do you start the guix-daemon? <OriansJ>I can provide exact system setup steps if you would so desire <lfam>In your guix-daemon.service file, do you have an Environment field that sets GUIX_LOCPATH? <OriansJ>well it is the stock /gnu/store/p7jcjqcaw66g05zjim0famggfwpna8k0-guile3.0-guix-1.1.0/lib/systemd/system/guix-daemon.service <OriansJ>Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 <lfam>What about that lstat error? I don't understand the relevance of that path in your home directory? <OriansJ>lfam: the lstat is when I add extra \ when it is wrapped in '\'' <lfam>I wish it was earlier in the day — I think the people who could get to the bottom of this quickly are done for the night <lfam>Shot in the dark: Remove the "LC_ALL=en_US.utf8" from guix-daemon.service, daemon-reload and restart, then try again <lfam>I always remove that part because it causes trouble on my Debian systems <maav>in debian I'd change it to C.UTF-8, but... could that cause an error in regexps? <maav>that error is raised as string->uri (which uses regexps) doesn't parse correctly the url <maav>all of them seem quite straightforward (for url parsing, i mean) <ryanprior>New emacs-guix-packaging feature: the guix-go-package snippet automatically populates the hash field for you. Packaging go libraries is getting seriously speedy. <ryanprior>In the common case, everything is pre-populated for you except the synopsis, description, and inputs. <lfam>That's really nice ryanprior <ryanprior>Inputs is the next thing I want to tackle by transforming the module definition file into a set of default inputs. <ryanprior>Oh that's awesome, if I were good at writing Guile I would have attempted that months ago. Bless Katherine & hope that gets merged. <lfam>ryanprior: Yeah, it will be awesome. We really need to improve the Go package tooling and build system if we want to continue with Go. I (temporarily?) stopped maintaining the Syncthing package because recent versions aren't compatible with our go-build-system <lfam>The complexity of the Go ecosystem is too great to be handled manually <ryanprior>Yeah I'm hoping I can get a sense by reading the patch of how much the importer actually does <lfam>Our advantage is that we can actually improve our tooling <ryanprior>Because there's lots of weird things you encounter in how go packages get structured <lfam>I don't think Debian will be able to adapt <OriansJ>too few people in Debian care about the builds <OriansJ>users just want a quick apt install foo <ryanprior>I dunno, Debian tooling has improved a lot over the years. I'll read the article though, thanks for sending it. <maav>OriansJ: did you try again to directly call guix download after the locale change? <lfam>Well, that's true, but if they want to package Go software in the form that users prefer it, they will need to increase the number of work hours available, by a lot, and they will need to relax the "stability" promises <ryanprior>OriansJ: that's what users of Guix want too though. Debian is right to prioritize making the experience of binary-package-wanters excellent imo <lfam>I've done Go package their way, and it's not worth doing without a paycheck <maav>OriansJ: it think you mixed up lfam and me <OriansJ>maav: yep; dealing with too many things at once <lfam>The reason I think they won't make those changes is that Debian seems to be a big organization that has grown up along with its tooling. Their organizational structure mirrors the tools they use to build the distro. It's hard to change one without the other, and it's clear that it's not easy to join Debian and start contributing; I assume this means it would be to hard to change the structure <lfam>The stability promises seem directly linked to the inability to rollback in a meaningful way, which is a limitation of the package management tools *and* the package development infrastructure (totally decentralized — you can't do `git revert` on the Debian source code. There isn't even a "Debian source code" to speak of) <maav>OriansJ: np, it's really weird the lstat twice and then the uri error... if you try file://home/oriansj/bash\?id\=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e does it say something different? <lfam>I think there is a really interesting conference keynote to be given on this subject — maybe even a book <lfam>I don't mean to put them down or anything like that. Debian is still my primary OS <OriansJ>lfam: well tooling is a reflection of the organization itself <maav>yup, it seems that canonicalize-path is doing something weird... <OriansJ>fixing people is *HARD* but changing code *EASY* <lfam>It's true, but I think for an organization as old as Debian, which began at the dawn of distros, they have influenced each other <lfam>And reinforced each other <OriansJ>lfam: well those who don't fit the Debian "culture" by default are "pruned" <lfam>I agree that changing people's minds, and the structure of the org, is much harder than changing the code. But changing the code in Guix is already much easier than in Debian. Hopefully this means that fewer people get pruned <OriansJ>as all cultures tend to form self isolating tendencies <lfam>Yes... hopefully it's possible to militate against that tendency <OriansJ>only by actively trying to consider things from a new person's perspective can a culture work against the more common self-isolation paradigm <lfam>Exactly! Deliberately returning and re-inhabiting the beginner's mind <lfam>It's a constant struggle <OriansJ>aka; assume zero knowledge and how far into building guix from source does one get today <OriansJ>last week it was 12% into the readme before *BROKE* <maav>OriansJ: last thing before i give up and go to bed, could you launch a guile session and execute (canonicalize-path "bash?id=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e") <OriansJ>maav: not possible prior to the first guix pull <maav>i mean, to check if that's raising the lstat error <OriansJ>guix repl isn't available off a fresh 1.1.0 install <OriansJ>one has to do a successful guix pull prior to it becoming available <maav>but there's no problem, as you already have one guix running, so you have guile there too <OriansJ>I can give you the exact steps to duplicate the server (down to everything but the passwords) <ryanprior>I'm hoping the new release provides a nicer out-of-the-box experience :) <lfam>We'll need to test it more extensively this time, ryanprior :) <maav>OriansJ: head -1 $(command -v guix) will tell you where is it located <OriansJ>ls /gnu/store/ | grep guile | wc -l =>252; which one you want? <OriansJ>/usr/local/bin/guix isn't exactly a guile <maav>OriansJ: head -1 $(command -v guix) shows the first line of the script <lfam>I can try your reproducer in a QEMU VM OriansJ. If you think that will be adequate <OriansJ>maav: and #!/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash is not a guile either <maav>OriansJ: how many changes then... :( <lfam>Are you trying to figure out exactly which Guile executable is being used by Guix? <lfam>You can do something like `guix gc --references $(realpath $(which guix))| grep guile` <OriansJ>lfam: well depends how exact you would like to make it <OriansJ>A debian vm should probably be as close to the real thing as possible <lfam>Stand by... for a little while <maav>I've seen your last paste: /gnu/store/5780x8w59lg898p9a45c2i18lx6r25yb-guile-next-3.0.2/bin/guile <maav>while lfam is booting :) ***catonano_ is now known as catonano
<lfam>There's no way that encrypted /boot affects this bug... <OriansJ>lfam: Then just Debian with only standard selected (as minimal as it gets) on a single partition <OriansJ>removed nano, added mg, screen and htop <maav>OriansJ:what a weird thing :( <OriansJ>maav: hence why I report and try to help those who could fix it <OriansJ>I only know what I have done and what the results are. What happens in between is only known by those familiar with the code in question. *lfam downloads the Debian image <OriansJ>only have a 1Mbit connection here; so caching matters when I wish to setup a box quickly <lfam>Thankfully my downlink is pretty fast <lfam>I'm juggling two conversations ATM but I'm going to try reproducing this tonight (New York time) <maav>OriansJ: sure, thanks for that <maav>and lfam, thank you too :) <OriansJ>and I have a 5am work shift tomorrow morning <lfam>Gotcha :) I've noticed your musings on working for the state of MI <lfam>I'll use sneek to reply to you if it's too late <lfam>Bold to untar from the root directory :) <lfam>The Debian live image doesn't have enough free space to install Guix :( <lfam>I've increased partitions and filesystems without rebooting before, but in this case it complains that the kernel is still using the old partition table <lfam>Maybe I can make it work <apteryx>maav: hi! About the btrfs subvolume delete-generations fix, do I need a system generation generated with the fix for the delete to generate a valid /boot/grub/grub.cfg? <lfam>Hm, I can't figure out how to increase the space in the Debian live image <apteryx>So far I've just tested guix pull, then 'sudo guix system delete-generations 2m' for example, and it gave me a problematic /boot/grub/grub.cfg <apteryx>oh, it would, because boot-prameters is that thing read from a file <apteryx>e.g., /run/current-system/parameters <lfam>Alright, I think I can get past my space issue by using a desktop Debian live image <lfam>Sorry, apteryx, I dunno! <lfam>sneek: later tell OriansJ: I can't reproduce your problem :( <lfam>sneek: later tell OriansJ: I followed the steps you gave in the paste, and was able to `guix download` that URL without any trouble <maav>apteryx: you got me because i forgot to push a commit :) <apteryx>i can have a quick look while I'm testing it <maav>a clarification for a message in the installer, nothing big <maav>now the installer tells the partitions going to be formatted in the confirmation scring <maav>regarding btrfs, the problem were calling delete-generations or roll-back :( <maav>if you roll back to a generation without prefix-directory in boot-parameters will generate wrong grub.cfg when subvolumes don't match the final paths <maav>after the patch you can delete-generations without triggering the issue (which workaround was to reconfigure again), but the generated systems cannot be changed <apteryx>ack, that's what I thought since it relies on the boot-parameters of each generation. <apteryx>You have to reconfigure at least once with the patch defore delete-generations will work, right? <apteryx>(so that the boot-parameters file used will have the new store-directory-prefix entry) <maav>yes, the current generation must have it <apteryx>OK. That's what I hadn't taken for account in my last test :-) <apteryx>I'm guix deploying to the machine now, will retry after it's done <apteryx>thanks for the fix by the way! It's slip unnoticed for a long time <maav>only reconfigure/init must have the operating-system definition available, the other operations rely on the information already available on the generated system <maav>no problem, i noticed because i had to do something similar for grub locales, and saw that the parameter was missing there, so it was just easier to fix than to test :) <maav>well, now i'm gonna sleep tight and hopefully without jumping out of the bed because i forgot something :) <apteryx>Having looked at the code, I'm confident it'll work! <maav>testing is always a good thing, good looking code can have issues too :) <maav>have a good night/day you too <apteryx>the new declarative authorized-keys may be a bit problematic for 'guix deploy', unless its file was already managed declaratively. <apteryx>A peaceful coexistence (/etc/guix/acl remains what it is, and /etc/guix/generated-acls or something now gets the keys from the os config) would be nice. <sss2>hi all, samba on foreign host os storing /var inside store, so after every update samba loosing all databases, this is very inconvenient <apteryx>sss2: what do you mean by storing /var inside store? store is at /gnu/store <sss2>but it's persistent data, like user accounts authenticatiuon and such <apteryx>Oh! Is that how our samba package is configured? Regarding the loss of data; how's that even possible to write data there in the first place? the store is supposed to be read-only, so it should fail trying to write to such locations <sss2>i guess it is possible override data location by config <sss2>but this defaults does not looks sane for me <apteryx>but just to be sure, does 'findmnt /gnu/store' shows it mounted as ro? <sss2>ah, no, it's foreign host os <sss2>so this is not guix problem <sss2>most probably via ./configure; make; make install <apteryx>Are you using a systemd unit for the guix daemon? <apteryx>(just for your safety and prevent other similar experiences). The store should really be immutable for anyone else but the daemon. <apteryx>as for the samba issue... lemme see. <apteryx>I think it's the --localstatedir that should be set to /var instead of its default PREFIX/var <apteryx>hmm: Cannot create the folder '${LOGFILEBASE}' (error: [Errno 13] Permission denied: '/var') (at install time) <lfam>It's so annoying when packages do that <lfam>I had to patch that out for atop just a few days ago <apteryx>Eh. This one is using the WAF build system (Python something) <lfam>They know it's going to be in /var, but they still try to create it. As if it wouldn't already exist <sss2>also it would be nice to have something like firejail <sss2>and special approach to generate profiles is required on guix i guess <Bumblehorse>Could someone help me understand patches in packaging? I used guix edit on various packages to see how others used it, but every example is (patches (search-patches "filename.patch")). How does it know where this file is? When I look at the url of these packages I can't find the patch file anywhere. <apteryx>it's figures out the gnu/packages/patches subdirectory relative to Guix found in the Guile %load-path <ryanprior>Thanks for pointing out that LWN article about Kubernetes in Debian lfam, it definitely resonates. I have some thoughts about it, I should write up a short blog post. <apteryx>sneek: later tell maav successfully regenerated grub.cfg after a delete-generations! thumbs up! <lfam>I'm interested to read your post ryanprior! <lfam>It resonated with me too <Bumblehorse>apteryx: I finally understood what you meant by that. Could you point me in the right direction to figuring out how to add a patch that isn't in gnu/packages/patches? I can't seem to find anything in the manual or cookbook. <Bumblehorse>Btw lfam, I just searched up "guix git" and your github repository came up as the first result. Are you famous in the guix community? <lfam>No, I've just had that repo up for a while. It must have been the first on github or something <apteryx>Bumblehorse: are you working with a channel? <apteryx>I think patches are searched from the root of the channel in this case (not sure) <lfam>Where are you trying to put them? <Bumblehorse>lfam: I'm not quite sure what you mean. Maybe I should clarify that I am trying to define a new package. <lfam>Okay, where is the package? Like, are you working from our Git repo? Or using --load-path? GUIX_PACKGE_PATH? <Bumblehorse>Ooh, it just dawned upon me... Am I supposed to send in the patch that I want to use along with the package definition when sending it all in to be added to guix? <lfam>If the package required the patch, then it would all be part of the patch you'd create to apply to the git repo <lfam>I'm not sure about the answer to your question <lfam>I've used GUIX_PACKAGE_PATH for custom packages and put the patches in the root of that repo <lfam>I figure channels are similar <Bumblehorse>I guess I should look into setting up an actual enviornment for make packages instead of just using guix package --install-from-file= <lfam>It will help if you want to contribute them or even just to keep them organized <Bumblehorse>Oh I certainly want to contribute. The world needs gtick! <lfam>The progenitor of the drum machine <Rodon>what is size of packages that guix pull after first launch ? i am in train..so connectivity is not that good. if it over a 500mb then i would launch guix later.. <lfam>Rodon: I don't know the size but I recommend waiting <lfam>I found it too slow for trains <lfam>Or, too much for slow train networks <Rodon>i get this "Permit downloading pre-built package binaries from the project's build farm? (yes/no)" ***amfl_ is now known as amfl
<wleslie>Rodon: ime downloading binaries is so much faster than downloading source and building <wleslie>I could be wrong, but I didn't think `guix pull` updates installed packages, just the list of what packages are available <wleslie>oh it does update the package manager too, makes sense <wleslie>"Download and deploy the latest version of Guix" <wleslie>terminology is sometimes a bit confused, but "Guix" is the package manager, "Guix System" the distribution <lfam>The first `guix pull` will download more than subsequent runs <lfam>And then you also download several packages to build the first profile, right? <leoprikler>Ahh, you mean build dependencies like texinfo et al.? <leoprikler>Those are (potentially) subject to change every few months when core-updates gets merged and can also get gc'd, so I'm not sure whether that statement holds generally. <leoprikler>But sure, subsequent git pulls can sometimes reuse some packages. <janneke>it seems as if these job for the hurd are "waiting for something"? <mothacehe>hey janneke! Yes they are submited to the guix-daemon and waiting to be build. If you have a look to https://ci.guix.gnu.org/status you will see that there are a lot of pending builds due to bugs in the daemon/offloading mechanism. <janneke>mothacehe: ah yes, there are even older jobs...so "situation normal" i guess and i must just be patient <civodul>mothacehe: are you sure these are offloading bugs? not something like blocked fibers in cuirass? <civodul>i see guix-daemon processes repeatedly asking for armhf-linux offloading <civodul>they get "postpone" and keep retrying... ***apteryx is now known as Guest85966
***apteryx_ is now known as apteryx
<civodul>looking at process 25711 right now on berlin, it could be this <sneek>Welcome back OriansJ, you have 3 messages! <sneek>OriansJ, lfam says: I can't reproduce your problem :( <sneek>OriansJ, lfam says: I followed the steps you gave in the paste, and was able to `guix download` that URL without any trouble <civodul>mothacehe: i'm not sure it's a deadlock here: 72007, which holds the lock that 25711 wants, is just stuck trying to offload to armhf and keeps retrying on "postpone" replies <jlicht>Are there any clojurians using guix? <kmicu>jlicht: roptat heroically wants to package Java/Maven; Closure (for ClojureScript) is also difficult to package. *kmicu was a Clojurian in the past. <civodul>jlicht: there've been people working on clojure-build-system & co., so i guess the answer is "yes" <civodul>but there's the usual chicken-and-egg problem that Guix is not great for Clojure hackers until it has more packages <peanutbutterandc>Is it possible to set native-search-paths only for a single output of a package? <civodul>peanutbutterandc: no, native-search-paths applies to all the outputs <peanutbutterandc>civodul, I see... Thank you, Mr. Courtes. I was thinking if the gnucash-python bindings (shipped with the source itself, compiled with a flag) should be packaged separately (like the apt-people seem to have done).... <civodul>peanutbutterandc: thanks for the heads-up! <civodul>note that PYTHONPATH should not be in gnucash itself, only in Python <civodul>however, you may want to use 'wrap-program' so that PYTHONPATH is set when the user runs 'gnucash' <peanutbutterandc>I see.... I can see that this makes a lot of sense too. I could just separate the python bindings into a separate output (gnucash:python) and then trust that the user will either have gnucash:python and python (from guix) in their environment.... <peanutbutterandc>Being a foreign distro user, I tend to think a lot in terms of making guix-installed everthing just ready-to-use with the host OS. In this instance I was thinking of using gnucash:python with host-os python. <peanutbutterandc>But not thinking that way does make a lot of sense. I think I'll try and re-do the patch then. Thanks! (: <jlicht>civodul`, kmicu: I thought as much! I was mostly wondering if our `clojure' package can be made to also contain the 'clj' script, as that would at least allow using clojure with it's own dependency solution (deps.edn) <sneek>maav, apteryx says: successfully regenerated grub.cfg after a delete-generations! thumbs up! <maav>sneek: later tell apteryx thank *you* for your tests :) <janneke>hmm, the shepherd does not like a kill -HUP <civodul`>janneke: oh, maybe it doesn't handle it at all? ***civodul` is now known as civodul
<maav>janneke: yes, it doesn't like at all, my emacs died too :) <maav>(i run the daemon on an user shepherd) <maav>hmm, nope, i just sent it to emacs because my fgrep was wrong (it has shepherd as the daemon name)... shepherd stays alive <janneke>civodul: looks like it -- i tried: herd restart shepherd -- it does handle that ;-) *janneke just moved the git daemon into a user shepherd service <janneke>hehe, some tasks become such a habit that it takes a while before it occurs to me to automate them <sneek>zimoun was in #guix 2 days ago, saying: oui oui tout le débat… pour moi, il faut décider pre- ou post- et s’y tenir. C’est à dire corriger quand une incohérence est trouvée, comme une typo en fait. (-:. <maav>janneke: hehe, then you'll get used to the automation too :) <jlicht>janneke, maav: how do y'all start user shepherd? I'd really like for it to be linked to user sessions, instead of crummy old `.profile' shenanigans, but that is what I'm stuck with at the moment <maav>jlicht: i currently do it with my xsession, but i think that global user shepherd services would be great for guix system <maav>subshepherds perhaps ;-) <jlicht>"not just the shepherds, but the shepherdessess, and the shepherd-children too" <maav>dark the path is, anakin <maav>as systemd may have some inspiration on lots of points... <maav>is this the right place to talk about shepherd? because i have some ideas there too.. :) *zimoun is AFK; g_bor[m], feel free to ping me whenever you want. <peanutbutterandc>What is the difference between #:modules and #:imported-modules inside of the (arguments) field in a package definition? And where should I put (guix utils) in order to use it in a certain phase, and why? <peanutbutterandc>I ask because I don't want this 20+ minute long build to fail again on me for the third time. <peanutbutterandc>This is interesting, I grep-ed in the source tree and there isn't a single instance of '(guix utils)' inside the (arguments) phase... <peanutbutterandc>Strange... I put (guix utils) in #:modules, and then in #:imported-modules, and then in both of them, and the build does not even start. <roptat>peanutbutterandc, in imported modules at least, you need to tell which modules to import, as well as any module they need <roptat>(guix utils) has #:use-module (guix config), but if (guix config) is not in the build-side, then (guix utils) cannot open it <roptat>usually, it's not a good idea to use things outside of (guix build ...) because they have dependencies on lots of things from the host side <peanutbutterandc>roptat, I saw that gnu/packages/xorg.scm: Line 4957 used an unquote to call the specific procedure from (guix config) and tried that and the build is running now.... <peanutbutterandc>however, I agree that putting in just in there in the build seems cleaner..... <roptat>ah yeah, the unquote there means that the code is run on the host-side, instead of the build-side <roptat>that way you don't have to import (guix config) and co <peanutbutterandc>roptat, could you please tell me what #:modules and #:imported modules does please? <peanutbutterandc>Also, should I make it a rule to never use anything outside of (guix build ...) in build side? <roptat>if you really have to, you might use other modules of course, but in general stick to (guix build ...) <roptat>I'm not really sure what the difference is between #:modules and #:imported-modules <nckx>peanutbutterandc: I don't agree that running as much as possible ‘late’ (during the build) instead of early on the host side is cleaner. Which procedure is it? <nckx>roptat: Me neither, and what's worse is I've known and forgot twice 😉 <peanutbutterandc>nckx, I later realized that I was concluding exactly the opposite of what roptat was saying. I kinda' took each extra #:use-module as 'polluting' the .scm file, when in fact what was being said was that it is better only to limit oneself to (guix build ...) packages to be run on the build side. Sorry. My bad. <roptat>although it might be something different (with-imported-modules vs #:imported-modules) <roptat>for modules, maybe see build-expression->derivation: "modules is a list of names of Guile modules from the current search path to be copied in the store, compiled, and made available in the load path during the execution of exp" <nckx>peanutbutterandc: No bad, no sorry. Good to get any confusion out into the open where we can chase it away with sharp sticks. <peanutbutterandc>nckx, (: I just hope that next time you know about #:modules vs #:imported-modules, you take the time to scribble it down in the reference manual somewhere. :D <peanutbutterandc>I have been having these issues where the package I'm working on - the build fails after the actual 'build' --- in the custom defined phases. And then the issue has to be debugged and then the build starts all over again... and I understand that this is a disadvantage of functional package management. But I wonder if there is any work-around or something <nckx>A gross hack I sometimes use for me-side bugs is to temporarily move my failing phase earlier (or delete the 'build phase, same effect), at least until I get the syntax hammered out. Of course that doesn't work if your phase absolutely relies on a build artifact that's hard to fake. <nckx>I also use --keep-failed a lot. But there's no way to resume a failed build after tweaking it, no. *nckx also has to go AFKBBYLBBQ o/ <peanutbutterandc>I see... it's all right though. The benefits of guix far outweighs this minor inconvenience. (I'd love to have some beefy computers someday to which I could offload the build jobs to) <maav>peanutbutterandc: for me --keep-failed works usually well, as i can go to that folder, source the environment and do the steps manually until i find where is the problem... later you have to do all the build, true, but you should do it anyway to check you did it right :) <zzappie>how do I stay up to date with Guix Days? <zzappie>There is no mail in guix-devel on this subject <maav>tumbleweed passing along the screen... <maav>the deadline for proposals is this friday <maav>but i'm not aware of any proposal yet, do you have one? ^.^ <zzappie>maav: well, there are lots of topics I'm intrerested in but not particularly expereined with to give a talk :) <maav>zzappie: probably civodul has more info about this, i'm on the spectator side for this one too :) <zzappie>The thing is that this not FOSSDEM with lots foss people walking arround (never been to fossdem). Guix days (unless heavily advertiesd outside Guix circles) will probably on the radar of people who already subscribed to guix mailing lists. <civodul>zzappie, maav: zimoun & roptat are those who take care of the Guix Days, i don't really know more <zzappie>So unless there is a "guix secret features commitee" It hard to think of proposals :) <civodul>proposals are supposed to be sent to guix-devel, though i think that can be intimidating <maav>civodul: thanks, at least you had more info than me :) <civodul>perhaps there should be individuals listed to contact <roptat>civodul, yes, I prefer an alias, because I don't want my address to be present on a web page (I know it's in git, but spammers don't seem to go that far) *zimoun re-reads the announce <zimoun>civodul, roptat: yeah the proposal could be sent individually via an alias. <roptat>zzappie, there's only one proposal by me for now. If you have subjects you're interested in, you can also propose a discussion topic, it doesn't require a presentation if you don't feel like it :) <zimoun>how is it complicated/long to create an alias? <roptat>maav, want to talk about the translation? :) <zzappie>I think one topic that will be interested for many is p2p substitutes <zzappie>IPFS or GNUnet or what else is out there <zimoun>maav, roptat: it could be cool to talk about translation. The current TP and PO workflow. And maybe present the “experimental” weblate. WDYT? <roptat>there's no "experimental" weblate for now, we're still waiting for the savannah admins to approve a separate project for it <maav>touchy subject, yes, hehehe <zimoun>zzappie: yeah it could be nice. It had been proposed as Outreachy internship but not selected by any applicants. <roptat>zzappie, would you like to lead a 30 minutes discussion session on this topic? that would be very nice! <peanutbutterandc>If anybody here is also interested in gnucash python bindings, please do take a look at: https://issues.guix.gnu.org/44309 I have just now sent in an updated patch. Python bindings are separated into it's own output, now. With it, one can use gnucash-python with `guix environment --ad-hoc python gnucash:python`. <zimoun>maavv, roptat: ah zut! All the TP workflow could be nice. :-) <peanutbutterandc>Also, please do chime in (preferably there), if there is any further polishing that I can do. <maav>roptat: i think i cannot give a talk right now, but i'd love to on the future... <zimoun>civodul: Do you know how could we create an alias? Or could we reuse an alias (guix-blog for example)? <zimoun>zzappie: feel free to send a proposal about it. :-) <zzappie>I think I once heard str1ngs is intrested in p2p guix subject too <civodul>zimoun: it's on fencepost.gnu.org; tell me what you want and i can create it <maav>zzappie: i'd love to hear about that subject too, hope i see your proposal soon :) <zimoun>civodul: I send you of off list. <zzappie>maav zimoun: Great! I'll write It soon. I'm not super experienced on this subject but this is defintetly something I'm interested working on :) *zzappie recently found zrythm. It's like dream came true <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, maav says: thank *you* for your tests :) <zimoun>civodul: thank for the link. But ouch! it hurts my eyes… <zimoun>civodul: let me know when the alias is created. Then I could send a re-call and in the same time indicate this alias. <civodul>so far we've managed to stay below that ridiculous shebang max line length :-) <civodul>reminds me that iyzsong had posted a binfmt_misc trick that would allow you to write #!python (say) and it would look up "python" in $PATH or something <civodul>useful, but not portable unfortunately <zimoun>civodul: cool! Thank you. I will do (if roptat does not beat me :-) after the massive Bioconduction upgrade. ;-) <roptat>I'm finishing the translation, 36 strings left <roptat>how would you translate "out of memory killer"? <maav>"gestor de llenado de la memoria", close to full-memory checker, with the actual name in parenthesis <maav>i'm not proud at all... and i don't even have a mark there <roptat>maav, don't you have it translated already? it's earlyoom <maav>yes, i copied it from there, but... i ain't equally proud of all text, hehe <roptat>maybe "gestionnaire du remplissage de la mémoire" then <roptat>there must be an existing translation though <maav>i have a FUZZY mark on the full description, that's why... these means "i must think again this", each FUZZY increasing the need of it <maav>in spanish out of memory usually is translated to: la memoria está llena <maav>but the construction of "memory-is-full manager" sounds a bit forced to me anyway <civodul>the whole "kill" terminology in Unix sounds terrible to me <nckx>OTOH a ‘manager’ that kills you when you misbehave sounds a bit euphemistic to me... <leoprikler>Imagine your tasks unionizing in demand for more RAM and less work hours. <roptat>I don't understand this sentence: A boolean indicating whether the positive adjustments set in @file{/proc/*/oom_score_adj}. <maav>i'm too much into dark humor to say something here on-topic, so i'll stay back and agree with civodul that it might be inappropiate the kill terminology in a world-wide project... even though I'm sure they didn't think about that term was coined <roptat>yeah, but I'm not sure how to complete it <apteryx>I think it originated from one of my commit, so I'll try providing you with the missing part ;-) <maav>roptat: oh, true, i also saw this one and didn't say a thing but understood ...adjustments _are_ set in... <apteryx>I guess it's missing ' should be ignored.' at the end of the sentence <apteryx>the doc of earlyoom says about the -i switch 'user-space oom killer should ignore positive oom_score_adj values' <maav>makes complete sense, the option is called ignore-positive-oom-score-adj? <maav>i'll change that too, thank you apteryx and roptat :) <maav>(in my translation i mean) <roptat>apteryx, thanks! can you fix that in the manual? <nckx>nckx@berlin ~$ sudo -i guix offload test /etc/guix/machines.scm localhost → guix offload: error: failed to connect to 'localhost': Timeout connecting to localhost ☹ <nckx>The ‘sleep 10d’ that's launched as a hacky SSH tunnel isn't running on the hosts but berlin doesn't seem to have noticed that. <roptat>mh... offlate tells me I'm missing two strings, but hiding already-translated strings shows nothing... I might have found a bug :/ <apteryx>roptat: pushed with commit 794928a906 <civodul>nckx: problem is there are several "localhost"s <civodul>the trick is to find which one's not responding <roptat>weird, python-polib says 10038 messages, poedit says 10036 and msgfmt says 9886 <nckx>civodul: You mean IPv4 vs 6? Otherwise I don't actually know what your point is, although I'm sure it's good nonetheless. <nckx>civodul: Oh, no, I'm not confused about that. <nckx>Both are mine. roptat's is commented out. <nckx>They are IPv4-only, but I don't have bogus AAAA records AFAIK. <maav>roptat: are they checking the obsolete strings too by chance? <roptat>well, 100% but with a few issues ^^' <civodul>nckx: i mean /etc/guix/machines has several occurrences of "localhost" and the error message doesn't tell you which one it is that's not responding <civodul>it should print the port number so we know *civodul goes ahead and rewrites a section or two <nckx>civodul: No, that's not an issue, the only occurrences are mine. <nckx>This was all working fine y'day and nothing™ has changed. ***jonsger1 is now known as jonsger
<maav>nckx: 111 seems to be a connection error, and the message shows the daemon socket <maav>ohhh, i get it, the port is open with ssh -L, did you try -vv to check which has traffic? <nckx>I can ask the daemon to build things locally just fie. <nckx>maav: Correct, this is a ‘temporary’ ‘while :; do ssh; done’ hack that rekado_ set up ages ago. <maav>nckx: to recap then, there are two of them and you don't know which one is failing (something that perhaps you're right should be told by offload script instead of just the backtrace) <nckx>maav: No, there's no uncertainty or confusion about hostnames (sergei is the one that's failing). I just don't understand what's going wrong. <nckx>I'm currently staring at port numbers in case I cross-wired something somewhere. <nckx>‘-bash: /home/hydra/.bash_profile: Input/output error’ <nckx>Mystery probably solved, I guess. <maav>nckx: then it wasn't that hard <maav>what was the problem? bash config? :( <maav>checking offload.scm and ssh.scm code it seemed quite simple, so a plain ssh should be equivalent, but i hadn't got the full picture yet before you solved it :) <nckx>It was ‘hard’ because I was fixated on finding configuration or software failures, not ‘hardware is broken, the end’. 🙂 <nckx>maav: Note ‘input/output’, not ’syntax’... <nckx>sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory <nckx>That was not on my mental checklist. <maav>oh, so the disk was ko... <maav>yes, and it's a good thing you don't have to think about it usually, let's see in some years with ssd... <jsoo>I've been having problems with ghc libraries recently. For instance, I have xmonad and xmonad-contrib installed but they are missing from $GHC_PACKAGE_PATH <nckx>maav: I can't do anything (it must be a freak coincidence that the stack to log in over SSH still happens to work -- nothing else does) do find out if it's a file system or hardware problem. These are relatively new 1-TiB spinning drives. If it's hardware, I am disappoint, but not surprise. <maav>yup, if sudo doesn't work... you cannot do almost anything, su doesn't work either, does it? <pimi_>can someone help me with this <pimi_>i want to indent some code using ./etc/indent-code.scm <pimi_>i want to indent some code using ./etc/indent-code.el <pimi_>and I get every time this message "Symbol’s function definition is void: cl-pushnew" <raingloom>pimi_: just a guess, but you might need some Emacs modules to be installed. <civodul>pimi_: i think it's a bug that maav fixed hours ago <pimi_>ok, I will test the latest version from git <maav>pimi_: yes, sorry for that, i overlooked that cl-lib wasn't loaded there :( <emys>hey, I am trying to set up emacs as a daemon with guix. <emys>everything works from the command line <emys>however, when I try to establish a user-space systemd (guix runs on top of debian on my machine) emacs doesn't seem to find use-package <emys>any ideas? I assume its because systemd doesn't have some variables configured (I guess) that help emacs find the guix-installed extensions <emys>ah, never mind I figured it out (asking the question really helped my brain). I now have added EnvironmentFile=/home/myuser/.guix-profile/etc/profile and it works like a charm. <Bumblehorse>I was told that when I have a package under $GUIX_PACKAGE_PATH I should put its required patches in that root directory, which I have done. But I'm getting the error "search-patches: unbound variable". I assume this means that it still can't find the patch file or I am missing a module. Any ideas? <roptat>Bumblehorse, no, that means guix doesn't find the function called search-patches <roptat>that's defined in (gnu packages) <nckx>maav: No, sudo nor su work and I've disabled password root logins like a good admin. But this is guix, so maybe one of the many /gnu/store/*/sbin/sudos will work... <nckx>Now I can't even SSH in as nckx. It's probably dead. Good-bye, Sergei. You will not be building 1.2. <lfam>It looks like CI has skipped evaluating some pushes <lfam>Not failed or in progress but absent <cbaines>lfam, Cuirass polls, so it will just skip commits <lfam>I always though it would evaluate each push <cbaines>From memory, I think it polls every 15 minutes <cbaines>I think it was stuck either yesterday or the day before though <lfam>It looks like it's still stuck <cbaines>So there is probably a larger gap than usual <lfam>Can you clarify what it skips? I know it doesn't evaluate it each commit, but shouldn't it evaluate each push? <nckx>Only if nothing newer was pushed during the 15-minute window (or longer, if polls fail). <cbaines>There could be derivations that Cuirass doesn't find out about, but only where they appear and then disapear within that window (which is unlikely) <lfam>Derivations of skipped pushes would be handled in later evaluations <nckx>Right, yes, just not as separately identifiable things. <cbaines>At some point I'd like to get data.guix.gnu.org broadcasting in some easy to consume formats the data it has about changes to the Git repository <cbaines>It takes the architecturally dubious, but seemingly reliable and up to date approach of subscribing to guix-commits <cbaines>and it would be nice if that information could be made available in a way that didn't require interacting with email <lfam>It would be interesting to run a parallel Git repo based on guix-commits and see what changes <lfam>Or at least it would be diverting <maav>cbaines: and the first commit is mine... o.o' looking into it <maav>cbaines: how could i get that log? :( <maav>oh, the X shows it, nvm :) <jlicht>maav: I was $TODAY old when I figured out your IRC nick \o/ <nckx>maav: Hah! :-D I ssh'd into the CI... Shows what I know about this ‘Guix’ thing. *nckx happily admits to knowing nothing about Cuirass though. <cbaines>(package-license package) can be a list of licenses, not just a single one, so license-name will fail for some packages <nckx>That commit looked fishy to me & I should have spoken up. <maav>jlicht: hehe, you know, miguel was taken :) <maav>nckx: 141.xxx is the broken-disk machine? because all the failures show it <cbaines>I was going to make some food, but I can revert 44daec7fa4ae97a3c4490adf461322ec9f7a780a unless someone else is poised to do so? <maav>some log say: "In procedure scm_lreadr: #<unknown port>:16:140: Unknown # object: #\<", which seems more another kind of error to me <nckx>maav: No, 141.xxx are all the local build nodes for berlin (the host behind ci.guix). These are about 25 x86_64 machines in the same rack. {dmitri,sergei}.tobias.gr are both aarch64 that I host at home, but you couldn't have known that. <maav>nckx: thanks for the info, i was worried i broke everything :( <nckx>‘waiting for the big garbage collector lock’ followed by a silence time-out could be just that: berlin's GC's are notorious multi-hour affairs. <nckx>Although the time-out should of course be fixed not to count those. <nckx>maav: Don't worry, you will yet if you stick around long enough. <cbaines>also, I'm not sure what state to revert to, so I'm just going to leave it <jsoo>Hey Guix, I have a question/thought. Can a build be paused? It might be cool to send a signal to a very long build to pause/resume later *vagrantc would like that too <vagrantc>in my experience(e.g. ctrl-Z), just suspending the process only suspends the client, but the daemon keeps building <vagrantc>obviously won't start new builds, at least <nckx>jsoo: I frequently pause builds by sending SIGSTOP to the builder's process tree. <nckx>Then resume with SIGCONT. <nckx>Just so y'all don't think I'm too 1337: I use htop's handy-dandy graphical tree to do so. ‘c’ to select subtree, F9 to send signal. <vagrantc>using kill -SIGSTOP/-SIGCONT and the pid? <cbaines>I'm very unfamiliar with debugging symbols, are debugging symbols available for SQLite in Guix? <vagrantc>you need to get all the processes in the entire tree? <nckx>vagrantc: Not per se, e.g. pausing the top level make will eventually pause the build once all child GCCs finish, but why wait. <jsoo>nckx: do you kill the process run with guile --no-auto-compile ...? <nckx>All that said: a straightforward way to do this on the CLI would be rad. <nckx>We have a ‘guix ps’-like thing who's real name I always forget. <jsoo>This also reminds me that someone recently made nix-top - a top like way to view nix processes <nckx>jsoo: ‘Kill‘ with SIGSTOP, yes, but including all subprocesses. <nckx>That returns emptiness but no error here so I guess so 🙂 <jsoo>wait, nckx, do you send the signal to all subprocesses? <jsoo>this will help a lot i think <nckx>It's not strictly necessary but why think? Never think. Waste of time. <jsoo>i recently was able to replace htop with the top from procps. i don't really want to go back, but... <vagrantc>i have never figured out how to get iowait information from guix's top <nckx>Does ‘top’ have an equivalent to htop's ‘p’ key? (Which I added for Nix but is pretty vital on Guix too.) <nckx>jsoo: What motivated you to switch to top? <lfam>vagrantc: Press 't' to cycle through the different views until you get the classic view <lfam>Soon all the tops will be like Guix's top: we are using a later version than most distros <nckx>Well, some distros intend to keep patching top to look like it did several years ago. Maybe vagrant is already using such a distro. <lfam>I suppose that might be a viable approach ;) <jsoo>nckx: fewer dependencies, mostly <jsoo>though it seems like htop is very small... so no reason, really :) <nckx>jsoo: I don't want to be pedantic but htop and top have the exact same dependencies, and are both 1.6 MiB themselves. <jsoo>nckx: yep, just saw. i have no reason, now <jsoo>i suppose to me i like top since it comes in %base-packages <jsoo>but yeah there really is no reason not to use it <lfam>This reminds me of my atop patch. I'm going to push it <jsoo>suppose there were a subcommand of guix processes to pause/resume some build. what would you want it to look like? <jsoo>maybe that's a question for the list? <nckx>Bikeshed ahoy. Looking at the output that ‘guix processes’ creates here, I'd like a simple command/option that simply lists which ‘packages’ are being built. And then offers ‘guix <that> --pause|--resume NAME’. <jsoo>yeah that's kinda what i thought, too <nckx>I have a simple script that lists /tmp/guix-build-* (with some liveness filtering). If I'm building libreoffice and htop, it just prints libreoffice and htop. Something like that. <nckx>Definitely a good listpost IMO. <nckx>Just brace for the shed. <jsoo>yeah, no problem. discussion would be good <cbaines>To answer my own question about SQLite debugging symbols in Guix, adding "debug" to the outputs for the package magically made them appear <cbaines>I haven't managed to convince gdb to use them though, so I think I'll need to install sqlite:debug, and then try and reproduce this segfault again <maav>i knew because i had to translate them, ofc :) <maav>but i didn't see your question :( <cbaines>maav, thanks, that might actually help. I've added that on to the guix environment command I'm using now <cbaines>I don't know yet, I'm waiting for another segfault now <g_bor[m]>That is why I asked why the symbols did not work... <jonsger>hmpf my cuirass fails evaluating with the same error <cbaines>g_bor[m], my knowledge about debugging C is extremely lacking... I think I've just about managed to potentially use the --with-debug-info flag successfully, and I'm attempting to reproduce the segfault again <nckx>vZS1aHdksSQKx2tx: Welcome! Questions are always welcome, too. *nckx will be away for a while though. <vZS1aHdksSQKx2tx>This first question I have is that I appended a line for GUIX_LOCPATH to the bottom of my user's .bashrc file. Is this alright or should I put that configuration elsewhere? <maav>vZS1aHdksSQKx2tx: if you install the glibc-[utf8-]locales into your profile that variable is already defined by $GUIX_PROFILE/etc/profile, are you on Guix System or on a different distribution? <vZS1aHdksSQKx2tx>And I did install glibc-[utf8-]locales but the installer kept asking me to update that env variable <vZS1aHdksSQKx2tx>I just checked my $GUIX_PROFILE/etc/profile and GUIX_LOCPATH isn't defined there <vZS1aHdksSQKx2tx>Should I move my GUIX_LOCPATH definitoin from ~/.bashrc to $GUIX_PROFILE/etc/profile? <maav>no, that file should be read-only, vZS1aHdksSQKx2tx <davidl>maav: re " some log say: "In procedure scm_lreadr: #<unknown port>:16:140: Unknown # object: #\<"" I reproduced this from commit 7c02eb6 and filed a bug-report minutes ago. <maav>vZS1aHdksSQKx2tx: i don't have any modification for that on my .bashrc, and i don't get that info... where do you have the locales installed? <maav>is it on your profile or system wide? <maav>and ~/.guix-profile/etc/configure does not include a line for GUIX_LOCPATH then? <vZS1aHdksSQKx2tx>maav: I don't seem to have that file on my system (~/.guix-profile/etc/configure) <maav>vZS1aHdksSQKx2tx: etc/profile, sorry, my mind... <maav>on my machine i have them on the global, but on a borrowed one where they are on the user profile i see 'export GUIX_LOCPATH="${GUIX_PROFILE:-/gnu/store/xxxx-profile}/lib/locale${GUIX_LOCPATH:+:}$GUIX_LOCPATH"' <maav>hmmm, vZS1aHdksSQKx2tx i think i can reproduce it, now i have to find why that's happening when i install a fresh profile but not in my normal one... <vZS1aHdksSQKx2tx>Also, my definition is not very dynamic. I just put "GUIX_LOCPATH=/home/dummy/.guix-profile/lib/locale" in my "~/.bashrc" ***familia_ is now known as familia
***V is now known as ^
<apteryx>is it possible to have a root user inside the chroot (id = 0) ? samba's test suite requires that <civodul>apteryx: in the build environment no <civodul>it's surprising that samba's test suite needs that <civodul>it's only feasible with unprivileged user namespaces <apteryx>apparently the tests attempts to set password with smbpasswd, which requires id = 0 <efraim>TIL icedtea@1 will FTBFS if the date is more than 10 years in the future <apteryx>maav: oh, perhaps! I've never used fakeroot ***^ is now known as V
<efraim>java.lang.RuntimeException: time is more than 10 years from present: 1420063200000 <maav>efraim: isn't it on our bootstrap path? <efraim>my aarch64 board sometimes gets the time wrong, it thought it was year 2211 <maav>how could be the current date more than 10 years from present?? i don't get that o.o <maav>i mean, how does check the present then? <efraim>if now isn't now, when is it? And I'm always here, wherever I am <efraim>I'll have to look at the source, I knew the time was off so I rebooted it <vZS1aHdksSQKx2tx>I have one other issue and I don't know if it's related to my locale problem. Numbers that I type don't show up in IceCat. <nckx>vZS1aHdksSQKx2tx: You need to install a font package, such as font-liberation. <vZS1aHdksSQKx2tx>Thanks for the link. I've got the info version open in Emacs now. I'll work my way through it. <vZS1aHdksSQKx2tx>Going to have to spend a lot of time with this manual. Will probably have to reinstall a few times to get it done the right way. Thank you all for your patience. <maav>vZS1aHdksSQKx2tx: you're welcome, ping again if you have any other issue <maav>efraim: java.scm says "Some of these timestamps cause problems as they are more than 10 years ago, failing the build process." but if some failed that mean there are some missing... <vZS1aHdksSQKx2tx>Audio seems to be working good after I installed pavucontrol. Very impressed. <lfam>There are some audio problems with Guix on other distros but hopefully "someone" will resolve them soon <apteryx>ss2: I'm readying an updated samba version for you to test! ***vZS1aHdksSQKx2tx is now known as vZS1_guix
<mroh>is it only me? `guix pull` on current master fails in guix-cli.drv? <lfam>While it works, mroh, what is your `guix describe`? <mroh>ok, thanks, then it's one of the channels. <lfam>No, I meant "while it is working on building `guix pull`" <lfam>My computer is not that fast ;) <lfam>Now I'll try pulling some older commits <lfam>Commit 3728ed7c773e09c86c0f11b2da3fc96c3794743d is good <sneek>mothacehe was in #guix 14 hours ago, saying: yes definitely!. <lfam>I've sent a bug report mroh, continuing to search for the faulty commit <mroh>thanks, I'm searching too... e1bd62eb5ce0f2410b2607f157989588791b43e0 works also <lfam>It's good through 98c4f108f2f34ba4e333a0017e69d164ec3502e2 <lfam>Only two more commits after that <lfam>Testing 21df702808a8f4491e1ef5badc607748288fa69a, since the subsequent commit is trivial <mroh>I'm confused ;) Only that snap thing is left? <lfam>Yes, if I understand correctly <lfam>So, each push (I think) to the Git repo should get built there, to provide substitutes for `guix pull` <lfam>I see there is another newer commit now <ngz>lfam: Did I mess up somehow? <lfam>I'm currently doing `guix pull` with the latest commit (wireshark update). Looking at the code, I don't see what could be wrong <mroh>weird. My interpretion of the error would guess, this must be commit which changes a service record or something, but there is none... <lfam>I successfully did `guix pull` for the last several commits, so I'm not sure what's up <lfam>It failed when I tried going from de5659d7d65fe8a8ff579ad2353e6036fb8db2bd to HEAD (current master) <lfam>What if you try again, mroh? <lfam>I can't reproduce it now... <lfam>I rolled back to where I started, did `guix gc`, and now I'm trying again <lfam>And I deleted the `guix pull` generations I just created <lfam>I wonder if it's a case where you need to pull to some intermediate commit... <mroh>yes, works now for me too. One commit (wireshark) later. <jonsger>mroh: I think I encountered the same :P works now after just do a pull after the failed one :P