<podiki[m]>I'm hitting a bug with eg `guix import go k8s.io/client-go -r` and vaguely remember something about go and refs/tags ...
<horizoninnovatio>Good Morning Guix! I've beeing doing "guix pull" "guix package -u" regularly for over a week, maybe two and there have been no updates/upgraades. Is this normal? or am I missing something?
<podiki[m]>depends what packages you have, if they weren't updated then nothing will happen usually (sometimes will because of dependencies being updated)
<podiki[m]>(on go importer, found several matching issues, so it is known... eg 51633, 52362)
<Andronikos>Does someone know the state of Guix running on a Raspberry Pi 4?
<KarlJoad>Quick question: Does Guix support the man(9) pages? They are non-standard and are provided by Linux's documentation system. I made a request to nixpkgs (#127424) about it, which has been added.
<sneek>KarlJoad, trevdev says: Update: I deleted my guix profiles and garbage collected my user. Then I ran a guix pull, and a guix home reconfigure. It looks like everything came back OK except that my gnupg pinentry broke. Its looking for pinentry in .guix-profile instead of .guix-home/profile. I guess guix home can't account for unexpected external state.
<sneek>KarlJoad, trevdev says: What's more is that using only guix home has had no effect on the original problem. After initially rebuilding my entire home to generation 1, garbage collecting, and doing a guix home reconfigure, I am still getting every home package downloaded and/or rebuilt
<sneek>KarlJoad, trevdev says: I appreciate your help, thanks for the suggestions. I am not sure what to do at this point beyond give up on home, or email the bugs list. Maybe I'll do both :)
<nckx> horizoninnovatio You should check whether 'guix describe' gives a new commit.
<KarlJoad>sneek: later tell trevdev[m] I recommend you email to the bugs list anyways. It makes sense that a reconfigure from generation 1 to current rebuilds everything, but does a subsequent reconfigure, without pull, still cause a mass rebuild?
<Andronikos>KarlJoad: After some research I didn't find anything. Let me know if you have something.
<trevdev[m]>KarlJoad: Thanks! I did email help-guix but after more reading and mulling I am still not sure I'm not just misusing guic gc. As per the docs reconfiguring your system after a gc can be "inconvenient" so do it as infrequently as you feel like you can get away with. Maybe this carries over to guix home with "requirements for the ability to install packages"
<sneek>trevdev[m], KarlJoad says: I recommend you email to the bugs list anyways. It makes sense that a reconfigure from generation 1 to current rebuilds everything, but does a subsequent reconfigure, without pull, still cause a mass rebuild?
<unmatched-paren>tangonov: I like it, except that I don't think the guix (package|home) split is that confusing. guix package is for installing packages in the traditional way, with mutable profiles, and guix home manages stuff the declarative way, with reconfiguration, containerization, et cetera.
<tangonov>I noticed profiles are pretty guix package centric as well. I wonder if it would ever make sense to mix the two
<ardon>Hi Guix! Sorry to cut the fun, but I'm genuinely lost here. I'm trying to package a Go application which depends on a Go library (that I'm also packaging myself). This library includes //go:embed directives on its source files to consume some SQL static files that it uses to initialize some application storage. From what I've read, these directives must be relative paths (meaning I can't patch this path to point to a /gnu/store/... one)
<ardon>and can't take symlinks. The last point is what is particularly bugging me. Since I'm referencing the library to build the Go application, I believe Guix uses symlinks from /tmp/guix-build/... and thus I always end up with "pattern xxx: cannot embed irregular file xxx" errors.
<ardon>I can submit this as a bug if it's too long to discuss here.
<ardon>Also, I should note that if I simply `substitute*' these directives for empty strings, it successfully builds but I consequently get runtime errors when launching the application
<civodul>ardon: hi! yes, it might be easier to discuss on the mailing list since the setup sounds a little tricky :-)
<civodul>i'm not familiar with Go; //go:embed is some sort of #include feature?
<efraim>oh nice, python on core-updates can be built with openssl@3
<ardon>civodul: Thanks, I'll open a bug report in a sec. I'm not familiar with it either, but from what I could gather from here https://pkg.go.dev/embed it's a way to embed static files within the source without having to make OS calls
<abrenon>does markdown formatting work in an email to the patch tracker (specifically, can I use ``` … ``` for verbatim blocks to report errors ?)
<sughosha>abrenon: Thanks for reviewing my patches. I replied but it may take some time to reach on the website. I will make the required changes and resend the patches.
<mbakke>ardon: so package B is embedding files from the source of package A?
<ardon>mbakke: As far as I can tell, package A (the Go application) needs package B (the Go library) as input, and package B has those "//go:embed" directives on one of its source files which point to SQL files in the same directory as that source file, which gets run when package A is built. However, building package B on its own doesn't produce any errors.
<nckx>Gooberpatrol66: Then there is no reason to ever pull as root or have a separate 'root's guix', unless you deliberately want two guixes that are out of sync. Most people don't. Guix System doesn't use root's guix for anything. Root is just another user, not 'the system'. You'd just be permanently wasting space on the closure of an old guix by pulling as root.
<nckx>Gooberpatrol66: The better solution for the average user is to only ever pull one cuix (their own) and use 'sudo guix' with that.
<nckx>sneek: later tell KarlJoad: There isn't really any Guix 'IRC infrastructure' or server to put there :-) Libera (once 'Freenode') provides a competently staffed network of servers, we don't host our own.
<nckx>sneek: later tell KarlJoad: even sneek isn't owned or operated by Guix, it's maintained & hosted by a #guile regular and was invited here long ago. She's Bobot++ extended with Guile, IIRC. I don't know if & where the code is hosted.
<sughosha>`guix lint` is only saying that the line is too long.
<sughosha>I tried `guix style` but that didn't affect the long line in description.
<sughosha>abrenon: Sorry, I forgot to ping you for the above reply!
<silicius[m]>I have a patchset to send. Am I reading the manual right that I should send the cover letter first, wait for the bug number and then send the patches to that bug?
<mbakke>ardon: I see, so the problem is that the GOPATH directory structure configured by Guix uses symlinks, and thus the Go compiler refuses to resolve those embed directives? sounds like it warrants a bug report indeed
<mbakke>ardon: in the mean time, you may be able to work around it by (delete-file-recursively "the/library"), and then (copy-recursively (assoc-ref inputs "the-library") "the/library")
<civodul>better let others fix GCC 12 issues before
<bjc`>speaking of compiler updates, do we have anyone who works on go? i need 1.18 for some stuff, and while ‘--with-commit=go1.18’ seems to work and pass all tests, i feel like someone with more expertise should probably be involved here ;)
<sneek>bjc`, muradm says: there are other things that depends on cgroups, especially docker, in order to not break others, i decided to maintain the compatibility. and as I point in my comments, i suppose that cgroups should be a dedicated service-type, instead of coming with either elogind or seatd
<bjc`>sneek: later tell muradm: i've come to the same conclusion, but from a different angle; i think it should be in %base-filesystems (it'll still be removable if its placed there) because it's lower-level than elogind/greetd, and the only way that i can see to make sure it's always mounted before them (without even larger infrastructural changes) is to put it in with the rest of the initial filesystems
<civodul>you could try to "guix install guix-jupyter --without-tests=guix-jupyter", which will allow you to go further if the test failures aren't fatal
<efraim>Oh, I was wondering about gcc-10.4.0, just got the email
<necrophcodr[m]>civodul: i will definitely try without the tests. of course it'd be ideal if those passed, but for me right now i'm just doing some research so as long as it isn't fatal that could definitely work!
<civodul>rekado: shouldn't we make simple-texlive-package public?
<civodul>that'd be convenient for users who import packages and would like to have them in their manifest
***jess is now known as JESS
<muradm>sneek: later tell bjc`: the other day we were discussing lxd requiring cgroup2, i have some draft patch that splits cgroup-fs and updates to v2. i promised to look at it in the weekend, but unfortunately had lack of time. will try to catch up upcoming weekend
<sneek>muradm, bjc` says: i've come to the same conclusion, but from a different angle; i think it should be in %base-filesystems (it'll still be removable if its placed there) because it's lower-level than elogind/greetd, and the only way that i can see to make sure it's always mounted before them (without even larger infrastructural changes) is to put it in with the rest of the initial filesystems
<peterpolidoro>so if I need a shell with packages and certain environment variable set and a PATH that only includes the the /gnu/store/*profile/bin then I need to set those variables outside of the guix.scm file or the manifest.scm manifest?
<civodul>right, if you need extra environment variables, you need to set them by yourself
<maximed>I've heard there are many people using ThinkPads here, do they work well with Guix (System)?
<peterpolidoro>but if a guix package needs certain environment variables to be set then those can be set within the package definition?
<peterpolidoro>so you cannot set environment variables when you install a package only when you run a binary within a package
<maximed>peterpolidoro: Only when running a binary, but without the ‘within a package’ clause.
<maximed>Unpackaged programs can set environment variables too.
<peterpolidoro>I will play around with wrap-program to see if I can create a package definition to do what I need, thank you
<maximed>(Also, TBC, "guix shell", "guix install -f", etc, could be modified to support setting arbitrary environment variables, via $GUIX_ENVIRONMENT/etc/profile, but at least currently that's not implemented (yet?))
<peterpolidoro>seems like it could be useful to set some environment variables when you run guix shell
<silicius[m]>Does it makes sense to include pyinstaller for a program that uses it or it's better to make some kind of script that runs it straight from sourcE?
<maximed>silicius[m]: We package the package itself in Guix, without an indirection by packaging thee installer for the package, if that's what you mean.
<maximed>However, we usually do not run things from source.
<maximed>Usually we compile the python things first (though not always!)
<silicius[m]>The program is just python and the official workflow build script uses pyinstaller, but afaik it just bundles all the modules in one file
<maximed>Does someone know a good list of which ‘AMD Radeon Graphics’ actually work?
<maximed>I've heard that ThinkPads usually just work.
<maximed>Does someone know if this only apply to the old ones or also the new ones?
<mbakke>'./pre-inst-env guix build --target=aarch64-linux-gnu nspr' fails on "core-updates", and the backtrace suggests that both (%current-target-system) and (%current-system) were #false in a call to (hurd-target? ...) down the stack
<mbakke>somehow other packages are fine, except those that depend on nspr/nss
<mbakke>the target-hurd? call is from bdw-gc.scm, which pretty much anything depends upon
<mbakke>I don't get why only nspr is affected by this, ideas?
<mbakke>this also happens with -d, no need to actually build anything
<nckx>maximed: The meme factor definitely comes from the old machines, with coreboot support etc. I'm very happy with my X230T but haven't tried newer ones.
<unmatched-paren>nckx: I think maximed is buying a new laptop, which obviously would come with Windows by default, so they want to get their money back on the pre-installed Windows (which certainly isn't free)
<maximed>unmatched-paren: Yes, though looking at some documents, apparently it shouldn't be a refund but rather not paying for the Windows license in the first place (could easily have misunderstood though) ...
<maximed>(My current one is ductapy and only charges when held right ...)
<nckx>maximed: Talking to me? I can't say, I'm extremely forgiving with my stuff, I've learnt, compared to others.
<nckx>It goes in the bag and nobody touches the bag.
<unmatched-paren>A shame Apple didn't name it the iWatch due to legal issues. Would have been a hilarious gaffe :)
<nckx>(Still assuming you were talking to me) I don't think anything beats a Thinkpad that isn't a gimmicky toughbook with rubber bits stuck on, but older higher-end Dells I've used were very sturdy. Felt so, too,
<mbakke>I'm inclined to treat this as "non-functional data" in FSDG lingo, as it is only used as part of the build process and not user-accessible ... thoughts?
<jackhill>mbakke: we might need a lawyer, which isn't me, but I can see ND being workable in an exmple corpus, but NC seems problematic.
<jackhill>Also, I wonder how they extraced page 8, whouldn't that be making a derivative work?
<jackhill>one reading: using it as a test case is fair use in the USA. It doesn't harm the market for the original, has a different nature of use than the original, and uses only as much as is needed, so 3 out of 4 factors.
<jackhill>In which case, it can be used in freedom.
<unmatched-paren>jackhill: In situations where "we might need a lawyer" is justifiably uttered, I'd say play it safe :)
<vagrantc>mbakke: it's not clear that the original document has any licensing at all ...
<mbakke>vagrantc: it has a "CC BY-NC-ND" banner at the bottom right of the first page
<mbakke>come to think of it, it is likely many PDF/image/video test suites have similar issues
<jackhill>unmatched-paren: that's all the time though, isn't it? In the case where there isn't a technical reason folks can't exercise their freedoms (e.g. missing source), I think the question is does the law prevent them from doing so, which is the desire for legal advince, and since I'm not addmitied to the bar, I can't give any :). Onother way to do the risk assesment, is that poppler isn't some random project,
<jackhill>and Xorg/freedesktop are comforatable with this use.
<vagrantc>wow, i searched for all of the terms in the document cc, by-nc-nd, creative commons, etc. ... a single icon is sufficient to assert licensing terms?
<jackhill>also, does arxiv.org have any overall terms for submitted items?
<vagrantc>and, does the modified document have the icon used to identify the licensing terms?
<vagrantc>none of these parties has complied with the terms of CC BY-ND-NC ... they all fail to give attribution
<unmatched-paren><vagrantc> none of these parties has complied with the terms of CC BY-ND-NC ... they all fail to give attribution
<vagrantc>i remember documenting the licensing for guix when packaging guix for debian, and it was an exhausting list of copyright holders, but there were very few issues that made me squint or grimace :)
<vagrantc>unmatched-paren: the authors of the original document are presumably the relevent parties ... but who knows, maybe the universities involved own the copyright
<vagrantc>and this is why most of the world just doesn't pay attention :)
<jackhill>at least it's only two universities to check…
<vagrantc>seems worth raising the issue upstream, at least
<vagrantc>maybe also ask the debian maintainers, to have another avenue of concerned parties who pay attention to licensing
<maximed>Updates #56290 with system / foreign distinction.
<jts>does anyone know what the error "expected a regular file" when running `guix build -f guix.scm` might be, when guix.scm is a (at least syntactically) well-formed package definition that returns the package it defines?
*mbakke needs to find a way to tag away patches and bugs that have been closed
<maximed>Though the mail program is a bit inaccurate, it counts mails I sent myself and counts mails I read quickly.
<vagrantc>mbakke: i have no need of more email, really, quite happy with guix so far :)
<mitchell>When i run guix system build on the installation os it fails with the error `guix system: error: canonicalize-path: no such file or directory:"/gnu/store/...-guix-1.3.0-27.../share/guile/site/3.0/gnu/installer/aux-files/logo.txt". How can this happen?
<mbakke>maximed: is your GPG public key available somewhere? I could not find it on my usual keyservers
<mbakke>mitchell: file system or store corruption perhaps? you could try 'guix gc --verify=repair,contents' (warning: expensive)
<KarlJoad>Does Guix have an equivalent to Nix's buildFHSUserEnv for shell environments? Does Guix even need it?
<sneek>KarlJoad, nckx says: There isn't really any Guix 'IRC infrastructure' or server to put there :-) Libera (once 'Freenode') provides a competently staffed network of servers, we don't host our own.
<sneek>KarlJoad, nckx says: even sneek isn't owned or operated by Guix, it's maintained & hosted by a #guile regular and was invited here long ago. She's Bobot++ extended with Guile, IIRC. I don't know if & where the code is hosted.