<apteryx>ecbrown: I'm curious about fsck run; how would it affect SSH access? Do you mean the fsck check at boot where it basically pause until it finishes? If so, I'm sure that's not that as I can login the VM in the QEMU viewer (it's up and running)
<drakonis>pkill9: pjotr tries to explain that in the email itself
<ecbrown>apteryx: my understanding of your problem was that you are using hurd, and hurd uses ext2. in my case, hurd is kind of crashy and it forces an fsck when rebooting. it can't start ssh daemon because it doesn't boot
<ecbrown>(but i think console would show you if you had to fsck)
<apteryx>so, hum, I can manually run the program of a shepherd service start slot fine in a test VM as the root user, but somehow the same fails when run by shepherd, with a mysterious 'Unbound variable: mkstemp' error, which doesn't make sense.
<ss2>raghavgururajan: I had it with 5.12.6, the machine is a Lenovo X61s. After rolling back to 5.10.39, these freezes haven't happened again. Looking at the hardware specs, they appear to be very similar. I haven't reported it upstream yet.
<efraim>sneek: later tell vagrantc I'd love to hear about the pinebookpro image, mine just arrived in country and I should be getting it later this week
<mschilli>The package in question is 'bseqsc'. I am able to follow their tutorial on https://shenorrlab.github.io/bseqsc/vignettes/bseq-sc.html up to running `bseq_proportions` without any issue when installing it manually to my user library on my Gentoo system (using system R and libaries and all). However, when I run try the same after a `guix environment --ad-hoc r r-bseqsc` (on the very same system, just
<mschilli>in case), calling that function results in an error: 'return code from pthread_create() is 22'
<emestee>ecbrown: I had the same problem and I rearrange it with org-mode and tangle, I now have "literate config" that generates .emacs.d/init.el
<emestee>i have it across half a dozen machines and it works great
<drgibbon>oh, Scheme, OK, well I hope to learn a bit of that by using Guix anyway.
<drgibbon>I use org pretty heavily, and a bunch of other stuff, auctex, polymode, etc etc.
<emestee>ecbrown: DT and SystemBuilders on youtube have great tutorials on how to do this
<drgibbon>No ivy-bibtex :D What's the deal if some Emacs package is missing from Guix, you just have to contrib a new one?
<ecbrown>emestee: thanks, i will have to take a look!
<ecbrown>drgibbon: the old mechanisms for loading elisp are still available, of course ;-). definitely package it up --- but also be careful of licensing / free-software matters. some code out there is "questionable"
<ecbrown>i hope a firewall expert could review this. i believe the iptables example lets one ssh in, but can't get out! (i don't believe that the average n00b looking for a starter firewall set wants this)
<ecbrown>from my own experience, i shut off the firewall because i couldn't figure it out :-(
<emestee>ecbrown: the rules in the example dont imply the blocking of outbound traffic, that's why it'd work
<ecbrown>emestee: the example looks innocuous enough. i think one needs to keep the state of outgoing ssh connections so that the ssh user can receive response from remote server
<emestee>(for early keyboard I have a patch somewhere to regenerate initrd with proper drivers)
<emestee>then you may want to change the installer kernel parameters to point to the root fs device explicitly as opposed to by uuid
<ingor>it kind of works meaning at least i can now start the grub of the image, but that's it... from there i still get the loop about waiting for the partition
<emestee>yes I believe there is code that repeatedly tries to enumerate all available devices
<emestee>it's possible that this is a genuine bug, i didnt write any of the guix code so its a bit hard for me to navigate in it, I am a newbie schemer
<emestee>I have no solution to offer I am afraid, other than to say it's a known and annoying problem
<ingor>i'll try to replace the root on the grub console so i can check if it works without redoing the image... working on a very bad 3g connection
<ingor>what i don't understand is why they are using --root=31393730-3031-3031-3139-343934363833 instread of --root=$root or something like that, specially after the search --fs-uuid --set 1970-01-01-19-49-46-83
<emestee>I have no idea. My disdain to magic numbers is great.
<ingor>which by the way works just fine... i mean search --fs-uuid --set 1970-01-01-19-49-46-83 sets $root to the root partition
<ecbrown>emestee: on the question of the firewall rules -- i just put the manual's rules in, and i lost my ssh connections from this laptop, and can't make new ones. revert to nftables and working rules, and it works again. add state rule to iptables, and it also works.
<emestee>in principle if you have firewalling you need conntrack
<ecbrown>just to summarize: i think the "average" user wants something like `ufw allow ssh' behavior. this instead sets up a bastion/black hole
<ecbrown>i don't want to knock the use-case for that, but speaking anecdotally, i could not figure out the firewall to dwim so i shut the damned thing off. this is the worst possible scenario
<emestee>ecbrown: yes but honestly at this point of time guix sd isn't for 'average users'
<pjotrp>maybe sexp-pack is not such a good choice for a name
<ecbrown>well, i won't argue that point. but i would argue that firewalls are an arcane science and pf, nftables, ipfw, etc. are DSL's that can be outside bailliwick of software developers. the software developer expects to ssh into the machine, and that's it -- of course they need to get out to the web for stuff
<pjotrp>it is obvious where it came from. How about sixp-pack
<emestee>ecbrown: tbh a decent firewall language would go a _long_ way for guix utility
<emestee>guix is already looking very attractive for devops
<pjotrp>but anyay, the reasoning is that a piece of software usually is just a bunch of files
<apteryx_>civodul: hi! Would you have an idea as to how shepherd autoload failures/warnings at compilation time may apparently end up causing 'mkstemp' to appear as an unbound variable? https://paste.debian.net/1199486/
***apteryx_ is now known as apteryx
<apteryx>I thought I could disregard the warning but I'm seeing an exception thrown about mkstemp being an unbound variable at run-time, when the service runs in Shepherd. If I manually run things in the VM as root, all is good. So it sees some weird compilation problem.
<apteryx>perhaps #:autoload, which I used in my module, is not compatible with the module-autoload! directives used in (gnu build shepherd), which my module imports?
<apteryx>my module declaration has #:use-module (gnu build shepherd) and also #:autoload (shepherd service) (fork+exec-command)
<ingor>i'm trying to read the partitions ids by doing: (use-modules (ice-9 ftw))
<ingor> (scandir "/dev/disk/by-id") but it doesn't work... any idea why?
<apteryx>don't mind the git history much, it's dirty :-)
<ecbrown>dstolfa: i think virt-manager has a command line component that actually works, or perhaps if manyally specifying a network. "no bridge"/"no work" maybe means just the gui can't get through it, but there's a way.
<ecbrown>i just havent' done it because i seem to recall it's just another dsl for specifying a vm that i don't need because i can do it in qemu anyway
<ecbrown>there's some like vm store "intelligence" i think
<dstolfa>you might be referring to virsh + the XML description of the VM, right?
*ecbrown 's jaw drops having discovered an incantation that gets emacs-guix to work on gnu system and foreign distro
<apteryx>civodul: so if you run 'make check-system TESTS=jami-daemon', you'll see it failing without a clear error, but that error is caused by mkstemp being unbound for some reason. That's from the send-dbus proc in (gnu build jami-service).
<apteryx>the quickest way to see what is actually failing in a start slot with shepherd seems to be to run the test VM OS with: ./pre-inst-env guix system build -e '(@@ (gnu tests telephony) %jami-daemon-os)' --no-offload -> run vm -> issue 'herd restart jami-daemon'. This error reporting shortcoming in Shepherd was reported in https://issues.guix.gnu.org/33968.
<dstolfa>ecbrown: maybe we should make a few bug reports that we bumped into...
<dstolfa>it'll never get fixed unless we have some kind of persistent PR
<lastebil>I have a (constantly) reproducable bug in the installer (iso) and it suggests mailing the output, but I'm unsure how to get that error output to a mail (as it's in a dialog window, and I am in the installer, not an ssh session)
<dstolfa>ecbrown: i do think that the bridge thing is worth reporting for virt-manager though
<lastebil>is there an error file on disk that, if I ssh'd over, I could then mail?
<Noisytoot>In the GPLv3: "Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public Licen
<Noisytoot>se, you may choose any version ever published by the Free Software Foundation."
<lfam>Send whatever is sufficient to explain the bug (as far as you understand it) and to allow others to reproduce it
<ecbrown>yes, i have to bring another system up because my main system can't be broken :-)
<lfam>Guix is probably the primary place where people use Hurd, so we shouldn't let it stay broken. But, we probably aren't going to delay security fixes because things don't work on Hurd. It's still pretty experimental
<dstolfa>lfam: i think best effort in these kind of cases applies, security updates on the majority of userbase is probably more important at this stage as you said
<sneek>nckx, dstolfa says: so i wrote a service that compiles and loads... it's a decent amount of code, and i was wondering what the best way to test something like this would be. perhaps something with a guix system vm? how would i get it to use the guix i built?
<ss2>uh, the small chassis doesn't help against heat management. They will just emit heat eventually. Just got me a docking station and hoping that this year's heat won't get the mainboard this time.
<nckx>dstolfa: Have you considered & rejected ‘./pre-inst-env guix system reconfigure’? I just test services ‘in real life‘ whenever I can. Not much of a VM fan, I spend more time debugging the VM than the point.
<dstolfa>nckx: i've tried, but i ran into a weird thing where it doesn't find my service type and suggests i add (gnu services vpn) to my use-modules, but i've done that so i assummed i'm doing something wrong
<lfam>To clarify my previous message, the things built for `guix environment guix` aren't protected from garbage collection. So, after every gc, you have to re-do `./configure --localstatedir=/var && make`
<lfam>Otherwise, you'll get confusing results from pre-inst-env
<dstolfa>nckx: yeah, the alternative is putting it all into /etc which is not what we want
<nckx>dstolfa: Er, Gentoo, Exherbo, Nix, Guix, if you really care :) I have more exes but the .config is younger.
<nckx>lfam: It's not worth burning out over, just put it aside, see if it calls to you later. (They often do IME.)
<lfam>I keep feeling like it's almost there and then it goes sideways
<lfam>The most annoying thing is that Guix System worked fine until the first reconfigure
<nckx>And you can't get back to that state? That's weird.
<lfam>Since then, the first generation stopped working (the NIC doesn't work), and subsequent reinstallations also don't work
<lfam>So, the first installation did something that wasn't accounted for
<lfam>It must have somehow borrowed part of Debian
<nckx>→ why I'm not a fan of borging. Even when it ‘helps’ it hurts.
<lfam>I didn't even end up using the attempt that installed to the running system
<lfam>But, there must have been something left over on the SSD that was re-used when I finally installed from a separate system
<nckx>Does the NIC have some kind of NVRAM? I'm not very versed in these things, but I remember I once had a WLAN card that remembered its MAC over reboots. Might've been the BIOS saving it, I dunno, but it confused me plenty
<itd>re first generation (not) working: did you already try to install debian prior to installing guix?
<nckx>The only phase that mentions ‘/usr/bin/env’ is a phase that *adds* it to avoid store references.
<lfam>dstolfa: Whatever you built manually is likely not the same thing as what it's trying to build during reconfigure. Check the name of the derivations that fail and succeed to make sure they are different
<lfam>dstolfa: Assuming that there is only one strongswan package in your Git tree, then `./pre-inst-env guix build --no-grafts strongswan -d` needs to print the same derivation name as what is being used during `reconfigure`
<lfam>If they are different, and that's unexpected, then either your development setup is still messed up, or there is more than one strongswan package defined in your Git tree
<lfam>itd: It's why I think the bootloader / EFI stuff is important to fixing my problem
<lfam>itd: Nothing else could have been erroneously used by Guix System except the boot stuff.
<lfam>Another weird symptom is that a USB NIC also doesn't work in Guix System
<lfam>So, the entire networking complex isn't working right
<nckx>Feeling very first-world problem, but I can't figure out why the kernel does the equivalent of ‘if (FBCON_LOGO_CANSHOW) /* the logo can be shown */ logo_shown = FBCON_LOGO_DONTSHOW; /* do not show the logo */’ Like, WTF.
<lfam>I'm not certain but I assume the USB is part of the networking complex, since the Macchiatobin is really a networking board
<lfam> /gnu/store/7sfbiqh21h90bc6zi8br1xh60m6qgdd5-bash-minimal-5.0.16/bin/sh: /tmp/guix-build-linux-libre-arm64-generic-5.10.40.drv-0/linux-5.10.40/scripts/bpf_helpers_doc.py: /usr/bin/env: bad interpreter: No such file or directory
<apteryx>civodul: the send-dbus helper in (gnu build jami-service) is annoyingly slow (2.5 s minimal). It seems to be used mostly in waitpid following a fork+exec-command process; any idea as to why it needs so much time?
<apteryx>it seems to be generally the case: ,time (let ((pid (fork+exec-command '("sh" "-c" "echo 'hello!'")))) (waitpid pid)) -> 2.5 s
<itd>lfam: dual boot debian/guix and see if debian still works? ;) (looks like some people tried to use nix on the macchiatobin  not sure if there's some inspiration there : https://github.com/bgamari/mcbin.nix )
<lfam>Debian is working itd. That's where I am doing my work