IRC channel logs


back to list of logs

<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.
<sprang>anyone in te SF Bay area?
<davexunit>no, I would totally be going to that if I was.
<sprang>I'm planning to head up there
<lfam>What's the preferred way to wrap a URL that is too long? For example, this one:
<davexunit>break into multiple string literals
<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.
<rekado->ACTION continues dreaming
<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>I fucked it up.
<csed>God damn it config.scm
<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>Seems to work now.
<csed>Multiple partition labels? I don't remember doing that.
<alezost>csed: I am in #emacs, but you probably saw me at #stumpwm
<alezost>someone also asked about multiple labels (if that's what you mean): <>
<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>yeah, I would also try to find out what grub wants: <>
<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>why so?
<nextos>i expected at least all binaries for my x86_64
<davexunit>nextos: sounds like you haven't authorized
<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
<nextos>no guixsd
<davexunit>see step 7 of the instructions here:
<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 file
<nextos>davexunit: yeah, i forgot to authorise.
<nextos>makes sense i got so many dependencies if it was trying to compile glibc
<davexunit>happy not-bootstrapping from source
<davexunit>the bootstrap would have taken a long time
<nextos>davexunit: i note the bandwidth from is not that good thou
<nextos>getting things at 700kbps
<davexunit>it's slow
<davexunit>we have limited resources
<nextos>no problem
<nextos>its decent
<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
<davexunit>that's good
<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?
<nextos>man pages for guix
<nextos>e.g. "man guix"
<davexunit>yeah, MANPATH will need configuring
<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.
<nextos>oh ok
<nextos>info guix works
<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.
<nextos>oh ok
<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
<davexunit>what makes it insane in nix?
<nextos>in the chain
<nextos>well, the way some packages are built
<nextos>they put too many things
<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
<davexunit>our mutt might do that, too, dunno.
<nextos>nope it doesnt
<davexunit>oh cool :)
<nextos>i dont remember the exact chain, i think it came via gnupg
<nextos>in nid
<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
<davexunit>since so many pieces of software use it.
<nextos>oh sure, and thats fine
<nextos>but nix policy was a bit wrong, they even bundled flash with firefox
<davexunit>yeah, I heard about that. :/
<nextos>some distros get it right, things as close to upstream as possible
<nextos>no patches unless really needed
<davexunit>that's what we do.
<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
<davexunit>and it's necessary for the system to work.
<nextos>that's fine
<nextos>but i find it really irritating when simple things like emacs-nox
<nextos>are broken in my ubuntu at work
<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.
<csed>rekado-: Awesome article, Our HPC admin does something similar, but manually and without Guix. think he might like this.
<nextos2>davexunit: yeah thats neat
<davexunit>so many things to do.
<nextos2>csed: most hpcs do those things in an ugly fashion, manually
<nextos2>csed: does
<davexunit>we've got a real nice foundation built, now we need to build the house.
<davexunit>more tools, more packages.
<csed>nextos2: Exactly.
<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
<csed>nextos2: Yeah.
<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)
<davexunit>yeah we should work to break them up a bit
<nextos2>otherwise it'd be hard to run guix in smallish hw
<nextos2>like humble chromebooks
<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