<civodul>it could be that the .drv for that path was GC'd <civodul>you mean like you have emacs-24.4 but not emacs-24.4.drv, right? <davexunit>it blows up guix publish, will have to handle that case. <davexunit>the good news is that I see many successful narinfo GETs in my log <civodul>oh, you need the .drv when filling in the "Derivers" field, right? <davexunit>yes, I need that. and that field *is* filled out correctly. <davexunit>but I then wrongfully assume that I can read that derivation file <civodul>here's an idea: just leave it as "Deriver: " <davexunit>but without the derivation... I don't know know how to fill out the "System" field. <davexunit>I guess I'll have to throw 404 in that case, but I want the derivation *back* <civodul>running guix-daemon with --gc-keep-derivations will make sure that .drv remain <civodul>it does --gc-keep-derivations --gc-keep-outputs <davexunit>I'd like to know how to get the derivation back. <davexunit>like, purge the relevant output from the store and rebuild <civodul>hmm there's the 'valid-derivers' RPC <civodul>i think db.sqlite knows all the derivers, but there's no RPC for that <davexunit>real quick: do you know to forcibly gc an output? <davexunit>hmm, getting 'invalid nar signature' every time I try to use a substitute from my 'guix publish' server. <davexunit>I'm stumped. I used export-paths in (guix store) to dump the nar file... <davexunit>the beginning of the file should start with the string nix-archive-1. <davexunit>preceeded by some numbers that give the length of the string to read. <davexunit>I can see that it has that, yet the result of reading the first string is "\\r" <mark_wea`>bah, firefox-31.3.0 has been out for about two weeks with some important security updates, and there's still no new icecat release. <mark_weaver>jxself: I am remembering correctly that you were opposed to us running ruben's script ourselves to create icecat from firefox? <mark_weaver>jxself: what do you suggest we do about the security vulnerabilities? <jxself>The easiest is probably to poke quidam for a new version, which I've done. <jxself>There are also other options, too, if they're done right. <jxself>"Have people download Firefox and then run this user-executed freedom patch" would not be one of them ;) <mark_weaver>well, end users would normally download the end result of that script from hydra <mark_weaver>if you're opposed to making it easy for people to do the process themselves, then I guess you should object to the publication of ruben's scripts. <mark_weaver>if your advice is to always wait for ruben to run his script, then he's going to have to be more prompt about it. <mark_weaver>to be clear, even if users ask guix for the source code, they would still normally download the end result of the script from hydra. <jxself>Back when LibreWRT was trying to become an FSF-endorsed distro we had a question about the firmware building process and what the FSF's opinion was. The build system is just a bunch of scripts that download things from various places, applies any desired patches, makes a cross-compiler, and proceeds to make the firmware image for the target router. <jxself>The upstream (OpenWRT) of course had their build system grab the kernel from kernel.org. The question that was submitted to the FSF was if it was sufficient to modify the build system such that it also grabbed the Linux-libre deblobbing scripts during the build process, then deblobbed the kernel source on the user's computer, or if the build scripts needed to instead download an already-cleaned kernel and use that instead. <jxself>Brett's response was that we needed to have people download the already-cleaned stuff, so that they were being steered to and downloading non-free software, and that's what happened in the end. <jxself>And so this is the type of situation I hope can be avoided in Guix. <mark_weaver>There are two issues here. One is that Alexandre is super-prompt about getting linux-libre updated. I guess he has some kind of automated system. <jxself>It's scripted, but still manual work is involved. <mark_weaver>but the other problem is that if everyone is trusting Alexandre's or Ruben's computers to do that job, then it makes it extremely useful for the NSA (or whoever) to attack those computers. <jxself>And telling people to download non-free software is the answer to that? <mark_weaver>I'm not suggesting "telling people" to do that. Do you think that Ruben's or Alexandre's publication of his scripts constitutes "telling people to download non-free software". <mark_weaver>I'm looking at Ruben's script right now, and it downloads non-free software. <jxself>Yes, it has to in order to modify it. :) <mark_weaver>Here's line 50: wget -N ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/${FFVERSION}esr/source/firefox-${FFVERSION}esr.source.tar.bz2 <mark_weaver>do you think that publication of this script is tantamount to "telling people to download non-free software" ? <mark_weaver>but you think that making it easy to run this script from guix is tantamount to that? <mark_weaver>making it easy to run a script that is the source code of an official GNU project. <jxself>In your plan, what would the uri in gnuzilla.scm be set to? <jxself>I meant for source code. Currently it is something like "mirror://gnu/gnuzilla/" version "/" name "-" version ".tar.xz" <mark_weaver>the source would have to itself be another package recipe that downloaded ruben's script and run it. <jxself>So another recipe in, say, gnuzilla.scm. <jxself>And so when someone told guix to install icecat this other recipe would be invoked to grab Rubén's script and download the source code themselves from mozilla.org. <jxself>That seems very similiar to the situation I emailed to the FSF some years back about the LibreWRT build system where people building firmware would grab the kernel from kernel.org and then clean it on their computer. <jxself>So, while Rubén merely publishing his script isn't the same as telling people to download non-free software because the general public doesn't have to use it in order to get icecat. They have already-cleaned tarballs to use instead. <jxself>But in the case you've described it seems different because that then does become necessary. <mark_weaver>the normal (and recommended) setup is that you download substitutes from hydra.gnu.org, and that includes the results of ruben's script, if the user asks for the icecat source code. <mark_weaver>but yes, for those who don't want to trust hydra, we provide the ability to do the job on their own computer. just like ruben and alexandre provide the means for people to run the scripts themselves. <jxself>But substitutes are not enabled by default, and it's really the source code that needs to be free. The binary follows that if all goes well. <jxself>Yes, they provide the means for those that are interested but it's not a precondition to get the software. <mark_weaver>if you ask guix for the source code, you get the output of ruben's script <mark_weaver>would it satisfy you if substitutes were enabled by default? that's probably going to happen anyway. <jxself>I could have made the same argument to the FSF. "When people build a kernel they merely get the output of the Linux-libre deblobbing script." <jxself>But, since Brett said it wasn't okay, we didn't go in that direction. <jxself>It seems that it's the FSF this needs to be taken up with really. ;) <jxself>And if he says that your plan's okay I'd like to know what's different about this case and LibreWRT's case. <jxself>Surely he'll be able to explain that, he always seems to do such a great job explaining stuff. :) <mark_weaver>I think the difference is that if you looked at the LibreWRT source code before that change was made, you'd see non-free software, whereas in our case, if you look at the source code of any package, you'll see only free code. <jxself>I don't understand why that difference would exist. <jxself>The LibreWRT build scripts are all free software. <mark_weaver>I'm not talking about the build scripts, I'm talking about the source code for the packages it contains. <jxself>The only non-free stuff that would have been downloaded is from kernel.org, and only after going through the whole make menuconfig thing to select what router you were compiling for and what packages you wanted included in the firmware image. From that point on it's all automatic. <mark_weaver>before they made the switch to downloading linux-libre, if you wanted to look at the source code of their kernel, you'd probably see non-free code, yes? <mark_weaver>the stripping of that non-free stuff was probably part of the process that produced the binary executables. <jxself>No, because no kernel was included. <jxself>Yes, it happened during that phase. <jxself>But it seems the same situation wit guix, since Ruben's script is running on the user's computer and so they're still downloading the non-free software to their computer. <mark_weaver>so in their case, the free version existed only ephemerally during the build process, and the "source code" that people would see was probably the upstream linux. <jxself>No, the source that was left behind was the cleaned stuff. <jxself>Because lxo's script deleted all of the problematic stuff. <jxself>And so that src directory had linux-libre in it. <mark_weaver>well, I don't know the details of the LibreWRT case, so I should probably avoid talking about it. <mark_weaver>it sounds to me like you're saying that the presence of Ruben's or Alexandre's scripts in a distro are enough to disqualify it from being DFSG compliant. <jxself>It was going to disqualify LibreWRT. <jxself>And there have been other cases (like with Parabola) where they had similiar plans and during the process of reviewing the distro for endorsement they were told to change. <jxself>And so my objections to it are based on these precedents. <mark_weaver>those two scripts being the true source code of two highly valued GNU projects. <jxself>Which is why, if RMS says your plan's okay, how it differs from the other times this issue has come up. <mark_weaver>I say "true source code" because that's what's in the VCS, and what developers actually edit. <jxself>Which is why, if RMS says your plan's okay, I'd like to know his explanation for how it differs from the other times this issue has come up. <rekado_>How can I force a rebuild of a package that I already installed? <mark_weaver>rekado: delete it using "guix gc --delete /gnu/store/...." and then build it again. <mark_weaver>note that "guix gc --delete" will refuse to delete it if there are any references to it, so you'll also have to delete any profiles that include it, and any other store directories that refer to it. <mark_weaver>another trick, if you're working on your own package recipe, is to change the package in some trivial way that will change the generated derivation. <rekado_>hmm, I cannot seem to remove any package from my profile. <rekado_>will try older versions of guix; currently all I get is a backtrace :( <rekado_>sent a bug report to the list. This is very odd. <rekado_>hmm, I guess I don't actually need to do that; I only need to build it for a different architecture. <rekado_>but it's still weird that I cannot remove a package from my profile. <mark_weaver>rekado: what command are you using to try to remove a package from your profile, and what's the error? <jmd>How can I list all packages complete with synopsis and description? <jmd>Sleep_Walker: Thanks. <civodul>davexunit: did my reply help in any way? <davexunit>If export-paths isn't producing the correct format, then I guess I have to write a new procedure? <civodul>in short: use 'write-file' to produce the nar <davexunit>the substituter should be satisfied and will give me the archive for my custom test package :) <civodul>that's starting to sound really cool! <davexunit>I noticed that the daemon does not support multiple substitution servers. <davexunit>removing that limitation would allow for some cool peer-to-peer stuff <civodul>note that the daemon has --substitute-urls (plural) <civodul>it's substitute-binary that cannot handle it :-) <davexunit>that's indeed where I found the code with the limitation. <civodul>yeah, that doesn't make any practical difference, just nitpicking <davexunit>so, once the nars are valid, I need to figure out signing and compression. <davexunit>compression should be easy enough, I think, since guix can already handle bzip2. <davexunit>signing is also already there, but I need to generate the proper "Signature: <sig>" line in the narinfo resources <civodul>i think tests/substitute-binary.scm shows how to do it ***nkar_ is now known as nkar