Bug#896934: diffoscope: decode monitor EDID data to text
On Thu, Apr 26, 2018 at 01:33:33PM +0800, Paul Wise wrote:
> Subsequently I looked up how
> to add new formats to diffoscope and found it was fairly easy.
:)
> If the attached patch is acceptable, let me know and I'll push the
> OpenPGP-signed version of the commit.
First please:
* add a test
* expand that TODO item, I can't understand what it is about
* wrap the long lines the way pep8 teaches
* explain why the external_tools.py's dict lists both edid-decode and
read-edid, but in the build-dep are made as alternatives
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#855273: diffoscope: fails to clean up after SIGTERM
Control: close -1 On Tue, Dec 05, 2017 at 06:55:02AM +0900, Chris Lamb wrote: > > > diffoscope: still fails to clean up after SIGTERM > > > > Can we reproduce this outside of Jenkins? Would really love a testcase > > so I can my teeth into this... > > Ping on this, Mattia? Would be great to either solve this or close the > bug either way. :) I haven't seen this on a while (or we accidentally hidden the effects), so I'm closing this bug. Don't worry I'll open a new one if I notice it again! :P -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#898022: diffoscope: Traceback when comparing paths with invalid unicode characters
Control: tag -1 patch
On Sun, May 06, 2018 at 01:38:58AM +0100, Chris Lamb wrote:
> This is via <https://github.com/lamby/trydiffoscope/issues/35>, but I
> think the bug is in diffoscope itself.
It is, although one could say it's a bug in argparse.
> However, I can't seem to minimally reproduce with file by itself:
>
> import magic
> filename = b'\xf0\x28\x8c\x28'
> with open(filename, 'w'):
> pass
> m = magic.open(magic.NONE)
> m.load()
> m.file(filename)
That's because argparse decodes the arguments, you can get the same
traceback by using this instead of the last command above:
|>>> m.file(filename.decode('utf-8', errors='surrogateescape'))
|Traceback (most recent call last):
| File "", line 1, in
| File "/usr/lib/python3/dist-packages/magic/compat.py", line 148, in file
|return Magic.__tostr(_file(self._magic_t, Magic.__tobytes(filename)))
| File "/usr/lib/python3/dist-packages/magic/compat.py", line 138, in __tobytes
|return bytes(b, 'utf-8')
|UnicodeEncodeError: 'utf-8' codec can't encode character '\udcf0' in position
0: surrogates not allowed
What do you think if we try to use:
|>>> m.file(f.encode('utf-8', errors='surrogateescape'))
In that place?
I.e., the following patch would fix this bug for me.
See also:
https://www.python.org/dev/peps/pep-0383/
https://bugs.python.org/issue21416
|diff --git a/diffoscope/comparators/utils/file.py
b/diffoscope/comparators/utils/file.py
|index 4fd49ac..0638ef4 100644
|--- a/diffoscope/comparators/utils/file.py
|+++ b/diffoscope/comparators/utils/file.py
|@@ -68,7 +68,7 @@ class File(object, metaclass=abc.ABCMeta):
| if not hasattr(self, '_mimedb'):
| self._mimedb = magic.open(magic.NONE)
| self._mimedb.load()
|-return self._mimedb.file(path)
|+return self._mimedb.file(path.encode('utf-8',
errors='surrogateescape'))
|
| @classmethod
| def guess_encoding(self, path):
Do you think this would be fine?
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#898022: diffoscope: Traceback when comparing paths with invalid unicode characters
On Thu, May 10, 2018 at 04:43:37PM +0100, Chris Lamb wrote: > > Do you think this would be fine? > > Whilst this works, would it not be better if we could use bytes for > filenames throughout? I mean, AIUI there is no assumption that > filesystems need to have any form of valid encoding whatsoever, let > alone UTF-8. That was my initial idea as well, but apparently the Python developers are of different opinion. Check out the PEP I linked in my previous email: https://www.python.org/dev/peps/pep-0383/ Together with the argparse bug I also linked: https://bugs.python.org/issue21416 - apparently it's "hard" (more like impossible?) to get bytes from the CLI... I believe that, like that bug is showing, we should just specify type=os.fsencode# https://docs.python.org/3/library/os.html#os.fsencode in the parser.add_argument() calls using a filename (to make sure argparse doesn't change output), and then re-encode them before passing them to functions that can't handle surrogate encoded stuff like this magic module. > However, somewhat happy to see this in diffoscope as it certainly > improves the current state of affairs. If you do commit it, please > include my testcase (or something based on it) that I added in: > > https://bugs.debian.org/898022#5 Of course. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#898022: diffoscope: Traceback when comparing paths with invalid unicode characters
Control: clone -1 -2
Control: tag -2 - patch
Control: severity -2 wishlist
Control: retitle -2 diffoscope: should handle the filenames as bytes
On Thu, May 10, 2018 at 06:01:50PM +0200, Mattia Rizzolo wrote:
> I believe that, like that bug is showing, we should just specify
> type=os.fsencode#
> https://docs.python.org/3/library/os.html#os.fsencode
> in the parser.add_argument() calls using a filename (to make sure
> argparse doesn't change output)
This indeed makes the filename be a .bytes through all the code, and
therefore requires a bunch of changes pretty much everywhere in the
comparators (str.endsiwth → bytes.endswith and with them all the
comparing strings needs to be become bytes as well).
I'm cloning this bug to keep track of this thing, as I'm not going to do
that now.
Initial patch to start (from there just try run it and it will crash)
|--- a/diffoscope/main.py
|+++ b/diffoscope/main.py
|@@ -74,11 +74,13 @@ def create_parser():
| parser = argparse.ArgumentParser(
| description='Calculate differences between two files or
directories',
| add_help=False, formatter_class=HelpFormatter)
|-parser.add_argument('path1', nargs='?', help='First file or directory
to '
|-'compare. If omitted, tries to read a diffoscope
diff from stdin.')
|-parser.add_argument('path2', nargs='?', help='Second file or directory
to '
|-'compare. If omitted, no comparison is done but
instead we read a '
|-'diffoscope diff from path1 and will output this in
the formats '
|+parser.add_argument('path1', nargs='?', type=os.fsencode,
|+help='First file or directory to compare. If
omitted, '
|+'tries to read a diffoscope diff from stdin.')
|+parser.add_argument('path2', nargs='?', type=os.fsencode,
|+help='Second file or directory to compare. If
omitted, '
|+'no comparison is done but instead we read a
diffoscope '
|+'diff from path1 and will output this in the
formats '
| 'specified by the rest of the command line.')
| parser.add_argument('--debug', action='store_true',
| default=False, help='Display debug messages')
|
Also, I believe doing that change also requires changing the handling of
the filenames in the Container objects, thanks to diffoscope's
recursivity. So really, a quite big change.
In the meantime to fix #898022 I'll apply the patch I posted earlier.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#898683: diffoscope: not installable from stretch-backports because of unmet dependency python3-distutils
Control: notfound -1 94~bpo9+1 Control: found -1 94 On Tue, May 15, 2018 at 09:15:58AM +0200, Moritz Schlarb wrote: > diffoscope 94~bpo9+1 depends on python3-distutils which is not present in > stretch-backports (and it doesn't look like it is just failing to migrate or > stuck in NEW). Thanks for your report! I'm uploading right now 94~bpo9+2 to fix this issue in stretch-backports right away. python3-distutils won't be present in stretch-backports, but that dependency is needed in buster, so I'll need to figure out the right incantation to get a dependency line that works for both (as I don't really want backports delta). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Experimental package repository moved
Hi people,
I apologize for the delay in sending this notice, I completely forgot…
On Wednesday the alioth.d.o admin, as planned[0], shut down the project
websites, including our reproducible.alioth.debian.org.
We were using that space also to host our experimental toolchain
repository[1].
Not having a particularly good idea on where to move it and also having
received no suggestions on IRC, I moved them to jenkins as well. This
means that from now on pretty much only me and Holger will be able to
upload packages there. I don't forsee this as a problem in the short
term, as I was pretty much the only one keeping up with the updates of
our patched gcc and dpkg. In the long term we should get rid of those
as well, so…[2]. In case you would like to upload new packages, just
get in touch with me.
The new URL for the repository is
https://tests.reproducible-builds.org/debian/repository/debian/
It's signed by the same key used previously, so apart from the changing
the URL (and maybe dealing with the HTTPS-only repo[3]) everything
should just work.
We also need somebody to update the wiki page[1], which has been
outdated for a while now…
[0] https://lists.debian.org/debian-devel-announce/2018/04/msg8.html
[1] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
[2] On a related note, we really need somebody to figure what are the
next steps on BUILD_PATH_PREFIX_MAP and gcc, etc.
[3] e.g.
https://salsa.debian.org/qa/jenkins.debian.net/commit/d4b907243
& https://salsa.debian.org/qa/jenkins.debian.net/commit/db3832025
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: [rb-general] Please review the draft for week 160's blog post
On Tue, May 22, 2018 at 07:36:46AM +0100, Chris Lamb wrote:
> Chris Lamb wrote:
>
> > Please review the draft for week 160's blog post [..]
>
> This has now been published; many thanks to all who contributed!
Erm, Chris, could you at least please make sure all the followup emails
are taken care of before publishing?
https://lists.reproducible-builds.org/pipermail/rb-general/2018-May/000960.html
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
package uploaded to our repo
https://tests.reproducible-builds.org/debian/repository/debian/gcc-7_7.3.0-26+really21.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#901548: diffoscope: Add lz4 comparator
Control: tag -1 moreinfo Hi Xavier, On Thu, Jun 14, 2018 at 12:27:47PM -0400, Xavier Briand wrote: > Add lz4 comparator. Thanks for your patch! However, I'd like to ask for some changes and improvements, and I also have some questions about it. See the comments inlined in the diff: --- /dev/null +++ b/diffoscope/comparators/lz4.py @@ -0,0 +1,61 @@ +# -*- coding: utf-8 -*- +# +# diffoscope: in-depth comparison of files, archives, and directories +# +# Copyright © 2014-2015 Jérémy Bobbio Surely this is a copy-paste error of some sort? +class Lz4File(File): +DESCRIPTION = "LZ4 compressed files" +CONTAINER_CLASS = Lz4Container +FILE_TYPE_RE = re.compile(r'^LZ4 compressed data$') Is this regex actually correct? I don't have any .lz4 file at hand, but I doubt `file` returns that string and nothing else (i.e., I'm concerned about the anchoring). Then, we really like tests. They are as easy as the comparators to write, and there are plenty of examples, do you think you could provide some? -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#901548: diffoscope: Add lz4 comparator
On Thu, Jun 14, 2018 at 02:25:09PM -0400, Xavier Briand wrote: > I followed the instructions provided in the CONTRIBUTING.rst > <https://salsa.debian.org/reproducible-builds/diffoscope/blob/master/CONTRIBUTING.rst> > file. > That being said, I'd feel more comfortable using gitlab's merge request. > > How would I go about it? Close this one and submit an other one? No, please keep this open and cross reference them all (here we'll mark this bug as forwarded to the MR, MR will just link this, and the commit message should have a 'Closes: #901548' line). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#901548: diffoscope: Add lz4 comparator
Control: forwarded -1
https://salsa.debian.org/reproducible-builds/diffoscope/merge_requests/4
On Thu, Jun 14, 2018 at 02:45:33PM -0400, Xavier Briand wrote:
> I opened a merge request on Gitlab (
> https://salsa.debian.org/reproducible-builds/diffoscope/merge_requests/4)
Thank you!
I reported my previous comments in a discussion there.
> forwarded 901548
> https://salsa.debian.org/reproducible-builds/diffoscope/merge_requests/4
This would need to either go in its own email to
cont...@bugs.debian.org, or on top of this message and cc control@bugs,
or do something like what I did in this message or any variants of them…
I believe we should spare mostly driven-by contributors from figuring
out how to interact at this level with the bug tracker, so I just did it
myself :)
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: appears to break multiple autopkgtests
Hi Ondrej,
On Wed, Jun 27, 2018 at 11:05:37PM +0200, Paul Gevers wrote:
> With a recent upload of pytest the autopkgtest of diffoscope, doit,
> pytest-httpbin and pytest-sugar started to fail in testing.
> See: https://qa.debian.org/excuses.php?package=pytest and links therein.
>
> With a very quick look, it seems that pytest-httpbin and pytest-sugar
> just need to adapt to the new behavior (deprecation of functionality). I
> can't really judge diffoscope and doit without diving deeper (I am going
> to bed now).
diffoscope is failing due to:
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py", line
176, in wrap_session
INTERNALERROR> config.hook.pytest_sessionstart(session=session)
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/__init__.py", line
617, in __call__
INTERNALERROR> return self._hookexec(self, self._nonwrappers +
self._wrappers, kwargs)
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/__init__.py", line
222, in _hookexec
INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/__init__.py", line
216, in
INTERNALERROR> firstresult=hook.spec_opts.get('firstresult'),
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/callers.py", line
201, in _multicall
INTERNALERROR> return outcome.get_result()
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/callers.py", line
76, in get_result
INTERNALERROR> raise ex[1].with_traceback(ex[2])
INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/callers.py", line
180, in _multicall
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/terminal.py",
line 510, in pytest_sessionstart
INTERNALERROR> self._write_report_lines_from_hooks(lines)
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/terminal.py",
line 515, in _write_report_lines_from_hooks
INTERNALERROR> self.write_line(line)
INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/terminal.py",
line 294, in write_line
INTERNALERROR> line = six.text_type(line, errors="replace")
INTERNALERROR> TypeError: decoding to str: need a bytes-like object, int found
Personally, I can hardly imagine how this would be a diffoscope issue,
so I ask the pytest maintainer to look into it.
Judging by the position of that output, it seem to come from the
conftest.py, pytest_report_header() function, alas I haven't tried
removing it to confirm.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#902709: diffoscope: test failures everywhere
Package: diffoscope Version: 98 Severity: serious Tags: ftbfs So, autopkgtest is failing, for both the tests (with and without recommends): https://ci.debian.net/data/autopkgtest/testing/amd64/d/diffoscope/529342/log.gz The ubuntu build also failed with a very similar error: https://launchpadlibrarian.net/376469998/buildlog_ubuntu-cosmic-amd64.diffoscope_98_BUILDING.txt.gz And also the reproducible builds build FTBFS with the same errors. So, I believe there is a bug here that needs to be fixed. Incidentally, Chris: any reason you did binary uploads instead of source only uploads? Considering how widespread the same failures are I have to believe that the fact it built for you is odd, instead of the other way around as it usually is :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#902709: diffoscope: test failures everywhere
Control: owner -1 !
Control: tag -1 pending
On Mon, Jul 02, 2018 at 06:52:15PM +0100, Chris Lamb wrote:
> Are we still seeing this on current master? (As-of writing, that is
> a6b4effc). I ask because, as mentioned previously, I cannot reproduce
> this. :)
This particular error is fixed by d6f1d04 (and I did include the bug
number in the commit).
However, in the process of fixing this I also configure gitlab CI, which
is reporting 4 more errors (look at salsa.d.o, or IRC yesterday).
> Happy to upload if your recent changes (d6f1d04 looks promising?)
> fix it.
I'll take care of it once I can debug the other 4 errors (tbh, I didn't
try to reproduce them locally).
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#902709: diffoscope: test failures everywhere
On Mon, Jul 02, 2018 at 08:43:04PM +0100, Chris Lamb wrote:
> > This particular error is fixed by d6f1d04 (and I did include the bug
> > number in the commit).
>
> Are we talking about the right commit? I only ask because I do not see
> the bug number in the commit... :)
>
>https://salsa.debian.org/reproducible-builds/diffoscope/commit/
> d6f1d04b3dbc3f350f50a798979e1501a8cb89f3
Oops, copy-paste error. Indeed, I'm referring to this other commit:
https://salsa.debian.org/reproducible-builds/diffoscope/commit/a6b4effcfb24780d9d2d1b76efa33132381f76eb
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#902920: diffoscope: be triggered by all the reverse-recommends
Package: diffoscope
Version: 98
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org
currently diffoscope is triggered only by its own dependency (python3,
python3-distutils, python3-distro, python3-libarchive-c, python3-magic)
and only one package that is not in that set, python3-pytest.
This is suboptimal: diffoscope relies *a lot* on the output of the
programs it is calling, and as such it has a tendency on breaking every
so often when that output changes. Usually we notice such breakage by
accident.
I would like to have all the recommended packages in the
Testsuite-Triggers field, but I can't figure how to accomplish that
without duplicating the list of packages a 3rd time (one in d/control,
the other in diffoscope/external_tools.py).
Any hint from the CI team would be appreciated.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#902920: diffoscope: be triggered by all the reverse-recommends
Thanks Ian for your insight!
On Tue, Jul 03, 2018 at 03:59:11PM +0100, Ian Jackson wrote:
> My approach is to autogenerate debian/tests/control. I have a rune
> which updates it, and a test case which fails when I forget :-).
So it seems this is pretty much the only sane way around this.
> (In my case debian/tests/control is generated not from debian/control,
> but from the test files which contain annotations about their
> dependencies, restrictions, etc.)
This would also be the case for us.
>Tests: hint-testsuite-triggers
>Depends: gnupg, patch, diffutils
>Restrictions: hint-testsuite-triggers
>
> The effect of putting something like that in your debian/tests/control
> is that autopkgtest will always skip the test, but the Depends get
> copied to Testsuite-Triggers and used by ci.d.n.
Mh, in our case we have this entry:
Tests: pytest
Depends: diffoscope, python3-pytest
Restrictions: needs-recommends
If I go down the route of autogenerating d/tests/control I could simply
drop the (as Paul pointed out, unreliable) needs-recommends restriction,
and have all the recommends spelled-out in the Depends field.
Do any of the diffoscope contributors have any hard feelings on me
making d/rules yet longer and implement the above? It would end up with
another bit to update whenever a new debian relations in added in the
external_tools, even if done semi-automatically...
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#902709: diffoscope: test failures everywhere
On Fri, Jul 6, 2018 at 7:50 PM Chris Lamb wrote: > > I'll take care of it once I can debug the other 4 errors (tbh, I didn't > > try to reproduce them locally). > > Did you manage to get to this? I tried to reproduce them locally (also jenkins doesn't hit them), but failed to and after some tries my allocated time finished. > Are we even still seeing them? :-) Alas yes, see the failures in https://salsa.debian.org/reproducible-builds/diffoscope/pipelines/12501 (I believe you also receive emails for those?) But as I said I'm totally unable to reproduce them, so I'm thinking tomorrow to fix up some other things and release nonetheless, hopefully somebody can look at GitLab CI at another time. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903444: diffoscope: FileNotFoundError with gfxboot/4.5.2-1.1-6
un obj = self.load(module, kwargs) File "/usr/lib/python3/dist-packages/binwalk/core/module.py", line 775, in load return module(self, **argv) File "/usr/lib/python3/dist-packages/binwalk/core/module.py", line 233, in __init__ self.plugins = binwalk.core.plugin.Plugins(self) File "/usr/lib/python3/dist-packages/binwalk/core/plugin.py", line 93, in __init__ self.settings = binwalk.core.settings.Settings() File "/usr/lib/python3/dist-packages/binwalk/core/settings.py", line 44, in __init__ magic=self._magic_signature_files(user_only=True), File "/usr/lib/python3/dist-packages/binwalk/core/settings.py", line 70, in _magic_signature_files files += [os.path.join(user_dir, x) for x in os.listdir(user_dir)] FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/jenkins/.binwalk/magic' Interestingly, I couldn't reproduce this locally, so it might have something to do with the environment we are calling diffoscope in jenkins (notice the odd file it seems to be looking for while crashing…). Artifacts are available in https://tests.reproducible-builds.org/debian/artifacts/r00t-me/gfxboot_unstable_amd64_tmp-dakAv/b1/ for a few more hours, or I have a copy with me as well for now. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903446: diffoscope: libarchive.exception.ArchiveError with lie/2.2.2+dfsg-3
/python3/dist-packages/diffoscope/comparators/utils/container.py", line 177, in compare_pair file1, file2, source=None, diff_content_only=no_recurse) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 118, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 366, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 304, in _compare_using_details details.extend(self.compare_details(other, source)) File "/usr/lib/python3/dist-packages/diffoscope/comparators/elf.py", line 590, in compare_details source="file list", File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 228, in from_text_readers **kwargs File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 186, in from_feeder unified_diff = diff(feeder1, feeder2) File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 327, in diff return run_diff(fifo1_path, fifo2_path, fifo1.end_nl_q, fifo2.end_nl_q) File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 220, in __exit__ self.join() File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 253, in join raise self._exception File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 244, in run end_nl = self.feeder(fifo) File "/usr/lib/python3/dist-packages/diffoscope/feeders.py", line 45, in feeder for buf in in_file: File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/libarchive.py", line 91, in list_libarchive with libarchive.file_reader(path) as archive: File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__ return next(self.gen) File "/usr/lib/python3/dist-packages/libarchive/read.py", line 73, in file_reader ffi.read_open_filename_w(archive_p, path, block_size) File "/usr/lib/python3/dist-packages/libarchive/ffi.py", line 85, in check_int raise archive_error(args[0], retcode) File "/usr/lib/python3/dist-packages/libarchive/ffi.py", line 69, in archive_error raise ArchiveError(msg, errno(archive_p), retcode, archive_p) libarchive.exception.ArchiveError: Unrecognized archive format (errno=84, retcode=-30, archive_p=140510526190864) I can totally reproduce this locally with v99, artifacts are available till tomorrow on https://tests.reproducible-builds.org/debian/artifacts/r00t-me/lie_unstable_amd64_tmp-JkpRk/ and I also have a copy of them. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903447: diffoscope: AttributeError with node-module-deps/6.1.0-1
Package: diffoscope
Version: 99
Severity: important
As seen with node-module-deps/6.1.0-1 on all suites/architectures:
Mon Jul 9 07:29:58 UTC 2018 I: diffoscope 99 will be used to compare the two
builds:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 460, in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 432, in
run_diffoscope
difference = compare_root_paths(path1, path2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
68, in compare_root_paths
difference = compare_files(file1, file2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
118, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/debian.py", line
184, in compare
differences = super().compare(other, *args, **kwargs)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 366, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 321, in _compare_using_details
other.as_container, no_recurse=no_recurse))
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py",
line 177, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
118, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 366, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 321, in _compare_using_details
other.as_container, no_recurse=no_recurse))
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py",
line 177, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
118, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 366, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 321, in _compare_using_details
other.as_container, no_recurse=no_recurse))
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py",
line 177, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
118, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 366, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 321, in _compare_using_details
other.as_container, no_recurse=no_recurse))
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py",
line 177, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
118, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 366, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 304, in _compare_using_details
details.extend(self.compare_details(other, source))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/json.py", line
73, in compare_details
diff = {repr(x): y for x, y in jsondiff.diff(a, b).items()}
AttributeError: 'list' object has no attribute 'items'
I can totally reproduce this locally; artifacts will be available till
tomorrow on
https://tests.reproducible-builds.org/debian/artifacts/r00t-me/node-module-deps_unstable_amd64_tmp-BYy96/
and I have a copy of them as well.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903449: diffoscope: RecursionError with ghc/8.4.3-1
diff/__init__.py", line 597, in diff return cls(**kwargs).diff(a, b, fp) File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 501, in diff d, s = self._obj_diff(a, b) File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 488, in _obj_diff return self._list_diff(a, b) File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 408, in _list_diff for sign, value, pos, s in self._list_diff_0(C, X, Y, len(X), len(Y)): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 374, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j-1): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 374, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j-1): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 374, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j-1): [Previous line repeated 354 more times] File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 379, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i, j-1): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 384, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 374, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j-1): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 374, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j-1): File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 374, in _list_diff_0 for annotation in self._list_diff_0(C, X, Y, i-1, j-1): [Previous line repeated 593 more times] File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 372, in _list_diff_0 d, s = self._obj_diff(X[i-1], Y[j-1]) File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 491, in _obj_diff elif a != b: RecursionError: maximum recursion depth exceeded in comparison I don't have artifacts for this, so I didn't try to reproduce it. Also it doesn't seem very reproducible either, as other suites/architectures didn't hit this crash in their last run. Nonetheless, I figured I'd file this for tracking (it sounds easy to check for RecursionError and give up on the jsondiff comparator…). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903447: diffoscope: AttributeError with node-module-deps/6.1.0-1
On Tue, Jul 10, 2018 at 10:12:45AM +0200, Mattia Rizzolo wrote:
> AttributeError: 'list' object has no attribute 'items'
>
>
> I can totally reproduce this locally; artifacts will be available till
> tomorrow
This is caused by the two attached very small .json:
mattia@warren ..cible/diffoscope/test/node-module-deps % diffoscope 1.json
2.json
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 460, in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 432, in
run_diffoscope
difference = compare_root_paths(path1, path2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
68, in compare_root_paths
difference = compare_files(file1, file2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
118, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 366, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 304, in _compare_using_details
details.extend(self.compare_details(other, source))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/json.py", line
73, in compare_details
diff = {repr(x): y for x, y in jsondiff.diff(a, b).items()}
AttributeError: 'list' object has no attribute 'items'
--
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 `-
1.json
Description: application/json
2.json
Description: application/json
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903447: diffoscope: AttributeError with node-module-deps/6.1.0-1
On Tue, Jul 10, 2018 at 03:44:21PM +0200, Mattia Rizzolo wrote:
> On Tue, Jul 10, 2018 at 10:12:45AM +0200, Mattia Rizzolo wrote:
> > AttributeError: 'list' object has no attribute 'items'
> >
> >
> > I can totally reproduce this locally; artifacts will be available till
> > tomorrow
>
> This is caused by the two attached very small .json:
>
> mattia@warren ..cible/diffoscope/test/node-module-deps % diffoscope 1.json
> 2.json
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 460, in main
> sys.exit(run_diffoscope(parsed_args))
> File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 432, in
> run_diffoscope
> difference = compare_root_paths(path1, path2)
> File
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py",
> line 68, in compare_root_paths
> difference = compare_files(file1, file2)
> File
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py",
> line 118, in compare_files
> return file1.compare(file2, source)
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
> line 366, in compare
> difference = self._compare_using_details(other, source)
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
> line 304, in _compare_using_details
> details.extend(self.compare_details(other, source))
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/json.py", line
> 73, in compare_details
> diff = {repr(x): y for x, y in jsondiff.diff(a, b).items()}
> AttributeError: 'list' object has no attribute 'items'
Which for what I'm concerned is a jsondiff bug that I reported at
https://github.com/ZoomerAnalytics/jsondiff/issues/20
Nonetheless, I'd say to wrap the whole jsondiff stuff and catch all
possible exceptions (this would cover 903449 as well) and call it a day.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903449: diffoscope: RecursionError with ghc/8.4.3-1
On Tue, Jul 10, 2018 at 10:15:57AM +0200, Mattia Rizzolo wrote: > > Thu Jul 5 10:46:13 UTC 2018 I: diffoscope 98 will be used to compare the > two builds: > Traceback (most recent call last): … > File "/usr/lib/python3/dist-packages/jsondiff/__init__.py", line 491, in > _obj_diff > elif a != b: > RecursionError: maximum recursion depth exceeded in comparison This is definitely a jsondiff bug: https://github.com/ZoomerAnalytics/jsondiff/issues/18 As I mentioned on #903447 I'd say to wrap the jsondiff call and forget. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Heads-up: New upstream version of src:file in experimental
Hi Christoph! On Thu, Jul 26, 2018 at 08:37:58AM +0200, Christoph Biedl wrote: > after a somewhat bumpy experience following the upload of the previous > upstream release of file (5.33), I eventually decided to introduce a > release procedure for src:file in Debian: New upstream release uploads > will go to experimental first, and package maintainers that probably > would like to know about that receive a notification about that so > they have some time to brace for impact. Thank you very much for this! > Additional question: Would you like to receive such notifications in > the future? If yes, please drop me a line in private. Same if you think > there is a better address than the "@packages.debian.org" one > I used this time - but I prefer role/team/package addresses over > personal ones. I'll add this to a small document to debian/ so that > information will be public - but not forgotten in the future. diffoscope@p.d.o is fine for diffoscope. An alternative would be our list address, but the former also forwards to the latter¹ so I'd prefer to keep the @p.d.o one for now. ¹ https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20180723/010464.html I'll test diffoscope and if you don't hear from me (in the form of bug reports), everything is fine ^^ BTW, for diffoscope a test build using the new version of file is enough of a test (in case you want to just do it yourself :)). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for week 174's blog post
> Please review the draft for week 174's blog post: > > https://reproducible-builds.org/blog/posts/174/?draft > > Feel free to commit any changes directly to _blog/posts/174.md in Git: I added a FIXME on an item. I'm afraid I won't be able to fix it though (I'm supposed to be on vacation!), so I'd need somebody else to expand that. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Empty build-id to make package reproducible
On Fri, Aug 31, 2018 at 09:44:18AM +0300, Otto Kekäläinen wrote: > pe 31. elok. 2018 klo 0.46 Daniel Kahn Gillmor (d...@fifthhorseman.net) > kirjoitti: > .. > > does this mean that galera-3 debugging symbols won't be easily findable? > > Perhaps, but we decided that responsibility is important and the > package should pass the new CI pipeline we set up at > https://salsa.debian.org/mariadb-team/galera-3/pipelines/15700 > Note that this still just a commit on sitting on the master branch, > and it hasn't yet been uploaded anywhere and this might not be the > final solution. > > Suggestions for better solutions are welcome. The thing I can say is that that commit is not fixing *anything*. The pipeline failed before and after https://salsa.debian.org/mariadb-team/galera-3/commit/1460cfa128fb457b5b5c60fcc5cac6faf5a216d5 (as can be seen in that page quite clearly). Instead, what fixed the pipeline was the next commit, which made DEB_BUILD_OPTIONS=nocheck actually work. Indeed, what was failing in the reprotest stage of the pipeline were the tests of the package, so disabling that made the pipeline pass. As a datapoint, the package is reproducible in our infra. > > then again, the debugging symbols for galera-3 look like they're being > > generated in a way that is pretty out-of-date, and hasn't been touched > > in at least 3 years, so maybe the maintainers don't care about these > > symbols very much: > > > > > > https://salsa.debian.org/mariadb-team/galera-3/blame/master/debian/rules#L51 > > This package is actively maintained and everything should be up to > date. If you are an expert on debug package rules stanzas, we are > happy to take any suggestions (or merge requests on Salsa) to make > that section not so "pretty out-of-date". I see dkg submitted a change, https://salsa.debian.org/mariadb-team/galera-3/commit/853d8dc20dbf67e9d8ac76668098a6b3560ab786 however, I wonder if that actually works with --build-id=none, given that the debug symbols are placed next to the build-id? (not sure, maybe there is a fallback, I haven't actually checked). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Empty build-id to make package reproducible
On Sun, Sep 02, 2018 at 12:15:57AM +0300, Otto Kekäläinen wrote: > First we fixed what r-b infra showed in diffoscope as the culprit, > then we fixed what reprotest showed as the failure on Salsa-CI. None > of the fixes were uploaded and now all of a sudden r-b pass.. Oh, that's annoying. And alas hard to figure now unless you just so happen to have the .buildinfo of some unreproducible builds :| > > As a datapoint, the package is reproducible in our infra. > > Apparently it now is.. > 2018-08-22 23:50 25.3.23-1 unstable amd64 reproducible > > .. but it was not in unstable at the time we were investigating this > and trying to fix it: > 2018-07-05 21:09 25.3.23-1 unstable amd64 unreproducible unreproducible > > (from https://tests.reproducible-builds.org/debian/history/galera-3.html) > > It seems we were trying to fix in the package an issue that was after > all in the r-b infra. I hadn't looked at the history before. Looking at it now it seems like it was costantly unreproducible in unstable, and the first reproducible built happened on 2018-08-12. That would be somewhat consistent with the change we did following the gcc-7→gcc-8 default change, where we instructed gcc to inject a new build flag -ffile-prefix-map to fix unreproducibilities caused by __FILE__ and assert() (that before should have been still fixed by our patched gcc-7 though, so I wouldn't know why it was unreproducible before without more data). > > I see dkg submitted a change, > > https://salsa.debian.org/mariadb-team/galera-3/commit/853d8dc20dbf67e9d8ac76668098a6b3560ab786 > > however, I wonder if that actually works with --build-id=none, given > > that the debug symbols are placed next to the build-id? (not sure, > > maybe there is a fallback, I haven't actually checked). > > Well, as the package is now reproducible on r-b infra without any > changes, I'll revert these experiments we did that are in git but > never uploaded. I recommend so, yes. disabling the build id is something that I've never seen done anywhere, and I wouldn't be confidend nothing will notice… To me it seems something that random tools could take as a given. And as dkg said, I would find it better to figure what causes it to vary, rather than hide it :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Empty build-id to make package reproducible
On Sun, Sep 02, 2018 at 04:47:22PM +0300, Otto Kekäläinen wrote:
> Now all of my packages build reproducibly apart from the biggest one:
> MariaDB 10.1.35-1 is OK in Buster but the same revision fails in Sid.
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mariadb-10.1.html
mhh, on i386 it's unreproducible even on buster though :\
In general, if a package is reproducible in buster but not in sid, it
means it's dependant on the build path, which is varied in sid but not
in buster.
Sadly diffoscope timeouts for mariadb (probably too many diffs), so it's
harder to check.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#905885: diffoscope: skipping tests on ci.debian.net is perhaps wrong?
Control: allow to override @skip_unless_tools_exist during tests and fail the test if the tool is missing On Sun, Aug 12, 2018 at 12:03:50AM +1000, Stuart Prescott wrote: > *also* diffoscope recommends apktool but tests on ci.d.n do not fail (but > should, I think) what you say here it's half true: the autopkgtest has Depends: all the recommends that we have. What is happening is that ci.d.n/autopkgtest (no clue what piece of the puzzle is responsable for this) is downloading the test dependencies from unstable if they are not available on testing, silently. I believe you may want to get in touch with the CI team for this, I don't think there is much a package can do here. > > > Perhaps @tool_required could be extended with an "all tools required" > > > mode such that no tests are skipped or missing tools are a test failure > > > (or error). An environment variable would work for setting that mode > > > and that mode used at package build time and in autopkgtest. > > > > (One difficulty with "just" extending @tool_required is that sometimes > > we really do want to skip the tests as they require a newer/older > > version of a particular tool in order that we can correctly match up > > the output.) That's an interesting idea, and I'm retitling this bug to do this. Though what we would need to twak is the @skip_unless_tools_exist decorator we use in the tests. Also, we have comparators (and tests) for tools that Debian doesn't ship, so if we add a flag to make @skip_unless_tools_exist fail a test instead of skipping it, we would also need to provide a mechanism to "override the override" and have it really skip those :) I'm not exactly sure how we should handle the various other @skip_unless_tool_is_* and friends though... -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#908072: diffoscope: `bin/diffoscope --list-debian-substvars` output depends on installed packages
Package: diffoscope
Version: 99
Severity: important
`bin/diffoscope --list-debian-substvars` depends on installed packages.
In particular, it seems "gnupg" and "rpm2cpio" are not printed if they
are not installed.
This makes d/rules generate differing d/tests/control whether the
package is built with nocheck or not.
This accidentally caused the FTBFS of version 100 (about to be
reported).
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#908074: diffoscope: test failures with LLVM 7
st_rlib.py:105: AssertionError This is with: ii llvm (1:7.0-43ubuntu1) ii llvm-7 (1:7~+rc2-1~exp3) ii llvm-7-runtime (1:7~+rc2-1~exp3) ii llvm-runtime (1:7.0-43ubuntu1) But I have no reasons to be believe it's ubuntu-specific, so I'm reporting this bug. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#908076: diffoscope: FTBFS: Files debian/tests/control and debian/tests/control.tmp differ
Source: diffoscope
Version: 100
Severity: serious
Tags: pending
Log:
|dh clean --with python3 --with bash-completion --buildsystem=pybuild
| debian/rules override_dh_auto_clean
|make[1]: Entering directory '/build/1st/diffoscope-100'
|Generating the debian/tests/control file...
|Files debian/tests/control and debian/tests/control.tmp differ
|
|The generated control file differs from the actual one.
|A sourceful upload of this package is needed.
|
|Differences:
|--- debian/tests/control 2018-08-31 20:09:48.0 -1200
|+++ debian/tests/control.tmp 2019-10-06 08:45:13.401730614 -1200
|@@ -2,7 +2,7 @@
| # EDIT debian/tests/control.in INSTEAD!
| #
| Tests: pytest-with-recommends
|-Depends: diffoscope, python3-pytest, file, abootimg, acl, apktool [!ppc64el
!s390x], binutils-multiarch, bzip2, caca-utils, colord, db-util,
default-jdk-headless | default-jdk | java-sdk, device-tree-compiler, docx2txt,
e2fsprogs, enjarify, fontforge-extras, fp-utils [!ppc64el !s390x], genisoimage,
gettext, ghc, ghostscript, giflib-tools, gnumeric, imagemagick, jsbeautifier,
libarchive-tools, llvm, lz4, mono-utils, odt2txt, oggvideotools [!s390x],
openssh-client, pgpdump, poppler-utils, procyon-decompiler, r-base-core, sng,
sqlite3, squashfs-tools, tcpdump, unzip, xmlbeans, xxd | vim-common, xz-utils
|+Depends: diffoscope, python3-pytest, file, abootimg, acl, apktool [!ppc64el
!s390x], binutils-multiarch, bzip2, caca-utils, colord, db-util,
default-jdk-headless | default-jdk | java-sdk, device-tree-compiler, docx2txt,
e2fsprogs, enjarify, fontforge-extras, fp-utils [!ppc64el !s390x], genisoimage,
gettext, ghc, ghostscript, giflib-tools, gnumeric, gnupg, imagemagick,
jsbeautifier, libarchive-tools, llvm, lz4, mono-utils, odt2txt, oggvideotools
[!s390x], openssh-client, pgpdump, poppler-utils, procyon-decompiler,
r-base-core, rpm2cpio, sng, sqlite3, squashfs-tools, tcpdump, unzip, xmlbeans,
xxd | vim-common, xz-utils
|
| Tests: pytest
| Depends: diffoscope, python3-pytest, file
|make[1]: *** [debian/rules:85: override_dh_auto_clean] Error 1
|make[1]: Leaving directory '/build/1st/diffoscope-100'
|make: *** [debian/rules:35: clean] Error 2
|dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
This was originally caused by #908072 - and incidentally fixing this
FTBFS by just applying that diff would case diffoscope to FTBFS with
nocheck… (as v99 did, but nobody noticed).
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903444: diffoscope: FileNotFoundError: [Errno 2] No such file or directory: '/home/lamby/.binwalk/magic' with gfxboot/4.5.2-1.1-6
On Mon, Sep 10, 2018 at 06:06:47PM +0100, Chris Lamb wrote:
> tags 903444 + pending
> thanks
>
> Fixed in Git, pending upload:
>
>
> https://salsa.debian.org/reproducible-builds/diffoscope/commit/075acf2f8c599e0f53463fee368a1a929e94a8eb
.oO wow
That's a crazy one, thanks for tracking this down!
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--
Package: ghostscript
Version: 9.20~dfsg-3.2+deb9u5
Severity: serious
X-Debbugs-CC: t...@security.debian.org, Moritz Mühlenhoff ,
reproducible-bui...@lists.alioth.debian.org
Control: affects -1 diffoscope
Dear maintainer,
after the latest ghostscript security update, ps2ascii started to crash:
|% ps2ascii
/build/diffoscope-101~bpo9+1/.pybuild/pythonX.Y_3.5/build/tests/data/test1.ps
|Error: /typecheck in --.bind--
|Operand stack:
| --nostringval-- false setshared true --dict:30/32(L)-- typecheck
--nostringval-- currentglobal .currentglobal
|Execution stack:
| %interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostringval-- false 1 %stopped_push 1998 2 3 %oparray_pop
1997 2 3 %oparray_pop 1981 2 3 %oparray_pop 1868 2 3
%oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval--
--nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 2009
3 3 %oparray_pop --nostringval-- --nostringval--
--dict:1267/1684(G)-- --nostringval-- 1936 %dict_continue
--nostringval-- 1974 9 4 %oparray_pop --nostringval--
|Dictionary stack:
| --dict:1267/1684(G)-- --dict:0/20(G)-- --dict:81/200(L)--
--dict:1267/1684(G)--
|Current allocation mode is global
|Current file position is 44643
|GPL Ghostscript 9.20: Unrecoverable error, exit code 1
Downgrading to 9.20~dfsg-3.2+deb9u4 shows the problem is limited to the
latest update:
|% ps2ascii
/build/diffoscope-101~bpo9+1/.pybuild/pythonX.Y_3.5/build/tests/data/test1.ps
|
|
|Today's date: February 28, 2016
|
|1
This also causes diffoscope (both 78 in stretch and whatever is in
stretch-backports at the moment) to FTBFS.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#909694: reprotest: please export DEB_BUILD_OPTIONS=reproducible=+all
On Wed, Sep 26, 2018 at 10:50:30PM +0200, Holger Levsen wrote: > < KGB-1> | Mattia Rizzolo master 4860753 jenkins.debian.net > bin/reproducible_build.sh * https://deb.li/v57l > < KGB-1> reproducible debian: enable all the reproducible-related build flags > from dpkg, by export DEB_BUILD_OPTIONS=reproducible=+all > https://deb.li/3oWVI > [22:44] < h01ger> | mapreri: re: 4860753: shouldt this also be done for > reprotest? > [22:45] <mapreri> | h01ger: possibly indeed yes :) FTR, it looks like reprotest is not exporting any DEB_BUILD_OPTIONS variable currently. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for week 179's blog post
On Sun, Sep 30, 2018 at 12:42:01PM +0100, Chris Lamb wrote:
> Chris Lamb wrote:
>
> > https://reproducible-builds.org/blog/posts/179/?draft
>
> Unfortunately this has not (yet) updated. Apologies for the race condition;
> the version in Git remains the canonical one, however.
(now updated)
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors
On Mon, Oct 08, 2018 at 12:15:36AM +0200, Marek Marczykowski-Górecki wrote: > Filling bugs in web browser is indeed something many people expect. (grumpy person here that don't understand those people…!) > What about providing appropriate "mailto" link to open new issue on BTS, > including all the magic headers, bug template etc? > Like the "reply" one existing already on BTS (I'm using it right now, I > even get quoted message I reply to!). I just added such a link in https://diffoscope.org/ - what do you all think? :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#910652: graphicsmagick-imagemagick-compat: Doesn't ship a compare tool
Package: graphicsmagick-imagemagick-compat
Version: 1.3.30+hg15796-1
X-Debbugs-Cc: diffosc...@packages.debian.org
Dear maintainer,
this package has a Provides:imagemagick, but it doesn't ship a
/usr/bin/compare like imagemagick does; therefore, it's not a full
alternative to it.
I'm adding a Build-Conflicts:graphicsmagick-imagemagick-compat to
diffoscope to prevent resolvers from picking up this package, as it
would cause tests to be skipped.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#911846: diffoscope: test failures in stretch-backports
Source: diffoscope
Version: 104
Severity: minor
Trying to build v104 in stretch-backports, one end up with this test
failure, introduced with the new ocaml comparator.
I just hope we won't need to do something like the haskell comparator,
which test basically never run... :(
=== FAILURES ===
__ test_diff ___
differences = []
@skip_unless_tools_exist('ocamlobjinfo')
def test_diff(differences):
expected_diff = get_data('ocaml_expected_diff')
> assert differences[0].unified_diff == expected_diff
E IndexError: list index out of range
differences = []
expected_diff = '@@ -1,5 +1,14 @@\n Unit name: Uchar\n Interfaces imported:\n
\t84838649f9351de166bfa8b9f2c84db4\tUchar\n \t07ea9e20ae...lib -safe-string
-strict-formats -c uchar.mli\n+Load path: \n+cmt interface digest:
84838649f9351de166bfa8b9f2c84db4\n'
tests/comparators/test_ocaml.py:49: IndexError
__ test_compare_non_existing ___
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f8e93627e80>
cmi1 = <
/builds/reproducible-builds/diffoscope/tests/data/test1.cmi>
@skip_unless_tools_exist('ocamlobjinfo')
def test_compare_non_existing(monkeypatch, cmi1):
> assert_non_existing(monkeypatch, cmi1, has_null_source=False)
cmi1 = <
/builds/reproducible-builds/diffoscope/tests/data/test1.cmi>
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f8e93627e80>
tests/comparators/test_ocaml.py:54:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f8e93627e80>
fixture = <
/builds/reproducible-builds/diffoscope/tests/data/test1.cmi>
has_null_source = False, has_details = True
def assert_non_existing(monkeypatch, fixture, has_null_source=True,
has_details=True):
monkeypatch.setattr(Config(), 'new_file', True)
assert Config().new_file, "didnt get patched"
difference = fixture.compare(MissingFile('/nonexisting', fixture))
assert difference.source2 == '/nonexisting'
> assert not has_details or len(difference.details) > 0
E AssertionError
difference =
fixture= <
/builds/reproducible-builds/diffoscope/tests/data/test1.cmi>
has_details = True
has_null_source = False
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f8e93627e80>
tests/utils/nonexisting.py:32: AssertionError
== 2 failed, 377 passed, 30 skipped in 307.14 seconds ==
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#913315: diffoscope: crash with PyPDF2.utils.PdfReadError with some packages
/diffoscope/comparators/pdf.py", line 70, in dump_pypdf2_metadata for k, v in sorted(pdf.getDocumentInfo().items()): File "/usr/lib/python3/dist-packages/PyPDF2/pdf.py", line 1101, in getDocumentInfo obj = self.trailer['/Info'] File "/usr/lib/python3/dist-packages/PyPDF2/generic.py", line 520, in __getitem__ return dict.__getitem__(self, key).getObject() File "/usr/lib/python3/dist-packages/PyPDF2/generic.py", line 182, in getObject return self.pdf.getObject(self).getObject() File "/usr/lib/python3/dist-packages/PyPDF2/pdf.py", line 1611, in getObject retval = readObject(self.stream, self) File "/usr/lib/python3/dist-packages/PyPDF2/generic.py", line 66, in readObject return DictionaryObject.readFromStream(stream, pdf) File "/usr/lib/python3/dist-packages/PyPDF2/generic.py", line 589, in readFromStream % (utils.hexStr(stream.tell()), key)) PyPDF2.utils.PdfReadError: Multiple definitions in dictionary at byte 0x2c1900 for key /Author -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#903446: diffoscope: libarchive.exception.ArchiveError: Unrecognized archive format (via comparators.debian) with lie/2.2.2+dfsg-3
On Fri, Nov 09, 2018 at 12:04:15PM -0500, Chris Lamb wrote:
> > Sure. Fixed in Git, pending upload:
>
> I have reverted this as it causes regressions in the rlib tests:
I think the most proper thing to do would be to understand why it's not
falling back to hex comparison when libarchive raises its exception?
--
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 `-
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#916353: diffoscope: test failure in alpine
Source: diffoscope
Version: 107
Control: submitter -1 nc...@alpinelinux.org
There is a test that fails in current git:
= test session starts ==
platform linux -- Python 3.6.7, pytest-3.7.4, py-1.5.3, pluggy-0.7.1 --
/usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/ncopa/aports/testing/diffoscope/src/diffoscope-105, inifile:
collecting ... collected 12 items
tests/comparators/test_zip.py::test_identification PASSED[ 8%]
tests/comparators/test_zip.py::test_no_differences PASSED[ 16%]
tests/comparators/test_zip.py::test_metadata PASSED [ 25%]
tests/comparators/test_zip.py::test_compressed_files PASSED [ 33%]
tests/comparators/test_zip.py::test_extra_fields PASSED [ 41%]
tests/comparators/test_zip.py::test_compare_non_existing PASSED [ 50%]
tests/comparators/test_zip.py::test_mozzip_identification PASSED [ 58%]
tests/comparators/test_zip.py::test_mozzip_no_differences PASSED [ 66%]
tests/comparators/test_zip.py::test_mozzip_metadata PASSED [ 75%]
tests/comparators/test_zip.py::test_mozzip_compressed_files FAILED [ 83%]
tests/comparators/test_zip.py::test_mozzip_compare_non_existing PASSED [ 91%]
tests/comparators/test_zip.py::test_encrypted PASSED [100%]
=== FAILURES ===
_ test_mozzip_compressed_files _
mozzip_differences = [,
, ]
@skip_unless_tools_exist('zipinfo')
def test_mozzip_compressed_files(mozzip_differences):
> assert mozzip_differences[1].source1 == 'dir/text'
E AssertionError: assert 'filetype from file(1)' == 'dir/text'
E - filetype from file(1)
E + dir/text
tests/comparators/test_zip.py:106: AssertionError
= 1 failed, 11 passed in 1.41 seconds ======
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#833603: cross-distro
On Wed, Dec 19, 2018 at 05:30:21PM +0100, Bernhard M. Wiedemann wrote:
> One aspect to consider:
> even if you found that all Debian packages do not need a handler
> anymore, there may be other distributions that still needed it.
>
> So please be conservative in what you drop.
I'd propose introducing something to configure at "built time" what
normalizers to disable/enable, coupled with a revert of the change you
mentioned.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#920701: diffoscope: Please document and allow to disable automatic inclusion of dbgsym packages
[03:02:13 PM] 2030 josch: one reason for not removing that feature completely, is that it can be hard to create a .chnages file if all you have are the .debs, and there are good reason for diffoscope to import the debug information while running objdump [03:02:38 PM] 2030 for sure we could at least add a log.info(importing .dbgsym) line though, at least it would be much less surprising ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Hi,
On Tue, Mar 19, 2019 at 04:13:46PM -0400, Chris Lamb wrote:
> > The relevant thing, IMO, is that proposed-updates and point
> > releases still exist for stretch, so I don't see it overkill
>
> Sure. Can you still loop the SRMs in on this before I backport this
> patch and create a stretchpu bug, etc. etc.? Thanks. :)
That kind of things are done by the person doing the update, and from my
experience the release team doesn't really deal nicely with requests
without a working diff, etc.
I will take this on, directly uploading to stretch as I am confident
they will approve it directly.
tbh I totally forgot about stretch itself while fixing that bug…
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Control: tag -1 pending
On Tue, Mar 19, 2019 at 03:29:52PM -0400, Chris Lamb wrote:
> > Ok, but this still should be fixed in stretch, right?
> > (Packages in stretch must build in stretch).
>
> Sure thing, but this would require a stable update which seems a
> little overkill, especially at this point in the buster release cycle…?
>
> Fancy pinging the SRMs on this? Not had to deal with this before.
Cherry-picked the related patches, and uploaded. Also, pu bug opened
for tracking at #925161 .
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Cannot rebuild diffoscope in stretch
Hi Christoph! On Thu, Mar 21, 2019 at 08:57:09AM +0100, Christoph Biedl wrote: > as I've prepared a new version of src:file for a stretch point release > and the changes have been somewhat bigger, I wanted to rebuild the > diffoscope package as additional check for possible regressions. > > Turns out the test suite fails even *before* using the updated file > package. That's a bug, that was reported yesterday and I already uploaded a new version to stable-new, now waiting for SRM. See: bug: https://bugs.debian.org/925051 p-u: https://bugs.debian.org/925161 git: https://salsa.debian.org/reproducible-builds/diffoscope/commits/stretch > After blatantly disabling the test, things got worse: > > __ ERROR at setup of test_obj_identification > ___ > | > | > lambda: specialize(FilesystemFile(filename)) > | ) > | > | filename = > '/<>/.pybuild/pythonX.Y_3.5/build/tests/comparators/../data/test1.o' > | > | tests/comparators/utils/data.py:35: > | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ > | diffoscope/comparators/utils/specialize.py:38: in specialize > | flag = cls.recognizes(file) > | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ > | > | file = < > /<>/.pybuild/pythonX.Y_3.5/build/tests/comparators/../data/test1.o> > | > | @staticmethod > | def recognizes(file): > | if isinstance(file, FilesystemFile) and not > os.path.lexists(file.name): > | > assert Config().new_file, '%s does not exist' % file.name > | E AssertionError: > /<>/.pybuild/pythonX.Y_3.5/build/tests/comparators/../data/test1.o > does not exist > | > | file = < > /<>/.pybuild/pythonX.Y_3.5/build/tests/comparators/../data/test1.o> > | > | diffoscope/comparators/missing_file.py:40: AssertionError > > ... and several more. This is a new one though… :\ I must say that that ENOENT there reminds me of a dpkg-source thing, check debian/source/options. Do you perhaps pass some flags to dpkg-source through ~/.devscripts (in case you use debuild) or ~/.config/dpkg/buildpackage.conf or something else? Somewhere in the archived bugs there should be one about this matter. The problem is that dpkg-source excludes from the tarball the .o files that are used for the test. Could you try rebuilding with the tip of the stretch branch I linked above (the only missing commit is an updated changelog, waiting for SRM to approve the upload). If it still fails, I'd be interested in the full log. For convinience, this is the (unsigned) source package built by me: https://volatile.mapreri.org/2019-03-21/0626fb90b70be4fe0d8c9b7c59d9af16/diffoscope_78+deb9u1.dsc indexing is disabled, but `dget` over that URL should also pull the tarball. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#925613: unblock: strip-nondeterminism/1.1.2-1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Dear RT,
please consider unblocking strip-nondeterminism; the version in unstable
is a minimal thing fixing a single bug. Full diff:
diffstat for strip-nondeterminism-1.1.1 strip-nondeterminism-1.1.2
debian/changelog|8
lib/File/StripNondeterminism.pm |4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff -Nru strip-nondeterminism-1.1.1/debian/changelog
strip-nondeterminism-1.1.2/debian/changelog
--- strip-nondeterminism-1.1.1/debian/changelog 2019-02-13 09:31:59.0
+0100
+++ strip-nondeterminism-1.1.2/debian/changelog 2019-03-12 18:47:40.0
+0100
@@ -1,3 +1,11 @@
+strip-nondeterminism (1.1.2-1) unstable; urgency=medium
+
+ * Call file(1) with the "--" argument placeholder to fix normalisation of
+files starting with a hyphen.
+(Closes: reproducible-builds/strip-nondeterminism#6, #924407)
+
+ -- Chris Lamb Tue, 12 Mar 2019 17:47:40 +
+
strip-nondeterminism (1.1.1-1) unstable; urgency=medium
* dh_strip_nondeterminism: Deduplicate hardlinks via stat(2) to avoid issues
diff -Nru strip-nondeterminism-1.1.1/lib/File/StripNondeterminism.pm
strip-nondeterminism-1.1.2/lib/File/StripNondeterminism.pm
--- strip-nondeterminism-1.1.1/lib/File/StripNondeterminism.pm 2019-02-13
09:29:48.0 +0100
+++ strip-nondeterminism-1.1.2/lib/File/StripNondeterminism.pm 2019-03-12
18:47:00.0 +0100
@@ -25,7 +25,7 @@
our($VERSION, $canonical_time, $clamp_time);
-$VERSION = '1.1.1'; # <https://semver.org/>
+$VERSION = '1.1.2'; # <https://semver.org/>
sub init() {
$ENV{'TZ'} = 'UTC';
@@ -35,7 +35,7 @@
sub _get_file_type($) {
my $file=shift;
open(FILE, '-|') # handle all filenames safely
- || exec('file', $file)
+ || exec('file', '--', $file)
|| die "can't exec file: $!";
my $type=;
close FILE;
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote: > The .buildinfo files are referred to in the .changes files; renaming > them would require updating the .changes file. The .changes files are > used to upload the security updates to ftp-master. With .changes being ephemeral, it feels to me that using them to cross the archive is not really a good solution, and whatever is used to copy packages from one archive to another (is it dak itself?) should instead re-create the upload and re-sign it. Also because that way it would be perfectly able to "upload" all of the sources+binaries from sec-master to ftp-master in a single go, which can't be bad. > ftp-master also has the same problem when uploads end up in policy > queues (the renaming to .buildinfo.N is only done when dak is "done" > with the file and will never touch it again). Also here, it feels to me that once something is accepted into a policy queue, dak should already consider it something controlled by itself, store checksums in the database and be done, not keep the .changes around as a "source of truth" for additional processing, imho. Sure, I understand that things works like that, I'm just showing a few design points that could potentially be done differently. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote: > > Also here, it feels to me that once something is accepted into a policy > > queue, dak should already consider it something controlled by itself, > > store checksums in the database and be done, not keep the .changes > > around as a "source of truth" for additional processing, imho. > > Throwing away .changes doesn't help with .buildinfo name conflicts. It helps in the sense that once the .changes is thrown away, dak would be free to rename the .buildinfo however it likes. > We could also just not accept .buildinfo uploads when they don't contain > useful information about published binaries, that is for source-only > uploads. > > Maybe I should reenable the check for this at least on security-master? > It was rejecting uploads that are okay for unstable/experimental so I > disabled it again the last time. That would indeed be a fine workaround for me, and reduce the load the security team is experience, since it's the team which is the most affect by this. (Incidentally, it also is the same way launchpad works, there you can't upload a .buildinfo for an arch that you aren't uploading, and humans can't upload binaries, so you can't upload .buildinfo for binaries at all). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
what to do with stretch?
Hi,
Today buster is being released, and I think we will do some shuffling to
copy the buster data into the new bullseye shortly after, so we can
start test for that as well.
That begs the question: what do we want to do with stretch?
I think it's not quite useful anymore to keep around, nothing is going
to change anymore there, so I propose to drop it entirely (at most
keeping the suite-wide stats and graphs, for reference).
Do anybody think there is any gain in an "archival" of sorts? In that
case I suppose we could do something to kind of hide the archived suites
from the package pages (as IMHO it's already crowded enough) and keep
everything there, without rebuilding anything anymore)
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#931881: diffoscope: undeclared versioned dependency on file
mh, no. I think some logic needs tweaking, as file is definitely present (it's an hard dependency of diffoscope), and that test should just be skipped. On Thu, Jul 11, 2019 at 11:42 PM Chris Lamb wrote: > Steve Langasek wrote: > > > At the very least, it seems this should be a versioned test dep on file > (>= > > 5.37), but perhaps it should also be a versioned runtime dependency. I > > haven't looked to see what the impact is of the wrong version of 'file' > when > > DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS is not set. > > I think we need to add "file" to the DIFFOSCOPE_TESTS_MISSING_TOOLS > list in debian/tests/pytest. Mattia, can you confirm? > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org 🍥 chris-lamb.co.uk >`- > > -- 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 `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#931881: diffoscope: undeclared versioned dependency on file
On Fri, 12 Jul 2019, 6:09 pm Chris Lamb, wrote: > * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS='' > → Fails; the required version is missing and unlisted. > > * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS="foo bar" > → Fails; the required version is missing and unlisted. > These shouldn't fail. As in, the program is present, but the required version is missing. That variable isn't holding versions after all. At least, having that fail in this case wasn't my intention when I wrote that thing. If you went down that route it would make that variable/setting unusable in any circumstance where simply the required version is missing. Having said all of this, I think we should make the failing test able to run with either of the file versions. `file` keeps changing and breaking our tests, but it would be awful to only support running the testsuite with the latest version available. > > ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Second build of kronosnet fails on i386
On Thu, Jul 25, 2019 at 11:10:51PM -0300, Chris Lamb wrote: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/kronosnet.html > > shows, the first build succeeds, but the second one hits a failure in > > the build time unit tests. This has been rather consistent for several > > uploads. That's not true. The build history clearly shows that it failed rather rarely: https://tests.reproducible-builds.org/debian/history/i386/kronosnet.html > Not 100% sure but I thnk the second build also has a slightly > different networking setup, possibly resulting in a lack of a > localhost interface? I'm just throwing that out there in case the > real, correct answer, rings bells in the minds of others... Not afaik, we don't do any kind of changes to the network setup, and whilst it's true that in the past localhost would not always resolv to 127.0.0.1, I now fixed it in pbuilder itself, so those class of bugs we used to see should not happen anymore. I'm also a bit of a loss as to what might be happening here, so the best I could do right now is to manually schedule another build (for unstable only at this time). Let's see. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Second build of kronosnet fails on i386
[ OT: why do you seem to label the mailing list with the name "Apple"? ] On Fri, Jul 26, 2019 at 03:08:47PM -0300, Chris Lamb wrote: > > whilst it's true that in the past localhost would not always resolv to > > 127.0.0.1, I now fixed it in pbuilder itself > > Ah, that was it? This resolves (get it…?) a nice long-time "mystery" > in my head. Can you elaborate a bit more on the fix, just out of > interest? After some deliberation between pbuilder maintainers, sbuild maintainers, d-policy people, interested 3rd parties, etc, we came to the conclusion that is the chroot's manager job to provide a useful /etc/hosts, i.e. pbuilder's job in this case. https://salsa.debian.org/pbuilder-team/pbuilder/commit/775e8fe1e7c142b14edbd8a19973f03912b548b9 -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Second build of kronosnet fails on i386
On Fri, Jul 26, 2019 at 04:58:00PM -0300, Chris Lamb wrote: > Ah, getcha, so build systems / test were failing to resolve "localhost" > rather than the underlying 127.0.0.1 loopback device being missing or > broken, etc.? Usually, that was it. At least the ones I had a chance to look at. Indeed, if there are still failing weirdly like glibc was, I'd be interested in seeing what else they might be missing. > Clearly, someone, somewhere, and some > time used "Apple" to refer to this list... :> -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Git][qa/jenkins.debian.net] reproducible: vary BUILDDIR for 2nd build so that the path length also
I think the reason we were not varying the length of the build path was because it can generate huge diffs, as it may translate in offsets all over the binaries. I can't imagine any other surprise other than that. On Fri, 9 Aug 2019, 12:22 am Vagrant Cascadian, < vagr...@reproducible-builds.org> wrote: > On 2019-08-08, Holger Levsen wrote: > > I've deployed the following change now. If this causes significantly > > more breakage than before we should probably/maybe revert it again... > > > > On Sun, Aug 04, 2019 at 03:13:56PM +, Vagrant Cascadian wrote: > >> Vagrant Cascadian pushed to branch master at Debian QA / > jenkins.debian.net > >> > >> Commits: > >> 94469490 by Vagrant Cascadian at 2019-08-04T15:13:41Z > >> reproducible: vary BUILDDIR for 2nd build so that the path length also > >> varies. > > Thanks for giving it a try! > > I'm kind of of the opinion *if* we vary build-path at all, we may as > well vary the length; the most obvious use-case for build-path > variations is builds in /home/USER and requiring all usernames to be the > same length is a bit unusual. :) > > But if things explode in surprising ways it can obviously can > revisited. :) > > live well, > vagrant > ___ > Reproducible-builds mailing list > Reproducible-builds@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#934405: debhelper: Please ignore binNMUs in get_source_date_epoch() function
On Mon, Aug 12, 2019 at 03:48:06PM +, Holger Levsen wrote:
> > I think it would be nice if that function ignored binNMU changelog entries.
>
> nope, please dont. using changelog entries inconsistently is a recipe
> for desaster.
Same.
My notes from IRC, so they can last longer:
[09:08:42 PM] comments on #934405 is welcome
[09:08:45 PM] -zwiebelbot- Debian#934405: debhelper: Please ignore binNMUs in
get_source_date_epoch() function - https://bugs.debian.org/934405
[10:53:13 PM] nthykier: well, we used to do that in the past, i.e.
using the previous changelog date. But we switched away because it was also
causing problems: #843773
[10:53:18 PM] -zwiebelbot- Debian#843773: sbuild should use build date as
binnmu changelog date - https://bugs.debian.org/843773
[10:53:45 PM] nthykier: I fear that having debhelper's
get_source_date_epoch() do that, would still lead to the same situation it was
in the past, leading to that same bug once again, just via a different route.
[10:55:06 PM] If I have to express my opinion on this matter, it's a
clear case on why keeping the timestamps within file metadata of generated
files is mostly a horrible idea and should be removed, instead of normalized.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#935684: diffoscope: squashfs-tools output change
On Sun, Aug 25, 2019 at 09:27:33AM +0200, László Böszörményi wrote:
> Recently squashfs-tools changed its output lines. This making
> diffoscope self-test fail without real reason. Please apply the
> attached patch to fix this and let squashfs-tools migrate to testing.
We can't apply that patch, because then the test would fail with an
older squashfs tools.
We usually use the program version or other indicators to decide if our
data is usable with the programs versions, but here I notice that the
change comes from an updated git tarball that doesn't seem to change the
porgram version.
How can we distinguish the previous squashfs-tools with the new one?
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#939387: Please provide a way to rebuild the package with debian/changelog-only changes
On Wed, Sep 04, 2019 at 01:06:50PM +0200, Stéphane Glondu wrote: > When recompiling all packages that use OCaml with OCaml 4.08.0, > diffoscope failed with: > > > debian/rules:16: *** Version in debian/changelog does not match diffoscope > > version. Stop. > > This is because my scripts generate a new changelog entry documenting > the recompilation, with a suffixed version, but otherwise does not > change the source package. OOI, what kind of suffix do you use? > I believe this kind of changes-only-in-debian/changelog should be > supported by all Debian packages. I disagree with this generalization. > Maybe you could relax the version > check so that the version in diffoscope/__init__.py is only a prefix > of the version in debian/changelog? So, the check is: ifneq ($(DEB_DISTRIBUTION),UNRELEASED) ifneq (,$(filter %-backports,$(DEB_DISTRIBUTION))) ifeq ($(DEB_VERSION:~bpo10+1=),$(PY_VERSION)) $(info Building a Debian backport, accepting version mismatch $(PY_VERSION) <-> $(DEB_VERSION)) else $(error Version in debian/changelog does not match diffoscope version or backport policy) endif else $(error Version in debian/changelog does not match diffoscope version) endif endif i.e. if you use UNRELEASED you can use whatever version you want to. I think in the past we did accidentally release with a mismatching version, and I really don't want it to happen again, so I'm somewhat worried about relaxing the check to "just allow all suffixes". That said, it has also been annoying for ubuntu, where every time they have to to do a change they also have to tweak this check (usually it's me so it's not that much of a hassle, but I can see other developers being annoyed at it). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#939386: FTBFS with OCaml 4.08.0 (embeds .cmi in source package)
Control: forwarded -1 https://salsa.debian.org/reproducible-builds/diffoscope/issues/67 On Wed, Sep 04, 2019 at 12:56:24PM +0200, Stéphane Glondu wrote: > The failure is due to a test that inspects a .cmi file that is shipped > by the source package, using the "ocamlobjinfo" command. This cannot > work. > > Indeed there is no compatibility guarantee on .cmi (or any other type > of object files) between different versions of OCaml. And this > incompatibility is what hurts here: the .cmi shipped in the source > package was made with OCaml < 4.08.0. The difference in version can be > seen with the "file" command. > > I have two suggestions: > - Handle gracefully the case where ocamlobjinfo rejects an object file > because it was not compiled with the same version of OCaml. We should indeed do this, like we do for haskell. > - Instead of shipping a .cmi file in the source package, generate one > at build time. That's https://salsa.debian.org/reproducible-builds/diffoscope/issues/66 and it's somewhat tricky (as the built files have to have the difference we expect them to). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#939387: Please provide a way to rebuild the package with debian/changelog-only changes
On Fri, Sep 06, 2019 at 09:52:40PM +0100, Chris Lamb wrote: > > I would suggest to compare only the first part (upstream > > version/major version/whatever). > > FYI I had to do something similar recently in src:xtrlock: > > > https://salsa.debian.org/debian/xtrlock/commit/eb0b4174c81fdb1b81926203af3bb8c7c34fdac9 > > Mattia, fancy implementing this? I believe you wrote the current > version check code. i.e. just making sure the d/changelog version starts with the same string in diffoscope/__init__.py? Indeed, after thinking for a day I guess it's safe enough. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#939387: Please provide a way to rebuild the package with debian/changelog-only changes
On Thu, Sep 05, 2019 at 10:56:23AM +, Holger Levsen wrote: > On Thu, Sep 05, 2019 at 10:07:26AM +0200, Stéphane Glondu wrote: > > I see this is a native package. Why don't you use the version in > > debian/changelog to generate diffoscope/__init__.py? If this was not a > > native package, or if the version number would otherwise naturally split > > in two parts, I would suggest to compare only the first part (upstream > > version/major version/whatever). > > this matches my notion that native packages cause more harm than good. > IMHO we should make diffoscope non-native. strip-nd is non-native, and in my experience is so much of a pain to do a new upstream release that I really don't want to do them anymore... Compared to that, this one issue with diffoscope is such a triviality that I can't even start compare them. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Heads-up: New upstream version of src:file in experimental
Hi,
On Fri, Dec 27, 2019 at 11:40:57AM +0100, Christoph Biedl wrote:
> A re-build showed no errors
Perfect. Then it's most likely fine. If we really want to do the next
step it would be to run autopkgtest, which runs just a couple more tests
iirc, but just rebuilding is good enough for me.
> - but has the build-dependency list of
> diffoscope always been that huge?
well… it just keeps growing with each file type we add support for. All
those packages are only needed to run the tests, look at the list of
"nocheck" build profiles… :)
> My plan is to upload to unstable in a week from now.
Thank you for the heads up!
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
notes repository shared with all DDs
Hi,
I just shared the notes repository¹ with the "Debian" group, therefore
giving all DDs write access to it.
It's my attempt to invite more direct contributions instead of MRs :)
¹ https://salsa.debian.org/reproducible-builds/reproducible-notes
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Request for help to make mariadb-10.3 in Debian reproducible
On Sun, Jan 19, 2020 at 11:57:05PM -, Chris Lamb wrote: > (Or, as a different place to start, Mattia might be able to remind me > how to instruct the build rescheduler to retain the build artifacts? > I can't seem to remember how...) it's an &keep-artifacts in the querystring of the scheduling cgi-bin. Having said that, I triggered a build for mariadb-10.3 for bullseye/amd64 that (assuming no bugs since I don't think this feature hasn't been used for a while!) should preserve artifacts. bullseye so that build path change doesn't influence the build, for an easier start. And thank you for taking up on Otto's request! :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Request for help to make mariadb-10.3 in Debian reproducible
here, please download them today, as they will then be deleted: https://tests.reproducible-builds.org/debian/artifacts/r00t-me/mariadb-10.3_bullseye_amd64_tmp-bRl4s/ On Mon, Jan 20, 2020 at 12:40 PM Mattia Rizzolo wrote: > On Sun, Jan 19, 2020 at 11:57:05PM -, Chris Lamb wrote: > > (Or, as a different place to start, Mattia might be able to remind me > > how to instruct the build rescheduler to retain the build artifacts? > > I can't seem to remember how...) > > it's an > &keep-artifacts > in the querystring of the scheduling cgi-bin. > > Having said that, I triggered a build for mariadb-10.3 for > bullseye/amd64 that (assuming no bugs since I don't think this feature > hasn't been used for a while!) should preserve artifacts. bullseye so > that build path change doesn't influence the build, for an easier start. > > And thank you for taking up on Otto's request! :) > > -- > 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 `- > -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#954991: ruby-zoom: Multi-arch conflict with zoom-0.5.0.gemspec
Control: severity -1 important
On Thu, Mar 26, 2020 at 10:54:15PM +1100, Hugh McMaster wrote:
> ruby-zoom conflicts on /usr/share/rubygems-
> integration/2.7.0/specifications/zoom-0.5.0.gemspec on mipsel <-> amd64,
> arm64,
> armel, and five more arches.
>
> A diff of arch packages shows that the zoom-0.5.0.gemspec file contains a
> timestamp that varies depending on when the source package was built.
This is something that stems from a "recent" sbuild change (#843773) -
that likely makes gem2deb use a binNMU date in the gemspec, which likely
varies between architectures.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Storing build logs outside of .deb packages
On Sun, May 31, 2020 at 02:49:46PM -0700, Vagrant Cascadian wrote: > On 2020-05-17, Paul Wise wrote: > > On Sat, 2020-05-16 at 22:58 +, Chris Lamb wrote: > >> My gut feeling is that this is the avenue we want to explore. Having a > >> separate mechanism to capture this build-specific metadata would be an > >> elegant solution and, as you imply, having the logs would have QA > >> advantages as well as permit reproducible builds. The system could be > >> generic enough for future use-cases that we cannot envisage too. > > > > Agreed that this is the best option. In order to standardise the > > naming, structure and organisation of the data in order to make it work > > across all Debian derivatives, probably a new conversation needs to be > > started between ftp-master and the dpkg maintainer. > > > >> We have taken great pains over the years that no special knowledge, > >> tools or tricks are required to compare the artifacts of a Debian > >> build with respect to reproducibility. > > > I'm guessing you just ignore all differences in buildinfo files and > > would have to add to that ignoring differences between build logs and > > other build metadata? > > That sounds likely, yes. I know this has been linked in multiple places, but I'll link it again: https://bugs.launchpad.net/launchpad/+bug/1845159 there has also been a relevant thread in debian-devel a few months back, spawned off the debian/.build thread started by Niels Thykier. I'm not quite clear what's the best way forward: I could go and implement whatever feels best to me in pbuilder, and then hope the rest of the tooling with catch up, copy my idea and adapt, but that feels unlikely… -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Storing build logs outside of .deb packages
On Mon, Jun 01, 2020 at 09:40:19PM +0800, Paul Wise wrote:
> Re-reading the above thread, I now think that debhelper/dpkg-dev is the
> wrong layer to be implementing this and that we want it in the hooks or
> config for the build system in use; launchpad, sbuild, pbuilder etc.
>
[…]
>
> So, I would suggest buildd.d.o folks and launchpad folks would be the
> maintainers of the rules about artefacts to preserve and that the
> artefacts be published in the same place as the build logs. Probably
> for Debian, DSA would need to add to the buildd puppet module a way for
> the buildd admins to specify a set of globs for files to preserve.
But so, do you think the first step lies in pbuilder/sbuild to decide an
interface for the package maintainers to use, or for the buildd managers
(wanna-build/buildd and launchpad) to decide on an interface that
sbuild needs to provide (and I would guess pbuilder will try to copy it
for consistency).
In the first case, it would mean me and Josh needs to think about
something, probably including Neils in case debhelper can help
maintainers do stuff (this is the reason I thought that the whole
debian/.build thing was a good idea).
I know I tried to catch Josh attention via IRC in the past, but he was
also basically lost on how to tackle this matter.
In the latter case, it would basically mean that Aurelien and Colin
needs to think together instead.
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Help with FTBFS polybar (builds fine on salsa-ci)
On Sun, Jun 07, 2020 at 03:34:12PM -0700, Vagrant Cascadian wrote: > On 2020-06-07, Samuel Henrique wrote: > > Polybar currently FTBFS on tests.reproducible-builds.org because of a > > timeout[0] while it builds without an issue on buildd[1] and > > salsa-ci[2]. > > More accurately, it Fails to Build Reproducibly; both builds typically > succeed do succeed, although diffoscope times out pretty consistantly: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/polybar.html > > > > Its builds are quite CPU Intensive but I believe there might be > > something wrong going on as a timeout seems like too much. > > Oh, the > diffoscope timeout is 120m ... so that would more-or-less explain it why > the "build" takes 2+ hours... indeed, the "builds" by themselves are usually taking ~10 minutes each (except on armhf), plus 2 hours of diffoscope which is the one step that timeouts. > Though I built polybar using reprotest, and it completed in ~22minutes, > including two builds and running diffoscope. > > > > I would like to clear this issue out before continuing with debugging > > the lack of reproducibility[3]. > > The diffoscope output from my test with reprotest: > > https://people.debian.org/~vagrant/reproducible/polybar.diffoscope.out.gz One thing you should consider: the build path length is varied nowadays. This means it can very easily cause shifts in the compiled binaries even after stripping (see the very recent bug open against debhelper to avoid saving RPATH when using cmake). Such thing won't happen during regular rebuilds, as the build path lenght is usually the same even when slighly different, and as such it's quite easier to diffoscope to build up the diff. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Help with FTBFS polybar (builds fine on salsa-ci)
On Tue, Jun 09, 2020 at 11:32:31PM +0100, Samuel Henrique wrote: > > The diff seems to be mostly made of entries like this (diff from a > > build with DEB_BUILD_MAINT_OPTIONS = reproducible=+fixfilepath [branch > > debian/samueloph/reproducible2]): > > │ │ │ │ - 250e36:48 8d 3d e0 b5 00 00 lea0xb5e0(%rip),%rdi > > │ │ │ │ + 250e36:48 8d 3d e8 b5 00 00 lea0xb5e8(%rip),%rdi > […] > This would cause a diff in ELF's .rodata, which in turn would cause a > shift in a bunch of .text assembly calls. This is exactly what I was hinting at in my previous mail. The shift there is of 8 bits, which just so happen to be the extra lenght of the second build (it has an extra '2/'). If it was embedding the path in many more places there would be many extra shifts as well, there being only 8 bits is probably an indicator that is saved only once, wherever that is. > After the fix, the only diff we have is from "NT_GNU_BUILD_ID" and > ".gnu_debuglink" which seems like a known issue[1] and I don't think > there's anything I can do. Are you diffing also the dbgsym? From my experience, I'd say pretty much all of those instanes are also cases where the build path is saved somehow, even if later stripped. > I just uploaded 3.4.3-2 with the fixes, so this means the diffoscope > timeouts won't happen anymore for this package, though the issue will > still be there and it might affect other packages. sigh, apparently it still timeouts :( -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#969084: buildd.d.o: please don't use a tainted buildenv
On Mon, Aug 31, 2020 at 02:44:12PM +, Holger Levsen wrote: > On Thu, Aug 27, 2020 at 04:25:56PM +0200, Guillem Jover wrote: > > I think ideally > > this would be using a system pathname and be part of a package that gets > > then listed in the .buildinfo files. > > I cannot comment on this except to say that I'd wish for some more pragmatism > :( It's not something that I run myself, but I believe https://tracker.debian.org/pkg/policy-rcd-declarative is a good solution to this: install that package, then instead of dropping that file into /usr/local/sbin/policy-rc.d, do echo ".* .* deny" > /etc/service-policy.d/00-buildd-deny-all That turns a non-dpkg tracked binary into a non-dpkg tracked conffile, which I suppose it's a good compromise. Improvement would be to ship that single conffile in a separate package (which, IMHO, src:policy-rcd-declarative could do, i.e. provide a "policy-rcd-declarative-deny-all" binary; or do fancy things with a debconf option sbuild-craetechroot could inject but that would be too dirty for me). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#969084: buildd.d.o: please don't use a tainted buildenv
On Wed, Sep 09, 2020 at 11:01:01AM +0200, Aurelien Jarno wrote: > Well I would say that we have a solution but not yet the patch, but > anyway I'll plan to work on writing a patch in the next days. Oh, great! thank you for being so quick! > > > Improvement would be to ship > > > that single conffile in a separate package (which, IMHO, > > > src:policy-rcd-declarative could do, i.e. provide a > > > "policy-rcd-declarative-deny-all" binary; or do fancy things with a > > > debconf option sbuild-createchroot could inject but that would be too > > > dirty for me). > > > > I'm tempted to clone this bug and make the clone a wishlist bug for such > > a "policy-rcd-declarative-deny-all" binary. What do you think? > > Indeed, that would be awesome. I opened a new bug instead, to give the policy-rcd-declarative maintainer some context without being shoved a bugload of comments ^^ https://bugs.debian.org/970027 -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#969084: buildd.d.o: please don't use a tainted buildenv
On Thu, Sep 10, 2020 at 02:14:57PM +0200, Aurelien Jarno wrote: > On 2020-09-10 11:58, Holger Levsen wrote: > > Hi, > > > > On Thu, Sep 10, 2020 at 01:45:31PM +0200, Mattia Rizzolo wrote: > > > On Wed, Sep 09, 2020 at 11:01:01AM +0200, Aurelien Jarno wrote: > > > > Well I would say that we have a solution but not yet the patch, but > > > > anyway I'll plan to work on writing a patch in the next days. > > > Oh, great! > > > thank you for being so quick! > > > > indeed, thank you very much Aurelien! > > > > fwiw, I also think it's fine to only have this for new > > unstable/bullseye/bookworm/... builds. > > policy-rcd-declarative is used for bullseye and sid chroots. We do not > have bookworm chroots yet ;-) do buildds use the sid chroots for experimental builds? -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: scribus: status change on tests.reproducible-builds.org/debian
Hi, that's not possible for us to do, as there might be *many* ways for you to have subscribed. Since you received this notication, most likely you subscribed to the "scribus" package either on the former PTS at packages.qa.debian.org, or in the newer tracker at tracker.debian.org. Nowadays tracker handles mails for both. After confirming that you indeed have an active subscription on tracker.d.o, I triggered a unsubscribe command for you. You should have received a confirmation mail with instruction on how to to finalize the unsub. On Thu, Nov 19, 2020 at 07:26:02AM -0500, Garry W. Johnson wrote: > Thanks guys for maintaining the auto notifications. I signed up for this a > couple years back when I was determined to learn Debian Linux. > Unfortunately that never happened, and I have no idea what any of this is > talking about. Please pull me from the email list when you have time. Sorry > for the inconvenience. > > On Wed, Nov 18, 2020 at 7:50 PM Reproducible Builds folks < > reproducible-bui...@lists.alioth.debian.org> wrote: > > > Dear maintainer, > > > > The reproducibility status of the package scribus changed during the > > continuous testing. > > See the following notes for more details: > > > > 2020-11-18 07:24 > > https://tests.reproducible-builds.org/debian/unstable/armhf/scribus > > changed from reproducible -> timeout > > > > Feel free to reply to this email if you have questions regarding > > this automatic notification. > > > > -- > > The Reproducible Builds folks > > > > > -- > Best Regards, > > Garry > > Facebook <https://www.facebook.com/garry.johnson.75054689> > Covenant Concepts <https://covenantconcepts.org/> > ___ > Reproducible-builds mailing list > Reproducible-builds@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#975261: diffoscope: install footprint is 2.6GB, please move some recommends to suggests
On Fri, Nov 20, 2020 at 09:31:55AM +, Holger Levsen wrote: > On Thu, Nov 19, 2020 at 06:35:11PM +, Ximin Luo wrote: > > I have managed to figure out that by moving the following Recommends to > > Suggests one can cut the footprint from 2.6GB to about 64MB which is much > > more > > reasonable. Therefore please do that. These are ordered roughly by size: > > maybe this can be solved by having two (or three) diffoscope packages: I agree, I don't want to need to use apt-get --install-suggests when installing diffoscope; even more because that's likely to fail due to random suggests conflicting or non existing or whatnot. And it would lead to even bigger installation size. > - diffoscope-full with the packages as recommends I reckon this "type" should stay named "diffoscope", what it currently is. So current users still get what they currently get. > - diffoscope-basic with the packages as suggests only ack. > - diffoscope-core with just diffoscope, which is the package the above two > depend on ack. If others (especially Crhis, since it's him doing most of diffoscope work nowadays) agree, I can take care of doing the needing packaging changes. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Comments regarding diffoscope_162_amd64.changes
On Mon, Nov 30, 2020 at 04:42:55PM +, Paul Richards Tagliamonte wrote:
> The following are some notes I'm passing along from one of our hardworking
> trainees. These comments should be addressed when able, but not worth a REJECT
> over. Thank you for maintianing diffoscope!
Thank you for your comments!
We'll get it sorted soon! For tracking porpuses, I copied your mail
here:
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/224
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: reproducible builds Debian usertags?
Hi Paul! On Sun, Dec 06, 2020 at 06:14:13PM +0800, Paul Wise wrote: > As part of my efforts to do some QA on Debian usertags, I noticed a few > typos and other issues with the reproducible builds Debian usertags, > which I fixed using a script and the attached commands to the bts bot. > > https://salsa.debian.org/pabs/qa/-/compare?from=master&to=usertags Thank you for doing so! > I also noticed that the index of bugs is missing several usertags, I've > included below the missing usertags and bugs/counts for each of them. > > https://tests.reproducible-builds.org/debian/index_bugs.html Note that the formal explenation for those usertags is at https://reproducible-builds.org/contribute/#how-to-report-bugs-in-debian and https://wiki.debian.org/ReproducibleBuilds/UserCategory (though I'm not sure anymore if they are properly in sync, plus the latter is not linked anywhere) >padding 1: #881231 >ASLR 1: #881231 >permissions 1: #858333 >ordering 2: #825406 #835263 >kernel 5: #849968 #858152 #884256 #970130 #976071 >timezones 1: #831583 >timezone 11: #834537 #835143 #840847 #841532 #841784 #843469 #855909 > #872460 #968627 #974911 #976359 > > It seems to me that: > > * ASLR tag should be removed since the bug is about padding/randomness > * padding bug should maybe be removed in favour of randomness? depends on what that padding is about. If it's due to different lenght of the build paths, then it should be "buildpath", IMHO. > * permissions bug should either stay or maybe move to umask? umask it is. > * timezones bugs should move to timezone not quite, see below. > * ordering bugs should move to fileordering well, depends. fileordering is specifically about readdir(). if it's, say, perl hashes not being ordered, that would be randomeness. > * the kernel and timezone bugs should become official not quite IMHO. "kernel" is already tracked under "uname", whereas "timezone" likely falls into "timestamps" > PS: the typo or other fixes can be done by the usertags-fixes cron job > automatically if wanted, for now I elected to do them just the once, > but if they recur then I will notice them via another cron job. I believe that some of the type you found is safe to fix, but in your proposal control@ mail I notice an oddity. > user reproducible-bui...@lists.alioth.debian.org > usertags 848136 - fileorder > usertags 848136 + fileordering > usertags 872729 - filesystemordering > usertags 875700 - filesystemordering > usertags 875704 - filesystemordering > usertags 872729 + filesystem > usertags 875700 + filesystem > usertags 875704 + filesystem > thanks these should all be "fileordering", the later "filesystem" is bogus. did you find it somewhere? All the others are good to be pushed from what I see, thank you! -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: maintaining reproducible-notes over the long term
On Fri, Dec 18, 2020 at 12:53:53PM +, Holger Levsen wrote: > > yet also see value in keeping history a little easier to > > reach than grepping through git logs. > > right. > > you also said on irc: > > "please wait at least until packages are verified as reproducible in > bullseye on all architectures before removing them from > reproducible-notes ... there are some packages which have intermitant > reproducibility issues" > > which AIUI can be solved by adjusting the scripts Mattia is running > in cron. The thing is, the script removes archived bugs and issues that are not reproduced anymore and marked as "deterministic" in issues.yml. I read over the diff after that's done and manually remove notes for packages that I confirm are indeed fixed (mostly, because the changelog says it fixed those issues indeed) and which comments just describe what the problem used to be. Having the script blindly remove the "comment" section would be dangerous, as that could easily accidentally remove stuff that was meant to be preserved. Vagrant: did you perhaps notice that I (manually or automatically?) removed notes for stuff that indeed shouldn't have been removed? > I just don't remember where exactly they live... Mattia? That's `clean-notes` in reproducible-misc.git :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: maintaining reproducible-notes over the long term
On Fri, Dec 18, 2020 at 09:13:21AM -0800, Vagrant Cascadian wrote: > Ok. It was unclear to me which parts were automated and which parts were > manual. Oh, that's very clear. The automated ones are done at midnight UTC and the commit author says "automatic commit from ..". Everything else is me doing it by hand! ;) > > Vagrant: did you perhaps notice that I (manually or automatically?) > > removed notes for stuff that indeed shouldn't have been removed? > > Maybe these all fall into the categories you're saying (although dynare > isn't reproducible on arm64, due to non-deterministic issues), although > since they haven't propegated to bullseye yet, I would think it would be > good to leave them open till the bugs are archived, or at least verified > fixed in bullseye? As I mentioned, it's mostly about the comments that I'm acting upon. Those won't ever be removed manually, so if I see that recent upload addresses whatever is written in the comments, plus I don't spot anything else within the note that is not addressed I go ahead and remove everything. Why do you believe waiting for the testing migration is useful here? I can't imagine a package reproducible in unstable but not in testing, where we are changing _less_ stuff. > e6adafa12eb7a9f0a9e4d79a4db7b468a5725d50 > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dynare.html right, but then again, the nondetermism there is not related to what was written in the note, is it? One of the reason I remove those notes is that in case of unreproducible packages they pop up in the "without notes" section(s), i.e. https://tests.reproducible-builds.org/debian/unstable/amd64/index_no_notes.html - instead of being drowned in (for example) https://tests.reproducible-builds.org/debian/unstable/amd64/index_notes.html > 4ecce9d22a41868b4d0ba2c81e0d25fe81838a2c > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bowtie2.html > > a50358f1fe94ea5d2d62b57a716a3a120ef6aacd > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cctools.html these should be fine, did I drop anything that is not by now "obsolete"? > Or maybe just had different expectations without the background of when > some of these decisions were made. :) That might be so, but I'm very much willing to adapt what I do to much your expectations. If you believe I am losing data let's try to figure a way to help me figure it out so that I won't do that anymore, while at the same time try to somehow keep the notes a tad tidier :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: maintaining reproducible-notes over the long term
On Sat, Dec 26, 2020 at 01:21:10PM -0800, Vagrant Cascadian wrote: > Another recent automated "--fix-deterministic" that surprised me: > > 327711ca32fb51df6580f0bbeb8c7d8f2501af90 > > At the time --fix-deterministic removed it, there were only 404 builds > for both amd64 and arm64 in unstable, and only builds of the previous > version where the issue was not fixed for i386 and armhf in unstable. _that_ is a bug. --fix-deterministic comes from misc.git's `edit-notes`, and I noticed it in the past as well. `--fix-deterministic` just considers the issue gone if the status turns "reproducible", but it seems that when the status is 404 for some reason it goes and mark that as good too. I haven't looked down as to why that happens. Incidentally, the notes were never made "architecture-aware", so many scripts dealing with the notes (not just clean-notes and edit-notes) hardcode "amd64" and look only at that (indeed the note pages do say "Our notes […] are targeted at packages in Debian in 'unstable/amd64' (unless they say otherwise)."). -- 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 `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote: > Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a > ecrit: > > # __FILE__ is a public, well defined API > > ? My copy of C11 says > > “ > __FILE__ The presumed name of the current source file (a character string > literal) > ” > > that's not so well-defined. I would not expect it to necessarily > contain the path to it. In fact, empirically I've seen that __FILE__ is expanded to whatever path gets passed to the compiler. You can easily see how stuff build with cmake get a full path in there, whereas stuff built with make gets a path relative to the Makefile. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#988964: please demote diffoscope to Recommends
On Fri, May 21, 2021 at 05:33:42PM -0700, Vagrant Cascadian wrote: > > Yes, just confirmed that it gets added through python3:Depends. > > > > So, I presume it will require mangling python3:Depends, or adjusting the > > code to convince the pybuild/dh_python/etc that it doesn't belong there. > > diffoscope is in install_requires, removing it gets it out of > python3:Depends, but may have other unintended consequences: Yes, currently diffoscope is run unconditionally unless --no-diffoscope is passed. which means that it need to learn to check before running it :) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Request for help] Making brian reproducible
On Tue, Jun 08, 2021 at 04:09:26PM +0530, Nilesh Patra wrote: > Hi Vagrant, > > On 6/8/21 3:40 AM, Vagrant Cascadian wrote: > > On 2021-06-08, Nilesh Patra wrote: > >> I was trying to make "brian" package reproducible. To my understanding it > >> has two problems: > >> > >> * use datetime.date.today() and similar stuff for build documentation - I > >> suppose I fixed these with using SOURCE_DATE_EPOCH > > > > Your fixes look reasonable; just be sure the way you're passing the time > > is independent of timezone (it might be fine as is). > > Sure Incidentally, instead of using SOURCE_DATE_EPOCH, please also double check if you couldn't just get rid of the timestamp at all. In my experience most timestamps are just useless and don't really provide anything valuable, so it's better to just get rid of them altogether. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope (and strip-nd) for bullseye
On Tue, Jun 08, 2021 at 09:06:07AM +, Holger Levsen wrote: > > > strip-nondeterminism OTOH has been in unstable for 32 days but won't > > > migrate on it's own because it doesn't have an autopkgtest. Looking at > > > the diff > > > to the version in sid, I'm not sure whether it warrants an unblock > > > request. > > I agree. Shall we return to this question if/when an issue that would > > warrant an unblock request comes up? > > yeah. "when/if"! :) Just to note that even with an autopkgtest it would need an explicit unblock as it's a key package (being in the pseudo-build-essential set). -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#991059: diffoscope: subprocess.CalledProcessError: Command unsquashfs... returned non-zero exit status 1
On Wed, Jul 14, 2021 at 08:31:48PM +0200, Roland Clobus wrote: > I'm planning to change the Jenkins job, such that the files that cause > diffoscope to crash will be published. Each file is 2.6GB. In this case, please have a look at reproducible_build.sh that already does something similar. you might want to consider moving the relevant function to _common.sh and call it wherever else you need it. > The difference between these two files is located inside a squashfs > file, which is inside the iso file. > During the invocation of diffoscope, diffoscope needs lots of memory > (>32GB) and free space on /tmp (>32GB but <48GB). Sigh, that's huge. :( > In the mean time, the timeout of 30 minutes in Jenkins has been raised > to 120 minutes, but that still does not fix the crash. … > I've attempted to reproduce the ISO files (using an older snapshot) on > my own comupter, but there diffoscope was able to run until the end, > even though it needed 105 minutes wall time... 105 in an idle system probably means that it would need 3/4 hours on jenkins. 120 totally won't fit. (BTW, this doesn't change that diffoscope shouldn't crash, just the timeout wrapper exiting.) -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: testing of bookworm has begon
On Tue, Aug 17, 2021 at 10:18:22AM +, Holger Levsen wrote:
> jenkins.debian.net master 1c5b2ef Holger Levsen TODO
> bin/reproducible_scheduler.py * reproducible Debian: start scheduling tests
> for bookworm * https://deb.li/3U8D4
>
> It will take some more hours until the first bookworm packages will be tested,
> due to the way scheduling etc works. Then, at least the dashboard will still
> miss the bookworm graphs... IOW: expect some things to be bumpy for the
> upcoming
> days and please do point out problems here, so we are aware and can address
> them.
Thank you for handling the addition of bookworm!
Hopefully it was easy enough to follow what we did last time with
buster.
Shall we officially drop stretch now? (perhaps move them to some r/o
place, or drop the completely?)
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: archive wide rebuild with "-DCMAKE_SKIP_RPATH=ON"?
On Thu, Aug 12, 2021 at 03:35:05PM +0200, Niels Thykier wrote: > > On 2021-08-10 Holger Levsen > public.gmane.org> wrote: > >> [...] > > > > Hello, > > > > Isn't CMAKE_SKIP_RPATH a rather strange choice, what are the expected > > benefits over CMAKE_SKIP_INSTALL_RPATH? There is potential for breaking > > testsuites. > > > > Doesn't this break packages that intentionally use rpath for private > > shared libraries? > > > > cu Andreas > > Hi Andreas, > > The CMAKE_SKIP_RPATH was recommended in #962474 > (https://bugs.debian.org/962474) to improve reproducibility by default. > The bug contains the rationale for that option and explains the > underlying issue (plus links to the upstream bug tracker where that > topic was also discussed). Indeed, -DCMAKE_SKIP_RPATH=ON for me broke things in src:lib2geom: https://salsa.debian.org/multimedia-team/lib2geom/-/commit/f8a4c06edbd64d4c77d69ef3aea93e978a7156e4 this is just an example, and I expect plenty of breakages. May I recommend we do *not* enable this on the r-b builders, as I'm positive it would break quite a few things here and there. Rather, it would be perfect for aws' comparative rebuilds. Now, who is the contact for those these days? -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: archive wide rebuild with "-DCMAKE_SKIP_RPATH=ON"?
On Fri, Aug 20, 2021 at 03:06:55PM +0100, Chris Lamb wrote: > Hi Lucas et al., > > > yes, to do a comparative rebuild, I just need such a script that adjusts > > the build environment to whatever is needed. See other examples in > > https://salsa.debian.org/lucas/collab-qa-tools/-/tree/master/modes > > For reference, the relevant part of debhelper's cmake.pm is: > > push(@flags, "-DCMAKE_SKIP_RPATH=ON", > '-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON') if not compat(13); > > Two quick questions arising from this: > > 1. Am I right in thinking we take out the "if not compat(13)" >conditional as part of this experiment? > > 2. Would the best way of introducing this be a custom rebuild of the >src:debhelper package, similar to the way, for example, boost was >tested earlier this year [0]? (I suspect this is the case if >customisation script is run before installation of packages, >otherwise we could simply sed the relevant file, similar to how we >tested fixfilepath [1] where we could rely on dpkg being installed.) I've just filed https://salsa.debian.org/lucas/collab-qa-tools/-/merge_requests/12 with a script that, as I expect, should be enough to run this test. It's similar in spirit on how vagrant run the last test rebuild, `sed`ing a "live" file instead of providing a patched package, as I understand that's a good enough way to do it. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#992694: reprotest: kernel variation makes ldconfig abort with message "FATAL: Kernel too old"
On Sun, Aug 22, 2021 at 03:03:14PM +0200, Baptiste Beauplat wrote: > While trying to debug > https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/191, I found > out that the kernel variation makes ldconfig abort with the following > message: "FATAL: Kernel too old" > This behavour is partially documented in the manpage under: > > ``` > Kernel > -- > > The "kernel" variation is currently not working for RPM based packages. > While building with this variation enabled, the tool > `/usr/lib/rpm/redhat/brp-ldconfig` > compains about `FATAL: kernel too old` and aborts the build. > ``` > > However all version of ldconfig (at least since 2017) require a kernel > 3.2, not just the RPM ldconfig. > > I think the documentation should be updated to warn users about ldconfig > not working in all cases. What would you say about this patch: |--- a/README.rst |+++ b/README.rst |@@ -378,9 +378,9 @@ mechanism to vary the system time. | Kernel | -- | |-The "kernel" variation is currently not working for RPM based packages. While |-building with this variation enabled, the tool `/usr/lib/rpm/redhat/brp-ldconfig` |-compains about `FATAL: kernel too old` and aborts the build. |+The "kernel" variation is currently not working for RPM based packages and other |+build process requiring `ldconfig`. While building with this variation enabled, |+`ldconfig` complains about `FATAL: kernel too old` and aborts the build. | | Avoid sudo(1) password prompts | == Besides potentially better identifying which versions of ldconfig are effectively broken, I don't think we could do much else. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Help with Mroonga to finally get all of MariaDB Server reproducible
On Tue, Oct 12, 2021 at 09:53:53AM +0100, Chris Lamb wrote: > > In https://github.com/mroonga/mroonga/issues/298 you wrote: > >> You could also build with > >> DEB_BUILD_OPTIONS=reproducible=-fixfilepath,+fixdebugpath and then > >> it might actually show the embedded build paths > > > > This is the next step I should do to debug. However I don't understand > > the context here. DEB_BUILD_OPTIONS is something one gives to the > > build, but I don't build reproducible builds locally but only upload > > the source code. Only place I do anything is in debian/rules where it > > is _read_ but never set. > > I believe that, from your point of view, "build with > DEB_BUILD_OPTIONS" refers to setting this variable in debian/rules and > then uploading the [source] package as before. For example: > > export DEB_BUILD_OPTIONS=reproducible=-fixfilepath,+fixdebugpath > > This environment variable will affect the workings and output of > dpkg-buildflags(1), setting different compiler flags where needed. But that's not appropriate either. ;) One should never *set* DEB_BUILD_OPTIONS in d/rules. Instead, they should set DEB_BUILD_MAINT_OPTIONS, which (according to dpkg-buildflags(1)) overrides DEB_BUILD_OPTIONS by also merging its non-conflicting values. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#995928: acorn: doc directory shipped by both binaries
Hi release team, concerning this bug, I'd like to hear advice from you on how you'd best like to see this fixed in stable. The current bug causes trouble for reproducible builds operations (basically, it throws away all build involving node-acorn in bullseye). See the last paragraph on my thoughts about the potential solutions; I'm happy to implement what you think would be best. On Fri, Oct 08, 2021 at 12:07:36PM +0200, Mattia Rizzolo wrote: > Source: acorn > Version: 8.0.5+ds+~cs19.19.27-3 > Severity: serious > Control: fixed -1 8.5.0+ds+~cs23.9.6-2 > > This happens in bullseye: > > root@warren:/# apt install node-acorn > ... > The following NEW packages will be installed: > libbrotli1 libc-ares2 libicu67 libnghttp2-14 libnode72 libuv1 node-acorn > node-debbundle-acorn node-xtend nodejs > ... > root@warren:/# apt install --reinstall node-debbundle-acorn > ... > (Reading database ... 12963 files and directories currently installed.) > Preparing to unpack .../node-debbundle-acorn_8.0.5+ds+~cs19.19.27-3_all.deb > ... > Unpacking node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) over > (8.0.5+ds+~cs19.19.27-3) ... > (Noting disappearance of node-acorn, which has been completely replaced.) > Setting up node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) ... > The following package disappeared from your system as > all files have been overwritten by other packages: > node-acorn > Note: This is done automatically and on purpose by dpkg. > > > This is due to node-acorn shipping /usr/share/doc/node-acorn (type: > symlink) which is *also* shipping by node-debbundle-acorn (type: > directory). > dpkg seems to always overwrite the symlink anyway, but it doesn't detect > that it's gone until later when reinstalling it. > > > To be honest, I'm not sure what was the wanted situation, but I *think* > the symlink is just wrong. Looking at the content of the > /usr/share/doc/node-acorn/ directory as present in node-debbundle-acorn, > I think that is the appropriate content. So, probably, the best fix is > to just get rid of the symlink from node-acorn, however that would leave > the package totally empty, which dpkg is not totally thrilled about. > So more likely at least the 2 symlinks of copyright and > changelog.Debian.gz in /usr/share/doc/node-acorn could be moved from > node-debbundle-acorn to node-acorn, so effectively shipping the > directory from both packages. > > > > This is fixed in 8.5.0+ds+~cs23.9.6-2 by moving everything to node-acorn > and turning node-debbundle-acorn into a pure transitional package. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: intersphinx mapping - https errors causing reproducibility failures
On Fri, Nov 19, 2021 at 08:49:33AM +, Neil Williams wrote:
> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/diffoscope-results/python-jira.html
>
> First build:
>
> PYTHONPATH=. http_proxy='127.0.0.1:9' python3 -m sphinx -N -bhtml docs/
> build/html # HTML generator
> Running Sphinx v4.2.0
> making output directory... done
> loading intersphinx inventory from https://docs.python.org/3.7/objects.inv...
>
> Comparative build:
>
> PYTHONPATH=. http_proxy='127.0.0.1:9' python3 -m sphinx -N -bhtml docs/
> build/html # HTML generator
> Running Sphinx v4.2.0
> making output directory... done
> loading intersphinx inventory from https://docs.python.org/3.7/objects.inv...
[…]
> WARNING: failed to reach any of the inventories with the following issues:
> intersphinx inventory
> 'https://requests.kennethreitz.org/en/master/objects.inv' not fetchable due
> to :
> HTTPSConnectionPool(host='requests.kennethreitz.org', port=443): Max retries
> exceeded with url: /en/master/objects.inv (Caused by
> SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
> certificate verify failed: certificate has expired (_ssl.c:1129)')))
What surprises me here is that it actually works.
Locally I see:
PYTHONPATH=. http_proxy='127.0.0.1:9' python3 -m sphinx -N -bhtml docs/
build/html # HTML generator
Running Sphinx v4.2.0
making output directory... done
loading intersphinx inventory from https://docs.python.org/3.7/objects.inv...
[…]
WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory
'https://requests-oauthlib.readthedocs.io/en/latest/objects.inv' not fetchable
due to :
HTTPSConnectionPool(host='requests-oauthlib.readthedocs.io', port=443): Max
retries exceeded with url: /en/latest/objects.inv (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
Which is what I expect, and which is what I see in, say, the amd64
build.
> The first run retrieves the inventories just fine, the second run
> always fails. This then leads to sphinx generating different output,
> causing the reproducibility failure.
Well, it's a RC bug even trying to do that (network access during the
build), so that's a bug coming your way ;)
--
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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled
(just dumping a quick point else I'm sure I'll forget by the time I get to
this mail when on the computer..)
A build process really must not create random files in HOME, and possibly
not even try to access them...
If having a nonexistent home dir (which... Isn't the case of boh default
pbuilder and sbuild?) leads to an ftbfs, that's pretty much a RC bug.
Although I don't remember the reference by heart, I'm quite sure I've seen
such RC bugs filed in the past.
On Wed, 9 Feb 2022, 7:36 pm Chris Lamb, wrote:
> Hi Dominique,
>
> >> --- a/dh_raku_build
> >> +++ b/dh_raku_build
> >> @@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
> >> --from=. --to=debian/tmp/pre-compiled!;
> >> doit({
> >> update_env => {
> >> +HOME => "/nonexistent",
> >> RAKUDO_RERESOLVE_DEPENDENCIES => 0,
> >> }
> >> },@cmd);
> >
> > Unfortunately, the build of perl6-zef with cowbuilder is already broken
> > with cowbuilder. The nonexistant home dir leads to build failures.
>
> Ah, shame. Although I wasn't experiencing a build failure, I was
> getting the same or similar warnings when building "perl6-readline".
>
> My gut sense is that this will require a change to Raku itself to not
> fail if the home directory does not exist. That would feel like a
> desired property anyway.
>
>
> Regards,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` la...@debian.org 🍥 chris-lamb.co.uk
>`-
>
> ___
> Reproducible-builds mailing list
> Reproducible-builds@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
>
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: haveged: status change on tests.reproducible-builds.org/debian
Hello Cyril, On Wed, Mar 09, 2022 at 01:51:41AM +0100, Cyril Brulebois wrote: > Reproducible Builds folks > (2022-03-09): > > 2022-03-08 01:09 > > https://tests.reproducible-builds.org/debian/unstable/amd64/haveged changed > > from reproducible -> FTBFS > > Let's do that: a pointer to the CI / build log would be helpful. Clicking on that URL bring you to a page that also links to the failing log. Anyhow, here is a direct link to the failing log: https://tests.reproducible-builds.org/debian/logs/unstable/amd64/haveged_1.9.14-1.build2.log.gz from that: |make check-local |make[3]: Entering directory '/build/2/haveged-1.9.14/2nd/ent' |./entest -t ./entitle.gif |Self-test good! |../src/haveged -n 16384k -v 1 |haveged: command socket is listening at fd 3 |Writing 16 M byte output to sample |haveged: ver: 1.9.14; arch: x86; vend: ; build: (gcc 11.2.0 ITV); collect: 128K |haveged: cpu: (VC); data: 64K (V); inst: 64K (V); idx: 39/40; sz: 53875/53875 |haveged: tot tests(BA8): A:1/1 B:1/1 last entropy estimate 7.99638 |haveged: fills: 32, generated: 16 M bytes |./entest -vf sample | |Test Results |Sample: 16777216 bytes |Entropy: 7.91 bits |Chi-Square: 197.890167(99.670454%) |Mean:127.519866 |PI: 3.140991(-0.019166%) |Correlation: -0.000286 |Check Fail: chisqr:99.670454% not in 1.00-99.00 |make[3]: *** [Makefile:574: check-local] Error 255 |make[3]: Leaving directory '/build/2/haveged-1.9.14/2nd/ent' |make[2]: *** [Makefile:447: check-am] Error 2 |make[2]: Leaving directory '/build/2/haveged-1.9.14/2nd/ent' |make[1]: *** [Makefile:481: check-recursive] Error 1 |make[1]: Leaving directory '/build/2/haveged-1.9.14/2nd' |dh_auto_test: error: make -j16 check VERBOSE=1 returned exit code 2 Note that in cases like this a build is automatically retried after a few days (2 or 3, I don't remember out of hand). Looking at the build history, I noticed that the last time this package failed it was 2021-09-08, with a build time that is very similar; we don't keep build old logs so I can't confirm. I can also add that the very same couple of builders was successfully used to build this package on 2021-10-29, and AFAIK since then nothing interesting happend on our infrastracture. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Status of Required/Essential/Build-Essential in Debian
On Wed, Apr 27, 2022 at 12:42:50PM -0700, Vagrant Cascadian wrote: > Lately, I've been trying to get a handle on the status of the really > core packages in Debian, namely the essential, required and > build-essential package sets. The first two are present on nearly every > Debian system, and build-essential is the set of packages assumed to be > available whenever you build a package in Debian. Thank you for your work!! > binutils has several identified issues and probably some unidentified > issues: > > included log files introduce reproducibility issues (debian specific?) > https://bugs.debian.org/950585 > > https://tests.reproducible-builds.org/debian/issues/unstable/test_suite_logs_issue.html I believe the long term solution to this would be introducing a standard way for package to produce build-related data that is not canonically distributed and should not count as a "build artifact". See also: https://bugs.launchpad.net/launchpad/+bug/1845159 The most common example of the above kind of data is the build log, but some package would like to take out other things from it, say test results, perhaps even (especially?) when a build fails. I tried to talk with Guillem about this some months ago (to see if dpkg could/should be involved), but then I dropped the ball. -- 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
