IRC channel logs
2023-05-07.log
back to list of logs
<oriansj>has anyone created a guix config for making the Guix install ISO but included *EVERY* package; so that any arbitrary config could be installed offline? <vagrantc>oriansj: i've wondered about similar things ... though not *EVERY* package ... that seems a bit much :) <oriansj>vagrantc: well think of it as a guix mirror, stored locally and always there to ensure you have guix when you need it <vagrantc>and would have to exclude borken packages which are somewhat inevitible ... although also useful to find out exactly what would be missing <elevenkb>hey there do I have to set up partitions in order for guix system to let me create a docker image? <Parnikkapore_m>How do you use url-fetch in a gexp? I might be writing a package that has to download sources from 2 places <platoxia>I'm not finding a techlive-amssymb package in guix. Is it wrapped in some other package maybe? <platoxia>disregaurd my last, amssymb was wrapped in the texlive-amsfonts package <apteryx>mirai: no; XDG_RUNTIME_DIR is not set <apteryx>oriansj: that'd be ridiculously large, pulling the likes of texlive or games (e.g. 0ad) <mirai>apteryx: but do you see any socket file made under that user? <rekado>I’m trying to build the OS for kreuzberg, but the tests for guile-fibers seem to run forever <efraim>it looks like guile-fibers-1.1 has the phase to skip some very long tests but not guile-fibers <cbaines>rekado, guile-fibers@1.1.1 seems really difficult to build for aarch64-linux <cbaines>I wonder if the aarch64-linux specific problem that civodul has spotted has something to do with it <ArneBab>I had searched before — it might be pretty useful to have. <rekado>kreuzberg overheated once during the build, not sure what happened the other time. I left it building over night, and according to “guix processes” it was still going when I got up in the morning. <rekado>I cancelled again; it’s now building linux, so at least it’s doing something productive now. <cbaines>rekado, do you know what's pulling in guile-fibers? <cbaines>ah, I think the shepherd does as of recent Guix revisions doesn't it <chomwitt>Hi. can i use non free firmware with guix distro ? <cbaines>chomwitt, that's the same as asking "can I use non free firmware with linux-libre", to which the answer is no. <cbaines>if you want to use non-free firmware, you have to use a different kernel <cbaines>rekado, shepherd-0.8 is used for the hurd since that version doesn't use fibers, maybe you could do the same for kreuzberg? <cbaines>I don't know if anything else is requiring fibers, but that might be it <rekado>I see that it’s building fibers 1.0.0 <cbaines>rekado, ah, I think cuirass depends on that <cbaines>the approach I took with the build coordinator is to have a guix-build-coordiantor/agent-only package, which doesn't include any of the dependnecies needed for the coordinator, just the minimal dependencies to run the agent <cbaines>I think the same could be done here, as I don't think cuirass needs fibers for the worker <rekado>if it’s just cuirass I’ll override the cuirass command with a variant that uses fibers without tests <rekado>I may have done this in the past already… <rekado>yup, commit 1d8c25fdf7f2bc95d02611dfcac8442279d94806 in maintenance.git <rekado>oh, here comes fibers 1.1.1 for shepherd… <carmenshea[m]>Hey all, I just finished building Guix Home. Seems to look and work exactly as before, just a few differences appear in the home directory...most of the directories now appear to be symbolic links. I have a question: Will guix pull, guix upgrade, and guix reconfigure work as before? <minima>carmenshea[m] i think so, but i also think that you're supposed to use "guix home reconfigure home-config.scm" <efraim>you'll want guix home reconfigure instead of guix pugrade <jlicht>sneek: later tell efraim: Thanks for pushing the swaylock update. <sneek>Welcome back efraim, you have 1 message! <sneek>efraim, jlicht says: Thanks for pushing the swaylock update. <efraim>I've gotten into the habit of locking my computers whenever I stand up, I've had to reboot 4 times already today <minima>i've started seeing the "hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH' ..." message - which is puzzling me because my bash profile includes the usual GUIX_PROFILE var definitions, like this: https://bpa.st/RF76S <minima>do you know what might be causing this? <minima>sorry, the message is displayed when using any guix command <minima>(oh other addendum: i'm on a foreign distro) <rekado>minima: have you installed glibc-locales and set GUIX_LOCPATH? <minima>hey rekado, thanks, yeah, i've done both things; to be clear, glibc-locales is installed via guix home (hope that's ok) - and yes, GUIX_LOCPATH is defined in my .bash_profile (which i even tried and parsed explicitly before running a guix command, to make sure it gets set) <minima>it gets set = GUIX_LOCPATH gets set <minima>i.e. i also get the "guile: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE" error, although in a slightly different context than what reported above <minima>i get it when running "./pre-inst-env guix search hello" from within a guix pure shell, i.e. after "guix shell --pure -D guix help2man git strace" <minima>this may very well be unrelated from the other glibc-locales issue i was mentioning a minute ago, but i also think both issues could be diff symptoms of the same problem or misconfiguration <mekeor[m]>hello. is there a easy way to "make" the guix repository without docs? i wanna save time :) <rekado>minima: this looks like you have a bit of a mismatch. E.g. an older daemon in a newer environment. <rekado>glibc 2.33 has been upgraded to 2.35 already <rekado>so it’s worth figuring out which part of your environment still uses the old glibc, and then upgrade that <efraim>you can check 'guile' in the root of the guix repository, I ran into that recently <minima>oh cool, that'd explain the issue... thanks rekado - this is a guix on foreign system installation, i've also upgraded guix from root and then i restarted the guix daemon but that didn't seem to do it <minima>efraim, ok, yeah, i see the guile shipped with the repo is linked to 2.35 now <minima>weird, if i use the binary (as in "./guile --version") i still get the error re 2.33 though <minima>oh, ok, no i get it, it's because the daemon is older than the rest of the system <minima>hm, barring the idea of waiting for my distro to ship an updated guix, what could be the solution here? to roll back to a previous guix home generation to avoid the glibc mismatch? or to use some form of containerisation (basically a VM i guess, with its own updated guix daemon)? <rekado>booted pankow, now restoring keys <mekeor[m]>ACTION also runs into the "gcry_md_hash_buffer: Function not implemented" error when "make"ing guix, just like jgart reported on help-guix mailing-list <oriansj>I thought guix had gcc-gnat but I can't find the GCC Ada compiler???? <efraim>we have 'ada/ed' packaged, which apparently can function as an Ada 83 interpreter, but we've never progressed from there <efraim>also I'm pretty sure it builds correctly on powerlc-linux <efraim>well that's incredibly frustrating. I'm pretty sure rust-bootstrap has been failing on riscv64 because it runs out of space in /tmp <ngz>rekado: I thought about an improvement (two, actually) over #:tex-directory in texlive-build-system. I'm worried that sometimes, cruft generated in the build directory gets installed in the output. <ngz>rekado: Also, sometimes, generated files in the build directory need to go into two or more directories, which cannot currently be handled by #:tex-directory keyword. <ngz>rekado: So, my first idea would be to get rid altogether of that keyword. During the build phase, we generate files in a top "build/" directory (i.e., at the same level as "doc/"…), then, for each file in "build/", we look into the other directories ("doc/", "tex/" or whatnot), and if we find the same file, we _replace_ it with the new one. Files that cannot be found elsewhere are considered as cruft and ignored. <ngz>rekado: During the install phase, we copy everything but "build/" as is in #$output, which will therefore contain generated files. <ngz>rekado: As a bonus, we don't need to specify non-generated files in simple-texlive-package's locations argument anymore. <ngz>I think the world will be a better place if we implement that. <jlicht>ngz: Consider me an uninformed outsider w.r.t. texlive, but how would your rewrite work with false positives and false negatives? <jlicht>where positive = file is included, negative = file is not included in the installed package <ngz>jlicht: That's the good news about Texlive. Everything is included already, so we cannot miss anything out. IOW, it would work even if we didn't try to generate anything. <ngz>If we generate a file that doesn't exist in the other Texlive directories, then it is not necessary. If Texlive directories contain a file that wasn't generated, it will be copied over anyway since all directories are copied. <ngz>jlicht: Does that sound convincing? <jlicht>ngz: In that case, this approach seems fairly promising! <ngz>Ultimately, we may be able to get rid of `simple-texlive-package' and define Texlive packages like any other one. <jlicht>I'm running into the vaguely familiar 'error: polkit-for-system: unbound variable'. Did this have something to do with import cycles? <ngz>Is the root of the current build directory is accessible during build? <ngz>(i.e., how can I get "guix-build-xxx.drv-x"?) <ngz>Hmmm, I'm not sure there's a way. <Guest9415>During my installation attemp i get: error: service 'file-system-/boot/efi' provided more than once' <jlicht>Guest9415: So at the risk of asking the obvious, did you supply a "/boot/efi" filesystem multiple times in the file-systems field of your operating-system record? <apteryx>jlicht: probably need to rebuild the .go files <cbaines>apteryx, that string comes from the patchwork series I think <cbaines>I'm not quite sure why that issue first had some csvkit related patches sent to it, then a gdb update. <Guest9415>jlicht, i dont supply it. there is an efi record in more than one storage unit of my system <Guest9415>in the nvme storage that i want to install , there a fat32 boot,esp /boot/efi partition , an ext4 partitoin mounted on / , and a swap partiton. There are boot efi partitoin also but at other storage units <Guest9415>but in the next step i see in the /etc/config.scm indeed all boot efi partitions of my system <Guest9415>i'll try to edit it to remove the ones i dont wont. <Guest9415>strange thought. in debian -based installers i havent seen that <Kabouik>How come Guix wants to instal all this from the command I ran? http://0x0.st/HZf6.png It is now installing a million of texlive packages, and others things not related to TeX, and one of this seems remotely related to ytfzf. <Kabouik>I rsync-ed some of my .config folders from my main Guix system laptop to my phone running Guix package manager only. Could it be that Guix picked something up in a config folder to install packages instaalled on my laptop? I do not see which config folder could have caused that, though. <mfg[m]>Might be transitive dependencies <Kabouik>What are those? TeX and other things listed there seem totally unrelated to ytfzf dependencies, which are just fzf, yt-dlp and mpv. <ngz>Kabouik: you can use "guix graph --path ytfzf texlive-whatever" to see how it happened. <ngz>Kabouik: The command "guix graph --path ytfzf texlive-bin" gives me the following path ytfzf -> libnotify -> ... -> texlive-bin. <yelninei>Hi everyone, I hope this is the right place ask a question. I am currently trying to write some guix packages. One requires multiple patch files located at another git-repo. Is there a way to let guix fetch and apply these automatically when building the package? My current solution is downloading the files manually and hard coding the path <ngz>yelninei: No, there's no internet access during the build. you need to download the patches and add them to the repo (and register them in "local.mk"). <Guest9415>unfortunately editing /etc/config.scm can help because efi boot partitions are identified by their uuid and i dont know which is which. can i execute 'lsblk' by another terminal ? <yelninei>ngz: ok but how does passing an origin object into the patches field work then? <Guest9415>i guess i could unplug all storage but one.. but that would mean atleast onehour work in pc since i have nvme behind a gpu.. <mfg[m]><Kabouik> "What are those? TeX and other..." <- Transitive in the mathematical sense. Itemas these TeX dependencies are most probably dependencies of the direct dependencies. Because it's TeX I'd assume it's for building documentation. <mfg[m]>s/Itemas/I'd guess/ the heck did this come out as Itemas?! <mfg[m]>Do we have package transformations to add inputs as command line arguments to a guix shell invocation? <mfg[m]>Such that a package gets modified to include that additional input? <mfg[m]>It seems that inputs can only be replaced <Guest9415>ok. in case someone else has more than one storage unit with efi boot the solution is to edit the system config und carefully remove the ones you dont want. <Guest9415>i am chomwitt by the way. just using irc from a backup laptop . <Guest9415>i installed ok . but during booting i see : Erroe : Driver 'pcspkr' is already registered. aborting <Guest9415>TheSkylarverncc[, in my case the booting freezed <Arya[projectsegf>pcspkr cannot cause issues, it just means that the pcspeaker thing was already registered <Guest9415>what is the 'firmware setup' grub menu entry ? <Guest9415>udevd[320] : no sender credentials received, message ignored <Guest9415>i found a couple of post that involve use a live USB/DVD, mount your root system, /etc/modprobe.d/blacklist.conf , blacklist pcspkr <Guest9415>so i guess using a live usb and mounting the guix root system could give me also access to the system config you asked <Kabouik>Thaanks mfg[m] and ngz for your answers. It's still building, it won't be quick on a phone when things like tbase need to be built. :< <ngz>yelninei: origin objects are downloaded before the build starts. But I may have misunderstood your question. <mfg[m]>Kabouik: Ah yeah that's true. Why can't you use substitutes though? are they unavailable? If so, it might be worth to find out why; maybe there are build failures, then you would not have to waste time trying to build things locally that don't actually work right now :) <Kabouik>I believe substitutes should be used by default, no? I am aassuming there is just no prebuilt version for aarch64 yet. <mfg[m]>Kabouik Ah yes, aarch64 🤔 did you check the build logs of the larger builds (as qtbase for example)? You can check them on ci.guix.gnu.org iirc if the log says that there was a build failure you don't need to build it, as it most likely will not succeed. <Kabouik>I haven't checked mfg[m], but if it failed and wil fail on my end too, can I just skip it? I assume it's a dep for something I ma trying to install and therefore there is no way around it. <mfg[m]>Well the aarch64 availability looks pretty bad right now. I'm not sure though if those are all real failures or if the build farm isn't fast enough or whatever, sorry 😔 <Kabouik>Is `ERROR: ld.so: object 'libtls-padding.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.` a preload Guix package manager does? I am having a hard time identifying the source of it, but it happens for every Guix command I run, in any terminal. The commands still work, there is just this error at the top. This does not happen for commands other than guix. <Guest9415>Where should i add in my config.scm (kernel-arguments (append (list "nomodeset") %default-kernel-arguments)) ? <Guest9415>my freshly installed guix system throw an error in 'guix system reconfigure /etc/config.scm' , aborting reconfiguration because commit 8e2... of channel guix is not a descendant of 98.... <juli>This probably means that at some point there was an amended commit and/or rebase of the git repo. If you're confident you're pulling from the correct place, you can add the `--allow-downgrades' flag and it should work. The other option is that someone has hijacked your route to the git repo and is offering spoofed code. This is improbable, but not impossible. <mekeor[m]>Guest9415: if you know what you are doing, you might pass --allow-downgrades, but make sure you have not been pwned first :) <mekeor[m]>Guest9415: put `kernel-arguments` just inside `operating-system`. <juli>on the topic of repository verification, why can I no longer make commits to my local checkout of the Guix repository? Do I need to configure GPG or something? <mekeor[m]>juli: someone mentioned that guix recently began enforcing cryptographic commit signatures. but did you also try to just guix pull? <Guest9415>mekeor[m], i am a new guix user. I found in the guix forum a hint to add a kernel argument line in my config.scm and then guix reconfigure <Guest9415>mekeor[m], ..in order to correct a booting freeze <mekeor[m]>juli: seems like this is still true on latest master <mekeor[m]>juli: so, yes, you need to configure gpg-signature. note that you can also simply use a ssh key. <mekeor[m]>Guest9415: "pwned" means maliciously hacked / cracked <mekeor[m]>Guest9415: i don't think that two things you are talking about are related to each other. namely: (1) the "aborting because commit ... is not descendant of ...". and (2) adding kernel-arguments. <Guest9415>mekeor[m], i see. i hope not. i've just installed guix and tried to solve a booting issue <mekeor[m]>Guest9415: afaik, --allow-downgrades can be passed to both 'guix pull' and 'guix system reconfigure' <juli>mekeor[m]: I've got a gpg key for my personal Guix channel and had the foresight to write down the procedure for getting a new one, so I'm just making a key for Guix. Thanks though! <Guest9415>mekeor[m], what checks should i make security-wise to be more sure that i am proceeding safely ? <Guest9415>how can i see the channels currently my system uses ? <juli>similarly, if you have a home profile, that's `guix home describe'; and if you want to check other profiles, it's `guix package [-p <profile>] --export-channels' <elevenkb>hey y'all's i want to set up a VPS which uses lvm device mapping <elevenkb>how do i mount the pv? do i just declare it as a file-system with type "lvm2"? <Guest9415>how can i check the latest commit of the default savahna channel of my system and the latest commit that my system has ? <elevenkb>Guest9415: i'm not quite sure what you mean by that... If I had to guess what you mean: <elevenkb>the easiest way to find out your guix version is to use a command like guix describe, guix system describe or guix home describe <rekado>sneek: later tell ngz #:tex-directory was a hack. The .ins files may specify directories as well, so we can’t just do whatever we want either. <elevenkb>Guest9415: in order to compare versions. <Guest9415> i mean that the default guix repo has a latest commit and thus a head version from which i pull packages. How can i inspect the version and the contents of that 'version' (like for example i would examine the contents of a debian repository) <Guest9415>and what does my config.scm has to do with the guix repo state? Isnt something that i control ? Why 'guix system reconfigure /etc/config.scm' should display an error regarding commits? <elevenkb>Guest 9415: hmm i'm a guix n00b so i have no immediate idea. do you mind pasting the error? <mfg[m]>Guest9415: you can see which guix you are using when running `guix describe` the commit hash that you see there for the channels are the git hashes which you can use to checkout the channels git repo at exactly that commit. There you see all the code that this specific version uses. I hope this is what you are searching for? <mfg[m]>So afaik the guix that runs on your system and that you configure with `guix system reconfigure` uses it's own copy of the repo. It's because every user can use a different version of the packages (which are part of the same git repo as the guix Daemon sources). The commit that your system uses should be displayed with `guix system describe` <mfg[m]>So when a user `guix pull`s the specific commit that the user is using can be different from what the system guix is using <mfg[m]>Why should a debugger accept linker flags? <mfg[m]>As in what does the package specification/your build command look like? <mekeor[m]>hello. i'm trying to add a package "tree-sitter-gomod" to guix proper. why do i get the following build error when i run `./pre-inst-env guix install tree-sitter-gomod`?: Throw to key `gnutls-not-available' with args `("(gnutls) module not available")'. https://paste.rs/5ne <nikita>I guess it doesn't matter if you didn't run into this before or had the necessity to change it <mfg[m]>I also fail to get where this is guix specific? Or is this a general question? 😅 Sorry if I'm not of much help <nikita>it was a general question to other packagers <nikita>as in, you do package llvm, you might run into weird behavior sometimes, have you seen this <nikita>if I get no response on the bug ticket in a week or so I'll just ask on their discourse forum <mfg[m]>Ah okay, I didn't get the context, I thought it was guix specific. <mekeor[m]>ACTION would be very happy if someone could merge the fixes for tree-sitter submitted by Pierre Langlois <efraim>mekeor[m]: I've merged them, but they're in the rust-team branch <mekeor[m]>does anybody have a "custom" mu4e action for applying a patch attached to (one or multiple) email(s)? <panosalevro>hey all, is there a way I can view available versions of a guix package to install? <juli>panosalevro: what exactly do you mean? You can use `guix search <package>' to see if different versions are available in the current version of Guix <lilyp>panosalevro: guix show <package-name> <elb>`guix pull` keeps timing out for me on substitutions for various packages; it _looks_ like it makes more progress each time it runs, but I don't want to be hammering on a server that appears to have Problems at the moment. Is there a way to tell it to just be more patient, I don't care how long the update takes? (I left for a few hours and came back, and still have the same problem) <lilyp>you can use --fallback to build packages from source when the substitution fails <elb>unfortunately that didn't work, although the `guix pull` command does say that it should <elb>(in fact, as far as I can tell, the error was exactly the same) <panosalevro>juli, lilyp: I meant past versions of the package like `guix install <package-name>@X.X.X <lilyp>Guix show shows all versions currently installable via that syntax. For versions gone, use time-machine. <panosalevro>I'm not sure where I can see that information with guix show <juli>right so that command will search for any package definitions in the version of Guix you're using which provide that version of the package. If you want to see the history of package versions available, as far as I personally know, you'll need to find a commit of the Guix source repository (https://git.savannah.gnu.org/cgit/guix.git) with that version available, then operate from that commit using, as lilyp said, ti <juli>me-machine. Not all past versions of a package may have been in the source tree; in such situations, you can try to write a package variant for that version such as by inheriting from a current version of the package <mekeor[m]>mekeor: yes. use it like so: (add-to-list 'mu4e-view-actions '("apply git patch" . mu4e-action-git-apply-mbox)) <Guest19>does someone know how I can get org.freedesktop.ScreenSaver dbus service? I know that gnome-settings-daemon provide it, though I use EXWM as DE and not GNOME 