<nisha>lfam `guix describe` and `guix --version` work <lfam>This will help us understand exactly which code you are running <nisha>lfam not familiar with debian's pastebin, but I did send it :) <lfam>I'm not sure I see it yet... where did you send it? :) <lfam>Okay, and zooming out... I'm not coming up with ideas about what could be wrong, that would cause you to be logged out or to crash SSH or something while installing a Guix package <lfam>Installing a Guix package involves downloading some files to /gnu/store, maybe doing some compilation in /tmp, updating a database in /var/guix, and then making some symlinks in your user's home directory <lfam>I'm also not familiar with Vagrant boxes. It's like a virtual machine? <lfam>Or just a way to specify a system that will be virtualized? <lfam>Also, I'm curious, after you type `guix install hello` and press Enter, does it log you out instantly? Or does it look like it's doing something first? etc <nisha>It does fetch some things first <lfam>So, nothing about how Guix operates should be able to control your user session or SSH server <lfam>But I notice that "ACL for archive imports seems to be uninitialized, substitutes may be unavailable" <lfam>That means that you haven't enabled the ability to download binaries, and so instead Guix will compile *everything* that is required to compile 'hello' <lfam>I wonder if your VM is running out of memory or something <nckx>nisha: Is there anything interesting logged in the output of ‘dmesg’? <nisha>yeah...just realized I don't just get logged out - my vm crashes <lfam>It's fine to avoid substitutes, Guix is actually a build-from-source distro that supports transparent substitution of binaries. But it may require some resources <lfam>So this is my first guess <nckx>How much RAM does it have, nisha? <rekado>in a package with ant-build-system I cannot get at the JDK with #$(this-package-input "jdk") <rekado>I looked at the ant-build-system and it explicitly labels the jdk input as “jdk” <rekado>we do this in a few places to distinguish the jre from the jdk <rekado>#$(this-package-input "icedtea") also doesn’t work <nckx>I don't think this-package-input looks at implicit inputs, unless you have a counterexample. <nckx>Which is to say, I tried it once, didn't work either. <nckx>OK, that's not ridiculously low and shouldn't crash immediately. <lfam>I feel like it should work unless it is attempting many package builds concurrently, or unless the storage is RAM-backed and becomes exhausted <guixy>Could it be something to do with build users and build group? <lfam>Like maybe if /tmp is a tmpfs <lfam>Yeah, should double-check the setup of the build users <nisha>I tried it both as a configured user and root <nckx>That won't make a difference. <nckx>The build runs as the same user(s). <nisha>but upping the RAM sounds like a good try <lfam>Guix kind of expects there to be about 10 "guixbuild01" "guixbuild02" etc user accounts that the actual work is delegated to <nckx>I don't actually think it will work, but cheap & worth a try! <lfam>nisha: Did you definitely create the guixbuild users? <nckx>‘Virtual RAM is cheap’ — now that I can agree with. <rekado>oops, I just accidentally pushed to core-updates-frozen… <nisha>lfam I have a guixbuild group <nisha>and I added a user to that group <nisha>oooh does guix expect a specific user?? <lfam>Can you also do `ps aux | grep guix-daemon` to double-check that the guix-daemon has an argument like '--build-users-group=guixbuild' <lfam>The daemon finds its build users via that argument <nckx>nisha: It shouldn't, it should just look at the membership of the guixbuild group, but I doubt other names are well tested. <lfam>I mean, it *should* work, according to spec. But I agree with nckx that it's probably not very well tested, since many of us install with the script or copy and paste that code snippet <nisha>The script didn't work for me...that's why I went the manual mode <lfam>I'm just trying to get a sense of how the system is provisioned and how the Guix installation is configured <lfam>That's okay! I also install manually <lfam>It's definitely supported <lfam>Can you check that the guix-daemon is running with that argument? <nisha>here's what's running /root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild <lfam>So, everyone else... any ideas? <nisha>biab - let me update the RAM and try again <florhizome[m]><jpoiret> "it doesn't compile to native..." <- I thought it has a jit, and that's native compilation <gnucode>I'm wanting to try to run guix from a console for a while...Essentially I would just start emacs after I login. <gnucode>But I think I would be tempted to give up this experiment after a few days...Is there someway that I could give a friend my "sudo" password and force myself to only use the console for a while? ie: make it impossible for me on "Guix System" to run X or wayland? <patched[m]>Is it possible to build using source from a local git repository? guix build doesn't seem to find a git repo when I give url "file:///path/to/my/repo" <gnucode> patched[m] It should be possible. You might be able to define a package for it. <guixy>gnucode: If it's a guix system, use the base services. <guixy>Don't include any desktop services <gnucode>guixy: thanks! That's a great way to do it! <guixy>gnucode: I've been trying to get startx to work from that setup for a while now. I probably would have had more success if I understood x a little better. <patched[m]>singpolyma: I'd like to try out changes locally first before pushing anywhere <guixy>gnucode: But if you can get a user-run startx to work let me know :) <gnucode>guixy: I would reccomend just running sway with %desktop-services. <guixy>patched[m]: --with-source=package-name=package-location <gnucode>guixy: I know it is possible to use %base-services and get a user-run startx. BUT I think you have to define various programs to be setuid, which %desktop-services does for you. <guixy>s/package-location/source-location <guixy>gnucode: Then you'd be good as long as those programs aren't setuid. <guixy>And you can control setuid in config.scm <gnucode>guixy: I'm actually tempted to make my laptop NOT have a sound server...I'm going really old school. :) <gnucode>BUT thanks for mentioning that I can just make various programs NOT setuid. I hadn't thought of that. <lfam>You could always pull to a commit that pre-dates ec7fb669945bfb47c5e1fdf7de3a5d07f7002ccf and then exploit that vulnerability to gain root <lfam>Sorry I know that's the opposite of what you want to do <gnucode>lfam: Well I'm going to try to forget that you mentioned that. hahah. <gnucode>and I'll will avoid looking up how to exploit that vunerability. :) <gnucode>and no need to apologize. I thought it was funny. :) <guixy>How long ago was that commit? <ss2>I'm reconfiguring and python2-pygtk is failing. <gnucode>thanks again for the help everyone! night! <ss2>with recent checkout. <guixy>ss2: When it's finally fixed, will you say "python2-pygtk has failed me for the last time!" <guixy>Or will you drop it and say that? <ss2>oh, sorry, I missed the conversation. <lfam>It's fallout from the "simplified inputs" style change <guixy>I know a lot of python packages fail to coexist because of conflicting inputs. <drakonis>i can actually run graphical applications on a foreign system <lfam>guixy: That's true, but I think this issue is different <ss2>okay, sorry, looking higher up this has been discussed so far. :) <lfam>I have to recompile my development tree. It will take a few minutes <ss2>I'll leave it for tonight then. Will complete the upgrade tomorrow. Heading off! <lfam>Note that there is no longer an input that is labelled "python-pygobject" <lfam>We just have to adjust that reference and then I expect it to be fine <GNUtoo>Hi, is there some people that use Guix SD on ARM 32bit computers? <guixy>At one point I used it on a raspberry pi v2. Now I'm all aarch63 <guixy>sorry, I meant package manager <guixy>Never got guixsd working on my bananapi <lfam>I think there is a small number of people. Build farm support for 32-bit ARM has been lacking so the user experience is not as good as other types of systems <GNUtoo>I got it working long time ago but all the last times I tried it didn't boot so I was wonderinf if for some other people it still boots. <GNUtoo>The isue was some lisp error during boot if I recall well, like the kernel booted but it didn't get to a shell prompt <GNUtoo>I've only boards with not much RAM though, like 512M or 1GiB to test with <lfam>Thanks <tschilptschilp23> <guixy>Looks like my gcc-toolchain is trying to use headers provided by clang-toolchain. <lfam>podiki[m]: Were you also working on a fix? <lfam>Okay, I'll do it shortly <lfam>I wasn't sure how to fix it "properly" so I just reverted the breaking change in order to save time <lfam>I'm testing the build of wicd (which depends on pygtk2) to make sure it builds too <tschilptschilp23>lfam: pulling right now. cannot promise to report back right away, as it's pretty late here and my eyes are tired already! <lfam>No worries. I'm confident this package will build for you <lfam>Or you can wait until tomorrow and get a substitute <lfam>"Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" <nckx>What does rde stand for? <lfam>nckx: Do you know how offloading is configured on berlin? It seems that when I build an aarch64 derivation there, it is always handled by the overdrive, but I'd like to make it use one of the honeycombs <nckx>Are they dover & grunewald? <lfam>I mean, kreuzberg, grunewald, and pankow are the honeycombs <lfam>At least one of them is in use, right? :) <lfam>overdrive1 is the overdrive <nckx>It is configured but perma-idle. <lfam>I don't quite know my way around how the farm is configured. I mainly grep in the maintenance repo and hope I find the info I need <nckx>Unless I'm missing an obvious, grunewald's simply not configured as an offload machine. rekado? <lfam>Can you tell me where that is configured? <nckx>machines-for-berlin.scm (I also checked /etc/guix/machines.scm but there's no uncommitted cheatery going on there). <nckx>The Wireguard tunnel's configured, and SSH'ing into the node works. <nckx>0.00 0.00 0.00 1/333 5783 <nckx>I could trivially add it to the list of offload boxes (and so could you) but we should wait for rekado. <nckx>Now I've said rekado 3 times. *nckx goes to get a mirror. <drakonis>trip report: post cuf merge guix works with foreign distros <KE0VVT>I'm debating what is a good convention for naming system declaration files, as opposed to home configuration files. Perhaps $(hostname).scm. <nckx>But since no ‘attempt’ was made to add them to machines-for-berlin.scm, I'm still cautious. <KE0VVT>And, for home configs, "$USER-home.scm". <nckx>Makes it easy to do magic hostname-based ‘auto’-loading. <KE0VVT>Also, does the graphical installer allow you to load a prewritten system declaration? <drakonis>apteryx: i ran graphical applications with a debian install with binary drivers <apteryx>nothing changed in that regard except a newer mesa stack <drakonis>i even rolled back to pre c-u-f pull and it had problems launching the applications <nckx>KE0VVT: Just that you can have a small /etc/guix/system.scm or whatever that automatically loads the right (gethostname).scm. <drakonis>looking forward to find out if it also applies to system installs <apteryx>drakonis: what do you mean by "if it applies to system installs" ? <nckx>In a complete changing of the mind, I'm going to start up building on grunewald, because I can't find anything wrong with it. Maybe it still has heat issues so I'm going to limit the number of parallel builds to 2. <drakonis>gotta make my gpu last until i can upgrade it <drakonis>if it does work, it'll simplify maintenance <lfam>Even a max-jobs of 1 would be alright if we are worried about heat <nckx>@ unsupported-platform /gnu/store/w9ciifkn95pzqsjd5kykybmskr03h8j4-gcc-toolchain-10.3.0.drv aarch64-linux <nckx>while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/w9ciifkn95pzqsjd5kykybmskr03h8j4-gcc-toolchain-10.3.0.drv', but I am a `x86_64-linux' <nckx>It's been years since I set up offloading and things are not going well. <nckx>guix offload test /etc/guix/machines.scm 10.0.0.10 works dandy. <podiki[m]>lfam: thanks for the quick fix, all good here! (well it downloaded the substitute, so even better) <nckx>apteryx: You need binfmt to offload? <apteryx>or perhaps your declared machine 'system' field is wrong <nckx>(systems '("aarch64-linux" "armhf-linux")) <podiki[m]>lfam: that should also fix the failing networkmanager, gnome-shell, etc. builds since they were missing that dependency <lfam>It's so refreshing to have NO GRAFTS <lfam>I feel like I need about half the storage space I did previously <podiki[m]>even though I was on c-u-f I do too, feel like i've been waiting for so long and holding off on some packaging <nckx>I GC'd 157 GiB yesterday (not all ‘master’-related, of course!). <podiki[m]>maybe I can finally setup a periodic gc too (didn't want to while "testing" c-u-f for so long just in case) <podiki[m]>perhaps someone should make an annoucement to guix-devel (and help?) about the big merge and next steps? <podiki[m]>(mutter and gnome-shell built successfully locally, should be a good sign for the CI now that pygtk is fixed) <lfam>I'm sure those involved are resting now :) <lfam>Would you like to do it? :) <podiki[m]>just building emacs (native-comp pgtk version) and then will do the reboot test <lfam>podiki[m]: Looks a message has arrived <apteryx>nckx: this on an aarch64-linux native machine (able to do armhf-linux natively as well), right? <nckx>Yeah, but I stopped pursuing that avenue. It was supposed to be a quick sanity check. Won't do if it's not sane! <nckx>It was an attempt to work around my complete lack of familiarity with the cuirass-worker mechanism and see if the thing even worked. ***jonsger1 is now known as jonsger
<lfam>"gpg: problem with the agent: End of file" <lfam>It cropped up after updating my installation <nckx>(cuirass-remote-worker-configuration (workers 4) …) ; on grunewald. As you might have noticed, there were only ever 3 workers listed at https://ci.guix.gnu.org/workers, not 4. Now I've shut down the remote-worker service on grunewald and 2 of those have vanished, as expected, but one does not. <nckx>It's dangerous to assume bugs when you have no idea how things work, but I wonder if that could be a bug 😛 <nckx>lfam: I can only say that I'm using gpg-agent without problems on an up-to-date system. <nckx>cuirass-remote-server has crashed… <apteryx>oh! now that's clearly bug report worthy <podiki[m]>and when guix looks for subs just stays at 0% <podiki[m]>perhaps the CI partied too hard post-merge :-| <apteryx>perhaps having issues with the network <apteryx>we'll have to resume work on Gnunet-powered substitutes ;-) ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ guix.gnu.org is down ⚠️ | 1.3.0 is out! https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
***ChanServ sets mode: -b *!*M6piz7wk*@*
<raghavgururajan>Hmm. Guix complains about GUIX_LOCPATH after guix pull, on guix system. <nckx>It can do that if you haven't updated all your user+system packages yet. <nckx>Because locales are glibc-version specific :-/ <nckx>I hope a lot of people have cold houses and/or laps tonite. <raghavgururajan>guix system reconfigure build texlive ghc rust etc stuff, which my melty x200t can't take up. So gonna retry after few hours. <nckx>I hear bordeaux is nice this time of year. <vagrantc>it's probably time to boot up the apm mustang and build all of aarch64 to heat things up a bit <vagrantc>i am running a heater using about 150 watts ... the arm64 server will only use 60 watts ... amittedly also produces a lot of noise <nckx>But can the heater be aimed at your face like an industrial heat gun? I think no. <lfam>I'm testing a gpg upgrade. Signing works, symmetric decryption does not <podiki[m]>guix.gnu.org on the same servers? or something? (down for me) <nckx>As guix.gnu.org? Unfortunately, yes. <nckx>Much redundancy. Very HA. <podiki[m]>syncthing-gtk fails to run for me due to some librsvg thing; will investigate later <nckx>logs.guix.gnu.org is critical infrastructure so remains up. <podiki[m]>thread '<unnamed>' panicked at 'Type RsvgHandle has already been registered', /tmp/guix-build-librsvg-2.50.7.drv-0/librsvg-2.50.7/guix-vendor/rust-glib-0.9.3.tar.gz/src/subclass/types.rs:485:13 <podiki[m]>and it was working on c-u-f prior to the big merge (but maybe pre-librsvg workaround?) <podiki[m]>was there some discussion on bordeaux out of space? <lfam>The datefudge source code disappeared upstream 🤦 <nckx>I was reading that mail as you spoke. <nckx>lfam: It's on guix.tobias.gr if you need it. <nckx>Not that you shouldn't let me provide you with arbitrary binaries. <lfam>My gpg problem was fixed in 2.2.31 <cehteh>is the bug-guix list moderated? i replied there and it didnt seem to get through <nckx>rn might not be the bestest of all times, alas. <nckx>At least I can't get my Guix to use it. <jackhill>I need to re-read cbaines's emails about setting up mirrors of guix build coordinator output, as I'd like to try doing so. <jackhill>I have a willing partner with a bunch of disks, but they need a better explaintation than, "we may have to write some code, and the code may want access to a database" ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ guix.gnu.org is down ⚠️ | Download: https://ftp.nluug.nl/pub/gnu/guix/ | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<nckx>(Mirror chosen highly arbitrarily to be both short and non-commercial and European because that was the status quo.) ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ guix.gnu.org is down ⚠️ | Download: https://ftp.nluug.nl/pub/gnu/guix/ | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://debbugs.gnu.org/guix https://debbugs.gnu.org/guix-patches | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<cehteh>is that just the website or more? <cehteh>just send mail lests see if that gets through <cehteh>nckx: ah damn under wrong sender :D nckx could you please whitelist my normal address too? :) <nckx>Mail works fine (please don't send ‘test’ messages, anyone). <nckx>vagrantc: You'd be amazed at what is required to get people to read the topic… <nckx>I'm very impressed so far. *apteryx is curious as to what exploded on berlin <cehteh>but hey people will notice it anyway that the server is down :D <vagrantc>i see all these ⚠️,, but is guix.gnu.org really down? <cehteh>i didnt asked how long ago the last gc run on berlin was :D <cehteh>i mean the once before the 5TB trash collected <nckx>cehteh: issues.guix is just a prettier Web front-end to the back-end behind debbugs.gnu.org. <cehteh>nckx: you can login to berlin too? seem my last message, <nckx>cehteh: I think it ran about 24h ago, IIRC. <nckx>cehteh: I can when it's up. <nckx>I don't have iWhatever access or anything. <cehteh>nah i meant the one before the shit hits the fan .. that must be months ago? <nckx>When what shit hit what fan? I don't follow. <cehteh>while i was brainfarting here it just came to me "omg they didnt forget relatime?!?!" <nckx>He's the only one who can fix this if it doesn't fix itself. <nckx>cehteh: Isn't that the default since kernel $forever. <nckx>You have to do $something to get old-timey atimes, at least. <nckx>Maybe we access files in a way that relatime still murders us. <cehteh>i doubt relatime has a pretty simple heuristic <cehteh>thats to be expected on spinning platters <nckx>It's a good point, though, definitely something to investigate, although I don't think it's likely unless something is actively fighting the kernel defaults. <cehteh>well some things could be tuned for sure, but since its a production machine i woulnt try too much <nckx>I never really took ‘deletion speed’ in fs benchmarks seriously (when is that ever on the critical path?), now I get it. <ns12>"guix substitute: error: connect*: No route to host" <ns12>"substitution of /gnu/store/b9x0w06vjb0lwhcagxj442lw6jx3vyxf-module-import-compiled failed" <cehteh>sometimes setting laptop_mode to some higher value helps to batch writes better, also the disk schedulers have some knobs to tune, make longer queues, longer timeouts to allow the scheduler to coalesque jobs better <ns12>"guix install: error: corrupt input while restoring archive from socket" <cehteh>nckx: dunno how XFS is now .. but when i tried it 15+ years ago it was pretty poor on massive metadata operations <nckx>Yeah, I don't actually have any experience with it, it just seems like a meme. <ns12>What should I do to install packages in the meantime? Build everything from source? <nckx>What is a good file system for those? <cehteh>anyway my plan is "dont care about the speed, just take it out of the hot/locked path" <nckx>Yes ns12. We're in something of a perfect shitstorm as far as substitutes are concerned. <cehteh>dunno but i think ext4 shouldnt be so bad <ns12>nckx: Is this an unexpected outage? <ns12>What is the underlying cause of the problem? <cehteh>5TB trash with zillions of hardlinked files is just massive <nckx>cehteh: <just take it> Yes, I agree that seems like the only real solution. <vagrantc>downgrade to whatever version bordeaux last built? ... which is also more-or-less out-of-disk space as i recall <nckx>I was just checking that but there's no Cuirass UI I can find. <nckx>Though I didn't look very hard yet. <nckx>Yeah, I don't want people to actually downgrade their systems, even if few will actually be using the log4js of the world in practice. <cehteh>you could throw money on it some TB enterprise grade SSD's but i am still believing in proper programming is more sustainable than thowing hardware on a problem <vagrantc>e.g. i think it's been paused since ~ December 3rd last i hear <nckx>We are in agreement. We have money. We don't have throwin' money. <nckx>If complexity weren't such a problem already I'd consider pitching something like bcache (to be clear: I won't). <nckx>At least there's a ‘12’ in that link. *clicks* <cehteh>locally here i have dmcache which is really great, but no cache would help with the deletion problem, whatever you delete is likely cold in the cache <nckx>I don't think bayfront's been resumed since that mail. <nckx>So yes, that's about it. Almost a month old. <cehteh>for my testing here dmcache is nice i can walk 200Million files in 1 hr in my tests, on pure platters that will take many hours <nckx>Put the metadata on SSDs. /s <vagrantc>ok, it's really time to boot up my aarch64 server with a pretty old guix install on it :) <apteryx> /gnu/store/b4vr6046c36g2b0q3d0zh9bpa9gczkqc-icecat-91.4.0-guix0-preview1.tar.xz.drv takes forever -- is parallel xz compression not working for that one? <nckx>vagrantc: Its time to shine! <cehteh>yes, but neither bcache nor dmcache can do that, zfs can do that with some efforts <apteryx>or perhaps it does its own thing as a computed file origin *vagrantc coughs as the fans spew dust everywhere <vagrantc>will see if i can't carve out some time tomorrow for that :) <apteryx>ah yes, the later: (invoke "tar" "xf" #+upstream-firefox-source) <nckx>Does anyone have /gnu/store/rfb2s26azhlqzznamfqydv3s3ab90sqf-python-minimal-3.9.6.drv they could share as a nar? <nckx><Does anyone> I have reached sneakernet-levels of desperation in mere hours, yes. *lfam wonders if they should push the gnupg update *apteryx slaps (setenv "XZ_DEFAULTS" (string-join (%xz-parallel-args))) in there <lfam>I suppose no, since I can't actually test it on current HEAD <vagrantc>lfam: it couldn't possibly break anything harder than it is right now :) <nckx>What's the rebuild count? <lfam>It grew to a very large number <nckx>Well, still, let's severely limit the number of rebuilds people have to perform now… <vagrantc>someone seems to have recreated core-updates-frozen :) <lfam>We'll have to deal with it once CI is back online because the gnupg version we have on master doesn't do symmetric encryption <nckx>vagrantc: Was it actually deleted yet? <lfam>I'd guess it sees use in password managers <apteryx>lfam: it'll be best to build this away from master, on the version-1.4.0 branch; but not now, berlin probably run out of disk space or something, let's not burden it more yet <lfam>Once CI is back up, I think we should make some effort to fix it on master because one of its critical features is missing <lfam>Maybe we can add a gnupg-next package and use it in specific places, for example <nckx>Nothing PotentialUser-33. The DNS is handled by GNU, so at least the *.guix.gnu.org subdomains hosted on other machines should remain up. <nckx>That just looks like a typo or Unicode attack? <lfam>I don't experience that redirect <nckx>Did you perhaps hit an accidental compose key or something? <nckx>That's how Unicode URLs ‘work‘. <nckx>Yes, and it included the “ in the URL. <nckx>At least we're not under attack… o_O <nckx>That was creepy for a brief moment. <jackhill>the things one learns in adventures without substitues: half of ruby-land is needed for `guix pull`. I would never have guessed. <nckx>So is Python-‘minimal’, which reliably fails its test suite on my laptop. <nckx>If I get it to build maybe we'll see npm scroll by. <nckx>Well, it's what ‘guix pull’ is stuck on here. <apteryx>I've rebuilt core-updates-frozen dozen of times, and don't recall python being flaky :-/ <jackhill>hey, at least we have so many of these packages packaged! <nckx>And yes, it has ‘dodgy’ written all over it. <lfam>It's hosted in the datacenter of a research institute <nckx>They are gracious and competent hosts. <lfam>Currently it's the middle of the night in that place <nckx>I'm sure it's somehow our fault. <lfam>Tests result: FAILURE then FAILURE <apteryx>nckx: I'm guessing file system related *raghavgururajan is confused with guix-home <nckx>I've tried on bcachefs, tmpfs, and btrfs so far. <lfam>Does anybody know why gnupg has so many dependents? <nckx>Am I really going to loop-mount an ext4 image? <nckx>…yes, I probably am, because what else is there to try. <apteryx>nckx: it reminds me of something... trying to recall <nckx>Loop image mounted, guix-daemon pointed, build started. <nckx>apteryx: Any specific part? <AwesomeAdam54321>The problem is that about half of my services get disabled because they respawn too fast <nckx>raghavgururajan: I hope you were riffing on my last message and not talking about yours! <apteryx>nckx: it's was some basic tool that failed on Btrfs, and then there was some plan to devise a linux-specific tool to replace it <apteryx>nckx: perhaps you should chime in with a revenge of the dead note <lfam>There already *is* a newer gnupg package! ffcf4ea9abbbc35fefbe4a491e1e5eac1c7c0002 <lfam>The big part of the reverse graph is gpgme *raghavgururajan starts a dial-up connection <KE0VVT>i rm rf'd a lot of my ~ and no bavkup <AwesomeAdam54321>Is there a way to conveniently start multiple services with 1 'herd start' command or something similiar? <lfam>KE0VVT: The site is down <KE0VVT>i guess everybodys deleting stuff tonight *KE0VVT checks moon phase *nckx promotes the health benefits of hourly backups. <lfam>Borg has saved my skin several times <KE0VVT>and with guix config in my home, maybe i dont need to worry about / <apteryx>PotentialUser-33: haven't heard of the timeshiter feature yet <nckx>The servpocalypse might be upon us but at least there's entertainment! *raghavgururajan hums "sync sync sync thing thing thing ..." <nckx>ERROR: test_fcntl_64_bit (test.test_fcntl.TestFcntl) *nckx fingers random components. <KE0VVT>raghavgururajan: syncthing helps a lot but not for everything *nckx hums rsync rsync don't overengineer ♪ *raghavgururajan 's mind was picked by nckx *nckx wrote an 821-line wrapper around rsync so don't take advice from them! <lfam>New versions of rsync provide plenty of opportunities to overengineer, with a wide variety of modern compression and hasning algorithms ;) <KE0VVT>nckx: oh yeah im not maintaining a wrapper screw that <lfam>My borg wrapper is only 67 lines long *apteryx needs to devise a guile wrapper around 'btrfs send' *raghavgururajan goes into a cloud called next <lfam>I don't know, it just happens to me <apteryx>nckx: the hunk of these 821 lines must be the ignore list I hope? <apteryx>you can tell when the script was hacked up <lfam>My wrapper script is pretty bonkers <nckx>apteryx: No, it's a few orders of magnitude more insane. <lfam>[ $# -lt 1 -o $# -gt 2 ] <nckx>It pries apart rsync and partially reimplements its own ‘protocol’ in bash. <nckx>So we can rsync the rsync file list, which is about a gigabyte in size. *raghavgururajan is sleep drunk <podiki[m]>nckx: still looking for that python-minimal? I have it <apteryx>nckx: you should make an xkcd out of it <podiki[m]>what exactly do you need and how do I get it to you <PotentialUser-33>we are like the people whos house is burning and we have a beer and chat <nckx>podiki[m]: guix archive --export /gnu/store/[the result of building that .drv] > /tmp/nar <lfam>It's kind of like the electricity is out so we just hang around and tell jokes <apteryx>it has that vibe of when the power is out <nckx>Nah, it's not that bad. It's more like a friendly neighbourhood get-together around a flaming barrel during a blackout. <lfam>The humanity that emerges when productivity is off the table <nckx>So what apteryx said, derp. <lfam>It's a good argument against hosting our own chat *nckx → now really going to eat something, thanks in advance podiki[m]. <podiki[m]>nckx: so you want the python-minimal output, e.g. guix build /gnu/store/...that.drv, export what that tells me is the store dir? <podiki[m]>sneek: later tell nckx whenever you are back I have it for you <podiki[m]>PotentialUser-33: what address? to connect via matrix? <podiki[m]>...I take it that means PotentialUser-33 made it over the bridge... <nckx>podiki[m]: I should've used $(…) instead of inventing my own syntax, but it's 6am for me too 😉 I will now gladly curl your arbitrary executable blobs. <sneek>nckx, podiki[m] says: whenever you are back I have it for you <podiki[m]>anyone else need anything by any chance? I won't be able to set up a mirror suddenly, but did manage to have everything (and then some) before the CI went down <nckx>podiki[m]: Sweet, it worked, thanks again. <nckx>Thank you so much for your work on c-u-f. <apteryx>:-) thanks for the encouragement; at some point I wasn't sure if I was breaking more than fixing ;-) <ns12>Is there a place to report severely outdated packages? <nckx>In all honesty, I'm not sure that's something we want to encourage. <nckx>I mean, mentioning one or two is fine, but updating severely outdated packages is rarely easy. <nckx>‘Knowing x is outdated’ is very, very rarely the bottleneck. <nckx>Which package did you have in mind? <ns12>I'm just asking in general. Whether or not there is a formal mechanism to notify the maintainers, just in case they forgot about updating packages or somehow didn't know about the existence of new versions. <nckx>People tend to submit patches instead. <ns12>Okay, I'll give it a try. <nckx>Wow, great ☺ If you get stuck, don't hesitate to ask questions. <ns12>Thanks for the encouragement. :) <podiki[m]>errr... I was going to link ns12 to the manual, only to hit the down server (duh) <nckx>D'oh, I forgot about guix refresh. <podiki[m]>or also guix build --with-latest for a one liner to see if it "just works" <nckx>My distrust of automagical tooling is showing and is probably undeserved. <nckx>guix refresh is definitely the way to go first. <podiki[m]>there's probably a (longer) one liner to do a git checkout, build, and refresh in the pre-inst-env, AND submit the patch all in one <podiki[m]>transformations always feel like superpowers to me, love them <nckx>We have one, but it's also out of service. <nckx>Nah, just more robust mirrors. <nckx>Mirroring Guix is not as simple as most other distributions which are just nearly-static directory trees you can rsync. <nckx>Seven-ALB[m]: The 2nd CI (bordeaux from now on) isn't ‘down’ per se, it was paused begin December because we ran out of space and thought we had plenty of time to decide what to do. <nckx>And the other half of the perfect storm is that today a branch was merged that makes all of bordeaux historical substitutes ‘obsolete’ for current master. If this had happened yesterday, it would have been comparatively less bad. <nckx>10TB will certainly suffice. <Seven-ALB[m]>is there a way to mirror only the store needed by a config.scmn <nckx>Remarkably yes. guix gc --requisites $(guix system build /etc/guix/system.scm) will get you extremely close, if not 100% there. <nckx>Substitute the file name of your choice. <nckx>(This command does not collect garbage at all; ‘guix gc’ has grown some options that make it more like ‘guix store’ now.) <nckx>That command does imply you've already built the system on the machine it's running on. <nckx>But there are ways around that at the trivial cost of no longer being a one-liner :) <guixy>blueman-applet shows a dialog with this error: <guixy>g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2) <guixy>How is this typically handled? <nckx>And how! I didn't even know then. <nckx>Or unreachable, at least. <rekado_>I gotta prep my kid for daycare, will check in 20 mins <efraim>with c-u-f merged I can poke guix.m4 and the manual about deprecated architectures <nckx>guix.tobias.gr is having the time of its little life. Pity it's still stuck bootstrapping Rust itself… ***ChanServ sets mode: +o nckx
***nckx sets mode: -b ix!*@*
***ChanServ sets mode: -o nckx
<abrenon>thanks for all the clear messages and the fallback nckx <nckx>There isn't really a fallback :( <abrenon>not for the substitutes but I mean to download guix itself <abrenon>isn't that the content of the nluug ftp thing ? <nckx>That is a trustworthy GNU mirror, at least. <allana>Hi everyone. Is anyone having issues updating substitutes on a "guix pull"? <allana>A "guix pull" is not succeeding on my system, staying at 0.0% for an extended period of time. <mothacehe>hi unmatched-paren, unpossible to know the whole guix infra is down atm <rekado_>meh, I can’t get connected to the serial console <unmatched-paren>what happened to the servers? i can't get to guix.gnu.org in a web browser either <abrenon>I suppose it's pretty bad if even the serial console doesn't respond ? <nckx>And after this, status.guix.gnu.org is definitely going to be a thing, so I can just slap that in the topic & be done with it. <mothacehe>florhizome[m]: that's not the CI, it's the whole server <nckx>rekado_: Are any of the berlin build nodes reachable? <rekado_>trying to get ahold of the networking team <rekado_>can’t access any of the build nodes either <rekado_>and not a single person has responded to my requests for help <abrenon>don't we have status monitoring for the various pieces of hardware ? (plugs, switch…) <nckx>From what I've seen, what status monitoring there is runs in a Windows VM(?), that kind of thing. <nckx>At least I hope it's a VM 😛 <nckx>It is completely separate from the berlin server. <nckx>Berlin hosts guix.gnu.org, ci.guix.gnu.org, issues.guix.gnu.org, probably something else I forget. <nckx>Bordeaux hosts, well, bordeaux.guix.gnu.org, and logs.guix.gnu.org. <nckx>florhizome[m]: It would be exceptionally trolly if it didn't host that. <cehteh>mhm .. so berlin is completely down now? or somehow reachable? <rekado_>nckx: that’s just the management interface of the storage <rekado_>I’m not the IT department. *They* have monitoring for the data centre, obviously. <florhizome[m]>But if Bordeaux works that means it’s a Berlin server problem <rekado_>it is not a server problem necessarily <cehteh>well there was the gc/rm thing ... maybe there was some glitch on the fs and it crashed/rebootng/fscking <nckx>It was acting weird, but I can really not say if it was weirder than usual. <nckx>Services failing, that sort of thing. Unfortunately not that unusual. <cehteh>rekado_: seen my mail i wanted to ask you if perhaps (small chance) the filesytem was not mounted with relatime (and possibly nodiratime) which may or may not be part of the slow delete process <nckx>I'm just glad rekado_ is OK and Germany is still there. <cehteh>is berlin really located in berlin? :) <nckx>(Maybe not just right now, cehteh :) <rekado_>so, I’m on the serial console; no response from the server <cehteh>ba prepared that booting/fsck will take quite some time <florhizome[m]>the knowledge that guix is hosted in Germany doesn’t help my urging need to bridge the situation with awkward jokes <nckx>Imagine if it were ext2. <cehteh>no hands on site you can call for a check? <nckx>It is not a commercial DC. <cehteh>i mean reset .. mkay last resort <zimoun`>I noted that the web page of ci.guix.gnu.org was not responding yesterday; end of my afternoon. <cehteh>sometimes a reboot is a good thing .. you notice everything you broken in the boot process since the last boot :D ... except that shoudnt happen on guix <nckx>There are a few hacks in place to boot on the Dell HBA thingamabob etc., but they should be quite settled at this point. <rekado_>cehteh: I could bike there now, of course <rekado_>zimoun: end of your afternoon would have been the network outage. <rekado_>which was actually unrelated to the MDC. <rekado_>nice. ‘All of the disks from your previous configuration are gone. If this is <rekado_>an unexpected message, then please power off your system and check your cables <vivien>Thank you for the core-updates-frozen merge :) *cehteh remembers back the time with compaq servers ands scsi disks in plastic cages .. one disk tried to escape by melting its was into freedom D: <rekado_>I’m restoring the controller’s disk config <rekado_>‘Unified Server Configurator does not support console redirection.’ <vivien>I decided to reconfigure without substitutes, but now that I’m building one of the webkits, I remember why that’s a bad idea. <rekado_>it now recognizes the virtual disk again <jlicht>happy day-after-merge-day, guix! \o/ <nckx>jlicht: Somebody celebrated by stealing our discs, but they put them back. <rekado_>but the ‘Lifecycle Controller’ is now in recovery mode and it tells me to ‘Repair Lifecycle Controller firmware using the Lifecycle Controller Dell UpdatePackage (DUP) or Lifecycle Controller Repair Package via iDRAC. For moreinformation, see Lifecycle Controller User's Guide.’ <nckx>Be sure to have your enterprise subscription key ready. <jlicht>it's not a party of some disks don't get misplaced! <vivien>nckx, did that somebody inject a self replicating backdoor into our binary seeds while the disks were missing? <nckx>Let's not joke about everything just now. <abrenon>that wouldn't be very funny, party or not <nckx>(It had occurred to me, though not in that literal a sense.) <csantosb>Anyone lucky with the following command ? <csantosb>'guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' -- chromium' <nckx>But crappy Dell hardware is Occam's friend. <zimoun`>why “guix time-machine --commit=94836b2 -- weather“ fail because /gnu/store/v8m3nivqdq9wp77x2wv0p51nw6sddg9g-guile-json-3.5.0 and do not build it? <csantosb>I just get an ugly 'Authorization required, but no authorization protocol specified' message <abrenon>vivien: but then wouldn't that show when we build packages locally and they don't match the substitutes on the server ? <abrenon>csantosb: I suppose you're using X11 then ? you need to pass some dir in /tmp too <nckx>abrenon: Yes, but not all packages are bit-reproducible yet, so it would require some human filtering of the (more than a handful of) false positives. But it could be done! <csantosb>abrenon: correct, X11. So I need the '--share=/tmp=/tmp' flag or similar ... ? <abrenon>csantosb: /tmp/.X11-unix, preferably not with share <abrenon>uh… -E ? is there such a thing ? I don't remember <abrenon>nckx: even if it needs a lot of work, that's still good news that it'd be possible <nckx>jlicht: I was thinking of something waay simpler, but omething that fancy would certainly be nice. <rekado_>switched the LC back to ‘enabled’ from ‘recovery’ <rekado_>perhaps because of a RAID controller firmware upgrade, or the fact that it was extended with SSDs <rekado_>all Dell servers get their upgrades pushed to their iDRAC via a management server. <rekado_>we explicitly acknowledge all upgrades that are pushed <rekado_>we hadn’t rebooted when we last applied the RAID controller upgrade <zimoun`>why even «guix time-machine --commit=94836b2 --no-substitutes -- weather» does not work? *jonsger still waits on server vendors jumping on the fwupd train... <nckx>jonsger: Firmware update? <nckx>(No: it's apparently a firmware blob uploader for GNOME. Unlikely future Guix material.) <jonsger>jop. Dell and Lenovo are doing that for Laptops/PCs quite broad, but not for servers. As they wanna sell bs firmware upgrade software... <nckx>‘In December 2015, it was revealed that Hughes had been working with a Dell developer to test the system on actual hardware, and that its Dell Edge Gateway product will support firmware servicing via fwupd.’ <jlicht>nckx: it's a service to get the right proprietary bits to your usrs even faster <nckx>I see that went nowhere. <abrenon>csantosb: I don't have the documentation right now and I'm late for a webconference <abrenon>I thought it was something like --expose ? <nckx>jlicht: So I sliced through the marketing spin correctly 😛 Thanks for the confirmation. <abrenon>it'll work with --share, it's just not necsseray to give RW, RO should be enough <jonsger>jlicht: there is also foss firmware up there :) <csantosb>abrenon: Tried this 'guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' --share=/tmp/.X11-unix --share=/tmp/.XIM-unix --share=/tmp/.X0-lock -- chromium'. Still no luck. <csantosb>Using expose instead of share doesn't make any difference. <jlicht>jonsger: cool! Perhaps the FSDG-projects can have a look some day when there is a reasonable amount of firmware on there for a libre spin of fwupd <attila_lendvai>rekado_, a hypothesis: maybe the firmware got upgraded, the config got migrated/adjusted to the new version, no reboot, and then something happened that caused the old version to change/overwrite the config... that would be stupid, but i've seen worse. <cehteh>there are a lot reasons speaking for linux software raid (and few against) <nckx>It's great when you have the luxury. <efraim>(NOT A BUG REPORT) it seems I now need to launch icecat with MOZ_WAYLAND_ENABLED <efraim>(STILL NOT A BUG REPORT) and torsocks isn't happy with me <efraim>still need to upgrade by user packages <zimoun`>nckx: how many derivations do you build? <nckx>I didn't check. Was that the problem? That it silently does nothing/too little? <nckx>‘computing 19,666 package derivations for x86_64-linux’ <nckx>A bit satanic, but nothing over the top. <nckx>I don't understand what the problem is, you'll have to share more than ‘x doesn't work’. <nckx>Otherwise, it seems like something's wrong with your installation, and what is anybody's guess. <zimoun`>nckx, the time-machine tries to build many derivations. Then fails. For instance cannot build derivation `/gnu/store/pw35ppk895rdzwykb5zhr20m5kkp0qrq-datefudge_1.23.tar.xz.drv': 1 dependencies couldn't be built <nckx>Yeah, but I don't get any of that. <zimoun`>if you have all already in your store that’s not a problem :-) <nckx>That error isn't unusual in itself. Things fail. Why did it fail? <zimoun`>my expectation is: it just works, building many many thing. But no, it just fails. <nckx>Sometimes things do. I just had 3 packages fail to build in so many hours. I tried them again (2 on a different machine) and voila, they worked. <jonsger>efraim: you could create an icecat-wayland package like icedove-wayland... <nckx>zimoun`: OK, that's known. <rekado_>I switched the controller from BIOS boot to UEFI boot <rekado_>which means: guix system reconfigure thought it was a good idea to just switch modes on me <zimoun`>it is not possible that because Berlin is down, ‘guix pull --no-substitutes’ fails! When Bordeaux is up! <nckx>What does bordeaux have to do with --no-substitutes? <efraim>jonsger: I know, I'm not ready to commit to wayland icecat, it wasn't working for me before <nckx>I don't know zimoun`. That's a different URL than the previous one (which is known vanished) and I still don't understand what you're actually asking. <nckx>This is the first time you mention ci.guix. <zimoun`>I am asking why ‘guix pull’ does not work when Berlin is down when we are running Bordeaux. <rekado_>for the record I changed two things: enabled disk fallback, so that more disks are retried when one cannot be booted from (shouldn’t have any effect because there’s just one virtual disk, RAID0, two SSDs, and one HDD as a spare) <nckx>zimoun`: And I'm asking, I guess, besides actual details, why bordeaux being up should make it succeed. ***chris is now known as Guest599
<nckx>You're saying that like it's a logical conclusion. <nckx>Why should bordeaux have substitutes for 94836b2? (Spoiler: it probably doesn't.) ***Talisman is now known as Dio
<nckx>So I still don't understand how bordeaux is supposed to make your command work. ***Dio is now known as CarDio
<zimoun`>nckx: that’s my point! We are running 2 build farms. I am not asking that the 2 build farms serve all the substitutes, I am asking why when Berlin is down, ‘guix pull’ becomes broken despite Bordeaux is up. <cbaines>bordeaux.guix.gnu.org doesn't serve content addressed files in the same way that ci.guix.gnu.org does <cbaines>I'm looking at addressing that at some point, and then I guess there's a list it needs adding to somewhere ***sam__ is now known as sam_
***gmodena_ is now known as gmodena
***ft_ is now known as ft
***lukedashjr is now known as luke-jr
<cbaines>guix publish does the translation, and it's something I'm hoping to enable with the nar-herder thing that I'm setting up currently <nckx>So we could get that file from bordeaux somehow, today, with a different URL scheme? ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<nckx>I think that's all the old URLs? <nckx>I left out ‘1.3.0 is out!’ because c'mon. <cbaines>nckx, maybe, I think bordeaux might have nars for the relevant file <cbaines>just needs to serve it in a way that's understood ***jave_ is now known as jave
***molybdenum.libera.chat changes topic to 'GNU Guix | ⚠️ guix.gnu.org is down ⚠️ | Download: https://ftp.nluug.nl/pub/gnu/guix/ | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://debbugs.gnu.org/guix https://debbugs.gnu.org/guix-patches | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ changes topic to 'GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<nckx>zimoun`: Also, bordeaux has been, er, ‘paused’ since the beginning of the month. <nckx>The situation is really not great. <nckx>zimoun`: It still serves older substitutes but its ability to serve as a back-up is virtually nil. <efraim>anyone have a patch for lagrange? <civodul>rekado_: big thank you! you're our hero! <nckx>how many beers do we owe rekado_ now? <efraim>I hear he also takes payment in making a service copy the necessary bits to /boot for berlin <nckx>rekado_: Seriously though, you will not be spending too much next FOSDEM (if that ever happens). <civodul>i know the kind of pressure you have when you're *the* person who can access the machine <civodul>how about a hackathon to improve redundancy/backups? <civodul>for example, we talked about redundancy for the web site but never got around to implementing it <civodul>cbaines is also looking at synchronizing nars among multiple servers, that's another thing we could work on <nckx>Good idea. I think we all had certain ideas during this ordeal. We should give them form while they are still fresh. <civodul>and there's status.guix.gnu.org, too <civodul>yeah, let's come up with a list of tasks <nckx>Seven-ALB[m] proposed possibly hosting another mirror. <nckx>I also noticed that the Chinese one doesn't actually function in the absence of berlin. Or at least not for me. That might've been for whatever other reason (GFW?) but it's something that I'll investigate further, because I was kind of counting on it as a fallback. <civodul>re the Chinese mirror, does it actually use rsync? <nckx>I'm not aware of any that do? <civodul>i know rsync was almost, but not quite, ready to use <nckx>I don't think it works as things are now. <nckx>Erp, I thought you knew. <nckx>Another thing to look up. <civodul>nckx: "yes" to you, "no" to florhizome[m] :-) <civodul>florhizome[m]: if you have updated your checkout, i suggest running "make clean-go && make" <efraim>I went full 'git clean -dfx' for this one <efraim>and then a second time after rebooting <nckx>‘As I said earlier, this does not <nckx>work well for Guix because Guix client does not handle HTTP 302 redirection correctly. So we tweaked the program a little bit to offer transparent proxy to Guix client. The program is here: https://github.com/sjtug/mirror-intel‘ <nckx>But if rsync is close to being ready, that's what mirror operators actually understand. <nckx>I didn't know it was, that's good news. <CarDio>Hello, here i can find an answer about packages like haskell's gi-gtk? <florhizome[m]>I just pulled -- which checkout? i get a few error messages like this and some package names are not found anymore. guix build: Warnung: „(gnu packages my-fonts)“ konnte nicht geladen werden: <florhizome[m]>In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed <nckx>(gnu packages my-fonts) is not a Guix module 😉 <abrenon>it's a local package of yours that needs recompilation because it was compiled with an old version of guile <nckx>You need to (at least) make clean-go in your local checkout. <abrenon>I get those all the time after I finally guix pull (twice a year) <nckx>It's more often if you pull more often. Remarkably so. <nckx>…GUIX-PACKAGE_PATH, according to you 😛 <nckx>I don't know what it looks like. <abrenon>but there's also some stuff in ~/.cache/guile or something, isn't there ? <nckx>But that would be printed in the error message if it were the problem, I think. <abrenon>so apparently I did miss all the fun <civodul>nckx: rsync may well be ready, we should get in touch with mirror operators <nckx>Although it's possible that guix pull swallows errors. <nckx>If you don't have a Makefile it's not relevant. <nckx>And the cache directory abrenon mentioned? <nckx>I find it very strange that there are no .go files mentioned in the error message; my Guix always spams me with them, copiously. <nckx>civodul: ‘May well’ sounds… like you're guessing. Not that I know much about mirror operation. <abrenon>so how can we make sure the disk in berlin hasn't been tampered with ? <nckx>We'll use Seven-ALB[m] as a guinea pig, if they get approval to go ahead with it. <civodul>nckx: the last issue i was aware of was a permission issue on /var/cache/guix/publish, which was fixed months ago <civodul>but yeah, for the rest i'm just guessing <nckx>abrenon: Maybe there are cameras. I don't see an ‘internal’ way. <civodul>did someone write a recap of the new things that were just merged? <civodul>i think mothacehe had written one a few months ago <nckx>florhizome[m]: Nothing, just delete it. <abrenon>it should reproduce the structure of the paths where it found the code to compile <abrenon>so you can rm -rf selectively if you like <abrenon>but you can also just wipe everything <nckx>I need to sleep, it's noon and I haven't slept. Good, er, night. <florhizome[m]>hm maybe geiser/emacs caches would be worth saving but idk shouldn'tbe toomuch damage <abrenon>ohhhh so cool it works in german ! (I was wondering why good neight ^^) <abrenon>csantosb: it's Xauthority. You need to pass it too <abrenon>guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=/tmp/.X11-unix --expose=$XAUTHORITY -- chromium <abrenon>aber es wirkt nicht auf Englisch : S <florhizome[m]>Ok the errors are gone but my packages are just not found now 😐 <abrenon>(I forget all the time and I always struggle to find it back, so thanks for the practice) <csantosb>Maybe someone should update the doc (guix shell) ? <abrenon>csantosb: I tell myself that all the time, and then I find it depends on too many things <abrenon>(for one, it's a X11-only issue, wayland people shouldn't have to be concerned…) <abrenon>if you find a way to improve it, I'd be glad, because it's a concrete use-case that would be nice to find as-is in the manual <csantosb>abrenon: the doc as it is now does it for wayland ? <vivien>So I fixed my issue with the SMTP server (always listen on addresses, not interfaces), and now I can finally switch to the static networking service \o/ <jpoiret>csantosb: wayland only needs --preserve="^WAYLAND_DISPLAY" <jpoiret>ah, for a container it might need something more (you won't make me admit that i don't know what the wayland transport is) <mbakke>is there a way to force evaluation of inherited package arguments with new variables? i.e. if a package uses the 'version' variable in its builder, it won't change even if the inherited package uses a different version <EdwardIII>hey, if you want to install guix system on qemu on an ARM guest, what are the options? build it on the host first? interested in playing with it but on mac m1 <EdwardIII>i see you can get guix actual for multiple platforms, but not guix system <ngz>Nice to see c-u-f eventually merged! <sneek>Welcome back ngz, you have 1 message! <sneek>ngz, luis-felipe says: thanks for reviewing and integrating my package :) <ngz>Yup, it should happen soon. It means most core packages got a version bump. <ngz>Default GCC is now 10, for example <ngz>It was 7.5 previously. ***aweinsto1k is now known as aweinstock
<jpoiret>mbakke: i think you'll have to inherit but still respecify the version manually <jpoiret>oh, I typed before I could actually think it through <jpoiret>I don't think there's a way to do this unfortunately <mbakke>I suppose a proper fix would be to pass #:version to the build system arguments <rekado_>tensorflow 1.9.0 cannot be built with Python 3.9. 3.7 works (after minor patching). <rekado_>even if we did fix that by patching the sources, we’d still have the problem that this version of tensorflow is not meant to work with a more recent numpy. <civodul>sneek: later tell mothacehe postgres is logging lots of things to syslog, is that intended? <ngz>Do I get that there is now a cleaner way to do (string-append "PREFIX=" %output) in #:make-flags using gexps? <ngz>Like #:make-flags (list (string-append "PREFIX=" %output)) -> #:make-flags #~(list (string-append "PREFIX=" #$output)) <jpoiret>system successfully reconfigured, see you on the other side :) <ngz>jpoiret: let us know, for the sake of humanity, how it is like on the other side… <jpoiret>although i'm cheating a bit: i had been running c-u-f for a while <ngz>I want to move to modular texlive. What would be a good starting point as a manifest? I currently use (specifications->manifest '("texlive")). <ngz>civodul: I do, thank you! <ngz>civodul: speaking of which, is it fine to push inputs simplification changes in master? I noticed many Emacs packages were not updated to the new syntax? <civodul>ngz: yes, just check the amount of rebuild involved (but for Emacs packages it should be fine) <civodul>when you know what you're doing, you can do "guix style --input-simplification=always PKG" <ngz>Yup. I read "Invoking guix style" section already. <ngz>You bet I know what I'm doing ;) <civodul>also, i hope the post above answers questions packagers/developers here may have <ngz>I'm reading it. I assume it'll answer my earlier question about gexps. <jpoiret>civodul: lengthy read, but quite complete :) <jpoiret>so, when modifying/updating packages now, should we also add commits that restyle them, or leave it to big `guix style` commits? <civodul>jpoiret: personally i don't mind smaller commits at this point <civodul>and yes, the post is quite long (perhaps a little boring?), but i failed to make it shorter :-) <jpoiret>no, i think it's pretty good. I didn't know about the intricacies of guix style, but the alternative read seems like a great idea <jpoiret>i could end up using it for personal projects :) <civodul>eventually we could add that to (ice-9 read) <ngz>civodul: nitpick: line 478 , we should enforce usual one-semicolon syntax for end-of-line comments. <rekado_>in English the ‘h’ is before the ’a’ in the onomapoetic expression for laughter. <civodul>i'm never quite sure about onomatopoetic phrases <ngz>civodul: I'm just suggesting to manually change it in the document, for posterity (in both old style and new style example). <ngz>Nice explaination, BTW. <civodul>also, i'd do ";comment" rather than "; comment" <ngz>There is also a strange indentation artifact at line 79 <sailorCat>Hi, I'm looking for a two features. First, there is a package — show all executable files it provides. Actually I can find a dir in the /gnu/storage, then inspect /gnu/storage/hash-package-version/bin, but perhaps there is a more straitforward option. Second, find a package that provides a given command. For instance I expected to find hcitool in the bluez package, but it's not here. What else, except install all <sailorCat>bluetooth-related packages and check them, I can do to find it? <jpoiret>sailorCat: for the first one, you can do `ls $(guix build thepackage)` <rekado_>sailorCat: it’s a common request, but no, at this point there’s no central service that you can query to answer the question of what files an arbitrary package provides. <jpoiret>or rather `ls $(guix build thepackage)/bin` <rekado_>the commands given require the package to be downloaded/built locally. <rekado_>there’s no way to query this remotely <jpoiret>the way I usually find which package an executable belongs to is search for its manpage on the internet, and look for what project it is a part of <abrenon>civodul: strange that no else has noticed but isn't the subject missing at the very begining of the article l'8 «if are to to keep» (I suppose «if *we* are to keep») <civodul>i wrote the first half ~10 days ago and the second half today; maybe that shows... <ngz>civodul: Actually, the document doesn't answer my earlier question: should we also turn #:make-flags (list (string-append "PREFIX=" %output)) into #:make-flags #~(list (string-append "PREFIX=" #$output)), or is that overdoing it? <rekado_>I think it’s a bit funny how we’ve gone from %output to (assoc-ref %outputs "out") to (lambda* (#:key outputs #:allow-other-keys) (assoc-ref outputs "out")) to #$output :) <civodul>seen that way, we have one extra character compared to the initial implementation :-) <ngz>rekado_: it's not always the case, e.g., in `f3' package. Hence my question. But I understand. Now, it's gexp all over the place. <abrenon>error messages aren't always very helpful <abrenon>what could "Wrong type to apply: #<syntax-transformer local-file>" mean ? <jpoiret>going to warm up with the new style by rewriting the pipewire-0.3 inputs <abrenon>I supposed "apply" refers to something being understood as a function when it's not <abrenon>but I have no idea what the syntax-transformer type could be, or if that's a good thing <jpoiret>looks like local-file is not defined at expansion time <jpoiret>syntax-transformer is the type of what syntax objects are bound to (roughly) <civodul>abrenon: right: you can only "apply" a procedure, as in (+ 2 3), where '+' is "applicable", but here 'local-file' is a macro <abrenon>yeah, but I had forgotten to use-module what brought local-file once in a different file while converting my guix.scm files here and there to use local-file <abrenon>and the error message was totally different, I wonder why <nisha>Hello! just reaching out with my findings about the VM crash: I tried the script and it worked. However, when I run the install steps manually it does crash. I upped my ram and CPU cores on the VM and the manual install steps continued for a little longer and then crashed. <jpoiret>so, with the new style being significantly terser, should we still try to keep to the one input per line rule, to facilitate merges? <notmaximed>civodul: Wasn't there a bug report about this-package-input not interacting well with package inheritance? <notmaximed>Unless that has been fixed since then, it would seem that the blog post is somewhat inaccurate. <mbakke>civodul: I suppose the manual link should be for the "devel" manual until the next release <mbakke>eh, derp, the relevant link goes to devel indeed <civodul>notmaximed: hmm i don't remember seeing such a bug report; do you have a link? <civodul>this-package-input refers to this-package, so we should be all fine, no? <apteryx>rekado_: Hi! Thank you for getting berlin up and running again! I'll cherry pick the 3 commits you pushed to core-updates-frozen to master, then delete the core-updates-frozen branch. Is this OK? <notmaximed>The problem was that 'this-package' is the original package definition, not the new package definition that inherits from the old . <jpoiret>notmaximed: doesn't that mean that it is a bug of (guix records) rather? <abrenon>is there a way to somehow "evaluate" a (local-file …) entry ? since I started using it in that repos, it doesn't find my (git-versioned) files anymore <abrenon>is a remote needed or something ? I don't understand what's going on <jpoiret>civodul: the blog post may be missing an example for a non-out package output <civodul>jpoiret: you mean with #$output:foobar? <civodul>perhaps more an example for the manual though, WDYT? <jpoiret>no, rather for a new-style package input using a package's non-out output <jpoiret>eg (list `(,util-linux "lib")), see in gnu/packages/linux.scm <jpoiret>also, I'd like some input (heh) for the one-line-per-input rule wrt the new style <rekado_>the postgres logging to /var/log/messages is a bit excessive <civodul>this-package-input honors lexical scoping so i don't see how it could do something else <civodul>i presume mothacehe might have been testing things? *rekado_ tries to figure out why the machine failed <civodul>jpoiret: ah yes, we could add such an example <rekado_>interestingly we got a clean SIGTERM at 2:55am *notmaximed writes example <rekado_>civodul: yes, all services were orderly shut down <rekado_>acording to the chat logs there were problems at 1:54am <ngz>jpoiret: I think the document explains it at some point. It's up to 5 inputs on a single if that fits, one line per input for greater values, IIUC. <ngz>jpoiret: on a single line* <civodul>rekado_: could you share the /var/log/messages excerpt somewhere? navigating it is... hard <rekado_>also: the root account’s .bash_history has been cleared <cehteh>cleared as totally empty or as in some old content? <civodul>rekado_: it was reconfigured at 02:11am <rekado_>bash_history really shouldn’t be empty <efraim>got to dive into wikipedia and power architecture to add a section to the manual about powerpc-linux existing but being unsupported <notmaximed>Though you gave some numerical computing package as an example, I think <civodul>rekado_: can it end up being emptied if there are concurrent shells running, and/or root runs "reboot"? <notmaximed>It's unsurprising the hello+broken-sed2 is brokenly succeeding, but it is a limitation of this-package-input <rekado_>civodul: I don’t know. I just find it really suspicious. <civodul>notmaximed: ok; so i think it's working as advertised <rekado_>we get a clean shutdown and all traces in bash_history of executed root commands removed. This doesn’t smell right. <civodul>rekado_: perhaps we should have an email thread among people with root access first to sort this out <ngz>Hmmm texlive-fira has a wrong hash. <tschilptschilp23>wow, building the new ungoogled-chromium at updating packages toasts my laptop for 1.5hours already... <abrenon>tschilptschilp23: yes it's usually pretty long <mbakke>tschilptschilp23: I hope you don't need your laptop for the next 8-12 hours <notmaximed>Looking at line 187 of guix/records, it appears 'this-package' refers to the package the thunk is used in, not the package it was originally defined in. <tschilptschilp23>mbakke: it's running anyway, I'm writing from it :) not doing any heavy calculations... <notmaximed>So all is ok, though the substitute-keyword-arguments thing not interacting well is suboptimal <abrenon>what could've been the target ? corrupting binaries ? <notmaximed>Maybe we need some extra syntax like (package (inherit old) (arguments old => (substitute-keyword-arguments old [...])) <ngz>latex-textpos also has a wrong hash... what's wrong with those texlive packages.... <mbakke>ngz: perhaps they were added on 'master' after TeX Live had been updated on 'core-updates'? <vivien>rekado_, you pushed 3 commits to core-updates-frozen after it has been merged, maybe you would want to push them to master instead? <jpoiret>sozuba: FTR, using qemu directly, not virt-manager as in the thread <ngz>mbakke: When %texlive-revision is changed, all hashes need to be updated in tex.scm? <jpoiret>did you try to enable the interface and manually dhcpcd on it? the qemu default network configuration runs a dhcp server on the virtual interface <ngz>mbakke: It makes sense, but ouch nonetheless. <samplet>It looks like emacs-libgit fails to build on master. Is it just me? It seems it can’t find the “emacs” input. Could be a problem with the simplified inputs. <tex_milan>Seeing all the troubles, it looks like ability to seed build packages automtically is needed. Do you remember bittorrent? :) <sozuba>jpoiret thanks for responding again, as much as I am aware, I am not running qemu through virt-manager. But incase I am wrong, could you please let em know how to know if i am using virt manager?. <samplet>It fails to build in the ‘make-autoloads’ phase, when ‘(assoc-ref inputs "emacs")’ returns ‘#f’. <sozuba>jpoiret, I tried yesterday as per the docs on manually enabling network, interfaces seems to be up and i try to enable dhcpcd as well. Then gave up. I will try again now <jpoiret>sozuba: as long as you are running the qemu command line, you are not using virt manager <jpoiret>what happens when you `dhcpcd` on the interface? does `ip addr` report an IP address afterwards <ngz>samplet: Ouch. Subtle problem. make-autoloads expects "emacs" label. <samplet>I thought it might work with "emacs-no-x", but no luck. (I haven’t learned the new system yet! :p) <ngz>Would it make sense to change (string-append (assoc-ref inputs "emacs") "/bin/emacs") into (search-input-file inputs "/bin/emacs") in `make-autoloads'? <jpoiret>yes, although I think it would require a rebuild of every package using the emacs build system <ngz>Not a biggie. Emacs packages are very light. <sozuba>jpoiret, in that case i am running qemu directly. The manual talks about "dhclient -v interface (eth0)".. results in IP 10.0.2.15. dhcpcd (tried, says unknown command). <ss2>no, all good, was on my side. <jpoiret>uhm, right it's `dhclient`, my bad :) <samplet>Ah. I see the commit came from 44 minutes ago. I guess it’s not my lucky day today! :) <sozuba>i tried to ping, unknown host. I think that;s due to the chosen interface not supporting icmp? <jpoiret>have you tried using wget (or curl, can't remember which one is included in the install image) to try to reach a random website? (ping might not work, because ICMP requires priviledges) <jpoiret>although unknown host is more of a DNS issue <jpoiret>no problem. You might want to check if you have a DNS server configured (your router might not have a default one, and so dhclient might not pickup any) <ngz>samplet: I need to go. Hopefully, the issue is fixed. <samplet>Me too. I’m sure one of the many Magit users will do something. <jpoiret>samplet: too bad, I haven't yet made the switch to guix emacs packages, still using straight.el <samplet>I didn’t use Emacs nearly as much until switching to Guix, so I didn’t ever have to migrate a config or anything. <abrenon>good luck with the post mortem ! I hope it's not too bad <jonsger>Hm starting with firefox 95, they wanna have WASI (webassembly) which we need to package. I hope it will not require to much work. At least it's only optional ATM... <sozuba>jpoiret it works after configuring dns server, thanks <jpoiret>no problem, glad it's working for you :) <sozuba>jpoiret, thank you :). Although I feel this is probably a bug and should be corrected, so as to be helpful to people. after connecting, going through the guided installer cases the same issue. So I am going to go ahead with the manual installation for now, but will submit a bug report. <jpoiret>sozuba: for sure, I will open a bug on the installer, hopefully we can add this feature for 1.4 <jpoiret>it should just be a matter of checking for and optional set dns servers manually <jonsger>btw congrats @all and @maintainers to the core-updates-frozen merge :) <apteryx>seems the make-autoloads phase was fixed by 6717ce28d0; thanks to Nicolas! <apteryx>jonsger: I feel that's probably going to translate into more bundled rust crates. <jpoiret>anything against patchsets that improve related packages at the same time? i have a couple of patches updating pipewire, xdg-desktop-portal-wlr, flameshot and adding wireplumber <jpoiret>I'd like to avoid opening multiple issues for that, and the leaf changes require the others version bumps <apteryx>it's OK to send related patches (commits) to the same guix-patches issue (preferred, actually, to have the full context) <apteryx>ah, I've reached that emacs-libgit failure *mbakke just used 'git format-patch -U' for the first time, neat <apteryx>(assoc-ref inputs "emacs") returns #f in the build phase of emacs-build-system.scm <mbakke>sometimes you want applying a patch to fail if the surrounding context changes, even if your one-line hunk could be auto-merged <civodul>though often i find it annoying that "git am" is stricter than "patch" <mbakke>civodul: git am -3 to the rescue :) <civodul>i always end up doing "git am --show-current-patch=diff|patch -p1" in such cases <mbakke>that pipe to 'patch -p1' is a neat trick, I've always manually merged when am fails... <dissent>hey guix major update today. i can't upgrade any packages or install anything. <jpoiret>what do you mean by "can't upgrade any packages"? what fails exactly? <apteryx>civodul: is it ok to lookup emacs in the build phase amongst inputs? (thinking about cross builds) <ngz>uh oh. It looks like I broke Emacs packages. <ngz>apteryx: No it doesn't work apparently =/ <ngz>(search-input-file inputs "/bin/emacs") raises the following error: In procedure string-append: Wrong type (expecting string): #f <apteryx>works here (I built emacs-libgit with the change) <dissent>jpoiret: i'm sorry, that wasn't correct. the packages that give me trouble are network-manager-applet deluge gtk+ webkitgtk gnome-keyring libnotify poppler libsoup libappindicator zathura telegram-desktop libx11 xorg-server. <dissent>i'm getting the upgrade both or remove one from the profile reponse. <ngz>Ooohh. OK. I understand. <jpoiret>dissent: when did you guix pull? I had a problem with python2-gobject <dissent>jpoiret: this started happening last night. <ngz>apteryx: I made the very same change in `make-autoloads', in fact we were talking about two different changes. <apteryx>yes, I made this change looking at 'git log' and seeing you had fixed the same problem for another phase, thank you! <podiki[m]>sneek: later tell @CarDio I saw you asked about haskell-gi, actually I packaged it (working!) but isn't in guix just yet <ngz>apteryx: Unfortunately, my fix was incomplete. Thanks for fixing the fix ;) <dissent>jpoiret: i have been... 2 new commits just came in though. yes I exercised some rollbacks today. excellent feature. renders btrfs redundant, no? <unmatched-paren>i'm back at my computer now, so i can reconfigure to the new merge :D <ngz>apteryx: I think emacs-xyz.scm is now ready for a massive re-styling! <jpoiret>dissent: do you know what exactly fails? <apteryx>ngz: hehe! it's a good timing if you want to do it (it has to rebuild them all anyway) <apteryx>do others sometimes see: "guix package: error: got unexpected path `/gnu/store/some-path`" ? during substitution? <apteryx>retrying usually works, so it seems load/network related <apteryx>civodul: when you have a chance, could you save your work and retry: "35560 normal Ludovic Courtès GNOME Shell 3.28 crashes and suspends to RAM (!) after ejecting removable media". That's a ridiculous one. <rekado_>apteryx: fixing this will break my workflow <civodul>i haven't seen it since then (on my partner's laptop) <jpoiret>dissent: looks like deluge is broken <podiki[m]>with the hit or miss of suspend to ram, maybe that was the only way to do it consistently for someone :) <apteryx>all these 'guix pull' bugs leave me clueless. what should we do about them? <rekado_>close them if they are not actionable <efraim>Let's tell people to try again instead of telling them to open a btig report <apteryx>52145 is one, but this one got stale so the action is easy (close) <jpoiret>it wants to propagate `librsvg` instead of gtk+'s `librsvg-bootstrap` or `librsvg-2.40`, so it's bound to cause problems <nckx>Maybe you're building more of it locally? (It does a remarkable amount of work for a ‘mere pull’.) <florhizome[m]><dissent> "jpoiret: i have been... 2 new..." <- I don’t think they are redundant ;) there might be cases where you prefer one over the other, though. <jpoiret>dissent: now, that one doesn't build at all, could you post the build log in a paste? <dissent>I remove bpytop and another issue is with fontmanger. <podiki[m]>pygtk was supposed to be fixed? (right before the ci crash) and worked for me at that point at least <unmatched-paren>oh, i'd guix pulled yesterday before the ci crash, so i'll pull again <unmatched-paren>Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed! <jpoiret>dissent: fontmanager will be easy to fix, however bpytop has a problem with python's sanity-check phase, which I don't know the intricacies of <jpoiret>could anyone pitch in? I'll fix fontmanager <apteryx>not prime estate though: No dependents other than itself: bpytop@1.0.67 <AwesomeAdam54321>Yay, I managed to set up GNU Shepherd as a working init system on a foreign distro <unmatched-paren>that sounds like exactly the kind of thing i wouldn't have dared doing before guix and its rollbacks <apteryx>seems the python sanity-check phase gets broken by guix styled python packages <apteryx>so to unbreak bpython you'd have to unstyle it <civodul>apteryx: could you collect issues of that sort (Python & Emacs)? <apteryx>making python-build-system label agnostic is going to cause a mass rebuild. We can batch these changes and try them in the version-1.4.0 branch <civodul>i'm surprised because the CI evaluations yesterday didn't show anything bad <unmatched-paren>why's /gnu/store/--8<--guix-packages-base.drv taking so long to build when i pull? <rekado_>unmatched-paren: it compiles all of gnu/packages/*.scm <rekado_>if you’re unlucky you’ll have to do this locally <rekado_>usually, though, ci.guix.gnu.org will finish building this before you have to <apteryx>civodul: perhaps I spoke too soon; investigating about that bpytop failure <rekado_>and then “guix pull” just downloads the compiled stuff <apteryx>the sanity-check.py script got called like: "python" "/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py" "/gnu/store/0irzla32qarhqja1zsbyjhan8qbm6h9w-bpytop-1.0.67/lib/python3.9/site-packages" failed with status 2 <apteryx>and failed because: nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py: error: unrecognized arguments: /gnu/store/0irzla32qarhqja1zsbyjhan8qbm6h9w-bpytop-1.0.67/lib/python3.9/site-packages <jpoiret>dissent: I just sent a fix for fontmanager, but it's not pushed yet. It did build, and seemed to work when I launched it, but I didn't test anything else <lfam>That's weird unmatched-paren <lfam>I wonder where that package comes from <nckx>unmatched-paren: ‘Try’? They should even have succeeded. <lfam>Ah, I thought we were on 40.0 <lfam>Unfortunately it failed to build <nckx>A mutt of 41 & (possibly mostly) 40. <lfam>builder for `/gnu/store/3zv14c2bzqfx35qlrhrmzx8cl8z0gw8n-webkitgtk-with-libsoup2-2.34.1.drv' failed with exit code 1 <nckx>raghavgururajan will know more. <apteryx>about bpytop I guess it does some tricks to use argv[0] and then doesn't like that it's invoked through sanity-check.py <apteryx>I don't see how this could be something new; was it working on c-u-f before yesterday? <podiki[m]>i've gotta run, but looks like the CI hasn't built anything since the crash last night? <podiki[m]>(last guix commit is from right before, the pygtk one, according to the frontend) <nckx>lfam: That's not reproducible then. What's the error? <apteryx>civodul: nevermind about what I wrote earlier with sanity-check; no issues there :-0 <lfam>"%exception #<&invoke-error program: "make" arguments: ("-j" "24" "-j" "24") exit-status: 2 term-signal: #f stop-signal: #f> " <unmatched-paren>it might be because i salvaged a guix 1.3.0 out the store to get around the dynamic linker errors on the latest guix? <rekado_>unmatched-paren: “guix pull” has its own profile <nckx>Error copying file (if different) from "/tmp/guix-build-webkitgtk-with-libsoup2-2.34.1.drv-0/webkitgtk-2.34.1/Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_implementation.py" to "/tmp/guix-build-webkitgtk-with-libsoup2-2.34.1.drv-0/build/JavaScriptCore/Scripts/builtins_generate_separate_implementation.py". <nckx>OK, didn't know if you'd seen it. <lfam>I did after I pasted the incorrect line :) <lfam>Anyways, it's weird. There is a substitute for this derivation *apteryx drops the investigation on bpytop -> something to do with wrapper script / arg manipulation I guess <nckx>I'm glad I'm not the only one who didn't grok that lfam. <nckx>That one's a real error, at least: launchtaskbar.c:71:10: fatal error: gdk-pixbuf-xlib/gdk-pixbuf-xlib.h: No such file or directory <jpoiret>dissent: any other failures you're aware of? I've just sent a patch fixing the deluge build as well. <NicholasvonKlitz>Is there any quick way to spin up an ad-hoc impure build system, say `cargo-build-system`, where all programs necessary to hack in that environment are there, but instead of dependencies coming from guix, they are pulled in from the language's native package manager, say `cargo` and crates.io? <jpoiret>NicholasvonKlitz: isn't just cargo sufficient for that task? <lfam>Are there any timestamps on those failed builds? <NicholasvonKlitz>similar to `guix shell` but without the needing to manually specify all the packages necessary to build an average c++ or rust project <nckx>Yeah, it ends in python2-pygtk <nckx>I got the same error building it on my laptop yesterday. <nckx>I could work around it by dropping pdfarranger. <NicholasvonKlitz>jpoiret: It might be a cargo-guix specific bug, but when I try to build outside of a cargo-build-system and a crate depends on gcc, I always just get `error: linker `cc` not found` even when gcc-toolchain is install, which leads me to believe environment variables are not set properly <nckx>It holding GNOME hostage is a problem. <jpoiret>uhm, i reported the python2-pygtk failure yesterday, and when I guix pulled a couple of hours ago and rebuilt, it was working <nckx>NicholasvonKlitz: gcc-toolchain doesn't provide a ‘cc’ symlink. Does cargo respect $CC? <nckx>You can set it to gcc then <unmatched-paren>anyway, i've reonfigured now; see you in the promised land (for real this time!) <nckx>unmatched-paren: See the ‘raw’ in your last URL? That's sushi. *nckx apologises profusely, got 2h of sleep. <jpoiret>this is morphing into c-u-f sprint v2 <NicholasvonKlitz>nckx: that solves it. I think it could be a productivity boost if there could be a pure profile that includes rust, cargo, pkg-config, openssl, etc. by default with environment variables properly set <NicholasvonKlitz>* pkg-config, openssl, gcc-toolchain, etc. by, * properly set. So you could just do something like `guix shell rust-app` and start working on most packages. <nckx>Possibly! I don't hack in rust so it's better if you propose all details directly to bug-guix at gnu dot org 😉 <unmatched-paren>ok, maybe it's an extension issue; i'll upgrade on the vt and remove my extensions <nckx>Or maybe guix-devel at gnu dot org instead, NicholasvonKlitz. Even if wishlist bugs are acceptable it's more of a discussion IMO. <apteryx>NicholasvonKlitz: that wouldn't be very Guixy though; pulling extra deps just to be able to build C things will not please everyone <unmatched-paren>gnome likes to spontaneously crash when it doesn't like an extension <apteryx>when building purely Rust things doesn't require them <unmatched-paren>ohno, upgrade is pulling in firefox source, i have a bad feeling that it'll try to rebuild icecat :| <apteryx>for the linker thing, perhaps it could be improved by explicitly using 'linker' in cargo.toml, something I discovered on the 'wip-cross-built-rust' branch or similarly named <nckx>I still have 12 rusts to bootstrap. <apteryx>the first one (1.40) takes 1 h 30, the others about 10 minutes each on a fast machine. <apteryx>but... how did we trigger a rust rebuild? <lfam>Maybe we never built it? <apteryx>NicholasvonKlitz: I'm not sure how exactly, but it seems it does implicitly <lfam>Or like, maybe Rust was garbage collected <nckx>That would be the cherry. <apteryx>/gnu/store/13wxi7vjnvyk9xzqav3pls3vignqz2k1-rust-1.54.0 <unmatched-paren>okay, gnome is still misbehaving, i'll try guix upgrade --do-not-upgrade=icecat and just settle for epiphany for a bit <nckx>If you took my ‘I'm still bootstrapping rust’ to mean ‘it's missing on berlin’, I apologise, that is not the case. I build my own packages. <apteryx>ah! so you had not built c-u-f yet, right? it shouldn't have changed <nckx>Indeed, not on this machine. <unmatched-paren>it probably does need upgrading; when i tried to `guix install gnome-shell-extensions` to get the new GUI, it complained about cairo and told me to update it <nckx>Rust packages (not compilers) can be quite zippy. <podiki[m]>CI (at least frontend) to me not showing builds after last night (pygtk commit) <lfam>Yeah, it seems that Cuirass is paused on CI <zimoun>I have machine running old CentOS (argh dam daily job!) with 2.6 modified kernel. Do you think it is possible to somehow “guix pack linux-libre” and unpack ? Tweaking some conf files? <jpoiret>lfam: sorry for the half baked patch. Looks like the only kept reference is an auto-added GI_TYPELIB_PATH in the wrapper launcher for the python script <lfam>zimoun: At least one thing will not work, or will need to be adjusted. The kernel config option CONFIG_MODPROBE_PATH="/run/current-system/profile/bin/modprobe" <lfam>zimoun: I don't know if it does anything while building, or if it can be changed after building and before booting <lfam>jpoiret: No need to be sorry, it's what review is for <lfam>I'm not very familiar with GI / gobject-introspection. Do you know what is the right thing to do here? <jpoiret>I just think that the setup.py crams all known GI repositories in the wrapper, so I think it will be safe to remove <lil>Hello! Please share commit with builded telega, with current commit guix build php <lfam>Alright. Can you test the resulting deluge package, jpoiret? I'm not so familiar with deluge either <jpoiret>me neither. The last one looked okay though, but I didn't test the torrenting part since I only touched UI-related stuff. <jpoiret>but I can test the basic functionality, sure <lfam>I just decided to look more closely at your patch because I know we are trying to phase out the C librsvg <lfam>zimoun: I know that Debian has kernel building scripts built in to the kernel source code. Like, you can do `make bindeb-pkg`, and install what it creates. Maybe there is something similar for RPM? <lfam>I sometimes take the Guix kernel config and build Debian kernels with it. I have to adjust MODPROBE_PATH and change the compression algorithm used by switching from MODULE_COMPRESS_GZIP to MODULE_COMPRESS_XZ <luis-felipe>Hi, anyone else getting this errors when recofiguring the system? <sneek>Welcome back luis-felipe, you have 1 message! <sneek>luis-felipe, nckx says: Thank you for making it. <luis-felipe>guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet. <luis-felipe>substitution of /gnu/store/13wxi7vjnvyk9xzqav3pls3vignqz2k1-rust-1.54.0 failed <luis-felipe>guix system: error: corrupt input while restoring archive from #<closed: file 7ff7915452a0> <lfam>luis-felipe: Hm... does the error happen again if you run the command again? <unmatched-paren>gnome-shell-extensions-app is crashing and apparently is written in javascript, which means extra pain :) <jpoiret>javascript? do you mean GJS, the Gtk abomination layer over JS? <lfam>luis-felipe: Can you run your command again, but with --dry-run, and then find the .drv file that corresponds to rust-1.54.0? <zimoun>lfam, thanks. I will give a look. :-) <jpoiret>is string-prefix? standard guile, an srfi, or rnrs? <nckx>It does not require any module imports. <ngz>Gah. emacs-guix: 1, me: 0. I couldn't restyle it completely. <unmatched-paren>i just noticed that i'm still on gnome xorg... is there a way to change it now? (there's still no gnome wayland option in gdm) <jpoiret>unmatched-paren: you need to have wayland? #t in your gdm configuration <unmatched-paren>after adding wayland? #t to my config, reconfiguring, and logging back in, i'm still in xorg <jpoiret>is there any way to use (guix search-paths) from the build side? <jpoiret>I get "no code for module (guix search-paths)" <apteryx>no, it'll probably pull the world unless it's in the (guix build ...) prefix <jpoiret>there's a comment in it saying that some function is here because it should be used in build side code <apteryx>ah yes, it's used in like every build system, so it should be safe <jpoiret>heh, I wanted to use string-tokenize*, but I'll just use string-split, it will work properly <jpoiret>unmatched-paren: the devel manual does talk about GDM wayland <jpoiret>but there's nothing about wayland gnome, because there isn't anything specific to it iirc <apteryx>ngz: by the way, you could do the whole module at once for package style changes <ngz>If I make a mistake, it is easier to revert this way, isn't it? <apteryx>I'm saying this mainly looking at the 'git log' story; I don't think we want 2000 commits for 'guix style 'changes :-) *apteryx deleted core-updates-frozen <minikN>Hello, when making a change to doc/guix.texi. How can I build the docs so that I can view the change (preferably as html)? <lfam>Similary `make doc/guix.info` <ss2>lfam: thanks for the fix! Was too late to answer last night. <unmatched-paren>should the gnome wayland session's Exec look like this: "Exec=/gnu/store/b0fifkclg2vvq4y1grkp22qzrmha46js-gnome-session-40.1/bin/gnome-session"? <unmatched-paren>hm, looks like both the xsession and the wayland-session have the exact same Exec line <unmatched-paren>looks like you do --session gnome-wayland in the gnome-session command <nckx>NicholasvonKlitz: Share your package. <lfam>"Wrong type (expecting pair): #<package graphene@1.10.6 gnu/packages/gtk.scm" <lfam>It's unusual to see the package@version syntax in this context, right? <lfam>I thought that @version syntax was only for the user interface <nckx>lfam: It's how package objects are pretty-printed. <nckx>scheme@(guix-user)> graphene <nckx>$1 = #<package graphene@1.10.6 gnu/packages/gtk.scm:2395 7a95c22e9790> *nckx ・゜゜・。。・゜゜\_o< QUACK! <florhizome[m]>I thought it was bc I was using different wayland/wayland-protocols packages but now these are updated <unmatched-paren>ah, looks like --session uses $GLOBAL_DATA/gnome-session/sessions/... instead of xsessions/wlsessions <florhizome[m]>What’s the difference between having wayland-protocols in native inputs and in normal inputs ? I normally put them in native, but these packages don’t ... <lfam>native-inputs are dependencies that are only used while building <lfam>"The distinction between native-inputs and inputs is necessary when considering cross-compilation. When cross-compiling, dependencies listed in inputs are built for the target architecture; conversely, dependencies listed in native-inputs are built for the architecture of the build machine. <lfam>native-inputs is typically used to list tools needed at build time, but not at run time, such as Autoconf, Automake, pkg-config, Gettext, or Bison." <lfam>I don't know anything about wayland so I don't know if it's right or wrong <florhizome[m]>wayland-protos definitely has functionality that is especially used at buildtime like wayland scanner and <lfam>Note that the distinction only matters for cross-compilation <unmatched-paren>the .desktop files of the x session and the wayland session look _exactly_ the same <lfam>Nothing will break if you put a dependency in the wrong category but are not cross-compiling <florhizome[m]>Both sddm and enlightenment fail to find their wayland server. <florhizome[m]>So basically there should be no libraries that are not propagated inputs or packages themselves? <lfam>Not sure what you are asking <lfam>Everything in Guix is a package <lfam>I think we just need to find some common terminology :) <florhizome[m]>Actually: All files are either from directly installed packages or propagated inputs <jpoiret>unmatched-paren: gnome-session --wayland on a tty should pseudo-work iirc <jpoiret>but I'm not even sure. GDM should work for sure, that's what I mostly tested <jpoiret>ehm, no, gnome-shell --wayland rather, sorry <jpoiret>florhizome[m]: what exactly is not working? I could help debug it <acrow>Hmmm... I don't understand why git clone <guix.git>; ./bootstrap && ./configure ends with cannot find libgcrypt. guile-gcrypt as well as libgcrypt are in my profile? <nckx>I got that when [I deduced that] my guile-gcrypt was older than my guix. <nckx>Upgrading everything made it work, at least. <acrow>Well, no luck so far. I've started a new shell under a tmux session and also logged into another terminal session but each returned the same error. I guess I'll need to duck out to allow a complete system restart. Just a few minutes. <florhizome[m]><jpoiret> "florhizome: what exactly is..." <- sddm is just not starting (i’m left on the ttyand just login from there...) and enlightenment as well. Can send you logs. <roptat>civodul, first sentence "it's occasionally necessary if are to keep" <roptat>civodul, "Packaging in Guix are" -> Packages *lfam learns about the `last` command <roptat>civodul, and a repetition: "to allow build-side code to allow build-side code" <roptat>civodul, not sure what get at means: "to get at an input’s file name" <acrow>The problem persisted across a full system reboot. <ss2>I'm getting a “Git error: unable to parse OID - too long” while trying to reconfigure. <apteryx>acrow: perhaps try 'rm guile' and ./configure again <lfam>ss2: Can you tell what it's doing? Is it trying to build a package? <roptat>civodul, "we can take advantage of gexps in package definitions will still supporting the common idiom" -> while? <ss2>lfam: I'm not so sure yet. The host https://paste.rs/g6n, I got them on two independant hosts. It could do with my declarations. Investigating this now. <ss2>They both built their profiles, then exited. <lfam>Even google doesn't help <lfam>It sounds like an incorrectly specific package definition, where the Git commit hash is too long <lfam>I mean, incorrectly specified <ss2>reconfigure with vanilla config is fine. Need to do some house cleaning. :) <ss2>copy pasta for beginners. The hash is missing a character. <jpoiret>lfam: oh no, i just went down the systemd hole <jpoiret>alas, i'll stop and go test sddm instead <acrow>apteryx: :) I'll re-read the docs and try again from the top. <unmatche1-paren>jpoiret: shouldn't gdm with wayland enabled launch gnome-shell with --wayland by default? <jpoiret>well, gnome-{session,shell} work in convoluted ways <jpoiret>you can enable debug? #t in the gdm configuration and look at /var/log/gdm/greeter.log or /var/log/debug ***unmatched-paren is now known as Guest4770
<jpoiret>you'll see what is happening (i don't guarantee understanding it though. I don't) ***unmatche1-paren is now known as unmatched-paren
<unmatched-paren>since the last gnome fiasco a while ago back on 3 i turned that on before, so i'll just less the logs <ss2>If I recall right, enabling debuggin in gdm will log to ~/.cache/gdm/session.log too. <jpoiret>among all the ways gnome-shell/session can detect what kind of session it should run, I think XDG_SESSION_TYPE=wayland is the most obvious one <unmatched-paren>i'll try it on the tty again later, but right now i'm building icecat in the background and i don't want to lose my place <unmatched-paren>how long does icecat usually take to build? on an average 4-core laptop? <unmatched-paren>i'm not sure checking the ci's timestamps will give me a time representative of a laptop :P <lilyp>I'd say anything between 0.5 and 2. <f1refly>is theres something special I need to do to get my clipboard working? I'm running herbstluftwm, but copy/paste doesn't even work when piping things to xclip <lilyp>btw. I love how our new backtraces look :) <tex_milan1>how to know if some package is available on substitute server? I want to update, but it always wants to build nss with takes very long time (doing some tests). <jpoiret>there are two consecutive documentations for sddm-configuration in the manual <jpoiret>florhizome[m]: at least it's not my fault, only worked on GDM :) I'm starting a barebones sddm vm <jpoiret>did you guix pull & reconfigure since yesterday? <tex_milan1>got like 50new packages and 64updated. is this the merge of f-c-u? <jpoiret>sddm starts as expected on a guix system vm for me florhizome[m] <jpoiret>I have to say that it looks pretty nice <tex_milan1>for me switching once from gdm to sddm just broke gdm. going back results in black screen, gdb seems running but display is black and unrespositive <jpoiret>can you even have multiple DMs running at the same time? <tex_milan1>not using them both, just reconfiguring it form sddm to gdm broke gdm... <jpoiret>hmmm, should be expected, kind of, since they have the same shepherd service name <tex_milan1>like once you try sddm you cannot go back to gdm <jpoiret>but yes, pulling the whole gnome-shell tree is annoying <jpoiret>so sddm works for me, sway won't launch but that's because by default it won't launch on a software_renderer backend <jpoiret>i looked up how to use hardware accel under qemu, but it looked annoying and I could just start sway with a flag anyways <ison>Does anyone have pipewire working? It seems the latest version is missing the "pipewire-media-session" binary. It existed prior to this update and was working. I thought it was required unless you have an alternative like WirePlumber, but there is no wireplumber for guix yet as far as I know. <jpoiret>ison: I am literally writing the patch cover letter for such a patchset <jpoiret>includes pipewire update to 0.3.41 and wireplumber <ison>jpoiret: Ah ok, good to hear. Thank you. <jpoiret>my motivation was to get screen sharing to work properly on wlroots-based compositors <ison>I have no specific need. Just testing it. I still have pulseaudio installed so for now I'm just falling back to that. <jpoiret>we're a long way from supporting pipewire out of the box though <vdv>is pulling or reconfiguring faster with the c-u-f merge? <jpoiret>I don't think there should be any noticeable difference <vdv>or does c-u-f just contain package updates? <jpoiret>well, package updates, service updates, patches and the like <unmatched-paren>like `guix style`, which is a new command to style-check your package definitions <ngz>I hereby declare emacs-xyz.scm as (almost) new-style compatible. <podiki[m]>glibc got an ld cache per package, that might be faster <podiki[m]>or at least less disk searching for libraries <phodina[m]>I'm trying to add Rust package to rust-apps.scm. But the package requires gcc-toolchain as an native-input. <phodina[m]>Adding commencement module to satify the import causes strange guile errors with unbound variables. <phodina[m]>I've tried to add just the use-module statement and I still get the errors. Is it possible there is some sort of circular dependency created? <the_tubular>Is this known : /builder for `/gnu/store/dvzk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv' failed to produce output path `/gnu/store/v5yajfs2y28wl3np4v4y6pr9lwgyadd9-guix-package-cache' <the_tubular>build of /gnu/store/dvzk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv failed ? <jpoiret>the_tubular: are you using other channels? <podiki[m]>(I've hit that too, but think it was from outside channel with some conflicting package or something) <the_tubular>I planned to create my own channel, but I haven't done it yet <the_tubular>View build log at '/var/log/guix/drvs/dv/zk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv.bz2 <podiki[m]>probably because they are kept in the store and text compresses nicely? <podiki[m]>(you can view old build logs which is handy) <Brandong[m]>But I am also seeing the same. guix-package-cache log shows: <Brandong[m]>Generating package cache for '/gnu/store/xl3q58vzsakzwpr28ajc3cmhl2iycn6z-profile'... <Brandong[m]>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (modify-phases)) (value #f)) <podiki[m]>Brandong: yeah, that looks like something referring to a package that doesn't exist (anymore) <raghavgururajan>Holy Crap! Calibre broke. The ebooks are rendering weird. No texts, only images. <nckx>Doesn't that (above) mean that modify-phases itself is undefined? <Brandong[m]><podiki[m]> "Brandong: yeah, that looks..." <- As in a package in my profile? I only have the official channel enabled. Is there a smart way for me to figure out what package causes the problem? <jpoiret>the recent emacs-xyz.scm commit seems to have broken it <jpoiret>i'm running make in a local checkout and it's giving me warnings <jpoiret>hmmmm, the arguments field of emacs-shroud is borked <jpoiret>only uses (list ) instead of quoting the whole contents <nckx>That would explain Brandong[m] error nicely. <nckx>Since mod-pha isn't defined on the host side. <jpoiret>looks like `guix style` just trampled all over it <jpoiret>uhm, 88097dfba765bacb809edae7639fc3ed2dead297 as a whole looks borked <jpoiret>it transformed all (arguments `(#:things ...)) into (arguments (list ...)) <apteryx>I reproduce the problems reported above <civodul>roptat: thanks for reporting all the typos in the blog post, looks like there's no shortage of them <roptat>civodul, haven't finished reading, I'm too tired <apteryx>jpoiret: seems to be at only 2 places (2 packages); lines 1313 ad 12272 <apteryx>shouldn't be too hard to fix without a revert <jpoiret>oh. i didn't realize the others were using g-exps <apteryx>guix style will finally force us into proper G-Exp understanding ;-) <jpoiret>yes, others are having the same issue as well <jpoiret>a very recent commit introduced this, people are on it as we speak <phodina[m]>What is the syntax to specify different output of a package in the new input syntax? <apteryx>I'm looking at emacs-shroud; how are we supposed to use (assoc-ref emacs:%standard-phases 'expand-load-path) in the #:phases arguments? <apteryx>the emacs: prefix is bound via the #:modules argument <jpoiret>aha, do #:modules directly translate to a (use-modules for the gexp) as well as a with-imported-modules outside of it or not? <nckx>I don't mind, but I wonder why (list `(,foo "bar")) instead of (list (list foo "bar")) ? <jpoiret>emacs-shroud works for me by just adding #~ apteryx, so i guess the prefix does work that way :) <jpoiret>nckx: how would scare non-guilers without a quasiquote otherwise? <nckx>At least it doesn't invite typing ("foo", bar) anymore. <apteryx>that would have clearly wrong, as it should have been ("foo" ,foo) <nckx>How will we document which package contains libuuid, FOR THE CHILDREN? <nckx>["foo", foo] actually works, that's horrible. <nckx>(use-modules (break racket brackets)) <nckx>src/vdagent/x11-randr.c:985:21: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead [-Werror=deprecated-declarations] <nckx>Breaking guix system vm gnu/system/examples/vm-image.tmpl <nckx>Anyone already claimed that bug? 