Re: Packages descriptions review
Wouter Verhelst wrote: > On Sat, Jul 30, 2005 at 08:30:51PM -0400, Anthony DeRobertis wrote: > They shouldn't be, as they're not supposed to be complete sentences > either (think of it as "package -- short description", as in "foo -- a > program to do something", or even "foo -- do something") Yeah, I know that argument, and happen to agree with it. I believe last time it came up a flamewar^W spirated discussion ensued. Was a consensus on that ever reached? If so, a lot of descriptions violate that consensus, and we should find an automated way of checking this (to the extent possible; proper nouns do need to be capitalized always). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
> On Sun, 2005-07-31 at 23:10 +0400, Nikita V. Youshchenko wrote: > > (3) allow new upstream into stable. > > But, how would be the proposed process for this software? > > I mean, should they also have some kind of grace period after uploading > to unstable? Would it enter stable after unstable? Or after testing? Or > would it enter stable directly without any kind of testing period? All > upstream releases would go into stable, or only those fixing non-trivial > bugs? How would we be able to remain security and stability on sarge > with this? This all is discussable. I think that new upstream should be allowed into stable only when it's clear that there is no other way to fix a critical problem. The decision should be made individually to each version. Moving through unstable and even testing is probably not an option because of library differences. So either packages should go directly, or after a short testing period through somethibng like proposed-updates. Since such cases should be very rare, they may be handled manually (so infrastructure changes are not needed). For the same reason, I don't think that stability risks are high. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
Jose Carlos Garcia Sogo wrote: > > You can also add the epoch number to your own packages. Thus, they will > be always newer than those coming from Debian, so they won't be > upgraded. Of course you don't have to add epochs to upstream sources. > That is not the goal of an epoch. > Upstream provides a debian build environment, of course without epoch. Its just a little bit strange: After running configure you can run "make deb-dist". It will call dpkg-buildpackage to build *.deb files. Regards Harri signature.asc Description: OpenPGP digital signature
Re: NMUs wanted: C++ library packages in need of uploading
On Mon, Jul 25, 2005 at 07:45:39PM -0600, Marcelo E. Magallon wrote:
> After some fiddling with AptPkg, my first cut at generating a list
> of packages ready to be transitioned is attached.
After getting fed up with AptPkg I rewrote the script in the attached
form. If you feed the script the packages files for _all_ the
architectures the output is _more likely_ to be right.
The attached list has been generated with an up to date Packages file
for the following architectures: alpha arm hppa hurd-i386 i386 ia64
m68k mips mipsel powerpc s390 sh sparc.
If you'd like to have exceptions added to this list ("that package
won't be transitioned ever", "that package doesn't need to be
transitioned") drop me a line.
Cheers,
Marcelo
PS: The list is *way* too big.
aegis, Christian Meder <[EMAIL PROTECTED]>
amule, Julien Delange <[EMAIL PROTECTED]>
apt, APT Development Team
apt-utils, APT Development Team
aqsis-libs, Will Newton <[EMAIL PROTECTED]>
aspseek-libmysqldb, Matt Sullivan <[EMAIL PROTECTED]>
avida-base, Miriam Ruiz <[EMAIL PROTECTED]>
bacula-director-common, Jose Luis Tallon <[EMAIL PROTECTED]>
blackbox, Bruno Barrera C. <[EMAIL PROTECTED]>
cdrdao, Andrew Suffield <[EMAIL PROTECTED]>
dcmtk, Juergen Salk <[EMAIL PROTECTED]>
doxygen, Matthias Klose <[EMAIL PROTECTED]>
fam, Chuan-kai Lin <[EMAIL PROTECTED]>
festival, Matthias Urlichs <[EMAIL PROTECTED]>
firebird2-server-common, Debian Firebird Group <[EMAIL PROTECTED]>
gpdf, Filip Van Raemdonck <[EMAIL PROTECTED]>
groff-base, Colin Watson <[EMAIL PROTECTED]>
gs-esp, Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
gstreamer0.8-misc, David I. Lehn <[EMAIL PROTECTED]>
hpoj, Mark Purcell <[EMAIL PROTECTED]>
hylafax-client, Giuseppe Sacco <[EMAIL PROTECTED]>
ibam, Martin Wuertele <[EMAIL PROTECTED]>
icomlib1, A. Maitland Bottoms <[EMAIL PROTECTED]>
ivtools-interviews, Guenter Geiger <[EMAIL PROTECTED]>
kino, Daniel Kobras <[EMAIL PROTECTED]>
konwert, Yann Dirson <[EMAIL PROTECTED]>
ladspa-sdk, Junichi Uekawa <[EMAIL PROTECTED]>
lam4, Camm Maguire <[EMAIL PROTECTED]>
libace5.4, Debian ACE+TAO maintainers <[EMAIL PROTECTED]>
libatlas-cpp-0.5, Michael Koch <[EMAIL PROTECTED]>
libavifile-0.7c102, Zdenek Kabelac <[EMAIL PROTECTED]>
libbeecrypt6, Anibal Monsalve Salazar <[EMAIL PROTECTED]>
libboost-date-time1.32.0, Steve M. Robbins <[EMAIL PROTECTED]>
libboost-filesystem1.32.0, Steve M. Robbins <[EMAIL PROTECTED]>
libboost-python1.32.0, Steve M. Robbins <[EMAIL PROTECTED]>
libboost-regex1.32.0, Steve M. Robbins <[EMAIL PROTECTED]>
libboost-test1.32.0, Steve M. Robbins <[EMAIL PROTECTED]>
libcal3d10, Michael Koch <[EMAIL PROTECTED]>
libccaudio1-1.1-0, Mark Purcell <[EMAIL PROTECTED]>
libchasen0, NOKUBI Takatsugu <[EMAIL PROTECTED]>
libchipcard20, Thomas Viehmann <[EMAIL PROTECTED]>
libclanlib2, Filip Van Raemdonck <[EMAIL PROTECTED]>
libcoyotl2, Al Stone <[EMAIL PROTECTED]>
libcppunit-1.10-2, Steve M. Robbins <[EMAIL PROTECTED]>
libcrypto++5.2, Stephen Zander <[EMAIL PROTECTED]>
libdar3, Brian May <[EMAIL PROTECTED]>
libdb4.2++, Debian Berkeley DB Maintainers <[EMAIL PROTECTED]>
libdc0, Pasi Savilaakso <[EMAIL PROTECTED]>
libdjvulibre1, Barak A. Pearlmutter <[EMAIL PROTECTED]>
libeditex0, Stefano Zacchiroli <[EMAIL PROTECTED]>
libevocosm0, Al Stone <[EMAIL PROTECTED]>
libfirebird2-classic, Debian Firebird Group <[EMAIL PROTECTED]>
libfirebird2-super, Debian Firebird Group <[EMAIL PROTECTED]>
libflac++4, Matt Zimmerman <[EMAIL PROTECTED]>
libfwbuilder6, Jeremy T. Bouse <[EMAIL PROTECTED]>
libgdal1, Silke Reimer <[EMAIL PROTECTED]>
libgfccore-2.0-0, Goedson Teixeira Paixao <[EMAIL PROTECTED]>
libgig, Matt Flax <[EMAIL PROTECTED]>
libginac1.3, Richard Kreckel <[EMAIL PROTECTED]>
libglibmm-2.4-1, Bradley Bell <[EMAIL PROTECTED]>
libglu1-mesa, Marcelo E. Magallon <[EMAIL PROTECTED]>
libgtkmm1.2-0, Bradley Bell <[EMAIL PROTECTED]>
libgtkmm2.0-1c102, Bradley Bell <[EMAIL PROTECTED]>
libgwenhywfar17, Henning Glawe <[EMAIL PROTECTED]>
libhdf5-serial-1.6.4-0, Josselin Mouette <[EMAIL PROTECTED]>
libhk-classes7, Mike Schacht <[EMAIL PROTECTED]>
libibtk0, Christian Bayle <[EMAIL PROTECTED]>
libid3-3.8.3, Robert Woodcock <[EMAIL PROTECTED]>
libinti1.0-1.2, Goedson Teixeira Paixao <[EMAIL PROTECTED]>
libjabberoo0, Goedson Teixeira Paixao <[EMAIL PROTECTED]>
libktoblzcheck1, Thomas Viehmann <[EMAIL PROTECTED]>
libmecab0, TSUCHIYA Masatoshi <[EMAIL PROTECTED]>
libmimelib1a, Debian Qt/KDE Maintainers
libmodplug0, Zed Pobre <[EMAIL PROTECTED]>
libmrml1, Robert Jordens <[EMAIL PROTECTED]>
libmusicbrainz2, Andreas Rottmann <[EMAIL PROTECTED]>
libmusicbrainz4, Andreas Rottmann <[EMAIL PROTECTED]>
libofx1, Thomas Bushnell, BSG <[EMAIL PROTECTED]>
libomnithread3, Bastian Blank <[EMAIL PROTECTED]>
libopenalpp-cvs, Loic Dachary (OuoU) <[EMAIL PROTECTED]>
libopenbabel0, Michael Banck <[EMAIL PROTECTED]>
libopenexr2, Andrew Lau <[EMAIL PROTECTED]>
libopenhbci14, Thomas Viehmann <[EMAIL PROTECTED]>
libopenthreads, Loic Dachary (OuoU) <[EMAIL PROTECTED]>
libopenvrml4, Sam Hocevar
Re: Bug#320672: ITP: leo -- English-German dictionary using dict.leo.org
Helge Kreutzmann wrote: > leo is a program for the command line which translates German words leo is a command-line program that translates... > into their English counterpart and vice versa using dict.leo.org. Suggestion: "Equivalent" instead of "counterpart." > This packages needs libnet-dict-leo-perl. Is that already packaged or ITP'd? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
OK, I've summarized all (I think) of Policy's requirements on packages in the wiki page, together with a cite to the section it came from. Also, I've completed "news", and would appreciate any feedback. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
2005-07-31 (日) の 22:34 +0200 に Ondrej Sury さんは書きました: > On Sun, 2005-07-31 at 15:32 +0200, Andreas Barth wrote: > > Hi, > > > > libdb4.1 should be removed from Debian soon. The following packages > > still use it (but could move forward to the more recent db4.2 or db4.3 > > package): > > > > libedataserver1.2-4 > > evolution-exchange > > evolution-data-server1.2 > > evolution > > evolution-data-server > > libedataserver1.2-dev > > Hi, > > I think that this could be delicate issue, because evolution creates DB > files in .evolution and it has to be migrated automaticaly for an user. > So bug is OK, but NMU would not be AFAIK welcomed, since it could broke > user addressbooks, etc. > > Takuo, am I right? Yes. I think so too. -- Takuo KITAME -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
On Sun, 2005-07-31 at 23:10 +0400, Nikita V. Youshchenko wrote: > (3) allow new upstream into stable. But, how would be the proposed process for this software? I mean, should they also have some kind of grace period after uploading to unstable? Would it enter stable after unstable? Or after testing? Or would it enter stable directly without any kind of testing period? All upstream releases would go into stable, or only those fixing non-trivial bugs? How would we be able to remain security and stability on sarge with this? Thanks, -- David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/ I smoke ten to fifteen cigars a day. At my age I have to hold on to something. GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
Tshepang Lekhonkhobe <[EMAIL PROTECTED]> writes: >> I ended up downgrading to xfree86 from testing, and then upgraded back up >> to xorg from unstable (and all that went smoothly). > > I was also using ubuntu's xorg on Sid, but unlike you I am still > unable to install xserver-xorg and xserver-common or even > xserver-xfree86 from testing. This means I can't run GNOME. Can you > help? Er, well, what goes wrong? I think I had to temporarily de-install a bunch of random Gnome packages and the like too. Of course I just re-installed them after I was done. I use aptitude BTW, which is generally a bit smarter about things than other package managers. -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please fix your RC bugs
In article <[EMAIL PROTECTED]> you wrote: > We can't keep the same ABI and toolchain forever, can we? Well, currently Solaris is doing bit advertisemet that they did not (never?) break compatibility. However since I am not into C++ ABI I cant comment if the current interface is ok or not. It is just very annoying that it is constantly changed, and that the compiler keeps also breaking source. I do see an advantage in breaking backward compatibility sometimes. This is a strong point in open source to be able to change old code, commercial systms suffer from it. Howeer we should not stress this too much. But maybe that comment needs to go in GCC direction. Personally I would say to wait for those transitions until the required source changes have reached upstream. And especially I dont see the need for urgend calls to fix those trivial bugs. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please fix your RC bugs
On Sun, Jul 31, 2005 at 08:22:26AM -0600, Wesley J. Landaker wrote: > On Sunday 31 July 2005 00:19, Andreas Barth wrote: > > we currently have almost 800 RC bugs in etch due to small glitches that > > started to make code FTBFS with the new gcc version. > > It is urgently necessary that maintainers start to fix their own > > packages, and that whoever has some time at their hands, NMU such > > packages. > A lot of that is waiting on the C++ ABI transition, and dependencies. And if > you NMU, please make sure you know what you're doing and read the bugs in > question, so that you are not hurting more than you help. FWIW, if the package actually *can* be built against the existing libraries using g++-4.0, then it doesn't actually hurt to do so as long as the package doesn't build libraries that need to be renamed. Yes, the package will have to be rebuilt again once the libs have transitioned to g++-4.0, if only because of the package name changes; but if these NMUs let us clear out the libjack transition ahead of the various other transitions, that would certainly be a good thing. > I don't want to rant, but since you are urging NMUs and apparently doing > them yourself. Your recent NMU of cheeesetracker compiled it against two > C++ ABIs; you could avoided this if you read the bug report and my > response. Also, always contact the maintainer first, and use a delayed > upload queue. You did neither of these when NMUing cheesetracker. Compiling against two C++ ABIs should not actually cause any damage *in cases where the linker command succeeds*, since libstdc++ uses fully versioned symbols. But of course one should always try to communicate with the maintainer before uploading an NMU, regardless. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#315945: seyon does not work when gnome-terminal is installed
[ Forwarded to -devel for discussion ] On Tue, Jun 28, 2005 at 02:30:16PM +0100, Steve McIntyre wrote: >On Mon, Jun 27, 2005 at 01:54:32PM +0200, Simon K?gstr?m wrote: >>Package: seyon >>Version: 2.20c-16 >>Severity: grave >>Justification: renders package unusable >> >>seyon does not work when gnome-terminal is installed. When I try to run >>it, I get the following message: >> >>Option --tclass is no longer supported in this version of >>gnome-terminal; you might want to create a profile with the desired >>setting, and use the new --window-with-profile option Two "--title" >>options given for one tab >> >>without gnome-terminal, seyon starts. I did not change any configuration >>(just installed the two packages). > >This is not a grave bug, it's easy to install rxvt or xterm and >configure seyon to use those. I'm actually tempted to reassign the bug >to gnome-terminal instead, for willfully breaking compatibility with >the older terminal programs for no obvious reason... How consistent an interface is meant to be provided by programs providing x-terminal-emulator? Seyon calls x-terminal-emulator with several command-line options to set the title etc. for the terminal sub-window that it starts. On xterm, rxvt and others this works fine. Gnome-terminal used to work just fine with these command-line options, but for reasons unknown now throws the quoted errors instead. I can see a few options for this bug: a) conflict with gnome-terminal (not a sensible option) b) depend on, and use xterm/rxvt/something specific rather than just using x-terminal-emulator (again, not good - people would then be forced to install/use that terminal, regardless of system settings) c) write a wrapper script for the terminal emulator, and cope with finding the right options for each possible emulator (potentially huge amount of work) d) reassign this to gnome-terminal (for gratuitously breaking compatibility) Suggestions gratefully received... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth signature.asc Description: Digital signature
Bug#320716: ITP: lablgtksourceview -- OCaml bindings for GtkSourceView
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> * Package name: lablgtksourceview Version : 0.0.1 Upstream Author : Stefano Zacchiroli <[EMAIL PROTECTED]> * URL : http://helm.cs.unibo.it/software/lablgtksourceview/ * License : LGPL Description : OCaml bindings for GtkSourceView LablGtkSourceView are the OCaml bindings for GtkSourceView, a GTK widget which extends the standard GTK text widgets implementing syntax highlighting, automatic indentation, and other typical features of source editors. Using LablGtkSourceView you can instantiate and use GtkSourceView widgets in OCaml programs which use GTK through the LablGtk interface. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
W. Borgert <[EMAIL PROTECTED]> wrote: >> (1) keep vulnerable packages in stable, >> (2) remove affected packages from distribution, >> (3) allow new upstream into stable. > I'ld "vote" for (2), maybe with the goal of creating pressure > towards upstream to take security more serious. But how do you push the users to remove the package from their systems? In reality they will keep the broken version installed and so you have (1) again :-( Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
El dom, 31-07-2005 a las 22:20 +0200, Harald Dunkel escribió: > Philipp Kern wrote: > > > > The maintainer could use an epoch to fix it. (It's like a 1: prefix.) > > > > > >>2.5.130.CVS.2005.07.19.01-1 > >>2.5.13-0.CVS.2005.07.19.01-1 > > > > > > Is it really important to have the 0 split away? I think while dashes > > are perfectly valid when there is a Debian revision they are not really > > loved by the maintainers. > > > > I'm running my own fvwm package for several years. Now it > appears to be always out-of-date, since the broken upstream > version number part of fvwm in the official repository seems > to have jumped from 2.5.12 to 2.5.130.xxx instead of 2.5.13. Put it on hold, and you won't be asked about upgrading it again. And you have been told above, using the dash in the upstream version is not a good option. > > The epoch number is not supported in the official fvwm sources. You can also add the epoch number to your own packages. Thus, they will be always newer than those coming from Debian, so they won't be upgraded. Of course you don't have to add epochs to upstream sources. That is not the goal of an epoch. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
Hi, * W. Borgert <[EMAIL PROTECTED]> [2005-07-31 23:24]: > On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote: > > (1) keep vulnerable packages in stable, > > (2) remove affected packages from distribution, > > (3) allow new upstream into stable. > ... > > What do you think on this? > > I'ld "vote" for (2), maybe with the goal of creating pressure > towards upstream to take security more serious. Don't forget: > The new versions will bring trouble to our poor users, as it's > not API nor ABI compatible, has different bugs, etc. Can't > Debian + Ubuntu + ... create enough demand for useful security > patches? Remember the KDE/Qt licensing discussion... > > (3) is second best. At least typical server installations are > not affected (we use w3m, don't we?) and desktop users are used > to frustration anyway. (1) is not an option. I think for 1 there is no way! 3 would be the best if this is possible and will not break the whole system. 2 would make sense if there is not a big community using the package or if this package has got no critical reverse dependencies. I think it would be good if the maintainer would try 3 and then a discussion on -devel should follow. If this doesn't work the package has to be removed. Regards NIco -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpajDay3eCIn.pgp Description: PGP signature
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote: > (1) keep vulnerable packages in stable, > (2) remove affected packages from distribution, > (3) allow new upstream into stable. ... > What do you think on this? I'ld "vote" for (2), maybe with the goal of creating pressure towards upstream to take security more serious. Don't forget: The new versions will bring trouble to our poor users, as it's not API nor ABI compatible, has different bugs, etc. Can't Debian + Ubuntu + ... create enough demand for useful security patches? Remember the KDE/Qt licensing discussion... (3) is second best. At least typical server installations are not affected (we use w3m, don't we?) and desktop users are used to frustration anyway. (1) is not an option. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
On Sun, 2005-07-31 at 15:32 +0200, Andreas Barth wrote: > Hi, > > libdb4.1 should be removed from Debian soon. The following packages > still use it (but could move forward to the more recent db4.2 or db4.3 > package): > > libedataserver1.2-4 > evolution-exchange > evolution-data-server1.2 > evolution > evolution-data-server > libedataserver1.2-dev Hi, I think that this could be delicate issue, because evolution creates DB files in .evolution and it has to be migrated automaticaly for an user. So bug is OK, but NMU would not be AFAIK welcomed, since it could broke user addressbooks, etc. Takuo, am I right? Ondrej. -- Ondrej Sury <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
Philipp Kern wrote: > > The maintainer could use an epoch to fix it. (It's like a 1: prefix.) > > >> 2.5.130.CVS.2005.07.19.01-1 >> 2.5.13-0.CVS.2005.07.19.01-1 > > > Is it really important to have the 0 split away? I think while dashes > are perfectly valid when there is a Debian revision they are not really > loved by the maintainers. > I'm running my own fvwm package for several years. Now it appears to be always out-of-date, since the broken upstream version number part of fvwm in the official repository seems to have jumped from 2.5.12 to 2.5.130.xxx instead of 2.5.13. The epoch number is not supported in the official fvwm sources. Annoying. Regards Harri signature.asc Description: OpenPGP digital signature
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
Hi! Nikita V. Youshchenko [2005-07-31 23:10 +0400]: > So options seem to be: > > (1) keep vulnerable packages in stable, > (2) remove affected packages from distribution, > (3) allow new upstream into stable. We recently had the same problem in Ubuntu. Adam Conrad and me both spend literally weeks with backporting and fixing patches, and in the end we came up with a semi-working Firefox which was pretty buggy and broke almost all extensions. So we just gave up and uploaded the new upstream versions into stable, which made relatively little trouble compared to the mess we created with backporting. It was not an easy decision since usually we follow the same strict "minimal patches" backporting policy, but we finally had to bow to reality; the Mozilla code is so ugly and intertwined that backporting patches is a battle you can't win without employing a couple of upstream developers (which just say "use the new upstream version, dude!"). I think in the end we have to do the same for Debian. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes: > Maybe in rare cases like this one, when these seems to be no other way to > keep important package set secure, we should allow new upstream into > Debain Stable? In this rare cases I agree otherwise the users will continue to use vulnerable packages or will use backports and then don't have sure that the build system is trusted. Is possible to use volatile for this kinda of things but I don't like the idea because not all users will use it. my 2c. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
On Sun, 2005-07-31 at 21:21 +0200, Harald Dunkel wrote: > And how is this going to be fixed? The broken version > number might be much higher than upstream's version > number. AFAIK there is no way to turn it back, is it? The maintainer could use an epoch to fix it. (It's like a 1: prefix.) > 2.5.130.CVS.2005.07.19.01-1 > 2.5.13-0.CVS.2005.07.19.01-1 Is it really important to have the 0 split away? I think while dashes are perfectly valid when there is a Debian revision they are not really loved by the maintainers. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
Jose Carlos Garcia Sogo wrote: > El dom, 31-07-2005 a las 19:13 +0200, Harald Dunkel escribió: > >>Hi folks, >> >>What happens if a package maintainer ignores upstream's >>version number (either on purpose, or by accident, e.g. >>a typo)? Is this allowed? > > > If it is done on purpose and for a given reason, it can be perfectly > valid. If not, you can consider that a bug, as usually package should > have the same version than upstream's distributed sources. > And how is this going to be fixed? The broken version number might be much higher than upstream's version number. AFAIK there is no way to turn it back, is it? The package I have in mind (fvwm) introduced a broken version number 2.5.130.CVS.2005.07.19.01-1 instead of 2.5.13-0.CVS.2005.07.19.01-1 Creating a bug report (#319386) did not help. Regards Harri signature.asc Description: OpenPGP digital signature
RFC: allow new upstream into stable when it's the only way to fix security issues.
Hello.
As it is being currently discussed on debian-security [1], security team
has hard times supporting mozilla family of packages, because of
unfriendly upstream policy - they don't want to isolate security fixes
from a large changesets of new upstream releases. And given the huge size
of the package, isolating security patches at Debian level also fails.
So options seem to be:
(1) keep vulnerable packages in stable,
(2) remove affected packages from distribution,
(3) allow new upstream into stable.
(1) is how it was done in woody times; however I think that most people
agree that it is a very bad option to keep users' systems vulnerable.
(2) may be a solution - but since mozilla and related packages (firefox,
thunderbird, galeon) are widely used, removing those looks like a serious
violation of SC ("debian supports it's users").
(3) is against the way how Debian used to work for years. However, isn't it
the time to tune our processes to keep with real-world issues better?
Maybe in rare cases like this one, when these seems to be no other way to
keep important package set secure, we should allow new upstream into
Debain Stable?
This should be extremely rare situation; probably approval from the
Technical Comettie should be needed in each case.
What do you think on this?
[1] http://lists.debian.org/debian-security/2005/07/msg00315.html
pgp8mBRGPfcWL.pgp
Description: PGP signature
Re: ignoring upstream's version number?
On Sun, Jul 31, 2005 at 07:13:43PM +0200, Harald Dunkel wrote: > What happens if a package maintainer ignores upstream's > version number (either on purpose, or by accident, e.g. > a typo)? Is this allowed? It depends on the situation - for example, nis ignores the upstream version number completely because it is an amalgam of three different upstream releases but I expect that's not the sort of situation you are thinking of. Could you be more specific about the situation, perhaps? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please fix your RC bugs
On Sunday 31 July 2005 08:22, Wesley J. Landaker wrote: > I don't want to rant, but since you are urging NMUs and apparently doing > them yourself. Your recent NMU of cheeesetracker compiled it against two > C++ ABIs; you could avoided this if you read the bug report and my > response. Also, always contact the maintainer first, and use a delayed > upload queue. You did neither of these when NMUing cheesetracker. BTW, I apologize if this came off sounding like a personal attack; I know Andreas meant well, and we all make mistakes. Sorry for getting upset at you, Andreas! But please, everyone, please be careful and considerate when you NMU--especially during this C++ ABI transition, or it'll just make things longer and harder. =) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpkxIWGqZtPU.pgp Description: PGP signature
Periodic cleanup of old automake versions (aka, removal of automake1.6)
Hello, We now have 5 versions of automake in the archive. These are necessary because new versions of automake tend to break backwards compatibility. We don't however need to keep all these versions around forever. So I'd like to get automake1.6 removed from the archive. The packages below have strict build-dependencies on automake1.6. It tends to be a bad idea to build-depend on the auto* tools (if for the only reason I'll be bugging you about it periodically), but if you want to continue, please transition to using automake1.7 or later (automake1.9 being the best). For most of you that should just work with no changes, if you have problems let me know. In a couple of weeks anyone who hasn't done this will get a wishlist bug filed against their package. A couple of weeks after that I will ask for the removal of automake1.6 and those bugs will be upgraded to severity serious. PS I would love if we could get rid of automake1.4. That's a bit unrealistic at this point, but if everyone can gently encourage their upstreams (and themselves) to start using later versions of automake, maybe it will be possible one day. amarok, Adeodato Simo <[EMAIL PROTECTED]> amaya, Steve Dunham <[EMAIL PROTECTED]> boson-base, Mickael Marchand <[EMAIL PROTECTED]> droidbattles, Kari Pahula <[EMAIL PROTECTED]> epplets, Stephen Frost <[EMAIL PROTECTED]> facturalux, Juan Manuel Garcia Molina <[EMAIL PROTECTED]> fam, Chuan-kai Lin <[EMAIL PROTECTED]> freqtweak, Enrique Robledo Arnuncio <[EMAIL PROTECTED]> gsmlib, automake1.6 isdnutils, Paul Slootman <[EMAIL PROTECTED]> k3d, David Martinez Moreno <[EMAIL PROTECTED]> kcdlabel, Stephen Gran <[EMAIL PROTECTED]> kde-i18n, Noel Kothe <[EMAIL PROTECTED]> ksimus-boolean, Aurelien Jarno <[EMAIL PROTECTED] ksimus-datarecorder, Aurelien Jarno <[EMAIL PROTECTED]> ksimus-floatingpoint, Aurelien Jarno <[EMAIL PROTECTED]> ksociograma, Juan Manuel Garcia Molina <[EMAIL PROTECTED]> lesstif1-1, Sam Hocevar (Debian packages) <[EMAIL PROTECTED]> libiodbc2, Christian Hammers <[EMAIL PROTECTED]> libnss-ldap, Stephen Frost <[EMAIL PROTECTED]> libosip, Anand Kumria <[EMAIL PROTECTED]> libosip2, ARAKI Yasuhiro <[EMAIL PROTECTED]> libtheora, Christopher L Cheney <[EMAIL PROTECTED]> libwmf, Matej Vela <[EMAIL PROTECTED]> lineak-defaultplugin, Aurelien Jarno <[EMAIL PROTECTED]> lineak-kdeplugins, Aurelien Jarno <[EMAIL PROTECTED]> lineak-xosdplugin, Aurelien Jarno <[EMAIL PROTECTED]> multisync, Mikael Sennerholm <[EMAIL PROTECTED]> rsplib, Anibal Monsalve Salazar <[EMAIL PROTECTED]> snort, Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]> splint, Samuele Giovanni Tonon <[EMAIL PROTECTED]> sppc, Mikael Hedin <[EMAIL PROTECTED]> sweep, Anand Kumria <[EMAIL PROTECTED]> swscanner, Andres Seco Hernandez <[EMAIL PROTECTED]> tapiir, Enrique Robledo Arnuncio <[EMAIL PROTECTED]> wmfsm, Arthur Korn <[EMAIL PROTECTED]> xbsql, Rafal Lewczuk <[EMAIL PROTECTED]> -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: please fix your RC bugs
On 7/31/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> you wrote: > > I don't want to rant, but since you are urging NMUs and apparently doing > > them yourself. Your recent NMU of cheeesetracker compiled it against two > > C++ ABIs; you could avoided this if you read the bug report and my > > response. Also, always contact the maintainer first, and use a delayed > > upload queue. You did neither of these when NMUing cheesetracker. > > Besides I find those contant ABI and toolchain changes pretty annoying, this > is really killing a lot of productive work. We can't keep the same ABI and toolchain forever, can we?
Re: please fix your RC bugs
In article <[EMAIL PROTECTED]> you wrote: > I don't want to rant, but since you are urging NMUs and apparently doing > them yourself. Your recent NMU of cheeesetracker compiled it against two > C++ ABIs; you could avoided this if you read the bug report and my > response. Also, always contact the maintainer first, and use a delayed > upload queue. You did neither of these when NMUing cheesetracker. Besides I find those contant ABI and toolchain changes pretty annoying, this is really killing a lot of productive work. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream's version number?
El dom, 31-07-2005 a las 19:13 +0200, Harald Dunkel escribió: > Hi folks, > > What happens if a package maintainer ignores upstream's > version number (either on purpose, or by accident, e.g. > a typo)? Is this allowed? If it is done on purpose and for a given reason, it can be perfectly valid. If not, you can consider that a bug, as usually package should have the same version than upstream's distributed sources. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED]
ITP: pcmciautils -- PCMCIA userspace utilities (Linux 2.6.13+)
retitle 319583 ITP: pcmciautils -- PCMCIA userspace utilities (Linux 2.6.13+) thanks I'm the maintainer of pcmcia-cs so I'm intending to package pcmciautils. * Package name: pcmciautils Version : 007 Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]> * URL : http://kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html * License : GPL Description : PCMCIA userspace utilities (Linux 2.6.13+) PCMCIAutils contains hotplug scripts and initialization tools necessary to allow the PCMCIA subsystem to behave (almost) as every other hotpluggable bus system. It only works 2.6.13 kernels and later. -- Pelle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ignoring upstream's version number?
Hi folks, What happens if a package maintainer ignores upstream's version number (either on purpose, or by accident, e.g. a typo)? Is this allowed? Regards Harri signature.asc Description: OpenPGP digital signature
Bug#320685: ITP: xfce4-sensors-plugin -- graphical hardware sensors display plugin for the Xfce4 panel
Package: wnpp Severity: wishlist Owner: Stefan Ott <[EMAIL PROTECTED]> * Package name: xfce4-sensors-plugin Version : 0.6.1 Upstream Author : Fabian Nowak <[EMAIL PROTECTED]> * URL : http://xfce-goodies.berlios.de/ * License : GPL Description : graphical hardware sensors display plugin for the Xfce4 panel The xfce4-sensors-plugin is, as the name implies, a plugin for the Xfce4 panel which displays data from your hardware sensors. It allows you to select the sensor values you'd like to see and the way you'd like them to be displayed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#320637: ITP: lltag -- Massive and magic command-line mp3/ogg file tagger
Ok, thanks for your comments. I've uploaded a new package to lltag webpage with the following description: Description: Automatic command-line mp3/ogg file tagger lltag is a command-line tool to set ID3 tags of mp3 files and Ogg tags. It may be used to tag multiples files at once by comparing their filename or pathname against a configurable list of formats. Regards, Brice Le 31.07.2005 05:02, Anthony DeRobertis a écrit : > Brice Goglin wrote: > >>Package: wnpp >>Severity: wishlist >>Owner: Brice Goglin <[EMAIL PROTECTED]> >> >> >>* Package name: lltag >> Version : 0.6.1-1 >> Upstream Author : Brice Goglin <[EMAIL PROTECTED]> >>* URL : http://bgoglin.free.fr/lltag/ >>* License : GPL >> Description : Massive and magic command-line mp3/ogg file tagger > > > I don't think "massive" is the right word here, unless this program is > 300MB, in which case I question if it should be put in the archive. > > Also, "magic" is not a very useful description of the program. > > >> lltag is a command-line tool to set ID3 tags of mp3 files >> and Ogg tags. It may be used to tag multiples files at >> once by comparing their filename or pathname with >> different formats. >> Formats may be either passed on command-line or guess >> by the program automagically. > > > Strike the last sentence. Usage information doesn't belong here. > Instead, put "by compare their ... against a configurable list of > formats." in the sentence above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please fix your RC bugs
On Sunday 31 July 2005 00:19, Andreas Barth wrote: > we currently have almost 800 RC bugs in etch due to small glitches that > started to make code FTBFS with the new gcc version. > > It is urgently necessary that maintainers start to fix their own > packages, and that whoever has some time at their hands, NMU such > packages. A lot of that is waiting on the C++ ABI transition, and dependencies. And if you NMU, please make sure you know what you're doing and read the bugs in question, so that you are not hurting more than you help. I don't want to rant, but since you are urging NMUs and apparently doing them yourself. Your recent NMU of cheeesetracker compiled it against two C++ ABIs; you could avoided this if you read the bug report and my response. Also, always contact the maintainer first, and use a delayed upload queue. You did neither of these when NMUing cheesetracker. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpHPESKi7nx2.pgp Description: PGP signature
about to remove libdb4.1
Hi, libdb4.1 should be removed from Debian soon. The following packages still use it (but could move forward to the more recent db4.2 or db4.3 package): arla kerberos4kth-servers vacation libedataserver1.2-4 libroken16-kerberos4kth kerberos4kth-kdc libapache-mod-witch libotp0-kerberos4kth evolution-exchange evolution-data-server1.2 xsim evolution libapache-mod-aspseek evolution-data-server libapache-csacek libapache-mod-speedycgi libdb4.1-ruby1.6 squidguard libedataserver1.2-dev libapache-mod-auth-shadow pkspxyc libdb4.1-ruby1.8 I itend to file important bugs on all of these packages, and after a while, start to NMU these packages. Is there a problem with that? As libdb4.1 is currently RC-buggy, and nobody really intends to put time into the fix, we need to go forward a bit faster than usual. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320672: ITP: leo -- English-German dictionary using dict.leo.org
Package: wnpp Version: N/A; reported 2005-07-31 Severity: wishlist * Package name: leo Version : 2.0.0 Upstream Author : Carsten Luckmann <[EMAIL PROTECTED]> * URL : http://www.itp.uni-hannover.de/~luckmann * License : GPL Description : English-German dictionary using dict.leo.org leo is a program for the command line which translates German words into their English counterpart and vice versa using dict.leo.org. leo does not support offline translations. leo is a very valuable tool for translating english<->german. This packages needs libnet-dict-leo-perl. leo is being used for several years already in our institute, previous version date back to the late 1990s. The perl version is in use for several years, as well as this (up to no inofficial) Debian packet. The user-visible messages (from the program) are already translated into 13 languages. You can get the currenty packages from: http://www.itp.uni-hannover.de/~kreutzm/data/leo_2.0.0-3_all.deb http://www.itp.uni-hannover.de/~kreutzm/data/libnet-dict-leo-perl_0.07-4_all.deb and the diffs from: http://www.itp.uni-hannover.de/~kreutzm/data/leo_2.0.0-3.diff.bz2 http://www.itp.uni-hannover.de/~kreutzm/data/libnet-dict-leo-perl_0.07-4.diff.bz2 The packages were created on a sarge system but should be rebuildable on a woody system as well (earlier versions did, but you'll need to backport one perl-module from sarge as well). -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux zibal 2.4.27-grsec #1 Wed Dec 22 15:20:05 CET 2004 i686 Locale: LANG=en_US, LC_CTYPE=en_US -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *.la dependency_libs and -dev deps
On Sun, Jul 31, 2005 at 12:55:51PM +0200, Loïc Minier wrote: > I tried following the thread on libtool and -dev inter-dependencies, > and I'd like someone to confirm the way to go (a summary of the SUMMARY > thread would be nice :). > What I'm currently doing right now is adding -dev dependencies on -dev > packages for each "-l" in dependency_libs. > I'm currently not paying attention to "*.la" in dependency_libs. > Is that correct? No, it's backwards. If an application is linking against your library using libtool, all of the .la files your own library references *must* be available at build-time, even if doing dynamic linking. The packages providing the "-l" libs are *not* required for normal operation, but they are required if you intend to support static linking or linking with a broken version of libtool. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: How to use svn(-buildpackage) with pbuilder?
On Sun, Jul 31, 2005 at 09:59:04AM +, W. Borgert wrote:
> - How do I have to arrange the repository, so that
better use arrangement which svn-buildpackage creates
branches trunk tags upstream build-area and tarballs
> under pkg-greetings/hello/tags/1.0-1/? Or do I have to put
> the upstream under pkg-greetings/hello/branches/upstream/1.0/?
svn-inject and consequently svn-upgrade does it for you
> - How do I call svn-buildpackage, so that pbuilder is used? Is
> --svn-builder=pdebuild enough?
I'm using
svn-buildpackage --svn-lintian --svn-builder="pdebuild --buildresult
`pwd`/../build-area --auto-debsign "
borrowed from a nice minimalistic HOWTO
http://workaround.org/moin/SvnBuildpackage
> - Has somebody a good build script that does all steps
> automatically? 1. checkout from svn, 2. build in pbuilder,
> 3. run linda, 4. run lintian, 5. run piuparts.
I did without 3 and 5 with a given above commands. But it is easy to add
3 and 5 just add them to --svn-postbuild as IT IS SAID IN THE MAN PAGE:
--svn-prebuild, --svn-postbuild, --svn-pretag, --svn-posttag
Commands (hooks) to be executed before/after the build/tag com-
mand invocations. Examples to fetch the orig tarball from a
local pool (trying pool/libX/... to):
svn-buildpackage --svn-prebuild='a="wget -chttp://mymir-
ror/debian/main/pool/";b="/$package/${package}_${upstream_ver-
sion}.orig.tar.gz"; $a$(echo $package|cut -c0-1)$b || $a$(echo
$package | cut -c0-4)$b'
Multiple retries with a bashism:
svn-buildpackage --svn-prebuild='wget-chttp://mymir-
ror/debian/main/pool/{`echo $package | cut -c0-1`,`echo $package
| cut-c0-4`}/$package/${package}_${upstream_ver-
sion}.orig.tar.gz'
Or using a bounty, see below...
svn-b --svn-prebuild="wget http://mymir-
ror/debian/main/pool/$guess_loc"
> Many thanks in advance!
You are welcome :-)
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpG2QgYKMhqi.pgp
Description: PGP signature
*.la dependency_libs and -dev deps
Hi, I tried following the thread on libtool and -dev inter-dependencies, and I'd like someone to confirm the way to go (a summary of the SUMMARY thread would be nice :). What I'm currently doing right now is adding -dev dependencies on -dev packages for each "-l" in dependency_libs. I'm currently not paying attention to "*.la" in dependency_libs. Is that correct? Bye, -- Loïc Minier <[EMAIL PROTECTED]> Come, your destiny awaits! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to use svn(-buildpackage) with pbuilder?
Hi, what is the right/best way to build packages from SVN using pbuilder? I am new to both, please be patient. Suppose, I have a package with complete upstream sources (no tarballs) under svn://svn.debian.org/svn/pkg-greetings/hello/ with the subdirectories branches/, tags/, and trunk/. - How do I have to arrange the repository, so that svn-buildpackage differentiates correctly upstream and debian stuff? Is it correct to have the upstream source only under pkg-greetings/hello/tags/1.0/ and the complete debianised tree under pkg-greetings/hello/tags/1.0-1/? Or do I have to put the upstream under pkg-greetings/hello/branches/upstream/1.0/? - How do I call svn-buildpackage, so that pbuilder is used? Is --svn-builder=pdebuild enough? - Has somebody a good build script that does all steps automatically? 1. checkout from svn, 2. build in pbuilder, 3. run linda, 4. run lintian, 5. run piuparts. Many thanks in advance! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
Hello, > You must update unreviewed description daily. Checked reviewed > descriptions again and show changes to the reviewer, if the review ist > not finished. Ok, did that. Thanks for your suggestions, -- Clément Stenac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: remove unwanted header lines from e-mails
On Sun, Jul 31, 2005 at 10:19:30AM +0200, Laszlo Boszormenyi wrote: > I have thousands of emails in separate maildirs. I would like to > remove header lines from all of them that matches a pattern. AFAICR > I have already used something similar a long time ago, but now I > can not dig up anything. Is there any tool that can do this (C/C++ > preferred, but Python/Perl is also OK)? (Note that this is much more relevant for debian-user than debian-devel) Try formail, from the procmail package. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
On Sat, Jul 30, 2005 at 08:30:51PM -0400, Anthony DeRobertis wrote: > One more question: Was the question, should short descriptions be > capitalized? ever decided? They shouldn't be, as they're not supposed to be complete sentences either (think of it as "package -- short description", as in "foo -- a program to do something", or even "foo -- do something") -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
remove unwanted header lines from e-mails
Hi, I have thousands of emails in separate maildirs. I would like to remove header lines from all of them that matches a pattern. AFAICR I have already used something similar a long time ago, but now I can not dig up anything. Is there any tool that can do this (C/C++ preferred, but Python/Perl is also OK)? Thanks in advance for any pointers, Laszlo/GCS -- BorsodChem Joint-Stock Company www.debian.org Linux Support Center Software engineerDebian Developer Developer +36-48-511211/23-85 +36-20-4441745 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
Hello, > One more question: Was the question, should short descriptions be > capitalized? ever decided? The policy does not answer this specific question. Anyway, for such highly-repetitive and computer-detectable "errors", it's not a good idea to mark the description as wrong here, it would make a too high number of affected packages. The correct method is to compile a list of such very common problems (in the wiki, for example), decide the best solution for this (in coordination with -devel and -l10n-english), and ask the lintian maintainers to add checks for these. Regards, -- Clément -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
