IRC channel logs


back to list of logs

<singpolyma>OTOH guix of all systems makes it easy and clean to have whatever versions you need
<minikN>podiki[m] If I recall correctly, then you said you have a newer version of flatpak set up for Guix?
<minikN>podiki[m] Alright, I found your desktop-manifest.scm already. Transforms are amazing. I'll try it now with flatpak, thanks!
<podiki[m]>minikN: yeah transforms are great. if you install with a transform and then ask guix to export as a manifest, it will capture that
<podiki[m]>minikN: also just submitted all the flatpak updates I was doing:
<minikN>Im on GuixSD again as you can tell
<podiki[m]>jpoiret: you should see what iskarian is doing, they've been handling a lot of go imports, updates, etc.
<minikN>podiki[m] So I copied your manifest and added my packages: and that worked. Now I added xdg-desktop-portal and xdg-desktop-portal-gtk to the manifest and wanted to update the profile, now it hangs here:
<minikN>Don't really understand why it needs to download flatpak again
<podiki[m]>I feel like I saw an issue report once about something similar, but I too see it download flatpak many times when having a transformation like this
<podiki[m]>perhaps a "guix download" (adds the source to the store) would work around that. but not sure why it hangs, I would give it time in case it is a network thing
<podiki[m]>sometimes it can be slow doing these things, otherwise a complete hang without any output usually comes from some dependency cycle
<podiki[m]>but that shouldn't happen unless you modified something....i would hope
<cws7788>Without the network, can I finish installing the system?
<apteryx>I'm not sure; but perhaps if everything was already cached
<apteryx>I don't think it's tested territory though
<vivien>Dear guix, have you bugged tramp developers to include /run/current-system/profile/bin /run/current-system/profile/sbin to the list of default search paths?
<lilyp>Not afaik
<minikN>podiki[m]: Actually quite weird. I wasn't able to install any profile yesterday. I tried with other profiles and even deleted them. It would just list the packages to install and then hang. But today it works again. Maybe a connection issue.
<civodul>vivien: hi! i don't think anyone did, but IIRC our emacs package gets it right
<civodul>but yeah, since it's not upstream, someone using Emacs from another distro cannot use Tramp to connect to a Guix System box
<vivien>civodul, well, I did something to my config that broke it.
<vivien>I don’t understand what.
<vivien>But it’s true that non-guixers can’t connect to guix boxes
<PurpleSym[m]>civodul: Thanks (wrt Haskell merge), but I saw that ghc fails to build on i686 🤦‍♂️ Working on a fix now…
<PurpleSym[m]>(The CI was not set up to build on i686 for wip-haskell, thus it was not caught.)
<civodul>PurpleSym[m]: oh ok
<civodul>well, not too bad for such a big update ;-)
<PurpleSym[m]>True, no other complaints so far. I take that as praise :)
<civodul>in other news: \o/
<civodul>if you run "guix build /gnu/store/nnl67m8c2x9rwqbnych1agc6p7g5473g-disarchive-collection.drv", you get a 579M Disarchive database
<lilyp>Did our SSL certificates change in recent times? I can pull normally myself, but pulling from CI fails and I think it's the CI configuration
<cbaines>lilyp, could you share the failure?
<cbaines>I remember hearing about some LetsEncrypt certificate change recently, I guess that could be related if it is a TLS issue
<lilyp>cbaines: hopefully captcha-less link:
<cbaines>Right, so I guess you're talking about this bit:
<cbaines>Updating channel 'guix' from Git repository at ''...
<cbaines>guix pull: error: Git error: the SSL certificate is invalid
<cbaines>That looks more like a potential Savannah issue
<lilyp>We do seem to have a valid Let's Encrypt certificate, though
<lilyp>at least according to my browser
<cbaines>validity isn't a simple valid/invalid thing though
<lilyp>valid from 2021-08-20 until 2021-11-18
<cbaines>this is the most recent change
<lilyp>ahh, so our certificate could be expired by extension
<cbaines>well, it's more the trust path aspect which can cause clients not to trust a certificate
<cbaines>I'm not quite sure what git and TLS stuff guix pull will use
<lilyp>Trying to pull via HTTP, because Guix doesn't use HTTPS for security anyway
<futurile>hello all
<civodul>hi futurile
<wigust>hi guix
<futurile>hi wigust
<apteryx>mbakke: gst-plugins-base has a include/gstreamer-1.0/gst/gl/wayland/gstgldisplay_wayland.h header that refers to wayland-client.h; breaks qtmultimedia. I'm now propagating wayland from gst-plugins-base; is this reasonable?
<attila_lendvai>how can i search which package installs autopoint (trying to build a gnu make checkout)
<lilyp>apteryx: I don't think so, it'd also mean installing wayland to people who only want to use gst plugins and don't care about qtmultimedia
<lilyp>Note that gst-plugins-base is propagated for GST_PLUGINS_SYSTEMS_PATH to work correctly by all other gst plugins
<lilyp>[variable name might vary, but you know the one]
<mbakke>apteryx: I think it's OK, with a comment explaining the situation; less intrusive solutions could be to add an "include" output of wayland, or adjusting gst-plugins-base pkg-config files to add wayland to includedir
<civodul>attila_lendvai: you can't really search unfortunately, but it's from gettext
<civodul>sneek: seen wigust
<sneek>wigust was last seen in #guix 2 hours and 49 minutes ago, saying: hi guix.
<civodul>wigust: oh, hi!
<wigust>civodul: hi
<civodul>i was looking at my *Guix Bugs* buffer and wondering what to do with the accumulating Guix Home issues :-)
<civodul>have you had a chance to look into them?
<apteryx>lilyp: note that gst-plugins-base is already built with wayland, so it's part of its closure already
<apteryx>lilyp, mbakke thank you both for the comments
<wigust>civodul: no, because i thought we should merge the guix home tests suite before anything else :-)
<lilyp>part of the closure yes, but we should still strive to avoid propagation conflicts imo
<attila_lendvai>civodul, thank you! (such a tool would be really useful, i'm stuck on such questions regularly, and resolve them by clues from random websearches)
<lilyp>hmm, could we disarchive substitutes?
<lilyp>because then we'd have a map of package names to store files that we could fairly easily generate on CI
<roptat>hi guix!
<wigust>civodul: Also we should do something with file-like objects, because the documentation and "guix home import" depend on this
<wigust>which is most of "bugs"
<wigust>file-objects in terms of 50967
<wigust>roptat: hi
<civodul>wigust: right, merging the tests first sounds like a good idea!
<civodul>re file-like objects, there are currently few Home services, so i'm in favor of changing the relevant bits so that file-like objects are accepted instead of plain gexps
<civodul>we'd adjust "guix home import" accordingly
<civodul>abcdw seems to be skeptical, but yoctocell seemed to agree
<wigust>civodul: Would it be possible to extend e.g. home-bash-service-type with only file-like objects? If yes, I agree, too, keeping in the mind that we will break abcdw configuration, but I guess it's not much work to adopt the change.
<lilyp>could we support both?
<lilyp>e.g. you can either have a file-like object in which case that's that or alternatively a (list of) gexp(s) that gets turned into a file?
<lilyp>might be somewhat relevant if we think about extensions and compositions, no?
<civodul>wigust: there are no backwards-compatibility considerations to be had :-)
<civodul>wigust: so yes, i think it would be possible
<raiguy>is the prosody service broken for anyone else?
<Inline>what is the prosody service ?
<Inline>guix weather is not reporting properly here i think
<Inline>i don't see any packages or package groups listed
<raiguy>the xmpp server
<wigust>civodul: than I ready to merge 50967 completely
<wigust>(tests + no slurp)
*wigust moves (gnu home-services) to (gnu home services)
<civodul>wigust: i've commented briefly on the tests, LGTM!
<civodul>i have to go for a while
<jeremyc>How do I lock in a particular kernel version in my config.scm? i.e. I want < 5.14.
<wigust>jeremyc: (operating-system (kernel linux-libre-5.10) ...)
<jeremyc>wigust, thank you!
<wigust>jeremyc: np
<teddd>How does one convert an environment to a profile manifest ? Espacially how do you get the dependencies for packages mentioned before --ad-hoc ?
<teddd>If I have guix environement guix --ad-hoc git
<teddd>How do I create the corresponding manifest that has the guix dependencies ?
<lilyp>teddd: you can always read the manifest in $GUIX_ENVIRONMENT/manifest
<teddd>ah nice thanks !
<vivien>Dear guix, I’ve bugged emacs tramp to include /run/current-system/profile/bin|sbin as a default search path for guix system servers, but they ask me if there’s a distinctive feature that will hint that the server is running on guix (something like a particular value of uname -sr). My best guess is: "There is a file named /run/current-system/configuration.scm", because of the provenance-service. What do you think?
<vivien>I don’t feel comfortable to tell them that relying on uname is generally not a good thing ^^
<vivien>(or other form of distribution detection)
<bdju>has there been any talk of packaging yt-dlp? the form of youtube-dl that is maintained a bit more actively
<bdju>I was getting bad throttling down to dial-up speeds recently and I heard yt-dlp has a workaround that avoids the issue
<lilyp>vivien: It's actually the opposite: There's a file out there called /etc/os-release that big distros typically populate but Guix (and probably also Nix) doesn't.
<vivien>lilyp, how would you tell from an SSH connexion whether we should look up the programs in /run/current-system/profile/bin (aka, the server is running guix system)?
<vivien>By programs, I mean the coreutils, plus other bonus programs such as perl
<lilyp>vivien: you could simply test for the existence of /bin/ls /usr/bin/ls and /run/current-system/profile/bin/ls in that order?
<lilyp>sh will return 127 if the command was not found and some other error else
<vivien>Apparently tramp does something else.
<vivien>I’ll ask for more precisions :)
<lilyp>I mean the correct™ thing would be to source the shell profile and then perhaps use env to extract the variables
<lilyp>not sure how exactly tramp maintains its shell tbh
<notmaximed>To detect if it's Guix System (and if /run/current-system/profile/bin should be included in the path): just check if that directory exists?
<notmaximed>Guix' "getconf PATH" displays /bin:/usr/bin. I'd think it should either be empty (to reduce irreproducibility and remove directories that don't exist on Guix System) or include /run/current-system/profile/bin (to be useful on Guix System)
<notmaximed>At least, that's what returned by ~/.guix-profile/bin/getconf PATH on Debian
<the_tubular>Is there still work being done on porting guix to pinephone ?
<lilyp>there's at least some talks and I think a branch as well
<the_tubular>Mind pointing me to it? The one I saw hasn't been updated since a few months
<lilyp>okay, there's only a pinebook branch atm, but some folks recently got their hands on some pinephones (see "I just got my pinephone" on guix-devel)
*nckx yawns.
<nckx>Good morning, Guix.
<nckx>vivien: +1, just literally test whether /run/current-system/profile/bin|sbin exists. For heaven's sake don't sniff the name/other random symptoms of Guixiness.