<podiki[m]>could be good to have in the contributing section of the docs frequent steps needed? like when a make clean or go-clean is needed, or a reset? or what to do when getting a translation file error?
<podiki[m]>(I'm always guessing too, mostly just "make" is fine, but sometimes needs more)
<jpoiret>pranavats: great! i'm kinda happy these do work, hope they'll be applied to GRUB for the next released
<jpoiret>other distros have the same issue as well
<sughosha>Hi Guix, I would like to know how does Guix handles updates of packages. Is every package should be updated manually by the respective maintainers, is there any automated process of handling them via `guix refresh` or something, or does Guix developers handle them in bulk at once? I'm asking this because I tried with `guix refresh gtk` and it says it can be updated to 4.6.1 while the current version in Guix is 4.4.1.
<abrenon>AFAIK packages don't have specific maintainers, although in practice of course some people have more interest in such or such package and will tend to follow its development more closely
<sughosha>I tried packaging many GNOME World's apps but many of them need gtk4 >= 4.5.0, but Guix has only 4.4.1 as of now.
<abrenon>I think many update patches we see are merely generated by their developer with guix refresh, performing certain checks to make sure the software still works as expected, or checking a new feature announced upstream
<abrenon>that's understandable, because, and that was my last point, there's possibly a lot of intrication with huge, central packages like GTK
<abrenon>I suppose you can just refresh it, but then I expect the amount of work required to ensure it hasn't broken all the existing gtk apps will be colossal
<abrenon>plus, when a patch impacts too many package I think I remember there's a specific process required to avoid triggering too many rebuilds at once on the CI
<abrenon>I expect such an update to be typically the case
<abrenon>have you checked if there's a branch for it ?
<sughosha>abrenon: Branch of what, of a package or of Guix?
<sughosha>I'm trying to package some GNOME applications, like Tangram and Telegrand. I'm just trying with latest release of them.
<sughosha>I will check if they have specific branch like stable or something. Currently I am referring to the release tags (don't know if they themselves are branches or part of a branch).
<paul_j>I am continuing to work with guix home, and have a quick question about shepherd services. I created a service for syncthing, but I think I used some code I found elsewhere. Anyway, I have now tried to create a service for gpg-connect, but I am getting an error "gpg-agent: unbound variable". I have the relevant code for the shepherd services here: https://paste.debian.net/1232206
<paul_j>I am not sure where I am creating a variable, or at least where it differs from the syncthing definition. I don't think it is in the provision line, so I am guessing I am doing something wrong with the start and/or the stop fields.
<paul_j>I do have a use-modules line for (gnu packages gnupg).
<akonai>there's no gpg-agent package, you need to call /bin/gpg-agent from the gnupg package
<akonai>or /bin/gpgconf and /bin/gpg-connect-agent in this case
<akonai>i.e. I believe #$(file-append gnupg "/bin/gpgconf") should work
<paul_j>akonai: did you have a look at the code in the pastebin? I call gpg-connect-agent to start it, and gpgconf to kill it. The only reference to gpg-agent is in the provision field, and in the file-append sections of the start and stop gexps. I could have formed the file-append section incorrectly of course!
<akonai>You have #$(file-append gpg-agent "gpgconf"), which tries to get the store name of the package gpg-agent, which doesn't exist
<paul_j>So my mis-understanding - let me try again!
<paul_j>akonai: Ok - so just to confirm my understanding: #$(file-append gnupg "/bin/gpgconf") actually returns "/gnu/store/<hash>gnupg/bin/gpgconf". In other words, it finds and dereferences the store location for the package in order to identify the path of gpgconf, so that can be called when shepherd (in this case) stops the service.
<apteryx>this way it'll automatically validate the signature of the release archive with it
***form_feed is now known as \f
<sughosha>Hi again! I am facing difficulty in packaging some applications which use meson build system but have cargo inputs. In build phase, it says "Updating crates.io index" and then "warning: spurious network error", and then "failed to get ... as a dependency of package ...". A help is appreciated.
<podiki[m]>I don't know the specifics, but there is no network access in the build environment, so probably you need to have those sources already (from a package in guix) or patch/unbundle them
<podiki[m]>someone with rust experience will know better
<podiki[m]>maybe there is a similar package already in guix you can look to see how it was handled?
<sughosha>I already added the needed dependencies in native-inputs, but still I'm getting this error.
<sughosha>All of the package upstreams recommend meson in their README. I never tried cargo-build-system, I will try one now (have to learn first).
<balbi_>hi folks. What's the trick to get `guix' (well, gnupg under `guix') to recognize my nitrokey? same config works on arch, doesn't work on `guix'. I'm assuming I'm missing some service, but no idea what it is :-p
<alMalsamo>is there any way yet to download all source tarballs for a system definition to pull all code necessary for compiling every package later offline pulling from local storage where all the source code hsa previously downloaded to?
<acrow>alMalsamo: When you ask, "is there any way", I think, are you asking if this is possible? To that, I think, yes; but I don't think that is what you really meant. I think you meant to ask if caching of source was a guix feature. To that I would say, not that I am aware of. However, source code caching for subsequent builds is sorta already there. You just want to postpone the phases 'unpack and beyond for later offline execution.
<balbi_>reza[m]: I'll give it a shot, thank you :)
<balbi_>reza[m]: worked like a charm, thank you :)
<alMalsamo>acrow: Do you know where in the source of Guix the feature for caching for subsequent builds is so I can try to study it and see how the fuck I can postpone for offline use?
<acrow>alMalsamo: It would require some digging around. I don't understand exactly what your motivation is but might it be easier to make your machine it's own substitute server and leverage local substitutes offline rather than caching and then building from source? Guix substitutes are verifiably reproducible.
<cbaines>alMalsamo, it sounds like you might be looking for guix build --sources=...
<cbaines>in particular, the --sources=transitive option is documented as: " This can be used e.g. to prefetch package source for later offline building."
<acrow>alMalsamo: cbaines has your answer. I didn't recall the --sources build option.
<alMalsamo>cbaines: Wow cool... kind of confusing to be a switch to the "build" command since it seems not to build anything, but it looks like it applies patches, but that is not the same as building really...
<alMalsamo>guix build --sources=transitive looks to be exactly what I need, but I would like to do this for an entire system not just one package at a time
<jackhill>hmmm, `guix gc --verify=repair,contents` doesn't seem to be sucessfully reparing files (it tries to repair the same store items on a second run). Is this likely to be a hardware problem? https://paste.debian.net/1232259/
<jackhill>alMalsamo: I haven't checked, but I wonder if `guix system build` would accept the --sources=transitive option. Otherwise, you could probably get `guix build` to do your set of needed packages by passing it a manifest, but if `guix system` will do it, then it will save you the trouble of figuring out which packages your system needs :)
<jackhill>unmatched-paren: for you specific thing, we could use different options per-archetecture. I thought there was already something in the patch tracker for that…
<alMalsamo>nckx: Hmm okay this appears a lot further down on the doc page than the section describing guix system build, it is kind of confusing order, does this apply? Are you saying I can use --sources=transitive switch to guix system build and it will download source code + patches for every single package in guis system definition?
<nckx>Alas, ‘--sources=’ is under ‘The command-line options presented below are specific to ‘guix build’.
<nckx>Alas, my big-brained scheme to abuse ‘guix build --sources=transitive $(guix system build -d /etc/guix/system.scm)’ went nowhere in a hurry.
<djeis>Does anyone know if something's blocking an update of guile-netlink to 1.1.2, and if nothing is could someone point me towards the simplest way to offer the updated package I just threw together? (all I did was update the package's version/hash and check if it builds)
<nckx>djeis: Assuming you have git set up and it's the top commit, it can be as easy as ‘git send-email --to=guix-patches [at] gnu.org -1’.
<nckx>That's the minimum, but it would be nice to rebuild all dependent packages (guix refresh -l guix-netlink) and run the system tests (make check-system, although I'm not sure they all pass as-is).
<djeis>I don't have a setup for changes in-tree yet, so to test I just copied the package out to my private channel. I'll try to do that this weekend though, I think it'd be a good first contribution and it's directly related to some work of mine.