IRC channel logs
2023-02-25.log
back to list of logs
<winter>okay, switching the install image to VirtIO worked. <civodul>apteryx: i pushed the perl-gd cosmetic changes i had and the #+ bit <winter>(i suspect this may be something that warrants tweaking in the default kernel configuration...) <winter>as USB images in a VM should be able to be discovered just fine, <winter>oh, am I bootstrapping the entire system... <winter>i didn't need this 24 hours ago 🙃 why now <winter>substitutes are definitely enabled <winter>what could possibly be different... <winter>i'd assume that merely editing `gnu/build/image.scm`, and building an installer image from that wouldn't require me to rebuild world because of that modified Guix, no? <winter>(rebuilding world/the system within the installer, that is -- down to GCCs) <nckx>I wonder what it means when guix gc says ‘sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory’… :) <winter>fwiw nckx, adding Image to the list was enough to get me up and running <winter>(ish, minus some weird issue wrt USB QEMU something something, but i digress) <winter>thanks for the tip about pre-inst-env lol <winter>wonder if i can figure out why none of this is being substituted if i drop into the shell <winter>surely it isn't normal to be building glibc-bootstrap-0 <civodul>apteryx: yw! would still be nice to have support cross-compilation of Perl extensions at some point, but that's more work :-) <nckx>winter: One arch (I think armhf but have already forgot) uses "vmlinuz" so it would have remained an eternat whack-a-mole and duplication. <nckx>However, can't test it because my Guix is borked. <winter>okay i'm definitely bootstrapping the entire system, ugh <winter>yeah same with guix system init manually, as expected i guess <winter>> ACL for archive imports seems to be uninitialized, substitutes may be unavailable <winter>how is this even possible in the install image >_> <winter>riiight, okay, so `/etc/guix/acl` exists <winter>but `/var/guix` is where Guix is trying to read everything from <winter>> Note: If you are using Guix System, you can skip this section: Guix System authorizes substitutes from ci.guix.gnu.org and bordeaux.guix.gnu.org by default. <winter>so `/etc/guix/acl` *is* the correct location <winter>ACL is definitely sane, cross-checked it with another system that can pull subtitutes. <nckx>My running guix-daemon was GC'd. <nckx>That sure explains ‘weird error messages’. <winter><winter> ACL is definitely sane, cross-checked it with another system that can pull subtitutes. <-- can't find the code that actually loads the file, though, just the code that warns it <winter>but the base service that initializes it with ci/bordeux's keys puts it at /etc/guix/acl as expected <nckx>Oh, I'll get myself out of this mess, but sorry I can't dive into yours :) <winter>yet guix is just not caring i guess <nckx>I should also point out that this isn't, to put it mildly, common, and may be somehow self-inflicted (although I can't see how). ′Oops I gc'd myself :3’ is not representative of Guix in general. <winter>might just post to the mailing list and give up <winter>because afaik it should be reading the ACL from /etc/guix <nckx>Unlikely, but: permissions? <winter>nckx: I think I figured it out -- for whatever reason, the installer image's Guix config directory is... /usr/local/etc/guix/acl? <winter>I... don't see how that's even possible? <winter>But that's where new ACL entries are imported to if I `guix archive --authorize` <winter>Maybe this is because I built a new install image. <winter>and the configure script did something weird. <nckx>I feel silly because I explicitly thought of that, then dismissed it as imp{ossible,robable}. <nckx>This is not intentional. <nckx>I missed quite a bit of recent context. <winter><nckx> Or ‘yours’? <-- Mine after I built it from a pre-inst-env <winter>Though I cannot find what autoconf thinks it should be. <winter>e.g. grepping for guix_prefix only shows the configure.ac refs <winter>okay so i need to pass --sysconfdir=/etc i guess <winter>Is this actually documented anywhere, though? Because unless you pass --sysconfidr=/etc, you get /usr/local/..., which breaks any Guix SD image you build <nckx>It's explicitly *not* documented (i.e., we do document --localstatedir= to avoid similar but worse disaster). <nckx>Either we make --sysconfdir=/etc the default, or, if the GNU coding standards don't let us, we need to add it to the docs. <winter>Better question: is there any code/documentation that shows how CI builds Guix, including that flag presumably, are the Cuirass specs anywhere? <winter>what about the `images` jobset, out of curiosity? <winter><nckx> Ew GitHub. <-- sorry, was quicker to grep around since a local clone didn't want to pull <nckx>It's OK, that's one reason the mirror's there (unfortunately). <nckx>But that's all ‘special’ CI jobs. <nckx>(Those that aren't ‘build all packages on branch X’.) <winter>Is that not ";; Build everything, including replacements." in that file? <winter>Could I execute a Curiass job from a plain guix invocation? <lechner>mirai / the only thing different with your NFS service snippet was the stop action, right? <nckx>My Guix is slowly dragging itself into a working state. Which is relatively impressive. If perfect software isn't an option, I'll take this. <nckx>Rebuilding missing items that should not have been GC'd. I don't know why they were. <nckx>I'd say /run/current-system is a good line in the sand, though :) <lechner>Hi, is there a way to invoke specific build systems on the command line (in a development shell), or should there be? <lechner>brettgilio / Hi, not quite. It's "(", a helpful soul also known as unmatched-paren around here <lechner>but it's tripped me up in the past, as well <nckx>Urgh… ‘no code for module (git)’. I might have been too jubilant. <lechner>do you have one in the store, or all of them (git) modules are gone? <nckx>This is in the build environment. <nckx>OK, the ‘good’ news is I've cobbled together enough of a working system to ‘guix copy’ and build .drvs on another (healthy) machine. That produces the same error. Some the bug is in the *.drv*… weird, but at least less outright spooky. <nckx>ACTION is so lucky that emacs still works. <lechner>tickling the goat's tail, so to speak <nckx>If I see a goat, I'm going to tickle it. That's the deal. Guix knew this. <nckx>(I almost did jinx it, by saying ‘and so does git’, which then promptly broke.) <nckx>So what I type out loud and doesn't seems to matter not. <lechner>we should really rename 'git' to 'goat' in Guix <lechner>is that the keyboard that puts all the letters on one key? <nckx>I find the ‘rolling’ motion of Dvorak's ‘oa’ quite pleasant? Colemak never did it for me, but that concept is legit. <lechner>maybe one day i can convert you all to my Halmak variant <nckx>More goat-yanking: if this ducktape-powered ‘guix pull’ succeeds, I should be able to bootstrap myself out of this hole of corruption. <mirai>lechner: and its not one-shot anymore <mirai>does guix support hibernate? <elb>if someone can bless it into guix bugs, that would be awesome <nckx>elb: What do you mean by not showing up in the database? <nckx>mirai: Yes, if you configure it the standard Linux way (i.e., there's no (hibernation? #t) wrapper, but mostly because that wouldn't be of value IMO). <mirai>nckx: I see this comment in elogind-configuration <mirai> ;; XXX Ignore it for now, since we don't <mirai> ;; yet handle resume-from-hibernation in <elb>nckx: hmmm when I searched mobile earlier today there were only two open vdirsyncer bugs, and that wasn't one of them <elb>maybe I just messed up <elb>ok yeah, it's just not tagged or something? if I search vdirsyncer on issues.guix.gnu.org, I don't see it <elb>if I search by number I do find it <nckx>Might be an indexing bug. <nckx>mirai: Wow, that is years out of date. <mirai>I'll go ahead and uncomment it then <nckx>We handle it just fine, excluding special (to me) cases like encrypted swap etc. <nckx>Well, we'd have to confirm that elogind does something sane when hibernation's unavailable, or there's no resume partition configured. <nckx>But if so, yes, sounds good. <mirai>is there someone in charge for elogind in guix? <nckx>ACTION points at the commons. ‘Yes.’ <mirai>right, I'll put it in a separate commit to allow for "cherry-picking" when sending for review <nckx>Without testing, the commit will be a bit ‘here's a change I think you should make, please do all the testing work and make the change if you agree’, but OK. <nckx>Maybe I'm a bit moody. Sorry if so. <mirai>I hope no one will fault me for taking the easy way of simply restructuring and leaving the fields as TODO for the elogind documentation in the guix manual <nckx>I mean, it's fine, just don't be offended if nobody jumps at that ‘review’ opportunity, is all :) <mirai>rewriting the past N old-style services has been taxing <nckx>Your work so far has been impressive to say the least. <mirai>I'm on a quest to uproot the service returning procedures from the manual and occasionally I wonder if I stumbled into an archaeological find when I see comments like these <nckx>mirai: Sorry, I'm the one who forgot to remove that! (Well, had no idea it was there, but also failed at grepping, apparently.) <nckx>elb: Weird, searching for ‘certificates’ turns up newer bugs like 61776, but not 61557… <elb>nckx: you see why I thought it wasn't there :-) <elb>I assumed I had just debbugs'd it wrong somehow <nckx>Even if you had (I don't think so) there shouldn't be a way to misreport a bug so it breaks search 😉 <jgart[m]>I also still don't have a clue how to compile the compiler. Maybe one day... 🙃 <nckx>elb: For irony's sake, would you mind reporting this? I won't work on it soon, and I don't want it to get lost. <nckx>ACTION looks at clock, wonders what 3 divided by 27 is, and goes to bed. o/ <nckx>jgart[m]: Wait… each language/book isn't simply the same set of image templates? And SICP is legitimately the largest collection (by far) I found? My faith in humanity is slightly restored. <nckx>ACTION goes to bed *emboldened*. <lechner>nckx / elb / was #61557 meant to be filed against 'vsyncdir'? If not, you can send "reassign 61557 guix \n thanks" to control@debbugs.gnu.org <elb>lechner: no, against vdirsyncer <elb>oh ... wait, it should be Package guix? <nckx>ACTION forgot to mute their laptop, lucky you. 😒 <elb>I wondered about that when I filed it, the gnu bugs instructions and the guix bugs instructions left a ... disconnect <nckx>More edidence that I should not be computing at this time. <elb>I assumed bugs-guix would _all_ be against guix <lechner>elb / don't worry. i spent a lot of time with debbugs in another life. have a good weekend, everyone! <elb>good night, and thank you <nckx>Weird. I get ‘Ignoring request to reassign bug #61557 to the same package’. <nckx>Seems like it was already reassigned. <bumble[m]>@iyzsong qutebrowser sound is working after upgrade thank you <bumble[m]>the guix system is fully functional without using dbus, ibus or elogind <mirai>I'm kinda surprised polkit-service works <mirai>2021 has polkit-service-type use polkit-mozjs or polkit-duktape and has this comment <mirai> ;; Since mozjs depends on Rust, which is currently x86_64-only, use <mirai> ;; polkit-duktape on other systems. <mirai>but polkit-service has been using 'polkit' since... 2016 <bumble[m]>the artwork that accompany the guix releases is amazing <bumble[m]>the 1.2 release airplane through the clouds is my favorite so far <bumble[m]>looking forward to seeing what is made for the next release <haugh>@Tristan Cottam, have you read up on the [Shepherd?](https://www.gnu.org/software/shepherd/manual/shepherd.html) It'll probably have a big impact on your approach. I don't know your use case but it looks a little like you're migrating from a container-centric deployment model. One of the earth-shattering things about the modern GNU system is how it makes containers a little less essential for normal service management. <TristanCottam[m]><haugh> "@Tristan Cottam, have you read..." <- On point! I used to run all my online services on Docker. I did get the impression that containers weren't as essential on Guix, but then which use cases would better fit Guix/Guix System containers? <TristanCottam[m]>To be clear, by "services", I mean online services, e.g. Nextcloud, Git, web servers, etc., not Guix services in the strict sense. <TristanCottam[m]>I haven't had a look at the Shepherd documentation yet, are there any sections in particular which are relevant to my situation? <TristanCottam[m]>I do I understand correctly that you recommend just using guix system for everything? <TristanCottam[m]> * Do I understand correctly that you recommend just using guix system for everything? <ae_chep>It has been a while since I packaged anything for guix (being a foreign distro user). Why would I be having an issue finding libguile-3.0.so when I am running pre-inst-env from a pure guix shell? <haugh>@Tristan Cottam It's a very large and astonishingly flexible system; if you want to run containers for everything, you can. You can also just run Docker. This is probably why you feel like you're not getting "definitive" answers: there's no one correct way to do anything. Personally I configure almost everything through (gnu services shepherd), but I'm in a pretty privileged position where I'm not being pressured to run software far outside this <TristanCottam[m]>haugh: I'm trying to migrate my entire workflow to the GNU ecosystem, so I guess I benefit from the same privileges as you do 😄. <haugh>@Tristan Cottam I was never a serious Docker user so I'm not the person who should make that comparison. Coming from heavy systemd use, I find extending service objects to be massively more intuitive than template units. The key advantage of writing as much configuration as possible in Guile is that Guile is an exceptionally mature and expressive programming language. <haugh>@Tristan Cottam you asked about use cases for guix containers: I personally don't run them in production but rather use them in interactive development for simulated integration testing (module/package/service integrity) before actually firing up the CI. Don't read too much into this, it's just what works for me right this instant. <TristanCottam[m]>Thanks for the insight! Could you clarify what you mean by "service objects" and "template units"? <haugh>"template units" is a systemd feature where you write crude markup into a configuration file and it uses that file as a base, generating virtual configurations according to the markup. Like almost all of the previous decade of configuration management, its main limitation is that it's not a programming language. <haugh>@Tristan Cottam I strongly recommend you read the entire GNU Shepherd manual. It's "short" although I recognize that GNU software may have warped my perspective on that attribute slightly <ae_chep>I've run `make` and now I `pre-inst-env guix` complains about missing `daemon-socket/socket` <mfg[m]>ae_chep: are you on a foreign distro? <mfg[m]>And what value did you specify during configure for localstatedir? <mfg[m]>For me localstatedir always needs to be /var <ae_chep>Okay, I have a /var/guix/daemon-socket/ . I'll edit so the build points at the right path <ae_chep>Should I do only --localstatedir or --prefix? I feel like I should edit prefix <ae_chep>welp, pre-inst-env works with --localstatedir alone. I'll leave that as is <ae_chep>now, a seperate category of question. Do you think include/*.h should be provided under the "lib" output of a package, or as a seperate output? <AwesomeAdam54321>ae_chep: if the package is a library, it should be in the "out" output. If not, I think it should go in the "lib" output <ae_chep>Thank you for the explanation. "lib" it is then <mekeor[m]>unmatched-paren: u r like a full time guixer :D <futurile1>unmatched-paren: congratulations on the second blog post - I'm finding them really helpful ;-) <sneek>futurile1, you have 1 message! <sneek>futurile1, efraim says: we now have a rust-team branch, feel free to check it out <futurile1>unmatched-paren: I know how much work it is writing well - very much appreciate the effort <ae_chep>My email client claims the acknowledgement email I got from guix is from the "Future" :) <rekado>on a somewhat outdated laptop I ran “guix pull” and tried to install the latest ungoogled-chromium that has been built on ci.guix.gnu.org <rekado>this fails because of an error in a profile hook <tiric>I am working to install guix on my machine. but there are some peole saying that I can't install extra proprietary drivers and non gnu stuff on guix without extra steps <tiric>could you tell me what exactly this entails <unmatched-paren>we're not allowed to "promote nonfree software" on this channel -.o.- <jpoiret>i'd never read past that one paragraph about promoting the use of free software, but the following ones have a ... quite paternalistic outlook <jpoiret>"do not ever include nonfree software, even if there is an easy way to exclude it. users will not know and care and so will end up using nonfree software" <bjc>i understand, and to some degree, agree with the idea that the distro shouldn't mention it. but enforcing it on participants in irc feels totalitarian <unmatched-paren>dthompson: Given that Guix is funded by the FSF, I don't see that happening :) <jpoiret>surely we can't consider the user to be responsible and take decisions based on their own beliefs <dthompson>unmatched-paren: guix isn't funded by the fsf <bjc>it promotes guix, for what little that's worth, but i don't know about money <dthompson>the fsf accepts donations for a variety of gnu projects, including guix <jpoiret>unmatched-paren: only partly though? <tiric>it is sort of funny if I can't get help for something as setting my wifi card or raid controller here. <bjc>i wouldn't call it funny. i find it authoritarian <jpoiret>tiric: well, in the meantime, as mentioned before, there's a whole other channel that can help you with those specifics <tiric>fubded or not they surly don't bought users belief system or their machines. <dthompson>at the end of the day, gnu is a loose collection of different projects. guix is free to make its own choices. <dthompson>if we collectively wanted to abandom fsdg, we could. <jpoiret>but would guix be able to stay a GNU project? <dthompson>the fallout is making rms and those in his circle mad <jpoiret>how so? I don't really see GNU endorsing non FSDG-compliant distributions <bjc>i don't necessarily want to abandon the fsdg, but i do think it should be tempered. like i said: the current environment feels totalitarian, where one is not even allowed to speak the forbidden truths. <jpoiret>bjc: but the FSDG is unlikely to change though <dthompson>bjc: the issue is that it's nearly impossible to change <bjc>maintaining a commitment to free software can be done in a more open fashion <dthompson>guix should draft its own guidelines and commit to them <nckx>sneek: later tell peterpolidoro: I didn't see your message on 22 Feb (PMs are not a reliable way to nab my attention): You did the right thing with Kicad, the Guix version number is not used to signal ‘rebuilds’ like some other distroes do. <jpoiret>the DFSG has always seemed like a nice compromise to me <dthompson>like I don't think guix should just include nonfree software, but I do think an exception needs to be made for firmware. <dthompson>and we should be able to point at third-party channels <bjc>the latter, for sure. the former i think needs to be case-by-case <dthompson>we should drop linux-libre because it's unusable for most people. <dthompson>it's unfortunate, but that's where we find ourselves. <jpoiret>well, even only the latter would be a huge step forward <dthompson>sure, but we also have to meet people where they are at <jpoiret>AwesomeAdam54321: i don't think that it's a satisfactory answer for end users <dthompson>linux-libre is probably the biggest barrier to entry for users <bjc>the thing is, people work on liberated firmware even while using standard linux <jpoiret>the dichotomy "buy a librem" or "develop your own reverse-engineered firmware" is a bit harsh <dthompson>I used to use a laptop that didn't require any nonfree firmware, but now it's too old to be useful. <jpoiret>when I introduce guix to people, it often seems like an "elitist" or "costly" distribution, just because you have to actively spend a lot of effort just to get it running on your own computer <dthompson>making a concession on the firmware issue allows guix to "just work" for many more people <dthompson>we still do not need to include any nonfree *software* <pjals>well, if guix would stop following the FSDG (which i would make me move away from guix) it would lose its shiny GNU prefix <bjc>the only thing it would lose is it's position on the fsf's free distro page <bjc>which has like 5 distros, total <jpoiret>i'm still not sure GNU would endorse a project distributing nonfree blobs <dthompson>giving the option of upstream linux OR linux-libre will result in a net increase in users, imo. <dthompson>jpoiret: it *will* open a can of worms. rms will be upset. <nckx>Not just rms. This isn't an rms-vs.-the-users thing. Shipping proprietary software is a big step, cfr. Debian drama. <dthompson>we wouldn't be shipping proprietary *software*. just firmware. <nckx>That's a distinction without a difference. <nckx>(Guix has historically cared not one whit for rms' pronouncements on things; it wouldn't be the blocker.) <bjc>not being able to use wifi is a pretty big problem <bjc>not all firmware is equally important <dthompson>getting commodity hardware to work is a big issue. that doesn't need to open the door for shipping proprietary apps. <dthompson>a firmware exception is a very practical, well-scoped change of policy imo <dthompson>the world we want is different than the world we're in. gotta onboard tomorrow's free software devs somehow. <jpoiret>but without even *shipping* proprietary software, just being able to refer to complementary channels would be a huge plus <dthompson>that change can come first before anything else. <jpoiret>(and by software i include "firmware") <bjc>tamping down on speech is definitely a bridge too far <dthompson>that alone is enough to open the "dropping FSDG" can of worms <bjc>i don't think this room will turn into a free-for-all if we can suddenly talk about the other channel <nckx>It's better to separate the two (channels. vs shipping our own proprietary softwareimeanfirmwarewinkwink) or it'll be almost impossible to resist the onslaught of FUD. I'd suggest starting with the channel thing, myself. <jpoiret>maybe there could be a funny option, by making "that other channel" the main publicized flavor of Guix, so that Guix can stay FSDG <dthompson>nckx: that sounds like a good path forward to me! <jpoiret>but at that point, just contorting the project just to circumvent the FSDG seems silly <nckx>(We'll get the FUDlights aimed at us regardless, make no mistake. :) <nckx>jpoiret: I only speedread the backlog. Which contortion are you referring to here? <jpoiret>something that I find hard to codify though, is that users *should* take proprietary vs. free in consideration, so that this channel doesn't end up just talking about M$ software all day <nckx>I have mused the same thing. <jpoiret>I don't mind people saying "well, you can look there if you need a pragmatic option for this to work", but I don't want them disregarding Guix's focus on free software either <bjc>i don't know that it needs to be codified too strongly, tbh. we'll need to rely on collective judgement, like adults <jpoiret>nckx: the contortion was just a thought experiment, where Guix + that other channel would become the "main face" of the project, while Guix itself would keep the FSDG distinction, but it's just that, a thought experiment <jpoiret>bjc: but you also don't want the project to lose that focus, right? <nckx>jpoiret: Ah. Agreed that's not worth it. <apteryx>I'm not sure what the problem is with regard discussing non-free software here. The policy is clear is made unambigous that way, and there are other channels to do so anyway, so nothing is stopping you <jpoiret>what happens if tomorrow, 1000 new users join the IRC channel and start arguing for new proprietary software to be included in Guix? there needs to be some stance on that for it to make sense <bjc>oh, there should be a stance, but i don't think it should be the current, draconian solution <jpoiret>apteryx: well, you technically can't refer those people to those other channels <jpoiret>there's no way for Guix on its website to mention those other channels either as an alternative <bjc>pointing someone to the other place seems reasonable to me <jpoiret>so most people will just assume it's a Trisquel situation: run linux-libre or leave <nckx>jpoiret: Setting aside my (genuine!) disagreement that firmware is magically not software, that could still be shut down with a ‘we don't ship that stuff, this has been discussed to death, please go elsewhere and/or stop’. <apteryx>jpoiret: I'd rather have them review the better options first (e.g. consider buying a compatible dongle) <bjc>the distinction, to me, is that this channel isn't the distribution itself. we're just people talking about a common interest. it should be fairly anarchic <jpoiret>nckx: oh but I completely agree with you here <nckx>bjc: I think that's inaccurate. This is the main distribution channel. <apteryx>bjc: this channel is the official discussion channel for GNU Guix, which is focused advancing free software. non-free software has no place here. <dthompson>I didn't say that firmware is magically not software! <jpoiret>the ideal solution would be to relax the "don't mention alternatives" part, but keep Guix fully free itself, that way there's a clear stance <dthompson>I said that it's so fundamental that we should just ship it so people's computers actually work instead of not work. <jpoiret>and the maintenance burden is not on Guix either! <nckx>dthompson: Sorry then, I didn't mean to misrepresent you. That's the only way I could interpret ‘shipping proprietary firmware does not imply proprietary software!’. <apteryx>dthompson: that's a very slippery slope to follow <dthompson>nckx: I meant that we can limit our exception to firmware only. <nckx>The software == apss definition is yours, not mine. <dthompson>"we ship upstream linux. no, we will not ship steam or whatever." <apteryx>that we should focus on shipping a system that "just works" on all hardware, no matter the non-free software considerations? <jpoiret>in a library you don't pretend the comics section doesn't exist just because you're the classical literature section: if someone asks for the newest spiderman then you can just redirect them there instead <bjc>guix is two things: a new, and powerful form of distributing an operating system, as well as a free software project. as a result, there are going to be people interested in the former, and not the latter. the question is how best to serve them <dthompson>apteryx: that we should ship the firmware blobs included in upstream linux because that *single* change enables a huge number of people to actually use guix. <nckx>dthompson: OK, but be we aware that to many people firmware is software (I didn't even think this was controversial :), so saying ‘we ship x firmware but not software’ to me is borderline winkywink. Well, more than borderline. Saying ‘we only ship x software of the y persuasion’ is more honest IMO, and illustrates that we made a choice. <apteryx>jpoiret: you don't have to pretend they don't exist, you can simply say it exists, we won't help you with it <jpoiret>apteryx: but you can at least point them there <apteryx>why? they can find it with one search engine query, if they really want it <apteryx>it'd be too easy for folks to enthusiastically point them there, without stressing the more important points <bjc>apteryx: that's the paternalism that's being complained about. at some point you have to trust people to not kneecap the project they're contributing to <bjc>and in borderline cases you talk about it <dthompson>apteryx: most people will do what they do today: try guix, have their wifi not work, then install something else. <jpoiret>it gives off a very different atmosphere though, which can seem very elitist to all non-users <dthompson>if the majority of the project is OK with that scenario, then we have nothing to change. <apteryx>jpoiret: you can always pm them if you want to go out of your way <dthompson>if we want to onboard more people, then it should change. <irfus>the considerations that a new user is forced to make when discovering that they may have hardware that won't work ootb without proprietary firmware is definitely useful. It brings into focus the non-openness of a lot of hardware, instead of making out hardware and software to be different realms with different rules. <jpoiret>but the official stance on it is what matters to the general public, and it's what shapes the image the project gives off <bjc>we're dancing around naming it, we have to tell them in secret. what goal, precisely, is being accomplished here other than making us feel like criminals? <nckx>It's a fact that people asking about a particular thing in this channel get bombarded with 5-10 PMs. <nckx>If that makes you feel like a criminal, I think you might have other issues. <jpoiret>maybe clarifying why Guix sways that way, and also that it's entirely possible to extend it yourself in whatever way you want, could help lessen the elitist vibe <nckx>I don't know what others PM, but mine certainly aren't in praise of proprietary software. To the point that I feel like a nag. But I don't feel policed. <jpoiret>although, having less users, but them having explicitely chosen Guix with its freedom considerations might be more of a blessing than a curse :) <nckx>I'm really stuck on the ‘elitist’ accusation :) Sharing moral values is not elitist. I can't make enough sense of it to respond. <bjc>it can be. there's a line somewhere, where it changes from, "this is what i believe" to "you should believe this, too" to "i'm better for having these beliefs" <nckx>First two are fine, third is pretty bad, yes. <nckx>Are you saying that's Guix? <bjc>fwiw, i don't feel that anyone here has ever been elitist <irfus>I don't think this project has crossed that 2nd line. (speaking as only a user) <nckx>(I mean, it's certainly a bad message. And yet it's something every single one of us believes about *something*. So it's still… a very interesting subject that would take us too far to unpack 😛) <bjc>that's a personal thing and my temperment. someone cynical, knowing no one, may feel that way just out of ignorance. or maybe they do see something i don't <ae_chep>I believe I am better for most things I believe in :/ <bjc>you know how some people think all vegans are secretly judging them for eating meat? i think it's something like that <nckx>I didn't want to bring up vegans. <nckx>But it does illustrate my opinion that if you resent someone for judging you, that person is not the problem, and you can't blame them for it. <bjc>it depends. some people really are like that <nckx>And my point is they are doing nothing wrong. <jpoiret>picture this: a user which has never even considered the free software question discovers Guix and thinks it's incredible. They want to try it out and install it on their computer, but suddenly nothing works, so they turn to the IRC channel for help. The only answer there is "you might need proprietary software for your wifi card, which Guix <jpoiret>doesn't ship. some other channels might provide it but we don't" <bjc>i mean some people really are being judgemental and elitist, and those people are doing something wrong, imho. i'm not a big fan of gatekeeping <jpoiret>because realistically, nobody would answer a whole pamphlet on what free software is, what are its goals, why Linux is actually not free, etc. <nckx>jpoiret: I've been the very frustrating situation before that I didn't (tech-)support someone to do something proprietary, and got an aggressive ‘I have a right to do what I want!’ back. That sounds like the entitled ‘no, I don't care, *you* have to help me!’ I'm getting from your example. <jpoiret>so nobody meant to be elitist, but the user's first experience with the community can come off as elitist <bjc>honestly, being that entitled isn't warranted even if they were using entirely free software <jpoiret>nckx: oh, i'm not advocating for anyone in Guix to debug that for them <jpoiret>i'm just describing a situation which can come off as elitist to new users <nckx>But why? Because of the ‘some other channels’? <nckx>What exactly is wrong with your picture? <jpoiret>i think that's the main problem to solve, not actually providing nonfree software or whatever <jpoiret>the thing that's "wrong" is that, from the user's perspective, being able to run Guix on *their* hardware is of no concern to the project <jpoiret>but the only impression they get is: "sorry, we don't do that here" <nckx>To me, that is *extremely* subtle and possibly dangerous to think we can control the message to that minute degree without being draconian, but I think I see your distinction now. <nckx>Thanks for being patient. <nckx>My concern is that there is a nonzero number of people who will experience Guix as elitist (or stupid, or creepy, or gay, or vegan, or…) for any random reason, including having a bad day, and that chasing a zero will hurt everyone else. <nckx>I know that's not what you're advocating. <jpoiret>Well, maybe making Guix's focus on entirely free software along with a rationale more prevalent in its presentation would help convey that message from the get-go <nckx>Oh, I totally agree with that part. <nckx>How is the FSDG lacking in this regard, IYO? <nckx>(Or any FSF/GNU/other document we could refer to, either as a link or as a basis to write our own.) <nckx>I've read the FSDG too many times :) <bjc>even if we were allowed to discuss the non-free channel, guix is still valuable as a 100% libre project, and will continue to attract work and attention simply for those values alone <bjc>i don't think the other place will eat our lunch just because we can talk about it <nckx>We're ‘losing’ users already [very growth-capitalist-market framing alert], it's not like people are currently using Guix without Wi-Fi clueless that there's no alternative. <jpoiret>nckx: well, for someone not necessarily acquainted with free software parlance, you can go on the main website, read a bit about Guix and then download it without ever realizing that it might not contain all software you might be used to <jpoiret>just saying that it's a GNU project and that it's liberating the users is a bit too obscure for the general public <nckx>(If ‘general public’ was in any way a pun, have a banana.) <bjc>i dunno. i wish guix were bigger in part because it would mean we'd have more people contributing and (hopefully) more committers as a result <bjc>my biggest problem with the project is how long patches languish <jpoiret>but now it also seems like i'm just bickering about very minor design points, which it maybe is :) <nckx>jpoiret: It's our first impression, it matters. <andreas-e>bjc: I do not think there is a point in having a big project that loses its core values. There are many big projects already that compromise on freedom. <nckx>jpoiret: No, please do bicker (constructively, and ideally by improving things)! <nckx>Turning Guix into Linux (contribution-wise) would net us all the contributors we'd ever want, but we'd all have to go search for a new distro; a net loss. <jpoiret>also, the only linked document is the FSDG, which is a guideline for distributions, not a rationale for end-users <bjc>i strongly value guix' commitment to free software, but i also believe that the current stance hinders more than helps the movement <bjc>i don't even run the other channel <andreas-e>jpoiret: Interestingly, the website starts with "Liberating". Maybe you could make a suggestion to expand on this, along the lines "only ships free software and firmware" (to avoid the discussion whether firm is soft or not). <jpoiret>Maybe acknowledging who guix is for and who it's *not for*, as well as mentioning that Guix is extendable so that channels may separetely provide nonfree software, without explicitely mentioning which ones, could help set the tone <bjc>but i'd like to be able to discuss it more openly, even just to point people there. different people have different circumstances, and have lots of reasons for not being able to use "open" hardware <singpolyma>I think that guix (vs guix system) does a lot for this already <singpolyma>Some new people do seem to come thinking they need guix system to get the benefit of guix <nckx>Trying to read our Web site with the eyes of a new user whose head doesn't explode with connotations when they see the word ‘GNU’, I agree with jpoiret. Having a friendly zero-knowledge into of what it means that Guix is Free (so still very focused on Guix) would be a great improvement. And help bolster our claim that we're building more than just software. As it is, we point users straight at the software. <nckx><with the eyes of a new user> *HARD*, by the way. <singpolyma>But honestly full guix system is a *lot* even if you are able to get your hardware working. apt install guix is a much lower bar for someone brand new <nckx>bjc: ‘even run’? As in use, or maintain? <bjc>i've never tried non-system guix, because it feels like it'd just make my systems messier to have two competing package managers <jpoiret>yes, the very first thing I see on the website when I open it is "Download", which might be what a lot of prospective Guix users start by doing <bjc>nckx: i don't use it <singpolyma>bjc: a lot of people already have 6 package managers. The promise of guix for me is to get it *down* to 2 <nckx>singpolyma: I might steal that. <nckx>(I've heard the ‘why another PM?’ argument to often, and too often with an XKCD link.) <singpolyma>Honestly I started used guix just for rollback of my production app deployments. But replacing cargo and cabal and gem and pip and make install with one thing is a huge win <bjc>i've been using vms and later containers for that reason for years and years. the promise of guix was getting rid of even that <bjc>software deployment is a nightmare, even if it's only to localhost <iyzsong[m]>guix does teach me what are free software, and that's what a gnu project for. firmware are binaries, we ought to build them from sources to distribute them. <nckx>The way it teaches many people currently is by not working. Regardless of where one stands, that can be improved. <SUPERB[m]>I was wondering why not to try a BSD-libre kernel instead of linux-libre while its structure is more similar to Gnu-hurd <patched[m]>I started using guix to force me to realize whenever I was dependent on something nonfree :D <nckx>How is BSD more similar to the Hurd than Linux? o_O <bjc>does glibc work with freebsd? <jpoiret>bjc: well, they have their own libc iirc <bjc>freebsd does, yes, but guix would have a hard time using that, i think <bjc>so it'd be likely easier to use glibc on freebsd <mitchell`>I think it would be worth while trying to package other libc implementations <SUPERB[m]>nckx: cuz Linux is monolithic while hurd and bsd are not? <nckx>mitchell`: Guix using != Guix packaging, just to be clear. <bjc>bsd is a monolithic kernel <bjc>hell, bsd is a monolithic operating system. it's got ‘make world’ after all <nckx>SUPERB[m]: I think you might be confusing BSD with something else, although I don't know what. <mitchell`>I thought these libraries were meant to be more or less the same from the userspace perspective. Why would guix be so sensitive for glibc? <nckx>And monolithic kernels are pretty sweet. <bjc>macos uses a freebsd userland on what used to be a microkernel, so maybe that's the confusion? <SUPERB[m]>nckx: You think Linux is much better than BSD ones? <mitchell`>I like linux a lot but maybe its because I'm familiar with it and it was a big step in my journey to software freedom <bjc>in a lot of ways, i prefer the bsds. i just don't like their licensing compared to the gpl <TristanCottam[m]>My two cents: I strongly agree that the Guix website should, without hindering its prestige, have a stronger focus on Free Software newbies <TristanCottam[m]>I don't think any single change will do, and that the website's design should be extensively reexamined and discussed, but having a link to further information which is at least as prominent as the download button is a no brainer <TristanCottam[m]>More importantly, I think this absolutely should be the subject of extensive discussion, regardless of any single person's opinion <mitchell`>I think it's a tough thing because some of the best things about guix that really set it apart from all the rest are lisp and nix, both of which take a bit of exposure to before you can really appreciate them. At least in my mind the "free software newbie" and the "software newbie" are largely the same person. <mitchell`>There is a lot of free software literature arguing it's merits and I think if someone ended up at Guix without finding these other things first that would be a rare thing <mitchell`>Perhaps we need more examples of practically exercising software freedom using guix <TristanCottam[m]>nckx: Of course, but I think we should have a dedicated place for this topic, as someone mentioned the other day, having a single IRC channel for everything Guix isn't a good way to discuss such important topics <nckx>ACTION just wanted to put the kibosh on the notion that this discussion was unwelcome or being supressed by any single or indeed happily maried persons. <nckx>TBH a dedicated IRC channel seems a bit ‘much’ to me, at this point. I think the whole community *should* [no fancy bold here] have a chance to see this scroll by & join in. If it becomes a distraction from support & development, we can split then. <TristanCottam[m]>Just as questions sometimes get lost in unrelated replies, I'm afraid this debate will fragment over time (If it isn't already) <mirai>thing is, if you follow FSDG to the letter, you can't mention this kind of info <nckx>TristanCottam[m]: I see your POV too… <TristanCottam[m]>nckx: Absolutely, but there should be some way, which ever it is, to at least allow making a separation of concerns <mirai>you could concoct a workaround by making a "unofficial guix" and essentially clone doc/guix.texi + litter it with @ifdef __NON_FREE__ instructions here ... @endif <nckx>Personally, I think it's very likely to become a troll magnet/echo chamber. Even choosing the name would be delicate! IRC channels aren't lightweight hashtags. <nckx>I don't think workarounds are needed to discuss any of this, the FSDG works for us, not the other way 'round. <bjc>i think it's fine here as an open-ended discussion, but if someone wants to turn it into a call-to-action, then it's probably better served on the ml <mirai>I've no problem with the status quo <TristanCottam[m]>nckx: In Matrix.org, there's the ability to reply in a thread, too bad Element uses non-free JS <nckx>I assume there are free clients, but moving this discussion to Matrix is going to heavily limit (possibly skew) participation. <TristanCottam[m]>On a side note: Does anyone know why app.element.io uses non-licensed JavaScript? <nckx>I actually came back here for a question about Matrix! To everyone who's connected to this IRC channel through Matrix: how did you find it? Exactly. Did you search for ‘guix’ (where, in which UI)? Did you follow a link (which)? Something else (what)? :) There's a relatively large number of [m] users (and some without [m]) here, and it could be important. <TristanCottam[m]>nckx: I read in a GNU article (no link, sorry) that that was the main reason why it wasn't considered <TristanCottam[m]>I understand, totally agree even, but I don't understand why Element uses non-licensed JavaScript <mfg[m]>libera.chat bridges the channels automatically and you can just join #guix:libera.chat <nckx>Right. But did you know this and manually type ‘#guix:libera.chat’? Just ‘guix’ and this one was near/at the top of the list? I'm interested in what exactly you did. <nckx>I'm aware of how the bridge works, but not how people find it in the wild. <mfg[m]>i use gomuks, i typed /join #guix:libera.chat iirc <nckx>Thanks. One count for ‘new and used the full ID’ :) <nckx>Yeah, I know the question's pretty basic, but it's the most basic action I'm interested in. <nckx>‘What u typed, how u knew?’. <nckx>Glad you said so rather than assuming yes. <TristanCottam[m]>Gotta go now, but I'd gladly discuss you-know-what and communication channels again later <Jeafran>Hello, could someone help me, I don't know why I get logged out every time I execute a command with guix <Jeafran>I'm using the operating system, only emacs qtile alacritty and xorg noma but I don't know why the session closes it didn't let me do guix pull <Jeafran>How could I see the records or the log <nckx>Is there anything in /var/log/messages that looks suspicious? It's the ‘main log’… for most things. There are a few other logs in /var/log. Guix is rather primi^Wold-school in its logging. <Jeafran>Llevo usando Guix cómo sistema operativo poco tiempo, aún cuesta acostumbrarme a manejar los permisos de grupos por ejemplo kvm cómo hago para añadirlo a mi usuario. <Jeafran>I've been using Guix as an operating system for a short time, it's still hard to get used to handling group permissions, for example kvm, how do I add it to my user. <the_tubular>I'm new to emacs and wondering which package manager matches best with guix, knowing that I'd like to keep guix as the only source of truth. <the_tubular>Meaning I don't need the packages managers that go fetch from ELPA/MELPA, I just want to load them in emacs <bjc>Jeafran: add ‘kvm’ to the ‘supplementary-groups’ list of your ‘user-account’, like this: http://ix.io/4kR2 <mitchell`>the_tubular: Use guix. `guix install emacs-evil` then when you launch emacs evil will be available <mfg[m]>XADE: for me this renders nicely, but please don't just paste such long snippets. use paste services and post the link here <mitchell`>Emacs, as installed by guix, is wrapped in a script which adds the profile to the load path <mitchell`>every emacs package you install will be available to emacs with no changes to your init file <mfg[m]>XADE: i guess you are trying to manually install guix system? <mitchell`>how do you normally configure them? I use `use-package` but don't :ensure anything <mfg[m]>XADE: if you do and you followed the steps in the manual, then you shouldn't need to chroot anywhere. If guix system init was successful just reboot. <the_tubular>But doesn't use-package fetch packages online or am I misunderstanding ? <mitchell`>It can, but only if you put `:ensure t` in the use-package form <mfg[m]>the_tubular: you can set the :ensure argument, this controls whether use-package tries to download things if they are not found already. <Jeafran>bjc: Thanks, I didn't understand that because in the manual it also tells me something about guixbuilder <mitchell`>if you don't want to duplicate your init.el in your profile. <mitchell`>Depends on what you mean by 'integrate'. Guix won't know anything about the packages installed with other package managers <unmatched-paren>i suspect the vast majority of emacs packages you might want to install are available with guix anyway <XADE[m]>mfg: but I want to chroot before booting <XADE[m]>to install grub in a different manner <the_tubular>Yeah, as I said above I'm trying to keep Guix as the only source of truth <mitchell`>and it's unlikely the other package managers will know about Guix. If they don't do anything too exotic they will probably work with the system programs provided by guix <mitchell`>If you want guix to be the source of truth then you should just use guix to manage emacs packages. I personally keep my emacs packages in their own profile which I can update/roll-back independently of other profiles <mitchell`>Plus `emacs-guix` provides a nice interface for managing these profiles <mfg[m]>XADE: i see. Because otherwise the system won'y boot or why? If not you could install normally, reboot and modify? If that's impossible, i can't help you, sorry :( <mitchell`>I mean when I install packages I run `guix package -i emacs-evil --profile=.emacs-profile` so emacs packages do not get installed in the default ~/.guix-profile <mitchell`>( not really I use emacs-guix to install these things like i said ) <mitchell`>But I point emacs-guix at this profile then run a bunch of commands <mitchell`>You mean "Can you have a manifests which consists of multiple manifests?" <mitchell`>A manifest is just a list of packages. We can easily concat multiple manifests <mitchell`>although you may need to write that code yourself <mitchell`>the manifest can contain arbitary scheme code <the_tubular> Nice thanks civodul I guess that code is already written :P <gnucode>well bummer my JMP.chat account suddenly no work. :( time to hop in the XMPP support room. <mirai>civodul: wrt dredging up pre v1.3.0 deprecated code, there's this comment on build-aux/build-self.scm: <mirai>04fa9c62d94 (Ludovic Courtès 2019-04-23 16:39:00 +0200 422) ;; Note: Use the deprecated names here because the <mirai>04fa9c62d94 (Ludovic Courtès 2019-04-23 16:39:00 +0200 423) ;; caller might be Guix <= 0.16.0. <sepi>Is it possible to specify an ordering/dependencies in mapped-devices like with file-systems? I'm having problems booting into a system that defines a file-system on top of a luks container which is on a raid1. When booting I get the message: "waiting for RAID source devices ...." for several times and then I land in the guile debugger <sepi>Another question is more about comprehension: are guix releases nothing else then a tag on the main branch? I find this a bit confusing since it's not really mentioned in the docs (afaik). In the end it's a rolling release distro with names on certain commits. <jpoiret>mirai: this is used when guix pull'd by an older guile, if there is a place to have compatibility shims that's the one <mirai>jpoiret: ok, so that one should stay untouched then <mirai>I'm getting odd make check fails from a clean ./bootstrap + configure + make <sepi>How can I debug the boot process in guix system? I'm having trouble with raid1, luks, fs mounting. Is it correct that this is managed by shepherd services? <nckx>mirai: Weren't you recently touching this stuff: ‘guix system: error: service 'networking' provided more than once’? <nckx>Is this a clean upstream checkout? <mirai>nckx: I did but that one hasn't been merged afaik <nckx>I'm also on master, but with ~40 commits to my name :) <nckx>I'm pulling upstream master to try to reproduce. <mirai>and it didn't cause any troubles when I spun vms to try out how the canonical names worked <nckx>Never mind, it's an expected error. <nckx>I jumped the gun because of your canonical patch indeed. <Wurt>Hi, I am testing a patch for updating transmission to 4.0.1, it is needed to compile all guix to make it? I have a really old laptop and it will take too many hours, how can I speed this test? <mirai>(uplifting news: the 26 (actually 28) old-style services have been deprecated/rewritten) <mirai>nckx: based on my unrebased branch, commit 67e4596781e11cd93b1fc6708484b6468388a18a was still "good" <nckx>Does /home/mirai/src/guix/test-tmp still exist? <mirai>there's 2 consistent failures with guix-pack and relocate pack I think but nothign like this <nckx>I'm not (yet) convinced this is due to any ‘bad commit’ in Guix proper. <nckx>mirai: Delete it (or move it out of the way if you want to keep it) and try again. <mirai>I'll distclean and try again <nckx>If you don't have precious untracked files, I'd use ‘git clean -dfx’ or something similar rather than relying on make deleting it (no idea if it does). <mirai>the tests that failed before... aren't failing now <nckx>Frustrating. I'm glad for you, but this is never satisfying. <nckx>Somehow your fake test-tmp database + store got out of sync somehow. Somehow. <mirai>I've decided to peek into dmesg <nckx>For a second I was verry worried you were going to point out file system corruption errors. <mirai>the checkout with the local branches, etc. resides in the same disk after all <nckx>Yes. I'd wish it on only a handful of my enemies. I think these segfaults might be ‘normal’ test suite side effects. I've certainly seen them often enough to ignore them now. I'll check. <haugh>nckx, I'm bridged through EMS/Libera. I just want to minimize the total software I use, and bridging (while very much in progress) represents the future of real-time communication in my opinion. <haugh>My matrix client lets me query "Homeservers" individually for new channels, :libera.chat is represented as a homeserver, querying :libera.chat for "guix" brings up this bridge. <haugh>Hey I'm sorry I missed the political exchange this morning, just want to articulate that I'm glad this is a topic of active and considered discussion and congratulate the community for exchanging a wide array of perspectives without losing the plot. It was a great read :) <mirai>how do I X-Debbugs-CC multiple addresses? <mirai>separate addresses with a comma? <William[m]123>is there a way to boot in text mode? by giving a kernel parameter through grub? <bjc>you can specify a kernel parameter for single-user boot, but shepherd doesn't have a concept of runlevels or systemd's targets <bjc>if you always want text mode, use %base-services instead of %desktop-services <mirai>ok, the comma didn't help at all and it just ignored the header completely <mirai>#61789 + #60756 completely vanquishes old-style services from the manual and current usage <nckx>mirai: I can't reproduce those segfaults with ‘make check’, but I'm still not worried. ¯\_(ツ)_/¯ <rekado>the build farm looks like it stalled <rekado>no substitute for ungoogled-chromium since Feb 18, and the latest evaluation of it has been cancelled. <rekado>also no webkitgtk-with-libsoup2 for i686-linux <surpador>Does anyone know how to get Chinese pinyin input working on Guix System? I'm using GNOME. I installed ibus and ibus-libpinyin, and set the variables recommended in https://issues.guix.gnu.org/35610 in my home configuration, yet I still see no pinyin option in gnome-settings or ibus-setup. <mirai>nckx: wrt #61686, how about "Monitor for kernel dropped network packets" ? <nckx>‘kernel-dropped’? I think that's what tripped up my parser (although the whole thing was pretty bad). <nckx>What's wrong with ‘dropped by the kernel’? You're not bumming assembly here. <mirai>right, I was thinking that it could be made shorter but readability wins here <nckx>(Actually, I guess ‘kernel Linux’, since it's Linux-only, and we tend to call that out when we think of it.) <mirai>(to me they both sound about the same) <nckx>(And we say ‘kernel Linux’ instead of ‘Linux kernel’ for reasons I don't wish to think about let alone explain.) <nckx>Somebody claimed to believe that ‘Linux kernel’ means that Linux is the OS, and now we're here. <nckx>Mind you, I'd totally do that too, just to see a bunch of nerds write ‘kernel Linux’ forever. <mirai>does the word ordering change the semantics? grammar isn't exactly my expertise <mirai>I'm thinking on the analogue "photo-editor Photoshop" <mirai>and this sentence fragment: "... for communication between the kernel Linux and user space for regulatory compliance" <mirai>substituting the kernel Linux part <nckx>Where'd you get that sentence? <mirai>most packages use Linux kernel <mirai>but this one and jfsutils(-static) do the inverse <mirai>linux-libre-documentation: synopsis: Documentation for the kernel Linux-Libre <nckx>I should not have started this tangent, sorry. I'm with you, ‘kernel Linux’ sounds silly in all but the most contrived or rare example, like the CRDA one. ‘Linux kernel’ is fine by me! <nckx>I'm responsible for the JFS occurence, after having previously been told that how we did things. Had I submitted that package today, I wouldn't have bothered. <civodul>mirai: ah yes, those deprecated symbols in (guix store) must still be kept <civodul>in general, we have to be more careful about deprecation in (guix ...) than in (gnu packages ...) or (gnu services ...) <haugh>why is guix more sensitive to deprecation <civodul>that's because it's important interfaces™ <mirai>right, I'll keep that in mind and maybe compile a list to guix-devel containing potentially "dead code" <civodul>there are implications notably wrt. to running "guix pull" from an old Guix <civodul>mirai: yeah, i think we should prolly focus on (gnu services ...) first <civodul>i thought that's what you had in mind initially? <mirai>civodul: oh yes, the first part is done! <mirai>#61789 + #60756 sheds 27-29 such services from the manual and the system defaults <mirai>some were broken, others had conflicting default values <apteryx>how can I restart guix-substitutes server? is that supposed to be 'herd restart guix-daemon'? <apteryx>I'm trying to understand why I'm getting: "guix substitute: warning: 127.0.0.1: connection failed: Connection reset by peer" <apteryx>(I'm exposing a remote machine's HTTPs port on localhost:8181 via SSH port forwarding) <nckx>Do you mean guix-publish? <nckx>The substituters themselves are short-lived, but yes, they are spawned by guix-daemon. <nckx>(Those being the clients, guix-publish the server.) <William[m]123>since guix-1.4.0 won't build on the install-in-progress chroot, and that it did build my main machine, I `guix archive --export guix > guix.nar`, copied it over, `guix archive --authorize --import < guix.nar` and that gives me a couple of warnings about `the repeated allocating of very large block` and OOMS with 12Gb ram. with 32Gb swap it doesn't OOM, but it spews nonsense at the screen for ~10min before I kill it <apteryx>mirai: 'kernel Linux' vs 'Linux kernel' was the wording encouraged by GNU (or at least RMS) for stressing that we're talking about the kernel, Linux, rather than 'Linux' as something bigger. I think this to ensure we don't end up calling the whole system just 'Linux'. <nckx>apteryx: Has he actually called for this (I tried to find sources but failed) or is this just people trying to emulate him (he does use ‘kernel Linux’ himself)? <apteryx>there's a subtle difference (the comma) <nckx>It's not subtle to me but that's just me. Thanks. <mirai>we could also go with "lignux" <mirai>ACTION ducks under the table <nckx>There *are* occurences of ‘the kernel Linux’ on FSF dot org, it's not our invention. <mirai>"the kernel, Linux", with the comma <mirai>but comma-less case I struggle to understand the difference (other than word ordering) <mirai>it sounds semantically the same to me <nckx>(With as well, but that's not what I meant.) <nckx>> Insisting on something that's semantically equivalent but unnatural & awkard. 🤔 <ellysone[m]>is there an enumeration-type to define configuration? <mirai>ellysone[m]: no but you can make one yourself <mirai>you make types up by defining a predicate <nckx>Anyway, I suggest just using whatever wording you think is the most clear, mirai. It's about the reader after all. <mirai>nckx: oh, I'm not concerned about that, I've already sent a v2 <nckx>Oh I get it. Clever. But a bug. <mirai>don't think that part of the patch is worth bikeshedding for <mirai>I was expecting the bot to recurse <mirai>bouncing between SRFI N and the link it grabbed <nckx>mirai: I don't think it's recursion, just the fact that the link mentions srfi-209 twice itself, so you get 3 references. <mirai>it's matching within the url <nckx>Yes. The bot has not coocoo for srfi-209. <mroh>that's why the bot is called ...-loops ^^ <nckx>Probably, but only if you control the server. <guix-help>hi, I'm trying to add my user to a group, but upon adding the group into supplementary-groups I get 'supplementary group 'xxx' of user 'xxx' is undeclared' <guix-help>so I assume the problem is that the group doesn't exist? <mirai>I mistook that name for the bot <nckx>(groups (cons* (user-group (name "xxx") (id 123)) … %base-groups) <nckx>mirai: It used to be named guix-helper-bot before the dessert-themed madness commenced. <nckx>You are not by any standard of the Internet dumb. <nckx>Oh, I didn't mean to imply that either. <civodul>damn it, the instructions to use ./etc/teams.scm are totally bogus <nckx>Heh, I was just reading your mail on another screen. <civodul>i wonder how some manage to reach teams <civodul>is there a training program that i missed? <nckx>For x86_64, I think building more than core should be OK. We're bug-bound (rekado said something about stalled builds?) but not core-bound. <nckx>Eh, CPU-bound, to avoid ambiguity. <nckx>civodul: Wait, did you literally pass ‘--add-header="X-Debbugs-Cc: foo" --add-header="X-Debbugs-Cc: bar" …’? <nckx>That's not how it's supposed to work. Is that how it's documented? o_O <nckx>No, you only one, comma-separated. <mirai>they're all ignored save for the last one <mirai>comma-separated also doesn't work <nckx>Then you should report a bug. <mirai>the field gets ignored completely <mirai>nckx: did you get a CC from me? I think for the large old-style services <mirai>iirc I X-debbugs-ccd 2 addresses <nckx>I'm stuck with K-9 at the moment, I don't think I can sanely search for that? <mirai>the receipt didn't say it CC'd anyone <nckx>Ominously, GNU's (forked! old! uh oh!) debbugs docs don't include Debian's ’If you want to send copies to more than one address, add them comma-separated in only one X-Debbugs-CC line.’ phrasing. <mirai>so I assume it failed or I used the wrong delimiter <nckx>Who knows, it might actually be missing 🤦 <civodul>if only there were a "teams.scm" team <nckx>Well, if GNU debbugs doesn't support this, as mirai indicates, what can we do? <mirai>X-Debbus-CC: ludo@gnu.org, me@tobias.gr <nckx>Typo aside, that's an example of something that won't work, right? <mirai>this was munched by debbugs in #61789 <nckx>No, I mean, do you mean it in a good or bad sense? <mirai>my keyboard munched the __bugs___ <nckx>Or did you actually make the typ—oh. <mirai>multiple x-debbugs-cc don't work, at least that one is right <nckx>Right, but that's expected (we should document it if it's a common misunderstanding though). <mirai>now, the comma thing, I'll "try again" on the next relevant patch <nckx>Honestly I haven't used teams.scm yet. Does it generate these bogus multiple headers? <nckx>…yes it does, it was just slow. <nckx>So this has never worked. <apoorv569[m]>How to get scripts like bash, perl, ruby and python running on Guix? <apoorv569[m]>Just have #!/usr/bin/env perl for example just says /usr/bin/env: ‘perl’: No such file or directory.. <nckx>civodul, mirai: Went ahead & sent that. If you have a patch waiting, a test would be appreciated :) <nckx>apoorv569[m]: Is perl installed? <nckx>And just typing ‘perl’ runs perl? <nckx>Disregard that, I'm dumb and can't keep two terminals straight. <nckx>I cannot, in fact, reproduce this, and all is well with the world. <apoorv569[m]>well running the script like perl path_to_script works but I don't want to run script manually.. is there a way to make it read the shebang? <nckx>Yes, ‘#!/usr/bin/env perl’. <nckx>It is… odd that this is reportedly not working for you. <elb>I remember when I was limited to alt+F1 through alt+F6 <elb>I still coudln't keep track of all my terminals <Noisytoot>Since when does Guix System have /usr/bin/env? <apoorv569[m]>I do have it in the script.. do I need to reboot before the system realizes that perl is installed? <nckx>elb: I have 12 workspaces and that's never enough, but don't ask me to keep 4 screen quadrants straight. <elb>(probably very few other people here remember when you didn't start X11 because it took too long) <nckx>Bleurgh, and the Moiré background giving you a headache whilst your hard drive rattled. <elb>don't forget netscape -installColorMap and the psychedelic colors when you changed focus <nckx>apoorv569[m]: No, this is very strange. What does /usr/bin/env bash -c 'echo $PATH' print? <apoorv569[m]>Noisytoot: Thats what I was thinking. I had to do `(extra-special-file "/usr/bin/env" (file-append coreutils "/bin/env"))` for running bash scripts <nckx>[If it's ‘bash: no such file or directory’, I give up.] <apoorv569[m]>It returns my PATH correctly. What are we looking for in the PATH? <nckx>The directory containing ‘which perl’. <nckx>Noisytoot: Since a very long time. <nckx>Assuming you use %base-services. 