IRC channel logs
2023-04-14.log
back to list of logs
<lfam>I confirm the problem aitzkora <lfam>Looks like the server that hosts ci.guix.gnu.org and logs.guix.gnu.org is not working <lfam>Probably some other services are offline too <negligiblebeans>Is it possible to use a locally stored channel? (For development purposes). i.e. Rater than specify a git url, specify a filepath to a git repo <sysfu>anyone recommend a minimalist git hosting service? I need a place to stash my config files, that's it. So ideally, there's no public web accessible interface, no captchas, 2FA support for yubikeys. So for looks like githuman and maybe paid sourcehut are the leaders. Don't want to mess with self-hosted for now. <sysfu>I don't any issue tracking, none of that. <bjc>i use cgit. it's ugly as hell and does almost nothing. i love it <sysfu>bjc: Beautiful! Never heard of that, but 'ugly as hell' descriptor is...well what's the opposite of a red flag, a green flag? will check it out thx. Looks like catgirl code hosting uses cgit-pink. <unmatched-paren>sneek: later tell davidl: oh, also, change %my-channel-directory to the appropriate directory :) <unmatched-paren>sysfu: oh, i didn't see "don't want to mess with self-hosted for now :)" sorry <sysfu>unmatched-paren: No worries, I might stand up something in a TrueNAS jail at home. My thinking was where can a skinflint who wants zero features stash some homedir and etc config files for free. <sysfu>Make you wonder if there are git hosting services that don't even have a web site, say you signed up via SSH only. And email is optional for account recovery. <mekeor[m]>negligiblebeans: for a local guix channel, i use (url "/home/user/path/to/my/guix-channel") without any file:// and it works <mekeor[m]>you need a host for cgit and gitweb though. i though sysfu is looking for a host, not a software. <sysfu>mekeor[m]: i was looking for a host. I don't suppose there's any market for the kind of host that I want however. Maybe notabug might work. githuman needs a blockstack id to login. <mekeor[m]>in order to work around the issue with ci.guix.gnu.org, i replaced (channel-with-substitutes-available %default-guix-channel "https://ci.guix.gnu.org") with just %default-guix-channel in my ~/.config/guix/channels.scm <sysfu>mekeor[m]: thank you, that's pretty much what I was looking for. The 'why did you do this?' section speaks to me. <sysfu>I has identified sourcehut as a top pick but wasn't ready to shell out for paid service just yet. <svl>Unscheduled downtime? <svl>The servers. Is it maintenance or an issue? <TylerWolf[m]>If there was maintenance I would think something would be in the IRC description. Hopefully it comes back online soon. <mekeor[m]>many guix-maintainers live in europe where it's quite late now... <svl>That's fine I'm not doing anything else tonight tbh <Guest19>I guess *.guix.gnu.org is down again <lfam>TylerWolf[m]: The IRC welcome message says "The server is DOWN" <lfam>AFAIK it's not on purpose <TylerWolf[m]>lfam: Oops my bad, when I previously logged on it hadn’t been there, and my mobile client didn’t show it anymore. <lfam>Yeah, I just added it ;) <lfam>Time to test working with no substitutes :) <indio>Hi. Is there any place to read about the differences of GuixSd and GNU Guix on another GNU/Linux? <indio>Just out of curiosity, but couldn't find any links. <lfam>Hm, I'm not sure there's like a list of differences. But we can answer questions you have here <indio>Ok. I'll write them as I can formulate them. Most importantly, I like the feature of being able to reintall my whole packages and configurations from a single configuration file. Is this possible in Guix in any GNU linux distro, such as Trisquel? Or do I need GuixSd for that? I don't care if I have to install a basic Trisquel first, to be able to reproduce the Guix state. <Guest19>is it possible to define .xsession with guix home? <indio>I hope I made sense, otherwise I'll tty to ask again later. <pkill9_>you can use manifests to instlal a collection of packages to user profile <indio>Is there a single, or a main big config file in GuisSd? <indio>That reconfigures the whole os, even from scratch? <indio>I read that somewhere and it did stick. <indio>Otherwise, that would be my side project. LazyOs. <indio>I know, not easy. But I toy with the idea due to fears of having to reinstall my gnu distro." <indio>I could live within user profile. But I'd need to be able te rebuild the whole thing with a single command and my data. <oriansj>indio: there is no need to fear reinstalls; especially if you have guix and proper backups <indio>guix package manager, right? <lfam>indio: Yes, there is a main config file in Guix System (we stopped calling it GuixSD a few years ago) <lfam>Users can still do their own packages that are not covered by the main file, but they don't have to <indio>oriansj: I once spent 1 week reinstalling windows 10 from scratch. I logged everything. I cry when I remember it. I know with GNU/Linux is bbetter. Yet traditional distros takes at least a day or two, from scratch. I'm willing to try the state of the art, because I need to save time. <oriansj>indio: Guix from zero to fully setup is 20 minutes for me, would you like to see my new system setup procedure? <indio>I'd like to keep using my current distro, but try Guix package manager to be able to reproduce the bulk of the config, if possible. <oriansj>indio: which distro do you currently have? <oriansj>no guix needed, just an option to install guix on top after if you want. <oriansj>I also have Arch and Gentoo procedures <oriansj>all of them produce the exact same system <oriansj>and my Debian procedure is unique in that it is able to give you an encrypted /boot (which isn't normally possible in Debian installs) <indio>Out of curiosity, and I might not make sense, can you rebuild your whole os you are running right now? with the exact same config and data? In those 20 mins?? <indio>You must be very frugal with you setups, I am myself. <oriansj>if I was being truly frugal, my operating system requirements could fit on a floppy disk. <indio>Can do that very same thing with Trisquel and guix on top? <indio>i used to run puppy linux, so i know of frugality. <oriansj>my needs are only about 512bytes; I can build everything else up from there <oriansj>and I can comfortably use vi, ed and SET <indio>I live in ram of employers pc. Yet I have more space requirements. I loose. <indio>I unconfortably use vi. It's a commit hazard. <oriansj>well is 4GB of space something you can access? <indio>No time to learn exit command. <indio>I have lots of ram. Too much for my thiness. <indio>Let me ask again. CCan you achieve installing from scratch in Debian and you current running configuration? <indio>I don't care if it is i userland. <oriansj>install is quick and easy, if you mean build everything from hex0 bootstrap-seed, it'll take a bit more <oriansj>using a 25 year old computer and DSL, one can install in 30 minutes <indio>No. I can install Debian from iso quickly, it is installing my packages and config and data I want to do quickly. <oriansj>ZFS send/recieve or BtrFS send/recieve an option? <indio>ahh. I use snapshots. I never lost a gnu linux setup since 2006. <indio>I lost my gentoo in 2006. I almost lost it. <oriansj>oh, I destroy and create from scratch every month <oriansj>it ensures my backup procedure is always complete and my data restore process is tested routinely. <indio>Compiler failed suspiciosly in gentoo compiling toolchain. Got stuck and could not compile anymore, IN GENTOO. I had to throuw it away. <indio>I will install Guix on my recently upgraded Triquel 11. <indio>I need to flee from windows. <oriansj>indio: that is more of a topic for #guix-offtopic than #guix <atka>how long has it been down? <bdju>anyone else unable to get a substitute for xournalpp? my guix is 11 days out of date so maybe that's part of it. trying --fallback as suggested by the error output <apteryx>confirm there's a DNS problem making all of Guix services unreachable <apteryx>the machines are still running though; e.g. berlin (141.80.181.40) is up and building stuff <apteryx>I've restarted its knot service, not sure if that'll help (I'm pretty DNS unaware) <ryan77628>Oop, and here i am just building libreoffice from scratch bc i didnt know any of the ips <ryan77628>i should write a few down when dns is back just in case lol <apteryx>seems restarting the knot service on berlin didn't help; we'll see what other guix-sysadmin folks say <apteryx>'[guix.gnu.org.] zone will be bootstrapped' seems promising; not sure how long that's supposed to take <apteryx>I've sent the tip to help-guix@gnu.org to help other folks probably struggling with the problem <ArneBab>Is guix.gnu.org down? an is it down site says it’s not only gone for me … <ArneBab>… arg, I just read the topic. I’m sorry for the noise. I wish you much strength regaining the server! <lilyp>ArneBab: It's not down for me <rekado>the server is not down but DNS resolution is broken <rekado>bayfront is the main DNS server IIRC and berlin can’t talk to it <rekado>and on bayfront the problem is that the gnu server 209.51.188.148 cannot be talked to <rekado>so someone should probably talk to the gnu sysadmins <cbaines>well this is fustrating, we should really increase the TTL's on some of these domains <cbaines>anyway, time to fit in some GC'ing on bayfront <jpoiret>would it make sense for guix to move off of gnu.org? <cbaines>given that we're already short on hardware and peoples time to run things, I'm not sure what the motivation would be? <jpoiret>right. I just thought that given gnu.org's quite recurrent downtimes and problems it might help a bit <cbaines>I think there's ways to mitigate that (like increasing TTLs) without going down the "we can do it better" rabbit hole <jpoiret>seems fair. I don't have much experience as a sysadmin so these are more questions than suggestions <cbaines>it would be good to see if we can contact the FSF about the problems though, I've got no idea who has interacted with them regarding DNS though <cbaines>rekado, that's great :D what was the problem? <rekado>I just sent email to the guix sysadmins with details. Short story is that the main GNU DNS server that we talk to has a new IP. <rekado>since at least April 10 we haven’t been able to talk to it <rekado>bayfront will need to be reconfigured with a config change <rekado>I’m running knotd manually right now <cbaines>that good investigating, I'd seen those log entries but I'd assumed the connectivity problems were on the FSF end <jgeerds>Just came here to see if the problem is on my connection side. Thanks for the info rekado. Is there a ETA for the fix? I guess I'll have to wait until dns ttl expires? <rekado>jgeerds: it already works for me. Check if you’ve got any caches that you could clear. <jgeerds>rekado: you're right, seems to work again. That's perfect because I'm currently setup my new laptop :-) <yasht>Hi, is there a way to graft a package system-wide? <rekado>yasht: I don’t think so; it would be good to have package transformations available as an option for the “guix system” sub-commands. <rekado>yasht: you can apply package transformations to the globally installed packages, but I don’t think know how you would rewrite all packages that are used by all services. <zimoun>jpoiret: what are ready for that with the domain guix.info ;-) Currently, www.guix.info is redirected to guix.gnu.org <yasht>So how should I go about replacing the alsa-ucm-conf system-wide with an updated version? <zimoun>jpoiret: maybe it could be worth to internally hard-code URL pointing to some subdomains of guix.info redirected to the current gnu.org subdomains. It would help to mitigate the issues when gnu.org is down for whatever reasons. <ffrrnn>GUIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIX <mroh>unmatched-paren: seems to work! good morning! ;) <apteryx>while transferring a massive amount of ghc stuff to an offload host; guix offload: sending 6 store items (1,974 MiB) to 'the-offload-host'..., the remote SSH server stopped responding (can't SSH to it anymore) <apteryx>seems it got stuck (no more bandwidth being used), but the offload build hasn't returned the prompt yet <apteryx>seems to be my reverse SSH tunnel that broke <apteryx>(which is configure via the autossh service) <andreas-e>apteryx: This offload-over-ssh-dies problem on berlin is a known issue. <apteryx>it happens with large transfers, right? <ffrrnn>working through 'how to design programs' to learn lisp has been a neat and lengthy distraction <andreas-e>Mostly, yes. But I have also seen it with small transfers following some large transfer. <andreas-e>It is quite systematic when building things like openjdk or ghc by hand. <andreas-e>(I do not find the issue number any more, but I am quite certain there is one.) <andreas-e>I have often seen it stuck on ghc-random, which is quite small. <apteryx>lechner: did we loose our friendly-bot definitevely? It is missed :-) <apteryx>I see I'm not using the -M switch with my autossh service, perhaps I should <andreas-e>apteryx: This is not the one I am thinking of. <andreas-e>I thought it happened only on berlin. But I stumbled upon a very old issue: <andreas-e>Maybe we should close it, by the way. It is talking about systems that do not exist anymore... <andreas-e>It is also strange that it should block several times on ghc-random, precisely; more often to be random, I would say... <rekado>I’ve built a bunch of things for aarch64 on berlin and it never froze <andreas-e>Just connect to berlin and try something like "guix build openjdk". It will start by sending maybe 1GB of data, and usually stops. Then there is a timeout after one hour. Or "guix build ghc". <apteryx>how do I forcibly close a listening connection? I think the reverse SSH connection appearing as port 6666 on my localhost is stuck and preventing autossh to connect again <rekado>andreas-e: does this happen with particular nodes only? <bjc>apteryx: you have to kill the process holding the socket open <rekado>the x86_64 nodes are all sitting in the same rack; there’s not supposed to be any networking problems <andreas-e>I do not think so. It happens quite often, and when all nodes have load 0, they seem to be chosen at random. (So the same big packages are transferred many times, to different nodes.) <andreas-e>It could be something with our ssh between the daemon and the build process; it needs not be the network. <andreas-e>But right now it has been working well, I have been trying ghc a few times and it started directly. <apteryx>ah, 'sudo ss -ptan' showed me which process is keeping the dead connection alive <sneek>ss[m], efraim says: tell me more about `zig build` not working for you. which version? I'd like to try to debug it <bjc>apteryx: what's ‘ss’? i've always used ‘lsof’ for that <andreas-e>efraim: zig in core-updates does not build. Maybe an incompatibility with glibc@2.35. There are messages about it in guix-devel. <davidl>unmatched-paren: yep, that worked! I am very happy, thank you so much! :) <sneek>davidl, you have 4 messages! <sneek>davidl, unmatched-paren says: run this in a guix repl with your channel in the load path and once it starts hanging, cancel the operation, and the last line in ~/recursion.log should tell you which package has a cycle in it <sneek>davidl, unmatched-paren says: disclaimer: i'm not certain this will work <sneek>davidl, unmatched-paren says: oh, also, change %my-channel-directory to the appropriate directory :) <apteryx>hm, per the autossh service documentation, the 'port' field I've used should have translated to a -M option <apteryx>ah, it sets the AUTOSSH_PORT environment variable <surpador>Has anyone been able to run a flatpak as a Shepherd service? I've been trying to use simple-service and fork+exec-command to run `flatpak run' and `flatpak kill', but I haven't gotten it working right yet. One problem I've had is that flatpak instance IDs can exceed the PID range and so Shepherd rejects the instance ID as a running value for the service. <zimoun>For instance, if FSF closes Savannah for whatever reason, it will be complicated with the current status to propagate the switch to all user. <zimoun>andreas-e: well, I have no idea about wget for i686 and it is blocking. <zimoun>andreas-e: Let me know about Julia. FYI, I will be offline after 19h (Paris) and til on Monday morning. :-) <andreas-e>Me neither for wget. The File1 and File2 that are mentioned are string variables (containing text, not file names) in the Python test scripts. I suppose they should be written to temporary files, then some kind of web server is started and wget is used to retrieve the files. But I have not checked that, and I do not feel competent to test it. <zimoun>Yeah, I have the same conclusion. <zimoun>And I totally miss why this piece would be different on i686 or on x86_64 <PotentialUser-95>Hello. I finally got my Honeycomb LX2 ARM server and it starts booting from sd card but at the very end I get an kernel not found error. The image I tested is an UBUNTU ARM provided by the guy who assembled the LX2. Can you suggest a working image or even better provide a download link? I know that the arm build farm is using the very same hardware <old>I'm still having the following error with rofi-wayland: <old>Wayland-ERROR **: 11:22:11.974: Rofi on wayland requires support for the layer shell protocol Trace/breakpoint trap <old>yet I have the gtk-layer-shell in my home configuration along rofi-wayland <old>I am missing something? <bjc>just curious: is there a reason to prefer rofi+wayland over wofi? <lissobone>This is a certified "welcome abroad" moment. <lissobone>Does prboom-plus fail to build for anyone else? <lissobone>I know that there are other free doom engines available, but I just need specifically prboom because of the old saves. Long story short, I broke Trisquel. I messed something up with python, but I saw this as a reason to try something new. That's how I installed Guix. The unauthorized package management is pretty cool. I'm still reading the info manual. <lissobone>I am starting to think that it's "aboard" and not "abroad". <lissobone>Cool. I tried to investigate the issue before writing here by checking the log files (using special technologies of the Future called 'grep', 'zcat' and also something else). I didn't understand what really happened, anyways. <lissobone>"No usable browser found"... Alright, I'm gonna just emacs it. <lissobone>I didn't find any errors reported from the compiler directly. <lissobone>%exception #<&invoke-error program: "make" arguments: ("-j" "16" "gamesdir=/gnu/store/h67zdk0vpcadjxi7xl9lbirzq6cil5a3-prboom-plus-2.5.1.4/bin") exit-status: 2 term-signal: #f stop-signal: #f> <lissobone>This line looks interesting. If only I understood what's written here. <unmatched-paren>lissobone: seems to me like "multiple definitions of <whatever>" is the problem <bjc>it means ‘make’ failed, but you'll need to look at the error log to see why <unmatched-paren>lissobone: that's just a printed representation of the guile exception that was raised <bjc>there should be a line saying where the build log is, shortly before everything died <unmatched-paren>it's an &INVOKE-ERROR, which happened when running PROGRAM with ARGUMENTS, that exited with EXIT-STATUS <bjc>oh, this is fun: ValueError: ZIP does not support timestamps before 1980 <bjc>that's trying to build sssd on core-updates <bjc>is there a way to set the datetime just for a single package build? <andreas-e>unmatched-paren: Functions are defined (instead of just declared) in header files. So this looks like a C++ program in which header files are included multiple times without #ifdef guards. <bjc>(ie, for the package, but not its inputs) <andreas-e>zimoun: Indeed, you can leave for the weekend with good conscience. Although you will then miss all the fun! <lissobone>(I'm in the process of thinking why this could have happened.) <lissobone>bjc: well, I looked at the error log. It raised more questions. <unmatched-paren>lissobone: i wonder if we could try adding: -Wl,--allow-multiple-definition <apteryx>andreas-e: I'll merge staging to master now <lissobone>Hmm, looks nice. I'll try it locally (if I figure out how; I am a newbie). <unmatched-paren>lissobone: i don't know; i was just looking at a stackoverflow page after searching "allow multiple definitions gcc" :P <unmatched-paren>it said --allow-multiple-definition, but i suppose i should check in ld's actual documentation <lissobone>By the way, is documentation for software served separately in Guix? <lissobone>If this is so, how to get it? It just so happens that my guix info page went somewhere (I probably garbage collected it), and now I have to ask it here. <lissobone>Hmm, interesting. Let me double check so I don't look like a dummy. <lissobone>Nope, info still shows the manpage. Anyways, I am pulling. <lissobone>A small step for man, and a giant leap for the Mankind. <unmatched-paren>then ``git branch -c NEW-BRANCH'' and open a development shell with ``guix shell -D guix'' <lissobone>Oh, so this is where the stuff I expected starts. <unmatched-paren>compile the guile files with ``./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)'' <lissobone>I should not have removed it from my '.bash_profile'. <lissobone>unmatched-paren: idk i was testing lol (that's why I did it). <unmatched-paren>lissobone: make sure that sources ~/.config/guix/current/etc/profile and ~/.guix-profile/etc/profile too <lissobone>I broke Trisquel (messed up dependencies) and saw that as an opportunity to try something new. That's how I ended up here. <lissobone>While it's doing its stuff (still cloning, the internet is kinda slow, but it will finish soon), I read some of the documentation. <lissobone>I saw something curious there: in particular, the peer to peer package sharing plans. <lissobone>Oh, that's how one installs documentation! `guix install bash:doc`! <unmatched-paren>lissobone: well, this has been an idea for a while, but recently it seems like we've got some GSoC interns who intend to have a go <lissobone>Not every package has a manpage or even an info manual. <unmatched-paren>the ones that have a separate output seem to have *massive* docs that take up a lot of disk space <lissobone>Cuz, judging by the 0.3 megabytes of bash:doc I have just downloaded, the impact is negligible. <lissobone>It's at 40% or something. Mayhaps I shall do it tomorrow, sinceth the Emacs clock tellth me that it is 1:55 AM. <unmatched-paren>lissobone: would you like me to detail the rest of the process, in case i'm not there? <lissobone>Ugh-h, what? Sorry, my parsing mechanisms failed here (no offense, really). How will you detail the rest of the process if you're not here? <unmatched-paren>after it finishes building, run ./pre-inst-env guix edit prboom-plus <unmatched-paren>lissobone: if you open it, there's a #:configure-flags '("--disable-cpu-opt") form in ARGUMENTS <unmatched-paren>in that form, add the string "CFLAGS=-Wl,--allow-multiple-definitions" <unmatched-paren>and then run ``make -j$(nproc)'' again, to build the new version of the file <unmatched-paren>and then you can run ./pre-inst-env guix build prboom-plus to build the updated version <unmatched-paren>and then follow these instructions to send the change to guix-patches@gnu.org: <lissobone>I'm currently bootstrapping it, but I don't know what package provides the 'autopoint' command which is missing. <lissobone>I installed autoconf and automake just in case. <unmatched-paren>that command starts a shell where the dependencies of guix are in the environment <attila_lendvai>one of the best thins in lisp is that it can give a backtrace. and it's rather dismaying that Guix hides it most of the time. (current annoyance: error in a start GEXP of a service without a backtrace) <attila_lendvai>unmatched-paren, herd doesn't have --on-error, but it's a good point i should remember, thanks! <lissobone>WARNING: (gnu services getmail): imported module (gnu services) overrides core binding `delete' <lissobone>I tried with vi and ed, but to no avail. I built it in an isolated container. Time to exit the sumbarine? <lissobone>(That's just my association with the isolated container.) <unmatched-paren>lissobone: exit it and add (your editor) and -EEDITOR to the shell line <lissobone>(#:configure-flags '("--disable-cpu-opt CFLAGS=-WL --alalow-multiple-definition") <lissobone>error: unrecognized option: `--alalow-multiple-definition' <lissobone>It should've also been "allow" and not "alalow". <lissobone>Hmm... None of the combinations seem to work. <lissobone>It offered me to write "./configure --help". <teddd>unmatched-paren: I am slowly understanding monads :O thanks to u <lissobone>Now that's an unrecognized option. CFLAGS are ok. <lissobone>The allow multiple definition parts is what triggers it. <lissobone>It says that '-z' is an unrecognized option. <lissobone>I will just check the available compile options. <apteryx>is rebasing in the mix of a merge a bad idea? <ieure>Rebases and merges don't get along; avoid. <ieure>I never create merge commits in Git, have encountered irksome problems with it too many times. <lissobone>(I followed their advice to execute './configure --help'.) <lissobone>But I believe that the compiler might have something in store. <apteryx>ieure: that's my experience too (it creates very confusing merge conflicts). so how should branches be merged then? 'merge' appeared the most natural solution, but when using that approach if new commits appear upstream, it needs to be rebased <apteryx>I could cherry pick, but that's kind of unwieldy for large branches, and I think it'd rewrite the commits (which merge could avoid unless you then have to rebase too) <teddd>I'm trying to build the guix website. I followed the instructions in the README. `haunt build' fails with `TIME-ERROR type bad-date-format-string: "~Y~m~d ~H:~M"' <teddd>Should I consider using some time machine ? <apteryx>hasn't been updated since gnu: haunt: Update to 0.2.6. in feb 2022 <apteryx>perhaps it should, to remain compatible with the latest guile? <teddd>what would need to get updated ? The guile in haunt package definition is already guile-3.0-latest <teddd>but 0.2.6 is alreay the latest <teddd>Maybe guile is too new ? Maybe some things need to be recompiled in guile on my side. I guix pulled recently after 2 months. So maybe I have some old compiled guile somewhere. How do I force recompilation? <apteryx>just deleting the .go in the project should be enough, if it doesn't use auto-compilation <teddd>I just cloned the repo so it should be the problem. But let me try <bjc>w00t! just got my system built with core-updates <bjc>i did have to disable lxd and setting the keymap, though. and patch like three things~ <teddd>apteryx: not working. Maybe a problem with locales ? <apteryx>teddd: I doubt so, but I'm out of ideas :-/ <apteryx>staging has now been merged to master! <bjc>staging and core-updates merged yesterday, right? <rekado>oh, got to rebase rust-team again <rekado>I really wished I could have merged rust-team firts. <rekado>we have been waiting for weeks to have rust 1.67.1 build on aarch64 and that’s probably been in vain now. <rekado>the rebase on top of the new master branch is going to hurtr <teddd>apteryx: I found the problem. In the patch I added the "date" mention was missing. So the parsing failed. <jpoiret>rekado: sorry to hear this, I can feel the pain <jpoiret>hopefully once staging and core-updates are sorted out we will be able to manage this better <apteryx>bjc: I was aiming for yesterday, but caught an ansible failure that needed fixing <apteryx>so it's going to be today (looking at the master -> cu now) <apteryx>rekado: what's missing for rust-team to be ready? <apteryx>I've mostly cherry picked stuff from rust-team into staging to help fixing the rust breakage there, didn't create much original rust work I think, so hopefully the merge will not be too painful <rekado>I now have to rebase 300+ commits <rekado>I had previously rebased rust-team on top of master, so I find it odd that there’s so much work to be done now <rekado>bleh, I just leave this for someone else. <tirifto>Hello! I’m not sure if this is on-topic, since I’ve installed Guix 1.4.0 from Debian’s repositories, but I want to ask if the repositories in such an installation are meant to stay up-to-date. <tirifto>Curiously, using ‘guix search’ I only find outdated package versions (icecat 102.5.0 and nheko 0.10.2), but after installing icecat, it says its version is 102.10.0. Could it be that search is somehow using an outdated repository…? <tirifto>I have ran ‘guix’ pull several times, until it said there‘s ‘nothing to be done’. <tirifto>Huh… the Jami and Icecat I installed are both newer than the search results, but the Nheko I installed is just as old. I might have changed my profile between installing these, but it feels like that shouldn’t stop Guix from getting the newest versions… <apteryx>tirifto: I think there's a gotcha when using the guix from debian <apteryx>/usr/bin/guix taking precedence or something, and not being shadowed by default with the guix from 'guix pull' <vagrantc>standard "hash guix" and/or logout and log back in again? is the guix you're using the guix you used from guix pull? <jpoiret>you can check with `command -v guix` <ekaitz>anyone coming to the OpenSourceSummit this year? it happens to be in my city <ekaitz>maybe for some reproducible builds stuff? they have a track for that <apteryx>i'm doing a few sanity checks to the master -> core-updates, and I'll merge after, if you can hold on to commits you were about to push there <lfam>Hey apteryx, how'd you do the staging deployment? Cherry-pick / rebase? <tirifto>Oh, I see the problem now! The path ‘~/.config/guix/current/bin’ has ‘guix’ and ’guix-daemon’ in it, and is included in the profile Guix asked me to set. But that same path has had no other executables in it, even though I had installed several programs. So instead, I source the profile which has ‘~/.guix-profile/bin’, which has all the executables… except for ‘guix’! <apteryx>lfam: a merge... then I didn't have a choice but to do a rebase because of some commits that got pushed in the meantime <apteryx>I've pushed the master -> core-updates merge in a rush... probably broke something, I'll look into it in an hour or two. <rekado>one for guix, the other for stuff you install with it <tirifto>Okay, I was worried this might be a weird state to have, but if that’s expected/recommended, everything’s good. :-) <tirifto>Thanks a lot for your help, apteryx, vagrantc, rekado!