<ifur>sprang: more than intel, at least as a rule :) <ifur>about 3 years ago since 64bit arm instructions started showing up in GCC? <ifur>the embedded crowd has always been libre friendly -- their employers not so much <davexunit>sigh, the "userops" community seems to be advocating for using environment variables as *the* means for customizing applications <davexunit>for this experimental Debian web application packaging project, anyway. <davexunit>no, I would totally be going to that if I was. <rekado->since I learned that Qt bundles so many libs I really don't want to use Qt software anymore. <rekado->would be nice if there was a shim to swap out Qt for Gtk. <DusXMT>rekado-: The idea is that it only gets loaded into memory once, so if you have eg. 5 Qt programs running at a time, they share the same in-memory copy of the libraries. Of course, I _do_ agree with you :) <efraim>if we package the libraries and load them as propogated inputs, will they be used instead of bundled Qt libraries? <DusXMT>efraim: indeed, but I think you mean as normal inputs, as propagated inputs are usually used for tools and the like <DusXMT>wait, that's native-inputs, I'm an idiot <efraim>I'm still working out how to remember them. `P`ropogated inputs get `P`ulled in <efraim>or `P`ropogated inputs are `Q`uite needed for `R`untime dependencies <csed>Dropping Guix on my X61s as we speak. <csed>Two errors in my config.scm so far. <csed>Gah. It looks like it's updating the repos. I think this might actually be working. <csed>This makes no sense. "Unbound variable: wicd" <alezost>csed: you probably forgot to use (gnu packages wicd) module <csed>alezost: Wait, I think you're in #emacs, maybe. Anyway yeah, I forgot wicd in (use-package-modules ... <csed>Multiple partition labels? I don't remember doing that. <alezost>csed: I am in #emacs, but you probably saw me at #stumpwm <csed>alezost: Nah, GRUB is being weird. "/boot/grub is not readable by GRUB on boot" <csed>Which I don't get, I have one partition with boot flipped to on. <alezost>csed: did it happen after "guix system init"? <csed>alezost: From what it looked like, guix system init was followed by the grub install, which now complains about "multiple partition labels" <csed>The isn't readable was me being stupid, forgot --root-directory. <csed>I don't actually know what multiple partition labels would mean, other than that there are multiple partition labels. I have a single partition labelled "root". <alezost>yes, "guix system init" installs grub in the end of the process, but I don't understand your case. Did you try to install grub manually with --root-directory? <csed>alezost: Yeah, since "guix system init" does a complete reinstall, I figured I'd debug it with "grub-install" until I got it working. <csed>Then another "guix system init" <csed>Actually, I don't know what "guix system init" does. Other than init a guix system. But it takes a while, therefore my latter approach. <csed>Dunno. Might be remnants of something that wasn't wiped properly. <alezost>basically "guix system init" populates directories (in the mounted partition) and then tries to install grub <csed>alezost: Right. So I think I'll dd the disk in question with /dev/null, then try fdisk again and a grub-install before the init. <csed>Once I create /boot, I guess. <csed>Go from there and end with "guix system init" once GRUB stops complaining. <csed>Oh, shred's here. That'll do. <nextos>hello, upon running "guix -i glibc-locales" I got a very long running build process <nextos>downloading tons of dependencies and compiling stuff <nextos>i expected at least all binaries for my x86_64 <davexunit>nextos: sounds like you haven't authorized hydra.gnu.org <davexunit>if you're not running GuixSD, then our build farm is not trusted by default. <davexunit>did you build from source? install from binary tarball? something else? <nextos>davexunit: thanks, i suspected something like that. Its a guix install on top of an ubuntu <davexunit>the file name for the public key file will be different if you haven't installed this way. <davexunit>but somewhere you are sure to have a hydra.gnu.org.pub file <nextos>davexunit: yeah, i forgot to authorise. <nextos>makes sense i got so many dependencies if it was trying to compile glibc <nextos>davexunit: i note the bandwidth from hydra.gnu.org is not that good thou <davexunit>hopefully some day our build farm will have more juice <davexunit>but for now it's a bit overloaded at all times <nextos>no worries, the non-bootstrapping went fine though <nextos>davexunit: i cant get guix man, is it because i need to set MANPATH? <davexunit>do you mean read the man pages for guix, or install a guix package for the 'man' program? <davexunit>I believe our latest release added man pages <davexunit>our primary documentation is in texinfo, so info readers work best. <davexunit>but we use a program that generates man pages from texinfo so those should work, too. <davexunit>if guix is available in say, /root/.guix-profile, then the man path should be something like /root/.guix-profile/share/man <davexunit>adjust as needed for whichever profile you want to read man pages from. <davexunit>if you were to install our man-db package, guix would output some text telling you to configure MANPATH with a certain value. <davexunit>yeah, for the software that guix has knowledge of i.e. not your ubuntu stuff, it can tell you some nice things such as what environment variables you should configure to make things work since we don't use /usr <nextos>davexunit: ok, i really like dependencies are not insane like in nix <nextos>with nix i installed mutt, and python2 eventually came in too <nextos>well, the way some packages are built <davexunit>nextos: you'll find some of that with guix, though we *try* to keep things reasonable. <nextos>davexunit: well, but at least you recognise it might be an issue <nextos>some nix devs got very aggressive when someone pointed out <nextos>mutt -> ... -> python2 is a bit wrong <nextos>i dont remember the exact chain, i think it came via gnupg <davexunit>you'll probably find something at some point that brings in a large dependency that isn't optimal. let us know when that happens. <davexunit>python will surely get installed at some point <nextos>but nix policy was a bit wrong, they even bundled flash with firefox <nextos>some distros get it right, things as close to upstream as possible <nextos>that's really nice, and im happy to hear <davexunit>we have some dynamic patching that happens to do things like fix shebangs that refer to /usr/bin or something <davexunit>but that's not the same as tweaking software functionality <nextos>but i find it really irritating when simple things like emacs-nox <nextos>because they apply and bundle dozens of extra things <davexunit>we have an emacs-no-x package to remedy that ;) <nextos>yeah, i know, i mean even the ubuntu emacs-nox package is somehow broken <davexunit>at work I use an ubuntu workstation, and I use guix packages as much as possible on it. <davexunit>having the latest and greatest emacs is a must for me. <davexunit>I should be able to reliably use even more guix software without ubuntu stuff interfering once I get basic container support into our 'guix environment' utility. <davexunit>then I can create a pristine environment where shared libs in /usr and other things *cannot* be accessed and break my builds. <nextos2>csed: most hpcs do those things in an ugly fashion, manually <davexunit>we've got a real nice foundation built, now we need to build the house. <nextos2>csed: i was using userspace portage (gentoo) to avoid their mess <nextos2>csed: but guix hopefully will make this much much simpler <davexunit>the caveat being that you need to be root or convince the administrator. <nextos2>davexunit: yeah, i tried userspace nix at it worked quite well <davexunit>in the future I think we'll have a better story for running the daemon as an unprivileged user. <davexunit>it *can* run unprivileged, but there's no isolation and things break. <davexunit>user namespaces can address this, but require a more recent kernel. <rekado_>csed: thanks. I'm currently (with too many interruptions) working on letting users manage their profiles on their own on all cluster nodes. This is currently the biggest practical limitation of having a central (mostly-)read-only store. <csed>rekado_: Not sure how well our users would manage that. Only two labs here are bioinformaticians. <rekado_>I don't know how comfortable our users will be with this change. <rekado_>it shouldn't be too hard for them to learn a few common commands. <rekado_>for others there's still the low-bandwidth way of asking me for help :) <nextos2>davexunit: shouldn't be git broken down to avoid getting subversion and python2 as defaults? <rekado_>I also think that our git package is a little fat. <alezost>ACTION is for git-minimal (and mpv-minimal) <nextos2>otherwise it'd be hard to run guix in smallish hw <phant0mas>I tried to install guix sd in a machine I have and when I reboot, after it adds the user groups, I get a kernel panic <phant0mas>tried various different configurations but I still get the same... ***null is now known as ar
<efraim>$ ./pre-inst-env guix size mpv | wc -l = 149 ***francis7 is now known as fchmmr
***fchmmr is now known as francis7
***ljhms_ is now known as ljhms
<rekado->oh, I see jack2 in the list. Should be jack1. jack2 should not be used as an input to other packages unless it's really needed. jack1 and jack2 both implement the same API. <rekado->confusing. I don't see any package using jack2 as an input, but it's in the list output by ./pre-inst-env guix size mpv