IRC channel logs
2025-12-30.log
back to list of logs
<ieure>Hmmm, got a weird one. Put my laptop to sleep last night, tried to wake it this morning, it wouldn't. Hard rebooted, but it won't boot, after unlocking GRUB, it complains "error: file `/boot/grub/x86_64-efi/normal.mod' not found." and drops me to the grub rescue prompt. <ieure>Indeed, poking around the grub rescue shell, that module does not exist at the path it's looking, though there are many other modules, and a bunch of ~-suffixed backup files. Which is odd. <test202020>two hours and guix with mirror substitue fail with gzip error for log. long time cpu be so hot ans fans working very fast and long. that big fail <FuncProgLinux>ieure: Like extending the build system to run autogen.sh and patch ACLOCAL_PATH (?) <FuncProgLinux>(it's needed for future MATE updates, as .tar.xz release files are no longer in the FTP mirror) <ieure>FuncProgLinux, You need to be much more specific. "Guix Scheme" isn't a thing (do you mean "Guile Scheme?"). gnu-build-system already runs autogen.sh. <FuncProgLinux>And while upstream will continue to deliver .tar.xz files I think It would be best to use the direct git source. <ieure>Sure, so, do that? Why do you think you need to "extend Guix Scheme" to accomplish it? <FuncProgLinux>ieure: I've already done some. But it requires me to patch the phases to set env variables and run the autogen.sh manually. (I don't discard that I'm doing something wrong though.. Using "setenv" and "invoke" seems kind of dirty) <FuncProgLinux>Oof. I cannot reach Debian Paste rn. But the changes involve increasing the inputs list sadly :/ <ieure>I'd have to look at your package definition to give any advice, but you shouldn't need to run autogen.sh manually. You can add a phase that sets environment variables before the 'bootstrap phase, which is the one that will run autogen.sh. <FuncProgLinux>Ah I see. I think I can upload it tomorrow. The autogen.sh step is needed for the other phases. The .tar.xz files upstream provides are source code distributions that already ran such command. <ieure>Yes, I understand, that's how all well-behaved autotools projects work. <FuncProgLinux>Then again I also seccond the idea of using "clean sources" instead of prebuilt projects. <test202020>guix 1.5.0 install unusable because all screen is artifact. on 1.4.0 that not be present <test202020>in first few seconds i see somethink like segfault error <ieure>test202020, Segfault on boot is a known issue. There is no 1.5.0 installer, only 1.5.0rc1. Please report issues with it to guix-devel and/or the issue tracker on Codeberg. <ieure>Including details of the hardware you're booting it on. <test202020>1.4.0 working and i cannot to login to another ttys <ieure>test202020, You're the first I've heard to encounter this problem, fixing it requires troubleshooting to determine the problem. I cannot tell you how to fix it because nobody knows how yet. Which is why you need to report the bug. <ieure>I don't understand what you're saying about switching ttys. <test202020>nomodeset to kernel fix that, but need to more research <jonze>test202020 this may be an issue with kernel 5.10.0-37 roll back if you can (i had same issue but different distro) <test202020>long waiting unser SDL2 building, looks like frozen <ieure>test202020, If you want help, you need to provide information and ask questions. Randomly saying stuff isn't going to get you anywhere. <apteryx>is there a way to have a service honor the environment variables set by the search paths of the profile diectory? <apteryx>*a guix system service honor the system profile environment variables? <moorhuhn>Why do I have on no systemd systems problems with opening tty 2 tty3 ... <moorhuhn>It 0.00001 second blinks then it becomes a blackscreen <PotentialUser-29>hey i have this problem that after installing guix i cant run guix-daemon. .config/guix/current/bin is in PATH but for some reason the directory doesnt exist (wasnt created by installer?). i cant run guix pull because the daemon isnt running. im on void linux. should i just run guix-daemon manually from /gnu and try guix pulling and hope it fixes <Rutherther>PotentialUser-29: void linux is runit, right? That is not a supported init system by guix-install.sh. That means you need to start guix-daemon yourself. I would not recommend doing that manually, rather, make a service for it. You can find the initial guix-daemon in /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon. You can find the systemd service in /var/guix/profiles/per-user/root/current-guix/lib/systemd/system/guix-daemon.service or... <Rutherther>...so you can base it off of that service. What's most important is running it as guix-daemon user, the arguments to guix-daemon and the environment <PotentialUser-29>Rutherther yeah i mean im planning on making a service for it, the issue was it not being availible in PATH :D ill make the service and get back to you <Rutherther>ie. "su -" and then I would expect you to have it in PATH. If not, something is wrong somewhere. Mind the "-" to use a login shell. <m4xxed>Does anyone know when the rust-team branch will be merged into master? (I need at least rust-1.99 <untrusem>you can use rust from rust-team branch with ` guix shell --from-branch=rust-team rust` <m4xxed>untrusem I thought so too, but ` guix shell --help` does not list this particular option on my system... <m4xxed>maybe I can combine `guix time-machine` with `guix shell` somehow? <Rutherther>exactly, "guix time-machine --branch=rust-team -- shell rust" <Rutherther>or you might want to do "guix time-machine --branch=rust-team -- describe -f channels > ./channels-lock.scm" first and then "guix time-machine -C channels-lock.scm -- shell rust" so that you always get the same commit even if it updates. So that you can control when you update <untrusem> guix install emacs-next --with-branch=emacs-next=master , I see this in manual <untrusem>guix shell: error: the source of rust@1.85.1 is not a Git reference <Rutherther>untrusem: that is for getting the emacs-next package with that branch, not Guix itself <Rutherther>you will probably struggle using transformations like that on rust, because it needs the previous rust versions to bootstrap them, so it's not as easy as just changing the commit of the rust package itself <m4xxed>alright, thank you Rutherther and untrusem for the ideas :) <Arsen>i permiate all corners of the free software world i fear <test202020>exisr ways to sync guix pull with user and system? <Rutherther>test202020: what do you mean by 'system' exactly? <Rutherther>and are you sure you want to sync them? Using root is typically discouraged in the first place. Anyway there are multiple ways to do that and if you want to have the least struggle, I would recommend pulling just as one user and pointing the other user's PATH to the first user's profile in their ~/.bash_profile (or other shell equivalent) <Rutherther>specifically by "GUIX_PROFILE=/var/guix/profiles/<first_user>/current-guix; . $GUIX_PROFILE/etc/profile; unset GUIX_PROFILE" <test202020>i already have synched pull in user, you mean i can use users cache? <apteryx>Arsen: I'm interested in this topic debuginfo, but last time I checked it was a bit bogged down by having to introduce bigger dependencies in this very early part of the graph. <apteryx>also, I suspect without some work on the infrastracture to serve debug symbols, this work wouldn't be very useful? <Arsen>the client would most certainly be useful even then <Arsen>wrt the extra deps, surely guix has some way to split the package up? <Arsen>(the new dep is curl, really) <Arsen>serving debuginfo requires *some* new infra but it's fairly easy <Arsen>it is enough to run debuginfod -F <directory containing debug info files> to serve stuff <Arsen>we're about to provide it in gentoo <test202020>working with full git repo is very slow and hard for machine. exist way for solve that problem? <identity>test202020: it takes a while the first time, and then some afterwards <sneek>Welcome back identity, you have 1 message! <sneek>identity, Rutherther says: if you're encuntering this (larger cursor) on Guix System, it might be the same thing, ~/.local/share/icons is not added. Only ~/.icons is from user's home in /etc/profile <identity>Rutherther: i do not even have ~/.local/share/icons <FuncProgLinux>idk if it's against the rules to ping another user here lol but is ieure here? I can provide the package definition I talked about yesterday (the autogen.sh stuff) <identity>FuncProgLinux: why would it be against the rules to contact a person that you want to contact? <test202020>but for what? why guix need to recount object always? <FuncProgLinux>identity: Spam prevention is the first thing that comes to mind to avoid clutteting the conversation (at least icedove IRC's gets cluttered easily) <identity>test202020: Guix does not need to do that *always*, git needs to recount objects when pulling new stuff (i.e. new objects) <FuncProgLinux>test202020: If you changed the main guix origin from codeberg to a local checkout repository, It will re-index everything. <Rutherther>test202020: yes, reconfigure does clone the repository, because it checks if you're doing a forward update. See the shared-cache-service-type for mitigation <test202020>nut for make that need to very slow reconfigure system.? <test202020>if i break indexing for change config.scm i going again to reindex repo <test202020>no way to disable indexing? this wasteful time... <test202020>i lost many hours today and my system not update from installer suite, because indexing is very slow and takes hours <test202020>that make system with other package managers more useful <test202020>user not want to lost hours for failing updates where in apt many time taking by downloading packages from web. <test202020>packages deb in my usb that very fast. declarative system configure is fine idea, but that hard to use with slow updates <yelninei>what can i do to make magit over tramp find the remote git? "~/.guix-profile/bin" is already in the tramp-remote-path <yelninei>Adding tramp-own-remote-path seems to work but I dont quite understand why the other one is not working <ieure>FuncProgLinux, I'm around now, but wasn't when you pinged. <FuncProgLinux>ieure: np, I was hacking around and I think you are right, no extension is needed, it's an issue with the phases order <FuncProgLinux>a pre-built tarball is given, but I opted for using the git sources directly. Sadly this requires the addition of (recursive? #t) and a lot of native-inputs :/ + fixing the phases to run the autogen.sh <ieure>FuncProgLinux, Since there's only one submodule, it shouldn't be too difficult to extract into a libegg package, if you're inclined. <ieure>FuncProgLinux, libgpod is doing some similar stuff to what you need in this package. <ieure>Looks like you may have cribbed from it already. <hugohugo>Note that I just learned that if you add "recursive? #t", that you need to change the hash, because if guix will find a checkout with the matching hash, it will not do a new checkout (so won't do the submodule recursion) <ieure>hugohugo, You have to do that any time you change the origin, including stuff like bumping the version. <hugohugo>When you change the version, it will complain that the hash is wrong, it won't reuse the checkout with the existing hash but the wrong version <Rutherther>that's only because you presumably also changed the name of the output, when using something like git-file-name. So it cannot be reused anymore, because the name is different now <Rutherther>but any time you do keep the file name, you need to make sure you recalculate the hash properly after doing any changes. That goes to any fixed output derivations, although you typically come into contact with them pretty much only when using the "origin" interface <hugohugo>Ah, and the 'recursive? #f' does not end up in the filename (why would it) <FuncProgLinux>ieure: The submodule itself is the "mate-common" package. Which is already "skipped" if we used the provided tarballs <FuncProgLinux>I'm not familiar with the libegg thing. Would it be the best course of action? <ieure>FuncProgLinux, libegg is the main (only?) thing in the mate-common submodule. <FuncProgLinux>ieure: Ah I see. I said that because the build fails because the autogen script complains about not finding "mate-common" but I haven't really read that script myself. I'll check libgpod <ieure>Rutherther, You might have some idea how to do this... I'm writing a collectd service. Collectd has a Python plugin which embeds an interpreter and lets you write plugins in Python. But you need to add stuff to its sys.path for that to work. <ieure>Rutherther, I packaged a plugin I wrote. But I don't know if there's a good way to figure out the sys.path entry for it to add to collectd's sys.path. Also, this propagates a library needed to work, which also has to end up on sys.path. <ieure>Rutherther, Which is sounding profiley to me. <ieure>Is there some way to get a profile of some package set? And figure out the path in there? Path needs to be computed because it includes the Python version, which will change over time. <Rutherther>ieure: can't they just be put to the regular site-packages paths? That way they will end up in sys.path through the GUIX_PYTHONPATH environment variable <ieure>Rutherther, That should work, but I don't like that you have to manipulate both the system profile (to add the packages) and services (to use them). And this should support running unpackaged plugin code. <Rutherther>ieure: I don't think you have to manipulate both, you can just make a profile as part of the service and 'activate' its search paths as part of the service. As for unpackaged, it's a question how to handle that well, yeah. In the end I think you will either need a wrapper or maybe some patching of a python file to handle it. But now, what path do you point it to when it's not packaged <ieure>Rutherther, Hmmm, are you talking about extending profile-service-type? <Rutherther>ieure: no, I am talking about a profile that would be part of the service <ieure>example of a service that does this? <ieure>That was my initial question, is how do I make a profile. <ieure>I see there's `make-profile' in (guix profiles), but nothing seems to use it. <Rutherther>ieure: https://paste.debian.net/hidden/2fd3b85f something like this is the idea. I do not know of a service that would be using something like this. I don't really have willingness to do a complete example at the moment, but I think I could in a few days <ieure>Rutherther, That's fine, I think I can make this work. <Rutherther>also I forgot about "#:select? not-config?" for removing the (guix config) from the source module closure, you can find that at multiple places in guix code. I am not really sure if the module can be imported as part of the closure or if that make-config.scm has to be used every time <Deknos>is there a reason why there's no importer for golang modules/projects? or is it just that nobody did the work? <ieure>Deknos, It's in the Guix manual, "Invoking guix import". <Deknos>i could have sworn java/mvn is also on there, but i do not see it.. does not matter that much, python and golang there \o/ <ieure>FuncProgLinux, Would you say it's not vegata-able <FuncProgLinux>I removed mate-common as an input and (recursive? #t) and added libegg but the package didn't build :( <hugohugo>Package name question: I'm trying to fix "electron-cash", and that needs Python package "python-bitcoinrpc". Now that exists, so I could package it with the name "python-bitcoinrpc". But there is also a package called "bitcoinrpc", what should that be called then? (I accidentally packaged that one first, before realizing it was the wrong one.) <hugohugo>(There is also 'pybitcoinrpc', and various varieties.) Oh, the just 'bitcoinrpc' has "bitcoin-python-async-rpc" as repo name, so maybe I can use that. Or "python-bitcoin-async-rpc". Not to be confused with "python-bitcoinrpc-async".... <hugohugo>Hmm no, I should just discard that "bitcoinrpc" one, because it wouldn't surprise me if some of those are scams... <vagrantc>also curious about weather the release team would find it acceptible to merge those at this point ... <vagrantc>ACTION seems to see some pedantic clouds on the horizon <vagrantc>i've pinged rutherer (not sure how to ping the whole team) and added a team-release label <identity>probably something like @guix/release-team <vagrantc>and mispelled Rutherther, but not in the issues :) <vagrantc>well ... may as well push to kernel-updates to give CI a chance to build everything current... <oliverD>I'm looking for help with my wifi (I installed guix on a old laptop) <FuncProgLinux>oliverD: It doesn't work OOTB? If it doesn't you can share internet via android phone using USB :) <oliverD>My Network controller is: Aualcomm Atheros QCA9377 802.11ac Wireless Network Adapter