<lispmacs[work]>vldn: I don't think so, but I just started playing around with esp8266 myself. I've run Punyforth on esp8266, but Punyforth comes with a python program that uploads itself to the esp8266
<ryanprior[m]>A package that I'm working on requires network-manager and one of its plugins (network-manager-openvpn.) Unfortunately, network-manager can't find its plugins at runtime unless they are installed to well-known locations, which I think the shepherd service does.
<ryanprior[m]>But if I want to just run the software without having it be a service, I don't know how to get it to recognize its plugins. Any suggestions?
<ryanprior[m]>The package I'm working on is the new version 3 of protonvpn-cli, which depends on network-manager.
<ryanprior[m]>One idea I had is to create a network-manager-for-protonvpn package that inherits from network-manager but adds its plugin at build time as an input and updates its rpath to include the plugin's lib directory.
<flatwhatson>ryanprior[m]: most things which want plugins like this use an environment variable of paths to search, maybe network-manager needs that too?
<flatwhatson>then any plugins you install can export themselves in the profile
<apteryx>The previous version would block reading the output of long-running child processes; this one fixes that.
<apteryx>now the /var/log/mcron.log log lines look like: "2021-08-17T12:00:05 /gnu/store/zxm6k4680k56rwnhh072zdhxjlllz6vm-rottlog-0.72.2/sbin/rottlog: mail: cannot send message: No such file or directory" or "2021-08-17T12:01:01 duckdns-update: running..." and "2021-08-17T12:01:01 duckdns-update: completed in 0.218s", for example.
<SVS>Hey, why does my keyboard not show these: >< in the manual install? I picked qwerty my country .gz
<bricewge>sneek: later tell ryanprior: I don't understand why `network-manager` don't have a `native-search-paths` for `NM_VPN_PLUGIN_DIR`. I guess using `networking-manager-service-type` together with with a user profile installed `network-manager` would overwrite `NM_VPN_PLUGIN_DIR`'s value form the service and could confuse users, thinking `network-manager` don't work even tho they “installed it everywhere” (in the system and the user profile). Most
<bricewge>people want to use `network-manager` system wide I would guess.
<slyfox>Some entries do match derivations like aircrack-ng, but some are a mystery for me, like : 3723 email@example.com /gnu/store/m7y8i8jfyvgns6gf1535hf6r4s1yvn9n-libstdc++-10.3.0-debug /gnu/store/84d8affpyvipdm4yv35kqc28q87dv1sv-libstdc++-10.3.0
<slyfox>which package does firstname.lastname@example.org come from?
<str1ngs>slyfox: libstdc++ but it's a gcc package so it is hidden
<NicholasvonKlitz>Be sure to check the bug tracker for any existing patches beforehand though :)
<NicholasvonKlitz>On an unrelated to note, has anyone been able to get FIDO or Webauthn to work with USB security keys (Yubikey, Solokey, etc.)? I've tried IceCate, Firefox nightly, flatpak firefox, Gnome browser, and none of them seem to detect my Solokey
<nirnam_>Hi, after installing bluez, I couldn't find bluetooth as a service in herd, what step did I missed?
<leoprikler>sneek later tell nirnam_: you need bluetooth-service-type in /etc/config.scm (assuming Guix System)
<maximed>sneek: later tell apteryx: Why are you ignoring the partial continuation in 'read-line*'? As it is now, if, say, a few characters of the line are read and then read-line blocks, then the first few characters are thrown away and won't be read the next time 'read-line*' is called (I think)
<sneek>maximed, apteryx says: I used call/ec with a simple 'return' continuation that just (return #f) in the suspendable-port handler, and it worked! Thank you for the pointers (see: https://notabug.org/apteryx/mcron).
<leoprikler>which commit did you use as base? (am is terrible with merge conflicts)
<leoprikler>nvm I somehow figured out how to do this in magit
<slyfox>I have a confusing guix stack trace from 'guix builf dune' on guix-core-updates-frozen: https://dpaste.com/DBYVEDMRY.txt . I suspect it's because ocaml build system does not define %outputs, but am not sure. Is there a way to get this backtrace contain more debugging details?
<apteryx>maximed: I was assuming if non-blocking read-line could not return, it'd leave the characters in the port buffer (but I wondered if this is what would actually happen or if it'd simply disregard them as you said)
<sneek>apteryx, maximed says: Why are you ignoring the partial continuation in 'read-line*'? As it is now, if, say, a few characters of the line are read and then read-line blocks, then the first few characters are thrown away and won't be read the next time 'read-line*' is called (I think)
<sneek>apteryx, maximed says: You need to keep the partial continuations around, and use them instead of 'read-line' if 'read-line' blocked previously
<Noisytoot>using (device (file-system-label "Guix_image")) generates exactly the same disk image (same file in /gnu/store)
<roptat>oh, it gets replaced by (gnu system image) anyway
<roptat>so there might be something wrong with the image generation or vmm
<vagrantc>efraim: oh, i just noticed you've been making more progress on wip-riscv! :)
<maximed>I noticed Guix has some DFSG (Debian Free Software Guidelines) and freedom 1 non-free documentation, e.g. the 'fsf-funding' man page and the 'gcc' info manual (in particular the 'Funding Free Software' chapter (or appendix?))
<maximed>Has this been discussed before in Guix somewhere?
<lfam>Guix doesn't use the DFSG, but rather the FSDG
<sneek>lfam, efraim says: I'll have to dig out my go cross compile patch again, I don't remember exactly what it was but something about setting the GOBIN made cross compiling fail. I'll finish up my go cross compile patch and then we can fix cross compiling syncthing later
<dstolfa>from RMS: The goal of invariant sections, ever since the 80s when we first made the GNU Manifesto an invariant section in the Emacs Manual, was to make sure they could not be removed. Specifically, to make sure that distributors of Emacs that also distribute non-free software could not remove the statements of our philosophy, which they might think of doing because those statements criticize their actions.
<lfam>I think that any question related to something that FSF / GNU has done licensing or software freedom has been carefully considered and explained. Now, it's fair to disagree with their reasoning, or think they missed the point. But they are definitely not careless
<dstolfa>FWIW it really feels like a lot of this is just fallout from the mess that debian and FSF had between themselves
<dstolfa>i wouldn't pay much attention to it, and i don't think it's relevant to guix
<maximed>Such front-cover texts don't tend to appear in practice, so it's probably not a problem in practice
<lfam>At least in the US, anyone can say a nasty thing like that freely. You don't need a complicated licensing scheme
<maximed>And the invariant sections in the GCC manual might technically make the manual non-free, but it's not like you cannot just skip reading those sections
<maximed>lfam: in case I wasn't clear: I was asking about _removing_ nasty cover texts (I'd like to do that _without_ having to ask permission from the nasty person who added those), not about the legality of adding them
<lfam>Yes, I know. But my point is that nobody will use the GFDL to somehow force others to repeat the insult
<lfam>I think there is some work-in-progress to improve this situation but you can't disable it
<maximed>defamation is a ‘strafbaar feit’ (approx. ‘offsense’) in $LOCAL_JURISDICTION. IIUC (and I'm pretty sure) a license (or contract, wasn't there a court case in Germany that considered the GPL to be like a contract?) cannot compel people to commit offences, so I'm pretty sure removing the front-cover text is legally-speaking safe in this case, even if it's directly against the GFDL
<lfam>maximed: Regarding appstream-glib, is it convenient for you to try setting $HOME to '/tmp'? That's more typical in our packages for cases where the build scripts want to write to $HOME
<maximed>leoprikler: Say I make a fork of something, add some documentation (and the offensive front-cover text), and upstream wants to integrate the new code and documentation, except the offensive thing
<lfam>I'd try it myself but it seems I'll need to build many Rusts
<maximed>lfam: I didn't have to build any rusts myself ...
<leoprikler>I'm pretty sure upstream will ask you politely to remove the front-cover text.
<lfam>I'm testing on ci.guix.gnu.org, it doesn't seem to have substitutes for rust and it aims to build them
<lfam>You might have already acquired the rusts, but maybe they were garbage collected on CI
<lfam>I'm not sure if the core-updates job is set up fully yet