IRC channel logs


back to list of logs

<chipb>nckx: ah. that makes sense.
<nckx>‘defaults’ expanded to ‘rw, suid, dev, exec, auto, nouser, and async’, chipb.
<emad-guix>I'm experiencing an error whith "guix refresh" and the details are here
<nckx>I'm worse at typing than usual.
<vagrantc>defaults is kind of like a grab-bag alias of "real" options
<lfam>I got confused because some other things from fstab are accepted by Guix's mount machinery
<lfam>Namely, compress-force=zstd
<nckx>emad-guix: I can reproduce it with ‘guix refresh bazaar’, not sure what it means yet.
<chipb>I'm aware of that. I wasn't aware linux-utils' mount /etc/fstab never gets involved even after initrd time.
<vagrantc>bazaar ... wow, that's almost as old as arch!
*chipb goes back to lurking.
<emad-guix>nckx hehe me too but Iam not sure why this is happining
<vagrantc>i keep thinking i should try btrfs ... and then i keep finding some reason not to (memory constraints, maybe?)
<vagrantc>i did try f2fs with guix ... but i was not impressed ... but maybe it requires a lot of manual tweaking to make it not terribly slow
<vagrantc>i had never thought of running "guix refresh" without arguments
<nckx>chipb: I get it, it feels weird and NIH'y, but the actual Guile code is tiny, clean, fast, and was actually an excellent thing to I H. That's... not always the case, I agree.
*vagrantc adds to wishlist a guile implementations for udev and modprobe for the initrd
<lfam>Whatever problems btrfs has, the new features are worth it to me. Like, easy online resizing, compression, free copies
<vagrantc>lfam: yeah, those sounds appealing
<lfam>Not to mention the checksumming
*vagrantc still remembers ext3 as the fancy new thing
<chipb>nckx: no worries. I was opening my mouth without any experience with guixsd or its boot stages myself. I do find it mildly amusing that 'mount' is ridiculous overhead in initrd, but a guile environment obviously is not. :-P
<nckx>vagrantc: What part of modprobe? (We already load modules ourselves, but it's rather forceful ATM. (for-each load initrd-modules), basically, no way to have them loaded on-demand by the kernel AFAIK.)
<lfam>And now ext4 doesn't have enough inodes! Time flies
<vagrantc>i never thought i'd see the day: ... nobody ever update linux-libre ever again, or any of it's dependencies!
<nckx>I think there are patches to do something like that too.
<vagrantc>nckx: yes, it's the forceful, manual bits i'm not fond of
<vagrantc>i even maybe filed a bug about this
<nckx>It shouldn't be hard to write a tiny insmod that the kernel can call when it detects a thing.
<nckx>Maybe that's even the patch I'm half-remembering :)
<nckx>vagrantc: Nice.
<nckx>I updated a hash that started with "lisp1" once and was sad.
<nckx>Oh, udev in the initrd.
<nckx>But yeah that's what I was thinking of, didn't realise it was your own work.
<pkill9>nckx: that's the real NFT right there
<vagrantc>nckx: i merely reported the issue, i didn't actually come up with any code :)
<nckx>;; XXX TODO
<lfam>Anything else wrong with my config.scm?
<Rooks>Is nonguix/nongnu ok to exist does it violate anything?
<Rooks>Just want to be sure
<nckx>It's not promoted here but it's perfectly fine.
<nckx>I'm sure it is, but omitting %base-initrd-modules or so is deliberate right? Seems like the kind of thing that would break boot even if it avoids some other error.
<nckx>lfam: ☝
<lfam>nckx: When combined with the "generic" kernel, it's supposed to make things just work
<nckx>It would on x86_64 machines anyway.
<lfam>Our default initrd-modules don't work on ARM
<Rooks>I see. Thanks
<lfam>And it's not clear what the correct set is
<nckx>Yeah, probably a lot more machine-specific than commodity x86.
<lfam>I think so
<nckx>That's the only thing that really jumped out... hm.
<vagrantc>if initrd-modules was smart enough to handle "include this functionality, which might be a module or might be a builtin, but only fail if you have neither ..." that would be helpful, too
<nckx>lfam: How far do you boot?
<lfam>nckx: The most recent attempt, it failed after GRUB due to that thing about "defaults"
<lfam>That's pretty good, compared to earlier attempts
<nckx>You haven't tried booting without the bogus ‘defaults’ option? That's hopeful.
<lfam>That's my next and hopefully final change
*vagrantc learns about the existence of openssh-sans-x
<nckx>Yeah, it's beyond the dreaded black screen/reboots without printing anything stage.
<nckx>Speaking of which
*nckx reboots.
<vagrantc>apparently, i've been using openssh-sans-x all this time
<iskarian>when patching out a baked-in path, is best practices to use "" or a bogus path like "/homeless-shelter"?
<vagrantc>lfam: given that this has apparently fallen flat: ... i guess i should just apply the patch to linux-libre-source@5.12 ?
<lfam>Yeah, go for it
<nckx>iskarian: I'd say bogus but it depends. Whichever makes it do the safest thing (which can be ‘not fail’ or ‘fail hard’ or anything inbetween) is bestest practice.
<nckx>"" is a weird path, and I'd wonder what it makes the programme do.
<vagrantc>iskarian: if you go bogus path route, maybe something potentially less poor taste like "/nonexistent"
<iskarian>that's what I thought; it feels weird to just be putting in a path like that
<Noisytoot>In the installer, if I enter the wrong WiFi password, it will also say that all future attempts to connect (unless I reboot, of course), have a wrong password
<lfam>It's been done for other packages
<iskarian>vagrantc: that's a better idea for sure
<vagrantc>and if someone creates "/nonexistent" all you can say is they did it to themselves :)
<nckx>iskarian: Is it meant not to exist inside the build environment, or never? /var/empty/nonexistent is ‘safer’ in the latter case, although it could always exist.
<nckx>I've used /proc/bogus before... if that exists, the user has clearly locked their warranty papers inside & set fire to the house.
<iskarian>nckx, never; it's a default tool path in a library, but the tool path should be set by environment variable for anything using said library
<iskarian>specifically, in gccgo; otherwise, the "lib" output has to be merged into "out" and "out" becomes >300MB
<nckx>Is it a path or a file name?
<iskarian>it's a path
<nckx>Path as in search path, file name as in /etc.
<nckx>I'd expect an empty path to be treated as an empty list, ‘don't search’.
<nckx>Like PATH=.
<nckx>* PATH=
<iskarian>Ah, I see what you're getting at...
<nckx>Confusing grammar habits.
<iskarian>The corresponding environment variables are GOROOT and GCCGOTOOLDIR, which are expected to be a single path rather than a list. So e.g. /nonexistent definitely seems safer.
<Noisytoot>Why not /proc/bogus?
<lfam>'nonexistent' is something of a standard bogus path for Guix
<lfam>It's the home of the nobody user
<iskarian>Huh. Good to know. I could have sworn I've seen the build environment use /homeless-shelter (which is why I suggested it earlier)
<nckx>It does.
<lfam>That one too
<lfam>Guix has two standard bogus paths
<nckx>For clarity.
<Noisytoot>Why does the installer install xf86-video-nouveau-1.0.17, when I don't have an Nvidia GPU
<lfam>The mcbin is generating the SSH host keys 🙏
<lfam>Give thanks
<lfam>Thanks for your help everybody, especially vagrantc!
<vagrantc>lfam: see what 1970 has to offer you ... or if you're lucky, a look into the present!
<vagrantc>e.g. check your clock before doing much :)
<lfam>It has a clock with battery ;)
<vagrantc>some people don't know what they have
<lfam>Alright, I'll finish it later or tomorrow
<nckx>Noisytoot: The installer doesn't hyper-tailor the installation to the hardware that happened to be around during installation.
<vagrantc>clearly, lfam knew we could drag it out a few more hours through IRC.
<nckx>Noisytoot: You could always change your mind or GPU.
<nckx>It's not like a desktop environment which is for life.
<vagrantc>i totally forgot i submitted 48371 and have a question waiting for me there
<Noisytoot>I have a laptop with no place to put an external GPU
<vagrantc>a realistic level of ambition :)
<nckx>I don't think making installations hyper-machine-specific like Windows out of the box is a feature. I expect to be able to install GNU/Linux, then move the hard drive amongst machines. Anything else is confusing (BIOS vs. UEFI being an unfortunate exception).
<nckx>Good night Guix o/
<Noisytoot>BIOS vs UEFI vs libreboot/coreboot GRUB
<GNUtoo>Noisytoot: for ARM supporting all the configuratins out there is probably complex though
<GNUtoo>For instance you often can put the bootloader in a lot of places, like on a microSD, on an internal storage device (eMMC), etc, and add to that that there are multiple way to install the bootloader on each of theses cases: for instance install at different possibles offsets from the start of the device, or in a partition
<GNUtoo>Though it would be a good idea to have 1 configuration well supported in a flexible way (like an offset on a block device)
<GNUtoo>Ah /me messed up nicknames again by not reading thestart of the conversation
<ulfvonbelow>has anyone managed to get pulseaudio working within a container as spawned by guix environment --container?
<Noisytoot>I've installed Guix System!
<dstolfa>Noisytoot: \o/
<dstolfa>Noisytoot: did you figure out swap + btrfs?
<raghavgururajan>lfam: I tried --keep-failed and found out that wasn't available in the expected location, that is under /src in build-dir.
<raghavgururajan>But I don't know why.
<Noisytoot>dstolfa: Not yet, I've just booted
<dstolfa>Noisytoot: just follow the typical btrfs guide, and then after you've created the swap file, follow the guix guide for swapfile (it's in the info page) and reconfigure
<dstolfa>it just works(TM)
<dstolfa>that's how i did it for my btrfs-based guix
<raghavgururajan>sneek, later tell lfam: I am experiencing system freezes during I/O operations, with linux-libre 5.12.x but not with 5.10.x. Just letting you know as this could be a bug.
<vagrantc>where is nix-system->gnu-triplet defined?
<vagrantc>seems to be guix/utils.scm ... but i have #:use-module (guix utils) ....
<vagrantc>ERROR: In procedure %resolve-variable:
<vagrantc>Unbound variable: nix-system->gnu-triplet
***TheCreeper1 is now known as TheCreeper
<iskarian>vagrantc, do you perhaps have it unquoted when it should be quoted?
<vagrantc>i found an easier approach
***ashkitten is now known as ashkitten-irc
<apteryx_>rekado: OK, good to know! I think it boils down to using the subdirectory returned via elpa-dir or similar instead of directly site-lisp/, as you probably found out
***apteryx_ is now known as apteryx
<vagrantc>what commands do you use to enter suspend on guix?
<vagrantc>there's probably some /proc of /sys values you can hit
<vagrantc>well, i guess hitting the "sleep" key seems to have worked
<chipb>vagrantc: oh, somebody just asked that a little bit ago.
<chipb>pkill9 │ solene: loginctl suspend
<vagrantc>ah, right, the elogind equivalent of systemctl suspend
<chipb>er. I guess copy/paste wasn't the best idea. sorry for pinging folks unnecessarily.
<vagrantc>no worries :)
<vagrantc>oh no, i broke u-boot installation with a65c935e29766940148d52b8116634b1e1cbcba6 on some platforms
<vats>Hello, selecting outputs using ":" syntax works for specification->manifest like (specification->manifest '("git:send-email")) but not for packages->manifest like (packages->manifest (map specification->package '("git:send-email"))). In the latter case I get the error "git:send-email: unknown package".
***Kimapr2 is now known as Kimapr
<maddo>can anyone who has 2 minutes test something?
<maddo>can't get vapoursynth from guix (on a foreign distro) to work
<mange>Yeah, I've got some time. I'm running Guix on a Ubuntu foreign distribution. What do you need tested?
<maddo>mange: guix install vapoursynth
<maddo>and then vspipe -v
<maddo>it tells me failed to initialize vapoursynth
<mange>I used an ad-hoc environment rather than installing it, but I'm getting the same message.
<maddo>then the package is broken I guess
<maddo>will open a bugreport
<mange>If I install python3 in the same profile I think it works.
<mange>Running this gives me version information $ guix environment --ad-hoc python vapoursynth -- vspipe -v
<maddo>it's still broken however, since it should be installed with vapoursynth on a foreign distro
<maddo>missing dep
<mange>Mmm. It is a build-time dependency, but it's not propagated. I guess we either need to move python to propagated inputs (not ideal), or add python as a regular input and wrap the vspipe program to set the right environment.
<nckx>Morning, Guix.
<nckx>mange: ‘is a build-time dependency, but it's not propagated’ sounds... correct? Build-time dependencies shouldn't be.
<sarg>pkill9: hey, found that you were working on enabling h264 in qutebrowser. Just wonder if you got any further than explained in
<mange>nckx: Yeah, but it looks like it's needed at run time, so it's incorrect to have it in native-inputs. :)
<nckx>Oh... typo? Got it now.
<HiddenKarma>Quick question, is an open source client to a proprietary MMORPG legal under the FSDG?
<HiddenKarma>I'm talking about RuneLite
<nckx>I think so, HiddenKarma. As long as everything that runs on the user's computer is Free software.
<HiddenKarma>OK, thanks
<nckx>maddo, mange: I couldn't find a reason to propagate python, but the error you describe is fixed on master. I also tried a very basic script, but please let me know if it also fixes real-world usage in a pure environment without Python.
<mange>nckx: Did you try running "vspipe -v" in an environment with only vapoursynth? When I did, it says it can't initialize.
<mange>That is, "guix environment --ad-hoc vapoursynth -- vspipe -v" doesn't work, "guix environment --ad-hoc python vapoursynth -- vspipe -v" works.
<mange>Ah, I see you also pushed the PYTHONPATH wrapper. Sorry, I missed that commit, so I thought you'd only moved in the input. That should fix it.
<Rohit>Can I request a package a here!
<Rohit>I want the micro editor to be available in guix repo
***fredmanglis_ is now known as fredmanglis
<pkill9>sarg: ah no i didn't
<pkill9>i forgot about that
***stikonas_ is now known as stikonas
<pkill9>basically need it to use the system's h264
<pkill9>instead of trying to build bundled one
<drgibbon[m]>Hello, just testing out Guix, how do I manage packages that were installed through the installer? e.g., `guix package --list-installed` only shows stuff that I installed afterwards. But what about if I want to remove a desktop that was selected during install, say `mate-desktop`?
<ecbrown>drgibbon[m]: if you remove reference to it and `guix system reconfigure /etc/config.scm' those packages will be removed from visibility
<ecbrown>i believe there is a `gc' that would have to be done to remove it from the guix store
<ecbrown>"remove reference to it" means e.g. comment it out in /etc/config.scm
<nckx>If you really need to free the bits, you'll have do delete old system generations (that do still refer to the desktop) with ‘guix system delete-generations […]’ before GC'ing.
<pkill9>drgibbon[m]: that's in your configuration.scm file
<dstolfa>a bit of an update on strongswan: i think the most sensible thing to do is to just write a service that writes out the full configuration for either ipsec.conf or swanctl.conf. it might take some doing but i'll work on it in free time
<nckx>dstolfa: Oh... right :) I agree with that assessment.
<dstolfa>nckx: i guess this would go in networking.scm rather than vpn.scm since strongswan is already there?
<dstolfa>just to make sure :)
<drgibbon[m]>pkill9: I see, so removing it from config.scm and doing `sudo guix system reconfigure /etc/config.scm` would uninstall it?
<nckx>It's more important that there's a well-de{fin,sign}ed way to configure Strongswan. If it uses global files in /etc behind the scenes, that can always be improved later without changing the user interface.
<drgibbon[m]>Or would it go after a garbage collection instead?
<dstolfa>yeah, i agree nckx
<pkill9>yea drgibbon[m]
<dstolfa>i've tried a bunch of things and that is the most sensible way to go about it imo
<dstolfa>i'll also aim to break this up into different patches that address different usability parts of strongswan (first one being autoconf options)
<nckx>dstolfa: I'd still go for (gnu services vpn)… Packages aren't always in the right place (see the dustbin of history that is admin.scm).
<dstolfa>ah okay, i guess i'll move it then :)
<dstolfa>(the service bit, not the package)
<pkill9>maybe the %base-x vars should be removed, just have everything shown in the config
<pkill9>who cares if it's verbose
<sarg>pkill9: yeah, i'm trying to make a fix for that. For that I need to add somehow `gn_args += use_system_openh264=true` to `src/buildtools/config/linux.pri`
<pkill9>sarg: that could be submitted as a patch upstream, and for now use a snippet
<pkill9>so does adding that line make it work?
<sarg>I hope so. Struggling with guix currently
<pkill9>i would run ./configure manually to see if it works
<pkill9>unpack the qtwebengine source into a directory, run `guix environment qtwebengine --ad-hoc openh264`, then add the line and run ./configure
<drgibbon[m]>Cool system so far, enjoying this run through with Guix. If I can learn how to package some missing stuff I might switch one of my machines over :)
<drgibbon[m]>btw, if I wanted say a custom build of ffmpeg, would it be hard to make local changes that persist across `guix pull` commands?
<pkill9>you can get the source with `guix build -S qtwebengine`
<ecbrown>drgibbon[m]: you have at least two choices: create a new package `my-ffmpeg' that shamelessly copies ffmpeg as a template. another is to modify ffmpeg, as if you were a developer. either of these you could publish to a git repo/branch, and then use channels. even another is to set up a web server and just push a modified version of your own ffmpeg.tar.gz. (it goes on and on. :-)
<pkill9>drgibbon[m]: you could use the environment variable GUIX_PACKAGE_PATH to add your own packages that you can easily update
<pkill9>or like ecbrown said use channels, though you have to commit that to git and then `guix pull` everytime
<pkill9>but if you just want to modify the source, you could use package transformations on the commandline, and they will persist across guix-pulls in the profile they were installed to
<pkill9>although then again that wouldn't be very helpful because you'd still need to update the source
<ecbrown>you can "inherit" packages and then just specify the bit withe.g. compiler flag that you need, which makes a little touching up quite easy. the downside that i find, is that sometimes recipes involve modifying inherited quantities, and i find substituting inside existing lists to require extra talents
<pkill9>actually no, you can modify it to use a different source URL which could point to a git repository i think
<pkill9>i think this usecase could be improved a bit so it's less clunky
<ecbrown>(i don't even know what i'm saying. it's not hard but sometimes a head scratcher when you're trying to relearn how to ride a bicycle ;-)
<dstolfa>nckx: before i hack on this too much, my current plan is as follows: provide a direct way to configure ipsec.conf and swanctl.conf for those that wish to explicitly specify what it should look like (this would equate to two rather large record types that we know how to produce a config out of), and then a more generic record type that can generate the two record types adequately for more... user-friendly
<dstolfa>does that sound like a good idea?
<dstolfa>obviously the user-friendly type wouldn't have fine-grained options specific to ipsec.conf or swanctl.conf, but it should be sufficient for *most* usecases
<nckx>From that description, I think I'd rather see a helper procedure than 2 different sets of record types. A (strongswan-configuration ...) constructor and a (simple-strongswan-configuration ...) both returning the same ‘full’ configuration for the service to consume.
<nckx>Just thinking out loud whilst eating pancakes.
<nckx>Hi ghost.
<dstolfa>nckx: i've thought of using something like that, but the problem i bumped into is that strongswan has 2 separate configuration interfaces for the same thing... sigh
<dstolfa>so the way i've gone about it right now is to have (strongswan-ipsec-configuration ...) (strongswan-swanctl-configuration) and (strongswan-configuration)
<nckx>Really the same thing? So even internally there's a significant overlap? (Aside, look at cups for a daemon that takes multiple configuration files, I mean nothing more advanced than how Guix ‘wraps’ those.)
<dstolfa>there's some "no equivalent"
<dstolfa>so it's not quite the same config, but ends up doing a similar thing
<dstolfa>both are used to configure your VPN, and ipsec.conf is deprecated, BUT... a lot of VPN services still distribute an ipsec.conf
<dstolfa>it's a really silly world out there
<dstolfa>we could have a guix interface to strongswan that isn't as powerful as the underlying strongswan interface itself and try to guess as many parameters as possible, but ultimately someone's bound to show up with "how do i do this weird thing"
<nckx>Could we just provide an ‘opaque’ ipsec.conf option where the user plugs in the file they've received from their provider, and only provide a Scheme API wrapper for the swanctl one?
<dstolfa>yes, absolutely
<dstolfa>it would make my life a lot easier as well if that was the case
<dstolfa>but i felt like that was very... ugly :)
<dstolfa>WELL, heh.
<dstolfa>ipsec.conf is absolutely horrible in the sense that it's pythonistic
<dstolfa>indentation matters
<dstolfa>so i guess we could say, give us a path to the file and we will configure it
<dstolfa>but putting the actual file into guile would have to involve a lot of spaces
<nckx>‘People want to use this file they got without digging into Strongswan’ seems to be the argument for supporting ipsec.conf at all, so maybe that's OK.
<nckx>Oh fun.
<nckx>Another reason to treat it as legacy and provide only the minimum level of support.
<dstolfa>yeah, it's really not great
<dstolfa>also, another question: what's standard guix practice to deal with secrets, such as passwords, auth keys, etc?
<dstolfa>strongswan has a second part of ipsec, which is ipsec.secrets
<dstolfa>this includes your id and auth token
<dstolfa>it would be unfortunate if people published their config files to say, a git repository, including their auth token being unaware
<dstolfa>i guess it's a user error, but could we warn about that somewhere, even if it's documentation?
<nckx>We… don't, currently, really. (grep the manual for ‘secrets’ for sundry examples.)
<nckx>Handle them I mean. Warning about that is fine.
<nckx>Several services do so, I see.
<dstolfa>ah i see, so maybe the ipsec record type should just be "ipsec.conf, ipsec.secrets" and that's about it
<dstolfa>due to indentation and so on
<dstolfa>and then properly support swanctl and have a decent interface on top of that
<nckx>I think that's acceptable dstolfa.
<nckx>Boy Strongswan is complex. IPsec stuff always seems to be.
<dstolfa>yeah... the only argument i ever see for ipsec over other things is because it's standard across different operating systems
<nckx>Read the docs over pancakes, I thought. Now I'm still reading and I'm all out of pancakes.
<dstolfa>i don't think anyone actually likes the configuration aspects
<nckx>That's my understanding to. It's a typical ‘industry standard’ that way.
<dstolfa>nckx: well, at least the pancakes were good, even if the strongswan docs are not all that fun
<nckx>They totes were tho.
<nckx>The 'cakes.
<nckx>Your plan sounds good to me, little more I can say without a little bit of code to review.
<thecatster>How do you guys handle GTK themes? I have mine applied in the config, and it applies to Emacs (when initially launching, I don't actually want it to) but not to any other GTK apps.
<thecatster>I've set GTK3 and GTK2
<dstolfa>nckx: sounds good. i'll hack on it as i get free time (i have some today) and give it test runs as i go. i currently have a workaround with docker so i can get work done on guix without needing it working right away
<sarg>pkill9: seems that the patch is working. Package is currently building, let's wait for the finish
<pkill9>idk i just tested the ./configure and it should have failed but it didn't
<pkill9>really need a better way to modify existing package definitions
<pkill9>i think i will just build the guix source and modify the package there and test it by having guix build it
<pkill9>ohhh the original failure was in the make stage so
<pkill9>ah nice
<pkill9>you know better what to do looks like
<pkill9>than me :P
<sarg>I've just checked the sources. The flag for openh264 is just missing (
<pkill9>oh nice
<pkill9>do you still need to modify linux.pri?
<pkill9>or just add the flag to that json file?
<sarg>yep, that's where qt flags are passed to chromium's GN
<sarg>json is probably used only for some GUI configurator
<sarg>check here:
<sarg>they take qt's flag and add it to gn_args which is processed by GN (preprocessor for ninja I believe)
<sarg>here is the flag thag GN expects
<pkill9>is it still building?
<sarg>pkill9: yep, 33%
<dstolfa>nckx: argh i hate how the swanctl config handles some things, namely supporting things like "10s, 1h, 12m" etc. i really want to make these things just natural numbers in the guix config, but then we have to guess what the "human readable" config is, and that simply depends on the instructions of the organization providing the vpn...
<nckx>Hm, why do ‘we have to guess what the "human readable" config is’?
<nckx>Why can't we just use seconds everywhere?
<dstolfa>nckx: because things like "4h" are a very big number and if people need help with their configuration from their org, seeing "14400s" in place of 4h might raise questions
<dstolfa>i'd like to avoid scenarios where someone asks for help, sends the generated config file and the org says: "ah right, guix is unsupported, look at this config file!"
*dstolfa has had things like this happen before and had to debug things himself
<dstolfa>i agree that just using seconds everywhere is sensible FWIW
<dstolfa>(from a technical point of view)
<nckx>dstolfa: What a bogus reaction! It's not that hard to calculate a prettier representation behind the scenes if you really want to. MODULO is your friend.
<nckx>We need to think about ‘our’ users too, and using seconds is far more friendly to them (e.g., I define some trivial hours->seconds etc. helpers at the top of my system.scm and poof, self-documenting code).
<dstolfa>that's a good point
<dstolfa>i guess let's just do the simplest thing, which is seconds
<dstolfa>and then if this becomes a problem at some point, we can do the conversion under tho hood
<nckx>I'm just sceptical that such a provider won't just look for the next excuse (‘…/gnu/store/flibbertygibbetsnakesonaplane-coreutils/bin/foo? Er, we don't support Guix!’)
<dstolfa>nckx: also, do you have a preference on, uh
<nckx>It's great you're thinking about this stuff though.
<dstolfa>let me just show you what strongswan wants to do
<nckx>OK, brb.
<dstolfa>see <conn>.over_time
<dstolfa>the config file wants to reference other configuration nodes and use them in arithmetic
<dstolfa>we could do this arithmetic in our config
<dstolfa>but then the end-result wouldn't be very legible
<dstolfa>namely how to get from value A to value B won't be obvious at all, whereas in this case it's in the config file
<dstolfa>i'm personally in favor of doing everything in guile, but again, readable configs and all that
<dstolfa>basically the config would literally contain "10% of rekey_time/reauth_time" which to me is just nuts... especially since it means "10% of MAX(rekey_time, reauth_time)", not division
<dstolfa>i think we could calculate this in guile and then just write the value in seconds, but (a) i'm not sure this works and (b) it wouldn't be very obvious how one arrived at the value
<nckx>I think we should just punt on this and support either a number or a string as field value, and write the literal string representation of either to swanctl.conf. I also think that ‘generating a strongswan.conf that looks human-made to support departments’ is too ambitious, and/or something that can be refined later.
<nckx>I say ‘we’, you're doing the work.
<nckx>So here, just let the user pass "10%" or 3600 and write that out.
<nckx>Is that too simple?
<nckx>You risk building an impressive but fragile shadow configuration system otherwise that will always risk going out of sync with upstream's… enterprisey logic.
<dstolfa>hm, maybe in that case these fields that reference other things in the config should just be strings, since they have their own enterprisey (read: weird) syntax for specifying how something should be calculated
<dstolfa>so "10% of ..." should just literally be "10% of ..." and unfortunately that's just strongswan
<nckx>Accepting both numbers & strings would merely be a convenience to users not having to write (number->string (* 60 5)) everywhere.
<dstolfa>ah yes, for the "h, s, m" thing that's true, but i'm referring to the <conn>.over_time which literally wants something in the format of "X% of something"
<dstolfa>where something is their own syntax for everything
<nckx>Then I misread the Wiki description, I thought it could be both an absolute time value or a percentage.
<nckx>→ ‘as time’.
<nckx>Super clear if not.
<dstolfa>yeah.. i'm not 100% sure i'll have to look into it a bit more, the wiki is half-clear
<nckx>I didn't read it as if users can *really* write ‘10% of …’ in the actual configuration file, just that strongswan internally uses that calculation to set the default value.
<dstolfa>yeah, i think so too
<dstolfa>but i'm not 100% sure :)
<nckx>Well, you're the authority, I'm sure you regret that now.
<dstolfa>nckx: i never had a choice, strongswan was forced on me :(
<nckx>You could test it in your non-Guixy docker one?
<dstolfa>the docker thing is uh, a little bit hardcoded and fragile with ipsec.conf
<dstolfa>i'll need a VM, but for that i need to get libvirt to make a bridge for me first
<dstolfa>and i don't know why it doesn't
<nckx>Sweet Russian nesting-doll circles of debugging hell.
<dstolfa>indeed, but it's not like non-guix things are smooth sailing either for most things i need so i'd rather get it right in guix than have a small million workarounds in other systems...
<nckx>dstolfa: I advise implementing a small subset that you know is valid now. Only the fields you need, know, & can test. You (or others) can always extend it later if you stick to the same structure as the actual .conf.
<nckx>Rather than guess how some field you might never used might behave, based on some ambiguous Wiki description.
*nckx has to reboot again, which is great for concentration, sorry.
*ecbrown observes some weird breakage in gnutls... rolling back
<dstolfa>nckx: i might just do the skeleton of the thing with just ipsec.conf for now since that would eliminate the docker workaround i have and it would verify that "legacy" configuration works as expected
<nckx>dstolfa: Sounds like we're on the same page.
<dstolfa>will continue a bit later, nice weather here
*dstolfa -> walk
***lispmacs is now known as forthmacs
<ecbrown>it's time to speed up the substitute servers by reporting in Kib/sec ;-)
<lfam>Do we have a way to declaratively set network interface MAC addresses on Guix System?
<sneek>lfam, you have 1 message!
<sneek>lfam, raghavgururajan says: I am experiencing system freezes during I/O operations, with linux-libre 5.12.x but not with 5.10.x. Just letting you know as this could be a bug.
<ecbrown>i hesitate to even think of the traffic that Guix generates
<lfam>sneek: later tell raghavgururajan: Okay raghavgururajan. I heard about some other reports of freezing with 5.12. What kind of computer are using? It's working fine for me on my computers
<lfam>Do we have a way to declaratively set network interface MAC addresses on Guix System?
<lfam>Or is there an rc.local type thing I can use to run macchanger?
<lfam>I guess I could also figure out static-networking-service-type isn't working for me
***zap1 is now known as zap
<lfam>I have this static-networking-service:
<lfam>But, the link stays "down"
<lfam>I tried `ip link set eth2 up` but it won't go up
<zap>lfam: as far as I know you cant set mac using static-networking-service but it has requirement field. Maybe you could make service that changes mac as the requirement service?
<lfam>The whole problem is that this computer does not have static MAC addresses. They change on every reboot, so my normal method of assigning stable local IPs doesn't work
<lfam>Yeah, something like that zap. I don't have a service to set the MAC address though
<dstolfa>how could i access the package install path in a profile when writing a service for it? i basically want to copy a file that the user specified in the service configuration to there
<lfam>It's weird that static-networking-service isn't working for me at all
<zap>lfam: yep i thougth mac address shouldnt have an effect on static networking service... strange
<lfam>I don't think it does...
<lfam>What I meant is that I usually assign IPs based on MAC
<lfam>Since the MAC is randomized, that doesn't work, and I have to use a static IP from the client
<lfam>And that isn't working, for some reason
<lfam>I notice that the interface says NO-CARRIER
<dstolfa>figured out my question, feel free to disregard :)
<lfam>What did you do dstolfa?
<dstolfa>lfam: i just grabbed the package definition, in this case strongswan (from networking.scm) and did a (string-append strongswan "/etc/ipsec.conf"), etc
<lfam>Now the previous Guix System generation has the same problem: no network :(
<lfam>That's weird
<zap>lfam: the problem is that you need to know interface name in advance and from what you said its not possible in your case. I had simmilar problem recently. So I had to write custom service that makes query and then uses function in syscalls.scm to set network up.
<lfam>Can you share your work, zap?
<zap>lfam: yep --
<lfam>Wow, thanks!
<lfam>It's weird, the networking on this board seems to have broken since installing Guix :(
<lfam>It worked after the initial reboot
<zap>Its WIP and think it might be hard to follow since im basically compiling a giant nested gexp there -- but the core part is configure-network-interface function. You might also find inerface-name-hwaddress-alist-gexp useful -- it returns mac/interface name alist
<lfam>Seems like my problem is going deeper
<lfam>The NO-CARRIER indicates that the physical layer is not detected as online
<lfam>And I can't get the debugging tool (ethtool) because I'm offline :(
<dstolfa>are there any good examples of services that modify files in the store?
<lfam>Files in the store cannot be modified
<dstolfa>hmm, not even via
<dstolfa>namely, add-text-to-store
<lfam>That adds a new file to the store
<lfam>Once something is added to the store, it's immutable and can only be deleted
<lfam>It may be possible to edit files in the store (this is Linux after all) but it's totally outside of the Guix model and will void your warranty ;)
<lfam>It's better to explain what you are trying to do so people can advise
<dstolfa>i'm basically trying to write a service + configuration interface for strongswan. a part of that involves creating a few configuration files (that already exist with default configuration)
<zap>lfam: maybe its the perfect usecase for `guix archive --iport' :)
<dstolfa>i want to keep them away from /etc, hence i'm trying to do it in the store
<lfam>dstolfa: The Guix way is to create a new configuration file in /gnu/store each time you change the configuration
<lfam>zap: Yeah... what a pain!
<dstolfa>so delete + make the new thing i assume
<dstolfa>are there any examples of that?
<dstolfa>well, obviously there are, but i guess the question is: are there any good examples i should look at :)
<lfam>No, the service does not delete anythign
<lfam>I would look at whatever the OpenSSH service does
<lfam>The only time that things are deleted is when running `guix gc`
<dstolfa>hmm, maybe the way to do it then is really just to put it into /etc
<lfam>We aren't communicating effectively
<solene>how do you change screen brightness? In mate it worked but I had to type root password every time it changed, on stumpwm I tried xbrightness but it can't find any display
<lfam>dstolfa: On my Guix System, `ps aux | grep sshd` => sshd: /gnu/store/qiq5q4imsvww9kbxarih9d3j2vw648bx-openssh-8.6p1/sbin/sshd -D -f /gnu/store/r994vq0r2kki6fa4ld6xrvnwvs03n0g7-sshd_config
<lfam>It creates a new sshd_config file when you change the configuration, and instantiates a new service that points to the new configuration file
<lfam>Does that make sense?
<dstolfa>ah, yes. that makes a lot more sense now
<zap>solene: i used brigthtnessctl once. You can manually fiddle with /sys/class/backlight/... but both ways require root priviliges
<zap>i guess unless you configure polkit service but I havent done it myself since Im using xfce at the moment and it works out of the box there
<solene>that doesn't seem fun
<dstolfa>lfam: hm, annoyingly strongswan can't work with this
<dstolfa>at least not very easily
*dstolfa sighs at how messy this is
<lfam>It needs to stay running when the configuration changes?
<dstolfa>lfam: no, it's just that a bunch of configuration needs to change for it to actually work with newly generated configuration files
<solene>is there a tool that create a guix package definition from cpan for perl modules?
<dstolfa>basically, in order to get the new files recognised, you need to modify yet another configuration file, and that one is a compile-time thing
<dstolfa>so it simply can't be modified without being in /etc
<lfam>The location of the configuration file can only be set at compile time?
<lfam>Well, then you should just "do it in /etc"
<zap>solene: guix import cpam?
<lfam>There are some services like that
<dstolfa>lfam: i can get away by doing only 1 configuration file and 1 directory in /etc, i think the others can go in the store
<dstolfa>but that 1 config file is just a nightmare
<lfam>Sounds like $VPN
<lfam>Nobody cares about security; Wireguard's real value is the easy configuration
<dstolfa>yeah, strongswan has more record types than wireguard has types + functions to implement everything btw
<dstolfa>and it's not even done
<lfam>Probably never will be completed, at this point
<lfam>I assume that a subset of "supported functionality" will replace the original specification
<dstolfa>probably yeah, because this is getting silly
<solene>zap: no, I would like to package a cpan module, in some distributions there are tools to create a package from a template and the information from cpan
<dstolfa>lfam: ... i do have a simpler solution for this with `guix environment` and `--expose=/path/to/cfg=/etc/...` :)
<dstolfa>what an enterprisy mess
<zap>solene: I think im not geting you :) guix import is exactly a tool to generage package using infromateion from cpan/opam/pypi etc
<lfam>I wonder, how can I use `guix archive` from a different system type?
<lfam>And get the correct derivation and everything
<solene>zap: ahh, sorry! I didn't read carefully enough. Thank you!
<lfam>I tried `guix build --no-grafts --target=aarch64-linux-gnu- ethtool -d` from the same Git commit and the derivation is different than on real aarch64 hardware
<solene>lfam: maybe this includes information from the system
<lfam>Maybe I can pass a drv to `guix archive`?
<dstolfa>lfam: honestly, if we're putting these two files in /etc, which i think we unfortunately have to, i don't think we strictly need any config file generation interface, because at that point you can use that main config file to point strongswan to the rest of the configuration
<dstolfa>but that one thing has to be modifiable for anything to work...
<dstolfa>obviously a service file would be nice, and still worth doing
<zap>solene: no worries :)
*zap going afk for some time
<dstolfa>does mkdir (the function) create a directory in the store?
<dstolfa>if so, i may be able to do some magic
<dstolfa>yes, okay i have an idea
<lfam>I guess the difference between Debian and Guix System is that Debian brings up the PHY with "Marvell 88E1510", and Guix uses "Generic PHY"
<lfam>I'm not sure what to make of this or what I could try
<lfam>It's really weird that it worked for a while
<lfam>I got an ethtool onto the system
<lfam>But, I don't even know what to look for
<lfam>Just querying the NIC gives me this:
***even2 is now known as even
<lfam>Something seems really messed up
<lfam>Even a USB NIC is reported as NO-CARRIER
<sarg>pkill9: compiling qtwebengine takes soooo long, I'll stop it. It shows 86%, but in the logs it's doing CXX on 4590th file out of 18859. Could you possibly run the build on the farm?
<pkill9>I don't have access to the build farm
<lfam>What CPU architecture are you using sarg?
<lfam>You can check the status of the build on the build farm: <>
<lfam>It will be part of the "master" specification
<lfam>You can do a search like "qtwebengine spec:master system:your-system-type"
<pkill9>lfam: this is for a patch
<lfam>You need a very powerful computer to build qtwebengine
<pkill9>sarg: just submit the patch to the original thread I started
<dstolfa>lfam: is it even worth supporting strongswan instead of suggesting workarounds? there's 92 configuration files in total that would need to be regenerated every time
<pkill9>lfam: can you have the build farm build it? it looks like you have access
<dstolfa>i can do it, but this is disgusting
<dstolfa>i've written them out, and i can finish the service
<drakonis>that sounds horrid.
<lfam>pkill9: I did build it on the build farm a few times, but it fails, as I described in that thread
<drakonis>just for reference
<lfam>pkill9: I request that you at least make sure the configure phase passes
<lfam>It also isn't clear what this patch is for. Does qtwebengine not support h264 at all? It's surprising and openh264 is not a very good implementaiton
<dstolfa>drakonis: they didn't even try to support strongswan properly lol
<dstolfa>i think they just gave up
<dstolfa>they are basically doing a "you can enable these plugins, disable these plugins" and that's about it
<dstolfa>each plugin has configuration
<dstolfa>you can't configure the logger
<dstolfa>you can't configure swanctl properly
<dstolfa>you can't configure what charon does
<dstolfa>like they just gave up i think and called it quits as well
<dstolfa>this is some half-assed implementation
<dstolfa>i'm tempted to say that putting things in /etc is better than doing something you can hardly configure
<drakonis>there'll be room for a second attempt soon enough
<drakonis>the kind you can do user level stuff
<dstolfa>drakonis: the problem is, there's not much room here. there are plugins that are compiled with guix's strongswan and each one of those creates a config file. without listing them all explicitly by default, the user would essentially have to know which plugins they need to use strongswan at all
<dstolfa>they just kind of didn't do that
<drakonis>hmm, i see.
<dstolfa>+ they can't really configure them, they just load them or not load them
<dstolfa>i'd like to avoid a case where you simply can't control your software because of an annoying limitation
<dstolfa>obviously we can do the same thing that they are doing, but it's very limited
<dstolfa>i think i'll put the infrastructure in place to extend it, but keep it very simple
<dstolfa>so one could easily modify it in the future
<pkill9>lfam: sarg has already been building it
<pkill9>so it's passed the ocnfigure phase
<lfam>They should reply to the patch ticket and explain what they changed
<pkill9>this is the patch
<pkill9>it's a follow on from the previous patch to make it look for openh264 from the distro
<sarg>give me a sec, I'll send it to the debbugs
<ss2>hi. If I build my own kernel, would it be better to build in a pure environment? Just wondering about reproducibilities.
<Noisytoot>Is it possible to use fish as my default shell on Guix System?
<lfam>ss2: I recommend building it as a package
<lfam>sarg, pkill9: Is there a specific need for openh264? qtwebengine should already support h264 via ffmpeg
<sarg>lfam: I've uploaded the patch for qtwebengine to debbugs, could you please try to build it?
<lfam>I won't be able to get to it today
<lfam>Well, probably in a few hours
<lfam>What about my question? Can't it use the h264 implementations in ffmpeg?
<sarg>to be honest - no idea. Maybe just `-with-proprietary-codecs` would do the trick. But openh264 is in the third_party tree, so it seems to be used in favor of ffmpeg's decoder
<lfam>I'm not sure there is any case where it would be preferred. Like I said, it's a limited and lower quality implementation of h264
<lfam>Maybe something is misconfigured with how our qtwebengine package uses ffmpeg
<lfam>This is why I didn't follow up with that patch in February, after it didn't work anyways
<lfam>Anyways, it seems suboptimal to add a 3rd h264 decoding dependency to this package, unless there is a reason
<lfam>ffmpeg already has two different decoders
<sarg>lfam: there is this include:
<sarg>32:#include "third_party/openh264/src/codec/api/svc/codec_api.h"
<sarg>lfam: figured it out. Enabling proprietary codecs turns on `rtc_use_h264` which depends on openh264 to encode in webrtc (skype calls?). Decoding is done using ffmpeg
<lfam>Can you mention that in the patch ticket? I have to go afk for a while
<raghavgururajan>Hello Guix!
<sneek>raghavgururajan, you have 1 message!
<sneek>raghavgururajan, lfam says: Okay raghavgururajan. I heard about some other reports of freezing with 5.12. What kind of computer are using? It's working fine for me on my computers
<raghavgururajan>sneek, botsnack.
<raghavgururajan>lfam: My device:
<sarg>while guix builds some package, is it possible to tail logs from somewhere? I'm looking at /var/logs/guix/drvs/ but the file seems to belong to a previous build
<dstolfa>is there a way to get guile to output errors better than: "here are 3 functions, error"
<raghavgururajan>Any thoughts on ?
<sarg>pkill9: hey, I've waited until the qtwebengine build was completed. It works
<pkill9>nice, did you test qutebrowser to see if it worked?
<pkill9>or any other browser using qtwebengine
<sarg>yep, I'm relaxing after this battle on /r/aww
<ss2>raghavgururajan: which kernel version are/where you using where you experienced feezes?
<apteryx>sneek: later tell civodul hey! I was wondering what happens with autoloaded modules w.r.t. to 'source-module-closure'? Seems they might not be added? I've been debugging a problem when I lazy bind (shepherd service) and something seems amiss.
***wrk is now known as pjotrp
<Noisytoot>Does Guix System include a firewall by default?
<ecbrown>no, barn doors are open
<apteryx>sneek: later tell civodul ah, I see extract-dependencies in (guix modules) has a case to cover #:autoload
<sneek>Got it.
<pkill9>nice sarg
<pkill9>did you build it on your own machine?
<dstolfa>sneek: later tell nckx 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?
<sneek>Got it.
<vagrantc>dstolfa: what do you mean by "guix i built" ... a guix with your modifications?
<dstolfa>vagrantc: yep, i've modified vpn.scm quite a bit, and i need to test it somehow
<vagrantc>you can either use all the pre-inst-env stuff to build an installation/vm/etc.
<vagrantc>or you can also do "guix pull --profile=/path/to/profile/custom-guix && /path/to/profile/custom-guix/bin/guix ..."
<vagrantc>you'd need to also pass --url= and commit= to guix pull ...
<vagrantc> for the pre-inst-env approach
<dstolfa>thanks. how do i tell sneek to cancel the message?
<vagrantc>the advantage with the approach described in the manual is if you continue to tweak your guix, you don't have to rebuild everything
<dstolfa>yeah i think i'll go with the pre-inst-env stuff
<vagrantc>not sure with sneek, but nckx probably has some clever things to add anyways :)
<dstolfa>alright, thanks, much appreciated :)
<vagrantc>yeah, using guix pull --profile= is only good if you can build quickly and are fairly confident of the changes ... i use it when i have changes that i'm reasonably confident of but aren't yet merged
<dstolfa>vagrantc: do you think that creating a VM is better here since i need to guix system reconfigure to test it?
<dstolfa>also... on another note, does `guix system vm` spawn a VM with networking?
<vagrantc>well, as long as you don't mangle your bootloader, worst case is you have to reboot with an older generation
<vagrantc>i don't have much experience with guix system vm ... i would first try it without your changes just to get familiar with it
<dstolfa>yeah... fair point
<vagrantc>and then try with your changes
<dstolfa>will give it a go, thanks
<vagrantc>but again, there's not much that can go horribly wrong :)
<vagrantc>perhaps the greatest thing about guix is that it encourages experimentation with relatively easy methods to revert back to a known working state
<dstolfa>i'm just not a fan of rebooting :D
<dstolfa>but yeah, it's not a big deal
<zap>what shall I do if i want to spawn for example an environment with additional guile-* package so that it added to guile load-path?
<vagrantc>guix environment --ad-hoc guile guile-PACKAGE
<vagrantc>i think...
<drakonis>oh boy, gnutls is exploding while compiling
<drakonis>its segfaulting atm
<ecbrown>yeah, i had to roll-back
<ecbrown>i assume its the commit after 4ec964ec38d511ca203cd3c29b194d0cfb99667a, but i am not sure
<zap>vagrantc: yep but it works only with --pure flag for me otherwise GUILE_* env variables are left unchanged and $GUIX_ENVIRONMENT/etc/profile is empty
*zap for me,,, otherwise
<vagrantc>zap: that sounds familiar...
***iyzsong- is now known as iyzsong
<iskarian>is there a general consensus on whether patches or substitute* is better for small changes?
<vagrantc>yay, i've managed to create a single image that boots both on the pinebook-pro-rk3399 and the pinebook-1080p ... with bootloaders for both on the same image :)
<vagrantc>it did require manually installing the bootloader for pinebook-pro-rk3399, as it can't use the default offsets as they clobber the pinebook's bootloader
<vagrantc>though the linux-libre config for arm64 may need some additional modules enabled for pinebook ... hrm.
<vagrantc>nothing on the display
<Noisytoot>Which package provides the "partprobe" command?
<vagrantc>Noisytoot: i would *guess* parted
<vagrantc>yup /gnu/store/...-parted-3.4/sbin/partprobe