<nckx>Like mekeor[m] I'm not quite sure what you mean, pashencija[m]. What does that code snippet imply? Bootable partitions (like sda4) bootstrapped from a tiny MBR (e.g., sda) were never a thing with GRUB 2. You need a 'BIOS boot partition' for that, an MBR alone wilr not work. Also not to be confused with a /boot file system or ESP. <ulfvonbelow>KarlJoad`: that could be tricky in the general case, because derivations operate at a different level of abstraction than packages. That is, not every output path in the store corresponds to a package. The surefire way would be to fold-packages to get the derivation for every single package, and check to see if it matches the derivation that produces that output, but of course that's very slow. <pashencija[m]>nckx: I'm working on an arm board where things are different. I want to be a able to generate two partitions: <pashencija[m]>Image API cannot create correct MBR for such layout (although partitions are generated correctly). <ulfvonbelow>you can get the derivation of an output with 'guix gc --derivers OUTPUTPATH' <pashencija[m]><mekeor[m]> "pashencija: what exactly is..." <- I hope my previous message answers your question as well. I want MBR for two partitions: one vfat without esp flag, one ext4 with boot flag. I think I'll start writing a patch on Thursday <KarlJoad`>ulfvonbelow: Ok. But then is there a way to get the package that produced a derivation? <KarlJoad`>I want to find the package that produces ca-certificates.crt. <ulfvonbelow>usually the package name is included in the store path <nckx>pashencija[m]: IC. Fully admit to being an x86-head with a dislike for the ARM boot mess... You seem like you've got a good grasp on the problem though :-) g'night. <ulfvonbelow>e.g. /gnu/store/longhashpart-PACKAGENAME-VERSION[-OUTPUTNAME] <KarlJoad`>Yet, when I search for ca-certificate-bundle, I don't see it. <KarlJoad`>It is stored in /etc/ssl/certs/ca-certificates.crt, and does exist. I just want the Guix name for it to use in the guix home module I am building. <ulfvonbelow>it seems it actually doesn't correspond to a single package, and is built as part of a system configuration <KarlJoad`>That's what the derivation looked like too. It's not in the package list online either. <KarlJoad`>Perhaps referring to the symlinked path in the configuration is enough?... <KarlJoad`>Yep. But no way to require that such a package exists... Unless I can force the hook to be run in guix hoem too. <ulfvonbelow>ca-certificate-bundle works by looking for certs in the etc/ssl/certs subdirectory of an output <ulfvonbelow>so as long as a package is installed in the profile that has something in etc/ssl/certs, it'll get picked up <paulapatience>rotateq: is it always appropriate to say "scalar" for arrays of rank 0? <KarlJoad`>ulfvonbelow: This package only reads from ca-certificates.crt, and does not actually install something to /etc/ssl/certs. <ulfvonbelow>to include a package in the home profile, extend the home-profile-service-type service <ulfvonbelow>is that package currently having trouble finding ca-certificates.crt? Is it looking for it at build-time or at use-time? <KarlJoad`>ulfvonbelow: Right now, neither. I am still trying to figure out how the user should specify the path to the file, if they want to. The path will be needed and looked for at run-time. <ulfvonbelow>typically certificates are configured system-wide by including nss-certs or similar package in the system configuration. It's generally left up to the user to provide them. <KarlJoad`>I am also giving the user the option to provide the path to a certificate manually, unless that is too difficult. <KarlJoad`>I also need to figure out what type the path to a file should be inside a define-configuration. <KarlJoad`>I used file-like-object before, but that will try to read the file into the store. The builder has no /etc, so that fails. I am using a string for now. <ulfvonbelow>could you modify the builder to write to (string-append #$output "/etc")? <KarlJoad`>I think I could, but I don't know why I would. <ulfvonbelow>that way the file-like-object can be successfully lowered to a file <ulfvonbelow>that way the user could specify the path as either a file-like-object or a string <KarlJoad`>Right now, the file path is specified as a text-config type inside the define-configuration, which fails because the builder now expects to read the file, rather than just write a file path out to a configuration file. <xigua>Anyone here using fcitx5 on guix system? <xigua>I've been fighting it to work for many hours over the past few weeks with no success <tribals>How to reference a file downloaded using `origin` in a package phase? <patched[m]>Guix hangs on boot right before gdm should start. Rolling back to a previous generation does not work. Can I somehow start guix without loading any services, to try to debug this/rebuild the system? <apteryx>can't you switch to a pseudo TTY? (Control+Alt+F2, for example) <patched[m]>Like, I can login in the tty if I'm fast, but after a couple seconds it freezes <apteryx>ah, the freeze affect the tty as well... hm odd <apteryx>do you have time to 'dmesg -w' before that to see any kernel messages? <apteryx>otherwise I would perhaps try the Guix live installation media (the latest "development" one available) and see if you reproduce the hang there <patched[m]>dmesg last messages are shepherd starting ttys and host-name <patched[m]>I multiboot, perhaps there is a way to chroot to the guix partition and rebuild the whole system? <apteryx>you could modify your operating system config and drop services you suspect are causing problems <patched[m]>Is there some guide for chrooting to guix for this kind of stuff? <patched[m]>I'm going to try something like this tomorrow when I've gotten some sleep <apteryx>I can share some rough notes I have that I'll put into the manual at some point <apteryx>let me know if they are useful/how they can be improved <apteryx>patched[m]: what architecture is your machine? is your config based on one of the templates? Did you add anything specific (services?) <zacchae[m]>patched: rolling back should fix no matter what, unless the problem is in a volatile portion like /etc (did you change something here?) My guess would be hardware as apteryx said. It is suspicious that problems started after an update, but could make sense if you hadn't rebooted in a long time (i.e. maybe reboot revealed the problem, not update) <apteryx>just throwing some guess; Linux moved to 5.17 in Guix recently <apteryx>which somehow caused my aging sound card volumes to be exposed in an even worst way from Pulseaudio <bdju> (cpu-scaling-governor-on-ac (list "performance")) <bdju>does changing this take effect without a reboot? <apteryx>emacsomancer[m]: is your RAM depleted when the test failures? <apteryx>or something in your logs about the OOMK (out of memory killer) being activated <apteryx>patched[m]: but yes, unless your GRUB is foobar'd rolling back should work <apteryx>doesn't seem too memory hungry (mutter test suite) <apteryx>I'm running it on my old x86_64 desktop <apteryx>emacsomancer[m]: on which system are you? <apteryx>emacsomancer[m]: I saw a process it using 1.1 GiB at some point, perhaps you don't have enough memory? <emacsomancer[m]>apteryx: I'm on Guix System x86_64 - with 8GiB memory and I haven't seen the memory usage go up past 50% <emacsomancer[m]>I see it complaining about Wayland, though I'm not currently using Wayland (maybe that's the problem? if I used wayland before it expects it now?) <gkh74>Hi all, I tried Guix as a foreign package manager on Ubuntu 22.04 and really liked it so far. Atm, however, I don't have the time to dig into it. No I have problems getting my "usr/bin/emacs" to run again. The thing is, that the GUIX installation set the EMACSLOADPATH, and I can't find any documentation on WHERE this is set. After guix package -r <gkh74>emacs, it still looks for the EMACSLOADPATH. I decided to remove GUIX completly from the system (follwoing https://www.reddit.com/r/GUIX/comments/m4f860/comment/gqu8esg). However, /usr/bin/emacs still looks after the EMACSLOADPATH environmet variable (which point to a now non-existing directory). Long question, short: Where does the <gkh74>guix-installation of emacs put the EMACSLOADPATH and how can I remove it? <civodul>so, looks like we still have those ci.guix problems <rekado>number of connections for cuirass has dropped from 233 when I last checked to 1. <efraim>guix-sysadmin mentioned that postgres was restarted, didn't check the timestamp though <abrenon>they work the same as other inputs I think <abrenon>some packages have several version maintained side by side <abrenon>like python, for instance has python-2.7, python-3.9 etc. <PotentialUser-42>abrenon I read something about that (fixed inputs), but can not find it anymore. <abrenon>sorry, "fixed inputs" doesn't ring a bell <abrenon>I mean, in the definition of python-3.9 (see "guix edit python"), there's this (version "3.9.9") field <PotentialUser-42>abrenon Maybe I am wrong. I had to read so much about python packaging and might confuse something <abrenon>so a package can have this "python-3.9" value among its inputs (propagated or not), but it's just a variable name referring to that precise definition, happening to point on 3.9.9 <abrenon>maybe it was 3.9.8 or 3.9.7 before it got a patch to be updated <PotentialUser-42>Wow. guix edit is quite useful. Did not see this before. I usually grep the guix source tree :) <abrenon>but as of my current version of guix, there's no 3.9.8 in the module, so you can't install python@3.9.8 because guix currently doesn't know how to build this <abrenon>yeah, it's tremedously helpful ! glad you like it too <abrenon>so, actually, to get a 3.9.8 python, I'd search for it in the guix repository's logs <abrenon>and then add a time-machine to the command-line to point to the commit when python-3.9 (or probably just python) was this 3.9.8 <abrenon>the way to do it declaratively to put within a file is to use "inferiors" <abrenon>a kind of alternative channel which you define as the official channel, but pinpointed back in time at that commit <abrenon>you'd of course do the same for python-lxml <abrenon>PotentialUser-42: does that help a bit or have I lost you ? <PotentialUser-42>abrenon Pardon, there was a phone call. I wrote some keywords like inferior on my todo list. At the moment this is not a serious problem, but one day I will check this is detail <abrenon>don't worry, I just noticed I sometimes have a pattern of writing several messages repeatedly without giving time to read and answer and I wanted to make sure it wasn't the case <abrenon>I hope that helps one day when you need it : ) <PotentialUser-42>abrenon You and others were so much of a help the past months. It always points me in the right direction. <rekado>efraim: I remember an email about this, but I think that was before I started watching connections. <rekado>efraim: never mind, I just found the more recent emails. <cbaines>that shows up in things like pg_stat_activity, and helps distinguish what connections are being used for <efraim>civodul: I can try for later today or tomorrow, right now I'm looking at python-cryptography-3.4.8 <efraim>I forgot how to "reset" back to standard arguments after inheriting from another package <civodul>efraim: i guess it depends on the arguments <civodul>for phases you could add an explicit #:phases %standard-phases, for instance <efraim>for now I just have (arguments (list #:python python)) <civodul>damn it's a nice collection of serious bugs that we have at our disposal *civodul tends to feel paralyzed when there's too much <patched[m]><apteryx> "patched: but yes, unless your..." <- Yeah even if I roll back to the first generation it freezes. I guess it could be a hardware issue, the laptop is over 10y at this point and at one time had some weird ram bitflip issues, could be that that problem has reappeared. Thanks for the notes btw, I'll try reconfigure the system someday this week. Is it possible to forcibly re-download all the derivations? <nckx>patched[m]: You can 'fsck' the store with 'guix gc --verify=contents,repair'. Is that relevant? I didn't read the whole log. <nckx>It will download substitutes for damaged files *if* available. <patched[m]>That will be useful, guix won't boot any gen so I am going to try chrooting into it to repair it <horizoninnovatio>guix-wine is at 7.0 and staging is at 6.6. I've install 7.0. Winehq 7.8 development is now released. If I install via winehq instructions, is there anything extra I need to do for it to be "seen" by my one wondoz app? <hnhx[m]>Could someone explain to me why is it that some packages are just downloaded in binary form and other packages are compiled from source? <hnhx[m]>like now I just downloaded gimp in binary, but when I downloaded icecat it compiled it <hnhx[m]>when does guix compile packages and when does it just download the binary? <iyzsong[m]>when binaries are missming from CI (substitutes server), it fallback to build from sources, status (jobs, queue) can be see ci.guix.gnu.org or via 'guix weather' <iyzsong[m]>it can be ci server problems (slow, lacking resources) or guix packages problems (code broken, package bugs) <hnhx[m]>iyzsong[m]: ah that makes sense then <hnhx[m]>so basically I dont have to wait for a maintainer to compile the source, I can just do it myself <iyzsong[m]>agree too, it's transparent, guix is sources based and binaries is an optimization. well, in practice i really need download by binaries.. <iyzsong[m]>unless i have somewhat power machines, not yet :k <hnhx[m]>altough I think gentoo does it better, since you can optimize the USE flags and setup ccache and everything <dgcampea>does guix build packages from source? I'm installing it from the ISO file (USB boot) <nckx>The CI is kind of borked. I mean, more borked than usual. You should be getting more substitutes than you are, hnhx[m]. <dgcampea>it seems to take longer to install (compared to other distributions) and I see some applying graft/building X lines <nckx> I'm mostly repeating iyzsong[m] here, but maybe you weren't around earlier: guix first polls configured substitute servers for cached build results. If it doesn't find any, it builds the package/derivation locally. <nckx>The substitute servers (CI) basically run guix pull && guix build $everything in a loop. <toangladius>hey, would anyone happen to know how to use the `xorg-start-command` in `config.scm`? i put it on top and the system reconfigures but i don't get either xorg or startx installed. I would like to use xorg without a login manager :D <iyzsong[m]>toangladius: you need add xorg-service-type and install sx into the profile, my bad for not document it... <Guest11>i'm running into issues trying to compile an U-Boot package. namely: "fatal error: asm/string.h: No such file or directory". i tried adding glibc both as an input and as native-input but to no avail. any ideas how i can resolve this? <allana>hi #guix! I just tried to do a build with go-build-system for --target=aarch64-linux, and I got an error: "no code for module (guix build go-build-system)" -- is this a known symptom to a problem that is easily fixable? <Guest11>i am building for another target, but i have no idea which package provides asm/string.h <Guest11>allana: i think you need to use the module (guix build-system go) ***pkill9_ is now known as pkill9
<allana>Guest11: I am, and I should mentionn that it builds fine for my architecture <apteryx>civodul: I'll reconfigure cuirass with your tentative fix commit <Guest11>allana: sorry, i guess i misunderstood you :) ***pkill9 is now known as tedt
***tedt is now known as pkill9
<allana>Guest11: No worries! I didn't mention what I should have in the question. Thanks for the response <apteryx>would we need to restart the workers too though? or just cuirass on the head node <civodul>just the three cuirass services on the head node <apteryx>currently getting "error: frontend-services: unbound variable" when trying to redeploy with my diff <apteryx>when running "~/src/maintenance/hydra$ sudo guix system -L modules reconfigure berlin.scm" <abrenon>I suppose biblatex is included in the general texlive package ? <Guest11>abrenon: i think it's in texlive-biblatex <apteryx>abrenon: 'guix search biblatex' returns texlive-biblatex <abrenon>I can't seem to reproduce an example beamer presentation with a bibliography <abrenon>yeah, I saw that one too but: trying in a new environment with on top doesn't help + I don't get any error when compiling the example doc with its \usepackage{biblatex} header <abrenon>so anyway the compilation produces a document, but it contains no bibliography : / <unfroq>abrenon: could you maybe provide a working minimal example for the latex beamer presentation? <Guest11>abrenon: and no useful hints in the logs? <civodul>apteryx: eval 324938 worked as well \o/ <unfroq>abrenon: "working" except for the bib <abrenon>no, I haven't found any interesting line <unfroq>abrenon: and I use the packages 'texlive', 'texlive-biblatex', and 'biber'. I use the biber command to process the bib items <abrenon>I didn't know there was a section in the manual about it, I'll try and read it a bit <apteryx>civodul: nice! i think my problem is poor error reporting; my custom cuirass/wip lacks a name/version fields/bindings <apteryx>civodul: cuirass restarted (all cuirass services) <apteryx>I've restarted postgres for good measures <apteryx>I'm now retrying the most recent 'master' evaluation <unfroq>abrenon: I was able to produce a proper beamer PDF, except for some font warnings with the following commands: 'pdflatex beamer-example.tex && biber beamer-example && pdflatex beamer-example.tex && pdflatex beamer-example.tex' <unfroq>abrenon: you need to add ',backend=biber' to the biblatex defintion in order to use biber: \usepackage[style=ieee,backend=biber]{biblatex} <abrenon>ahhh so this example works specifically with biber ? <efraim>civodul: https://bpa.st/3U3A here's what I have for python-cryptography using define-syntax but I haven't been able to get it to work <abrenon>I don't know about it but when you mentioned it earlier it sounded like it was an additional package you chose to use but wasn't required per se <unfroq>abrenon: yeah, I just use biber. I have no idea how to do it with other backends. biber worked just fine for me over the years. I think it is one of the most modern backends. <unfroq>abrenon: don't wonder about the multiple runs of pdflatex. I forgot the reason, but sometimes certain things are not picked up in a one-shot run. So you need to run pdflatex twice after biber. Especially with bigger documents. <abrenon>I think I remember such a thing from very ancient times when I was running pdflatex directly instead of writing Markdown and having pandoc do all the work for me <allana>Anyone know if aarch64-linux is supported at all for the go build system? Having a hard time understanding the error "no code for module (guix <allana> build go-build-system)" when the package builds just fine for my host system x86_64-linux. *allana is also not sure if I should use --system or --target (or both?) <nckx> Depends on whether you want to cross-compile (target) or build natively (system, would use Qemu on x86). <unfroq>I have some trouble updating my Guix system. What is the default/preferred way to reconfigure guix with a os defintion? I run into some trouble while using sudo to do the reconfiguration. <Guest11>guix update && guix system reconfigure /path/to/config.scm <nckx>unfroq: sudo (which on Guix System defaults to sudo -E). Trouble is hence unexpected. <allana>nckx: Thanks. I do have qemu-binfmt-service-type enabled for this system and using --system seems to be working :-) <nckx>allana: Weird error, btw. So that's with --target? <nckx>unfroq: Standard incantation: guix pull && sudo guix system reconfigure ... <hnhx[m]>Does anyone know how can I use the gcc-toolchain so gcc will find all the required things to compile something? <allana>to be clear, "guix build --target=aarch64-linux" fails, "guix build --system=aarch64-linux" works <Guest11>allana: for --target you need a triplet <nckx>allana: Add -gnu to target. <nckx>I'm trying a random go- pkg now... <nckx>guix build --target=aarch64-linux-gnu go-github.com-smartystreets-assertions <unfroq>nckx: I had no trouble for a long time. When I do 'sudo guix system -L ~/.config/guix/systems/ reconfigure ~/.config/guix/systems/my-system.scm' I receive an error: Git error: repository path '/home/myuser/.channels/some-channel/' is not owned by current user. The channel folder is owned by my regular user. Since sudo is invoked, it seems to expect a different environment <nckx>allana: Oh boy, it starts building the cross compiler here. But no Guile errors... <apteryx>mothacehe: I've restarte cuirass with the tentative fix from civodul <mothacehe>one restricting checking the system/target argument <nckx>mothacehe: The Go subject? <mothacehe>and another one adding a documentation node on the subject <mothacehe>apteryx: oh great, did you upgrade the Cuirass package? <mothacehe>hey civodul! nice catch on the inferior close issue :) <nckx>I saw them but didn't comment, but +100 on the concept mothacehe. <civodul>mothacehe: it looked like a déjà vu! (pronounced with English accent) <mothacehe>i was just writing an email about that. Is there an alternative to primitive-fork we could used in (guix inferior) to also get rid of the warning? <civodul>i don't think we can avoid primitive-fork unfortunately <unfroq>nckx: And when I use sudo -E instead of just sudo, i get: Git error: repository path '/home/myuser/.cache/guix/checkouts/l74z...ct3a/' is not owned by current user. If "current user" refers to my regular user invoking sudo, the error is actually incorrect. <civodul>mothacehe: but yes, we could have a par-for-each variant that uses processes instead of threads; there's one like that in the Git history... <civodul>mothacehe: re primitive-fork, what we'd need is a posix_spawn-like primitive implemented in C that would be safe, pretty much like what open-pipe does <nckx>unfroq: Having now read the issue... It's a regression (as in new 'security' check) in libgit2, it's (overly?) strict about user identity and sudo confuses it. <nckx>You're not doing anything wrong, it should work but now doesn't. <mothacehe>civodul: i can take a look to the n-par-map/fork thing before upgrading cuirass version <mothacehe>this way we would also get rid of the warning <mothacehe>but the guile spawn procedure would be great in the long run <nckx>unfroq: Can you afford to wait a day or few until it's fixed? <unfroq>nckx: No, I did not provide that issue. Hmm. I don't know how to use a derived os-declaration without using the -L option to search for modules in a certain load path. <unfroq>nckx: sure I can wait. But how can I know that this will be fixed? I think I have the problem since about two weeks already. <nckx>Well, I'm not positive it's -L. I'm on a mobile right now so typing & searching & ssh'ing are a pain. <allana>Guest11: and nckx: adding -gnu to --target=aarch54-linux for building a go package yielded the same error. <nckx>But it must not affect a regular pull/reconfigure or the sky would have fallen by now. *apteryx pictures nckx handling tons of emails on a tiny device with K9 <unfroq>nckx: My user package management is fine. I just can't update my system state. <nckx>apteryx: Er, yeh, exactly :-/ Also imagine insisting on an IRC presence. I hate it TBH. <unfroq>nckx: Do you think it would be a good idea to provide some comments on the issue you mentioned? I don't want to provide confusion, if this is not closely related <apteryx>mothacehe: changing topic, it seems cuirass has been happy with the storage performance as of late, right? are there still IO bottlenecks? <nckx>unfroq: I think it would, and thank you! From where I'm standing (admittedly, outside) it's clearly the same root cause, and discussion has stalled, so it's good if someone bumps it. <mothacehe>apteryx: i didn't observe any "missing derivation ..." which are symptomatic of I/O issues, but on the other hand Cuirass hasn't be building much lately :p <apteryx>yeah; it seems to have a a 10K+ queue at the moment, so I was taking a peek <apteryx>the drive saturating at the moment is /dev/sdh, the older array which holds /gnu/store <nckx>allana: Mhich packafe, unless you're being vague for a reason? <apteryx>not exactly saturating, but taking a higher load *nckx cries into the world's tiniest Dvorak keyboard. <bdju>build logs not bz2 anymore? I used to do bzcat file | upload-alias <nckx>Weird, I can't manage to get substitutes for an aarch64 xgcc on any system. <bdju>got a build failure for emacs-libgit <nckx>bdju: IIRC there was talk about the poor trade-offs of bzip2 for logs a while back, maybe somebody bold finally got the axe out. <bdju> http://ix.io/3XV4 in trying to gunzip + pipe ot, I just extracted it in place, will try zcat next time. anyway this is the build log <nckx>allana: I cannot reproduce any error with the smartywhatever command I quoted earlier. <efraim>I actually disabled log compression on my machine and use btrfs' zstd compression instead <nckx>I couldn't be arsed and use btrfs's zstd AND Guix's gzip compression, so my log files are compressed TWICE and half the size!! <nckx>...actually they probably have the nocow bit set but only by accident, still absolutely 0 arsing done. <nckx>efraim: Do you use it for /gnu as well? <nckx>Do any comparisons, by any chance? <efraim>my store is very full, give me a few minutes to run compsize against it and I'll see what it says <efraim>but IIRC between btrfs compression and guix's deduplication I get between 5:1 and 6:1 vs nothing <nckx>That is more significant than I expected. *jonsger[m] wonder how something like drpm would like for Guix <jonsger[m]>I compared a while ago two firefox nars (no version bump, just updated packages somewhere down in the dep tree): the only difference was some couple (hundreds) of -/gnu/store/oldhash-firefox +/gnu/store/newhash-firefox <apteryx>jonsger[m]: yeah, binary diffs could be cool <nckx>Thanks! I will do the data science when I'm back at my desk. <efraim>disk usage is "real space taken", disk usage -> uncompressed is btrfs compression, uncompressed -> referenced is guix-daemon's deduplication <mothacehe>apteryx: looks like the evaluations are still performed with the 1.1.0-11.9f08035 package <apteryx>odd, I reconfigured and restarted the cuirass services <apteryx>is the cuirass field of the cuirass-configuration record honored? <mothacehe>that's a good question, i usually compile and run customized cuirass versions, then upgrade the cuirass package <apteryx>the system generation still points to /gnu/store/qamrzl942khb7w0cb4csyflnxfkwvvxq-cuirass-1.1.0-11.9f08035 <apteryx>$ guix gc -R /gnu/store/zfdwzwizh7b1y7apblb32ji9ih97wvw4-system | grep cuirass <apteryx>the #$cuirass gexp should be unquoted perhaps? <apteryx>ah, nevermind, the whole thing is unquote'd <apteryx>seems I didn't run reconfigure; perhaps I ran 'build' and thought I had run reconfigure... ahem. Redoing it. <apteryx>seems to be on /gnu/store/z8haznhwck4bjm4gxqy25wvwv4041wvx-cuiras-1.1.0-12.f087aaf now <mothacehe>yup we have now two evaluations using the new package, thanks apteryx <toangladius>iyzsong[m]: so i added the `xorg-server-service-type`, but when i run `sx spectrwm` as normal user my whole system freezes, and i can't even ctralt2 out of it, it only works as root for some reason. not sure what I'm doing wrong <KarlJoad`>I am working on a module for Guix. I have a REPL inside of Emacs, which loads the module and works perfectly fine. I have a REPL in a separate terminal using `./pre-inst-env guix repl`, and that fails due to a type error. Why these behave differently is confusing me. Anyone seen this before? <apteryx>nckx: btrfz compression doesn't attempt to recompress uncompressible (such as already compressed) files <apteryx>so your .gz log files should be left untouched by it <PotentialUser-42>Hi. I am a little confused. If I remove a package after running guix gc sometimes other packages were downloaded <the_tubular>Yeah, it's just uselessly taxing on disk unmatched-paren <PotentialUser-42>unmatched-paren OK. I will show some of my colleagues a typical guix workflow and that surprised me. Thank you for the answer. <dgcampea>is there anything I can do to reduce the amount of times I have to input the password for an encrypted setup <dgcampea>right now I have to input it 4 times (and it takes quite a lot of time per entry) <KarlJoad`>Has anyone ever seen Guix system fail to find a bootloader after removing the disk? <vagrantc>KarlJoad`: isn't the bootloader usually installed on a disk? <KarlJoad`>It is installed onto the disk, yes. That's why this has been so weird. <KarlJoad`>I install Guix, reboot, use it, anything, and Guix works fine. I remove the disk once and switch to another OS, then come back to Guix, and I never reach the Guix bootloader. <unmatched-paren>KarlJoad`: mine occasionally loses the bootloader, but i think it's a bug in my UEFI <vagrantc>KarlJoad`: i'm not following you ... if you remove the disk the bootloader is installed on, how will the computer find the bootloader? <KarlJoad`>vagrantc: The disk with the bootloader and the root disk are the same. I completely remove the disk with both to switch OSs. <KarlJoad`>unmatched-paren: Hmmm... Maybe. But this does not happen with any other OS. NixOS, Windows, etc. <KarlJoad`>vagrantc: The Guix disk with both the bootloader, kernel, root FS, everything is on one disk. I plug the disk back in and things stop working. <vagrantc>if it's UEFI ... probably something about the other OS booting that fiddles with the EFI settings <KarlJoad`>That could be it. I've never encountered this issue when switching between NixOS and Windows, no matter how many times I switch. So I guess my question is now, does Guix System do something special with EFI settings? <vagrantc>probably need to debug this at the EFI shell ... see if there's an entry for guix, if something else is set as default that's no longer present, etc. <vagrantc>if you can manually load off the guix disk... *vagrantc is not too savvy with EFI, fwiw <apteryx>civodul: 80 minutes "In progress..." :o <raingloom>Hey so i installed Guix on an i686 laptop with about 1G of RAM and obviously set ~/.config/channels.scm up so that it uses channels-with-substitutes-available. And Yet! It is building things. Why the heck is that? <bjc>the substitutes servers have been bogged down lately, so its possible they're not caught up yet <Christoph[m]>Where can one check the status of the substitute servers? <raingloom>i have tried pulling at least once every week, same result each time. <raingloom>i thought the point of channels-with-substitutes is that it uses the commit that has substitutes available. if there is no commit with substitutes.... that's a problem. <raingloom>actually, it might be a good idea to warn the user in a case like that. <apteryx>civodul: I wonder if we should revert bd86bbd300474204878e927f6cd3f0defa1662a5 until we can find a proper solution <bdju>emacs-evil build failure this time: http://ix.io/3XWa (zcat worked great, thanks for the suggestion earlier efraim) <raingloom>so i don't get why my machine is also building it... <apteryx>is our installer script still not authorizing bordeaux? <raingloom>i tried explicitly passing --substitute-urls and now it actually printed a line about fetching the substitute list. computing the derivation on spinning rust with a layer of encryption still takes a while though. <raingloom>okay now it is at least downloading guix-packages-base instead of building it. <cbaines>apteryx, I think the current release doesn't include the signing key, which means you can't do it in the same way as ci.guix is authorized <apteryx>it seems to be working actually, some peer is getting substitutes from bordeaux; at least 'guix weather' was querying it <apteryx>or perhaps it uses it for 'guix weather' but wouldn't trust downloading its nars? <apteryx>another thing; guix weather would lead me to believe that ungoogled-chromium is available from bordeaux in this output; but if I build the manifest it goes on to build it? https://paste.debian.net/1241095/ <cbaines>yeah, there are two separate things, and the default substitute urls is just a function of how recent the guix is <apteryx>it's probably quite confusing for users, we should fix that <cbaines>apteryx, double check your acl and see if it includes the bordeaux key <cbaines>guix weather doesn't check signatures, so it just reports if the nars are available <apteryx>my guix-service-type config cons a bunch of extra keys on top of %default-authorized-guix-keys, so it should be there <apteryx>yeah, grep 7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F /etc/guix/acl has a match <cbaines>apteryx, so data.guix.gnu.org doesn't know about that ungoogled-chromium derivation <cbaines>which means that this could be a grafting derivation <cbaines>maybe try with --no-grafts to see if what that says? <cbaines>could you share the output for that? <cbaines>hmm, it does look like guix is wanting to build that ungoogled-chromium derivation <cbaines>it could be a caching issue, but that seems unlikely since the build on bordeaux finished days ago <apteryx>also, ungoogled-chromium was recently built on ci.guix.gnu.org, but not available from there yet it seems <cbaines>maybe try guix build /gnu/store/3w394fv4lysdwsciaha44g86x08ifzm7-ungoogled-chromium-101.0.4951.64-1 and see if guix is happy to substitute the output directly? <apteryx>it starts the build (unpacks sources) <cbaines>directly building the output shouldn't do that <cbaines>yeah, that'll give you a good read on whether guix is happy substituting it <cbaines>assuming your acl is fine, and your substitute urls are considering bordeaux, the next most likely thing is cached narinfos I think... <cbaines>you could try clearing out /var/guix/substitute/cache/ and .cache/guix/substitute/ <cbaines>if it does turn out to be a caching issue, that might suggest something is up with the caching of negative lookups either on the bordeaux end or in guix <cbaines>right, I think guix weather doesn't use the daemon's configuration <apteryx>do we have a %default-substitute-urls variable to use so that I don't get this problem again <apteryx>ah, re-exported from there, but originally from (guix store), it seems. <apteryx>So for people using install-guix.sh, after guix pull, bordeaux is in the substitute-urls, but not authorized <cbaines>although the guix used for the dameon won't have bordeaux in the default substitute URLs until it's updated <cbaines>I'm not sure if the clients default takes precedence though <nckx>apteryx: I see your old btrfs comments and raise you compress-force, but carry on debugging things that matter ;-) <apteryx>cbaines: so, I had my peer authorize bordeaux, and retry 'guix build -m manifest.scm', and it still would go on building ungoogled-chromium <apteryx>their guix-daemon seems to run with this command: `/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild` <attila_lendvai>i'm using (current-filename) in a package's definition, but in some circumstances it returns #f. is there any other alternative? e.g. acquiring a module's path, or loading a module-relative file? <apteryx>which is consistent with our guix-daemon.service.in systemd service template <mekeor[m]>attila_lendvai: what circumstances, exactly? :) <cbaines>apteryx, does it seem like it checks bordeaux? you could also try specifying the --substitute-urls when running guix build <attila_lendvai>mekeor[m], i don't know, i forgot to make a note. maybe it was when i guix pull'ed my channel. simply guix build my-package works as expected. <apteryx>cbaines: guix-install.sh must put 1.3.0 as the guix-daemon (or its inner version), which didn't have bordeaux in its default substitute urls yet <attila_lendvai>mekeor[m], yep, i tried it. it happens when i `guix pull` the channel. a ./pre-inst-env guix build works as expected. <apteryx>cbaines: it did! so I have something to improve in guix-install.sh before the next release <cbaines>the next release should make things easier, since the release tarball will contain the key <apteryx>(adding the authorization key for bordeaux) <cbaines>and the guix used by the daemon will use bordeaux by default <apteryx>i think nckx even had a patch for it but we were holding it until the next release (since the keys were missing in the current 1.3.0 tarball) <apteryx>something changed recently, I can't reconfigure my machine with my custom mcron checkout: sudo guix system reconfigure ~/stow/guix/hurd.scm --> guix system: error: Git failure while fetching file:///home/maxim/src/mcron: repository path '/home/maxim/src/mcron/' is not owned by current user <KarlJoad`>apteryx: That feels like the same issue people have been getting with Guix checkouts in .cache. <apteryx>even deleting the cached checkout won't do <KarlJoad`>ulfvonbelow recommended this some time back. I wonder if it would help here too. 'git config --global --add safe.directory /home/<you>/<checkout>' <allana>Nothing special AFAIK, can share package definition if you want ot help me test the error :-) *attila_lendvai has restructured the code and so avoids the current-filename issue <attila_lendvai>mekeor[m], oh well... i can guix pull it now, but (current-filename) returns #f when i try to guix reconfigure... <attila_lendvai>and to my dismay `guix system reconfigure` doesn't print nor log a backtrace, and only prints a not-very-useful error message ("In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f", which is coming from dirname) *attila_lendvai has found guix system --on-error=backtrace reconfigure <apteryx>KarlJoad`: my workaround is that I've now specified an exect commit for the git-checkout file:///something source git repository, as it seemed otherwise it was attempting a 'git fetch' as root in it, and this is what was causing the error <apteryx>if you specify the commit exactly, it doesn't fetch, thus the error is avoided <apteryx>not exactly convenient for testing changes... but hey, who said security was convenient <apteryx>(this is apparently the result of git fixing a CVE) <tribals>Just tried to create my own package which depends on slf4j-simple, and noticed origin links are dead. I'm wonder is it ever used by someone? Original package was added around ~2017, and according to Wayback Machine, those links are dead probably starting from 2019 or earlier <nckx>For now, find an archived version, make sure it has the same file name (or download and rename it), then 'guix download' it into the store. <nckx>Can be a remote or local file. <nckx>If the hash matches, Guix will use it to build slf4j. <nckx>'guix hash FILE' to check. <nckx>allana: But your peculiar module error is specific to your package, not any go- package, correct? You'll have to share it then :-) <fnstudio>hey! i'm updating a guix installation (on a foreign host) via the usual guix pull && hash && guix package --upgrade but it seems to get stuck in the process... it says "X MB will be downloaded ... 'check' phase" and it stays there forever <nckx>tribals: The fix is that trivial. If you submit a patch, it will probably be merged soon. Just not by me right now. <tribals>Which fix will be accepted more likely? Seems like slf4j release sources available on github, and in wayback machine. Which one is preffered? <nckx>Both. Neither. It really doesn't matter, since the content is validated. Guix accepts a list of strings - use both ;-) <nckx>Just make sure bot really are identical. <tribals>Well, git checkout is unlikely identical to tar.gz, definitely, hash will not match )) <nckx>I was talking only about updating the URL, not the hash, for now. If you are updating the package, go for git-fetch. It's just more work. I don't know how familiar you are with Guix. <nckx>Either would be welcome, but the latter would cause rebuilds (prolly not too many but check). *nckx going to give thumbs a rest now, phew; thanks for 'volunteering'! <lechner>Hi, how do I figure out which package ships a particular file, please? <vagrantc>there have been discussions about how to create a database of files and various workarounds... <vagrantc>lechner: if it's a file you might already have installed ... ls /gnu/store/*/PATH/TO/FILE somethings works for me <vagrantc>and there's of course following the symlink farms :)