IRC channel logs

2024-08-07.log

back to list of logs

<nikolar>so a bunch of substitues are failing on aarch64 because of llvm-17.0.6
<nikolar>and that build seems to time out
<nikolar>so probably just bumping the timeout limit and building again would solve the problem
<nigko>Hello Guix! Does anybody use git repositories as Guix channels as described in https://guix.gnu.org/cookbook/en/html_node/The-Repository-as-a-Channel.html?
<jaft_r>Hey, nigko; I do.
<nigko>I have found that "repositories as a channel" do not work on my machine with Guix System.
<jaft_r>Hmm; where have you found yourself running into issues?
<nigko>jaft_r: when I try to build a package from the repopository I have got an error in configure build phase: "/gnu/store/..../bin/bash: ./configure: No such file or directory"
<nigko>But when I use repositories as a package on another foreign distro machine, they work as expected.
<jaft_r>Mmm; gotcha. I can't be certain but it sounds like getting the repository set up went fine, getting Guix to recognize and register the channel (after a "guix pull") went fine, and it's just the install of a package part which is giving trouble. Did you test installing the package before adding it to the repo.?
<nigko>jaft_r:  `'guix pull'  went without error. Only 'guix install/build' throws an error. Yes, the package is built fine via 'guix build -f guix.scm'.
<jaft_r>nigko: Hmm; would mind sharing the channel, any? I could take a look at it, that way.
<nigko>jaft_r: I have created a test repo https://gitlab.com/anigko/test-channel.git
<nigko>It reproduces the behavior. On my Guix System machine 'guix build test-repo' throws an error https://paste.debian.net/1325701/
<nigko>And on foreign distro 'guix build test-repo' works as it should.
<jaft_r>nigko: what's the absolute path of where it installs to, when using a foreign distro?
<nigko>jaft_r: /gnu/store/samf205j3w8ypf2cf15xgrvwjqzc9533-test-repo-1.0
<jaft_r>Sorry; I meant specifically "content". "/gnu/store/samf205j3w8ypf2cf15xgrvwjqzc9533-test-repo-1.0/content", I'm guessing?
<nigko>jaft_r: /gnu/store/samf205j3w8ypf2cf15xgrvwjqzc9533-test-repo-1.0/share/content
<jaft_r>That's it. Realized it just before you sent that. O. K.
<jaft_r>But on a foreign distro, you're able to add the channel to your "channels.scm", do a "guix pull", and then run "guix build test-repo" and it all works?
<nigko>Yes, it does.
<jaft_r>nigko: Huh; I'm really sorry but I don't think I'd know. If it /hadn't/ worked on the foreign distro, I may've said it's possibly the use of "local-file" which is causing issues. Maybe a channel wouldn't have access to the files outside of the module or something about how channels are setup in the process of installing packages.
<jaft_r>Obviously, – locally – no issue but maybe you can't do that with a channel. But working on a foreign distro would seem to indicate that's not an issue.
<jaft_r>And it's not like the channel's repository is changing /just/ for Guix System (as far as I'd imagine, at least).
<nigko>jaft_r: Could you please add the channel to your channel.scm and try to build test-repo? If it throws an error on your machine, I may submit a bug report.
<jaft_r>Sure; a good idea. One sec. I'll let you know how it goes.
<weary-traveler>are there any further developments relating to #72183 that may have happened elsewhere (i.e., not on the issue)?
<jaft_r>nigko: welp; again, good call. I was able to run "guix install test-repo" and then I uninstalled it and garbage collected the path and was able to run "guix build test-repo", after that. Both worked and succeeded.
<nigko>jaft_r: Thanks for your help! Was it on foreign distro or Guix System?
<jaft_r>Absolutely! And Guix System.
<nigko>jaft_r: Interesting. That means something is wrong with my Guix System.
<jaft_r>Unfortunately; though I can't imagine what: all of the files needed for the package install are in the repo., not on your machine…
<nigko>jaft_r: Well, to figure this out I can start to reduce my Guix System config to some very minimal variant. Now I know where to dig! Thanks again!
<futurile>Morning all
<nutcase>Good morning Guixers. I was quite happy with my Thinkpad T480s that now has some issues and I need to replace. Do you have a recommendation for a robust 14" Notebook, good battery lifetime, an LTE module (option) that is sufficiently compatible with Guix? I considered a Thinkpad T14s, but I am confused by the different options available (Intel, AMD and Qualcomm). Is there one platform I should prefer over another in terms of compatibility with Guix...
<nutcase>... System (+nonguix), which is my main OS?
<Franciman>hi nutcase which issues does your former laptop have?
<nutcase>USB-C power socket hardware issues (loose copper)
<Franciman>are you selling it?
<Franciman>i am interested in buying
<Franciman>anyways. What specs are you looking for?
<nutcase>well, it's my employers notebook, I'm afraid I'm not allowed to sell it
<Franciman>Maybe any ultrabook would work
<Franciman>but please be careful that non free software is not supported in this channel
<nutcase>14", 1TB, 32GB Ram, LTE, hardware Virtualization support, (Trackpoint), and of course: low noise, long battery, high power, low price :-) Something like that.
<futurile>nutcase: I would do a general search for that laptop and "linux". In the past it's always been that going with AMD/Intel CPU makes no difference, but the board (wifi/bluetooth) etc had made a difference - generally 'Intel everywhere' was better for compatibility.
<futurile>nutcase: given that your use-case is "for work" - I wouldn't go with anything exotic e.g. ARM laptop
<nikolar>so, any guix maintainers around
<nutcase>futurile thanks for the hint wrt ARM. That is something I wanted to know. Unless someone reports that everything works like a charm on ARM, I am rather skeptical, unfortunately.
<bdju>lately I get a lot of slowdown changing and resizing tmux windows. using sway and foot.
<futurile>nutcase: yeah, I'm sure it would be very cool - but there will definitely be more difficulties on ARM - exciting to see a few more laptops come out with the capability though
<kaij>how does guix determine whether a substitute matches?
<kaij>currently I just run a mirror of guix as my main channel, and I now want to extend it with some other packages, etc. but that means the primary url would change (right now it's still the savannah hosted guix repo). would substitutions I build still work? would I have to recompile everything?
<AwesomeAdam54321>kaij: The substitutions would only change if you changed the package recipe or it's inputs changed
<AwesomeAdam54321>Guix asks the substitute server if it already has built the same derivation that's generated from the package recipe locally
<AwesomeAdam54321>and uses the substitute if that's the case
<GNUtoo>Hi, I've a patch for install-guix.sh, how do I test it if it requires to add extra files inside Guix?
<GNUtoo>If I test it as much as I can locally and then send the patch, the QA system will most likely build Guix with it, so can I somehow take the same guix-install.sh than my patch has, and somehow modify it to use something from the QA?
<GNUtoo>Hi, with this patch, do I need to change the order of the fields or not? https://issues.guix.gnu.org/70896 ?
<GNUtoo>Or can it just go in?
<GNUtoo>It's form the 15 May
<kaij>how does versioning actually work? looking at the docs it suggests different versions should be packaged as different packages, so llvm-13/15/17 for example. but in practice I need to write clang@13/15/17, and looking at the package definition, it is just named "clang" and the version field differs.
<futurile>kaij: you specify the version you want with clang@17.06 clang@18.1.8 etc
<kaij>right, but for other packages it's different. linux-libre for example. and the docs say that's the correct version https://guix.gnu.org/manual/en/html_node/Version-Numbers.html
<kaij>also wondering how I'd refer to clang@13.0.1 in code
<futurile>kaij: yup, most end-user packages will only have one version in the archive at a time - libraries there tend to be situations where there are more versions - because packages depend on a particular version
<futurile>kaij: rust's a good example - where the expectation in the Rust ecosystem is that minor versions are all different - 0.2.X 0.3.X - so we have lots of Rust libs
<kaij>ah, so the package-123 is done so minor versions that are transparent to the end user. makes sense. And how does it work in code? how do I say install clang 13 for example
<futurile>you specify it so `guix package --install package@version`
<futurile>or you specify it in your manifest - depending on whether you're using the command line, or using a declarative approach with something like guix home etc
<kaij>yeah, I mean in the manifest. how would I do that?
<Rutherther>the @ syntax will work only with specifications->manifest, right? not with packages->manifest, or am I mistaken? how would you do equivalent behavior with 'raw' packages?
<kaij>I mean `(list ... clang@13)` isn't valid as far as I understand
<Rutherther>that's why I mentioned the specifications, you put these as string
<Rutherther>"(specifications->manifest (list "clang@13"))" works fine
<futurile>Rutherther: thanks for explaining that - yeah I use 'specifications->manifest' so much I forget
<futurile>Rutherther: and then there's the whole 'out' thing which I still need to figure out how to do heh
<kaij>I see, does that work in ie operating-system? Like, ist that the same typing as a package list?
<kaij>for example (operating-system ... (package (append (specification->manifest (list "clang@13")) %
<Rutherther>kaij: you use manifests for whole profiles. For a package, just reference the package directly, like "llvm-13"
<Rutherther>kaij: the reason why specifications are different, is probably because they look only at names of the packages, and there are multiple "llvm", so it's unknown which to choose. But if you write guile, you just reference directly, they are bound to different public exports of the llvm module
<kaij>oh I see, the manifest will search for a package fitting that, but in guille I have to directly specify the "object" that I want to use
<kaij>is that about right?
<Rutherther>kaij: that seems right to me. Though I am quite new in guix, so I may as well be mistaken
<kaij>yeah, me too but you're super helpful regardless
<ebrasca>Hello, I get the following error "skipping invalid root from `/var/guix/profiles/per-user/ebrasca/current-guix-17-link' to `/gnu/store/rkmsg2mxqc2rz0jhjbrg24q23am05bz2-profile'"
<ebrasca>How I can fix it?
<jaft_r>Hey, ebrasca; when do you get the error? Which command do you run which produces it?
<ebrasca>jaft_r: I run "guix gc"
<Altadil>Hello, I’m trying to figure out how to use cuirass. Following the docs, I now have the system service, I can access the Web UI and add specifications. But nothing is getting build. From the doc, I understand that nothing needs to be done for the local build option. Am I wrong? I can trigger an evaluation, but then, still nothing visible. Where does cuirass store its log? (The doc mentions the build logs, but in my case, there is n
<jaft_r>ebrasca: did you manually delete any profiles, lately?
<ebrasca>jaft_r: Probably not
<jaft_r>Fair.
<ebrasca>jaft_r: Do you know how I can fix it?
<jaft_r>ebrasca: Trying to Google around but, unfortunately, I don't. It sounds like "/var/guix/profiles/per-user/ebrasca/current-guix-17-link" is pointing to a profile which no longer exists. I'm not sure how you'd resolve it, though
<lilyp>anyone using guix on ubuntu 24.04? I'm trying (and failing) to get a gnome app using the stuff from guix there
<Guest2>Is there any reason for an AR9271 usb wifi adapter to have problems being detected, or is it just faulty (I bought it new recently)?  I've tried it with multiple distros on 3 computers, and the problem is the same.  It often won't show up in lsusb or dmesg, and I have to unplug and replug it, often several times until it does.  It just took ~30
<Guest2>tries right now and a few days ago.  On this this computer it's been stable so far once detected, but on the other two, there were times where it would lose connection to my network and not be able to reconnect until I did the whole unplug and replug bit again.
<weary-traveler>any spritely goblins knowledgeable people here. #spritely seems quiet
<Deltafire>Guest2: send it back
<Guest2>Guest2 Can't since bought it NIB (Sharp VR-WL25) on ebay with no returns accepted.
<Guest2>^meant for Deltafire
<kaij>is there a native way to change default for build tools? ie the node package for node-build-system, or the Linux package for linux-module-build-system?
<kaij>of course patching the channel / repo works, but wondering if there's a "native" way?
<dariqq>kaij: do you jsut want to customize an existing package? You could create your own package inheriting from the original one and then set the #:linux/#:node/etc argument to what you want
<kaij>I want to change it for all dependencies of a package, especially for node that's important
<Rutherther>kaij: so you mean you want to change package A that is a dependency of B, C, D etc., so that B, C, D sees modified package A, correct? then probably easiest is to use transformations, or the stuff those use internally.
<Rutherther>kaij: either on cli via --with-inputs, or in guile with "options->transformation"
<kaij>would that then be part of the profile somehow? or how would that work?
<Rutherther>kaij: no, you need to make sure that all packages where you want to replace it are transformed
<Rutherther>kaij: which means that you call the transform function on them. options->transformaton will return a transform function
<kaij>hmm, not sure I totally understand then. Where or how would I use options->transformation? in my mind that probably produces a new package, and then I use that as part of my package list instead of the original one?
<Rutherther>kaij: exactly. But you will need to produce a new package, even if you changed it in the channel, changing a dependency consequently changes the package. Unless you use grafts, but that can be used only if they are completely compatible, and is meant more for security fixes
<Rutherther>kaij: alternatively you can use the "package-input-rewriting" to not use specifications (as was shown before, those are strings specifying the package), but to use guile object. Honestly this will probably be needed if you are changing the original package just in your file. So I shoul've mentioned this first
<kaij>Ok, makes sense. So I make lambda that applies the transformation, checks the build system to be node, if so changes the node option, and recursively applies to all dependencies. and that should yield a new package with all dependencies build for the new node version?
<Rutherther>kaij: I don't think it has to check the build system to be node. Why is that important?
<kaij>I mean it'd set the build system to be node, but with the #:node option set. If a package depends on some C lib, I probably shouldn't do that
<Rutherther>kaij: the transform function will modify only those packages that have node as a dependency, others will stay the same. So I don't think there is a need to check build system
<kaij>ah I see, makes sense. will give that a try, thanks!
<Gooberpatrol66>does guix support grub2 now that it uses grub 2.12?
<Gooberpatrol66>does it support luks2 i mean
<mekeor>sorry for repeating my question. should it work fine to use multiple branches of the guix repository as channels?
<mekeor>(i'd like to use the latest go version from go-team branch and latest tex packages from tex-team branch)
<Schemer81>hi
<Schemer81>what does pola-wrapper mean in the following?
<Schemer81> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/least-authority.scm?h=master#n43
<ieure>Schemer81, It's the default value of the #:name kwarg passed to the `least-authority-wrapper' procedure.
<Schemer81>ieure I was able to deduce that as well
<Schemer81>I'm interested to know if pola is an acronym for something or if it refers to something
<Schemer81>s/deduce/know
<ieure>Schemer81, Guessing "program of least authority"
<Schemer81>yea, that might be it
<Schemer81>thanks for rubber ducking that with me
<ieure>No problem!