IRC channel logs

2024-08-19.log

back to list of logs

<llano>still 'Could not find OpenGL (missing: GLES2)'
<nikolar>Heh I was kidding
<llano>probably some wizardry needed that is beyond my capabilities, which is fine for now.  I'm just experimenting currently.
<nckx>nikolar: Oh, I was not annoyed.
<nckx>olndrxyz: I get it too.
<nikolar>nckx: btw after my patch is merged, is it immediately live
<nckx>olndrxyz: Something merely being present in the store means very little, and installing packages is unlikely to have any effect in this case. IceCat should be (and IIRC, was) configured to find these libraries by their absolute names, and it seems like something broke.
<nckx>nikolar: Yes.
<nikolar>Heh apparently the package I fixed managed to get built
<nikolar>I guess less activity on the server
<nckx>I did restart the build when you originally reported the failure, but let's not rely on {IRC rando with admin access, phase of the moon} tuples in our builds.
<nckx>Well, not any more than we already do.
<nikolar>Lol of course
<nikolar>I was just surprised they it built
<nckx>Same.
<nikolar>Since it seems that there are constant builds on the aarch64 servers
<nikolar>s/they/that
<civodul>nckx: hey! no worries, we’ll find out; also maybe worth adding an entry in etc/news.scm?
<civodul>until then…
<civodul>ACTION -> zZz
<nckx>sneek: Later tell civodul Good idea. Good night!
<sneek>Okay.
<fnat>When sending a patch (e.g. a v2), what's the best practice? Can it be an attachment? Or should I reply to my reviewer first and then send the patch separately via git-send-email?
<fnat>Sent as an inline attachment... hope it's ok.
<mirai>fnat: with git-send-email -v<YOUR-REVISION-HERE/e.g. 2>
<mirai>+50 internet points if you manage to use --in-reply-to=<ORIGINAL-THREAD-ID> as well
<jaft_r>mirai: where do you get the original thread ID? I always try to include that but it's never clear to me if I'm using the right number.
<mirai>if you use ublock-origin you can paste this (https://paste.debian.net/1326849/) snippet into your "My Filters"
<mirai>after you apply that you should see a "Message-ID" under the sender name when you open this https://issues.guix.gnu.org/72699 for example
<mirai>don't forget the angle brackets
<mirai>you really have to use it as --in-reply-to='<cover.1724000901.git.liliana.prikler@gmail.com>'
<jaft_r>AH! Welp; /definitely/ haven't been using the right ID. But this is good to know. And with the brackets; noted. Thanks a ton.
<mirai>anytime
<PuercoPop>how do I debug/test a channel. Currently my channel is failing when I do guix pull because what appears to be an unbound variable. But I get no warnings when I do guix repl -L . in the channel's repository
<mange>Can you load all of the modules in your channel in that REPL?
<PuercoPop>mange: Let me try. is there a repl helper to load all the modules in a directory?
<mange>I don't know, sorry.
<nikolar>nckx: thanks for the improvements for the commit :)
<Altadil>Hello. I’m trying to write a cuirass specification using a custom job. According to the manual, there is a build type (custom . list) where list is a list of modules with a cuirass-jobs procedure (and said procedure returns jobs). However, this is the only mention of cuirass-jobs in the whole manual. I also tried to grep for it in the sources but also got only one lone mention… does anyone know where one can find more about how
<Altadil>*about how to write this cuirass-job procedure
<cbaines>nckx, 58a839273d1e4fac2b3a0ec456aabdf82deaa124 leads to nearly 4000 rebuilds
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=58a839273d1e4fac2b3a0ec456aabdf82deaa124
<nckx>cbaines: Is core-updates still a thing?
<cbaines>nckx, right now it definately is https://qa.guix.gnu.org/branch/core-updates and hopefully it can be merged soon
<ngz>Hello Guix
<civodul>o/
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, nckx says: Good idea. Good night!
<civodul>yes, i think ‘core-updates’ is mergeable or almost
<civodul>we should check “make assert-binaries-available”
<cbaines>I reconfigured with core-updates yesterday and that seems to have gone OK
<ngz>Great news!
<cbaines>lollypop is broken unfortunately https://issues.guix.gnu.org/72042
<cbaines>and I think there's a problem with the chromium source
<civodul>oh
<civodul>i know petsc is broken too, i was planning to work on it
<civodul>we should make a call on guix-devel, see what people consider blocking/problematic, and set a deadline
<cbaines>there's a few derivations blocking lots of builds on i686-linux https://data.qa.guix.gnu.org/revision/1a30e510464f5d3232f80007328b9af4dd90c6d4/blocking-builds?system=i686-linux&target=none&limit_results=50
<galois`>Is is possible to program in C# with monogame on guix?
<galois`>I don't think it is.. But it would be nice if it could be verified. Would I need a vm for it?
<ngz>galois`: Monogame is not packaged in Guix, so I would answer "not right now", at least. Also, I do not know much about C# programming, so there may be more bricks missing.
<galois`>ngz: Thanks
<ngz>So the first step could be to package it ;)
<galois`>Not sure if this is possible. But yeah..
<robin>afaik anything c# remains unpackaged (possibly because it's hard to bootstrap)
<robin>so packaging mono (or roslyn or whatever if it's compatible) would be a prerequisite for packaging monogame :)
<AwesomeAdam54321>galois: I did preliminary work for bootstrapping C#: https://issues.guix.gnu.org/57625
<AwesomeAdam54321>Building old versions of mono is difficult though because I couldn't figure out how to fix a ./configure test
<AwesomeAdam54321>But it should be possible to finish the bootstrap by starting from pnet
<olndrxyz>Hi! What do you use to enter the sudo password right away when running `guix pull && sudo guix system reconfigure config.scm`? `sudo sh -c "su -c 'guix pull' $USER && sudo guix system reconfigure config.scm"` returns "hint: After setting PATH, run hash guix to make sure your shell refers to /home/user/.config/guix/current/bin/guix".
<fnat>mirai: Ha, thanks, brilliant. Do you reckon I should resend this then? https://issues.guix.gnu.org/72398#2 The patch is still visible as an attachment so maybe it's fine?
<Kabouik>It seems my `~/.guix-profile` is not in the $PATH when I ssh into a foreign distro with guix-installed packages. Is there some extra configuration required?
<robin>AwesomeAdam54321, oh, that's awesome! i didn't know whether dotgnu might be useful there :)
<robin>presumably one could then bootstrap up to modern mono with a rust-style compiler chain...and maybe roslyn if any version could be bootstrapped from mono...
<robin>it'd be great to have c# support in godot and not just gdscript
<Rutherther>Kabouik yes you need to source etc/profile of your guix-profile
<Kabouik>Thanks Rutherther
<civodul>ACTION restarted a bunch of workers behind ci.guix
<nikolar>civodul: what are the aarch64 runners btw
<taeaad>I'm trying to write some manifest files for packages from Pypi, but I get this error: "scikit_build_core.errors.CMakeNotFoundError: Could not find CMake with version >=3.18" but this doesn't get fixed by installing guix install cmake...
<civodul>nikolar: those behind ci.guix are Honeycombs and Overdrive (2-core machines that were made by SoftIron)
<civodul>we need to upgrade
<nikolar>only 2 cores
<civodul>yeah…
<nikolar>maybe i could get a rk3588 board and build some substitutes :P
<civodul>nikolar: if you want to donate and possibly host a build machine, that’d be welcome!
<nikolar>heh i'll think about
<civodul>:-)
<lynn_sh>i switched from void to guix recently (same laptop) and noticed a huge dip in battery life. im guessing this has something to do with the amount of desktop services normally running, but i was wondering if there's something official i can look at about this, or perhaps a setup from soneone i can browse? I checked the official documentation but
<sneek>lynn_sh, you have 2 messages!
<sneek>lynn_sh, nckx says: Guix doesn't use any weird/custom gnupg locations I'm aware of. Mine are in ~/.gnupg/private-keys-v1.d/ if that helps.
<sneek>lynn_sh, nckx says: Also, make sure your permissions survived the copy. They should be 700 for the directory, 600 for the files.
<lynn_sh>there seems to only be batsignal service and upower.
<lynn_sh>nckx just got your messages, i think the permissions on my gpg key didnt survive. i transferred it as an .asc and it all worked. i just needed to get a pinentry client.
<Rutherther>lynn_sh there is power profiles daemon or tlp to manage your power usage. https://guix.gnu.org/manual/devel/en/html_node/Power-Management-Services.htmlAlternatively it could be related to some optimizations you used on gentoo, but you dont on guix.
<Kabouik>Anyone here compiling code for Arduino from Guix? I installed arduino-cli using a Debian distrobox and exported the executable to Guix, then installed all required libraries for my project, then ran a guix shell gcc because it is required, but then I am getting these errors which I really have no idea how to debug: https://0x0.st/XJBL.txt (the same Arduino code works fine for a collaborator using Windows and VSCode, in fact he wrote the code, so maybe
<Kabouik> there are incompatibilites due to Windows?).
<Kabouik>This may or may not be off-topic, I don't know if the issue is related to how Guix works.
<Rutherther>Why dont you export everything from the container? I think you are going to have hard time mixing fhs stuff with nonfhsAlso I would expect it needs gcc for the mcu target, which depends on what arduino you are using, not gcc for Linux. Though I might be mistaken.
<noracodes>does anyone else here use KDE? for some reason, applications don't seem to be able to add icons to the system tray, neither those installed through guix-home nor through flatpak.
<rynn>Does anyone know if there's a trick to setting your default browser in Guix? Both Lagrange (gemini client) and Newboat (terminal RSS reader) are unable to launch URLs.
<rynn>I'm using Icecat and have it set as the default browser in Gnome shell, but it doesn't seem to make a difference.
<Kabouik>Rutherther: you're right, I should try to do everything from the container. I just was confused regarding glibcxx, I'm not sure how I can find it for the mcu target. The board being installed in arduino-cli, I would expect this should come with it.
<Kabouik>Iguess it's libstdc++-something
<Rutherther>rynn do you have it in your mimeapps.list?
<abcdw>Is it ok to update nss/fixed? It won't trigger massive rebuilds, right?
<rynn>Rutherther: Where would I find that? /usr/share/ doesn't seem to exist.
<Rutherther>~/.config/mimeapps.list
<rynn>Hmm, everything is pointing to something like `text/html=icecat.desktop;userapp-IceCat-TDPLS2.desktop;`
<rynn>All the image formats and everything else points to `org.gnome.eog.desktop`
<rynn>Oh, eog must be Eye of Gnome
<rynn>So eog for image formats, and icecat for the browser mimetypes.
<rynn>Not sure about tha TDPLS2 though
<mirai>fnat: I wouldn't bother with a resend, leave it for a v3
<mirai>I'll send you some feedback on it as well later
<fnat>Super, thanks mirai!
<dariqq>rynn: maybe you are missing one of the xdg packages (xdg-utils?)
<Rutherther>rynn I went through newboat code and apparently it takes default browser from env var Browser, or falls back to lynx
<rynn>lynx would be fine actually, let me install that and see if it will hand it off
<Rutherther>As for Lagrange, that one seems to use xgd-open, so there Xdg utils could help
<rynn>Rutherther: Thanks for that find, I'd rather handoff from Newsboat to lynx instead of Icecat anyways, so that works for me.
<rynn>Works beautifully, quitting out of lynx drops me right back to where I was in Newboat
<rynn>dariqq: I'll add xdg-utils and see if that fixes it, thanks
<xFFFC0000>If I have clang installed in my default profile, when I go inside `guix -D gcc` (for example), `clang` should be present there? or there is something wrong with my configuration? because even after `guix -D gcc` I have access to my guix installed clang executable in my PATH.
<Rutherther>Yes, it should. Use --pure to remove stuff from your previous path
<xFFFC0000>Rutherther: thanks
<Rutherther>xFFFC0000 also note that installing dev tools to your default profile means you might not get correct env vars when you use guix shell without the dev tool present inside of your shell _definition_.
<xFFFC0000>Rutherther: strangely, even with --pure clang is there. I `guix shell --pure --development monero glibc libbacktrace zlib` it is possible something is wrong with my config
<jpoiret>xFFFC0000: it is possible, do try to run `guix shell hello --pure --check
<jpoiret>you might have put things in .bashrc instead of .bash_profile
<xFFFC0000>jpoiret: it was because of .bashrc
<xFFFC0000>I had `GUIX_PROFILE="$HOME/.config/guix/current" . "$GUIX_PROFILE/etc/profile" ` there.
<nckx>Oof. That doesn't belong in any file.
<xFFFC0000>nckx: learned that the hard way :)
<xFFFC0000>apologies for many questions. Thanks all
<Rutherther>nckx why doesn't it belong in any file? Guix System has it in /etc/profile by default
<nckx>xFFFC0000: The (ba)sh file distinction is one of those things that seems academic until it bites your face off while you're sleeping.
<nckx>Rutherther: You are utterly right, I meant to write ‘~ file’ but my fingers skipped over it.
<jpoiret>yea, /etc/profile is good. nckx probably meant that it doesn't belong in any user-facing files
<nckx>Apologeses.
<jpoiret>although some other shells don't load system-wide conf files if there is a corresponding user file :)
<Rutherther>jpoiret nckx so what about foreign distros? do you think it's bad to put it to your ~/.profile in a foreign distro?
<jpoiret>nah, it's fine :)
<xFFFC0000>one other thing I am confused is what is difference between these two: `GUIX_PROFILE="$HOME/.guix-profile" . "$GUIX_PROFILE/etc/profile"` and `GUIX_PROFILE="$HOME/.config/guix/current" . "$GUIX_PROFILE/etc/profile"`
<jpoiret>as long as it's loaded on login and not on each new shell, and that it's done so only once, it should be good
<nckx>Rutherther: It's not ‘bad’, but I'm not sure in which case you'd have the access needed to set up the system-wide daemon but not have the permission/desire to make ‘guix pull’ just work system-wide, out of the box. But there are probably cases.
<jpoiret>xFFFC0000: there are 2 profiles on a basic guix install, the profile for your user-installed packages via `guix package` located in $HOME/.guix-profile, and the profile containing guix itself, managed via `guix pull` instead, at `$HOME/.config/guix/current`
<xFFFC0000>jpoiret: should I load both of them?
<Rutherther>xFFFC0000 yes, otherwise guix install or guix pull won't work properly for you
<xFFFC0000>( based on previous reply I assume `GUIX_PROFILE="$HOME/.config/guix/current" . "$GUIX_PROFILE/etc/profile" ` can be loaded inside `/etc/profile` )
<xFFFC0000>Rutherther: thanks. where is the proper place to load both of them. I assume `/etc/profile`
<jpoiret>xFFFC0000: if you want access to `guix` and to your user-installed packages, yes :)
<jpoiret>(that's to say, you do)
<Rutherther>also you should make sure to load .config/guix/current only after .guix-profile (and really, any other path that could contain guix executable file), to make sure guix is picked out of ~/.config/guix/current
<jpoiret>Rutherther: you should absolutely *not* have a `guix` binary in your ~/.guix-profile
<jpoiret>there's 0 reason to
<Rutherther>of course, but I think it's another safety mechanism if you accidentally did that and didn't realize
<Rutherther>xFFFC0000 here is /etc/profile from Guix System if you were interested https://termbin.com/uolh
<nckx>xFFFC0000: You can wrap them in an if [ -f … ] clause if you want to avoid harmless errors on clean installations (where Guix is not in ~ yet, and the user won't have a profile). Or if your system is actually multi-user in 2024.
<xFFFC0000>any easyway to fix this: https://paste.debian.net/1326907/ nothing important but a headache.
<xFFFC0000>Rutherther: great. I am going to give that profile a try. I needed something like that :)
<Rutherther>xFFFC0000 of course the full config is not going to work on other distros. Basically the for in there is what should interest you
<xFFFC0000>understandable.
<nckx>xFFFC0000: Start by finding out where lesspipe is being invoked.
<Rutherther>xFFFC0000 pure removes stuff from PATH, so you won't get stuff from /bin. I suppose your shell is using lesspipe in your rc file. So you have couple of options. You can remove lesspipe from your rc, supply lesspipe in the shell, or make sure rc file refers to full path of the binary
<nckx>(I find it a strange tool to invoke non-interactively and unconditionally, but who'm I to disagree with Debian.)
<Rutherther>oh, is lesspipe invoked in Debian inside of shell rc files by default?
<nckx>Hm, that's what I took from the question being asked at all, but no, I don't actually know.
<nckx>If you added lesspipe yourself, well, either don't, or wrap it in a test…
<Rutherther>but it wouldn't surprise me. I've seen the same error from someone else few days ago. So either it's coincidence, or it's default somewhere, so people use it without knowing about it
<xFFFC0000>I am looking at .bashrc and related files to locate `lesspipe` usage.
<nckx>What I think I'd do in your situation, if I wanted to keep my distro defaults pristine, is (1) export a bash function called ‘lesspipe’ that does something or nothing, depending on the importance, or (2) something hacky like create an otherwise empty directory with a ‘lesspipe’ in it that is either a symlink to ~/.guix-profile/bin/lesspipe or a no-op, and put that directory in $PATH.
<Rutherther>what I would do in their situation is switch to Guix System :D
<nckx>Touché.
<nckx>ACTION ‘Hey what's your IP address’, fires up guix deploy.
<nckx>‘Cuirass — Your friendly Guix continuous integration service.’ is this new?
<nckx>git: This is new.
<dariqq>Anyone familiar with cmake? What CMAKE_SYSTEM_NAME would the xtensa-ath9k-elf target map to?
<dariqq>I guess it is just 'Generic' from the configure flags that the atj9k firmware packages set
<jfred>Where can I find documentation on what %current-system and %current-target-system each represent? I'm trying to skip a particular test on a particular arch where it's flaky but I'm finding them hard to search for
<nckx>jfred: I don't think it is properly documented. %current-target-system is #f when not cross-compiling (the common case), or the target triple specified after the --target= build option. %current-system represents is always set to the actual current (host) system, i.e. your machine.
<nckx>For historical reasons it is NOT a triple, but a ‘Nix system’, which is almost the same but not quite.
<nckx>You might like guix build --list-{systems,targets}.
<nckx>Note how the i586 (Hurd) strings ruin any supposed simplicity.
<nckx>Add the forgotten () to my first message.
<Altadil>Hello, has anyone ever got a weird error from guild compile, claiming "no such option: -L", while said option does exist? Even weirder, I get it for only one file in the project, running the same command on the others still works fine…
<Altadil>Also, the auto-compilation when running the file with guile does not run into any issue. Nor the actual execution of its content.
<sepeth>Hi Guix, anyone seen this error when building plasma-nm: ld: /gnu/store/...-qcoro-qt6-0.10.0/lib/libQCoro6DBus.a(qcorodbuspendingcall.cpp.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZN23QDBusPendingCallWatcher8finishedEPS_@@Qt_6' which may bind externally can not be used when making a shared object; recompile with -fPIC
<sepeth>I don't know much about Qt but QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) looks like it is a Qt signal, and perhaps it gets loaded dynamically.
<sepeth>Last 100 lines https://paste.debian.net/1326926
<jfred>nckx: ah thanks, that gives me a good starting point
<jfred>nckx: so if you were to run `guix build --system=aarch64-linux` from an x86_64-linux system with binfmt-service-type enabled, and you were looking at %current-system in a gexp'd expression in the build arguments, would that be run within the QEMU emulation layer and therefore evaluate to amd64-linux?
<jfred>sorry, aarch64-linux
<jpoiret>jfred: yes, and %current-target-system would be #f
<jfred>jpoiret: thanks!