<jeko>"guix deploy: error: unauthorized public key" but I can see my coordinator key in the target "/etc/guix/acl" <jeko>do I need to reconfigure the target before ? <vagrantc>package still needs lots of work, but at least the majority of the beurocracy is over :) <craftyguy>having the latest versions of things available to install is important for me, but it looks like some packages in guix lag behind a bit. is that something folks could help contribute towards (e.g. by upgrading, testing, sending patches) or is there another reason (e.g. like debian's unstable-->testing flow that delays things on purpose) ? <xelxebar>craftyguy: Pretty sure it's mostly a manpower thing. For some low-level infrastracture packages (e.g. glibc, flex, bison, etc) that are essentially dependencies of everything, the lag is because these require us to rebuild tons of packages. You have to make sure all of that goes smoothly just to do a version bump. <craftyguy>the things I'm most interested in are not low-level packages like that, but things like swaywm <xelxebar>Cool. If you're interested, we would definitely welcome your contributions! <xelxebar>If you're unsure how to proceed, there are tons of helpful (and extremely knowledgeable) people here. The channel tends to be pretty quiet at this time, but if you wait around, you'll get more responses once the active members wake up and join in here. <craftyguy>great. yeah I'm just considering trying out guix at the moment, but wanted to understand if there's a path forward to helping keep some things I care about up to date. sounds like there is :D <craftyguy>my bouncer is up 24/7, so I can wait indefinitely if I have questions :P <dustyweb>g_bor[m]: sorry just got back from a thing, will check soon :) <UnderSampled>So, I was able to get the AppImage to execute by adding the extra-special-file, but it isn't able to find zlib <UnderSampled>error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory <UnderSampled>I tried running in a `guix environment --ad-hoc zlib`, but that doesn't seem to have done anything <craftyguy>I'm a little confused about when to run 'guix pull' vs 'sudo guix pull' after reading the 'after install' section in the manual. when I want to upgrade everything installed on the system, I should do both? <xelxebar>craftyguy: Are you running on a foreign distro, or are you running a full Guix System? <xelxebar>Cool. Then you really never need to run sudo guix pull. <xelxebar>To upgrade your system, just use sudo -E guix system reconfigure. That will grab the guix from your user's environment. <craftyguy>I must have missed a step or something, I get 'wrong number of arguments for reconfigure' *craftyguy has to step away for a bit <xelxebar>craftyguy: sudo -E guix system reconfigure <path to file containing your operating-system declaration> <UnderSampled>How may I get zlib into my search path such that running a foreign binary (like this AppImage) will find it? <xelxebar>Typically, that's something like /etc/config.scm <craftyguy>xelxebar: ah, sorry, I think I recall reading that before <UnderSampled>I keep reading guix folks saying "Don't use LD_LIBRARY_PATH" <xelxebar>Well, it's probably "better" to update the binary's RPATH, but LD_LIBRARY_PATH is okay for testing or a quick-and-dirty sanity check. <xelxebar>UnderSampled: You'll want to put <zlib output path>/lib in that variable. <UnderSampled>And in this case, I'm not compiling anything (silly vendor doesn't believe in free software, I guess) <xelxebar>UnderSampled: See the patchelf tool. It'll let you munge executable files, including setting RPATH :) <xelxebar>For finding an output, you can just do `guix build zlib`. It'll just print the output paths to stdout if already installed. <xelxebar>Depends on what you're doing. Under the hood, guix uses patchelf, I believe, so the "proper" solution would be to simply write a guix package def that uses a trivial-build-system and copies your vendored binaries into the output. Guix will take care of making sure libs and stuff are patched in. <xelxebar>UnderSampled: If you want to know more about LD_LIBRARY_PATH and RPATH, check out the ld.so(8) manpage. <UnderSampled>I was able to get it to work (sorta) with LD_LIBRARY_PATH <UnderSampled>unfortunately, now it appears to not like that I don't have FUSE support <xelxebar>Not sure what you mean. Do you have fuse installed? <lfam>I don't pay as close attention as I used to, but I don't think that Guix uses patchelf, although we do have it <UnderSampled>I have a pretty new guix install without much customization <UnderSampled>One thing I miss from Gentoo is the wiki with information about installing and configuring common things <UnderSampled>maybe I just don't trust it, and running `guix install <package>` is enough 99% of the time? <xelxebar>lfam: Maybe I am misunderstanding guix/build/rpath.scm incorrectly? Looks like it's calling out to patchelf. <lfam>Yes but, as far as I can tell, that code isn't actually being used anywhere <lfam>I think that, instead, we instrument the linker to bake the correct paths into binaries during the build process <lafrenierejm>Has anyone encountered "can't load package: import cycle not allowed" when packaging a Go module? <xelxebar>UnderSampled: The guix info manual is pretty darn good. Granted, you do have to already have some understanding of Guix's organization and assumptions. <lfam>Btw, the source hash is incorrect. If it looks like it is working try `guix build go-github-com-golangplus-fmt --source --check` <lfam>It builds for me lafrenierejm <lfam>Maybe there are some other changes not taken into account by that code snippet? <xelxebar>lfam: Oh, interesting. I clearly haven't looked at things closely enough. Thanks for the pointer. <lfam>You're welcome! During the European day you will definitely get a more detailed answer <lafrenierejm>lfam: Thanks. Works for me too (after updating the hash) with the `--source` flag. <lfam>In general, if your /gnu/store already contains the data described by the hash, Guix won't try fetching it again, so you might not notice that it was incorrect <lfam>It's a common way to get tripped up <lafrenierejm>This is just one of several dependencies, so I had reused the hash of the package immediately prior. <lfam>Yup, that's exactly how it happens :) Or you change the version and forget to change the hash, etc <lfam>I usually change a single character of a copy-pasted hash to avoid this (the first character has to be 0 or 1) <xelxebar>lfam: Any chance you are familiar with samba? <UnderSampled>surely I shouldn't add all of those packages to my LD_LIBRARY_PATH? <UnderSampled>maybe, is there a way to have `guix environment -C` put symlinks in the container's /lib64? <xelxebar>UnderSampled: Ouch. That's a huge pain. Yeah, you could install all the required packages in an environment and then put $GUIX_ENVIRONMENT/lib in LD_LIBRARY_PATH <xelxebar>If you supply all the right packages as --ad-hoc arguments to guix environment, then it should. <xelxebar>:) That's the hard part. Unfortunately Guix doesn't (yet) have a command to find a package for a given filename. <xelxebar>This is in the works and seems like it'll land soonish, but that doesn't help you now ;) <xelxebar>Your best bet is to probably use a different package manager's tooling to find packages for each lib that ldd outputs. For the most part, package names are mostly universal. <xelxebar>Or you could just use an internet search. <UnderSampled>is there a way to see what packages depend on a given package (not the other way around)? <UnderSampled>I made an environment for GIMP, and that seems to have gotten most of what I need <lfam>I hate to say it but there are 3 different ways, depending on your goal <lfam>`guix refresh --list-dependent nss-certs` will list the packages that will be rebuilt if nss-certs is changed <lfam>So, direct and transitive dependencies, although it doesn't account for dependencies of build systems <lfam>The second one: `guix graph --type=reverse-package nss-certs`. It gives dependency graph data in the "dot" format. So, you can use `dot` to draw graphs or use another program to parse it <lfam>Finally, `guix package --search=. | recsel -e 'dependencies ~ "nss-certs"' -p name,version,synopsis` <lfam>That uses `recsel` from the recutils package to print human-readable structured text, and it will show you the direct dependencies <lfam>The first one is for packagers, the second one is for "real" analysis of the graph, and the third one is for reading <lfam>I think it's a bit confusing <lfam>Parsing the dot format can take a looooooong time if the graph has many nodes, so be patient if you get a lot of results from the `guix refresh --list-dependent` method <xelxebar>lfam: Dang. That was a nice mic-drop answer. The recsel trick is neat. I had no idea the human-readable guix output was actually a standard of sorts. <lfam>`guix graph` is the most powerful and flexible one <lfam>Yeah, the recutils are a good compromise between structured and human-editable! <lfam>I'm not sure though UnderSampled. It could be, but IIRC `refresh` pre-dates `graph`, although it would not be surprising if it was tweaked to reuse the `guix graph` code <lfam>Yes, although it gets unwieldy for packages with a lot of reverse-dependents. The xdot is a nice and simple interface <lfam>You can do this: `guix graph --type=reverse-package nss-certs | xdot -` <lfam>It's from the graphviz package <lfam>My bad! It's its own package, xdot <UnderSampled>normal dot took a long time, complained of it being to large (warning, not error), and then some reason didn't actually save anything <lfam>It shouldn't crash but it's a big graph and will take a while to process <ryanprior>New in emacs-guix-packaging: M-x guix-packaging-insert-input prompts you for a package string (eg "ruby@2.7.2") and inserts the corresponding package input, ie <ryanprior>It uses completing-read to save you the hassle of looking up the exact package string. <xelxebar>What instatiates /run/setuid-programs? When rolling-back to a generation with extra setuid progs, /run/setuid-programs isn't getting populated with these progs. <xelxebar>The docs say that one needs to reboot when rolling-back, but I'd like to do things manually. <db48x>I'm trying to install something via guix, but the sed package fails one of its tests <db48x>since everything depends on sed, this is a bit annoying <db48x>I have a patch to sed which I think will fix the problem, but I'm having trouble making a sed package that uses the patch <db48x>guix/ui.scm:1936:12: In procedure run-guix-command: <db48x>error: search-patches: unbound variable <db48x>can anyone make any recommendations? <ryanprior>db48x: I think you'll need (modules '((guix build utils))) <UnderSampled>the package "nss" has some of the libraries I need, which are in it's /lib/nss folder, but some reason the nss folder doesn't appear in $GUIX_ENVIRONMENT/lib <db48x>ryanprior: an interesting idea, but it doesn't change anything. also, search-patches is defined in (guix packages)… <db48x>libgcc_s is automaticly included by gcc whenever it decides that it is needed <ryanprior>db48x: ah well sorry for leading you wrong there :\ I've had similar issues related to modules not being loaded before, I'm not very good at troubleshooting them though <lafrenierejm>craftyguy: I'm not an expert, but I don't think those exceptions are anything to worry about. <UnderSampled>now, I have --ad-hoc gcc-toolchain, but it doesn't find libgcc_s <UnderSampled>so, which package would it actually be in, or what folder would it install to? <ryanprior>I see libgcc_s on my system in the gcc, gfortran, and gcc-objc++ guix packages <UnderSampled>when I try putting just gcc in the ad-hoc, it says it's superceded by gcc-toolchain <db48x>ryanprior: I'm surprised that they aren't shared <ryanprior>They have the same hash, so I suspect they are hard links <ryanprior>I don't actually know enough about filesystems to check X.X <UnderSampled>how do I actually get gcc (not gcc-toolchain) into my environment? <UnderSampled>I just tried putting gcc-toolchain on the left of --ad-hoc, but it doesn't seem to have done so <ryanprior>You gotta ask for gcc-toolchain, the gcc package is hidden from the CLI <ryanprior>You'd want it on the right of the ad-hoc though I'm pretty sure <UnderSampled>I do, but it doesn't actually add the lib to the environment <ryanprior>UnderSampled: I reproduced your issue with this command: guix environment --pure --ad-hoc coreutils gcc-toolchain grep dash -- dash -c 'ls $GUIX_ENVIORNMENT/lib | grep -i gcc' <ryanprior>I would have expected to see it in there (spelled environment wrong, but it still doesn't work if you spell it right) <ryanprior>So I don't know what the deal is or how you get that library in your profile. I can see it's there in the package, so why doesn't it get pulled into profile. Dunno <ryanprior>I don't know, could be intended behavior for some reason, could be a bug in the profile hook that builds that libs, could be a problem with the package, I'm pretty ignorant of how gcc-toolchain is supposed to work <db48x>I doubt it's a bug in the gcc-toolchain package, since everything else manages to get built somehow <UnderSampled>I'm looking in the store, and it looks like that .so is not marked as executable <UnderSampled>I added the folder directly to my LD_LIBRARY_PATH, and it still didn't show up <ryanprior>You shouldn't have to add anything to your ld library path <UnderSampled>ryanprior: you may have missed the context that I'm trying to run a precompiled executable from an AppImage <ryanprior>I definitely missed that, don't know why that means you need ld library path but please ignore if that's not a helpful comment =D <UnderSampled>adding the $GUIX_ENVIRONMENT/lib to the ld library path gets most of what I need found (without having to use patchelf to change the rpath) <UnderSampled>it just misses the nss folder (since it's not recursive), and apparently libgcc <UnderSampled>but I'm not sure if the latter is because of the .so itself <abcdw>How to build emacs package with specific emacs version? Trying to do something like `(parameterize ((%emacs rde-emacs)) emacs-use-package)`, but it doesn't work( <abcdw>it still builds use-package with emacs 27, but rde-emacs is 28 and can't use resulting bytecode. <mroh>abcdw: take a look at eg `guix edit emacs-magit` ***leoprikler_ is now known as leoprikler
<abcdw>mroh: It uses gnu-build-system and have emacs as a direct dependency. But my question is a little bit different, how can I build already defined packages (which uses emacs-build-system) against different version of emacs. <abcdw>mroh: According to what I understand from source code, it seems that it should be enough to redefine %emacs parameter, but for some reason it doesn't work( <mroh>abcdw: emacs-magit uses emacs-no-x to compile the package. You might do the same: (arguments `(#:emacs ,your-emacs) ...) <nckx>zzappie: Rather late to the party but check out Bluefish as well if don't mind a little clutter. (It has tabs! ...and an update, ooh.) <civodul>hi kurisu! maybe you need to run "guix pull" to get up-to-date packages <kurisu>i already tried, but i will redo it and read in case there's a message or error <civodul>then make sure your shell refers to the latest guix, i.e., ~/.config/guix/current/bin/guix <abcdw>mroh: oh, ok, I looked at old version of the package and it didn't have #:emacs argument. Ok, will try to redefine arguments for all the packages I use. <abcdw>g_bor[m]: Yep, I can try package-input-rewriting, thank you for the tip. <abcdw>Oh, I see, emacs-build-system uses parameterize inside, that is why my trick didn't work. Yep, I should specify emacs as an input to packages. mroh, thank you. <mroh>abcdw: yw! btw, according to C-x v h it has this since Mar 27. ;) <abcdw>mroh: probably I have guix somewhere around ~v1.1, because disk-image was broken on recent commits. *civodul runs GC on berlin <db48x>why does installing glibc-utf8-locales require ghostscript, libtiff, libjpeg, etc? <efraim>it looks like macs has cython generated files in it <civodul>db48x: it's probably due to "profile hooks", which generate for instance the GLib schemas in your profile, etc. <efraim>I'm putting on my TODO list adding a phase to the python-build-system to check for files generated by cython <efraim>I got most of the way there with python-efl for a general purpose snippet for deleting them, just need to add phase to check 'head -n1' for 'Generated by Cython' <jeko>I am trying to play with "guix deploy". But failed with the error "guix deploy: error: unauthorized public key" <jeko>I checked on the target /etc/guix/acl <jeko>so it should be authorized...isn't it ? <db48x>civodul: that's a good idea; if I can download things I won't have to build them, which means I don't have to fix sed before I can do anything interesting <db48x>lol, guix substitute: error: host name lookup error: System error <civodul>the installation script now explicitly checks for it <db48x>no, I'm running with selinux <db48x>Nov 09 01:01:48 erebor audit[840963]: AVC avc: denied { read } for pid=840963 comm=677569782073756273746974757465 name="resolv.conf" dev="sdh3" ino=134977754 scontext=system_u:system_r:guix_daemon.guix_daemon_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 <civodul>i'm not familiar with SELinux but there's a policy file in Guix, maybe that helps? <db48x>yes, I've been editing it as I go along <db48x>if I ever get it to work I'll post a patch <vits-test>jeko: > Each target machine must authorize the key of the master machine <jeko>vits-test: I copy paste the content from /etc/guix/signing-key.pub is it OK ? <jeko>and pass this file to "guix archive --authorize" <jeko>maybe I need to edit the content a bit ? <vits-test>guix archive --authorize < file.pub # supposed to work <vits-test>examples in manual have "use alice identity id_rsa port 2222" <civodul>db48x: that'd be great, thanks for looking into it <vits-test>jeko: do target has ssh-server running, with user keys auth-ed? <jeko>I am connected to the target via ssh and my machine.scm contains (user "root") (identity "/home/jeko/.ssh/id_ed25519.pub") (port 2222) <jeko>(I don't bother to allow root connection as I am just experimenting) <vits-test>example has not "/home/alice/.ssh/id_rsa", but "./id_rsa" <jeko>(tho error = same error?) <jeko>I presumed all path in the machine.scm file are relative to my coordinator file-system <jeko>vits-test: thank you for taking time to help anyway, I appreciated ;) <zzappie>nckx: Hey didn't know about Bluefish. Ooh it has lot's of menu bars :) In our case Atom won the contest even though it didn't satisfy the first criteria of "not being a browser". It has plugins for scheme and also other things like paredit <nckx>zzappie: Glad you found a winner! I found Atom/browser-based-interactive-anything distractingly slow. <civodul>davidl: hi! it must be a typo in the description of a package in one of the channels you use <nckx>civodul: That reminds me: ‘guix search/show’ not showing channel names, is that by design? Or due to some limitation? <nckx>And yes, location: works for me since I don't use gnu/, but I don't think that's a rule? <civodul>nckx: yeah you can use location: to find out which channel it comes from, but it's probably not ieda <zzappie>nckx: Emacs Doom config was close to winning. It creates an illusion of modern conventional text editor but still emacs weirdness (with vi weirdness on top). <zzappie>I've came acros this notion (don't remember where I've read it) that nodejs and electron based apps being extremily hard to package in Guix. <dannym>But that's mostly because npm and nodejs don't understand modularity. It's very difficult to package things which have so many cycles in the dependencies. <dannym>(Not to mention the upstream npm repository allowed a disgruntled programmer to delete releases, breaking all users...) <dannym>I'd like to use some node packages myself (icestudio fpga ide, Ledger wallet admin, atom editor etc), but every time I touch it it's just this entangled mess <db48x>dannym: are you creating a guix package for every npm dependancy? <db48x>seems like you could just package the whole wad into a single guix package <dannym>In my opinion, if this is to be fixed, someone needs to champion fixing it. (That someone will not be me, at least not this year) <dannym>db48x: That's not good for security updates. At that point, I can just not use Guix--it is possible to just use node itself to get it <dannym>db48x: Also, I agree one could group together some of their one-function-libraries into one guix package, for multiple of such groups. But now you really need some serious graph theory to solve that automatically ;) <db48x>hmm. I'm not sure how it makes much difference. a security update to one of the dependencies needs to cause a guix package to be rebuilt <dannym>db48x: Yes, but how to find whether it's affected or not <db48x>but it doesn't matter much if you update the whole wad or just one part <db48x>dannym: cron job that downloads the whole wad, and checks to see if the hash has changed? <cbaines>It's more about breaking the concept that package names/versions mean something. <nckx>jeko: I can't view the animation so not sure if this answers your question: /etc/guix/acl isn't user-modifiable state anymore, it's now managed by Guix based on authorized-keys (see etc/news.scm for the announcement). Don't edit it by hand. <db48x>though we shouldn't let the perfect be the enemy of the good, and all that <cbaines>If you know there's a vulnerability in node-foo version 4 and 5, then you can look at when that was in use, and what packages are potentially affected by looking at the package definition for node-foo, and things that use it <cbaines>If you start keeping copies of node-foo at some version inside other packages, then that problem changes to having to scan the contents of all packages, back through history, to try and work out what's going on <zzappie>In't there already similar hack in cargo build system in guix? <dannym>And when I said "champion fixing it", I mean "champion fixing it UPSTREAM, not in guix" <jeko>nckx: yeah you have to download the gif to see the animation... I used "guix archive --authorize < coordinator.key.txt" to add the key <nckx>Yeah, that's very recently deprecated. <jeko>nckx: oops so I should use something else to share <jeko>ok ! i'm looking for the news.scm in order to read it <dannym>zzappie: Not really. There is some weird contraption in cargo-build-system because rust libraries are more like static libraries, so you need to have the source of everything. But that's not really the same thing otherwise <nckx>jeko: Thanks, I could telecharger and voir your fichier just fine. I don't think IceCat is to blame here. <dannym>zzappie: In my opinion, rust dependency management is better than what guix usually uses (they use semantic versioning, feature flags; and bootstrapping works all the way down to C++ etc), so it's the opposite of node in this (node's versioning is a hot mess, bootstrapping is not thought about etc) <dannym>But I would be very happy to be proven wrong <civodul>dannym: Rust bootstrapping is a thing because you worked on it, no? :-) <civodul>it's not like upstream Rust cares about it, AIUI <dannym>civodul: Well, and thepowersgang ;) <jeko>nckx: I found the news paragraph! Thank you for pointing it out! I have something to try <dannym>civodul: True--but it does work. And it keeps working for years now--so let me rephrase it as "someone in the Rust community, anyone, cares about bootstrapping" ;) <dannym>Which is more than I can say about most other projects <civodul>dannym: true, but you're a key factor of that :-) <zzappie>dannym: Maybe it's too late for a champion in this case :) <dannym>(Come to think of it, rust libraries are more like C++ template libraries. There, too, you need full source (in the "header" files--hah) in order to build dependents) <dannym>zzappie: Is it? I'm not really in the Javascript community at all, so I wouldn't know. <zzappie>dannym: Me neither it is just seems too huge and wild to me <dannym>As far as I understand it, npm is the main distribution mechanism for both server-side Javascript and for Javascript client apps. <db48x>even for the ones that are in the browser <zzappie>dannym: and it's taken over by microsoft o_o <zzappie>They dropped me a letter with these "exiting news" this summer as I remember <nckx>I'm sure you couldn't contain yours. <abcdw>I changed #:emacs argument for emacs-use-package, but deminish (dependency of use-package) still built with old emacs and as a result bytecode doesn't work. Is there a way to use different version of emacs for all emacs packages? <leoprikler>not afaik, you'd have to craft your own package-with-emacs <db48x>wouldn't the --with-input option be able to replace the emacs package with a different one? <abcdw>leoprikler: it means that emacs-next package is useless, because you can't use any of emacs-* packages with it <abcdw>db48x: idk, I tried to use package-input-rewriting, but emacs-build-system takes emacs package from arguments, not from inputs afaik. <jlicht>nckx: I think the issue RE hibernation and disk corruption was booting into a system _without_ the the "resume=..." kernel argument after hibernating. Definitely a case of PEBKAC I would say :-). <leoprikler>maybe pebkac, but this still sounds like a problem that guix should prepare for <nckx>jlicht: You would have had the same result even with resume=, since it was ignored. <leoprikler>given that it provides you many generations to choose from <jlicht>guix makes it too easy to damage the space-time continuum :-) <jlicht>but I would indeed 100% prefer "I'm not booting, as that would probably hose your disks"-esque messages though <nckx>TuxOnIce handled this better (horrible shouty ‘UI’ but it worked) but it's dead. It would warn you if it detected a suspended image on the configured swap device and present an interactive prompt. <nckx>Linux proper just doesn't even. <nckx>‘Not completely destroying file systems’ is after all a policy, not a mechanism, so putting it in the kernel would be evil! /s <nckx>We could do our own scan in the initrd. <jlicht>nckx: Issue is that the hibernation data can be located in many places. <nckx>But it's orthogonal to supporting resumption. <jlicht>and assuming we are in a system generation where we have no resume configured, we would need a heuristic to determine this. (Or try them all?) <nckx>It really would be a scan, with all the horribleness that entails IMO, but some people like that. <jlicht>Could we at least such hack testable? So a system test of sorts to demonstrate "look ma, no disk corruption" <jlicht>s/at least such hack/at least make such a hack/ <nckx>I looked it up and QEMU supports hibernation. <jlicht>cool, I'll look into making QEMU corrupt the disk first ;-) <nckx>I feel the urge to repeat that b9abb301 in no way ‘enables hibernation’. It makes it possible to resume without corruption. It's still possible to corrupt your disc, but previously that was the only possibility 😉 We're on par with other distros now. In future we can do better. <mroh>abcdw: I don't think emacs-next is useless, because I use a (modified) one since some weeks. It runs (my) emacs packages in unmodified emacs27 bytecode w/o problems. I guess, the problem is the use-package (macro/bytecode) wizardy. <jlicht>nckx: I didn't mean any of my messages in a way that reprimands or blames you for these issues, FWIW. <db48x>well, I think I have an selinux policy that allows "guix install" to work <db48x>of course there's all the other guix commands that still might not work <abcdw>mroh: ok, true, some other packages works even compiled with emacs27, but still not cool that there is no simple way to specify default emacs for emacs-build-system. <db48x>and maybe guix pull works too <db48x>guix remove didn't need anything extra <db48x>guix repl fails, but there are no selinux errors <db48x>guix/ui.scm:1936:12: In procedure run-guix-command: <db48x>no code for module (ice-9 readline) <db48x>is there some simple example of the guix system vm/container commands that I could try out? <db48x>just the simplest thing that can run bash or something <leoprikler>Well, the thing is vm/container require different config than normal (specifically you'd set a password for your users), but I personally use `guix system vm config.scm` -m 2G quite often <leoprikler>[specifically whenever I need to check, that something in GNOME works as expected] <efraim>not that much different. containers don't need a network listed but you add --network to the command <efraim>alright, there are a bunch of things you can leave out, like most filesystems <db48x>oh, and I'm using guix in Fedora, rather than an actual guix system <db48x>so I don't have a config.scm handy :) <civodul>db48x: just run "guix system vm config.scm" and you'll see :-) <db48x>no such file or directory :) <jas4711>how do guix handle libraries which dlopen() other libraries wrt library search paths? i'm trying to use libxmlsec which dlopen libxmlsec1-gnutls which fails. on "normal" linux systems, dlopen will search standard library paths, but on guix dlopen won't find libxmlsec1-gnutls that way <db48x>civodul: I actually tried the first one on that page, but it is missing module imports <civodul>db48x: hmm could you paste the error you got? <civodul>it definitely works for me on current master <db48x>/home/db48x/src/test.scm:48:35: error: openssh-sans-x: unbound variable <db48x>hint: Did you forget a `use-modules' form? <civodul>jas4711: hi! often the solution is to hard-code the .so file name in the dlopener <civodul>but it really depends on whether you want dynamic composition or not <jas4711>civodul: okay, this would be inside xmlsec which is provided by guix so i'm not sure how to do it <civodul>db48x: openssh-sans-x was added in June, so you can either "guix pull" or comment out that line <civodul>(note that the manual at /devel is for current master, continually refreshed) <civodul>jas4711: you'd patch the source file of xmlsec that calls dlopen <roptat>jas4711, I think dlopen also looks for libraries in the rpath, if that helps <jas4711>i wonder why it fails to find libxmlsec1-gnutls then, it should be on the rpath. <db48x>civodul: thanks. I thought I had pulled the latest version, but perhaps there's something else to do there <jas4711>thanks. i'll put this on the rainy-day-todo list <roptat>probably libxmlsec1-gnutls is part of xmlsec? then you'd need to have xmlsec be part of the rpath of your binary <civodul>db48x: maybe you're still running the previous version; did you type "hash guix" & co. as indicated upon completion? <roptat>you can always use strace to see where it tries to find that library, and readelf to find the actual rpath <civodul>db48x: does "guix show openssh-sans-x" succeed? <jas4711>roptat: it should be. i'm trying to fix the oath-toolkit definition included in guix to link with xmlsec1 for pskc support <db48x>guix is hashed (/usr/local/bin/guix) <db48x> db48x ~ ll /usr/local/bin/guix <db48x>lrwxrwxrwx. 1 root root 54 Nov 6 06:50 /usr/local/bin/guix -> /var/guix/profiles/per-user/root/current-guix/bin/guix <roptat>make sure you have ~/.config/guix/current/bin first in your $PATH, run "hash guix" again (no output), now type guix should tell you it's in ~/.config/guix <civodul>maav: ¡hola! «Material audiovisual» :-) <maav>civodul: hola! Yep, I've checked with other people and accessibility guides and it seems the best term <maav>i hope i fixed all the points that could make the translation too localized, but reports, as always, are welcome :) <db48x>roptat: thank you; that fixed it <jeko>I am struggling to append a key with %default-authorized-guix-keys <db48x>although there's still some confusion. one of my shells has GUIX_PROFILE=~/.guix-profile, the other GUIX_PROFILE=~/.config/guix/current <maav>db48x: the former should be the good one, the latter should only be seen by guix command <maav>civodul: it wouldn't be like that if the project wasn't as great as it is :) <civodul>roptat: should we update the banner on the web site? <jeko>civodul: Ha! It seems it does help! Thanks !! I can move to the next error message… haha <jeko>I used append instead of list <jeko>civodul: Oh I have to use both hahaha (next error solved xD) <maav>reading that example twice i see that perhaps would be better using cons instead of append+list, wdyt? <db48x>maav: oh, I see now. thank you again :) <jeko>maav: as I don't need more keys I guess cons can works, will try it ! <civodul>maav: there are many places where we started using append+list instead of cons because "append" and "list" are actual words anyone can understand, whereas "cons" is a bit obscure <maav>s/anyone/any english speaker/ ;-) *civodul would love to see a plan for Scheme i18n <jeko>cons only takes two parameters ? <maav>it helps anyway (as checking a dictionary is easier than checking Lisp history) <civodul>right, and then you'll see "cons cells", "car", "cdr", bah <maav>jeko: yup, cons "constructs" a pair <db48x>civodul: do you mean localizing the scheme function and macro names? <jeko>(so append + list can be more generic for my lazy self who like to copy/paste/customize to try things out quicly before going deeper into the details) <db48x>but I guess there's no reason why you couldn't load a bunch of new definitions <civodul>it's technically possible, but it's of course a can of worm, just like languages in the real world <db48x>next you'll want to load an existing source file and see it localized into your language :) <maav>well, it's a big effort, and unis usually like to create their own and not-compatible-with-anything language... but it's doable <civodul>nowadays a kid who's a native English speaker can prolly more easily learn programming than another kid <lalo_salamanca>Guys, how can I install guix on olinuxino lime2? Currently aarch64 as shown on download page is meant to be installed on top of gnu/linux OS <civodul>lalo_salamanca: you'd have to create the image yourself <civodul>either by cross-compiling from x86_64, or building natively on the AArch64 machine <civodul>the easiest way may be to install Guix on top of a "foreign distro" on the Lime2, and then use "guix system init config.scm /" <civodul>you have to be prepared for some debugging if you follow the approach above, though <lalo_salamanca>So on debian I install guix with binary and then you suggest guix system init config.scm? <maav>with the / at the end, it needs the path <leoprikler>I personally prefer "car" and "cdr" to "kopf" and "fuß". <maav>leoprikler: all my life thinking that car was a vehicle and now it means head, what a world is this... :-P <zzappie>lalo_salamanca: you can also check out the gnu/system/examples/beaglebone-black.tmpl in guix repo as starting point. <maav>i wouldn't translate them (neither cons) as they don't map to english concepts neither, they match to pdp registers, hehe <leoprikler>In German we sometimes refer to the start of something (the car of the list) as "Kopf" (engl. head) and to the bottom as "Fuß" (lit. foot, but english speakers are probably more familiar with tail in some places). <civodul>then we'd see people write (coche lst) because of translator misunderstanding <zzappie>maav: srlsy? I never went out searching fo etymology of cons car cdr <maav>i was just joking, the thing is that car means content address register, something that isn't even useful in current lisps <abcdw>mroh: I have another interesting point. How to use native comp with current emacs-build-system? <leoprikler>car/cdr are registers, cons is short for "construct" iirc <lalo_salamanca>Guys, I want absolutely lean guix for server. I can get that right? I want no DE, just some virtual terminal for server <zzappie>lalo_salamanca: it is a file in guix repository <maav>zzappie: yep, seriously, but it wasn't pdp, wiki says it was an IBM704. My memory fails sometimes, hehe <leoprikler>btw. try using gender-neutral terms such as people, [Gg]uix, or comrades ;) <zzappie>maav: Ok :) I gues many people don't care why they called this way once learn. Especially because there are caaddr and cdddadddr don't know how to translate theese <zzappie>leoprikler: I guess stickingwordstogether doesnt bother german speakers at all <maav>i would translate them as "bad code" anyway :-P <db48x>leoprikler: why would that be troublesome? <leoprikler>dunno, might not be permitted in some business settings <leoprikler>thankfully, srfi-1 gives us erste, zweite, dritte, vierte… <abcdw>civodul: I find emacs-build-system a little inflexible, I can't easily specify emacs package, which will be used to build all emacs packages and their dependencies. That means that I can't use some packages with emacs28, because they are compiled with emacs27. Probably it will be more problem with native compilation of emacs packages. Am I missing something? Or it's really no easy way to do so right now? <civodul>it's great that we've already identified potential pitfalls of this whole endeavor :-) <civodul>abcdw: this is not directed specifically at me, right? :-) <db48x>abcdw: as a point of reference, is it possible to swap out the gcc used by the normal build system? <leoprikler>there is --with-c-toolchain, but it's rather fresh <leoprikler>my personal tendency is still towards manifests and explicit package mappings <db48x>perhaps something similar could be done for emacs then <leoprikler>IIRC --with-input should already capture implicit inputs, such as emacs <maav>leoprikler: regarding srfi-1, those names are the only sensible choice from my POV, i don't know why aren't they already in rnrs before starting with a "large language" <leoprikler>I disagree, there are meaningful uses of (cdaddar) et al. <abcdw>leoprikler: the problem that emacs passed using #:emacs argument, not inputs -> with-input won't work( <db48x>sensible especially for things that aren't straight lists <abcdw>civodul: Sorry for mentioning your for different questions, but you almost always have great ideas or suggestions) <leoprikler>abcdw: does it not even end up being an implicit input? <abcdw>leoprikler: Not sure what do you mean by implicit input, from what i see, it end up being build-input for resulting BAG. *zzappie thinks caddaddras are usefull in some cases. I once wrote functions like deepfind in python. Because i didnt have them <abcdw>leoprikler: guix/build-systems/emacs.scm:78 <maav>nobody can say that cdaddar isn't concise, but i disagree about meaningful for the reader: we usually don't read all the letters on a word and that's the living example of a word where you have to actually count the letters to decipher its meaning <db48x>maav: true. that's why you always rename it <jlicht>cdaddar is amazing for code golf <db48x>make an accessor for your data structure with a sensible name, but whose definition is just caddr <db48x>but I wouldn't use third everywhere in my code either; it doesn't have a specific name <maav>the accessor has to be renamed because the local domain of knowledge "needs" specific symbols, but the implementation with third is more readable than with caddr from my POV <db48x>the others though, the ones that let you access the branches of your tree <db48x>it would definitely be a loss to get rid of them <leoprikler>cdar is almost as important as cadr once you know sxml exists <maav>i wouldn't remove them, as old code shouldn't be changed just for that reason, but I think a tree access should be performed in tree terms, not as pairs of kind-of-lists-but-really-pairs <maav>if you have to pay for each letter you type, that'd be great... but (left-leave (right-leave (left-leave x))) might be more verbose but seems to me easier to read and to maintain <maav>yes, homophones and my sleepy mind, hehehe <maav>yup, that's right, it would be branch, wouldn't it? <leoprikler>that's the thing, people are divided on what to call that <leoprikler>also there is discrimination of non-binary trees *zzappie finds very funny how the conversation about "how make scheme more accessibe" spawned a discussin with lot of strange looking words impossible to comprehend :) <leoprikler>c[ad]*r also does that to some extent, but still less so <divoplade>Isn't it easy to implement general trees on top of binary trees? Isn't it how scheme works? <maav>well, i don't see c[ad]*r as a fair ground for trees neither... not even lists are first class after all <leoprikler>and (tree-index* t 1 2 3 4 5) or (t12345 t) is not much more readable either <maav>divoplade: sure, you can implement them with pairs, or even vectors <leoprikler>divoplade: to implement non-binary trees with pairs, you first have to implement lists with pairs <maav>leoprikler: the problem is that c[ad]^nr are actually n operations, and keeping clean names and compressed operations are two objectives quite hard to obtain. I'm tkw <maav>sorry, hit enter by mistake <maav>i'd like to leave the compression to the compiler, and the full meaning to the reader <apteryx>are EFI file systems always to be mounted at /boot/efi? <apteryx>In other words, is this a reliable signature to detect a EFI file system? <maav>apteryx: nope, it shouldn't be <maav>there are /sys variables for efi systems... but the esp mark in the partition table should tell which one is used to boot <zimoun>cbaines: hey! Nice post. The images greatly improve compared to the draft. :-) Well, I have not seen an email to guix-devel about it. <apteryx>maav: OK, thanks. Seems there's no way to strip out the EFI from the examples under gnu/sytsem/examples/*.tmpl then (this would have been useful to turn these templates into something readily bootable when using 'guix system disk-image'). <maav>apteryx: what do you mean with strip out the efi? <maav>i guess that changing the bootloader to just grub would make the trick, but i'm not sure what's the problem you're facing <maav>i see in grub.cfg:install-grub that the installation is not performed on disk-images... that could be an issue <maav>disregard, there is another function for that... then i'm lost :( <maav>luis-felipe: thank you a lot, i'll check these out :) <maav>regarding overview i used página principal, but if vistazo seems ok to you it's a real translation and not a fuzzy term (and a workaround for the current problem that it leads you to the english version) <maav>cool, also i though that revertir was an anglicism... but it comes from latin and it's widely accepted, so one fake-false-friend less on my list :) <apteryx>maav: I meant removing the EFI file system from a user-provided operating-system when generating disk images, because the disk image machinery already populates its own efi partition/file system. <apteryx>that's the case for our lightweight-desktop.tmpl and desktop.tmpl templates, for example <maav>luis-felipe: regarding the use of the femenine as neutral: persona is a femenine word, not being able to use that as the neutral term only indicates the "machismo" in which we're currently educated, not a correct or incorrect usage. You wouldn't hear or read it from the news, because the male-dominated culture isn't something easy to change, but that position tries to be a minimal contribution to it <maav>and i say that because it felt weird for me at some point too, but it shouldn't be <luis-felipe>maav: I understand the machismo part, I live in a Catholic region. But if the change is left to people, then I would choose to use the termination -e for nouns instead of -o or -a. At that point though, many people will not consider it Spanish, and it there will be hate comments all over the place :) <maav>apteryx: perhaps we could tag it as a convention (disk-image needs it to be on /boot/efi) or as a new flag on the file-system declaration... <civodul>all Latin languages suffer from that but there are solutions, including repetition ("los y las desarollodoras"), "last personas", or use of -e or -@ <civodul>you don't have to choose one specific option, you can combine them <maav>last personas sounds great for a metal band ;) <luis-felipe>civodul: I've noticed that people, no matter the language, tend to econimize words, that repetiotion is not a solution, in my opinion. <civodul>luis-felipe: i'm not saying it's the solution, just that it can be used when everything else fails <civodul>anyway, i just wanted to show sympathy as a French speaker :-) <maav>actually, all of these problems are exposed in my footnote :-) <civodul>i think what maav did is great, and surely there are other solutions too, but as long as we agree on the goal, it should be fine <luis-felipe>Oh, sure, but then there's people who don't identify themselves as woman or men (masculine or feminine) <civodul>agreed, but the footnote above says feminine is for "personas" <civodul>too bad our languages are buggy and lack a smooth upgrade path :-) <maav>speaking lisp... oh, i forgot about car :-P <luis-felipe>civodul, maav: I've seen more uses of the nouns and pronouns terminated in -e though, while I've never seen the style used in Guix translation. <apteryx>maav: I'm going with the least effort (weak check identifying efi file systems based on the "/boot/efi" mount point) <maav>luis-felipe: i changed the translations for the app because it misgendered at account creation (i added the word account because there is no user but account creation, btw), if there is any place where that happens, it's a bug <apteryx>civodul: do you have a suggestion for a UI element that outputs a message at the "info" level ? <civodul>luis-felipe: it seems to me "@" is more frequent than "e" in Iberia, though i could be wrong <civodul>there's a procedure with that name in (guix diagnostics) <luis-felipe>maav: You mean the use of «usuaria» instead of «usuario» is a bug? <maav>luis-felipe: not at all, i mean that 'la usuaria Miguel' could be misgendering (not for me, btw, i don't like those categories and I wouldn't complain at all) but 'la usuaria' means a generic person. <jeko>When deploying, I got an exception with the message "(%exception #<inferior-object #<&message message: "'/gnu/store/nwxnw94hj8hz42gs20z1664vmddi69nc-grub-2.04/sbin/grub-install --no-floppy --target=i386-pc --boot-directory //boot /dev/vda' exited with status 1; output follows:\n\n Installation pour la plate-forme i386-pc.\n /gnu/store/nwxnw94hj8hz42gs20z1664vmddi69nc-grub-2.04/sbin/grub-install\xa0: erreur\xa0: impossible d'obtenir le chem <luis-felipe>civodul: the use of @ is common here too; I wouldn't use it though. <jeko>in canonique de «\xa0none\xa0».\n">>)" <jeko>My target is a x64_86 and it is specified in the machine declaration but grub has --target=i386-pc <civodul>jeko: could you share your bootloader config? it might be lacking something <jeko> (bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/vda"))) <luis-felipe>maav: Oh, ok. Yeah, it makes sense that it is not considered a bug in the convention used in the Spanish translation. <civodul>jeko: hmm, looks correct; could you share the whole command and output? <jeko>"grub-bootloader allows you to boot in particular Intel-based machines in “legacy” BIOS mode" is it the explanation haha ? <civodul>it's weird that you get an raw inferior object in there <jeko>"guix deploy ynm-machine-declaration.scm" <jeko>should I share my files ? <jeko>dunno how to do that with irc ooops <civodul>hmm yes you can share, via a "paste" site as note in the subject of the channel <maav>civodul, luis-felipe: both @ and e, and x too, are common here; just not on mainstream media and pro-state feminism, as they usually duplicate the terms <luis-felipe>maav: -a and -o don't seem neutral to me, that's all. <civodul>roptat: translation "import du module .. à partir de l'hôte" lacks a trailing ~% <civodul>jeko: it all looks good to me, i don't get where that "none" comes from :-/ <civodul>perhaps you can email that to bug-guix *vits-test "вы только русский не трогайте, реформаторы хреновi" <jeko>civodul: Thank you very much for the review ! I'll write to bug-guix ! <civodul>yay, "make assert-binaries-available" passes on version-1.2.0! at last! \o/ <zimoun>civodul, mothacehe: “guix weather --display-missing |grep -e '\-r-' |wc -l“ returns 941 over 15327 packages in version-1.2.0, i.e., too much for a release. Is it possible to trigger a requeue of these packages? <civodul>apteryx: any thoughts on update-guix-package? it's one of the last release blockers i think <zimoun>civodul: another release blocker is the number of packages blocked in the CI. <civodul>zimoun: hi! we can try (maybe manual build rather than "requeue"...) <zimoun>not critical… well, if as a user I do ‘guix install r-foo’ and I am compiling a lot, I will not be happy. <zimoun>it is 7% of the missing packages. <apteryx>civodul: My preference would be for keeping the safeguard and convenience of using a git worktree for the checkout, but adding the sources to the store when the GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT environment variable is defined. <apteryx>the sources would be added to the store from the clean git worktree checkout, of course <zimoun>civodul: maybe more critical: autoconf-2.68 or glibc-2.27, u-boot-*, gcc-toolchain-4.8.5, a lot of rust-*, gparted-1.1.0, qemu-2.10, couple of emacs-* (and emacs-next-28.0.50), old gcc-4.{7,8}, mesa-*-20, couple of ghc-*, couple of java-*, linux-libre-5.4.74, couple of cl-* or sbcl-*, clang-toolchain-{10,11}.0.0, gmsh-4.6.0, couple of maven-*, skopeo-1.2.0. How is it possible to do manual build? <civodul>apteryx: ok but then that would need to be implemented and tested <raingloom>folx, anyone knows how to set Guix up on a DigitalOcean droplet with minimal hassle? the one guide i found seems rather outdated. <civodul>apteryx: you'd rather not go with the version i posted last week? <civodul>i think it's less i/o-intensive, too <ryanprior>new in emacs-guix-packaging: M-x guix-packaging-insert-input prompts you for a package string with completion and inserts it formatted as an input <ryanprior>eg if you specify ruby@2.7.2 it'll insert ("ruby@2.7.2" ,ruby-2.7) <civodul>ryanprior: "emacs-guix-packaging"? didn't know that one! <ryanprior>It reads the guile source code and looks for a define-package form, so it might not work for all packages if they have unusual source code. <ryanprior>I would be interested in building a scripting interface to guix to take the guesswork out of such things <apteryx>civodul: It'll be one git worktree extra, which isn't much. I think the convenience/safeguard of enforcing pristine sources from the worktree is worth that extra IO cost. <apteryx>+ the diagnostic of attempting to push non-upstream commit instant, which I find great. <ryanprior>another neat thing: I worked with repology to add guix support to their find-project-by-repo-package-name tool <ryanprior>so you can link to a project in repology by its name in guix; you don't have to search to find out what repology's name is for that project, and if the repology name changes it won't break the link <civodul>apteryx: sure, i think keeping GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT non-default is the right approach; i'm not arguing about that <civodul>apteryx: we need (1) to restore the ability to use a private commit though, and (2) i'm rather in favor of not shelling out if it's not strictly needed <civodul>but of these, #1 is the top priority <civodul>ryanprior: nice! you should drop a note on the list <civodul>zimoun: "guix weather -c 10" says we have 81% coverage on 'version-1.2.0', and like you wrote, a long tail of missing packages with few dependents <ryanprior>how do I join the list? I've been meaning to figure that out <ryanprior>oh dang somehow I've gone through this before and didn't figure it out, this time it was obvious <civodul>java-snappy (112 dependents) fails to build <zimoun>civodul: yep, and 81% + 7% of r- (which mostly build from my small experiments) mean 88% which is better :-) I am almost sure that the CI missed some because IO or Cuirass <civodul>./pre-inst-env guix weather $(./pre-inst-env guix package -A ^r-| cut -f1) -> 37% <zimoun>I am trying to see if they are on bayfront or nckx machine… but it is really slow; compared to berlin. I do not know why. <zimoun>maybe mothacehe can tell more, but I think some r packages are ‘blocked’ by the Cuirass <zimoun>however, only 57.6% of the 16,638 are served by bayfront <db48x>after messing with selinux all day, I forgot that I still haven't fixed this search-patches problem <zimoun>civodul: guix weather --substitute-urls=https://guix.cbaines.net $(guix package -A ^r- |cut -f1) -> 99.4% substitutes available (1,479 out of 1,488). And I do not know if guix.tobias.gr follows the branch version-1.2.0. nckx? <civodul>zimoun: i think cbaines has just demonstrated the superiority of the Guix Build Coordinator ;-) <apteryx>civodul: I'm testing a hybrid update-guix-package version. Will send the patch when it passes the tests. <civodul>fun fact: "guix time-machine --branch=version-1.2.0 -- build --no-grafts $r_packages --max-jobs=100 --keep-going" eventually fails with "creating pipe: Too many open files" <civodul>so it looks like the daemon is being silly <zimoun>mothacehe, civodul: I do not remember, is it possible to distinguish from ci.guix.gnu.org which packages failed and which packages simply did not try to build? <leoprikler>Regarding "too many open files", I don't think we clean up our ports all that nicely (in Guile/Guix). <vagrantc>so, no more typo fixes on descriptions in 1.2.0 ? <vagrantc>(e.g. string freeze for translations ... ?) <mothacehe>zimoun: you can use the search at ci.guix.gnu.org to find a build is scheduled, started, done or failed. <vagrantc>any idea how this issue is coming up? I: guix: file-references-package-build-path usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnu/ci.go <vagrantc>none of the other .go files in guix include the build path <zimoun>mothacehe: with the web interface, right? *zimoun says "see you then" <nckx>zimoun: guix.tobias.gr is very ill and probably won't be ready in time for 1.2, along with dmitri.tobias.gr ☹ <nckx>It might might might be. <nckx>That doesn't make it SHA-1 😛 The default output is ‘nix-base32’ sha256, a special NIH hash inherited from Nix. <nckx>It's the ‘sha256’ used in Guix packages. You can try others with --format. <nckx>divoplade: Basically, ‘base32 with less chance of naughty words’ (really). <nckx>I don't know if there's a rationale for the truncation. <nckx>divoplade: With a different base32 character set. <nckx>I never actually bothered to check the # of bits. <nckx>C-u 52 is all you need ♪ <apteryx>mothacehe: no worries; I have a patch to sanitize (as in: strip) the operating system conflicting file systems when generating disk images. I'll send it shortly. <apteryx>it's a simple hack, but it allows the operating system definitions under gnu/examples/ to boot <mothacehe>I think the patch fixing disk-image for lightweight-desktop could go to 1.2.0 <apteryx>Great! About the bootloader installers/disk-image-installers; I think it'd be ideal if they were used mutually exclusively. <apteryx>It seems only the grub bootloader-install currently does something useful when its 2nd argument (device) is #f. <apteryx>if we could rework that one to no longer have that requirement, then we wouldn't need to call bootloader-installer at all as part of a disk image generation. <apteryx>why does grub need to install stuff under /boot/grub as part of the grub installation? Is it because the MBR is too tiny to hold it all? <mothacehe>yes dedicating bootloader-installer to install/reconfigure and bootloader-disk-image installer to image production would be great <apteryx>about my last question; I mean it in the context of disk image generation <mothacehe>yes that's right, the Grub installed in the MBR gap (space between the end of the MBR and the first partition) only contains 4 modules (biosdisk, part_msdos, fat and ext2). It then loads all the modules from /boot/grub. <mothacehe>we could have this module copying moved to (gnu system image) <apteryx>civodul: update-guix-package is working well. Testing 'make release' <apteryx>mothacehe: Could we create the grub_bios partition (was this how it's called?) and have it installed there instead? Since we are in control of the partitions layout. <raingloom>fun fact: a failed `guix system init /etc/config.scm /` inside Ubuntu can nuke your host guix install :D <apteryx>I think 'guix system init' can nuke any guix install (it clears the database under /var/guix to start with). <raingloom>this would be irritating if it had any data on it, but i'm having fun :D <nckx>The destruction is pretty atomic IIRC. <raingloom>the error is this btw, if anyone cares: 123whatever/sbin/grub-install: error: /gnu/store/1234-grub-efi-2.04/lib/grub/i386-pc/modinfo.sh doesn't exist <raingloom>the problem is, the guix command is now broken, but the store is still there, so the install script refuses to run. <mothacehe>apteryx: for now the image is created with a dos partition. Using bios_grub requires GPT partitioning unless I'm wrong. <apteryx>Do you know if the the tools used support GPT? <mothacehe>apteryx: yes it could be as simple as passing gpt = true in the genimage config file *apteryx trying to 'make release' on the v1.2.0rc1 branch -> <apteryx>No rule to make target 'po/doc/guix-manual.pot', needed by 'distdir-am'. Is the fix 'make download-po' ? <vagrantc>i don't know what it isn't invoked, it looks like a dependency of various targets that should be called <vagrantc>calling it manually works for me to run make dist, though <apteryx>vagrantc: thanks! it now seems stuck at using a pretty old version and fails on: mv: cannot stat 'guix-1.0.1.24273-24918-dirty.tar.gz': No such file or directory <apteryx>seems like VERSION in Makefile.am might be wrong. <vagrantc>apteryx: basically, it pulls it from the most recent tag, which for some reason git describe thinks is 1.0.1 instead of 1.1.0 <vagrantc>it should fix itself once you do a signed tag of v1.2rc0 or something <vagrantc>although then i don't know if you merge that tag into master what version git describe will pick for the future <vagrantc>i've forced it to use 1.1.0 as a reference point by deleting all the other tags ... and then it gives a curiously larger "number of commits since" <apteryx>civodul: patch sent! I haven't adapted Makefile.am yet, because as you can see, I'm not out of the forest yet :-) <vagrantc>apteryx: but to regenerate it, i think you need to re-run ./bootstrap <vagrantc>might also need to "git clean -dfx" and start from scratch. <apteryx>I tried ./bootstrap ealier, it didn't help <vagrantc>there's .version and possibly .tarball-version <vagrantc>i had the best luck ... deleting tags i didn't want it to refer to, running from an absolutely clean checkout, and manually calling make doc-pot-update <apteryx>.version is at 1.0.1.10741-6162b5. I don't yet have .tarball-version. <vagrantc>well .... /o\ has been my experience with make dist :) <vagrantc>nice to have someone else fighting with it; hopefully we can actually get these issues fixed :) <vagrantc>i mostly have been doing them in a mad dash to build packages for debian ... which now looks done ... so looking forward to the first 1.2rc signed tarball. <vagrantc>although even better would be able to build just from a tarball produced by git archive ... :) <apteryx>seems dist-with-updated-version should be called always <apteryx>which is supposed to take care of VERSION <vagrantc>for completeness .... git clean -dfx && ./bootstrap && ./configure --localstatedir=var && make doc-pot-update && make dist <apteryx>the good news is that it does run the dist-with-updated-version <apteryx>so now to figure out why it doesn't work <abcdw>mroh: The problem was with use-package. Building with newer emacs doesn't help, but updating use-package to more recent solved the problem. <divoplade>Hi! Is it possible to configure an installation os with extra channels? <roptat>mh? weird issue with nginx: it says server-names-hash-bucket-size is too low (64), but I specified it in the configuration, and it's been working for months like that <apteryx>vagrantc: Ah, another clue: in configure.ac, VERSION gets set in the AC_INIT via: [m4_esyscmd([build-aux/git-version-gen .tarball-version])], <roptat>but indeed, the generated configuration doesn't contain the word "bucket" in it at all (though it has all my server blocks) <apteryx>so now I know how that script gets called, I can try to debug it. <vagrantc>divoplade: the channels are defined by "guix pull" ... not in the instantiated os <vagrantc>divoplade: or do you mean in the installer? <divoplade>vagrantc, I'd like to edit the generated configuration file, but I need other modules than what guix provides <divoplade>Otherwise the system won't boot so I don't get a chance to run guix pull <vagrantc>you can run guix pull from the installer, i would presume, and configure your channels there... <apteryx>so yeah, that's the problem, './bootstrap' doesn't regenerate totally the configure script, at least it leaves the {PACKAGE_}VERSION variables untouched it seems. <apteryx>vagrantc: apparently that's expected; it seems the tags were not annotated <apteryx>if you try: 'git describe --abbrev=4 --match="v*" HEAD' you'll get the same thing as the git-version-gen script outputs. <apteryx>which should be v1.0.1-24138-gc84e6 unless you've created annotated tags yourself. <apteryx>civodul: I'm wondering why tags such as 'v1.1.0' are not annotated; is this expected? <civodul>apteryx: "annotated", what do you mean? <apteryx>git describe anly picks up annotated tags by default, those produced with a commit message and the -a switch <apteryx>they are meant as more 'official' or public tags compared to just tagging with 'git tag' (without -a), which are usually for private uses. <apteryx>civodul: after creating a v1.2.0rcTEST annotated tag locally, it proceeds until: ./doc/guix.de.texi:1641: @xref reference to nonexistent node `Die Substitut-Server anfechten.' <civodul>apteryx: ok, i'll give it a spin in a moment *civodul is finishing a draft blog post for the release <apteryx>well the procedure described in release.org should work: git tag -s -m "GNU Guix 1.2rcTEST_SIGNED." v1.2rcTEST_SIGNED (-s implies -a IIUC). <lfam>In 10 years, Ubuntu will be "a Guix-type distro" ;) <maav>apteryx: v1.1.0 is already a signed tag (git cat-file -t v1.1.0 shows tag, not commit as with lightweight tags) <apteryx>maav: does 'git describe' picks it up for you? <apteryx>rather, git describe --abbrev=4 --match="v*" <maav>apteryx: the problem is not that it isn't signed, but the shortest path to a tag <maav>git describe --match="v1.1*" shows 67k+ to v1.1, but only 24k+ to v1.0.1 <civodul>apteryx: woow, i must look ridiculous now, i had never heard of "annotated" tags (although all tags are "annotated" in English language terms?) <maav>so for git v1.0.1 is a better match <civodul>but git-tag(1) says: Tag objects (created with -a, -s, or -u) are called "annotated" tags; <civodul>and all the tags were created with -s, so i guess they're "annotated"? <apteryx>v1.0.1 is actually closer to the current HEAD than v1.1.0 <maav>civodul: yes, they are, git cat-file -t <thing> shows tag for annotated tags, and commit for lightweight ones, as they are more like "fixed-branches" <apteryx>I'm happy I finally understand why v1.0.1 kept coming up in 'make release'; and I have confidence that calling ./bootstrap successfully generates a new VERSION in configure based on what's in git. <gpk>How do I configure a service like dhcp-client? Should I make a file in /etc or am I supposed to do it in config.scm? <maav>apteryx: you're welcome, happy to help:-) <apteryx>and that I wasn't able to reproduce, even with the reproducer you shared here a couple days ago :-/ <apteryx>civodul: still stuck with that problem? <maav>civodul: yes... it's very weird, as the problematic variable is file-local-variables-alist (or something like that), not the dir-locals :( <civodul>apteryx: still; i didn't want to spend too much time on it, there's a release cooking :-) <maav>civodul: i didn't moved it to scheme-mode as i couldn't reproduce it without it after trying, but perhaps it's worth to do that change... :( <apteryx>maav: file-local-variables-alist is nil here. Could it be some Elisp packages interfering? <maav>not in the file but debugging the procedure when it crashes you can check that it's filled with those vars... <maav>that's the weird problem :( <civodul>to whom it may concern: i've pushed a draft announcement to guix-artwork.git, feedback welcome! <civodul>now we just need to fix all the rest... <apteryx>So, apparently I got unlucky with my last 'make doc-pot-update', I've done it again and it no longers fail on some .de translation file. <apteryx>Which means, I can finally see where update-guix-package fails in Makefile.am and fix it. <apteryx>civodul: perhaps 'make doc-pot-update' should be ran in the bootstrap script? <maav>it cannot run there because you need configure before that <apteryx>Ah. Some chicken and egg problem. Can we run it later? As part of make release? <maav>shouldn't be better to hook it to make dist? <roptat>wait, why does server-names-hash-bucket-size do nothing anymore? <roptat>since the deletion of this part is not mentionned in the commit message, I suppose it was not intentional. Is it ok to re-introduce that? my server's broken without it <nckx>roptat: Please do, it's not deprecated. <cbaines>It's a regression, so ideally this could be fixed on the 1.2 branch as well <civodul>maav: if doc-pot-update is a dependency of dist, won't that lead to modifications to pot files ("dirty tree")? <civodul>roptat: this would be a question for wigust <civodul>but yeah, it does look like an unintended change <civodul>apteryx: please don't change release.org just yet, i'm a bit wary of changes at this stage (but interested in improvements!) <maav>civodul: yes in a non-release state, that's why make dist should be called after downloading the latest po files, because they have been merged by tp with the latest pot, so there shouldn't be any difference <roptat>to master, should I push to version-1.2.0 too? <apteryx>git cherry-pick master (or your commit) <roptat>do I need to sign, or does cherry-pick keep the signature from master? <maav>cherry-pick signs again because it creates a new commit <maav>(if you sign by default, if not you have to add the -o option to git before cherry-pick command) <maav>also, i always do git push remote branch, it was very different on git 1 <maav>and you can configure it to push everything, not only your branch <maav>(that was the old default) <roptat>bah my network is being weird again: ssh: Could not resolve hostname git.savannah.gnu.org: Name or service not known <maav>(git push origin version-1.2.0 in this case, not the actual words that are also git commands) <roptat>though dig can resolve it just fine <nckx>roptat: herd invalidate nscd? <nckx>(Which is a horrible & obscure work-around...) <lfam>I've found myself wishing that `herd doc nscd list-actions` was more prominently advertised <lfam>Or, more commonly supported <jonsger>lfam: what can I do with those actions `shepherd --help` and `herd --help` are a pretty silent about all it's features and command line options <civodul>lfam: TBH, i never remember how to view that doc, it's terrible <lfam>jonsger: If I understand correctly, `herd doc foo` is always supported, but usually there is not much information. list-actions is more mysterious... <lfam>I used to know more about it but I've forgotten <civodul>apteryx: FWIW i don't experience problems with the German manual on 'version-1.2.0' <apteryx>civodul: OK I adapted Makefile.am and made a couple fixes to update-guix-package.scm, I'll push a last (hopefully) version. <civodul>luis-felipe: looks nice, fine with me! <vagrantc>apteryx: so you've rediscovered why i delete all the older tags :) 
