IRC channel logs
2026-02-08.log
back to list of logs
<Tadhgmister>k got it. `guix shell --container --writable-root` with `rm /bin/sh` reproduces the error <ieure>Anyone have a recommendation for packaging a Python project that has no setup.or or pyproject.yaml? <ieure>I guess just like uhhhhh create one and patch it into the source? <ieure>It has requirements.txt, but no package definition, no PyPI entry. Upstream suggests you run it straight out of the repo. <Wurt>ieure, in my private repository, I usually review Arch Linux PKGBUILDs. In this case, they only handle file installation (perhaps copy-build-system could work.) <Wurt>How can I automatically detect redundant inputs in a package? I’ve submitted multiple pull requests with that mistake... <the_tubular>Why doesn't guix pull && guix system reconfigure && uname -a doesn't lead to a new kernel version ? <ieure>Wurt, I thought of copy-build-system, but python-build-system byte-compiles everything, and that wouldn't. <Wurt>ieure, in that case, your idea seems like the best approach. Perhaps you could ask the author to include that file in future releases. <ieure>Wurt, They've been asked before and declined. :( <Wurt>ieure, sometimes, people choose violence... <ieure>the_tubular, Agree with yarl, you have to reboot to load the new kernel, I don't think you can hot upgrade a kernel version in a running system. <nephele>Hi there, I'm looking for some information, I've looked at the guix website but didn't really figure out if guix would fit my usecase. Anyhow: I would like to have a re-producible mail server config based on alpine linux, having alpine install "the right packages" with commands would be straightforward, but managing config files (so I as a user only have to set the *really* relevant stuff) is not that easy. How does guix configuration <nephele> management work? can it provision configuration files for me, can I have one "big" config file with config for severall server applications that it can then provide? <ieure>nephele, The Guix analogue there would be a system service for your mail server. You configure it in Scheme, in the same file as all the other stuff about the system, and it will serialize that to the software's native configuration. <ieure>nephele, See the "Using the Configuration System" section of the Guix manual, and "Mail Services" for the mail-related services supported. <nephele>Can I write code to support mail services that aren't supported? I would like to read the handbook, is there an accesible version available? I only found light-mode html or pdf variants, but I would need a dark variant <ieure>nephele, You can, I will caution you that this will be difficult for a newcomer to Guix. <ieure>nephele, I am not aware of a dark mode manual, probably there's a browser extension which will do that. Or you can read the local info manual in Emacs or the terminal, either of which are readily themeable. <nephele>Browser extensions break websites that already have a dark mode, sadly. Where can i obtain the info pages? it seems my Haiku already has info installed <nephele>as for it beeing difficult, I would expect that. my end goal is to have a more "user friendly" way to administrate a mail server, with friendly defaults and only having to configure the bare minimum you'd actually need. I don't know if guix is the right tool, but if it is i will probably have to manage to support software that is required in the setup if it isn't supported yet :) <ieure>nephele, The info pages come with the Guix package. <ieure>If your distro has a Guix package, install it, and you'll get the manual as well. <nephele>I don't have a distro, I can't install a guix package <ieure>nephele, I think any decent dark-mode browser extension would have some sort of site allow/denylist. And extension can always be disabled, so you can turn it on to read the Guix manual and turn it off after. If you can only read comfortably in dark mode, surely this isn't the first time this has come up? <nephele>maybe I can obtain the package from a linux distribution and extract it and read the doc that waa <ieure>nephele, I am the opposite, dark mode is physically painful for me to read, I use the browser reader mode to work around it, or a user style applied with Firemonkey. Before that, I had a bookmarklet that forced everything to black-on-white. <nephele>No, it isn't. But I can sometimes read in light mode. I haven't gotten around to adding a forced colors mode to Haikus webrowser sadly <nephele>Are there sites that force a dark mode for you? with modern web standards that normally should respect the user preferences <ieure>nephele, Yes, many sites are dark mode only, also I'm not using a setup with dark/light mode switch at all. Example is any <ieure>... any Mastodon server, when logged out, is dark mode. <nephele>That's interesting. I had assumed those were just respecting my UA, I know of severall mastodon servers that are light only aswell. <nephele>For "modern" browsers the prefers-color-scheme querry should for you, hopefully, evaluate to light and the website should then know what color scheme to serve to you :/ <pomel0>how do I test a shepherd daemon service I have written, before I add it to my system configuration? <ieure>pomel0, In a VM, with `guix system image'. You can also test a good amount of things (the configuration / serializing) in the REPL. <pomel0>ieure: thanks, I'd like trying the REPL. I'm loading my service.scm file, but it says "no code for module (gnu gexp)" and exists, what module am I missing to use (gnu gexp)? <clone>pomel0: I think you mean (guix gexp) <pomel0>clone: yes... I just realized, sorry <nixpup>Hey everyone, I have a question/need some help real quick. I tried adding the "(service home-pipewire-service-type)" to my Guix Home configuration (home.scm), but upon build, guix tells me this module does not exist, even though it's referenced in the Guix Manual. How do I set up pipewire on Guix, either through Guix Home or in my system configuration? <clone>nixpup: did you import the (gnu home services sound) module? <nixpup>clone: I didn't! I'll try that as soon as the current `guix home container` build is done, thanks! <lilyp>quick info: rust failing to build on x86-32 currently kills wine – if someone manages to get more info on that, please raise an issue on the repo <mange>Has there been any discussion anywhere about language versions used to build things, compared to packaged language versions? I think it's dumb that `guix shell ruby ruby-nokogiri -- ruby -e 'require "nokogiri"'` doesn't work, but adding @3.3 to ruby makes it work. <efraim>janneke: gdb-minimal in the manifest for the hurd or in the devel-hurd gnu system example, does it matter what version it is? I'm updating gdb on the rust-team branch <Rutherther>lilyp: not sure I understand, rust has ever been building on i686? even the supported-systems in rust package seem to suggest not. Or did wine start depending on rust recently? <dariqq>but this is currently on the new python-team branch. If one can figure out how to do this without changing the x86_64 derivation that would be great <jlicht>Does anyone have an example of the AGit workflow that respects (automatically or manually) our PR templates? I use Emacs btw ;) <Rutherther>efraim: yeah but that gives that rust is introduced through mesa. And mesa doesn't depend on rust on i686. Well I cannot really say what happens with the inputs when #:system argument of a package is set to i686-linux, but seems that at least the graph does not really respect it <dariqq>guix graph --path wine rust -s i686-linux <Rutherther>lilyp: are you building wine with -s i686-linux? that has been required for as far as I can remember <dariqq>Rutherther: Are you up to date. I have one via samba , dnspython, trio and then python-cryptography <Rutherther>dariqq: oh sorry I have ran this with old guix and haven't realized <efraim>it looks like python-dnspython depends on python-trio unconditionally <jlicht>can confirm what dariqq says on b7510ecaf19ffed2ab78dadb2446afb33f213461 <dariqq>hence my pr above as cryptography seems to be only needed for tests in trio <Rutherther>dariqq: okay I see it now with the guix I pulled for this, but forgot to use <efraim>I'll play with dnspython to mess with the propagated-inputs <janneke> efraim: as long as it builds, later is better :) <dariqq>efraim: trio already depends on cryptography via propgation and the other checks for this are precisely to avoid this. But now it also explicitly depends on it <janneke>i believe we needed gdb-15 to support the 64-bit hurd <janneke>(a newer version than the "standard" gdb, in any case, at the time) <efraim>janneke: I figured as much. I'm blanket moving gdb and gdb/pinned to gdb-17 on rust-team. gdb/pinned is currently at 12 <efraim>dariqq: check git-blame for those lines :) <dariqq>efraim: 19e7200286989a7afc90adecb415cf09093cc4dd A yearly tradition? <efraim>ugh, thanks for reminding me. I was going to wrap everything in python-dnspython, but I'm supposed to check why python-trio suddenly really wants python-cryptology <efraim>Hopefully one of these days we'll get rust building on i686 <futurile>Q: under what circumstances should we create a /fixed package (or a -next)? I could do with a later version of Boost for OBS, but it's like thousands of packages <futurile>Our version is really of date, but presumably we don't move it much because of the thousands of packages thing <dariqq>efraim: cryptography got added explicitly as an input. In my pr i made it optional but it also changes the x86_64-linx package because it reorders the inputs <efraim>futurile: generally if it's a package that causes many rebuilds, but we would want to install in a profile <efraim>and some measure of not wanting to wait <efraim>I'm test building samba on i686, then I'll push the change. do we have a bug report for wine requiring rust? <Rutherther>I don't think so, lilyp asked someone to create it after more info is known <efraim>ok, wine should be buildable now <efraim>next looks like python-sphinx on ppc64le <yelninei>janneke: guix build guix -s i586-gnu now almost works except when guile OOMs. Then there also issues with the guix tests because they are not sandboxed (buildusers being able to access /var/guix/daemon-socket/socket and the network so we get all the expensive tests with even more build requirements) <jlicht>efraim: samba build for me with --system=i686-linux, thanks! <jlicht>is it possible the python-team branch that was merged (recently~ish?) broke ungoogled-chromium? I'm trying to bisect here, but ETA is still a couple of days away at this pace :D <jlicht>(could be something else entirely of course, in which case a Mea Culpa on my end for assuming things) <untrusem>how much does go build system differs from new rust build system I have only experience with the later <untrusem>I have just used `guix import go` for one package <yelninei>janneke: yes currently answering. I am a bit proud to get the shepherd syslogd/klogd working which took a while to figure out <janneke>yelninei: feel free to clone, add your name, and add your work! <janneke>yelninei: and if you feel it's too early for this post, we can postpone <acid-bong>just did `guix pull` just after 3 or 4 days and it's exhausting my CPU (90-96 degrees). did something change since wednesday? <Rutherther>acid-bong: I wouldn't say so. What step of it is exhausting for your CPU? <galois`>Hi, where does the book-sicp package exist? <galois`>Thanks. How do I get a local copy of it? <yelninei>janneke: The main issue on x86_64 is the one with signals/shell replacements that does not quite work yet and causes test failures. I am completly unsure how/why this works on debian <acid-bong>also findable with `guix search` or, for shorter, `guix package -A` <galois`>acid-bong: Well I don't find it with guix search, that's why I asked :D <acid-bong>Rutherther: the compilation took longer than usual and heated up my laptop like crazy <acid-bong>galois`: maybe it was added super recently (i updated a couple of minutes ago) <galois`>guix show: error: book-sicp: package not found <Rutherther>acid-bong: guix pull can compile a lot of stuff depending on what doesn't have substitutes etc. <galois`>guix pull fails atm. I'm still very new to Guix, so this is probably very related to some wrong setting <Rutherther>acid-bong: guix depends on gcc toolchain, guile, thus glibc, ... and so on. That is why I am asking what actually was the step, ie. what was logged at the time you were experiencing the exhaust of your CPU <Rutherther>galois`: what does it fail with? what architecture are you on and what is the current guix you're using (guix describe)? <acid-bong>Rutherther: the entire span of building guix-cli, guix-system and other components of guix <Rutherther>acid-bong: okay, those are just guile scm -> go compilations. I expect then that on Wednesday you just hit a commit that has already been built by CI, whereas now you've hit one that wasn't <Rutherther>acid-bong: those do not depend on any refactors, they are compiled every time new guix commit is made. The same set of files have to be compiled over and over with every new commit <galois`>Rutherther: Should I share this info with pastebin? <Rutherther>galois`: yes please, ideally the whole log of guix pull <attila_lendvai>what is the current state/solution of gcc-toolchain not creating a cc in bin/? this project just wants a cc in the PATH, and i'd prefer not to modify the build to accommodate guix. <Rutherther>attila_lendvai: most packages accept CC environment variable or make flag. Does this one not? <attila_lendvai>Rutherther, seems like CC is not set either. if i `export CC=gcc` then it works, but it's a complex build script for some common-lisp project that somewhere deep down also invokes cc... <attila_lendvai>my dream is a guix.scm, a guix shell, and it all should work out of the box, without adjusting upstream <Rutherther>attila_lendvai: then just make a package that creates the bin/cc file as a symlink and provide that. I don't really think there is anything else you can do <Rutherther>galois`: or maybe in this case you also have to set GIT_SSL_CAINFO as this is a git operation <galois`>Rutherther: No I have not. I pasted all the exports and the install of nss-certs in my terminal but now I get: Git error: unexpected http status code: 404 <dariqq>Rutherther: https://ci.guix.gnu.org/build/17424329/details is because the builder ran out of disk space. But guix pull regularly does not work (on the first try) because of memory exhaustion. Retrying it seems to be able to reuse some things from the previous run and it is less of a problem. <acid-bong>galois`: that's an example url that's obviously non-existent <galois`>acid-bong: True. But why is this set? <acid-bong>because you blindly followed the manual at some point? <galois`>Yeah, it's defined there. What do I do? Delete the file entirely? <Rutherther>dariqq: right, I haven't checked the log of the first one, I checked logs of two other ones and then just thought all are going to be the same - (ram) memory exhaustion <galois`>Ok, thanks for the help Rutherther and acid-bong <dariqq>Rutherther: I have an issue open for that in https://issues.guix.gnu.org/74381 , when I reported that last year janneke mentioned that guix-packages-base already has a smaller chunk size, i have not tried if reducing it even further could help <acid-bong>btw, does Guix have a Nixpkgs-like concept of a development branch that's ahead (Nixpkgs' master and staging) and a slower user-targeted branch that's slightly behind the former (nixpkgs-unstable, nixos-unstable and such)? <Rutherther>dariqq: what I wanted to say is that I do not think CI has been failing previously on i686, or was it? So sometihng must have changed, there are now a lot of failures. Be it at CI side or at Guix side. Maybe it's all due to the lack of disk space and there is ie. a swap that fills the little space there is left and it fails with memory exhaustion? Not sure if that's plausible, though. <Rutherther>acid-bong: no, Guix does not have that concept. When developers decide something fine to push to users, they do push to master directly and that is used by users <acid-bong>but that way CI might not make it :thinking: <Rutherther>acid-bong: that's why bigger changes are pushed to team branch and built in advance <Rutherther>dariqq: okay if I go further in history there are still some failures on CI, but they're much less frequent since that one from 26th of Jan <Rutherther>dariqq: most pages are all green and then sporadically there are some where a failure is. But now there are multiple failures per page <cbaines>I too noticed that it was working better than before, maybe the rust packaging changes reduced the resource requirements <Rutherther>cbaines: i you mean what dariqq and me are discussing, yes, builds of (guix self) on i686 <dariqq>Rutherther: From experience it seems to be very non deterministic/ dependant on what/how much has changed <Rutherther>cbaines: I think now (very recent) it works much worse than before <Rutherther>dariqq: the builds are isolated so I do not think it could depend on how much changed <dariqq>jan 25 has all the things from next master so something from there maybe? <Rutherther>dariqq: definitely could be. It seems to me something must've started consistently allocating more memory during the process, leading to the failures <cbaines>any ideas why tests/publish.scm is has failing tests? <cbaines>error: <path-info>: unbound variable <galois`>So book-scpi still doesn't show up in my search results, even after a fresh guix pull. Why? <cbaines>would book-sicp work for you instead galois` ? <Rutherther>galois`: did you not get a hint about sourcing the guix profile at the end of guix pull? Either execute what the hint tells you or relog <futurile>oh that was very close, I was hopping around my room, went to sit down on my office chair but kinda didn't get the crutches->chair bit right - so landed up half of the chair shooting backwards across the room - 'shooting' might be too strong but it was very funny <untrusem>nice I can comment on few things, but you were very good for a beginner, maybe nix experience somewhat helps <nemin>Please do, I'm happy to learn. And thanks for taking a look! <untrusem>should I comment on your lobsters post or just here? <nemin>I suppose Lobsters might have more reach, so it might help others too. <yelninei>is it possible that gcc not work with --disable-bootstrap? <untrusem>you can use `guix shell -m manifest.scm --pure` next time, manifest.scm is the guix repo <nemin>Thank you. I've been eyeing Guix for quite a few years, but KDE not being stabilized kept me away. It feels nice to finally start using it seriously. <untrusem>so we got a new member thanks to kde-team 🙂 <untrusem>because templates helps a bunch with commits and boilerplate for package definations <nemin>Emacs, mostly. At work I'm forced to stick with VSCode. <nemin>I couldn't get yasnippet to work properly, despite loading the snippet in the manual... <futurile>ah I finally I understand how people deal with the format - as a Vim user I just have to cut-n-paste from a text file I have <untrusem>but it have shifted to using a single file for templates, actually I need to raise a issue about this <nemin>I have no experience with tempel myself. Maybe it works better than YAS for this project? <nemin>Ah, seems we're at an impasse then :) <nemin>untrusem: I just mean that you have no yas experience, I have no tempel experience, thus we cannot be certain why it doesn't work on my end. I'll just have to try tempel then for my next project. <Guest21>I created a custom package for the Pragmata Pro font, I included it in my guix home config. Now if I create an image and spin up a vm, describe-char from Emacs says it uses Pragmata Pro, but it looks really ugly. It is not sharp. Anyone know why it is like that and how to fix it? <makx>omg a guix image for the visionfive ... gotta try that <Tadhgmister>can someone remind me: .NET isn't a thing on guix right? I was thinking mono does that but think I am just mixing up .NET and C# <Rutherther>Tadhgmister: mono is a reimplementation of .NET, but I presume they do not have feature parity with Microsoft's, so it will depend on what version of .NET you're targeting <Rutherther>not sure what has happened since that time, but I would expect newer versions to be supported as well <Tadhgmister>tyvm, looked at the package description in guix for mono and it didn't mention .NET so thought it was a different package I needed <Tadhgmister>oh mono is in gnu/packages/dotnet.... k I should have clued in sooner <Rutherther>Tadhgmister: although sorry I think I was wrong, it seems it probably won't be capable of compiling any of the newer .NET Core or .NET (5, 6, ...) apps, only .NET framework ones <Rutherther>it really is confusing how they call everything .NET <Tadhgmister>If Pinta (which says it wants .NET 8) doesn't work I may just try the OG Paint.Net. Surely software from a decade ago would run on modern mono versions <Tadhgmister>but pinta also says on linux it can be built by running `./configure --prefix=... && make install` which is always appealing for candidate software to put in guix <makx>Otherwise the yuck solution is to use flatpak 😬 <cdegroot>I have Nix installed to get access to a wider range of software without straying too far from the True Path ;-) <Tadhgmister>same, pretty much just use nix for brave browser while I occasionally go into its source and figure out how to package parts of it with minimal success... haven't actually considered looking for image editors there <Tadhgmister>*occasionally look at brave's source to try to package it for guix <NegateThis>Flatpack is not the Guix/Nix way but providing basic sandboxing is kinda nice for stuff that doesn't need access to my whole system. <NegateThis>Haha wait yeah that seems obvious now that you mention it <cdegroot>I always forget what I install so a garbage collect is the way, pretty much the main reason I don't use flatpak. <nemin>By the way, I'm sure this is a silly question, but I'm curious: How come most of the package form takes "(key value)" pairs, but arguments takes "#:key value"? <nemin>(I know the syntax itself, I'm more curious about the reasons why the two differ.) <Tadhgmister>I have also wondered that, feel like a number of places guix chooses to use alists where I feel like tagged lists would be clearer <Tadhgmister>might be historical reasons, when guix setup their record types they chose the alist style notation and there hasn't ever been any compelling reason to change it. The parsing of ensuring that each element is a pair and the first one matches an expected symbol is likely easier than ensuring each second element is a key <nemin>But parsing is more of a language concern, no? As in as long as Guile works well, Guix shouldn't care about it. Beyond that, yeah, I guess I can accept that explanation, though I do wish they went with the keyword syntax instead everywhere. Makes forms much less crowded. <Tadhgmister>scheme parsing is honestly kind of trivial other than functions being able to do the `define-syntax`, it is the functions which do do that tthat get complicated. The handling of guix record types like package, operating-system, origin, etc do define their own syntax and associated parsing. I'm just saying the initial design would have been slightly easier with the current notation than the one that looks "cleaner" <Tadhgmister>could also be that the keyword notation didn't exist when guix records were being designed <clone>I think the reason that the arguments is keyword format is those are actually keyword arguments passed to a build system function, like gnu-build for gnu build system <clone>I guess arguments could have been a record too, but since different build systems take different arguments you would need a arguments record type for each build system and it would be a pain <clone>But i'm just guessing on the reason based on code i've read <jfred>I'm digging through the code since I can't find a way to do this from the docs, but if anyone knows: is it possible to have one package installed in a manifest that's been built for one system (e.g. x86_64) on a machine that's otherwise another system (aarch64)? I'm looking to package/play around with fex-emu a bit and it would be convenient if I could have an x86 program in my profile alongside the rest of it <jfred>I can see that e.g. some of the `guix` commands take a `--system` parameter, but I'm looking to be a bit more targeted than that <Tadhgmister>jfred to clarify, one package and all its dependencies? <Tadhgmister>the why wouldn't `guix shell my_package --system=...` work? or the equivelent command to export the actual profile containing that package <Tadhgmister>I'm not sure you can do it in a manifest in a non hacky way, there are workarounds using stuff in (guix gexp) to override the system/target in the build but haven't looked at using that in the context of a manifest <janneke>yelninei: i incorporated your additions, thanks! <jfred>That would work for a dev shell, but at some point I envision myself wanting to have some x86 packages in my profile so I can treat them like any other installed applications. `guix shell` will probably do for now though <jfred>or... maybe this is better handled with multiple profiles at the moment? <Tadhgmister> (with-store store (run-with-store store (lower-object pkg "armhf-linux")))) <Tadhgmister>To get a gexp that resolves to a package that is forced to be compiled natively <Rutherther>Tadhgmister: no need to go that low level, just wrap packages/manifest-entries "with-parameters" <jfred>Rutherther: ooh! thanks, that's very helpful! :D <Tadhgmister>in my case I was cross compiling a whole system so there were cases where going that low level was helpful, but knowing about with-parameters is very insightful <Tadhgmister>nope nevermind, with-parameters would probably have done it exactly as I needed it in my case too <Tadhgmister>ahh no it doesn't. because I needed to trick the system config code into defaulting arguments to one system but cross compile all the code for another.... so looking at it now doing `with-parameters` and then overriding all the default settings that are based on the system would definitely be the better way to go <Tadhgmister>nope still no tricking involved. I just invoke the default arguments with a different `with-parameters`... ok this has been eye opening <kestrelwx>Guest21: Do other fonts look sharp in that Emacs? <yelninei>janneke: Thanks. For the issues on x86_64-gnu: The intr-msg-clobber patch for libc supposedly should fix it but it does not (completely?). I removed it from libc after adding some patches from glibc 2.42 which mention that they obsolete the workaround. In debian it got reintroced recently when more issues were found. <yelninei>janneke: The easiest way to see it is doing a "echo `./foo`" where foo is an executable script but without a shebang. This causes a hang during configure of util-linux when it tries to get the ncurses flags from ncursesw-config <janneke>sometimes it feels like an uphill battle... <yelninei>the weird thing is that that works currently on debian and I dont know why it does not for us <yelninei>i which libc changes would be a bit easier to test <Guest21>kestrelwx: Turns out Emacs wasn't using the font, although it says so in describe-char. I set the font again with the menu bar and it looks different. Maybe I should install fonts with guix system and not user wide with guix home? <clone>Guest21: I run emacs in a profile of its own and I noticed I had to put fontconfig in the profile to make fonts work right. I'm not sure exactly why or if its applicable to you but it might be worth trying just sticking fontconfig in your home profile <yelninei>Rutherther: Thanks a lot for cross shells. They made trying to port something a lot easier. <Rutherther>yelninei: no problem at all. I am happy someone actually uses them. During the past few months I actually got to know some parts of Guix that I didn't prior and I think I can massively simplify the codebase <yelninei>Rutherther: It took me a while to figure out where to find the relevant dirs to configure the cross-gcc I was trying to build. Definitly more convenient than waiting 4h for gcc to build natively when I dont know if it will work yet. <coopi>so im trying to extend `elogind-service-type' but I think I did something wrong cuz even though it builds succesfully, it doesn't seem to take effect <futurile>coopi: doesn't work meaning what? you still have gdm? <coopi>futurile: As in, the device still suspends (the default configuration) upon lid close <Rutherther>futurile: I mean that's the idea of extensions, that you take the already existing service and extend it. However elogind doesn't support extending. I thought that should throw an error on reconfigure. <nemin>I wonder, was it ever discussed why the mirrors list from Libreplanet.org aren't in the manual? Is it a case of nobody bothering or is there some reason that prevents it? Bordeaux and the ci build farms often fold under load, directing people to other (trusted) mirrors sounds reasonable to me. <futurile>nemin: the mirrors would be useful, it's actually not so much that they 'fold' under load, it's that they're bandwidth limited for somewhat unknown reasons <futurile>nemin: CI is in a science institute, we think it's probably due to peering. For the USA one of the other science groups has a build farm and mirror <futurile>that if I've understood cbaines investigation of it <futurile>(Nix has managed to get sponsorship from AWS which is great, unfortunately we don't have anything like that) <nemin>Right, my understanding of why it's so slow was incorrect then, my bad, but the end result is the same. I think if it's not outright banned for some reason, it'd make sense to guide people towards the mirrors too. I dunno about anyone else here, but as a newcomer, the fact that Guix has a site on Libreplanet too with important info was not at all evident. <nemin>I'm happy to open an issue about it and even add it to the docs, just wanted to make sure I'm not walking into a blatant faux pas :) <futurile>nemin: I don't think there's any issue around the mirrors. Additionally, I thought it would be nice to have a function that would select the mirror for you <futurile>nemin: suggest it as a doc pr - go for it! <NegateThis>Dam this is nice information. I had no idea Guix had mirrors closer to me than the Germany and France ones <mwette>I assume if my package build tries to install files outsize of the associaged gnu-store subdir then the phase will fail. Correct? <ieure>mwette, Correct, files can only go into the package output. <mthl>Hello, I am trying to check the behavior of a service type definition change I have made in my local guix git clone. I am not sure how to perform a manual test. I have tried `./pre-inst-env guix pull` inside a `guix shell --pure` environment to update ~/.config/guix/current and then I am doing a `sudo guix system reconfigure my-config-using-change-service-type.scm` in another terminal (outside of guix shell) and I am expecting <mthl>/run/current-system include my changes but I don't see them. Any idea what I am getting wrong ? <civodul>mthl: hi! the best way to test a Guix System service is with: ./pre-inst-env guix system vm config.scm <kestrelwx>Wonder how come I still see '%2%' in the timeout message, I'm pretty sure the service is from a system configuration on a recent commit. <mthl>civodul: Thanks, I will follow that path <nemin>"qtdeclarative-6.9.2-debug 867.8MiB 110KiB/s 01:19:21 58.7%" This is pain. <untrusem>nemin, yes it pain sometimes, specially that qtdeclaratvie package <civodul>kestrelwx: yeah i fixed it recently, but maybe that didn’t make it into 1.5.0? <untrusem>you can use other substitute urls, maybe that might hel <ieure>kestrelwx, I just ran into that weird timeout message for the first time 30 minutes ago. <kestrelwx>civodul: Oh, it's not the `current-guix` daemon. <mthl>civodul: I have succeeded in checking my change behavior inside a VM. thanks for the suggestion! It required several trial to get a minimal working test system, but the error messages were helpful. <bobo>@futurile Thanks for your reply regarding guix.scm file <kestrelwx>I think the llvmpipe tests for Mesa would fail on older AMD64 CPUs with SIGILL, like they do on other platforms. I see it on my 2013 Broadwell. I'm not sure if that matters, though. <kestrelwx>I should probably just check what instruction it is. But yeah, this is 2013 CPU. <kestrelwx>`guix build mesa --check` should fail on lp_test_format, if I'm correct. <kestrelwx>I'll check in the morning where the failure is on my end that'll probably be enough. <FuncProgLinux>sneek later tell kestrelwx that I was able to build with these outputs, even with 3 rounds: /gnu/store/zmf2sxdl3iwzdp3w4sw0vwda0bm8cihw-mesa-25.2.3-bin /gnu/store/sd1hghag49mzwm8phwlf7xa0yf7vjmkq-mesa-25.2.3 <simendsjo>Is there a problem with linux 6.18? I notice it was added Jan 3, but linux-libre still points to 6.17 (which is unsupported according to kernel.org?) <gabber>what is the reason for the per-author copyright lines we keep in our source code? <theesm1>simendsjo: not that i'm aware of, think i'll prepare a pr to update it tomorrow (and possibly prepare one for the removal of 6.17 and one to prepare adding 6.19 which has been out since a few minutes) <theesm1>there's always a delta of some weeks between adding a new kernel version and letting linux-libre point to it