Bug#957265: marked as pending in geekcode
Control: tag -1 pending Hello, Bug #957265 in geekcode reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/eric/geekcode/-/commit/6259a7eb16066036c095c9fdc284453d0988db43 Merge branch 'master' into 'master' Add patch to fix FTBFS with GCC 10 (Closes: #957265) See merge request eric/geekcode!2 (this message was generated automatically) -- Greetings https://bugs.debian.org/957265
Bug#957265: marked as pending in geekcode
Control: tag -1 pending
Hello,
Bug #957265 in geekcode reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/eric/geekcode/-/commit/86608c7d02948ffce36ce009c0c6ba691e700a82
Add patch to fix FTBFS with GCC 10
Fix variable declarations in geekcode.{c,h}.
Closes: #957265
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/957265
Bug#965995: dnscrypt-proxy: Purging fails: rm: cannot remove '/etc/dnscrypt-proxy/dnscrypt-proxy.conf.dpkg-bak': Is a directory
* Axel Beckert (a...@debian.org) wrote: > Package: dnscrypt-proxy > Version: 2.0.44+ds1-2 > Severity: serious > X-Debbugs-Cc: Axel Beckert > > Purging dnscrypt-proxy fails for me as follows (and IIRC I never changed > anything from the default config, but the package might have a bit on > history on that machine): > > # dpkg --purge dnscrypt-proxy > (Reading database ... 1190427 files and directories currently installed.) > Purging configuration files for dnscrypt-proxy (2.0.44+ds1-2) ... > rm: cannot remove '/etc/dnscrypt-proxy/dnscrypt-proxy.conf.dpkg-bak': Is a > directory > dpkg: error processing package dnscrypt-proxy (--purge): > installed dnscrypt-proxy package post-removal script subprocess returned > error exit status 1 > Errors were encountered while processing: > dnscrypt-proxy > > Might be just a missing "-r" to "rm" in the postrm script or so. So this appears to be a bug related to a mess in the past where there was a /etc/dnscrypt-proxy/dnscrypt-proxy.conf directory created at some point. I'm using dpkg-maintscript-helper but it appears to failing on this edge case. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#884320: [pkg-opensc-maint] Bug#884320: upgrade error libp11-2 -> libp11-3
Control: tags -1 unreproducible I'm confused how this could be possible since on my machine I see: $ sudo dpkg -L libp11-3 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libp11.so.3.3.7 /usr/share /usr/share/doc /usr/share/doc/libp11-3 /usr/share/doc/libp11-3/changelog.Debian.gz /usr/share/doc/libp11-3/copyright /usr/lib/x86_64-linux-gnu/libp11.so.3 $ apt show libp11-3 Package: libp11-3 Version: 0.4.7-2 Priority: optional Section: libs Source: libp11 Maintainer: Debian OpenSC Maintainers Installed-Size: 79.9 kB Depends: libc6 (>= 2.14), libssl1.1 (>= 1.1.0) Homepage: https://github.com/OpenSC/libp11 Download-Size: 24.0 kB APT-Manual-Installed: no APT-Sources: http://ftp.us.debian.org/debian unstable/main amd64 Packages Description: pkcs#11 convenience library Libp11 is a library to simplify using smart cards via PKCS#11 modules. It was spun of the OpenSC project but can be used with any pkcs#11 module. * Matthias Klose (d...@debian.org) wrote: > Package: libp11-3 > Version: 0.4.7-2 > Severity: serious > Tags: sid buster > > missing breaks/replaces > > Unpacking libp11-3:amd64 (0.4.7-2) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ZbKGej/78-libp11-3_0.4.7-2_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/libp11.so.2.4.7', which is > also > in package libp11-2:amd64 0.4.7-1 > Preparing to unpack .../79-libp11-dev_0.4.7-2_amd64.deb ... > > ___ > pkg-opensc-maint mailing list > pkg-opensc-ma...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#875349: marked as pending
tag 875349 pending thanks Hello, Bug #875349 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=b76e48c --- commit b76e48c5f8f8339fae60a01398a45e962f75bebe Author: Eric Dorland Date: Mon Dec 11 00:43:49 2017 -0500 Rebuild against libssl 1.1 once again Closes: 875349 diff --git a/debian/changelog b/debian/changelog index 5836600..a623820 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +libp11 (0.4.7-2) unstable; urgency=medium + + * debian/control, debian/libengine-pkcs11-openssl.install, debian/rules: +Rebuild against libssl 1.1 once again. (Closes: #875349) + + -- + libp11 (0.4.7-1) unstable; urgency=medium * New upstream release.
Bug#859555: marked as pending
tag 859555 pending thanks Hello, Bug #859555 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-opensc/pkcs11-helper.git/commit/?id=1d80287 --- commit 1d802872df7230e64c9bbad92175a1a295cf468e Author: Eric Dorland Date: Sun Dec 3 16:55:55 2017 -0500 Recompile against libssl-dev Closes: 859555 diff --git a/debian/changelog b/debian/changelog index 56f8f5f..20a31d8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +pkcs11-helper (1.22-3) unstable; urgency=medium + + * debian/control: Recompile against libssl-dev. (Closes: #859555) + + -- + pkcs11-helper (1.22-2) unstable; urgency=medium * Retarget to unstable.
Bug#828471: marked as pending
tag 828471 pending thanks Hello, Bug #828471 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-opensc/opensc.git/commit/?id=11fe58b --- commit 11fe58b0790499bf14251c28a1f7f7630b8f38fb Author: Eric Dorland Date: Sun Nov 26 00:38:38 2017 -0500 Switch to openssl 1.1 Closes: 828471 diff --git a/debian/changelog b/debian/changelog index a4f0f89..e1ae07a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +opensc (0.17.0-2) unstable; urgency=medium + + * debian/control: Switch to openssl 1.1. (Closes: #828471) + + -- + opensc (0.17.0-1) unstable; urgency=medium * New upstream release.
Bug#846548: marked as pending
* Julien Cristau (jcris...@debian.org) wrote: > It's now through NEW. The next step would be an upload to sid, with > urgency=high, and an unblock request to the release.debian.org > pseudopackage. Thanks and done as you have seen. I'm guessing it's not worth it, but should we promote libp11 0.4.4-1 as well for version parity? > On 06/06/2017 02:26 AM, Eric Dorland wrote: > > OK, apologies for the delay (and I know we're getting down to the > > wire). I just uploaded libp11-openssl1.1 to experimental and of course > > it's in NEW. If this looks ok let me know what the next steps are if > > we want to try to get it into stretch. > > > > * Julien Cristau (jcris...@debian.org) wrote: > >> On 05/30/2017 07:16 AM, Eric Dorland wrote: > >>> * Julien Cristau (jcris...@debian.org) wrote: > >>>> On 05/29/2017 03:15 AM, Eric Dorland wrote: > >>>>> * Julien Cristau (jcris...@debian.org) wrote: > >>>>>> On Mon, May 22, 2017 at 03:42:57 +, Eric Dorland wrote: > >>>>>> > >>>>>>> tag 846548 pending > >>>>>>> thanks > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> Bug #846548 reported by you has been fixed in the Git repository. You > >>>>>>> can > >>>>>>> see the changelog below, and you can check the diff of the fix at: > >>>>>>> > >>>>>>> > >>>>>>> https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0 > >>>>>>> > >>>>>> So, erm. This seems like it would break using libengine-pkcs11-openssl > >>>>>> in an application using libssl1.0.2. As a SONAME bump it also seems > >>>>>> rather inappropriate during the freeze. > >>>>> > >>>>> That's a good point. I was trying to provide an alternative to the > >>>>> broken NMU that was going to be uploaded, but yes this will break > >>>>> applications built against libssl1.0.2. It does fix using this with > >>>>> the openssl tool however. > >>>>> > >>>> Right. > >>>> > >>>>>> I'm very interested in having this fixed in stretch so I can get the > >>>>>> secure-boot stuff working on ftp-master, but this doesn't look like the > >>>>>> way to go. Not to mention that you'd have to justify the bump from > >>>>>> 0.4.3 to 0.4.4. > >>>>>> > >>>>>> Can you explain your plans here? > >>>>> > >>>>> As you suggested in your followup, the way forward would appear to be > >>>>> to upload a new libp11 source package that builds against > >>>>> libssl1.0.2. I can also backport all of the changes to 0.4.3 and > >>>>> upload to testing-proposed-updates. Does that sound reasonable? > >>>>> > >>>> Having read through the 0.4.4 changes I think I'd be ok with getting > >>>> that in if you're confident. I guess the other question is should > >>>> libp11-dev come from the openssl1.1-using package or the > >>>> openssl1.0.2-using one. At this late stage I guess it's safer to stay > >>>> with 1.0.2, and have the libp11-openssl1.1 package (or however it's > >>>> called) only provide a libengine-pkcs11-openssl1.1 binary? > >>> > >>> OK, I like this plan. We should get the naming right going forward > >>> though for the libengine-pkcs11-openssl1.1 package. Is that how other > >>> packages are handling naming when they depend on a particular version > >>> of openssl? > >>> > >> I'm not sure, to be honest. I don't know if there are any other similar > >> cases right now. This package name wouldn't survive stretch in any > >> case, I guess? > >> > >>> I should be able to get fixed uploads to unstable in a couple of days. > >>> > >> Nice. Thanks. > >> > >> Cheers, > >> Julien > > > -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Bug#846548: marked as pending
OK, apologies for the delay (and I know we're getting down to the wire). I just uploaded libp11-openssl1.1 to experimental and of course it's in NEW. If this looks ok let me know what the next steps are if we want to try to get it into stretch. * Julien Cristau (jcris...@debian.org) wrote: > On 05/30/2017 07:16 AM, Eric Dorland wrote: > > * Julien Cristau (jcris...@debian.org) wrote: > >> On 05/29/2017 03:15 AM, Eric Dorland wrote: > >>> * Julien Cristau (jcris...@debian.org) wrote: > >>>> On Mon, May 22, 2017 at 03:42:57 +, Eric Dorland wrote: > >>>> > >>>>> tag 846548 pending > >>>>> thanks > >>>>> > >>>>> Hello, > >>>>> > >>>>> Bug #846548 reported by you has been fixed in the Git repository. You > >>>>> can > >>>>> see the changelog below, and you can check the diff of the fix at: > >>>>> > >>>>> > >>>>> https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0 > >>>>> > >>>> So, erm. This seems like it would break using libengine-pkcs11-openssl > >>>> in an application using libssl1.0.2. As a SONAME bump it also seems > >>>> rather inappropriate during the freeze. > >>> > >>> That's a good point. I was trying to provide an alternative to the > >>> broken NMU that was going to be uploaded, but yes this will break > >>> applications built against libssl1.0.2. It does fix using this with > >>> the openssl tool however. > >>> > >> Right. > >> > >>>> I'm very interested in having this fixed in stretch so I can get the > >>>> secure-boot stuff working on ftp-master, but this doesn't look like the > >>>> way to go. Not to mention that you'd have to justify the bump from > >>>> 0.4.3 to 0.4.4. > >>>> > >>>> Can you explain your plans here? > >>> > >>> As you suggested in your followup, the way forward would appear to be > >>> to upload a new libp11 source package that builds against > >>> libssl1.0.2. I can also backport all of the changes to 0.4.3 and > >>> upload to testing-proposed-updates. Does that sound reasonable? > >>> > >> Having read through the 0.4.4 changes I think I'd be ok with getting > >> that in if you're confident. I guess the other question is should > >> libp11-dev come from the openssl1.1-using package or the > >> openssl1.0.2-using one. At this late stage I guess it's safer to stay > >> with 1.0.2, and have the libp11-openssl1.1 package (or however it's > >> called) only provide a libengine-pkcs11-openssl1.1 binary? > > > > OK, I like this plan. We should get the naming right going forward > > though for the libengine-pkcs11-openssl1.1 package. Is that how other > > packages are handling naming when they depend on a particular version > > of openssl? > > > I'm not sure, to be honest. I don't know if there are any other similar > cases right now. This package name wouldn't survive stretch in any > case, I guess? > > > I should be able to get fixed uploads to unstable in a couple of days. > > > Nice. Thanks. > > Cheers, > Julien -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#846548: marked as pending
* Julien Cristau (jcris...@debian.org) wrote: [snip] > > OK, I like this plan. We should get the naming right going forward > > though for the libengine-pkcs11-openssl1.1 package. Is that how other > > packages are handling naming when they depend on a particular version > > of openssl? > > > I'm not sure, to be honest. I don't know if there are any other similar > cases right now. This package name wouldn't survive stretch in any > case, I guess? Well when openssl 1.2 comes out we might have this same problem again right? > > I should be able to get fixed uploads to unstable in a couple of days. > > > Nice. Thanks. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#846548: marked as pending
* Julien Cristau (jcris...@debian.org) wrote: > On 05/29/2017 03:15 AM, Eric Dorland wrote: > > * Julien Cristau (jcris...@debian.org) wrote: > >> On Mon, May 22, 2017 at 03:42:57 +, Eric Dorland wrote: > >> > >>> tag 846548 pending > >>> thanks > >>> > >>> Hello, > >>> > >>> Bug #846548 reported by you has been fixed in the Git repository. You can > >>> see the changelog below, and you can check the diff of the fix at: > >>> > >>> > >>> https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0 > >>> > >> So, erm. This seems like it would break using libengine-pkcs11-openssl > >> in an application using libssl1.0.2. As a SONAME bump it also seems > >> rather inappropriate during the freeze. > > > > That's a good point. I was trying to provide an alternative to the > > broken NMU that was going to be uploaded, but yes this will break > > applications built against libssl1.0.2. It does fix using this with > > the openssl tool however. > > > Right. > > >> I'm very interested in having this fixed in stretch so I can get the > >> secure-boot stuff working on ftp-master, but this doesn't look like the > >> way to go. Not to mention that you'd have to justify the bump from > >> 0.4.3 to 0.4.4. > >> > >> Can you explain your plans here? > > > > As you suggested in your followup, the way forward would appear to be > > to upload a new libp11 source package that builds against > > libssl1.0.2. I can also backport all of the changes to 0.4.3 and > > upload to testing-proposed-updates. Does that sound reasonable? > > > Having read through the 0.4.4 changes I think I'd be ok with getting > that in if you're confident. I guess the other question is should > libp11-dev come from the openssl1.1-using package or the > openssl1.0.2-using one. At this late stage I guess it's safer to stay > with 1.0.2, and have the libp11-openssl1.1 package (or however it's > called) only provide a libengine-pkcs11-openssl1.1 binary? OK, I like this plan. We should get the naming right going forward though for the libengine-pkcs11-openssl1.1 package. Is that how other packages are handling naming when they depend on a particular version of openssl? I should be able to get fixed uploads to unstable in a couple of days. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#846548: marked as pending
* Julien Cristau (jcris...@debian.org) wrote: > On Mon, May 22, 2017 at 03:42:57 +0000, Eric Dorland wrote: > > > tag 846548 pending > > thanks > > > > Hello, > > > > Bug #846548 reported by you has been fixed in the Git repository. You can > > see the changelog below, and you can check the diff of the fix at: > > > > https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0 > > > So, erm. This seems like it would break using libengine-pkcs11-openssl > in an application using libssl1.0.2. As a SONAME bump it also seems > rather inappropriate during the freeze. That's a good point. I was trying to provide an alternative to the broken NMU that was going to be uploaded, but yes this will break applications built against libssl1.0.2. It does fix using this with the openssl tool however. > I'm very interested in having this fixed in stretch so I can get the > secure-boot stuff working on ftp-master, but this doesn't look like the > way to go. Not to mention that you'd have to justify the bump from > 0.4.3 to 0.4.4. > > Can you explain your plans here? As you suggested in your followup, the way forward would appear to be to upload a new libp11 source package that builds against libssl1.0.2. I can also backport all of the changes to 0.4.3 and upload to testing-proposed-updates. Does that sound reasonable? -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Bug#846548: marked as pending
tag 846548 pending thanks Hello, Bug #846548 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0 --- commit e8d6da04fa3e0805c2cfeea4351f3c559b460882 Author: Eric Dorland Date: Thu May 18 00:26:24 2017 -0400 Rebuild against libssl 1.1 and fix the path to the engine directory Patch from Luke Faraone. Closes: 846548 diff --git a/debian/changelog b/debian/changelog index c2d6f4b..3540ceb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +libp11 (0.4.4-2) unstable; urgency=medium + + * debian/control, debian/libengine-pkcs11-openssl.install, debian/rules: +Patch from Luke Faraone to rebuild against libssl 1.1 and fix the path +to the engine directory. (Closes: #846548) + + -- Eric Dorland Thu, 18 May 2017 00:25:29 -0400 + libp11 (0.4.4-1) unstable; urgency=medium * New upstream release.
Bug#846548: [pkg-opensc-maint] Bug#846548: patch for #846548
Sorry for not getting back to this sooner. I've canceled this upload since it has the side-effect of breaking libp11 (ie it bumps it's soname). I think the way forward would be to make that bump and rebuild the only dependency (pam-p11) against it, but I'm not 100% sure pam-p11 compiles with openssl 1.1. I guess this plan will require release manager approval since it's rather a lot of changes. * Luke Faraone (l...@faraone.cc) wrote: > On Thu, 11 May 2017 20:33:41 -0700 Luke W Faraone wrote: > > On Thu, 11 May 2017 19:45:51 -0700 Luke W Faraone > > wrote: > > > Attached is a patch to fix the path to the engine directory, and moves > > > this library back to libssl-dev. (it isn't clear to me from changelog or > > > git log why the move to 1.1 was originally reverted) > > > > And of course, that patch was bogus. Attached is a orrected patch. I > > intend to upload this to DELAYED/5 once I have a chance to test on real > > hardware. > > Tested (attached) and uploaded accordingly. > > -- Luke > $ openssl req -engine pkcs11 -keyform engine -new -key > "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=[…];token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;type=private" > -out req.pem -text -x509 -subj '/CN=Luke Faraone' > engine "pkcs11" set. > No private keys found. > PKCS#11 token PIN: > cobalt:/tmp/tmp.1Pc1kTLqDp$ cat req.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > a7:78:4e:07:98:95:7d:95 > Signature Algorithm: sha256WithRSAEncryption > Issuer: CN = Luke Faraone > Validity > Not Before: May 13 20:07:39 2017 GMT > Not After : Jun 12 20:07:39 2017 GMT > Subject: CN = Luke Faraone > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > […] > -BEGIN CERTIFICATE- > […] > -END CERTIFICATE- > > ___ > pkg-opensc-maint mailing list > pkg-opensc-ma...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Bug#852039: marked as pending
tag 852039 pending thanks Hello, Bug #852039 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-opensc/pam-p11.git;a=commitdiff;h=31bdea0 --- commit 31bdea0cc7087a961eb6f9076f078895c06da8c6 Author: Eric Dorland Date: Wed Jan 25 01:09:20 2017 -0500 Read certs again on token login Thanks Sam Hartman. Closes: 852039 diff --git a/debian/changelog b/debian/changelog index bbaed78..f8d4a36 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +pam-p11 (0.1.5-7) unstable; urgency=medium + + * debian/patches/0002-Read-certs-again-on-token-login.patch: Read certs +again on token login. Thanks Sam Hartman. (Closes: #852039) + + -- Eric Dorland Wed, 25 Jan 2017 01:08:12 -0500 + pam-p11 (0.1.5-6) unstable; urgency=medium * debian/control: Explicit build-deps on libssl1.0-dev.
Bug#852039: [pkg-opensc-maint] Bug#852039: pam-p11: diff for NMU version 0.1.5-6.1
Hi Sam,
Thanks for the patch. I'll prepare an upload for it tomorrow if you
want to hold off for a bit.
* hartm...@debian.org (hartm...@debian.org) wrote:
> Control: tags 852039 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for pam-p11 (versioned as 0.1.5-6.1) and
> uploaded it to DELAYED/2day. I realize this is a small delay, but I want the
> changes to make it in before the freeze. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
> diff -Nru pam-p11-0.1.5/debian/changelog pam-p11-0.1.5/debian/changelog
> --- pam-p11-0.1.5/debian/changelog2016-12-10 20:32:54.0 -0500
> +++ pam-p11-0.1.5/debian/changelog2017-01-23 15:13:19.0 -0500
> @@ -1,3 +1,10 @@
> +pam-p11 (0.1.5-6.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Fix segfault after token login, Closes: #852039
> +
> + -- Sam Hartman Mon, 23 Jan 2017 15:13:19 -0500
> +
> pam-p11 (0.1.5-6) unstable; urgency=medium
>
>* debian/control: Explicit build-deps on libssl1.0-dev.
> diff -Nru pam-p11-0.1.5/debian/patches/reread_certs_on_token_login
> pam-p11-0.1.5/debian/patches/reread_certs_on_token_login
> --- pam-p11-0.1.5/debian/patches/reread_certs_on_token_login 1969-12-31
> 19:00:00.0 -0500
> +++ pam-p11-0.1.5/debian/patches/reread_certs_on_token_login 2017-01-20
> 17:23:43.0 -0500
> @@ -0,0 +1,40 @@
> +Index: pam-p11/src/pam_p11.c
> +===
> +--- pam-p11.orig/src/pam_p11.c
> pam-p11/src/pam_p11.c
> +@@ -56,6 +56,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + const char *user;
> + char *password;
> + char password_prompt[64];
> ++int loggedin = 0;
> +
> + struct pam_conv *conv;
> + struct pam_message msg;
> +@@ -119,7 +120,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + }
> +
> + /* get all certs */
> +-rv = PKCS11_enumerate_certs(slot->token, &certs, &ncerts);
> ++ cert_scan: rv = PKCS11_enumerate_certs(slot->token, &certs, &ncerts);
> + if (rv) {
> + pam_syslog(pamh, LOG_ERR, "PKCS11_enumerate_certs failed");
> + rv = PAM_AUTHINFO_UNAVAIL;
> +@@ -156,7 +157,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + goto out;
> + }
> +
> +-if (!slot->token->loginRequired)
> ++if (!slot->token->loginRequired ||loggedin)
> + goto loggedin;
> +
> + /* get password */
> +@@ -209,6 +210,9 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
> + goto out;
> + }
> +
> ++loggedin = 1;
> ++goto cert_scan;
> ++
> + loggedin:
> + /* get random bytes */
> + fd = open(RANDOM_SOURCE, O_RDONLY);
> diff -Nru pam-p11-0.1.5/debian/patches/series
> pam-p11-0.1.5/debian/patches/series
> --- pam-p11-0.1.5/debian/patches/series 2016-12-10 20:32:54.0
> -0500
> +++ pam-p11-0.1.5/debian/patches/series 2017-01-20 17:22:14.0
> -0500
> @@ -1 +1,2 @@
> 0001-Use-INSTALL-instead-of-libLTLIBRARIES_INSTALL.patch
> +reread_certs_on_token_login
>
> ___
> pkg-opensc-maint mailing list
> pkg-opensc-ma...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint
--
Eric Dorland
43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
signature.asc
Description: PGP signature
Bug#828506: marked as pending
tag 828506 pending thanks Hello, Bug #828506 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-opensc/pkcs11-helper.git;a=commitdiff;h=6f55e4d --- commit 6f55e4dc258a8c3b1685535c68b019e25d7cc5e5 Author: Eric Dorland Date: Fri Jan 6 17:35:49 2017 -0500 New upstream release Closes: 828506 diff --git a/debian/changelog b/debian/changelog index ec8993c..515dad2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +pkcs11-helper (1.11-7) unstable; urgency=medium + + * New upstream release. (Closes: #828506) + + -- Eric Dorland Fri, 06 Jan 2017 17:35:33 -0500 + pkcs11-helper (1.11-6) unstable; urgency=medium * debian/compat, debian/control, debian/rules: Upgrade to debhelper 10.
Bug#849631: dnscrypt-proxy 1.8.1-4 fails to start
Control: tags + moreinfo unreproducible I'm not seeing this on my system. If you upgrade what does your dnscrypt-proxy.socket, dnscrypt-proxy.service and /etc/dnscrypt-proxy/dnscrypt-proxy.conf files look like? * Perl (zer0.div...@yahoo.fr) wrote: > Package: dnscrypt-proxy > Version: 1.7.0+dfsg-1 > Severity: serious > Tags: upstream > Justification: serious > > Dear Maintainer, > >* What led up to the situation? >After upgrade dnscrypt-proxy, it wan't start anymore. >* What exactly did you do (or not do) that was effective (or > ineffective)? > Working as before. >* What was the outcome of this action? >dnscrypt-proxy.service and dnscrypt-proxy.socket stop working. >I get these output in journalctl: >Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Service >hold-off time over, scheduling restart. >Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Start >request repeated too quickly. >Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.socket: Unit >entered failed state. >Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Unit >entered failed state. >Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Failed >with result 'start-limit-hit'. > >And if I feed dnscrypt-proxy command with the configuration file, I >get in terminal: >Dec 28 22:13:01 debian dnscrypt-proxy[1694]: Wed Dec 28 22:13:01 2016 >[INFO] + DNS Security Extensions are supported >Dec 28 22:13:01 debian dnscrypt-proxy[1694]: Wed Dec 28 22:13:01 2016 >[INFO] + Provider supposedly doesn't keep logs >Dec 28 22:13:01 debian systemd[1]: dnscrypt-proxy.service: Service >hold-off time over, scheduling restart. > >* What outcome did you expect instead? >Running dnscrypt-proxy.service and dnscrypt-proxy.socket. > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (990, 'unstable'), (150, 'testing'), (100, 'stable'), (5, > 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages dnscrypt-proxy depends on: > ii adduser 3.115 > ii init-system-helpers 1.46 > ii libc62.24-8 > ii libltdl7 2.4.6-2 > ii libsodium18 1.0.11-1 > ii libsystemd0 232-8 > > dnscrypt-proxy recommends no packages. > > Versions of packages dnscrypt-proxy suggests: > ii resolvconf 1.79 > > -- Configuration Files: > /etc/default/dnscrypt-proxy changed: > DNSCRYPT_PROXY_LOCAL_ADDRESS=127.0.2.1:53 > DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.org-fr > DNSCRYPT_PROXY_OPTIONS="" > > /etc/dnscrypt-proxy/dnscrypt-proxy.conf changed: > ResolverName=dnscrypt.org-fr That equals sign looks problematic. > ResolversList /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv > Daemonize yes > PidFile /var/run/dnscrypt-proxy.pid > User _dnscrypt-proxy > LocalAddress 127.0.2.1:53 > EphemeralKeys yes > MaxActiveRequests 250 > LogFile /var/log/dnscrypt-proxy.log > LogLevel 7 > BlockIPv6 yes > > > -- no debconf information -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#846774: marked as pending
tag 846774 pending thanks Hello, Bug #846774 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-opensc/libp11.git;a=commitdiff;h=d970edf --- commit d970edfba87abbd49506aa2f2f6b4ab2c87d9abf Author: Eric Dorland Date: Tue Dec 6 00:01:41 2016 -0500 New upstream release Closes: 846774 diff --git a/debian/changelog b/debian/changelog index 86eb1e7..78c2e45 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +libp11 (0.4.3-1) unstable; urgency=medium + + * New upstream release. (Closes: #846774) + + -- + libp11 (0.4.2-1) unstable; urgency=medium * New upstream release.
Bug#840728: marked as pending
tag 840728 pending thanks Hello, Bug #840728 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-opensc/libp11.git;a=commitdiff;h=9e2a79f --- commit 9e2a79fb560f7d368c17ed31f972df11579fe852 Author: Eric Dorland Date: Sun Oct 23 15:05:38 2016 -0400 Use enginesexecdir instead of enginesdir, to work around install-exec-hook issues Closes: 840728 diff --git a/debian/changelog b/debian/changelog index 637c180..86eb1e7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,6 +3,10 @@ libp11 (0.4.2-1) unstable; urgency=medium * New upstream release. * debian/control, debian/libengine-pkcs11-openssl.install, debian/rules: Move libengine-pkcs11-openssl package here. + * +debian/patches/0001-Add-enginesexecdir-use-it-instead-of-enginesdir.patch: +Use enginesexecdir instead of enginesdir, to work around +install-exec-hook issues. (Closes: #840728) -- Eric Dorland Sun, 23 Oct 2016 01:13:29 -0400
Bug#823030: [pkg-opensc-maint] Bug#823030: Status
* José Luis González (jlgon...@ya.com) wrote: > On Sat, 30 Jul 2016 01:53:17 -0400 > Eric Dorland wrote: > > > Control: tags -1 moreinfo > > > > What software is breaking exactly? You should not need libopensc2, it > > was always an internal library. > > It's an external package, from Spain's ID card electronic signing > system. As far as I remember it depended on those packages. > > I managed to install the external packages with packages from stable. Is it actually linking against libopensc2? -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#823030: [pkg-opensc-maint] Bug#823030: Status
Control: tags -1 moreinfo What software is breaking exactly? You should not need libopensc2, it was always an internal library. * José Luis González (jlgon...@ya.com) wrote: > Hi, > > any news or feedback on this issue? > > Regards, > José > > ___ > pkg-opensc-maint mailing list > pkg-opensc-ma...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#815004: [pkg-opensc-maint] Bug#815004: libengine-pkcs11-openssl: Engine is installed at wrong location (sparc64 as well)
t;/lib64/libkrb5support.so.0", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
> statfs("/sys/fs/selinux", {f_type="SELINUX_MAGIC", f_bsize=4096,
> f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0,
> 0}, f_namelen=255, f_frsize=4096, f_flags=4128}) = 0
> statfs("/sys/fs/selinux", {f_type="SELINUX_MAGIC", f_bsize=4096,
> f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0,
> 0}, f_namelen=255, f_frsize=4096, f_flags=4128}) = 0
> access("/etc/selinux/config", F_OK) = 0
> access("/etc/system-fips", F_OK)= -1 ENOENT (No such file or
> directory)
> open("/etc/pki/tls/openssl.cnf", O_RDONLY) = 3
> open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib64/openssl/engines/libpkcs11.so", O_RDONLY|O_CLOEXEC) = 3
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libp11.so.2", O_RDONLY|O_CLOEXEC) = 3
> (pkcs11) pkcs11 engine
> open("/usr/lib64/p11-kit-proxy.so", O_RDONLY|O_CLOEXEC) = 3
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libffi.so.6", O_RDONLY|O_CLOEXEC) = 3
> open("/etc/pkcs11/pkcs11.conf", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
> such file or directory)
> open("/home/mator/.config/pkcs11/pkcs11.conf", O_RDONLY|O_CLOEXEC) =
> -1 ENOENT (No such file or directory)
> stat("/home/mator/.config/pkcs11/modules", 0x7ffc8a781f40) = -1 ENOENT
> (No such file or directory)
> stat("/etc/pkcs11/modules", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> open("/etc/pkcs11/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> stat("/etc/pkcs11/modules/..", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/etc/pkcs11/modules/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/usr/share/p11-kit/modules", {st_mode=S_IFDIR|0755,
> st_size=4096, ...}) = 0
> open("/usr/share/p11-kit/modules",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> stat("/usr/share/p11-kit/modules/..", {st_mode=S_IFDIR|0755,
> st_size=4096, ...}) = 0
> stat("/usr/share/p11-kit/modules/p11-kit-trust.module",
> {st_mode=S_IFREG|0644, st_size=693, ...}) = 0
> open("/usr/share/p11-kit/modules/p11-kit-trust.module", O_RDONLY|O_CLOEXEC) =
> 4
> stat("/usr/share/p11-kit/modules/.", {st_mode=S_IFDIR|0755,
> st_size=4096, ...}) = 0
> open("/usr/lib64/pkcs11/p11-kit-trust.so", O_RDONLY|O_CLOEXEC) = 3
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
> statfs("/selinux", 0x7ffc8a782050) = -1 ENOENT (No such file or
> directory)
> open("/proc/mounts", O_RDONLY) = 3
> open("/tmp/fficgaRwB", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
> unlink("/tmp/fficgaRwB")= 0
> [ available ]
> +++ exited with 0 +++
> [mator@node01 ~]$
>
> ___
> pkg-opensc-maint mailing list
> pkg-opensc-ma...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint
--
Eric Dorland
43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
signature.asc
Description: PGP signature
Bug#815004: marked as pending
tag 815004 pending thanks Hello, Bug #815004 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-opensc/engine-pkcs11.git;a=commitdiff;h=0f9adff --- commit 0f9adff289380caf2887276d6e979871dbe174ba Author: Eric Dorland Date: Tue Mar 15 01:15:40 2016 -0400 Install engine into the current openssl engine directory Closes: 815004 diff --git a/debian/changelog b/debian/changelog index 1996eb6..b22ae83 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +engine-pkcs11 (0.2.1-2) unstable; urgency=medium + + * debian/control, debian/rules, debian/libengine-pkcs11-openssl.install: +Install engine into the current openssl engine directory. (Closes: +#815004) + + -- + engine-pkcs11 (0.2.1-1) unstable; urgency=medium * New upstream release.
Bug#802118: [pkg-opensc-maint] Bug#802118: libengine-pkcs11-openssl: Functions to set static global data may cause memory leak.
* persmule (persm...@gmail.com) wrote: > Package: libengine-pkcs11-openssl > Version: 0.1.8-5 > Severity: grave > Tags: security > Justification: user security hole > > Dear Maintainer, > > Functions in src/engine_pkcs11.c to set static global data (set_module, > set_pin, get_pin and set_init_args) do not free memories pointed by the > corresponding pointers before assigning them to newly allocated > memories, which > may cause memory leaks if they are called more than once. > > The bugs related to set_module, set_pin and get_pin are fixed on > upstream, but > the one of set_init_args is not. Agreed that these are valid memory leaks but what's the security implication? This doesn't seem obviously exploitable. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
Bug#796863: libassa3.5-5v5 and libassa-3.5-5v5: error when trying to install together
* Riley Baird (bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch) wrote: > This is listed in the FTP master's cruft report, so if I'm correct, it > shouldn't be necessary to request a removal from unstable. Yeah and you have the right conflicts/replaces. I'm surprised it's complaining about this. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#788807: [gnome-shell-extension-redshift] Uninstallable with Gnome 3.16
shift";, > -"shell-version": [ "3.6", "3.8", "3.12" ], > +"shell-version": [ "3.6", "3.8", "3.12", "3.14", "3.16" ], > "settings-schema": "org.gnome.shell.extensions.redshift" > } > diff -Nru > gnome-shell-extension-redshift-0~20141101.git3091f6f/src/schemas/org.gnome.shell.extensions.redshift.gschema.xml > > gnome-shell-extension-redshift-0~20150616.git4648ad79/src/schemas/org.gnome.shell.extensions.redshift.gschema.xml > --- > gnome-shell-extension-redshift-0~20141101.git3091f6f/src/schemas/org.gnome.shell.extensions.redshift.gschema.xml > 2014-11-02 03:53:35.0 +0530 > +++ > gnome-shell-extension-redshift-0~20150616.git4648ad79/src/schemas/org.gnome.shell.extensions.redshift.gschema.xml > 2015-06-15 01:21:03.0 +0530 > @@ -4,7 +4,7 @@ > >true >Activate redshift mode. > - Wether redshift mode should currently be > active. > + Whether redshift mode should currently be > active. > > > -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#768927: opensc: OpenCT missing. Was removed in 760258
Control: severity -1 important * Cornelius Kölbel (co...@cornelinux.de) wrote: > Hi Eric, [snip] > Yes, but to my up-to-now-knowledge using pcscd and opensc is not enough. > As soon as we installed openct things worked fine. > I will ask the opensc guys. Did you have any luck making it work with pcscd? -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#768927: opensc: OpenCT missing. Was removed in 760258
* Cornelius Koelbel (co...@cornelinux.de) wrote: > Source: opensc > Version: 0.13 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > >* What led up to the situation? > > OpenSC is the "driver"/"middleware" for talking to smartcards. > It depends on OpenCT, which is the driver for the Card Terminals. > OpenCT is also maintained by the opensc project, which is now hosted > at github. > With bug #760258 openct was removed, so that opensc can not be used > anymore, since tools like the opensc-explorer do not find any card > terminal anymore. openct is basically dead upstream and I consulted with the opensc devs on its removal. >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Tried to run Aladdin eToken Pro 64K. It could not be found, due to > the missing openct package. The card terminal could not be found. Have you tried installing pcscd? I just realized there's no recommends on it which there probably should be. >* What was the outcome of this action? > > the card terminal software was not available. No card terminal / card > reader could be found, aladdin etoken could not be found and not be used. > >* What outcome did you expect instead? > > OpenSC needs to be available. OpenSC should contain a dependency on > OpenCT. OpenCT should be installable and the etoken should be accessed. -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#764292: [Pkg-gnupg-maint] Bug#764292: gnupg2: brings too many dependencies into standard task
G=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages gnupg2 depends on: > ii dpkg 1.17.13 > ii gnupg-agent 2.0.26-2 > ii install-info 5.2.0.dfsg.1-2 > ii libassuan0 2.1.1-1 > ii libbz2-1.0 1.0.6-5 > ii libc0.1 2.19-11 > ii libcurl3-gnutls 7.33.0-1 > ii libgcrypt20 1.6.2-3 > ii libgpg-error01.13-0.2 > ii libksba8 1.3.0-2 > ii libreadline6 6.2+dfsg-0.1 > ii zlib1g 1:1.2.8.dfsg-2 > > Versions of packages gnupg2 recommends: > ii libldap-2.4-2 2.4.31-1+nmu2+b1 > > Versions of packages gnupg2 suggests: > pn gnupg-doc > pn parcimonie > pn xloadimage > > -- no debconf information > > ___ > Pkg-gnupg-maint mailing list > pkg-gnupg-ma...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnupg-maint -- Eric Dorland 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#559783: Upping the severity
> > Increasing the severity since this prevents new uploads as it fails > > the embedded library check. > Hi, Eric! > cve-2009-3720 has closed long ago. > also upstream is dead (only security problems are fixed). > Do You have any other (not cve-2009-3720) causes to keep severity > serious? Yes, ftp master will not accept uploads due to the embedded libraries so it's effectively FTBFS. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#730846: gnupg2: FTBFS on mips, mipsel: gpg: Fatal: can't disable core dumps: Operation not permitted
Control: reassign -1 buildd.debian.org
Control: severity -1 important
Control: retitle -1 mips, mipsel buildds: Unable to disable core dumps
As pointed out by Bastian Blank in <20131104203044.ga17...@mail.waldi.eu.org>:
> Turns out it does fail. There seems to be a kernel bug that makes it
> fails if anything tries to set a value of RLIM_INFINITY:
>
> | getrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0
> | setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = -1
> | EPERM (Operation not permitted)
>
> Workaround is to also set the hard limit to a smaller value.
* Salvatore Bonaccorso (car...@debian.org) wrote:
> Hi Andreas,
>
> On Sat, Nov 30, 2013 at 08:04:22AM +0100, Andreas Beckmann wrote:
> > Package: gnupg2
> > Version: 2.0.22-1
> > Severity: serious
> > Justification: fails to build from source (but built successfully in the
> > past)
> >
> > Hi,
> >
> > gnupg FTBFS on mips*:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=mips&ver=2.0.22-1&stamp=1381015396
> >
> > [...]
>
> I'm not the maintainer, but just additional reference for this issues.
> See also [1] for followups with wb-team with this issue on mips*.
>
> [1] http://lists.debian.org/debian-wb-team/2013/11/msg0.html
>
> Regards,
> Salvatore
--
Eric Dorland
ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
Bug#730846: gnupg2: FTBFS on mips, mipsel: gpg: Fatal: can't disable core dumps: Operation not permitted
* Salvatore Bonaccorso (car...@debian.org) wrote: > Hi Andreas, > > On Sat, Nov 30, 2013 at 08:04:22AM +0100, Andreas Beckmann wrote: > > Package: gnupg2 > > Version: 2.0.22-1 > > Severity: serious > > Justification: fails to build from source (but built successfully in the > > past) > > > > Hi, > > > > gnupg FTBFS on mips*: > > > > https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=mips&ver=2.0.22-1&stamp=1381015396 > > > > [...] > > I'm not the maintainer, but just additional reference for this issues. > See also [1] for followups with wb-team with this issue on mips*. > > [1] http://lists.debian.org/debian-wb-team/2013/11/msg0.html Thanks Salvatore, I had not seen the two followups to this thread due to not being on debian-wb@. I think this is properly a buildd bug rather than a gnupg2 problem, so I'm going to reassign it. In the mean-time I'm going to disable the test-suite on mips and mipsel to temporarily work around the problem and get builds on those platforms going again. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#714567: working as intended
Control: tags -1 wontfix Control: notforwarded -1 This is working as intended and I don't believe it makes sense to remove this warning. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#725431: automake-1.14: FTBFS: Test failure in t/primary-prefix-invalid-couples.tap 280
Tags: patch Looks like it. fedora has a fix for it I think: http://pkgs.fedoraproject.org/cgit/automake.git/tree/automake-1.13.4-hash-order-workaround.patch?h=f20 I'll look at adding that patch this weekend. * Daniel Schepler (dschep...@gmail.com) wrote: > Source: automake-1.14 > Version: 1:1.14-1 > Severity: serious > > From my pbuilder build log: > > ... >dh_auto_test > make[1]: Entering directory `/tmp/buildd/automake-1.14-1.14' > make check-TESTS check-local > make[2]: Entering directory `/tmp/buildd/automake-1.14-1.14' > make[3]: Entering directory `/tmp/buildd/automake-1.14-1.14' > SKIP: t/get-sysconf.sh > XFAIL: t/pm/Cond2.pl > XFAIL: t/pm/Cond3.pl > ... > PASS: t/primary-prefix-invalid-couples.tap 278 - mismatched prefix/primary in > sysconf_HEADERS > PASS: t/primary-prefix-invalid-couples.tap 279 - automake error out on > mismatched prefix/primary couples > FAIL: t/primary-prefix-invalid-couples.tap 280 - ... and with the same > diagnostic of 'automake -a' > PASS: t/primary-prefix-valid-couples.sh > PASS: t/primary-prefix-couples-force-valid.sh > PASS: t/primary-prefix-couples-documented-valid.sh > ... > PASS: contrib/t/parallel-tests-html-recursive.sh > PASS: contrib/t/help-multilib.sh > PASS: contrib/t/multilib.sh > make[4]: Entering directory `/tmp/buildd/automake-1.14-1.14' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/tmp/buildd/automake-1.14-1.14' > > Testsuite summary for GNU Automake 1.14 > > # TOTAL: 3036 > # PASS: 2964 > # SKIP: 29 > # XFAIL: 42 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > See ./test-suite.log > Please report to bug-autom...@gnu.org > > make[3]: *** [test-suite.log] Error 1 > make[3]: Leaving directory `/tmp/buildd/automake-1.14-1.14' > make[2]: *** [check-TESTS] Error 2 > make[2]: Leaving directory `/tmp/buildd/automake-1.14-1.14' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/tmp/buildd/automake-1.14-1.14' > dh_auto_test: make -j1 check returned exit code 2 > make: *** [build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > Looking in the test log for the failed test, it looks like it's seeing > differences in the order of output lines. (Maybe the hash table overhaul > in Perl 5.18 is the cause of this?) -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#713320: FTBFS: automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
I did not look deeply but something in either your build or dh_autoreconf is setting -Werror on the automake invocation, which is not the default. I don't believe this is a bug in automake. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#714452: automake1.13: FTBFS: There seems to be no Makefile in this directory.
Hi Dmitrijs, Thanks for preparing a fix for this. I'm confused what changed to make this break. I used pbuilder to build the package initially with no problems. Did something about debhelper change to break this? * Benjamin Drung (bdr...@debian.org) wrote: > Package: automake1.13 > Version: automake1.13: FTBFS: There seems to be no Makefile in this directory. > Severity: serious > Justification: FTBFS on amd64 > > Hi, > > your package fails to build with pbuilder: > > I: Building the package > I: Running cd tmp/buildd/*/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" > dpkg-buildpackage -us -uc -rfakeroot > dpkg-buildpackage: source package automake1.13 > dpkg-buildpackage: source version 1:1.13.3-1 > dpkg-buildpackage: source changed by Eric Dorland > dpkg-source --before-build automake1.13-1.13.3 > dpkg-buildpackage: host architecture amd64 > fakeroot debian/rules clean > dh clean >dh_testdir >debian/rules override_dh_auto_clean > make[1]: Entering directory `/tmp/buildd/automake1.13-1.13.3' > dh_auto_clean > make[2]: Entering directory `/tmp/buildd/automake1.13-1.13.3' > GNUmakefile:23: There seems to be no Makefile in this directory. > GNUmakefile:24: You must run ./configure before running 'make'. > GNUmakefile:25: *** Fatal Error. Stop. > make[2]: Leaving directory `/tmp/buildd/automake1.13-1.13.3' > dh_auto_clean: make -j1 distclean returned exit code 2 > make[1]: *** [override_dh_auto_clean] Error 2 > make[1]: Leaving directory `/tmp/buildd/automake1.13-1.13.3' > make: *** [clean] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 > E: Failed autobuilding of package -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#697251: gnupg2: gnupg key import memory corruption
* Thijs Kinkhorst (th...@debian.org) wrote: > On Sun, January 6, 2013 06:38, Eric Dorland wrote: > > Gah. I went out of town for Saturday and Sunday. I meant to upload before > > I left today but forgot. I just tried to now but I can't seem to reach my > > main Debian machine. So I won't be able to upload before Sunday night > > Eastern USA time. So if anyone wants to build it from the diff and upload > > feel free. > > Doing so now. Much appreciated. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#697251: gnupg2: gnupg key import memory corruption
Gah. I went out of town for Saturday and Sunday. I meant to upload before I
left today but forgot. I just tried to now but I can't seem to reach my main
Debian machine. So I won't be able to upload before Sunday night Eastern USA
time. So if anyone wants to build it from the diff and upload feel free.
Nico Golde wrote:
>Hi,
>* Eric Dorland [2013-01-05 14:02]:
>> * Thijs Kinkhorst (th...@debian.org) wrote:
>> > On Fri, January 4, 2013 11:39, Thijs Kinkhorst wrote:
>> > > On Thu, January 3, 2013 04:19, Christoph Anton Mitterer wrote:
>> > >> This is a follow up for #697108 and CVE-2012-6085.
>> > >
>> > > Eric,
>> > >
>> > > Thanks for fixing this in unstable. Can you also provide an
>update for
>> > > stable-security? Let me know if you prefer that we handle it.
>> >
>> > As a heads up, I plan to work on DSA's for gnupg{,2} this weekend,
>I'll
>> > apply the patch from the unstable upload, unless you object.
>>
>> Attached is the debdiff for the stable security update. A little
>> bigger than one might want, but it wouldn't build with removing some
>> of this cruft. Let me know if it's ok and I'll upload it.
>
>I can live with that cruft, please go ahead and upload. Thanks!
>
>Nico
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#697251: gnupg2: gnupg key import memory corruption
* Thijs Kinkhorst (th...@debian.org) wrote: > On Thu, January 3, 2013 04:19, Christoph Anton Mitterer wrote: > > This is a follow up for #697108 and CVE-2012-6085. > > Eric, > > Thanks for fixing this in unstable. Can you also provide an update for > stable-security? Let me know if you prefer that we handle it. Sorry I meant to do both last night but it got late. I'll prepare and upload the stable-security update tonight. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#697251: gnupg2: gnupg key import memory corruption
Thanks for the heads up. Will get to it later today. * Christoph Anton Mitterer (cales...@scientia.net) wrote: > btw: The corresponding redhat bug[0] seems to already contain some > backported patches till 2.0.20 comes out. > > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6085 -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#689946: lat: Cannot open assembly '/usr/lib/lat/lat.exe': No such file or directory.
Thanks for the patch, I'm preparing an upload now. * gregor herrmann (gre...@debian.org) wrote: > Control: tag -1 + patch > > On Wed, 10 Oct 2012 05:10:39 +0900, Hideki Yamane wrote: > > > > $ lat > > > Cannot open assembly '/usr/lib/lat/lat.exe': No such file or directory. > > > > Because /usr/bin/lat specifies /usr/lib/lat/lat.exe in that file but > > lat package has /usr/lib/x86_64-linux-gnu/lat/lat.exe. > > > > > > $ cat lat/lat.in > > #!/bin/sh > > @MONO@ @MONO_FLAGS@ @prefix@/lib/lat/lat.exe "$@" > > > > /usr/bin/lat > > /usr/lib/x86_64-linux-gnu/lat/gnome-keyring-glue.dll > > /usr/lib/x86_64-linux-gnu/lat/gnome-keyring-glue.dll.config > > /usr/lib/x86_64-linux-gnu/lat/lat.exe > > /usr/lib/x86_64-linux-gnu/lat/plugins/ActiveDirectoryCoreViews.dll > > /usr/lib/x86_64-linux-gnu/lat/plugins/JpegAttributeViewer.dll > > /usr/lib/x86_64-linux-gnu/lat/plugins/PasswordAttributeViewer.dll > > /usr/lib/x86_64-linux-gnu/lat/plugins/PosixCoreViews.dll > > /usr/lib/x86_64-linux-gnu/pkgconfig/lat-plugins.pc > > And: > > Architecture: all > > And: > > E: lat: triplet-dir-and-architecture-mismatch usr/lib/x86_64-linux-gnu/ is > for amd64 > N: > N:This package contains a directory under /lib or /usr/lib which doesn't > N:match the proper triplet for the binary package's architecture. This is > N:very likely to be a mistake when indicating the underlying build system > N:where the files should be installed. > N: > N:Refer to Debian Policy Manual section 9.1.1 (File System Structure) for > N:details. > N: > N:Severity: serious, Certainty: possible > N: > N:Check: files, Type: binary, udeb > > > This can be fixed by passing "--libdir=/usr/lib" to dh_auto_configure > in debian/rules > > > But we also have: > > debian/rules: > include /usr/share/cli-common/cli.make > --> > /usr/share/cli-common/cli.make:4: WARNING: the use of > /usr/share/cli-common/cli.make is deprecated! Use dh $@ --with=cli instead. > and tons of: > dh_FOO: > Unknown option: with > > But "dh $@ --with=cli" alone doesn't fix the path issues. > > > I'm attaching my preliminary patch, but since I have no idea about > mono and not alot about multiarch, I leave this at this point. > > Cheers, > gregor > > diff -Nru lat-1.2.3/debian/changelog lat-1.2.3/debian/changelog > --- lat-1.2.3/debian/changelog2012-05-27 07:57:16.0 +0200 > +++ lat-1.2.3/debian/changelog2012-10-23 19:49:41.0 +0200 > @@ -1,3 +1,14 @@ > +lat (1.2.3-9.1) UNRELEASED; urgency=low > + > + * Non-maintainer upload. > + * Fix "Cannot open assembly '/usr/lib/lat/lat.exe': No such file or > +directory.": > +- pass "--libdir=/usr/lib" to dh_auto_configure in debian/rules > +- use "dh $@ --with=cli" in debian/rules. > +(Closes: #689946) > + > + -- gregor herrmann Tue, 23 Oct 2012 19:21:49 +0200 > + > lat (1.2.3-9) unstable; urgency=low > >* debian/control: Update homepage. (Closes: #656843) > diff -Nru lat-1.2.3/debian/rules lat-1.2.3/debian/rules > --- lat-1.2.3/debian/rules2012-05-27 07:57:16.00000 +0200 > +++ lat-1.2.3/debian/rules2012-10-23 19:48:49.0 +0200 > @@ -1,12 +1,10 @@ > #!/usr/bin/make -f > > -include /usr/share/cli-common/cli.make > - > %: > - dh $@ > + dh $@ --with=cli > > override_dh_auto_configure: > - dh_auto_configure -- MCS=/usr/bin/mono-csc > + dh_auto_configure -- MCS=/usr/bin/mono-csc --libdir=/usr/lib > > override_dh_auto_install: > dh_auto_install -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#668630: automake1.11: FTBFS under pbuilder: gettext-macros.test hangs
tags 668630 unreproducible thanks I build under pbuilder and I haven't seen this. Can you try rebuilding your pbuilder tarball? * Daniel Schepler (dschep...@gmail.com) wrote: > Source: automake1.11 > Version: 1:1.11.4-1 > Severity: serious > > From my pbuilder build log: > > ... > PASS: gcj.test > PASS: gcj2.test > PASS: gcj3.test > SKIP: gcj4.test > PASS: gcj5.test > SKIP: gcj6.test > > And the build process hangs here. "ps afuwwx" shows "/bin/sh ./gettext- > macros.test" spawning "/bin/sh /usr/bin/gettextize --force". strace on the > gettextize process shows it's stuck doing a "read(0, ". -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
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-users&m=126451730710129&w=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 ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#564652: fix build for freebsd
* Andreas Jellinghaus (a...@dungeon.inka.de) wrote: > Build-Conflicts: should handle this, right? > > patch attached. > > Andreas I'm confused now. The freebsd patch earlier in this thread seems to add a dependency on libusb2 for freebsd. Your patch adds a build conflict on libusb-dev. Are both necessary? -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#516780: /usr/lib/iceweasel/iceweasel: iceweasel crash confirmation
* William F. Dowling (william.dowl...@thomsonreuters.com) wrote: > Subject: /usr/lib/iceweasel/iceweasel: iceweasel crash confirmation > Followup-For: Bug #516780 > Package: iceweasel > Version: 3.0.9-1 > > *** Please type your report below this line *** > I am confirming this crash for version 3.0.9-1, running >iceweasel -safe-mode --sync Does it happen if you move your .mozilla director out of the way? -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#523300: Iceweasel Critical Crash Report
* Denis Combs (denisco...@googlemail.com) wrote: > Package: iceweasel > Version: 3.07 > Severity: critical > > > I was testing a web page with some JavaScript that I was in the process > of writing and was testing. The JavaScript included one or two 'alerts' > to test where I was in the script prior to any 'function' and there was > code to get elements by id. The code should have been called with the > body onload function, unfortunately I hadn't got to that point and was > calling it early. However the 'alert/s' appeared to crash iceweasel out > of hand. > > I include the GNomebug-buddy report below. Are you still seeing this in the latest iceweasel? -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#524501: Iceweasel crashes and the system freezes.
* Shams Fantar (sfan...@snurf.info) wrote: > Indeed, the system works fine and Iceweasel doesn't freeze without flash. > > This is always the same problem since longtime with Iceweasel and > flash... when a solution will be found ? soon ? or do we have to use > another browser to avoid that problem ? Which flashplugin are you using? The non-free adobe one? There isn't much to be done in that case, given that we can't change it. It shouldn't be able to freeze the system though. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#527640: opensc: insecure due to wrong public exponent
There's no need to prepare a stable update, since this only affects
version 0.11.7, which isn't in stable.
* Michael S. Gilbert (michael.s.gilb...@gmail.com) wrote:
> Package: opensc
> Severity: grave
> Tags: security
> Tags: patch
>
> Hi,
>
> There is a vulnerability in opensc. Details are:
>
> | The security problem in short: you need a combination of
> | 1.) a tool that startes a key generation with public exponent set to 1
> | (an invalid value that causes an insecure rsa key)
> | 2.) a PKCS#11 module that accepts that this public exponent and forwards
> | it to the card
> | 3.) a card that accepts the public exponent and generates the rsa key.
> |
> | OpenSC is insecure because due to a code bug in pkcs11-tool it had
> | the wrong public exponent. But OpenSC PKCS#11 module is secure, it
> | ignores the public exponent. So only if you generate your keys with
> | pkcs11-tool from OpenSC 0.11.7 (which very few people do), and only if
> | you used it with sone other vendors PKCS#11 module, and only if the
> | card accepted the bogus value too, then your rsa key is unsecure.
> |
> | you can easily verify keys by looking at the rsa public key or a
> | certificate or certificate request, for example the openssl command
> | line tools can print the content in plain text. public Exponent = 1
> | is bad (3 and higher are accepted values, 65537 or higher is suggested
> | by the NIST).
> |
> | Here is the full security advisory. No CVE included, as I was not able
> | to get one from distributions, vendor-sec or mitre.
> |
> | OpenSC Security Advisory [07-May-2009]
> | ==
> |
> | pkcs11-tool generates RSA keys with publicExponent 1 instead of 65537
> |
> | OpenSC includes a tool for testing its PKCS#11 module called
> | pkcs11-tool. This command line tool includes the ability to ask the
> | PKCS#11 module to generate an RSA key pair. The tool used to default to a
> key size
> | of 768 bits and a public exponent of 3. These values are considered
> | small but ok. In december 2008 a change (SVN commit 3602) changed
> | these values to more secure default values of 1024 bit key size
> | and a public exponent of 65537. A bug in that code however caused
> | the default public exponent to be 1. That value is invalid and
> | insecure, a message encrypted with it will be unencrypted.
> |
> | If pkcs11-tool is used with the PKCS#11 module included in OpenSC,
> | there is no security issue, as OpenSC PKCS#11 module ignores any
> | public exponent passed to it. Only when pkcs11-tool is used with
> | other third party PKCS#11 Modules the problem comes up.
> |
> | Thanks to Miquel Comas Martí, who found and fixed this bug and
> | contacted us on May 7th, 2009.
> |
> | This bug only affects users of OpenSC SVN trunk or OpenSC release
> | 0.11.7. Older releases do not contain this problem, and the new
> | OpenSC release 0.11.8 fixes this problem. Only users of the command
> | line tool "pkcs11-tool" are affected by this problem, and only the
> | generate rsa key pair function is affected ("--keypairgen" or "-k").
> | There is no option to configure the public exponent using the
> | command line tool, so all such uses are affected.
> |
> | The command line tool "pkcs11-tool" can be used with the OpenSC
> | PKCS#11 Module "opensc-pkcs11.so" or "opensc-pkcs11.dll" or with any
> | other PKCS#11 module. Only when used with other PKCS#11 module the
> | problem arrises, as the OpenSC PKCS#11 Module ignores the public
> | exponent passed to it.
> |
> | If you use a third party PKCS#11 Module with pkcs11-tool you
> | can use openssl with engine_pkcs11 to create a certificate
> | signing request and then use openssl to analyze that csr,
> | for example
> | openssl req -in req.pem -noout -text
> | ...
> | Exponent: 1 (0x1)
> | ...
> |
> | Would show the problem.
>
> Please coordinate with the security team (t...@security.debian.org)
> to prepare updates for the stable releases.
>
> A patch that fixes the problem follows:
> --- src/tools/pkcs11-tool.c (Revision 3687)
> +++ src/tools/pkcs11-tool.c (Revision 3688)
> @@ -1035,7 +1035,7 @@
> {
> CK_MECHANISM mechanism = {CKM_RSA_PKCS_KEY_PAIR_GEN, NULL_PTR,
> 0}; CK_ULONG modulusBits = 1024;
> - CK_BYTE publicExponent[] = { 65537 };
> + CK_BYTE publicExponent[] = { 0x01, 0x00, 0x01 }; /* 65537 in
> bytes */ CK_BBOOL _true = TRUE;
> CK_OBJECT_CLASS pubkey_class = CKO_PUBLIC_KEY;
> CK_OBJECT_CLASS privkey_class = CKO_PRIVATE_KEY;
>
>
--
Eric Dorland
ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
Bug#527239: [sqlfairy] missing dependency
This is fixed in 0.09004-2. * Davide Prina (davide.pr...@gmail.com) wrote: > Package: sqlfairy > Version: 0.09004-1 > > I have found that the problem is a missing dependency > > $ apt-file search Digest/SHA1.pm > libdigest-sha1-perl: /usr/lib/perl5/Digest/SHA1.pm > > # apt-get install libdigest-sha1-perl > > solve the problem > > Ciao > Davide > > --- System information. --- > Architecture: i386 > Kernel: Linux 2.6.26-customized > > Debian Release: squeeze/sid > 990 testing www.debian-multimedia.org > 990 testing security.debian.org > 990 testing ftp.it.debian.org > > --- Package information. --- > Depends(Version) | Installed > -+-== > perl | 5.10.0-19 > libsql-translator-perl (= 0.09004-1) | 0.09004-1 > libgraphviz-perl | 2.03-2 > > > Package's Recommends field is empty. > > Package's Suggests field is empty. > > > > -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#527353: GSS consistently fails with: Decrypt integrity check failed
* Sam Hartman (hartm...@debian.org) wrote:
> severity 527353 important
> tags 527353 moreinfo
> thanks
>
> "works for me" between two Debian systems. Can you please tell me the
> server software, and include klist -5e output after running ssh?
>
>
> If the server is Debian, make sure it is running the same version of
> libgssapi-krb5-2 and libkrb5-3 (assuming it has either of those
> packages)
Client is up2date unstable, and where I reported the bug.
Server is debian stable, running the heimdal kdc, version
1.2.dfsg.1-2.1. It doesn't have libgssapi-krb5-2 and libkrb5-3
installed.
I was running with the heimdal-clients on my box, so klist -5e didn't
work. I installed krb5-user instead and it still doesn't work. After
the ssh:
$ klist -5e
Ticket cache: FILE:/tmp/krb5cc_1000_uR9367
Default principal: e...@kuroneko.ca
Valid starting ExpiresService principal
05/07/09 20:06:50 05/08/09 20:03:02 krbtgt/kuroneko...@kuroneko.ca
Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC,
AES-256 CTS mode with 96-bit SHA-1 HMAC
--
Eric Dorland
ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
Bug#527353: GSS consistently fails with: Decrypt integrity check failed
Package: libgssapi-krb5-2 Version: 1.7dfsg~beta1-3 Severity: grave Happy to provide more diagnostics but not entirely certain where to look. The latest upgrade broke ssh and offlineimap. from ssh: debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Decrypt integrity check failed debug1: Unspecified GSS failure. Minor code may provide more information Decrypt integrity check failed debug1: Unspecified GSS failure. Minor code may provide more information from offlineimap: Account sync kuroneko: DEBUG[imap]: Unspecified GSS failure. Minor code may provide more information: Decrypt integrity check failed klist: Credentials cache: FILE:/tmp/krb5cc_1000_Il7029 Principal: e...@kuroneko.ca Issued Expires Principal May 7 02:05:44 May 7 12:02:03 krbtgt/kuroneko...@kuroneko.ca -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-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/bash Versions of packages libgssapi-krb5-2 depends on: ii libc62.9-10 GNU C Library: Shared libraries ii libcomerr2 1.41.5-1common error description library ii libk5crypto3 1.7dfsg~beta1-3 MIT Kerberos runtime libraries - C ii libkeyutils1 1.2-10 Linux Key Management Utilities (li ii libkrb5-31.7dfsg~beta1-3 MIT Kerberos runtime libraries ii libkrb5support0 1.7dfsg~beta1-3 MIT Kerberos runtime libraries - S libgssapi-krb5-2 recommends no packages. Versions of packages libgssapi-krb5-2 suggests: pn krb5-doc (no description available) pn krb5-user (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525167: 3.0.9 available (security update)
* Alberto (api2...@inwind.it) wrote: > > The version in Lenny is very up-to-date, thank you. > > (except for the new release today). > > Uhm... but the version is still 3.0.6. Is it updated > via xulrunnel? Just to avoid futher mistakes... The security fixes apply only to xulrunner. Also won't necessarily bump the version number if we don't do a sourceful upload. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#516944: iceweasel: Does not start up after upgrade from etch to lenny
* Steve Kostecke (st...@antoniuk.md) wrote: > Package: iceweasel > Version: 3.0.6-1 > Severity: grave > Justification: renders package unusable > > > I just upgraded an m68k system (MacMini) to Stable/Lenny and iceweasel > is no longer usable. Iceweasel-3 is considerable slower to load than > iceweasel-2 and it won't open 'about:config' or any web-pages. Local > files can be opened. The preferences dialog can be opened but is > _very_ sluggish. I think you mean powerpc and not m68k. Did you try the instructions in /usr/share/bug/iceweasel/presubj before submitting? > Unfortunately, Iceape is no-longer available in Stable/Lenny to be used > as an alternate browser. > > Error: [Exception... "Component returned failure code: > 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" > nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" > location: "JS frame :: file:///usr/lib/iceweasel/components/nsBrowserGlue.js > :: bg__initPlaces :: line 449" data: no] > Source File: file:///usr/lib/iceweasel/components/nsBrowserGlue.js > Line: 449 > > Error: formatURLPref: Couldn't get pref: startup.homepage_welcome_url > Source File: file:///usr/lib/iceweasel/xulrunner/components/nsURLFormatter.js > Line: 68 > > Error: uncaught exception: [Exception... "Component returned failure code: > 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" > nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" > location: "JS frame :: chrome://browser/content/search/search.xml > :: get_searchService :: line 145" data: no] > > Error: uncaught exception: [Exception... "Component returned failure code: > 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" > nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" > location: "JS frame :: chrome://browser/content/search/search.xml > :: initialize :: line 527" data: no] > > Error: uncaught exception: [Exception... "Component returned failure code: > 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDocShellHistory.useGlobalHistory]" > nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" > location: "JS frame :: chrome://browser/content/browser.js > :: prepareForStartup :: line 763" data: no] > > FWIW, free(1) on this system reports: > > total used free shared buffers cached > Mem:515352 377964 137388017172 292984 > -/+ buffers/cache:67808 447544 > Swap: 19531160 1953116 -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#503298: libengine-pkcs11-openssl: engine-pkcs11-0.1.4 fails in get_pin
* Cyril Brulebois ([EMAIL PROTECTED]) wrote:
> tag 503298 patch
> thanks
>
> Aron Griffis <[EMAIL PROTECTED]> (24/10/2008):
> > I reported this bug upstream over a year ago and it was finally fixed.
>
> Thanks for having done so. Could you please grab the source package,
> apply the attached patch, build it, and confirm it works fine for you?
> I'm no such medium to check by myself.
>
> Eric, would you like me to NMU it to fix this RC bug? If you prefer, you
> can of course scratch the NMU line, adjust the version and the trailer
> line and upload it yourself.
Thanks Cyril, I'll upload it tomorrow, no need to NMU.
> Some remarks:
> - I included the diff w/o any patch management system to keep the
>changes minimal (I could have used quilt otherwise).
> - I didn't use simple-patchsys.mk either, since it would have
>introduced a failure to build twice in a row, see #414305/#494254.
> - debian/rules should be including the rules include after all other
>class includes. But since no related bug got reported, I'm not
>touching that either.
> - I'm not bumping urgency so that it gets some bits of testing in
>unstable before having a chance to migrate.
>
> Hope this helps.
>
> Mraw,
> KiBi.
> diff -u engine-pkcs11-0.1.4/debian/changelog
> engine-pkcs11-0.1.4/debian/changelog
> --- engine-pkcs11-0.1.4/debian/changelog
> +++ engine-pkcs11-0.1.4/debian/changelog
> @@ -1,3 +1,14 @@
> +engine-pkcs11 (0.1.4-1.1) unstable; urgency=low
> +
> + * Non-maintainer upload.
> + * Backport revision 110 (upstream ticket #11) to fix failure to ask a
> +PIN, often rendering the smartcard locked: check for mycb not being
> +NULL before trying to dereference it, in src/engine_pkcs11.c's
> +get_pin(). Thanks to Aron Griffis for both Debian and upstream bug
> +reports (Closes: #503298).
> +
> + -- Cyril Brulebois <[EMAIL PROTECTED]> Tue, 04 Nov 2008 01:26:45 +0100
> +
> engine-pkcs11 (0.1.4-1) unstable; urgency=low
>
>* New upstream release.
> only in patch2:
> unchanged:
> --- engine-pkcs11-0.1.4.orig/src/engine_pkcs11.c
> +++ engine-pkcs11-0.1.4/src/engine_pkcs11.c
> @@ -105,7 +105,7 @@
> const char *prompt_info;
> } *mycb = callback_data;
>
> - if (mycb->password) {
> + if (mycb != NULL && mycb->password) {
> sc_pin = set_pin(mycb->password);
> return sc_pin;
> }
--
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Bug#497789: Fake?
* Luca Niccoli ([EMAIL PROTECTED]) wrote: > Look on Google for the name of the submitter. > I suspect we should consider this bug a deliberate fake. What makes you think so? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#490360: iceweasel: I also have this issue
* Enrique Ivers ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 3.0.1-1 > Followup-For: Bug #490360 > > I seem to get this issue when switching between virtual > desktops... but it also happens quite frequently when browsing to a > new site when I have multiple tabs open. I've also had it happen > once or twice when I just close a tab. > > Let me know if there is any way I can get more info for you. Does the fix suggested in the bug work for you? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#490963: iceweasel is not saving my bookmark changes
* Chip Salzenberg ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 3.0~rc2-2 > Severity: important > > I have disabled all extensions. Nevertheless, when I make changes to my > bookmarks - adding a new bookmark or even adding a new separator - those > changes are not saved when I quit and restart iceweasel. > > Strangely, one kind of change *is* saved: if I rearrange the order of > folders in my bookmark toolbar, the rearrangement is saved. What are the permissions on the files under ~/.mozilla/firefox? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#484270: bug #484270 iceweasel 3.0~b5-4 seg fault
* Michael Danziger ([EMAIL PROTECTED]) wrote: > Hi, > > I'm not such an expert linux user but it's pretty clear to me that I'm > suffering from this same bug. When called from the command line, > iceweasel returns "Segmentation fault" and it doesn't open. This > happened when I tried to upgrade early to 3 at rc1. I gave up and > downgraded back to 2.0.0.14. Now that it's in the sid repositories at > iceweasel_3.0~rc2-1 I automatically upgraded. > > The last guy who posted didn't post the open(...)=25 command so I > followed mine that far up. > > This is actually the first real bug that I've posted on (the packages > have been pretty good thusfar ;) ) so if I'm missing some vital > information, let me know, I'd be happy to supply it. Your straces look different. Yours seem to crashing inside libpango. Do you have pango-graphite installed perchance? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#484270: iceweasel 3.0~b5-4 seg fault
> [pid 20367] <... futex resumed> ) = ? ERESTART_RESTARTBLOCK (To be > restarted) > [pid 20366] +++ killed by SIGSEGV +++ > > Process 20366 detached > > [pid 20367] +++ killed by SIGSEGV +++ > > Process 20367 detached > > Process 20365 detached > > > I installed iceweasel-dbg but iceweasel -g finds no debugging symbols: > > # aptitude show iceweasel-dbg > Unable to find an archive "stable" for the package "iceweasel-dbg" > Package: iceweasel-dbg > New: yes > State: installed > Automatically installed: no > Version: 3.0~b5-4 > > $ iceweasel -g > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > (no debugging symbols found) > (gdb) set pagination off > (gdb) run > Starting program: /usr/lib/iceweasel/firefox-bin -a firefox > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > Error while reading shared library symbols: > Cannot find new threads: generic error > Cannot find new threads: generic error > (gdb) bt full > #0 0xb7fb0201 in _dl_debug_state () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0xb7fb3608 in ?? () from /lib/ld-linux.so.2 > No symbol table info available. > #2 0x in ?? () > No symbol table info available. > (gdb) q > The program is running. Exit anyway? (y or n) y > > > If I downgrade to 3.0~b5-3 it works normally again. > > Anything else I should try? > > Thanks, > Geoff > > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: i386 (i686) > > Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) > Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) > Shell: /bin/sh linked to /bin/bash > > Versions of packages iceweasel depends on: > ii debianutils 2.28.6 Miscellaneous utilities specific > t > ii fontconfig2.6.0-1generic font configuration > library > ii libc6 2.7-11 GNU C Library: Shared libraries > ii libgcc1 1:4.3.0-5 GCC support library > ii libglib2.0-0 2.16.3-2 The GLib library of C routines > ii libgtk2.0-0 2.12.9-4 The GTK+ graphical user > interface > ii libnspr4-0d 4.7.1-1NetScape Portable Runtime Library > ii libstdc++64.3.0-5The GNU Standard C++ Library v3 > ii procps1:3.2.7-8 /proc file system utilities > ii psmisc22.6-1 Utilities that use the proc > filesy > ii xulrunner-1.9 1.9~rc1-2 XUL + XPCOM application runner > > iceweasel recommends no packages. > > -- no debconf information > > -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#483397: iceweasel: latest xulrunner update leaves iceweasel broken
* Gábor Gombás ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 3.0~b5-4 > Severity: grave > Justification: renders package unusable > > > Hi, > > After upgrading xulrunner-1.9 I get the following when I want to run > iceweasel: > > $ iceweasel > Error: Platform version '1.9' is not compatible with > minVersion >= 1.9b5 > maxVersion <= 1.9b5 Did you upgrade to iceweasel 3.0rc1? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#473534: FTBFS: missing libdbus-glib-1-dev dependency?
forcemerge 472467 473534 forcemerge 472467 473535 forcemerge 472467 473538 thanks * Trent W. Buck ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 3.0~b4 > Severity: serious > Justification: no longer builds from source > > See attached transcript. Please don't file three separate bugs on what is basically the same issue. Please don't file duplicate bugs. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#469244: offlineimap issues "MYRIGHTS" command to servers which don't support it
Package: offlineimap
Version: 5.99.5
Severity: grave
Justification: renders package unusable
Something appears to have changed in .5 and I can no longer sync with my
dovecot imap server.
Thread 'Folder sync kuroneko[.]' terminated with exception:
Traceback (most recent call last):
File "/var/lib/python-support/python2.4/offlineimap/threadutil.py", line 153,
in run
Thread.run(self)
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "/var/lib/python-support/python2.4/offlineimap/accounts.py", line 247,
in syncfolder
localfolder.syncmessagesto(statusfolder, [remotefolder, statusfolder])
File "/var/lib/python-support/python2.4/offlineimap/folder/Base.py", line
396, in syncmessagesto
self.syncmessagesto_flags(dest, applyto)
File "/var/lib/python-support/python2.4/offlineimap/folder/Base.py", line
373, in syncmessagesto_flags
object.addmessagesflags(addflaglist[flag], [flag])
File "/var/lib/python-support/python2.4/offlineimap/folder/IMAP.py", line
351, in addmessagesflags
self.addmessagesflags_noconvert(uidlist, flags)
File "/var/lib/python-support/python2.4/offlineimap/folder/IMAP.py", line
345, in addmessagesflags_noconvert
self.processmessagesflags('+', uidlist, flags)
File "/var/lib/python-support/python2.4/offlineimap/folder/IMAP.py", line
372, in processmessagesflags
myrights = imapobj.myrights(self.getfullname())[1][0].split()[1]
File "/usr/lib/python2.4/imaplib.py", line 534, in myrights
typ,dat = self._simple_command('MYRIGHTS', mailbox)
File "/usr/lib/python2.4/imaplib.py", line 1028, in _simple_command
return self._command_complete(name, self._command(name, *args))
File "/usr/lib/python2.4/imaplib.py", line 865, in _command_complete
raise self.error('%s command error: %s %s' % (name, typ, data))
error: MYRIGHTS command error: BAD ['Error in IMAP command MYRIGHTS: Unknown
command.']
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-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/bash
Versions of packages offlineimap depends on:
ii python2.4.4-6An interactive high-level object-o
ii python-support0.7.6 automated rebuilding support for p
offlineimap recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451327: iceweasel: a running FF/IW steals new local and remote FF/IW instances
forcemerge 229547 451327 thanks * Paolo ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: N/A > Severity: grave > > Seems that at some point, Mozilla has introduced a 'feature' that fixed the > 'another instance of ... already running' issue, so that if you start another > instance of FF it won't complain, but simply it'd open another window of the > already running instance. > So far so good. > The bad news is that this happens with FF launched on a remote system as well, > which is *not* what's supposed to happen. > Here's a scenario: > > L. local system: Sarge - stock FF1.5.0.12, FF2.0.0.8, SM1.1.5, Debian's FF. > R. remote system: Etch - same as above, except Debian's FF->IW . > > 1. On L, ssh -X into R > 2.1. On L, start FF - any version > 3.1 On R, start FF - any version: the window comes up surprisingly fast; > problem is, that's just another window of the locally running FF! ie > if FF1.5 is running on L, then 'iceweasel' on R opens FF1.5 again. > > The converse is also true: > > 2.2 On R, start IW (or FF/SM) > 3.2 On L, start FF (or SM): what you get is another window of the remote > IW/FF/SM. > > FF/SM fails to check if the running instance on current $DISPLAY belong to > same host+binary it's being started from. > This has some obvious, and perhaps some not so obvious, security issues. Please don't file duplicate bugs. What precisely are the security risks? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#443454: icedove
* Alexander Sack ([EMAIL PROTECTED]) wrote: > On Sat, Oct 06, 2007 at 04:58:17PM -0400, Eric Dorland wrote: > > Hi Alexander, > > > > Are you available to make a release of icedove, or would you like me > > to take care of it this weekend? > > > > * Jan Christoph Uhde ([EMAIL PROTECTED]) wrote: > > > Hi Eric, > > > would you please take a look at icedove's bug #443454 and support > > > Alexander Sack or patch the package an do a non maintainer update:) > > > People really appreciate a working thunderbird:) > > > > > > Thanks for your time and your work at the debian project. > > I plan to do that on Sunday. Cool, thanks. -- 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
Bug#443454: icedove
Hi Alexander, Are you available to make a release of icedove, or would you like me to take care of it this weekend? * Jan Christoph Uhde ([EMAIL PROTECTED]) wrote: > Hi Eric, > would you please take a look at icedove's bug #443454 and support Alexander > Sack or patch the package an do a non maintainer update:) People really > appreciate a working thunderbird:) > > Thanks for your time and your work at the debian project. > > Best regards! > Jan -- 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
Bug#412053: uim-xim: Makes other applications bug when using non-ascii characters.
reassign 412053 uim forcemerge 426221 412053 thanks So it looks like the consensus was this is uim's fault. Reassigning and merging. * Charles Plessy ([EMAIL PROTECTED]) wrote: > Package: uim-xim > Version: 1:1.2.1-9 > Severity: important > > Dear uim, nautilus and iceweasel maintainers, > > I was suffering of iceweasel crashing (#412053) and nautilus refusing > the input of tilde characters on the right half of filenames (#422758), > and thanks to the sagacity of readers of debian-user-french, I think > that found a common denominator: uim-xim. > > I think that the problem is similar to the following scim bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348893 > > Basically, strange things happen when inputting non-ASCII characters > through uim-xim, especially symbols and accented characters. I checked > the behaviour of Nautilus with japanese characters, and it seems that > they trigger the same problem as other non-ascii characters. > > Surprisingly, out of two machines, the bug only affects fresh Etch installs. I > figured out that uim-anthy is not called the same way on both systems (I use > im-swich). > > NO CRASH: (upgrade from Sarge) > - > > XIM=uim > XIM_PROGRAM=/usr/bin/uim-xim > XIM_ARGS= > GTK_IM_MODULE=uim > ENGINE=anthy > > if [ -r "$HOME/.uim" ]; then > TMPFILE=$(mktemp) || exit 1 > if [ "$(grep "; IM-SWITCH VALUE" $HOME/.uim)" ]; then > sed "s/(define default-im-name '[^)]*) ; IM-SWITCH VALUE/(define > default-im-name '$ENGINE) ; IM-SWITCH VALUE/" < $HOME/.uim > $TMPFILE > else > cat $HOME/.uim > $TMPFILE > if [ "$(grep -E "^\(define[[:space:]]+default-im-name[[:space:]]" > $HOME/.uim)" ]; then > echo "; (define default-im-name '$ENGINE) ; IM-SWITCH VALUE" >> $TMPFILE > else > echo "(define default-im-name '$ENGINE) ; IM-SWITCH VALUE" >> $TMPFILE > fi > fi > mv $TMPFILE $HOME/.uim > else > echo "(define default-im-name '$ENGINE) ; IM-SWITCH VALUE" > $HOME/.uim > fi > > > CRASHES: (fresh Etch) > > > # UIM with GTK systray indicator > XIM=uim > XIM_PROGRAM=/usr/bin/uim-xim > XIM_ARGS= > GTK_IM_MODULE=xim > QT_IM_MODULE=xim > # It seems to me that the system needs to be initialized. > # Folowing trick will wait 10 seconds without slowing down X start up. > XIM_PROGRAM_XTRA="(sleep 10; uim-toolbar-gtk-systray)" > DEPENDS="uim-xim,uim-gtk2.0|uim-qt,uim-anthy|uim-canna|uim-prime|uim-skk|uim-m17nlib" -- 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
Bug#429052: iceweasel: mailcap entry makes user more vulnerable to Mozilla bug 230606
severity 429052 important thanks Since upstream does not consider this a critical bug, I don't think we should either. Some sort of warning to the user would be good though, I agree. I could take iceweasel out of mailcap, but this might annoy more than this exploit is a threat. A stripping script would work I suppose, but would probably be surprising to the user. Ccing pkg-mozilla-maintainer, do you guys have any opinions? * Vincent Lefevre ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 2.0.0.4-1 > Severity: grave > Tags: security > Justification: user security hole > > The default /etc/mailcap entry makes iceweasel to be called directly > to view HTML files with a "file://" URL. Due to Mozilla bug 230606 > (or 382637, on which the attached example is based), data readable > by the user can be sent to a remote web server. > > For instance, on my machine, after saving the attached mail file and > removing my personal ~/.mailcap file (to use Debian's): > > $ mutt -f exploit-file > > I type 'v', down, enter to view the attached exploit-file.html file > with Iceweasel. /var/log/apache2/error.log now contains: > > [Fri Jun 15 17:45:11 2007] [error] [client 127.0.0.1] File does not exist: > /var/www/vin > > This example just provides the hostname (value of /etc/hostname) to > the local web server, but one can provide more private information > (such as the contents of the user's .ssh/id_rsa or the contents of > /etc/passwd) to any remote web server (this needs a bit more JavaScript > to transform the data into a URL, though). > > A possible fix is to pass the data first to a wrapper that will clean > up the HTML file (i.e. remove scripts), or, if one wants to still have > the possibility to run scripts, store the file to some place where a > "http://localhost/..."; URL can be used (the user must have a local web > server installed). -- 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
Bug#437289: FTBFS(alpha): wrong type argument to unary exclamation mark
forwarded 437289 https://bugs.g10code.com/gnupg/issue822
thanks
* Falk Hueffner ([EMAIL PROTECTED]) wrote:
> Package: gnupg2
> Version: 2.0.5-1
> Severity: serious
> Justification: no longer builds from source
>
> [...]
> gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl
> -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\""
> -DGNUPG_LIBEXECDIR="\"/usr/lib/gnupg2\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\""
> -DGNUPG_DATADIR="\"/usr/share/gnupg\""
> -DGNUPG_SYSCONFDIR="\"/usr/etc/gnupg\"" -I/usr/include
> -DWITHOUT_GNU_PTH=1 -Wall -g -O2 -Wall -Wcast-align -Wshadow
> -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security
> -Wno-pointer-sign -Wpointer-arith -MT libcommon_a-estream-printf.o -MD -MP
> -MF .deps/libcommon_a-estream-printf.Tpo -c -o libcommon_a-estream-printf.o
> `test -f 'estream-printf.c' || echo './'`estream-printf.c
> estream-printf.c: In function 'read_values':
> estream-printf.c:711: error: wrong type argument to unary exclamation mark
> make[3]: *** [libcommon_a-estream-printf.o] Error 1
> make[3]: Leaving directory `/build/buildd/gnupg2-2.0.5/common'
> [...]
>
> Full log at
> http://buildd.debian.org/fetch.cgi?&pkg=gnupg2&ver=2.0.5-1&arch=alpha&stamp=1186626239&file=log
>
> The reason is
>
> static int read_values (valueitem_t valuetable, size_t valuetable_len,
> va_list vaargs) {
> [...]
> if (!vaargs)
>
> "!vaargs" simply doesn't make any sense, I have no idea what it is
> supposed to do. It just happens to compile on many architectures,
> where va_list is a pointer.
Thanks for the report. I've filed a bug upstream, and they tend to be
fairly responsive.
--
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
Bug#425194: appears to need libcairo2.0-cil to sucessfully be used
Package: libgtk2.0-cil Version: 2.10.0-2 Severity: serious I got the following error when building my lat package. My mono isn't superb but it looks like it's complaining that gtk-sharp needs cairo to be present. And indeed adding libcairo2.0-cil to my build dependencies does the trick. But it sounds like they would be better off in yours. ** (/usr/lib/mono/2.0/gmcs.exe:27041): WARNING **: The following assembly referenced from /usr/lib/mono/gac/gdk-sharp/2.10.0.0__35e10195dab3c99f/gdk-sharp.dll could not be loaded: Assembly: Mono.Cairo(assemblyref_index=2) Version:1.0.5000.0 Public Key: 0738eb9f132ed756 The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0). ** (/usr/lib/mono/2.0/gmcs.exe:27041): WARNING **: Could not load file or assembly 'Mono.Cairo, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. Stacktrace: at (wrapper managed-to-native) System.Reflection.MonoMethodInfo.get_method_info (intptr,System.Reflection.MonoMethodInfo&) <0x4> at (wrapper managed-to-native) System.Reflection.MonoMethodInfo.get_method_info (intptr,System.Reflection.MonoMethodInfo&) <0x> at System.Reflection.MonoMethod.get_Attributes () <0x00025> at System.Reflection.MethodBase.get_IsVirtual () <0xc> at Mono.CSharp.MemberCache.AddMethods (System.Reflection.BindingFlags,System.Type) <0x001a4> at Mono.CSharp.MemberCache.AddMethods (System.Type) <0x0002b> at Mono.CSharp.MemberCache..ctor (Mono.CSharp.IMemberContainer) <0x00164> at Mono.CSharp.TypeHandle..ctor (System.Type) <0x0013f> at Mono.CSharp.TypeHandle.GetTypeHandle (System.Type) <0x0004e> at Mono.CSharp.TypeHandle.GetMemberCache (System.Type) <0xb> at Mono.CSharp.TypeManager.MemberLookup_FindMembers (System.Type,System.Reflection.MemberTypes,System.Reflection.BindingFlags,string,bool&) <0x0022a> at Mono.CSharp.TypeManager.RealMemberLookup (System.Type,System.Type,System.Type,System.Reflection.MemberTypes,System.Reflection.BindingFlags,string,System.Collections.IList) <0x00192> at Mono.CSharp.TypeManager.MemberLookup (System.Type,System.Type,System.Type,System.Reflection.MemberTypes,System.Reflection.BindingFlags,string,System.Collections.IList) <0x0001f> at Mono.CSharp.Expression.MemberLookup (System.Type,System.Type,System.Type,string,System.Reflection.MemberTypes,System.Reflection.BindingFlags,Mono.CSharp.Location) <0x00061> at Mono.CSharp.Expression.MemberLookup (System.Type,System.Type,System.Type,string,Mono.CSharp.Location) <0x0001d> at Mono.CSharp.MemberAccess.DoResolve (Mono.CSharp.EmitContext,Mono.CSharp.Expression) <0x002dc> at Mono.CSharp.MemberAccess.DoResolve (Mono.CSharp.EmitContext) <0xf> at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext,Mono.CSharp.ResolveFlags) <0x00142> at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext) <0x00012> at Mono.CSharp.Argument.Resolve (Mono.CSharp.EmitContext,Mono.CSharp.Location) <0x00051> at Mono.CSharp.Invocation.DoResolve (Mono.CSharp.EmitContext) <0x00215> at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext,Mono.CSharp.ResolveFlags) <0x00142> at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext) <0x00012> at Mono.CSharp.ExpressionStatement.ResolveStatement (Mono.CSharp.EmitContext) <0x00016> at Mono.CSharp.StatementExpression.Resolve (Mono.CSharp.EmitContext) <0x0001f> at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext) <0x001ef> at Mono.CSharp.Try.Resolve (Mono.CSharp.EmitContext) <0x00094> at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext) <0x001ef> at Mono.CSharp.EmitContext.ResolveTopBlock (Mono.CSharp.EmitContext,Mono.CSharp.ToplevelBlock,Mono.CSharp.Parameters,Mono.CSharp.IMethodData,bool&) <0x0018a> at Mono.CSharp.EmitContext.EmitTopBlock (Mono.CSharp.IMethodData,Mono.CSharp.ToplevelBlock) <0x00048> at Mono.CSharp.MethodData.Emit (Mono.CSharp.DeclSpace) <0x00162> at Mono.CSharp.Method.Emit () <0x00017> at Mono.CSharp.TypeContainer.EmitType () <0x002e9> at Mono.CSharp.RootContext.EmitCode () <0x00206> at Mono.CSharp.Driver.MainDriver (string[]) <0x00a55> at Mono.CSharp.Driver.Main (string[]) <0x00055> at (wrapper runtime-invoke) System.Object.runtime_invoke_int_string[] (object,intptr,intptr,intptr) <0x> Native stacktrace: /usr/bin/mono [0x81880c0] /usr/bin/mono [0x816ad89] [0x4001d440] [0x40ed3b29] [0x411ea3ae] [0x411ea365] [0x411e9d65] [0x411e9b84] [0x411e9795] [0x411e9600] [0x411e947f] [0x411e93ac] [0x412017d3] [0x412011db] [0x41201028] [0x41200cba] [0x4120f0be] [0x4120e245] [0x4120df50] [0x412008db] [0x4120071b] [0x412004f2] [0x4121bfe6]
Bug#411919: Acknowledgement (iceweasel: lost all settings after upgrade)
* Beno?t Dejean ([EMAIL PROTECTED]) wrote: > Le dimanche 25 février 2007 à 01:34 -0500, Eric Dorland a écrit : > > * Beno?t Dejean ([EMAIL PROTECTED]) wrote: > > > Le mercredi 21 février 2007 à 16:46 -0500, Eric Dorland a écrit : > > > > forcemerge 411493 411919 > > > > thanks > > > > > > > > * Beno?t Dejean ([EMAIL PROTECTED]) wrote: > > > > > I now understand what happened. > > > > > > > > > > Iceweasel now looks for .mozilla/iceweasel where it was looking > > > > > for .mozilla/firefox. I had many dirt in .mozilla. So i have replaced > > > > > the newly empty created .mozilla/iceweasel by my old > > > > > .mozilla/firefox. > > > > I have upgraded today and it happened again. > > > We are now back to .mozilla/firefox, right ? > > > > Yes, are you certain it's still happening? > > on my first upgrade, i had to move .mozilla/firefox > to .mozilla/iceweasel. > on second upgrade to 2.0.0.1+dfsg-4, i had to move > back .mozilla/iceweasel to .mozilla/firefox > > I don't know if storing the profile in .mozilla/iceweasel was a mistake > or not. Now, it is back to the point it was before the 2 latest > upgrades. It was a mistake. -- 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
Bug#411919: Acknowledgement (iceweasel: lost all settings after upgrade)
* Beno?t Dejean ([EMAIL PROTECTED]) wrote: > Le mercredi 21 février 2007 à 16:46 -0500, Eric Dorland a écrit : > > forcemerge 411493 411919 > > thanks > > > > * Beno?t Dejean ([EMAIL PROTECTED]) wrote: > > > I now understand what happened. > > > > > > Iceweasel now looks for .mozilla/iceweasel where it was looking > > > for .mozilla/firefox. I had many dirt in .mozilla. So i have replaced > > > the newly empty created .mozilla/iceweasel by my old .mozilla/firefox. > > > > > > My full profile is back. > > > > > > This is a non trivial migration for common user that upgrades. > > > > This has been fixed in 2.0.0.1+dfsg-4. > > I have upgraded today and it happened again. > We are now back to .mozilla/firefox, right ? Yes, are you certain it's still happening? -- 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
Bug#411919: Acknowledgement (iceweasel: lost all settings after upgrade)
forcemerge 411493 411919 thanks * Beno?t Dejean ([EMAIL PROTECTED]) wrote: > I now understand what happened. > > Iceweasel now looks for .mozilla/iceweasel where it was looking > for .mozilla/firefox. I had many dirt in .mozilla. So i have replaced > the newly empty created .mozilla/iceweasel by my old .mozilla/firefox. > > My full profile is back. > > This is a non trivial migration for common user that upgrades. This has been fixed in 2.0.0.1+dfsg-4. -- 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
Bug#411505: Bug#411483: Bug#411475: Unfortunate issues
Ok, I have a potential patch in SVN, could someone build and test it, I'm not in a good position to do that tonight. * Eric Dorland ([EMAIL PROTECTED]) wrote: > * Mike Hommey ([EMAIL PROTECTED]) wrote: > > On Mon, Feb 19, 2007 at 05:48:45PM -0500, Eric Dorland <[EMAIL PROTECTED]> > > wrote: > > > * Mike Hommey ([EMAIL PROTECTED]) wrote: > > > > merge 411475 411479 411483 411493 411505 411531 > > > > severity 411475 serious > > > > thanks > > > > > > > > Hi, > > > > > > > > These issues are, as far as I can see, all from the same origin: the fix > > > > for bug #408883. This is very unfortunate, and I see the following > > > > choices to solve the issue: > > > > > > I'm shocked that this change had all these negative side effects. > > > > > > > - Hack the profile manager so that it tries to use the firefox profile > > > > if it exists, like it already does with very old profiles that were in > > > > ~/.firefox. > > > > > > This is probably a good idea in any case. > > > > The downside of this is that if people create a profile with iceweasel > > and later try firefox, the profile won't be shared. > > Good point. > > > > > - Hack the profile manager so that it doesn't display "Firefox" but > > > > "Iceweasel", without involving a modification of the nsXREAppData like > > > > has been done in the fix for #408883. > > > > > > Basically the problem is that the name field in nsXREAppData is > > > overloaded. There should be a display name field in that struct for > > > this situation. I think I'll work on a fix from that approach. > > > > ... or the other way around: a "profile directory base" field. By > > default, this is .$vendor/$product (both $vendor and $product being > > lowered-case). When there is no $vendor, it's on .$product. > > This rule also applies to xulrunner applications, so we have to think > > about something that will still work when firefox will be based on > > xulrunner... > > Well how would that be different? There's also other things that use > this name field in non display ways. > -- 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
Bug#411493: Bug#411475: Unfortunate issues
* Mike Hommey ([EMAIL PROTECTED]) wrote: > On Mon, Feb 19, 2007 at 05:48:45PM -0500, Eric Dorland <[EMAIL PROTECTED]> > wrote: > > * Mike Hommey ([EMAIL PROTECTED]) wrote: > > > merge 411475 411479 411483 411493 411505 411531 > > > severity 411475 serious > > > thanks > > > > > > Hi, > > > > > > These issues are, as far as I can see, all from the same origin: the fix > > > for bug #408883. This is very unfortunate, and I see the following > > > choices to solve the issue: > > > > I'm shocked that this change had all these negative side effects. > > > > > - Hack the profile manager so that it tries to use the firefox profile > > > if it exists, like it already does with very old profiles that were in > > > ~/.firefox. > > > > This is probably a good idea in any case. > > The downside of this is that if people create a profile with iceweasel > and later try firefox, the profile won't be shared. Good point. > > > - Hack the profile manager so that it doesn't display "Firefox" but > > > "Iceweasel", without involving a modification of the nsXREAppData like > > > has been done in the fix for #408883. > > > > Basically the problem is that the name field in nsXREAppData is > > overloaded. There should be a display name field in that struct for > > this situation. I think I'll work on a fix from that approach. > > ... or the other way around: a "profile directory base" field. By > default, this is .$vendor/$product (both $vendor and $product being > lowered-case). When there is no $vendor, it's on .$product. > This rule also applies to xulrunner applications, so we have to think > about something that will still work when firefox will be based on > xulrunner... Well how would that be different? There's also other things that use this name field in non display ways. -- 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
Bug#411531: Bug#411475: Unfortunate issues
* Mike Hommey ([EMAIL PROTECTED]) wrote: > merge 411475 411479 411483 411493 411505 411531 > severity 411475 serious > thanks > > Hi, > > These issues are, as far as I can see, all from the same origin: the fix > for bug #408883. This is very unfortunate, and I see the following > choices to solve the issue: I'm shocked that this change had all these negative side effects. > - Hack the profile manager so that it tries to use the firefox profile > if it exists, like it already does with very old profiles that were in > ~/.firefox. This is probably a good idea in any case. > - Hack the profile manager so that it doesn't display "Firefox" but > "Iceweasel", without involving a modification of the nsXREAppData like > has been done in the fix for #408883. Basically the problem is that the name field in nsXREAppData is overloaded. There should be a display name field in that struct for this situation. I think I'll work on a fix from that approach. -- 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
Bug#411192: CVE-2007-0981: serious cookie-stealing vulnerability
tags 411192 pending thanks * Kees Cook ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 2.0.0.1+dfsg-2 > Severity: grave > Tags: security, fixed-upstream, patch > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0981 says: > > "Mozilla based browsers allows remote attackers to bypass the same > origin policy, steal cookies, and conduct other attacks by writing a URI > with a null byte to the hostname (location.hostname) DOM property, due > to interactions with DNS resolver code." > > Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=370445 > Upstream patch: https://bugzilla.mozilla.org/attachment.cgi?id=255252 Thanks, patch is applied and I will try to roll out a build 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
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
Bug#399785: iceweasel eats all cpu while displaying about:
severity 399785 important tags 399785 unreproducible thanks * Wilfried Goesgens ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 2.0+dfsg-1 > Severity: grave > Justification: renders package unusable > > I just updated to iceweasel. > Two points. My menubar is empty. No menus. nada. > i entered about: in the url to check the version, nothing happened aside of > iceweasel eating all cpu. > I use littlefirefox theme from Alfred Kayser. I'm certainly not seeing this, and neither are most people it seems. Do you have any extensions installed? Have you tried moving your profile directory out of the way? -- 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
Bug#399949: iceweasel: NoScript plugin will make bookmarks disfunctional.
severity 399949 normal tags 399949 unreproducible thanks * Wilfried Goesgens ([EMAIL PROTECTED]) wrote: > Package: iceweasel > Version: 2.0+dfsg-1 > Severity: grave > Justification: renders package unusable > > NoScript limits Javascript enabledness to a whitelist. > After the update no clicking on the bookmark menu will open a page. > Clicking the home button works. > turning off NoScript for a site won't work anymore, because of the menu won't > open > on clicking on the Noscript-Button on the footline. > After disabling noscript and restarting iceweasel bookmarks work again. Noscript is working fine for me. Did you update to it's latest version? -- 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
Bug#399656: about:iceweasel still shows "firefox"
severity 399656 normal thanks * Michael Gilbert ([EMAIL PROTECTED]) wrote: > severity 399656 serious > thank you > > this bug is a serious policy violation because the term "firefox" > itself is now non-free. Uh, no. The term is trademarked, but that's not necessarily a problem. The fox logo is non-free, but it's not present. -- 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
Bug#397845: vsound: diff for NMU version 0.6-4.1
tags 397845 + patch thanks Hi, Attached is the diff for my vsound 0.6-4.1 NMU. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 diff -u vsound-0.6/debian/control vsound-0.6/debian/control --- vsound-0.6/debian/control +++ vsound-0.6/debian/control @@ -2,7 +2,7 @@ Section: sound Priority: optional Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]> -Build-Depends: debmake, sox, autotools-dev, devscripts, automake +Build-Depends: debmake, sox, autotools-dev, devscripts, automake1.4 Standards-Version: 3.6.1 Package: vsound diff -u vsound-0.6/debian/changelog vsound-0.6/debian/changelog --- vsound-0.6/debian/changelog +++ vsound-0.6/debian/changelog @@ -1,3 +1,11 @@ +vsound (0.6-4.1) unstable; urgency=high + + * NMU. + * debian/changelog: Build depend on automake1.4 instead +automake. (Closes: #397845) + + -- Eric Dorland <[EMAIL PROTECTED]> Sun, 12 Nov 2006 23:13:26 -0500 + vsound (0.6-4) unstable; urgency=low * Added a note in README.Debian about conflict between -t @@ -97,3 +105 @@ -Local variables: -mode: debian-changelog -End: + signature.asc Description: Digital signature
Bug#397843: tcpstat: diff for NMU version 1.4-4.2
tags 397843 + patch thanks Hi, Attached is the diff for my tcpstat 1.4-4.2 NMU. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 diff -u tcpstat-1.4/debian/control tcpstat-1.4/debian/control --- tcpstat-1.4/debian/control +++ tcpstat-1.4/debian/control @@ -1,6 +1,6 @@ Source: tcpstat Section: net -Build-Depends: libpcap-dev, autoconf, debhelper, automake +Build-Depends: libpcap-dev, autoconf, debhelper, automake1.4 Priority: extra Maintainer: Will Lowe <[EMAIL PROTECTED]> Standards-Version: 3.5.0.0 diff -u tcpstat-1.4/debian/changelog tcpstat-1.4/debian/changelog --- tcpstat-1.4/debian/changelog +++ tcpstat-1.4/debian/changelog @@ -1,3 +1,11 @@ +tcpstat (1.4-4.2) unstable; urgency=low + + * NMU. + * debian/control: Build depend on automake1.4 instead of +automake. (Closes: #397843) + + -- Eric Dorland <[EMAIL PROTECTED]> Sun, 12 Nov 2006 22:48:11 -0500 + tcpstat (1.4-4.1) unstable; urgency=low * Non maintainer upload @@ -37,6 +44,0 @@ - -Local variables: -mode: debian-changelog -add-log-mailing-address: "[EMAIL PROTECTED]" -add-log-full-name: "Will Lowe" -End: signature.asc Description: Digital signature
Bug#376655: lufs: diff for NMU version 0.9.7-8.1
tags 376655 + patch thanks Hi, Attached is the diff for my lufs 0.9.7-8.1 NMU. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 diff -u lufs-0.9.7/debian/changelog lufs-0.9.7/debian/changelog --- lufs-0.9.7/debian/changelog +++ lufs-0.9.7/debian/changelog @@ -1,3 +1,10 @@ +lufs (0.9.7-8.1) unstable; urgency=high + + * debian/control: Update automake build dependency to +automake1.4. (Closes: #376655) + + -- Eric Dorland <[EMAIL PROTECTED]> Sun, 12 Nov 2006 22:26:59 -0500 + lufs (0.9.7-8) unstable; urgency=low * debian/control: Remove unnecessary autotool dependencies (closes: #376655) diff -u lufs-0.9.7/debian/control lufs-0.9.7/debian/control --- lufs-0.9.7/debian/control +++ lufs-0.9.7/debian/control @@ -2,7 +2,7 @@ Section: misc Priority: optional Maintainer: Eduard Bloch <[EMAIL PROTECTED]> -Build-Depends: debhelper (>> 4.0.0), bzip2, automake, dpatch, autotools-dev, libtool +Build-Depends: debhelper (>> 4.0.0), bzip2, automake1.4, dpatch, autotools-dev, libtool Standards-Version: 3.7.2 Package: lufs-utils signature.asc Description: Digital signature
Bug#396731: need to depend on automake1.4
Package: bitcollider Version: 0.4.0-3 Followup-For: Bug #396731 The automake maintainer is working towards reclaiming the automake package name, which currently rests on automake1.4, the oldest version of automake. Your package Build-Depends on automake, hence this bug report. Please see http://wiki.debian.org/AutomakeTransition for more information on this transition. You need to switch the build dependency on automake to automake1.4. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394900: firefox: Another error now... :-/
* Nicolas ([EMAIL PROTECTED]) wrote: > Package: firefox > Followup-For: Bug #394900 > > > Now, I get another error. I don't understand why those errors appear suddenly. > :-/ Can you run a memtest to make sure your hardware isn't flaky? Do you have any other machines you can reproduce this on? -- 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
Bug#394402: fireflier_1.1.6-2+b2(hppa/unstable): FTBFS: bad build-depends
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Sun, Oct 22, 2006 at 11:09:45PM -0400, Eric Dorland wrote: > > > > A full build log can be found at: > > > > http://buildd.debian.org/build.php?arch=hppa&pkg=fireflier&ver=1.1.6-2+b2 > > > > Well, at least automake1.4 is frozen now, so this isn't an RC > > > problem > > > for etch... > > > > Eric, why are you making this change in a package that's been frozen? Why > > > does the changelog claim that there is a "new automake package", when this > > > package is not in the archive and doesn't appear to be in NEW? > > > I hadn't even been aware automake1.4 was frozen or that it was part of > > toolchain-source. I guess I should have been paying better attention. > > Well, this was mentioned in > <http://lists.debian.org/debian-devel-announce/2006/09/msg00020.html> -- I > had to double-check that we really did send something out covering this :) You didn't expect me to read that whole email did you? It was really long :P > > The automake1.10 source package in NEW contains the new automake > > package. This is all part of my diabolical plan lightly documented on > > http://wiki.debian.org/AutomakeTransition, and I did send some mail > > out outlining this to -devel or -release or both months ago. I went > > through and NMUed almost every package that had a build dependency on > > automake about a month ago, so either fireflier's dependency is new > > (for shame) or I somehow missed it in my sweep (shame on me). > > FWIW, I find a total of 5 packages still in unstable with a build-depend on > 'automake' with no alternatives, and 4 packages that build-depend on > automake as an alternative to automake1.4 or automake1.7, which means > they're likely to FTBFS with automake 1.10 after this update. (2 more > build-depend on automake1.9 | automake, so have a fair chance of still > working with automake 1.10.) > > I do remember the discussion of the automake transition, but transitions > like that need to either be finished completely before the freeze starts, or > they need to be done in such a way that they don't cause us more > release-critical bugs when we're trying to push a release out the door. I > recognize the advantage of getting "automake" switched off of 1.4 sooner > rather than later, so I think it'd be ok to push this change through if you > take care of all of the reverse-deps first. I was indeed doing it in a way to not cause more RC bugs. I filed wishlist bugs against all packages that i found to still have these build-dependencies and NMUed almost all of them. There were 3 remaining by my count, but they either had FTBFS bugs so NMUing was difficult or the maintainer told me don't touch, they would take care of it. I need to double check those again to see if they're still having problems. Since fireflier is obviously the 4th package, what is the 5th you noticed? I'm glad you agree this would be a good thing to go into etch. I'll work on sorting out the remaining issues 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
Bug#394900: firefox: Firefox regularly crashes - g_slice_alloc () from /usr/lib/libglib-2.0.so.0
* Nicolas ([EMAIL PROTECTED]) wrote: > Package: firefox > Version: 1.5.dfsg+1.5.0.7-2 > Severity: grave > Justification: renders package unusable > > > Hello, > > Since a few days, firefox regularly crashes (each 2-3 minutes!). I ran firefox > -g, and here's the output: Do you have any plugins or extensions installed? What happens if you run firefox with -safe-mode? -- 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
Bug#394402: fireflier_1.1.6-2+b2(hppa/unstable): FTBFS: bad build-depends
* Steve Langasek ([EMAIL PROTECTED]) wrote: > tags 394402 sid > thanks > > On Fri, Oct 20, 2006 at 10:00:29PM -0600, [EMAIL PROTECTED] wrote: > > There was an error while trying to autobuild your package: > > > > Automatic build of fireflier_1.1.6-2+b2 on peri by sbuild/hppa 85 > > > Build started at 20061020-1604 > > > [...] > > > > ** Using build dependencies supplied by package: > > > Build-Depends: debhelper (>> 3.0.0), iptables-dev, libpam0g-dev, > > > libssl-dev, libqt3-mt-dev, automake, autoconf, libtool, pkg-config, > > > libgtkmm2.0-dev, g++, m4, kdelibs4-dev, libxml2-dev, libgconf2-dev > > > [...] > > > > Building dependency tree... > > > Package automake is not available, but is referred to by another package. > > > This may mean that the package is missing, has been obsoleted, or > > > is only available from another source > > > However the following packages replace it: > > > automake1.4 > > > E: Package automake has no installation candidate apt-get failed. > > > A full build log can be found at: > > http://buildd.debian.org/build.php?arch=hppa&pkg=fireflier&ver=1.1.6-2+b2 > > Well, at least automake1.4 is frozen now, so this isn't an RC problem > for etch... > > Eric, why are you making this change in a package that's been frozen? Why > does the changelog claim that there is a "new automake package", when this > package is not in the archive and doesn't appear to be in NEW? I hadn't even been aware automake1.4 was frozen or that it was part of toolchain-source. I guess I should have been paying better attention. The automake1.10 source package in NEW contains the new automake package. This is all part of my diabolical plan lightly documented on http://wiki.debian.org/AutomakeTransition, and I did send some mail out outlining this to -devel or -release or both months ago. I went through and NMUed almost every package that had a build dependency on automake about a month ago, so either fireflier's dependency is new (for shame) or I somehow missed it in my sweep (shame on me). -- 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
Bug#354622: Is the bug fixed for Firefox too?
reopen 354622 reassign 354622 firefox thanks * Francesco Poli ([EMAIL PROTECTED]) wrote: > Hi! > > The BTS seems to consider this bug as closed, but the upload that > closed it seems to only concern thunderbird (which has been renamed as > "icedove"). > > Has firefox been renamed too? > Or should the bug be reopened and reassigned to firefox? Not yet, and indeed it should. -- 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
Bug#354622: Using Firefox as the app name without official branding is still a trademark violation
* Mike Connor ([EMAIL PROTECTED]) wrote: > > >>To my knowledge, Debian isn't including "extra" security fixes over > >>and above what we're shipping. If they are, that would possibly be > >>considered an act of bad faith between downstream and upstream, > >>unless the security bug was Debian specific. This type of potential > >>"Firefox from foo is better than Firefox from bar" comparison is > >>something we have explicitly avoided. > > > >As pointed out many times, we've had to backport security fixes > >ourselves into 1.0.4 because security support has dropped for the 1.0 > >branch. So whether that's "extra" or not, I don't know. Even if we > >added a security patch that the original version didn't have I don't > >see how we could act in bad faith. Even if we somehow neglected to > >file a bug report on it, it's not like we could hide the fact that we > >had added the patch from you. > > Backporting security fixes from newer releases is not really "extra" > in my mind. It'd be fixing stuff that isn't fixed elsewhere without > discussing it with us. > > The argument for fixing upstream is that by taking a fix for a bug > that's unpatched upstream, you will call attention to that potential > exploit, and thus put non-Debian users at risk. The problem is > exponentially worse if we don't know the issue exists and thus don't > know we need to fix it. If that's not malicious, its at least > irresponsible, in my opinion. Well on the one hand if there's a patch available to fix a security issue that I can get my hands on, I probably won't wait until the official release from Mozilla to apply the fix. If I can get my hands on it, that means umpteen many people can too, so I would see no point in delaying even if it does draw attention to the vulnerability. On the other hand if somehow I was privy to a vulnerability that upstream wasn't, of course I would report it. I'm a good citizen in this community as I'm sure nearly all of Debian is. But my point was even if I didn't (eg, hit by a bus, had dental surgery, was mad at you because you ran over my puppy or merely because I forgot) I couldn't actually hide the fact that I did it effectively. It's all out in the open, so I don't see how I could be accused of bad faith or irresponsibility. -- 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
Bug#354622: Renaming Mozilla applications
* Mike Hommey ([EMAIL PROTECTED]) wrote: > On Mon, Oct 02, 2006 at 03:33:15AM -0700, Steve Langasek wrote: > > > Well having transition packages would definitely be part of the plan, > > > so that shouldn't be an issue. > > > > FWIW, I don't see any substantial difference between a package named > > "firefox" that is a transition package, and one that contains the browser > > software. If one is determined to infringe a trademark, why would the other > > not? > > The trademark infringement is when providing something that is called firefox > but that is not quite firefox, but still calls itself firefox. > Providing a transition package so that users are able to get what we want to > provide them as an alternative to firefox is a different situation : it is > providing something that is called firefox, that is empty and installs > something else that is called iceweasel and calls itself iceweasel. Where is > the trademark infringement ? I can still write "firefox is shit" and not > infringe any trademark. Exactly. If the package is called firefox then it can be perceived as claiming it is firefox. If we provide an empty package called firefox to ease the upgrade to iceweasel or what have you, it just looks like we're providing an upgrade path from firefox to the new package. -- 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
Bug#354622: Using Firefox as the app name without official branding is still a trademark violation
* Mike Connor ([EMAIL PROTECTED]) wrote: > On 2-Oct-06, at 2:02 AM, Conrad Knauer wrote: > > >On 10/1/06, Eric Dorland <[EMAIL PROTECTED]> wrote: > > > >>> http://www.mozilla.org/foundation/trademarks/community-edition- > >>policy.html > >>> > >>> One of the permitted changes is "Porting the software to > >>different operating systems" > >> > >>I'm not sure that's what that clause really means, but one easy > >>example is backported security fixes. Another is just regular bug > >>fixes that aren't in the official releases for whatever reason. > > > >Personally I would say that Debian packages with extra security and > >bug fixes would 'exceed the quality' of the official Mozilla packages > >and thus be a good example of what Community Editions are about: > > To my knowledge, Debian isn't including "extra" security fixes over > and above what we're shipping. If they are, that would possibly be > considered an act of bad faith between downstream and upstream, > unless the security bug was Debian specific. This type of potential > "Firefox from foo is better than Firefox from bar" comparison is > something we have explicitly avoided. As pointed out many times, we've had to backport security fixes ourselves into 1.0.4 because security support has dropped for the 1.0 branch. So whether that's "extra" or not, I don't know. Even if we added a security patch that the original version didn't have I don't see how we could act in bad faith. Even if we somehow neglected to file a bug report on it, it's not like we could hide the fact that we had added the patch from you. > The Community Editions policy is possibly unclear, but it's really > talking about porting to BeOS or SkyOS or some other unsupported OS. > There is no provision for patching the source code otherwise. -- 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
Bug#354622: Using Firefox as the app name without official branding is still a trademark violation
* Conrad Knauer ([EMAIL PROTECTED]) wrote: > On 10/1/06, Eric Dorland <[EMAIL PROTECTED]> wrote: > > >> > >http://www.mozilla.org/foundation/trademarks/community-edition-policy.html > >> > >> One of the permitted changes is "Porting the software to different > >operating systems" > > > >I'm not sure that's what that clause really means, but one easy > >example is backported security fixes. Another is just regular bug > >fixes that aren't in the official releases for whatever reason. > > Personally I would say that Debian packages with extra security and > bug fixes would 'exceed the quality' of the official Mozilla packages > and thus be a good example of what Community Editions are about: You might say that, but when this came up the last time this was not the interpretation of Gervase and the Mozilla Foundation. > >> "It is very important that Community Editions of Firefox and > >> Thunderbird meet (or exceed) the quality level people have come to > >> associate with Mozilla Firefox and Mozilla Thunderbird. We need to > >> ensure this, but we don't want to get in people's way. So, we are > >> taking an optimistic approach." -- 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
Bug#354622: Maybe a solution to use the name *and* the logo
* Mike Hommey ([EMAIL PROTECTED]) wrote: > Hi all, > > There is maybe a way for debian to keep the name and use *a* logo. Note > that it is not *the* logo, since firefox logo is non-free, but the > nuvola icon theme has an LGPL version of the firefox logo, made from > scratch, and pretty similar to the original one. If we can use this logo > with the firefox name, the only remaining issue is patch validation. > > Mike, would it be possible to use this nuvola logo[1] instead of the > official one ? This seems kind of questionable. It's basically indistinguishable. Is this sort of thing really permissible under copyright? > Mike > > 1. http://en.wikipedia.org/wiki/Image:Firefox.svg > -- 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
Bug#354622: Using Firefox as the app name without official branding is still a trademark violation
* Conrad Knauer ([EMAIL PROTECTED]) wrote: > Mike Hommey wrote: "Some changes applied to the debian packages don't > fall in the community edition authorized changes, and there's no way > we want not to apply these." > > If you're referring to the list of "permitted" changes in Community > Editions on > http://www.mozilla.org/foundation/trademarks/community-edition-policy.html > I would really like to see what specifically you think would not be > allowed. One of the permitted changes is "Porting the software to > different operating systems" which would imply a degree of > OS-integration (e.g. updates through apt-get vs. individual programs > downloading updates for themselves). Also, it says below the list: I'm not sure that's what that clause really means, but one easy example is backported security fixes. Another is just regular bug fixes that aren't in the official releases for whatever reason. > "It is very important that Community Editions of Firefox and > Thunderbird meet (or exceed) the quality level people have come to > associate with Mozilla Firefox and Mozilla Thunderbird. We need to > ensure this, but we don't want to get in people's way. So, we are > taking an optimistic approach." > > I would like someone from Mozilla (Mike? :) and someone from Debian > (Eric? :) to sit down and determine if there is actually anything > stopping the Debian FF release from being called "Firefox Community > Edition Debian" right now... If it can, problem solved :) If not, > can the Mozilla CE Policy be altered slightly to accomodate Debian > and/or can Debian move some of the changes into a separate package? I asked Gervase the last time this came up if we could fix the Community Edition Guidelines to make this possible and he said it wasn't possible. If it is now that would be great. > Eric Dorland wrote: "If we call the package firefox, aren't we > claiming that's what it is and hence infringing the mark? I'd > certainly like to keep the package name unchanged, but also if it is > left as firefox and the browser presents itself as "Foobar" might that > not confuse users? > > If the CE idea actually has merit, changing the package to > "firefox-community-edition-debian" or "firefox-ced" or some such (with > an accompanying change in the description) shouldn't be too confusing > to users; plus you could always have a metapackage "firefox" that > installs the CE version. -- 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
Bug#354622: Renaming Mozilla applications
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Thu, Sep 28, 2006 at 09:55:33AM -0400, Eric Dorland wrote: > > * Steve Langasek ([EMAIL PROTECTED]) wrote: > > > On Wed, Sep 27, 2006 at 10:25:00PM +0200, Francesco Poli wrote: > > > > > it's sad to see that the safer path (renaming Mozilla applications in > > > > order to avoid being restricted by any trademark policy) was really the > > > > one to choose... :-( > > > > That was my conclusion[1] and unfortunately it seems that the other > > > > possibility (reaching a trademark agreement) only worked for a short > > > > time. > > > > > I wonder if we can come up with a renaming scheme that makes it not too > > > > difficult for a user to find the right package to install. > > > > I don't know any reason we should believe that trademark prevents us from > > > using the name "firefox" for functional elements such as package names and > > > file/directory names. The trademark does of course prevent us from > > > labelling the *interface* "firefox" and using the logos; but we already > > > have > > > a build switch we can use to comply with those requirements. > > > Certainly file/directory names are functional, but the package name is > > both labelling and functional. If we call the package firefox, aren't > > we claiming that's what it is and hence infringing the mark? > > IANAL, and answering this question authoritatively would certainly require > one. I'm merely saying that I don't *know* any reason that trademark law > prevents us from using "firefox" for the package name, which I view as a > functional element. Well can we get advice this advice? I know I can't afford it :) I'd be pretty certain that the Mozilla Corp would object to us keeping the package name. Having some sort of justification would be helpful. Keeping the package name would be great though, making things a lot less painful. > The only other instances I can remember of a maintainer renaming a package > in response to trademark claims are scrabble, and gnocatan. For scrabble, > the rename still hasn't even taken place, and I don't know if there's going > to be an upstream rename along with a package rename, but apparently the > ftpmasters rejected a package rename once already; for gnocatan, I was > involved in the upstream renaming process which was done at least as much > out of courtesy to the creator of Settlers of Catan as out of any belief > that we were infringing a trademark, and the package renaming was just done > to follow the upstream rename -- with dummy packages added to the archive to > provide an upgrade path. > > So neither of these are completely analogous to the firefox case, where it's > *upstream's* trademark triggering the rename and we're not exactly intending > to create a permanent fork. Yes, so not much help here :P > > I'd certainly like to keep the package name unchanged, but also if it is > > left as firefox and the browser presents itself as "Foobar" might that > > not confuse users? > > Do you think this would be more or less confusing than for users to not be > able to find a firefox package in the archive, despite many related packages > still referencing it by that name at the time of release? Well having transition packages would definitely be part of the plan, so that shouldn't be an issue. -- 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
Bug#354622: Renaming Mozilla applications
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Wed, Sep 27, 2006 at 10:25:00PM +0200, Francesco Poli wrote: > > > it's sad to see that the safer path (renaming Mozilla applications in > > order to avoid being restricted by any trademark policy) was really the > > one to choose... :-( > > That was my conclusion[1] and unfortunately it seems that the other > > possibility (reaching a trademark agreement) only worked for a short > > time. > > > I wonder if we can come up with a renaming scheme that makes it not too > > difficult for a user to find the right package to install. > > I don't know any reason we should believe that trademark prevents us from > using the name "firefox" for functional elements such as package names and > file/directory names. The trademark does of course prevent us from > labelling the *interface* "firefox" and using the logos; but we already have > a build switch we can use to comply with those requirements. Certainly file/directory names are functional, but the package name is both labelling and functional. If we call the package firefox, aren't we claiming that's what it is and hence infringing the mark? I'd certainly like to keep the package name unchanged, but also if it is left as firefox and the browser presents itself as "Foobar" might that not confuse users? -- 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
Bug#354622: Using Firefox as the app name without official branding is still a trademark violation
* Mike Connor ([EMAIL PROTECTED]) wrote: > > On 21-Sep-06, at 1:38 AM, Eric Dorland wrote: > > >>>If this isn't possible, could we at least get a stay of execution? > >>>Etch is going into deep freeze in less than a month. Would it be > >>>possible to resolve this after the release? > >>> > >> > >>I would think it makes much more sense to resolve this before you put > >>another long-lived release into the wild, unless your aim is to delay > >>compliance. Ignoring the logo issue entirely, I have grave concerns > >>around the nature and quality of some of the changes the patchset > >>contains, and I would like to see the changes as a set of specific > >>patches before I could make any recommendation as to whether we > >>should > >>continue to allow use of the trademark. If we were forced to revoke > >>your permission to use the trademark, freeze state would not > >>matter, you > >>would be required to change all affected packages as soon as > >>possible. > >>Its not a nice thing to do, but we would do it if necessary, and > >>we have > >>done so before. > > > >Well yes I suppose I am trying to delay compliance since you've caught > >us at an awkward time, and hoping for a little understanding. But from > >the tone of the conversation that doesn't appear to be the > >forthcoming. > > Its less about "understanding" than the legal requirements for > enforcing trademarks. We can't selectively ignore things because its > inconvenient. I understand, but this is not a new issue. The situation has been stable for over a year. It's unclear to me where the urgency is coming from. But in any case, we will be complying shortly. > >The diff.gz of the source package completely outlines the changes > >we've made in a fairly monolithic diff. If you strip out the > >regeneration of the configure file and all the debian files the diff > >is fairly small. I'm not sure what you would find objectionable, > >almost any patches we apply are from your bugzilla and have already > >been reviewed, or are minor integration or portability patches. > > There's changes for default font style, window sizes, a patch to a > file that shouldn't need patching in 1.5 (since it was fixed in our > CVS three months before we shipped 1.5) and a few other things, just > from a skim. Could you be more specific to which file is patched unnecessarily? Certainly all the changes are there to fix real bugs, and I'd be happy to discuss any and all changes we've made. The majority tend to be already reviewed patches in the bugzilla. > >>If you do have this set of patches (a question which you didn't > >>bother > >>to answer) a link would be greatly appreciated so I can get them into > >>our bugzilla and get the right sets of eyes on the code. > >>Regardless of > >>whether we're going to circle around on the logo issue, if you > >>intend to > >>continue using the mark, you need to do that ASAP. > > > >I don't appreciate the accusatory tone you've taken there. I don't > >maintain the changes as patches, but inside a Subversion repository > >that contains a complete history of my (and co-maintainer Mike > >Hommey's) changes. It's not publicly available, because it's on my > >desktop machine for size and speed reasons, but I can make a copy > >available to you if you would like. > > I'm getting questions from others asking why change X or Y was made, > and I don't have answers. My tone's a little tense because I had to > ask a few times to get a response. Having individual patches means > that if we say "this change is ok" we can put that patch somewhere > accessible to everyone and anyone can use that patch. Having > everyone do one-off patches means less sharing and more forking, > which is the opposite of what I consider open source's biggest strength. I'm not a big fan of patch based build systems, which is why I use subversion. The changes are copiously detailed in the debian/changelog and again I'd be happy to answer any questions you might have if the changelog is not enlightening. > >>As for your straw man about security bugs, what security bugs > >>would you > >>be fixing with your own patches? If there are security bugs, they > >>should be fixed upstream, not in your own tree. We've had this > >>discussion repeatedly in the context of the security group, and we > >&g
Bug#354622: Using Firefox as the app name without official branding is still a trademark violation
* Mike Connor ([EMAIL PROTECTED]) wrote: > Just to sum everything up, since some of this is getting circular, this > is how we have been dealing with Linux distros. Ultimately, fair is > fair, and unless you think Debian should get a special deal (which I > don't think is DFSG-friendly, let alone likely to happen) , these are > the conditions you need to get on board with: > > - All changes the distributor wishes to make to the source code must be > provided as discrete patches, along with a description of why the change > is required > - Releases are expected to be based on the CVS tag and/or source tarball > for the release version, plus approved patches. > - build configurations should also be submitted for approval. > - The logo and the trademark are required to be used together. > > Ultimately, I don't have a lot more to say here. The ball is in your > court now, but you should absolutely not plan to ship without addressing > these issues one way or another. It looks like the only way we can go is to change the name. I'm going to do that as soon as humanly possible. The other issue is if we can still distribute the firefox packages we already have in sarge. If etch releases as scheduled we will still be backporting security fixes into that version until Dec. 2007 (or as long as it is remains possible). Etch will become the new stable release in Dec, so it's doubtful any new users will install sarge after that point. So is keeping the name in sarge permissible? -- 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
