IRC channel logs


back to list of logs

<nckx>It was a guile-parted bug.
<lfam>Ah, looks closed :)
<nckx>It does.
<sneek>marusich, you have 2 messages!
<sneek>marusich, dftxbs3e says: I would like to try and rebase the branch on master ASAP
<sneek>marusich, narispo says: growing list of all failed powerpc64le-linux builds with failed logs etc.
<marusich>sneek, later tell dftxbs3e we need to rebuild the bootstrap binaries in order to fix the problem with the statically linked guile, right? Do you know how to fix it? Re: rebasing on master, that's fine w/me if it works. Last time, I merged master into wip-ppc64le, so I'd prefer merging, but rebasing is fine too.
<marusich>sneek, later tell narispo neat, it's good to see things being reported in the Guix Data Service. Who's building this? Is somebody running Cuirass on a powerpc64-linux system, or is the build farm using the transparent qemu binfmt trick to emulate the builds for the arch?
<sneek>Got it.
<leoprikler>Can Guile/Guix shell-escape strings during build phases?
<leoprikler>oh, wait, format ~s probably does what I want already
<ngz>leoprikler: Regarding oshu revival, LGTM. You may want to sort inputs alphabetically and replace @dfn{oshu!} with simply Oshu! in the description.
<leoprikler>sorting done, but I'd personally prefer lowercase oshu
<ngz>Fair enough. But @dfn was odd anyway :)
<leoprikler>What to use there instead?
<ngz>Nothing (hence the capital letter), or possibly @code{...}.
<leoprikler>I think I could use @command for oshu without !, but oshu! with bang is neither code nor command, but rather a pseudo-trademark™
<ngz>It the title of a work, isn't it?
<ngz>it is*
<leoprikler>In an abstract sense maybe, but in a more concrete sense it is the name of a product, and those are typically case-sensitive.
<ngz>Hmmmm... What about ``oshu!''?
<ngz>or @i{oshu!} ...
<leoprikler>@i seems closest if I take a quick look at rgrep
<leoprikler>should I also @i-wrap osu! or is that fine?
<ngz>Your call! :)
<ngz>I would lean towards consistency in this case, but anything goes.
<leoprikler>Consistency it is.
<leoprikler>Aaand sent to the ML for more bikeshedding
<ngz>Yay… I guess
<lfam>Oof. That is an old patch
<leoprikler>Old patches deserve love too.
<leoprikler>W.r.t. renpy-build-system: That patch only solves part of my problem sadly, the other part is that the game still fails to run since it's meant for an ancient version of Ren'py and there's no source code to go fix it.
<lfam>I see
<lfam>Got any ideas?
<leoprikler>I think that's what I get for trying to package stuff for the evil channels.
<leoprikler>Hmm, not quite, I could try using unrpa et al, but they're not yet packaged either
<lfam>`git shortlog -n -c --summary v1.2.0..HEAD` 🤯
<lfam>That's a lot of patches
<ngz>Oooh *blush*
<leoprikler>more than 1.1.0 to 1.2.0?
<lfam>No, but less time has passed
<leoprikler>True, but we also have more rust packages since.
<leoprikler>If I finally get down to package fractal, that's easily 50 more.
<lfam>There's also `git shortlog -n --summary v1.2.0..HEAD`, which shows authors instead of committers
<lfam>It's a nice long list
<leoprikler>Nicolas still leading
<ngz>I'm cheating. I packaged Rust stuff.
<lfam>`guix import -t crate --recursive`
<ngz>nushell alone required 270 dependencies…
<lfam>It's crazy
<ngz>And it was bumped to a new release like 2 days after I pushed it. Depressing.
<leoprikler>btw. is there a way of handling rust packages, that must be created from a specific git commit?
<ngz>You can fetch source from a git repository, not necessarily from
<leoprikler>okay, but what if the git repo does not mirror the layout in
<ngz>I don't know. I guess I didn't encounter such beasts.
<ngz>Is your question theoretical or do you have a crate in mind?
<ngz>And your package definition fails?
<leoprikler>I've already packaged 0.2 on a branch of mine, but the commit is somewhere between 0.1 and 0.2
<leoprikler>Well, I can't get the git-fetch variant into my dependencies. Cargo yells it doesn't exist.
<leoprikler>Perhaps I'm doing something wrong there
<ngz>hmmm. I don't know, sorry.
<leoprikler>Don't worry, I wouldn't be asking if it wasn't something extremely arcane in the first place 😄️
<marusich>sneek, later tell dftxbs3e I am not actually sure we need to rebuild the powerpc64le-linux bootstrap binaries. What is the problem with the statically linked bootstrap guile? It seems to work when I use it.
<ngz>Time to sleep!
<ngz>Bye folks.
*leoprikler → 😴️ as well
*apteryx is adding a static output to QEMU
<vagrantc>for the qemu-user stuff? or something else?
<apteryx>the qemu:static output will be equivalent to the 'qemu-user-static' package of other distros
<apteryx>useful to unlock qemu user-emulation with other container manegement systems such as Docker
<apteryx>(I'll need to expose a fix-binary? switch to the qemu-binfmt service, which will switch the qemu binaries to the static versions and set the F flag for the binfmt registrations
<apteryx>after that the qemu user emulation should be available for any application
<apteryx>should be easy once I have the package bits in place (qemu just finished building successfully)
<apteryx>but time to sleep!
<vagrantc> \o
<vagrantc>i had proposed a bug to enable soemthing like this for a smaller closure when building foreign binaries...
<vagrantc>sneek: later tell apteryx i had started a bug about qemu static targets in:
<Aurora_v_kosmose>Should I package a library that seems like it may be abandonware beyond the Debian team or not?
<Aurora_v_kosmose>I realized it died when I went to port my chatbot to Guix (to create a portable tarball) and found I couldn't find cl-irc.
<Aurora_v_kosmose>The original CVS host is dead.
<efraim>We use Debian's fork of w3m
<efraim>So it's not out of the question
<Aurora_v_kosmose>Oh I see.
***spk121_ is now known as spk121
***amfl_ is now known as amfl
<wumpus>i'm trying to get shutdown through 'virsh shutdown', which simulates the ACPI power button, to work in a GUIX VM, is there a simple low-overhead way i'm overlooking to do this? i know acpid exists as a package but there's no service for it, and pulling in the desktop services just for elogind-service seems overkill
<Aurora_v_kosmose>From within the VM, when you send the virsh signal, do you see anything happen in the kernel logs & other system events?
<g_bor[m]>wumpus: i guess you can just pull in elogind service
*Aurora_v_kosmose is wondering if it's just ignored entirely or some option
<Rovanion>Guix environment refuses to load a file that other tools can read:
<Rovanion>The path used in the `head` call is copied from the `guix` call.
<milkey>i'm thinking about packaging some ethereum stuff, would it make sense to make a (gnu packages cryptocurrency) module?
<milkey>then we can move bitcoin-core out of finance.scm
<Rovanion>And I've done the inverse. Modified the `head -n 1 $file` call so that it reads `guix environment --ad-hoc --load=$file` instead. And its in the same shell with the same user.
<Rovanion>Ran strace on it and found the issue. The file not found error comes from invoking the code in the file rather than guix not finding the file. That should be fixed...
***rekado_ is now known as rekado
<raghavgururajan>Hello Guix!
<cage_>raghavgururajan, hi!
<alextee[m]>is it ok if my patch includes the removal of extra space at the end of a line somewhere else in the file I'm editing?
<wumpus>Aurora_v_kosmose: i'll check, but what i expect is that the ACPI signal reaches the kernel fine (as it works for other Linux-based VMs like ubuntu), there's just nothing in userspace that triggers a soft shutdown in response
<wumpus>g_bor[m]: yes, just biting the bullet and installing elogind (and whatever it pulls in, some dbus service related things?) would be one option, it seemed overkill to have for a tiny VM, so i was just wondering if this had been considered before
<wumpus>i really want to avoid pulling in 'desktop' stuff like X11 and display managers and fonts, but maybe my worry is ungrounded there
<leoprikler>alextee[m]: it will maybe cause a little stress to the reviewer, but we aim for proper indentation anyway
<leoprikler>you may want to separate the line noise from your actual commit however
<nckx>alextee[m]: Better to keep it separate. If you're thinking ‘well that's not worth a patch...’: there are (surprisingly many) more " $" in .scm files alone.
<nckx>But they're optional; one fix is better than none.
<alextee[m]>I'll send a separate patch for it then, thx
<nckx>thk you.
<alextee[m]>it's just a bit annoying for the audio.scm file because my editor auto-corrects that and I have to keep removing it from the staging area lol
<nckx>git commit -p?
<alextee[m]>oh TIL
<alextee[m]>I was using gitg
<nckx>Yeah, git hides a lot of stuff to L.
<nckx>Never tried that.
<alextee[m]>it's basically a GUI version that allows you to stage/unstage things interactively
<alextee[m]>but commit -p looks more neat
<alextee[m]>patch sent (among with others)
<leoprikler>I have aliased gitg to "git gud", but only use it to look at the tree.
<leoprikler>Guix has made me learn magit.
<leoprikler>milkey: would that be too big for finance?
<leoprikler>if it packs a large bunch of rust stuff, that belongs to crates anyway ;D
<pretzel>leoprikler: Thanks for the suggestion. It's a simple patch (approx. 10 loc), but I'd prefer a diff. mdevos: Thanks. I fail to understand how to use such a plain-file as with-patch argument (latter seems to expect a path string not a file-like object).
<leoprikler>It might be easier to use guix' package facility directly rather than through (guix transformations) here.
<cage_>i am trying to install guix stable on a ubuntu (last stable) and it fail to build guile 3.0, someone got the same problem?
<xelxebar>Hrm, I have a (udev-rules-service 'foo foo-rules) entry in my services, but after a reconfigure the rule isn't showing up under the output reported by herd rules udev...
<cbaines>cage_, are you installing through building from source, or using the binary installation?
<cage_>cbaines, binary
<cbaines>cage_, OK, the binary installation shouldn't involve building guile, so when's that happening?
<cage_>i deownoladed the image and followed the instruction to setup the environment (making '/gnu' directory making build users etc.)
<cage_>than typed git pull to update the channels
<cage_>and just 'guix install hello'
<cbaines>Ok, so I'm guessing you've installed Guix successfully then
<cbaines>and you're having problems when doing guix install hello
<cage_>i get the command and all the infrastructure, so i think yes :)
<cbaines>What specific derivation fails to build?
<cbaines>and have you enabled substitutes?
<cage_>guile 3.0
<cbaines>when I say derivation, I mean a file within /gnu/store ending in .drv
<cage_>sorry but i am just starting with substitutes, can you explain me what are or point to the manual?
<cbaines>so you're looking for a line like: build of /gnu/store/1h6cjgrldak6z3qqrpnwvjh2cdr04955-0ad-0.0.24-alpha.drv failed
<cbaines>(for example)
<cbaines>as for substitutes, there's some information in step 7 here
<cage_>i skipped that point before ^^;
<cage_>i enabled substitutes and installing 'hello' again
<cage_>seems that is pulling binary packages now
<cage_>seems that worked :)
<cage_>cbaines, thanks!
<cbaines>great :)
<cage_>should i update guix using 'guix pull'?
<smartineng>Hello, is guix has gnat/gcc-ada compiler in the package repository?
<janneke>smartineng: no, i don't think gnat/ada has not been bootstrapped yet
<smartineng>there are some serious issue with it or just no time to fix it?
<leoprikler>bootstrapping takes a lot of time and effort
<janneke>i believe there's a cyclic dependency, but a search may give better information
<nckx>smartineng: You need an Ada compiler to build GNAT, and I failed to find an Ada compiler that can do so that can be built from source...
<nckx>smartineng: I'm not an Ada programmer though, there may be an obvious choice that I'm not aware of.
<nckx>Others have shown interest:
<apteryx>sneek: later tell vagrantc oh nice, we'll manage to squash a bug in the process :-)
<sneek>apteryx, you have 1 message!
<sneek>apteryx, vagrantc says: i had started a bug about qemu static targets in:
<sneek>Will do.
<dftxbs3e>hello! :-D
<sneek>dftxbs3e, you have 1 message!
<sneek>dftxbs3e, marusich says: we need to rebuild the bootstrap binaries in order to fix the problem with the statically linked guile, right? Do you know how to fix it? Re: rebasing on master, that's fine w/me if it works. Last time, I merged master into wip-ppc64le, so I'd prefer merging, but rebasing is fine too.
<dftxbs3e>marusich, oh well yes merging is fine too, I just kind of dislike merge commits aha
<dftxbs3e>marusich, I think we do, I am not sure yet if that guile-static binary is in the bootstrap binaries themselves or built using them (my investigations for this were inconclusive). I am not sure why it contains such a reference and the binary seems not static at all since there's few dynamic libraries listed by ldd.
<dftxbs3e>marusich, I think we could detect this better using the forbidden reference functionality..?
<dftxbs3e>Going to review some patches now, since that how I think I will be most useful as a committer first!
<leoprikler>Rust folks, how do you deal with "the trait bound `anyhow::Error: std::error::Error` is not satisfied"
<dftxbs3e>leoprikler, can you send code?
<dftxbs3e>leoprikler, preferably in
<hapster>o/ #guix
<hapster>is anyone else having troubles with guix pull?
<hapster>I seem to have a problem with guix-package-cache
*nckx pulls. Could you paste the entire error to, hapster?
<nckx>& do you use channels in addition to the canonical Guix upstream @ Savannah?
<dftxbs3e>nckx, hello :-D ! I am using "make authenticate" before pushing and it says it can't verify my commit for some reason. "key 148B CB8B D80B FB16 B1DE 0E91 45A8 B1E8 6BCD 10A6 is missing" - Is that my GPG install or..?
<dftxbs3e>(it also fails with ./pre-inst-env make authenticate)
<mbakke>dftxbs3e: try updating your 'keyring' branch
<dftxbs3e>mbakke, okayy!! thank you! I have GNU Guix's official remote named "upstream" instead of "origin" there.
<hapster>I do use two channels but those share the "dont speak about it" characteristic ;-)
<mbakke>dftxbs3e: also, there is a 'pre-push' hook in 'etc/git'; it will run make authenticate for you to ensure no bad commits are pushed :-)
<mbakke>(but you need to install it manually)
<dftxbs3e>mbakke, I already got that! :-D
<leoprikler>dftxbs3e: hmm, rust-playground does not complain, but trying to build fractal in Guix delivers a bunch of those errors
<dftxbs3e>leoprikler, can I reproduce the error somehow? Got a patch?
<smartineng>Daymn this GNAT lack of boostrappability by force is really ridiculous but maybe there is a hope with some older versions
<nckx>smartineng: Thanks, will read later.
<nckx>hapster: Could you share bitte das Erstellungsprotokoll? (bzless/bzcat/... /var/log/guix/drvs/as/lr254bx5qr3rzw3rqlk29iqx45vc0x-guix-package-cache.drv.bz2)
*nckx briefly AFK.
<dftxbs3e>leoprikler, building
<jonsger>hm, simple-cuirass-service is simply not working like I want it :(
<dftxbs3e>It's a bit annoying that "git checkout <branch>" invalidates make caching by altering dates
<leoprikler>I haven't had that issue yet. My branch diverged from master five days ago or so.
<leoprikler>so the large number of rebuilds is probably caused by that
<dftxbs3e>leoprikler, I didnt mean it for your branch, been switching to and from "keyring" to update it.
<leoprikler>okay, in that case you get a full rebuild, sure
<nckx>hapster: Never mind; I'm pretty sure the error is in a naughty channel, not in Guix. Please try disabling those before reporting bugs.
<nckx>Shit, too late. ☺
<hapster>nckx: okay :)
<hapster>nckx: you were right, thanks :)
<leoprikler>Some nice advice to Guix from Rust: "[A] library should not be deterministically recompiled for all users of the library." Just where did we go wrong?
<dftxbs3e>leoprikler, what do you mean?
<leoprikler>It's a joke at the expense of Rust, since we aim to reproducibly build everything, not just end-user applications.
<euandreh>leoprikler: where is that quote from?
<euandreh>could you share the link?
<raghavgururajan>leoprikler: I tried packaging QtSingleApplication (, but I get "failed to produce output path" error. Any ideas?
<leoprikler>full error?
<raghavgururajan>builder for `/gnu/store/mlpp94hpr5difzw9lbzjc2n3a83lrng7-qtsingleapplication-0-53.9568abd.drv' failed to produce output path `/gnu/store/r1rdqiramrj757v0l3j02kl26qi74b54-qtsingleapplication-0-53.9568abd'
<leoprikler>hmm, that means that "make install" or whatever equivalent did exactly nothing
<leoprikler>IOW you need to replace 'install
<dftxbs3e>leoprikler, well I think it's mainly because it's the end-user application that defines things like RUSTFLAGS and not libraries themselves, and in GNU Guix we don't currently reproduce libraries since we only package source code right now.
<raghavgururajan>I see.
<leoprikler>s/reproduce libraries/reproduce Rust libraries/
<dftxbs3e>It would be nice if the remote's name for checking keyring could be configured, like "origin" or "upstream"
<dftxbs3e>leoprikler, yes :-)
<leoprikler>We (more or less) reproducibly build other libraries just fine and there is at least one patch in the ML that fixes Rust's weird take on software architecture.
<dftxbs3e>leoprikler, they just don't have a stable ABI yet heh, does that thing also happen with Go by the way?
<dftxbs3e>leoprikler, I got an hash mismatch for rust-sourceview4
<leoprikler>0.2 or for-fractal and which hash?
<leoprikler>btw i tried ("rust" ,rust-1.50)("rust:cargo" ,rust-1.50 "cargo") and the same happens
<dftxbs3e>leoprikler, I ran "./pre-inst-env guix build fractal" on your "fractal4" branch, expected hash: 1bm1y4k3czplyf796cxgs4k6lrdhkjb7f52ligml73pakz9s1q26 actual hash: 0aib8385fxdpw79sasfzn6q11sqx3wigkb267if9fb12bagycgpk
<dftxbs3e>(for rust-sourceview4)
<dftxbs3e> /gnu/store/1cfcs1h1842iy096s5m73kj4m2zrnwlw-rust-sourceview4-0.2.0.tar.gz
<leoprikler>Interesting, fixed it locally
<leoprikler>Ahh, I think 1bm was with #:recursive? #t
<dftxbs3e>leoprikler, tell me when you push something that can reproduce the fractal error :-D
<leoprikler>just add (recursive? #t) to the git-reference of rust-sourceview4-for-fractal
<leoprikler>then you should no longer have the hash mismatch
<dftxbs3e>leoprikler, okay! done! Building fractal now
<dftxbs3e>nckx, leoprikler: what's the policy for copyright lines? when should we add them? is it always at the discretion of the contributor? should we do it for contributors if they didnt (or suggest that they do)? Nobody ever told me to add them since I don't myself.
<abcdw>Evening everyone!) Tomorrow have a stream about declarative configuration of userspace software and services. Made an announce in mastodon: Would be glad to see you and your suggestion/ideas/comments.
<leoprikler>I personally tend to forget them as well, but at least for major contributions such as non-trivial packages, you should definitely add them.
<dftxbs3e>abcdw, awesome :-D
<dftxbs3e>nckx, leoprikler: just pushed my first commit, hope everything's okay: :-D
<abcdw>dftxbs3e: acquired a commit access?)
<dftxbs3e>abcdw, yes! :-D
<leoprikler>btw. it reproducibly fails for the non-recursive git checkout with your hash as well
<abcdw>dftxbs3e: congrats!)
<dftxbs3e>cbaines, hello! :-D it would be nice to be able to checkout in guix-patches directly to bug-ids or something, like <bug-id>-v<n>
<dftxbs3e>abcdw, Thanks!
<dftxbs3e>leoprikler, got the error now, looking
<rekado>dftxbs3e: do you mean in
<dftxbs3e>rekado, yes or debbugs, I mean for that: - I don't have an email setup that allows me to "git am" productively right now, so I just fetch from cbaines's repo part of their patchwork infra
<dftxbs3e>I use GNOME Evolution
<dftxbs3e>cbaines's guix-patches allows me to cherry-pick patches submitted to the ML as commits directly
<rekado>ah, I see.
<nckx>dftxbs3e: Perfect.
<dftxbs3e>nckx, :-D
<nckx>dftxbs3e: re: copyright, for small changes I just follow what the contributor did; for ones that are obviously significant and lack a copyright line I always ask (the name/mail they use for git might not be the one they want recorded there, for whatever reason).
<dftxbs3e>nckx, okay! thank you!
<dftxbs3e>leoprikler, why as soon as I change whatever input it says: error: failed to select a version for `cairo-sys-rs` ?
<leoprikler>did you get a version conflict or is there no cairo?
<dftxbs3e>leoprikler, this happens whenever I update an input's definition or add inputs to the list, I didnt do anything related to cairo at all.
<dftxbs3e>leoprikler, it's a version conflict
<dftxbs3e>leoprikler, versions that meet the requirements `^0.10` are: 0.10.0
<dftxbs3e>leoprikler, the package `cairo-sys-rs` links to the native library `cairo`, but it conflicts with a previous package which links to `cairo` as well:
<dftxbs3e>package `cairo-sys-rs v0.9.2`
<leoprikler>the stuff you're adding into the mix probably have their own cairo, which is older
<leoprikler>you need to bring in libraries, that build against cairo-sys-0.10 or that don't build against cairo at all
<dftxbs3e>leoprikler, it does not
<dftxbs3e>I just upgraded anyhow to 1.0.38
<dftxbs3e>I am thinking this is somehow due to Cargo.lock not being respected, but building 4.4.0 separately to investigate
<leoprikler>hmm, perhaps it's due to the cargo inputs, that still get propagated by rust-sourceview4-for-fractal
<leoprikler>(since the inputs are the same as rust-sourceview4-0.2, but they'd actually differ)
<marusich>dftxbs3e, which guile are you looking at? The one contained in the bootstrap binaries doesn't seem to be a dynamically linked executable.
<dftxbs3e>marusich, the one resulting from guile-static-stripped@3.0
<marusich>The one I am referring to is the one in
<marusich>Do you encounter an error when you use "bin/guile" from that tarball?
<marusich>file says it's statically linked:
<marusich>It does work for me without erroring out.
<cage_>the guix file now works flawlessly with my software, thank to you all!
<dftxbs3e>marusich, it works for me too, so it's probably not bootstrap binaries
<marusich>OK, well at least that's good; I dread rebuilding them :(
<avalenn>dftxbs3e: Go and Rust seem to really be on the same "there is no such thing as binary library" page.
<marusich>If you can provide more details about the guile you think is not working, I can help investigate, but right now I don't know which guile you're referring to.
<marusich>guile-static-stripped@3.0 is the one built and included in the bootstrap binaries, right?
<dftxbs3e>marusich, it's guile-static-stripped@2 in the bootstrap binaries it seems
<marusich>But isn't that the binary at which works correctly?
<marusich>Are you saying that if you build it now, using a different commit than was used to build , it does not work?
<dftxbs3e>marusich, just run ./pre-inst-env guix build guile-static-stripped@3 - I think you'll meet the error. Basically that package is used when building a GNU Guix System image
<dftxbs3e>marusich, on our branch
<marusich>I see what you mean now
<marusich>I will check i tout
<dftxbs3e>Basically the binary contains a dynamic link to glibc with "eeeeeee.." in the gnu/store path which means it was erased by GNU Guix, so the binary does not run obviously
<vagrantc>in tests/channels.scm ... test-name: channel-news, one entry ... consistently fails for ... i've been unable to reproduce the failure locally
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, apteryx says: oh nice, we'll manage to squash a bug in the process :-)
<vagrantc>is that test potentially indirectly dependent on the network somehow?
<vagrantc>it works fine on my machines and the official debian build machines, just not on the tests infrastructure
<NieDzejkob>they don't give you the build logs?
<vagrantc>build log is available from the above URL
<vagrantc>but, it's not clear to me exactly what is failing with that test
<vagrantc>apteryx: fwiw, debian's qemu-user-static basically works without having any binaries in the chroot for some time now
<vagrantc>and in theory the non-static variant as well
*vagrantc waves hands magically
<leoprikler>dftxbs3e: same error with updated anyhow
<vagrantc>have mixed feelings about the way guix uses qemu for emulated foreign architecture builds ... having the entire closure of qemu available in the build environment would seem to potentially taint the purity of the build environment
<vagrantc>that said, it's honest :)
*vagrantc wonders if a bit of kernel-level deception wouldn't be better in this particular case
<vagrantc>NieDzejkob: part of the issue may just be my lack of fluency with guile ...
<leoprikler>dftxbs3e: if you want to reproduce it, I've force-pushed fractal4
<nckx>smartineng: Sorry, but <> still sounds like you're expected to "bootstrap" from some older GNAT binary you're assumed to find lying around, not [from (say) a different Ada compiler that can itself be bootstrapped] from (say) C.
<vagrantc>is there a /bin/sh in the environment used by guix-daemon to build packageS?
<nckx>Shouldn't be.
<leoprikler>nckx: not quite. I read this as "if you somehow manage to bootstrap ancient GNAT, you can probably jump to modern GNAT easily", which is an interesting proposal at least (*cough* rust *cough*)
<vagrantc>nckx: thanks for confirming :)
<nckx>leoprikler: I didn't read it that way but that would be better indeed.
<nckx>So I hope you're right.
<nckx>Well, hm, no: that just leaves ‘manage to bootstrap ancient GNAT’ as the original begged question.
<nckx>I read ‘not worth it’ as ‘we never bootstrapped from C’, so GNAT 0.1 isn't going to be better. That said, I haven't found it yet ☺
<leoprikler>of course, but I'd imagine that a sufficiently ancient GNAT can be compiled with a different Ada and some spit.
<nckx>The only Ada we have conforms to a standard that predates GNAT, is the problem.
<nckx>I'll give looking for the oldest surviving GNAT another go, so we're not just slinging hypotheticals at each other.
*nckx gets fedora, whip.
<dftxbs3e>leoprikler, yes.. I didnt think the upgrade would solve it
<dftxbs3e>leoprikler, the error doesnt make sense basically, but it's not easy to modify upstream code and test changes
<leoprikler>I've also specified inputs for sourceview4 now, so you should be able to go ham without stuff breaking
<dftxbs3e>leoprikler, oh cool!
<euandreh>Is there a way to (local-file ...) to escape PWD? I wanted to reference (local-file "~/.ssh/") but the tilde won't expand, and running "guix deploy" will prefix $PWD
<euandreh>so I get the error: guix deploy: error: canonicalize-path: Aucun fichier ou dossier de ce type: "/home/andreh/dev/libre/servers/vps/~/.ssh/"
<leoprikler>(getenv "HOME")
<euandreh>leoprikler: hmmm, that makes sense
<euandreh>let me try it
<raghavgururajan>leoprikler: I hope you received my follow-up email for v11. Seems like we can't use QtSolutions. There are classes missing.
<euandreh>aaaaand it works like a charm. ty leoprikler
<leoprikler>raghavgururajan: any specifics as to what class it's missing? there doesn't seem to be anything in nextcloud's tree, that adds to it
<leoprikler>rather it just takes away
<raghavgururajan>error: ‘SharedTools’ has not been declared
<raghavgururajan>error: expected primary-expression before ‘public’
<leoprikler>(substitute* (list "src/gui/application.cpp" "src/gui/application.h") (("SharedTools::QtSingleApplication") "QtSingleApplication"))
<apteryx>vagrantc: from what I've read non-static variants wouldn't work because dynamically loading wouldn't be allowed to work from the container
<apteryx>unless you map the paths
<apteryx>Actually I've tried it and it doesn't work, this is what Guix uses when you configure the qemu-binfmt service
<apteryx>it gets away with it in the case of guix-daemon by adding many --chroot arguments to bind expsoe transitive dependencies of qemu (so that it can dynamically load them from the container)
<apteryx>s/bin expsoe/expose/
<apteryx>I have tried the dynamically linked QEMU with the fix binary (F) binfmt_misc flag though
<dftxbs3e>leoprikler, still looking, but will continue tomorrow!
<marusich>dftxbs3e, do you know what the syscall id for clone is on ppc64le? I want to add it to guix/build/syscalls.scm (search for existing string "mips" to find the code I'm looking at), since I think that might be why some guix tests are failing.
<marusich>I am not sure how to find the syscall id, although it seems like it should be trivial........
<nckx>marusich: arch/powerpc/kernel/syscalls/syscall.tbl ?
<marusich>It seems like it is 120.
<nckx>Would make it 120.
<marusich>Where even is that file? sigh
<marusich>I guess it's automatically generated (of course it is..) in glibc
<marusich>whatever, 120 it is
<nckx>marusich: In Linux.
<marusich>The clone procedure hard-codes these, presumably for linux.
<nckx>I assume (but haven't checked) that glibc simply includes the kernel definition.
<marusich>FWIW there is a TODO that says "don't do this" :)
<marusich>Thank you for the help!
<nckx>Thank you for the work.
***seepel1 is now known as seepel
<jackhill>When creating a package for a daemon, for which there will be a system service, should anything special be put the in the package description?
<leoprikler>What special thing are you thinking about?
<leoprikler>$package is next to useless from command line, use $service instead?
<jackhill>leoprikler: Something to directly people reading the description to documentation for the shepherd service.
<leoprikler>I don't think that's done anywhere in Guix. See e.g. the gnome package, which is used for gnome-desktop-service-type.
<jackhill>Perhaps, it's not nessisary, or something we ordinarily do, and that's okay, but as long as I'm writing the description I thought I would think about it :)
<vivien_>Hello! Today I've been busy writing a caching web client for guile. With promises and futures, it was really fun!
<jackhill>vivien_: cool, perhaps you'd be interested in submitting it to the Guix Potluck 2021!
<leoprikler>Guile Potluck?
<jackhill>er, yes, Guile potluck
<jackhill>although perhaps the Guix Potluck would be a good Guile potluck entry: :)
<vagrantc>apteryx: yeah, the F flag is key to it being amazing :)
<vagrantc>apteryx: i think because the kernel is handling it, it isn't limited by the chroot of the working environment ... but further testing needed to be sure
<brown121407>Hi, Guix! Knowing that we have a "kernel" field in the operating system configuration and that Guix works on at least two kernels (Linux and Hurd) does this mean that we could one day have a GNU/BSD operating system with Guix running on top of a *BSD kernel? Is this possible?
<pkill9>brown121407: i think someone/some people have looked into that, i can't remember what the verdict was
<pkill9>i think nckx may know
<cbaines>I think one issue is software support for the kernel, glibc works with Linux and the Hurd, but I'm unsure about BSD?
<vagrantc>debian has a GNU/kFreeBSD port which has some patches (maybe upstreamed by now), but it isn't a very mature port. but definitely possible
<vagrantc>(e.g. GNU userland, FreeBSD kernel)
<brown121407>cbaines, does Guix directly depend on glibc? I mean, is it something in glibc that other libcs don't have that makes Guix work?
<vagrantc>so, theoretically possible, though i think guix relies (or at least prefers to have) some linux specific features for the container features used to build packages and such
<cbaines>brown121407, Guix doesn't directly, but most things packaged for Guix directly or indirectly use glibc
<jackhill>What about nscd, is that a glibc feature, and how important is to to Guix to avoid loading conflicting libcs for name and other database lookups?
<nikita`>guix is very glibc specific. i abandoned my explorations of a port to netbsd because it also needs to support the kernel + libc combinationation (more or less). freebsd gets away with some linuxisms in their kernel, but i have no idea if glibc works for them with lots of pretending and patches. doesn't for us, and doesn't for openbsd as far as i can guess
<nikita`>the us here = netbsd
<nikita`>also for anyone suggesting the idea of GNU/BSD combination seems somewhat okay and who doesn't approach this from a Linux perspecitve, please take 5 steps back from the idea and look at what makes BSD BSD and why this is a bad idea.
<rekado>jackhill: nscd is part of glibc. It is indeed used to provide a stable client-server protocol for user names as an alternative to loading plugins that have been built for a different C library.
<milkey>a step in that direction would be getting stuff building on top of musl libc instead of glibc
<rekado>milkey: there’s really no point in doing this without glibc
<leoprikler>nikita`: what makes BSD BSD?
<rekado>you can swap out kernels easily (as long as they are supported by the glibc), but you can’t easily swap out any of the lower level parts that the Guix package graph is built upon.
<vagrantc>huh. never made the connection between the SD in BSD and the "old" GuixSD
<milkey>i would be interested in a version of guix using musl & clang instead of glibc & gcc but it's not worth spreading the developer effort too thin
<milkey>coming from gentoo I'm used to doing weird things like swapping out one libc for another, but I appreciate stock guix breaking much less often :P
<apteryx>vagrantc: I'll try it, if I get the time tonight
<vagrantc>milkey: wow, surprising to hear there are other systems that break more :) i really like guix and all ... but it does have some surprising tracebacks pretty often. :)
<milkey>at least when guix breaks it's reproducible most of the time
<sundbry>it might work on illumos, it has a linux kernel compatibility mode built in
<sundbry>that would be an interesting project ffor a hypervisor running on guix
<leoprikler>For a software that breaks all the time, Guix is surprisingly stable :)