IRC channel logs
2022-11-23.log
back to list of logs
<Fare>yikes, after building rust 1.54 and 1.55, it now builds 1.58.1... <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 <abhicherath[m]>So my rust build just competed (ran guix build -e '(@@ (gnu packages rust) rust-1.65)' <nckx>‘guix install /gnu/store/…rust-1.65’ <zimoun>civodul: thanks. (aside, I did not found it in the documentation ;-)) <nckx>Yes, didn't guix build print it <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 <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]: modify doc/guix.texi, run ``guix shell -D guix'', inside there do ``./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)'' <abhicherath[m]>how can i get git send-email to give me something i can copy and paste into thunderbird hehe <abhicherath[m]>maa no worries it's something ive been meaning toget around to anyway <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? <unmatched-paren>(arguments (list #:configure-flags #~(list (string-append "CC=" #$(cc-for-target)))) <nckx>lechner: <currently works only on port 25> Wait wat? <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. <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>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 <unmatched-paren>what should i call a variant of an emacs package that uses the latest commit instead of tag? <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 <unmatched-paren>actually, i think it migt be better to use a literal ellipsis in the store path example <unmatched-paren>i *think* the ... will be expanded by texinfo to an actual ellipsis unicode character <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. <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>abhicherath[m]: e.g. you can do -1 which has the same effect as HEAD^ <unmatched-paren>well, nckx is a maintainer, and there seems to be a consensus that non-maintainer committers should be the ones vouching <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. <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>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 <unmatched-paren>abhicherath[m]: yeah, when i wrote that i didn't realise -v REVISION didn't work <mirai>git send-email munching '-v' <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? <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 <nckx>florhizome[m]: Uh, yes, nominally. <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>nckx / mbsync is the other way around <nckx>Don't test many other tools then, you won't like what you find. <nckx>ACTION never invokes it interactively. <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]>unmatched-paren you mean because we lack the dependencies? I would try the ...next method <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>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. <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 <unmatched-paren>florhizome[m]: there are patches for the latest wlroots/wayland/libdrm/etc on the mailing list <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]>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 <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 <podiki[m]>according to guix refresh, but that's not foolproof <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 <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 <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 <lechner>Hi, what's a reason why I might not be able to start sshd manually in a root shell, please? <abhicherath[m]>what's the easiest way to see if there's substitutes for a given package for a given system? <nckx>guix weather --system=aarch64-linux … <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>Oh, I thought git-devel was a mailing list. <nckx>ACTION tried ‘/join #git-devel@irc.libera.chat’ just for fun and it… ‘works’. In the wrong sense. <nckx>I didn't know @ was legal. <nckx>So of course now I created #~gexp and #$ungexp. <nckx>abhicherath[m]: It joins (well, creates) a channel literally named ‘#git-devel@irc.libera.chat’ 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>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. <nckx>lechner: No, but it implements ‘on-behalf-of’ socket listening vaguely like systemd. <nckx>So it does seem like you have sshd already? <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 'lechner-desktop.us-core.com' failed: No route to host <vagrantc>jackhill: i haven't gotten anywhere near a guix image yet ... just the kernel so far <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 :) <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. <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 guix-install.sh 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 <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 <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>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>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>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]>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 <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 'lechner-desktop.us-core.com' failed: No route to host <Fare>yes, herd stop guix-daemon helps <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? <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? <nckx>Fare: Always, unless you ask for no grafts with --no-grafts. <lechner>you are trying to outsmart the daemon <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. <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>i switched to a new ISP today and got a new prefix, but the internal IPv4 local address works <nckx>So lechner-desktop.us-core.com 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 <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? <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.