IRC channel logs
2024-12-18.log
back to list of logs
<zjabbar>Hey #guix! I wanted to ask what happened with the Python packages recently. I don't want it to sound like I'm pointing fingers. I imagine the tests went well in the ./pre-inst-env, so I think this is an interesting engineering challenge. <zjabbar>I tried looking at the IRC logs to see if there was some discussion about it. Would supporting multiple versions of Python packages be a headache or a boon for robustness? <unmush>today I discovered that while mono does not have line numbers in backtraces by default, pnet does <sneek>Welcome back apteryx`, you have 1 message! <sneek>apteryx`, rekado says: Thanks, I have rebased python-team on top of master. <apteryx`>(#fvector->list: expected vector, got ~S#f#f) <apteryx>I'll push #70581 in a few minutes in no one objects <csantosb>Do we finally have gitlab guix container images for real ? ... <jlicht>I'm planning to push the node@20 update later today, if no other merges or pushes ruin the fun <efraim>do we also finally switch from using old-node to node-20 for packages? <jlicht>efraim: If I did my job well, yes <jas>hi! what is the most simple package to build and install in guix? i'm working in a minimal image. 'hello' depends on gcc... is there some guile-only package without any C dependencies? <jas>efraim: thank you! i will try. yes, a data-only package seems best <jas>hmm. it still depends on trivial-build-system which pulls in a lot. is there a simpler package, that doesn't depend on any build system? <jas>i just want to prove that 'guix package -i FOO' works in a really minimal guix image <divya>jas: That'll be just fetching a pre-built binary then. <divya>Defeating the point of packaging it in guix :) <jas>...without substitutes :) <efraim>'e '(@@ (gnu packages bootstrap) %gcc-bootstrap)' <efraim>-e '(@@ (gnu packages bootstrap) %gcc-bootstrap)' <jas>maybe what i'm after doesn't make sense. i have created a small image using 'guix pack' and want to get 'guix package -i' to work within that image <jas>so maybe my real problem is getting substitutes to work. i got an error: substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <jas>it seems some public key is necessary, but how to add that to a 'guix pack'? <divya>jas: What packages does the profile of your `guix pack` have? I am afraid it'll depend on that. <jas>i can add packages to the pack, but want to keep it minimal. maybe pulling in gcc is unavoidable? <jas>right now I run: guix pack guix bash-minimal coreutils-minimal grep iproute2 findutils inetutils gzip libcap net-base shadow lndir --save-provenance -S /bin=bin -S /share=share -f docker --image-tag=guix --max-layers=8 <jas>even a 'guix package -i grep' pulls in gcc etc wanting to rebuild it, because substitutes aren't available <unmush>methinks your problem there is that the package named "guix" is inherently different from the guix that contains it <unmush>consequently it's not surprising that your guix's grep may be different from your guix's guix's grep <unmush>you may be interested in -e '((@ (gnu packages package-management) current-guix))' <jas>unmush: yes that sounds like an idea. i'll try to rebuild these images and do some 'guix describe' checks <jas>dariqq: thank you! yes, that is what i'm missing <jas>unmush: you were right -- 'guix describe' from within the 'guix package' image points to an earlier commit compared to the 'guix describe' that ran 'guix pack'. i don't understand how that happens though <unmush>if you look in (gnu packages package-management) you'll find that there's a (define-public guix (package ...)) just like with any other package <unmush>if you thought "hm, this commit listed here seems old! I'll fix it!", you would do so by editing the commit specified, staging your changes, committing them, and maybe sending a patch to guix-patches. <unmush>you would then run 'guix pull' to get your updated guix with the newer guix package, look at the commit listed there, and say "hm, this commit listed here seems old!" <unmush>tl;dr - the newest guix package that can have its commit listed directly is already at least one commit old <jas>thanks. everything makes sense except my brain isn't wired for this intuitively <unmush>current-guix does a runtime lookup or something like that to figure out the actual commit representing the current guix instead of having it be statically-defined in a file <mccd>Heya, is there a way to set a package to always use the latest commit? <mccd>With go-build-system, the docs say that you need to set ImportPath. What is unclear to me is what that should be set to if you have a local install <mccd>all examples use github.com/something <homo>of all arm and riscv hardware in gnu/system/images/ is there any that is freedom-respecting? on #fsf I heard that visionfive2 requires non-free software for RAM <homo>also considering the image is for visionfive2 specifically, does it mean riscv has same problem as arm that it's impossible to have same system image for different hardware or otherwise hardware gets physically damaged? <efraim>all of the system images have been tested to work on their respective hardware using software provided in Guix <efraim>it's possible that there can be a u-boot -> UEFI option using grub-efi, but we haven't worked it out yet <homo>efraim: I mean there are pine64 star64, pine64 ox64, pinetab-v and roma as hardware with risc-v processor, in arm world there is technical limitation that forces to have separate system image per hardware or else hardware gets physically damaged, is that also true for riscv if there was a single image for all riscv hardware? <efraim>If they need a separate bootloader then they'd need a separate image for each board <homo>I don't know the technical details behind that, but that is why replicant for example has different system image for every phone <efraim>if we can install u-boot to SPI or to an early part of the SDcard and then have a standard grub image later on the sdcard then we could work out something to have 1 image <homo>according to what I heard on #fsf, there are no freedom-respecting riscv hardware, but there is freedom-respecting arm hardware, it would be disaster to get riscv hardware just to discover that it requires proprietary software to function <homo>searching on the internet is not helpful when results contain "linux", "bsd" and "open source" despite that blobs are included in drivers <mccd>Ah, it seems that when I use local-file and go build system. The files are never copied over - src is empty. Should I then replace the phase unpack and move over the files manually somehow? <jas>which locale-related package is needed to fix this error? Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'. <jas>it happens when doing 'guix pack' and adding the 'nss-certs' package, it seems to contain a filename with non-ascii: (symlink "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny.pem" #) <Rutherther>jas: I dont really know how to fix that. But why do you need to add nss certs? Distros typically provide their trusted certs, and this would probably be just re-adding a lot of the same ones <jas>i'm not on any other distro, this is a native guix container image. wget fails complaining about CA certs <csantosb>jas: out of curiosity, did you try the `guix system image` approach ? <csantosb>Seems that you have way less concerns that way (but probably some others ...) <jas>csantosb: yes, i did set that up and i think you are right that it solves some of these things, however it made the container really large. so i suppose i'm reinventing the sheel going from 'guix pack' into a usable system... <csantosb>jas: by the way, the `copy-build-system` suite of packages are dead simple <jas>i solved the nss-certs problem: export LANG=C.UTF-8 before starting guix-daemon... <csantosb>You're already probably aware of the way sr.ht produces the guix image, using the previous one to create a new one <csantosb>I guess they push the original one by hand 🤔 <jas>thanks for the link! seems like many has had this need <jas>yeah, i was just going to ask about how the first one was created <csantosb>Thanks for your effort: having ci containers in forges is a #2 killer feature for guix ! <csantosb>jas: chicken and egg problem, not a big deal I guess: build image locally, push it, build a new one daily in its latest version <cbaines>I'm seeing some open-fdes permission denied log file errors with the shepherd <cbaines>both with some system tests, but now with a actual machine as well <cbaines>these appear to happen at boot and cause the shepherd to stop responding <cbaines>at least in the system test case, it didn't appear to happen all the time <jas>csantosb: i really like automating the initial image creation -- having an untrustworthy initial process seems fishy. doing that was simple if we jump from debian <csantosb>How old is guix under debian when you do a `apt-get install guix` ? <jas>csantosb: just 80000+ commits old <jas>the 'guix pull' takes ~20 minutes, but i store the output in a container image and upload that. so it is quick to re-use the same 'guix pull' image <csantosb>(related to my quest for releases ... this is a huge block for people willing to use guix) <csantosb>jas: correct me if i'm wrong, but the `guix system image` is reproductible, whereas building from "debian:trixie-slim" and "apt-get update" is not ? This is the drawback I can see. <jas>csantosb: i'm not confident of anything here -- but how do you create the system that runs your 'guix system image'? that's the concern i'm solving via debian:trixie-slim <jas>i could add a stage0+stage1 solution where i re-run the guix-pack command in the resulting guix container -- for comparisons. is 'guix pack' reproducible? <cbaines>hmm, also having ssh problems, sshd: no hostkeys available <jas>so maybe an good setup would then be: <jas>1) launch a debian:trixie image, run apt-get install guix, guix pull, store that as a container for caching <jas>2) launch that newly built debian+guix container to create a guix pack and store that as a container <jas>3) launch this 'guix pack' container and produce another guix image and upload that as a new container <jas>4) use the previous container to build your software in a GitLab pipeline, accessing 'guix package -i FOO' etc <janneke>ACTION goes from a gcc-12 that builds to a gcc-12 that works <jas>right now i am skipping step 3, building GNU Hello using the guix image created in 2 <janneke>at the cost of yet another world rebuild <janneke>bah, a "fix" for 11.4.0 apparently broke all non-gcc-14 c++'s <janneke>hopefully 11.5.0 works without the "fix" that i assumed would be needed for all non-gcc-14's <csantosb>jas: in 3) you use `guix pack` or `guix system image` ? <csantosb>by the way, using debian as origin is not untrustworthy too ? <janneke>yeah, gcc-11.5.0 no longer needs -Wno-error=incompatible-pointer-types and -Wno-error \o/ <janneke>ACTION goes to remove the uninformed gcc-build-with-gcc-14.patch and remove the gcc-11 enhancement from gcc.sh again <janneke>wow, this gcc-11.4.0 bug (and my wrong approach to fix it) cost me at least a week, and at least 3 world rebuilds <apteryx`>janneke: is there a reason for qemu@7 instead of latest in hurd templates? <janneke>apteryx`: yes, the 64bit hurd needs --machine q35, which doesn't work or isn't availale in qemu@8 <apteryx>am I supposed to see a login prompt? <janneke>qemu@8 has been problematic in general for me, it's riscv64 emulation is fubar <apteryx>I only see 'irq handler [11]: newdelivery port ffffffffdfea1688 entry ffffffffddc6bc00' <janneke>if you are using the regular qemu gui, there should be a login> <janneke>the 64bit hurd sometimes fails to boot properly... <apteryx>there seems to be q35 in qemu@8, at least it's in the doc and the machine boots to the same point when using --machine q35 <janneke>apteryx: okay, well if it works, then great :) <janneke>ACTION didn't get the 64bit hurd to boot with qemu@8.2.2 <apteryx>well, so far it doesn't for me with any qemu :-/, but it works at least as much :-) <janneke>apteryx: you do build with something like ./pre-inst-env guix system image --image-type=hurd64-qcow2 --image-size=25G --no-offload gnu/system/examples/devel-hurd64.tmpl <apteryx>I see the GRUB screen, it boots, I see a few guile messages, than that irq handler thing and it seems to hang there <janneke>apteryx: so you're using the 64bit versions of qcow2 and tmpl? <janneke>ACTION hasn't tested the past (two?) weeks, but it should be ok <cbaines>when I add unrelated services on Guix, ssh breaks :( <janneke>apteryx: i always use (kernel-arguments '("noide" "console=com0")) because i don't like gui's :) <janneke>apteryx: qemu@8 works for me too, so now i don't know why (or even if) qemu@7 seemed to be necessary <janneke>ACTION realizes they work from a different machine and goes to check on the original machine <apteryx>janneke: I used the command from bare-hurd64.tmpl <apteryx>janneke: so you do not get any login prompt right? <apteryx>perhaps it works, I haven't poked the mapped ssh port yet <janneke>apteryx: indeed, i don't, because i use --no-graphic etc <janneke>maybe i should try the gui again, for reference <apteryx>try without the -nographic option; you'll see a black screen with nothing I think <efraim>that sounds like when I got asked if the graphics work on riscv64. I had to admit I'd never hooked a screen up to the devices <apteryx>janneke: ssh -vvv -p 10022 root@localhost doesn't work for me <apteryx>but maybe because of authentication or something: kex_exchange_identification: read: connection reset by peer the moment I kill QEMU <apteryx>(from the ssh client side trying to connect) <janneke>ACTION goes to try the exact build instructions using bare-hurd64.tmpl <janneke>core-packages-team world is rebuilding anyway... <apteryx>If I add -nographic to the qemu invocation, I can't get passed the GRUB boot it seems <apteryx>I tried waiting or hitting C-a b, to no avail <janneke>yeah, you need console=com0 for that <apteryx>I'll give it another shot some time later, it's exciting stuff anyways :-) <janneke>it's so terrible that cannot be passed from the command line somehow <janneke>also: using timeout 0 in the grub bootloader helps <janneke>i wouldn't know how when building from a image <janneke>it works when pointing to a (linux)kernel and initrd <janneke>"it works" meaning: there is a qemu kernel-arguments option to pass... <orahcio>Hi, I am reading the guix manual on greetd-service-type section and guix has no initial-session for greetd, like on it wiki, there is some way to do autologin on greetd? <bjorkintosh>alright. after sudo apt install guix, I did guix pull. it's super slow, and ends with uix pull: error: Git error: SSL error: received early EOF <orahcio>homo: thanks, I think on guix we need to change defaul-user and the sway config for the greetd need to be the config file of the default-user, but It is not a good way. I will try the guix way with password login on greetd and after this I will try the getty way with autologin. For now, after try sddm and gdm with autologin, the gdm wayland was the best choice for me, the sddm wayland results on no graphics in my laptop and I falled on tty <Rutherther>bjorkintosh: probably not. It shouldn't really end like that. early EOF could be some kind of network connection being dropped, so you can try rerunning <bjorkintosh>I have 1 gig fiber, so I doubt it's a network issue. <Rutherther>bjorkintosh: nobody says the issue has to be on your side <Rutherther>I don't know what you mean. The substitute servers are not always reliable, ssl errors happen spontaneously <Kimapr>how 2 install manpages for libc functions and stuff <homo>orahcio: I think default user is a privelege separation mechanism so that greetd doesn't run as root <civodul>Kimapr: hi! try “guix install man-pages” <homo>basically greetd user has enough priveleges to check that password you type is correct <homo>services run as root are security nightmare <cbaines>I seem to have broken shepherd enough that my sshd processes are running as the httpd user, and I don't know how I've done it <Kimapr>civodul: that appears to be exactly what i'm looking for. thanks! <Kimapr>i'll also install man-pages-posix <orahcio>homo: yes, that's why greetd on guix needs the initial-session like on the original greetd project, we can put the auto-login user and we don't need to change the greeter user, but acctually greetd on guix is usual just for password login <homo>to me dm is basically for fancy eye-candy graphics while typing password, so I don't understand why would anyone want a dm when doing auto-login <orahcio>homo: I understand your point. It is about possibilities, when the laptop sleeps maybe we want to put the password just after this. But I want to leave of my graphical profile and I need a screen with login just at this moment. It is more because I got used to a graphical login to be there when I "need" it <homo>orahcio: swaylock and other programs depend on sway's and other compositors' protocol to lock screen, from what I know gnome is the only compositor that uses dm for screen locking <homo>I don't know how kde does it, but sway doesn't rely on dm for lock-screen <orahcio>homo: yes, I think I stayed in the plasma world for many years, the KDE does it via dm too, always a linux distro with KDE comes with sddm or lighdm. I will try also put autologin with just getty and use swaylock when I want to lock the screen <orahcio>but greetd project comes with auto-login, I think guix also needs to give the original project possibilities <homo>orahcio: you can bind a key in sway to suspend and lock screen <jlicht>what would be the best way to alias 'node' to 'node-lts'? About to push the update, but forgot to ask how to do this :# <homo>orahcio: maybe reading how to use swayidle will help you to lock screen automatically when putting laptop to sleep <orahcio>homo: nice, on my last system I did a greetd auto-login, when I quit sway a tuigreet screen asked for the password. I was trying to do the same on GuixSD now <homo>I think for that you'll need to adjust gnu/services/base.scm and send a patch <homo>but anyway, compositor devs disagree on how to handle everything, so whether you need dm or not depends on compositor <orahcio>homo: swayidle I like to use for just turn off my monitor, I don't like automatic lock screen. I will learn how to send a patch, the GuixSD is a great system and in slow steps I want to contribute with this project <homo>actually thinking of that, I think about possibility to use getty to auto-login myself and immediately run swaylock, that way I can please my eyes while typing password without running display manager... <homo>and while typing password, a lot of necessary programs can start in the background without waiting for them to start after typing password <homo>the worst thing that can happen is swaylock crashing <orahcio>homo: nice idea, greetd on guix can run sway for login screen <orahcio>but of course, it will be one sway for password screen and after another sway session for your profile <homo>but that way it won't start programs before login <homo>and it's nice when everything is loaded as quickly as possible <bjorkintosh>Rutherther: I fixed my problem by purging the ubuntu version of guix and installing via the shell script. <homo>but, I am gnome user, there is no other compositor that gives same workflow as gnome <homo>I'd be happy to switch to lightweight replacement without sacrificing the workflow <janneke>sneek: later tell apteryx; hah, you already made two of the same fixes to the hurd examples as i made locally, thanks! i've pushed a comment about the login prompt not showing <janneke>sneek: later tell apteryx: i've tested these exact instructions and they work for me <debman>im trying to install guix OS and none of the files for ~/.guix-profile are installed, so im wondering if I used a bad image, did something wrong, or the install didnt work generally <debman>i just used this "guix-system-install-1.4.0.x86_64-linux.iso" installed everything, selected to install xfce, but none of the files for the guix package manager, or environment variables were installed, which prevented it from working with a default install <debman>so I tried manually adding them as the "hint" and "info guix" instructed, but it seems like it's totally broken, and I need to reinstall, because something went wrong <homo>have you run "guix pull"? <debman>yea I did it last night, and installed a few packages <debman>but I think everything went into the wrong directories <debman>I was using sudo guix for everything <debman>the problem is: all the environment variables, and files such as ~/.guix-profile were not installed <Rutherther>you shouldn't pull as sudo if you want your guix instance you use to be the one pulled <homo>"guix pull" is supposed to be run without sudo, it doesn't need root priveleges <debman>but I think something went wrong with the install <Rutherther>but that's expected. Only after you relogin or manually source etc profile, you get the ~/.guix-profile <debman>im wondering if I didn't select the appropriate option during the install <Rutherther>you first need to actually install something and only then you will get the appropriate variables after relogging <debman>right but all of the other files too are not present <debman>and every time I did an operation, it wouldnt create the files <debman>so I tried making them manually, entering the environment variables manually <debman>all of the files listed in info guix <debman>and suggested as hints, after using say guix install <Rutherther>there is a ton of files listed in info guix... please show whole command, its output and what files you expect, but aren't there <debman>its kind of difficult because now I am in a live cd <debman>because the default install has no web browser <debman>sudo guix install midori (to get a web browser) <Rutherther>if you did sudo guix install vlc, vlc should appear in /root/.guix-profile profile <debman>and it hinted I should source my roots home directoy which confused me <Rutherther>as other user you of course don't have permission to access that, so you shouldn't use sudo guix install to install something for your user <debman>i tried guix pull this morning and it hanged at 19%.. <Rutherther>also you don't need to install stuff to use it. guix shell will work every time, so you could've just did "guix shell midori" to get your web browser, no need to install it <debman>so maybe Ill just have to try installing some basic programs without sudo <debman>so again, I did sudo guix pull, i tried running every command I could <debman>and there was no /root/.guix-profile created <debman>or any of the profile directories <orahcio>homo: The default workflow of gnome can be reproduced by KDE plasma or mybe even sway/i3 with some aditional tools, but will need some time to configure everything, I also like default workflow, but I leave gnome on the big transition from the 2 to the 3 <Rutherther>if that file in home ~/.guix-profile is not created (althought it should be), just create it yourself, it's a symlink to "/var/guix/profiles/per-user/$USER/guix-profile" <debman>ok thats why Im wondering if my install didnt work properly, because it seems that expected behavior isn't taking place on my system <Rutherther>if we assumed you had disk corruption/ram corruption etc., it's very likely there would be complete failure of something, not just one missing file and no errors in the build/substitution <debman>so could you just tell me the default expected route for a new system install... such as: FIRST run guix pull, guix upgrade, then I can install packages normally? <debman>also can you tell me if it's possible to install to an f2fs drive, instead of ext4, or those supported in the installer, I tried it last night, and it crashed the installer at the partitioning stage <Rutherther>1. guix pull as your user, 2. relog or manual source of ~/.config/guix/current/etc/profile, 3. guix install as your user, 4. relog or manual source of ~/.guix-profile/etc/profile, if any of those home profiles didn't exist after running command that should create them, look into /var/guix/profiles/per-user/$USER, where the profiles should be. Additionally, it's not completely necessary to do steps 1 and 2 if you are fine with running very outdated... <debman>ok thank you so much ; D I love guix <Rutherther>if you were unable to find the profiles, you can always just revert to "guix shell" which will work (give you the package you want inside of the shell), unless you did something really bad in your bashrc or your system is broken <Rutherther>(something really bad in your bashrc would be something like "export PATH=") <debman>so after the first guix install I should relog, and then I can just install packages normally right? <debman>i cant manually source those directories/files, since they don't exist unless I make them <Rutherther>yes, exactly. The profile file first has to exist, only then you will get the env vars. But this applies to every env var added. So for example if you decided to install emacs and emacs packages afterwards, you again need to relog/source when EMACSLOADPATH is introduced for the first time <Rutherther>I doubt they won't exist if you run as your user, but if they didn't, as I said, look for them into /var/guix/profiles, and symlink that file in your home to there <Rutherther>the files in your home are just symlinks that never change <debman>I will try it again thank you for your help... <debman>can I ask u a couple more questions perhaps? <debman>because I have never used guix before so I have a lot of questions <debman>I want to do things such as, install source code from third parties, build a custom kernel and install it, perhaps do things to the system outside of the guix system management system, and personally manage it myself, such as the kernel <debman>I guess it's ironic, because that's the whole point of guix.... but I am used to managing the system, outside of prescribed packagemanagement and systemd system managers ect <civodul>efraim: hey, lemme know if you’d like me to review an updated rust-ring patch; you seemed almost done :-) <debman>how could I... for example, grab some source code from a third-party, and then manage it and install it, using guix? <debman>or if I want to introduce a custom kernel, and drivers, how could I use guix, to at least register their existence in it's scheme <debman>I noticed a lot of standard gnu-utils are not present on the default install of guix too, which confused me <debman>im used to having commands like "clear" and "file" on the system <debman> the last distro I was in, didnt provide man pages... so it was impossible to actually use it <debman>I don't know, but I think it could be something I invent myself <debman>instead of having a remote organization manage my system, I want to manage my own system <debman>its really easy, if the system is designed in such a way, that you can, that is not prohibitive <debman>if I want to install new ram, or a new harddrive, I can unplug them, and plug in new ones, but with modern linux OS's you can't do that anymore <Rutherther>as for kernel, that's more of a question about modifying the already existing package, you probably don't need to package kernel from the ground since it's already packaged. There is a procedure called customize-linux, you can give it the source, config options. <debman>so i typically just ignore distro kernels now, and pull new kernels from kernel,org <debman>if I go grab the 6.12 kernel from kernel.org and build/install it in ten minutes, is guix going to flip out <Rutherther>for custom linux modules it's again packaging them, you can look at examples in the module with the kernel gnu/packages/linux.scm in the guix repository <debman>so can guix manage it's own kernel, how it pleases, and I can just install my own <debman>because there already is a system, besides guix, like the operating system, and I already know how to use that <debman>on many distro's this is not a simple task, such as fedora <debman>there are prescribed methods, and so you have to use the manual methods to slip past their programmed limitations <Rutherther>I don't know what you mean by "going to flip out", and it's also unclear to me what you refer to by guix in that sentence, do you mean the guix system? <debman>so instead of make install, you have to cp the kernel image produced from make <Rutherther>you definitely won't be able to make install almost anything on guix, you need to package it via guix for it to be reliable <debman>I think it should be easy... on guix to just manually install a new kernel, and some drivers <Rutherther>*it will work to make install it, but it can break as guix doesn't know what libraries you are using in there, so it doesn't guarantee those libraries will stay in your /gnu/store, where all packages reside <debman>other distributions are prohibitive for technical complex reasons <Rutherther>it can be easy if you know how to package and edit packages, especially for minor adjustments. If it was something big it can get quite complex <debman>right... so is guix incompatible with typical linux packages? <debman>because of it's file system ... system? <Rutherther>I am not sure what you mean by packages here. Like, you definitely aren't able to run packages packaged for fhs normally. But you can package the typicall packages using guix, and the typical packages are usually already packaged, so you don't have to do anything, just install them <Rutherther>if you compiled something on, let's say, ubuntu, and wanted to run it on guix it won't work by default, you need to do some extra steps for it to work <debman>like a kernel from kernel.org for example <debman>the system libraries are in unique locations... <homo>sneek later tell orahcio plasma, just like gnome, is not lightweight, is more buggy and worst of all in qt and kde world every theme is .so file, furthermore I didn't see automatic creation and deletion of workspaces feature being available anywhere outside of gnome, and that feature alone saves me a lot of time <debman>(it does OS detection which alters it's system of building/installing) <debman>Like I just was using slackware recently as well <Rutherther>that's more about the initrd I think, since that is the thing that knows where to find stuff. The kernel itself should be okay, as far as I know it shouldn't have any dynamic dependencies outside of itself, that's the main issue <debman>which links to source code, at their upstream sources, and makes scripts to help you build/install them <debman>and so grabbing source code, from the innumerable number of projects that support the entire gnu/linux ecosystem and attempting to build them on guix, will not work <look>debman: I am running my own 6.12.4 kernel built straight up from kernel.org (altough I've used guix to build it because... its much much easier than building manually lol) <debman>because standard locations... for say libc, are not present, or have symlinks in guix <Rutherther>you can always make it work, but it can be more work to compile it. It really depends on the program. Some programs unfortunately expect something from fhs, but you can always patch that <debman>so like the entirety of github... is source code, and instructions for building that source code, on linux <jonsger>hmpf, ci.guix.gnu.org seems to lack behind in building evaluations <Rutherther>you seem to be mixing up a lot of stuff into one thing. It's not that simple, that it won't work... what exactly do you think won't work? <debman>other distributions work around this, by making symlinks, to expected locations, for system libraries <debman>well on other distributions, you have a lot of freedom, about how you build your system <debman>using source code, or packages, or prescribed methods, for augmenting it <debman>because of the fact, that they follow the standards, such as the FSH <debman>so packages that build and install, on debian, painlessly, also do so, on arch linux, and fedora, and ubuntu <Rutherther>well most packages are not expecting FHS, they utilize build systems like cmake, or even if they have plain make file they use pkg-config <debman>well im going to discover the answers to these questions on my own... <debman>like there is the guix package repository for example <debman>then there's the entire world, called the internet, of various programs, and source code, and packages <Rutherther>yep, look to the source code and see the patches required for some packages <debman>if we are limited by the guix system deign to only use it's system, we are missing out on the entire world of different options <homo>standard file system hierarchy is simply not suitable for guix, for example, it doesn't let users to have different versions of packages or to not have them at all <debman>i just went looking for a package last night, that guix didnt have <homo>this is not plan9 of inferno where contents of /bin can be totally different to every user and every process <debman>which lets qt apps, use an adwaita theme such as adwaita-dark <debman>it lets you use vlc with a dark mode skin <Rutherther>if you want something to work long time you should package it via guix. If you want to build something and try it out for a few minutes you can still compile it manually, for programs that really need fhs for something you can just enter a container with emulated fhs. But don't expect it to just work after few weeks when you could've already cleaned up your store and the libraries it was using don't exist anymore <debman>it has source code available online, I can go get it, and build it (i just did that on slackware) <bjorkintosh>alright. that was fun. guix is too godamn fucking slow. <debman>so I guess nothing at all will work, without being reprogrammed to work with guix <debman>because everything is in unique locations <Rutherther>yeah, seems no one packaged it and I suppose it won't be accepted as upstream claims it's unmaintained <debman>its simply themes, it doesnt need maintenance.. <homo>it does need maintenance because in qt world every theme is a .so library <Rutherther>you don't need to push it upstream, you can have it locally <Rutherther>just saying that it probably won't appear in official repository <debman>I will discover it on my guix journey <debman>I try all the different linux distro's... <debman>I have to tell you, I don't like having to deal with so many new systems <debman>I don't like "trending" programming <debman>im honestly sick and tired, of having to learn new systems, for managing an operating system every time I try a new OS <homo>assuming you are familiar with creating packages in other distros that is <Rutherther>okay, doesn't matter then. if you had I just wanted to say Guix System is similar to it in some of the limitations, so you would probably already be familiar with that <debman>like you can install a program, or create a package for your package mangement system to install <Rutherther>it can't be completely automated, but for some build systems there is guix import, like for pip, crates etc. <debman>its actually much nicer, getting away from these management systems <debman>thats when my computer is at it's most happiest <homo>guix is inspired by nixos and is a fork of nix <debman>I think it's really interesting guys <debman>but I am mising the freedom, and ease of use of other distro's <debman>I have to squint at all the guix documentation, and try to remember everything and take notes <debman>so installed packages go to guix/store <debman>and, they also go into .guix-profile/bin? <homo>both guix and nixos are easier to use than other distros when you have will to learn <debman>it will be in two different locations <debman>and then if I upgrade it, I will then have four web browsers <homo>the way guix manages packages is the reason I don't want to use any other distro <ieure>debman, The profile contains links into the store. <ieure>It's not a second copy, it's a pointer to a copy which exists in the store. <debman>im just trying to imagine the system, in my mind, I dont know what will happen xD <homo>if you are running out of space when upgrading: $ info "(guix) Invoking guix gc" <debman>so if I install a web browser, it will go into guix/store, a symlink will be created in .guix-profile <debman>and then if I upgrade it, I will have two web browsers <homo>if you want to delete previous version of web browser, run $ guix gc --delete-generations <ieure>debman, Yes, the old and new copies. <homo>generations allow to have backups in case something breaks after upgrade <debman>I want to build the whole distro from source <Rutherther>you can do that with guix. Guix is source based, and if you download something, it's just a cache hit based on the hash of the build instructions <vagrantc>just disable substitutes and get ready for long compile sessions :) <homo>generations saved me a lot of times when I tested different combinations in /etc/config.scm, without them I would have to reinstall the whole system or boot from usb and fix everything by hand <debman>I can build a geeks host, and then pull from it locally <debman>thats cool, I reinstall all the time <debman>everything breaks, every day, on my computer <Rutherther>with guix you can either first build something on the other computers and then substitute it on your target (or guix copy it to the target), or you can also add build machines that the builds will be distributed to <homo>if you have to reinstall guix, it's either because file system is damaged or you want to change password for disk encryption <debman>if you dont have the source, you've got a big problem with alot of these distros out there I think <debman>so... do you guys know, about 32 bit library support? <homo>if you want to run wine, it doesn't require 32-bit libraries anymore <debman>the way they do it, is they provide 32 bit support libraries, which opens up a whole new world of programs.. <Rutherther>installing 32 bit libraries is probably going to be hard, but you can use a shell with 32bit libraries using "--system=i686-linux" <ieure>What is the world of open-source programs that only run on 32-bit hardware? <homo>beware, there is no rust on 32-bit <debman>I actually really like 32 bit programs.... because I think they run super super fast, on 64 bit machines <Rutherther>there is no need for that, as the hashes are different so everything can be in one store. Even for completely different architectures <debman>I want to try guix, with other distro's too <debman>replacing their system management systems with guix might be a really good thing <Rutherther>the reason I said installing is going to be hard is only because of lack of support. I don't think it would be hard in principle, it's just that no one did the work for it to work <debman>thats basically what I try to do anyways <dariqq>does anyone where where i need to look for tex amsthm.sty and amssymb.sty ? <debman>so how would a guix package manager, and shepherd init work ontop of debian? say... if it had 32 bit library support <homo>basically guix doesn't support multilib because nobody misses neither steam nor proprietary games here <debman>apt and guix would exist side by side... but how would that benefit me <debman>you must not have very big graphics cards... <Rutherther>it depends on how you would set that up, but I don't really know what shepherd init on top of debian works... if you are going to use guix for saying what services are in shepherd and what packages are used, you are basically making it guix system, it's no longer debian, so what would "debian" do in that picture? <debman>so I apt install *a package!* where does guix come into play? <debman>will it create an image or profile of my system or something? <Rutherther>if you apt install something guix will not do anythign <Rutherther>apt will put it to the locations it knows, like /bin, /lib etc. <debman>so how would I use guix, next to apt, on a debian based system <Rutherther>I don't understand the question. Guix has nothing to do with apt, they are completely separate, it doesn't matter if apt is there or not <debman>its like I have alot more priorities, with my computer, than simply managing packages <debman>I understand that, guix and apt are separate, but how I would use guix to do anything <civodul>sneek later tell apteryx we’d need to check with janneke, but i think 118d6429c8e7d4fce19da569da959ca753edb087 is incorrect <Rutherther>the same way as normally, you use guix shell, guix install... like on guix system <homo>there is well-written documentation both in cookbook and manual <debman>so I guess I was confused, I thought guix would help manage my system, such as debian <debman>but it's just it's own system I gather <debman>like if guix replaced debians system management scheme, that would be fantastic <debman>I think you might have thousands of users lined up outside your door to learn to use guix then <debman>but so it's just a container or a system of containers on my system then <efraim>civodul: I think janneke said they tested out the commands before making the changes <efraim>also, I pushed the rust-ring patches to the rust-team branch <ieure>debman, It's a different package manager, same as if you use Debian to install pip and pip to install Python packages. <dariqq>texlive-amscls seems to be the thing i want <debman>right like having snap or flat packages.... <ieure>debman, It seems ludicrous to have a Debian package which replaces all the Debian management stuff. Nobody would do that, they'd ship a completely different distro. <debman>so we can have guix, and snap, and flat, and github, and on and on <debman>thats what people are working on every day <homo>neither git nor github are package managers <ieure>Well, I think the idea here is that Guix on a foreign distro gives folks a taste of Guix System, which they could eventually switch to. <debman>replacing systemd, replacing the limitations of debians packaging <ieure>And/or if your personal machine is Guix System, you can have some of the same facilities on another distro, if you can't run Guix System. <debman>replacing the prescribed systems management facilities, has been the name of the game for probably forty years <homo>if you simply don't like systemd, there are distros based on debian that don't use systemd, guix is not the right tool to get rid of systemd <debman>yea for people you'd like to talk to.. <debman>You see, you don't just have systemd today <debman>you are going to have it tomorrow, and whatever changes that brings <homo>it doesn't make any sense for guix to even change init system on foreign distro <debman>which you have no power over, without removing that system management scheme <debman>so yea, forty solid years, of working to provide new solutions <ieure>I have literally no idea what you're trying to say. <Rutherther>seems completely wasteful when you can just build guix system, without any debian stuff at all <debman>with their package manager, I can apt get, and edit configs, and have my complete ideal system up and running, in an hour <debman>custom kernel, graphics drivers, every package I could dream of, working, in a single hour <ieure>Sounds like that's the distro for you then! <Rutherther>but that is just because it has been worked on for longer time. It's not that guix would be incapable of having that <debman>but it doesnt matter, that debian provides such ease of use <debman>if it doesn't secure it's own community <janneke>civodul: thanks for the heads-up, but it now seems that: qemu-8.2.2 also works for the 64bit hurd, *and* --machine q35 is no longer necessary <debman>I can install a complete linux system with hundreds of customizations in a single hour <debman>but its a totally insecure linux system <homo>entire guix system is defined in a config file, it's safe to run "guix pull && sudo guix system reconfigure /etc/config.scm" and if something goes wrong, you can switch back to the version of system that worked <debman>and a totally insecure linux community <janneke>however, i do not get a login prompt on the 64bit hurd -- but i cannot be 100% sure that i ever got one because i most always use --nographic <janneke>ACTION is now checking the 32bit hurd...but compiling guix 2 times takes a while <debman>anyways, thank you guys for your help... I have been to every libra irc channel for different distro's and always get violently harrassed typically. that hasn't been the case here. thank you so much <janneke>civodul: np! better a bit too much noise than too little <homo>don't bother, it was a very confusing conversation <jlicht>civodul: something went wrong wrt the subuid subgid merge; A `gnu/tests/shadow.scm` is now listed in local.mk, but not in the source tree from what I can see <olafes>Compiling guix fails with this error: <olafes>;;; Failed to autoload atf in (gnu packages check): <olafes>;;; Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (atf (gnu packages check)) #f)'. <olafes>Any idea what could be the cause? <olafes>Does this mean that guix/tests.scm needs to autoload (gnu packages check)? <janneke>sneek: later tell apteryx: the login prompt only/still appears on the 32bit hurd, so apparently it's just broken for the 64bit hurd <janneke>civodul: any ideas why "login> " would be only broken on 64bit hurd? <jas>thanks all here for help and suggestions! <dariqq>do i need to do some extra things to get latex fonts working during a build? When i run things in a manual guix shell it is able to find the font but in a regular build it eventually errors <dariqq>ACTION found texlive-updmap.cfg which works <homo>I have a really tedious work to fix messy spacing caused by invoking style <homo>without it it's impossible to start neither gdm nor wayland, at least on my laptop <podiki>jas: oo nice, thanks for sharing! <rekado>the build of Guix fails with "No rule to make target 'gnu/tests/shadow.scm', needed by 'make-system-go'. Stop." <janneke>rekado: commit a1ecd7f56c4ffadc49d5501a0df7f4c4556120c2 fails to add it <janneke>ACTION had a commit ready to de-register it from the makefile but somehowe hoped civodul would notice and fix it by adding the file <freeworld>hi guix, anyone know about how to install shepherd on different distro's like debian/devuan? <cow_2001>what do i put in a commit message of a guix patch when i add a phase to the emacs-denote package definition that builds the info manual? <vagrantc>freeworld: there was a recent post on guix-devel abnout someone working on that <freeworld>I honestly don't even want services running on my system, I want init to little to nothing <freeworld>like if my service manager would bring up the network and go away I would be happy <freeworld>dont even do that... I turn off automatic network configuration... because automatically linux systems are connecting to remote servers when they start up <freeworld>I just read on dev-1.org they are considering supporting shepherd for the devuan distribution <janneke>rekado, civodul: headsup, adding the missing file <homo>"./bootstrap ; ./configure ; make" gets stuck at "[ 11%] LOAD guix/tests.scm", did it fall into infinite recursion? <cow_2001>wonder when it will appear in the list :| <jlicht>janneke: thanks for following up on the missing file <sarg>hey guix, how to split system / home config in multiple files, so that all end up in the provenance and the system could be reconfigured from it? I.e. currently I use `(load "./home.scm")` in `system.scm` and such include can't be resolved when referenced from `/run/current-system/configuration.scm` <jlicht>heads-up for the folks using/managing guix-science & other external channels; Node.js was just bumped on master, so there may be breakage <civodul>it exists in release tarballs, but yeah, that’s confusing