IRC channel logs
2023-12-03.log
back to list of logs
<apteryx>cmiller: "not intended for Linux Libre" is funny; Linux Libre is Linux minus the blobs. So what matters is that the documentation precisely mention what works with blobs or not. <cddr>How to make an already running guix system act as a substitute for installing to other pcs in a lan <cddr>cmiller: thanks, and is there a way to set priority for the substitutes <ieure>Is there a more... productiony way to serve substitutes? Like can I point nginx at a directory or something? <civodul>ieure: you can use nginx as a proxy to ‘guix publish’ <ieure>civodul, Yes, I know. Perhaps a better question is: do the official servers also run `guix publish' to serve substitutes? <cmiller>cddr: Not that I am aware of. But if you run a command you can always use --substitute-urls= which would use those instead of the ones already defined. <nckx>ieure: I'm not sure whether they (both) still use guix publish to actually serve toots to real clients, or whether the nar herder has replaced that part. <cddr>okay I see that makes sense maybe it will also respect the order in which i give urls <nckx>I don't understand what's productiony about pointing nginx to a directory rather than proxying. <nckx>ACTION proxies guix publish through nginx as well. <nckx>cddr: Substitute servers are tried in the order given, so put your best one at the front. <nckx>The ‘Priority’ field of /nix-cache-info is AFAIK entirely historic cruft. <Kolev>nckx, guix shell: error: supdup: unknown package <nckx>If you're using my paste verbatim, it's missing some bytes at the bottom. <ieure>Hmm. I'm packaging a thing that runs `install -o root -g root ...', and it's failing with: install: invalid user ‘root’ <nckx>You need to patch out or otherwise unalive the ‘-o root -g root’. <nckx>There is no root in buildland. <singpolyma>Might need other special handling depending on why it does that <ieure>singpolyma, Heh, well. I wrote the thing I'm packaging, I did it because when I packaged it for Debian, the files need to be owned by root. <singpolyma>Ah, ok, so can probably patch it out easily then <cddr>I notice in grub.cfg, modprobe.blacklist=usbmouse,usbkbd enabled by default <cddr>I have a usb-c thunderbolt doc that I can't use with guix currently, could it be because of this <nckx>singpolyma: In my experience most packages don't have a good reason to -o root and work fine with it removed, but I might have got {un,}lucky. <ieure>nckx, If you omit -o root, the files end up owned by whatever user ran the command, which isn't what you want for a package on a traditional Linux distro. <Kolev>nckx, I added 'supdup' to the bottom. same result. <nckx>Kolev: I'm not sure what you expect, I have no idea why you're running ‘guix shell’. I never did. <Kolev>nckx, I don't know how to do all this. guix build then? IDk\ <nckx>ieure: …which is root, though, by default (‘sudo make install’ or the non-sudo equivalent—the destinations being root-owned too). <nckx>Kolev: I guess? You've been here for years, I assume you're familiar with ‘guix {build,shell,…} -f FILE’. <nckx>~ λ guix shell -f /tmp/supdup.scm -- supdup --help <nckx>Trying --help ...connect(server): No such file or directory <Kolev>I'm not getting that result. <ieure>Every time I think I sort of have the hang of this, something breaks in a new and mystifying way. <ieure>But using the paths it printed out, I can see that /gnu/store/1jlp79i8y53nf3szzq9vvy5a7d9dbzxs-xkeyboard-config-2.38/share/X11/xkb/rules/evdev exists. <ieure>How come I can easily find that file in the inputs, but the build cannot? <zilti>Does anyone have an example for `greetd-wlgreet-session`? No matter what I try, I cannot get it to work; I am trying to set `command` to either `"swayfx"` or `(file-append swayfx "/bin/sway")`, but in both cases, I am getting an error about an invalid G-expression input. <lfam>I'm wondering if there are any metrics available for the QA system, similar to <ci.guix.gnu.org/metrics>? <jeremyc>I updated the package definitions for erlang and elixir to latest versions but want to manually verify the hash. I, however, am having problems tracking down how the URL is constructed to recreate the URL so I can manually hash. Both use git-fetch, (uri) built with (git-reference) with github base URL and (commit) with version string appended. <lfam>jeremyc: For Git sources, you can use clone the repo, check out the hash, and then run `guix hash --recursive --exclude-vcs` on the directory containing the repo <jeremyc>That doesn't yield the same result as when I built the package. When I built the package, it ultimately failed stating the hash was XYZ but Expected ABC... <jeremyc>I'm assuming what it reported it "was" is correct, but want to verify :-) <lfam>I can try to help if you tell me which package and which commit you are trying to update to <jeremyc>I just tried to recreate the hash for 25.3.2, which is what the current package points to using the same method and the hash guix hash ... creates for that is not what is in the package definition. <lfam>I can reproduce the problem <lfam>It's surprising, this should "just work" <the_tubular>Would anyone be interested in payment in exchange to help me debug my code and deploy it ? <lfam>jeremc: I tried it on another git-reference package, opustags, and calculating the hash with `guix hash` gives the expected result <lfam>Something is funny with otp.git <lfam>Could try comparing the checkout in /gnu/store with the one you created by hand with `git clone` using diffoscope, see what is different <jeremyc>I wonder if it is the comment there in OTP package definition "The tarball from ... contains many pre-compiled ... so we use this snapshot of the source ..." <jeremyc>Which is why I was trying to reconstruct what that URL may be that it is downloading. <lfam>There's no secret about what it's downloading. It clones 'otp' from github and then checks out the tag <lfam>The comment explains why we don't download the tarball <jeremyc>OK, I guess for now I'll just trust what it says it "was" and update my package definition. A bit leary of that, would really like to verify. <lfam>When simple things don't work as expected, it's useful to question the basics <lfam>Yeah, it's worth getting to the bottom of this. I'm running diffoscope now but it's taking a long time <juli`>hey y'all. quick question. if i'm packaging something that uses a vendored, unreleased version of a package we have, i should make a separate package for whatever unreleased version they're using rather than do a recursive git pull, right? <jeremyc>It's not putting the patch in the tree that is referenced before doing the hash is it? That would throw things off for us. <lfam>This is a bug, to put it simply <lfam>No, the hash is calculated on the downloaded source. I commented out the patch to be sure that hadn't changed <ieure>o m g okay, so I figured out my problem, which is that `search-input-file` and `search-input-directory` don't really search in the way you might expect and neither the code nor the documentation say how it *actually* works. <ieure>Which is that you have to give *the complete path* to the thing within the store item. <ieure>So this works perfectly: (search-input-file inputs "share/X11/xkb/rules/evdev") <ieure>While this does not: (search-input-file inputs "rules/evdev") <lfam>juli`: Making a package is preferred, but I think that reviewers can be convinced to use recursive git fetching too <ieure>"Search" in this case means "test if the exact given path exists within the store item, and return its absolute path if so". Rather than, like, searching. <ieure>Anyway, that was like an hour of my life I'll never get back. <lfam>My understanding is it's more like "match" than "search" <juli`>lfam: thanks, I figured but wanted to make sure :3 <ieure>Yes well it would certainly be nice if how it worked was actually documented. <lfam>Can you point to the misleading documentation? <lfam>It would be great to avoid confusing more people <ieure>Docstring for both those procedures also doesn't discuss that aspect of what they do. <lfam>Looks like the "searching" aspect of this procedure is more about searching multiple inputs (i.e. built packages) <lfam>It might be easiest to rename the procedure. In general, in Guix packaging, everything must be specified rather precisely. If the procedure actually searched for a file in the way you expected and returned e.g. the first matching result, it would not be idiomatic for how things work <lfam>It's already somewhat "loose" that it looks within multiple inputs and returns a match (which one? the first one?) <lfam>jeremyc: I'm going to open a bug report about this <lfam>The diffoscope analysis showed no difference to file presence or contents <lfam>Lots of difference to metadata but that is hard to make use of, since literally every file has different metadata, such as different timestamps and permissions <vivien>lilyp, the python-dbusmock update is not enough to fix gnome-shell. After moving the check phase after install (I will update the gnome-shell issue), I now get the 3 last tests to fail with: GLib-GObject-CRITICAL **: <date>: cannot register existing type 'ShellGlobal' <lilyp>looks like some typelib gets loaded twice <lilyp>this is typically the case when you have two inputs with different hashes <lilyp>if they both get loaded, they might conflict <lilyp>but date looks like a glib type <vivien><date> is me removing the current date <lilyp>ahh, okay, in that case look whether ShellGlobal (coming from gnome-shell) is somehow sourced twice <PotentialUser-30>This line repeats forever. I'm a beginner and Scheme Lisp is still difficult for me (I've started reading SICP, but my skills are not enough yet). <PotentialUser-30>I used the binary image graphical installer, how do I deal with this problem? Can I download an ISO image that will reference the working mirrors? <vivien>ShellGlobal is a type registered in the shell-12 library, defined in native code <vivien>OK I guess installing before running the tests was a bad idea, if I augment GI_TYPELIB_PATH with the build directory instead I get a different error: (EE) could not connect to wayland server <vivien>Do we have a way to run a wayland server for tests? <vivien>PotentialUser-30, the ISO was created some time ago now, so there are a lot of things to update. <vivien>It’s normal if it takes some time. <PotentialUser-30>Is it possible to install GUIX-LINX on a computer without Internet access? <vivien>I just had leftover garbage in my workspace <PotentialUser-30>Can I just download the entire repository to a flash drive and hum binaries from it when I install it? I can't access https://ci.guix.gnu.org. I can't set up the system without a graphical installation yet, so all cho mugu is to type the code into config.scm <vivien>lilyp, to be clear, the python-dbusmock was enough to build gnome-shell, I thought it did not because I had an unclean git workspace, but in fact it does <vivien>OK my git repository is REALLY messy but it should work <adanska>would someone mind pinging me? i'm just testing out a new irc client and i want to see if the notifications work :) <Franciman>Just a speculative proposal. Would you like that guix were configurable in prolog (or a logic language) rather than scheme? <jpoiret>itd: in the meantime you should be able to use `glibc-locales@2.35` <fnat>I'm not sure about the full implications of this, but my workaround was to use `(make-glibc-locales glibc)' instead of `glibc-locales', as mentioned in the bug report <itd>jpoiret: thank you, yes that's easier to use for me. :) <jpoiret>fnat: glibc-locales as a Guile symbol should be the proper one <jpoiret>the Hurd one (at version 2.37) is named glibc-locales/hurd <itd>fnat: thank you for the report/solution. :) I haven't tried your approach since (I first overlooked it, sorry, and) due to my home.scm's structure haven't found a good place to put it. <fnat>jpoiret: do you mean symbol as opposed to a string fed to `specifications->packages'? <fnat>(technically, a string within a list that gets fed to ...) <fnat>jpoiret: cool, thanks, but pinned to 2.35, I suppose? <jpoiret>the guile symbols refer to a whole package object, along with its version. That one is at version 2.35 already, you don't need to "pin" it <fnat>oh, ok, gotcha, thanks jpoiret <fnat>no sorry, i meant s/gotcha/i see/ :) <vivien>Oh, the test fails! Let’s build it with -K to see what’s going on. <vivien>ACTION sweeps the dust under the carpet <vivien>So, I think we have everything needed for GNOME 44.6, and most things for 44.7 (maybe gnome-user-docs will do a 44.7 too, but there is none yet). The next step is to have QA run through it, then merge everything into gnome-team, then test, fix usability issues, and finally merge into master! <efraim>vivien: bad news, you'll still have to wait for rust-team to merge first ;P <vivien>efraim, does rust-team make system-wide changes? On gnome-team, we have an updated eudev and udev-service-type with support for hwdb <efraim>the closest we have to system wide changes is cross-compiling librsvg <efraim>rust is fairly self contained, it just touches thousands of packages <vivien>Regarding QA, I know the feeling <vivien>We also have a world rebuild to do <vivien>In any case, we don’t seem to have conflicts, great! <anthk_>on the installation, may I suggest enabling ZRAM for i686 with < 2GB RAM machines? <anthk_>ideally, 1GB of RAM for a 2GB machine it's good <anthk_>at least it fails on the install process, even with a big enough 2-4GB swap partition <vivien>lilyp, apteryx, you both commented respectively on #67473 and #67464 with a modified commit message; should I spam you with new series for just that change, or will you reword the commits on your respective ends? <vivien>I am leaning on the spam approach so that everything is clear <vivien>Also QA has not started to evaluate the series so we don’t waste QA time <lechner>also, i always spam even on minor changes. in my mind, it was major enough that the reviewer cared to comment so they should see the result <vivien>From what I understand, you have a week to voice objections, and QA has a week to try and build the series. If it detects problems, then we solve them and go another round. If it says it’s OK or if it is on strike, we merge it and rely on CI to detect problems. I could be wrong of course. <vivien>(I will spam because there are other changes to make) <elevenkb>Hello there, is there a convention for showing the version of an unstable package? <apteryx>vivien: I don't mind the spam (less likely to fall into cracks). More efficient would be if you had commit access yourself to apply it with the nitpicks addressed by yourself :-) <apteryx>(and register yourself to the GNOME team as well :-)) <elevenkb>ok, I see that there's a function git-version for that. <vivien>For now I will just send patches :) <ieure>Looking into packaging a Matrix client and ughhhhh <ieure>FluffyChat is built with a proprietery, binary-only framework and build system. <ieure>Element is a webapp wrapped in Electron, which requires 100000 packages because JS people love nothing more than making packages for oneliners. <ieure>Element also uses yarn as both a build tool and package manager. It's not in Guix. <ieure>Might just have to.. .use the web client? ugh <lilyp>sheesh, someone was productive while I was playing MtG <vivien>I had to send a v4 for the gnome-team world-rebuilding updates :) <lilyp>thanks for the heads-up, lemme kill my local branch again <vivien>QA failed to build the revision for #67601 :( <lilyp>does gnome-shell work now for you or not? <efraim>ieure: I can recommend nheko, it's what I've been using on the desktop <ieure>efraim, I'll check out nheko. I have an intense dislike of snap/flatpak apps, they never work right. I'm appreciating that Guix packages are usually easy enough to write that I don't have to deal with that stuff. <vivien>ieure, I think I remember someone was trying to package JS things but then gave up because some of the root dependencies have unclear or proprietary licenses (was it cwebber?) <ieure>vivien, Wouldn't surprise me. While I would ideally like to have stuff in Guix proper, my goal is to have a usable setup for myself, so I can choose not to care about things like that, if I like. <ieure>The JS ecosystem is a nightmare, I can't believe people think this is the first thing new programmers should learn. <PotentialUser-32>building /gnu/store/mskq30lywz5b73lm1dxxd5ymwscxds7b-libtorrent-rasterbar-1.2.18.drv... <vivien>ieure, java is another pain in the neck, with its motto “Compile once, trash the source” <ieure>vivien, It's not great, but it's not nearly as bad as JS stuff, where they think it's a great idea to take a oneline like "if (x > 0) { return true; }" and make it a package. <ieure>I've said it before, I'll say it again: NPM isn't a package manager, it's installable Stack Overflow answers. <anthk_>I've seen worse; build systems using JS instead of a dumb and simple makefile <graywolf>Or maybe: How long should I wait in general before asking for review? <vivien>Kolev, is there a supdup executable somewhere in /gnu/store/4xgj9xpc70126k1fs5kysb05fj0zj2vl-supdup-0.0? Maybe in the /bin subdirectory? <Kolev>vivien, there is. I can run it from there. <befalou>anthk_: check out Fractal 5, just released and instant favourite <vivien>Kolev, if you run guix shell --rebuild-cache -f supdup.scm -- supdup, is it better? <evilsetg>I am trying to make a derivative of the installation image system. But when I want to alter the services I get the error "more than one target service of type 'shepherd-root". This happens even when I inherit from the installation os and then do anything with the services. See the code here: https://paste.debian.net/1300055/ <graywolf>evilsetg: operating-system-user-services <sarg>also, (home-page) of guile-netlink is returning 502 <pastor>Hi, Is it possible to select the `gcc-toolchain' used by the `cmake-build-system'? <nckx>pastor: Like, the version? Yes, but ‘select’ where? <nckx>For example, a likely answer would be ‘guix shell -e '(@ (gnu packages commencement) gcc-toolchain)'’. <nckx>roptat: sarg> also, (home-page) of guile-netlink is returning 502 <pastor>nckx: I've noticed that I can provide `gcc-12' withing the `native-inputs` field and the build system seems to pick up <pastor>I thought `gcc-*' was deprecated <pastor>nckx: Shouldn't I be using gcc-toolchain instead? <nckx>pastor: I'm missing some context here, I think. <pastor>nckx: I'm trying to package something which expects to have gcc@12 <nckx>Then add gcc-12 to native-inputs, not gcc-toolchain. <nckx>The gcc packages are not deprecated. <nckx>‘guix install gcc’ is… for better or worse. <pastor>Yeah. But I've seens that the `gcc-*' packages have the follwing string "This package is superseded by gcc-toolchain@11.3.0 package." <nckx>That is not relevant to writing packages. <cwebber>vivien: you may be remembering a blogpost I wrote <nckx>pastor: But it is confusing, and no good solution has yet been found. <vivien>I remember you had trouble with jquery <nckx>pastor: The background is that people used to ‘guix install gcc’ or ‘guix shell gcc’ and expect to be able to build things. Hah! Fools. So that was made impossible. But in Scheme code, e.g., for packages, gcc/gcc-N is still the right thing to use. <pastor>nckx: makes sense. Thanks for clarifying! <nckx>Kolev: Bogus ) after the key fingerprint. <nckx>Move it to the very end of the file. <vivien>“Our deployment and build setups have gotten so complicated that I doubt anyone really has a decent understanding of what is going on, really.” (that was said 8 years ago) <ieure>efraim, nheko won't let me log into my homeserver. :/ <Franciman>how can i get the list of installed desktop entries available? <civodul>sarg: i’m missing context for the guile-netlink patch and i’m not as qualified as roptat anyway <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, parnikkapore says: Thanks for fixing the Cuirass processor-count issue (https://issues.guix.gnu.org/67502); it also affected my own setup, and now I can get rid of the local patch that fixes that :D <vivien>Franciman, you should look at $XDG_DATA_DIRS, but if the question is, “why won’t the program I just installed appear”, then the answer is to log out and log in <Franciman>thanks, my question is how do i know the .desktop names available? <Franciman>i want to set zathura as my default pdf reader, but i don't know its .desktop name <vivien>If you installed it with “guix install”, then it should be in ~/.guix-profile/share/applications/ <Franciman>can I set the default applications in guix ? <vivien>Some gnome-team patches have been applied, but the corresponding issues are still open, is it normal? <vivien>We will have a list when QA tells us it can’t apply the patches because they have already been applied <vivien>(commit 260b054aeaa0739bed1637742b6094c97dab47f2) <vivien>260b054aeaa0739bed1637742b6094c97dab47f2 <vivien>Kolev, the answer may lie in /var/log/guix/drvs/70/jhiwz2kxcnrfn972wb0g58bi612kp3-kolev.drv.gz <ieure>Correct, that's the build log, which should show why it failed. <Kolev>(exception misc-error (value #f) (value "no code for module ~S") (value ((packages linux))) (value #f)) <vivien>There’s no (packages linux) module in guix, but there is (gnu packages linux) <vivien>Maybe you could start by looking at your channels, if you have any, and grep for '(packages linux)' to find where the problem is, then replace it with (gnu packages linux) <vivien>If it’s a bug in guix, it is more serious <ieure>Fractal looks really nice, I wonder if it's reasonable to package. <ieure>Works with --no-substitutes, RIP my CPU fan <Kolev>vivien, I did (define-module (kolev packages linux) <ieure>Kolev, Then you need to use the (kolev packages linux) module. <jeremyc>ieure, that's good to know. I was getting 10-20k/sec yesterday again for a few hours. <civodul>ieure: for some reason ‘guix publish’ was not responding, i’ve restarted it <ieure>See, this is why I'm not jazzed about using that for a local substitute server. <ieure>Kolev, Making a channel has nothing to do with your problem. There's no magic in Scheme imports; if you declared your module (kolev packages linux), that's the thing you have to use. <Kolev>ieure, but guix pull is probably doing it. I'm not using it anywhere... <ieure>Kolev, I don't think guix pull does anything like that. Something has to be trying to import the (packages linux) module. <nckx>This is a channel bug, not Guix. <nckx>Your directory structure defines a (packages linux) module, although you probably didn'n mean to. <nckx>Through the 'directory' entry in .guix-channel. <nckx>Either move your code to kolev/kolev/packages/*.scm, or remove the 'directory' entry (why is it there?). <nckx>I was talking to myself.