IRC channel logs
2024-12-10.log
back to list of logs
<basicnpc>(Wow.. I only want to package maestral.. but then it virals into ~10 packages, taking out almost all of my day. Is this normal?) <homo>I'm trying to build custom kernel in order to be able to use gdm https://paste.debian.net/1339109/ but the problem is linux-modules package gives error: gnu/build/linux-modules.scm:278:5: kernel module not found "usb-storage" "/gnu/store/a4yhzd6ajz8qjx2l3v68b4zi8q21zank-linux-libre-simpledrm-6.11.10/lib/modules" <resu>is there a way I can call "guix build/configure" to not pull the latest packages <resu>I have a very slow internet connection so its kinda annoying when testing configs <robin>resu, guix time-machine or inferiors might help, if the issue is that guix wants to do too much after guix pull-ing, for example. i don't have much experience with them though <resu>I havent read up much on "time-machine" so ill look into that <apteryx>efraim: rust-libcst is supposed to come with python bindings, but there are none in the package... I wonder if perhaps we have to install these manually? <efraim>Probably. I can take a look at it today <apteryx>if you have some time, I'd be interested to know if you see anything. I looked at the cargo.toml but it seems the features should be already enabled <homo>sorry for part before link, forgot to remove it <Rutherther>sneek: later tell resu: guix build doesnt pull latest packages. It pulls the packages according to guix version you have. So just make sure to use stable guix version as long as you do not want new downloads. You can even use older versions of your guix profile or keep multiple guixes somewhere else, utilizing time machine and guix shell guix <basicnpc>Spent a whole day and still not done (laugh-cry)! <basicnpc>Now I'm stuck with packaging python-virtualenv-20.23.0 <basicnpc>ModuleNotFOundError: No module named 'virtualenv.version' <basicnpc>But come on.. I'm installing virtualenv. How am I supposed to have the module virtualenv.version? <basicnpc>I will read log. Please help :-) Thank you! <basicnpc>In the meanwhile, in the keep-failed directory, I do see ./virtualenv../src/virtualenv/version.py <efraim>apteryx: it looks like the rust package rust-libcst is a sub package of the python package <Rutherther>basicnpc why are you packaging virtual env from scratch when its already in guix? <basicnpc>Rutherther There's one virtualenv but the version isn't right. <basicnpc>See, I only want to package maestral, but then the missing of deps keep asking me to package more because each of them only allow their deps to have certain versions. <janneke>efraim: so, i'm changing (and (target-linux?) (target-x86-64?)) to (and (target-linux?) (target-x86?)) to fix ii686...but you said aarch64 also fails <janneke>any reason to not just use (target-linux?), or do you think we should not include arm/powerpc/riscv at this time <efraim>I'll try sending building hello for powerpc64le to berlin and see if that works. if it's fine then i'd assume riscv64 would also befine <rekado>gfortran-toolchain is at version 11, but gcc-toolchain is at version 14. Is this a problem? <rekado>I also see that the gfortran-toolchain package provides libstdc++.so.6, which it probably should not do. <efraim>rekado: we discovered that you can't mix gfortran versions so gfortran-toolchain uses the only version of gfortran we support, which is the same version of our gcc <efraim>depending on how and where we use the *-toolchain packages it might be worth switching gcc-toolchain to provide all the language support that gcc supports, and then gfortran-toolcahin could be an alias for gcc-toolchain <rekado>does this mean that in a single profile you can only use gcc-toolchain@11 together with gfortran-toolchain? <efraim>oh good, guix cross-built for powerpc-linux seems to work just fine <efraim>guix copy: error: implementation cannot deal with > 32-bit integers <efraim>looks like I spoke too soon about cross-built guix <efraim>honestly I think this is an cross-endian issue <efraim>janneke: gcc-boot0 failed on ppc64le. I've switched that one to just be target-linux and now I'm testing that on ppc64le and aarch64 <efraim>took about 12 minutes to fail on ppc64le before <efraim>nope, that didn't help on either architecture <efraim>janneke: assuming it helps I would add it for i686 since it has the same bootstrap path as x86_64 <efraim>aarch64 looks for libpthread.so and libpthread_nonshared.a, i'll see if those are in %bootstrap-glibc <efraim>looks like we've got this wave thing going alright <Lumie>I haven't updated Guix in 1.5 months, geez <Lumie>I'm starting to get withdrawals <csantosb>Ey guix, is this just a subjective feeling or the amount of updated emacs packages has recently decreased in master branch ? <civodul>csantosb: thatâs my impression too! what happened to the Emacs team? <csantosb>issues site is down now, but would it be that the amount of patches just decreased ? <efraim>ok, I tried patching libpthread.so to like libc.so, so maybe it'll build gcc-boot0 now on aarch64-linux <janneke>ACTION pushed squash commits for i686-linux's commencement/bash/libstdc++ <janneke>ACTION also rebuilds a 32bit childhurd <efraim>ok, now I got aarch64 failing at the same spot as ppc64le <efraim>and now I have gcc-boot0 building for powerpc64le <cow_2001>i probably looked at it and did not understood any of it one or twice before <apteryx>is it supposed to be fine building a crate from its git checkout? <apteryx>I think the issue is some metadata is not there: now it seems the <apteryx>err, find-files: /gnu/store/5rab6p4qvh2ygmp0sfgyjicppjy2sxf6-rust-ruzstd-0.7.3-checkout/share/cargo/registry: No such file or directory <apteryx>and then no crate for ruzstd gets added to the build of the dependent <apteryx>ah, that unpack-rust-crates looks at the rust package *sources* ? <efraim>yeah, that's how we ended up with cargo-inputs <efraim>huh, armhf's %bootstrap-glibc doesn't have a libpthread_nonshared.a <apteryx>so reading between lines, it seems unpack-rust-crates looks for .crate files under share/cargo/registry prefix of each cargo-inputs, and install/unpace those <efraim>it does that for regular inputs, but it also grabs all the transitive sources from cargo-inputs <apteryx>so the problem is that the share/cargo/registry when built from git is only availabel in the built package, not in the source, as would normally be the case for crates taken from crates.io <apteryx>but the unpack phase only looks in the *source* of the package, not the package output <apteryx>I guess I'll revert building ruzstd-0.7 from a crate <apteryx>(and manually disable a few tests for which there are missing data files) <PotentialUser-19>I tried sending a patch to update a package, but debbugs never replied to my email, so I can't send the patch (there are two patches, so I needed to use a cover letter before the two emails). I tried checking if the issue had been opened on issues.guix.gnu.org, but the site is down. Do you know if that second thing is the cause of the first ? Or if <PotentialUser-19>it's just expected that debbugs take a few hours to reply ? It's my first time sending a patch. <basicnpc>Does the guix channel contain many packages with repetitive versions? <csantosb>qa.guix.gnu.org is down to, or do I have a bad day ? đ„ <basicnpc>Say a package A has version 1 2 3 4 5 and guix channel needs to have many of them, say 1 2 4 5? <mccd>Heya, I have a service (laminar) that executes bash scripts. Within the bash script I have `#!/usr/bin/env -S guix shell -- sh`, but the script complains that guix is not found. Is there a specific way I can make guix available to the script/user? <basicnpc>I was trying to package one thing, and found that I need to package many missing dependencies. Many of them are already in guix, but the versions are wrong. <civodul>csantosb: it seems to be confused by the fact that mumi is down, actually <graywolf>Hello, before I dig into it further, I am getting error when trying to run `guix home container'. Anyone has idea what this is about: guix home: error: mount: mount "none" on "/tmp/guix-directory.5XnNJy/sys": Operation not permitted <sneek>graywolf, you have 1 message! <sneek>graywolf, ArneBab says: I use ,profile (for-each (λ _ (PROC)) (iota 10)) <graywolf>But will check the issue, maybe there will be hints. Thanks :) <csantosb>basicnpc: if B depends on A1, and C depends on A2, you won't be able to install B and C on the same profile, I guess, if A1 and A2 are both propagated <graywolf>hm, I do not think I am using apparmor though <graywolf>I know this used to work, so I wonder what changed <csantosb>You cannot install python3.8 and python3.9 in the same profile, for example: there is a conflict <civodul>ACTION restarted issues.guix.gnu.org <graywolf>But `guix shell -C' *does* work, so this is something specific to guix-home <Altadil>PotentialUser-19: if it is your first patch, I believe it needs to be manually approved, so it is expected to take longer. I donât know what impact the current outage had on your mail, though <basicnpc>csantosb I see. What if they are just libraries, not binary that must show up in the PATH? <csantosb>If they are considered as inputs in the package definition, not as propagated inputs, I guess it should be fine <csantosb>That being said, rather try to update obsolete packages, if possible <PotentialUser-19>Do you know if it'll cause an issue that I have only sent the cover letter for now ? (Since I need a debbugs id to send the patch series itself.) <janneke>efraim: headsup, i've pulled your core-packages-team fixes, saved the result as core-packages-team-old, rebased core-packages-team, and am about to push a binary-equivalent (apart from the rebase) core-packages-team <efraim>the gcc-final changes are needed on the other architectures too <janneke>ok, i'll remove the target-x86 there before pushing <efraim>the STAGE_CC_WRAPPER and -Wno-implicit-function-declaration flags <janneke>i'm keeping the REMOVEME commits because i guess we both don't want to rebuild world at this time <efraim>I have a fix for arm32 in bootstrap-glibc but it only affects armhf <janneke>well, in that case i'm removing the if -- <efraim>i586-pc also gets the adjustments then? it's all that was left : <janneke>yeah, it's highly probable that's needed; if *-linux, and x86_64-hurd needs them with gcc-14... <amano>Does anyone use guix system on single board computers? <basicnpc>I guess that's a hex, so I translated that into base32 (via an online converter), but it still complains. <efraim>I have guix system on a couple of boards, but I mostly use them for building packages <Rutherther>Yes, guix is originally fork of nix, so how derivations are handled comes from it <basicnpc>gosh. I am still figuring out which hash to put.. <basicnpc>So I need to use a function in guix for that..? <Rutherther>Use guix download, or just put a placeholder with wrong hash, and get the right one in guix build output <basicnpc>Rutherther I tried to use the place holder but for pypi fetcher it doesn't work. <basicnpc>It provided lots of 404 not found, and i realized while fetching it puts the hash in the request <PotentialUser-19>`guix download <URL>` downloads the referenced file to the store and outputs its hash. <basicnpc>Did that.. still failed and all of them "404 not found" <noe>basicnpc: it works with an underscore in pypi-uri â(uri (pypi-uri "trove_classifiers" version))â <basicnpc>Now it's thinking it is version 0.0.0 again. ... <efraim>implicit-function-declaration error in bash-final for powerpc64le. I'll wait and see how the other architectures do <basicnpc>How do I package something that bootstraps its own version? For example, say the package XYZ-n always require XYZ-(n-1). Do I need to package them all the way back (say n=23)? <basicnpc>I'm actually running into a similar issue where -n requires -(n-k), but I don't know what k is.. <gabber>basicnpc: what software are we talking about? <gabber>in the case of GCC there's an old version (4 something) that is capable of building newer ones and can itself be built through other, simpler c compilers (tcc in that case) <basicnpc>I'm packaging a newer version of python-poetry. <basicnpc>And when I package this poetry-plugin-export, it's asking to use a "new enough" versin of poetry again. <basicnpc>I remember some common lisp implementation (sbcl?) uses this kind of bootstrapping too. <gabber>you may need to build an old(ish) version of poetry-plugin-export first <gabber>almost all packaging/compiling software does this (unfortunately) <basicnpc>I see. Ok, I need to take a few hour break. Have been spending my whole yesterday on it. (So I don't have my guix box now.. I am addicted somehow.) <gabber>basicnpc: sounds like a reasonable plan (: <basicnpc>And btw.. I just want one package, and then it spirals in to >10 packages, which took me a lot of time. Is it normal to a guix user? <gabber>basicnpc: yes. but only with packages not yet available <basicnpc>I have a natural need, and it's unavailable. And turns out that most of its dependences aren't available either. <basicnpc>Also, a lot of them shut off #:tests?.. I wonder if this is really ok to do. <basicnpc>Some of them didn't get the versioning right either (so the python library thinks itself as being version 0.0.0). <basicnpc>"Everything that builds will always build in the future." - This is a good and desirable promise, but now I'm in the rabbit hole I start to have doubts. <tobtoht_>why does `guix graph git-minimal` include bootstrap dependencies? is there a way to filter them out? <Rutherther>basicnpc version 0.0.0 usually means it depends on setuptools smp and it was not provided <tobtoht_>bootstrap dependencies appear to show up for any package that (transitively) depends on glibc-utf8-locales (e.g. also patchelf, gawk) <civodul>ACTION tries to find where that comes from <efraim>same bash-final error on armhf for core-packages-team <mccd>Hey, I have a file in my-packages/my-package.scm with (define-module (my-packages my-package)) at the top. Afterward when I try to run guix deploy os.scm -L my-packages, it complains that my-packages is not found. What am I missing? <graywolf>I sometimes have issues with -L . spewing warnings due to .scm files not being modules (e.g. for channels.scm file). Is there some convention to work around that? I guess I *could* name all non-modules files with something else then .scm... <civodul>tobtoht_: so this comes from texinfo <mccd>Hmm, so in one file I have a (define-public blahblahblah...) that gets successfully imported and adds a package. How do I now install that in my os definition? <Guest26>I have just installed guix for the first time as a package manager on my Fedora installation. Before I do anything, I just wanted to get a sense of what the installation process has done. Running "echo $PATH" I can see that my path has been modified to include some guix-related directories. But I cannot tell by which mechanism my path has actually <Guest26>been modified. I noticed that a file was added at /etc/profile.d/zzz-guix.sh, but as far as I'm aware zsh does not load this file upon login (maybe I am wrong about this though?). I couldn't find any other edited files that I know zsh does load, such as /etc/zprofile <Guest26>maybe systemd loads this file? that would make some sense, as I noticed the guix installer detected that I was using systemd <basicnpc>Rutherther Yeah, something I came to get used to fixing. B <Guest26>oh I see now... /etc/zprofile on my system loads /etc/profile which in turn loads everything in /etc/profile.d <efraim>27 hours to build rust-1.54 on riscv64-linux <efraim>oh thats a relief. I still had a copy of guile-final on powerpc-linux <efraim>janneke: re overload-threshold on hurd, I found that anything over 1 was reported back as 1 <cwebber>heya y'all, I'll be speaking at the Guix Social thing on Thursday :) <mfg>efraim: does it make sense to base the tree-sitter upgrade on rust-team branch? or should it go to master? I'm currently also updating as much of the grammars as i can. It works with way less hassle than i anticipated (thus far) <librehawk>GUIX Linux 2 Hurd Without ReInstalling, is this possible? <mfg>librehawk: you mean on bare metal? i don't think so. <mfg>because the kernel gets loaded at boot time and even though linux can kexec another linux kernel, i doubt it can hand off the system to an entirely different one <mfg>so i don't see how this would work without reconfiguring and rebooting the system <Googulator>In live-bootstrap, we hand off from builder-hex0 to Fiwix, and then from Fiwix to Linux, so it's certainly possible in theory <Googulator>But either GNU Mach would need to support acting as a Linux kexec guest, or Linux would need to support loading GNU Mach into an environment it's familiar with <unmush`>reminder that librehawk asked "without reinstalling", not "without rebooting" <mfg>ah, sry. Then yes, it's possible/ <Googulator>different calling convention both libc<->kernel and userspace<->libc <unmush`>yeah, so you'll need to have different profiles for each system <mfg>If your system cofniguration used to use linux and you update it for hurd (assuming the relevant packages build currently) it should be possible to create a new system gerneration with hurd <mfg>and then reboot into it <Googulator>One solution would be a libc that can talk both libc<->Hurd and libc<->Linux on the backend, and present a consistent frontend ABI <mfg>i don't see how the abi is relevant here since all packages are compiled for hurd in that case <unmush`>mfg: and what is ~/.guix-profile compiled for? <unmush`>and, for that matter, ~/.config/guix/current <Googulator>ABI is relevant if you want to avoid having to complie everything twice <mfg>the current system, upon reconfiguring and rebooting this is going to point to another profile <unmush`>guix system doesn't touch the per-user profiles <Rutherther>it won't, but it doesn't matter, you can just rebuild it <Googulator>I wonder why libc<->userspace ABI is even different between Hurd and Linux <mfg>unmush` i see what you mean, don't know how guix handles this/what happens <Googulator>different enough even that compilers need to target GNU/Hurd and GNU/Linux separately <Googulator>ideally, a compiler should be able to target "GNU" or "glibc" or however you want to name it <Googulator>& then glibc can take care of figuring out how to talk to the kernel <unmush`>potentially the profile-manipulating code could be adjusted so that each profile generation name includes the system it is built for, and system boot could then do a little dance with the symlinks to make all the generic profile names point to the latest one of the current system <unmush`>I'm sure things like shader caches will cause problems no matter what though <Rutherther>why are you guys complicating it so much? no one asked about having system support both platforms, but about moving from one to the other <unmush`>because the idea of supporting both platforms is a bit exciting and therefore tempting to ponder <Rutherther>then just make a service to switch /var/guix/profiles/per-user based on the booted system <librehawk>I know there are Users who want Linux as a Slave kernel in Hurd, to run everything #FreeSW, but too tedious for a small community... Pls Today let's speak of Migration from Linux to Hurd with Ease via Guix <look>Hi, I'm trying to reconfigure my system, but its failing because guix-1.4.0-28.285f086 fails to build, is there anything immediate I can do to reconfigure my system? <rekado>librehawk: Linux is free software, too. <Rutherther>Kolev: just put the ip. Or if all the computers are in your control, you can just make it a domain and put it to their hosts file. Or even more fancier, if that server is supposed to run always, you can make it a dns server, and point other clients in the lan to it as dns server. Then you can make any domain you want, point it to any ip you want, and change on the fly <Rutherther>look: what command are you running specifically? what is in the log? <Kolev>Rutherther, can I put the hostname `farnsworth`? <Rutherther>I am not sure what you are asking. Like, yeah, it can be the servername and you can point others to it. But if they won't access it by that domain, the virtual host will not be matched, so your site will not load. So do it only if the clients will be accessing the server with domain "farnsworth" <Rutherther>look: hm, so why don't you use older guix version? <look>Rutherther: went back a couple commits and that did the job, thanks <Rutherther>but it's still strange. On upstream CI guix builds are not failing on x86_64-linux <dariqq>it looks like x86_64-gnu is missing in the 'package-transitive-supported-systems, implicit inputs' tests <basicnpc>poetry 1.2.0 requires poetry-plugin-export 1.0.6 <basicnpc>which requires poetry-plugin-export 1.0.5 <basicnpc>I feel stupid and being kicked around by the versions. <basicnpc>Is there a smarter way of doing this? Or should I really go through tens if not hundreds of bouncing back and forth? <basicnpc>Also, say I want to contribute my packaging later in the guix repo, I should include all of them, right? <unmush`>python packaging has always been suffering. Maybe the poetry self-dependency is only for tests or something? <Rutherther>basicnpc: if there is a cyclic dependency, you need to somehow break it, one way is indeed by going down by all the versions. Another is to use other substitute compiler/dependency that is simpler to build, I doubt that would be an option here. Another possibility is to use already built version, but this introduces trusting trust attack possibiliies, for that reason is discouraged and it isn't very common in the official guix channel <rekado>basicnpc: is it enough to add python-poetry-core here instead of the full poetry package? <basicnpc>rekado I don't think so. Utimately at some point poetry was required. <basicnpc>Rutherther What would you suggest xD ... <janneke>dariqq: hmm, it's comparing to (filter target-linux? %supported-systems) <janneke>so x86_64-gnu shouldn't be in the actual-value, according to the intent of the test <dariqq>janneke: Oh i didnt see that, interestingly (target-linux? "x86_64-gnu") is #f for me <janneke>yeah, sure -- so that's why there's no i586-gnu, x86_64-gnu in the expected-value <janneke>it [still] puzzles me how i586-gnu doesn't show up in actual-value and x86_64-gnu does <unmush`>basicnpc: for example, python has a wealth of testing frameworks that have cyclic dependencies on themselves, because they decided to rely on themselves to test their own correctness (lol). IIRC we had to make a bunch of *-bootstrap packages with `#:tests? #f' to get those working. <janneke>it seems that "someone knows" that you cannot cross-build from arm to i586-gnu, but is fine with x86_64-gnu <unmush`>that's the only experience I have with python cyclic dependencies <dariqq>janneke: Found this edca2863bcb52388fe454e14136264a4f7490273 . Maybe also filter for target-linux? in the other case? <dariqq>janneke: or remove all hurd targets from the linux headers (probably better) <janneke>=> (supported-systems (remove target-hurd? %supported-systems)) <dariqq>ACTION wonders where else i586-gnu is hardcoded <janneke>ACTION searched for that a lot, but an extra chack wouldn't hurt <cow_2001>i have a guile-xyz type of package i am writing. it has a script in another language. i want to package that script file somewhere guile would know where to look. how do i go about doing that? where do i put such script files? <dariqq>Also janneke , if you are up for a (rather pointless) world rebuild cmake-build-system currently sets LINUX as CMAKE_SYSTEM_NAME instead of GNU when crosscompiling to hurd. I have sent #72751 a couple of months ago for this <cow_2001>concretely, i am packaging guile-pstk, a GUI library for Guile, and one of the things in it was a Tcl script for initialisation of stuff on the Tcl side. i took the source out of the pstk.scm source file because it seemed to be more comfortable working with source files rather than strings of those sources <csantosb>There is something wrong with `guix refresh -s module:(gnu packages guile)`, but what ? <csantosb>Taken from 9.6 Invoking âguix refreshâ <janneke>dariqq: we may well have a gnu world rebuild coming up some time soon <Rutherther>I don't know what the reasoning is, but they switched to year.month versioning <dariqq>janneke: great. Imo moving the cross compile logic out of the build side code would be really beneficial for decoupling the cross compilation and normal build (i.e. adding new target , adding other Flags for cross compilation like CMAKE_SYSTEM_PROCESSOR ... would not cause rebuilds for non cross compiling cases) <cow_2001>i see that a lot of tcl libraries are on /lib/libname/libname.tcl <cow_2001>that is #$output/lib/libname/libname.tcl <Deltafire>anyone know why ^@ characters are shown on the console during boot? <Deltafire>wow, didn't realise Shepherd is 21 years old :o