Re: multi-arch:same failures when bin-nmus changelog dates are not the same

2018-03-30 Thread Jean-Michel Vourgère 
On Thursday, 29 March 2018 18:43:25 CEST Julien Cristau wrote:
> On 03/29/2018 06:35 PM, Jean-Michel Vourgère wrote:
> > (...)
> > On arm64 [1] the binnmu .buildinfo contains:
> > Environment:
> >  (...)
> >  SOURCE_DATE_EPOCH="1522153653"
> > 
> > while on armhf [2] the binnmu .buildinfo contains:
> > Environment:
> >  (...)
> >  SOURCE_DATE_EPOCH="154789"
> > 
> > /s/b/dpkg-buildpackage (...)
> It parses debian/changelog, which is where sbuild writes the binNMU info
> in the unpacked source.  (...)

I suppose then the best thing to do would be to have dpkg-buildpackage ignore 
the d/changelog entries that are tagged "binary-only=yes" when setting 
SOURCE_DATE_EPOCH, right?

Other options I can think of:

- Have "dch --bin-nmu" keep the last date. Or whatever tool WB uses when 
creating the new changelog entry.

- Have wanna-build set SOURCE_DATE_EPOCH to the last non-binnmu changelog 
entry. This would break package that overwrite SOURCE_DATE_EPOCH themselves. 
So this is a bad idea.

- Prohibit bin-nmu of packages tagged Multi-Arch:same and only do full source 
upload for these. Eeerk :(


Any tough anyone?

I'll fill a bug against dpkg-dev if nobody moves. Please don't wait for me as 
I am sure there are many people more qualified that me in this list.


By the way, shouldn't the "binary-only=yes" property in the changelog should 
be documented in the policy 4.4, especially if unrelated processes start using 
it?


signature.asc
Description: This is a digitally signed message part.

Re: multi-arch:same failures when bin-nmus changelog dates are not the same

2018-03-29 Thread Julien Cristau 
On 03/29/2018 06:35 PM, Jean-Michel Vourgère wrote:
> Some thoughs:
> 
> On arm64 [1] the binnmu .buildinfo contains:
> Environment:
>  DEB_BUILD_OPTIONS="parallel=3"
>  LC_ALL="POSIX"
>  SOURCE_DATE_EPOCH="1522153653"
> 
> while on armhf [2] the binnmu .buildinfo contains:
> Environment:
>  DEB_BUILD_OPTIONS="parallel=4"
>  LC_ALL="POSIX"
>  SOURCE_DATE_EPOCH="154789"
> 
> /s/b/dpkg-buildpackage does not overwrite SOURCE_DATE_EPOCH if it is already 
> defined in the environment.
> Also, it looks like it does not parse the changelog.Debian.$arch that are bin-
> nmu specifics.
> 
It parses debian/changelog, which is where sbuild writes the binNMU info
in the unpacked source.  There's no changelog.Debian.$arch at that point
anywhere.

> Could it be that the wanna-build stack wrongly define the variable before 
> calling dpkg-buildpackage?
> 
Nope.

Cheers,
Julien

Re: multi-arch:same failures when bin-nmus changelog dates are not the same

2018-03-29 Thread Jean-Michel Vourgère 
Some thoughs:

On arm64 [1] the binnmu .buildinfo contains:
Environment:
 DEB_BUILD_OPTIONS="parallel=3"
 LC_ALL="POSIX"
 SOURCE_DATE_EPOCH="1522153653"

while on armhf [2] the binnmu .buildinfo contains:
Environment:
 DEB_BUILD_OPTIONS="parallel=4"
 LC_ALL="POSIX"
 SOURCE_DATE_EPOCH="154789"

/s/b/dpkg-buildpackage does not overwrite SOURCE_DATE_EPOCH if it is already 
defined in the environment.
Also, it looks like it does not parse the changelog.Debian.$arch that are bin-
nmu specifics.

Could it be that the wanna-build stack wrongly define the variable before 
calling dpkg-buildpackage?

Any way, the value must be identical in all architectures. And it's not the 
case.



[1] https://buildd.debian.org/status/fetch.php?
pkg=rrdtool=arm64=1.7.0-1%2Bb1=1522153882=0
[2] https://buildd.debian.org/status/fetch.php?
pkg=rrdtool=armhf=1.7.0-1%2Bb1=155293=0

On Thursday, 29 March 2018 14:41:28 CEST Jean-Michel Vourgère wrote:
> Hello
> 
> My package rrdtool [1] got some multi-arch failures since last bin-nmu.
> 
> The problem is that pod2man uses the changelog date to generate the man
> footer, and that date is no longer the same on all architectures !
> 
> /usr/share/doc/librrds-perl/changelog.Debian.arm64.gz contains
> rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
>   * Binary-only non-maintainer upload for arm64; no source changes.
>   * Rebuild without ruby2.3 support.
>  -- arm Build Daemon (arm-conova-01)  conova...@buildd.debian.org>  Tue, 27 Mar 2018 12:27:33 +
> 
> 
> while /usr/share/doc/librrds-perl/changelog.Debian.armhf.gz contains
> rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
>   * Binary-only non-maintainer upload for armhf; no source changes.
>   * Rebuild without ruby2.3 support.
>  -- armhf / armel Build Daemon (hoiby)
>  Wed, 28 Mar 2018 08:13:09 +
> 
> 
> as a result, /usr/share/man/man3/RRDs.3pm.gz differs on arm64 architecture:
> .TH RRDs 3pm "2018-03-27" "perl v5.26.1" "User Contributed Perl
> Documentation" and on armhf architecture:
> .TH RRDs 3pm "2018-03-28" "perl v5.26.1" "User Contributed Perl
> Documentation"
> 
> Ultimately, this makes package librrds-perl is no longer co-installable.
> Multi-arch hinter says:
> librrds-perl conflicts on /usr/share/man/man3/RRDs.3pm.gz on armhf <->
> amd64, arm64, armel, and 6 more
> 
> Please advise how to proceed!
> 
> 
> [1] https://tracker.debian.org/pkg/rrdtool



signature.asc
Description: This is a digitally signed message part.

Re: multi-arch:same failures when bin-nmus changelog dates are not the same

2018-03-29 Thread Wookey 
On 2018-03-29 14:41 +0200, Jean-Michel Vourgère wrote:
> Hello
> 
> My package rrdtool [1] got some multi-arch failures since last bin-nmu.
> 
> The problem is that pod2man uses the changelog date to generate the man 
> footer, and that date is no longer the same on all architectures !

Don't do that. It's a reproducibility failure as well as breaking
multi-arch co-installability.
 
> Please advise how to proceed!

I'm surprised the reproducibility people have not nobbled pod2man to
stop this behaviour already. Is there a bg about it somewhere?

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: multi-arch:same failures when bin-nmus changelog dates are not the same

2018-03-29 Thread Julien Cristau 
On 03/29/2018 02:41 PM, Jean-Michel Vourgère wrote:
> Hello
> 
> My package rrdtool [1] got some multi-arch failures since last bin-nmu.
> 
> The problem is that pod2man uses the changelog date to generate the man 
> footer, and that date is no longer the same on all architectures !
> 
> /usr/share/doc/librrds-perl/changelog.Debian.arm64.gz contains
> rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
>   * Binary-only non-maintainer upload for arm64; no source changes.
>   * Rebuild without ruby2.3 support.
>  -- arm Build Daemon (arm-conova-01)  conova...@buildd.debian.org>  Tue, 27 Mar 2018 12:27:33 +
> 
> 
> while /usr/share/doc/librrds-perl/changelog.Debian.armhf.gz contains
> rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
>   * Binary-only non-maintainer upload for armhf; no source changes.
>   * Rebuild without ruby2.3 support.
>  -- armhf / armel Build Daemon (hoiby)  
>  
> Wed, 28 Mar 2018 08:13:09 +
> 
> 
> as a result, /usr/share/man/man3/RRDs.3pm.gz differs on arm64 architecture:
> .TH RRDs 3pm "2018-03-27" "perl v5.26.1" "User Contributed Perl Documentation"
> and on armhf architecture:
> .TH RRDs 3pm "2018-03-28" "perl v5.26.1" "User Contributed Perl Documentation"
> 
> Ultimately, this makes package librrds-perl is no longer co-installable. 
> Multi-arch hinter says:
> librrds-perl conflicts on /usr/share/man/man3/RRDs.3pm.gz on armhf <-> amd64, 
> arm64, armel, and 6 more
> 
> Please advise how to proceed!
> 
Make the manpage contents not depend on the build date?

Cheers,
Julien