<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>And the use case is rather niche IMO <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 <lfam>Sometimes it's really easy <lfam>Bash already has a separate doc output <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 <lfam>It's based on a misunderstanding of how Guix builds packages <lfam>I think we should get back to the concrete problem, which is that some things are too large for your use case, and work on ways to improve that situation <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 <rekado>an example is any Haskell package <lfam>rekado is more experienced than me and can help explain more clearly than I can *rekado slowly walks backwards <lfam>I'm running low on energy :) <slimjim>well I don't understand much, so I'm sorry if my ideas don't make sense :P <lfam>It's hard for me to explain concisely <lfam>I want us to help you with your problem <rekado>slimjim: a better place for a discussion like this is probably guix-devel@gnu.org <rekado>a good preparation, though, is to read a little about how it works now <slimjim>rekado yeah I agree. I'm trying to dive into the whole mailing-list / debbugs workflow <rekado>then we can avoid some misunderstandings <slimjim>gotta get my emacs+gnus setup and grok git-send-email <rekado>I don’t envy you; setting up git send-email for the first time is annoying. <slimjim>coming from a gitlab-based workflow I was very impressed to see how productive large development teams can be with nothing but email <slimjim>most people that criticize an email-based workflow probably aren't using emacs though :) <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 <rekado>I must admit that even though I live in Emacs I never really liked M-x debbugs <rekado>probably because it’s so closely integrated with gnus <lfam>The way that packages go from "package recipe" to "store item" involves a few levels of lossy intermediate representations <lfam>Learning a little about this can help understand what is easy / possible and what is not. One doesn't have to be an expert at all <rekado>re email-based workflow: for me the biggest problem was the initial perception of shouting into the void <slimjim>rekado: I find the threads a lot easier to read in gnus though, so I appreciate the automatic downloading of mbox files for the issue <lfam>There have been some comprehensive yet short talks on the subject that were recorded and put online. I need to find one and save the link, because they explain it more clearly than I can <slimjim>I find the gnus mbox threading a lot easier to understand than scrolling through a linear list of emails <lfam>Having a good email client is essential! <lfam>For me, mutt is key to being productive with Guix development <lfam>It takes so long to get the hang of it, though <lfam>It does represent a barrier to new contributors <rekado>I’m now stuck at a local maximum (mu4e). It doesn’t do threading all that well, unfortunately. <rekado>don’t have the mental bandwidth to switch to anything else, though <slimjim>I've been browsing help-guix and guix-devel currently by downloading mbox files for the month and then reading in gnus <rekado>I’m also preparing to become old, so I’m learning not to learn new things <lfam>Yes, rekado. The effort of switching seems insurmountable <lfam>Okay... it's a little soon for that rekado! <rekado>gotta start at *some* point; might as well do it when the body feels ready <rekado>actually… sleep might help right now. <slimjim>I might eventually submit some patches based off dustyweb's prior work for packaging python-cheroot, if I can get a handle on git-send-email and clean up what I have locally <lfam>If git-send-email is too much of a stumbling block, `git format-patch origin/master` should create the right patches, and you can send them as an attachment <lfam>Another rarely used method is to send a link to a Git repo with the commits <lfam>We prefer a specific workflow for frequent contributors, but new contributors should just get us the code in whatever way they can <nikita`>gnus is only fun with reasonable empty inboxes. after that you hit emacs being slow as heck <slimjim>nikita`: do you know if the native-comp branch improves gnus' performance with large inboxes? ***chrislck_ is now known as chrislck
<slimjim>anything using python-build-system that has output in bin (using the wrap phase) gets native-inputs included in PYTHONPATH, which results in them going into the pack <slimjim>`guix size cpplint` shows quite a bit of size due to python-pytest and its dependencies, which are only native-inputs to the cpplint package <leoprikler>PYTHONPATH picking up native inputs is indeed an issue, not just due to `guix size` <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..." <lfam>Or, that are subject to grafting <lfam>Anyways, back to cooking <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? <lfam>lafrenierejm: Which tests are failing? <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 <lfam>drakonis: It's not supported <drakonis>question, how's the feature prospects for guix in 2021? <drakonis>the mailing list doesnt seem to point to anything exciting right now <ryanprior>drakonis: three things I'm excited about for 2021 <ryanprior>One is that emacs-guix is getting revamped and moved into the Guix infrastructure, which will hopefully provide a nice interface. <ryanprior>The second is that we've got a bunch of gtk4 and pantheon desktop environment stuff that we can use to modernize the desktop, it'll be lots of work but I'm looking forward to it. <ryanprior>And finally, I'm expecting to make some headway packaging more of the nodejs ecosystem using an aggressive dependency-chopping build system <ryanprior>If you ask 10 of us what our top hopes are for Guix features in 2021 you might get a dozen answers, and I'd definitely read that blog post, so ask away =D <ryanprior>The hypothetical one where somebody asks 10 Guix maintainers their top hopes for 2021 and records the answers. <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 <lfam>Building ungoogled-chromium requires some serious computing resources. How much RAM is available? <lfam>In general, if substitutes are enabled, Guix will always use them when it can <lfam>It might not be enough, I don't recall exactly how much it needs <lfam>What commit is reported by `guix describe`. I can check if it's working form here <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 <lfam>Okay, then it's likely it can succeed <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 <ryanprior>It'll tell you whether it would download it or build it <ryanprior>guix package --dry-run --upgrade ungoogled-chromium <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. <lfam>ride: Try the "bin" output of glib <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? <ride>I am also wondering what "license:expat" means in the license field. I see it is used for program released under the MIT license. <chaosmonk>ride: it's to distinguish it from the x11 license, a similar license which is also called "the MIT licence" <slimjim>chaosmonk: in bash, `ulimit -n -S` and `ulimit -n -H` will show you the Soft and Hard limits for number of open files, respectively <slimjim>well, the u-g custom build step tries to set the soft limit to 2048. Your hard limit is higher than that, so that part should be succeeding <chaosmonk>is there a chance setting the soft limit to 2048 would help? <slimjim>so maybe that's not it... does `ulimit -v` show something other than 'unlimited' for the virtual memory limit? <slimjim>chaosmonk: no, b/c the build daemon itself is going to raise the soft limit to 2048. <slimjim>the only reason that would fail is if your hard limit were less than that <slimjim>either way, nothing you do now is going to affect the build already in progress :\ <slimjim>you'd have to stop and restart the build for any ulimit / resource changes to go into effect, AFAIK, and then you'd have to restart the build from scratch <chaosmonk>raghavgururajan: running "--dry-run --install" as root (--dry-run --upgrade as root doesn't work because u-c isn't installed as root) as that it would use the substitute <chaosmonk>ugh, it's getting late. i might as well let it keep running overnight and see what happens. thanks for everyone's input <slimjim>kill off as many other processes as you can to reduce resource use while it's going... <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` <sundbry>basically i download guix-1.2.0.tar.xz and do `guix system init` in a chroot to install guix, and reboot into a working fresh os to get to my starting state <sundbry>as soon as it deletes glibc (at the end of the log) the procedure crashes because it loses the link to ld-linux.so <sundbry>I guess I dont understand why so many packages in my store are being re-substituted in the first place, it seems unnecessary <sundbry>I think because my provenance info is missing from `guix describe` it tries to re-substitute the world when i boot the fresh os -_- <leoprikler>(invoke "xbuild" "something.csproj") should work with mono as input <leoprikler>but it seems to be pretty self-contained with only a handful of dependencies. Huh <kolyad>I have not seen any sort of think approaching that description, other than the NixOS-mobile project, which I assume prompted you to ask. <pkill9>does anyone here run guix package manager on fedora? <pkill9>I'm thinking of switching to fedora <abcdw>pkill9, why are you switching to fedora? <pkill9>you can install guix without using local package manager tho <pkill9>abcdw: hmm not sure if I will actually, but mostly because I want a more stable operating system <pkill9>idk, i might not bother actually <jonsger>underdstandable. But I'm not sure if fedora is the right place for that. I often have a feeling that its the playground of RedHat, often with brave introduction of new tech... <rekado_>pkill9: more stable than Guix System? <rekado_>Fedora does not have system roll-backs <pkill9>hmm yea, there were also some other reasons but now I think about it, there are simpler solutions I think <pkill9>it's things like, cron jobs and writing services which are more complicated in guix <pkill9>but the simple solution is to run those things in userspace <pkill9>with some other program that makes it simpler <rekado_>pkill9: mcron does accept vixie cron syntax as well, it’s just not the preferred way to do things <rekado_>so you *can* do it the traditional way <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 <jonsger>maybe I should call it stable and broken <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. <vits>hello. today we run a build of bare-hurd.tmpl. __the message__ 'updating substitute' shown 102.2%. <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. <raghavgururajan>i also think that icecat may be missing a deoendency or the feature is disabled at build time for some reason. <atom`>raghavgururajan: I tried with safe-mode however I'm still getting errors :( <atom`>Isn't it strange if there is a missing dependency but it works in Chromium on the same system? <raghavgururajan>bandali, do you have any idea about atom` 's issue with U2F in IceCat? <jonsger>atom`: icecat has scripts who patching firefox all over, pretty agressive <bandali>raghavgururajan, i do not, off top of my head. atom` if there's a new issue, please report to bug-gnuzilla@gnu.ogr <bandali>i plan on putting in some work for icecat over the next few weeks, i'll see if i can find out more about the older bug you linked <bandali>i myself don't use u2f myself so it might be hard for me to debug it <atom`>I have successfully built IceCat using the Guix preview source (guix <atom`>build -S icecat) on a foreign GNU/Linux distro. Things I noticed: <bandali>if other folks have more information, please add it to that bug report and/or send a new one; thanks! <atom`>- When IceCat 68 is built from source on this foreign distro (without <atom`> using any software from Guix to do the build), the built IceCat 68 <atom`> works. The "Unknown U2F Error" does not occur. This means that the <atom`> system is configured correctly to allow me to use my security token, <atom`> and IceCat is built correctly to use it. <atom`>- However, on the same foreign distro, when I install IceCat 68 from <atom`> Guix, it doesn't work. I get an "Unknown U2F Error". <bandali>please don't paste long lines into irc <atom`>I will submit a bug report by the end of the week! <bandali>atom` thanks! or if it's very much the same issue, feel free to send a reply to that one <atom`>Currently compiling Firefox proper to check that it works there (my previous experience has been with Firefox on Gentoo). <atom`>bandali: Sure I will keep that in mind! <atom`>Thank you all for your advice! <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 <chaosmonk>yeah, i tried that last night and it did say it would use the substitute <lispmacs[work]>I don't have access to my email right now to submit a bug report, but I'm getting a failure trying to build python2-cairocffi <raghavgururajan>Is so. compare the `guix describe` output for root and regular user. <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 <nij>I'm a new user intending to try guix as a package manager (not the full OS yet..). Is there any repo that contains working examples (profiles, settings.. etc)? Thank you.. <apteryx>uh, 'guix build texlive-base' gives an output containing... nothing? <apteryx>ah, there's a comment in the sources: 'for use in package definitions only' <apteryx>it should probably be a hidden package, then <apteryx>hmm, no, that comment is for texlive-union <apteryx>ok, so texlive-base is a metapackage only propagating a set of default packages <apteryx>so it's normal it doesn't have an output of its own <dustyweb>what is with the world of programming these days <dustyweb>I'm making a package for embree (dependency on newer blender version) and halfway thorugh the compile it's used up 10GB already <dustyweb>last time I didn't pay attention, used up 15GB, my computer crashed :\ *dustyweb watches htop with intensity this time <dustyweb>"software is a gas and expands to fill all available space-time" <lfam>There isn't really any interesting configuration to speak of for this use case <dustyweb>oh, cmake is parallelizing a bunch of gcc I guess <lfam>You need to install it, set up the guix-daemon, and make sure to do the steps in Application Setup <nij>lfam: Thanks for sharing. Runnin `guix install hello` does work for me. <nij>What I hope is to have a file, similiar to NIX's configuration.nix, which lists a list of packages and versions I want. <nij>And the system (as a collection of packages) can be reproducible from that file that declaratively specifies it. <lfam>It works per-user, however. There's no concept of a "system level" for Guix on other distros <lfam>In order to reproduce a user's Guix packages, you'll need the manifest, and the output of `guix describe` <nij>lfam: thank you!!!! I will read about that :D <lfam>Great :) Please feel free to keep asking questions <nij>It must be somewhere.. but what's the difference between a manifest and a profile? <nij>I get that a manifest is basically a list of packages. <leoprikler>a profile is a directory, that actually contains all those packages <nij>(Another unrelated question.. if I want to use Guix not only as a package manager but the whole system, I have better first check that all of my hardware are "free", right?) <nij>leoprikler: I see! Thanks! <lfam>A manifest is the list of things you want, and a profile is what you actually get <lfam>It's the difference between a list of ingredients and a bowl of soup <nij>lfam: the name is quite weird. Sounds to me that they should exchange their name <nij>(haha but that's not the point.) <nij>After all, a profile sounds more like something to describe what the thing (manifest) is.. <leoprikler>Nah, manifests have always been boring text documents, so that checks out. <leoprikler>Concerning Guix on a foreign distro, your distro will likely bridge that gap for you most of the times. <leoprikler>The reason Guix system doesn't work all too well on unsupported hardware are the kernel and device drivers. <nij>leoprikler: Oh I might use the wrong term. By "using Guix as a system" I meant to use the GuixSD operating system. <leoprikler>Ah, yes, if you want to make the switch from foreign distro to Guix System, you will have to upgrade to supported hardware. <nij>Ok.. I will stick with the package manager first. <leoprikler>Note, "free hardware" is a subset of "hardware, that has free drivers". <leoprikler>For instance, the nouveau driver is free software, but nvidia certainly doesn't put out free hardware. <leoprikler>nij: If you're willing to experiment, you might be able to try linux-libre on your distro before switching to Guix. <nij>leoprikler: Yes I will try that. One step at a time :D <nij>manifest in M-W is either a noun or an adjective @@.. I'm looking at its noun form. <nij>In 1561, manifest as a noun meant manifestation. <nij>(anyway.. I will embrace how it's used here.. just a funny comment.) <leoprikler>(computing) A file containing metadata describing other files. <nij>Ah ha! Learnt a new word then :D <leoprikler>Granted, the word "profile" is probably inherited from nix tho, which likely inherited it from some big browser, that shall not be named. <leoprikler>I'm not sure if we should invent new terminology for that or just run with the metaphors that we're given by the ancients. <leoprikler>Tbf. the overload between "a place, where stuff is sold" and "a place,where items are stored" triggers me every time as well. <lfam>When are we going to install it on Berlin? :) <lfam>The full cbaines suite, that is. The data service and the build coordinator <cbaines>berlin would be nice, as it has so many cores, I'm just focusing on the software at the moment though <cbaines>I pushed some changes to the Guix Build Coordinator earlier today so it can better manage the number of builds it's running on a machine based on the load <lfam>It's been tough to make progress on the staging branch with Cuirass <lfam>I can see things building on GBC but not on Cuirass :/ <cbaines>I haven't looked in a little while, I did see some discussion of KDE things on staging though <cbaines>is the branch at the freeze/testing phase? <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 <cbaines>lfam, there's a section of the cuirass-howto in maintenance.git on retrying an evaluation, so I can try that... <lfam>Thanks, I appreciate it. I wonder if it will work... or why it has not been <cbaines>I've run: DELETE FROM checkouts WHERE evaluation = 20397; <cbaines>The UI has changed to show "In progress...", so maybe that's a good sign <cbaines>by the way, has anyone sorted out your access to berlin yet? <lfam>cbaines: I added myself to the list of sysadmins in maintenance.git but I don't believe the server has been reconfigured yet. At least, nobody has replied saying so <cbaines>I had a look previously, and the maintenance.git checkout on the machine is on a effectively unauthored revert commit <lfam>I figured it would take a while <cbaines>I guess I could cherry pick the commit where you added yourself, I'll try that <cbaines>lfam, you should be able to SSH to berlin now I think <estraw>Hey all, I have a question on packaging and conventions/etiquette <estraw>I'm trying to package something made in Rust that has a lot of dependencies, using the Cargo importer adds a lot more packages that are dependencies of the dependencies <estraw>Is it accepted practice to add each package in one commit, using the snippets? Or should I be squashing these <cbaines>one new package per commit is the convention <estraw>and if so, is there a format for the commit messages I should be using? <estraw>i was concerned about the large volume of patches needed but I guess that's what patch series are for lol <cbaines>particularly in the case where you find yourself adding a new version of a Rust thing, I'd check if any of the existing versions would work <cbaines>we've ended up in a situation where for some packages, Guix has many versions, and I'm not sure that's completely necessary <cbaines>no-username-3210, is the error correct, do you not have a guild binary on your $PATH? <lfam>Thanks cbaines! It's working <cbaines>lfam, great, I set you a password and left it in a file in your home directory <lfam>I was just noticing that <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 <slimjim>does guix patch out those tests then so they don't fail? <lfam>In any case, there are several thousands of Guix packages that depend on python, so changes to it go through the "core-updates" process, which takes several months <lfam>We can apply bug fixes in the meantime with a graft <cbaines>Updating and fixing things is always good, but I don't think this particular security issue is a risk to Guix users <atw>interesting, cbaines, is that thanks to how builders are configured? <cbaines>atw, at least on Linux, the guix-daemon uses a isolated network namespace when building derivations (except for fixed output derivations) <slimjim>thanks for the explanation cbaines, I think you're right that this mitigates the risk <slimjim>I was playing around with `guix lint -c cve` last night and there are several on python, that was the one that caught my eye <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` <alextee[m]>3.3.1 is actually fine, i need a feature introduced in 3.3.0 <lfam>You might help with testing the staging branch :) <lfam>`guix pull --branch=staging && do whatever you wanted to do` <lfam>Or use Git and ./pre-inst-env <lfam>The feedback would be valuable <alextee[m]>i want a stable system for now, don't have too much time to fiddle with this <alextee[m]>i'll install my version manually until the staging branch gets merged <apteryx>rekado: I'm trying to understand if it's possible to define a new latex format; in other words extend the list of formats 'built-in' our texlive-latex-base package? <alextee[m]>is there some kind of priority of what gets added to the path first when you have multiple packages with the same binary?