sponsored NMU's to be forbidden (Re: How can a non-DD fix broken packages?)
On Tue, May 30, 2006 at 09:48:06PM -0300, Henrique de Moraes Holschuh wrote: > IMHO we really should have a global NMU blacklist (no, never per-package. > That way lies lameness) which we could ask the ctte to place maintainers in > for a few months when someone does the NMU-and-forget routine and that NMU > causes problems: screw up an NMU and don't clean up after yourself, get > punished by not being able to screw up through NMUs again for a while. > > We should *also* have the pts auto-add anyone who does an NMU to receive all > bug reports. If you NMU, you *are* responsible for it, and it is not nice > to make it so easy for one to forget he NMUed something, after all. You sure do have a point here. But that seems to apply to both DD's and non-DD's. I still don't see why a sponsored NMU would be bad. -- Bart Martens <[EMAIL PROTECTED]> Wed, 31 May 2006 07:20:01 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: distributed-net [non-free]
Hi, The distributed-net package was orphaned by it's maintainer a few weeks ago, and I have decided to adopt it. I have prepared a new version of the package, and would now like to request that someone sponsor it. The short and long descriptions below were taken from the control file for the package, which was written by one of the previous maintainers. Short Description: donate unused CPU cycles - client for distributed.net Long Description: Donate your extra CPU cycles to a worthy cause! distributed.net started in 1997 as a project whose purpose was to win a series of contests sponsored by RSA Data Security Inc., to crack their RC5 encryption by brute-force methods. These contests were meant to show governments of nations such as the United States, who limit exports or use of cryptography, that the standards allowed are too weak for general use. Since this time, distributed.net has changed their focus from solely cracking RSA's RC5 and DES projects to working on more diverse distributed computing problems. The ongoing projects are RC5-72 and Optimal Golumb Rulers (25-mark), the latter of which has practical applications in science. There are also a number of other projects which are either periodic or upcoming. You may choose which project you wish to participate in. By installing this package, unused CPU cycles on your computer will be used to work on cracking the code. There should be no noticeable slowdown of your system, since the client runs niced, and only uses CPU time when your computer would otherwise be idle. For more information, see http://www.distributed.net/ Licence: Distributed.net has a proprietary (non-free) licence, that generally forbids redistribution, however they have mad an exception for the Debian project (as can be seen on the copyright file). Changes that I have made to the package: For my fist upload I have updated the package to the newest upstream version, added support for amd64, and bumped the standards version to match the most recent version of the Debian policy manual (based on my reading of the manual, no changes were needed). Where to get the package: I have put all of the relevant files (tar-balls, .deb and .changes files) at the following location: http://hebb.cis.uoguelph.ca/~jstark/debian/ I have set this up as an apt repository so apt should be able to retrieve the packages once the following lines are added to your sources.list: deb http://hebb.cis.uoguelph.ca/~jstark/debian ./ deb-src http://hebb.cis.uoguelph.ca/~jstark/debian ./ Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can a non-DD fix broken packages?
On Tue, 30 May 2006, Steve Langasek wrote: > The difference being that most of the time when someone "sponsors" an NMU, > they're effectively shirking their own duty to follow up on the package and > ensure that the NMU hasn't introduced any regressions. Often, they're > shirking their duty to even check the correctness of the provided patch > themselves. IMHO we really should have a global NMU blacklist (no, never per-package. That way lies lameness) which we could ask the ctte to place maintainers in for a few months when someone does the NMU-and-forget routine and that NMU causes problems: screw up an NMU and don't clean up after yourself, get punished by not being able to screw up through NMUs again for a while. We should *also* have the pts auto-add anyone who does an NMU to receive all bug reports. If you NMU, you *are* responsible for it, and it is not nice to make it so easy for one to forget he NMUed something, after all. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can a non-DD fix broken packages?
On Tue, May 30, 2006 at 02:04:00PM -0700, Don Armstrong wrote: > On Tue, 30 May 2006, Bart Martens wrote: > > On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote: > > > There are no technical measures in place which *prohibit* > > > developers from sponsoring NMUs. Nevertheless, the concept of a > > > sponsored NMU is a broken one, because responsibility for the NMU > > > lies with the uploader, not with the sponsoree. > > Does that mean that your opinion is that sponsored NMU's should be > > forbidden? I would regret that. It's not bad that someone in the NM > > queue also does NMU's to help fixing other packages. And I don't see > > a problem with responsability if the sponsor is aware of that > > responsability. > A sponsored NMU basically means taking the patch for the NMU just like > you would from a RC bug that had a patch, testing it just like you > would normally, and making the upload just as you would for any other > NMU. > Since you're responsible for the NMU anyway, there's really no > sponsoring going on; you're just using a pre-existing patch as the > basis of your NMU. The difference being that most of the time when someone "sponsors" an NMU, they're effectively shirking their own duty to follow up on the package and ensure that the NMU hasn't introduced any regressions. Often, they're shirking their duty to even check the correctness of the provided patch themselves. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How can a non-DD fix broken packages?
On Tue, 30 May 2006, Bart Martens wrote: > On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote: > > There are no technical measures in place which *prohibit* > > developers from sponsoring NMUs. Nevertheless, the concept of a > > sponsored NMU is a broken one, because responsibility for the NMU > > lies with the uploader, not with the sponsoree. > > Does that mean that your opinion is that sponsored NMU's should be > forbidden? I would regret that. It's not bad that someone in the NM > queue also does NMU's to help fixing other packages. And I don't see > a problem with responsability if the sponsor is aware of that > responsability. A sponsored NMU basically means taking the patch for the NMU just like you would from a RC bug that had a patch, testing it just like you would normally, and making the upload just as you would for any other NMU. Since you're responsible for the NMU anyway, there's really no sponsoring going on; you're just using a pre-existing patch as the basis of your NMU. Don Armstrong -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[RFS] NMU of gcc-h8300-hms
As I've been told a few hours ago, I hereby request a sponsor for an NMU of gcc-h8300-hms. The files are available from http://www.model.in.tum.de/~tautschn/debian/ ; the according patch has been posted to the BTS, #328244 Cheers, Michael signature.asc Description: Digital signature
Re: How can a non-DD fix broken packages?
Bart Martens wrote: > On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote: > >>There are no technical measures in place which *prohibit* developers from >>sponsoring NMUs. Nevertheless, the concept of a sponsored NMU is a broken >>one, because responsibility for the NMU lies with the uploader, not with the >>sponsoree. > > > Does that mean that your opinion is that sponsored NMU's should be > forbidden? I would regret that. It's not bad that someone in the NM > queue also does NMU's to help fixing other packages. And I don't see a > problem with responsability if the sponsor is aware of that > responsability. But maybe I'm missing something? > I would have to agree with Vorlon. Whenever I have wanted to do an NMU (not, I am not yet a DD), I just fix whatever bug and send a patch to the bug. After that, I can announce on IRC or a suitable mailing list for someone to please review the changes, incorporate them and do the NMU. That other person's name goes on the changelog entry, but they always give credit to the originator of the patch (I have not seen a case where it has not been done). In that way, there is a review by a DD and that DD is definitely accepting responsbility, as they are ones patching and uploading. I'm not sure if that is correct, but that is how I have ssen it work. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: How can a non-DD fix broken packages?
On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote: > There are no technical measures in place which *prohibit* developers from > sponsoring NMUs. Nevertheless, the concept of a sponsored NMU is a broken > one, because responsibility for the NMU lies with the uploader, not with the > sponsoree. Does that mean that your opinion is that sponsored NMU's should be forbidden? I would regret that. It's not bad that someone in the NM queue also does NMU's to help fixing other packages. And I don't see a problem with responsability if the sponsor is aware of that responsability. But maybe I'm missing something? -- Bart Martens <[EMAIL PROTECTED]> Tue, 30 May 2006 22:02:12 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: C Tutorial ?
Jon Dowland <[EMAIL PROTECTED]> writes: > At 1146961412 past the epoch, Roger Leigh wrote: >> Note that programming GTK+ in C is not "C programming", >> it's "GObject programming". This requires that you know >> not only about how objects are implemented on a >> fundamental level by the C++ compiler (...), but how to >> re-implement these concepts in C. And, in addition, >> several features from smalltalk such as properties. > > I disagree here. You do not need to know about most of the > OO/C++ concepts you list in order to *use* GTK+, at least in > a superficial sense. Some of them (properties) are needed > for non-trivial programs, but low-level stuff like vtables > etc. are hidden from you quite well. I would argue that to build anything more complex than a trivial "hello world" application, comprehensive knowledge of GObject/GType is a requirement. If you look at any GNOME application (gnumeric is a good example), it is a set of objects all derived from GObject or GtkWidget and their derived types, and the working application is a collection of these objects linked together with e.g. signals and containment. That said, it's hard and error prone, which is why I abandoned C GTK+ development last year in favour of python. It's IMO the main cause of bugs, because the compiler just can't catch many mistakes. If you do use the C API, you end up expending a great deal of energy for relatively little gain compared with using one of the other language bindings. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpIamTLj5OSq.pgp Description: PGP signature
Re: Question about linux-wlan-ng-firmware in main
This one time, at band camp, Frank Küster said: > Stephen Gran <[EMAIL PROTECTED]> wrote: > > Can't you just ship those ten lines in contrib, and the rest in main? > > This may be archive bloat, but surely it's arch:all, so that minimizes > > the bloat at least. I am not over fond of the freer-than-free holy > > wars, but it does seem like this script is exactly the sort of thing > > that contrib was designed for. > > This explicitly does *not* mention "Suggests". Who said anything about Suggests? I am not talking about inter-package dependencies. I am only talking about the script that downloads some non-free firmware. The rest of the package is of course fine for main, as far as I can tell from the conversation so far. > I rather think it's a technical question: Can a source package in main > produce one binary package that is installed in contrib, or is the > separation done only on the level of source packages? I don't know the answer to that myself, although I can't see why not, legally or ideologically, since contrib is defined as free in and of itself, but with missing and/or non-free dependencies. It shouldn't be impossible to have a source in main/binary in contrib arrangement, although maybe it is due to limitations of the archive software. Not that I'm set on forcing this (as yet nonexistant) _binary_ package into contrib. It's just that all the other download packages are moving there, and I thought it should be with it's friends. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
sponsored NMU (Re: How can a non-DD fix broken packages?)
On Tue, May 30, 2006 at 02:37:56PM -0400, Joe Smith wrote: > That is a Serious bug, and is a FTBFS, so AIUI, it is RC. So it can be > filex in a NMU. However, According the the Developer's reference, only DD's > can NMU. If that is true, then sponsored NMU are not allowed. However, > tradition holds against this, as there have be numerous cases of sponsored > NMU's. Assuming the DevRef is in error, you should prepepare an NMU, > following the rules [0], publish the packages someplace public, and send a > message to this list with a title beginning "[RFS] NMU". > > [0] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Yes, an NMU can be done by a non-DD working via a sponsor. I don't think the docs are in error about this. I think that large parts of the docs are older than the concept of sponsoring, and that most docs that seem to be for DD's also apply for non-DD's working via a sponsor. -- Bart Martens <[EMAIL PROTECTED]> Tue, 30 May 2006 21:00:57 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can a non-DD fix broken packages?
On Tue, May 30, 2006 at 02:37:56PM -0400, Joe Smith wrote: > "Michael Tautschnig" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > That is a Serious bug, and is a FTBFS, so AIUI, it is RC. So it can be > filex in a NMU. However, According the the Developer's reference, only DD's > can NMU. If that is true, then sponsored NMU are not allowed. However, > tradition holds against this, as there have be numerous cases of sponsored > NMU's. There are no technical measures in place which *prohibit* developers from sponsoring NMUs. Nevertheless, the concept of a sponsored NMU is a broken one, because responsibility for the NMU lies with the uploader, not with the sponsoree. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How can a non-DD fix broken packages?
"Michael Tautschnig" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] That is a Serious bug, and is a FTBFS, so AIUI, it is RC. So it can be filex in a NMU. However, According the the Developer's reference, only DD's can NMU. If that is true, then sponsored NMU are not allowed. However, tradition holds against this, as there have be numerous cases of sponsored NMU's. Assuming the DevRef is in error, you should prepepare an NMU, following the rules [0], publish the packages someplace public, and send a message to this list with a title beginning "[RFS] NMU". [0] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can a non-DD fix broken packages?
On Tue, May 30, 2006 at 07:49:22PM +0200, Michael Tautschnig wrote: > Hi all! > > This email is motivated by an effective current issue, as detailed below, but > I'm seeing myself in similar situations quite often. > > There is a package, which isn't officially orphaned, but the maintainer is > neither responding to bug reports nor to mails to her @d.o address. Even > though > there is a patch provided with the bug report or I do have one myself, I'm > seeing no way of how to fix the bug and get the package back on track. > > For the curious, my motivation currently stems from #328244. We are using > brickos and gcc-h8300-hms at our site for teaching purposes, so we had to > patch > the gcc-h8300-hms package and provide it in our local repository, but this > isn't > the way Debian works, is it!? If you want to fix the package only once, then a "non-maintainer upload" (NMU) may be the way to go. http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu If you are interested in keeping the package up-to-date regularly, then you may want to offer co-maintainership to the current maintainer. -- Bart Martens <[EMAIL PROTECTED]> Tue, 30 May 2006 20:17:37 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How can a non-DD fix broken packages?
Hi all! This email is motivated by an effective current issue, as detailed below, but I'm seeing myself in similar situations quite often. There is a package, which isn't officially orphaned, but the maintainer is neither responding to bug reports nor to mails to her @d.o address. Even though there is a patch provided with the bug report or I do have one myself, I'm seeing no way of how to fix the bug and get the package back on track. For the curious, my motivation currently stems from #328244. We are using brickos and gcc-h8300-hms at our site for teaching purposes, so we had to patch the gcc-h8300-hms package and provide it in our local repository, but this isn't the way Debian works, is it!? Thanks, Michael signature.asc Description: Digital signature
Re: Question about linux-wlan-ng-firmware in main
Bas Wijnen <[EMAIL PROTECTED]> wrote: > On Tue, May 30, 2006 at 03:26:56PM +0200, Frank K?ster wrote: >> No, it wasn't. As long as I can remember, packages which contained a >> small part of contrib material, which was not crucial for the function >> of the package as a whole, can go to main. Look at the policy: >> >> , 2.2.1 The main category >> | Every package in main must comply with the DFSG (Debian Free Software >> | Guidelines). >> | >> | In addition, the packages in main >> | >> | * must not require a package outside of main for compilation or >> | execution (thus, the package must not declare a "Depends", >> | "Recommends", or "Build-Depends" relationship on a non-main >> | package), >> ` >> >> This explicitly does *not* mention "Suggests". > > Packages containing some contrib material, without which the package functions > well, can indeed go in main AFAIK. However, if I understand the situation > correctly, this package is completely useless without the non-free firmware if > you happen to have a device which needs it. It seems we are confusing source packages and binary packages here. The source package is linux-wlan-ng, and this clearly has a use independently of any non-free files. The binary package is linux-wlan-ng-firmware, and this is only a downloader. > Then again, this sounds pretty much like a thing for debian-legal. :-) I rather think it's a technical question: Can a source package in main produce one binary package that is installed in contrib, or is the separation done only on the level of source packages? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question about linux-wlan-ng-firmware in main
On Tue, May 30, 2006 at 03:26:56PM +0200, Frank K?ster wrote: > No, it wasn't. As long as I can remember, packages which contained a > small part of contrib material, which was not crucial for the function > of the package as a whole, can go to main. Look at the policy: > > , 2.2.1 The main category > | Every package in main must comply with the DFSG (Debian Free Software > | Guidelines). > | > | In addition, the packages in main > | > | * must not require a package outside of main for compilation or > | execution (thus, the package must not declare a "Depends", > | "Recommends", or "Build-Depends" relationship on a non-main > | package), > ` > > This explicitly does *not* mention "Suggests". Packages containing some contrib material, without which the package functions well, can indeed go in main AFAIK. However, if I understand the situation correctly, this package is completely useless without the non-free firmware if you happen to have a device which needs it. The fact that the package is useful for other people is quite irrelevant: the download script is useless for them anyway, irrespective of their attitude towards non-free software. To me it does indeed sound like this is a good example of what contrib is meant for. That is, I think the whole package should be in contrib if it contains this script, because it provides typical contrib-functionality for a group of people (and no significant other functionality, to that group). I can see that having the whole package in contrib is not desirable, though. It can only be avoided by splitting off the script (or removing it altogether, but that's not very nice to our users). Then again, this sounds pretty much like a thing for debian-legal. :-) Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Question about linux-wlan-ng-firmware in main
Stephen Gran <[EMAIL PROTECTED]> wrote: >> In fact, I go even further: I wish that the package use a low-priority >> debconf question (defaulting to "do not download") to let the user execute >> the wrapper at installation time. Of course, the question should warn the >> user that he's about to download non-free stuff. > > Can't you just ship those ten lines in contrib, and the rest in main? > This may be archive bloat, but surely it's arch:all, so that minimizes > the bloat at least. I am not over fond of the freer-than-free holy > wars, but it does seem like this script is exactly the sort of thing > that contrib was designed for. No, it wasn't. As long as I can remember, packages which contained a small part of contrib material, which was not crucial for the function of the package as a whole, can go to main. Look at the policy: , 2.2.1 The main category | Every package in main must comply with the DFSG (Debian Free Software | Guidelines). | | In addition, the packages in main | | * must not require a package outside of main for compilation or | execution (thus, the package must not declare a "Depends", | "Recommends", or "Build-Depends" relationship on a non-main | package), ` This explicitly does *not* mention "Suggests". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question about linux-wlan-ng-firmware in main
On Tue, 30 May 2006, Stephen Gran wrote: > Can't you just ship those ten lines in contrib, and the rest in main? > This may be archive bloat, but surely it's arch:all, so that minimizes > the bloat at least. I am not over fond of the freer-than-free holy > wars, but it does seem like this script is exactly the sort of thing > that contrib was designed for. Please think about what makes sense. Contrib has been designed for free stuff which are useless without non-free stuff. So when you create a wrapper package to install non-free fonts, it goes clearly in contrib because having that package in main would advertise too much the non-free fonts within Debian (the package name appears in synaptic, and the description clearly mentions non-free stuff) and we do not want that. However in our case, this wrapper script is *not* a package on its own. It's a helper script for a regular main package. The purpose of the script is not to encourage people to use non-free stuff but only to enable users which need those firmwares to download them... it's really not at the same level than the other wrapper for me. The "freer-than-free inquisitors" will explain that this is only rhetoric but for me it's not. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
This one time, at band camp, Raphael Hertzog said: > Contrib is effectively meant for wrapper on non-free stuff. But contrib is > really needed when the wrapper stuff is the *main purpose* of the package. > > In the case concerning us, we have 10 lines of DFSG-free code that can be > used to download non-free firmwares within a bigger DFSG-free package. > > For me it's no worse than putting the 10 lines of code in README.Debian, > it serves really the same purpose. > > So my vote is "keep that little wrapper in the main package, it doesn't > hurt". > > In fact, I go even further: I wish that the package use a low-priority > debconf question (defaulting to "do not download") to let the user execute > the wrapper at installation time. Of course, the question should warn the > user that he's about to download non-free stuff. Can't you just ship those ten lines in contrib, and the rest in main? This may be archive bloat, but surely it's arch:all, so that minimizes the bloat at least. I am not over fond of the freer-than-free holy wars, but it does seem like this script is exactly the sort of thing that contrib was designed for. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Question about linux-wlan-ng-firmware in main
On Tue, 30 May 2006, Goswin von Brederlow wrote: > > A downloader package is a bit of grey area; much like a typical > > "contrib" package, it has some more-or-less hardcoded string that > > points to non-free data; it does not, however, depend on anything > > outside of main to function (since main is enough to get a network up > > and running, and the web service, while not dealing with free > > software, is not Debian's concern as it is only between the user and > > the company publishing the data files). > > It depends on software not in debian to function properly. If the > firmware is no longer supplied on the firms webserver then the > donwload package stops working. Imho that is a clear dependency even > if it doesn't fall under the "Depends:" field. Contrib is effectively meant for wrapper on non-free stuff. But contrib is really needed when the wrapper stuff is the *main purpose* of the package. In the case concerning us, we have 10 lines of DFSG-free code that can be used to download non-free firmwares within a bigger DFSG-free package. For me it's no worse than putting the 10 lines of code in README.Debian, it serves really the same purpose. So my vote is "keep that little wrapper in the main package, it doesn't hurt". In fact, I go even further: I wish that the package use a low-priority debconf question (defaulting to "do not download") to let the user execute the wrapper at installation time. Of course, the question should warn the user that he's about to download non-free stuff. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
Simon Richter <[EMAIL PROTECTED]> writes:
> Hi,
>
> Goswin von Brederlow schrieb:
>
>> But does it have any use without the non-free firmware? Only then can
>> you close an eye and let it stay in main due to its other functions.
>
> Yes: Loading free firmware. Whether such a thing exists is largely
> irrelevant; for the loader, it is just data, and we do not
> discriminate on fields of endeavour (i.e. it is fine to copy your
> non-free data around as you like it, even into your hardware if you so
> choose).
I disagree there. As long as there is no way to create free firmware
(no specs, secret checksum/signature, ...) or even as long as nobody
has done so the package has no practical use in main (without the
non-free firmware) and belongs to contrib. The purely theoretical
(untill someone does it) use of creating free firmware is no argument
for main in my opinion. Having it in contrib is no hardship for users.
> A downloader package is a bit of grey area; much like a typical
> "contrib" package, it has some more-or-less hardcoded string that
> points to non-free data; it does not, however, depend on anything
> outside of main to function (since main is enough to get a network up
> and running, and the web service, while not dealing with free
> software, is not Debian's concern as it is only between the user and
> the company publishing the data files).
It depends on software not in debian to function properly. If the
firmware is no longer supplied on the firms webserver then the
donwload package stops working. Imho that is a clear dependency even
if it doesn't fall under the "Depends:" field.
> The real problem with firmware in my opinion is that it ignites a
> flamewar between people that don't really care whether they have free
> software as long as it works, and free software purists that want to
> be able to change their entire system, including the firmware. The
> former group usually emphasizes that "our priority are our users", the
> latter "our priority is free software".
The problem only arises when people want to include non-free firmware
in main with such excuses as "this isn't software" or "it isn't run on
your cpu". Just like anything else firmware can be free (like the
adaptec firmware in the kernel source) or non-free and must be placed
as such in main or non-free. Purist can then choose not to use
non-free while sane people do.
> We have yet to find a sane middle ground; largely because it would
> probably be "display a dialog educating the user that they are now
> leaving the wonderful world of free software where you can expect the
> development team to consist of actual humans that reply to bug
> reports, and entering the evil corporate dystopia where emails are
> answered by 'your opinion is very important to us'" -- and this would
> upset both groups ("You zealots should not pester the users with your
> ideology all the time" vs. "Yeah, as if somebody read all those
> messages").
>
> Good ideas welcome.
>
> Simon
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
Hi,
Goswin von Brederlow schrieb:
But does it have any use without the non-free firmware? Only then can
you close an eye and let it stay in main due to its other functions.
Yes: Loading free firmware. Whether such a thing exists is largely
irrelevant; for the loader, it is just data, and we do not discriminate
on fields of endeavour (i.e. it is fine to copy your non-free data
around as you like it, even into your hardware if you so choose).
A downloader package is a bit of grey area; much like a typical
"contrib" package, it has some more-or-less hardcoded string that points
to non-free data; it does not, however, depend on anything outside of
main to function (since main is enough to get a network up and running,
and the web service, while not dealing with free software, is not
Debian's concern as it is only between the user and the company
publishing the data files).
The real problem with firmware in my opinion is that it ignites a
flamewar between people that don't really care whether they have free
software as long as it works, and free software purists that want to be
able to change their entire system, including the firmware. The former
group usually emphasizes that "our priority are our users", the latter
"our priority is free software".
We have yet to find a sane middle ground; largely because it would
probably be "display a dialog educating the user that they are now
leaving the wonderful world of free software where you can expect the
development team to consist of actual humans that reply to bug reports,
and entering the evil corporate dystopia where emails are answered by
'your opinion is very important to us'" -- and this would upset both
groups ("You zealots should not pester the users with your ideology all
the time" vs. "Yeah, as if somebody read all those messages").
Good ideas welcome.
Simon
signature.asc
Description: OpenPGP digital signature
