<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 -.-
<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
<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.
<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
<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.
<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.
<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?
<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')
<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/...."
<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
<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.
<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
<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 :)
<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
<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? https://pastebin.com/G7mduBj8
<bluekeys>I think I could be making progress. The errors are now saying ld: cannot find -lLLVM_LIBRAIES-NOTFOUND. Where would I find them?
<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.
<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?
<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
<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?
<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.