Bug#688779: liburcu1: shlibs too weak
* Faidon Liambotis parav...@debian.org wrote: On Tue, Sep 25, 2012 at 12:04:59PM -0400, Aaron M. Ucko wrote: Package: liburcu1 Version: 0.7.4-1 Severity: serious Justification: Policy 8.6 This is a bug report against liburcu/0.7.4-1 but you seem to have closed it in an ltt-control upload. If it wasn't a liburcu bug in the first place, you should have reassigned the bug before closing it; if it is a liburcu bug OTOH, you shouldn't Close it from a different package. From what I can see, the bug is still considered by britney for migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 found ltt-control/$brokenversion as to fix this inconsistency. I don't completely follow, can you give some clarification? Also, can you include a link to where I can see the britney information you're referencing? -- Jon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
On Fri, May 10, 2013 at 10:23:04AM -0400, Jon Bernard wrote: This is a bug report against liburcu/0.7.4-1 but you seem to have closed it in an ltt-control upload. If it wasn't a liburcu bug in the first place, you should have reassigned the bug before closing it; if it is a liburcu bug OTOH, you shouldn't Close it from a different package. From what I can see, the bug is still considered by britney for migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 found ltt-control/$brokenversion as to fix this inconsistency. I don't completely follow, can you give some clarification? Also, can you include a link to where I can see the britney information you're referencing? This bug report was originally found on liburcu/0.7.4-1. The ltt-control upload send a mail to 688779-close@ and this marked the bug as fixed in ltt-control/2.1.0~rc4-2. But it wasn't found on that package in the first place, so this was essentially no-op. You can see this on the top of this bug report: Found in version liburcu/0.7.4-1 Fixed in version ltt-control/2.1.0~rc4-2 Since the bug was found in a version of liburcu and wasn't fixed (or unfound) in subsequent liburcu version, the BTS considers the bug as still present in the most recent version of liburcu. You can clearly see this on the dot graph in the top right side of the bug page. You can also see how this will prevent the migration of liburcu to testing (britney's excuses): http://qa.debian.org/excuses.php?package=liburcu The solution is to either mark the bug as fixed in a newer version of liburcu (by mailing -done@ with e.g. Version: 0.7.6-1) or to inform control@: notfound liburcu/0.7.4-1 found ltt-control/2.1.0~rc4-1 thanks Cheers, Faidon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
On Tue, Sep 25, 2012 at 12:04:59PM -0400, Aaron M. Ucko wrote: Package: liburcu1 Version: 0.7.4-1 Severity: serious Justification: Policy 8.6 This is a bug report against liburcu/0.7.4-1 but you seem to have closed it in an ltt-control upload. If it wasn't a liburcu bug in the first place, you should have reassigned the bug before closing it; if it is a liburcu bug OTOH, you shouldn't Close it from a different package. From what I can see, the bug is still considered by britney for migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 found ltt-control/$brokenversion as to fix this inconsistency. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
* Jon Bernard jbern...@debian.org wrote: * Aaron M. Ucko u...@debian.org wrote: Jon Bernard jbern...@debian.org writes: Is there an easier way of doing this without searching through the source to find all liburcu calls and then pinning them to a specific version in the symbols file? - or is that how it's done? You can run dpkg-gensymbols on a build tree of 0.6.6, copy the resulting symbols file over to a build tree of 0.7.4, and repeat. That said, that approach may well be overkill here. or simply insisting on a versioned dependency in its .shlibs file (e.g., by running dh_makeshlibs -V). This will yield a file containing: liblttng-ctl 0 liblttng-ctl0 (= 2.1.0~rc4) But that will not help me with the liburcu dependency, which should likely be 0.7.4. It's not clear to me how to get dh_makeshlibs to do the right thing. I meant that *liburcu*'s rules should run dh_makeshlibs -V; sorry if that was unclear. (That said, it would probably be wise for ltt-control to do the same for the sake of its libraries' own reverse dependencies.) My first thought was that Build-Depends: .. liburcu-dev (= 0.6.6) is too lenient, and that version should be bumped. I could then release ltt-control version 2.1.0-2 with this change, and avoid the binNMUs, no? What am I missing? That would only work if liburcu1 shipped a symbols file with a magic Build-Depends-Package line. Also, which of these in your opinion is the best/most-proper solution? I might just go for having liburcu1 run dh_makeshlibs -V for simplicity; although that approach can result in overly tight dependencies, that shouldn't be a big deal here. Ok, this makes sense. So just to be clear, here are the steps I plan to follow: 1. In liburcu source, add -V to dh_makeshlibs to set strict symbol version dependencies on this particular version 2. Rebuild ltt-control against the new liburcu, which will pull in liburcu's shlibs and cause ltt-control to depend on that specific version of liburcu. 3. Request binNMU for ltt-control. Is step 3 necessary, will the updated ltt-control not sort this out? That's the only piece I don't quite follow. Because step 2 requires no source changes, just a rebuild. Thus, binNMU. I believe I understand now. Thanks Aaron! -- Jon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
* Aaron M. Ucko a...@alum.mit.edu wrote:
3 would have been in lieu of 2, which is in retrospect a better choice in this
case, and will give you the opportunity to tighten liblttng-ctl0's own shlibs
while you're at it. Please take care to have ltt-control build-depend on
a version of liburcu-dev with this fix. (I presume liburcu-dev already
Depends: liburcu1 (= ${binary:Version}.)
Ahh, good advice. Thanks.
--
Jon
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
3 would have been in lieu of 2, which is in retrospect a better choice in this
case, and will give you the opportunity to tighten liblttng-ctl0's own shlibs
while you're at it. Please take care to have ltt-control build-depend on a
version of liburcu-dev with this fix. (I presume liburcu-dev already Depends:
liburcu1 (= ${binary:Version}.)
Thanks!
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#688779: liburcu1: shlibs too weak
* Aaron M. Ucko u...@debian.org wrote: Jon Bernard jbern...@debian.org writes: Is there an easier way of doing this without searching through the source to find all liburcu calls and then pinning them to a specific version in the symbols file? - or is that how it's done? You can run dpkg-gensymbols on a build tree of 0.6.6, copy the resulting symbols file over to a build tree of 0.7.4, and repeat. That said, that approach may well be overkill here. or simply insisting on a versioned dependency in its .shlibs file (e.g., by running dh_makeshlibs -V). This will yield a file containing: liblttng-ctl 0 liblttng-ctl0 (= 2.1.0~rc4) But that will not help me with the liburcu dependency, which should likely be 0.7.4. It's not clear to me how to get dh_makeshlibs to do the right thing. I meant that *liburcu*'s rules should run dh_makeshlibs -V; sorry if that was unclear. (That said, it would probably be wise for ltt-control to do the same for the sake of its libraries' own reverse dependencies.) My first thought was that Build-Depends: .. liburcu-dev (= 0.6.6) is too lenient, and that version should be bumped. I could then release ltt-control version 2.1.0-2 with this change, and avoid the binNMUs, no? What am I missing? That would only work if liburcu1 shipped a symbols file with a magic Build-Depends-Package line. Also, which of these in your opinion is the best/most-proper solution? I might just go for having liburcu1 run dh_makeshlibs -V for simplicity; although that approach can result in overly tight dependencies, that shouldn't be a big deal here. Ok, this makes sense. So just to be clear, here are the steps I plan to follow: 1. In liburcu source, add -V to dh_makeshlibs to set strict symbol version dependencies on this particular version 2. Rebuild ltt-control against the new liburcu, which will pull in liburcu's shlibs and cause ltt-control to depend on that specific version of liburcu. 3. Request binNMU for ltt-control. Is step 3 necessary, will the updated ltt-control not sort this out? That's the only piece I don't quite follow. Thanks again! -- Jon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
* Aaron M. Ucko u...@debian.org wrote: Package: liburcu1 Version: 0.7.4-1 Severity: serious Justification: Policy 8.6 lttng-tools's postinst fails on my system, which still has liburcu1 0.6.7-2 (from testing), demonstrating that liblttng-ctl0 needs a versioned dependency on liburcu1. I would say liburcu1 is primarily at fault here (though lttng will need a round of binNMUs once you've fixed it). Thanks for catching this, I understand the problem conceptually, but I have couple of questions about how to properly handle it. Could you please ensure that dpkg-shlibdeps will yield sufficiently strict dependencies on liburcu1 by either adding a .symbols file that will direct it to do so selectively. Is there an easier way of doing this without searching through the source to find all liburcu calls and then pinning them to a specific version in the symbols file? - or is that how it's done? or simply insisting on a versioned dependency in its .shlibs file (e.g., by running dh_makeshlibs -V). This will yield a file containing: liblttng-ctl 0 liblttng-ctl0 (= 2.1.0~rc4) But that will not help me with the liburcu dependency, which should likely be 0.7.4. It's not clear to me how to get dh_makeshlibs to do the right thing. My first thought was that Build-Depends: .. liburcu-dev (= 0.6.6) is too lenient, and that version should be bumped. I could then release ltt-control version 2.1.0-2 with this change, and avoid the binNMUs, no? What am I missing? Also, which of these in your opinion is the best/most-proper solution? Thanks in advance, -- Jon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
Jon Bernard jbern...@debian.org writes: Is there an easier way of doing this without searching through the source to find all liburcu calls and then pinning them to a specific version in the symbols file? - or is that how it's done? You can run dpkg-gensymbols on a build tree of 0.6.6, copy the resulting symbols file over to a build tree of 0.7.4, and repeat. That said, that approach may well be overkill here. or simply insisting on a versioned dependency in its .shlibs file (e.g., by running dh_makeshlibs -V). This will yield a file containing: liblttng-ctl 0 liblttng-ctl0 (= 2.1.0~rc4) But that will not help me with the liburcu dependency, which should likely be 0.7.4. It's not clear to me how to get dh_makeshlibs to do the right thing. I meant that *liburcu*'s rules should run dh_makeshlibs -V; sorry if that was unclear. (That said, it would probably be wise for ltt-control to do the same for the sake of its libraries' own reverse dependencies.) My first thought was that Build-Depends: .. liburcu-dev (= 0.6.6) is too lenient, and that version should be bumped. I could then release ltt-control version 2.1.0-2 with this change, and avoid the binNMUs, no? What am I missing? That would only work if liburcu1 shipped a symbols file with a magic Build-Depends-Package line. Also, which of these in your opinion is the best/most-proper solution? I might just go for having liburcu1 run dh_makeshlibs -V for simplicity; although that approach can result in overly tight dependencies, that shouldn't be a big deal here. Thanks in advance, No problem. Please let me know if you have further questions. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
Package: liburcu1 Version: 0.7.4-1 Severity: serious Justification: Policy 8.6 lttng-tools's postinst fails on my system, which still has liburcu1 0.6.7-2 (from testing), demonstrating that liblttng-ctl0 needs a versioned dependency on liburcu1. I would say liburcu1 is primarily at fault here (though lttng will need a round of binNMUs once you've fixed it). Could you please ensure that dpkg-shlibdeps will yield sufficiently strict dependencies on liburcu1 by either adding a .symbols file that will direct it to do so selectively or simply insisting on a versioned dependency in its .shlibs file (e.g., by running dh_makeshlibs -V). Thanks! Setting up lttng-tools (2.1.0~rc3-1) ... /usr/sbin/addgroup /usr/bin/lttng-sessiond: symbol lookup error: /usr/lib/x86_64-linux-gnu/liblttng-ctl.so.0: undefined symbol: rcu_flavor_mb invoke-rc.d: initscript lttng-sessiond, action start failed. dpkg: error processing lttng-tools (--configure): subprocess installed post-installation script returned error exit status 1 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liburcu1 depends on: ii libc6 2.13-35 liburcu1 recommends no packages. liburcu1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
