IRC channel logs


back to list of logs

<nckx>sneek: Later tell adamnr the logging bot has trouble accepting the passings of the months.
<sneek>Got it.
<HexMachina>hi guix: I'm trying to use the clang-toolchain package to compile a project that is currently not packaged in guix; I'm trying to invoke clang with the -m32 flag to generate a 32-bit x86 (i386) binary but /gnu/store/...-clang-toolchain-17.0.3/include/gnu/stubs.h tries to include gnu/stubs-32.h, which doesn't exist
<HexMachina>The clang-toolchain/include dir has include/gnu/stubs.h and include/gnu/stubs-64.h but no include/gnu/stubs-32.h
<nckx>bienjensu: Here too. I find this behaviour surprising, perhaps even bug-like.
<HexMachina>Is there any way to get a version of clang-toolchain that will let me compile 32 bit code on my 64 bit host?
<rebiw>I'm having trouble installing the latest version of krita. Using --with-latest=krita.
<rebiw>The following error appears: gpgv: Can't check signature: No public key
<elevenkb>I can't compile xelatex documents because xelatex.fmt is not found.
<adamnr>Thanks nckx
<sneek>adamnr, you have 1 message!
<sneek>adamnr, nckx says: the logging bot has trouble accepting the passings of the months.
<elevenkb>nvm, I found this:
<peanuts>"xelatex is broken, because xelatex.fmt is missing"
<nckx>rebiw: Guix should prompt you to add the key?
<nckx>To $HOME/.config/guix/gpg/trustedkeys.kbx ?
<nckx>Did that not work?
<rebiw>no. I'm trying again.
<nckx>Odd. Works here (after answering y).
<rebiw>It is the first time (I believe ) that guix asks for some gpg related operation. I'm a complete gpg noob, maybe I need to configure something in my system.
<rebiw>This are the errors after answering yes.
<rebiw>guix install: warning: missing public key 064182440C674D9F8D0F6F8B4DA79EDA231C852B for 'mirror://kde/stable/krita/5.2.1/krita-5.2.1.tar.gz'
<rebiw>guix install: error: failed to fetch source from 'mirror://kde/stable/krita/5.2.1/krita-5.2.1.tar.gz'
<nckx>I answered y, not yes, although I don't know if that matters.
<rebiw>I meant y
<nckx>Let me try again.
<rebiw>Are you using guix system? I'm using debian.
<nckx>HexMachina: Note that the stubs*.h ‘provided’ by clang-toolchain is just a symlink to glibc's, the real provider. Guix's glibc is not built with multilib support, full stop. You should be able to use -m32 with a compiler built with Guix's --system=i686-linux option.
<nckx>rebiw: I am using Guix System, although I don't immediately see how that would make a difference here…
<nckx>HexMachina: I think there's an open feature request to make -m32 work with the 64-bit packages…
<nckx>…yep, but it's in ‘patches welcome’ state.
<peanuts>"gcc -m32 can't find stubs-32.h"
<nckx>rebiw: This is what I get on my laptop <> but I have access to a Debian machine, let's see.
<nckx>Note that the file did not exist and was created. Maybe that's different for you.
<HexMachina>nckx: ah, well that's unfortunate for my use-case but makes sense. Thanks for the link! I'll look into useing --system=i686-linux
<PotentialUser-77>hi there, i am trying to turn a list of objects: ( local-file, package, origin... anything lowerable)  into a string which includes their output paths and is placed into the store. Is this possible to do with simple functions like ( computed-file, ....) or must i learn how to use the monadic store functions?
<janneke>samplet: "someone" suggested a possible connection between and mes on #guile-steel
<PotentialUser-77>i guess i am looking for a plain-file like function that accepts a gexp and evaluates it and stores the resultant string, is this computed-file~s function?
<nckx>rebiw: OK, this is what I get on Debian <> but it looks like a network error. This machine can't access the IPv6 Internet.
<janneke>it's still early days, but with modular mes it may not seem so impossible to think about running pre-scheme on mes?
<rebiw>nckx  Thanks! this would be useful. I'm probably having the same issue.
<nckx>So it's not (purely) a Guix issue.
<samplet>janneke: I’m optimistic ATM. I’ve been hacking away at ‘syntax-case’ and have quite a lot running. One problem is that as the foundations of the Mes interpreter keep shifting, it keeps getting cruftier. :/
<nckx>I never set up GPG on this machine.
<nckx>Whilst on my working laptop I did.
<janneke>samplet: :) , :-D, :-/
<lilyp>vivien: turns out guix refresh is wrong and there's a g-s-d 44.1; would bumping that resolve our issue?
<janneke>optimism and working code is really great, the interpreter has been getting more and more worrisome, esp. after moving to m2-planet
<rebiw>nckx I have not set up gpg either I will try to do that (I need to look it up)  and see how it goes.
<janneke>we could do with a new perspective on this some time
<nckx>Maybe this is what made it work, don't have time to test just now:
<vivien>lilyp, gnome-settings-daemon is already at 44.1 on the gnome-team branch
<vivien>I think?
<samplet>janneke: I remember you saying that, and my working is not making it better, exactly. It would be nice to settle down and work on speed and legibility. Modules was a disruptive change, and ‘syntax-case’ is going to be rough, too.
<nckx>rebiw: Yes, that made it work! Seems like [at least] Debian's gnupg does not ship with a working default [anymore].
<rebiw>nckx Thanks! this will point me in the right direction. I need to learn about this keyserver stuff.
<janneke>samplet: yeah, no reason to let this discourage ourselves, we've come a long way and i'm sure this will also work out well somehow
<PotentialUser-32>Hello! I'm trying to do "guix pull", but "guix substitute: warning: connection failed: Connection timed out". Is it down now?
<nckx>Nope, but it might be flaky.
<nckx>Does it happen consistently?
<PotentialUser-32>I have tried two times.
<nckx>This would not cause that error, but it's more bad news:
<nckx>(Those are the build stati for the ‘guix pull’ substitutes.)
<nckx>PotentialUser-32: Does ‘guix download’ work?
<PotentialUser-32>charlzk@Carla:~/Downloads$ guix download
<PotentialUser-32>Starting download of /tmp/guix-file.zCtIL0
<PotentialUser-32>In procedure connect*: Connection timed out
<PotentialUser-32>Starting download of /tmp/guix-file.zCtIL0
<PotentialUser-32>following redirection to `'...
<nckx>You got quieted by a bot. Use for many-line pastes.
<nckx>That said, I got the gist this time.
<nckx>I tried a few times but can't reproduce your ‘In procedure connect*: Connection timed out’ at all.
<nckx>I wonder if this is something specific to your connection (by which I don't necessarily mean your machine, could be upstream).
<peanuts>"debian Pastezone"
<nckx>I didn't see that it succeeded the second time.
<PotentialUser-32>May be has been blocked for users from Russia?
<lechner>by whom?
<nckx>PotentialUser-32: Yes, it was, but I don't see why you'd then succeed on the second try.
<nckx>lechner: The MDC.
<lilyp>vivien: oops, right…
<lilyp>but why do we fail to mock it then?
<PotentialUser-32>I have checked accessibility and, yes it is blocked for Russia.
<nckx>Yeah, sorry about that, it's nothing we control.
<nckx>You might have more success with
<nckx>If is blocked you might as well remove it from the list of defaults.
<nckx>Or use the Tor service, or a VPN, or something. Not something with which I can help.
<PotentialUser-32>Thank you!
<vivien>lilyp, I have no idea. The mock seems really simple to me.
<vivien>There’s no program to execute, no typelib to load
<nckx>PotentialUser-32: Oh, there's also <>. This is the second time this month that I forget about this page that I myself wrote… 😒
<peanuts>"Group:Guix/Mirrors - LibrePlanet"
<nckx>If anyone knows of or operates a reliable mirror that isn't yet listed, let me know.
<PotentialUser-32>Interesting. Thank you!
<lilyp>hmm, it appears dbusmock is 5 versions out of date, but then there's a cycle with upower (fun)
<graywolf>Hm, could someone help me with ? The QA fails (, but I do not understand why. I am importing (gnu packages version-control), and it does work for me locally.
<peanuts>"[PATCH 0/5] Update libtorrent-rasterbar and dependent programs"
<graywolf>Any idea?
<nckx>#$@% is just the best.
<ieure>I think you need git in your inputs? But isn't there some built-in way to apply patches, so you don't have to manually donk around with Git?
<graywolf>ieure: I assumed the gexp "carries" the dependencies with it, and it works locally. But will try it, thank you for the tip.
<graywolf>For reasons I cannot use the built-in way :/
<peanuts>"[PATCH 0/5] Update libtorrent-rasterbar and dependent programs"
<vivien>lilyp, “SYSTEM_BUS = False” in (mutter output)/share/mutter-12/tests/dbusmock-templates/ looks very sus
<vivien>I’ll try with SYSTEM_BUS = True
<nckx>graywolf: It does carry.
<nckx>You can use ‘this-package-input’ though.
<nckx>graywolf: What does the working source builder (listed in the source's .drv) look like?
<ieure>graywolf, See the `patches' field of `origin':
<peanuts>"origin Reference (GNU Guix Reference Manual)"
<ieure>You 100% don't have to do this manually.
<graywolf>As I mentioned in the commit message, (patches) refuses to handle binary patches
<ieure>Ah, I see. That's unfortunate.
<graywolf>I would very much prefer not to have to do this manually.
<graywolf>nckx: Trying to find out... is the derivation, but
<nckx>Can you download the file?
<nckx>By which I mean the file added by the patch.
<ieure>graywolf, You could also add a patch which disables the test_create_torrent test instead.
<graywolf>Hm, probably. I mean, definetely
<nckx>I get ‘error: corrupt patch at line 28’.
<nckx>For /gnu/store/7ndv3y2nwwf8qmg6k8ni421apyfrj67r-libtorrent-rasterbar-fix-tests.patch.
<graywolf>nckx: Can package have multiple sources?
<vivien>Nevermind it seems to be intended that way
<nckx>No, but you can add origins as inputs.
<graywolf>Oh I see. Then I could just copy it over instead of using the git. Will give that a try, thank you very much.
<nckx>You'd have to revert to the alist input style for the native-inputs, I think, then you can assoc-ref it.
<nckx>It's still hacky but 32% less hacky.
<graywolf>Just to make sure, something like (inputs `((boost . ,boost) (openssl . ,openssl) (my-file . ,(origin ...))) ?
<graywolf>(I will look up the syntax, just making sure I got the idea)
<nckx>Right, but native, since not architecture-dependent.
<graywolf>Got it, thanks a lot
<nckx>The syntax is wrong in multiple ways but I'll shut up then 😉
<elevenkb>How does one use a package like texlive-stix2-otf practically? I've added it to a manifest but can't \setmainfont{STIX Two Text} for example.
<civodul>avp: thanks for
<peanuts>"#67570 - [PATCH] gnu: kubo: Fix build. - GNU bug report logs"
<civodul>i’ll take a look soonish
<civodul>(if nobody beats me)
<vivien>The dbusmock <-> upower cycle is not nice
<vivien>I’m trying to run the example.tmpl machine with the new gnome-shell, I will let you know if it is a real gnome-shell problem or just a dbus mock problem
<vivien>But I have a few webkitgtks to build before that
<lilyp>try reverting e21f0cb7b7a87992004193cd56638ad961fe5928; then you can just build mutter instead
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<nckx>This is the second time that overloading my build server with builds OOM'd, of all things and for some reason, ZNC.
<nckx>Which, rounded down, uses exactly no RAM. Weird…
<ieure>Linux's OOM killer is well-known for making seemingly ridiculous choices like that. The reality is that it's just a very difficult situation to be in, and the obviously right behavior on one situation will be ridiculous in a different one.
<ieure>It looks like there's a per-process oom_adj setting in /proc, which you can use to tell the kernel how important a thing is.
<ieure>ex. if you're OOM building on a desktop machine, you probably want to kill the build and leave the desktop up. If you're OOM building on a build machine, you probably want to kill things other than the build first.
<nckx>The first time it happened I thought of tweaking oom_score_adjust (or whatever it's called), but thought, no, surely this was a one-time fluke. Now I'll have to learn about oom_score_adjust.
<nckx>I hate learning things.
<nckx>Oh, oom_adj != oom_score_adj. I didn't know that. Thanks for the hint, ieure.