<bdju>I could also downgrade my grim to fix it, probably, but the process seemed complicated to me, and also that isn't an ideal fix anyway <nckx>Which version ‘works’? Or what's the watershed commit? <bdju>if it downgrades for everyone that should be easy. I think besides the rotation, not much changed in grim for the current version ended <bdju>version of guix or of grim? <bdju>1.3.0 should work I think <nckx>I don't know if it will downgrade for everybody. I think users of ‘guix package -u’ might stay stuck on the new version. <bdju>ah. well, I typically just apply my manifest unless I'm holding back a broken package, so I think it'll work for me at least <bdju>would they have to specify a version with an @ otherwise? <nckx>Yeah, it's likely I was the one to update that. Those release notes seem familiar. But not clear that this is a breaking/flag day change... <nckx>I use manifests excluively, so not sure. <nckx>‘guix install grim@1.3.0’ would work but not sure how ‘upgrade’ would. <bdju>yeah, I'm surprised they didn't put a note about it. I think grim and sway even had several days between updates in general so surely other people had breakage at some point <nckx>Hm, mcron on one of my servers has a zombi child. Is that common? <nckx>bdju: I went ahead and pushed that patch to master. Do let me know if it doesn't fix the issue. Good night! <bdju>thanks! will take a look. <bdju>(sorry I missed the last message, although I don't actually know how to test a patch like that, so maybe it worked out in the end) <joshuaBPMan>what do you all use instead of spamassassin? guix doesn't seem to have it installed. <luis-felipe>I'm reading the Rust book and there is a linter called clippy. In Guix, it seems to be packaged as rust-clippy. However, after installing it, the clippy command is not found. <luis-felipe>For example when running "cargo clippy" in a terminal or "rust-run-clippy" in Emacs. <luis-felipe>So I don't know if I'm missing something or if this is a bug in rust-clippy... <mroh>joshuaBPMan: bogofilter, maybe. <mroh>luis-felipe: rust-clippy pkg doesn't seem to have any output. Look's like a bug. <Brendan[m]2>i wish guiles backtraces wouldn't just elide all the important bits and truncate everything <jonsger>sometimes COLUMNS=300 or so helps, but not always <Brendan[m]2>in a package build though? that would require changing it inside guix wouln't it? <jonsger>Brendan[m]2: yes, that is the problem. It would need to be changed inside the daemon <Brendan[m]2>is guile upstream interested in simply changing the default? <Brendan[m]2>what procedure returns the file name with the .suffix removed? <Brendan[m]2>just dumping a thought but i feel that string-append is a function whose frequency of use * name length is extremely high. i always feel like it would be nice abreviated to str or something like that <Brendan[m]2>mbakke so i have a question with regards to the greetd service. the graphical greeters wlgreet and gtkgreet run inside a wayland compositor like sway or cage. I'm using sway. Now, with wayland, loading keyboard layouts is considered outside the scope of the project; rather it's the compositor that should do that. Sway can load keyboard layouts from its own config or i think via environment variables. In the context of guix, <Brendan[m]2>there doesn't appear to be any xorg-configuration service, rather there is simply the xorg-configuration type which is passed around and used by whatever needs it. What do you think is the correct way we should retrive the system XKB layout and enable it? <bdju>nckx: I had a lot of packages to build when I updated, but I finally got to test grim now and it works!! thank you for the downgrade <bdju>(or rather than a lot to bu ild, the ones that built took a while anyway) <jonsger>Brendan[m]2: can confirm, I guess it comes from f43ffee90882c2d61b46d69728daa7432be297e4 <jonsger>civodul: f43ffee90882c2d61b46d69728daa7432be297e4 breaks guix pull <civodul>jonsger: yup, workin' on it, thanks for the heads-up! <GNUtoo>In the manual there is the following: <GNUtoo>guix system disk-image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' <GNUtoo>Is it possible to do the same in an scm file? <civodul>definitely, and it'd be more readable <GNUtoo>If so how do I use 'A20-OLinuXino-Lime2' in it? <civodul>the "@" thing is to access a binding within a module <civodul>(os-with-u-boot installation-os "A20-OLinuXino-Lime2") <GNUtoo>can I still define operating-system in that case? <GNUtoo>like: (operating-system (host-name <civodul>here it's using "installation-os" as the OS <civodul>which is the OS definition of the installation medium (with the installater GUI, etc.) <civodul>but you can replace it by your own OS definition <janneke>mothacehe: on current master building a hurd image like this, is broken: , ./pre-inst-env guix system --target=i586-pc-gnu disk-image gnu/system/examples/bare-hurd.tmpl <civodul>like (os-with-u-boot (operating-system ...) "A20-OLinuXino-Lime2") <janneke>it seems that "target" was dropped from 313f492657 scripts: system: Add support for image-type; am i missing something? <mothacehe>No target is still there the new "-t" option is the image type. <zimoun>In term of release, what bug are totally blocking? <zimoun>hey mothacehe! Really cool all the stuff about Cuirass &co :-) <civodul>zimoun: oh, when are we having that hackathon? <mothacehe>janneke: but not that passing --target will be become the deprecated way of doing this (hopefully). guix system -t hurd-raw disk-image my-os.scm should work. <zimoun>civodul: when you want. Personnally, I will do some work today. <zimoun>civodul: the open question is about the freeze? <civodul>zimoun: i mean, what's the date we agreed upon? :-) *civodul feels disorganized <zimoun>I will try to address 43744 (guix-install.sh) today if non one beats me. Dany mentioned #43513 is blocking. <janneke>mothacehe: great, this works: ./pre-inst-env guix system --image-type=hurd-qcow2 disk-image gnu/system/examples/bare-hurd.tmpl <mothacehe>janneke: nice, I'm still looking at your issue <zimoun>With cmake-build-system, what is the easiest to remove one specific test? <mothacehe>janneke: hmm I can reproduce, it tries to native build "hurd" package itself. <civodul>zimoun: not sure, probably commenting out the file name in CMakeList.txt <mothacehe>janneke: oh found out why, my bad. "target" can now be set in the <image> record or by the command line. Here the #f target from the <image> takes precedence over the "target" from command line. <mothacehe>target from command line should maybe override the target from <image> record. <GNUtoo>Does guix support cross compilation / installation? <GNUtoo>../../pre-inst-env guix system disk-image --system=armhf-linux stage1.scm <GNUtoo>The host is x86_64 and the target armhf <GNUtoo>while setting up the build environment: executing `/gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile': No such file or directory <GNUtoo>$ file /gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile <GNUtoo>/gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /gnu/store/llkv94k15spryi6zf0gjm0fp7m8k3i8g-glibc-2.31/lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, not stripped <GNUtoo>The host can run that file thanks to the libre/qemu-user-static-binfmt Parabola package <GNUtoo>$ /gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile <civodul>GNUtoo: --system is *not* about cross-compilation <civodul>so you can do "-s i686-linux" on x86_64, but not -s anything <GNUtoo>oh ok, can I create an image for an ARM board on an x86 computer? <civodul>that would be --target=arm-linux-gnueabihf *janneke is afk for a bit *GNUtoo starts reading that <civodul>looking at the "important" bugs, some that strike me as "more important" would be the guix-install.sh thing i posted yesterday and the git clone lack of progress report: https://issues.guix.gnu.org/39260 <zimoun>civodul: I am planning to work today on guix-install.sh #43744 <civodul>i think it can make a significant difference to newcomers <zimoun>mothacehe: is the “looping for ever” bug (partitioning step if I remember crrectly) in the installer fixed? <zimoun>mothacehe: cool! I have just seen recent random demos on Youtube&co. complainaing about that. <mbakke>Brendan[m]2: it would be good to make use of the (keyboard-layout ...) field and expose that to the wayland compositors somehow. <civodul>we should do another round of installer tests <mothacehe>civodul: the installation tests have been successful for a few weeks <civodul>mothacehe: yes, that's what i mean, on real hw <civodul>but hey, thumbs up on getting all those tests in a good shape! <civodul>it was "pas gagné d'avance" as we say ;-) <mothacehe>haha yes the container hack was a bit desperate <guix-vits>Can someone test if `guix graph webkitgtk |xdot -` works? <Brendan[m]2>I'm on Sway and sometimes, like just now, my system totally freezes up such that i cannot even switch tty. the only thing i can do that has an effect is suspend with the power button. after hard rebooting i cant find anything in the logs that indicates anything went wrong. how does one debug such things? *zimoun is grumpy. Unexpected "have to go office" and rainy weather. AFK ~1h. <nckx>guix-vits: Yes, as civodul was probably going to tell sneek, who is dead. <divoplade>In my (limited) experience, these freezes are due to the computer being out of memory. Do you have a swap partition? <Brendan[m]2>i created a swap file. it did occure while i was compiling packages <Brendan[m]2>and its usually like that for me too. im not sure if it was or not this time. years ago with linux it used to just get laggy and then fix up when more ram was free. i think linux has changed over time and now it tends to just die <nckx>Brendan[m]2: Is your HDD led lit up the whole time? That's the easy way to tell. <numerobis>Hi #guix! I struggle a little bit to understand the difference between /root/.config/guix/current and /root/.guix-profile. In various places (e.g. in the documentation and in hints after sudo guix pull), it is suggested to define, GUIX_PROFILE="`echo ~root`/.config/guix/current", which confuses me a bit (I would think GUIX_PROFILE should be set to /root/.guix-profile). Is there a quick exlpanation of <numerobis>the difference between these directories somewhere? <Brendan[m]2>does anyone else get this "failed to load cursor theme adwaita" when running just about any gui application? <nckx>numerobis: /root/.config/guix/current contains the latest guix from ‘guix pull’. /root/.guix-profile is where it installs packages by default. <nckx>I assumed it was because I don't have the adwaita cursor theme 😛 <nckx>Isn't it harmless? I've never seen a missing cursor in years, and Adwaita is fugly. <numerobis>nckx: Thank you very much, I think I am starting to understand, and indeed is see that ~/.guix-profile/bin does not contain the 'guix' executable. <Brendan[m]2>well my cursor changes size depending on which window its on. each toolkit has to set it on its own you see <nckx>numerobis: If you ever ‘guix install guix’ it would, but you should never do that. You'll end up in a downgrade cycle since Guix revision N always contains the N-1 revision Guix package. <Brendan[m]2>wayland doesnt deal with that, so gtk, qt, etc all have to do it their own way <nckx>Which 2 applications would illustrate the size difference? I'm on Wayland+Sway if that matters. <Brendan[m]2>it used to be that moving up to waybar made it bigger, but that doesnt anymore after update <Brendan[m]2>to anything. make a floating emacs and move from the mode line to your background *mothacehe found yet another Cuirass bug and wonder how such a simple tool can be that complex. <nckx>Brendan[m]2: tobias.gr/cur - I don't see it. <nckx>Hah, grim does not capture the cursor. <civodul>mothacehe: i think it's mixing several things that don't work together well: Fibers, sqlite, the daemon protocol, etc. <nckx>Brendan[m]2: You'll have to take my word for it that GTK emacs had the same cursor last week. <nckx>I'm interested in yours. <mothacehe>civodul: Yes, you're right. The situation is slowly improving but I fear that Cuirass will remain quite complex & fragile. I was so pissed yesterday, I even considered a full C++ rewrite. <divoplade>numerobis: My .profile looks like this, and it seems to work :) <divoplade>GUIX_PROFILE="$HOME/.config/guix/current/" source "$HOME/.config/guix/current/etc/profile" <civodul>mothacehe: it's tempting to reap the nice bits apart and build something new from that <civodul>the bit that does "while true ; guix time-machine -- build x y z; done" should be this simple <nckx>Brendan[m]2: Oh, it's not the size, it's a different bitmap. Isn't that Adwaita on the left? It looks very similar. <Brendan[m]2>I get this one too Unable to locate theme engine in module_path: "adwaita", <mothacehe>civodul: yes the time-machine example is super nice, but part of the complexity comes from the fact that scaling is hard here. Having 10 concurrent evaluations evaluation around 70K derivations can be hard. <Brendan[m]2>same for murrine. i wanted to install murrine but it propagates gtk2 which conflicts, so i cant even put that in my profile <nckx>My cursor doesn't change in GTK emacs either, so your toolkit is doing more than mine but it doesn't seem to be Wayland-mandated. <nckx>I don't use themes though. <nckx>But the fallback is at least consistent. <civodul>making it multi-process can help, too <jlicht>If I build an image/container/vm of a Guix System, the 'guix' in there will refer to all packages as they were at the version/commit of the `guix' package itself, right? <civodul>mothacehe: conceptually Fibers give us something that's "multi-process", but experience has shown that there's no shortage of blocking operations, and that it's hard to inspect it (there's no "ps" command for Fibers) <jlicht>nckx: Thought so indeed. If you want to make an 'updated' image available, the path of least resistence is to 'upgrade' the version of the guix package before building? <jlicht>civodul: in my (limited) experience with green threads in other languages, I always used them to accept input/jobs and quickly put them on some queue that is consumed by a dedicated (non-green) thread. You can still bolt on some kind of 'ticketing' so you can later query the system as to what happened to your actual request <nckx>Well, it's what I would do, but maybe there's an easier way to copy the ‘building’ Guix into the image (what you're doing manually). <civodul>jlicht: interesting; i think there's something similar here (an evaluation fiber, a build fiber), but it's a bit more fuzzy <civodul>and we use "real" threads only in specific cases <mothacehe>civodul: linux freeze :( I think too that the multi-process thing could help. I made sure that all the "read-derivation" calls were contained in the evaluations process. <civodul>it's kinda ironic: Hydra was multi-process and i found it silly, esp. how they use the database to communicate to one another <jlicht>civodul: ymmv, but having a channel-like structure (in memory or via an actual db) makes it a lot easier to reason about things in isolation. <jlicht>nckx: wasn't there some magical make target or script to update the guix package definition? <mothacehe>yup, having N processes fighting over to open a lot store files seems to work really better than having N threads doing the same thing. Not sure why though. <civodul>jlicht: in practice these fibers communicate over channels, it's really all message passing, and i agree it helps <civodul>i guess in cuirass most of the confusion comes from blocking stuff <civodul>and the hacks we have to work around them <Brendan[m]2>complexity is perhaps guix's biggest downside. if i was smart enough id come up with some way of redesigning parts to simplify <mothacehe>civodul: I added a watchdog that reports when fibers are blocked. It should help us find the fibers that are blocking. <mothacehe>for instance calling build-derivations can block :( <jlicht>civodul: I meant between isolated threads/processes though ;-). <civodul>mothacehe: build-derivations call put-bytevector essentially, and that is supposedly non-blocking no? (as in: Fibers provides a non-blocking implementation of it) <civodul>read-derivation uses 'read', which blocks, but it's supposed to be "fast" <janneke>"<mothacehe> janneke: fixed with bdbd8bf905." <mothacehe>civodul: ok for read-derivation. For build-derivations, doesn't it read a boolean from the guix-daemon socket? <mothacehe>I'm not sure yet but I think that when the gc mutex is held, build-derivations will also block. <nckx>jlicht: Yes, make update-guix-package, neve rused it. <zimoun>dear Guixers on foreign distro, is /etc/bash_completion.d a common place for your distro? It is the case for Debian. I think Ubuntu too? OpenSUSE? Fedora? <foo-dogsquared>noob qn: i've noticed that some go packages have incomplete depedencies (eg. in `native-inputs') in their definition and still successfully build it without specifying the dependencies. is it a preference to specify them with the already existing go packages? <civodul>so 'read' is missing from that, but as long as we only 'read' from local files, we should be fine <civodul>the RPCs in (guix store) use the things in (guix serialization), and all that uses suspendable primitives i think <civodul>now, it's easy to overlook one tiny primitive that breaks it all <mothacehe>ok, understood thanks. I'll have a closer look to see what's blocking here then. <BlackMug>i want to ask for Guix release based on Hurd, can it has a security feature which can give a VM per package instead of MAC sandboxing which most current OSs use it? <BlackMug>from our last discussion i really though about that sandboxing it sound great but implementing it is very bad <BlackMug>as each package should define itself and has its own MAC profile (whether apparmor or selinux or..etc) <BlackMug>well what about universal thing which the package can run in when installed but with or without sandboxing it doesnt crush or damage the entire system if its malicious <civodul>it's not the topic of this article, to be fair :-) <BlackMug>agree, sorry if its not but thought about it will talk about it <civodul>one thing that's been discussed for some time is the possibility of wrapping packages so their run in separate namespaces (on GNU/Linux) <civodul>something similar could be done on GNU/Hurd, but we're far from there <BlackMug>but namespaces also need a configured profile for each package in order to be sandboxed <BlackMug>firejail,bubblewrap has their own profiles for the packages they support <BlackMug>but im talking about sickening very old malicious package installed within guixsd but it will only damage itself <civodul>the situation of Debian is very different though since binaries cannot easily be verified <BlackMug>yes packages within debian sadly not in good secure <BlackMug>well virtualization is more secure than containing or really different approach, but guix can be real deal futuristic OS with microkernel and great package manager and even securing their packages after installation based on trustless state <BlackMug>i look forward for guixsd and cant wait to use it within my Qubes VM (once offline installation supported), but i dont want to see it just another hobby distro without security in mind <civodul>security is not just about run-time support though (containers/VMs, etc.) <kmicu>Qubes using broken CPUs for efficent virtualisation is a trade off. There is no such thing as ‘security’ we can only minimise risks against something. <civodul>right, but reproducible builds & bootstrappable builds are crucial from a security standpoint <BlackMug>me talking about malicious package installed within Guixsd but it cant do anything except within itself (when the user use it) but not damaging the entire OS <civodul>so your point is about run-time isolation; my point is that your point is just one aspect of the bigger picture, not necessarily the most important one :-) <kmicu>(Guix System doesn’t update CPU microcode which can be a good thing and can be a bad thing at the same time. It depends on threat modelling. There are many issues like that.) <civodul>also, in a free software context, things are a bit different <BlackMug>kmicu Qubes is software , CPU is hardware. Not sure what do you mean using broken CPU? <civodul>Guix is not about running opaque binaries in the first place <jlicht>BlackMug: unless you go out of your way, the cpu you run Qubes on still runs proprietary software. An entire OS, even! <kmicu>Malicious package aka proprietary software in the same way as modern browsers execute proprietary javascript so they need sandboxes to stay sane. <civodul>MINIX is a nice piece of software tho :-) <BlackMug>civodul i agree not the only security feature needed, but i doubt its less important than others. Because even if the package is malicious not damages to OS. <BlackMug>jlicht i dont see Guix solving this hardware issue as well <leoprikler>I do have to note, Guix would make packaging evilmalware(1) really easy. <leoprikler>I haven't gotten around to please_delete_all_my_files(1), though. <BlackMug>the packaging within Guixsd using guix thats really nice one, but we need a trustless state to the packages and their developers <jlicht>BlackMug: It's not entirely a hardware issue: we 'win' by not playing the game in the first place; no microcode updates = no _extra_ backdoors, or so the story goes. It doesn't make the problem go away entirely, as you say <BlackMug>we cant have that without eliminating the effect of the package directly to the system <BlackMug>jlicht no body said guixsd must have microcode updates, because this is totally different issue <BlackMug>and using OpenPower CPUs every firmware is free software <jlicht>BlackMug: you mentioned Qubes, I mentioned that the cpu you use is (probably) still being backdoored. Not talking about the broader context of wanting to solve the halting problem ;-) <jlicht>sorry for the confusion nonetheless *civodul wonders about the effectiveness of this discussion :-) <BlackMug>when i mentioned Qubes i just wanted to point out the virtualization used within their system <BlackMug>jlicht though do you know Qubes dom0 which is the one that talk to the hardware doesnt contain internet within itself? but this going to be another discussion though... <BlackMug>anyway for VM per package design shall i open a ticket about it? <kmicu>Qubes requires specific hardware, Guix System also is focused on specific hardware. Hardware with efficent virtualivation is not libre friendly. So that’s not the current focus of Guix System. <BlackMug>because i dont know really if im talking to devs or just normal users <BlackMug>leoprikler lol, wish development can be that easy <leoprikler>They might not have direct commit access to the Guix repository, but most everyone here has at least contributed a package or two. <BlackMug>talking about packages contribution, to search for packages availability within guix from the guix website is a pain in the neck <BlackMug>going to alphabetical then scrolling down to sometimes 20+ pages of packages this is horrible <kmicu>BlackMug: power9 is not affordable and not accessible. Guess how many folks here have power9 systems. <BlackMug>kmicu you are talking about aspects that the software has no hands into solving it like not affordable , proprietary CPU...etc this is has nothing to do with the software/OS to solve. <BlackMug>leoprikler then what do you mean by static if its not about JS? <jlicht>thanks for telling me about dom0, BlackMug! It seems interesting. <luis-felipe>Hi, I think there is an erratum in the documentation of the cargo-build-system. The last sentence says: <luis-felipe>"The install phase installs any crate the binaries if they are defined by the crate." <leoprikler>static here means, that all pages exist as shown on the web page and are not generated on the fly. <kmicu>BlackMug: I’m trying to explain where Guix System puts its focus. If your goal is to safely execute proprietary code then Guix System is not designed to protect users from that. If your goal is to execute only libre software then security risks are really minimal. <BlackMug>civodul i have reported to gnu.org and savannah that there are 8 hardening parts the TLS need but i got no respond from them <civodul>luis-felipe: hi! efraim can probably confirm/correct <BlackMug>kmicu free software doesnt mean secure, so if you think every free software is secure one its not that. And im pro-freedom , i hat proprietary as well. <civodul>i think we've sufficiently drifted off-topic by now <leoprikler>Yes, there are bugs in free software, but when exactly do those bugs become relevant? <kmicu>BlackMug: I’m talking about minimizing risks in real world. There is no such thing as security. We can only be secure against something. If we use default Guix System browser we already minimizing risks because we refuse to run proprietary software. <kmicu>Nix(OS) has a dedicated security team but they package a lot of blobs so that could be justified. /me shuts up for today ;) <zimoun>civodul: bad! :-( Bad day… Kind of emergy work because covid blabla… With team coworker, the coming weeks, we will be shifting 1 week over 2. So I have to explain them VPN &co. install on Windows (ouch!) etc. And I am not focus enough… I did a trivial mistake (so v2) with the patch #43761 updating gmsh, maybe two: still (modules ’((guix build utils))). Arg! :-) <BlackMug>kmicu free software is first step towards security but its not the whole security. Yes minimizing but still can be malicious anytime anywhere <jlicht>I do think it would be nice to be able to (more easily) isolate software running in Guix, such as web browsers. I use guix environment for now, but it would be nice to be able to state it in my manifest that e.g. "this browser should _always_ run in such a containerized setting" *jlicht hoping to pull this conversation back to the POLA stuff I saw on the ML recently :-) <BlackMug>jlicht currently software almost isolated as its running with userspace, but what more to be added to a VM to protect the OS from this X software <rekado_>BlackMug: re package search: it’s a long-standing open issue. It used to be impossible with the kind of website backend we had (it’s a long story), but that has been rectified and we’re only waiting for someone to do the work to add search to the site. <BlackMug>its like convenient VS security, same as before when ppl where against free software because proprietary was providing convenient but not freedom <rekado_>it’s not difficult, it just isn’t important enough to most people given that you can search with “guix search” <rekado_>those who think it’s important can certainly make the adjustments <BlackMug>well sad for me because i really get tired when i search for packages <rekado_>BlackMug: why aren’t you using “guix search” then? <rekado_>“guix search” is going to give you more relevant results because they will match your particular variant of Guix, channels and all <jonsger>BlackMug: I use "guix package -A foo" as search, I found it more convinient :) ***grumble is now known as Spooktober
<jlicht>that reminds me, searching from within emacs is kind of borked again in eshell. It tries to pipe to my pager unconditionally now, and I actually have no way of disabling this as it still defaults to "less". <rekado_>I do that in Emacs anyway, because I don’t want git to use my PAGER <mothacehe>janneke: civodul: I reconfigured berlin with the latest guix-daemon. The 'guix build -s i686-gnu hello' command is now 'waiting for locks or build slots'. <BlackMug>rekado_ thanks for the link, is just what i was asking for <civodul>mothacehe: janneke & i have been working on it on-and-off over the last few days <civodul>i've reconfigured the build nodes this morning with the tweaks i pushed to maintenance.git <civodul>the good news being: it's working \o/ <civodul>yeah i've been offloading to the childhurd on my laptop too, it's pretty fun <BlackMug>civodul guix i cant yet put my hands on as really using it because it doesnt support offline installation which i need for my Qubes VM in order to run it <civodul>BlackMug: i'm sorry it doesn't suit your needs <BlackMug>i opened a ticket about that, and waiting for the infinity time to finish <mothacehe>let's now see what Cuirass thinks about all that <efraim>luis-felipe: indeed, if there's no binary defined in the package then the cargo-build-system doesn't install one. My understanding is that clippy got absorbed into rust/cargo/something and the separate package is more legacy now. <civodul>BlackMug: you can help instead of waiting, or you can choose that this isn't suitable <civodul>but please don't expect the volunteers here to do the work for you <BlackMug>anyway thanks guys for the great discussion, but i want to ask where can i report that ticket about VM feature i open it in Guix report or where? (just to keep it as a reminder for others to look at and archiving it) <BlackMug>civodul its a huge change to the entire OS bootup can i have this privilege to change the behavior of the OS? <BlackMug>i think this is need to be done from high level developers who control how guixsd behave when installed <BlackMug>ok gonna report it to the bug report what to loose... <BlackMug>I hope guixsd is not just another distro with no secure design in mind. Thanks again <3 <luis-felipe>efraim: I see. And about the cargo-build-system documentation, do you see an erratum in the last sentence? "The install phase installs any crate the binaries if they are defined by the crate." <zimoun>civodul: I have updated the package Gmsh to the last version. It could be nice to have for v1.2 since it is widely used by HPC folks for meshing CAD. <zimoun>I think I forgot to remove (modules …) which is unnecessary now, I guess. <luis-felipe>efraim: Shouldn't it be "The install phase installs any binaries if they are defined by the crate."? Or maybe my English is worse every day... ***nlofaro_ is now known as nlofaro
<zimoun>jonsger: you are using OpenSUSE, right? <zimoun>what is the default interactive shell? Bash? <apteryx>hello! could someone confirm that: guix build --system=aarch64-linux glib fails É <apteryx>(you need to have a aarch64 machine to offload to, or use the qemu-binfmt service to emulate one). <civodul>hmm there's something in libgit 1.0 vs. 0.28 that breaks tests/proxy.scm in guile-git <apteryx>jonsger: for me it fails early with: executing `/gnu/store/swp244ah51hcqgghzdn4pczgkjmnvcsw-guile-2.0.14/bin/guile': No such file or directory <apteryx>according to 'file', that binary was built for ARM aarch64 <jonsger>apteryx: it succeeds for me, but the error smells a little like your binfmt service is not running or broken <morgansmith>Anyone use wireshark? I'm not sure how to let it access my network devices without running it as root :/ <civodul>apteryx: ENOENT is about the ELF interpreter of that file, most likely <civodul>so that the --chroot-directory options are in sync <leoprikler>morgansmith: wireshark probably expects you to be in a special group for that <morgansmith>I guess I should try it out and bump that thread with my experiences <efraim>bah, luix-felipe already left and sneek's not here <efraim>I was AFK pretty much all day, was going to apologize for not answering <morgansmith>"--with-git-url=/home/pancake/src/emacs" isn't working anymore... it used to work. am I typing it differently somehow? <morgansmith>oh, I forgot to shove an =emacs-next= in there. that format always messes me up :P <morgansmith>My history of playing online video games has me wanting to respond with profanities anytime someone greets themselves. I'm starting to think that culture wasn't healthy :P <morgansmith>It's just kinda like the small talk you know. Instead of asking people how they are, you insult them. Just how it be <alextee[m]>im trying to upgrade my guix after a few weeks of not pulling (bad connection - have broadband now yay) <alextee[m]>and i get this guix substitute: error: host name lookup error: Name or service not known <morgansmith>sometimes it takes 7 tries. I also have bad internet. Could be the server though <alextee[m]>my connection is pretty stable now though, don't think its me <alextee[m]>ok now i get /builder for `/gnu/store/aihgqsk41wilzrqiic1hqx4pgc3b97hz-guix-package-cache.drv' failed to produce output path `/gnu/store/6mwbcqdlhpmkl2dpdaavx2nd4q72pq2y-guix-package-cache' <roptat>ah, I also have these "Name or service not known" <roptat>but it's not only with ci, but also my own domain <alextee[m]>btw is there any way to fetch the commit with chromium available? i can't build it locally and I see it's failing on current master <alextee[m]>I'm guessing if I do guix pull --commit with some magic hash it will fetch the prebuilt chromium <roptat>click the build, then on that page, click the evaluation number <roptat>at the top of the evaluation page, you have the full commit number <alextee[m]>how long are the pre-built binaries available on the server btw? <roptat>I'm not sure, I think we keep at least the builds for the released versions, and probably a few months <alextee[m]>maybe i can just tell it to not upgrade chromium? *alextee[m] checks the manual <alextee[m]>--do-not-upgrade[=REGEXP] do not upgrade any packages matching REGEXP <alextee[m]>/builder for `/gnu/store/aihgqsk41wilzrqiic1hqx4pgc3b97hz-guix-package-cache.drv' failed to produce output path `/gnu/store/6mwbcqdlhpmkl2dpdaavx2nd4q72pq2y-guix-package-cache' <alextee[m]>any ideas what's wrong? i get that when I `guix pull` <civodul>alextee[m]: did you check with just the 'guix channel? <civodul>"guix time-machine -- describe" works for me (it's roughly equivalent) <alextee[m]>trying that now, I moved my channels.scm elsewhere <divoplade>Hello, it seems that a blender dependency named "tbb" does not build... can anyone confirm it, or is it because I don't have enough memory? <morgansmith>how much memory you got? It's building now and it's eating 8GB/12 rn <divoplade>I have strong words for programs that need gigabytes to even compile, but I'll keep them for myself :) <jlicht>regarding the host issues: by default, Guix system caches negative entry for a loooooooooong time. Try `sudo herd invalidate nscd hosts' if you want your 'retry' to actually retry :-) <jlicht>regarding the "Name or service not known"-fun people seem to be having <apteryx>civodul: strange, I restarted guix-daemon both on the remote offload and locally, but still hitting the binfmt problem with glib. This is following a 'guix deploy' of the said remote. <civodul>apteryx: maybe you need to "herd restart qemu-binfmt" as well <civodul>the thing is: what's written in /proc/*/*binfmt* must match the --chroot-directory options of guix-daemon ***niko is now known as ping
<apteryx>the only entry maching the name'*binfmt* under /proc is /proc/sys/fs/binfmt_misc, which contains qemu-aarch64 qemu-arm qemu-mips64el register status <civodul>apteryx: those contain an "interpreter" line with th efile name of qemu <civodul>you must make sure that this file name is in one of the --chroot-directory options of guix-daemon <civodul>i'm saying this for completeness but restarting the two services should be enough :-) <apteryx>I confirm that restarting qemu-binfmt as well fixes it <nckx>Hullo again, glorious guix. <cbaines>Does anyone know what an underscore means in a Guile backtrace? a bit like: 338:10 4 (exec-query _ _ _ #:serializer _) <lispmacs[work]>I'm trying to do a package update using a Manifest file. However, there is a build failure on a random library I don't know anything about. Is there a way to see what depends on that library? Say, by building the dependency graph of the profile I trying to build <civodul>cbaines: hey! underscore just means there's an argument but its value is not printed <cbaines>lispmacs[work], what's the output after the failure? I think it usually says what dependent derivations now can't be built, and I think that's the information you're looking for. <civodul>maybe you're feeding pgsql with something that's not proper UTF-8? <cbaines>civodul, do you happen to know how Guile decides what and what not to print? <civodul>i've been meaning to learn about this :-) <cbaines>and it uses the current locale encoding, which I hope is a UTF-8 encoding (and the Guix Data Service now explicitly switches to a UTF-8 locale, so it should be) <civodul>i recommend being explicit instead of hoping the locale is UTF-8 <civodul>i think string->pointer has an optional encoding arg <zimoun>civodul suggested “ps -aux | grep ncsd” to check by guix-install.sh and then suggest install it. Instead, is “piodf nscd” compliant? <cbaines>civodul, indeed... I was contemplating the effort involved in writing a pure-Guile client for PostgreSQL, that would resolve the fiber blocking issues with using bindings. I think it's a few years off though... <civodul>zimoun: pidof is a good idea, but you can't assume it's available, so you should check the return value of "type -P pidof" first <nckx>zimoun: pidof is better. ps -aux | grep ncsd doesn't even work here, and ‘ps | grep foo’ will always return a bogus line matching the grep itself. <nckx>I sometimes use | grep [f]oo but it's a pretty ugly hack. <lispmacs[work]>cbaines: oops, I already cleared that screen. I saved the build failure log, but didn't think about that <jackhill>A question about the new(-ish) image-type options to guix system disk-image. Is it expected that there isn't a linux-libre-qcow2 image type? <zzappie>Has anyone encountered a situation when you would need to use two build systems? <nckx>jackhill: In addition to a default ‘qcow2’ one (still pulling that guix to see the list of types)? That sounds odd to me. Maybe some joyous day when the Hurd is the default... <nckx>zzappie: Yes. It's not common but not that rare either. <nckx>Plenty of examples in Guix. <jackhill>nckx: I think it has been removed. --list-image-types doesn't print plain qcow2, and specifying that results in a backtrace: Wrong type (expecting exact integer): #<&formatted-message format: "~a: no such image type~%\n" arguments: (qcow2)> <nckx>zimoun: Extremely common. De facto standard. Universal? That I don't know. I'd rely on it and deal with exceptions when and if they occur. <jackhill>hmm, at the very least we should at least replace the backtrace with a nice human error. <nckx>jackhill: Removed or bogus? ‘qcow2’ was hypothetical. I don't have the list yet. <nckx>Adding the kernel to the image type just sounds weird to me. <apteryx>how are the linux-libre kernel and the qcow2 disk image format related? <zzappie>nckx: dyou know what is the standard way to go about it? I need to include eg cargo in inputs and modify build phases to add shell invocations? Or there it is better to try to use the build-system api in gexps? <nckx>zzappie: The standard/common way is to choose a ‘primary’ (build-system foo-build-system), then import both build system's modules, and modify-phases %standard-phases (which will be foo's) to add bar-build-system's phases when and where needed. Not sure where gexps come in? <nckx>Same here (without arguments) but it's not available if pidof isn't. <nckx>But then neither is ‘ps’ so I'm not sure which weird environment was being talked about. <nckx>(On GNU at least, procps provides pidof, pgrep, and ps.) <alextee[m]>upgraded my guix!! after a couple of months of not upgrading <zzappie>nckx: I used wrong term. I refered to things you write modify-phrases as gexps because they are running on "build side". :) <zimoun>civodul: guix-install.sh done in #43769. Hope it is good. <nckx>zzappie: I feel like there are better examples if only I could find them, but look at the lollypop package in (gnu packages gnome). It's a very basic but hence clear example of modest build system mixage. <zimoun>rekado_: You mean “pgrep -fa name” instead of “pidof”. I have used “pidof” to check ’nscd’ in guix-install.sh. BTW, the current ${ERR} should be turned with a new orange ${WARN}, but I always need to check the coloring scheme such as “ \033[32”… :-) <nckx>zimoun: Minor: how about ‘We recommend installing and/or starting your distribution's ‘nscd’ daemon’? Or ‘please install’ if length matters. <nckx>The current phrasing is just begging for a ‘;-)’ after ‘...or to start it’ and reads oddly to me. <zimoun>nckx: yeah, better! for sure… too bad day for a good inspiration. :-) <zimoun>I will send v2 tomorrow including your comments and orange color. :-) If noone beats me. *nckx still waiting for 2/2 to arrive. <zzappie>nckx: yeah this is what I was looking for <apteryx>Oh, I guess it's now evening in Europe. <mfg>Does someone use inkscape on guix system? why are the symbols missing in some places? Are there any environment variables that need to get exported? <mfg>i mean the graphical symbols :D <zzappie>mfg: I'm using inkscape -- my panel symbols seem to be in place <nckx>apteryx: Dinner time, even. <mfg>zzappie: hm, interesting :/ <nckx>Forgive my mad graphix skills. <mfg>nckx: that's exactly how it looks for me :D, sway <leoprikler>if so, you might be lacking some icons that are shipped with gnome by default <mfg>i had to hand trace a logo because the resolution was so bad that it couldn't autotrace it properly... took me 2 hours yesterday, just to get stuck while trying to get the right color profile and cmyk -> also bad graphix skills :D <mfg>leoprikler: No, i'm just usng sway. Does an extra icon package exist? <leoprikler>you may want hicolor-icon-theme or adwaita-icon-theme <leoprikler>raghavgururajan is working on updating all the packages, that lack them, you may want to inform them when they're back here <nckx>mfg: Many GUI applications have a package called hicolor-icon-theme as input. Inkscape doesn't. I wonder what happens if it's added. <nckx>mfg: I'm trying to try, but keep hitting substitution TLS errors. <zzappie>nckx mfg: I'm using xfce with adwaita icon-theme and adwaita-dark color scheme it comes with gnome-themes-extra I think. <mfg>adding both icon packages doesn't change it for me :( <nckx>As inkscape inputs or to your profile? <mfg>to the ad-hoc list of an environment; or is this something which i shouldn't be doing? <apteryx>nckx: do you know why this works (hicolor-icon-theme as an input)? It's because it gets wrapped in the XDG_DATA_DIRS at build time. <apteryx>That's a rather inelegant kludge in my opinion. Desktop environments should ship with hicolor-icon-theme, if they don't already. <mfg>leoprikler: that would explain things :D <apteryx>leoprikler: it's again because of XDG_DATA_DIRS (if you use with --pure it won't work, without it will since XDG_DATA_DIRS is set from /etc/profile, if you have the icons installed in your user profile) <leoprikler>apteryx: you'll always get those people who'll try to be cool and run stuff with little more than ratpoison or xmonad <nckx>apteryx: Yes, it's a kluge, but it's the standard kluge. I'm not actually against removing it (like I don't agree applications like IceCat should have a ‘default font’ input bloating up the place). <leoprikler>if you do --ad-hoc adwaita-icon-theme, then that's likely a nope <nckx>But I'm just trying to get Inkscape in line with our other packages, not discuss the concept. <apteryx>I believe the root cause here is issues.guix.gnu.org/22138. <apteryx>We should fix this instead of adding more kludges :-) <nckx>apteryx: What do you mean by ‘Desktop environments should ship with hicolor-icon-theme’? <leoprikler>gst doesn't suffer from this because every gstreamer package propagates gstreamer tho <nckx>I have hicolor-icon-theme in my system profile, we do not seem to be talking about the same thing. <apteryx>nckx: the package should come with the templates as a system installed package <nckx>apteryx: For me the bug here is that Inkscape doesn't find it, not that it's missing. <apteryx>that's two different actions to do to improve the situation 1) install hicolor-icon-theme as default for desktop systems and 2) fix bug #22138. Fixing 2) would fix inkscape, I believe. <apteryx>You can test by setting manually XDG_DATA_DIRS <apteryx>if in a pure environment, something like: export XDG_DATA_DIRS=$GUIX_ENVIRONMENT/share <mfg>setting XDG_DATA_DIRS manually works <nckx>Oh, yeah, I've grumbled about this in other contexts. It's terrible but hard to solve well. <nckx>I had to add some kluges to the libva packages for the same reason. <apteryx>there are already two solutions proposed. We should try them. The fear seems to be "too many environment variables". I don't see a problem with that, except perhaps forcing a better environment variable hygiene (cough PYTHONPATH). <nckx>apteryx: Sounds good but what does ‘we should try them’ actually mean? Merge? <apteryx>nckx: we can guix pull from a local checkout with a proposed fix, upgrade our user profile, see if there's any breakage <roptat>nckx, I still prefer my solution, but if you can make a patch out of ludo's procedure, then that's good enough for me :) <nckx>Yes. roptat: Only because Ludo's is IYO needlessly complex, or for other reasons? <nckx>apteryx: I don't expect any breakage, but testing is always good! <roptat>I'm not completely convinced looking at references is enough <roptat>but I'm convinced it's already a good step forward <apteryx>well, it could pull PYTHONPATH, for example, an break stuff on foreign distros, perhaps <roptat>we already break stuff on foreign distros because of that... <nckx>You seemed less opinionated there. <apteryx>roptat: there's a FIXME in your proposed patch to 22138. Had you thought of another way? <roptat>apteryx, that's not my style of writing, I probably copied some code elsewhere (bad practice, I know ^^') <roptat>I think what I wanted to say is that, when I install something in my profile, I'm expecting it to contribute to the behavior of that profile, and I install it because I want that behavior. In the current situation, I install some packages, but they are not working (so not contributing any behavior) because they're missing some environment variables. I can add other packages (whose behavior I don't care about or don't want) to profit from their metadata and add <roptat>what ludo and I suggest is a way to prevent that by add the metadata: ludo suggests to get only the metadata from runtime dependencies, whereas I suggest to use metadata from any existing package. In both cases, the environment variable is only defined when it refers to at least one file/directory in the profile <roptat>I'm not convinced that runtime dependencies are all you need. If you look at python, or maybe some libraries for other languages, they're not necessarily referencing the compiler <helaoban>question: what are the consequences of running 'guix system reconfigure' as a non-root user? I accidentally forgot to add sudo on an invocation and the build proceeded until it ran into some permission issues and failed. <apteryx>helaoban: it'll just fail with a permission error <helaoban>does everything just get rolled back to the current generation, no harm no foul? <apteryx>no harm no foul, the system generation pointer doesn't get updated <roptat>it'll build you new system and fail at actually making the transaction to it, it won't roll back, it just won't be able to start the transaction at all <roptat>nckx, maybe there's a parallel with profile hooks <roptat>I'm not entirely sure, but I think the hooks always run with the condition that inputs files are present <roptat>for instance, the font cache is built when there's a font file in the profile, not when there's a specific package in the profile <roptat>I'd like environment variables to be the same: define them when there's a file they could refer to, not when there's a specific package in the profile <nckx>Eh, I've never actually needed to touch the profile hook, not that familiar with them 🙂 You could have told me they were unconditional and I would have believed you. Yes, they do sound similar to search paths, assuming ‘a font file’ meant ‘$profile/share/fonts exists’, not ‘find $profile -iname *.ttf‘. <roptat>also it'd be less expensive computation, as you could simply cache the set of variables when you run guix pull, then use that cache to build them in profiles <roptat>yeah, hooks are similar to environment variables, but they produce files that are read by other programs (that may not be in the profile in question) <nckx>roptat: So move them out of package definitions entirely? No longer have each consumer define its search paths but have a central profile-hook-like piece of code? <nckx>...or is that too extreme a conclusion. <bandali>hey roptat, any news about the copyright situation with guix-translations? <roptat>yes! I fixed the generation for new po files in the guix repository <nckx>I think the current (native-)search-path system is a pretty damn elegant way to do things. It just has some flaws. I'd prefer keeping it, just wanted to see how far your comparison to profile hooks went. <roptat>we're still missing the answer from two translators before we can change the license of the guix-manual.*.po (from gplv3 -> gfdl) <bandali>roptat, ha, cool, thanks for the update! please feel free to reply to the savannah ticket with that info :-) <nckx>*elegant considering the alternatives I've seen, that is. It will always be a mess because it is a messy thing. <bandali>i look forward to seeing more progress on that front <roptat>I have permission from ludo to change copyright from him to guix contributors, but I'm not sure about the attribution to the FSF <roptat>bandali, yeah and the TP admins don't like us anymore because we mentionned weblate :/ <apteryx>roptat: wouldn't Python libraries end up referencing the Python VM via an implicit inputs in their build system? <apteryx>so this instance would work with Ludovic's proposal of considering only run-time dependencies? <roptat>nope, for instance you can try "guix size python-polib" and there's no reference to python <apteryx>is guix size showing only run time deps? <roptat>yes, it gives you the closure of references <roptat>which is our definition of runtime dependency <roptat>in any case, python-polib has no reference other than itself, so it can't contribute an environment variable <roptat>even though I could have python installed in another profile <roptat>and it doesn't propagate python, so python won't be in the profile at all, nor be a runtime dependency (tried with guix environment --ad-hoc python-polib) <apteryx>right. python-polib is not exactly useful wi <roptat>you could have python in your default profile, and just want to provide python-polib <apteryx>the merging of different profiles search paths is a separate issue <roptat>in an environment or a separate profile <roptat>the thing is, when I install python-polib, I expect it to be useful in some way <roptat>but it could be my foreign system's python <roptat>it's not really about merging profile <cbaines>packages that are "completely useless" in isolation aren't restricted to Python libraries. Things like fonts and icons probably could be seen similarly. <apteryx>Perhaps the python-build-system could add Python itself as an implicitly propagated input? <cbaines>In all three cases, it's the combination of a font with code for rendering, and a python library, with an interpreter that results in something more than the sum of the packages involved <roptat>apteryx, that would be pretty bad for python binaries I think <roptat>they have a reference to python already, but propagating would mean they can't be upgraded independently or use a different python anymore <cbaines>Apologies, but I missed the problem(s) being discussed here, what's the crux of the issue? <roptat>comparing the merits of my patch compared to ludo's :) <cbaines>Are there any clear concrete examples where the current behaviour is problomatic? <apteryx>try 'guix environment --pure inkscape hicolor-icon-theme' and enjoy the lack of them ;-) <nckx>apteryx: <python-build-system could add Python> isn't that just factoring out the kluge, for one specific package? <nckx>(Disclaimer: I wrote that.) <cbaines>apteryx, Ok, and in the case of icons, do you know what package defines the search path that would match hicolor-icon-theme? <leoprikler>that's in glib tho, which should be propagated by gtk+ <nckx>apteryx: ‘run time dependencies’ == references? <cbaines>Ah, yeah, glib sets a rather broad search path for share -> XDG_DATA_DIRS, which is what I assume is relevant <nckx>apteryx: Or propagated-inputs? Or something else? <roptat>currently we look for variables in the profile's packages (that includes propagated-inputs). ludo's approach is to use run-time dependencies instead, which adds much more packages that could potentially define variables <cbaines>apteryx, I can't get to the point where I have icon problems with inkscape, I can't get it to start at all in a pure environment... *raghavgururajan asks everyone, not to get thrown-off by the vhost hot-chilli. It me, the real me, not the imposter. <cbaines>apteryx, I got that far, with --ad-hoc though, I get:No protocol specified <cbaines>Unable to init server: Could not connect: Connection refused <cbaines>Maybe I was running through SSH or something... <apteryx>no you're right there's something to expose for X <nckx>raghavgururajan: You have a cloak now, so ‘nobody’ knew 🙂 <raghavgururajan>nckx: The unaffliated one? The gateway cloak supposed to override it. <mfg>does a pkg config file make sense for a header only library? <nckx>Ops, if they could be bothered, probably. <nckx>lispmacs[work]: ‘Had a brief power glitch the other day. That was probably it.’ -- sneek's owner. <apteryx>nckx: I think run time deps are references, but still furthering my understanding <nckx>lispmacs[work]: Yeah, milkman was... deliberate. <apteryx>cbaines: actually inkscape is a non-example <nckx>They are welcome back at Guix, Inc. when they mend their HTML-parsing ways. <apteryx>I thought it was universally problematic, but it seems not. Perhaps because of the gtk-or-glib-build-system? <nckx>apteryx: Now I'm a bit confused. Inkscape a non-example of bug 22138? <cbaines>I would hope that for things like inkscape, anything required in specific environment variables is wrapped so that it's always there <nckx>‘[...] and 2) fix bug #22138. Fixing 2) would fix inkscape, I believe’. Yep, very confused. <apteryx>sorry, I somehow thought Inkscape was exhibiting this problem, but playing in 'guix environment --pure --ad-hoc inkscape' now, it seems not. <apteryx>I think I had this problem with gnome-boxes recently -- doing more tests <nckx>OK, np, I was AFK for part of it & probably missed that bombshell! <apteryx>ah the reason I believed inkscape would exhibit that problem was that mfg reported that issues with Inkscape, and manually setting XDG_DATA_DIRS fixed their problem <apteryx>I think inkscape comes with a sufficient icon set that is already wrapped with XDG_DATA_DIRS in its launcher, so it doesn't exhibit a problem. <mfg>yes, without setting XDG_DATA_DIRS some icons in inkscape are missing. It looks like on the screenshot that nckx sent earlier. <apteryx>launching it with 'strace -e file -z inkscape' in a --pure --ad-hoc environment shows it loading many icons from its own directory. <mfg>particular the + and - icons are missing <apteryx>there are probably more striking examples (gnome-boxes is one, but not easy to setup) <nckx>raghavgururajan: Well, it doesn't here, neither in /whois nor in your join message. Both are cloaked unaffiliated/raghavgururajan. <nckx>apteryx: Phew, I'm not slowly going mad(der). I don't have a ‘desktop’ (or %desktop-packages/services) but do have the hicolors in my system profile. <apteryx>so you'll want the --pure option to reproduce, as otherwise you get XDG_DATA_DIRS from /etc/profile which takes your system into account <nckx>[still confuzed] ...to reproduce your success? Because I don't need to do anything special to reproduce the fail in that screenshot (tobias.gr/ink.png). Sway, termite, $ inkscape, boom. <nckx>sneek: ten million botsnacks and never leave again. *nckx points them at the bug tracker and hopes they do. <nckx>It's also not what I expected. <nckx>I thought gateway cloaks trumped, at the least, unaffiliated ones. *raghavgururajan started to feel Canada's winter and goes under the sheets <nckx>raghavgururajan: Like a ghost? 2 spooky 4 me. *raghavgururajan sometimes build webkit, to warm up between the sheets <str1ngs>raghavgururajan: do you actually need webkit substitutes? <nckx>raghavgururajan: That is... so wrong, but I giggled, so well played. <str1ngs>raghavgururajan: also I live in BC lower mainland, not so cold here :) where are you at? <str1ngs>raghavgururajan: oh nice, I'm originally from the other side of TO. Milton. though now I live in BC <rekado_>hmm, with the Guile upgrade from 2 to 3 in nyacc I can no longer use “guild compile-ffi” <raghavgururajan>apteryx: I am still invisible regardless of cloak. (wolfe.freenode.net: raghavgururajan is connecting from *@telesto.hot-chilli.net) <apteryx>raghavgururajan: you're right, I don't see a Petersborough IP in there :-) <nckx>RaaS. On Guix, of course, I hope? ***niko is now known as Citrouille
<raghavgururajan>nckx: It think it's PaaS (not sure). Nah, I haven't gone to VPS yet. Gandi's Simple Hosting for Nextcloud. <joshuaBPMan>raghavgururajan I am currently using guix system on a linode. But I've only got it set up for a website so far. <apteryx>nckx: OK... Here's the fix for Inkscape: guix environment -C --network --expose=$HOME/.Xauthority -E '^DISPLAY$' --ad-hoc inkscape gnome-icon-theme <apteryx>then XDG_DATA_DIRS=$GUIX_ENVIRONMENT/share inkscape <nckx>It explicitly depends on gnome? <apteryx>I don't know what is the name of that +/- icons it wants, but they aren't in hicolor (we could file a bug upstream for that, perhaps) <apteryx>I also don't know how to easily find out the icons it's attempting to read <mfg>you also straced inkscape, didn't you? i saw a lot of attempts to read Adwaita and if it failed, then hicolor <rekado_>ah, the new nyacc just needs a snippet <mfg>apteryx: ok, the output looks different looking again at it, but those icons are found when i run your command with gnome-icon-theme substituted by adwaita, so if gnome icons is a bigger package adwaita might be enough <divoplade>Dear guix, how do I create a package definition for a guile module that requires another guile module? Mine requires (json) from guile-json, but even with ("guile-json" ,guile-json) in the native-inputs, inputs and propagated-inputs, it is still not available. <apteryx>raghavgururajan: interesting. Inkscape has a bug then, because it relies on stuff frome gnome-icon-theme not in adwaita-icon-theme <rekado_>divoplade: note that there are different versions of Guile JSON out there. <rekado_>divoplade: there are quite a few packages in (gnu packages guile-xyz) that use guile-json <divoplade>Oh, it seems that it works with guile-json-3 <apteryx>raghavgururajan: oh, sorry, I spewed some misinformation again, inkscape + adwaita does work <apteryx>nckx: it works with adwaita-icon-theme to ***rekado_ is now known as rekado
