IRC channel logs
2024-02-01.log
back to list of logs
<rekado>in lieu of a fix I gave the googles-bot service the boot. <sarg>also archive search is missing last half a year <rekado>sarg: that’s another known bug that nobody has bothered fixing yet. The thing uses the wrong database file (which is updated continuously) <hackyhacker>f1refly: thanks the time sync was the issue with the SSL certificates! <rekado>maybe now that it’s FOSDEM time I’ll take a few minutes to fix these things. <rekado>apteryx: FYI it’s goggles-bot on bayfront. Until someone fixes it it’s easy enough to just restart it. <apteryx>it'd be nice to see this fixed, along automating the rsync job for mumi <rekado>if someone wants to fix it I can tell them exactly where the bug is <rekado>you’ll notice that the 1st is not in fact greater than the 31st. <rekado>no, because the 31st is greater than the 30th <rekado>either check also the month and year and millenium… or just compare timestamp prefixes <apteryx>what is the logic aiming to achive? find if we've started a new month? <rekado>so when a new day has begun we close the old file and start a new one <rekado>otherwise we append to the open file <sarg>replace (tm:mday time) with (+ (* 1000 (tm:year time)) (tm:yday)) <apteryx>wouldn't it be enough to use something like: (not (= day (tm:mday time))) ? <sarg>even just s/mday/yday/ would reduce the bug occurences to once per year :) <apteryx>assuming this runs often, it'll trigger when the day becomes something new (whether it's 31, 1 or whatever) <apteryx>I've never reconfigured bayfront, I don't think I have access but I'll confirm this <apteryx>yeah, I'm currently not an admin on that machine <apteryx>I can add myself to it, but I'll need someone else to reconfigure <apteryx>rekado: if you sync your guix-maintenance to master (commit 30226ae) and reconfigure that on bayfront, the bug should be fixed <apteryx>ACTION resumes painful debug on pkg-config ghost dependency cycle <dissoc>im trying to write a package with submodules. i use (recursive? #t) but the build fails and I dont see the library pulled in. looking at git.scm it looks like it runs git submodule update --init --recursive. which seems like it would work. am i missing something? <dissoc>if i use guix package -K, should i see the submodule in /tmp/guix-build-package/sources ? <dissoc>should i just have a src? and include as input and copy files? <apteryx>dissoc: it should work with recursive? #t <apteryx>we also have git-fetch/lfs, if they use that <apteryx>although this would typically be for large data, such as test data or game data perhaps <apteryx>so we can probably do without bash's timeout <dissoc>i got it. was my mistake. had (file-name (git-file ...)) that i forgot to remove when copying another package for template <apteryx>mcron currently will start multiple jobs in parallel, right? <freakingpenguin>Main annoyance is guix shell -D -- make won't result in the same site since the fonts will be missing, but that might be unsolvable? <apteryx>rekado: doesn't work: Rsync Debbugs data: Password: @ERROR: auth failed on module var-lib-debbugs <lilyp>alextee2: I wouldn't recommend pulling from gnome-team, but you can experiment with a local checkout from git <lilyp>it is an official branch that gets substitutes at a sligthly slower rate than master <lilyp>as for Wayland, I think this should already be supported on master, but you have to enable it in gdm <apteryx>rekado: any clue where the secret file is? <lilyp>(we should probably make the wayland flag default on gnome-team now that I think of it) <apteryx>with a --password-file as used by lechner (thanks!) <jackhill>hi guix, I have (service guix-publish-service-type <rekado>jackhill: does “ss -tunlp” indicate that there’s any service running at all? <jackhill>rekado: yep, I see "tcp LISTEN 0 128 127.0.0.1:9090 0.0.0.0:* users:(("shepherd",pid=1,fd=23))" <jpoiret>lilyp: please do, I've been meaning to for years now :) <lilyp>I'll add it to my imaginary TODO list right before (or after?) making pipewire the default :) <jpoiret>that's going to be harder to do though <jpoiret>ah, I guess that's needed to switch to wayland by default right ? <lispmacs[work]>hi, is somebody working on a gcc-toolchain package, or binutils, for ARM Cortex-R/M? Like binutils-arm-none-eabi in Debian? I'm not seeing anything in the guix repository <freakingpenguin>lispmacs[work]: They exist, but aren't directly visible as packages anymore. Look at gnu/packages/embedded, e.g. make-newlib-arm-none-eabi. <lilyp>we have some arm-none-eabi, but it might not be the one you're looking for <lilyp>jpoiret: I guess that's a no to both; it should be possible to just mod our alsa-service-type more or less <lispmacs[work]>freakingpenguin: are the installed as part of some other package? <lilyp>and no, it has no relation to making wayland default, it's just another api switch over in the gnome world <freakingpenguin>lispmacs[work]: I'm not sure how using them in a guix package works, but I'm pretty sure you can use them with e.g. guix shell by putting them in a manifest. <rekado>lispmacs[work]: the axoloti-patcher and axoloti-runtime packages use a cross-compiler for arm-none-eabi with nanolib. <ulfvonbelow>what's the "normal" way for a package that uses vulkan to be able to work? Add both mesa and vulkan-loader as inputs and add mesa's lib/ to the rpath? <jpoiret>lilyp: but pipewire is started through dbus as opposed to pulseaudio being started as a child of the first program that needs it. In gnome land where the dbus activation environment is overfed its going to work ok, but outside of that it'll probably be wonky <ulfvonbelow>for example, in a test, I see this: MESA: error: ZINK: failed to load libvulkan.so.1. Presumably that means that the program is attempting to use opengl via mesa, and mesa is attempting to do that using vulkan via the ZINK backend, but can't find it. Should vulkan-loader be an input to mesa? <jpoiret>ulfvonbelow: ah, interesting, are you seeing this behavior on master? <jpoiret>I have an issue with that on core-updates as well but I was talking to podiki about it and whether it was a more general issue after the latest mesa update <ulfvonbelow>uhhh, I'm seeing it on my local branch rebased on master as of *checks date* January 18 <ulfvonbelow>it looks like that error is coming from line 3146 of src/gallium/drivers/zink/zink_screen.c in mesa: screen->loader_lib = util_dl_open(VK_LIBNAME); <ulfvonbelow>seems like a pretty hard dependency on vulkan-loader to me <ulfvonbelow>now should it be done via substitute* of VK_LIBNAME's definition, or by adding the lib/ of vulkan-loader to rpath? <jpoiret>ulfvonbelow: does RPATH affect dlopen? <ulfvonbelow>I think so, IIRC dlopen uses the same path for searching as the dynamic linker does <jpoiret>mrh57: did you try the --no-user-init option as suggested? <ulfvonbelow>according to 'man dlopen', it searches DT_RPATH (if no DT_RUNPATH) --> LD_LIBRARY_PATH --> DT_RUNPATH --> /etc/ld.so.cache --> /lib --> /usr/lib <jpoiret>ah, right. Still, I think patching the dlopen call itself is better, the reference is clear <ulfvonbelow>I'm actually a bit curious why the tests for mesa itself failed to catch this <jpoiret>maybe LD_LIBRARY_PATH is properly set in that environment? 🤷 <ulfvonbelow>it would be quite surprising if LD_LIBRARY_PATH managed to conjure up a vulkan-loader where there is none, since it isn't an input to mesa <ieure>My LD_PONY: Dependency Management is Magic <jpoiret>ulfvonbelow: ah, right. Maybe they just don't test that? :) <podiki>Thanks for potentially figuring this out <podiki>You can probably bump mesa to the latest point release if you are changing the definition <podiki>Not v24 though, that just came out and if we want the NV driver we need rust.... <podiki>Yeah, unless people want to wait for next mesa-updates, which I plan as soon as a point release of 24 is out <podiki>On another channel someone has started on the NV driver, but I haven't tried personally <jpoiret>i'm also considering vivien's request to add the eudev upgrade… <jpoiret>feature-branches or not feature-branches, that is the question <podiki>We might want to check the mesa test log, it's possible or didn't check zink or some other fallback? <podiki>I'm fine with grouping eudev with mesa (similar rebuilds in number? Maybe some overlap), but that is not yet <jpoiret>also upgrading glibc to 2.39 is going okay after figuring out what to do with libcrypt it seems <podiki>I saw patches the other day to update libdrm and wayland-protocols, but that's all I have on my radar I think. Oh and vulkan probably <podiki>Nice. I was gonna vote for 2.39 too <jpoiret>i don't want to delay the eventual merge too much though <jpoiret>lots of patches that were added onto c-u later in the cycle because people requested them ended up causing more build failures down the line <jpoiret>since the patches were either a bit outdated or just untested on the reverse dep graph <podiki>A steady pace and more branches I think will help <jpoiret>i've seen people saying that we shouldn't be scared of rebuilding world more often, but one thing they don't necessarily realize is that you still need to test things locally before pushing, and that does take a long time <jpoiret>I bought a more powerful laptop mostly for that <jpoiret>i mean, I've stopped counting how many world rebuilds i've tested up to gnome in that c-u cycle <jpoiret>thankfully now I can do something else on my computer while it's building stuff in the background (32G of RAM helps quite a lot :) ) <mrh57>jpoiret: didn't make any difference <mrh57>jpoiret: using --no-userinit (a bit late)