IRC channel logs
2024-06-19.log
back to list of logs
<trannus_aran>hey, does anyone know how to enable the nscd on RPM based distros? <lfam>I guess that's the pyproject-build-system <lfam>Updating Python packages is always a huge can of worms <podiki>yeah, pyproject-build-system should be used as the default now too (i think the importer will) <podiki>there are some pending bigger updates on python branch, unless those were merged while I was away <lfam>I was "only" trying to update yt-dlp <lfam>It requires urllib3 1.26.17... but we have 1.26.15. Of course, >4000 packages depend on this <podiki>take a look at python-team first, if it wasn't merged <lfam>Well, it's worse than Rust because I actually understand how to do Python packaging, so I am stuck trying ;) <lfam>Okay, thanks for the tip <podiki>hahah good point (likewise for me, although "understand" more loosely for python) <lfam>I see an urllib3 update at the tip of the python-team branch <lfam>I mean, I've been doing Python packaging in Guix for so long... I can fight my way through. Rust is a total mystery <podiki>i just know when i've tried any "simple" rust update/import it ends up being so so many packages <lfam>Yeah, I actually worked on of the first significant Rust package in Guix (rav1e). Holy cow <lfam>The Rust people just have a totally different idea of how software should be assembled. Guix is instead an evolution of the old way, not a total revolution <lfam>I'm glad it exists and that people are using it. But I certainly don't know how to package it <lfam>Rav1e was so complex we actually just added it in a single 5641 line commit <podiki>unfortunately from what i've learned in my guix time is that every language/ecosystem wants to do it their own odd way (and not one set standard usually) which is at odds with guix's approach and needs <lfam>And I am usually a stickler for sticking to the project conventions about Git! <podiki>i do have some hundreds(?) of haskell packages i never tried to commit <podiki>mostly generated packages for bindings to glib/gtk stuff <lfam>It's true that all the languages go their own way, but Rust is the only one where we had to disregard the Guix 'package' abstraction <lfam>It's just on another level of combinatorial complexity <lfam>Yeah, I think we all have some dusty old Git branches in our laptops ;) <freakingpenguin>lfam: Do you know how Rust compares to Go for packaging complexity? Every time I dip my toes there I run away screaming. <lfam>freakingpenguin: Go is a bit special but not as hard as Rust <lfam>It can certainly be tedious <lfam>I would use the recursive Go importer, unless it's broken <freakingpenguin>At some point I tried using it and it was trying to retrieve tags that didn't exist, I think because the repo changed their naming scheme partway through. <freakingpenguin>I feel like pairing package managers/build systems and languages was a mistake. Sure they're convenient, but it seems to silo ecosystems. <lfam>I haven't seen that one before <lfam>Hard to work around, I suppose <lfam>I do think it's likely that our Go build system (in Guix) could be overhauled. It was designed for an earlier iteration of Go's internal build processes, and I know they are doing something else these days <freakingpenguin>It certainly required more effort than I was willing to put in at the time. I like hacking at the internals, packaging is only fun until I have to deal with dependencies. <lfam>Maybe it counts as "hacking at the internals" ;) <lfam>There is a lot of great free software written in Go. That was my motivation for landing the old go-build-system, even though I don't write Go or care about it in particular <lfam>But I agree that it's really a bear <freakingpenguin>lfam: Fair point! I like how many subsystems there are in Guix to learn. <lfam>The funny thing is that Google has their own build system that is basically the same model as Guix, a memoized cache of build artifacts <lfam>If only they had chosen Guix, then we'd have some Go experts to help us <freakingpenguin>Bazel was designed around monorepos, right? I've never used it myself but conceptually it seems similar. <lfam>That I'm not sure about it. But it is a functional paradigm with memoization <lfam>IIRC, Google does use a monorepo. Must be huge! <freakingpenguin>I wish providing a vendor dir in go project tarballs didn't go out of fashion. It was a nice stopgap solution. <freakingpenguin>I shudder to imagine the complexities that go into software design at the scale Google operates. <lfam>Yeah. It makes sense to me to do a monorepo <jmes>Is there a way to only install something if it has a substitute available? This would be useful when I need a one-off usage of a big browser <freakingpenguin>jmes: A workaround could be "$ guix weather foo && guix install foo". It looks like guix weather returns nonzero if the substitute isn't available. <freakingpenguin>Although it also seems like it returns nonzero if /any/ substitute server doesn't have the substitute, which feels wrong. <jakef>i think so too, thanks for submitting the bug freakingpenguin <ngz>There have been many "cannot build missing derivation…" build failures on CI lately. <ngz>It requires restarting build manually, which is not optimal. <dariqq>is there a better way to build rust+meson projects other than the abomination that is using cargo-build-system to set up the vendor dir and then importing all meson phases? <jmes>freakingpenguin: Ah nice, that does the trick (the guix weather trick from before) <dariqq>efraim: :/. Could that part maybe be seperated out of cargo-build-system to make it easier to integrate with others (i have no idea how that would work) or do i have to accept that cargo is just fundamentally broken? <efraim>there's a couple bits with the cargo-build-system relating to pulling in necessary dependency sources that haven't been separated out. Fixing the hash of the vendor-dir has been pulled out, but in general with other packages which mix rust with other code I've found it easier to start with the cargo-build-system and then add in others <efraim>IMO the real problem with the rust ecosystem is the cyclical dependencies. We work around that in other systems with -bootstrap packages, but we'd need too many for rust for it to be feasible <dariqq>a fun thing i found out recently that even if there are release tarballs with vendored crates it is not easy to use them (even after patching the checksums) because with meson the buildir is not a subdir of the source so the .cargo config in the source is never found (the meson script usually resets CARGO_HOME to the builddir) <efraim>I'm not such a fan of it. If there are changes or updates needed to any of the dependant packages then we'd need to apply them for each of the individual apps packaged. To me it seems one step away from accepting bundled the dependencies <efraim>that said, it isn't actually bundling dependencies, but we do lose the ability to make changes to one package and then re-use it across others <efraim>I've been toying with the idea of "this crate is packaged because it needs adjustments, everything else can use a definition created by guix import directly" <ngz>Setting skip-build back to #t, i.e., using most crates package as source only, would be a step in the right direction. You can make changes to one package and all dependents will benefit from it. <jakef>futurile: can we look forward to david thompson's talk appearing on the guix.social youtube channel? <Googulator>if I interpret this correctly, we're 1 step away from connecting 7.10.x to the (quasi-)bootstrap <Googulator>7.0.4 can build 7.6.x in theory, which is then sufficient for 7.10 <efraim>IIRC 7.4 or 7.6 should be able to bridge the gap and build 7.10, and then we'd be fairly well set on i686-linux. I had to take a break from working on it for a while, it was driving me crazy and eating into my paid time <Googulator>I wonder if 7.6 or 7.10 can cross-compile itself from i686 to x86_64 <efraim>I didn't look into how the cross-architecture bit works, only that I know it's supposed to be supported and is the eventual plan for x86_64 haskell <Googulator>semi-bootstrapping from 4.08's hc sources would be a great step forward compared to the current system of downloading a full binary version <futurile>jakef: yes, it'll be a couple of days as I need to edit it all up - and I'm still learning how to do it properly honestly <efraim>I remember being really deep in the weeds on that for like a month straight, almost got it working on my powerpc laptop also <Googulator>I've been looking into a full bootstrap path as well - since the last time rekado tried, we rediscovered the previously lost source code for ghc 0.26 & 2.10, Yale Haskell Y2.2, and several older versions of nhc, that could be useful for bootstrapping <Googulator>plus a full development repo of ghc from 0.26 to the present day (unfortunately skipping over the 0.29 branch, going from 0.27-pl1 to the 2.x development instead) <Googulator>I'm hoping we can do clisp (already bootstrapped) -> Yale Haskell Y2.2 (we have a broken version of Y2.05 right now; Y2.2 contains a port to an older version of clisp, but unfortunately doesn't work OOB with modern clisp) -> ghc 0.29 -> ghc 2.10 -> ghc 4.08.2 <Googulator>possibly even skipping 0.29, since Y2.2 seems to support the same Haskell-1.2-with-draft-1.3-monadic-IO as 0.29 <Googulator>alternatively, instead of clisp, we could try to use Guile, since Yale Haskell is actually written in an early version of Scheme, with a Scheme -> Common Lisp translation layer tacked on <apteryx>hm, even with setting source dir with 'dir' in gdb, it won't find the sources of linphone-desktop <apteryx>the binary source info expects them at /tmp/guix-build-linphone-desktop-5.2.4.drv-0/ <graywolf>Hi Guix :) I am trying to configure nginx on my server, and it seems the extra-content field is added *after* server-blocks content. Is there a way to do custom code *before* the servers blocks? <mange>Hmm. It doesn't look easy. You might be able to do it with some creative configuration values (most things aren't escaped, so a well placed line break can let you inject arbitrary config lines), but it doesn't look supported at the moment. <graywolf>I wonder whether there even is a reason to have it at the end... <graywolf>I will sent a patch moving it and see whether it will be accepted <graywolf>I am pretty sure I do not want to go via the misusing the "not escaping anything" property of the code :) <efraim>I had to add extra stuff to a field or two for my home-openssh-config <freakingpenguin>graywolf: FYI there's another patch related to nginx's extra content to try and make it a bit prettier and also support accepting a list of strings. #71586 <redacted>Is there a way to get guix to make its chroot outside tmp? I'm trying to build an ISO with guix system image, but I get an error about running out of space <ray1729>redacted: have you tried setting TMPDIR? <redacted>Yes. TMPDIR is ignored by the daemon when placing the chroot I think. I'll find where it says that in the docs <freakingpenguin>redacted: I think you need to set TMPDIR before invoking the build daemon <freakingpenguin>On Guix System you can do that by setting the tmpdir option in guix-service-type. I imagine for a foreign distro it depends on your init system. <redacted>Looks like the archwiki shows you how to do this and it's easy <graywolf>I wonder whether the simple-format prevents usage of file-like objects or whether it will still work... <freakingpenguin>The repl commands mentioned in "(guix) Using Guix Interactively" in $ guix repl seem to not work, anyone else notice that? <freakingpenguin>graywolf: It should work, they'd get lowered the same way the nginx package does in the include line. <graywolf>freakingpenguin: Could you give an example (of commands not working)? Semms fine here. <trying2instguix>`guix system: error moving build output `/gnu/store/[...]-bash-5.1.16-doc' from the chroot to the store: Invalid cross-device link' <ieure>Any thoughts what'd make an offloaded build spin forever with "process 23595 acquired build slot '/var/guix/offload/build-box-host:22/0'" and "normalized load on machine 'build-box-host' is 1.00" ? <ieure>Also says "waiting for locks or build slots..." <ieure>Nothing else is building though? <graywolf>ieure: What does `cat /proc/loadavg' print on the machine (the offload server)? <ieure>graywolf, "8.78 8.82 8.81 2/447 5055" <graywolf>Well something is running there (might not be a guix build ofc). Default overload-threshold is 0.8, you can turn it of with #f (that is what I do) <ieure>Actual CPU utilization is maybe 40% <graywolf>Yeah, I should read up on how load is calculated <graywolf>My guess would be guix uses the load value, not cpu usage <ieure>Cuirass is what's chewing CPU, but it's not obviously doing anything. <ieure>Actually I don't know what's going on, htop shows no processes using significant CPU, but the CPU utilization shows ~40% ute on all six cores. <ieure>Oh... my external HDD looks like it's failing and that's horking up all kinds of stuff. sigh <ieure>trying2instguix, You're trying to hard link a file from one device onto another device, no filesystem supports that. <trying2instguix>`guix system: error moving build output `/gnu/store/[...]-bash-5.1.16-doc' from the chroot to the store: Invalid cross-device link' <jdlugosz963>I'm writing a service that extends the functionality of the radicale-service, and I have a problem with this service-extension: (service-extension radicale-service-type radicale!-radicale-service). In the end, it doesn't use the configuration returned by radicale!-radicale-service, but the default one of radicale-service-type. <trying2instguix>the only thing i think i might be doing out of the ordinary is using nilfs2 for root <trying2instguix>i wanted to upload my config.scm but i cant figure out how to get wget to upload a file to litterbox <trying2instguix>`guix install: error moving build output `/gnu/store/[...]-curl-8.5.0-doc' from the chroot to the store: Invalid cross-device link' <ieure>trying2instguix, Are you running that from a chroot into your installation or something? <ieure>trying2instguix, Same error from `guix shell curl'? <ieure>trying2instguix, Sounds like something in the install env is horked, you should be able to do that. <trying2instguix>i guess ill try restarting... for the 10th time... and try things step by step from there <ieure>trying2instguix, My advice is to try a more typical install. Guix is ludicrously difficult to install at all, doing an atypical setup makes it even harder. <ieure>I've installed Guix maybe a half dozen times, it's still like pulling teeth. <trying2instguix>oh yeah, and i HAVE to use the shell because the wizard is a black screen <ieure>trying2instguix, What installer are you using? <Googulator>it *always* unconditionally wants to build its unit tests, which in turn depend on google-highway's unit testing code <Googulator>which I was forced to disable, due to broken CPU feature testing <ieure>trying2instguix, Yeah, are you using one of the official install images, one you made yourself, something else? <ieure>The "graphical" installer is text-based and will work on any pty, it doesn't need a framebuffer. <ieure>I don't understand that question. <trying2instguix>i mean, tty1 is blank, right, because it runs using a framebuffer, and it didnt work on my machine <ieure>You're confused, the Linux console doesn't work like that. <ieure>Everything is fbcon or text, you don't have one fbcon and one text. <ieure>It sounds like the installer is broken in the nightly image. <ieure>Maybe try the 1.4.0 "release" install image? <trying2instguix>i think i had a problem with that one, im trying to remember what it was <ieure>Also "shell" is the name of ex. bash, sh, zsh, fish. They all run on fbcon, text tty, graphical terminal emulator etc. <ieure>I'm not sure how to start the installer program from a second virtual console. <trying2instguix>okay so i checked dmesg and it showed `probe of uvesafb.0 failed with error -22' <ieure>Might be a shepherd service? Honestly no idea. <ieure>trying2instguix, If you think your problems are fbcon-related, maybe edit the Linux kernel arguments in the installers' GRUB to disable that. <ieure>I'm not sure that's the case, but might be worth a try. <ieure>trying2instguix, The installer boots to GRUB, you can boot differently from there. <ieure>Hmm, that's definitely not how the installers I've used have behaved. But I haven't used a nightly. <trying2instguix>maybe i need to press esc at just the right time. oddly, i think i did that accidentally in one of the boots. the problem is i think grub isnt showing anything <instguix>i should mention that i am using libreboot so the vesa graphical mode or whatever wont work <instguix>did you say anything in the past 10 minutes that i missed <instguix>is it just that nilfs does not work at all <instguix>i am at one hair from using debian instead <dariqq>Googulator: i think youll need to escape the parentheses (and maybe more) in the match string and you dont need the parentheses around the replacement string <Googulator>yeah, ended up doing "include.jxl_tests.cmake." which should match that line <Guest73>by chance, does anybody know what might be wrong with guix bootstrapping on my funny system: <ieure>instguix, I still run Debian, it's a fine distro. <instguix>i just wanted to have more freedom with picking software alternatives <ieure>instguix, You can use Guix as a package manager on top of Debian. <instguix>since upstream distros keep getting more and more sour every year <ieure>instguix, Guix is honestly not very good at shipping updated packages in a reasonable timeframe. Debian 12 has newer Python than guix doesn. <Guest73>its not hard to just create a new package anyways <instguix>yes but it failing with the most basic packages like python is an impediment <Guest73>(package (inherit stuff)) seems to work well <instguix>also if its complex to build, it bears a lot of weight on the user <Guest73>does anyone here do anything with stage0? <Guest73>I think m2 planet is supposed to work anywhere, still, in guix itself it seems to fail <Guest73>I think we're missing some knowledge from jedi-masters here <instguix>in other words the few people who created critical mass amounts of incomprehensible ad hoc spaghetti <Guest73>well so far I was ok with it. but now I want to bootstrap it on a non-chrooted guix-daemon and then it fails <Guest73>I feel more like walking on the knife's edge and you don't know whan you'll lose your balance <Googulator>Guest73: is your kernel built with 32-bit userspace support? <ChrisLeague>Good #$time-of-day ! I'm suddenly having trouble with `local-file` canonicalizing relative paths. All is okay when I use `guix build -f path/to/file.scm` or `guix build -L . local-pkg-name`. But I wanted to create a channel and put my scheme modules in a subdir, and now I'm getting: "error: canonicalize-path: No such file or directory..." when I <ChrisLeague>do `guix build -L src local-pkg-name`. Is there a gotcha where "relative to source file" is interpreted strangely when said source file is found on load-path ≠ CWD ? <Guest73>I am running under proot on a redhat server. if it matters I can check <Googulator>this has the same stage0-based bootstrap as Guix, but is somewhat easier to debug, since the intermediate binaries aren't in some obscure temporary directory that probably gets deleted immediately <Googulator>(incidentally, I'm currently performing a bootstrap of a Guix System install on top of a live-bootstrap system) <Guest73>what could cause the bootstrap to fail like this: M2-Planet-1.9.0/test/test1000/proof.answer <Guest73> +> ../bootstrap-seeds/POSIX/x86/kaem-optional-seed mescc-tools-seed-kaem.kaem <Guest73> +> ../bootstrap-seeds/POSIX/x86/hex0-seed hex0_x86.hex0 hex0 <Guest73> +> ./kaem-0 mescc-tools-mini-kaem.kaem <freakingpenguin>Darn, scons build system doesn't support cross compilation. Having never used it myself I wonder if that's an unavoidable limitation. <taeaad>Why did Guix and Nix OS turn out to be separate projects? <eikcaz>ChrisLeague: iirc it should check relative to the file the ,(local-file ...) resolves <simendsjo>Any StumpWM users here who has updated to the "lisp-team" merge yesterday? My system broke with "Failed AVER: (= (ASH .. snip .. This is probably a bug in SBCL itself". Is it unique to my setup or something others experience too? <simendsjo>That's good I guess :) Are you using any of the following packages? sbcl stumpwm+slynk `(,stumpwm "lib") sbcl-stumpwm-ttf-fonts sbcl-stumpwm-pass sbcl-stumpwm-globalwindows sbcl-stumpwm-swm-gaps sbcl-stumpwm-net sbcl-stumpwm-wifi sbcl-stumpwm-stumptray sbcl-stumpwm-kbd-layouts sbcl-stumpwm-numpad-layouts sbcl-stumpwm-cpu sbcl-stumpwm-disk sbcl-stumpwm-mem sbcl-stumpwm-winner-mode sbcl-stumpwm-screenshot <freakingpenguin>Yes to ttf-fonts and pass, no to the rest unless they're pulled in as dependencies. <simendsjo>Ok, thanks. I'll see if I can reduce it. It happens already when I require some packages it seems. <ngz>When building Lyx, I get "fatal error: nod.hpp: No such file or directory". Where could this file is supposed to come from? <apteryx>header only; must be trivial to package <the_tubular>What is the point of guix installing emacs packages that comes with emacs by default ? <ngz>the_tubular: To get more recent versions? <the_tubular>Not too familiar with emacs, is there a big version difference usually ? <ngz>the_tubular: It depends on the package, an one the version. Also, a new version may not be necessarily big, but could fix the very problem you're experiencing with the current one. <the_tubular>I mean that emacs-next is generally not too old right ? <noe>What if you're using an old version of emacs ? <df0>the_tubular: i don't see any dependencies on other emacs packages for the main emacs package <ngz>I don't follow Emacs development, but usually, external packages are included late in the release process. <ngz>IOW, I don't think emacs-next refreshes regularly its built-in packages. <ngz>(but I could be wrong) <the_tubular>df0 what do you mean ? emacs-next comes with tons of emacs stuff no ? <df0>the_tubular: only what's included with emacs? I don't see any other dependencies <df0>could be 300mb expanded <freakingpenguin>Some packages rely on the guix-packaged versions due to known bugs with the built-in versions at the time. Apparently emacs-es-mode was packaged in Guix while emacs-24.5 was out and had a bug, so it pulled the newer guix-packaged org in. <df0>maybe i misread your question, i thought you were saying that guix was installing emacs packages separately, that were already included in the standard emacs package <the_tubular>No df0, I was asking why should I pull those package, when emacs already comes with it <the_tubular>This was pushed yesterday, and version bumped 12 March