<dustfinger>tricon: I will let you know. I have not had any time to play with it. I assembled it at the end of the day yesterday and my weeks are generally quite busy. I will post back here though after I have had time to get to know the system more.
<dustfinger>I really hope I get get guix working on it with decent performance. It sounds like it will be a challenge, which I don't mind, but that also means it won't happen immediately.
<dustfinger>tricon: I was actually going to buy the pinebook pro before I discovered the mnt-reform.
***zub2 is now known as zubbie
<zubbie>anyone know how to see the config.scms the installer uses? trying to learn and seeing those examples would help!
<podiki[m]>guix-devel or discussion on the patches? not sure
<sia[m]>what are the minimum hardware requirements (memory, storage, cpu) for gnu guix system?
<lechner>sia[m]: i run it on a 1G nano linode, but updates can take a while
<lechner>sia[m]: also, i think you'd do well with 80 G to 200 G in disk space for anything holding graphical user programs. the garbage collector can be a bit aggressive, so i do not run it often right now
<sia[m]>lechner: i'm planing to install on a 1g ram as well. i don't have that much storage, but i'll see if i can do it anyway and upgrade otherwise. thanks for the help!!
<lechner>sia[m]: please focus on booting first (perhaps via mapped-drives). you may end up installing twice, and everything else may end up being a waste of your time the first time around
***rekado_ is now known as rekado
<lechner>Hi, how can I provide myself a patched version of /share/X11/xkb/symbols together with xkeyboard-config 2.34, please?
<lechner>Hi, would someone please offer some packaging advice? I'm taking baby steps! The vendored Golang prerequisites probably have to be packaged separately, but why are the input declarations causing errors, please? http://paste.debian.net/1239753/
<lechner>Also, how can I bump the open file limit in Guix, please?
<luke-jr>littlebobeep: well, that's part of why I am not installing Guix on my main workstation ;)
<luke-jr>littlebobeep: AFAIK some others have in fact done it tho
<luke-jr>is there a way to ask Guix for a status report and/or time estimate?
<littlebobeep>luke-jr: Ahhh well nothing in commencement.scm but I see powerpc64le bootstrap binaries referenced in bootstrap.scm and according to bjc's link yes it is supported platform, but from your words you don't even want to use these bootstrap binaries? Without stage0-posix support you will need to cross-compile I guess...
<bjc>hopefully the cross compiled binaries that are built will match the existing ones. although i think i saw in the ml today that guile is one of the ones that fails a challenge
<luke-jr>littlebobeep: my goal for a Guix install I fully trust, would be to create the bootstrap binaries with my existing system
<luke-jr>cross-compiling from Guix isn't a solution for me tho
<luke-jr>littlebobeep: I would guess GCC 4.7 doesn't support PPC64LE
<littlebobeep>luke-jr: Well I did not read all responses in bug #41669 yet but if the bootstrap binaries are not reproducably built during cross-compilation that kind of fucks up the entire trust chain
<littlebobeep>luke-jr: Why can't you cross-compile from Guix? Don't you have x86_64 hardware? How else will you bootstrap?
<luke-jr>littlebobeep: I don't trust Guix yet - the point of this exercise would be to build a Guix I do trust
<luke-jr>littlebobeep: so what I'd want to do, is figure out the right version of GCC etc to build with my current system, to build matching bootstrap seeds
<littlebobeep>luke-jr: Ahhhh okay fair enough but do you trust Guix starting from stage0-posix going to M2-Planet then Mes and TCC?
<littlebobeep>luke-jr: I am not sure what OS you could reasonably trust if not this ^ to cross-compile your POWER9 bootstrap binaries
<luke-jr>littlebobeep: my old workstation was x86_64 Gentoo, bootstrapped from a stage1 over a decade ago
<luke-jr>I cross-compiled a PPC64LE USB boot on that
<littlebobeep>But didn't stage1 just use an old version of GCC to compile a new version of GCC + even larger binary seed than Guix currently bootstraps from? I never started from stage1 Gentoo but as I understand it they never implemented diverse double compilation
<bjc>thankfully, guix does have that information. you can see what versions of the bootstrap tools it uses, then cross compile those yourself. then you should be able to put it into the expected paths in the tarball and go
<bjc>you will need to adjust the sha of the tarball, though, since it's not actually reproducible according to 41669
<luke-jr>bjc: it would be nice if you could inject tools that don't match, then produce matching outputs that adopt the same hash as the normal ones
<oriansj>oh and if anyone has PowerPC hardware and wants it properly bootstrapped contributing to M1 macro assembly developmenet in mescc-tools is an important step
<luke-jr>eg, if the input data hashed included only the actual inputs, not the recursive hash of the input's inputs
<bjc>luke-jr: that's a pretty big violation of guix's expectations
<djeis>You couldn't even define a package until you'd already built all of the inputs to that package, and different ways of building a dependency would result in totally different package definitions.
<djeis>Grafting is taking a built package and changing one of its dependencies by replacing paths in the content of the package.
<djeis>It produces a new package where the dependency has been replaced.
<bjc>if things are working well, they'll converge, since the bootstrap will build the next phase, which should now be at least the same version of things built the way guix expects it, and then the build from then on should be, ideally, the same as what the substitutes servers produce
<djeis>It lets you change a dep without doing a full rebuild.
<djeis>Nix does something similar to grafting to implement content addressing.
<luke-jr>bjc: but the input hashes won't match still
<bjc>you will likely have to change a fair few hashes on the first post-bootstrap rebuild, yeah
<djeis>He's suggesting you build the bootstrap tarball using the bootstrapped guix.
<bjc>and maybe some after that, but it should be fewer
<djeis>Then you take that new bootstrap tarball and bootstrap a new guix out of it.
<djeis>In the hope that eventually you produce a bootstrap tarball with the same hash as the one we already use.
<djeis>B/c the guix you bootstrap off of that will have the same hashes as ours.
<luke-jr>I think I might have actually tried that once, and didn't get far
<luke-jr>probably because I didn't/don't know what I'm doing XD
<djeis>Since the bootstrap tarball is a fixed-output derivation (a content-addressed/content-hashed dependency) it doesn't mater what you used to build it.
<djeis>But if you use an already bootstrapped guix to build it you have a better chance of producing the same bootstrap tarball we're already using.
<djeis>At which point the rest of your dep tree will match.
<bjc>i don't know if you have to have the tarball match exactly, since presumably the things that differ are going to be minor (rather than a sign of broken code or malfeasance), in which case, even if the hash for, say, gcc is different, the binary produced by that gcc will still be bit identical with the one produced by the existing bootstrap tarball
<bjc>rebuilding the bootstrap tarball is probably the most straightforward way to get to that point, but i wouldn't go past doing that 2 or 3 times
<djeis>Well, for the bootstrap tarball that's actually at the root of the derivation tree it would need to match exactly.
<luke-jr>djeis: the hard part was getting Guix to accept the divergent bootstrap tarball
<djeis>I would expect that'd just be a matter of editing a sha at the right spot in the code.
<bjc>does guix actually verify the hash of the tarball after its been downloaded?
<luke-jr>djeis: IIRC Guix wanted a different hash than the one it injected it with
<djeis>Well, the definition probably cites a particular place it tries to download the tarball from so you might've needed to change that too? I've not actually looked at the in-tree definition of the bootstrap tarball... Lemme see if I can find it.
<bjc>oh, is the bootstrap tarball the root of all packages?
<bovid-19>Hi! I've installed an Emacs based on emacs-with-native-comp (from github.com/flatwhatson/guix-channel), but transformed to use the master branch (http://paste.debian.net/1239789). Now I'd like to pin it so it doesn't recompile as soon as I use it as an input of another package. Is there any way to find out which commit a package was built from? I had a look at the symlink I got from `which emacs-29.0.50', hoping I could use the
<bovid-19>shortened hash in the directory name, but it's located inside `/gnu/store/nx6f4xjrvzdqjb0s32q1qyhxm29xp2r0-emacs-native-comp-28.1.50-199.5e47d62'.
***ChanServ changes topic to '!! Website, CI, MUMI down for maintenance !! GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<attila_lendvai>i started to use home services, and it did something with my fonts... random anomalies, like gnome password entry font is a bit smaller, emacs displays some unicode chars with an enormous line spacing, etc. what am i missing?
<unmatched-paren>attila_lendvai: it does some stuff with fontconfig afaik, but i'm not sure how that would mess it up
<jfred>Hmm... so I've been using 'guix home' to manage some of my dotfiles and my user's packages, and lately it's been getting stuck on 'Finished updating symlinks.' near the end of a reconfigure. Has anyone else experienced this?
<dirtcastle>how nixos has lots of packages when the community seems so small. the subreddits have only 2000 ppl. irc also has less ppl. but arch Linux has now than 1 million and irc also has around 2500 etc iirc. who is making these packages/build scripts.
<unmatched-paren>(define (frob foo bar) ...) is equivalent to (define frob (lambda (foo bar) ...))
<djeis>Quoting the message he just sent me: "not really guix-specific to be fair, but guix seems to be the only distribution still shipping such an old unpatched QtWebEngine while shipping a much newer glibc"
<nckx>djeis: By the way, you can still send mail to bug-guix@ and it will still end up in mailboxes and on the ‘main’ (if ugly) debbugs archive page.
<unmatched-paren>dirtcastle: and that applies to your whole suggestion to turn guix into gentoo: why not just use gentoo?
<dirtcastle>unmatched-paren: I have this ambitious goal of creating a package Manager that can give extremely easy user interface and the the option to download packages in stable, rolling and source based way. all three in one. apt is good at stable release. arch is good at rolling release. gentoo at source based. and we need immutable , reproducible and roll back nature of guix/nix. mix all of them together. I think guix does 3 already upto some level?
<dirtcastle>stable, rolling and being nix like. so only Bringing the features of gentoo is left.
<unmatched-paren>dirtcastle: guix brings different features to gentoo, with the same or better results :)
<unmatched-paren>(package/inherit ...) 1. allows guix to fulfill reproducibility goals, because you have to create a new package or modify an existing one to get different results and 2. gives you far greater control
<unmatched-paren>i suppose i'd better show you how to use (package) so you know how to use (package/inherit)
<dirtcastle>unmatched-paren: mainly this - there are profiles in gentoo. u can choose desktop ( which means Xorg) gnome and kde. when u select a profile, say gnome all the packages u compile will get gnome support but kde and xorg support will be removed automatically.
<unmatched-paren>so, package is basically just a guile object (package ...) with s-expression fields (package (foo-field ...) (bar-field ...) ...)
<djeis>Sure, and you could just name them differently.
<nckx>djeis: Guix doesn't ‘resolve dependencies’ like other package managers, so what's the use case? I.e. you can't say ‘barpkg requires foopkg with features A & B set, C unset, I don't care about D’.
<blake2b>I get a similar error trying `guix install`, I'm building packages locally atm
<nckx>Berlin (‘CI’) being down shouldn't break guix pull. Perhaps your Linode guix still has cached ‘this substitute is good’ URLs that it tries to download anyway, and guix is still very bad at handling network failures.
<blake2b>cool, I'm trying --with-subs rn, I'll try that next if it fails
<blake2b>using the subsitute url worked :), thanks
<f1refly>i don't understand what you're trying to tell me with that nckx
<nckx>blake2b: In theory (well, and in fact) substitutes are fully transparent, and your local guix has all the information it needs to calculate the pull locally, if slowly. It just refuses. Borderline bug. Definite annoyance.
<nckx>atka: The fact that that such logic doesn't make sense (to me) and yet I believe it confirms my prejudices of btrfs. 2 drives failing in a 6-drive array will still kill data, so at 5 it *is* hella ‘degraded’.
<atka>hmm maybe one of the extra copies would be better with raid1 and six disks