IRC channel logs


back to list of logs

<maximed>tribals: put the , before the (string-append: #~`(,(string-append foo bar ...) other things ...)
<maximed>`, is a no-op
<maximed>(like unmatched-paren writes)
<maximed>with #~`,((string-append ...) ...), you're trying to somehow use the result of string-append as a procedure
<maximed> While it's great to have a system for not having to update everything at once when doing an incompatible update of a dependency, you often don't have to do that, please don't do 29 different incompatible 0.XX releases and forget to update dependents to the new API
<maximed>18 done, 27 to do (some of which require changes to source code for new dependencies)
***yewscion is now known as yewscion-away-g
***yewscion-away-g is now known as yewscion
<fnstudio>hm... i've tried using guix system like this: guix system image -L . -e "(use-modules (my-oses)) my-base-os" but it doesn't work: error: '(use-modules (my-oses)) my-os' does not return an operating system or an image
<fnstudio>if i try the exact same code in a file and run: guix system image -L file.scm, then that works
<fnstudio>am i misunderstanding the way -e (--expression) should be used?
***yewscion is now known as yewscion-away-g
<patched[m]>Is it possible to build a package without checking the hash? I'd like to skip this for definitions of local packages.
<polyex>heya when is 1.4 out? thanks
<nckx>Hopefully sometime this summer, but there is no clear timeline yet.
<polyex>i tell everyone about guix. it's the best OS
<polyex>no other way to manage all the complexity of computers
<PotentialUser-90>I'm curious to use Guix on Triskel (KDE) 10, but I heard there were issues (see here: Do you know if it's been resolved, or that I have to do anything special to get Guix to run with KDE?
<nckx>PotentialUser-90: Take this with a grain of salt as I'm not a KDE user, but I don't think KDE packaging or integration in Guix have changed significantly in quite a while. So whatever was true then is probably still true now. There simply aren't (m?)any KDE users that contribute to Guix. Chicken & egg & all that.
<PotentialUser-90>That's helpful to know, thanks. What DE do you use?
<nckx>PotentialUser-90: Sway (the Wayland clone of i3). Not ‘really’ a DE, the nitpickers would say.
<nckx>I spend 97% of my time in a terminal, emacs, or Web browser so the E would only get in the way.
<singpolyma>nckx: better than a DE. But still Wayland so only partly better ;)
<nckx>PotentialUser-90: That's just my preference though, not a Guix limitation. Quite a few Guixers use GNOME. We're just biased towards one of the big 2, for now, unfortunately.
<nckx>singpolyma: I dread to ask what would be better…
<singpolyma>nckx: well, if you like sway then probably i3
<nckx>Ah, downgrade.
<nckx>Used i3 for years; config-file compatibility was a nice touch I'll admit.
*nckx ~> AFK, perchance to dream, but maybe not.
<PotentialUser-90>nckx: I appreciate the help. I like shiny looking things so KDE works for my purposes, but I was interested in it's approach to packages and apps not included in the Trisquel repos. I'm a casual user who mostly just needs browsers, mail and office stuff. Thx
***yewscion-away-g is now known as yewscion
<vagrantc>does python-build-system not support #:parallel-build? #f ... ?
<vagrantc>i get Unrecognized keyword: #:parallel-build? ... when adding it to the patchwork package definition
***yewscion is now known as yewscion-away-g
***yewscion-away-g is now known as yewscion
<apteryx>vagrantc: it doesn't
<vagrantc>ok, that explains it :)
***yewscion is now known as Guest1478
***yewscion is now known as yewscion-away-_g
<raguay>How would I install guix on Parrells for Mac on a M1 chipset?
<efraim>hello guix!
<unmatched-paren>raguay: i don't believe it would currently work, unless you're talking about asahi? even then i doubt it would function.
<raguay>Does anyone know how to install guix on Parrells for Mac on a M1 chipset?
<unmatched-paren>raguay: see above
<unmatched-paren>not sure what parrells is though
<unmatched-paren>aha, it's a VM, sorry
<raguay>Yea, it's the faster VM on MacOS.
<unmatched-paren>looks like a VM for running windows...? at least that's what they're marketing it as
<unmatched-paren>i think you should just use qemu probably
<raguay>I've looked all over the guix website and haven't found anything. The qemu build is still Intel chip only. I'm using an M1 chip system.
<unmatched-paren>raguay: you could use that in x64 qemu, though, couldn't you?
<unmatched-paren>i don't think guix system will work on m1 arm
<raguay>No, the vm have to have the same architecture. The site says it supports that chipset, but doesn't tell how.
<unmatched-paren>raguay: it supports aarch64, but likely not the M1 version of aarch64. i don't think any linux distros run on M1 except for asahi. you found the archs here, right?
<unmatched-paren>no, sorry
<unmatched-paren>where did you find that it supports M1?
<raguay>I thought that aarch64 am M1 was the same.
<unmatched-paren>raguay: there's major differences i think
<unmatched-paren>so much so that there's a whole Linux distro project working to get linux running on m1
<unmatched-paren>The developers quickly realised that just attempting to boot the Linux kernel compiled for Apple silicon's processor architecture (AArch64) would be challenging, as it involved working out the functionality of proprietary Apple code used in the boot process. The work was time consuming and took most of the year, including submitting pull requests to the main Linux kernel developers to keep development in sync and avoid regressions. However, i
<unmatched-paren>t subsequently led to a thorough and comprehensive explanation of the previously undocumented boot process, which Martin and others published on GitHub.[2]
<unmatched-paren>see, there's a lot of differences from your average aarch64 board
<unmatched-paren>the GPU doesn't work either (yet)
*unmatched-paren afk
<civodul>Hello Guix!
<raguay>Is it possilble to add on top of my existing Ubuntu for M1?
<PurpleSym>Hm, is the recursive importer not inserting any blank lines between the packages for me only any more?
<pranavats>Is there any effort to package Web Assembly software for guix? Like, are there packages for wabt or binaryen somewhere?
<pranavats>Oh well, wabt is in Guix. Nevermind.
<jpoiret>fnstudio: a bit late, but -e expects one statement only, so you should wrap that with a begin
<jpoiret>or directly use (@ (my-module) my-os)
<fnstudio>hey jpoiret, not late at all, i was just about giving this another try now
<fnstudio>thank you very very much
<fnstudio>it works like a charm :)
<nikola_>Hello, I'm new to guix and i was just playing around with it in a VM
<nikola_>Now I'm thinking about installing it to real hardware
<nikola_>Are there any resources like tutorials to help me learn the proper way to manage the system
<fnstudio>nikola_: did you have the chance to look at the official docs?
<ardon>Hi Guix, I'm constantly getting this error "[GSSH ERROR] Channel opening failure: channel 67 error (2) open failed" when invoking `guix deploy'. As I pointed out a few days ago, if I re-run the command a few times it will eventually go through, but it's quite annoying. I should also add that when this happens I notice sshd-PID processes popping up in `herd status'. Has anyone else experienced this or know what might be the root of the
<fnstudio>nikola_: i think that's a good place to start, e.g.
<nikola_>Yes i have, i do have a few questions though
<nikola_>For example, am i supposed to update guix separately for each user (my own and root)
<voroskoi>i set up the user version to guix-daemon
<voroskoi>so i do not bother with root
<fnstudio>nikola_: (disclaimer: i'm not an expert) i think there can be packages installed globally and those only need to be updated once - but individual users may have additional packages installed in their paths and those will have to be updated separately
<nikola_>voroskoi: how would you do that
<nikola_>Also i have a Ryzen CPU with Vega graphics and an Intel wifi chip, what kind of support can i expect for them
<jpoiret>you do not need to update root's guix
<jpoiret>as long as you use sudo, you can use your own user's guix, but with root privileges
<jpoiret>basically, the workflow would be: `guix pull` to update your copy of the Guix software (in the ~/.config/guix/current/ profile), `sudo guix system reconfigure /path/to/config.scm` to update your system generation with your new Guix copy, and `guix package -u` to update your user-installed packages (in the ~/.guix-profile/ profile)
<jpoiret>steps 2 and 3 are independent and can be swapped
<jpoiret>or you could do one but not the other (although there might be issues if eg we update the glibc)
<nikola_>Thanks that's useful to know
<nikola_>I just don't need to worry about root's guix
<jpoiret>yep (and it might not have one, if you've never ran guix pull as root
<nikola_>Are there known issues with guix and ryzen and Vega though
<jpoiret>check out if your card requires a proprietary blob here:
<jpoiret>although it might not include everything
<jpoiret>guix uses the linux-libre kernel, that removes proprietary blobs and the ability to load them
<jpoiret>although you can easily switch which kernel you're using, but the Guix proper only provides support for linux-libre
***CodeKiwi is now known as DigitalKiwi
***wielaard is now known as mjw
<johnjaye>unmatched-paren: the vm reconfigure command froze again
<johnjaye>i'll try one more time then maybe switch to qemu or hardware.
<johnjaye>worst case scenario i can just use the install as is?
<johnjaye>ok the gpg sig checks out. so it's not the downloaded file i think
<nikola_>Has anyone written a runit service for the daemon
<pranavats>jpoiret: I wonder what the status of your patch for grub2 is. The one fixing support for luks2.
<jpoiret>pranavats: it's been reviewed twice (my c skills are terrible), but now there's a clearer picture of what we're going to do
<jpoiret>basically, there is another patchset that does something similar (but not totally), and we're going to adapt them to keep the best of each
<pranavats>jpoiret: I have the old patchset applied in my config. Where can I keep track.of this issue?
<jpoiret> should keep you updated
***GNUcifer is now known as cehteh
<apteryx>nckx mothacehe efraim moin!
<apteryx>it's the 2nd Tuesday of the month ;-)
<apteryx>1st, even
<mothacehe>apteryx: hey! present :)
<apteryx>OK :-)
<apteryx>efraim: are you able to attend?
<efraim>Wait, today?
<apteryx>if you can, it's now :-)
<efraim>Oh, right. I'll be there in a minute
<nikola`>I have a question
<nikola`>I installed guix on my artix installation
<jonsger[m]>ask it :)
<nikola`>And it seems to prepend path with it's own path
<nikola`>That is, when i try to use GCC it's always guix gcc
<nikola`>And not the system gcc
<nikola`>Is there a way for that to not happen
<rchar01>after: guix system delete-generations
<rchar01>I have an error:
<rchar01>guix system: error: symlink: Permission denied: "//var/guix/gcroots/"
<rchar01>Any ideas?
<ulfvonbelow>nikola`: I assume you refer specifically to your user profile (~/.guix-profile) and your 'guix pull' checkout (~/.config/guix/current)? You'll probably want to keep guix itself pretty early in the search order, but the user profile you could probably move farther back. The ideal solution would be to have your profile generated such that ~/.guix-profile/etc/profile appends rather than prepends, but I'm not sure how to do that.
<nikola`>The script /etc/profile.d/ always prepends the guix path
<DynastyMic>Greetings, I want to download Allegro CL on Guix, however I run on the following error:
<nikola`>So when i move it out of profile.d i get my normal config
<DynastyMic>~/guix-packages/acl10.1express.64 $ ./allegro-express
<DynastyMic>/gnu/store/lnni4nl00jin1kp766ksb933dlpr7zr7-emacs-27.1/bin/emacs: /home/ivan/guix-packages/acl10.1express.64/allegro-express: No such file or directory
<nikola`>ulfvonbelow ^
<ulfvonbelow>it'll be a little slower than sourcing the profile, but you could change /etc/profile.d/ to instead use 'eval "$(guix package --search-paths=append -p ~/.guix-profile)"'
<nikola`>What does that do
<DynastyMic>Isn't it possible on guix to just decompress the installation and run with ./ ?
<nikola`>Should i just manually source when i need it
<nikola`>I have to start the daemon manually anyway
<ulfvonbelow>'guix package --search-paths -p <profile>' emits the environment variables that profile defines. --search-paths takes an optional parameter (one of 'exact', 'prefix', or 'suffix') that indicates where in the search paths those environment variables should go
<ulfvonbelow>"exact" replaces the search paths altogether, "prefix" puts guix directories at the front of the search order, and "suffix" puts guix directories at the end of the search order
<nikola`>Is it ok if I manually source when i need it
<nikola`>We'll see then :)
<rchar01>guix system: error: symlink: Permission denied: "//var/guix/gcroots/"
<rchar01>any ideas how can i solve it?
<ulfvonbelow>I assume you've tried running as root?
<ulfvonbelow>system-wide actions typically require root access
<ulfvonbelow>and (re)installing a bootloader definitely sounds like a system-wide action
<rchar01>it is an error after guix system delete-generations
<rchar01>is it sth wrong with deleting generations?
<ulfvonbelow>when you say an error "after" guix system delete-generations, do you mean that the error message shows up after you press enter to run 'guix system delete-generations', or that after you ran it the first time, the error now shows up no matter what you try to do with 'guix system'?
<ulfvonbelow>I'd say try to run 'sudo guix system delete-generations'
<rchar01>after running the command: guix system delete-generations
<avalenn>I am trying to use guix home and to managed directories like explained in but I have "Unrecognized keyword: #:recursive" error
<avalenn>my bad, I forgot the "?" at "#:recursive?"
<civodul>heh :-)
<rchar01>thx, sudo helped
<rchar01>another question
<rchar01>What is the purpose of guix pull and guix upgrade, should I run both to upgrade the system (get the latest packages)?
<ulfvonbelow>generally speaking, 'guix pull' gets updated package definitions (as well as an updated guix), while 'guix upgrade' replaces your user profile (~/.guix-profile) with one populated using the newly-obtained package definitions.
<ulfvonbelow>I'd recommend visiting the manual (run 'info guix')
<civodul>rchar01: "guix pull" updates the list of available packages, whereas "guix upgrade" actually upgrades those that are installed; see
<civodul>yeah, what ulfvonbelow wrote :-)
<rchar01>I found everything in the manual, thanks again. :-)
<reza[m]>hi guix
<reza[m]>is there a way to resolve symbolic links in guile? like readlink does in bash?
<civodul>reza[m]: yes, it's called 'readlink' too :-)
<civodul>as in: (readlink "/bin/sh")
<reza[m]>ah nice, can I use it to get the real paths of files in a go build?
<ulfvonbelow>and if you want "readlink -f", I believe that's 'canonicalize-path'
<reza[m]>I try to package this go module: here
<reza[m]>but itis using `//go:embed` to embed files into the source which does not accept symbolic links, how do I circumvent this?
<reza[m]>I tried to use `canonicalize-path` but this does not seem to work
<reza[m]>I have to somehow copy the files in into the build source
<abrenon>hi guix
<ekaitz>hi all
<ekaitz>with the new input definition based on lists, how can I choose an input from a package making sure I chose the right one
<ekaitz>imagine the case of a package that has an input that is (cross-libc triplet), how can I differentiate that from the libc that comes with the gcc toolchain?
<abrenon>I don't think it changes something on the selection, since the list contains the values themselves, not their name
<ulfvonbelow>you could use 'define' or 'let' to bind the result of cross-libc, then evaluate it both in the input list and in the gexp.
<abrenon>but anyway, I think the new system still accepts the old assoc list form, doesn't it ?
<ulfvonbelow>although it should also work to evaluate cross-libc twice with identical arguments
<ekaitz>hm ok
<ekaitz>so they are directly obtained from the name of the package so for my case it's probably better to re-evaluate
<sneek>Welcome back vagrantc!
<ekaitz>did anyone find errors with `cross-base`
<ekaitz>it's giving me weird errors to use it
<ekaitz>in projects that didn't have them (I tried to time-machine and they work in the past)
<ekaitz> this thing
<ekaitz>looks like the commit b55310603f0df7d5ae02d47cb8d4be58bf1d41ca is weird
<Guest2477>hello guys, why did the guix, which is a free distribution, restrict access to the site and repositories with ru ip? I can't open the website and install the system
<vagrantc>Guest2477: it may be some point in between guix's hosted services, it was not a decision of guix
<Guest2477>got it, I'll try hard to install the system via vpn, thanks for the answer. I hope the problem gets resolved
<abrenon>ekaitz: what do you mean ? what's weird about this commit ?
<ekaitz>abrenon: well, literally that it broke cross-base for me
<abrenon>ok, sorry, I thought you meant something in the diff itself looked suspicious
<ekaitz>abrenon: i'm porting stuff for riscv so i need to (cross-libc "riscv...") a lot and I don't know how but I'm pretty sure that commit broke the cross-base but I can't really explain why
<ekaitz>abrenon: I mean, the commit is legit, but there's something weird there that it's breaking :(
<Guest2477>vagrantc Thanks a lot for your help, I understand now
<vagrantc>Guest2477: in a follow-up, seems like some ip blocks were banned due to attacks on the hosting provider
<vagrantc>Guest2477: there's a mirror in china that might be accessible too ... don't have the URL handy
<abrenon>I'm afraid I won't be of much help in that area, sorry : /
<Guest2477>vagrantc I realized, I tried to install the system for an hour by passing traffic through TOR, but since it often changes bridges, this causes short-term Internet outages and an installation error, I will try to try through VPN
<vagrantc>Guest2477: good luck!
<mitchell>Hello guix. I have a set of patches I would like to contribute. Can someone help me review them, I've never done this before
<jpoiret>mitchell: have you looked at the "Submitting Patches" part of the manual?
<vagrantc>mitchell: i've had ok-ish luck posting links to proposed patches here for really rough work-in-progress review
<mitchell>jpoiret: Yes, I built several times and ran them through the linter. Now i have 4 patchs but I'm not sure what to do with them or how to arrange them
<mitchell>vagrantc: any review would be appreciated. How do I do this?
<jpoiret>for sending, i recommend reading
<vagrantc>mitchell: try posting the first patch to and post the link here
<vagrantc>mitchell: use the full commit hash, not a short one
<mitchell>I wonder if its possible to add a rule for that in guix lint
<vagrantc>and then there is (version (git-version "1.2.3" revision commit))
<vagrantc>mitchell: you'll also want to have in the commit something like * gnu/packages/fpga.scm (abc): ... describing the changes
<vagrantc>mitchell: see other commits for examples
<maximed>mitchell: Replace 'rev' by 'revision'
<maximed>"guix refresh -u" knowns about 'revision' but does not recognise 'rev'
<lechner>Hi, why do #55762 and #55763 not show up in (or perhaps in but only in please?
<maximed>(will be important for the not-yet-compleded 'git-generic' updater, also currently important for Minetest mod packages on ContentDB)
<vagrantc>lechner: are they bug-guix ?
<maximed>mitchell: #:f is the keyword #:f, which will be interpreted as if it was #true, write #false instead
<lechner>vagrantc: Hi, i'm not sure what that means. I sent them to guix-patches
<vagrantc>lechner: if you sent to ... but sounds like you didn't
<mitchell>maximed: right... thank you
<maximed>mitchell: propagation is suboptimal for $various_reasons and can often be avoided by adding a phase that replaces an invocation of a program by the absolute path (try a combination of 'substitute*' and 'search-input-file')
<lechner>vagrantc: Should they have gone there instead?
<vagrantc>lechner: no, sorry for the red herring
<maximed>vagrant: There is a simpler way of setting the make flags:
<maximed>(arguments (list #:tests? #false #:make-flags #~(list (string-append "PREFIX=" #$output)) #:phases #~(modify-phases ...)))
<vagrantc>maximed: this is in regards to?
<maximed>(probably no need to replace the 'install')
<maximed>*vagrant -> mitchell
<lechner>vagrantc: that's okay. i'll talk to you!
<maximed>Though I'm not sure if the default install phase respects #:make-flags, maybe that's only for the build ĥase, so maybe not.
<vagrantc>lechner: are the pages paginated?
<mitchell>/maximed: There was a reason, but its been a while now so i've forgotten
<maximed>mitchell: the indentation of modify-phases (for symbiyosys) is non-standard -- "./pre-inst-env guix style symbiyosys" should fix that
<mitchell>I'll test it
<lechner>vagrantc: wow, they are!
<lechner>i've had more than 400 bugs in my packages
<maximed>mitchell: (for symbiyosys): the makefile runs "gcc" to compile things. However, when cross-compiling (with guix build --target), the cross-compiler TARGET-gcc is required (where TARGET=aarch64-linux-gnu or such)
<vagrantc>lechner: also works
<lechner>vagrantc: yeah, thanks! sorry, i have poor eyesight and thick glasses
<mitchell>maximed: So i need to conditionally replace gcc by the cross compiler?
<maximed>That could be fixed with #~(modify-phases ... (add-after 'unpack 'fix-cross-compilation (lambda _ (substitute* "Makefile" (("\\bgcc\\b") #$(cc-for-target)))))))
<maximed>mitchell: If you use cc-for-target, you can make the replacement unconditional
<mitchell>maximed: oh i see. I guess i just assumed the build system would handle details like that
<maximed>#$(cc-for-target) -> TARGET-gcc when cross-compiling, #$(cc-for-target) -> gcc when compiling natively
<maximed>mitchell: Some build systems take care of such details (e.g. meson-build-system)
<maximed>However, no (guix) build system automatically patches makefiles
<mitchell>maximed: Is there a reason that "gcc" isn't always pointing to cc-for-target?
<mitchell>i guess it may not always be gcc
<maximed>mitchell: Because sometimes a native compiler is required even when the package is cross-compiled
<maximed>some packages first compile a tool (natively, not cross-compiled) to generate ‘source’ code, and then compile the ‘source’ code with the cross-compiler
<vagrantc>lechner: i can relate to subtle differences between and too :)
<maximed>mitchell: cc-for-target currently assumes "gcc" or "target-gcc" (it never uses clang)
<maximed>Could be extended though, see
<johnjaye>about how long should a 'guix system reconfigure /etc/config.scm' command take?
<maximed>mitchell: For yices2: Guix supports non-linux and non-x86_64 systems
<maximed>To figure out the GNU triplet (e.g. x86_64-unknown-linux-gnu), use (%current-target-system)
<maximed>wait no, that sometimes returns #f
<maximed>a combination of 'or', '%current-system', 'nix-system->gnu-triplet', '%current-target-system'?
<maximed>There were some patches to simplify that ...
<mitchell>seems like something that should be reified in gexp's
<nikola`>What are gexps exactly
<maximed>mitchell: The 'current-target-gnu-triplet' from
<maximed>that will always return the "x86_64-unknown-linux-gnu"-like thing
<mitchell>nikola: staged build expressions similar to traditional backquoted s-expressions but with syntax to make quoting/unquoting build expressions saner
<maximed>nikola`: A convenience for separating the Guile code that runs in Guix and the Guile code that is run during the actual compilation
<maximed>with some nice things for being able to import any module from any Guile package (even when not a dependency of Guix) -- using with-extensions
<maximed>and being able to ‘copy’ modules from Guix -- using with-imported-modules
<mitchell>#$target-system would be a nice thing to type
<maximed>Documented in (guix)G-Expressions
<maximed>mitchell: You can type: #$(current-target-gnu-triplet)
<maximed>(after applying the relevant patch from
<mitchell>but that doesn't always work you were saying
<maximed>mitchell: %current-target-system won't always work for your package, but current-target-gnu-triplet does
<maximed>(the issue is that %current-target-system returns #false when compiling natively)
<mitchell>nikola: give this a read too
<lechner>vagrantc: thanks again for your help!
<maximed>mitchell: on symiyosys: the home page is considered to be conceptually separate from the repository url, even if sometimes they coincide
<maximed>in this case, I'd consider the documentation website to be more home-y:
<mitchell>makes sense
<johnjaye>this reconfigure seems very prone to fail
<johnjaye>my internet fluctuated and the process halted a minute after i started it
<johnjaye>what exactly does system reconfigure do?
<maximed>johnjaye: First it download everything that will be needed, then it performs the reconfiguration
<mitchell>johnjaye: it attempts to make your current system reflect the operating-system fed to it. If you don't have the packages you need in your store it will attempt to download/build it
<maximed>The first step requires Internet to download, the second step should be immune to shenanigans
<johnjaye>ok. i'll babysit it until the download part finishse then
<maximed>The first step is the same for "guix shell", "guix build", "guix package -u"
<maximed>johnjaye: how did it fail?
<maximed>Also, have a look at --keep-going
<maximed>then you should have to intervene less often
<johnjaye>can i just repeat the command like with apt until it finishes?
<johnjaye>my internet is ideal for stress testing network things as it randomly disconnects every hour or so
<johnjaye>sometimes more
<johnjaye>just froze
<maximed>johnjaye: How did it freeze
<johnjaye>well you see first the package name is printed. like gcc
<johnjaye>then it prints these little # characters. #....#....#.... or like #####. then the hashes just stopped. very disconcerting you know
<maximed>I mean, what's the last few output lines
<maximed>johnjaye: I'd hesitate to run "sudo guix system reconfigure" in a loop, but running "guix system build" in a loop should be ok
<maximed>(the latter only downloads/build the required things, without performing the actual changes)
<johnjaye>it's in a vm so i can't easily copy it
<johnjaye>here's an image:
<johnjaye>well i ran guix pull first
<johnjaye>unmatched-paren said to do guix pull && guix system reconfigure /etc/config.scm && guix upgrade
<johnjaye>i have to do something like that with large apt upgrades as well. e.g. while true do apt-get install -y stuff
<maximed>johnjaye: dunno, maybe
<johnjaye>assuming the process has no problems how long should it take approximately.
<johnjaye>this is from a fresh install in virtualbox with the iso
<maximed>johnjaye: I don't know
<vagrantc>ugh. this has become a habit... guix gc --delete $(guix build PACKAGE)
<johnjaye>that's... disconcerting
<maximed>depends on the number of packages and services in the system configuration and the speed of Internet (locally and on the substitute farm)
<maximed>johnjaye: How's this disconcerting?
<johnjaye>it's also disconcerting you don't find it disconcerting
<johnjaye>this is the 3rd time i've tried to get guix working in a vm. download, verify iso with gpg, then install. very basic stuff.
<johnjaye>so unless i'm really far out of line here I would think it shouldn't be this hard
<maximed>I mean, Internet speeds vary around the world, how could a rando from the Internet have a clue how long the downloading will take for you?
<johnjaye>i can get a debian system up with gnome in less than 24 hours. much less usually.
<maximed>ok, I guess I misunderstood the question
<maximed>I though the question was: how long does it take for "guix system reconfigure" to complete
<johnjaye>ok fair enough. i meant here the total time to do all 3 commands plus the cd install. guix pull, system reconfigure, upgrade
<johnjaye>like i can sit here today because i don't have to go anywhere. but i can't babysit this process constantly.
<mitchell>try this for a faster install
<johnjaye>mitchell: as /etc/config.scm?
<maximed>My recommendation:
<mitchell>use the one in the vm as the baseline. but edit it to look more like this
<mitchell>it has less things to build
<maximed>(1) start with a lightweight installation (you can always add stuff later) (like mitchell suggests)
<Guest2491>will guix be faster than debian? for low perfomance system
<maximed>(2) grab some reliable Internet if available
<mitchell>faster in what regard?
<maximed>(e.g. ethernet connection)
<mitchell>installing? no
<mitchell>but since you can fine tune the builds, some pieces of software may run faster.
<maximed>(3) run thee "guix system build --keep-going" in a loop (while :; do guix system build --keep-going; dpne)
<unmatched-paren>johnjaye: i see you pinged me. wh
<maximed>mitchell,Guest2491: (when using --tune, currently only available for a very few packages but could easily be added to others)
<johnjaye>so the default /etc/config.scm has packages as %base-packages plus nss-certs
<maximed>johnjaye: TBC, you're using the installer, right?
<johnjaye>should i edit mate-desktop-service-type out of the services list?
<johnjaye>maximed: virtualbox. 2G ram. 50G drive. installed and gpg verified iso from website. internet drops frequently
<johnjaye>those are my rpg stats
<maximed>johnjaye: you could give it try I guess if you want to go desktopless,
<maximed>but it has been a long time ago since I used the installer
<johnjaye>that's a good idea. should give a better chance of completion
<unmatched-paren>johnjaye: when i installed guix it did take some time, but not an hour...
<johnjaye>then i might be able to get mate desktop afterward
<unmatched-paren>oh, of course
<johnjaye>ok. i let it run overnight since i had no reference for how long it would take
<unmatched-paren>when i installed guix i was using ethernet
<unmatched-paren>since my wifi card doesn't work
<unmatched-paren>so naturally the downloads would be quicker
<maximed>johnjaye: also (4): speed benefits from parallelism, so maybe use "-M 8" or such
<johnjaye>well. i guess i can order a 50ft ethernet cable to test that assumption
<maximed>to download 8 things in parallel
<maximed>johnjaye: WDYM with ‘that's a good idea’? (what idea was that referring to?)
<johnjaye>the manual says -M 8 is for jobs. does that mean downloads or cpu time
<maximed>johnjaye: yes
<johnjaye>what you said about desktopless
<maximed>a job includes a download
<maximed>it also includes building a package (technically, a derivation)
<johnjaye>i thought it downloaded everything at the start
<unmatched-paren>hmm, i didn't know guix provided a jobs flag
<maximed>johnjaye: usually, yes (with some exceptions w.r.t. grafts, where Guix does not know in advance what to download)
<maximed>"guix" usually downloads things before building things
<maximed>so first the download jobs, then the build jobs
<vagrantc>did the patches to split out the concept of download-jobs and build jobs not get merged?
<vagrantc>e.g. you could have a different level of parallelism for downloads than builds
<maximed>vagrantc: I don't know
<vagrantc>that seemed tremendously useful
<maximed>didn't know that build jobs and download jobs have separate parallelism
<vagrantc>well, there was a patch set to make that possible ...
<maximed>vagrantc: When I do "guix build --sources=transitive hexyl", it starts downloading sources one-by-one
<maximed>vagrantc: When "guix build --sources=transitive hexyl -M4", it downloads multiple in parallel
<mitchell>is the "-m" flag different then the "-c" flag
<mitchell>i've been using "-c" to limit the number of cores
<maximed>mitchell: Yes: --cores --> parallelism _inside_ a builder
<mitchell>i see
<maximed>(not necessarily respected by the package's build scripts)
<johnjaye>wait. to be clear, this means that throughout the entire process it will be downloading things, then building, then downloading, then building?
<maximed>Basically corresponds to "make -jCORES"
<maximed>johnjaye: Well, if substitutes are available and grafts aren't complicating things, then it's first downloading, then building
<maximed>but in some situations, you can have the latter
<maximed>johnjaye: do you want to built everything from source (very slow, but possible)
<unmatched-paren>Pretend there's a make target for each download and build. The builds depend on the download and their dependencies. Now imagine you're running the makefile with -j8, like maximed said.
<johnjaye>i don't know what i want. i just ran the commands unmatched said.
<johnjaye>if i want to develop at all i have to right?
<unmatched-paren>johnjaye: no
<maximed>or would you accept downloading ‘officially compiled’ versions from
<unmatched-paren>johnjaye: it's only if you're really paranoid/have enough processing power
<maximed>johnjaye: You can choose to switch whenever you want.
<johnjaye>what is it doing right now
<unmatched-paren>johnjaye: probably using binary substitutes
<unmatched-paren>they're enabled by default afaicr
<maximed>johnjaye: I noticed it downloaded a fuse tarball and gcc tarball, so maybe it's building from source
<vagrantc>maximed: i was thinking of which apparently hasn't been merged
<johnjaye>gcc was downloaded first yes
<maximed>OTOH, findutils-4.8.0, so maybe a mix
<unmatched-paren>ah, that's probably why
<maximed>I guess not everything had a substitute available?
<unmatched-paren>maybe 1.3 is losing substitutes
<unmatched-paren>as it gets more outdated
*maximed afk
<johnjaye>here's where it's at now:
<unmatched-paren>sorry you've been having so much trouble with this
<unmatched-paren>looks like substitutes to me...?
<unmatched-paren>can you see any .tar.* files being downloaded? those are likely source tarballs
<jgibbons[m]>If I provide the things necessary to make a guix-produced Debian package for guix, including scripts to set up and clean up the daemon, will guix provide an offical .dpkg?
<unmatched-paren>not sure a guix dpkg is a good idea
<vagrantc>jgibbons[m]: you mean will guix have a .deb ?
<unmatched-paren>to see why, look at debian's guix package
<vagrantc>offical is a bit of a confusing term when you're talking about two projects :)
<jgibbons[m]>vagrantc: yes
<vagrantc>admittedly, there are some inscrutible bugs in the debian guix package, but not really all that different from a foreign distro
<vagrantc>or should i say Debian package of guix ?
<vagrantc>as opposed to thise hypothetical Guix package for debian
<jgibbons[m]>unmatched-paren: You refer to ?
<unmatched-paren>vagrantc: i mean that the debian package is very outdated, and the only thing it's really good for is bootstrapping a `guix pull`ed version
<unmatched-paren>it would be work for not much gain
<vagrantc>the current released version of guix is available in debian bookworm/testing
<vagrantc>though guix hasn't released for quite a while...
<vagrantc>jgibbons[m]: yes, also the version in testing
<unmatched-paren>vagrantc: the current release is far too old
<vagrantc>well, maybe guix should release a new version then :)
<the_tubular>1.404 ?
<vagrantc>unmatched-paren: but yes, i never really saw it as much more than something to bootstrap a trust path
<the_tubular>Sorry, it was too easy
<unmatched-paren>vagrantc: i think that'll happen soon, but a rolling package management system that tracks master constantly is no fit for a stable distro's repos imo :)
<Guest2491>Do you have a deluge torrent client installed without any problems?
<unmatched-paren>*a new release will happen soon
<unmatched-paren>according to civodul
<mitchell>can't wait
<vagrantc>i'll believe/package it when i see it! :)
<vagrantc>jgibbons[m]: so are you talking about a .deb that more-or-less follows master ?
<unmatched-paren>thing is, the releases will become outdated very quickly; they're only symbolic milestones
<vagrantc>yes, that's what guix pull is for
<unmatched-paren>but yes, it's helpful for installing guix on a foreign distro easily.
<unmatched-paren>apparently though the debian guix package shadows the guix pulled one
<jgibbons[m]>I'm thinking of adding a .deb option to
<unmatched-paren>so you need to uninstall it basically right away
<vagrantc>unmatched-paren: shadows how?
<vagrantc>unmatched-paren: i've never had that problem
<jgibbons[m]>It would be no more useless than the binary release or install iso
<unmatched-paren>vagrantc: it seems to sometimes take priority in executable lookup over the pulled one
<unmatched-paren>jgibbons[m]: fair enough :)
<vagrantc>unmatched-paren: like, when your PATH doesn't include current/guix ?
<jgibbons[m]>Shouldn't it respect PATH?
<jgibbons[m]>I wouldn't be opposed to adding a .deb option to latest.
<unmatched-paren>vagrantc: i dunno. i've just seen that being reported, and vaguely remember it happening to me at some point -.o.- either way, i still think a .deb option would be overkill, although some `guix-bootstrap` executable would be nice to have for a similar purpose
<unmatched-paren>but you do it if you want to and you think it would be useful :)
<jgibbons[m]>Options under "latest" are use CI and follow master, don't they?
<unmatched-paren>jgibbons[m]: yes
<unmatched-paren>the problem would be updating it
<unmatched-paren>you'd basically have no other choice but to uninstall the deb after you'e
<unmatched-paren>*'re done pulling
<unmatched-paren>if you want to keep following mastre
<vagrantc>unmatched-paren: that's just ... not true
<maximed>vagrantc: Debian's guix package is convenient for setting up to daemon
<vagrantc>maximed: sure
<unmatched-paren>or download a new guix deb, i guess, but then you'd lose channels and that process sounds a little annoying
<vagrantc>maximed: although then it's stuck running an ancient daemon :)
<maximed>though Debian seems to forget to update the deb when the daemon is updated
<vagrantc>there's no forgetting
<vagrantc>it's in the README.Debian
<unmatched-paren>as in, i don't think you can use a guix that isn't from `guix pull` with alternative channels? please correct me if i'm wrong
<vagrantc>guix doesn't update the daemon unless you reconfigure your system. same with debian.
<maximed>vargrantc: I'm not seeing it in README.Debian
<maximed>it doesn't say anything about being ancient
<jgibbons[m]>Wouldn't the .deb install guix & daemon to a system profile?
<maximed>jgibbons: (Debian's) deb doesn't.
<maximed>It just installs it in /usr/bin/guix and /usr/bin/guix-daemon
<jgibbons[m]>A guix-produced .deb includes a profile, doesn't it?
<jgibbons[m]>It's just like any other pack
<jgibbons[m]>Though I could be wrong
<vagrantc>a guix packed .deb woudl be a little more different and ... presumably not too hard to build
<maximed>vagrantc: I read that, but I don't see being mentioned there
<johnjaye>unmatched-paren: ah yeah i get ya. it sounds like it's a debian stable situation where the stable is so old it takes a ton of effort to update it
<vagrantc>maximed: "The guix-daemon and guix-publish servers are configured run from the binaries in /usr/bin, rather than from the "root" user's guix profile.
<johnjaye>ok failed again. screw this. i'm doing that while build loop someone mentioned before
<vagrantc>maximed: in other words, it updates guix daemon when you update the package. not from guix pull or whatever.
<unmatched-paren>johnjaye: hmm... do you get an error pointing you to a compressed log file?
<maximed>vagrantc: ok
<unmatched-paren>if so, could you put the whole thing on
<vagrantc>maximed: obviously, you can override that ... i guess i could spell that out in more detail
<maximed>though the original remark was: ‘though Debian seems to forget to update the deb when the daemon is updated’
<unmatched-paren>johnjaye: sorry about this! it doesn't usually fail to install like this
<vagrantc>maximed: it only packages the released versions of guix.
<unmatched-paren>guix does have the occasional... issues with onboarding
<vagrantc>maximed: there might have been a security update patch or something
<unmatched-paren>but generally it at least reconfigures correctly
<johnjaye>unmatched-paren: can you tell me the exact command then
<johnjaye>right now i have
<johnjaye>while :; do guix system build; done
<vagrantc>maximed: it can't possibly follow guix-daemon from master ...
<jgibbons[m]>guix-daemon on guix system is only updated with guix system reconfigure, correct?
<maximed>vagrantc: the problem is that there sometimes are important changes to the daemon, leading to bug reports in bug-guix@ that (IIUC) result in ‘your daemon is ancient’
<unmatched-paren>johnjaye: i'm not entirely sure why you're running it in a loop; might be missing context from earlier. you probably have substitutes disabled, which would make the download take a lot longer of course
<maximed>(though maybe that was for _really_ ancient like 1.1.0, maybe not 1.3.0)
<johnjaye>no this is 1.3. just tell me exactly what to type
<unmatched-paren>johnjaye: i'll try to figure out how you can enable substitutes
<johnjaye>i already did guix pull
<unmatched-paren>or, rather, see how you check whether you have substitutes...
<maximed>vagrantc: wait, "apt show guix" says 1.2.0-4
<unmatched-paren>johnjaye: it's usually guix system reconfigure /etc/config.scm... and i can tell that isn't working :(
<vagrantc>maximed: current versions in debian are 1.2.0 and 1.3.0 ... if there are relevent guix-daemon patches (e.g. security) that need backporting, it could happen
<johnjaye>unmatched-paren: the error this time said something about how a get was somewhat slow so i think it's still stuck on the download portion
<unmatched-paren>ok, to be clear: is it that reconfigure is taking too long, and so your internet cuts out while it's doing stuff?
<vagrantc>maximed: sounds like you're running "stable" currently named "bullseye"
<jgibbons[m]>Can a guix-built .deb include a cron job that updates the profile that contains guix-daemon?
<unmatched-paren>i wasn't here earlier, sorry
<vagrantc>jgibbons[m]: that sounds ... evil.
<unmatched-paren>johnjaye: the "X is somewhat slow" is a non-fatal warning
<johnjaye>i'm not sure. last error was guix substitute: warning: while fetching... server is somewhat slow
<jgibbons[m]>Optional cron job?
<vagrantc>jgibbons[m]: obviously, it can do whatever. it's basically a tarball with some scripts at runtime.
<unmatched-paren>johnjaye: aha, that's the "haha your internet cut out take this cryptic message" error
<jgibbons[m]>Would it be better to include an "update-guix-daemon" script?
<unmatched-paren>guix's network handling isn't that great, apparently
<johnjaye>ok. is there some analogue of repeating apt-get in a while loop? that's what i always did on debian
<nckx>Morning Guix.
<johnjaye>something like while:; sudo apt-get -y install mypackage; done
<unmatched-paren>johnjaye: wait, that guix system build invocation
<unmatched-paren>you need to specify /etc/config.scm as an argument
<unmatched-paren>that may work!
<unmatched-paren>`guix system reconfigure` basically creates a system, then switches the "current system" symlink to the new system. `guix system build` does all that *except* changing the symlink
<unmatched-paren>so it's basically the same option syntax
<johnjaye>ok. i wasn't sure how to lookup the command. apparently 'man guix system' is sufficient
<johnjaye>unmatched-paren: to be fair my networking is fairly unusual. it's good enough to do most common tasks. but debian and fedora installers hate it!
<vagrantc>awesome ... node-addon-api ... has this integrity checksum that differs each time you build it:
<vagrantc>│ │ │ │ │ + "_integrity": "sha512-LOfBSMNHncejhcGiQMdYi6QruOXGGb8vt7z0jaWGHw2Gc8HkO5/BmjPVocMgPiubf9mnHEsWqGXDxr7px9boBw==",
<johnjaye>(it's wireless remote internet)
<unmatched-paren>johnjaye: the majority of guix's documentation is in `info` format. as you probably know, info is knid of... opinionated
<vagrantc>│ │ │ │ │ - "_integrity": "sha512-Sne3jnbNCK1ZTcM/5ve2Ehh7NQNNGo4nfjbVtwJWuUEAsy+1ZP1Z+qntA5dAUcWaV6QUpPtL8KZxswN2aK1NpQ==",
<johnjaye>oh right i forgot. in gnu land everything is info
<vagrantc>integrity through arbitrary change
<unmatched-paren>johnjaye: sadly
<johnjaye>by the way. to help lighten the mood a bit. i tried running the install instructions through a tts reader just to see if it would work.
<unmatched-paren>johnjaye: it's one of the only things where i prefer to use a web browser instead of the specialized tool :)
<johnjaye>had several problems. but the command pronuncation in particular was bad. like chmod was "schmod" and "gnu" was "nu"
<jgibbons[m]>So, back to my question, if I provide the things necessary to make a guix-produced Debian package for guix, including scripts to handle the daemon, would guix provide an offical .deb?
<johnjaye>so i changed it to say "gu nu slash lee nux"
<unmatched-paren>johnjaye: the latter makes sense, to be fair :)
<johnjaye>the hardest part i believe is that when it reads commands it doesn't read them like a human would. i'm just speculating. but i think like when you read an ip address say you don't read it in a monotone
<vagrantc>jgibbons[m]: seems more appropriate question for
<unmatched-paren>the former sounds like someone dislikes chmod and is saying something along the lines of `chmod schmod`... :P
<johnjaye>like one nine two dot one six eight dot. i think you put stress on the number syllables so it sounds more natural. so it sounds jarring when when the numbers and the punctuation are given equal volume
<jgibbons[m]>vagrantc: fair enough
<vagrantc>although i frequently run things via irc as a first pass too :)
<unmatched-paren>johnjaye: anyway, running `guix system build /etc/config.scm` in your while loop should work
<johnjaye>i did. it's saying a lot about substituting. like this line says substituting gnome-desktop
<johnjaye>glibc-2.33-debug is the one it's on now
<vagrantc>jgibbons[m]: i suspect you'd want to spell out what it provides over the existing options (e.g. binary tarball + installer script, the package from Debian, etc.)
<unmatched-paren>johnjaye: that's good. means you aren't building stuff from source.
<johnjaye>ok. so it's purely a network issue maybe?
<unmatched-paren>substitutes are guix's name for pre-built stuff
*vagrantc breakfasts and wanders off
<unmatched-paren>johnjaye: it's almost certainly guix just giving up when your internet temporarily disconnects
<johnjaye>it disconnects a lot.
<unmatched-paren>that's the exact message i get when my connection fails
<johnjaye>i can barely play starcraft
<nckx>Guix doesn't handle disconnection well. The error reporting you've already noticed, and there's no resume-from-byte-X feature.
<johnjaye>that's on the *new* bnet by the way. the one that has extra friendly reconnection
*nckx looks up bnet.
<johnjaye>indeed. well i'm going to go now. come back in a few hours. if it fails i'll retry with no desktop.
<vagrantc>johnjaye: can you set up another machine somewhere with a caching proxy close to you?
<johnjaye>maybe. but i'd need a guide to do it. debian preferably
<johnjaye>by the way i assume guix is based off debian?
<johnjaye>i get that vibe from the installer
<unmatched-paren>johnjaye: no
<nckx>In no way imaginable.
<unmatched-paren>it's entirely standalone
<unmatched-paren>doesn't even use systemd
<nckx>So installing Debian has a Guixy vibe? I thought they used Calamares.
<nckx>Only because I thought $everyone used Calamares.
<unmatched-paren>and if a system doesn't use dpkg, can you even call it a debian-based system?
<vagrantc>guix's closest relative is arguably Nix
<unmatched-paren>nckx: i think they also have a text installer
<nckx>☝ using Calamares.
<nckx>unmatched-paren: IC.
<maximed_>sneek: later tell vagrantc: I've made a list at, possibly some of them are already in Debian's 'guix package' though. I guess I could give switching to Debian's guix a try ...
<sneek>Will do.
<maximed_>sneek: botsnack
<johnjaye>the text installer is probably the same i guess
<vagrantc>i've installed many a hundred debians, but mostly with debian-installer, not calamares
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, maximed_ says: I've made a list at, possibly some of them are already in Debian's 'guix package' though. I guess I could give switching to Debian's guix a try ...
<johnjaye>red and blue make the most sense for high contarst
<nckx>Once you go TUI, the only background colour anyone likes is blue, so you quickly end up in a vibe.
<unmatched-paren>nckx: does debian use calamares though? last time i installed it, it used some fullscreen installer app
<johnjaye>to be fair turbo c had a blue/yellow thing going on
<vagrantc>but wait, i was wandering off...
<johnjaye>so it's not the only choice
*vagrantc commits!
<nckx>unmatched-paren: I dunno!
<unmatched-paren>i particularly remember the debian installer's somewhat oversized mouse for some reason... :P
<johnjaye>debian allows graphical or text install. netinst uses text by default i believe
<nckx>I thought they did…
<unmatched-paren>oh, yes. live install uses calamares
<unmatched-paren>i remember now
<johnjaye>pro tip: if you want to boot with some preseeding params hit escape as the logo comes up
<nckx>It's used by the ‘Live medium’ whatever that is. [wikipedia]
<johnjaye>you can also access the rescue prompt but that is more indirect
<unmatched-paren>netinst uses either text mode or their ad-hoc gui thing i think
<unmatched-paren>nckx: although not $everyone uses calamares.
<johnjaye>anyway i'm off. thanks for the help unmatched-paren and everyone
<unmatched-paren>e.g. fedora
<unmatched-paren>uses their own thing
<nckx>Bye johnjaye.
<unmatched-paren>and apparently they're replacing it with something web-based... naturally :(
*unmatched-paren afk
<maximed_>question: would downgrading the daemon (to 1.2.0 + Debian patches) be safe?
<nckx>Guix mentioned on debian-legal:
<nckx>maximed_: That depends entirely on what ‘Debian patches’ means? E.g., they probably patch <>, but check, and I doubt anyone's going to stick their neck out with a ‘yep’.
<nckx>It should be.
<nckx>Mumble muble.
<maximed>I'll just give it a try
<maximed>(didn't expect a ‘yes, safe’ answer, but maybe there was an incompatible change in database format or something that people know about --> ‘nope’)
<nckx>Oh, that kind of safe.
<maximed>nckx: (on debian-legal) oof, I thought it was a mail about removing Guix for distributing GFDL+invariant-sections manuals (:
<nckx>I think there were some bug fixes to how well it speaks the protocol but no changes to the protocol since 1.2.0.
<nckx>maximed: Sorry for the false alarm! I was just happy to see Guix in a (to me) unexpected place. Now let's hope the Debian detectives don't discover something we missed.
<maximed>not a false alarm, just speculation that was easily resolved by actually opening the link
<nckx>All links on IRC should instantly and unquestionably be clicked. Especially when posted by me.
<unmatched-paren>nckx: what if they look something like <>
<nckx>I don't know about you, but I would almost certainly click that?
<nckx>Possibly a me-thing.
<unmatched-paren>nckx: yeah, it even promises that it isn't sketchy!
<unmatched-paren>nckx: now i have to click that... cannot... control... self
<unmatched-paren>i see what you mean.
<nckx>See, the access.logs are rolling in.
<unmatched-paren>we must immediately patch to remove that message! :P
<nckx>It will never die. Eons from now, people will emerge from their fallout shelters deep inside the husks of a scorched earth, and whisper ‘please, how to install guix sd?’.
<the_tubular>Maybe one day the installer won't be so cryptic ;)
<the_tubular>I remember trying for a whole week trying to install guix for my first time
<unmatched-paren>(is it bad that i only realized the joke was about the old guixsd name after you said 'please, how to install guix sd?'?)
***mark_ is now known as mjw
<nckx>(I was referring purely to the ‘guixsd’ name yes. Installer improvements of course welcome.)
<unmatched-paren>either way, we must scrub it from existence. i will get my h4xx0r friends to ddos ur site!!!1
<nckx>unmatched-paren: I was clearly too cryptic, or I'm too easily triggered :)
<unmatched-paren>maybe i'm just too used to people accidentally saying 'guixsd
<nckx>unmatched-paren: I think that will be trivial considering what I ’spend’ on hosting it, so OK bye I guess.
<the_tubular>Sorry, I'm still traumatized nckx
<unmatched-paren>the_tubular: would you like me to phone a mental health expert?
<nckx>unmatched-paren: I just don't understand where they come from? The Web site, the ISO file name, the manual, the installer, the boot process, all say ‘System’. 15 minutes (or fine, hours) later: ‘hooray I have finally installed Guix esdee’.
<nckx>Like… OK?
*unmatched-paren looks up "how do i telephone the emacs psychiatrist"
<nckx>Clearly it's an ineradicable meme.
<unmatched-paren>nckx: it's not as bad as [censored]
*nckx should replace that URL with something truly offensive now, or a cute animal, so people will think it was truly horrible before.
<unmatched-paren>sorry, i'll have to pm you. as long as you promise you won't faint in horror
*nckx has kicked unmatched-paren from #guix (That's illegal.)
<unmatched-paren>(so as not to leave some future reader wondering: i was talking about people using 'GUIX' :)
<nckx>I'm sure they were absolutely riveted.
<nckx>vagrantc: Impressive work. Thanks.
***rgherdt_ is now known as rgherdt
<daviid>fwiw, this url in the guix manual gives a 404 -
<nckx>Thanks. That looks very familiar…
<nckx>I have an unfinished fix-that-precise-thing branch that hasn't yet managed to fix it, despite the code looking right. I'll give it another go.
<vagrantc>nckx: what is impressive this time? :)
<nckx>Your war on time and entropy.
<vagrantc>i think i've tipped that balance by 0.02% by now!
***jfred_ is now known as jfred
<nckx>Definitely more.
<vagrantc>i've pushed 15 commits recently, two of which didn't fix everything, one of which fixed three packages ... 15-2+3 ... 16 fixed packages ... out of 22086 packages ... 16/22086*100 ~= 0.07 ... you're right!
<vagrantc>more than three times the influence i thought!
<vagrantc>and a couple uncommitted wip patches...
<nckx>22086 packages *total*.
<vagrantc>if my last refresh of is to be believed
<vagrantc> i was right about ecl packages almost being the majority of known reproducibility issues in guix
<vagrantc>over 500 out of ~1000
<vagrantc>532 out of 1081, to be more precise ... not quite the majority...
<vagrantc>er, 1084
<vagrantc>the data just keeps rolling in
<mitchell>why are the --system arguments not triplets like the --target arguments
<mitchell>armhf-linux system vs arm-linux-gnueabihf target
<vagrantc>not sure, but guix picked different architecture names than what gcc would represent ... some of the features do not necessarily directly map to gcc triplets
<nckx>mitchell: Because that's what Nix used. Perhaps a better question for #nixos, though the only authoritative person is probably Eelco.
<vagrantc>what are the pros and cons of modifying source using a snippet in the source of a package definition vs. a phase in the arguments ?
<mitchell>I know this one! Snippets modify the source as returned by 'guix build --source' which should be buildable on a foreign distro without guix. Therefore you should not use snippets to embed store names. Only use them to modify things like bundled projects and non-free aspects
<mitchell>Use phases to patch sources with store names
<maximed>mitchell: They are also used for non-bundled things and free things.
<maximed>E.g., in case of a security fix to apply a patch
<maximed>... actually, that's patches, not snippet
<vagrantc>so ... using a phase will allow you to use the same tarball, whereas a snippet (or patches?) will actually generate a new tarball?
<vagrantc>i've noticed occasionally some packages generate what appear to be multiple source tarballs in the process of building them ... linux-libre and maybe u-boot?
<maximed>Though for some simple fixes I found writing a snippet more convenient than a patch or phase (in antioxidant)
<maximed>(technically dependency updates but whatever)
<mitchell>from section 19.4.5 "The boundary between using an origin snippet versus a build phase to
<mitchell>modify the sources of a package can be elusive. Origin snippets are
<mitchell>typically used to remove unwanted files such as bundled libraries,
<mitchell>nonfree sources, or to apply simple substitutions. The source derived
<mitchell>from an origin should produce a source that can be used to build the
<mitchell>package on any system that the upstream package supports (i.e., act as
<mitchell>the corresponding source). In particular, origin snippets must not
<mitchell>embed store items in the sources; such patching should rather be done
<mitchell>using build phases. Refer to the ‘origin’ record documentation for more
<mitchell>information (*note origin Reference::)."
<mitchell>so sorry
<maximed>vagrantc: yes: if a snippet or patch is used, then Guix will unpack the source, apply the patch/snippet, and make a tarball again
<nckx>mitchell: :)
<maximed>something something about making the patching process transparant for the #:phases and build system
<vagrantc>mitchell: well, good for being thorough, not so great for irc ettiquette :)
<nckx>The idea being that the unpatched source is never 'offered' to the user. (FSDG)
<mitchell>i am quite new to this
<vagrantc>nckx: that helps make it clear
<nckx>It's frankly your client's fault, mitchell, though mine doesn't warn either.
<nckx>All good.
<mitchell>emacs would never do me dirty like that!
<vagrantc>i suspect historically i've updated some packages that ought to use snippets that instead use phases as it was just what i was familiar with
<vagrantc>(e.g. u-boot, arm-trusted-firmware)
<maximed>I think the most important here is (1) it works (2) without licensing issues
<maximed>and that the rest is a matter of convenience
<maximed>(e.g., offering a source tarball usable on other distros is convenient, but IMO comes secondary to making it work on Guix)
<maximed>I don't think there's a consensus on the border
<mitchell>I think it offers a nice conceptual distinction though. If it breaks the build on another system maybe it ought to be a phase.
<maximed>mitchell: There are some packages which removes bundled Windows binaries (because bundled, binary, and sometimes non-free)
<maximed>that probably breaks the build on Windows systems
<mitchell>thats fair
<apteryx>'guix import pypi something' no longer outputs a trailing newline
<mitchell>which packages do this?
<maximed>mitchell: I've seen something likewise for Android (bundled, binary, but free)
<nckx>Snippets aren't the place to put Guix-specific patches, for example. A --source that won't build without substitute*s is fine. Some folks don't get that.
<nckx>Snippets should only remove 'questionable' code (legal, CVE). In practice this isn't always followed but that doesn't make it right.
<maximed>mitchell: So it looks like a good criterium but not usable as a hard rule to me.
<maximed>nckx: What about fixing bugs in a snippet, in a non-Guix-specific manner?
<mitchell>maximed: why not a patch?
<maximed>AFAIK fixing bugs is allowed in 'patches'.
<mitchell>what are patches for then?
<maximed>So why is it allowed in patches but not in snippet?
<mitchell>oh you said 'is' i read isn't
<unmatched-paren>mitchell: i use them for large changes that would be inconvenient to implement with e.g. substitute*
<nckx>Patches make it muddy, just because of how they are implemented.
<nckx>You'd need 2 patches fields for it to work.
<maximed>nckx: For a more concrete situation, some time in the past I added MINETEST_MOD_PATH to Minetest, with a patch.
<maximed>This patch was Guix-specific, but would also build on other systems.
<maximed>This patch was added to the 'patches' field of 'origin', and not a phase.
<nckx>Right. So it shows up in --source, when ideally it wouldn't, but that's just how patches are implemented. There is no concept of Guix-specific patchen and not-.
<maximed>nckx: I don't follow with ‘when ideally it wouldn't’.
<maximed>It's portable source code, and it adds something nice.
<nckx>Ideally, guix build --source foo returns FSDG compliant code, not Guix specific code. In practice Guix-specific patches sneak in as an implementation detail: there's no 'apply-extra-guix-patches phase.
<mitchell>why not a 'native-patches' field to the origin
<nckx>What is a non-native patch?
<mitchell>like a bug fix
<maximed>nckx: I guess my problem with that, is that then the 'patches' field only exist because of the existence of non-free software.
<nckx>I'm not saying patches should be system-specific! God no.
<maximed>So if all software was free by law or something, then 'patches' wouldn't serve any purpose anymore.
<maximed>But 'patches' could be useful even in a free world (e.g., the MINETEST_MOD_PATH patch).
<nckx>mitchell: Sorry, I don't understand. Native applies to machine code, not source code. Patches apply only to source code.
<vagrantc>wow, wine64. never thought i'd be building that.
<nckx>maximed: Almost, yeah.
*vagrantc slices some timestamps out of wine64
<maximed>So, why restrict 'patches' to FSDG and CVE issues, why not expand it purpose.
<vagrantc>nckx: what is the reason you want an un-guix-ified source?
<mitchell>nckx: in package input definition "native" applies to things that only need to be there at build time. So i guess i was thinking a "native patch" would be one that only applied to our system
<nckx>--source is not a recommendation algorithm, 'you asked for grep, but we think you'll love our VRgrep patch'.
<nckx>'Adding nice features' is not its place.
<vagrantc>well, if you want the upstream source, download the upstream source?
<maximed>vagrantc,nckx: Like, if you want un-guix-ified source, why not just download a tarball/git clone from upstream instead of downstream.
<maximed>* as vagrantc says
<maximed>nckx: My interpretation of "guix build --source grep" is: give me the source code of the 'grep' package.
<maximed>And if our 'grep' package is extended with the VRgrep patch, then to me that implies the source code includes the vrgrep patch.
<maximed>Like, I ask the source code of the 'grep' package from _Guix_, so I expect the source code of the _Guix_ package, not upstream's grep.
<nckx>mitchell: How would a patch apply only during build but not affect the final output?
<nckx>maximed: Yes. You've made it abundantly clear, thanks.
*nckx e mobile, having trouble keeping up :-(
<vagrantc>patching files not used during the build :)
<vagrantc>let me add this useless patch! :)
<nckx>Verified to have no effect.
<nckx>Love it.
<vagrantc>i daresay a few of my "fixes" recently feel that way
<mitchell>nckx: I do not know lol. I haven't thought about it that hard
<vagrantc>"fixed it for me, but ci and bordeaux have different ideas"
<nckx>Ohkay, sorry for banging on. I thought you had an underlying pount I was totally missing.
*vagrantc claps politely
*nckx bows.
<unmatched-paren>*audience begins throwing roses and confetti falls*
<vagrantc>many ruby packages in guix aren't reproducible due to unsorted gunk in various shipped .gem* files ... something similar for node too
<nckx>Naïve question: why does unsorted input matter?
<nckx>I'm gonna regret learning this but shoot.
<unmatched-paren>how to make a reproducible, bootstrappable package manager: build the source code of npm into a standalone executable that embeds node, then one's-complement (bitwise not) it. easy.
<unmatched-paren>now when you run it you will get a well-behaved program that cooperates gracefully with distro packaging! :D
<nckx>*unsorted but constant input, you get my *inhales* *ok* *i can do this* point.
<unmatched-paren>nckx: unmatched-emphasis-asterisk
<nckx>The first one isn't emphasis, it's *correction. Just to trigger you.
<nckx>Apparently not a universal convention, OK.
*unmatched-paren adds a second item to REASONS_TO_USE_SED_ON_IRC.txt, below "Feeling smugly superior"
<nckx>Sedding means I have to type twice as much.
<nckx>Think 'thefuck', not 'sed'.
<vagrantc>nckx: unsorted input may not matter as long as the output is sorted ... but sometimes the easiest way to get sorted output is to sort the input too ...
<nckx>My fingies are getting really owie, I need to take a break.
<nckx>vagrantc: IC.
<nckx>Not really but this is Ruby & Node, I'll believe anything unbelievable.
<vagrantc>i don't quite see it yet, that's why i've skipped all those so far :)
<vagrantc>i've seen similar issues in python, but know how to fix some of them
<DynastyMic>hi, does anyone have a guide on how to build a program on guix which uses its own ./install-program file
<the_tubular>Is there a channel with mitm-proxy in it ?
<oriansj>the_tubular: would there be a point to that as most channels are logged?
<the_tubular>I meant a guix channel
<maximed>DynastyMac: you probably have to replace the 'build' and 'install' phase
<maximed>The specifics depend on the package.
<maximed>I haven't seen an 'install-pgoram' file before.
<the_tubular>I wanna try my hand at https decryption
<maximed>* install-program
<maximed>I am not aware of a general guide.
<maximed>* DynastyMac -> DynastyMic
<oriansj>the_tubular: should be rather simple:
<the_tubular>That's not how that works oriansj
<maximed>oransj: I think the_tubular is looking for a package named mitmproxy:
<the_tubular>Yes, this maximed
<maximed>the software, not the underlying concept
<the_tubular>You don't attack SSL, you mitm yourself so you can see https in the clear higher on your network
<the_tubular>Basically the proxy will have both certificate
<oriansj>maximed: didn't parse that from the statement but I might be biased to writing code rather than finding the name for existing code
<maximed>the_tubular: I don't know a package definition, but apparently it's on pypi
<maximed>so the dependencies should be available with "guix import pypi"
<the_tubular>Yeah, I might try that
<the_tubular>I never tried guix import though
<the_tubular>guix import pypi mitmproxy ?
<maximed>the_tubular: I tried that, but it fails because only a binary version is on pypi
<maximed>the_tubular: Apparently nix has mitmproxy:
<the_tubular>We need a nix importer then :P
<maximed>There used to be one, but it has been removved for having become broken.
<the_tubular>Damn, really ?
<the_tubular>I mean a good working one could give us access to tons of software.
<kennyballou>Is there a way to change the permissions on a file in the store? I'm using to setup slurmd, but cannot get the slurmdbd service to start because the configuration file is o444.
<kennyballou>I guess my question is realy: is there a way to specify the file mode to `computed-file`? I cannot seem to change the file during activation because the store is read-only, etc.
<ulfvonbelow>kennyballou: after a store item is built, it is immutable. Regardless of what you set its permissions to during the building process, it will always end up with write permissions off for all users. If you need the config file to be writable, you'll have to copy an initial version to a non-store location where it can be found.
<kennyballou>ulfvonbelow: I don't really need the file to be writable. I would simply like to modify the permissions so that I can start a service that performs a permissions check. Thank you for the confirmation. I was thinking that there's no way to do this because it essentially violates the principle of the store.
<kennyballou>I can do what NixOS is doing with the service and copy/install the file into a runtime directory:
<kennyballou>ulfvonbelow: you even suggested as much in your answer, again, thank you.
<nckx>Immutability aside, you can't create files in the store that aren't world-readable. If slurm's whining about that then the above is your only option.
<nckx>Of course, it's still theatre: the original file will still be in the store, readable.
<kennyballou>nckx: yes, thankfully I can punt that problem for now since this is really only for my own local installations. I'm (un)?fortunately not managing an "actual" cluster.
<vagrantc>hrm. have a few patches which remove timestamps, but don't solve reproducibility issues completely... hrm.
<kennyballou>nckx: to competely unravel the onion, I'm trying to debug why jobs submitted by GWL aren't succeeding. I may be chasing something that doesn't even matter.
<nckx>vagrantc: I have a similar ‘fix’ for smlnj. The other mismatches dwarf it, so it feels silly to push, but… hrm.
*nckx was going to say ‘be sure to join #guix-hpc, kennyballou’ but… you did :) That channel is less active and GWL questions are certainly welcome here, but I haven't used it myself.
<johnjaye>nckx: is most work on guix adjusting projects to build on guix?
<johnjaye>i'm browsing the mailing list but i can't tell
<vagrantc>and just keeping up with a constant stream of updates ...
<the_tubular>There is also a lot of new features in guix
<vagrantc>also, because of the design, updating packages that directly or indirectly are used to built everything ... end up getting put into staging or core-updates, depending on how much has to be rebuilt when they are updated
<vagrantc>but merging those branches tends to be challenging
<nckx>johnjaye: Hm, I'm not sure how to measure or answer that. Most work is probably maintenance & integration work: making packages work together, not segfault, actually start a full DE, etc. Some of that work is necessary because Guix does some things differently, sure, but… I think that it's the majority of work in *most* distributions?
<johnjaye>that makes sense. debian is probably similar
<vagrantc>the rebuild cycles are definitely harder debian
<nckx>So the possible implication (not saying it's yours) that ‘guix weird = more work’ isn't true. Plus, some of the weirdness actually helps save time. That's why it exists at all, after all.
<vagrantc>harder than debian
<vagrantc>guix sacrafices some conveniences for arguably more correctness (e.g. not assuming a "minor" library update is compatible with the old one)
<nckx>The rebuild cycles are definitely long, but I don't know if they cause more human-hours in the end. It's more that we're a tiny team in comparison and honestly not very disciplined about it all…
<nckx>That's a high-level answer. Maybe you meant: when adding a new package. I'd say yes, but that's the only ‘creative’ part of packaging anyway 😛 The rest is just copy-pasting descriptions, URLs, and dependencies.
<nckx>So writing phases to adjust the build system to Guix can be 0% of the effort (well-behaved autotools) or 16,000% compared to the rest of the <package> boilerplate, it's not really that meaningful and depends heavily on the package.
*nckx rambles off to bed; good night Guix o/