IRC channel logs
2024-12-22.log
back to list of logs
<Googulator>Any news on the GCC 4.9 build failure? I've just restarted work on bridging the gap between GHC 7.0 and 7.10, but unfortunately the chain up to 7.0 is rooted in GCC 4.9... <Googulator>For now, I'm working in a time machine from a commit where GCC 4.9 works, but obviously that's no good if I want to contribute back. <homo>at least it's easy to build hugs without gcc 4.9 #74784 <homo>another guess gcc 4.9 is mandatory for ghc because of pre-generated C files <homo>I attached log to #74783 , but it doesn't tell much <homo>but if gcc 4.9 is broken, how later versions of gcc are boostrapped then? <homo>s/boostrapped/bootstrapped/ <redacted>If I guix pull and a package fails to build, am I just unable to update my system until it's building successfully? <Googulator>homo: wouldn't be the first time there are substitutes for a package that then cannot be built... case in point: Yale Haskell <Googulator>the version that's pulled as a substitute is completely broken (weird runtime errors), but it *exists* <Googulator>`guix shell -D cl-yale-haskell; guix shell --no-substitutes cl-yale-haskell` fails <Googulator>and so do any other attempts to build rekado's fork of Yale Haskell for clisp, on Guix or anything else <Googulator>So how did the Guix substitute binaries come to be?! <bdju>did gajim fail a database migration for anyone else? I guess I'm just screwed now... awful. <bdju>it crashed on me (as it often does) and when I started it up again, I guess it had updated, so it forces me into a db migration that takes several minutes when I was in a hurry to message someone, then the db migration fails and it closes. <bdju>hm could it be related to skipping wfetch on upgrade after it failed? both that and gajim use python <amano>How does people develop haskell programs on guix? There is no haskell-language-server package. <bdju>I've uninstalled wfetch and re-done my upgrades and tried `guix install gajim` just in case, but not noticing a change. the db migration keeps failing. https://0x0.st/8rHN.txt here is the traceback. is there anything I can do? just earlier today gajim was working fine... <david95>Hi all. Please tell me how to correctly download programs? I wanted to download Gajim (18.5MB in the repository) and through GUIX I already disappeared 3GB)) and after the GUIX manual installation minus 2GB. I understand correctly that in order to download the Gajim program (18.5MB I need 5-7GB of free space? What are the correct figures for downloading programs and GUIX? Share your experience. <Rutherther>david95: guix can definitely take more space than other package managers, due to its nature where you get another built package when its version changes / dependencies change and the old one is not deleted. But this is likely something else, you seem to be checking size in repository of gajim only, without its dependencies, whereas with guix you are seeing dependencies as well. Guix is completely standalone, it needs all dependencies. <rekado>I've tried to "guix deploy" to my aarch64 system. Unfortunately, I get "remote command [...] failed with status 0" <Rutherther>I think that was already discussed here that it was because of guile ssh update that changed something. Someone provided a patch as well <rekado>I can run the listed command just fine, and status 0 sounds like it indicated success. <Rutherther>maybe I am misremembering, but there were certainly problems after guile ssh update, just not sure if it was this status 0 thing or something different <efraim>rekado: I generated my image and wrote it to an SD card, haven't used guix deploy without building rust for a while <efraim>I know guix-icons pulls in rust, I'm not sure what else <rekado>Rutherther: thanks for the pointers. I'm trying out different older commits (currently 8eb7176fefc8676f40cdd627d6da39675ad1d24b) because the more recent commits seem to have triggered world rebuilds on aarch64. <rekado>(I'm made to build bootstrap packages, glibc, etc) <rekado>efraim: I found using the SD card on the rockpro64 so incredibly fiddly that I have not touched it ever since I patched uboot to ignore some CPU resets to enable booting over SATA. <rekado>the moment it worked I was just happy to leave it right where it was <rekado>"guix deploy" has served me well since then <rekado>what's up with issues.guix.gnu.org? If nobody beats me to it I'll hop on ci.guix.gnu.org in a few mins and give it a kick. <Rutherther>rekado: ah, so maybe if you have guile ssh 0.18 there, you could either revert that or apply the commit in question <cow_2001>guix pull takes a century for some strange reason now <efraim>unmush: I'm still not able to build 5.10.0. I even tried applying that patch to my guix tree with --keep-cr <unmush>hmm, perhaps you also need to set core.autocrlf to false? <unmush>do you see any of the ^Ms in the patch itself? <unmush>although I would hope that --keep-cr would override core.autocrlf by itself <efraim>I don't see anything that looks like ^M <cbaines>Simon has pushed, but his key isn't in the keyring <unmush>efraim: not even near the patch for AssemblyInfo.cs? <unmush>I just downloaded the patch myself and I can see the CRs in emacs <efraim>I don't see it in less or in vim after saving the file from mutt <efraim>interesting, I see it now after downloading it from issues.guix.gnu.org <efraim>and the sha256sum of the patch is different <unmush>I've got 6dc24a1b9de1c3f17808a163aaf862b163e3ed44fe42fc98a128c6b001b24dd3 here <efraim>ba779dd6507d7cc109f065bcf23df5c47e2ed143f45f0654729e37ef3ebe78fb from mutt and ad40aec952128ad6df3321b2ee0d4c61f025d7468d42ad49c42f4839232af7fe from the web <efraim>for v2-0019-gnu-Add-mono-5.10.0.patch <unmush>email: the true enemy of reproducible builds <efraim>ok, this time I got a warning about CRLF line endings and was able to build the source for 5.10.0 <Deltafire>has anyone tried packaging jellyfin for guix? <amano>How do I manage symlinks in ~/.config through guix home? <rekado>amano: one way is via home-dotfiles-service-type <efraim>I use home-xdg-configuration-files-service-type for putting files in ~/.config <amano>How do people develop haskell programs on guix? <amano>There is no haskell-language-server package. <homo>amano I have never ever used haskell-language-server, and I write haskell programs using acme from plan9 <amano>homo: haskell-language-server is the better way. <df>is this sort of thing to be expected occasionally, or is something broken? <Rutherther>it is unfortunate, but expected, as mpv does indeed propagate ffmpeg of older version and you seem to have requested to install ffmpeg. Just don't do that, install mpv only, which will give you ffmpeg as well (although older version) <df>in that case ffmpeg is not actually part of my profile though is it? <df>for example it wouldn't appear if I exported a manifest? <Rutherther>it is part of your profile, though you are correct that it won't be in the manifest <df>so... there is possibly a better way to do this anyway, but I have been using guix package -I <name> to find the location and thus contents of a package <df>that doesn't work if the package isn't in the profile <df>er, or if it isn't explicitly installed <Rutherther>you can use guix build for that, though it will give you all outputs, unlike what guix install does <df>will have a look, thanks <jakef>df: no idea if this will work, but you could try guix install mpv --with-graft=ffmpeg=ffmpeg <Rutherther>jakef: that seems like a recipe for something not working, grafting with completely different version of a package, where the version was kept lower because it would be harder to update <df>I have explicitly installed ffmpeg@6.1.1 for now, so it appears in guix package -I at least <df>I assume that might cause issues down the line when mpv upgrades but that should be easy enough to fix <homo>does it happen on every machine that suspend results in black screen and unresponsive system? <Rutherther>homo: no, only the ones where something is missing/broken, like driver or firmware. It's usually common that other people with same hw will experience same issue <homo>"/dev/mapper/cryptroot: recovering journal" I've seen this so many times, yet didn't notice any damaged file <Guest31>I ran `make check` in `guix shell -D guix --pure` after cloning and pulling the git repository and got some test failures. Should I bother with a bug report? If yes, is there an easy way to see the versions of all dependencies? Anything else I should include? <jakef>can't guix pull at the moment (696d949) <efraim>jakef: sorry, thanks for fixing that <efraim>I don't remember Zheng's IRC handle <bost>Hi. The 2e6adef5a6 'gnu: xfce4-power-manager: Update to 4.20.0.' introduced a bug causing `guix system build` to fail. I wrote a fix, I'd would be great takes a look at it so that `guix system reconfigure` works again. See https://issues.guix.gnu.org/75025 <bost>IMO it's a high priority problem <bost>* It's would be great if someone takes ... (Sorry) <bost>ACTION Oh bloody hell, I can't write a proper English sentence today. :-/ <Rutherther>bost: I suppose the system build/reconfigure should fail only for those using xfce4, no? <bost>Rutherther: yeah. I suppose that as well. <Rutherther>alright then, from your message I understood it's completely broken for everyone <bost>Ah, sorry for misunderstanding. Well then it's not a high prio, just higher prio bug, I'd say. <df>hmm, so it looks like it tries to upgrade ffmpeg to the latest with every guix package -u (I thought maybe it'd pin it at the version I'd asked for) <df>not really a problem, and I guess it means matters will just resolve themselves if/when mpv is updated to use a newer ffmpeg <Rutherther>rekado: is there a time plan for updating to python 3.12? <csantosb>Just realised that we don't have #:test-command in copy-build-system ! <df>what is the best way to tell emacs that I consider all the variables under the guix/ tree safe? as I understand it, all the means to mark a variable as safe are not dependent on the source file location <lilyp>df: you can't – you have to approve of the form itself <df>hmm, ok... but I potentially might not trust the same setting in a different source tree <rekado>Rutherther: Sharlatan Hellseher supposedly has a plan for 3.12. I don't know anything more about it, though. <rovanion>In order to get Musescore 4.4.x working I had to change build system for HarfBuzz from make to meson - it produced unprocessed CMake files with make. Now I seemingly have to rebuild the world before I get to build MuseScore. I've seen the word graft float around, is it perhaps useful here? <Rutherther>rovanion: why do you need to modify harfbuzz, can't you just make a new package that will be like harfbuzz, but with different build system, and make that an input of musescore? <rovanion>Rutherther: It was just the natural thing to do, to fix it for all. Didn't think of the alternative. <Rutherther>also grafts are only runtime, if the problem is upon build, it won't help you at all. If it's during runtime, still, it's always possible something else will break with grafts, they are mainly meant for security fixes that change as little as possible, like only some implementations of methods <df>when browsing the guix source code, if I attempt to navigate to a built-in like define-syntax-rule, I'm taken to the guile binary. is there a way to get to the source instead? should I just clone it manually and add it to geiser-guile-load-path or is there a more guix-y way to make it available? <rovanion>Going the new-package-route, thanks for the tip. <civodul>df: things like ‘define-syntax-rule’ are defined in Guile proper in boot-9.scm and you cannot jump to its definition <civodul>kinda annoying, but that’s the way it is <civodul>(fortunately, there are relatively few of these) <civodul>cbaines: hey, it looks like dover is down; do you have any insight? <PotentialUser-13>Is pulseaudio part of %desktop-services? I do not see it when I run "herd status" (nor do I see ALSA, either). <Rutherther>PotentialUser-13: it is. But pulseaudio doesn't have shepherd service, it doesn't need one. It's started by a client automatically, when it isn't running <df>civodul: thanks. is that just boot-9.scm or any of the scheme code defined by guile itself? <df>ah nm, answered my own question, looks like I can jump to things like format <civodul>df: yeah, it’s just boot-9 and procedures implemented in C, like ‘open-file’ <bdju>how can I check my gtk version on guix system? <bdju>need it for a gajim issue report <bdju>if I try to dry-run install gtk+ it says it'd be 3.24.41 so gonna go with that I guess <Rutherther>bdju: if you want to know the version used with gajim, use guix graph command on the package <bdju>is there an example for this use-case somewhere? I don't wanna learn a whole new command just for this if possible... <bdju>also I thought I was on gajim 1.9.3 but when I list generations I see 1.7.3 written out a bunch. guix search shows 1.9.3. why would my generations not list me upgrading to 1.9.3 anywhere? <homo>I wonder why pulseaudio and alsa are part of %desktop-services if pulseaudio daemon and sound work by-default without them <Rutherther>homo: they do work because pulseaudio is part of the sw. They are in the services probably because you can pass configuration through them <Rutherther>bdju: maybe you didn't upgrade, or are using gajim from different profile, I don't know <bdju>I don't do much non-default stuff, and I've tried to fully upgrade again or reinstall gajim again already and IIRC it said "no change" the last time I tried <bdju>and I can't check the version inside gajim itself like I usually would due to it being broken <Rutherther>look at real path of the binary you are executing, that will tell you version of the guix package <bdju>gajim: /gnu/store/s6bqjkc0jwb8aapb13x0n09b8hnha89b-profile/bin/gajim <bdju>this is the result of whereis but I don't see a version number <rekado>to follow the symlink to its final destination <bdju>still not sure what's up with the generation thing but I guess it doesn't matter <Rutherther>also, what is that output of you sent with the path to /gnu/store? <bdju>which gives a more generic-looking output without a hash in it so I figured that one was a symlink but didn't realize the other one was too <bdju>and readlink gives the same result whether used on the output of which or whereis <Rutherther>alright then, yeah, that one follows one symlink down, not sure why it does that rather than printing the first symlink or following all the way <RavenJoad>I am building a package where I want to provide a command-line argument by default (think always providing -h when I invoke ls). wrap-program cannot do that, because that only does environment variables. Is there another function that I should use? <Googulator>GHC 7.4.2 stage1 built by our GHC 7.2.2 segfaults building Float.lhs; 7.4.2 stage1 built by official 7.2.2 binaries doesn't. Currently experimenting with 7.0.4 official binaries -> 7.2.2 -> 7.4.2 to see if this is related to the environment Guix builds GHC in, or instead something passed on from binary to binary ("compiler tradition" á la Thomson) <Googulator>efraim: there are some significant changes to 7.0.4, to properly get rid of the vendored libffi <Googulator>(time machine used because of the gcc-4.9 failure; the commit chosen is the one I started Guix-on-live-bootstrap from, as it's known not to have the gcc-4.9 issue) <stochastic>can we downgrade the repos like with `--allow-downgrades` when using `guix deploy` ? <civodul>stochastic: yes, there’s a field in ‘machine-ssh-configuration’ IIRC <Googulator>As a weird side note, GHC 7.0.4 is not self-hosting 🤯 <Googulator>Can be built with 6.10.x and 6.12.x, but nothing newer than that <Googulator>Luckily 7.2.2 has no such problem - it happily rebuilds itself (but it doesn't fix the segfault when building 7.4.2) <homo>wow, ghc is just so random <homo>also considering that every release there is API breakage in libraries, I wonder if it is also the reason why bootstrap chain is so long <Googulator>GHC used to have an "N-2" policy for bootstrapping until recently <Googulator>IIRC it's now "most recent LTS available at time of release" <Googulator>7.6 was an exception, because it could bootstrap from 7.0 (in theory, at least...) <homo>I remember go adapting this N-2 policy, which is very sad for language that markets itself as simple, not bloated with feature creep <Googulator>7.0 and 7.2 both need a trivial patch before they will accept 7.6's source code - only to then die on Float.lhs <singpolyma>Well go has always had extra language extensions in the compiler versus what they allow for users <Googulator>singpolyma: that's pretty terrible policy, implementing the compiler for a language effectively in a superset of that language <homo>at least there are 2 bootstrap paths for go, either use go 1.4 or use gccgo <Googulator>ideally, it should be the other way around (extra features supported by the compiler not used in the compiler's source, for easier bootstrapping), but even Rust's policy is better than that <singpolyma>The idea I think is that they trust the compiler authors (themselves) more than they trust the users <homo>but there is no bootstrap path for ghc, nhc and microhs <homo>7.0.4, 7.2.2 and 7.4.2 rebuild themselves so many times it's horrible <Googulator>7.2.2 built with 7.0.4 official binaries and then rebuilt with itself generates the same broken 7.4.2 stage1 compiler as 7.2.2 rooted in 4.08's .hc files <Googulator>That's partly good news, as it means this is not an example of potentially malicious compiler tradition