IRC channel logs


back to list of logs

<nckx>gorrilaX20: We got separated. Welcome back.
<nckx>gorrilaX20: Your configuration has some errors in it.
<nckx>Not related to the module.
<nckx>Trying to fix it.
<gorrilaX20>nckx: thank you very much!
<nckx>gorrilaX20: Replace your configuration with this: (only the fixed version of yours, promise 😉)
<gorrilaX20>nckx: Of course
<nckx>TL;DR: your ( and )s weren't matched correctly.
<gorrilaX20>nckx: It is actually doing something, I think it is WORKING!
<nckx>gorrilaX20: It's building a system that should load the module automatically. However (and this is completely my fault): I was in a hurry earlier, rushed, and made a mistake. The firmware… it isn't free. :-/
<gorrilaX20>nckx: Oof :/
<nckx>So I've commented it out. Let's reboot your machine and see what happens.
<gorrilaX20>nckx: It is still busy
<nckx>gorrilaX20: Big oof. I sent you a personal message about it but I don't think you saw it.
<gorrilaX20>nckx: I'd prefer not to use proprietary crapware
<gorrilaX20>nckx: But wifi is really neccesary
<gorrilaX20>nckx: So unfortunately I must use the proprietary firmware if t doesnt work
<nckx>I feel your pain.
<gorrilaX20>nckx: guix/ui.scm:1936:12: In procedure run-guix-command:
<gorrilaX20>Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'.
<gorrilaX20>substitution of /gnu/store/24yvi2yyknfrpyb7linxd09dkpc560xp-nss-certs-3.50 failed
<gorrilaX20>killing process 8863
<NieDzejkob>echo "free replacements for wifi firmware" >> ~/longterm-todo
<gorrilaX20>guix system: error: some substitutes for the outputs of derivation `/gnu/store/qnc4hww9jcc3sdd0hqs0n6zsfirf8h5r-nss-certs-3.50.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<NieDzejkob>did you get a message about locales?
<gorrilaX20>NieDzejkob: Yes
<NieDzejkob>what locale are you using?
<nckx>gorrilaX20: Repeat the command you ran with --keep-going. When that fails (it will), replace --keep-going with --fallback.
<gorrilaX20>NieDzejkob: nl_NL.UTF-8, as I am dutch
<nckx>gorrilaX20: The nss-certs is a notorious test suite for anything remotely unexpected local-wise.
<gorrilaX20>nckx: I will do that
<nckx>En check ook je PB.
<gorrilaX20>nckx: Je bent ook nederlands?
<nckx>Zuiderse namaak.
<gorrilaX20>nckx: XD
<NieDzejkob>ah, yes, I know some of these words!
<gorrilaX20>NieDzejkob: It works with --fallback (I think)
<nckx>gorrilaX20: --fallback means ‘build locally if substitution fails’. The locale error happens specifically when unpacking the substitute (=prebuilt binary), but not when building from source, so this works around the error.
<gorrilaX20>nckx: Thats interesting.
<nckx>It's a known bug but I'm not sure we even know what happens or how to fix it.
<gorrilaX20>nckx: well that happens
<nckx>I've never encountered it, I guess I'll try nl_NL.UTF-8 when I have time.
<gorrilaX20>nckx: Allright what even is the diffrence between nl_NL and the belgian one?
<nckx>I honestly wouldn't know.
<nckx>Not that I use either.
<gorrilaX20>nckx: You just use en_US or something?
<nckx>s/nou/nu/, done.
<nckx>zh_CN or en_IE (it's like en_US but with sane units).
<nckx>Truly, en_IE is a life hack.
<gorrilaX20>nckx: I know right haha metric ftw
<gorrilaX20>nckx: Done. SHould I reboot now?
<gorrilaX20>nckx: bye
<NieDzejkob>I think this bug happens when $GUIX_LOCPATH is not set at some point. guix-daemon?
<gorrilaX20>nckx: Rebooted did not work, got nonfree firmware loading disabled error
<gorrilaX20>nckx: This is sad, however how do I make sure I can run the rtl8723de driver?
<nckx>NieDzejkob: Is that possible on Guix System? I've saved gorrilaX20's configuration, I'll try to reproduce it in a VM.
<vagrantc>hrm. on armhf with commit fae75ff9911b91a8c5ec257335c7ebed04c82929 "guix build guix" fails with: FAIL: tests/cache.scm
<nckx>gorrilaX20: If you get that error, you successfully loaded the driver.
<gorrilaX20>nckx: its just the firmware right?
<gorrilaX20>nckx: That's causing the issue
<nckx>gorrilaX20: Correct.
<nckx>As a GNU distribution, we cannot endorse or help you install any non-free software. That includes firmware.
<gorrilaX20>nckx: I understand that
<gwroalyf>nckx: gorrilaX20 said that he new to Guix but not to Linux, so probably they can search the Web.
<gwroalyf>*they new
***gwroalyf is now known as guix-vits
<leoprikler>Well, the particular difference of Guix to other distros in this regard is the use of the linux-libre kernel, that disallows blobs.
<guix-vits>leoprikler: No switch? Respect.
<leoprikler>So even if they're "not new to Linux", they're probably not used to being restricted in their hardware choice to that extent, as many just add those blobs because they don't care.
<leoprikler>Switch? What switch?
<guix-vits>leoprikler: "allow-load-blobs? #t"
<guix-vits>Anyway, someone there uses a custom Kernel, and the Cookbook has something about this. But this isn't a "due tomorrow" task, probably.
<leoprikler>As far as I understand, you have to go out of your way to seek out the tainted kernel if you need blobs, but I may be mistaken.
<ngz>IIRC, linux-libre refusing to load blobs is a bug, not a feature.
<leoprikler>idk, "I hate blobs, but AMD gets a pass, because they threaten to not let me display anything on the screen otherwise" does not like a very convincing argument for blob loading
<guix-vits>nckx: Is "rtlwifi_new" proprietary as well?
<leoprikler>looking at all those _fw.bins... yes
<nckx>guix-vits: Yes ☹
<ngz>leoprikler: I think a blob is not necessarily non-free, as long as source code is available.
<nckx>ngz: That's correct, and they're quick to point that out, but it's not one they seem in much of a hurry to fix either.
<ngz>nckx: It may be structurally hard to fix.
<ngz>It sounds like collateral damage from the deblob script.
<ngz>I wonder how Debian deals with that. I think they somehow deblob their kernel, yet they can load firmware.
<nojr>hello friends, I have a question: why are some packages for python so outdated? for example, django sits at version 1.11 and pandas is around v0.25?
<leoprikler>nojr: because people haven't updated them. Package updates are to be sent to first for review
<drakonis>ngz: they just dont provide them
<drakonis>the linux kernel doesnt load it if it isnt available
<drakonis>no deblobbing required
<drakonis>no patching required, as the loading mechanism has changed enough for the firmware to live on a different repository
<leoprikler>I don't think Debian uses Linux-libre by default, does it?
<vagrantc>ngz: debian's packages just shunt the kernel into a separate part of the repository; they don't remove the ability of the kernel to load blobs like linux-libre does.
<vagrantc>ngz: er, just shunt the kernel blobs into a separate part ...
<vagrantc>that said, linux-libre is perfectly able to load blobs for free firmware, e.g. ath9k_htc
<nckx>drakonis: The issue is that it would still print ‘looking for proprietarygargage.fw’ in dmesg and Linux-Libre considers that ‘pointing users to non-free software’. It's a very… principled stance. I'm not sure I share it but I *get* it.
<vagrantc>linux-libre more-or-less audits which firmwares to disable
<nojr>leoprikler: so the person that sends the package is not technically the one in charged? anyone can resend for updates?
<nckx>nojr: Yes. We have no designated package maintainers.
<nojr>nckx: ok gotcha, thanks
<ngz>drakonis, vagrantc: I see. Thanks.
<ngz>Sleep time! Bye.
<drakonis>nckx: its a really weird stance to deny its existence
<raingloom>guess i'll ask again: how does one use "gio mount" without installing the entirety of gnome? i just can't figure out what packages are needed and where.
<nckx>drakonis: I guess, if that's how you see it.
<ryanprior>raingloom: those sorts of questions are mysterious to me. I've literally been bisecting package lists to figure things out =X
<raingloom>ryanprior: welp, great. i guess i'll look at the inputs of gnome and try adding stuff from it. if you figure it out, pls add it to the docs or package descriptions somehow.
<ryanprior>Anybody know which package has `ping` in it?
<butterypancake>I want to use the v4l2 loopback kernel module but I don't think it's packaged? I'm not sure how kernel modules are done in guix, can someone point me to some existing kernel module packages I can look at?
<apteryx>butterypancake: wireguard-linux-compat seems to be such an example
<butterypancake>oh yes, that's wonderful example! Thank you very much! It looks like a completely normal package other than the use of linux-module-build-system though. I wonder if I can get away with packaging v4l2 without figuring out how kernel modules work :P
<nckx>ryanprior: inetutils.
<nckx>Probably needs to be setuid.
<ryanprior>Do I have to do something special to let it be setuid?
<nckx>butterypancake: Search for -linux-module for some simpler examples (wg includes a kernel patch which complicates the code).
<nckx>I also prefer that naming scheme for lack of a better way to discover packages.
<nckx>ryanprior: cons it to the setuid-programs list of your operating-system.
<ryanprior>Is that possible on a foreign distribution?
<butterypancake>all the things that end in linux-module are in linux.scm. I guess that's where I should put v4l2loopback?
<nckx>ryanprior: No. You'll have to ‘manually’ make a copy & make it setuid, or something like that.
<ryanprior>Oh boy, more fun.
<nckx>butterypancake: Yes, I'd prefer so.
<nckx>They are essentially plug-ins for the kernel, sprinkling them around in say video.scm here feels wrong to me.
<butterypancake>oof. It looks like someone needs to take the 2 seconds to tighten up the linux-module names. They're all in the same spot but a third don't have the suffixes
<butterypancake>I mean theres a bunch in one spot. Maybe not all
<nckx>Well, that seemed like overkill to me.
<butterypancake>ugh, I don't think a single thing I've packaged had a configure script so I keep having to pass parameters to the makefiles. Shouldn't we in the default build system set CC and prefix and stuff?
<nckx>This week I'm saying: no. But tune in next week when I change my mind again.
<butterypancake>I feel that's a really hard thing to change your mind on. Wouldn't you have to do a regression test for literally everything?
<nckx>Mind, not code.
<butterypancake>ahhh, very true
<nckx>A regression test on my mind would be a lost cause from the start.
<butterypancake>now I'm confused. the configure step worked but I don't see a configure script...
<nckx>I'm not used to Linux kernel modules having a ./configure script (I'm aware they exist, I think ZFS had one). Are you using the linux-module-build-system?
<butterypancake>I am. and it has a configure phase. but the manual says the configure phase means something different so I'm going to ignore this I think
<nckx>Anyway, its 'configure phase isn't ‘run ./configure’. Each build system can define its own meaning of what it means to configure. See guix/build/linux-module-build-system.scm.
<nckx>./configure is really autotools-specific, although it's extremely common to the point that non-autotools packages sometimes include one (those are fun — they often choke on standard arguments and need special-casing anyway).
<butterypancake>looking at you opendoas :/
<butterypancake>is :#check-flags not a thing? I need to add -C ./tests to the check phase...
<nckx>butterypancake: No, you'll have to replace the check phase for that. You can still re-use the standard make-flags (even if you don't currently use any), see rtl8821ce-linux-module which replaces the 'build phase.
<nckx>However, most kernel module test suites can't be run because they require loading the module first which is obviously not going to happen. But YMMV.
<butterypancake>wait, that phase doesn't end in #t. Or did you tell me invoke always returns #t? I remeber something like that
<nckx>Yep. It's documented to.
<butterypancake>if you claim something is gpl2+ at the top of a file, do you just provide the standard gpl2 license along with it? Is there no + added to that license file somewhere?
<butterypancake>That would explain why I messing up licenses on my first ones
<nckx>Oh please. That's happened to literally everyone.
<nckx>*Almost everyone. I forgot liars.
<butterypancake>ya, I have no clue how to pass the makeflags to the check phase. I'm certanly doing something wrong...
<butterypancake>wait, maybe I'm doing something right. The default makeflags are empty right?
<butterypancake>I think I actually did it perfectly and forgot that the default makeflags are empty :P
<nckx>(lambda* (#:key (make-flags '() #:allow-other-keys) …)
<nckx>butterypancake: Yay!
<butterypancake>almost right, why the '()?
<nckx>It's a default.
<nckx>If make-flags wouldn't be passed for some reason.
<butterypancake>cool. Thanks for teaching me :)
<nckx>How? When? I'm not really sure, it's a defensive reflex. Note that #:make-flags support is *really* new to the l-m-b-s. As in, this week or so.
<nckx>Maybe it's no longer needed, like we don't write (inputs '()) (outputs '()), I dunno.
<nckx>It's 05:00 here I should not try to think and go to bed.
<nckx>Do well! o/
<butterypancake>:P sleep well!
<butterypancake>IT BUILT!!!!
<butterypancake>now how the hell do I test it...
<butterypancake>do I install it?
*nckx whispers between freshly brushed teeth (…ew): you can try to insmod it, and if your lucky the kernels will match and it will work.
<nckx>*you're but 5am & all.
<butterypancake>I installed it but modprobe can't find it, do I restart my system?
<nckx>butterypancake: No, insmod /gnu/store/the/full/path.ko.
<butterypancake>will do
<nckx>Or insmod ~/.guix-profile/lib/module/the/same.ko.
<nckx>All ‘installing’ buys you here is a known file name. To actually make it show up in modprobe's search path you'd have to add it to your system configuration.
<butterypancake>THE DEVICE SHOWED UP
<apteryx>nckx: eh, sleep tight in the gentle morning light.
<nckx>I'm glad I stayed up 10 extra minutes for the sense of (indirect) accomplishment but now I muszzzzzzzz
<butterypancake>expect a patch real soon :P Thanks so much for all your help! But you might consider getting a more normal circadian rythm :P
<apteryx>cbaines: reading man setgid makes me think that having a separate setgid-program-service-type is the right thing... shame I already made a bunch of changes for extending setuid-program-service-type
<apteryx>(not published yet)
<apteryx>or maybe not. What syscalls exist in Linux and how uid/gid are stored as file attributes are two different things.
<apteryx>all setuid-program-service-type is sets the copy the program file outside of the store, set the file ownership (user, group) and chmod it to #o6555.
<apteryx>which means both the setuid and setgid bits are set currently
<pushcx>If I run 'guix search ruby' there's a couple version of ruby available. How do I specify which I want in a 'guix environment' command?
<apteryx>pushcx: ruby@version
<pushcx>apteryx: thanks!
<xelxebar_>Anyone here familiar with internals, specifically relocations?
<reepca>does berlin by any chance export /var/guix over NFS as per
<xelxebar_>I have a hand-written ELF and am trying to get a simply "hello world" assembly prog working with puts, but I'm failing at getting to relocate my symbols correctly.
<janneke>xelxebar_: puts? sort of like this =>
<xelxebar_>janneke: Well, the assembly code itself is the easy part, I'm hand-coding the elf binary (via .byte* assembler directives etc.)
<xelxebar_>Also, that example doesn't use puts, it directly invokes the (i368) write syscall.
<janneke>xelxebar_: sure...and it needs the header -- just wondering what you're doing...
<janneke>for the bootstrap, i played a fair bit with hand-crofting elfs, but avoided dynamic loading
<xelxebar_>janneke: Oh cool. I'm also hand-writing an ELF. Getting a static "hello world" like you show is pretty straightforward, but now I'm stuck trying to set up the relocations correctly to work with libc.
<xelxebar_>I mean, I have the reloc, symbol, string, dynamic, and hash tables all set up so that readelf seems to like it on the surface.
<xelxebar_>However, running with LD_BIND_NOW=1 and LD_DEBUG=bindings, simply relocates nothing.
<janneke>xelxebar_: and readlink show the dependency on libc?
<xelxebar_>janneke: yeah.
<xelxebar_>Running the binary with LD_BIND_NOW=1 and LD_DEBUG=bindings also shows that is pulling in libc but failing to bind any of my supposed relocations.
<xelxebar_>I have glibc and glibc:debug pulled into an environment and am stepping through from the _start of, but without studying glibc's source, nothing stands out to me.
<janneke>and doing that (LD_DEBUG...) with a trivial gcc-compiled elf shows no obvious other output?
<xelxebar_>janneke: The only difference is that it shows puts and _exit being relocated. ;p
<xelxebar_>I've compared against the gcc-compiled elf and meticulously ajusted sections, alignment, etc, but clearly there's something I'm missing.
<janneke>xelxebar_: oh!
<xelxebar_>Of course, I'm not simply re-writing the gcc-compiled elf by hand, only using it as a reference.
<xelxebar_>Probably the biggest difference is not including a got or plt. I figured that directly relocating in the .text section would be a good first attempt at setting up dynamic linking. However, I'm not even sure if this is unreasonable.
<janneke>xelxebar_: have you looked at poke?
<xelxebar_>Never heard of it!
<janneke>=> "she can search, inspect, create, shuffle and modify abstract entities such as ELF relocations, MP3 tags,"
<xelxebar_>This looks pretty handy! Thanks.
<xelxebar_>Also, I don't see it in guix packages. Might have to do that.
***wxie1 is now known as wxie
<janneke>xelxebar_: oh, i saw the announcement but haven't played with it yet
<xelxebar_>janneke: What board/ml/radio station do you frequent that has this kind of stuff on it? Need this in my life.
<reepca>I've been getting 502 responses from for over an hour now; any idea what its status is?
<janneke>xelxebar_: probably info-gnu,
***wxie1 is now known as wxie
<xelxebar_>Thanks. Looks like our bison package is too old to build it :/ I'm already deep in the elf rabbit hole... should I start some hardcore yak shaving while I'm at it?
<janneke>s/should/could ;)
<nckx>Mornin' Guix.
<mothacehe>Hey nckx!
<mroh>good morning nckx!
***apteryx is now known as Guest22959
***apteryx_ is now known as apteryx
*nckx waves.
<guix-vits>Hi nckx.
<sneek>marusich, you have 3 messages!
<sneek>marusich, dftxbs3e says: I tried reading code in the maintenance repo and looking at the how to-s and it's been very unclear to me
<sneek>marusich, lle-bout says: so cuirass runs but not so much because it wont really build anything - I was trying to build an installation image but could not because things reference grub-efi which isnt available on powerpc64-linux - using $ ./pre-inst-env guix system disk-image gnu/system/install.scm
<sneek>marusich, lle-bout says: I would like to work on the little endian side some time
<marusich>sneek later tell lle-bout I intend to keep poking at this as time goes on. If we can't figure out how to make gcc reproducible, we may want to consider just biting the bullet and getting the bootstrap binaries in, but we can discuss that on guix-devel a bit, too.
<sneek>Will do.
<xelxebar_>Dang, nckx, you went to bed ~6 hours ago and are already back. Is #guix directly fed into your neocortex or something?
<civodul>Hello Guix!
<marusich>hello civodul, and good night :0
<marusich>That was meant to be smiling face :)
<nckx>xelxebar_: Lol. More like 4h, I'm afraid. :-/ Not great. #guix babbles in the background to distract me from work and I am grateful for it.
<nckx>civodul: Greetings comrade.
<efraim>I couldn't figure out how to make a little endian chroot on dftxbs3e's PPC64 machine
<bricewge1>Hello Guix!
<civodul>hey ho!
*guix-vits +1, io-ho-ho
<bricewge1>civodul: Tell when you want to debug the “guix deploy” UUID issue
<bricewge1>Did you manage to reproduce it on your side?
<guix-vits>Is anyoune had that: `herd stop tor` didn't stop the actual tor process, so `herd restart tor` result is failure?
<civodul>bricewge1: nope, never encountered this
<civodul>guix-vits: no, maybe a bug?
<guix-vits>civodul: IDK. How can i check?
<guix-vits>`sudo herd stop tor` -> Service tor has been stopped.
<guix-vits>`ps -e| grep tor` -> 31995 ? 00:00:01 tor
<guix-vits>htop shows that this owned by "tor" user
<bricewge1>civodul: Oh, that's odd, myabe there is an issue with my hardware
<civodul>bricewge1: ah, are there hints suggesting that in dmesg or something?
<nckx>The description was pretty bad.
<guix-vits>nckx: Also \" in Texinfo isn't valid?
<nckx>guix-vits: No, it's all right, just didn't make sense here.
<guix-vits>nckx: Thanks, noted.
<bricewge1>nckx: I'm having issue sending email.
<nckx>bricewge1: FYI, your key on hkps:// is expired. Haven't checked the one on Savannah yet.
<nckx>bricewge1: It won't solve your problem, but issues.guix accepts Web replies now.
<nckx>bricewge1: By the way, you can use ‘git am -s’ to add the (mandatory) Signed-off-by line for you. Or you can of course add it by hand. I did that for an embarrasingly long time.
<bricewge1>I don't know why I didn't saw the double space missing bettwen sentences, I looked for it...
<bricewge1>nckx: My keys on Savannah are up-to-date
<nckx> works better with my ‘gpg --refresh-keys’ cron job though 😉 It's worth updating when you have the time.
<bricewge1>nckx: Will do!
<bricewge1>I still don't understand the nuance between Signed-off and PGP signing the commit I submit for someone else.
<nckx>Thanks! I agree that Savannah is more important though.
<bricewge1>I mean it's clear that I'm not the author but just the commiter
<nikita`>Signed off is more like a statement
<bricewge1>Is it used to more easily parse git-log?
<bricewge1>nikita`: Signing with GPG seems like a stronger, non repudiable, statment
<nikita`>I'm no fan of pgp, but both serve different purpose in guix I think. I only know that in another project we check and reject pgp-less commits.
<bricewge1>nckx: Updated, thanks for the heads up
<bricewge1>nikita`: PGP has an awful UX for sure. What are there different purpose? That's what I'm missing here.
<bricewge1>Commit have to be pgp signed here too, maybe gpg-less commits will be rejected in the future.
<civodul>they've been rejected for a few years :-)
<bricewge1>I mean on the server side
<bricewge1>FWIU Savannah don't allows that.
<civodul>bricewge1: we have a hook on Savannah for guix.git that rejects unsigned commits
<nckx>bricewge1: Without getting into the legal history of it, S-o-b as passed down to us from Linux means you explicitly certify that <>, while GPG just proves ‘I dun this’. However, it's true that *we* don't actually document that anywhere, it's just implicit knowledge.
<nckx>…or maybe I'm overestimating things and people just cargo-cult it because it's in the log :-/ Dunno.
<bricewge1>civodul: That's good news! I was stuck at
<nckx>While you could define a GPG sig to mean the same in the context of your project, S-o-b lines can easily be passed around through e-mails and patchworks and such. A GPG signature attached to a commit is always at risk of falling off.
<nckx>But you want the GPG to make sure the S-o-b is actually legit, so it's all a bit grey.
***guix-vits is now known as gwroalyf
<civodul>bricewge1: what i meant in that message is that we don't have a server-side hook that does the work that "make authenticate" does
***gwroalyf is now known as guix-vits
*guix-vits "roar"
<bricewge1>nckx: “[...] please add a Signed-off-by line [...]. This improves tracking of who did what.”
<nckx>bricewge1: I'm aware, but that doesn't answer your question I was trying to answer above.
<nckx>Manual says ‘do this’, you ask ‘but why if GPG’, that's a fair question.
<bricewge1>The doc should reflect the legal reason behind it
<bricewge1>nckx: Yes, thank you for answering now I understand the nuance
<nckx>bricewge1: Ah, right, I guess I was too subtle, ‘However, it's true that *we*’ above is nckx for ‘this is not good and should probably be fixed’ 😉
<nckx>And ‘probably’ is nckx for ‘’, sigh.
<nckx>I just don't want to tell others what to do if I don't do it myself.
<bricewge1>Now I understand it's using the same terminology "to sign", but the meaning is totally different.
<bricewge1>I would fix it myself but I don't if I could phrase it right.
<nckx>There's a whole other dimension to this which is the impedance mismatch between legal folks and folks who use the term ‘impedance mismatch’. We think in terms of ‘cryptographic crypto, zomg’, while the legal world is sometimes far more impressed by ‘we covered our asses in 3 different ways, look, we tried very hard, and have processes and precedent and (unsigned) records’. And they're not as wrong as ‘we’ might think they are. But that's a separate
<nckx> rant 😛
<bricewge1>civodul: Ok, so a commit will be rejected if it isn't signed but it won't reject it if the signature isn't authorized.
<bdju>can someone look at issue #37444 (patch to add aerc) and determine if it can be merged or not? it hasn't been touched since 2019 October it looks like, but no one commented about any problems left with it
<bdju>I had started trying to package aerc before knowing about this patch
<civodul>bricewge1: exactly
<arend>hello guys
<iyzsong>hello :3
<arend>can you use Sway with Guix?
<pinoaffe>arend: sway is packaged on guix, but I have not yet tried it out
<arend>guess I can try it out in a VM
<efraim>I believe most people use sway without a login manager
<arend>you mean like GDM?
<arend>GDM doesnt work on my system anyway
<bdju>yes, sway works. I use it
<arend>I prefer booting into terminal and then start the desktop environment manually hehe
<bdju>that's what I do, just boot to tty, then I login and run "exec sway" and I'm off to the races
<bdju>you need elogind and possibly dbus installed
<efraim>bdju: I took a quick peek at the patches, the concern is that they all seem to need a bit of work. commit message, synopsis/description, and of course checking the version number and license and making sure they build. And by concern I mean desire to return to it later
<bdju>efraim: darn. thanks for looking into it.
<bdju>I was kinda hoping it was good to go and just slipped through the cracks
<efraim>bdju: I put it on my todo list™
<bdju>thank you for that!
<NieDzejkob>efraim: also note that since the patches got posted, aerc released two major versions
<efraim>NieDzejkob: I figured as much. Normally when patches get dropped like that, if it's simple, i'll bump it on their behalf. if not I'll commit it as-is and then maybe bring it up to date
<jlicht>hey guix!
<brown121407>jlicht: hi!
*janneke runs update-guix-package and prays no-one pushes to master meanwhile
*janneke pushes most of wip-hurd-vm
<guix-vits>Do anyone know why neither `guix environment linux-libre ncurses`, nor `guix environment linux-libre --ad-hoc ncurses` give _me a working `make nconfig`? Only `guix environment linux-libre ncurses --ad-hoc ncurses` do the trick.
<iyzsong>missing 'pkg-config'?
<brown121407>Do any of you have problems with ccls not recognizing cin or cout as part of the std namespace? It seems to be working fine on Arch but not on Guix (I have this problem in both Emacs and neovim)
<guix-vits>iyzsong: Thanks, this indeed works: `guix environment linux-libre --ad-hoc ncurses pkg-config`
<guix-vits>brown121407: if this is a "Guix System" installation, do this persist restarting of the user session?
<brown121407>guix-vits: this is indeed a Guix System installation. I've had this problem for about a week now, been doing updates every couple of days, rebooting, nothing changed. Haven't restarted yet after todays update, will try a bit later
<butterypancake>I'm getting this error when running =make authenticate=. Did we recently change how that works? Do I have to do something manually?
<butterypancake>Git error: cannot locate remote-tracking branch 'keyring'
<butterypancake>nckx: when you removed the check phase from v4l2loopback, you didn't add '#:tests? #f'. I'd send a patch to debbugs but I don't know what the protocol is for sending patchs to closed issues, and I don't think this warrents a new issue
<guix-vits>Anyone else get 502 from
*guix-vits "that was not your bad" -> firehole@
<guix-vits>butterypancake: i just believe there was a conversation about keyring or something, near a week ago.
<civodul>janneke: wo0t!
<civodul>butterypancake: you now need to have a local 'keyring' branch tracking upstream's
*civodul just read on PHP governance
<civodul>interesting thoughts in there
<civodul>i wonder what lessons could be learned for Guix
<janneke>civodul: yeah!
<janneke>that was quite a journey...and we're only beginning, really :)
<arend>I wish Discord wasnt as popular and people used a freeër (lol) alternative instead FeelsBadMan
<mothacehe>janneke: just generated a Hurd image on top of master, isn't that wonderful!
<katco>discord and slack. i much prefer matrix.
<mothacehe>now trying without --no-grafts
<janneke>mothacehe: \o/
<mbakke>mothacehe, janneke: yay, congrats! \o/
<Kozo>janneke, mothacehe: Way to go!
***ztrawhcse is now known as elibrokeit
<civodul>janneke: yup, a long journey, but the result is really nice
<civodul>thanks for all the work!
<civodul>we should gather a herd of guix to party!
<apteryx>cbaines: I think I've successfully extendid the setuid-programs-service-type to allow configuring the ownership of setuid programs (uid/gid). This will effectively allow you to fix your sendmail issue with OpenSMTPD.
<efraim>can anyone spot what causes the segfault?
<apteryx>janneke: indeed, thanks for your efforts on the Hurd front!
<NieDzejkob>efraim: I doubt strace will tell you much about a segfault, try gdb instead
<rhou[m]>what is the guix equivalent of a dockerfile?
<efraim>NieDzejkob: Thanks. I'll add it to the vm i'm working in
<NieDzejkob>rhou[m]: Depends on what you want, but I'd say manifests are close
<rhou[m]><NieDzejkob "rhou: Depends on what you want, "> I want to be able to version it with a repository
<rhou[m]><rhou[m] "I want to be able to version it "> Instead of distributing a Docker image I will just distribute a reproducable Dockerfile
<cbaines>apteryx, cool, thanks, let me know if you want me to take a look at any patches :)
<apteryx>they'll be hitting guix-patches soon
*janneke apprecates all the warm comments and feelings for the hurd
<cbaines>rhou[m], I'm not sure there's a direct equivalent just using Guix, what are you trying to do though? If you want to distribute a Dockerfile, then you'll need a Dockerfile.
<guix-vits>rhou[m]: maybe `guix pack`? It is just "takes some packages" from your store and pack'em together. It also can produce a Docker image. (5.2 in manual). `guix pack -m MANIFEST` is aslo possible.
<cbaines>If you want to use Guix in that Dockerfile, you can, although that has some comprimises compared to using Guix to generate the Docker images directly.
<rhou[m]><cbaines "If you want to use Guix in that "> so you would recommand to generate the docker image directly from guix pack?
<cbaines>rhou[m], it really depends on what you want in the image?
<rhou[m]><cbaines "rhou, it really depends on what "> I have some build tools which I distribute for different platforms (windows, linux) via a docker image
<cbaines>rhou[m], if those build tools can be packaged as Guix packages, then guix pack should work for that
<leoprikler>+1 for guix pack
*guix-vits yay
<rhou[m]><cbaines "rhou, if those build tools can b"> and what do I version? the guix manifest, the dockerfile or both?
<leoprikler>if the dockerfile is autogenerated, you only have to version the guix manifest
<leoprikler>for distribution, you distribute the container
<rhou[m]><leoprikler "if the dockerfile is autogenerat"> does it makes sense to also pack my build dependencies via guix inside the docker?
<leoprikler>IIRC `guix pack` should give you the full closure, so you don't have to manually specify them
<rhou[m]><leoprikler "IIRC `guix pack` should give you"> what do you mean by manually specify them?
<civodul>rhou[m]: see :-)
<rhou[m]>where do I find documentation about the manifest file?
<ArneBab>I fixed my problem with guix pull: rm -rf ~/.cache/guix/checkouts/*; guix pull # works again
<mothacehe>janneke: I don't know if you noticed it, but Hurd image also build without "--no-grafts" thanks to recent civodul patch!
<janneke>mothacehe: that's great!!!! no, i didn't notice -- on the contrary, i may even have told civodul that patch set "didn't help" :-|
<MSavoritias>Hi. I've been using this command to upgrade guix on bare metal: guix pull && sudo guix system reconfigure /etc/config.scm
<MSavoritias>do i need to reconfigure every time? I remember I think that I couldn't upgrade gnome to 3.34 without the reconfigure
<MSavoritias>I have seen also the guix package -u. Is that needed too? because the manual doesnt mention it in Upgrading Guix
<MSavoritias>If I run only guix pull though do i update the root profile's packages ? or do I need to do sudo with pull
<leoprikler>you don't need sudo with pull
<leoprikler>you need to reconfigure for stuff like gnome 3.34, because that's installed system-wide
<janneke>mothacehe: i'm removing --no-grafts from the recipe
<ArneBab>MSavoritias: you can use guix upgrade instead of guix package -u
<MSavoritias>when do i need guix upgrade? Thanks leoprikler. Got it
<guix-vits>MSavoritias: in Guix there is a "system profile" and "the users profiles". The `upgrade` is for the latter.
<leoprikler>guix upgrade is for package in your user profile
<leoprikler>you need both of them from time to time
<leoprikler>to see what they'd do, just add --dry-run
<MSavoritias>so i should add guix upgrade or guix package -u after i do guix pull for updating?
*civodul is almost done with git-authenticate integration in "guix pull"
<ArneBab>MSavoritias: you need `guix pull && guix upgrade`
<guix-vits>MSavoritias: `guix pull` just updates the package definitions. It's all like the `apt update` & `apt upgrade` in Debian.
*janneke notices that their failing local substitute server make guix build appear to "hang"
<NieDzejkob>yeah - apt update = guix pull; apt upgrade = reconfigure, and then guix upgrade for per-user installed packages
<MSavoritias>ah ok.
<MSavoritias>and the package -u is more configurable right?
<MSavoritias>or it doesnt matter?
<ArneBab>guix upgrade only takes a single argument, guix package -u takes multiple. But if you just want to upgrade all, it doesn’t matter. (someone please correct me if I’m wrong)
<guix-vits>MSavoritias: for `guix` it is possible to use --help flag: `guix upgrade --help`, `guix package --help`, `guix system --help`... It'll show USAGE and the other fields.
<guix-vits>ArneBab: and according to this flag, `upgrade` takes a Regexp to operate on packageS.
<MSavoritias>didnt know that. im gonna dig around. Thanks for the pointers
<guix-vits>Hey-ho, Guix: why there is no /proc/config? I'd a small tr. with retriving a working .config from a linux-libre (`# guix build linux-libre --check; cp /tmp/guix-blah-linux-libre/.config PLACE`). Also i'd failed to use the L. Kernel scripts/extraxt-* to get the config from bzImage...
<janneke>guix-vits: you need to set config options: CONFIG_IKCONFIG=y, CONFIG_IKCONFIG_PROC=y
<janneke>linux does not include that by default
<mbakke>guix-vits: you can get the config from 'gnu/packages/aux-files/linux-libre/5.4-x86_64.conf' in the guix source tree
<bdju>anyone using the profanity xmpp client? as soon as I sign in, I get a zsh trace trap error and it crashes. I just installed it today
<guix-vits>Thanks janneke. Thanks mbakke.
<apteryx>cbaines: I just send the patches; added you in CC if you want to have a look!
<cbaines>apteryx, cool, thanks :)
<apteryx>cbaines: by the way, do you have experience with smtpctl? My understanding is that 'smtpctl encrypt some-string' should print the encrypted some-string, but it doesn't do that for some reason
<cbaines>apteryx, I don't unfortunately, I've only managed to muddle through looking at queues with it a few times
<apteryx>OK! No problem.
<apteryx>oh, about my suggestion in the mail, I think it could be moved to the service itself; I see that opensmtpd defines its own 'sendmail' as a symlink to smtpctl under its sbin/ directory.
<apteryx>or perhaps it'll just work, given that the smtpctl that the link points to will have the proper ownership
<apteryx>I think so, yes
<vagrantc>hrm. this misses a lot of things ... guix environment guix -- make authenticate
<vagrantc>No Guile development packages were found.
<vagrantc>oh, i snuck a --pure in there ... for added fun ...
*vagrantc vaguely recalls needing to add git and gnupg ... but guile? guile?
<lfam>How do I fix "Git error: cannot locate remote-tracking branch 'keyring'" while pushing? My list of Git branches includes 'remotes/origin/keyring
<lfam>Do I need to check it out locally or something?
<NieDzejkob>When I got that error, I created a local keyring branch that tracks origin/keyring and it went away
<vagrantc>oh yeah, the keyring branch.
<lfam>Yeah, that's working for me. Thanks for confirming there's not another way
<vagrantc>still ... somehow it thinks i don't have guile installed?
<lfam>Well, working more than before. Now it fails to push during configure with "./configure: line 7038: syntax error near unexpected token `3.0"
<lfam>And then "./configure: line 7038: `GUILE_PKG(3.0 2.2)'"
<lfam>I'm just going to disable the hook for now
*vagrantc wonders how well authenticate handles a rebase where history diverges
<NieDzejkob>weird, doesn't happen to me. Maybe try make clean?
<civodul>lfam: please report what the problem is, so we can work on a solution that works for everyone
<civodul>the hook is not supposed to break configure :-)
<lfam>It may not be the hook, it could be something else
<civodul>but, if it runs in an environment where some dependencies are missing, things can go wrong
<lfam>I can't run `make clean` if ./configure fails
<civodul>the error you get is because guile.m4 could not be found in ACLOCAL_PATH
<NieDzejkob>then git clean -Xf or something like that
<civodul>although normally "autoreconf" should error out instead of producing an invalid configure script
<NieDzejkob>actually, git clean -Xfd, I think
<vagrantc>civodul: "some dependencies are missing" i thought guix's strength was in handling dependencies :P
<civodul>true! :-)
<lfam>It's working now that I re-bootstrapped
<vagrantc>how do we know what dependencies for make authenticate?
<civodul>it's basically the dependencies of core Guix
<civodul>so guile-gcrypt and guile-git mostly
<vagrantc>civodul: no need for git or gnupg ?
<vagrantc>apparently i need to also run ./bootstrap ?
<civodul>you need to have a configured tree
<civodul>normally one only needs to run ./bootstrap once in their life
<civodul>given than configure & co. are automatically rebuilt as needed later on
<civodul>"normally" i guess
<vagrantc>i've had to re-run ./bootstrap innumerable times
<vagrantc>i've frequently found things break if i don't re-run ./bootstrap
<civodul>yeah, things related to translations can require that
<lfam>Bug report filed
<civodul>but i rarely have to run it myself
<civodul>maybe because i'm a believer ;-)
<vagrantc>maybe if i add a user civodul and build from there
<lfam>I also have to run ./bootstrap quite often these days. I figure it's because we have a lot of translations now
<civodul>vagrantc: that should automatically hide a few bugs and give better performance :-)
<lfam>Sorry if this has been reported but is returning 502 for me
<civodul>yeah, looking into it
<vagrantc>civodul: maybe this guile stuff would make sense to me too :)
<civodul>what makes you think it makes sense to me? :-)
*vagrantc feels the wisdom oozing
<civodul>to whom it may concern: the load on bayfront is dangerously high
<vagrantc>so 'make authenticate' depends on a guix built from source in a git checkout?
<civodul>there's an obvious chicken-and-egg issue
<civodul>if everything goes well, i may post the patch series to integrate that into "guix pull" tonight
<vagrantc>that's why we invented biosciences
<civodul>lfam & all: is back up!
<janneke>"<civodul> normally one only needs to run ./bootstrap once in their life" ... o, oh.../me possibly already spent some of their future life's allowances
<civodul>and we need a service for it
<civodul>heh :-)
<janneke>well, luckily you said "normally"
<civodul>i'm explaining the theory
<civodul>reality is much more boring
<vagrantc>in the plutonic ideal of guix
<vagrantc>well, this whole make authenticate dance is proving to be a challenge for me :/
<NieDzejkob>can't tell if plutonic is a typo or a fully intentional pun
<vagrantc>NieDzejkob: hah. meaning is interpreted by the observer
<ArneBab>guix-vits: I did not realize that upgrade takes a regex — thank you!
<vagrantc>janneke: so i've got linux-libre 5.7.x + 24 patches working on the pinebook pro
<janneke>vagrantc: sweet!
<NieDzejkob>vagrantc: ooh, quantum
<vagrantc>some of them are marked to the effect "hack ... do not mainline" ... so those probably shouldn't land in master
<janneke>i'm pondering about getting another one; dannym has mes for arm almost working
*vagrantc is really struggling to not get the mnt/reform
<vagrantc>the philosophy is solid, but the price tag is harsh
<vagrantc>janneke: shortly after i received my pinebook-pro they came out with a keyboard variant that would work better for me ...
<janneke>oh, i heard dustyweb about that ... and comparable in performance to the pbp, right?
<vagrantc>i'd guess a little slower
<janneke>vagrantc: do you have accelerated X running?
<vagrantc>it's basically only got the slow quad-core processors, not the fast dual-core+slow quad-cores that the pinebook-pro has
<vagrantc>janneke: not X ... but sway/wayland
<vagrantc>i *think* it's accelerated?
<vagrantc>looks like battery support landed in linux-next, too ...
<janneke>ah, now i'm completely out of my comfort zone -- does it run emacs? ... emacs-exwm?
<vagrantc>janneke: emacs-no-x runs fine ... never test anything else
<janneke>okay, fair enough
<janneke>i started X, a n d i t w a s v e r y v e r y s l o o o w
<vagrantc>janneke: i think since linux-libre 5.6.x it's been working fine ...
<vagrantc>but maybe that's wayland vs. X
<guix-vits>vagrantc: though emacs with x has pdf-tools, and "pdf-view-midnight-minor-mode" is good.
<janneke>could be, i know nothing about this, but i was going: "why would i want accelerated X?" ... and then starting emacs took well over a minute...
<janneke>but it could very well be something else...dunno :)
<vagrantc>janneke: so did your old pinebook-pro ever get back to working condition?
<janneke>no, i tried all kinds of mask mode tips that str1ngs's just dead
<janneke>oh well, i had some fun with the hurd
<apteryx>nckx: what was that mkpasswd or similar command you hinted me at?
<apteryx>even with the right gid, smtpctl encrypt still won't honor a command line passed argument (I suspect echo 'mypass' | smtpctl encrypt also doesn't, although I can't be sure)
<apteryx>I guess mkpasswd
<apteryx>ah, the bug I'm seing is this:
<bonz060>Hi guys. I'm trying to add some package on some channel under gn/packages/twint.scm <-- The package is called twint. I'm running: `env GUIX_PACKAGE_PATH=/home/saitama/projects/guix-bioinformatics /home/saitama/guix/pre-inst-env guix install twint -p ~/opt/genenetwork2 --fallback --dry-run` but I keep getting: `guix install: error: python-twint: unknown package`. The package definition if you want to have a look at it looks like:
<bonz060>When adding new package definitions, how do you test it out? Do you run it against a GUIX_PACKAGE_PATH? I'm afraid, for me, the hello world example in the docs wasn't clear enough in the sense that it never went beyond adding deps and showing how you add to say a channel.
<butterypancake>typo first line "gnu"
*apteryx pushes a fix for smtpctl
<bonz060>butterypancake: That's not a typo. Look it's a file under `gn`:
<bonz060>butterypancake: all package definitions in that channel start with `define-module (gn package <name>))`
<butterypancake>ok, I didn't say I was smart or knowledgable. I only have 3 packages under my belt :p
<barnet>Hi there, hope everyone is doing well :) im new to guix system and im very amazed about this project and the people behind it. I need some help, want to execute an sh. script but it doesnt works it says No such file or director. didnt find anything about it at web :(
<bonz060>butterypancake: that's ok. Thanks for offering to help though.
<butterypancake>so the arugment you pass to install is something that has been define-public'd. You didn't define anything called twint. You probably want to install python-twint?
<butterypancake>ls /bin
<butterypancake>doing ls /bin shows that only sh is installed. Most likely the shebang at the top of your sh script says something like #! /usr/bin/bash right?
<vagrantc>ouch, when you rebase, apparently 'make authenticate' has to start over from scratch :/
<vagrantc>the good news is 'make authenticate' is working for me
<butterypancake>The build system for guix doesn't seem to be amazing in my eyes. It's pretty average, but I wish it was as solid as emacs' build system
<butterypancake>so what is the appropriate shebang you're supposed to use on a guix system to get bash? It's like /usr/bin/env something right?
<tsmish[m]>bonz060: I use something like this for testing stuff, but I'm sure better way exists: guix package -e '(begin (load "file.scm") (@ (gn packages twint) python-twint))'.
<butterypancake>barnet: can you post the shebang from the sh script? It should be the first line and it'll look something like: #! /bin/sh
<codemac>all my guix fonst are broken right now :( has anyone seen this where all gui applications in <other os>+guix cannot load a font?
<codemac>same with icons as well.
<vagrantc>fonts are tricky ... 'fc-cache -rv' sometimes fixes it for me ... if i'm remembering correctly
<barnet>Hi @butterypancake ,its my first time that i dive in deep in gnu/linux. i tried to open the sh. script with text editor or geany but it says its not compatible... or text editor just freezes and does nothing
<guix-vits>barnet: Hi. What is exact error do you get?
<butterypancake>barnet: run: file "script file name" to see if it's actually a text file
<butterypancake>barnet: are you familiar with using a terminal?
<barnet>im a Beginner
<bonz060>butterypancake: same thing; installing `python-twint` brings up the same error.
<butterypancake>barnet: a beginner who know how to open a terminal and use the "ls" and "cd" commands?
<bonz060>tsmish[m]: thanks. That's really helpful. Now I'm getting: `error: failed to evaluate expression '(begin (load gn/packages/twint.scm) (@ (gn packages twint) python-geopy))':
<bonz060>Unbound variable: #{base32#:use-module}#`; I've tried installing packages from other places, but installing from `twint.scm` does not work and I have no idea why
<barnet>@butterypancake no.. xD i quess im on the wrong place with guix system if i cant master terminal :D but i really want to using linux since 5 years just superficial but after swtiching to gnu/linux it gets very interisting to dig deeper
<bonz060>barnet: not really. Think of it as an opportunity to grow and learn new stuff. See it a challenge IMHO
<butterypancake>barnet: Everyone was in your shoes at some point. I was in your shoes until after I start university. I would suggest watching some youtube videos on some basic terminal stuff. The terminal is a really useful tool.
<dustyweb>janneke: yes you probably heard about it from me
<dustyweb>I did order one and am excited about it
<barnet>@butterypancake well said, exactly i've tried the last weeks a bunch of gnu/linux distro to find the best distro for my needs and hardware xD im running on a beelink x55 with intel
<barnet>@butterypancake, yes about terminal its on my to do list how to vids,docs,etc you guys think about terminology as noob it just looks epic
<mbakke>vagrantc: perhaps we should hide the newer kernel variants that rely on the automatically generated config?
<janneke>hi dustyweb, be sure to share your experiences when you get it
<vagrantc>mbakke: weird. i thought i had handled that...
<vagrantc>e.g. there shouldn't be any kernels generated
<vagrantc>mbakke: i don't see linux-libre@5.6 or linux-libre@5.7
<mbakke>vagrantc: oh indeed, just the -headers and -arm-generic
<mbakke>nvm then :-)
<butterypancake>barnet: I mean ubuntu is a prefectly fine distro. If you're a free software fanatic (which we all are here) we'd suggest trisquel. Guix is sorta a baby in terms of distro's and it might no be great for begninners. Personally I used mint at first. Most linux's are pretty similar once you understand how they work under the hood. After a few months of Mint I switched to arch linux because I wanted a challenge. Arch linux doesn't
<butterypancake>tools for a lot of things so it's great for learning the terminal inside and out. I'm currently on Guix not because it's unique or offers me something other distros can't, but because I want to learn scheme. Honestly the distro doesn't matter much. Just focus on what you personally want to accomplish and learn the tools that will let you get there. You can do that on any distro.
<vagrantc>mbakke: i messed that up with @5.6 and reverted the part
<vagrantc>that said ... we really need someone who feels capable of reviewing the configs to get to a newer version ... or be happy with LTS kernels...
<vagrantc>that said, my local builds of linux-libre@5.7 on x86_64 resulted in some issue with graphics/drm and sway woul
<vagrantc>dn't run
<vagrantc>so i didn't push any x86_64 stuff :)
<mbakke>I've been considering submitting a config update for 5.7, but I really do not want to maintain the kernel packages :/
<guix-vits>What about using the Debian Kernels?
<vagrantc>mbakke: it's also extra difficult because it's configs for multiple architectures ...
<vagrantc>guix-vits: what do you mean? the config generated by debian?
<vagrantc>i think that's how armhf and arm64 kernel config was bootstrapped at some point, though it's diverged a lot since
<vagrantc>probably time to CC guix-devel on the request for help with kernel maintenance, though
<guix-vits>vagrantc: yes, and maybe, the "Debianized" sources from their repo? Funtoo do so afaik (though they aren't GNU distro).
<guix-vits>not that i'm understand the matter.
<bonz060>:tsmish[m] and :butterypancake thanks. I've been able to pinpoint my problem. I had a typo somewhere that really messed my --dry-run
<bonz060>butterypancake: you should checkout racket if you want to get deeper in that scheme universe
<vagrantc>guix-vits: the debianized sources wouldn't meet the FSDG
<vagrantc>the problem isn't really the sources; by and large linux-libre tooling takes care of that.
<vagrantc>mbakke: you could submit the kernel config update ... "just this once"
<vagrantc>anyways, emailed guix-devel about the kernel status...
<pushcx>dustyweb: Ah, hi to a familiar face. I ordered a Pinebook Pro a while ago, I want to try getting guix running on it. (I know other folks have already had at least partial success.)
<vagrantc>pushcx: there's the wip-pinebook-pro branch ... i'll update soonish with linux-libre 5.7.x
<mbakke>vagrantc: oh, great ... I'll consider submitting a general config update once I get around to updating my own kernel :P
<dustyweb>pushcx: ah cool :)
<dustyweb>hope it works
<NieDzejkob>hmm, would it be reasonable to use a grafted LLVM only for mesa, and use the fixed version directly for all other dependents?
<NieDzejkob>(I need to backport a fix for a miscompilation and it's the kind of bug you wouldn't want to wait around in c-u)
<pushcx>vagrantc: Oh neat, I'd only seen a blog post rather than a branch. Thanks for the pointer!
<vagrantc>pushcx: literally in the process of updating it right now :)
<pushcx>And sorry, I'm a total newbie, but: branch on what repo? :)
<codemac>vagrantc: fc-cache -rv didn't help :/ thanks though I appreciate it
<barnet>@butterypancake, first of all thank you so much for spending your time ^^, good point your probably right this step by step way is one of the efficient ways to get experience with gnu/linux. but honestly while running on guix i've learned way more then my years just being consuming my os like , ubuntu,opensuse,arch, so i will try to work as long i
<barnet>can with this gnu/linux so its like you said it depends on you which shoes does fit you the most :) and guix fits me very well hehe so you guys probaly going to see me here more often.
<barnet>but to get back to my question about execute an sh., so need to modify my sh. file
<barnet>thanks guys wish you an successful week
<nckx>apteryx: Just ‘mkpasswd’, confusingly provided by our ‘whois’ package.
*nckx suspects the hysterical raisins.
<nckx>butterypancake: I lost it when I rebased my modified version on top of your original after Brice had pushed it. It's fixed on master.
<apteryx>Has anyone success configuring OpenSMTPD with gmail?
<apteryx>It's blocking me on auth so far, after the TLS handshake passes (smtps on port 465 or smtp+tls on port 587 both work)
<mbakke>NieDzejkob: will LLVM 10 from 'staging' help?
<mbakke>and Mesa 20.0.7
<nckx>apteryx: Have you enabled ?
<nckx>‘Less secure’ = ‘not Google-controlled’.
<apteryx>ah, just figured it out! I had to use the label in the URI such as "smtp+tls://"
<NieDzejkob>mbakke: one of the two patches is included in LLVM 10
<apteryx>that label which I used in my /etc/smtpd/creds-relay table (it has the syntax: 'label username:password')
<mbakke>NieDzejkob: right, I think I misread your message, you mean the fix is important for most consumers, but not necessarily Mesa, right?
<apteryx>nckx: thanks for the help
*nckx did nothing but did so happily.
<mbakke>NieDzejkob: in any case LLVM can be patched freely as long as Mesa does not get affected, as you observed
<mbakke>it's OK for Mesa to have its own special variant
<NieDzejkob>mbakke: I mean, AFAIU, mesa only uses LLVM at runtime (to compile shaders?), while other packages are likely to use it at compile time
<NieDzejkob>anyway, thanks for your opinion on this!
<mbakke>note that Mesa on 'staging' uses LLVM 10, which complicates things :-)
<mbakke>it will likely be merged in a day or two
<mbakke>NieDzejkob: it would be good if you made LLVM 10 the default 'llvm' variable while you're at it ;-)
<NieDzejkob>a day or two? Sweet! I'll wait with that, then
<NieDzejkob>what about core-updates? Any timeline for that? (there are some patches I'd like to include in the cycle)