IRC channel logs


back to list of logs

<aitzkora> has a problem ?
<lfam>I confirm the problem aitzkora
<lfam>Looks like the server that hosts and 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
<unmatched-paren>negligiblebeans: use file:// :)
<negligiblebeans>Perfect, thanks unmatched-paren
<TylerWolf[m]>Is anyone else having issues with the ci being down?
<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>sysfu: cgit is used by gnu
<unmatched-paren>there's also gitweb which i believe is included with git
<unmatched-paren> <- sysfu: uses cgit (i actually prefer it... it's just as simple as cgit but imo nicer)
<unmatched-paren>sneek: later tell davidl: oh, also, change %my-channel-directory to the appropriate directory :)
<sneek>Got it.
<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]>Tyler Wolf: yes, we do
<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, i replaced (channel-with-substitutes-available %default-guix-channel "") with just %default-guix-channel in my ~/.config/guix/channels.scm
<mekeor[m]>when talking about self-hosted git-services, there's this nice chicken scheme implementation:
<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?
<apteryx>what kind of 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.
<svl>Makes sense :)
<mekeor[m]>many guix-maintainers live in europe where it's quite late now...
<mekeor[m]>i'd guess this will take some while
<svl>That's fine I'm not doing anything else tonight tbh
<Guest19>I guess * 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_>indio: you can ins
<pkill9_>you can use manifests to instlal a collection of packages to user profile
<indio> is down
<indio>from my place at least
<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?
<indio>oriansj: wow.
<oriansj>hmm, the closest I have is Debian and from zero to ready is about 22 minutes:
<indio>with the aid of guix?
<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>I see. That's fantastic.
<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>oriansj: ^^^
<indio>NO WAY
<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>you use emacs, so u can't.
<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 did before
<oriansj>and I can comfortably use vi, ed and SET
<indio>hmm thats a few bytes
<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>But some version dont work.
<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>In less than an hour or so?
<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.
<indio>I'll have to test it.
<oriansj>and automated testing is an option
<indio>I mean, try it.
<oriansj>indio: is git-annex not an option?
<indio>new to git, god vcs
<oriansj>ZFS send/recieve or BtrFS send/recieve an option?
<indio>impossible to loose a repo
<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
<indio>Well. Two sides of a coin.
<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>Not kidding.
<indio>It's a paradox.
<indio>I switched.
<indio>I will install Guix on my recently upgraded Triquel 11.
<indio>I need to flee from windows.
<indio>A big mistake.
<oriansj>indio: that is more of a topic for #guix-offtopic than #guix
<atka> down?
<atka>ok, thanks
<atka>how long has it been down?
<indio>use cache
<indio>more than 2 hours and half
<atka>ok, just curious
<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 ( is up and building stuff
<apteryx>I've restarted its knot service, not sure if that'll help (I'm pretty DNS unaware)
<apteryx>so you should be able to get substitutes with say: --substitute-urls=
<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>the last know messages were:
<apteryx>'[] zone will be bootstrapped' seems promising; not sure how long that's supposed to take
<apteryx>I've sent the tip to to help other folks probably struggling with the problem
<apteryx>good night, guix!
<ArneBab>Is 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
<ArneBab>rekado: thank you for the info!
<rekado>and on bayfront the problem is that the gnu server cannot be talked to
<rekado>so someone should probably talk to the gnu sysadmins
<rekado>gotta run
<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
<jpoiret>gimp for example has its own domain
<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'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
<rekado>FYI: I just fixed it.
<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?
<xd1le>ty rekado
<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 ;-) Currently, is redirected to
<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 redirected to the current subdomains. It would help to mitigate the issues when is down for whatever reasons.
<rekado>zimoun: hard-code where?
<unmatched-paren>morning :)
<unmatched-paren>testing circe...
<mroh>unmatched-paren: seems to work! good morning! ;)
<apteryx>rekado: thanks for the DNS fix!
<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>andreas-e: perhaps related: #62213
<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>Or maybe this is also the same thing:
<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>FWIW I’ve never seen that
<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".
<andreas-e>Maybe it does not happen for aarch64?
<apteryx>andreas-e: closed #35181, thanks
<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
<ss[m]>damn, that just tagged me
<sneek>ss[m], you have 1 message!
<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
<apteryx>it's like the new netstat
<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: <- and jgart[m] too
<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>it didn't
<apteryx>ah, it sets the AUTOSSH_PORT environment variable
<apteryx>nevermind then
<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.
<surpador>For instance, I had code like the following which failed due to the range check:
<zimoun>rekado: hard-code in Guix code. For instance, instead of "" something like ““ redirected to Savannah. The day when Savannah is down, it is easy to switch to other machine.
<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
<andreas-e>zimoun: Indeed, this is confusing.
<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
<andreas-e>zimoun: Okay for julia, I just pushed!
<andreas-e>ghc is now in its silent test time.
<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>Anyone alive? Any hackers?
<andreas-e>It fails on the build farm, see here:
<unmatched-paren>davidl: yay! :D
<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>That's literally what I got!
<lissobone>Except with -j4 in place of -j16.
<lissobone>And 16 seconds instead of 17.
<lissobone>What might be causing the issue?
<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-") 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
<zimoun>andreas-e: cool! Thanks
<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!
<unmatched-paren>what is it about code from the last century...
<lissobone>I'm back.
<lissobone>From now on, let's be logical.
<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
<unmatched-paren>to the CFLAGS...
<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).
<lissobone>Isn't it "--allow-multiple-definitions"?
<andreas-e>apteryx: Cool!
<unmatched-paren>lissobone: i don't know; i was just looking at a stackoverflow page after searching "allow multiple definitions gcc" :P
<andreas-e>I keep my fingers crossed.
<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?
<unmatched-paren>lissobone: depends on the package
<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>unmatched-paren: for instance, bash.
<unmatched-paren> should be provided when you guix pull...
<lissobone>Hmm, interesting. Let me double check so I don't look like a dummy.
<unmatched-paren>try source ~/.config/guix/current/etc/profile
<lissobone>Nope, info still shows the manpage. Anyways, I am pulling.
<unmatched-paren>lissobone: interesting. anyway, regarding the local build thing: git clone
<lissobone>Uhh, just git clone?
<lissobone>I thought it was going to be fancier.
<unmatched-paren>first step :P
<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.
<lissobone>I fixed it. I just sourced /etc/profile.
<unmatched-paren>compile the guile files with ``./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)''
<unmatched-paren>lissobone: nice, okay
<lissobone>I should not have removed it from my '.bash_profile'.
<lissobone>Alright, compiling...
<unmatched-paren>lissobone: why did you do that? :)
<unmatched-paren>alright, tell me when compilation finishes
<lissobone>(I am bewildered. Help me.)
<unmatched-paren>about which problem? :)
<lissobone>Alright, not anymore.
<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>That's already done.
<lissobone>I saw that in the docs.
<unmatched-paren>ah, are you on a foreign distro...?
<lissobone>Uhh, no, but I used to be on one.
<lissobone>I broke Trisquel (messed up dependencies) and saw that as an opportunity to try something new. That's how I ended up here.
<unmatched-paren>ah, right (i saw that earlier but forgot :))
<lissobone>Anyways, why am I compiling Guix?
<lissobone>Weren't we talking about prboom-plus?
<lissobone>Is it, like, a lesson?
<unmatched-paren>to change the package
<unmatched-paren>to see if we can fix it
<unmatched-paren>prboom-plus, i mean
<unmatched-paren>guix includes its packages in the main repo
<lissobone>Hmm, alright.
<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
<unmatched-paren>lissobone: that's only for some packages
<lissobone>Yeah, I know.
<lissobone>Not every package has a manpage or even an info manual.
<unmatched-paren>the ones that specify a :doc output :)
<unmatched-paren>no, some packages include docs with the default :out output
<lissobone>Like, leaving no choice to the user?
<unmatched-paren>with most packages there's no cost to including docs
<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.
<unmatched-paren>i know that's the case for glib, at least
<unmatched-paren>/"doc" -> dbus -> ;22 MiB of HTML doc
<unmatched-paren>why am i not suprised :)
<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>lissobone: just tell you what to do next
<unmatched-paren>after it finishes building, run ./pre-inst-env guix edit prboom-plus
<unmatched-paren>which will open the package in your $EDITOR
<lissobone>And edit the guile scheme file?
<unmatched-paren>ACTION opens it to see what it's like
<unmatched-paren>lissobone: if you open it, there's a #:configure-flags '("--disable-cpu-opt") form in ARGUMENTS
<lissobone>Oh, yeah, I got that message.
<lissobone>You'll just tell the stuff in advance.
<lissobone>Thank you.
<lissobone>It cloned!
<unmatched-paren>in that form, add the string "CFLAGS=-Wl,--allow-multiple-definitions"
<lissobone>Now I understand why are we doing this.
<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>if that works, you can commit the change with this message:
<unmatched-paren>and then follow these instructions to send the change to
<lissobone>I've got a single question, though.
<unmatched-paren>(i swear it looks more complicated than it is :P)
<unmatched-paren>fire away
<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>are you running it in ``guix shell -D guix''?
<lissobone>Oh, wait. No, I am not!
<unmatched-paren>that command starts a shell where the dependencies of guix are in the environment
<lissobone>It's thinking.
<lissobone>It works!
<lissobone>I ran the shell with -C.
<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)
<unmatched-paren>attila_lendvai: does it print it with --on-error=backtrace?
<unmatched-paren>(i don't know whether it will)
<unmatched-paren>lissobone: yay :)
<attila_lendvai>unmatched-paren, herd doesn't have --on-error, but it's a good point i should remember, thanks!
<unmatched-paren>ah, yeah, of course, service scripts are run by shepherd, not guix
<lissobone>It's compiling.
<lissobone>88% compiled.
<lissobone>WARNING: (gnu services getmail): imported module (gnu services) overrides core binding `delete'
<lissobone>Is this dangerous?
<unmatched-paren>lissobone: nope, it's fine :)
<lissobone>It sped up.
<lissobone>sh: line 1: nano: command not found
<lissobone>That's when I tried to edit that thing.
<lissobone>DOn't worry, I almost see the root.
<unmatched-paren>lissobone: you need to set $EDITOR :)
<lissobone>I know, it's set to nano.
<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.)
<lissobone>I am ediditinfngtg it.
<unmatched-paren>lissobone: exit it and add (your editor) and -EEDITOR to the shell line
<lissobone>I already did that, no worries.
<lissobone>(#:configure-flags '("--disable-cpu-opt CFLAGS=-WL --alalow-multiple-definition")
<lissobone>It should be like that, right?
<lissobone>Or, like, each flag in a separate string?
<lissobone>There's a reason it's a list...
<unmatched-paren>each flag in a separate string
<lissobone>error: unrecognized option: `--alalow-multiple-definition'
<lissobone>It should've been plural.
<unmatched-paren>huh, okay
<lissobone>It should've also been "allow" and not "alalow".
<lissobone>Hmm... None of the combinations seem to work.
<lissobone>It says "unrecognized option".
<lissobone>It offered me to write "./configure --help".
<unmatched-paren>oh, it's the CFLAGS bit it doesn't seem to like
<lissobone>It doesn't say anything about cflags.
<unmatched-paren>AH! I'm an idiot, it's a cmake project, not autotools!
<unmatched-paren>maybe try -DCFLAGS=...
<teddd>unmatched-paren: I am slowly understanding monads :O thanks to u
<teddd>Not done with reading yet
<lissobone>Now that's an unrecognized option. CFLAGS are ok.
<unmatched-paren>wait, what
<lissobone>The allow multiple definition parts is what triggers it.
<unmatched-paren>i think i'm looking at the wrong source code
<unmatched-paren>oh, i see
<unmatched-paren>maybe try -Wl,-z muldefs
<lissobone>Still, unrecognized option: `-z'.
<unmatched-paren>uh, okay...
<unmatched-paren>try just -z muldefs
<unmatched-paren>without -Wl,
<lissobone>It says that '-z' is an unrecognized option.
<lissobone>I will just check the available compile options.
<teddd>Can I apply this patch, and render the docs locally to view it in a browser ?
<apteryx>is rebasing in the mix of a merge a bad idea?
<apteryx>(or after a merge, rather)
<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 checked the options.
<lissobone>(I followed their advice to execute './configure --help'.)
<lissobone>There aren't really any useful onese.
<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>was haunt updated recently?
<teddd>last release is Jan 21
<apteryx>hasn't been updated since gnu: haunt: Update to 0.2.6. in feb 2022
<apteryx>(in guix)
<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>maybe the version
<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
<rekado>feeling rather deflated
<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>(the branch)
<rekado>now: everything.
<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>previously = yesterday
<katco>i'm so sorry rekado :(
<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.
<unmatched-paren>tirifto: yes, you can guix pull and everything
<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'
<apteryx>it's supposedly documented
<apteryx>vagrantc: any idea about ^ ?
<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`
<abralek> Check this out. I am a little bit lost.
<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>it was a bit weird
<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.
<apteryx>ACTION afk
<rekado>tirifto: source both
<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!