Bug#948589: nmu: file_1:5.38-3

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#948589: nmu: file_1:5.38-3

Helmut Grohne
Package: release.debian.org
User: [hidden email]
Usertags: binnmu
Control: affects -1 + libmagic1

nmu file_1:5.38-3 . ANY . unstable . -m "rebuild with a #948269 fixed file"

The file package was built with a broken version file wrt #948269. As
such libmagic1 lacks shared library dependencies. A simple rebuild fixes
the problem.

Helmut

Reply | Threaded
Open this post in threaded view
|

Bug#948589: nmu: file_1:5.38-3

Christoph Biedl-7
Helmut Grohne wrote...

> The file package was built with a broken version file wrt #948269. As
> such libmagic1 lacks shared library dependencies. A simple rebuild fixes
> the problem.

This leaves me somewhat confused since I understand your rationale
the file package needs itself to be built, in other words, a circular
build dependency. This should not happen, and I'd like to eliminate
that.

Mind to shed some light on this? How was libmagic wrongly built, how did
this manifest?

(You might have noted the file build overrides dh_shlibdeps -
appearently this is not enough?)

    Christoph

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#948589: nmu: file_1:5.38-3

Helmut Grohne
Hi,

On Fri, Jan 10, 2020 at 04:58:22PM +0100, Christoph Biedl wrote:
> This leaves me somewhat confused since I understand your rationale
> the file package needs itself to be built, in other words, a circular
> build dependency. This should not happen, and I'd like to eliminate
> that.
>
> Mind to shed some light on this? How was libmagic wrongly built, how did
> this manifest?

Well, the circle is implicit. file is used by debhelper/dpkg to generate
shared library dependencies. libmagic1 misses its library dependencies
on a number of architectures.

Aurelien suggested that someone greps .buildinfo files on coccia for
packages built with 1:5.38-2:

./01/06/girara_0.3.4-1_all.buildinfo
./01/06/girara_0.3.4-1_amd64.buildinfo
./01/06/girara_0.3.4-1_arm64.buildinfo
./01/06/girara_0.3.4-1_armel.buildinfo
./01/06/file_5.38-3_amd64.buildinfo
./01/06/file_5.38-3_arm64.buildinfo
./01/06/girara_0.3.4-1_armhf.buildinfo
./01/06/girara_0.3.4-1_i386.buildinfo
./01/06/file_5.38-3_armel.buildinfo
./01/06/girara_0.3.4-1_ppc64el.buildinfo
./01/06/girara_0.3.4-1_s390x.buildinfo
./01/06/file_5.38-3_armhf.buildinfo
./01/06/file_5.38-3_i386.buildinfo
./01/06/file_5.38-3_mips64el.buildinfo
./01/06/file_5.38-3_ppc64el.buildinfo
./01/06/file_5.38-3_s390x.buildinfo
./01/06/python3.8_3.8.1-2_amd64.buildinfo

Looks like we want to binNMU girara and python3.8 as well.

Helmut

Reply | Threaded
Open this post in threaded view
|

Bug#948589: nmu: file_1:5.38-3

Andreas Beckmann-4
In reply to this post by Christoph Biedl-7
On Fri, 10 Jan 2020 16:58:22 +0100 Christoph Biedl <[hidden email]> wrote:

> Helmut Grohne wrote...
>
> > The file package was built with a broken version file wrt #948269. As
> > such libmagic1 lacks shared library dependencies. A simple rebuild fixes
> > the problem.
>
> This leaves me somewhat confused since I understand your rationale
> the file package needs itself to be built, in other words, a circular
> build dependency. This should not happen, and I'd like to eliminate
> that.
>
> Mind to shed some light on this? How was libmagic wrongly built, how did
> this manifest?
binary debdiff of bad and good libmagic1 builds:

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: {+libbz2-1.0, libc6 (>= 2.15), liblzma5 (>= 5.1.1alpha+20120614), zlib1g (>= 1:1.1.4),+} libmagic-mgc (= [-1:5.38-3.bad)-] {+1:5.38-3.good)+}
Version: [-1:5.38-3.bad-] {+1:5.38-3.good+}

The bad one was done with 1:5.38-2, the good one with 1:5.38-3 installed.

> (You might have noted the file build overrides dh_shlibdeps -
> appearently this is not enough?)

dh_shlibdeps (any maybe other dh_*) call 'file' - the (buggy?) version
installed in the system, not the freshly built one.

Attached patch is a hack to prepend a 'file' wrapper script in the path
that uses the freshly built one (I hope I did the call right?), this allows
for a correct libmagic1 package to be built even in the presence of the buggy
1:5.38-2 in the system by using the new file command during the later stages
of the build process.
It's probably not cross-build safe, though.

Andreas

file_5.38-3.1.dsc.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#948589: nmu: file_1:5.38-3

Christoph Biedl-7
clone 948589 -1
reassign -1 file
retitle -1 file: When building the file package, use the just-built file program in debhelper
thanks

Andreas Beckmann wrote...

> File lists identical (after any substitutions)
>
> Control files: lines which differ (wdiff format)
> ------------------------------------------------
> Depends: {+libbz2-1.0, libc6 (>= 2.15), liblzma5 (>= 5.1.1alpha+20120614), zlib1g (>= 1:1.1.4),+} libmagic-mgc (= [-1:5.38-3.bad)-] {+1:5.38-3.good)+}
> Version: [-1:5.38-3.bad-] {+1:5.38-3.good+}
>
> The bad one was done with 1:5.38-2, the good one with 1:5.38-3 installed.

Thanks a lot, that bit of information helped me to understand the
situation. So src:file has indeed a circular build dependency, and
while this probably does not really do harm - at least no one bothered
to report issues with that in the past (at least) twelve years -, it is
not sound.

> Attached patch is a hack to prepend a 'file' wrapper script in the path
> that uses the freshly built one (I hope I did the call right?), this allows
> for a correct libmagic1 package to be built even in the presence of the buggy
> 1:5.38-2 in the system by using the new file command during the later stages
> of the build process.

That's a good point to start at anyway. I will have to add some more
bits, like overriding dh_strip (which calls the file binary as well).

> It's probably not cross-build safe, though.

Looks like it. Possibly I can find a solution for that as well.

    Christoph, now having an even longer "lessons learned" list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#948619: Bug #948619: file: When building the file package, use the just-built file program in debhelper

Andreas Beckmann-4
On 10/01/2020 22.36, Christoph Biedl wrote:
> bits, like overriding dh_strip (which calls the file binary as well).

The PATH prepend-and-export should cover everything calling the 'file'
binary after override_dh_auto_install target, no need for explicit
override_dh_* targets. It would be more difficult if something is using
libmagic.so.1 via perl/python/linking-against-the-shared-library instead
of calling the 'file' binary from the PATH.


Andreas