<lfam>mark_weaver: Any thoughts on the poppler patch?
<lfam>Also, the 'prepare-socket-test' phase you added to ocaml in 69b8f08cb doesn't seem to be necessary anymore. I'm going to test some of ocaml's dependents with the latest ocaml, and if it works, I'll remove that phase and update.
<lfam>The file that phase patched seems to have been replaced with a similarly named file (sockets.ml) that uses the loopback interface instead of trying to reach inria.fr.
<lfam_>Looks like I'll need to update camlp4 when updating ocaml
<ng0>sneek: later tell jlicht: I don't see the full backlog. if there was anything else added it escaped the buffer. If there are problems, it's for other people to fix as I currently focus only on project tasks (ie: gnunet+secushare related works in all kinds of projects)
<ng0>sneek: later tell civodul: Okay, thanks. I see how and if I can or want to mirror this (a fix would be if there already was a .onion of the whole gnu.org/s/ space.. partyvan.eu has a mirror, but i haven't checked for /s/guix
<f0ff>so there is no simple way to just get a kernel that isn't deblobbed?
<f0ff>feel wrong to just download and a slap a kernel from kernel.org over the system i try to learn
<adfeno>f0ff: You could compile your kernel from source, but then you would loose your essential freedoms. And we won't be able to help you regarding kernel building or studying, if we find out that your kernel has non-free software that interfaces with the thing you're trying to do.
<adfeno>What you must understand, however, is that GNU Linux-libre has a *bug* that denies the user the ability to use non-free firmware that is supplied *by the user, after the kernel installation*. This is, according to Alexandre Oliva, a bug that is hard to solve.
<mark_weaver>and that pressure is unlikely to ever happen as long as OSes that include non-free blobs and "just work" on such hardware
<mark_weaver>because when it comes down to it, most users don't even think about this stuff until a situation like this, where an OS they'd like to use doesn't "just work"
<f0ff>but with hardware there is always some middle stuff.. wheter they come on chip or afterwards..
<mark_weaver>I agree that there are still problems with non-free hardware designs, but for now I'm just trying to hold the line at a place where *we* don't have to distribute non-free software
<f0ff>i just wanted to state the problem and i see both sides in the argument
<mark_weaver>*nod* I certainly don't claim to be fully satisfied with my laptop that can run free software from the boot firmware up
<mark_weaver>anyway, guix is quite easily hackable. you can run it from a git checkout on your own private branch, and merge upstream changes from us or rebase your branch on our master branch.
<adfeno>f0ff: Regarding what people call "free hardware" or "open hardware" (in which "free hardware designs" should be used instead), this is indeed a problem. However, we must recognize some priority of control and power here, like mark_weaver pointed out.
<adfeno>"Seeing the priority" as I said requires thinking on where the average users can perceive the unjust/unfair power of the proprietors/owners of non-free software more easily in their day-to-day routine, that is, what kind functional data they'll generally look for, no mater in which computer.
<lfam_>f0ff: I'm not that familiar with XFCE, but there must be some system-wide text rendering setting you can play with
<f0ff>i'll just feed the gfx the blobs it is asking for.. there is blobs in most other stuff also, but they are on chip so ..
<z0d>cpjjl: I usually prefer tweaking my system with a normal user as opposed to using root
<cbaines>Does anyone know how to turn a system definition (e.g. gnu/services/base.scm ) in to a tarball? build-aux/make-binary.tarball.scm looks like it might to that, but I get some error when trying to use it.
<cbaines>"build-aux/make-binary-tarball.scm:36:0: Throw to key `match-error' with args `("match" "no matching pattern" ("build-aux/make-binary-tarball.scm" "gnu/services/base.scm"))'."
<cbaines>I'm trying to create something that will work with Docker (e.g. something to pass to docker import)
<sietedosfede>Hello. Im trying to boot GuixSD 0.10 without success. The kernel loops the following message at boot: 'ACPI Error: No handler or method for GPE "XX", disabling event (20160108/evgpe-790)' with "XX" as hex values... If anynone knows somethig about that: Thanks!
<sietedosfede>PS: I have a Dell Inspiron 5545 with 6C AMD Kaveri GPU. I tried appendig blacklist=sp5100_tco at the end of 'linux ...' line for GuixSd grub entry. Also tried other flags but nothing really worked. It booted with QEMU from Arch without truoble.
<sneek>jlicht, ng0 says: I don't see the full backlog. if there was anything else added it escaped the buffer. If there are problems, it's for other people to fix as I currently focus only on project tasks (ie: gnunet+secushare related works in all kinds of projects)
<bishopj>How about a manner of build hydra voting? Aka only if a certain majority build correctly consider it a valid build. Then just use different hardware and kernels and bootstrap systems to increase the odds of catching something
<mark_weaver>rain1: I keep copies of failed logs on hydra that I suspect might work when retried, and sometimes I file bug reports
<jlicht>Is there an easy way to find out exactly how 'configure' was called when building a package with the `gnu-build-system`?
<mark_weaver>bishopj: to gain confidence that the builds are genuine, I think we need people with completely independent systems building stuff and making sure it matches what hydra provides, which is what "guix challenge" is meant to do
<bishopj>mark_weaver: could it be a help to the project for me to setup an independent build server?
<mark_weaver>bishopj: yes, independently-run servers that build guix packages from source code and finding cases where the outputs differ from what hydra provides would be very useful, indeed!
<jlicht>I have a configure script that tries to detect a 32-bit userland on a 64-bit cpu by checking for the existence (and ELF-type) of /usr/bin/env. Should I try to patch this configure file so it just compiles for the cpu architecure, or is there a better way?
<bishopj>mark_weaver: then I would love to help then :D
<jlicht>(quote from the script: " /usr/bin/env exists *everywhere*."
<lfam>I saw this subject mentioned on reddit recently, and GuixSD came up. I think it may be our claim to fame ;)
<mark_weaver>jlicht: you might check if it is possible to inhibit the /usr/bin/env test by passing a suitable argument to ./configure, but if not, patching might be the best way
<janneke>lfam: it could be that windows beat us to it
<mark_weaver>bishopj: a few things: in order to be most useful in this way, it should avoid getting any binaries from hydra, so that a compromised hydra would not be able to compromise your system as well.
<jlicht>is it a sane default to assume 32 bit cpu -> 32 bit userland, and the same for 64 bit?
<bishopj>mark_weaver: not a problem, considering that the 0.10 does not even include the .pub for hydra
<mark_weaver>and the other thing is that hydra must not be able to detect that it is you that is asking for the binaries
<mark_weaver>because a compromised hydra might try to hide itself by delivering good binaries to you (and anytime it detects that it is being tested for authenticity) and bad binaries to some other people
<bishopj>mark_weaver: well that might be hard but I could use some proxy configuration to route though multiple IP addresses and if possible though tor
<bishopj>mark_weaver: Also, I would never actually use any binaries provided by hydra but rather only binaries built locally
<mark_weaver>civodul write 'guix challenge'. I let him know that it was important that 'hydra' must not be able to detect requests coming from 'guix challenge' compared with other requests, but I haven't checked to see if that is the case.
<bishopj>mark_weaver: Honestly, if hydra seperated the building of packages out from the distribution. It would be much easier to add support for new networks and protocols for the distribution of sources and binaries
<quiliro>but i still have some problems with my wifi
<quiliro>is it possible for you to allow linux-libre to load the free firmware it is not loading?
<quiliro>lfam: you were right.... openfwwf was only packaged for me
<mark_weaver>so it might be better for substitutes to only include the hashes of the files within, and then to fetch those files from content-addressed storage instead
<bishopj>lfam: Although I only am hoping torrents for the ISO releases
<mark_weaver>and then the things you are downloading are even more numerous and smaller, which means you better minimize the per-download overhead
<lfam>Everything tends toward a content-addressed block store ;)
<quiliro>at Hello mashi Alexandre (Mashi is the kichwa word for friend, partner, associate, camerade. Kichwa is the language spoken in the Andes mountain region along the West of South America). I am trying to lo use Broadcom wireless device on GuixSD. It is confirmed to work with free drivers and free firmware. It works correctly in Trisquel too. dmesg gives the following messages. I have included only the relevant parts:
<quiliro>[ 20.400251] b43-phy0: Broadcom 4311 WLAN found (core revision 10) [ 20.432041] b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8 [ 20.432058] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 2, Version 0 [ 20.444116] Broadcom 43xx driver loaded [ Features: PNL ] [ 20.444306] ssb0:0: Missing Free firmware (non-Free firmware loading is disabled) [ 20.444308] Unable to load firmware [ 20.591119] b43 ssb0:0:
<quiliro>Direct firmware load for /*(DEBLOBBED)*/ failed with error -2 [ 20.591135] b43 ssb0:0: Direct firmware load for b43-open/ucode5.fw failed with error -2 [ 20.591154] b43 ssb0:0: Direct firmware load for b43-open/ucode5.fw failed with error -2 [ 20.591158] b43-phy0 ERROR: Firmware file "b43-open/ucode5.fw" not found [ 21.313688] b43-phy0 ERROR: /*(DEBLOBBED)*/ 'lspci -vmmnn -d 14e4:' shows: Slot: 03:00.0 Class: Networ
<lfam>The worst case is if people start putting the files on public trackers, and users start downloading whatever comes up when they search on Pirate Bay or some site like that
<lfam>We should probably pre-empt the demand for that
<bishopj>Let them download torrent files from Pirate Bay and provide a signature that will be useful for validating which one is right
<lfam>Yes, but many users won't check the signature. At least on our site, the signature is right there.
<lfam>I'd guess that the majority of users don't check signatures. We have to remind them and make it easy.
<adfeno>All that is need is the torrent file (or magnet) and the client, and if you're seeding trackerless torrents, you'll need an open port. That's all. Then, start putting the torrent files and magnet links somewhere public, so that your peers can enjoy.
<adfeno>I personally don't like to use public trackers. My torrents are mostly trackerless.
<bishopj>Providing options for users is something we should honestly consider
<adfeno>I only keep the torrents that are officially from our partners around the free software movement, or that are high-quality and under a format used by free software by default.
<mark_weaver>I suppose i don't have any specific objection to providing torrents for our installers, but at this point I'm not sure what it would help, exactly.
<adfeno>The others I usually don't seed. I actually reencode them to a file format used mianly by free software, and provide them without trackers.
<mark_weaver>I don't think we have enough people downloading our installer at any given time to benefit much from a torrent
<mark_weaver>to be honest, I doubt we have more than one person downloading it at a time
<mark_weaver>http supports resuming downloads, as does wget and downloaders built into modern web browsers
<bishopj>mark_weaver: The benefit wouldn't be about saving you bandwidth but rather making the installers more available to users
<bishopj>As to the previous topic... mark_weaver: If you provide a write up on how to setup a mirror, I'd be more than happy to convert it to a bunch of deploy scripts and stand up a few mirror/build servers to help the project. Am more system administration than programmer
<jlicht>A guix config.scm that provides the basic setup for a mirror would be even more awesome
<lfam>bishopj: If you just want to mirror substitutes, check out guix-maintenance.git and adapt hydra/nginx/mirror.conf. I run a private mirror to speed things up for me and take some load off the public ones
<lfam>Yeah, a full OS declaration would be awesome
<bishopj>Honestly, I am far more familiar with puppet and chef than guix at this point but I figure do a mirror setup in puppet to document to myself what exactly needs to be done and then attempt to convert that knowledge into a guix OS declaration.