IRC channel logs


back to list of logs

<jonsger>can `linux-arguments` used without an extra (boilerplate) menu entry and instead be used for the currently used kernel?
<jonsger>ah thats called kernel-arguments :)
<apteryx>we've officially passed the 20k packages count!
<nckx>I'd like to thank everyone who made this possible, and also Rust.
<drakonis>rust mvp
<nckx>Almost 3K packages alone.
<podiki[m]>what was lucky 20,000?
<apteryx>nckx: all 3K plagued by CVE 20202-21658 ^^ (
<nckx>I would like to unthank Rust.
<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.
<podiki[m]>but but system language!
<podiki[m]>back on my grafting journey, think I found a (new?) weird thing
<apteryx>what is it?
<podiki[m]>the union-build from before seems expected; grafting: just replaces the store path, so something like a change in version of<version> will be wrong
<podiki[m]>but now I'm doing it with 64 and 32bit together (not sure if this is the cause) and one is grafted and the other not
<podiki[m]>in other words, building the library twice in union-builds as inputs to a package, and one doesn't seem to get grafted
***califax- is now known as califax
<podiki[m]>perhaps grafting just happens once or somehow misses another same input (but different architecture)?
<podiki[m]>I know this is outside of what any regular package does, I think, but I'm not sure if it is some combo with union-build or mixing systems in inputs
<apteryx>have you shared your investigation to guix-devel or somewhere?
<apteryx>someone in the know about grafts may be able to chip in
<podiki[m]>ludo chimed in earlier to explain, but now I have the new example
<podiki[m]>likely doing something that is unexpected from the usual guix packaging, but I would expect it to work (might be on my end)
*vagrantc watches guix-build-coordinator-agent fire up packages builds
<vagrantc>going to have to put it to sleep, though
<PotentialUser-7>I can't find much information about PXE boot in the manual. Is it supported?
<vagrantc>there was someone who worked on network booting guix a while back
<Ribby>I hope it wasn't me?
<PotentialUser-7>Any chance you remember who it was or where it was talked about?
<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.
<apteryx>There's nothing like /etc/crypttab in Guix yet, right?
*apteryx was trying to figure out how to automount an external, LUKS-encrypted drive
<PotentialUser-7>Ribby: I am currently evaluating Guix for a deployment to a trial fleet of 20 servers(and hopefully more if it goes well)
<PotentialUser-7>vagrantc: thanks, will check that out. I guess if PXE doesn't work out I could deploy a different distro and script a Guix installation.
<vagrantc>yeah, doesn't look like it got merged in the end
<Ribby>PXE needs to be researched for its use in guix as well as gnu derivatives. Same for anything new. Boot and bootloading could be a serious matter!
<vagrantc>can't recall, but i suspect i've also heard of other people using network booted guix
<vagrantc>without booting, there's no computer.
<vagrantc>well, no useful computer ...
*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
<vagrantc>and maybe an early libc?
<janneke>alMalsamo: GNU Mes is used to bootstrap, it builds the mes c library and tinycc
<janneke>alMalsamo: guile is only used to run the guix builder, and to run gash, because gash is not ported to mes yet
<vagrantc>alMalsamo: there are a couple blog posts about it, where the size of the bootstrap seeds was reduced in half each time (~75% the size of the original)
<vagrantc>janneke: and hi! :)
<janneke>vagrantc: yeah hi :-)
<alMalsamo>Yes I've seen those blog posts
<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
<vagrantc>or working in all directions...
<vagrantc>so "what's the point?" kind of seems like an odd question
<vagrantc>the point being working toward a goal
<alMalsamo>vagrantc: I never asked "what's the point" what are you referring to?
<alMalsamo>Also what is boot0 I am familiar with stage0 but that is a different name?
<vagrantc>ah, i guess it was "what is the purpose of"
<alMalsamo>Well I asked that because it doesn't seem like the Scheme intepreter of GNU Mes was used in current Guix bootstrap process
<vagrantc>it was used to produce the seed, but not as part of the source bootstrap
<vagrantc>but mescc is written in Mes scheme, so ... it is used?
<vagrantc>the seed is the scheme interpreter, no?
<vagrantc>anyway ... gotta head ...
*vagrantc waves
<janneke>alMalsamo: again, the gnu mes scheme interpreter is used in the bootstrap, see the blog posts that vagrantc pointed to, or see the code
<janneke>alMalsamo: please stop suggesting that it "seems not to be used", that's just an idea in your head
<cehteh>is there some educational tutorial how to bootstrap guix?
***whound is now known as winterhound
***winterhound is now known as whound
<civodul>Hello Guix!
<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
<civodul>do you find it's taking too long?
<demotri>civodul: It takes longer and longer.
<demotri>I could more-or-less live with that.
<demotri>But since today, I stumpled upon the Korean problem.
<demotri>And could not yet solve it.
<civodul>demotri: did you run ./bootstrap?
<demotri>I tried all sort of things :-)
<demotri>I git-cleaned, bootstrapped, etc.
<demotri>The final thing I did not, was setting the LANG variable in the (pure) guix-environment.
<demotri>That's what I'm trying out right now.
<civodul>so what error did you get? the question marks?
<demotri>Yes, the question marks. Like in the above bug report (that seams to be solved).
<civodul>that suggests you're not using a UTF-8 locale, or the locale is not supported?
<civodul>if you do "guix shell -D guix", you get a working environment, including GUIX_LOCPATH
<demotri>Hm. I'm in a "guix environment --pure guix --ad-hoc ...", so, yes, there is no LANG variable set. (still doing the old environment style)
<demotri>GUIX_LOCPATH is set, but not LANG. So for now, I'm trying it with "export LANG=en_US.UTF8" set after entering the environment. Let's see.
<civodul>try "en_US.UTF-8" (note the hyphen)
<civodul>uh, interesting CVEs in util-linux's libmount and in glibc
<civodul>who wants more grafts? :-)
<efraim>gotta catch 'em all!
<demotri>civodul: Yes, I used it with the hyphen, I just wrote it out of memory, there the typo came in.
<demotri>It somehow didn't work. I'm starting from scratch with a new guix pull, git clean ... , etc
<florhizome[m]>I have a package that uses zig to build.... (full message at
<florhizome[m]>Zig seems to need clang to be around but I set “CC” to gcc
<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: This is gi-pango. This is the error "Failed to load shared library ''". The "cairo" Library has this .so file but why doesnt it linking.
<civodul>demotri: super weird, perhaps email all the details to bug-guix, it shouldn't be this painful
<rekado_>the disks are installed, but they don’t show up on
<rekado_>I guess the server considers them to be part of the virtual disk
***whound is now known as dust__
<janneke>alMalsamo: that's indeed kind of hard to see, when running mescc using -v it prints the scheme interpreter that is used
<janneke>and here CC is set to use mes, not guile
<rekado_>so, uhm, the disks are all connected to the same internal RAID controller.
<rekado_>hope I can make it expose these disks raw
<ngz>attila_lendvai: About versions in commit messages: your patch set is not the place to discuss it, but you're welcome to start a discussion on the devel mailing list about it.
<ngz>attila_lendvai: I'm not opposed to including versions when adding a package, but it's not what we do currently, and when in Rome, do as romans do.
<rekado_>yay, kicked the 6 new disks out of the RAID
<rekado_>my work here is done, I think
<demotri>civodul: Solved. Switching from "guix environment" to "guix shell" helped in the sense that it suggested the --check parameter; and indeed, it found two lines I messed up in my .bashrc :-)
<civodul>rekado_: yay!
<civodul>demotri: ah, that's good!
<rekado_>one more thing: the system messages tell me that /mnt_test (sdd) doesn’t have the “large directory” feature enabled
<rekado_>we should enable it (via tune2fs?)
<rekado_>anyway, biking back home
<civodul>i don't see large.*directory in "tune2fs -l" on my disk
<mroh>rekado_: No, I tried. One can't boot with grub afterwards, see
<attila_lendvai>ngz, FYI, i don't think rust-ethereum-types is an internal lib for that company. it's used by many other libs, it's types for standard Ethereum values like addresses.
*attila_lendvai is updating the patchset
<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?
<ngz>I don't see this line
<ngz>Where does it come from'
<ngz>Nevermind, I was not on master branch.
<ngz>Yes, you can sneak its removal in.
<ngz>attila_lendvai: ^
***aya is now known as gyara
<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.
<ngz>good as in automated.
<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.
<rekado_>nckx: oh, wow. That’s surprising.
<rekado_>I’ve enabled the feature on other machines like the server that serves the guix-daemon and /gnu/store for the MDC
<rekado_>these are CentOS machines, not Guix System
<rekado_>so they’re not booting from /gnu/store
<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.
<nckx>Nor've I revisited the matter since then.
<attila_lendvai>ngz, so, if i relax the zeroize dependency spec for both rbw and rust-rsa, then rbw compiles without errors. i'll update the patch to avoid adding the intermediate version of zeroize.
<ngz>attila_lendvai: OK.
<civodul>PurpleSym: hi! python-uvloop fails on power9:
<PurpleSym>civodul: I don’t have a PPC machine to investigate that issue unfortunately :( Weird that it only fails for one arch.
<civodul>yeah i suspect it's a non-deterministic failure that's not arch-specific
<rekado_>nckx: surprising that this would break booting with grub
<mbakke>funny guix shell bug: exiting a shell after running a non-existent command gives ...
<mbakke>guix shell: error: /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash: command not found
<mbakke>to reproduce: guix shell RET foo RET exit RET
<ngz>On a foreign distro, I get, unsurprisingly: /bin/bash: command not found
<PurpleSym>civodul: Can we restart that job for PPC and see if it happens again?
***minikN1 is now known as minikN
<PurpleSym>It builds fine multiple times on my local machine, but that’s still n=1, so…
***yewscion91 is now known as yewscion
<apteryx>if anyone was looking for a Btrfs subvolume-based backup solution, I've packaged and tested btrbk; seems solid.
<mhj[m]>Oh cool! I’m more interested in a home snapshot solution but I’ll give it a try
<apteryx>if your home is on a subvolume that's doable via btrbk
<apteryx>I'm still interested to know if there's a way to have encrypted external drives automounted at boot on Guix System
<vivien>Does guix depend on guile-json? Can I use it in a patch?
<ekaitz>hi guix how can I include all the inputs of a package using a manifest file?
<ekaitz>is there something like (inputs package-name)
<nckx>DYM package-inputs? All records support <record>-<field> accessors.
<nckx>A temporary gotcha is that is returns whatever ‘style’ the package happens to use. We're migrating gradually so whether you get an alist or not is currently a surprise.
<nckx>(Did I test that assumption? No. But even if you consistently get an alist now, don't count on it, is muh point.)
<ekaitz>aaah great
<ekaitz>i'm trying to add them to a (packages->manifest )
<ekaitz>with some extra stuff
<apteryx>vivien: what do you mean by "can I use it as a patch" ?
<vivien>"in" a patch
<vldn>still no wine64 substitute avaiable?
<vivien>It would be cleaner to generate a json string with a proper json library rather than with format
<nckx>Back on a Guix machine: p-i and p-n-i always return an alist. I was thinking of something else.
<nckx>vivien: Use (guix build json), it's pretty neat.
<nckx>I use it to customise Firefox.
<vivien>Thank you :)
<vivien>nckx, I think it’s not exactly the same data type, correct? Objects are (@ (key . "value") ...) and arrays are lists
<nckx>I have never used another library.
<vivien>There’s an SRFI for JSON
<vivien>189 IIRC
<attila_lendvai>srfi-189 is for Maybe and Either
<vivien>180 sorry
<nckx>How do you people even vaguely memorise that stuff.
<nckx>I repeat my last message with emphasis 😃
*nckx can remember 1 and… 26, and that's about it.
<vivien>19 for dates
<vivien>That’s pretty much it for me!
<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
<jpoiret>srfi-34/35 for conditions too
<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)
<sneek>Will do.
<apteryx>mhj[m]: here's my btrbk config file as an example, in case that's useful:
<podiki[m]>been meaning to look at btrfs snapshot backups too apteryx thanks for packaging!
<podiki[m]>though my home subvol should probably be split up since most of it is large amounts of data that don't need to be backed up
<mhj[m]>thanks apteryx !
<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?
<apteryx>perhaps it only does*
<redsith>hmm, let me try
<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?
<vivien>(line 325)
<vivien>Sorry you’re now the official help desk for (guix build json)
<efraim>ekaitz: my copy is here, there should be a copy somewhere on the gnu servers
<efraim> here's the other one, linked from
<civodul>vivien: unless you have a Good Reason to choose (guix build json), i recommend using Guile-JSON
<ekaitz>thanks efraim
<vivien>civodul, I’m trying to mock pypi and it would be clearer to use a json printer, is guile-json available in guix?
<civodul> requires it, it's used in many places
<civodul>maybe you can even use the JSON mappings in (guix import pypi)
<apteryx>anyone knows why 5.15-arm.conf has CONFIG_SND_EMU10K1=m but 5.15-x86_64.conf doesn't?
<apteryx>it's a sound card driver
<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
<civodul>how can we distinguish 127 from 127?
<civodul>we could set up a pipe so the child sends a message upon real 127 or something
<vivien>Wow, running all these guix tests made the computer heat my room
<vivien>For a cooler future, is there a way to only run one guix test and not the whole suite?
<civodul>vivien: yes, see
<vivien>3 polar bears saved
<phf-1>Hello Guix! How can I download the logs of the IRC so that I can grep things?
<apteryx>make check-system TESTS=elogind fails because the make-ext-image attempts to create a file system of 261k ('guess)
<apteryx>"Filesystem too small for a journal"
<apteryx>I'll ensure at least 1MB is choosen
<apteryx>this should fix it, according to man mke2fs "The size of the journal must be at least 1024 filesystem blocks (i.e., 1MB if using 1k blocks, 4MB if using 4k blocks, etc.)"
<apteryx>(it uses 1k blocks by default it seems)
<nckx>I filed a bug about this.
<nckx>Can't find it now.
<nckx>vivien: No idea, I just stumbled upon it :) civodul: <i recommend using Guile-JSON> Not on the build side surely.
<unmatched-paren>hi guix o/
<nckx>I can't test much as my laptop then broke.
<nckx>(Physical, not Guix.)
<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
<unmatched-paren>here's nim.scm:
<nckx>Oh no, now I have to switch.
<unmatched-paren>here's the build log:
<unmatched-paren>it's worth noting that nim shells out to gcc to build the final executable (it uses c as portable assembly)
<unmatched-paren>it's possible that nim is trying to build its stdlib, but can't find it; the /bin/sh error seems to say otherwise tho
<unmatched-paren>since we only see it try to build one `std_*.nim` file before failing
<apteryx>nckx: seems my fix works; does this look good to you?
<unmatched-paren>i'll try building from nimble's HEAD
<nckx>apteryx: I prefer mine TBH, but both are mere workarounds.
<apteryx>oh, apologies, I had missed your fix
<unmatched-paren>ok, HEAD is no better... :(
<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: 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>apteryx: Or so we assume.
<sneek>Will do.
<apteryx>nckx: what do we assume? :-)
<nckx>That it fixes an issue exposed by the behavior change.
<apteryx>what I meant is that mk2fs wants 1,000,000 bytes for a ext4 journaling file system; the change in size could have been due to many things; I'm not too interested in finding the exact cause.
<nckx>What's the problem then?
<nckx>I don't get it.
<apteryx>we were disagreeing whether your solution is a fix vs workaround; I think it's a fix!
<nckx>Who cares?
<nckx>If this is about writing 1e6 instead of (ash 1 20), feel free to choose whatever.
<apteryx>I've replied to the bug, no, I'm fine with (ash 1 20); although it not required it'll please tools more than 1e6 (such as parted). Feel free to push it!
<nparafe>Hi! I am trying to follow this guide: , but I'm stuck at pvcreate /dev/mapper/fde . I get -bash: pvcreate: command not found, any help?
<unmatched-paren>nparafe: i'm fairly sure i remember reading on that those guides were deleted because they were outdated
<unmatched-paren>`These guides were outdated, so they were deleted. You can find links to them here:`
<nckx>nparafe: pvcreate is provided by the lvm2 package.
<nckx>apteryx: OK, will read yreply later.
<unmatched-paren>nparafe: that quote is from
*nckx is stumped by the /bin/sh from hell.
<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.
<nckx>(Why the --branch=master?)
<nparafe>nckx following the guide doesn't mean I am understanding the guide :)
<unmatched-paren>nparafe: it defaults to master :)
<nckx>nparafe: :)
<nckx>OK, just curious. It's almost certainly pointless, but certainly harmless.
<jpoiret>just stumbled upon this
<jpoiret>it's a guix derivative
<nckx>I wonder what happened to them (if that's the right word; maybe they're doing fine, but they've been quiet lately).
<nckx>They used to semi-regularly frequent our channels a few years ago jpoiret.
<jpoiret>oh, alright! seems like their latest version is very recent
<nckx>And I think I saw an @pantherx address not long ago.
<nckx>I just can't remember who.
<nckx>jpoiret: Cool!
<nckx>I'm going to go for a run. Night all.
<nparafe>bb nckx
<nparafe>regarding pvcreate command not found, echo $PATH gives me: /run/setuid-programs:/root/.config/guix/current/bin:root/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin
<unmatched-paren>nparafe: looks like you've been running guix as root
<unmatched-paren>also there's a missing / in front of `root/.guix-profile/bin`
<unmatched-paren>should be `/root/.guix-profile/bin`
<unmatched-paren>actually, it really shouldn't be there at all; it should be `/home/_/.guix-profile/bin`
<unmatched-paren>guix should never be run with sudo (unless you're running `guix system reconfigure`)
<nparafe>I see, I thing it is impossible for me to continue. I'll keep an eye for an updated guide in the future.
<unmatched-paren>is it impossible
<apteryx>nckx: eh, no worries. later!
<unmatched-paren>do `sudo guix package --list-installed`, note every package you see, then `sudo guix remove` them all, then switch to your regular user and reinstall them
<nparafe>during installation, how do I exit root...
<unmatched-paren>ah... i see
<unmatched-paren>sorry, i didn't know you were doing installation
<unmatched-paren>try /root/.guix-profile/bin/pvcreate maybe?
<nparafe>/root/.guix-profile/bin/pvcreate didn't work, but /root/.guix-profile/sbin/pvcreate did the trick
<unmatched-paren>great! :D
<nparafe>thanks I am now advancing to the abyss of the unknown
<unmatched-paren>i guess rust must vender its stdlib somehow, so vendoring nim's shouldn't be impossible
<unmatched-paren>i think i've cracked it... maybe?
<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 May I ask you when you last time used it? I'm having problems with current version of mailutils
<zap>or I just don't know how to use it properly
<lilyp>alMalsamo: Satisfying business clients, perhaps?
<sneek>Welcome back lilyp, you have 1 message!
<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?
<cwebber>lfam: hi
<sneek>Welcome back cwebber, you have 1 message!
<sneek>cwebber, lfam says: Did you happen to see that TLS error again?
<nparafe>using the file as my config.scm duriing installation I get guix system error service swap-swap requires udev which is not provided by any service
<cwebber>I didn't while finishing the install, but if I bump into it again I'll mention it
<cwebber>maybe it would be a good idea to try to spin up a vm of the installer and see if repeating it a few times can get it to reappear
<lfam>Okay, thanks cwebber. If we can get the precise name of the file that failed to download, it will assist debugging
<lfam>Yes, I'll watch for it in my tests
<lfam>nparafe: Hello. I looked at your config.scm. What do you intend to do with your (services ...) section?
<lfam>nparafe: It appears that you tried to remove all services
<lfam>nparafe: Also, I'm certain that your uuid value "theuiddgoeshere" will not work
<nparafe>I am just trying to combine the scm in: with this:
<nparafe>yes I just removed the uid for the upload
<lfam>Oh, okay
<lfam>Okay, I recommend changing your (services ...) to look like this: (services %desktop-services)
<nparafe>Now I have: -->guix system error committing transactions: database or disk is full <-- The steps I did (apart from the scm amd adding /root/.guix-profile/sbin/ before some commands) are listed here:
<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`
<nparafe>Status of cow store \ it is started
<lfam>How big is the storage you are installing to?
<lfam>That's big enough!
<lfam>Does anyone else have any ideas?
<lilyp>lfam: writing to the wrong location?
<lilyp>I once put /etc instead of /mnt
<nparafe>,aybe this helps:
<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>i hope i don't have to do anything weird like #:nimble-inputs...
<phf-1>Hello Guix! I have a strange behaviour here. It appears that a dependency should be present but it's not.
<unmatched-paren>and i'm still suffering from the /bin/sh error from yesterday... :(
<rekado_>phf-1: by default “--container” does not have networking
<rekado_>add “--network” to access the network
<phf-1>should not be wheel present since python-wheel is in the maniefest ?
<phf-1>So, yes, it does work with "--network" but should it not work without?
<unmatched-paren>the web is mutable and thus not reproducible
<unmatched-paren>so nix and guix disable internet connections in their containers and chroots etc. by default
<rekado_>phf-1: I don’t know.
<rekado_>inside the container GUIX_PYTHONPATH should be set, and our Python will respect it to find packages.
<rekado_>so I would expect it to find the packages
<unmatched-paren>s/containers and chroots etc\./build environments/
<rekado_>is there a way to make Python print what locations it accesses to find packages?
<rekado_>perhaps that could give you an explanation
<phf-1>rekado_, yes, exactly. and actually, I can import wheel...
<rekado_>huh, odd
<rekado_>I don’t know enough about Python to guess what’s wrong, but I’d think that “creating venv isolated environment” would have something to do with it.
<rekado_>maybe it resets the variables?
<unmatched-paren>during a build process, / means `the directory that the build is taking place in`, right?
<phf-1>rekado_, ok, thanks :)
<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 /.
<unmatched-paren>nckx: thanks :)
<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
<unmatched-paren>lilyp: the thing is
<unmatched-paren>grep -r /bin/sh in the nimble repo returns nothing
<lilyp>hum, then perhaps it's in nim itself
<unmatched-paren>i did the same command in nim; some stuff comes up, but all of it has been patched out by whoever made the nim package
<unmatched-paren>no other inputs are involved other than the implicit inputs from gnu-build-system
<nckx>apteryx: I forgot I don't have access to Guix (or my keys)! :) Feel free to push & close whatever & whenever you see fit.
<unmatched-paren>lilyp: here's the recipe:
<unmatched-paren>and the build output:
<lilyp>does nimble have a --verbose flags like make?
<unmatched-paren>lilyp: s/nimble/nim/? nimble is what i'm currently trying to build (using nim) :)
<unmatched-paren>i'll try -v
<lilyp>I'm not sure, perhaps it's koch then
<unmatched-paren>you can see all the compiler flags here:
<lilyp>but you're execting src/nimble.nim from what I can see
<unmatched-paren>lilyp: yes
<unmatched-paren>koch does that for you, but since koch tries to download from teh interblags, we can't use it
<lilyp>and I'm asking whether that has a command line option to print out the full commands it's invoking
<lilyp>i.e. whether src/nimble.nim has such a flag
<unmatched-paren>ah, okay, i'll have a peek at it and see whether it takes flags
<apteryx>nckx: oh, that sucks! thanks for letting me know, and good luck with laptop recovery
<lilyp>unmatched-paren: btw for the record github tarballs are evil
<nckx>Thanks. Everything's safe.
<lilyp>An upside to Guix is that laptop failures are easy to recover from :)
<unmatched-paren>lilyp: src/nimble.nim does not appear to take flags
<unmatched-paren>lilyp: `github tarballs are evil` <- noted
<lilyp>hmm, it might be the "nim c" command.
<lilyp>what does that do?
<unmatched-paren>short for nim compile
<lilyp>write. it. out.
<unmatched-paren>we could try nim c --verbosity:3
<lilyp>try --verbosity:9001 just to be on the safe side
<lilyp>I'll take a nap until roughly tomorrow.
<lilyp>Let's hope Nim folk take printf debugging seriously.
<unmatched-paren>uh, 3 is _very_ verbose; it prints stuff about code being `GC unsafe` etc.
<unmatched-paren>not something that we need, i'll try 2
<unmatched-paren>lilyp: well, it'll be `echo` debugging in nim... :)
<unmatched-paren>here it is, with the GC unsafety bits snipped
<unmatched-paren>huh, looks like we don't have to vendor the stdlib actually
<unmatched-paren>somehow it magically appears in the cache :)
<unmatched-paren>ok, i'll try again tommorrow... o/
<zacchae[m]>If I "guix package --switch-generations=N", then guix describe will show the commit string for THAT generation, correct?
<rekado_>apteryx: were you going to set up the btrfs raid thing on berlin? Or was it mothacehe?
<rekado_>just so there are no misunderstandings: at this point I don’t know what to do and someone else needs to take over
<apteryx>rekado_: I don't mind to take on from here
<apteryx>so the drives are exposed to Berlin already?
<zacchae[m]>I ask because I'm trying to install a non-broken version of qutebrowser on another machine. I tried guix time-machine --commit=(N's commit) -- package -i qutebrowser, but no dice
<apteryx>rekado_: by the way, thanks a lot for seeing to it (purchase & installation!)
<shtwzrd[m]>Is there a way to get `guix shell` to output the GUIX_ENVIRONMENT variable, or otherwise tell us where the resulting profile is? Similar to `--search-paths`?
<rekado_>apteryx: yes, see also my mail to guix-sysadmin
<rekado_>the disks are exposed as single device nodes (up to /dev/sdj or something)
<rekado_>it may be a little difficult to tell them apart from the device nodes for the multipath SAN
<civodul>rekado_: \o/
<civodul>shtwzrd[m]: no
<zacchae[m]>alright, figured it out. I should have used guix package --export-channels, not guix describe
<civodul>zacchae[m]: right, "guix describe" shows the info of 'guix' itself, not that of ~/.guix-profile
<apteryx>rekado_: I see! so from sdg to sdl
<zacchae[m]>civodul: thanks
<zacchae[m]>On a related note, how is it possible that building using the channels from and old, working, profile could not build those same packages on a new machine?
<zacchae[m]>I thought guix was super reproduceable?
<civodul>zacchae[m]: usually you should be able to rebuild the same things on the new machine, but there could be issues like disappearing source or non-deterministic issues
<civodul>what was your experience?
<civodul>(we're working on disappearing source with Software Heritage, among other things)
<zacchae[m]>It failed to build password-store. It looks like the same error that cropped up a few days ago, but this generation is from back in December, so it "shouldn't" break
<zacchae[m]>I.e., password-store works fine on the machine/profile I took the channel spec from
<civodul>what Guix commit is that?
<zacchae[m]>One sec
<zacchae[m]>but i see a comment in the channel file as well:
<zacchae[m]>;; Note: these other commits were also used to install some of the packages in this profile:
<zacchae[m]>;; "e21b422f7ff85570c5ff6c9ce98775744f672776"
<zacchae[m]>maybe that's my issue
<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