IRC channel logs
2024-05-16.log
back to list of logs
<fnat>There's this thunderbolt docking station that I've been trying to get working today. External monitors work fine, i.e. monitors connected to the station are seen and can be used by the connected laptop. <fnat>However, usb devices don't seem to be detected. <fnat>No traces in /var/log/messages when connecting/disconnecting a usb device to the station. <fnat>(Thunderbolt 3, I should have mentioned.) <PotentialUser54>So I'm getting this package ready for submission and guix style is telling me "the source file name should contain the package name". I'm not exactly sure what that means <PotentialUser54>As best I can tell it's upset about something in the source s-expression, but I'm not sure where the file name would be specified. I'm just doing a git-fetch <ieure>PotentialUser54, Perhaps you're missing (file-name (git-file-name name version)) ? <ulfvonbelow>it seems that the existence of a GDK_PIXBUF_MODULE_FILE other than gdk-pixbuf's own built-in one in a build environment makes gdk-pixbuf unable to find its own loaders <ulfvonbelow>example: a package uses both svgs and gifs in its tests, and librsvg's loaders.cache shadows gdk-pixbuf's <fnat>Anyone who's been using boltctl (package 'bolt') successfully on their system? If I launch any variation of boltctl I seem to be getting this error: "The name org.freedesktop.bolt was not provided by any .service files". <Kolev>Can Guix System run Jellyfin and Nextcloud? <freakingpenguin>Kolev: Perhaps with oci-container-service-type. Jellyfin I know is programmed in C# and I believe Mono/DotNet was removed because it can't be built from source, so I doubt it'll be supported officially. <Kolev>Should I use a different media server? ☹️ <freakingpenguin>I don't know if there's another way to run it on Guix without oci-container-service-type. <singpolyma>How do you mean mono "can't be built from source"? <KE0VVT>It's a shame the best free software media server is written in wretched C#. <KE0VVT>Is it worse than Chromium, freakingpenguin? <wakyct>crikey, has anyone read the Ebury story on Ars Technica? <freakingpenguin>I should have said "can be built fully from source without bootstrap binaries". The Guix Blog has posts on that. <KE0VVT>Is using containers on Guix System more or less work than on other distros? <singpolyma>Well *nothing* can be built without bootstrap binaries 🙂 <KE0VVT>I'm thinking of running my home lab server on Guix System so I can easily manage state. Keep all the configs in version control and all the state on an external disk. <singpolyma>I'm aware guix has got a subset of packages building from a very small bootstrap, but obviously a bootstrap will always be needed. Even if you count assembly as source you'll need an assembler <freakingpenguin>True! In this case the bootstrap is pure machine code, and I believe it's down to 357 bytes on x86_64 (my goodness!) Small enough that it's auditable, sans needing a kernel. <lykso>That said, what's the right way to inherit from a package and append a value to one of its properties? I want to add a make flag to the linux kernel package's arguments without clobbering what might already be set. <lykso>Wow, sorry. Wifi silently failed and only that last message got actually sent. <apteryx>Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (call-with-temporary-output-file (guix utils)) #f)' <lykso>Re-sending: A few days ago I came in asking for help regarding making references to origin output paths, with the aim of recursively applying patches from a subdirectory of a git repository. "apply-mnt-patches" in this file represents the solution I arrived at: https://paste.debian.net/1317101/ Sharing for the benefit of anyone who might be combing through the logs with a similar question in the future. <apteryx>OK, it's a regression from 54be7795b5cc2f6cad05f8649121372c9d5af806 <apteryx>lykso: why not use the 'patches' field of an <origin> record? <lykso>That's what I started out trying to do, but it didn't look like there was a way to use a g-exp there <apteryx>I think file-like objects should be fine for patches <apteryx>but that's not recommended; it's preferable to add patches to git to avoid them vanishing from wherever they were taken from <lykso>Yeah, I'd seen that was the pattern y'all were following, and I figured that was why you were doing it that way, but I wanted to maintain clarity regarding the source and provenance of those patches. <lykso>Right now I'm just trying to pass "V=1" to make so I can see what's actually getting run. I see #make-flags is the way to do that, but just setting that results in an error about "configure" not being found, so I imagined I was clobbering make flags from the package I'm inheriting <lykso>I figure I want to use "substitute-keyword-arguments" with "package-arguments" but I'm not really sure how I'd get the value of "#:make-flags" from the original arguments in order to then add on to them <apteryx>something like (arguments (substitute-keyword-arguments (package-arguments base) ((#:make-flags old-flags ''()) (cons "V=1" old-flags)))) <apteryx>old-flags is more conventionally named just 'make-flags' <freakingpenguin>lykso: The kernel specifically has customize-linux in (gnu packages linux). I don't think you can add make flags but you can add config options. <ulfvonbelow>I think that's going to produce a complaint on the builder side about there "V=1" not being a procedure <apteryx>so more like (arguments (substitute-keyword-arguments (package-arguments base) ((#:make-flags old-flags ''()) #~(cons "V=1" #$old-flags)))) <lykso>apteryx: Thanks! Trying that now. <lykso>freakingpenguin: AFAICT, customize-linux returns a package that can then be inherited from, right? That's what I'm doing here. <lykso>apteryx: No error this time! Much obliged. :) <KE0VVT>Vorta isn't able to connect to my repo over SSH. It insists on Borg protocol. <miaomiao>I am seeing this error when I try to install it: "guix package: error: cannot install non-package object: #<unspecified>" <freakingpenguin>miaomiao: Are you trying to build/install via -f <file>? If so you need to add a line containing sc-controller to the end of your script. <apteryx>cbaines: could reproduce it on my side too... interesting <miaomiao>freakingpenguin: i'm doing -f. does it just need a line with the name at the end? <miaomiao>or is there some particular syntax to it? <freakingpenguin>Yep. build -f <file> tries building the package returned at the end of <file>, so you need to return your package. <apteryx>cbaines: ah, same-ver nss-certs are the same object <miaomiao>that seems to have done the trick, but now another head appears: "error: python-vdf: unbound variable" <miaomiao>but i know that exists, i'm looking at gnu/packages/python-xyz.scm right now <apteryx>I'd like 'delete' at most one object X <freakingpenguin>miaomiao: That's probably just from running an older Guix. Looks like python-vdf was just added a few days ago. <miaomiao>oh! you know that makes complete sense, it's been a while since i've done a pull. <miaomiao>pretty serendipitous for me to be working on this now haha <apteryx>deduplicating the list before what I was doing would probably eliminate that <miaomiao>and actually looking at it now someone may have beaten me to the punch with a patch including a much better-looking sc-controller script. this was opened several years ago, though...admittedly i have a hard time following the formatting, so maybe this has a more recent update? https://issues.guix.gnu.org/58403 <miaomiao>that patch i linked for sc-controller seems to work just fine for me, so that's very convenient and saves me a little hassle. I wonder why that hasn't been brought upstream yet? regardless thank you for the help freakingpenguin. I learnt a thing! <freakingpenguin>You're welcome! No clue why it wasn't merged, probably just flew under the radar. <KE0VVT>efraim, I've settled on Debian + Guix for this Chromebook. It's mainly for house guests to use, anyhow. <lilyp>Would it be possible to configure savannah to allow force-pushes on some branches? Manually deleting and re-pushing seems kinda archaic. <picnoir>I have a small-ish issue when playing with services. After working on a service, running make several times, I'm trying to run a system test suite, I end up with a ABI mismatch. It happened several times already. My current workaround is to nuke the compiled files cache (through make clean). I'm wondering if there's a more fine-grained workaround to go around this cache issue. <cbaines>lilyp, how are gnome-team things going? I spotted that the testing of #70936 is progressing <bost>Hi. `sudo guix system reconfigure ...` throws me 'guix system: error: aborting reconfiguration because commit 4c94b9e983bc51d9504655f1e7727c4f6d14b6b7 of channel 'guix' is not a descendant of c81ed0970007810a4662edbc3474f5afc656fe95'. However both seem to be valid commit in my checkout dir: <bost>git show --no-patch --oneline 4c94b9e983bc51d9504655f1e7727c4f6d14b6b7 c81ed0970007810a4662edbc3474f5afc656fe95 <bost>4c94b9e983b news: Update commit for fixed-output derivation vulnerability. <bost>c81ed097000 gnu: nar-herder: Update to 0-29.fb764aa. <bost>Do you know what's going on? <cbaines>bost, this is the downgrade protection, are you trying to reconfigure with an older revision of guix <bost>cbaines: yes I know that it's a protection :) That's why I'm asking. ;-) `guix system describe` shows me 'Apr 27 2024 04:02:51 (current)' with guix-channel commit being the c81ed0970007810a4662edbc3474f5afc656fe95 <bost>cbaines: IOW I reconfigured my system 3 weeks ago. That's not *that* long ago, I'd say. <cbaines>bost, could it be that you've used sudo -E rather than just sudo for reconfiguring in the past? <cbaines>I think without the -E, you might be using root's guix, rather than your users <bost>cbaines: IOW I had to play with the environment variables to get the `guix pull` running. <lilyp>cbaines: I've pushed them with the comments, but I'm not sure if that's all that was needed. CI will tell <bost>cbaines: Aaaaah the `sudo -E # --preserve-env` was a good hint. The `sudo -E guix system reconfigure ... ` is the solution after 'guix pull: error: Git error: the SSL certificate is invalid'. Thanx Chris! <quaaa>I have erlang installed through guix-home, and I'm trying to include `erl_nif.h` on a C program. I can see the file is present under `$HOME/.guix-home/profile/lib/erlang/usr/include/erl_nif.h`, but that doesn't seem to be present on my include path. Aside from manually adding it, which seems like a brittle solution, is there any way to make libraries installed through guix-home show up on the include path? Am I misunderstanding <jpoiret>quaaa: it's possible that the guix package doesn't install the header to the expected place <jpoiret>usually ~/.guix-profile/include/ would work <jpoiret>or ~/.guix-home/profile/include/ if you're using guix home <quaaa>It doesn't seem to be there. There are many other libraries there though, could it be a packaging bug? <quaaa>Ah sorry, ~/.guix-home/include doesn't exist in my system <quaaa>I was checking ~/.guix-profile/include <jpoiret>the profile you're using is under ~/.guix-home/profile/ <jpoiret>usually, if you see /usr in a path it's usually indicative of a packaging error <jpoiret>on guix we don't ever use /usr except for /usr/bin/env <quaaa>Okay, ~/.guix-home/profile/include does exist and contains libraries, but not the erlang ones <quaaa>I should probably report it as a bug then, right? <jpoiret>probably, yes. maybe look into how erlang ends up being installed on other distros/where it suggests its headers should end up <quaaa>On the erlang documentation it looks like they expect it should be placed somewhere directly available from the include path, but it seems to be a source of trouble in other distros as well. Apparently it tends to end up on `/usr/lib/erlang/usr/include/erl_nif.h` <jpoiret>aha! maybe upstream's `make install` target (or whatever else they use) uses the wrong destination for it then <jpoiret>we're starting to get substitutes for yesterday's core-updates push which includes the glibc 2.39 update <jpoiret>that's a good sign! I still have some ungrafts to push and we should be good to go <civodul>from the strace of ‘guile -c '(pk (getpw (getuid)))'’, it seems that nscd is contacted for the passwd entry, but then the code falls back to reading /etc/nsswitch.conf, then /etc/passwd <civodul>oh, got it: we have (implicitly) “enable-cache passwd no” in our nscd.conf <not_you>Hi, new to guix. can anyone explain to me how to get arm embedded(coretex-m) bare metal toolchain going? <not_you>like arm-none-eabi i think. just wanna be able to compile for rp2040 atm.(have picosdk) <jpoiret>not_you: you should be able to use make-arm-none-eabi-toolchain-* in (gnu packages embedded) <not_you>what options are there for the star? or am i supposed to just use the star in my system.scm to get all the nessecary utils? <jpoiret>no, you'd need to look at the source to see all the available toolchains <jpoiret>civodul: apparently our NSS build is not optimized, should we deem that a problem? <civodul>jpoiret: you mean the package called ‘nss’, right? <not_you>sry if this is a stupid question but where do i find the options then? just specifically added (gnu packages embedded) to my system.scm and can't find anything eihter through guix search or on the web. <not_you>do i need to set up the whole development thing for guix just so i can find all the options in the repo guile scheme? <civodul>not_you: there’s ‘guix build --list-systems’ and ‘guix build --list-targets’ (the latter is for cross-compilation) <not_you>ok i just ran 'grep -rnw -e' over the guix guile repo and fund something defined as make-arm-none-eabi-toolchain. hope i'm not bothering u but how does that fit into my configuration? can't just add it as a package. <civodul>that’s a cross-compilation toolchain <jpoiret>civodul: no, rather, there's a build variable "BUILD_OPT=1" to get an optimized build apparently <jpoiret>not_you: it's a procedure that returns a package, you need to call it like (make-arm-none-eabi-toolchain) <civodul>jpoiret: ok; worth discussing in particular with Christina, who’s looked into nss quite thoroughly it seems <not_you>civodul: pretty sure it is. i wanna build on my x86-64 for my rp2040. so that's compiling on one platform for another so p sure that's cross compiling or am i being increadibly silly and not realizing it? <civodul>not_you: that’s definitely cross-compilation <civodul>normally you’d do ‘guix build whatever --target=arm-none-eabi’ <civodul>but for some reason, this particular triplet doesn’t show up in ‘guix build --list-targets’ <dariqq>how does file-append work with packages with multiple outputs? Is there a way to specify the output to append to? <not_you> ‘guix build whatever --target=arm-none-eabi’ is this what the way u instaill the toolchain or the way u bild a .c file? if the latter wouldn't that mean i have to chagne all makefiles i wanna use on arm embedded to reflect that? <dariqq>background: d0ad4f557fc8b9d105877f2ef4de0ce12c5c9566 still seems to download the doc output <dariqq>the doc output can be gced afterwards but will be redownloaded on rebuilding the system <civodul>dariqq: it’s a limitation of ‘file-append’: it doesn’t let you specify the output you want <civodul>i think i came up with a trick once for that <not_you>guix build rly seams like way more for building for architectures with operating systems. u can't just build a linux package for cortex m0. if this is actually the way ur supposed to build ur embedded firmware i think guix just isn't for bare metal embedded dev. <picnoir>civodul: sorry, I was away. I'm packaging Nsncd fyi. The package is done, the service bricks the boot for now. ETA hopefully tonight :) <dariqq>in this case the doc output is quite small (i think 200 kb or so) so its not really a big issue. One of the reasons i moved it to another output was to not needing it when runnig the daemon so was a bit surprised when it got downlaoded. I guerss the fact that it is gcable is a slight remedy <not_you>ok weird there's the gcc-cross-avr-toolchain package, but seemingly nothing like that for arm. btw where do i find help-guix? don't wanna be holding this up if it's rly abt something else. on this server it's either non existant or at least empty. <jpoiret>not_you: some people do use Guix for bare metal embedded, as the (gnu packages embedded) module contains quite a lot of related work, but there aren't that many <jpoiret>you might find more help on help-guix, yeah <not_you>tried /join #help-guix and it's an empty channel with not even a welcome message set so it feels like it doesn't exist. <not_you>just tend to find mailing lists incompatible with my ADHD attention span. <zamfofex>Hey, Guix! i586-gnu substitutes when? 😄 (I don’t want to sound demanding, so please do consider this to be just me showing interest!) <ieure>zamfofex, As I understand it, there are some difficult issues around this, because many modern software builds require more RAM than a 32-bit machine can address. :/ <ieure>I'm not sure which have that issue. <zamfofex>Note that the Hurd now supports x86‐64, I wonder if it’d be a big hassle to bring that to Guix too. <zamfofex>Last time I worked on something regarding Guix (and/or the Hurd), most of my issue was just having to wait for packages to build. I would like to work on trying to bring x86‐64 support for the Hurd to Guix, but I’m already afraid of having to wait days upon days for packages to build, and then having to fix something that invalidates all of my waiting. <jpoiret>zamfofex: we had already started trying to make the hurd packages more generic, by removing hard-coded mentions of i586 <jpoiret>maybe it's just a matter of adding a new platform? <daviwil>phew, struggling to get OBS 30.1.2 working. I've got it building, but after upgrading the package to use QT6, it can no longer initialize EGL correctly <cbaines>zamfofex, substitute availability is low (at 3.9%), but there are at least some substitutes <zamfofex>Well, I guess it’s time for me to sink my time into this, then! 😅 <KE0VVT>Vorta cannot access my Borg repo over plain SSH. <jpoiret>zamfofex: you might want to wait until the glibc 2.39 upgrade, since it's going to include many things you'll need <civodul>wo0t! thanks for the pleasant conversation, futurile and those who joined :-) <PotentialUser12>I'm creating a shell like so "guix time-machine -C channels.scm -- shell -m manifest.scm --container" and am interested in using "guix copy" to copy all of the substitutes used in that shell to my own private substitute server. Is there a way to accomplish this? I know the output of "guix build" can be captured relatively easily with xargs, but I'd <PotentialUser12>like to avoid doing builds for every package I use since, ideally, they will either be available as a substitute publicly or privately from my own server. <PotentialUser12>futurile: That is what I'm trying to accomplish. I have a local substitute server stood up and I can pull from it just fine when creating a shell. The issue is when something doesn't exist on my local server I either need to pull from the public server or build it. Once that is finished I want to copy it to my local server so I don't have to worry <PotentialUser12>To give additional context: I am pulling from my local server in CI pipelines and will in the future have additional users running CI pipelines as well. I don't want to give all of them SSH access to the substitute server to run guix build commands. I'd much prefer to have their CI pipelines just copy back anything the server didn't already have. <craigbro>futurile: thanks for sharing the meeting link