IRC channel logs


back to list of logs

<vldn>anyone packaged platformio yet? :D or programs an atmega / arduino chip with guix? ...
<lispmacs[work]>vldn: I have done a lot of AVR program with Guix
<lispmacs[work]>vldn: however, I usually only need avrdude as I am loading FORTH onto the AVR chip and then programming it over the UART
<lispmacs[work]>I have gotten arduino-ide to run on Guix but I don't use it anymore
<lispmacs[work]>since, again, I am usually just uploading a FORTH binary to the chip and then programming it through the FORTH facilities.
<vldn>possible to program a esp8266 with avrdude?
<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
<vldn>okay then i keep packaging platformio :)
<vldn>build runs so far.. let's see how far i'll get
<lispmacs[work]>vldn: oh, Punyforth uses
<lispmacs[work]>which is available in Guix
<vldn>ah what nice
<lispmacs[work]>so, is the Guix tool available for esp8266 programming
<vldn>and avrdude runs with atmega32u4? :D
<lispmacs[work]>vldn: I believe so, though I don't have that chip myself
<vldn>nvm platformio is working so far..
<vldn> if somebody wants to try the platformio package definition
<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
<the_tubular>Anyone is using guix as a firewall ?
***califax- is now known as califax
<KittyOwO[m]>the_tubular: I'm not, but I am curious what methods of sandboxing ect. exist utilizing guix system's tools
<the_tubular>Same, I was wondering if someone came up with a good idea
<apteryx>hello Guix! I improved the mcron annotated output patch with suspendable ports, if anyone would like to try: I sent the v2 upstream (
<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.
<irfus>hi #guix!
<iskarian>Hello :)
<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.
<pkill9>haven't read much about this, but it looks interesting, it's a content-addressed functional programming language which references variables using a hash
<pkill9>using a hash*
<pkill9>and apparently you can change variable names without breaking code and without grepping through all the text files, looks interesting
<tissevert>hello guix !
<raghavgururajan>Hello Guix!
<raghavgururajan>Anyone using NitroKey with Guix System?
<KittyOwO[m]>I am not, but what is NitroKey?
<bricewge>I'm using a yubikey but it shouldn't be that different
<bricewge>raghavgururajan: At worst we are missing a udev rule for nitrokeys
<str1ngs>raghavgururajan looks cool I used a yubico and google titan key
<bricewge>Or some specific software (like ykman for yubikeys) but most features shoudl work
<raghavgururajan>I see.
<bricewge>BTW solokeys v2 looks like a great alternative for yubikey, ruggedness wise and it's open
<slyfox>As a workaround to see what is missing (and probably need fixes) in core-updates-frozen I tried 'guix weather': './pre-inst-env guix weather --display-missing -c 10 --substitute-urls='
<abrenon>hello guix
<slyfox>Some entries do match derivations like aircrack-ng, but some are a mystery for me, like : 3723 libstdc++@10.3.0 /gnu/store/m7y8i8jfyvgns6gf1535hf6r4s1yvn9n-libstdc++-10.3.0-debug /gnu/store/84d8affpyvipdm4yv35kqc28q87dv1sv-libstdc++-10.3.0
<slyfox>which package does libstdc++@10.3.0 come from?
<str1ngs>slyfox: libstdc++ but it's a gcc package so it is hidden
<str1ngs>which I'm not a fan of btw
<slyfox>ahhh, hidden package makes sense
<slyfox>Got it as: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) libstdc++)'
<str1ngs>I would think you'd want (gnu packages gcc)
<str1ngs>commencement might be for something else. maybe bootstrapping
<slyfox>oh, good point. (gnu packages gcc) does try to build the derivation locally \o/
<str1ngs>awww yeah o/\o
<mothacehe>hey guix!
<irfus>Is there a dnscrypt-proxy service for guix?
<NicholasvonKlitz><irfus> "Is there a dnscrypt-proxy..." <- Yes there is. I'm not sure it is compatible with dnscryptv2
<NicholasvonKlitz>You might have to package:
<NicholasvonKlitz>And expose it as a service
<NicholasvonKlitz>But that shouldn't be too hard. You can copy a lot from nix:
<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)
<sneek>Will do.
<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>Welcome back maximed, you have 1 message!
<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:
<sneek>Will do.
<leoprikler>bdju: Are you the bdju on libreplanet?
<bdju>leoprikler: yes. did I do something wrong?
<maximed>sneek: later tell: You need to keep the partial continuations around, and use them instead of 'read-line' if 'read-line' blocked previously
<maximed>sneek: later tell apteryx: You need to keep the partial continuations around, and use them instead of 'read-line' if 'read-line' blocked previously
<sneek>Will do.
<leoprikler>IIUC endless-sky already exists in Guix, yet you added it to the wishlist – why?
<maximed>sneek: later tell apteryx: (untested)
<sneek>Got it.
<maximed>leoprikler: It has been a little more than a week since the v3 of <>, and I haven't received any further responses. Can it be applied to master?
<leoprikler>maximed: this is about the minetest mod thing, right?
<leoprikler>If you pinky promise you checked all the mods work, then go ahead :)
<bdju>leoprikler: no special reason, must've been a mistake. was it added recently? I tend to do a guix search before I add something
<maximed>leoprikler: I'm not a commiter :)
<leoprikler>oh, my bad
<maximed>I didn't thoroughly check _all_ the mods though
<maximed>They all load though
<bdju>removed endless sky from the list. sorry about that
<leoprikler>Oh, right, you do have a check phase for that
<maximed>And I tried out some console commands from 'worldedit',
<maximed>made some simple mesecons constructs,
<maximed>used the 'unified-inventory' GUI
<maximed>the 'ethereal' world gen
<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: . 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?
<slyfox>This is the builder: . Could it be that '#:outputs (list (cons "out" ((@ (guile) getenv) "out")))' should be expanded by this time?
<maximed>slyfox: The '#:outputs (list (cons ... (getenv "out"))) seems correct
<maximed>The issue is that %outputs is undefined
<maximed>Maybe the build phases should be made a G-exp, and (assoc-ref ... "out") could be replaced with #$output
<maximed>I'll prepare a patch
<slyfox>Thank you!
<vldn>is it possible to run guix pull automatically while system reconfiguring with the help of a guile command within my config.scm?
<maximed>vldn: Not really, but there is "unattended-upgrade-service-type", which might or might not be useful for your use case
<maximed>Or maybe "guix time-machine -- reconfigure config.scm"?
<maximed>That will _temporarily_ use the latest guix
<maximed>Or "guix pull && guix system reconfigure ..."
<vldn>mhh if i pinned my kernel to a specific channel definition (like you'll do when you want a specific commit with a inferior package) then it pulls at the start of every reconfigure..
<vldn>but i think just the kernel package
<maximed>slyfox: I sent a patch series to fix these issues: <> (It might take a little while for mumi to receive the patches)
<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, you have 3 messages!
<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
<sneek>apteryx, maximed says: (untested)
<maximed>apteryx: I would assume 'read-line' doesn't put the characters back into the buffer if it starts blocking, but you might want to check
<apteryx>actually in my testing I remember rsync writing "\r progress .... 90%" and these would be disregarded (no newline). So my code was probably throwing them away as you noted.
<apteryx>I'll use the call-with-prompt as you hinted at yesterday and keep the continuation around
<slyfox>maximed: Oh, that's quite a list of fixes! Thank you! gexp evaluation rules are still way above my understanding /o\
<maximed>slyfox: gexp (#~) and ungexp (#$) are largely like quasiquote (`) and unquote (,)
<maximed>There is ungexp-native (#+) as well, with behaves slightly different from ungexp (#$) when cross-compiling
<Noisytoot>Why is a Guix ISO generated using failing at "waiting for partition '31393730-3031-3031-3138-343435333239' to appear..." when I boot it in VMM?
<roptat>what's VMM?
<roptat>and how did you generate the iso?
<Noisytoot>I generated it using guix system image -t iso9660 using as the configuration file
<maximed>Noisytoot: maybe "/dev/vda1" is incorrect?
<maximed>I just inserted a CD into my laptop and I don't see /dev/vda1 appearing
<Noisytoot>maximed, It's in a virtual machine
<Noisytoot>/dev/vda1 means it's using the virtio-blk driver
<maximed>I don't know what the correct partition name is
<Noisytoot>it works with QEMU, but not with VMM
<maximed>maybe use somethin like "(device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb"))"
<maximed>(replace the UUID)
<roptat>it's an iso, so I don't think there's a /dev/sda or /dev/vda anyway
<roptat>the installer uses (file-system-label "Guix_image")
<roptat>in the device field of the root file-system
<roptat>maybe use that instead?
<maximed>that should be independent of the /dev/... name
<maximed>Does someone have ‘real world’ examples of how the 'inferior-package-...' functions are used?
<maximed>I know how to use them, but I have an idea for a change to make, and I would want to see if it simplifies things
<Noisytoot>Where does it get the UUID 31393730-3031-3031-3138-343435333239 from?
<rekado>Noisytoot: blkid
<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>Welcome back lfam, you have 1 message!
<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
<lfam>sneek: later tell efraim: Okay, let me know how I can help
<sneek>Got it.
<maximed>lfam: the fsf-funding.1 man page would fall under the ‘Non-functional Data’ exception I guess?
<lfam>I don't know about these things :) I just wanted to clarify that the DFSG isn't in use for Guix
<lfam>The FSDG seems to include documentation in the category of "information for practical use"
<maximed>Some package definitions do remove some non-free images, e.g. ‘tennix’, so it seems guix is sometimes stricter than the FSDG
<lfam>Stricter, or perhaps mistaken
<lfam>I'm not sure the finer points of these policies are well-understood
<lfam>Certainly I do not understand them fully
<lfam>It's not even clear from the tennix package what it means for those images to be "non-free"
<maximed>I would assume it's a situation like CC-BY-ND instead of CC-BY
<maximed>What about the 'gcc' info manual? It has ‘invariant sections’, which makes the manual non-free, at least according to Debian (see, e.g., (and me).
*dstolfa thinks the FSF doesn't care much about debian and vice versa since their uh... history
<lfam>I mean, how could the FSDG (written by FSF) and the GCC documentation (founded by RMS) conflict with each other?
<lfam>And even if they did, what would the risk be?
<lfam>If FSF going to sue us?
<lfam>With Debian, the situation is very different, and not purely about licensing. In the first years of the Debian project, the Debian people were... let's say... alienated by FSF
<lfam>Those decisions are not simply about licensing
<lfam>Anyways, the GCC doc copyright is claimed by FSF, who wrote FSDG. I doubt we need to worry about distributing their docs
<lfam>You might be able to get a specific answer in the #fsf channel
*vagrantc still doesn't understand how the GFDL still has plain-as-day-obviously-nonfree defaults
<lfam>I think it's been explained in detail before, but I don't have a link handy
<lfam>Like, they have their reasons
<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
<lfam>I've spent a lot of time reading old history of the movement on mailing lists, and interpersonal problems seem to have been decisive for a lot of "what exists" in our world now
<lfam>To me, it really illustrates the value of people skills
<raghavgururajan>Hello Guix!
<maximed>lfam: I'll go on #fsf and ask the question. Maybe the waters have calmed, and maybe the FSF people have changed their opinion in the mean time. Maybe.
<lfam>If you are concerned about calmness, you don't have to mention Guix
<lfam>You could just ask, does the GFDL conflict with the FSDG?
<Noisytoot>lfam, I don't think the FSF would write a license that conflicted with their own guidelines
<maximed>Noisytoot: people (and organisations) can be inconsistent
<maximed>(the question has been asked on #fsf btw)
*maximed afk for a while
<lfam>I'd agree that they might be inconsistent at a high level, but at this low level of granularity, they are usually consistent. As the discussion there did show
<lfam>There was an explanation for this seeming inconsistency
<maximed>lfam: ‘there was an explanatiion for ...’ --> are you referring to the tight restrictions on what ‘secondary sections’ can be?
<maximed>lfam: Did you see my question on ‘front cover texts’ like ‘maximed is a horrible unperson’ that the GFDL forbids to remove?
<lfam>Yeah I did
<lfam>I mean, I can't say I agree with the whole thing. But in my experience, any question of this type that you pose to the FSF will get an extremely detailed and careful response
<lfam>Maybe it's sophistry, I can't really say
<lfam>The whole endeavour is based on the threat of lawsuits, which don't really happen as history shows
<lfam>I wouldn't worry about it too much
<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>It's totally unecessary
<lfam>I think it's an unlikely scenario
<maximed>I'm wondering if $LOCAL_JURISDICTION allows removing the front-cover texts in this scenario, even if the GFDL forbids it
*maximed looks into local free speech and libel laws
<lfam>Ultimately, the question is "will there be consquences if I violate this license?" And I think history shows that the answer is almost always "no"
<maximed>Would people go to the judge ‘maximed refuses to include the front-cover text ‘maximed is a horrible non-person’’? Seems implausible to me
<lfam>I agree
<lfam>And in the USA, the judge might not even hear the case
<lfam>And good luck finding a competent lawyer to file the case
<maximed>It makes the plaintiff look like a horrible person ...
<lfam>It's just a waste of the court's time
<lfam>I think that, within the software community, there is a tendency to view law and licenses as code, in the sense that they are effective on their own
<lfam>But, it's not like that. The law must be interpreted and applied
<lfam>It takes effort and you have to be motivated in order to do it
<dstolfa>there's a lot of armchair lawyering regarding licenses, but ultimately as lfam said, silliness will simply get you told off from the court
<maximed>lfam, dstolfa: agreed
<dstolfa>you probably have a better case for defamation than enforcing something like this
<leoprikler>better question, in which scenario would you want to copy something with a nasty front-cover text and then not include said front-cover text?
<leoprikler>Even in big rebranding scenarios like glimpse or tenacityaudio, chances are that you would rather drop the offensive thing in all but some of its entirety
<vldn>can i display creating of manual pages after every reconfigure?
<lfam>No, sorry vldn
<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, 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
<lfam>So, things may be garbage collected
<lfam>I'm doing `./pre-inst-env guix build --no-grafts appstream-glib`
<lfam>On core-updates, appstream-glib depends on rust, but not on master
<maximed>lfam: I see 133 hits for "/tmp" and 99 hits for (getcwd)
<lfam>I think /tmp is best. current working directory may change and could even be the source directory
<maximed>FWIW, I copied the (setenv "HOME" (getcwd)) from another package (maybe 'glib')
<maximed>I'll test if "/tmp" works
<lfam>I suppose if it's the same as glib, no big deal. Tbh I didn't realize people were also using getcwd for this
<maximed>Maybe a ‘standardised’ 'set-home' procedure can be added, to be used as (add-before 'check set-home) in a modify-phases form?
<maximed>So the decision could be made in a central place
<maximed>something for core-updates though
<maximed>lfam: it builds successfully with (setenv "HOME" "/tmp")
<lfam>Thanks for checking maximed. I'll push the modified patch
***jonsger1 is now known as jonsger
<catonano>I created a profile with guix environment some-package -r some/path. It's in the list of roots now. How do I eliminae it ?
<maximed>catonano: delete some/path
<maximed>rm some/path
<catonano>maximed: that's all ? Thanks !
<maximed>iiuc, it won't be considered a root anymore on the next "guix gc" run
<maximed>(not sure though)
<muradm>hi guix
<tricon>Howdy, muradm
<muradm>git checkout core-updates-frozen && ./pre-inst-env guix system reconfigure
<muradm>this will work? will build most packages locally?
<muradm>any body does such thing to ones host to be on bleeding edge?
<muradm>lfam: any comments on #49969 (seatd/greatd thing)?
<muradm>bricewge: could you try #49969 (seatd/greatd thing)?
<muradm>tricon: fine ty
<lfam>muradm: You can try core-updates like that, and you can also do `guix pull --branch=core-updates-frozen && guix system reconfigure ...`
<lfam>I think it's close to ready, unless you are using 32-bit ARm
<lfam>I just sent some "weather reports" for core-updates. Give me a minute to find the link
<lfam>Here they are: <>
<podiki[m]>lfam: nice!
<podiki[m]>looks like it is very usable on x86-64 already
<lfam>Note that all this does is check what substitutes are missing! It doesnt run any tests
<lfam>But, I think it's a very good sign. I can't remember ever seeing 97% availability before
<muradm>lfam: thanks, will try core-updates-frozen now.. :)
<lfam>It's remarkable
<podiki[m]>what tests do you mean? build tests must be passing, but guix tests (make test on the guix tree)?
<lfam>Yeah, like Guix's `make check` and `make check-system`
<lfam>I'm running some of them now
<lfam>Like, imagine a bug in Guix System's file-systems code, that caused data loss. It wouldn't be reflected in the weather reports
<podiki[m]>do they all pass on current main branch? is that a requirement before a big merge?
<podiki[m]>(excited for this core-updates update, with the new package input style and guix home especially)
<lfam>Dunno, and yes
<lfam> <> is still a problem
<lfam>Does anyone know how to run a specific test?
<iskarian>lfam: `make check TESTS="tests/go.scm"`
<iskarian>Multiple tests can be space-separated within the quotes
<iskarian>oh, and Guix System tests will probably be bare test names rather than .scm files
<lfam>Yeah, I remember how to run the system tests
<lfam>`make check-system TESTS=rsync`
<lfam>Mainly because it's impractical to run all of them
<dstolfa>lfam: i leave them overnight