IRC channel logs


back to list of logs

*civodul waits for "guix processes" to complete
*lfam prepares a graft for graphviz
<cbaines>it's probably that the guix-build-coordinator-agent managed to start a load of builds when came back
<cbaines>I've managed to stop the agent now, so it should be back to normal
<civodul>cbaines: oh i see, thanks for finding out
<civodul>can we set an upper limit on the number of builds?
<cbaines>there is one, and the agent does look at the system load before starting new ones
<civodul>ah, so something must have gone wrong :-)
<lfam>"load average: 0.1 0.2 0.1" "Great, start all the builds :)"
<civodul>oh right, could be!
<civodul>perhaps there's a 5mn delay
<lfam>I'm just joking. I have no idea how it works
<cbaines>I think the parallelism increased and kept increasing as the load wasn't going up
<civodul>yeah, that makes sense
<cbaines>then suddenly builds started working, so a bunch of builds got started
<lfam>That makes sense
<cbaines>there's probably some way to make the agent smarter and not increase the parallelism if no builds are actually running
<cbaines>I've finished with maintenance now, so hopefully things should work a bit smoother now
<cbaines>in hindsight, I should have probably put in the effort to do the latest migration in a zero downtime way
<civodul>cbaines: thanks for the maintenance work!
<vldn>did somebody packed caddy?
<civodul>vldn: "guix search caddy" turns up nothing, so i guess the answer is no
<cbaines>civodul, part of this was deploying the fix for content negotiation, so that should work better now
<lfam>cbaines: It wasn't really an easily predictable outcome. Live and learn
<civodul>cbaines: excellent; i started playing with a client library yesterday
<cbaines>lfam, well, the downtime bit was, and I should probably try to avoid writing migrations in ways that lead to lots of downtime
<lfam>Oh, fair enough
<cbaines>in this case, it was changing the way derivation systems were stored, from a string to a number
<cbaines>it just happens that changing that for the ~28.5 million derivations in the database took a while
<cbaines>what I should have done was do one deployment to add the column, then populate it gradually in the background, then another to switch the column that's in use
<cbaines>civodul, cool, well just let me know if you run in to any more issues
<vldn>mhh i get Error: make: Not bound variable even with (use-modules (gnu packages base))
<vldn>do i miss something?
<nckx>vldn: gnu-make, not make.
<drakonis>is there any work on a content addressed store right now?
<pkill9>owudl there be any downsides to content-addressed store?
<drakonis>as far as i'm concerned, there shouldnt be anything?
<xelxebar>Battery cut out in the middle of a guix package -m operation.
<xelxebar>Now seeing this: /gnu/store/1h7biaq1lz6avf61rr4bh4adpvpgdqpg-python-pygobject-3.34.0/lib/python3.8/site-packages/gi/ empty
<xelxebar>However, guix build --repair python-pygobject just spits out `/gnu/store/1h7biaq1lz6avf61rr4bh4adpvpgdqpg-python-pygobject-3.34.0' without actually repairing anything.
<xelxebar>Am I doing something wrong?
<xelxebar>Also guix build --check thinks everything is okay.
<flatwhatson>my "guix pull" is failing to build guile 3.0.7 to bootstrap itself, seems to be a failing UT?
<flatwhatson>guess i can just wait for the substitute servers to catch up
<xelxebar>Okay, so manually deleting /gnu/store/1h7biaq1lz6avf61rr4bh4adpvpgdqpg-python-pygobject-3.34.0 from the store and doing, guix build --repair ibus caught the problem.
<xelxebar>However, I see the same issue with the brand new substitute O.o
<xelxebar>Doing the same thing again with --no-substitutes builds a correct python-pygobject library though.
<xelxebar>Something wrong with the substitute itself??
<lfam>Can you share the URL of the substitute?
<lfam>Also, when you saw that error message "empty", what command triggered it?
<xelxebar>lfam: Hrm. How do I get the substitute URL?
***tophullyte is now known as help
***help is now known as Guest7386
<xelxebar>Was having problems with ibus and just noticed that file was showing up in error messages. That message itself simply comes from `file'
<lfam>Whatever command you used to get the substitute can show the URL
<lfam>I see. I was wondering if it was a store item that was already "in use", or something that was downloading when the battery died
<xelxebar>Oh... wait. I think I'm just missing something. /gnu/store/1h7biaq1lz6avf61rr4bh4adpvpgdqpg-python-pygobject-3.34.0 is a grafted output.
<lfam>Oh, so maybe the power was lost while grafting
<lfam>It's weird that you'd end up using it anyways. That's not how the profile operations are supposed to work
<lfam>The work should all be complete before the new profile becomes effective
<xelxebar>I've had this happen before. Empty files end up in outputs.
<lfam>What filesystem are you using xelxebar?
<lfam>This definitely warrants a bug report. It's not supposed to be able to happen for Guix
<xelxebar>Okay. I'll send something to bug-guix.
<lfam>Guile 3.0.7 failed to build on CI
<xelxebar>Thanks :)
<flatwhatson>weird, doing "guix pull --commit=d6aeebb23639258311fdfb9dbf5f903079fde51a" (ie. just before the 3.0.7 stuff) and then "guix pull" worked
<lfam>Yeah, makes sense that the Guile update broke something
<lfam>I'm retrying the build
<jorge[m]><civodul "aquí hay un ejemplo con gnome-de"> Hola,esto aun no lo logro, estoy con mi guix a media maquina😨
<lfam>flatwhatson: Assuming you are using x86_64-linux, there should be a Guile substitute now
***iyzsong-- is now known as iyzsong-w
***iyzsong-- is now known as iyzsong-w
<vagrantc>wow, surprised to see md5 and sha1 mentioned in the release announcement ... both of which are awfully weak
<vagrantc>obviously, the gpg signature is a stronger verification
*vagrantc did a sha256sum on it and the was surprised to not find a matching checksum ... only to realize there's no sha256 in there :)
<atomsk298[m]>Hello, I've running into a weird problem. Everytime I run guix pull, I get logged out. Here is my config file: I'm not sure what happened, or why. Am I missing a service?
<vagrantc>guix pull, or guix system reconfigure ... ?
<raghavgururajan>Cawbird - Free Software Desktop Client for Twitter
<raghavgururajan>If anybody likes, please use the patch and let me know if there are issues.
<atomsk298[m]><vagrantc "guix pull, or guix system reconf"> guix pull. At first I reconfigured, and then it broke. Afterwards, i backed up my data and wiped the hard drive, then did a fresh install. Once it finished, I logged into my account, connected to the internet, ran guix pull, and it logged me out.
<davidl>Hi, anyone who wants to review an old patch of mine: #47898 - it is for CORE-UPDATES, and tested the build and passes lint-check (if I recall correctly).
<PurpleSym>davidl: Afaik usually Guix does not add features not supported by upstream.
<quickting>um is it ok if i ask about the nonfree kernel here?
<davidl>PurpleSym: well that's a shame, because this particular feature is pretty short and simple and very useful. Other distros like CentOS doesn't mind providing patches and it makes some packages a lot better.
<davidl>PurpleSym: I submitted a patch for vsftpd with I think over 50 CentOS patches and that was accepted.
<davidl>PurpleSym: so I actually Im not sure if that should have been accepted either if that is a strict policy.
<PurpleSym>I don’t know whether it’s a strict policy or not. I think I’ve had patches like that rejected in the past, so -.-
<PurpleSym>Also Guix is by no means homogeneous.
<davidl>PurpleSym: ok, well I still hope for it to be accepted, because everyone wants xmllint --xpath0 option for their commandline xml parsing!
<davidl>PurpleSym: do you have a patch number for your patches that got rejected so I can check?
<soheil>Hello Guix World!
<quickting>so... is it ok if i ask about the nonfree kernel here?
<PurpleSym>quickting: No, unfortunately not.
<leoprikler>raghavgururajan: I don't know how far we should go to support non-free web services.
<AppAraat[m]> - "It's basically Nix (the package manager), but with Lisp instead of Nix (the language), and made for libre diehards." - Is this true?
<leoprikler>Well, it's technically true, but abbreviated to a point where it might be dangerously polarizing.
***apteryx is now known as Guest89099
***apteryx_ is now known as apteryx
<AppAraat[m]>leoprikler: Granted I'm not overly familiar with either of the projects, but I thought Guix package manager had more features like the Guix VM.
<rekado_>AppAraat[m]: it’s not true.
<leoprikler>I'm not familiar with what the Nix package manager has or doesn't have, but the benefits of Guix are real :)
<rekado_>AppAraat[m]: here are two comments I wrote about this: and
<AppAraat[m]>Thanks, I'll take a look.
<tissevert>hello guix !
<MysteriousSilver>Greetings #guix, I tried installing the package manager using the installation script on a different GNU/Linux distribution. The shell doesn't recognize the command `guix`, but is able to run `/var/guix/profiles/per-user/root/current-guix/bin/guix`. Is this normal? Thanks in advance
<leoprikler>I don't think the installer creates a symlink to root's guix command elsewhere, you have to do that on your own IIRC.
<leoprikler>Note that when using guix as non-root user, you will probably use your own current-guix/bin/guix over root's, which is conveniently stored in ~/.config/guix/current
<tissevert>MysteriousSilver: have you editted your $PATH / reloaded your .bash_profile or equivalent ?
<MysteriousSilver>tissevert: not yet, what should add in the path? (i only ran the guix-install script)
<tissevert>I'm not sure but I thought the install script said something about editing your profile to make sure the newly-installed guix command was in your PATH (I've performed the installed on a different distribution only once so I may be mistaken)
<MysteriousSilver>tissevert: yeah, so the script adds guix to path. But in my case, the installation failed in between since /etc wasn't writable. I had to manually add the guix-daemon unit. Running the script a second time says guix is already installed. Maybe this was the problem.
<MysteriousSilver>Ok, I found the problem, the guix binary is at /usr/local/bin/guix, while my distro doesn't use the /usr directory as $PATH
***iyzsong-- is now known as iyzsong-w
<nckx>Good morning, Guix.
<nckx>MysteriousSilver: Which zany distro's this?
<MysteriousSilver>nckx: NixOS
<nckx>Bah, one of those non-FHS ‘functional’ weirdoes.
<nckx>(Nix doesn't have a Guix package? Pity.)
<nckx>They still haven't revoked my commit access, I should quickly sneak one in. Or add some checks to the installer. How do you ‘manually add’ systemd units on NixOS?
<MysteriousSilver>nckx: not sure if this is the right way to do it, but this is what i added to my nix configuration:
<nckx>MysteriousSilver: With those 2 adjustments, does Guix actually work?
<MysteriousSilver>nckx: guix worked, but packages installed with guix wasn't found by shell. I had to run another command (i am not which one) from the guix manual node getting started
<nckx>Probably . "$GUIX_PROFILE/etc/profile"
<nckx>That would make sense if your /etc is read-only, since Guix tries to add the equivalent there.
<davidl>PurpleSym: ok, I checked it now, and I think I agree with the general point that it's better to have something included upstream whenever possible, but as you mentioned it's been several months without a merge of a pretty useful feature so maybe at some point it's time to just include it anyway. I am wondering whether you can define 2 jupyter-lab packages: one that is "clean" upstream, and one that includes your patch? Im also thinking about the
<davidl>possibility of adding patches but not including them by default, so that you at least can inherit the package easily and people can include the patches if they want.
<PurpleSym>davidl: The patch was merged upstream, so this issue is actually done.
<mbakke>nckx: they were close:
<terpri>i'm not sure if this is a problem for anyone else, but i managed to get opencl working with mesa-opencl
<terpri>it's an easy hack: create /etc/OpenCL/vendors/mesa.icd containing the *absolute path* to
<terpri>the current opencl-related packages just put a bare "" which would normally be found in /usr/lib, i guess
<roptat>hi guix!
<terpri>i'll try to fix mesa-opencl-icd, as it should be a fairly straightforward hack (just prefix the .icd with the absolute path after installation)
<terpri>the icd contents, rather
<roptat>petite question de français : pour vous, il faudrait écrire "la commande va (essayer de) instealler" ou "la command va (essayer d') installer" ?
<roptat>visiblement un point de désaccord entre moi et tissevert, minime, mais une fois réglé je soumets la dépêche chez linuxfr :)
<mothacehe>Salut roptat ! Je voterais pour "essayer d'installer", merci pour la traduction !
<terpri>not tested with a real program, but clinfo is showing both GPUs with reasonable-looking output (vs. "Number of platforms:" EOF or whatever it typically says)
<terpri>moin moin roptat
<ss2>hello Guix!
<ss2>I'm trying to figure out how to work with inheritances, or package variants, if it is that what I've understood so far.
<ss2>Anyway, so I've made one, pushed it to my local channel, but it is still not found as such. Actually both packages exist now beside each other.
<ss2>despite, that I give it a different name with (define-public NAME ...)
<nckx>roptat: Assuming the question is about ‘de’, not ‘command’: can't you just omit the brackets? IMO they're not that valuable in English either. (Maybe that's what mothacehe meant.)
<roptat>ah, that makes sense
<nckx>(If I were king I'd just drop ‘(try to)’ from the original; ls doesn't say it will ‘try to list your files’ either.)
<abralek>Hi guix
<nckx>Hallo abralek.
<ss2>This is what my definition looks like:
<vldn>hi :) i'm writing a package definition for a go program. How to cd into a directory in src before the whole build process begins?
<nckx>ss2: You bound it to a different variable name, but the name is explicity kept as "davfs2": (name (package-name davfs2))
<nckx>You don't even need that line if you keep the name, but since you want to change it, use (name "davfs2-test").
<nckx>vldn: (arguments `(#:phases (modify-phases %standard-phases (add-before 'build 'chdir (lambda _ (chdir "src")))))) ; barring typos, and please add a newline before each (
<nckx>If Go programmes have a 'configure step (I don't know), use ”add-before 'configure” or even “add-after 'unpack”.
<apfel>hi there, is there a emacs geiser function to pretty print a buffer full of sexp, as if read buy 'read' and printed with pretty-print? This seems to be such an obvious function, thats why i assume it exists. But i had no luck finding it.
<abralek>I came across with the case where I need to create a VM with an extra drive. Basically I want to build a VM with imap server and a maildir dataset for testing purposes. I am reading gnu/system/vm.scm at the moment. Has anyone did something similar?
<vldn>nckx: to navigate inside the downloaded git-fetch source its chdir "src/subdir1/subdir2" ?
<abralek>Some hints regarding the API would be really helpful
<zzappie>apfel: just searched for formatting buffer in scheme few minutes ago, only found emacs-semantic-refactor
<nckx>vldn: That should work.
<zzappie>abralek: checkout system-qemu-image/shared-store-script, you can pass qemu options directly to it
<nckx>vldn: If it doesn't or you get stuck/lost, run the guix build with --keep-failed. It will print a ‘note:’ near the end with a directory name where you can inspect the state of the build directory when it failed.
<vldn>ah thats cool, ty!
<davidl>PurpleSym: aha ok, nice. Though I don't see any jupyter-lab package in guix master yet anyway?
<abralek>zzappie: Yes, that is what I am currently doing. <virtual-machine> doesn't allow to propagate the option into virtual-machine-compiler
<vldn>is there a list of expressions like "chdir" for the build-system? normal g-expressions? ^^
<vldn>i'm here for like 5 days and learn guix
<terpri>or -K for short (ime you'll be using that option a lot if you have a reason to use it ;))
<PurpleSym>davidl: It’s in a different channel, because of the other problems (see the issue I linked).
<davidl>PurpleSym: ok, I hadn't all of it yet.
<apfel>zzappie: thank you. I tried that in the past, but i missed srefactor-lisp. It seems to work now.
***Mysterio` is now known as MysteriousSilver
<bone-baboon>How can I reopen a bug that I closed?
<bone-baboon>Using email ^
<nckx>bone-baboon: send ‘reopen NNN’ in the body of a mail to control at
<zzappie>abralek: ah you dont need to use <virtual-machine>
<nckx>vldn: This one's just a standard Guile procedure, see <>. It's not specific to Guix or have anything to do with G-expressions. Unfortunately I'm not aware of a newbie-friendly tutorial or list ☹
<zzappie>abralek: wait a sec I'll make a paste
<bone-baboon>nckx: Thanks
<vldn>helpful anyway :) ty!
<davidl>nckx: Hi, do you feel up to reviewing an old patch of mine: #47898 - it is for CORE-UPDATES, and tested the build and passes lint-check (if I recall correctly). It adds --xpath0 option for xmlparsing to xmllint.
<nckx>vldn: Some very commonly-used helpers like substitute* and invoke are very Guix-specific and are ‘documented’ in docstrings in <>.
<davidl>nckx: since it's bash-related maybe you would be interested :)
<nckx>My stack is $too_many tasks high, I need to pop some off before I do something that requires actual concentration.
<nckx>And yes, you're right:
*nckx AFK to actually get things done.
<bone-baboon>What Emacs package provides `debbugs-gnu`?
<zzappie>abralek: check this out
<sertified>Does anyone use Jupyter notebooks?
<zzappie>abralek: you replace (simple-operating-system) with your os record and define any options in #:options keyword arg.
<zzappie>as I understand <virtual-machine> is mainly used for system tests with "marionette-operating-system"
<zzappie>but I miss this functionality actually. I would make system test more flexible. Like making severall marionettes and connecting them into virtual network or other crazy thing. Anyone interested in such thing too?
<zzappie>*It would make system tests
<zzappie>bone-baboon: I think emacs-debbugs
*zzappie I usually do 'C-h f emacs-func' then go to source and then do C-x C-f and look at /gnu/store/...-emacs-package.ver ending, to find out what package emacs function belongs to :)
<ss2>nckx: Thanks! that worked.
<bone-baboon>zzappie: Thanks
<mbakke>davidl: I replied to the xmllint patch :)
<apteryx>raghavgururajan: for the release process; that's how it's done right now: tag the sources; update the guix package to it, produce release artifacts.
<apteryx>so if you guix pull to the the exact commit corresponding to v1.3.0, you'll get the running Guix at this version, but it's knowledge of the Guix package will be still at the old version (say when using 'guix environment guix')
<davidl>mbakke: thanks, replied back!
<mbakke>davidl: cool, then it can be added straight to 'master' as well :)
<davidl>mbakke: Ok, should I send a new patch, or how should we proceed?
<mbakke>davidl: yes, please send a new patch
<davidl>mbakke: ok thanks. I'll let you know when I have gotten around to it. May take a few days unfortunately.
<mbakke>davidl: great, no hurries. Just ask here if you have any questions :)
<davidl>mbakke: ok, thank you :)
<irfus>hi #guix
<irfus>how is precedence/priority decided when there are packages with the same name in different channels?
<irfus>e.g. I want to define a package variant for a package already present in guix. I will define this variant in a local file or channel. How to make sure this is preferred over the guix one always?
<vldn1>still trying to build a package definition for a go a program. Is there a method to set the right path to my main.go before running build? 'build phase complains about "can't load package: package . : no Go files in /tmp/...."
<vldn1>the install instructions from github are: $git clone "" $ cd caddy/cmd/caddy/ $ go build
<roptat>irfus, when there are two packages with the same name, the one with the biggest version is chosen. If both have the same version number, it's undefined
<roptat>vldn1, you can try to add a phase before build that does (chdir "cmd/caddy")
<nckx>vldn1: Try adding ‘#:import-path ""’ or something very similar to the arguments field.
*nckx (pop 3)
*nckx (push davidl's thing)
<vldn1>tried chdir already @roptat , then it complains about "cannot find package "", it searches in the wrong place :/ now i try the import path argument
<roptat>(without the chdir I think)
<roptat>we need a tutorial like "packaging go for non-go programmers" (and similar for other languages)
<roptat>some of these build systems are a bit obscure if you don't know how the tool is supposed to work behind the scenes
<vldn1>yeah thx @nckx now it wants some required dependencies, seems like it works now
<roptat>or maybe it's just a matter of making the manual more verbose about what's happening and what you should do in general
<nckx>Such a tutorial would be nice. I know nothing about Go itself either, so it's hard to help with it.
<irfus>roptat: thanks
<terpri>vldn1, random guess: is go attempting to download dependencies while building in the chroot?
<terpri>vldn1, and i imagine 'guix import go ...' doesn't DTRT? (some importers are much better than others...)
<maddo>I had a question, since we're using shepherd and it uses elogind (afaik) for seat management, wouldn't it be better if we did a migration to seatd?
<maddo>It seems promising and far simpler than elogind
<vldn1>i'm just now arrived at the magic of guix import go .. :D
<maddo>(also, grats on 1.3.0)
<vldn1>cool shit
<apteryx>vldn1: hehe :-) you're now just one step from arriving at 'no go modules support in the go build system' ;-)
<apteryx>this will be the next thing to improve/fix for Go in Guix
<vldn1>it works when running it on seperate packages but not when running it recursive over the folder
<vldn1>also much fewer inputs when writing from hand
<terpri>for optional features or testing-only imports i'd guess? or is the importer mucking it up?
<nckx>maddo: Perhaps! Why would it be better?
<maddo>nckx: elogind is more of a hack than an actual thing. It's still systemd-logind with the parts reliant on systemd thrown out. It shares its complicated API with logind and it's much harder to mantain
<maddo>seatd is fairly simple and straightforward and it is compatible with (e)logind
<maddo>it is also much smaller
<terpri>don't we need systemd-logind compatibility for gnome or something? the api doesn't seem *horrible* at first glance
<nckx>davidl: I think I merely agree with mbakke's last response. I'm a bit confused by upstream's ‘we can't go changing the API just for this’-response (which is 100% correct) when your patch doesn't seem to need to do so. But I didn't dig deep.
<nckx>maddo: It also does a lot more.
<nckx>elogind, that is.
<terpri>it's definitely a bit of a hack, as...i dunno, a neutral fork, without any consideration given to it from upstream afaik
<nckx>maddo: seatd doesn't look compatible with (e)logind to me.
<nckx>Don't clients need to be ported to a compatibility layer like libseat?
<terpri>maddo, what would the advantage be if it's a thin layer atop elogind? or would it be more of an alternative for users who don't need elogind?
<nckx>terpri: IMU seatd isn't a layer, it's a seat management daemon like elogind but with fewer features. libseat is the layer, which then connects users like Sway to different seat manager ‘back ends’ (sound minimal yet?) like seatd or logind or...
<terpri>ah, i was confused by the "elogind compatibility" bit i think
<nckx>I don't get that part either.
<nckx>At least compatibility would be news to me.
<zzappie>it is not possible to get gexp from derivation right? or am I missing something?
<zzappie>I mean to get gexp from something that was (gexp->derivation "name" gexp)
<nckx>The conversion is extremely lossy if that's what you mean.
<zzappie>I haven't run it though
<zzappie>for example system-qemu-image/shared-store-script returns (gexp->derivation "" builder)
<zzappie>but I want to use the builder to pass it to make-marionette
*zzappie still gets lost distinguishing monadic versus non monadic variables. Am I in the monad? Can I use it now? Lift? Lower? ->gexp?
*zzappie oh, maybe (now)? ((now))?
<nckx>Honestly, same (hence the silence).
<nckx>(((monad harder)))
<zzappie>excuse me :) my brain is melting. So much stuff and it doesnt fit in my queue
<terpri>zzappie, it's difficult for sure, and trickier in a dynamic language (than Haskell, e.g.). give yourself time and don't hesitate to ask questions
<terpri>i totally get the "full queue" feeling, having worked on "small projects" like bootstrapping sml on guix
<bdju>is there any way to pause a really long build so I can do other things without lag but not lose the progress?
<bdju>I've been building qtwebengine all morning and it's at 86%
<nckx>bdju: Not elegant, but sending SIGSTOP (to resume: SIGCONT) to the daemon or builder's process tree just works. Only gotcha is that timeouts keep counting down.
*nckx uses htop for that, the ‘h’ standing for ‘hammer’.
<bdju>ah okay
<zzappie>terpri: thanks :) I was also thinking about the fact that dymanic nature of scheme makes it more complicated. You given bunch of names most of which are procedures
<bdju>okay I can't get anything to seem to happen via htop. I'm just gonna give up and kill it and hopefully someday soon there's a substitute
<nckx>bdju: Are you root?
<nckx>Has anyone here actually used Typed Scheme or similar? What were the trade-offs, apart from more keystrokes?
<bdju>I wasn't at first, but then I tried with root. nothing seemed different. or rather I relaunched htop with sudo
<nckx>bdju: Select the build tree with ‘c’, then F9, then 19. It's *ugly* but I guarantee it works.
<bdju>nckx: wow, you're right. that worked. thanks
<bdju>cpu usage just shot down
<jonsger>the opensuse package update is sent in for review :)
<AleQu[m]>Hey folks, is there something we can do if we've submitted a package definition patch but it doesn't seem to be getting any attention? Is commenting on the issue considered alright (and is it of any use)?
<mbakke>AleQu[m]: commenting is OK, asking about it here may also bring some eyes to it :)
<mbakke>AleQu[m]: what's the bug ID?
<raghavgururajan>Hello Guix!
<raghavgururajan>karthik[m]: Yes, you can git pull and edit gnome.scm. You may need to bootstrap that guix copy.
<AleQu[m]><mbakke "AleQu[m]: what's the bug ID?"> it's 47966
<mhj[m]>Hi hi, for programs that expect a FHS system, should I just try to run them in a chroot? I was thinking of installing Alpine in a chroot for like the 1 or 2 programs that I want to use that I can't find on other package managers.
<leoprikler>you can do FHS environments with guix or patchelf
<mhj[m]>Ohhh, I didn't realize
<raghavgururajan>apteryx: Ah I see.
<raghavgururajan>leoprikler: Yeah, services are a bummer. Atleast now, user can know what's running on their system.
<karthik[m]><raghavgururajan "karthik: Yes, you can git pull a"> thanks!
<bluekeys>Hey guix. I'm trying to build zig from source and I'm hitting an error. Does anyone have any ideas what I'm doing wrong, and a little bit of time to put me right?
<bluekeys>I think I could be making progress. The errors are now saying ld: cannot find -lLLVM_LIBRAIES-NOTFOUND. Where would I find them?
<roptat>are you missing llvm as a dependencyQ
<bluekeys>I've done a guix install llvm, I wanted to make sure I can manually compile it before attempting a package roptat
<farkr>hello. is this the proper channel for getting help with gnu guix?
<roptat>hi :)
<farkr>hi. I just installed guix for the first time several days ago so I'm still in the process of learning about this. I'm a bit unclear on how exactly this system handles environment variables. for example, why is the GUILE_LOAD_PATH set to /run/current-system/profile while Guile modules that install through guix get installed to /gnu/store/*-profile/? why is the package manager choosing to install on the latter
<farkr>while guile wants to load modules from the former?
<roptat>/run/current-system/profile is the location of the profile, it's actually a symlink to that /gnu/store/*-profile/ directory, which in turns contains symlinks to the various items in the profile
<roptat>but in general, guix will create environment variables that point to the store directory, not to the profile location. I think GUILE_LOAD_PATH is a special case that's set by default
<roptat>not on a guix system right now, so I can't check, but I think it's set in /etc/profile, instead of /run/current-system/profile/etc/profile (that one should contain only references to /gnu/store)
<farkr>what determines which *-profile folder /run/current-system/profile points to? I see several of them in gnu-store.
<farkr>thanks for answering btw
<roptat>/run/current-system/profile points to the "current system", which is either the system you booted to, reconfigured to or rolled back to
<roptat>when you reconfigure, guix create on of these /gnu/store/*-profile directories (it's name is computed from its content), and switches /run/current-system/profile to that directory
<roptat>(actually, to another one in /var/guix/profiles, which keeps a list of all the profile directories for each generation of the system or the user profile)
<farkr>okay. that makes a lot of sense. thanks again for explaining
<bluekeys>Does anyone know why we have a lld 11, but not 12? But, we have llvm 12?
<roptat>bluekeys, apparently not. if you want to contribute now's your chance :D
<derivates>Hello people, I tried formatting my Guix with btrfs with a few options but I get an error on booting up, it says the noatime option is not recognized
<derivates>I will quickly share a snippet of my FS scructure, im sure im missing a field
<derivates>forgot this
<derivates>;; BTRFS mount options (starts with a comma to be string-appended)(define base/btrfs-options ",noatime,compress=zstd,space_cache=v2")
<nckx>derivates: ‘noatime’ isn't a mount option.
<nckx>Not a valid one, anyway.
<derivates>when manually using mount -o you can tho
<nckx>Add (flags '(noatime)).
<dvn>> Opportunistic use of neighboring substitute servers is entirely safe, thanks to reproducible builds.
<dvn>[Citatation needed]
<nckx>derivates: Mount lets you mix flags & options, the underlying syscall and Guix do not.
<dvn>that's from the 1.3.0 release blog post
<nckx>derivates: Typo: (flags '(no-atime))
<derivates>ahh! thats it then, can I pass multiples right? are those non-strings?
<nckx>(...we had to Scheme it up just a notch.)
<nckx>derivates: They are symbols.
<derivates>I saw the no-atime symbol but what about this ",noatime,compress=zstd,space_cache=v2"
<nckx>The rest are options.
<tissevert>dvn: I presume it's the same mechanism as when adding a substitute server without signing, and still used because the binary file is the same as the one from the signed server
<nckx>derivates: (flags '(no-atime)) (options "compress=zstd,space_cache=v2") should work.
<tissevert>you know what the binary must be like so if someone has the exact same binary you don't need it signed, you know it's the right one and hasn't been tampered with
<derivates>+subvol under options still right? then the only odd thing I had was noatime in there
<dvn>tissevert: so guix will check that the binary has the same content hash i as from the signed server?
<nckx>derivates: Sounds correct.
<derivates>oh okay, many thanks nckx, I would love to expand this on the manual/cookbook...
<nckx>Basically, flags are a known fixed list of C #defines in the kernel <>, options can be any old string because the kernel's VFS layer doesn't handle them, it just passes them to the driver.
<nckx>derivates: That would be very welcome! Try to explain the difference (like I did, or preferably better 😉) so it's not just a Magic List.
<nckx>Even if most users will treat it as such.
<vagrantc>dvn: i've certainly seen it work that way ... e.g. i had a machine running guix-publish, and another with that listed as a substitute server, but not it's key, and it would download some files from it but some it would download from the guix substitute server (even when i know it had a local build of that substitute)
<tissevert>I don't know the details of the implementation so I'd love a proper reference like the one you asked for but I guess it's something along those lines although from what I understood there was a reason why the hash was known in advance and not checked afterwards but I may be mistaken
<vagrantc>i think i went so far as to use guix challenge to check at least one case
<nckx>dvn: If you have a substitute from untrusted server A, and it's reproducible, you can trivially verify it with trusted server B's signature because they are both the same file.
<nckx>The citation is simply ‘that's what reproducible means’.
<derivates>nckx: do you know any sort of way scheme would allow me to common factor some stuff on the silesystem part?
<dvn>to be honest, it reads as hubris to me
<nckx>It's just a fact.
<dvn>reproducible builds do not magically equate to being able to safely install packages from an unknown server
<nckx>[citation needed] 😉
<dvn>unless there is an automatic mechanism to verify the content of the binaries against the signed binaries of a trusted server
<dvn>guix does not use content addressing, so you can not depend on the hash of the dependency graph
<nckx>You seem to be missing the crucial bit of having a trusted server.
<dvn>please elaboratte nckx
<nckx><unless there is an automatic mechanism to verify the content> You just got it.
<dvn>nckx: you mean "guix challenge" right?
<nckx>No, that would require manual (and error-prone) intervention. Guix *always* verifies the signatures of all downloaded substitutes, discarding them immediately if they don't match.
<bluekeys>roptat I shall try. I may fail, but I shall try ;)
<vagrantc>dvn: if you have a cryptographic signature on an object, you can verify with an absurdly high degree of confidence that it is the same as another file arrived at by a different route
<nckx>Not silently, but not halt-the-world loudly IIRC, but I may misremember. It just discards them and builds from source.
<dvn>vagrantc: yes, of course.
<tissevert>so what that means is «packages are retrieved from wherever, signatures are retrieved from trusted servers» ?
<nckx>Not hubris, just maths. :)
<vagrantc>dvn: so... if you have reproducible builds, you can get your signatures from one server and your substitutes from another server for anything that built reproducibly
<drakonis>hmm, is there any more examples on how grafting works?
<dvn>nckx: you're misunderstanding. i was saying that the statement in the blog post was hubris, because it was a simplification of the situation. reproducible builds do not matter if you don't verify them properly
<drakonis>other than the blog post
<dvn>and it sounds like there are verification mechanisms that i was not aware of
<nckx>dvn: I understood what you meant.
<tissevert>and so it seems I was totally mistaken about that weird «known in advance» thing I thought I remembered ?
<dvn>well saying "not hubris, just maths" makes it seem like you didn't
<dvn>because i am not questioning things as fundamental as cryptograghic signatures and hashes
<roptat>dvn, reproducible builds mean it's more likely someone else has built a bit-to-bit identical package than what the build farm has, so it makes sense to ask the first if they're closer to you
<dvn>yes, that is completely obvious and aparent
<roptat>that's all the blog post tried to convey I think
<dvn>but only valid if you *verify* that binary against a trusted binary
<dvn>which apparently happens, but i was unaware
<tissevert>yeah, anyway the only risk there is is for a false negative, not a false positive, right (oh no, the signature doesn't match, let's download from the trusted one anyway, I don't see how that could let someone download bad contents) ?
<vagrantc>i guess the point of reproducible builds pretty much assumes you do useful things with the results (e.g. verify), so the author of that statement didn't feel the need to spell it all out?
<dvn>nckx: so if i download a substitute from unknown server A, then guix will automatically verify that the hash derived from the content of the binary will match the corresponding hash on server B?
<nckx>dvn: Yes.
<dvn>nckx: ok great. would be nice to have a blog post which explains some of that, because that statement linked to a blog post in 2017 about reproducible builds which didn't cover any of this
<dvn>there are a lot of people who claime reproducibility will do magical things that it will not without other mechanisms in place, so it raised some red flags for me
<nckx>You claimed the blog post made a hubristic claim, which it didn't. You were simply so weary of hubristic claims that you assumed as much. I can relate, but it's still not a pleasant way to start a discussion. I *don't* think the blog post's claim is magical at all.
<nckx>Of course, bugs are always possible...
<dvn>i do think that it's a big claim to make with not enough info to back it up
<dvn>i don't mean to claim it's a mortal sin, by any means :)
<dvn>sorry if it came off overly harshly
<vagrantc>without reproducible builds, it wouldn't be possible at all
<vagrantc>so ... the statement is by no means false
<dvn>i didn't say it's false
<bluekeys>Is there some way I can do a guix edit ... without the terminal "Waiting for emacs"?
<nckx>It's a blog post, not a whitepaper.
<dvn>it's a "don't worry, it's secure!" type of statement, and that is 1. dangerous, and 2. usually wrong. in this case it happens to be backed up by legitimacy, but that is not often the case
<dvn>nckx: right, and this is a criticism not an indictment
<nckx>bluekeys: Start it in the background?
<vagrantc>i guess being part of the reproducible builds project, i mostly deal with people who get what reproducible builds can do and what it can't
<nckx>s/?/&/, enev.
<bluekeys>like guix edit ... &
<bluekeys>lol. thx, that works :)
<nckx>Sorry for not being able to type like a human with the cursed paws.
<nckx>*these! FFS. I'm going to take a break :)
*nckx → kibble.
<vagrantc>nckx: sounds like a perfect time for you to refresh a few hundred packages or something
<bluekeys>the cursed paws, sounds like a band
<PotentialUser-77>Hello, if 2 channels have a package with the same name, is there any way to force which one gets installed?
<nckx>yjftsjths gets it.
*nckx has coffee now so let's try this again.
<nckx>PotentialUser-77: With ‘guix install’? I'm not aware of a way to do so if they have the same version.
<Noisytoot>I get "Authenticating commits 9edb3f6 to 7112753 (1,527 new commits)...
<Noisytoot>[## ]guix git: error: could not authenticate commit c80627731bc100baa4b6c5d265df5465cee9498e: key CD2D 5EAA A98C CB37 DA91 D6B0 5F58 1664 7F8B E551 is missing" when running "guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"
<Noisytoot>It works after "git fetch origin keyring:keyring"
<vagrantc>Noisytoot: that makes sense ...
<vagrantc>Noisytoot: the keyring contains the keys used to sign the repository ... so you need your keyring to be up to date
<Noisytoot>How is the keyring authenticated?
<vagrantc>it's just a source of key data, it's not authenticated
<Noisytoot>What's guix/android-repo-download.scm for?
<vagrantc>the .guix-authorizations in the repository you're authenticating is what determines what valid keys are, and adding a key requires a previous signer
<dongcarl>Noisytoot: Here's some more info:
<mdevos>sneek: later tell PotentialUser-77: guix install name@version or guix install -e '(@ (the channel module) the-package)',
<mdevos>* , -> ?
<mdevos>sneek: later tell bluekeys: "EDITOR=echo guix edit package", and open the file in your favourite editor
<sneek>Will do.
<nckx>sneek: later tell mdevos: By definition, emacs is the favourite editor. Like ed is the standard editor.
<nckx>And vi is, well, it's vi, that's punishment enough.
<Noisytoot>nckx, What's nano?
<drakonis>its an editor
<Noisytoot>I know, but if emacs is the favourite editor, ed is the standard editor, and vi is vi, what is nano?
<drakonis>nano is a small editor
<vagrantc>very small
<Noisytoot>Is it smaller than ed?
<vagrantc>'wc -c' can tell you
<nckx>Yes nano is the smol editor :3
<Dyedefra>emacs the best :)
<yjftsjthsd>nano is also the easy editor; sit a newbie down at vi or emacs and they'll be lost, give them nano and they can be working ASAP
<nckx>Let's debate at length whether someone familiar with the caret notation for ‘ctrl’ can sanely be called a newbie.
<nckx>Whoops, sorry, my bad, let's not.
<vagrantc>and that uppercase means lowercase?
<nckx>vagrantc: Actually, Shift+Ctrl+<key> does work too.
*vagrantc didn't expect to be called out
<nckx>That's for if you miss emacs and your 8 other fingers are getting dangerously bored.
<nckx>Noisytoot: I wondered too:
<nckx>(I still don't have a foggy what ‘repo’ does, but that's the story.)
<Noisytoot>How can I generate HTML documentation (for Guix)?
<soheilkhanalipur>Hello Guix World!!
<soheilkhanalipur>Please fix it!!!!
<cbaines>soheilkhanalipur, that link works for me
<cbaines>soheilkhanalipur, if you've got an issue, have you filed a bug report?
<soheilkhanalipur><cbaines "سُـھِـیـل, if you've got an issu"> .This problem happens once in a while!
<soheilkhanalipur>In guix package -u
<Noisytoot>"make html" seems to work
<nckx>soheilkhanalipur: Last time, you were asked to look at /var/log/guix/drvs/vl/zrszqn9kj9x8lzyqh4144pq569ggab-phodav-2.5.drv.bz2 to find the ‘real’ problem.
<soheilkhanalipur><nckx "سُـھِـیـل: Last time, you were a"> File is empty!
<nckx>‘bzless /var/log/guix/drvs/vl/zrszqn9kj9x8lzyqh4144pq569ggab-phodav-2.5.drv.bz2’ shows nothing but ‘byte 0/0 (END)’?
<zzappie>nckx: hey considering this marionette-thingie I asked earlier. It appears it was expecting just a qemu script location. So just needed to run the derivation in store and get the output...
<nckx>qemu script as in bash script?
<zzappie>bash script invoking qemu
<zzappie>*location :)
<nckx>Cool beans.
<zzappie>now I have /tmp/repl unix socket connected to vm
<zzappie>super cool