Re: packages that FTBFS twice in a row ...

[Mattia Rizzolo]

On Sat, Dec 23, 2017 at 08:27:50AM +, Holger Levsen wrote:
> On Fri, Dec 22, 2017 at 10:43:34PM +0100, Mattia Rizzolo wrote:
> > So, yes, source packages can be built reproducibly!
> 
> neat, thanks for pointing this out! In which version of dpkg was that
> feature?

dpkg (1.18.11) unstable; urgency=medium
…
  * Make dpkg-source generate reproducible source packages when run
standalone, by honoring SOURCE_DATE_EPOCH.
…
  * Perl modules:
…
- Fix reproducible source package support in Dpkg::Source::Archive, by
  sorting the tar contents with --sort=name.
…
 -- Guillem Jover   Sun, 06 Nov 2016 03:09:02 +0100

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Holger Levsen]

On Fri, Dec 22, 2017 at 10:43:34PM +0100, Mattia Rizzolo wrote:
> Actually, Guillem went ahead and did this himself.  He also thought it
> would be hard, but after trying only few changes to dpkg were needed.
> Look:
[...] 
> So, yes, source packages can be built reproducibly!

neat, thanks for pointing this out! In which version of dpkg was that
feature?


-- 
cheers,
Holger


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Mattia Rizzolo]

On Fri, Dec 22, 2017 at 04:32:50PM +, Holger Levsen wrote:
> no. the creation of Debian source packages is not reproducible at the
> moment. I don't recall whether we found a fundamental problem with it or
> if simply we had other fishes to fry.

Actually, Guillem went ahead and did this himself.  He also thought it
would be hard, but after trying only few changes to dpkg were needed.
Look:

mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % mkdir 
../a ../b
mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % 
dpkg-source -b .
dpkg-source: info: using options from diffoscope/debian/source/options: 
--tar-ignore=.*.sw? --tar-ignore=*/*~ --tar-ignore=,,* --tar-ignore=.[#~]* 
--tar-ignore=.deps --tar-ignore=.git --tar-ignore=.gitattributes 
--tar-ignore=.gitignore --tar-ignore=.gitmodules
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building diffoscope in diffoscope_89.tar.xz
dpkg-source: info: building diffoscope in diffoscope_89.dsc
mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % dcmd mv 
../diffoscope_89.dsc ../a
mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % 
dpkg-source -b .
dpkg-source: info: using options from diffoscope/debian/source/options: 
--tar-ignore=.*.sw? --tar-ignore=*/*~ --tar-ignore=,,* --tar-ignore=.[#~]* 
--tar-ignore=.deps --tar-ignore=.git --tar-ignore=.gitattributes 
--tar-ignore=.gitignore --tar-ignore=.gitmodules
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building diffoscope in diffoscope_89.tar.xz
dpkg-source: info: building diffoscope in diffoscope_89.dsc
mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % dcmd mv 
../diffoscope_89.dsc ../b
mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % cd ..
mattia@warren ~/devel/reproducible/diffoscope % diffoscope a/diffoscope_89.dsc 
b/diffoscope_89.dsc
 
|##|
  100% Time: 0:00:00
mattia@warren ~/devel/reproducible/diffoscope %


So, yes, source packages can be built reproducibly!
:D

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Holger Levsen]

On Fri, Dec 22, 2017 at 04:59:35PM +, Thorsten Glaser wrote:
> >On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote:
> >> Does the reproducible build effort currently test for reproducibility of
> >> source packages?
> >
> >no. the creation of Debian source packages is not reproducible at the
> >moment. I don't recall whether we found a fundamental problem with it or
> 
> Debian source packages are the *source* form of everything in Debian;
> therefore, they are (per definitionem) “correct”, as they are taken
> and copied, not (re)created.

yes. the question was, whether it's possible to do this in a bit by bit
reproducible way. as became clear again here, this ain't easy and doesn't
get us much anyway, so we didnt pursue it further.


-- 
cheers,
Holger


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Thorsten Glaser]

Holger Levsen dixit:

>On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote:
>> Does the reproducible build effort currently test for reproducibility of
>> source packages?
>
>no. the creation of Debian source packages is not reproducible at the
>moment. I don't recall whether we found a fundamental problem with it or

Debian source packages are the *source* form of everything in Debian;
therefore, they are (per definitionem) “correct”, as they are taken
and copied, not (re)created.

>(I guess it's probably that this would require pristine-tar which would

pristine-tar is not perfect and does not work on all architectures
or with all workflows, not even all VCSes. This does not sound
desirable.

Standard workflow for a “second” upload is to download the previous
one, reusing the same origtgz, creating a second Debian source pak‐
kage with it, and then using debdiff to validate the changes, anyway.
(I do. Don’t you?) So I don’t think that’s something that needs to
be explored.

bye,
//mirabilos
-- 
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
16:06⎜ Thank god I found you =)   20:03│«bioe007:#cvs» mira2k: ty
18:36⎜«ThunderChicken:#cvs» mirabilos FTW!  23:03⎜«mithraic:#cvs» aaah. thanks

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Holger Levsen]

On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote:
> Does the reproducible build effort currently test for reproducibility of
> source packages? 

no. the creation of Debian source packages is not reproducible at the
moment. I don't recall whether we found a fundamental problem with it or
if simply we had other fishes to fry. 

(I guess it's probably that this would require pristine-tar which would
be a fundamental change if we'd make this a must)


-- 
cheers,
Holger


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Thorsten Glaser]

Andreas Beckmann dixit:

>How could we check for these bugs?

Why are these bugs anyway? I mean, not why they are defined as bugs
(I do know the rule), but why does this rule exist (or, at least,
still exist)?

Even quite some time ago, I’d assume a build to always start from
a clean state (.dsc or, nowadays, a VCS). Package uploads are made
after cowbuilder (pbuilder) or sbuild.

So, is this still necessary?

Apologies for getting slightly off with the topic.

bye,
//mirabilos (no offence intended, just curious)
-- 
This space for rent.

https://paypal.me/mirabilos to support my work.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: packages that FTBFS twice in a row ...

[Paul Wise]

On Thu, Dec 21, 2017 at 12:14 PM, Andreas Beckmann wrote:

> How could we check for these bugs?

I guess the archive-wide rebuilds should be the location for this.

https://wiki.debian.org/qa.debian.org/ArchiveTesting

IIRC Lucas used to do semi-regular testing of this.

> I think the interesting failures to look for ...

I'd suggest testing all of the points eventually though.

> Given proper pbuilder support (deliver build result from the first build
> even if 4. debian/rules clean failed), testing for 4.a) should be
> trivially possible to do for reproducible builds with only marginal
> computation time requirements.

The other thread has a response to this:

https://lists.debian.org/msgid-search/20171213103337.n7so73u5lmhbr...@layer-acht.org

> Does the reproducible build effort currently test for reproducibility of
> source packages?

It is focussed on binary packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

packages that FTBFS twice in a row ...

[Andreas Beckmann]

Hi,

here are my observations after analyzing a few pbuilder --twice failures
in experimental. I only did full (source+arch+indep) builds.


The command sequence being tested is roughly:

1. debian/rules clean
2. dpkg-source
3. debian/rules build binary
4. debian/rules clean
5. dpkg-source
6. debian/rules build binary

1.-3. are utilized by regular builds and tested by normal archive-wide
rebuilds, therefore I'll only consider packages passing these steps.

Possible failure scenarios for the second build:

4. debian/rules clean
   There are bugs related to make distclean and debian/rules clean, they
   usually don't show up during 1. since the source tree is not in a
   configured state (no Makefile?) and the debian/ tree is not in a
   built state.

   a) make distclean may fail, probably an upstream bug
  * #884898, icu/experimental, parallel distclean race

   b) passes, but leaves new/modified files in the source tree
  * This is the majority of bugs, usually generated filed don't get
deleted properly. The subsequent error from dpkg-source is
pretty obvious.

   c) passes, but leaves new/modified in the debian/ tree
  * #884419, #884815: override_dh_clean does not run dh_clean
resulting in debian/$PKG/ package build directories and
debhelper logfiles being left in the tree. Subsequent
dpkg-source will choke on unknown binary files under debian/
There is a lintian check coming: #884817 "lintian: check for
override_dh_clean target missing call to dh_clean".
  * there may be text-only changes in debian/ that don't trigger
errors, but cause differing source package to be built in 2./5.

   d) passes, but deletes files that cannot be regenerated
  * #884706, #884813, #884819, #884889
This passes the subsequent dpkg-source (since it will just warn
on deleted files by default, which is very convient to get rid
of generated files that are shipped in the upstream tarball),
but will fail during the following build

5. dpkg-source

   a) may fail as a consequence of 4.b), 4.c)

   b) may build a source package that differs from the one built in 2.
  Testing for these bugs easily may need some new features in
  pbuilder, e.g. a --one-and-a-half option :-)
  A possible candidate is git/experimental 1:2.15.1+next.20171214-1
  which should add a 'debian/git-core/usr/share/doc/git-core -> git'
  symlink (#884890).

6. debian/rules build binary

   a) may fail as a consequence of 4.d)


How could we check for these bugs?

I think the interesting failures to look for are 4.a), 5.b), 6.a)
(leaving out the probabe majority 5.a)), since they may make working
with the packages difficult by failing in non-obvious ways. I would also
consider these as RC.

We would probably need some enhancements for pbuilder to allow testing
points 4. and 5. without doing a full --twice run. Also I don't know
whether it is easily possible to classify pbuilder --twice failures to
the command that failed and whether it was first or second build.

Given proper pbuilder support (deliver build result from the first build
even if 4. debian/rules clean failed), testing for 4.a) should be
trivially possible to do for reproducible builds with only marginal
computation time requirements.

Does the reproducible build effort currently test for reproducibility of
source packages? In that case testing for 5.b) could hopefully be done
with reproducible builds as well, it would just require another
dpkg-source call. Failures for 5.a) could be filtered out unless someone
volunteers for the bug filing.

Testing for 6.a) effectively doubles the compute power needed for a
rebuild test, so maybe that should be rather left to infrequent
specialized archive-wide rebuilds.


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds