IRC channel logs
2023-12-01.log
back to list of logs
<nckx>sneek: Later tell adamnr the logging bot has trouble accepting the passings of the months. <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. <sneek>adamnr, nckx says: the logging bot has trouble accepting the passings of the months. <nckx>rebiw: Guix should prompt you to add the key? <nckx>To $HOME/.config/guix/gpg/trustedkeys.kbx ? <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>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>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? <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? <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. <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 <vivien>lilyp, gnome-settings-daemon is already at 44.1 on the gnome-team branch <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: ci.guix.gnu.org: connection failed: Connection timed out". Is it down now? <nckx>Nope, but it might be flaky. <nckx>Does it happen consistently? <nckx>(Those are the build stati for the ‘guix pull’ substitutes.) <nckx>You got quieted by a bot. Use paste.debian.net 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). <nckx>I didn't see that it succeeded the second time. <nckx>PotentialUser-32: Yes, it was, but I don't see why you'd then succeed on the second try. <lilyp>but why do we fail to mock it then? <nckx>Yeah, sorry about that, it's nothing we control. <nckx>You might have more success with bordeaux.guix.gnu.org. <nckx>If ci.guix.gnu.org 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. <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>If anyone knows of or operates a reliable mirror that isn't yet listed, let me know. <lilyp>hmm, it appears dbusmock is 5 versions out of date, but then there's a cycle with upower (fun) <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 :/ <vivien>lilyp, “SYSTEM_BUS = False” in (mutter output)/share/mutter-12/tests/dbusmock-templates/gsd-color.py looks very sus <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>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. <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. <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. <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. <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 <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>Oh, oom_adj != oom_score_adj. I didn't know that. Thanks for the hint, ieure.