Re: [OT:HUMOR] Re: software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Oct 10, 2004 at 11:37:06PM -0500, Adam Heath wrote: Price for Commercial Software: > > Adobe Illustrator CS - 90.00 > > Adobe Acrobat 6.0 Professional - 100.00 > > McAfee Personal Firewall Plus 2004 v. 5.0 - 20.00 > > Adobe Photoshop Elements 2.0 - 40.00 > > Macromedia Studio MX 2004 - 180.00 > > Abode InDesign CS - 100.00 > > Microsoft Windows Server 2003 Enterprise Edition - 200.00 > > Adobe Photoshop 7.0 - 60.00 > > Adobe Premiere Pro 1.5 - 100.00 > > QuickBooks Premier Edition 2004 - 80.00 > > Microsoft Office XP Pro - 100.00 > > Symantec pcANYWHERE 11.0 - 80.00 > > Macromedia Studio MX 2004 - 180.00 > > 3D Home Architect Landscape Design Deluxe 6.0 - 29.99 Cost: several hundreds dollar and vendor lock-in Price for libre Software: > inkscape - 0.00 > xpdf - 0.00 > gimp-* - 0.00 > emacs - 0.00 > scribus - 0.00 > gimp - 0.00 > kino - 0.00 > gnucash - 0.00 > openoffice - 0.00 > ssh - 0.00 > qcad, but only does 2d - 0.00 Cost: zero dollars and pure freedom! Membership has its privedleges! - -Kev - -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBahJZAWAAuqdWA9cRAqdwAJ4wFh1f9sjIVC+29CYH3yXmvKL09QCeIhFU l4X/TawwRI6ynL91ISgAxrE= =vAOO -END PGP SIGNATURE-
Re: J?rg Schilling is damage; the community should route around him
Original Message Subject: Re: J?rg Schilling is damage; the community should route around him Date: Mon, 11 Oct 2004 01:45:22 -0400 From: Sean Harshbarger <[EMAIL PROTECTED]> To: Steve Kemp <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Steve Kemp wrote: On Sat, Oct 09, 2004 at 01:18:50PM +0200, Jose Carlos Garcia Sogo wrote: El s??b, 09-10-2004 a las 00:04 -0500, Branden Robinson escribi??: It's time to fork. Let us work with the rest of the community to standardize on a new set of tools based on the last free version of cdrtools, thank Mr. Schilling for his valuable contributions, and leave him be to pursue his interests in proprietary software without interference or argument from us. He appears to regard placing his work under the plain vanilla GNU GPL that works for so many projects as an act that he cannot perform in good conscience. Let us stop placing him in that uncomfortable position. I agree with you. And I guess that the "good" direction would be pushing libburn, which seems a bit stalled right now. Also, DVD[-R[W], +R[W]] support should be added to it. On top of that library, it would be easier to build command line and GUI oriented programs, which could drop at that moment cdrecord. I wrote about this only a few days ago in a brief piece which was included in planet.d.o. At the time I was directed very quickly towards libburn. Using a library seems a lot saner than taking over any of the cdrecord codebase. If necessary a command line wrapper around the library could emulate the cdrecord command line options. I couldn't gain access to the libburn CVS repository, but I did download the .0.2 version and the test code worked for me. I was able to burn an image using it fairly quickly, although I can't say how stable the code is generally. (The API documentation was nice). But what is needed there is people with time and access to different drives. Perhaps people behind dvd+rw-tools could be interested, and some company out there could sponsor this piece of software. I think a few individuals would be happy to host the code and work on it, but hardward testing really is the stumbling block - as is portability testing. The problem with cdrecord is that it works, and though there are some glitches that people would like to see fixed, writing another different tool is only that: rewriting. And using the same language, i.e. there is no perl vs. python, perl vs. php, ... It does seem a little tedious reimplimenting code which already exists, and mostly works. This either suggests: 1) It isn't worth doing, and we just put up with the maintainer. 2) It shuld be done in a better way (library based?) 3) Forking a free-er/older version. Given the vehemence of J?rg to SuSE and the other people "illegally distributing inofficial versions (sic)" I strongly suggest option 3 is not a good idea - if nothign else it will lead to confusion amongst users. Perhaps having a Debian package of libburn would be a good starting point - then popular programs can be patched to work with it? I already put the libburn package in unstable a couple months back in hopes that more people would adopt/help it out. The libburn team has been somewhat idle last month or so, and I think this is the type of poking they need to continue it. The api is IMO nice, but the library is still missing some things. Only thing they might want to do later on is goto a lgpl versus the gpl they have now. A wrapper around libburn could give us the possibility of using that in place of cdrecord. A few have mentioned interest in this so that they could easily convert favorite apps, IE nautilus-cd and xcdroast. As the main developer of the Coaster Project for gnome, I have already embraced libburn as a viable solution to this new age of disc burning, and only want to see more developers jump on the bandwagon to help libburn get better. -Sean signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: Common set of debconf templates
Quoting Marc Haber ([EMAIL PROTECTED]): > Do we have infrastructure to handle different answers for the same > question? Maybe I'd like to have a different dbadmin password on my > postgresql database than on mysql? Yes, we have it through the REGISTER command in the debconf protocol (see man debconf-devel)where you can create several independent questions from the same template. quote from debcond-devel(7): QUESTIONS A question is an instantiated template. By asking debconf to display a question, your config script can interact with the user. When debconf loads a templates file (this happens whenever a config or postinst script is run), it automatically instantiates a question from each template. It is actually possible to instantiate several independent questions from the same template (using the REGISTER com- mand), but that is rarely necessary. Templates are static data that comes from the templates file, while questions are used to store dynamic data, like the current value of the question, whether a user has seen a question, and so on. Keep the distinction between a template and a question in mind, but don't worry too much about it. REGISTER template question This creates a new question that is bound to a template. By default each template has an asso- ciated question with the same name. However, any number of questions can really be associated with a template, and this lets you create more such questions. This is quite different from *shared* templates: SHARED TEMPLATES It's actually possible to have a template and a question that are shared among a set of packages. All the packages have to provide an identical copy of the template in their templates files. This can be useful if a bunch of packages need to ask the same question, and you only want to bother the user with it once. Shared templates are generally put in the shared/ pseudo-directory in the debconf tem- plate namespace.
Re: PROPOSAL: debian-mozilla@lists.debian.org
On Sun, Oct 10, 2004 at 10:51:21PM +0200, Aurelien Jarno wrote: > > I think that creating a such list is a very good idea. Currently the > only way to contact mozilla package's maintainers is to do an apt-cache > search mozilla and grep for the email adresses. FYI there is currently Or send a mail to @packages.debian.org -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 If you iz watching dis in da UK, you may remember me from da telly. If you iz in Belgium you iz living in a shit hole. --Ali G (Ali G indahouse)
RFA: quik -- Bootloader for PowerMac or CHRP systems
Package: wnpp Severity: normal Hi, I intend to orphan the PowerPC bootloader quik. I haven't used it myself for a long time, and don't feel like spending the time and effort needed for getting it in shape again. Apart from the two important bugs already in the bts, quik lacks the capability of loading a ramdisk, which makes it quite useless with the current official kernels. I do hope that someone steps up and takes over. If this does not happen within a week, I will orphan the package for good. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: about volatile.d.o/n
martin f krafft <[EMAIL PROTECTED]> schrieb: > also sprach Marco d'Itri <[EMAIL PROTECTED]> [2004.10.08.2029 +0200]: >> Is looking up .org domains in the wrong whois server enough to be >> considered "useless"? > > I found it rather useless in woody when the .org registrar changed. I'd say it is a bug in whois to ship this information in the binary, instead of some file in /etc/. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFD: Draft for a volatile.d.o policy
Sven Mueller <[EMAIL PROTECTED]> wrote: > == > > Draft for a volatile.debian.org packaging and update policy. > [...] > Policy for v.d.o > [...] > - A new version uploaded to v.d.o should restrict itself to new code >which is needed to keep fulfilling the original task of the package >when it first entered v.d.o. Why not: "of the package when the last stable distribution was released"? Besides that, it sounds quite well. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: about volatile.d.o/n
* Florian Weimer ([EMAIL PROTECTED]) [041010 16:40]: > * Andreas Barth: > > - volatile is not "just another place" for backports, but should only > > contain changes to stable programs that are necessary to keep them > > functional; > Can volatile receive critical updates which are usually not applied to > stable because backports are not available for some reason? Are you speaking about mozilla? ;) Well, that's definitly not the first purpose of volatile, and so, I would like to postpone it a bit. However, in the long run, I think you're right about adding newer packages if they fix security issues, and we can't fix them otherwise. But I think it needs more than just some consideration how to do this in a non-breaking way. 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: RFC: best practice creating database
On Sat, Oct 09, 2004 at 08:02:22AM +0200, Andreas Tille wrote: > On Fri, 8 Oct 2004, Stefan Hornburg wrote: > > >First of all documentation. > Definitely! I was about to write some, to at least have an overview of what commands are available. Unfortunately, I haven't found the time yet. Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: Automake & dependency tracking
Wouter Verhelst wrote: > Is there any other reason why we would still need to use automake's > dependency tracking anyway? I don't think so. You may want to use it while working on the package, but it seems like a fine idea to turn it off when finalizing the package.
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sunday 10 October 2004 14:58, Jeroen van Wolffelaar wrote: > On Sun, Oct 10, 2004 at 01:21:44PM +0200, Christian Surchi wrote: > > Il sab, 2004-10-09 alle 17:48, martin f krafft ha scritto: > > > > I think it's not a right comparison, nullmail is an MTA. and > > > > AFAIK, msmtp is not an MTA: > > > > > > it transports mail to the next relay, right? > > > nullmailer is a "simple relay-only mail transport agent." > > > > > > what's the difference? > > > > Deep difference. Our mail-transport-agents are able to behave as daemon, > > listening on 25 port. > > This is not true, since not required by policy. Policy says: The policy does not define what a MTA is, but requires that all MTA packages have newalises command although it might do nothing. IMHO a MTA must be capable acts as a client and as a server to transfer messages between machines and is responsible for properly routing messages to their destination, e.g. RFC 974. msmtp does not do all of these, therefor it is not a MTA, and might have nothing to do with /usr/sbin/sendmail. > 11.6. Mail transport, delivery and user agents > > | (...) the interface to send a mail message is `/usr/sbin/sendmail' (as > | per the FHS). Right, and that is mandated when you have a MTA with features like described above. This does not mean that telnet is a MTA when invoked like: /usr/bin/telnet mail.host.dom 25 ehlo blabla mail from: _sender_ rcpt to: _recipient_ data write some bits mail-a
Re: about volatile.d.o/n
Christoph Berg <[EMAIL PROTECTED]> wrote: > Re: Henning Makholm in <[EMAIL PROTECTED]> >> Should volatile include updates of packages such as debian-keyring? >> debian-policy and developers-reference? > > Those who need these packages will run Sid anyway. I'd sincerely hope not. The fact that few developers run stable is a contributing factor to the lack of motiviation towards releasing. I don't think many people understand just how old stable currently is. Where possible, I think developers should be encouraged to run at least one stable box... -- Matthew Garrett | [EMAIL PROTECTED]
Re: [OT:HUMOR] Re: software
On Sun, Oct 10, 2004 at 11:37:06PM -0500, Adam Heath wrote: > On Thu, 7 Oct 2004, wrote: > > McAfee Personal Firewall Plus 2004 v. 5.0 - 20.00 > Why? If you really care there's clamav, also for 0.00. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: TG3 firmware report...
* Nathanael Nerode: >> Unless of course the firmware itself is GPL'd, and therefore no one >> can legally give it out without offering the source as well. > > It is GPLed. This is why it hasn't been put in non-free. :-P > Until they do one of these two things, the firmware is not safe to > distribute. Of course it is safe to distribute. What do you fear? That Broadcom might sue you for distributing something that they have written and released under the GPL, and actually have a case? They might as well sue Debian because the toolchain supports the SB-1 architecture. Of course, Debian is free to refrain from distribution for other reasons, but citing legal problems to cover up political decisions is dishonest.
Re: about volatile.d.o/n
* Andreas Barth: >> Can volatile receive critical updates which are usually not applied to >> stable because backports are not available for some reason? > > Are you speaking about mozilla? ;) Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. Other complex packages can easily enter this state, too, especially when sarge has been around for a year or two. Actually, Mozilla's situation is beginning to look rather promising. The distributor community seems to pick up the challenge and issue patches. Of course, if we release 1.6 with sarge (a version that is officially unsupported by upstream), we might not be able to profit from this development. > However, in the long run, I think you're right about adding newer > packages if they fix security issues, and we can't fix them otherwise. > But I think it needs more than just some consideration how to do this in > a non-breaking way. I agree that this has to be decided on a case-by-case basis.
Re: about volatile.d.o/n
Martin Zobel-Helas <[EMAIL PROTECTED]> wrote: > i would like to see some "policy", what, when and under which > circumstances gets included to volatile.d.n. The most sensible policy would be a case by case consideration. Some packages can sanely have the desired features backported [1], and some can't [2]. It's possible that we /could/ write policy that would actually be able to differentiate between the two cases, but it's fairly likely that it would just end up devolving into flamewars about corner cases or misclassification. I'd suggest a team of reasonable people who we trust to make the decisions and liase with package maintainers as appropriate. It's much less effort and it involves much less unhappiness. [1] whois would probably be a good example - if the set of whois servers is suddenly altered, the right thing to do is to change the list rather than update to the latest version [2] If sensible spamassassin functionality is based on a new parsing engine, then backporting that functionality to the old parsing engine may be impossible and is certainly going to involve a sufficiently large amount of new and untested code that any claims about enhanced stability aren't going to be massively convincing -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
Daniel Burrows <[EMAIL PROTECTED]> wrote: > I generally have to resort to backports or unstable when installing Debia= > n=20 > on recent hardware, because we don't update hardware drivers in stable. =20 > Would the kernel and X be candidates for volatile? I think those are arguments for making releases more quickly, rather than anything else. It's a subtley different argument to the volatile one. -- Matthew Garrett | [EMAIL PROTECTED]
Re: TG3 firmware report...
Florian Weimer <[EMAIL PROTECTED]> wrote: > * Nathanael Nerode: >> Until they do one of these two things, the firmware is not safe to >> distribute. > > Of course it is safe to distribute. What do you fear? That Broadcom > might sue you for distributing something that they have written and > released under the GPL, and actually have a case? They might as well > sue Debian because the toolchain supports the SB-1 architecture. Indeed. It's obviously the intention of the licensor to provide code that can be distributed. There are potentially issues with derived works containing a combination of the firmware and other GPLed code, but that's why we'd consider non-free rather than anywhere else. -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > I generally have to resort to backports or unstable when installing Debia= > > n=20 > > on recent hardware, because we don't update hardware drivers in stable. =20 > > Would the kernel and X be candidates for volatile? > > I think those are arguments for making releases more quickly, rather > than anything else. I'm not sure about that, graphics hardware, for example, is far faster moving than stable. And there are forces pulling both ways on the stable release cycle. The kernel and X are both at least somewhat modular, how unrealistic is it to think in terms of backporting just the drivers ? And would that be better? > It's a subtley different argument to the volatile > one. Agreed. Not useless, simply not useful. ;) Most of us must encounter this, I think in terms of 'choose your poison'. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: Bug#275816: ITP: libfile-type-perl -- determine file type using magic
Florian Weimer <[EMAIL PROTECTED]> writes: > File::Type uses magic numbers (typically at the start of a file) to > determine the MIME type of that file. > > File::Type can use either a filename, or file contents, to determine the > type of a file. > > (Another svk dependency.) Does its feature differ from File::MMagic (libfile-mmagic-perl)?
Re: Common set of debconf templates
On Mon, Oct 11, 2004 at 07:36:40AM +0200, Christian Perrier wrote: > SHARED TEMPLATES >It's actually possible to have a template and a question that >are shared among a set of packages. All the packages have to >provide an identical copy of the template in their templates ^ >files. This can be useful if a bunch of packages need to ask >the same question, and you only want to bother the user with it >once. Shared templates are generally put in the shared/ >pseudo-directory in the debconf tem- plate namespace. What happens when the template changes in the template package but is out of sync in the other packages? -- Brian Sutherland
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > Hi all, > > we had some discussion about volatile, and I'm more and more considering to > pick this task up. I think some issues are quite obvious: > > - packages should only go in in cooperation with the maintainers; > > - volatile is not "just another place" for backports, but should only > contain changes to stable programs that are necessary to keep them > functional; Andi, I would like 'must' keep them functional: IOW, voltaile is prepared to drop packages from volatile that are, for whatever reason, unable to keep up with the purpose. It would be sad if volatile ended up containing useless packages! Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
paddy <[EMAIL PROTECTED]> wrote: > On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: >> I think those are arguments for making releases more quickly, rather >> than anything else. > > I'm not sure about that, graphics hardware, for example, is far faster moving > than stable. And there are forces pulling both ways on the stable release > cycle. If we aimed at a new stable release about once a year (which obviously requires providing support for more than one release at once, but still), that would be much less of a problem. > The kernel and X are both at least somewhat modular, how unrealistic > is it to think in terms of backporting just the drivers ? And would that > be better? Adding new drivers is usually fairly easy and probably wouldn't cause any problems. Backporting more recent versions of existing drivers isn't desperately hard, but newer drivers frequently cause regressions in existing hardware support. Without going through a full release cycle, it's difficult to track down whether or not something has broken. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#275816: ITP: libfile-type-perl -- determine file type using magic
* Hilko Bengen: > Florian Weimer <[EMAIL PROTECTED]> writes: > >> File::Type uses magic numbers (typically at the start of a file) to >> determine the MIME type of that file. >> >> File::Type can use either a filename, or file contents, to determine the >> type of a file. >> >> (Another svk dependency.) > > Does its feature differ from File::MMagic (libfile-mmagic-perl)? Not really. Actually File::Type appears to be inferior because it doesn't use the magic(5) configuration files of the system.
Re: Updating scanners and filters in Debian stable (3.1)
On Sun, Oct 10, 2004 at 02:50:35PM +0200, Marc Haber wrote: > On Fri, 8 Oct 2004 10:59:39 +0100, paddy <[EMAIL PROTECTED]> wrote: > >On Wed, Sep 15, 2004 at 09:37:57AM +0200, Marc Haber wrote: > >> It will also happily write to /usr which is IMO a no-no for user > >> binaries. > > > >Where should it write to ? > > > >Would /var/lib or /usr/local be right ? > > /usr/local is the domain of the local admin. Agreed. Can't use that. > /var/lib or /var/cache > might be the right place. But it should be configurable, since some > people mount /var noexec which might break the setup. All told I'm inclined to think this makes it 'not the right place'. > The clean way would be to build .deb files from the downloaded > plugins, and to install them via the package management. I don't believe that everything can, will and should go into package management. (although that may be the answer in this case). I can only imagaine that such debs would best live on volatile. The point of my original question is that I can't see the right place. Another attempt: whatabout under /home/nessus (or whatever)? Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: Updating scanners and filters in Debian stable (3.1)
On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote: > This one time, at band camp, Martin Schulze said: > > A while ago there was a discussion in which it was said that such > > tools are rather useless (or even dangerous) if they don't get their > > database updated in accordance with new viruses/security problems. > > > > Some of these systems are hence not suitable for a stable Debian > > release where updates will only be made for security problems and > > very important bugfixes. > > > > Have you thought about keeping these packages out of sarge or did you > > develop a solution so that users can get their databases updated > > outside of the stable Debian release? > > ClamAV uses freshclam for virus definitions, so the actual database > updates are covered. That being said, there are relatively frequent > changes to the scanning engine as well, leaving me feeling like it may > not be the best choice for a stable release. I do plan to continue > offering out of band up dates on p.d.o, but I am not sure this is the > best way to proceed. Feedback welcome, Stephen, Revisiting your original question. Reading the Debian Policy Manual as I am right now: 2.2.1 The main section ... packages in main ... must not be so buggy that we refuse to support them While you clearly do not refuse, it was argued that the net effect is likely to be just so. Perhaps the question now should be: does volatile modify this? (for example, does volatile count as support for this purpose). Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Matthew Garrett <[EMAIL PROTECTED]> schrieb: > Christoph Berg <[EMAIL PROTECTED]> wrote: >> Re: Henning Makholm in <[EMAIL PROTECTED]> >>> Should volatile include updates of packages such as debian-keyring? >>> debian-policy and developers-reference? >> >> Those who need these packages will run Sid anyway. > > I'd sincerely hope not. The fact that few developers run stable is a > contributing factor to the lack of motiviation towards releasing. I > don't think many people understand just how old stable currently is. > Where possible, I think developers should be encouraged to run at least > one stable box... Which would be painful to use. Some backports - e.g. Adrian Bunk's collection - are really advisable. But even then you know how old woody is. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 11:42:57AM +0100, Matthew Garrett wrote: > paddy <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: > >> I think those are arguments for making releases more quickly, rather > >> than anything else. > > > > I'm not sure about that, graphics hardware, for example, is far faster > > moving > > than stable. And there are forces pulling both ways on the stable release > > cycle. > > If we aimed at a new stable release about once a year (which obviously > requires providing support for more than one release at once, but > still), that would be much less of a problem. I'm wondering if the long-term solution may be to extend security.d.o support for some important subset (say standard, for the sake of argument), allowing the main release cycle a little more freedom to float to a different level if that is where it wants to go. > > The kernel and X are both at least somewhat modular, how unrealistic > > is it to think in terms of backporting just the drivers ? And would that > > be better? > > Adding new drivers is usually fairly easy and probably wouldn't cause > any problems. Backporting more recent versions of existing drivers isn't > desperately hard, That's good ... > but newer drivers frequently cause regressions in > existing hardware support. Without going through a full release cycle, > it's difficult to track down whether or not something has broken. If all drivers are in one large package, then this is a huge problem, but if they can be packaged individually, much less so I think. Even without individual packaging, volatile might one-day still make a home for such things (but I _won't_ be helping! :) It it easy to imagine how one might admit a single driver onto the volatile archive ... Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Andi, On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > - It should allow any administrator to "just use" volatile, as they "just > use" security.d.o, and they should be confident that nothing is broken by > that; It would be great to get some clarification of this. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 12:55]: > On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > > - volatile is not "just another place" for backports, but should only > > contain changes to stable programs that are necessary to keep them > > functional; > I would like 'must' keep them functional: IOW, voltaile is prepared to > drop packages from volatile that are, for whatever reason, unable to keep > up with the purpose. It would be sad if volatile ended up containing > useless packages! Of course we need to reserve the right to drop packages - but, doing that would still be bad. Adding a package to volatile means for me that we are very confident that we can support it till the current debian major release is archived. If we can't do that, we shouldn't have added it in the first place. 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: Bug#275816: ITP: libfile-type-perl -- determine file type using magic
At Mon, 11 Oct 2004 12:47:25 +0200, Hilko Bengen wrote: > Does its feature differ from File::MMagic (libfile-mmagic-perl)? It seems under different license. File::MMagic is The Apache License because it contains mime.magic database based on mod_mime_magic. -- NOKUBI Takatsugu E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] / [EMAIL PROTECTED]
Re: Bug#275816: ITP: libfile-type-perl -- determine file type using magic
* NOKUBI Takatsugu: > At Mon, 11 Oct 2004 12:47:25 +0200, > Hilko Bengen wrote: >> Does its feature differ from File::MMagic (libfile-mmagic-perl)? > > It seems under different license. File::MMagic is The Apache License The code is under a BSD-style license with a documentation requirement which could well be incompatible with the GPL. > because it contains mime.magic database based on mod_mime_magic. In theory, we could get rid of that database (or put it into a separate file), so that the file is not encumbered by the Apache license. But given that we can't reach GPL compatibility this way, it's probably not worth the effort. Good catch, anyway.
Re: Smooth Debian Installer Experience
On Sun, Oct 10, 2004 at 01:13:34PM +0200, Tilo Schwarz wrote: > On Saturday 09 October 2004 15:56, Colin Watson wrote: > > On Sat, Oct 09, 2004 at 12:48:27AM +0200, Tilo Schwarz wrote: > > > Just one remark: When I was asked to enter a package server I would > > > have liked to enter my local package repository (with all the base > > > stuff in it), but either I couldn't or I didn't see it. But, never > > > mind ... > > > > Scroll up to the top of the country list and you'll see "enter > > information manually". > > Ahh, thank you for the hint. In my case, I simply didn't expect to find > a "enter information manually"-possibility in the country list, but in > the following ftp-server list. I actually scrolled a few times up and > down the ftp-servers looking for a way to enter the server manually and > I couldn't make the step back to the country list mentally ;-) I think it should be in both lists, actually. -- Colin Watson [EMAIL PROTECTED]
Re: TG3 firmware report...
On Mon, Oct 11, 2004 at 11:40:30AM +0200, Florian Weimer wrote: > Of course it is safe to distribute. What do you fear? That Broadcom > might sue you for distributing something that they have written and > released under the GPL, and actually have a case? They might as well > sue Debian because the toolchain supports the SB-1 architecture. they may have released it under the GPL, but there's a strong case for arguing that they're in violation of their own licensing terms for not providing the source code to the firmware blobs. if they were in fact in violation of said terms, debian could not legally distribute the code. or so the argument goes. sean -- signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: > * paddy ([EMAIL PROTECTED]) [041011 12:55]: > > On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > > > - volatile is not "just another place" for backports, but should only > > > contain changes to stable programs that are necessary to keep them > > > functional; > > > I would like 'must' keep them functional: IOW, voltaile is prepared to > > drop packages from volatile that are, for whatever reason, unable to keep > > up with the purpose. It would be sad if volatile ended up containing > > useless packages! > > Of course we need to reserve the right to drop packages - but, doing > that would still be bad. Adding a package to volatile means for me that > we are very confident that we can support it till the current debian > major release is archived. If we can't do that, we shouldn't have added > it in the first place. Hmm, deja vu ;) What happens to packages that become orphaned? Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 15:35]: > On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: > > Of course we need to reserve the right to drop packages - but, doing > > that would still be bad. Adding a package to volatile means for me that > > we are very confident that we can support it till the current debian > > major release is archived. If we can't do that, we shouldn't have added > > it in the first place. > Hmm, deja vu ;) > > What happens to packages that become orphaned? The same that happens with them in stable. The volatile team has to keep care of them till the current debian major release is archived. 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: about volatile.d.o/n
On Mon, Oct 11, 2004 at 03:37:21PM +0200, Andreas Barth wrote: > * paddy ([EMAIL PROTECTED]) [041011 15:35]: > > On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: > > > Of course we need to reserve the right to drop packages - but, doing > > > that would still be bad. Adding a package to volatile means for me that > > > we are very confident that we can support it till the current debian > > > major release is archived. If we can't do that, we shouldn't have added > > > it in the first place. > > > Hmm, deja vu ;) > > > > What happens to packages that become orphaned? > > The same that happens with them in stable. The volatile team has to keep > care of them till the current debian major release is archived. Given that the volatile team is the gatekeeper to the volatile archive, this is an excellent approach: packages are unlikely to get in too easily. It's also a big commitment: kudos once again for stepping up to the plate. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: PROPOSAL: debian-mozilla@lists.debian.org
Jesus Climent schrieb: On Sun, Oct 10, 2004 at 10:51:21PM +0200, Aurelien Jarno wrote: I think that creating a such list is a very good idea. Currently the only way to contact mozilla package's maintainers is to do an apt-cache search mozilla and grep for the email adresses. FYI there is currently Or send a mail to @packages.debian.org That solves only part of the problem. There should be a forum for *all* maintainers of mozilla-related packages to communicate. Once instance where this would have been and still could be useful is the ongoing transition to firefox 1.0pre. Another (related) issue is how to repackage firefox /thunderbird extensions and locales for Debian. I have severe difficulties understanding what the extension manager does. All I understand is that repackaging those extensions for Debian requires massive hacks. It would be incredibly helpful to have something like a mozilla packaging policy, just like the existing Debian GNOME packaging policy. Stuff like this could be discussed on a prospective debian-mozilla list. Thanks, Johannes
Re: gawk: Odd regexp matching problem if LANG=ja_JP
On August 18, 2004 at 2:57PM +0900,
miles (at lsi.nec.co.jp) wrote:
> Package: gawk
> Version: 1:3.1.4-1
> Executing the following line in a shell:
>
>echo -e '--- orig/lisp/ChangeLog\n+++ mod/lisp/ChangeLog' | LANG=ja_JP
> gawk '/[Cc]hangeLog/ { print }'
>
> yields not the expected two lines of output, but instead only the first one:
>
>--- orig/lisp/ChangeLog
>
>
> If the LANG-setting portion is changed to use C, then it works as
> expected (others such as "de" seem to work too):
>
>echo -e '--- orig/lisp/ChangeLog\n+++ mod/lisp/ChangeLog' | LANG=C gawk
> '/[Cc]hangeLog/ { print }'
>
> yields:
>
>--- orig/lisp/ChangeLog
>+++ mod/lisp/ChangeLog
>
>
> I'm not sure if the actual encoding has any impact -- ja_JP, ja_JP.utf8,
> and ja_JP.eucjp all exhibit the same problem.
ko_KR, zh_CN, and zh_TW exhibit the same problem. On CJK
locales, this bug causes gawk scripts unusable.
Downgrading gawk to version 1:3.1.3-3 prevents the problem.
Could anyone fix this bug?
Thanks,
--
Tatsuya Kinoshita
pgpW5IstnR7Q0.pgp
Description: PGP signature
Re: J?rg Schilling is damage; the community should route around him
On Monday 11 October 2004 07:46, Sean Harshbarger wrote: > I already put the libburn package in unstable a couple months back in > hopes that more people would adopt/help it out. The libburn team has > been somewhat idle last month or so, and I think this is the type of > poking they need to continue it. First of all, great work! :) The package has some typos in the Description: s/liburn/libburn/ s/acces/access/ ... Best regards pgpyyxriovmET.pgp Description: PGP signature
ppp/ip-up vs. network/if-up
Hi, why ppp provides its own mechanism of telling programs when the interface is coming up or down? Many programs register for the ppp mechanism, but not for the network mechanism. Where is the difference and why both isn't the same? Bye, Joerg. -- Real programmers don't comment their code. It was hard to write, it should be hard to understand.
Re: PROPOSAL: debian-mozilla@lists.debian.org (was: Transitioning to Mozilla Firefox 1.0PR)
#include * Johannes Rohr [Fri, Oct 08 2004, 10:20:12AM]: > >> I remarked that mozilla-firefox is built on hppa using gcc-3.2 (I > > [...] > > Dear all, > > due to the ever increasing number of mozilla-based packages I wonder if > it would be a good thing to have a separate debian-mozilla mailing > list. Personally I have big difficulties understanding the hacked way What is wrong with an Alioth project, say "mozilla-group"? There you can create mailing lists you need. Regards, Eduard. -- morgen! was ist morgen? aehm, mittwoch!
Re: TG3 firmware report...
On Mon, 2004-10-11 at 09:06 -0400, sean finney wrote: > On Mon, Oct 11, 2004 at 11:40:30AM +0200, Florian Weimer wrote: > > Of course it is safe to distribute. What do you fear? That Broadcom > > might sue you for distributing something that they have written and > > released under the GPL, and actually have a case? They might as well > > sue Debian because the toolchain supports the SB-1 architecture. > > they may have released it under the GPL, but there's a strong case for > arguing that they're in violation of their own licensing terms for not > providing the source code to the firmware blobs. if they were in fact > in violation of said terms, debian could not legally distribute the > code. or so the argument goes. > You can't violate your own licensing terms. A licence is what an author gives to somebody to adjust the rights they have on a work. The licensee is bound by the licence, not the author. (Note that this arguably doesn't apply where the author has taken back patches under their own licence because they are in fact the licensee not the author.) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: [OT:HUMOR] Re: software
Scripsit Kevin Mark <[EMAIL PROTECTED]> > Price for Commercial Software: > Cost: several hundreds dollar and vendor lock-in And even more if one wants legit copies. > Membership has its privedleges! Which? No membership is required. -- Henning Makholm "... and that Greek, Thucydides"
Re: TG3 firmware report...
sean writes: > they may have released it under the GPL, but there's a strong case for > arguing that they're in violation of their own licensing terms for not > providing the source code to the firmware blobs. if they were in fact in > violation of said terms, debian could not legally distribute the code. What do you mean by "legally"? Copyright infringement is a tort, and there is no way they could win an infringement lawsuit against a distributor for failing to redistribute the source for the blobs when they did not supply it themselves and yet asserted that the work was under the GPL. The real risk (if any) is of being sued by a kernel author. -- John Hasler
Re: gawk: Odd regexp matching problem if LANG=ja_JP
At Mon, 11 Oct 2004 23:29:15 +0900 (JST),
Tatsuya Kinoshita wrote:
> > Package: gawk
> > Version: 1:3.1.4-1
>
> > Executing the following line in a shell:
> >
> >echo -e '--- orig/lisp/ChangeLog\n+++ mod/lisp/ChangeLog' | LANG=ja_JP
> > gawk '/[Cc]hangeLog/ { print }'
> >
> > yields not the expected two lines of output, but instead only the first one:
> >
> >--- orig/lisp/ChangeLog
> >
> >
> > If the LANG-setting portion is changed to use C, then it works as
> > expected (others such as "de" seem to work too):
> >
> >echo -e '--- orig/lisp/ChangeLog\n+++ mod/lisp/ChangeLog' | LANG=C gawk
> > '/[Cc]hangeLog/ { print }'
> >
> > yields:
> >
> >--- orig/lisp/ChangeLog
> >+++ mod/lisp/ChangeLog
> >
> >
> > I'm not sure if the actual encoding has any impact -- ja_JP, ja_JP.utf8,
> > and ja_JP.eucjp all exhibit the same problem.
>
> ko_KR, zh_CN, and zh_TW exhibit the same problem. On CJK
> locales, this bug causes gawk scripts unusable.
>
> Downgrading gawk to version 1:3.1.3-3 prevents the problem.
>
> Could anyone fix this bug?
One possible workaround is use GAWK_NO_DFA=1
% echo -e '--- orig/lisp/ChangeLog\n+++ mod/lisp/ChangeLog' | LANG=ja_JP.eucJP
GAWK_NO_DFA=1 gawk '/[Cc]hangeLog/ { print }'
--- orig/lisp/ChangeLog
+++ mod/lisp/ChangeLog
I may find the reason of this bug. This is because pattern string has been
changed, but begin,end remain to point the same address so that
mblen_buf and inputwcs won't be updated.
For example, this patch will fix the problem, but it may slow down,
so I think better fixes should be made.
--- dfa.c~ 2004-07-26 23:11:41.0 +0900
+++ dfa.c 2004-10-12 01:05:14.0 +0900
@@ -2872,13 +2872,14 @@
{
int remain_bytes, i;
buf_begin -= buf_offset;
+#if 0
if (buf_begin <= (unsigned char const *)begin && (unsigned char const *)
end <= buf_end) {
buf_offset = (unsigned char const *)begin - buf_begin;
buf_begin = begin;
buf_end = end;
goto go_fast;
}
-
+#endif
buf_offset = 0;
buf_begin = begin;
buf_end = end;
Regards,
Fumitoshi UKAI <[EMAIL PROTECTED]> / <[EMAIL PROTECTED]>
Hewlett-Packard Laboratories Japan http://ecardfile.com/id/ukai
Re: about volatile.d.o/n
Scripsit Florian Weimer <[EMAIL PROTECTED]> > >> Can volatile receive critical updates which are usually not applied to > >> stable because backports are not available for some reason? > Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. > Other complex packages can easily enter this state, too, especially > when sarge has been around for a year or two. I would advise not trying to overloade volatile with too many meanings. A backport of a new Mozilla release is something vastly different from new rules for a spam filter, and I see little value in lumping them together in the same add-on repository. I would like to see a volatile with a very strict mandate: 1. Volatile is a means for *pushing* updates to stable installations, where such updates are necessary for *preserving* the utility of packages due to changes of the outside world. 2. "Necessary for preserving the utility" should be judged under the assumption that the machine that runs stable does not itself change. (I.e., appeals to "this is needed for modern hardware" don't count). 3. No update pushed through volatile should ever change any user interfaces or programmatic interface. (How paranoid developers are expected to be in ensuring this is negotiable, but it must at least be the *goal* that no interfaces change.) The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. If I run a web browser on a stable machine, it is because I am satisfied with its behavior and capabilities. If I want a newer one, I can go to a regular backports repository and pick one by hand. I do not want to get a new version pushed at me simply because it becomes available. If I wanted that kind of behavior I would run testing or unstable, not stable. An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. An update that fixed the default style sheet to include new tags from XHTML 2.1, assuming that it was possible without code changes, would be borderline. Anything more involved than that - no thanks. -- Henning Makholm "Punctuation, is? fun!"
kernel update takes out nvidia drivers
I just did an update on my system. it updated my kernel to a newer version of the same kernel. It also updated all the nvidia packages. But X no longer works. Even though the nvidia packages are installed, the drivers do not work, the kernel module doesn't load. So I tried running the nvidia-installer program to "re-wrap" the compiled nvidia binary to the new kernel (which should have been done by the package maintainer IMHO) and it informs me I need the kernel source. I installed the kernel source and the nvidia-install program STILL tells me I need the kernel source or headers. Anyone have ideas on how to fix? I have no X at all now :-( -- .''`. Carl B. Constantine : :' : [EMAIL PROTECTED] `. `'GnuPG: 135F FC30 7A02 B0EB 61DB 34E3 3AF1 DC6C 9F7A 3FF8 `- Debian GNU/Linux -- The power of freedom "Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world."
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit George Danchev <[EMAIL PROTECTED]> > IMHO a MTA must be capable acts as a client and as a server to transfer > messages between machines and is responsible for properly routing > messages to their destination, e.g. RFC 974. msmtp does not do all > of these, therefor it is not a MTA, and might have nothing to do > with /usr/sbin/sendmail. You are wrong. See nullmailer. The definition of mail-transport-agent is that it provides a /usr/sbin/sendmail that local software can use to submit emails for delivery to arbitrary addresses with some reasonable expectation that it will actually be delivered. It is *not* required that the package that provides mail-transport-agent must itself do any particular part of the delivery process, as long as its /usr/sbin/sendmail will *somehow* arrange for delivery. It would be perfectly good to have a package airgap-mailer whose /usr/sbin/sendmail will just *print* hardcopies of its input on a configured printer, with instructions to the human operator to type the email into the machine at the Internet-connected side of the air gap. This package would provide mail-transport-agent because it implements the policy-defined API for shipping email for delivery. > Note that telnet does know nothing about smtp protocol. Neither does airgap-mailer. > > Note that a MTA isn't required to know ANYTHING about smtp. Suppose a > > package provides an sendmail that is an alias for 'ssh mailhub > > /usr/sbin/sendmail', then that package is a MTA. > Such a package will require a dependency of ssh (at least) on the remote > machine and you will be in a little trouble hacking your control file to > satisfy things like that ;-) That is up to the system administrator to arrange. If it provides a /usr/sbin/sendmail, then it is an MTA. It does not make it any less an MTA that it requires some manual configuration before its /usr/sbin/sendmail can do anything useful with its input. Most MTA's do, actually. > I think ssmtp is incorretly described as a MTA That must be because you don't understand what an MTA is. > WARNING: the above is all it does; it does not receive mail, expand aliases > or manage a queue. That belongs on a mail hub with a system administrator. Neither of these are necessary tasks for an MTA. -- Henning Makholm "The spirits will have to knit like banshees, but with enough spirits it *can* be done!"
Re: about volatile.d.o/n
* Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: > The goal should be that I, as a user, can add volatile to my > sources.list and periodically do an apt-get upgrade - without risking > to suddenly have my web browser updated to a new major release where > it starts behaving differently, all my users' preferences get out of > kilter, etc. I think this is one of the most important statements - and I think it describes our policy quite well. I could however see the possiblity to add a new package "mozilla1.7", that users can optionally install. However, I also won't like it. 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: kernel update takes out nvidia drivers
* Carl B. Constantine ([EMAIL PROTECTED]) wrote: > I just did an update on my system. it updated my kernel to a newer > version of the same kernel. It also updated all the nvidia packages. But > X no longer works. Even though the nvidia packages are installed, the > drivers do not work, the kernel module doesn't load. > > So I tried running the nvidia-installer program to "re-wrap" the > compiled nvidia binary to the new kernel (which should have been done by > the package maintainer IMHO) and it informs me I need the kernel source. > > I installed the kernel source and the nvidia-install program STILL tells > me I need the kernel source or headers. > > Anyone have ideas on how to fix? I have no X at all now :-( Nevermind, I installed the headers instead and that worked. However, why it happened in the first place is puzzling to me. If I update all the nvidia packages with the kernel image, why doesn't it just work? Why do I need to re-run nvidia's installer program? It doesn't make sense to me. -- .''`. Carl B. Constantine : :' : [EMAIL PROTECTED] `. `'GnuPG: 135F FC30 7A02 B0EB 61DB 34E3 3AF1 DC6C 9F7A 3FF8 `- Debian GNU/Linux -- The power of freedom "Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world."
Re: TG3 firmware report...
Scripsit sean finney <[EMAIL PROTECTED]> > they may have released it under the GPL, but there's a strong case for > arguing that they're in violation of their own licensing terms for not > providing the source code to the firmware blobs. The copyright holder cannot logically be in violation of his own licensing terms. He does not need a license at all to distribute his own work, thus there is nothing for *him* to violate. -- Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."
Re: TG3 firmware report...
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit sean finney <[EMAIL PROTECTED]> > > > they may have released it under the GPL, but there's a strong case for > > arguing that they're in violation of their own licensing terms for not > > providing the source code to the firmware blobs. > > The copyright holder cannot logically be in violation of his own > licensing terms. He does not need a license at all to distribute his > own work, thus there is nothing for *him* to violate. Right. In cases like this one, what has happened is that the copyright holder has simply failed to make legal distribution possible, by saying "you must distribute complete source" and then failing to provide it. So the only way to comply with the license in such a case is simply to do no distribution at all. Thomas
Re: Common set of debconf templates
> > SHARED TEMPLATES > >It's actually possible to have a template and a question that > >are shared among a set of packages. All the packages have to > >provide an identical copy of the template in their templates > ^ > >files. This can be useful if a bunch of packages need to ask > >the same question, and you only want to bother the user with it > >once. Shared templates are generally put in the shared/ > >pseudo-directory in the debconf tem- plate namespace. > > What happens when the template changes in the template package but is > out of sync in the other packages? IIRC, a mess..:-) and angry translators..
Re: about volatile.d.o/n
Henning Makholm writes: > 1. Volatile is a means for *pushing* updates to stable > installations, where such updates are necessary for *preserving* > the utility of packages due to changes of the outside world. > 2. "Necessary for preserving the utility" should be judged under > the assumption that the machine that runs stable does not itself > change. (I.e., appeals to "this is needed for modern hardware" > don't count). > 3. No update pushed through volatile should ever change any > user interfaces or programmatic interface. (How paranoid > developers are expected to be in ensuring this is negotiable, > but it must at least be the *goal* that no interfaces change.) > ... > An update of mozilla-browser would be appropriate for volatile if it > did not change the upstream codebase, but, say, updated the default > SSL root certificate set in response to announcements from a > well-known CA. > An update that fixed the default style sheet to include new tags > from XHTML 2.1, assuming that it was possible without code changes, > would be borderline. Anything more involved than that - no thanks. Sounds about right to me. -- John Hasler
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: > Scripsit Florian Weimer <[EMAIL PROTECTED]> > > > >> Can volatile receive critical updates which are usually not applied to > > >> stable because backports are not available for some reason? > > > Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. > > Other complex packages can easily enter this state, too, especially > > when sarge has been around for a year or two. > > I would advise not trying to overloade volatile with too many > meanings. Agreed. I think its hard enough establishing a simple meaning. But these issues have been bubbling and motivating in this area for some time, perhaps there will be more room at the inn soon? > A backport of a new Mozilla release is something vastly > different from new rules for a spam filter, To be fair, the issue is that if were just rules, there wouldn't be a need. > and I see little value in > lumping them together in the same add-on repository. risky. but there may be some synergies. And then there is the potential cost of a profusion of little repositories. Whatever the solution is to the mozilla problem, there does at least appear to be consensus that there has been one. > I would like to > see a volatile with a very strict mandate: > >1. Volatile is a means for *pushing* updates to stable > installations, where such updates are necessary for *preserving* > the utility of packages due to changes of the outside world. Of course the outside world is where new hardware becomes available ;) >2. "Necessary for preserving the utility" should be judged under > the assumption that the machine that runs stable does not itself > change. (I.e., appeals to "this is needed for modern hardware" > don't count). Excellent. This really makes the distinction. Not that I care one way or another whether drivers can enter volatile, but the lack of a good distinction was really bothering me. >3. No update pushed through volatile should ever change any > user interfaces or programmatic interface. (How paranoid > developers are expected to be in ensuring this is negotiable, > but it must at least be the *goal* that no interfaces change.) This is still blurry for me, although I agree with your example. Let me offer examples of real-life changes and their impact: MailScanner can be configured to send mail to an admin account warning of various events. I filter these with procmail. Recently these warnings changed. I would not want a volatile maintainer to be hamstrung in such a case if no package in debian uses the interface: I made the mess, I can fix it (and I will, soon ... :) (Also: which would you rather have backward-compatibility or forward-compatibility? depends on how much past you have and what future you see) Clearly the names of virus identifications sometimes change. This is expected. I would say that the interface is _defined_ as volatile. But these are at one extreme, clamav not dragging sendmail into the archive is at another, and you are identifying important ground in the middle. > The goal should be that I, as a user, can add volatile to my > sources.list and periodically do an apt-get upgrade Personally, if use it (as I hope to), it will be only for specific packages. > - without risking > to suddenly have my web browser updated to a new major release where > it starts behaving differently, all my users' preferences get out of > kilter, etc. If I run a web browser on a stable machine, it is because > I am satisfied with its behavior and capabilities. This sounds quite hectic, I'm begining to feel all dizzy. > If I want a newer > one, I can go to a regular backports repository and pick one by hand. > I do not want to get a new version pushed at me simply because it > becomes available. If I wanted that kind of behavior I would run > testing or unstable, not stable. Ah, that's much better. Playing the devil's advocate: Someone's going to say "so don't do that then" aren't they. Are you saying you have a use for a volatile mozilla, or simply that you see potential problems? If it's the latter, then I agree, you have identified a potential problem area. Also: for a web-browser, yes. For applications in more voltile domains I'm willing to be a little more flexible. But that's just me. Is it practical, or even possible, to identify the use-cases for a web-browser in volatile, to shed more light on what users actually want? Hell, do we care what users want (only kidding folks!) > An update of mozilla-browser would be appropriate for volatile if it > did not change the upstream codebase, but, say, updated the default > SSL root certificate set in response to announcements from a > well-known CA. It would seem a shame to have to do a whole mozilla-browser package just for that. > An update that fixed the default style sheet to include new ta
Re: TG3 firmware report...
Matthew Garrett wrote: > Florian Weimer <[EMAIL PROTECTED]> wrote: >> * Nathanael Nerode: >>> Until they do one of these two things, the firmware is not safe to >>> distribute. >> >> Of course it is safe to distribute. What do you fear? That Broadcom >> might sue you for distributing something that they have written and >> released under the GPL, and actually have a case? Yes. They would have an excellent case. They didn't grant explicit permission to distribute without source. I don't have source, so I'd better not distribute. If I were defending myself, I'd have to claim that they'd granted implicit permission, and I don't think I'd have better than a 50-50 chance of winning; see below. >> They might as well >> sue Debian because the toolchain supports the SB-1 architecture. > > Indeed. It's obviously the intention of the licensor to provide code > that can be distributed. Maybe it's obvious to you. It's certainly not obvious to me. In actual fact, Broadcom released the firmware code under a license which does not grant permission to redistribute. (It requires source but the source is not provided; see Thomas Bushnell's message which summarizes the situation at http://lists.debian.org/debian-devel/2004/10/msg00705.html .) To me, this means that Broadcom didn't know what the hell it was doing. I cannot divine Broadcom's actual intentions from that, and Broadcom can easily and convincingly claim that it intended something different from what you assume. If Broadcom (or some irresponsible successor company; think SCO) decided to sue for copyright infringement, they could claim that they had never intended to allow people in general to redistribute the firmware without source -- that it was just for them to distribute, and perhaps for kernel.org as well -- that any further distribution was inadvertent -- and they would actually have a pretty good case, as far as I can tell. (Of course, if you get an actual legal opinion from a copyright lawyer saying differently, I will of course concede, since IANAL.) Now, if Broadcom could be contacted, and they said, "Oh, we meant to allow anyone to redistribute the hex/binary blobs without further source code," that would be different. Then it would be safe to distribute with a copy of that statement. I have not been able to get such a clarification from Broadcom, and I have tried. If you can get such a clarification, more power to you. -- This space intentionally left blank.
Re: about volatile.d.o/n
Andreas Barth writes: > I could however see the possiblity to add a new package "mozilla1.7", > that users can optionally install. However, I also won't like it. I see no reason for new packages to ever go into volatile. Such things belong in backports. -- John Hasler
Re: PROPOSAL: debian-mozilla@lists.debian.org
Eduard Bloch schrieb: [...] Dear all, due to the ever increasing number of mozilla-based packages I wonder if it would be a good thing to have a separate debian-mozilla mailing list. Personally I have big difficulties understanding the hacked way What is wrong with an Alioth project, say "mozilla-group"? There you can create mailing lists you need. Well, I fail to understand what the extra effort of first creating an Alioth project in order to then set up a mailing list would be good for. I understand that Alioth's primary purpose is to facilitate collaborative maintainership, like e.g. practiced by Debian's GNOME team. However, this was not what I had in mind when I made my proposal. I simply would like to have a forum to discuss common issues related to packaging mozilla-related software. Thanks, Johannes
Re: about volatile.d.o/n
* John Hasler ([EMAIL PROTECTED]) [041011 19:55]: > Andreas Barth writes: > > I could however see the possiblity to add a new package "mozilla1.7", > > that users can optionally install. However, I also won't like it. > I see no reason for new packages to ever go into volatile. Such things > belong in backports. If we really say: "Well, we recommend to upgrade your package to the newest version.", _than_ I think adding it to volatile may be ok. However, certainly a border case, and certainly not the most important thing to start off (so, IMHO, we can just postpone the discussion about, and start with the things we all agree about). 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: TG3 firmware report...
Thomas writes: > In cases like this one, what has happened is that the copyright holder > has simply failed to make legal distribution possible, by saying "you > must distribute complete source" and then failing to provide it. He has provided what he claims is source. If he sues me for redistributing all of what I got from him after he told me it included source he will be laughed out of court. > So the only way to comply with the license in such a case is simply to do > no distribution at all. You just have to refrain from distributing derivatives that are combinations of such bungled works and ones that are properly GPL'd (or get permission of the authors of the properly GPL'd works). -- John Hasler
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Monday 11 October 2004 19:18, Henning Makholm wrote: > Scripsit George Danchev <[EMAIL PROTECTED]> > > > IMHO a MTA must be capable acts as a client and as a server to transfer > > messages between machines and is responsible for properly routing > > messages to their destination, e.g. RFC 974. msmtp does not do all > > of these, therefor it is not a MTA, and might have nothing to do > > with /usr/sbin/sendmail. > > You are wrong. See nullmailer. > > The definition of mail-transport-agent is that it provides a > /usr/sbin/sendmail that local software can use to submit emails for > delivery to arbitrary addresses with some reasonable expectation that > it will actually be delivered. MTA is a software talking at least one Mail Transfer Protocol (like SMTP, UUCP, X.400 ...) These Mail Transfer Agents are responsible for properly routing messages to their destination. See RFC 974 for routing messages. Obviously MTA provides /usr/sbin/sendmail, as required by the policy. > It is *not* required that the package that provides > mail-transport-agent must itself do any particular part of the > delivery process, as long as its /usr/sbin/sendmail will *somehow* > arrange for delivery. Are you talking about MDA here ;-). Delivery agents are used to place a message into a user's mail-box. When the message arrives at its destination, the final transfer agent will give the message to the appropriate delivery agent, who will add the message to the user's mail-box. OK, most MTA comes with MDA apps. > It would be perfectly good to have a package airgap-mailer whose > /usr/sbin/sendmail will just *print* hardcopies of its input on a > configured printer, with instructions to the human operator to type > the email into the machine at the Internet-connected side of the air > gap. This package would provide mail-transport-agent because it > implements the policy-defined API for shipping email for delivery. Such a package must talk at least one Mail Trasfer Protocol to be called MTA. Providing /usr/sbin/sendmail is required but not enough to call it MTA. In the case of msmtp you can create a configuration file with your mail account(s) and tell your MUA to call msmtp instead of /usr/sbin/sendmail. msmtp has not the features of a MTA, and does not need providing /usr/sbin/sendmail. ;-) But you want it provides /usr/sbin/sendmail, to call it MTA, which is seriosly broken logic Care to explain that to its authors ? > > Note that telnet does know nothing about smtp protocol. > > Neither does airgap-mailer. > > > > Note that a MTA isn't required to know ANYTHING about smtp. Suppose a > > > package provides an sendmail that is an alias for 'ssh mailhub > > > /usr/sbin/sendmail', then that package is a MTA. > > > > Such a package will require a dependency of ssh (at least) on the remote > > machine and you will be in a little trouble hacking your control file to > > satisfy things like that ;-) > > That is up to the system administrator to arrange. If it provides a Satifying package's Depends: is in the domain of packaging system handlers. Ever seen a debian/control file & friends ? You have dependencies to resolv on a remote machine... > /usr/sbin/sendmail, then it is an MTA. It does not make it any less an Providing /usr/sbin/sendmail is required, but not enough to call it MTA. > MTA that it requires some manual configuration before its > /usr/sbin/sendmail can do anything useful with its input. Most MTA's > do, actually. Satifying package's Depends: is in the domain of packaging system handlers. Ever seen any debian/control ? You have dependencies to resolv on a remote machine... do not talk me about configurations ... > > I think ssmtp is incorretly described as a MTA > > That must be because you don't understand what an MTA is. beats me ;-) p.s. s/an MTA/a MTA -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: about volatile.d.o/n
Scripsit Andreas Barth <[EMAIL PROTECTED]> > I could however see the possiblity to add a new package "mozilla1.7", > that users can optionally install. However, I also won't like it. Me neither. For example, if I was already using somebody else's backport of mozilla1.7, I wouldn't like it if volatile.d.o hijacked that package and attempted to update it with maintainer scripts that know nothing about the backport I'm using. All additions of new packages carry such a risk, and I don't think that volatile should take that risk unless demonstrably necessary for reaching the main goal of volatile. Which is not duplicating something that existing backports repositories do well. (For the same reason, any updates that add any _new_ /usr/lib/*.so files should be treated with extreme caution. Their name may clash with something I have in /usr/local/lib, and break things. On the other hand /usr/lib/packagename/*.so is fair game). -- Henning Makholm "... popping pussies into pies Wouldn't do in my shop just the thought of it's enough to make you sick and I'm telling you them pussy cats is quick ..."
Re: TG3 firmware report...
John Hasler <[EMAIL PROTECTED]> wrote: > What do you mean by "legally"? Copyright infringement is a tort, and there > is no way they could win an infringement lawsuit against a distributor for > failing to redistribute the source for the blobs when they did not supply > it themselves and yet asserted that the work was under the GPL. > > The real risk (if any) is of being sued by a kernel author. That's only a risk if we ship it linked with the kernel. Shipping a single blob of hex in non-free shouldn't be a problem in that respect. -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
paddy writes: > Whatever the solution is to the mozilla problem, there does at least > appear to be consensus that there has been one. IMO Mozilla belongs in something like backports.debian.org. -- John Hasler
Re: ppp/ip-up vs. network/if-up
On Oct 11, Joerg Sommer <[EMAIL PROTECTED]> wrote: > why ppp provides its own mechanism of telling programs when the interface > is coming up or down? Many programs register for the ppp mechanism, but > not for the network mechanism. Where is the difference and why both isn't Historical reasons? Also, many programs are interested only the ppp interface (it could be argued that they actually care about the interface associated to the default route, but at this point it would be a bit complex to do something about this). -- ciao, | Marco | [8496 inIoQb3pGkNg2] signature.asc Description: Digital signature
Re: TG3 firmware report...
Nathanael Nerode writes: > To me, this means that Broadcom didn't know what the hell it was doing. > I cannot divine Broadcom's actual intentions from that, and Broadcom can > easily and convincingly claim that it intended something different from > what you assume. The intent implied by publically releasing a work under the GPL is well understood and widely known. I don't believe that they would stand any chance of getting an injunction, let alone damages. The fact that they have already permitted redistribution would count heavily against them. -- John Hasler
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Mon, Oct 11, 2004 at 09:00:35PM +0300, George Danchev wrote: > MTA is a software talking at least one Mail Transfer Protocol (like SMTP, > UUCP, X.400 ...) My example, delivering mail via 'ssh mailhub /usr/sbin/sendmail', is an example of transporting mail. > These Mail Transfer Agents are responsible for properly > routing messages to their destination. See RFC 974 for routing messages. > Obviously MTA provides /usr/sbin/sendmail, as required by the policy. uucp doesn't do routing either, who says the MTA must do routing? Exim too can be configured to not do routing, simply drop off the mail at some other host. > Such a package must talk at least one Mail Trasfer Protocol to be called MTA. You're repeating... proof by repetition? Still no backup to your statement. > But you want it provides /usr/sbin/sendmail, to call it MTA, which is > seriosly > broken logic Care to explain that to its authors ? Simple: The Debian way for sending mail is by having a package providing 'mail-transport-agent' taking care of it. In stead of requiring users to hand-configure their MUA and all other packages sending mail, the Debian way is to have the system administrator install the preferred package providing mail-transport-agent that will get the job done, so only ONE package needs to be configured. msmtp is such a package that gets the job (making sure mail is deliverd) done. > > > Such a package will require a dependency of ssh (at least) on the remote > > > machine and you will be in a little trouble hacking your control file to > > > satisfy things like that ;-) > > > > That is up to the system administrator to arrange. If it provides a > > Satifying package's Depends: is in the domain of packaging system handlers. > Ever seen a debian/control file & friends ? You have dependencies to resolv > on a remote machine... Err, any webbrowser has generally a remote dependency on a http server, just like any m-t-a has (possibly indirectly). But those remote dependencies don't need to be Debian, nor is the task of Debian's package management system to care for it, this is a system administration task. > > /usr/sbin/sendmail, then it is an MTA. It does not make it any less an > > Providing /usr/sbin/sendmail is required, but not enough to call it MTA. Hm, I've read that before somewhere. > > > I think ssmtp is incorretly described as a MTA > > > > That must be because you don't understand what an MTA is. > > beats me ;-) Mail Transport Agent is English for Software Transporting Mail, ssmtp, nullmailer, msmtp all fall in that category. If you want to narrow this definition to have additional requirements, please backup those claims with policy/whatever. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: about volatile.d.o/n
Scripsit paddy <[EMAIL PROTECTED]> > On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: > > A backport of a new Mozilla release is something vastly > > different from new rules for a spam filter, > To be fair, the issue is that if were just rules, there wouldn't > be a need. Why not? I pretty much want to have the spamfilter rules on my mail box updated from time to time. Currently that has lead me to put a low-pinned unstable in sources.list and get spamassassin from there. But it was not meant to suddenly pull in spamassassin3. If volatile had existed, I could have avoided that. > MailScanner can be configured to send mail to an admin account warning > of various events. I filter these with procmail. Recently these > warnings changed. I would not want a volatile maintainer to be > hamstrung in such a case if no package in debian uses the interface: I disagree here. One of the main reasons to run stable (apart from getting security updates) is that one can be sure that one's homegrown scripts will not suddenly stop working because some of the Debian-provided software changes the behavior. That means that updates should avoid *any* unnecessary interface changes, right down to preserving spelling errors in the messages used by the intially released version. Volatile should preserve that stability guarantee and stick to changing the internal processing to be up-to-date with the changed world. > Clearly the names of virus identifications sometimes change. > This is expected. I would say that the interface is _defined_ as volatile. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. > Playing the devil's advocate: > Someone's going to say "so don't do that then" aren't they. They probably are, at least until we can agree what is and what is not the purpose of the facility. I'm arguing what *should* be the purpose. > Are you saying you have a use for a volatile mozilla, or simply > that you see potential problems? If it's the latter, then I > agree, you have identified a potential problem area. I'm not sure that I understand that question. > Also: for a web-browser, yes. For applications in more voltile domains I'm > willing to be a little more flexible. But that's just me. Do you have an concrete example we can use to discuss where the line should be drawn? > > An update of mozilla-browser would be appropriate for volatile if it > > did not change the upstream codebase, but, say, updated the default > > SSL root certificate set in response to announcements from a > > well-known CA. > It would seem a shame to have to do a whole mozilla-browser package > just for that. First example that came to mind. A smart maintainer who anticipates doing such an update would probably separate out the root certificates in a small package that could be shared with other PKI-using packages. For all I know, this may already be how it works currently; I did not spend much time tracing the dependencies of the various mozilla packages. > I think what you're saying is you don't want the browser to change > very much. Yes. If it makes the keyboard shortcuts I'm used to work differently, then it's too much. > I don't know how important fixing 'the default style sheet to > include new tags from XHTML 2.1' is, but it sounds pretty > unimportant to me. Yes. The point was that if somebody cared enough to do a volatile update for it I wouldn't find it totally out of line. But I would not expect anybody to care that much. > Presumably, security fixes are more important. Security fixes should be handled by security.d.o. There may or may not be somebody who claims that they *are* not handled by s.d.o (I haven't seen that, but I haven't looked for it either). Even if true, that does not change the fact that s.d.o is where it *should* be handled. Introducing volatile just to make it a competing security team would be silly. > I don't see any need to place obstacles in the way just in case. > And I'm concerned that those obstacles might ultimately get in the way > of packages _in_ volatile (when we have some). I'm not proposing any mozilla-specific obstacles, at least as not as far as I'm aware. -- Henning Makholm "Slip den panserraket og læg dig på jorden med ansigtet nedad!"
Re: RFA: quik -- Bootloader for PowerMac or CHRP systems
On Mon, Oct 11, 2004 at 08:34:57AM +0200, Jens Schmalzing wrote: > X-Debbugs-CC: wouldn't kill people, would it? For reference, this is #275935. Regards, Kyle McMartin.
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit George Danchev <[EMAIL PROTECTED]> > On Monday 11 October 2004 19:18, Henning Makholm wrote: > > The definition of mail-transport-agent is that it provides a > > /usr/sbin/sendmail that local software can use to submit emails for > > delivery to arbitrary addresses with some reasonable expectation that > > it will actually be delivered. > MTA is a software talking at least one Mail Transfer Protocol (like SMTP, > UUCP, X.400 ...) That is not what mail-transport-agent means in Debian. > > It is *not* required that the package that provides > > mail-transport-agent must itself do any particular part of the > > delivery process, as long as its /usr/sbin/sendmail will *somehow* > > arrange for delivery. > Are you talking about MDA here ;-). No. > Delivery agents are used to place a message into a user's mail-box. Yes, and nullmailer (and probably msmtp) does not do that. A mail-transport-agent does not need to be a delivery agent too. > Such a package must talk at least one Mail Trasfer Protocol to be > called MTA. False, not for the meaning of mail-transport-agent we use in Debian. > Providing /usr/sbin/sendmail is required but not enough to call it > MTA. Providing /usr/sbin/sendmail is the necessary and sufficient condition to be a mail-transport-agent. > msmtp has not the features of a MTA, As it has been explained her, msmsp has exactly the features of a mail-transport-agent. > Providing /usr/sbin/sendmail is required, but not enough to call it MTA
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 01:13:40PM -0500, John Hasler wrote: > paddy writes: > > Whatever the solution is to the mozilla problem, there does at least > > appear to be consensus that there has been one. > > IMO Mozilla belongs in something like backports.debian.org. It's certainly not in the category of applications that I'm interested in seeing in volatile. I'm over the moon at what _is_ happening. Happily, Andi appears open-minded, but focused on the hard work of doing the 'obviously right' things first. There is a plenty of uncontroversial work to do, I think we can worry about mozilla if the need ever arises. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 21:00]: > Happily, Andi appears open-minded, but focused on the hard work of > doing the 'obviously right' things first. Well, I'm just waiting for maintainers to say: "Yes, please include a more uptodate version of my package foo." 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: kernel update takes out nvidia drivers
Carl B. Constantine wrote: * Carl B. Constantine ([EMAIL PROTECTED]) wrote: I just did an update on my system. it updated my kernel to a newer version of the same kernel. It also updated all the nvidia packages. But X no longer works. Even though the nvidia packages are installed, the drivers do not work, the kernel module doesn't load. I think you are in the wrong mlist, the place to ask these kind of question is debian- having nvidia packages installed doesn't mean that the module is included in every new kernel, when you download a new kernel you have to compile them, they are not included cause they are not free software or even open source. So I tried running the nvidia-installer program to "re-wrap" the compiled nvidia binary to the new kernel (which should have been done by the package maintainer IMHO) and it informs me I need the kernel source. I installed the kernel source and the nvidia-install program STILL tells me I need the kernel source or headers. header files are ready for compiling kernel modules, there is an header package for every kernel image, kernel source must be prepeared for every kernel image. Anyone have ideas on how to fix? I have no X at all now :-( Nevermind, I installed the headers instead and that worked. However, why it happened in the first place is puzzling to me. If I update all the nvidia packages with the kernel image, why doesn't it just work? Why do I need to re-run nvidia's installer program? It doesn't make sense to me. Yes it make sense cause Debian developers doesn't want to include non free software in a kernel release, but Debian gives u the possibility to compile a module by yourself. -- Guglielmo Dapavo
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Mon, 2004-10-11 at 19:00, George Danchev wrote: Normally I wouldn't mention it but if you're going to pull people up on their grammar please at least get it right. :-) > p.s. s/an MTA/a MTA Nope. An MTA, an SOS, a UPS. It's dependent on vowel /sounds/ rather than vowels. Adam
Re: TG3 firmware report...
John Hasler <[EMAIL PROTECTED]> writes: > Thomas writes: > > In cases like this one, what has happened is that the copyright holder > > has simply failed to make legal distribution possible, by saying "you > > must distribute complete source" and then failing to provide it. > > He has provided what he claims is source. If he sues me for redistributing > all of what I got from him after he told me it included source he will be > laughed out of court. In this case, one would be well advised to obtain an explicit waiver on the point, rather than to rely on such. Regardless, the question is irrelevant to Debian, because we require source.
Re: [OT:HUMOR] Re: software
Kevin Mark <[EMAIL PROTECTED]> writes: > On Sun, Oct 10, 2004 at 11:37:06PM -0500, Adam Heath wrote: > Price for Commercial Software: >> > Adobe Illustrator CS - 90.00 >> > Adobe Acrobat 6.0 Professional - 100.00 >> > McAfee Personal Firewall Plus 2004 v. 5.0 - 20.00 >> > Adobe Photoshop Elements 2.0 - 40.00 >> > Macromedia Studio MX 2004 - 180.00 >> > Abode InDesign CS - 100.00 >> > Microsoft Windows Server 2003 Enterprise Edition - 200.00 >> > Adobe Photoshop 7.0 - 60.00 >> > Adobe Premiere Pro 1.5 - 100.00 >> > QuickBooks Premier Edition 2004 - 80.00 >> > Microsoft Office XP Pro - 100.00 >> > Symantec pcANYWHERE 11.0 - 80.00 >> > Macromedia Studio MX 2004 - 180.00 >> > 3D Home Architect Landscape Design Deluxe 6.0 - 29.99 Debian 3.0r2 8 CD set - 17.99 [1] The reassurance of knowing your operating system is carefully maintained by over 800 developers with the strictest requirements on freedom - Priceless The GPL. It's everywhere you want to be. [1] http://cart.cheapbytes.com/cgi-bin/cart/0070010984.html
Re: TG3 firmware report...
John Hasler <[EMAIL PROTECTED]> writes: > The intent implied by publically releasing a work under the GPL is well > understood and widely known. I don't believe that they would stand any > chance of getting an injunction, let alone damages. You cannot infer person A's intent in doing something merely by assuming that it must be the same as persons B, C, and D.
Re: Re: Terminal - a good terminal?
[ I'm not subbed to -devel, this was pulled from the archive -- please Cc me on replies ] Thomas Dickey wrote: > Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > > Primitive? heh. And as for the rest, I haven't had trouble -- it's > > just an infocmp away. In any case, switching the emulation is trivial > > -- it's not like terminal emulation is complicated. > > Judging by the variety of poor implementations, I'd say that's > incorrect. Even "linux" emulation - how many implement its savable > colors? Well, at least one does. :) A lot of our main emulation code was culled from the kernel source, and abstracted some. So we got most of it for free, and the rest is just doing a few things that aren't implemented by the kernel. So yeah, "setterm -*ground foo -store" works. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: > Scripsit paddy <[EMAIL PROTECTED]> > > On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: > > > > A backport of a new Mozilla release is something vastly > > > different from new rules for a spam filter, > > > To be fair, the issue is that if were just rules, there wouldn't > > be a need. > > Why not? Well, the argument goes: that can be done out-of-band, but some updates involve changes or additions to the engine. There is a class of such software. > I pretty much want to have the spamfilter rules on my mail > box updated from time to time. I understand that. Each of us has differing needs. > Currently that has lead me to put > a low-pinned unstable in sources.list and get spamassassin from there. > But it was not meant to suddenly pull in spamassassin3. If volatile > had existed, I could have avoided that. Ouch. I agree that there are dificulties with pinning up to unstable. Did spamassassin3 go into unstable as 'spamassasin'? (I've not been paying attention) I bet a few people were caught out by this! SA3 has been on the cards for some time now. Is there a policy around name changes at these times? could you have pinned (<<3.0) ? At the end of the day, I'm not certain exactly what you wanted protecting from, but it's hard to be certain that volatile would give it to you. After all the point is to get (at least some) changes. > > MailScanner can be configured to send mail to an admin account warning > > of various events. I filter these with procmail. Recently these > > warnings changed. I would not want a volatile maintainer to be > > hamstrung in such a case if no package in debian uses the interface: > > I disagree here. One of the main reasons to run stable (apart from > getting security updates) is that one can be sure that one's homegrown > scripts will not suddenly stop working because some of the > Debian-provided software changes the behavior. That means that updates > should avoid *any* unnecessary interface changes, right down to > preserving spelling errors in the messages used by the intially > released version. Yes. I can certainly see your point here, and would be more than happy with a volatile where this was the case. I simply see both sides of the coin. Even when the edges get very blurred. And I think they can. > Volatile should preserve that stability guarantee and stick to > changing the internal processing to be up-to-date with the changed > world. > > > Clearly the names of virus identifications sometimes change. > > This is expected. I would say that the interface is _defined_ as volatile. > > Clearly, but the *format* in which the virus scanner reports its > findings should stay stable. You'll get no argument from me on the priciple of that. But what is stable? What if a format needs extending to take account of some new circumstance? I can go on in this vein... For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. Vital new functionality is added to (A) impacting only (1). Upstream (B) is updated to use the new (1). Functionality will suffer seriously if the new (1) is not implemented. The maintainer(s) may want to take steps to zero the impact on existing users, but the case for eventually upgrading to (1+) is compelling: it is only a question of when and how. In extremis, backporting can become a destabilising activity. > > Playing the devil's advocate: > > > Someone's going to say "so don't do that then" aren't they. > > They probably are, at least until we can agree what is and what is not > the purpose of the facility. I'm arguing what *should* be the purpose. fair enough, I couldn't resist :) > > Are you saying you have a use for a volatile mozilla, or simply > > that you see potential problems? If it's the latter, then I > > agree, you have identified a potential problem area. > > I'm not sure that I understand that question. Yeah, sorry, looking back it wasn't terribly polite. I must learn some manners. You've said mozilla belongs in backports, which I'll take to mean: mozilla does not belong in volatile. So you're not advocating mozilla in volatile. It may be that someone will come along that will advocate it in a compelling fashion, but I'm not holding my breath. Until then, if no one is building it, then what is there to knock down ? Should anyone do so you've pointed out a potential problem area. I'd like to think that the potential problem for users of mozilla is not the same for users of clamav because the users are different. But it may be that you mean this example with wider application, hence the inquiry and my interest. > > Also: for a web-browser, yes. For applications in more voltile domains I'm > > willing to be a little more flexible. But that's just me. > > Do you have an concrete example we can use
Re: about volatile.d.o/n
Andi, On Mon, Oct 11, 2004 at 09:01:41PM +0200, Andreas Barth wrote: > * paddy ([EMAIL PROTECTED]) [041011 21:00]: > > Happily, Andi appears open-minded, but focused on the hard work of > > doing the 'obviously right' things first. > > Well, I'm just waiting for maintainers to say: "Yes, please include a > more uptodate version of my package foo." I would say that's 'obviously right'. It could be worse: If I were maintainer, _I_ would be volunteering. Now I wouldn't wish that on anybody :) Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: Updating scanners and filters in Debian stable (3.1)
This one time, at band camp, paddy said: > On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote: > > This one time, at band camp, Martin Schulze said: > > > A while ago there was a discussion in which it was said that such > > > tools are rather useless (or even dangerous) if they don't get their > > > database updated in accordance with new viruses/security problems. > > > > > > Some of these systems are hence not suitable for a stable Debian > > > release where updates will only be made for security problems and > > > very important bugfixes. > > > > > > Have you thought about keeping these packages out of sarge or did you > > > develop a solution so that users can get their databases updated > > > outside of the stable Debian release? > > > > ClamAV uses freshclam for virus definitions, so the actual database > > updates are covered. That being said, there are relatively frequent > > changes to the scanning engine as well, leaving me feeling like it may > > not be the best choice for a stable release. I do plan to continue > > offering out of band up dates on p.d.o, but I am not sure this is the > > best way to proceed. Feedback welcome, > > Stephen, > > Revisiting your original question. > > Reading the Debian Policy Manual as I am right now: > > 2.2.1 The main section > ... > packages in main ... > must not be so buggy that we refuse to support them > > While you clearly do not refuse, it was argued that the net effect is > likely to be just so. People seem to comparing apples and oranges rather frequently in this discussion, so I will try to be very clear here. I am not talking about regular bugs in clam that affect the security, stability, or packaging of the software itself. Infrastructure is already in place for those sorts of problems. The problem is only that packages of this sort need to change to keep up with the threats they are designed to combat. The inability to pick up a new virus is not a bug in the same category as 'segfaults at start' or 'never worked at all' - it is a 'this used to work, but times have changed' bug, similar to a 'please package new upstream version because it has more features' kind of bug. If clam releases in stable, and there is no volatile, then there is no in-band mechanism to deal with these sorts of bugs. So there will likely be tons of 'does not catch virus X' bugs tagged wontfix and people will just be referred to out of band update sites. This is not the end of the world, but I think we can do better. > Perhaps the question now should be: does volatile modify this? > > (for example, does volatile count as support for this purpose). I don;t think it relates to that part of the policy manual, as I said above, but perhaps some people feel so. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpdu6XefPNnx.pgp Description: PGP signature
Re: about volatile.d.o/n
This one time, at band camp, John Hasler said: > Henning Makholm writes: > > > 1. Volatile is a means for *pushing* updates to stable > > installations, where such updates are necessary for *preserving* > > the utility of packages due to changes of the outside world. > > > 2. "Necessary for preserving the utility" should be judged under > > the assumption that the machine that runs stable does not itself > > change. (I.e., appeals to "this is needed for modern hardware" > > don't count). > > > 3. No update pushed through volatile should ever change any > > user interfaces or programmatic interface. (How paranoid > > developers are expected to be in ensuring this is negotiable, > > but it must at least be the *goal* that no interfaces change.) > > > ... > > > An update of mozilla-browser would be appropriate for volatile if it > > did not change the upstream codebase, but, say, updated the default > > SSL root certificate set in response to announcements from a > > well-known CA. > > > An update that fixed the default style sheet to include new tags > > from XHTML 2.1, assuming that it was possible without code changes, > > would be borderline. Anything more involved than that - no thanks. > > Sounds about right to me. AOL. Thanks, Henning, for saying it so much better than I could. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp5hMEkqM8u4.pgp Description: PGP signature
Re: PearPC Section (contrib or main)
On Sat, Oct 09, 2004 at 08:15:47PM +0200, Ramón Rey Vicente wrote: > Leo "Costela" Antunes wrote: > | PearPC does not need MacOS X or other non-free operating system to be > | fully used, it can be used with Debian/PPC for example, so, does it need > | to stay in contrib? > > And, whats about dosemu? dosemu not need a non-free operating system to > be fully used. With dosemu-freedos for example, you reach a fully > funtional DOS-like environment. Why dosemu is into contrib section? More > specifically, dosemu, dosemu-freedos and xfonts-dosemu Because freedos needs a non-free compiler to build. regards, guillem
Bug#276057: ITP: mediawiki -- Wikipedia wiki engine
Package: wnpp Severity: wishlist * Package name: mediawiki Version : 1.3.5 Upstream Author : Mediawiki developers <[EMAIL PROTECTED]> * URL : http://wikipedia.sourceforge.net/ * License : GPL Description : Wikipedia wiki engine MediaWiki is the wiki engine that runs Wikipedia, Wiktionary, Wikibooks, and all the other Wikimedia wiki web sites. (A wiki engine is a web-based tool for collaborative editing). It uses PHP and MySQL. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8
Re: TG3 firmware report...
On Mon, Oct 11, 2004 at 10:47:26AM -0500, John Hasler wrote: > What do you mean by "legally"? Copyright infringement is a tort, and there > is no way they could win an infringement lawsuit against a distributor for > failing to redistribute the source for the blobs when they did not supply > it themselves and yet asserted that the work was under the GPL. the terms of the gpl quite explicitly state that software must be distributed with its source code, where source code is defined as "the preferred form of the work for making modifications to it" (and i somehow doubt that a binary blob is their preferred form, but if they could successfully argue this point this is all m00t). unless we have the author's permission to use an alternate license, wherein the bulk of the code went into contrib and the binary blob went into non-free, or unless the author opened up the firmware, we're unable to legally redistribute it, period. On Mon, Oct 11, 2004 at 06:53:05PM +0100, Matthew Garrett wrote: > That's only a risk if we ship it linked with the kernel. Shipping a > single blob of hex in non-free shouldn't be a problem in that respect. i do not believe that a piece of gpl'd code could legally link against this blob. if this were to be put under some system for loading firmware in userland, i think it'd be up for debate; but the lack of a usable Free alternative would make me think the driver would still need to go in contrib at the least. On Mon, Oct 11, 2004 at 04:53:10PM +0100, Scott James Remnant wrote: > You can't violate your own licensing terms. A licence is what an author > gives to somebody to adjust the rights they have on a work. The > licensee is bound by the licence, not the author. you're arguing my point. debian is a licensee, and is not able to meet with the terms of the license. On Mon, Oct 11, 2004 at 05:26:38PM +0100, Henning Makholm wrote: > The copyright holder cannot logically be in violation of his own > licensing terms. He does not need a license at all to distribute his > own work, thus there is nothing for *him* to violate. this is true, but there is something for *us*... On Mon, Oct 11, 2004 at 01:19:54PM -0500, John Hasler wrote: > The intent implied by publically releasing a work under the GPL is well > understood and widely known. I don't believe that they would stand any > chance of getting an injunction, let alone damages. have you missed everything going on with SCO? granted, their case was a load of crap from the beginning, but it goes to show that this is not something to be taken lightly. and anyway, i don't think you'll get very far trying to argue "implied intent" against the holder of a copyright in a courtroom... sean -- signature.asc Description: Digital signature
Bug#276068: ITP: kftpgrabber -- A KDE FTP client
Package: wnpp Severity: wishlist * Package name: kftpgrabber Version : 0.4.0 Upstream Author : Jernej Kos <[EMAIL PROTECTED]> * URL : http://kftpgrabber.sourceforge.net/ * License : GPL Description : A KDE FTP client It supports SSL/TLS connections to secure FTP sites, OTP passwords and FXP transfers. It also has transfer queuing support, and many more features. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-hardened Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Monday 11 October 2004 21:30, Henning Makholm wrote: > Scripsit George Danchev <[EMAIL PROTECTED]> > > > On Monday 11 October 2004 19:18, Henning Makholm wrote: > > > The definition of mail-transport-agent is that it provides a > > > /usr/sbin/sendmail that local software can use to submit emails for > > > delivery to arbitrary addresses with some reasonable expectation that > > > it will actually be delivered. > > > > MTA is a software talking at least one Mail Transfer Protocol (like SMTP, > > UUCP, X.400 ...) > > That is not what mail-transport-agent means in Debian. The policy says: "The mail spool is /var/mail and the interface to send a mail message is /usr/sbin/sendmail (as per the FHS)." But the policy does not define what an MTA is, but uses it. So I believe here is a good definition of what Mail transfer agents (MTAs) are: http://sendmail.org/email-explained.html (read it thoroughly) All packages having 'Provides: mail-transport-agent' * talk at least one Mail Transport Protocol * but not all of them are capable of routing messages to their destination * provide /usr/sbin/sendmail > > Delivery agents are used to place a message into a user's mail-box. > > Yes, and nullmailer (and probably msmtp) does not do that. A > mail-transport-agent does not need to be a delivery agent too. I've never said that mail-transport-agent does need to be a delivery agent too. > > Such a package must talk at least one Mail Trasfer Protocol to be > > called MTA. > > False, not for the meaning of mail-transport-agent we use in Debian. mail-trnsport-agent is a virtual package provided by packages capable of being MTA. Debian policy does not define what MTA is and does need to. # zcat virtual-package-names-list.txt.gz | grep mail-transport-agent # mail-transport-agenta mail transport agent (e.g. Smail, Sendmail, &c) > > Providing /usr/sbin/sendmail is required but not enough to call it > > MTA. > > Providing /usr/sbin/sendmail is the necessary and sufficient condition > to be a mail-transport-agent. > > > msmtp has not the features of a MTA, > > As it has been explained her, msmsp has exactly the features of a > mail-transport-agent. doesnt buy ... see above. > > Providing /usr/sbin/sendmail is required, but not enough to call it MTA. > > Providing /usr/sbin/sendmail is the necessary and sufficient condition > to be a mail-transport-agent. again. > > > MTA that it requires some manual configuration before its > > > /usr/sbin/sendmail can do anything useful with its input. Most MTA's > > > do, actually. > > > > Satifying package's Depends: is in the domain of packaging system > > handlers. Ever seen any debian/control ? > > You are talking nonsense. Inter-package dependencies are for > expressing requirements on which packages must be installed on the > same machine. Software running on other machines is explicitly not > included. No. You are talking nonsense, because you want to install a package which provides /usr/sbin/sendmail containing: 'ssh mailhub /usr/sbin/sendmail' while having possibly bunch of dependencies to be satisfied on the remote machine... Also policy says: '/etc/aliases is the source file for the system mail aliases (e.g., postmaster, usenet, etc.), it is the one which the sysadmin and postinst scripts may edit. After /etc/aliases is edited the program or human editing it must call newaliases. All MTA packages must come with a newaliases program, even if it does nothing, but older MTA packages did not do this so programs should not fail if newaliases cannot be found.' I've read nothing from your posts about keeping these files in piece on the local and remote machine ... wont mention locking at all ... So the given example of yours is really fragile and insane. I do not buy your bending examples, as well as the definition of what an MTA is and how the debian policy interpret it because it just mandates that the interface to send a mail message is /usr/sbin/sendmail (as per the FHS) and it uses the MTA abbreviation in a common, but obvious way. That's all from me. > > p.s. s/an MTA/a MTA > > The letter M is pronounced [em], which starts with a wowel > sound. Hence the proper article is "an", not "a". Agreed. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Proftpd 1.2.10 available in experimental
Subject says all. Interested people can have a look on it and return feedback on BTS. I have no intention to release 1.2.10 in sarge at this time, anyway. -- Francesco P. Lovergine
Re: RFD: Draft for a volatile.d.o policy
Frank Küster [u] wrote on 10/10/2004 19:17: >> Sven Mueller <[EMAIL PROTECTED]> wrote: > == Draft for a volatile.debian.org packaging and update policy. > >> [...] > Policy for v.d.o > >> [...] > - A new version uploaded to v.d.o should restrict itself to new code which is needed to keep fulfilling the original task of the package when it first entered v.d.o. > >> >> Why not: "of the package when the last stable distribution was >> released"? Quite simple: Say a new open source network security scanner enters the world, and it works well when compiled against Debian stable, we might want to add it to v.d.o even though it wasn't available when the last stable distribution was released. Or a new version of clamav is released, which sadly breaks compatibility, so we rename it to clamav2 and it can still be released through v.d.o, similarly to exim4 entering debian alongside exim a while ago. >> Besides that, it sounds quite well. Thanks. BTW: I am prepared to help volatile.d.o to spring to life as much as possible. This includes helping to keep orphaned packages up-to-date in v.d.o if the need arises for some reason. This also might include working on a sort of security team for v.d.o (I think both jobs should actually be combined in v.d.o). IANDD though, but if needed, I will apply to become one. cu, sven PS: Sorry for also sending this reply in private, didn't mean to do that.
Re: about volatile.d.o/n
Henning Makholm [u] wrote on 11/10/2004 19:48: >> Scripsit Andreas Barth <[EMAIL PROTECTED]> >> > I could however see the possiblity to add a new package "mozilla1.7", that users can optionally install. However, I also won't like it. > >> >> Me neither. For example, if I was already using somebody else's >> backport of mozilla1.7, I wouldn't like it if volatile.d.o hijacked >> that package and attempted to update it with maintainer scripts that >> know nothing about the backport I'm using. Either you are using a backport, which implies that the version you are using is actually somewhere in the debian archive (probably testing or unstable) or you are using an unofficial package in which case Debian can't help you. It is impossible to tell which unofficial packages are available. www.apt-get.org does quite a good job at listing most unofficial repositories, but I don't think that volatile.d.o should actually check each of them for possible clashes with software entering v.d.o. If you install something unofficial on your system and it breaks because of some conflicting version/package in the official archive (be it main, non-us, security or the proposed volatile), this is _your_ problem or that of the provider of that unofficial package, not Debian's. If you are using a backport from backports.org, there won't be a problem, but if there was one, it would still not be up to Debian, but to the backporter. regards, Sven PS: Sorry, didn't mean to send this reply in private first.
Re: about volatile.d.o/n
Henning Makholm [u] wrote on 11/10/2004 20:22: [volatile.debian.org] Security fixes should be handled by security.d.o. Perhaps yes, perhaps no. At least it should follow two rules: 1) If not handled by security.d.o, it should at least be handled in close cooperation with security.d.o 2) It has to have a seperate security archive so that a security fix for a package in v.d.o does not cause a package from the main stable release to be updated. What I mean by the second rule is that if I have to put deb http://volatile.debian.org stable main contrib into sources.list, I would also need to put deb http://security.debian.org volatile/stable main contrib there to fetch the security fixes. I don't want the "normal" stable security deb line to cause security updates to v.d.o to be fetched. cu, sven
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Mon, Oct 11, 2004 at 09:00:35PM +0300, George Danchev wrote: > On Monday 11 October 2004 19:18, Henning Makholm wrote: > > That is up to the system administrator to arrange. If it provides a > > Satifying package's Depends: is in the domain of packaging system handlers. > Ever seen a debian/control file & friends ? Oh please. grep-available -FMaintainer -sPackage 'Henning Makholm' > You have dependencies to resolv on a remote machine... Hint: an MTA communicates with different hosts, by definition... > > /usr/sbin/sendmail, then it is an MTA. It does not make it any less an > > Providing /usr/sbin/sendmail is required, but not enough to call it MTA. Get real. Are you suggesting it's sane for a package to *require* an SMTP server to run on the local host? As long as /usr/sbin/sendmail exists, it is command-line compatible with the 'original' sendmail, *and* is is able to get mail off the system to a different host, I'd say one can talk about an MTA. > > MTA that it requires some manual configuration before its > > /usr/sbin/sendmail can do anything useful with its input. Most MTA's > > do, actually. > > Satifying package's Depends: is in the domain of packaging system handlers. > Ever seen any debian/control ? You have dependencies to resolv on a remote > machine... do not talk me about configurations ... What's beyond the host is out of reach for packaging. > > > I think ssmtp is incorretly described as a MTA > > > > That must be because you don't understand what an MTA is. > > beats me ;-) > > p.s. s/an MTA/a MTA No, an MTA. If you expand it to mail-transport-agent, you use 'a'. The abbreviation gets 'an'. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Bug#276085: ITP: mpfr -- C library for multiple-precision floating-point computations with exact rounding
Package: wnpp Severity: wishlist * Package name: mpfr Version : 2.0.3 Upstream Author : [EMAIL PROTECTED] * URL : http://www.mpfr.org * License : LGPL Description : C library for multiple-precision floating-point computations with exact rounding The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for double-precision floating-point arithmetic (53-bit mantissa). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8 Locale: LANG=C, LC_CTYPE=C
Re: TG3 firmware report...
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > In this case, one would be well advised to obtain an explicit waiver > on the point, rather than to rely on such. > > Regardless, the question is irrelevant to Debian, because we require > source. Debian does not require source for non-free. The distribution that we ship under the name "Debian" requires source, but that's not the only software we provide. -- Matthew Garrett | [EMAIL PROTECTED]
Re: RFD: Draft for a volatile.d.o policy
Sven Mueller writes: > Say a new open source network security scanner enters the world, and it > works well when compiled against Debian stable, we might want to add it > to v.d.o even though it wasn't available when the last stable > distribution was released. Or a new version of clamav is released, which > sadly breaks compatibility, so we rename it to clamav2 and it can still > be released through v.d.o, similarly to exim4 entering debian alongside > exim a while ago. Those things belong in the non-existent backports.debian.org, not in volatile.debian.org. > This also might include working on a sort of security team for v.d.o (I > think both jobs should actually be combined in v.d.o). v.d.o. should be supported by the Debian security team. I don't think it is worth doing if it can't be. One way to help make sure Debian security can support it is to keep it as small and simple as possible. -- John Hasler
Re: Automake & dependency tracking
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: > Hi, > > Recent versions of automake add an option --disable-dependency-tracking > to the generated configure script. If you don't use that option, the > generated Makefile will wrap all calls to the compiler in a call to > 'depcomp', which will generate a Makefile snippet in a .deps directory > to better track dependencies. This would include dependencies in the to > be built package, but also dependencies outside that package, e.g., > system headers. > > While I can understand the value of this for an upstream developer, I > would wonder whether this is of any value for Debian packages. Debian > packages typically do not profit from this kind of optimization; after > all, a call to 'dpkg-buildpackage' will start off by running a 'make > clean', which means that all source files are (unconditionally) rebuilt > anyway. Well that's true if invoked from dpkg-buildpackage, it's not necessarily true in general. A developer working on a package might not do a complete clean rebuild, so it could have adverse effects. But if we could detect dpkg-buildpackage was the runner, then disabling dependency tracking would provide a little speed boost. > Is there any other reason why we would still need to use automake's > dependency tracking anyway? > -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: PROPOSAL: debian-mozilla@lists.debian.org (was: Transitioning to Mozilla Firefox 1.0PR)
* Johannes Rohr ([EMAIL PROTECTED]) wrote: > [Cc and reply-to debian-devel] > > Am 2004.10.08 06:49 schrieb(en) Mike Hommey: > >On Fri, Oct 08, 2004 at 12:24:07AM +0200, Aurelien Jarno wrote: > >> I remarked that mozilla-firefox is built on hppa using gcc-3.2 (I > > [...] > > Dear all, > > due to the ever increasing number of mozilla-based packages I wonder if > it would be a good thing to have a separate debian-mozilla mailing > list. Personally I have big difficulties understanding the hacked way > how mozilla extensions etc are being repackaged for Debian and I would > be very happy if there was a place to discuss such matters. > > Looking forward to any comments & opinions, I'm very much in favor of such a list, but it would be best if Takuo and other leading mozilla packagers wanted such a thing as well. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: TG3 firmware report...
* Thomas Bushnell: > John Hasler <[EMAIL PROTECTED]> writes: > >> The intent implied by publically releasing a work under the GPL is well >> understood and widely known. I don't believe that they would stand any >> chance of getting an injunction, let alone damages. > > You cannot infer person A's intent in doing something merely by > assuming that it must be the same as persons B, C, and D. Well, of course you can. A lot of contracts are made this way (for example, if you buy something in a shop). Is U.S. law really *that* different?
Bug#276116: ITP: gmailfs -- Use your GMail account as a filesystem
Package: wnpp Severity: wishlist * Package name: gmailfs Version : 0.2 Upstream Author : Richard Jones <[EMAIL PROTECTED]> * URL : http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html * License : GPL2 Description : Use your GMail account as a filesystem Use your GMail account as a regular filesystem. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-686-smp Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15
