<rekado_>(made with the new texlive importer that I don’t dare release)
<jackhill>rekado_: one of the tlpdb maintainers gave a presentation at packaging con. It sounded like its maintained by only two people! I bet they'd be willing to collaborate on improvements, althouth I think they are constrained by the desire to support legacy systems and practices
<kittyblam>Hey, anyone know where beyond the cookbook I could learn about packaging? I haven't done packaging outside of guix and am struggling to apply packaging as shown in the cookbook etc. onto real packages
<singpolyma>kittyblam: reading existing packages or the output of the importers I find useful
<kittyblam>singpolyma: speaking of that, its baffling me right now that
<kittyblam>guix edit (I assume thats the go to for looking at these?) just loads up nano when I have everything set to nvim I thought? lol
<singpolyma>Not sure, I wasn't aware of guix edit. I just have a clone of the guix get repo and read things that way
<civodul>vivien: i'm just thinking of a two-line change that could improve the first-time user experience, not more :-)
<abrenon>that's funny because that's one of the aspect that disturbed me the most at first when I was trying to write my first local packages (and one of the reasons why it seemed a good thing to me to centralize all my local packages in a single file instead of a guix.scm per repos)
<abrenon>but now that I've made my peace with it, I simply skip define-public and live my best life
<civodul>i think R5RS says it's "unspecified", which Guile interprets as "the unspecified value"
<abrenon>civodul: that wasn't intended as support ; ) rather a plea for examples without "define-public" and the simplification of terms: a package file should intuitively hold an expression of type "package"
<apteryx>civodul: hmm, so if I download some .tar.xz release from github, with the accompanying .asc file, and there's no easy way to valite the GnuPG key used to produce the signature is the intended one, the check doesn't have any value, right?
<xelxebar>A while back, there was talk of implementing "reverse search" (file path -> package). IIRC nckx (?) was working on a prototype. Did this end up going anywhere?
<mjw>roptat, nice, hope it will be accepted, it would be nice to at least see some people virtually again (we are entering a new 3 week lockdown in the Netherlands again, it feels this pandemic will never end... sniff)
<roptat>yeah, we've had great success the previous years, so I don't see why they'd reject it this year :)
<roptat>in any case we'll probably have a fringe event too, just for guix
<apteryx>civodul: so if downloading source code is TOFU, is there any value in checking the signature? Perhaps it helps detecting corruption (the same a checksum would) ?
<roptat>compared to last year, it looks like there are a bit less proportion of apps that have at least a translation, and translations are a bit more spread out (some apps are only translated in one language that is neither German nor French, the top 2)
<apteryx>still thinking in that context I don't have any mean to *verify* is truly own by whom it ought to.
<sneek>dannym, raghavgururajan says: I am re-working patches in #42958, for applying them on current c-u.
<Guest81>Thank for reply! But can you be more specific?
<rekado>Guest81: IIRC /var/lib/gdm is the home directory of the gdm user account. So if there are logs they should be in that directory. With the logs you might be able to figure out why GDM isn’t starting.
<rekado>apteryx: core-updates-frozen looks pretty good. I’ve built almost up to pigx. There are just a few broken packages left that I will need to fix.
<Guest81>Okay! Currently I'm running guix pull, I will report you after that.
<rekado>apteryx: most notably: python-nbconvert, which holds up python-notebook, python-widgetsnbextension, python-ipywidgets, python-rich, and multiqc
<rekado>I’m also upgrading my profile; building blender now. So far there has only been one build failure (dino), which is now fixed.
<rekado>apteryx: curiously, ‘guix system build’ complains about a conflict
<rekado>different variants of at-spi2-core are used due to gnome and network-manager-applet.
<apteryx>civodul: re guix refresh -u, it downloads the key referred to in the (detached?) signature?
<apteryx>by the way, we should really choose another key server than the one currently in use; it never response, makes the --key-server argument necessary; info '(gnupg) Dirmngr Options' says the default is now 'https://keyserver.ubuntu.com'.
<rekado>we’re having a problem with simple-texlive-package
<rekado>when we copy built files we’re also copying trash
<rekado>so packages end up with /share/texmf-dist/build, for example, or the package archive itself in /share/texmf-dist
<rekado>once we’re done with core-updates-frozen we need to take a good look at texlive
<rekado>we’re close to having something good here; but it needs all the attention to details that I couldn’t afford.
<florhizome[m]>Not sure if I understood this: can I load multiple profiles in userspace at once? I created a couple profiles, it definitely helps (I also remarked that it is most definitely bigger icon packages and/or fonts that slow down the „generating profile with... ) part down to a near standstill..
<jpoiret>florhizome[m]: yes! loading a profile is simply a matter of adding some profile-specific paths to your environment variables, which is taken care of by $PROFILE/etc/profile
<jpoiret>the preferred way is to set GUIX_PROFILE to a profile's path, then source $GUIX_PROFILE/etc/profile
<jpoiret>the reason for that is that the /etc/profile will then use your GUIX_PROFILE variable instead of the store name in order to have a more human-readable path for your env vars
<florhizome[m]>I just copied over a script from the cookbook, but actually that sounds like that hmmm
<florhizome[m]>Maybe that was another thing^^... Are fonts and icon caches shared between those?
<lenny>hi, the bashtop package seems to be broken on my install. I installed it via `guix install bashtop` but when i start it it displays: gnu/store/vxydnyix3nrgwgf4bc531qd2r31hs4af-profile/bin/bashtop: line 65: locale: command not found
<roptat>mh, this should have been hard-coded to a store path instead...
<roptat>it should work if you also install glibc in the profile
<lenny>roptat: you're right "guix environment --ad-hoc bashtop glibc -- bashtop" works
<lenny>It seems like it should not be that way. I would like to learn about packaging on guix anyway. should i add glibc as a dependency to bahstop and submit a patch?
<roptat>no, that's not how we do it, adding a dependency (input) would not change anything. With a propagated-inputs, it would force the installation of glibc, but it's not necessary. Instead, we should have a phase that hard-codes the store path to locale
<roptat>if you want to have a look, you could search for "substitute*" in existing packages
<roptat>otherwise, you can simply send a bug report with what you reported, and the "fix" we found :)
<lenny>Hmm, somebody else could probably fix it faster, i'll try for this evening. If i don't get it working i'll submit a bug report
<lilyp>rekado, vivien: ad gnome-boxes, is there perhaps a libsoup input already to gnome-boxes itself?
<lilyp>it might be, that pkg-config simply fails the lookup because of (ugh) Requires.private
<lenny>roptat: can you explain why installing glibc is not necessary?
<Zambyte>I actually had a very similar issue as lenny but with foot. I installed foot on a foreign distro using `guix install foot`, but I get an error saying "locale is not UTF-8". If I run the package using `guix shell foot -- foot` it does run.
<roptat>lenny, usually, we replace relative calls (like "locale") with absolute filenames (like "/gnu/store/.../bin/locale"), so it helps with reproducibility (we know it's always the same glibc that's being used, and not something else from a foreign distro that might interfere), and it reduces the number of packages explicitly or implicitly added to a profile, which helps reduce conflicts
<roptat>lenny, in your case, we haven't done that, so installing glibc is necessary, but we should have replaced the call with an absolute filename
<roptat>the goal is that whatever happens "guix shell <foo> -- foo" will always work
<Zambyte>It seems like sort of an essential package to me; especially if I've installed things that don't work without it. The guix info page says "in foreign distros, a few additional steps are needed to get everything in place" and lists installing the glibc-locales package as one of the steps. I feel like the script to install guix on a foreign distro should already do this if it's a needed step
<Zambyte>`guix remove glibc-locales foot && guix install foot` doesn't print any warning that glibc-locales is missing
<zamfofex>Zambyte: Some packages might be installed on the system profile, not in your profile.
<zamfofex>Zambyte: E.g. you might not even have ‘glibc’ in your profile.