IRC channel logs
2024-02-19.log
back to list of logs
<PotentialUser-65>why does guix pull action downloads all other software (i can understand downloading basic tool chains) like tar, git-minimal, ghostscript. <Kingsy>Hi all, so I am interested in using guix, however after writing the ISO to a usb and booting to it, I get an error that it was unable to find a partition, the partition name is like a UUID. <Kingsy>is there anything special I need to be doing to get guix installed? I just downloaded the iso and copied it to a usb stick with rufus <Kingsy>then obviously I booted to it in legacy mode without UEFI <Kingsy>weirdly after the grub menu too, it says that it cant find "something" <- I cant remember the exact wording, but the item it quotes looks like a date from 1970... which is just very very odd <wigust>Kingsy: Hi. Nothing special, almost like any other distro. I don't understand why do you get the error, but I could recommend to try Ventoy instead. <Kingsy>wigust: should I be using UEFI or legacy? both should work no? <Kingsy>wigust: ermm waht the in the world is ventoy? I just downloaded that but it seems like it wants me to install ventoy to the USB rather than the guix image/! <Kingsy>ok will reboot and try this out. thanks for the heads up on ventoy btw. this is very cool <Kingsy>wigust: ok that worked, got a different issue though, my laptop uses a intel wireless chip that doesnt seem to be supported, is tehre a way of loading non free wifi drivers so I can install? <wigust>Kingsy: probably, but we don't advertise non free things to the people here <podiki>PotentialUser-65: those all seem pretty basic to me as well: tar to handle archives [you need to unpack source or substitutes you download], git as well to get sources, ghostscript probably to build docs [eg basic tools docs] etc <apteryx>got to texlive-bin on core-updates: configure: error: cannot find/use gd <apteryx>fixed by deleting libtool archives from gd <jfred>Hmm. Odd. I've just tried using guix home on a tablet running postmarketos with plasma mobile, and when I `guix home reconfigure` plasma mobile fails to start on boot. If I remove the profile symlink that `guix home` creates it starts up just fine. Trying to figure out why... <apteryx>has anyone tried to update binutils 2.42 on core-updates? <futurile>Q: anyone know if the bordeaux build farm is stuck? I've been waiting for a build all weekend - it looks like it got jammed on the 17th for an i686 build <futurile>I thought there was somewhere I could see the build farms status - but I can't find the link now <cbaines>futurile, do you have a link to the build? <cbaines>so the priority for that build is 300 <cbaines>builds for the rust-team branch started a few days ago, so this might be what you noticed <adanska>Hi, just wondering: whats the purpose of bordeaux? is it just another, seperate build farm or is it complementary to ci.guix.gnu.org (beyond just being a backup source of substitutes)? <jpoiret>adanska: it's separate and complementary <jpoiret>it doesn't run the same software, and also hosts QA <cbaines>adanska, it's meant to provide substitutes like ci, and also enable QA (by building things) <graywolf>Hello :) How should I sent patches for a reported bug? To the bug address? Will the CI pickup the patch despite it not being set to guix-patches? <cbaines>graywolf, if the bug is open against guix-patches, then that should be fine <cbaines>if the bug is open against a different package, I'd open a new bug against guix-patches and send the patches to that <graywolf>How can I tell the package on issues.guix.gnu.org? <graywolf>Ah, on debbugs I see package guix, so I will just sent a patch as usual <graywolf>And one more question, where should bugs of issues.guix be reported to? <futurile>cbaines: OK - so I think you're saying it's 'normal' that the build started being processed on the 17th (and today 2 days later it's still waiting). The reason it's confusing to me is that I was looking at this: https://qa.guix.gnu.org/patches <futurile>cbaines: and it's being sitting in a state of 'preparing' for 2 days <futurile>cbaines: clearly '300' means something like ... 'gonna be a while' <futurile>cbaines: as the queue on that page hasn't been moving I started thinking things were broken <futurile>cbaines: is there any way to more accuretly know when a build might actually take place? <efraim>I'm in your CI, using all your cycles <cbaines>futurile, not currently, although it should be possible to make better predictions <cbaines>we can also tweak priorities if builds aren't happening in the right order <futurile>it's just a review, I don't think it necessarily deserves bumping up. It's more that 'as a packager' I don't know when my builds likely/estimated to happen <futurile>as it entered the 'prparing' state on that page, I was thinking 'oh it's going to happen now' - but it just sat there for 2 days <cbaines>futurile, on a more practical point, I'm not sure adding the usertag has worked <cbaines>I think the email needs to go to control@debbugs.gnu.org and probably also needs to specify user guix <futurile>cbaines: yeah I spent all weekend trying to get it to work <cbaines>that page should have instructions that work <futurile>cbaines: I get failures trying to send to control@debbugs.gnu.org - it looks like an error message is coming back from the debbugs instance <futurile>cbaines: I tried it with multiple email clients <cbaines>right, I wonder if that's something to do with the problems with opening new bugs... <cbaines>maybe try again as I think some things on the debbugs end have been fixed <sham1>Welp, docker no longer works <futurile>cbaines: probably - I noticed that civodul always sends to control and nnnn@ so that was my last attempt <efraim>ghc-7.6 is proving harder to build than I expected <sham1>Welp, to document to posterity, since the channel is logged: if after a system reconfigure docker starts talking about "unknown runtime", just remove the container and try again <efraim>anyone have a multilib toolchain lying around? I'm wondering if something like that might solve some issues on arm <ayatsfer>hello, what is the package for cargo (rust)? <ayatsfer>so that I can get it in a shell with specifications->manifest <spiderbit>Hi, I thought I configured my guix to use another branch as guix / main upstream, but with guix pull it seems to still pull from master <civodul>spiderbit: hi! ‘guix pull’ honors ~/.config/guix/channels.scm first <spiderbit>it says authenticating channel guix commits 9... to 7d6550e <spiderbit>thought if I start guix pull as user X with sudo <spiderbit>like that just with the normel guix url and introduction art <spiderbit>civodul is the problem with the make-channel-introduction do I need a different commit there? <spiderbit>I used guix pull --allow-downgrades at some point, I think because it complained but I did not touch since then (a few days ago) the channels.conf <spiderbit>so why did it seem to work back then but not now <spiderbit>and why does it pull from nonguix but not from this "flat" branch <spiderbit>it's like it reads from a different channels.scm <spiderbit>if I do guix pull as user without sudo it does pull I think the right stuff <spiderbit>I see in /root/.config/guix is another channel.scm <spiderbit>my next problem will be how do I configure eudev to use my hwdb file: <spiderbit>Do I have to copy the file in a directory? $(udevlibexecdir)/hwdb.d ? Or is there a config option defined I don't really see that in that definition but I did not package a lot yet so maybe I am blind <spiderbit>and if it's the former what would be $(udevlibexecdir) <spiderbit>es ist halt selten aber dann muss man hier auch nen kernel upgraden <spiderbit>weil guix ja normal nur mit libre kernel kommt <spiderbit>und ich aber ein repos brauch für normalen kernel <spiderbit>und dort sind dann glaub nicht immer substitutes oder nie nicht ganz sicher <spiderbit>ups sorry posted last messages in wrong chat <apteryx>did anyone tried binutils 2.42 on core-updates? gash limits perhaps? <lispmacs[work]>hi, I had some *very* basic questions about midi synth in Guix. Wondering if maybe there is an enthusiast here who could private message me <apteryx>efraim: did you try using mold to link our rust builds? <apteryx>it'd probably make things a bit faster <efraim>nope, but that sounds like an interesting idea <apteryx>i've updated it to 2.4.0, will push that soon <efraim>I can test it out, but I already have rust-team building on CI so I'd like to not switch it right now <apteryx>don't worry, it's just a random idea <apteryx>it'd not allow rust to build on i686 still so... hm <roptat>I noticed an issue with Korean, where all characters are printed on top of each other. Does it happen to others, say when viewing https://guix.gnu.org/ko/ <roptat>when I copy and paste in a terminal, they show up correctly <roptat>so it's really a font issue, but I'm not sure how to debug this... <ieure>roptat, What program are you viewing that page in? <apteryx>rekado: what would you think of de-registering hydra-guix-129 as a build machine, and opening it up as an offloader to sysadmins or select guix committers? or perhaps we have a better machine for that task? <roptat>I also have the issue when I try to read Korean in Libreoffice <rekado>apteryx: I don’t have an opinion either way, as long as we don’t hand out SSH access to these machines. <rekado>129 is privileged among all build farm nodes, isn’t it? Do the build nodes permit SSH access from 129 (like they do for the head node)? <spiderbit>(format port "hardwarelibdir = $(udevlibexecdir)/hwdb.d\n") <spiderbit>so would that be something like /usr/local/libexec/eudev/hwdb.d/ <spiderbit>what's the easiest way to echo the content of this variable: <spiderbit>I somehow doubt that I can just put the hwdb file there because udevadm --update can't write in it's package directory and I doubt that you have to put it and somehow triggering the rebuilding of it <spiderbit>also for some reason it still seems to point to eudev 3.2.11 when gnome-team eudev version should be 3.2.14 <roptat>spiderbit, maybe add a (throw 'something) after that, and use guix build --keep-failed, then look at the result in Makefile.am? <roptat>ah no, nevermind, it's printed into Makefile.am <spiderbit>first I have to check if I even have now gnome-team version because only that version supports hwdb files <roptat>I mean it's not expanded at that point <spiderbit>it says guix c692808 but branch still master <roptat>I think it will install to /gnu/store/...-eudev-.../lib/udev/hwdb.d <roptat>you need to clone the repository and checkout the gnome-team branch <roptat>there should be a way to specify a branch in your channels.scm <spiderbit>ok when I do guix pull it says 622df which would be gnome-team branch <spiderbit>but with describe it says something else and well I still need the correct version of eudev 3.2.14, maybe --allow-downgrades does that <spiderbit>well it then computes guix derivation for x86_64 and then "nothing to be done" <spiderbit>do I have to make it the old commits somehow forgotten that he pulls from the new branch <spiderbit>it seems to me that guix pull pulls the correct branch <podiki>guix pull doesn't change anything but update guix (and the package definitions) itself <podiki>perhaps it would help if you share what exactly you are trying to do (maybe you did earlier?) as perhaps you are getting lost in some weeds that can be avoided <spiderbit>and because that was not possible in older eudev because of a bug <spiderbit>expected that my system is now on gnome-team HEAD <spiderbit>I did basically that except it's the same URL <lispmacs[work]>hi, if I wanted to start out with a really simple, pure profile, that had just enough in at that I could interact with the command line and file system, which packages would I need to include? <spiderbit>Ideally I would only cherry pick the eudev version but it seemed easier to switch the branch... especially not very interested in managing my own git fork of it at least yet... <efraim>apteryx: I was able to use RUSTFLAGS to set mold as ld, but gcc didn't know what to do with it. apparently we need a newer gcc or to use clang <spiderbit>ok with sude guix pull -l I see the last generation with branch gnome-team <spiderbit>shouldn't that be enough if I then run sudo guix system reconfigure... <podiki>you should just use sudo only for reconfigure <podiki>e.g. guix pull; sudo guix system reconfigure.... will update guix and use it for the system; sudo guix pull probably update's root's guix (and generally stay away from root's guix, it is confusing and leads to permissions issues, just use sudo for reconfigure) <spiderbit>is there a reason why I can't instead of sudo not call reconfigure as root or is that possible, too? I thought it failed but might be wrong. <spiderbit>and is there a reason why root even works with guix commands especially pull <podiki>by default on guix system sudo will use user's guix (environment) <podiki>it just can get confusing and people end up inadvertendly using root on their user's directory <podiki>you can do things multiple ways of course, i'm just telling you what i think is easiest and less likely to cause breakage <podiki>nothing disastrous, but easy trap especially if you don't realize <podiki>guix is not like other systems where you need root to install things. we only need root to write the bootloader i believe <podiki>so best to embrace that and use root/sudo less; tis good practice i would say <dissoc>is there a way to deploy or generate an image without sending a file into the store? something like a private key for example <spiderbit>podiki but that is still only the half I need afterwards make it eat my hwdb file <podiki>spiderbit: that i don't know about; not familiar with those eudev things but good luck! <spiderbit>Well I guess a reason I forget sometimes what I am supposed to be run as user and what with sudo with of course lack of some background knowledge <spiderbit>is because system upgrade can take so extremely long that I seldom do it, that was especially true on a netbook I installed it a pull could literally take days :D <spiderbit>but even with my older thinkpads old dualcore i5 it can be a bit slow <spiderbit>especially if not all substitutes are up to date <dissoc>podiki: thanks, looks interesting. i havent seen this before. i will try it out <podiki>let us know how it goes! definitely a feature people would like in guix <apteryx>efraim: you should be able to simply add mold-as-ld-wrapper to native-inputs <apteryx>its binary is 'ld' and it's compatible with the one it replaces on PATH <jackhill>is it possible to build an image for the pine64-lts from an x86-64-linux host? <apteryx>efraim: otherwise for the -fuse-ld=mold to be recognized that was added with GCC 12 (but not necessary with the "as-ld-wrapper" trick <apteryx>rekado: I'm not sure if 129 is privileged that way, I don't think so. <apteryx>lilyp: my memory fails me; which environment variable do we need to wrap for GI typelibs to be found? <podiki>as sham1 pointed out, docker can stop running after reconfigure/reboot complaining about "unknown runtime specified /gnu/store/...runc.../sbin/runc" which exists but i guess something changed on reconfigure? <podiki>anyway, for docker compose: docker-compose up --build --force-recreate -d will do it (force recreate the containers) <podiki>another reason for me to move them all to our oci-container-service, and upstream my change for containers to run on same internal network by default (like docker compose) <sham1>Yeah, it's probably a new docker install that happens on the reconfigure, which in turn means that the old runtime as stored in the container no longer matches the one in docker <dodoyada>are guix manifests only really package lists? can you use them for providing giux shell options? <sham1>They're only package lists IIRC <sham1>Might be nice if you could do more with them, but eh <podiki>i believe they are still guile code, just need to evaluate to a manifest at the end? <podiki>but no, no interaction with guix shell currently. some talk about a way to better pass options to guix shell has been discussed and would be nice <euouae>has anyone managed to boot into guix from kexec? <euouae>I'm naively trying to do what works in debian but it won't work on guix <sham1>Yeah, the only thing a manifest can do is specify packages for guix shell to use. Automatically, if manifest.scm is the file name <euouae>e.g. `kexec -l /gnu/store/.../bzImage --append=<stuff from /proc/cmdline>' and then `kexec -e` <sham1>I feel that kexec might go very wrong very fast <dodoyada>I would love to use guix as a build system, it seems so made for that <euouae>I've tried this from system-rescue but I've also tried from within guix with `--reuse-cmdline` <sham1>Well, how does kexec deal with things like the init stuff. I honestly don't know, so I'm mostly clueless about if it'd actually be a good idea or not <apteryx>maybe wrap-all-programs from glib-or-gtk-build-system should wrap also GI_TYPELIB_PATH? <euouae>sham1, I'm more clueless than you are <euouae>sham1, what init stuff? I should study that more <euouae>I hate being pinned between a rock and a hard place, but that's where I'm at <sham1>Well like, does it redo the whole pid1 launching stuff? Or does it retain the existing processes? Or something in between <sham1>And I wonder how shepherd specifically would cope with any of those <sham1>So really it just saves you the actual power cycle. I know that for servers that's huge, but yeah <euouae>no it doesn't just save you a power cycle -- it enables you to do stuff that I'm interested in <sham1>Now I'm curious. So... enlighten me! What does it give you <euouae>in particular I want Guix + Argon2 kdf, and because kernels are in /gnu/store, there's two ways to do this: full-disk encryption with GRUB unlocking or USB boot (from any distro), unlock, and kexec into guix <euouae>Argon2 is an algorithm for hashing the password you provide at boot to unlock your hard drive <euouae>My first approach was to try to modify GRUB actually, but I'm not getting much help on the mailing list. This is a hail mary right now because I'm even less acclimated to kexec <euouae>IMHO the right thing to do is fix GRUB but I don't want to deep dive into their source code if the maintainers aren't telling me what the plan should be <euouae>I'm going to summarize the issue on the guix mailing list <sham1>Yeah, I also reckon that it'd be the better choice of action, but if they don't respond then what can you do <jpoiret>is there any error message or anything? <jpoiret>also please don't `kexec -e` on a live system, you need to make sure everything is unmounted first <euouae>Hm, not sure if the umount isthe issue, but no there's no error, qemu freezes <jpoiret>well, you have to look in the grub configuration to find out where it is <jpoiret>by that i mean in /boot/grub/grub.cfg <jpoiret>euouae: well not unmounting the filesystems can cause data loss <euouae>make sense, I'm doing it from a readonly liveCD though <jpoiret>a guix livecd? might be harder to find the initrd <jpoiret>also if you're using another distro's livecd /proc/cmdline is *definitely* not the thing to use <jpoiret>you want the kernel cmdline in the grub configuration instead <jpoiret>i've never tried kexecing into guix myself but i'm interested <jpoiret>you can even kexec into multiboot kernels huh <jpoiret>among the things i was wondering about were for example CPU microcode updates, whether they were possible when kexecing <euouae>Nah I meant, in which part of the boot process are they loaded <dodoyada>is there a good guile package minimal demo that shows how to set up a project with a simple repl setup + guix packaging? <euouae>dodoyada: a new package or modify an existing package? <jpoiret>euouae: haven't looked that deep into it. but even then do the CPUs themselves allow multiple microcode updates per power cycle? <euouae>either microcode is built-in to the kernel loaded or it is in initrd