<nckx>M4R10zM0113R: It's a Guile procedure. Since I don't know your background or exactly what you're trying to do: you do know that the Guix initrd is a Scheme programme, not the usual busybox+shell scripts? It only contains a handful of packages, and those are things like e2fsprogs and cryptsetup.
<nckx>dftxbs3e: Er. That's a new one. I'm stumped.
<reepca>nckx: garbage collection *could* in theory hurt if there are obfuscated references. For example, if contents get compressed, encrypted, split up, etc. Certain gcc optimizations used to cause it, for example.
<dftxbs3e>I ran the build on another machine where guix gc was NEVER ran
<nckx>samplet: I'm also very interested in those notes. Any chance they can be published?
<dftxbs3e>reepca: "/gnu/store/h32ick5vi3d013bhcmga02z2rkz9aq16-gcc-cross-powerpc64le-linux-gnu-7.4.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory "
<M4R10zM0113R>wait... gdm?... I don't see it on config.scm... is it part of the desktop module or something?
<reepca>M4R10zM0113R: it's in %desktop-services I believe
<samplet>davexunit, nckx: It looks like I built coreboot by building their special toolchain and just building outside of the store. I did try to build it in the store, but parts of it use Ada. I made a GNAT package, but it is very ugly, and GNAT is not bootstrappable, so I never sent it in.
<M4R10zM0113R>reepca: base-services%? Is there more than config.scm I need to look on?
<nckx>samplet: Yeah, that libgfx GNAT dependency… seems like you got about as far as I did.
<nckx>Building things outside of Guix feels so tedious now.
<dftxbs3e>nckx: I may even start using guix for CI :P
<dftxbs3e>Once it's ported to powerpc64le it's going to be perfect
<nckx>Also make sure to back up your precious ~/project-foo directory because their ain't no way your ever reproducing that again.
<nckx>*you're, and with that it's officially time for me to go to bed.
<samplet>M4R10zM0113R: They are defined by Guix. The %base-services list contains basic services like TTYs and the Guix Daemon. The %desktop-services list contains all of those plus services for desktops, like (IIRC) eudev and GDM.
<reepca>dftxbs3e: what does '$(/gnu/store/516li48bmfm2jyp94hykcabixqwpm7vc-gcc-cross-powerpc64le-linux-gnu-7.4.0/bin/gcc -print-prog-name=cc1plus) -v' say?
<reepca>Hm, in magit the passphrase prompt is showing up in the magit-process output... anyone else experience that?
<samplet>dftxbs3e: This is getting too tricky for me. It looks like we stopped using CPLUS_INCLUDE_PATH in favour of just CPATH (don’t ask me why – that bug report is complicated). For whatever reason, g++ is not happy with this when compiling GMP.
<samplet>When building GCC, we now manually set CROSS_CPLUS_INCLUDE_PATH.
<TurBo_biT>guix is like gentoo in the "installation" of packages compiling it?
<reepca>TurBo_biT: sort of, it's possible to transparently get pre-built binaries from a trusted substitute server, but falling back to compiling from source automatically is always an option.
<reepca>on a different note, I found out what was up with magit: openssh 8.0 changed the way their password prompt is printed, so I need to update magit accordingly
<ison[m]1>I'm trying to repair a store item but it doesn't seem to do anything. I am getting corrupt video after an update (screen looks totally scrambled) and I have determined the problem is in mesa, the libGL.so.1 library. When I run "guix gc –check" on the derivation it says the output differs from the one in the store. So then I try to use "guix gc –repair" and it finishes in 2 seconds and only outputs the store path. It doesn'
<ison[m]1>seem like it builds anything. When I try –check again it still says it differs.
<TurBo_biT>are you thinking about give support to Power architecture?
<reepca>ison[m]1: when you say "the derivation", do you mean the /gnu/store/...-mesa-XXX path or the /gnu/store/...-mesa-XXX.drv path?
<ison[m]1>reepca: the .drv path (obtained by running guix gc –derivers on the other path)
<reepca>the latter is "the derivation", but it's a description of how to produce the store path that contains libGL.so.1
<reepca>it's not clear how to repair a derivation, as the only bookkeeping the store keeps about it is the hash. Repairing a derivation's outputs is just re-running the build. But the derivations themselves are crafted by the client-side guix code and transferred as-is to the store.
<reepca>you could try gc'ing the derivation and then running guix build -d mesa (or whatever the proper package name is) and that should re-send all necessary derivations that aren't already there
<ison[m]1>reepca: well I tried both paths actually, I only assumed I had to provide the .drv path because when I did the other one it didn't give any output at all
<ison[m]1>reepca: I basically just want to keep the new build that –check does and replace the old one, but it seems like it just reports that it differs and that throws it away
<reepca>I can't seem to find options called --check or --repair for 'guix gc', there's --verify=repair and there's 'guix build --check'.
<ison[m]1>right, I'm using guix build –check. There's also a guix build –repair
<reepca>ah, okay. so you ran 'guix build --repair mesa' and nothing seemed to happen?
<ison[m]1>Right, there's no output at all and it finishes instantly. However, with –check it actualy takes a few minutes and I can see the build output
<reepca>hmmm. Well the issue there is that "repairing" a store path only happens if its hash doesn't match what's registered in the database. Since nothing is happening, presumably the hash does match. So the output isn't "corrupt", but as you discovered with --check, its output is nondeterministic (a second build produced different results). But the daemon has no way of knowing which is the "right" one, as the existing one is already known to
<reepca>be a valid result of building that derivation.
<ison[m]1>So is there no way for me to just re-build the item in the store then (and keep the re-build)?
<reepca>it'd basically be rolling the dice a second time, with no guarantee that it would be any better. Do we know anything about what specifically in libGL.so.1 is the problem?
<donofrio>need advice..... we are restricted to /app directory only to install and house our stacks (linux folks keep rest of OS and root) I have root for a hour as needed - I'd like to know how to make /app "root" for guix what switch do I feed installer to get this to work or do I simply need to compile from source (host os's are suse, redhat, aix7)
<ison[m]1>reepca: I wish I could narrow it down more, but there are no errors. It's just corrupt video. Even the log-in screen is corrupt (it just looks like weird lines all over the screen). I'm sure it's that library though because if I run something with LDPRELOAD to my previous working version of libGL then it works.
<reepca>donofrio: first important piece of information, if you can't secure consistent write access to /gnu/store for the daemon and you put the store somewhere else in the filesystem, the hashes of store items will differ and you won't be able to get most binary substitutes
<donofrio>I could push them for that or could I just symlink it so /app would be / making that work? cause the host os doesn't care about that gnu directory
<reepca>the store directory can't be a symlink, as all paths get canonicalized. What do you mean by making /app "root" for guix? Making it the installation prefix?
<donofrio>worse case linux folks can make the ln -s /app/gnu/store /gnu/store ?
<reepca>it would still internally be resolved to /app/gnu/store, and the hash part of store paths would be computed based on that.
<donofrio>what I mean by /app as root is we have full access to /app and not much else.....so we've been using ansable and static releases version file to pull apache pcre openssl and php or jboss, but this get stale too quickly to keep up with the vulnerability so I found this project and it seems like the perfect answer to our package needs we currently have no package concept for the /app structure
<reepca>if you could convince the linux folks to bind-mount /gnu/store to /app/gnu/store, substitutes would be available.
<ison[m]1>What about adding a users with home directory inside /app?
<reepca>you'll have to install from source, though, I believe, as you don't have access to /var, which the installer would try to write to by default
<reepca>ison[m]1: could you elaborate? I'm not sure what you mean.
<ison[m]1>reepca: well i guess I'm not sure exactly what his situation is. If he can get the admin to install guix normally (with store in /gnu/store) then he could manage everything without needing root access just by having a user in /app
<donofrio>ok if I compile from source will I be able to repoint /gnu/store to /app/gnu/store?
<donofrio>what I was saying is we mightbe able to get another directory created to a mount to make /gnu/store owned by us along with /app or as suggested a mount of /gnu/store from /app or something like that?
<reepca>M4R10zM0113R: if you're referring to symbolic linking, no, the store directory is canonicalized (symlinks resolved) prior to computing hashes and such, so substitutes wouldn't be available.
<reepca>ison[m]1: true, but it would require the admin to be okay with the guix daemon constantly running as root
<donofrio>so I just need to request that /gnu/store is owned by us and I should be alright with stock installer script?
<donofrio>thought is ran as user? (thought I read that on the webpage?)
<reepca>donofrio: not exactly, assuming the daemon won't be allowed root access, you'll need a localstatedir other than /var, so guix will have to be configured for that.
<donofrio>felt like WSL for everything else (usermode = gnix?)
<donofrio>that /var might not work out so smoothly...the host os owns /var
<reepca>donofrio: aye, so if you download a source release you can run ./configure --prefix=/app and localstatedir will default to /app/var.]
<ison[m]1>reepca: It just sounds to me like there's a misconception here. He's saying that he can request /gnu/store be owned by his user, so it sounds to me like he can get Guix installed normally, with the daemon running and all, and he's just not sure that he can install packages without root
<ison[m]1>donofrio: Are you aware that once Guix is installed under root normally that you can still install and update packages as a normal user without root privileges?
<donofrio>I'm not concrned if I have to compile - do it all day at work lol
<ison[m]1>donofrio: well assuming you have Guix fully installed the normal way then the daemon should take care of all that. Basically there is a guix daemon which has root access and you can communicate with that daemon to build and update your packages without you having root access yourself
<donofrio>we have systemd access so why do I need root? and what I mean by systemd access is I make the start and stop scripts and linux folks make it systemd'd for us to start and stop being our service accounts
<donofrio>am I correct that guix provides usermode like unix on linux? (probably over simplifed but that is how this feels right now?) course only heard about this great project yesterday from slashdot
<reepca>I'm not sure what you mean by "usermode like unix". Regarding systemd, the guix installer puts a service file for the daemon in /etc/systemd/system, from which it will be automatically run as root by systemd. Using guix after that point does not require root for anything but the daemon.
<donofrio>ok should be alright we'll make it work....so only way to fix /var is to compile? would like it to user /app/gnu/var or something like that
<reepca> /var is only used by the daemon, so as long as it's okay for the daemon to run as root it's okay for it to use /var.
<donofrio>any other suggestions I'm open and will lurk here forever now ;)
<ison[m]1>donofrio: Sorry, it just sounds like there might be some confusion here. So just to be clear the "normal" way to do this is to have Guix installed as root, with the guix-daemon running (perhaps your admin can take care of this part). Then once that's done any user on the machine can install their own per-user packages (which I assume is what you mean by the usermode).
<donofrio>we live in /app compile make there do everything there (systemd/sudo needed to start apache and jboss/tomcat) but as I said everything is compiled now from static version files from ansible, would like to be able to say gnix upgrade apache and it would upgrade apache in /app
<donofrio>if the balk, if this where I use --prefix to compile to keep everything within /app (in that /gnu/store and /var would all be in /app?)
<donofrio>tired but excited so typing gets bad lol
<marusich>If you put the store (/gnu/store) in a different location, then you will not be able to use the pre-built substitutes from the Guix build farm.
<donofrio>want all ablities that I can leverage....
<donofrio>just know linux folks do not like us outside of /app
<marusich>You can still build the software from source, but it will be slow if you put the store in a non-standard location.
<marusich>If you can set up your own build farm, you could also publish your own substitutes for your custom store path (e.g., /app/gnu/store)
<marusich>By the way, the reason you can't use the build farm's substitutes in that case is because the store prefix ("/gnu/store") is one of the many factors which determines the hash in a derivation's output path.
<marusich>If your store prefix doesn't match the one used by the build farm, the store paths you build will never look like the ones published by the build farm; they will all have different hashes.
<marusich>So, every time Guix asks the build farm, "Do you have a substitute for this store item?" the answer will be "no"
<reepca>on an unrelated note, current emacs-magit checkout fails to build because it expects to find libgit, and all we have is libgit2...
<buenouanq>2 things I'm going to attempt to package this week: gmusicbrowser and ibniz
<rekado>ZombieChicken: I think for the very high price it’s a little disappointing. On the other hand I really appreciated not having to muck about with BIOS hacks to make a Linux-libre compatible Wifi card work.
<rekado>civodul: yeah, the complexity makes it hard for me to understand how to debug things.
<civodul>diving into gnome-shell + gdm + localed/systemd just to debug the gdm keyboard layout issue was... interesting
<efraim>I've heard the build quality goes up dramatically as they have more revisions of the hardware
<cbaines>Quick g-expressions question, I'm seeing things like (quasiquote ((test unquote 1))) be generated. This looks wrong and invalid to me, but it actually seems to work, so now I'm a bit confused?
<ZombieChicken>rekado: Yeah. ANything like that will have some problems, but if it's backlight is generally unreliable on battery, that is a serious problem
<ZombieChicken>any hardware problem is an issue, really. Software can be fixed, whereas hardware is a much different issue
<ZombieChicken>the price is kind of to be expected; it's a new market and a new idea without the economies of scale you get from Dell, HP, et al.
***daviid is now known as Guest84852
<rekado>ZombieChicken: I found the production quality to be sub-par. This is the Librem 13v2. I hear they’ve got newer revisions now.
<civodul>i think we should get rid of the dot in Guile 42 maybe?
<civodul>rekado: regarding 1.0.1, it looks like the story will be: new shepherd release with fix for wpa_supplicant PID file issue, address other installer issues (which are rather minor), and go ahead
<rekado>you can link the glibc package’s ld-linux…so to /lib64
<kabo>I ran patchelf --set-interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2 ./firefox
<kabo>now I get ./firefox: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
<rekado>kabo: this will just be the first of many such errors. This binary was linked on an FHS system. Guix does not follow the FHS, so the libraries won’t be where the “firefox” binary expects them to be.
<brendyyn>He basically takes maintaining python2 packages himself, and python2 for windows, however there is some python3 stuff being merged in to the calibre repo from another developer, so their may be hope
***PotentialUser-31 is now known as desttinghim
<wednesday>rekado: Well python2 end of life is meant to be next year right? ha
<efraim>looks like gst-plugins-base FTBFS on armhf
<dadinn>how do i define key file for a LUKS mapped device in the system configuration?
<brendyyn>if you just run guix gc it will clean up everything
<dftxbs3e>samplet: Hi! - Next error "powerpc64le-linux-gnu-ld: /tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.28.drv-0/build/libc_pic.a: error adding symbols: archive has no index; run ranlib to add one"
<rekado>I think it makes sense to make sure that 3.30 is consistent and merge it as soon as feasible.
<civodul>samplet: re wip-build-systems-gexp, we should get that done! want to work on it?
<rekado>it’s fine to wait a little longer for 3.32
<bgardner>Good morning Guix; I'm working on building a package here and I'm having trouble with a dependency. The package depends on BDB and I'm getting "db.h" not found. My environment is "guix environment guix --ad-hoc=bdb" but I don't seem to have a proper INCLUDE set up based on "guix package --search-paths". Any advice on the proper way to proceed?
<roptat>with guix, you get package recipes that are built locally, but because most packages are reproducible, you cannot differentiate between a local build or a build from another computer or a build farm, substitutes are what we call downloads of build results (binaries) from someone else's computer (usually, the official build farm)
<roptat>I assume #:substitutable #f makes guix not even try to look for substitutes from any substitute url it knows of (or makes it unavoidable when publishing substitutes)
<efraim>My understanding is that with #:substitutable #f and maybe also #:local-build #t it should be ok
<mitescugd>anyone else had problems building plugins for bitlbee? the plugin doesn't appear. I've configured bitlbee with `--plugins=1` and `--plugindir=$GUIX_PROFILE/lib/bitlbee`, and the compiled plugin is there. I'll also ask around #bitlbee as a last resort, but maybe someone has a quick fix already. :)
<dongcarl>Any progress on packaging Guix for Debian?
<davexunit>I use packer all the time at work for building AMIs
<g_bor[m]>I added debug loglevel to sshd,and when I start manually, i have debug output in /var/log/debug, but it seems that on the failed start attempt sshd does not get to the point to log to syslog.
<cbaines>davexunit, yep, including the source of all the dependencies makes it easy to build a initial package defintion, but it's a bit of work to build a proper one
<nckx>dongcarl: Re: the Overdrives: I'm still fighting them, I'm afraid. Despite 8 GiB of RAM, running ‘guix pull’ or ‘guix install’ causes it [sic] to be OOM-killed (if I'm lucky) or freezes the box (if I'm less so). I'm away from home for a short while, so I can't press the power button :-/
<nckx>I don't understand why this only affects me; hope to find out soon.
<reepca>anyone familiar with the emacs packaging scene feel like packaging libgit (elisp bindings to libgit2)? Apparently current magit checkouts need it, but the current magit in guix is broken due to an openssh upgrade (changed password prompt isn't recognized by magit). I'm really lost on how to package emacs-libgit.
<reepca>It's got a git submodule it uses and it seems like none of gnu-build-system, cmake-build-system, or emacs-build-system work by themselves.
<rekado>reepca: git submodules can be added as native inputs
<rekado>reepca: or maybe you can do a recursive git-fetch
<dongcarl>nckx: What are overdrives? I feel like I'm missing context
***nand1_ is now known as nand1
<rekado>“Overdrive 1000” (would be even better if they were named “Overdrive 2000”) is an aarch64 development box.
<vagrantc>dongcarl: softiron overdrive is an aarch64 (64-bit arm)
<nckx>There's an Overdrive 3000 so I guess 2000 is a reserved number.
*rekado remembers that “2000” naming craze in the 90s
<nckx>I'm using the overdrive.scm from the maintenance repo by the way.
*nckx does too, but maybe marketing droids don't share our sense of humour.
<nckx>Apart from guix crashing, they're ready to use!
<reepca>rekado: actually it looks like the initial definition generated by the importer downloads a release that includes the submodule already, I'm just lost as to what sort of build system it's supposed to have. When I make it cmake-build-system, it succeeds but doesn't install the elisp parts, and when I make it emacs-build-system, it succeeds but doesn't install the actual C bindings.
<cyris212>Is there some kind of http client shipped with the GuixSD installer?
<reepca>cyris212: 'guix download' should work for fetching stuff
<cyris212>I need to fetch the config.scm from a webserver...
<civodul>i think there's also wget, and if not, you can run "guix install wget"
<cyris212>civodul: Good point, I will try this. Thank you.
<vagrantc>i've started sometimes using guix download to download things i that i probably don't want indefinitely, but might want to persist across reboots or something ... and then they'll eventually get garbage-collected :)
<cyris212>vagrantc: that is actually an interesting approach :-)