<blake2b>I know I had similar problems with a signing key issue some time ago and the issue ended up being that I had accidentally installed the package manage in my user profile
<dthompson>yup. and I have a systemd service that starts the current guix for the root user. I'm updating that now. all this time I thought the issue was the remote connection so I haven't looked so closely at the local setup.
<dthompson>once I find the root cause I hope I can see a way for guix to generate an error clearly explaining what is wrong
<dthompson>because the error right now is extremely cryptic
<blake2b>wait so you do have guix installed in your profile?
<dthompson>in the root user's profile. I use that profile for running the daemon so I can 'guix pull' as root and get the latest then restart the daemon.
<apteryx>blake2b: glad there's at least a potential VNC user. I'm now trying to unlock XDMCP in our gdm. Seems it was buggy in 40.1.
<apteryx>the accessibility buttons in GDM don't work; could someone confirm?
<trevdev[m]><apteryx> "the accessibility buttons in GDM..." <- How may I help?
<trevdev[m]>Any StumpWM peeps on? And/or CL? I'm trying to de-funk my understanding of how 3rd party libs should work. The whole stumpwm guix situation looks to be all derived from one source package and most easily installed on the root system much like stumpwm itself. I managed to write my own gexp to install my contrib module picks in my guix home env, but I'm having problems getting sbcl-slime-swank to work in either case
<fiesh>we've been using zfs on linux for many years on our production system (on /, Gentoo based), absolutely rock solid file system
<fiesh>I guess if you only have one device, you can also go for btrfs and have a very similar feature set. but if you have more than 2 devices and want some form of redundancy other than mirroring, zfs is your only option for a good fs
<sneek>dthompson, nckx says: Why not use /root/.config/guix/current/bin/guix-daemon? You seem to have thought this through, but I don't see what further downgrading buys you — apart from bugs like this one :). It's roundly discouraged and might be made hard to impossible in future.
<yuu[m]>examors: btrfs is good, but if when doing serious stuff i would prefer zfs for reliability
<unmatched-paren>and since you can't patch go packages in phases, you have to use propagation like that
<acrow>That is another reason I like guix -- always finding out new(er|ish) stuff.
*acrow modifies his config.scm and home-configuration.scm package listings.
<acrow>There was a time when I believed %desktop-services betrayed me and so I went by my own devices and lo now I discover the xdg-utils. No wonder awesome and EXWM are comparative wonders for me. :) BTW, this also reminds me of how that MacOS does things.... I guess this is the future. :/
<mbakke>implementing new abstractions takes work, but tends to pay off in the long run ... mostly people are just lazy and/or cowardly and opts for the least amount of friction
<acrow>nckx: I'm not ignoring you -- I do not know but am also curious. What you say makes it seem much less of an issue, aligned with action we see, but others have tagged this as a high priority and that fits with what vagrantc says that imeans we cannot successfully bootstrap from NVMe hardware (the newest stuff). Just seems backwards to what I hear said... Hmmm.
<acrow>mbakke: true, but we may want to introduce you to some better people. :)
<vagrantc>there are some kinds of lazy that are better than the alternatives
<vagrantc>take, for example, tricking, er, enticing someone to automate a task that you had been doing manually
<nckx>acrow: I think you might have misunderstood me. I didn't mean to comment on the bug report with that last message.
<nckx>I agree with the ‘important’ assessment (hence the silence of almost a year is odd, but whatever). Mes is one of those projects that will have to adapt and do some work. I certainly don't advocate for emulating the old syscalls in Mes, if that's how it came across.
<unmatched-paren>okay, naming opinions needed: what should be the actual name of the boolean field in <note> (for post-install notes) that suppresses the note if the package is being used via `guix shell` or `guix environment`?
<davidl>a weird thing Ive noticed is that in the terminal when Guix outputs "expected hash" it changes the first digit, for example the package's (incorrectly) defined base32 value is set to something starting with "2...", it will show "0..", and for a "9.." it will show "1.." I have seen this multiple since defining 100+ node packages recently.
<apteryx>so if you meant, RAID 5 or RAID 6, say that.
<Cairn>Hey unmatched-paren. I'm using your aerc patchset as a starting point for a different package, since you've already packaged a lot of the dependencies I need. I'm curious about your `go-github-com-protonmail-go-crypto` packages. I get "warning: bad use of '_' syntactic keyword" when I try to use them.
<lilyp>davidl: the first character can only be 0 or 1 due to the length of sha256
<Cairn>unmatched-paren, yeah, it looks like I've been using it. You just havent't updated any of the `go-github-com-protonmail-go-crypto` prefixed packages since version 1, so I didn't see any differing versions of those.
<rgl>indeed, it would make bootstrapping a new system much easier. as-in, pxe install.
<tricon>rgl: I have flirted with the idea of PXE-booting a tiny distro for hosting a VM, then pushing an OS (e.g. Guix) to it as a VM...
<minikN_>Hello. I use chromium and everytime I pull and there is an update for it I needs to get compiled from source (I'm using substitutes). But it never works, it goes to 100% (which already takes several hours) but then just stops at 100%. It's been going for two days already. Can I do something about it ? Thanks!
<rgl>tricon, I can use debian-live. but its somewhat lame not being able to use guix :D
<tricon>rgl: it's just a thought, though. i don't have a working implementation of this outlined or anything.
<unmatched-paren>minikN_: `guix weather ungoogled-chromium` says there's a substitute
<unmatched-paren>> This package provides the Guix Workflow Language (GWL), a scientific computing extension to the Guix package manager. It combines the specification of work units and their relationship to one another with the reproducible software deployment facilities of the functional package manager GNU Guix. A GWL workflow will always run in a reproducible environment that GNU Guix automatically prepares. The GWL extends your Guix installation with a
<lilyp>actually, guix workflow works from guix shell as well: guix shell guix gwl -- guix workflow have-fun.w
<tricon>unmatched-paren: i'll have to start reading through the source. there may be some things i could borrow/piggy-back on here. i do recall seeing this some time ago.
<hugonobrega[m]>hello guys. I haven't been able to update my guix system in ages (I guess a couple of weeks now) because of apparent network issues, but it's now been so long that I thought maybe someone had a better idea what could be going on. I've tried several different gnu substitute server urls but they all give the same result: some variation of "guix substitute: warning: while fetching <...> server is somewhat slow; <...> error: connect*:
<unmatched-paren>hugonobrega[m]: that looks like a network issue, but recently dthompson experienced a problem where that was displayed but the issue was unrelated
<hugonobrega[m]>unmatched-paren: it would be surprising if it were a network issue as it's been going on for so long now (and I have no other networking issues otherwise). got any leads for that dthompson issue that I can investigate? thanks!
<minikN_>unmatched-paren: I just did a pull again followed by a reconfigure.. it is downloading the substitute.. but then it's building it anyway... : building /gnu/store/nhrl66rn909j65jghx2cdqxv6bg75sf8-ungoogled-chromium-104.0.5112.101-1.drv...
<fiesh>apteryx: and likewise does not call mirroring "raid"
<dthompson>hugonobrega[m]: your issue looks different than mine. my error was related to archive signing not working properly.
<dthompson>that was a local error. yours is a problem with remote substitute servers.
<Cairn>What I've done is set the import-path to "github.com/boltdb/bolt/cmd/bolt" and unpack-path to "github.com/boltdb/bolt" which seems to succeed.
<Cairn>The issue is that when I use that new package as an input to another, I get an issue akin to the sort of issue I would get if I just used "github.com/boltdb/bolt" as the import-path. I'll get a message like "no Go files in /tmp/guix-build-hydroxide-0.2.23.drv-0/src/github.com/boltdb/bolt"
<Cairn>So it's succeeding when I build it on its own, but causing a project that depends on it to fail.
<vagrantc>acrow: your linking to the top of the thread leads to a lot of history and reading that would lead someone with limited time to not follow-up on it
<vagrantc>acrow: maybe post a summary and link to that instead? for 32947
<rekado_>Cairn: I’v been having similiar problems with Go packages
<rekado_>I honestly don’t know how to package them correctly
<Cairn>I'm so close: I've set up half a dozen deps, and yet I'm stuck on this last issue
*vagrantc was just looking at how crazy it would be to package git-bug ... but implemented in Go and feel a little lost with where to start
<Cairn>rekado_: Do you have any example packages I could take a look at which have a similar problem?
<rekado_>not “cmd” in particular; just the fact that Go repositories contain multiple modules and in Guix we seem to create one package definition per module.
<rekado_>one example is go-github-com-biogo-hts-fai, go-github-com-biogo-hts-csi, go-github-com-biogo-hts-cram, etc in (gnu packages bioinformatics)
<Cairn>Ah. Well, I guess it's fine to make one general package like `go-github-com-biogo-hts`, since it'll provide all the submodules
<Cairn>But I'm not sure if that's too general of a thing
<vagrantc>acrow: it's not clear how to use the --exclusions argument ...
<Cairn>Alright, alright, I got it. I misremembered the error; I wasn't getting a missing file issue when I just used "github.com/boltdb/bolt" as my input, but I was actually just getting a failed test issue. I used "#:tests? #f" and it succeeded.
<vagrantc>acrow: debian/copyright-scanner -d $(pwd) --exclusions=debian/ ... In procedure car: Wrong type argument in position 1 (expecting pair): ()
<vagrantc>acrow: seems to run if i used --excludes=^debian/ ... no idea if it is working as expected
<acrow>vagrantc: Where people have questioned what this Apache project has licensed we have made inquiries upstream. Those suspicions have been documented and you will see that those discussions have ended without any changes by the Apache project. As I see it we have done more than the due diligence needed to package a widely used free software library whose license continues to be maintained upstream.
<vagrantc>acrow: making a clear, explicit summary and then pointing people to that will make it easier for someone to review
<vagrantc>acrow: relaying all that in IRC doesn't help a lot, per se. :)
<vagrantc>acrow: for more exciting news ... the file stemming/trimming is cool, bit it's leaving a leading /
<acrow>vagrantc: What we have done on guix's behalf is carefully review the source to find and remove embedded dependencies and binaries that make the build easier. I don't think anyone would assert that what remains is inappropriately licensed. I still trust that the upstream is a reliable free software provider.
<acrow>vagrantc: I can get rid of the leading backslant -- that actually happened as part of a fix and I ought to have nailed it down better.
<vagrantc>acrow: but asking someone to review, and then pointing them to the whole thread, instead of a summary of the rest would help
<vagrantc>acrow: at least, in my opinion it would help
<vagrantc>acrow: continuing to debate on irc about it perhaps less :)
<acrow>vagrantc: Well I had been considering changing my nick from acrow to relentless-nag.