IRC channel logs

2021-10-04.log

back to list of logs

<singpolyma>nckx: really? Is that documented? I feel like I've read the guix pack part of the manual a lot recently...
<nckx>singpolyma: Yeah.
<nckx>--format=deb: “This produces a Debian archive …”
<nckx>Maybe you're reading an old manual?
<nckx>The Note: is one such wart (which I was just wondering about).
<singpolyma> https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html
<singpolyma>Is that not latest?
<nckx>No. https://guix.gnu.org/manual/devel/en/guix.html
<nckx>Your link is for the latest release (1.3.0).
<nckx>It's erm… not… ideal.
<singpolyma>Oh. That's very unexpected since one is very unlikely to run a "release" version of guix for long
<nckx>I've suggested adding a note to the top.
<nckx>I'm so annoyed by this eternagotcha that I can't be bothered to deal with it.
<nckx>Yes, that sounds extremely illogical put like that 😃
*nckx shrugs.
***Tirifto_ is now known as Tirifto
<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.)
<nckx>podiki[m]: I certainly don't dispute that.
<singpolyma>After I install guix the first thing I always do is run pull, since the release version is basically broken for my use cases anyway
<nckx>Same-oes.
<podiki[m]>and guix will tell you to pull if it has been some days, if you do some (most?) operations with guix
<singpolyma>I knew this pulled from git but hadnt really processed that running guix pull means not running a release anymore
<nckx>Why would you want smelly old bits on your shiny new sys.
<podiki[m]>only new and shiny bits please
<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.
<nckx> http://issues.guix.gnu.org/51000
<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
<nckx>‘Guix is a package management like Debian.’
<nckx>podiki[m]: Thanks!
<podiki[m]>(since I see a brief description of "versions of Guix" to be related for a beginner learning what Guix is)
<podiki[m]>I'll volunteer to help write anything too, if needed
<oriansj>podiki[m]: start with the questions you don't know the answer to and what you needed to learn to effectively find those answers.
<podiki[m]>often the answer was to ask nicely here :) and then answer the same questions for newer newbies. but yes, we can head that off with the manual more
<oriansj>especially with labels/tags that match what people looking for might look for first.
<jab9>hello guix people!
<sneek>Welcome back jab9, you have 4 messages!
<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.
*nckx eyes the inviting hole anon.
<nckx>*heads
<podiki[m]>well I'm all in on guix, really enjoy it and the community is both helpful, but at a size where you can contribute easily
<Jeremy[m]>podiki[m]: yes!!!
<nckx>++!
<Jeremy[m]>guix is so great
<nckx>Hi Jeremy[m].
<Jeremy[m]>the tech is also state-of-the-art, I don't think there's anything else out there that compares
<Jeremy[m]>hey nckx :)
<MeowcatWoofWoofF>I don't really understand how to install from source using guix, as opposed to running autoconf/automake manually.
<Jeremy[m]>MeowcatWoofWoofF: you create a package description right?
<MeowcatWoofWoofF>Do I?
<Jeremy[m]> https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html
<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.)
*nckx AFK 'gain.
<singpolyma>A try-build-install-. script would be totally possible in some cases though
<Aurora_v_kosmose>I just noticed PowerPC support was added. That's pretty nice.
<MeowcatWoofWoofF>lol, I just want to use the official Mullvad client on my fresh install.
<pkill9>MeowcatWoofWoofF: you can still run autoconf/make etc manually
<sneek>pkill9, you have 2 messages!
<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)
<sneek>pkill9, maximed_ says: E.g. with 'runcon'
<MeowcatWoofWoofF>How do we use stuff like "gem update" on Guix System? Is it okay to give ourselves write permissions to stuff like '/lib/ruby/gems' under the GNU store?
<MeowcatWoofWoofF>Or will we wind up in dependency heck?
***jonsger1 is now known as jonsger
<apteryx>b
<apteryx>hmm, we don't have this yet in our wrap-program: set var to X, but if the allow the environment to completely override it
<apteryx>that's useful if X is to accept a single value, not multiple
<nckx>(wrap-program … `("X" ?= (,blah))) …?
<nckx>Makes sense if there's a use case.
<apteryx>my use case is GDK_PIXBUF_MODULE_FILE
<apteryx>if won't allow multiple variables, I think, and the profile value is more worthy than the one computed at its build time
<apteryx>at some package's build time*
<nckx>Why wrap a backup though?
<apteryx>it's just sugar, to allow running the software directly from the store
<apteryx>without installing it to a profile
<apteryx>(it's for the glib-or-gtk build system, which already wraps the binaries with all that is needed)
<nckx>Makes it harder to reason about its behaviour, but it's similar to the if (getenv("XDG_FOO")) … else "~/.local" stuff many ‘apps’ already do in code.
<apteryx>true
<apteryx>perhaps I'll punt on that sugar for now
<nckx>It's just an icky boundary in general.
<nckx>I'm not against it per se, I just don't know what to think ☺
<apteryx>it's fine, you gave me an excuse to be down scope my change ;-)
<nckx>I was just curious, so thanks for sharing the use case.
<apteryx>MeowcatWoofWoofF: it's not OK to write to /gnu/store for any reason
<apteryx>can't you install the gems as your user ? pip for example has a --user mode
<apteryx>(it installs to ~/.local/...)
<apteryx>or better yet, package it for Guix :-)
<MeowcatWoofWoofF>I didn't know that was a thing.
***califax- is now known as califax
<MeowcatWoofWoofF>'gem update --user' worked. Can I do that with any program featuring its own package management?
<MeowcatWoofWoofF>(Still trying to set up VPN after successfully installing the Guix System)
<apteryx>MeowcatWoofWoofF: it's up to them, but it's a common pattern
<apteryx>just remember that if you even have some weird problems with your Guix packages, they may have to do with the out-of-band dependencies you manually installed with external tools
<apteryx>if you ever*
<MeowcatWoofWoofF>'gem install bro --user' also worked, but the bin directory for Ruby isn't included in PATH by default. That can always be appended, at least.
<MeowcatWoofWoofF>Trying to build from source, I'm told I'm "missing pkg-config macros"
<apteryx>arg. the issue runs deeper than staging
<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
<apteryx>(welcome!)
<jeremyc>OK, it said success at the end and to reboot.
<apteryx>OK. There are images built tracking current master on ci.guix.gnu.org, perhaps you could try these
<jeremyc>apteryx, ok, thanks, I'll head over there and see what I find.
<podiki[m]>this (installer issues) come up enough perhaps we should have a link to a current from master installation image? (do we want to prefer that or 1.3.0 in instructions?)
<podiki[m]>or at least for troubleshooting to try a more recent image easily
<raghavgururajan>sneek, later tell jab9: Np! You can share when you are available. :)
<sneek>Okay.
<efraim>hello guix!
<user_oreloznog>hello!
<mekeor[m]>hi guix :)
<jab>sneak later tell raghavgururajan my sway config is here: https://notabug.org/jbranso/sway-config
<jab>sneak tell raghavgururajan my config is here https://notabug.org/jbranso/sway-config
<jab>sneek: tell raghavgururajan my sway config is here: https://notabug.org/jbranso/sway-config
<sneek>raghavgururajan, jab says: my sway config is here: https://notabug.org/jbranso/sway-config
<jab>sneek: bot snack
<jab>sneek: raghavgururajan thanks for having me share that. My sway config was currently NOT under version control...
<sneek>Sneeky bot running on Guile version 3.0.3 using bobot++ release.2.3.1-6-a463-dirty
***matijja` is now known as matijja
<civodul>Hello Guix!
<brendyn>yo
<efraim>hello!
<brendyn>im a bit confused about how to use channels from a manifest when using a guix checkout instead of a pulled guix.
<efraim>brendyn: `./pre-inst-env guix package -L /path/to/channel -A foo'
<brendyn>efraim, an i install from a manifest using this?
<efraim>brendyn: sorry, I'm bad about checking back with IRC and I don't hear the bing since I don't have speakers
<efraim>`./pre-inst-env guix package -L /path/to/channel -m /path/to/manifest'
<brendyn>thanks ill try it
<efraim>why is cmake and cmake-bootstrap at different versions?
<efraim>(on core-updates-frozen)
<excalamus>good morning, guix
<nckx>Good morning Guix in general and excalamus, efraim, brendyn, and civodul (phew) in particular.
<excalamus>hey :)
<ss2>what would be the best way to debug a service? It fails, and I don't find meaningful error messages for it.
<ruffni>ss2: are there (more meaningful) error messages in the program being started by the service?
<ss2>No, none that I can find. The only errors are that the service fails in messages. Changes are that the declaration isn't correct.
<ss2>But I loaded it into an REPL, and there's an error thrown, so that might help.
<gierdo[m]>Hi guix!... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/03553950e18c41fa78c64a3406803d88b0d2f37c)
*nckx quotes:
<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…
<nckx>I doubt there's something built in.
<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?
<gierdo[m]>nckx: Thank you for your reply and info!
<gierdo[m]>I was afraid of that.. Not that big of an issue.
<gierdo[m]>And sorry for the "GuixSD" 😉
<mfg>Hi, does anyone use julia on guix? I get an error saying julia can't find libLLVM-11jl.so and i found https://github.com/JuliaGPU/oneAPI.jl/issues/72. But looking at julia.scm there is a package with a julia specific llvm version. Am i missing osmething?
<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 ☺
<excalamus>GuixSD is no longer used as a term?
<nckx>For like ever, no.
<excalamus>okay, so it's guix system
<nckx>Yup.
<excalamus>good to know
<nckx> https://git.savannah.gnu.org/cgit/guix.git/log/?qt=grep&q=guixsd
<excalamus>er, rather, good to be in the know
<nckx>It felt like longer ago, but still, years.
<nckx>excalamus: I must be missing some subtlety because both sound the same to me.
<excalamus>I have no idea how I missed the change
<nckx>In retrospect an announcement might've been needed even though we apparently didn't think so at the time. Perhaps we underestimated how well-known GuixSD was by then? Who knows.
<excalamus>nckx, I was trying to avoid my first expression being interpreted as sarcasm
<excalamus>it's still early for me, so being caution
<excalamus>:)
<efraim>nckx: IIRC you can't delete openssh's /var/empty, it makes the openssh service fail to start
<nckx>excalamus: Oh, no problem, but I can see how the second is safer in that regard.
<nckx>efraim: I'll add a comment then.
<nckx>Thanks.
<mfg>So the library itself is missing from guix environment julia --ad-hoc julia, so that's the reason why it cannot be found
<efraim>ba912479e8481d69b699ce348b35d5d70f0c9367
<nckx>lol
<efraim>it's been about 2 years
<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
<wigust>hi guix
<excalamus>hi, wigust
<nckx>o/ wigust
<civodul>hey ho!
<civodul>so, gforge.inria.fr finally went down
<civodul>but the irony of it is that despite all our work, we've already lost upstream tarballs
<civodul>like "guix build -S scotch --no-substitutes" won't work
<dstolfa>civodul: which tarballs
<civodul>zimoun`: ↑
<civodul>dstolfa: i've been told about the one of "scotch", i haven't checked others yet
<civodul>but see https://issues.guix.gnu.org/42162
<dstolfa>:(
<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"
<jpoiret>but the package hasn't been updated
<civodul>i saved that one tarball! \o/
<efraim>any suggestions where to stick gr framework? https://github.com/sciapp/gr/tree/v0.59.0 seems to be some graphics library
<mothacehe>nckx: hey! do you think you could create me an account on the guixp9 machine please :)?
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, raghavgururajan says: Just saw your gnome40 branch. Glad! :) Let me know if you need anything.
<nckx>mothacehe: 'course.
<nckx>User name?
<mothacehe>raghavgururajan: I merged the wip-gnome40 branch in the core-updates-frozen branch! Thanks for your work on the wip-gnome branch!
<mothacehe>mathieu would be fine!
<nckx>OK. PM me your private SSH key and I'll get to it in a jiff.
<nckx>Uh
<nckx>wtf
<nckx>public?
<nckx>I mean, it was worth a try.
<nckx>Please, everyone PM me your private keys, thanks!
<tricon_>Hahaha
***tricon_ is now known as tricon
<tricon>Wow, what an imposter.
<nckx>Oh the identity thefts.
<jbv1[m]>efraim: yes gr !! I'd be very happy to have it on guix !!
<mothacehe>hehe nice try :p email sent!
<cehteh>hmm would it be totally unreasonable to ask for 'guix system reconfigure' without an FILE argument, using the current system description from the store?
<cehteh>and 'guix system reconfigure --edit' fetches that, starts an editor, saves a tempfile, reconfigures the system .. basically aiming to deprecate the /etc/config.scm on users descision
<civodul>howdy mothacehe!
<civodul>nice to see you 'round :-)
<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: mathieu@10.0.0.7: 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?
<mothacehe>nckx: work great, thanks :)
<nckx>Great! Somebody should port Guix to this architecture so we can get rid of Debian.
<mothacehe>jpoiret: maybe we could start by a change in the desktop.tmpl file until we get some feedback from Nvidia users?
<mothacehe>nckx: could you also initialize my password :)?
<jpoiret>right, this seems like a good starting point. is there also a mechanism to warn users that use default values for some records that they are going to be changing soon?
<jpoiret>just like the warning i've been getting about targets vs target
<the_tubular>Any cool change in guix 1.3.0-8 ?
<nckx>mothacehe: I sent it in a mail.
<mothacehe>nckx: great!
<nckx>Hm, it's still spinning in mu4e. Which has become terribly slow, again, as of late.
<mothacehe>He, my Gnus setup is also terribly slow these days
<mothacehe>jpoiret: we could use "warn-about-deprecation" when wayland? is #false, but every GDM use would get a warning
<nckx>Re-initing the database ‘fixes’ it, but sheesh.
<nckx>I think the mail has left the building.
<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.
<the_tubular>Oh, I see. So which package "means" much in guix ?
<nckx>But -8 is just to got a fix to the lint test into the package proper.
<the_tubular>Like which one added guix-home for example ?
<nckx>Well, for ‘guix pull’ users, Guix pulls (heh) directly from master, so there are no separate ‘updates’: each commit to the master branch is an update immediately available to users.
<jpoiret>guix "the program" itself contains all packages definitions, when you guix pull you don't just update a package list (like in arch for example), but you update the whole guix program
<jpoiret>guix-home is just a new feature of guix itself
<nckx>The package guix is only relevant for Guix's own test suites, and initial deployments where it's the ‘bootstrap guix’, but you're expected to use it only to immediately ‘guix pull’ to master.
<mothacehe>nckx: sorry to bother you again, I could change my password but I'm not part of the sudoers group
<nckx>Ugh.
<nckx>‘You have new mail in /var/mail/debian’ 😃
<nckx>The incident has been reported!
<nckx>I'd never actually seen that happen. Anyway, you're added now. I can't find my checklist which has these steps on it
<nckx>probably at home.
<mothacehe>nice, I should be able to debug this cuirass-remote-worker thing now :)
<tekakutli>
<tekakutli>te
<tekakutli>
<tekakutli>my bad
<mothacehe>23412 powerpc64le-linux builds pending, the guixp9 should be quite busy.
<ss2>sorry that I have to ask again, I've been extending my practice service module, but it is somewhat just not really functioning anymore. Paste: http://ix.io/3AOx
<nckx>Rebuilding OpenSSH on only 2 of the 8 cores? Yes.
<ss2>And then I load it into my system declaration, and add the service type. Has it mayb got to do with the way I put it into my declaration?
<ss2>This service type I've now more or less copied in style that was laid out in radicale-service-type. I suspect that maybe the way I'm loading it is just not right anymore.
<ss2>And I've got no idea how to debug this yet. :/
<jpoiret>ss2: what do you mean by "Not functionning anymore"? is the shepherd service not starting?
<ss2>yes, it fails
<ss2>lemme fetch the error..
<ss2> http://ix.io/3AOH
<ss2>Sometimes it passes, but then the service unit fails, and I'm lost..
<roptat>hi guix!
<civodul>o/
<ss2>allright, I disabled all reverences to activation-service-type. Now at least reconfigure passes, but the service is dead.
<ss2>I'd really like to find out why this happens.
<ss2>okay, there is something in the logs.
<jpoiret>mpd looks like it needs some mandatory configuration, but your mpd.conf file is empty
<ss2>I does initiate a daemon, although it can't do anything anymore.
<ss2>I'm not planing to extend it, since there's a service declaration anyway.
<ss2>*for mpd
<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
<michzappa>i am not sure*
<MeowcatWoofWoofF>lol
<nckx>IIRC you're on a foreign distribution (which might default to -i already), but make sure to use ‘sudo -i’ just in case.
<MeowcatWoofWoofF>What does the -i flag do after sudo?
<nckx>Was bst*** a typo or does matrix.org enforce absolutely no nick consistency across the bridge?
<MeowcatWoofWoofF>I think I found what I need to progress with my new Guix System:
<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
<nckx>that will cause problems later.
*nckx → away.
<MeowcatWoofWoofF>I see! I'm somewhat familiar with login shells.
<civodul>mothacehe: hey! i just noticed that one can restart a previous evaluation but cannot trigger a new one
<civodul>like when you don't want to wait until it's time for the next one
<mothacehe> civodul: we could definitely add something like that but I fear it won't be trivial given how things are wired.
<mothacehe>I'll keep that in mind. Note that I implemented a feature that you proposed long ago: https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=bc821c8eb953d3ecba7f61c7af21879ba9085c69
<civodul>mothacehe: oh nice, thanks!
<civodul>re triggering, it's just that i had set a 2h period for the "source" jobset and now i'm eager to see whether my fix actually fixes it :-)
<civodul>mothacehe: BTW, we've had issues on berlin where some Cuirass logs show "cannot build foo.drv which is missing", suggesting that .drv's resulting from evaluation are not protected from GC
<civodul>does that ring a bell?
<michzappa>nckx: that was a typo, company-mode got in my way
<mothacehe>the "cannot build foo.drv" in Cuirass are not caused by gc'ed things but by the publish server sending 504 errors
<mothacehe>presumably because of nginx timeouts
<mothacehe>more details here: https://issues.guix.gnu.org/50040#9
<civodul>aaah!
<civodul>ok
<civodul>i saw you mention that bug, but i thought it was not related
<civodul>argh, crap
<mothacehe>yup, i'll try to resume my investigations on that topic now that I have a consistent access to my computer :)
<civodul>heh :-)
<civodul>i think berlin is running 'guix publish' before e53d8a84c6fbf7641e7d0e6e8658da0bb01fcd71
<mothacehe>oh updating will be a good start then!
<civodul>yeah i think so
<mothacehe>I'd like to find a nice metric to monitor I/O pressure too
<civodul>yes, it's tricky
<civodul>have to go, ttyl!
<mothacehe>bye!
***GNUtoo_ is now known as GNUtoo
<Gooberpatrol66>what all monitoring programs (something like nagios) does guix have services for?
<roptat>Gooberpatrol66, https://guix.gnu.org/manual/devel/en/html_node/Monitoring-Services.html
<Gooberpatrol66>roptat: thx
<roptat>there seems to be four of them, hopefully you can find one that's good for you :)
<iskarian>morning guix :)
<nckx>Hi iskarian.
<iskarian>a lot has happened while I've been busy with other things!
<iskarian>guix home is in master now, it seems; I'll have to try that out sometime
<nckx>That wasn't supposed to happen just yet, but here it is ☺
<iskarian>Ahhhh
<iskarian>Maybe I'll wait for the inevitable bug fixes to land first :)
<nckx>Python people! Is there an environment variable I can set so AssertionErrors don't truncate the middle of long strings? E.g. "blah blah … blah blah" — the bug is obviously hiding in the ….
<nckx>Please say yes because monkey-patching Python is torture to me.
<nckx>s/monkey-patching //
<jeremy>I am doing a manual installation and the font is very small. Can I change the console font some how?
<jeremy>nm, asked it after searching and failing, then of course found the answer. setfont FullGreek-Terminus32x16.psf.gz is fine.
<nckx>Glad :-) It's a valid question and it's something that could probably be automated.
<tekakutli>alo, is anyone free and willing to help me see whats wrong with my package attempt?
<radvendii>o/
<drakonis>well, post the definition on pastebin or debian paste
<drakonis>somewhere we can check it
<tekakutli> https://github.com/tekakutli/rakurri
<tekakutli>btw what happenes with (build-system gnu-build-system) if the makefile only has make install
<tekakutli>no ./configure
<iskarian>you need to delete the configure phase, check the source for "delete 'configure" for examples
<tekakutli>thanks
<maximed>tekakutli: The Makefile won't work, as it tries to install things in ~/.local/share, and $HOME is not set to anything useful in the build environment
<maximed>I don't know where krita looks for brushes
<tekakutli>./local/share/krita/
<tekakutli>hmm
<iskarian>is that where the guix krita package looks?
<maximed>if it looks in XDG_DATA_DIRS, maybe replacing ~/.local/share with /gnu/store/[...]-rakurri-brush-set-for-krita-[...]/[something] works
<tekakutli>well im actually in arch, and yea it uses the same .local/share/krita than non-guix krita
<maximed>tekakutli: Possibly it looks in .local/share/krita, but also in $XDG_DATA_DIRS
<maximed>If it's only in the former, some patches to krita might be necessary such that it can find brushes installed with "guix install rakurri-brush-set-for-krita"
<tekakutli>let me see
<tekakutli>will come back later then
<maximed>License information seems to be missing in the source code of rakurri-brush-set-for-krita
<tekakutli>I will tell rakurri
<tekakutli>I have a better makefile btw
<tekakutli>but wanted to try this first
<tekakutli>thank you maximed
<jgart> https://github.com/Abjad/abjad/discussions/1362
<maximed>jgart: ‘guix pack --format =docker’ <-- a space too much?
<jgart>thanks for catching that
<jgart>I'll fix now
<jgart>fixed ;)
<maximed>jgart: There's another one: "guix pack --format =deb"
<jgart>fixed it too
<jgart>;)
<jgart>If there are any other things just let me know here
<jgart>thanks
<radvendii>is there a way to use a local directory as a channel in guix?
<maximed>radvendii: -L
<radvendii>I want to modify something in guix and test it out
<maximed>"guix build -L/some/directory/with-modules stuff"
<maximed>"guix install -L/some/directory/with-modules stuff"
<radvendii>but i want to replace the normal guix stuff
<radvendii>will that overwrite?
<radvendii>i guess it's higher priority or something?
<maximed>radvendii: What do you mean with ‘replace’?
<radvendii>like i want to modify some of the existing guix infrastructure
<maximed>radvendii: Like modifying an existing procedure in Guix?
<radvendii>yeah
<maximed>E.g., changing how modify-phases works
<radvendii>actually one of the build systems
<radvendii>but yeah, that kind of thing
<maximed>radvendii: Usually one would clone the git repository of guix, make modifications, and build it
<radvendii>oh and then use the `guix` executable from that
<radvendii>makes sense
<maximed>"git clone ...", "guix environment guix", ./bootstrap, ./configure --localstatedir=[something], make modifications, make, ./pre-inst-env guix do-stuff-with-modified-guix
<maximed>There's a section in the manual about hacking on guix
<radvendii>hmmm... if i just want a simple build, i would have expected `guix build -f guix/guix.scm` to work
<jgart>radvendii, you can put a package in a file and build it outside of a source tree
<maximed>If guix/guix.scm ends with a package, that should work
<jgart>that is usually faster
<jgart>and then you can later integrate it into a tree
<maximed>But it won't automagically use your modified build system
<jgart>here's a script I use for setting up trees with no fuss: https://git.sr.ht/~jgart/dotfiles/tree/master/item/bin/executable_guix-prepare-tree
<radvendii>jgart: what do you mean? i'm not trying to rebuild a package, but a build system
<jgart>for when you don't want to think about it
<jgart>oh, missed that
<jgart>You can still put build systems outside of a tree
<maximed>radvendii: Another possibility is copying the definition of the build system from guix into the file holding the package definition of the package you're testing
<jgart>I think yoctocell has one for gerbil IIRC
<jgart>gerbil-build-system
<radvendii>there's a bunch of interdependent stuff though. i'm not sure exactly what i'd have to copy out
<maximed>radvendii: It depends on what you're modifying
<jgart> https://git.sr.ht/~yoctocell/guix-yoctocell/tree/master/item/yoctocell/guix
<jgart> https://git.sr.ht/~yoctocell/guix-yoctocell/tree/master/item/yoctocell/guix/build/gerbil-build-system.scm
<maximed>If you want to add more implicit inputs or something, copying the code from guix/build-system/SOMETHING.scm should be enough
<radvendii>like there's `guix/build-system/go.scm` which references `guix/build/go-build-system.scm`
<radvendii>i'm modifying something in the latter file
<maximed>radvendii: maybe replace %standard-phases with (modify-phases %standard-phases (replace 'stuff ... )...)?
<maximed>Assuming you're modifying phases
<radvendii>oh hm good idea
<maximed>And later do it ‘properly’ in the source tree of guix?
<maximed>Or copy go-build-system.scm as well
<maximed>But you might need to rename it, I dunno
<maximed>If you'll copy it, make sure to adjust the file name in you modified go.scm as well
<maximed>* file name -> module name
***jeremy is now known as jeremyc
<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?
<nckx>Yes.
<nckx>It expects a quoted sexp (data), not a procedure object (opaque callable thing which can't be carried over the host -> build environment barrier).
<radvendii>and sexps don't take their context with them
<radvendii>so it's like a dynamic scoping kind of thing
<nckx>Right. Not yet, at least.
<awb99_>I am using a custom channel, and now I got collission warnings: https://paste.debian.net/1214313/
<awb99_>this is my custom channel: https://github.com/pink-gorilla/gorilla-guix-chan/blob/master/.guix-channel
<nckx>awb99_: You can ignore that.
<awb99_>thanks nckx !
<awb99_>In the verbosity options,
<awb99_>I tried to search a manual what I can do.
<awb99_>seems to require an integer
<awb99_>but couldnt find the meanings...
<nckx>“Use the given verbosity LEVEL, an integer. Choosing 0 means that
<nckx> no output is produced, 1 is for quiet output; 2 is similar to 1 but
<nckx> it additionally displays download URLs; 3 shows all the build log
<nckx> output on standard error.”
<nckx>Info: (guix)Common Build Options
<nckx>awb99_: ☝
<awb99_>wow! you know it all nckx! faster than the speed of light :-) thank you!
<nckx>Uh… I… OK ☺ You're welcome.
<nckx>Any time.
<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,
<awb99_> https://github.com/pink-gorilla/gorilla-guix-chan
<awb99_>this is my current channel.
<awb99_>I did define a few packages that are not in guix.
<awb99_>And I added in install, install-lists, of packages I use.
<awb99_>And in config I put configurations for services that I will use in os + machine configs.
<tekakutli>alo again, can patches work on makefiles?
<tekakutli>I mean transformations
<tekakutli>nevermind
<civodul>sneek: later tell mothacehe it's workin'! https://ci.guix.gnu.org/eval/27221?status=failed
<sneek>Will do.
<civodul>tekakutli: you mean --with-patch?
<civodul>the patch can modify anything that's in the original source
<awb99_>I have a problem updating a guix server via ssh deploy. I have created a new root image that I have started the server with. Now I want to send an updated config via guix deploy,
<awb99_>it all worked nicely, it has been building local packages to be sent to the server.
<awb99_>In the end I got an error: unauthorized public key
<awb99_>It is somehow weird, since I can connect with my private key to the server via ssh.
<awb99_>Is there a second key for ssh deployment?
<attila_lendvai>iskarian, i have improved the go importer... but i'm pondering, do we need to implement the version selection algorithm described here? https://golang.org/ref/mod#minimal-version-selection
<sneek>Welcome back attila_lendvai, you have 1 message!
<sneek>attila_lendvai, iskarian says: I'm sitting on a patch for that at the moment, I've just been busy :)
<attila_lendvai>iskarian, ouch. i wonder what "that" meanas here, and how much we have stepped on each other's feet...
<attila_lendvai>iskarian, these are my changes: https://github.com/attila-lendvai/guix/commits/import
<attila_lendvai>iskarian, with this i can import the closure of go-ethereum, except one dependency (cloud.google.com/go/bigtable@v1.2.0)
<radvendii>what is the `@` macro (or procedure idk)?
<radvendii>i'm not even sure how to search for it...
<iskarian>attila_lendvai, looking at your commits... let's see... the github forks will work if you manually go the pkg.go.dev url and click the button
<iskarian>(so pkg.go.dev fetches their info)
<iskarian>radvendii, it looks up a binding in a module. see https://www.gnu.org/software/guile/manual/guile.html#Using-Guile-Modules
*attila_lendvai has also sent an email meanwhile
<radvendii>ah. so it's still going to have that dynamic scoping problem
<attila_lendvai>radvendii, IIUC that's a syntax for looking up symbols at compile-time from packages you haven't imported, or @@ for private symbols
<attila_lendvai>iskarian, oh, nice! i didn't know i can force that site to cache/parse projects. lemme see the log where it has failed...
<iskarian>attila_lendvai, I'm not sure why vcs->origin even checks iv VERSION starts with v; it should never.
<iskarian>oh, apologies, disregard that
<iskarian>I misread it
*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
<attila_lendvai>well, it's a single if now anyway, so... undoing it.
<attila_lendvai>actually, turning it into a cond
<iskarian>I wouldn't bother with detecting a "/" at the end of ref-prefix, just decide whether the ref-prefix should contain it or not and assume that
<iskarian>(and of course describe how ref-prefix is used in the docstring)
<iskarian>hmmm, can we just pass in the actual tag to 'vcs->origin' rather than adding VCS-REPO-REV-PATH? For example, this is the direction I was going with my approach: https://paste.debian.net/1214323
<attila_lendvai>iskarian, yeah, that'd probably be cleaner. not sure what's the semantics of go-version->git-ref anyway. maybe it should be renamed to something less definit, like extract-foo-bar.
<iskarian>as far as the "Fix the interpretation of the replace directive" commit, I'm not going to read into that rn, but perhaps take a look at my last message in #49602
<iskarian>for context
<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.
<iskarian>got to vet our sources, and all that
<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.
<attila_lendvai>i mean cross-distro reproducible builds
<iskarian>I don't think that's a goal of guix. we want builds to be reproducible with other guix builds, but not necessarily
<iskarian>other distros
<iskarian>regarding packaging each dependency separately, I don't think it's for reliability but rather vetting each dependency so no malware slips in
<iskarian>I'm
<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
<iskarian>s/easily/easy/
<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...
<iskarian>isn't that what --pin-versions is for?
<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?
<iskarian>sure
<attila_lendvai>but that's a major issue for tools like go-ethereum.
<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 :)
<iskarian>or even download a binary, I suppose
<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
<iskarian>hmmm. what does gentoo do?
<iskarian>(assuming they package it)
<attila_lendvai>FTR, i have tried running the official geth binary, and it seemed to work when run this way: ~/.guix-profile/lib/ld-linux-x86-64.so.2 geth
<attila_lendvai>hrm, maybe i'll just create a package that grabs the official binary and wraps it...
<attila_lendvai>i don't know anything about gentoo, but there's this: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-p2p/go-ethereum/go-ethereum-1.10.8.ebuild
<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.
<tekakutli>hello, are iskarian or maximed still here?
<tekakutli>