Please unblock automake1.11, automake1.10, automake1.9, automake1.7
Hello, I've updated all of the automake packages in the subject to fix CVE-2012-3386. It looks like an update to automake1.4 will not be necessary but I'm awaiting confirmation and will respond back if it is. It would be good for these (admittedly mild) fixes to make it into Wheezy so please unblock these packages. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: Bug#681097: CVE-2012-3386: Information disclosure
* Adam D. Barratt (a...@adam-barratt.org.uk) wrote: On Wed, 2012-07-25 at 00:32 -0400, Eric Dorland wrote: Sorry Jonathan, due to some personal commitments and the flu I haven't gotten to this yet. But I'll prepare these by the end of the week. It appears this was uploaded already, as it's now sitting in p-u-NEW. Now that that's happened, it will get processed in due course, but for any future issues, please bear in mind that Jonathan's message said: Please prepare a minimal-changes upload targetting each of these suites, and submit a debdiff to the Release Team [0] for consideration. They will offer additional guidance or instruct you to upload your package. [...] 0: debian-release@lists.debian.org We should consider changing that to be a request to file a bug, but in any case the discussion is intended to happen /before/ the upload, not as a result of it. Sorry about that. I didn't reread the instructions when I was preparing the package and forgot this step. Attached is the debdiff. I still need to upload automake1.10, automake1.9 and automake1.7. Would you like to see those diffs as well? They will be the same. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com diff -Nru automake1.11-1.11.1/debian/changelog automake1.11-1.11.1/debian/changelog --- automake1.11-1.11.1/debian/changelog 2010-01-18 00:49:09.0 -0500 +++ automake1.11-1.11.1/debian/changelog 2012-07-29 03:20:29.0 -0400 @@ -1,3 +1,10 @@ +automake1.11 (1:1.11.1-1+squeeze1) stable; urgency=low + + * lib/am/distdir.am: Fixes CVE-2012-3386 Temporary worldwide write +permissions during make distcheck. (Closes: #681097) + + -- Eric Dorland e...@debian.org Sun, 29 Jul 2012 03:19:19 -0400 + automake1.11 (1:1.11.1-1) unstable; urgency=low * New upstream release. Contains fix for CVE-2009-4029, which created diff -Nru automake1.11-1.11.1/debian/patches/debian-changes automake1.11-1.11.1/debian/patches/debian-changes --- automake1.11-1.11.1/debian/patches/debian-changes 2010-01-18 00:57:26.0 -0500 +++ automake1.11-1.11.1/debian/patches/debian-changes 2012-07-29 03:37:59.0 -0400 @@ -1,4 +1,15 @@ Please use the git repo for development. +--- automake1.11-1.11.1.orig/lib/am/distdir.am automake1.11-1.11.1/lib/am/distdir.am +@@ -441,7 +441,7 @@ distcheck: dist + ## Make the new source tree read-only. Distributions ought to work in + ## this case. However, make the top-level directory writable so we + ## can make our new subdirs. +- chmod -R a-w $(distdir); chmod a+w $(distdir) ++ chmod -R a-w $(distdir); chmod u+w $(distdir) + mkdir $(distdir)/_build + mkdir $(distdir)/_inst + ## Undo the write access. --- automake1.11-1.11.1.orig/lib/Automake/Makefile.in +++ automake1.11-1.11.1/lib/Automake/Makefile.in @@ -37,14 +37,7 @@ subdir = lib/Automake signature.asc Description: Digital signature
debdiff for automake1.10_1.10.3-1+squeeze1
Proposed stable update for automake1.10. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com diff -Nru automake1.10-1.10.3/debian/changelog automake1.10-1.10.3/debian/changelog --- automake1.10-1.10.3/debian/changelog 2010-02-22 00:31:55.0 -0500 +++ automake1.10-1.10.3/debian/changelog 2012-07-29 21:23:29.0 -0400 @@ -1,3 +1,10 @@ +automake1.10 (1:1.10.3-1+squeeze1) stable; urgency=low + + * lib/am/distdir.am: Backport fix for CVE-2012-3386 Temporary worldwide +write permissions during make distcheck. (Closes: #681117) + + -- Eric Dorland e...@debian.org Sun, 29 Jul 2012 21:22:49 -0400 + automake1.10 (1:1.10.3-1) unstable; urgency=low * New upstream release. Contains fix for CVE-2009-4029, which created diff -Nru automake1.10-1.10.3/debian/patches/debian-changes automake1.10-1.10.3/debian/patches/debian-changes --- automake1.10-1.10.3/debian/patches/debian-changes 2010-02-22 00:33:04.0 -0500 +++ automake1.10-1.10.3/debian/patches/debian-changes 2012-07-29 21:31:23.0 -0400 @@ -1,4 +1,15 @@ Please use the git repo for development. +--- automake1.10-1.10.3.orig/lib/am/distdir.am automake1.10-1.10.3/lib/am/distdir.am +@@ -362,7 +362,7 @@ distcheck: dist + ## Make the new source tree read-only. Distributions ought to work in + ## this case. However, make the top-level directory writable so we + ## can make our new subdirs. +- chmod -R a-w $(distdir); chmod a+w $(distdir) ++ chmod -R a-w $(distdir); chmod u+w $(distdir) + mkdir $(distdir)/_build + mkdir $(distdir)/_inst + ## Undo the write access. --- automake1.10-1.10.3.orig/lib/Automake/Makefile.in +++ automake1.10-1.10.3/lib/Automake/Makefile.in @@ -36,14 +36,7 @@ subdir = lib/Automake signature.asc Description: Digital signature
debdiff for automake1.9_1.9.6+nogfdl-3.1+squeeze1
Proposed stable update for automake1.9.
--
Eric Dorland e...@kuroneko.ca
ICQ: #61138586, Jabber: ho...@jabber.com
diff -u automake1.9-1.9.6+nogfdl/Makefile.in
automake1.9-1.9.6+nogfdl/Makefile.in
--- automake1.9-1.9.6+nogfdl/Makefile.in
+++ automake1.9-1.9.6+nogfdl/Makefile.in
@@ -408,7 +408,8 @@
|| exit 1; \
fi; \
done
- -find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
+ -find $(distdir) -type d ! -perm -755 \
+ -exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {}
\; \
diff -u automake1.9-1.9.6+nogfdl/debian/changelog
automake1.9-1.9.6+nogfdl/debian/changelog
--- automake1.9-1.9.6+nogfdl/debian/changelog
+++ automake1.9-1.9.6+nogfdl/debian/changelog
@@ -1,3 +1,12 @@
+automake1.9 (1.9.6+nogfdl-3.1) unstable; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * Fixed CVE-2009-4029: do not assign insecure permissions to directories in
+build tree.
+
+
+ -- Giuseppe Iuculano iucul...@debian.org Mon, 08 Mar 2010 23:29:32 +0100
+
automake1.9 (1.9.6+nogfdl-3) unstable; urgency=low
* debian/automake1.9.postinst: Bump the priority above automake1.10 at
only in patch2:
unchanged:
--- automake1.9-1.9.6+nogfdl.orig/lib/am/distdir.am
+++ automake1.9-1.9.6+nogfdl/lib/am/distdir.am
@@ -192,11 +192,7 @@
endif %?DIST-TARGETS%
##
## This complex find command will try to avoid changing the modes of
-## links into the source tree, in case they're hard-linked. It will
-## also make directories writable by everybody, because some
-## brain-dead tar implementations change ownership and permissions of
-## a directory before extracting the files, thus becoming unable to
-## extract them.
+## links into the source tree, in case they're hard-linked.
##
## Ignore return result from chmod, because it might give an error
## if we chmod a symlink.
@@ -209,7 +205,8 @@
## the file in place in the source tree.
##
if %?TOPDIR_P%
- -find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
+ -find $(distdir) -type d ! -perm -755 \
+ -exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {}
\; \
signature.asc
Description: Digital signature
Re: debdiff for automake1.9_1.9.6+nogfdl-3.1+squeeze1
* Adam D. Barratt (a...@adam-barratt.org.uk) wrote: On Sun, 2012-07-29 at 23:24 -0400, Eric Dorland wrote: Proposed stable update for automake1.9. This looks like the patches that are already in stable? +automake1.9 (1.9.6+nogfdl-3.1) unstable; urgency=high Err whoops, attached the wrong diff. Here's the right one. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com diff -u automake1.9-1.9.6+nogfdl/debian/changelog automake1.9-1.9.6+nogfdl/debian/changelog --- automake1.9-1.9.6+nogfdl/debian/changelog +++ automake1.9-1.9.6+nogfdl/debian/changelog @@ -1,3 +1,10 @@ +automake1.9 (1.9.6+nogfdl-3.1+squeeze1) stable; urgency=low + + * lib/am/distdir.am: Backport fix for CVE-2012-3386 Temporary worldwide +write permissions during make distcheck. (Closes: #681118) + + -- Eric Dorland e...@debian.org Sun, 29 Jul 2012 22:59:38 -0400 + automake1.9 (1.9.6+nogfdl-3.1) unstable; urgency=high * Non-maintainer upload by the Security Team. diff -u automake1.9-1.9.6+nogfdl/lib/am/distdir.am automake1.9-1.9.6+nogfdl/lib/am/distdir.am --- automake1.9-1.9.6+nogfdl/lib/am/distdir.am +++ automake1.9-1.9.6+nogfdl/lib/am/distdir.am @@ -323,7 +323,7 @@ ## Make the new source tree read-only. Distributions ought to work in ## this case. However, make the top-level directory writable so we ## can make our new subdirs. - chmod -R a-w $(distdir); chmod a+w $(distdir) + chmod -R a-w $(distdir); chmod u+w $(distdir) mkdir $(distdir)/_build mkdir $(distdir)/_inst ## Undo the write access. signature.asc Description: Digital signature
debdiff for automake1.7_1.7.9-9.1+squeeze1
Proposed stable update for automake1.7. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com diff -u automake1.7-1.7.9/debian/changelog automake1.7-1.7.9/debian/changelog --- automake1.7-1.7.9/debian/changelog +++ automake1.7-1.7.9/debian/changelog @@ -1,3 +1,10 @@ +automake1.7 (1.7.9-9.1+squeeze1) stable; urgency=low + + * lib/am/distdir.am: Backport fix for CVE-2012-3386 Temporary worldwide +write permissions during make distcheck. (Closes: #681119) + + -- Eric Dorland e...@debian.org Mon, 30 Jul 2012 23:19:21 -0400 + automake1.7 (1.7.9-9.1) unstable; urgency=high * Non-maintainer upload by the Security Team. diff -u automake1.7-1.7.9/lib/am/distdir.am automake1.7-1.7.9/lib/am/distdir.am --- automake1.7-1.7.9/lib/am/distdir.am +++ automake1.7-1.7.9/lib/am/distdir.am @@ -295,7 +295,7 @@ ## Make the new source tree read-only. Distributions ought to work in ## this case. However, make the top-level directory writable so we ## can make our new subdirs. - chmod -R a-w $(distdir); chmod a+w $(distdir) + chmod -R a-w $(distdir); chmod u+w $(distdir) mkdir $(distdir)/_build mkdir $(distdir)/_inst ## Undo the write access. signature.asc Description: Digital signature
Re: debdiff for automake1.9_1.9.6+nogfdl-3.1+squeeze1
* Cyril Brulebois (k...@debian.org) wrote: Hello Eric, not sure you got that mail (at least M-F-T said you didn't want a copy): Adam D. Barratt a...@adam-barratt.org.uk (31/07/2012): On 31.07.2012 04:12, Eric Dorland wrote: * Adam D. Barratt (a...@adam-barratt.org.uk) wrote: On Sun, 2012-07-29 at 23:24 -0400, Eric Dorland wrote: Proposed stable update for automake1.9. This looks like the patches that are already in stable? +automake1.9 (1.9.6+nogfdl-3.1) unstable; urgency=high Err whoops, attached the wrong diff. Here's the right one. Thanks. Please go ahead. Regards, Adam I haven't seen a diff in p-u-NEW, hence this ping. ;) Sorry my main Debian box had a hard drive failure and I'm just piecing things back together from backups. I'll upload in the next couple of days. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
I need help getting Mozilla FIrefox 0.9.3-5 into testing
If you take a look at http://bjorn.haxx.se/debian/testing.pl?package=mozilla-firefox I'm in pretty good shape. However, I definitely need mozilla-firefox-locale-es and mozilla-firefox-locale-gl removed from testing before the new version will go in. The other problem is that I build depend on the version of binutils in unstable. I thought the testing scripts did not consider the build-depends, but if they do that could pose a problem as well. Could any release/ftp-masters take care of the first issue, and someone enlighten me to the second. Thanks. -- 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: I need help getting Mozilla FIrefox 0.9.3-5 into testing
Ok, looking again at http://bjorn.haxx.se/debian/testing.pl?package=mozilla-firefox there seems to be a few more issues. It appears that mozilla-firefox, mozilla-firefox-locale-de, mozilla-firefox-locale-fr, mozilla-firefox-locale-ja, mozilla-firefox-locale-tr, mozilla-firefox-locale-uk need to be hinted to go in together. mozilla-firefox-locale-it and mozilla-firefox-searchplugin-ja need to be hinted for removal. mozilla-firefox-locale-it should make it back into testing in 6 days with the new version, so that shouldn't be a problem. mozilla-firefox-searchplugin-ja doesn't have a version in unstable, so it's probably quite safe to remove. Thanks gentlemen. (and ladies). * Steve Langasek ([EMAIL PROTECTED]) wrote: On Sun, Sep 19, 2004 at 08:37:53PM -0400, Eric Dorland wrote: If you take a look at http://bjorn.haxx.se/debian/testing.pl?package=mozilla-firefox I'm in pretty good shape. However, I definitely need mozilla-firefox-locale-es and mozilla-firefox-locale-gl removed from testing before the new version will go in. Hinted for removal, since mozilla-firefox looks like it's ready to go tomorrow. The other problem is that I build depend on the version of binutils in unstable. I thought the testing scripts did not consider the build-depends, but if they do that could pose a problem as well. Build-Depends are not evaluated by the testing scripts, though it's important that missing build deps be taken care of prior to release. -- 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--
Re: I need help getting Mozilla FIrefox 0.9.3-5 into testing
* Steve Langasek ([EMAIL PROTECTED]) wrote: On Tue, Sep 21, 2004 at 11:11:55AM -0400, Eric Dorland wrote: Ok, looking again at http://bjorn.haxx.se/debian/testing.pl?package=mozilla-firefox there seems to be a few more issues. It appears that mozilla-firefox, mozilla-firefox-locale-de, mozilla-firefox-locale-fr, mozilla-firefox-locale-ja, mozilla-firefox-locale-tr, mozilla-firefox-locale-uk need to be hinted to go in together. mozilla-firefox-locale-it and mozilla-firefox-searchplugin-ja need to be hinted for removal. mozilla-firefox-locale-it should make it back into testing in 6 days with the new version, so that shouldn't be a problem. mozilla-firefox-searchplugin-ja doesn't have a version in unstable, so it's probably quite safe to remove. Yes, this hint is already in place. http://ftp-master.debian.org/testing/hints/ I don't see the hint for mozilla-firefox-searchplugin-ja, but I guess if it doesn't have a version in unstable, katie should be smart enough to remove it herself. Thanks for the link, learn something new everyday. Ok, mozilla-firefox should go in the next time katie runs (fingers crossed). -- 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--
Please hint firefox into testing
Hello, According to http://bjorn.haxx.se/debian/testing.pl?package=firefox firefox is ready to go into testing, except it's blocking on a bunch of translation packages that have been updated and renamed themselves already for the most part. -- 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 hint firefox into testing
* Luk Claes ([EMAIL PROTECTED]) wrote: Eric Dorland wrote: * Luk Claes ([EMAIL PROTECTED]) wrote: Eric Dorland wrote: [...] I've uploaded a fixed package of mozilla-firefox-locale-all yesterday... Apparantly all the depending packages should be no problem as they are updated. But there are some problems with the non-depending packages: m-f-locale-af-za, m-f-locale-ast-es, m-f-locale-pt-pt, m-f-locale-sq-al and m-f-theme-rtlclassic are not provided by the mozilla-firefox-locale-all package anymore as the translations are outdated; m-f-locale-ar, m-f-locale-el, m-f-locale-it, m-f-locale-ja and m-f-locale-tr ship translations for an outdated mozilla-firefox at least according to their dependencies... They've had nearly 4 months since firefox 1.5 was uploaded to unstable. We can't wait around for them to provide translations forever. It was not my intention to imply such thing (waiting for them to provide updated packages). I only wanted to shed some light on the statuses from the different packages to ease making a testing hint :-) No worries, I just wished to make it clear that I don't think we should wait for them. -- 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
Reclaiming automake
¶the [EMAIL PROTECTED] airsnort peacock Chris Lawrence [EMAIL PROTECTED] gnome-lokkit Marcelo E. Magallon [EMAIL PROTECTED] gtkgl2 gtkglarea lib3ds Camm Maguire [EMAIL PROTECTED] codebreaker maxima perspic Cyril Martin [EMAIL PROTECTED] eagle-usb Martin Maurer [EMAIL PROTECTED] fireflier Remco van de Meent [EMAIL PROTECTED] scli A Mennucc1 [EMAIL PROTECTED] snmpkit Stephen M Moraco [EMAIL PROTECTED] gpsim Gopal Narayanan [EMAIL PROTECTED] yacas Pedro Zorzenon Neto [EMAIL PROTECTED] avrprog Søren Boll Overgaard [EMAIL PROTECTED] pan tcltls Jonathan Oxer [EMAIL PROTECTED] lcdproc Barak A. Pearlmutter [EMAIL PROTECTED] xgraph VÃctor Pérez Pereira [EMAIL PROTECTED] gfslicer squidguard Zed Pobre [EMAIL PROTECTED] cppopt libmodplug modplugxmms Filip Van Raemdonck [EMAIL PROTECTED] clanlib Klaus Reimer [EMAIL PROTECTED] sqlxx strutilsxx Roberto C. Sanchez [EMAIL PROTECTED] toshutils Amaya Rodrigo Sastre [EMAIL PROTECTED] fkiss Riccardo Setti [EMAIL PROTECTED] libgalago Thomas Smith [EMAIL PROTECTED] fuzz Christian T. Steigies [EMAIL PROTECTED] luola Paul J Stevens [EMAIL PROTECTED] dbmail Al Stone [EMAIL PROTECTED] llvm Norbert Tretkowski [EMAIL PROTECTED] lcd4linux Riku Voipio [EMAIL PROTECTED] wbxml2 James R. Van Zandt [EMAIL PROTECTED] autoproject -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* Artur R. Czechowski ([EMAIL PROTECTED]) wrote: Hi Eric, On Sun, Jun 25, 2006 at 07:11:14PM -0400, Eric Dorland wrote: automake1.4: This is the old school package, that's been completely unsupported for a number of years (since 2002). It certainly not used with any new software and any software still using it should be migrated away from it. It is also the only package that provides automake, cause there are still 73 packages by my reckoning that build depend on automake and expect that be automake 1.4. Have you considered packages depending on automake1.4? apt-cache rdepends automake1.4 | grep ^ | dd-list --stdin says: For the purpose of this transition these are fine. But yes, it would better if these packages could depend on something newer. Hakan Ardo [EMAIL PROTECTED] toolchain-source For some reason this depends on both automake1.4 and automake1.7. Weird. Debian PHP Maintainers [EMAIL PROTECTED] php4 php5 php4 is fairly old, but I'm surprised php5 still uses automake 1.4. Is this really the case? Gustavo Noronha Silva [EMAIL PROTECTED] glade Glade apparently still generates 1.4 Makefile.am files. Probably easy to fix, if anyone is working on glade anymore. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* Scott James Remnant ([EMAIL PROTECTED]) wrote: On Thu, 2006-06-29 at 19:37 -0400, Eric Dorland wrote: * Scott James Remnant ([EMAIL PROTECTED]) wrote: On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: Scott James Remnant dropped me an email recently, interested in improving the automake situation in Ubuntu and Debian[0]. [0] Their plan, which mirrors mine, is documented here: https://wiki.ubuntu.com/AutomakeTransition If you could have another read through of that spec, now it's post-draft, and make sure we're still both planning the same thing that'd be great. I don't see any reason for Ubuntu to go a different direction to Debian here. In particular I had a momentary thought about what packages should actually depend/build-depend on now -- could you check that. The automaken | automake$VER is probably not wise. A new version of automake may not be fully backwards compatible. If it were, we wouldn't have these problems. Better to depend on a known version that works, or better still don't build depend on it at all and ship the generated files in the diff.gz. I'd personally tend to err on the assume it is, unless it isn't -- would you suggest all packages be changed to not B-D on automaken then? In my opinion this would be best practice. Some maintainers don't agree. I'm going to get started on Saturday, and I'll be on IRC (#debian-devel) so if you (or anyone) want to join in the fun, we can coordinate there. I've just filed #376047 too, so any bugs filed should be made to block that one. The disadvantage of doing this for a living, rather than for fun, is that weekends tend to be out :) I'll pick up on Monday :p You've lost your love of free software Scott :P No worries, hopefully on Monday you'll wake up to see a lot of progress. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Bug#578358: gnupg-agent: mangles passphrases should be grave (data loss, fixed upstream)
fixed 578358 2.0.14-2 thanks * Simon McVittie (s...@debian.org) wrote: On Tue, 07 Sep 2010 at 04:12:15 +0200, Lionel Elie Mamane wrote: On Mon, Apr 19, 2010 at 09:18:57AM +, Sascha Silbe wrote: Keys created / imported / having passphrase changed with gpg-agent 2.0.14 cannot be decrypted (and thus used), preventing all gpg operations. This has been fixed upstream in 2.0.15: Keys that are already mangled are unreadable even by 2.0.15 This seems to be a duplicate of Bug #567926. According to Werner's announcement in http://marc.info/?l=gnupg-usersm=126451730710129w=2 this can affect X.509 and SSH keys, but not OpenPGP. The patch whose ChangeLog entry Sascha quoted seems to be identical to encode-s2k.patch, which was applied in 2.0.14-1.1 to fix #567926, then re-applied by the maintainer in 2.0.14-2. Indeed, this is fixed in 2.0.14-2. Sascha, were you basing your bug report on a bug you have experienced yourself, or just on the upstream announcement? If you have experienced the bug yourself and know how to reproduce it, could you please try to do so with 2.0.14-2 and confirm whether it's already been fixed? Relatedly, the BTS still thinks #567926 affects 2.0.14-2 (because the changelog for that version neither includes the NMU entry nor re-closes the bug), but for some reason it has archived that bug anyway. Fixing that now... Regards, Simon -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: Security updates for mozilla based software [Was: Security updates]
Alexander Sack wrote: On Sun, Dec 24, 2006 at 01:43:40PM +0100, Mike Hommey wrote: Oops, I decided to follow-up to debian-release after setting the subject and forgot to change it. So, here is a proper subject. On Sun, Dec 24, 2006 at 01:40:37PM +0100, Mike Hommey [EMAIL PROTECTED] wrote: Hi I see Alex has uploaded version 1.5.0.9 of icedove. What should we take as a course of action for xulrunner, iceweasel and iceape ? Should we go with newer upstreams (note there's no official xulrunner release, but I fake them taking from tags in upstream cvs) or backport security fixes ? Please lets upload new upstream versions as long as possible - e.g. as long as etch is not released. Those are just minor upstream version shifts, so taking them entirely should be pretty safe imo. Right, I agree. In fact I'm building 2.0.0.1 packages right now on my laptop, but I might need you to sign and upload them Mike. Sorry it's taken me a while, life's been very busy the last month. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security updates for mozilla based software [Was: Security updates]
Eric Dorland wrote: Alexander Sack wrote: On Sun, Dec 24, 2006 at 01:43:40PM +0100, Mike Hommey wrote: Oops, I decided to follow-up to debian-release after setting the subject and forgot to change it. So, here is a proper subject. On Sun, Dec 24, 2006 at 01:40:37PM +0100, Mike Hommey [EMAIL PROTECTED] wrote: Hi I see Alex has uploaded version 1.5.0.9 of icedove. What should we take as a course of action for xulrunner, iceweasel and iceape ? Should we go with newer upstreams (note there's no official xulrunner release, but I fake them taking from tags in upstream cvs) or backport security fixes ? Please lets upload new upstream versions as long as possible - e.g. as long as etch is not released. Those are just minor upstream version shifts, so taking them entirely should be pretty safe imo. Right, I agree. In fact I'm building 2.0.0.1 packages right now on my laptop, but I might need you to sign and upload them Mike. Sorry it's taken me a while, life's been very busy the last month. In fact I am away from my gpg key, so if you could sign upload the package at http://people.debian.org/~eric/iceweasel/. New iceweasel package for christmas :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#404733: Mozilla-based and related packages status
* Steve Langasek ([EMAIL PROTECTED]) wrote: We're now down to 1 RC bug it seems, but this is still outstanding. I had heard from other members of the release team that an upload was expected this weekend, but that appears not to have happened. Since there seems to be a consensus that iceweasel should not ship /usr/lib/firefox, and this bug blocks a significant fraction of the remaining RC bugfixes for etch, I'm going to go ahead with preparing an NMU for this against the current unstable now. Please don't. I will be uploading a new version late tonight at the latest. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Mozilla codebase releases 1.8.1.2 and 1.8.0.10
* Steve Langasek ([EMAIL PROTECTED]) wrote: On Sun, Feb 25, 2007 at 09:39:46AM +0100, Mike Hommey wrote: I'll let the RMs decide whether iceape and icedove upgrades are less problematic since they don't involve reverse dependencies. Less problematic, certainly. Hopefully these updates won't have the problem of past mozilla new-upstream-version security fixes, where every single file shows up in the diff because of cvs keywords? I don't think every single file will, but yes, there are a bunch of CVS keyword changes only I believe. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Mozilla codebase releases 1.8.1.2 and 1.8.0.10
* Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) wrote: Mike Hommey [EMAIL PROTECTED] writes: [new iceweasel to unstable] The fix for #412418 is already in svn. I'm not sure it will happen for next upload but I'd like to uniformize the patches applied to all the mozilla packages, which I started to do with xulrunner in version 1.8.0.10-1, which explains some of the new patches applied to it. These new patches on xulrunner were taken from icedove, iceweasel or iceape for most of them. I'd like to do the same kind of thing with iceape and iceweasel before the release, if we have time for this, which is the reason of [1], which needs to be updated with the latest information available. I would love to see an upload to unstable before you start with that work, so that we can get a releasable version of iceweasel into testing soon. If time allows, you can propose a new packages with reorganized/added patches at a later point, but right now, I would like to get big pieces like iceweasel finally ready for release. I'll try to roll a new release tonight. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Mozilla codebase releases 1.8.1.2 and 1.8.0.10
* Mike Hommey ([EMAIL PROTECTED]) wrote: On Tue, Mar 06, 2007 at 06:05:09PM -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Mar 06, 2007 at 01:38:02PM +0100, Mike Hommey wrote: On Tue, Mar 06, 2007 at 12:13:37PM +0100, Marc 'HE' Brockschmidt wrote: Eric Dorland [EMAIL PROTECTED] writes: * Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) wrote: I would love to see an upload to unstable before you start with that work, so that we can get a releasable version of iceweasel into testing soon. If time allows, you can propose a new packages with reorganized/added patches at a later point, but right now, I would like to get big pieces like iceweasel finally ready for release. I'll try to roll a new release tonight. This led to #413162 (and friends). Could you please do another upload fixing only this bug, so that we finally have a version that is releasable? Plus, upstream is going to put up a 2.0.0.3 release fixing regressions introduced in 2.0.0.1 and 2.0.0.2, including a fix on client certificate handling that may be important at least for french people who want to do their tax declaration online using iceweasel. We really need to be converging on the release at this point. If 2.0.0.3 doesn't include any RC fixes, please upload the 2.0.0.2 that you have so that we can get iceweasel into a releasable state and consider 2.0.0.3 when it's available. I don't think there's any harm in releasing 2.0.0.2+dfsg-3 right now, and then uploading 2.0.0.3 a few days later. I've screwed up the last few releases, so it would be good to make sure the little bugs are all out of the way so when 2.0.0.3 is released it will be a simple drop in. I'm building right now and will upload once it's built. You have approximately an hour to stop me if you really feel this is a bad idea. Here are the bugs that are fixed in 2.0.0.3, so far: https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=blocking1.8.1.3%2Border=map_assigned_to.login_name,bugs.bug_id One is security wise, though I don't see any real critical impact for this... I'd say #371525, #371576, and #370136 are pretty serious regressions. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Some last minute things that would be good to push in
Hello,
I have a few minor fixes in packages that are in unstable right now
that while not release critical, I think would be helpful to have in
the next release. I've attached patches below for ease of reviewing.
automake 1:1.4-p6-11 - 1:1.4-p6-12
This just removes the provides of automake, since we're moving away
from supporting automake 1.4, and also adds a versioned conflict on
automake, which allows automake1.4 and the new automake package be
able to be installed at the same time, which would be good. Low risk.
automake1.8 1.8.5+nogfdl-1 - 1.8.5+nogfdl-2
Remove a doc-base file which removes an annoying warning at install
time. Very low risk.
opensc 0.11.1-2 - 0.11.1-3
Biggest fix here is to put the mozilla-signer plugin in the right
place. Also some documentation and path fix. Low risk.
post-el 2004.07.23-3 - 2004.07.23-5
Fixes to make it work with emacs22. I'm a heavy user of this so tested
very well. Low risk.
sqlfairy 0.07-4 - 0.07-5
Small fix for some broken argument variables. Very low risk.
And FYI there will probably be new security fix upstream releases for
gnupg2 and iceweasel within the week.
--
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
Index: debian/control
===
--- debian/control (.../1.4-p6-11) (revision 47609)
+++ debian/control (.../1.4-p6-12) (revision 47609)
@@ -2,15 +2,15 @@
Section: devel
Priority: optional
Maintainer: Eric Dorland [EMAIL PROTECTED]
-Standards-Version: 3.7.2.0
+Standards-Version: 3.7.2.2
Build-Depends: debhelper ( 4.0),
Build-Depends-Indep: autotools-dev (= 20010511.2), texinfo
Package: automake1.4
Architecture: all
Section: devel
-Provides: automaken, automake, automake1.4-doc
-Conflicts: automake, automake1.5, automake1.4-doc
+Provides: automake1.4-doc
+Conflicts: automake ( 1:1.4-p6-3), automake1.5, automake1.4-doc
Replaces: automake, automake1.4-doc
Depends: autoconf, autotools-dev (= 20010511.2)
Description: A tool for generating GNU Standards-compliant Makefiles
Index: debian/changelog
===
--- debian/changelog (.../1.4-p6-11) (revision 47609)
+++ debian/changelog (.../1.4-p6-12) (revision 47609)
@@ -1,3 +1,14 @@
+automake (1:1.4-p6-12) unstable; urgency=high
+
+ * Urgency high, I love doing things at the last minute.
+ * debian/control:
+- Standards-Version to 3.7.2.2.
+- Don't provide automake and automaken anymore, we are too old.
+- Versioned conflict on automake, since we now have a new automake
+ package.
+
+ -- Eric Dorland [EMAIL PROTECTED] Thu, 19 Oct 2006 00:35:56 -0400
+
automake (1:1.4-p6-11) unstable; urgency=low
* debian/copyright: Update FSF address.
Index: debian/automake1.8.doc-base
===
--- debian/automake1.8.doc-base (.../1.8.5+nogfdl-1) (revision 47611)
+++ debian/automake1.8.doc-base (.../1.8.5+nogfdl-2) (revision 47611)
@@ -1,17 +0,0 @@
-Document: automake-1.8
-Title: automake-1.8
-Abstract: Automake is a tool for automatically generating `Makefile.in's from
- files called `Makefile.am'.
- .
- The goal of Automake is to remove the burden of Makefile maintenance
- from the back of the individual GNU maintainer (and put it on the back
- of the Automake maintainer).
- .
- The `Makefile.am' is basically a series of `make' macro definitions
- (with rules being thrown in occasionally). The generated
- `Makefile.in's are compliant with the GNU Makefile standards.
-Section: Apps/programming
-
-Format: info
-Index: /usr/share/info/automake-1.8.info.gz
-Files: /usr/share/info/automake-1.8.info*
Index: debian/changelog
===
--- debian/changelog (.../1.8.5+nogfdl-1) (revision 47611)
+++ debian/changelog (.../1.8.5+nogfdl-2) (revision 47611)
@@ -1,3 +1,10 @@
+automake1.8 (1.8.5+nogfdl-2) unstable; urgency=high
+
+ * debian/automake1.8.doc-base: Forgot to remove. Thanks Daniel
+Leidert. (Closes: #404097)
+
+ -- Eric Dorland [EMAIL PROTECTED] Mon, 29 Jan 2007 02:08:46 -0500
+
automake1.8 (1.8.5+nogfdl-1) unstable; urgency=low
* New tarball with GFDL documentation stripped out because of Cover
Index: debian/control
===
--- debian/control (.../0.11.1-2) (revision 47611)
+++ debian/control (.../0.11.1-3) (revision 47611)
@@ -72,6 +72,7 @@
Section: web
Architecture: any
Depends: ${shlibs:Depends}
+Recommends: pinentry-gtk2 | pinentry-x11
Replaces: libopensc-openssl ( 0.9.4-6)
Description: Mozilla plugin for authentication using OpenSC
A plugin for mozilla that allows S/MIME and SSL authentication using
Index: debian/changelog
===
--- debian/changelog (.../0.11.1-2) (revision 47611)
+++ debian/changelog
Re: Some last minute things that would be good to push in
* Steve Langasek ([EMAIL PROTECTED]) wrote: On Thu, Mar 08, 2007 at 04:28:30AM -0500, Eric Dorland wrote: I have a few minor fixes in packages that are in unstable right now that while not release critical, I think would be helpful to have in the next release. I've attached patches below for ease of reviewing. automake 1:1.4-p6-11 - 1:1.4-p6-12 This just removes the provides of automake, since we're moving away from supporting automake 1.4, and also adds a versioned conflict on automake, which allows automake1.4 and the new automake package be able to be installed at the same time, which would be good. Low risk. Four packages in testing build-depend on automake[1]. Do you know which version they build with? Granted, the current situation means that the resolution of the build-dep may be non-deterministic; but it might instead be deterministic but non-obvious, in which case this change would introduce 4 RC bugs... Well don't the buildds and other tools always prefer a real package over a Provides? automake1.8 1.8.5+nogfdl-1 - 1.8.5+nogfdl-2 Remove a doc-base file which removes an annoying warning at install time. Very low risk. Unblocked. opensc 0.11.1-2 - 0.11.1-3 Biggest fix here is to put the mozilla-signer plugin in the right place. Also some documentation and path fix. Low risk. Unblocked. post-el 2004.07.23-3 - 2004.07.23-5 Fixes to make it work with emacs22. I'm a heavy user of this so tested very well. Low risk. emacs22 isn't in etch; not reviewed. Ah, good point. sqlfairy 0.07-4 - 0.07-5 Small fix for some broken argument variables. Very low risk. Unblocked. Thanks, No, thank you :) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Some last minute things that would be good to push in
* Steve Langasek ([EMAIL PROTECTED]) wrote: On Fri, Mar 09, 2007 at 01:37:14AM -0500, Eric Dorland wrote: * Steve Langasek ([EMAIL PROTECTED]) wrote: On Thu, Mar 08, 2007 at 04:28:30AM -0500, Eric Dorland wrote: I have a few minor fixes in packages that are in unstable right now that while not release critical, I think would be helpful to have in the next release. I've attached patches below for ease of reviewing. automake 1:1.4-p6-11 - 1:1.4-p6-12 This just removes the provides of automake, since we're moving away from supporting automake 1.4, and also adds a versioned conflict on automake, which allows automake1.4 and the new automake package be able to be installed at the same time, which would be good. Low risk. Four packages in testing build-depend on automake[1]. Do you know which version they build with? Granted, the current situation means that the resolution of the build-dep may be non-deterministic; but it might instead be deterministic but non-obvious, in which case this change would introduce 4 RC bugs... Well don't the buildds and other tools always prefer a real package over a Provides? They'll do whatever apt-get does. Is it the case that apt-get always prefers a real package? If so I have no problem unblocking this. Well doing an apt-get install automake in a fresh etch chroot with no automake packages installed does the following: # apt-get install automake Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: autoconf autotools-dev m4 Suggested packages: autoconf2.13 autobook autoconf-archive gnu-standards autoconf-doc automake1.10-doc Recommended packages: automaken The following NEW packages will be installed: autoconf automake autotools-dev m4 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/1055kB of archives. After unpacking 3863kB of additional disk space will be used. Do you want to continue [Y/n]? Selecting previously deselected package m4. (Reading database ... 9637 files and directories currently installed.) Unpacking m4 (from .../archives/m4_1.4.8-2_i386.deb) ... Selecting previously deselected package autoconf. Unpacking autoconf (from .../autoconf_2.61-4_all.deb) ... Selecting previously deselected package autotools-dev. Unpacking autotools-dev (from .../autotools-dev_20060702.1_all.deb) ... Selecting previously deselected package automake. Unpacking automake (from .../automake_1%3a1.10+nogfdl-1_all.deb) ... Setting up m4 (1.4.8-2) ... Setting up autoconf (2.61-4) ... Setting up autotools-dev (20060702.1) ... Setting up automake (1.10+nogfdl-1) ... So it looks like it will certainly prefer the real package over the virtual one. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Please push mozilla-firefox 1.0.4-2 into testing
Alright, after a false start with 1.0.4-1, -2 has finished building on m68k and is ready for inclusion in testing. 1.0.4 is security fix release, no new features. -- 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: remove mozilla-firebird from testing
Just relax guys, I've been lazy about this. It will get done shortly. * Andreas Barth ([EMAIL PROTECTED]) wrote: * Andre Lehovich ([EMAIL PROTECTED]) [040310 05:40]: On Tue, 9 Mar 2004, Steve Langasek wrote: There are no outstanding RC bugs on this source package, and therefore #233916 still applies to mozilla-firebird, and I've reopened it. It was closed by the upload of mozilla-firefox/0.8.2 but remained in the mozilla-firebird packages. If mozilla-firebird is replaced by -firefox, then please fill a bug against ftp.d.o for removal, and it'll be removed. That's the best way to do it. Cheers, Andi -- 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--
Re: Comments regarding automake1.12_1.12-1_amd64.changes
* Cyril Brulebois (k...@debian.org) wrote: Luca Falavigna dktrkr...@debian.org (22/05/2012): Also adding debian-release mailing list in the loop. Thanks, Luca. 2012/5/22 Luca Falavigna ftpmas...@debian.org: I fear your automake 1.12 upload won't end up in unstable so soon. As you know, Release Team is planning to freeze Wheezy within June, and uploading a new major version of automake now could lead to more RC bugs, forcing the delay of the freeze or the release date. I blocked the upload for now pending a OK from the Release Team first, you should get in touch with them to see whether it's OK to have the new automake in unstable. Hello Eric, we're struggling with a bunch of uncoordinated transitions at the moment, with extra fun thanks to an uncoordinated switch to gcc 4.7, and its extra hundreds of RC bugs; so it would be nice if we could wait until this big mess is sorted out before considering an additional switch to a new automake version. Ideally, an archive-wide rebuild would make it possible to see how many new FTBFS would pop up, and see if that can be handled. How would one go about getting a archive-wide rebuild to test this? I hope that sheds some light on the current situation… Sure, thanks for the details. It would be nice to get automake 1.12 into the release but it wouldn't be the end of the world. I'm actually more worried about getting ride of automake1.7 for this release (http://bugs.debian.org/648591, since I have your attention). I'll still be able to upload new versions of automake 1.11 if this upload is rejected right? Mraw, KiBi. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: On the (ab)use of the Urgency field
* Adam D. Barratt (a...@adam-barratt.org.uk) wrote: Hi, I realise everyone's waiting for news of the freeze (we're working on it...) but please bear in mind that this is not an appropriate use of the Urgency field: * Urgency high to beat the freeze. As mentioned in the last mail we sent to d-d-a (and several at various points before that) if you have serious concerns that important updates to your package won't be included in the release, the correct approach is to talk to us, not try and work around us. The net effect of the above is more likely to be that the urgency will be overriden on the britney side as if the package had been uploaded with a lower urgency. It looks like my recent libassa upload fell afoul of this, but it does in fact fix a release critical bug in libassa 3.5.1-1. The -dev package is missing a dependency that makes building against the library impossible. The changelog could have been clearer and I could have filed a bug, but I was lazy. Can you please remove the urgency override? -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: Mozilla in Lenny
* Mike Hommey ([EMAIL PROTECTED]) wrote: [snip] - Anti-phishing protection should be disabled by default, because of its privacy concerns. This must be done on iceweasel end. My tcpdump'ing around did not confirm that they're sending every request out to check for phising. Has anyone actually observed this? PS thanks for all the great work on xulrunner. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: iceweasel 3.0.3- into lenny
Hello release gurus, Could you unblock iceweasel to let in 3.0.3-2, which fixes several security issues and a branding issue? * Noèl Köthe ([EMAIL PROTECTED]) wrote: Hello Eric and Mike, http://packages.qa.debian.org/i/iceweasel.html iceweasel needs a request on debian-release@ to get the new version into lenny. Is it just forgoten, because I cannot find one on the lists. Thank you. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [SRM] Update of gnupg/gnupg2 to fix a memory leak (was: Bug#345911: gnupg: Memory leak fix)
* Daniel Leidert (daniel.leidert.s...@gmx.net) wrote: Hi, In the past it had been reported several times, that importing a large keyring (for example the Debian keyring) might need a really long time and make gnupg allocate much memory (trying to reproduce the issue I observed a DoS). I recently reported the issue to Werner Koch and he found a memory leak and fixed the issue. It seems the patch applies to gnupg (probably to 1.4.6 in oldstable too) as well as gnupg2. Should this be fixed in stable and olstable? Then I would prepare the packages for gnupg (CCed Eric for gnupg2). http://bugs.debian.org/345911 (#345911, #113897, #172115) https://bugs.g10code.com/gnupg/issue1034 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=31;filename=345911_svn4993.diff;att=1;bug=345911 http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/g10/keyring.c?root=GnuPGrev=4993r1=4963r2=4993 (gnupg 1.4) http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/g10/keyring.c?root=GnuPGrev=4994r1=4980r2=4994 (gnupg2) Regards, Daniel I didn't see any response to this, did anything come of it? -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: automake transition breakages
* Ondřej Surý (ond...@sury.org) wrote: Hi, recent automake transition to 1.14 broke (FTBFS) at least two of my packages. Would it be possible to coordinate the (next) transition better than uploaddeal with breakages like we do with the rest of our packages? Did the transition from automake 1.13 to automake 1.14 cause your package to FTBFS? Can you point me at logs because that's not supposed to happen under the new versioning scheme upstream is following (ie 1.X versions should now be backwards compatible). If you were going from an earlier version to 1.14 (or 1.13) I have seen a few reports of problems with unit test framework. Right now the automake package is always tracking the latest upstream version and new versions sometimes break things. If you're worried about that kind of breakage then build depending on a specific version of automake might be a better bet. If people don't like this current scheme we can discuss if the current scheme is a bad idea. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: automake transition breakages
* Guillem Jover (guil...@debian.org) wrote: Hi! On Mon, 2013-09-30 at 11:09:26 +0200, Ondřej Surý wrote: I have seen these two breakages (so far): libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 This uses -Werror in AM_INIT_AUTOMAKE, don't do that. Ah yes, this has bitten a few other people as several new warnings have been added in the last couple of releases so this is basically guaranteed to cause a failure. gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 (gweled) This one is calling autoreconf in debian/rules w/o --install (or --force), and as such will miss needed scripts at build time. I don't see any problem with automake here, just upstream or packaging problems. Thanks for the analysis Guillem. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: automake transition breakages
* Ondřej Surý (ond...@sury.org) wrote: Hi Eric, On Mon, Sep 30, 2013, at 4:50, Eric Dorland wrote: * Ondřej Surý (ond...@sury.org) wrote: Hi, recent automake transition to 1.14 broke (FTBFS) at least two of my packages. Would it be possible to coordinate the (next) transition better than uploaddeal with breakages like we do with the rest of our packages? Did the transition from automake 1.13 to automake 1.14 cause your package to FTBFS? Can you point me at logs because that's not supposed to happen under the new versioning scheme upstream is following (ie 1.X versions should now be backwards compatible). If you were going from an earlier version to 1.14 (or 1.13) I have seen a few reports of problems with unit test framework. I have seen these two breakages (so far): libgd2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724841 gyrus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724917 both packages has been successfully built in wheezy (gyrus) or jessie (libgd2). Right now the automake package is always tracking the latest upstream version and new versions sometimes break things. If you're worried about that kind of breakage then build depending on a specific version of automake might be a better bet. If people don't like this current scheme we can discuss if the current scheme is a bad idea. I am not worried about the scheme, but about the process. I don't know if this was an one time fling, or it will happen more frequently, but if the updates starts breaking things more often then uploading the new automake version to experimental and then trying to rebuild (at least part of) the archive, or adding an lintian checks, etc. would be a good way how to improve the process. Doing a rebuild is something I could try for next time. I'm not really familiar with how to do that though, can you point me in the right direction? What sort of lintian checks did you have in mind? But maybe I am just an exception to the rule with my two out of ~80 packages breaking. Ondrej -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#864383: unblock: libp11-openssl1.1/0.4.4-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libp11-openssl1.1 This is a new package which is adds only pkcs11 engine support for openssl 1.1. Without this the change it can't be used with openssl 1.1 only with openssl 1.0.2 and since the openssl command is coming from 1.1 without this it would be a functionality regression in stretch. Full context in #846548. No debdiff since this is a new package. unblock libp11-openssl1.1/0.4.4-4 -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#913674: release.debian.org: Regression: Recent upgrade of opensc breaks Yubikey NEO support
Sorry for the delay, I'm happy to prepare a p-u upload this weekend. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
