IRC channel logs


back to list of logs

<Fare>yikes, after building rust 1.54 and 1.55, it now builds 1.58.1...
<unmatched-paren>Fare: yup, rust has an annoyingly long bootstrap chain
<rekado>you can also use “include”
<unmatched-paren>each release can only be built with the one directly before...
<Fare>omg, it's going to go all the way to rust 1.65, with 24h builds in between???
<nckx>Fare: This is why not having substitutes for aarch64 is considered a release blocker. At least I hope it will be fixed by then.
<zimoun>how search-patches works with --load-path?
<cbaines>nckx, we do have substitutes for aarch64
<civodul>zimoun: it traverses %load-path
<civodul>nckx: i opened to keep track of the LibreOffice/i686 issue
<abhicherath[m]>So my rust build just competed (ran guix build -e '(@@ (gnu packages rust) rust-1.65)'
<abhicherath[m]>How do I get it into my profile?
<nckx>‘guix install /gnu/store/…rust-1.65’
<zimoun>civodul: thanks. (aside, I did not found it in the documentation ;-))
<abhicherath[m]>Hmmm how do I get cargo too?
<abhicherath[m]>the rust package has cargo as another output right?
<nckx>Yes, didn't guix build print it
<unmatched-paren>abhicherath[m]: it'll be in the cargo output, yes
<abhicherath[m]>Ahhh yes yes
<abhicherath[m]>I was derping cause I didn't realize the hash would be different so was hitting tab complete wondering why nothing showed uo
<abhicherath[m]>Also, this way of invoking guix package -i isn't in the docs, should it be?
<unmatched-paren>pretty sure most commands that accept packages also accept store paths
<unmatched-paren>guix build accepts .drvs iirc
<jonsger>ACTION likes the "herd configuration" command already
<jonsger>ACTION although it would be nice to have some kind of outcomplete to find out which commands herd does have...
<civodul>jonsger: glad you like it! it received... little feedback so far
<civodul>re completion, we should definitely add Bash completion for "herd"
<abhicherath[m]>so this sentence Each package may specify either a simple package name, such as guile, or a package name followed by an at-sign and version number, such as guile@1.8.8 or simply guile@1.8 (in the latter case, the newest version prefixed by 1.8 is selected).
<nckx>abhicherath[m]: Yeah… ‘Each PACKAGE may specify either a’ implies an exhaustive list, which is misleading.
<abhicherath[m]>should be Each package may specify either a simple package name, such as guile; a package name followed by an at-sign and version number, such as guile@1.8.8 or simply guile@1.8 (in the latter case, the newest version prefixed by 1.8 is selected); or a store path, such as ...
<abhicherath[m]>and the manual is in the checkout right? I can try submit a patch
<unmatched-paren>abhicherath[m]: yup
<unmatched-paren>abhicherath[m]: modify doc/guix.texi, run ``guix shell -D guix'', inside there do ``./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)''
<unmatched-paren>then do ``info doc/'' or ``pinfo doc/''
<unmatched-paren>then you'll want to write a commit message looking something like:
<unmatched-paren>i can't find that line
<unmatched-paren>oh, i found it
<abhicherath[m]>same time here ah grepping these is kinda annoying
<unmatched-paren>abhicherath[m]: search for ``@node Invoking guix package''
<abhicherath[m]>yep i found it 👍
<abhicherath[m]>changing it rn
<unmatched-paren>okay, remember to use that commit message format :)
<abhicherath[m]>and then commit with that as commit message?
<unmatched-paren>and send it to the ml following this guide:
<abhicherath[m]>how can i get git send-email to give me something i can copy and paste into thunderbird hehe
<abhicherath[m]>ah format-patch
<abhicherath[m]>got it
<unmatched-paren>abhicherath[m]: you don't
<unmatched-paren>please don't :)
<unmatched-paren>git send-email does email-sending itself
<unmatched-paren>please please please don't use attachments
<unmatched-paren>it makes reviewing really annoying
<abhicherath[m]>ok but now I've to set up smtp aaa, alright will do after lunch
<unmatched-paren>sorry :)
<unmatched-paren>abhicherath[m]: <- here's my gitconfig for reference
<abhicherath[m]>maa no worries it's something ive been meaning toget around to anyway
<unmatched-paren>see [sendemail] specifically
<abhicherath[m]>alright brb lonchtime
<PotentialUser-63>I am trying to build my first package. It fails with message "command cc not found". Typically cc is linked to gcc in Linux systems. Or I think exported by the env var CC=gcc. How can I change the build system (gnu-build-system) to set this env var?
<lechner>abhicherath[m] / Hi, for mail i found opensmtpd the easiest, but it currently works only on port 25. i have not spend enough time to get the sendmail binary to work
<lechner>abhicherath[m] / you probably also have to grant elevated privileges to a few executables
<unmatched-paren>PotentialUser-63: You need to add this:
<unmatched-paren>(arguments (list #:configure-flags #~(list (string-append "CC=" #$(cc-for-target))))
<nckx>lechner: <currently works only on port 25> Wait wat?
<nckx>How so?
<unmatched-paren>PotentialUser-63: this basically adds ``CC=gcc'' to the ./configure args
<unmatched-paren>PotentialUser-63: remember to use #$(cc-for-target), as it will expand to eg ``gcc-aarch64-linux-gnu'' when cross-compiling; if you just do ``CC=gcc'', cross-compilation will fail as it'll use a native compiler
<nckx>If that doesn't work (it's the better option but some packages are… special), you can try adding it to #:make-flags instead.
<lechner>nckx / abhicherath[m] / never mind, 'sendmail' works. thanks nckx for the interjection!
<nckx>I did nothing but the scoobydoo ruh? but you're welcome.
<lechner>one more thing off my plate
<PotentialUser-63>unmatched-paren : which module provides cc-for-target please?
<unmatched-paren>PotentialUser-63: (guix utils)
<nckx>lechner: opensmtpd is such a wonderful MTA, it saddens me that it's no longer actively maintained. Luckily, the basics are covered and it's not abandoned.
<lechner>Here is to Guix getting off the ground! This bird has the largest wingspan in the world, with up to 3.5 meters.
<lechner>nckx / i thought opensmtpd was merely in maintenance mode because they founders now used proprietary enhancements at work, and it was all about speed for them. they seemed responsive in #opensmtpd, although with a small community.
<lechner>nckx / you are right about it being lovely. after postfix and exim, i don't miss either
<lechner>i feel the same way about #gssapi
<lechner>or #zeromq
<unmatched-paren>what should i call a variant of an emacs package that uses the latest commit instead of tag?
<unmatched-paren>rather, what should i call the variable
<unmatched-paren>emacs-foo-next, maybe?
<lechner>maybe -recent, since it may not be the -latest after some time
<unmatched-paren>i think -next might be best, because that's what the actual emacs package's devel version uses
<lechner>how about -unreleased
<lechner>maybe -next is best
<lechner>or -new ?
<unmatched-paren>i'll use -next :)
<abhicherath[m]>OK i think I sent the patch
<unmatched-paren>abhicherath[m]: your first ml post may take a while to appear
<unmatched-paren>as it needs to be manually reviewed
<unmatched-paren>to stop spam addresses
<abhicherath[m]>does that look ok?
<abhicherath[m]>ah i've submitted a couple of bug reports
<unmatched-paren>actually, i think it migt be better to use a literal ellipsis in the store path example
<abhicherath[m]>mm yea that makes sense
<unmatched-paren>i *think* the ... will be expanded by texinfo to an actual ellipsis unicode character
<unmatched-paren>not certain though
<abhicherath[m]>ok so if I do a commit --amend here
<abhicherath[m]>and then email again
<unmatched-paren>abhicherath[m]: make sure to use the address
<unmatched-paren>and the -v flag
<unmatched-paren>e.g. -v2
<unmatched-paren>also, there's too much indentation before the ``[...]'' and ``on store paths'' in the commit message
<nckx><as it needs to be manually reviewed> Done, btw.
<unmatched-paren>ah, you used a tab
<abhicherath[m]>ah yepyep got it I was looking through
<unmatched-paren>you'll want to use two spaces before those
<unmatched-paren>abhicherath[m]: is a bit incomplete imo
<abhicherath[m]>I have like 3 computers open in front of me with weird logins so i couldn't copy paste my bad
<unmatched-paren>e.g. it doesn't mention the -NUMBER flag
<abhicherath[m]>thought it was a tab, should be two spaces?
<unmatched-paren>to send NUMBER commits
<unmatched-paren>yup, two spaces
<abhicherath[m]>will fix
<nckx>0 spaces.
<unmatched-paren>nckx: oh, right, okay.
<unmatched-paren>my mistake :)
<unmatched-paren>abhicherath[m]: e.g. you can do -1 which has the same effect as HEAD^
<unmatched-paren>sends the last one commit
<unmatched-paren>this details the git send-email procedure we usually use
<unmatched-paren>for single patches and multiple patches
<unmatched-paren>c baines has agreed to vouch for me for commit access \o/
<unmatched-paren>only one person needed now...
<unmatched-paren>(the other is raghav gururajan)
<florhizome[m]>Maybe nckx ?
<unmatched-paren>well, nckx is a maintainer, and there seems to be a consensus that non-maintainer committers should be the ones vouching
<florhizome[m]>oh :(
<unmatched-paren>though it's not *forbidden*, just better to have vouches from non-maintainers as the maintainers will be the ones receiving the "pls commit access" email
<nckx>Well, it was less of a consensus than I thought. I'm also not hard-against it. Yes, exactly, what you just wrote.
<nckx>My thought would be: we've grown so large; you really couldn't find a third non-maintainer? But that can happen, and it can be discussed.
<abhicherath[m]>oops i sent it without -v 2
<unmatched-paren>abhicherath[m]: that's okay
<unmatched-paren>abhicherath[m]: btw it's arrived in my inbox now
<nckx>Aside: I don't think -v 2 works, I think it has to be -v2.
<nckx>Weird undocumented option is weird.
<florhizome[m]>Well i would recommend you, as i already have some contributions rotting on the mailing list ;p
<unmatched-paren>as i recently found out...
<abhicherath[m]>think the docs need some fix here then
<unmatched-paren>florhizome[m]: i'll definitely have a look at those if/when i get commit access :)
<mirai>nckx: I presume it's in git format-patch
<florhizome[m]>Yup it's -v2
<unmatched-paren>abhicherath[m]: yeah, when i wrote that i didn't realise -v REVISION didn't work
<mirai>and it looks like a bug
<mirai>git send-email munching '-v'
<nckx>You're right: -v <n>
<florhizome[m]>It kinda resembles using -2 to select the Last two commits but yeah it's inconsistent
<nckx>mirai: So it gets munched as ‘verbose’ or whatever?
<florhizome[m]>maybe podiki or jpoiret would like to vouch for unmatched-paren
<mirai>it's a bug because if you reorder the '-v' arg in send-email, the last error messages will show the arg value being moved around
<lechner>unmatched-paren / Hi, you do not have ssh in your config, right?
<abhicherath[m]>thanks so much for the handholding btw unmatched-paren
<nckx>That is a bizarre bug to have in a project like git.
<mirai>nckx: idk, send-email doesn't have a --verbose switch afaik
<florhizome[m]>Does podiki have commit Access?
<abhicherath[m]>anything else that I've to do for this patch?
<nckx>florhizome[m]: Uh, yes, nominally.
<florhizome[m]>I am already confused by mbsyncs -v and -V
<florhizome[m]>one is for verbose one vor version but don't ask me
<unmatched-paren>lechner: nope, i don't use ssh
<nckx>florhizome[m]: I'm not denying your confusion, but at least -V for --version and -v for --verbose is at least a very common convention. At least.
<lechner>florhizome[m] / that's messed up
<lechner>nckx / mbsync is the other way around
<nckx>Don't test many other tools then, you won't like what you find.
<nckx>lechner: Ooh.
<lechner>it's time for the picture, i think
<nckx>ACTION never invokes it interactively.
<nckx>ACTION confuserd.
<florhizome[m]>unmatched-paren i just read wlroots got a new Release so wayfire will also get one and other wayland compositors so it would be a good time to commit some stuff i have lying around :)
<unmatched-paren>florhizome[m]: it'll be a while before we'll have those new releases in guix, sadly
<nckx>unmatched-paren: Anyway, I am actually very happy to vouch for you, just add me to the bottom of your list :)
<podiki[m]>florhizome: I do not (have commit access) but in the process as well :)
<florhizome[m]>* florhizome still hasn't automated that
<unmatched-paren>abhicherath[m]: btw you can use for a nicer debbugs interface
<florhizome[m]>unmatched-paren you mean because we lack the dependencies? I would try the method
<unmatched-paren>florhizome[m]: i'm not entirely sure that'd be accepted in guix
<unmatched-paren>for core packages like libdrm
<florhizome[m]>I'm in the process of contributing citra (and yuzu) and i was told explicitly to make a sdl2-next to stay on the latest versions butbmaybe that's not core enough?
<unmatched-paren>ACTION does guix refresh --list-dependents sdl2
<unmatched-paren>hmm, this looks like a "staging"-worthy package, not quite core-updates, but i'm not familiar with the upper limits for dependent rebuilds
<florhizome[m]>That's actually Something guix needs to do better, keeping those deep dependencies up to date.
<unmatched-paren>maybe libdrm-next would be okay, idk :)
<podiki[m]>yeah it is around that at ~800
<podiki[m]>for sdl2; there is a patch for 2.26.0 submitted the otehr day, probably one of you here :)
<unmatched-paren>florhizome[m]: it's quite difficult to balance "number of grafts" and "outdated-ness"
<podiki[m]>I'd like to have more "feature" branches for these kinds of updates, since we have the infrastructure for
<florhizome[m]>In my book libdrm is outdated on guix especially since it's not even in c-u
<podiki[m]>I've been putting off bringing this up for a big discussion until 1.4.0 is set
<podiki[m]>libdrm should be updated on core-updates I thought
<podiki[m]>with wayland-protocols and mesa
<unmatched-paren>florhizome[m]: there are patches for the latest wlroots/wayland/libdrm/etc on the mailing list
<unmatched-paren>i'm not sure they've been merged onto core-updates yet though
<podiki[m]>there was at least libdrm 2.4.112 when I checked some time ago
<podiki[m]>ah, 2.4.114 was updated by Maxim on core updates just a few days ago
<florhizome[m]>podiki yes.
<florhizome[m]>Maybe it would also make sense to soften the criteria for minor releases
<florhizome[m]>Like i really doubt libdrm has a disruptive Policy for their 0.0.x releases
<florhizome[m]>It's always Like that lol, when i say such things
<podiki[m]>yeah, my pet project is keeping mesa up to date, where I don't think there are usually breaking changes (well recently they dropped older drivers) but a massive amount of rebuilds
<florhizome[m]>Is that the newest version though?
<podiki[m]>according to guix refresh, but that's not foolproof
<podiki[m]>let's find the source...
<florhizome[m]>Maybe i'm confusion it with sdl
<podiki[m]>yes, the latest tag I see on
<unmatched-paren>abhicherath[m]: it is done :) <>
<florhizome[m]>Funny how keeping Linux uptodate is easier then These packages
<podiki[m]>I think we can reevaluate, after all browsers take a looong time to compile but of course critical to keep up to date
<puppysad>1. Guix OS lacks gpg installed by default! How does it even validate downloads then? I had to install gpg using "guix install"
<puppysad>2. I'm still new to guix so still learning, it is super annoying how it boots up into gui. how can I make it not boot into gui so that I can choose to start gui as needed?
<lechner>nckx / i thought you posted a blown-up version of the weird guy in thruth.png from time to time, but it was probably in my imagination, and is not in the logs
<podiki[m]>I wouldn't be surprised if some of the "staging" level changes are quicker than rebuilding chromium :-P
<florhizome[m]>well that's good
<abhicherath[m]>this is an actual git bug huh? I wonder how hard it'd be to actually fix it
<podiki[m]>unmatched-paren: is there an upstream bug for that? or known quirk?
<podiki[m]>puppysad: to your first question, something being installed means visible for the user to use, but internally more can be used (e.g. building a package will compute the hash of the source within the build container)
<nckx>lechner: Ah! Glad it was memorable. Not that often, though }:-)
<florhizome[m]>puppysad : i think you could maybe disable the respective Services or you reconfigure without them
<puppysad>the config.scm file under /etc/?
<florhizome[m]>It doesn't need to be there but yeah i guess
<florhizome[m]>There is also one under /run/current-system
<florhizome[m]>Not sure where exactly though
<podiki[m]>check out "guix system list-generations" to see store links to all system info for a generation
<podiki[m]>including channels, configuration, and all that
<podiki[m]>"canonical file name" is the directory with that, or "configuration file" tells you directly
<podiki[m]>of course you can't edit those directly, but to copy it somewhere you want or see previous configurations you used
<florhizome[m]>puppysad if you want a more minimal config you should not expand on %desktop-services but rather %base-services
<florhizome[m]>In the Services field
<florhizome[m]>But then you can't start the Desktop Services
<florhizome[m]>So i would try to disable some
<florhizome[m]>via shepherd
<lechner>Hi, what's a reason why I might not be able to start sshd manually in a root shell, please?
<lechner>it just exits without a message
<abhicherath[m]>I asked about the git-send-email thing in git-devel
<abhicherath[m]>what's the easiest way to see if there's substitutes for a given package for a given system?
<abhicherath[m]>I want to check if php has substitutes for aarch64
<nckx>guix weather --system=aarch64-linux …
<abhicherath[m]>o wait just give the package nvm
<nckx>And of course I just sent mail asking whether the git -v bug was reported.
<abhicherath[m]>wait that's weird, cause I tried building it on raspberry pi a couple days back
<nckx>abhicherath[m]: Could you cross-link that thread back to ?
<abhicherath[m]>cross link what thread? irc?
<nckx>Oh, I thought git-devel was a mailing list.
<abhicherath[m]>nono on irc
<abhicherath[m]>noones responded yet tho
<abhicherath[m]>abhicherath[m]: the build errored out with a failed test
<nckx>ACTION tried ‘/join’ just for fun and it… ‘works’. In the wrong sense.
<nckx>I didn't know @ was legal.
<abhicherath[m]>nckx: wdym?
<nckx>So of course now I created #~gexp and #$ungexp.
<nckx>abhicherath[m]: It joins (well, creates) a channel literally named ‘’ on the Libera network.
<abhicherath[m]>hmmm ill go try to install php on rpi again but I recall that it wasn't building with a failed openssl test
<lechner>Hi, does the Shepherd have an internal ssh-daemon, please? tcp6 0 0 [::]:ssh [::]:* LISTEN 1/guile
<vagrantc>yay. got a kernel building for the mnt/reform ... less that 10 patches on linux-libre 6.0.9
<vagrantc>admittedly two of the patches are *huge* ... but one of them can probably be eliminated entirely and one could probably be made smaller
<vagrantc>cwebber: interested ^ ? :)
<vagrantc>i think one of the huge patches actually needs to be purged for FSDG reasons ... will see if i can just get awy with dropping it.
<jackhill>vagrantc: oooh, cool!
<nckx>lechner: No, but it implements ‘on-behalf-of’ socket listening vaguely like systemd.
<nckx>So it does seem like you have sshd already?
<nckx>ACTION away.
<jackhill>vagrantc: I'd be interested in a Guix image for Reform.
<lechner>nckx / i borrowed someone's config but it had no sshd. now i can't run 'guix-deploy' to add it
<lechner>i did 'herd stop ssh-daemon' and guix shell openssh to run the daemon manually. now i can connect manually but not via guix deploy, even after restarting guix-daemon
<lechner>the error is guix deploy: error: failed to deploy lechner-desktop: SSH connection to '' failed: No route to host
<lechner>but there is a route
<vagrantc>jackhill: i haven't gotten anywhere near a guix image yet ... just the kernel so far
<vagrantc>jackhill: tested booting debian with it
<vagrantc>jackhill: also, the bootloader requires some non-FSDG stuff, but could make a "bring-your-own-bootloader" image
<jackhill>vagrantc: yeah, anyway if I can help by testing let me know. So far, I've only installed Guix on the factory Debian image.
<gnucode>I kind of wonder how difficult the emacs build will be with it having merged tree sitter, which uses a fair amount of rust.
<nikken>hey everyone, i think i just stumbled over a minor bug in the html docs: links to the Cookbook (from eg. "Getting Started") 404 because they link to /manual/en/guix-cookbook/index.html whereas the cookbook is at /en/cookbook/en/guix-cookbook.html
<nikken>should i send a mail to bug-guix@?
<jackhill>vagrantc: but I guess I'm also interested in learning what the process is for these arm systems. Perhaps my naïve impression that most of the hardware-specific bits would be in the kernel
<lechner>nikken / i would wait for a response here first. the working link seems to have the language encoded twice, or was a typo
<oat>Hello could someone help me with the latest Giux Installer version I add VGA=0x315 in the Linux line over the grub: AMD x86_64 HD Radeon: logs ice-9/boo-9.scm:1685:16: In procedure raise-exception:
<oat>In procedure stat: No such file or directory: "/etc/static/configuration"
<oat>The installer throws a scheme@(guile-user)>
<oat>Could I run the installer from there?
<vagrantc>jackhill: yeah, most hardware-specific stuff is kernel ... sometimes mesa and related stuff
<nikken>lechner: sure thing, i'll check back tomorrow :)
<jackhill>cool, I definitely hava much to learn
<lechner>nikken / for a bug report, it may be more helpful to find all, or at least more, broken links here or maybe even in the entire documentation
<lechner>nikken / you could even run this spider tool, or any of the ones below it
<whereiseveryone>did this get logged? or no because I still haven't IDENTIFIED myself?
<nikken>lechner: i suspect the typo (?) to be in /doc/htmlxref.cnf because there are no actual URLs in the guix{-cookbook}.texi but i'll happily go for a 404 hunt tomorrow!
<lechner>nikken / i would run it on the live website
<civodul>oat: hi! what did you see before that prompt? did you go through all the steps until it produced a config file?
<civodul>or is it when booting the installed system that you get this error?
<oat>civodul: it's when booting the install system
<lechner>Hi, can anyone 'guix deploy' on localhost with ConnMan instead of NetworkManager?
<rekado>whereiseveryone: on #guix you don’t need to be identified.
<lechner>that's why they were asking!
<HexMachina>Hi all! I'm running Guix on a foreign distro (Ubuntu 18.04), and I noticed possibly a bug? Or at least something I wasn't expecting. Looks like the script creates symlinks in /usr/local/share/info to files in /var/guix/profiles/per-user/root/current-guix/share/info* - this includes guix's "dir" info index file. This replaces the
<HexMachina>existing dir file in /usr/local/share, which includes info docs for a few packages I'm installing from source manually and not managing through guix
<HexMachina>End result of this is that after installing Guix, I can no longer access the info pages for software I manually installed from source into /usr/local/share/info
<HexMachina>Is this intended behavior?
<lechner>sneek / later tell unmatched-paren: With greetd, have you seen this error from pam_mount? Hxproc_run_async: ofl: No such file or directory
<sneek>Will do.
<lechner>sneek / botsnack
<lechner>sneek: later tell unmatched-paren: i believe our 'pam-mount' lacks the input 'hxtools', which ships the 'ofl' executable but is presently unpackaged
<Fare>Ahem, I'm trying to install guix in a chroot... that was easy enough when the cross-install system was debian, but is surprisingly harder now that the cross-install system is guix(!)
<lechner>sneek: later tell unmatched-paren: it's also noted in the source code (sorry, the upstream Git browser is not working currently)
<sneek>Will do.
<lechner>Fare / why do you need a chroot?
<lechner>Guix comes fully isolated
<lechner>for some value of "fully"
<lechner>all installed executables are reusable in any context via 'guix shell'
<lechner>there are also some container options
<lechner>Hi, ConnMan in Guix disables the internal DNS proxy on port 53, right?
<civodul>no idea
<civodul>mbakke: thumbs up for merging the KDE patches!
<Fare>lechner: it's installed on the harddisk, I want to install it on a usb key
<Fare>so I can run from the usb key
<Fare>especially important when travelling
<Fare>or switching hardware
<Fare>I suppose that one solution is: boot on debian on USB, then use that as cross-install system for other USB. Sigh.
<Fare>"Debian: the Guix cross-installer!"
<oat>Why did the Guix latest version crash my HDD?
<florhizome[m]><Fare> "lechner: it's installed on the..." <- So you want a live Iso?
<florhizome[m]>You should be able to generate an iso via commandline and flash it onto your stick
<Fare>not an ISO, a bootable USB with my entire environment.
<Fare>an ISO is especially annoying, because it won't let you partition the rest of your disk as data.
<Fare>Also, I want my disk encrypted
<Fare>i.e. carry your data with you as you travel, not in your vulnerable device (vulnerable to being stolen or tampered with)
<Fare>(or forced open at the border)
<Fare>"look, this is a regular Windows gaming device"
<CompanionCube>well, if you actually have the usb key on you, they can just require the password before they let you in.
<Fare>if they know you have it on you and where you hide it, maybe.
<CompanionCube>which they will, because they're too paranoid *not* to find it
<florhizome[m]>Ah i understand.
<florhizome[m]>I actually used chroot successfully from the installer iso to operate on my guix installation after windows update broke grub a few months ago
<Fare>certainly, if they are going to drug and torture you in a fake russian prison, you're toast anyway. But there are intermediate rubberhose attacks that you can survive if only you have plausible deniability.
<Fare>maybe I should kill the guix daemon on the main installation so I can start one in the chroot?
<CompanionCube>this is true, but torture is a much greater jump than just scanning and looking at usbs
<florhizome[m]>That doesn’t make sense
<florhizome[m]>It’s not important where that build daemon runs
<Fare>dunno, but when I chroot into /mnt, su and sudo complain about something (PAM not working?) and when I use root power to run guix system reconfigure, it complains that guix system: error: fport_read: Connection reset by peer
<florhizome[m]>Have you tried using guix system deploy or init to the device?
<nckx>Why are you using chroot to install Guix System?
<nckx>Regardless of whether it's technically possible, it's not supported, nor necessary.
<lechner>Hi, how does 'guix deploy' establish the SSH connection, please? Here, gives this error while the openssh client performs in a shell guix deploy: error: failed to deploy lechner-desktop: SSH connection to '' failed: No route to host
<Fare>yes, herd stop guix-daemon helps
<lechner>i'd be afraid to stop it
<Fare>florhizome[m], aha, I hadn't though of deploy or init... will deploy do what I think including setup EFI correctly?
<nckx>Please, if you're just installing Guix System, read the manual first. Mucking about with a chroot makes no sense at all. You're hurting yourself.
<Fare>OK, I ran guix system reconfigure after killing the daemon outside the chroot and restarting it inside... and it's building a new firmware tarball... why??? Shouldn't it just activate the existing system with different boot/root parameters???
<florhizome[m]>I haven’t tried deploy but init is what you run in general to install a system for the first time
<Fare>why is it doing a update when I didn't guix pull to ask for an update?
<lechner>it needs a good bootloader
<nckx>Probably because you're installing in such a bizarre way.
<Fare>nah, it even did a graft on lvm2... are there security updates done even without asking for it?
<lechner>it's a new frontier!
<nckx>Fare: Always, unless you ask for no grafts with --no-grafts.
<lechner>you are trying to outsmart the daemon
<lechner>it's not possible
<Fare>ok, I'll try rebooting... see you on the other side, I hope.
<nckx>lechner: IPv4 trouble, perhaps?
<nckx>Or lack of IPv6, better said.
<lechner>nckx / which one?
<nckx>That's just a guess, but ‘no route to host’ doesn't leave many options. Certainly nothing to do with ports or services.
<nckx>lechner: 2604:21c0:125:10f0::d35 presumably. You'd know better than I do.
<lechner>no, i meant does guix deploy query only one?
<lechner>the ipv6 is wrong
<lechner>i switched to a new ISP today and got a new prefix, but the internal IPv4 local address works
<nckx>So is an internal hostname?
<Fare>Failed: somehow the BIOS didn't recognize the device as bootable :-(
<vagrantc>curious about the release workflow ... is version-1.4.0 the baseline for the release, or will master be merged in before the release?
<lechner>nckx / well, it's both, in the sense that my router also resolves the local dhcp addresses, although I never figured out how that worked with DNSSEC. maybe my router is a trusted resolver
<Fare>is there something magical I need to do on an USB disk so it's recognized as bootable?
<nckx>lechner: I mean, it seems ‘clear’ that this is a name resolution error, but I'm not claiming that makes the problem obvious. Just that it's the problem. Guix uses guile-ssh, throug guix/ssh.scm, but I'm not aware of any known issues that would cause what you're seeing.
<nckx>Just for debugging, I'd try setting the Internet-facing A/AAAA records to match your internal ones. If it suddenly works, you know where to look.
<nckx>Fare: Nothing magical, but do make sure you're using the ‘grub-efi-removable-bootloader’.
<lechner>Fare / did the USB stick show up in your ad-hoc boot menu? did you use legacy MBR or EFI? If EFI, did you try the removable media path (or whatever the name is)?
<nckx>This will install GRUB as BOOTX64.EFI (clobbering any other you might have, which is why it's not the default). Most firmwares require this because they ignore boot entries for ‘removable’ media.
<nckx>It's like the default entry point, or whatever used to be the MBR, or however you want to regard it.
<Fare>the usb stick is missing a bootx64.efi, I think
<lechner>nckx / i am unable to assign an A record to this equipment because I am behind NAT but I will add the IPv6 as you suggested. I'll also look into whether guile-ssh aborts on the the faulty IPv6 rather than trying IPv4 next
<nckx>Sounds like a plan.
<Fare>Aha, I see there's a grub-efi-removable-bootloader
<Fare>as contrasted to grub-efi-bootloader
<nckx>Are my messages not coming through?
<Fare>nckx, seeing them now
<nckx>ACTION unplugs the wi-fi and plugs it back in.
<nckx>Fare: …anyway. Yes. That's the answer. Although ‘mv’ works too…
<nckx>Fare: So they are arriving late? Or not at all? (Obligatory ‘can you read this?’ joke.)
<Fare>nckx: "mv" ? from what to where? Or did you mean "cp" to locate a proper bootx64.efi ?
<nckx>I meant mv, to rename it. cp, of course, works fine too.