Re: kernel firmwares: GR proposal
Seconded. On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote: > Overview: > > The Linux kernel source contains device drivers that ship with firmware > files provided by the hardware manufacturer. They are uploaded during > the driver initialization to the corresponding hardware device. > > Some of these binary image files are provided as a hexdump of register > bank settings, others consist in fact of compiled binary code which is > executed on the hardware device. > > Any device driver in the Linux kernel is freely available in source > format and licensed under the GPL2. For many device drivers with > attached firmware, the firmware image is freely distributable along > with the corresponding driver. The most common source format for > firmwares is the hexdump char array. It is almost impossible to > distinguish between register dumps and binary code without asking the > device manufacturer who provided the firmware. > > Removing every firmware which is distributed as hexdump only will > cripple the kernel to an extent where it becomes unusable for most of > our users, because popular network and scsi devices are among the > drivers in question. Without these drivers, the user's system might not > be installable at all. > > > The current situation: > > We achieved a lot of progress compared with the situation in 2.6.8 (the > kernel that shipped with sarge). We were able to convince upstream that > a firmware loader is a good thing, and that firmware and kernel code > should be separated. This firmware loader was added in 2.6.13, and > meanwhile, more than 40 drivers have been converted to the new > infrastructure. However, this is not yet finished, and some important > drivers still use the old method. There will be a day where we can drop > the remaining legacy, but we are not there yet. > > Also, though the firmware loader allows us to put the firmware where it > belongs to (main or non-free, depending on the case), the installer can > as of now only take udebs from main. Fixing this is not too hard, but > it is doubtful whether we can fix this in time for etch, and we do not > want to depend on that (and even then, we still would have non-free > firmware, see above). But since there is lots of hardware which needs > firmware for correct operation, the installer would not work for > mainstream hardware otherwise. > > There are two ways how to deal with it: > 1. Accept these issues as transitional issues for now; or > 2. Delay etch for some serious time. > > > In our social contract, we promised that the users and the free software > community are our priorities. We firmly believe that our users profit > very much from releasing etch in time, and that this is important enough > that we can accept the transitional status with having a few firmware > images left in main that should belong somewhere else. Of course, > everyone who wants to make the number of such firmware images as small > as possible is welcome to help converting old firmware loaders to the > new standard, and working on the Debian installer. We are happy if this > issues become smaller or even vanishes, but we do not want this to be a > release blocker. > > > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. > > > We want to emphasize that the success of this GR is considered as > necessary by the kernel and release team for successfully delivering etch > in time (and to allow us a successful planning of that). > > > on behalf of the kernel- and release team > Frederik Schueler -- Prepare for tomorrow -- get ready. -- Edith Keeler, "The City On the Edge of Forever", stardate unknown signature.asc Description: Digital signature
Re: Let's vote ...
On Fri, Sep 22, 2006 at 09:11:02PM +0200, Frederik Schueler wrote: > On Fri, Sep 22, 2006 at 10:45:34AM -0500, Manoj Srivastava wrote: > > come to an agreement about what exactly in that email > > constitutes the actual general resolution? I second the following GR. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iEYEARECAAYFAkUUPwUACgkQLkAIIn9ODhHlDwCg68Ik6S3Yb6MWNODtQxkD2O2k H20An1SU29YsVAt1eZy+bz5m/WiyjGZr =G1IU -END PGP SIGNATURE- -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
On Wed, Sep 27, 2006 at 12:36:56PM -0500, Manoj Srivastava wrote: > , > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | 2. We acknowledge that there is a lot of progress in the kernel > | firmware issue; however, it is not yet finally sorted out; > | 3. We assure the community that there will be no regressions in > | the progress made for freedom in the kernel distributed by > | Debian relative to the Sarge release in Etch > | 4. We give priority to the timely release of Etch over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware in udebs as > | long as it is necessary for installation (like all udebs), and > | firmware included in the kernel itself as part of Debian Etch, > | as long as we are legally allowed to do so, and the firmware is > | distributed upstream under a license that complies with the DFSG. > ` I second this a amendment. Bastian -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, "The Omega Glory", stardate unknown signature.asc Description: Digital signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
I second the following proposal. > === START OF PROPOSAL === > Definition: For the purpose of this resolution, the "firmware" mentioned below > designates binary data included in some of the linux kernel drivers, usually > as > hex-encoded variables and whose purpose is to be loaded into a given piece of > hardware, and be run outside the main memory space of the main processor(s). > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue, both upstream and in the debian packaging; however, it is not > yet finally sorted out. > > 3. We give priority to the timely release of Etch over sorting every bit > out; > for this reason, we will treat removal of problematic firmware as a > best-effort process, and in no case add additional problematic material > to the upstream released kernel tarball. > > 4. We allow inclusion of such firmware into Debian Etch, even if their > license > does not normally allow modification, as long as we are legally allowed > to > distribute them. > > 5. We further note that some of these firmware do not have individual > license, > and thus implicitly fall under the generic linux kernel GPL license. > We will include these firmware in Debian Etch and review them after the > release. Vendors of such firmware may wish to investigate the licensing > terms, and make sure the GPL distribution conditions are respected, > especially with regards to source availability. > > 6. We will include those firmware into the debian linux kernel package as > well > as the installer components (.udebs) used by the debian-installer. > END OF PROPOSAL signature.asc Description: Digital signature
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
On Fri, Oct 24, 2008 at 09:15:43PM +0900, Charles Plessy wrote: > The Debian Project, by the way of a general resolution of its developpers, > decides: > > - The changes announced the 22nd of October on the debian-devel-announce >mailing list (Message-id: <[EMAIL PROTECTED]>) are suspended. It needs to say that the decision is put on hold according to §4.2.2 of the constition. Also the outcome needs to be finite, you want to drop this decision. > - Evolution of the membership procedures of the Project will be prepared in a >discussion that will be finished by consensus or a general resolution. You don't want to force a specific behavior for the future, this may be a amendment to the constitution. Well, maybe you want. This would make it impossible to change the membership procedures without an GR. Bastian -- The face of war has never changed. Surely it is more logical to heal than to kill. -- Surak of Vulcan, "The Savage Curtain", stardate 5906.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 10:35:23AM +, Neil McGovern wrote: > -- > - Following the announcement of the 22nd of October on the > debian-devel-announce >mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer >Status"; > > - Given the importance of defining how the Project accepts new members; > > - Because of the strong opposition to the method used to prepare, discuss and >decide the announced changes, and without judging their validity; > > - In accordance with the paragraphs 4.1(3) and 4.2(2.2) of the Constitution; > > The Debian Project, by way of a general resolution of its developers, decides: > > The changes announced the 22nd of October on the debian-devel-announce > mailing list (Message-id: <[EMAIL PROTECTED]>) are > suspended [§4.1(3)]. This suspension is effective immediately [§4.2(2.2)]. > > In addition, the developers make the following statement: > > The delegates of the Project leader are asked to not take decisions that are > not consensual about the membership procedures of the Project, and to let > these procedures change by way of a general resolution if no consensus > can be reached. > -- Seconded. Bastian -- Dismissed. That's a Star Fleet expression for, "Get out." -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud" signature.asc Description: Digital signature
Re: Draft text on Init Systems GR
Hi Brian On Fri, Nov 15, 2019 at 01:10:58AM -0500, Brian Gupta wrote: > Do you think it's ok in any case to remove init scripts. Let's say an > upstream stops maintaining init scripts, I would like to know if this is a real world problem. Please provide an example of a package where the init script actually comes from upstream and is not maintained in debian/*.init and installed by dh_installinit. Init scripts are inherent incompatible between distributions. One designed for RedHat or, worse, SUSE will not really work on a Debian system, due to differences in used tools. LSB tried to standardize that, but this effort is dead as well. Regards, Bastian -- Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3
Re: Privacy guarantees
On Sat, Sep 11, 2021 at 06:18:16AM +, Paul Wise wrote: > On Fri, Sep 10, 2021 at 2:44 PM Felix Lechner wrote: > > A fellow developer and I have reached an impasse over the appropriate > > level of privacy guarantees in Debian. [1] > I think that lintian privacy tags currently represent several sets of bugs: > The browsers shipping in Debian place no barriers between local files > on disk, sites on the local network and sites on the Internet. So if > someone reads some local documentation they didn't get from Debian > using a browser from Debian, they could have a privacy violation. Could you please describe what the policy violation is you see? Especially as you generalize. And yes, the browsers place barriers between local files and network. E.g. chromium enforces a referrer policy of "strict-origin-when-cross-origin" on file://. Bastian -- If I can have honesty, it's easier to overlook mistakes. -- Kirk, "Space Seed", stardate 3141.9
Re: Renaming the FTP Masters
On Thu, Nov 11, 2021 at 02:23:58PM -0500, Daniel Kahn Gillmor wrote: > I'm legitimately surprised to hear that anyone in the Debian project > believes that the term "FTP master" is *not* confused and outdated. I'm really surprised that ftp master is more important than the weird definition of DD and DM. Bastian -- There's another way to survive. Mutual trust -- and help. -- Kirk, "Day of the Dove", stardate unknown
Re: Changing how we handle non-free firmware
On Tue, Aug 23, 2022 at 11:20:09PM +0200, Bart Martens wrote: > It would be nice to have both installers presented on the front page, so users > can choose. I have no strong opinion on whether the "plus" installer would be > called official or not. While we are at it, can you please propose a wording of this choice that a non-technical user can understand? Bastian -- Bones: "The man's DEAD, Jim!"
Re: Changing how we handle non-free firmware
Moin On Wed, Aug 24, 2022 at 11:05:21AM +0200, Thomas Goirand wrote: > My recent experience with servers (10 and 25 Gbits/s dual port SFP+) is that > you need firmware for network cards when running with: > - Broadcom (bnx2 / bnx2x) > - Qlogic > - Intel (they partially work without the firmware-misc-nonfree package > though) Sure, why add expensive flash if you got a pretty good operating system available to feed you everything in properly sized bites. > No additional package is needed for Mellanox cards. The kernel drivers for newer Mellanox cards contain some support for firmware loading. I haven't checked what they feed, but they can. It comes all down to cost. Hardware is often bootstrapped with SPI flash, which is slow, much slower then the PCIe interface. But this gets off-topic. Bastian -- Captain's Log, star date 21:34.5...
Re: Changing how we handle non-free firmware
Hi On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote: > DSC 1 says we will never "require the use of a non-free component". To me, > this is the major relevant issue. Nothing in Debian requires any non-free component. Require would be: can't be used without, which clearly is not true. > Proposal A will use non-free-firmware by default, but "where possible...will > include ways for users to disable this". Without the "where possible", I > think this opt-out is compatible with the DSC. However, if it is not > possible to disable the non-free-firmware, then it feels like the system is, > in fact, requiring it. Thus this option, as worded, feels potentially > incompatible with the DSC. It is always possible to disable it: remove the entry from the sources.list and the packages. Also, you may want to explain why the installer is part of the system at large. Also please explain it in the context of DSC 4, the sections of the DSC don't stand on it's own. > d. The Secretary declares the option invalid and strikes it from the GR. >This feels heavy handed given that other remedies are available, >most notably (b), which is available even after (and if) A wins. I fail to see where the secretary may do that. The supermajority rules are declarative, they don't need to be invoked. > e. If Proposal A wins, the entire GR is declared invalid. This is the >thing I'm objecting to. I fail to see where this is allowed. Bastian -- One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4
Re: Changing how we handle non-free firmware
On Tue, Aug 30, 2022 at 05:05:35PM -0400, Antoine Beaupré wrote: > Didn't we have buster/updates for a while? Is breakage related to that > the reason why we're not doing this here? We didn't have "buster" and "buster/updates" in the same place. And less "buster/updates" being a subset of "buster". The support for "buster/updates" is a hack also. Bastian -- "Get back to your stations!" "We're beaming down to the planet, sir." -- Kirk and Mr. Leslie, "This Side of Paradise", stardate 3417.3
Re: [RFC] General Resolution to deploy tag2upload
On Wed, Jun 12, 2024 at 08:59:46AM +0200, Holger Levsen wrote: > Am Tue, Jun 11, 2024 at 10:27:56PM -0700 schrieb Russ Allbery: > > > As I said several times before: the implementation has known security > > > bugs (unless you fixed them). But I guess this is going to get ignored > > > again anyway... > > Could you describe what known security vulnerabilities you believe exist, > > does it matter if this GR is about a design? currently the RFC is not to > vote about an implementation... :/ If we need a design, then we can easily avoid the problem points. There is a working counter proposal open: https://bblank.thinkmo.de/introducing-uploads-debian-git.html Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Re: [RFC] General Resolution to deploy tag2upload
On Wed, Jun 12, 2024 at 04:23:29PM +0100, Simon McVittie wrote: > On Wed, 12 Jun 2024 at 15:20:45 +0100, Ian Jackson wrote: > > tag2upload, like dgit, ensures and insists that the git tree you are > > uploading corresponds precisely [1] to the generated source package. > > > > If you base your Debian git maintainer branch on the upstream git (as > > you should) and there is a discrepancy between the contents of the > > upstream git branch, and the .orig.tar.gz you're using, the upload > > will fail. How would it fail? > 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? This actually means we need to get rid of orig.tar completely. Something that does not exist can't differ. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
Re: A thought experiment regarding tag2upload and trust
Hi On Sat, Jun 15, 2024 at 11:03:17AM +0200, Philip Hands wrote: > If Ian were to offer a hosting service for such personal tag2upload > instances, in a way that he assured me could not be used to sign > packages unless I had signed a matching git-tag, I would be willing to > trust his assurances, and may well take him up on the offer. I don't actually think that the keyring people or DSA would do very kindly with that. > If that's OK, but tag2upload as proposed is not, are we really drawing a > line based on what name is on the signing key? If the service is able to provide a verifiable chain of source. But exactly this part is missing. But maybe you can answer the question: Given the .dsc file, how can you, and more critical the public, verify that you and only you signed that upload? > Would it make any difference to the FTP masters if there was some way > for me to assert that I trust the tag2upload service/key to build/sign > source packages for me? It is not about you, it is about the public and their trust in the integrity of the Debian archive. > Of course, without something describing exactly what the problem is from > the FTP master's point of view, it's very hard to judge the merits of > their position. Hu? This was done several times and every time disregarded. Bastian -- Kirk to Enterprise -- beam down yeoman Rand and a six-pack.
Re: [RFC] General Resolution to deploy tag2upload
Hi On Wed, Jun 19, 2024 at 11:18:36AM -0700, Russ Allbery wrote: > > Other ideas like waldi's 3.0 (gitarchive) also go in that direction. > > Similarly, I'm not sure a source package based on Git avoids the need for > a source package build system. There are a ton of ways that maintainers > store things in Git, and I'm not sure it makes sense to upload all of > those as-is. Do you have some examples of weird things? > The things that break are slightly different, but, for > instance, some maintainers do not want the upstream source in the same > branch as their Debian packaging files. You may have to add quite a lot > of unwanted complexity to 3.0 (gitarchive) to represent those cases. Well, I already thought about something like that. The question is just: can we boil that down to a manageable number? For example the Linux kernel just got the debian directory in git, but not the source. We in Debian still maintain patches, but other distributions just switched to a fork of upstream Linux with their changes on top. A possible impelementation would use one or more submodules to reference the real source. The implementation for the source format just needs to expand those submodules for "git archive". This creates then a reproducible result. Okay, this still have the problem that parts of the source is actually generated. But we can also integrate such a step into the source format if we want. So in the end you are not doing "commit; push" but "dpkg-source --commit", which prepares, commits the changes, tags and push or so. > Or > reintroduce a source package build step, in which case we're back to where > we started. And that's where the problem lies. We make this either declarative and reproducible. Or we make it touring complete. > > I'm interested what other ftp-masters prefer when considering a trade > > off between space and additional integrity guarantees here. I have a > > preference for the integrity side. > > I think it's also a trade off in supported workflows. If we start telling > people exactly how they have to use Git to work on Debian packages, we can > simplify a lot of things, but wow do I ever not want to open that can of > worms. Every time we open it on debian-devel, it's a giant mess. (Even > more than this thread!) But why would tag2upload need to support them? It is something new, it can tell people: we support the following, use it or not. IMHO it is one of the problem of Debian that we fail to move forward. Bastian -- Sometimes a feeling is all we humans have to go on. -- Kirk, "A Taste of Armageddon", stardate 3193.9
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote: > 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. I doubt that this a usable definition. Do you think that the provision that a program is pushed into another generic purpose cpu should always make them free? An imaginal system can include several CPU types: - Host CPU (lets say the Power cores of a Cell processor) - Slave CPU (the SPUs of a Cell processor, different instruction set and ABI then the host) - GPU (current NVidia and ATI chips can be filled with rather generic programs to do vector operations) - device driving CPU (e.g. the MIPS cores of a broadcom network chip) Only the last ones are usualy filed by the OS with a firmware and then started. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, "The Omega Glory", stardate unknown -- 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 Elections 2014: Rebuttals
On Wed, Aug 06, 2014 at 03:53:09AM +0200, Jan Sechser wrote: > can you plz remove me from the list thanks Please do that yourself. For more information read the footer on _every_ mail; I'll quote one for you: > 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/cb23b9d3-71d1-4cac-ac16-939558c4a...@gmx.ch Bastian -- -- 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/20140806073344.ga19...@shell.waldi.eu.org
