Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, 30 Aug 2006, Mike Hommey wrote: > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL PROTECTED]> > wrote: > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > > > > > Debian needs to make a decision on how it will deal with this legal > > > minefield. That is higher priority than the entire discussion going on > > > right now, because it determines whether Debian will distribute these 53 > > > BLOBs *at all*, in 'main' or in 'non-free'. > > > > > Oddly enough nobody has proposed a GR addressing this, > > > > Because voting is an absurd means of settling questions of legal liability. > > It's the domain of the ftp team to determine whether we can legally > > distribute a package on our mirrors. > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > time. 53 + 7 = 60. Please Mike, you have lately a tendency to inflame discussions for nothing. You've used me to expect better from you. 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: 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: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: > 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. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy regarding virtual packages
On Wednesday 30 August 2006 00:29, Steve Langasek took the opportunity to say: > On Tue, Aug 29, 2006 at 01:51:39PM +0200, Magnus Holmgren wrote: > > On Monday 28 August 2006 21:06, Steve Langasek took the opportunity to say: > > > On Mon, Aug 28, 2006 at 04:01:57PM +0200, Magnus Holmgren wrote: > > > > Making mail-transport-agent the empty package, and having it depend > > > > only on exim4 (the default), should work. Of course, exim4 can't > > > > conflict with it (but it's enough that all the others do), > > > > > > No, that's not enough. The exim4 package has file conflicts with the > > > other implementors of m-t-a; there need to be Conflicts declared > > > *directly* between exim4 and the others. > > > > So "package-a conflicts package-b" is not the same thing as "package-a > > conflicts package-b AND package-b conflicts package-a"? The policy seems > > to be saying that if a package conflicts with another package > > (asymmetric), then they can't be installed at the same time (symmetric). > > What I understood was being discussed was a situation where package-a > depends package-b, package-a conflicts package-c, and package-b and > package-c have conflicts at the filesystem level. Aha. No, package-c conflicts package-b as well. We would have (for example): Package: mail-transfer-agent Depends: exim4 Package: exim4 Provides: mail-transfer-agent Replaces: mail-transfer-agent (??) Package: postfix Provides: mail-transfer-agent Conflicts: mail-transfer-agent Replaces: mail-transfer-agent Anyway, this looks a bit ugly. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpe1muqeru91.pgp Description: PGP signature
Re: The bigger issue is badly licensed blobs (was Re:Firmware poll
On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote: > On Wed, 30 Aug 2006, Mike Hommey wrote: > > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL > > PROTECTED]> wrote: > > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > > > > > > > Debian needs to make a decision on how it will deal with this legal > > > > minefield. That is higher priority than the entire discussion going on > > > > right now, because it determines whether Debian will distribute these 53 > > > > BLOBs *at all*, in 'main' or in 'non-free'. > > > > > > > Oddly enough nobody has proposed a GR addressing this, > > > > > > Because voting is an absurd means of settling questions of legal > > > liability. > > > It's the domain of the ftp team to determine whether we can legally > > > distribute a package on our mirrors. > > > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > > time. > > 53 + 7 = 60. > > Please Mike, you have lately a tendency to inflame discussions for > nothing. You've used me to expect better from you. this dig is obviously meant to calm things down… Not to mention that *you* are wrong and that Mike is right, there is currently only 7 blob's that we can suppose to be distributable and sourceless at the same time. Mike's frustration cry would have been unoticed if you hadn't felt compelled to slosh your sanctimonious oil all over the fire. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re:Firmware poll
On Wed, Aug 30, 2006 at 10:22:38AM +0200, Pierre HABOUZIT wrote: > > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > > > time. > > 53 + 7 = 60. > > Please Mike, you have lately a tendency to inflame discussions for > > nothing. You've used me to expect better from you. > this dig is obviously meant to calm things down… > > Not to mention that *you* are wrong and that Mike is right No, he's not. There are 60 sourceless blobs that we would potentially redistribute in main depending on the outcome of this discussion. This depends on the answer to two questions: does the project consider it ok to include sourceless firmware in main, and does the ftp team believe it's ok to distribute sourceless firmware that is claimed to be under the GPL? Only the first question belongs to debian-vote, and it's one we should try to get answered regardless of the answer to the second -- because for those 53 other pieces of firmware, if the ftpmasters *do* decide we need a better license, the most likely outcome of contacting upstreams would be that they give us a better license and *still* don't give us the source. And in any case, posting to complain that you think a particular issue isn't worth having a GR about is hardly a productive use of anyone's time. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: > Le jeudi 17 août 2006 à 11:48 -0400, Anthony L. Bryan a écrit : > > Given that downloads like Debian ISOs are already putting a heavy > bandwidth load on the servers and that they are already shared among > many servers, I don't think it is a good idea to encourage users to load > several servers at once with one download. We should instead push > bittorrent as the main distribution media for ISOs. I don't think you got the picture. Metalink can contain information for download using the following protocols: *) http *) ftp *) bittorrent *) e2k Also, magnet url's can be included. What protocol is used to download the files, remains to users choice. IMHO, either if you use metalinks or not, the user can still choose to use http/ftp/torrent/e2k/ without you to approve that. The main advantage in using metalinks is that all information about downloading files using different protocols are included in _one file_ and the user has to choose which one to use. And related to mirrors. What's the purpose of the mirrors ? To reduce the load on the main servers and to help in better distribution files. Agree ? Let's see now. What does metalink does ? Permit the use of _all mirrors_ and better, permit the average Joe to download the images faster. How do you know that the bittorrent is the logical choice ? Just becase the protocol is great for distributing large files ? How do you known that some area of China (for example) does not use e2k as their primary download protocol ? Just think that in this moment, metalink provides the user the most complete information for downloading a file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9VHljGXbUSvc3AsRAngGAJ9N7AxjO/3qbTRZM2alaM81JPN9yQCfUB23 MOEc/gmgtqBrLebg4A+8Nxk= =DI3k -END PGP SIGNATURE- -- 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 Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote: > On Wed, 30 Aug 2006, Mike Hommey wrote: > > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL > > PROTECTED]> wrote: > > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > > > > > > > Debian needs to make a decision on how it will deal with this legal > > > > minefield. That is higher priority than the entire discussion going on > > > > right now, because it determines whether Debian will distribute these 53 > > > > BLOBs *at all*, in 'main' or in 'non-free'. > > > > > > > Oddly enough nobody has proposed a GR addressing this, > > > > > > Because voting is an absurd means of settling questions of legal > > > liability. > > > It's the domain of the ftp team to determine whether we can legally > > > distribute a package on our mirrors. > > > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > > time. > > 53 + 7 = 60. Re-read Nathanael's mail. The blobs that are concerned by all the discussion that has happened so far, and wasted a lot of time, are 7. The 53 are those that have licenses that technically don't allow redistribution. > Please Mike, you have lately a tendency to inflame discussions for > nothing. You've used me to expect better from you. I'm just pissed about all this waste of time discussing in the void while a release is "supposed" to happen in 3 months. And here I'm not only talking about this particular thread. Mike PS: Don't worry, you won't hear a lot from me since I'll be on vacation from saturday for almost 3 weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to package OTF CID fonts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, I'm developing a set of Pan-CJK CID fonts (OTF/TTF format, not wrapped up PS), which will come with their own font specific CMap files. The Adobe ones won't work. Now my question: Where should the fonts and the CMap files be installed and how to register them in the system, so that most applications will be able to use them? Any hints/pointers on defoma, fontconfig, xorg, etc.? Any example configs out there? Cheers Arne - -- Arne Götje (高盛華) <[EMAIL PROTECTED]> PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9V6Nbp/QbmhdHowRAt56AJ9ZbgytnBe1sddUVDLV8f3/a0HGdQCfd/QP Pb73Z3NcQqIFNuUaJP8jFcc= =exb9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: inet-superserver virtual package
On Mon, 2006-08-28 at 12:27:43 +0200, Marco d'Itri wrote: > On Aug 28, Guillem Jover wrote: > > Just yesterday night dato raised the issue on #d-release, and I was > > telling about the virtual package, and that we could move to it now, > > and worry later about a possible transition to that new update-inetd > > (if it happens to exist some day), aj was fine with that. > OK, but then let's do it right. > The idea is to move update-inetd from netbase to each one of the inetd > packages (openbsd-inetd, inetutils-inetd, rlinetd, xinetd), which will > provide the inet-superserver virtual package and depend on a version of > netbase which does not have update-inetd (is a Replaces needed too?). I'm not convinced that duplicating update-inetd in most of the inetd providing packages is a good idea, even if this would allow xinetd to be able to replace a normal inetd easily. I'd prefer that the odd cases override update-inetd, via a custom script that gets called if present from u-i or replace it or whatever. Also in case the mythical rewrite happens it will be easier to coordinate just one instance than all of them, or to sync them if people start fixing their instances. > netbase then will temporarily depend on inet-superserver to allow smooth > upgrades until the other packages will switch to a dependency on the > virtual package[1][2]. Do you mean only a depedency to the virtual package, w/o a real one? > [2] At the same point we should argue about the tcpd dependency too, > currently most packages rely on netbase pulling it. I see arguments for > both having the inetd depend on it if needed (some directly use libwrap) > and having the server packages depend on it if needed (some do not > actually use it). I favour the first option, BTW. Yes we could do that at the same time. And I prefer the first option as well. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: inet-superserver virtual package
On Aug 30, Guillem Jover <[EMAIL PROTECTED]> wrote: > I'm not convinced that duplicating update-inetd in most of the > inetd providing packages is a good idea, even if this would allow > xinetd to be able to replace a normal inetd easily. I'd prefer that the > odd cases override update-inetd, via a custom script that gets called > if present from u-i or replace it or whatever. I can't see why this would be better. > Also in case the mythical rewrite happens it will be easier to > coordinate just one instance than all of them, or to sync them if > people start fixing their instances. I do not believe this. xinetd and rlinetd need their own versions of the program anyway, so at best it could be shared by openbsd-inetd and inetutils-inetd. Coordinating the changes in a 13 KB code base among 2 or 4 maintainers is easy. > > netbase then will temporarily depend on inet-superserver to allow smooth > > upgrades until the other packages will switch to a dependency on the > > virtual package[1][2]. > Do you mean only a depedency to the virtual package, w/o a real one? No. -- ciao, Marco signature.asc Description: Digital signature
Re: Why does Ubuntu have all the ideas?
Am 2006-08-24 17:51:55, schrieb Rudy Godoy: > I do believe it's more a matter of relations with press and media than > budget. We have no easy-way-to-get-it to tell people why they would want to > use Debian. Ubuntu, on the other hand, has achieved to do so, and what they > tell that we can't? nothing. All what they advertise we do offer. But we > are not good on advertise our OS. What do we do, if one day to another 10 million or more peoples want to use Linux (it does not mater which distribution) ARE WE PREPARED? I asume, the worldwide Linux resources would crash. > We need to tell people: Debian is fine for you because it allows you to > get your work done and be productive, whether you are an artist, > corporate employee, student, doctor, etc. Right... > That kind of advertisement, focusing on things that matter for people > more than specs and technical details, which are only interesting for > those who already in the computing area. > I know there is a subproject working on such things, which is great. ? ? (Skolelinux) > No, I still believe we need more people and relations with press, and > not only the technical ones, we should advertise more our work and > good experiences like donzka, LinEx, and the others. Not only tell > ourselves: we know we are doing things better. We should tell it to > others too! Hmmm... Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Am 2006-08-25 11:46:20, schrieb Mgr. Peter Tuharsky: > 1b, If things don't work, it's sometimes hard to get them working > either. Example: Bug 372719. The OOo 2.0 keeps crashing for 2 months > thank to KNOWN bug in security upgrade. Now tell somebody, that Debian But OOo 2.0 is not in Stable! > 1c, Other cases are when something CAN be done in Debian, and even > documentation exists, but it is quite complicated and time consuming, > and truly should be much easier. Mostly the installer's playground to > make life easier and set up things. For example, to automatically > install national fonts and translation packages if the user already > entered his location and national data. Right, this is one thing I mis in the installation of X. Same for the console font since it does not fit my needs for "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". Using UTF-8 on the console is a nightmare... LatArCyrHeb is no solution since it is not complete. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Am 2006-08-26 02:56:25, schrieb Hendrik Sattler: > Am Freitag 25 August 2006 12:54 schrieb Wouter Verhelst: > > Given that a kernel image these days takes up about 50M already > > I guess that those that care for the smallest possible base system (and those > that hate initrd/initramfs) have their own kernel. My one (for a laptop) has > an installed size of 7456 KB (not even close to 50MB). For Linux its true. I have arround the same size. > HS Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Am 2006-08-26 02:01:21, schrieb Benjamin Seidenberg: > You can always use a Transnational Republic ID card. :-) Where can I get this? - Martin? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Am 2006-08-27 01:19:23, schrieb Adam Borowski: > I am pretty sure Michelle has at least _some_ sort of ID, even as an > illegal alien. And with the current anti-Arab scare she would be > already deported were she lacking complete valid papers -- you can > sit in peace if you don't travel anywhere, but by browsing > debian-devel I get the impression Michelle travels around a lot. If you are working for the French Ministry of Defense in conjunction with the Interneational Court of Justice (Den Haag) you will have some privilegues. And yes, I can can do voyagues in Iran, Syria, Lebanon and Turkey without any problems using a Syrien passport NON-VALID in Europe. But thats not a problem with the MOF but with the regional Prefecture. > Michelle, you're not a nobody. Many people know you. If I walked I know and my E-mail searched in Googls for at least the last 8 Years (This is WHY I accept several 1000' apamss per day and using spamassassin, etc.) > Also, the name means little. I don't really care if an upload was > done by a person who claims to be named "Benjamin Seidenberg", I care Since I am Hermaphrodite (I have a legal judgement for the name change) there is a problem with my nams now... 5 diffent names... 1) My Birthname=> Tamay Dogan (female) 2) My illegal Adoptivname => Carsten Konzack (male) 3) At the french Foreignt Legion => Michel Clairmont (male) and later (now women at the FL) => Michelle Clairmont (female) 4) And my Civil European Name => Michelle Konzack (female) 5) And since my friends in Morocco => Samira Samir (female + male) know I am hermaprodite, they call me Now I am waiting for the European Court of jusice to decide what to do. (I am genetic hermaphrodit, so NO doctor can tell I am female or male) (I like to be HOW I AM - an Hermaphrodite doing its job) Thanks, Greetings and nice Day, - confusing the World Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- 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
Hello, On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: > 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. I'm not a lawyer, but my take on this is that if someone ships you a BLOB under the GPL, you have the legal right to demand sources from him. So, in other words, I think Debian (or SPI? or FSF?) *could* make a real hurricane in the press (and courts) by trying to wrestle source code from said vendors. If that'd be good or bad for Debian, I don't know, but it will be very expensive and time consuming. Best, --Toni++ -- 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
Op wo, 30-08-2006 te 17:16 +0200, schreef Toni Mueller: > > Hello, > > On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: > > 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. > > I'm not a lawyer, but my take on this is that if someone ships you a > BLOB under the GPL, you have the legal right to demand sources from > him. So, in other words, I think Debian (or SPI? or FSF?) *could* make > a real hurricane in the press (and courts) by trying to wrestle source > code from said vendors. If that'd be good or bad for Debian, I don't > know, but it will be very expensive and time consuming. No you can not demand this from the vendor which owns the copyright on the BLOB. They are not bound by the GPL and can distribute the BLOB anyway the want. Third parties, like Debian, are bound by the GPL to distribute the BLOB with the corresponding sources and if they don't distribute the source the can not distribute the BLOB. Of course IANAL and don't know the fine details of copyright law. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 05:16:29PM +0200, Toni Mueller wrote: > > > Hello, > > On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: > > 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. > > I'm not a lawyer, but my take on this is that if someone ships you a > BLOB under the GPL, you have the legal right to demand sources from > him. So, in other words, I think Debian (or SPI? or FSF?) *could* make > a real hurricane in the press (and courts) by trying to wrestle source > code from said vendors. If that'd be good or bad for Debian, I don't > know, but it will be very expensive and time consuming. My own understanding, and we discussed this on -legal when we aproached broadcom about the tg3 licencing, is that this is not the case, not really anyway. What happens, is that we, debian have not the possibility to provide those sources, and as thus, simply lose all rights per the GPL to distribute the source code in question, and thus what could happen, would be for the copyright holder to sue us for not respecting the GPL clauses. Obviously, since he doesn't do so himself, he would lose anyway, so the point is mostly moot, but the GPL itself says it doesn't allow us to distribute the problematic code in those cases. Since the firmware blobs are not derivative works of the kernel, but constitute mere agregation in the same binary format, the authors of other pieces of GPLed code fo the linux kernel cannot even sue us for distributing the kernel code with those GPL-violating binary BLOBs. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Update: status of inetd
On Mon, Aug 28, 2006 at 12:58:27PM +0200, Marco d'Itri wrote: > On Aug 28, Roger Leigh <[EMAIL PROTECTED]> wrote: > > > 1) Split out update-inetd from netbase into a new "inetd" package. > No, because e.g. xinetd needs a totally different update-inetd program. > It's simpler if each inetd package will ship its own update-inetd. If I understood correctly, all the update-inetd scripts have to provide for each and every inetd superserver, or at least fill in a list of calls to update-inetd. Why? - Install openbsd-inetd - Install inetd-using server A - replace openbsd-inetd by xinetd - server A was never registered by xinetd ! Instead, all packages should call a common update-inetd minus the last line. This common part registers the arguments for the service under a common format. Then it calls a inetd-specific script that parses those informations, and puts those in the correct form (files in /etc/xinetd.d/, big file in /etc/inetd.conf,...). In the postinst of every inetd superserver, this specific script is also called. In the prerm of the superserver, the inetd-specific files are deleted. I do not see how one can do otherwise, unless every inetd superserver is capable of migrating data from any other superserver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Update: status of inetd
On Aug 30, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote: > Instead, all packages should call a common update-inetd minus the last > line. This common part registers the arguments for the service under a > common format. Then it calls a inetd-specific script that parses those We do not have a new, improved update-inetd. -- ciao, Marco signature.asc Description: Digital signature
ITP: adun.app -- a Molecular Simulator
Package: wnpp Severity: wishlist * Package name: adun.app Version : 0.5 Upstream Authors : Michael A. Johnston, I. F. Galván, Jordi Villà-Freixa * URL : http://diana.imim.es/Adun * License : GNU GPL Description : Molecular Simulator Adun is a new extendible molecular simulation program that also includes data management and analysis capabilities. . Homepage: http://diana.imim.es/Adun -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX -- 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
"Sven Luther" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: 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. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. I think everybody can agree that it would be clearer if the blobs used a licence that clearly allows distribution without requiring source. In the case of the GPL that is definately not clear. About the main issue: As I see it, there are three possible catagories for drivers using firmware that all drivers should ideally fall into assuming the driver part is free : 1. Module and firmware in free. (The firmware can be compiled into the module, or can be loaded from a file.) 2. Module in free, firmware in nonfree, loaded from file by driver. [One could argue that the modules belong ion contrib, unless the firmware is optional (perhaps allowing access to non-essential features)]. 3. Module in non-free. [Firmware compiled into module, has not yet be seperated into seperate file. This is acceptable, but many of these could be converted to type 2 if somebody puts in the work]. I know we have some modules of type 1. I'm pretty sure we have some modules of type 3. It has not been clear to me if we currently have any modules of type 2. Obviously if the infrastucture is not there, that should be fixed. Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 modules. This can definately be fixed, but doing it for etch could delay release. Besides all of that we have quite a few modules with problematic licences. Generally the licence problem is on the firmware, although some might affect the rest of the driver. Some are type-3 style (firmware hard-coded into module, firmware lacking source.)Many of those could be shipped as type-3 modules if licence clarification can be obtained (or preferable: relicencing). A few are type-2 style, they could be shipped as type-2 if proper clarification can be obtained. The above is a rough summer of the problems as I understand it. Please correct be if I am wrong. So the question I have is how long would etch need to be delayed to add support for non-free firmware to D-I? We could also push back the freeze on the kernel by the same amount and have some people work on obtaining clarification on some of the problematic licences. With the combination of those two we could end up with having very few drivers not ship, and all shipped drivers both free and non-free be usable during installation. While pushing Etch back is a big deal, it almost seems to me that some of the proposed GRs are an even bigger deal, and, as has been pointed out, the GRs would probably only make a difference for a small number of modules, unless we ignore the problematic licencing of most of the remaining drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385349: ITP: bazaar-webserve -- allow a bzr branch to be accessed via the web
Package: wnpp
Severity: wishlist
Owner: James Westby <[EMAIL PROTECTED]>
* Package name: bazaar-webserve
Version : Unknown
Upstream Author : Goffredo Baroncelli
* URL : http://goffredo-baroncelli.homelinux.net/bazaar-dev/
* License : GPL
Programming Lang: Python
Description : allow a bzr branch to be accessed via the Web
bazaar-webserve provides both a plugin to bzr, and set of cgi scripts
that allow a bzr branch to be accessed over the Web. It is similar in
intent to websvn and gitweb.
.
It first provides a command ("webserve") to bzr which starts up a
server and receives HTTP requests. It can also work via CGI and so use
a HTTP server to handle the requests.
.
It allows for browsing of the repository, and for browsing through
revisions and viewing diffs between revisions. It can also be
configured to provide a .tar.gz download of a requested revision, and
to allow branching from the hosted branch.
.
Homepage: http://goffredo-baroncelli.homelinux.net/bazaar-dev/
The upstream name of this software is bazaar-webserve, so I am going
with that, but bzr-webserve would fit in better with the rest of the
debian bzr naming scheme.
I have put version unknown as there have not been any releases as such.
I am going to contact the author and ask whether he will be making
releases. If he isn't then I will package appropriately named snapshots.
James
--
James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/
seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385338: wish: dpkg-reconfigure localepurge to select when to run localepurge automatically
CC'ed debian-devel On Wed, Aug 30, 2006 at 04:49:11PM +0100, João Batista wrote: > > I'd like to propose a facility, configurable when running > dpkg-reconfigure localepurge , to allow the sysadmin to select when > localepurge should be run e.g.: > - everytime dpkg/apt is run (default) > - manually > Sorry, but i won't inlude this. It surely sounds like a good idea and all, but all this user friendly configuration facilities are starting to become more than a nuisance for me. It has started to take more time and thought than the main functionality i was primarily interested in. My personal goal with this program has since long been reached and i really don't want to bother about extending it anymore. Actually i was already thinking about ripping out all the debconf facilities and going back to plain old fashioned manual configuration via plain text configuration file. But i can imagine the outcry of the user base, which seems to have grown pretty large by now. Maybe it's time to simply give up on it so that someone else with more time and ambition might want to maintain it for Debian. Any takers? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Deploying configuration as packages
Hi list, For deploying a number of servers at a client's, we've started using package-based configuration. The idea is not new and not complicated: put the local configuration files in Debian packages to deploy them. This answers to the following needs: * simplicity; * ability to deploy only some of the configuration or to generate the configuration depending on the server; * differentiating modifications made by the local administrator from those coming from the deployment tool (as dpkg asks in this case). Other options that come to mind are cfengine, but it is too complex for small or medium-sized installations, or a RCS, but it isn't flexible enough. However not all Debian packages allow such things easily. Packages that split their configuration files, like apache or exim4, allow to ship extra configuration files. Some others allow multiple layers of defaults; for example, one of the reasons for the GConf changes was to allow such packages to be deployed. For other packages, the configuration shipped by Debian has to be replaced. Several options were considered: 1. Customize the configuration files in every Debian package we want to have configured. This works as expected, but it means a lot of work whenever the packages are updated, e.g. for security updates. 2. Ship the packages as provided by Debian, and replace the configuration files by maintainer scripts in specific packages. This is ugly, and leads to dpkg asking whether files should be overwritten when it shouldn't. 3. Strip the packages from their configuration files, and ship the configuration files in specific packages. As the stripping operation can be automated, this is acceptable in production. Option 3 is currently winning, but we'd like to improve things in the future. First question to the developers, what are you using for deploying configuration on your servers? For something more interesting to debian-devel contributors, what could be done to improve the situation? * The first thing that comes to mind is the ability to divert conffiles. This could help a lot to build things around existing packages. Do you think this is realistic? Can this be done with the current conffile architecture in dpkg? * Otherwise, there could be an interface to dpkg for handling special cases, putting conffiles in a different internal state with a specific command. * ... any other ideas are welcome. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Deploying configuration as packages
also sprach Josselin Mouette <[EMAIL PROTECTED]> [2006.08.30.2023 +0200]: > First question to the developers, what are you using for deploying > configuration on your servers? cfengine and puppet > * The first thing that comes to mind is the ability to divert > conffiles. This could help a lot to build things around existing > packages. Do you think this is realistic? Can this be done with > the current conffile architecture in dpkg? no, you will lose data if you try. Arguably this should be fixed. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems "a warm bed in a house sounds a mite better than eating a hot dog on a stick with an old geezer traveling on a lawn mower." -- alvin straight (the straight story) signature.asc Description: Digital signature (GPG/PGP)
Re: Bug#385338: wish: dpkg-reconfigure localepurge to select when to run localepurge automatically
On 30-Aug-06, 12:38 (CDT), Paul Seelig <[EMAIL PROTECTED]> wrote: > CC'ed debian-devel > > On Wed, Aug 30, 2006 at 04:49:11PM +0100, Jo?o Batista wrote: > > > > I'd like to propose a facility, configurable when running > > dpkg-reconfigure localepurge , to allow the sysadmin to select when > > localepurge should be run e.g.: > > - everytime dpkg/apt is run (default) > > - manually > > > Sorry, but i won't inlude this. It surely sounds like a good idea and all, > but all this user friendly configuration facilities are starting to become > more than a nuisance for me. And the desired functionality is easily achieved by removing /etc/apt/apt.conf.d/99-localepurge, right? Debconf is an appriate tool when there is no obvious "correct" answer, but for these 1% options, editing the config file is no burden. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Deploying configuration as packages
* martin f krafft ([EMAIL PROTECTED]) wrote: > also sprach Josselin Mouette <[EMAIL PROTECTED]> [2006.08.30.2023 +0200]: > > First question to the developers, what are you using for deploying > > configuration on your servers? > > cfengine and puppet Are you using both at the same time? Or moving from one to the other? > > * The first thing that comes to mind is the ability to divert > > conffiles. This could help a lot to build things around existing > > packages. Do you think this is realistic? Can this be done with > > the current conffile architecture in dpkg? > > no, you will lose data if you try. Arguably this should be fixed. > -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: bug rates
Joey Hess <[EMAIL PROTECTED]> writes: > I wonder if it would be worthwhile to try to quantify this some more, > by looking at all the RC bugs over a period of time and determining: > > a. What percentage were caused by issues in new uploads. > b. What percentage by transitions. > c. What percentage also affect stable. > > and finding the relative time-to-fix of each of these. d. How many RC bugs are there in stable. e. How many RC bugs from stable are fixed in etch. > -- > see shy jo As a start a thrid line in the RC bug plot for stable bugs might be nice. Just to see how fast RC bugs get discovered post release. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
On Wed August 30 2006 02:52, Subredu Manuel wrote: > Josselin Mouette wrote: > > Le jeudi 17 août 2006 à 11:48 -0400, Anthony L. Bryan a écrit : > > > > Given that downloads like Debian ISOs are already putting a heavy > > bandwidth load on the servers and that they are already shared > > among many servers, I don't think it is a good idea to encourage > > users to load several servers at once with one download. We should > > instead push bittorrent as the main distribution media for ISOs. > > I don't think you got the picture. Metalink can contain information > for download using the following protocols: > *) http > *) ftp > *) bittorrent > *) e2k <...> You seem to be ignoring that metalinker will use multiple protocols, servers, and connections in an effort to get the fastest download. http://www.metalinker.org/Metalink_3.0_Spec.pdf also indicates it will switch servers if the download rate falls, and perhaps even perpetuate old torrents --- which is all great for the client, but will pretty much guarantee worse than possible performance from the servers. It is also not clear what will happen when a release is made and hundreds (thousands?) of clients hit the fastest mirror, whose download rate then drops, prompting all the clients to try switching to the new fastest mirror, whose rate then drops, ... At the very least there will be more overhead traffic for the servers, worst case could be some kind of nasty cyclic oscillations with the server loads which undermines transfer efficiency for everyone. Ya, that's kinda FUDish, but given the newness and limited deployment of the technology, speculation is about all we have to work with. The objective is to ease and spread out the load on the servers; bittorrent and socially engineered access to the less efficient protocols is more likely to do that than bittorrent + ftp + http + multiple servers/client. IMO I think Metalinks are an interesting idea which deserve investigation, but it seems clear they would result in more server overhead and unclear whether the load spreading would offset that or even happen[1]. - Bruce [1] could clients be attracted to a few fast ftp servers and the often slow-to-start torrents end up being underutilized... the exact opposite of what is best for Debian's servers.
Use of dpkg --set-selections is brain-dead?
Hello gurus, I thought I would be slick and write a package that contains a script that will figure out what should be installed/removed/upgraded/etc. on each of the machines where I work. (Using sarge, btw.) I had planned to do this by listing each of the packages and it's install status in a file, then piping that file to 'dpkg --set-selections', and then using 'apt-get dselect-upgrade' to process the new package selections. Unfortunately, this doesn't seem to work as I expected. I've traced my problem down to the use of 'dpkg --set-selections' command. As an example, I have a package named tiem-nis-client-cfg that sets up NIS for generic workstations. If I understand correctly, I should be able to do the following: echo "tiem-nis-client-cfg install" | dpkg --set-selections And then, when I type 'dpkg --get-selections', I should see "tiem-nis-client-cfg install" one some line in the output. Unfortunately, this doesn't seem to work: ~# echo "tiem-nis-client-cfg install" | dpkg --set-selections ; echo $? ; dpkg --get-selections | grep 'tiem-nis-client-cfg' ; echo $? 0 1 The dpkg --set-selections command prints no error, and returns no error code, but tiem-nis-client-cfg isn't set for installation. I know that the package database knows about my tiem-nis-client-cfg, because I can do this: ~# apt-cache show tiem-nis-client-cfg Package: tiem-nis-client-cfg ...blah, blah, blah... And I can install the package by hand: ~# apt-get install tiem-nis-client-cfg Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libslp1 nis Suggested packages: slpd openslp-doc The following NEW packages will be installed: libslp1 nis tiem-nis-client-cfg 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 291kB of archives. After unpacking 1065kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.us.debian.org sarge/main libslp1 1.0.11a-2 [47.3kB] Get:2 http://tortoise sarge/non-free tiem-nis-client-cfg 1.4 [3780B] Get:3 http://ftp.us.debian.org sarge/main nis 3.13-2 [240kB] Fetched 291kB in 0s (293kB/s) Preconfiguring packages ... Selecting previously deselected package libslp1. (Reading database ... 50195 files and directories currently installed.) Unpacking libslp1 (from .../libslp1_1.0.11a-2_i386.deb) ... Selecting previously deselected package nis. Unpacking nis (from .../archives/nis_3.13-2_i386.deb) ... Setting up libslp1 (1.0.11a-2) ... Setting up nis (3.13-2) ... Setting NIS domainname to: tiem.utk.edu Starting NIS services: ypbind [binding to YP server .. backgrounded] (Reading database ... 50289 files and directories currently installed.) Unpacking tiem-nis-client-cfg (from .../tiem-nis-client-cfg_1.4_all.deb) ... Setting up tiem-nis-client-cfg (1.4) ... Setting NIS domainname to: tiem Starting NIS services: ypbind Tell me, oh wise gurus of Debian -- is dpkg just brain-dead? Is the man page horribly wrong/out-of-date? Or what? Confused, Michael Peek -- 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
Joe Smith wrote: > "Sven Luther" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: >>> 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. >> >> A few very vocal people do. I guess they can be counted on the fingers of >> both >> hands or so. Probably less. The people who disagree with this interpretation are contradicting the plain text of the GPL, ignoring copyright law, ignoring the stated intent of the drafters of the GPL and the FSF, etc. As I said, the distributors of this unlicensed material probably *intended* to give it a proper distribution license. Should Debian rely on the assumption of good intentions? Debian doesn't do that for copyright issues in *general*. > I think everybody can agree that it would be clearer if the blobs used a > licence that clearly allows distribution without requiring source. > > In the case of the GPL that is definately not clear. > > > About the main issue: > As I see it, there are three possible catagories for drivers using > firmware > that all drivers should ideally fall into assuming the driver part is > free > : > > 1. Module and firmware in free. (The firmware can be compiled into the > module, or can be loaded from a file.) > > 2. Module in free, firmware in nonfree, loaded from file by driver. [One > could argue that the modules belong ion contrib, unless the firmware is > optional (perhaps allowing access to non-essential features)]. > > 3. Module in non-free. [Firmware compiled into module, has not yet be > seperated into seperate file. This is acceptable, but many of these could > be converted to type 2 if somebody puts in the work]. > > > I know we have some modules of type 1. I'm pretty sure we have some > modules of type 3. It has not been clear to me if we currently have any > modules of type 2. Yes, we do. bluez-firmware and atmel-firmware. > Obviously if the infrastucture is not there, that should be fixed. It's there except for d-i. > Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 > modules. This can definately be fixed, but doing it for etch could delay > release. Right. > Besides all of that we have quite a few modules with problematic licences. > Generally the licence problem is on the firmware, although some might > affect the > rest of the driver. Some are type-3 style (firmware hard-coded into > module, firmware lacking source.)Many of those could be shipped as type-3 > modules if licence clarification can be obtained (or preferable: > relicencing). A few are type-2 style, they could be shipped as type-2 if > proper clarification can be obtained. > > > The above is a rough summer of the problems as I understand it. Please > correct be if I am wrong. That's all correct. > So the question I have is how long would etch need to be delayed to add > support for non-free firmware to D-I? Joey Hess estimated 6 months work, but that was to implement a whole bunch of uncommon special cases. I think it is totally unnecessary to implement all, or even any, of those. http://lists.debian.org/debian-vote/2006/08/msg00122.html For (2) from that post, which is the key sticking point for d-i, it needs to be done anyway, and honestly should not take more than a month if someone bothers. So -- point me to the correct parts of the installer. I don't know where to find this "anna". libdebian-installer I'm looking at -- it would be a great help if someone could direct me to the part of the code which loads udebs from disk/network, because I can't find it. Is that all in 'anna', which I can't find? :-/ If I can't find the source code for 'anna', I can't fix it. (3) is trivial and simply requires the will to fix RC bugs. (4) is frankly not nearly as important as Joey makes it out to be. It is very unlikely that someone will have a machine where *both* the CD *and* the NIC *and* the floppy drive if present *and* the USB driver (USB key) need non-free firmware. As long as there is one piece of hardware with fully free drivers which can be used to load the additional non-free material on the machine, it is perfectly tolerable that an alternate piece of hardware is not so supported. (I've seen systems where the NIC needed non-free firmware downloaded and ones where the CD did, but never ones where both did.) I know it's theoretically possible that someone will buy a "hell machine" where every single peripheral requires a non-free firmware download -- but it's
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Sven Luther wrote: > Since the firmware blobs are not derivative works of the kernel, but > constitute mere agregation in the same binary format, the authors of other > pieces of GPLed code fo the linux kernel cannot even sue us for > distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- 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
Steve Langasek wrote: > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal >> minefield. That is higher priority than the entire discussion going on >> right now, because it determines whether Debian will distribute these 53 >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > liability. It's the domain of the ftp team to determine whether we can > legally distribute a package on our mirrors. Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. I know this is Debian tradition, but it's worth thinking about whether it really makes sense. Debian-legal has very little legal expertise, and as a result the consensus errs on the side of caution at essentially all times with regard to copyright. Probably too much caution, but without getting an actual legal opinion, that seems like the right thing to do. Should the ftpmasters, who have even less legal expertise, ever take the risk of erring on the side of recklessness? (This risk is currently being taken with the mislicensed 'firmware' BLOBs.) Does this expose anyone but the ftp team to legal liability? Now, if the rest of Debian has repeatedly disavowed all responsibility, it may be that the ftp team and only the ftp team are *personally* liable if Debian makes an illegal distribution, and in that case it would make sense for them to determine such things. I'm not sure the ftpmasters are actually comfortatble with assuming personal legal liability for every package in Debian though. I wouldn't be! -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- 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 Wed, Aug 30, 2006 at 08:18:28PM -0400, Nathanael Nerode wrote: > Sven Luther wrote: > > > Since the firmware blobs are not derivative works of the kernel, but > > constitute mere agregation in the same binary format, the authors of other > > pieces of GPLed code fo the linux kernel cannot even sue us for > > distributing the kernel code with those GPL-violating binary BLOBs. > > This is not clear in the cases where the blobs are embedded directly into Please reread the discussion on debian-legal about this, where consensus was mostly found to support this idea, and also remember that we contacted broadcom with this analysis, who contacted their legal team, and i also mailed the FSF lawyers with it, and got no counter-claim to it. > the kernel, particularly when they're embedded in the same source files. > There's a case to be made that this is *not* mere aggregation, but creation > of an enhanced combination work which is derivative of both the firmware > and the other parts of the kernel. Simply putting files side by side is > mere aggregation -- what's happening with the drivers and firmware might be > mere aggregation, but nobody can be sure until a court case happens. Well, in the debian-legal discussion i gave plenty of counter examples, ranging from a firmware flasher (little C program with embedded firmware, exact same case as the kernel situation), to compressed binaries with uncompressing software embedded, passing by filesystem binaries containing both GPLed content as well as non-free content. So, all in all, unless you bring new evidence, there is really very little doubt about this, unless you want to consider your hardware a derived work of the linux kernel, but i doubt a judge will follow you on this one. IANAL, but there is a part of common sense and simple logic in most legal cases. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Deploying configuration as packages
Le mercredi 30 août 2006 à 21:26 +0200, martin f krafft a écrit : > > * The first thing that comes to mind is the ability to divert > > conffiles. This could help a lot to build things around existing > > packages. Do you think this is realistic? Can this be done with > > the current conffile architecture in dpkg? > > no, you will lose data if you try. Arguably this should be fixed. Sure. The question is whether it is realistic to fix dpkg in this matter. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: ITP: adun.app -- a Molecular Simulator
Hi On Thursday 31 August 2006 01:58, Gürkan Sengün wrote: > Package: wnpp > Severity: wishlist > > * Package name: adun.app Maybe I miss some essential parts, but I always wonder why some people add a .app to the software name? Can you please give me a short explanation or point me to a previous thread? Cheers Steffen pgpxBWvNnr2RF.pgp Description: PGP signature
Re: ITP: adun.app -- a Molecular Simulator
On Thu, Aug 31, 2006 at 09:24:21PM +1000, Steffen Joeris wrote: > Hi > > > * Package name: adun.app > Maybe I miss some essential parts, but I always wonder why some people add > a .app to the software name? Can you please give me a short explanation or > point me to a previous thread? > IIRC .app is usually used by apps with gnustep support (e.g. WindowMaker dockapps). It doesn't normally mean they only work on gnustep though, just that they use some features from gnustep, when available. -- GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore signature.asc Description: Digital signature
Re: inet-superserver virtual package
On Wed, 2006-08-30 at 14:22:07 +0200, Marco d'Itri wrote: > On Aug 30, Guillem Jover wrote: > > I'm not convinced that duplicating update-inetd in most of the > > inetd providing packages is a good idea, even if this would allow > > xinetd to be able to replace a normal inetd easily. I'd prefer that the > > odd cases override update-inetd, via a custom script that gets called > > if present from u-i or replace it or whatever. > I can't see why this would be better. Well, if we want to be able to replace any of the inetd with any other one we need a neutral format (as someone else also said in the other thread), this neutral format could be the existing inetd.conf, because the other packages should support already converting from it, so the only thing needed would be to add this hook support to update-inetd for the specific cases where the application does not read the "neutral" format directly. Also because this hook support should imply minimal code, just passing the whole arguments to it if the file is present. > > Also in case the mythical rewrite happens it will be easier to > > coordinate just one instance than all of them, or to sync them if > > people start fixing their instances. > I do not believe this. xinetd and rlinetd need their own versions of > the program anyway, so at best it could be shared by openbsd-inetd and > inetutils-inetd. Coordinating the changes in a 13 KB code base among > 2 or 4 maintainers is easy. This is a fair point, thought there would be way more of those. But consider the above, and if the others have to support the "neutral" format, we may as well share the code, for all of them. > > > netbase then will temporarily depend on inet-superserver to allow smooth > > > upgrades until the other packages will switch to a dependency on the > > > virtual package[1][2]. > > Do you mean only a depedency to the virtual package, w/o a real one? > No. Then I agree here with Roger, that spreading this dependency all over the place makes future changes difficult innecessarily, even if you can consider me biased I'd think the same if the package for this depedency was going to be inetutils-inetd. ;) regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug rates
Joey Hess wrote:
> Steve Langasek wrote (elsewhere):
>> something changes in the archive (often for a transition that needs
>> to happen), a large number of packages are broken by this, and some
>> appreciable number of the maintainers don't respond in a reasonable
>> amount of time ("reasonable" defined as "sufficient to make headway
>> against the RC bug count"; average time to bugfix << average interval
>> between archive-breaking transitions).
>
> I wonder if you have any numbers on this? My gut feeling for a while has
> been that part of what's keeping the RC bug levels in balance is that
> we have a constant stream of RC bugs being filed for issues that are not
> new but have only turned up as things get tested.
Yep.
> A certian percentage
> of these affect stable too. One obvious example is security bugs. It
> seems to me that if you look at the RC bug graph, most of the sharp
> spikes and dips are due to the kind of transitional RC bugs you're
> talking about, which says that we do pretty well at dealing with those,
> at least for significant transitions that cause a lot of similar bugs.
>
> One of my problems with our current release process is that it doesn't
> seem to take into account the bugs that exist in stable. By the current
> metrics we could easily be in a position today where testing has many
> fewer RC bugs than stable, but still be far from a release. And even if
> we get the RC bugs to zero and make a release, that release will have
> many undiscovered RC bugs which will turn up later.
Yep.
> That makes it hard
> for me to worry about bringing the count down to zero, since it's really
> just pushing the iceberg underwater for an instant.
Yeah, I think you have a good point here.
Personally, I would prioritize RC bugs which apply to "key" packages
-- the benefit from getting those RC-bug-free is
larger than that of getting other packages RC-bug-free. Unfortunately,
some vital packages like the toolchain packages and the kernel have some of
the oldest and most irritating RC bugs. Licensing
> I wonder if it would be worthwhile to try to quantify this some more,
> by looking at all the RC bugs over a period of time and determining:
>
> a. What percentage were caused by issues in new uploads.
Weirdly, these are often the quickest to be fixed. Exceptions: Bugs
caused by large upstream changes; bugs in packages with inactive
or inattentive maintainers.
> b. What percentage by transitions.
Gah, probably most of them. Time-to-fix is weird for transitions; most
packages are fixed very quickly, and then there's a long tail, primarily
caused by inactive maintainers. Amaya's been working on finishing up
some of those long tails, as have I. Mostly they don't get finished.
> c. What percentage also affect stable.
I try to versiontag for this. This should be a detectable quantity now,
thanks to versiontagging. These, oddly (or perhaps not so oddly) are
often the ones which take the longest to fix. However, they're also where
I put my priorities, because long-standing bugs are substantially more
annoying than new bugs.
A release where we fixed all the (discovered and undiscovered) RC bugs from
the *previous* release would be a very successful release. :-)
> and finding the relative time-to-fix of each of these.
--
Nathanael Nerode <[EMAIL PROTECTED]>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
--
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
Toni Mueller wrote: > > > Hello, > > On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: >> 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. Marco trolled again. FYI, no serious person disagrees with this interpretation. >From the GPL: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Debian is not doing this for the BLOBs b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Debian is not doing this for anything c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) -- Debian is not allowed to do this So Debian isn't satisfying the conditions of clause 3. Therefore, the GPL does not grant Debian permission to distribute the BLOBs in object code or executable form. > I'm not a lawyer, but my take on this is that if someone ships you a > BLOB under the GPL, you have the legal right to demand sources from > him. Unfortunately not. Generally, only a copyright holder can sue for GPL violation. (In contrast, Debian's Social Contract promises that Debian will distribute source code for all the programs in Debian -- so under common law I could sue Debian for false advertising because it isn't distributing source code for some of the programs.) *However*, consider the following case: (1) The driver is written by person A and released properly under the GPL. (2) The firmware is written by corporation B and distributed without source. (3) Either B or person C combines the firmware with the driver to make a single work, and distributes it -- without the source for the firmware. In this case, person A can sue any distributor of the combined work. Arguably, any contributor with copyright in any part of the Linux kernel might be able to sue any distributor of a kernel with firmware in it. Some of the contributors to the kernel are very vociferously against sourceless firmware, and might actually do it. Dropping -vote, setting followups to -legal. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- 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 Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal > >> minefield. That is higher priority than the entire discussion going on > >> right now, because it determines whether Debian will distribute these 53 > >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > > liability. It's the domain of the ftp team to determine whether we can > > legally distribute a package on our mirrors. > Actually, letting an overworked team of four with (to my knowledge) zero > legal expertise settle questions of legal liability is pretty absurd too. They are the team responsible for vetting the legality of what's distributed on the mirrors. None of them have any legal expertise to my knowledge; but they do know where the lawyers are if they have questions, and they *are* the ones in the hot seat(s). > Should the ftpmasters, who have even less legal expertise, Judging by some of the nonsense that debian-legal is typically riddled with, if I were an ftpmaster I would find that claim insulting. The only claim to expertise that debian-legal has is in the area of analyzing license terms and how they stack up against the requirements of the DFSG. That is an important function, but it is *not* legal expertise. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: adun.app -- a Molecular Simulator
On Wed, 30 Aug 2006 22:12:04 -0400, Daniel Dickinson <[EMAIL PROTECTED]> said: > On Thu, Aug 31, 2006 at 09:24:21PM +1000, Steffen Joeris wrote: >> Hi >> >> > * Package name : adun.app >> Maybe I miss some essential parts, but I always wonder why some >> people add a .app to the software name? Can you please give me a >> short explanation or point me to a previous thread? > IIRC .app is usually used by apps with gnustep support (e.g. WindowMaker > dockapps). It doesn't normally mean they only work on gnustep though, > just that they use some features from gnustep, when available. To clarify, ".app" is generally used by GNUstep programs, and for some dockapps. Dockapps that are not written specifically for GNUstep don't use GNUstep features at all, and those that use GNUstep features rely on GNUstep. I am not aware of any that don't rely on GNUstep, but that use GNUstep features when present. There seems to be only a handful of dockapps that use ".app", though, so if you see a package that says ".app", chances are that it's a GNUstep program. And nearly all GNUstep programs say ".app". The ".app" comes from the NeXT nomenclature of programs. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- 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
[Nathanael Nerode] > So -- point me to the correct parts of the installer. I don't know > where to find this "anna". svn://svn.debian.org/d-i/trunk/packages/anna signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: >> Actually, letting an overworked team of four with (to my knowledge) zero >> legal expertise settle questions of legal liability is pretty absurd too. > > They are the team responsible for vetting the legality of what's > distributed > on the mirrors. None of them have any legal expertise to my knowledge; > but they do know where the lawyers are if they have questions, Well, that's good! Do they really have the hotline to the lawyers? Excellent! I hope they actually use it occasionally; I've never heard of them doing so, so if they have gotten any legal opinions, they've kept them secret. (Dammit, when Debian developers attempted to get legal advice on trademark policy, it sunk into a black hole. The advice never really came back, after several years.) > and they > *are* the ones in the hot seat(s). Meaning that they are personally liable and the rest of the Debian developers aren't? :-) I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. It seems to me that the developers have entrusted the ftpmasters with the responsibility of guarding Debian's funds and property against a copyright infringment lawsuit. Is that the general feeling of the developers? Are the ftpmasters comfortable with that responsibility? If so, my proverbial hat is off to them. >> Should the ftpmasters, who have even less legal expertise, > > Judging by some of the nonsense that debian-legal is typically riddled > with, if I were an ftpmaster I would find that claim insulting. There is at least one laywer who posts regularly. Which counts as some legal expertise, and which is exactly what I was referring to when I said "very little". > The only claim to expertise that debian-legal has is in the area of > analyzing license terms and how they stack up against the requirements of > the DFSG. That is an important function, but it is *not* legal expertise. See above. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Sass wrote: > > You seem to be ignoring that metalinker will use multiple protocols, > servers, and connections in an effort to get the fastest download. > http://www.metalinker.org/Metalink_3.0_Spec.pdf also indicates it will > switch servers if the download rate falls, and perhaps even perpetuate > old torrents --- which is all great for the client, but will pretty > much guarantee worse than possible performance from the servers. > > It is also not clear what will happen when a release is made and > hundreds (thousands?) of clients hit the fastest mirror, whose download > rate then drops, prompting all the clients to try switching to the new > fastest mirror, whose rate then drops, ... At the very least there > will be more overhead traffic for the servers, worst case could be some > kind of nasty cyclic oscillations with the server loads which > undermines transfer efficiency for everyone. Ya, that's kinda FUDish, > but given the newness and limited deployment of the technology, > speculation is about all we have to work with. When a new release is made, all servers (and mirrors) are getting hit. First, the tier 1 (ftp..debian.org), and then the other mirrors. So, if you only consider http and ftp, metalink is the logical choice, since it switches automatically to a new server, when the rate drops (at least, it should, but this depends on the client). The only situation in which you can save the servers bandwidth is when you use download protocols that involves the users bandwidth, like bittorrent, edonkey and other specifica file sharing protocols. So, there are 2 situations here: *) make .torrent files *) make .metalinks files only with bittorrent, e2k protocols and magnet urls You can see that metalink has advantage over bittorrent simply by having bittorrent _and e2k_ :) > > The objective is to ease and spread out the load on the servers; > bittorrent and socially engineered access to the less efficient > protocols is more likely to do that than bittorrent + ftp + http + > multiple servers/client. IMO ok. then use metalink only with bittorrent and e2k links :) I only try to convince you that using this technology is just a very big advantage for the average joe. > > I think Metalinks are an interesting idea which deserve investigation, > but it seems clear they would result in more server overhead and > unclear whether the load spreading would offset that or even happen[1]. Sure. I'm not saying that it should be adopted as once, without further investigation and tests. But is not something that should be ignored just because is new. I'm only saying that metalink deserves a change. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9oFgjGXbUSvc3AsRAgwnAJ4igHthjnvH4K6MqoiEggwc1levcgCeKsNZ KpOGY4jRTx40t54xgzGIsrE= =pChm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
