IRC channel logs


back to list of logs

<VesselWave>attila_lendvai: Thank you so much! I have been asking it too often
<redacted>Is it possible to reference my nginx configuration file from multiple places in my guix config?
<redacted>Similar to how (local-file "foo.txt") returns the path to /gnu/store/[hash]-foo.txt
<redacted>I think I don't grok how configuration blocks get turned into files, which might be why I'm confused on this point.
<vivien>redacted, you can run “sudo herd configuration nginx” to see the final file used by nginx
<lechner>rekado / fsf whitelisted my IP, but rsync is still asking for a password. does mumi use one?
<lechner>rekado / i'm mumi's biggest fan
<Kolev>Adding new user to system. Reconfigure takes a long time.
<porcupirate>Removing the offload machines from a system config and reconfiguring does not remove the machines file. I think there's a similar problem with substitutes, but I haven't checked.
<achow101>ok... now my problem is "no space left on device" when building a derivation, but 'df -h' says I'm nowhere near full
<achow101>oh i'm running out of inodes during the build
<rekado>Kolev: it will be fast when you use the same Guix as before. Check which guix you’re using.
<NewGuixUser>So I think I'm running into a certificate error when trying to build an old version of openssl to get python 3.8.5. Is there a better solution than just manually changing the system time?
<NewGuixUser>Well it looks like changing my system time worked
<rekado>NewGuixUser: is this the build or the tests that fail? You could disable the tests with a transformation.
<NewGuixUser>rekado: it was the tests. Everything has been running smoothly since, it's just taking awhile since this commit is old enough that everything needs to be bootstrapped
<jpoiret>yeah, some older versions of openssl have time bombs unfortunately
<jpoiret>if you're building openssl yourself, you can disable the tests, that might be easier
<adanska>anyone running Guix System with GNOME have hibernation working? I added the `resume` kernel argument but loginctl hibernate doesnt do anything. strace shows that its throwing some sort of error, but nothing comes out from stderr or stdout. see line 290
<rekado>it would be nice if “guix copy” could also manage remote profiles
<rekado>I deploy an application that has been built locally to a remote server with “guix copy”
<rekado>this copies all new store items to the remote, but it doesn’t operate on profiles
<rekado>I suppose I could then run “ssh remote -- guix install /gnu/store/…-the-new-thing” to update a remote profile
<rekado>but that’s a little inconvenient
<rekado>I’m looking for something between “guix copy” and “guix deploy”
<civodul>rekado: ‘guix package’ could operate over SSH similar to how ‘guix deploy’ does it
<sneek>Welcome back civodul, you have 2 messages!
<sneek>civodul, phf says: How to go from `#<gexp-input native #<origin "" #<content-hash sha256:1nfw5vbzcvqzpsahwxz7zjlshg31pa9f306g3hzm1kfx5rsyvry4> () 7f9c3ee0c900>:out>' to `/gnu/store/pgw9...-samovar-1.0.2.tar'
<sneek>civodul, rekado says: ran out of space while building tensorflow
<civodul>souds a bit tricky though
<civodul>another option is to run ‘guix publish’ on the build server
<phf>civodul: Hi: It's ok, I've figured it out.
<civodul>good :-)
<civodul>rekado: re ENOSPC, not sure what to do; can we make sure Tensorflow gets built with -g0 or similar?
<civodul>builds start iff there’s at least 5GB free
<gabber`>so i've (finally!) managed to get my raspi to boot into GRUB, but now i'm left at the GRUB REPL. any ideas on how i can get the system to boot?
<rekado>civodul: is -g0 to ensure there are no debugging symbols…?
<rekado>the two outputs of the tensorflow package are huge
<rekado>the “python” output is 700+MB because it contains a lot of libraries that are only necessary to finish the build of the python-tensorflow package
<rekado>“out” itself is 200+MB
<rekado>the source code and the vendored inputs both take up a lot of space, too.
<civodul>rekado: yes, if it’s C++, debugging symbols take a huge amount of space during the build, on /tmp
<civodul>so it looks like the whole thing (source + build result + build tree) may take close to 5GB right now
<civodul>in other news, pretty (relatively pretty) build logs:
<civodul>anyway, maybe i can adjust the GC thresholds on build machines, too
<civodul>ACTION -> lunch
<rekado>ooh, nice logs!
<viivien> :( “Builds for this patch series not yet submitted as master branch substitute availability is low for: i686-linux”
<civodul>rekado: the JS code for build logs was written *cough* by a junior intern, bear with them
<civodul>rekado: one of the build machines was quickly running out of space; i found it had lots of stale GC roots, which i’ve now removed
<civodul>it should be better now
<ennoausberlin>Hello guix. Is someone from the python team around? Any chances to pack torchaudio for guix? There is only binary on pypi but an github repository exists
<PotentialUser-47>Hi! I am having problems with emacs(-next): with version 30.0.50, org-roam doesn't work correctly: when I try to run 'org-roam-node-find', "Selecting deleted buffer" appears in the terminal. When I run 'emacs-30.0.50 --debug-init', it doesn't start correctly because of an error with org-roam/emacsql:
<PotentialUser-47>And Emacs 29.0.50 complains that 'seq--take' is undefined. I have no idea where this comes from. As far as I understand it, it should be 'seq-take' and part of Emacs.
<phf>Hello #guix! So, I've got enough code ( to have `./pre-inst-env guix build elixir-machete' to build, tests inlcuded of course (Elixir packages rarely include tests).
<phf>It's my first contribution to Guix beyond just a few packages. The contributing guide is quite extensive ( Is there a way to check my code for major issues before I spend time aligning with the guidelines in the Contributing guide?
<phf>It is also my first time writing Guile code.
<phf>I also have about 70 more Erlang and Elixir packages on the back burner, possibly enough to get Phoenix to build.
<nckhexen>gabber`: Which system?
<nckhexen>If it's a Guix system, and you've configured GRUB as its bootloader, it will have created a /boot/grub/grub.cfg. Find it (manually using ’ls’, or try an automated ‘search’) then load it with ‘configfile FILE’.
<nckhexen>I'm assuming this GRUB is healthy and not a rescue> prompt.
<gabber`>nckhexen: Raspberry 4 Model B (i've posted to help-guix@ a couple of minutes before but i guess my email hasn't been forwarded to the list yet)
<nckhexen>(Done, thanks for the hint.)
<gabber`>there is one grub.cfg in /efi/boot/arm64-efi/grub.cfg with only one line: "source efi/boot/grub.cfg" (which doesn't exist)
<nckhexen>I'm pretty sure it's /boot/grub/grub.cfg.
<nckhexen>Well, that was before I read the ‘image’ part, I'm not as familiar with those.
<nckhexen>Images: weird.
<gabber`>i'm sure it *should be* -- and that's probably the reason why it won't boot
<gabber`>but thanks, that's a good pointer to go after
<nckhexen>ACTION receives your mail.
<nckhexen>Well, maybe not, since this seems to be a Weird Boot Loader (…by my standards :) —
<gabber`>it definitely is: it touches pretty much all the boot-loading topics (U-Boot, EFI, GRUB, ...) which inspired me on writing a blog post on the topic
<gabber`>well, turns out /boot/grub/grub.cfg
<gabber`>is on the *other* partition (duh)
<nckhexen>Ah. Yes that partition is the worst.
<gabber`>... and we boot (manually, but still!)
<nckhexen>Should be ‘trivial’ to add a <the *other* other partition>/grub/grub.cfg that configfiles for you, to continue this trend of cursed chainloaders. Should.
<gabber`>i'm sure i'll find a way. as long as it boots automatically i'll be happy™
<mirai>what's the correct term for the kind of result obtained from a system-test?
<mirai>it returns a /gnu/store/… thing
<mirai>not exactly a gexp, I'd say it's whatever you get from building a gexp
<mirai>'derivation' ?
<civodul>derivation, yes
<civodul>though actually <system-test> records are “lowerable” (just like packages, operating systems, etc.)
<civodul>meaning you can insert them in a gexp
<mirai>oh, that's interesting
<mirai>I just finished posting to guix-devel about expressing dependencies between system-tests
<mirai>if they can be inserted within a gexp perhaps I can use it in the meantime for that
<gabber`>does #:hooks in efi-bootloader-chain refer to a simple lambda? or a lambda in a gexp?
<apteryx>can we lookup a package by its variable name? Or I must pray that variable name == package name ? I have this odd need to fix
<apteryx>(the user provides a list of dependencies as actual Guix code in the hall.scm file, and the generator of the guix.scm output should ideally add the correct #:use-modules for these dependencies itself.
<apteryx>I think it's this way to avoid requiring Guix libraries installed to generate such file; but I'm think to implement the feature conditionally when guix is available
<civodul>apteryx: one can traverse bindings exported by (gnu packages …) modules and get the variable/package mapping
<civodul>that’s what build-package-metadata.scm does for
<mirai>is (specifications->packages …) insufficient?
<apteryx>ah, I wasn't thinking about such an approach
<apteryx>mirai: yeah, that's what I was thinking to do, warning in case it fails
<apteryx>e.g. someone used a variable rust-something-4.3.2 but the package name is "rust-something".
<mirai>"name@version" ?
<civodul>apteryx: it’s definitely possible to obtain, given a package “spec”, its module name and variable name (if any)
<gabber`>nckhexen: your idea was to create a /grub/grub.cfg on the partition that grub already mounts as /, right?
<civodul>Hall should be able to generate the right ‘define-module’ stanza and refer to the right variables
<apteryx>actually I was thinking to use package-name->name+version and find-packages-by-name (this is what 'guix show' does)
<apteryx>civodul: the problem is that the input is not a "spec", it's a code
<apteryx>so the user would use actual guix variable bindings
<civodul>so Hall sees <package> values, right?
<apteryx>that's not a very good design, perhaps, but that's how it decouples hall from guix I guess
<apteryx>you have to give it the dependencies as in the old guix days: `((hello ,hello) ("guile-lib" ,guile-lib) ...)
<apteryx>in your hall.scm file, which must be read as data
<civodul>and then Hall just pastes that as-is in the generated guix.scm?
<apteryx>I assume so
<civodul>without depending on Guix, that’s the only thing it can do
<apteryx>and doesn't try to adjust the #:use-module list; it simly has a useful hard-coded template for it including guile and guile-xyz
<civodul>or it could download and process that
<civodul>if adding a dependency on Guix is acceptable, then it can get accurate data via the Guix APIs
<apteryx>yes; I'd like to try to autoload (gnu packages) and gather the package locations as a best effort
<apteryx>does that sound reasonable? it's the least invasive change I can think about, that should provide some benefits
<apteryx>perhaps I could also accept Guix package specifications in the hall.scm file when Guix was found
<apteryx>maybe in a new field would be cleaner
<apteryx>or similar
<apteryx>then I can error if that field is used if Guix is not available, and otherwise have guaranteed good results.
<civodul>that introduces a dependency of Hall on Guix
<civodul>whether that’s acceptable, i don’t know
<apteryx>it'd be optional; don't want it, don't use 'dependency-specs'
<civodul>but at least it would ensure that it generates valid code
<civodul>oh ok
<podiki>so I'm finally trying to use geiser, and my first try of M-. nothing happens :( or it freezes which I see guile doing something in the background, even after it completes nothing :(
<apteryx>did you build the project first?
<apteryx>civodul: thanks for the ideas
<podiki>apteryx: me? it was a built checkout of guix but doing a git pull and rebuild now anyway
<apteryx>podiki: yes. when there are lots of files to evaluate it becomes unresponsive
<apteryx>byte compiling everything should help
<podiki>it did finish eventually but still did nothing; let me see after a fresh build
<apteryx>Also, you need to start the REPL before navigating; Geiser warns about it
<podiki>yes, did that at least :)
<apteryx>I typically use C-c C-a to load the module I'm looking
<podiki>and on the topic, anything special that needs to be done for external channls and using geiser? for an external channel had some report needing to set geiser-binary to "guix repl" otherwise it was out of date guix? (investigating now)
<gabber`>podiki: geiser-add-to-load-path
<podiki>alright now it goes to the module at least in guix checkout when using M-.
<ekaitz>hi, in a cross-compilation to a different machine is there any way to jump inside a failed build dir and continue manually?
<ekaitz>with -K i can keep the directory but I don't see any comfortable way to jump in, in a virtualized container
<ekaitz>do you have a trick for this?
<apteryx>can I get the variable name of a package given its spec?
<apteryx>ekaitz: sourcing environment-variables there is not enough?
<ekaitz>it's empty in this case idk why
<podiki>gabber`: thanks, but didn't seem to be needed actually, works on my end...
<podiki>thanks all; seems a fresh build of guix checkout did the trick
<ekaitz>apteryx: also, even if it did, i don't think it would jump to the target arch
<podiki>though M-. only goes to the module when trying on a package name, is that expected?
<apteryx>ekaitz: cross compilation means building for a different target using a cross-compiler. sourcing '. environment-variables' should be enough to get the cross-compiler to work
<apteryx>(if I understand correctly what you are doing)
<ekaitz>apteryx: guix build X --system=riscv64-linux
<ekaitz>it's not cross
<apteryx>that's not cross-compilation; that's building natively on a riscv64 machine
<ekaitz>i just realized that when i said
<ekaitz>sorry for the wrong terminology
<ekaitz>any trick for this :)
<apteryx>np. in this case connecting to that remote riscv64 machine, going to the failed build and sourcing environment-variables should do it
<ekaitz>apteryx: but the remote machine is my machine in qemu
<apteryx>but you can't -K and offload at the same time (-K implies local), so you'll have to resort to GUIX_DAEMON_SOCKET=ssh://your-riscv-host ./pre-inst-env guix build package-x -K
<apteryx>so it's not remote :-) it's building via QEMU user emulation locally
<apteryx>then the failed build should be local, and sourcing . environment-variables should be enough
<apteryx>the rest will happen by the same binfmt registration magic
<ekaitz>`environment-variables` is empty
<apteryx>this you need to figure out why; does the build fail early?
<ekaitz>not really
<ekaitz>it's a bootstrapping thingie
<ekaitz>that might be the source of the problem
<ekaitz>but still, i'm building several dependencies and they go alright
<ekaitz>and i found the same thing in them too
<ekaitz>(when they didn't build right)
<ekaitz> <-- this is the package
<ekaitz>and it's failing in the build step
<apteryx>OK; sorry, I don't know
<ekaitz>np thank you
<apteryx>ACTION checks at importer to see how we generate package variable names for package objects
<apteryx>hm, in pypi: string->symbol
<apteryx>so we expect the package name to match 1:1 with its variable name
<ekaitz>apteryx: in packages with different versions that's not the case most of the times
<gabber`>how can i install a file in the efi part of my first MBR partition? i tried an mkdir-p which fails (permission denied)
<efraim>ekaitz: it might be a qemu bug. I can try building it on real hardware later
<apteryx>ekaitz: true. It seems the best mapping may be, even when guix is available
<ekaitz>efraim: can you try launch it please? if you clone the repo you just have to run this script
<efraim>I'm currently at a conference but I can get it started after I get back to my hotel tonight
<ekaitz>efraim: <3 thank you
<ekaitz>also, enjoy the conference
<ekaitz>don't go like running to the hotel to do this, it's not that important
<podiki>efraim: what's the latest on the rust-team branch, is that to be merged on a regular interval? (there's a patch to add rust-cbindgen-0.26 I was looking at, but then just saw a separate commit on rust-team already)
<efraim>Basically whenever I get around to it. I was hoping to be more active with it
<efraim>I didn't look at what commits I could cheerypick back to master
<podiki>efraim: needed for that non-icecat browser; I could cherry pick the rust-team branch; otherwise looks good to me (does an inherit for cbindgen 0.24)
<podiki>seems all inputs are same version but I can double check it builds
<podiki>any preference on the cherry-pick or the other patch that does an inherit for 0.24?
<efraim>I don't have a preference between the two, either way it should be deduplicated after rebasing the rust-team branch
<podiki>alright. i have 66729 already locally so I'll just do that after I double check. thanks!
<pastor>Hello. I'm packaging some dependencies for a package I want to contribute. One of the dependencies are the multiple crates from this repo:
<pastor>Te problem is that from this repo multiple crates are generated. Since I need a newer version I cannot use the old crates from
<pastor>How should I package this?
<pastor>I guess I should make multiple packages. On the origin reference is it possible to take only a subdir of the git repo?
<rekado>pastor: SVN was able to do this; git doesn’t let you do this.
<rrobin>don't know if you can include subdir in the origin, but worst case you can chdir on a phase
<rekado>so you’d define one package with that origin and add a phase to chdir
<rekado>then the other packages inherit the same origin and chdir elsewhere
<pastor>rekado: changing dir on one phase changes the dire for the subsecuent ones?
<rrobin>yes it changes for the following phases
<pastor>Alright. That sound acceptable enough. Btw I was wondering. For this package for now I'm having more that 2k lines of rust packages. Do I have to make all the packages compile? They seem to work when used in the `#:cargo-inputs` even if the don't compile individually. Many are from `guix import`
<pastor>rekado: If I do the chdir. How is it going to work for `#:cargo-inputs`? Won't the whole directory be inserted as a crate instead of a subdir?
<pastor>maybe I should replace the unpack phase and do some hacks leave only the sources I need?
<pastor>Ah no. They require dependencies from the other modules on the same repo...
<nckhexen>gabber: That is what I meant (so GRUB's $prefix, since it doesn't quite work the way a Unix system does, although it heavily borrows from its… aesthetics).
<nckhexen>I don't really understand your ‘insert a file in the efi part’ question.
<alxsim>Do you know if anyone is looking at packaging Typst?
<jackhill>Hi, I'm trying to run a python program (ansible) from a relocatable pack on CentOS 7. However, it prints this error instead of running "ERROR: Ansible could not initialize the preferred locale: unsupported locale setting" Thoughts?
<lechner>rekado / Hi, FSF whitelisted my IP, but rsync is still asking for a password. does mumi use one?
<philip>Could someone take a look at nghttp2 ( I don't feel like I know what I'm doing with grafting, especially, so the patch may be completely wrong, but I thought someone should address CVE-2023-44487.
<podiki>philip: that's the right idea from my quick look, though probably a name like nghttp2/fixed is more conventional (but not fully established)
<podiki>philip: I assume you tested that it builds? and for abi compatibility/running a dependent that gets the graft?
<podiki>philip: since such a version change might indicated other changes (in build, in usage)
<podiki>"guix repl" use guix and guix's package definitions from the current user (i.e. latest guix pull version) right? while GUILE_LOAD_PATH is for the current system configuration?
<podiki>trying to set GUILE_LOAD_PATH to be e.g. a guix checkout doesn't change anything? i'm confused
<podiki>confused over how guix's modules are loaded by guile in general, I'm missing something
<mekeor>podiki: perhaps missing %load-path variable?
<mekeor>(and perhaps %load-compiled)
<podiki>ah figured it out, you need both GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH
<podiki>i just assumed (yes yes, we know what happens) that the compiled path was just for speed but I guess not?
<podiki>...or not. i'm confused over what is working or not here :|
<podiki>ignore the comment about compiled path, i think it is just to use compiled stuff; some other thing over here....ignore me now :)
<mekeor>wtf, i have a local package declaration, which gets its source from, which now requires me to log-in in order to access the source!
<mekeor>i wonder if this breaks the process of building (more precisely, downloading) packages for cuirass-instances like and bordeaux.~
<nckhexen>If the source isn't substitutable or mirrored, then yes.
<mekeor>i.e. is a very bad source-source?
<podiki>i think my conclusion was that you should extend GUILE_LOAD_PATH don't just replace it, as there are some bits in the system's profile you miss out on
<podiki>and you get "no code for module" errors
<podiki>gitlab should be fine, but maybe the repo went private?
<nckhexen>mekeor: Uh, you lost me there. Why would that be?
<nckhexen>I mean: what's so special about
<mekeor>nckhexen: let me tell you my story. have a local (package ... (url "")). try `guix install it`. get an error that it can't be downloaded. try to open url in the browser, which states: " needs to review the security of your connection before proceeding. Please unblock to proceed."
<mekeor>i never experienced or to require a log-in to access code.
<nckhexen>Whoakay. I thought you meant the repo had gone private.
<podiki>ah, cloudflare
<nckhexen>GitHub rate-limits things (‘guix refresh’ has a whole code path to deal with this) but I don't think it limits clones, although I wonder if it will if it thinks you're ‘suspicious’.
<mekeor>well, i'm not sure if this is relevant, but after logging in, i saw that the repo had been deleted (and moved to
<nckhexen>The C in Cloudflare stands for cancer.
<Lumine>mekeor: maybe cloudflare is being a clown
<nckhexen>mekeor: Oh.
<jaeme>Which package provides the ~uname~ program?
<podiki>i've seen the cloudflare for gitlab in the browser but never saw an issue with a git checkout
<nckhexen>mekeor: GitLab's way to 404 is to prompt for a log-in.
<podiki>jaeme: guix locate tells me bash and coreutls
<nckhexen>I think it's well-intentioned, to prevent information leaks in some (edge) cases, but it's confusing.
<nckhexen>Yes, it's coreutils.
<nckhexen>(Bash? No… Maybe some union package?)
<mekeor>for me, it's /gnu/store/yr39rh6wihd1wv6gzf7w4w687dwzf3vb-coreutils-9.1/bin/uname
<mekeor>feel invited to share your coreutils' hash
<jaeme>Its in coreutils yay
<mekeor>and yes, /gnu/store/…-bash-5.1.16/lib/bash/uname exists -- under /lib!
<jaeme>Should I include the nss-certs package as an input?
<podiki>guix locate doesn't lie then :)
<mekeor>jaeme: input to what?
<podiki>ACTION goes to run, literally, after too much confusion over guile load paths...
<jaeme>Its patch 66694
<nckhexen>Damn it, I *knew* about that lib uname, but I forgot >:(
<jaeme>I'm revising it with gexps
<jaeme>mekeor: I want to be able to enter a pure guix shell with working ani-cli
<nckhexen>jaeme: No, it should be provided by the OS, it's a bit of a special case (maybe? depends on your perspective) in that regard.
<mekeor>jaeme: do not put nss-certs in inputs
<nckhexen>It's fine to add it for your own convenience but saying that it ’should’ be there is false.
<nckhexen>(So remove it when you submit it upstream.)
<mekeor>yeah, imagine a user of ani-cli watches only animes from a server that does not require https
<jaeme>Ok, thanks for clarifying
<nckhexen>I think the best argument/logic here is that certs are a ‘state of the world’ thing, like timezones, which shouldn't be locked in functionally as if they were software.
<nckhexen>There's also the argument that users/admins should easily be able to untrust them.
<nckhexen>There have been some dodgy certs in nss-certs. These are eventually removed but it can take time.
<Kolev>I get a weird message, trying to use Mosh.
<jaeme>nckhexen: Interesting. I'll def keep note of that.
<jaeme>Where should I place ani-cli in videos.scm?
<futurile>evening Guixers
<jaeme>videos.scm is not ordered alphabetically
<nckhexen>jaeme: At the top, then :)
<jaeme>Correction: *video.scm
<jaeme>nckhexen: okie dokie.
<nckhexen>I put new packages above the first package that would come after it alphabetically. Which sounds more complicated than it is.
<jaeme>If I import more modules for the packages, how should I declare that in the commit changelog
<jaeme>I add (gnu packages bittorrent) etc to the #:use-module chain
<nckhexen>They aren't mentioned.
<jaeme>How about updating the copyright header?
<nckhexen>Also nope. Hey now! Don't get the wrong idea! Our changelogs *are* pedantic! Promise!
<nckhexen>In general, unless the entire commit is only about fixing/modifying/… a comment, I don't mention comment changes at all.
<jaeme>Okay I submitted my revised patch to debbugs, this is a lot of fun lol.
<jaeme>I can't believe anime was one of my first patches smh
<nckhexen>I think my first-ever patch to Nix was enabling the insults to sudo 🤷
<mekeor>jaeme: i love it :) i'm looking forward to try ani-cli :)
<mekeor>nckhexen: insults to sudo?
<nckhexen>Most of them aren't even good.
<nckhexen>Oh well.
<mekeor>ACTION needs to try out `guix publish` in order to use the performant work-computer to build packages for the personal-computer; in particular emacs-yaml somehow needs ages to build
<Kolev>Guix frustrates me. `guix pull` takes forever, for example.
<mekeor>nckhexen: guix does not ship sudo with insults, right?
<nckhexen>I don't think so.
<nckhexen>In fact I'm quite certain.
<mekeor>Kolev: i agree. guile and guix need performance improvements.
<mekeor>ACTION wasn't expecting sudo to have a very active recent commit history
<rekado>Kolev: are you using channel-with-substitutes-available?
<Kolev>rekado, I have substitutes enabled, if that's what you mean.
<rekado>no, I’m asking about channel-with-substitutes-available in your channels file
<rekado>because that will only pull guix up to a point that has successfully been built on the substitute servers
<rekado>so you don’t need to compile any of the “guix pull” derivations locally
<rekado>all the work that then remains is to compute the initial derivation (that’s a little slow) and to download substitutes
<mekeor>here's an exemplary channels.scm with channel-with-substitutes-available:
<mekeor>(although it's more verbose than needed, since %guix-default-channel or so exists)
<nckhexen>mekeor: I update sudo several times a year, unfortunately this has included security updates.
<nckhexen>ACTION is reminded that opensmtpd was updated, so thanks, indirectly.
<mekeor>nckhexen: perhaps try guix package -i sudo --with-configure-flag=sudo=--with-all-insults etc
<nckhexen>Thanks, but for…?
<mekeor>nckhexen: if you want sudo to insult you
<nckhexen>Ah, thanks :) I already use a custom sudo package.
<mekeor>nckhexen: oh, why? security improvements? :D
<gabber>may i propose sudo-with-insults (or should it rather be named insulting-sudo?)
<mekeor>gabber: or should it be another output of the sudo package?
<nckhexen>It's a different build, so can't be an output. Also, it would suffer the same fate as fortune-mod, a long ML thread followed by reversion.
<gabber>is that worth the read?
<nckhexen>IMO no.
<nckhexen>mekeor: Don't worry, I'm not hoarding sekrit security fixes for myself. It's mainly historical, and I could probably do without it, but I used it to enable the Python integration which I played with for a while.
<mekeor>maybe that thread would satisfy the need to be insulted
<gabber>is the winning argument GNU communication standards being against humor (i'm about 30% kidding, i actually like that standard)
<civodul>any Home user here? we desperately need active reviewers on the ‘home’ team
<Altadil>civodul: do you mean the guix home command ?
<Altadil>I do use it (more than guix install actually), so I there is a need for testing I can help (but I lack the experience for actual package review :(
<civodul>one can learn :-)
<civodul>i was looking at
<civodul>i think we need fixed-term mandates on teams, it cannot work if membership is sloppy
<nckhexen>Not just teams.
<rekado>oh, that’s a nice service! Just today I was wondering whether we have one.
<civodul>aah, see? :-)
<civodul>nckhexen: yup!
<civodul>two candidates on the ‘home’ team in 5mn, not bad :-)
<gabber>not super keen on the home-team membership (or review that patch in particular), but have i never sent my patches to create an audio team (and add my self to that)?
<Altadil>civodul: yes, I am actually in the learning process for packaging (well rather I should get back to it when I have some time ^.^) . I’ll keep in mind that there are teams in need of reviewers. Is there a way to see which are understaffed ? I guess just the number of members is not a good indicator.
<gabber>ACTION can't find a hint of these patches on issues.g.g.o so they'll rebase and send'em
<civodul>Altadil: the numbers and the actual activity reviewing patches in the team’s scope
<civodul>gabber: if even you don’t know whether you’re on a team, we have a problem :-)
<civodul>apparently there’s no audio team et
<gabber>i knew i was not on the team (since i checked the sources) but i was at least 30% sure (yes, that's a lot) that i sent the patches (since i had crafted them -- and mentioned them to somebody somewhere?)
<Altadil>civodul: thanks. I can’t do much now, but I’ll remember to check that once I’m more able.
<apteryx>civodul: seems in latest version of hall, you can declare dependency on guix via (features '((guix #t) ...)) in the hall.scm spec file
<podiki>speaking of teams, I need to create one for mesa and friends. graphics?
<civodul>sounds like a good name for that
<gabber>is tonight the night ... where we all create and join new teams?
<gabber>ACTION is excited
<podiki>the tricky thing is scope, maybe we can see about extending the teams code to take a list of packages? and then anything touching those or dependents of could be cc'ed in git send-email? (maybe too tricky?)
<podiki>ACTION also needs to send an email about a mesa-updates branch and start cranking on that
<gabber>nckhexen: did you need much more system configuration magic to replace the %base-packages sudo with your custom one? more than adding your package to the config and to setuid-programs?
<nckhexen>gabber: No magic. I just added sudo/nckx to my list of privileged-programs (my equivalent to setuid-programs), didn't bother adding it to packages because the man page/bash completion is functionally identical.
<gabber>and you also didn't remove it from the system's %base-packages? which works because in $PATH your personal profile comes before the system's?