<apteryx>It's somewhat amusing to think that not only Rust is not immune to CVE (duh), but it makes it near-impossible for a distribution to issue a timely fix, thanks to its irresponsible static linkage FTW attitude.
<Ribby>Well, the installation provides an option for network updates/upgrades. You can use an ethernet to get it going. Of course, if you are using PXE as in a specialized server, I hope you know your commands before boot networking connection.
*vagrantc meant to say "without booting, there's no computing" but missed the chance
<alMalsamo>So apparently I heard Guix still depends on Guile binary to bootstrap... what is the point of GNU Mes Scheme interpreter then?
<ulfvonbelow>does the --new-instance flag of icecat work for anyone else? It always produces a "Icecat is currently running, but is not responding" error for me, which would seem to contradict the point of --new-instance...
<vagrantc>alMalsamo: eventual goal is to get rid of the guile bootstrap binaries
<alMalsamo>vagrantc: Hmm okay so what is the purpose of the Sceme interpreter portion of GNU Mes if it's not used to bootstrap?
<janneke>alMalsamo: where did you get the idea that it is not used?
<timmy>does anyone have an example for setuid-program-service-type in a config.scm that only does setgid?
<alMalsamo>janneke: Hmm I dunno when is it used in Guix then? It's not used to bootstrap and once Guix is installed the Scheme interpreter is always Guile as far as I understand it...
<timmy>sendmail: this program must be setgid smtpq
<vagrantc>alMalsamo: it's used to build other tools early in the toolchain
<vagrantc>alMalsamo: notably, mesCC, which is a minimal C compiler writing in Mes scheme.
<vagrantc>alMalsamo: which can, after jumping through some hoops, bootstrap gcc
<alMalsamo>But as I understand it there are two parts of GNU Mes, the Scheme interpreter written in C, and the C compiler written in Scheme. I understand the C compiler is use to build mes c library and tinycc, but the Scheme interpreter portion of Mes is apparently unused currently?
<alMalsamo>janneke: Also Gash + Gash-utils doesn't run on Mes yet? I thought Mes supported Guile Scheme, what needs to be changed in Mes to support Gash?
<vagrantc>you can build mes with mes to do diverse double compilation...
<vagrantc>which we did a weak version of in late 2019...
<vagrantc>three distros reproducing a bit-for-bit identical mes
<vagrantc>alMalsamo: the work to bootstrap mes from the boot0 and all that is not yet done ... gotta start somewhere, and you don't necessarily *have* to start only at the beginning, you can fill in gaps in the middle working from both directions
<whound>Whats the work flow for building pacakge definitions form hackage packages ?
<alMalsamo>janneke: Hmm I apologize for not understanding, I am a newb compared to you who is a wizard, so I read the blog post another time but it is still not clear how the Scheme interpreter is used in bootstrap process in this post... maybe the only thing I can see is the dependecy graph which starts with "bootstrap-mes" but I don't know if this package refers to the GNU Mes Scheme interpreter or the GNU Mes C
<alMalsamo>compiler written in Scheme. Also right alongside this package is listed "bootstrap-guile" which makes me assume that Guile is used as Scheme intepreter for bootsrap not GNU Mes, but apparently I am incorrect?
<alMalsamo>The blog post I do not find to be clear. And the documentation for bootstrapping from source in general in Guix docs I find to be lacking, the last time I tried installing Guix it just downloaded substitutes and I really didn't want that I wanted to compile everything from source and couldn't figure it out.
<alMalsamo>I previously DID compile from Ludo's bootstrap binaries back in 2015 but GNU Mes didn't exist then so I know it is possible
<alMalsamo>But when I tried Guix last year it only downloaded substitues and couldn't figure it out
<alMalsamo>But because the blog post is lacking I guess the best option is to study the code which I would like to do but it will take me a long time because I am such a n00b
<janneke>alMalsamo: "listed "bootstrap-guile" which makes me assume that Guile is used as Scheme intepreter for bootsrap not GNU Mes"
<janneke>that's a reasonable and logical assumption, but it's incorrect
<janneke>alMalsamo: in a way it's strange not to use bootstrap-guile to run mescc because it's available and better, but the whole point of introducing mes+mescc is to show that we can remove the dependency on bootstrap-guile
<demotri>Can I build the guix source code without the docs?
<alMalsamo>Okay then, but the dependency on bootstrap-guile is not removed yet, so how is the GNU Mes Scheme interpreter used in the bootstrap process? I don't see any explanation of this on the blog post but you said it *is* used so I trust you, I just don't understand how/where (and again sorry for being a newb who hasn't studied the fucking code yet which would solve my questions no doubt)
<civodul>demotri: not really, docs are a dependency of the default makefile rule
<attila_lendvai>ngz, re versions in commit messages: it's very useful, and i badly miss them in the git log. do we value uniformity above usefulness? if so, would it be possible to change the rules to also include the version when a package is added?
<attila_lendvai>my motivation is quickly evaporating now that i have a working openethereum-binary package. but OTOH i do want to fit in, because i really like the Guix experience, and if it'll remain my primary OS then i'm pretty sure i'll have many other patches coming... i'll try to gather enough motivation for one more round.
<whound>Guys I'm trying to build some hackages. package def: http://ix.io/3NsJ. This is gi-pango. This is the error "Failed to load shared library 'libcairo-gobject.so.2'". The "cairo" Library has this .so file but why doesnt it linking.
<alMalsamo>HI all someone on Session is talking up Flatpack which I have never heard of before, they claim it can "give access to only and only one file on the entire system to giving read only access to only one directory or entite system, you can even controls system buses, GPU, hardware acceleration, etc." and talk about sandboxing apps
<alMalsamo>How does Guix compare to sandboxing and fine-grained controls offered by Flatpack?
<ngz>attila_lendvai: Fair enough. That was just a suggestion.
<attila_lendvai>ngz, there's an annoying empty first line in crates-io.scm that my emacs keeps cleaning up. shall i indclude its removal in the first commit, or leave it out from this patchset?
<attila_lendvai>ngz, roger. re rust-zeroize: i have no clue whether the requirement can be relaxed or not. probably not, because a new release still sticks to the old version. if i relax it, and it compiles without new warnings/errors, would that qualify?
<ngz>attila_lendvai: Sometimes Rust developers are over-cautious and minor-version restrictions may not be warranted, IMO. If it compiles without errors, that's fine. OTOH adding an intermediate version is not the end of the world, but we currently have no good way to clean old unused Rust libraries, so they just stack up.
<attila_lendvai>rust-rsa (a dependency) also has explicitly version = ">=1, <1.5"
<attila_lendvai>and my update broke it that didn't materialize due to #:skip-build? #t
<attila_lendvai>ngz, what's the deal with the #:skip-build?'s? when shall we use it? i have no intuition about it...
<ngz>attila_lendvai: Well, there is no consensus about it. I put it in any non-leaf crate. Otherwise, it is just too long to tests builds, at least on my machines. It is also useless, because whatever would be built would not be re-used later on. OTOH, many developers think actually building intermediate crates is a good way to know if everything is correct, even if the build is a waste.
<ngz>attila_lendvai: Another point is that not skipping builds implies adding cargo-development-inputs, so more dependencies, and more Rust hell.
<nckx>rekado_: Surprising as in doesn't match your experience, or just that it hasn't been fixed yet? It's possible that it only breaks with(out) a combination of other options set. I have no personal interest in ext4 and didn't test a full tedious matrix.
<vivien>Anyway, SRFI 180 is very close to guile-json: objects are alists and arrays are vectors. The difference is that guile-json prefers to build alists with strings keys and SRFI 180 requires symbols
<vivien>I’m not aware of an april-1st-type SRFI, but one may very well exist
<ekaitz>efraim: you had a tutorial about building sources with guix didn't you? it was called "build it with guix" or something similar, do you have a link anywhere? I can't find it
<podiki[m]>vldn: there are wine subs I see...? but no "staging" ones as that wasn't updated for wine 7.0 (is there a staging currently?)
<podiki[m]>sneek: later tell whound I have all of the haskell gi (and taffybar) package defs, but working on cleaening up to submit them; it needs a different gobject-introspection for cairo (I think same error you're seeing)
<redsith>Hi guys, i cant get gpg working. I have the gnupg + pinentry packages installed but when i try to decrypt a file it says no pinentry, although pinentry-curses is in the path (/run/current-system/profile/bin/pinentry-curses)
<apteryx>hmm, perhaps do the right thing without further configuration when pinentry is installed to your user profile?
<redsith>ok, that works. Guess it needs to be in the user profile. Thanks
<mhj[m]>I'm planning on re-installing Guix with full disk encryption and a separate home partition for the btrfs backups, just to make it easier. Altho I am aware of btrfs subvolumes, I'm not quite up to Guile Scheme syntax to be able to write my own operating system definition. The most I've messed with are packages, services and my user profile.
<vivien>Huh, nckx, why does the json printer in (guix build json) escape forward slashes in strings?
<mbakke>the zabbix-web service goes some lengths to support a 'db-secret-file', presumably to avoid copying the database password to the store; but then goes on to embed the password in /gnu/store/...zabbix.conf.php anyway
<mbakke>civodul: did you see this funny 'guix shell' bug? guix shell RET command-that-does-not-exist RET exit RET ? :)
<civodul>mbakke: i did! it is fun, i'm not sure what to do about it
<unmatched-paren>`Could not find command: '/bin/sh'. OS error: No sucb file or directory 2` seems to imply that it can't find /bin/sh... but the package i'm adding (nim-nimble) does not mention /bin/sh in its source anywhere. (nim itself does, but it's patched out in the recipe.) does this error mean something else?
<unmatched-paren>also `Error: invocation of external compiler program failed. No such file or directory`, but `/bin/sh` isn't a compiler program...
<nckx>I wouldn't ascribe too much value to that last detail.
<civodul>nckx: can be used on the build side now that we have gexps all around, except if that poses bootstrapping issues
<apteryx>nckx: something in the behavior has changed across kernels, alright; but capping to a value that are actually usable with file systems is not a workaround, in my opinion
<apteryx>it fixes an issue exposed by the behavior change
<zimoun>civodul, or anyone: on a fresh checkout, I get this error: «guile: error while loading shared libraries: libguile-3.0.so.1: cannot stat shared object: Invalid argument» and I have no clue how to debug that.
<unmatched-paren>sneek: later tell lilyp: re. nim-nimble shelling out to git and/or hg, i just recalled earlier that ocaml's opam package manager does the same (but with more; afaik it also supports svn, darcs and rsync)
<nckx>I suspected unistd.h but nope. Or not AFAICT.
<nckx>apteryx: apologies, I had missed your ’apologies…’ line above and totally misjudged you.
<nparafe>nckx lvm2 is installed, I installed it using guix pull --branch=master && guix install lvm2
<unmatched-paren>maybe the `Additional info: .../bin/sh...` line is completely irrelevant... all the signs seem to be pointing to "the Nim compiler is trying to build Nim's std but is failing" except that line
<nckx>Then something's wrong with your $PATH nparafe.
<alMalsamo>What's the point of PantherX except to allow non-libre software? Why wouldn't these people just not help develop Guix?
<zap>Hey civodul! I've been looking for some examples of mailutils and found your (email) module on gnu.tools. May I ask you when you last time used it? I'm having problems with current version of mailutils
<sneek>lilyp, unmatched-paren says: re. nim-nimble shelling out to git and/or hg, i just recalled earlier that ocaml's opam package manager does the same (but with more; afaik it also supports svn, darcs and rsync)
<lilyp>unmatched-paren: to clarify, shelling out to git is no hard blocker, but it's important to consider that it can't do that inside of guix build nim-foo
<lfam>sneek: later ask cwebber: Did you happen to see that TLS error again?
<nparafe>Just a parenthesis. today is the day I am doing my taxes. It is the most boring job in the unverse, so instead I am trying to convice myself that installing guix in a librebooted computer with encryption, is more urgent.
<lfam>nparafe: I guess it ran out of disk space. Does that seem likely? If not, maybe the instruction to run `herd start cow-store /mnt` was skipped? That starts a service that ensures that the system is installed to the target disk
<lfam>You could also check the status of that service with `herd status cow-store`
<unmatched-paren>lilyp: yeah, i get that i'll have to vendor things like with cargo. i've already figured out how to do that with nim _packages_, but i can't figure out how to do it with the nim _standard library_ (which is seperate, because... uh...)
<unmatched-paren>Still getting `Error: invocation of external compiler program failed. OS error: No such file or directory \n Additional info: Could not find command: '/bin/sh'. OS error: No such file or directory 2`, apparently i've not cracked it... There are no mentions of /bin/sh in the nimble source, and all places where it appears in nim itself are patched out...
<nckx>unmatched-paren: No, builds don't see themselves as happening in /, by default they happen in /tmp/guix-build-foo-1.drv-0 inside the container. / really is a (very restricted) subset of your real /.
<phf-1>rekado_, indeed, you were right. It's a Python build thing since: ~python3 -m build --no-isolation~ works.
<nparafe>Is it possible I get the no space left error because I have started the installation using the "gui" untill the wifi setup and later changed (alt+F2) to terminal?
<unmatched-paren>well, i've figured out how to vendor nim's stdlib \o/ but i still get the /bin/sh error /o\
<unmatched-paren>(symlink (string-append nim "/lib") "guix-vendor-std"), then (invoke "nim" "compile" "--lib:guix-vendor-std" "-o:nimble" "src/nimble.nim") will hopefully work once i figure out the /bin/sh thing...
<lilyp>unmatched-paren: is that hard-coded in some known location in nimble? if so, you might want to consider making it read the SHELL environment variable or something like that
<zacchae[m]>wait, no. I probably installed something after rolling back. It shouldn't be an issue, as password-store and qutebrowser were installed originally
<zacchae[m]>oh, interesting. The commented hash is the one I wanted. I guess I guix pulled without installing from manifest at some point? The problem is probably something I did, and not a problem with guix. I got what I wanted working anyway
<civodul>zacchae[m]: yes, if you don't install from a manifest, --export-channels will list several commits, because effectively your packages may originate from different commits
<civodul>if you use manifests, there'll always be just one commit