Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
On Mo, Jan 25, 2010 at 08:28:01 (CET), Luk Claes wrote: >> Yes, exactly. In this draft GR I propose to ignore some DFSG-non-free >> files, which includes sourceless files. Our social contract only >> stipulates that the Debian sytstem must be DFSG-free. We already have >> a non-free section for the non-free works that we would like to >> distribute for the purpose of being used with the our operating >> system. I think that our social contract also allow us to distribute >> innert non-free files together with the source of the Debian system >> as long as they do not take part of it. > > And who in their right mind do you expect to vote for ignoring DFSG > non-freeness, people that want to leave the project? Is this a threat or 'just' an insult? > The source is part of the Debian system as you call it, so what it > contains should be DFSG free. This is your opinion/interpretation on our foundation documents. Since Charles obviously doesn't follow here, a vote to determine consensus on this disagreement seems appropriate. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Call for seconds: DFSG violations in Lenny
Alexander Reichle-Schmehl <[EMAIL PROTECTED]> writes: > Andreas Barth schrieb: >> In case any of the proposals get enough seconds, I would propose then: >> >> | Debian's priorities are our users and free software. We don't trade them >> | against each other. However during getting an release out of the door, >> | decisions need to be done how to get a rock stable release of the high >> | quality Debian is known for, release more or less on time, and to >> | minimize the usage of problematic software. We acknoledge that there >> | is more than just one minefield our core developers and the release team >> | are working at. >> | >> | We as Developers at large continue to trust our release team to follow >> | all these goals, and therefor encourage them to continue making >> | case-by-case-decisions as they consider fit, and if necessary >> | authorize these decisions. > > Should you need to propose this, consider it seconded by me. > > Should you do a s/acknoledge/acknowledge/ and/or s/therefor/therefore/ > I'll still second it. I second both Andreas Barth's proposal with and without Alexander's proposed corrections. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpohFiGIk3eg.pgp Description: PGP signature
Consequences for the lenny release, was: Call for seconds: DFSG violations in Lenny
Robert Millan <[EMAIL PROTECTED]> writes: >4. We give priority to the timely release of Lenny over sorting every bit > out; for this reason, we will treat fixing of DFSG violations as a > best-effort process. Did anyone already writeup a summary of stuff that would be covered by this note? My questions in particular: - are the violations in glibc covered here? - are the violations in portmap covered here? - what other violations are currently known to exist in lenny? AFAIUI and have if Robert's option 2 (allow Lenny to release with proprietary firmware) gets voted over option 3 (allow Lenny to release with any DFSG violations) all these issues have the potential to delay the lenny release until they are fixed. Is my understanding correct? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed amendment: Resolving DFSG violations
Thomas Viehmann <[EMAIL PROTECTED]> writes: > Hi, > > I propose to amend the Robert's resolution by adding the following choice > --- > The Debian project, recognizing that bugs do not fix themselves, > applauds Ben Hutchings's efforts to remove non-DFSG-conformant bits from > the linux-2.6 package in a way that is still making users a priority. It > instructs the project leader to authorize spending of Debian funds to > send a box of chocolates to Ben. > --- > I belive that Robert's resolution is a waste of time Seconded. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpBrYgcuh9Zc.pgp Description: PGP signature
Re: Results for General Resolution: Endorse concept of Debian maintainers
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Sun, Sep 23, 2007 at 11:56:34PM +, David Moreno Garza wrote: >> On Tue, 2007-08-07 at 22:10 +0200, Raphael Hertzog wrote: >> > Please be patient, it will come. >> >> Like when? > > As soon as -private archive get declassified I think. Is this sarcastic or is there some non-obvious relationship? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Debian Maintainers GR
Russ Allbery <[EMAIL PROTECTED]> writes: > If we're voting for the proposal on the basis that all it creates is a > governance structure and everything else will be at the discretion of the > people involved, the proposal should *say* that rather than laying out a > bunch of initial policy. It instead lays out a lot of detailed procedure > which contradicts many of the proposals mentioned on this thread and does > not imply that's all going to change drastically as soon as the proposal > is adopted. If that is the problem of the current GR, I wonder why nobody has come up to write (and others to second) an admentment which changes the initial starting policy. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Debian Maintainers GR
Russ Allbery <[EMAIL PROTECTED]> writes: > For example, if a DM wants to later become a full DD, so far as I can > tell they get no automatic credit for being a DM. While an AM could > take that into account, it shouldn't have to rely on an AM to evaluate > that. It should be a natural next step that can be taken by people > who want to. This isn't prohibited or prevented by the current proposal. Moreover, it explicitly lists the FD and DAM members as people who can implement what you are proposing here. > I'm also not fond of the emphasis that the DM proposal has. I don't want > to see the focus be on people who just want to maintain a few packages and > don't want to deal with / pay attention to / learn about the rest of > Debian. I'm happy to have people not get general upload access until they > have passed checks on their ability to deal with NMUs, shared libraries, > or other things that they don't care about for their own packages, but I > think *everyone* with upload permission needs to go through P&P (not just > the stripped down version in this proposal) and understand that they're > making a committment to the project as a whole, not just to some > individual packages. This is a question of policy, and TBH, I'd expect FD/DAM to implement a policy like this, which is against supported by the current proposal. > I gather from the rest of your mail that you don't feel like you can > effect change in NM and that's why you decided to fork the process in > this proposal, but I at least feel from Joerg's response that this is > excessively pessimistic. I rather think that AJ is trying to craft a policy which is flexible enough that FD/DAM/keyring-maint can adapt to whatever they feel fit. Furthermore, I haven't seen one proposal in this thread which wouldn't be implementable by the current proposal. Hey, it can even by voided/disabled by keyring-maint or DAM by simply refusing every person to go through the DM process. Furthermore, DAM/FD/keyring-maint is able to make every further restriction or precondition they can think of. The top complaints I'm reading from this thread are: 1. it has been proposed by AJ 2. it is too detailed (the micromanagment argument) as for the latter, the proposal explictly talks about an 'initial policy'. I read this as that the proposer of that GR expects it to be changed in near future. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal - Use Cases
Anthony Towns <[EMAIL PROTECTED]> writes: > On Thu, Jun 21, 2007 at 02:50:59PM +0100, Anthony Towns wrote: >> So here's a proposal for the Debian Maintainers idea that's been floating >> around for some time now [...] >> I've used terms like "initial policy" quite a bit -- [...] > > Shortly before leaving DebConf someone (whose name I've forgotten, > sadly) suggested that some sample use cases for the DM process might be > useful. Here's some that come to my mind: That was me. I suggest(ed) that the ballot should either contain or reference usecases, which can be implemented by this GR. In my conversations with other DDs I got the impressen that the resolution text is quite dry, and people might not be able to actually figure out what consequences that proposal can have if it passes. I think the list of usecases is pretty interesting. Some of them (DD on probation) sound very intersting and realisitic to implement from me, I'd like to hear comments from ftp-master on that. In order to faciliate discussion, I'd suggest to move the list to a wiki. I have only quite limited net access right now, so maybe someone else is faster than me with moving the Anthony's list along with comments to http://wiki.debian.org. Thanks! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpmSTUEo9k3J.pgp Description: PGP signature
Re: [GR] DD should be allowed to perform binary-only uploads
Bill Allombert <[EMAIL PROTECTED]> writes: > The Debian project resolves that Debian developers allowed to perform > combined source and binary packages uploads should be allowed to perform > binary-only packages uploads for the same set of architectures. The use case I imagine at this point is that a maintainer uploads a library package src+bin (e.g. src+amd64) for his private arch, and after weeks he notices, that it still has not been built on e.g. sparc yet. So he decides to start his spare Ultra 1 workstation, builds the package in his custom environment and uploads it. My question to this use case: What happens with the "lost" buildlogs? Is there any possibility for a maintainer who depends on this library to check the build logs for this package on this particular architecture? Is the maintainer somehow encouraged or force by policy to publish his buildlogs? What happens if a maintainer starts to maintain a rogue buildd which does not publish his buildlogs? What if this buildd is misconfigured and uploads hundreds of 'broken' packages? In short, how does this proposal address the issue James listed in http://lists.debian.org/debian-devel/2007/01/msg00760.html? I think this proposal needs further discussion. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpu2CB03WSPe.pgp Description: PGP signature
Re: kernel firmwares: GR proposal
Marco d'Itri <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > 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. Like, say, 'restricted'? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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
Sven Luther <[EMAIL PROTECTED]> writes: >> relevant part is this: >> >> >>4. determines that for the purposes of DFSG #2, device >> >> firmware shall also not be considered a program. >> >> I as non native speaker understand that as this: [...] > > Yeah, but then way not say it clearly, and say that we will make an DFSG > exception for firmware, independently of them being programs or not. I'm not sure if Steve really meant it the way I rephrased it, but I think it is. Of course there could be some more clear wording on this, right. >> In fact, I'd love to see some better rationale for the quoted point >> (#4) of the proposed amendment. > > I think the rationale behind it is : We want to keep the firmware in > main, so we say they are not program. This is the motive, but not the rationale why we (can) make such an exception. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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
Sven Luther <[EMAIL PROTECTED]> writes: > Let's say i have a wireless chip, which includes a pci interface which can be > either host or device, a wireless interface to some antenas, an arm core, some > ram and flash. > > [explanations snipped] > > This is not a 100% real example, since i am not aware of a wireless chip with > a real pci interface, they usually come with some gpios, usb, or some kind of > serial interface, and below: > Other examples are SATA or SCSI HW RAID device, like the AMCC/3WARE one, which > include a IO-processor which is in turn a powerpc 40x or 44x based core, which > you could turn into a standalone device all by itself. Or other HW RAID card > which use some kind of service processor from intel. I'm not sure if its clear, but I think this discussion is about device firmware for hardware which (given existance) can be used in multiple operational modes. Honestly, I find this rather hypothetic (maybe quite academic) and I don't feel that this is what Steve is talking about. Perhaps to wording can be fixed for that. The 2nd example you give is a bit different and hits way better what Steve had in mind: These peripherials (well, better controllers for peripherials but I don't think this matters here) are using non-free software (device firmware) which is in turn used by free software, like a debian operating system. I don't think that anyone here seriously doesn't consider this as what we commongly call ``program''. The relevant part is this: >>4. determines that for the purposes of DFSG #2, device >> firmware shall also not be considered a program. I as non native speaker understand that as this: "We of course consider device firmware as programs in general. It is just that for some hardware devices, additional non-free software is needed so that our free software (both applications and device drivers) can be used on this kind of hardware. As we want to serve both of our users and spreading beautiful and usable free software, for some cases [1] we accept that our free software is using some non-free programs on our (peripherial/controlling) devices. For these hardware devices, we support our users and the free software movement by providing them the needed ``device firmware''. We therefore make the clarification that for the purposes of DFSG #2 we special case ``device firmware'' so that for this specific issue, ``device firmware'' is not considered as a program." There are some variations on this which set a limit "until we have better infrastructure to separate non-free ``device firmware'' from the kernel and the installer. Please note that I'm not really decided on this matter. This mail may sound biased. If it is, I'm sorry. I really don't know yet what I would vote (if I was allowed to vote, of course). In fact, I'd love to see some better rationale for the quoted point (#4) of the proposed amendment. [1] the case that there we don't have free access to the sources of the ``device firmware'' -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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
Sven Luther <[EMAIL PROTECTED]> writes: >> Please note in this subthread, that Steve ist talking about ``device >> firmware'', whereas this subthread is talking about ``firmware'' in general. > > And note how the line blurs when you consider a peripheral firmware which is > using the same set of chips which would be also used in standalone devices. I don't think I really understand this sentence. I assume for now that you mean with ``peripheral firmware'' what Steve means with ``device firmware''. Let me try to describe what you mean: Given a hardware device, which is commonly used as peripheral device for a computer system. This hardware device happens to have enough ram, rom and peripherial on its own, so that it could run as a ``standalone device''. In this case, you could make use of source of the sourceless ``device firmware'' in question for your own programms on the ``standalone device''. In case I'm right: WTF?! Can you please give me some concrete examples of devices which can be used both as ``peripherial'' as well as ``standalone''? In case I'm wrong, please clarify. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Steve Langasek <[EMAIL PROTECTED]> writes: > >> 4. determines that for the purposes of DFSG #2, device firmware >> shall also not be considered a program. > > I am bothered that there is never a definition of "firmware" here. Please note in this subthread, that Steve ist talking about ``device firmware'', whereas this subthread is talking about ``firmware'' in general. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
