Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Moreover, while I think a majority of the developers are surely > honorable, this is not true of everyone. Now that this is the *third* > time we are being asked to vote on essentially the same question, I > suspect that many of the proponents of the measure are simply > unwilling to let it drop, and will continue to pester the rest of the > project forever. This is not honorable behavior. Well, maybe the people who mislabeled the "everything is software" vote as an "editorial change" and deceived many other developers should have tought about this. -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Xavier Roche <[EMAIL PROTECTED]> wrote: > I fully agree. The "Holier than Stallman" stuff is really getting > ridiculous. After the firmware madeness, now the documentation madeness. > And after that, the font madeness maybe ? (after all, fonts ARE also > software, and they shall be distributed with their original sources) The usual suspects from time to time have already been trying to start an images madness on [EMAIL PROTECTED] If you care about Debian, please contribute sane ideas to [EMAIL PROTECTED] -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Simon Richter <[EMAIL PROTECTED]> wrote: > The binutils package generates part of its documentation from header > files in order to get the structures and constants right. The headers > are GPLed, the compiled documentation is under the GFDL. For this > relicensing to happen, one must be the copyright holder, or have an > appropriate license, which after a quick glance does not seem to be > there. Thus, only the FSF may build the binutils package. I'd be very > surprised if that were to meet your definition of free software. Did you ask FSF what they think about this situation? -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Josselin Mouette <[EMAIL PROTECTED]> wrote: > This was necessary only because the release manager believed the changes > to be non-editorial. I cannot even understand an interpretation of the > old wording that can lead us to accept non-free documentation into main. This may be annoying for you, but it's a fact that there is an interpretation of the old wording which has been used for years to accept non-free documentation into main. -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Has anyone come forward and said "I was deceived by GR 2004-03"? I Yes, multiple people did. HTH. -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Or maybe this is only something that has been invented a posteriori when A search in the debian-devel@ archive of the past years would be enough to expose this as a lie, but maybe you were not a developer at the time and so I suppose you could be partially excused. -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > >> Has anyone come forward and said "I was deceived by GR 2004-03"? I > > Yes, multiple people did. HTH. > Who? I can't recall any. Can you provide pointers? Sure, look at the flame which followed aj's message. > What did they say in response to questions like "did you read the > changes?" I do not remember. I do not think it's relevant either. -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > This may be annoying for you, but it's a fact that there is an > > interpretation of the old wording which has been used for years to > > accept non-free documentation into main. > How is this relevant? It shows that there was a widely accepted meaning of what "software" is in the context of the DFSG, so the change was not "editorial". -- ciao, Marco signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Feb 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Surely it does. People who say "I was deceived; and I didn't bother > to take elementary steps to avoid deception" have chosen to be > deceived. Well, at least now you agree that the GR title was deceiptful. > Were you "deceived" by the 2003 amendment? No, because the second time I received the ballot I had time to waste and spent it reading the proposed changes. But just by reading the subject I would have believed too that these were trivial changes, just like in the precedent GR. -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >Why is freedom of software only important for the central > processing unit, but immaterial for other processing usints? Who said it's not important? I believe it is, just that it's not a battle which should be pursued by Debian by not distributing sourceless firmwares. It is clear that by banning firmwares from Debian we harm our users (easily verifiable) much more than we help the cause of free software (it's hard to prove that it would be of any help, and the burden of proof lies on who supports it). >And, given the trend of multiple processing usints, and not > all of them being symmetric (the cell, for example, the central > processing unit serves as little more than a traffic cop), with > processing increadsingly off loaded to the graphics processing unit, > physics processing units, encryption processors, biometrics > processors, peripheral processing units, we should be careful about > how we define processing units for which software freedom in > unimportant/ OK. Let's get back to this when it will be a problem. >Si, am I silly and alone in thinking that firmware is binary > computer programs? Let us ask google to define: firmware: You are silly in pretending that the DFSG and the widely shared consensus among developers always intended considering them non-free and inappropriate for main. >So, unless otherwise stated, the foundation document terms > refer to commonly understood meanings of words; looking to > dictionaries, encyclopedias, and common references. I'd say that they refer to the meaning commonly accepted by developers. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >A completely different issue is whether we take upstream's word for >GPL compability, or if we claim that something is not redistributable >because it contains a firmware blob *and* is licensed under the GPL as >a whole. There is hardly a consensus on this, so I expect that the ftpmasters will decide what to do (or decide nothing and continue as usual and as other distributions who retain real laywers do). -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data,?including firmware
[EMAIL PROTECTED] wrote: >On Wed, Aug 23, 2006, Matthew Garrett wrote: >> > This is a good proposition, as it does not allow firmwares already in >> > non-free (eg madwifi) to go into main. >> Madwifi contains non-free code that runs inside the kernel on the host >> processor. Whatever the project's opinion on firmware, madwifi is >> clearly non-free. > Yes, that's why we (including Aurélien) want to keep it in non-free. Like everybody else AFAIK, so it's not clear why this unrelated package is being used as an example. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data,?including firmware
[EMAIL PROTECTED] wrote: >I heavily disagree to this change. It makes the text unpredictable. I support your disagreement for the reasons you explained and also because separating the firmwares from the kernel would not solve the problem of making them available to Debian users. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Aug 23, Sven Luther <[EMAIL PROTECTED]> wrote: > Indeed, but would it not make more sense, to aknowledge that the firmware is > non-free, and then argue that we should include it nonetheless, instead of > making obviously false claims like "firmware are not programs" ? "Firmwares are not programs *for the purpose of DFSG compliance*" is a statement which may or may not be true, but will not obviously false (or not) until we will known the outcome of this GR. I do not mind either way anyway, my purpose it to make Debian an useful and free (as-in-freedom) Linux distribution, not arguing about the general definition of the word "firmware". -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >Ever since the sarge release, an ongoing question has been: what do the DFSG >require for works that are not "programs" as previously understood in >Debian? Thank you for your proposal. While I was thinking about a different proposal (both wider and narrower in scope), I like this and fully support it. I appreciate your attempt in verifying if the majority of developers still believes in the DFSG as it used to be intended until the DFSG-revisionists colonized [EMAIL PROTECTED] It should be noted that this will still not allow distribution of firmwares used by some popular devices which are freely distributable but not modifiable. Nor will this solve the problem of the Firefox logo, so looks like I will need to propose a new GR myself. But I will not be able to work on it before the winter. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
[EMAIL PROTECTED] wrote: >> This is FUD. Nothing in this proposal says that we will ignore licenses >> when distributing firmware or any other works. >Maybe, but you take the first step toward this, so when will you stop ? Also, http://www.nizkor.org/features/fallacies/slippery-slope.html HTH. >there are currently stuff in non-free, or even which was rejected in non-free, >which could arguably be using the same kind of permissibility as the firmware >code, like the miboot apple copyrighted boot sector, which is only 256 bytes The only way you can argue this is by not understanding the proposed GR: a boot sector is not firmware since it's loaded from a disk to run on the same CPU which will later run the OS. (Not that I would have any objections to shipping it in main, since this would help and not hinder the cause of free software.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >> I would prefer if the term "firmware" would be defined or at least >> explained in the GR. Something like: > >> firmware (data which is sent to attached devices for processing and >> which is not, directly or indirectly, executed on the host CPU) > >I don't object to this. Is there agreement among the GR sponsors that this >is the definition of firmware that should be used? I agree with the general idea, but I am not sure if this definition covers CPU microcode updates like the ones uploaded by the microcode.ctl package. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >If there is a vote, I will vote AGAINST granting a special >exception to firmware, or considering firmware as data. Manoj's >arguments are compelling IMHO. In addition, the proposed GR makes no >mention of blobs, which are binary-only pieces of software that execute >*in kernel space*, *on the central processing unit*. Linux contains >a few blobs. I would therefore: No, "blobs" are opaque streams of bytes which are uploaded to some device and never executed by the system CPU. You are talking about non-free object files to be linked with the rest of the kernel code, and the Linux kernel does not contain any. Please get a clue. >The proposed GR mentions that some firmware requires non-free tools in >order to create it from source code. Just because no free tools exist >*now* does not imply that no free tools will *ever* exist; and just >because some vendor tries to lock people in with non-free firmware does >not mean we should accept to be locked in. We *are* "locked in" no matter if we distribute sourceless firmwares or not since everybody will always end up using some. > I think we should learn from >OpenBSD on this front. I agree. Indeed, the OpenBSD project not only distributes sourceless firmwares, but also sourceless firmwares with a license which forbids modifications and reverse engineering. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
[EMAIL PROTECTED] wrote: >My understanding is that upstream has not been entirely receptive >to patches that remove non-free firmware from it. Maybe that's >because they don't have an established firmware-nonfree project >(like Debian does) into which to move that firmware? No, it's because they really do not believe this to be a problem, like everybody else but a few people polluting debian-legal. >A consensus of DD that "firmware is not software" carries no >legal weight. 44 of the sourceless-firmware-contaminated >files in the Linux kernel are claimed to be covered by the GPL. >There is no legal way for Debian to redistribute those files, >since we can't provide that source to people who attempt to >exercise their GPL-mandated rights. Other distributions disagree, and they have actual lawyers who are payed to care about such things. >http://lists.debian.org/debian-vote/2006/08/msg00166.html >> > I think we should learn from OpenBSD on this front. >> I agree. Indeed, the OpenBSD project not only distributes >> sourceless firmwares, but also sourceless firmwares with a >> license which forbids modifications and reverse engineering. >Care to back up that statement? It runs 180 degrees counter >to my understanding of OpenBSD. Feel free to dig in the OpenBSD mailing lists archives if you care. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
[EMAIL PROTECTED] wrote: >Searching OpenBSD mailing list archives for mails matching both keywords >firmware and source found nothing. Are you sure it's in there? Well, probably there is a reason if you have not found anything by looking for "source"... With a two minutes google search of "de Raadt firmware" I have found: http://www.theage.com.au/articles/2004/10/29/1098992287663.html De Raadt said that when a request was made to a vendor to 'open' their firmware, "it just means we want clear distribution/redistribution rights. We don't need the 'source code' to their firmware. There are no intellectual property concerns." (I do not understand why he received an award from FSF for this, BTW.) And http://kerneltrap.org/node/6550: Jeremy Andrews: What is it about binary firmware that you're willing to ship it, versus binary blobs? How can you trust the firmware binary to do what it should do? And what if the firmware has a bug? Theo de Raadt: [...] But in the end, if we wish to support any such devices, we must be practical. We must accept the risk that there is a flaw in the firmware. [...] Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical ?limitations
[EMAIL PROTECTED] wrote: >Rationale: most of us want to release etch ASAP, and most of us want to >remove the firmwares from the kernel ASAP. This is a way that shouldn't This is false: most of us do not mind at all distributing sourceless (or even not modifiable) firmwares in the kernel packages. >stop the ongoing work on both of these issues. The wording makes it >clear that as soon as the kernel and d-i are able to use split out >firmwares, the migration will have to be done. This way we won't >discourage the work from Nathanael Nerode and other people who worked >hard so far to remove the non-free blobs, and we won't hold etch >development because of that issue. We are not discouraging them, the upstream kernel maintainers did when they clearly showed that they could not care less about their patches. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical ?limitations
[EMAIL PROTECTED] wrote: >> >Rationale: most of us want to release etch ASAP, and most of us want to >> >remove the firmwares from the kernel ASAP. This is a way that shouldn't >> This is false: most of us do not mind at all distributing sourceless >> (or even not modifiable) firmwares in the kernel packages. >I don't think you can legitimately claim to speak for *most* developers on >this issue. And I have no intention of doing it, I merely noted what has been and still is the prevalent opinion on the issue that can be observed on our mailing lists and in its practical effects: it's obvious that there is only a small number of people, some of them not even developers, who "want to remove the firmwares from the kernel ASAP". -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >This discussion has indeed been going on for a while. The most important >arguments seem to be that one side is saying "It must be Free!" while >the other claims "There is nothing useful in making it Free". Wrong. The real other argument is "there is nothing useful in making it non-free". Quite a different position. >I think the answer to that discussion can only be found in trying to >analyse and answer these arguments. So let's try that. Maybe you should try again after understanding what we are talking about. >Then again, maybe I'm just crazy and don't know what I'm talking about. >That wouldn't be a first ;-) Indeed. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >No. We just keep providing the official free images. And someone else will >provide the non-free variants. Yes: Ubuntu. > This scenario would reflect exactly the >situation that already exists WRT Debian as in (free) "Debian" and Debian as in >"Debian + non-free + even-more-evil-external-non-distributable repositories". Except that ~everybody agrees that non-free software is not part of Debian while most people do not agree that some firmwares should not be part of Debian. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One non-DD's thoughts on dfsg-freeness and firmware
[EMAIL PROTECTED] wrote: >I realize that hardware includes non-free firmware in rom, but I think >that observation misses the point. Firmware in rom isn't being^M >distributed by the debian project. The first problem I see with debian The good old "what I don't see cannot hurt me" argument. >and non-free firmware is the question of provenance; where did it come >from? If it is extracted from a windows driver then legally it is a >potential landmine as it there is no permission even to distribute. This applies to *anything* we distribute. If you have serious reasons to believe that we are distributing something illegally then you are supposed to warn the maintainers responsible for it and/or the ftpmasters. If you don't, then please stop spreading FUD. >The second problem I see is that if it is part of main, the debian >project is claiming it is dfsg-free, which is most often not the case. Free is what we define to be free. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >I think it is ludicrous to pretend that firmware is not a program. I am not sure, it's not very funny to me. But it worked pretty well until you and a few other people started pretending we have been confused for all these years and actually meant something else. >Suppose we had in our possession the source code and an assembler for >it. Surely then it would be obviously a program. So what? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > Debian must decide whether it wants to ship BLOBs with licensing which > technically does not permit redistribution. At least 53 blobs have this > problem. Many of them are licensed under the GPL, but without source code > provided. Since the GPL only grants permission to distribute if you > provide source code, the GPL grants no permission to distribute in these > cases. Many people disagree with this interpretation. > Oddly enough nobody has proposed a GR addressing this, and Debian continues > to ship 47 improperly licensed files in linux-2.6. If I were SCO, I'd buy > up the copyrights to them from the original companies, and then I'd have a > real case for a lawsuit. Not really. What effects do you think a lawsuit about this would have? -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >> So I think the real question is "How does us refusing to ship non-free >> firmware help free software?". >WE'RE NOT CONSIDERING DOING THAT. I hate to shout, but *have* you heard of >non-free? It was mentioned in the post you're replying to! I did. And it's not part of Debian. I am interested in working on Debian, not in Debian + other repositories. (Especially if their purpose is distribution of random proprietary programs.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
[EMAIL PROTECTED] wrote: >Not for some reason, for some very obvious reasons. They're not adequate >as an immediate solution to this problem because separating the firmware >from the packages that currently contain it is hard and needs development *And* will need work from the kernel team for the foreseeable future since there is no evidence that Linus and the other upstream maintainers (or other distributions) now have any interest in following such a path. >I really don't think that, if all that support and infrastructure were in >place and we had a straightforward way of pulling out the firmware and >help from upstream in doing so going forward, anyone would object that >strongly to using contrib and non-free. I expect there would be some Yes, I would strongly object. I am very annoyed at people who consider some GPL'ed drivers to be contrib material because the hardware they support stores its proprietary firmware on the system hard disk instead of on a flash eeprom chip like some other hardware. As a contributor to some of these projects I consider this demeaning. The only compromise I can see is a new archive section different from main, contrib or non-free which will be considered part of Debian and distributed on our CD and netboot images. Then the people who use proprietary firmwares in their computers but cannot stand the idea of having some on their CDs will be able to easily create their own media. >It's a contentious issue because it's a pragmatism tradeoff against ideals >whose importance are not universally agreed on. Those are just inherently No, it's a contentious issue because some people are trying hard to change the values of Debian replacing what was a compromise widely accepted by everybody in Debian and most people outside Debian with mindlessly following their idea of the DFSG. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Amendment - allow hardware support from non-free into the debian system
[EMAIL PROTECTED] wrote: >3. as a special exception to help users who have vital hardware >without free software drivers yet, the Debian system and official CD >images may include hardware-support packages from the admin section of >the non-free archive area which conform to all Debian Free Software >Guidelines except guideline 2 (Source Code), or an archive section/area >with equivalent requirements. This may include proprietary kernel drivers and will exclude important firmwares which are not legally modifiable. Both too much and too little at the same time. I would otherwise support a similar amendment, but I in this form I consider it harmful to our cause. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
With this message I formally second aj's proposed resolution from <[EMAIL PROTECTED]>. I deeply appreciate this, I believe it is the right step to bring back Debian to its origins and hopefully will help reducing the tensions in the project caused by the SC change. Still, I want to ask you to reconsider point f, which proposes an in-person debate to be held at the next debconf. This is unfair, because it excludes from the debate two classes of developers: people who cannot partecipate to the debconf[1] and people who are not proficient enough in spoken english to be able to fully express themselves in an in-person debate. [1] not just because of money issues, but also because for many people it is not easy to take a week off work. -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal - Amendment - allow hardware support from non-free into the debian system
[EMAIL PROTECTED] wrote: >> This may include proprietary kernel drivers and will exclude important >> firmwares which are not legally modifiable. Both too much and too little >> at the same time. >How would you exclude proprietary kernel drivers while allowing important >firmwares which are not legally modifiable? Firmwares do not run on the same CPU controlled by the OS, etc. The difference has already been discussed on this mailing list. >Do you think that Steve Langasek's original proposal would exclude/allow >those in that way? It obviously did not include proprietary drivers. It did not include more restrictively licensed firmwares either, but it was not supposed to. >> I would otherwise support a similar amendment, but I >> in this form I consider it harmful to our cause. >Prove it. I should prove that Debian distributing illegal proprietary kernel drivers would really be a bad idea? I have better things to do with my time. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
On Sep 06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > No, it's a contentious issue because some people are trying hard to > > change the values of Debian replacing what was a compromise widely > > accepted by everybody in Debian and most people outside Debian with > > mindlessly following their idea of the DFSG. > I'm sorry, when did Debian accept that compromise? When the DFSG was created. -- ciao, Marco signature.asc Description: Digital signature
Re: Firmware & Social Contract: GR proposal
[EMAIL PROTECTED] wrote: >> No. Ceasing to make commitments we can't keep doesn't mean we should >> stop meeting the commitments we can. Which is why the bullet points you >> didn't quote were in the proposal. >What do you mean that we "can't keep" the commitment to make the >kernel free software? > >We just stop shipping the relevant drivers. As usual you forget that we also have that other commitment to our users, and that we used to pride ourselves in providing the best free OS. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Amendment - allow hardware support from non-free into the debian system
[EMAIL PROTECTED] wrote: >> >> I would otherwise support a similar amendment, but I >> >> in this form I consider it harmful to our cause. >> [EMAIL PROTECTED] wrote: >> >Prove it. >> I should prove that Debian distributing illegal proprietary kernel >> drivers would really be a bad idea? >No, prove that you would otherwise support a similar amendment. I am not sure how this can be done. Let's try this way: "I promise that I will second a GR proposing to create a new archive section for restrictively-licensed firmware files (and not proprietary drivers or random proprietary programs) to be distributed on Debian install media". -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
[EMAIL PROTECTED] wrote: >That doesnt make a good reputation, setting something central like the >Social Contract and then randomly changing it back because its ohhh, so >hard to follow that change. We followed the SC pretty well until it was changed. Admitting that the change was not appropriate would be an act of honesty. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
On Sep 06, Sven Luther <[EMAIL PROTECTED]> wrote: > > >That doesnt make a good reputation, setting something central like the > > >Social Contract and then randomly changing it back because its ohhh, so > > >hard to follow that change. > > We followed the SC pretty well until it was changed. Admitting that > > the change was not appropriate would be an act of honesty. > And voted a first time with 3:1 supermajority to change it, followed by a 3:1 > vote to confirm those changes. This still does not make it a good idea. -- ciao, Marco signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
On Sep 06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > >> > No, it's a contentious issue because some people are trying hard to > >> > change the values of Debian replacing what was a compromise widely > >> > accepted by everybody in Debian and most people outside Debian with > >> > mindlessly following their idea of the DFSG. > >> I'm sorry, when did Debian accept that compromise? > > When the DFSG was created. > Oh, come on. The DFSG says that firmware counts as free? Where? The widely accepted custom was to interpret the DFSG this way, yes. This is what matters. -- ciao, Marco signature.asc Description: Digital signature
Re: Firmware & Social Contract: GR proposal
On Sep 06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > There is an absolute ranking in Debian, that *first* we must provide > 100% free software, and *second* we do whatever we can to help our > users consistent with the first. This is just your opinion, not a fact. -- ciao, Marco signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
On Sep 07, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > The widely accepted custom was to interpret the DFSG this way, yes. > > This is what matters. > What is your evidence of this? My experience of 9 years in Debian, which can be verified by browsing the list archives. -- ciao, Marco signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
[EMAIL PROTECTED] wrote: >I have not been the only one to be upset about the firmware situation >every time it has been brought up, as can be verified by browsing the >list archives. I can see that the controversy is old, but certainly >not that your interpretation was "widely accepted." Wrong. The controversy is not old, it is at best a few years old. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's vote ...
[EMAIL PROTECTED] wrote: >I am concerned with including in Debian firmwares whose license >reduce the usefulness of Debian through obnoxious clauses >that would also affect people that do not need the firwmare >in the first place (e.g. by restricting distribution or use of packaging >embedding the firmware) or even being illegal for Debian to distribute Please explain how this would actually happen. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Withdrawn: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: >While I still believe that this proposal represents a reasonable position >for the project to take, the discussion over the past two weeks makes it >clear to me that a large enough fraction of our developership disagrees >strongly with this interpretation that it's not in the best interest of the >project to push forward with this proposal. So what? A large enough fraction of our developership disagrees strongly with the current interpretation as well. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
With this message I formally second Frans Pop's proposed resolution from <[EMAIL PROTECTED]>. -- ciao, Marco signature.asc Description: Digital signature
Re: GR idea related to ongoing licensing discussions
[EMAIL PROTECTED] wrote: >I start with those two because they're the least controversial and have >been part of license analysis for long enough that they're in various FAQs >and in the Wikipedia article on the DFSG, but neither are explicitly >stated in the existing guidelines and there's always some low-level >controversy over whether the existing terms really do imply them. No, I think there is still high controversy over these criteria, which appeal mostly the DFSG-revisionsts which a few years ago colonized debian-legal. I do not believe that they are currently being used by the ftpmasters, who are the people who actually decide what is DFSG-free or not. Are you really looking for more issues over which developers could be divided? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR idea related to ongoing licensing discussions
[EMAIL PROTECTED] wrote: >A good understanding of the effects (ie, providing answers to questions >like: how common are such clauses? if they don't happen, why complain? if >they've already happened, how have they caused problems?) seems like a >good thing to have before making decisions about them. Agreed. Thank you for the reality check. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR idea related to ongoing licensing discussions
[EMAIL PROTECTED] wrote: >Marco d'Itri claimed existance of such DFSG-revisionists in >http://lists.debian.org/debian-legal/2006/12/msg00160.html >(apologies for the "fraudster" shout in my first reply) but went all >quiet when I showed that it looks like non-money fees were DFSG >breaches before debian-legal even existed... Yes, I went all quiet because (as I already explained to you at least once) I was relocating and staring a new job (which is much more interesting than posting to Debian lists, so I rarely read them nowadays). Can't you come up with anything better than this? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR idea related to ongoing licensing discussions
[EMAIL PROTECTED] wrote: >Maybe relocating, but not on VAC AFAICS and still active on various This is not what I claimed. >> Can't you come up with anything better than this? >Why do I need to? Can you show that those DFSG-1-revisionists exist? DFSG revisionists are the people holding one or more of these beliefs, which were not usually accepted by developers when I joined the project: - the DFSG 1.1 just clarifies the meaning of the DSFG 1.0 and does not actually imposes new rules about what is acceptable in Debian - the dissident test, the desert island test, the moose test, etc are implied by the DFSG - reasoning schemes like "even if everybody used to agree that the DFSG had to be interpreted as X we now believe that it really meant Y != X" - various other minor beliefs about what the DFSG means which were not commonly accepted by developers some years ago, among them the "every restriction is a fee" (possibly for multiple values of "every") which you are defending here Analysis of the debian-legal@ archive can show that there are such people, therefore DFSG revisionists as previously defined exist. QED. HTH. (Hopefully even you will be able to understand that this description is not rigorous in the mathematical sense, so please refrain from nitpick.) >If not, stop trolling. Accusing people who oppose your views of "trolling" shows lack of dialectic skills. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR idea related to ongoing licensing discussions
[EMAIL PROTECTED] wrote: >So if it didn't hinder your participation in debian, it's probably not I am not sure if you are accusing me of being a liar or you are just being stupid. Anyway, thank you for reminding me why discussing with you is a waste of time. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please drop/replace the use of the term "diversity"
la...@debian.org wrote: >May I gently request we replace the use of the word "diversity" >throughout the "init systems and systemd" General Resolution prior to >it being subject to a plebiscite? I fully agree. Also, it is not acceptable for a small minority to frame the whole debate in the terms that they favour. -- ciao, Marco
Re: Review of proposals
lu...@debian.org wrote: >In order to save voters' time by making it possible to read proposals in >a more sensible order, I think they should be re-ordered as: I agree. >Concern about length of proposal D >== > >I am a bit concerned about the length of proposal D, and the fact that >it is both very detailed and very vague. > >For example, it raises a (probably valid) concern about >"non-init-related [declarative] systemd facilities", but: I am seriously concerned about this too, because the "it is reasonable to expect developers of non-systemd systems including non-Linux systems to implement it" clause means that in the best case ANY progress will still be dictated by the lowest common denominator of what is "reasonable" (to whom?) to implement on non-Linux systems. Also, I think that the total amount of developers for the non-Linux ports is less than 10: what is reasonable to expect from them considering the dire lack of manpower? Let's consider the most simple things to implement: is it reasonable to expect that the wider "non-systemd community" implement systemd-tmpfiles, considering that they did not do this in the last 8 years? Are the supporters of proposal D willing to commit to support including systemd-tmpfiles in policy and implementing it and other similar interfaces for (all? Is one enough? How would this work?) the alternative init systems if proposal D won? >1/ it mixes it with an argument that declarative facilities are better. >Well, maybe I can agree with that. I'm not sure it's something >the project needs to issue a statement on through a GR. Me too... >Well, given that some of the criterias are not super-clear (see above), >it's likely that policy consensus will be hard to reach. Then the TC is >left with deciding based on the project's wishes as expressed in this >GR. But assuming that proposal D wins, where is that project's wish on >non-init-related declarative systemd facilities expressed? The proosal title says that they do not want to block progress, but what is that exactly? -- ciao, Marco
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
guil...@debian.org wrote: > * The traditional-only way camp: This group outright rejects things > like systemd, and other similar technologies. Some of this group was > part of Debian in the past, but found a new home in Devuan. People I read all my emails with mutt (which I used to maintain) and the news with tin (which I still maintain). I send all my emails over UUCP. My desktop is fvwm (with parts of GNOME!) My terminals are 80x25. I maintain Fidonet-related software. My favourite programming language is Perl. I use IRC all the time and I despise Slack. I judge people who send HTML emails or top quote or have signatures longer than 4 lines. I am quite fond of my traditions but I still recognize the systemic benefits provided by only supporting systemd: I do not accept for this issue to be framed as "tradition vs. progress". -- ciao, Marco
Re: Opposite of a Platform for DPL 2020
andr...@fatal.se wrote: >I just wanted to take the opportunity to say that while I might not >have thought exactly the same as you in every detail I very much >appreciate that you've tried to actually show leadership during >your time as DPL (rather than just being a passive spokesperson for the [...] Me too, and I am sad that you will not run again. -- ciao, Marco
Re: Nuance Regarding RMS
b...@debian.org wrote: >I can personally vouch for the fact that RMS can be very difficult. He Thank you for this contribute. -- ciao, Marco
Re: Changing how we handle non-free firmware
s...@debian.org wrote: >Free installer: > > - will not work with some hardware This is a bit more complex than that. The current installer is insecure for all systems which use Intel and AMD CPUs (i.e., with very good approximation, almost all of them), because microcode updates provide mitigations for speculative attacks and other various bug fixes. > + fully supported Is the kernel team actually willing to support systems not running current microcode? > + can be redistributed freely Just like the installer containing non-free firmwares, then. >Installer including firmware: > > + supports more hardware Actually: needed to support all the most widely used hardware, i.e. x86 systems and Raspberry Pis. > - some bugs might be unfixable True, but OTOH not updating the system firmwares guarantees that some known bugs are not being fixed. > - users need to be aware of non-free licenses I believe that "need" here is a strong word. Some users will /like/ to know which non-free firmwares they need to use (I do!), but I cannot think of any reasonable scenario in which somebody /needs/ to know that. >IMO: Both installers should be on the same download page, with a brief >explanation on who should select which (like we used to have in package >descriptions), and possibly a longer page explaining this in more detail. Looks like you are volunteering to build the firmware-free media then, good to know. -- ciao, Marco
Re: Changing how we handle non-free firmware
simon.rich...@hogyros.de wrote: >If Debian provides an installer image, but does not at the same time >promise to have vetted all applicable licenses against a list of >criteria that is acceptable to the legal department, this installer >image becomes close to useless to corporate users. I *am* a corporate user and I believe that the scenario that you are describing is highly unusual. Anyway, nothing of this really matters and it is pointless to argue this point because: - corporate users need non-free firmwares like everybody else, and - nobody is arguing that installation of non-free firmwares should be somehow hidden from users -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload
deb...@kitterman.com wrote: >As I understand it, Debian was affected by the xz-utils hack, in part, because >some artifacts were inserted into an upstream tarball that were not >represented in the upstream git. Please explain how use of tag2upload is >relevant to this scenario? I'm afraid I don't follow. I think that it was assumed, and I agree, that a well-maintained Debian git source tree has the upstream branch pulled from the upstream git repository, keeping the complete history, and not created locally by importing upstream tar release archives. -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload
ans...@43-1.org wrote: >In addition it reintroduces trust in weak cryptographic hashes which >effort was spent to remove. While SHA-1 is generally deprecated, it is not "weak" in the way that it is used by git so I do not believe that this is a valid argument. -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload
s...@debian.org wrote: >Is your position here that if your upstream releases source tarballs >that intentionally differ from what's in git (notably this is true >for Autotools `make dist`), then any Good™ maintainer must generate >their own .orig.tar.* from upstream git and use those in the upload, >disregarding upstream's source tarball entirely? It is mine, and this is what I have been doing for a long time for all my packages. Another interesting consequence of always using the upstream git tree as the Debian source is that packaging snapshots then becomes trivial. Practical examples are kmod and inn2. (I even have some automation to pull, tag and merge a new upstream snapshot.) -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload [and 1 more messages]
s...@debian.org wrote: >Do we actually want or need to hoard all the collaboration history? Of course: this makes auditing much easier. -- ciao, Marco
Re: Security review of tag2upload
si...@josefsson.org wrote: >Can this be substantiated? Using SHA1CD in Git does not necessarily >mean someone cannot manually create a Git repository with a colliding >git commit somewhere in the history that gets accepted by git, and >allows someone to replace actual file contents. That may be the case, >but I haven't seen any detailed analysis answering that. This is quite a strong assertion, and it is up to you to prove it. The current consensus among cryptography experts is that SHA-1 is still resistant to preimage attacks. -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload
r...@debian.org wrote: >My understanding is that the problem with this >design from their perspective is that it requires a fat client on the >uploader's system, and whole point of tag2upload is to stop requiring a >fat client on the uploader's system. In particular, it requires all the >code to reconstruct the source package from a Git tree be installed >locally, which is basically a full dgit implementation. Does it? What if both the tag2upload client and server implemented instead some very simple serialization and canonicalization algorithm over the source package? I am thinking about hashing something like a sorted list of (file name, file hash) tuples. (Still, I would be happy to use the current implementation of tag2upload.) -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload
On Jun 15, Russ Allbery wrote: > The serialization isn't the problem, constructing the source package is. > Once you have a source package, there are lots of things you can do, but > the problem is precisely that going from a Git tree to a source package is > non-trivial and involves a whole bunch of Debian-specific code. Yes, I understand this. But I think that the goal can be much simpler: just allowing dak to verify that the content (i.e. the files) of the source package it received is the same that the uploader's PGP key has signed on their own system. Then the actual source package can be reconstructed by dgit for the archive as planned. > > I am thinking about hashing something like a sorted list of (file name, > > file hash) tuples. > I was trying to figure out while I was walking today whether that would be > all you need, and I'm not sure it is. I couldn't convince myself that you > could ignore file permissions, symlinks, hard links, and so forth. Maybe, but it should not be hard to add this kind of metadata. -- ciao, Marco signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
jo...@debian.org wrote: >We want dak (and anyone else) to be able to say "Yes, DD/DM $x has >signed off this content". That only works, if dak (and later, the >public, if they want to check too) have the signature for this in a way >they can verify it. And not just a line somewhere "Sure, $service >checked this for you, trust us, please". Yes, you have been very clear from the start that this is what you want. But I do not think that I have seen an actual explanation of /why/ you want that. -- ciao, Marco
Re: [RFC] General Resolution to deploy tag2upload
On Jun 17, Sven Mueller wrote: >1) because it is the job of FTPmaster to authenticate and authorize the >uploader (and Joerg sees that as "human uploader", which I somewhat agree >with) If this were the actual issue then the ftpmasters could just run the tag2upload server themselves (which I think would make sense). >2) because Joerg wants third parties to be able to verify the signature of >the human uploader without the need for Debian specific tools. Yes, I understand what he wants. But again, it is not obvious why we should share this desire. >There is another aspect he mentioned: he thinks the uploader needs to test >the build of the package. (I'm theory I agree, but there are situations Everybody can upload totally untested packages even without tag2upload: maybe tag2upload would make this marginally easier, but then I do not believe that this is a compelling enough argument to offset the benefits of a tag2upload-like service. -- ciao, Marco signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
ijack...@chiark.greenend.org.uk wrote: > In this message I discuss in some detail five packaging workflows. I am more familiar with the gbp patches-unapplied workflow: can you point us to some educationlly relevant example repositories using the git-debrebase workflows? (Maybe without dgit, to make things easier to understand.) [gbp] >ftpmaster's alternative design, AIUI: > >The alternative design I've been positing supposes including a >manifest of the contents of the unpacked source package. Ie, patches >applied. But why does it have to be patches-applied? Then both sides could easily (?) compute a canonical hash of the patches-unapplied git repositories, and it would still provide the same security properties. -- ciao, Marco
Re: Summary of the current state of the tag2upload discussion
mbeh...@debian.org wrote: >I think we have seen and still see with usrmerge how difficult and cumbersome >the resolution of an initially as simple presented project turned out. I >understand the answer of Scott directed in that way, at least this is a >reservation of mine. For the record, usrmerge became difficult and cumbersome because non-technical reasons prevented implementing the simple solution in dpkg. -- ciao, Marco
Re: First Draft proposal for modification of Debian Free Software Guidelines:
[EMAIL PROTECTED] wrote: >> 2. In the past, the issue of documentation, fonts, images, sound >> files, and other non-program type files was "dealt with" by treating >> them as if they weren't "software". > >This is not really true. We mostly ignored the issue, but they were >always software. We never said "oh, these aren't software". Instead, *You* did not, other people did and still do. >> 3. Since the issue of the "freeness" of documentation, fonts, images, >> sound files, and other non-program type files is now clearly a >> "software" issue, it makes sense to clear up the situation by adapting >> the DSFG to the needs of these types of software, if it is of benefit >> to the cause of Free Software. > >Yes, but we must do so with an end to the cause of Free Software. Refusing to distribute binary firmwares does not help free software. You may choose between getting the firmware on a EEPROM chip or having your driver load it, but at the end of the day you will still use free software. So, if removing binary firmwares makes using free software harder for our user it actually harms the cause. -- ciao, Marco
Re: Proposal - Deferment of Changes from GR 2004-003
[EMAIL PROTECTED] wrote: >i propose an amendment that deletes everything but clause 1 of this proposal, >so that the entire proposal now reads: > > that the amendments to the Social Contract contained within the > General Resolution "Editorial Amendments To The Social Contract" > (2004 vote 003) be immediately rescinded. Seconded. (Please post this in a new thread as well, I originally missed your message.) -- ciao, Marco
Re: Social Contract GR's Affect on sarge
On May 06, "Thomas Bushnell, BSG" <[EMAIL PROTECTED]> wrote: > But no, I misspoke. I'm happy to grant the stuff in the ROM is > software, in one sense, but not in another--it can't be changed (it > isn't *soft*). For this reason, the term "firmware" has become > customary. What about flash EPROM (which you can change)? -- ciao, | Marco | [6177 diEmj1dnlVlTY]
Re: Results for General Resolution: Lenny and resolving DFSG ?violations
In linux.debian.vote Thomas Bushnell BSG wrote: >I would prefer this. But I am afraid of it, and so I would vote against >it. I am afraid that there are folks in the project who really don't >care if Debian is 100% free--even as a goal. I think that Ted Tso is >even one of them. Count me in as well then, since I completely share his opinion. >I wish we could have in the world of GNU/Linux one, just one, >please--just one--distribution which really took free software as of >cardinal importance. Debian has promised to be that, while living up to What about you spend your time hacking on gnewsense then, and let us create on an OS which will also be useful? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG ?violations
In linux.debian.vote Thomas Bushnell BSG wrote: >On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote: >> I'm not ashamed at all; I joined before the 1.1 revision to the Debian >> Social Contract, which I objected to them, and I still object to now. >> If there was a GR which chainged the Debian Social contract which >> relaxed the first clause to only include __software__ running on the >> Host CPU, I would enthusiastically vote for such a measure. Me too. >Can you please define "host CPU" for us? What about the same one which is executing the OS kernel? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009: Final call for nominations.
l...@liw.fi wrote: >While I agree with Ben, perhaps we could retire this, the 12765th >iteration of this discussion, in favor of having a discussion about >platforms and some Q&A with the candidates? Maybe this is a good time to ask the candidates what is their position wrt this PC bullshit. So candidates, what do you think about this? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal - preserve freedom of choice of init systems
In linux.debian.project Ian Jackson wrote: >For me the answer is: We should preserve diversity and freedom of >choice, at the cost of functionality. Making that statement now, >very clearly, will make that doomsday scenario less likely. We can easily have a GR on this as well: "would you rather keep Gnome and KDE or MyToyBSD in Debian?". I look forward to it. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lf4h0i$icb$1...@posted-at.bofh.it
Re: Proposal - preserve freedom of choice of init systems
ijack...@chiark.greenend.org.uk wrote: >Since in practice there is only one hegemonic init system, this is >sufficient to ensure our commitment to diversity. Is this pluralis maiestatis? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lf73mg$n5h$1...@posted-at.bofh.it
Re: Re-Proposal - preserve freedom of choice of init systems
aigar...@debian.org wrote: >To be frank, in cases like logind I would expect the logind binary >package to be split out and its source patched in such a way to allow >it to work without systemd running (however badly) and moving the main >systemd package from Dependencies to Recommended. It is quite clear that the real world does not and will not meet your expectations, because logind is not released this way and is not packaged this way. Now what? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1qmm3$l72$1...@posted-at.bofh.it
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Seconded. On Oct 17, Lucas Nussbaum wrote: >It is now clear that we will have a vote on this issue. I think that we >should use this opportunity to clarify the Project's position, and that's >not something that would be achieved if "Further Discussion" were to >win. > >I am therefore bringing forward an alternative proposal, deeply inspired >from the "Advice: sysvinit compatibility in jessie and multiple init >support" option of the TC resolution on init system coupling[1], which >was originally written by Russ Allbery[2] and was then amended by many >participants to the discussion in February 2014. > >[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html >[2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html > >- begin proposal ->8 >Debian has decided (via the technical committee) to change its default >init system for the next release. The technical committee decided not to >decide about the question of "coupling" i.e. whether other packages in >Debian may depend on a particular init system. However, the technical >committee stated in #746715 that "[it] expects maintainers to continue to >support the multiple available init systems in Debian. That includes >merging reasonable contributions, and not reverting existing support >without a compelling reason." > >The Debian Project states that: > > Software should support as many architectures as reasonably possible, > and it should normally support the default init system on all > architectures for which it is built. There are some exceptional cases > where lack of support for the default init system may be appropriate, > such as alternative init system implementations, special-use packages > such as managers for non-default init systems, and cooperating > groups of packages intended for use with non-default init systems. > However, package maintainers should be aware that a requirement for a > non-default init system will mean the software will be unusable for > most Debian users and should normally be avoided. > > Package maintainers are strongly encouraged to merge any contributions > for support of any init system, and to add that support themselves if > they're willing and capable of doing so. In particular, package > maintainers should put a high priority on merging changes to support > any init system which is the default on one of Debian's non-Linux > ports. > > For the jessie release, all software that currently supports being run > under sysvinit should continue to support sysvinit unless there is no > technically feasible way to do so. Reasonable changes to preserve > or improve sysvinit support should be accepted through the jessie > release. There may be some loss of functionality under sysvinit if > that loss is considered acceptable by the package maintainer and > the package is still basically functional, but Debian's standard > requirement to support smooth upgrades from wheezy to jessie still > applies, even when the system is booted with sysvinit. > >The Debian Project makes no statement at this time on sysvinit support >beyond the jessie release. > > >This resolution is a Position Statement about Issues of the Day >(Constitution 4.1.5), triggering the General Resolution override clause >in the TC's resolution of the 11th of February. > >The TC's decision on the default init system for Linux in jessie stands >undisturbed. > >However, the TC resolution is altered to add the additional text above. >-- end proposal -->8 > >Lucas -- ciao, Marco signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
f...@zz.de wrote: >for 30 years so why are some people pushing _so hard_ to replace it NOW and by >something >as controversal as the systemd stuff. A vocal minority and a lot of trolls do not make something controversial. Considering how widely it has been adopted by other distributions I would say that for such a big change it is not controversial at all. >We already got to the "point of no return" with systemd - and THIS is something >i guess is not something our users asked for, and something the TC did not >foresee. "If I'd asked people what they wanted, they would have asked for a better horse". -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1qoso$ppa$1...@posted-at.bofh.it
Re: Re-Proposal - preserve freedom of choice of init systems
On Oct 17, Florian Lohoff wrote: > > A vocal minority and a lot of trolls do not make something > > controversial. > I havent found the mentioned minority you speak about? Probably because you appear to be in the middle of it... > > Considering how widely it has been adopted by other distributions I > > would say that for such a big change it is not controversial at all. > Because of pressure of other upstreams going forward everyone adopted it > and this makes it non controversial - i dont get it?!? If you postulate some conspiracy to make everybody use systemd then I do not think that there is much more that we can argue about. But even then, if this alleged pressure has been strong enough to make every non-kooky distribution adopt systemd then it should be obvious that resisting it would be futile for us as well. -- ciao, Marco signature.asc Description: Digital signature
Re: Tentative summary of the amendments
svante.sign...@gmail.com wrote: >This is incredible, 90+ postings are from the pro systemd people. Are >you afraid of something? Where do the other side of view speak up. Seems Indeed, it looks like that systemd users are seriously underrepresented in these threads: https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2h58b$191$1...@posted-at.bofh.it
Re: Tentative summary of the amendments
On Oct 26, Flavius Bindea wrote: > if systemd is goinging to be the default I'll switch to another distrib. systemd is already the default and it will still be the default no matter the outcome of this GR, which is about something else. > maybe to a fork. Cool. Debian encourages forks. -- ciao, Marco signature.asc Description: Digital signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
ijack...@chiark.greenend.org.uk wrote: >I don't want to be having this conversation again in a year's time, And still, I am ready to bet that we will... >with those upstreams and their like-minded Debian contributors saying >things like `it is too late now; the world has moved on'. It is *already* too late: it is a fact that the rest of the relevant world has moved on and has adopted systemd. >I am personally not a great fan of sysvinit. This argument is not >really about service startup, though. It's about > systemd's graphical console management, Kernel developers have been explaining for years that we need a user space console to properly support things that are not well supported now, and I do not see anybody else writing one... > its replacements for syslog, You are not required to replace your syslog daemon, and indeed the Debian systemd package does not replace it. > cron, You are not required to replace your cron daemon, and indeed the Debian systemd package does not replace it. > ntpd, You are not required to replace your NTP daemon, and indeed the Debian systemd package does not replace it. Also, systemd-timesyncd is a simple NTP client and cannot replace ntpd anyway except for a trivial (but common) use case. > acpid, Systemd does not replace acpid. Maybe you should try to better understand how systemd actually works before deciding that you do not like it. :-) -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2quub$s94$1...@posted-at.bofh.it
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
ijack...@chiark.greenend.org.uk wrote: >If my GR fails I expect a series of bitter rearguard battles over >individual systemd dependencies. This looks like a great way to encourage people to make systemd mandatory just to be done with this once and for all... :-) >That's not the problem. The problem is the possibility of packages >wich requires systemd's syslog replacement, its cron replacement, or >its ntpd replacement. It is not clear why a program would want to depend on any of these components, so you are scared about something that is at best hypotetical. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2s85t$rji$1...@posted-at.bofh.it
Re: Can you all please stop?
r...@debian.org wrote: >Also, adopting systemd has been far from "easy." Just ask the systemd >maintenance team in Debian, who I am sure are seriously questioning why >they ever wanted to be the default init system right about now given all >the work it entails! Not really, I want that because it is the best option for Debian. :-) It's not like there were no bitter complaints from a few people when I introduced udev to Debian, but I knew that I was right and time confirmed this. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m310ha$1bt$1...@posted-at.bofh.it
Re: Re-Proposal - preserve freedom of choice of init systems
goli...@riseup.net wrote: >I came to Linux for FREEDOM and for configurability. Finally, I could http://islinuxaboutchoice.com/ Thank you for your contribute. Next! -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3e287$oq9$1...@posted-at.bofh.it
Re: userspace virtual terminals
j.deboynepollard-newsgro...@ntlworld.com wrote: >... which is the result if one has one's eyes tightly shut. User space >replacements for Linux and BSD kernel virtual terminals have already >existed, and been written, for years. There's a whole non-Anglophone I am not an expert of this issue, but I think it is fair to assume that if they have not replaced yet the current kernel console, notwithstanding the frequent requests for a replacement by kernel developers, then they probably are not the right tool for this and we still need one. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3iiib$mqa$1...@posted-at.bofh.it
Re: Social Contract GR's Affect on sarge
On May 06, "Thomas Bushnell, BSG" <[EMAIL PROTECTED]> wrote: > But no, I misspoke. I'm happy to grant the stuff in the ROM is > software, in one sense, but not in another--it can't be changed (it > isn't *soft*). For this reason, the term "firmware" has become > customary. What about flash EPROM (which you can change)? -- ciao, | Marco | [6177 diEmj1dnlVlTY] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
[EMAIL PROTECTED] wrote: >> 2. In the past, the issue of documentation, fonts, images, sound >> files, and other non-program type files was "dealt with" by treating >> them as if they weren't "software". > >This is not really true. We mostly ignored the issue, but they were >always software. We never said "oh, these aren't software". Instead, *You* did not, other people did and still do. >> 3. Since the issue of the "freeness" of documentation, fonts, images, >> sound files, and other non-program type files is now clearly a >> "software" issue, it makes sense to clear up the situation by adapting >> the DSFG to the needs of these types of software, if it is of benefit >> to the cause of Free Software. > >Yes, but we must do so with an end to the cause of Free Software. Refusing to distribute binary firmwares does not help free software. You may choose between getting the firmware on a EEPROM chip or having your driver load it, but at the end of the day you will still use free software. So, if removing binary firmwares makes using free software harder for our user it actually harms the cause. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Deferment of Changes from GR 2004-003
[EMAIL PROTECTED] wrote: >i propose an amendment that deletes everything but clause 1 of this proposal, >so that the entire proposal now reads: > > that the amendments to the Social Contract contained within the > General Resolution "Editorial Amendments To The Social Contract" > (2004 vote 003) be immediately rescinded. Seconded. (Please post this in a new thread as well, I originally missed your message.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal G (was: Proposal - Deferment of Changes from GR 2004-003)
On Jun 01, Andreas Barth <[EMAIL PROTECTED]> wrote: > I propose the following amendment, replacing the entire text of the > resolution: Seconded. -- ciao, | Marco | [6555 tr7cnnrfx4XGs] signature.asc Description: Digital signature
Re: Vote Robinson for DPL!
[EMAIL PROTECTED] wrote: >> Branden, and the SPI board, need to stop side stepping issues. >Why are you discussing this on debian-vote? Still? Why not? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Robinson
[EMAIL PROTECTED] wrote: >Here are the top ten contributors to the list over the past 14 months or so. With two or three exceptions, all of them are DFSG-revisionists. This pretty much sums up the debian-legal situation. >People who accuse me of extremism should therefore ask themselves: is >debian-legal a less extreme place now that my presence is nearly >nonexistent? If not, why not? If so, then have I not solved the problem? Non sequitur. I have not seen anybody stating that you alone set the position of debian-legal. >"Extremism" in any case is just red-herring language, a charge without >substance. It tells one nothing about a person's actual views, except >presumably that one's views are not in alignment with the speaker. It Nice rethoric, but this is not true. The Merriam-Webster dictionary defines extremism as "the quality or state of being extreme", and in this context it is referred to a relative position from more widely accepted principles. Obviously, "extremism" is not a bad thing in itself. >offers little more to a reasoned discussion than calling someone "bad". >The ubiquity of the term "extremist" in U.S. political discourse, a field >almost uniformly ridiculed by the U.S.'s fellow developed nations, may >suggest a link between its use and the absence of substantive debate. Or maybe it suggests that you accept U.S. political categories and try to apply them in other contexts too, possibly as a way of ridiculing your opponents. >"Consensus-building" is the flip side of the coin. It's a generic >feel-good term. No, "consensus" is what we had before people like you started trying to change what was the accepted meaning of the DFSG. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions for all candidates re: interpersonal behavior
[EMAIL PROTECTED] wrote: >Assume the demarcated hypothetical scenario to be true for the questions >which follow. Now let's try with a less hypothetical scenario. I'd like to know from the candidates what do they think about a candidate who, after discovering a possible bug in somebody else's package, proclaims on IRC that he will not discuss it with the maintainer because he personally dislikes him. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Robinson
[EMAIL PROTECTED] wrote: >> With two or three exceptions, all of them are DFSG-revisionists. >> This pretty much sums up the debian-legal situation. >Marco subscribes to the notion that the DFSG was originally only meant >to apply to ELF binaries, and anything else is de jure free. Anybody >who says different, including anybody who was around at the time, can >be dismissed as a 'revisionist'. Bzzz! Wrong. Incidentally I voted against the last two GRs, but this is not what I was talking about. DFSG-revisionists are the people who in the last year invented things like the "dissident test" which are not derived from the DFSG and pretend to use them as a measure of software freeness for Debian. >> No, "consensus" is what we had before people like you started trying to >> change what was the accepted meaning of the DFSG. >Since all objections have been dismissed, obviously there was >"consensus", with the exception of the thing currently being >dismissed. This "consensus" has been formed in the small circle of the DFSG revisionists when nobody else payed much attention to debian-legal, and now it's being used to silence dissenting opinions with the argument that "all objections have been dismissed". >It's a fairly conventional circular argument; most people on -legal >have stopped paying any attention. True. They are the people who caused this, after all. But they do not represent other developers, so I still have hopes for Debian. (I appreciate that you define my opinions as "trolling". Since I'm sure that you understand well the correct meaning of this word, then I must assume that you have no other arguments than an ad hominem.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Robinson
[EMAIL PROTECTED] wrote: >> DFSG-revisionists are the people who in the last year invented things >> like the "dissident test" >search in debian-legal for "dissident test" in 2003. You are right, now it's almost two years old. But this detail is not much relevant. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT: Re: debian-women obscurity, was: Clarification about ?krooger's platform
[EMAIL PROTECTED] wrote: >No, I think you see it but you disagree whether the directory >of women or the current list charter is discriminating on the >basis of sex, and the severity or remedies of past incidents. Sure, and the obituaries are a discrimination on the basis of death. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Robinson
[EMAIL PROTECTED] wrote: >Though I am interested in being involved in debian-legal, I am turned >off by Andrew Suffield's description of anyone with a view other than >his own as an "anti-freedom advocate". In my experience this is a common attitude among DFSG-revisionists, like when Branden Robinson on IRC used to define me a warez trader because I do not share his views on firmwares packaging. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Robinson
[EMAIL PROTECTED] wrote: >> This "consensus" has been formed in the small circle of the DFSG >> revisionists when nobody else payed much attention to debian-legal, and >> now it's being used to silence dissenting opinions with the argument >> that "all objections have been dismissed". >Silence? Have you been banned from debian-legal now? I can see an No, but I see no point in discussing licensing issues with a dozen of people who keep saying that they reached consensus a couple of years ago and I should shut up, so I tend to avoid most threads. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Robinson
[EMAIL PROTECTED] wrote: >> No, but I see no point in discussing licensing issues with a dozen of >> people who keep saying that they reached consensus a couple of years >> ago and I should shut up, so I tend to avoid most threads. >The point that you have to recognize is that the arguments someone new >might bring up are, in all likelihood, already well considered by the >rest of the group. They may be new to *you*, but they are not new to No, I am well aware of the past arguments. I just happen to disagree with them. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to all DPL candidates
[EMAIL PROTECTED] wrote: >Out of curiosity, which "important pieces of software" are hidden >by not mentioning or including non-free (and contrib)? I will add to the list ipw2100-source, ipw2200-source and many other drivers which have been declared unworthy of main after the firmware madness. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
