<bdju>dragon-drop isn't working for me after guix upgrades <bdju>`which dragon` says command not found <bdju>I was using it in a bunch of scripts <bdju>it's still in my manifest file, I guix install'd it again, no change <bdju>is there a way to check the /gnu/store hash thing of a package I have installed and then go find what files it has from there? because it just seems like the dragon binary from dragon-drop is gone and I wonder if there's one with another name <Gooberpatrol66>what's an example of a package where the build directory is not in the root of the source tree? <mange>I think anything using #:out-of-source? with the cmake build system does that. The awesome window manager, for instance. <mange>Yeah, looking at cmake-build-system.scm it does (mkdir "../build") (chdir "../build") before building. <viaken>Did the Linux deprecation move forward or something? I tried to system init and I don't see kernel files in /boot{,/efi}. <Gooberpatrol66>mange: is there a way to build in a subdir that already exists? (because the makefile is not in root) <mange>Can you just chdir into the directory? <viaken>Oh shoot, that was an April 1st post. <viaken>Yeah, it got me. :) I should've known better. <apteryx>rekado: no worreis about anonip; we could probably just disable it instead of having it respawn for now <bdju>no one knows what's wrong with dragon-drop? *apteryx is about to push a big set of GNOME updates to master <lilyp>apteryx: any biggies missing from gnome 42? IIRC a lot of packages require newer gobject-introspection <apteryx>nothing from gnome-core I think, if every gnome core things are under (gnu packages gnome) <apteryx>I even ventured in GNOME 43 land, with some pain (libsoup3) <rekado>bdju: use “find $(guix build the-thing)” to see all files in the built package <bdju>I'm seeing /bin/bin/dragon, could that be the problem? (extra bin) <bdju>inside bin is another bin and a share despite the share further up <bdju>although one share has doc and the other has man. I'm not sure what this usually look slike <bdju>thanks for the tip by the way <wingo>hey guix people have fun in paris this weekend!!! <mbakke>efraim: that sounds very un-free to me <efraim>mbakke: The note in the readme I feel like maybe could be ignored, but the part added to the LICENSE file is pretty explicit <efraim>luckily the change comes after the 1.0.63 that we have packaged <Luk6655>Are there any recommendations regarding storage for /gnu/store? (filesystem - ext4/btrfs/lvm). <Luk6655>Specifically if there are any (performance) issues running on btrfs/lvm. <jpoiret>Luk6655: people really like putting it on fses with transparent compression <jpoiret>i've been running it on btrfs without compression myself <jpoiret>lvm shouldn't pose any issues either <Luk6655>I'm currently exploring use of btrfs. All my storage is vanilla ext4 (+1 lvm volume) but I'll likely be migrating to btrfs. <jpoiret>be careful of the btrfs raids though, some of them are completely unusuable <Luk6655>No, no raid. I'll keep my archive volume as lvm mirror (a slow spinning disc) and I plan btrfs for everything else. Perhaps with exception of /tmp. It seems to tick all the boxes (ability to shrink as well as grow online, transparent deduplication etc) <Luk6655>Also I wonder if guix in $home has some disadvantages(reproducibility-wise) compared with guix os <Luk6655>Assuming one uses guix shell - - pure, it should allow one to achieve the same results as on the os itself. <mbakke>I was a happy user of btrfs RAID1 for some time until I lost a drive and discovered that btrfs would not boot while degraded <mbakke>and promptly went back to mdraid <Luk6655>It failed to boot, but was the data recoverable? <mbakke>Luk6655: yes, it could be mounted from a live USB with some specific option, don't remember what <Luk6655>Ok, so very inconvenient, but not destructive. Still, thanks for the heads up. <mbakke>it was some time ago, maybe things have changed <mbakke>but I don't want to make the same mistake again :P ***jesopo is now known as jess
<mbakke>I tried updating antlr4 to fix python-afdko on core-updates, but getting "error: cannot find symbol Path.of" (the of method appears to be missing from the Path interface somehow). <mbakke>anyone familiar with java who knows what might be going on? <klm_>I've just written a custom shepherd-root-service which won't start. Where can I find its logs? <pkill9>what online service is best to backup to? <jpoiret>mbakke: that's a grub issue, i was mostly takling about RAID5/6 <apteryx>unmatched-paren: oh, you had a pkgconf package? /me looks into it <sneek>Welcome back apteryx, you have 1 message! <apteryx>mbakke: you can boot degraded if you use root=degraded or something as kernel argument <apteryx>or degraded as an option on your specific mount directly <ulfvonbelow>hmm, on my 6-core machine ungoogled-chromium actually does use 50GB of virtual memory (6.2GB resident / 8GB RAM + 25GB / 50GB swap, not sure how the math adds up) <apteryx>mbakke: I ended merging my GNOME changes before the staging merge, I got excited after testing it all :-). If the conflicts are too painful I can volunteer to merge master into staging to iron them out; let me know. <mbakke>apteryx: nice! it would be great if you could handle the merge to staging and further to core-updates :-) <mbakke>apteryx: in case you did not know, GNOME stopped using intltool years ago and just need gettext now <apteryx>right, I saw this in your commits and made the switch where I spotted intltool usage; sometimes it was still needed by some package <mbakke>the mutter upgrade still adds mutter-9 to runpath, that should probably be removed? <mbakke>I noticed you added intltool to mutter, that's why I mentioned it :) <apteryx>probably the configure option can be removed now that it's handled as a patch <apteryx>oh. perhaps a merge conflict :-(. there was many of them, to the point I suspected git had a problem, but I realized they mostly were about adding #:meson meson-60, ah <mbakke>heh, sorry about that, didn't expect that someone would be brave enough to upgrade to GNOME 42 on 'master' :-) <apteryx>the libsoup2/libsoup3 mixing was a bit unholy I guess, but we'll be ready for a rather painless GNOME 43 updates <ss2>gnome-bluetooth isn't building for me. The source is erroring out again. <apteryx>you are building without substitutes? <ss2>I began reconfiguring right after you pushed early on. There weren't substitutes available yet. <apteryx>I forgot to adapt the source URL it seems <ss2>yeah, removing +minor fixes it. <civodul>thanks all for the all the cool stuff that's been happening in the repo lately :-) <civodul>core-updates, staging, emacs native compilation, etc. <apteryx>mbakke: about the merge of master into other branches, I'll look into it at the end of my day <civodul>once we're done with the event, i'm happy to give a hand for a ten years release! :-) ***Dynom_ is now known as Guest7984
<civodul>i think it's an area where Guix really shines <civodul>plain "guix graph" already does a lot <apteryx>would be interesting to have the author do another article comparing the same flow but with Guix <civodul>srfi/srfi-1.scm:241:2: In procedure map: <wingo>that error message tho, straight from the early nineties <antipode>This ‘Gephi’ mentioned in the blog seems rather useful for complicated graphs. <civodul>too bad such mistakes can remain for so long <civodul>we prolly need two things: sanitizers, and an escalation process :-) <apteryx>apologies for failing to act on that report; seems the email didn't reach my inbox <apteryx>or perhaps I deleted it by mistakes (eh, only 196 messages left in that INBOX!) <civodul>np! it's easy to overlook things in the mass of bug reports and patches we get <civodul>that's why an escalation process would be nice <apteryx>I think CC'ing the author of problematic commit ought to be enough <apteryx>we already stress that committers must stand by their changes and be ready to fix any problem found with them <abrenon>I fail to build guix from my local clone of the repos: I get a torrent (fills my terminal's buffer) of "@ref reference to nonexistent node" errors trying to compile doc/guix.de.texi <abrenon>given the previous lines of this chan, I take it you have all been rebuilding without any problem on the latest commits <apteryx>perhaps need to run ./bootstrap anew <abrenon>(I've pulled three times, cleaned and re-run everything from ./bootstrap already) <apteryx>civodul: it'd be cool to be notified when something such as the website fails to build <podiki[m]>I've had to clean out most of the doc directory recently and then bootstrap/configure again <podiki[m]>i wasn't sure what so I just deleted all of doc I think and then used git to restore to previous state (I didn't know what was generated or not) <abrenon>ohhhh that might be worth noting, thank you ! <abrenon>I missed the info that old clones would have to be fixed by hand <abrenon>./boostrap is doing many things it previously wasn't <podiki[m]>I don't, I just know to start deleting stuff after I try like 3 times to make and get weird results :) something about translations and what is generated/built maybe? would like to know too <abrenon>it would be nice if the Makefile could somehow do its job and figure when a rebuild is required ^^ <abrenon>looks like integrating translations with a code repos is no easy task, I wish I understood it better <jpoiret>you can use git reset --hard and git clean to get a clean build directory <podiki[m]>yeah, I do that sometimes too if needed (i often have some patch series in progress so try not to do anything too drastic; but yes stashes, etc.) ***maximed is now known as antipode
<abrenon>well yes, my next move would have been to try and clone anew somewhere else to see if my local version was somehow turned evil or if the problem was from the code itself <abrenon>I was just unfortunately too shallow in my analyzis of git status: seeing nothing modified, I forgot about .gitignore and too quickly assumed it meant my repos was as good as a fresh clone <efraim>for the translations I normally 'rm -r -- po doc; git checkout -- po doc' and then rerun configure <tschilptschilp23>Hi! I'm just trying to write an r-package definition to be used with 'guix shell PACKAGES -f DEFINITION.scm' to look at a shiny-app. This here is the definition: http://paste.debian.net/1253746. However, when I run the command, I receive that one here: http://paste.debian.net/1253747. I've already compared to other r-package definitions and I can't really make out what's going on. Is guix somehow telling me, that I'm missing a <tschilptschilp23>module? The package-section itself comes from 'guix import cran RcmdrMisc', I haven't really fiddled around with details here. <zamfofex>Take the parentheses out of the package at the bottom. <tschilptschilp23>zamfofex: Thanks a lot! It was pretty frustrating not even getting towards dependency-games :) <abrenon>efraim: should that be part of the normal contributing process ? should we document that ? can we hope to reach a state where this is no longer needed ? <unmatched-paren>abrenon: personally: (1) not ideally (2) yes (3) idk, never looked at the build system for fear of drowning in autotools :) <abrenon>haha a good reason not to touch it indeed : ) <unmatched-paren>i've seen a claim that fixing the other annoying problem -- the need to do `make clean-go` sometimes -- would require modifications to guile itself <rekado>the text for “guix archive --import” looks wrong <rekado>“if it is signed by a public key not among the authorized keys” <rekado>we don’t sign with a *public* key, do we? <unmatched-paren>podiki[m]: hmm, well i just came across a package that uses a nightly feature stabilised in 1.60 <unmatched-paren>and since the feature is in the Cargo.toml, the fix must be applied to every single dependent of the package <podiki[m]>but each should be just adding on to the rust chain building and easy, I would hope <zamfofex>rekado: It seems wrong, but if you replace it with “private key”, I’d assume it’s wrong too, since then you don’t authorize private keys. <unmatched-paren>(setting RUSTC_BOOTSTRAP=1 and adding -Z namespaced-features to the cargo flags) <abrenon>yeah, it's almost a figure of speech <podiki[m]>unmatched-paren: well it should be built on staging :) if you just need 1.60 <abrenon>I found it very understandable when I needed to read that part of the doc last week, and I took it to mean "signed with the private component of an asymmetric key which public component has been authorized" <podiki[m]>or on antiox branch; both have subs according to web interface <podiki[m]>yup, behind a bit, but as I said, staging/antiox will get you a few more versions when they are merged (or pull from there) *unmatched-paren resumes poking around in guixrus for something to upstream <rekado>I think there’s a better way to express that we use a key pair here. <zamfofex>Maybe “if it is signed by a private key whose public key is not authorized” or something along those lines? <apteryx>unmatched-paren: rust releases are every 6 weeks. that's a bit much <apteryx>for somethnig that takes forever to build and requires every version that came before <podiki[m]>unmatched-paren: ah, 57702 will also be needed for cbindgen (and thus icecat update) <podiki[m]>I'll note that on the thread about icecat, will be needed soon <gnucode>hmmm, I can't seem to shutdown my guix system server... <gnucode>sudo halt... is just apparently chilling and not doing anything. <gnucode>then when I type in logout in the tty...I cannot login again to that tty. <gnucode>maybe it's time to raise the elephant.... <gnucode>I just logged into as root and ran halt... still the computer is not shutting down... <gnucode>raising skinny elephants in utterly boring... worked! <ekaitz>gnucode: I know of some hardware with the same issue <gnucode>ekaitz: I just raised the elephant. Linux provides a method to hard shutdown your computer with some keystrokes. That let me shutdown the machine. <gnucode>Now, I am wanting to replace elogind with seatd...that would be nice <ekaitz>gnucode: please ping me when you have any news <gnucode>ekaitz: well the first error that I am getting is 'file-system-/sys/fs/cgroup' provided more than once. Using %desktop-services... <gnucode>I would love to figure out how to use sway with %base-services, but I'm not sure how... <ekaitz>gnucode: you can also filter %desktop-services to use the one you want <ekaitz>but we should take a look also on why doesn't the device shut down... <gnucode>ekaitz: yeah my config removes a ton of desktop services... <singpolyma>Anyone around who knows about maven-build-system? It seems like #:exclude does not allow removing dependencies, only maven plugins, is that correct? <podiki[m]>yes the magic sysreq keys is good if it comes to that , I remember "busier" as the acronym, backwards <unmatched-paren>gnucode: I've s/elogind/seatd/ on my machine, but you have to be aware of one thing: <unmatched-paren>polkit doesn't work on seatd, so upower and networkmanager won't work <gnucode>unmatched-paren can you send me a copy of your config? <gnucode>I don't actually use upower or networkmanager. :) <gnucode>unmatched-paren: are you using sway? <unmatched-paren>it was *supposed* to be a version of seatd that removes all dependencies on elogind <gnucode>guix show seatd shows that seatd does depend on elogind <unmatched-paren>it also uses sway 1.7 since master only has 1.6, but there's also sway-latest also in guixrus <unmatched-paren>Seatd provides libseat, an abstraction library allowing applications to support both daemons *unmatched-paren still can't find any package from guixrus to upstream :( <gnucode>unmatched-paren: I didn't know guixrus had sway-latest... <gnucode>unmatched-paren why is master stuck on sway 1.6 ? <unmatched-paren>gnucode: it needs a new version of several core libraries (libdrm, wayland-protocols) <gnucode>unmatched-paren sounds good. Would you say that sway 1.7 is much better than 1.6 ? <zamfofex>Kind of a miscellaneous question, but does anyone know what’s the difference between “FAIL” and “XFAIL” in coreutils’ tests? I’m still trying to establish a substitute server, and coreutils’ tests failed, some of which are listed as “XFAIL”, and one that is listed as “FAIL”. <gnucode>unmatched-paren yeah. sway is like super stable. I have had almost 0 issues. <gnucode>best linux window manager I've ever had. much more stable than gnome. <gnucode>hmmm. that's interesting to think of it that way. <unmatched-paren>so you have ``compositor <-> windows'' instead of ``compositor <-> window manager <-> x server <-> windows'' ***the_tubular92 is now known as the_tubular
<gnucode>unmatched-paren: that's honestly why i want to use wayland... <unmatched-paren>i've used libwayland-client, and looked at libxcb, and i much prefer the former <gnucode>also, is it even possible to use your config "system.scm" via guix system vm system.scm ? <gnucode>eg: does qemu let you run an OS with a wayland environment? <gnucode>hmmm...I tried with a really basic sway.scm and I couldn't get it to work... <gnucode>i bet that simple sway config is in some bug report somewhere. <gnucode>unmatched-paren do you suppose guix will have a "firefox" package? Or are we stuck with icecat? <gnucode>ahhh. it might be hard to "package" those things out... <lilyp>omg, webkitgtk-next builds with gtk4? <zamfofex>Well, I think I found the first broken package (!!!) that I might be able to fix! Now I just need to figure out a way to try to fix it without having to go through bootstrapping once again. <zamfofex>Since I did try to build it on a substitute server, I might be able to leverage that, thankfully! ***califax_ is now known as califax
<jpoiret>unmatched-paren: you could never package firefox as "firefox" since it's a trademark reserved for mozilla-distributed binaries <jpoiret>there's librewolf that could be leveraged, it seems to have more development effort behind it <apteryx>seems emacs has this new behavior of popping up an elisp warnings buffer in your face <jpoiret>Although I wouldn't really know since I've been using 28 long before release <morganw>If you are using native compilation with I think you'll see a lot of warnings as the compilation happens <trevdev>If I inherit some other package, is there a way to extend that package's modified build phases without having to copy-paste them and hope for the best later on? <zamfofex>I think I figured out the issue! See: <https://logs.guix.gnu.org/hurd/2022-09-13.log#224914> Now, there are various ways to resolve it, I feel, and I’m not sure which is the most appropriate one. (1) Patch ‘glibc’ in Guix (or use a snippet). (2) Patch (or snippet) ‘coreutils’ in Guix. (3) Change Guix to include ‘/var/run/mtab’. (4) Send a patch to ‘glibc’. And (5) Send a patch to ‘coreutils’. <trevdev>To elaborate, I have defined and built emacs-lsp-mode-with-plists which also needs to augment the build phases. I don't want to override the inherited augmentations, so I have copy-pasted them. This means if someone comes along to add some other augmentation for `emacs-lsp-mode` I will miss out on it if I do not catch it. <zamfofex>Now, which of these do you think would make the most sense? 🤔 <jpoiret>trevdev: you'll want to use substitute-keyword-arguments and modify-phases <jpoiret>there are a couple examples in the codebase <trevdev>Thanks guys, I am already using `modify-phases`. I am also copy-pasting all of the inherited modified phases under the assumption that if I don't, they will be overwritten. Was that a bad assumption? <zamfofex>It depends. You need to use ‘substitute-keyword-arguments’ like jpoiret instructed, alongside ‘package-arguments’ with the package you are inheriting. <trevdev>Alright, I'll go for a ripgrep. Appreciate the help <trevdev>emacs-treemacs-extra seems to have the example I am looking for. Nice!