IRC channel logs


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
<cmiller>cddr: (though not 100% sure, kinda have my problems differentiate all those commands)
<peanuts>"GNU Guix Reference Manual"
<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?
<nckx>They used to.
<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.
<civodul>ci.guix uses ‘guix publish’
<nckx>The ‘Priority’ field of /nix-cache-info is AFAIK entirely historic cruft.
<ieure>civodul, Okay.
<cddr>nckx cool.
<civodul>bordeaux.guix uses the nar-herder:
<peanuts>"bayfront.scm\hydra - guix/maintenance.git - Articles, talks, and documents for Guix maintainers"
<nckx>Kolev: Cool. This is what I had that built, but I didn't look at the output. <>.
<Kolev>nckx, guix shell: error: supdup: unknown package
<nckx>If you're using my paste verbatim, it's missing some bytes at the bottom.
<nckx>wl-copy did a weird.
<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>does anyone know why?
<cddr>I have a usb-c thunderbolt doc that I can't use with guix currently, could it be because of this
<peanuts>"system.scm\gnu - guix.git - GNU Guix and GNU Guix System"
<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
<nckx>--help: unknown host.
<nckx>A good start.
<nckx>ACTION → 😴💤
<Kolev>I'm not getting that result.
<Kolev>Good night .
<parnikkapore>sneek, later tell civodul Thanks for fixing the Cuirass processor-count issue (; it also affected my own setup, and now I can get rid of the local patch that fixes that :D
<sneek>Will do.
<peanuts>"[Cuirass] cuirass remote-worker gets the CPU count wrong on the OverDrive"
<cow_2001>scroll won't build :(
<ieure>Every time I think I sort of have the hang of this, something breaks in a new and mystifying way.
<ieure>I have this thing I'm trying to build:
<peanuts>"debian Pastezone"
<ieure>It fails with this error, which I believe means it can't find an xkb/rules/evdev file in the package inputs:
<peanuts>"debian Pastezone"
<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 <>?
<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>jeremyc: Hm, tricky
<lfam>I can try to help if you tell me which package and which commit you are trying to update to
<jeremyc> is the package I am referring to. I changed version number to 26.1.2, which I then figured the commit was OTP-26.1.2, which is a tag.
<peanuts>"erlang.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System"
<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 ?
<the_tubular>Please whisper me
<the_tubular>(Scheme code ofc)
<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>Oh.... I missread...
<lfam>No worries
<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
<peanuts>"Build Utilities (GNU Guix Reference Manual)"
<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
<jeremyc>OK, thank you for helping out.
<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
<lfam>jeremyc: <>
<peanuts>"Cannot reproduce hash calculation of erlang package"
<jeremyc>Great, I'll keep an eye on it.
<adanska>Hi Guix!
<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'
<vivien>Does it sound familiar to you?
<lilyp>looks like some typelib gets loaded twice
<lilyp>this is typically the case when you have two inputs with different hashes
<vivien>Does the gtk+ / gtk duo count?
<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
<vivien>I censored it
<lilyp>ahh, okay, in that case look whether ShellGlobal (coming from gnome-shell) is somehow sourced twice
<PotentialUser-30>Hi all
<PotentialUser-30> I decided to try installing GUIX but ran into a problem:
<PotentialUser-30>substitute: updating substitutes from ''... 0.0%
<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?
<janneke>PotentialUser-30: the cookbook has some notes on an air-gapped install --
<peanuts>"Cluster Network Access (GNU Guix Cookbook)"
<vivien>Oh dear it’s passing the tests
<vivien>I just had leftover garbage in my workspace
<vivien>Sorry for bothering you
<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 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>it was*
<vivien>… or not
<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 :)
<adssda>adanska: ping!
<Franciman>Just a speculative proposal. Would you like that guix were configurable in prolog (or a logic language) rather than scheme?
<itd>I observe something similar to which does not appear with `guix pull --commit=ea348b105d1fb8f02b3ca8665c5ad33928f7483f`.
<peanuts>"guix package: error: package glibc-locales@2.37 does not support x86_64-linux"
<itd>I.e., this issue might be related to
<peanuts>"Wrong glibc-utf8-locales package used on GNU/Hurd"
<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 ...)
<nckx>Kolev: Eh, weird? I'm using ‘guix shell -f supdup.scm’ with
<jpoiret>fnat: yes
<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>ACTION builds something
<vivien>Oh, the test fails! Let’s build it with -K to see what’s going on.
<vivien>The build succeeds.
<vivien>ACTION sweeps the dust under the carpet
<futurile>morning everyone
<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
<vivien>Wow that’s cool
<efraim>rust is fairly self contained, it just touches thousands of packages
<vivien> ??! You haven’t even started to build it!
<efraim>the build farm fell behind :/
<peanuts>"Branch rust-team Guix Quality Assurance"
<vivien>peanuts is falling behind too!
<peanuts>vivien: Hi, for comments please contact my maintainers at
<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_>if not, guix with fail
<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?
<peanuts>"[PATCH gnome-team 00/12] Hopefully the last world rebuild"
<peanuts>"[PATCH gnome-team 0/4] Update mutter"
<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>vivien / what does "queuing for Dec 10th" mean here, please?
<peanuts>"[PATCH gnome-team 00/12] Hopefully the last world rebuild"
<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 think I’ll spam.
<vivien>(we merge it into gnome-team)
<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.
<elevenkb>so nvm.
<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>32 new messages
<lilyp>sheesh, someone was productive while I was playing MtG
<vivien>It’s apteryx ’ fault
<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?
<peanuts>"[PATCH gnome-team] gnu: Add xdg-desktop-portal-gnome."
<vivien>It does
<lilyp>good to know
<efraim>ieure: I can recommend nheko, it's what I've been using on the desktop
<efraim>or element from flatpak
<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.
<anthk_>no gtk4 or qt5/6 client?
<anthk_>or for pidgin
<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>I have long 'check' phase. Is it normal?
<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>Would someone with commit privileges have time to review ? It looks like gnu/packages/bittorrent.scm has no team, so I am not sure it would be picked up on its own...
<peanuts>"[PATCH 0/5] Update libtorrent-rasterbar and dependent programs"
<graywolf>Or maybe: How long should I wait in general before asking for review?
<Kolev>I can get supdup.scm to build, but I cannot do `guix shell -f supdup.scm -- supdup`.
<peanuts>"guix-channel/supdup.scm at main - guix-channel -"
<peanuts>"debian Pastezone"
<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
<anthk_>fractal 5?
<befalou>gtk4 matrix client
<vivien>Kolev, if you run guix shell --rebuild-cache -f supdup.scm -- supdup, is it better?
<vivien>(with --rebuild-cache)
<Kolev>vivien, it works!
<peanuts>"debian Pastezone"
<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:
<peanuts>"debian Pastezone"
<evilsetg>Does anyone know why this would happen?
<graywolf>evilsetg: operating-system-user-services
<graywolf>is what you should use
<evilsetg>Oh, okay.
<evilsetg>Thanks, I'll try that.
<sarg>civodul, can you check this patch for guile-netlink? I've mailed Julien a week ago, no answer yet.
<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
<nckx>pastor: Correct.
<pastor>I thought `gcc-*' was deprecated
<Kolev>Throw to key `match-error' with args `("match" "no matching pattern" (authorizations (version 0) (("631C C434 A56B 5CBD FF21 2346 9764 3795 FA3E 4BCE") (name "kolev"))))'.
<peanuts>"csh/guix-channel: My Guix channel - guix-channel -"
<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
<pastor>nckx: Alright. Thanks!
<nckx>pastor: But it is confusing, and no good solution has yet been found.
<vivien>I remember you had trouble with jquery
<cwebber>gettin' close to a decade old ;)
<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)
<vivien>(or rather, written)
<vivien>But now we have web components
<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 (; it also affected my own setup, and now I can get rid of the local patch that fixes that :D
<peanuts>"[Cuirass] cuirass remote-worker gets the CPU count wrong on the OverDrive"
<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 ?
<Franciman>i mean in scheme code
<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>(for instance, #67472)
<peanuts>"[PATCH gnome-team] gnu: yelp: Update to 42.2."
<vivien>(commit 260b054aeaa0739bed1637742b6094c97dab47f2)
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<Kolev>I got this error running `guix pull` and I don't know what it means.
<peanuts>"debian Pastezone"
<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>Is horked? Getting this trying to build a package: 2. &message: " HTTP download failed: 504 (\"Gateway Time-out\")"
<cwebber>it's also being slow for me
<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.
<Kolev>ieure, I'm trying to make a channel.
<peanuts>"guix-channel/linux.scm at master - guix-channel -"
<alethkit>I *think* bordeaux works
<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.
<ieure>Yes, I just found that:
<peanuts>"guix-channel/.guix-channel at master - guix-channel -"
<ieure>Kolev, I have a channel working, if it's helpful to reference that:
<peanuts>"ieure/atomized-guix - atomized-guix -"
<nckx>Either move your code to kolev/kolev/packages/*.scm, or remove the 'directory' entry (why is it there?).
<Kolev>nckx, oh, I see. Thanks.
<nckx>YM, GN, TTYL.
<nckx>Dammit. *YW.
<nckx>I was talking to myself.
<nckx>ACTION -> zzz