IRC channel logs


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>OK, thanks
<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>right here:
<rekado>you’ll notice that the 1st is not in fact greater than the 31st.
<apteryx>so, flip the < to > ?
<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>every day gets its own file
<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>and I'll become admin for next time
<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?
<ieure>Oh god submodules.
<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>rekado: seems rsync has --timeout
<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?
<apteryx>rekado: do you think this would do?
<freakingpenguin>Hi all! I have a static site packaged in Guix, and instead of statically storing fonts in my repo I fetch them as Guix packages. I got it working but is there a cleaner solution than
<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>rekado: nevermind, found it
<apteryx>testing v2
<apteryx>with a --password-file as used by lechner (thanks!)
<apteryx>rekado: done for debbugs rsync job
<jackhill>hi guix, I have (service guix-publish-service-type
<jackhill> (guix-publish-configuration
<jackhill> (port 9090)
<jackhill>oops, lets try that again. Hi guix, I have in my operating system config, but `wget http://localhost:9090 times out. What's wrong with my publish service?
<rekado>jackhill: does “ss -tunlp” indicate that there’s any service running at all?
<jackhill>rekado: yep, I see "tcp LISTEN 0 128* 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
<lispmacs[work]>I wanted to build some Rpi Pico firmware
<lispmacs[work]>and make a guix package for it
<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.
<freakingpenguin>Might need to dig around the mailing list for the specifics.
<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
<lispmacs[work]>okay, I'll see what all is available in embedded module
<ulfvonbelow>for example, in a test, I see this: MESA: error: ZINK: failed to load 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
<jpoiret>yeah, that should be hard-wired
<jpoiret>thanks for the investigation
<ulfvonbelow>now should it be done via substitute* of VK_LIBNAME's definition, or by adding the lib/ of vulkan-loader to rpath?
<ulfvonbelow>how does one augment the rpath with meson, anyway?
<mrh57>has anyone seen this?
<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/ --> /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....
<jpoiret>you mean on core-updates, right?
<ulfvonbelow>> rust
<ulfvonbelow>"why is it always you?"
<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>It always grows
<podiki>A steady pace and more branches I think will help
<podiki>Going forward that is
<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)