Bug#639560: symbol changes
Hi, I made the upload, so I guess I should comment on this. On Sun, 2011-08-28 at 15:39 +0200, Jakub Wilk wrote: > * Philipp Kern , 2011-08-28, 10:52: > >The package FTBFS'es on mips, powerpc, s390, sparc and the inofficial > >ports s390x and powerpcspe because of changes in the symbol set wrt the > >symbols file: > > Hmm, symbols file was added in 0.7-5, even though it isn't mentioned in > the changelog. Yep, sorry, forgot to add that one to the changelog... > >- spifhash_jenkinsLE@Base 0.7 > >+#MISSING: 0.7-5# spifhash_jenkinsLE@Base 0.7 > > Looking at the source code spifhash_jenkinsLE is only defined on > little-endian systems. Yes. > >+ spiftool_regexp_match@Base 0.7-5 > >+ spiftool_regexp_match_r@Base 0.7-5 > > These two OTOH are defined everywhere and I don't understand why they > weren't included in the symbols file. Even lintian loudly complains: > > E: libast2: symbols-file-contains-current-version-with-debian-revision on > symbol spiftool_regexp_match@Base and 1 others Except lintian didn't complain at all when I built it in a freshly updated chroot. These symbols are actually conditional on the presence of some header (regex.h) from libc6-dev, so I guess my build might have happened in a time window when there were some multi-arch related header problems. Anyway, I'll fix that with a new upload today. Regis -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314619435.2777.7.camel@x200s
Processed: z88: send tags to control@b.d.o
Processing commands for cont...@bugs.debian.org: > tags 639059 patch Bug #639059 [src:z88] z88: FTBFS: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory Added tag(s) patch. > user ubuntu-de...@lists.ubuntu.com Setting user to ubuntu-de...@lists.ubuntu.com (was mon...@probeta.net). > usertags 639059 origin-ubuntu Bug#639059: z88: FTBFS: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory There were no usertags set. Usertags are now: origin-ubuntu. > usertags 639059 oneiric Bug#639059: z88: FTBFS: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory Usertags were: origin-ubuntu. Usertags are now: origin-ubuntu oneiric. > usertags 639059 ubuntu-patch Bug#639059: z88: FTBFS: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory Usertags were: origin-ubuntu oneiric. Usertags are now: ubuntu-patch origin-ubuntu oneiric. > usertags 639059 multiarch Bug#639059: z88: FTBFS: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory Usertags were: ubuntu-patch origin-ubuntu oneiric. Usertags are now: ubuntu-patch multiarch origin-ubuntu oneiric. > thanks Stopping processing here. Please contact me if you need assistance. -- 639059: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639059 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131462378512882.transcr...@bugs.debian.org
Processed: [src:timidity] A debdiff to fix the FTBFS bug
Processing commands for cont...@bugs.debian.org: > tags 639196 patch Bug #639196 [src:timidity] timidity: FTBFS: nas_a.c:201: undefined reference to `AuNextEvent' Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 639196: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639196 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131462519421922.transcr...@bugs.debian.org
Bug#639196: [src:timidity] A debdiff to fix the FTBFS bug
tags 639196 patch thanks Hi, I attach a debdiff with a QA Upload to solve this bug. As this package has an ITA, maybe this patch can be added to the adoption :-) I can try to ask for a sponsor to make the QA upload if the adopter prefers it. Cheers, Mònica diff -Nru timidity-2.13.2/debian/changelog timidity-2.13.2/debian/changelog --- timidity-2.13.2/debian/changelog 2010-06-08 18:33:38.0 +0200 +++ timidity-2.13.2/debian/changelog 2011-08-29 15:03:17.0 +0200 @@ -1,3 +1,11 @@ +timidity (2.13.2-40) unstable; urgency=low + + * QA upload. + * Pass the new multiarch ubication of nas library to ./configure, +and build-depend on dpkg-dev. (Closes: #639196) + + -- Mònica Ramírez Arceda Mon, 29 Aug 2011 12:54:24 +0200 + timidity (2.13.2-39) unstable; urgency=low * Orphan the package. diff -Nru timidity-2.13.2/debian/control timidity-2.13.2/debian/control --- timidity-2.13.2/debian/control 2010-06-08 18:34:05.0 +0200 +++ timidity-2.13.2/debian/control 2011-08-29 15:03:38.0 +0200 @@ -2,7 +2,7 @@ Section: sound Priority: optional Maintainer: Debian QA Group -Build-Depends: debhelper (>= 7), libasound2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], libaudiofile-dev, libesd0-dev, libjack-dev, libaudio-dev, libvorbis-dev (>= 1.0.0-3), libspeex-dev (>= 1.0), libflac-dev (>= 1.1.4), libncurses-dev, libslang2-dev, libx11-dev, libxext-dev, libxmu-dev, libxpm-dev, libxt-dev, libxaw7-dev, tcl8.4-dev, tk8.4-dev, libgtk2.0-dev, autotools-dev +Build-Depends: debhelper (>= 7), libasound2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], libaudiofile-dev, libesd0-dev, libjack-dev, libaudio-dev, libvorbis-dev (>= 1.0.0-3), libspeex-dev (>= 1.0), libflac-dev (>= 1.1.4), libncurses-dev, libslang2-dev, libx11-dev, libxext-dev, libxmu-dev, libxpm-dev, libxt-dev, libxaw7-dev, tcl8.4-dev, tk8.4-dev, libgtk2.0-dev, autotools-dev, dpkg-dev (>= 1.16.0) Standards-Version: 3.8.3 Homepage: http://timidity.sourceforge.net/ diff -Nru timidity-2.13.2/debian/rules timidity-2.13.2/debian/rules --- timidity-2.13.2/debian/rules 2009-09-11 09:47:54.0 +0200 +++ timidity-2.13.2/debian/rules 2011-08-29 15:18:18.0 +0200 @@ -14,6 +14,8 @@ export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) export DEB_BUILD_ARCH_OS ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS) +export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +export DEB_LIBDIR_MULTIARCH = /usr/lib/$(DEB_HOST_MULTIARCH) # FOR AUTOCONF 2.52 AND NEWER ONLY CONFFLAGS = @@ -77,7 +79,8 @@ --with-default-output=default \ --enable-interface=$(interface) \ --enable-dynamic=slang,tcltk,vt100,xskin,gtk \ - --enable-server --enable-network --enable-spectrogram --enable-wrd + --enable-server --enable-network --enable-spectrogram --enable-wrd \ + --with-nas-library=$(DEB_LIBDIR_MULTIARCH)/libaudio.so touch doconfigure-stamp clean: configure doconfigure signature.asc Description: This is a digitally signed message part
Bug#639196: [src:timidity] A debdiff to fix the FTBFS bug
Thanks -- I do have (essentially) that fix in my intended upload, but forgot about the dpkg-dev versioned build dependency. I'll fix that and will poke my sponsor again. -- Geoffrey Thomas geo...@ldpreload.com On Mon, 29 Aug 2011, Mònica Ramírez Arceda wrote: tags 639196 patch thanks Hi, I attach a debdiff with a QA Upload to solve this bug. As this package has an ITA, maybe this patch can be added to the adoption :-) I can try to ask for a sponsor to make the QA upload if the adopter prefers it. Cheers, Mònica
Processing of tagsoup_1.2-3_amd64.changes
tagsoup_1.2-3_amd64.changes uploaded successfully to localhost along with the files: tagsoup_1.2-3.dsc tagsoup_1.2-3.diff.gz libtagsoup-java_1.2-3_all.deb libtagsoup-java-doc_1.2-3_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qy62n-0003hz...@franck.debian.org
Processing of tinylaf_1.4.0-2_amd64.changes
tinylaf_1.4.0-2_amd64.changes uploaded successfully to localhost along with the files: tinylaf_1.4.0-2.dsc tinylaf_1.4.0-2.diff.gz tinylaf_1.4.0-2_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qy67f-0003be...@franck.debian.org
tagsoup_1.2-3_amd64.changes ACCEPTED into unstable
Accepted: libtagsoup-java-doc_1.2-3_all.deb to main/t/tagsoup/libtagsoup-java-doc_1.2-3_all.deb libtagsoup-java_1.2-3_all.deb to main/t/tagsoup/libtagsoup-java_1.2-3_all.deb tagsoup_1.2-3.diff.gz to main/t/tagsoup/tagsoup_1.2-3.diff.gz tagsoup_1.2-3.dsc to main/t/tagsoup/tagsoup_1.2-3.dsc Override entries for your package: libtagsoup-java-doc_1.2-3_all.deb - optional doc libtagsoup-java_1.2-3_all.deb - optional java tagsoup_1.2-3.dsc - source libs Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qy6bf-0005d3...@franck.debian.org
tinylaf_1.4.0-2_amd64.changes ACCEPTED into unstable
Accepted: tinylaf_1.4.0-2.diff.gz to main/t/tinylaf/tinylaf_1.4.0-2.diff.gz tinylaf_1.4.0-2.dsc to main/t/tinylaf/tinylaf_1.4.0-2.dsc tinylaf_1.4.0-2_all.deb to main/t/tinylaf/tinylaf_1.4.0-2_all.deb Override entries for your package: tinylaf_1.4.0-2.dsc - source utils tinylaf_1.4.0-2_all.deb - optional utils Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qy6bq-0005f8...@franck.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
Package: ca-certificates Version: 20110502 Severity: critical Tags: security Please see the following: https://bugzilla.mozilla.org/show_bug.cgi?id=682956 http://pastebin.com/ff7Yg663 http://pastebin.com/SwCZqskV (or just search current news for "DigiNotar", optionally in conjunction with "gmail" or "google".) Whatever resolution Mozilla and others end up with (revocation of the certificate or of the entire CA), ca-certificates will likely need to do the same. - Josh Triplett -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829210357.26233.13731.reportbug@leaf
Bug#639744: Followup from Mozilla
https://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/ Looks like Mozilla plans to disable the entire root for now. ca-certificates should follow suit. - Josh Triplett -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829232233.GA5667@leaf
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Monday 29 August 2011 16:03:57 Josh Triplett wrote: > Whatever resolution Mozilla and others end up with (revocation of the > certificate or of the entire CA), ca-certificates will likely need to > do the same. FWIW, individual certificates can't be "revoked" in ca-certificates. Shipping revocation lists is useless too. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201108292009.05392.geiss...@debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Mon, Aug 29, 2011 at 08:09:02PM -0500, Raphael Geissert wrote: > On Monday 29 August 2011 16:03:57 Josh Triplett wrote: > > Whatever resolution Mozilla and others end up with (revocation of the > > certificate or of the entire CA), ca-certificates will likely need to > > do the same. > > FWIW, individual certificates can't be "revoked" in ca-certificates. > Shipping revocation lists is useless too. Does OpenSSL not have any facility for a system-wide revocation list? Fortunately, in this case, the resolution involves disabling the DigiNotar Root CA entirely, which ca-certificates can do. - Josh Triplett -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110830011911.GA7304@leaf
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Monday 29 August 2011 20:19:11 Josh Triplett wrote: > Does OpenSSL not have any facility for a system-wide revocation list? No, I already checked that back when the Comodo hack occurred. Every application needs to manually load the revocation lists, just like they need to manually check the trust chain and all the other this-should-all-be- done-in-just-one-place things. (I only checked OpenSSL and GnuTLS, don't know about other implementations.) > Fortunately, in this case, the resolution involves disabling the > DigiNotar Root CA entirely, which ca-certificates can do. Yep, this case can nicely be handled by ca-certificates. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201108292032.42755.geiss...@debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Mon, Aug 29, 2011 at 08:32:40PM -0500, Raphael Geissert wrote: > On Monday 29 August 2011 20:19:11 Josh Triplett wrote: > > Does OpenSSL not have any facility for a system-wide revocation list? > > No, I already checked that back when the Comodo hack occurred. > Every application needs to manually load the revocation lists, just like they > need to manually check the trust chain and all the other this-should-all-be- > done-in-just-one-place things. I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a "revocation store" format, similar to a "certificate store", or would this need some special-purpose custom format? - Josh Triplett -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110830032426.GB7535@leaf
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote:
> On Mon, Aug 29, 2011 at 08:32:40PM -0500, Raphael Geissert wrote:
> > On Monday 29 August 2011 20:19:11 Josh Triplett wrote:
> > > Does OpenSSL not have any facility for a system-wide revocation
> list?
> >
> > No, I already checked that back when the Comodo hack occurred.
> > Every application needs to manually load the revocation lists, just
> like they
> > need to manually check the trust chain and all the other
> this-should-all-be-
> > done-in-just-one-place things.
>
> I understand that they'd have to manually load the lists, but perhaps
> it
> would make sense to standardize a location from which they should load
> them? Does OpenSSL or GnuTLS have any concept of a "revocation store"
> format, similar to a "certificate store", or would this need some
> special-purpose custom format?
And it'd be nice if nss could share that store...
nss apps are more or less starting to use a {/etc/,~/.}pki/nssdb/ which
can be shared accross apps (though I only know about evolution using it
right now).
By the way, shouldn't this bug be clone to libnss3-1d (and maybe
iceweasel and icedove if they ship the certificates themselves)?
Regards,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
