Bug#1053870: CVE-2023-42118: integer underflow in libspf2 resulting in RCE
Wednesday, 18 October 2023 11:56:01 CEST, Salvatore Bonaccorso wrote: > On Fri, Oct 13, 2023 at 12:05:19PM +0200, Bert Van de Poel wrote: > > As already outlined on > > https://security-tracker.debian.org/tracker/CVE-2023-42118 there's a > > known security issue in libspf2 found through a security review of > > Exim by the Zero Day Initiative. An integer underflow in libspf2 was > > found which can be used to perform RCEs. A patch on > > https://github.com/shevek/libspf2/pull/44 is available and has been > > merged into the main repository. All relevant links are already > > available on the Debian Security Tracker. > > Please note that as already outlined in the security-tracker and on > the upstream issue there is still no confirmation from ZDI that the > two issues are the same. So no, we cannot consider the pull/44 from > upstream the fix for CVE-2023-42118. It looks like it fixes *some* important bug, so should I make uploads with it for the time being? BTW, the same exact place in the code was the subject of CVE-2021-20314, but nobody realised that the patch applied then wasn't complete. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#1010066: prayer: Depends on private functions that are hidden with tidy 5.8
tisdag 31 maj 2022 kl. 16:11:03 CEST skrev Trent W. Buck: > https://sources.debian.org/src/prayer/1.3.5-dfsg1-8/session/html_secure_tid > y.c/#L274-L334 > https://api.html-tidy.org/tidy/tidylib_api_5.8.0/group__parser__h.html#ga46 > 769d54f0a1bcfd801d60c34eb563e7 > > Is it sufficient to simply change "prvTidyDiscardElement to > "TY_DiscardElement"? > > The TY_DiscardElement docs say "TY_Private". > Does that mean "you're not allowed to call this, either"? You mean TY_(DiscardElement)? TY_() is simply a macro that prepends "prvTidy" to the function name, but it's internal, which is why Prayer called it as prTidyDiscardElement(). What changed, however, is that those internal functions are now hidden so you _can't_ link them. At the same time, there is a public version now, tidyDiscardElement(), but there is no public tidyAddAttribute(), which is where we get stuck. > If so, we can build prayer without tidy at all. > Prayer will then use an older in-house HTML sanitizer: > > https://sources.debian.org/src/prayer/1.3.5-dfsg1-8/Config/?hl=16#L16 > > https://sources.debian.org/src/prayer/1.3.5-dfsg1-8/session/Makefile/#L27-L > 35 Well, not automatically. It's not bundled with the Prayer source. I don't know if it can be found anywhere. > The whole purpose of html_secure*.c is to "safely" embed an attacker's > untrusted HTML (the email) inside trusted HTML (the webmail app). > The code predates things like Content-Security-Policy (added circa 2013), > so it's probably *NEVER* safe, regardless of whether tidy is or isn't used. > > Prayer is abandoned upstream since the 201x's. > I can't find a direct citation, but here's the last time the "homepage" > existed: > > https://web.archive.org/web/20161129034822/http://www-uxsup.csx.cam.ac.uk:8 > 0/~dpc22/prayer/ > https://web.archive.org/web/20130701184507/http://www-uxsup.csx.cam.ac.uk/% > 7Edpc22/ Yeah, it may be time to let Prayer go. It's not exactly modern, and I don't even use it myself. -- Magnus Holmgrenholmg...@debian.org Debian Developer
Bug#946829: Patch works!
torsdag 19 december 2019 kl. 11:41:21 CET skrev du:
> I can confirm that patch works as expected.
>
> Patch does not apply cleanly on my SA (3.4.2-1~deb9u2) but only for
> cosmetic differences, attached a patch that wok on SA 3.4.2-1~deb9u2.
>
>
> Thanks!
I came up with the following RE loop to parse the options string. It should
allow a few more things that admins might potentially be using, like non-
integer values (for dontgreylistthreshold), while barfing on bad syntax.
while ($optionhash =~ /(?:\G(?(?['"])(?.*?)
\g{quot1})
\s*=>\s*
(?>(?['"])(?.*?)\g{quot2}
|
(?-?(?:\d+(?:\.\d*)?|(?:\d*\.)?\d+))
)\s*(?:;?\s*\)\s*$|;(?!$))/gxc) {
$option{$+{opt}} = $+{val};
}
if ((pos($optionhash) // 0) < length $optionhash) {
die "Syntax error";
}
I just need to add the variable untainting.
--
Magnus Holmgrenholmg...@debian.org
Debian Developer
signature.asc
Description: This is a digitally signed message part.
Bug#942747: FTBFS: "Error: Unbound module Parser"
Package: ocamlnet
Version: 4.1.6-1
Severity: serious
While test building packages build depending on nettle, ocamlnet failed to
build both on
experimental and on sid (I'm using an amd64 sbuild chroot).
Here's the end of the build log. I don't know anything about OCaml, so I can't
help you.
make[3]: Entering directory '/<>/src/rpc-generator'
make[4]: Entering directory '/<>/src/rpc-generator'
ocamlyacc parser.mly
sed -e 's/@VERSION@/4.1.6/' \
-e 's/@AUTHDHREQS@//' \
-e 's/@PREFERRED_CGI_PKG@//' \
-e 's/@REGEXP_PROVIDER@/str/' \
-e 's/@COMPAT_PCRE_PROVIDER@//' \
-e 's/@ZIP_PROVIDER@/zip/' \
META.in >META
echo "let cpp = \"cpp\";;" > config.ml
make[4]: Leaving directory '/<>/src/rpc-generator'
make[3]: Leaving directory '/<>/src/rpc-generator'
make[3]: Entering directory '/<>/src/rpc-generator'
ocamlfind ocamldep -pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo
-D HAVE_BYTES " *.ml *.mli >depend || { rm -f depend; exit 1; }
make[3]: Leaving directory '/<>/src/rpc-generator'
make[3]: Entering directory '/<>/src/rpc-generator'
ocamlfind ocamlc -g -safe-string -I ../../src/netstring -package "bytes unix"
-pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo -D HAVE_BYTES " -w
-25 -c config.ml
ocamlfind ocamlc -g -safe-string -I ../../src/netstring -package "bytes unix"
-pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo -D HAVE_BYTES " -w
-25 -c syntax.ml
ocamllex lexer.mll
echo /usr/bin/ocamlrpcgen >rpcgen-packlist
127 states, 803 transitions, table size 3974 bytes
ocamlfind ocamlc -g -safe-string -I ../../src/netstring -package "bytes unix"
-pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo -D HAVE_BYTES " -w
-25 -c lexer.ml
ocamlfind ocamlc -g -safe-string -I ../../src/netstring -package "bytes unix"
-pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo -D HAVE_BYTES " -w
-25 -c options.ml
opts="-opaque"; \
if [ -f "$(basename parser.mli .ml)".nopaque ]; then opts=""; fi; \
ocamlfind ocamlc -g -safe-string -I ../../src/netstring -package "bytes unix"
-pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo -D HAVE_BYTES " -w
-25 -c $opts parser.mli
ocamlfind ocamlc -g -safe-string -I ../../src/netstring -package "bytes unix"
-pp "../../tools/cppo-0.9.4/cppo -include ../../config.cppo -D HAVE_BYTES " -w
-25 -c rename.ml
File "lexer.mll", line 5, characters 7-13:
Error: Unbound module Parser
make[3]: *** [../../Makefile.rules:129: lexer.cmo] Error 2
make[3]: *** Waiting for unfinished jobs
rm lexer.ml
make[3]: Leaving directory '/<>/src/rpc-generator'
make[2]: *** [Makefile:23: all] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:49: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:26: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
--
Magnus Holmgrenholmg...@debian.org
Debian Developer
signature.asc
Description: This is a digitally signed message part.
Bug#941105: FTBFS: relocation R_X86_64_TPOFF32 against `tls_serialization_float_format' can not be used when making a shared object
Package: libstorj0 Version: 1.0.3-1 Severity: serious While rebuilding packages depending on nettle, libstorj failed with the following error: /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -O3 -Wall -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o libstorj.la -rpath /usr/lib storj.lo utils.lo http.lo uploader.lo downloader.lo bip39.lo crypto.lo rs.lo -lcurl -lnettle -ljson-c -luv -lm libtool: link: gcc -shared -fPIC -DPIC .libs/storj.o .libs/utils.o .libs/http.o .libs/uploader.o .libs/downloader.o .libs/bip39.o .libs/crypto.o .libs/rs.o /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -lnettle -ljson-c -luv -lm -g -O2 -fstack-protector-strong -O3 -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -pthread -Wl,-soname -Wl,libstorj.so.0 -o .libs/libstorj.so.0.0.0 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libjson-c.a(json_object.o): relocation R_X86_64_TPOFF32 against `tls_serialization_float_format' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status Not sure what's happening there since -fPIC is indeed used. The full build log is attached. -- Magnus Holmgrenholmg...@debian.org Debian Developer sbuild (Debian sbuild) 0.78.1 (09 February 2019) on johansson.kibibyte.se +==+ | libstorj (amd64) Tue, 24 Sep 2019 20:03:59 + | +==+ Package: libstorj Distribution: sid Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/sid-amd64-sbuild-2fc154fe-2db6-43fd-b47b-c98ab8b5fc71' with '<>' I: NOTICE: Log filtering will replace 'build/libstorj-wu1kZk/resolver-e6BMLW' with '<>' +--+ | Update chroot| +--+ Get:1 http://ftp.se.debian.org/debian sid InRelease [139 kB] Get:2 http://ftp.se.debian.org/debian sid/main Sources.diff/Index [27.9 kB] Get:3 http://ftp.se.debian.org/debian sid/main amd64 Packages.diff/Index [27.9 kB] Get:4 http://ftp.se.debian.org/debian sid/main Sources 2019-09-24-0215.17.pdiff [20.1 kB] Get:5 http://ftp.se.debian.org/debian sid/main Sources 2019-09-24-0813.11.pdiff [5362 B] Get:6 http://ftp.se.debian.org/debian sid/main Sources 2019-09-24-1416.36.pdiff [10.1 kB] Get:7 http://ftp.se.debian.org/debian sid/main amd64 Packages 2019-09-24-0215.17.pdiff [22.8 kB] Get:8 http://ftp.se.debian.org/debian sid/main amd64 Packages 2019-09-24-0813.11.pdiff [4835 B] Get:9 http://ftp.se.debian.org/debian sid/main amd64 Packages 2019-09-24-1416.36.pdiff [8123 B] Get:6 http://ftp.se.debian.org/debian sid/main Sources 2019-09-24-1416.36.pdiff [10.1 kB] Get:9 http://ftp.se.debian.org/debian sid/main amd64 Packages 2019-09-24-1416.36.pdiff [8123 B] Fetched 266 kB in 7s (36.2 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: apt e2fsprogs libapt-pkg5.0 libarchive-zip-perl libattr1 libc-bin libc-dev-bin libc6 libc6-dev libcom-err2 libext2fs2 libss2 logsave 13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 10.1 MB of archives. After this operation, 100 kB of additional disk space will be used. Get:1 http://ftp.se.debian.org/debian sid/main amd64 libc6-dev amd64 2.29-2 [2651 kB] Get:2 http://ftp.se.debian.org/debian sid/main amd64 libc-dev-bin amd64 2.29-2 [277 kB] Get:3 http://ftp.se.debian.org/debian sid/main amd64 libc6 amd64 2.29-2 [2819 kB] Get:4 http://ftp.se.debian.org/debian sid/main amd64 libapt-pkg5.0 amd64 1.8.4 [980 kB] Get:5 http://ftp.se.debian.org/debian sid/main amd64 apt amd64 1.8.4 [1420 kB] Get:6 http://ftp.se.debian.org/debian sid/main amd64 libc-bin amd64 2.29-2 [794 kB] Get:7 http://ftp.se.debian.org/debian sid/main amd64 logsave amd64 1.45.4-1 [71.5 kB] Get:8 http://ftp.se.debian.org/debian sid/main amd64 libext2fs2 amd64 1.45.4-1 [245 kB] Get:9 http://ftp.se.debian.org/debian sid/main amd64 e2fsprogs amd64 1.45.4-1 [590 kB] Get:10 http://ftp.se.debian.org/debian sid/main amd64 libattr1 amd64 1:2.4.48-5 [21.5 kB] Get:11 http://ftp.se.debian.org/debian sid/main amd64 libarchive-zip-perl all 1.66-2 [103 kB] Get:12 http://ftp.se.debian.org/debian sid/main amd64 libcom-err2 amd64 1.45.4-1 [70.8 kB] Get:13 http://ftp.se.debian.org/debian sid/main amd64 libss2 amd64 1.45.4-1 [75.3
Bug#941041: unbound: FTBFS with nettle 3.5.1, accesses ECC curves directly
Package: unbound Version: 1.9.3-1 Tags: upstream Severity: serious _verify_nettle_ecdsa() (in validator/val_secalgo.c) uses the addresses of nettle_secp_256r1 and nettle_secp_384r1 directly. As the comment in ecc- curve.h explains, "Due to ABI subtleties, applications should not refer to these directly, but use the below accessor functions." (nettle_get_secp_256r1() and nettle_get_secp_384r1().) Indeed, dnsmasq will fail to build with nettle 3.5.1, which I'm in the process of getting uploaded to unstable (and has been uploaded to experimental). -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#940985: dnsmasq WFTBFS: Accesses ECC curves directly
Package: dnsmasq Version: 2.80-1 Tags: upstream Severity: serious dnsmasq_ecdsa_verify() (in crypto.c) uses the addresses of nettle_secp_256r1 and nettle_secp_384r1 directly. As the comment in ecc-curve.h explains, "Due to ABI subtleties, applications should not refer to these directly, but use the below accessor functions." (nettle_get_secp_256r1() and nettle_get_secp_384r1().) Indeed, dnsmasq will fail to build with nettle 3.5.1. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#926952: sa-exim: Unbuildable/uninstallable in sid
lördag 4 maj 2019 kl. 12:47:18 CEST skrev Magnus Holmgren: > söndag 21 april 2019 kl. 19:55:10 CEST skrev Magnus Holmgren: > > But now that I look closer, it looks like the "spool format error" message > > is only triggered by malformed header files, and Thomas in https:// > > lists.exim.org/lurker/message/20180726.174108.0620f3c0.en.html had > > narrowed > > it down to multiple messages being received over the same connection. I > > still haven't been able to reproduce it though. It might be stochastic. > > Okay, so as I reported on the exim-dev list, I figured out that > primary_hostname, which has been being expanded once and the pointer kept in > static memory since forever, is now being overwritten although allocated > from the permanent pool. My plan is to change this to expand it anew for > each run; that solved the problem when I tested. I'm also going to add an > unrelated patch that disables body rewriting when the spool file is in wire > format and which handles CRLF line endings when scanning headers. Do you > think that you can then re-enable local_scan for the release? Actually, if the only difference wireformat makes is that the line endings are CRLF instead of LF, rewriting the body is probably not a/the problem, as SpamAssassin uses the same line endings as it gets. Carriage returns need to be stripped from the headers, though, so I'll see to that. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#926952: sa-exim: Unbuildable/uninstallable in sid
söndag 21 april 2019 kl. 19:55:10 CEST skrev Magnus Holmgren: > But now that I look closer, it looks like the "spool format error" message > is only triggered by malformed header files, and Thomas in https:// > lists.exim.org/lurker/message/20180726.174108.0620f3c0.en.html had narrowed > it down to multiple messages being received over the same connection. I > still haven't been able to reproduce it though. It might be stochastic. Okay, so as I reported on the exim-dev list, I figured out that primary_hostname, which has been being expanded once and the pointer kept in static memory since forever, is now being overwritten although allocated from the permanent pool. My plan is to change this to expand it anew for each run; that solved the problem when I tested. I'm also going to add an unrelated patch that disables body rewriting when the spool file is in wire format and which handles CRLF line endings when scanning headers. Do you think that you can then re-enable local_scan for the release? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#926952: sa-exim: Unbuildable/uninstallable in sid
söndag 21 april 2019 kl. 07:34:15 CEST skrev Andreas Metzler: > On 2019-04-20 Magnus Holmgren wrote: > > tisdag 16 april 2019 kl. 18:46:56 CEST skrev du: > [...] > > > > I have just uploaded exim 4.92-6 to exoerimental which /should/ > > > work with sa-exim, allowing you to debug properly. > > > > Thanks. So far I haven't managed to reproduce the problem of the malformed > > body file, though. > > That is kind of good news, it suggests some temporary bakage in exim > that was fixed since. Or I need to test with more binary data. After all, IIUC, the point of BDAT is that you can send chunks of binary data of given sizes instead of the reveiving server having to look for .. > > However, I produced a segfault in local_scan() when I fed > > exim a spam message using BDAT with report_safe = 1 in local.cf, > > SARewriteBody: 1 in sa-exim.conf and spool_wireformat = true in > > exim4.conf(.template). > > Is this reproducible? I got it multiple times, but then I built and installed a slightly modified sa-exim, and now I can't reproduce it anymore, even after I reinstalled sa- exim from testing. I'm pretty sure that I've been using the same spam mail the entire time too. But I'm thinking that if the problem actually persists, I can at least work around it by checking if body_linecount == 0, which should mean that spool_wireformat = true (or that there's no body to rewrite anyway) and disable body rewriting then. But now that I look closer, it looks like the "spool format error" message is only triggered by malformed header files, and Thomas in https:// lists.exim.org/lurker/message/20180726.174108.0620f3c0.en.html had narrowed it down to multiple messages being received over the same connection. I still haven't been able to reproduce it though. It might be stochastic. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#926952: sa-exim: Unbuildable/uninstallable in sid
tisdag 16 april 2019 kl. 18:46:56 CEST skrev du: > On 2019-04-15 Magnus Holmgren wrote: > > So it seems that everything should work unless spool_wireformat=true > > *and* SARewriteBody: 1. How do I detect in sa-exim whether wire format > > is used for a given body file though? > > -spool_file_wireformat in the -H file? I mean from sa-exim.c. We don't read the -H file directly. > I just do not think the reports of breakage where with > spool_wireformat=true, true though. - Nobody mentioned it and it is not > something one set accidentaly. > > I have just uploaded exim 4.92-6 to exoerimental which /should/ > work with sa-exim, allowing you to debug properly. Thanks. So far I haven't managed to reproduce the problem of the malformed body file, though. However, I produced a segfault in local_scan() when I fed exim a spam message using BDAT with report_safe = 1 in local.cf, SARewriteBody: 1 in sa-exim.conf and spool_wireformat = true in exim4.conf(.template). -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#926952: sa-exim: Unbuildable/uninstallable in sid
måndag 15 april 2019 kl. 19:46:14 CEST skrev Andreas Metzler: > Hello, > > Afaiu basically exim has got a new feature and in that case (CHUNKING) > the spoolfile looks a little bit differently and sa-exim fails to handle > this special case properly. So it has BDAT lines in it? > Even in version 4.14 exim's documentation said > > | The file is open for reading and writing, but updating it is not > | recommended > > which I'd read as "you may keep both pieces if it breaks". :-( Well, now that I look closer (it's been too long since I did that) I realise that of couse the headers are available and manipulated through the header_line structs in memory and that it's only the body that's read from and written to the fd, so there should be no problems if SARewriteBody is set to 0 in sa-exim.conf (which is the default). > I have not tested it but I suspect it might break even more when > spool_wireformat is set. Isn't it the case that if CHUNKING has been offered AND spool_wireformat is set, then the body files are in an alternate format? read_message_bdat_smtp() looks like it is like the good old read_message_data_smtp() but for CHUNKING. And the documentation for spool_wireformat says "If this option is set, Exim may for some messages use an alternative format for data-files in the spool which matches the wire format. Doing this permits more efficient message reception and transmission. Currently it is only done for messages received using the ESMTP CHUNKING option." So it seems that everything should work unless spool_wireformat=true *and* SARewriteBody: 1. How do I detect in sa-exim whether wire format is used for a given body file though? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#926952: sa-exim: Unbuildable/uninstallable in sid
fredag 12 april 2019 kl. 19:23:40 CEST skrev du: > The dlopen localscan patch in exim4 has been nonfunctional in unstable > for quite some time (4.92~RC2-1/experimental/18 Dec, 4.92~RC3-1 > unstable/26 Dec and buster/03 Jan). The issue only popped up end of > March on the upstream user support ML. > > At this time I opened a tracking bug in exim #925982 and looked at > sa-exim. It is dead upstream since 2006 and buggy: > * https://lists.exim.org/lurker/message/20180726.113354.6d03efde.en.html > * #879687 I've seen reports of bugs, but I didn't realise it was that bad. sa-exim hasn't exactly changed; has the way local_scan() is called changed? It's supposed to get an fd, read a message from it, and possibly write an altered message back (after piping it through spamc). What can "Format error in spool file" mean? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#914632: RFC: proposed fix for CVE-2018-19518 in uw-imap
söndag 30 december 2018 kl. 09:38:57 CET skrev Salvatore Bonaccorso: > There is an alternative approach wich was raised by Magnus in the > respective bug: https://bugs.debian.org/914632#12 (and see followup > from Moritz). So, is it OK to upload this (assuming there's no code out there that actually uses SET_RSHPATH or SET_SSHPATH)? (By no longer defining RSHPATH, rshpath doesn't get set by the following code and tcp_aopen() will return NIL without doing anything. #ifdef RSHPATH /* rsh path defined yet? */ if (!rshpath) rshpath = cpystr (RSHPATH); #endif ) -- Magnus Holmgrenholmg...@debian.org Debian Developer commit e644cfbd0aac25ef320912e58e0d37cb715b2b88 Author: Magnus Holmgren Date: Sun Jan 13 21:07:41 2019 +0100 [CVE-2018-19518] 2013_disable_rsh.patch (new): Disable access to IMAP mailboxes through running imapd over rsh (Closes: #914632). diff --git a/debian/changelog b/debian/changelog index b6960d1..cc7b885 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +uw-imap (8:2007f~dfsg-5+deb9u1) stretch-security; urgency=high + + * [CVE-2018-19518] 2013_disable_rsh.patch (new): Disable access to IMAP +mailboxes through running imapd over rsh, and therefore ssh (Closes: +#914632). Code using the library can enable it with tcp_parameters() +after making sure that the IMAP server name is sanitized. + + -- Magnus Holmgren Sun, 24 Feb 2019 19:45:23 +0100 + uw-imap (8:2007f~dfsg-5) unstable; urgency=low * 1006_openssl1.1_autoverify.patch (new): Use new features for diff --git a/debian/patches/2013_disable_rsh.patch b/debian/patches/2013_disable_rsh.patch new file mode 100644 index 000..7a68644 --- /dev/null +++ b/debian/patches/2013_disable_rsh.patch @@ -0,0 +1,11 @@ +--- a/src/osdep/unix/Makefile b/src/osdep/unix/Makefile +@@ -985,7 +985,7 @@ onceenv: +-DMD5ENABLE=\"$(MD5PWD)\" -DMAILSPOOL=\"$(MAILSPOOL)\" \ +-DANONYMOUSHOME=\"$(MAILSPOOL)/anonymous\" \ +-DACTIVEFILE=\"$(ACTIVEFILE)\" -DNEWSSPOOL=\"$(NEWSSPOOL)\" \ +- -DRSHPATH=\"$(RSHPATH)\" -DLOCKPGM=\"$(LOCKPGM)\" \ ++ -DLOCKPGM=\"$(LOCKPGM)\" \ +-DLOCKPGM1=\"$(LOCKPGM1)\" -DLOCKPGM2=\"$(LOCKPGM2)\" \ +-DLOCKPGM3=\"$(LOCKPGM3)\" > OSCFLAGS + echo $(BASELDFLAGS) $(EXTRALDFLAGS) > LDFLAGS diff --git a/debian/patches/series b/debian/patches/series index ced3fcc..80d69e8 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -9,3 +9,4 @@ 2012_krb5_multidev.patch 1005_poll.patch 1006_openssl1.1_autoverify.patch +2013_disable_rsh.patch signature.asc Description: This is a digitally signed message part.
Bug#914632: uw-imap: CVE-2018-19518
lördag 23 februari 2019 kl. 15:26:25 CET skrev Salvatore Bonaccorso: > On Sun, Jan 13, 2019 at 06:24:36PM +0100, Magnus Holmgren wrote: > > söndag 13 januari 2019 kl. 08:31:28 CET skrev Salvatore Bonaccorso: > > > On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote: > > > > On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote: > > > > > I'm wondering if anyone would complain if I'd disable RSH (SSH) > > > > > connections > > > > > altogether. > > > > > > > > Full ack, that seems like the most sensible fix. > > > > > > Any news on this approach, or did you spot any problem with that way? > > > > Here's my plan. Removing the RSHPATH define should disable the insecure > > code, I reckon. I just haven't been able to make gbp use my long PGP key > > id... > Any news on this? I thought I'd write a NEWS.Debian entry about disabling RSH, but then I realised it wouldn't be disabled completely, only by default; code using the library can still set rshpath by calling tcp_parameters(SET_RSHPATH, path). But maybe that's just fine. I also haven't got around to actually verifying that the patch works as intended. Perhaps wanting to run imapd via remote shell is so rare that there's no need to write a NEWS.Debian entry? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#914632: uw-imap: CVE-2018-19518
söndag 13 januari 2019 kl. 08:31:28 CET skrev Salvatore Bonaccorso: > On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote: > > On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote: > > > I'm wondering if anyone would complain if I'd disable RSH (SSH) > > > connections > > > altogether. > > > > Full ack, that seems like the most sensible fix. > > Any news on this approach, or did you spot any problem with that way? Here's my plan. Removing the RSHPATH define should disable the insecure code, I reckon. I just haven't been able to make gbp use my long PGP key id... -- Magnus Holmgrenholmg...@debian.org Debian Developer --- a/src/osdep/unix/Makefile +++ b/src/osdep/unix/Makefile @@ -985,7 +985,7 @@ onceenv: -DMD5ENABLE=\"$(MD5PWD)\" -DMAILSPOOL=\"$(MAILSPOOL)\" \ -DANONYMOUSHOME=\"$(MAILSPOOL)/anonymous\" \ -DACTIVEFILE=\"$(ACTIVEFILE)\" -DNEWSSPOOL=\"$(NEWSSPOOL)\" \ - -DRSHPATH=\"$(RSHPATH)\" -DLOCKPGM=\"$(LOCKPGM)\" \ + -DLOCKPGM=\"$(LOCKPGM)\" \ -DLOCKPGM1=\"$(LOCKPGM1)\" -DLOCKPGM2=\"$(LOCKPGM2)\" \ -DLOCKPGM3=\"$(LOCKPGM3)\" > OSCFLAGS echo $(BASELDFLAGS) $(EXTRALDFLAGS) > LDFLAGS signature.asc Description: This is a digitally signed message part.
Bug#914632: uw-imap: CVE-2018-19518
> CVE-2018-19518[0]: > | University of Washington IMAP Toolkit 2007f on UNIX, as used in > | imap_open() in PHP and other products, launches an rsh command (by > | means of the imap_rimap function in c-client/imap4r1.c and the > | tcp_aopen function in osdep/unix/tcp_unix.c) without preventing > | argument injection, I'm wondering if anyone would complain if I'd disable RSH (SSH) connections altogether. -- Magnus Holmgren Debian Developer
Bug#898581: Remove pike7.8 from Debian?
söndag 13 maj 2018 kl. 23:59:49 CEST skrev du: > Debian 9 "Stretch" has both pike7.8 and pike8.0. In general, we try > not to have duplicate packages in Debian. Is there any reason we > shouldn't remove pike7.8 from Debian unstable now? No, Pike 8.0 has been out long enough now that I was actually planning to have 7.8 removed before buster. I've been meaning to create a pike-defaults package similar to python-defaults. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#828589: uw-imap: FTBFS with openssl 1.1.0
torsdag 3 november 2016 kl. 00:23:37 CET skrev Sebastian Andrzej Siewior:
> On 2016-09-12 17:00:28 [+0200], Kurt Roeckx wrote:
> > > But this problem existed before 1.1.0 support (this patch).
> > > What do you recommend here? The builtin usage
> > > (X509_VERIFY_PARAM_set_hostflags()) looks simple. The alternative
> > > X509_check_host() is 1.0.2+ and since it can not be applied to stable I
> > > don't see the point. I would add this for 1.1.0 and keep the current
> > > validation for < 1.1.0.
> >
> > We don't want to upload this to Debian stable in any case. But if
> > it's only doing the right thing with 1.1.0 that works for me.
>
> So I've been looking at this again. The patch attached should do what
> you asked for. It is so untested that EA is already using it…
I'm thinking we can and should keep using CTX functions (e.g.
SSL_CTX_get0_param()), which minimizes the amount of changes. And your
cert_verify() seems to essentially do the same things as the existing
ssl_open_verify().
> Ehm. One thing: The callback that uw-imap invokes
> scq(err_str_cpy, "hostname", cert_subj)
>
> expects to pass the hostname of the connection. I have no idea how to
> obtain it at that point.
ssl_start_work() puts it in a static variable that ssl_open_verify() reads.
I have tested my patch to the extent that I get a validation error when I use
"mailutil check" with an IP address, but not when I use the hostname. I
haven't tested all kinds of SAN shenanigans, but I suppose we can trust
OpenSSL here. The error message is of course different since we rely on the
built-in validation routine instead of our ssl_validate_cert().
--
Magnus Holmgrenholmg...@debian.org
Debian Developer --- a/src/osdep/unix/ssl_unix.c
+++ b/src/osdep/unix/ssl_unix.c
@@ -227,8 +227,16 @@ static char *ssl_start_work (SSLSTREAM *
/* disable certificate validation? */
if (flags & NET_NOVALIDATECERT)
SSL_CTX_set_verify (stream->context,SSL_VERIFY_NONE,NIL);
- else SSL_CTX_set_verify (stream->context,SSL_VERIFY_PEER,ssl_open_verify);
+ else {
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+ X509_VERIFY_PARAM *param = SSL_CTX_get0_param(stream->context);
+ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
+ X509_VERIFY_PARAM_set1_host(param, host, 0);
+#endif
+
+ SSL_CTX_set_verify (stream->context,SSL_VERIFY_PEER,ssl_open_verify);
/* set default paths to CAs... */
+ }
SSL_CTX_set_default_verify_paths (stream->context);
/* ...unless a non-standard path desired */
if (s = (char *) mail_parameters (NIL,GET_SSLCAPATH,NIL))
@@ -266,6 +274,7 @@ static char *ssl_start_work (SSLSTREAM *
if (SSL_write (stream->con,"",0) < 0)
return ssl_last_error ? ssl_last_error : "SSL negotiation failed";
/* need to validate host names? */
+#if OPENSSL_VERSION_NUMBER < 0x1010
if (!(flags & NET_NOVALIDATECERT) &&
(err = ssl_validate_cert (cert = SSL_get_peer_certificate (stream->con),
host))) {
@@ -275,6 +284,7 @@ static char *ssl_start_work (SSLSTREAM *
sprintf (tmp,"*%.128s: %.255s",err,cert ? cert->name : "???");
return ssl_last_error = cpystr (tmp);
}
+#endif
return NIL;
}
@@ -312,7 +322,7 @@ static int ssl_open_verify (int ok,X509_
* host to validate against
* Returns: NIL if validated, else string of error message
*/
-
+#if OPENSSL_VERSION_NUMBER < 0x1010
static char *ssl_validate_cert (X509 *cert,char *host)
{
int i,n;
@@ -342,6 +352,7 @@ static char *ssl_validate_cert (X509 *ce
else ret = "Unable to locate common name in certificate";
return ret;
}
+#endif
/* Case-independent wildcard pattern match
* Accepts: base string
signature.asc
Description: This is a digitally signed message part.
Bug#777833: digikam: ftbfs with GCC-5 (patch)
söndagen den 20 september 2015 13.54.52 skrev Magnus Holmgren: > Maintainers, are you planning on uploading a recent digikam version? I could > NMU to add this build dependency but there still remain other RC bugs. Let me rephrase that. Is there anything I can help you with? Merely adding the missing libsoprano-dev build dependency is no longer enough; I've noticed, due to the new version of marble. And 4.14 seems to require some work; libkgeomap, libkface, and some other libraries that where previously bundled in the "extra" directory now apparently need to be packaged separately. Another, minor issue is that MySQL database support is no longer enabled by default; "-DENABLE_MYSQLSUPPORT=ON -DENABLE_INTERNALMYSQL=ON" has to added to the dh_auto_configure command line. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#799514: pike8.0: FTBFS: Missing Build-Depends on libsoprano-dev
Saturday, 19 September 2015 20.44.46, Chris Lamb wrote: > pike8.0 fails to build from source due to missing Build-Depends on > libsoprano-dev. This was previously pulled-in via a transitive > relationship. Are you sure that you filed this against the right package and for the right reason? AFAIK Pike doesn't use libsoprano. I did notice that the package FTBFS due to a new TYPEOF() macro in libfreetype 2.6, however. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#777833: digikam: ftbfs with GCC-5 (patch)
tisdagen den 25 augusti 2015 19.05.52 skrev Danny Edel: > I tried to rebuild digikam on sid today. The current version still > > misses libsoprano-dev dependency and fails with: > > make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed > > by 'lib/libkvkontakte.so.1.0.0'. Stop. > > Once a build-time dependency on libsoprano-dev was declared, I was able > to compile digikam on a sid sbuild, it linked against the new > opencv-*2.4v5 libraries. It seems that the reason that digikam failed to build with GCC 5 was that it failed to parse an unusual version number; now it fails for a completely different reason. Maintainers, are you planning on uploading a recent digikam version? I could NMU to add this build dependency but there still remain other RC bugs. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#788525: git-remote-https segfault involving libgnutls
Friday, 12 June 2015 13.53.07 you wrote: > In my setup, a simple "git ls-remote https://github.com/irmen/Pyro4.git"; (or > any https repo I had) would silently die, with only strace revealing > git-remote-https segfaulting. Check your version of libcurl3-gnutls - you probably need the version from unstable. It appears that not all packages migrated to testing at the same time, meaning that we will see breakage in testing as well. Things should resolve themselves within a day or two. -- Magnus Holmgren Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
fixed 784009 gnutls28/3.3.15-5 thanks We can probably close this bug now. We should at least get the fixed version right so the package can migrate. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#785297: bug 785297 is forwarded to https://github.com/tatsuhiro-t/aria2/issues/346, tagging 785297
torsdagen den 4 juni 2015 19.03.50 skrev Andreas Metzler: > Find attached a minimal patch for the debian package to include the > upstream fix. Do you want to do the NMU, with an appropriate delay, since you've already posted the diff? -- Magnus Holmgren Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784009: Bug#785376: transition: nettle
fredagen den 15 maj 2015 16.09.20 skrev Emilio Pozuelo Monfort: > On 15/05/15 14:43, Magnus Holmgren wrote: > > There's a new major release of the GNU Nettle cryptolibrary (stabilized at > > version 3.1.1) that I'd like to upload to unstable. > > Please fix the nettle arm64 build in experimental first. The bug in gcc that caused the tests to fail on arm64 has been patched now. OK to upload? (gcc-4.9 4.9.2-20 has been built and installed on arm64 but not all other architectures yet). -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#784009: Segmentation fault
torsdagen den 14 maj 2015 07.56.56 skrev Andreas Metzler: > On 2015-05-10 Magnus Holmgren wrote: > > måndagen den 4 maj 2015 19.32.52 skrev Andreas Metzler: > [...] > > >> I think GnuTLS being listed as part of the guile-1.8 removal is an > >> error in the reporting script, GnuTLS has moved to guile-2.0 in 2013. > >> OTOH I hope we can have gnutls linked against nettle 3.x without > >> needing to update to 3.4.x. (Which would couple together two > >> transitions. And 3.4 ist still a development release.) > >> <http://lists.gnutls.org/pipermail/gnutls-devel/2015-May/007583.html> > > > > A rather significant patch, but since someone has already done it, > > will you use it? 3.1-1 has entered experimental, as you may have > > seen. Should I upload 3.1.1-1 to unstable or to experimental for > > now? > > Given that it originates from GnuTLS' author I will try to use it. > Could you upload 3.1.1-1 to experimental? I have done so. > Have you already opened a transition tracker, BTW? Not yet. I've been testing building depending packages all day, and most builds cleanly although some failed for other reasons, but lsh-utils needs some work. I'd like to see if I can patch it or have to ask upstream. -- Magnus Holmgrenholmg...@debian.org Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785297: aria2: FTBFS with linux-libc-dev 4.0.2-1
Source: aria2
Version: 1.18.10-2
Severity: serious
Hi. I just tried to build aria2 in sid (using cowbuilder) in preparation of
the transition of nettle. I don't have much more detail, but something seems
amiss with regards to the detection, declaration, and/or invocation of the
getrandom syscall (in the current builds, the syscall interface was not
detected at all).
checking for getrandom... no
[...]
checking for getrandom linux syscall interface... yes
[...]
CC getrandom_linux.lo
getrandom_linux.c: In function 'getrandom_linux':
getrandom_linux.c:56:20: error: 'SYS_getrandom' undeclared (first use in this
function)
read = syscall(SYS_getrandom, p, buflen, 0);
^
--
Magnus Holmgrenholmg...@debian.org
Debian Developer
signature.asc
Description: This is a digitally signed message part.
Bug#784009: Segmentation fault
måndagen den 4 maj 2015 19.32.52 skrev Andreas Metzler: > On 2015-05-03 Magnus Holmgren wrote: > > lördagen den 2 maj 2015 17.47.21 skrev Andreas Metzler: > > > On 2015-05-02 Niels Möller wrote: > [...] > > >> /I/ think that would help, afaict we would need to either package a > >> nettle-2.7 with versioned symbols or patch Debian's version. > > > > Not sure how this situation is normally handled, but when Nettle 3.1 > > is uploaded to sid, new versions of GnuTLS and other packages > > linking against it should follow soon after [1], so the problem is > > temporary. > > Hello, > "temporary" can take surprisingly long if one of the linking packages > suddenly develops a build error. ;-) > And one can get a surising amount of bug reports from people doing > partial ugrades, too. Yeah, some additional testing and some coordination and/or swift (bin)NMUing may be in order, but I say let's get this over with. :-) > > In testing there should never be more than one version as > > there's only one source package. > > I somehow missed that fact in my considerations. (I think that at some > point the RM considered changing the testing migration infrastructure > to allow keeping old, "orphaned" binaries around to simplify > transitions. - I am not sure whether this was ever implemented.) You may be right. We should keep in mind that all binary packages need to be accompanied in the archive by the corresponding sources, but that's not impossible to do. > > I'm not aware of any special > > provisions for transitions of libraries *without* symbol versions, > > but since Nettle does now. A 2.7.x with symbol versions might > > still be helpful to some if you meant for it to be uploaded to jessie (and > > stable point releases of various Debian derivatives). > > I do not think we have ever done that, making a stable-update just to > introduce versioned symbols. - Needs doublechecking with -release. No, I don't think that's an accepted cause for a stable update. All depending packages would need to be rebuilt and re-uploaded as well for it to be meaningful. > > [1] That is, Nettle 3.1 will be uploaded to sid when the current > > upload to experimental has been cleared by the FTP masters and > > GnuTLS is ready to follow, which I guess is after the guile-1.8 > > transition, but perhaps an upload of 3.4.0 to experimental is in > > order before then? Last I checked, all other packages linking > > against nettle needed no code changes. > > I think GnuTLS being listed as part of the guile-1.8 removal is an > error in the reporting script, GnuTLS has moved to guile-2.0 in 2013. > OTOH I hope we can have gnutls linked against nettle 3.x without > needing to update to 3.4.x. (Which would couple together two > transitions. And 3.4 ist still a development release.) > <http://lists.gnutls.org/pipermail/gnutls-devel/2015-May/007583.html> A rather significant patch, but since someone has already done it, will you use it? 3.1-1 has entered experimental, as you may have seen. Should I upload 3.1.1-1 to unstable or to experimental for now? -- Magnus Holmgrenholmg...@debian.org Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
lördagen den 2 maj 2015 17.47.21 skrev Andreas Metzler: > On 2015-05-02 Niels Möller wrote: > > Andreas Metzler writes: > >> Looks like we need a two-step transition: nettle 2.7 -> nettle > >> 2.7+versioned_symbols , nettle 2.7+versioned_symbols -> nettle 3.1. > > > > I'm considering making a nettle-2.7.2 release with version symbols. The > > version string would simply be derived from the version in the soname, > > "NETTLE_4" and "HOGWEED_2". Would that help? > > [...] > > /I/ think that would help, afaict we would need to either package a > nettle-2.7 with versioned symbols or patch Debian's version. Not sure how this situation is normally handled, but when Nettle 3.1 is uploaded to sid, new versions of GnuTLS and other packages linking against it should follow soon after [1], so the problem is temporary. In testing there should never be more than one version as there's only one source package. I'm not aware of any special provisions for transitions of libraries *without* symbol versions, but since Nettle does now. A 2.7.x with symbol versions might still be helpful to some if you meant for it to be uploaded to jessie (and stable point releases of various Debian derivatives). [1] That is, Nettle 3.1 will be uploaded to sid when the current upload to experimental has been cleared by the FTP masters and GnuTLS is ready to follow, which I guess is after the guile-1.8 transition, but perhaps an upload of 3.4.0 to experimental is in order before then? Last I checked, all other packages linking against nettle needed no code changes. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#782266: nettle-dbg: directory vs. symlink conflict: /usr/share/doc/nettle-dbg -> libnettle4
torsdagen den 9 april 2015 18.46.34 skrev Andreas Beckmann: > Package: nettle-dbg > Version: 3.0-2 > > during a test with piuparts I noticed your package installs files over > an existing symlink shipped or created by another package. > > This was observed during an sid->experimental upgrade. I think this was addressed in unstable; I'll merge the changes from there shortly. -- Magnus Holmgrenholmg...@debian.org Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work
fredagen den 18 juli 2014 21.35.52 skrev du: > NetworkManager has started creating a new wired connection "eth0" > after/during boot; this connection has ipv4 (and ipv6) disabled, and > thus provides no connectivity. I can manually select my original > wired connection (standard dhcp) in gnome3 (or using nmcli), but it > keeps creating the "eth0" interface and using it after restarting. I had the same or similar problem, except that only IPv4 was disabled. It seems that the cause in my case was that I tried to load netconsole on the kernel command line, which I think worked before I switched to systemd and/or stopped using ifupdown. Now when didn't try to load netconsole automatically, no automatic connection was created, but the interface was renamed from eth0 to eth1. systemd still reported that mounting remote file systems failed, but the network connection came up and /home was mounted eventually nonetheless. Strangely enough, checking /etc/udev/rules.d/70-persistent-net.rules (last modified in August), there is an eth0 line with a MAC address that doesn't match the current address of my NIC, and an eth1 line that does, but I'm pretty sure that the actual address hasn't been changing, and it matches /etc/NetworkManager/system-connections/eth0, which hasn't been changed since before the last boot. I did also rename the connection in NetworkManager, but that should't have any consequences, should it? I suppose it would have been possible to work around the problem by adding a no-auto-default setting to NetworkManager.conf. I'm not sure what to make of this but it seems that loading netconsole was bringing the interface up early (but leaving it unconfigured), which may have confused NM. It may also have prevented udev from renaming it, but I don't know if these points are related. -- Magnus Holmgrenholmg...@debian.org Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774919: nettle-dbg: copyright file missing after upgrade (policy 12.5)
fredagen den 9 januari 2015 13.58.28 skrev Helmut Grohne: > On Fri, Jan 09, 2015 at 04:24:45AM +0100, Andreas Beckmann wrote: > > 1m7.4s ERROR: WARN: Inadequate results from running adequate! > > > > nettle-dbg: missing-copyright-file /usr/share/doc/nettle-dbg/copyright > > This likely is an unintended(!) conversion from directory to symlink. I > believe that this is a regression in the 2.7.1-4 upload that aimed to > fix #773022. In 2.7.1-4 only libhogweed2 and nettle-bin would symlink > their docs to libnettle4. Thus the original patch, only added the > version restriction to the dependencies. Nah, I thought I knew what I was doing, but I had forgotten that replacing directories with a symlinks annoyingly requires manual handling, so maybe I'll change back to the way it was, unless that's considered too late now... > Now what actually ended up in 2.7.1-4 is: > > dh_installdocs -a -Nnettle-dev --link-doc=libnettle4 > dh_installdocs -a -pnettle-dev > > So while nettle-dev is exempted from the linkdoc, nettle-dbg is not. I > see a few ways forward here: > > * Add -Nnettle-dbg and -pnettle-dbg to the respective dh_installdocs >commands. > * Revert to 2.7.1-3 and take the patch for #773022. > * Actually transition this directory to a symlink using >dpkg-maintscript-helper. > > Given that Magnus Holmgren addressed #773022 within a week, I think that > it is likely that he addresses this bug in a timely manner or speaks up > as to what his preferred solution is. > > Helmut -- Magnus Holmgrenholmg...@debian.org Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745233: libhogweed2: should have versioned depend on newer libgmp10
tisdagen den 22 april 2014 22.12.24 skrev Steve M. Robbins: > I think I understand the rationale for using the super-fine-grained symbol > versioning. If someone from the debian-science-maintainers team would like > to maintain this file, please go ahead and commit it to the repository. > Unfortunately, I don't have the time to audit each release; so if left to > me, I will use the easy and conservative "dh_makeshlibs -V" solution. Once the symbols file is in place, maintaining it shouldn't require very much effort. As I explained, dpkg-gensymbols, which is run by dh_makeshlibs, tells you about any symbol changes when you build the package. You merely have to apply the generated diff to the symbols file and adjust the minium required version appropriately, making the procedure more automated compared to manually checking when the dependencies have to change. Running simply "dh_makeshlibs -V" should be avoided as will result in unnecessarily tight dependencies and therefore may delay testing transitioning. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#745233: libhogweed2: should have versioned depend on newer libgmp10
söndagen den 20 april 2014 12.53.02 skrev Steve M. Robbins: > So to be sure: adding "-V" is the right thing to do here? You should add "-V libgmp10 (>= 6.0.0)" and keep it that way until further symbols are added. But preferably you should create a symbols file so that packages that don't use the new symbols don't get unnecessarily strict dependencies: Go back to the previous version or, to be sure, the first version with SOVERSION 10 (5.0.x). Add a file debian/libgmp10.symbols with the following content: libgmp.so.10 libgmp10 #MINVER# Build the package. You should get complaints about new symbols and a diff. Apply that diff, but change the version number on each line to only consist of the upstream version (or the upstream version + "~", to allow for backports). For symbols that have existed from the beginning of libgmp10, you can change the version number to 0, meaning no versioned dependency will be generated. Repeat for each nee upstream version that might have added new symbols (which I guess means 5.1.x and 6.0.0). -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#745233: libhogweed2: should have versioned depend on newer libgmp10
reassign 745233 libgmp10 retitle 745233 libgmp10: Wrong shlibs information after 6.0.0 adds new symbols affects 745233 libhogweed2 thanks söndagen den 20 april 2014 12.55.09 Ivo De Decker: > On Sun, Apr 20, 2014 at 01:14:18AM +0200, Magnus Holmgren wrote: > > That kind of thing should never happen; that's what we have shlibs and > > symbols files for. Do you know if there's any reason that libgmp10 > > doesn't include a symbols file and/or declare new a minimum version in > > it's shlibs file? > I agree that this shouldn't happen, but I don't know why libgmp10 doesn't > include symbols or shlibs files that enforce this dependency. I'm adding a > Cc to to gmp maintainers. I think I can even dare reassign the bug. Please update the dh_makeshlibs command for gmp 6.0.0 or, preferably, add a symbols file. Then nettle and all other packages that reference the new symbols should be binNMUed. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#745233: libhogweed2: should have versioned depend on newer libgmp10
lördagen den 19 april 2014 15.21.21 skrev Ivo De Decker: > The new nettle upload contains a version of libhogweed2 which uses symbols > from the new version (6.0.0) of libgmp10, but it doesn't have a versioned > dependency. This means it's possible to install libhogweed2 with an older > version of libgmp10, but this doesn't work. That kind of thing should never happen; that's what we have shlibs and symbols files for. Do you know if there's any reason that libgmp10 doesn't include a symbols file and/or declare new a minimum version in it's shlibs file? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#731860: libtar: CVE-2013-4420: directory traversal when extracting archives
tisdagen den 11 februari 2014 11.26.15 skrev du: > On 9 February 2014 22:08, Magnus Holmgren wrote: > > The first "if" should be a "while", shouldn't it? Otherwise we'll only > > skip > > over the first "../" if file_name starts with "../../", if I'm not > > mistaken. > That's handled by the while loop right after the if. Attached test > case contains an entry called ../../../empty-file > tar tf should print a warning message and list the full path, while > libtar should simply print it as 'empty-file'. Yes, an odd number of ".." will yield the desired result, but the even ".."s will be missed. We should also strip any leading slashes to be of any use, so I'll add that too. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#731860: libtar: CVE-2013-4420: directory traversal when extracting archives
tisdagen den 10 december 2013 16.27.32 skrev du: > CVE-2013-4420[0]: > tar_extract_glob and tar_extract_all path prefix directory traversal > > Attached is a proposed patch that makes libtar work similarly to tar. The first "if" should be a "while", shouldn't it? Otherwise we'll only skip over the first "../" if file_name starts with "../../", if I'm not mistaken. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#711593: pike7.8-gtk: fails to upgrade from 'testing' - trying to overwrite /usr/lib/pike7.8/modules/Tools.pmod/PV.pike
On lördagen den 8 juni 2013, you stated the following: > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Getting the right modules in the right package drives me crazy! For the record, I did add Replaces and Breaks declarations, I was just one off with the release number. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#708366: marked as done (pike7.8: FTBFS due to conflicting REG_* definitions)
found 708366 7.8.700-3 stop Oops, that didn't work. Apparently I only tested building the package on i386 in my mind. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#682256: Bug#668008: transition/unblock: uw-imap
On söndagen den 14 oktober 2012, you stated the following: > On Mon, Sep 24, 2012 at 08:12:19 +0200, Magnus Holmgren wrote: > > Unfortunately, Jonas's decision to upload without an SONAME bump broke > > all packages that use libc-client (see bug #682256), due to an extra, > > internal (and in this case unnecessarily strict) version check that > > fails. > > > > The SONAME *shouldn't* have had to be changed as 2007f is merely a bugfix > > release, except for an attempt to also support AIX 5.2, but that's > > nothing that affects us. There are no ABI or API changes. See attached > > diff. > > How about the patch below? It might certainly be a good idea too disable that check permanently; it is rather redundant after all. > diff -Nru uw-imap-2007f~dfsg/debian/changelog > uw-imap-2007f~dfsg/debian/changelog --- > uw-imap-2007f~dfsg/debian/changelog 2012-06-29 13:32:24.0 +0200 > +++ uw-imap-2007f~dfsg/debian/changelog 2012-10-14 20:02:14.0 > +0200 @@ -1,3 +1,10 @@ > +uw-imap (8:2007f~dfsg-1.1) unstable; urgency=low > + > + * Non-maintainer upload. > + * Disable broken version check (closes: #682256) > + > + -- Julien Cristau Sun, 14 Oct 2012 20:02:13 +0200 > + -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#686212: Please allow translation of all debconf templates
On onsdagen den 29 augusti 2012, you stated the following: > A small typo in one of the templates (missing prepending underscore) > prevent one screen to be translated. That's intentional. I don't plan to present that template to the administrator at this time; It's just there so the EXTRA_ARGS variable in /etc/default/lsh- server can be preserved. Still, it may be worthwhile to translate it for future use. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#666634: pyscrabble: FTBFS: /bin/sh: 2: rsvg: not found
severity 34 wishlist retitle 34 Use rsvg-convert instead of rsvg to convert icons thanks On lördagen den 31 mars 2012, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > for size in 16 22 32 48 64 96; do \ > > > > rsvg -h $size -w $size debian/pyscrabble.svg > > pyscrabble-$size.png; \ > > > > done > > > > /bin/sh: 2: rsvg: not found > > /bin/sh: 2: rsvg: not found > > /bin/sh: 2: rsvg: not found > > /bin/sh: 2: rsvg: not found > > /bin/sh: 2: rsvg: not found > > /bin/sh: 2: rsvg: not found > > make: *** [build-stamp] Error 127 That seems to be rsvg's fault (http://bugs.debian.org/666276), but I guess I should switch to rsvg-convert eventually. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#640278: heimdal-dev: Symlinks broken after multi-arch conversion
On torsdagen den 8 september 2011, Matthias Klose wrote: > No, the symlinks are not broken. Maybe you do maintain a package with > broken or explicit checks for locations of libraries? The symlinks are fine in the unstable/testing version (1.4.0-8), because there they're created "by hand" in debian/rules, but they are indeed broken in the experimental version: $ ls -l /usr/lib/libkrb5.so /usr/lib/libasn1.so lrwxrwxrwx 1 root root 18 14 aug 04.30 /usr/lib/libasn1.so -> heimdal/libasn1.so lrwxrwxrwx 1 root root 18 14 aug 04.29 /usr/lib/libkrb5.so -> heimdal/libkrb5.so $ ls -l /usr/lib/heimdal ls: cannot access /usr/lib/heimdal: No such file or directory As I wrote elsewhere, using krb5-config --libs (or pkg-config) avoids the problem, but then maybe these symlinks should be dropped altogether? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#640278: heimdal-dev: Symlinks broken after multi-arch conversion
Package: heimdal-dev Version: 1.5~pre2+git20110729-2 Severity: serious The symlinks listed in debian/heimdal-dev.links were left behind in /usr/lib and are thus broken. They should be moved to /usr/lib/$DEB_HOST_MULTIARCH somehow, or possibly at least point to targets in /usr/lib/$DEB_HOST_MULTIARCH/heimdal. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#591595: fixed in comixcursors 0.6.1-3
On onsdagen den 25 augusti 2010, Ben Finney wrote: > On 22-Aug-2010, Magnus Holmgren wrote: > > On tisdagen den 17 augusti 2010, Ben Finney wrote: > > >* debian/preinst: > > > + Handle the case where no cursor themes are yet installed > > > > > >(Closes: Bug#591595). > > > > However, it was clearly postinst that failed. > > I am unable to reproduce this behaviour with ‘comixcursors’ 0.6.1-3. > What have you done to confirm that the bug still occurs after this > change? In a sid chroot: # aptitude install comixcursors The following NEW packages will be installed: comixcursors 0 packages upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/4639kB of archives. After unpacking 51.3MB will be used. Selecting previously deselected package comixcursors. (Reading database ... 12905 files and directories currently installed.) Unpacking comixcursors (from .../comixcursors_0.6.1-3_all.deb) ... Setting up comixcursors (0.6.1-3) ... update-alternatives: error: no alternatives for x-cursor-theme. update-alternatives: using /etc/X11/cursors/ComixCursors-Black-Small.theme to provide /usr/share/icons/default/index.theme (x-cursor-theme) in auto mode. update-alternatives: error: unable to make /usr/share/icons/default/index.theme.dpkg-tmp a symlink to /etc/alternatives/x-cursor-theme: No such file or directory dpkg: error processing comixcursors (--configure): -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#591595: fixed in comixcursors 0.6.1-3
On söndagen den 22 augusti 2010, Ben Finney wrote: > On 22-Aug-2010, Magnus Holmgren wrote: > > On tisdagen den 17 augusti 2010, Ben Finney wrote: > > >* debian/preinst: > > > + Handle the case where no cursor themes are yet installed > > > > > >(Closes: Bug#591595). > > > > However, it was clearly postinst that failed. What you need to do is > > ship an empty /usr/share/icons/default directory. Crystalcursors had > > the same bug not once but twice: 363059 and 582517. > > Do I understand you correctly that *every* cursor theme package needs > to ship the same empty directory? That this is cause to make a lintian > override for every such empty directory? Why? I've just recently begun looking into cursor packages, but as I understand it, that's how things stand currently. Strangely enough, lintian doesn't complain about the empty directory in crystalcursors. I haven't figured out why yet. > Why is it not, rather, a directory provided by some single, common > package? I don't think there is actually any suitable package to hold it. Cursor themes are handled on the client side of X, so x11-common and other server-side packages are out. I also don't think it's a good idea to put it libxcursor or any other client library package. I think that what it would come down to is a cursor-themes-common package that would contain nothing but that empty directory, and that's hardly worth it. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#591595: fixed in comixcursors 0.6.1-3
reopen 591595 thanks On tisdagen den 17 augusti 2010, Ben Finney wrote: >* debian/preinst: > + Handle the case where no cursor themes are yet installed >(Closes: Bug#591595). However, it was clearly postinst that failed. What you need to do is ship an empty /usr/share/icons/default directory. Crystalcursors had the same bug not once but twice: 363059 and 582517. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#592119: prayer
Package: prayer Version: 1.0.18-1 Severity: serious If you enable SSL session caching, prayer uses Berkeley DB (libdb) for that, and, during initialization, compares the version number (major.minor.patch) returned by db_version() with the compile time version and terminates if the major or minor version numbers don't match or the current patch number is lower than the compile time patch number. That's unnecessary and incorrect, at least for Debian's purposes, because a) packaging, dependencies, and sonames make sure that a compatible version of libdb will be loaded, and b) the documentation states that there will be no API or ABI changes within a minor version. What can happen, and what happened now, is that prayer is built and uploaded to unstable, transitions to testing before the version of libdb it was linked against, and, if SSL session caching is enabled, complains that libdb is too old when in fact it is not. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#567945: lsh-server: Does not configure on mipsel
severity 567945 normal thanks On lördagen den 24 juli 2010, Magnus Holmgren wrote: > On torsdagen den 17 juni 2010, you stated the following: > > Hi, > > > > sh4 has the same problem. What is sh4 by the way? > > There was the following logs in syslog. > > > > Jun 17 05:38:44 localhost lshd[26143]: lshd: Could not bind any address. > > > > The problem probably is that while lsh-server.postinst creates > /etc/ssh/sshd_not_to_be_run, it doesn't actually stop sshd. > [...] > Still though, I find it strange that lsh-server would be installed if > openssh- server is already, since that would fulfil lam-runtime's > ssh-server dependency. Of course, if you install lsh-server in a chroot, pbuilder or otherwise, and an SSH server is installed outside it, binding port 22 will still fail, and there's not much that can be done about that. You would probably get exactly the same result if openssh-server were to be installed instead of lsh-server, because the former's postinst also fails if sshd can't be started. In summary, if you install lsh-server when there is already an sshd listening on port 22 you *have* to choose a different port for lsh-server, and having any package build-depend (indirectly) on ssh-server is probably a bad idea. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#567945: lsh-server: Does not configure on mipsel
On torsdagen den 17 juni 2010, you stated the following: > Hi, > > sh4 has the same problem. > > There was the following logs in syslog. > > Jun 17 05:38:44 localhost lshd[26143]: lshd: Could not bind any address. > The problem probably is that while lsh-server.postinst creates /etc/ssh/sshd_not_to_be_run, it doesn't actually stop sshd. I could fix that, as long as policy allows it, but the problem is that it is generally difficult to keep track of what ports and interfaces the local administrator has configured various services to use. Because two packages providing the same network service, such as HTTP/WWW, can be configured to use different ports, such packages generally do not declare conflicts with each other. Avoiding port conflicts is the responsibility of the administrator. This also means that a dependency on ssh-server is no guarantee that an SSH server is listening on port 22. Also, /etc/ssh/sshd_not_to_be_run is an old, ugly hack that should not be relied upon, and sshd could have already have been configured to listen to another port, meaning that is should not be disabled. In the case of SSH servers, it could be argued that there is little reason having more than one installed. On the other hand, I wouldn't want to remove one SSH server before I know that the next one works. At least not remotely, but on the third hand, configuring SSH servers is probably something you should do from a local console. Still though, I find it strange that lsh-server would be installed if openssh- server is already, since that would fulfil lam-runtime's ssh-server dependency. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#567945: lsh-server: Does not configure on mipsel
On måndagen den 15 mars 2010, Adam C Powell IV wrote: > On Sun, 2010-03-14 at 22:49 +0100, Andreas Barth wrote: > > If the tests are all successfull, I think marking this as > > "unreproducible" and/or closing it is ok. > > That will be an acceptable outcome when packages which reverse-depend on > this can successfully install it on the mipsel buildd. There is no trace of any build failure on https://buildd.debian.org/build.cgi?pkg=scalapack. The buildds seem to have a policy-rc.d that prevents any services from starting, and seem to have had that for some time, so I'm curious as to exactly *where* lsh-server failed to start... -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#567945: lsh-server: Does not configure on mipsel
On tisdagen den 2 februari 2010, Magnus Holmgren wrote: > On måndagen den 1 februari 2010, Adam C Powell IV wrote: > > lsh-server fails to configure on mipsel, as can be seen in the buildd > > log for scalapack: > > > > Setting up lsh-server (2.0.4-dfsg-6+b1) ... > > Creating lsh random seed file (this may take a while) ... done. > > Creating lsh host key ... > > .. > > > > done. > > Starting secure shell v2 server: lshdClosed spurious fd 3 > > failed! > > Can someone please check if there's any syslog output from lshd? I've successfully tried installing lsh-server on a virtual mipsel machine under QEMU. I could really use some help here. I think there's also a bug in lam, though. Either liblam4 should merely suggest lam-runtime, or lam-runtime should merely suggest ssh-server, or it should prefer a specific ssh-server implementation. On onsdagen den 3 februari 2010, Niels =?UTF-8?Q?M=C3=B6ller wrote: > Magnus Holmgren writes: > >> Starting secure shell v2 server: lshdClosed spurious fd 3 > > I also think this message is suspicious. lshd tries to close all fd:s > between 3 and getdtablesize() (to avoid that any spurious open fd leaks > to user processes it spawns). Expected result is that all these close > calls should fail with EBADF. So what is fd 3, and why is it open? Probably the pipe for writing commands to Debconf. I could try closing it, but I don't think it's the problem as lshd started successfully in spite of it when I tested. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#567945: lsh-server: Does not configure on mipsel
On måndagen den 1 februari 2010, Adam C Powell IV wrote: > lsh-server fails to configure on mipsel, as can be seen in the buildd > log for scalapack: > > Setting up lsh-server (2.0.4-dfsg-6+b1) ... > Creating lsh random seed file (this may take a while) ... done. > Creating lsh host key ... > .. > > done. > Starting secure shell v2 server: lshdClosed spurious fd 3 > failed! Can someone please check if there's any syslog output from lshd? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#552717: prayer: FTBFS: Nonexistent build-dependency: libc-client2007b-dev
On onsdagen den 28 oktober 2009, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > ** Using build dependencies supplied by package: > > Build-Depends: cdbs, debhelper (>= 5), quilt, libc-client2007b-dev | > > libc-client2007-dev | libc-client-dev (>= 7:2007~), libldap2-dev, > > zlib1g-dev, libssl-dev (>= 0.9.6), libdb-dev > > > > ┌ > >──┐ │ Install build dependencies > > │ > > └ > >──┘ > > > > Checking for already installed source dependencies... > > W: Unable to locate package libc-client2007-dev > > W: Unable to locate package libc-client2007b-dev What happened/is happening with the "planned switch to unversioned libc-client post-lenny"? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#545090: lsh-server upgrade causes installation problem
On fredagen den 4 september 2009, Bartłomiej Gródek wrote: > aptitude dist-upgrade causes installation error. Please find the error log > below: > Setting up lsh-server (2.0.4-dfsg-3) ... > Starting secure shell v2 server: lshd failed! > invoke-rc.d: initscript lsh-server, action "start" failed. Fix is on its way. But even then you need to work around it by setting VERBOSE=no. So to recover, please run (as root) VERBOSE=no dpkg --configure --pending now, or VERBOSE=no aptitude dist-upgrade after 2.0.4-dfsg-4 arrives. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#543123: chiark-utils: FTBFS: Nonexistent build-dependency: libnettle-dev
> > Checking for already installed source dependencies... > > libx11-dev: missing > > libnettle-dev: missing > > debhelper: missing > > Checking for source dependency conflicts... > > E: Package libnettle-dev has no installation candidate I intend to NMU this very shortly. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#543131: lsh-utils: FTBFS: Nonexistent build-dependency: libnettle-dev
On lördagen den 22 augusti 2009, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > ** Using build dependencies supplied by package: > > Build-Depends: cdbs, debhelper (>= 4.1.16), dpatch, autotools-dev, > > libgmp3-dev, zlib1g-dev | libz-dev, liboop-dev, libxau-dev, > > libnettle-dev, texinfo (>= 4.2), guile-1.6 | scsh-0.6, heimdal-dev, > > libwrap0-dev | libwrap-dev, libpam0g-dev | libpam-dev, libreadline5-dev | > > libreadline-dev, m4 I know; I maintain both packages. Turned out some patching was needed and nettle 2.0-1 was ACCEPTED quicker than I expected. :-/ -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#459705: Status upload of pike7.8?
On lördagen den 22 augusti 2009, Luk Claes wrote: > Hi > > What's the status of uploading pike7.8 which uses an updated Nettle? Soonish. I have checked in a patch; I'll just see what other changes to include in the same upload. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#518198: [debpool] Bug#518198: One other missing dependency
On onsdagen den 4 mars 2009, Micah Anderson wrote: > The list of missing package dependencies is actually: > > libdigest-sha-perl, libarchive-tar-perl and liblinux-inotify2-perl I never got around to looking at Andres's changes, but I thought the intention was that at least libdigest-sha-perl and liblinux-inotify2-perl would be optional? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#459705: Source package contains non-free IETF RFC/I-D
On torsdagen den 22 januari 2009, Magnus Holmgren wrote: > On fredagen den 16 januari 2009, Robert Millan wrote: > > tags 459705 patch > > thanks > > > > On Thu, Jun 26, 2008 at 12:33:58PM +0200, Magnus Holmgren wrote: > > > While I generally agree that everything Debian ships should be really > > > free, not merely free to redistribute, in this case I feel that a > > > single file buried inside another tarball, which no-one has reason to > > > unpack since Nettle exists as a package of its own, is such a marginal > > > issue that the desire to ship a pristine tarball should carry more > > > weight. > > > > I'm attaching a script that does this for you. It should no longer be a > > burden to remove that file from a deeply buried tarball. > > Thanks. However, I'd like to repeat that the reason I haven't fixed this > bug isn't that it's hard, but that it seems like such a marginal problem > that I consider it more important with a pristine tarball. Especially after I made the effort to make the package work with tarballs as shipped by upstream. And "HE" seemed to agree too. Furthermore, the problem is resolved upstream in Pike 7.8, which bundles Nettle 1.15 and should probably replace Pike 7.6 entirely in the next release. I apologise for not protesting sooner, but could you please cancel the NMU? I can't stop it simply by uploading a new Debian revision since you increased the upstream version. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#459705: Source package contains non-free IETF RFC/I-D
On fredagen den 16 januari 2009, Robert Millan wrote: > tags 459705 patch > thanks > > On Thu, Jun 26, 2008 at 12:33:58PM +0200, Magnus Holmgren wrote: > > While I generally agree that everything Debian ships should be really > > free, not merely free to redistribute, in this case I feel that a single > > file buried inside another tarball, which no-one has reason to unpack > > since Nettle exists as a package of its own, is such a marginal issue > > that the desire to ship a pristine tarball should carry more weight. > > Hi Magnus, > > I'm attaching a script that does this for you. It should no longer be a > burden to remove that file from a deeply buried tarball. Thanks. However, I'd like to repeat that the reason I haven't fixed this bug isn't that it's hard, but that it seems like such a marginal problem that I consider it more important with a pristine tarball. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#506811: pyscrabble-server: Permission denied to write pyscrabble.log
On måndagen den 24 november 2008, Mauro Lizaur wrote: > Everytime i try to execute pyscrabble-server i get the following error: > > [20:51:16] terminaldelmal:~$ pyscrabble-server > [...] > IOError: [Errno 13] Permission denied: '/var/log/pyscrabble/pyscrabble.log' That's because I've built the pyscrabble-server package so that pyscrabble-server can be started automatically from /etc/init.d/pyscrabble, running under a dedicated account "pyscrabble". I did not mean for it to be run manually. There should be more information in /usr/share/doc/pyscrabble-server/README.Debian. > I tried changing the owner of this file (me:me), and i'm still getting the > same error. > Also, i tried executing it as root (not the brightest ideas, but..) and i > got this: > > [20:53:35] terminaldelmal:~# pyscrabble-server > bash: pyscrabble-server: command not found That's because /usr/games is not normally in root's $PATH. It might have been a mistake to install pyscrabble-server in /usr/games. It's possible that it should have been installed in /usr/sbin even though it's a game server. It might have reduced confusion. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#494011: setting package to prayer prayer-accountd, tagging 494011, tagging 493009
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # prayer (1.2.2.1-3) unstable; urgency=low # # * welcome_is_template.patch: #- shared/config.c: Don't require that the help_dir option, which was # removed from the default prayer.cf earlier, is defined # (Closes: #493009). # * makefile_install_config.patch: #- shared/config.c: Likewise don't check for lock_dir (Closes: #494011). # package prayer prayer-accountd tags 494011 + pending tags 493009 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492285: prayer: Build-depend on unversioned libc-client-dev to allow BinNMUs
On söndagen den 27 juli 2008, Jonas Smedegaard wrote: > On Sun, Jul 27, 2008 at 06:37:34PM +0200, Magnus Holmgren wrote: > >On torsdagen den 24 juli 2008, Jonas Smedegaard wrote: > >> As subject says, package should build-depend on libc-client-dev to > >> allow binMUs. > > > >Since libc-client-dev is virtual it's no longer possible to express the > >build dependency on version 2007 or newer. I find that a bit > >unsatisfactory. > > Oh - do prayer depend on features only available in libc-client2007 or > newer? Yes. > If so, it was wrong of me to change to use the virtual package. A valid > dependency could then instead be the following: > > libc-client (7:2007) | libc-client2007b | libc-client2007 > I suppose you mean libc-client-dev (>= 7:2007~) | libc-client2007b-dev | libc-client2007-dev I'll fix that. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#492285: prayer: Build-depend on unversioned libc-client-dev to allow BinNMUs
On torsdagen den 24 juli 2008, Jonas Smedegaard wrote: > As subject says, package should build-depend on libc-client-dev to allow > binMUs. Since libc-client-dev is virtual it's no longer possible to express the build dependency on version 2007 or newer. I find that a bit unsatisfactory. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#486066: pike7.6-perl: broken on hppa
On fredagen den 13 juni 2008, Niko Tyni wrote: > From the buildd log: > > ## Configuring module: Perl > [...] > checking if perl is embeddable... no Detection seems to work now. Testing would the module works would be appreciated. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#459705: Source package contains non-free IETF RFC/I-D
On tisdagen den 8 januari 2008, you stated the following: > This source package contains the following files from the > IETF under non-free license terms: > > > Pike-v7.6.112/bundles/nettle-1.14.tar.gz:nettle-1.14/testsuite/rfc1750.txt > > This problem really is in nettle, and not pike, and was earlier > discussed in that context, see: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393400 While I generally agree that everything Debian ships should be really free, not merely free to redistribute, in this case I feel that a single file buried inside another tarball, which no-one has reason to unpack since Nettle exists as a package of its own, is such a marginal issue that the desire to ship a pristine tarball should carry more weight. I've asked upstream to switch to Nettle 1.15, but it's unlikely that they'll make a new 7.6 release soon. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#486066: setting package to pike7.6-pcre pike7.6-sdl pike7.6-manual pike7.6-perl pike7.6-gl pike7.6-meta pike7.6-odbc pike7.6-bzip2 pike7.6-mysql pike7.6-pg pike7.6-core pike7.6-doc pike7.6-gdbm pi
# Automatically generated email from bts, devscripts version 2.10.29 # # pike7.6 (7.6.112-3) unstable; urgency=medium # # * 12_perl_init.dpatch (new): Fix silent build failure on hppa (Closes: ##486066). Thanks to Niko Tyni. # package pike7.6-pcre pike7.6-sdl pike7.6-manual pike7.6-perl pike7.6-gl pike7.6-meta pike7.6-odbc pike7.6-bzip2 pike7.6-mysql pike7.6-pg pike7.6-core pike7.6-doc pike7.6-gdbm pike7.6-image pike7.6-reference pike7.6-svg pike7.6-dev pike7.6 pike7.6-sane tags 486066 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
On fredagen den 30 maj 2008, you stated the following: > The ftbfs on autobuilder issue could be fixed by switching the order of > the optional build-dependencies. However, toolame is a stand-alone command-line encoder; it's hardly of any use when building idjc. Free may really have meant libtwolame-dev, but that's not a drop-in replacement for liblame-dev either; TwoLAME has a different API and ABI and at any rate, IDJC's ./configure doesn't look for it. > but IMO it is a very bad idea to have a package build against a legally > dubious library just because the system it was built on happened to have > it installed. Well, if it's installed it gets used whether or not it is listed as a build dependency. You'd have to list all such undesirable libraries in Build-Conflicts to prevent building against them, but IMHO that's merely inconvenient to everyone living outside the relatively few countries where software can be patented, who wants to rebuild the package with full functionality. Since there is no LAME in Debian there is no possibility that a package linked against LAME will make it to stable. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#461219: closed by Duncan Findlay <[EMAIL PROTECTED]> (Not really a bug in spamassassin)
On Thu, 17 Jan 2008 12:34:15 +, you stated the following: > After about 1 month on my small system, only delivering my personal > emails, spamd was timing out every time trying to expire the database. Sorry for the delayed response to this bug report... However, I'm not sure if I can do much about it except put a recommendation in README.Debian. Even if I increase the timeout to five minutes or more, there's no guarantee that it will suffice either. RFC 2821 recommends a timeout of ten minutes and some MTAs will give up before that. When I lowered my bayes_expiry_max_db_size from 1 000 000 to 500 000 on my not-so-new computer, sa-learn --force-expire took just over three minutes, so it seems a bit strange that an expiry run with a default db size on decent hardware with modest load should take over four minutes. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#459705: Pike has been bundling Nettle with non-free RFC for a long time
found 459705 7.6.24-1 -- Magnus Holmgren [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Bug#442880: strongswan: postinst failure (missing /etc/init.d/ipsec)
debian/rules contains # TODO: check if we still need this rm -f $(CURDIR)/debian/strongswan/etc/init.d/ipsec?* What's the idea here? To set up ipsec from /etc/network/if-pre-up.d/ instead? -- Magnus Holmgren[EMAIL PROTECTED] pgplHKxMAoeU2.pgp Description: PGP signature
Bug#431874: strongswan - FTBFS: cannot create regular file `/etc/ipsec.conf': Permission denied
tags 431874 + patch thanks Here's the patch needed. Again, I checked the most recent upstream release and found that it's fixed there. -- Magnus Holmgren[EMAIL PROTECTED] 01_starter_install_destdir.dpatch Description: application/shellscript pgpLy46VCmcJg.pgp Description: PGP signature
Bug#427311: FTBFS: *** missing separator.
tags 427311 + patch
thanks
The output of ghc -E (the pre-processing phase) must have changed to add LINE
pragmas. The ghcsym() function in script/confhc doesn't take this into
account, so "{-# LINE 1 ghcsym.hs #-}\n" ends up in lib/debian/config. Given
that __GLASGOW_HASKELL__ is always an integer according to
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor,
I think that it's better to look for it specifically than to try to filter
out everything else.
--- hmake-3.12.orig/script/confhc
+++ hmake-3.12/script/confhc
@@ -78,7 +78,7 @@
ghcsym () {
echo __GLASGOW_HASKELL__ >ghcsym.hs;
$1 -E -cpp -optP-P ghcsym.hs -o ghcsym.out;
- grep -v '^#' ghcsym.out | grep -v '^$' > $2;
+ grep '^[0-9]\+$' ghcsym.out > $2;
rm -f ghcsym.hs ghcsym.out;
}
echo -n " Looking for ghc... "
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
pgp4tVWo1b2QQ.pgp
Description: PGP signature
Bug#441705: Info received (gok: package content changed if build twice or more times in a row)
tags 441705 + patch thanks Attached are two patch files. One that patches debian/rules and one that was meant to be dropped into debian/patches. Unfortunately that won't work due to bug #414305, so the options are a) use dpatch instead or b) patch the source directly. Makefile.in is patched to avoid having to run automake. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) "Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack)" -- Dave Evans (This patch intentionally has reduced context.) diff -Nur gok-1.2.5/help/gok/C/Makefile.in gok-1.2.5.new/help/gok/C/Makefile.in --- gok-1.2.5/help/gok/C/Makefile.in 2007-09-17 14:43:21.0 +0200 +++ gok-1.2.5.new/help/gok/C/Makefile.in 2007-09-17 14:43:24.0 +0200 @@ -302,1 +302,1 @@ -DISTCLEANFILES = legal.xml +DISTCLEANFILES = diff -Nur gok-1.2.5/Makefile.in gok-1.2.5.new/Makefile.in --- gok-1.2.5/Makefile.in 2007-05-25 19:36:38.0 +0200 +++ gok-1.2.5.new/Makefile.in 2007-09-17 14:46:11.0 +0200 @@ -910,1 +910,2 @@ -mostlyclean-am: mostlyclean-generic mostlyclean-libtool +mostlyclean-am: mostlyclean-generic mostlyclean-libtool \ + mostlyclean-local @@ -946,7 +947,8 @@ uninstall uninstall-am uninstall-desktopDATA \ uninstall-gladeDATA uninstall-iconDATA uninstall-info-am \ uninstall-local uninstall-pixmapsDATA uninstall-pkgconfigDATA \ - uninstall-pkgdataDATA uninstall-schemaDATA uninstall-xmlDATA + uninstall-pkgdataDATA uninstall-schemaDATA uninstall-xmlDATA \ + mostlyclean-local @INTLTOOL_DESKTOP_RULE@ @INTLTOOL_XAM_RULE@ @@ -994,6 +996,8 @@ uninstall-local: rm -rf $(DESTDIR)$(datadir)/gok + +mostlyclean-local: @for l in *; do \ if [ -f $$l/main.kbd ]; then \ rm -rf $$l; \ diff -u gok-1.2.5/debian/rules gok-1.2.5/debian/rules --- gok-1.2.5/debian/rules +++ gok-1.2.5/debian/rules @@ -16,0 +17,13 @@ + +makebuilddir/gok-doc:: + if [ ! -f debian/docs-backup.tar.gz ]; then \ + tar -czf debian/docs-backup.tar.gz docs/reference; \ + fi + +clean:: + if [ -f debian/docs-backup.tar.gz ]; then \ + rm -rf docs/reference; \ + tar -xzf debian/docs-backup.tar.gz; \ + rm debian/docs-backup.tar.gz; \ + fi + pgpGEhnSYifoV.pgp Description: PGP signature
Bug#442929: strongswan: Maintainer script modifies conffiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: strongswan Version: 2.8.0+dfsg-1 Severity: serious Justification: Policy 10.7.3 I came across strongswan looking for RC bugs to fix as part of my NM process. While investigating bug #442880 and bug #431874 I noticed that openswan ships /etc/ipsec.conf and /etc/ipsec.secrets as conffiles, which the postinst script then modifies. The DPM forbids this, because "[t]hese two styles of configuration file handling must not be mixed, for that way lies madness: dpkg will ask about overwriting the file every time the package is upgraded." - -- Magnus Holmgren[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG7vt6k7mRNn1h4+YRAkKjAKCIVfK0va8mP+Sp4h+219wC48acBQCfQKT4 mL9RA6GZ0PGNPabU6CjkMUM= =MAVP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441705: gok: package content changed if build twice or more times in a row
tags 441705 + upstream In related news, "debian/rules clean" does a poor job, which can be blamed on upstream shipping files (documentation) which are regenerated when building the package, as well as deleting the $LANGUAGE directories in the uninstall-local target instead of in the mostlyclean-local target. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpn77BkjFVNj.pgp Description: PGP signature
Bug#440324: bugzilla: Uninstallable due to bashisms (when using POSIX shell, eg. dash)
Ted Percival <[EMAIL PROTECTED]>: > Installation is failing on my system where /bin/sh is a link to > /bin/dash. The precense of the "-ne" and "-e" in output indicates that > there are probably one or more scripts using bash features without > specifying /bin/bash as the interpreter. I've taken a look at this bug as part of my NM process. The "-n" and "-ne" you're seeing comes from dbconfig-common, not bugzilla. This particular problem was fixed in dbconfig-common 1.8.33. That probably has nothing to do with the error message from mysql. Apparently the database wasn't created successfully. I think you need to provide more details of what you did, how you answered debconf questions and what other output you got. -- Magnus Holmgren[EMAIL PROTECTED] pgpyOuFiZA7Of.pgp Description: PGP signature
Bug#440577: libdkim-dev: Package namespace conflict
Source: dkim-milter Severity: serious Both dkim-milter and libdkim builds libdkim-dev, and libdkim0 and libdkim2 conflict too, even though the names aren't completely identical. As I explained when dkim-milter was first packaged, I'm not completely foreign to dropping Alt-N's libdkim altogether, but the issue should be properly discussed first. -- Magnus Holmgren libdkim maintainer pgpxRaRBSqAwd.pgp Description: PGP signature
Bug#426425: sa-exim: sa-exim does not depend on a recent enough version of exim
severity 426425 important thanks On Monday 28 May 2007 19:49, Shalon Wood wrote: > When I upgraded my system yesterday, mail broke. After investigation, it > turned out that sa-exim had been upgraded, but exim4 had not. The new > version of sa-exim used the local_scan() version 1.1 ABI, but the old exim4 > was compiled with the version 1.0 ABI. How old? Even exim4 4.63-17 (the version in Etch) should declare ABI version 1.1 (in reality, the minor version should have been bumped long ago), and you reported running 4.67. Can you provide more details, please, like exact log messages? I'm lowering the severity in the meantime. -- Magnus pgp1pLgMmnKNu.pgp Description: PGP signature
Bug#426425: sa-exim: sa-exim does not depend on a recent enough version of exim
On Monday 28 May 2007 19:49, Shalon Wood wrote: > When I upgraded my system yesterday, mail broke. After investigation, it > turned out that sa-exim had been upgraded, but exim4 had not. The new > version of sa-exim used the local_scan() version 1.1 ABI, but the old exim4 > was compiled with the version 1.0 ABI. This is a bit tricky since it depends on the version of exim4-dev. sa-exim doesn't actually need ABI 1.1 (yet), but the build system doesn't know that (just like with libraries, but in this case there is no library and no shlibs file providing the needed Exim version). So I think exim4-dev needs to be modified too, in some way. -- Magnus Holmgren pgpgEwqUKv7Sk.pgp Description: PGP signature
Bug#415034: chiark-utils FTBFS
tags 415034 + pending thanks Fixed package can be found in ftp://ftp.kibibyte.se/debian/pool/main/n/nettle, DSC is ftp://ftp.kibibyte.se/debian/pool/main/n/nettle/nettle_1.15-2.dsc I need a sponsor to upload it, and I though it would be both nice and practical if one of you DDs involved here would have the honour. -- Magnus Holmgren pgpjYfNSiz862.pgp Description: PGP signature
Bug#415034: chiark-utils FTBFS -- who is to blame?
On Tuesday 15 May 2007 11:58, Steve Langasek wrote: > On Tue, May 15, 2007 at 11:05:40AM +0200, Magnus Holmgren wrote: > > According to the nettle docs, summer needs be linked with -lnettle -lgmp, > > but I don't know if this is Right. As it happens, I was just discussing > > this with upstream. > > No it's not right. No software should be required to care about the > implementation details of the library it's using, *especially* when > dynamic linking on an OS that gets this right (such as GNU/Linux). I was thinking of using pkg-config to get the right linker flags, thereby relieving the software using nettle from knowing the details. But it's still much better to link libnettle.so.2 with -lgmp, since it's always needed anyway. > The previous upstream version of libnettle (or at least, the Debian > packaging thereof) got this right. The current behavior is a regression. Yes, apparently I lost that piece of the Debian diff when I upgraded to upstream version 1.15. I'll fix it right away. -- Magnus pgpueaA9Vwp9A.pgp Description: PGP signature
Bug#415034: chiark-utils FTBFS -- who is to blame?
According to the nettle docs, summer needs be linked with -lnettle -lgmp, but I don't know if this is Right. As it happens, I was just discussing this with upstream. -- Magnus Holmgren nettle maintainer pgp72FmfkwE8j.pgp Description: PGP signature
Bug#420443: sa-exim fails to run and loses email
I have made a preliminary 4.2.1-8 available at ftp://ftp.kibibyte.se/debian/pool/main/s/sa-exim/ (deb/deb-src ftp://ftp.kibibyte.se/debian sid main) Please read the changelog, but if you don't use teergrubing or body rewriting there should be no change whatsoever. -- Magnus Holmgren sa-exim maintainer pgpvkAFgREnPc.pgp Description: PGP signature
Bug#419101: Archive::Ar doesn't pad members to 2-byte boundary
Package: libarchive-ar-perl
Version: 1.13b-1
Severity: grave
Justification: Makes the package largely unusable
Tags: upstream patch
Forwarded: http://rt.cpan.org/Public/Bug/Display.html?id=18383
Archive::Ar doesn't take the 2-byte alignment (see
http://en.wikipedia.org/wiki/Ar_(file_format)>) of headers into account;
neither when writing nor when reading. See upstream bug report (which he
hasn't reacted on after a full year) for the former case. The latter case is
sometimes not noticed because the s/// on line 322 is in multi-line mode; it
should be single-line (/s). After line 335, add
substr($scratchdata, 0, $headers->{size} % 2, "");
Or possibly add "\n?" to the beginning of the regexp on line 322.
--
Magnus Holmgren[EMAIL PROTECTED]
pgpbgHLdaSjBZ.pgp
Description: PGP signature
Bug#414290: Experimental libc-client packages almost empty
Source: uw-imap Version: 7:2006d.dfsg-1 Severity: grave Packages libc-client2006b.dfsg-1 and libc-client2006b.dfsg-1-dev end up empty, except for some files in /usr/share/doc/*. Seems you forgot to update the package names to 2006d in debian/control. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgppz5gIGHS0P.pgp Description: PGP signature
Bug#328362: pmk: postinst fails, missing depends?
found 328362 0.9.3s2-2.1 thanks I can reproduce this bug too. Apparently pmksetup segfaults after reading pmkcpu.dat. Version 0.10.1 seems to fix the bug. I can take maintainership of the package and upload the new version. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpM3YZPhuG7S.pgp Description: PGP signature
Bug#354654: bug#354654 general: fat32 gets corrupted
> Since I have the need to continue to work with my machine1, I finally did > an apt-get dist-upgrade for machine1, and installed debian kernel > 2.6.15-1-686. I erased fat32 partition and replaced it by a ext2 and give > access to it from windows using fs-driver. I will see if problems are still > present (if I continue to loose directories). > > In machine2 I will also upgrade the kernel but without erasing the fat32, > to have a chance to see if the problems comes from the kernel. I will also > remove hdparm from machine2, if the kernel is not the problem. > > I will let you know what are the results in the coming weeks, because if it > is a bug it worth to be reported. What were the results? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpHrJtaqlPfT.pgp Description: PGP signature
Bug#399362: imapproxy: Bashism in init script
Package: imapproxy
Version: 1.2.4-5.1
Severity: serious
Justification: Policy 10.4, "shell scripts specifying /bin/sh as interpreter
must only use POSIX features"
Tags: patch
> if [ "$START" == "no" -a "$1" != "stop" ]; then
> log_warning_msg "Not starting imapproxy - disabled in ${DEFAULT}";
> exit 0;
> fi
It appears dash and posh chokes on "==" above. A single "=" is enough and POSIX.
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
pgpxDskJdpsTz.pgp
Description: PGP signature
Bug#395860: still here in 0.19-2
On Friday 03 November 2006 16:09, Florent Bayle took the opportunity to say: > It seems that this problem is still here in 0.19-2 : > > Automatic build of libmail-dkim-perl_0.19-2 on saturne by sbuild/amd64 85 > > Build started at 20061102-2213 > > * > >* > > [...] > > > make[1]: Leaving directory `/build/buildd/libmail-dkim-perl-0.19' > > /usr/bin/make test TEST_FILES="t/[^v]*.t" # I really just want to > > exclude verifier.t make[1]: Entering directory > > `/build/buildd/libmail-dkim-perl-0.19' PERL_DL_NONLAZY=1 /usr/bin/perl > > "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" > > t/[^v]*.t t/verifier ^ This borders on the insane ... obviously I should have read dash(1) better; then I would have seen that the ^ is a bashism and should have been an !. I wonder how many will actually be affected by this. -- Magnus pgpjMdg7sq35Y.pgp Description: PGP signature
Bug#395860: libmail-dkim-perl: FTBFS: tests fail
On Monday 30 October 2006 10:16, Julien Danjou took the opportunity to say: > On Mon, Oct 30, 2006 at 11:04:25AM +0200, Magnus Holmgren wrote: > > Needless to say I can't reproduce this. Maybe the failure is transient; > > verifier.t depends on DNS and the public DKIM key at > > shan._domainkey.vmt2.cis.att.net being available. Too bad the test script > > doesn't print more details. > > So this test should be disabled, since you can't expect the buildd to be > connected to Internet. I believe you, but where is this documented? Also, since libmail-dkim-perl is Arch: all, it doesn't really need to be autobuilt (by buildd.debian.org). Can the severity be lowered for this reason? BTW, why make test at all? Shouldn't the packaging and the distribution guarantee that building works everywhere if it works in one place? -- Magnus Holmgren pgpqoofgKvJ4I.pgp Description: PGP signature
Bug#395860: libmail-dkim-perl: FTBFS: tests fail
On Saturday 28 October 2006 11:09, Julien Danjou took the opportunity to say: > There was a problem while autobuilding your package: > > # Failed test 'result() works and gave expected answer' > > # in t/verifier.t at line 28. > > > > # Failed test ''mine_ietf01_1.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''mine_ietf01_2.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''mine_ietf01_3.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''mine_ietf01_4.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf00_1.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf00_2.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf00_3.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf00_4.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf00_5.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf01_1.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''good_ietf01_2.txt' should 'pass'' > > # in t/verifier.t at line 80. > > > > # Failed test ''bad_ietf01_1.txt' should 'fail'' > > # in t/verifier.t at line 80. > > > > # Failed test 'determined body had been altered' > > # in t/verifier.t at line 47. > > > > # Failed test ''bad_ietf01_2.txt' should 'fail'' > > # in t/verifier.t at line 80. > > > > # Failed test 'determined header had been altered' > > # in t/verifier.t at line 49. > > > > # Failed test ''bad_ietf01_3.txt' should 'fail'' > > # in t/verifier.t at line 80. > > > > # Failed test 'determined RSA failure' > > # in t/verifier.t at line 51. > > # Looks like you failed 18 tests of 22. Needless to say I can't reproduce this. Maybe the failure is transient; verifier.t depends on DNS and the public DKIM key at shan._domainkey.vmt2.cis.att.net being available. Too bad the test script doesn't print more details. -- Magnus Holmgren pgprUqSn5txLc.pgp Description: PGP signature
Bug#312243: Roxen4 shutdown still kills independent mysql instance
found 312243 4.0.425-1 thanks Happens here too. I checked the source package and found that debian/patches/002_default_paths patches /usr/share/roxen4/start with the wrong path. By the way, the init.d script *also* tries to kill the roxen mysql server. I think one kill is enough. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpAiOTgQmyj6.pgp Description: PGP signature
Bug#368468: FTBFS: Forgot to touch patch-stamp?
Monday 22 May 2006 19:18 skrev Bastian Venthur: > Magnus Holmgren wrote: > > Because of the lack of "touch patch-stamp", or anything else that creates > > patch-stamp, in the patch-stamp target, patch-stamp, configure-stamp, and > > build-stamp are redone when debian/rules binary is called. That might not > > be so bad in itself, but the upstream Makefile then tries to create 20 > > directories that already exist, failing miserably. > > Are you sure this is due the lack of patch-stamp? I've encountered this > bug before too but I thought I fixed it with the .NOTPARALLEL target in > debian/rules. The problem was (and still is, as it seems) that this bug > is very hard to reproduce. I believe you should be able to download a source package with apt-get source, possibly fix build dependencies with apt-get build-dep, and then build the binary packages with dpkg-buildpackage -rfakeroot. When I do that, what very deterministically happens is this (after dpkg-buildpackage calls dpkg-source): * dpkg-buildpackage runs debian/rules build, * which runs make. * Makefile creates the output directories. * Makefile makes the various themes (make -C blue_src etc.) * dpkg-buildpackage runs debian/rules binary * which depends on (binary-indep binary-arch), which depend on build, which depends (via build-stamp, configure-stamp, and patch) on patch-stamp, which is never created as a file, * so patching, configuring, and building is done once again, * and Makefile tries to create the same directories again. > I just ran pdebuild 10 times with and 10 times without your suggested > change and had not one single occurrence of the bug you described. I'm not familiar with pdebuild. It's possible that it calls debian/rules goals differently. Just calling debian/rules clean followed by debian/rules binary works, for example. > I know this bug too, but I'm currently not able to reproduce. It looks > like some race condition or something. > > > So, in debian/rules, > > > > touch patch-stamp > > > > at the end of the patch-stamp target should suffice. > > Although I doubt that this will fix the bug, I agree that a touch > patch-stamp is missing. > > So what do we do now? From my point of view, the missing patch-stamp > itself is not a grave bug (although it *is* missing) and the FTBFS seems > to be unrelated to the patch-stamp issue -- at least for me, since I'm > not able to reproduce. > > On the other side: If you can reproduce this bug (e.g. it happens all > the time without patch-stamp) and could confirm that adding your patch > closes the bug, I'd be convinced. > > If you cannot reproduce this bug deterministically too, I'd suggest to > downgrade this bug to minor since the missing patch-stamp does not cause > a FTBFS for CC and hunt for the other bug in a separate bug report. Adding "touch patch-stamp" very deterministically fixes the problem for me (i.e. dpkg-buildpackage works), since the build target isn't called again. But upstream should also fix the Makefile. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp3fhaDxIh8J.pgp Description: PGP signature
Bug#368468: FTBFS: Forgot to touch patch-stamp?
Package: crystalcursors Version: 1.1.1-6 Severity: grave Tags: patch Because of the lack of "touch patch-stamp", or anything else that creates patch-stamp, in the patch-stamp target, patch-stamp, configure-stamp, and build-stamp are redone when debian/rules binary is called. That might not be so bad in itself, but the upstream Makefile then tries to create 20 directories that already exist, failing miserably. I think that the "dpatch call-all -a=pkg-info > patch-stamp" found in dpatch(1) is just an example and irrelevant with simple dpatches. So, in debian/rules, touch patch-stamp at the end of the patch-stamp target should suffice. In addition, tell upstream to fix the Makefile so that it does nothing when nothing needs to be done, instead of failing. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpikb39IyhC2.pgp Description: PGP signature
Bug#363059: Bug #363059 still not fixed: Fails to install, missing dir to create alternatives.
reopen 363059 thanks I think you made a mistake somehow. In debian/rules you (still) delete the usr/share/icons/default directory soon after dh_installdirs create it: # Don't overwrite system's default xcursor rm -r $(CURDIR)/debian/crystalcursors/$(ICONDIR)/default I think you should change this to rm -r $(CURDIR)/debian/crystalcursors/$(ICONDIR)/default/* or patch Makefile not to copy index.theme there. Ironically, all *_src/Makefiles create the default directory if it doesn't exist. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpboxnR10Og9.pgp Description: PGP signature
Bug#355855: Putting the internal database in /var/cache/roxen4 violates the FHS
Package: roxen4 Version: 4.0.325-6 Severity: serious Justification: Policy 9.1.1 Even if the "local" database only contains cached data, the "roxen" database and any user-defined databases don't. Therefore the FHS, which states that "[t]he application must be able to regenerate or restore the data", is violated. I think it would be better to put everything under /var/lib instead, possibly making /var/lib/roxen4/local a symlink to /var/cache/roxen4/local. $pcdir could also be left where it is now, if possible. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (90, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-proffe-1 Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Versions of packages roxen4 depends on: ii debconf 1.4.71 Debian configuration management sy ii hostname 2.91utility to set/show the host name ii mysql-server-5.0 [mysql-serv 5.0.18-8mysql database server binaries ii pike7.6-image7.6.67-1Image module for Pike ii pike7.6-mysql7.6.67-1Mysql module for Pike ii procps 1:3.2.6-2.1 /proc file system utilities roxen4 recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
