Jörg Schilling is damage; the community should route around him
I don't know about anyone else, but I am tired of reading about the petulant behavior of cdrtools's upstream author ([1][2][3]). Mr. Schilling is clearly unhappy with his choice of the GNU GPL for his software. That is his prerogative, but in my view he causes too much chaos and confusion by continuing to add GPL-incompatible riders to his license. He is furthermore unwilling to pay heed to the needs of the community, which requires that important tools like cdrecord be under the stewardship of a non-mercurial personality (at least when it comes to licensing decisions). 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. [The subject is a reference to a famous quote by John Gilmore.] [1] http://lwn.net/Articles/97469/ [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270060 -- G. Branden Robinson| If you want your name spelled Debian GNU/Linux | wrong, die. [EMAIL PROTECTED] | -- Al Blanchard http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#275596: nagios-text removes /etc/nagios on purge
On Sat, 09 Oct 2004, Andrew Pollock wrote: > On Sat, Oct 09, 2004 at 07:32:19AM +0200, Peter Palfrader wrote: > > On Sat, 09 Oct 2004, Andrew Pollock wrote: > > > > > On Sat, Oct 09, 2004 at 05:52:39AM +0200, Peter Palfrader wrote: > > > > Package: nagios-text > > > > Version: 2:1.2-3.6 > > > > Severity: serious > > > > > > > > nagios-text removes /etc/nagios on purge (postinst). Other packages, > > > > like nagios-nrpe-server also have configuration in there, and purging > > > > nagios-text removed them as well. > > > > > > Surely this is akin to "I purged Apache it it blew away all my logs in > > > /var/log/apache"? > > > > Surely it isn't. var/log != /etc > > Apache owns /var/log/apache because it made it, and removes it on a purge. > nagios owns /etc/nagios, and removes it on a purge. All bets are off if > another package or non-standard configuration goes putting files in there... var/log is greatly different from /etc. I don't assume apache rm -rf's /etc/apache. > > > Doesn't nagios-text own /etc/nagios? Surely any other packages that go > > > shoving stuff in /etc/nagios can expect all bets to be off on a purge, > > > especially if they don't depend on nagios? > > > > Just remove the files you created there. The package has no business > > removing other _configuration_ files from /etc/nagios. > > Well that's going to happen if it removes the directory. If the postrm only > removes the directory when it's empty, it's going require more smarts in the > the postrm's of all the packages that are using this directory, otherwise > it's potentially going to get left lying around after all such packages are > purged. just try rmdir, or let dpkg solve it, if you have /etc/nagios in the package. -- Peter
Re: RFC: best practice creating database
On Fri, 8 Oct 2004, Stefan Hornburg wrote: First of all documentation. Definitely! Kind regards (and sorry for the ACK message - but it was so necessary) Andreas
Count the sands of the sea, number the stars
ates Willcox aspirates unseeded Terpsichore smithy pharmaceutic dishevel plush pressure Dar nonperishable compen Audio (Musjic) Inteirnet Games Biusiness ... Online two days ago . Oirder any sioft you nieed for a low pirice . sations fiefdom Astoria committed exho For exajmple: shop - 299$ , us - 30$ . http://geocities.com/shrub_richardson_56/ rtations spinoff seducers poster moneyed subscribers operational fanciful unattended hammer parades Take just a caxndy and beciome ready for 36 hxours of loive annoy increase props precede Armada bywor This is most modvern and safe wacy not to cover wicth shame Only 15 miinutes to wait FDA Axpproved http://geocities.com/goddard_pynners_43/
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 02:28:10AM +0200, Jesus Climent wrote: > On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: > > > > I generally have to resort to backports or unstable when installing > > Debian > > on recent hardware, because we don't update hardware drivers in stable. > > Would the kernel and X be candidates for volatile? > > I dont see any reason why not, if they can be marked as NotAutomatic. > Due to versioned dependencies, that could be impractical for X, which has a long list of reverse depends. I'd like to see in volatile just as much as possible 'autoconsistent' pieces of software (to minimize possibility of subtle breakage). Other things have already their home in backports.org, at admin's risk. If you check d-kernel you we'll also see that any new release of kernel would potentially cause problems to a good deal of users. It's not a thing we could seriously think to support IMHO. Also, little is nice: thinking of having a looong list of (complicated and interdependet) volatile packages would imply looong release cycles. That's exactly the opposite we would gain with v.d.o|n. -- Francesco P. Lovergine
Re: about volatile.d.o/n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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; > > - Good candidates are clamav (including spin-offs), spamassassin, > chkrootkit; Hi Andres, I've tried to follow the debate so far, but I'm not as knowledgable as a DD, but I have some thoughts. Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. Does this correspond with what others think? also if the data conformed to the expected format for the version in stable, would it have to go throught the same QA process (expr-unstable-testing-stable)? - -kev - -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBZ4y3AWAAuqdWA9cRArSSAJ9RJRIqRuR/TObzU8fAds6E5xR6FACeMyS4 lkNMzUJn7sr6bEdFbZ9hjqc= =zYVC -END PGP SIGNATURE-
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > Packages like virus checkers seem to be > composed of 2 parts: the app program and the data where the data in > this case are virus sigs and the app is say clamav. And the 'volitile' > part is the virus sigs whereas the app (once it hits stable) shouldnt > change unless it warrents a 'security' update. So, volitile should be > for the data/virus sigs that need updating when new bugs hit the 'net. > No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. -- Francesco P. Lovergine
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 08:47:27AM +0200, Francesco Paolo Lovergine wrote: > > > > Would the kernel and X be candidates for volatile? > > > > I dont see any reason why not, if they can be marked as NotAutomatic. > > > > Due to versioned dependencies, that could be impractical for X, which has > a long list of reverse depends. Sorry, with X i thought of "package X" instead of xserver-*. I meant for the kernel, which in some cases it could be tagged non automatic for updates, so that only the package is installed if the users wishes so. Making 2.6 kernels available for woody could have been an scenario where this approach could have work, except for the dependencies that the new kernel requires, but still is a good example of a possibility. J -- 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 First came darkness, then came the strangers. --Dr. Schreber (Dark City)
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > > Packages like virus checkers seem to be > > composed of 2 parts: the app program and the data where the data in > > this case are virus sigs and the app is say clamav. And the 'volitile' > > part is the virus sigs whereas the app (once it hits stable) shouldnt > > change unless it warrents a 'security' update. So, volitile should be > > for the data/virus sigs that need updating when new bugs hit the 'net. > > > > No, often such kind of programs need engine update. That's true for > both AV and antispam programs as well. > > -- > Francesco P. Lovergine Hi Francesco, so: the program = engine part + (some un-named part) ??? and the engine part and the data part are volitile -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: about volatile.d.o/n
* Jesus Climent ([EMAIL PROTECTED]) [041009 11:10]: > I meant for the > kernel, which in some cases it could be tagged non automatic for updates, so > that only the package is installed if the users wishes so. Making 2.6 kernels > available for woody could have been an scenario where this approach could have > work, except for the dependencies that the new kernel requires, but still is a > good example of a possibility. Generally, new packages could be added to volatile, as long as there is a very good usage of them. However, if I see how painful security updates for the kernel currently are for the security team, I think we should better reconsider this very good - because once a package is added, we need to do security updates on 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: 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/
pmount vs updfstab
Actually Ubuntu Linux uses pmount: pmount is a wrapper around the standard mount program which permits normal users to mount removable devices without a matching /etc/fstab entry. Together with hal and gnome-volume-manager (or similar programs) this will provide fully automatic device handling without user intervention. Do we have a "debian solution" about this issue? Or we want to use updtfstab? I tink actually Debian doesn't has any "official solution". How we can use pmount on a Debian system? Cheers, Blue
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 01:57:58PM +0200, Bluefuture wrote: > Do we have a "debian solution" about this issue? Or we want to use > updtfstab? What is updtfstab? HAL upstream has fstab-sync as fstab wrapper, which will probably be used in RedHat's upcoming Fedora Core distribution, seeing how the HAL guys are mostly employed by RedHat. It is too late for Sarge anyway, so I guess we should revisit this issue in a couple of months and evaluate how Ubuntu did with pmount and Fedora with fstab-sync and perhaps what the other distributions use. But in the end, it depends on who does the work, so if Martin Pitt (pmount author) should volunteer to integrate this into Debian, that would be great I guess. Michael
Strange behaviour at kernel upgrade
I got this strange behaviour on Sid today while upgrading kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do you want to stop now? [Y/n]", and it aborted just like if I answered "y". The only thing noticeable is that I took a long time (a few minutes) to answer. I suspect there should be no timeout in this case. I just wanted to let you know, just in case. Preparing to replace kernel-headers-2.6.8-1 2.6.8-3 (using .../kernel-headers-2.6.8-1_2.6.8-4_i386.deb) ... Unpacking replacement kernel-headers-2.6.8-1 ... Preparing to replace kernel-headers-2.6.8-1-686 2.6.8-3 (using .../kernel-headers-2.6.8-1-686_2.6.8-4_i386.deb) ... Unpacking replacement kernel-headers-2.6.8-1-686 ... Preparing to replace kernel-image-2.6.8-1-686 2.6.8-3 (using .../kernel-image-2.6.8-1-686_2.6.8-4_i386.deb) ... You are attempting to install an initrd kernel image (version 2.6.8-1-686) This will not work unless you have configured your boot loader to use initrd. (An initrd image is a kernel image that expects to use an INITial Ram Disk to mount a minimal root file system into RAM and use that for booting). As a reminder, in order to configure LILO, you need to add an 'initrd=/initrd.img' to the image=/vmlinuz stanza of your /etc/lilo.conf I repeat, You need to configure your boot loader -- please read your bootloader documentation for details on how to add initrd images. If you have already done so, and you wish to get rid of this message, please put "do_initrd = Yes" in /etc/kernel-img.conf. Note that this is optional, but if you do not, you will continue to see this message whenever you install a kernel image using initrd. Do you want to stop now? [Y/n]n Ok, Aborting dpkg: error processing /var/cache/apt/archives/kernel-image-2.6.8-1-686_2.6.8-4_i386.deb (--unpack): subprocess pre-installation script returned error exit status 1 Regards -- Jérôme Warnier Consultant BeezNest http://beeznest.net
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 02:46:05PM +0200, Bluefuture wrote: > Il giorno sab, 09-10-2004 alle 12:23 +0200, Michael Banck ha scritto: > > > What is updtfstab? > I use this on sarge/sid and works very fine: > http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorageEnglish It seems this one just uses udev, not HAL. I hope that we get full project-utopia integration for sarge+1 (we've already come a long way). updtfstab still looks like a good interim solution though. Michael
Re: Jörg Schilling is damage; the community should route around him
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. 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. 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, ... Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 12:57:46PM +0200, Michael Banck wrote: > On Sat, Oct 09, 2004 at 02:46:05PM +0200, Bluefuture wrote: > > Il giorno sab, 09-10-2004 alle 12:23 +0200, Michael Banck ha scritto: > > > > > What is updtfstab? > > I use this on sarge/sid and works very fine: > > http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorageEnglish > > It seems this one just uses udev, not HAL. I hope that we get full > project-utopia integration for sarge+1 (we've already come a long way). > > updtfstab still looks like a good interim solution though. In the remote hypothesis I understood the terms of the question :) I'd prefer a daemon-based approach a la vold, without touching configuration files around not of competence. See vold.sf.net, it is the Linux version of a well known tools in Solaris. -- Francesco P. Lovergine
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 01:23:42PM +0200, Francesco Paolo Lovergine wrote: > On Sat, Oct 09, 2004 at 12:57:46PM +0200, Michael Banck wrote: > > On Sat, Oct 09, 2004 at 02:46:05PM +0200, Bluefuture wrote: > > > Il giorno sab, 09-10-2004 alle 12:23 +0200, Michael Banck ha scritto: > > > > > > > What is updtfstab? > > > I use this on sarge/sid and works very fine: > > > http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorageEnglish > > > > It seems this one just uses udev, not HAL. I hope that we get full > > project-utopia integration for sarge+1 (we've already come a long way). > > > > updtfstab still looks like a good interim solution though. > > In the remote hypothesis I understood the terms of the question :) > I'd prefer a daemon-based approach a la vold, without touching > configuration files around not of competence. > See vold.sf.net, it is the Linux version of a well known tools in > Solaris. > I add also that I like *very much* the possibility of stopping the daemon at any time and mounting by hand devices like true men do, without breaking other things around; or not installing it at all, too. -- Francesco P. Lovergine
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
On Fri, Oct 08, 2004 at 06:59:50AM +0200, Christian Perrier wrote: > All such templates should probably go into a common set of debconf > templates, provided by a very small package, which all these packages > should depend upon, instead of constantly reinvent the wheeland > make up, translators, do damn boring work. Is is guaranteed that these templates be available in the .config script? Because, reading from the debconf-devel manpage: Note that the config script is run before the package is unpacked. It should only use commands that are in essential packages. The only dependency of your package that is guaranteed to be met when its config script is run is a dependency (possibly versioned) on debconf itself. -- Brian Sutherland
Re: about volatile.d.o/n
Re: Henning Makholm in <[EMAIL PROTECTED]> > > Some things are not so obvious: > > Should volatile include updates of packages such as debian-keyring? > debian-policy and developers-reference? Those who need these packages will run Sid anyway. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 12:25:55PM +0200, Michael Banck wrote: > On Sat, Oct 09, 2004 at 01:57:58PM +0200, Bluefuture wrote: > > Do we have a "debian solution" about this issue? Or we want to use > > updtfstab? > > What is updtfstab? > > HAL upstream has fstab-sync as fstab wrapper, which will probably be > used in RedHat's upcoming Fedora Core distribution, seeing how the HAL > guys are mostly employed by RedHat. > > It is too late for Sarge anyway, so I guess we should revisit this issue > in a couple of months and evaluate how Ubuntu did with pmount and Fedora > with fstab-sync and perhaps what the other distributions use. The hal debian package ships with fstab-sync, but it's not enabled by default. See README.Debian for details. > But in the end, it depends on who does the work, so if Martin Pitt > (pmount author) should volunteer to integrate this into Debian, that > would be great I guess. I've already discussed this with Martin somewhat. He's prepaired to maintain pmount for Debian if we decide to use it for the project utopia stuff in Debian. But as you rightfully said, this is Sarge+1 stuff. Sjoerd -- After the last of 16 mounting screws has been removed from an access cover, it will be discovered that the wrong access cover has been removed.
Re: pmount vs updfstab
Am Saturday, 9. October 2004 13:50 schrieb Sjoerd Simons: > But as you rightfully said, this is Sarge+1 stuff. So none of this will be done separately (faster) by the debian desktop team first? Is there still work beeing done to get the "desktop" branch up and running?
Re: pmount vs updfstab
Francesco Paolo Lovergine wrote: On Sat, Oct 09, 2004 at 12:57:46PM +0200, Michael Banck wrote: On Sat, Oct 09, 2004 at 02:46:05PM +0200, Bluefuture wrote: Il giorno sab, 09-10-2004 alle 12:23 +0200, Michael Banck ha scritto: What is updtfstab? I use this on sarge/sid and works very fine: http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorageEnglish It seems this one just uses udev, not HAL. I hope that we get full project-utopia integration for sarge+1 (we've already come a long way). updtfstab still looks like a good interim solution though. In the remote hypothesis I understood the terms of the question :) I'd prefer a daemon-based approach a la vold, without touching configuration files around not of competence. See vold.sf.net, it is the Linux version of a well known tools in Solaris. I think hal + dbus-1 + fstab-sync works very well on debian, but the real missing feature is the possibility for users to mount remote file systems like cifs and smbfs without having root privileges or having to suidroot smbmnt, this solution doesn't work very well and it would be useful to create mount points on demand in the user home directory. my 2 cents... -- Guglielmo Dapavo
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 03:04:10PM +0200, alphac wrote: > I think hal + dbus-1 + fstab-sync works very well on debian, but the > real missing feature is the possibility for users to mount remote file > systems like cifs and smbfs without having root privileges or having to > suidroot smbmnt, this solution doesn't work very well and it would be > useful to create mount points on demand in the user home directory. > Some environments more err... user-friendly already have this kind of features, like smb4k for KDE. Anywy, I totally dislike tools which hack fstab or other configuration files around, they have the bad habit to (mis)configure things in a way I hate deeply. They are not solutions, but fast and dirty hacks, pure and plain, nothing which could not be done with some ugly scripts and sudo equivalently, as in the old *nix days on non-Solaris systems. A daemon based approach is a more clean solution. -- Francesco P. Lovergine
Re: Smooth Debian Installer Experience
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". Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
On Sat, Oct 09, 2004 at 01:45:50PM +0200, Brian Sutherland wrote: > On Fri, Oct 08, 2004 at 06:59:50AM +0200, Christian Perrier wrote: > > All such templates should probably go into a common set of debconf > > templates, provided by a very small package, which all these packages > > should depend upon, instead of constantly reinvent the wheeland > > make up, translators, do damn boring work. > > Is is guaranteed that these templates be available in the .config script? The templates would probably have to be copied at build-time, debhelper-style. -- Colin Watson [EMAIL PROTECTED]
Re: installing TCP programs when RPC programs are running
Loïc Minier <[EMAIL PROTECTED]> - Thu, Oct 07, 2004: > Ok, and a warning on all RPC programs not using a static port number? > The only one I use right now is nfs-common, and I see following > packages depending on portmap: > rwalld am-utils nfs-common bootparamd nfs-user-server drac nis > rusersd rstatd fam ugidd Conclusion, I am going to file bug reports of wishlist priority for the above packages, linking to this thread and suggesting a notice / warning that RPC port are not fixed and could collide with services that are installed on a fixed port. Thanks for your comments. Regards, -- Loïc Minier <[EMAIL PROTECTED]>
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 08:19:24PM +0200, Martin Zobel-Helas wrote: > On Friday, 08 Oct 2004, you wrote: > > That's all for now. Comments and suggestions are welcome. > > i would like to see some "policy", what, when and under which > circumstances gets included to volatile.d.n. > > Is for example a package "whois" also a candidate for volatile? > Regestries change from time to time; i just consider .org changed within > the last 2,5 years... That sounds like a candidate for a stable update to me, not volatile. -- Colin Watson [EMAIL PROTECTED]
Re: Strange behaviour at kernel upgrade
On Sat, Oct 09, 2004 at 12:48:23PM +0200, Jérôme Warnier wrote: > I got this strange behaviour on Sid today while upgrading > kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do > you want to stop now? [Y/n]", and it aborted just like if I answered > "y". > > The only thing noticeable is that I took a long time (a few minutes) to > answer. I suspect there should be no timeout in this case. > > I just wanted to let you know, just in case. > > > > Preparing to replace kernel-headers-2.6.8-1 2.6.8-3 (using > .../kernel-headers-2.6.8-1_2.6.8-4_i386.deb) ... > Unpacking replacement kernel-headers-2.6.8-1 ... > Preparing to replace kernel-headers-2.6.8-1-686 2.6.8-3 (using ^ Notice the extra space here. It appears you inadvertently hit the space bar while you were doing something else. As a result, you had that space in your input buffer, so when you hit enter, it was the space, rather than the 'n', which was processed. As this script interprets everything which is not 'n' as the default value, it bailed out. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: about volatile.d.o/n
also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.09.1618 +0200]: > That sounds like a candidate for a stable update to me, not > volatile. You mean an r-release? The problem with those is that they have too much inertia to be able to provide fixes quickly. So then our users will have an inoperable whois for a couple of weeks at least. This is precisely the same situation as with AV scanners and precisely the motivation behind v.d.o. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
This one time, at band camp, Kevin Mark said: > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > > > Packages like virus checkers seem to be > > > composed of 2 parts: the app program and the data where the data in > > > this case are virus sigs and the app is say clamav. And the 'volitile' > > > part is the virus sigs whereas the app (once it hits stable) shouldnt > > > change unless it warrents a 'security' update. So, volitile should be > > > for the data/virus sigs that need updating when new bugs hit the 'net. > > > > No, often such kind of programs need engine update. That's true for > > both AV and antispam programs as well. > > > Hi Francesco, > so: > the program = engine part + (some un-named part) ??? > and the engine part and the data part are volitile In the case of clamav, most of the work of scanning is handled by library functions, and these functions are called by the frontend programs like clamscan, clamdscan, and the milter. I think that spamassassin works much the saem way - most of the real work is done by the perl module Mail::Spamassassin, and the frontend programs /usr/bin/spamassassin and spamc are an interface to using these functions. In addition to the engine itself, as has been noted, there are the data sets that the engine uses to identify potential targets. In the case of spamassassin, these are rules, and in the case of clamav, these are virus signatures. Right now, it is easy enough to get new data sets - the clamav suite inculdes an updater for it's data, and spamassassin is easy to add new rules to. The problem is updating the engine in a stable release. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpCEQgGc6Vi3.pgp Description: PGP signature
Processed: Re: Bug#275635: How to increase the Threads Size in debian...
Processing commands for [EMAIL PROTECTED]: > reassign 275635 general Bug#275635: How to increase the Threads Size in debian... Warning: Unknown package 'how' Warning: Unknown package 'to' Warning: Unknown package 'increase' Warning: Unknown package 'threads' Warning: Unknown package 'size' Warning: Unknown package 'in' Bug reassigned from package `how to increase the threads size in' to `general'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Package: wnpp Severity: wishlist * Package name: msmtp Version : 1.2.3 Upstream Author : Martin Lambers <[EMAIL PROTECTED]> * URL : http://msmtp.sourceforge.net * License : GPL Description : smtp client which can be used as a smtp plugin with mutt msmtp is an SMTP client that can be used as an "SMTP plugin" for Mutt and probably other MUAs (mail user agents). It forwards mails to an SMTP server (for example at a free mail provider) which does the delivery. The description was taken from msmtp site. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Julien Louis <[EMAIL PROTECTED]> [2004.10.09.1616 +0200]: > msmtp is an SMTP client that can be used as an "SMTP plugin" for Mutt and > probably other MUAs (mail user agents). > It forwards mails to an SMTP server (for example at a free mail provider) > which > does the delivery. How does this differ from nullmailer? Why should we have Yet Another SMTP client in Debian? Also, mutt has no concept of plugins. It just calls a script or executable to deliver the mail. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Updating scanners and filters in Debian stable (3.1)
On Fri, Oct 08, 2004 at 04:44:05PM -0700, Thomas Bushnell BSG wrote: > paddy <[EMAIL PROTECTED]> writes: > > > But, I can see the case, as I describe before, where achieving the function > > of a package places great pressure on the time to package, so much so that > > if an interim, first cut package can achieve this most effectively > > (ie: quickest) by shipping upstream 'important fixes/features' mixed with > > 'other "new functionality", which is not actually necessary' then that can > > be a win too. But I could agree: only with the proper follow-up. > > No, no, no. > > If nobody is around to devote that time to the package, then it should > not be released. It is not ok to release it, and then say, "I don't > have the time to do it right!" and then do it wrong. > > Thomas Agreed. If anyone is saying 'do a half-assed job', I'm right there with you: No, no no. Nevertheless, I still believe in what I _have_ said. Perhaps the problem is with the word 'release'. Elsewhere Andi has said something like 'release area and staging area'. I certainly don't mean release in this sense - and I can see how I could be causing confusion. I simply mean 'make publicly available'. I mean to imply nothing about branding or what have you, except that I believe its best to label such a thing as what it is: and certainly not to confuse it with other things that is clearly not. I think: It would appear that we both believe in 'doing the right thing'. There are likely some differences between us as to what that may be, but probably not as much as our words would suggest. And a good part of that is down to my poor choices of words. I hope we can get past those poor choices. Once more, in more detail, then: I'm not talking about the case where sufficient resources are not available to be applied. I'm talking about the case where, in the application of sufficient resources in a timely fashion, the best outcome is an initial product that does not consume as much resource to produce as later products in the same process, not because of any desire to not expend resources, but because quicker is better, and even nine women will not bear a child to term in one month. Sometimes less is more. Perhaps this case never occurs, in which case perhaps I owe you apology for wasting you time, but so far you don't seem to be saying that: I think more likely we're stuck on a form of words. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: > This one time, at band camp, Kevin Mark said: > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > > > > Packages like virus checkers seem to be > > > > composed of 2 parts: the app program and the data where the data in > > > > this case are virus sigs and the app is say clamav. And the 'volitile' > > > > part is the virus sigs whereas the app (once it hits stable) shouldnt > > > > change unless it warrents a 'security' update. So, volitile should be > > > > for the data/virus sigs that need updating when new bugs hit the 'net. > > > > > > No, often such kind of programs need engine update. That's true for > > > both AV and antispam programs as well. > > > > > Hi Francesco, > > so: > > the program = engine part + (some un-named part) ??? > > and the engine part and the data part are volitile > > > Right now, it is easy enough to get new data sets - the clamav suite > inculdes an updater for it's data, and spamassassin is easy to add new > rules to. The problem is updating the engine in a stable release. Indeed, there is a consensus that data updates with the volatility of, say, virus scanner sigs belong firmly out-of-band. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
martin f krafft <[EMAIL PROTECTED]> - Sat, Oct 09, 2004: > How does this differ from nullmailer? Why should we have Yet Another > SMTP client in Debian? Because it doesn't provide the same set of functionalities? A quick look at nullmailer and msmtp homepages shows that msmtp supports SASL, and that is is developed actively. The last release of nullmailer upstream is quite old now, given the path that SMTP is taking right now... If you want to send mail via SMTP with Mutt, you're likely to find yourself typing "smtp client mutt" in google, or "apt-cache search mutt smtp", guess what you would find? ;) Regards, -- Loïc Minier <[EMAIL PROTECTED]>
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Il sab, 2004-10-09 alle 17:04, martin f krafft ha scritto: > also sprach Julien Louis <[EMAIL PROTECTED]> [2004.10.09.1616 +0200]: > > msmtp is an SMTP client that can be used as an "SMTP plugin" for Mutt and > > probably other MUAs (mail user agents). > > It forwards mails to an SMTP server (for example at a free mail provider) > > which > > does the delivery. > > How does this differ from nullmailer? Why should we have Yet Another > SMTP client in Debian? I think it's not a right comparison, nullmail is an MTA. and AFAIK, msmtp is not an MTA: > Also, mutt has no concept of plugins. It just calls a script or > executable to deliver the mail. I think that msmtp simply will take the place of sendmail binary called by mutt. bye Christian
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Christian Surchi <[EMAIL PROTECTED]> [2004.10.09.1730 +0200]: > 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? oh well, msmtp has TLS and SASL and IPv6, so I guess it is more featureful than nullmailer... > I think that msmtp simply will take the place of sendmail binary > called by mutt. oh, and calling it a plugin make is sounds so much better. are these guys marketing specialists or software hackers? did you know about lpr? it's the mutt print plugin which may also work with other programmes. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Saturday 09 October 2004 18:48, martin f krafft wrote: > also sprach Christian Surchi <[EMAIL PROTECTED]> [2004.10.09.1730 +0200]: > > 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? the diff is that with msmtp you wont have a mta, but a mua. > oh well, msmtp has TLS and SASL and IPv6, so I guess it is more > featureful than nullmailer... and much more ... also has msmtpqueue which is a pair of very simple shell scripts that allows you to "queue" mails and send them all at a later time (useful for dialup connections: write your mails offline and send them when you are online). > > I think that msmtp simply will take the place of sendmail binary > > called by mutt. > > oh, and calling it a plugin make is sounds so much better. are these > guys marketing specialists or software hackers? they just quoted it "SMTP plugin" , but I guess 'a mua backend' will be more correct in that case. > did you know about lpr? it's the mutt print plugin which may also > work with other programmes. having msmtp officially packaged is a good thing imho. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote: > Duncan Findlay <[EMAIL PROTECTED]> writes: > > > When spamassassin is upgraded, it's more than just the rules. Often > > the method of parsing the message is changed -- leading to better > > results, or support for different tests is added, etc. It would be > > very difficult to only backport the appropriate changes, and the > > result would be less stable than the version from which backporting > > was taking place. On the other hand, each new version makes minor > > changes to functionality. (Ignore 3.0.0 right now, it's got different > > issues all together.) To require backported changes would simply be a > > waste of effort and would defeat the purpose to a certain extent. > > Nonsense. It would be harder work, and maybe there is nobody around > to do the hard work. But it is hardly impossible. > > This is what stability is about. What you are calling for is > abandoning Debian's stability judgment to upstream's, in a situation > where upstream isn't making any stability promises at all. > > So backport the appropriate changes only, and find programmers who can > do a good enough job not to screw it up and destabilize it. > > Thomas Thomas, The more the discussion goes on, the more value I see for this emphasis. I started with clamav in mind as my archetypal example program. But defining the class of programs, finding a form of words, is more dificult than it at first appears. Take 'useless' for example. Elsewhere in the thread makes the point that hardware drivers could come into the 'useless' category, and I know exactly what he means: I've been there. But, I wouldn't want to have make X11 or kernels in volatile work: sounds like a world of pain. I got to thinking. In many ways the volatile conversation, is like the one which goes 'can we have a five year EOL so that oracle will support us'. Both deal with having a release cycle which is different from the status quo, and other general discussion on that subject is often heard. The appearance of volatile.d.n suggests to me that Debian is continuing to grow in a healthy way. Perhaps deepfreeze.d.n (or whatever) is waiting in the wings, or other things. I could imagine maintaining clamav against a 5 year old codebase (I do something not so different to that now). clamav is in C, and reasonably self-contained. The version skew doesn't really get to you. The perl based stuff is a bigger problem. I guess I'm saying two things: Ultimately the general rule _always_ has be 'backport the appropriate changes only'. Perhaps maintainers of candidates for volatile will want to take a cautionary second to imagine what it might be like to be working against that five-year-old codebase. And the reason I'm saying these things is that I think that volatile and main archive, 'deepfreeze-or-whatever' or whatever comes along will be at their best if they all work together, rather than being seperate little islands. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 05:13:49PM +0100, paddy wrote: > Elsewhere > in the thread makes the point that hardware drivers could come > into the 'useless' category, and I know exactly what he means: I've been > there. And seconds after I pressed the send button I got that horrible sinking feeling. s//Daniel Burrows/ I'm sorry Daniel, no offense intended. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Jesus Climent <[EMAIL PROTECTED]> writes: > Just another thought... You think that people looking at the code to backport > a given set of features has a better clue about stability than the long time > experienced upstream programers? I expect the Debian maintainers of such a package to understand the code very well themselves, because that would be a necessary part of the job. The upstream maintainers might well have a good clue about stability, but the point is that they haven't promised anything about stability. Stability means not changing features and interactions with other parts of the system, and I don't think they worry about that much at all. Thomas
RFD: Draft for a volatile.d.o policy (was: Re: Updating scanners and filters in Debian stable (3.1) )
Thomas Bushnell BSG [u] wrote on 08/10/2004 18:18: Will Lowe <[EMAIL PROTECTED]> writes: My argument is just that even if you backport the important features of a new release into an old codebase, it's hard to make any valuable claims about the resulting product if the "backport" changes more than a few lines of code. This is true if you don't know what you just did. If you know what you did, you may well be able to make a claim like "no new command line features are added". Doing a backport of some upstream change is usually a pretty difficult task (except for smaller security fixes). It's pretty easy to claim "no new command line feature added", but it is pretty difficult to claim "no new bugs added" or "all necessary security fixes added". I agree that a pure security fix (like s.d.o security updates) should not introduce new code functionality, but only fix the security bug. At times, this might be a hard task, but usually it is an easy to medium level (though usually also very time consuming) task. However, what we are talking about here are packages that become less and less useful over time, these are namely: 1) anti-spam software 2) security scanners (snort and the like) 3) virus scanners (clamav etc.) And since they are pretty closely bound to the above: 4) mail-scanners (amavisd etc.) These are packages that become less useful over time, not because upstream releases new versions with new features, but because the old features aren't enough to fulfill the original tasks anymore. Therefore, and because you asked for a policy for v.d.o before (more or less directly), here is a new try for such a policy (sorry for sending the original one directly to you, Thomas, instead of the list): == Draft for a volatile.debian.org packaging and update policy. Target: volatile.debian.org (or short: v.d.o) is intended to be a repository for packages which degrade over time with respect to their usefulness. These include, but might not be limited to: 1) Virus scanners (clamav etc.) 2) Intrusion detection systems and security scanners (snort, nessus, etc.) 3) Anti-Spam software (spamassassin etc.) 4) Tools which are so closely related to a software in 1-3 that they might need to be updated when a new version of the related software is introduced to v.d.o Policy for v.d.o - Packages in v.d.o are generaly limited to the kind of software listed above. - v.d.o is devided into two parts: - volatile.debian.org - volatile-testing.debian.org (short v-t.d.o). - A new (version of a) package always enters v-t.d.o first, direct uploads to v.d.o are strictly forbidden. - Before a package enters v.d.o, it must prove it's stability by living in v-t.d.o for 2 weeks first without a qualified bug report against it. A qualified bug report is hereby defined as a report for a new bug in the version uploaded to v-t.d.o which doesn't exist in the version in v.d.o. If there is no corresponding version in v.d.o, it must live in v-t.d.o for 6 weeks without any critical bug being reported against it. No package may enter v.d.o with RC bugs open. - 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. - A new upstream version which doesn't adhere to the previous rule may enter v.d.o under a new name. Alternatively, it may enter v.d.o if it is certain that it doesn't break compatibility with any package using it either in the main stable release of Debian or v.d.o - If a new upstream version breaks compatibility with existing packages, it may only enter v.d.o if it lived in v-t.d.o for at least 6 weeks and all packages where compatibility has been broken are simultaneously entering v.d.o (or entered it before). - If a new version of a Software (A) introduced to v.d.o requires new versions of software (X) which are not yet part of v.d.o, these new versions might only be introduced to v.d.o if that new version of X does not break compatibility with the current Debian stable version and is introduced to v.d.o simultaneously with the new version of A. - Only DFSG-free software may enter v-t.d.o or v.d.o! - Software in section 4 of the "targets" paragraph may only be updated in v.d.o if this is needed to either keep support working for a newer version of a software in v.d.o or if this introduces support for a new software in v.d.o (for example if bogofilter support is added to amavisd). Other new features are no reason to update such a package. == Like said before, this is a very basic and preliminary version of a v.d.o policy, but it should make the most important things quite clear. I know this policy is not really to the taste of Thomas Bushnell, especially because new features _might_ be introduced. But with the pretty
Re: RFD: Draft for a volatile.d.o policy (was: Re: Updating scanners and filters in Debian stable (3.1) )
The draft looks good, Sven. Please also include target # 5 as follows. > Draft for a volatile.debian.org packaging and update policy. > > Target: > > volatile.debian.org (or short: v.d.o) is intended to be a repository for > packages which degrade over time with respect to their usefulness. These > include, but might not be limited to: > 1) Virus scanners (clamav etc.) > 2) Intrusion detection systems and security scanners (snort, nessus, >etc.) > 3) Anti-Spam software (spamassassin etc.) > 4) Tools which are so closely related to a software in 1-3 that they >might need to be updated when a new version of the related software >is introduced to v.d.o 5) Architecture-independent data which depend on the contents of the stable release itself. Refer to [http://lists.debian.org/debian-devel/2004/09/msg00951.html] for rationale. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpHsRKnXwblJ.pgp Description: PGP signature
Re: RFD: Draft for a volatile.d.o policy (was: Re: Updating scanners and filters in Debian stable (3.1) )
Sven Mueller <[EMAIL PROTECTED]> writes: > Doing a backport of some upstream change is usually a pretty difficult > task (except for smaller security fixes). It's pretty easy to claim > "no new command line feature added", but it is pretty difficult to > claim "no new bugs added" or "all necessary security fixes added". It's in fact so difficult, that this is exactly why we don't just allow arbitrary changes to stable things, and relabeling them "volatile" and "optional" doesn't actually change the matter. We might need a method for allowing really important upgrades in to stable, which preserve stability, and we have that now for regular stable proposed updates, for security, and we could add it for virus scanners and the like. But in all those cases, we need the same concern for stability. Saying "it's really hard" is not a good excuse! People are doing it for those other packages all the time. > These are packages that become less useful over time, not because > upstream releases new versions with new features, but because the old > features aren't enough to fulfill the original tasks anymore. Right, and I'm happy to see that done, provided that only the new features are allowed which actually keep the particular utility in place. > I know this policy is not really to the taste of Thomas Bushnell, > especially because new features _might_ be introduced. Heh, but compromise is always possible, and I'm interested in hearing what other people say about this proposed policy before I comment further on its details.
Fwd: [Freeguide-tv-users] Download for debian?
The unstable link at http://packages.debian.org/freeguide shows version 0.8, but http://packages.debian.org/unstable/misc/freeguide shows version 0.7.2. Why is this? Cheers, Shaun -- Forwarded message -- From: Andy Balaam <[EMAIL PROTECTED]> Strange. At packages.debian.org/freeguide it shows version 0.8, but at http://packages.debian.org/unstable/misc/freeguide is says 0.7.2. Is this ok? Andy
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sat, Oct 09, 2004 at 05:48:55PM +0200, martin f krafft wrote: > > > I think that msmtp simply will take the place of sendmail binary > > called by mutt. > > oh, and calling it a plugin make is sounds so much better. are these > guys marketing specialists or software hackers? Well "plugin" may not be the appropriate word to define the msmtp function in mutt. But is there any *good* reason to make so much noise for just one word ? -- Vous aimez nos idées ? Vous souhaitez que le développement de MultiDeskOS continue ? N'hésitez pas ! Envoyez-nous des emails de soutien ou mieux, envoyez-nous votre soutien sur notre compte bancaire ou via la poste. -- Jayce - N'oubliez pas l'artiste ! --
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Julien Louis <[EMAIL PROTECTED]> [2004.10.09.1907 +0200]: > Well "plugin" may not be the appropriate word to define the msmtp > function in mutt. But is there any *good* reason to make so much > noise for just one word ? No. But if you - are aware of the Debian archive bloat, - know of the plethora of available SMTP agents, most of which can be easily configured with debconf to be just that, a forwarding MTA, and - read a description like "smtp client which can be used as a smtp plugin with mutt", which not only threatens to unnecessarily bloat the archive even more, but also consists of FUD, you might understand my reaction. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: installing TCP programs when RPC programs are running
On Sat, Oct 09, 2004 at 04:18:36PM +0200, Loïc Minier wrote: > Conclusion, I am going to file bug reports of wishlist priority for the > above packages, linking to this thread and suggesting a notice / > warning that RPC port are not fixed and could collide with services > that are installed on a fixed port. I don't think it's really sensible to have each and every package provide this warning. If we want to trigger this on package install it'd be better to arrange for a single warning rather than having a new one pop up for each package. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: PearPC Section (contrib or main)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 - -- Ramón Rey Vicente JID [EMAIL PROTECTED] - GPG public key id 0x9F28E377 GPG Fingerprint 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaCrSw4Wp058o43cRAhzWAKDUNKPQqrnsAZI6gIIhm6NeHUlcrwCeNf05 C3vjnidkFiSL5sQy2rtLf80= =qbrq -END PGP SIGNATURE-
Re: installing TCP programs when RPC programs are running
Mark Brown <[EMAIL PROTECTED]> - Sat, Oct 09, 2004: > I don't think it's really sensible to have each and every package > provide this warning. If we want to trigger this on package install > it'd be better to arrange for a single warning rather than having a new > one pop up for each package. Good idea: which package should hold the refcount debconf var? portmap? -- Loïc Minier <[EMAIL PROTECTED]>
First spam
First use of email address: 2004-10-06 18:56 (UTC) First spam received at email address: 2004-10-09 17:12 (UTC) If you've been wondering how long it takes for an email address to propagate from the Debian list archives to spammers, here's one data point: less than 71 hours. -- André Majorel http://www.teaser.fr/~amajorel/> Do not use this account for regular correspondance. See the URL above for contact information.
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
martin f krafft <[EMAIL PROTECTED]> - Sat, Oct 09, 2004: > you might understand my reaction. Of course! Maybe the OP should have provided a better description, for example with a listing of features, or with reasons why the software distinguish itself from alternatives? But there's no need to get angry, and I'm sure you wasn't _really_ angry. ;) And since the OP is probably reading this, he can now fix his description, so that the package can easily be chosen when it's available in Debian. -- Loïc Minier <[EMAIL PROTECTED]>
Re: RFD: Draft for a volatile.d.o policy
Thomas Bushnell BSG [u] wrote on 09/10/2004 19:12: Sven Mueller <[EMAIL PROTECTED]> writes: Doing a backport of some upstream change is usually a pretty difficult task (except for smaller security fixes). It's pretty easy to claim "no new command line feature added", but it is pretty difficult to claim "no new bugs added" or "all necessary security fixes added". It's in fact so difficult, that this is exactly why we don't just allow arbitrary changes to stable things, and relabeling them "volatile" and "optional" doesn't actually change the matter. Right. We don't want arbitrary changes - as you call it - allowed into the main stable release. What is proposed here however is a way to allow users to opt-in on changes like that. We might need a method for allowing really important upgrades in to stable, which preserve stability, and we have that now for regular stable proposed updates, for security, and we could add it for virus scanners and the like. But in all those cases, we need the same concern for stability. Well, that would be nice to have. However, these updates would most likely still be far too infrequent. And there are quite a few people around, which are ready to accept a (very) low possibility of added instability for having optimal performance with this kind of software. What most people in this thread seem to see in volatile.d.o is an opt-in to get certain packages ported to stable in a cutting-edge like fashion. Not really bleeding-edge, but newest upstream release which is stable enough for production. I certainly wouldn't like to see - say - SpamAssassin 4.0 in volatile on the very same day it was released upstream. But I would like to see it in there as soon as it has proven to be stable enough for püroduction and it has also proven to not interfere with the stability of the rest of the system. Saying "it's really hard" is not a good excuse! People are doing it for those other packages all the time. You are comparing apples and oranges here. Backporting a security fix for some software usually only affects a few lines of code. Backporting an updated scanning engine for a virus/spam/network scanner is something completely different. We might want to set some sort of limit as to which kind/size of change has to be backported and which kind/size of change can warrant an update to the current stable upstream release. These are packages that become less useful over time, not because upstream releases new versions with new features, but because the old features aren't enough to fulfill the original tasks anymore. Right, and I'm happy to see that done, provided that only the new features are allowed which actually keep the particular utility in place. I'm sorry, but for the idea of volatile.d.o most people in this thread expressed (i.e. IIRC only you seem to object to that idea), this limitation is not intended. However, I see the value of that kind of limitation, but I would like to see the kind of policy you seem to have in mind to be used for updates to the regular stable release. I know this policy is not really to the taste of Thomas Bushnell, especially because new features _might_ be introduced. Heh, but compromise is always possible, and I'm interested in hearing what other people say about this proposed policy before I comment further on its details. You're welcome. cu, sven
Re: Smooth Debian Installer Experience
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". > > Not to nitpick here, but shouldn't options like "None of the above" be at the end of a list? Generally, the idea of picking something from a list is to go though the list, and if not found, to select "Not on this list" item. This means you start at the beginning of a list, and go towards the end. - Adam -- Building your applications one byte at a time http://www.galacticasoftware.com
Bug#275725: ITP: knetworkled -- Network activity monitor for KDE systray
Package: wnpp Severity: wishlist This is a little app which displays network activity in an icon in KDE's system tray, which lets you know if something is taking a long time to transmit or the connection just hung. * Package name: knetworkled Version : 0.5.1 Upstream Author : Brent Kelly <[EMAIL PROTECTED]> * URL : http://www.glitch13.com/knetworkled.php * License : LGPL Description : Network activity monitor for KDE systray Current Features: Docks into KDE system tray. Has a configuration dialog from which you can select what network device to monitor (out of the ones you have available) and how often you want to poll that device for activity (100ms to 1000ms). Tooltip popup when mouseovering the systemtray icon that displays what device is being monitored and how many TX/RX packets have been transmitted/recieved. Known bugs: It doesn't get the correct RT/TX values from /proc/net/dev because the columns for the numbers are different than the the title columns for a couple people people I've seen (don't know why their dev file is screwy). Its possible that it's the same for people with kernels other than 2.4.x or 2.6.x. If yours is different and you know what columns are what, the columns the program uses are simple defines that you can change before compiling. There's no install rule for the makefile. I'd like it to detach from the console or whatever its run from, this is probably easy, but like I said, I'm a neophyte at this stuff. I'm sure there's a few more... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> This one time, at band camp, Kevin Mark said:
> > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
> > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
> > > > Packages like virus checkers seem to be
> > > > composed of 2 parts: the app program and the data where the data in
> > > > this case are virus sigs and the app is say clamav. And the 'volitile'
> > > > part is the virus sigs whereas the app (once it hits stable) shouldnt
> > > > change unless it warrents a 'security' update. So, volitile should be
> > > > for the data/virus sigs that need updating when new bugs hit the 'net.
> > >
> > > No, often such kind of programs need engine update. That's true for
> > > both AV and antispam programs as well.
> > >
> > Hi Francesco,
> > so:
> > the program = engine part + (some un-named part) ???
> > and the engine part and the data part are volitile
>
> In the case of clamav, most of the work of scanning is handled by
> library functions, and these functions are called by the frontend
> programs like clamscan, clamdscan, and the milter.
Hi Stephen,
so,
email
|
\/
{lib}clamav->clamav{frontend}<-clamav-{data}
|
\/
mbox
the api for {lib} and {frontend} must be in sync.
update {lib} api and then you would have to update all {frontends}.
does not sound like 'stable' policy?
the data format used in {data} and read by the {lib} must be in sync.
update the {lib} may lead to a change in data format which would
probably lead to an api change which would mean updates to all
{frontends}. ugh!
would it be good to backport new dataformat to 'stable' dataformat or
risk having to fix {lib} and {frontend}s? then they would be 'unstable'
and need QA?
clam-data has an updated but not all similar frontends do.
what is done for others that do not have 'freshclam'?
what is the diff between
stable.update,security.update,volitile.update?
enquiring minds what to know? hope this is not too OT!
-Kevin
--
(__)
(oo)
/--\/
/ |||
* /\---/\
~~ ~~
"Have you mooed today?"...
signature.asc
Description: Digital signature
WARNUNG - GroupShield-Ticket Nr. OB3_1097349440_ROPF-SV-XCH_1 wu rde generiert
Ausgeführte Aktion: Die Nachricht wurde isoliert und gegen einen Text ausgetauscht, der den Empfänger über die ausgeführte Aktion unterrichtet. An: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Von: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Gesendet: -1729716224,29666868 Betreff: ***SPAM*** Mail Delivery (failure [EMAIL PROTECTED]) Einzelheiten zur Anlage: Anlagenname: N.Z. Datei: Infected.msg Infiziert? Ja Repariert? Nein Blockiert? Nein Gelöscht? Nein Virusname: Exploit-MIME.gen.c <>
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote: > On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: > > This one time, at band camp, Kevin Mark said: > > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: > > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > > > > > Packages like virus checkers seem to be > > > > > composed of 2 parts: the app program and the data where the data in > > > > > this case are virus sigs and the app is say clamav. And the 'volitile' > > > > > part is the virus sigs whereas the app (once it hits stable) shouldnt > > > > > change unless it warrents a 'security' update. So, volitile should be > > > > > for the data/virus sigs that need updating when new bugs hit the 'net. > > > > > > > > No, often such kind of programs need engine update. That's true for > > > > both AV and antispam programs as well. > > > > > > > Hi Francesco, > > > so: > > > the program = engine part + (some un-named part) ??? > > > and the engine part and the data part are volitile > > > > > > > Right now, it is easy enough to get new data sets - the clamav suite > > inculdes an updater for it's data, and spamassassin is easy to add new > > rules to. The problem is updating the engine in a stable release. > > Indeed, there is a consensus that data updates with the volatility > of, say, virus scanner sigs belong firmly out-of-band. Hi Paddy, so that leaves libs and frontends (at least for clamav) but I thought the ideas was to protect against virus threats? if its out-of-band (not in debian control) than the only thing that would seem reasonable is to convert between any new data format and the data format used in stable. current stable= no changes to package = stable system with security left to user with volitile=backport data format= stable system with some new data to improve security somewhat with volitile=backport lib, frontends,data?= possible unstable system with possibly up-to-data security Dont take the above as anything other than my overexagerated guess. I'm just thinking it through to see if I can squeeze this into me wee brain! -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
On Fri, Oct 08, 2004 at 09:03:22AM +0200, Christian Perrier wrote:
> Indeed, this is a long time since I think about such "common debconf
> templates" package.
> The current way of handling common templates by the use of shared/* is
> not optimal ATM, as all packages using shared/* templates must define
> them. They must have the same text...but nothing enforces this...and
> there is no mechanism for reusing the translations which are
> replicated many times.
>
For real shared/* stuff intended to be used in a debconf select type
question you can use an approach similar to the one that is used in
dictionaries-common. The select type main question belongs to
dictionaries-common (and is not shared), and each ispell dict/wordlist has
an empty (really a single whitespace) common shared question. This allows to
know the owners for that shared question, and feed the global question with
a set of possible values in a limited way (they cannot be l10n'ed).
Things are more complicated for us, since each package can provide more than
one entry to the global question owners field, but this way we avoided the
sync problems between all the ispell dicts/wordlists packages templates.
For debconf notes things should also be possible, with some minor tricks via
db_subst or its perl equivalent.
The problem is for the majority of debconf questions, that do not fit in any
of the above categories. Using db_subst might help, templates like
Template: debian/foo-test
Type: boolean
Description: ${shortdesc}
${longdesc}
could be used along with db_subst, but the problem is that AFAIK debconf
currently does not support extracting a debconf template description to a
string. If at the pre-config stage the strings are available, they could
even be get from a normal gettext structure from a .mo file, but I am
unsure that is possible, gettext-base is not essential although is in
the base section.
Cheers,
--
Agustin
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 11:44:41AM +0200, Andreas Barth wrote: > > Generally, new packages could be added to volatile, as long as there is > a very good usage of them. However, if I see how painful security > updates for the kernel currently are for the security team, I think we > should better reconsider this very good - because once a package is > added, we need to do security updates on it. I am not implying it has to be, but in the long run it can be a good candidate to add value to an otherwise old (yeah, stable too) distribution. -- 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 That's thirty minutes away. I'll be there in ten. --Wolf (Pulp Fiction)
Re: First spam
On Sat, 9 Oct 2004, Andre Majorel wrote: > First use of email address: 2004-10-06 18:56 (UTC) > First spam received at email address: 2004-10-09 17:12 (UTC) > > If you've been wondering how long it takes for an email address to > propagate from the Debian list archives to spammers, here's one > data point: less than 71 hours. You know, this is part of our "privacy policy" for the mailing lists: "We do not sell email addresses, we give them for free" This is of course not written anywhere but it's sadly true.
Re: First spam
On Sat, Oct 09, 2004 at 11:25:11PM +0200, Santiago Vila wrote: > > First use of email address: 2004-10-06 18:56 (UTC) > > First spam received at email address: 2004-10-09 17:12 (UTC) > > > > If you've been wondering how long it takes for an email address to > > propagate from the Debian list archives to spammers, here's one > > data point: less than 71 hours. > > You know, this is part of our "privacy policy" for the mailing lists: > "We do not sell email addresses, we give them for free" > This is of course not written anywhere but it's sadly true. First mention of the word SPAM: 9 Oct 2004 20:38:35 +0200 First post from Santiago Vila : 9 Oct 2004 23:25:11 +0200 If you were wondering how long it would take for him to get the debate back on list... :) Santiago has a bit of rationale... Some obfuscation in the list archives might be needed at some point, at least until SPF is widely deployed (thanks to every copr/entity/... for making SenderID a no-no). J -- 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 It's called a change-over. The movie goes on and nobody knows the difference. --Narrator (Fight club)
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:54:11PM -0400, Kevin Mark wrote: > On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote: > > On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: > > > This one time, at band camp, Kevin Mark said: > > > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine > > > > wrote: > > > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > > > > > > Packages like virus checkers seem to be > > > > > > composed of 2 parts: the app program and the data where the data in > > > > > > this case are virus sigs and the app is say clamav. And the > > > > > > 'volitile' > > > > > > part is the virus sigs whereas the app (once it hits stable) > > > > > > shouldnt > > > > > > change unless it warrents a 'security' update. So, volitile should > > > > > > be > > > > > > for the data/virus sigs that need updating when new bugs hit the > > > > > > 'net. > > > > > > > > > > No, often such kind of programs need engine update. That's true for > > > > > both AV and antispam programs as well. > > > > > > > > > Hi Francesco, > > > > so: > > > > the program = engine part + (some un-named part) ??? > > > > and the engine part and the data part are volitile > > > > > > > > > > > Right now, it is easy enough to get new data sets - the clamav suite > > > inculdes an updater for it's data, and spamassassin is easy to add new > > > rules to. The problem is updating the engine in a stable release. > > > > Indeed, there is a consensus that data updates with the volatility > > of, say, virus scanner sigs belong firmly out-of-band. > > Hi Paddy, > so that leaves libs and frontends (at least for clamav) > but I thought the ideas was to protect against virus threats? > > if its out-of-band (not in debian control) than the only thing that > would seem reasonable is to convert between any new data format and the > data format used in stable. maybe there is a place for this, but my understanding is the evolution of data formats is coupled to changes in the scaning engine and backward compatibility is maintained upstream for as long as the upstream maintainers deem reasonable. It may be that engines will eventually evolve to the point where these changes happen on the timescale of a debian stable release, then again it may be in the nature of the problem that they never will. Noone seems to be suggesting that the former is on the immediate horizon (as they are for mozilla for example). I am arguing the latter. > current stable= > no changes to package = stable system with security left to user for clamav, i would hope security.d.o to cover as usual. and virus scanning is not generally about protecting linux hosts. So I see it as a question of function rather than security, in this case. > with volitile=backport data format= > stable system with some new data to improve security somewhat maybe, see above. > with volitile=backport lib, frontends,data?= > possible unstable system with possibly up-to-data security clamav is a really good example of a very self-contained, at least in some setups. two pipes, no privs (someone corrrect me if I'm wrong). In the case of clamav, what i believe is at issue is not the stability or security of whole individual systems (possibly the clamav function) but importantly the stability of the archive, that system. > Dont take the above as anything other than my overexagerated guess. > I'm just thinking it through to see if I can squeeze this into me wee > brain! It's great to talk with you. The more I look at it, the more of the complexity of the problem I see. I hope you can find plenty more room in there ;) Regards, Paddy > -Kev > -- > > (__) > (oo) > /--\/ > / ||| > * /\---/\ >~~ ~~ > "Have you mooed today?"... -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 10:48:15PM +0100, paddy wrote: > maybe there is a place for this, but my understanding is the evolution > of data formats is coupled to changes in the scaning engine and backward > compatibility is maintained upstream for as long as the upstream > maintainers deem reasonable. It occurs to me that it may be possible to do some backporting of signatures (as distinct from a simple mechanical translation). No doubt Thomas will provide encouragement, if you are inclined to undertake such a sisyphean task. Peering into my crystal ball I see a man with a soldering iron handing you a medal emblazoned with the words 'Real Programmer'. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: First spam
On Sat, 09 Oct 2004, Jesus Climent wrote: > Santiago has a bit of rationale... Some obfuscation in the list archives might Won't work. Spammer-database-feeders nowadays either subscribe to the mailinglists (not common), or get the data for a pletora of spyware in Winblows computers (really, REALLY common). So, it might even give you a larger window, but obfuscating the archives won't save you from address harvesting. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#275140: Redirections and noclobber
On Fri, Oct 08, 2004 at 12:33:23PM +0200, Frank K?ster wrote: > Nils wrote in his bug report: > > , > | The postinst script: > | /var/lib/dpkg/info/tetex-base.postinst > | fails if you set bash's "noclobber" (say in your .bashrc via set -o > noclobber). > | (yes, I set noclobber in root's .bashrc -- I'm careful) > ` You should do this carefully: if [ -n "$PS1" ]; then # set whatever interactive things you want fi Julian
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:44:13PM -0400, Kevin Mark wrote:
> On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> > This one time, at band camp, Kevin Mark said:
> > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
> > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
> > > > > Packages like virus checkers seem to be
> > > > > composed of 2 parts: the app program and the data where the data in
> > > > > this case are virus sigs and the app is say clamav. And the 'volitile'
> > > > > part is the virus sigs whereas the app (once it hits stable) shouldnt
> > > > > change unless it warrents a 'security' update. So, volitile should be
> > > > > for the data/virus sigs that need updating when new bugs hit the 'net.
> > > >
> > > > No, often such kind of programs need engine update. That's true for
> > > > both AV and antispam programs as well.
> > > >
> > > Hi Francesco,
> > > so:
> > > the program = engine part + (some un-named part) ???
> > > and the engine part and the data part are volitile
> >
> > In the case of clamav, most of the work of scanning is handled by
> > library functions, and these functions are called by the frontend
> > programs like clamscan, clamdscan, and the milter.
> Hi Stephen,
>
> so,
> email
> |
>\/
> {lib}clamav->clamav{frontend}<-clamav-{data}
> |
> \/
>mbox
Apologies Stephen, you will need to correct me, but here goes:
email
|
V
stuff
|
libs -{api.3}--{api.4}
| |
V V
sigs -{api.1}-> engine -{api.2}-> frontend
|
{api.4 or 5}
|
V
stuff...
> the api for {lib} and {frontend} must be in sync.
> update {lib} api and then you would have to update all {frontends}.
> does not sound like 'stable' policy?
if {api.2} changes then presumably frontend must change.
> the data format used in {data} and read by the {lib} must be in sync.
> update the {lib} may lead to a change in data format which would
> probably lead to an api change which would mean updates to all
> {frontends}. ugh!
I imagine it is quite possible for {api.1} to change without impacting
{api.2}. Indeed, I suppose that to be part of the value of {api.2}.
If it actually exists. I confess, I made it up.
> would it be good to backport new dataformat to 'stable' dataformat or
> risk having to fix {lib} and {frontend}s? then they would be 'unstable'
> and need QA?
see my previous mail.
> clam-data has an updated but not all similar frontends do.
> what is done for others that do not have 'freshclam'?
This is in flux, and part of the problem being discussed. See for
instance discussion of snort rules and oinkmaster, or nessus-plugins.
> what is the diff between
> stable.update,security.update,volitile.update?
> enquiring minds what to know? hope this is not too OT!
Don't know, but I guess perhaps this is a question for Andi.
Regards,
Paddy
> -Kevin
>
>
> --
>
> (__)
> (oo)
> /--\/
> / |||
> * /\---/\
>~~ ~~
> "Have you mooed today?"...
no, why do you think I should ???
--
Perl 6 will give you the big knob. -- Larry Wall
Re: Smooth Debian Installer Experience
On Sat, Oct 09, 2004 at 02:33:47PM -0500, Adam Majer wrote: > 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". > > > > > Not to nitpick here, but shouldn't options like "None of the above" be > at the end of a list? Generally, the idea of picking something from a > list is to go though the list, and if not found, to select "Not on this > list" item. This means you start at the beginning of a list, and go > towards the end. I couldn't find it until after I'd read a desrcription of how to. I'd given up in fact. Perhaps there is a usability problem here. regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: Bug#275140: Redirections and noclobber
On Sat, Oct 09, 2004 at 11:05:40PM +0100, Julian Gilbey wrote: > > | /var/lib/dpkg/info/tetex-base.postinst > You should do this carefully: > if [ -n "$PS1" ]; then > # set whatever interactive things you want > fi Why is the shell invoked by dpkg executing the .bashrc in the first place? First of all .bashrc is not invoked if you call /bin/sh and neigher bash ./test.sh nor ./test.sh (with test.sh beeing "#!/bin/bash\necho test" and .bashrc = echo bashrc) is execuring .bashrc Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: First spam
On Sat, Oct 09, 2004 at 07:11:02PM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 09 Oct 2004, Jesus Climent wrote: > > Santiago has a bit of rationale... Some obfuscation in the list archives > > might > > Won't work. Spammer-database-feeders nowadays either subscribe to the > mailinglists (not common), or get the data for a pletora of spyware in > Winblows computers (really, REALLY common). > > So, it might even give you a larger window, but obfuscating the archives > won't save you from address harvesting. > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] yeah, obscurity vs security. I'm actually surprised it takes them that long. debian-devel must be way down the target list. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
TG3 firmware report...
Hi, I'm writing regarding the issue of inclusion of TG3 binary firmware in the Debian-distributed Linux post-2.6.5 kernels. I understand this has been a contentious topic, and I've read most of the mailing list archives on it, so I'm not trying to restart the debate, but merely adding some additional information, which might not be widely know. Clearly, the TG3 firmware is still distributed with the upstream Linux kernel tarballs, yet removed (post-2.6.5) from Debian distributed kernels for reasons of DFSG guidelines. Much of the debate of this removal has surfaced around the fact that most Broadcom chipsets work fine without the firmware inclusion, and, at worst, possibly simply lose some of their more advanced features. Unfortunately, I believe that my server board contains one of the rare on-board Broadcom chipsets that is completely unable to function (best as I can tell), without downloading this firmware, or without at least disabling the download of it... In other words, it works perfectly with 2.4.26, but not at all with 2.6.8. It's recognized fine, get's IP address fine, has kernel modules loaded etc., but simply drops packets off the stack... My chipset is the Broadcom 5705 (not nearly as popular as the 5704, etc.), but included onboard in the only motherboard that offers a single Opteron processor---namely the Tyan Tomcat K8S---which I think is a wonderful board for certain economical uses where dual processor Opteron capability is overkill. Anyway, just thought I'd see what people think of this, and how the Debian community wants to proceed. Is there some way to enable compability with this without downloading the firmware and violating the DFSG? Thanks, Daniel PS Please cc: me on replies. Also, unfortunately, for various reasons, I don't currently have access to my Tomcat K8S board to test any options with the Broadcom 5705 chipset... :( -- Daniel A. Freedman <[EMAIL PROTECTED]>, Graduate Fellow Electronic Structure Calculations, LASSP, Cornell University
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit Christian Surchi <[EMAIL PROTECTED]> > msmtp is not an MTA: > I think that msmtp simply will take the place of sendmail binary called > by mutt. If it provides /usr/sbin/sendmail, then by definition it is a mail-transport-agent and should, if packaged, declare itself as such. If it provides the same functionality as /usr/sbin/sendmail but with a different command name, then somebody needs to explain why. -- Henning Makholm "Jeg forstår mig på at anvende sådanne midler på folks legemer, at jeg kan varme eller afkøle dem, som jeg vil, og få dem til at kaste op, hvis det er det, jeg vil, eller give afføring og meget andet af den slags."
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [u] wrote on 07/10/2004 09:52: * Duncan Findlay | Umm... I'd like to see that 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | Furthermore, you should use the -m option to limit the number of | children to something sane, like 5 or so. This is per child, as I wrote. Do you have any additional rulesets like those SARE rules installed? If so, how many/what total size? SA3 really explodes in size when more rules are given. Without additional rulesets, i.e. just with the rules SA 3.0 ships with, I have about 20M of memory usage by spampd (spamassassin based SMTP/LMTP proxy). With an additional 460k of rules (some SARE, some others), this shoots up to 40M. With 5M of additional rules, it consumes like 170M of memory. So I would guess that you use additional rulesets totalling about 10-15M in size. Am I right? If so, try removing the biggest rulesets installed, probably something like SARE BigEvil or the like. cu, sven
Re: about volatile.d.o/n
Here I go, replying to myself again ... On Sat, Oct 09, 2004 at 10:48:15PM +0100, paddy wrote: > clamav is a really good example of a very self-contained, at least in > some setups. two pipes, no privs (someone corrrect me if I'm wrong). > In the case of clamav, what i believe is at issue is not the stability or > security of whole individual systems (possibly the clamav function) but > importantly the stability of the archive, that system. Even if I'm not oversimplifying, I'm assuming that compromise of a clamav process could give access to any local exploits available through available system calls. I take it that stable and security.d.o pick up the tab for this. Which makes me wonder: I seem to recall that maintenance of linux kernels has tended to drop covering local holes after a period on old kernels. I take it stable has this covered, but it would be a consideration for any potential deep-freezers, and is at least a box to check for volatile. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: First spam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2004 07:38 AM, paddy wrote: > I'm actually surprised it takes them that long. > debian-devel must be way down the target list. probably geeks don't buy viagra, home loans, online medicine, etc :) lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaIsUjBz/yQjBxz8RAr1zAJ9FJJDeVXUrZOed8omfMMW+zdW82ACgtaKv fqx1ktWIqpBlKwjm2aVgyo4= =Sap8 -END PGP SIGNATURE-
Re: pmount vs updfstab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2004 10:04 PM, alphac wrote: > I think hal + dbus-1 + fstab-sync works very well on debian, but the > real missing feature is the possibility for users to mount remote file > systems like cifs and smbfs without having root privileges or having to > suidroot smbmnt, this solution doesn't work very well and it would be > useful to create mount points on demand in the user home directory. samba shares can be mounted by user with smbmount. But I wished there would be cifs user mount tool too .. lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaI0wjBz/yQjBxz8RAlAXAJ0V2uaBm2JN6PU+QdA9WK/uiUYicwCfaDzp gN8xP6COVLrcCkqlQyVWoNg= =3d05 -END PGP SIGNATURE-
Re: possible mass bug filing: spamassassin 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/07/2004 01:43 AM, Tollef Fog Heen wrote: > * martin f krafft > > | What do you think? > > API changed generally means you bump soname. Why not for SA as well. > > Also, SA3 is useless, as it eats about half a gig of RAM on my > system. Per child. > at office SA2 eats 89MB per daemon, and it opens a new daemon for each damn mail ... becaue spamd can't handle multile connections, but SA3 can, so under the line SA3 is more efficient. Furthermore, we should all know that Anti-Spam, Anti-Virus is a CPU & memory hog. It needs tons of memory and fastest cpu ... always. lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaJOyjBz/yQjBxz8RAl9AAKDWKEdE3jTwFeyl8aw1ka9Xqxg5awCdHHPJ gbGMGc2yL+2nbEZdDf/1eUI= =drOc -END PGP SIGNATURE-
Re: Suspicious reply from katie
Marcin Owsiany <[EMAIL PROTECTED]> writes: > I have just uploaded another version, which resulted in receiving > the attached message. Note the NEW status, and the warning. Is this > a katie bug? Or did I do something wrong? It's a James-is-a-moron problem. I broke (read: deleted) experimental's overrides by mistake. I hope to fix it over the next couple of days. -- James
Re: possible mass bug filing: spamassassin 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2004 07:25 PM, Tollef Fog Heen wrote: > * Duncan Findlay > > | A lot of that is shared, but not reported as such by top/ps due to > | changes in how the kernel reports shared memory. The kernel only > | reports memory that is used in shared libraries, I believe. More > | memory is shared between spamd and it's children. > > My system ran out of swap, with 768MB memory and half a gig of swap. > Problems went away when I downgraded to SA2. If SA uses more than 100 > MB shared memory, I'd say something is seriously wrong anyhow. please read the SA3 man page. it doesn't open spamd on demand, but it runs them permanently, but each can have (default) 200 conenctions. therefore you can set the "how many daemons max" flag to 2 or so, because then you can handle 400 parallel connections. should be enought for home ... lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaJR2jBz/yQjBxz8RAumjAKC7mZ0gt+npU72LWNSKtUxv7MdP7wCfS3sE aunhCS6QGdC7FnwXb64aAlc= =h245 -END PGP SIGNATURE-
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [u] wrote on 07/10/2004 10:00: * Sven Mueller | Well, perl modules don't have an SO name. : [EMAIL PROTECTED] /usr/lib > apt-cache show libvideo-capture-v4l-perl| grep ^Depends Depends: perlapi-5.8.3, perl (>= 5.8.3-2), libc6 (>= 2.3.2.ds1-4) Seems like perl provides an API that the module depends on, no? perlapi seems to be some sort of a pseudo package. But anyway: What does a package version have to do with SO names? | And actually, the "library" part of SA isn't intended to be the most | often used one. If it is provided, it must work. So if someone provides a huge program which consists of various specially crafted dynamic libraries (whose APIs are documented but not really intended for use outside of this specific program), these libraries may not change in a way which changes those APIs? Sure seems strange to me. The only official interfaces SpamAssassin ever provided (to the best of my knowledge) are: 1) calling spamassassin directly (as a commandline tool) 2) calling the spamc client (again, as a commandline tool) 3) accessing spamd over its defined interface (which is used by spamc) > If it is changed in an incompatible fashion, it must bump soname. > Or make SA into a library proper, with libmail-spamassassin-perl being the module part and spamassassin depending on that. Well, in that case, libmail-spamassassin-perl would be the size of the current spamassassin package, and the new spamassassin package (which depends on the libmail-spamassassin-perl package) is about 2k in size, description and packaging overhead included. Sorry, that doesn't make much sense. > You'd still have to bump soname, but only for the library part. Go learn perl, than come back. Perl Modules might have version numbers, but they certainly don't have SO names. BTW: Give a descend definition of what you refer to as soname, and I might apologize and say that you are right. But for now we either have different ideas of what a soname is or you don't have much knowledge about perl (heck, I don't know perl well, but I know enough to be certain that perl modules don't have anything I would call a soname). This is _not_ hard to get right, and there is really no exuse not get it right. The only way to get it right (in your sense of the word) would be to rename the Perl Mail::SpamAssassin module (along with its sub-modules) to Mail::SpamAssassin3. However, this would make some programs break which are otherwise able to cope with v3 Mail:SpamAssasin quite well. spampd for example has a total of 10 lines which differentiate between versions v being < 2.7, 2.7 <= v < 3.0 and v >= 3.0 _and_ do what's needed to work with either of the three possible categories of SpamAssassin versions. If SpamAssasin v3 would be renamed to Mail::SpamAssassin3, the changes would be more like 120 lines. And given the fact that the SA3 API has been published more than 7 month ago (more like 8: 2004-02-18 was the last date on which the API was changed in an incompatible way), each tool had more than enough time to adjust to this. Note: The outside API (i.e. the API to _use_ SpamAssassin as opposed to the inside API used to enhance SpamAssassin by plugins) only had pretty minor changes. Regards, Sven
Re: possible mass bug filing: spamassassin 3
Sven Mueller [u] wrote on 10/10/2004 04:46: Go learn perl, than come back. Sheesh, I shouldn't write mail after prolonged discussions with my boss... I apologize for the rudeness of that comment. Even though it was meant somewhat jokingly, I realize it probably was too harsh. Sorry. cu, sven
Re: about volatile.d.o/n
Jesus Climent [u] wrote on 09/10/2004 02:28: On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? I dont see any reason why not, if they can be marked as NotAutomatic. I certainly see reason not to include X in colatile. X pulls in xlibs, and xlibs is depended on by a _huge_ amount of programs if I'm not mistaken. It is near impossible to tell wether an X upgrade might break things or not. As for the kernel: If I were a volatile RM-aequivalent, I might consider getting the kernel into v.d.o, even though it is a huge beast, it usually either breaks completely on some specific system or it doesn't break anything. But I'm not sure about this. regards, Sven
