<slimjim>and with `guix pack -f docker --entry-point=somepackage`, users would not ever be running commands inside the docker image, just the toplevel package would be auotmatically invoked. So if that package depends on python, sqlite, or what have you, the consumers of the docker image don't need man pages, info pages, bash completions, etc
<slimjim>b/c the image woudn't even have bash in it at all
<slimjim>so I'm trying to find a way to say "ONLY give me the run-time dependenices of this package". Man-pages for dependent packages I wouldn't consider to be necessary
<slimjim>but this seems like a larger problem with packages including more things in their default 'out' target than they need to when not being directly included in a profile/pack
<lfam>I see what you're saying, but it's not a trivial change to make
<lfam>What goes into "out" does not depend on whether or not the built package is going into a user profile, system profile, a pack, etc
<slimjim>well, this is why I ask. Trying to survey to see if anyone has already done something like this before. If not, I may need to do it myself.
<slimjim>lfam: I wouldn't consider the use-case "niche", I've seen a number of articles online comparing `guix pack` with things like appimage, flatpack, docker images, etc. Perhaps the interest is small now because it's not well-established yet, but the idea for this was a big thing that drew me to guix in the first place
<lfam>The concept of "dependencies" in Guix isn't based on types of files — e.g. exectutables, libraries, man pages, etc. It's based on store items, which are the top-level directories in /gnu/store
<slimjim>as a software distribution mechanism that enabled full transparency and reproducibility
<leoprikler>if the doc of a package is considered too big, it'll get its own output
<leoprikler>if not, you're better off not unnecessarily introducing it
<lfam>That's not the only criteria, leoprikler. The package should also be used widely throughout the package graph. A leaf package with large documentation would not have a separate 'doc' output, typically
<lfam>So, Python could actually be a good candidate for this, assuming the docs are large
<nikita`>i think i did something like this back then for my own
<slimjim>what about the idea of multiple outputs that are included by default, so instead of e.g. having to specify somethign like "bash:out bash:doc", you could instead say "bash[without:doc]" to explicitly exclude the doc ouptut (which would otherwise be included)
<nikita`>but you need to walk some inofficial path for python docs
<leoprikler>slimjim: you won't get bash:doc unless you explicitly request it
<lfam>slimjim: These "split" packages require manual work in each case, and it is not always possible
<slimjim>leoprikler: I know that is the case *now*. I'm throwing out ideas for a different way of doing it, where multiple output targets could be included by default, and then adding a way to EXCLUDE outputs that would otherwise be default
<slimjim>AFAIK that doesn't exist now, but could it?
<slimjim>then from that you could build up machinary like a --without-doc package transformation
<rekado>“guix build” builds everything. If a package has more than one output and is configured to use those output locations (e.g. with ./configure flags or with build phases that move files) then files end up in those other outputs.
<rekado>it’s not always possible to actually use different prefixes for certain files
<lfam>Guix builds packages in a functional way, and the output of the function is one or more directories in /gnu/store ("store items"). For package recipes with multiple outputs, the recipe must include instructions for moving files into the correct store item. On the other hand, package transformations transform the recipes themselves, and can do that kind of thing throughout the entire package graph, which is super nice. But "package
<lfam>outputs" and "package transformation" occur at different levels, both conceptually and in terms of code organization
<rekado>FWIW git send-email works outside of Emacs
<lfam>The biggest software project of all (Linux) is email-based. But there are pros and cons to both approaches
<slimjim>leoprikler: what's etiquette for something like this, asking if is anyone still looking at a bug? On https://issues.guix.gnu.org/25235 it looks like Ludo had a patch in 2017 that didn't fix the issue, then in April Ricardo asks a question, Arun gives a response, and then no activity since then.
<slimjim>is it appropriate to 'bump' the issue to bring it back up on developers' radar?
<slimjim>or is it already a known/hard problem that's subsumed by issues elswhere?
<leoprikler>Posting messages, that don't add anything is somewhat counterproductive.
<leoprikler>That being said, there is no indicator, that someone is actively working on any given issue. If you feel capable, you may want to look into it yourself.
<leoprikler>You could propose a (WIP) patch or what have you.
<slimjim>leoprikler I'm trying to reproduce some of the package lists as described in that ticket. If I've already downloaded a package via a substitute, how do I force building it from source so I can inspect the build logs?
<slimjim>`guix build --no-substitutes cpplint` for instance just returns the path to the package I already downloaded via subsitute
<slimjim>and no change if I add `--rounds=2`, which I thought was supposed to build it multiple times to verify reproducibility
<slimjim>and `guix challenge cpplint` complains because there is no local build (which I'm trying to create)
<slimjim>hmm maybe `guix build --check` is what I want
<lfam>slimjim: Likely you'll need to add --no-grafts. Grafting is considered a "build", so for packages that are subject grafting, --check may only re-do the graft
<lfam>I mean to write, "... so for packages that subject to grafting..."
<slimjim>lfam: the situation I'm trying to reproduce, as mentioned in the issue, is when certain build paths are different when grafting vs when not grafting, so to repro I'm trying to do a local build both with and without grafting
***ece3 is now known as ece
<lafrenierejm>A `guix system disk-image …` is failing on three tests. Any idea how I should go about resolving that?
<chaosmonk>hi, does anyone know of a reason that guix would choose to compile a package from source when upgrading even though there is a substitute available according to "guix weather" and ci.guix.gnu.org?
<drakonis>hmm, say, is it possible to reasonably replace shepherd with another init?
<lfam>chaosmonk: Assuming it's the same derivation (same store path, including the hash), there are a couple explanations. It could be that the substitute server is not authorized on this installation of Guix — if you are downloading other substitutes from it, that's not it. Or it could be a transient networking failure — Guix will cache the negative result for a little while. The ci.guix.gnu.org server could be having trouble, too
<chaosmonk>lfam: thanks, i can download other substitutes, so that's not it. ungoogled-chromium has been compile for a day and a half now, and the progress bar has been stuck at 100% for the last 6 hours. i don't know how much longer it's going to take, and it's making my computer too slow to get any work done. is there a 100% sure way to force guix to use the substitute? i'm afraid to cancel the upgrade and try again in case it just starts over compiling from
<chaosmonk>i've built u-c before at times when there wasn't a substitute available. it's always taken at least a day, but this is the first time it has stayed at 100% for this long. that's the only reason i'm questioning it
<chaosmonk>on the off chance that there was some temporary failure, is there a way, without canceling the current build, to determine whether guix would use the substitute if i ran guix upgrade again?
<chaosmonk>guix weather says there is a substiute, so at first i thought a substitute had been added in the meantime, but ci.guix says that the substitute for this version of u-c has been available for over a week
<procra>Did some one tried linux container or did you guys think that guix containers are secure enough?
<lfam>Nothing simple that I can think of, chaosmonk
<chaosmonk>ryanprior: it exited with an error, that my profile is locked by another process, presumably the current build of u-c still stuck at 100%
<ryanprior>Ah darn, I haven't seen that lock message before.
<chaosmonk>i typically get that message when i try to start a guix transaction while another one is ongoing
<ryanprior>fwiw I never build it, not worth, I always run with --do-not-upgrade=ungoogled-chromium unless there's a substitute :\
<chaosmonk>yeah... it's a pain. but there already is a substitute and it's still building form source, so i'm not sure what will change if i wait
<chaosmonk>what does guix even do in between 100% and completion that could be taking so long?
<lfam>chaosmonk: The percentage meter is not exact — there isn't any way to truly predict how long it will take. So, it could be that the final step is taking much longer than the other steps. I don't know how it decides what is a "step"
<raghavgururajan>chaosmonk: For profile lock, you can try the commands as different user or root. The profile is different for each user. So root may not be locked.
<slimjim>chaosmonk: the final 'link' of the chrome/chromium binary at the end of the build is VERY memory intensive
<slimjim>I'd check ps and htop output, if you are out of memory and swap space it could make your system unusable and maybe not even finish
<ride>I am trying to create a package and I am stuck with this error: "FileNotFoundError: [Errno 2] No such file or directory: 'glib-compile-resources'"
<ride>I would assume this should be provided by glib, but it is present in the native-inputs.
<slimjim>chaosmonk: also worth checking your nofile ulimit. the u-g build adds an 'increase-resource-limits step before doing the build that tries to se the nofile ulimit to 2048 to accomdate the link step. If your hardlimit is less than that, could be causing issues with the link
<lfam>ride: Look at the packages in 'gnu/packages/freedesktop.scm' to see examples
<chaosmonk>slimjim: it is using a lot of ram, but i have about 1GB free atm. how do you check the nofile ulimit?
<olivuser>I am trying to get /etc/profile sourced BEFORE my window manager (exwm) is launched. I want to do that because said window manager does not function properly, because it does not find utilities like git or ls when opening a file (git) or using dired (ls)
<sundbry>Hello #Guix, does anyone understand what would cause `guix system reconfigure --debug=6 /etc/config.scm` to try to delete my glibc here? It's literally deleting the glibc from under itself and bricking the os on a virgin install after `guix system init`
<rekado_>services… I give you that. It’s a little more involved than specifying a command to run.
<rekado_>maybe there’s something we can do about that.
<OriansJ>well even on Fedora cron is going to go away as systemd.timer are being pushed as the replacement
<jonsger>rekado_: I don't think that roll backing helps make Guix feel more stable. It's more a problem of broken packages, which do not build anymore or other stuff which breaks and hinders going forward.
<rekado_>meh, somebody broke the recursive importers
<rekado_>jonsger: we have a different definition for what makes a system stable
<OriansJ>jonsger: well the word stable in no way implies something is functional; only that it isn't changing. But yes in general software practice it is better to try to only tag stable releases on things that actually work.
<OriansJ>but unfortunately the world under use can change in an instant.
<OriansJ>gnutls-3.6.12 for example; included a cert that no one really noticed until after it expired.
<atom`>Hi. I have been asking for some support in the past few days regarding FIDO U2F issues in Guix. It turns out that the device works properly in Ungoogled Chromium (installed just to test), but not in IceCat, with similar results as those shown in this thread: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38341 Does anyone have a positive experience using U2F in IceCat or otherwise know how to move forward with such issues? I know that
<atom`>the same device works perfectly fine in Firefox.
<NieDzejkob>There's something about the end of the year that makes me want to revisit Guix again...
<leoprikler>atom`: which Firefox version compared to which IceCat version?
<leoprikler>IIRC the IceCat project has a long way to catch up to upstream
<atom`>leoprikler: It has worked on all Firefox versions for a long time. The currently installed IceCat version is 78.6.0 which should support U2F out of the box. I think the problem is either related to IceCat scripts or the IceCat "implementation" in Guix. In the bug report I referred to in my previous comment they mentioned it working on IceCat built from source, however I have yet to try this.
<raghavgururajan>atom`: I think IceCat may be using different config values from firefox. You could compare and play around with the values in about:config
<atom`>raghavgururajan: I don't think that is the issue, as the related security.webauth.* values are the same in my Firefox and IceCat about:configs
<raghavgururajan>You could also try running IceCat on safe-mode. Options --> Help --> Restart with addons disabled.
<vits>hello again. bare-hurd.tmpl has instruction on building, and running the image at the top. I tried them, and get 'start ext2fs: ext2fs: device: hd0s1: panic: get_hypermetadata: bad magic number 0 (should be 0xef53)'
<chaosmonk>i just canceled the build. i'm going to try again and see if it uses the substitute this time
<raghavgururajan>chaosmonk: Btw, you mentioned that u-c is not installed in root profile right? You can try `guix install --dry-run u-c` to see if it build or downloads substitute. Instead of guix upgrade
<raghavgururajan>If it is different, copy the commit value from root profile and do `guix pull --commit=copied-commit-value --allow-downgrades` as regular user. Then do `guix install --dry-run u-c`as regular user. It should use the substitute.
<chaosmonk>raghavgururajan: it's using the substitute this time. idk why it didn't before, but at least it's working now
<jonsger>I thought only rust ignores the `--cores` parameter from guix-daemon but it seems like clang does it as well (mozilla build system)
<atom`>bandali, raghavgururajan: Just to let you know the same problem with U2F from IceCat is present in Firefox that I just finished compiling. Don't have time to debug more today, but perhaps there is indeed some missing dependency for Firefox-based browsers.
<bandali>atom` interesting. so it's seems it's an upstream issue then?
<bluekeys>Hello guix! How does one send audio to a bluetooth headset?
<NieDzejkob>bluekeys: with pulseaudio and bluez it should be pretty much plug-and-play AFAIK
<atom`>bandali: I don't think so since it works fine on the same Firefox version in Gentoo. Maybe there is something that needs to be configured to enable Firefox/Icecat to "talk to" the U2F key? Like I said it works for ungoogled-chromium, but all the related U2F configuration is basically scrapped together outside of the installation of either browser (i.e. adding the service, udev rules, installing U2F-related packages)
<bandali>atom`, i wasn't sure how you built firefox, so i thought maybe you did a vanilla build
<bluekeys>I have a service setup in config.scm. I also have bluez and bluez-alsa and can connect to my device using bluetoothctl. I can hear the connection in my headset. I can also drop it and hear that too. If I try to run a video using vlc, for example, the sound comes out of my laptop audio, not the headset.
<atom`>Ahh Firefox is from the Guix channel whose name shall not be mentioned :p
<webstrand>I like to set up my remote servers with an encrypted root partition, for a thin layer of security. To unlock the filesystem at boot, I start an sshd in my initramfs. Is guix capable of something similar?
<webstrand>I'm not even sure if guix supports unencrypted boot with an encrypted root?
<lfam>cbaines: Yes, it was frozen a couple weeks ago, but Cuirass has stalled
<lfam>cbaines: According to the web interface, Cuirass hasn't evaluated the branch in weeks
<slimjim>hi #guix, what is the general timeframe for updating to a new version of python? I see python-next is at 3.9.1, but regular python is still at 3.8.2, and there is a critical CVE affecting all versions of python before 3.9.0, see https://nvd.nist.gov/vuln/detail/CVE-2020-27619
<slimjim>"In Python 3 through 3.9.0, the Lib/test/multibytecodec_support.py CJK codec tests call eval() on content retrieved via HTTP."
<slimjim>so this could expose anyone building python from source to RCE via MITM
<cbaines>Not in Guix at least, since builds happen without network access
<lfam>On the staging branch, it is updated to 3.3.1.
<lfam>If you need 3.4.1 on the master branch soon, I recommend creating a new package python-sphinx-3.4, that would inherit from python-sphinx and change the version, and then use that package where needed
<lfam>I'm hoping to merge the staging branch within 7 days
<lfam>You can check "how many packages will be rebuilt" with `guix refresh -l python-sphinx`