IRC channel logs

2021-05-31.log

back to list of logs

<ecbrown>apteryx: about the ssh bug: also perhaps the vm needs fsck run
<drakonis>ho ho
<drakonis>i'll have patches soon
<drakonis>i just wish i didnt have to recompile whenever i changed a step
<drakonis>but okay.
***Noisytoot is now known as noisytoot[x]
***noisytoot[x] is now known as Noisytoot
<flatwhatson>so 'git-checkout' re-uses a single repository clone for multiple builds, but afaics 'git-reference' does not, which can be pretty wasteful for larger repos like emacs
<flatwhatson>is there a good reason it needs to be this way?
<drakonis> https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00430.html oooooooooooooooo
<drakonis>this one looks like a killer idea
<pkill9>i don't understand it drakonis
<pkill9>what would a 'sexp-pack' be?
<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
<pkill9>i tried to understand but didn't get it
<drakonis>basically, its a way around having to import hundreds of dependencies into the guix tree for a single package
<drakonis>a sexp-pack is a packed up dependency resulting from a impor
<drakonis>import
<drakonis>at least as far as i can understand
<drakonis>btw, what's the recommended way to list the contents of a directory
<drakonis>i'm trying to fix a package but i'm having some issues figuring out how to do that inside a build
<drakonis>because i need to find a specific file
<pkill9>drakonis: so it's just a bundle?
<drakonis>yeah?
<drakonis>kinda like that i guess?
<pkill9>a bundle of package definitions?
<drakonis>hmm, yeah
<drakonis>it'd be like invoking import during a build process i think
<drakonis>alternatively, it'd allow replacing the dependency fetching phase of a build system
<pkill9>what about ones that need patching?
<pkill9>oh hmm
<pkill9>the build system itself wouldn't need patching
<pkill9>just the sources, like it suggests
<drakonis>yes
<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)
<raghavgururajan>ss2: 5.12.(3|4|5|6)
<apteryx>ecbrown: ah, sorry, I'm using a VM made with 'guix system vm'
<apteryx>which is not Hurd
<ecbrown>my mistake, sorry for the noise. ps my 10022's work
<apteryx>no no, thanks a lot! I'll try with your command and the Debian Hurd image, for the kicks!
<apteryx>If it works I'll at least know that QEMU is sane
<apteryx>then it'll point to the VM image produced being faulty somehow
<apteryx>I bet it'll works, because I'm able to SSH into the childhurd VM I'm running, which must use that hostfwd trick
<apteryx>the childhurd service specifies a network device with --device, and reuses that with --netdev where it uses hostfwd
<apteryx>which is not the same as the '-nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22' the manual hints at
<apteryx>ecbrown: if you are curious to test the same system on your side, here's the trivial os declaration: https://paste.debian.net/1199447/
<apteryx>you generate the vm with 'guix system vm os.scm'
<apteryx>the command for the childhurd is: qemu-system-i386 -m 512 --device rtl8139,netdev=net0 --netdev user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:15900-:5900 --snapshot --hda /gnu/store/84881fwqhwl37n7gbh8lhg3i01sxrp2p-disk-image --no-reboot --enable-kvm
<apteryx>(and this works)
<apteryx>I'm guessing my minimal os is too minimal and is missing a networking component
<apteryx>I'm retrying with (service dhcp-client-service-type) added
<apteryx>works :-)
<ecbrown>noice
<apteryx>that was a silly mistake of mine in retrospect, but I'll add a note to the manual to make sure nobody else goes through the same exercise
<apteryx>thanks a lot for your reply on the tracker :-)
<ecbrown>hah no problem
<apteryx>ecbrown: would you mind me to thank you in the doc addition commit message?
<ecbrown>well it's not necessary, but i would not be opposed! thanks for the offer
<apteryx>done! :-)
<lfam>Howdy
<apteryx>hello, lfam!
<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.
<lfam>Weird
<vagrantc>hello guix
<apteryx>lfam: ah, I think there was some error masking going on in my code, now I could see an error that makes more sense, by manually running it
<apteryx>(again)
<lfam>I'm glad you found an error ;)
<lfam>Hi vagrantc
<lfam>I got an interesting anecdote about my problem with the macchiatobin
<lfam>The problem is that, after the first reconfigure, the network stopped working. I'm sure something else broke too but this is what I noticed
<lfam>Somebody else installed Nixos on their macchiatobin today, and had the exact same pattern
<vagrantc>curious
<lfam>I installed from Debian, they used the Nixos installer
<lfam>But it seems like something about how our systems update themselves is breaking something
<lfam>I'm using 5.12, they are using 5.11
<vagrantc>oh, fwiw, i made a live Debian image for arm64 today, if you ever need it again :)
<lfam>Oh amazing :)
<vagrantc>it was a byproduct of my pinebook + pinebook-pro image testing
<vagrantc>one image, two laptops. apparently someone's got some patches to also support the pine64-lts with the same u-boot as pinebook
<vagrantc>so that would work too
<lfam>I was able to stop breaking the Debian installation on my SD card. I was holding `guix system init` wrong
<vagrantc>lfam: ah, how do you hold it better? :)
<vagrantc>since i had similar problems with guix system init on the mustang building pinebook* images
<vagrantc>maybe i hold it wrong also
<lfam>I just didn't realize that I had to mount all the target filesystems
<lfam>It's been a while...
<lfam>So, it was using the host's /boot/efi
<vagrantc>ah, yes.
<lfam>I also missed the part about turning on the ESP flag for that partition
<lfam>I've never used EFI before
<vagrantc>yeah, EFI takes some getting used to
<vagrantc>some nice things, some annoying things
<lfam>My hypothesis about the macchiatobin is that something about `guix system reconfigure` overwrites some useful data in /boot
<lfam>Because, my impression is that some things in there are used to initialize the hardware or explain the hardware to the kernel
<lfam>Does that seem like it's on the right track?
<lfam>I'm reinstalling now, and if it works, I'm going to preserve /boot before reconfiguring, so I can compare them
<lfam>I'm not sure what else could go wrong in this way
<vagrantc>not so much
<vagrantc>there's ... efibootmgr ... would be good to look at the output before and after
<vagrantc>i think that's what it's called
<lfam>I'm adding it to the reinstallation config
<lfam>The link doesn't work after installation now. I tried it a couple times
<lfam>It always says NO-CARRIER in `ip link show`
<lfam>efibootmgr output: <https://paste.debian.net/1199451/>
<drgibbon>n00b question about Guix as OS: How often is `guix system reconfigure` run in normal day to day use? Is it usual to run that after every `guix pull`?
<lfam>drgibbon: You run it whenever you want to update the system
<drgibbon>So.. guix pull updates the repo/software list, and the system reconfigure actually does the installing?
<lfam>Yeah
<drgibbon>ok thanks.
<drgibbon>I know it's a bit more complex than that, just trying to work out the basics.
<lfam>`guix system reconfigure` effects the system-type stuff. Kernel, services, packages named in config.scm, etc
<lfam>For things you've installed with `guix install`, you use `guix upgrade`
<lfam>For both cases, `guix pull` controls your "view" of what's available
<lfam>It's kind of like `apt-get update`
<drgibbon>oh right, I didn't realize `guix upgrade` was separate from the reconfigure command.
<lfam>It's to let users do their own package management without administrator privileges
<drgibbon>cool
<drgibbon>is it also possible to ignore that, and use root for it all?
<drgibbon>say, `sudo guix install whatever`
<lfam>Then you'd do `sudo guix upgrade`
<lfam>If you don't want to install any packages per-user, you should put them all in config.scm
<drgibbon>ahhh
<lfam>See ya later
<raghavgururajan>Any thoughts on this (https://lists.gnu.org/archive/html/help-guix/2021-05/msg00131.html)?
<drgibbon>Is immutable-store true by default? (or how would I go about checking the default value..)
<pkill9>how much space and RAM does qtwebengine need to build?
<pkill9>i guess it's chromium so
<pkill9>a lot
<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
<sneek>Okay.
<efraim>sneek: botsnack
<sneek>:)
<raghavgururajan>pkill9: For some reason I was able to build qtwebengine on my melty x200t with 8gigs of ram.
<raghavgururajan>efraim: I was wondering if you any clue with this issue (https://lists.gnu.org/archive/html/help-guix/2021-05/msg00131.html)? Just wanted to pick your brain as some of your commits were go-related packages. :)
<efraim>ah, yeah, go can be annoying
<raghavgururajan>> After rolling back to 5.10.39, these freezes haven't happened again.
<raghavgururajan>ss2: Same here. But I used `kernel linux-libre-lts` in my config.scm, instead of roll-back.
<efraim>it doesn't look to me like it thinks it's a different package
<efraim>does go-0xacab-org-leap-shapeshifter build alright?
<raghavgururajan>yeah. It seems go sources from inputs are made available under /src in the build-dir. shapeshifter was missing but others were there.
<raghavgururajan>Yeah, it builds fine.
<efraim>perhaps the source gets installed wrong?
<efraim>i'll checkout the patchset
<raghavgururajan>Thanks efraim, I appreciate it.
<ss2>raghavgururajan: oh, didn't mean by rolling back. I installed this version instead. Should use this term properly.
<ss2>do you have logs? I've got two, incomplete bug messages off the kernel.
<civodul>Hello Guix!
<raghavgururajan>ss2: Gotcha!
<raghavgururajan>No, I didn't.
<raghavgururajan>Hey civodul
<raghavgururajan>* didn't get the logs.
<efraim>raghavgururajan: I'm not sure why it wasn't picked up, but I was able to place it manually with this snippet: https://paste.debian.net/1199453/
<raghavgururajan>efraim: Thanks so much.
<zap>hello guix!
<emestee>weeeeeeeeeeeee
<bricewge>Hello Guix
<bricewge>raghavgururajan: Did you managed to package home-assistant?
<drgibbon>No Signal users on Guix? I will have to learn how to package once I get going :)
<zap>\o/
<zap>drgibbon: Signal is free software?
<pkill9>the problem with the desktop signal client is it is an electron application
<pkill9>which is a nightmare to package due to the dependency hell
<pkill9>so it hasn't been packaed
<pkill9>packaged*
<drgibbon[m]>ahhh
<efraim>sifive board just arrived!
<drgibbon>zap: As far as I know it is, yes.
<drgibbon>efraim: hadn't heard of it, looks cool :)
<pkill9>nice efraim
<pkill9>it's ridiculous that web browsers needs 16G RAM to build
<pkill9>have to spin up a VPS just to build it
<mschilli>Hello, I have an issue with an R package when installed via Guix. Is there anyone that might be able to give me some pointers to get to the bottom of this?
<pkill9>efraim: how much did it cost?
<raghavgururajan>bricewge: home-assistant?
<raghavgururajan>Oh that.
<raghavgururajan>Not yet started.
<bricewge>Ok, it seems tricky
<pkill9>I would like to move the packages field in OS config to a service
<bricewge>raghavgururajan: BTW, I can reproduce the linphone issue at https://issues.guix.gnu.org/47641
<pkill9>i feel like it makes sense that guix system simply provides services
<pkill9>everything you use it for is a service
<pkill9>LaaS
<pkill9>libre as a service
<pkill9>a service to the user
<cbaines_>pkill9, I think services can already add packages to the system profile, right?
<pkill9>yep they can
<raghavgururajan>bricewge: I see. I still couldn't find the root cause of that issue.
<pkill9>i think the packages field is basically a wrapper around a service that adds packages to the system profile
<bricewge>raghavgururajan: It seems that it's dependencies aren't in sync with what is specified https://gitlab.linphone.org/BC/public/linphone-sdk
<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'
<raghavgururajan>bricewge: you mean missing linphone-sdk as depenency?
<bricewge>raghavgururajan: I can produce a coredump but it will contain my credentials
<mschilli>Any advise would be greatly appreciated.
<raghavgururajan>fake account may be?
<bricewge>No, linphone-sdk is a "meta-package" that they use to pin dependencies for the whole project
<raghavgururajan>Yeah. I have packaged them and added independently. Is there a missing dependency?
<bricewge>For exemple for 4.5.17 the version of mediastreamer2 need to be 585b3614
<bricewge>I did not saw them pined to a git commit last time I checked
<bricewge>I don't have access to a "fake account" unfortunately
<bricewge>To make linphone crash I just have to call myself (it doesn't happen in the last version)
<bricewge>When someone call me it make it crash too but it's more difficult to reproduce it
<bricewge>I think it is somewhat linked to the VoIP server configuration
<tissevert>hi guix
<efraim>pkill9: sorry, I was AFK for a bit. $665, from https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW32dvEIR3vHEV%2FPYYkdMA%3D%3D
<efraim>I ordered back in mid-November, just got here today
<drgibbon>Does Guix actually replace the Emacs package.el, or is there a subset of packages available?
<raghavgururajan>bricewge: Thanks for the info. I'll check it out.
<ecbrown>drgibbon: try `guix package --list-available | grep emacs- | sort | less'
<dstolfa>hello guix
<drgibbon>ecbrown: nice, thanks. Quite a bit then.
<ecbrown>drgibbon: i've used emacs for.... forever, and i currently have a .emacs monolith. i've had good luck just composing on the emacs packages i need for the task at hand
<ecbrown>e.g. geiser + magit for guix work. don't need helm, org, etc. lol
<drgibbon>hmm, geiser is a new one for me :)
<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"
<drgibbon>cool cool
<drgibbon>I'm not a real guixer just yet, but the system is looking more and more compelling to me.
<emestee>drgibbon: I am honestly charmed by it, I have a laptop next to me that I installed guix on and use it as a security terminal
<emestee>i find myself more and more often using guix on non-guix machines to install something that the original distro's repo don't have/is slightly outdated
<emestee>also i have a couple of package patches that I keep forgetting to submit
<ecbrown>"behind every guix laptop on the desk is a 64-core threadripper in the basement compiling its code" (or something)
<drgibbon>It looks like a really elegant and useful system, plus a nice and clean, high-standard repo of free software, very cool :)
<ecbrown>and you can make parts of it old and stanky like centos 6
*ecbrown publicizes [bug#48753] iptables example update --- https://lists.gnu.org/archive/html/guix-patches/2021-05/msg01270.html
<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>ecbrown: yes but this is done implicitly
<emestee>actually let me experiment!
<emestee>yes, basically
<emestee>*if* you have outbound blocking (i.e. -P OUTPUT DROP or -A OUTPUT <some conditions> DROP) then you need to have an outbound rule -m state --state ESTABLISHED -j ACCEPT
<emestee>s/<some conditions> DROP/<some conditions> -j DROP/
<emestee>this isnt the case in the manual (the OUTPUT chain is empty and has the policy ACCEPT)
<emestee>so it should not be a problem
<emestee>oh wait
<ecbrown>yezzzzzzzzzzz? ;-)
<ecbrown>m'yezzzzz lol
<emestee>yes you are indeed correct, the REJECT rule belongs to the output chain
<emestee>oh no derp its iptables-save format
<emestee>so basically in the manual's example configuration all outbound traffic is allowed and connection tracking isn't needed
<ecbrown>but the response isn't through 22 is it?
<emestee>the source port of the response will be 22
<emestee>so the rule would be -I OUTPUT xxx -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
<ecbrown>i am scurrying around trying to find a guixsd that i can experiment with, just observe phenomenologically
<emestee>you can reproduce it on any machine
<ecbrown>not one in service :-)
<emestee>ecbrown: https://pastebin.com/Vms6mE0z
<ingor>hello! could someone please help me understand the --root=31393730-3031-3031-3139-343934363833 part of the grub loading script?
<emestee>if you remove the first -A OUTPUT command you wont be able to connect to https anymore, because the other command will block it
<emestee>ingor: are you having an issue booting guix sd on hyperv?
<ingor>yes... on kvm actually
<ecbrown>is that a UUID?
<ingor>more specifically on hetzner
<ecbrown>associated with `blkid'
<ingor>it looks like so, but then the UUID is 1970-01-01-19-49-46-83 which is how the root is identified by search --fs-uuid --set 1970-01-01-19-49-46-83
<ecbrown>that looks like a date stamp, beginniing of unix epoch + some time
<ingor>it is kind of a constant that seems to be used so the disk on which the image is can be identified
<ecbrown>i think there are UUID's and then there are labels
<ingor>right
<ingor>the label is GUIX_X86_64-LINUX_1.3.0
<emestee>ingor: there is an issue in current guix sd, apparently the drivers necessary to mount a virtual DVD in virtualized environments are missing from installation's initrd
<emestee>I've been trying to figure out what drivers are needed under hyperv
<emestee>this is the error you are looking at
<emestee>you could _possibly_ cheat by converting the ISO into a hard disk image, adding that image as an attached hard drive and pointing the installer to it
<ingor> https://lists.gnu.org/archive/html/bug-guix/2019-08/msg00139.html
<emestee>yes this is the error you get when the installer isn't able to mount the root filesystem
<ingor>it is exactly what i did after giving up to do the loop dance in grub
<emestee>did it work?
<ingor>i just dd the iso to an attached disk...
<ingor>no, it didn't
<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.
<ingor> https://pastebin.com/wHTP8kCC
<ecbrown>i'd like to confirm whether you saw something similar, or if perhaps you can use the stock rules and make (new) ssh connections out
<ecbrown>s/stock/current manual example
<Guest10>Hi all, I made this operating-system wrapper macro to allow appending to fields, if anyone is interested: https://termbin.com/z9o9
<Guest10>It's my first time with Lisp so please dont mind the bad code
<zap>Guest10: very cool :)
<emestee>Guest10: yeah ill need to go through this in the evening
<emestee>syntax rules are still magic to me
<zap>copying to my guile snipets file
<emestee>ecbrown: after you _fully_ applied the rules you were unable to connect?
<Guest10>zap: hope you like it, it's pretty useless but I think it looks much cleaner
<ecbrown>emestee: in fact i switched services from nftables to iptables!
<Guest10>emestee: they're still magic to me too, lol
<ecbrown>emestee: did you try? (sorry, i feel like i'm going mad lol)
<emestee>ecbrown: I know from experience that this happens when the creation of rules is interrupted in the middle. I can try, to be sure.
<ecbrown>cool, thanks. because when i read that rule, it looks like it should dwim, but when executing it, it doesn't
<emestee>ecbrown: you are executing it from a remote session?
<ecbrown>it happens on local and remote
<ecbrown>(fortunatley i can ssh into a remote machine still to reconfigure)
<ecbrown>(but not get out lol)
<emestee>wait
<emestee>I think I misunderstood you
<emestee>I assumed you meant your inbound sessions stop working because the return traffic to ssh is blocked, but you're saying you can't ssh _out_ of the remote machine when these rules are applied?
<ecbrown>yes!!!
<ecbrown>because the uber-foreign machine can't talk back!
<dstolfa>hum, what is the preferred way to do cells in guix?
<emestee>ah that is a different story, indeed you need a conntrack rule in the input table
<ecbrown>that's the patch
<emestee>yes :D
<ecbrown>:-D thanks emestee!!!!
<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
<emestee>hmmmm
<pjotrp>that gets compiled or interpreted
<pjotrp>and stored somewhere
<ecbrown>emestee: that is a totally sweet idea. channels or something
<pkill9>pjotrp: i don't understadn what the sexp-packs are
<ecbrown>"packet channels"
<pjotrp>guix can handle dependencies and push stuff in the right place
<ecbrown>or just a scheme dsl
<pjotrp>all sixp-pack has to do is package up - so it is ready for guix compilation
<pjotrp>without using cargo or npm and such
<pkill9>so it just bundles all the dependencies together before ocmpiling?
<pkill9>compiling*
<pjotrp>I found a cargo->ninja converter. That would be useful. Cargo tries to do too much.
<Guest10>emestee: guile DSL to generate iptables files? :o
<emestee>well
<emestee>consider it from a devops perspective
<emestee>i have 50 boxes managed by ansible, ansible is simply not well fit for managing firewall rules
<pkill9>guix configurations generally are just DSLs
<emestee>rules are positional, and modifying any complex setup by ansible requires a flush and reload of everything because it'd be too complex for ansible to read the existing rules
<Guest10>what's wrong with ansible? can't you use it to scp a generic rule file and modify/template it as needed?
<emestee>Guest10: because I want to express it in high level ansible terminology, or, barring that, in high level firewall management terminology
<emestee>of course I can have a template to install rules
<emestee>but then let's say I have a box that belongs both to "mail" and "webhost" categories, and these have different rules, how do I reconcile that?
<efraim>the sexp-pack idea seems similar to how we do the cargo packages now, except that we don't create a big source bundle
<emestee>another actual example, i have a bunch of mail servers where IMAP and webmail access is restricted to specific subnets
<emestee>and a bunch where it isn't
<emestee>so i can either have some evaluated logic that constructs rules based on e.g. a flag, or I can have two different rule templates
<efraim>by comparison, last I checked debian actually combines all the rust sources into one grouping and builds all the outputs in one go
<emestee>so yes a firewall management DSL would be incredibly helpful
<Guest10>emestee: I see, never got that deep into firewall rules. My personal server cluster is using VPNs & sidecar proxies, and at work we use a "cloud firewall". How do you currently manage them?
<ecbrown>(cisco shit or openbsd+pf if i have my choice)
<emestee>Guest10: painfully.
<emestee>Guest10: essentially ufw and ansible conditionals
<emestee>I'm beginning to bind machines to bastions with wireguard so that administrative access is safer and i only need to manage public port rules
<ecbrown>that danged wireguard -- so compelling but no ability to tunnel over tcp/443
<Guest10>I'm not sure how well it'll suit your use case, but have you looked into using a service discovery program like Consul?
<dstolfa>ecbrown: believe me, it's better than the alternatives
<ecbrown>oh like ipsec lol?
<dstolfa>yeah... screw ipsec
<dstolfa>i hate it
<dstolfa>i have spent the last 2 days writing a guix service for strongswan and i absolutely hate how messy ipsec is
<ecbrown>i am sending you thoughts and prayers to get strongswan up
<dstolfa>ecbrown: thanks :D
<dstolfa>1 function dealing with strongswan configuration is longer than all the stuff required for wireguard combined btw
<dstolfa>so many files :(
<roelj>Does anyone have experience with packaging a Python package that uses a "toml" file instead of a setup.py?
<ecbrown>roelj: what's your question more directly?
<roelj>ecbrown: Well.. what would the "configure" or "build" phase do? I guess I need to modify the phases of the python-build-system.
<ecbrown>cool thanks, i will let that simmer and go look through python*scm for examples of doing just that
<roelj>I'm trying to update python-anndata :)
<ecbrown>i think python-black in python-xyz.scm has a complicated case of that
<ecbrown>just searching for toml in the python-* that have examples of where to shoe-horn in some changes
<roelj>Ah thanks!
<roelj>Yeah, it seems generating one's own setup.py is also possible
<roelj>I don't see where python-black interacts with the toml file though
<ecbrown>yeah, some of them are complicated but there's often a couple of gems in there that just e.g. add a define statement
<ecbrown>roelj: i'm only on my second cup of coffee lol i'm just illustrating a strategy ;-)
<ecbrown>until a python toml expert comes along ;-)
<roelj>ecbrown: I see, much appreciated :)
<roelj>It gave me pointers already
<PurpleSym>roelj: It seems to be build using flit, right? python-tinycss2 is a similar package, but ultimately we need https://issues.guix.gnu.org/46848
<roelj>PurpleSym: Indeed
<roelj>PurpleSym: Nice patch series!
<PurpleSym>Thanks, but I know my Scheme code is pretty terrible :) Also I’m sure there are alot of special cases that I missed. Hence the need for a reviewer.
<roelj>I know too little about Python to do a proper review
<PurpleSym>No problem.
<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>and here's the disassemble of the problematic module in case it may be useful: https://paste.debian.net/1199490/
<apteryx>ingor: I think there's a guile-parted module used in the installer you may find helpful, not knowing exactly what you are trying to do
<ingor>just trying to figure out why the installer doesn't boot
<apteryx>ingor: for me (scandir "/dev/disk/by-id/") works the same as ls would
<dstolfa>has anyone managed to get libvirt in guix to create a bridge and manage it?
<dstolfa>libvirt generally works for me, but i think i have to do all the bridging and NAT matually. in other distros this was all done by libvirt
<dstolfa>also... how does one even create bridges manually in guix? i can't find a way to configure it in the manual
<ecbrown>dstolfa: no. i can not get it to work in virt-manager due to bridge missing
<ecbrown>i resort to qemu
<dstolfa>hmm, so you manually create the bridge every time?
<ecbrown>yes
<dstolfa>that's a bit sad
<ecbrown>it works out practically. if a vm stops it needs to be restarted with tlc
<dstolfa>ecbrown: could you share your scripts somewhere?
<ecbrown>(unintentionally stops, this is kvm for gods sakes)
<ecbrown>i run my vm's in tmux
<dstolfa>oh, so you write out the full qemu command?
<ecbrown>just have a battery of windows that have a qemu-yada-yada command line
<ecbrown>yes
<dstolfa>hmm, maybe guix has a good qemu service one can use
<dstolfa>to specify VMs
<dstolfa>that way i can eliminate libvirt
<civodul>apteryx: woow, that's a very specific question :-)
<civodul>apteryx: do you have a wip patch for jami-service somewhere?
<apteryx>civodul: I've modified it rather heavily and it's in flux; just made a dump of what I have here: https://gitlab.com/Apteryks/guix/-/commits/add-jami-service
<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>yes, that's right
<projectmoon>Where can I follow gnome 40 progress?
*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).
<dstolfa>ecbrown: nah it's broken
<dstolfa>error: Cannot check QEMU binary /usr/bin/qemu-system-x86_64: No such file or directory
<dstolfa>i think it's gonna be qemu
<ecbrown>what would happen if you shoe-horned in that extra special file service
<ecbrown>sorry working from memory. the service that lets you make /usr/bin/env
<dstolfa>you mean special file thingy?
<ecbrown>but on for that binary to whatever the guix one is
<ecbrown>sorry, that /usr/bin/qemu-sys... to the guix one
<dstolfa>i can check later, i just made a quick runqemu.sh :P
<dstolfa>i need a VM now (sadly)
<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
<ecbrown>good idea
<ecbrown>say i would be curious if you can solve your bug with that extra special file
<ecbrown>i have virt-manager but i can't create your same context that gives that error
<ecbrown>e.g. that underlying machinery of virt-manager in fact may work with a little duct tape
<dstolfa>i'll let you know, need to access a windows machine real quick first :D
<ecbrown>cool cheers
<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?
<dstolfa>in case someone feels brave
<civodul>apteryx: i think https://gitlab.com/Apteryks/guix/-/commit/5ebbd8aff972de2fe57c7f623926edd7c42a0a0f is fine; it should have no effect, nowadays
<ecbrown>dstolfa: definitely yes!!! i'll file a bug report for what i see in virt-manager
<lastebil>- the error happens to prevent installation from working, so... I can't get it from an installed system either (:
<apteryx>civodul: OK! It does print a lot of warnings, but perhaps that's inevitable.
<civodul>yes
<civodul>apteryx: as for mkstemp, it should be 'mkstemp!' instead
<civodul>but yeah, the "failed to autoload (shepherd service)" warnings are expected and fine
<apteryx>oh! How does mkstemp! differ from mkstemp? It doesn't seem to be documented.
<civodul>in (gnu build shepherd) and the new (gnu build jami-service), the goal is to have a "soft" dependency on the Shepherd
<apteryx>right
<civodul>'mkstemp' doesn't exist, does it?
<civodul>hmm it does
<civodul>wait
<civodul>oh yes, mkstemp (no bang) is new in 3.0.6
<civodul>so for now we'll stick to good'ol 'mkstemp!'
<apteryx>haha! So I'm running an older Guile in the VM
<civodul>yes, 3.0.2 on master
<civodul>(shepherd runs on 3.0.2)
<ecbrown>dstolfa: i need to download a trisquel iso in order to make my case ;-)
<apteryx>phew! Thanks a lot for checking :-). Perhaps I'll still have a few hairs when I'm done.
<civodul>it's a big chunk of code that you have for Jami!
<apteryx>indeed! It used to be self-contained in the service definition but it was growing out of hand.
<lastebil>so is anyone familiar enough with the installer to know if there is a location of the error file?
<lastebil>or can someone suggest an alternate method of starting the install so that I can attempt to get the output and then mail it?
<ecbrown>lastebil: you can try the command line install
<ecbrown>i've observed some cranky gui crashes where i just went through the steps -- very educational too except its a pain without some clipboard -- so you can ssh in and copy and paste things
<lastebil>ok, I'll try that and see if I can't get this error report in.
<ecbrown>you will also have access to a log file, and some tools to try to copy that out
<ecbrown>when you do command line install
<ecbrown>or maybe you can use virual console to switch in? is it still alive?
<ecbrown>ctrl-alt-F3 or something
<lastebil>it's still alive, let's see...
<lastebil>there is a last-installer-error in /tmp, and that is indeed the error. this will work.
<ecbrown>sweet!
<zap>how to distinguish between gpl2 and gpl2+?
<Noisytoot>zap, check the license header
<zap>Noisytoot: so its explicitly says gpl2 only in case of "gpl2"?
<dstolfa>zap: pretty much
<dstolfa>GPLv2 and later vs GPLv2 only
<dstolfa>if there's no clause, i would assume GPLv2 only
<Noisytoot>I think or later is the default
<dstolfa>Noisytoot: surely it includes the text explicitly though?
<dstolfa>it would be very weird if the meaning of GPLv2 without any follow-up text changed
<dstolfa>and probably wouldn't work very well
<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."
<Noisytoot> https://www.gnu.org/licenses/gpl-3.0.en.html, section 14
<dstolfa>right, so it's explicit
<pkill9>webengine is taking a long time to build heh
<Noisytoot>It's the same in the GPLv2 (section 9)
<Noisytoot> https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
<zap>Thanks! found it :)
*zap goig afk for an hour
<noisytoot[x]>/whois Noisytoot
<Noisytoot>that was meant to be sent as a command
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<pocimaci>change to server secusys.eu
<jess>hi pocimaci
<roptat>hi guix!
<pkill9>so far i have spent almost 2 USD compiling qtwebengine
<dstolfa>roptat: hi!
***tissevert1 is now known as tissevert
<solene>sbcl update!
<TheAsdfMan>Hello, I made a local channel for my package variants, can i do a guix pull only for it?
<roptat>TheAsdfMan, you can use a channels.scm (in .config/guix/channels.scm) to pin specific versions of your channels
<roptat>you'd pin the guix channel and not yours, then run guix pull
<roptat>be aware that you'll need to revert that if you want to update the guix channel later
<TheAsdfMan>roptat: thanks!
<TheAsdfMan>roptat: Do i pin it with the channel introduction and keys, So it doesn't mess the guix's Channel Authentication?
<roptat>yes
<roptat>you can generate a first channels.scm with guix describe I think
<roptat>TheAsdfMan, "guix describe -f channels"
<TheAsdfMan>roptat: thanks again!
<zap>pkill9: haha
<Noisytoot>I've just packaged udftools!
<Noisytoot>I'll submit it later
<Noisytoot>It puts some stuff in an "sbin" directory, what should I do with that?
<pkill9>i'm building on an 8 core 2.3 ghz intel CPU with 32GB of RAM
<civodul>stumbled upon this: https://stackoverflow.com/questions/67744653/better-reproductibility-of-rpackages-pin-version-of-packages-in-nix-in-compari
<civodul>it calls for "guix describe" and "guix time-machine" or similar
<bricewge>It seems that the system-checks loadable-kernel-modules-service-[0-2] were never build (I can't find them in Cuirass)
<bricewge>And loadable-kernel-modules-service-[12] are failling
<bricewge>How can I debug them? There is no documentation about it
<ix>Noisytoot: symlink to /bin?
***ss2` is now known as ss2
<bricewge>I managed to find the loadable-kernel-modules-service-[0-2] check https://ci.guix.gnu.org/build/512174/details
<bricewge>Indeed, the never succeed. linux-loadable-module-service-type which is tested here never load a module, so it couldn't succed since the test what the module to be loaded.
<bricewge>Theses should be disabled or fixed by testing if the module is present (and not necessarily loaded) in the profile
<TheAsdfMan>Hello, i have a package definition and it uses git-fetch in a local git repo in my home directory, but when building the package it says the repo doesn't look like a git repo
<roptat>I think that's because it needs a bare repository to clone from
<TheAsdfMan>roptat: i made it a bare repo, but it still gives the same error
<TheAsdfMan>Does the git-fetch process happen as one of the guixbuild users?
<roptat>possibly
<roptat>I'm not sure
<TheAsdfMan>because my /home directory permissions are drwx------
<TheAsdfMan>and the repo is in it
<roptat>ah yes, it's a derivation, so the daemon delegates it to one of the guixbuild users
<TheAsdfMan>roptat: thanks
<itd>Hi. I'd like to hide a channel URI's userinfo [1] in the output of `guix pull` (when using git over http). Is that possible? Thanks! [1]: https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.1
<roptat>I don't think so, it will just print the whole URI
<roptat>you'll probably need to patch guix to do that. If you manage to find out where and what you need to do, you're welcome to submit a patch :)
<itd>Okay, thanks. :)
<roptat>sorry I couldn't help more than that ^^'
<itd>No worries. Thanks for your time! :)
<lfam>pkill9: Indeed, it's a very expensive package to build
<ecbrown>earlier someone had mentioned a gnutls build problem on master. i see it too, i think it's i586-pc (hurd)
<ecbrown>solene: can you see if your gnutls patch recently submitted causes build issue with i586-pc ?
<ecbrown>(i don't know how, exactly lol)
<ecbrown>i think i see it because i run childhurd
<dstolfa>drakonis: ^
<dstolfa>i think you had issues with gnutls too?
<drakonis>aye
<drakonis>i see
<drakonis>sounds like its childhurd at play
<drakonis>i do have it enabled because i wanted to fiddle with hurd
<ecbrown>i suppose linux will now have to be degraded lol
<lfam>Are there problems with GnuTLS on linux? Or just Hurd?
<ecbrown>just hurd, i think
<lfam>Okay
<ecbrown>i have childhurd on all my machines so i thought it was a problem everywhere. until i just installed a new desktop today and saw it went to master just fine
<ecbrown>but crapped out when i added my additional services
<lfam>I only test on Linux, to be honest
<lfam>(I tested and pushed that commit)
<lfam>Is there a bug report for this issue?
<ecbrown>not yet
<lfam>That is the first step to fixing it :)
<ecbrown>i can make one if you want, i think i would just do --target=i586-pc
<ecbrown>or send the log of the crash of course
<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
<lfam>Yeah
<sarg>is there a command to rollback just one package? or maybe to install it given the path in /gnu/store?
<ecbrown>sarg: i highly recommend inferiors
<ecbrown>there is an example in the manual that is short and sweet, i use it to roll back tigervnc-server to 1.10.1 instead of 1.11
<ecbrown>(by commit hash)
<sarg>yeah, but in my case the package was installed with `guix package -f`, so technically it's not versioned properly
<lfam>You can do `guix install /gnu/store/...`
<lfam>But, I also recommend inferiors
***lispmacs[work] is now known as forthmacs[work]
***forthmacs[work] is now known as lispmacs[work]
<pkill9>sarg: how long did it take you to build qtwebengone, and on what specs?
<sarg>pkill9: somewhat 4 hours on thinkpad t420 (i5,16gb)
<yarrak>Can someone tell me why I am unable to open executable files? :(( Tor Browser, monero-gui etc.
<sarg>yarrak: you mean just random binaries downloaded from the internet?
<yarrak>yes
<ecbrown>there's no /usr /usr/lib filestructure that static programs expect to find
<sarg>they're linked dynamically so you need to provide proper libs
<ecbrown>(i mean dynamic)
<sarg>you could try with LD_PRELOAD=~/.guix-profile/lib ./some-program
<yarrak>Thank you both, i will try. :)
<sarg>yarrak: https://gitlab.com/pkill-9/guix-packages-free/-/tree/master#how-to-use-fhs-binaries-compatibility-service-in-your-guix-configuration
<sarg>for LD_PRELOAD to work you also need /lib/ld-linux. pkill9 has got around it with his fhs
<pkill9>sarg: damn, it's taking longer than 4 hours on this 2.3GHZ 8 core 32 GB RAM VPS, it's using all the cores
<jeko>Hello Guix ! I finally setup Polari to connect to Libera.Chat haha
<lfam>I'm surprised you could build qtwebengine in 4 hours on an old thinkpad
<pkill9>same
<pkill9>maybe it's cursed
<lfam>I would estimate at least 12 hours, and maybe even a day
<lfam>It takes about 50 minutes on the build farm, which uses 4 recent and real cores. Not cores optimized for low power
<pkill9>nice
<lfam>I guess that Qtwebengine is quite a bit smaller than Chromium, which takes about 3.5 hours
<lfam>I figured they would be roughly the same. Maybe an old Thinkpad really can do it in 4
<pkill9>maybe it's overclocked with nitrous cooling
<ss2>I'm surprised it didn't melt!
<lfam>Thinkpads are well designed. They don't overheat in my experience
<lfam>Even with overclocking, mobile cores just don't do as much per cycle as the types of cores used in our build farm
<dstolfa>thinkpads are great, i don't understand why modern laptops don't base their design on them, especially the keyboard
<nckx>Always happy when I log in without context & read something that is true.
<sneek>nckx, you have 1 message!
<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?
<nckx>Good morning Guix.
<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
<dstolfa>i've exported it and all.
<pkill9>see mnt reform
<nckx>Sorry to ask the obvious, but did you add everything to the vpn module's #:export list?
<dstolfa>from what i can see, yes
<dstolfa>which is why i'm confused
<nckx>Your problem doesn't sound familiar to me.
<dstolfa>but it's good to know that this is *supposed* to work
<dstolfa>because that means it's something with my environment/code/config
<nckx>Could you share your Guix git diff + the strongswan-service snippet I can add to my system.scm?
<dstolfa>yep
<lfam>Make sure you have the Guix development dependencies available when using pre-inst-env
<lfam>`guix environment guix -- ./pre-inst-env ...`
<dstolfa>lfam: yeah, i'm doing this inside `guix enviornment --pure guix
<nckx>dstolfa: It *should* work, yes, unless we're both missing something obvious. And as lfam implies: that your ‘building Guix from git’ set-up is entirely sane.
<nckx>I've been using Guix System like this for years. ~20 packages rebased on top of master.
<lfam>I wouldn't use --pure for this
<nckx>(‘Which I should really upstream any day now some day.’)
<lfam>Anyways, if it doesn't work with pre-inst-env, and the development setup is correct, then something is wrong with your code
<dstolfa>ah, let me try without --pure
<lfam>But, pre-inst-env is finicky and not very Guixy
<nckx>I wouldn't either but I'd be intrigued if *that's* what fixes a ‘did you forget to add?’ error.
<lfam>So, you just have to be a Guix expert to test these things
<dstolfa>let me try to re-checkout and rebuild everything just to see if i broke something by accident
<dstolfa>since now it's complaining it can't connect to the daemon...
<lfam>Yeah, when things get weird I always reconfigure
<lfam>That probably means you misconfigured the build
<lfam>Make sure to do `./configure --localstatedir=/var`, unless you have a reason not to
<nckx>Ma— ☝
<lfam>And, you'll know if you have a reason not to
<dstolfa>now it's working, yeah
<lfam>Nice
<dstolfa>i think i might have ran configure without it by accident somewhere between me writing the service and running it now
<lfam>The primary failure mode of pre-inst-env iis when you garbage collect the development dependencies and don't rebuild the checkout
<dstolfa>hmm, good to know :)
<dstolfa>that will save me time
<dstolfa>btw: the way strongswan service works right now is that it basically does what lfam suggested, but with every single configuration file
<dstolfa>we regenerate the entire strongswan config every time the service starts
<dstolfa>this is around 92 files
<nckx>That might be OK.
<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
<lfam>Confusing and wrong
<nckx>By which I mean: it's not obviously wrong, so keep working on that MVP version you have that actually works.
<dstolfa>lfam: ah okay, thanks for clarifying it
<nckx>Optimise later, if at all.
<dstolfa>nckx: yeah, for now i'm just doing the legacy interface with ipsec.conf and ipsec.secrets
<dstolfa>when that works, i will actually write a swanctl config interface
<dstolfa>but i think it might make sense to do this in a three patch series (build options, ipsec, swanctl)
*lfam tries building a kernel using Guix but with configuration from a Debian system
*nckx has *finally* managed to get a full-sceen Guix boot splash after… patching the kernel in a few places, so that's not great, but it looks pretty.
<nckx>Considering how long Guix takes to boot.
<lfam>The Debian configuration seems to require some extra dependencies (e.g. zlib)
<lfam>It would be great to have a splash screen
<nckx>Yeah, my kernel does to.
<nckx>*o
<lfam>It requires extra dependencies nckx?
<nckx>I'm might be slightly drunk but that doesn't mean spelling doesn't matter
<lfam>It would be nice to have a list...
<lfam>Better than waiting 10 minutes for the build to fail, for each dep
<lfam>I think I'm on a wild goose chase building this kernel like this, but the macchiatobin experts think my problems are related to the kernel config
<lfam>And I'm out of ideas
<dstolfa>oh shoot, i pulled at an awkward moment so now i'm compiling a bunch of stuff
<nckx>lfam: Just a few compressors (zlib, cpio, xz, lz4, zstd) that I'm sure depend entirely on my personal configuration, and elfutils for CONFIG_STACK_VALIDATION (so, same).
<lfam>Alright
<nckx>I never checked which options, sorry. It's a kernel config I've ported over ~20 years & 4 distros.
<lfam>Gah, it needs /usr/bin/env
<dstolfa>which 4 distros? :)
<lfam>I'm starting to feel like the macchiatobin isn't worth it
<lfam>It's only 4 cores
<lfam>I'm spending all my time on this
<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
<lfam>I really don't know
<lfam>It doesn't have stable MAC addresses which is pretty annoying
<lfam>I'll have to add support for specifiying MAC addresses to static-networking-service-type
<Noclip[m]>Mhh, interesting term. Didn't know the word "borging" before.
<nckx>What's weird to me is that the first one worked. —or, your router simply still remembered it from the last successful Debian connection.
<nckx>(Actually my guess.)
<lfam>The MAC address thing is a separate problem
<lfam>I can work around that
<nckx>OK.
<lfam>The problem is the NIC can't be brought up. It always reports NO-CARRIER in `ip link sho`
<lfam>w
<lfam>It works in Debian and in the UEFI shell
<lfam>Why would /usr/bin/env be required when building a Guix kernel? It's really surprising
<lfam>Sigh
<lfam>It's also tough to do all this on the console
<nckx><NO-CARRIER> WTF. That's very low-level.
<lfam>Yeah
<lfam>Some driver or something isn't being loaded
<dstolfa>um, how does one view build logs? :)
<lfam>Add --log-file to the command and read the file
<dstolfa>aah okay
<lfam>Guix will give you name of the file when the build fails, too
<lfam>I had already tested with linux-libre, nckx, to make sure the drivers are free. But it also fails when I tried with upstream Linux
<lfam>It's mysterious
<lfam>I get the sense that there is nobody on earth who knows what's wrong :(
<dstolfa>lfam: hm, this happens during a guix system reconfigure, probably because i'm running it as root in a guix environment guix?
<dstolfa>it's complaining it failed to build strongswan (which i can build manually) during a system reconfigure
<lfam>What happens?
<lfam>Well, something is different
<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
<nckx>* in my kernel.
<nckx>Crucial info right there.
<lfam>itd: Yeah
<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`
<dstolfa>lfam: thanks, i'll check it out
<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>Lol who knows nckx
<lfam>Backwards compatibility
<nckx>Backwards all right.
<ss2>does anyone know how to get around with libvirt and redirecting usb devices?
<dstolfa>hm, is there an output log of shepherd somewhere? everything seems to "start" but strongswan's not running :)
<lfam>Package: https://paste.debian.net/1199536/
<lfam>Failure:
<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
<lfam>I don't see how this is possible
<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 [1] not sure if there's some inspiration there [1]: https://github.com/bgamari/mcbin.nix )
<lfam>Debian is working itd. That's where I am doing my work
<lfam>That will be helpful, thanks
<dstolfa>hum, i'm obviously misunderstanding how to create a directory with compute-file. i thought it was just (mkdir #$output)?
<dstolfa>computed-file rather
<lfam>Is there a nice way to diff kernel configs?
<apteryx>you could diff the defconfigs
<apteryx>which should be much smaller but not exhaustive (it'd show only the options deviating from the defaults)
<lfam>How do I convert the config into a defconfig?
<apteryx>'make defconfig' IIRC
<apteryx>or make savedefconfig
<lfam>Okay
<apteryx>unless that's a buildrootism
<apteryx>but I think it comes from the kernel
<Noisytoot>ix, Some other packages install thing only into sbin without a symlink (like alsactl), so I think just having it in sbin is fine
<apteryx>lfam: by the way, it was discussed we could have a defconfig saved along our .config in the repo for our linux-libre config
<lfam>What would that do apteryx?
<thecatster>Just trying to know out of curiousity, why is Firefox not in the official repositories, is it not OSS? Not looking to know how to install it.