IRC channel logs

2021-11-29.log

back to list of logs

<unmatched-paren>yes, it looks like pkg-config is getting stuff wrong :|
<unmatched-paren>when i build libmpack-lua traditionally, the things are in .deps/usr/*/lua/5.1, not lua5.1
<civodul>cbaines: alright, i'll let it run overnight, thank you!
<unmatched-paren>there's no pkg-config entry for lua 5.1 in my PKG_CONFIG_PATH... strange
<vagrantc>huh. passing --max-jobs to time-machine worked.
<unmatched-paren>rekado_, is there some other place i could look for clues about why pkg-config is misbehaving?
***mab is now known as bandali
*vagrantc wonders if that's where --keep-going belongs too
<rekado_>unmatched-paren: well, *is* it misbehaving? It only prints what the package’s .pc file tells it to print.
<rekado_>are the installed .pc files for lua5.1 reporting the wrong locations?
<unmatched-paren>ok i'm going to try to copy the lua5.3.pc into a ~/.local/share/pkgconfig/lua5.1.pc file, then add that dir to PKG_CONFIG_PATH, then edit the 5.1 file until stuff works
<unmatched-paren>see, there are no .pc files for lua5.1
<unmatched-paren>okay so that didn't work
<unmatched-paren>i think guix's packages might be at fault here
<rekado_>civodul: looks like VACUUM completed. At long last I was able to copy outputs from the build nodes!
<lfam>More problems with Github's auto-generated tarballs: <https://github.com/github/feedback/discussions/8149>
<lfam>Although this one seems like more of a mistake than a deliberate choice
<user->hello
<lfam>But it vindicates our approach of preferring to use Git sources directly
<user->does anyone know if there is a channel that offers the most recent stable version of Kodi
<user->guix install kodi installs 18.8 the current version however is 19.3
<rekado_>civodul: db.sqlite is down to 12G now
<unmatched-paren>i think i have it! the makefile defines the installation stuff for lua packages! if i patch that, it might work
<unmatched-paren>it feels really good to make progress :D
<singpolyma>I've never understood why anyone uses tarballs
<civodul>rekado_: oh yes, it has just completed!
<unmatched-paren>i might not even need to patch it, i can just redefine the variable i think \o/
*vagrantc wishes there was some sort of git proxy guix could use to avoid re-downloading needless history across multiple revisions
<unmatched-paren>oh, hm, okay, looks like i've already done that without noticing
<lfam>user-: Maybe there is such a channel, I haven't heard of it. I figure that if somebody wanted to work on keeping Kodi up to date, they'd do it within Guix proper rather than a 3rd-party channel
<civodul>you could also try "guix install kodi --with-latest=kodi" (no guarantees)
<lfam>singpolyma: There are tarballs, and then there are tarballs. In many cases, upstream releases a tarball that is substantially different than what is in their Git repo. As a distro we have to decide what to build from on a per-package basis
<lfam>But the tarballs under discussion are not those created by upstream, but rather automatically generated by Github per-tag
<rekado_>any takers for this patch set: https://issues.guix.gnu.org/49834#16 ?
<vagrantc>it's often more expensive to use git-fetch than url-fetch ... though there are huge advantages to using git-fetch anyways
<lfam>Definitely it's more expensive, in many ways
<unmatched-paren>the Makefile looks fine, and the recipe looks fine, so it looks like pkg-config is at fault here...
<lfam>It would be helpful to get some more opinions on <https://issues.guix.gnu.org/52162>
<singpolyma>vagrantc: could shallow clone if the repo is huge, I guess
<unmatched-paren>lemme see if i can patch the install stage entirely
<vagrantc>singpolyma: even shallow clones are expensive, and not all servers supportit
<jgart>rgherdt, awesome! thanks for sharing. That's great to hear/know
<rgherdt>jgart: yw
<user->lfam: if it comes to it i will make it. im really new to guix thats the only thing preventing me from diving in :)
<unmatched-paren>...ok i feel stupid now, i had forgotten to update the nvim recipe to use patched-lua5.1-mpeg :P
<lfam>user-: Okay, we are here to help if you need it :)
<unmatched-paren>neovim is building now \o/
<unmatched-paren>it builds :D
<lfam>user-: The Contributing section of the manual should give complete instructions about setting up a development environment (for testing package updates and other changes): <https://guix.gnu.org/manual/devel/en/html_node/Contributing.html>
<lfam>And we can help advise beyond that
<unmatched-paren>WOO!
<lfam>:)
<user->lfam: thanks. that is useful
<unmatched-paren>Neovim 5.1 has been installed and is running \o/ now i'll try nightly
<user->civodul: thank you. this started the install but failed with error "build of /gnu/store/rffq80l3iny3fqnr6mx838xgfml7js25-kodi-19.3-Matrix.drv failed"
<lfam>user-: It should have also printed the path to a log file
<lfam>That log would offer more details about what went wrong
<lfam>Looking at the current Kodi package definition, it does seem moderately complex: <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/kodi.scm?id=4883d7fe9ea68c2f4c2f9af01e350ec9c038b689#n272>
<lfam>I'd expect a major update like 18 -> 19 to require some changes
<lfam>It might be trivial to update to 18.9, though
<user->what does --with-latest comand do?
<user->im guessing some required packages were not accounted for
<lfam>user-: It's a "Package Transformation Option": https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html
<lfam>" It replaces occurrences of package in the dependency graph with its latest upstream version, as reported by guix refresh"
<lfam>You could also try, for example, `guix build --with-commit=kodi=18.9-Leia kodi`, to test the update to 18.9
<user->ok i dug through the log. it seems like required packages was the problem
<lfam>But, these package transformation options are not magic
<lfam>Yeah
<lfam>They do what they say on the box, but nothing else
<user->is there a way i can force the packages to be installed
<user->without installing one-by-one
<lfam>In Guix, package builds take place in an isolated container. The rest of your system has no relationship to building packages
<lfam>Every dependency is specified in the package definition
<unmatched-paren>somehow seeing my old neovim config again is extremely nostalgic
<lfam>user-: So, the best approach to testing this update is to set up a Guix development environment, and then work from that
<user->ok thanks for the tips
<user->i will look into this more
<zacchae[m]>vdv: I have that in my list of services. I don't specify name-server or gateway, but the error seems unrelated to that. guix is complaining about having a static-network-service in addition to the network service in %desktop-services.
<unmatched-paren>urgh making a channel needs you to do stuff with gpg :(
<jgart>KE0VVT, raghavgururajan I have a librebooted X200T also but CPU overheats and fan growls. Might turn it into a low powered server or machine for experimenting. I had purchased it from an electronics recycling warehouse in Miami for $4: http://www.escrapusa.com/. Parabola is currently on it.
<unmatched-paren>gpg and git stuff are exactly the kind of things i hate doing
<jgart>I purchased about ~20 old librebootable thinkpads from them at that price until they suddenly raised the price on me ha
<jgart>unmatched-paren, would be cool if guix supported signify for signing as an alternative to gpg
<lfam>+1
<unmatched-paren>what's signify?
<jgart>seems like a simpler implementation
<unmatched-paren>oh ok another pgp implementation
<lfam>No, it's not PGP
<lfam>It's a radically simpler asymmetric crypto signing implementation
<lfam>It has nothing to do with PGP in any way
<jgart> https://flak.tedunangst.com/post/signify
<lfam>It's like the simplest possible asymmetric signatures tool
<jgart>void linux uses it as does openbsd
<unmatched-paren>simpler is good :D
<jgart> https://man.voidlinux.org/signify.1
<lfam>We have a couple implementations packaged
<jgart>Guix has signify packaged
<lfam>Also, minisign and asignify
<jgart>guix (show||edit) signify
<jgart>gpg can have annoying bugs sometimes
<lfam>I think it's similar to Git in that they both have humongous problem spaces, and are thus extremely complex
<lfam>However, it turned out that Git's big problem space was valuable to solve, whereas PGP's was not
<jgart>I currently have an issue with gpg on my machine that I haven't bothered to continue investigating which is preventing me from contributing to a guix channel. Spent some time investigating it to no avail
<lfam>So, signify is like a do-over of the part of PGP that got widespread adoption, signatures
<jgart>I prefer doas to sudo also
<lfam>I could probably help solve your gpg problem. I've gotten pretty adept with it via Guix work
<jgart>I only use doas on my gnu/linux machines
<jgart>lfam, thanks for the help
<jgart>let me see if I can reproduce it
<jgart>I haven't bothered looking at it for a while since I only use gpg currently for signing commits to a guix channel
<lfam>I'm going to eat dinner but I'll be back later to check any messages
<jgart>cool, I'll just tag you here. But thanks again
<unmatched-paren>nvim commit 6e70b7b31d224d94abbd6bc66a0b64d7db88f326 builds flawlessly too \o/
<jgart>lfam, error: gpg failed to sign the data
<jgart>lfam, fatal: failed to write commit object
<jgart>lfam, that's from running `git commit -S`
***unmatched-paren_ is now known as unmatched-paren
<unmatched-paren>one small snag: some of the tree-sitter parsers are failing to compile, presumably because of the old tree-sitter version
<unmatched-paren>i'll try to update it tomorrow, bye :)
<jgart>unmatched-paren, what branch?
<jgart>unmatched-paren, how's it going with the tree-sitter packaging?
<lfam>jgart: I think I saw this recently when my key had expired
<KE0VVT>How do I install GNOME extensions?
<apteryx>rekado: about pipewire, just nobody got around to it; I tried go to the latest version, there was some problem, quit. The version before the last one works though, and there's a patch for it on our tracker
<jgart>lfam, 2021-04-24 [E] ;)
<lfam>There you go
<lfam>For a few months I was doing this:
<lfam>`guix environment --ad-hoc libfaketime -- faketime '2020-11-10 12:34:56' git rebase HEAD --exec "git commit --amend --no-edit --gpg-sign"`
<lfam>Until I could bring myself to dig my offline master key out of storage and properly adjust the expiration date
<lfam>When code-signing, the existence of an expiration date is somewhat misguided
<jgart>lfam, how do you do gpg? are there any practices you follow that might not be obvious to a new user?
<lfam>Well, there's unfortunately very little about it that is obvious to a new user
<lfam>I do think my set-up is fairly standard, as far as it goes for gpg / pgp
<lfam>I have a "master" key that lives offline and never touches a computer that is connected to a network
<lfam>All the keys that actually get used are "subkeys" of this ke
<lfam>key
<jgart>how did you learn to do that?
<lfam>I recall that there are some advantages to this complicated arrangement, but I don't remember what exactly they are
<jgart>any easy guides we can follow?
<lfam>I bookmarked these three blog posts:
<lfam> https://alexcabal.com/creating-the-perfect-gpg-keypair/
<lfam> http://www.connexer.com/articles/openpgp-subkeys#tweaking
<lfam> https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html
<lfam>I guess I cobbled it together from there
<apteryx>lfam: advantage is that if one of your subkeys get compromised, you revoke it, generate a new one from your master key, and don't loose any trust signatures accumulated on that master key.
<jgart>ah thanks! I'll take a look. much appreciated
<lfam>I see apteryx
<apteryx>(you do not have to rebuild your web of trust)
<lfam>Right
<lfam>It's a use case that you don't hear much about any more (web of trust)
<lfam>jgart: I have a note about the 3rd link: "Updated for GnuPG 2.1"
<lfam>gpg changed a bit between 1.4 and 2.1, with a middle phase in 2.0
<lfam>So you do want to make sure to target your learning to 2.1
<jgart>I've heard some complicated gpg signing stuff in conversation but can't remember all the details now
<jgart>like signing you master with another key...
<jgart>something like that...
<jgart>s/you/your
<jgart>apteryx, lfam maybe that's what you're referring to regarding subkeys. Having a master key that you sign other keys with. Master key is never used online but only for signing other keys that are used online?
<lfam>I don't really sign other keys
<lfam>If I were to start over I would probably do something simpler
<apteryx>jgart: yes
<jgart>apteryx, cool
<jgart>yes, that was explained to me once
<lfam>I think it's important to remember that asymmetric cryptography was only "discovered" a few decades ago, and only became accessible to the public in the 1990s
<jgart>but I forgot all the details. I might have some notes somewhere about it
<lfam>Whatever designs were created then were the first designs, and probably history will show that we didn't get it quite right
<jgart>unfortunately it seems like security practices are only getting looser nowadays with regards to signing
<lfam>In what sense?
<jgart>distros only giving shasums for example and no gpg signing
<jgart>not guix
<jgart>but elementaryos, for example to take one example
<jgart>elementaryOS
<jgart>i've seen a few others
<lfam>Overall, I think the idea is that cryptographic signing should never be presented to the user, but rather handled automatically in software
<lfam>Like in Guix
<lfam>Whether or not those other projects do that, I don't know
<jgart>using binaries without signing like people do on github
<jgart>for example, how go binaries are distributed sometimes
<jgart>and recommendations to curl into shell
<jgart>as a means of installing
<jgart>nix recommends that for example
<jgart>which is unsafe of course
<lfam>Ahem... Nix is not the only one ;)
<jgart> https://nixos.org/download.html
<lfam>I mean, in any case, the initial introduction to a new software ecosystem (like a distro) is going to be secured by the combination of TLS and DNS
<jgart>curl -L https://nixos.org/nix/install | sh
<jgart>there was a company that was hacked just a few years ago that way
<lfam>Don't forget our own instructions ;)
<lfam> https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
<podiki[m]> https://github.com/drduh/YubiKey-Guide this is very helpful (not only for yubikey)
<lfam>`wget && ./foo`
<lfam>It's basically the same thing
<lfam>And you run it as root!
<lfam>So, TLS and DNS are doing all the work
<jgart>is it?
<jgart>I inspect the shell script first
<lfam>Internally, the script verifies a signature, but that's under the control of whoever can serve the script to your wget command
<jgart>then I run it
<lfam>Sure, but I don't think that the objection to `curl | sh` is that you can't read it. I feel like approximately nobody reads it anyways. And it is some complicated shell, so not that easy to read either
<lfam>My understanding is that the objection pre-dates the recent push to use TLS for *every* HTTP connection
<lfam>With TLS, the calculus changes
<jgart>I don't ever pipe random scripts to shell
<jgart>from the internet
<lfam>That's a good idea, but it's quite common to do the opposite
<jgart>right
<lfam>So the question was, how do we make the typical behaviour safe?
<lfam>The answer that we are living through now was "make TLS mandatory"
<jgart>the times they are a changing 🎶️
<lfam>And the browsers have worked hard to make that a reality, and to squash certificate authorities who could ruin the security of TLS
<lfam>So now the recommended way to install Guix is to wget a script and run it as root
<jgart>hmmm, I'll have to read up a bit more on this
<jgart>but that's good to know
<jgart>lfam, what's the guix practice for packaging multiple go versions of a library?
<jgart>similar to rust?
<lfam>I really don't know what's the best practice
<jgart>I'm working on https://github.com/honza/smithy
<lfam>There's been a lot of discussion about it but I don't think any of the proposals have been enacted (I could have missed it!)
<jgart> https://git.eletrotupi.com/
<jgart>it's a javascript free git forge
<lfam>My personal recommendation is to use the exact versions specified by whatever you're packaging, and if we already have the dependencies at other versions, add new packages with the correct version
<jgart> https://git.pokorny.ca/
<lfam>It might be annoying but Go software does not really have a concept of "versions", so you really have to use the exact Git commit to make sure that everything works
<jgart>lfam, what's your goto way of checking if upgrading a package will break others?
<lfam>Go doesn't even really have a strong concept of "external dependencies". You're supposed to bundle ("vendor") all of your dependencies
<lfam>I would use `guix refresh -l foo` and then try rebuilding everything
<jgart>is there a way that you rebuild everything without having to type em all?
<lfam>But for Go, I would add new packages with correct versions rather than upgrade existing packages
<lfam>Copy and paste
<lfam>You could even use cut
<apteryx>lfam: that's not really true anymore no? Go has this module system, which is versioned; and I seem to recall that vendoring is discouraged
<lfam>Yeah, like I said, I probably missed things
<apteryx>the problem is that we do not have support for Go modules yet in Guix
<lfam>Right
<jgart>lfam, so I inherit packages to add new versions?
<lfam>Yeah jgart
<jgart>ok
<lfam>apteryx: But even with the "versioning", my impression is that it's really "per commit" rather than what we would consider a proper version, with some compatibility promises in minor releases
<lfam>But maybe the situation is changing. I haven't paid attention to Go in a while
<jgart>I saw that rekado added multiple versions of some rust packages that were not inherited from recently
<jgart>when should I inherit and when should I not?
<lfam>You can use inheritance or not. They are equivalent in terms of code, but maintenance burden is a little higher with inheritance
<lfam>It can be hard to understand the inheritance later on
<jgart>ohh ok
<jgart>but one practice is not discouraged over another, correct?
<jgart>both are fine
<lfam>Not officially
<jgart>for upstream
<jgart>ok
<lfam>I mean, officially both are fine
<jgart>cool
<lfam>If the inherited package doesn more than just change the version, I suggest avoiding inheritance
<lfam>Your future self will probably be grateful
<lfam>I think it would be awesome to have a "modern" Git forge supported in Guix with packages and a service
<jgart>that sounds good to me and makes sense for readability by a human
<jgart>it would be cool for guix to support fossil
<lfam>You might take a look at the ffmpeg packages for an example of some complicated inheritance
<lfam>It can be tough to understand how all the changes propagate down the hierarchy of inheritance
<jgart>lfam, thanks! I'll take a look at those
<jgart>lfam, do you happen to know if this is required in our st package? https://issues.guix.gnu.org/51627
<lfam>I don't, sorry
<lfam>Did it fix a problem for you?
<jgart>I feel like it fixed a bug for me with 256colors
<jgart>but I wasn't able to reproduce it on another machine
<jgart>I packaged an st fork for a guix channel that definitely had the issue. It was inheriting from guix's st
<jgart>then I compiled the terminfo files and it went away
<jgart>lfam, does st work for you currently as is in guix master branch?
<lfam>I don't know, I'm not using it. And I feel like testing it on Debian wouldn't be a good test
<jgart>lfam, another question I have is regarding the following: https://issues.guix.gnu.org/52160#5
<jgart>I upgraded the python language server recently
<jgart>The version in guix is deprecated
<jgart>The spyder team forked palantir's lsp server and continued maintaining it. So people have now moved to python-lsp-server instead
<jgart>Since it is a fork I edited the deprecated version in the master branch instead of removing it and starting from scratch.
<jgart>Is this a problem for the commit history/diff that upstream guix wants to see?
<lfam>No
<lfam>But, you should take care to make the deprecation work properly with the Guix tooling
<lfam>I think you did that
<jgart>it would be a bit tedious now to try to retrospectively reproduce the deletion of the old version
<jgart>lfam, yup I did
<jgart>I added the deprecation aliases where needed
<lfam>Great
<jgart>I had to also upgrade python-jedi in the process
<jgart>and another python library iirc
<jgart>unfortunately debbugs broke my patch series in two.
<jgart>the other half is here: https://issues.guix.gnu.org/52161
<jgart>52160 and 52161
<jgart>I think I learned what I need to do from now on to avoid that as it says in the manual
<jgart>to avoid that quirk in debbugs
<jgart>there was some discussion earlier about it
<jgart>singpolyma, how do you like qtile? I've had it on my list of tiling window managers to explore further for a while now
<lfam>Huh
<lfam>jgart: Should we merge the two tickets?
<jgart>singpolyma, I saw that your patch for qtile got accepted recently. That's great!
<jgart>lfam, yes they go together
<jgart>do you need me to do something on my end?
<singpolyma>jgart: it's ok. I'm used to dwm but qtile is neat. I'm interested in it partly to see how closely I can get it integrated with xonsh etc
<jgart>singpolyma, dwm is my daily driver
<jgart>I keep coming back to dwm
<lfam> https://debbugs.gnu.org/server-control.html
<jgart>singpolyma, I might try frankenwm next
<lfam>You can send a message that contains "merge 52160 52161" to <control@debbugs.gnu.org>
<lfam>It's not going to do exactly what we would want, but it will link the two tickets together so that reviewers know about both
<jgart>singpolyma, I tried bspwm for a bit and I ended up trying to configure it to match the exact same keybinds as dwm via sxhkd
<jgart>lfam, thanks!
<jgart>hopefully I don't tear the house down with that email haha jk
<singpolyma>jgart: I like the ability to pin one window to the side for my gajim roster
<jgart>lfam, where can I learn all these email codes for debbugs?
<lfam>From that server control web page I linked to
<jgart>singpolyma, wdyt of adding guile ffi bindings to adjust dwm colors? vanity fair?
<jgart>lfam, cool! thnx
<singpolyma>jgart: why not just write yet another WM in guile? ;) Or run qtile on python on guile. That would be hot
<jgart>singpolyma, https://github.com/fadein/swm
<jgart>qtile on python on hy on ...
<jgart>singpolyma, how does xonsh compare to fish?
<jgart>maybe they're not comparable...
<jgart>I've only tried fish
<singpolyma>I haven't used fish, but a huge thing with xonsh is I can import any python lib at the command line
<jgart>that's dope
<jgart>ye I had read about that
<jgart>I should try it sometime
<jgart>singpolyma, have you used guix to manage python deps for xonsh?
<jgart>like, using pandas installed with guix in xonsh?
<jgart>same question for qtile?
<singpolyma>I can import the qtile control lib in my xonsh, qtile in guix, xonsh from debian
<jgart>I see the xonsh package in guix is pretty out of date
<jgart>I use jrnl installed with xbps because guix's jrnl is way out of date
<jgart>the latest version of jrnl is blocked by pep 517
<singpolyma>I like typing things like json.loads($(curl blah))
<jgart>ha, very cool!
*jgart installs xonsh
<singpolyma>Also curl blah --data-ascii @(json.dumps({...}))
<singpolyma>xonsh has a readline mode, but if you like fish you'll want the other (usually default) one
<jgart>I've been shell hopping
<singpolyma>I prefer the rash syntax I think, and the schemeyness vs the pythonness, but rash has a barely working interactive mode
<jgart>void packages some obscure ones
<jgart>singpolyma, I had a short stint with rash
<jgart>I should probably come back to it
<jgart>singpolyma, https://github.com/andrewchambers/janet-sh#quick-examples
<jgart>janet-build-system would be nice to go with it ;)
<jgart>yet another project
<jgart>singpolyma, https://acha.ninja/blog/dsl_for_shell_scripting/
<singpolyma>I'm mostly interested in interactive, because I want it for my daughter once she's old enough. Interactive first, leading to scripting later
<jgart>singpolyma, this perl package: https://metacpan.org/dist/Graph-Easy can render `guix graph ...` as ascii
<jgart>singpolyma, that's great! Sounds like a good workflow
<singpolyma>Shell interaction is the most natural place (of currently useful tools) to program by accident
<jgart>singpolyma, patch paste for graph-easy: https://paste.sr.ht/~jgart/784fe79261f31581cd88bceb4941ff780d4562a9
<jgart>singpolyma, I agree
<singpolyma>Anything with a real programming language for config file comes next I guess.
<jgart>I think that's where I started
<jgart>iirc
<singpolyma>So, xonsh, I can write qtile configs in xonsh, kitty and gedit plugins in xonsh
<singpolyma>Python isn't my favourite, but this stuff all exists already
<jgart>yup
<jgart>I feel the same about python
<jgart>so much great stuff exists already in that ecosystem
<singpolyma>The idea is to give her an environment where they syntax she uses to drive the main shell can also be used to mold as many other parts of the system as possible
<jgart>it can atleast be a detour before RIIG
<singpolyma>And to do it without me spending a decade writing it all, since she's already 4 now
<jgart>sounds like she's on her way to becoming a super hacker
<singpolyma>Hehe. Or at least know what a computer is and how to drive one at a minimum I hope
<lispmacs>I wrote a package definition a year or so ago that was dependent on gcc-toolchain, but now it is broke because all versions of gcc-toolchain now dependent on a newer, incompatible version of glibc
<lispmacs>how do I override the glibc version used by my package?
<sam_>.. how new of a glibc?
<jgart>lispmacs, in theory `guix time-machine ...`
<lispmacs>I want the package itself fixed, not to time-machine back
<sam_>(I'm wondering why you can't just change the definition of your thing)
<sam_>(or fix your thing with new glibc)
<jgart>back to the future(s)
<lispmacs>sam_: I want to change the definition of my thing
<lispmacs>can I override somehow the version of glibc used by gnu-toolchain, with some guile trick in the package definition?
<lispmacs>right now it just has a package defintion specifying gcc-toolchain
<lispmacs>I was hoping for something like (replace-glibc gcc-toolchain older-version)
<lispmacs>or (substitute-dependency gcc-toolchain glibc-2.30)
<lispmacs>some trick like that
<lispmacs>I was sure I saw there was a way to do that in some video or blog post I read ages ago, but can't remember any details
<apteryx>lispmacs: you don't use gcc-toolchain in a package definition; you use gcc directly there
<apteryx>you can override the default GCC version used by simplying adding your own to native-inptus
<apteryx>but since you want to override the default glibc maybe that's why you thought about using gcc-toolchain?
<apteryx>I'm not sure how that's done, but grepping the source would probably yield examples, hopefully.
<excalamus>good evening, guix
<jgart>lfam, I sent the merge command
<lfam>It worked!
<Guest13>Hi, I am looking forward to install guix as a main system. Is xserver included in vanilla install? Or it will be better to google all basic packages first, and write it on paper?
<podiki[m]>Guest13: the graphical installer will give you options to pick from like Gnome or EXWM, also handling xserver
<Guest13>Great! Thanks
<jgart>lfam, awesome! TIL debbugs
***roptat is now known as Guest1860
<jgart> https://paste.sr.ht/~jgart/3f9b9a4ef7ccc123694f6e03fb330b84a56535fd
<jgart>can anybody help me read the above build failure? What do you think the problem might be?
<jgart>> .rodata' can not be used when making a shared object; recompile with -fPIC
<jgart>lfam, tput: unknown terminal "st-256color"
<jgart>lfam, that's the error I get when I use guix's packaged st
<jgart> https://issues.guix.gnu.org/51627 fixes that issue
<rekado>apteryx: oh, I already pushed the latest version to c-u-f
<rekado>(pipewire 0.3.40)
<rekado>weston notably still needs 0.2, though. The version that builds fine with 0.3 has not been tagged/released yet.
<janneke>nevermind, the grub gfxmode setting is back after a fresh system reconfigure; not sure what happened the last time...
<abrenon>hello guix
<civodul>Hello Guix!
<unmatched-paren>Hi Guix :)
<abrenon>o/
<unmatched-paren>would anyone be interested in me making a channel for nightly neovim?
<mothacehe>hey guix!
<jgart>unmatched-paren, yes!
<unmatched-paren>ok, i'll publish it on codeberg as soon as i can figure out the GPG stuff :)
<civodul>hey mothacehe!
<unmatched-paren>can i make a package require package X _or_ package Y?
<unmatched-paren>(this is for goneovim, which will require either neovim or neovim-nightly)
<rekado>unmatched-paren: no, you’ll have to pick one or the other.
<unmatched-paren>ok, i'll make a (make-goneovim) procedure and then use that to make a goneovim-with-neovim-stable and goneovim-with-neovim-nightly
<jonsger>efraim: your PHP update brought two new testfailures :(
<unmatched-paren>i'm really surprised that there's no tree-sitter for scheme... the vim regex highlighting seems to choke on the package scheme files
<unmatched-paren>another thing for the todo list, i guess :)
<jlicht>hello guix!
<mothacehe>rekado: there's only two workers showing up on pankow and grunewald. Any chance you could create me an account on those machines so that I can investigate this issue?
<rekado>mothacehe: I don’t have enough cables to connect all three.
<rekado>kreuzberg had to give up its cable to my partner’s laptop :)
<rekado>why only two workers each: I’m not sure
<rekado>sometimes it’s four
<rekado>sometimes it’s 6 on pankow (for a short time)
<rekado>looks like you *do* have an account already
<mothacehe>yeah i saw that, we have the same issue with guix9p but all the hydra-guix-* machines do not exhibit this behaviour
<rekado>ludo, rekado, and mathieu
<mothacehe>oh right, i would just need you to initialize my password :)
<rekado>I thought we have ssh pubkey authentication
<civodul>mothacehe: i also noticed that overdrive1 sometimes displays 4 workers, even though it's running with --workers=2
<unmatched-paren>how would i get the store location of an input? is it just (assoc-ref inputs "pkg")?
<civodul>unmatched-paren: yes exactly
<rekado>doen’t work?
<rekado>I meant: does ssh pubkey auth not work for you?
<mothacehe>yes it works my ssh-agent wasn't started!
<mothacehe>looks like i will still need a password initialization to use sudo
<efraim>jonsger: for which architecture?
<efraim>I only tested x86_64 and aarch64
<jonsger>mothacehe: I saw this behaviour on my cuirass setup as well, for a short time it displays 4 workers but its configured with --workers=2 :)
<efraim>unmatched-paren: I have on my eventual TODO list to add guix package highlighting to vim-guix-vim, but it's been on there forever
<jonsger>efraim: its on x86_64 https://paste.opensuse.org/view/raw/21097907
<mothacehe>jonsger: when restarting the cuirass-remote-worker, the old workers are still in database for the communication timeout duration
<mothacehe>which explains the brief overlap
<efraim>after working on pcre on powerpc and riscv64 I'm convinced it's cursed
<jonsger>ah, thx for the explanation :)
<rekado>mothacehe: just FYI: on pankow I’m building core-updates gtk+ manually
<mothacehe>alright
<mothacehe>looks like we are missing guix daemon users on grunwald: all build users are currently in use; consider creating additional users and adding them to the `guixbuild' group
<rekado>okay, will do
<jonsger>efraim: with how many RAM did you built PHP?
<rekado>I suppose I should do that in the operating-system configuration and then deploy
<unmatched-paren>hm the goneovim build instructions are really vague...
<unmatched-paren> https://github.com/akiyosi/goneovim/blob/master/Development.md
<mothacehe>rekado: there's a build-accounts-to-max-jobs-ration thing in build-machines.scm
<unmatched-paren>it says to set QT_DIR to /path/to/qt, but i'm not sure _which_ qt library it's talking about
<unmatched-paren>libQt5Core.so? libQt5Core.so.5? libQt5Core.so.5.15???
<unmatched-paren>libQt5Core.prl, or libQt5Core.la????? there's so many! and that's just the qtCore stuff!
<efraim>jonsger: My machine has 64GB of ram
<jonsger>okay, that is similar
<unmatched-paren>the instructions expect you to download the Qt binaries from qt.io, which isn't very helpful for packaging...
<Karthik[m]>unmatched-paren: nice username BTW !
<efraim>php on master just passed the test suite again on my machine
<efraim>I have the same warning about the XFAIL test but not the pcre test
<rekado>unmatched-paren: .so .so.5 .so.5.15 — they are all the same. Just links to one another.
<rekado>the .la is a libtool wrapper, I think. You can ignore it for the most part.
<rekado>no idea what .prl is, but I’m guessing it’s not important
<rekado>mothacehe I keep getting an error when trying to deploy to pankow/gnurewald. The error is because of offloading to 10.0.0.4.
<rekado>how can I tell Guix not to offload to .4 any more?
<mothacehe>not sure there's a per-machine granularity
<civodul>rekado: you'll have to comment out .4 in /etc/guix/machines.scm
<jonsger>efraim: got a substitute for PHP now, so the issue passed silently away :)
<unmatched-paren>i think i might give up on goneovim for now
<unmatched-paren>it uses some weird amalgam of the qt and go build systems and i can't figure it out
<unmatched-paren>gnvim uses rust, which i'm much more familliar with, and gtk, which is probably just as bad as qt
<unmatched-paren>and neovide doesn't use a toolkit, only vulkan
<unmatched-paren>i think i'll try neovide
<unmatched-paren>a shame it's so hard to build because goneovim had quite a few nice features like built in minimap and indent guide :(
<ss2>hello!
<ss2>I'm trying to package gotk3. Unfortunately it is failing, and I can't see why yet: https://paste.rs/64F
<unmatched-paren>what's the error?
<ss2>Additionally, I noticed that many go packages are named URL-projecthost-projectname, should I copy that schema as well?
<unmatched-paren>yes probably
<ss2>hang on.
<unmatched-paren>go can be a pain :)
<unmatched-paren>a lot of modern languages seem to be made with almost zero thought for distro packaging
<ss2>the output broke paste.rs, and paste.debian thinks that I'm spamming.
<unmatched-paren>try bpa.st
<ss2>Text exceeds spam score.
<ss2>...
<unmatched-paren>can you try to cut it down? does the output include lines of filenames?
<unmatched-paren>remove said filename lines, since they're just the output of tar -xvf
<ss2>I do. It looks as if I'm temporarely banned now.
<ss2>need another paste service now. :/
<unmatched-paren>the output shouldn't be that long... there must be some parts that you can snip
<ss2> https://paste.debian.net/1221221/
<ss2>yeah, pasting the whole lot, or long lines is problematic.
<unmatched-paren>maybe each folder in github.com/gotk3/gotk3 is supposed to be a different package? the issue looks to be that there's no .go files in the root of the repo. there's a go.mod though...
<unmatched-paren>" Each component is given its own subdirectory"
<ss2>so, each module represents it's own package?
<unmatched-paren>sounds like you'll need to make a github-com-gotk3-gotk3-gtk package, a github-com-gotk3-gotk3-glib package, etc.
<unmatched-paren>ss2: looks like it
<unmatched-paren>try guix import github.com/gotk3/gotk3/gtk
<unmatched-paren>sorry
<unmatched-paren>`guix import go github.com/gotk3/gotk3/gtk`
<ss2>actually guix import github.com/gotk3/gotk3 gives me close to that what I've already prepared, but say ../gtk failes.
<ss2>reason: "https://proxy.golang.org/github.com/gotk3/gotk3/gtk/@v/list" could not be fetched: HTTP error 410 ("Gone").
<unmatched-paren>really sorry, i have virtually no experience with go :(
<ss2>neither do I. I just created a sub package with -gtk, extracted to github.com/gotk3/gotk3, imported to ../gtk, and it failes with the same error.
<ss2>got it! #:import-path does the trick.
<ss2>*setting
<unmatched-paren>\o/
<mothacehe>thanks for increasing the build accounts count rekado
<mothacehe>i'll run a custom cuirass-remote-worker service on grunewald to investigate the missing workers issue
<mothacehe>at first sight, looks like the two missing workers are running but somehow stuck. gdb/strace is really helping me.
<unmatched-paren>noooo neovide needs new nvim!
<mothacehe>*isn't really
<unmatched-paren>*new rust
<apteryx>rekado: re pipewire, thank you!
<apteryx>which package do I need for a GCC x86_64 --> i686 cross compiler?
<apteryx>ah, standard-cross-packages helps (in (guix build-system gnu))
<unmatched-paren>guix doesn't have skia packaged?!
<apteryx>what should I do at the package level to cause the implicit cross-compilation inputs to be added?
<apteryx>set #:target manually?
<unmatched-paren>...i think i'll just use nvim in the terminal for now :)
<apteryx>another question: what happens to the 'inputs' when cross-compiling? seems they just get ignored? ,@(if target '() inputs) -> in lower in (guix build-systems gnu)
<efraim>look a bit lower, the inputs get 'native-ified'
<efraim>in host-inputs
<civodul>apteryx: hi! we never cross-compile from x86_64 to i686 because x86_64 processors can execute i686 instructions
<civodul>so we just do native builds, as in "-s i686-linux"
<civodul>but yeah, in the case of Rust you'd want to cross-compile, hmm
<efraim>It gets trickier, for i686 you want to emulate x86-64 and cross compile back to yourself
<civodul>if you do "guix build -s i686-linux rust@1.39", it won't work because it'll try to build mrustc on i686
<apteryx>efraim: thanks! ah, this I think "#:native-inputs %build-host-inputs" in the `gnu-cross-build' procedure
<efraim>although I suppose that just depends on how you look at it
<civodul>but perhaps you could provide 'rust-1.39' an i686 gcc toolchain
<civodul>so that'd be some sort of a hybrid build
<apteryx>we only need to cross-compile 1.54 :-)
<civodul>oh?
<apteryx>not the whole rust bootstrap
<civodul>then can you just sticking #:system "i686-linux" in rust-1.54?
<civodul>hmm or am i saying nonsense?
<civodul>maybe?
<civodul>at any rate, i'm pretty sure you don't need the whole Guix cross-compilation machinery (which prolly wouldn't work anyway)
<apteryx>I think I tried that, but then it was automatically attempting to build all the rust bootstrap for i686-linux as rust-1.54 is a native input
<civodul>can rustc be told to generate i686 code?
<apteryx>yes
<apteryx>"--target=i686-unknown-linux-gnu" at build time
<civodul>alright, so maybe you "just" need to pass the right flag in rust-1.54 and run a native x86_64 build?
<civodul>--target is a rustc flag?
<apteryx>It's used in the build at the level of the rust build system (x.py), but I think it ends up being passed to cargo (and probably rustc)
<apteryx>my original attempt was using a native x86_64 build, and forcing the inputs for i686-linux. I got far, but eventually I get this: https://paste.debian.net/1221186/
<attila_lendvai>i wonder why i'm building gnome-shell@3.34.5 locally (on master). maybe it's local change that upgraded something? nothing looks suspect...
<civodul>apteryx: so rustc invokes gcc? i thought it was self-contained
<apteryx>rust takes a config.toml, where I set the paths of tools such as llvm, cc, cxx and ar
<apteryx>well, s/rust/cargo/ I guess
<apteryx>seems gcc is used when building some of its crates (libraries)
<civodul>weird
<apteryx>probably libraries interfacing with system libs (wrappers)
<apteryx>or bindings
<apteryx>civodul: apparently gcc is only used as a linker
<civodul>ok
<civodul>apteryx: i was thinking about something like this: https://web.fdn.fr/~lcourtes/pastebin/rust-i686-native-build.patch.html
<civodul>it doesn't quite work, but maybe that's an option
<rekado>mothaceh`: oh, sorry, I started the cuirass-remote-worker on grunewald again before seeing your message.
<mothaceh`>no problem, just stopped it :)
<rekado>php 7.4.25 failed to build on aarch64
<rekado>one failed test: Bug #66731: file: extensive backtraking, with pcre.jit=0 [ext/fileinfo/tests/cve-2014-3538-nojit.phpt]
<mothaceh`>on real hw or on qemu emulated?
<rekado>on pankow, so real hw
<mothaceh`>now that we have more arm hw, we could maybe stop emulating arm/aarch64 builds
<apteryx>civodul: thanks, I found a line I had forgotten to update in the config.toml (default-linker); and the cross inputs labels are different. Adjusted and retrying.
<apteryx>what happens to the native-inputs when cross-building?
<mbakke>apteryx: wdym?
<apteryx>are they preserved as-is; I'm asking because my native-inputs "cargo" label seems to vanish
<civodul>they're preserved as-is
***Guest1860 is now known as roptat
***roptat is now known as roptat_
***roptat_ is now known as roptat
<roptat>hi guix!
<mothaceh`> hey roptat!
<roptat>just to dissipate a doubt, I have two package updates to submit, but I can't update the first one alone, or the second fails, nor can I update the second alone, because it fails too. With both updated, there is no failure. Should I send a single patch for both packages, or is it ok to break something if I push a fix in the same series?
<nckx>Ehlo Guix.
*nckx think: single patch.
<attila_lendvai>for the same reason i've sent it as one commit, and a maintainer split it into one commit per package. thinking of e.g. git bisect, i don't think it was a good idea...
<nckx>I agree.
<nckx>People sometimes don't try ‘hard enough’ to find an order that works, but that's different.
<nckx>Sometimes there isn't one.
<roptat>right, in this case I tried both possible orders
<roptat>in the case of my maven update, I haven't tried everything yet
<roptat>but it's going to be messy I think :/
<nckx>I meant hard enough within reason, of course :)
<roptat>yeah, for maven I only found the target state I want, but haven't tried yet to see if I can split it into smaller commits
<nckx>Well, I don't think things should break between commits even if they are pushed together, but I know that others disagree.
<nckx>One of which likes to start sentences with Well, ☺
<nckx>phodina[m]: Re: testing megapixels: I take your word for it that it works.
<zimoun>roptat, nckx, we break all the time when we update. It happens with Julia, R, scientific Python for the few I follow a bit.
<sneek>zimoun, you have 1 message!
<sneek>zimoun, apteryx says: -p, --procs {N|auto} Integer value N launches N additional local worker processes -> so it's zero based, not one based :-)
<zimoun>Personally, I think it is better to have the “compiler” part updated with one commit, then the broken (leaves) packages fixed by following ones.
<zimoun>Instead of a big commit fixing everything. Obviously, if “compiler” requires several updates in the same time. But that’s not the case here. For what my opinion is worth.
<nckx>And I don't think we should break all the time.
<zimoun>nckx, so we should have another branch and not push directly to master; wait that CI rebuild all “guix refresh -l foo” and then fix. Because I am not convinced that all dependent packages pushed to master are beforehand carefully locally built.
<roptat>probably the difference is the number of dependents. An update of python would require rebuilding a lot, so we don't necessarily test everything, and we have to fix. But for coq, we have less than 10 dependents, so we can test all of them
<zimoun>or I do not understand how it is possible to have red bullet https://ci.guix.gnu.org/eval/48880/dashboard :-)
<roptat>sometimes guix refresh -l is not good enough (rust, or inherited packages especially)
<zimoun>yes, I agree. But main of these red bullets do not fall in this category, IMHO. ;-)
<roptat>but at least when it's affordable to test all of guix refresh -l packages, why intentionally break them?
<roptat>a lot of these are rust packages, and some of the rest is also cuirass' fault ("cannot build missing derivation")
<roptat>nevermind, the bulk of it is perl and emacs packages, all failing because of a few "cannot build missing derivation") in one of their dependencies
<unmatched-paren>how do i create an empty branch for the keyrings in my guix channel git repo?
<dhruvin>git orphan branches I believe
<rekado>for R updates I have been using separate branches since the last few times.
<zimoun>roptat, «why intentionally break them?». IMHO, to keep atomicity. Well, I do not have a strong opinion. :-) I am just sharing that personally, I would split the commit updating Coq into 3 commits. That’s just my opinion and I am fine with only one commit. ;-)
<nckx>zimoun: Maybe, some day! My scope here was ‘best-effort, today’. Accidental breakage, or an inability to locally test huge rebuilds, are unavoidable with our current tooling, and proactive pushing + reactive fixing is IMO fine for now. Knowingly breaking a known package mid-series is different & should be avoided.
<rekado>but ci.guix.gnu.org has been rather unpredictable, so after waiting for a day with no progress (and having built all packages locally myself) I usually just merge.
<nckx>zimoun: All IMO of course.
<unmatched-paren>dhruvin: that worked, thanks
<nckx>‘Atomic’ here is, perhaps ironically, a wide spectrum ☺
<roptat>zimoun, so I think I have a stronger opinion than yours and some support, so I'll go ahead and push coq's update as a single patch, instead of an update and two fixes
<roptat>(this evening though)
<nckx>Hmm. -rw-r----- 1 root root 0 Nov 19 00:00 /var/log/messages
<nckx>syslogd is running & has been since 26 September.
<nckx>‘herd restart syslogd’ felt risky so I sent it some yummy signals instead. Now it's logging those, at least.
<dhruvin>unmatched-paren: cheers!
<vivien>Hello guix !
<apteryx>civodul: re native-inputs when setting the #:target argument; I have a "cargo-bootstrap" in my native-inputs, yet in the configure phase (assoc-ref inputs "cargo-bootstrap") -> #f
<nckx>Hi vivien.
<apteryx>ah, probably need to access itvia native-inputs. I'm too used to native compilation where inputs = native-inputs + inputs I guess
<jpoiret>apteryx: iirc, you should almost always use (or native-inputs inputs) in place of just inputs for things you want to be able to use natively
<apteryx>jpoiret: so as to not break cross-compilation, right?
<jpoiret>yes, as when compiling natively, everything is in inputs, and when cross-compiling only the tools that you want to run natively on the building machine are in native-tools
<apteryx>that's what I've just learned today... I must have been causing harm cross-compilation for a bit.
<jpoiret>native-inputs * silly typo
<civodul>apteryx: right, it's #:native-inputs in build-side code
<civodul>but again, i don't think #:target "i686-linux-gnu" is viable from x86_64-linux
<apteryx>the tools at least build
<apteryx>I hope it works this way I don't need to special case i686-linux; the same recipe could then be applied to derive a aarch64-linux-gnu cross-built rust
<civodul>yes, that'd be nice
<civodul>i thought the i686-linux-gnu cross-toolchain just wouldn't build or something, but if it does, that's good
<sailorTheCat>Hi, what can I do with `/tmp/guix-build-rtl8821ce-linux-module-0.0.0-3.897e7c4.drv-0/source/core/rtw_br_ext.c:20:11: fatal error: net/ipx.h: No such file or directory
<sailorTheCat> #include <net/ipx.h>
<sailorTheCat>`?
<sailorTheCat>How to understand which package need to be installed?
<slyfox>it's a linux-headers package. which version do you have?
<slyfox>in linux-5.15 ipx.h was removed
<slyfox>you probably need to port that kernel module
<sailorTheCat>do you have a doc how to do it?
<slyfox> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff63261978ee1f00758f447d63276a6f180a81dc
<sailorTheCat>thanks
<slyfox>The Tl;DR is to remove any IPX handling
<slyfox>If it's someone else's code maybe it's already done? Random repo from the internet: https://github.com/tomaspinho/rtl8821ce/commit/2357b5443e4d35af34868cd213856a6db072e159
<attila_lendvai>make check-system TESTS="basic" prints "error: local-file: unbound variable", and i'm unable to find where from.
<attila_lendvai>to the best of my knowledge, this is the same in a vanilla guix checkout
<attila_lendvai>it otherwise seems to work
<slyfox>could be a stale .go cache somewhere?
<attila_lendvai>i've deleted my ~/.cache/guile
<slyfox>i usually do 'touch' for every SCM file to make sure, but it takes a while to rebuild.
<slyfox>At least on foreign distros with guix installed system-wide it's very hard to use local checkout without something like https://issues.guix.gnu.org/48434
<slyfox>The commit message has a strace call hack to find out where .go files come from. Maybe it would be useful for you as well to track problematic import.
<vagrantc>i've been using guix shell (or earlier guix environment) when using pre-inst-env on a foreign distro ... a little tricky, but works.
*attila_lendvai is on guix system
<slyfox>probably makes things even more complicated :) (i never tried local checkout of guix on guixsd)
<vagrantc>hrm. aarch64 on core-updates-frozen ... needs care and feeding :/
<rekado>vagrantc: I’m building a bunch of things manually
<rekado>because I want them to be built on the new fast nodes, and because there are a lot of failed builds that I can refresh.
<vagrantc>you got the honeycombs up and running, then? :)
<rekado>yes
<vagrantc>at some point i should probably boot the apm mustang again and get it all updated ... 16gb of ram helps quite a bit :)
<rekado>two of them are connected; the other one needs a cable.
<rekado>gotta bike to the office one of these days and pick one up
<unmatched-paren>my tree-sitter/nightly neovim channel works now! \o/ https://codeberg.org/unmatched-paren/guix-channel
*vagrantc ponders picking up a couple honeycomb lx2 systems for the build zoo for reproducible builds
<rekado>I like these systems. They are pretty fast. Maybe a little picky wrt SSDs and RAM.
<rekado>if reimbursement with the FSF wasn’t so slow I’d order a couple more.
<vagrantc>support EFI out-of-the-box?
<unmatched-paren>btw someone might want to absorb that 20.1 tree-sitter into the tree-sitter patch (it's at 19.5)
<unmatched-paren>i'm too tired now :]
<jgart>unmatched-paren, that's awesome! I'll give it a try. I've been meaning to try neovim with tree-sitter
<sneek>Welcome back jgart, you have 1 message!
<sneek>jgart, unmatched-paren says: Here's the nightly nvim channel I was talking about :) https://codeberg.org/unmatched-paren/guix-channel
<unmatched-paren>jgart, you'll need to use install https://github.com/nvim-treesitter/nvim-treesitter and run :TSInstall <some language>
<jgart>cool! thanx
<jgart>unmatched-paren, what's your preferred method of installing neovim plugins?
<unmatched-paren>packer.nvim
<unmatched-paren>you'll also need this snippet in your init.lua:
<unmatched-paren>one moment
<unmatched-paren> https://paste.debian.net/1221249/
<jgart>I saw you had your dootfiles up
<jgart>is it in there too?
<unmatched-paren>i haven't pushed to my doots in a while
<unmatched-paren>they're from when i used debian :P
<unmatched-paren>i've been meaning to update them but i can't be bothered
<unmatched-paren>here's packer btw: https://github.com/wbthomason/packer.nvim
<jgart>unmatched-paren, I upgraded the python language server in Guix to use the maintained fork: https://issues.guix.gnu.org/52161
<rekado>vagrantc: they don’t do anything without a microsd card that contains the EFI image.
<jgart>I saw you were using that one in dootfiles
<unmatched-paren>so: require 'packer'.startup(function(use)
<unmatched-paren> use 'some/plugin'
<unmatched-paren> end)
<yewscion>I may have messed something up with my binary install (doesn't happen on my system installs). When I ran `guix pull` today, it told me my `$GUIX_PROFILE` variable was set incorrectly, and needed to be set to `$HOME/.config/guix/current/`. So I set that, sourced the appropriate `/etc/profile`, and ran `guix package -u`... But then, it said the same
<yewscion>variable needed to be set to `$HOME/.guix-profile` instead. Is there a definitive guide to how this variable should be set somewhere? And anyone have some idea as to why this might be happening?
<rekado>without the sd card they don’t start up at all. No output on the serial interface.
<unmatched-paren>i don't actually use python and i have no idea why i had it in there :)
<rekado>I guess it should be possible to flash the EFI to a chip on board, but I haven’t figured this out yet.
<rekado>(I’m using one and the same sd card to boot up all three machines.)
<jgart>unmatched-paren, ohh ok
<unmatched-paren>i'll update my dotfiles now, actually...
<jpoiret>yewscion: it's both! there's the guix-the-program profile, which only contains the guix install, and your default package profile which is in .guix-profile. You have to source both the guix profile and the package profile's /etc/profile for them to be active
<unmatched-paren>hmm gnu stow or git bare repo?
<jpoiret>note though that if you install some package that needs a new environment variable to function, you'll have to source them again for it to function properly (if you have the sourcing things in your .{whatever-}profile, logout and login is enough)
<yewscion>jpoiret: I see, so this is an expected behavior? The problem I was trying to solve was updating guix itself; the system version (which it seems to be defaulting to every once in a while) doesn't have `guix home` or `guix shell` capabilities. To be clear, both `~/.guix-profile/etc/profile` and `~/.config/guix/current/etc/profile` should be sourced
<yewscion>for full functionality?
<yewscion>Also, is there a canonical setting for `$GUIX_PROFILE` ? I can source both of the above files explicitly in my dotfiles, if needed.
<jpoiret>yes! by default, when you install on a foreign distro, you'll temporarily be using a guix binary that is installed inside the distro's preferred location (eg /bin or /usr/bin), and which is a fixed version (likely old, like 1.3 old). When you `guix pull`, guix fetches the latest guix commit, and builds guix-the-program (which also contains the
<jpoiret>package definitions, mind you), creates a profile for it in the store and finally symlinks .config/guix/current/ to it. So, to use the `guix pull` guix, you need to source that profile, otherwise you'll be using the distribution's guix
<yewscion>I see, that makes sense. Thanks!
<jpoiret>yewscion: you can see what the default /etc/profile (the system-wide one, which will be sourced by POSIX-compliant shells) looks like on guix system by looking here https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm#n906
<jpoiret>it'll give you an idea of how all of it is done by default on the guix systems
<jpoiret>especially the part that starts with "# Arrange so that ~/.config/guix/current comes first."
<yewscion>Awesome, that helps a lot, actually! Thanks, jpoiret!
<\a>How can I automatically run a command on boot with Guix System (specifically intel_reg write 0x00061254 <value> to fix the backlight control value: https://libreboot.org/docs/misc/#finetune-backlight-control-on-intel-gpus)
<\a>?
<roptat>\a, you'll need an activation service
<jpoiret>you can look into defining a one-shot shepherd service, see https://guix.gnu.org/manual/en/html_node/Shepherd-Services.html#Shepherd-Services
<jpoiret>or, an activation service (or a boot service even)
<roptat>oh is that a thing?
<jpoiret>boot services you mean? see https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services.scm#n389
<roptat>thanks :)
<jpoiret>although they're not used for much iirc, only for starting shepherd itself after sourcing the activation scripts
<roptat>\a, so I would do something like this, in the list of services (in /etc/config.scm): (simple-service activation-service-type (list #~(invoke #$(file-append intel-reg "/bin/intel_reg") "write" "0x00061254" <value>)))
<roptat>(replace intel-reg with the package that actually contains intel_reg
<roptat>(
<roptat>ah, maybe you just need a single gexp, not a list
<roptat>so (simple-service activation-service-type #~(invoke #$(file-append intel-reg "/bin/intel_reg") "write" "0x00061254" <value>)) instead
<unmatched-paren>jgart: i've updated my dotfiles now, in case you want to take a look: https://codeberg.org/unmatched-paren/doots
<jgart>cool, thnx!
<jgart>how is it that I append a manifest full of packages to my current profile?
<jgart>-m replaces my profile with the contents of the manifest
<roptat>that's expected, a manifest defines all the packages of a profile
<jgart>Is there currently a way to "cons" a manifest to the current profile from the cli interface?
<roptat>I don't think so
<jgart>I want the union of a manifest and my current profile
<jgart>ok
<jgart>I'm too lazy to copy paste them from my manifest file and remove the double quotes. This would be a nice feature, I think
<jpoiret>would there be any interest in creating a "Getting started" """"tutorial"""" on the guix website? I feel like i've already explained one too many times the concept of profiles, between the guix one, the default packages one, etc…
<jgart>basic set operations on manifests would be cool: union, intersection, difference, complement (with respect to a user chosen universe which can be another manifest file)
<unmatched-paren>jpoiret, absolutely
<unmatched-paren>what many free software projects are missing most of all is an official 'Getting started'
<unmatched-paren>which is why you see so many 'Getting started with x' blog posts and articles...
<roptat>There's a getting started section in the manual, maybe we can improve that?
<jgart>jpoiret, I'm hosting a guix docs meetup on December 11
<jgart>We're going to work on docs on Big Blue Button if you're interested
<jgart>roptat, Maybe that can be the theme for the meetup unless we finish it before the 11th ;)
<roptat>sounds good :)
<jgart>unmatched-paren, https://issues.guix.gnu.org/52017
<jgart>I saw you had ccls in your dootfiles
<jgart>just upgraded it too
<jgart>testing welcome and appreciated
<jpoiret>roptat: that's true! maybe we could also make it available under a shortcut on the guix website then ("Manual" is something that many people will intentionally avoid)
<jpoiret>i'll be thinking about expanding on it. Profiles deserve a couple paragraphs by themselves, so that users can understand how they're made, what they look like and why they're sourced
<unmatched-paren>jgart: nice! i don't really use c that much tho, the tree-sitter is to make the ugly syntax bearable when i have no choice, so i won't really have many opportunities to try it
<apteryx>when we cross build things at the package level; is the resulting package usable as-is in that target packages graph? or a hack is needed to happen to copy the output to the correct #:system ?
<roptat>jpoiret, so trick users into opening the manual by having a dedicated link? I like that :)
<jpoiret>exactly 8)
<unmatched-paren>deceive them into learning >:)
<jgart>I'll probably fall for it
<unmatched-paren>gnome-shell is building itself... why's there no substitute for it?
<nckx>unmatched-paren: Probably https://ci.guix.gnu.org/build/1857195/details
<nckx>error parsing file /tmp/guix-build-evolution-data-server-3.34.2.drv-0/build/src/camel/Camel-1.2.gir: Error on line 60833 char 33: Document ended unexpectedly while inside an attribute value
<nckx>Just dodgy enough to restart the CI build…
<nckx>…it was a transient.
<nckx>unmatched-paren: There is a toot now.
<nckx>sneek: seen mothacehe?
<sneek>I last saw mothacehe in #guix 5 hours and 49 minutes ago, saying: *isn't really.
<apteryx>why is "cross-binutils" added to the native inputs rather than inptus when cross compiling?
<nckx>sneek: later ask mothacehe: When (manually) restarting a CI build, would it be feasible to automatically restart all dependent packages that were marked as ‘dependency failed’ because of that package alone?
<sneek>Okay.
<apteryx>nckx: it's already the case I think
<\a>roptat, Wrong number of arguments to #<procedure simple-service (name target value)>
<nckx>At least in the Web UI, gnome-shell did not change state to (re)‘started’ after evolution-data-server changed from failed to succeeded.
<nckx>apteryx: ☝
<roptat>\a ah sorry, I was missing an argument indeed: (simple-service 'fix-backlight activation-service-type #~(invoke #$(file-append intel-reg "/bin/intel_reg") "write" "0x00061254" <value>))
<apteryx>nckx: yeah, I don't know how to visually get a feedback about whether this is actually happenning or not
<nckx>sneek: later tell mothacehe: If that is already the case, it's not clear from the UI. A dependent (gnome-shell) remained ‘failed’ even when all dependencies became green. Maybe it was being rebuilt in the background though, I didn't wait around and manually restarted it.
<sneek>Got it.
<rekado>sneek: seen reepca?
<sneek>reepca?, pretty sure was seen in #guix 9 months ago, saying: command finally failed with the same error as before.
<attila_lendvai>i'm working on a system-test, and it hangs for quite a while at "Please wait while gathering entropy to generate the key pair;". is there something i can do about it? maybe avoid adding a specific service?
<jgart>unmatched-paren, wdyt of calling your channel guix-neovim-nightlies or something similarly descriptive? Will it be a channel dedicated only to providing nightlies for neovim or any software?
<engblom>I am trying to figure out if guix is supporting zfs. All I can find is this https://issues.guix.gnu.org/45692
***rgherdt_ is now known as rgherdt
<engblom>Is it possible to have guix running on ZFS root?
<podiki[m]>I don't know, but there's an ongoing discussion of ZFS on guix-devel: https://lists.gnu.org/archive/html/guix-devel/2021-11/msg00094.html
<podiki[m]>(and does discuss those patches)
<jpoiret>no idea, although it will definitely be more complicated than other filesystems. If you don't already have zfs/need specific zfs features, btrfs is similar and has no licensing issues
<nckx>engblom: If it's possible, it will not be easy, and will likely involve patching Guix first.
<nckx>‘Supporting ZFS’ != ‘supporting booting from a ZFS root’.
***tomerparetsky is now known as tripfandango
<engblom>jpoiret: ZFS is so much more mature and stable than btrfs. I would not trust my files to btrfs
<nckx>guix build: error: gcry_md_hash_buffer: Function not implemented
<nckx>So this is not uncommon, but what is the root cause?
<engblom>nckx: I see, then I will have to postpone any plans on switching to guix as I do not want to be without zfs.
<dstolfa>engblom: guix works really well on ubuntu, and ubuntu supports zfs pretty nicely
<nckx>I got it when pulling to core-updates-frozen and then doing my traditional ‘guix environment guix -- ./pre-inst-env guix <stuff>’.
<nckx>engblom: Okido.
<nckx>An alternative would be to add ZFS root support to Guix yourself.
<dstolfa>it would be good to get raid5's patches reviewed as well :(
<dstolfa>unfortunately... time constraints and all
<jpoiret>i have been using btrfs for 5 years without a single hitch. I think the ZFS is more mature than btrfs talk is outdated, but ymmv
<dstolfa>jpoiret: btrfs still can't support dynamic mountpoints, doesn't work properly with nfs and is anything but 'easy' to manage compared to zfs when you have multiple machines that need to occassionally share data
<dstolfa>also, raid56 is just broken on btrfs
<dstolfa>that said, i personally don't need guix to boot off zfs, i just need it to support using zfs storage :)
<apteryx>jpoiret: same experience with Btrfs (it just works)
<apteryx>I use a raid1c3 array (RAID1 on 3 drives) with zstd compression
<jpoiret>alright, can't say anything about nfs since i don't use it :)
<apteryx>I use NFS on Btrfs at work
<apteryx>no issues whatsoever
<engblom>nckx: No, I would not have time to add it myself. I have just switched workplace and because of that I am so busy that I have to cut down on all my hobbies. I still have some programming projects to do for my old workplace.
<jpoiret>maybe switching to a totally different distro (that will need some time for you to adapt and get everything working as you want) shouldn't be on top of your priorities then :)
<dstolfa>heh, this kind of busy sounds like: "i don't even want to update my current distro, let alone switch" :D
<jpoiret>especially with guix, which has the tendency to feel like you're fighting against it for at least a week
<engblom>Guix just attracted me because of it being configured with guile. I like the lisp family of programming language. The latest release of Ubuntu has some strange graphic glitches that is very annoying. Each time I move the cursor over menu items in Firefox it is flickering like crazy. If it was not for this I would not consider switching distro.
<jpoiret>to give you an example: I switched my mail from protonmail to my own self-hosted dovecot because getting protonmail bridge packaged on guix would take wayyy too much effort (thanks go)
<jpoiret>not saying this isn't good by the way, i'm happier with my current setup. Just that it's going to take some, well, adaptation
<engblom>I am also self-hosting my mail. The biggest problem with self-hosting is spam filtering. That is a complete uphill battle.
<jpoiret>oh, I haven't got any yet. Although I'm using some upstream configuration that should take care of it itself.
<samplet>Guix trivia: The number of XZ-compressed Linux[-Libre] tarballs Guix has used since version 1.0? About 650.
*samplet is testing Disarchive’s XZ support
<sneek>jpoiret: Greetings!
<jpoiret>oh hello there sneek
<jpoiret>sneek, botsnack
<sneek>:)
***potatoal- is now known as potatoalienof13
<rekado>php failed one of its tests again on aarch64. This time it’s 7 different tests.
<raghavgururajan>jgart and KE0VVT: I had the same problem in X200T with CPU overheating and fan growling. I replaced the Fan+HeatSink unit and its all better now.
<rekado>why do we need php for gtk?
<raghavgururajan>rekado: gtk 4?
<raghavgururajan>Folks, anyone else has the issue of 5GHz WiFi disconnecting often with network-manager on guix system?
<jgart>raghavgururajan, sounds like the right thing to do :)
<rekado>raghavgururajan: 3.24.30
<sam_>raghavgururajan
<sam_>oops
<rekado>this build here is also doing php right now: https://ci.guix.gnu.org/build/1817741/details
<rekado>I expect this to fail, too
<raghavgururajan>jgart: I tried different ones, but eBay item 263831779825 is the best.
<raghavgururajan>rekado: I see. php is odd indeed.
<raghavgururajan>for gtk
<rekado>it’s among the native inputs of libsoup-minimal
<raghavgururajan>ah,web soup.
<vagrantc>too much soup in my computer not work
<attila_lendvai>if i have a system-test; how can i run it interactively in qemu so that i can inspect the vm's state manually? where is the code that spawns a qemu from an operating-system definition?
<apteryx>raghavgururajan: I don't have any issues with 5 GHz using this: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-dual-band-pcie-card-gnu-linux-tpe-n300pcied3-full-profile
<apteryx>well, I had to specify the band to use to get maximum throughput for some reason (I'm using a LibreCMC router with it).
<apteryx>router/AP
<attila_lendvai>hrm, am i looking for guix system vm somefile.scm?
<raghavgururajan>apteryx: I see.
<apteryx>attila_lendvai: yes