<sietedosfede>Hello, anyone anytime suffered this kind of error while booting the live image of GuixSD:acpi error no handler or method for gpe <sietedosfede>Boot just keep printing that line with certain unlegible parameters at almost speed of light. Seems like screen drivers not working properly. <sietedosfede>Anyone knows a kernel parameter that could help solve this? Thanks in advance <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 <rain1>because they're cross linked? <lfam_>I'm not sure why yet. It fails to build with "ocamlbuild: command not found" <lfam_>This version of ocaml is when they stopped distributing ocamlbuild with ocaml. It's a separate package onw <rain1>it's always trouble knowing who provides what <lfam_>Sadly, I just wanted to update to fix a bug. Maybe I can just patch the existing version instead. <lfam_>Gah, I have to look up how to use SVN again <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>anyhow i got it up and running but bad me need nonfree kernel i think <adfeno>What is the message you're seeing <f0ff>comfy with x and the fontrendering atm is very dodgy.. <f0ff>i don't know what kind of video mode is running atm, but i know that is fine with non-free stuff <adfeno>Hm... ATI has an history of not being freedom frinedly. <adfeno>But, we can have ways around it... Let's see... <adfeno>Is there a message that appears in the screen? <f0ff>yeah some firmware blobs heh.. also ksm is nice.. but i don't have that <f0ff>[ 4.231688] radeon 0000:01:05.0: Direct firmware load for /*(DEBLOBBED)*/ failed with error -2 <f0ff>[ 4.231763] [drm:r600_init [radeon]] *ERROR* Failed to load firmware! <f0ff>[ 13.671541] 0000:03:00.0: Missing Free firmware (non-Free firmware loading is disabled) <adfeno>Can you tell me how many GPUs you have on your computer? <mark_weaver>f0ff: if you have the means, I would encourage you to acquire hardware that does not require non-free software to use <mark_weaver>in any case, Guix is committed to including only free software <adfeno>Is there only one (ATI)? Or are there others available inside the computer or at your disposal to try out? <f0ff>no it is only the onboard stuff.. and that will remain ati <adfeno>Don't you have a spare GPU near you, so you can remove the current GPU and place the spare one? <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. <mark_weaver>f0ff: please understand that the hardware problem (hardware that requires non-free software to work) is not going to get any better until there is pressure on manufacturers from users <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.. <f0ff>i guess it is kinda hard for vendors to release the "source" for blobs at times <f0ff>the hardware isn't all free <f0ff>and the blobs comes bundled with that <f0ff>it isn't software per see(sp) <mark_weaver>it's relevant whether OS distributors such as Guix need to include non-free software <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. <f0ff>yeah i just installed it :) i got rain1's link so i'll check it out.. atm i just want to read the text in emacs without squinting.. i guess i'm in some s/xvga mode :P <lfam_>f0ff: There must be a way to make your text rendering better with free software. Are you on the console or in X? <f0ff>but i'm so confy with x that i kinda require it :P <lfam_>Are you using a desktop environment, just a window manager, etc? <f0ff>i did the gnome/xfce install from examples <f0ff>gnome bails without acceleration i guess.. xfce meh kinda works <f0ff>or well gnome doesn't bail but you bail because you can't tolerate the rendering time so you reboot :D <lfam_>f0ff: I had acceleration issues with GNOME when I ran it in QEMU. I thought we fixed that before 0.10.0 was released... <lfam_>Ah, I see. Yes, it's painful :) <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 .. <f0ff>can't afford a free computer ;-) <f0ff>nah it would work nice without blob feeding <f0ff>maybe my cheap led screen also make it hard on the eyes with this resolution <adfeno>I hope you don't recommend the non-free software you put there to your peers... <f0ff>there isn't much control you can have over your computer atm.. it runs out of hand when most compoments runs their own computers heh <rain1>we are screwed if we don't get serious about free hardware and instruction sets ASAP <adfeno>:D But we must find the right free hardware design to support. <adfeno>... Because if we end up supporting simply the "open hardware" projects, we might end in a tight spot. <rain1>the gap in power between high range current intel and a newly released free RISC-V might be very large to begin with <rain1>I'm happy to make that sacrifice for a totally libre stack, i'm looking forward to it keenly <rain1>in qemu they can run risc-v linux alredy <rain1>once a powerful risc-v computer comes out we can get guix on that no trouble <f0ff>rain1: thanks for the definition! <- that was the good part .. it seems very chatty and a bit hardcoded.. is a tool used to "render" the definitions? <rain1>they're usualy written by hand or copied and changed <rain1>i made a GUI tool to help created them but it isn't well tested so might not be useful <f0ff>is it possible to get/find definitions for installed packages? <f0ff>thanks :-), i'll probably be back for more stupid questions later, need to get me modesetting right first if i don't wanna end up blind heh :P ***vasile_ is now known as vasile
<cpjjl>Hi, why is it advised not to put user packages in global configuration file (/etc/config.scm), even if there is only one (human) user on the system? <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) <cpjjl>janneke, I read that in the doc <janneke>ACTION likes explaining consequences of a choice better than any advice for or against it <df_>cbaines: it looks like the match fails because it is expecting two command line args: system and output file <df_>no idea if it does what you want though <pmal>Maybe someone could guide me how to configure printer on guixsd ? :D <ajgrf>pmal: that's generally not working right now. you may have some luck with networked printers in gnome apps, but otherwise step 1 involves writing scheme code to integrate cups into guixsd <pmal>I was trying to run cups, but without luck, so thought to ask here. ***remi1 is now known as remi
<bishopj>Is there a way in guix to only utilize packages that have reproducible builds? <roelj>bishopj: Do you have an example of a package that whose build isn't reproducible? <bishopj>Not exactly, I am just attempting to figure out why when upgrading guix on a system that has not been upgraded in a while, that ALL of the package builds seemed to failed. <bishopj>The primary reason it hasn't been upgraded in a while is because I have not yet figured out how to setup proxy settings in guix <roelj>Right. When a package fails to build, I think that is a bug. Could you try upgrading a single (small) package: guix package --upgrade=<package-name-here>? Then post the build failure output. <bishopj>According to hydra.gnu.org the package build is failing and looks like has been for a while <roelj>Ok. Then it will reliably fail to build on your local machine as well ;) <roelj>You could exclude it from the upgrade with the --do-not-upgrade flag <bishopj>I was hoping for a general mechanism to only allow packages that have had a successful reproducible builds <roelj>Well actually, the build fails reproducibly.. But you probably want only succesful builds :) <roelj>So the build fails at "make[4]: *** No rule to make target '../../gnu/packages/weechat.scm', needed by 'guix-packages.pot-update'. Stop." <bishopj>Exactly, If only there was a way to make that information available on the server, such that all of the clients will not consider it an upgrade until it builds successfully <roelj>I do not know a solution to this though. <bishopj>Perhaps a new feature to the hydra software perhaps? <roelj>I think the information is already there (hydra provides it), so it should be doable to implement this. <roelj>But I don't know the code involved <bishopj>Perhaps it could be a feature request for the next release <bishopj>Also I do need an ability to configure guix to use a specific network proxy <roelj>icedtea:jdk is what I use myself. ***imrekt is now known as ir
***ir is now known as imr
<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. <sietedosfede>I readed that yestarday. It's just IDK if kernel is succesfully loading the parameters or what else... <lfam>Can anyone figure out how letsencrypt and xscreensaver both depend on subversion? <janneke>ACTION has been building subversion more often today than ever used it :-( <sietedosfede>I was thinking I could try pre-loading the kernel parameters before making the GuixSD an ISO, it's just I don't know how to for now <lfam>sietedosfede: We have a few older versions of the kernel in our package tree. You could try using one of those <sietedosfede>lfam: That's will I do! I'll report later then. Thank you. <lfam>janneke: Do you have any idea? `guix refresh -l subversion` makes it look innocuous, but it seems to be "underneath" many packages! <janneke>lfam: i haven't looked into it, just saying it annoyed me too <lfam>Yes, very annoying. But if it's necessary, and we fixed that bug, then that's just how it goes! <janneke>weird, the refresh guix --list-dependent subversion can't be right <lfam>Since git depends on subversion, I wonder if git-download packages also require subversion, even though git-svn should be a separate output. <sietedosfede>Sorry my newbie question but, when I extract the .xz guixsd-usb-install it have not extension: How can I navigate the file itself? <lfam>sietedosfede: Did you decompress (with `xz -d`) or un-archive (with `tar xf`)? <lfam>Then, it's still a tarball <lfam>So, you need to extract it with `tar xf foo` <sietedosfede>Question: In order to modify something like a grub config I need to build it from source? <lfam>`file` calls it "DOS/MBR boot sector" <lfam>Do you have Guix (the package manager) installed? <lfam>If you install Guix, then you can build your own installer with `guix system disk-image`. That's actually how we create the installer. <lfam>If you search in the manual for install.scm and 'disk-image' you will find relevant help <lfam>Also, the file 'gnu/system/grub.scm' is where the GRUB configuration is generated. I don't understand it fully but I have been able to make small edits successfully <lfam>Man, my dinky VPS was able to run subversion's test suite much more quickly than my workstation ***imr is now known as imrekt
<rain1>what are your favorite text editors on guix? other than emacs <rain1>wow why does mpv depend on texlive :| <rain1>mpv depends on vapoursynth which seems to need it <rain1>which depends on leptonic which depends on gnuplot-5.0.2 <rain1>so: mpv < vapoursynth < tesseract-ocr < leptonic < gnuplot < texlive-minimal <rain1>what would be the best way (if possible?) to remove the dependency of texlive from mpv? <lfam>You'd have to investigate whether leptonica can be built and used without gnuplot <rain1>ah! says that is only needed for test suite <lfam>Oh, I misunderstood your correction. But, you'd have to find some place where it might be option. <rain1>having to download 1.76GB of latex stuff to run tests on library thaht a library that the video player i want uses it XD <lfam>Good thing it's easy to make package variants :) <lfam>I might make a subversion variant without a test suite! <rain1>I had to sit for about an hour or more waiting for those svn tests <rain1>maybe a nice thing would be a env var that says don't bother running tests (or install deps to run tests) <rain1>oh that wouldn't help here, it's a native input <lfam>Well, I wouldn't distribute it. I wouldn't even use it to build software I'm going to use. But for testing things, it would be nice to save the time. <lfam>Disable one test suite to run another <rain1>what is it supposed to do? nothing works anyway <rain1>it's just some kind of superstitious cargo-cult thing to try to keep bugs away <lfam>I've "built" many packages successfully until I figured out how to enable the test suite. It catches portability issues very often <lfam>And, I think things would work even less without good test suites ***pizzaiolo1 is now known as pizzaiolo
<rain1>I had this issue when I tried to build a web browser <rain1>g++ crashed when building webkitgtk <rain1>so i ended up having to just use a binary of fierfox <mark_weaver>lfam: your poppler fix looks good to me, and seems to work well for me. please push :) <rain1>ac++: internal compiler error: Killed (program cc1plus) <mark_weaver>rain1: I've seen that happen on hydra occasionally as well. retrying the build usually works <rain1>might be not enough memory on my computer, it's a shame <lfam>I think that should be plenty! <rain1>these web browser programs really stress the C++ compiler <lfam>Yeah, they are very expensive to build <rain1>i've had a similar thing with building ff on guix (not on arch linux though) <mark_weaver>rain1: fwiw, I've built webkitgtk successfully on my i686 machine with only 2GB of RAM <rain1>i wish i could do without a browser but i can't <mark_weaver>rain1: and I seem to recall that I've built it on x86_64 with 4GB of RAM as well <rain1>I'll give it 3 tries and see if it manages to build <mark_weaver>several of our packages occasionally fail to build due to internal compiler errors on hydra <mark_weaver>I've seen it happen several times with ardour, clang, llvm, webkitgtk and qt <rain1>is there any coordination between different build servers (or even just between different builds) to list out which packages are built reproducibly and which aren't? <mark_weaver>hydra doesn't attempt to build things more than once, unless I ask it to retry a failed build <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`? <jlicht>also, how does this sneek thing work :O? <mark_weaver>jlicht: the default 'configure' phase of 'gnu-build-system' prints the arguments passed to configure in the build log output <mark_weaver>jlicht: write "sneek: help" and he'll send you some info about the commands in PM <mark_weaver>bishopj: hydra doesn't have enough spare capacity to build things more than once, and also, having hydra do it all automatically would not detect security breaches in hydra itself. <jlicht>mark_weaver: thanks, that's quite useful <bishopj>In what way is its capacity limited? <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 <mark_weaver>bishopj: we don't have enough build slaves, and also the master machine itself is overloaded <lfam>rain1: That's not supposed to happen! Did you have to cycle the power? <janneke>ACTION is feeling like a build slave today ;-) <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? <lfam>janneke: Perhaps by a little 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: I also was thinking of alternate root binaries to create the root binaries of guix to look for any trusting trust attacks inside them <mark_weaver>but certainly hiding the originating IP address of your build server would be important as well <bishopj>mark_weaver: well then tor support for guix challenge might be important then <mark_weaver>bishopj: and tor support for ordinary substitutes as well, so that challenges and subtitute downloads are indistinguishable <mark_weaver>as for the bootstrap binaries, it is true that we need a way to verify them as well, and so far that hasn't been done. <mark_weaver>ideally, we would have a documented way to produce suitable bootstrap binaries from diverse starting systems <bishopj>mark_weaver: we might also want to consider other privacy network support as well to further increase the possible hidding space <mark_weaver>we have a plan to use gnunet for distribution of binary substitutes <mark_weaver>I don't know of any other anonymity network that comes close to the size of tor, though. <quiliro>finished reading the manual completely <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? <lfam>quiliro: You need the openfwwf firmware, right? <bishopj>mark_weaver: For example why use torrents for the distribution of guix? That way there is no single point from which you must get anything <quiliro>lfam: but i think it is already leaded <quiliro>the firmware is in another directory <quiliro>linux-libre at first says it is nonfree and then says it is missing <bishopj>mark_weaver: torrents have the wonderful property of allowing everyone to be sure of getting the exact same thing <quiliro>but the file that linux-libre says is missing is in another directory <lfam>quiliro: I don't think we have openfwwf in Guix yet. I think you are the only person that has it so far. <lfam>quiliro: Somebody gave you a patch in this channel, right? Can you send the patch to guix-devel@gnu.org so other people can look at it? <mark_weaver>bishopj: building and distribution of packages is fairly well separated out in guix. "guix archive" allows exporting and importing of packages <lfam>I'm not sure... does anyone know if you guix-devel allows non-subscribers to send mail? <lfam>quiliro: If so, I'll send it to guix-devel for you if you put it on a paste site <mark_weaver>lfam: posts from non-subscribers have to go through moderation, and I'm not sure how often that's dealt with <mark_weaver>but mail to bug-guix should be allowed from non-subscribers <lfam>Good idea. That way, quiliro, you would get updates to your bug only, rather than all of guix-devel. Will you send it to bug-guix@gnu.org with a description of the problem? <mark_weaver>bishopj: I'm not sure how torrents provide any extra guarantees of everyone getting the same thing than we already have <mark_weaver>bishopj: at some point, you fetch a torrent file, and a man in the middle could give you a different torrent file than other people are getting <quiliro>lfam: so you suggest not subscribing to any list? <jlicht>mark_weaver: at least you'll get your compromised binaries faster ;-) <lfam>quiliro: Correct. You can send a message to bug-guix@gnu.org and then you will automatically get replies to your mail, but not to the other bugs. <mark_weaver>most of our substitutes are quite small, and I suspect the overhead of torrenting would be too much <mark_weaver>we need a faster hydra.gnu.org master machine, which is coming soon, and we also need mirrors <bishopj>mark_weaver: well for one ensuring 16KB not being compromised is alot easier than 100MB being uncompromised <mark_weaver>the other thing is that we can already envision how to substantially improve the efficiency of substitute distribution from deduplicating them <lfam>bishopj: Do you know any torrent clients that can serve tens of thousands of torrents? <mark_weaver>e.g. it's quite common that substitutes of updated packages are almost the same as an earlier version you already downloaded <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 <quiliro>controller [0280] Vendor: Broadcom Corporation [14e4] Device: BCM4311 802.11b/g WLAN [4311] SVendor: Hewlett-Packard Company [103c] SDevice: BCM4311 802.1 <lfam>I will have to look into rtrorrent <quiliro>i do not know how to erase a text i pasted chating through emacs <mark_weaver><bishopj> mark_weaver: well for one ensuring 16KB not being compromised is alot easier than 100MB being uncompromised <lfam>bishopj: We don't offer ISO releases ;) But I get your point <lfam>quiliro: It's okay. I'll read and comment on your mail <bishopj>mark_weaver: well for one, you could simply print 16KB and obtain it that way <bishopj>mark_weaver: torrent files can be signed and the files within the torrent can be signed as well. <mark_weaver>okay, and how is that easier than signing the nar (Nix archive) files? <bishopj>mark_weaver: I am not talking about updates once someone has guix installed but rather the mechanism of obtaining it for the first time <lfam>The installers are also signed <mark_weaver>okay. how is it easier to sign a torrent than to sign the installer itself? <bishopj>lfam: but the installer is hard to obtain with a flaky internet connection <bishopj>mark_weaver: It isn't but torrents are much better at downloading exact binaries when the network is flaky <lfam>I remember reading that curl or wget had some support for resuming failed downloads <lfam>We could also offer an rsync link, and users could do `rsync --partial`. I'm not sure how that would affect trust issues <bishopj>lfam: yes but wget -c doesn't correct bit corruption in downloads <lfam>Yeah, offering a more resilient download mechanism would be good <adfeno>I prefer torrents because I can share it once done. <bishopj>Even Debian, ubuntu, Centos, Arch, Gentoo and many other Linux distributions offer torrents for their install media <adfeno>And it's way easier to share than with traditional ways. <adfeno>No matter if the torrent is trackerless or not. <bishopj>One can also encrypt a torrent file to send to a friend and there would be no way for an attacker to know if it was an email message about something sensitive for a torrent file <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 <adfeno>mark_weaver: By "installers" you mean GuixSD images? <mark_weaver>I don't know anyone who finds it easier to download a torrent than to download over http <bishopj>Well for one, I find it easier to download over torrent <bishopj>When I download Gentoo images, I get it at 1GB/s with torrents. 2MB/s with using https <adfeno>mark_weaver: I find it more "gently and caring" to download and *seed* torrents that I like. Mostly because it shifts the network overload *away* from the original provider. <mark_weaver>that depends on there being a large number of seeders <bishopj>mark_weaver: or a few very fast ones, such as myself <adfeno>I try to seed between 64KB/s and 128KB/s per torrent. <adfeno>↑ This is because I have all my completed torrents seeding. <bishopj>adfeno: I just let rtorrent calculate the bandwidth to allocate to each torrent automatically based upon available bandwidth <lfam>Off-topic: How do you get the arrows? Does your client make it easy or do you just remember the codepoint? <adfeno>Nowadays, I'm trying to finish the creation of torrents for each of the LibrePlanet talks that I like. <bishopj>lfam: If using erc simply C-x 8 <enter> <adfeno>lfam: AltGr (right Alt) + Shift + U <bishopj>emacs list-unicode-display provides a search option for unicode chars too <bishopj>simply use-package list-unicode-display <lfam>That's what I mean by your client making it easy. Maybe one day I will start using Emacs :) It seems very nice <bishopj>lfam: The secret to learning emacs is to not try to do anything complicated <bishopj>simply use emacs to start taking notes <bishopj>Then you'll discover org-mode and your notes will get alot better and simply use it where it makes your life better <bishopj>Emacs is a tool you can learn in 5 minutes but it takes a lifetime to master <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.