Problems to upload
Hi, did something changed in the upload queue?: $ dput *.changes Uploading package to host ftp-master.debian.org ... Good signature on /home/tillea/debian-maintain/sponsor/dosbox/dosbox_0.63-2.dsc. Uploading via ftp dosbox_0.63-2.dsc: Error '553 Could not create file.' during ftp transfer of dosbox_0.63-2.dsc Traceback (most recent call last): File /usr/bin/dput, line 909, in ? main() File /usr/bin/dput, line 858, in main progress=config.getint(host,'progress_indicator')) File /usr/share/dput/ftp.py, line 54, in upload f, 1024) File /usr/lib/python2.3/ftplib.py, line 415, in storbinary conn = self.transfercmd(cmd) File /usr/lib/python2.3/ftplib.py, line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File /usr/lib/python2.3/ftplib.py, line 327, in ntransfercmd resp = self.sendcmd(cmd) File /usr/lib/python2.3/ftplib.py, line 241, in sendcmd return self.getresp() File /usr/lib/python2.3/ftplib.py, line 214, in getresp raise error_perm, resp ftplib.error_perm: 553 Could not create file. $ dupload *.changes dupload note: no announcement will be sent. Uploading (ftp) to ftp-master.debian.org:/pub/UploadQueue/ [ job dosbox_0.63-2_i386 from dosbox_0.63-2_i386.changes dosbox_0.63-2.dsc, md5sum ok dosbox_0.63-2_i386.deb, md5sum ok dosbox_0.63-2.diff.gz, md5sum ok dosbox_0.63-2_i386.changes ok ] Uploading (ftp) to anonymous-ftp-master (ftp-master.debian.org) [ Uploading job dosbox_0.63-2_i386 dosbox_0.63-2.dsc 0.9 kBdupload fatal error: Can't upload dosbox_0.63-2.dsc: YOU MUST USE PASSIVE MODE. Type: passive at /usr/bin/dupload line 506 $ dupload --to erlangen *.changes dupload note: no announcement will be sent. Uploading (ftp) to ftp.uni-erlangen.de:/public/pub/Linux/debian/UploadQueue/ [ job dosbox_0.63-2_i386 from dosbox_0.63-2_i386.changes dosbox_0.63-2.dsc, md5sum ok dosbox_0.63-2_i386.deb, md5sum ok dosbox_0.63-2.diff.gz, md5sum ok dosbox_0.63-2_i386.changes ok ] Uploading (ftp) to erlangen (ftp.uni-erlangen.de) [ Uploading job dosbox_0.63-2_i386 dosbox_0.63-2.dsc 0.9 kBdupload fatal error: Can't upload dosbox_0.63-2.dsc: YOU MUST USE PASSIVE MODE. Type: passive at /usr/bin/dupload line 506 When trying manual ftp I found out that dosbox_0.63-2.dsc was put to master but with zero bytes and I'm not allowed to remove this file. Kind regards Andreas. -- http://fam-tille.de
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 04:59:15PM -0600, Dirk Eddelbuettel wrote: On Thu, Dec 16, 2004 at 11:34:55PM +0100, Ingo Juergensmann wrote: Although the problem is well known and the solution is obvious, nobody seems to have the guts to make a change (or even to speak about it). Let's have a discussion about reducing our number of architectures. The number of archs introduces some additional work, true, but it's usually no showstopper. Attempting to support several thousand binary packages on a dozen architectures across three release flavours imposes a large cost (see e.g. Joey Hess' recent blogging about the increased sysadmin work he has to do so that he can test d-installer). Of course, when you do such things as a new installer, you have additional work in porting it. Another choice would have been to use old boot-floppies on those archs that are not that well supported by d-i. But it was a decision made by someone that all archs should use the new d-i. Complaining afterwards that your own decision puts some more work on you is somewhat strange, eh? So we know the costs. Can we quantify the benefits? In http://blog.bofh.it/id_66, Marco showed these numbers of downloads at the Italian site: architecture files downloaded i386 1285422 all504789 powerpc17754 ia64 10111 sparc 3336 arm850 alpha 507 hppa 204 mipsel 91 m68k 15 mips 7 s390 4 total 1823090 AFAIK this data has not been refuted. So, let's begin with throwing out s390 and mips... Clearly, for informed decision we'd need more data, from more hosts and over longer periods. How about number of installed packages? Another funny statistic: 5280 : mipsel 5428 : mips 5482 : alpha 5514 : hppa 5538 : arm 5546 : s390 5565 : powerpc 5578 : m68k 5593 : sparc 5601 : ia64 5680 : amd64 5973 : i386 We could argue that the low numbers of the users in popcon might be caused by the low number of available packages. So, throw out mipsel, mips, alpha, hppa, arm, s390 and powerpc. But it would be nice if we based this discussion on /measurable usage/ of Debian to complement the costs with actual benefits -- as opposed to hypotheticals (such as compiling thousands of packages for arches without actual users). I know you and Marco are great haters of m68k co, just because you sometimes need to wait one or two days longer for your package. But may I remind you on the qt-x11-free story from the begin of this year on mipsel? That was a great blocker for about 70 other packages caused by a ignorant buildd admin. As it stands, 4 downloads for s390 appear somewhat disproportionate to 1,285,422 for i386. As always for statistics, they mean nothing without a proper interpretation - and how you interprate the data is totally up to you. For me, it only shows that there are not many s390s in Italy or they don't use the italian mirror for whatever reasons or they don't update their systems that often because they run stable instead of unstable as many of the i386 users do. How about solving the problems that exists and where the solution doesn't punish our users (or maintainers)? -- Ciao... // Ingo \X/
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
Wouter Verhelst wrote: I don't know what the essense of Free Software is to you; You do so. I created the DFSG. It defines what the essense of Free Software is not only to me but to this project. However, to me, the essense of Free Software is that it allows one to modify the software as one sees fit. Remove that ability, and I don't see the software as Free anymore. You never lose the right to modify. You lose the right to claim that a modified version is the certified one. I addressed this specifically in DFSG section 4: The license may require derived works to carry a different name or version number from the original software. At the time, there was an "Official" version of ABIWord sanctioned by ABISource, and any modified version would be unofficial and had to bear a different name, and DFSG #4 was written specifically to allow that sort of uses. This is certainly a form of certification. Indeed, Debian makes use of similar certification for its Official CD. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 11:10:15PM -0500, Joey Hess wrote: Jay Berkenbilt wrote: I've sent messages to various [EMAIL PROTECTED] addresses many times for various reasons, and they have all always been ignored. Me too, for values of ignored that include may have resulted in some action, but never got a reply email. I think that we need BTS pseudo-packages for the autobuilders. Why? To make it public what buildd admins are the worst? I think we all already know who those people are... -- Ciao... // Ingo \X/
Re: Problems to upload
On Fri, Dec 17, 2004 at 07:50:16AM +0100, Andreas Tille wrote: $ dput *.changes Uploading package to host ftp-master.debian.org ... Good signature on /home/tillea/debian-maintain/sponsor/dosbox/dosbox_0.63-2.dsc. Uploading via ftp dosbox_0.63-2.dsc: Error '553 Could not create file.' during ftp transfer of dosbox_0.63-2.dsc Traceback (most recent call last): File /usr/bin/dput, line 909, in ? main() File /usr/bin/dput, line 858, in main progress=config.getint(host,'progress_indicator')) File /usr/share/dput/ftp.py, line 54, in upload f, 1024) File /usr/lib/python2.3/ftplib.py, line 415, in storbinary conn = self.transfercmd(cmd) File /usr/lib/python2.3/ftplib.py, line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File /usr/lib/python2.3/ftplib.py, line 327, in ntransfercmd resp = self.sendcmd(cmd) File /usr/lib/python2.3/ftplib.py, line 241, in sendcmd return self.getresp() File /usr/lib/python2.3/ftplib.py, line 214, in getresp raise error_perm, resp ftplib.error_perm: 553 Could not create file. When trying manual ftp I found out that dosbox_0.63-2.dsc was put to master but with zero bytes and I'm not allowed to remove this file. See the dcut command (or the README file in UploadQueue) for information on how to remove broken files from the ftp server. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL and LGPL issues for LCC, or lack thereof
Michael K. Edwards wrote: What part of "normally distributed ... with ... the operating system" is confusing? The license requires that the source code all of the pieces that constitute a derivative work of some original piece of GPL code must be provided. This would be the original GPL program and the scripts used to build it, and any other code you link into it and the scripts used to build that. The build tools are separate works that never become derivative of the GPL program. Concievably a contract could require that you specify the build system, but the GPL doesn't purport to be a contract. It is designed to only grant rights, not restrict any rights that you would otherwise have. This also side-steps the issue of consent. I will grant you that this clause was written in the days that commercial operating systems shipped with the C compiler bundled That section is specifically addressing the libraries that are actually linked into the work, and thus become part of a derivative work containing the GPL code. Back when all GPL code was developed on Sun, we had a non-free C library. That's the piece that came with the compiler and the OS for which we had to make an exception. At first blush, I would expect "distribute ... under terms of your choice" to refer to the entire contract between "licensor" and "licensee" (if we are talking about software that is "licensed" and not sold; the common-law contract between seller and buyer is a whole different animal). If that contract includes a support clause, and the support clause does not permit modification of the work without loss of some of the economic benefits of the contract, then one could argue that this "exception" (from the requirement to offer source as per the GPL) should not apply, and that the distributor must either offer source or refrain from distributing the LGPL material. This issue was researched very thoroughly by Moglen and Ravicher for FSF (who you can ask), and others, in regard to the Red Hat service contract. That may violate the spirit of the GPL, but it turns out not the letter, because the offering of service is outside of the scope of the license. [Long analysis of Sun case deleted] The Sun Java license granted to Microsoft included a restriction on the creation of derivative works: they were required to conform to, and not extend, Sun's published Java standard. The mention of "intersection of copyright and contract law" is an observation that isn't really connected with the finding that the irreperable harm was entirely within the domain of copyright law. And the finding contradicts the purpose for which you quoted the whole thing. It's very interesting to note that the (L)GPL is explicit about revoking the contractual license There's no contract. It revokes a copyright permission. Yet it creates a contract-law obligation of continued performance on the distributor's part, so long as the distributor owes continued performance (such as technical support) under the terms of its license with the recipient of the bundled components. There is no language in the license that would do this and no law that would imply it. I'm not sure whether to take you seriously or not. Your reading of these licenses is so far off that I wonder if you're just playing with me to see if I can actually find the flaws in your argument. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 11:10:15PM -0500, Joey Hess wrote: Jay Berkenbilt wrote: I've sent messages to various [EMAIL PROTECTED] addresses many times for various reasons, and they have all always been ignored. Me too, for values of ignored that include may have resulted in some action, but never got a reply email. I think that we need BTS pseudo-packages for the autobuilders. I'm not sure that would help much; indeed, in the common case (package needs a simple requeue, buildd admin would have taken care of it in due course anyway, sender isn't worried about a lack of reply as long as things are fixed), it would seem to impose a lamentable amount of overhead -- time that could otherwise be spent on the never-ending task of buildd/port maintenance. The BTS overhead is justified for packages, since any developer can NMU a package; as long as the buildds for most ports are one-maintainer-per-arch, I don't see that having a list in the BTS of packages to be requeued gives us anything over the present situation. In the case of mails sent to arch@buildd.debian.org about issues that go unfixed for long periods, it would be nice to know what the story is. And personally, since I send a lot of these mails about packages with RC issues, I think more feedback from the buildd maintainers would help me to know better when these emails are helpful and when they're a distraction; but in the absence of feedback, I'll continue to assume my current approach is ok... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
[Ingo Juergensmann] Why? To make it public what buildd admins are the worst? To make public the requests made regarding the autobuilders (others can see existing requests, and do not have to send identical requests again), and to make sure the state of each request is available both to the requestor, the buildd admin and the public. It might make the buildd request handling more transparent. After all, it is an official service in Debian, and someone should always give replies to the requests sent to its maintainers.
Re: Problems to upload
On Thu, 16 Dec 2004, Steve Langasek wrote: See the dcut command (or the README file in UploadQueue) for information on how to remove broken files from the ftp server. I do not find the string dcut in ftp://ftp-master.debian.org/pub/UploadQueue/README but the *.commands file would probably help as well. But what me *really* concerns is why dput and dupload failed in the first place. Especially the hint to PASSIV MODE smells like something has changed to the situation before. I do not know something about passive mode but I'm afraid somebody has changed something at our firewall which resulted in problems with FTP protocol. Kind regards Andreas. -- http://fam-tille.de
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
On Fri, Dec 17, 2004 at 08:51:52AM +0100, Petter Reinholdtsen wrote: [Ingo Juergensmann] Why? To make it public what buildd admins are the worst? To make public the requests made regarding the autobuilders (others can see existing requests, and do not have to send identical requests again), and to make sure the state of each request is available both to the requestor, the buildd admin and the public. As Steve already stated, it might put some extra load on those people. Beside that I think that they wouldn't care at all about those bugs - as they do right now about answering emails to let the maintainers know what's happening (or not). Anyway, I think that it would be a good idea to have somewhere a place where people can check whether a problem with the buildds is already reported or not. But I guess a simple archive on the web should do this as well. No need for a BTS... It might make the buildd request handling more transparent. After all, it is an official service in Debian, and someone should always give replies to the requests sent to its maintainers. Shouldn't that be the case with the DAM, ftp-masters, etc. as well? Ooops, wasn't there last year a big flamew^Wthread about some peoples communication skills? Deja-vu? ;-) -- Ciao... // Ingo \X/
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
On Thu, Dec 16, 2004 at 11:01:16PM -0800, Bruce Perens wrote: You never lose the right to modify. You lose the right to claim that a modified version is the certified one. I addressed this specifically in DFSG section 4:/ / /The license may require derived works to carry a different name or version number from the original software./ At the time, there was an Official version of ABIWord sanctioned by ABISource, and any modified version would be unofficial and had to bear a different name, and DFSG #4 was written specifically to allow that sort of uses. This is certainly a form of certification. Indeed, Debian makes use of similar certification for its Official CD. Indeed; however, IMO excerting the right to modify as defined by the DFSG should never result in the loss of support, or other negative consequences, because in that case you might as well not have it. This type of certification does carry that kind of negative consequence. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Linux Core Consortium
Op do, 16-12-2004 te 17:07 -0800, schreef Adam McKenna: On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote: I think Wouter is only asking for reciprocity here. If they don't care about his concerns why should he care about theirs ? Or alternatively not caring is a freedom. We care because our priorities are our users and free software. Just because someone works for an ISV or develops on/for proprietary software does not make them a second class user. That said, I am not arguing for or against LCC, I just didn't like the tone of Wouter's e-mail, or the sentiment implied in it. I did not intend that sentiment; I explained what I meant to say in a new thread. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Linux Core Consortium
On Dec 16, Wouter Verhelst [EMAIL PROTECTED] wrote: I refuse to accept that 'providing a common binary core' would be the only way to fix the issue. It is probably the easiest way, and for lazy people it may look as if it is the only one; but we should not dismiss the idea that it is possible to fix the Free software or the standard so that the LSB /will/ work. Agreed. Certifying binaries is simply not acceptable. -- ciao, | Marco | [9856 dojTFydnOyWkk] signature.asc Description: Digital signature
Re: LCC and blobs
Brian Thomas Sniffen wrote: Peter Van Eynde [EMAIL PROTECTED] writes: And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite You name is software! Now I'm a Common Lisp hacker, you know the data is code people, but even _we_ do not consider a string software unless it drives some software. Is your name input for a state-machine? Architectural plans for a house, shipped in a Debian package, are software. I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? And you restrictions that any package that depends on non-DFSG software to work cannot be in main means that after releasing sarge we have to remove from main: - all bootloaders. Grub cannot start my XP without the XP bootsector. - tftpd. I want to netboot my Solaris machines. The tftpd needs the solaris code to work. - all font renderers. I want to see a document with the font I bought, and without it the document is broken, so the renderer needs the font, right? - all interpreters. I want to run HACMP. It is in perl, so the perl is useless to me without HACMP. - the kernel. I want to ship a stripped down debian with my non-DFSG code in an embedded system. The kernel is useless without my code, so the kernel cannot be in main. Should I go on? Groetjes, Peter
Re: LCC and blobs
On Fri, Dec 17, 2004 at 09:53:51AM +0100, Peter Van Eynde wrote: I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? And you restrictions that any package that depends on non-DFSG software to work cannot be in main means that after releasing sarge we have to remove from main: [Several rather absurd overgeneralisations] Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. - Matt signature.asc Description: Digital signature
Re: LCC and blobs
Brian Thomas Sniffen wrote: Some firmware is part of the hardware. Some isn't. It's easy to tell -- either it's in the hardware or it isn't. Of course, the name firmware should make it clear that this is an often ambiguous line. But this does seem to be a good practical place: can anybody with the device and the driver use it? Or are there some people who even with a functioning, complete device and a driver who can't get it to work? This is not only a feature of a device with firmware. Some hardware you cannot buy, you only get a license to use it. If I remember correctly you never buy an EMC, you only get permission to use it and have to pay every year to continue to use it. So you want to rip out all fiber-channel drivers because they might be used to connect to an EMC? I see no limitation of my freedom in using firmware. Please tell me how I am limited in my freedom. If I wanted a open source firmware I could buy a device with open firmware, Then Windows isn't proprietary either. Sigh. It is, but does the fact that I can boot it with grub limit my freedom? Groetjes, Peter
Re: Default gcc for sarge, libunwind
Frank Lichtenheld [EMAIL PROTECTED] wrote: The libunwind issue is newer, you probably just have to read the corresponding bug reports. Which bugs? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Default gcc for sarge, libunwind
Steve Langasek [EMAIL PROTECTED] wrote: On Thu, Dec 16, 2004 at 08:13:31PM +0100, Adeodato Simó wrote: [quoting me, Frank] Secondly, I'd like to learn what this libunwind is about and why tetex-bin is linked against it on some (many!) arches, but not on i386. The package description wasn't really helpful there. nfi about this, sorry. This is not many, or even some; there is precisely one architecture which includes libunwind7, ia64, where AIUI this library plays a role in being able to properly debug program call stacks. I was fooled by the fact that http://bjorn.haxx.se/debian/testing.pl?package=tetex-bin lists all architectures as problematic where gcc-3.4 has not yet been built, and overlooked that this doesn't mean tetex-bin depends on libunwind on all these arches. Why this library was suddenly deemed critical for the architecture after we were already 3 months into a toolchain freeze is another question. This I'd like to know, too FWIW, these questions seem more appropriate to debian-devel than debian-mentors; these are not what I would call novice packaging questions. :) When I asked the first question, I expected to turn out to be just a big misconception of mine. Well, moving to debian-devel, and Cc-ing Matthieu and Al, libunwidn maintainers. TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
Joey Hess [EMAIL PROTECTED] wrote: Jay Berkenbilt wrote: I've sent messages to various [EMAIL PROTECTED] addresses many times for various reasons, and they have all always been ignored. Me too, for values of ignored that include may have resulted in some action, but never got a reply email. Hello, To balance this a little bit: My range of reaction includes immediate response and response after one day, and may have resulted in some action, but never got a reply email is the usual response for specific buildd addresses, no reaction happens rarely. I think that we need BTS pseudo-packages for the autobuilders. Isn't this trying to solve a social problem with technical means and therefore doomed to fail? - This'd try to force people to send mails to the bts instead of to you. (Probably with the same results.) Something better integrated into the buildd-network than a pseudo-package in the Debian BTS might work. The simple act of rescheduling would close the bug. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash http://downhill.aus.cc/
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard wrote: Hmm. A few places to draw the dependency from driver to firmware line seem to be: 1: a dependency exists if the driver needs access to a copy of the firmware (for devices that need the firmware uploaded on every boot); 2: a dependency exists if the hardware needs firmware at all; There is no way to determine if a device that needs a initialisation sequence is in the first or in the second part. The sequence might just be a safeguard against accidental activation, or it might patch the firmware. For instance if you start an wifi device it has to know your country. Is this just used to configure the device or is it used to patch the firmware so it does not have to do lookups all the time? We cannot know. Groetjes, Peter
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
On Fri, Dec 17, 2004 at 10:03:00AM +0100, Wouter Verhelst wrote: On Thu, Dec 16, 2004 at 11:01:16PM -0800, Bruce Perens wrote: You never lose the right to modify. You lose the right to claim that a modified version is the certified one. I addressed this specifically in DFSG section 4:/ /The license may require derived works to carry a different name or version number from the original software./ At the time, there was an Official version of ABIWord sanctioned by ABISource, and any modified version would be unofficial and had to bear a different name, and DFSG #4 was written specifically to allow that sort of uses. This is certainly a form of certification. Indeed, Debian makes use of similar certification for its Official CD. Indeed; however, IMO excerting the right to modify as defined by the DFSG should never result in the loss of support, or other negative consequences, because in that case you might as well not have it. This type of certification does carry that kind of negative consequence. But this happens all the time in all kinds of situations (think Red Hat RHEL support vs. Fedora, or even users reporting bugs to the Debian BTS about backported packages), and is perfectly valid under the DFSG -- even if we don't want to be put in this situation by ISVs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard [EMAIL PROTECTED] wrote: On Thu, Dec 16, 2004 at 10:51:39AM +0100, Frank Küster wrote: When the issue of binary blobs in the kernel was first discussed here, if I'm not mistaken the proposed solution was to rewrite the respective drivers to be able to load the blob at runtime from somewhere, and that somewhere would then be populated from non-free or an external source. And it was said that if the hardware device generally works without firmware loading, just with worse performance, or if most devices supported by the driver worked without, and just a minority depended upon it, then the driver (the kernel module or monolitic kernel) would be Free. Just to be a little clearer: drivers that require non-free firmware, but are under a Free license, are Free. Software which is not Free always goes in non-free. Software that is Free goes in either main or contrib. The active question, here, is not whether these drivers are Free; we're assuming they're Free, and asking whether they should go in main or contrib due to the firmware being non-free. Thanks, I really wasn't clear about that. But the question is still the same: If the procedure described above was regarded as sufficient to keep distributing the kernel in main, why must a userland tool that does essentially the same (AFAICT) go to contrib? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: LCC and blobs
Raul Miller wrote: Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. The API is known, otherwise there would be no Linux driver. The fact that we uploaded the firmware does not excuse the device from respecting its API. Nor is it our task to write the firmware, Debian is a distribution for general-purpose computers, if you want to have a distribution for firmware you are free to do so. Debian should consider hardware as things that you have to talk to with a certain protocol. [hardware with build in flash that lost the flash] However, unlike non-flash devices that need the firmware uploaded every time, the driver is still useful without it. Yes. It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? Groetjes, Peter
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard [EMAIL PROTECTED] wrote: On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: No, there's a very concrete reason: given an installation of Debian main, the driver works. Drivers that require non-free firmware don't work out of the box; The vast, vast majority of drivers require non-free firmware. Hmm. A few places to draw the dependency from driver to firmware line seem to be: No, that's not what you said. There's some room to quibble over whether a dependency exists - there's no room to quibble over whether a requirement exists. Almost all modern hardware either contains firmware or requires firmware to be uploaded. Therefore, almost all drivers require firmware, since otherwise the hardware they drive would not exist. Please, let's be honest about what requirements software has. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 02:37:09PM -0500, Ian Murdock wrote: On Tue, 2004-12-14 at 18:15 +0100, Tollef Fog Heen wrote: This sounds a bit like the government whose country had three different types of power plugs. None compatible, of course. Somebody then got the great idea that if they invented another one to supersede the three plugs in use (since that caused overhead). That country now has four plugs in use. Actually, it's more like the country that has a few dozen different types of power plugs, and they're all so minutely different from each other that the consumer has no idea why it's like that, only that if he buys something that requires electricity, he can only use what he buys in 50% of the places that have electrical power. Also, the differences are small enough that he *might* be able to plug in what he has bought in some of the other places, but he's never sure if or when the thing he plugs in will blow up. Three of the six makers of the most common plug types then get together, realize the stupidity of the current situation, and decide to correct it. At the very worst, there are two fewer plug types. At the very best, the dozens of others gradually disappear too. The end result is that consumers can now buy electrical equipment that work in more places. s/power plugs/Windows service packs/ Wait... what was the ISVs' argument against having to test their software on multiple slightly-incompatible distros again? ;-) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: LCC and blobs
Matthew Palmer wrote: Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. Ok. I'm game. Why? Where is the error my in applying your rules? Groetjes, Peter
OSPF and distance vector routing source code
hello, Would you please tell me how can I get source code for OSPF and distance vector ? It would be of great help to me , if u can send me some address relatedto linux based systems and of socket programming type. Regardsj.s dhilip chandran Yahoo! India Matrimony: Find your life partner online.
OSPF and distance vector routing source code
hello, Would you please told me how can I get source code for OSPF?Regardj.s dhilip chandran Yahoo! India Matrimony: Find your life partner online.
Re: Bug#286027: ITP: ms-sys -- tool for writing Microsoft compatible boot records
On Thu, Dec 16, 2004 at 09:21:03PM -0600, Graham Wilson wrote: This is a Linux program for writing Microsoft compatible boot records. The program does the same as Microsoft fdisk /mbr to a hard disk or sys d: to a floppy or FAT partition except that it does not copy any system files, only the boot record is written. Where is the included boot block code from? According to the author's page it's taken from: http://www.geocities.com/thestarman3/asm/mbr/MBR_in_detail.htm I'd also like to point out that the boot block source code is not included, certainly making this package non-DFSG-free, and probably making it undistributable by us under the GPL. Boot blocks are included as a series of properly ordered bytes, so yes... seems that it's not DFSG free. Don't know however if it makes it totally undistributable. Author chose GPL and it's his decision. You can always change those boot blocks by changing bytes listings. Anyway... if it's impossible to put it in non-free then I'm going to close that bugreport. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: removing in postrm rc*.d symlinks that I did not create
It has been suggested that you install symlinks[*] but provide an /etc/default/foo file with an environment variable that forcibly disables the service when set to off or whatever, and that the initscript be written so that it overrides this forced disabling when run from the command line. Of course this can be made to work but it is a bad hack. Bad because it doesn't use Debian's standard mechanism for configuring services. The idea behind initscripts is that they do what they are told when they are run. sysv-rc and file-rc implement two different schemes for determining when they are run and with what arguments. I don't see why people keep trying to undermine the standard mechanism. Under the circumstances you describe it is reasonable to refrain from installing symlinks[*] in runlevel directories. I think you are justified in deleting the symlinks on purge too, so I suggest you simply override lintian and linda. [*] (or do the file-rc equivalent, which happens automatically if file-rc is installed because you use update-rc.d) -- Thomas Hood
Re: OSPF and distance vector routing source code
On Dec 17, 2004 at 09:44, j.s.dhilip praised the llamas by saying: hello, Would you please told me how can I get source code for OSPF? Makes a nice change from dualling banjos. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: Problems to upload
* Andreas Tille ([EMAIL PROTECTED]) [041217 07:55]: When trying manual ftp I found out that dosbox_0.63-2.dsc was put to master but with zero bytes and I'm not allowed to remove this file. The _only_ way to remove failed uploads is to upload a commands file, e.g. with dcut. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
John Goerzen wrote: On Thu, Dec 16, 2004 at 10:43:37PM +0100, Wouter Verhelst wrote: Thus, the answer to the failure of the LSB is not the Free Software people should be more helpful to the non-free people; the correct answer is the non-free people should be more helpful to the Free Software people. Very well written, Wouter. Thanks. I agree. One other possibility -- and I don't know if it's true or not -- is that the organization working on LSB is itself the problem. As a person who has seen an ISV in action I think the main problem is that they know the software works with product X, version Y. What they do not know is which properties of the product they are using, so if a new version comes out they have no way of knowing if it will work. The fact the glibc is known for incompatible changes in its ABI is not helping... Sun solves this by having a tool call appcert. http://developers.sun.com/solaris/articles/appcert.html it checks if the application only uses the official Sun API. Groetjes, Peter
Re: LCC and blobs
On Fri, Dec 17, 2004 at 10:45:07AM +0100, Peter Van Eynde wrote: Matthew Palmer wrote: Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. Ok. I'm game. Why? Where is the error my in applying your rules? Primary purpose, for a start. Perl can't go in main because it's useless without some non-free, perl-using app is ridiculous. - Matt signature.asc Description: Digital signature
Re: Problems to upload
Andreas Tille [EMAIL PROTECTED] wrote: [...] But what me *really* concerns is why dput and dupload failed in the first place. Especially the hint to PASSIV MODE smells like something has changed to the situation before. [...] | dput (0.9.2.15) unstable; urgency=low | | * More verbose error message for ftp uploads. And also use active | ftp per default. (Closes: #268489) | [...] | -- Christian Kurz [EMAIL PROTECTED] Sat, 13 Nov 2004 22:21:06 +0100 cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash http://downhill.aus.cc/
Re: Bug#285518: misdn-utils includes a firmware loader
On Thu, Dec 16, 2004 at 06:29:46PM -0500, Glenn Maynard wrote: On Thu, Dec 16, 2004 at 12:02:30AM +, Jonathan McDowell wrote: If we refuse to handle non-free firmware being loaded onto devices and require they come with it already inside then we get to play the I can't see it, it doesn't matter game, which gives the purists a warm fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard disc. This improves the experience for our users - they get to have the warm fuzzy feeling too, knowing that in sacrificing the ability to use many modern toys and gadgets they are purer of mind and body. Even better is the fact that they doubley can't use the hardware because we're too busy arguing about the firmware to make a release! No, there's a very concrete reason: given an installation of Debian main, the driver works. Drivers that require non-free firmware don't work out of the box; they say sorry, for [legal|philosophical][1] reasons, we can include this driver but we can't completely the installation automatically like everything else; go hunt down the firmware and come back. Any other software doing that would go straight to contrib, but people want to make an exception for drivers. If you're trying to install the distro and your ADSL modem/wireless card/SCSI controller needs some firmware to work at all, then going and hunting down the firmware could prove a bit tricky. Your sarcasm and condescension make me wonder why you're here at all, though; you appear to regard Debian's founding principles with contempt. No, I'm just aware of the fact that the Social Contract contains more than Clause 1. I accept Free Software is a very important part of Debian, but I'm also able to work out that if our users can't even install our free software then we're not really doing much for the promotion of Free Software nor are we managing to serve our users. J. -- For the Limit, I will forgive| Black Cat Networks Ltd all. -- David Damerell, afw.| http://www.blackcatnetworks.co.uk/ | UK Web, domain and email hosting
Re: RFC: common database policy/infrastracture
but something to point out: dbconfig-common already performs the administrative actions needed to set up the database and database user Well, see, the GnuMed bootstrapping does a lot more advanced things regarding the database user. There's users and groups with varying levels of access to the database. However, if dbconfig-common creates the admin account we just use it. We can also deal with the fact that the database is pre-created, no problem. 2. From the application point of view I could ask people to include an option which prevents the bootstrap script from doing the work which is just done. I guess this is no big deal for the very responsive authors. Agree. We might need to double-check but I think we are in good shape on that already. for the admin pass, it should be configurable globally whether or not the admin password is stored at all. I think you need to be very clear on what you mean here. There is an admin account for *PostgreSQL* (eg. postgres in most cases) but there's also an admin account for the database gnumed inside PostgreSQL (usually called gm-dbowner). The latter one owns all objects in that database and grants rights to other user groups. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: Problems to upload
On Fri, 17 Dec 2004, Andreas Metzler wrote: But what me *really* concerns is why dput and dupload failed in the first place. Especially the hint to PASSIV MODE smells like something has changed to the situation before. [...] | dput (0.9.2.15) unstable; urgency=low | | * More verbose error message for ftp uploads. And also use active | ftp per default. (Closes: #268489) | [...] | -- Christian Kurz [EMAIL PROTECTED] Sat, 13 Nov 2004 22:21:06 +0100 Perhaps this was the reason but I should probably reopen the bug which claimed more verbose error messages. The failure was caused because only passive mode seems to work - at least I was asked by manual ftp-client to switch to passive mode (I do not know until know what passive excatly is). Also dupload caused a passive mode related error message. In contrast to this dput just stopped with a Python error. Kind regards Andreas. -- http://fam-tille.de
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
Op vr, 17-12-2004 te 01:40 -0800, schreef Steve Langasek: On Fri, Dec 17, 2004 at 10:03:00AM +0100, Wouter Verhelst wrote: Indeed; however, IMO excerting the right to modify as defined by the DFSG should never result in the loss of support, or other negative consequences, because in that case you might as well not have it. This type of certification does carry that kind of negative consequence. But this happens all the time in all kinds of situations Sure, but that doesn't suddenly make it a good idea. My point is that there must be a better way to fix this. I would suggest an alternative, but I do not know what, exactly, it is in the LSB that makes proprietary developers decide it is not viable. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
[no subject]
Sir/Madam, I have Intel Mainboard 915GEV inbuilt Lan Card. Unable to install driver for Debian Woody r3.0 ( 2.4.18 ). Please send a solution regards -- Soumen Biswas Dept. of CSE, College of Engg. Mgmt, Kolaghat Ph: 03228-2331217,03228-233136 Email: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ / /__ __ / / D e b i a n G N U \ \/ / / / __ __ __ \ / / / / / / _ \ / / / / / \ / /___ / / / / ) // (_/ / / /\ \ (__)(_/ (_/ (_/ \/ (_/ \_) NB: I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: LCC and blobs
* Peter Van Eynde | Architectural plans for a house, shipped in a Debian package, are | software. | | I'm stunned. So anything in a Debian package is software. With alien I | can convert a tar.gz into a debian package, so all tar files are | software. With tar I can create a tar.gz from any file, so all | electronic data is software? Yes, for the purposes of the DFSG, it is. | - all bootloaders. Grub cannot start my XP without the XP bootsector. but grub itself is free and works with free kernels, ergo no dependency on XP. It can use XP, but that's totally besides the point. | - tftpd. I want to netboot my Solaris machines. The tftpd needs the | solaris code to work. Same for this -- tftpd itself is free and it has free data to work with. | - all font renderers. I want to see a document with the font I bought, | and without it the document is broken, so the renderer needs the font, | right? No, because there exists free fonts. That there exists non-free fonts which it can use is besides the point. | - all interpreters. I want to run HACMP. It is in perl, so the perl is | useless to me without HACMP. To you, sure, but there exists free programs and perl itself is free, so perl can go to main. | - the kernel. I want to ship a stripped down debian with my non-DFSG | code in an embedded system. The kernel is useless without my code, so | the kernel cannot be in main. But it can work with free hardware and is itself free. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#286027: ITP: ms-sys -- tool for writing Microsoft compatible boot records
i maintained ms-sys until the 1.1.3, i knew about 2.0 but didn't do the update. did you see some part of mbr code is free and some not? you probably want to talk to upstream, as i don't intend to maintain ms-sys anymore (i don't want non-free stuff generally). i was pointed to the package mbr in #debian-nonfree and i know about free mbr code in www.freedos.org (in the kernel source package) good luck cheers, guerkan -- Gürkan Sengünmail: [EMAIL PROTECTED] ETH Hönggerberg HPR E 86.1 phone: +41 1 633 6604 Departement Physik, ETH Zürich web: http://www.phys.ethz.ch
Re: RFC: common database policy/infrastracture
On Fri, 17 Dec 2004, Karsten Hilbert wrote: Well, see, the GnuMed bootstrapping does a lot more advanced things regarding the database user. There's users and groups with varying levels of access to the database. However, if dbconfig-common creates the admin account we just use it. We can also deal with the fact that the database is pre-created, no problem. Fine. Agree. We might need to double-check but I think we are in good shape on that already. I guessed this. BTW, do you think that the daily snapshot service will be started soon or should I switch back to check out from CVS. I'd prefer the snapshot because this is a certain file which I could refer to. I think you need to be very clear on what you mean here. There is an admin account for *PostgreSQL* (eg. postgres in most cases) On Debian GNU/Linux the user postgres has no password (by default). You can only su postgres and use the ident method from localhost. but there's also an admin account for the database gnumed inside PostgreSQL (usually called gm-dbowner). The latter one owns all objects in that database and grants rights to other user groups. I was talking about this user as administrator of the GnuMed database. I see no need to store the password of gm-dbowner in any file inside the file system. Thus it should be avoided. Kind regards Andreas. -- http://fam-tille.de
Re: LCC and blobs
Peter Van Eynde [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Some firmware is part of the hardware. Some isn't. It's easy to tell -- either it's in the hardware or it isn't. Of course, the name firmware should make it clear that this is an often ambiguous line. But this does seem to be a good practical place: can anybody with the device and the driver use it? Or are there some people who even with a functioning, complete device and a driver who can't get it to work? This is not only a feature of a device with firmware. Some hardware you cannot buy, you only get a license to use it. If I remember correctly you never buy an EMC, you only get permission to use it and have to pay every year to continue to use it. So you want to rip out all fiber-channel drivers because they might be used to connect to an EMC? No. They have useful functionality in connecting to other fiber-channel devices. Open standards are a nice thing. The fiber-channel devices have no dependency on the EMC hardware -- and even if they did, Debian doesn't express dependencies on hardware in its packaging system. I see no limitation of my freedom in using firmware. Please tell me how I am limited in my freedom. If I wanted a open source firmware I could buy a device with open firmware, Then Windows isn't proprietary either. Sigh. It is, but does the fact that I can boot it with grub limit my freedom? Of course not -- and grub can boot Linux or the Hurd, too. So Grub has no dependency on Windows. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Problems to upload
Quoting Andreas Tille ([EMAIL PROTECTED]):
But what me *really* concerns is why dput and dupload failed in the
first place. Especially the hint to PASSIV MODE smells like something
has changed to the situation before. I do not know something about
passive mode but I'm afraid somebody has changed something at our firewall
which resulted in problems with FTP protocol.
THis is highly likely to be this problem. 0-sized files are usually
the result of uploads failing because only passive FTP transfers work
in some situations.
This is why I indeed use Tollef's delayed queue in any situations
including those I want to do an immediate upload (I just use the 0-day
queue)...
In case you're not aware of it, here's the dupload.conf entry:
$delay = ($ENV{DELAY});
$cfg{'delayed'} = {
fqdn = gluck.debian.org,
login = bubulle,
incoming = ~tfheen/DELAYED/$delay-day/,
dinstall_runs = 1,
method = scpb
};
Re: LCC and blobs
Peter Van Eynde [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Peter Van Eynde [EMAIL PROTECTED] writes: And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite You name is software! Now I'm a Common Lisp hacker, you know the data is code people, but even _we_ do not consider a string software unless it drives some software. Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. Architectural plans for a house, shipped in a Debian package, are software. I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. software is not program. Programs are software that happens to be executable. Data is not executable, but still software. And you restrictions that any package that depends on non-DFSG software to work cannot be in main means that after releasing sarge we have to remove from main: - all bootloaders. Grub cannot start my XP without the XP bootsector. Grub doesn't depend on XP's bootsector. It provides other useful functionality -- booting Linux -- without it. That's more of a Suggests. - tftpd. I want to netboot my Solaris machines. The tftpd needs the solaris code to work. It implements the tftpd protocol all by itself. There are even plenty of tftp clients out there. Apache doesn't become non-free because you want to use it to distribute your great novel... which you haven't written yet. Should I go on? Please at least read Policy on what Depends means first. If you also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Bug#286027: ITP: ms-sys -- tool for writing Microsoft compatible boot records
* Bartosz Fenski aka fEnIo | * Package name: ms-sys | Version : 2.0.0. | Upstream Author : Henrik Carlqvist [EMAIL PROTECTED] | * URL : http://ms-sys.sourceforge.net/ | * License : GPL | Description : tool for writing Microsoft compatible boot records http://packages.debian.org/ms-sys -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: LCC and blobs
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Please at least read Policy on what Depends means first. If you also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. Note that the social contract says requires, not depends. I'm inclined to believe that policy is in the wrong here. (This does not mean that I believe the social contract's wording to be sane in this respect) -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#286027: ITP: ms-sys -- tool for writing Microsoft compatible boot records
On Fri, Dec 17, 2004 at 01:56:43PM +0100, Tollef Fog Heen wrote: | * Package name: ms-sys | Version : 2.0.0. | Upstream Author : Henrik Carlqvist [EMAIL PROTECTED] | * URL : http://ms-sys.sourceforge.net/ | * License : GPL | Description : tool for writing Microsoft compatible boot records http://packages.debian.org/ms-sys Geee I had to be blind yesterday ;) Ok I'm closing this bugreport, and sorry for confusion. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 04:59:15PM -0600, Dirk Eddelbuettel wrote: As it stands, 4 downloads for s390 appear somewhat disproportionate to 1,285,422 for i386. s390 is a little special, because it's neither a desktop nor a server architecture, but rather a mainframe one. One software installation can service many thousands of users; these are the things IBM was talking about when they thought they would only sell five of them. So it will always be disproportionately low by this measure. Exactly how far different it is from the rest is difficult to tell. The other architectures don't have that excuse. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: LCC and blobs
Raul Miller wrote: Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote: The API is known, otherwise there would be no Linux driver. The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. The fact that we uploaded the firmware does not excuse the device from respecting its API. Personally, I've never found devices to be particularly apologetic under any circumstances. Nor is it our task to write the firmware, Debian is a distribution for general-purpose computers, if you want to have a distribution for firmware you are free to do so. Are you thinking that these firmware devices are not used in general purpose computers? If not, this seems about as relevant as the other stuff you've said (which is to say: not at all). Debian should consider hardware as things that you have to talk to with a certain protocol. This would make all software which uses a well defined interface into hardware It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The has to bit. -- Raul
Re: LCC and blobs
Brian Thomas Sniffen wrote: Peter Van Eynde [EMAIL PROTECTED] writes: Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. :-) [data == software ?] Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. Hmm. I remember we had an editorial change that then turned into something completely different, followed by 6 damage limitation options and 1 hard line option. A damage limitation option won, but I if I read the matrix correctly the hard line option was defeated by _every_ damage limitation clause, so I would not be so certain that we had this debate. Post-sarge we will have the debate and I hope that this time ftp-master will state the consequences of the options in advance, so there are no surprises any more. Also having less then 7 options would also be nice. [clarifications] I think I'm starting to understand your point of view. So _any_ use of the software without using non-DFSG data makes it free, right? But what if loading the firmware is not required? That if the device was warm-booted in another OS? (I know there are technical limitations here) Would the driver-firmware relation still be a depends? Oh, I have another use for the ipw2100 driver without firmware: it can recognise the card from the pci-id information. :-) Please at least read Policy on what Depends means first. If you I see no mention of this in version 3.6.1.1. There is: |5.6.9. Package interrelationship fields - see chapter 7 |7.2. Binary Dependencies - is for debian packages. And has: |... |The `Depends' field should be used if the depended-on package is required |for the depending package to provide a significant amount of |functionality. |... |7.6. Relationships between source and binary packages -N/A There is no mention of dependency of packages on external data that fall outside the packaging system. So what meaning do you mean? If you extend the rules for packages to firmware then the question becomes what significant amount of functionality is. In the past it was used for can run, optional libraries were Suggested in. [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls ipw2100-1.0.fwipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw ipw2100-1.1.fwipw2100-1.2.fwipw2100-1.3.fwisl3890 ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ mv: cannot move `t' to a subdirectory of itself, `t/t' [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l t/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko The module loaded without firmware, not? It detected my card, but failed to load the firmware. ipw2100: Detected Intel PRO/Wireless 2100 Network Connection ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. ipw2100: eth1: ipw2100_get_firmware failed: -2 ipw2100: eth1: Failed to power on the adapter. ipw2100: eth1: Failed to start the firmware. ipw2100Error calling regiser_netdev. ipw2100: probe of :02:02.0 failed with error -5 I would say this is a functional driver. It provides me with useful information about my system. The fact that I cannot connect to a wifi lan is the same situation as with grub not being able to load XP without the XP bootsector, if there were a free firmware with the same API I would be able to load and use it. also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. Well. The last couple of times I thought rationality would return and I grew tired of the gedanken-experiments going on, and actually I did not care for the documentation idiocy. I should have paied more attention to my history classes and how extremists will take over democratic regimes because the majority cannot be bothered resisting simplistic arguments until it is too late. Making Debian uninstallable because of mistaken beliefs is too much and I care enough to resists this. I survived Erik Naggum, so this should be a walk in the park. Groetjes, Peter
Re: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Dec 16, 2004 at 11:10:15PM -0500, Joey Hess wrote: Jay Berkenbilt wrote: I've sent messages to various [EMAIL PROTECTED] addresses many times for various reasons, and they have all always been ignored. Me too, for values of ignored that include may have resulted in some action, but never got a reply email. I think that we need BTS pseudo-packages for the autobuilders. I'm not sure that would help much; indeed, in the common case (package needs a simple requeue, buildd admin would have taken care of it in due course anyway, sender isn't worried about a lack of reply as long as things are fixed), it would seem to impose a lamentable amount of overhead -- time that could otherwise be spent on the never-ending task of buildd/port maintenance. The BTS overhead is justified for packages, since any developer can NMU a package; as long as the buildds for most ports are one-maintainer-per-arch, I don't see that having a list in the BTS of packages to be requeued gives us anything over the present situation. What would help would be an email address where any DD can send a signed mail to request a rebuild or to set a dep-wait or a build failure. There could be a webpage where one selects the package(s) and architecture and it generates a mail template that just needs to be signed and send in case you fear the syntax is to complex. In the case of mails sent to arch@buildd.debian.org about issues that go unfixed for long periods, it would be nice to know what the story is. And personally, since I send a lot of these mails about packages with RC issues, I think more feedback from the buildd maintainers would help me to know better when these emails are helpful and when they're a distraction; but in the absence of feedback, I'll continue to assume my current approach is ok... -- Steve Langasek postmodern programmer MfG Goswin
Re: LCC and blobs
Raul Miller wrote: On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote: The API is known, otherwise there would be no Linux driver. The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. I don't understand you. An API is not programmed. Something can provide or support an API or use an API. In this case the firmware+hardware provides and API to the linux driver. It is known, we can support it. If the device has bugs in executing the API it makes no difference if there is a firmware or not to the driver, nor does it to our support because we don't provide the firmware, we only use it. The mere fact of uploading the firmware does not give us an obligation to support it. If your printer misprints a page you don't expect debian to patch it do you? ... It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The has to bit. If the has to is to do a specific task, eg connecting to a wifi network, then the has to is no different from grub loading the XP bootsector. In the other case the ipw2100 driver already loads and does some (very limited) work. Groetjes, Peter
Re: Naming for OSSP projects in Debian (libraries, dirs)
On Wednesday 15 of December 2004 21:05, you wrote:
I saw that you also ITP a OSSP (www.ossp.org) project for Debian:
OSSP uuid. I intent to do the same for OSSP sa. I'm using the sa
library successful for a small application so my intention is
make it public for others who intent to do the same too.
I've done already a Debian package and intent to sync the future
OSSP work with you. The problem I see with OSSP are the too simple
names e.g. libsa or libuuid. The header files are also installed
by default in /usr/include. This will lead in problems for uuid
more then for sa because Debian provide already more then one
file with the name uuid.h:
http://packages.debian.org/cgi-bin/search_contents.pl?word=uuid.hsearchmod
e=searchfilescase=insensitiveversion=unstablearch=i386
I've uploaded my packages to incoming. You can see them at
http://people.debian.org/~dexter/incoming/
We run in naming conflicts with other packages sooner or later.
It would be nice if we can have the same name semantic for this
two OSSP packages. I would propose:
Header files go to /usr/include/ossp/*, e.g. /usr/include/ossp/{sa,uuid}.h
Library start with libossp*, e.g. libossp{sa,uuid}*.
In fact I've already done that. The *.h goes to /usr/include/ossp/ and library
name is libossp-uuid.so. There is no problem with names as far as I've
modified /usr/bin/uuid-config.
The problem is that Debian will become binary incompatible with
foreign programs base on OSSP libraries :( I hope we find a solution
that match the requirements of the OSSP project and Debian.
There are no more distributions which release OSSP libraries, AFAIK.
--
.''`.Piotr Roszatycki, Netia SA
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
`-
Re: LCC and blobs
Raul Miller wrote: The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. On Fri, Dec 17, 2004 at 03:51:22PM +0100, Peter Van Eynde wrote: I don't understand you. Hmm... An API is not programmed. Programs are written against an API. The API represents the aspect of the computer which is being programmed when you write a program. Something can provide or support an API or use an API. Use an API can correspond to an API being programmed for the case that that the use of the API involves the creation of a program to do the using. In this case the firmware+hardware provides and API to the linux driver. Sure. But that's not the API I was talking about. I was talking about the API the firmware uses -- the one that the program contained in the API was designed to work with. It is known, we can support it. Which has nothing to do with the issue I was talking about, because you've got the wrong API. If the device has bugs in executing the API it makes no difference if there is a firmware or not to the driver, nor does it to our support because we don't provide the firmware, we only use it. EXACTLY! We don't provide the firmware. And the reason we don't provide the firmware is that we don't understand the issues well enough to do so. This rather concisely captures what the DFSG is about. The mere fact of uploading the firmware does not give us an obligation to support it. And, in fact, we shouldn't support it. If your printer misprints a page you don't expect debian to patch it do you? This is another good example. And, taking it a bit further, I think shipping a printer to me would be a waste of Debian resources. [That said, I don't have a printer.] It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The has to bit. If the has to is to do a specific task, eg connecting to a wifi network, then the has to is no different from grub loading the XP bootsector. We don't distribute the XP bootsector. In the other case the ipw2100 driver already loads and does some (very limited) work. The issue is completeness. A piece of software which has to have some non-free software to become functional is useless without that non-free software. -- Raul
Re: Default gcc for sarge, libunwind
Why this library was suddenly deemed critical for the architecture after we were already 3 months into a toolchain freeze is another question. This I'd like to know, too FWIW, these questions seem more appropriate to debian-devel than debian-mentors; these are not what I would call novice packaging questions. :) When I asked the first question, I expected to turn out to be just a big misconception of mine. Well, moving to debian-devel, and Cc-ing Matthieu and Al, libunwidn maintainers. Frank, Libunwind is a stack unwinder. It currently seriously support IA-64 only. However the upstream author is currently working on its extension over other architecture like i386. It is not only used for debugging (gdb can use it to unwind stack on a faster way than analysing the code), but can be used when an exception is raised on a try/catch block to define which personality routine is used. More about libunwind: http://www.hpl.hp.com/research/linux/libunwind/ To learn more about the evolution of the libunwind functionality and the libunwind package on Debian/IA-64 please these two threads: http://lists.debian.org/debian-ia64/2004/11/msg00019.html and then: http://lists.debian.org/debian-ia64/2004/12/msg00017.html The short version of the current issue is: There were two libunwind. One is used by gcc and is included into gcc sources. The second one is the one I'm packaging with Al. It contains more functionality than the gcc one. However it appeared the gcc libunwind was bugged and gcc needed to use the libunwind provided by our package to work properly. But the libunwind package is not inside of the base system set and a depedency on libunwind is not acceptable (freeze). People are currently working on updating the Debian gcc package to include the correct libunwind code inside of its own source and not depend on the libunwind package. Hoping I'm answering your concern. Please do not hesitate to ask more, Matthieu
Re: LCC and blobs
On Fri, Dec 17, 2004 at 10:33:41AM -0500, I clumsily wrote: I was talking about the API the firmware uses -- the one that the program contained in the API was designed to work with. That should have read: I was talking about the API the firmware uses -- the one that the program contained in the firmware was designed to work with. -- Raul
Re: Help needed with debconf
if [ $variant == Unicode ]; then That is a bashism which will fail if /bin/sh is dash. Use [ foo = bar ] instead. Thanks... are there any more pitfalls like this? [ expr -a expr ] is a pretty common mistake. [ expr ] [ expr ] should be used instead. (The same with OR.) */ Christoffer Sawicki [EMAIL PROTECTED]
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
Wouter Verhelst wrote: Indeed; however, IMO excerting the right to modify as defined by the DFSG should never result in the loss of support, or other negative consequences, because in that case you might as well not have it. This type of certification does carry that kind of negative consequence. DFSG #4 was specifically written explicitly to accomodate a situation where the user would potentially lose the right to support if he modified the program. ABISource's intent was to support their official version only. Now, you can always go back to the official version when you need support. But if you are going to modify the program, it only seems fair that you should take on the support burden for your modification. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Bug#286105: ITP: pngwriter -- Library for plotting PNG image pixel by pixel
Package: wnpp Severity: wishlist * Package name: pngwriter Version : 0.5.0 Upstream Author : Paul Blackburn [EMAIL PROTECTED] * URL : http://pngwriter.sourceforge.net * License : GPL Description : Library for plotting PNG image pixel by pixel PNGwriter is a very easy to use open source graphics library that uses PNG as its output format. The interface has been designed to be as simple and intuitive as possible. It supports plotting and reading in the RGB (red, green, blue), HSV (hue, saturation, value/brightness) and CMYK (cyan, magenta, yellow, black) colour spaces, basic shapes, scaling, bilinear interpolation, full TrueType antialiased and rotated text support, bezier curves, opening existing PNG images and more. Documentation in English and Spanish. Runs under Linux, Unix, Mac OS X and Windows. Requires libpng and optionally FreeType2 for the text support. Homepage: http://pngwriter.sourceforge.net/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=ca_ES, LC_CTYPE=ca_ES (charmap=ISO-8859-1)
Re: Problems to upload
[didn't sent to the list...] Andreas Tille wrote: On Fri, 17 Dec 2004, Andreas Metzler wrote: first place. Especially the hint to PASSIV MODE smells like something has changed to the situation before. | dput (0.9.2.15) unstable; urgency=low Perhaps this was the reason but I should probably reopen the bug which claimed more verbose error messages. The failure was caused because only passive mode seems to work - at least I was asked by manual ftp-client to switch to passive mode (I do not know until know what passive excatly is). Also dupload caused a passive mode related error message. In contrast to this dput just stopped with a Python error. Your analysis is correct, my apologies. As non-DD, I really don't get to test ftp uploads as thoroughly as I should. There is a bug report (and I've just sent a (corrected) fix), #283370, which concerning this problem. Sorry for leaving this open for so long. Kind regards Thomas (dput comaintainer) -- Thomas Viehmann, http://thomas.viehmann.net/
Re: Linux Core Consortium
On Fri, Dec 17, 2004 at 10:05:00AM +0100, Wouter Verhelst wrote: Op do, 16-12-2004 te 17:07 -0800, schreef Adam McKenna: On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote: I think Wouter is only asking for reciprocity here. If they don't care about his concerns why should he care about theirs ? Or alternatively not caring is a freedom. We care because our priorities are our users and free software. Just because someone works for an ISV or develops on/for proprietary software does not make them a second class user. That said, I am not arguing for or against LCC, I just didn't like the tone of Wouter's e-mail, or the sentiment implied in it. I did not intend that sentiment; I explained what I meant to say in a new thread. I apologize for misinterpreting your sentiment. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: RFC: common database policy/infrastracture
On Thu, 2004-12-16 at 15:34 +0100, Andreas Tille wrote: On Thu, 16 Dec 2004, Olaf van der Spek wrote: Is that the majority or the minority of applications? Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user. Can you tell me any reason why I should store a clear text password in a text file for *my* application only because *other* applications would require this? Kind regards Andreas. -- http://fam-tille.de Why not create a user in MySQL / PostgreSQL that has only rights to create databases and populates them ? First time installing dbconfig will ask for the admin password to create the user and packages that needs some install to databases can use that account to create that database. Hmm.. think it isn't possible then dbconfig needs an dependency on postgresql and mysql.. and i think that's not preferable. Matthijs Mohlmann
request for testing help and NMU
Hello all, I've been mostly out of commission for a while, and my key isn't currently in the keyring. I've been working with Jaqque to get it in, but we haven't finished that yet. But, I've had some requests for a new limewire package, and so I've made one. My problem is that I don't have access to a debian machine running X. So, can someone install this package of limewire and try it out and let me know if it works? Then, if it does, would someone be willing to NMU it for me? The package can be found here: http://sandiego.indymedia.org/debs/ Thanks, mbc -- http://hyperpoem.livejournal.com http://hyperpoem.net encrypted email preferred // gpg key id: F118F6D8 The hidden hand of the market will never work without the hidden fist ... And the hidden fist that keeps the world safe for Silicon Valley's technologies to flourish is called the US Army, Air Force, Navy and Marine Corps. - Thomas Friedman, The Lexus and the Olive Tree
Re: GPL and LGPL issues for LCC, or lack thereof
Hopefully this continues to be interesting to debian-devel readers. Perhaps replies should go to debian-legal; GMail doesn't seem to let me set Followup-To, but feel free to do so if you think best. I have copied Eben Moglen (General Counsel to the FSF) at Bruce's suggestion. Mr. Moglen, I am not a lawyer, but I'm doing my humble best to match the (L)GPL up to recent case law. Your name was invoked by Bruce Perens with regard to an analysis of the Red Hat service contract and the GPL, and if you have the time, I would value your comments. This debate arose in the context of a discussion about the Linux Core Consortium's proposal to share binaries among GNU/Linux distros. I don't think the LGPL ought to permit ISVs to discriminate between users who link against these golden binaries and those who link against functional equivalents, and I don't think that distros ought to offer ISVs this illusory solution to their (perceived) quality and interoperability problems. I also think, based on the actual text of the LGPL, that it may already be enforceable as a ban against this discrimination. You can find previous messages in this thread at http://lists.debian.org/debian-devel/2004/12/thrd3.html starting at Linux Core Consortium (Bruce Perens). me What part of normally distributed ... with ... the operating system is me confusing? Bruce The license requires that the source code all of the pieces that Bruce constitute a derivative work of some original piece of GPL code must be Bruce provided. This would be the original GPL program and the scripts used to Bruce build it, and any other code you link into it and the scripts used to build Bruce that. The build tools are separate works that never become derivative of Bruce the GPL program. I am talking about the LGPL here, not the GPL. Please re-read sections 5 and 6 of the LGPL for the definition of work that uses the Library (which assumes that it only becomes a derivative work after linking) and the special exception to the GPL requirement of releasing source code. As I read it, the exception clause can and does place limits on the allowable build tools even though they are not derivative works. It may not have been the original intention of the GPL authors to address the availability of build tools. But the language I cited from LGPL section 6 seems to succeed in the intention stated in the preamble, which includes: If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. You can't do that if you don't have the full means of recompiling it. Bruce Concievably a contract could require that you specify the build system, Bruce but the GPL doesn't purport to be a contract. It is designed to only grant Bruce rights, not restrict any rights that you would otherwise have. This also Bruce side-steps the issue of consent. I am having a hard time believing that you are arguing that the GPL is not an enforceable contract. If it's not a contract, then what is it? At least under U. S. law, I'm not aware of any other theory under which copyright license can be granted (fair use and the like are acceptable justifications for using copyright material without a license, but do not result in a grant of license). Even a grant with no return consideration is considered a unilateral contract, and the (L)GPL is certainly not intended to be a unilateral grant. A grant of license in return for specific performance is in fact a contract whether there's a signature or not. The distributor can choose whether or not to accept the offered contract, but if they don't choose to do so, they can't claim to have received a copyright license. For an analysis of similar issues in an offer of copyright license, see Fosson v. Palace Waterland (1995) at http://caselaw.lp.findlaw.com/data2/circs/9th/940.html . You will again have to go beyond a superficial reading of who won, because issues of fact went against the copyright holder. Here are a few excerpts (see the original for references to other cases): excerpts Under California law, an offer is a manifestation of willingness to enter into a bargain, so made as to justify another person in understanding that his assent to that bargain is invited and will conclude it. ... under California law, acceptance is the `manifestation of assent to the terms thereof made by the offeree in a manner invited or required by the offer.' ... under California law, where no time limit is specified for the performance of an act, a reasonable time is implied. ... Thus, the failure to specify a timeframe for payment of the license fee would not render the contract illusory. If doubt[exists] as to whether the agreement was bilateral or unilateral, such doubt would have to be resolved by interpreting the agreement to be bilateral. . . .There is a presumption in favor of interpreting ambiguous
Re: LCC and blobs
Brian Thomas Sniffen [EMAIL PROTECTED] writes: Peter Van Eynde [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Architectural plans for a house, shipped in a Debian package, are software. I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. software is not program. Programs are software that happens to be executable. Data is not executable, but still software. No, a definition of software was never decided upon. The vote was about removing the word software in certain places from the DFSG, regardless of its definition. -- For every sprinkle I find, I shall kill you!
Re: GPL and LGPL issues for LCC, or lack thereof
On re-reading the sequence of events, it looks like I was the one who switched the context of the hypothetical reproducible build tools obligation from GPL to LGPL. Bruce, my apologies for implying that you were the one who switched contexts. So we seem to agree that the support for this requirement isn't adequate in the GPL (which I consider to be a flaw in the GPL). I think the support is adequate in the LGPL, as my most recent e-mail elaborates. Presumably that's what is really at issue (at a strictly legal level) in the LCC; proprietary applications don't usually link against GPL libraries, since most ISVs consider the GPL likely to be enforceable. For code under other licenses, I have to fall back on the DFSG to contend that Debian shouldn't encourage efforts to standardize binaries. I find arguments from the Social Contract and hypothetical benefits to users unpersuasive. Cheers, - Michael
Re: LCC and blobs
On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote: No, a definition of software was never decided upon. The vote was about removing the word software in certain places from the DFSG, regardless of its definition. However, the S in DFSG means software; the SC was adjusted to say that everything in Debian is judged by the DFSG, but the DFSG was not renamed (for example, to mean Debian Free Stuff Guidelines). This means, to me, that everything in Debian is Software. It's a moot issue, anyway; any time the dictionary lawyers nitpick software, the real point is probably long lost, anyway ... :) -- Glenn Maynard
Re: Naming for OSSP projects in Debian (libraries, dirs)
Hi Peter, In fact I've already done that. The *.h goes to /usr/include/ossp/ and library name is libossp-uuid.so. There is no problem with names as far as I've modified /usr/bin/uuid-config. Ok. I did not upload my packages until now. I will change the library and package name to libossp-sa12 as you did. The include files will also be in /usr/include/ossp as you have done. -- Raphael Bossek -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
Re: LCC and blobs
On Fri, Dec 17, 2004 at 03:23:54PM +0100, Peter Van Eynde wrote: Hmm. I remember we had an editorial change that then turned into something completely different, followed by 6 damage limitation options and 1 hard line option. A damage limitation option won, but I if I read the matrix correctly the hard line option was defeated by _every_ damage limitation clause, so I would not be so certain that we had this debate. Post-sarge we will have the debate and I hope that this time ftp-master will state the consequences of the options in advance, so there are no surprises any more. Also having less then 7 options would also be nice. It was not defeated, it was delayed until post-sarge, at which point the 2004-003 GR's SC will kick in automatically with no further debate. I don't know what debate you think we'll have; while I'm sure many debates on many topics will be held, 2004-003 *will* reactivate unless another GR is held to repeal it. [clarifications] I think I'm starting to understand your point of view. So _any_ use of the software without using non-DFSG data makes it free, right? This is the widely-accepted understanding of software in main, yes. But what if loading the firmware is not required? That if the device was warm-booted in another OS? (I know there are technical limitations here) Would the driver-firmware relation still be a depends? Then it requires that other OS to function. Oh, I have another use for the ipw2100 driver without firmware: it can recognise the card from the pci-id information. :-) That's attempting to sidestep the issue and pretend freeness isn't important, which isn't something Debian should be stooping to. :) I would say this is a functional driver. It provides me with useful information about my system. The fact that I cannot connect to a wifi lan is the same situation as with grub not being able to load XP without the XP bootsector, if there were a free firmware with the same API I would be able to load and use it. If grub was only able to load XP, and not other operating systems, and it required XP's boot sector to be functional, it would probably go in contrib. However, grub loads several operating systems, so XP's boot sector is just added functionality. also read the archives, you'll have a chance at understanding the For what it's worth, it's not really reasonable to expect people to read the archives, since the archives on these topics probably exceed a thousand messages. Well. The last couple of times I thought rationality would return and I grew tired of the gedanken-experiments going on, and actually I did not care for the documentation idiocy. I should have paied more attention to my history classes and how extremists will take over democratic regimes because the majority cannot be bothered resisting simplistic arguments until it is too late. Making Debian uninstallable because of mistaken beliefs is too much and I care enough to resists this. I survived Erik Naggum, so this should be a walk in the park. So now you're saying that expecting that documentation be Free is idiocy, and that the majority doesn't actually want it, despite the very clear results of GR 2004-003. Sorry, that's a tired old complaint that's not even worth refuting ... -- Glenn Maynard
Re: Bug#285518: misdn-utils includes a firmware loader
On Fri, Dec 17, 2004 at 09:39:46AM +, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: No, there's a very concrete reason: given an installation of Debian main, the driver works. Drivers that require non-free firmware don't work out of the box; The vast, vast majority of drivers require non-free firmware. Hmm. A few places to draw the dependency from driver to firmware line seem to be: No, that's not what you said. There's some room to quibble over whether a dependency exists - there's no room to quibble over whether a requirement exists. Almost all modern hardware either contains firmware or requires firmware to be uploaded. Therefore, almost all drivers require firmware, since otherwise the hardware they drive would not exist. Please, let's be honest about what requirements software has. Sorry, but I don't see a distinction between the word depend and require in this context, and I don't see any reason to draw one. I see a clear difference between a driver that needs (expects, requires, depends on, you pick) its own copy of a firmware to be copied around-- subjecting users and developers to its copyright restrictions, and imposing a limitation on the ability of that driver to work out of the box--and one that does not. -- Glenn Maynard
Re: GPL and LGPL issues for LCC, or lack thereof
Michael K. Edwards wrote: Hopefully this continues to be interesting to debian-devel readers. It's not even interesting to me, and I hope that someone of greater legal competence sets you right and ends the discussion. The LGPL requires that the creator of a derivative work provide the object code for relinking, and not prohibit relinking and reverse engineering. It does not, however, require that creator to take other necessary steps to make relinking possible, such as providing a JPEG loading tool for the FLASH in an embedded device and the necessary documentation to use it. Perhaps that is why it mentions reverse-engineering - you're expected to be able to figure this out for yourself. More likely the lack of affirmative language regarding that it actually be possible to replace the program is due to a lack of foresight. At a GPL 3 planning meeting almost two years ago, I suggested that GPL 3 include affirmative language that the user must be made able to replace a program in a device if the program is at all replacable. The context of the suggestion was a discussion regarding what we would do about DRM. It was understood that once we replaced a program, the DRM facility would no longer vouch for it. But we could gain control of the overall device, perhaps minus any hardware DRM facility, by replacing the kernel. This suggestion was well received. However I can't say when GPL 3 will happen or what it will contain. However, it doesn't address your belief that certification and support obligations should survive such modifications. That's still covered by the following: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. Regarding whether or not the GPL is a contract, it is intended to be a unilateral grant of rights and does not require consent nor specific performance. Thus, I have little desire to chase down the volumes of contract cases which you offer. You can read a case on the nature of consent such as Specht v. Netscape, which might convince you that we don't necessarily get sufficient consent on the licenses that we distribute for them to bind as contracts. If you accept the contention that "sublicensing" and/or "distribution" covers the performance of contractual obligations between distributor and recipient, then my statement stands. This seems to be one place where you have a problem. The right to sublicense is specific to the copyright grant offered. It does not connect with other contracts offered, such as offers of support, which are outside of the scope of the license. Regarding whether such things are separate covenants, you should consider that the copyright grants, including the right to sublicense, are made to all parties, while the customer must approach Red Hat with consideration in order to gain the service contract. I am hoping that you can find someone whose opinion you would accept who will bring a swift close to this discussion. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: GPL and LGPL issues for LCC, or lack thereof
On Fri, 17 Dec 2004 12:26:01 -0800, Bruce Perens [EMAIL PROTECTED] wrote: The LGPL requires that the creator of a derivative work provide the object code for relinking, and not prohibit relinking and reverse engineering. It does not, however, require that creator to take other necessary steps to make relinking possible, such as providing a JPEG loading tool for the FLASH Is that really JPEG? Or JTAG?
Do you want XFree86 working out of the box?
Do you want a working XFree86 configuration out of the box, without having to answer questions about your hardware? Try to install xdebconfigurator, URL:http://packages.debian.org/xdebconfigurator, and see if it work for you? To test it, install the package and run xdebconfigurator dexconf This will replace your current /etc/X11/XF86Config-4 file, based on the detected hardware. It can even be used at install time, if it is installed by debian-installer before base-config starts. Give it a try, and report any problems to BTS. (Try version 1.14 in Sid. Version 1.12 in sarge have a few annoying problems now fixed in sid. :)
Re: Do you want XFree86 working out of the box?
So, I did this a few days ago, and ddcprobe was not in any Debian package. Also, it got the mouse as /dev/input rather than /dev/input/mouse, and the resulting X configuration didn't work. It would be really nice if it worked. Thanks Bruce Petter Reinholdtsen wrote: Do you want a working XFree86 configuration out of the box, without having to answer questions about your hardware? Try to install xdebconfigurator, URL:http://packages.debian.org/xdebconfigurator, and see if it work for you? To test it, install the package and run xdebconfigurator dexconf This will replace your current /etc/X11/XF86Config-4 file, based on the detected hardware. It can even be used at install time, if it is installed by debian-installer before base-config starts. Give it a try, and report any problems to BTS. (Try version 1.14 in Sid. Version 1.12 in sarge have a few annoying problems now fixed in sid. :)
Re: GPL and LGPL issues for LCC, or lack thereof
Olaf van der Spek wrote: Is that really JPEG? Or JTAG? That's all we need, lossy ROM image compression :-) Yes, JTAG. Thanks Bruce
Re: LCC and blobs
Peter Van Eynde wrote: Brian Thomas Sniffen wrote: Peter Van Eynde [EMAIL PROTECTED] writes: [data == software ?] Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. Hmm. I remember we had an editorial change that then turned into Considering the fact that Debian has always considered everything on the Debian CDs to be subject to the DFSG (see Bruce Perens' messages on this topic around the time of the vote, along with agreement from others around at that time), it certainly seems like making that clearly explicit is nothing more than an editorial change. something completely different, followed by 6 damage limitation options and 1 hard line option. A damage limitation option won, but I if I read That's not an accurate summary: we had 4 variations on postpone for Sarge, one repeal the changes entirely option, and one do nothing, the changes apply for Sarge option. I think that covers both extremes as well as many points in the middle. the matrix correctly the hard line option was defeated by _every_ damage limitation clause, so I would not be so certain that we had this debate. Certainly we did; the votes were for two entirely different purposes. The first stated our position more clearly and unambiguously, and the second said just because we are making this explicit doesn't mean we have to fix our lax enforcement of it immediately, before releasing Sarge. Post-sarge we will have the debate and I hope that this time ftp-master will state the consequences of the options in advance, so there are no surprises any more. Also having less then 7 options would also be nice. We have already had the debate; we will not have it again post-sarge unless someone decides to raise another GR. Considering that one of the options in the previous GR was repeal the changes entirely, and that option was at the bottom of the ranking along with the opposite extreme, I think it is quite clear that developers agree with the new social contract. Indeed, the vote before that showed that developers agree with it by more than a 3:1 ratio. :) [clarifications] I think I'm starting to understand your point of view. So _any_ use of the software without using non-DFSG data makes it free, right? Within reason, yes. (Linker errors because a library is missing, or similar situations in which the only functionality is to tell you that a piece is missing, don't count.) But what if loading the firmware is not required? That if the device was warm-booted in another OS? (I know there are technical limitations here) Would the driver-firmware relation still be a depends? No, then the driver Depends: firmware | other-os . We don't ship either, so the driver still needs to go to contrib. :) And presumably other-os depends (though not in the Debian package sense) on the firmware as well, so even if that other OS was Free and we shipped it, we'd be back to needing the firmware. Oh, I have another use for the ipw2100 driver without firmware: it can recognise the card from the pci-id information. :-) To me, that seems much like arguing that because an emulator (such as one for a console system) provides a GUI, and because it can run and display that GUI without needing a ROM, the emulator should go to main. I don't believe that is a significant amount of functionality. Do you? Feel free to try to convince people. Think about it this way: is that functionality sufficient that if the firmware was Free Software distributed in main, that you would still say the driver should only declare a Recommends or Suggests on the firmware? Please at least read Policy on what Depends means first. If you I see no mention of this in version 3.6.1.1. There is: |5.6.9. Package interrelationship fields - see chapter 7 |7.2. Binary Dependencies - is for debian packages. And has: |... |The `Depends' field should be used if the depended-on package is required |for the depending package to provide a significant amount of |functionality. |... |7.6. Relationships between source and binary packages -N/A There is no mention of dependency of packages on external data that fall outside the packaging system. So what meaning do you mean? Dependencies on anything outside of the Debian archive automatically put a package in contrib; see 2.2 Sections. For example, see the packages placed in contrib because they depend on mplayer, despite the fact that mplayer is Free Software (just legally dangerous to package in any useful manner, rather than stripped of much of its useful functionality). If you extend the rules for packages to firmware then the question becomes what significant amount of functionality is. In the past it was used for can run, optional libraries were Suggested in. [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls ipw2100-1.0.fwipw2100-1.1-p.fw
Re: Do you want XFree86 working out of the box?
On Fri, 17 Dec 2004 22:30:02 +0100, Petter Reinholdtsen [EMAIL PROTECTED] wrote: Try to install xdebconfigurator, URL:http://packages.debian.org/xdebconfigurator, and see if it work for you? To test it, install the package and run xdebconfigurator dexconf This will replace your current /etc/X11/XF86Config-4 file, based on the detected hardware. (Try version 1.14 in Sid. Version 1.12 in sarge have a few annoying problems now fixed in sid. :) What is testing/Unstable called? Sid? I'm on Debian 3.1 Ultrasparc and the above procedure results in both ddcprobe abd dexconf not being found nor installable. ... but, I used apt-get ... I'll search for another way. -- WC -Sx- Jones http://insecurity.org/
Bug#286141: ITP: kbandwidth -- Network interface monitor in KDE tray
Package: wnpp Severity: wishlist * Package name: kbandwidth Version : 1.0.1 Upstream Author : Niko Sommer [EMAIL PROTECTED] * URL : http://www.kde-apps.org/content/show.php?content=18939 * License : GPL Description : Network interface monitor in KDE tray Network monitoring Kicker-applet for KDE 3.x. This tool can show speed of any network interfaces. For example traffic of your ADSL, LAN, Modem or others. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Re: LCC and blobs
Glenn Maynard [EMAIL PROTECTED] writes: On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote: No, a definition of software was never decided upon. The vote was about removing the word software in certain places from the DFSG, regardless of its definition. However, the S in DFSG means software; the SC was adjusted to say that everything in Debian is judged by the DFSG, but the DFSG was not renamed (for example, to mean Debian Free Stuff Guidelines). This means, to me, that everything in Debian is Software. I'd say it's just there by legacy. It's a moot issue, anyway; any time the dictionary lawyers nitpick software, the real point is probably long lost, anyway ... :) Sure, how bout this: It seems to me that if you're saying everything in Debian is software, then your definition of software must be something equivalent to information stored in a way that can be read by a machine. In that case, you'd certainly agree that the information stored on a punch card is software. And, if a punch card can store software, then certainly a name chiseled into the aforementioned granite could be considered software. After all, it's entirely conceivable a machine could be made to read it--it's not even all that different in concept from a punch card reader. That leads to the conclusion that anything in the universe could be considered software, since even sub-atomic particles store information that could be considered machine-readable. In other words, you've redefined software to mean simply information. It's entirely inconsistent with the common usage of the term software, but whatever. Has the real point been lost yet? :) What I'm trying to get at is that software is such a nebulous term that it really has no meaning, so it was just removed from the SC where it caused confusion. Just say Debian is 100% free, not that Debian is 100% free software, so we stop making ourselves look foolish trying to define what exactly software is. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Fri, Dec 17, 2004 at 11:36:09PM +0100, Måns Rullgård wrote: To me, that seems much like arguing that because an emulator (such as one for a console system) provides a GUI, and because it can run and display that GUI without needing a ROM, the emulator should go to main. I don't believe that is a significant amount of functionality. Do you? Feel free to try to convince people. I'm convinced enough. Some time ago, I was playing around with an emulator for Texas Instruments calculators. It obviously required a ROM image to be useful, and the only legal way of obtaining one was dumping it from your own calculator (an easy task). I still found this emulator useful, since I happen to have one of the calculators. By your reasoning, the only software allowed in main would be programs that could be used on any machine that will run Debian at all. The only things I can think of that all machines have are a CPU and a few megabytes of RAM. Everything else is more or less optional. (I don't think this follows at all from his reasoning, but here I'm focusing on your reasoning, since it seems a little confused.) By your reasoning, everything in contrib should be moved to main, and contrib should not exist. Can you please explain what the difference is between your calculator example, and everything else in contrib? Free software that needs non-free software to function is not allowed in main. (There's no debate over this--it's a fundamental principle, straight out of the first clause of the Social Contract.) That's the whole reason contrib exists; that's where your calculator emulator would go, if no free ROM image was available. It doesn't matter how easy it is to get that ROM image. If it was distributed under a distribute freely, but do not modify license, it would be trivial to obtain, could go in non-free, and the emulator would be useful to people that don't own the calculator. Despite that, the emulator would still go in contrib. (The firmware debate is due, in part, to it not being immediately clear whether a driver requiring firmware to fire up a device counts as depend[ing] on an item of non-free software, but your emulator example has no such ambiguity.) -- Glenn Maynard
Re: removing in postrm rc*.d symlinks that I did not create
On Fri, 17 Dec 2004 10:49:13 +0100, Thomas Hood wrote: [...] The idea behind initscripts is that they do what they are told when they are run. sysv-rc and file-rc implement two different schemes for determining when they are run and with what arguments. I don't see why people keep trying to undermine the standard mechanism. Under the circumstances you describe it is reasonable to refrain from installing symlinks[*] in runlevel directories. I think you are justified in deleting the symlinks on purge too, so I suggest you simply override lintian and linda. Amen. Well, almost. Under current sysv-rc semantics invoke-rc.d defauls to running the script if neither S nor K links are present. And there were reasonable arguments given for this behaviour. Thus, if Nicolas would want to use invoke-rc.d to maybe run the init script of his package on upgrades, it would be necessary to install K links by default. But maybe just not running the script on upgrade even if the S link is present is the correct solution for athcool. I don't know. -- Micha Politowski Talking has been known to lead to communication if practised carelessly. signature.asc Description: Digital signature
Re: LCC and blobs
On Fri, 17 Dec 2004 09:53:51 +0100, Peter Van Eynde [EMAIL PROTECTED] said: Brian Thomas Sniffen wrote: Peter Van Eynde [EMAIL PROTECTED] writes: And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite You name is software! Now I'm a Common Lisp hacker, you know the data is code people, but even _we_ do not consider a string software unless it drives some software. Is your name input for a state-machine? Architectural plans for a house, shipped in a Debian package, are software. I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? Yes. Software, hardware, wetware. One of these three. And you restrictions that any package that depends on non-DFSG software to work cannot be in main means that after releasing sarge we have to remove from main: - all bootloaders. Grub cannot start my XP without the XP bootsector. Umm, you have configured grub to use optional software. Grub on my boxes can boot my machines just fine, so there is no general dependency. - tftpd. I want to netboot my Solaris machines. The tftpd needs the solaris code to work. In that case. I can have tftpd booting Linux kernels -- so tftpd does not need solaris, though it can be so configured. - all font renderers. I want to see a document with the font I bought, and without it the document is broken, so the renderer needs the font, right? Wrong again, but that's just the patternm. The font renderer can render any fonts, including non-free ones. - all interpreters. I want to run HACMP. It is in perl, so the perl is useless to me without HACMP. I think you really really need a course in logic and causation. - the kernel. I want to ship a stripped down debian with my non-DFSG code in an embedded system. The kernel is useless without my code, so the kernel cannot be in main. The kernel is, in general useful without non-free software. Should I go on? Sure, but preferably after you have taken some courses in basic logic. manoj -- At least they're ___EXPERIENCED incompetents Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: LCC and blobs
On Fri, 17 Dec 2004 14:52:56 -0800, Brian Nelson [EMAIL PROTECTED] said: Glenn Maynard [EMAIL PROTECTED] writes: On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote: No, a definition of software was never decided upon. The vote was about removing the word software in certain places from the DFSG, regardless of its definition. However, the S in DFSG means software; the SC was adjusted to say that everything in Debian is judged by the DFSG, but the DFSG was not renamed (for example, to mean Debian Free Stuff Guidelines). This means, to me, that everything in Debian is Software. I'd say it's just there by legacy. It's a moot issue, anyway; any time the dictionary lawyers nitpick software, the real point is probably long lost, anyway ... :) Sure, how bout this: It seems to me that if you're saying everything in Debian is software, then your definition of software must be something equivalent to information stored in a way that can be read by a machine. No. Information encoded electronically, in 0's and 1, usually. Things related to computers are either software, hardware, or wetware. In that case, you'd certainly agree that the information stored on a punch card is software. Umm, no. Nor is stuff on a printed page that can be scanned using OCR. The card is physical, I can feel it, make holes in it, and it is hardware. When read by a card reader (or when a page is scanned in), it gets an electronic representation in the machine, and then is software. Since thge rest of your post proceeds from this false premise, I am eliding it. manoj -- A horse! A horse! My kingdom for a horse! Wm. Shakespeare, Henry VI Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: LCC and blobs
On Fri, 17 Dec 2004 15:23:54 +0100, Peter Van Eynde [EMAIL PROTECTED] said: Brian Thomas Sniffen wrote: Peter Van Eynde [EMAIL PROTECTED] writes: Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. :-) [data == software ?] Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. Hmm. I remember we had an editorial change that then turned into Ah, the tired refrain of incompetent nincompoops too fucking lazy to read email about critical changes to core documents delivered into their mailboxes not once, not twice, but three times at least, and this after months of discussion. And given that the SC was originally intendeed to cover everything on an official CD, yes, htese were merely editorial changes. something completely different, followed by 6 damage limitation options and 1 hard line option. A damage limitation option won, but I if I read the matrix correctly the hard line option was defeated by _every_ damage limitation clause, so I would not be so certain that we had this debate. Right. The repeasl the changes bit was defeated by every single grandfather our lax observance of the DFSG until after this next release. So, we had an option to reeal the changes, we did not take it. Post-sarge we will have the debate What makes you think there shall be a debate? and I hope that this time ftp-master will state the consequences of the options in advance, so there are no surprises any more. Also having less then 7 options would also be nice. Why is another vote needed? Who is asking for one? Well. The last couple of times I thought rationality would return and I grew tired of the gedanken-experiments going on, and actually I did not care for the documentation idiocy. I should have paied more attention to my history classes and how extremists will take over democratic regimes because the majority cannot be bothered resisting simplistic arguments until it is too late. Making Debian uninstallable because of mistaken beliefs is too much and I care enough to resists this. I survived Erik Naggum, so this should be a walk in the park. http://www.debian.org/social_contract.1.1 That's the version that shall be in effect post sarge. manoj -- Chemist who falls in acid will be tripping for weeks. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: LCC and blobs
Glenn Maynard [EMAIL PROTECTED] writes: On Fri, Dec 17, 2004 at 11:36:09PM +0100, Måns Rullgård wrote: To me, that seems much like arguing that because an emulator (such as one for a console system) provides a GUI, and because it can run and display that GUI without needing a ROM, the emulator should go to main. I don't believe that is a significant amount of functionality. Do you? Feel free to try to convince people. I'm convinced enough. Some time ago, I was playing around with an emulator for Texas Instruments calculators. It obviously required a ROM image to be useful, and the only legal way of obtaining one was dumping it from your own calculator (an easy task). I still found this emulator useful, since I happen to have one of the calculators. By your reasoning, the only software allowed in main would be programs that could be used on any machine that will run Debian at all. The only things I can think of that all machines have are a CPU and a few megabytes of RAM. Everything else is more or less optional. (I don't think this follows at all from his reasoning, but here I'm focusing on your reasoning, since it seems a little confused.) By your reasoning, everything in contrib should be moved to main, and contrib should not exist. That's not what I said, nor what I meant. For instance, a Matlab program no doubt depends on Matlab, which is clearly non-free. Can you please explain what the difference is between your calculator example, and everything else in contrib? I don't know all the packages in contrib, and I don't have the time to go and read the descriptions of all of them. Free software that needs non-free software to function is not allowed in main. (There's no debate over this--it's a fundamental principle, straight out of the first clause of the Social Contract.) Well, that makes it as fundamental as the SC, no more, no less. In this context, I'll accept it though. That's the whole reason contrib exists; that's where your calculator emulator would go, if no free ROM image was available. It doesn't matter how easy it is to get that ROM image. If it was distributed under a distribute freely, but do not modify license, it would be trivial to obtain, could go in non-free, and the emulator would be useful to people that don't own the calculator. Despite that, the emulator would still go in contrib. OK, then it's about time someone removes libti68k (Motorola 68000 emulation library for Texas Instruments calculators) from main. Not only does it require a ROM image, it also depends on libticalcs3 and libticables3, both of which require an actual calculator, and hence the firmware (let's call it firmware, to make the analogy easier to see), without which the calculator is useless. Now you'll say the calculator doesn't need the firmware to be loaded every time you want to use it, and that would somehow make a difference. Suppose now, that TI released a new model, which didn't have flash memory, so it would need to be reloaded if the batteries were removed, while in all other respects being compatible to the previous models. Would this suddenly render all those libraries non-free? (The firmware debate is due, in part, to it not being immediately clear whether a driver requiring firmware to fire up a device counts as depend[ing] on an item of non-free software, but your emulator example has no such ambiguity.) That's where we disagree. Suppose some piece of hardware had a Compact Flash reader, and came with a Compact Flash card containing firmware necessary for the hardware to run. Would this also be non-free? -- Måns Rullgård [EMAIL PROTECTED]
Re: Linux Core Consortium
On Thu, 16 Dec 2004 12:51:54 -0800, Adam McKenna [EMAIL PROTECTED] said: On Thu, Dec 16, 2004 at 09:25:38PM +0100, Wouter Verhelst wrote: Op do, 16-12-2004 te 14:46 -0500, schreef Ian Murdock: We've heard directly from the biggest ISVs that nothing short of a common binary core will be viable from their point of view. Well, frankly, I don't care what they think is 'viable'. 'ISV' is just another name for 'Software Hoarder'. I thought Debian was about Freedom, not about how can we make the life of proprietary software developers easy? Regardless of how you feel about proprietary software, it is someone else's work and they are free to sell or license it as they see fit. Quite so. But I am in no way obligated to spend my time making it easier for them to do so in a proprietary fashion -- even if some users out there happen to like such software. I don't see how someone advocating freedom can in the same (virtual) breath presume to dictate what other people do with their work. My point exactly. Why should the free software have to go out of its way to make things easier for them? (But .. our users luuv non free software only stretches so far). Perhaps I am missing the point there? manoj -- A witty saying proves nothing. Voltaire Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Linux Core Consortium
On Thu, 16 Dec 2004 12:45:15 -0800, Bruce Perens [EMAIL PROTECTED] said: 1. (*) text/plain ( ) text/html Wouter Verhelst wrote: 'ISV' is just another name for 'Software Hoarder'. Please keep in mind this portion of Debian's Social Contract: /We will support our users who develop and run non-free software on Debian / Right. We'll not do anything actively sabotaging running non-free software -- we probably shall even expend a modicum of effort to help them. But there is a line, beyond which such effort is better spent on free software. One of the reasons for this is that you can get more people to appreciate Free Software if you can get it into their hands first. If they have no choice but to stick with RH and SuSE because they can't get their stuff supported elsewhere, they will never get our message. Right. So I am cautiously in favour of giving LCC a shot -- while bearing in mind that this is not a do or die effort. If it does not impact the users of free software, and it does not require major effort, we should see if LCC can be supported. manoj -- She always believed in the old adage -- leave them while you're looking good. Anita Loos, Gentlemen Prefer Blondes Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: LCC and blobs
On Sat, Dec 18, 2004 at 01:28:46AM +0100, Måns Rullgård wrote: I'm convinced enough. Some time ago, I was playing around with an emulator for Texas Instruments calculators. It obviously required a ROM image to be useful, and the only legal way of obtaining one was dumping it from your own calculator (an easy task). I still found this emulator useful, since I happen to have one of the calculators. By your reasoning, everything in contrib should be moved to main, and contrib should not exist. That's not what I said, nor what I meant. For instance, a Matlab program no doubt depends on Matlab, which is clearly non-free. Some time ago, I was playing with a program that depended on Matlab. it obviously required Matlab to be useful, and the only legal way of obtaining it was to purchase it. I still found the software useful, since I happened to own a license to Matlab. Matlab is non-free, just as the BIOS that you're copying off of the calculator is non-free; both the Matlab program and the emulator go in contrib, for the same reason. I might even have an (expensive) calculator that has Matlab in a ROM, which would make these cases even more parallel. OK, then it's about time someone removes libti68k (Motorola 68000 emulation library for Texas Instruments calculators) from main. Not only does it require a ROM image, it also depends on libticalcs3 and libticables3, both of which require an actual calculator, and hence the firmware (let's call it firmware, to make the analogy easier to see), without which the calculator is useless. Requiring a calculator for a program designed to manipulate that calculator is OK, in the same fashion that requiring a 3c905 is OK for a 3c905 ethernet driver. The difference between software driving a piece of hardware, and an emulator requiring a non-free BIOS block (that happens to be available on a piece of hardware) seems clear to me. While I can understand (even if I disagree with) arguments that they are the same, the conclusion of that line of reasoning seems to be merge contrib entirely back into main, since I can take any non-free library, stick it in a flash, and say look, now it's a hardware dependency!. (I don't have the energy to file a bug against libti68k about this at the moment, but if what you say is accurate, I suspect it should be done.) Now you'll say the calculator doesn't need the firmware to be loaded every time you want to use it, and that would somehow make a difference. Suppose now, that TI released a new model, which didn't have flash memory, so it would need to be reloaded if the batteries were removed, while in all other respects being compatible to the previous models. Would this suddenly render all those libraries non-free? No, because (as has been said already) the existance of cases where you need non-free stuff isn't the issue; the issue is whether there exist cases where you don't. If nobody can use the software without needing non-free data, the software is (at best) contrib. If some people can use it without that data, it can go in main, regardless of the existance of people who can't. The existance of a free Matlab, or of a free calculator BIOS, would allow the program using Matlab and the BIOS emulator into main. The reason each is (or in the emulator case, should be) in contrib is because a free version of this stuff does not exist, not because non-free versions do exist. Suppose some piece of hardware had a Compact Flash reader, and came with a Compact Flash card containing firmware necessary for the hardware to run. Would this also be non-free? I believe software that only works with this reader would go in contrib, if that's what you mean, unless the data on that card was Free itself. It's a dependency on non-free software. (It's not the same as having the firmware stored in flash memory on a device, since removable devices are expected to be removed, overwritten, or lost; where I'd call a device with a hosed flash broken. (The former I'd sell on eBay as drive only, no packaging, drivers or manuals; the latter I'd expect to see sold AS-IS, UNTESTED.) However, this is a corner case, and I think the simpler cases of simple on-card flash should be dealt with before banging our heads on the corner cases. -- Glenn Maynard
Re: GPL and LGPL issues for LCC, or lack thereof
I'll try to address the Specht case and summarize, and we can call this an end to the discussion if that's what you want. Bruce You can read a case on the nature of consent such as Specht v. Netscape, Bruce which might convince you that we don't necessarily get sufficient consent on Bruce the licenses that we distribute for them to bind as contracts. Specht v. Netscape 2001 (if we are talking about http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07482.PDF ) relies on a theory of final (retail) sale under the California version of the Uniform Commercial Code. The opinion doesn't even contain the word copyright. If you want to argue that the Specht case applies to a distro's or an ISV's use of LGPL code, then you are saying that the (L)GPL isn't enforceable at all in the US unless the copyright holder takes technical measures to require all recipients to read the license. Even this probably isn't true, because what distro or ISV can plausibly claim to be ignorant of the (L)GPL, as the Specht plaintiffs claimed to be ignorant of the arbitration clause in Netscape's license? Here's a precis of those volumes of contract cases (two actually, for which I gave the URLs, both addressing copyright licenses), plus Specht: LGPL an illusory contract (a factual question, the criteria for which are discussed in Fosson) or not enough consent to bind as contract (a factual question, discussed in Specht) = no contract = copyright law applies, and in the absence of a positive defense such as fair use, likely to succeed on merits. Alternately, valid contract and violation of terms (a factual question, Sun) = likely to succeed on merits; likely to succeed on merits and terms are license restrictions (vs. contractual covenants, a factual question, Sun) = conduct is outside license and copyright law applies. Copyright law applies = automatic presumption of irreparable harm; Irreparable harm and likely to succeed on merits = preliminary injunction. That's the entire scope of what I claim to have read in those appellate decisions. If it's correct, the only open question is whether the limits on the exception granted in LGPL Section 6 permit the hypothesized conduct of the ISV and/or the distro. The remaining factual issues do appear to me to be clear in the LGPL (the Fosson criteria succeed and Specht doesn't fit the facts), but don't even affect the conclusion (both contract and no contract cases are covered). You also claim that the LGPL doesn't require constructive availability of tools required to exercise the right to modify, that the (L)GPL is a unilateral and unconditional grant of rights under some theory other than contract, and that the act of distribution is somehow separable from the terms of a commercial software license. I believe that I have already adequately refuted these assertions. Did I miss any other arguments? Cheers, - Michael
Re: LCC and blobs
Peter Van Eynde [EMAIL PROTECTED] writes: I think I'm starting to understand your point of view. So _any_ use of the software without using non-DFSG data makes it free, right? Any reasonable use. Printing out a firmware not found message doesn't count! But what if loading the firmware is not required? That if the device was warm-booted in another OS? (I know there are technical limitations here) Would the driver-firmware relation still be a depends? Then there's a dependency on the other OS instead, and *it* either has a dependency on the driver, or is free software and we can just do it the same way they do. So now you have a dependency on non-free software, and several ways to fulfill it. If you could express the entire software dependency tree in free software, then the software at the root of that tree is also free and can go in Debian. Oh, I have another use for the ipw2100 driver without firmware: it can recognise the card from the pci-id information. :-) Great, so can lspci. Waste of time and archive space. It's a driver, not a card prober. Please at least read Policy on what Depends means first. If you I see no mention of this in version 3.6.1.1. There is: |5.6.9. Package interrelationship fields - see chapter 7 |7.2. Binary Dependencies - is for debian packages. And has: |... |The `Depends' field should be used if the depended-on package is required |for the depending package to provide a significant amount of |functionality. |... |7.6. Relationships between source and binary packages -N/A There is no mention of dependency of packages on external data that fall outside the packaging system. So what meaning do you mean? If you extend the rules for packages to firmware then the question becomes what significant amount of functionality is. In the past it was used for can run, optional libraries were Suggested in. Firmware that is optional is, well, optional. Suggests is a perfectly reasonable expression of that. Depends is not. [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls ipw2100-1.0.fwipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw ipw2100-1.1.fwipw2100-1.2.fwipw2100-1.3.fwisl3890 ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ mv: cannot move `t' to a subdirectory of itself, `t/t' [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l t/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko The module loaded without firmware, not? It detected my card, but failed to load the firmware. ipw2100: Detected Intel PRO/Wireless 2100 Network Connection ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. ipw2100: eth1: ipw2100_get_firmware failed: -2 ipw2100: eth1: Failed to power on the adapter. ipw2100: eth1: Failed to start the firmware. ipw2100Error calling regiser_netdev. ipw2100: probe of :02:02.0 failed with error -5 I would say this is a functional driver. It provides me with useful information about my system. The fact that I cannot connect to a wifi lan is the same situation as with grub not being able to load XP without the XP bootsector, if there were a free firmware with the same API I would be able to load and use it. No. It's a driver for an ipw 2100; it has an ipw2100 and can't drive it. It's not functional -- it failed to power on the adapter. In the case of Windows and Grub, Grub is a generic bootloader. It can usefully boot Linux, Hurd, or NetBSD without access to an XP bootsector. It has significant useful functionality. What device can the ipw2100 driver drive without the firmware? Making Debian uninstallable because of mistaken beliefs is too much and I care enough to resists this. This certainly doesn't make Debian uninstallable. All the drivers in question can move to contrib. It just ensures that Debian ships only free software in Debian main. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Glenn Maynard [EMAIL PROTECTED] writes: On Sat, Dec 18, 2004 at 01:28:46AM +0100, Måns Rullgård wrote: I'm convinced enough. Some time ago, I was playing around with an emulator for Texas Instruments calculators. It obviously required a ROM image to be useful, and the only legal way of obtaining one was dumping it from your own calculator (an easy task). I still found this emulator useful, since I happen to have one of the calculators
Accepted preseed 1.02 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Dec 2004 20:04:01 -0500 Source: preseed Binary: file-preseed initrd-preseed network-preseed preseed-common Architecture: source all Version: 1.02 Distribution: unstable Urgency: low Maintainer: Debian Install System Team [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: file-preseed - Load debconf preseed file (udeb) initrd-preseed - Load debconf preseed file from /preseed.cfg on the initrd (udeb) network-preseed - Download debconf preseed file (udeb) preseed-common - Common files for preseeding (udeb) Closes: 276001 283680 Changes: preseed (1.02) unstable; urgency=low . * Joey Hess - Not intended for sarge. - Split out preseed-common to allow multiple preseed packages to exist on one image w/o replacing each other out of existence. Closes: #283680 - Add initrd-preseed package, which loads a preseed file (always /preseed.cfg if it exists) from the initrd during d-i boot. Closes: #276001 * Updated translations: - Bulgarian (bg.po) by Ognyan Kulev - Greek, Modern (1453-) (el.po) by Greek Translation Team - Finnish (fi.po) by Tapio Lehtonen - French (fr.po) by French Team - Latvian (lv.po) by Aigars Mahinovs - Romanian (ro.po) by Eddy Petrisor - Russian (ru.po) by Russian L10N Team Files: 58c2503f4c9f7dc3277a44250681d49b 598 debian-installer optional preseed_1.02.dsc cdd7d15cf205ed36f2a7c38b6fdd42fa 21711 debian-installer optional preseed_1.02.tar.gz 793a8decf3513362269f3513934e313e 9750 debian-installer standard preseed-common_1.02_all.udeb b20c43b62be3d61b5a0bb6dca293154b 2360 debian-installer standard network-preseed_1.02_all.udeb 999cfdf531b98e546914d57ff9242403 2254 debian-installer optional file-preseed_1.02_all.udeb 3436d366353a576f3f5aa34bf89e5923 894 debian-installer extra initrd-preseed_1.02_all.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwkWb2tp5zXiKP0wRArTaAJwOWMDcSatc7wXtvcuwL/1nwDwj4wCgrjTT BehstKgZ1AY+RubwftnCPDs= =NMkf -END PGP SIGNATURE- Accepted: file-preseed_1.02_all.udeb to pool/main/p/preseed/file-preseed_1.02_all.udeb initrd-preseed_1.02_all.udeb to pool/main/p/preseed/initrd-preseed_1.02_all.udeb network-preseed_1.02_all.udeb to pool/main/p/preseed/network-preseed_1.02_all.udeb preseed-common_1.02_all.udeb to pool/main/p/preseed/preseed-common_1.02_all.udeb preseed_1.02.dsc to pool/main/p/preseed/preseed_1.02.dsc preseed_1.02.tar.gz to pool/main/p/preseed/preseed_1.02.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-sparc-2.6 0.04 (sparc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Dec 2004 16:09:54 -0500 Source: linux-kernel-di-sparc-2.6 Binary: nic-modules-2.6.8-1-sparc32-di xfs-modules-2.6.8-1-sparc32-di ext3-modules-2.6.8-1-sparc32-di md-modules-2.6.8-1-sparc64-di ipv6-modules-2.6.8-1-sparc64-di nic-modules-2.6.8-1-sparc64-di plip-modules-2.6.8-1-sparc32-di ide-modules-2.6.8-1-sparc64-di scsi-common-modules-2.6.8-1-sparc32-di ext3-modules-2.6.8-1-sparc64-di ppp-modules-2.6.8-1-sparc64-di scsi-common-modules-2.6.8-1-sparc64-di kernel-image-2.6.8-1-sparc32-di fat-modules-2.6.8-1-sparc64-di ipv6-modules-2.6.8-1-sparc32-di fat-modules-2.6.8-1-sparc32-di reiserfs-modules-2.6.8-1-sparc32-di cdrom-core-modules-2.6.8-1-sparc32-di reiserfs-modules-2.6.8-1-sparc64-di md-modules-2.6.8-1-sparc32-di scsi-core-modules-2.6.8-1-sparc64-di usb-modules-2.6.8-1-sparc64-di scsi-core-modules-2.6.8-1-sparc32-di plip-modules-2.6.8-1-sparc64-di ppp-modules-2.6.8-1-sparc32-di cdrom-core-modules-2.6.8-1-sparc64-di kernel-image-2.6.8-1-sparc64-di xfs-modules-2.6.8-1-sparc64-di Architecture: source sparc Version: 0.04 Distribution: unstable Urgency: low Maintainer: Debian Install System Team [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: cdrom-core-modules-2.6.8-1-sparc32-di - CDROM support (udeb) cdrom-core-modules-2.6.8-1-sparc64-di - CDROM support (udeb) ext3-modules-2.6.8-1-sparc32-di - EXT3 filesystem support (udeb) ext3-modules-2.6.8-1-sparc64-di - EXT3 filesystem support (udeb) fat-modules-2.6.8-1-sparc32-di - FAT filesystem support (udeb) fat-modules-2.6.8-1-sparc64-di - FAT filesystem support (udeb) ide-modules-2.6.8-1-sparc64-di - IDE drivers (udeb) ipv6-modules-2.6.8-1-sparc32-di - IPv6 driver (udeb) ipv6-modules-2.6.8-1-sparc64-di - IPv6 driver (udeb) kernel-image-2.6.8-1-sparc32-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.8-1-sparc64-di - Linux kernel binary image for the Debian installer (udeb) md-modules-2.6.8-1-sparc32-di - RAID and LVM support (udeb) md-modules-2.6.8-1-sparc64-di - RAID and LVM support (udeb) nic-modules-2.6.8-1-sparc32-di - Network card modules for Sparc kernels (udeb) nic-modules-2.6.8-1-sparc64-di - Network card modules for Sparc kernels (udeb) plip-modules-2.6.8-1-sparc32-di - PLIP drivers (udeb) plip-modules-2.6.8-1-sparc64-di - PLIP drivers (udeb) ppp-modules-2.6.8-1-sparc32-di - PPP drivers (udeb) ppp-modules-2.6.8-1-sparc64-di - PPP drivers (udeb) reiserfs-modules-2.6.8-1-sparc32-di - Reiser filesystem support (udeb) reiserfs-modules-2.6.8-1-sparc64-di - Reiser filesystem support (udeb) scsi-common-modules-2.6.8-1-sparc32-di - Very common SCSI drivers (udeb) scsi-common-modules-2.6.8-1-sparc64-di - Very common SCSI drivers (udeb) scsi-core-modules-2.6.8-1-sparc32-di - Core SCSI subsystem (udeb) scsi-core-modules-2.6.8-1-sparc64-di - Core SCSI subsystem (udeb) usb-modules-2.6.8-1-sparc64-di - USB support (udeb) xfs-modules-2.6.8-1-sparc32-di - XFS filesystem support (udeb) xfs-modules-2.6.8-1-sparc64-di - XFS filesystem support (udeb) Changes: linux-kernel-di-sparc-2.6 (0.04) unstable; urgency=low . * Include drivers/net/dmfe.o which was in joshk's 0.03, which was never checked into svn. Files: b80b40e16c6aa86e4e05097ed7ced78c 1666 debian-installer optional linux-kernel-di-sparc-2.6_0.04.dsc 1f08ac16a8a8a5bf65cee39da1c0e985 3659 debian-installer optional linux-kernel-di-sparc-2.6_0.04.tar.gz 1fd1941f26e5981181faa47b146193e5 1442780 debian-installer extra kernel-image-2.6.8-1-sparc64-di_0.04_sparc.udeb 423ec0b0228bc4e715617f597895f216 658268 debian-installer standard nic-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 433825c8b7f8190b6208728b474f6fc5 56840 debian-installer optional ppp-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 1764975de68e1df68ccb3e2b0ae741f1 62616 debian-installer standard ide-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 055ae19f9afda4e0adc40ea99e97a30d 55150 debian-installer standard cdrom-core-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 705461fe535d675e04f8bcaca159e2cc 54802 debian-installer standard scsi-core-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 2b9a4639b2997848cf35330cf0658803 300622 debian-installer standard scsi-common-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 6a39f713ddfc2492d1964d1b912cf773 27688 debian-installer optional plip-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb f83541e38fa9f4bfe4d35c5a8320194a 139034 debian-installer extra ipv6-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 9843e0e3fabe538940b5bf6a902aa4b0 99294 debian-installer standard ext3-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb dda72a6048a87116ebee7b1ba2550b63 164188 debian-installer standard reiserfs-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb c6a2dbf19b98d433c0c11f843be026fa 271572 debian-installer standard xfs-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb 01886db01b14b2e5b68781cb01918f30 35124 debian-installer extra fat-modules-2.6.8-1-sparc64-di_0.04_sparc.udeb
Accepted linux-kernel-di-sparc 0.63 (sparc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2004 18:09:05 -0500 Source: linux-kernel-di-sparc Binary: reiserfs-modules-2.4.27-1-sparc64-di scsi-core-modules-2.4.27-1-sparc64-di usb-modules-2.4.27-1-sparc64-di firmware-modules-2.4.27-1-sparc64-di md-modules-2.4.27-1-sparc32-di reiserfs-modules-2.4.27-1-sparc32-di cdrom-core-modules-2.4.27-1-sparc32-di scsi-core-modules-2.4.27-1-sparc32-di md-modules-2.4.27-1-sparc64-di ext3-modules-2.4.27-1-sparc32-di ppp-modules-2.4.27-1-sparc32-di ipv6-modules-2.4.27-1-sparc64-di scsi-modules-2.4.27-1-sparc64-di firewire-core-modules-2.4.27-1-sparc64-di xfs-modules-2.4.27-1-sparc32-di loop-modules-2.4.27-1-sparc32-di ide-modules-2.4.27-1-sparc64-di scsi-modules-2.4.27-1-sparc32-di nic-modules-2.4.27-1-sparc64-di xfs-modules-2.4.27-1-sparc64-di nic-modules-2.4.27-1-sparc32-di kernel-image-2.4.27-1-sparc32-di loop-modules-2.4.27-1-sparc64-di ppp-modules-2.4.27-1-sparc64-di cdrom-core-modules-2.4.27-1-sparc64-di ext3-modules-2.4.27-1-sparc64-di ipv6-modules-2.4.27-1-sparc32-di kernel-image-2.4.27-1-sparc64-di Architecture: source sparc Version: 0.63 Distribution: unstable Urgency: low Maintainer: Debian Install System Team [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: cdrom-core-modules-2.4.27-1-sparc32-di - CDROM support (udeb) cdrom-core-modules-2.4.27-1-sparc64-di - CDROM support (udeb) ext3-modules-2.4.27-1-sparc32-di - EXT3 filesystem support (udeb) ext3-modules-2.4.27-1-sparc64-di - EXT3 filesystem support (udeb) firewire-core-modules-2.4.27-1-sparc64-di - Core FireWire drivers (udeb) firmware-modules-2.4.27-1-sparc64-di - Firmware request modules (udeb) ide-modules-2.4.27-1-sparc64-di - IDE drivers (udeb) ipv6-modules-2.4.27-1-sparc32-di - IPv6 driver (udeb) ipv6-modules-2.4.27-1-sparc64-di - IPv6 driver (udeb) kernel-image-2.4.27-1-sparc32-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.4.27-1-sparc64-di - Linux kernel binary image for the Debian installer (udeb) loop-modules-2.4.27-1-sparc32-di - Loopback filesystem support (udeb) loop-modules-2.4.27-1-sparc64-di - Loopback filesystem support (udeb) md-modules-2.4.27-1-sparc32-di - RAID and LVM support (udeb) md-modules-2.4.27-1-sparc64-di - RAID and LVM support (udeb) nic-modules-2.4.27-1-sparc32-di - SBus/PCI network card modules for Sparc32/64 kernels (udeb) nic-modules-2.4.27-1-sparc64-di - SBus/PCI network card modules for Sparc32/64 kernels (udeb) ppp-modules-2.4.27-1-sparc32-di - PPP drivers (udeb) ppp-modules-2.4.27-1-sparc64-di - PPP drivers (udeb) reiserfs-modules-2.4.27-1-sparc32-di - Reiser filesystem support (udeb) reiserfs-modules-2.4.27-1-sparc64-di - Reiser filesystem support (udeb) scsi-core-modules-2.4.27-1-sparc32-di - Core SCSI subsystem (udeb) scsi-core-modules-2.4.27-1-sparc64-di - Core SCSI subsystem (udeb) scsi-modules-2.4.27-1-sparc32-di - SBus/PCI SCSI card modules for Sparc32/64 kernels (udeb) scsi-modules-2.4.27-1-sparc64-di - SBus/PCI SCSI card modules for Sparc32/64 kernels (udeb) usb-modules-2.4.27-1-sparc64-di - USB support (udeb) xfs-modules-2.4.27-1-sparc32-di - XFS filesystem support (udeb) xfs-modules-2.4.27-1-sparc64-di - XFS filesystem support (udeb) Closes: 285741 Changes: linux-kernel-di-sparc (0.63) unstable; urgency=low . * Joey Hess - Add usb-modules to try to get usb keyboard to work. Only for sparc64 kernel, sparc32 has no usb modules. - Increase build-dep on kernel-wedge, needed to use common usb-modules list. - Add sungem to sparc64 nic-modules. - Built on a system with a fixed -sparc32 modules.dep, so with crc32 module and other sparc32 deps fixed. Closes: #285741 Files: 5f29ba16daf78514bd011916016604ca 1693 debian-installer optional linux-kernel-di-sparc_0.63.dsc 005ef48ef36b68ee4a39a16f80f82a02 16444 debian-installer optional linux-kernel-di-sparc_0.63.tar.gz e4f8baa77bf45a4271e6001411ec389d 970200 debian-installer extra kernel-image-2.4.27-1-sparc32-di_0.63_sparc.udeb 29bfc5fb068954e7f07c28052a254132 72076 debian-installer standard nic-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb b012aacd18eb2b1ecdd07b2f56e2ebc7 48810 debian-installer optional ppp-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb 6a97234ee8307a7bfa6b39e466705673 29784 debian-installer standard cdrom-core-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb 43e4bc04c1cc0dc3896b7fdcf048670b 53514 debian-installer standard scsi-core-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb ceba631c36b10a916005058569c6e0b5 97100 debian-installer standard scsi-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb ab31364ae81af609a29f9f8560258992 9812 debian-installer standard loop-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb cab6aa116b3d837eda17b4e0252452b5 130266 debian-installer extra ipv6-modules-2.4.27-1-sparc32-di_0.63_sparc.udeb 0818df87c3c4952d4b2f954b262b91c7 86472 debian-installer standard
Accepted localechooser 0.01 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 28 Nov 2004 11:08:35 +0100 Source: localechooser Binary: localechooser Architecture: source all Version: 0.01 Distribution: unstable Urgency: low Maintainer: Debian Install System Team [EMAIL PROTECTED] Changed-By: Christian Perrier [EMAIL PROTECTED] Description: localechooser - Choose language/country/locale (udeb) Changes: localechooser (0.01) unstable; urgency=low . * New package built by merging languagechooser and countrychooser First published in d-i repository. Specific changelog starts here. This release will close the following languagechooser bugs: - 265085: languagechooser and countrychooser being not different packages anymore, the user may change the language at any time. Also closes 268815 and 272325 - 271258: picking a C locale is now possible - 259104: only display languages marked as OK for it when debian-installer/framebuffer=false * Christian Perrier - removed unused replace_translations - Welsh properly spelled in Welsh - Add entries for post-sarge supported languages Files: 5fb63f52cb3193ab7dca7889be2a4c09 656 debian-installer standard localechooser_0.01.dsc a83dfcd715b7d53325b4727fe205b9f4 56217 debian-installer standard localechooser_0.01.tar.gz fe1df09f0021b86668c5a488027230aa 62350 debian-installer standard localechooser_0.01_all.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBqaWI1OXtrMAUPS0RAlbdAJ9P+DJel6P9nPGw/yizJo6ftB2gGQCfUNwy nU0zNfYStEw5VeN9BYT4LbA= =Tvyv -END PGP SIGNATURE- Accepted: localechooser_0.01.dsc to pool/main/l/localechooser/localechooser_0.01.dsc localechooser_0.01.tar.gz to pool/main/l/localechooser/localechooser_0.01.tar.gz localechooser_0.01_all.udeb to pool/main/l/localechooser/localechooser_0.01_all.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gst-editor 0.8.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Dec 2004 01:10:59 -0500 Source: gst-editor Binary: gstreamer-editor Architecture: source i386 Version: 0.8.0-1 Distribution: unstable Urgency: low Maintainer: David I. Lehn [EMAIL PROTECTED] Changed-By: David I. Lehn [EMAIL PROTECTED] Description: gstreamer-editor - GStreamer Pipeline Editor and other GUI tools Closes: 264757 286032 Changes: gst-editor (0.8.0-1) unstable; urgency=low . * New upstream (Closes: #286032) * Ack NMU (Closes: #264757) * debian/gstreamer-editor.manpages, debian/gst-inspect-gui.1: * Remove, included in upstream * debian/watch: * Add * debian/control: * Add Build-Depends: intltool * debian/gstreamer-editor.docs: * Remove IDEAS Files: c312f311f6ede41f3d5da0b6fb484188 853 gnome optional gst-editor_0.8.0-1.dsc 00e004ad68f9b90138b87ec729cb1607 491192 gnome optional gst-editor_0.8.0.orig.tar.gz 640219fc930c6d0e6906edc80bdddbf6 2769 gnome optional gst-editor_0.8.0-1.diff.gz 7176b10a2b6c40b4809c730421715a91 220194 gnome optional gstreamer-editor_0.8.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwphHPIQIWBo7SN4RAvBaAKCkaMGtyW2yiFZ2UZzAjAmZtxt6ZACdE+Fx 8gc8Wx7hr18TEnNoCJpdQTQ= =5D4K -END PGP SIGNATURE- Accepted: gst-editor_0.8.0-1.diff.gz to pool/main/g/gst-editor/gst-editor_0.8.0-1.diff.gz gst-editor_0.8.0-1.dsc to pool/main/g/gst-editor/gst-editor_0.8.0-1.dsc gst-editor_0.8.0.orig.tar.gz to pool/main/g/gst-editor/gst-editor_0.8.0.orig.tar.gz gstreamer-editor_0.8.0-1_i386.deb to pool/main/g/gst-editor/gstreamer-editor_0.8.0-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dosbox 0.63-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Dec 2004 16:00:08 +0100 Source: dosbox Binary: dosbox Architecture: source i386 Version: 0.63-2 Distribution: unstable Urgency: low Maintainer: Peter Veenstra [EMAIL PROTECTED] Changed-By: Peter Veenstra [EMAIL PROTECTED] Description: dosbox - A x86 emulator with Tandy/Herc/CGA/EGA/VGA graphics, sound and DO Closes: 278598 283570 284032 284500 285645 Changes: dosbox (0.63-2) unstable; urgency=low . * Fix compilation on amd64/gcc-4.0 (Closes: #285645) * Fix compilation on kfreebsd-gnu (Closes: #278598) * Patched code up to cvs of 16 december 2004. Fixes various small bugs. * Improved documentation (Closes: #284500, #283570) * Build on unstable (Closes: #284032) * Change maintainer emailaddress. Files: 88a579132f194cd2ba7b39030e9d46a0 883 otherosfs optional dosbox_0.63-2.dsc c2cdb91ed2ea604265f9c9ca4955a43c 12400 otherosfs optional dosbox_0.63-2.diff.gz eed37f829a31f6fc77a0d997d7528505 391844 otherosfs optional dosbox_0.63-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwpIxYDBbMcCf01oRAq59AJ9vji+ee/82WnxMDTjJFmpDdSyBUgCgsCpV yS52LGrzTdkya5ibXV6ZOpE= =Ar6b -END PGP SIGNATURE- Accepted: dosbox_0.63-2.diff.gz to pool/main/d/dosbox/dosbox_0.63-2.diff.gz dosbox_0.63-2.dsc to pool/main/d/dosbox/dosbox_0.63-2.dsc dosbox_0.63-2_i386.deb to pool/main/d/dosbox/dosbox_0.63-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ganglia-monitor-core 2.5.7-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 11 Dec 2004 18:07:29 + Source: ganglia-monitor-core Binary: ganglia-monitor libganglia1-dev libganglia1 gmetad Architecture: source i386 Version: 2.5.7-2 Distribution: unstable Urgency: low Maintainer: Stuart Teasdale [EMAIL PROTECTED] Changed-By: Stuart Teasdale [EMAIL PROTECTED] Description: ganglia-monitor - A cluster system monitoring daemon gmetad - Meta-daemon for ganglia cluster monitoring toolkit libganglia1 - Ganglia cluster system monitor toolkit (shared libraries) libganglia1-dev - Ganglia cluster system monitor toolkit (devel libraries) Closes: 285212 Changes: ganglia-monitor-core (2.5.7-2) unstable; urgency=low . * Autoreconfed again for mips/mipsel shared library support. Closes: #285212. Files: b0b8193b6999e455d9ad537ad71d1640 754 net optional ganglia-monitor-core_2.5.7-2.dsc 147619c8b39876ee9b196ace72789bc2 314359 net optional ganglia-monitor-core_2.5.7-2.diff.gz f2c85fe13f646ab86e0bb036ae61e0a6 138188 net optional ganglia-monitor_2.5.7-2_i386.deb 08fc18628079e5ec3699a66140a9a8af 91838 net optional gmetad_2.5.7-2_i386.deb 3007d7dc0766408f88e63979a5987cce 90236 libs optional libganglia1_2.5.7-2_i386.deb 89a06cf47bfe27d8647c3119ec3e7514 119670 libdevel optional libganglia1-dev_2.5.7-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBwqesITGblEwaW+URAngDAKCB8w/DjSjhrVSmudaB/O5it3DTmQCeL5dl +w7IrUEa+z0POyBIS605N6A= =GC9R -END PGP SIGNATURE- Accepted: ganglia-monitor-core_2.5.7-2.diff.gz to pool/main/g/ganglia-monitor-core/ganglia-monitor-core_2.5.7-2.diff.gz ganglia-monitor-core_2.5.7-2.dsc to pool/main/g/ganglia-monitor-core/ganglia-monitor-core_2.5.7-2.dsc ganglia-monitor_2.5.7-2_i386.deb to pool/main/g/ganglia-monitor-core/ganglia-monitor_2.5.7-2_i386.deb gmetad_2.5.7-2_i386.deb to pool/main/g/ganglia-monitor-core/gmetad_2.5.7-2_i386.deb libganglia1-dev_2.5.7-2_i386.deb to pool/main/g/ganglia-monitor-core/libganglia1-dev_2.5.7-2_i386.deb libganglia1_2.5.7-2_i386.deb to pool/main/g/ganglia-monitor-core/libganglia1_2.5.7-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
