IRC channel logs


back to list of logs

<florhizome[m]>I can’t find it though
<singpolyma>florhizome[m]: what's the link?
<singpolyma>Oh, haha
<singpolyma>I've wanted something like that
<florhizome[m]>It’s supposed to be named guixrus
<florhizome[m]>Yeah me too
<florhizome[m]>like toysRus but for guix
<florhizome[m]>There is supposed to be a channel on libera too
<florhizome[m]>can’t find it either
*lfam deletes pre-core-updates-merge profile generations
<lfam>No turning back now!
*lfam needs disk space
<lfam>Ah, there is another 12 GB
<nckx>> guixrus
<nckx>Literally everyone: ah, the Russian Guix community channel.
<nckx>f1refly: It… shouldn't. What's your channels.scm?
<f1refly>nckx: I just removed it entirely for testing and am now running guix pull again
<f1refly>ran through now, I must've misconfigured a personal repo I guess? I'll try to re-add and run pull again
<nckx>Did you import (gnu packages instrumentation)?
<florhizome[m]><nckx> "Literally everyone: ah, the..." <- toys.rus?!
<singpolyma>Need the trademark infringing backwards R to really sell it ;)
<nckx>Guixяus — yah, Cyrillic is now trademark-infringing, welcome to hell.
<taterbase>I'm having a challenging issue, I've downloaded the guix package `emacs-w3m` but I'm not sure how to get emacs to load it. Using the require line in the w3m docs didn't work. Anyone here using emacs-w3m?
<vldn[m]>i3status-rust failed to installiert on cfcfda5 :(
<nckx>Oh nein.
<nckx>taterbase: You say ‘downloaded’ like you might not mean ‘installed’? How did you download/install it?
<unmatched-paren>florhizome[m]: that's ok, i might contribute my packages there and abandon my channel, actually...
<taterbase>nckx: I meant `guix package -i` however I just looked again and I installed w3m standalone not the emacs plugin DX
<vldn[m]>does it installiert for you nckx?
<vldn[m]>f*** autocorrect xD
<vldn[m]>error is "unbound variable %output"
<nckx>Sec, I'm already fixing it.
<vldn[m]>ty very much
<nckx>(Takes a sweet while to build… :-/)
<vldn[m]>lot of deps, true
<nckx>But the Rusty kind that get built during the package build itself.
<nckx>‘starting phase `install'’ — continues to compile MORE STUFF.
<nckx>It compiles (or claims to) the same thing multiple times as well.
<nckx>I'll give it the benefit of the doubt that it's necessary.
*nckx building it again.
<nckx>This package was either cargo-culted or machine-modified.
<vldn[m]>if its too much work then i'll Look Into it the next days :)
<vldn[m]>but maybe the error is obvious
<nckx>It was trivial, it's just the buildstest that takes forever :-/
<nckx>I didn't help, by missing a second occurence of %output the first time, but still :)
<nckx>‘Compiling’ in rust(-build-system) parlance means leaving my CPU idle for more than half of the time. That explains it, kind of.
<nckx>I wonder what that's about.
<nckx>vldn[m]: Finally done.
<vldn[m]>ah woop woop
<vldn[m]>can i pull it? or how long does the commit need?
<nckx>It's instant.
<nckx>For better or worse.
<vldn[m]>nice :) what do i need to modify in that case?
<vldn[m]>using quite a lot sway and Rust thingies
<vldn[m]>if i'm Stuck if a similiar error
<nckx>The variable %output is no longer bound, so you have to use (lambda* (#:key outputs #:allow-other-keys) (let* ((out (assoc-ref outputs "out")) (…)) (do stuff with out here, instead of %output))) instead.
<nckx>In this (odd) case both phases using %output actually already had (lambda* (#:key outputs #:allow-other-keys) …) in place — they just didn't use it.
<nckx>Hence my comment above.
<nckx>Maybe someone got distracted, or used an incomplete rewrite script, I have no idea.
<nckx>Or combined bits from different examples.
<vldn[m]>i think somebody let guix style run over the whole stack, maybe this? :D
<vldn[m]>but alright :)
<nckx>That's what I thought at first, but I don't think guix style does this.
<nckx>Anyway, in case the diff is more clear than my rambling story:
<nckx>resources → share is just me bikeshedding :)
<raghavgururajan>Does guix-defaults? in home-bash-configuration, add anything to .bash_profile?
<raghavgururajan>When guix creates home directory, what is its permission?
<raghavgururajan>700 or 755?
<lilyp>users don't have cross-home permissions unless you invite them
<KE0VVT>Has anybody tried to put Vorta <> on Guix?
<lilyp>no, but looking at the setup.cfg it does appear rather sane
<lilyp>this might be a good exercise to get started; there's at least one dependency that appears currently unpackaged, so you get to learn a bit
<KE0VVT>lilyp: I'm using "borg" alone, but a nice GUI would be nice.
<KE0VVT>Oh boy, I'm scared of packaging.
<lilyp>It could be worse.
<lilyp>You could be the complete nutcase that tries to keep Ren'py up to date.
<lilyp>Or do literally anything related to Node or Rust.
<mroh>KE0VVT: you can try this;a=blob;f=mroh/guix/packages/python.scm;h=f4c0817221b6b8c53047b27bf8a2820e16ed5dde;hb=HEAD#l654 as a starting point. Might need some license and test work... ;)
***sneek_ is now known as sneek
<nckx>Nobody's asked us ☹
<mroh>oO, gimp was the beginning of gtk... not even sure if java exsisted at that time...
<nckx>To be fair, this is where we are now.
<nckx>_addpoint mroh for remembering GTK means the GIMP tool kit.
<nckx>Let us race pigeons and do other old person things together.
<nckx>The GIMP is not this, but I wonder how many obscure projects are using ‘we're not vulnerable to log4j’ blog posts as a way to surf the news cycle to get attention.
<podiki[m]>speaking of borg, there was a patch for borgmatic, wonder if it got merged...
<podiki[m]>oh nice it did
<spk121>nckx: guile-ncurses is not vulnerable to log4j!
<mroh>I guess, the java world now learns what jndi really means... I wonder where there were if B.Joy would had more success with jini instead...
<mroh>ok, this is like ;)
<mroh>"guix package: package 'widelands' has been superseded by 'widelands'", huh?
<podiki[m]>anyone familiar with the whole rsvg thing and how it works
<podiki[m]>syncthing-gtk error
<nckx>mroh: Implementation detail to force upgrade from version 21 to 1.0.
<mroh>live is to short to support rust packages ;)
<mroh>nckx: ah, ty!
<podiki[m]>I don't have interest in the rust, but the breakage it caused in another (python) package
<singpolyma>What's the best way to get a custom helper procedure inside a build phase?
<mroh>podiki: I can reproduce this. You are right, maybe it's a python problem.
<taterbase>are there docs for creating a clean guix inside of an existing guix install? I'm thinking almost like a chroot in debian?
<singpolyma>taterbase: probably you want guix shell?
<taterbase>oh perhaps! Thank you singpolyma
<taterbase>I'm trying to recreate the steps I went through when building a library and I was really hacking it together there for a while and want to make sure all the steps I did were necessary
<taterbase>singpolyma: are you referencing the guix environment command?
<singpolyma>taterbase: that command is deprecated and replaced by guix shell command
<taterbase>ah thank you!
<taterbase> are these docs out of date then?
<podiki[m]>taterbase: use the "devel" manual
*vagrantc almost wonders if the non-devel manual is actually a service to the community
<podiki[m]>a source of confusion we need to clear up, but "devel" here just means current guix, e.g. what you are running (the "stable" version matches the 1.3.0 installer but that is out of date except on the installer media)
<vagrantc>unless you only use release versions and never run guix pull, it's guaranteed to be out of date
<taterbase>oh... are the docs available locally on my machine?
<taterbase>(sorry still learning)
<podiki[m]>we were discussing here the other day, perhaps best to just get rid of "stable" almost entirely
<podiki[m]>yes, "info guix"
<podiki[m]>will match exactly the guix version you have installed
<taterbase>Thank you!
<podiki[m]>most welcome 🥔base
<KE0VVT>singpolyma: Gajim gives me an error when I try to run it.
***ChanServ sets mode: +o nckx
***nckx sets mode: +b $a:betelgeus$##fix-your-connection
***nckx sets mode: -b *!*betelgeus@*
***ChanServ sets mode: -o nckx
<singpolyma>KE0VVT: installed from guix or host? You're on foreign yes?
***ChanServ sets mode: +o nckx
***nckx sets mode: +b $a:betelgeus*$##fix-your-connection
***betelgeuse9 was kicked by nckx (betelgeuse9)
<nckx>Whelp, I managed to break Guix:
<apteryx>is... /gnu/store actually gone?
<nckx>No no!
<nckx>Sorry for making that sound worse than it is.
<nckx>Guix is just confused? I certainly am.
<nckx>It's what happens when I accidentally quote a gexp, for whatever reason.
<nckx>No, an ungexp. #~(stuff '#$thing etc)
<nckx>Glad it's not obvious to others either.
***nckx sets mode: -b $a:betelgeus$##fix-your-connection
<the_tubular>So, I successfully installed debian without problems ...
<the_tubular>So hardware problems are out of the way
<the_tubular>I gave it the hostname : wishthiswasguix
<the_tubular>But I'm probably gonna stick with debian as it's my 4th day in a row trying to install guix and I give up
<nckx>Actually it happens when I ungexp an alist, full stop.
<KE0VVT>singpolyma on foreign
<nckx>the_tubular: 4 days is too long for anything. Better luck next time.
<KE0VVT>singpolyma: lrwxrwxrwx. 6 root root 65 Dec 31 1969 /home/caleb/.guix-profile/bin/gajim -> /gnu/store/jf529bzcws11pl9ibgj8qv45dd17sgcy-gajim-1.3.1/bin/gajim*
<the_tubular>Yeah... nckx feels like wasted time
<the_tubular>Sad cause I really like guix
<the_tubular>And I know guix on top of debian is not what guix should be
<KE0VVT>the_tubular: I'm using foreign Guix.
<nckx>I wasn't around for the last day, but unless you made much progress, staring at a failed boot screen is also not what Guix is supposed to be.
<nckx>Nobody can say you didn't try.
<the_tubular>Sorry, I'm not understanding your first sentence nckx
<the_tubular>Also, congratz for the promotion :P
<the_tubular>But I didn't make much progress, solved the network issue, and then ran into 6-7-8 more issues, that I could / could not reproduce
<the_tubular>apteryx suggested it was maybe hardware failure, so i decided to install debian, see if it was working, which it did ...
<apteryx>the_tubular: now you must have the itch to 'guix system init' on top of debian as someone suggested yesterday ;-)
<apteryx>but perhaps better rest first :-)
<the_tubular>i installed debian on my "main" disks
<the_tubular>disk *
<the_tubular>So guix system init won't work right .. ?
<the_tubular>Whatever I'm done for a while, I'll wait a few weeks, and maybe test 1.4.0
<nckx>the_tubular: Just that ‘guix on top of debian is not what guix should be’ → neither is what you went through, so at some point you have to say ‘well this ain't it’ and cut your losses.
<nckx>the_tubular: Promotion?
<the_tubular>I can't loose 3-4 more days banging my head on a brick wall again ...
<nckx>Nobody here wants that!
<nckx>We're shameless Guix pushers but only if it's fun consensual fun.
<the_tubular>The "@" in front of your name is channel admin no ?
<nckx>Oh, oops.
***ChanServ sets mode: -o nckx
*nckx was taking care of some admin.
<the_tubular>Ohh :(
<the_tubular>Sorry for the demotion then
<nckx>I cannot imagine a channel in less need of badge-flashing ops than #guix.
<the_tubular>Will there be any improvement on the installer on 1.4.0 ?
<the_tubular>If so, I'll probably test it again
<the_tubular>I'm still pretty disappointed at myself though
<nckx><Will there be> I hope so, and I think your public misadventures here the past week convinced not only me that there needs to be more bare-metal installer testing by real humans before the next release.
<nckx>the_tubular: Not going to tell you how to feel but I see no reason why you should be disappointed in *yourself*…
<the_tubular>I mean, been using linux for "a few years" now and not being able to install something that should be pretty "hand holding" is hard on the morale
<nckx>Guix is still very far from being Debian or ‘even’ {Arch,Gentoo,your favourite cool kid distro here} as far as installation robustness, testing, and polish go.
<nckx>I would not call it hand-holding despite the installer UI.
<kittyblam>I've had better experience than those by far
<nckx>Oh, same here, pre-installer days even.
<the_tubular>When was the installer added ?
<nckx>But it's not like there aren't crocodiles left & right of the path, and if something (like quirky firmware or pre-existing partitions) push you even slightly off the expected path, the results are messier than they ought to be.
<mroh>the_tubular: You might run both, debian and guix on different partitions (or volumes). I also have a debian grub.cfg which includes the guix (and gentoo,arch etc) partition/boot stuff...
<nckx>the_tubular: Around November 2018.
<the_tubular>Sure, but I can't install guix...
<kittyblam>ynkow, talking about the installer reminds me
<the_tubular>Anyway, I'll stay updated with Guix, it's such an interesting project. But It's also important to realize that if I can't install it, it probably turned down a few people befoire me ...
<nckx>We know.
<nckx>(Which was not meant to sound dismissive.)
<kittyblam>I should clean up my config.scm and clean up that yafaray.scm I made a while back and get that into the guix repository lmao
<the_tubular>Also, just to close the book on my case, what was with all that nvram stuff that has no space left ?
<the_tubular>What I'm trying to say, is ; is this a real problem that I'm having ?
<the_tubular>That's what the guix installer told me, but I installed debian without erorrs, so it had to write to NVRAM right ?
<nckx>I'm not sure. I get the feeling that Guix's copy/build/version (but how?) of efibootmgr and/or GRUB is somehow more fussy or sensitive to this issue.
<mroh>the_tubular: maybe, you can try installing guix under debian and then something like`guix init /mnt/myGuixPartition`, chmod there, guix reconfigure, add it to grub.cfg, so you don't need the installer...
<nckx>It's true that Guix installs GRUB more frequently than most other distributions, because it happens at each system reconfiguration IIUC, but it's not like even you got that far.
<nckx>But I don't have any UEFI machines left to play with.
<the_tubular>To be honest mroh, there are some pretty important services that I want up on this box, so yeah, I'm done with testing stuff on baremetal on this machine for a while
<nckx>You can disable Guix's GRUB installation completely and use a pre-existing or otherwise installed GRUB.
<the_tubular>Yeah... As I said above, I want that box up... :/
<the_tubular>No time for testing anymore
<the_tubular>I might test in a VM, but I feel it's going to be easier
<the_tubular>I might have an SSD laying around, maybe I'll give it another try. I'll see.. But this week was pretty brutal
<mroh>the number of git stashes always goes in the same direction as the number of browser tabs: to ♾️
<the_tubular>Also, what's confusing me is that guix system reconfigure would trhow the same NVRAM error the installer did ...
<the_tubular>Eariler when I had guix working
<zamfofex>Hello everyone! If I hold “ctrl‐c” on a VT, eventually it breaks and stops allowing me to login from it (until I reboot). I think that’s the fault of ‘mingetty’. Is there any way to resolve that? Would it be worthwhile to move away from ‘mingetty’? It seems the latest release for it was in 2008.
<nckx>Bug reports like these are wild rides that somehow leave you just where you started:
<nckx>zamfofex: Definitely worth a bug report.
<nckx>Reminds me of that GRUB bug where you could bypass the password prompt by holding Esc (if not as bad by far, it's still a nasty DoS).
<nckx>the_tubular: My only regret is not knowing that -v -v apparently prints a trace, although it remains to be seen how useful that is in practice.
*apteryx enabled compression for debug symbols gtk+@2: from 28 to 12 MiB. Not bad!
<podiki[m]>the_tubular: sorry it didn't go your way!
<podiki[m]>just to throw in another suggestion, you can play with guix as a package manager and in a vm, and with a vm when you have a system config you like you can use that pretty directly on bare metal in the future
<podiki[m]>so you can play with all the config stuff and hit the ground running in the (not so distant I hope!) future
<the_tubular>That's pretty much what I wanted to do
<the_tubular>But my system config is starting to bit a bit complicated
<the_tubular>So I wanted to start with the official installer so I get something that I know works
<podiki[m]>or, also cool, use the config as a live image, not quite bare metal but also similar
<apteryx>there are a couple of cross-compilation traps in our grub package
<apteryx>(member (or (%current-target-system) (%current-system)) (package-supported-systems lvm2))
<apteryx>%current-target-system in Guix is a GNU triplet wile %current-system is a Nix system (confusing, I know).
<apteryx>while supported-systems are Nix systems
<apteryx>so the conditions will never be true for cross-compilation, ad many inputs will be missing.
<bdju>lfam: thanks!
<sneek>bdju, you have 1 message!
<sneek>bdju, lfam says: I fixed barcode
<bdju> looks like bpytop is failing to build now
<lfam>Has anyone tried using `guix system image` with an X window server lately? For me, the image boots but then X seems to never start. There's just a cursor blinking on the screen
<lfam>Or even `guix system vm`
<mroh>bdju: simple one line hack/fix:
<AIM[m]>Doesn't Xfce version of guix come with bluetooth?
<AIM[m]>Do I have to add packages for it?
<bdju>mroh: nice. if it's a known/solved issue then I'll just skip upgrading it for now in the meantime
<AIM[m]>Anyone uses Bluetooth on your guix installation?
<mroh>lfam: Are the VT/tty's coming up? (ALT-cursorR/L in qemu)
<mroh>I used some images, I think 2 days ago, but w/ gdm or sddm, not plain X11.
<mroh>AIM: yes, I use bluetooth (on my laptop).
<lfam>Thanks mroh
<lfam>The other TTYs are up
<lfam>It's weird, neither of the desktop templates work for me
<bdju> buku has failed to build now
<mroh>AIM: I installed "bluez bluez-alsa blueman" in my system configuration. I dont think xfce pulls any of them.
<lfam>Ah, I'm hitting #52051 now
<AIM[m]>mroh: Thanks, I'll check that then
<mroh>lfam: in a vm? \o/ that would be great!
<lfam>No, on bare metal now
<lfam>I don't know what was wrong in the VM. That's why I switched to bare metal
<mroh>you're on HDD?
<the_tubular>Authenticating channel 'guix', commits 9edb3f6 to 2607ff0 (28,807 new commits)...
<the_tubular>First guix pull on Debian
<lfam>mroh: Yes
<the_tubular>Annnnd it crashed :(
<the_tubular>Just my luck striking again
<mroh>`guix pull` crashed?
<the_tubular>Yep ...
<mala>the_tubular, that's *really* weird (I'm using that checkout on debian as we speak). Where did you get the inital guix installation? Debian package?
<mala>is this the same server as you've been messing with before?
<the_tubular>Everything weird happens to me apparently ...
<mala>how much RAM does it have? (I'm clutching at straws here...)
<the_tubular>You think the problem is hardware related ?
<lfam>That bug has been reported upstream (Debian):
<the_tubular>Ohh nice find lfam
<the_tubular>That's also very recent
<mala>oh phew
<mala>i guess this is maybe more core-update growing pains
<the_tubular>I mean, I must have found a lot of those lol
<lfam>Did you ever figure out why your networking wasn't working?
<the_tubular>This one I did
<lfam>What was wrong?
<the_tubular>Remember the interface I did not recognize ?
<the_tubular>I guess it was starting first and this interface routed traffic
<the_tubular>When I shut it down, it all went good
<the_tubular>Does that make sense ?
<the_tubular>Also I'm pretty sure the interface was Idrac
<the_tubular>debian sees it as "Idrac", guix showed something like enp0s26...
<lfam>I wonder how they identify it
<lfam>So, the routing was not set up right?
<the_tubular>That's my best guess
<efraim>hello guix!
<the_tubular>I had an IP address with my working interface
<the_tubular>But no traffic could go through it
<mroh>maybe, the debian installer runs ipmitool somehow:
<the_tubular>Could be it
<the_tubular>I don't know much about debian, I installed it just to test if my problem was hardware related
<the_tubular>But it's Debian 11
<raghavgururajan>Phew! Finally published everything I had/have,
<mroh>I think, this machine is really complex... we should at least package ...
<florhizome[m]><raghavgururajan> "Phew! Finally published everythi..." <- Hope i will push some stuff to guixrus today :)
<raghavgururajan>flatwhatson: That'd be great. :)
<unmatched-paren>i've heard that systemd is way faster than the other init systems, but guix boots way, way faster than any other os i've used
<unmatched-paren>debian and ubuntu would take maybe 5-10 seconds, but guix takes about 0.5-3
<unmatched-paren>i guess plymouth might have slowed it down a bit
<unmatched-paren>and there may have been more services on debian/ubuntu than i currently have enabled on guix
<unmatched-paren>i like being able to know *exactly* what's on my system :)
<jpoiret>systemd is fast? Maybe that was the original plan but they keep adding layers upon layers of unrelated features to it, so it's kinda expected that it would take a long time to boot
<unmatched-paren>apparently since it doesn't use shell scripts all the time like openrc and init do, it's faster than them; that was the idea at least, from what i've heard
<florhizome[m]>unmatched-paren: did you see my message about guixrus/wayfire?
<unmatched-paren>florhizome[m]: yep, that was ok :)
<unmatched-paren>you have absolutely no obligation to put your package in any one particular channel, whether it be guixrus, paren or guix itself
<florhizome[m]>cool :)
<florhizome[m]>ofc you might use the Channel, too ;)
<unmatched-paren>actually, what's the email address that i can send guixrus patches to? i've never used srht before
<florhizome[m]>uhm you have to ask jgart ..
<florhizome[m]>When i try i can Tell you :D
<florhizome[m]>I actually Just built wayfire + wf-shell with and without the sanitizer argument and i'm Sure your Problems stem from it.
<unmatched-paren>"shell scripts" <- of course, shepherd doesn't use shell scripts either
<unmatched-paren>florhizome[m]: yep, but with it you need to set an environment variable
<florhizome[m]>pretty sure there is a doc on
<unmatched-paren>i made a number of improvements to your wayfire.scm in my channel (new style inputs, formatting), so you can use that if you like
<florhizome[m]>yeah Just leave it off
<florhizome[m]>scrap it
<unmatched-paren>btw, you know how you wrapped it in a shell script?
<florhizome[m]>I tried to told you before
<florhizome[m]>don't sanitize
<florhizome[m]>be dirty
<unmatched-paren>well, without it, it crashes, and with it, it crashes, and with the environment variable, all of them work except wf-background
<florhizome[m]>Oh really?
<florhizome[m]>Thats really weird
<florhizome[m]>There already ist a wrapper script
<unmatched-paren>guix has a way more elegant way to wrap stuff, you'll be pleased to know
<florhizome[m]>It runs when you login to wayfire-run
<florhizome[m]>I know but this works for now :D
<florhizome[m]>Or i don't know exactly
<unmatched-paren>the built-in wrapper makes the actual elf binary <name>.real, and wraps it in a shell script <name>
<unmatched-paren>much cleaner
<unmatched-paren>i'll just search through the guix source for an example, one second...
<florhizome[m]>but i know it's possible
<florhizome[m]>wrap-program or wrap-script
<unmatched-paren>ok, i'll ripgrep for wrap-program then...
<florhizome[m]>so you are building wayfire with sanitizer or all?
<unmatched-paren>well, it breaks if i don't use it, but it works if i use it with the variable, so sanitizer it is -.o.-
<florhizome[m]>For me it started working when i started building wfconfig directly with it
<florhizome[m]>No: are you using the Argument for all packages or only wayfire?
<unmatched-paren>only wayfire
<florhizome[m]>and ist the build breaking or at runtime?
<unmatched-paren>at runtime
<florhizome[m]>Do you unset the ASAN env var when running unsanitized WF?
<unmatched-paren>no, i have to set some kind of ignore var to get it to work when it's sanitized
<unmatched-paren>ok, i'll try installing with the option on wf-config
<florhizome[m]>so you didn't try not sanitizing anything and Not setting ASAN.. variable?
<florhizome[m]>you haven't disbaled it afaik
<unmatched-paren>i didn't know there was an asan variable... what's it called?
<florhizome[m]>you Said you need to Set some env var to make WF Shell Work when running wayfire when you built IT with the Adresse sanitizer option
<unmatched-paren>yes, to disable a check
<florhizome[m]>ok but you set it just for those programs then? not globally?
<florhizome[m]>I'm just pretty sure you shouldn't need it and it just complicates stuff further.
<unmatched-paren>without asan: ==5280==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
<florhizome[m]>It's just a random leftover from problems I had that were fixed when building wfconfig with wf directly.
<florhizome[m]>Yeah bc wayfire is sanitized and the other programs are linking to it. That makes sense.
<unmatched-paren>ah! anyway, wf-shell is unnecessary imo, there's already swaybg and some nicer shells that we could try to get working, like nwg
<florhizome[m]>but every plugin will have this problem I think^^
<unmatched-paren>right, ok
<unmatched-paren>well, i'll just remove the asan argument from wayfire
<unmatched-paren>do i add one to wf-config or...?
<florhizome[m]>or we can't exclude it.
<florhizome[m]>dare it one more time D:
<jpoiret>unmatched-paren: nwg is in go
<unmatched-paren>ok :) i'll git push and guix pull...
<unmatched-paren>jpoiret: yes, we know :(
<florhizome[m]>Don't sanitize anything in wayfire.scm. it doesn't get COVID ;)
<unmatched-paren>florhizome[m]: gah, i was waiting for the opportunity to make that joke! :)
<florhizome[m]>i think the panel is python
<florhizome[m]>There is also wapanel
<florhizome[m]>do you have wayfire in your config.scm or do you just try it from the commandline for now?
<unmatched-paren>i switch into tty2 from gnome to test it rn
<florhizome[m]>or system config
<unmatched-paren>i just have it in my user profile for now, until i can customize it enough that it is comfortable to use instead of gnome
<unmatched-paren>i'm just wrestling with my config right now so that i can update wayfire (a bunch of packages are failing to build)
<unmatched-paren>\o/ they all work now :)
<florhizome[m]>Do you run it with the script?
<florhizome[m]>try dbus-run-session wayfire or dbus-run-session
<florhizome[m]>Idk why it would crash without that though
<unmatched-paren>wayfire itself doesn't crash, wf-shell does
<unmatched-paren>one moment, just going to test the updated stuff on the tty
<florhizome[m]>i thought wayfire crashes when not built with sanitized argument
<unmatche1-paren>hello! this is wayfire me :)
<unmatche1-paren>everything is working now \o/
<unmatche1-paren>thanks, florhizome[m]
<florhizome[m]>I'm glad :)
<unmatched-paren>ok, i'm going to try to get nwg working, wish me luck >:)
***unmatche1-paren is now known as unmatched-paren
<unmatched-paren>does guile's (dynamic-link) not work in guix? i'm trying to play about with its FFI as described in, but (dynamic-link "libwayland-client") doesn't work (No such file or directory) even though i have it installed according to `pkg-config --libs wayland-client`
<unmatched-paren>ok, looks like i have to run it with LD_LIBRARY_PATH=blah
<unmatched-paren>ok it works now disregard the above
<NicholasvonKlitz>I'm currently trying to update librsvg to 2.52.5 (including it's dependencies: freetype, harfbuzz, etc.). I updated all the package definitions. However, when now trying to build the new librsvg, it is compiling llvm, rust, and a few other packages from scratch, rather than using available subsitutes. As a result, my computer ran out of memory and crashed :O ... Any ideas what this might be?
<NicholasvonKlitz>Even more weird is the fact that is compiled 2 different version of llvm as well
<NicholasvonKlitz> It also seems to depends on 15 different version of rust?
<nckx>NicholasvonKlitz: All Rust packages do, that's the bootstrap chain.
<nckx>It would be so nice if guix weather accepted .drv arguments directly.
<nckx>NicholasvonKlitz: What does ‘guix weather rust@1.54’ say?
<nckx>It's ‘100.0% substitutes available (3 out of 3)’ here.
<NicholasvonKlitz>0% available
<nckx>I assume your Guix is outdated, or you've somehow modified the Rust derivation.
<nckx>Try pulling.
<nckx>Or git pulling, depending on how you're working here.
<NicholasvonKlitz>I definitely didnt modify the rust derivation. I actually currently working off c-u-f because master wouldn't build on my system. Could that be the reason?
<nckx>c-u-f is obsolete and no longer exists upstream.
<nckx>It's old code.
<nckx>It was merged into master about a week ago.
<NicholasvonKlitz>oh... I'll try and migrate my patches and see if it will build now. Random packages seemed to be giving me errors when I tried to `make`
<nckx>berlin unexpectedly went down around that time (it was an exciting time!) and might not have full historical substitute coverage.
<nckx>NicholasvonKlitz: I've been running off master since the merge, but then I didn't have problems before it either.
<f1refly>I recenty updated my kernel (last working version was the 14th, broken one started with 16th). My laptop is running with coreboot, and I suspect the recent inclusion of coreboot-framebuffer support may have something to do with this. Unfortunately I'm currently using the non completely free linux kernel since I couldn't get my hands on a compatible wifi card yet, so this could explain why this change
<f1refly>may have reached me later than others. Is there anything I have to consider in my coreboot config to get linux to play along? my error behaviour is a blank screen with some green artifacts, so i strongly suspect it's got to do with the change in question.
<f1refly>(I'm not asking for support for my unsupported setup, only if any coreboot users had similiar experiences)
<NicholasvonKlitz><nckx> "Nicholas von Klitzing: I've been..." <- yay master compiles now
<rekado_>weird: ’guix deploy’ to the aarch64 nodes builds glibc 2.31…?
<florhizome[m]>Might be part of the mes bootstrap
<nckx>f1refly: If you're not using linux-libre, I don't understand how you're affected by its configuration?
<nckx>NicholasvonKlitz: Yay!
<nckx>f1refly: I use coreboot, and vanilla Linux: the changes I made to linux-libre were actually based on mine.
<efraim>rekado_: it's always current glibc and the prevously used glibc, in case user profiles haven't been updated
<nckx>f1refly: Do you use native gfxinit?
<f1refly>nckx: "# CONFIG_MAINBOARD_HAS_LIBGFXINIT is not set"
<f1refly>from my coreboot .config
<f1refly>I'm currently installing the gcc-toolchain to actually launch make configure
<nckx>OK, that might complicate matters for testing here (no proprietary blob, native gfxinit only). I'll reconfigure with linux-libre & see if anything new happens.
<f1refly>is there a metapackage like gcc-toolchain to install the various autotools?
<f1refly>nckx: I'm willing to reconfigure, I just need to set up the build tools first
<nckx>Autotools to me are just auto{conf,make}?
<nckx>So, no.
<nckx>f1refly: What will you reconfigure to?
<rekado_>efraim: ah, I see.
<f1refly>arch has a group called like base-devel, so I wondered if something similar exists on guix
<f1refly>nckx: I'll try setting it to native gfxinit
<nckx>Oh, OK. Whatever you're comfortable with.
*nckx reboots to test.
*nckx had forgot that Linux removed VT scrollback and defaults to a huge 8x16 font that wastes screen space. Great combo.
<vivien>autoconf, autoconf-archive, libtool, automake and gettext should give you a good starting point :)
<nckx>f1refly: So, ‘unfortunately’, my kernel displays the Guile rescue prompt just fine.
<nckx>s/my kernel/my linux-libre/
<nckx>It can't go further because linux-libre can't mount my root file system, so I can't test the transition to i915 this way. I booted a USB installer to test that, and will try again, but will need to find a USB first.
<nckx>f1refly: Does the garbling happen immediately after the GRUB → Linux transition, or does the kernel print anything readable before it happens?
<f1refly>nckx: it happens during kernel module loading (or immediately after it). I can decrypt my root volume with grub fine and see linux starting. I already asked for help in the channel and worked down to pinning an earlier linux version (that still worked), but the build failed because it couldn't find the kernel module "framebuffer_coreboot"
<f1refly>honestly I might try just reinstalling, fortunately it's not a pain with guix and I feel like I might have messed up somehow
<tissevert>hi guix
<nckx>Is this an i915ish system?
<nckx>f1refly: Reinstalling doesn't tend to fix things though.
<nckx>Hi tissevert.
<f1refly>intel sandybridge x64 using integrated graphics
<f1refly>a lenovo thinkpad x220 :)
<f1refly>nckx: it might if I somehow broke something in /gnu
<f1refly>(which i didnt fiddle with afaik but you never know?)
<rekado_>f1refly: guix gc --verify=repair,contents
<rekado_>that will fix broken things in /gnu
<f1refly>running it now, going to eat while it's doing it's thing
<nckx>f1refly: I just don't think that's likely and a reinstall will not be able to roll back. Something to keep in mind.
<f1refly>yes, you're right
<nckx>This is an X230T (Ivy Bridge) so very similar. Odd. Sadly, I don't have access to USB storage here (not at home) and I'm not going to reformat my swap or anything silly like that just yet.
<nckx>I just hope there's a way to make the CB and i915 framebuffers play nicely, because the CB ‘support’ fixed a real bug too :-/
<f1refly>i'd potentially have enough storage to just set up a new guix beside the one I'm writing this from just for testing without deleting this
<f1refly>I can feel your pain of never having enough flash drives around to do the job at hand
<nckx>Yes, this is obviously not a geek home.
<f1refly>i always have two seperate usb drives on my keychain just in case :)
<nckx>Phuh. Organised people.
<f1refly>so the gc operation didn't report any broken packages
<f1refly>(unfortunately, kind of?)
<nckx>I'll keep an eye on your progress here and will try myself this evening (Eurotime). The patch was tested quite a while ago. Something might've broken.
<f1refly>I'm at CET as well
<nckx>This has all the hallmarks of a kernel bug but it's our problem :-/ Sigh. TTYL.
<unmatched-paren>to get rid of the (target) deprecation warning, i need to change (target "/boot/efi") to (targets (list "/boot/efi")) in the bootloader configuration, right? i just want to be sure before touching anything grub-related
<unmatched-paren>(why would you want multiple bootloader targets, anyway?)
<mothacehe> unmatched-paren: yes correct
<notmaximed>unmatched-paren: it was for RAID setups, I think?
<rekado_>nckx: thanks for pointing me to the fix for my blank screen during early booting! Adding i915 to the initrd-modules made all the differencee.
<unmatched-paren>florhizome[m]: i've added wayfire to my system config so i can use it with gdm, but it seems to crash when i launch it from there. have you experienced this?
<yewscion>Good Morning, Guix!
<unmatched-paren>sneek: later tell florhizome[m]: i added wayfire to my system onfig but it crashed when i tried to launch it from gdm, have you experienced this?
<sneek>Got it.
<unmatched-paren>sneek: botsnack
<florhizome[m]>unmatched-paren: I haven’t tried out gdm, still using sddm. Although gdm is supposed to work now with wayland. Have you tried from the tty again?
<sneek>Welcome back florhizome[m], you have 1 message!
<sneek>florhizome[m], unmatched-paren says: i added wayfire to my system onfig but it crashed when i tried to launch it from gdm, have you experienced this?
<unmatched-paren>florhizome[m]: it works from the tty, but not from gdm
<unmatched-paren>one second, i'll try looking at the log
<florhizome[m]>maybe you have to look at the intricacies of gdm service, might need to enable wayland there
<kwjc>that is correct
<unmatched-paren>i've enabled wayland already to be able to use gnome-wayland
<kwjc>do you have any *.desktop files somewhere in your system? I think gdm is honoring any *.desktop files before anything else. if the two conflict, it won't load xorg
<unmatched-paren>wayfire is a wayland compositor, not an xorg window manager
<unmatched-paren>how would two seperate sessions 'conflict', anyway?
<f1refly>I found, which might be related to my case. I tried to use a known good linux version that (r)didn't
<f1refly>(presumably) didn't include the coreboot framebuffer module in question, so I now cannot build the old pinned kernel because the running system think it wants it?
<lilyp>f1refly: what's the error you're getting?
<nckx>f1refly: It's not that, it's that the module is now added to ‘%base-initrd-modules’ by default.
<nckx>You need to (fold delete %base-initrd-modules (list "the_new" "modules")) rather than use it verbatim.
<f1refly>yes, that makes more sense. the new module can't be loaded by my old system.
<lilyp>nckx: nice delete fold, I only used a single delete because it's just one module in my personal case
<nckx>That's the (srfi srfi-1) delete by the way. Scheme is a generally sane language until it's not.
<nckx>lilyp: I think there will turn out to be two problematic modules, otherwise it's indeed pointless show-offery :)
<lilyp>In my case (5.4 kernel) it was just simplefb
<f1refly>lilyp: I'm getting interesting graphical glitches but no graphics when booting a recent kernel version from coreboot using stock bios vga graphics initialization, which seems to be caused by a new kernel module which was included to allow linux to take over the initialzed graphics buffer from coreboot, now I tried to roll back to see if my configuration.scm will built a working system again but I
<f1refly>couldn't because guix tries to include the module in my initrd that didnt exist back then
<nckx>lilyp: But 5.4 on master or historical inferior 5.4?
<lilyp>"historical 5.4", meaning 5.4 built a few days ago
<lilyp>I don't pin to inferiors and I'd like to use latest kernels otherwise, but 5.15 hurts my head
<nckx>How so?
<nckx>15 too big? Should we bug Linus to go to 6?
<lilyp>lots of flickering
<tissevert>weird, I deleted gdm-service-type from %desktop-services but still get the "xorg-server" provided more than once error
<tissevert>I wonder how I should troubleshoot that
<f1refly>i blacklisted the module and reconfigured the system successfully!
<nckx>That's something!
<tissevert>looks like set-xorg-configuration is the culprit
<nckx>But ugh. The whole point of the change was so that users of Coreboot+LUKS wouldn't have to add obscure-sounding kernel modules to their system configuration for boot not to appear frozen. If the other half of Coreboot users now has to do that anyway, nothing was gained.
<f1refly>okay, so using the previous kernel works. I'll now try using a recent kernel while blacklisting the module
<nckx>I still say kernel bug though. No reason i915 should glitch depending on what FB driver you used before it.
<tissevert>can "set-xorg-configuration" really add a xorg-server service ? that used to work with gdm
<nckx>Since you say ‘blacklist’: keep the delete; don't use modprobe.blacklist= here; I doubt that will have any effect.
<f1refly>yes, I meant that
<f1refly>built ran through
<f1refly>rebooting now
<rekado_> looks suspicious
<rekado_>especially because there are at least 1040 builds in waiting here:
<rekado_>I don’t get it.
<f1refly>works fine now
<f1refly>deleting the framebuffer module works!
<bdju> lagrange build failure
<nckx>f1refly: ‘Great’! Which module was that exactly? simplefb?
<f1refly>nckx: framebuffer_coreboot
<nckx>Hmkay. Thanks.
***stikonas_ is now known as stikonas
<nckx>f1refly: When you said ‘pinned kernel’ earlier, what did you mean? One from an inferior, or just (kernel linux-libre-5.10) or so?
<f1refly>i used an inferior and set tags for the channels to use
<tissevert>no substitutes for lxpanel and compilation fails on my host:
<tissevert>doesn't that look like a missing dependance in the package's definition ?
*rekado_ cancelled all builds for wip-java-boostrap-simplify and restarted all builds
<nckx>tissevert: Yes. Have you tried adding gdk-pixbuf?
<f1refly>nckx: it works now with a recent kernel though
<nckx>But you haven't tried something like (kernel linux-libre-5.10) from current master, right?
<nckx>That's fine, just something I want to test later.
<nckx>tissevert: It was not that simple.
<tissevert>what do you mean ? (no, I haven't tried a modified version of the package yet, it's always worked for me)
<f1refly>nckx: no, I didn't
<tissevert>and I think it's the first time I have to build it locally
<nckx>gdk-pixbuf-xlib/gdk-pixbuf-xlib.h was removed from upstream gdk-pixbuf as obsolete.
<f1refly>I have another question: is there some compositor running when starting my wm with lightdm? when I start picom from my herbstluftwm autostart the whole system comes to a crawl
<f1refly>although without it videos still tear
<nckx>So presumably the only fix is to update lxpanel.
<nckx>No input is missing.
<tissevert>what ?
<nckx>What what?
<tissevert>so the package definition is good, but the version number wasn't upgraded accordingly ?
<nckx>It's not ‘good’ in that's it's too old to compile with the gdk-pixbuf now in Guix. gdk-pixbuf was probably upgraded through the c-u-f merge.
<tissevert>ahhh, I'm finding one of the c-u-f merge accidents
<tissevert>great, I'm feeling like I'm part of something : )
<nckx>Updating lxpanel to 0.10.1 fixes it.
<nckx>I'll push it shortly.
<tissevert>oh, sorry, I didn't want to make you do it
<tissevert>thank you so much
<nckx>Done! I didn't check whether all other lx* packages need updating, though.
<tissevert>I'll tell you soon ; )
<nckx>Try upgrading/reconfiguring with --keep-going this time.
<tissevert>well that *is* a quickfix ; )
<nckx>It should, well, keep going and not stop at the first error.
<nckx>But at the last 😉
<tissevert>my VM isn't very fast, it's still guix pulling
<nckx>I don't think I've ever heard someone say ‘this VM is very fast’.
<KE0VVT>Finally running fdupes on my $HOME.
<tissevert>I'm surprised how unslow they are on the lab's laptop
<tissevert>and that is, even running ubuntu
*tissevert realizes she's not part of the kvm group
<tissevert>why didn't qemu yell when I asked it to -enable-kvm ? 🤔
<nckx>Can't say. Works here. Bonkers that it's not the default in 2021 but here's hoping for 2022.
<tissevert>: )
<tissevert>I'm waiting for guix pull to return then I'll reboot the VM with the correct group and see if that changes something
<nckx>Adding yourself to a new group can take a log-in cycle to take effect.
<tissevert>(and then I'll be able to test your fix… sad to think you deployed it faster than it's gonna take me to use it)
<nckx>‘Deployed’. It's a 2-line diff. But thanks 😉
<tissevert>yes, I knew but thanks for the reminder, that's the kind of mistakes that can turn a slow, boring attempt into a nightmare of inexplicable series of "nothing works" as expected
<nckx>Surprisingly, lxpanel seems to actually be the only lx* affected.
<tissevert>that's weird
<nckx>Yes, I know that feeling. Death by a thousand paper cuts.
<tissevert>this ! exactly
<tissevert>I hate it so
<tissevert>"1 package updated: lxpanel-0.10.1": no kidding…
<tissevert>wow, it's noticeably faster
<tissevert>oh noes ! looks like it's trying to buid chromium ! ^^
<nckx>You should get a substitute from ci.guix.
<nckx>And I don't need to ask if you've pulled.
<tissevert>yes I did get it (I was surprised to see that a substitute had already been built)
<tissevert>it's finishing the guix system build, always a lot of warning messages about "collisions" on tooling like view and mime.cache and stuff
<tissevert>but it looks like everything went ok, no other errors
<tissevert>reconfigure worked flawlessly !
<tissevert>thanks again for the help nckx
<nckx>My pleasure.
<tissevert>now, I have to understand why sway doesn't behave like i3 and I can't even ask it to exit but that's another story ^^
<nckx>Sway is ridiculously compatible with i3, to the point that you should be able to rename .config/i3 to .config/sway and be on your merry way.
<nckx>It should feel like a clone…
<nckx>(There was one exception, but I forget what it was.)
<tissevert>yeah, I know, which is why I gave i3 a try in the first place, as a first step in a long-planned migration to wayland
<tissevert>I renamed i3-nagbar to swaynag in the config just in case
<tissevert>but sway doesn't even seem to run after I login from sddm
<tissevert>(I didn't find it in ps' output)
*nckx AFK.
*tissevert AFK too
<KE0VVT>nckx: Except the apps for Wayland are different from i3.
<KE0VVT>nckx: So you'll have to rename those in the config too.
<KE0VVT>But I guess the old apps will run with XWayland, so…
<KE0VVT>Rename file, switch to Sway, migrate slowly to Wayland apps.
<florhizome[m]>Guix style now returns “mkstemp: the filesystem is readable only”...
<florhizome[m]>but I just wanna use it for my local files... sigh
<nckx>florhizome[m]: You have to make sure that guix style finds the right file, either with pre-inst-env (which I've tried) or --load-path (which I haven't).
<nckx>KE0VVT: Yes, I expect all X11 programmes to work under (X)Wayland. Are there ones that don't?
<florhizome[m]>I’m trying with -L
<florhizome[m]>so load-path
<nckx>No luck?
<florhizome[m]>what i posted before. ..
<nckx>Works here.
<nckx>~/my-channel $ guix style --load-path=$PWD --input-simplification=always PACKAGE
<lfam>KE0VVT, lilyp: Vorta patches: <>
<jpoiret>nckx: i'm pretty sure clipboard managers and the like won't work properly
<nckx>But who uses those but of course you're right.
<jpoiret>also, things like screenshot tools
<nckx>Won't they handle the (possibly useless) ‘X11 side’ fine?
<florhizome[m]>Everything that you consider a part of the desktop environment essentially ;P
<nckx>Ah, that thing I never use, rite.
<nckx>i3 → Sway → desktop environment tools was not a leap my mind made.
<florhizome[m]>You have a desktop environment even if you don’t think you have one imo
<nckx>Hey, that's my go-to point, don't steal it.
<florhizome[m]>It’s just not premade (:
<nckx>‘Which DE do you use nckx’ ‘Sway!’ ‘OMG YO‌U SHOULD HAVE SAID NONE’ ‘…ok.’
<bdju> taisei build failure
<jpoiret>`oh yeah my DE is a bunch of scripts I hacked together, do you want me to help you install Linux?`
<jpoiret>erhm `GNU/Linux`
<bdju>I think there's a wayland clipboard manager, but last time I tried it, it had some weird bug, so I switched to manually putting stuff I'll re-paste a lot in a file called "clip" that I pipe into bemenu for selection and then pipe that to wl-copy
<nckx>See, we manage, we're normal, we save things to intermediate files, it is the commercial OS vendors and users who are wrong.
<jpoiret>wl-copy/wl-paste has a bunch of quirks though. Sometimes I can't seem to copy or paste some specific things
<nckx>I only use it in my ‘2-factor auth’ script and it works fine there (which xclip didn't, reliably, so me hap).
<nckx>What kind of specific things?
<florhizome[m]>nckx: I thought we are on a Unix like system, and everything is files
<florhizome[m]>ppl really don’t understand wayland yet. It makes room for much more individual graphical environments but it also rips out the middleman everybody dealt with.
<bdju> vte-ng build failure (dependency of termite, which I'm probably just going to uninstall now that I'm thinking about it)
<jpoiret>florhizome[m]: a major issue though is that for a long time wayland didn't have additional protocols for many things, so many tools relied on GNOME-specific apis and such
<jpoiret>xdg-desktop-portal and friends is trying to bridge the gap but there's still much to be done
<florhizome[m]>Yeah that’s still an issue if you talk to ppl @wayfire
<florhizome[m]>Especially since sway pushed things further but they have their own ipc so many more complex matters are not really tackled yet.
<lilyp>lfam: I say add borg as input and patch invocations
<lfam>lilyp: Yeah, it's probably the best option, although maybe it is a case where the limitations of propagation are valuable. Like, we wouldn't want people to install a different borg than the one used by vorta
<florhizome[m]>and they just want to work as a compositor.
<lfam>Anyways, lilyp, I probably won't use Vorta (or I would have used it already). It's just too hard to change how I run my backups now
<lfam>So... help wanted!
<lilyp>I use MongoDB as backup, so I don't judge your broken script collection.
<lfam>Also, the issues with the missing icons made me feel like it was a little too fragile to rely on
<florhizome[m]><jpoiret> "xdg-desktop-portal and friends..." <- Yeah and the problem is really DEs continuing the style of merely communicating about interoperability and progress of common protocols. That’s where I’m mad at gnome; they might be able to just use their shell to solve stuff, but it doesn’t help others and the whole ecosystem to progress.
<lilyp>lfam: Looking at a randomly picked source file, it appears as though borg is simply invoked as 'borg'.
<lfam>Which file is that?
<lfam>Or, is it every file? :)
<lilyp>I guess the other commands are built similarly.
<lfam>I do a function (method?) with a docstring "Find packaged borg binary. Prefer globally installed."
<lilyp>So go ahead and propagate it, it's probably saner than doing the correct substitute*
<lfam>We could always ask upstream to use a single location for this
<lfam>They seem very responsive, and it's actually a commercial product. So they want people to use Vorta
<nckx>Did I miss why wrapping won't work?
<lfam>I just didn't mention it
<lilyp>hum, let me check again
<lfam>Or think of it
<nckx><we wouldn't want people to install a different borg than the one used by vorta> does not make sense to me.
<lfam>Like, you don't get my point at all? Or you disagree with it?
<nckx>I think… both? :)
<lfam>To compare, I have a custom ffmpeg package that I use often. It's sometimes annoying that e.g. VLC doesn't use it
<lilyp>lfam: Okay, so the initial 'borg' that is listed in every other command is actually replaced by the one you found
<lfam>But, I can't see anyone choosing to make a custom Borg package
<nckx>Why does it have to be custom?
<lfam>AAC licensing issues
<lilyp>can't you transform vlc to use your own ffmpeg tho?
<lfam>If I was using Vorta, but wanted to use Borg itself for some task, I'd definitely prefer if it was the exact same binary as used by Vorta
<lfam>It's a digression, but I don't want to recompile almost all my packages due to custom ffmpeg :)
<lilyp>but you get that if you install both borg and vorta as-is from guix
<nckx>Oh, I meant Borg above, not ffmpeg. If I want to install an older, newer, (or actually indeed: why not patched with some testing patch?) borg because I'm interested in messing/hacking on borg, why should that be made hard?
<lfam>Makes sense nckx
<lfam>Probably not the most common use case but it does make sense
<nckx>And ‘you have to use an environment because we say so’ counts as hard here.
<nckx>This might explain my position.
<lfam>Yeah, I think we are just leaning in different directions on this. Not a big deal
<lfam>Definitely, it's not Guix policy to prefer the limitations of propagation. I just thought it might be valuable in this case. But I don't feel strongly about it in any way
<lilyp>anyway, I think you can substitute shutil.which('borg') with the output path if you want to hardcode the command
<nckx>This makes it sound like I have a far stronger opinion than I have, but I've been limited in practice by this before and just want to either understand why it happens or prevent it from becoming entrenched.
<lfam>Note that I wrote the Vorta patches starting in 2019, but don't actually use it
<lfam>So, I'm very loose about this
<lfam>lilyp: Okay cool
<lfam>See any other improvements that we can make, lilyp? And everyone?
<lfam>I can send a v2
<lilyp>wait, having another look
<ngz>lfam: yes, use new style ;)
<lfam>ngz: Already done locally :)
<lfam>Thanks for the reminder
<nckx>No suggestions, it's so much shorter than I expected it to be.
<ngz>I think I will use this package actually.
<lfam>That's years of improvements upstream nckx
<lfam>It used to be a more complicated package
<lilyp>Just to check, the tests don't write to home, but sanity-check does?
<lfam>Yes lilyp. It would be great to understand what's going on there
<lfam>Unless I got the order of phases wrong. check is before sanity-check, right?
<lfam>It's a very fast build, all are welcome to test it :)
<lfam>It's one of these programs that does almost nothing, delegating everything to dependencies
<lfam>Oh, since I am going to patch the borg path now I am wondering. Does anyone have an example of using the new style for modify-phases? I don't know how to do it yet
<lilyp>sanity-check is done directly after check normally, so yeah
<lilyp>I think you're executing some top-level code there, so that'd explain things
<NicholasvonKlitz>hmm @nckx I'm still getting 0.0% for `guix weather rust@1.54` even after pulling the latest changes from master.
<lilyp>there's a new style for modify-phases?
<nckx>NicholasvonKlitz: Just to check, what does ‘guix describe’ report?
<lfam>lilyp: I don't know. Since I will be doing (assoc-ref inputs "borg"), I though maybe I could use a gexp
<lilyp>(search-input-file inputs "bin/borg")
<lfam>Yeah, but I don't know how to use it in this context
<lfam>I can't find any examples in gnu/packages
<lilyp>M-x rgrep search-input-file :)
<lfam>I guess I was looking for another part of the new style
<lfam>I'll look again
<nckx>NicholasvonKlitz: Oh, but you're on a custom checkout.
<lilyp>oh, I forgot about the leading slash, my bad
<lfam>I can figure that part out :)
<nckx>I don't have that commit, so even if you claim you didn't touch Rust, there's no way to verify that and Guix seems to think you did. What does guix build -d rust@1.54 return?
<NicholasvonKlitz>nckx: Well because I need to apply my patches
<nckx>Sure, but if it returns anything but /gnu/store/vz51h8zcykalyijd2k8bzlzfr46ak1ay-rust-1.54.0.drv you've somehow touched Rust in the process.
<NicholasvonKlitz>It returns `/gnu/store/vz51h8zcykalyijd2k8bzlzfr46ak1ay-rust-1.54.0.drv`
<lilyp>Can anyone help me debug a GI_TYPELIB error?
<lilyp>I get the following: Typelib file for namespace 'HarfBuzz', version '0.0' not found
<nckx>…again, really wish we could just weather .drvs.
<lilyp>but ls $GUIX_ENVIRONMENT/lib/girepository-1.0/HarfBuzz-0.0.typelib
<lfam>search-input-file will probably always work here, but it's not the same thing
<lfam>What if another package also has a 'bin/borg' file?
<lfam>It's a looser guarantee that (assoc-ref inputs "borg)
<NicholasvonKlitz>nckx: You're also getting 0%?
<nckx>I'm getting 100%.
<nckx>See paste.
<jpoiret>lilyp: what's GI_TYPELIB_PATH?
<NicholasvonKlitz>oh wait nvm I misread
<nckx>You do get 0% twice right?
<roptat>gettext-minimal fails to build on armhf, and that's needed for guix pull...
<ngz>lfam: It doesn't matter if another package has bin/borg in practice, does it?
<jpoiret>iirc that's a search-path of glib, so you need to have glib explicitely installed in the environment for it to properly set the env var
<lfam>ngz: Why wouldn't it? That is, if both are dependencies of vorta?
<lfam>How could search-input-file know which one to choose
<NicholasvonKlitz>nckx: Okay wait now it works. I was using an old shell: ` 100.0% substitutes available (3 out of 3)`
<ngz>lfam: Your package is already in trouble in that case (binary shadowing)
<lilyp>jpoiret: A long string, that among others has /gnu/store/dswp2mfwb56xg57903cvhwcjj1fpdhqi-harfbuzz-2.8.2/lib/girepository-1.0 (a different harfbuzz, probably with one level of grafting less)
<ngz>It wouldn't make it worse.
<nckx>NicholasvonKlitz: OK. Wonderful.
<lfam>ngz: It's not in trouble now
<NicholasvonKlitz>thanks again for the help. I see if librsvg build now
<lfam>Like, with the old style, it wouldn't necessarily be a problem
<lfam>But, it would definitely be a problem with search-input-file
<ngz>I fail to see how in can happen in the current package.
<jpoiret>lilyp: you're using `guix shell`, right? Could you try with glib in the list of packages in that invocation? otherwise i don't really know what's wrong there
<lilyp>lfam: I'd say "it's a feature"
<ngz>Do you have two "bin/borg" ?
<lfam>We are doing a substitution here. With the old style, I choose which dependency to use for the substitution. With search-input-file, one does not choose
<lilyp>ngz: prepending another borg in inputs
<lfam>No, I don't currently have two 'bin/borg' files. I'm just saying that search-input-file is not an exact replacement for the old method
<lfam>It's a looser binding than the old method
<ngz>lilyp: And? This will use another bin/borg maybe? Prepending another borg instead of replacing it is not good anyway.
<lfam>I think there must be another procedure that is a better replacement
<lfam>Something like (string-append $#borg "/bin/borg)
<lfam>Or whatever the syntax is
<lfam>That's what I want to use, or stick with the old style for now
<lfam>Just searching for a string match is not very Guix-y
<lilyp>I think there is some with-inputs thingy, but imho you're being a little too anal here :P
<lfam>That accusation does phase Guix packagers!
<lfam>I mean, does not faze
<lfam>I mean, I don't mind being too anal here. If we just wanted to use dynamic binding based on strings then we wouldn't have Guix
<nckx>I get that it's supposed to be the ‘which’ of champions but I was also surprised that ‘search-input-file’ doesn't error out on ambiguity.
<nckx>At least by default.
<lfam>So, I'm still looking for an example of using a gexp in modify-phases to replace (assoc-ref inputs "foo")
<lilyp>#$(this-package-input "borg") would be the syntax you're looking for, but it only works inside a gexp context
<lfam>Like, we didn't encourage use of which before, either
<nckx>But for other reasons, not possible ambiguity.
<lfam>We always asked people to specify an input package, rather than use which
<lfam>That's why I encouraged it, although I am sure there are other reasons too
<lilyp>That was due to limitations in which, however
<lilyp>i.e. it would return a native-input instead of an input for example.
<NicholasvonKlitz>@nckx This is still odd... It's still trying to build rust from scratch, even now that I get 100%
<lfam>It's okay for there to be multiple reasons
<singpolyma>Won't the result be deterministic from the inputs?
<lfam>There doesn't have to be only one reason
<lfam>Since Guix is all about specifying the dependency graph, I don't see why we should encourage people to stop doing that in some contexts
<lfam>I think so singpolyma, but only by accidnet
<lfam>Well, I suppose there's nothing stopping somebody from making multiple packages named "foo"
<lfam>Then you get ambiguity from (assoc-ref inputs "foo"), also
<singpolyma>So long as it's deterministic and correct then it can't break since it won't change?
<lfam>I guess I'm not communicating my concern clearly
<lfam>I think that replacing (assoc-ref inputs "foo") with search-input-file entails a loss of specificity in how we describe dependencies.
<lfam>That's something we generally try to avoid in Guix
<lfam>It's not clear to me why we would make that choice now
<singpolyma>But the only thing that matters is what literal strings end up in the output. The process to get there just has to be deterministic and then the closure will be correct
<lfam>Hm, I don't really agree that this new method is "enough"
<lfam>We should make it work with gexps, so that packages can be selected specifically in cases like this. Or justify the loss of specificity explicitly, rather than just saying that it's good enough
<lfam>Maybe I missed that justification / explanation
<singpolyma>I'm not sure what the explicitly would gain. Unless there is an actual ambiguity and then of course it's up to this packages to use a different way
<lilyp>lfam: I think the old style gives a wrong sense of security that the file you're looking for actually exists
<lfam>True lilyp. But I think that's unrelated to my concerns here
<lilyp>let's say I constructed the vim command like (string-append (assoc-ref inputs "vim") "/bin/vim")
<lilyp>i.e. old style
<lilyp>but then someone came along and rightfully replaced vim with emacs.
<NicholasvonKlitz><NicholasvonKlitz> "@nckx This is still odd... It'..." <- I also just look through the rust package definitions again, and I can't find anything in my patches that would cause rust to rebuild
<lilyp>the command would now look for vim in the emacs input or fail to assoc-ref :)
<lfam>That is correct
<lilyp>more importantly, it would silently patch in the wrong reference
<lfam>But how is that related to what I am talking about?
<singpolyma>If you change the inputs all bets are off and you need to be paying attention
<singpolyma>That was always true, AFAICT
<lfam>It seems like a weakness of the old style, but not germane to what I am concerned about
<lfam>I don't foresee a problem using search-input-file specifically with the vorta package, as it related to patching its borg invocation
<lfam>My objection is more general, that search-input-file is not a replacement for (assoc-ref inputs "foo"), but rather a replacement for `which`
<lilyp>Putting the debate aside, you can try using the old style using ,#$(this-package-input INPUT)
<lfam>And already we discourage use of `which`, favoring (assoc-ref ...)
<lfam>Okay, I will look into that
<singpolyma>assoc-ref also still works fine
<lfam>Yes, true
<lilyp>Again, (assoc-ref ) over which was at least in part due to the technical restriction.
<lfam>But I do want to help things progress
<lfam>In part, sure, but also the other reason. I had this explained to me and explained it to others
<lilyp>and partly also cargo cult, i.e. other peeps were using assoc-ref so I do too
<singpolyma>Just never look at the atrocity that is the default wrap-ruby-program call in ruby-build-system...
<lfam>I'm somewhat suprised that people want dynamic bindings in Guix
<singpolyma>lfam: it's not a dynamic binding, is it? That would be a popagation
<lilyp>(define wrapped-file
<lilyp> (string-append (dirname prog) "/.real/" (basename prog))) whoo boy, off to a good start
<lfam>I think it's more dynamic than if you specify which store item to contstruct the path from
<singpolyma>lfam: you end up with a static result still
<lfam>Which is highly static, and not *that* different from static linking in terms of building a distro
<singpolyma>lilyp: meh, that's the normal part inherited from wrap-program. What's really gonna bake is that it just sits GEM_PATH to whatever it happened to be set to during build
<rekado_>re “which” vs explicit package references: I recently encouraged the use of “which” for patching references in hwloc(?), because the alternative would have been pages and pages of similar looking substitute* clauses.
<NicholasvonKlitz><NicholasvonKlitz> "It returns `/gnu/store/vz51h8zcy..." <- This is so odd. Now the same command returns `/gnu/store/rlxb9rd8px2gj28dy0rhddr5s9mzgsm5-rust-1.54.0.drv`
<lfam>If I do it like this, I get "error: ungexp: unbound variable":
<lfam>Do I need to import a module somewhere?
<NicholasvonKlitz>> <> > <> It returns `/gnu/store/vz51h8zcykalyijd2k8bzlzfr46ak1ay-rust-1.54.0.drv`
<NicholasvonKlitz>> This is so odd. Now the same command returns `/gnu/store/rlxb9rd8px2gj28dy0rhddr5s9mzgsm5-rust-1.54.0.drv`
<NicholasvonKlitz>Is there any easy way to see what is causing a package to rebuild?
<lfam>rekado: I see. There are definitely pros and cons to each technique
<rekado_>lfam: where’s the beginning of the gexp?
<lfam>rekado_: I guess that I left it out :)
<lfam>I need to, like, begin the "quote" of the gexp?
<lilyp>yeah, my bad
<lfam>Here's the entire arguments field:
<lfam>No, it's my bad. For not knowing the language that Guix is written in
<lfam>Not well, anyways
<lilyp>I think you can ,#~(string-append ...)
<lfam>Now gexp is unbound
<lfam>I will send a v2 WIP patch series to the patch tracker and maybe you can help me write this part?
<lfam>It has a patch that works, using assoc-ref, and then my WIP patch using gexps, that does not yet work
<rekado_>mixing quasiquotation with gexps is pretty ugly
<rekado_>I know because I’ve done it a lot.
<rekado_>very confusing
<rekado_>but I tried to fix packages on c-u-f with the least changes
<lfam>Can you point me to a commit where you did it rekado_?
<lfam>I'd like to look at some examples
<rekado_>I haven’t used them in build phases, but in configure-flags.
<lfam>I haven't seen many examples in (modify-phases)
<lfam>The examples I found were kind of unusual
<rekado_>i can take a look at the patch; do you have a number?
<lfam>Check the v2 series:
<lfam>Thanks rekado_
<lfam>So, the entire modify-phases becomes a gexp
<lfam>The only tweak is that the argument of this-package-input needs to be a string rather than a variable
<NicholasvonKlitz>> <> > <> > <> It returns `/gnu/store/vz51h8zcykalyijd2k8bzlzfr46ak1ay-rust-1.54.0.drv`... (full message at
<KE0VVT>nckx: I'm sure all X11 apps work. I've used GNOME and Wayland forever.
<bdju> wslay build failure (godot dependency)
<lfam>bdju: You really gotta send these to <>
<lfam>Unless they are getting fixed reliably!
<lfam>I don't mean to discourage you from doing something that works
<bdju>I do occasionally report bugs to the mailing list
<bdju>maybe if the updates ever actually go through successfully I'll go back and file reports for everything
<lfam>I only fixed barcode because I knew exactly what to do
<rekado_>lfam: oops, didn’t get to test it
<bdju>okay issues reported. left out bpytop because mroh already has a pending patch for it
<lfam>Thank you bdju
<bdju>you're welcome
<vivien>Hi, I get a linux build error on linux-libre-lts: gnu/build/linux-modules.scm:257:5: kernel module not found "simplefb" "/gnu/store/1ai7mxw5ad58ic9slxsjzsxaryi5wksp-linux-libre-5.10.87/lib/modules"
<vivien>Is it just me?
<ngz>bdju: I think i'm going to fix wslay.
<jacereda>how can I tell guix to "Download & decompress some package. Apply any patches specified and environment variables. Leave me in a shell at the source folder so I can diagnose a build problem with gdb"?
<lfam>It's probably not just you vivien
<lfam>What command did you run to get this error?
<podiki[m]>roughly, guix build package --with-patch=package=path/to/patch -K
<podiki[m]>and then you go to the failed build folder in /tmp and source the enviornment variables
<bdju>ngz: thanks!
<podiki[m]>but not sure about the "environment variables" in your first sentence jacereda
<taylan>'guix shell' might also be able to do what jacereda is asking for, but I haven't Guixed in a while :P
<jacereda>guix shell doesn't complete
<podiki[m]>doesn't complete what?
<jacereda>so I guess I need some "keep broken build folder" flag
<jacereda>it errors before entering the shell, that's what I want to diagnose
<podiki[m]>guix shell you can use to set up an environment that has gdb and dependencies you want to work on a package
<jacereda>the build process crashes
<lfam>That flag is -K
<podiki[m]>yes, the -K flag keeps the build
<lfam>Also called --keep-failed
<podiki[m]>and the enviroment to be sourced
<jgart>`` is broken in various places for alpine linux
<jacereda>great, thanks
<jgart>I tested yesterday
<excalamus>hello, Guix!
*jgart considers making a POSIX version of
<vivien>lfam, guix time-machine -C <my channels, including guix master> -- system reconfigure /run/current-system/configuration.scm (where I have linux-libre-lts, and a couple kernel arguments to blacklist radeon and amdgpu)
<vivien>The failing derivation is named /gnu/store/749jz16if0990znilvd60c3xzc2672b4-linux-modules.drv
<lfam>vivien: You're using time-machine. It's a current commit?
<roptat>so, gettext fails its tests "perror2" and "strerror_r" on armhf. What can I do about that?
<excalamus>I'm debugging a simple SDL window which will display a bitmap. When I map the memory using mmap, I get a segfault error "in iris_blorp_exec () from /gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/lib/dri/"
<vivien>lfam, yes, it’s the unattended upgrade service (I just checked that it still produces the error)
<taylan>Public Service Announcement: If you want balanced parentheses in your shell scripts when using the 'case' syntax, you can enclose the case branches in full parentheses, like this: "case foo in (case1) bar ;; (case2) baz ;; (*) default; esac" This is POSIX-compliant!
<excalamus>that's not something calling directly
<lfam>vivien: It's likely broken for everyone. Can you send a bug reporT?
<taylan>jgart: looks like it shouldn't be too challenging; the only Bashisms I see from a glance are [[ ]]
<taylan>writing things in POSIX sh used to be my hobby in my early Unixing days :P
<excalamus>it's not clear to me if it's a guix issue or something upstream
<vivien>lfam, does this derivation depend on the kernel arguments passed in the system configuration?
<excalamus>or user issue in that I don't have something installed correctly
<lfam>vivien: I'm wondering the same thing
<vivien>I’m gathering the evidence to send the bug!
<lfam>Possibly fallout from bc09e7ab569d5306ce99c5525150695c9d539ef0
<lfam>"gnu: linux-libre: Support the Coreboot framebuffer."
<lfam>If you are comfortable working from a development checkout, you could try reverting that commit
<vivien>I’m not comfortable at all, unfortunately :)
<vivien>What I usually do is define more packages in my channels, but I can’t do that with this particular issue
<lfam>Okay. Then we'll just have to wait for someone else to try it
<vivien>(by more packages I mean a fixed version of the failing packages)
<vivien>Until a critical vulnerability in linux lts is discovered, I prefer that solution ^^
<lfam>If you are worried about security, I think it's better to use the latest stable kernel in the 5.15 series
<lfam>The older series are buggier and receive less fixes
<lfam>I mean, the newer series have new bugs, but over time they become better than the old series
<lfam>The old series slowly get worse and worse and backports get harder
<lfam>Maybe it's a controversial opinion but it's shared by the kernel maintainers
<lfam>Do you know how to use Git? You could revert the commit and then pull from the repo you reverted it in
<lfam>That way you don't have to set up a development environment
<vivien>Yes, but I would need to set up a channel for guix, set up the commit signatures, and not forget that I did that
<vivien>I’m not very confident about it, trying the 5.15 kernel seems like an easier thing to do right now
<lfam>How about if I push a WIP branch to Savanna for you?
<vivien>Oh I could use it yes
<lfam>It would be signed. However, afterwards, when you stopped using it, you'd probably have to use allow-downgrade
<ngz>How can I force a build process to detect a library in include/ if pkg-config failed?
<vivien>I know about allow-downgrades
<vivien>I used it a lot to debug things on core-updates-frozen back in the days
<lfam>Okay, stand by
<rekado_>jgart: it *is* a bash script, though
<rekado_>does bash on alpine behave differently?
<jgart>rekado_, I tried running the script after installing bash on alpine but there are commands that are not compatible such as groupadd and useradd
<jgart>I modified the script to use adduser and addgroup instead
<jgart>The script also did not detect that usermod was missing IIRC
<jgart>not sure if being POSIX helps this particular situation. Is adduser/useradd and addgroup/groupadd irrelevant to POSIX compatibility across shells? maybe I'm conflating things in that regard
*jgart reads
<lfam>That's the place to look
<lfam>And a nice reference:
<jgart>lfam, thnx!
<KE0VVT>Agh, “guix pull” takes a while…
<ngz>Has GI_TYPELIB_PATH a default value when unset?
<excalamus>okay, looks like I just needed mesa-headers
<jgart>florhizome[m], unmatched-paren, Here's the email address for sending patches to guixrus: ~whereiseveryone/
<jgart>So far, Ragahv and I can review any patches for guixrus
<jgart>What I did on sourcehut to set that up was create a project for guixrus and add a public inbox associated with it.
<florhizome[m]>nice :) will try in an instant
<excalamus>no, that wasn't it... :/
<podiki[m]>ngz: I don't think so? but there is some internal default it sounds like!
<jgart>I'm planning to make a cookiecutter template for Guix channels in general so that others can make their own channels more easily.
<jgart>I'm interested in curating what goes in the cookiecutter template with others in the Guix community. We can develop it together as an open source project.
<excalamus>looks like it was mesa-utils
<podiki[m]>speaking of, anyone know why multiple librsvg (same version, different hash) exist in the store and referenced by the same things?
<rekado_>jgart: cookies can go into the cookbook
<jgart>If someone has a better software they can recommend than cookiecutter feel free to share
<ngz>jgart: cookieclicker is clearly better <> ;)
<lilyp>promoting non-free games in #guix? That's a bannable offense!
<jgart>Starting your own Guix Channel would be as easy as:
<jgart>`guix shell python-cookiecutter -- cookiecutter`
<lilyp>now do it in elisp
<ngz>lilyp: oops, sorry :)
<jgart>ngz, haha
<civodul>efraim: rust-rayon fails to "build"
<jgart>no worries
<podiki[m]>it'll go on your permanent record!
<excalamus>sigh, no that doesn't solve it...
<lilyp>tbf a "guix channel" subcommand to do channel-related tasks would be nice
<excalamus>anyway, I'll quit with the play-by-play
<lilyp>maybe write a guix extension and have it merged chaotically like guix home :)
<podiki[m]>sorry to repeat earlier, lost in the cookie talk: why does GI_TYPELIB_PATH have two librsvg paths? (same version) any idea why that would happen? breaks syncthing-gtk
<jgart>`guix cookie project-dir`
<jgart>or whatever ha
<jgart>yeah that would be cool
<KE0VVT>Upgrading Gajim and hoping it will then run. (Have you had any issues, singpolyma?)
<lilyp>ngz: Your apology is accepted, but we will still deduct one good noodle star.
<samplet>Why is Guix telling me it’s rewriting hashes and I should cross my fingers? All I’m doing is downloading a file with ‘guix build -S’!
<mroh>podiki: Have you tried to remove the "wrap-libs" phase from syncthing-gtk? maybe it doubles stuff...
<podiki[m]>mroh: will give it a try. what is curious is that both librsvg's I see have the same list of guix gc references to them. but i know nothing about librsvg
*samplet starts reading daemon code...
*jgart plays supertux to repent from opening ngz's link
<vivien>lfam, it’s long because I need to build linux
<opalvaults[m]>yall guix is so good dang
<opalvaults[m]>never had this much fun hacking
<podiki[m]>feel the same way opalvaults, a joy to do it all in a lisp
<opalvaults[m]>also I just found this paper on CLOSOS - Specification of a Lisp Operating System, and it's pretty amazing if anyone is interested
<jgart>check out rg's guix home configs:
<opalvaults[m]>podiki: absolutely, it feels like anything is possible.
<jgart>those will be my TLDR guix home docs
<samplet>Turns the Guix daemon does this when it’s not building in a chroot, but why isn’t it building in a chroot? (I’m running the daemon from a checkout, so it’s probably my fault somehow!)
<opalvaults[m]>jgart + raghavgururajan , great code. definitely gonna try and integrate some of these ideas
<opalvaults[m]>Haven't gotten to play much with guix home yet
<civodul>samplet: it prints that message also when doing --check
<podiki[m]>same, thanks jgart
<jgart>I haven't either. I think I will start seriously now
<samplet>Ah! I am using “--check”. Thanks! Somehow I never noticed it before.
<jgart>I've just been casually reading home docs and browsing guix home configs "in the wild"
<podiki[m]>I'm still wondering how I want to incorporate literate org-mode files that I currently use; would like to keep that around
<nckx>Evening, Guix.
<podiki[m]>maybe guix home will replace the gnu stow step
<podiki[m]>o/ nckx
<jgart>I think I'll start by just managing xdg and bash* config files with home
<opalvaults[m]>podiki: that's what I'm hoping to do as well. It looks like in raghavgururajan 's config there's a lot of code dealing with basically copying dotfiles from a git backed directory to it's proper XDG .config spot
<opalvaults[m]>Which could easily replace `stow .`
<jgart>I've been using chezmoi
<jgart>Happy so far with it
<nckx>So I had predictable success booting linux-libre to an i915 VT on my X230T. Still more of a relief than failure would have been. I'll build a desktop image now; maybe the extra graphics® matter.
<jgart>except for the fact that guix has an ancient version of chezmoi packaged
<jgart>I should try upgrading that at some point
<rekado_>did you know that bash has a configuration option to log history to syslog?
<opalvaults[m]>jgart: when is the next packaging get-together?
<jgart>opalvaults[m], next year
<opalvaults[m]>jgart: word. i'll get on the guix mailing list and keep my eye out
<nckx>Hello, what's this:
<rekado_>civodul nckx: I’d like to try to build a custom bash on to log bash history to syslog. Yay or nay?
<nckx>rekado_: …no?
<opalvaults[m]>rekado_: convenient, although I'm curious how cluttered that would look
<nckx>That was still in response to the previous question.
<nckx>rekado_: …yes!
<opalvaults[m]>can you still `history` and grab commands or does it still have to be in bash_history for that to work?
<opalvaults[m]>or is it just logging history related to bash?
<nckx>I'm almost certain it's an also situation.
<rekado_>opalvaults[m]: I’d add a syslog rule to dump it into a separate file, and to log it to a remote logging server.
<vivien>lfam, reverting bc09e7ab569d5306ce99c5525150695c9d539ef0 works, maybe you could partially revert it and only keep the coreboot framebuffer thing only for 5.15?
<nckx>rekado_: How did you find that? A lazy info (and man! I'm thorough!) search for ‘syslog’ doesn't tell.
<jgart>opalvaults[m], next Guix Documentation Meetup: Jan 15 and next Guix Packaging Meetup: Jan 22
<vivien>In the mean time, I’ll switch to linyx 5.15
<opalvaults[m]>That's an interesting idea rekado_ . I'll have to throw my hat into configuring syslog. That's one less file in ~ ;P
<nckx><Hello> Hm, doesn't look related.
<jgart>opalvaults[m], I'll make an announcement on guix-devel soon
<opalvaults[m]>jgart: thanks for the info :)
<jgart>no prob
<rekado_>nckx: I made a googling.
<jgart>opalvaults[m], I submitted a Guix Packaging Meetup as a workshop to LibrePlanet 2022
<rekado_>I thought: I wonder if I could do that… And StackOverflow says “yes, you can”
<opalvaults[m]>jgart: well just in time for me to attend a LibrePlanet finally. That will be really fun
<jgart>so, maybe we'll have one there in April if they accept my application
<nckx>rekado_: Cool!
<nckx>Now do auditd. /s
<civodul>rekado_: that's surprising... why not? i wonder to what extent this would allow us to really know what an attacker did, though
<jgart>opalvaults[m], It would be my first LibrePlanet also :)
<nckx>vivien: Is this linux-libre-lts on current (or recent) master?
<nckx>‘On master, ’
<opalvaults[m]>Question: If StumpWM needs modules that I've installed via `guix install` but they are only in /gnu/store afaict, should I just copy those modules to .guix-profile/ in a custom directory for SBCL related modules?
<nckx>I guess it probably is.
<nckx>I'm clever.
<rekado_>civodul: an attacker could just not use bash
<rekado_>and an attacker could kill syslog
<civodul>yes, that's the thing
<opalvaults[m]>I need to point StumpWM to them, is the reason I'm asking but they appear to only be in /gnu/store so I don't think it's very convenient to use that absolute path
<rekado_>but up to a point we’d see what they did
<rekado_>(on the remote log server)
<civodul>but they could do things without going through root's bash, no?
<jgart>rekado_, I think I will try installing guix on alpine linux manually without the bash installer script first
<jgart>I'll document what I did
<cbaines>doesn't bash not log commands if you start them with whitespace?
<nckx>I saw this less as a security thing than a transparency (and simply good housekeeping) thing.
<civodul>yes, that sounds good
<rekado_>also: lots of layers
<nckx>As a security measure against >12-year-olds it's quite useless.
<rekado_>even though I should know how to use this idrac thing, I’d totally mess up clearing the logs when I intrude :)
<nckx>rekado_: Also, yes.
<jgart>My goal is to get guix running on either carbslinux or oasislinux
<nckx>cbaines: Not by default.
<cbaines>nckx, indeed, I just tried that out as root on my system, and the commands were logged
<civodul>jgart: FWIW, with the way LibrePlanet ended last year, i'm personally reluctant to associating with it (or other FSF-led efforts); YMMV, of course
*nckx uses ignoreboth, it's quite nice to not litter your history with known trash/one-offs.
<civodul>nckx: i'm sure i'd mess up, even though i'm >> 12yo :-)
<jgart>civodul, I'm not aware of things that happened. Maybe, I should read up.
<jgart>Is there somewhere I can read about that?
<nckx>civodul: Well, if we add enough ‘bad’ security measures someone will eventually trip, if only because we gain the element of surprise 😉
<rekado_>“by the way, uhm, I’m back; surprise!”
<nckx>Oh, thanks rekado_. I was wondering what that meant.
<nckx>Now I know.
<podiki[m]>mroh: removing the wrap in syncthing-gtk gets rid of the whole GI_TYPELIB_PATH
*rekado_ randomizes the SSH port to evade the haxxors
*nckx aims a web cam at the NIC LEDs for hardware intrusion detection.
<nckx>(Do they still have LEDs? I'm a bit out of the hardware-that-costs-actual-$ loop.)
<rekado_>yes, they still have LEDs
<civodul>so you can make nice pictures
<rekado_>on the front panels Dell installs blue/amber LEDs
<nckx>So you can see it's thinking.
<rekado_>I prefer amber, which is why I keep some nodes in degraded state
<civodul>sometimes they have fancy backlit LCDs too!
<rekado_>oh, yeah, I hate these
<rekado_>the server name is displayed there
<vldn[m]>mhh cannot create real-root directory no space left
<nckx>Current live feed of berlin:
<vldn[m]>but 25gigs free
<nckx>vldn[m]: /tmp tmpfs?
<jonsger>rekado_: I'm setting on servers in the internet ssh's port to something not 22. it keeps the logs way more silent :)
<Gooberpatrol66>i want a computer that looks like that
<podiki[m]>the key snooping using changes in electrical signals in sockets from a dfiferent room is very cool/scary; same with seeing changes in lighting
<nckx>Gooberpatrol66: One of the best designs ever. Thinking Machines CM-2.
<vldn[m]>nothing mountet extra on /tmp
<vldn[m]>do i have to create a Filesystems directive for /tmp ?
<nckx>Wait, what do you mean?
<nckx>‘Filesystems directive’ sounds un-guixy.
<vldn[m]>i mean i have nothing done with my /tmp folder
<vldn[m]>and nothing in my config.scm
<nckx>Then I don't know, though.
<jgart>civodul, I haven't kept up with all the details of the Stallman situation. I remember hearing different stories. It's a bit confusing to hear all the divergent stories/analyses around the drama.
<jgart>I haven't had the time to cross analyse everything
<jgart>Did you read Leah Rowe's defense of Stallman? It seems she took it down since then. Not sure if the above link is accurate to the original source. It looks like it on a quick glance.
<nckx>Wow, that's… something.
<civodul>jgart: i don't want to rehash the drama :-) i just wanted to make sure you know that some lost confidence in the org
<nckx>Is this on-topic though? It started as on-topic. Is it still?
<civodul>not really, my bad!
<nckx>It certainly started as relatively on-topic. But once old blog posts get dug up to reopen old arguments I don't think there's progress ahead.
<nckx>Mmm, hash.
<podiki[m]>speaking of hash (check out this segue)
<podiki[m]>what's the difference between: and
<jgart>I was not politicizing, by hosting a meetup at LibrePlanet. I see it as just another venue to get packager's involved at. It's hard enough to get people involved in developing on guix. But if it would not be seen in a favourable light by the Guix community at large, then I can retract it if it gets accepted. I don't want to piss off the guix community at large if Guix prefers not to be associated with LibrePla
<podiki[m]>same librsvg vesion, different hash, different input (one doesn't have rust stuff?)
<jgart>sorry for the long sentence on irc
<podiki[m]>we still have a guix wiki (of sorts) on libreplanet
<podiki[m]>librsvg: and both appear in GI_TYPELIB_PATH for syncthing-gtk
<bdju>anyone else using latest qutebrowser? many webpages are showing up really weird
<nckx>FTR I don't think you pissed anyone off or that anyone thought you were politicising. Just someone noted they weren't fans of LP.
<Gooberpatrol66>how should i test modifications to shepherd services? can i run them with ./pre-inst-env somehow?
<jgart>that said, it's unfortunate that such a small community, relatively speaking, is boycotting/hindering itself. The free software mission is already hard enough and we have bigger enemies in the world that would like to undermine it (mega corps, etc...)
<nckx>podiki[m]: Little more than a guess, but could it be <>?
<nckx>Community size or cohesion are not good arguments for accepting something you wouldn't otherwise accept.
<vivien>I don’t think we need to agree about libreplanet (or even have an opinion about the situation) to talk about guix, right?
<lfam>I don't think it was decided that Guix wouldn't do anything with libreplanet
<lfam>It's just one person who said they didn't want to participate, right?
<podiki[m]>nckx: thanks. but seems odd that anything that refers to one librsvg also refers to the other one as well. maybe no big deal but that break syncthing-gtk. maybe can work around it somehow..
<jgart>sure, but, what are we not accepting?
<jgart>Just wish there was a doc that clearly and plainly stated it for the record
<jgart>There's lots of noise on the internet regarding this situation
<jgart>The facts are not clear
<lfam>About what?
<nckx>I think plenty of people have shared their stories and opinions on the matter already. Maybe those willing to have this discussion can have it in #guix-offtopic.
<lfam>Sure, it's a good idea
<nckx>podiki[m]: It would make perfect sense if librsvg kept a reference to librsvg-bootstrap… but it doesn't seem to. So who knows! My guess was just that.
<podiki[m]>okay, so changed syncthing-gtk's input from librsvg to librsvg-bootstrap, which fixes the issue (both appearing in the gi_typelib_path)
<taterbase>I've been doing some reading around bootstrapping with Guix and I'm blown away by what's happened and what's in store. Initially I chose Guix because I like lisp and the idea of functional reproducible package managers. But the work with Mes and Hex0 is incredibly exciting! The reason I even started going down this rabbit hole is because I was doing research around what it would take to get Gnat as a package for Guix
<taterbase>requires... Gnat to be compiled). Is anyone aware of progress around an ada compiler for Guix?
<nckx>Progress? No.
<nckx>I couldn't find an old enough version of GNAT to compile with anything other than GNAT.
<taterbase>It almost feels like someone is going to have to write a completely new ada compiler in C
<nckx>It existed, but if it still does or would be of use, who knows.
<podiki[m]>nckx: so changing librsvg to librsvg-bootstrap makes it so only one librsvg appears in the gi_typelib_path, fixing the syncthing-gtk issue I have; but that seems...not the right thing to do?
<nckx>It was developed as an add-on to GCC by AdaCore. I seem to remember that it was even proprietary, but don't quote me on that. However, if it was relicenced (‘open sourced’) after the fact that doesn't bode well for the old code.
<rekado_>same here. I was curious about Ada and was unhappy to see that there’s no obvious way to bootstrap it.
<rekado_>taterbase: write the new Ada compiler in Guile instead!
<nckx>We AlSo HaVe AdA 83 (ada-ed).
<taterbase>nckx: I was looking at ada-ed but the irc logs indicated no joy in getting it to work?
<nckx>I mean really what could you really be missing.
<nckx>taterbase: Nope.
<samplet>I also looked into it. There’s an “AdaEd” (or some such) compiler that was used for educational purposes. It is free software and can be ported to modern systems. It only compiles Ada 89 (or something – it was a long time ago).
<taterbase>Even the ada-ed docs indicate it's not great to use for ada compilers past a certain version
<nckx>Not with the earliest copies of GNAT I could find, that is.
<samplet>Even old versions of GNAT need Ada 95.
<samplet>I believe that GNAT and Ada 95 were developed in tandem.
<nckx>Yeah, I packaged it as a might-limp-just-far-enough-to-bootstrap-GNAT-0.001 option, not as a useful package in itself (although it still is a nice package).
<rekado_>this is how bash-with-syslog logs: Dec 19 23:25:30 localhost /gnu/store/8d6570ksb9lzynhh16xkmdky576p9ml9-bash-with-syslog-5.1.8/bin/bash[12559]: HISTORY: PID=12559 UID=1000 hello
<nckx>samplet: Basically, yes.
<taterbase>rekado_: would creating a new ada compiler in scheme have any deficiencies compared to one in C?
<rekado_>a bit verbose.
<nckx>I sorely miss GNAT for Coreboot, which is probably why anyone ever asks about it today.
<samplet>There’s also an Ada 95 lexer and parser, but I can’t remember if they are free software. All my notes are on another machine. :)
<rekado_>taterbase: C is not a very comfortable language for writing compilers. Guile already has a compiler tower so adding a new language can be easier.
<taterbase>Guile certainly feels more approachable. I just worry the scope of ada's std lib and what gnat does these days
<taterbase>nckx: that's exactly what got me started. I ended up downloading binaries on github and getting them to work on my machine
<taterbase>I was like "Why doesn't guix just do this" but then I read some blog posts and was enlightened
<nckx>samplet: In case it wasn't clear, ada-ed is in Guix. It's just very ‘educational’ as you say.
<rekado_>taterbase: by targetting an existing non-toy language (= Guile) you could bypass a lot of the implementation.
<rekado_>ah yes, coreboot. That’s also why I wanted GNAT.
<nckx>So this is what compiler grooming looks like.
<taterbase>what do you mean you could bypass impl with guile?
<mroh>podiki: why shouldn't it be "the right thing"? (our emacs pkg does the same) and if it works and fixes the problem, it can't be to bad ;)
<nckx>mroh: It should go away some day, whether or not that's likely 😉
<samplet>I thought that maybe with the lexer and parser you could write a compatibility shim that translates the new Ada features needed for early GNAT to stuff that Ada Ed could handle.
<taterbase>oh that's interesting!
<podiki[m]>mroh: also syncthing-gtk is very much a leaf, so it shouldn't need the librsvg with bundled rust stuff
<vivien>It seems hard to implement languages in guile
*nckx had a suspicion, and indeed: at least two packages *propagate* librsvg-bootstrap. That's… bad.
<podiki[m]>but I do like the practical approach and letting a future someone (me, probably me) fix it better later
<podiki[m]>anything critcal doing that propagating?
<rekado_>nckx: we had the same problem in gnome itself
<rekado_>maybe a week or two before the merge
<nckx>podiki[m]: Which package was this again? gtk+ is one of the naughty propagaters, and almost certainly how lrsvg-b ends up in the build environment.
<nckx>If it transitively uses gtk+ at all, that's why.
<podiki[m]>nckx: syncthing-gtk, indeed has gtk+ as an input
<nckx>OK. Then using librsvg-bs is OK for now.
<nckx>With a comment.
<podiki[m]>it also builds and seems to run fine removing librsvg all together (since gtk+ propagates), what is better for the change (with comment/mark as todo)?
<nckx>I agree that practical prevails, here, especially synce it's not syncthing-gtk's ‘fault’.
<nckx>That I can't say.
<nckx>Personally, I'd omit it?
<nckx>‘synce’. OK. :)
<podiki[m]>i'm a fan of removing things too
<samplet>There’s a lexer, too:
<podiki[m]>should this be noted in a code comment as well? or is this just "known" due to gtk+ and librsvg
<samplet>It looks like it is intended to be free software, but uses a non-standard license.
<taterbase>samplet: I was just looking for some ada specs
<taterbase>I wonder if/how gnat diverges from the std ada
<samplet>This is also pretty interesting:
<bdju>"it happens if your QtWebEngine is too old and your glibc is too new" - qutebrowser dev I think we need to upgrade qtwebengine and/or downgrade something else in the meantime to fix a new issue with the qutebrowser package where on some sites text doesn't appear properly
<mroh>podiki: I wonder how many other pkgs have this problem...
<podiki[m]>mroh: was just wondering too...
<taterbase>do we have a definitive oldest known version of gnat source in ada?
<podiki[m]>thanks nckx and mroh, will prepare a quick patch now
<mroh>podiki: doesn't this mean if a pkg has gtk+ and librsvg as an input it's potentialy broken, because it has 2 librsvg's than?
<podiki[m]>yeah, though not sure how many will actually break
<nckx>Potentially, yes.
<nckx>I can't think of a good way to fix <>. (1) ‘%base-initrd-modules-lts’ :-/ (2) make this particular module ‘optional’ somehow if version < N, but ew (3) something else?
<samplet>taterbase: I have a file called “gnat-1.64-sparc-src.tar.gz” full of files from 1993-12-09. That’s the oldest one I found when looking.
<podiki[m]>I see similar commits now that I'm looking, eg. d508c5baab16f99818e6514351ed0ab7ad9e8116 for xfce
<taterbase>samplet: is that hosted anywhere?
<podiki[m]>i'll make my commit message slightly more verbose to note why librsvg as input is being removed
<nckx>Oh, you beat me, I had a gnat167-src.tar-gz (sic).
<podiki[m]>patch sent, hope my additional detail is useful for future searches when this may come up again
<nckx>‘I see […] now that I'm looking’ — ain't that always the case.
<podiki[m]>I'm not sure if xfce was broken due to the 2 librsvg, but was effectively the same kind of commit
<samplet>taterbase: Not sure where I got any of it from anymore, but here are three early GNAT tarballs that might be interesting:
<podiki[m]>(it was a busy time a few weeks ago)
<rekado_>oh, I just realized we aren’t using syslog-ng
<rekado_>inetutils syslog doesn’t seem to have support for content filter/dispatch
<podiki[m]>if we are talking syslog, btw, this was brought up the other day:
<podiki[m]>would love to see some better logging for guix/shepherd
<rekado_>podiki[m]: thanks for the pointer!
<rekado_>it’s not quite what I was looking for, but it’s a good opportunity to merge some patches from 2016
<podiki[m]>props to florhizome for digging that one up
*rekado_ tries to package aiscm, builds llvm-13 now