Re: proposed stable update for libcompress-raw-zlib-perl
On Thu, 2009-08-27 at 00:25 +0300, Niko Tyni wrote: > the security team deferred patching CVE-2009-1391 to the stable > update. This needs to be fixed both in perl and the separate > libcompress-raw-zlib-perl. Please let me know if I can upload > the latter with the attached debdiff. Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: proposed stable update for perl
On Thu, 2009-08-27 at 00:12 +0300, Niko Tyni wrote: > perl (5.10.0-19lenny2) stable; urgency=low > . >* Fix a typo in the replaces/conflicts/provides: libcpan-plus-perl > should have been libcpanplus-perl. (Closes: #516289) >* Fix a memory leak with the map operator. (Closes: #528332) >* Configure CPANPLUS to use the site directories by default. > (Closes: #533707) >* Save local versions of CPANPLUS::Config::System into /etc/perl. > (See #533707) > . > perl (5.10.0-19lenny1) stable-security; urgency=high > . >* [SECURITY] CVE-2009-1391: Fix a buffer overflow in Compress::Raw::Zlib. > (Closes: #532736) Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Security update for ‘burn’ package
On Thu, 2009-08-27 at 14:06 +1000, Ben Finney wrote: > "Adam D. Barratt" writes: > > Please could you prepare and send an updated diff which does not include > > the removal of old commented out code and the removal of functions from > > "import" lines where the code is no longer used? > > Done now, and attached to this message. Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-team] RFS: sponsor for poppler stable point release
On Thu, 27 Aug 2009 01:38:18 pm Michael S Gilbert wrote: > Hi, > > A new lenny release is coming soon and there are some open security > issues in poppler that I have fixed. Attached is the debdiff of the > changes. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/p/poppler > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/p/poppler/poppler_0.8.7-2lenny1. >dsc > > I would be glad if someone uploaded this package for me. Doesn't matter, as long as the version number is higher than the previous stable one, but lower than the one in testing. I personally prefer to have the codename in the version. Cheers Steffen -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-team] RFS: sponsor for poppler stable point release
On Thu, 27 Aug 2009 01:38:18 pm Michael S Gilbert wrote: > Hi, > > A new lenny release is coming soon and there are some open security > issues in poppler that I have fixed. Attached is the debdiff of the > changes. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/p/poppler > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/p/poppler/poppler_0.8.7-2lenny1. >dsc > > I would be glad if someone uploaded this package for me. Just a note, I haven't looked at the patch. The distribution field for point release updates should either say "stable" or "stable-proposed-updates". Only uploads targeted for security.debian.org should have "stable-security" in the distribution field. Cheers Steffen -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Security update for ‘burn’ package
"Adam D. Barratt" writes:
> Ah, yes, I missed that on my first skim through the diff due to the
> horrible indent level. :-/
Take a guess what was one of the first refactoring operations done to
the code base by new upstream :-)
> Looking through the diff again, there are a lot of changes which don't
> appear to be required and make the diff harder to review; one of the
> principles of stable updates is that diffs should be minimal wherever
> possible.
Understood; I was aiming for that, but I appreciate knowing where this
can be improved.
> Please could you prepare and send an updated diff which does not include
> the removal of old commented out code and the removal of functions from
> "import" lines where the code is no longer used?
Done now, and attached to this message.
diff -Nru burn-0.4.3/debian/changelog burn-0.4.3/debian/changelog
--- burn-0.4.3/debian/changelog 2009-08-23 15:12:43.0 +1000
+++ burn-0.4.3/debian/changelog 2009-08-27 13:40:56.0 +1000
@@ -1,3 +1,12 @@
+burn (0.4.3-2.2) stable; urgency=high
+
+ * Non-maintainer upload.
+ * Security fix for “TEMP-0542329 burn: Insecure escaping of file names”.
+ * Backport fix for secure handling of child process command arguments.
+(Closes: Bug#542329)
+
+ -- Ben Finney Thu, 27 Aug 2009 13:35:51 +1000
+
burn (0.4.3-2.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru burn-0.4.3/debian/control burn-0.4.3/debian/control
--- burn-0.4.3/debian/control 2009-08-23 15:12:43.0 +1000
+++ burn-0.4.3/debian/control 2009-08-27 13:40:56.0 +1000
@@ -2,7 +2,7 @@
Section: otherosfs
Priority: optional
Maintainer: Gaetano Paolone (bigpaul)
-Build-Depends: debhelper (>= 4.0.0)
+Build-Depends: debhelper (>= 4.0.0), quilt (>= 0.40)
Standards-Version: 3.6.0
Package: burn
diff -Nru burn-0.4.3/debian/patches/01.subprocess.patch burn-0.4.3/debian/patches/01.subprocess.patch
--- burn-0.4.3/debian/patches/01.subprocess.patch 1970-01-01 10:00:00.0 +1000
+++ burn-0.4.3/debian/patches/01.subprocess.patch 2009-08-27 13:40:56.0 +1000
@@ -0,0 +1,433 @@
+Author: Ben Finney
+Description: Bug#542329: burn: Quotation marks in filenames aren't handled properly.
+Use ‘subprocess’ module, with command argument sanitisation, for
+all invocation and interaction with child processes.
+
+=== modified file 'burn'
+--- old/burn 2005-03-16 19:37:40 +
new/burn 2009-08-27 03:14:53 +
+@@ -53,6 +53,8 @@
+ import ogg.vorbis
+ import gettext
+ import popen2, pwd
++import subprocess
++import shlex
+ import tty, termios, time, fnmatch
+
+ gettext.bindtextdomain('burn', '/usr/share/locale/it/LC_MESSAGES/')
+@@ -147,12 +149,15 @@
+
+ def check_media_empty():
+ """check if cdrom is empty using cdrdao"""
+- # giuppi's function
+- device = config.get('CD-writer','device')
+- driver = config.get('CD-writer','driver')
+- media_raw_info=popen2.popen2('%s disk-info --device %s --driver %s 2>/dev/null'%(cdrdao,device,driver))
++ command_args = [
++ cdrdao, "disk-info",
++ "--device", config.get('CD-writer', 'device'),
++ "--driver", config.get('CD-writer', 'driver'),
++ ]
++ command_process = subprocess.Popen(
++ command_args, close_fds=True,
++ stdout=subprocess.PIPE, stderr=open(os.devnull))
+- lines=media_raw_info[0].readlines()
+- for line in lines:
++ for line in command_process.stdout:
+ if line.startswith('CD-R empty'):
+ if line.split(':')[1].strip()=='yes':
+ return True
+@@ -175,12 +180,15 @@
+
+ def get_media_capacity():
+ """get media capacity using cdrdao"""
+- # giuppi's function
+- device = config.get('CD-writer','device')
+- driver = config.get('CD-writer','driver')
+- media_raw_info=popen2.popen2('%s disk-info --device %s --driver %s 2>/dev/null'%(cdrdao,device,driver))
+- lines=media_raw_info[0].readlines()
+- for line in lines:
++ command_args = [
++ cdrdao, "disk-info",
++ "--device", config.get('CD-writer', 'device'),
++ "--driver", config.get('CD-writer', 'driver'),
++ ]
++ command_process = subprocess.Popen(
++ command_args, close_fds=True,
++ stdout=subprocess.PIPE, stderr=open(os.devnull))
++ for line in command_process.stdout:
+ if line.startswith('Total Capacity'):
+ if line.split(':')[1].strip()=='n/a':
+ return None
+@@ -284,23 +292,20 @@
+ class ISO:
+ "ISO class"
+ path_o = []
+- mkisofs_line = ''
++ mkisofs_args = []
+ windows = config.get('ISO','windows_read')
+ tempdir = config.get('ISO','tempdir')
+ image_name = config.get('ISO','image')
+ mount_dir = config.get('ISO','mount_dir')
+ dest = normpath(tempdir + image_name)
+- def mkisofs_line_append(self, addenda):
+- """append string (addenda) to mkisofs_line"""
+- self.mkisofs_line = self.mkisofs_line + addenda
+- def mkisofs_line_view(self):
+- """view command in mkisofs_line"""
+- return self.mkisofs_line
+ def create(self):
+- """exec command in mkisofs_line"""
++ """ Execute data track recording command. """
+ print _('Creating temporary image: '), self.dest
+
RFS: sponsor for poppler stable point release
Hi, A new lenny release is coming soon and there are some open security issues in poppler that I have fixed. Attached is the debdiff of the changes. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/poppler - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/poppler/poppler_0.8.7-2lenny1.dsc I would be glad if someone uploaded this package for me. Kind regards, Michael Gilbert poppler.debdiff Description: Binary data
proposed stable update for libcompress-raw-zlib-perl
Hi release team,
the security team deferred patching CVE-2009-1391 to the stable
update. This needs to be fixed both in perl and the separate
libcompress-raw-zlib-perl. Please let me know if I can upload
the latter with the attached debdiff.
Thanks for your work,
--
Niko Tyni nt...@debian.org
diff -u libcompress-raw-zlib-perl-2.012/debian/changelog
libcompress-raw-zlib-perl-2.012/debian/changelog
--- libcompress-raw-zlib-perl-2.012/debian/changelog
+++ libcompress-raw-zlib-perl-2.012/debian/changelog
@@ -1,3 +1,10 @@
+libcompress-raw-zlib-perl (2.012-1lenny1) stable; urgency=high
+
+ * [SECURITY] CVE-2009-1391: Fix a buffer overflow in inflate().
+(Closes: #532738)
+
+ -- Niko Tyni Sat, 13 Jun 2009 22:19:41 +0300
+
libcompress-raw-zlib-perl (2.012-1) unstable; urgency=low
* New upstream release
diff -u libcompress-raw-zlib-perl-2.012/debian/patches/series
libcompress-raw-zlib-perl-2.012/debian/patches/series
--- libcompress-raw-zlib-perl-2.012/debian/patches/series
+++ libcompress-raw-zlib-perl-2.012/debian/patches/series
@@ -1 +1,2 @@
+CVE-2009-1391
use-debian-zlib.patch
only in patch2:
unchanged:
--- libcompress-raw-zlib-perl-2.012.orig/debian/patches/CVE-2009-1391
+++ libcompress-raw-zlib-perl-2.012/debian/patches/CVE-2009-1391
@@ -0,0 +1,18 @@
+[SECURITY] CVE-2009-1391: Fix a buffer overflow in inflate().
+
+Closes: #532738
+
+https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1391
+
+Fix cherry-picked from upstream version 2.017.
+--- libcompress-raw-zlib-perl-2.012.orig/Zlib.xs
libcompress-raw-zlib-perl-2.012/Zlib.xs
+@@ -1319,7 +1319,7 @@
+ while (RETVAL == Z_OK) {
+ if (s->stream.avail_out == 0 ) {
+ /* out of space in the output buffer so make it bigger */
+-Sv_Grow(output, SvLEN(output) + bufinc) ;
++Sv_Grow(output, SvLEN(output) + bufinc +1) ;
+ cur_length += increment ;
+ s->stream.next_out = (Bytef*) SvPVbyte_nolen(output) + cur_length
;
+ increment = bufinc ;
proposed stable update for perl
Hi release team,
the security team deferred patching CVE-2009-1391 to the stable update.
I'd also like to get a couple of other bugfixes in, debdiff attached.
Please let me know if this is OK by you.
Sorry about the unwrapped debian/control lines; it really is
just s/libcpan-plus-perl/libcpanplus-perl/
Changes:
perl (5.10.0-19lenny2) stable; urgency=low
.
* Fix a typo in the replaces/conflicts/provides: libcpan-plus-perl
should have been libcpanplus-perl. (Closes: #516289)
* Fix a memory leak with the map operator. (Closes: #528332)
* Configure CPANPLUS to use the site directories by default.
(Closes: #533707)
* Save local versions of CPANPLUS::Config::System into /etc/perl.
(See #533707)
.
perl (5.10.0-19lenny1) stable-security; urgency=high
.
* [SECURITY] CVE-2009-1391: Fix a buffer overflow in Compress::Raw::Zlib.
(Closes: #532736)
--
Niko Tyni nt...@debian.org
diff -u perl-5.10.0/pp_ctl.c perl-5.10.0/pp_ctl.c
--- perl-5.10.0/pp_ctl.c
+++ perl-5.10.0/pp_ctl.c
@@ -946,7 +946,7 @@
if (PL_op->op_private & OPpGREP_LEX)
PAD_SVl(PL_op->op_targ) = src;
else
- DEFSV = src;
+ DEFSV_set(src);
PUTBACK;
if (PL_op->op_type == OP_MAPSTART)
@@ -1057,7 +1057,7 @@
if (PL_op->op_private & OPpGREP_LEX)
PAD_SVl(PL_op->op_targ) = src;
else
- DEFSV = src;
+ DEFSV_set(src);
RETURNOP(cLOGOP->op_other);
}
@@ -4663,7 +4663,7 @@
SAVETMPS;
EXTEND(SP, 2);
- DEFSV = upstream;
+ DEFSV_set(upstream);
PUSHMARK(SP);
PUSHs(sv_2mortal(newSViv(0)));
if (filter_state) {
diff -u perl-5.10.0/pp_hot.c perl-5.10.0/pp_hot.c
--- perl-5.10.0/pp_hot.c
+++ perl-5.10.0/pp_hot.c
@@ -2398,7 +2398,7 @@
if (PL_op->op_private & OPpGREP_LEX)
PAD_SVl(PL_op->op_targ) = src;
else
- DEFSV = src;
+ DEFSV_set(src);
RETURNOP(cLOGOP->op_other);
}
diff -u perl-5.10.0/patches-applied perl-5.10.0/patches-applied
--- perl-5.10.0/patches-applied
+++ perl-5.10.0/patches-applied
@@ -38,6 +38,8 @@
debian/patches/37_fix_coredump_indicator
debian/patches/38_fix_weaken_memleak
debian/patches/39_fix_archive_tar_symlink_unpack
+debian/patches/40_compress_raw_zlib_cve_2009_1391
+debian/patches/41_map_memleak.diff
debian/patches/50_debian_use_gdbm
debian/patches/51_debian_ld_run_path
debian/patches/52_debian_extutils_hacks
@@ -64,0 +67,2 @@
+debian/patches/74_debian_cpanplus_config_path
+debian/patches/75_debian_cpanplus_definstalldirs
diff -u perl-5.10.0/perl.h perl-5.10.0/perl.h
--- perl-5.10.0/perl.h
+++ perl-5.10.0/perl.h
@@ -1292,8 +1292,12 @@
#endif
#define ERRSV GvSV(PL_errgv)
-/* FIXME? Change the assignments to PL_defgv to instantiate GvSV? */
-#define DEFSV GvSVn(PL_defgv)
+#ifdef PERL_CORE
+# define DEFSV (0 + GvSVn(PL_defgv))
+#else
+# define DEFSV GvSVn(PL_defgv)
+#endif
+#define DEFSV_set(sv) (GvSV(PL_defgv) = (sv))
#define SAVE_DEFSV SAVESPTR(GvSV(PL_defgv))
#define ERRHV GvHV(PL_errgv) /* XXX unused, here for compatibility */
diff -u perl-5.10.0/debian/control perl-5.10.0/debian/control
--- perl-5.10.0/debian/control
+++ perl-5.10.0/debian/control
@@ -69,9 +69,9 @@
Priority: standard
Architecture: all
Depends: perl (>= ${Upstream-Version}-1)
-Conflicts: libpod-parser-perl (<< 1.32-1), libansicolor-perl (<< 1.10-1),
libfile-temp-perl (<< 0.18), libnet-perl (<= 1:1.19-3),
libattribute-handlers-perl (<< 0.78.02-1), libcgi-pm-perl (<< 3.15-1),
libi18n-langtags-perl (<< 0.35-1), liblocale-maketext-perl (<< 1.08-1),
libmath-bigint-perl (<< 1.77-1), libnet-ping-perl (<< 2.31-1),
libtest-harness-perl (<< 2.56-1), libtest-simple-perl (<< 0.62-1),
liblocale-codes-perl (<< 2.06.1-1), libmodule-corelist-perl (<< 2.13-1),
libio-zlib-perl (<< 1.07-1), libarchive-tar-perl (<= 1.38-2),
libextutils-cbuilder-perl (<< 0.21-1), libmodule-build-perl (<< 0.2808.1-1),
libmodule-load-perl (<< 0.12-1), liblocale-maketext-simple-perl (<< 0.18-1),
libparams-check-perl (<< 0.26-1), libmodule-pluggable-perl (<< 3.6-1),
libmodule-load-conditional-perl (<< 0.22-1), libcpan-plus-perl (<< 0.83.09-1),
libversion-perl (<< 1:0.7400-2), libpod-simple-perl (<< 3.05-2),
libextutils-parsexs-perl (<= 2.18), podlators-perl (<< 2.2.0)
-Replaces: libpod-parser-perl, libansicolor-perl, libfile-temp-perl,
libnet-perl, libattribute-handlers-perl, libcgi-pm-perl, libi18n-langtags-perl,
liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl,
libtest-harness-perl, libtest-simple-perl, liblocale-codes-perl,
libmodule-corelist-perl, libio-zlib-perl, libarchive-tar-perl,
libextutils-cbuilder-perl, libmodule-build-perl, libmodule-load-perl,
liblocale-maketext-simple-perl, libparams-check-perl, libmodule-pluggable-perl,
libmodule-load-conditional-perl, libcpan-plus-perl, libversion-perl,
libpod-simple-perl, libextutils-parsexs-perl, podlators-perl
-Provides: libpod-parser-perl, libansicolor-perl, libfil
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, 2009-08-26 at 16:10 -0400, Noah Meyerhans wrote: > On Wed, Aug 26, 2009 at 08:40:17PM +0100, Adam D. Barratt wrote: > > > > fwiw, the open-whois change is one I'd definitely be happy to accept. > > > > > > I'm preparing that upload now. Is it OK to use the same version number > > > as the one that was rejected? > > > > You can, although if you are then you'll need to leave it until after > > it's moved from the "pending" section of > > http://release.debian.org/proposed-updates/stable.html to the lower > > "processed" section to make sure that the previous package has been > > rejected by dak. > > Attached is a proposed debdiff. I included the pod2man fixes because > they're easy, don't affect functionality, and the manpages are ugly > without them. Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, Aug 26, 2009 at 08:40:17PM +0100, Adam D. Barratt wrote: > > > fwiw, the open-whois change is one I'd definitely be happy to accept. > > > > I'm preparing that upload now. Is it OK to use the same version number > > as the one that was rejected? > > You can, although if you are then you'll need to leave it until after > it's moved from the "pending" section of > http://release.debian.org/proposed-updates/stable.html to the lower > "processed" section to make sure that the previous package has been > rejected by dak. Attached is a proposed debdiff. I included the pod2man fixes because they're easy, don't affect functionality, and the manpages are ugly without them. Thanks. noah diff -u spamassassin-3.2.5/debian/changelog spamassassin-3.2.5/debian/changelog --- spamassassin-3.2.5/debian/changelog +++ spamassassin-3.2.5/debian/changelog @@ -1,3 +1,13 @@ +spamassassin (3.2.5-2+lenny1) stable; urgency=low + + * Remove open-whois.org as it is cybersquatted (Closes: #537477) + * Fix numerous perl pod errors that caused warnings to be embedded +in several manpages. + * Fix man page formatting so as not to break whatis. + * Update debian/control to list the right Maintainer value. + + -- Noah Meyerhans Wed, 26 Aug 2009 15:45:35 -0400 + spamassassin (3.2.5-2) unstable; urgency=low [ Duncan Findlay ] diff -u spamassassin-3.2.5/debian/control spamassassin-3.2.5/debian/control --- spamassassin-3.2.5/debian/control +++ spamassassin-3.2.5/debian/control @@ -1,8 +1,8 @@ Source: spamassassin Section: mail Priority: optional -Maintainer: Duncan Findlay -Uploaders: Jesus Climent , Noah Meyerhans +Maintainer: Noah Meyerhans +Uploaders: Jesus Climent Build-Depends: debhelper (>= 4.1.16), perl (>= 5.6.0-16), libssl-dev, dpatch, libhtml-parser-perl (>= 3.24), libdigest-sha1-perl, libnet-dns-perl (>= 0.34) diff -u spamassassin-3.2.5/debian/patches/00list spamassassin-3.2.5/debian/patches/00list --- spamassassin-3.2.5/debian/patches/00list +++ spamassassin-3.2.5/debian/patches/00list @@ -4 +4,5 @@ -40_remote_dsbl.dpatch +40_remote_dsbl +41_remove_openwhois +60_fix-pod +70_fix-whatis +80_fix_man_warnings only in patch2: unchanged: --- spamassassin-3.2.5.orig/debian/patches/70_fix-whatis.dpatch +++ spamassassin-3.2.5/debian/patches/70_fix-whatis.dpatch @@ -0,0 +1,95 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 70_fix-whatis.dpatch by +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: Fix lintian's complaints about bad whatis lines + +...@dpatch@ +diff -urNad spamassassin-3.2.5~/lib/Mail/SpamAssassin/Plugin/Check.pm spamassassin-3.2.5/lib/Mail/SpamAssassin/Plugin/Check.pm +--- spamassassin-3.2.5~/lib/Mail/SpamAssassin/Plugin/Check.pm 2009-08-09 16:35:07.0 -0400 spamassassin-3.2.5/lib/Mail/SpamAssassin/Plugin/Check.pm 2009-08-09 16:37:04.0 -0400 +@@ -1,6 +1,6 @@ + =head1 NAME + +-Mail::SpamAssassin::Plugin::Check ++Mail::SpamAssassin::Plugin::Check - spamassassin message checking plugin + + =head1 SYNOPSIS + +diff -urNad spamassassin-3.2.5~/lib/Mail/SpamAssassin/Plugin/OneLineBodyRuleType.pm spamassassin-3.2.5/lib/Mail/SpamAssassin/Plugin/OneLineBodyRuleType.pm +--- spamassassin-3.2.5~/lib/Mail/SpamAssassin/Plugin/OneLineBodyRuleType.pm 2009-08-09 16:35:07.0 -0400 spamassassin-3.2.5/lib/Mail/SpamAssassin/Plugin/OneLineBodyRuleType.pm 2009-08-09 16:37:04.0 -0400 +@@ -1,6 +1,6 @@ + =head1 NAME + +-Mail::SpamAssassin::Plugin::OneLineBodyRuleType ++Mail::SpamAssassin::Plugin::OneLineBodyRuleType - spamassassin body test plugin + + =cut + +diff -urNad spamassassin-3.2.5~/lib/Mail/SpamAssassin/Plugin/VBounce.pm spamassassin-3.2.5/lib/Mail/SpamAssassin/Plugin/VBounce.pm +--- spamassassin-3.2.5~/lib/Mail/SpamAssassin/Plugin/VBounce.pm 2009-08-09 16:35:07.0 -0400 spamassassin-3.2.5/lib/Mail/SpamAssassin/Plugin/VBounce.pm 2009-08-09 16:37:04.0 -0400 +@@ -17,7 +17,7 @@ + + =head1 NAME + +-Mail::SpamAssassin::Plugin::VBounce ++Mail::SpamAssassin::Plugin::VBounce - spamassassin bounce classification plugin + + =head1 SYNOPSIS + +diff -urNad spamassassin-3.2.5~/lib/Mail/SpamAssassin/Util/DependencyInfo.pm spamassassin-3.2.5/lib/Mail/SpamAssassin/Util/DependencyInfo.pm +--- spamassassin-3.2.5~/lib/Mail/SpamAssassin/Util/DependencyInfo.pm 2009-08-09 16:37:04.0 -0400 spamassassin-3.2.5/lib/Mail/SpamAssassin/Util/DependencyInfo.pm 2009-08-09 16:37:22.0 -0400 +@@ -17,6 +17,16 @@ + # limitations under the License. + # + ++=head1 NAME ++ ++Mail::SpamAssassin::Util::DependencyInfo - spamassassin debugging helpers ++ ++=head1 SYNOPSIS ++ ++ loadplugin Mail::SpamAssassin::Util::DependencyInfo ++ ++=cut ++ + package Mail::SpamAssassin::Util::DependencyInfo; + + use strict; +@@ -208,6 +218,8 @@ + + ### + ++=head1 METHODS ++ + =over 4 + + =item $f->debug_diagnostics () +diff -
Re: Security update for ‘burn’ package
On Wed, 2009-08-26 at 10:21 +1000, Ben Finney wrote: > "Adam D. Barratt" writes: > > > On Sun, 2009-08-23 at 15:57 +1000, Ben Finney wrote: > > In either case, the answer is yes - uploads to any Debian archive must > > be signed by a key in the Debian keyring. > > Okay. So I should seek a sponsor in the ‘debian-mentors’ forum for the > update into ‘stable’? Or should that be done here on the > ‘debian-release’ forum? For any stable upload which requires sponsorship, you should look for that wherever you would for any other upload, be that debian-mentors or elsewhere. > > One quick query about the debdiff; apologies if I'm missing something, > > but this hunk looks like a functionality change, rather than a strict > > replacement: > > > > +- if path_excluded: > > +- iso.mkisofs_line_append(path_excluded + ' ') > > ++ for path_excluded in paths_excluded: > > ++ iso.mkisofs_args.extend(["-x", path_excluded]) > > Thanks for asking. This change is necessary to go from invoking a shell > with a single command-line string, to invoking a list of command-line > arguments to be executed directly. [...] > This is a backport of the same approach from the version in ‘unstable’. Ah, yes, I missed that on my first skim through the diff due to the horrible indent level. :-/ Looking through the diff again, there are a lot of changes which don't appear to be required and make the diff harder to review; one of the principles of stable updates is that diffs should be minimal wherever possible. Please could you prepare and send an updated diff which does not include the removal of old commented out code and the removal of functions from "import" lines where the code is no longer used? In general, code tidy-up is obviously a good thing, but it's not really appropriate for a stable update. The change to burn-configure should definitely not be included, as it only contains tidy-ups. Apologies for not having spotted / mentioned that earlier. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, 2009-08-26 at 15:13 -0400, Noah Meyerhans wrote: > On Wed, Aug 26, 2009 at 08:11:08PM +0100, Adam D. Barratt wrote: > > > Feel free to reject these packages, though; they're definitely not what > > > I *intended* to upload. > > > > Okay; I've done so, so they'll disappear from p-u-new at the next > > dinstall. > > > > fwiw, the open-whois change is one I'd definitely be happy to accept. > > I'm preparing that upload now. Is it OK to use the same version number > as the one that was rejected? You can, although if you are then you'll need to leave it until after it's moved from the "pending" section of http://release.debian.org/proposed-updates/stable.html to the lower "processed" section to make sure that the previous package has been rejected by dak. Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, Aug 26, 2009 at 08:11:08PM +0100, Adam D. Barratt wrote: > > Feel free to reject these packages, though; they're definitely not what > > I *intended* to upload. > > Okay; I've done so, so they'll disappear from p-u-new at the next > dinstall. > > fwiw, the open-whois change is one I'd definitely be happy to accept. I'm preparing that upload now. Is it OK to use the same version number as the one that was rejected? noah signature.asc Description: Digital signature
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, 2009-08-26 at 14:32 -0400, Noah Meyerhans wrote: > On Wed, Aug 26, 2009 at 07:22:47PM +0100, Adam D. Barratt wrote: > > There are also a few other changes which weren't mentioned in the > > changelog or your mail, at least the first of which looks unintentional. > > The others are relatively minor, but I wasn't sure if they were intended > > to form part of the update, as they weren't mentioned. > > I curse "svn merge" :-) > Feel free to reject these packages, though; they're definitely not what > I *intended* to upload. Okay; I've done so, so they'll disappear from p-u-new at the next dinstall. fwiw, the open-whois change is one I'd definitely be happy to accept. Cheers, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Stable update for python-support
On Wed, 2009-08-26 at 20:24 +0200, Josselin Mouette wrote: > Le mercredi 26 août 2009 à 19:18 +0100, Adam D. Barratt a écrit : > > Ah, I see by "prepared" you meant "uploaded". :-) > > > > In future, it would be good if you could post a debdiff to -release and > > wait for confirmation before uploading Just In Case[tm]. > > Is it really a problem for you? I mean, if you choose to reject it, I > have no problem uploading it again. > > If it causes trouble to do this without the confirmation mail, I’ll > stop, of course, but it looked harmless. It's not a huge problem for small updates, and I'm certainly not going to not accept it because you didn't ask first. As a general rule though, not having to reject stuff makes me a happier RA. :-) Letting us know that you've uploaded and what/why (as you did) is definitely better than simply uploading and waiting for someone to notice though. Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
FSF Guidelines for Free System Distributions (was: Release goal for Squeeze)
(The ‘debian-release’ forum is for coordination of the release of Debian. This discussion about release goals should better take place on the ‘debian-devel’ forum.) Praveen P writes: > I would like to see squeeze released 100% free at par with "Guidelines > for Free System Distributions" by FSF. I assume you're referring to the guidelines documented here http://www.gnu.org/philosophy/free-system-distribution-guidelines.html>. In your assessment, what specific, measurable goals would the Debian project need to set in addition to those already announced for Squeeze http://lists.debian.org/debian-announce/2009/msg00010.html>? > I am using gnewsense also. It is very difficult to get quality free > softwares to replace the proprietary ones now. Note that, unlike the FSF, the Debian project does not distinguish between programs and non-programs for free software; per our Social Contract, all software works in Debian need to meet the Debian Free Software Guidelines regardless of how their bits might be interpreted. This is in contrast to the FSF “Guidelines for Free System Distributions” which makes special mention for different freedoms for each of programs, documentation, and “non-functional data”, without guidelines for works that may defy pre-hoc classification or straddle those boundaries. Do you see these differing standards of freedom being in conflict? How would you suggest they be resolved? > The condition will go worse with the advancement of time. So this is > my request and suggestion for debian developers. You're welcome to suggest specific, measurable release goals. As it stands, your suggestion doesn't give much to aim for more than what the Debian project is already committed to for Squeeze. -- \ “Nature hath given men one tongue but two ears, that we may | `\ hear from others twice as much as we speak.” —Epictetus, | _o__) _Fragments_ | Ben Finney -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Stable update for python-support
On Wed, 2009-08-26 at 19:03 +0100, Adam D. Barratt wrote: > On Wed, 2009-08-26 at 15:48 +0200, Josselin Mouette wrote: > > I have prepared a python-support update targeted at the next lenny point > > release. > > > >* update-python-modules (create_dotpath): > > + Completely ignore lines starting with "import", as they would be > >executed by python upon startup. > > > > It is just a backport of this change which was made for 0.8.6, which > > fixes a very annoying bug triggered by some packages using some > > completely brain-dead functionality of .pth files. > > Please go ahead. Ah, I see by "prepared" you meant "uploaded". :-) In future, it would be good if you could post a debdiff to -release and wait for confirmation before uploading Just In Case[tm]. Thanks, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, Aug 26, 2009 at 07:22:47PM +0100, Adam D. Barratt wrote: > In future, it would be good if you could post debdiffs to -release and > wait for confirmation /before/ uploading. :-) OK > >* Remove open-whois.org as it is cybersquatted (Closes: #537477) > >* Backport IPv6 support for the Received header parser (Closes: #510711) > >* Correct the Maintainer field. > >* Fix numerous pod2man errors that caused warning messages to be > > embedded within several man pages. > > There are also a few other changes which weren't mentioned in the > changelog or your mail, at least the first of which looks unintentional. > The others are relatively minor, but I wasn't sure if they were intended > to form part of the update, as they weren't mentioned. I curse "svn merge" > - The documentation fix for spamhaus and SURBL not being free for all > has been reverted, as has the corresponding changelog entry from 3.2.5-2 > (and the changelog trailer for that version changed). > > - The perl-modules dependency has grown a "| libio-zlib-perl (>= 1.04)" > alternative. > > - GPG.KEY is no longer not compressed > > - sa-update is no longer run with an explicit umask by the cron job These all came from unstable. The libio-zlib-perl makes life easier for backporting this package to etch, and is the only one that I actually *meant* to include. The rest I blame on svn. > > The IPv6 header support is the only change to actual functionality. It > > fixes the problem where the config parser was unable to handle IPv6 > > addresses in config directives like "trusted_networks". Given that one > > of lenny's release goals was pervasive IPv6 support, I felt that this > > was worth fixing. Aside from myself, at least one other person is > > currently using packages including this patch on a busy mail site, and > > they work as expected. It is worth noting, though, that this change > > introduced a new dependency on libnetaddr-ip-perl. > > Personally, the patch is a little larger than I'd currently be happy > accepting for a stable update (at least for a non-security / RC fix). I > realise the changes are all in unstable, although only for a couple of > weeks. Yeah, I wasn't sure whether it'd be accepted or not. The change doesn't have any functional effect at all if you haven't configured any IPv6 addresses in trusted_networks, etc, so I believe them to be safe. Feel free to reject these packages, though; they're definitely not what I *intended* to upload. > I'd definitely suggest a lenny-backports upload including the changes > though. That's pretty much a given. SpamAssassin in bpo stays pretty well in sync with what's in testing. noah signature.asc Description: Digital signature
Re: [SRM] wordpress update for lenny
On Tue, 2009-08-25 at 12:58 +0200, Giuseppe Iuculano wrote: > I'd like to fix an annoying bug (#519798) in the wordpress password reset > procedure in lenny. > debdiff attached. Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Stable upload for avelsieve
On Tue, 2009-08-25 at 11:37 +0200, Jan wrote: > I would like to see an upload of avelsieve accepted to stable-p-u. A few > weeks before the stable release I fixed an important bug for dovecot > users using the sieve capabilities via avelsieve. Unfortunately I lost > track of that with an upload of a new upstream version which didn't make > it into lenny. > > There are two different patches, one for a small bug which makes > deleting the last sieve rule impossible, and another one for proper use > with dovecot-imap. A user just asked to include these patches in lenny > by filing a grave bug. I don't consider this issue as grave but it at > least shows the impact of the missing patches for dovecot users. Please go ahead. On a side note, if you as the maintainer don't consider the bug to be grave, it shouldn't be marked as such... Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Stable update for python-support
Le mercredi 26 août 2009 à 19:18 +0100, Adam D. Barratt a écrit : > Ah, I see by "prepared" you meant "uploaded". :-) > > In future, it would be good if you could post a debdiff to -release and > wait for confirmation before uploading Just In Case[tm]. Is it really a problem for you? I mean, if you choose to reject it, I have no problem uploading it again. If it causes trouble to do this without the confirmation mail, I’ll stop, of course, but it looked harmless. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: [SRM] spamassassin 3.2.5-2+lenny1
On Wed, 2009-08-26 at 09:24 -0400, Noah Meyerhans wrote: > Hello. I just uploaded a new set of spamassassin packages for > consideration for the upcoming stable point release. The changelog > entry is: In future, it would be good if you could post debdiffs to -release and wait for confirmation /before/ uploading. :-) >* Remove open-whois.org as it is cybersquatted (Closes: #537477) >* Backport IPv6 support for the Received header parser (Closes: #510711) >* Correct the Maintainer field. >* Fix numerous pod2man errors that caused warning messages to be > embedded within several man pages. There are also a few other changes which weren't mentioned in the changelog or your mail, at least the first of which looks unintentional. The others are relatively minor, but I wasn't sure if they were intended to form part of the update, as they weren't mentioned. - The documentation fix for spamhaus and SURBL not being free for all has been reverted, as has the corresponding changelog entry from 3.2.5-2 (and the changelog trailer for that version changed). - The perl-modules dependency has grown a "| libio-zlib-perl (>= 1.04)" alternative. - GPG.KEY is no longer not compressed - sa-update is no longer run with an explicit umask by the cron job > The IPv6 header support is the only change to actual functionality. It > fixes the problem where the config parser was unable to handle IPv6 > addresses in config directives like "trusted_networks". Given that one > of lenny's release goals was pervasive IPv6 support, I felt that this > was worth fixing. Aside from myself, at least one other person is > currently using packages including this patch on a busy mail site, and > they work as expected. It is worth noting, though, that this change > introduced a new dependency on libnetaddr-ip-perl. Personally, the patch is a little larger than I'd currently be happy accepting for a stable update (at least for a non-security / RC fix). I realise the changes are all in unstable, although only for a couple of weeks. I'd definitely suggest a lenny-backports upload including the changes though. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Stable update for python-support
On Wed, 2009-08-26 at 15:48 +0200, Josselin Mouette wrote: > I have prepared a python-support update targeted at the next lenny point > release. > >* update-python-modules (create_dotpath): > + Completely ignore lines starting with "import", as they would be >executed by python upon startup. > > It is just a backport of this change which was made for 0.8.6, which > fixes a very annoying bug triggered by some packages using some > completely brain-dead functionality of .pth files. Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Pidgin SSL issue - proposed-updates
On Wed, 2009-08-26 at 10:34 -0400, Ari Pollak wrote: > Philipp Kern wrote: > > On Mon, Aug 24, 2009 at 09:26:46AM -0400, Ari Pollak wrote: > >> Bug #542891 covers a security bug that will probably be getting a CVE > >> number and affects all supported versions of Debian, but the security > >> team indicated that it isn't important enough to warrant a DSA. So I was > >> planning on uploading an update to lenny and etch with the fix. > > > > That's ok. It would be cool however if you could post debdiffs for > > both before you upload them to proposed-updates. > > Here's the diff for lenny. Apparently etch isn't affected by this bug > since it never claimed to require SSL/TLS, so I won't be updating that. Please go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Release goal for Squeeze
[Praveen P] > I would like to see squeeze released 100% free at par with > "Guidelines for Free System Distributions" by FSF. I am using > gnewsense also. It is very difficult to get quality free softwares > to replace the proprietary ones now. The condition will go worse > with the advancement of time. So this is my request and suggestion > for debian developers. What exactly would have to change to make this happen? Your request is rather vague to me, and I wonder how much work is involved and the consequences of the change you propose. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
Josselin Mouette wrote: > Le mercredi 26 août 2009 à 10:14 +0200, Tshepang Lekhonkhobe a écrit : >> I saw recently that RT did not list 2.6 as default Python as a release >> goal. I also saw a thread talking about the problems related to 2.6. >> Does this mean Squeeze won't use it by default or are u guys working >> on it? > > In the current state of affairs and given the plans of the Python > maintainers, there will be likely no python2.6 (even as non-default) in > squeeze. What specific technical issue(s) are in your opinion so unlikely to get solved soon? Is there any unreasonable plan of the Python maintainers in your opinion? Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team: Release goals, schedule, state of the union
On Wed, Aug 26, 2009 at 08:23:09AM +0200, Marc 'HE' Brockschmidt wrote:
> Steffen Joeris writes:
> > On Wed, 26 Aug 2009 06:51:48 am Marc 'HE' Brockschmidt wrote:
> >> Release Goals
> >> =
> [...]
> >> - kFreeBSD:
> >> Debian 6.0 Squeeze should be the first Debian release shipping with
> >> a non-Linux kernel.
> > Out of curiosity, how is security support working for this and who is
> > providing it?
>
> We [1] were hoping that kfreebsd-{i386,amd64} would be handled like i386
> and amd64 and be supported by the security team.
>
> As we know that the security team's manpower is limited, we acknowledge
> this by asking you for any concers in supporting a architecture. For the
> Squeeze cycle, this hasn't been done yet [2], as we haven't decided yet
> which of the old architectures can't be supported from a release team
> point of view.
>
> Including kFreeBSD architectures in the release has been in discussion
> for some time now, and we didn't see any official security team position
> on this yet, thus assumed there were no (big) concers. Should you have
> see some, please inform us soon.
The scope of security support for FreeBSD is different than for Linux:
FreeBSD doesn't treat local denial of service issues as security issues,
but rather as regular bugs (which is fine for > 90% of all systems).
I don't think we can do anything about this, so this needs to be documented
in release notes.
Other than that I don't see a problem. Security issues in the FreeBSD
kernel are infrequent. Testing can be a problem, so we need someone from
the kfreebsd porters to build and test the update for us. Since Aurelien
has been doing that for the existing - unsupported - packages in Lenny
already (in the form of stable-proposed-updates), everything should be
fine if he continues to do so.
Also we should aim at only supporting one kernel for FreeBSD in the Squeeze
release. (I don't know the current state, but IIRC there were multiple
kfreebsd kernel packages in the past).
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
On Wed, Aug 26, 2009 at 09:20:51PM +1000, Ben Finney wrote: > I'm confident that, if the right coordination of effort and publicity of > the necessary to-do tasks were applied, there would be ample willingness > From Debian members who want Python 2.6 in Debian Squeeze. It would indeed be nice if someone could list the hurdles that stand between us and Python 2.6 in Squeeze, or point us to the web page that lists them. Python2.6 is in experimental: http://packages.debian.org/source/experimental/python2.6 Python2.6 is in Ubuntu jaunty: https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028266.html Has anything changed since: http://lists.debian.org/debian-python/2009/03/msg00091.html and: http://lists.debian.org/debian-python/2009/08/msg3.html ? I read the list and can search the archives, but have not found a list of tasks that need doing to get 2.6 in squeeze. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Pidgin SSL issue - proposed-updates
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Philipp Kern wrote:
> On Mon, Aug 24, 2009 at 09:26:46AM -0400, Ari Pollak wrote:
>> Bug #542891 covers a security bug that will probably be getting a CVE
>> number and affects all supported versions of Debian, but the security
>> team indicated that it isn't important enough to warrant a DSA. So I was
>> planning on uploading an update to lenny and etch with the fix.
>
> That's ok. It would be cool however if you could post debdiffs for
> both before you upload them to proposed-updates.
Here's the diff for lenny. Apparently etch isn't affected by this bug
since it never claimed to require SSL/TLS, so I won't be updating that.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREDAAYFAkqVR6AACgkQwO+u47cOQDsQ7QCgiy/BtpNOr4bXuWycFlLqcgR1
3KUAnAlNnRmEyisdwECAfyL3X3ozaKNX
=gyK9
-END PGP SIGNATURE-
diff -Nru pidgin-2.4.3/debian/changelog pidgin-2.4.3/debian/changelog
--- pidgin-2.4.3/debian/changelog 2009-08-26 14:31:07.0 +
+++ pidgin-2.4.3/debian/changelog 2009-08-26 14:31:08.0 +
@@ -1,3 +1,11 @@
+pidgin (2.4.3-4lenny4) stable; urgency=medium
+
+ * debian/patches/35_xmpp-require-ssl.patch:
+- Fix XMPP not properly enforcing "Require SSL/TLS" on some older
+ servers (Closes: #542891)
+
+ -- Ari Pollak Tue, 25 Aug 2009 09:53:14 -0400
+
pidgin (2.4.3-4lenny3) stable-security; urgency=low
* debian/patches/33_ssl-nss-self-signed-crash.patch:
diff -Nru pidgin-2.4.3/debian/patches/35_xmpp-require-ssl.patch
pidgin-2.4.3/debian/patches/35_xmpp-require-ssl.patch
--- pidgin-2.4.3/debian/patches/35_xmpp-require-ssl.patch 1970-01-01
00:00:00.0 +
+++ pidgin-2.4.3/debian/patches/35_xmpp-require-ssl.patch 2009-08-26
14:31:08.0 +
@@ -0,0 +1,28 @@
+#
+#
+# patch "libpurple/protocols/jabber/auth.c"
+# from [c6da33813f947a747b08aec752db34db121516fd]
+#to [4846e5134fd09bde6ad21cd0b75b64693e90e5ea]
+#
+
+--- libpurple/protocols/jabber/auth.c c6da33813f947a747b08aec752db34db121516fd
libpurple/protocols/jabber/auth.c 4846e5134fd09bde6ad21cd0b75b64693e90e5ea
+@@ -689,6 +689,18 @@ void jabber_auth_start_old(JabberStream
+ JabberIq *iq;
+ xmlnode *query, *username;
+
++ /* We can end up here without encryption if the server doesn't support
++ * and we're not using old-style SSL. If the user
++ * is requiring SSL/TLS, we need to enforce it.
++ */
++ if (js->gsc == NULL &&
++
purple_account_get_bool(purple_connection_get_account(js->gc), "require_tls",
FALSE)) {
++ purple_connection_error_reason (js->gc,
++ PURPLE_CONNECTION_ERROR_ENCRYPTION_ERROR,
++ _("You require encryption, but it is not available on
this server."));
++ return;
++ }
++
+ #ifdef HAVE_CYRUS_SASL
+ /* If we have Cyrus SASL, then passwords will have been set
+* to OPTIONAL for this protocol. So, we need to do our own
pidgin_2.4.3-4lenny4.debdiff.sig
Description: Binary data
Stable update for python-support
Hi,
I have prepared a python-support update targeted at the next lenny point
release.
* update-python-modules (create_dotpath):
+ Completely ignore lines starting with "import", as they would be
executed by python upon startup.
It is just a backport of this change which was made for 0.8.6, which
fixes a very annoying bug triggered by some packages using some
completely brain-dead functionality of .pth files.
--- deb-maint/python-support/trunk/update-python-modules2009/05/05
17:04:53 12975
+++ deb-maint/python-support/trunk/update-python-modules2009/05/05
17:05:11 12976
@@ -186,6 +186,9 @@
if f.endswith(".pth") and os.path.isfile(f):
for l in file(f):
l=l.rstrip('\n')
+if l.startswith('import'):
+ # Do not ship lines starting with "import", they are executed!
(complete WTF)
+ continue
pathlist.append(l)
l2=os.path.join(path,l)
pathlist.append(l2)
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
signature.asc
Description: Ceci est une partie de message numériquement signée
[SRM] spamassassin 3.2.5-2+lenny1
Hello. I just uploaded a new set of spamassassin packages for consideration for the upcoming stable point release. The changelog entry is: * Remove open-whois.org as it is cybersquatted (Closes: #537477) * Backport IPv6 support for the Received header parser (Closes: #510711) * Correct the Maintainer field. * Fix numerous pod2man errors that caused warning messages to be embedded within several man pages. The IPv6 header support is the only change to actual functionality. It fixes the problem where the config parser was unable to handle IPv6 addresses in config directives like "trusted_networks". Given that one of lenny's release goals was pervasive IPv6 support, I felt that this was worth fixing. Aside from myself, at least one other person is currently using packages including this patch on a busy mail site, and they work as expected. It is worth noting, though, that this change introduced a new dependency on libnetaddr-ip-perl. noah signature.asc Description: Digital signature
Re: Bits from the release team: Release goals, schedule, state of the union
On Wed, 26 Aug 2009, Goswin von Brederlow wrote: > Is that actualy a release goal for squeeze? Yes, that's the release goal because it requires work on many packages. There's no point in having a release goal stating "wait until ftpmasters apply buxy's patch to allow 3.0 source packages". > Since blindly changing dpkg-source to use 3.0 format breaks packages > maybe a better change would be to make a missing debian/source/format > first a warning and then an error. But maybe that is just me. Many transition scenario are possible, I chosed one that makes most sense to me. It's not going to be disruptive if we take the time to prepare for the switch. This is what this release goal is about. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
Josselin Mouette writes: > Le mercredi 26 août 2009 à 10:14 +0200, Tshepang Lekhonkhobe a écrit : > > I saw recently that RT did not list 2.6 as default Python as a > > release goal. I also saw a thread talking about the problems related > > to 2.6. Does this mean Squeeze won't use it by default or are u guys > > working on it? > > In the current state of affairs and given the plans of the Python > maintainers By this, do you mean “the plans of the maintainers of the Debian maintainers of Python”, or “the plans of the upstream maintainers of Python”? > there will be likely no python2.6 (even as non-default) in squeeze. Can this situation be improved by input from enthustic volunteers, even those without specific skills in the Debian package of Python? I'm confident that, if the right coordination of effort and publicity of the necessary to-do tasks were applied, there would be ample willingness From Debian members who want Python 2.6 in Debian Squeeze. -- \ “A new swimming pool is rapidly taking shape since the | `\contractors have thrown in the bulk of their workers.” | _o__) newspaper article, east Africa | Ben Finney pgpshMPn25uue.pgp Description: PGP signature
Re: Bits from the release team: Release goals, schedule, state of the union
Raphael Hertzog writes: > On Wed, 26 Aug 2009, Matthijs Kooijman wrote: >> Or is the second step in this release goal of actually using the new source >> format for all (or at least a lot?) packages? > > Yes. I'd like to achieve this by changing dpkg-source to build 3.0 (quilt) > or 3.0 (native) source packages by default (generating a source package > using the old format would then require putting "1.0" in > debian/source/format). > > Cheers, > -- > Raphaël Hertzog Is that actualy a release goal for squeeze? If so then I would prefer if that where stated specifically and seperately to the goal of allowing 3.0 source packages at all. Allowing 3.0 format is long overdue imho and from what has been told just needs patches to be applied to DAK to b completed. Changing packages I believe will happen naturally after that and I would rather see a gradual adoption of the new format than brute forcing maintainer to change their packages before squeeze. The new format has enough advantages to stand on its own. Change dh_make and other package creating helpers so new packages default to 3.0 (quilt). Since blindly changing dpkg-source to use 3.0 format breaks packages maybe a better change would be to make a missing debian/source/format first a warning and then an error. But maybe that is just me. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: KDE plans for the squeeze cycle
Hi Marc et all, I will answer including also Qt 4 plans, that as you know is a quite important part of KDE 4 :) > * Which major upstream releases of KDE are expected in the next two > years? Which of those are material for Debian stable, which might be a bit > flaky? About KDE -- We currently have KDE 4.3.0 in unstable. KDE 4.4 is expected about January 2010. KDE 4.5 is expected about July 2010. It is not a good idea to do more speculation about dates after this point because in KDE they are also testing new release management methods. About flaky releases, usually 0 point releases have some bugs and any further point releases are highly preferred to ship in a Debian stable release. In case of freezing with a .0 (or .1) release, we would like to be given the possibility of upload the next point releases given that point releases have so far contained fewer regressions than actual bug fixes. Having a .2 or .3 point release would be the ideal. We would like to mention that neither of us expected to release with KDE 4.3.X and we didn't give (nor will give now being late to the party) to it as much care as it probably needed to. About Qt - We currently have Qt 4.5.2 in the archive and the development and expectations are on Qt 4.6. This release is expected about the end of this year or worse case, very early 2010. Qt 4.6 will deliver an important set of new features (animation API, state machine framework), and important updates (graphics view, webkit, qtscript) [0]. Leaving 4.6 outside of the next stable, would put Squeeze in an unsupported status of new Qt software for its entire life span. It is also worth mentioning Qt 4.5.x doesn't support GCC 4.4 (and won't), Qt 4.6 will do. As with KDE the best is always shipping with a point release and Qt 4.6.1 is our minimal target. > * How much time do you usually need from a new upstream release of KDE > to a stable Debian package in unstable? KDE releases the tarballs to packagers one week before release, so packagers have time to prepare the packaging. We usually get something ready (with the 4.x releases) for release day, sometimes with some bugs, sometimes not. These bugs are usually weeded out during a week or two after this. For point releases, which is only bug fix releases, we usually get the packaging fully right at first upload, which happens around release day. > * How many "big" transitions will the upcoming changes cause? When should > those > happen? Can we do something to make them easier? We already have done most of the complicated stuff when moving from kde 3 to kde 4. We have some stuff we would like to do but nothing too big or "must do" before next release. If we could plan the Debian release cycle completely after what would be good for KDE, squeeze will freeze shortly after KDE 4.5.0 is uploaded to Debian (July 2010) and the 4.5.x point releases would be allowed in. KDE would have the possibility to take advantage of the new things in Qt4.6, and we would reach Qt4.6.2 or something like that on the Qt side. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
Le mercredi 26 août 2009 à 10:14 +0200, Tshepang Lekhonkhobe a écrit : > I saw recently that RT did not list 2.6 as default Python as a release > goal. I also saw a thread talking about the problems related to 2.6. > Does this mean Squeeze won't use it by default or are u guys working > on it? In the current state of affairs and given the plans of the Python maintainers, there will be likely no python2.6 (even as non-default) in squeeze. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bits from the release team: Release goals, schedule, state of the union
On Wed, 26 Aug 2009, Matthijs Kooijman wrote: > Or is the second step in this release goal of actually using the new source > format for all (or at least a lot?) packages? Yes. I'd like to achieve this by changing dpkg-source to build 3.0 (quilt) or 3.0 (native) source packages by default (generating a source package using the old format would then require putting "1.0" in debian/source/format). Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team: Release goals, schedule, state of the union
On Wed, Aug 26, 2009 at 10:21:00AM +0200, Marc 'HE' Brockschmidt wrote: > You missed something: > http://lists.debian.org/debian-devel-announce/2008/04/msg4.html On Wed, Aug 26, 2009 at 10:18:05AM +0200, Raphael Hertzog wrote: > You missed several announces on debian-devel-announce (you are supposed to > be subscribed and reading) and a status update on -devel recently. Ah, thanks. From reading there, and the other pointers you've given, I understand that this release goal is mostly focused on applications that work with source packages (dpkg, apt, svn-buildpackage, etc.), not on changing "regular" packages to (be able to) use the new source formats. I had expected changes to be required in all packages, which is why I didn't remember that particular announcement (I had read it and concluded it did not affect my package). I think the source of my confusion was (and is) caused by use of the phrase "all packages" in the release goal "Have all packages in the archive buildable using the new source package formats.". Perhaps phrasing it as "Having the archive and all package-support tools support the new source package formats" would be better? Or is the second step in this release goal of actually using the new source format for all (or at least a lot?) packages? Thanks for your time! Matthijs signature.asc Description: Digital signature
Re: Bits from the release team: Release goals, schedule, state of the union
Matthijs Kooijman writes: >> - New source package format: >> Make it possible to build all packages using dpkg source format >> 3.0 (quilt). > This seems like something that requires packagers to take some action, or at > least check their packages for this possibility? However, I've never heard > about this new "source format" until now. Did I miss something, You missed something: http://lists.debian.org/debian-devel-announce/2008/04/msg4.html > A quick read of the dpkg-source manpage about the source format 3 didn't > really help my understanding of what would be required to attain this goal. > Could you elaborate a bit? Perhaps in the next update? The documentation for all goals is reachable from the release goal list I referenced in the bits mail [1], in this case you can find more information on http://wiki.debian.org/ReleaseGoals/NewDebFormats There are links to a description of the new format as well as pointers to bugs filed for known problems. Marc Footnotes: [1] http://release.debian.org/squeeze/goals.txt -- BOFH #154: You can tune a file system, but you can't tune a fish (from most tunefs man pages) pgpNnPT0o1LCd.pgp Description: PGP signature
Re: Bits from the release team: Release goals, schedule, state of the union
Hi, On Wed, 26 Aug 2009, Matthijs Kooijman wrote: > > - New source package format: > > Make it possible to build all packages using dpkg source format > > 3.0 (quilt). > This seems like something that requires packagers to take some action, or at > least check their packages for this possibility? However, I've never heard > about this new "source format" until now. Did I miss something, or will there > be separate announcements about this still? You missed several announces on debian-devel-announce (you are supposed to be subscribed and reading) and a status update on -devel recently. Start with http://wiki.debian.org/Projects/DebSrc3.0 to get more information. > A quick read of the dpkg-source manpage about the source format 3 didn't > really help my understanding of what would be required to attain this goal. > Could you elaborate a bit? Perhaps in the next update? Basically fix all those bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hert...@debian.org;tag=3.0-quilt-by-default (And continue to maintain other packages sanely to not expand that list) Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
will 2.6 be default?
Hi, I saw recently that RT did not list 2.6 as default Python as a release goal. I also saw a thread talking about the problems related to 2.6. Does this mean Squeeze won't use it by default or are u guys working on it? It always seems a great challenge everytime there's a switch of defaults. Is there anything to learn from other distros or are they taking shortcuts, or is there something else holding back Debian's progress. -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team: Release goals, schedule, state of the union
Heya, > - New source package format: > Make it possible to build all packages using dpkg source format > 3.0 (quilt). This seems like something that requires packagers to take some action, or at least check their packages for this possibility? However, I've never heard about this new "source format" until now. Did I miss something, or will there be separate announcements about this still? A quick read of the dpkg-source manpage about the source format 3 didn't really help my understanding of what would be required to attain this goal. Could you elaborate a bit? Perhaps in the next update? Gr. Matthijs signature.asc Description: Digital signature
Re: [SRM] stable udev update
Hallo Marco, am Tue, Aug 25, 2009 at 10:11:47PM +0200 hast du folgendes geschrieben: > On Aug 25, Julien Cristau wrote: > > Looks like the uploaded package wasn't built in a lenny environment. > Indeed, sorry for the mistake. I am uploading a properly built > 0.125-7+lenny3. > (What about .symbols files for libraries >= standard as a release goal?) that would have hid this problem in question if there were other subtle changes from the build environment of Lenny to the old you used? (Not that I would be against it in principle or something.) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Unjamming the botan transition
Hallo Zack,
am Tue, Aug 25, 2009 at 08:43:25AM -0700 hast du folgendes geschrieben:
> I'm trying to figure out why the renamed botan library packages and
> their dependencies (monotone and keysafe) have not made it into
> testing, despite everything being a "Valid candidate". The most
> recent update_output.txt (Generated on: 2009.08.25 10:44:55 +)
> just says
FWIW, the output Andi quoted was dak ls on ftp-master. If you are
certain that there was a dinstall since Britney's update_output and
your time (there are various sources on the net to get the dinstall
times, which are 4 times a day) you can use rmadison which does
a dak ls on the database mirror which is updated at the end of dinstall.
> Trying hint from luk: botan1.8/1.8.5-5 -botan-devel/1.8.1-1
> monotone/0.44-2 keysafe/0.4-1.1
> leading: botan1.8,-botan-devel,monotone,keysafe
> failed: botan1.8
I suspect that it needed aging. When I last tried my hints they were
constantly broken by new uploads to the point I stopped tracking it.
> but yesterday's (Generated on: 2009.08.24 22:34:02 +) has
> marginally more information:
>
> Trying hint from luk: botan1.8/1.8.5-5 -botan-devel/1.8.1-1
> monotone/0.44-2 keysafe/0.4-1.1
> leading: botan1.8,-botan-devel,monotone,keysafe
> start: 139+2497:
> i-27:a-9:a-23:a-11:h-20:i-12:m-8:m-8:p-4:s-9:s-8:k-1270:k-1227
> orig: 139+2497: i-27:a-9:a-23:a-11:h-20:i-12:m-8:m-8:p-4:s-9:s-8:k-1270:k-1227
> recur: [] botan1.8,-botan-devel,monotone,keysafe 696/0
> ...
> finish: [botan1.8,-botan-devel,monotone,keysafe]
> endloop: 139+2497:
> i-27:a-9:a-23:a-11:h-20:i-12:m-8:m-8:p-4:s-9:s-8:k-1270:k-1227
> now: 139+2499:
> i-27:a-9:a-23:a-11:h-20:i-12:m-8:m-8:p-4:s-9:s-8:k-1271:k-1228
> * kfreebsd-amd64: keysafe
> * kfreebsd-i386: keysafe
> Apparently successful
>
> Despite this being *labeled* a success, packages did not move, and I
> think the problem is keysafe becoming uninstallable on
> kfreebsd-{amd64,i386}. If so, perhaps binNMUs of that package on
> those architectures would help?
We are currently not considering uninstallability on kfreebsd-* a problem.
This might change in the near future but will be announced in this case.
> The only other thing that might be going on is, is it source or binary
> packages that are mentioned in hint files? I see things like this in
> the older update_output.txt ...
It's trying source packages (and binNMUs of them as srcpkg/arch) but
uninstallability is reported for binary packages as source packages do
not have dependencies and you normally want to know where it's coming
from.
> p.s. For reference, these are the relevant lines in the current set of
> hint files:
>
> adeodato:block keysafe
> adeodato:block monotone
> luk:hint botan1.8/1.8.5-5 -botan-devel/1.8.1-1 monotone/0.44-2 keysafe/0.4-1.1
> neilm:unblock monotone/0.44-2
> neilm:remove botan-devel/1.8.1-1
> neilm:hint monotone/0.44-2
>
> of which I *think* only luk's is actually doing anything at this point.
True. And I assume that adeodato's hints are currently ignored anyway.
Kind regards,
Philipp Kern
--
.''`. Philipp KernDebian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpp:p...@0x539.de Wanna-Build Admin
`-finger pkern/k...@db.debian.org
signature.asc
Description: Digital signature
Re: Bits from the release team: Release goals, schedule, state of the union
Hi Marc
On Wed, 26 Aug 2009 04:23:09 pm Marc 'HE' Brockschmidt wrote:
> Steffen Joeris writes:
> > On Wed, 26 Aug 2009 06:51:48 am Marc 'HE' Brockschmidt wrote:
> >> Release Goals
> >> =
>
> [...]
>
> >> - kFreeBSD:
> >> Debian 6.0 Squeeze should be the first Debian release shipping with
> >> a non-Linux kernel.
> >
> > Out of curiosity, how is security support working for this and who is
> > providing it?
>
> We [1] were hoping that kfreebsd-{i386,amd64} would be handled like i386
> and amd64 and be supported by the security team.
>
> As we know that the security team's manpower is limited, we acknowledge
> this by asking you for any concers in supporting a architecture. For the
> Squeeze cycle, this hasn't been done yet [2], as we haven't decided yet
> which of the old architectures can't be supported from a release team
> point of view.
>
> Including kFreeBSD architectures in the release has been in discussion
> for some time now, and we didn't see any official security team position
> on this yet, thus assumed there were no (big) concers. Should you have
> see some, please inform us soon.
For kernel-security support, we have Dann Frazier in the security team, who is
also working in the kernel team (and of course other kernel team members might
help on security behind the curtain).
Now I am not sure how to do it for another kernel, because the rest of the
team is usually busy with the rest of the archive. Maybe it would be a good
idea to see, if someone from the kfreeBSD kernel team would be willing to
help? Also, I guess Dann or someone else from the sec team should probably
comment on this as well.
Cheers
Steffen
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team: Release goals, schedule, state of the union
On Wed, 26 Aug 2009 04:58:24 pm Andreas Barth wrote: > * Steffen Joeris (steffen.joe...@skolelinux.de) [090826 08:53]: > > For kernel-security support, we have Dann Frazier in the security team, > > who is also working in the kernel team (and of course other kernel team > > members might help on security behind the curtain). > > So your basic concern is: Who will support the kbsd-specific packages > (kernel plus kernel-near userland)? (The other packages shouldn't be > an issue, or?) Yeah basically, I mean they should be supported from within the security team, but I was wondering, whether we have a particular individual appointed for it (like for the linux kernel) or how the details should look like. I just reread my first response to Marc and saw that it could have been read as very sarcastic and rude, my apologies that wasn't the intention I wrote that sentence in a hurry. Cheers Steffen P.S. The comments/ideas/questions in this thread are my own, not the view of the security team. P.P.S. We could probably drop -devel from this thread. signature.asc Description: This is a digitally signed message part.
