Re: [GNU-linux-libre] Parabola GNU/Linux
Joshua Ismael wrote: > Archlinux has an automatic building system in wich you > provide some information and the script automatically > build them. > > For Parabola GNU/Linux we provide scripts for deblobing > while building so anyone can compile it's linux-libre kernel > from the vanilla source. > > If the purpose is to provide the means to build a free > kernel we already make this. Isn't this enough? My understanding is that the existing free distros provide already-deblobbed kernel source code for their users to get, instead of having them download the original unmodified tarball from kernel.org. My own personal opinion is that grabbing the corresponding linux-libre tarballs and then fixing any distro-specific patches that don't cleanly apply is a better choice. It's a good question, though: Can a free distro have their users download nonfree software and then go through the process to clean it up later? signature.asc Description: This is a digitally signed message part
Re: [GNU-linux-libre] Parabola GNU/Linux
On 03/01/11 17:20, Jason Self wrote: Parabola is a GNU/Linux distro that claims to be a fully free copy of Arch. In reviewing it I have some concerns: 1. The Parabola developers perform no rebranding of any kind. This results in the installer claiming to the "Arch Linux". I've also found that the GRUB menu lists it as "Arch Linux" when booting, and so does the login prompt. (There's probably more, I imagine but that's where I stopped.) I wonder how this fits in the the "we will not list a distribution whose name makes confusion with non-free distributions likely" in the Free Distro Guidelines? I've also discovered this as of this afternoon: "We avoid having a kernel-free distro (!) by packaging a vanilla kernel and applying ArchLinux's patches, but deblobing everything before compiling and packaging." [2] I took this to mean the binary has been "freed" but not the source. I then grabbed the source from [3] and verified that it does indeed contain all of the non-free parts of the kernel. I think that this means their kernel deblobbing efforts are insufficent, if anyone is able to go and obtain the non-free bits of the kernel in this way. Archlinux has an automatic building system in wich you provide some information and the script automatically build them. For Parabola GNU/Linux we provide scripts for deblobing while building so anyone can compile it's linux-libre kernel from the vanilla source. If the purpose is to provide the means to build a free kernel we already make this. Isn't this enough? Has anyone else looked at Parabola? [1] http://parabolagnulinux.org/ [2] http://wiki.parabolagnulinux.org/index.php?title=Blacklist [3] http://repo.parabolagnulinux.org/sources/packages/kernel26-2.6.36.2- 1.src.tar.gz
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
What you propose is implemented by the following commands: git branch -f branch1\' branch2 # branch1' is now same as branch2 git rebase --onto branch3 branch1 branch1\' # now branch1' is branch3 plus changes in branch2..branch1 I am glad the operation exists. However, the full operation I have in mind allows multiple substitutions. The example I stated before uses just one, which I could describe as replacing c2 with x. However, there are multiple blobs that were first inserted at different times, and we need to deal with all of them. Maybe a series of rebase operations could handle them one by one, For efficiency, one would want to avoid rebasing any given revision more than once. Can you specify, in rebase, "Stop with revision A; don't process its children"? With that, the job could be done. Specify, for A, the revision before the next insertion of another blob. So you have Torvalds' revisions as follows a <- b <- c <- d <- e <- f <- g and suppose blobs were inserted in b and f. So you make x which replaces b but doesn't insert the blob. Then you rebase c...e onto x (giving c' ... e'). Then you edit f to make y, whose parent is e' and which doesn't insert the f blob. Then you rebase g onto y to make g'. This could handle any number of blobs, sequentially. And if you have a script to remove each blob, a master script could run automatically to convert the repository, and it would only have to process each revision once. What's more, any new revisions from Torvalds' repository can be converted very fast (assuming they don't add new blobs) by rebasing them. In addition, revisions in our repository can be converted the same way. Just remember the last pair of revisions where a blob was deleted. Suppose it is m <> z. You can take our revisions, based on z, and rebase them into m in a copy of Torvalds' repository. Then you can upload those to his real repository. Is the whole problem solved? Will we get addicted to rebase? -- Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org
[GNU-linux-libre] Re: PCMCIA .cis files
there aren't any freedom problems with the binaries, the only issue now, if any, is GPL compliance: sh/could we ship only the binaries if we know they were built from textual sources that we don't ship? We want to use these files under the GPL, not the other alternative, so we need to comply with it. If you'd be happy doing all future editing of these files on the binaries then you can sincerely say these binaries are the source code. Otherwise, the text files are the source code, so they should be included. What is Torvalds doing? How does he justify not including the textual files in his Linux sources? Does he say he is using them under the other license? Does he say he has an arrangement to refer to the other site for the textual files? Does he say that the binary files are sources? If he has not addressed the issue, maybe you can poke him so he has to do so, and then whatever solution he uses might be good for us too. -- Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 4, 2011, Richard Stallman wrote: > Yeah, I believe so. I'm not sure the current pcmcia driver doesn't > really offer the interface the userland program that makes the > conversion relies on, or if it only fails to do so on a machine that > doesn't have a pcmcia interface, but the important point is that it's > definitely not functional on any random machine. > In that case, either we need a separate binary-to-text converter for > these files http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg03468.html has a patch by Dmitry Eremin-Solenikov with a stand-alone version of the dump_cis program, that converts .cis binary to text. The separate patch that introduces mkcis, to convert from text to binary, wasn't archived there, but we already have a stand-alone program that does that job, so there aren't any freedom problems with the binaries, the only issue now, if any, is GPL compliance: sh/could we ship only the binaries if we know they were built from textual sources that we don't ship? FWIW, 2.6.37-libre is already out, without the .cis files, but with requests for them. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 4, 2011, Richard Stallman wrote: >> My proposal does that automatically. If filter-branch doesn't do that, >> I think that implies filter-branch is not the same thing. > Compatibility as in git pull/merge recognizing automatically the > saved-away commit equivalences? > I am not sure what that means. It means git pull (the preferred way to bring in changes from a remote repository) or merge (the preferred way to bring in changes from a local branch, which may be a clone of a remote branch) ought to be able to use these equivalences, instead of regarding the commits as unrelated. It also means there should be another variant of git pull that, sort of like rebase, reapplies commits from one branch to another, but that, unlike git pull --rebase, reapplies changes from upstream on top of local, updating the commit mapping while at that. > The correspondence table would be saved permanently (unless you delete > it), so the proper command could automatically move any change from > one repository to the other. The bit that is missing is the integration above. We can do without the second part for the time being, although it's somewhat inconvenient. But without the first part, using our repository would be far more cumbersome than using upstream. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 4, 2011, Richard Stallman wrote: >> Where does it store the correspondence table? > In git refs/original, unless overridden. > I don't understand the answer. It means literally nothing to me. You can think of it as a tag, named after the original commit, pointing at the rewritten commit. > branch1: c1 <- c2 <- c3 <- c4 > branch2: c1 <- c2 <- da > rebasing branch1 onto branch2 would yield: > branch2: c1 <- c2 <- c3 <- c4 <- da' > Proper English usage would be to call it "rebasing branch2 onto branch1". > If you confirm for me that git users customarily use the incorrect > usage, I will accept the fact that they do. But I want to get > confirmation of this. No, sorry, my mistake. Here's a formal description of how git rebase behaves: # git rebase [--onto newbase] upstream [branch] * check out branch (if omitted, use the currently checked-out branch) * collect all commits that are in branch but not upstream * reset branch to point to the head of newbase ?: upstream * re-apply the commits, skipping already-applied patches > In order for me to understand the semantics, could you tell me > how the text of da' relates to the text of c4? Is it the same diff > as the diff between da and c2? In other words, is it true that > da' = c4 + (da - c2)? Yup. > Anyway, the operation I proposed is different. Yep. > Assume we have this: > branch1: c1 <- c2 <- c3 <- c4 > branch2: c1 <- c2 > branch3: whatever <- x > transform branch1, with c2 -> x in the correspondence table, > would not alter branch1, but make a new branch (call it branch1'): > branch1': whatever <- x <- c3' <- c4' What you propose is implemented by the following commands: git branch -f branch1\' branch2 # branch1' is now same as branch2 git rebase --onto branch3 branch1 branch1\' # now branch1' is branch3 plus changes in branch2..branch1 > Is this what filter-branch does? git filter-branch is, in a way, a smarter git rebase, that can be told to modify or discard certain commits instead of just reapplying them, and to take note of the mapping from old to new commits. It doesn't actually change any branches. It takes a list of commits and creates remapped commits. Branches or tags can be reset to point to them afterwards. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 4, 2011, Richard Stallman wrote:
> That the kernel would include a session, build or release id as part of
> the hashed string, and it would provide userland with that string so
> that it would be included in the computation that searches for the
> firmware.
> How could this be useful? I just don't get it at all.
Varying the string would make it harder for people to publish “cheat
sheets” that would render the mangling obsolete, while still enabling
firmware to be found if it is installed.
Say, kernel driver used to request_firmware("foobar/blobname.fw"...)
We compute the hash of "`uname -r`/foobar/blobname.fw", and ask the
userland hotplug script for %x of that hash number.
Userland hotplug script runs e.g.
find /lib/firmware ! -type d -print |
sed "s,^/lib/firmware/,," |
{
requested=`cat /sys/...`
pfx=`uname -r`/ # could be /sys/.../hashprefix instead
found=
while read file; do
if test `echo -n $pfx$file | md5sum` = "$requested -"; then
found=$f
break
fi
done
if test -n "$found"; then
cat /lib/firmware/$found > /sys/...
else
...
fi
}
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
