IRC channel logs


back to list of logs

<lfam>michel_slm: What's the model number of the CPU? You could use `lscpu`
<lfam>There is over a decade of i7 processors
<lfam>michel_slm: I would estimate 10 minutes to an hour, depending on your hardware
<michel_slm>lfam: ah, I left that laptop compiling in another room, I can check after this
<michel_slm>it's likely the i7-8550U and a common issue with my laptop (Dell XPS 13) is the CPU would get thermal throttled. probably won't be a problem once this is being built on Fedora's official build servers
<michel_slm>once this is built and working I just need to get an exemption for the Guix store not being FHS-compliant :p
<lfam>Ah, too bad such a new and fast CPU is integrated without proper thermal management
<michel_slm>lfam: on an ultrabook, I'm not sure that's possible. I bet it's just not meant for anything but bursty CPU usage
<lfam>I agree, what can you do in that tiny space
<lfam>Well, compiling all of Guix from scratch is not required for daily use :)
<michel_slm>lfam: yep. provided the Fedora packaging committee give me an exemption for /gnu/store! if I'm forced to put it in /var then users will have to compile Guix pacakges from scratch :p
<michel_slm> * lfam: yep. provided the Fedora packaging committee give me an exemption for /gnu/store! if I'm forced to put it in /var then users will have to compile Guix packages from scratch :p
<lfam>You might look into what is going on with Debian. vagrantc is working on that
<michel_slm>but yes, I remember in the horrible days of Pentium 4, Dell once put a desktop P4 in a laptop. won't run at full speed unless you attach the power brick
<michel_slm>lfam: yeah, I started doing this right after cwebber noted that it landed in Debian.
<michel_slm>a Fedora contributor also has guix (a slightly older version) in their personal COPR ("PPA") repository, trying to see if they want to collaborate too
<michel_slm>lfam: what're they working on exactly? being able to move the store without invalidating packages?
<lfam>They are working on making an official Debian package. I assume they have similar issues regarding file locations
<michel_slm>lfam: that package is in now.
<michel_slm>but the store is not listed in the list of files
<lfam>In my experience, the debian web infrastructure can be out of sync with itself
<michel_slm>(Debian might be looser than Fedora in this regard. in Fedora, config and state paths all have to be declared as belonging to the package, but on Debian I sometimes have problems figuring out which package owns a given config since the config is generated during the installation)
<jgibbons[m]>So herd is unusable outside of Guix?
<jgibbons[m]>I was reading an earlier conversation.
<jgibbons[m]>If herd could be used as an init system outside guix, it would be possible to transform arch into guix, part by part.
<jgibbons[m]>Nevermind. Element/matrix doesn't autoscroll.
<lfam>It's not unusual, but it's far from a drop-in replacement for another distro's service management
<lfam>I mean, it's not unusable
<iyzsong-w>shepherd as a second 'init' (not as pid 1) should be fine and easy.
<PotentialUser-12>Hi, I'm trying to reconfigure my system, but it keeps failing with "guix system: error: getting attributes of path '/gnu/store/{HASH}-passwd': No such file or directory", I've tried gc, pull, and updating packages but can't seem to fix it
<PotentialUser-12>Guix is correct that the location does not exist
<kozo[m]>PotentialUser-12: What's the whole command you are running?
<PotentialUser-12>sudo guix system reconfigure config.scm
<PotentialUser-12>I've also attempted sudo guix system --fallback -k reconfigure config.scm, but I'm not really sure that's correct. it didn't change anything regardless.
<iyzsong-w>I usually run with 'sudo -E guix ...', but I guess that's not the problem here.
<iyzsong-w>and before sudo, make sure 'cd' to an existed directory. but I guess that's not the issue here too...
<PotentialUser-12>yeah just tried -E, didn't change. the command is running, it's grafting, then it fails saying it (correctly) can't find the directory
<vagrantc>PotentialUser-12: might also want to share if you have any surprises in your config.scm, given that without that there's really no way to know what your command failed
<vagrantc>e.g. through or something
<PotentialUser-12>probably useful to share what it was doing right before it failed, applying grafts to mate-1.24.1.drv
***iyzsong-- is now known as iyzsong-w
<vagrantc>good luck!
*vagrantc waves
<PotentialUser-12>sure I'll paste it, give me a moment
<apteryx>sneek: later tell civodul: got it, NIX_STORE_DIR is when wanting to affect teh store directory from outside of the daemon; the daemon sets NIX_STORE in the builder environment internally. So in (guix build utils), it's good to check for both to detect %store-directory.
<PotentialUser-12>ok here it is, I've "redacted" some variables.
<PotentialUser-12>I don't really know much about guix, but I think it's an issue with my gnu store moreso than my config, but I could be wrong.
<lfam>PotentialUser-12: Did you try `guix gc --verify=contents`?
<PotentialUser-12>hey look at that :) 'path hash-passwd disappeared, removing from database'
<PotentialUser-12>im sure this will fix it
<PotentialUser-12>great, that fixed it thanks
<PotentialUser-85>I'm having some issues understanding guile, how do I modify '(remove (lambda (service)
<PotentialUser-85> (eq? (service-kind service) avahi-service-type))
<PotentialUser-85> %desktop-services)
<PotentialUser-85>I'm having some issues understanding guile, how do I correctly modify this:
<PotentialUser-85>(remove (lambda (service) (eq? (service-kind service) avahi-service-type)) %desktop-services)
<PotentialUser-85>to remove multiple services from %desktop-services?
<PotentialUser-85>I'm having some issues understanding guile, how do I correctly modify this: '(remove (lambda (service) (eq? (service-kind service) avahi-service-type)) %desktop-services)' to remove multiple services from %desktop-services?
<PotentialUser-85>I'm having some issues understanding guile, how do I correctly modify this: '(remove (lambda (service) (eq? (service-kind service) avahi-service-type)) %desktop-services)' to remove multiple services from %desktop-services?
<PotentialUser-85>woops :x
<theruran>How come when I run gcc -L$(pkg-config --libs uuid) -luuid I get a dynamically-linked binary that says is not found?
<iyzsong-w>PotentialUser-85: the first param for 'remove' is a pred procedure, for multiple services (eg: to remove A, B, and C), you can use '(lambda (service) (member service '(A B C)))'
<theruran>err well forget the -L and -luuid there. It's got -L/gnu/store/... and -luuid right in the gcc invocation I swear
<theruran>pkg-config works but ld doesn't?
<theruran>trying it with guix environment util-linux and ld says it can't find -luuid
<davidl>Hi, I am trying to provide a mixed-text-file object to the mysql configuration in the "extra-content" field, which is evaluated strangely on a guix system reconfigure: guix system: error: invalid character `
<davidl>' in name `
<davidl># Galera Provider Configuration
<davidl>the "-builder" part is where I have a package object.
<davidl>I expected it to evaluate to a path in the store.
<davidl>Can a mixed-text-file contain other mixed-text-file objects is perhaps the question?
<cbaines>davidl, probably not is the answer
<mdevos>does someone else also have trouble upgrading libreoffice?
<mdevos>guix package -u is hanging at 52.6% completion (downloading from
<cbaines>davidl, you might be able to pass something like #~(string-append "..." #$foo "...") in
<davidl>cbaines: hmm, unfortunate. Thanks, Ill try that. I did try something similar first, but Ill try your example too.
<davidl>cbaines: complains that string-append doesn't want g-expressions
<cbaines>davidl, can you share the relevant bit of code?
<davidl>cbaines: the galera package is not in guix yet
<cbaines>davidl, right, one way of viewing G-expressions is code staging, so you're deferring execution of code until it's excuted "on the build side" by the daemon
<cbaines>I'd make the whole expression you're passing in to extra-content a G-expression, so starting with #~(string-append
<cbaines>then where you've got #~(string-append #$galera ""), you should just put #$galera
<davidl>cbaines: yeah thats what I had tried first which failed as well.
<cbaines>davidl, can you share that attempt, as well as the error message?
<davidl>cbaines: yes
<davidl>cbaines: now that worked, so I must have made some syntax mistake before.
<davidl>cbaines: thank you!
<cbaines>davidl, you're welcome :)
***apteryx_ is now known as apteryx
<nij>Hello! What's recommended (for newbies) when it comes to disk partition? I used to give 30GB to `/` for my arch machine. But the situation is different here on Guix, I'd imagine, as all packages got stored there.
<iyzsong-w>nij: I just use the whole disk as a single / partition...
<nij>iyzsong-w: even no swap?
<nij>And yeah, that's what I plan to do. I'm looking for any reason not to.. though :S
<leoprikler>I personally separated /boot, because that's what I'm used to coming from Gentoo, plus swap of course.
<efraim>I normally use a swap file, easier to adjust later
<leoprikler>Luckily for me, Guix /boot fits more than 3 system generations :)
<stikonas>Gentoo works perfectly find with non-separated boot...
<stikonas>I only separated /boot/efi which you have to
<stikonas>(and swap)
<nij>leoprikler: any advantages to separate /boot?
<leoprikler>None to speak of. When I installed Gentoo, it would only boot that way, though.
<stikonas>leoprikler: that's strange... Maybe it was before grub supported your rootfs...
<stikonas>I think that's the only advantage of separate /boot. You can use other file system when bootloader can't read rootfs
<stikonas>which might still happen even today in some cases....
<leoprikler>ah yes, those darn ext4 partitions
<nij>speaking of partitions
<nij>Which FSs are recommended for Guix?
<abcdw>nij: I use btrfs with subvolumes, works without any issues. Have full disk encryption, except /boot/efi.
<allana`>Hi guix! Anyone here have experience running guix in a Docker container? Is it even possible? This is a hard thing to search for with the given keywords of "Docker" and "guix". I have tried to do something clever, making a container with guix using "guix pack -f docker -S /bin=bin guix".
<allana`>abcdw: Thanks!
***allana` is now known as allana
<raghavgururajan>Hello Guix!
<raghavgururajan>nij: My partition scheme ->
<avalenn>abcdw: why is `guix pack` approach not sufficient for metacall?
<raghavgururajan>nij: Partition scheme is something I give a lot of thought into. Let me know if you need info or help.
<raghavgururajan>leoprikler: Are you dual-booting Guix and Gentoo?
<leoprikler>Nah, that's just what I'm used to coming from Gentoo.
<leoprikler>It's more of a habit than anything else.
<leoprikler>Same with my using MBR instead of GPT.
<raghavgururajan>I see.
<raghavgururajan>Tobias use to talk about Gentoo.
<allana>avalenn: I was hoping to use "guix pack -f docker guix" to build a docker image capable of running guix. Would be curious if you or anyone else has been able to
<raghavgururajan>I should take a survey of current guix system users regarding which distro they come from.
<abcdw>avalenn: better ask @viferga about that) I'm not related to metacall anyhow, but I remember he did something related to guix pack for metacall.
<avalenn>I did not try to exec guix from an image built with `guix pack` so I have no idea if this is possible or not.
<avalenn>But if it is not, I think we should improve Guix to make it possible.
<allana>avalenn: I was able to create the docker image and load it, start the daemon. But then running "guix pull" would not work because of an error that seemed obscure to me.
<mdevos>allana: that's expected, I think. Containers can't modify the store by default, but maybe there's a way around that
<allana>I'm trying ot have the store on the container's filesystem
<mdevos>posting the error message (e.g. on would be helpful
<allana>Ah, ok. here is a paste where I try to run "guix pull" from a docker container running the guix daemon:
<allana>The container was naively built using "guix pack -f docker -S /bin=bin guix". The resulting docker image was loaded and then run like this: "docker run -it guix guix-daemon"
<avalenn>Could you paste the build log at the end (after bunzipping it) ?
<allana>avalenn: okay, mind if I just create a new paste
<avalenn>Yep! New paste.
<allana>avalenn: oops, sorry I didn't include bzcat in the container image, so It's not going to be easy for me to extract that... hmmm
<avalenn>docker cp
<allana>avalenn: guix perform-download: error: refusing to run with elevated privileges (UID 0)
<allana>it was a one-liner
<avalenn>I will try to understand this one. I just managed to reproduce it here.
<apteryx>allana: probably need to run docker with --privileges or whatever it's called
<civodul>allana: also, the problem is that "guix pack guix" does not create the build user accounts as explained at
<sneek>civodul, you have 1 message!
<sneek>civodul, apteryx says: got it, NIX_STORE_DIR is when wanting to affect teh store directory from outside of the daemon; the daemon sets NIX_STORE in the builder environment internally. So in (guix build utils), it's good to check for both to detect %store-directory.
<civodul>apteryx: (guix build utils) was initially meant for the build environment, which is why it checks for NIX_STORE only
<civodul>i would adjust unit tests to setenv NIX_STORE, if needed
<apteryx>do you mean sed 's/NIX_STORE_DIR/NIX_STORE/' -i test-env.ini ?
<apteryx>I think this whole thing needs to be refactored so that only GUIX_STORE exists
<apteryx>I meant build-aux/
<apteryx>The daemon currently honors both, so to me it makes sense that (guix build utils) honors both as well, since this module is no longer used only on the builder side of things.
<apteryx>when we refactor it to use GUIX_STORE we can fix all occurences of the legacy vars.
***dddddd_ is now known as dddddd
<civodul>apteryx: NIX_STORE (the build-side one) is set in stone, for better or worse
***nij is now known as Guest26569
<civodul>or we could imagine a multi-year transition, but there's little to be gained anyway
<civodul>NIX_STORE_DIR could be renamed, though
<civodul>when i wrote "set in stone", i mean that we'll want the daemon to be able to build old derivations, which expect $NIX_STORE to be set
***Daniel[15 is now known as vertigo_38[m]
<apteryx>civodul: I see, thanks for explaining. We can add to it, though, leaving the old one set in the daemon if that's required for backward compatibility (e.g., add GUIX_STORE and use this to derive %store-directory)
<civodul>apteryx: yes, that's what i meant by multi-year compatibility: in the daemon, set GUIX_STORE in addition to NIX_STORE
<civodul>but it means that at some point we'd drop NIX_STORE, which would break older derivations
<civodul>that's why i think there's little to be gained
<civodul>(plus it's just on the build side so it's mostly invisible)
<lemes>hello, guix :-)
<sneek>Welcome back lemes, you have 1 message!
<sneek>lemes, ryanprior says: I saw your blog post, great idea & glad you're working on it! What do you think about having a `guix versions` command that shows past package versions & what commits they're reachable by?
<lemes>I'm trying to push a few commits to the wip-guix-log branch, this is my first time doing it, and I'm getting the following error: How do I solve this?
<civodul>hi lemes!
<civodul>this is coming from the pre-push hook
<civodul>probably you need to install guile-git and guile in your profile
<civodul>(guile-git is what provides the (git) module that's mentioned in the error message)
<civodul>so hopefully "guix install guile guile-git" will solve it
*civodul has to go afk for a bit
<lemes>oh, I see. let me try it. thx
<apteryx>civodul: I thought about one possibility with GUIX_PYTHONPATH; it could be possible to filter per-version site-packages entries at runtime in the, which would allow having a single GUIX_PYTHONPATH environment variable (that would be version agnostic). I find that a bit less clean but on the otherhand it's easier to deal with.
<lemes>civodul, it worked! thank you
<zimoun>lemes: Cool!
<leoprikler>Well, perhaps we could make it one PYTHONPATH per major version instead of major+minor pair, like with GTK
<apteryx>leoprikler: I think it's nice to be able to run safely Python 3.X versions in the same profile, for easy testing for example
<shcv>if I'm working on a package or custom linux kernel version from git, how do I get the necessary sha256 base32 sum?
<leoprikler>in that case pythonpathX_Y it is
<shcv>I assume it's the sum for the cloned git repo, but it's not a single file...
<apteryx>leoprikler: that's how it's implemented on the cu/farewell-to-pythonpath branch currently, but another idea I had was that we could simply use GUIX_PYTHONPATH at the expense of some extra runtime filtering
<leoprikler>yeah, but why not directly use pythonpath if you're going to filter anyway?
<apteryx>that way the environment variable name is static and doesn't need a dedicated procedure; it makes it easier to wrap programs taht don't use the python-build-system (by lifting the requirement to add #:imported-modules and #:modules argument just to get that 'guix-pythonpath' procedure)
<apteryx>leoprikler: because PYTHONPATH is special and Python puts it at the beginning of its PATH, doesn't allow you to process it before doing so.
<apteryx>GUIX_PYTHONPATH is not known to Python, that's why we can do whatever we want with it in a file.
<roptat>hi guix!
<shcv>so how do I get the sha256 base32 to go with a git-fetch source?
<apteryx>git clone X; cd x-sources; guix hash -rx .
<apteryx>don't forget to 'git checkout $release-tag'
<shcv>and if I'm not using a release tag?
<apteryx>you can checkout the exact commit you want
<apteryx>'git checkout commit-id'
<apteryx>usually we try to package release tags if they are present
<shcv>thanks for the help; I finally found the line in the cookbook that mentioned how to get the hash >.< (
<apteryx>shcv: eh, no worries :-)
<apteryx>anyone knows how to fix this kind of error: ';;; In procedure load-thunk-from-memory: incompatible bytecode version'
<apteryx>in one of my checkout
<apteryx>it's a warning, more accurately. The line before that reads: ';;; WARNING: loading compiled file $HOME/src/guix/gnu/packages/kde-plasma.go failed:'
<apteryx>it happens for all files
<apteryx>ah, perhaps I need to rerun configure
<rekado>Guile version mismatch
<rekado>Guix uses Guile 3.0.5 which produces bytecode that is incompatible with that produced by 3.0.2.
<apteryx>it right, it's captured at configure time, so easy to forget about it :-)
<rekado>‘make clean-go’ deletes your old compiled Guile modules
<apteryx>yep, I had run that
<apteryx>I had run 'make clean-go', rebuild, and then had the same problem. This in a 'guix environment guix --pure'
<apteryx>I've now reattempting the same *after* having having re-run ./configure --localstatedir=/var
<apteryx>ah, it was not enough still... so the ./ script must be the one fixing GUILE
<apteryx>err, ./bootstrap
<apteryx>that's crazy, I'm still hitting the same problem
*apteryx runs 'make distclean'
<apteryx>that seems to have fixed it
<apteryx>rekado: thanks for the help
<apteryx>was there a way around not using 'origin' as a remote name for the pre-push Git hook?
<apteryx>with the remote named 'upstream', I get: guix git: error: Git error: cannot locate remote-tracking branch 'origin/keyring'
<civodul>apteryx: yes, see the --keyring option of "guix git authenticate"
<zimoun>“guix repl” appends via ’user-config’ the file $HOME/.guile. I find annoying because I would like to add Guix related config which fails with regular Guile repl. Does it make sense to have let say ~/.config/guix/repl.scm and fallback or append then to ~/.guile?
***daniel[m]4 is now known as daniel[m6
<civodul>zimoun: so "guix repl" would load these two files at startup, right?
<civodul>why not
<civodul>you're pretty demanding in terms of customization :-)
<zimoun>yes, 2 files loaded at startup.
<zimoun>Customizations because once I have watched an interesting talk at FOSDEM: «Guix the Emacs of distro». Do you know? ;-)
<raghavgururajan>Woah! In guix system, there use to be symlinks for initrd.img and vmlinuz, under "/". But recently its been missing. Were they removed purposely?
<raghavgururajan>Or am I confusing them with trisquel.
*raghavgururajan feeling dizzy
<jonsger>raghavgururajan: maybe under /boot, but definitv not directly under /
<apteryx>civodul: thanks; I saw that but I wasn't sure how to apply it to the pre-push hook
<raghavgururajan>jonsger: Ah yes, I probably seen them under "/boot". But recently I don't see them.
<apteryx>the nixpkg git repository is more than one gigabyte to download (!)
<apteryx>I wonder what they keep in there.
<apteryx>1.30 GiB to de exact
<drakonis>apteryx: there's a lot of commits
<drakonis>266283 commits as of this typing
<runejuhl>Good evening all. I'd like to amend locale-definition to add en_DK -- how would I go about doing that? I can find instructions for GuixSD, but I'm currently using it on top of Ubuntu...
<joshuaBPMan>runejuhl you are using say Guix's Libreoffice on a Ubuntu distribution, but you want to write in en_DK?   hmmm.
<joshuaBPMan>I'm not certain how to go about doing that.  I hear Denmark is a super cool country though....
<joshuaBPMan>I think in guix land they provide the locale via a shepherd service.
<runejuhl>joshuaBPMan: LibreOffice? No, just proper time formats instead of the terrible American C default :) I use en_US for everything but the time format
<cbaines>glibc-locales includes en_DK, have you got that package installed runejuhl
<runejuhl>joshuaBPMan: Denmark is not a bad place, no. I do wish it had both proper summers and winters -- it feels like it's been autumn all winter. Cloudy, rainy. Ugh!
<runejuhl>cbaines: yes, have tried installing both glibc-locales and glibc-utf8-locales
<runejuhl>...damn. Figured it out. It's been bugging me forever, and of course it's not until now that I realise that LC_TIME was set to en_DK.UTF-8. Changing to just LC_TIME=en_DK works
<runejuhl>Thank you for being my rubber ducks :)
<cbaines>cool, glad you got it working
<cbaines>I'd expect en_DK.UTF-8 to work as well, but I don't have a great understanding of locales
<joshuaBPMan>cbaines  Who does?
<runejuhl>Yes, not sure why one would work and not the other -- but it works now, so *shrug* :)
<argylelabcoat>When hooking guix packages up to shepherd services, I've found guile errors in shepherd configs difficult to debug. Is there a way to debug guix shepherd service definitions nicely? a goop error will not necessarily provide enough information to easily glean what file/line number is causing the trouble
<joshuaBPMan>argylelabcoat  I can kind of agree to that.  I'm writing a sway service right now.  My current error is wrong type to apply #(unspecified).  With no line number.
<cbaines>argylelabcoat, yes, it can be difficult. What package are you trying to hook up to which service?
<joshuaBPMan>Though I know that you get am #(unspecified) error when (display `(list 1 ,(if #f #f)))
<argylelabcoat>I'd honestly like a way to get access to the guile debugger and get a backtrace
<argylelabcoat>right now? some custom services and mosquitto
<argylelabcoat>I'm working for an industrial automation company building an iiot product
<joshuaBPMan>I actually wrote a blog post about error messages in guile the other day:
<joshuaBPMan>I'm guessing that debugging macros in any language is REALLY hard for the compiler to report.
<argylelabcoat>I've worked out the issues I was having, but now I'd like a way to deploy not just a system image/container, but a application bundle that utilizes shepherd
<joshuaBPMan>argylelabcoat  Does this section in the guile manual help?
<roptat>joshuaBPMan, in your case, you're getting unspecified because the if statement is missing an else case ;)
<argylelabcoat>I've looked at the guile manual, but I couldn't figure out how to launch shepherd with guile in a way that didn't lose a lot of guix context
<joshuaBPMan>roptat  Yup.  :)   I was giving an example of why one would get an unspecified error.  Nice eye roptat!
<argylelabcoat>so what I'm mostly asking is how to improve my tooling and process so I can be more effective at using guix
<argylelabcoat>and shepherd :)
<cbaines>With the way Guix constructs the Guile files for Shepherd, everything is on one line, so I can tell you conclusively that all your errors are on line 1
<argylelabcoat>Though if you have any tips for taking shepherd out of a system container and making an app bundle that launches with shepherd, I'd be excited to know how
<joshuaBPMan>argylelabcoat   That's some videos of my building a sway service, but I'm pretty much where you are now.  I have a service definition, but I'm not certain why the reconfigure is working.   :)
<cbaines>argylelabcoat, what command are you running when you're seeing the error?
<joshuaBPMan>My current strategy is to put the service definition next to my config.   Then in my service definition, I have a (add-to-guile-load-path (current-directory) or something.  Then (use-modules (sway-service)    ...I feel like I'm probably rambling, and maybe not providing much help....
<argylelabcoat>well, what I have is a copy of the basic_system.scm system defninition that comes in the guix repo, then when I was having the issue (It's gone, I worked it out yesterday bye re-writing the entire service from scratch), It would be an argument mismatch that I was able to deduce was the (service mosquitto-service-type) in my services list in my basic_system.scm
<argylelabcoat>The command I was using is: ./pre-inst-env guix system container rta/systems/basic_system.scm -r runcontainer && sudo ./runcontainer && rm -rf runcontainer
<cbaines>OK, and was the error occuring in the guix system container command, or the sudo ./runcontainer bit?
<argylelabcoat>in the system container command
<argylelabcoat>I assume that where it went wrong was involving my (default-value (mosquitto-configuration)) in the mosquitto-service-type
<argylelabcoat>like I said, I just rewrote the whole thing staring really hard at the rsync service def in the guix repo
<argylelabcoat>the second time around, which looked the same to me as the first time, worked
<argylelabcoat>so it had to be some strange minor difference in the service definition
<argylelabcoat>what I'd like is a procedure to troubleshoot this better than going nuclear next time
<cbaines>right, constructing the container should be OK to debug, although errors that occur when building the relevant derivations may be a little tricky
<argylelabcoat>yeah, I'm getting to the point where I'll be rolling guix out to a software team in-house
<cbaines>unfortunately I've not got any magic process to suggest, I think there's a way to go in Guix itself to do more checking of "user" input, so that exceptions don't occur deep in Guix itself
***daniel[m6 is now known as vertigo_38
<roptat>if the issue is during the build of the container (and not while running it), I'd try to run things in a guix repl, step by step
<argylelabcoat>I see
<roptat>see where it fails, to narrow it down
<argylelabcoat>Is there a way to do that better than firing up a guix repl and copying+pasting ?
<roptat>not really
<roptat>I'd open a guix repl, load the service module, build a service config, then a service definition
<roptat>so the only thing I'm copy-pasting is from the os definition, not from the service module
<argylelabcoat>that's at least something
<roptat>well, if I get "unspecified" when loading the module, I'd probably copy-paste it bit by bit ^^'
<joshuaBPMan>Sounds like it would be nice to have a shepherd service for reading systemd service files.  And the shepherd probably needs some love.
<argylelabcoat>Is there a smarter way to build & test shepherd services than in a container?
<roptat>not really, that's what we use for our service tests
<roptat>we call that a "marionette"
<argylelabcoat>like, I'd really wish I could be in a guix environment, and simply shepherd -c init.scm
<argylelabcoat>and have the init.scm have a service def
<roptat>that would be pretty different from the situation with the Guix System though
<roptat>but I see why you would like to have that
<roptat>I'm not familiar enough with the shepherd to know how to do that though
<argylelabcoat>I can tell you that the error I get trying that, is that the shepherd is lacking knowledge of guix at that point
<argylelabcoat>and it can't resolve various packages
<argylelabcoat>is there a way I can tarball a guix container?
<argylelabcoat>I mean, the docker image is a tarball, but I'd rather not need docker
<roptat>with guix pack, you can get this kind of tarball, but I'm not sure how it will help
<cbaines>argylelabcoat, given Guix constructs shepherd configuration in the store, it's better just to work with store paths at that point, rather than with package definitions
<raghavgururajan>leoprikler: Would you like me to add the '-for-telegram-desktop' suffix for both variable-name and package-name or just the variable-name?
<argylelabcoat>roptat, separate issue, I need a way to send a testing container to the QA team
<argylelabcoat>I'd rather they not need to issue a build, just chroot and go
<roptat>not sure if you can create a tarball of a complete system
<argylelabcoat>cbaines, interesting, so I could have a init generator as a package, then use shepherd -c to run that init?
<roptat>guix pack can create a tarball for a set of packages, but it doesn't have services
<leoprikler>raghavgururajan: depends on what you're doing
<leoprikler>If you're using inline inputs, then it's best to do it in the origin file-name.
<argylelabcoat>roptat, right, but if I am on the right path with being able to build an init as a guix package, then I could perhaps
<leoprikler>If you have an actual variable, it's best to keep the package name as-is, but name the variable <package>-for-telegram-desktop.
<cbaines>argylelabcoat, for your particular application, you may be better off packaging a wrapper script, then using guix pack
<argylelabcoat>cbaines, that's where my mind is headed...
<cbaines>argylelabcoat, if you actually need the system configuration stuff, then you'll need to use a container/vm anyway
<roptat>I would build the derivation (which is not necessarily a package) that corresponds to the shepherd service. When building the container, you probably see you're building something like /gnu/store/...-shepherd-something.scm.drv
<roptat>(where something is the name of the service)
<roptat>building that derivation gives you a scheme file that can be run by the shepherd (maybe with some additional glue code)
<argylelabcoat>cbaines, as I don't have my ARMv7 kernel/uboot ported to guix yet, I am still using a Yocto image for my hardware still. So for QA, they have a Yocto booted ARM board, and I want a way to give someone with linux usage, but not dev skills, an easy way to download a build and run it while i figure out the Guix System Image for our board
<argylelabcoat>so a wrapper script sounds like a cool solution, especially if I can keep using shepherd and not have to fall back to gnu pies or something
<raghavgururajan>leoprikler: For tg-rlottie and tg-voip. I am using hidden-package.
<leoprikler>in that case just the variable names
<roptat>argylelabcoat, maybe "guix system image", I think it generates an iso of a Guix System, so you should be able to mount it and chroot in it
<argylelabcoat>There's probably a blog post or series in all of these struggles I'm having, but I mostly just want to get things working, then start submitting the patches to guix for civetweb, libpaho, etc that I had to create
<argylelabcoat>I guess I also created a mosquitto-2 package since mosquitto is a v1 in guix right now
<argylelabcoat>and that required a more up to date libwebsockets (v4)
<argylelabcoat>I created and abandoned package specs for some database servers too, I should track those down... had couchdb working for example
<argylelabcoat>and I had to switch our Angular web-ui to yarn so that I could properly vendor dependencies and allow for deterministic UI builds
<argylelabcoat>similar issue with Go Modules in guix... our go services build with Gnu Makefiles and vendored dependencies so that guix is happy with them
<argylelabcoat>have a 300 line macro that sets up the arguments for that makefile for cross-build/etc
<argylelabcoat>So, there's a lot that could maybe get documented, and posted on how to use Guix for new product development with Angular/Go/C++ with what I'm sorting out... but thanks for all the help so far
<argylelabcoat>I've got an old package spec that builds a supervisord conf script, but the lack of supervisord in guix made that a bit useless
<argylelabcoat>but if I can do something similar with shepherd, that'd be rad
<civodul>vlc fails to build on staging: vlc-qt-5.15.patch no longer applies
<lfam>civodul: Wow, I'll take a look
*lfam builds VLC without the patch
<civodul>lfam: hey! probably has to do with the merging the upgrade that was made on 'master'
<lfam>That's funny, there's already a substitute for that derivation
<lfam>Oh, maybe my Git tree needs to be rebuilt
<lfam>Yup civodul
<lfam>I think that upstream VLC made the patch unnecessary
<civodul>great, that'd be a happy end
<lfam>civodul: It should be fixed now
<pkill9>--with-patch is sweet
<pkill9>someone made a pull request for a feature I want, so I just add .patch to the url to get it in patch format and download it and build it with the patch with --with-patch and now I got it
<pkill9>i wonder if installing it to a profile will remember the patch in the store, or the file path to the patch
<pkill9>i hope the former
<joshuaBPMan>that's kind of awesome.  May I ask what the patch was?
<pkill9>it's this pull request for calcurse
<pkill9>this is the patch url
<joshuaBPMan>hmmmm.  I've never heard of that program.
<pkill9>the feature adds the ability to turn a todo item into an appointment on the currently selected day
<joshuaBPMan>sounds like a nice feature to have
<zimoun>civodul: thanks for reviewing 45983. I do not understand your ’formatted-message’ suggestion. Instead of (format #f (G_ …)) it is (formatted-message (G_ …)) that’s it?
<pkill9>yea it's nice to have astack of todo items and just press shift+p to cut them down before you've done them
<pkill9>it's nice that you can also just install the modified package
<zimoun>civodul: because I have missed that ’message’ is subject to translation. So the patch is maybe not useful since it is just cosmetic.
<civodul>pkill9: you can check ~/.guix-profile/manifest to see how 'with-patch' is "remembered"
<civodul>it's the file name as you passed it to --with-patch
<pkill9>yea i was just looking at that
<pkill9>i was wondering if it uses the store path so it doens't need to remember
<pkill9>but it just uses file path
<civodul>zimoun: yes, instead of (message (format #f ...)), you should use (formatted-message (G_ ...) ...)
<civodul>it's a slight improvement
<civodul>pkill9: yes because the package transformation machinery doesn't know it's a file name
<apteryx>does a search-path-specification add its 'owner' to the list of directories/files too?
<apteryx>I rekon yes
<zimoun>civodul: hum, I should be tired but I do not understand how to use ’formatted-message’ in this case.
<civodul>apteryx: i think so
<civodul>zimoun: it's just the transformation i showed above; syntactic sugar but the result is equivalent
<civodul>it's getting late for us though :-)
<zimoun>civodul, I get «error: (condition-instantiation &message () (formatted-message (G_ “…" name)): source expression failed to match any pattern» so I should miss something.
<apteryx>are changelog commit messages still warranted for automated mass refactoring via sed?
<leoprikler>You should check what your sed script does, so yes ;)
<leoprikler>If it does the same everywhere, you can do * file (location): Likewise.
<apteryx>I'm doing it... I just felt silly midpoint pressing Shift-C in Magit like a monkey.
<apteryx>emacs macros are fun though
<civodul>zimoun: yes, check examples from the code, there's a subtle difference in how to use it compared to &message
<civodul>apteryx: heh :-) for mass sed, it's even better to include the sed script (or similar) in the commit log IMO
<civodul>it's happened in the past
<civodul>commit 233e76769ae3a438bff7117c68f2c88739a28db0 for example :-)
<apteryx>efraim: cc-for-target! interesting :-) sorry for causing you some work
<apteryx>civodul: ah, nice.
<apteryx>I've done both for this time around!