<gnucode>nckx: you could use something like this for your opensmtpd config: <nckx> gnucode: Thanks. That sure... works :) <nckx>Definitely needs to be fixed not to require filter lines to be files but a clever workaround it is. <gnucode>nckx awesome! I am glad it works for you! <vagrantc>nobody else has been feeding sneek lately, eh? <podiki[m]>I don't think I leave enough for sneek to miss me <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>it has something to do with /mnt and failing to find a directory in it <johnjaye>> error: failed to evaluate directive: (directory "/var/lock" 0 0 1023) <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 :) <johnjaye>hello. do you have a bug to report as well? <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 <PotentialUser-29>Hi. I saw David Wilsons (system crafters) video about Herbstluft wm. How can I add it as session to gdm? I don't know where to configure it <ss2>PotentialUser-29: put the package into the list of your system declaration. <PotentialUser-29>ss2 So it has to be in the systems profile? guix package -i herbstluftwm as user is not enough? I was not aware of it. Thank you <PotentialUser-29>ss2: While guix is really good documented it is sometimes hard to find it, though. Thank you <james[m]>How does one become a build farm for Guix. I understand security is not an issue as its reproducible so anybody should be able to contribute builds easily. <james[m]>I have a 16 core, 3.7 GHz CPU computer with 64GB of ram. And that computer I am not always using. So would like to put it to use. <james[m]>I think it would be cool to improve the 'guix weather' numbers perhaps into the 90% mark if enough people do it. <PurpleSym>There is no way to “join” the build farm currently. You can run cuirass+guix publish, but people would have to add your substitute server to their installation manually. <james[m]>PurpleSym: Ah I see. That's unfortunate. <james[m]>I guess that's not possible then. I want to directly contribute build power. <james[m]>How do I run guix challenge on all the packages i have? <james[m]>I followed the docs but it just say no arguments specified. <nckx>vagrantc <nobody else has been feeding sneek lately, eh?> Everyone else uses a bouncer, and sneek is sick of our faces. <nckx>Morning Guix, he said, as he pretended to join. <james[m]>On the manual it is presented like if you provide no arguments but the substitute URLs. It does this automatically. <PurpleSym>james: Yeah, that was changed not too long ago. Maybe something like `guix challenge $(guix package -I)` <james[m]>PurpleSym: Nope. Because it spits out the other stuff not just the names. I could use the cut utility but perhaose there is a cleaner way. <PurpleSym>Ah, sorry, you need `guix package -i | cut -f 1` in the brackets. <james[m]>I see. It would be nice if there was a cleaner way. But it works. <james[m]>Also what if I want to check the reproducibility of all the packages in guix? <PurpleSym>You probably have to resort to writing scheme. <james[m]>guix challenge $(guix package -A | cut -f 1) <james[m]>Its running at least. Talking about packages being superseded. <PurpleSym>Yeah, but there may be multiple versions of each package. <PurpleSym>There’s also hidden packages, which are not in the list. <james[m]>For now. Latest version is good enough for me. <james[m]>I was hoping guix has some public stats on this or something. <james[m]>I think there should be an easy way to do this. In the same way guix weather checks availability. <james[m]>We need something to check reproducibility. <james[m]>I dont mind the fact it has to build the packages locally. I know it would take a very long time. But just looking at the latest versions of the packages would be a good way to measure it. <james[m]>% wise how reproducible the substitute servers are. <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 ***civodul` is now known as civodul
<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 ? <unmatched-paren>if you don't want to mess about with qemu you can use gnome boxes, which is just a friendly UI on top of qemu <nckx>james[m]: So does the manual's 'guix challenge' example need to be updated? <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. <nckx>dhruvin: <Doesn't having package maintainers help accepting patches of updates?> That remains to be seen, it's only ever been asserted as truism. I'm sceptical but any experiment in a storm. *dhruvin opens dictionary :) <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>Nope! This is that experiment :) <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. <nckx>That's a sweet way of putting it. <Unthahorsten>Hello, I just broke my guix installation, I use a foreign distro <Unthahorsten>After a guix pull, some package version I need are missing so I replaced channels.scm with an old file. <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>I get «guix pull: error: bind: Permission denied». What does it mean? <rekado_>zimoun: no idea what would cause this. Is the command just “guix pull”? <zimoun>Is it that my store is somehow broken? <zimoun>Using another user on the same machine, same error. So it is probably my store that is broken. <zimoun>I do not know how to find what could be wrong. )-: <zimoun>Is it possible that it is an issue with the socket? <rekado_>you could attempt to strace -f guix pull <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 <zimoun>rekado_: it needs some work before merge. <jpoiret>Unthahorsten: can you roll back your `guix package` profile? <ss2>I've seen this error message too. But while offloading. <florhizome[m]>Well I guess I can maybe re–enable it to get into windows for now. <florhizome[m]>if I would install guix on top of another distro, maybe there would be a way of retaining their keys 🤔 <jpoiret>well, the issue is not keys but rather being able to sign the images you load <jpoiret>with other distros it's pretty simple with hooks for the linux package, but we... <jpoiret>actually you could just wrap you kernel and initrd with something that adds a signature to them <jpoiret>although you'd most likely have to add your private key to the store for that <jpoiret>(kernel (sign my-kernel)) something like that <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` <jpoiret>if you just guix pulled you might need to log-out log-in <jpoiret>although manifest version 4 is very recent so i'm not sure you've rolled back to a pre-manifest-version-4 package profile <Unthahorsten>After rolling back I just run guix pull and it works, but other commands does not. <civodul>zamfofex: yes, my bad! i'll take another look at those glibc patches <civodul>Unthahorsten: looks like you pulled, the ran "guix upgrade" or "guix install", and then ran "guix pull --roll-back" or similar <civodul>meaning you went back to an older 'guix' command that doesn't understand the new format <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 <Unthahorsten>jpoiret: Thanks it works again after rolling back up to generation 1 ! <Unthahorsten>Then what is the correct procedure to use another channels.scm ? And how to obtain a guix commit containing a list of sepcific packages versions ? <rekado_>zimoun: is any work happening on that branch? I rebased it yesterday, but there hadn’t been any commit since Jan 2021 <zimoun>no, sadly I have not taken the time to complete the missing work for a merge. <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. <civodul>zamfofex: yeah packaging can be expensive if you have to test lots of dependents <nckx>TLS (networking in general) is Guix's Achilles' heel :) <civodul>expensive as in: you have to wait for a long time to know whether your change breaks dependents <civodul>as for TLS: no bug report, no problem :-) <silicius[m]>Got the swftools package working, but it has problems with finding freetype during the configure phase <rekado_>hmm, in the GWL test suite I now also see “unsupported manifest format” *rekado_ rebuilds the environment <johnjaye>hey. any ideas on why my installer failed? <johnjaye>> error: failed to evaluate directive: (directory "/var/lock" 0 0 1023) <johnjaye>it started after it said something about /mnt <jackhill>I'm also open to ideas on how to get them in the archive once we find them :) <silicius[m]>oh wow. swftools bundles its own xpdf with a patch alongside it, not sure what to do with it now <unmatched-paren>silicius[m]: i guess you could make a xpdf-for-swftools that inherits from the original xpdf and adds that patch <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? <silicius[m]>I tried adding xpdf as input, but it looks like swftools uses xdpf's source because it errors out on " #include "xpdf/config.h" <silicius[m]>It's in the source output, but I'm not sure how to reference it in code (to copy it to swftools to replace the bundled one) <johnjaye>silicius[m]: arguably nobody is good at c=+ <johnjaye>er c++. given how templates are turing complete <johnjaye>you're basically programming 2 languages at that point ,not one <maximed>(also, it also challenges the references and not only the package store items of the things in the profile itself) <maximed>james[m] 'And culd be a concrete way to verify third part substitute servers': For cooperative servers sure, but what if they are malicious or compromised? There's a TOCTTOU problem there. <maximed>silicius[m]: maybe in a post-install phase copy the generated config.h to .../include/xpdf/config.h (or was it share/include/xpdf/config.h)? <maximed>something like (copy-file "config.h" (string-append #$output "/share/include/xpdf/config.h")) <silicius[m]>maximed: for now it won't even build. I see during build phase that it tries to unpack the bundled source and then some source errors out that it cannot find xpdf/config.h <johnjaye>isn't config.h autogenerated by autotools? <johnjaye>so it probably can't find some lib. when guix builds packages how does it even work. i need to read the manual on this <maximed>silicius[m]: I thought the idea was to modify swftools to _not_ use the bundled xpdf? <maximed>And hence, to modify the xpdf package to install the required xpdf/config.h somewhere. <silicius[m]>in this case, the bundled xpdf was unpacked to the same dir as the erroring source file and xpdf/config.h exists (relatively to that source file) <maximed>silicus[m]: what's the current package definition? <maximed>(from what I hear, the swftools source code archive includes a bundled tarball of xpdf which is unpacked during configuration or something?) <maximed>That's bundling, which is not accepted in Guix. The bundled copy needs to be removed. <maximed>e.g. with (origin ... (snippet #~(delete-file "the-tarball"))) <johnjaye>meaning in guix every software package has to depend on another guix package, not its own version of that package? <zamfofex>That’s a strange way to word it, but I think that’s it! <maximed>Having dependencies or no dependencies is fine, but putting a copy of some package inside itself and using that is bundling, which is not fine. <maximed>because it makes it hard to actually update the dependency everywhere <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 <maximed>silicius[m]: Where is the bundled copy? <maximed>silicius[m]: lib/pdf needs to be removed. <maximed>Correction: lib/pdf/xpdf-3.02.ta"r.gz <maximed>Correction: lib/pdf/xpdf-3.02.tar.gz <maximed>(the other files in there don't look like bundling <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 <maximed>(i.e., look for certain file names and for 'Generate by ...' strings in those files) <maximed>zamfofex: If you are doing that anyway, you might as well just use the git origin directly (OTOH verification, though even when using git some projects put generated files on there anyway) *maximed wasn't really AFK <zamfofex>Would it be possible to establish “true source tarballs” (for current and old versions) of GNU packages, at least? Or would that require too much coordination, or otherwise be too difficult? <unmatched-paren>zamfofex: I believe most of the GNU packages don't include generated files anyway <maximed>Maybe, but I'd think that just removing the generated stuff for only the versions in Guix (with the method described previously) would be less work and sufficient for Guix. <johnjaye>would it be possible to dispense with gnu autotools? <silicius[m]>I give up on this one tool from swftools, other stuff in the package works and I don't know how to make this one thing work <johnjaye>i mean. a lot of those configure scripts are checking for libraries or what not right. <johnjaye>well guix presumably has the libraries it wants. so why check for them <maximed>There exist non-Guix systems as well. <maximed>And possibly the packager forgot to add the library, so a nice error message would be nice. <johnjaye>are there any source packages that had to be somewhat rewritten for guix and the configure script dropped ? <johnjaye>it checks for libraries and headers right <zamfofex>maximed: I think johnjaye means “do away with autotools *in Guix builds*”. <maximed>Also, some such scripts (not only Autotools, FWIW) also check for versions. <unmatched-paren>it often does things like set up testing frameworks (such as libcheck) <maximed>zamfofex, johnjaye: That's what I meant. <unmatched-paren>if they were talking about one they would presumably say "the makefile" instead <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? <johnjaye>> Debian has long considered that these are not source and so it <johnjaye>regenerates all these files as a first step (IIRC). <johnjaye>by the way, i've had bugs in the past due to different versions of autotools <johnjaye>1.16 seemed to break some autotools scripts <maximed>Guix packages multiple versions of the autotools. <maximed>So if required, we can just give a package and old version of the relevant autotools packages. <zamfofex>Would it be difficult to try to sidestep autotools for packages early in the boostrapping process? E.g. perhaps writing a plain makefile for them manually, for example. <unmatched-paren>johnjaye: Nobody would dare risk their sanity reimplementing autotools. <singpolyma>Usually replacing autotools with a simpler Makefile is trivial <maximed>(so incompatible autotools shouldn't be a problem) <unmatched-paren>zamfofex: I'd guess that gcc's autotools infrastructure is extremely complex <zamfofex>unmatched-paren: Even for the early bootstrapping versions? I’d imagine build system complexity increases *as* a projects matures. <unmatched-paren>zamfofex: We package gcc 4; by then gcc was pretty mature, I'd think? <unmatched-paren>In my experience, he fourth major version generally indicates maturity. <unmatched-paren>Actually it's 4.7.something so it'd be quite far on in the 4.x series too <johnjaye>does guix have a master dependency graphs somewhere? <johnjaye>like showing gcc depends on autotools depends on perl etc. like what graphviz produces <silicius[m]>pass it to a program that understands the format, I think it was xdot <johnjaye>first i must download the substitute for xdot *unmatched-paren checks what the difference is *johnjaye hates the internet <johnjaye>well, i hate how in linux everything is supposed to be always online. so you have to download a binary for even trivial things like file <johnjaye>and with slow internet that's... very painful <silicius[m]>jonjaye: what's the alternative? Stuff needs to be installed before you can use it <johnjaye>well. it would be convenient to have a list of "common-sense" files to have for development <johnjaye>windows even comes with curl by default iirc <silicius[m]>There could be a %common-packages, I ended up making my own list in my system definition <johnjaye>i suppose i'm really complaining about a bootstrapping problem now that i think about it. like how you have a webpage to explain how to purchase internet services <silicius[m]>I think the guix livecd comes with some software already bundled, so unless you run guix pull it will use the locally available packages <johnjaye>like you need curl to get the source code for a package manager but you need that package to build curl <unmatched-paren>johnjaye: Unless it's a really weird package you could use wget or something (or just implement file fetching yourself, probably trivial in perl/python/whatever) <rekado_>interesting that your “common-sense file to have for development” are programs that I don’t use ¯\_(ツ)_/¯ <rekado_>that’s the problem with pre-configuration: can’t get it right for everone <rekado_>johnjaye: with Guix the assumption is *not* that you will always be online. But we do assume that you have some sort of network with services. These can be local. <zamfofex>The solution, of course, is to just download all packages on ‘guix pull’. (I kid. 😅) <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). <johnjaye>the "solution" is to have some definitions of these package sets based on common preferences ***mark_ is now known as mjw
<podiki[m]>tribals: similar to what I did before moving to guix system, started with an os definition on a usb stick to try it out on the hardware first <johnjaye>in my case you could call it "term-devel" for things you need to be productive at a terminal. curl. tmux. w3m. etc <johnjaye>podiki[m]: that's probably a smart idea. i can't get guix to install on my hard drive <podiki[m]>johnjaye: I didn't end up doing an install from that live usb to the system (should be able to use that os config to do it though), but just to test. it is handy though <johnjaye>by the way. why are the hashes in /gnu/store 32 letters long? <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: <tribals> ; (device (uuid "45caa74f-6272-4db5-a83d-1c20fd617d38")) ***ChanServ sets mode: +o lfam
<tribals>sorry for posting code, but I don't see any other way to share it ***tribals was kicked by lfam (tribals)
***ChanServ sets mode: -o lfam
<drakonis>its fine, just use a paste service next time <tribals>drakonis: no, I'm not using matrix. But if you willing to collaborate, definitely, we could find a way to do that. <tribals>Long story short: i doesn't ever boot. <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>if i can safely follow the configuration you pasted <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. <tribals>It is commented out now, but I've tried to `init` system with this configuration, it was failed. <tribals>Also, when I've been doing `guix system init`, I mounted future guix-root to /mnt, and my *actual* ESP to /mnt/boot. I can confirm that bootloader has been installed successfully. <drakonis>set it to lvm-device-mapping instead of luks <tribals>Note that current gist I've shared is modified, at the time of `guix system init`, it was grub-efi-bootloader, not grub-efi-removable-bootloader <drakonis>do refer to the template i linked earlier <drakonis>you set up your device mappings incorrectly <drakonis> (targets (list "vg0-alpha" "vg0-beta")) <tribals>Is that correct? (despite being commented out right now) <drakonis>you can still have it point to an uuid while using device-mapper <silicius[m]>What package I can include in python shell so a program can output sound with pulse? <drakonis>tribals: a similar issue here, perhaps this would help? <silicius[m]>I get `ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave` in guix shell <my-package> --pure <tribals>drakonis: Will check that, thank for now. Will be later. <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 <lilyp>if you get a file not found, that might also be the fault of the dynamic linker <lilyp>status 1 means the command produced an error, no? <Andronikos>I use the guix package from MELPA. Calling it to output all packages results to the error "let: Symbol’s function definition is void: geiser-company--setup". How can I fix that? <tribals>As you can see, grub's lvm module still missing <tribals>Then, from where those `initrd /gnu/store/dc65akk7m63dnlafqgzg7y52vjy5x7jy-combined-initrd/initrd.img` gnu-store things should come? <lilyp>Andronikos: I'm not aware of any particular fix, but you could M-x toggle-debug-on-error to see how this is even called. <lilyp>Note that emacs-guix has gained a little bit of dust and might be broken in parts; both guix and geiser had potentially breaking updates in between <rekado_>FWIW I’m using emacs-guix from Guix and it seems to work just fine. <rekado_>(after a long period of being terribly broken) <Andronikos>rekado_: How did you Emacs detect it? If I install it through the Guix package manager (I am on a foreign distro btw.) it doesn't even show the guix command in Emacs. <rekado_>Andronikos: uh, I don’t know. I don’t do anything special. I think it’s all done via the EMACSLOADPATH variable when Emacs starts. <lilyp>note that you probably need emacs from guix as well to get that environment variables <lilyp>rekado_: I'm pretty sure guix is still broken w.r.t. company integration *rekado_ doesn’t know about that <rekado_>I have company installed, but I’m far away from my Emacs-hacking days. <lilyp>~/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:169:7: Unknown # object: \"#~\"\n\nEntering a new prompt. <lilyp>M-x toggle-debug-on-error M-x company-mode M-x eshell guix <lilyp>That's (invoke-command store machine command) btw. <Andronikos>Well I guess if it isn't really maintained anymore I stop playing around with it. Can a beginner help out on this project or is it to advanced? <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 ? <singpolyma>Your shell needs to have guile explicitly listed to end up on the path <singpolyma>Oh the problem is you used /usr/bin/env which doesn't exist <jeko>it's just in my Guile script I specify how the shell can run guile (the shebang) <singpolyma>If you really want a the and that searches path (usually a bad idea) probably #! guile will work <singpolyma>An interactive version of patch-shebangs would be useful probably <jeko>dunno what it is. I'll search for it <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. <unmatched-paren>yewscion: I haven't checked, but maybe `guix build --manifest=manifest.scm --source`? <rekado_>tissevert: is that lack of space in the image? <tissevert>actually lack of space on the system building it because I stupidly mount a small amount of my RAM on /tmp and then forget I do <tissevert>also because I asked for too many packages in the image I was generating <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 made a patch that adds LVM support to grub-bootloader. Unfortunately, I can't test it because ./pre-inst-env ignores my ~/.config/guix/channels.scm. <tribals>And my operating system configurations depends on other channel. <jackhill>Has anyone thought about working with git or other scm upstreams to make their archive generation more deterministic using techniques we've learned from disarchive? <tribals>rekado_: Would it ever work? The patch touches non-package modules, specifically gnu/bootloader/grub.scm and gnu/system.scm <jab>tribals: Why are you interesting in LVM support in the bootloader? What exciting possibilities does that open up? <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