<jonsger>ACTION trying to compile glibc for powerpc64le
<ng0>OriansJ: a while back I started working on it (torbrowser). I encountered some issues, and torproject and the torbrowser team is helpful, but I layed this off for a while since I have more important issues right now
<ng0>OriansJ: furthermore, once (if not already the case) Torbrowser team has addressed all the trademark of firefox mentions "issues", we are officially allowed to ship the real, branded Torbrowser as Torproject trademarks team/person and the browser team was okay with my approach
<ng0>as a legal safety net I would ask them again (this time public) to get a recorded "it is okay the way it is") once the guix package is ready
<jonsger>civodul: working on it fulltime until wednesday. "bootstrap guilec" tries to kill my PC :P
<snape>civodul: do you think it's a good idea to remove the --load-path option to Cuirass? I think it should be done in the long term but it won't simplify the migration for people who use it. Maybe a deprecation warning would be better.
<ng0>I'm about to send the updates for erlang and elixir I'Ve been using. Imo, and that's how I've been handling packages in general, we should keep the old ones around in older version… but since nothing/only packages themself depend on elixir and/or erlang, I will go with the Guix way to simply update in place.
<jlicht>Is #guix also the place to be at for talking about cuirass? If so, guix environment balks at loading the build-aux guix.scm file, but only if calling guix from a git checkout
<jlicht>I have a diff of the generated .go files: http://paste.debian.net/1033899/. The only thing I am able to divine is that the 'broken' version seems to be using guile 2.2.3 instead of 2.2.4, and that the 'file name table' is different
<OriansJ>ng0: Thank you for clarifying the Tor-browser situation
<ng0>a realistic date could be at some point in 2019? Depends on how often I can work on it.
<ng0>there's this rusty train arriving, which could make it just a tiny tiny bit challenging in guix ;)
<brendyn>It's a bit over my head, but I would like to learn some Rust, maybe after I finish SICP
<OriansJ>jonsger: if you are interested in guix on PowerPC, would you perchance be willing to help with a little testing for the mescc-tools support of PowerPC? That would help put PowerPC into the stage0 bootstrap group.
<civodul>as for use cases, there's daily "desktop-style" usage, software development, and high-performance computing
<pkill9>it would be cool to have a library of guix configurations for different laptops, that have all the random quirks applied (e.g. i have to set a kernel parameter for the brightness buttons to work). Not that i'm asking anyone to do it, too much effort tbh lol, but it's neat that it could be done
<civodul>"1.2.2 is already the latest version of xbacklight"
<efraim>I have it working with enlightenment, but I had to add the enligtenment backlight binary to setuid
<gast>umm, yes, or interested in it. there are 185 here; that's 1 interested non-user(me); 184 potential users... how many are actually using it and where? I'm responsible for the software that delivers the ngsservice for PublicHealthEngland(excepting TB)
<efraim>I know it works with the slider, I don't remember if I tried the buttons
<Sleep_Walker>so, good news is that package is fine as it is (test would still be good idea), but change of dbus configuration doesn't trigger dbus-system reload...
<Sleep_Walker>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its configuration file and to flush its user/group information caches. Some configuration changes would require kicking all apps off the bus; so they will only take effect if you restart the daemon. Policy changes should take effect with SIGHUP.
<mbakke>Sleep_Walker: Interesting! I wonder how to implement that for the D-Bus service.
<mbakke>Perhaps we can do that unconditionally on reconfigure (if the service already runs).
<mbakke>Or every time a dbus-root-service-type extension changes... food for thought! :)
<snape>mbakke, Sleep_Walker: The Shepherd can't (yet) do anything to running services. It would be too dangerous, the goal is to be conservative. So it won't SIGHUP running programs.
<snape>but there is a plan to implement 'reload' actions
<jackhill>I'm trying to use guix import against melpa-stable. stable.melpa.org uses a let's encrypt certificate, and the import is currently failing with X.509 certificate of 'stable.melpa.org' could not be verified: signed-not-found
<jackhill>how should I make the le-cert available to guix import?
<jackhill>I wonder if we could make guix import elpa -a melpa-stable add the cert automatically. Although, maybe we don't want to do that to our users?
<civodul>jackhill: did you install nss-certs and define the relevant env vars?
<janneke>samplet: possibly...we can probably just use things like `normalize-word' in gash/geesh:parse-tree->script
<janneke>the globbing and tilde-expansion needs to run just in time, and Gash' script looks different--maybe we can steal bits of the algorithm
<samplet>janneke: For sure. The ‘word’ module needs to communicate with the back-end as it goes.
<samplet>It’s nice to write the back-end code without thinking too much about globbing or references, though. Which is why I wanted a separate module for those things.
<janneke>samplet: ah, words are unnamed atoms or sexps, that makes sense
<janneke>i see my current effort mainly as an exploration, before we start to "really" work on broadening it, we need to think about geesh/gash and naming <sh-pipe> vs pipeline and many more things. i still want to see some non-trivial scripts work correctly
<blu3r4d0n>I hope eventually I can run this as a daily driver
<samplet>janneke: I think I will do two things in the short term: make sure the files you mentioned parse cleanly, and commit some of the nascent back-end code that I have. The latter I’ll do so that you can see the general direction I was going. And yes, we should discuss a bit on guix-devel.
<pkill9>i don't suppose anyone has created a way to include guix pakcage definitions from a remote url in their guix system configuration?
<civodul>i suppose you could always do (primitive-load (http-get ...)) but...
<pkill9>so you would just do `guix system reconfigure ..` and within the system configuration it would retrieve package definitions froma URL, add the extracted folder to the GUIX_PACKAGE_PATH, and build the system?