Bug#1016963: Please test u-boot for nanopi_neo2
On Wed, Dec 28, 2022 at 04:16:13PM -0800, Vagrant Cascadian wrote: > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > >> On 2022-08-20, Vagrant Cascadian wrote: > >>> On 2022-08-10, Vagrant Cascadian wrote: > This bug is just to delay migration to testing while more platforms get > tested. If you have a relevent board, please consider testing and > reporting the status: > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental > > (2023.01-rc*) and updating the wiki page if successful and/or replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > nanopi_neo2 Done for all my boards, both with unstable and experimental versions. Thanks. Dom > > live well, > vagrant -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1017440: pahole: Several tools just segfault
severity -1 important thanks On Tue, Aug 16, 2022 at 01:12:55PM +0200, Guillem Jover wrote: > Package: pahole > Version: 1.23-2 > Severity: serious > > Hi! Hi Guillem! > Many of the tools simply segfault when executed. On a shared library > with debugging symbols: > > $ codiff libsysfs.so.2.0.1 libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ dtagnames libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ prefcnt libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ scncopy -s data -o output libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ syscse libsysfs.so.2.0.1 > Segmentation fault (core dumped) > > On a stripped library: > > $ codiff /usr/lib/x86_64-linux-gnu/libbsd.so.0 \ >/usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ dtagnames /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ prefcnt /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ scncopy -s data -o output /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ syscse /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > > Some even with no arguments: > > $ dtagnames > Segmentation fault (core dumped) > $ prefcnt > Segmentation fault (core dumped) Thank you for reporting, I added a smoke test that tries to use all these tools and can be used to track the overall state. I've not the time to dig into these failures but I'll report them to the upstream developers. Given that the package is far from being unusable, I'm reducing its severity to important. > > Thanks, > Guillem > Regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#978681: Ignore my previous message, sent by mistake
Hi, Please ignore my previous message, was sent by mistake. Apologies for the spam. Regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978681: +pending
set -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#922112: Add the SPDX header to include/linux/hash.h
From: Domenico Andreoli It is unlikely that who contributes to this file is unaware of the kernel licensing but bringing the license statement into the file itself makes it properly reusable in different contexts. CC: Daniel Borkmann CC: Francesco Fusco CC: George Spelvin CC: Hannes Frederic Sowa CC: Ian Campbell CC: Jay Vosburgh CC: Jens Axboe CC: Linus Torvalds CC: Masami Hiramatsu CC: Matthew Wilcox CC: Nadia Yvette Chambers CC: Pavel Emelyanov Signed-off-by: Domenico Andreoli --- include/linux/hash.h |2 ++ 1 file changed, 2 insertions(+) Index: b/include/linux/hash.h === --- a/include/linux/hash.h +++ b/include/linux/hash.h @@ -1,3 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + #ifndef _LINUX_HASH_H #define _LINUX_HASH_H /* Fast hashing routine for ints, longs and pointers.
Bug#922112: fio: hash.h is not DFSG compliant
Package: fio Severity: grave According to debian/copyright, hash.h is licensed as GPL-2+ but this is not true. There is not any mention of license attribution in its verifiable history, not by its copyright holder or anybody else on their behalf. Thanks to Ulrich Mueller for the relevant research [0]. Similar bug is reported to package dwarves [1], which includes on older copy of this same file. Regards, Domenico [0] https://lkml.org/lkml/2019/2/11/773 [1] https://bugs.debian.org/919356 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Licensing of include/linux/hash.h
On Mon, Feb 11, 2019 at 12:08:32AM +0100, Kristian Fiskerstrand wrote: > On 1/23/19 9:50 AM, Domenico Andreoli wrote: > > Ben Finney writes: > >> Domenico Andreoli writes: [...] > >>> the only knot left is now the license of hash.h > >>> > >>> This file is also present in the kernel [0] with an updated copyright > >>> but still without license. [...] > >> To know that work (that file) is free software, we need a clear grant of > >> some specific license, for that work. > >> > >> If the work is not free, it would be incorrect to have the work in Debian. > > > > Is it possible that for the kernel it is instead correct because it is, > > as whole, covered by its COPYING? > > > >> Alternatives, for complying with the Debian Free Software Guidelines with > >> this package, include: > >> > >> * Find a credible grant of license under some GPL-compatible free > >> license to that exact file. Document that explicit grant in the Debian > >> package. This demonstrates the work is DFSG-free. > >> > >> * Convince ???dwarves-dfsg??? upstream to replace that file with a > >> different > >> implementation (I don't know whether such an implementation exists) > >> under a license compatible with the same version of GNU GPL. Document > >> that explicit grant in the Debian package. This demonstrates the > >> modified work is DFSG-free. > >> > >> * Replace that file in Debian only, with a different implementation as > >> above. Document that explicit grant in the Debian package. This > >> demonstrates the modified Debian package is DFSG-free. > >> > >> * Move the work to the ???non-free??? area. > >> > >> * Remove the work altogether. > >> > >> Those are in descending order of (my recommended) preference. [...] > It was [pointed out] by one of our license group that [hash.h] is the > same that has a GPL-2+ in [fio] which has a signed-off-by. > > References: > [pointed out] > https://bugs.gentoo.org/677586#c1 > > [hash.h] > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c Yes, the Signed-off-by is from Jens Axboe (in CC) but he's not the original author, I guess he just copied the file as Arnaldo did. The file he committed has not any reference to the license. > [fio] > https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright I'm afraid that this entry in wrong. I'll seek confirmation with Martin Steigerwald. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Licensing of include/linux/hash.h
Ben Finney writes: > Domenico Andreoli writes: > > > the situation of dwarves-dfsg improved a lot over the weekend > > That's good to hear. What is the event you're referring to? Can you give > a URL to something that describes this change? Upstream (in CC) reacted to my request of clarification and patches have been applied upstream and on Salsa. See bug 919356 [0] (please keep in CC). > > the only knot left is now the license of hash.h > > > > This file is also present in the kernel [0] with an updated copyright > > but still without license. > > The file you show (in the Linux code base) seems likely to have an > equivalent implementation under a different license, from some other > code base. This will require research and work unlikely to be done before Buster release. Are we going to drop this package for now? > > I received a private email from somebody in the kernel community who > > already tried to contact Nadia in the past but did not get any reply. > > Thank you also for contacting the Linux developers forum to ask > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>. (also in CC now) > > I think that pushing it to non-free is formally the right thing but I > > actually feel it's not the right thing. > > To know that work (that file) is free software, we need a clear grant of > some specific license, for that work. > > If the work is not free, it would be incorrect to have the work in Debian. Is it possible that for the kernel it is instead correct because it is, as whole, covered by its COPYING? > Alternatives, for complying with the Debian Free Software Guidelines with > this package, include: > > * Find a credible grant of license under some GPL-compatible free > license to that exact file. Document that explicit grant in the Debian > package. This demonstrates the work is DFSG-free. > > * Convince ‘dwarves-dfsg’ upstream to replace that file with a different > implementation (I don't know whether such an implementation exists) > under a license compatible with the same version of GNU GPL. Document > that explicit grant in the Debian package. This demonstrates the > modified work is DFSG-free. Arnaldo, what priority would you give to this task? > > * Replace that file in Debian only, with a different implementation as > above. Document that explicit grant in the Debian package. This > demonstrates the modified Debian package is DFSG-free. > > * Move the work to the ‘non-free’ area. > > * Remove the work altogether. > > Those are in descending order of (my recommended) preference. Thanks, Domenico [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Fw: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
[need to re-CC debian-legal again, sorry.] On Tue, Jan 22, 2019 at 06:05:37PM +0100, Domenico Andreoli wrote: > On Mon, Jan 21, 2019 at 03:58:19PM +, MJ Ray wrote: > > Missed the bug off the CC for this. Sorry. > > It seems it did not arrive to debian-legal either. > > > Begin forwarded message: > > > > Date: Mon, 21 Jan 2019 13:34:13 + > > From: MJ Ray > > To: debian-le...@lists.debian.org > > Subject: Re: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear > > > > > > Domenico Andreoli skribis: > > > > > the situation of dwarves-dfsg improved a lot over the weekend, the > > > only knot left is now the license of hash.h > > > > > > This file is also present in the kernel [0] with an updated copyright > > > but still without license. > > > > > > I received a private email from somebody in the kernel community who > > > already tried to contact Nadia in the past but did not get any reply. > > > [...] > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h > > > > > > > One of the commits to that file is from Nadia. Sorry if I'm being > > dense, but where does the doubt that it is under the kernel's licence > > arise? > > The file does not mention any license. While the kernel has its blanket > license, dwarves has not any. > > Can I simply claim it's a GPL-2.0-only? I mean, I think it's reasonable > and, as you said, it's unlikely that Nadia did not notice it was in > the kernel but I wanted a second opinion. > > Do you thin I could even add the SPDX? > > Thanks, > Domenico > > -- > 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Fw: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
On Mon, Jan 21, 2019 at 03:58:19PM +, MJ Ray wrote: > Missed the bug off the CC for this. Sorry. It seems it did not arrive to debian-legal either. > Begin forwarded message: > > Date: Mon, 21 Jan 2019 13:34:13 + > From: MJ Ray > To: debian-le...@lists.debian.org > Subject: Re: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear > > > Domenico Andreoli skribis: > > > the situation of dwarves-dfsg improved a lot over the weekend, the > > only knot left is now the license of hash.h > > > > This file is also present in the kernel [0] with an updated copyright > > but still without license. > > > > I received a private email from somebody in the kernel community who > > already tried to contact Nadia in the past but did not get any reply. > > [...] > > [0] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h > > > > One of the commits to that file is from Nadia. Sorry if I'm being > dense, but where does the doubt that it is under the kernel's licence > arise? The file does not mention any license. While the kernel has its blanket license, dwarves has not any. Can I simply claim it's a GPL-2.0-only? I mean, I think it's reasonable and, as you said, it's unlikely that Nadia did not notice it was in the kernel but I wanted a second opinion. Do you thin I could even add the SPDX? Thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
Hallo d-l, the situation of dwarves-dfsg improved a lot over the weekend, the only knot left is now the license of hash.h This file is also present in the kernel [0] with an updated copyright but still without license. I received a private email from somebody in the kernel community who already tried to contact Nadia in the past but did not get any reply. I need advice on how to handle the package, it is all GPL 2.0 with just this exception. I think that pushing it to non-free is formally the right thing but I actually feel it's not the right thing. Regards, Domenico [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 03:45:03PM -0200, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 18, 2019 at 06:30:38PM +0100, Domenico Andreoli escreveu: > > From: Domenico Andreoli > > > > Hi Arnaldo, > > > > I noticed that some files of pahole come without licensing and > > copyright information, this makes Debian struggle with the redistribution > > and, unfortunately, puts the inclusion of pahole into coming release > > at risk. > > > > For your convenience, I attached a patch that adds the info where > > missing and also adopts the SPDX notation. > > Thanks, I've added the fb team involved in recent changes to this > package so that they are aware of it and can voice any concern, folks > anything to say about this? Is everything okay? > > I'm tentatively adding this to my repo, hope to tag 1.13 soon. Excellent! Would be also nice to have the COPYING file to cover every other file without explicit copyright. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 03:34:04PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 18, 2019 at 03:33:25PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu: > > > On Fri, Jan 18, 2019 at 03:45:03PM -0200, Arnaldo Carvalho de Melo wrote: > > > > Em Fri, Jan 18, 2019 at 06:30:38PM +0100, Domenico Andreoli escreveu: > > > > > From: Domenico Andreoli > > > > > > > > > > Hi Arnaldo, > > > > > > > > > > I noticed that some files of pahole come without licensing and > > > > > copyright information, this makes Debian struggle with the > > > > > redistribution > > > > > and, unfortunately, puts the inclusion of pahole into coming release > > > > > at risk. > > > > > > > > > > For your convenience, I attached a patch that adds the info where > > > > > missing and also adopts the SPDX notation. > > > > > > > > Thanks, I've added the fb team involved in recent changes to this > > > > Hey, is that I problem for me to take your GPG signature as an indicator > > I can add a: > > > > Signed-off-by: Domenico Andreoli > > Or better: > > Signed-off-by: Domenico Andreoli yes, as in my original patch ;) > since that is the one you used in the From: line, ok? > > > ? > > > > > > package so that they are aware of it and can voice any concern, folks > > > > anything to say about this? Is everything okay? > > > No concern on adding the SPDX notation. > > > I would like to add my employer to a few btf files: > > > > > > + Copyright (c) 2018 Facebook > > > > > > > > btf_encoder.c| 6 ++ > > > > > btf_encoder.h| 5 + > > > > > libbtf.c | 6 ++ > > > > > libbtf.h | 6 ++ > > > > > libctf.c | 6 ++ > > > > > > Thanks! > > > Martin > > > > -- > > > > - Arnaldo > > -- > > - Arnaldo -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 08:02:40PM +0100, Domenico Andreoli wrote: > On Fri, Jan 18, 2019 at 03:44:27PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jan 18, 2019 at 03:41:33PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Fri, Jan 18, 2019 at 03:28:33PM -0300, Arnaldo Carvalho de Melo > > > escreveu: > > > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu: > > > > > No concern on adding the SPDX notation. > > > > > I would like to add my employer to a few btf files: > > > > > > > + Copyright (c) 2018 Facebook > > > > > > Sure, I'll add a patch, authored by you, with a signed-off-by you, etc, > > > > CC the group and signed by me as well, just like the kernel process. On > > > > top of Domenico's patch. > > > > > > Now I noticed that the patch adds Copyright entries as well, so I'm > > > fixing it up, as libbtf.[ch] I haven't authored, and btf_encoder.[ch] > > > where authored by Facebook engineers based on ctf_encoder.[ch] that I'm > > > the author, so I'm just fixing these things up in Martin's follow up > > > patch. > > > > End result, ok? > > yes, thanks! > > > > > commit 1610b9b4327d14589800606fc4d31229eb8f1daf > > Author: Martin Lau > > Date: Fri Jan 18 15:42:37 2019 -0300 > > > > Fixup copyright notices for BTF files authored by Facebook engineers > > > > Cc: Andrii Nakryiko > > Cc: Domenico Andreoli > > Cc: Yonghong Song > > Signed-off-by: Martin Lau > > Signed-off-by: Arnaldo Carvalho de Melo > > could please add also mine? well, only to my original patch obviously, not this. > Signed-off-by: Domenico Andreoli > -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 03:44:27PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 18, 2019 at 03:41:33PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Jan 18, 2019 at 03:28:33PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu: > > > > No concern on adding the SPDX notation. > > > > I would like to add my employer to a few btf files: > > > > > + Copyright (c) 2018 Facebook > > > > Sure, I'll add a patch, authored by you, with a signed-off-by you, etc, > > > CC the group and signed by me as well, just like the kernel process. On > > > top of Domenico's patch. > > > > Now I noticed that the patch adds Copyright entries as well, so I'm > > fixing it up, as libbtf.[ch] I haven't authored, and btf_encoder.[ch] > > where authored by Facebook engineers based on ctf_encoder.[ch] that I'm > > the author, so I'm just fixing these things up in Martin's follow up > > patch. > > End result, ok? yes, thanks! > > commit 1610b9b4327d14589800606fc4d31229eb8f1daf > Author: Martin Lau > Date: Fri Jan 18 15:42:37 2019 -0300 > > Fixup copyright notices for BTF files authored by Facebook engineers > > Cc: Andrii Nakryiko > Cc: Domenico Andreoli > Cc: Yonghong Song > Signed-off-by: Martin Lau > Signed-off-by: Arnaldo Carvalho de Melo could please add also mine? Signed-off-by: Domenico Andreoli > > diff --git a/btf_encoder.c b/btf_encoder.c > index 613e7e9a6d43..7aed9b454c1f 100644 > --- a/btf_encoder.c > +++ b/btf_encoder.c > @@ -1,7 +1,12 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > + > + Derived from ctf_encoder.c, which is: > + > + Copyright (C) Arnaldo Carvalho de Melo > + Copyright (C) Red Hat Inc > */ > > #include "dwarves.h" > diff --git a/btf_encoder.h b/btf_encoder.h > index daf5d372986a..80237bb4ca61 100644 > --- a/btf_encoder.h > +++ b/btf_encoder.h > @@ -3,7 +3,10 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > + > + Derived from ctf_encoder.h, which is: > + Copyright (C) Arnaldo Carvalho de Melo > */ > > struct cu; > diff --git a/libbtf.c b/libbtf.c > index 64437f3bd2d9..c6ece9d84de5 100644 > --- a/libbtf.c > +++ b/libbtf.c > @@ -1,7 +1,7 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > */ > > #include > diff --git a/libbtf.h b/libbtf.h > index ef1c49804a20..780f3ec888d7 100644 > --- a/libbtf.h > +++ b/libbtf.h > @@ -1,7 +1,7 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > */ > > #ifndef _LIBBTF_H -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#919356: [PATCH] Add missing licensing info
From: Domenico Andreoli Hi Arnaldo, I noticed that some files of pahole come without licensing and copyright information, this makes Debian struggle with the redistribution and, unfortunately, puts the inclusion of pahole into coming release at risk. For your convenience, I attached a patch that adds the info where missing and also adopts the SPDX notation. I presumed to match your intentions in fact copyright/licensing but please comment back so that I can adapt and hopefully converge quickly. Kind regards, Domenico Signed-off-by: Domenico Andreoli --- btf_encoder.c| 6 ++ btf_encoder.h| 5 + codiff.c | 6 ++ ctf.h| 5 + ctf_encoder.c| 6 ++ ctf_encoder.h| 6 ++ ctracer.c| 6 ++ dtagnames.c | 6 ++ dutil.c | 6 ++ dutil.h | 6 ++ dwarf_loader.c | 6 ++ dwarves.c| 6 ++ dwarves.h| 6 ++ dwarves_emit.c | 6 ++ dwarves_emit.h | 6 ++ dwarves_fprintf.c| 6 ++ dwarves_reorganize.c | 6 ++ dwarves_reorganize.h | 6 ++ elf_symtab.c | 6 ++ elf_symtab.h | 6 ++ elfcreator.c | 6 ++ elfcreator.h | 6 ++ gobuffer.c | 6 ++ gobuffer.h | 6 ++ libbtf.c | 6 ++ libbtf.h | 6 ++ libctf.c | 6 ++ libctf.h | 6 ++ list.h | 6 ++ pahole.c | 6 ++ pdwtags.c| 6 ++ pfunct.c | 6 ++ pglobal.c| 5 + prefcnt.c| 6 ++ rbtree.c | 16 ++-- rbtree.h | 16 ++-- scncopy.c| 6 ++ strings.c| 6 ++ strings.h| 6 ++ syscse.c | 6 ++ 40 files changed, 105 insertions(+), 152 deletions(-) diff --git a/btf_encoder.c b/btf_encoder.c index bfdab27..854434c 100644 --- a/btf_encoder.c +++ b/btf_encoder.c @@ -1,3 +1,9 @@ +/* + SPDX-License-Identifier: GPL-2.0-only + + Copyright (C) 2019 Arnaldo Carvalho de Melo + */ + #include "dwarves.h" #include "libbtf.h" #include "btf.h" diff --git a/btf_encoder.h b/btf_encoder.h index a9d622f..62409f8 100644 --- a/btf_encoder.h +++ b/btf_encoder.h @@ -1,5 +1,10 @@ #ifndef _BTF_ENCODER_H_ #define _BTF_ENCODER_H_ 1 +/* + SPDX-License-Identifier: GPL-2.0-only + + Copyright (C) 2019 Arnaldo Carvalho de Melo + */ struct cu; diff --git a/codiff.c b/codiff.c index a3bee05..8bbc32a 100644 --- a/codiff.c +++ b/codiff.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2006 Mandriva Conectiva S.A. Copyright (C) 2006 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ #include diff --git a/ctf.h b/ctf.h index 6233f6f..25b7989 100644 --- a/ctf.h +++ b/ctf.h @@ -1,5 +1,10 @@ #ifndef _CTF_H #define _CTF_H +/* + SPDX-License-Identifier: GPL-2.0-only + + Copyright (C) 2019 Arnaldo Carvalho de Melo + */ #include diff --git a/ctf_encoder.c b/ctf_encoder.c index ab70254..8f1c0be 100644 --- a/ctf_encoder.c +++ b/ctf_encoder.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2009 Red Hat Inc. Copyright (C) 2009 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ #include "dwarves.h" diff --git a/ctf_encoder.h b/ctf_encoder.h index 91c43d9..16e76e2 100644 --- a/ctf_encoder.h +++ b/ctf_encoder.h @@ -1,12 +1,10 @@ #ifndef _CTF_ENCODER_H_ #define _CTF_ENCODER_H_ 1 /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2009 Red Hat Inc. Copyright (C) 2009 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ struct cu; diff --git a/ctracer.c b/ctracer.c index 710bdab..e4bd5e0 100644 --- a/ctracer.c +++ b/ctracer.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2006 Mandriva Conectiva S.A. Copyright (C) 2006 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ #include diff --git a/dtagnames.c b/dtagnames.c index 16b9987..0ffcbf7 100644 --- a/dtagnames.c +++ b/dtagnames.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2006
Bug#919356: Licensing of include/linux/hash.h
Hi Nadia, As part of the licensing assessment on pahole [0] that I am making for Debian, I realized that file hash.h in both pahole [1] and the kernel [2] comes without any licensing specification. Could you please make an explicit choice and maybe provide patches? Kind regards, Domenico [0] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tree/hash.h [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
Package: dwarves-dfsg Severity: grave This file is without license info: - hash.h These are also without copyright info: - btf_encoder.c - btf_encoder.h - ctf.h - libbtf.c - libbtf.h - libctf.c - libctf.h Though the detailed analysis is not yet complete, it's clear that the copyright/licensing situation does not satisfy DFSG. -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#906769: arm kernels fail to boot
On Wed, Aug 22, 2018 at 4:36 AM Salvatore Bonaccorso wrote: > > Hi, ciao, > On Tue, Aug 21, 2018 at 10:07:42PM +0200, Salvatore Bonaccorso wrote: > > I have put in > > > > https://people.debian.org/~carnil/tmp/linux/arm64/ > > https://people.debian.org/~carnil/tmp/linux/armel/ > > [https://people.debian.org/~carnil/tmp/linux/all/] > > armhf packages: > https://people.debian.org/~carnil/tmp/linux/armhf/ armmp on Allwinner A20: it works. thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#906769: arm kernels fail to boot
On Mon, Aug 20, 2018 at 03:16:52PM -0700, Vagrant Cascadian wrote: > I can confirm this on several machines in the reproducible builds zoo, > running linux-image-4.9.0-8-armmp-lpae version 4.9.110-3+deb9u3. > > What I've noticed is that machines running the "armmp" variant appear to > be unaffected, all of the systems that failed were running the > "armmp-lpae" variant. Two A20-OLinuXino-LIME2 with 4.9.0-8-armmp here, both cannot boot. I don't see any big crash but there are some 'Illegal instruction' towards the end. Thanks. Domenico [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.9.0-8-armmp (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u3 (2018-08-19) [0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt:Machine model: Olimex A20-OLinuXino-LIME2 [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 16 MiB at 0x7f00 [0.00] Memory policy: Data cache writealloc [0.00] psci: probing for conduit method from DT. [0.00] psci: Using PSCI v0.1 Function IDs from DT [0.00] percpu: Embedded 14 pages/cpu @ef6c1000 s27596 r8192 d21556 u57344 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260416 [0.00] Kernel command line: console=ttyS0,115200 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 993148K/1048576K available (7168K kernel code, 1008K rwdata, 2216K rodata, 1024K init, 335K bss, 39044K reserved, 16384K cma-reserved, 245760K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc080 (8160 kB) [0.00] .init : 0xc0b0 - 0xc0c0 (1024 kB) [0.00] .data : 0xc0c0 - 0xc0cfc19c (1009 kB) [0.00].bss : 0xc0cfe000 - 0xc0d51c4c ( 336 kB) [0.00] Hierarchical RCU implementation. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] arm_arch_timer: Architected cp15 timer(s) running at 24.00MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [0.09] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [0.24] Switching to timer-based delay loop, resolution 41ns [0.002745] clocksource: timer: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.003653] clocksource: hstimer: mask: 0x max_cycles: 0x, max_idle_ns: 12741736309 ns [0.004387] Console: colour dummy device 80x30 [0.004434] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=12) [0.004452] pid_max: default: 32768 minimum: 301 [0.004732] Security Framework initialized [0.004747] Yama: disabled by default; enable with sysctl kernel.yama.* [0.004790] AppArmor: AppArmor disabled by boot time parameter [0.004877] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004890] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.006102] CPU: Testing write buffer coherency: ok [0.006173] ftrace: allocating 26775 entries in 79 pages [0.068075] /cpus/cpu@0 missing clock-frequency property [0.068116] /cpus/cpu@1 missing clock-frequency property [0.068130] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.068185] Setting up static identity map for 0x4010 - 0x40100098 [0.073874] EFI services will not be available. [0.085503] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.085732] Brought up 2 CPUs [0.085756] SMP: Total of 2 processors activated (96.00 BogoMIPS). [0.085763] CPU: All CPU(s) started in HYP mode. [0.085769] CPU: Virtualization extensions available. [0.086836] devtmpfs: initialized [0.098345] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 4 [0.098846]
Bug#794977: dselect: no access methods are available
Hi, I'm just speaking out as one of those few users of dselect: please continue to maintain it. It's usually the first package I install on a new Debian-based system I get under my hands. Maybe it does fewer things respect to the alternatives but it does them fast and good enough. I feel always in command with it and I can always sort out what I want quite quickly, no matter how complex is the dependency chain I need to manage. Thanks, Domenico
Bug#706137: libfdt-dev: Missing header file prevents the library usage
Package: libfdt-dev Version: 1.3.0-2 Severity: grave Hi, one file is missing from the binary package and makes it unusable. I get this error: /usr/include/libfdt.h:54:24: fatal error: libfdt_env.h: No such file or directory The following patch should fix the problem. diff --git a/libfdt/Makefile.libfdt b/libfdt/Makefile.libfdt --- a/libfdt/Makefile.libfdt +++ b/libfdt/Makefile.libfdt @@ -4,7 +4,7 @@ # be easily embeddable into other systems of Makefiles. # LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1 -LIBFDT_INCLUDES = fdt.h libfdt.h +LIBFDT_INCLUDES = fdt.h libfdt.h libfdt_env.h LIBFDT_VERSION = version.lds LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o) I'm available for NMUing the package. Best regards, Domenico -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676330: kdbg: FTBFS on mipsel
Package: kdbg Version: 2.5.1-1 Severity: grave Hi, this is the build error on mipsel: Linking CXX executable kdbg cd /build/buildd-kdbg_2.5.1-1-mipsel-aPVTxU/kdbg-2.5.1/obj-mipsel-linux-gnu/kdbg /usr/bin/cmake -E cmake_link_script CMakeFiles/kdbg.dir/link.txt --verbose=1 /usr/bin/c++-Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -g -DNDEBUG -DQT_NO_DEBUG -Wl,--enable-new-dtags CMakeFiles/kdbg.dir/kdbg_automoc.o CMakeFiles/kdbg.dir/pgmargs.o CMakeFiles/kdbg.dir/procattach.o CMakeFiles/kdbg.dir/debugger.o CMakeFiles/kdbg.dir/dbgdriver.o CMakeFiles/kdbg.dir/gdbdriver.o CMakeFiles/kdbg.dir/xsldbgdriver.o CMakeFiles/kdbg.dir/brkpt.o CMakeFiles/kdbg.dir/exprwnd.o CMakeFiles/kdbg.dir/regwnd.o CMakeFiles/kdbg.dir/memwindow.o CMakeFiles/kdbg.dir/threadlist.o CMakeFiles/kdbg.dir/sourcewnd.o CMakeFiles/kdbg.dir/winstack.o CMakeFiles/kdbg.dir/ttywnd.o CMakeFiles/kdbg.dir/typetable.o CMakeFiles/kdbg.dir/prefdebugger.o CMakeFiles/kdbg.dir/prefmisc.o CMakeFiles/kdbg.dir/pgmsettings.o CMakeFiles/kdbg.dir/watchwindow.o CMakeFiles/kdbg.dir/dbgmainwnd.o CMakeFiles/kdbg.dir/main.o -o kdbg -rdynamic /usr/lib/libkdecore.so.5.7.0 /usr/lib/libkio.so.5.7.0 -lutil /usr/lib/mipsel-linux-gnu/libQtNetwork.so /usr/lib/mipsel-linux-gnu/libQtXml.so /usr/lib/libkdeui.so.5.7.0 /usr/lib/libkdecore.so.5.7.0 /usr/lib/mipsel-linux-gnu/libQtDBus.so /usr/lib/mipsel-linux-gnu/libQtCore.so /usr/lib/mipsel-linux-gnu/libQtGui.so /usr/lib/mipsel-linux-gnu/libQtSvg.so /usr/lib/mipsel-linux-gnu/libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3' collect2: ld returned 1 exit status make[3]: *** [kdbg/kdbg] Error 1 make[2]: *** [kdbg/CMakeFiles/kdbg.dir/all] Error 2 make[3]: Leaving directory `/build/buildd-kdbg_2.5.1-1-mipsel-aPVTxU/kdbg-2.5.1/obj-mipsel-linux-gnu' make[2]: Leaving directory `/build/buildd-kdbg_2.5.1-1-mipsel-aPVTxU/kdbg-2.5.1/obj-mipsel-linux-gnu' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-kdbg_2.5.1-1-mipsel-aPVTxU/kdbg-2.5.1/obj-mipsel-linux-gnu' dh_auto_build: make -j1 returned exit code 2 make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 cheers, Domenico [0] http://www.directadmin.com/forum/showthread.php?t=43000page=1 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672607: #672607: pidgin-sipe 1.11 does not use NTLM type authentication and does not connect to Lync server
Hi, using pidgin-sipe 1.13.1-2 here, it works nicely. Thank you. cheers Domenico -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672607: #672607: pidgin-sipe 1.11 does not use NTLM type authentication and does not connect to Lync server
notfound 672607 1.11.2-1.1 thanks On Tue, May 15, 2012 at 11:53 AM, Mònica Ramírez mon...@debian.org wrote: El dl 14 de 05 de 2012 a les 11:25 +0200, en/na Domenico Andreoli va escriure: Hi, same problem here, I confirm the severity. Workaround: downgrade pidgin-sipe to 1.11.2-1. Could you test if it works with 1.11.2-1.1? Maybe last upload broke something :( yes, 1.11.2-1.1 works. cheers, Domenico -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672607: #672607: pidgin-sipe 1.11 does not use NTLM type authentication and does not connect to Lync server
Hi, same problem here, I confirm the severity. Workaround: downgrade pidgin-sipe to 1.11.2-1. Thanks, Domenico -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559638: FTBFS [hppa]: unrecognized command line option -m32
Hi, -m32 is a machine dependent option, on x86 it is used to build 32bit code whereas -m64 is for 64bit code. it is not available on hppa because userland is 32bit only. regards, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559628: FTBFS [hppa]: could not run sample program
hi, i'm rebuilding erlang on my hppa box, just in case anything (like NPTL transition) has changed/improved the erl interpreter behaviour in the meanwhile. stay tuned. cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? in case anyone is interested, the binaries and the build log are here: https://mnl.crema.unimi.it/~cavok/gcc-4.4_4.4.2-2 regards, Domenico [0] https://buildd.debian.org/fetch.cgi?pkg=gcc-4.4ver=4.4.2-1arch=hppastamp=1255927737file=log -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483266: hdbc-sqlite3_1.1.4.0.0(hppa/unstable): FTBFS: segmentation violation
hi, On Wed, Aug 06, 2008 at 08:38:01AM -0500, John Goerzen wrote: [EMAIL PROTECTED] wrote: Package: hdbc-sqlite3 Version: 1.1.4.0.0 Severity: serious There was an error while trying to autobuild your package: Automatic build of hdbc-sqlite3_1.1.4.0.0 on penalosa by sbuild/hppa 98 Build started at 20080527-2141 Would you be able to do a debug build and run the test under gdb, or alternatively give me access to an hppa machine with hugs and libhugs-hdbc installed? I have a spare hppa box, feel free to send me your public ssh key in a signed mail. ciao, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474249: petsc: FTBFS on (my) hppa
Package: petsc Version: 2.3.3-9 Severity: serious It looks like definition of PETSC_MPI in debian/rules is somewhat pesky, probably it is broken by localization issues.. don't know, but on my hppa it comes to udelam instead of lam, which is wrong. I suggest you to rewrite such guessing using readlink command. Regards, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 fakeroot debian/rules clean dh_testdir if [ -e patch ]; then \ debian/rules unpatch; \ fi make[1]: Entering directory `/home/cavok/devel/debian/petsc-2.3.3' for patchfile in `ls --reverse debian/patch-*`; do \ patch -p1 -R $patchfile; \ done patching file src/sys/utils/makefile patching file src/sys/objects/makefile patching file docs/bugreporting.html patching file docs/index.html patching file docs/faq.html patching file python/BuildSystem/config/setCompilers.py patching file python/PETSc/utilities/debugging.py patching file bmake/common/rules.shared.basic rm patch make[1]: Leaving directory `/home/cavok/devel/debian/petsc-2.3.3' mv TAGS thetags dh_clean # These are needed for -lam, -dec and -contrib builds rm -rf debian/libpetsc2.3.3-udelam debian/libpetsc2.3.3-udelam-dev \ debian/libpetsc2.3.3-udelam-dbg mv thetags TAGS rm -f build* install* debian/*.substvars debian/libpetsc2.3.3-udelam-dev.docs debian/libpetsc2.3.3-udelam-dev.postinst debian/libpetsc2.3.3-udelam-dev.prerm # This is commented because it really doesn't do anything useful for us # (removes example executables, so what?) # make PETSC_ARCH=linux-gnu PETSC_DIR=/home/cavok/devel/debian/petsc-2.3.3 clean # These probably should be removed by `make clean' but aren't rm -f `find . -name \*.o -print` `find . -name \*.pyc -print` rm -rf lib debian/extemp bmake/linux-gnu* debian/rules build for patchfile in `ls debian/patch-*`; do \ patch -p1 $patchfile; \ done patching file bmake/common/rules.shared.basic patching file python/PETSc/utilities/debugging.py patching file python/BuildSystem/config/setCompilers.py patching file docs/bugreporting.html patching file docs/index.html patching file docs/faq.html patching file src/sys/utils/makefile patching file src/sys/objects/makefile touch patch PETSC_DIR=/home/cavok/devel/debian/petsc-2.3.3 ./config/configure.py \ --with-debugging=1 \ --useThreads 0 --with-mpi-dir=/usr/lib/udelam \ --with-blas-lib=-lblas --with-lapack-lib=-llapack \ --with-umfpack=1 --with-umfpack-include=/usr/include/suitesparse \ --with-umfpack-lib=[/usr/lib/libumfpack.so,/usr/lib/libamd.so] \ --with-superlu=1 --with-superlu-include=/usr/include/superlu \ --with-superlu-lib=/usr/lib/libsuperlu.so \ --with-spooles=1 --with-spooles-include=/usr/include/spooles \ --with-spooles-lib=/usr/lib/libspooles.so = Configuring PETSc to compile on your system = TESTING: configureExternalPackagesDir from config.framework(/home/cavok/devel/debian/petsc-2.3.3/python/BuildSystem/config/framework.py:807) TESTING: configureLibrary from PETSc.packages.NetCDF(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/packages/NetCDF.py:10) TESTING: configureLibrary from PETSc.packages.PVODE(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/packages/PVODE.py:10) TESTING: configureDebuggers from PETSc.utilities.debuggers(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/utilities/debuggers.py:22) TESTING: configureMake from PETSc.utilities.Make(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/utilities/Make.py:21) TESTING: configureMercurial from config.sourceControl(/home/cavok/devel/debian/petsc-2.3.3/python/BuildSystem/config/sourceControl.py:23) TESTING: configureCVS from config.sourceControl(/home/cavok/devel/debian/petsc-2.3.3/python/BuildSystem/config/sourceControl.py:30) TESTING: configureSubversion from config.sourceControl(/home/cavok/devel/debian/petsc-2.3.3/python/BuildSystem/config/sourceControl.py:35) TESTING: configureMkdir from config.programs(/home/cavok/devel/debian/petsc-2.3.3/python/BuildSystem/config/programs.py:21) TESTING: configurePrograms from config.programs(/home/cavok/devel/debian/petsc-2.3.3/python/BuildSystem/config/programs.py:43) TESTING: configureCLanguage from PETSc.utilities.languages(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/utilities/languages.py:43) TESTING: configureLanguageSupport from PETSc.utilities.languages(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/utilities/languages.py:49) TESTING: configureExternC from PETSc.utilities.languages(/home/cavok/devel/debian/petsc-2.3.3/python/PETSc/utilities/languages.py:66) TESTING: configureFortranLanguage from PETSc.utilities.languages
Bug#474249: #474249 petsc: FTBFS on (my) hppa
retitle 474249 petsc: FTBFS: wrongly guess the MPI directory tags 474249 +patch thanks On Fri, Apr 04, 2008 at 04:58:26PM +0200, Domenico Andreoli wrote: It looks like definition of PETSC_MPI in debian/rules is somewhat pesky, probably it is broken by localization issues.. don't know, but on my hppa it comes to udelam instead of lam, which is wrong. I suggest you to rewrite such guessing using readlink command. --- rules.orig 2008-04-04 17:02:38.0 +0200 +++ rules 2008-04-04 17:07:00.0 +0200 @@ -26,7 +26,7 @@ # Note that as of PETSc 2.3.0 this only specifies the name of the PETSc # packages, the implementation is chosen by BuildSystem according to what's # available at build time. -PETSC_MPI=$(shell ls -l /etc/alternatives/mpi | cut -b 74- | sed s/include//g | sed s/lib//g | sed s/\\///g) +PETSC_MPI=$(shell readlink /etc/alternatives/mpi | xargs basename) PETSC_MPI_DIR=/usr/lib/$(PETSC_MPI) # Overriding this with contrib attempts to link with hypre and parmetis. -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461236: boost vulnerabilities (was [pkg-boost-commits] r14144 - in boost/trunk: ...)
On Sun, Jan 20, 2008 at 05:32:03PM -0600, Steve M. Robbins wrote: Hi all, Hi, I do understand that derivative distributions such as Ubuntu do put their own release entries in there. I imagine the Ubuntu users understand that and can differentiate the Ubuntu release from the Debian one in some fashion. However, I think that the pure Debian changelog should include only entries for Debian releases. I agree with you in the principle. As a principle, I do not find that strange if things actually go differently. Anyway I have not any strong preference, feel free to modify things at you wish. By the way, I notice that entry is targeted at experimental; what is the plan here? This fix looks fine for unstable, no? Are you planning some further not-for-unstable modifications? Experimental because agreement for unstable has still to be found with RMs, Boost is again in the middle of a transition. I am hereby asking RMs their advice. cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442338: Fwd: Bug#442338: FTBFS: error: 'CURLE_FTP_USER_PASSWORD_INCORRECT' was not declared in this scope
severity 442338 normal thanks On Sat, Sep 15, 2007 at 10:16:49PM +0200, Daniel Stenberg wrote: On Sat, 15 Sep 2007, Domenico Andreoli wrote: curl 7.17.0 breaks the build of openoffice.org. Rene has already found the cause, it is described below. Eh, no. curl 7.17.0 does *not* break this as you will see below. better :) Is it only a formal error by the curl side or openoffice.org requires to be upgraded to the new API? The error code CURLE_FTP_USER_PASSWORD_INCORRECT has been moved to the list of codes that will be removed in the future, and thus it isn't present if you define CURL_NO_OLDIES when you build. So if you want backwards-compatible style you *don't* define CURL_NO_OLDIES and you can use that define fine still. If you define it, you should be prepared to edit some of the codes to the up-to-date versions. so I do not need to do anything.. great! ;) hmm.. no, I should really change this bug severity. Thank Daniel for the fast response! You always are my best upstream developer. Cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442338: Fwd: Bug#442338: FTBFS: error: 'CURLE_FTP_USER_PASSWORD_INCORRECT' was not declared in this scope
Hi all, curl 7.17.0 breaks the build of openoffice.org. Rene has already found the cause, it is described below. Is it only a formal error by the curl side or openoffice.org requires to be upgraded to the new API? Regards, Domenico On Sat, Sep 15, 2007 at 04:25:52PM +0200, Rene Engelhard wrote: Hi, Frank Lichtenheld wrote: your package failed to build from source. because curl broke afais. [...] | Making: ../../../unxlngs.pro/slo/ftpcontent.obj | g++ -fmessage-length=0 -c -O2 -fno-strict-aliasing -DCURL_NO_OLDIES -I. -I../../../unxlngs.pro/inc/ucpftp -I../inc -I../../../inc/pch -I../../../inc -I../../../unx/inc -I../../../unxlngs.pro/inc -I. -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solver/680/unxlngs.pro/inc/stl -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solver/680/unxlngs.pro/inc/external -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solver/680/unxlngs.pro/inc -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solenv/unxlngs/inc -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solenv/inc -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/res -I/build/buildd/openoffice.org-2.3.0~rc3/stlport/stlport -I/build/buildd/openoffice.org-2.3.0~rc3/stlport/include/stlport -I/build/buildd/openoffice.org-2.3.0~rc3/stlport/include/stlport -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solenv/inc/Xp31 -I/usr/lib/jvm/java-gcj/include -I/usr/include -I/build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/solver/680/unxlngs.pro/inc/offuh -I. -I../../../res -I. -pipe -g1 -Wreturn-type -Wno-ctor-dtor-privacy -fPIC -DLINUX -DUNX -DVCL -DGCC -DC300 -DSPARC -DCVER=C300 -DNPTL -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DSPARC -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DGSTREAMER -DCUI -DSOLAR_JAVA -DOOG680=OOG680 -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../../unxlngs.pro/slo/ftpcontent.o /build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/ucb/source/ucp/ftp/ftpcontent.cxx | /build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/ucb/source/ucp/ftp/ftpcontent.cxx: In member function 'virtual com::sun::star::uno::Any ftp::FTPContent::execute(const com::sun::star::ucb::Command, sal_Int32, const com::sun::star::uno::Referencecom::sun::star::ucb::XCommandEnvironment)': | /build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/ucb/source/ucp/ftp/ftpcontent.cxx:587: error: 'CURLE_FTP_USER_PASSWORD_INCORRECT' was not declared in this scope | /build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/ucb/source/ucp/ftp/ftpcontent.cxx:588: error: 'CURLE_BAD_PASSWORD_ENTERED' was not declared in this scope | /build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/ucb/source/ucp/ftp/ftpcontent.cxx:591: error: 'CURLE_FTP_ACCESS_DENIED' was not declared in this scope | /build/buildd/openoffice.org-2.3.0~rc3/ooo-build/build/OOG680_m5/ucb/source/ucp/ftp/ftpcontent.cxx:593: error: 'CURLE_FTP_QUOTE_ERROR' was not declared in this scope | dmake: Error code 1, while making '../../../unxlngs.pro/slo/ftpcontent.obj' | ---* tg_merge.mk *--- Looking at curl 7.16.4, I see this defined in curl.h as 10: $ grep -r CURLE_FTP_USER_PASSWORD_INCORRECT /usr/include/curl/* /usr/include/curl/curl.h: CURLE_FTP_USER_PASSWORD_INCORRECT, /* 10 -NOT USED */ in an enum. Now, with 7.17.0: $ grep -r CURLE_FTP_USER_PASSWORD_INCORRECT /usr/include/curl/* /usr/include/curl/curl.h:#define CURLE_FTP_USER_PASSWORD_INCORRECT CURLE_OBSOLETE10 $ grep -r CURLE_OBSOLETE10 /usr/include/curl/* /usr/include/curl/curl.h: CURLE_OBSOLETE10, /* 10 - NOT USED */ /usr/include/curl/curl.h:#define CURLE_FTP_USER_PASSWORD_INCORRECT CURLE_OBSOLETE10 with CURLE_OBSOLETE10 now being in the enum. It seems that curl wanted to keep compatibility but actually broke it because the subsitution doesn't work? Reassigning a clone to curl. -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Bug#429533: new proposal: boost-config
Hi, Suppose two systems, a Fedora based on gcc 4.1 and a Debian based on gcc 4.2, both sporting Boost 1.35.0 built with --layout=system, for simplicity. Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen? BTW, the user is a free software developer and his app is going to be ported also to other Microsoft, UNIX and popular embedded operating systems, where Boost has been built mixing --layout=system and --layout=versioned. Now he faces the problem of linking to the Boost library of interest. How he is supposed to solve the problem? This is a new summary of the binary and source portability problems that current build system is inflicting on the Boost libraries. My proposal is: 1) dump the --layout= thing, versioned/decorated sonames are always used 2) provide symlinks like the following, when appropriate: /usr/lib/libboost_date_time-gcc42-1_34_1.so - libboost_date_time-gcc42-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-d-1_34_1.so - libboost_date_time-gcc42-d-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-1_34_1.so - libboost_date_time-gcc42-mt-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-d-1_34_1.so - libboost_date_time-gcc42-mt-d-1_34_1.so.1.34.1 3) provide also these symlinks, if desired: /usr/lib/libboost_date_time.so - libboost_date_time-gcc42-1_34_1.so /usr/lib/libboost_date_time-d.so - libboost_date_time-gcc42-d-1_34_1.so /usr/lib/libboost_date_time-mt.so - libboost_date_time-gcc42-mt-1_34_1.so /usr/lib/libboost_date_time-mt-d.so - libboost_date_time-gcc42-mt-d-1_34_1.so 4) add more decorations as required. e.g. Python version to Boost.Python library name. This way multiple Boost.Python libraries, every built with a different Python version, could coexist on the same system. 5) provide a program, say boost-config, that may be invoked to find the right build parameters for a given library, toolset and variant(s). some examples (suppose default compiler is gcc 4.0, the one used to build Boost): $ boost-config --name=DateTime --ldflags -lboost_date_time-gcc40-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.1 --variant=mt,d --ldflags -lboost_date_time-gcc41-mt-d-1_34_1 $ boost-config --name=Threads --toolset=gcc-4.2 --ldflags -lboost_threads-gcc42-mt-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.2 --variant=python-2.5 --ldflags Error: unknown variant python-2.5 for the given library $ boost-config --name=Python --variant=python-2.4 --ldflags -lboost_python-gcc40-python24-1_34_1 $ boost-config --name=Python --toolset=gcc-4.2 --variant=python --cxxflags -I/usr/include/python if toolset is omitted, the default system compiler is used, if any (e.g. cc/c++ under linux), otherwise an error is reported. Point 1) is really optional. In case --layout is kept, the subsequent points would be related only to --layout=versioned and --layout=system should be documented as source of any sort of portability issues. Point 2) is required only on UNIX systems where GNU ld is used, it might have not sense with other linkers. Every linker has its own story. Point 3) is applicable only where 2) is and would be handy only when source portability is not an issue, to the user discretion. Big warning about source portability should be placed nearby its documentation. Point 4) would allow packaging Boost.Python on distributions in which multiple versions of Python may be available. Point 5) is the way to the complete source portability, at least across sane systems (read, probably not Windows/MSVC). Note that if Boost is built using a compiler different from the one asked to boost-config, the linker will complain about the inexistent library. It would be easy to make boost-config extract allowed parameter combinations from an XML file built by Boost.Build at build time. That's all, good night. Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429533: [pkg-boost-devel] Bug#429533: dev package changes and its severity
On Thu, Jul 19, 2007 at 12:08:08AM +0200, Ji??í Pale??ek wrote: Hello, hi, Boost library naming is described in the documentation [0]. [0] http://www.boost.org/more/getting_started/unix-variants.html#library-naming Which does not mean it is correct for libboost-*-dev to silently change its interface (.so library naming). Moreover, if you have carefully read the document you're pointing to, you'd find there's nothing about -st. Only -mt or absence of -mt i am aware of this and i don't like -st that much. before having -st, there was only absence of any -st and -mt which pointed to -mt. quite disgusting. cheers, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426871: [pkg-boost-devel] Bug#426871 closed by Domenico Andreoli [EMAIL PROTECTED] (Bug#426871: fixed in boost 1.34.0-3)
On Tue, Jun 26, 2007 at 12:05:49PM +0200, Michal ??iha?? wrote: Hi hi, On Tue, 26 Jun 2007 11:55:40 +0200 Domenico Andreoli [EMAIL PROTECTED] wrote: say that i changed my mind after the announce of the imminent transition to python 2.5 as default :) anyway those -2 and -3 were already in the queue... The only question is how imminent it really it, based on experiences from previous transitions, it took always longer than expected ;-). boost is not a light thing to turn from a compiler/python version to another. it always passes from the NEW queue (ftp-masters are surely starting to hate me) and a rebuild of all its reverse dependant packages. so i try to foresee the Next Thing and prepare boost for it in experimental. sometimes it takes weeks to pass throught the NEW queue, sometimes (like yesterday) it takes hours. Well I'd really like to have a solution for this. Current tagpy is uninstallable because old boost libraries have been removed, it FTBFS because something changed in boost what needs minor change in sources. However if I upload this version to fix FTBFS, I will get version which will not work with default python, what is again bad as it is against Python policy and breaks applications using it. i'd say to build it with pytohn 2.5. it will installable, it will build from source and it will ok with the next default python version. you fix 2 RC and you get 1 RC. not the best, but something better.. :} moreover, the only rdepend of tagpy is yours and it is an application. so it should not be that great tragedy to make it use python 2.5 in advance respect the whole archive for some time. ciao, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426871: [pkg-boost-devel] Bug#426871 closed by Domenico Andreoli [EMAIL PROTECTED] (Bug#426871: fixed in boost 1.34.0-3)
On Tue, Jun 26, 2007 at 10:06:48AM +0200, Michal ??iha?? wrote:
Hi
hi,
On Mon, 25 Jun 2007 21:03:26 +
[EMAIL PROTECTED] (Debian Bug Tracking System) wrote:
This is an automatic notification regarding your Bug report
#426871: Does not work with default python,
which was filed against the libboost-python1.34.0 package.
Changes:
boost (1.34.0-3) experimental; urgency=low
.
* Build with python 2.4 (closes: #426871).
* Drop ${Source-Version} substvar from rules.
Was it intentional to upload this version to experimental? There already
is newer version which is still using python 2.5...
say that i changed my mind after the announce of the imminent transition
to python 2.5 as default :) anyway those -2 and -3 were already in
the queue...
this bug results closed for the wrong motivation, feel free to reopen
it if you think is appropriate.
cheers
domenico
-[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429533: [pkg-boost-devel] Bug#429533: dev package changes and its severity
On Tue, Jun 19, 2007 at 11:17:02PM +0900, Junichi Uekawa wrote: Hi, hi, I've browsed through the bug logs, but this is ugly. yes, it is We're breaking all those APIs, and there is no sane way of finding out what to use. we? who? breaking those APIs? it is only a matter of fixing the already broken library name used to link with programs. i don't see anything broken. Also, please keep the severity of those bugreports to 'grave', since they cause FTBFS on all the other packages. if those packages used the right library name, they would not be interested by this change. I am wondering why libboost needs to be special-cased to especially supply a '-st' version. Why not force everyone to use '-mt'? special-cased respect who? to not be special case, the single thread would not have the -st and the multi thread would have the -mt. which is the countrary of what you are asking. that is the reason of my change. ciao domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429533: [pkg-boost-devel] Bug#429533: Bug#429533: dev package changes and its severity
Hi, On Tue, Jun 26, 2007 at 11:25:43PM +0900, Junichi Uekawa wrote: Please elaborate 'right library name' Boost library naming is described in the documentation [0]. Cheers, Domenico [0] http://www.boost.org/more/getting_started/unix-variants.html#library-naming -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429533: [pkg-boost-devel] Bug#429533: Bug#429533: Bug#429533: dev package changes and its severity
On Wed, Jun 27, 2007 at 05:30:21AM +0900, Junichi Uekawa wrote: Hi, hi, Boost library naming is described in the documentation [0]. [0] http://www.boost.org/more/getting_started/unix-variants.html#library-naming Which does not mean it is correct for libboost-*-dev to silently change its interface (.so library naming). no, silently not. the real bug from my POW is that I did not announced the change. Why not just provide -pthread version (-mt) per default and provide -st version for people who really care? because using -mt versions in place of -st is suboptimal in a way i am not able to evaluate. if building c++ as multi-threaded had a negligible impact, -pthread switch would be the default. moreover careful people is usually the one using multi-threaded stuff, not the opposite. cheers, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425923: [pkg-boost-devel] Bug#425923: quantlib: FTBFS with new boost libraries
On Fri, May 25, 2007 at 12:23:49PM -0500, Dirk Eddelbuettel wrote: basebud:/var/local/cache/apt-proxy/debian/pool/main/b/boost# dpkg -c libboost-test1.34.0_1.34.0-1_i386.deb drwxr-xr-x root/root 0 2007-05-14 09:24 ./ drwxr-xr-x root/root 0 2007-05-14 09:23 ./usr/ drwxr-xr-x root/root 0 2007-05-14 09:24 ./usr/lib/ -rw-r--r-- root/root 22560 2007-05-14 09:24 ./usr/lib/libboost_prg_exec_monitor-gcc41-mt-1_34.so.1.34.0 -rw-r--r-- root/root 22544 2007-05-14 09:24 ./usr/lib/libboost_prg_exec_monitor-gcc41-1_34.so.1.34.0 -rw-r--r-- root/root263444 2007-05-14 09:24 ./usr/lib/libboost_unit_test_framework-gcc41-1_34.so.1.34.0 -rw-r--r-- root/root263460 2007-05-14 09:24 ./usr/lib/libboost_unit_test_framework-gcc41-mt-1_34.so.1.34.0 drwxr-xr-x root/root 0 2007-05-14 09:23 ./usr/share/ drwxr-xr-x root/root 0 2007-05-14 09:23 ./usr/share/doc/ drwxr-xr-x root/root 0 2007-05-14 09:24 ./usr/share/doc/libboost-test1.34.0/ -rw-r--r-- root/root 3600 2005-03-31 01:06 ./usr/share/doc/libboost-test1.34.0/README.Debian -rw-r--r-- root/root 29069 2004-03-05 23:54 ./usr/share/doc/libboost-test1.34.0/copyright -rw-r--r-- root/root 6855 2007-05-14 07:27 ./usr/share/doc/libboost-test1.34.0/changelog.Debian.gz basebud:/var/local/cache/apt-proxy/debian/pool/main/b/boost# dpkg -f libboost-test1.34.0_1.34.0-1_i386.deb Boosters: Could this be your bug that I have to use g++ 4.1 ? this is because upstream does not trust in compilers ABI stability even across the same producer (they do not cover it in the test suite). anyway i never thought of making this an explicit dependency, as it should. indeed currently it is possible to use the boost libraries with a compiler different from the one used to build them. dirk, are you working at autoconf tests to guess boost linking params? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423351: E: Package libcurl3 has no installation candidate
hi Robin, On Fri, May 11, 2007 at 11:10:05AM +0200, Robin van Westrenen wrote: tribbin:/home/robin# apt-get install libcurl3 Reading package lists... Done Building dependency tree... Done Package libcurl3 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libcurl3 has no installation candidate I use the standard ftp.nl.debian.org repository. indeed the package has been superseded by libcurl4. whatever package still depends on libcurl3 needs to be rebuilt using the new version and this bug belongs to it, not to libcurl3. which is such package? regards domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423446: pycurl_7.15.5-1 (unstable): FTBFS: versioned build-dep on libucrl3-gnutls-dev
On Fri, May 11, 2007 at 03:04:58PM -0700, Steve Langasek wrote: Hi Domenico, Hi Steve, You might have heard about the libcurl3 - libcurl4 transition in unstable. ;) One of your packages, pycurl, is failing to build because it has a versioned build-dependency on libcurl3-gnutls-dev, which of course is now a virtual package: dpkg-checkbuilddeps: Unmet build dependencies: libcurl3-gnutls-dev (= 7.15.4-1) dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. I had already figured out this preparing new upstream release... :/ Please update your build dependencies to the new package name so that the curl transition can proceed to testing once glibc is unblocked. I will do it soon, thank you. Cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423246: kernel-patch-2.6-reiser4: should this package be orphaned?
severity 423246 normal reassign 423246 wnpp retitle 423246 O: kernel-patch-2.6-reiser4 -- Kernel patches for Reiser4 FS thanks On Thu, May 10, 2007 at 10:14:38PM +0200, Lucas Nussbaum wrote: Hi, hi Lucas, While reviewing packages that were not included in Etch, your package came up as a package that should maybe be orphaned by its maintainer, because: * RC buggy for a long time (doesn't work with the current kernel), no action from the maintainer If you think that it should be removed from Debian instead of being orphaned, please reply to this bug and tell so. i know i should not wait for someone else to wake me on some package of mine, but i really lost the interest for this package since they started providing patches against -mm kernel tree. i'm reassigning to debian-qa but if nobody steps in i would make request for removal. thank you for the time spent after lazy DDs. regards, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422849: git-core: FTBFS - test suite fails
On Wed, May 09, 2007 at 01:26:36PM +, Gerrit Pape wrote: On Tue, May 08, 2007 at 06:05:50PM +0200, Domenico Andreoli wrote: is there a way to pass -v down from debian/rules? maybe fakeroot is messing here... Adding GIT_TEST_OPTS=-v to OPTS should work. Regards, Gerrit. i already figured out how to achieve this. thanks. domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422849: git-core: FTBFS - test suite fails
severity 422849 important thanks On Wed, May 09, 2007 at 01:05:47PM +, Gerrit Pape wrote: On Tue, May 08, 2007 at 06:05:50PM +0200, Domenico Andreoli wrote: On Tue, May 08, 2007 at 01:45:30PM +, Gerrit Pape wrote: can you please, after the build failure, do $ (cd t sh t1400-update-ref.sh -v) this works. the next build failed elsewhere, but manually the test passed. This is strange, and shouldn't be, -v is just to make the tests verbose. How are you trying to build the package?, as which user, what is the environment, what the command you run? Can you try with pbuilder? i'm using debuild -uc -us -B on a pure sid box used only for debian development. anyway the error was due to some problem loading libraries. i didn't wrote it down, so i'm trying to reproduce it again. it might be from ld, i'm still not sure. in the meanwhile libc6 has been updated... surely it is not from git-core since i read it also in building curl 7.16.2. build of git-core was done using libcurl 7.15.5, the one in testing/stable, so it should not be a fault of libcurl itself. please keep the report open until i'm able to reassing to the right package or close it. thank you. regards domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422849: git-core: FTBFS - test suite fails
Package: git-core Version: 1:1.5.1.3-1 Severity: serious hi, this is where the build fails: ... * ok 27: Query [EMAIL PROTECTED] (past end of history) * ok 28: creating initial files * FAIL 29: git-commit logged updates diff expect .git/logs/refs/heads/master * FAIL 30: git-cat-file blob master:F (expect OTHER) test OTHER = $(git-cat-file blob master:F) * ok 31: git-cat-file blob [EMAIL PROTECTED] 23:30}:F (expect TEST) * FAIL 32: git-cat-file blob [EMAIL PROTECTED] 23:42}:F (expect OTHER) test OTHER = $(git-cat-file blob [EMAIL PROTECTED] 23:42}:F) * failed 3 among 32 test(s) make[2]: *** [t1400-update-ref.sh] Error 1 make[2]: Leaving directory `/home/cavok/git-core-1.5.1.3/t' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/cavok/git-core-1.5.1.3' make: *** [build-arch-stamp] Error 2 debuild: fatal error at line 1228: debian/rules build failed i attached full build log. let me know if i can do anything to help you. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 git-core_1.5.1.3-1_hppa.build.gz Description: Binary data
Bug#422849: git-core: FTBFS - test suite fails
On Tue, May 08, 2007 at 01:45:30PM +, Gerrit Pape wrote: On Tue, May 08, 2007 at 02:49:51PM +0200, Domenico Andreoli wrote: this is where the build fails: ... * ok 27: Query [EMAIL PROTECTED] (past end of history) * ok 28: creating initial files * FAIL 29: git-commit logged updates diff expect .git/logs/refs/heads/master * FAIL 30: git-cat-file blob master:F (expect OTHER) test OTHER = $(git-cat-file blob master:F) * ok 31: git-cat-file blob [EMAIL PROTECTED] 23:30}:F (expect TEST) * FAIL 32: git-cat-file blob [EMAIL PROTECTED] 23:42}:F (expect OTHER) test OTHER = $(git-cat-file blob [EMAIL PROTECTED] 23:42}:F) * failed 3 among 32 test(s) make[2]: *** [t1400-update-ref.sh] Error 1 make[2]: Leaving directory `/home/cavok/git-core-1.5.1.3/t' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/cavok/git-core-1.5.1.3' make: *** [build-arch-stamp] Error 2 debuild: fatal error at line 1228: debian/rules build failed i attached full build log. let me know if i can do anything to help you. can you please, after the build failure, do $ (cd t sh t1400-update-ref.sh -v) this works. the next build failed elsewhere, but manually the test passed. is there a way to pass -v down from debian/rules? maybe fakeroot is messing here... cheers domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419774: .so symlink broken
found 419774 7.16.1-1 notfound 419774 7.16.2-1 thanks On Tue, Apr 17, 2007 at 11:28:00PM +0200, Rene Engelhard wrote: Hi, hi, as you spoke on -release about a curl transition I wanted to do a testbuild an installed libcurl4-openssl-dev. The build breaks: of course! :) .a?! Let's look. [EMAIL PROTECTED]:/usr/lib$ ls -l libcurl* lrwxrwxrwx 1 root root 17 2007-04-17 21:45 libcurl.a - libcurl-openssl.a lrwxrwxrwx 1 root root 23 2007-02-18 12:22 libcurl-gnutls.so.3 - libcurl-gnutls.so.3.0.0 -rw-r--r-- 1 root root 210992 2006-08-07 16:47 libcurl-gnutls.so.3.0.0 lrwxrwxrwx 1 root root 18 2007-04-17 21:45 libcurl.la - libcurl-openssl.la -rw-r--r-- 1 root root 446394 2007-02-10 00:50 libcurl-openssl.a -rw-r--r-- 1 root root977 2007-02-10 00:50 libcurl-openssl.la lrwxrwxrwx 1 root root 24 2007-04-17 21:45 libcurl-openssl.so - libcurl-openssl.so.4.0.0 This one doesn't exist, so... ... but should. indeed libcurl4-openssl-dev should depend on libcurl4-openssl, while it is depending on libcurl4. i just uploaded 7.16.2-1 to experimental, i also fixed this bug. please, cpuld you redo the test with this new version? thank you. Regards, Rene cheers domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Bug#416496: [pkg-boost-devel] Bug#416496: boost_1.33.1+1.34.0-cvs20070221-1(hppa/experimental): FTBFS: linking problems
On Wed, Mar 28, 2007 at 01:44:22PM +0200, Frank Lichtenheld wrote: Hi, hi, your package failed to build from source. this might be the new edition of #334959, which was worked aroud with -mlong-calls. strangely, the switch is passed to bjam but it idoes not arrive to the gcc command line any more. i have to check it. thanks domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358577: gnumeric: uninstallable on sid
Package: gnumeric Version: 1.6.2-3+b1 Severity: serious hi, gnumeric is not installable on sid because of gnumeric-common and gnumeric-doc version being only 1.6.2-3. probably the dependencies on these packages are too strict. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349209: [pkg-boost-devel] Bug#349209: boost: Boost Graph Library is non-free and undistributable in compiled form
On Sun, Mar 12, 2006 at 10:09:34AM -0500, Douglas Gregor wrote: On Feb 5, 2006, at 10:58 AM, Steve M. Robbins wrote: Dear Boost Graph Library Developers, The following is a reply to a bug report from a Debian user [http://bugs.debian.org/349209] pointing out deficiencies in the library licensing, from Debian's point of view. We'd like to know whether the few remaining files NOT available under the Boost Software License may be relicensed. Thanks. The entirety of the Boost Graph Library is has now been relicensed under the Boost Software License. The updated licenses will appear in the next major Boost release (1.34.0), although they also apply to existing releases. great! thank you. i'm going to upload a new debian boost 1.33.1 package with the new copyright info. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349209: boost graph library license RC bug #349209
hi, boost package has a RC bug #349209 due to non-free license of graph library. this issue should be being sorted by Steve M. Robbins and upstream, so i would not make it stop the migration of boost to testing, also considering that testing already has this bug, especially if such migration stalls the one of other packages. while this clearify the situation of unstable/testing, more is to be done for sarge and woody. should the Debian Boost Team provide DFSG-compatible updates for stable and oldstable? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334497: acknowledged by developer (Re: binutils: linking error in building boost)
reopen 334497 thanks On Sun, Jan 15, 2006 at 08:03:06PM -0800, Debian Bug Tracking System wrote: Hi, hi, Given that boost up-to-date for hppa at the moment, I'm assuming this bug has been fixed and closing it. it is up-to-date because it is built using -mlong-calls option which works around this bug. please have a look at #342267. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341174: boost FTBFS on hppa
On Mon, Dec 19, 2005 at 01:29:05PM +0800, Randolph Chung wrote: Is anyone looking into this problem with building boost on hppa? As there are quite a few packages which build-depend on boost (including parts of KDE, and aptitude), this is likely to cause hppa to hold up the c2a transition unless some progress is made here. i'm seeing.. i tried some builds on paer.d.o, to see how new compilers/linkers behavaed with respect to this. maybe latest binutils 2.16.1cvs20051214-1 fixes this... i'm not doing more, sorry. This is a bug in gcc, but while it is being debugged some more, the toolchain actually suggested a workaround for you: /usr/bin/ld: [...] cannot reach 0aae__ZSt10_ConstructIN5boost7archive6detail19basic_iarchive_impl7aobjectES4_EvPT_RKT0_+0, recompile with -ffunction-sections Try adding that flag (-ffunction-sections) to the gcc compile flags for hppa. i just finished to re-check the build with this option. unfortunately it still fails. the log is at http://people.debian.org/~cavok/boost_1.33.0-5_hppa.build. The problem is that a branch instruction on hppa has limited range (17-bits), so if the branch target is too large (this happens often with large problems, especially c++ code with lots of templates), the toolchain needs to add special stubs for far branches. gcc has logic to figure this out, but sometimes its calculations do not match what binutils calculates. thank you for the first explanation i read about this error message. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341174: boost FTBFS on hppa
On Tue, Dec 20, 2005 at 05:48:17PM +0800, Randolph Chung wrote: i just finished to re-check the build with this option. unfortunately it still fails. the log is at http://people.debian.org/~cavok/boost_1.33.0-5_hppa.build. I notice you have some files built with -O0 and some with -O3. Any particular reason? no, nothing done by me Do you know if boost has some functions in it that are very very big? (perhaps machine generated?) Doesn't look like it... i have no idea. Can you also try with -mlong-calls (instead of -ffunction-sections) this seems to work :) These are obviously all workarounds until we fix the real problem. ok, thanks. i'm now building -6. thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341174: boost FTBFS on hppa
On Sat, Dec 17, 2005 at 01:59:49AM -0800, Steve Langasek wrote: Hello, Hi, Is anyone looking into this problem with building boost on hppa? As there are quite a few packages which build-depend on boost (including parts of KDE, and aptitude), this is likely to cause hppa to hold up the c2a transition unless some progress is made here. i'm seeing.. i tried some builds on paer.d.o, to see how new compilers/linkers behavaed with respect to this. maybe latest binutils 2.16.1cvs20051214-1 fixes this... i'm not doing more, sorry. ciao domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341174: gcc-3.4: boost 1.33.x FTBFS with cannot handle R_PARISC_PCREL17F...
Package: gcc-3.4 Version: 3.4.4-10 Severity: important hi, starting with version 3.4.4-10, gcc-3.4 makes boost 1.33.x FTBFS. /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/basic_iarchive.o(.gnu.linkonce.t._ZSt24__uninitialized_copy_auxIN9__gnu_cxx17__normal_iteratorIPN5boost7archive6detail19basic_iarchive_impl7aobjectESt6vectorIS6_SaIS6_SB_ET0_T_SD_SC_12__false_type+0xa0): cannot reach 0aae__ZSt10_ConstructIN5boost7archive6detail19basic_iarchive_impl7aobjectES4_EvPT_RKT0_+0, recompile with -ffunction-sections /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/basic_iarchive.o(.gnu.linkonce.t._ZSt24__uninitialized_copy_auxIN9__gnu_cxx17__normal_iteratorIPN5boost7archive6detail19basic_iarchive_impl7aobjectESt6vectorIS6_SaIS6_SB_ET0_T_SD_SC_12__false_type+0xa0): cannot handle R_PARISC_PCREL17F for void std::_Constructboost::archive::detail::basic_iarchive_impl::aobject, boost::archive::detail::basic_iarchive_impl::aobject(boost::archive::detail::basic_iarchive_impl::aobject*, boost::archive::detail::basic_iarchive_impl::aobject const) /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status the full log is available at http://buildd.debian.org/fetch.php?pkg=boostver=1.33.0-5arch=hppastamp=1132750731file=logas=raw. please let me know how to provide more details. unfortunately i'm currently not a toolchain expert. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341174: gcc-4.0: boost 1.33.x FTBFS with cannot handle R_PARISC_PCREL17F...
Package: gcc-4.0 Version: n/a Severity: important hi, gcc-4.0 makes boost 1.33.x FTBFS on hppa. this bug is probably the same of #342245 for gcc-3.4, only that gcc-4.0 _never_ built 1.33.x on that architecture. /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/threading-multi/xml_oarchive.o(.gnu.linkonce.t._ZN5boost7archive6detail18interface_oarchiveINS0_12xml_oarchiveEElsIKNS0_12version_typeEEERS3_RT_[boost::archive::xml_oarchive boost::archive::detail::interface_oarchiveboost::archive::xml_oarchive::operator boost::archive::version_type const(boost::archive::version_type const)]+0x44): cannot reach 1f29__ZN5boost7archive18basic_xml_oarchiveINS0_12xml_oarchiveEE13save_overrideERKNS0_12version_typeEi+0, recompile with -ffunction-sections /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/threading-multi/xml_oarchive.o(.gnu.linkonce.t._ZN5boost7archive6detail18interface_oarchiveINS0_12xml_oarchiveEElsIKNS0_12version_typeEEERS3_RT_[boost::archive::xml_oarchive boost::archive::detail::interface_oarchiveboost::archive::xml_oarchive::operator boost::archive::version_type const(boost::archive::version_type const)]+0x44): cannot handle R_PARISC_PCREL17F for boost::archive::basic_xml_oarchiveboost::archive::xml_oarchive::save_override(boost::archive::version_type const, int) /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status the full log is available at http://buildd.debian.org/fetch.php?pkg=boostver=1.33.0-2arch=hppastamp=1130099046file=logas=raw. i'm again available to delve further into this if only i get some hint of the direction to follow. anyway i'd be probably able to only extract more info, surely not to to fix the compiler itself. thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340784: libcurl3-openssl-dev - don't depend against libkrb5-dev
hi, On Sat, Nov 26, 2005 at 12:17:30AM +0100, Bastian Blank wrote: | $ grep krb usr/lib/libcurl.la | dependency_libs=' -L/usr/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv /usr/lib/libidn.la -ldl -lssl -lcrypto -lz' Bastian ah! i forgot about libtool. of course this is a bug i will fix in the next upload. i'm sorry for Gabor Gombas (#334888) but i can't really let libcurl3-*-dev packages installed without libkrb5-dev. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339154: [pkg-boost-devel] boost and new g++
On Thu, Nov 17, 2005 at 05:26:07PM +0100, Christophe Prud'homme wrote: All, hi, I have recompiled boost 1.33.0-3 using the new C++ compiler it worked like a charm. great :) i think we should upload -4 with packages renamed and no icu on m68k. it would have more chances to enter etch than -3 and in the meanwhile would unblock other depending stuff. Christophe, this is yours. kill it :) or do you prefer to start another branch for 1.33.1 and let me manage -4? Steve, how is there? how we are going? :)) cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319232: [pkg-boost-devel] Bug#334959: boost: FTBFS on hppa
tags 319232 + pending tags 334959 + pending thanks On Sat, Oct 29, 2005 at 11:56:36AM +0200, Aurelien Jarno wrote: Hi, hi, Please find attached a patch to fix the FTBFS on hppa. The only solution I found is to build boost with g++-3.4. Using -ffunction-sections, as suggested by ld in the error message does not work. oh, thank you for the idea. i just applied it to the subversion repository. this is used to fix also the ICE on m68k. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334959: , Bug#334497: boost: FTBFS on hppa
hi Nathanael, On Fri, Oct 21, 2005 at 02:30:22AM -0400, Nathanael Nerode wrote: From http://buildd.debian.org/fetch.php?pkg=boostver=1.33.0-1arch=hppastamp=1129127511file=logas=raw we see the following: usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/threading-multi/xml_oarchive.o(.gnu.linkonce.t._ZN5boost7archive6detail18interface_oarchiveINS0_12xml_oarchiveEElsIKNS0_12version_typeEEERS3_RT_[boost::archive::xml_oarchive boost::archive::detail::interface_oarchiveboost::archive::xml_oarchive::operator boost::archive::version_type const(boost::archive::version_type const)]+0x44): cannot reach 1f29__ZN5boost7archive18basic_xml_oarchiveINS0_12xml_oarchiveEE13save_overrideERKNS0_12version_typeEi+0, recompile with -ffunction-sections /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/threading-multi/xml_oarchive.o(.gnu.linkonce.t._ZN5boost7archive6detail18interface_oarchiveINS0_12xml_oarchiveEElsIKNS0_12version_typeEEERS3_RT_[boost::archive::xml_oarchive boost::archive::detail::interface_oarchiveboost::archive::xml_oarchive::operator boost::archive::version_type const(boost::archive::version_type const)]+0x44): cannot handle R_PARISC_PCREL17F for boost::archive::basic_xml_oarchiveboost::archive::xml_oarchive::save_override(boost::archive::version_type const, int) /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status i'd be very glad to know where the bug is and if i can really solve it. few days ago i opened bug #334497 to get some attention. i hope somebody steps in with the proper knowledge to shed some light on the topic. i also sent a mail on debian-devel [0], but i've not heard anything from anybody. with the info i currently have, i'm not able to predict when this bug will be handled. i should try a different liker version, but i'm still too young in the field of compiler/linker errors. regards domenico [0] http://lists.debian.org/debian-devel/2005/09/msg01222.html -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319232: (no subject)
hi Martin, Martin wrote: Will an upload to fix boost's FTBFS on hppa and m68k be made soon? As kdeedu build-depends on boost, this issue is tied into the gcc-4.0 ABI transition. soon? with the info i have, i cannot promise anything soon about FTBFS on hppa. please follow the evolution of #334959. about m68k, recently somebody posted on debian-devel about the problems with gcc 4.0.2 and -O3, someone else answered saying he would have rescheduled package failing on it to see if 4.0.2 has a fix. i must have deleted the thread by error and i'm not fiding it in the archives. the only workaround is to build with -O2, already tested but not deployed in the debian/rules. probably i'll upload a version compiling with -O2 on m68k and let see what happens. it won't be the next one, -2, which i'm rolling in these minutes. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333609: /usr/bin/ld: cannot find -lgssapi_krb5
On Wed, Oct 12, 2005 at 11:35:24PM +0100, Qingning Huo wrote: Hi, hi, /usr/bin/ld failed to find -lgssapi_krb5, which is mentioned in /usr/lib/libcurl.la. i forgot to add the dependency on libkrb5-dev, i'll fix it in the next upload. in the meanwhile you can install it manually. thank you. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333734: curl security issue
Joey, i uploaded curl 7.13.2-2sarge3 to http://people.debian.org/~cavok/curl/ for your review, i'm waiting the clearance to upload. the CAN-2005-3185 name is taken from iDEFENSE advisory 10.13.05 but still not confirmed by cve.mitre.org. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Bug#318590: editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)
On Sat, Sep 24, 2005 at 11:39:28AM -0400, Daniel Jacobowitz wrote: On Sat, Sep 24, 2005 at 04:52:31PM +0200, Domenico Andreoli wrote: yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname still being libcurl.so.3. everything else is in place for a good upload. as of today, i've not found a solution different from patching the makefiles. i'd like a tool to modify this kind of things in the elf, probably elfsh is what i'm looking for. something to run after the build process. any idea? In general you can't do this unless you're replacing it with a shorter soname. I highly recommend fixing the build system instead. the build system is automake+libtool. fixing it means telling to libtool which soname is to be used. ah.. libtool... i hate clever software.. the only way i know to achieve this is to modify the lib_LTLIBRARIES variable and releated. am i missing anything? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318590: editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)
On Sat, Sep 24, 2005 at 04:15:53PM +0200, Elimar Riesebieter wrote: On Sat, 17 Sep 2005 the mental interface of Domenico Andreoli told: It doesn't seem so: dpkg -l | grep curl ii curl 7.14.1-2 ii libcurl3 7.14.1-2 ii libcurl3-gnutls7.14.1-2 ii libcurl3-gnutls-dev7.14.1-2 Building moc depending on libcurl3-gnutls-dev gives dh_shlibdeps debian/moc/usr/bin/mocp: /usr/lib/libcurl.so.3: version `CURL_GNUTLS_3' not found (required by debian/moc/usr/bin/mocp) Why /usr/lib/libcurl.so.3 and not /usr/lib/libcurl-gnutls.so.3? ldd ./mocp | egrep (ssl|gnutls) ./mocp: /usr/lib/libcurl.so.3: version `CURL_GNUTLS_3' not found (required by ./mocp) libgnutls.so.11 = /usr/lib/libgnutls.so.11 (0x0fc3b000) libssl.so.0.9.7 = /usr/lib/libssl.so.0.9.7 (0x0f7df000) yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname still being libcurl.so.3. everything else is in place for a good upload. as of today, i've not found a solution different from patching the makefiles. i'd like a tool to modify this kind of things in the elf, probably elfsh is what i'm looking for. something to run after the build process. any idea? i'm also sorry for being not responsive at all, my real life should return to me some of the good old free time in a week or two. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318590: versioned symbols patch
hi Daniel,
here is my proposed patch to allow, at configure, time the production
of shared library with versioned symbols. i used it to build curl
7.14.1-1 debian package now in experimental.
i'd be very glad to see it applied to your source tree. feel free to
modify any part of it but please let me know the final tag name in
lib/libcurl.vers.in in order to match it in the next upload to debian
unstable.
cheers
domenico
Index: configure.ac
===
RCS file: /cvsroot/pkg-curl/debian/curl/configure.ac,v
retrieving revision 1.1.1.20
retrieving revision 1.2
diff -d -u -p -r1.1.1.20 -r1.2
--- configure.ac1 Sep 2005 20:29:20 - 1.1.1.20
+++ configure.ac15 Sep 2005 21:51:06 - 1.2
@@ -1105,9 +1105,50 @@ fi dnl only done if some kind of SSL was
AM_CONDITIONAL(CABUNDLE, test x$ca != xno)
+dnl **
+dnl Check for linker switch for versioned symbols
+dnl **
+
+AC_MSG_CHECKING([if libraries can be versioned])
+GLD=`$LD --help /dev/null 2/dev/null | grep version-script`
+if test -z $GLD; then
+versioned_symbols_flavour=
+AC_MSG_RESULT(no)
+AC_MSG_WARN(***
+*** You may want to rerun configure using --with-gnu-ld to enable versioned
symbols.
+)
+else
+AC_MSG_RESULT(yes)
+AC_MSG_CHECKING([whether versioned symbols are wanted])
+versioned_symbols_flavour=
+
+AC_ARG_ENABLE(versioned-symbols,
+AC_HELP_STRING([--enable-versioned-symbols], [Enable versioned symbols in
shared library])
+AC_HELP_STRING([--disable-versioned-symbols], [Disable versioned symbols in
shared library]),
+[ case $enableval in
+ yes) AC_MSG_RESULT(yes)
+ if test $OPENSSL_ENABLED = 1; then
+ versioned_symbols_flavour=OPENSSL_
+ else
+ if test $OPT_GNUTLS != no; then
+ versioned_symbols_flavour=GNUTLS_
+ fi
+ fi
+ ;;
+
+ *) AC_MSG_RESULT(no)
+ ;;
+ esac
+], [
+AC_MSG_RESULT(no)
+]
+)
+fi
+
+AC_SUBST(VERSIONED_FLAVOUR, [$versioned_symbols_flavour])
+AM_CONDITIONAL(VERSIONED_SYMBOLS, test $versioned_symbols_flavour != )
-
dnl **
dnl Check for the presence of ZLIB libraries and headers
dnl **
@@ -1861,6 +1902,7 @@ AC_CONFIG_FILES([Makefile \
include/curl/Makefile \
src/Makefile \
lib/Makefile \
+ lib/libcurl.vers \
tests/Makefile \
tests/data/Makefile \
tests/server/Makefile \
Index: lib/Makefile.am
===
RCS file: /cvsroot/pkg-curl/debian/curl/lib/Makefile.am,v
retrieving revision 1.1.1.18
retrieving revision 1.16
diff -d -u -p -r1.1.1.18 -r1.16
--- lib/Makefile.am 31 Mar 2005 07:02:03 - 1.1.1.18
+++ lib/Makefile.am 15 Sep 2005 21:51:32 - 1.16
@@ -82,7 +82,11 @@ if MIMPURE
MIMPURE = -mimpure-text
endif
-libcurl_la_LDFLAGS = $(UNDEF) $(VERSION) $(MIMPURE)
+if VERSIONED_SYMBOLS
+VERSIONED_SYMBOLS = -Wl,--version-script=libcurl.vers
+endif
+
+libcurl_la_LDFLAGS = $(UNDEF) $(VERSION) $(MIMPURE) $(VERSIONED_SYMBOLS)
# Makefile.inc provides the CSOURCES and HHEADERS defines
include Makefile.inc
Index: lib/libcurl.vers.in
===
RCS file: lib/libcurl.vers.in
diff -N lib/libcurl.vers.in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/libcurl.vers.in 15 Sep 2005 21:47:03 - 1.1
@@ -0,0 +1,5 @@
[EMAIL PROTECTED]@3
+{
+ global: curl_*; curlx_*; Curl_*;
+ local: *;
+};
-[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318590: curl situation is intolerable
On Mon, Sep 12, 2005 at 03:03:02AM -0700, Steve Langasek wrote: On Mon, Sep 12, 2005 at 11:34:22AM +0200, Domenico Andreoli wrote: will libcurl3 with versioned symbols break existing packages linked to it? It will not. good It would be best to coordinate with upstream to get symbol versioning added there as well, so that binaries built against the symbol-versioned Debian lib can also be run on other systems. i already contacted him cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318590: curl situation is intolerable
On Sun, Sep 11, 2005 at 10:54:17AM -0300, Henrique de Moraes Holschuh wrote: On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote: It is *absolutely intolerable* to declare such conflicts for shared libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT HAVE DIFFERENT NAMES. The package has to build libraries with differently versioned symbols as well, to avoid total app meltdown if both libraries are loaded into the same address space. hmm.. i didn't realized this. how does it work? -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318590: Versioned symbols?
On Sun, Sep 11, 2005 at 11:53:19PM +0200, Daniel Stenberg wrote: Hello Why would it need versioned symbols? The whole point of the different .so names would be so that _either one_ of the libs could be used, both would _never_ be used at the same time as it would be pointless. never? libA uses curl+openssl, libB curl+gnutls and progC uses libA and libB. i'm right thinking at versioned symbols, libcurl3 and libcurl3-gnutls as the solution to my packaging problems. i'll send you a patch, i think you are also interested in versioned symbols too. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325247: libwvstreams4.0-qt: uninstallable because of missing libqt3c102-mt
hi, i prepared a NMU to fix this missing library package, it is available at http://people.debian.org/~cavok/wvstreams/. please let me know if the upload is also wanted. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Bug#325247: libwvstreams4.0-qt: uninstallable because of missing libqt3c102-mt
On Fri, Sep 09, 2005 at 11:15:27AM -0400, Simon Law wrote: On Fri, Sep 09, 2005 at 11:48:56AM +0200, Domenico Andreoli wrote: i prepared a NMU to fix this missing library package, it is available at http://people.debian.org/~cavok/wvstreams/. An NMU is friendly, provided that you've been careful. Is this just a simple recompile? yes and no. debdiff shows differences on config.guess and config.sub and the following of debian/changelog: diff -u wvstreams-4.0.2/debian/changelog wvstreams-4.0.2/debian/changelog --- wvstreams-4.0.2/debian/changelog +++ wvstreams-4.0.2/debian/changelog @@ -1,3 +1,9 @@ +wvstreams (4.0.2-4.1) unstable; urgency=low + + * Rebuilt with recent qt-x11-free. (Closes: #325247) + + -- Domenico Andreoli [EMAIL PROTECTED] Fri, 9 Sep 2005 11:24:16 +0200 + wvstreams (4.0.2-4) unstable; urgency=low i still have to write a notice about NMU in changelog. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325247: libwvstreams4.0-qt: uninstallable because of missing libqt3c102-mt
On Fri, Sep 09, 2005 at 11:39:30AM -0400, Simon Law wrote: On Fri, Sep 09, 2005 at 05:29:49PM +0200, Domenico Andreoli wrote: On Fri, Sep 09, 2005 at 11:15:27AM -0400, Simon Law wrote: On Fri, Sep 09, 2005 at 11:48:56AM +0200, Domenico Andreoli wrote: i prepared a NMU to fix this missing library package, it is available at http://people.debian.org/~cavok/wvstreams/. An NMU is friendly, provided that you've been careful. Is this just a simple recompile? yes and no. debdiff shows differences on config.guess and config.sub and the following of debian/changelog: That's fine, thanks! do i upload it? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325643: Bug#318590: Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote: On Fri, Sep 02, 2005 at 12:24:18PM +0200, Domenico Andreoli wrote: - libcurl3 (GnuTLS, soname: libcurl.so.3) So the libcurl3 in sarge and etch will have ABI incompatibilities? at the release time of etch this problem will regard only external software. this kind of installations will be able to use libcurl3-openssl-dev package or switch to GnuTLS. is this reasonable enough? No, definitely not. You cannot change the ABI of an existing library package, especially not one that's been in a stable release; you need to rename it instead. so we need both libcurl3-openssl and libcurl3-gnutls until libcurl4? i am not seeing this as a problem. dom -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325643: libcurl and moc
On Thu, Sep 01, 2005 at 09:40:17PM +0200, Elimar Riesebieter wrote: On Tue, 30 Aug 2005 the mental interface of Daniel Stenberg told: The problem you have with libcurl and OpenSSL/GnuTLS is not strictly an upstream problem. In the curl project there are some ideas floating around that are being discussed on how this could be fixed for Debian (and other distros) but that is only because they don't do it themselves, it is not because it is an actual problem in the curl camp. It is more of an indirect annoyance. Also, discussions are only talk. There is no fix or solution in the work for the nearest period of time. Everyone's invited to come help sort it out. In my view, there's only one available work-around for the short to mid term, and that is to use a separate .so file for libcurl built with GnuTLS. My resume on Daniels point of view is to get a different .so name for gnutls in the very short term and kick off ssl in Debian apps midterm! Note, this will _not be done upstream_! This is not as hard as Marco's demand, but we have to do it in that way. There are some curl based packages like oggvorbistools, moc etc which are at the moment uninstallable and herewith I invite Domenico to provide a package where gnutls and ssl can exist beside in one installation. For me, as a not much experienced voluntary I'll spend some spare time to understand the technique on how to do that and hopefully can assist Domenico to create a package. ok, we are hooked into the libflac6 transition, let's start the curl one. my wish is to upload curl 7.14.1 with the following package layout: - curl (OpenSSL, linked to libcurl-openssl.so.3) - libcurl3 (GnuTLS, soname: libcurl.so.3) - libcurl3-openssl (OpenSSL, soname: libcurl-openssl.so.3) - libcurl3-gssapi (OpenSSL, MIT Kerberos 5) - libcurl3-dev (OpenSSL, depends: libssl-dev) - libcurl3-openssl-dev (GnuTLS, depends: libgnutls-dev) - libcurl3-dbg this way libcurl3 and libcurl3-openssl can be contemporarily installed. curl command line depends on package libcurl3-openssl. BTW, is libcurl3-openssl legal or it should be libcurl-openssl3? any more comments? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 02:58:05AM -0700, Steve Langasek wrote: On Fri, Sep 02, 2005 at 11:16:28AM +0200, Domenico Andreoli wrote: ok, we are hooked into the libflac6 transition, let's start the curl one. my wish is to upload curl 7.14.1 with the following package layout: - curl (OpenSSL, linked to libcurl-openssl.so.3) - libcurl3 (GnuTLS, soname: libcurl.so.3) - libcurl3-openssl (OpenSSL, soname: libcurl-openssl.so.3) - libcurl3-gssapi (OpenSSL, MIT Kerberos 5) - libcurl3-dev (OpenSSL, depends: libssl-dev) - libcurl3-openssl-dev (GnuTLS, depends: libgnutls-dev) - libcurl3-dbg this way libcurl3 and libcurl3-openssl can be contemporarily installed. curl command line depends on package libcurl3-openssl. BTW, is libcurl3-openssl legal or it should be libcurl-openssl3? any more comments? Why does libcurl3-gssapi need a separate package from libcurl3-openssl? probably none. in case it is acceptable to enable GSSAPI everywhere, i could also enable it in the libcurl3 (with GnuTLS) and remove libcurl3-gssapi completely. Your -dev package names seem to be crossed, relative to the corresponding lib packages. I think you really wanted to say - libcurl3-dev (GnuTLS, depends: libgnutls-dev) - libcurl3-openssl-dev (OpenSSL, depends: libssl-dev) ? yes, of course :) And yes, lintian will complain to you if you name your library package libcurl3-openssl instead of libcurl-openssl3. :) lintian would be shut up with an ovverride... no remorse. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325643: Bug#318590: Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 11:56:13AM +0200, Adeodato Simó wrote: * Domenico Andreoli [Fri, 02 Sep 2005 11:16:28 +0200]: - libcurl3-dev (OpenSSL, depends: libssl-dev) - libcurl3-openssl-dev (GnuTLS, depends: libgnutls-dev) Obvious typo/whatever here, right? On Fri, Sep 02, 2005 at 02:58:05AM -0700, Steve Langasek wrote: Your -dev package names seem to be crossed, relative to the corresponding lib packages. I think you really wanted to say - libcurl3-dev (GnuTLS, depends: libgnutls-dev) - libcurl3-openssl-dev (OpenSSL, depends: libssl-dev) ? yes - libcurl3 (GnuTLS, soname: libcurl.so.3) So the libcurl3 in sarge and etch will have ABI incompatibilities? at the release time of etch this problem will regard only external software. this kind of installations will be able to use libcurl3-openssl-dev package or switch to GnuTLS. is this reasonable enough? thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Bug#325543: vorbis-tools: uninstallable because of missing libflac6 and liboggflac1
Package: vorbis-tools Version: 1.0.1-1.4 Severity: serious Tags: sid hi, this package is not installable because it depends on libflac6 and liboggflac1. both these packages are not in sid any more. please rebuild. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325544: easytag: uninstallable because of missing libflac6
Package: easytag Version: 1.99.7-2 Severity: serious Tags: sid hi, this package is not installable because it depends on libflac6. libflac6 is not in sid any more. please rebuild. this bug does not apply on hppa port where easytag depends on libflac7. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325247: libwvstreams4.0-qt: uninstallable because of missing libqt3c102-mt
Package: libwvstreams4.0-qt Version: 4.0.2-4 Severity: serious Tags: sid hi, this package is not installable because it depends on libqt3c102-mt. libqt3c102-mt is not in sid any more. please rebuild. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325249: oprofile: uninstallable because of missing libqt3c102-mt
Package: oprofile Version: 0.8.1-2 Severity: serious Tags: sid hi, this package is not installable because it depends on libqt3c102-mt. libqt3c102-mt is not in sid any more. please rebuild. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320046: FTBFS due to dpkg-architecture changes
On Tue, Jul 26, 2005 at 07:07:05PM +0200, Matthias Klose wrote:
Package: curl
Version: 7.14
Severity: serious
ifneq (${DEB_BUILD_GNU_SYSTEM},m68k-linux)
... and maybe others. Don't rely on the GNU variables
please elaborate. why they are wrong? any reference to any doc/thread
i missed?
cheers
domenico
-[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320046: FTBFS due to dpkg-architecture changes
On Wed, Jul 27, 2005 at 11:51:40AM +0200, Matthias Klose wrote: please see Scott's mail on d-d-a. for my reference: http://lists.debian.org/debian-devel-announce/2005/06/msg00010.html -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318139: CXX 4.0 transition
On Fri, Jul 15, 2005 at 10:10:21PM -0700, Steve Langasek wrote: On Sat, Jul 16, 2005 at 12:51:06AM +0200, Domenico Andreoli wrote: On Thu, Jul 14, 2005 at 12:30:57PM +0200, Robert Jordens wrote: [Thu, 14 Jul 2005] Domenico Andreoli wrote: BTW, i don't think it is a good idea to distribute boost binaries built with a compiler that has never seen the boost regression test suite. I got uneasy as well but ooking on the boost webpage, there was no newer release yet. here is a pointer to the 1.33.0 release status: http://lists.boost.org/boost/2005/07/30375.php Sure. What do you think about running the testsuite on each build? it is a good idea. the test suite results are produced as html pages. most of the debian users would not be interested in them. what about providing a separate binary package i.e. libboost-regression? Ultimately, what would be most useful from a QA standpoint is a test suite that can output either a success or failure code during the package build, and information about which tests failed if any. I'm pretty sure that *no* users are interested in having the test suite results packaged. :) i don't master the test suite, i'm currently unable to confirm this can be achieved out-of-the-box. ciao -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318995: boost: rebuild needed for C++ ABI transition (NMU patch attached)
On Mon, Jul 18, 2005 at 10:44:46PM -0700, Steve Langasek wrote: Hi Domenico, hi Steve, Under the 0-day NMU policy for the C++ ABI transition, I have prepared an NMU for boost, because its C++ library packages need to be rebuilt so that a number of other C++-based packages can transition to g++ 4.0. The diff for this NMU is attached; the NMU will be uploaded shortly. If you see any problems with the patch, let me know so I can have the package rejected out of NEW. i thought my statements in #318139 were clear, i'm working on boost 1.33.0 prelease packages which solve also the transition to g++ 4.0. i'm then surprised to see your NMU, as if you forgot everything... IMHO such NMU is not necessary, the fixed version of boost 1.32.0 is going to live few days anyway. haven't you anything more important to do? :)) cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318139: CXX 4.0 transition
On Thu, Jul 14, 2005 at 12:30:57PM +0200, Robert Jordens wrote: [Thu, 14 Jul 2005] Domenico Andreoli wrote: BTW, i don't think it is a good idea to distribute boost binaries built with a compiler that has never seen the boost regression test suite. I got uneasy as well but ooking on the boost webpage, there was no newer release yet. here is a pointer to the 1.33.0 release status: http://lists.boost.org/boost/2005/07/30375.php Sure. What do you think about running the testsuite on each build? it is a good idea. the test suite results are produced as html pages. most of the debian users would not be interested in them. what about providing a separate binary package i.e. libboost-regression? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318139: CXX 4.0 transition
On Wed, Jul 13, 2005 at 08:13:55PM +0200, Robert Jordens wrote: I plan on NMUing boost for the CXX transition today. See: http://lists.debian.org/debian-devel-announce/2005/07/msg1.html The idea is from here: https://bugzilla.ubuntu.com/show_bug.cgi?id=10768 I will attach a patch as soon as I have this bugnumber. hi, please stop. i'm working to the upcoming 1.33.0 release. this will handle the transition to gcc 4.0 in the simplest, safest and cleanest way. i'm already testing it with gcc 4.0. i'm planning a release in few days. BTW, i don't think it is a good idea to distribute boost binaries built with a compiler that has never seen the boost regression test suite. i'm aware of the transition plan. thank you :) cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Bug#304470: glade-gnome-2: needs to be rebuilt using newer libraries
Package: glade-gnome-2 Version: 2.6.8-2 Severity: grave This package is not installable. It depends on libgda2-1 and libgnomedb2-3 which have been superseded by libgda2-3 and libgnomedb2-4. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296678: libcurl3: NTLM Authentication buffer overflow (CAN-2005-0490)
tags 296678 + pending thanks On Wed, Feb 23, 2005 at 11:22:11PM +0100, Moritz Muehlenhoff wrote: iDefense discovered a buffer overflow in NTLM authentication that may lead to arbitrary code execution. This is CAN-2005-0490. Woody is not affected, as it doesn't contain the vulnerable NTLM code. (It's not listed on the Not-Vulnerable list yet, though) Upstream's patch to address this issue is attached, I didn't resync it against the Debian package, because all this internal to-7.11 patching seems, umm, scary. yes, i know and agree about the scary patch. i'm going to remove support for libcurl2, it was used only by discover. discover now doesn't need libcurl2 any more. There's another buffer overflow in Kerberos handling, but I doesn't seems to be enabled in debian/rules, but please double check this. wildo cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294407: Accepted curl 7.13.0-1 (i386 source)
doh! - Forwarded message from Otavio Salvador [EMAIL PROTECTED] - Date: Wed, 09 Feb 2005 14:42:00 -0200 From: Otavio Salvador [EMAIL PROTECTED] To: Domenico Andreoli [EMAIL PROTECTED] Subject: Re: Accepted curl 7.13.0-1 (i386 source) || On Wed, 9 Feb 2005 17:24:32 +0100 || Domenico Andreoli [EMAIL PROTECTED] wrote: da On Wed, Feb 09, 2005 at 02:10:10PM -0200, Otavio Salvador wrote: Take a try and you will see. da $ dpkg -L libldap2 | grep .so$ da $ dpkg -L libldap2-dev | grep .so$ da /usr/lib/liblber.so da /usr/lib/libldap.so da /usr/lib/libldap_r.so da $ da please refer to http://curl.haxx.se/mail/lib-2005-01/0261.html in order da the get the background of this story. thanks. You did right but libldap2 package have a serious bug then. I already reported it against libldap2-dev and when it's got fixed you need to change curl packages to use libldap2 package. You can check the bug http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libldap2-dev in some minutes. Thanks a lot. - End forwarded message - -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
