<apteryx>strange, ("org" ,emacs-org) became emacs-emacs <apteryx>actually emacs-org and emacs-scel became (list emacs-emacs org-scel) <nckx>jpoiret: Had I switched to this workspace when you pinged me you would have saved me 30s, so it is appreciated! <jpoiret>anyway, keep up the good work everyone, i'm going to catch some z <apteryx>jpoiret: where did you add that #~? I thought I tried that without luck <kwjc>strange question, do hardware based backdoors (e.g. Spectre) work with FOSS drivers? a.k.a what guix system has? <nckx>apteryx: (list #:blah #~(list stuff #$thing foo)) ? <nckx>(arguments (list #:blah #~(list stuff #$thing foo))) to be ‘clear’. <apteryx>OK; I'll experiment more after lunch and with less stress; pushed a revert of two packages for now to fix 'guix pull' (hopefully). <nckx>kwjc: You can mitigate against them though, and modern software does, both FOSS and other. <nckx>Best to always test it before pushing. <nckx>I speak from experience. And the one after that. And… <apteryx>I got rid of the compilation warnings <apteryx>(plus a simply reused the previous copy so it should be a no risk game) <sozuba>this in guix would be helpful for users facing this wondering what is wrong <sozuba>jpoiret, the reason I m having that issue is because what i am having in my host /etc/resolv.conf is #generated by networkmanager" <nckx>jpoiret: That patch alone applies & works perfectly! <nckx>apteryx: (When sated) Did you do anything particularly clever to revert individual package sexps or just copy/paste? <apteryx>I rarely do anything particularly clever, if that answers your question ;-) <nckx>All right! Neither do I. <lfam>If I am working on x86_64, and I have offloading set up for aarch64, is there a way to build packages for aarch64 with the same derivation as if they were built "natively"? <lfam>Like, do I cross-compile? Use '--system'? <nckx>--system *is* a native build. <lfam>I'm familiar with --system=i686-linux and what it means <lfam>(The "personality" thing) <lfam>Are you saying it could be used for this too? <nckx>I'm saying it's the same thing. <cbaines>--system controls how the derivation is computed <cbaines>if you try it for some system your hardware doesn't support, without offloading/emulation, it should fail <cbaines>but it sounds like for aarch64-linux, hopefully it'll be offloaded <lfam>I'd test it myself but the system in question is doing a big GC right now <lfam>I often pick aarch64 derivations from the Cuirass web UI and do `guix build aasdfdsaf.drv`, which works <nckx>IME, ‘offloading/emulation’ is actually ‘offloading & emulation’, an offload machine wasn't enough. <lfam>But it would be great to do `guix build hello --system=aarch64-linux` and be sure that it's the same that Cuirass would have done <nckx>I still got an ‘but I am an xxx’ complaint. <lfam>My interest is renewed now that I can offload to one of the new machines <lfam>You added grunewald, right? <nckx>Well, yes, but does it actually work now? <lfam>Yes, I tried a `guix build asdfsadf.drv` earlier and it went to 10.0.0.10 <nckx>At least the reboot had a silver lining, kicking it back into business. <nckx>It didn't work at all yesterday. <lfam>But now I want to do `guix build hello --build-on-aarch64` <lfam>It will help "level up" our QA regarding that platform <nckx>Unless I severely misunderstand you (always an option) that's really just --system… <lfam>Okay, great. I just didn't remember <nckx>I wish I could say I deliberately rebooted berlin to fix offloading to grunewald but no. <nckx>(Side note for ultra-correctness: it's not technically ‘offloading’ in the classic sense that Cuirass does, now, it's grown its own protocol.) <lfam>A few minutes ago, I wondered (via email) if reconfiguring a system that had been online for that long, and then restarting some services, is something that is guaranteed to work <lfam>Or, not "guaranteed" but "it's definitely supposed to" <lfam>Of course there are no guarantees <lfam>Especially if we don't use locale-libcs to ease the transition <nckx>‘It's always worked before’ is about the only answer we have. <nckx>It's not a great one to base workflows on no. <lfam>The uptime was pretty long before the shutdown <lfam>I wonder if it's the kind of thing that is well-tested on any operating systems besides Guix and Nix <nckx>I think we should set a fixed schedule (every * days) and/or policy (every *or kernel bump) for reboots. We won't always follow through, but at least each missed reboot will be a decision, and something that needs a mild defence. <lfam>Although I can't imagine it would result in a graceful shutdown <lfam>Like, if there was a problem <nckx>Sadly it's not always clear. <lfam>I don't know, either way <nckx>(Also ‘pankow’ is new in that list since the reboot. Something was definitely stuck before.) <lfam>Yeah, it wasn't there before <lfam>nckx: Are you looking for a careful review of #51619 (Coreboot framebuffer)? If it fixes a problem for you then I think it's fine. I can batch it with today's kernel updates <lfam>They probably won't get pushed until tomorrow <lfam>And, does it require #52498? <nckx>If that looks good to you, then they should make a bug-free whole. <nckx>‘Careful review’ — just your stamp of approval as kernel maintainer ☺ <nckx>They boot here, on (Corebooted) bare metal and (not) VM. <lfam>I'll test on non-Coreboot bare metal <nckx>I don't have non-Corebooted bare metal but I can't imagine it breaking. <lfam>I don't really consider myself a kernel maintainer... more of a kernel updater <lfam>There are many others who understand how to compose a kernel and modules and all that... but I am the one who is willing to handle updates <apteryx>lfam: while you mention it, thanks again for the continued linux-libre updates :-) <apteryx>raghavgururajan: no, it was about a guix pull failure <lfam>You're welcome! I do think it could be beneficial to spread the load. Not because it's too much, but because it could be a good on-ramp for new contributors <lfam>And maybe some people are interested in helping maintain the kernel packages but don't know they can ask to help <apteryx>lfam: good points about kernel maintaining; it'd be nice to have a few people in the know <lfam>Building rtl8812au-aircrack-ng-linux-module-5.6.4.2-6, "Unbound variable: %build-inputs". I think this is new since the merge *nckx still unnerved by the reverse video highlighting of the new bash's C-r. <apteryx>lfam: it probably doesn't work too on latest kernels, unless something changed <nckx>Well, I'll fix it assuming it's fixable. ☝ <nckx>As long as it works with either latest or any LTS kernel it's fine. <apteryx>true, perhaps I should try LTS on that other machine <lfam>apteryx: I was using it on 5.15 before the merge, after fixing it for 5.15 <nckx>When you C-r now, your search string will be highlighted in the text. <nckx>Hm, (assoc-ref %build-inputs "linux-module-builder") ; implicit input, sneaky, I'll actually have to think for once. <apteryx>no builds can be repatriated from workers while it's GC'ing <nckx>I thought GC was done tho. <nckx>Database worker unresponsive for 5 seconds (db-clear-build-queue). <apteryx>OK. Perhaps it was affected by the long GC <nckx>Oh, but that's very recent. <nckx>WARRNNINNNGNGN: : (cuirass watchdog): i i i miipmmopproteeededtedt edt eedt emedt emdedt emdo muulloloeloedloed loed ule (fibers)(fibers) ooovvveeerrrrrriidees c csoo rrcrcerceorceo rrbiin dbbinnngngnngn ngn dngn d`ngn d`ing `sleep' <nckx>I don't know if that's serious, but backtraces usually aren't the best sign. <lfam>Backtraces usually contain English <nckx>There are a lot more ‘Database worker unresponsive for 5 seconds’ lines. <apteryx>any chance to guess what led to it from the log? <nckx>failed to lock file '/var/lib/cuirass/.cache/guix <nckx>Ah, newlines and /s and IRC. <nckx>Git error while fetching inputs of 'core': "failed to lock file '/var/lib/cuirass/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/refs/heads/master.lock' for writing: " <nckx>It may well be completely unrelated but I'll purge the cache. <nckx>…I should've moved it as evidence but too late. My bad. <nckx>I doubt it contained any. *nckx shuts down postgres, herd does not seem to return, hart stops. <nckx>But the machine is still responsive. <nckx>%exception(#<&invoke-error program: "/gnu/store/smp26m83ayl08lqzh8spn2hakigr86cx-pg_ctl-wrapper" arguments: ("stop") exit-status: 1 term-signal: #f stop-signal: #f>) <nckx>There's no postgres running though. <nckx>Was there before? I didn't check 🤷 <nckx>2021-12-15T03:34:04 Database worker unresponsive for 5 seconds (db-clear-build-queue). <nckx>Someone who actually knows Cuirass should take a look. <nckx>Offloading to the criminally idle beefcakes does indeed work just fine, as guix installing iotop demonstrates. <nckx>Cuirass is sending statements to postgres! Postgres is seeing the statements! Postgres is… reading and writing from and to the discs! <nckx>It's not very effective. <apteryx>I think it must have accumulated a very looong list of things to fetch from workers, causing the database queries to be very slow <nckx>That's my suspicion, but *hours*? <nckx>This has been going on for them. <nckx>Note that Ricardo is running a guix gc --verify=contents, which will impact I/O, but still. <nckx>Also checked for forgotten processes by name between restarts. <apteryx>let me find past logs of tips from mothacehe <nckx>Curiously, nothing seems to appear in /var/log/cuirass-sql.log *vagrantc managed to guix pull from ~may up to ~yesterday on aarch64 :) <nckx>Looking at the file timestamps it might have stopped being used in January 2021 and be a total red herring. <apteryx>nckx: OK my exchange with mothacehe was on teh 2021-11-25 <apteryx>quoting: to fully restart Cuirass, I usually run: sudo herd restart cuirass && sudo -E bash -x ./home/mathieu/remote_command.sh "herd restart cuirass-remote-worker" <nckx>Oh boy, a secret sauce bash script in $HOME <apteryx>so perhaps what is missing is restarting the remote workers as well? <apteryx>and then it took a long while after restart before picking up; I also had noted "pteryx seems to be busy clearing the build queue: 2021-11-25T16:34:54 Database worker unresponsive for 5 seconds (db-clear-build-queue)" <nckx>OK, if that's ‘busy’ I'll wait. <apteryx>quoting again: that's the query that does "update builds set status = scheduled where status = started" basically <nckx>Just note that it's been hours. <nckx>I ran the remote restart shell script, thanks for that. <nckx>postgres: cuirass cuirass [local] UPDATE waiting <apteryx>and then I was following "status" in the log file; if you see crashes again we should report them, last time mothacehe fixed them promptly <nckx>Stuff is happening, it just… keeps on happening with little to show for itself. <nckx>I'll keep an eye on it going forward. <nckx>Maybe we should upgrade to tater-base. *nckx pops cuirass from stack, exposing linux-module-builder, goes to stare at code. <apteryx>I tried a few things there already, without luck <nckx>Your usual #$inputs suspects? <nckx>Doing this in a phase would be trivial so there has to be a way. <apteryx>oh, and that's probably silly, not being in a gexp? <apteryx>no, search-input-file is just a proc it seems <nckx>Yes, it's not gexp-magical. <apteryx>how to use %build-inputs in #:make-flags? <apteryx>dc4b4d4d9593a2368b84568e80cee0289c797271 seems to give it away <apteryx>turn the make flags into a gexp, then use #$(this-package-input "htslib") <apteryx>instead of (assoc-ref %build-inputs "htslib") <nckx>I even tried this-package-implicit-input just because I felt lucky. <nckx>Well, there's an obvious if unsatisfying answer. <apteryx>would the implicit inputs have labels there? <nckx>Actually, I didn't try that. <nckx>I had the same doubt now. <vagrantc>my 60 watt space heater is doing well, managed to get linux-libre built, which is always a long haul on aarch64 ... guile-static-3.0.7 is taking plenty of time. <apteryx>wait, this package was not even restyled <apteryx>so why did it break in the first place? <nckx>Because %build-inputs is gone. <apteryx>why is there still 1322 occurrences of it in the code base? <lfam>inetutils has a substitute and uses %build-inputs <nckx>It is a surprising number, though, I agree. <nckx>> It is a surprising number, though, I agree. <nckx>Less surprising if you're not talking about the linux-module-build-system 😃 <nckx>I don't think the comparison is valid. <nckx>I don't really have the energy for yet another stack-pushing digression, sorry. <nckx>I don't context-switch well. <nckx>I don't mean to be rude, I'm just as confused about most of this stuff, I'm just trying to focus on understanding one thing well before jumping to the next. <nckx>Staring at huge diffs of notorious build-system boilerplate doesn't help. <vagrantc>yay, it booted with my favorite message! "error in finalization thread: Success" <nckx>I think part of me believed that would be alleviated by gexping. <nckx>For a similar change I don't understand but was necessary, see 058766ec7aee9373346c28497af1875da82aa991 <nckx>Somehow, %outputs and %build-inputs are gone now, OK, but why? I don't know. <nckx>It's not obvious from 7d873f194ca69d6096d28d7a224ab78e83e34fe1 <nckx>and that's assuming I'm even looking at the right commit. <apteryx>compared to that example, we have inheritance added on top <nckx>True, it's just the only example I have of another linux-module that needs a similar change. <nckx>Come back with coffee, find the damn thing in 20 seconds. 😒 <nckx>Line 511 in guix/build-system/gnu.scm <nckx>Nothing fancy, just the explicit provision I kept missing. <nckx>What? No. I meant with-build-variables in guix/gexp.scm. <nckx><Line 511 in guix/build-system/gnu.scm> is what's missing from linux-module.scm, no? <apteryx>yes, I ended up looking at this too; this is what makes using gexp magical <nckx>Natively. Can't test the cross case because I'd have to compile an xgcc first. <nckx>It does not feel satisfying, because I still don't feel like I grok the secret that will make thinking about gexps effortless. :) <nckx>Not trying to do it am 5 in the morning might help, though. <apteryx>well without this 'with-build-variables' the bindings are effectively gone <apteryx>I tried deploying to a remote machine, and lost access (ssh connection refused) deja-vu. <nckx>I hope it's more accessible than berlin! <nckx>I'm pretty sure the cross-compilation case needs the separate fix I mentioned earlier, but well, still building GCC… <nckx>(And maybe not and everything I thought I knew is a lie after all, who knows!) *nckx contemplates sleep. *nckx still needs to upgrade their static-networking form. <vagrantc>hrm. epiphany is no longer available on aarch64? ... rust? <lfam>Hm, I didn't participate but I saw people taking care to preserve GNOME stuff on aarch64 <lfam>Specifically the rust issue <lfam>Do you mean that there's no substitute? Or the package doesn't exist at all on aarch64? <lfam>Hm, I see that it uses the Rust librsvg. So it will be limited to x86_64 until we get Rust working on other platforms or until we add a conditional to use the old librsvg on ARM <vagrantc>it is no longer listed in systems: ... only x86_64-linux <vagrantc>had actually been using epiphany on the pinebook pro as a reasonably workable browser <lfam>I can make a patch for you to test that adds the conditional <lfam>The problem may go deeper than just epiphany, though <vagrantc>haven't updated the pinebook pro since the core-updates merge, and given the state of things might wait a bit ... or build everything on the apm mustang and take it from there <lfam>I'm looking, and epiphany depends on Rust librsvg transitively through several of its direct dependencies. Maybe these transitive dependencies all resolve to the same place, I don't know. But it won't be simple to bring it back <lfam>Rather, we need to get rust working on aarch64 <lfam>Not a great answer but ultimately the path we need to go down <nckx>Is that realistically a ‘we’-level job? <the_tubular>Dumb question, can my config.scm acutally setup my disks ? <lfam>By "we" I mean "people who use Guix on aarch64, including people who may arrive in the future" <vagrantc>lfam: yeah, rust is increasingly a must for a lot of software ... <lfam>Yeah, and use of rust is increasing rapidly <lfam>So, as our aarch64 hardware resources improve, I'm hopeful the community of people helping with Guix on aarch64 will keep growing <vagrantc>and using a bootstrap seed for rust was a no-go ... due to static linking issues or something, if i recall <vagrantc>bad form anyways, so maybe that's for the best :) <lfam>I don't know the details <apteryx>wip-cross-built-rust branch has a working cross built rust, but it's not statically linked (rustc can't easily be) <vagrantc>yeah, that sounds like what i was getting at <apteryx>so using it as a bootstrap seed would be a bit messy (it'd have to contain its full closure and use some relocation hack to refer to its inputs at another place than /gnu/store) <vagrantc>for a language that is all about static linking, kind of ironic that it can't itself be statically linked :) <nckx>the_tubular: Your system configuration can do anything, in the sense that it's a programme that runs as root each time you reconfigure. All Guix expects is that it returns an operating-system, but if you write code that first checks whether your partitions are xxx and invokes, say, fdisk+mkfs if they aren't, it will work. You have the full power of Guile at your disposal, limited only by your own sanity & good taste. <apteryx>vagrantc: binary bootstrap seed would work, that's what everyone is doing, but it's far from Guixy <nckx>the_tubular: That said, no, there is not a Guixy (partitions …) field to actually do this for you in a Guixy way. Maybe you're interested in guix deploy. <the_tubular>Well, i'm still limited by my Guile knowledge apparently :( <apteryx>I have some ideas to make the cross built rustc statically buildable, but there's more road ahead, no warranty of success (it's a hacky, unsupported territory road) <lfam>Hm, gnome-calculator is failing to start on my non-GNOME Debian since the merge: <lfam>GLib-GIO-ERROR **: 23:30:24.298: Settings schema 'org.gnome.system.proxy' is not installed <vagrantc>hmmm... maybe there are some people i know in the rust community i could pester, er ... solicit for assistance. <nckx>What a normal dependency for a calculator. <the_tubular>But, I'm still thinking we should do something about Cookbook <the_tubular>I'd probably understand better if the documentation was more accessible <nckx>(Does it fetch currency data from the intarwebz? Still…) <nckx>the_tubular: Improvements are certainly welcome. <vagrantc>lfam: sounds similar to a bug someone reported using the guix debian package ... <lfam>Hm, it works before the core-updates merge. It's my preferred calculator program (the pickings seem surprisingly slim?) <lfam>I use ncmpcpp as a client and plain mpd as the server <lfam>And I keep sonata installed as a client for guests <vagrantc>lfam: the history of that bug is mixed with another unrelated issue, but not sure really figured out what to do about it <apteryx>lfam: is mpd strictly about remote controlling playback, or can it be used to stream the music to a remote device too? <apteryx>such as, play the music on a mobile device, streamed from the mpd server? <apteryx>but I doubt our current mpd service is ready for it <apteryx>it also requires an out-of-band file sharing (NFS, samba or WebDAV) means <lfam>Hm, yeah I haven't looked into that <apteryx>oh, the simpler/limited http streaming scheme is supported, there's even an example in the docs <lfam>For what I do, leaving the MPD computer plugged directly into the stereo, it's a solid solution as long as everyone involved is happy using an MPD client <lfam>itunes isn't what it used to be so there's not much competition for "polished UI for playing files" <lfam>As you can see, there's not much to do besides customize mpd.conf and run the mpd daemon <lfam>So, it's nice that MPD is simple to use and doesn't require orchestrating a dozen discrete services <apteryx>I'm trying the http streaming conf for fun <lfam>Has anyone tried xcalc lately? It doesn't seem to work right for me *nckx calculates various zero-based things. <nckx>Do you honestly use xcalc or were you just desperate for a new and proxyless calculator? *nckx uses bc like a total nerd ☹ <lfam>I am looking for a GUI calculator that works <lfam>gnome-calculator, xcalc, and pantheon-calculator aren't working for me <nckx>Actually, honestly, no: nowadays I use Guile. <cehteh>qalc has a gui frontend (i never use :D) <cehteh>but it can handle units and lots of coversions which makes it extremely cool <lfam>Debian's xcalc looks very nice *nckx → work. Good day, nerds. <lfam>mate-calc is nice and very simple, which is what I need <lfam>That's very handy cehteh <cehteh>i have a shortcut which opens a small transuucent terminal window on top with qalc <nckx>I wonder if the restart had some untintended side-effect. <nckx>Perhaps our workers are on strike. <nckx>Except Dover isn't on strike, Dover is just idle. Fitting. <lfam>Yeah, I played with it for a couple minutes. I like it <lfam>It works and it has a history, which is important <cehteh>i already wonder if one can use that like the commandline one, just having additional buttons <apteryx>nckx: the rtl8812au driver works! thank you for fixing it <lfam>In case anyone wants a laugh <cehteh>missing some stylesheet/fonts/theme? <cehteh>does it log stuff to terminal when you launch it from there? <lfam>Missing pretty much everything :) <lfam>I guess it's missing its error messages too <podiki[m]>of which I think I have the package I need to submit that core-updates-frozen-forever-excuses is done <apteryx>nckx: precision, I only tested using the latest kernel linux <flatwhatson>found a bug in gnu/packages/virtualization.scm, line 1541 should be %build-inputs instead of %build-input, causes criu to fail to build <lfam>Should be fixed now flatwhatson <unmatched-paren>hi guix, i managed to launch gnome wayland using XDG_SESSION_TYPE=wayland gnome-session <cehteh>under debian i have also (not so) funny bugs .. wrong pointer size depending on where on the monitors the pointer appears. wayland is just not mature <cehteh>managed to replicate all my config from i3 to wayland, looked nice except becoming unusable by those fu*kups <cehteh>my guess is when scaling happens they mistook a multiplication with a division at some place <unmatche1-paren>maybe i'll try launching gdm manually with XDG_SESSION_TYPE=wayland? <unmatched-paren>maybe something to do with the winit library that many gui rust crates use <florhizome[m]>i complained all the time about guix being less snappy/smooth then manjaro, well that seems to have gone <florhizome[m]>maybe my thinkfan service is starting to work (I was to busy with transferring to new master yesterday to check, but it spits some stuff onto the terminal (I think that’s the kms thingy?) before the login manager pops up), or it’s just cuf, or both :) anyways, that’s great :) <florhizome[m]>also jpoiret helped fixing sddm, now it’s only enlightenment that doesn’t work, I guess I will need to report that <florhizome[m]>I pasted some xorg configuration into my config that broke it. <jpoiret>florhizome[m]: i've had an issue with thinkfan/shepherd forever, on my laptop hwmon takes its sweet time to be available, and thinkfan cannot start without it. However, shepherd stop trying to restart it at some point, and the number of retries is not configurable (yet). So I often end up with no fans working when resuming from suspend or <jpoiret>booting, unless I remember to start thinkfan manually :) <jpoiret>also, for enlightenment, I'd suggest using a very minimal config, and trying to reproduce it in a vm first: that's how everyone will test it <jpoiret>abrenon: yes, when the temperature throttling kicks I start suspecting something usually <florhizome[m]>yes I guess it’s good anyways to have a base/minimal config around anyways <jpoiret>$(guix system vm /etc/config.scm) is enough <jpoiret>although you might want to add `-m 4096 -smp 4 -enable-kvm -vga virtio` or something along those lines for better performance <jpoiret>those are qemu flags that are appended to the default ones of guix system vm <jpoiret>i know that the bochs driver is somewhat broken, so -vga virtio might be necessary for eg sway <florhizome[m]>i’m using the classic /proc/acpi/ibm/fan interface for the fan for now <florhizome[m]>I would prefer to have the full speed stage available and hwmon seemed very complicated <abrenon>is there anything particular to know about fonts handling for ImageMagick's "convert" ? <abrenon>I'm trying to turn some SVG I generated from latex and get repeated errors about the helvetica font not being found <abrenon>all the reported similar errors I find are ghostscript-related and happen on MacOS, I made sure ghostscript was in the same environment but that doesn't change a thing <jpoiret>Could you add a minimal reproducer? I haven't tested latex and friends on guix yet <sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, civodul says: postgres is logging lots of things to syslog, is that intended? <jpoiret>Although you may have more luck with librsvg's binary tools, since imagemagick is kind of messy <mothacehe>oh that's something i enabled and forget about <abrenon>ah, thanks, I didn't know about librsvg <abrenon>it's just something I'm trying to do in a guix shell, so as reproducer I'll include the initial .tex, the manifest I enter and the Makefile used *abrenon is packing things up <jpoiret>abrenon: i won't be available for a couple of hours so if you see me later and the issue still stands feel free to mention me <abrenon>see you and thanks for your help already : ) <abrenon>ok never mind it works so much better with rsvg-convert : ) <abrenon>I've never really liked ImageMagick anyway <NicholasvonKlitz>I'm currently trying to package the gtk4-rs crates. Building works fine, but some of the tests are failing because they cannot connect to a `broadway` server. <rekado>NicholasvonKlitz: can you start “bin/broadwayd :1” in a build phase, and then set GDK_BACKEND=broadway BROADWAY_DISPLAY=:1? <NicholasvonKlitz>Any ideas if I'm on the right path? I'm thinking about packaging broadway and including it as a native-input in the rust-gtk4 crate <NicholasvonKlitz>interesting. What exactly do you mean by can you start "bin/broadwayd:1"? <rekado>gtk itself should provide $out/bin/broadwayd <rekado>so I would expect it to be available in gtk 4 as well. <NicholasvonKlitz>Ah okay. Just to clarify, since I'm including gtk as a native input, I should be able to execute broadwayd prior to the check phase just by executing "./bin/broadwayd :1"? Sorry I'm a little new to this :) <efraim>I assume it'd be something like (invoke (search-input-file "/bin/broadwayd") ":1") <efraim>(search-input-file inputs "/bin/broadwayd") <mothacehe>rekado: i now have a php build failure when trying to reconfigure berlin :( <rekado>to get past this we could override the php package to a custom php package with tests disabled <mothacehe>but cuirass says it builds fine, must be a transient check error <NicholasvonKlitz>aha, after looking through the gtk bin output, I think it actually is `gtk4-broadwayd` <efraim>that could do it. I'm still building out to gtk to see if it was indeed still there <attila_lendvai>source-module-closure has a very unfortunate default for #:select? (guix-module-name?) that silently ignores the user's own modules. i've spent some time debugging this. <NicholasvonKlitz>Ok great, broadwayd was now found and invoked, but it is issues starting... <NicholasvonKlitz>`Can't listen: Error binding to address (GUnixSocketAddress): No such file or directory` Any ideas what this means :) ? <efraim>above it add (setenv "HOME" (getcwd)) <rekado>NicholasvonKlitz: “&” would require a shell. You can use “(system "… &")” instead of “invoke”. <rekado>mothacehe: the openssl_x509_checkpurpose test also fails on my laptop <attila_lendvai>so, the hooks in modify-phases don't need to return with #t anymore, right? where can i read about the c-u-f API changes? <rekado>attila_lendvai: correct. Build phases don’t need to return a boolean. <rekado>it has been like this for … more than a year when we moved to using “invoke” to raise exceptions <rekado>but only now do the build systems no longer print warnings <rekado>there’s going to be a blog post about the new inputs format. <attila_lendvai>rekado, thanks! i've been adding them in my 4-5 months of guix'ing to avoid the warnings... :) <jgart>Looking forward to the next one! <rekado>attila_lendvai: heh, I’ve been removing them whenever I touched the build phases anyway, in anticipation of the c-u-f merge… :) <jgart>apteryx, is anyone working on a minetest service? <attila_lendvai>rekado, it's an example of how guix could be more considerate of the inflow of contributors. the warning should have been removed when the constraint on the return value was elevated. *attila_lendvai is waiting for guix pull after rebasing all his stuff to the c-u-f merge master <rekado>attila_lendvai: yes, but: it required a change to the build systems, which is a world-rebuilding event. <rekado>the delay of getting core-updates merged was not planned by anyone. <attila_lendvai>rekado, oh, i see! didn't think of that. maybe there could be multiple c-u branches? e.g. have one for such simple, certainly non-breaking change, and merge these into master more frequently than the big c-u-f struggle that needs to ensure everything works...? <attila_lendvai>well, actually two is probably enough. one for world-rebuilding, but semantically simple changes; and one for all other world-rebuilding changes. <rekado>however, in the past (and that change dates back to that past) we didn’t have enough capacity to rebuild the world so quickly <rekado>so doing this *multiple* times was unthinkable <rekado>“capacity” here means not only available build nodes but also Cuirass support <rekado>going forward we should have more independent branches, even when they result in world rebuilding changes. <efraim>Back In My Day™ we used to tell people not to push commits for a full day or two because openssl was getting a version bump and we needed to rebuild everything <rekado>build capacity for non-x86_64 is still limited, but hopefully we’ll be able to ramp it up some more. <florhizome[m]>uhm when I build a vm with guix system vm from my current-system/configuration.scm file, what will be my password? <rekado>mothacehe: have you had any luck with php yet? <rekado>I see that we have quite a few packages for which there aren’t any substitutes yet. <mbakke>I also think the 'core-updates' approach does not scale... it would be good to have a branch with "stable" updates such as libjpeg, OpenSSL, expat, python 3.9.X etc, and merge it as part of the ungrafting cycle; and different topic branches for breaking changes, such as GCC upgrade, Python 3.10, build-system changes, etc. <zimoun>after “guix pull”, and “guix gc”, I get this: «guix gc: erreur : entrée corrompue en restaurant l'archive depuis socket». What could be wrong? <mothacehe>mbakke: i agree, we need to come up with a different branching organization. Could be good to start a discussion about that on the ml. <zimoun>mothacehe, yeah! As we already discussed a couple of times. :-) <mothacehe>rekado: yeah the openssl_x509_checkpurpose looks it is trying to access internet <zimoun>I get this error about “guix gc” on two different machines. <walrus_>I have a problem, after I ran 'guix pull' and 'guix package -u' as root I can't run guix as user due to what appears to be a libc mismatch. Trying to run 'guix' complains about GLIBC_2.33 not being found. <vivien>walrus, maybe you need to restart gdm <walrus_>I already restarted the laptop once :/ <vivien>So, maybe you need to reconfigure your systen <jpoiret>you should not interact with guix when logged in as root <jpoiret>unless you know why you are doing so <jpoiret>the actual approach should be using `sudo guix` as your user <florhizome[m]>abrenon how...by jump to tty? I think I have to get the qemu arguments right... <jpoiret>that's because when you `sudo guix`, guix is searched inside your user's PATH env vars, not inside the PATH that would supposedly be setup when logging in <walrus_>jpoiret: I did, I just phrased it differently <jpoiret>florhizome[m]: you can use something like `(password (crypt "test" "$6$abc"))` to have an initial password <zimoun>bah, after repeating the same, it works. Hum?! Anyway. :-) <jpoiret>walrus_: can you run guix at all (on any other user)? <jpoiret>florhizome[m]: in your user declaration inside of the config file <jpoiret>for tests, I copy the configuration file and remove all non-relevant parts, and add this to simply testing <walrus_>jpoiret: Only through sudo or as root. <florhizome[m]>btw, thinkfan is working here :), but it restarts several times at startup. <rekado>mothacehe: only on test failure it tries to send a report <rekado>are you sure the test itself tries to access the internet? <mothacehe>no you're right, that's only during the test report <mothacehe>i'm reconfiguring without zabbix to at least get cuirass going again <attila_lendvai>sudo -E ./pre-inst-env guix system reconfigure config.scm returns silently the prompt -- not very useful ***Guest599 is now known as chris-l
<florhizome[m]><jgart> "Guix Packaging Meetup this..." <- oh, cool :) I have *some* stuff that needs help on the last stretch. <dissent>hey guix what are the bare minimum packages needed to get audio working on a system. I'm having the issue of no audio input -- difficult for having video chats. <abrenon>florhizome[m]: not sure I get your last message or jpoiret's remark <abrenon>configurations may have a password set but it's optional <abrenon>in all the liveCDs I've generated so far, without a password, I simply set it upon first login with root <civodul>i'll go ahead and publish the blog post on simplified inputs <civodul>i hope it doesn't sound too "arrogant" (a complaint i've heard before) or too lyrical <jpoiret>you could do that, but since you'd need one for many things, it's often easier to add it to the configuration itself <rekado>civodul: *photo of printout of screenshot of thumbs up emoji* <abrenon>but then it can't be published without a security risk <jpoiret>oh, but I don't use my own password, for that, this is a feature that's useful for testing only i feel <rekado>dissent: are you using Guix System with the desktop services? <jpoiret>does `guix shell pavucontrol -- pavucontrol` show any input device? <dissent>Just "Monitor of Built-in Audio Analog Stero" <dissent>Ah not input. Output. I can hear people fine, they just can't hear me <jpoiret>alright, so your input device is not recognized by the audio stack <rekado>dissent: go to Configuration and check that you’ve selected a duplex config <jpoiret>is your microphone external/internal, in bluetooth, anything specific? <jpoiret>did it use to work on another distro? *civodul now runs post-merge system + user profile (minus icecat), all working great \o/ *rekado still compiles icecat <dissent>both internal and external microphones aren't receiving anything. not bluetooth. specifics? um lenovo thinkpad l580, what else would i provide? <civodul>rekado: nothing, just missing substitutes <civodul>my laptop stopped halfway, pretending it needed more disk space <dissent>Everything used to work fine on Arch. That was months ago now. It was worked before with Guix after reinstalling alsa and pulse but the cause was never clear. <dissent>rekado: i don't think so, also doesn't work with chromium... sometimes qutebrowser does the trick. <dissent>i've also switched from a system76 to a lenovo while still having the same issue so it doesn't seem to be a hardware issue. <jpoiret>could you try removing the part about the alsa-service-type? it's already included in %desktop-services, if you want to modify the configuration (but you shouldn't need to for pulesaudio), you can do so with the modify-services macro <florhizome[m]><abrenon> "in all the liveCDs I've generate..." <- how do you do that starting from a login manager? Normally I remember jump to tty and login as root.. how would that workout here? <zimoun>I did “guix pack -RR” then copied the result on a machine I do not control. I get «proot error: ptrace(TRACEME): Operation not permitted». What is missing? A config about kernel? <dissent>jpoiret: okay. something weird. people on the other end can hear my audio output. so my output goes into my input. <jpoiret>zimoun: the program needs CAP_SYS_PTRACE, maybe it doesn't have it <jpoiret>did you try rekado's suggestion about the duplex config <rekado>dissent: my comment about icecat was directed at civodul, sorry for the confusion <zimoun>jpoiret, thanks. Which program? I am simply trying the manual example: guix pack -RR -S /mybin=bin bash then copy then tar xf pack.tar.gz then ./mybin/sh <jpoiret>well, I think that ./mybin/sh would use ptrace under-the-hood, but I'm not sure <jpoiret>someone else will have to chime in on this i think, I don't know much about the relocatables <zimoun>sestatus returns «SELinux status: disable» <zimoun>kernel is 3.10.0-1160.el7.x86_64. <mothacehe> now simple sql queries are taking forever, maintaing berlin is turning into a nightmare <mbakke>is there a problem with its storage since it has become so slow? <zimoun>is it possible to turn off “guix gc” for the users on a shared machine? <cbaines>mothacehe, assuming this is PostgreSQL, have you got some EXPLAIN or EXPLAIN ANALYZE output you can share? <mothacehe>cbaines: yup but something as simple as "update builds set status = x where id = y" is taking forever <jpoiret>guix gc should be safe wrt other users as well, so there's no ACL for the guix-daemon iiuc <yewscion>Hello everyone, I have a quick question about hardware compatibility in GNU/Guix: On H-Node, it says that the RTL8812AE chipset works without trouble with free software. I purchased a cheap wifi card for my recent build, and it worked fine initially. But upon `guix system reconfigure` yesterday to change my keyboard layout from stock, the card is <yewscion>no longer detected as a network interface. <zimoun>jpoiret, I know. But many users run “guix shell”, then sometimes one run “guix gc”. The next “guix shell” is really annoying. I would like to disable “guix gc” for the regular users. <mbakke>zimoun: you could use a TCP socket and make the /var/guix/daemon-socket unavailable -- IIRC GC is disabled when communicating over a network socket <cbaines>things like indexes can slow updates down, so there may be things that can be tweaked there. There are also things like the fill factor for indexes and tables which can help trade insert/update performance for space on disk <jpoiret>zimoun: the other you can also add `--root=gc-root` <yewscion>Is there a specific package that supports the RTL8812AE chipset? I see a package for RTL8812AU, but not RTL8812AE. <zimoun>jpoiret, to “guix shell”, yeah. But I cannot control what people are doing. :-) <rekado>mothacehe: if there’s anything I can do to assist, please let me know <mothacehe>oh, i think the static-networking service also broke avahi discovery <mothacehe>ok i'm switch to a previous system generation <abrenon>florhizome[m]: yeah, just like you said, jump to tty (but I see no reason why login as root to the graphical session wouldn't work) <EdwardIII>hey, if you want to install guix system on qemu on an ARM guest, what are the options? build it on the host first? interested in playing with it but on mac m1. i see you can get guix actual for multiple platforms, but not guix system <civodul>EdwardIII: it's possible to build an image of aarch64 using "guix system image" <civodul>you should be able to build a minimal system image that way <EdwardIII>civodul: if i wanted to do that, would i need to have some other linux running on my machine first? <EdwardIII>hmm i don't think you can install guix on mac os but i guess it would be possible on docker <roptat>alternatively, you can run a live system of another distro in qemu, install guix, and use the manual installation steps <abrenon>btw, aren't the development iso download links broken ? <EdwardIII>roptat: ah ha ok. maybe i will give that a go some time :) <roptat>abrenon, I think that's correct, it downloads the latest iso that was successfully built <florhizome[m]>EdwardIII: I think I have seen someone talking about that possibility.. <abrenon>hmmm it went from 502 Bad Gateway to {"error": "No build found"} <roptat>abrenon, I think because cuirass was restarted and it lost all its information? <abrenon>but how come it works for you ? (with the link I pasted or navigating from the website ?) <roptat>I was answering to "it looks weird" <zimoun>I have «guix-daemon --build-users-group=guixbuild --max-jobs=0», and “guix offload test” returns success. But “guix build hello --no-grafts --check” builds locally. What do I miss? <rekado_>roptat: mothacehe wrote that they dropped the db <samplet>GNUtoo: I just pushed a fix for GDM. If you run GDM on Wayland and have Sway in your system profile, everything should work. <roptat>rekado_, also what did we decide to do with the server? do we still trust it? *abrenon is very curious about that too <rekado_>I don’t think we have sufficient reason to distrust it. <civodul>zimoun: i think --check has a --no-offload effect <apteryx>mothacehe: is there anything I can do to help with the CI burden? <rekado_>roptat: but we’re still discussing the exact next steps <samplet>jpoiret: We have a patch that makes GDM look in “/run/current-system/...” for X sessions. I updated it to do the same for Wayland sessions. <jpoiret>hmmm. Weird, how did my system detect Sway without this patch then 🤔 <samplet>This is specifically for selecting Sway from the GDM menu, not just running it. <abrenon>rekado_: could it be useful to compute some packages locally on several person's host to compare with what is on the server ? <zimoun>civodul, ah! That’s annoying. :-) Ok good to know. <jpoiret>samplet: gdm is actually looking also in the system data dirs, precisely the $XDG_DATA_DIRS/wayland-sessions <nckx>Hi mothacehe! Thank you for taking a look at berlin! <samplet>jpoiret: Right.... I’m now trying to figure out (1) if I missed something when updating the patch and, if so, (2) do we need the patch at all anymore (even for X). <nckx>Anyway, good morning Guix & all that. <jpoiret>what's weird is that XDG_DATA_DIRS doesn't actually try to point to the profile's share directory in gnu/services/xorg.scm! <jpoiret>so i still don't know how it could pick it up <mothacehe>hey nckx & apteryx, thanks for proposing support :)! I have several things going on, but I'll send a small recap on guix-devel. <nckx>mothacehe: I'm just off for dinner myself. Are cuirass* supposed to remain stopped? *rekado_ tries to simplify JDK bootstrap <GNUtoo>samplet: thanks a lot, I did a patch and so on but it took ages to test and it probably didn't work *GNUtoo will look at the way you did it to see what I missed <jpoiret>there is not a single reason in my current configuration for GDM to see sway.desktop <samplet>GNUtoo: It looks like I may have fixed a non-issue and your problem might be something else. If you could test it, that would be helpful! <GNUtoo>Also, I didn't rebase it on the last changes <samplet>jpoiret: I’m tried without my update and I still see Sway. (I must have made some kind of mistake when testing.) Like you, I don’t know how it finds it. <rekado_>roptat: a little more patching, newer version of ECJ, skip building icedtea 1.x. <jpoiret>maybe g_get_system_data_dirs has /run/current-system/profile/share/ in it <attila_lendvai>gnome-tweaks is broken for me (prints useful errors when started from terminal) <samplet>We could probably claw back a few of the hacks that were needed to get the older version of GDM running. <GNUtoo>When doing sudo guix shell -D guix and ./pre-inst-env guix system reconfigure --save-provenance /path/to/my/system.scm it didn't find sway <GNUtoo>And it took ages running the nss tests <GNUtoo>I think I tested it at commit d0e6971d9a3e3728ea8348ae08833816ed607510 <GNUtoo>(primary_laptop: add bemenu for sway) *apteryx is not really a minetest person <GNUtoo>Anyway it would be great if someone could pick-up where I left and/or redo the work if needed <jpoiret>oh no, it won't even work, since the binary isn't called as /run/current-system/profile/bin/gdm <GNUtoo>Though to test properly I should probably do a minimalist (and standlone) system.scm and test that on another machine somehow <rekado_>attila_lendvai: I can’t reproduce this. gnome-tweaks works fine here. <samplet>jpoiret: You’re right. My update is basically a no-op. <jpoiret>well, it theoretically shouldn't be. Still scratching my head about that. <attila_lendvai>rekado_, the first error i see: .../libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/[hash]-libproxy-0.4.17/lib/libproxy.so.1), leading to: Failed to load module: /run/current-system/profile/lib/gio/modules/libgiolibproxy.so <attila_lendvai>the ultimate error is from python: KeyError: "unknown key: 'hinting'" <jpoiret>attila_lendvai: did you update your guix profile? <attila_lendvai>jpoiret, right! i knew i forgot something... :) i haven't updated the apps, because i had to fix gpaste... sorry for the noise! <jpoiret>because on my system sway gets picked up no problem, and has for a couple of months on c-u-f <GNUtoo>oh ok, maybe something is wrong on my system then <jpoiret>no one knows, that's the problem :) i'm deciphering GDM source right now <GNUtoo>My patch probably has some insights on it <jpoiret>it seems that both functions that are patched to have /run/current-system/profile/... are not actually used at all <jpoiret>(i'm only using gitlab search though, maybe grepping will give more uses) <GNUtoo>Maybe some dconfig settings are used then <GNUtoo>As I understand these settings are relative to the user which runs gdm (typically gdm on most distributions) <samplet>GNUtoo: For context, I just pushed a very similar commit, and it works, but jpoiret pointed it out that it worked before. Now I’ve noticed that I must of made a mistake in reproducing your issue, because it works for without my (our) changes. <GNUtoo>My patch didn't work for me, so either it's an issue in my setup, or my way to test the patch (I do use sudo guix shell -D guix) or my patch <GNUtoo>If I did a VM or something like that I could drop the sudo but I'd need to adapt/write a new system.scm for that <jpoiret>GNUtoo: more often than not you can just re-use your current config with a VM, and strip unrelated bits <jpoiret>samplet: it's actually af37e6bbd4a0b97c8147ccbd1548dc2e5f830466 that does it, right in the gdm package definition <GNUtoo>(The issue is that the system.scm I use is deeply intertwined with my Parabola installation, so there is modifications and additions to do) <samplet>jpoiret: Good find. Now what’s the story with that patch? :) <jpoiret>looks like andy's commit is older than the patch. I don't really know why it's there, but the patch is a bit more involved, it makes GDM not search in the system dirs, but only in the current system profile <jpoiret>looks like it was solving a gnome issue <GNUtoo>ahhh I've only these files in /run/current-system/profile/share/wayland/: <GNUtoo>wayland.dtd wayland-scanner.mk wayland.xml <jpoiret>wayland sessions should go into /share/wayland-sessions/, not wayland <GNUtoo>Yes, I've sway.desktop in /share/wayland-sessions/ <GNUtoo>I can test adding sway.desktop there non-destructively with bind mounts <samplet>I think I remember now. The patch is supposed to make sure that GDM does not offer a GNOME session when it’s unavailable. <\a>"guix system reconfigure" is failing: ice-9/boot-9.scm:1685:16: In procedure raise-exception: <\a>Git error: unexpected http status code: 502 <GNUtoo>We could add a README in that directory somehow to make sure it's available? <GNUtoo>The issue is that way-and-sessions looks like that here: wayland-sessions -> /gnu/store/ffmi02dzyqw1m3zy8qk97058v23anp73-sway-1.5.1/share/wayland-sessions <GNUtoo>Whereas xsessions is a directory <GNUtoo>(all these are in /run/current-system/profile/share/) <samplet>Basically, it removes searching the results of ‘g_get_system_data_dirs’. *GNUtoo will retry with sway.desktop in /run/current-system/profile/share/wayland ***mnhrdt_ is now known as mnhrdt
<GNUtoo>ok but there I've already sway.desktop <jpoiret>GNUtoo: perchance, did you not set (wayland? #t) in your configuration? it is reqired for wayland sessions to be picked up by gdm <jpoiret>that should go into gdm-configuration <samplet>jpoiret: I think the original patch unnecessarily replaced ‘DATADIR’ with ‘"/run/current-system/profile/share"’, and I aped it in an attempt to fix GNUtoo’s issue. <GNUtoo>I probably need to guix pull if the patch for that is recent <jpoiret>just add this in your config.scm and reconfigure <jpoiret>samplet: there's also a non-redundant deletion in that patch, so all is not lost :) <jpoiret>maybe substitute* should fail if there are no matches? <samplet>GDM on Guix: now with more chewing gum and shoelaces! :) <samplet>jpoiret: That’s something of an old discussion. <GNUtoo>I've that: /system.scm:293:29: error: (gdm-configuration (debug? #t) (wayland? #t)): extraneous field initializers (wayland?) <GNUtoo>So something is probably wrong here <jpoiret>i think it would be possible to have gdm working differently: have `gdm-configuration` contain a `sessions` entry which would be a list of packages (maybe just file-likes) which would have .desktop files <jpoiret>GNUtoo: are you using a recent-enough guix version? <samplet>If I can find time, I’ll see if I can contribute by cleaning up the GDM <-> GNOME Shell dependency cycle hacking stuff (cf. the “XXX” comment in the GDM service. <GNUtoo> commit: c12c7f128418d4e0d8373d6e918547bc7f95abef <jpoiret>you need a `guix` from at least 2 days ago if not less <GNUtoo>ok I don't have the new patch if that's what you mean <jpoiret>yes, GDM wayland came with the big merge <samplet>jpoiret: I have to go now, but thanks for helping make sense of everything! <GNUtoo>So I need to guix pull and re-test <jpoiret>samplet: there is no way to clean that up <GNUtoo>So it'll take some time (and probably days if nss has to be tested again) <GNUtoo>Anyway thanks a lot for the help!!! <jpoiret>are you on an arch with no substitutes? <GNUtoo>It's a long story, but I've not made the switch to x86_64 yet on my main laptop <GNUtoo>And there are substitutes for many things but I also often have to build things too <GNUtoo>What prevents me from switching to x86_64 is that I share my home and a postgresql data directory between Guix and Parabola i686 <GNUtoo>And homes sometimes have cache for binaries as I understand <GNUtoo>And also I can't reuse the same postgresql data directory between two different architectures as I understand <civodul>sneek: later tell luis-felipe i'm pushing a fix for liferea in a minute! (it requires libsoup 2.x) <NicholasvonKlitz>or is there a way to work with capture groups, so that I can replace the lookbehind with a capture group that I disregard? <nckx>How do you not get an error from using \s rather than \\s? <civodul>rekado_, nckx, efraim: i'm going to reconfigure berlin to get an updated 'guix' package, which in turn should allow us to update guix.gnu.org <nckx>But \s isn't a valid escape sequence. <NicholasvonKlitz>yes that's why I was wondering what alternatives are. I can't find a list of valid escape sequences <nckx>What alternatives? You're just missing an \. Write \\s, then you'll get a different error (invalid preceding regular expression). <nckx>I assume you read the error. <nckx><even when> Now you're talking about a *different* error, though. <NicholasvonKlitz>nckx: sorry but I'm having trouble understanding the error messages. When it says `Invalid preceding regular expression" #f ("(?<! |^)#.*") `, does it mean the error is in `("^ *#.*")`? <nckx>I think it's a general ‘invalid regexp’ error, not referring to a specific subexpression. <nckx><does guile not support lookbehind (?<!)> That would seem to be the case, I can't get it to like it… <apteryx>it doesn't, AFAIK, look-behind is not part of ERE IIRC. <NicholasvonKlitz>okay well then does anyone have ideas how to match in-line comments without look-behind :) <nckx>NicholasvonKlitz: <without matching single line comments> This feels so cosmetic, does it really matter? <NicholasvonKlitz>nckx: unfortunately it does. due to a bug in gtk4-rs I need to remove comments from a toml file without messing up newline characters <nckx>So it's not just an aversion to empty lines. OK, fair. <nckx>(("^([^#].*)(#.*)" _ code comment) (string-append code "\n")) ; works for comments that don't themselves contain # <nckx>You could probably fix that if needed. <nckx>The brute force of capturing can often compensate for missing PCRE (etc.) features. :) <jpoiret>oh, by capturing too much, you mean that it captures the whole line? <NicholasvonKlitz>nckx: could explain this syntax. I'm having trouble following because of all the dynamic typing :) <nckx>I don't think dynamic typing enters into it. Each substitute* clause is ((REGEXP [VARIABLE…]) REPLACEMENT). Variables are optional. The first one always captures the entire match, which we don't care about, so we give it the conventional ‘I don't care’ name of ‘_’ (this is not magic, just a variable name). The subsequent variables capture each ‘(…)’ regexp group in order. The REPLACEMENT is just scheme code: we append a newline <nckx>to the captured code in Scheme. <nckx>Basically, don't do too much (like negative matching) in your regexp, outsource it to Scheme and throw away the comment there by not using it. <nckx>It's not perfect but I think it works for your case? <nckx>If you care about trailing spaces etc. you can tweak it to omit them as well. <nckx>s/trailing/& or leading/ <guixy>Looks like synfig conflicts with itself... <lfam>The package definitions will have to be adjusted to fix that <lfam>It's a classic case of an impossible propagation graph <tex_milan>hi guix! how to find out why guix upgrade is trying to rebuild locally "nss" even though weather says it is available pre-build? <jackhill>civodul: I found my static-networking-service-type problem from the other day. It was a typo; I had introduced a space at the end of the IP address. Everything I want so far is working now. Thanks again for all the work. I'm super excited to have static v6 configurations now! <lfam>Not sure exactly, tex_milan. The build farm / CI server is currently not operational but undergoing some maintenance. So it may be that the answer to "is the substitute available" was cached, and that information is no longer correct <tex_milan>@lfam it's been that way couple last days. can anybody at least disable tests in nss? it takes 48hours to finish those tests apparently.... <lfam>No, sorry, we aren't going to disable tests or adjust packages to work around this <tex_milan>and can i do it myself in my config? some override? <lfam>It's definitely possible to disable tests on your end <lfam>We understand that it's annoying and inconvenient to be without substitutes, but it's a temporary situation <NicholasvonKlitz>nckx: `successfully built /gnu/store/p33n1z95g12s42jbhcm9mc36xlyqv51n-rust-gtk4-0.3.1.drv` thanks :) <tex_milan>and why guix weather nss reports it has 2 substitutes available? sadly it doesn't tell what version, I assume it is computed based on my config so correct one? <lfam>Hm, I'm not so familiar with how the package transformation works. I see that nss has a custom test phase, but it does check the value of #:tests?, if I understand correctly <tex_milan>(no problem if something doesn't work, I am just trying to understand how it works) <nckx>tex_milan: #:tests? (and all argument keywords) is optional, defaulting to #t. What matters is ‘if tests?’ in the check phase, which will DTRT. <lfam>I do think that skipping the tests may not be a win in terms of "finish quickly", although it depends on your goal. Many packages depend on NSS, so if you change it by using --without-tests, then those dependent packages will also change and need to be rebuilt, even if you already had built or downloaded their substitutes <sneek>Welcome back luis-felipe, you have 1 message! <sneek>luis-felipe, civodul says: i'm pushing a fix for liferea in a minute! (it requires libsoup 2.x) <nckx>tex_milan: ‘guix weather nss’ doesn't look at or care about any ‘config’. It checks whether the default nss package (guix show nss) in that invoked version of guix is available. ***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
<tex_milan>thanks, looking into it. for some reason my .cache/guix/..../ has non-master (old) even I run guix pull. <nckx>I.e. ‘guix build nss’ should download a substitute. If it doesn't, that's weird and unexpected, if it does, and then doing [something else] still builds nss, it's a different build of nss. <tex_milan>other thing: guix install nss does install substitue. no problem. but one other package that has it as input causes this rebuild..... <lfam>Anyways, that means it's a different nss package. Guix will never rebuild something that it's already downloaded, unless you do `guix build --check nss <nckx>tex_milan: What's the exact nss derivation? Looks like /gnu/store/<hash>-nss-<version>.drv. That file uniquely identifies all build options &c. of NSS. <nckx>nss still seems to be grafted from nss/fixed, maybe that's it. <lfam>Huh, I didn't realize we still had grafts <nckx>It was a surprise for me too, so don't entire exclude PEBKAC just yet. <lfam>Is it a replacement (i.e. graft)? <lfam>I think it's merely inheritance <nckx>I mean it's not a replacement. <tex_milan>perhaps it is because my guix is behind for some reason? I did guix pull <nckx>It doesn't seem to be used? <nckx>That's why I'm a bit suspicious. <lfam>Hm, worth checking that state of the tree from before the merge. Could be a mistake <lfam>tex_milan: It will help us give advice if you share the exact nss derivation <lfam>It should be printed in the output of the command that causes it to be built <tex_milan>Derive([("bin","/gnu/store/9x7y4l7cxzrd7hxnhcrm1gjm3zxp0ca2-nss-3.59-bin","",""),("out","/gnu/store/lvikmfxcjjpybvy7q9m1rvx7cjd3vib3-nss-3.59","","")],[("/gnu/store/2ggaz5f8xh3c5hjzr21k9v9mf4s1yh2c-perl-5.30.2.drv",["out"]),("/gnu/store/2mnyswrnfp1al769qadvc77cv4zgc7pm-guile-3.0.2.drv",["out"]),("/gnu/store/2x9wwv8wrscm27sx1jw4klxqy0r7d1d3-grep-3.4.drv",["out"]),("/gnu/store/3wprz0xr81h4f6mn81ca3mr9mbpjb25h-gzip-1.10.drv",["out"]),("/gnu/store/3 <tex_milan>-nspr-4.29.drv",["out"]),("/gnu/store/4kyvrbhvxkw6qs98q98cqb5njjgabs1z-ld-wrapper-0.drv",["out"]),("/gnu/store/6y3gg4g02xa82i4pdjmqq3kkinn8k69r-diffutils-3.7.drv",["out"]),("/gnu/store/9kd454yi2q8f7gdcmwvmvgrc2mry63aq-sqlite-3.31.1.drv",["out"]),("/gnu/store/a0dm94fg4b3qrd9phrl1g9jx46c0zxdq-libfaketime-0.9.8.drv",["out"]),("/gnu/store/caw9v8r1g1aryx35sb6j3mpnbz45m2ma-zlib-1.2.11.drv",["out"]),("/gnu/store/cybxpxqnn21ha691h7f1ig8sxz4xg5pa-gawk-5. <tex_milan>fzw7ldii0ms4plmf6i4yfhvv4vaa24s0-tar-1.32.drv",["out"]),("/gnu/store/g693bffjqhq0sw1d2gwhk2ifn2qjmm2z-glibc-utf8-locales-2.31.drv",["out"]),("/gnu/store/iii1489zf1hi64p75ijr3kb7w1si3dzd-bash-minimal-5.0.16.drv",["out"]),("/gnu/store/j4mjy4zxnrc9clpq2gd0nyc392hp21cl-findutils-4.7.0.drv",["out"]),("/gnu/store/jnr108v040hmk4rgkghfx1nz0pmhgq0p-linux-libre-headers-5.4.20.drv",["out"]),("/gnu/store/mdj4m5ylbfydh29dpkqwfdg3yw30pnpr-xz-5.2.4.drv",["out" <tex_milan>a4bzxys032vmpr3k1-nss-3.59.tar.xz.drv",["out"]),("/gnu/store/rimrr1446kzbpirrd6y8x55iip2rzp9p-binutils-2.34.drv",["out"]),("/gnu/store/sb95jyinvwc0fgks52prw83kajkv0ccy-bzip2-1.0.8.drv",["out"]),("/gnu/store/v4gyxvd1vpv911ararc55pyvd4wcigbr-make-4.3.drv",["out"]),("/gnu/store/va6drddhwaf279izk1lscv1zpa7ainxi-sed-4.8.drv",["out"]),("/gnu/store/w2nhgr30i6sxawl9y06qvryw9wa5zy7g-gcc-7.5.0.drv",["out"]),("/gnu/store/x8wi1gj2m12k3zngh0pxm1sicgzhmwmr-fi <tex_milan>ore/y9vv89w4i22wk2gd68s85wsyaym6cllm-module-import-compiled.drv",["out"]),("/gnu/store/z1i3yn9a25jc2i6xw4mq561wrfxwmfd1-coreutils-8.32.drv",["out"]),("/gnu/store/z22wd37dbvldnln8219h7n961yalsv6r-glibc-2.31.drv",["out","static"]),("/gnu/store/zw7js91xq48gsd5sgddlvncnljp4i0k6-patch-2.7.6.drv",["out"])],["/gnu/store/6w7a2jibzarh9r9lkqfznrqpybxkwgaz-nss-3.59-guile-builder","/gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import"],"i686-linux","/g <tex_milan>z44fl2yn8b-guile-3.0.2/bin/guile",["--no-auto-compile","-L","/gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import","/gnu/store/6w7a2jibzarh9r9lkqfznrqpybxkwgaz-nss-3.59-guile-builder"],[("GUILE_LOAD_COMPILED_PATH","/gnu/store/h2nv8781zwnlnfqafimqj9ya21d8v278-module-import-compiled"),("bin","/gnu/store/9x7y4l7cxzrd7hxnhcrm1gjm3zxp0ca2-nss-3.59-bin"),("out","/gnu/store/lvikmfxcjjpybvy7q9m1rvx7cjd3vib3-nss-3.59")]) <lfam>As well as the result of `guix describe` <lfam>Wait, I meant the filename :) <nckx>tex_milan: Not. The. Contents. <tex_milan>Generation 10 Dec 12 2021 22:59:09 (current) <tex_milan> commit: 4725a85f893767793d1e874642e130146f85dfcb <tex_milan> commit: 9b24cd3b8e36ecd5f9f72926de12597aac954238 <nckx>tex_milan: This is known as flooding and is illegal on IRC. <tex_milan>sorry! /gnu/store/lp43g62s8khr1q2cyy6kjah1s4apqp7q-nss-3.59.drv <drakonis>at this rate you're going to get hit by network flood protection <nckx>Use a pastebin for >= 3 lines :) <nckx>No biggie, it happens, usually once. Seems like you got lucky. <lfam>So, we are currently on NSS 3.71 <lfam>I think this is from before the core-updates merge <lfam>I have to go AFK for a while <tex_milan>ok, so problem is that guix pull doesn't really pull? <nckx>No, because then guix weather wouldn't show a substitute. <nckx>What does ‘guix show nss’ show as version? <nckx>Only paste version this time 😉 <lfam>guixy: There are other conflicts in synfig besides glibmm. The package will have to be overhauled <nckx>Hm, but berlin doesn't have that derivation, neither does bayfront. <nckx>tex_milan: Did you ‘guix pull’ after 10 Dec? <nckx>Remember that ‘guix pull’ is per-user. <nckx>tex_milan: Run ‘type guix’. <unmatched-paren>huh, bizarre, the icecat update has erased librejs and the other preinstalled extensions <unmatched-paren>they still show in the extensions list, but they aren't doing anything... <nckx>I'm a bit lost but good news is good news. <unmatched-paren>drakonis: those extensions are literally the only reason i use icecat over epiphany... <tex_milan>you had to press some switch on those servers ;-) <nckx>tex_milan: Maybe you didn't run the previous pull in the exact context you thought you did (that is not to blame you at all, it happens). <nckx>Or maybe you just angered an elder god, who knows. <tex_milan>uthenticating channel 'guix', commits 9edb3f6 to 3eadcdc (2,961 new commits)... <unmatched-paren>honestly the only thing i'd need in epiphany before i could switch is noscript-like functionality that i can disable on a per-script basis <drakonis>epiphany's update cycles are bound to gnome, arent they? <tex_milan>i did it from the same context as far as I know. maybe something bad in channels config? something that would not report error but caused quiet fail of update? <tex_milan>and I was wondering why it has neovim-0.4 :) <nckx>tex_milan: <quiet fail> should really, really not happen, and certainly not arbitrarily fix itself. But we can never exclude the very unlikely. <tex_milan>i have learned guille and did the update to 0.6 using snippets I found on internet. <nckx>Don't forget that we accept patches from viewers at home. <tex_milan>thanks! works. i used the same / similar things. maybe took yours :) don't remember exactly. <unmatched-paren>nckx: there actually is already a tree-sitter patch. however, it adds the _emacs_ tree-sitter plugin, which does not afaik have a self-contained install option like nvim's TSInstall, so it needs to package the individual parsers, which i think from a cursory look at the patch needs a couple of nodejs changes <nckx>tex_milan: By ‘context’ I also mean that $PATH could have somehow been broken so that you weren't using the right guix in ~/.config/guix/current, but an older ‘unpulled’ one. But it's hard to say after the fact. <nckx>unmatched-paren: Oh boy. <tex_milan>@nckx maybe. i had to use nongnu installer to get it booted on my AMD CPU laptop. maybe that? <tex_milan>@unamtched-paren what do you mean about tree-sitter? build or its architecture? <unmatched-paren>you need to create a javascript program that returns all the rules, then run the tree-sitter command on it which invokes node or something <tex_milan>but hey, maybe it is easier to write rules in js. and then for performance it generates cxx... <unmatched-paren>why not just use a DSL like yacc does? depending on node makes no sense <tex_milan>because yacc / DSL can be a show stopper for many developers who otherwise have no problem with JS. it is web world now outside :) <unmatched-paren>also, although the core library is in dependency-less C, the CLI is Rust, and there are rust and wasm bindings <tex_milan>I eneded in guix because I wasn't able to learn DLS/NixOS. blame me. <unmatched-paren>i couldn't figure out how to package it, luckily someone pointed out that it had already been done :) <tex_milan>hurray, upgrade works and doesn't rebuild nss anymore! :) <nckx>Are you saying it doesn't use Go yet? <nckx>0/10 not a modern programme, needs Go <unmatched-paren>tex_milan: at least java is bootstrappable, try bootstrapping kotlin, groovy or scala <nckx>Java is not Modern, Java is Enterprise. <nckx>When's the last time you heard of a security vulnerability in a Java package? Hmmmmm? *nckx gets flooded off the 'net. <unmatched-paren>Java is not just enterprise. Java is expanding your scalable IoT SaaS big data on to the cloud at exabyte level scale!!!! <nckx>Eleventy-two octillion devices run Java. <nckx>It's not just a good idea—it's the law. <unmatched-paren>Next we'll have companies boasting about their amazing Service as a Service(r) products <florhizome[m]>after configuring stuff in X11 enlightenment, enlightenment wayland started but froze (with the warning acpid cannot be found, also had appeared in X11) <unmatched-paren>maybe alacritty's window looks strange under wayland because of the winit library? <florhizome[m]>Also had some weirdeties with sddm trying different minimalisations of my config <unmatched-paren>winit is a pure-rust windowing lib which doesn't use anything like sdl or glfw, only native windowing system functions <attila_lendvai>BTW, is there machinery to apply a specific commit from a git repo (as opposed to saving it under patches/)? <nckx>attila_lendvai: I don't think so. <attila_lendvai>nckx, too bad. it would make fixing python-daemon super convenient. <nckx>You can point an origin record to the .patch URI as ‘rendered’ by many popular forges like GitLab, but that's not really what you're asking. <nckx>Plus it's not really more convenient than just saving the patch, and (at least in theory) less robust. <unmatched-paren>i wonder if there's some env variable that i'm missing to get winit to use the native theming <tex_milan>unmatched-paren: vlang, hmm. didn't know about it, definitely will look at it. looks interestingly. <attila_lendvai>nckx, saving the patch is a lot more trouble, with updating the makefile, then not forgetting to delete the entry when you delete the patch, etc, etc... <unmatched-paren>tex_milan: ah, vlang is a massive pain, i'd recommend you stay away from it for now until they realize that depending on the executable being in a mutable directory is a terrible idea <jpoiret>is it common to have qemu segfault on you? <unmatched-paren>the author appears to use a mac, which doesn't have a package manager, so i guess you can't blame them <florhizome[m]>Does someone know how guix uses gnu mes and how it compares to debootstrap? <nckx>Ohkay. It's subjective then. I find that less work. I still recommend shipping the patch file with Guix if you intend to commit this to Guix. The robustness argument has won out, and direct origins aren't that common anymore. <tex_milan>unmatched-paren: oh. that's bummer. i just saw vlang vs go and it looks interestingly. thanks for warning! <drakonis>use odin if you want something that's like it but done right <drakonis>v is a horrifying language with absolutely horrifying packaging <florhizome[m]>jpoiret how do apply the arguments to guix system vm you recommended? <jpoiret>just add them as args to the script `guix system vm` produces <nckx>Did something happen in ~2000-2010 that just erased all knowledge of how to package things from human brains? <nckx>Was Nix/Guix dreamt up in a Faraday cage? <jpoiret>i'm currently testing something in a vm using "$(./pre-inst-env guix system vm ../sway-vm.scm) -m 4096 -smp 4 -enable-kvm -vga virtio" <unmatched-paren>huh, i'd never heard of odin, from the website it does indeed look like a better C like v looked to me until i saw the packaging <jpoiret>nckx: i think the overwhelming majority of devs now don't have the same background as before <attila_lendvai>nckx, it's much easier to fix by disabling the tests until the next release. but i don't get your reference to direct origins? you mean pointing to the git repo (as opposed to pypy)? <jpoiret>mass produced, use web frameworks with thousands of deps, want an easy one line install without thinking about the ramifications etc... <unmatched-paren>i don't understand the obsession with macs among developers; it seems almost objectively worse than gnu/linux even if you ignore freedom issues <jpoiret>that's what the go modules system seems like to me, as well as npm, and rust to an extent <nckx>attila_lendvai: I meant something like (patches (list (origin … ))) pointing to something like gitlab.com/foo/bar/blah/commit.patch, as a way of cherry-picking a single commit. <tex_milan>heh. good luck using anything like npm, modules or whatever if you really need security. <jpoiret>also, I think that people have been told to reuse code too much, to the point where every single stupid snippet on the planet is an unmaintained go package from 5 years that serious widespread software still depends on <nckx>It's for the Web, you don't need security. <florhizome[m]>jpoiret: no there also seem to be a fair amount of ppl that study “proper” compsci and use python and do ai everywhere <tex_milan>true. my bias is industrial automation firmwares. so you end up with c++98 and 10years old libraries :) <nckx>jpoiret: That was one of the things that struck me about the Guile (maybe, Scheme) community at first: less ‘DRY’ than was hip everwhere else. <attila_lendvai>nckx, oh, i see. i wouldn't do that... i think even what i proposed would only be nice to use when you point to a commit in the same repo as the origin points to (i.e. a commit after the release tag) <jpoiret>yes, i'm still mad about the official protonmail bridge app in go, but they depend on 7 years old code (!!!) <LevyElara[m]>florhizome: v still leaks memory for hello world by default <nckx>attila_lendvai: I thought you meant, say: check out the ‘release-X.Y tag, then apply this single (much) later commit’. <jpoiret>nckx: the language helps tremendously i think. Very powerful abstractions and less boilerplate without requiring 50+ packages <unmatched-paren>well, lisp strikes me as extremely DRY language, but not in the sense of 'use a load of other people's packages' and more 'all the macrooooooooos!!!' <nckx>If you just want to check out an arbitrary commit, that is trivial, there's an aptly-name ‘commit’ field for that ☺ <tex_milan>oh. it is building qt-base. that's probably even worse then nss :) <nckx>I'm not saying it's good or bad, but calling it ‘a different kind of DRY’ is very apt. <Brandong[m]>wop wop wop, that's some WET-ass parens. Grab a bucket and a mop. <florhizome[m]>What are the opinions on nim? Seems to be used in GNUnet applications so it can’t be that bad? <attila_lendvai>nckx, what you described is what i meant. sorry if my wording was confusing! my last point was only that such an "extra" patch-commit would come from the same repo most of the time. <vagrantc>many of the style commits move inputs from one line per input to a long line or a few long lines of inputs ... makes it much harder to read diffs when inputs change :/ <tex_milan>guix weather qtbase ... it tells me 100% substitues available at ci.guix... and 0% available at bordeax... why it is building it locally and not using the ci.guix substitute? what version it checks against? <vagrantc>and by many, i guess i meant a small number of them that i saw ... maybe that's not the norm. <nckx>Again, the default qtbase (‘guix show qtbase’) provided by the exact guix binary you invoked on that command line. Guix packages are ‘part of’ each guix command for practical purposes. There is no package manager binary + external package data ‘repo’ as with other package managers. <unmatched-paren>apps that use gtk are unaffected, but things like alacritty and kitty are ignoring the gnome theming <attila_lendvai>is pypy mirrored into the software heritage archives? IOW, is it better to point origin to a github repo, or to pypy? <nckx>Git if you ask me, if it's not missing stuff from the pypi tarball (like tests!). <nckx>I am not aware of a policy that transcends individual maintainer preference, though ☺ <florhizome[m]>unmatched-paren: I think kitty has an option to use system titlebars <nckx>attila_lendvai: I don't know if SWH mirrors pypi, good question. <unmatched-paren>but for some reason it's using a default cursor too, and there are errors in the console about it <unmatched-paren>[349 19:04:29.060621] [glfw error 65544]: on_gnome_cursor_theme_read: failed with error: [org.freedesktop.DBus.Error.ServiceUnknown] The name org.freedesktop.portal.Desktop was not provided by any .service files <jpoiret>you need to install xdg-desktop-portal <jpoiret>although that won't change much I think <jpoiret>by the way, this is dbus (another init system replacement, less evil this time), not systemd <nckx>Lots of important end-user packages failing to build on my substitute server: gimp, wine, mpv, … <nckx>Seems like it's all due to python2-pygtk. <jpoiret>you need to logout and login as well I'd say <jpoiret>since dbus is already started and has already scanned the available service files <unmatched-paren>ok, i've also installed xdg-desktop-portal-gtk, just in case. and now i'll log out... <nckx>While you were typing that I noticed: Generation 299 Dec 15 2021 04:09:53 <nckx>It should pull every 5 minutes if new commits are available… <jpoiret>unmatched-paren: good catch, that should be needed as well <nckx>jpoiret: Glad to hear it was fixed! *vagrantc fires up the guix space heater and continues compiler <unmatche1-paren>[349 19:08:48.984257] [glfw error 65544]: Failed to connect to DBUS session bus. DBUS error: Failed to connect to socket /tmp/dbus-1IbWjXrXHi: Connection refused <jpoiret>glfw connects to dbus? this is preposterous <jpoiret>i think you'll have to set the cursor theme using something dconf-related <unmatched-paren>i'll try fiddling with gnome-settings, maybe it'll reset some stuff or something? <apteryx>nckx: yuck, where does python2-pygtk rears its head in the graph? <nckx>apteryx: That turned out to be only for GIMP (which directly depends on it), I didn't look at the rest yet. <nckx>There is no UI on this thing. <nckx>The missing linkification? Something else? <rekado_>zimoun: could you try Ctrl-F5 to refresh your CSS cache? <nckx>zimoun: I don't see any weirdness. <rekado_>btw: this looks like the system has been rolled back <rekado_>I think that’s what Mathieu did in an attempt to get cuirass back to work. <unmatched-paren>if someone's willing to get a vm with wayland gnome working i'll send over my config <zimoun>civodul: about offload “guix build --check”, to be to understand: build sends a request to the daemon, the daemon then call “guix offload”. So, IIUC, to offload --check, it is about hook. Right? <attila_lendvai>what is this new (?) sanity_check.py? it fails for trezor-agent, even though the output seems to work. shall i just delete the phase? <nckx>I also don't understand the phase (it is extremely Pythony!). <nckx>Simply deleting it does not sound like a good first step. <attila_lendvai>i *think* it's something for python *libs*, but this is a "toplevel" app with a wrapper script. but i also don't understand it. <opalvaults>Which env variable is responsible for .desktop files? It seems as though /etc/profile.d/guix.sh is set correctly, and all of my variables point to where I think .desktop files should be for the guix package manager but are there other places that guix stores .desktop files that needs to be set? <lilyp>I think we need a better input function for modify-* <lilyp>the current rules break the common use of append elsewhere <nckx>guix system: error: failed to load '/etc/guix/system.scm': <nckx>ice-9/eval.scm:159:9: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <apteryx>lilyp: ah, that's why my appends have been looking weird as of late. thanks for spotting it <nckx>‘Oops, something went wronng :(’ <lilyp>apteryx: i don't think append or prepend need any special rule anyway <nckx>You had me tab-completing prep just in case. <lilyp>(append pkg1 pkg2 pkg3) would still be the same as before, with an implicit list being formed and everything but still ***zxtx_ is now known as zxtx
***unmatched-paren is now known as Guest1812
***unmatche1-paren is now known as unmatched-paren
<civodul>rekado_, nckx, efraim: berlin reconfigured! (maybe an hour ago actually) <unmatched-paren>looks like gnome dropped support for window decorations on the side of the wayland compositor... <unmatched-paren>anyway, setting kitty to use xwayland reenabled server side decorations for it. <lilyp>isn't doing decorations outside of the compositor the holy wayland grail? <nckx>Oh, or maybe thank you civodul (too). <lilyp>unmatched-paren: i might be wrong, but one appeal of wayland was to throw out stuff the X server didn't need because toolkits already implement them on their own anyway <lilyp>because they're no longer gnomified? <rekado_>I booted up kreuzberg (the third of the aarch64 nodes on my desk) and hooked it up to my router with a cable that I ripped out from elsewhere <lilyp>i suspect gnome apps do still do their beautiful header bars tho, right? <lilyp>yeah, so basically anything built on gtk will use gtk widgets, but other stuff uses whatever <podiki[m]>glad to see the CI back up! plenty for it to do now :) <unmatched-paren>ok, so libdecor aims to be a solution to the titlebar problem eventually, but doesn't fix it yet <lilyp>sounds a lot like solution selling to me <lilyp>What if you wanted to reconfigure your system, but then building /gnu/store/an1jrr0pn55bqnac3akw5nyw1fbyv8h4-qemu-minimal-6.1.0.drv … <lilyp>I can't, the only way is forward :) <lilyp>Except in the case of renpy, which really needs to go to Guix Past soon <ngz>Hello. I tried to move to a modular texlive, so I created a manifest file with (specifications->manifest '(... some texlive packages...)). Unfortunately, I'm not able to compile even the simplest LaTeX document. Am I supposed to add `texlive-updmap.cfg' somewhere, somehow? <lilyp>stupid question, but are you using/have you looked at texlive-union? <lilyp>IIRC it works like sdl-union, so you can do your own combination (assuming the combination itself makes sense, which idk which ones do) <ngz>IIUC, texlive-union is deprecated in favor of `texlive-updmap.cfg', hence my question. <ngz>But, I wouldn't know where to insert texlive-union anyway. <ngz>Something like (specifications->manifest '(texlive-union (... some texlive packages...))) ? <ngz>(BTW, what's wrong with Renpy? It hasn't moved to Python3 yet?) <rekado_>ngz: you don’t use texlive-updmap.cfg in your manifest <rekado_>installing the texlive-* packages into your profile should be enough <ngz>Unfortunately, I get "I can't find the format file `pdflatex.fmt'" <ngz>which is pretty depressing <rekado_>the general approach is simple, though: install texlive-base and whatever else you may need. <ngz>My manifest contains textlive-base. I also added texlive-etex, just to be sure, but it doesn't help. <f1refly>I still couldn't figure out why I don't have a clipboard, any idea what could cause this? <f1refly>when i try putting stuff in the selection and reading it again with xclip it doesn't work as well <attila_lendvai>"0.0% (0 out of 32) of the missing items are queued" -- and yet i'm building qtbase locally, even though qtbase is not listed as a missing item (using --display-missing). is this an anomaly? or do i have wrong assumptions? <attila_lendvai>(i have some local commits, but nothing that should affect qtbase) <rekado_>ngz: could you share a little reproducer for us? <rekado_>an issue like that was reported to help-guix about a month ago, but the resolution was “it works now, don’t know why, lol” <podiki[m]>civodul: great! looking forward to reading and learning the new tricks <rekado_>civodul: thanks for publishing this! <rekado_>oh, and for writing it. Oh, and for implementing this tricky feature that looks so smooth and simple from the outside. <ngz>rekado_: Well, the manifest it a poor man reproducer. You cannot compile anything with it, even \documentclass{article}\n\begin{document}\nfoo\end{document} <podiki[m]>keyboards around the world will thank civodul for less keystrokes! <podiki[m]>(seeing repetitiveness in a lisp always makes me think there's a better way) <rekado_>revamping all the texlive things is near the top of my list for the time after the c-u-f merge, so I guess I’ll get to it sooner now. <jacereda>hi, I've just installed guix and my first reconfigure attempt seems to get stuck in the check phase of qemu-minimal, any idea? <rekado_>jacereda: you’re unlucky not to have been able to download a binary for qemu-minimal! <rekado_>the check phase takes quite a long time to run <jacereda>rekado_: is there any way to pull a different hash where qemu-minimal is in the binary cache? <rekado_>(the build farm was inoperable for a few hours and so hasn’t been able to build a few things yet) <rekado_>jacereda: yes, you can pull an older version of Guix. <jacereda>ok, thanks, I gues I'll let the build farm do its job and retry tomorrow, it's late here :) <KE0VVT>Is it bad to do (packages (append (list tmux git emacs) %base-packages))? <rekado_>“append” is a perfectly fine way to make a bigger list out of two smaller ones. <ngz>(cons* tmux git emacs %base-packages) is arguably nicer. <KE0VVT>rekado_: The installer seems to insist on writing (packages (append (list (specification->package "emacs") (specification->package "emacs)) %basepackages)) <rekado_>…and it uses the very common English word “cons*”, not this arcane “append” :) <rekado_>KE0VVT: the installer does this for maximum readability and portability <ngz>who speak english anyway? <rekado_>KE0VVT: specification->package lets us use the names of packages without having to know where the package variable is defined, so that’s neat. <vivien>civodul, good, less assoc-ref and more semantic macros <rekado_>and “append” just works, whether you just add a few more packages or remove some. <rekado_>the type is always obvious: this is a list and that is also a list. <jacereda>BTW, the default config.scm has to be tweaked due to bootloader and swap configuration <rekado_>KE0VVT: with cons or cons* that’s not always true, and we’ve confused quite a few people with our use of “cons” in generated configs. <rekado_>“no idea what %base-packages is”, but I guess with cons I can add things to the base packages? <KE0VVT>rekado_: What is (cons) and (cons*)? <ngz>Anyway, now it is #~(#$emacs $>%base-packages), thanks to gexps ;) <rekado_>and then they did (cons emacs vim %base-packages) and got a confusing error. <rekado_>KE0VVT: cons conses an element onto a list <KE0VVT>ngz: Those gexps look absolutely horrid. <KE0VVT>ngz: Are they trying to turn Lisp into Perl? <vivien>rekado_, `(,emacs ,vim ,@%base-packages) is more robust <rekado_>KE0VVT: cons* (“cons prime” for variant of “cons”) is like “cons” but it can cons more than one element onto a list. <KE0VVT>So what is (specification->package ...)? <rekado_>so it takes a bunch of elements and the last one must be a list. <rekado_>specification->package turns a package specification — i.e. a string like “emacs@28” into a reference to a package variable. <rekado_>that package variable might be called “emacs-next-pgtk” or whatever. <rekado_>it gets you the first part that comes after the “(define …)” <rekado_>…when you give it the value of the “name” field of that package <rekado_>(that sounds much more confusing than it is. Sorry.) <jacereda>is it possible to completely replace sudo with doas? <jgart>rekado_, thanks for sharing that vid, very impressive! <rekado_>ngz: FWIW I just ran “guix shell -C -m ~/your-manifest.scm” and then inside that environment ran “pdflatex some.tex” with the simple foo document you pasted here. <rekado_>it also said “pdfTeX warning: pdflatex (file pdftex.map): cannot open font map file”, and I believe it because font maps are weird. <rekado_>and that document contains a gloriously formatted “foo”. <rekado_>maybe it’s old configs, state in your home directory? <ngz>I'm trying something more radical: I rm -Rf ~/.texlive2021/ <rekado_>(better run this from outside of ~/) <rekado_>sometimes I wish there was an alternative to “rm -rf” that more fully captured my anger. <ngz>It didn't change anything. I'm trying the container now. <rekado_>for the record: I tried this with guix 6786336 <rekado_>(that’s not a version number, it’s a partial hash) <ngz>So it's fairly recent. <rekado_>maybe strace it and see if it touches some weird files? <rekado_>it’s entirely possible that our packages are misconfigured and only the sterile environment of a barren container accidentally makes it work. <ngz>Juste "strace latex foo.tex" ? <rekado_>strace -f -o ugly.log -s 2048 pdflatex foo.tex <drakonis>its kinda hard to find an appropriate title to use for linking to the new blog post on hn and lobsters <ngz>rekado_ the output is too large for paste.debian.org <nckx>I guess if you don't someone else will, and at least you can control the narrative—er, title this way. <nckx>‘Guix ran a linter that broke everything’ would be worse. ***atw` is now known as atw
<drakonis>as guix comes with its own home manager equivalent <vagrantc>guix weather nss and guix build nss both error out with: "error: nss: unbound variable" while guix build u-boot-tools proceeds to build a derivation for nss ... i am confuzed <vagrantc>with guix 3eadcdc63eb4ea16eb4dc1e8ee7fb369e04ffb52 <podiki[m]>is nss hidden maybe? (vs nss-certs or whatever) <nckx>I think it's because zlib is missing. <nckx>error: zlib: unbound variable <podiki[m]>yeah not great when the code notes a 60 hour timeout... <nckx>podiki[m]: It's not hidden. It also works with ./pre-inst-env, not without it. <podiki[m]>works fine as package input (was building something other day and could add it just fine), but did notice you can't just 'guix build nss' <rekado_>ngz: that’s expected. It’s a huge dump and most of it is not useful. <rekado_>but perhaps you can search for /home/ngz to see if it accesses something unusual <nckx>Is this a circular module reference symptom? <nckx>gnu/packages/commencement.scm:461:13: error: tcc: unbound variable *vagrantc wonders if it's worth considering some alternate compression for the logs in /var/log/guix <nckx>bz2 is literally not the best at anything anymore. <vagrantc>bz2 seems not a great compression/cpu/etc <nckx>Except ‘compatibility with bzip2’. <ngz>rekado_ Unfortunately, I don't know what would be "unusual". Is there a way to update kpathsea results somehow? <vagrantc>are those logs used programatically at all, or are they basically just there to manually peek at things? *vagrantc can't even find where in the code it actually uses bzip2 <nckx>See libstore/build.cc line ~2570 <nckx>(#if HAVE_BZLIB_H, because it's relative new, you know.) <vagrantc>would almost welcome gzip for a reduced dependency set, even <vagrantc>though the obvious one to add would be zstd ... <nckx>I was coming from another angle with xz, but it just confirms the ‘anything but bz2’ point. <vagrantc>xz seems pretty slow and so-so these days <vagrantc>how did i become opinionated on compression algorithms? <nckx>Doesn't it still compress better than zstd? <nckx>As in, even if zstd -22 can do better, it's actually slower then. <vagrantc>in my experience the default compression is still better with zstd <civodul>vagrantc: re nss "unbound variable", you found a bug <podiki[m]>as one that knows nothing on compression, how much a difference are we talking in ratio for plain text (logs) vs speed for these? <nckx>civodul: Does the circular module reference hypothesis hold water? <ngz>rekado_ it seems I'm very confused with LaTeX innards, so I cannot properly understand the issue with my configuration. Thanks for taking time to reproduce the problem anyway! <nckx>I'd very much like to know your algorithm for approaching those. <civodul>nckx: i'd look for inherits of packages from other modules <nckx>My ‘type random stuff into a terminal’ one isn't working so far. <civodul>and/or add (set! %load-verbosely #t) somewhere, to see which modules get loaded <nckx>Well, nss-certs inherits nss' source… <nckx>Thank you for that tip! I'll try now. <vagrantc>zstd --adapt ... wow ... basically adjust according to the workload at the moment <nckx>vagrantc: I wonder what the API for that looks like. If it's available as an easy option, great.