<johnjaye>hmm, got another problem installing on hardware. this time i used the latest installer though
<johnjaye>the first problem which i was able to correct is it assigned 2 /boot/efi partitions. the other one was on my windows drive. so i managed to work around that and get the installer going. until it crashed
<johnjaye>this was *after* i fixed the /boot/efi error so I didn't save that one
<johnjaye>this is with the latest guix iso not the 1.3 one
<rekahsoft>Hi all, I ran into an odd issue when updating an old, out of date guix vm of mine (from bf986c3e to cec5a522). I tried to pull a set of channels that included ones that were not yet used on this vm, however this resulted in an error "unsupported manifest format". However, when I tried to pull just the guix channel, it worked, and after updating, I was able to pull the additional channels that originally resulted in
<rekahsoft>the "unsupported manifest format" error message. Any idea why this occurred? I ask because I am now seeing a similar error when trying to update this same system via `guix deploy`. Any help appreciated :)
<NaturalNumber>spent hours trying to set up emacs-org-roam. i followed the manual and had all of the dependencies like a good boi, but it didn't work until i installed gcc-toolkit. maybe this can help someone out.
<dominicm>NaturalNumber: was this with the guix emacs-org-roam package, or using the one from MELPA
<james[m]>Originally I just thought guix was 100% reproducible on the official substitute servers. But now I realise it might not be.
<james[m]>I would like to see where deterministic builds fail as well.
<james[m]>And could be a concrete way to verify third party substitute servers I might use.
<PurpleSym>civodul: Any opinion on how to temporarily work around https://issues.guix.gnu.org/56343, so we can bump the guix package due to the manifest version change? I’d just remove telephony.scm from Makefile.am, but there might be a better way.
<civodul`>PurpleSym: yes, we can remove it from Makefile.am
<civodul`>i hadn't realized we needed to bump the 'guix' package, sorry about that
<parmegv>hi everyone! I'm testing guix pack, and after transferring one relocatable pack to my work machine where I don't have root privileges, I cannot remove the gnu store. It says permission denied. How should I remove the installation of a pack?
<parmegv>the pack only had bash, after I couldn't rm -rf I installed guix and extracted it again to run guix gc, but of course there is no daemon running so gc does not work.
<parmegv>moreover, if I do guix package -I there are no packages listed
<rekado_>“guix package -I” looks at the contents of ~/.guix-profile
<rekado_>so if you haven’t installed anything with “guix install” it won’t list any packages
<dhruvin>I see many gnu+linux distributions have contributors and maintainers of packages. guix doesn't have this concept. What was the motivation? Doesn't having package maintainers help accepting patches of updates?
<parmegv>to remove the installation of a pack, I just chmod -R 777 gnu & rm -rf gnu. No need for guix to do anything, just basic linux file management
<parmegv>dhruvin: as far as I understand it, there is no need for specialized people to become maintainers of packages. it is very easy to create guix packages, and contributing it to the main Guix repository is just a couple of emails away. I think I read this in the manual
<reyman>Is it possible to run Ubuntu or other distro with vm (not docker) on top of guix to test something ?
<dhruvin>parmegv: Yes, submitting guix packages as patches is quite easy. But they need to be reviewed before they're accepted; and this process is interactive for new or tricky packages. If we have special groups (like desktop group) that review and accept relevant patches, the process can be smoother I think.
<dhruvin>Currently, the reviewes and committers are thanklessly doing this. But I'm wondering if introducing something like maintainer/groups willl help. People in guix surely would have thought about it and decided to not have this. So I'm interested in the reason.
<rekado_>dhruvin: we already have that. See etc/teams.scm
<dhruvin>rekado_: I never saw this in packages, so I wrongly believed this to be missing.
<dhruvin>Oh yes. I too believe that having maintainers won't necessarily lead to faster acceptance/feedback of patches. I was wondering if we experimented before and if had reasons not to go in that direction.
<nckx>Before that, the idea was that not having a concept of package/code ownership would help, because nobody would fear they were stepping on somebody's toes by reviewing something they happened to know well despite not being on the team.
<nckx>This was equally unproven, so now we'll see if things improve or not ;-)
<dhruvin>I never saw guix as a distro that experiments with non-conventional ideas, that can later be adopted by others and become conventional. This makes it even more interesting.
<Guest87>i'm having issues deprecating use-package for guix package management for emacs-extensions.. it seems that there are at least two .elc files in my .guix-profile/share/emacs/site-lisp/ (namely site-start.elc and guix-emacs.elc). when i try to start evil-mode by invoking (evil-mode 1) i get "Symbol’s function definition is void: make-closure"
<rekado_>Unthahorsten: my guess: your “guix pull” profile at .config/guix/current uses the newer manifest format, but you’re using an older Guix from before the introduction of that new manifest format version.
<zimoun>Well, I have been too lazy for investigating the huge strace log. Instead, I just reboot. ;-)
<jpoiret>Unthahorsten: when did the error appear? after the `guix pull --allow-downgrades`, or while running that?
<jpoiret>i think you could go the "dumb" way, since you don't care about downgrade attacks: simply `rm -rf .config/guix/current` and `guix pull` using the system-wide guix
<civodul`>zimoun: wrong permissions on /tmp or $TMPDIR?
***civodul` is now known as civodul
<zimoun>civodul: thanks. That’s why reboot fixed the issue. :-)
***wielaard is now known as mjw
<Unthahorsten>jpoiret: after modifying the channels the 'guix pull --allow-downgrades' command or 'guix pull --commit=cabda1197 --allow-downgrades' just produce "unsupported manifest format" errors. I need to go back to an old set of packages
<civodul>Unthahorsten: you can always do "guix pull --roll-back" to get back to where you were before pulling
<Unthahorsten>civodul: Thanks I will try removing my profile and pull again. In fact what I need is to install a set of specific package versions but these are not all available. How to know which guix commit contain a set of specific package versions ?
<Unthahorsten>And what is the correct way to use a channels.scm ? I replaced it and now everything is broken
<rekado_>zimoun: what are your thoughts on wip-guix-log?
<florhizome[m]>I am configuring a new laptop… does guix have a fprintd service and should I worry about secureboot? I‘d like to keep windows around for now (installing guix on a second drive).
<Unthahorsten>Still no luck :( guix pull fails with a build log containing (exception %exception (non-self-quoting 140737321002416 "#<&message message: \"unsupported manifest format\">"))
<jpoiret>florhizome[m]: guix system doesn't have any automation for image signing iiuc
<civodul>Unthahorsten: could you copy the complete output to a paste service?
<jpoiret>you'd have to carry a manual grub.cfg, with an out-of-store kernel and initrd just to be able to sign them i think
<jpoiret>windows can run without secureboot though
<Unthahorsten>I removed all my profiles, guix pull works with my new channels.scm but others commands fails: $ guix package --list-installed
<jpoiret>but you'd have to also add shim and sign grub
<Unthahorsten>I rolled back to previous generation but no, guix commands always return 'error: unsupported manifest format'
<zamfofex>Is there any chance someone could take a look at <https://issues.guix.gnu.org/54832>? (It’s been almost a month.) Though I have been thinking, Glibc 2.36 releases next month, so could it be worthwhile waiting until then?
<Guest87>Unthahorsten: did you add something to one of your GUIX_FOO or GUILE_FOO paths?
<Unthahorsten>Even if I roll back to a generation from May I still have this error
<Guest87>well, system reconfiguration / roll-back doesn't clear your environment and such
<Unthahorsten>No I only overwrite channels.scm with an old file, I have GUIX_PROFILE GUIX_LOCPATH and GUIX_PYTHONPATH but nothing strange
<jpoiret>Unthahorsten: can you look at ~/.guix-profile/manifest and tell us what version it is?
<jpoiret>and also, the output of guix describe as well as `command -v guix`
<zamfofex>civodul: Thank you! Sorry for asking so plainly as I did. Note that I haven’t sent more patches yet, I was waiting for the questions I asked to be answered! Do you feel like it does indeed make sense to wait until 2.36 is released? I was hoping glibc could be updated before the 1.4 release, whenever that happens to be.
<jpoiret>Unthahorsten: did you try to roll-back the `guix package` generation also?
<jpoiret>no, that rolls back only your `guix pull` profile (which contains only guix)
<jpoiret>since your `guix package` profile (the one actually containing your packages) has a manifest version that is too new for your (now older) guix version to understand, you'll need to roll-back to a previous version of that package profile as well
<jpoiret>`guix package --list-generations` and `guix package --roll-back` are what you're looking for for this
<zamfofex>Y’know what? Just a little rant/vent here. I feel like Guix is wonderful, but I have a really sour experience working on anything related to it. Because of its inherent nature, whenever I work on it, things always take a long time (building, running, etc.), so it just becomes a test of patience, which isnot particularly fun.
<zamfofex>And if something doesn’t quite work out, I get late errors and sometimes have to start things nearly from scratch, having to wait through all of it again.
<zamfofex>I have recently decided I want to try to package Deno with help of the ‘crate’ importer. And the importer failed fairly late into importing it for some reason I don’t fully understand (with some kind of TLS error), and now I have to try it again and wait through all of it again without guarantees that it’ll work this time.
<nckx>I completely agree, but don't understand why you'd have to backtrack any work.
<nckx>Or do you just mean wait for the machine to work?
<zamfofex>Well, sometimes changing something can cause for a lot of things to have to be redone. E.g. modifying a package definition that is early in the build tree.
<zamfofex>When I say “have to be redone”, I don’t mean by me (manually), but rather by Guix itself.
<zamfofex>Maybe you should see if it works with the newest version in Guix, otherwise you could try to package 3.02 as ‘xdf-for-swftools’, I think. Are the patches it applies relevant enough, or could they be waived?
<maximed>Not really related to the bild failure, but descriptions in Guix are in TeXinfo, so the list needs some different markup.
<zamfofex>I always wondered something about Guix. I noticed a lot of times, packages sources will be downloaded after e.g. ‘./configure’ was run. Why are such generated files granted the privilege of being considered “sources”?
<maximed>Also IIUC the .git suffix for Git repositories on GitHub is dropped in Guix (or was it the other way around)
<maximed>zamfofex: They aren't, let me find the mail ...
<silicius[m]>maximed: I know, but I left finising touches for later. If you remove pkg-config then it will build just fine, but one of the tools will be left out by ./configure
<zamfofex>maximed: I see! 🤔 Don’t a lot of GNU package sources have auto-xxx already run on them? Would the ideal end goal solution be to download their sources from Git or something?
<maximed>zamfofex: That's one method, but far from the only one. E.g.,
<maximed>in a snippet, 'configure' etc. could be removed.
<maximed>Then a phase of gnu-build-system will automatically run something like 'autoreconf -vif'.
<silicius[m]>maximed: Deleted xpdf bundled source, now it tries and fails to build it's rule needs to be removed as well
<maximed>That way, tarballs can still be used (using git can in some cases lead to cycles, because the http/https/ftp downloader is 'built-in' whereas 'git-fetch' uses a variant of the git package)
<maximed>Though even then some cases of generated auto-... files might remain (e.g. maybe gcc) because of bootstrap problems (you need perl to run autoconf and perl needs a C compiler to compile and GCC uses autoconf ...)
<johnjaye>i've been suprised how much stuff is written in perl
<johnjaye>guix seems to bring all these dependency problems with circular dependencies to light
<johnjaye>althought to be fair if autoconf was in C you'd have the same issue right. gcc -> autoconf -> gcc
<zamfofex>maximed: I see. Though I think it’s difficult to determine which files might have been generated, no? I think there at least should be a way to verify that the patched sources match the sources from Git. Perhaps that could be done as part of the origin’s build? So that e.g. when building the origin, it could automatically clone from Git too and verify the patched tarball matches that.
<zamfofex>Though that feels entirely redundant unless there is a way to skip that verification.
<unmatched-paren>johnjaye: in that case it would almost certainly be possible to built it with tinycc
<unmatched-paren>we can build perl with tcc, but it's rather annoying because perl uses a configure script written in perl
<zamfofex>Also: Did people not realize these generated files were in the tarballs in the past? Or was it simply not a concern? If the latter, what caused for it to start being a concern? Why wasn’t it a concern eariler?
<tribals>Now I'm adopting Guix *package management* for about a year. This is very pleasant, and I'm using it literally for everything: I get software which is missing in my distro. I use it as universal dependency manager for software projects of any language. I think it is time to move to *system management* as well. (Also, my distro seems to be rot.)
<tribals>So, my idea was to: using currently running foreign distro, compose `(operating-system ...)` on it, targeting to usb flash drive, test it on real hardware, then perform actual "installation".
<zamfofex>tribals: From my experience, using the installer is more pleasant. The disc image generated by ‘guix system’ is too small, and specifying ‘--image-size’ requires enough disc space to fit the specified size (and takes much longer).
<tribals>Then, I go to second part: installation. To my understanding, actual installation is performed with `guix system init ...`. Again, IIUC, there is no any difference from where it was invoked: either in Guix System, booted from installation media, or from foreign distro: the result of `guix system init` is the same, as it depends only on configuration passed. Also, even in foreign distro, I'm able to provide correct configuration: file systems, mount points
<tribals>Unfortunately, this method was failed. And I don't see any issues in configuration. I tried to boot with range of options: with root at usb flash drive, in LVM volume, in tmpfs - nothing works. Seems like `guix system init` being ran from foreign distro, produces incorrect bootloader configuration
<tribals>Eg, if I try to boot with root on LVM, then grub doesn't initialize it, so i could not find neither initrd, nor root.
<tribals>I would very appreciate any help regarding my installation issues. If anyone interested, please, take a look at my OS configuration.
<lfam>tribals: So, I would first suggest that you double-check that /boot/efi is mounted at /dev/sda1
<zamfofex>tribals: As an alternative, could you run ‘guix system init’ from a system booted from an image generated by ‘guix system build’?
<tribals>Note that I'm using nonguix channel, so don't point at this, please. To me, using only linux-libre is no-option, as it just doesn't run on my hardware.
<lfam>tribals: It's common to use UUIDs to refer to devices in Guix System, because names like "sda1" are not stable
<lfam>I don't have experience with EFI so I can't offer more specific advice
<lfam>I would also suggest being more specific about how your system fails to boot. Maybe you could share some pictures of your screen on imgur.com or similar
<tribals>lfam: definitely, I can be more specific. Let's trace it by steps.
<tribals>The first step was: use *actual* filesystems supposed to be mounted by running system, in my configuration. That means: every mentioned filesystem should point to actual block device. I'm willing to host guix on separate LVG VG. So, i did:
<drakonis>i should have a working config i can refer to for uefi installs
<tribals>Grub tries to find linux and initrd on - I don't ever know where it tries to find?
<tribals>Secure boot is off-interest right now, but when I proceed with running system, I'm planning to turn it on, and sign my own kernels. That's another story. Let's deal with "running system" part first
<drakonis>otherwise you can just get rid of the block that maps devices and refer to it by uuid
<tribals>Note also that I've tried to reference my root by UUID, as I too prefer to use UUID. No luck. Also, I've refeneced guix-root LV in operating-system mapped devices, in dependencies of file-system, and according to docs, UUID for such case is ever no-option:
<tribals>> When the source of a file system is a mapped device (see Mapped Devices), its device field must refer to the mapped device name—e.g., "/dev/mapper/root-partition". This is required so that the system knows that mounting the file system depends on having the corresponding device mapping established.
<trevdev>If I have built something successfully in a build tree with a command like (invoke "sh" "build.sh"), and I know that the resulting binary is sitting in bin/executable, how may I then invoke *that* as the next step in the build (invoke "bin/executable")? I feel like I might be missing some build variable similar to #$output
<lilyp>trevdev: nope, just do "./bin/executable" if build.sh places the executable relative to the current working directory
<trevdev>lilyp: I thought so. So to be sure, (invoke "bin/executable") should work as it is there relative to "build.sh". I checked the build directory by using the -K flag, the binary is where it should be
<trevdev>lilyp: I can go into my build dir that I kept with -K and run the invocation there plainly and it does not exit, whereas if I run it with (invoke) I get that status 1. Something must be missing by way of inputs or something. Thanks again
<jeko>I'm wondering : I have a guile script I want to call from the shell. So I put #! /usr/bin/env guile on top of it. But then I want to run it from a guix shell environment which contains a Guile. and so my script can't find Guile from inside the environment. Is there a trick to handle this case ?
<tissevert>what values should be used for device and type in the file-system mounted on / to generate a live image ?
<tissevert>I get repeated errors reporting possible lack of disk space but df -h says there's over 17G free
<tissevert>and inode usage on / is even better (43% only)
<yewscion>Hello All, I was wondering if there was currently a way to specify that guix should download all of the origins for a manifest, but not install them. I can't seem to find it documented anywhere, but I have a use-case where I have a long commute that I'd like to have my machine build during, and currently it fails to do so because it only downloads a little at a time.
<yewscion>unmatched-paren: That seems to be working, thanks!
<tschilptschilp23>Hi guix! This might be a dumb question, so my excuses ahead, however - is there a way to run binaries on guix that don't come from the substitute servers or were built on guix system? Not so much for necessity but rather for interest.
<podiki[m]>you mean non-guix binaries? like from an automated "linux build" of a project?
<rekado_>tschilptschilp23: if they are dynamically linked binaries you’ll have a fun game of whack a mole ahead of you.
<podiki[m]>usually they won't work without tweaking, like with patchelf or maybe some LD_LIBRARY_PATH
<rekado_>the first obstacle is the location of the loader
<rekado_>you can use patchelf to fix the binary or arrange for the loader to be in the conventional location
<rekado_>but the next obstacle is to arrange for libraries
<rekado_>lots of packages will need to be put on LD_LIBRARY_PATH
<tschilptschilp23>podiki: yes, non-guix ones. I'm running a small vm-setup with jenkins on guix using qemu with debian, and played around with pipelines. This brought me into the funny situation, that I actually 'bake' binaries, which I can't use on the very host itself ;)
<podiki[m]>a more expected FHS-like container setup would do it, something used for a package in a non-free channel but I would like to make it more general and usable for other cases like you describe
<podiki[m]>so that you could have a `guix fhs-shell` command or something like that
<tschilptschilp23>it's admittedly a very artificial situation... maybe it's time to make contact with patchelf.
<tschilptschilp23>wow, thanks for all your kind input! I will have to wrap my head around the whole FHS-/non-FHS thing, which will take some time!
<ternary>Could someone explain how the certbot service works to me? The manual doesn't ever mention needing to add it to the list of mcron jobs, but I don't see it by running `sudo herd schedule mcron`. When I look at the code though, mcron seems to be how it's doing it's scheduling
<ternary>Is it just implied that you're supposed to add it to the list of mcron jobs?
<ternary>Oh wait, maybe I don't understand the mcron stuff well enough since the example in the manual is also in a service rather than some list of jobs. So why don't I see certbot when its added to my services?
<ternary>Nevermind, ignore me. I just restarted mcron and now it's there
<jab>nckx and anyone else whose interested in reviewing my opensmtpd-records patch: I just posted a video in the last email
<tribals>I did partitioning of my storage space exactly as I would. Now, I want to use it for Guix. It doesn't support my case. There is a bug.
<rekado_>tribals: generally, though, the development workflow is to make changes in your checkout of the Guix sources; combining the checkout with an extra channel is a bit weird.
<tribals>Personally I'm very frustrated with grub at all. It's a mess. I've had not using it about ten years or so. Unfortunately, at x64 guix supports only grub. So, I must tackle with it in some way. In future I'm planning to replace it, but I need to start with something first.
<jab>tribals: ok cool. I thought guix had supported LVM already, but I guess not.
<tribals>I could just fire up patch to mailing list, is very tiny, though. What is the chances that it will be ever accepted?
<tribals>jab: that's in particular strange. LUKS works over LVM, too. Seems like LUKS is supported, but LVM is not.
<tribals>jab: It would be sign that *nobody* actually tried it ever. Then, the question is: what other people using? It would be strange nowadays to not use any mappings in modern Linux