<nckx>The (reasonable) argument is that a lot of newbies tend to install Guix with the Web manual next to them for some reason rather than the manual that came with the release, get confused that the two don't match.
<podiki[m]>devel version tracks master and/or core-updates changes?
<podiki[m]>seems like you'd only want the "stable" version when following the install
<podiki[m]>(and I too prefer reading the web version, never got into 'info' much though always mean to)
<nckx>That's fine, but it's fair to expect you to take care of making sure the versions match in that case.
<nckx>It should just be made clearer which manual is which.
<singpolyma>I would just have expected the main url to be the latest version
<singpolyma>If it had 1.3.0 in the URL I would be less confused
<podiki[m]>at least a note like "after install and running a pull, the 'stable' manual is no longer what you have" or something better
<podiki[m]>(I'm always a -git -devel type person anyway, but I can see it throwing people)
<singpolyma>Well, a guix user has no good reason to believe they are running a "devel" version
<podiki[m]>admittedly, the version numbers in general threw me at first, as I wan't sure how that jived with a rolling release; so I was confused what guix does (and with core-updates and other branches)
<podiki[m]>perhaps that ("versions" of guix) should be clarified as the root here?
<nckx><If it had 1.3.0 in the URL> I was just typing up a bug report suggesting exactly that.
<nckx>podiki[m]: If you're writing babby's first system configuration with which to ‘guix system init’ from the live installer following the manual's instructions, you are expected not to pull. Hence the manual should describe what is possible in the release version of Guix. That is at least the reasoning.
<podiki[m]>nckx: do we have anything explaining what versions of Guix means? I don't remember seeing it. I think that would be helpful (rolling release but also versions with new features or major updates)
<podiki[m]>nckx: yes, that is a good point, and great to have the manual with the install media. but seems the stable manual is limited really to that environment, or reading up before installing (when you'll be using a release version)
<nckx>(By the way, the manuals do contain “This document describes GNU Guix version 7f5e881, a functional package management tool written for the GNU system.” after the ToC, which nobody wil see.)
<singpolyma>Well, the systems I run guix on are themselves Debian stable. I don't mind old usually :)
<nckx>The manual contains half a thousand mentions of the word ‘version’ and I didn't check them all, but I didn't find an explanation of ‘Guix releases’. You're just expected to absorb it through osmosis.
<oriansj>well writing from the perspective of people who are unfamiliar with your project is an incredibly rare skill. So Guix documentation comes from the perspective of people who are familiar with it all and thus skip the bits which trip people up.
<podiki[m]>hmm something for Introduction or Getting Started perhaps
<podiki[m]>yes, us newer users are important with our annoying questions ;)
<nckx>oriansj: Agreed! Doing it well, at least, in a way that doesn't read like a weird blog.
<podiki[m]>thanks for creating an issue nckx, I'll chime in there later too
<sneek>jab9, raghavgururajan says: Could you share your ~/.config/sway/config file?
<sneek>jab9, nckx says: rspamd does a lot more than ‘just’ filter spam: it can send DMARC aggregate reports (which allegedly helps tiny personal mail servers maintain a reputation at the megaproviders', although I haven't verified that), greylisting, RBLs, and doesn't require an external DKIM filter. The others don't do all of that, although Spamassassin does more than Bogofilter. rspamd is probably heavier-weight, though (I run a Redis service
<sneek>jab9, nckx says: n't comment on the effectiveness of the spam content filters themselves; that would need a proper benchmark.
<sneek>jab9, nckx says: Note that ‘heavy-weight’ doesn't mean slow, in fact rspamd seems faster than others.
<podiki[m]>perhaps a cookbook beginner's guide, or add to the "getting started" section. though generally I do find the manual pretty good, I just started quickly doing things that needed more
<jab9>raghavgururajan I will share with you my sway/config file...busy at the moment...
<nckx>podiki[m], singpolyma: Thanks for taking your turn to hammer on one of the perennial weak points. It's only ‘annoying’ in that our heards are so tired, and the sand is so soft & comfy.
<Jeremy[m]>write a package description, let's say `example-package.scm`, and then run `guix package -f example-package.scm`
<nckx>MeowcatWoofWoofF: Well, guix isn't built to build/install unpackaged software from the command line, if that's what you're trying to do. No ‘guix try-to-build-and-install-what's-in-this-directory’ command. It's designed around writing package descriptions (build recipes), then building those in an isolated environment and installing them into the store.
<nckx>(And it sounds like that's what you're trying to do; apologies if I'm off base.)
<sneek>pkill9, maximed_ says: While SELinux configurations usually label binaries specially, SELinux can do without labelling binaries, if the programs manually switch context (I don't remember the necessary commands though). (IIUC, I haven't ever actually tried this)
<apteryx>inskscape doesn't use the glib-or-gtk build system and is used in builds not using glib-or-gtk either
<apteryx>so setting GDK_PIXBUF_MODULE_FILE in glib-or-gtk doesn't help for these.
***jeremy is now known as jeremyc
<jeremyc>I am brand new to Guix (not Linux). I have installed Guix a few times but can not seem to get it to even register as a drive that is bootable. I am on a modern computer (11th gen Intel) and UEFI enabled. My standard Linux distro is debian. Any thoughts? I just got done installing 1.3.0 from bootable USB onto a M2 SSD, the only one in my system.
<jeremyc>Reboot, computer doesn't recognize any drive as bootable.
<apteryx>I've heard that the installer could sometimes get confused by existing partitions
<apteryx>but if you managed to install without error, it's probably not that bug
<nckx>gierdo[m]> I'm running guix on top of debian/ubuntu, mainly for managing an environment as consistent and manageable (as code) as possible between various work/personal machines.
<nckx>gierdo[m]> The ubuntu base (work machines) is a requirement, the debian base is a nice to have for a few things, so going full-on guixsd is not really an option.
<nckx>gierdo[m]> I run sway where possible with i3 as fallback. Now to the challenge:
<nckx>gierdo[m]> If swaylock/waylock/i3lock are installed in the user profile, they don't work due to suid (access to /etc/shaddow) only being possible in the system scope. I haven't found other solutions than building/installing the screen locker outside of guix.
<nckx>gierdo[m]> Does anybody of you have a similar problem + solution? Is it possible/recommended to run "guix system" if not running guixsd?
<nckx>So, first off: it is definitely not recommended to run ‘guix system’ if you're not running Guix System (we got dropped the ‘GuixSD’ name years ago). It will turn your Debian system into a Guix System, basically, and you certainly don't want that.
<nckx>Store files can't be setuid and I don't know if there's an accepted method to install setuid programmes through Guix on foreign distributions. Guix System just makes a copy and chmods that; you *could* write a hacky script that does the same and puts them somewhere first in $PATH…
<ruffni>just to get this straight: `guix pull` fetches the latest commits from channels and (if no substitutes found) /builds/ the most recent version of `guix`? is it possible to cross-compile this process?
<nckx>gierdo[m]: A script like that would be relatively simple to write (for each in set uid pro gramme; do cp $HOME/.guix-profile/[s]bin/$each $HOME/.local/bin; chmod $HOME/.local/bin/$each; done) but make sure you don't make hard links to save space. Guix used to do that and it was a security hole 😉 http://issues.guix.gnu.org/28751
<nckx>gierdo[m]: No apologies necessary, it's just astounding how such an ancient name refuses to die.
<nckx>One which we generally agreed, when the change to ‘Guix System’ happened, was clunky and opaque ☺
<nckx>Point taken, I should've added a comment then…
<jbv1[m]>@mfg yes there is a problem with the current llvm-julia it does not create libLLVM-11jl.so I have to send a patch
<mfg>jbv1[m]: ah i see, thanks for working on it :-)
<jbv1[m]>out of curiosity do you often use julia on guix ? I plan to propose a patch for julia build system to make guix more inter operable with julia package manager and would be interested to hear opinions on the topic
<mfg>jbv1[m]: in fact this is the first time i have used julia.
<jpoiret>i'm trying out core-updates-frozen and `light` isn't building with "ld: light-light.o:/tmp/guix-build-light-1.2.2.drv-0/source/src/helpers.h:24: multiple definition of `light_loglevel'; light-main.o:/tmp/guix-build-light-1.2.2.drv-0/source/src/helpers.h:24: first defined here"
<civodul>oh, and kudos raghavgururajan & mothacehe for GNOME 40!
<nckx>mothacehe: You should be able to log in! Let me know. Change you password just in case.
<mothacehe>hey civodul! thanks, back from holidays (even though I didn't fully disconnect :p)
<mothacehe>the core-updates-frozen now even has GNOME 40 + Wayland support thanks to Josselin
<jpoiret>what's the policy on patches for core-updates-frozen? light doesn't build at all on it, just need to pass -fcommon to gcc to fix it
<mothacehe>nckx: I still have: firstname.lastname@example.org: Permission denied (publickey) :(
<mothacehe>jpoiret: build fixing patches are welcomed on the core-updates-frozen branch
<jpoiret>alright, expect one in the next hour then
<jpoiret>by the way, about wayland becoming default for gdm, what do you think would be the best way to achieve that? set the flag to be the default in gdm-configuration or change the desktop.tmpl file instead?
<jpoiret>since it can be a breaking change for nvidia users
*nckx types some more hateful stateful things… and now?
<nckx>the_tubular: ‘All tests should pass’ 😛 The Guix package in Guix doesn't mean much, although one of the previous updates did add XFS support, which was probably good news for both people interested in Guix on XFS.
<ss2>and I just figured that placing #log-file: "/var/log/programme.log" with put most of the errors into that file shepherd is trying to spawn. Which is a great help.
<ss2>I just spend half an afternoon without knowing that. ^^
<michzappa>I think I've found a bug in the crate importer when a package has a version of 0.0.0. Has anyone heard of that before? Might email guix-devel later or do a more in-depth trawl through the issue tracker
<MeowcatWoofWoofF>Is there any use case for using 'sudo guix install'? I was thinking root might be able to utilize some things, if given their own guix profile.
<michzappa>if you want to have packages in root's guix profile but not your other users then that is a use case, as for why someone would want that I am not bsturmfels
<MeowcatWoofWoofF>Instead of stuff like 'guix install ruby' I need to use 'guix install ruby:bin'
<nckx>MeowcatWoofWoofF: It spawns a ‘log-in shell’ which is… an esoteric concept, but it boils down to whether the elevated programme sees root's environment (as if you'd logged in as root, or run ‘sudo su -’), or still sees your user environment whilst running with elevated privileges. The former is what you want, since you want guix to operate on /root/.guix-profile; you do NOT want guix writing ~/.guix-profile but making it root-owned, because
<radvendii>hmmm i'm a little confused about scoping. if i have a function i want to replace a phase with, and i do `(replace 'phase my-phase)`, it complains about undefined identifier (even though i've defined it in that file)
<radvendii>my understanding is this is because it's being quoted, and passed off to another file where that function is not defined
<radvendii>if i do `(replace 'phase ,my-phase)`, it complains about "Unknown # object", and the same complaint if i use `',my-phase`
<radvendii>is it just not possible to define it in a separate function? do i have to do it inline?
<awb99_>I got a question on custom channels. I look at them as a source code repositioy that has shared code. So essentially I could put in there custom configurations, and helper libraries. And of course package definitions.
<awb99_>But now my question is, if a custom channel would also be a good place to put in config files, say bash_rc files,
*attila_lendvai notices the go importer mails on the list
<iskarian>attila_lendvai, it took a minute to wrap my head around your changes because I didn't even consider modifying go-version->git-ref since no packages use it for tagged versions :) perhaps they should eventually, rather than `(string-append "v" ...)'? I'm not sure.
<attila_lendvai>iskarian, i didn't really understand the problem domain here. i just took the easy way out of the hole i found myself in with those prefixed git tags.
<iskarian>the 'begin' at build-system/go.scm:75 is unnecessary; the third+ arguments of 'if' are essentially wrapped in 'begin' by it
<iskarian>(we should also use the parser's support for recognizing comments to use "// indirect" requires and blocks only for "upgrading" the minimum version of packages, but not actually include them in inputs)
<iskarian>(especially important since all dependencies for the main package/tests are required to be in the go.mod as of go1.17)
<attila_lendvai>iskarian, will do. FYI, the anomaly that lead me to look there was that go-ethereum's go.sum did not contain a dependency that the importer was struggling with. but i'm not well versed in any of this... i just want to do reproducible builds of go-ethereum.
<attila_lendvai>iskarian, great work with that parser, BTW! looks very elegant compared to the problem at hand.
<iskarian>thanks! I can relate, haha, I was just trying to import aerc :) and somehow got into all this
<attila_lendvai>iskarian, i'm completely fine if you butcher my commits, take whatever is useful, merge with yours, and push the results. you seem to know more about this than i do.
<iskarian>oh, the contents of that paste was all I had, and I don't even have commit access!
<attila_lendvai>iskarian, i'm still wondering why we don't just leave all this complexity to the upstream tooling... especially if golang prefers to link stuff statically.
<attila_lendvai>iskarian, hrm, shall i then look into incorporating your suggestions into my patches tomorrow? will you have time to deal with this?
<attila_lendvai>iskarian, AFAIU nix lets the golang tooling fetch all the sources, calculate the hash, and capture it in the packaging (what they call vendoring). i don't think the guix way of packaging every dependency separately brings any extra reliability on top of that.
<attila_lendvai>...and it brings a disproportionate amount of complexity. especially if we want reproducible builds.
<iskarian>not sure that packaging each dependency separately is necessarily the way to go, but the problem still needs to be solved. with nix's method, it's too easily for dependency changes to slip things in
<attila_lendvai>i think it's very much desirable with go-ethereum, and in general in the crypto space. these software are dealing with wallets holding millions of dollars worth of crypto... making a mistake in the go importer, and building it with a wrong version of a dependency that has a bug unfixed, may result in enormous losses. and it's not even hostile actors here...
<attila_lendvai>iskarian, but do we seriously think that the guix project will put comparable efforts into auditing e.g. the go-ethereum codebase and build infrastrucutre than the upstream itself?
<iskarian>isn't it additive, rather than either-or? If we're using --pin-versions?
<attila_lendvai>iskarian, golang's algo to pick of the actual sources based on the go.mod requirements is not trivial. aren't we reimplementing that in the importer? or 2) is our strategy to just grab anything mentioned, put it all there, and then let the golang tooling run this algo at build time?
<iskarian>since we use GOPATH to build, golang doesn't know anything about versions at build-time
<attila_lendvai>iskarian, then a misbehavior in the go importer can lead to compiling with the wrong versions, right?
<attila_lendvai>e.g. if your geth client is staking, and it's running with a bug compared to the rest of the network, e.g. due to getting compiled with the wrong version of one of its dependencies, then such a bug directly turns into real losses.
<iskarian>you could always install Go and clone and build :)
<attila_lendvai>iskarian, that's not my point. my point is that guix tries to act as an extra pair of eyes wrt worms, but may end up mis-compiling the package and causing losses for people who just guix package -i go-ethereum
<attila_lendvai>iskarian, would it be easy to change the build process so that guix puts all the dependencies it thinks into a directory, and then golang's compiler picks up whatever it choses based on the go.mod files and its algorithm? that would be somewhat safer, because a mistaken guix packaging would only lead to build errors due to missing dependencies.
<attila_lendvai>iskarian, re replace directive: reading the golang spec didn't make sense to me either. these directives are only useful if the ones in the toplevel project apply to every dependency in the transitive closure.