<nly>a fun result ;; $97 = 666 <nly>the number of unique git-references-urls in (gnu packages emacs-xyz) <evhan>Hi there, looking for a way to list packages that include a file, by name or regexp. Is that possible? <evhan>Like guix package -s, but for package "contents". <apteryx>evhan: not really, unless you happen them installed under /gnu/store <atw`>not sure if that's possible, evhan, because package contents are only known after they are built <apteryx>we'd need some kind of database to be generated and maintained by a build farm for this use case <evhan>Right, I figured that would be the case, hence the scare quotes. <Jarak>Hi folks. Question that has probably been answered a million times before, but which I couldn't find the answer to: How exactly does one install Guile 3.0 with Guix? I can't see a version 3 package in the packages list, and when I try searching with Guix on the command line, it doesn't list anything. Even following the Guile Downloads page's ad <Jarak>vice, to append @3.0 to the Guile, doesn't work. <Jarak>jackhill: Looks like you are correct! To be honest, even if I had spotted that one, I probably would have skipped over it. Thanks :) <apteryx>(regarding native-inputs for a python package tests dependencies) <Jarak>On a slightly-related note, I have been having a lot of trouble with trying to get Guix to work on a new (virtualized) Fedora 31 install. I followed the binary installation instructions, but that didn't work amazingly well, and there are still problems - primarily, I keep getting the message about installing locales no matter what I do, and I keep <Jarak> having to start the daemon manually any time I want to use Guix. I did look at the Application Setup page of manual, but none of what is listed there has helped. Would the best thing to do be to open an issue on the issue tracker? <Jarak>(forgot to mention, I searched the issue tracker already for issues with 'Fedora' in them, and didn't spot one that seemed to be the same as mine) <jackhill>Jarak: yeah, I think the name probably made more sense when guile 3.0 hadn't been released yet (compare to emacs-next). If we lucky, before not too long 3.0 will be the default guile, and this peculiarity will be behind us. <jackhill>no idea about the fedora issues unfortunately <Jarak>Ah, that makes a bit more sense now. Yeah, I imagine with the Fedora problems, it's probably not a quick & easy fix - I'm more looking for how and where best to supply requisite information so that somebody who has a clue about such matters can investigate. It's probably that I have done something wrong, but I can't work out what. Thanks again : <jackhill>oh, an idea about locales, you need them installed in both the environment in which you run the guix command (so you're user's profile), and the environment the guix-daemon runs (so root's profile for guix on another distro). If you haven't put it in both plces it's worth a look. <Jarak>Hmm, that could well be the problem. I'm not in a position to check on that right now, but I'll try to remember to do so as soon as I can. <Jarak>Yeah, I have done that step. Repeatedly. And confirmed that GUIX_LOCPATH is set appropriately. I still keep seeing the error message. <terpri>Jarak, does your locale ($LANG) exist under the $GUIX_LOCPATH directory? (only likely to be the problem if it's an uncommon language or non-utf8 locale) <terpri>and yes, please file issues for these kinds of problems <Jarak>Hmmm, not sure - I'll have to look when I get the chance. That also might be the problem, as I'm quite possibly not under one of the utf8 locales. <Jarak>Anyway, I've got to run, but thanks everyone! :) <efraim>has anyone successfully built the vim update? ***apteryx_ is now known as apteryx
<cbaines>efraim, I just tried building it twice, and got a test failure both times <efraim>it fails on both of my machines, on bayfront and assumably on berlin <fishinthecalcula>Hi Guixers! I'm trying to host a development Wordpress instance in a Guix System container on my laptop. Right now I'm using a shared directory to hold WP code and Apache and PHP-fpm are working perfectly. I'd also like to host the db inside the same container but since I would need to load an existing DB, I was wondering if there's any way to run mysql dump after boot and before shutdown to load/store the DB in the <fishinthecalcula>shared directory. Should creating two simple services that run something like "mysqldump -u ... -p ... > dump.sql" suffice? Thank you <guix-vits>fishinthecalcula: symlink to shared db (never worked with db')? <fishinthecalcula>guix-vits: Hi! I'm also no SQL wizard, I'm still learning but I think the symlink would only be half of a solution: IIUC the actual db file would be in the shared directory and a symlink would have to be created each time I start the container (which could be often, I'm doing this to have a local Wordpress plugin development setup) so I would still something to run "ln -s /shared-dir/mydb /var/...", is that correct? <guix-vits>fishinthecalcula: idk. why did you created this container immutable? <fishinthecalcula>guix-vits: I was not aware of the possibility of having a mutable Guix container. Are you talking about a Docker exported Guix container? Right now I'm running the Guix System on my laptop and to start the container I'm using guix system container -N my-config.scm and this is my config https://paste.debian.net/1133093/. I never looked into Docker but maybe it could be a temporary workaround. Thank you! <guix-vits>fishinthecalcula: possibly i'd mismatch docker and vm-images. <guix-vits>fishinthecalcula: in manual, there is a --share=source=target flag. Probaly you can mimic the /var layout in your /shared-dir, and mount it in /var/... of container (as --share is rw, opposed to --expose)? <fishinthecalcula>guix-vits: You mean QEMU images? Yeah that's where I started from but to have a persistent state one is supposed to generate an actual image every time the configuration is changed and use that instead of the output from guix system, and I like very much guix system the functional way of spawning things :D. <fishinthecalcula>guix-vits: Yes I'm starting the container with the command "guix system container ${CONFIG_PATH} --network --expose=$HOME --share=${SHARE_PATH}=/exchange". You was suggesting to start it like " ... --expose=$HOME --share=${SHARE_PATH}/mysql/foo/bar=/var/mysql/foo/bar"? <guix-vits>fishinthecalcula: yes.. why not, after all :) <guix-vits>but i'm not sure if the mountpoint will be created if not existed in Docker image. <fishinthecalcula>guix-vits: Yes, right now I'm really ready to try everything, damn WP... I'll try and report back if successfull, thank you very much for your support! <fishinthecalcula>guix-vits: In a "simple" Guix container mount points are created also if not present IIRC. <efraim>'guix build foo' doesn't return a string, it returns 0 <efraim>any idea how to retrieve the directory? <efraim>I think my problem is I'm using system* and not something else in guile <efraim>I get the directory as an output, but the return value is 0 <guix-vits>efraim: manual's --log-file example: guix build --log-file `guix build guile`. Maybe it's `-sensitive? <efraim>guix-build in (guix scripts build) returns #<unspecified> *guix-vits flushed, expressing: "idk about programming" <rekado>efraim: users tell me that vim fails its test suite. There also is no build of the latest vim on cuirass. <efraim>rekado: with 8.2.0332 or 8.2.0343? <efraim>guix weather says it's not on berlin yet but it should be on bayfront <rekado>mostly “Unexpected swap file: .a.swp” <rekado>so perhaps the test suite isn’t parallel safe <nckx>rekado: The tests aren't run in parallel. <nckx>They've been breaking randomly for a few releases now. <rekado>so… is there an upstream response to this? <efraim>no idea, I just saw that 332 wasn't working and 343 is what arch chose and seemed to work <guix-vits>PKGBUILD's; idk which results the maintainers got from that on 343 . <efraim>we run outs with -j1 and with term unset but with TZDIR set <nckx>Hm, it just built (manually) on berlin. <nckx>I know only that building on btrfs makes it worse. <nckx>Maybe I'm just unlucky then. <guix-vits>nckx: "manually" is with guix or "make ..."? <nckx>guix-vits: Sorry, I meant ‘by manually running guix build’ vs. waiting for Cuirass. <nckx>So at least users will now get a substitute. <guix-vits>nckx: not enough, sudoedit will search for vi... <NieDzejkob>Is it a bad idea to make guix system init import (shepherd comm)? <NieDzejkob>I want to warn if the user skipped the instruction to start cow-store <nckx>Don't assume the Shepherd is running and has some arbitrary (optional) service. <mfg>I'm having problems qith spice+qemu+usbredir. I always get insufficient permission errors when i try to redirect a usb device to my guest. <mfg>Google suggests i need to add a rule to /etc/polkit-q/localauthority/50-local.d/file.pkla, but since this is a read-only filesystem, i think it has to be somewhere in my system config, but where? <wingo>mfg: just a bit of context, iirc the way this works is that polkit defines a service, which is part of your OS definition <wingo>and then other services can extend polkit with additional rules <wingo>when guix creates the /etc files for polkit, it will pull together all of the extensions when populating polkit's config dirs <mfg>wingo: yes i use guixsd. Okay then i will look on how to add rules there :) thank you. <wingo>so at this point you need to identify which service would be responsible for defining this rule <wingo>and if it's not doing it, you need to make it do so :) often packages are built in such a way that they will install files like this <wingo>but to get them into /etc they may need to be wired up as services <wingo>like building usbredir might put a pkla file in /gnu/store/usbredir-xxxxx/etc/polkit-q/... <wingo>and you just need to get that package to participate in the polkit extension <wingo>(i don't know anything about usbredir obviously :) <wingo>that's the proper solution, anyway -- the one that we should support upstream :) <wingo>if you are in a pinch it's also possible to define individual files in your os config. can be a bit tricky though as to whether defining a file deep in /etc is actually picked up by the service or not <wingo>like the service could just have some kind of courtesy link from /etc to somewhere in the store, but the path that the service hard-codes is directly to the store. probably would be a bug though if that were the case <mfg>Thank you for the insight :) <guix-vits>wingo: pitch.scm: (take-etc-snapshot-am-gonna-put-my-file-there-by-hand-service "sure") <apteryx>any idea why (current-filename) might cause the error: 'unknown location: missing file name' to be output when doing 'guix build -f my-package-def.scm' <guix-vits>apteryx: where is the (current-filename ...) is defined? <wingo>apteryx: that sounds weird to me, i can't think of why that would be <wingo>is it an error in the daemon? <wingo>perhaps there is some code being streamed over a socket or something that doesn't have a name <apteryx>wingo: I'll try a minimal example which doesn't interact with the daemon just to be sure <dftxbs3e>GNU Emacs has so many transitive dependencies, it's crazy <apteryx>wingo: I think there must be another error and the true message is masked by this as a side-effect <apteryx>wingo: indeed: (source (local-file ))... I'll make myself a coffee :-) <drainful>I would like to modify the emacs package so that an xdg .desktop file is produced for emacsclient so that emacsclient can be used as a default for xdg-open, but I don't see how the emacs.desktop file is created in the first place <guix-vits>drainful: In source targalls i's looked at (at least for endless-sky) desktop files are pre-created. Better add your hand-crafted one in ~/.local/applications <guix-vits>see skeletons, possible the .local/applications/emacs.desktop can be added there to be added to every newly created user ~/ <guix-vits>wingo: (and=> (syntax-source "") (lambda (s) (assq-ref s 'filename))) ;; not yet understand why "syntax-source" needs a parameter <drainful>I didn't know about skeletons, I've just been using gnu stow for that sort of thing. Very cool. <NieDzejkob>nckx: The problem is that a reasonable minimum for small partitions also lets through ramfs for common amounts of RAM <NieDzejkob>the idea is to warn if filesystem(/gnu/store) == overlayfs && cow-store exists && cow-store not started <guix-vits>NieDzejkob: "Don't assume the Shepherd is running and has some arbitrary (optional) service." ? <guix-vits>NieDzejkob: what bad will happens if there is enough RAM? Aren't `guix system init` will anyway install everything to /mnt or elsewhere? <DamienCassou>is there a way to have lsb_release in Guix System? The application I'm trying to install complains that this is missing <bavier`>DamienCassou: your system configuration could generate it <NieDzejkob>If /etc/lsb_release, I'd consider modifying the package sources to bypass it <bavier`>sorry, yeah, I was thinking of /etc/os-release <DamienCassou>I'm talking about the command. The application is trying to executen it <DamienCassou>unfortunately, I'm talking about a closed-source flatpak application. I would like not to install it but my company requires it <mbakke>rekado: you around? Berlin is not building anything atm, see guix-sysadmin@. <DamienCassou>thank you efraim. What do you do with it? Do you place it in /etc? How? <DamienCassou>efraim: why did you add this service? Any package needed it? <efraim>I did it for fun. Or someone else needed it for something. But probably for fun <rekado>DamienCassou: FWIW we have an emacs slack client. <rekado>mbakke: I was about to go out, but I can take a look. <rekado>I had a “guix gc” loop running to free some space. <rekado>we have only 1.4TB free at this point. <DamienCassou>rekado: I have tried using it for some time, but I couldn't really use it on a daily basis IIRC. I will try again if everything else fails <rekado>mbakke: the database may have been corrupted when we ran out of space. <mbakke>rekado: I can confirm that builds are working again with the loop gone. <rekado>it would be good if GC would prefer big items when cleaning up. <rekado>I’m currently vacuuming the cuirass db. <nckx>rekado: Bioconductor release quesh. Can packages like r-txdb-mmusculus-ucsc-mm10-knowngene be upgraded when their source vanishes (as is the case)? <DamienCassou>efraim: I see you are using both khard and emacs. I have created khardel and vdirel, 2 emacs packages to help me manage my contacts <efraim>I don't actually use emacs. I was planning on learning so I could use emacs-debbugs and emacs-guix but I never got around to it <mehlon>I stopped using emacs because it tries to mess with how I write tabs and turns them into spaces <NieDzejkob>O_o that sounds like something trivially configurable <mehlon>well yes, but there are way too many small problems that are trivially configurable with emacs <mehlon>I just use MATE's Pluma for most purposes now <NieDzejkob>This example is just a matter of taste, but I can't think of many others <Blackbeard>Too many small problems with emacs? I rarely have them. Funny how two people can experience the same thing in a completely different way <Blackbeard>If I anything I have way less problems with Emacs as my OS :) than any other thing <mehlon>well the whole 'OS' thing is kind of the problem.. I just want a text editor that sorta does what I need out of the box and I don't have to keep configuring it, I already have an OS for that! <mehlon>for instance, it starts up just a little too slow, the file selection is just a little weird and clunky. text does not quite behave like text, but rather like a terminal from before I was born, CUA controls are not on by default, etc, etc. <elais>does anyone work with direnv and guix together? <janneke>i'm using M-x guix-set-emacs-environment a lot <janneke>been wondering about direnv like behaviour tied to that; but i'm not sure if that will work for me <elais>so you just create the environment, name it, and then switch to it in the buffer you've opened? <janneke>yes, or actually i use named profiles for most of my regular work ~/.config/guix/foo <janneke>note that this switches all of emacs... <elais>if emacs is using packages not imported from guix does this break any of that? <rekado>nckx: yes, all bioconductor packages can be upgraded <rekado>bioconductor does not have an archive of previous releases (unlike CRAN) <rekado>I always try to upgrade all bioconductor and cran packages, but I suppose the updater doesn’t work for annotation/experiment packages. <nckx>No prob. Just didn't want to ruin anybody's research if the convention is to cite just ‘bioconductor release x.foo’ (or whatever, IDK 🤷) <apteryx>I'm attemting to use this in a guix.scm file: (zero? (system "git describe --tags --exact-match &>/dev/null")) <apteryx>and can't seem to mute the output of git describe, it always complains about: git: 'git describe --tags --abbrev=0' is not a git command. See 'git --help'. <apteryx>the code is run as part as 'guix build -f guix.scm' <dftxbs3e>efraim, "./pre-inst-env guix package -A" returns nothing at all on powerpc64-linux interestingly.. <efraim>dftxbs3e: add it to %supported-systems in (guix packages) <dftxbs3e>also, I'm really looking forward GNU Hurd's success because Linux is a real PITA when it comes to sharing rights to privileged operations to multiple people. It feels like a huge bottleneck and risk to either rely on sudo for massively error-prone policies or give everyone who administers root <dftxbs3e>Monolithic kernels in general, I suppose <dftxbs3e>A Microkernel or Object Capabilities kernel feels missing <janneke>my hurd resurrection efforts currenly fail at python-boot0 <janneke>just dug up some glibc patches and building another round of bootstrap-tarballs ***jonsger1 is now known as jonsger
<evhan>Have I maybe built guix wrong somehow? <bavier`>evhan: your gcrypt has guile bindings installed? *bavier` had though 'configure' checks for this <evhan>IDK... I've used `guix environment guix' to set up build dependencies, and ./configure ran OK. <NieDzejkob>Use ./pre-inst-env while you're still in the `guix environment guix' <evhan>NieDzejkob: Aha, thank you. Now I'm hitting a permissions issue running scripts/guix. <evhan>Which I guess has to do with --build-users-group. <evhan>That's with the daemon running as `sudo -E ./pre-inst-env ./guix-daemon --build-users-group=guixbuild' and running the build command `./pre-inst-env guix build hello', with my user is in the guixbuild group. I feel like I'm missing something setup-wise... <NieDzejkob>huh, why are you running the daemon manually? Are you planning to hack on the daemon? <evhan>If I don't run the daemon `guix build' just tells me it can't connect to a listening socket. <NieDzejkob>are you running on a foreign distro or guix system? <NieDzejkob>the daemon should be up and running before you mess with local git checkouts <evhan>I do, and the daemon is up and running, but uses a different prefix than the build in the local checkout. <evhan>So uses a different socket path as well. <evhan>I can rebuild it to use the same prefix if that's what I'm supposed to do? <mbakke>evhan: you need to run './configure --localstatedir=/var' in your Guix checkout to make './pre-inst-env' find the daemon socket <mbakke>also, there is no need to run the daemon from the checkout unless you want to hack on the daemon itself, it would be good to de-emphasize the daemon stuff in the manual... <samplet>mbakke: I just saw your message. I think I know what the issue is with Gash, and I’m looking into it now. <jeko>Do you know why I can't call guix after $ guix environment --pure guix ? <jeko>I get : Command 'guix' is available in '/usr/local/bin/guix' <jeko>The command could not be located because '/usr/local/bin' is not included in the PATH environment variable. <evhan>I saw "Then, run ./configure as usual." and did, but missed the flag. <jeko>I installed guix using the recommanded install script <evhan>(Which, you know, mea culpa and all that.) <mbakke>jeko: guix environment drops you in a shell with all _dependencies_ of the packages specified, and resets all environment variables <mbakke>jeko: 'guix environment guix' is really only useful if you want to build Guix from source <mbakke>evhan: I know, that section of the manual has tripped many would-be contributors.... improvements very welcome :/ <jeko>mbakke: hmm ok! so I don't need it to hack on some package ? <mbakke>jeko: if you want to hack on a package from Guix, you need it to build your Guix fork <jeko>mbakke: yep I built guix in the pure env. then I though I had to use the pure env anytime I want to do stuff on guix. but it may be too much *evhan was also unclear on that. <jeko>mbakke: actually I "guix environment --pure guix" then "./pre-inst-env guix build ....." am I ... bothering myself? haha <mbakke>jeko: no that sounds exactly right. Once you have the ./pre-inst-env, you no longer need 'guix environment guix' though. <jeko>mbakke: ohhhh I get it! thank you <mbakke>jeko: glad to help, good luck! :-) <jeko>mbakke: now I can sleep haha see you! <dftxbs3e>bavier`, hey! if you are bavier1, I fixed the issue by modifying glibc's interpreter path and use /lib/ld64.so instead of /lib64/ld64.so <dftxbs3e>that was the reason why it couldnt figure out the dependencies <evhan>mbakke: Recompiling with the right localstatedir worked, thank you for your help. <dftxbs3e>does GNU Guix 1.0.1 get packages from any other branch than version-1.0.1 ? <drakonis>actually, guix runs on a rolling release model <drakonis>if you do a pull it'll update to whatever's in master <dftxbs3e>I've been so obsessed with GNU Guix that I even forget to sleep at times :S <samplet>mbakke: It should be “(package-version gash)” and “(package-version gash-utils)”. Shall I push the fix?