<mbakke>jonsger: I was doing some similar CI trickery for x86_64, but think I'll just let Cuirass take care of it <mbakke>pleasant diffstat: 85 files changed, 4239 insertions(+), 9128 deletions(-) <mbakke>cuirass does not handle well when an evaluation is cancelled: it does not retry builds that were cancelled in the next evaluation ... so we were lacking substitutes for R packages, OpenJDK dependents, among others <mbakke>I think those will be retried when they are in a different specification (branch), at least we'll find out shortly *mbakke crosses fingers that cuirass will retry the cancelled jobs <jonsger>only missed subs for sddm, fcitx, telegram-desktop which is pretty good I think <lilyp>why telegram-desktop isn't getting substituted is beyond me <jonsger>but its a different derivation and seems to not getting grafted... <mbakke>jonsger: I'm getting a hash mismatch for /gnu/store/hlk9wi21ajykdcvz9n0dqmdxvndi32bh-thunderbird-102.3.1-checkout <podiki[m]>I wasn't getting subs for some kde-related packages recently, but they built fine locally. maybe the staging merge will fix that (I never investigated) <jonsger>mbakke: hash should be 16wlpcv1n64crcgk4gcl92r37dlpw26izvam82pbp5f8c25amlnk according to my commit to master. I think it somehow get lost in merge-commit 322917aeb8e672c21378fd371a5cff4a9f0c2520 <mbakke>jonsger: that sounds plausible ... efraim does that ring a bell? <mbakke>jonsger: can you update the hash again? <jonsger>podiki[m]: its your fault if you use KDE not our CI for being lazy :P *jonsger should go to bed soon... <podiki[m]>but I don't I swear! :) I just have a few packages that use kde libraries <jonsger>mbakke: I'll directly update then to 102.3.3 which is out for some days now but I didn't recognized until yet... <mbakke>efraim: now is a good time to push that rust bootstrap patch to a new staging branch :) <mbakke>podiki: kwayland consistently fails on the CI, but I can't reproduce it either <podiki[m]>I feel like this isn't the first time I've notice kde-related stuff not subing but builds fine locally.... <mbakke>whoops, that message was not meant for you podiki :) <mbakke>podiki: I've committed a change to kwayland that should let us track down the failing test on CI <podiki[m]>mbakke: kwayland failed on CI, built locally, but different store hash <mbakke>podiki: did you use --no-grafts? <daviid>that's not gona be possible, sorry, but we thank you to think guix has somuch power :) <brendyn>I'm very happy patches I made many months ago made it through. I'll try build and test some programs <podiki[m]>mbakke: no, did not, was just part of my system reconfigure (must be dependency for something...) <podiki[m]>ah, I'm on the staging merge commit, not the followup for kwayland changes <podiki[m]>I'll check again later after I finish all my upgrades <podiki[m]>just did locally as well, shows okay on CI but different hash <Kabouik>guix build, but that does not seem to be that simple, unfortunately. It wouldn't build :> <podiki[m]>mbakke: kwayland still wants to build locally, not sure why it is differing (but still builds) <podiki[m]>Kabouik: likely needs cairo input, maybe some adjustments so emacs finds cairo? (just guessing haven't looked but might another day) <podiki[m]>brendyn: on a new pull and upgrade didn't try to locally build rust-1.58.1 (needed as dependency for something else), just substituted the eventual package that depended on it rather than needing to build <podiki[m]>the final rust version has changed (to 1.60 I think from 1.58), i would make sure you are on current latest guix commit and retry just in case <brendyn>yeah i updated to post staging-merge and got these issues now <Kabouik>Hopefully that's something relatively easy podiki[m], I think support for background opacity would be golden (kind of mandatory for my own taste) <podiki[m]>I had seen that post, filed away somewhere to figure out at some point :) <podiki[m]>neither emacs-next or next-pgtk did anything with setting alpha background; recompiling specifying the x-toolkit flag, but I don't think that matters (defaults to gtk3 anyway) <podiki[m]>(yes, checked build log, gtk3 is selected already) <Kabouik>Hum, so maybe the issue is on my end (unless the settings in the blog post do not enable transparency on your end either) <podiki[m]>emacs-next is on nearly the latest commit so should have this, not sure why it doesn't work for me <user>Hello good night, guix pull stopped to work here, Here is thw correct channel to get some help? <linj> /boot is luks1, others are luks2 <linj>when booting, before grub UI shows up, I am asked to input password for my /boot luks, and it says "Slot 0 openned". Then I am asked my other three luks partition's passwords. Although the password is right, it says "error: Invalid passphrase. \n error: no such cryptodisk found.". <linj>after those three failures, I see grub with blue background <linj>error: no such device: root <linj>error: file `/@gnu/store/hash-linux-libre-5.19.14/bzImage` not found <linj>error: you need to load the kernel first <brendyn>user, im not sure. i suggest emailing that to bug-guix@gnu.org <user>Oh, I will try brendyn thx *mroh is impressed by the weather. <mroh>brendyn: very good (for me at least), I think. I just updated my profiles and get substitutes for everything. <help>user, that might be some disk corruption, because you seem to have a lot of zeroes somewhere <help>you could try to run guix gc --verify=repair,contents <linj>Is there any guide to mount partitions in the "emergency guile repl"? <linj>On boot, I failed to mount a partition, and am dropped into a guile repl <user>thankx help I will give it a try <help>linj, you should be able to enter a shell-like environment from the repl <help>then you should be able to use mount as usual <linj>help: thanks, I just found that as well ***help is now known as roptat
<roptat>was wondering why I got so many hl <linj>roptat: do you know how to continue after mounting is done <roptat>I think if you quit you get a kernel panick <roptat>maybe you can try to do whatever the initrd would do, manually <linj>I am new to guix and don't know what initrd does <linj>guess reinstalling is easier since I have found my error in the config <roptat>you could boot on the installer, chroot to the guix partition and reconfigure from there if you don't want to lose your data <lilyp>stupid wrong number of arguments – who deleted the fixes? <Sughosha>Hi all, is it to clone git recursively only with the needed submodules while packaging in Guix? Like git clone --recurse-submodules=<pathspec> <roptat>in git-reference, you can use (recursive? #t) <Sughosha>roptat: I know that, but that clones every submodules. Is it possible to only clone with selected submodules? <Sughosha>A package has many submodules that are already packaged in guix, but also some submodules that are necessary to build and cannot be seperately packaged. <lilyp>Sughosha: A fix is to define the submodules as origins and then pull them in via (copy-recursively #$my-origin) <lilyp>(of course, you also need to give it the right destination) <lilyp>see the unpack after unpack pattern <Sughosha>lilyp: Thank you. So I should define only the origin and then copy it. <linj>How can I check the content of the generated initrd script <roptat>you need to find the store item that corresponds to that initrd <linj>that's what I am asking for :) <roptat>if you know the store item of the system, you could find it with guix gc -R <the-system-store-path> | grep initrd <roptat>if it's a booted system, then guix gc -R /run/current-system *roptat is struggling with outdated software <roptat>I can't even find the original sources, all I have is a debian tarball <linj>mount: no such file or directory <linj>I have two luks partitions, and built btrfs raid1 on them <roptat>I don't know if you can use file system labels for luks partitions <roptat>I mean, (device (file-system-label "boot")) probably won't work as you expect <roptat>I have (device "/dev/mapper/boot") for my systems <roptat>it would work if you created the file system inside the luks partition with a label, probably <roptat>but it won't be the name that you unlock the luks partition with <linj>my label is right, some of them are the same as the name in /dev/mapper/ <linj>since my btrfs needs two partitions: /dev/mapper/root and /dev/mapper/root-raid1, is (device "/dev/mapper/root") enough? <linj>or can I specify two devices <Franciman>where are the (guix packages) modules located? <Franciman>i mean, generally where can i find the .scm libraries defining the API? <roptat>somewhere in the store, but the exact location depends on the commit of guix you are using <Franciman>is there a way to access it? Or should they be left there uninspected? <roptat>~/.config/guix/current/share/guile/site/3.0/gnu/packages.scm <roptat>even root shouldn't be able to modify them :) ***Dynom_ is now known as Guest4005
<jas>hi. what is the state of Rust support in Guix? I hear people complain about freedom-related issues, but I've never understood if there is anything but trademark or other concerns? any pointers? <jas>so guix contains a complete rust environment? <ducking> <unmatched-paren>Guix has decent Rust support, though the version may be behind given Rust's frequent releases <unmatched-paren>The cargo-build-system is a bit of a hack, though Maxime is working on an alternative build system that should work much better with Guix <jas>okay that is good enough for me -- i'm looking into yet another rewrite of a c library as rust, but wouldn't want to do that if there are fundamental freedom-related issues <jas>making sure things build on guix is a good freedom-test for new work <nckhexen>jas: Those complaints are not in good faith IMO. Rust is as free as GCC. <jas>thanks for confirming! <jas>lack of detail always creates uncertainty. sometimes lack of detail merely means there is no substance <nckhexen>Sorry to sound annoyed for a sec, I… was. This is the first time I've heard it confirmed that the FUD actually (almost) misinformed someone. <jas>unmatched-paren: any particular reason for this? i agree rewriting everything in yet another language has its problem. but if a rust library can be called from other c libraries just as if it were another c library, that would be nice <nckhexen>unmatched-paren: A good summary. It also has advantages, or this discussion would be easy :) <jas>rewriting everything in java and python always failed because the c-world couldn't easily call it <unmatched-paren>Librsvg's Rust rewrite has caused quite a bit of pain with Guix and probably elsewhere. <unmatched-paren>We have to fallback to an old C version for archs other than 64-bit x86 and ARM. <jas>cross-platform support will be an issue in practice though... is there any fundamantal issue, or just lack of time/interest? <nckhexen>That is my understanding of the main problem but it's only based on what I've overheard, yes. <unmatched-paren>the emacsclients aren't launching, even though ps shows emacs --fg-daemon to be runnnig <unmatched-paren>And when I ``herd restart emacs'', it launches, but then hangs as soon as I ``M-x'' <nckhexen>I dunno if all those Guix hashes would scare #emacs, but you could try. 't Is the season. <PurpleSym>sneek: later tell civodul: Wrt release: Can I still push a few world-rebuilding changes to haskell-build-system to core-updates or is it too late for that? They’re currently sitting in wip-haskell, but I never got around to get the indended Haskell ecosystem done. <vivien>Hi, I have created a guix channel with my package in it. If I do: guix build -L . <package>, it works. If I add the channel in ~/.config/guix/channels.scm and do guix pull, it fails with: (exception %exception (non-self-quoting 140736923757920 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>")) <vivien>How am I supposed to debug that? <grobx[m]>I'm using a manifest to setup a shell where I can develop on guix by simply using (package->development-manifest guile-studio) <nckhexen>vivien: I have no idea besides the obvious ‘does /var/guix/daemon-socket/socket exist’. ***foo-dogsquared1 is now known as foo-dogsquared
<nckhexen>So pull really works fine without your channel in channels.scm? <antipode>I just encountered a Rust crate that has the same name as one if its dependencies <antipode>I've modified antioxidant appropriately, but please don't. <antipode>IIUC, it works for upstream because the dependent (python-blake3) isn't only crates.io. <antipode>However, antioxidant interpreted 'same name -> let's link the library to itself'. <Kabouik>Are you on Wayland too podiki[m]? Wondering if transparency works with it at all (emacs-next-pgtk) <nckhexen>Kabouik: Works fine (for emacs values of fine: transparent text, yay). I'm not aware of a reason to use emacs when you could just use your compositor for that. <nckhexen>'alpha-background not working might be due to the age of my emacs, I just noticed… <nckhexen>Kabouik: Works perfectly after upgrading emacs to 29. <nckhexen>vivien: Is putting packages into a channel supported? <nckhexen>Or using packages as a channel, put it that way. <vivien>It used to work a few months ago <nckhexen>So it found guile-rdf? That's what it's currently not doing here. <vivien>It’s not in the same git branch so I guess it does not matter <nckhexen>I totally missed the ‘branch "guix"’ remark and was pulling from main 🤦 <PotentialUser-26>Hello. I wonder how substitutes are used. I want to update a package and there is a dependency to the package nss. It takes forever to build it locally on my Raspberry Pi400 but there is a substitute on bordeaux. Why it is not used? Do I have to specify something? <nckhexen>PotentialUser-26: Does ‘grep 7D602902D3 /etc/guix/acl’ return a thing? <lilyp>We recently had a staging merge, so there's a chance nss got updated and not yet built <PotentialUser-26>lilyp: I am not that deep into the staging process. I just tried guix weather nss -s arch64-linux <PotentialUser-26>nckhexen: Ok. I did. But now I have to wait until the current guix package -u sbcl is finished, before I try it with emacs-next-pgtk <nckhexen>You could run ‘guix build’ in parallel, but sure, do whatever you're comfortable with. <PotentialUser-26>nckhexen: Just to be sure. guix build puts it in the store but not in my profile? That sounds helpful on my x86 machine, but not on the PI. It would probably slow down it even more if I do this in parallel. <lilyp>PotentialUser-26: hmm, that's fishy then, but guix weather doesn't always appear to give the right results <lilyp>also consult guix package --dry-run; if it tells you derivations will be built, that's bad news for your pi <two[m]>`(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (faac)) (value #f))` <nckhexen>lilyp: Guix weather just reports the weather, not whe(urgh)ther your Guix would trust the substitutes. With bordeaux not being in the ACL everywhere, that happens. <nckhexen>two[m]: Looks like an oversight in gst-plugins-bad, yes. lilyp, are you available to fix that? <lilyp>Guess I don' t trust berlin then? <nckhexen>lilyp: Thanks for fixing it, but an answer would have been appreciated. <two[m]>i've also tried nix and all it does when updating is download something <two[m]>why can't that be substituted in guix? <PotentialUser-26>I try to create an identical developer environment on all my machines to make my colleagues curious. Just a few packages are missing before I freeze the setup. Guix getting more popular and mature. Even aarch64 is more and more supported. I love that. Playing around with guix home, too. Racket on aarch64 is not building due to the move to chez, but <nckhexen>two[m]: Why can't what be substituted in Guix? <nckhexen>You're obviously aware that updates in Guix are substituted, so what is your real question? <nckhexen>Most of us aren't familiar with what Nix does and doesn't do these days. <two[m]>nckhexen: are they? i have "computing derivation" running for a few minutes using a lot of cpu <lilyp>there seem to be packages that won't get substituted despite substitutes clearly being available according to guix weather <lilyp>see the telegram-desktop example from above <two[m]><nckhexen> "You're obviously aware that..." <- should i send a bug to the mailing list then? <two[m]>that updates aren't substituted on debian <antipode>two[m]: Before something can be substituted, the daemon needs to know its derivation, and at least in the current implementation, computing the derivation of Guix takes quite some time. <nckhexen>lilyp: That's not what that example shows. Just that grafts aren't presented as distinct from ‘builds’ in the UI. There's no indication from those pastes alone that ‘guix build telegram-desktop’ wouldn't download telegram-desktop, and here at least, it explicitly lists it as part of the ‘102.1 MB would be downloaded’ with --no-grafts. So, UI annoyance, but not worrying. <nckhexen>(It *is* also substituted. Try it if you don't trust me, as you shouldn't.) <antipode>two[m]: We know that updates are substituted (e.g. I just got some substitutes today), maybe in a few particular cases there is a bug, but then you would need to report a bug about a specific case, not about updates in general. <antipode>The compute-guix-derivation can be slow, but it's not a package build (so no substitute). <mbakke>re: faac, sorry for ruining the fun of fixing it :-) I just noticed Cuirass had failed <two[m]>does guix use openssl or gnu tls? <antipode>If you want a more specific answer, you need to elaborate on what you mean with 'guix' and 'use'. <two[m]>antipode: can it be cached if the part after the computing derivation fails? <lilyp>nckhexen: I don't trust you, because I did try. <antipode>two[m]: I suppose such a thing could be implemented. <lilyp>It seems something in the grafting logic causes a full build <nckhexen>substitution of /gnu/store/ivaqrf7gpc828c0aivzbapa69i3v08cb-webrtc-for-telegram-desktop-0-327.621f3da complete <nckhexen>Whoops, wrong paste, but it's in there, sec. <antipode>two[m]: (on TLS) E.g, do you mean 'when packages support multiple TLS backends, what backend does Guix choose?’, or do you mean what TLS thing does the substitution code use, or ...? <nckhexen>/gnu/store/pxsydr3ly6vd7drbcxa5h3ygrxihggmv-telegram-desktop-4.2.2 <two[m]>antipode: for fetching substitutes <antipode>More precisely, Guix uses Guile's web modules, which use the Guile bindings of GnuTLS for https. <nckhexen>lilyp: Does it print it with --dry-run --no-grafts, at least? <nckhexen>Not that I don't believe you, but just to check your Guix is remotely sane. <lilyp>without grafts, it gets substituted, with grafts there is an actual build <lilyp>try it if you don't trust me <nckhexen>lilyp: So, just to confirm: if you ’build’ with --no-grafts it substitutes the exact hash that it starts to build without --no-grafts? Or is it somehow different? <nckhexen>s/starts to build/compiles from source/ TBC. <lilyp>/gnu/store/6c81fg8c9nchixhnwnj4kzb95jg6alqr-telegram-desktop-4.2.2 <nckhexen>‘Mine’ (/gnu/store/pxsydr3ly6vd7drbcxa5h3ygrxihggmv-telegram-desktop-4.2.2) was. <two[m]>could you please merge my translations? <two[m]>i sent them to weblate a month ago <nckhexen>Yeah OK I can get to 6c81 (/gnu/store/ri9cks3ammvrqjavhy2l52xc7vjg47g1-telegram-desktop-4.2.2.drv). I have no idea what to do with that information. <mbakke>two: pinging roptat often works about translations <nckhexen>lilyp: <It seems something in the grafting logic causes a full build> Do you have a hunch beyond that? I assume you didn't choose telegram at random. <lilyp>I chose telegram because I know it to be a troublesome build. <lilyp>I did not choose it because of a particular flaw in the grafting logic that I know of. <mbakke>just 'guix build -d telegram-desktop' (with grafts) requires full builds of webkitgtk and webrtc-for-telegram-desktop <mbakke>The following derivations will be built: /gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv /gnu/store/4837agjhh1ghng95jsbym196n9pf81r6-webrtc-for-telegram-desktop-0-327.621f3da.drv /gnu/store/q8gvylzjj87fnh8ri97rpcckmk0n3phg-webkitgtk-2.36.7.drv <mbakke>and those derivation (which I asked for with -d) are already in my store! <mbakke>yet guix insists on full builds of the dependencies <nckhexen>I already have the exact webkitgtk it ‘needs’ in the store of a machine that never built telegram-desktop, so it's not an entirely new build. <nckhexen>Or, well, no, I guess that's not reliable now, never mind. <nckhexen>mbakke: Only the derivations, though, right? No built store items of either? <mbakke>nckhexen: well, guix says it only wants to build the derivations (which are already in the store), and then goes ahead to build the outputs of webrtc-for-telegram-desktop and webkitgtk <lilyp>I don't think it'd say it wants to build the derivations when the store items already exist <nckhexen>That seems to be my case with webkitgtk. <vivien>Ahem nckhexen the error was because I had the wrong directory in my channels.scm so there was no "guix" branch in the repo I pointed to… sorry… <mbakke>errh, even commenting those inputs and running 'guix build -d telegram-desktop' proceeds to do a full package build ... does the grafting derivation actually need the output of the ungrafted package? <lilyp>commenting inputs actually changes the package <nckhexen>vivien: Just glad you solved it, I couldn't make it fail. <mbakke>right, but I'd expect 'guix build -f' to not require building anything at all, apart from computing .drv's <lilyp>wait, so we're building the package to check what we need to build? spooky <nckhexen>I've heard of grafts ‘forcing’ things but this is excessive. <nckhexen>But maybe that's all it is, in an unexpectedly deep way? <mbakke>nckhexen: what does 'guix build -d telegram-desktop' yield for you? <mbakke>presumably it's not /gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv <mbakke>do we have a good tool to diff .drv's? <rekado>mbakke: I view them in Emacs, which displays them nicely (probably something emacs-guix does); and then I use ediff-buffers on it. <mbakke>nckhexen: does that grafting derivation depend on 92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv or 4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv ? <mbakke>rekado: thanks for the tip! I also view them in emacs but did not consider ediff-buffers <mbakke>it seems that 'guix build -d foo' depends on a different .drv than 'guix build --no-grafts -d foo' <nckhexen>mbakke: Is it foolish to think that's not a grafting derivation? (So, er, neither?) <mbakke>nckhexen: oh, I suppose you're on a different revision.. can you see if it depends on the same drv as 'guix build --no-grafts -d telegram-desktop', or something else? <mbakke>or, if it's not a grafting derivation (which only depends on the ungrafted telegram-desktop + a few more), paste it? *nckhexen working ATM, sorry, but will catch up. <mbakke>inspecting the two different .drv's I have for telegram-desktop, they depend on different drvs of pango and several others ... there is clearly a bug here somewhere <mbakke>curious to see what it outputs when webkitgtk finishes building <mbakke>berlin wants to build gcc-9.5.0 among other things, starts grafting, and then starts building things <podiki[m]>nckhexen: so you got alpha-background on our emacs-next package, what wm/de are you on? <nckhexen>OK, not just me then. I was feeling extremely stupid but at least now I have company. <podiki[m]>I didn't know I needed background alpha until it wouldn't work for me.... <nckhexen>podiki[m]: Yeah. I thought that was the question? <nckhexen>Well, it was Kabouik's question anyway. That's all I answered. I don't know if there was more context. <podiki[m]>yes, well good to know it works on wayland, but should also on X I thought (with compositor) <podiki[m]>likely an X/compositor thing then, local setup <nckhexen>podiki[m]: Come to the dark side, we have transparency. <podiki[m]>i need my stumpwm (or maybe xmonad)....I know people like sway but I'm addicted to the lisp <podiki[m]>I have the nice blurry transparency with picom, would look very nice with alpha-background methinks <nckhexen>I understand. If a decent xmonad Wayland ‘fork’ ever materialised I'm switching back. *mbakke needs to do other stuff, will get back to graft debugging later <Kabouik>I haven't gotten transparency to work either podiki[m], on Wayland, but good to know that you get the same issue on X. <Kabouik>The blog post I linked here didn't seem to cover compositor-specificities, but since it didn't work for me on Wayland and emacs-next-pgtk, I was thinking that maybe Wayland was my issue. Apparently it is not. <mbakke>one theory is that the grafting machinery also affect fixed-output derivations such as git checkouts *mbakke could not help himself <nckhexen>‘On Wayland’ isn't very meaningful, and I should have specified that I use Sway earlier. <mbakke>oh, graft derivations needing the output of the ungrafted package is not a bug, according to a comment in tests/grafts.scm:1053 <mbakke>there is still a bug here somewhere, though <mbakke>now I'm in the funny situation where I have the output of 'guix build telegram-desktop', but not 'guix build --no-grafts telegram-desktop' <abhiseck`>"gcc hello.c -o hello.o" works but "gcc -static hello.c -o hello.o" returns a linker error in guix system. why's that? <two[m]>looks like translations from other authors have been pulled, but mine weren't? <podiki[m]>mbakke: yes, have seen mahogany, but I think it is far from being a WM yet. thoughmaybe I should try working on it at some point... <antipode>abhiseck: Works for me: echo 'int foo() {return 0;}' > foo.c && guix shell --pure gcc-toolchain -- gcc --static -c foo.c -o hello.o <nckhexen>two[m]: German? The last po merge included that… <nckhexen>antipode: If you have glibc:static somehow, otherwise you get the -lc error. <nckhexen>I don't know what's going on there, but your pure environment is sus. <antipode>I did a --pure -- if there is a glibc:static, it's one that's implied by "gcc-toolchain". <nckhexen>antipode: Uh, you disable linking, so of course it will succeed. <antipode>Oops I thought that abhiseck's command included -c <antipode>Why name your compiled stuff 'stuff.o' when you are actually linking ... <antipode>abhiseck`: I can reproduce with 'echo 'int foo() {return 0;}' > foo.c && guix shell --pure hello gcc-toolchain -- gcc --static foo.c -o hello.o' <two[m]>translations by kyrylo are in uk.po, but mine are not? <antipode>abhiseck`: What's the reason for linking statically? <antipode>If it's to get a binary that works on non-Guix systems, that (possibly) won't work, as our glibc's 'system' function contains a reference to /gnu/store/.../bin/bash <antipode>(Doesn't address the problem though ...) <antipode>The problem that gcc-toolchain in a pure environment cannot find its glibc:static, even though the equivalent in the build environment 'just works' (IIUC) *antipode checks if glibc:static is in the implicit inputs <nckhexen>I think we have different opinions then, but that's fair. <antipode>(A solution "just add glibc:static to your 'guix shell'" would be fine for me too) <antipode>It's in the implicit inputs: (assoc-ref (bag-direct-inputs (package->bag (specification->package "hello"))) "libc:static") <two[m]>are issues moderated before they are shown on the website? <nckhexen>(They aren't moderated before appearing on the Web site. It's weird.) <nckhexen>Bah, the git repository doesn't track authorship. And the Web UI is what it is. Are you sure you committed translations before 6 October, two[m]? <patched[m]>Is a there a nice way to handle profiles in emacs? E.g., when I run `run-python`, I would like the python repl to use a specific profile. <nckhexen>two[m]: "Видаляємо ~a..." is one of yours, no? <podiki[m]>patched: there was a recent discussion on guix-devel about things like environments and emacs, perhaps helpful? <two[m]>nckhexen: yes but that's from two months ago <two[m]>my translations from 1 months ago are not but his from 2 weeks ago are <nckhexen>I'm not familiar with Weblate (I doubt anyone here besides roptat is) but that seems like it shouldn't be able to happen, technically… <abhiseck`>antipode: "What's the reason for linking statically?" <-- it was for learning purpose, I'm learning how to statically link c programs <roptat>two[m], oh it's marked as "previously translated" <roptat>I think because we have a big repo, it takes some time to update, and if you translate during that time frame, the update "erases" your translation <roptat>hopefully it sticks this time :/ <abhiseck`>antipode: I thought '-c' means only compile but don't link, I didn't know you have to pass "-static -c" together (to link statically) and shouldn't do "-o *.o". <PotentialUser-26>nss is now available as substitute for aarch64. At least emacs-next-gtk builds there. Thank you <podiki[m]>Kabouik: on the alpha-background front, I did get it with X but using the Arch emacs-git package on my laptop (where emacs-next from guix didn't work), so maybe a guix build option (for X)...? <Kabouik>Interesting podiki[m], maybe it's a missing build option but hopefully not one specific to X <Kabouik>I also asked the question in #systemcrafters since I think daviwil uses Guix and I see transparent background in their videos <podiki[m]>I'll take a look at the build options for anything obvious <two[m]>@roptat i cannot update translations, "Lock could not be acquired in 1" <nckhexen>sneek: later ask antipode: Do we have a word for (Scheme) ‘record’? Best I have so far is ‘dossier’, which is meh. There's also the usual cheat option: ‘record (zn., informatica)’. <roptat>two[m], if you ignore, the message goes away but the translation is not updated, so it stays empty <roptat>you should "fix string" to use the translation that is suggested (if it's correct) <roptat>two[m], that might be because I was looking at the same translation, I don't think the components are locked <podiki[m]>Kabouik: over on reddit someone said they also don't have transparency on nix.... curious <nckhexen>sneek: later ask antipode: I did go for ‘record’, but am open to better ideas. <nckhexen>Kabouik: So which compositor do you use? <Kabouik>I use Sway nckhexen, which I heard is its own compositor, so I removed compton/picom from my old i3 config <podiki[m]>well sounds like it should work for you, since it works for nckhexen on sway... <Kabouik>I didn't get that it works for nckhexen, missed that. What is the corresponding configuration you use nckhexen? <nckhexen>Kabouik: I just C-j'd (set-frame-parameter nil 'alpha-background 50) to test. I don't use it myself. <nckhexen>Another thing I noticed later: when I full-screen emacs (Super-f) , it blends with… grey or so. But unmaximised it blends fine. <nckhexen>Kabouik: <missed that> OK, I was severely confused by your later replies, that explains it :) <podiki[m]>the only difference I see right now is that the arch package has newer gtk and cairo (and guix refresh doesn't see a newer cairo) *unmatched-paren gives up on home-emacs-service-type <nckhexen>Kabouik: Are there things which aren't their own compositor? What are they called? <nckhexen>unmatched-paren: Sorry you didn't find any help. Maybe the answer will jump out at you later. <unmatched-paren>nckhexen: Well, even with the single simplest setup I could think of, it still behaved erratically <nckhexen>This is emacs-next-pgtk-29.0.50-1.0a5477b (run as a daemon, but that shouldn't® matter… right?) <unmatched-paren>emacs --fg-daemon only, installing the packages into the profile, and installing the init file as ~/.emacs <nckhexen>I don't use home myself, as I'm sure you're tired of hearing. <nckhexen>unmatched-paren: My version comment was aimed at Kabouik, sorry, that was confusing. <unmatched-paren>When I launched it, it didn't seem to evaluate the .emacs, and when I relogined, the emacsclients failed with something like ``cannot connect to socket: permission denied'' <Kabouik>Yeah I noticed that full screen windows in Sway lose transparency nckhexen, so I was trying only out of fullscreen with emacs, but no dice. <unmatched-paren>Also, when I ``herd restart emacs'', it doesn't restart anything; only if i rereconfigure. <nckhexen>Kabouik: Now I'm intrigued. I did literally nothing but evaluate that set-frame-parameter line. I didn't configure anything. <nckhexen>I'll see if I can shut down emacs & try without .emacs… <unmatched-paren>I'm gonna try writing a home-sway-service-type, which won't have the same issues because no shepherd-services will be necessary. <podiki[m]>well cairo 1.16 was from oct 2018, latest is 1.17.4 from nov 2020.... <nckhexen>Ew. Menu bars. Icons. Huge fonts. What vanilla-flavoured hell is this. <nckhexen>Menu bar + icons don't turn transparent, I of course hadn't noticed that, but otherwise works fine. <podiki[m]>anyone know why cairo was never updated? in fact I see it was updated in 2021-03 yet just to 1.16 <nckhexen>I mean, I do have a touchscreen, it's tempting to see how far in this direction I could take emacs… <Kabouik>nckhexen: yes nckhexen, this was part of why I didn't even consider using Emacs GUI in the first place. Now it is a little bit better after I understood how to make it look minimmal and, well, more terminal like. <Kabouik>Speaking of touchscreen, I end up being pretty happy about my GPD Pocket 3 running Guix, nckhexen. I know you were kinda interested in what would be my experience with it. It's my daily machine (with external monitors at work, of course), <podiki[m]>cairo...does wayland use cairo? is that only an X thing? <Kabouik>I do miss a RCtrl key, and I have a lot of anger towards those non-standard ; and ' key positioins. <nckhexen>Kabouik: Ah, thanks for the interim review. Yes, I was, and kudos for remembering. <nckhexen>podiki[m]: Cairo is just a graphics library, neither ‘Wayland’ nor X use it, clients do, the display tech doesn't care. <nckhexen>Kabouik: Interesting that it's your daily machine. <podiki[m]>well now i'm down a rabbit hole of why cairo is old in guix <nckhexen>I think I mentioned then that I mainlined a Vaio P for years, but I'm not sure I could go back to that. <nckhexen>podiki[m]: librsvg? But then that's no direct answer, just a vague smell. <nckhexen>I can never remember if Rust is c-u or just feels that way. <podiki[m]>i can't remember librsvg and all that, thought it was untangled in last core-updates? <nckhexen>Oh, possible, I am still but a filthy ‘master’ peasant. <Kabouik>It's powerful enough for me. The small screen can get annoying, but since I use mostly terminal applications, I can usually just change the font size as I want. Or fullscreen/tab windows with Sway when my workspace is tiled. At work I use it with two external monitors (one HDMI and one USB-C). At home too, when I'm not too lazy to go upstairs where they are. Kanshi is a great little utility to automatically recognize which displays are connected. I <Kabouik>find it a lot better than autorandr that I was using in X. <podiki[m]>anyway, cairo 1.17.4 builds with no changes, other than removing patches (i believe they aren't needed but should check the cve's) and updating source url <podiki[m]>nckhexen: i mean in last core-updates merge, i remember a lot of librsvg wrangling <podiki[m]>cairo is a world rebuild if there ever was one, ~9k packages I think <nckhexen>Kabouik: I'm going to remember the kanshi trick & try it on my dock. *nckhexen herd restarts emacs back into sanity. <Kabouik>It was a game changer for me. Probably I was misusing the xrandr/arandr/autorandr/srandr thingies, but with kanshi all I need is autostart Kanshi with Sway, and the kanshi config is pretty straigtforward and quick to write. With things like `workspace 1 output HDMI-A-1 DP-8 DSI-1` in my Sway config, I can also handle multiple setups to organize my workspaces. <nckhexen>I tried a few things to make transparency break, but it persisted. <podiki[m]>I could submit a core-updates patch for cairo with a big caveate "i don't know anything but cairo is old and this builds" <Kabouik>That is encouraging nckhexen. It might be something in my config, or my theme. I will keep trying after I finish reviewing Systemcrafters dotfiles to improve my emacs base setup, and will try without .emacs too. <podiki[m]>over on X-land I'm out of ideas and no idea how to debug, annoying <nckhexen>podiki[m]: It could be built as a branch on berlin if you want. That happens. <Kabouik>I'm sorry to have conveyed that frustration podiki[m] when I mentioned transparency in Emacs, but at least happy that some Guix wizards like you are aware of that potential issue now <podiki[m]>nckhexen: a quick look at the changelog and I didn't notice anything serious, if things work already I think the newer version would at least build everything (whether other bugs crop up I dont' know) <podiki[m]>hahah wizard...I'll take it, even if I'm more the blindly stumbling around junior witch <nckhexen>Chances of it making the release are IMO slim (but that doesn't mean none), just to make that clear. <podiki[m]>whatever the word is for an apprentice with more enthusiasm than sense <podiki[m]>nckhexen: yeah, just wondering if there is a good reason it wasn't updated to a more current version when it was last updated; perhaps no reason, just missed <nckhexen>I'm Mickey in Fantasia. I don't know who the wizard is. <podiki[m]>since I did the (very quick) work of a simple update I'll submit a patch later and people can say something if they know something <nckhexen>Sometimes, things just work. It happens. <podiki[m]>seems just fixes and new pixel format support <podiki[m]>also 1.17.4 was nearly 2 years ago now and the notes say the current maintainer wasn't going to have time anymore <Kabouik>Just curious: you mentioned above that you C-j'd (set-frame-parameter nil 'alpha-background 50) nckhexen. C-j for me just seems to create a new line at column position 0. Is there more to know about C-j? <podiki[m]>C-j will put the output on the next line, here I just get "nil" <podiki[m]>vs C-x-e which evaluates but output just in minibuffer <podiki[m]>(doing both with cursor at end of the s-exp that is) *podiki[m] is wanting some "free heat" and is building emacs-next with newer cairo <nckhexen>Make sure point is at the end of the line, after the closing ), when you hit C-j. <Kabouik>Oh, so that was C-j after typing the elisp line in M-x then? <nckhexen>I used the scratch buffer, then evaluated the line. <Kabouik>I didn't know I could do that, cool. <podiki[m]>alternatively, you could M-: to do some elisp in the minibuffer <nckhexen>Yes. My preference for scratch + C-j is just that, there's no underlying reason. Anything that evaluates lisp should have the same effect. <Kabouik>I had no idea the scratch buffer could evaluate lisp, I was seeing that as just a draft buffer with no filename yet <podiki[m]>you can use it for whatever, but I believe it defaults to lisp mode <Kabouik>Well. Background transparency works for me then. I must have had something conflicting with it in my config <Kabouik>(You're alone with no transparency now podiki[m]!) <podiki[m]>is this the the little inconsequential thing that gets me to wayland and spending the day getting a sway config going? *nckhexen makes soft shunning noises :} *podiki[m] contemplates the things he should do and the thing he doesn't have to <Kabouik>The little inconsequential thing that made me get to Wayland was… Moving to Guix from Solus. Quite a time sink I have found there, I thought spending time on the Wayland transition would be insignificant next to it (and it kind of was indeed!) <Lumine>Kabouik: I also came to Guix from Solus :) <Kabouik>The transition was smoother than I expected, moving to Sway was easy, and the programs I had to replace actually kind of worked better than those I was using before (like kanshi discussed above). <nckhexen>So all you Solus refugees aren't pining for the budge? <nckhexen>(I've never used it, but it's all I know of Solus.) <Lumine>I was using Plasma actually but I started with Budgie, which was nice <nckhexen>‘Moving’ to Sway from i3 is almost silly. <podiki[m]>how does sway compare to other tiling wms (I did use i3 a long time ago, guess it is the same-ish?) <Kabouik>If I were to go back to a floating WM, I'd probably get Budgie too. *podiki[m] has started down the librsvg rabbit hole <Kabouik>Yes nckhexen, but my previous attempts were not so successful because of small things I couldn't replace, or deep rabbit holes <nckhexen>I wish I could say I had to battle dragons to get to Wayland, but the entire transition wasn't even worth the name. So I'm interested in how it can differ so much for others. <Kabouik>I don't remember any clear example, but a combination of (1) I am a noob today, but I started noobier; (2) Solus doesn't have a great number of packages in its repository and I could compile things but that was annoying to maintain sometimes; (3) I also use i3 on my phone in a LXC container and I was using the exact same i3 config on my devices, so that meant breaking that easy cross-device-sync of my config and programs <Kabouik>But as I said, my last attempt this summer when moving to Guix was a lot smoother than expected. <nckhexen>‘I am a noob’ ‘I use i3 in an LXC container’ pretty sure you have to pick just one, legally speaking. <Kabouik>But that doesn't compare to mastering Guix great powers and packaging things beyond just "guix import" <Kabouik>Or, lately, learning the wonders of emacs. <nckhexen>Maybe my memory's gone rosy but I think I just ‘cp -a ~/.config/i3 ~/.config/sway’ and that was it. I'm sure there are edge cases. I suspect my current sway config is no longer a valid i3 one. <Kabouik>I started with a cp too, but there were some changes yes, and optimization that could probably have worked in i3 as well, but didn't occur to me at the time I was using i3. <nckhexen>But my sway == i3 above was not said in jest. <podiki[m]>well...updating cairo means librsvg doesn't build, so updated librsvg and still fails (probably something easy here, about "vendor" so maybe some unvendoring step failed) <podiki[m]>I'll just send the easy patch and this info later <Kabouik>There are other things with the transition to Wayland though, like Xwayland scaling vs Wayland scaling. Remember I'm using a 8" 1200p laptop, so I need scaling, and having to deal with X-only programs shown in Xwayland with non-dynamic scaling in a multimonitor setup can be annoying. <nckhexen>True. These are all things I never had to deal with. <antipode>nckxhhexen: None that I know of (concerning ‘record’) <sneek>Welcome back antipode, you have 2 messages! <sneek>antipode, nckhexen says: Do we have a word for (Scheme) ‘record’? Best I have so far is ‘dossier’, which is meh. There's also the usual cheat option: ‘record (zn., informatica)’. <sneek>antipode, nckhexen says: I did go for ‘record’, but am open to better ideas. <nckhexen>I've remembered exactly one Wayland-related regression in all this time: I had to set MOZ_USE_XINPUT2=1 to get touch to work in FF. <antipode>‘dossier’ in Nederlands is kinda meh but so is ‘record’ in English IMO <nckhexen>Right. It's been normalised in English (these were record-keeping machines after all) but not in Dutch so it sounds bizarre, whilst being the same word. *Lumine was "fancy" and used the i3-gaps with polybar and all kinds of other goodies <nckhexen>antipode: I noticed, which means nobody has :) <nckhexen>That's not nice if someone has. I just haven't noticed. Sorry hypothetical someone. <antipode>Does '[...]/gnome-bacgrounds-42.0.tar.xz.drv' timed out sound familiar? <antipode>It doesn't have a snippet so sounds like a network hang to me. <antipode>The log is garbled (mixed with other logs, on ci.guix.gnu.org) <antipode>Though it says it's at /var/log/guix/drvs/cdlj97q2w5cyxsjmcjjqwd7dbv4mg4c9-gnome-backgrounds-42.0.tar.xz.drv.gz <antipode>I think I've heard somewhere that logs are substitutable ... <podiki[m]>so I swear I tried this before, but emacs-next-pgtk does have alpha-background for me on X <podiki[m]>(and I had left pgtk behind since I think it's more for wayland, but that's what i get) <antipode>Hypothesis: maybe one of the mirrors is b0rken <antipode>nckhexen: Are you available to press some 'rebuild' buttons? <Kabouik>Same for me, I would have sweared I have tried what I did when it worked. And actually I can still break transparency apparently now, something in my config is setting background back to 100 somehow. <podiki[m]>"People using X should _never_ use PGTK. The regular X build does a much <podiki[m]>better job at supporting that than PGTK ever will." from the emacs devel list, and yet! <podiki[m]>i wonder if some of that (pgtk bugs on x) is for people in DEs and not simpler WMs since I never ran into any problems <antipode>nckhexen: The rebuilding 'worked' in the sense that I now know I need to adjust 'librsvg'. <Kabouik>I think (use-package blah) is not something I should use on Guix because emacs package are installed through Guix, not through emacs own package manager. I assume (require 'blah) is the way. But how do I pass extra options like those? https://0x0.st/owKj.txt <podiki[m]>you may need to tell use-package to not automatically download packages (if you used ensure) <podiki[m]>you can still use use-package, if packages and emacs in the same profile it should be on the load-path <Kabouik>I get a "Symbol's function definition is void: use-package" when I use use-packages (and emacs does not eval my .emacs) <Kabouik>The doom-modeline here was just an example, I have a few other packages whose base configuration I took from their README are based on use-package <podiki[m]>that means you don't have use-package installed/found by emacs <Kabouik>Oh, I had no idea that actually was a package too <Kabouik>I should have looked, sorry. And thank you! 