Bug#888237: Fwd: Re: diffoscope and file renames

Chris Lamb: > > I had no idea I should have installed it, and indeed I was missing it. > > … which is itself a bug! However, the solution is not very obvious - why > can't really detect whether we need would benefit from fuzzy matching without > doing said fuzzy matching! > > Will have a think

Bug#848049: diffoscope: Add detection of order-only differences in plain text formats

Hi! Маша Глухова: > The reason why I did not use some algorihm like that is that it requires to > read files for the second time. Right now, all the actual work with the > content of the files (except for the quick check for has_same_content) is > delegated to diff, and on big files, it occupies

Bug#849142: [PATCH] Update dex_expected_diffs and test requirement to ensure test compatibility with enjarify >= 1.0.3. (Closes: #849142)

Chris Lamb: > Daniel Shahaf wrote: > > > > +if subprocess.call( > > > +('python3', '-c', 'import enjarify.typeinference'), > > > > Use sys.executable instead of hardcoding 'python3', to handle the case > > that there's more than one python3 binary on the system? > > I deliberately

Bug#848049: diffoscope: Add detection of order-only differences in plain text formats

Маша Глухова: > I believe the attached patch would provide the requested functionality. Nice work! :) > From: Maria Glukhova > Date: Sat, 24 Dec 2016 12:29:57 +0200 > Subject: [PATCH] Add detection of order-only difference in plain text format. > > Detect if the text

Re: package uploaded to our repo

Mattia Rizzolo: > Next steps: > it would be great if somebody could figure what's the real gain of > having .dsc in Checksums-Sha256. This is how .buildinfo files have linked a source package in an unambiguous manner to the resulting binaries. I see how the current specification is giving you

Re: [dpkg] 08/08: document 1.18.10.0~reproducible1

Mattia Rizzolo: > The reason we like to have a static string in there (and in jenkins we > use the host architecture), is that otherwise diffoscope would be noisy > about the difference in the name if we compared the .changes files […]. Would it still be the case after Satyam's work which

Bug#838260: diffoscope: Reduce noise from offsets deltas in readelf(1) diffs

Daniel Shahaf: > Jérémy Bobbio wrote on Tue, Sep 20, 2016 at 13:18:49 +: >> But why stop with images? In the precise case of the readelf output, >> having line-oriented diff means we are carrying around a useless and >> confusing information: the line numbers are

Re: [Reproducible-builds] Remaining reprotest variations

Ceridwen: > For most of the variations I've done so far, I've been either > depending on external utilities or had POSIX-compliant ways to execute > them.  The rest of the variations pose more problems. > > 1. user_group.  The POSIX standard includes the notion of user/group > ids, but the only

Re: [Reproducible-builds] [diffoscope] Support for --ignore-profile flag in diffoscope

Ximin Luo: > Concretely I have some suggestions: > > 1. instead of calling this "ignore" we call it "hide". and instead of > "irrelevant" we say "common"/"minor"/"known" Great suggestions! :) > 2. diffoscope --ignore-* (or --hide-*) MUST NOT return 0 or otherwise > give the impression that two

Re: [Reproducible-builds] Support for --ignore-profile flag in diffoscope

Ximin Luo: > This is quite an open-ended problem and there is no single "correct" > answer. I don't even know myself what would be best, at this stage. I think what we need to come up with now is a list of use cases. Then we can decide which one we want to support and how easy it should be. Is

Re: [Reproducible-builds] Applying to Outreachy to work on Reproducible Builds

Valerie R Young: > Also: I've asked to join the alioth reproducible builds project (username: > spectranaut-guest), which I believe will give me access to git.debian.org. I > should have a public repo to push changes to soon! :) Seems you're in. :) -- Lunar.''`.

Re: [Reproducible-builds] [GSoC 2016] : Application review

Satyam Zode: > >> Official coding period. > >> 3) Week 1 - 2 (May 27 - June 9): > >> - Work on "Allow users to ignore arbitrary differences" part. > >> - Work simultaneously on unreproducible packages. > > > > How much time are you going to give to the community so they can review > > your

Re: [Reproducible-builds] [GSoC 2016] : Application review

Satyam Zode: > As far as my research till now is concerned. Brief timeline looks like: > Design and Experiment: > 1) During the application screening:(March 26 - April 22) > 1.1) Acquaint myself with diffoscope and research about proposed features. > 1.2) Get hands-on experience with

Re: [Reproducible-builds] [GSoC 2016] : Application review

Satyam Zode: > I have written project proposal (application) for the same. I kindly > request you to review the application [1]. I need your valuable > feedback and suggestions. I will consider it to improve an > application. >  [1]:

[Reproducible-builds] Heads-up! (was: [dpkg] 07/07: Document 1.18.5.0~reproducible1)

Jérémy Bobbio: > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,15 @@ > +dpkg (1.18.5.0~reproducible1) UNRELEASED; urgency=low > + > + * Use a single timestamp for ar headers when building a .deb. > + * Use the common build timestamp for all files cr

[Reproducible-builds] Bug#815844: Bug#815844: diffoscope won't build without python-magic from PyPi

Leo Famulari: > However, diffoscope's README [2] says that: > > ``Magic-file-extension`` can be used instead of > ``python-magic``. It is built from `file > `_. > Available on Debian and Fedora as ``python3-magic``. > > I removed the requirement of python-magic

Re: [Reproducible-builds] Bug#815171: Bug#815171: Bug#815171: Bug#815171: diffoscope: build time tests fail on armhf

Holger Levsen: > But given the above (100% build failure on armhf and 33% > failure on am64) I now think this is indeed a serious > issue, thus it should be treated as such. I've removed myself from Uploaders. As you are listed there, feel free to fix the bug as you see fit. -- Lunar

[Reproducible-builds] Bug#815171: Bug#815171: Bug#815171: diffoscope: build time tests fail on armhf

Holger Levsen: > I dont see why this should be a normal bug, ftbfs are > serious by default. Because it's just a test that is brittle. It doesn't affect normal use of the installed package and does only prevent a successful build one times out of ten. To please the cruel god of FTBFS I can

[Reproducible-builds] package uploaded to our repo

pyppd_1.0.2-3.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

[Reproducible-builds] Bug#815171: diffoscope: build time tests fail on armhf

Control: retitle -1 diffoscope: tests for directory are brittle Control: severity -1 normal Holger Levsen: > diffoscope fails to build from source in unstable/armhf but has > successfully built in the past: […] > […] > tests/comparators/test_directory.py:53: AssertionError > […] >

[Reproducible-builds] Bug#815252: colord: please make the build reproducible (timestamps)

Source: colord Version: 1.2.12-1 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps Control: block -1 by 814883 Hi! While working on the “reproducible builds” effort [1], we have noticed that colord could not be built reproducibly. The attached

[Reproducible-builds] Bug#815248: liblcms2: Writes uninitialized strings when writing named colors

allocated on the stack are zero'ed before a copy of the + actual string is made. + . + For consistency, we also remove unneeded extra allocated bytes in + Type_ColorantTable_Write() and Type_NamedColor_Write(). +Author: Jérémy Bobbio <lu...@debian.org> + +diff --git a/src/cmstypes.c b/src/cmstypes.c

Re: [Reproducible-builds] [Reproducible-commits] [misc] 01/01: Move timezone setting from rebuild.sh to pbuilderrc.build

Hi! > commit 420424b096c254aa5610b479fb1746e1a7bd13cb > Author: Esa Peuha > Date: Sat Feb 20 09:50:46 2016 +0200 > > Move timezone setting from rebuild.sh to pbuilderrc.build > --- > prebuilder/pbuilderrc.build | 1 + > prebuilder/rebuild.sh | 1 - > 2 files

Re: [Reproducible-builds] Projects and mentors wanted for our participation in upcoming outreach programmes

Holger Levsen: > > My main concern about making reprotest a GSoC project is “who is going > > to take care of the code after the summer?” I've seen way too many > > GSoC projects deliver something quite usable which is not followed up > > properly and then quickly rot. So the project gets an

Re: [Reproducible-builds] Projects and mentors wanted for our participation in upcoming outreach programmes

Holger Levsen: > On Sonntag, 14. Februar 2016, Nicolas Dandrimont wrote: > > Some of you have been waiting for it, and it's finally time: we are looking > > for mentors and project ideas for Debian's next participation in outreach > > programmes, from May to August 2016. > […] > Also, I've mostly

[Reproducible-builds] Bug#814883: lcms2: please add a way for clients to set the creation date/time in profile headers

cmsSetHeaderCreationDateTime + Clients might want to set an explicit value for the creation date/time + of a profile, e.g. to match the creation date/time of a description + file. +Author: Jérémy Bobbio <lu...@debian.org> + +--- lcms2-2.6.orig/include/lcms2.h lcms2-2.6/include/lcms2.h +@@ -

[Reproducible-builds] Bug#814832: libpgm: please make the build reproducible (timestamps)

+ in the environment. More details can be found on: + https://reproducible-builds.org/specs/source-date-epoch/ +Author: Jérémy Bobbio <lu...@debian.org> + +--- libpgm-5.1.118-1~dfsg.orig/openpgm/pgm/version_generator.py libpgm-5.1.118-1~dfsg/openpgm/pgm/version_generator.py +@@ -4,8 +4,9 @@

Re: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

Holger Levsen: > I know that *you* have grasped the concept of transitive build depends very > well, but I'm pretty sure that 97% of the DD population have no idea what > transitive build depends are, especially compared to build-depends or > alternative build-depends. And even 70% were too

Re: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

Holger Levsen: > On Sonntag, 31. Januar 2016, Jérémy Bobbio wrote: > > A breakdown of the change since the last submitted patch is available > > for easier review: > > https://anonscm.debian.org/cgit/reproducible/dpkg.git/log/?h=pu/buildinfo > > should we upload a p

Re: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

Hi! We were discussions the restrictions on buildinfo identifiers: fweb_1.62-12+b2_brahms-20120530T114812Z.buildinfo ^^^ this part The proposal was “the string should consist only of alphanumeric characters and hyphens”.

Re: [Reproducible-builds] Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

kg-genbuildinfo(1) +.\" +.\" Copyright © 1995-1996 Ian Jackson <i...@chiark.chu.cam.ac.uk> +.\" Copyright © 2000 Wichert Akkerman <wakke...@debian.org> +.\" Copyright © 2008-2010 Raphaël Hertzog <hert...@debian.org> +.\" Copyright © 2006-2014 Guillem Jover

Re: [Reproducible-builds] Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

Guillem Jover: > > How about naming the field “Environment-Variables”? > > Hmm, or Environment, or Build-Environment, which reminds me that I've > found the usage of Build-Environment (as the list of transitively > required packages) slightly confusing, precisely because the first > thing that

Re: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

Guillem Jover: > Lunar: > > I think the proposed patch is missing a field to record some environment > > variables that can affect the build process. Right now, I'm thinking of > > DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from > > dpkg-buildflags). Maybe others? Build profiles? >

Re: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

Guillem Jover: > > One of the main change is that `.buildinfo` should now be named with an > > arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP > > but can be set to an arbitrary value by the `--buildinfo-identifier` > > command line flag. > > Hmmm, leaking the hostname

Re: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

Guillem Jover: > I've some pending changes I'll be committing to master or a separate > branch, that I'd like to be tested on the reproducible setup (ideally > against the already generated and pre-existing reproducible binaries), > if that's possible, I'll ask about that when those land, I just

[Reproducible-builds] package uploaded to our repo

libxslt_1.1.28-2.1.0~reproducible2.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

[Reproducible-builds] Bug#812899: libsm: please make the build reproducible (locale)

Source: libsm Version: 2:1.2.2-1 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: locale Hi! While working on the “reproducible builds” effort [1], we have noticed that libsm could not be built reproducibly. The attached patch makes sure the text

[Reproducible-builds] Bug#812895: libxml++2.6: please make the build reproducible (environment)

Source: libxml++2.6 Version: 2.40.1-1 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: environment Hi! While working on the “reproducible builds” effort [1], we have noticed that libxml++2.6 could not be built reproducibly. The reason is that the entire

[Reproducible-builds] Bug#812876: glib2.0: please make the build reproducible (locale)

Source: glib2.0 Version: 2.46.2-3 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: locale Hi! While working on the “reproducible builds” effort [1], we have noticed that glib2.0 could not be built reproducibly. The attached patch ensure that functions

[Reproducible-builds] Bug#812762: findutils: FTBFS if fr_FR or other locales are installed

Source: findutils Version: 4.6.0-2 Severity: important User: reproducible-builds@lists.alioth.debian.org Usertag: ftbfs Hi! findutils will FTBFS due to test errors if fr_FR or a couple other locales are installed. The failing tests are test-mbrtowc{1,2,3,4}.sh. The log contains:

Re: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

Jérémy Bobbio: > The attached patch will enable dpkg-buildpackage to create .buildinfo > files as specified on the Debian wiki [1]. They have two main purposes: > > * recording information about the system environment used during a >particular build—versions of the bui

[Reproducible-builds] Bug#807669: dh-strip-nondeterminism: Breaks some jar file

Control: tag -1 + patch Raphael Hertzog: > On Mon, 14 Dec 2015, Raphael Hertzog wrote: > > Your analysis is correct but dh_strip_nondeterminisn should detect the > > signature and avoid messing up with the file in that case. > > > > That's what this bug is about. > > And we got another case

[Reproducible-builds] Bug#812524: Bug#812524: UnicodeDecodeError with glob2/0.9.4.4-2.4 on unstable/amd64

Control: tag -1 + pending Mattia Rizzolo: > File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 95: > ordinal not in range(128) Fixed in 00b26a6. --

[Reproducible-builds] Bug#812534: Bug#812534: TypeError with python-expyriment/0.7.0+git34-g55a4e7e-3.1 on unstable/amd64

Control: tag -1 + pending Mattia Rizzolo: > File "/usr/lib/python3/dist-packages/diffoscope/comparators/debian.py", > line 185, in recognizes > for d in buildinfo.get('Checksums-Sha256'): > TypeError: 'NoneType' object is not iterable Already fixed in af6bcf80. -- Lunar

[Reproducible-builds] Bug#808207: diffoscope: Filter objdump --disassemble output before diffing it

Hi Mike! Mike Hommey: > When comparing large ELF binaries, some minor differences can end up hurting > the visibility of more important differences. > > Specifically, objdump --disassemble displays symbols+offsets for addresses > it derives from IP-relative addressing, like the following: > >

[Reproducible-builds] Bug#808197: diffoscope: readelf --debug-dump can be brutal

Control: tag -1 + pending Mike Hommey: > However, if each debug section was compared individually, that give more > chance for diffoscope to work. (--debug-dump takes values allowing to treat > each debug section independently) Implemented by Dhole and currently available in the master branch.

[Reproducible-builds] Bug#808267: diffoscope: Redundant information in ELF comparisons

Hi Mike, Mike Hommey: > When comparing ELF files, the following commands are used: > - readelf --all > - readelf --debug-dump > - objdump --disassemble --full-contents > > objdump --disassemble --full-contents is actually redundant in itself. For > example, it will dump both an hexdump and a

[Reproducible-builds] package uploaded to our repo

dpkg_1.18.5~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

[Reproducible-builds] dpkg-dev: please make mtimes of packaged files deterministic

reassign 759886 dpkg-dev retitle 759886 dpkg-dev: please make mtimes of packaged files deterministic thanks Hi! The attached patch series is an attempt to make the mtimes of packaged files deterministic. It is taken from the `pu/reproducible_builds` dpkg branch maintained by the “reproducible

Re: [Reproducible-builds] package uploaded to our repo

Jérémy Bobbio: > dpkg_1.18.5~reproducible1.dsc has just been uploaded to > https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain With this upload, we should not need a modified debhelper anymore. :) See #759886. -- Lunar.''`. lu...@debi

[Reproducible-builds] dpkg-dev: please add support for .buildinfo files

5-1996 Ian Jackson <i...@chiark.chu.cam.ac.uk> +.\" Copyright © 2000 Wichert Akkerman <wakke...@debian.org> +.\" Copyright © 2008-2010 Raphaël Hertzog <hert...@debian.org> +.\" Copyright © 2006-2014 Guillem Jover <guil...@debian.org> +.\" Copyright © 2015 Jérémy B

[Reproducible-builds] Bug#808121: Bug#808121: Bug#808121: diffoscope: HTML output is bloated

Esa Peuha: > While we are at it, let's convert HTML character entity references > (which each use 6-8 characters and as many bytes in the HTML file) > to actual characters (which UTF-8 encodes as 2-3 bytes). Since all > diffoscope output files are peppered with abundant amounts of these > things,

[Reproducible-builds] Bug#808103: Bug#808103: diffoscope: Truncated symbols in ELF diffs

Control: tag -1 + pending Mike Hommey: > When there are differences in symbols-related sections of ELF files, > symbols can be truncated if they are long enough. That happens often > with C++ mangled symbols. > > The following patch fixes the issue: […] Applied, thanks! -- Lunar

[Reproducible-builds] Bug#808104: Bug#808104: diffoscope 43 KeyError's with several packages

Control: tag -1 + pending Mattia Rizzolo: > Seen on rb.d.n, with several packages, e.g. > dhcpdump/1.8-2 on testing/amd64 > console-data/2:1.12-5 on testing/amd64 > > > Wed Dec 16 01:52:13 UTC 2015 - diffoscope 43 will be used to compare the two > builds: > Traceback (most recent call last): >

[Reproducible-builds] Bug#808121: Bug#808121: diffoscope: HTML output is bloated

Close: tag -1 + pending Mike Hommey: > Looking at the HTML in the HTML output, one can see that it is needlessly > large. > > Specifically, there appears to be a lot of e.g. > following each other, without even a separation between them. This conflates > the amount of memory necessary for

[Reproducible-builds] Bug#808002: Bug#808002: diffoscope: Add support for Mozilla-optimized ZIPs

Control: tag -1 + pending Mike Hommey: > On Tue, Dec 15, 2015 at 04:31:46PM +0100, Jérémy Bobbio wrote: > > Mike Hommey: > > > It would be useful for diffoscope to output differences in omni.ja files > > > as > > > for other Zip files, instead of

[Reproducible-builds] Bug#808002: Bug#808002: diffoscope: Add support for Mozilla-optimized ZIPs

Mike Hommey: > It would be useful for diffoscope to output differences in omni.ja files as > for other Zip files, instead of ending up with a diff of an hexdump. > > The attached patch implements a minimal support for this. It however doesn't > look at the difference in the `preload` value.

[Reproducible-builds] Bug#806891: [Reproducible-commits] [diffoscope] 01/01: Multi-file HTML output

Joachim Breitner: > Multi-file HTML output Really great idea. :) Thanks for the initial patch! > +parser.add_argument('--jquery', metavar='url', dest='jquery_url', > +help='link to the jquery url, with --html-dir. By > default, a symlink to

[Reproducible-builds] diffoscope dedicated mailing-list

Hi! diffoscope is really growing bigger than just the Debian community, so it felt better to create a dedicated mailing-list. Please subscribe: https://lists.reproducible-builds.org/listinfo/diffoscope -- Lunar.''`. lu...@debian.org: :Ⓐ :

[Reproducible-builds] On which arch should Arch:all packages be built? addition to scsh-0.6, we should not be trying to build these packages on amd64:

Santiago Vila: > Let's take cmucl as an example: > > Package: cmucl > Architecture: i386 all > > It has "all", yes, but implicitly I take the Architecture line > as saying that I should only try to build the "Arch: all" package > using a i386 autobuilder. > > > Does this make sense? I think

[Reproducible-builds] Bug#806321: coreutils: please make the build reproducible (timestamps)

by the one in the help2man package. Add + the required Build-Depends. The in-tree help2man doesn't support + SOURCE_DATE_EPOCH. +- Set SOURCE_DATE_EPOCH to the date of the latest debian/changelog entry. + + -- Jérémy Bobbio <lu...@debian.org> Thu, 26 Nov 2015 12:43:39 +0100 + cor

[Reproducible-builds] Bug#806328: xz-utils: please ship xz.pot

Source: xz-utils Version: 5.1.1alpha+20120614-2.1 Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org, sanv...@debian.org Hi! While working on the “reproducible builds” effort [1], we have noticed

[Reproducible-builds] Bug#806331: xz-utils: make the selected POSIX shell stable accross build environments

Source: xz-utils Version: 5.1.1alpha+20120614-2.1 Severity: normal User: reproducible-builds@lists.alioth.debian.org Usertags: environment X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org, sanv...@debian.org Hi! While working on the “reproducible builds” effort [1], we have noticed that

[Reproducible-builds] Bug#806149: diffoscope TypeError processing openjfx/8u60-b27-4

Control: merge 805774 806149 Control: tag 805774 pending Mattia Rizzolo: > Seen on rb.d.n with openjfx/8u60-b27-4 on testing (trying it on unstable > resulted with a FTBFS of the package...) Same problem as #805774. Fixed in Git. -- Lunar.''`. lu...@debian.org

Re: [Reproducible-builds] [R-B WEBSITE PATCH] native en_US speaker website tweaks

Daniel Kahn Gillmor: > index.html | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Thanks, it's now live! :) -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'`

Re: [Reproducible-builds] GCC patch reviewed. Proposed mail for gcc-patches mailing list

Santiago Vila: > I have very mixed feelings about this kind of patches. > > I fear that by modifying gcc to hide the improper usage of __DATE__ > and __TIME__, we could be removing an incentive for maintainers and > authors to write software which is truly reproducible, i.e. we run > the risk of

Re: [Reproducible-builds] Repro Build report I do not understand

Dirk Eddelbuettel: > One of my packages which still didn't build reproduciby is littler -- for > which I am upstream. I rewrote the build process, and even though it produces > a small binary (which embeds R for use in #! scripts etc) it now ships as an > R package on CRAN. Which all build

Re: [Reproducible-builds] Repro Build report I do not understand

Dirk Eddelbuettel: > | From the quick look I had, it seems symbols are sorted in a different > | order depending on the locale: > | >

Re: [Reproducible-builds] binNMU detection for generating Changes field in buildinfo (was: Re: binNMU or reproducible builds (choose only one))

Johannes Schauer: > Lunar: > > Simon McVittie: > > > BinNMUs don't upload any source at all. They instruct the autobuilders > > > to run sbuild with some non-default options ("sbuild --binNMU=2 > > > --make-binNMU "Rebuild with foo 3" foo_1.2-3" will result in > > > foo_1.2-3+b2_i386.changes, I

Re: [Reproducible-builds] Weird localedef failures

Lunar: > We already had an issue where locales-all was not providing everything > that locales would provide. See #788352. > > I guess the fact that locales-all doesn't ship localedef can be > considered as a bug. But the whole point of locales-all is that you > don't need to build anything. >

Re: [Reproducible-builds] On expiring packages and issues

Santiago Vila: > On Fri, Oct 16, 2015 at 03:22:34PM +0200, Jérémy Bobbio wrote: > > I think it's sound to also remove issues due to Debian-specific > > toolchain once it has been fixed. I don't think there's much value in > > keeping tabs on something like ordering

Re: [Reproducible-builds] On expiring packages and issues

Holger Levsen: > On Freitag, 16. Oktober 2015, Santiago Vila wrote: > > Hi. Do we expire issues (not packages) when no package currently have them? > > https://reproducible.debian.net/index_issues.html -> scroll down to the > bottom. > > > (I would prefer to keep them). > > it depends, i'd

[Reproducible-builds] Bug#801855: ongl: test strings depend on default character encoding of the build system

Source: ognl Version: 2.7.3-6 Severity: minor User: reproducible-builds@lists.alioth.debian.org Usertags: locale Hi! It seems that depending on the build system default character encoding, the non-ASCII characters in org/ognl/test/QuotingTest.java might get mistranslated. This also prevents

Re: [Reproducible-builds] Notes on OpenWRT Reproducibility

bnewb...@robocracy.org: > 1. There's a statement that diffoscope "cannot detect .bin files as > squashfs". I don't think that's accurate, I could rename .squashfs files to > .bin and diffoscope found the magic and worked fine. diffoscope currently recognizes Squashfs images using file(1). The

[Reproducible-builds] Bug#801333: retitle

retitle 801333 diffoscope: UnicodeDecodeError with haskell-authenticate-oauth/1.5.1.1-4 clone 801333 -1 retitle -1 diffoscope: UnicodeDecodeError in test_text_option_with_file severity -1 minor thanks Holger Levsen: > someone just reported the same problem on irc: […] It was not the same

[Reproducible-builds] package uploaded to our repo

dpkg_1.18.3.0~reproducible2.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

[Reproducible-builds] [report] Week 23 in Stretch cycle

What happened in the [1]reproducible builds effort this past week: Toolchain fixes Barry Warsaw uploaded wheel/0.26.0-1 which now uses [2]SOURCE_DATE_EPOCH instead of WHEEL_FORCE_TIMESTAMP and [3]uses time.gmtime() to avoid timezone issues. Patches by Chris Lamb and Reiner

Re: [Reproducible-builds] CI testbuilds LC_ALL vs. LANG

Andreas Metzler: > If we are aiming for locale agnostic builds we seem to take a > unnecessary work intensive approach by adding > export LC_ALL=C > to dozens (hundreds?) of debian/rules or changing > -sort > +env LC_ALL= sort > instead of simply patching dpkg-buildpackage. Using

Re: [Reproducible-builds] dpkg 1.18.3.0~reproducible1 is broken (?)

Santiago Vila: > Using > > deb http://reproducible.alioth.debian.org/debian/ ./ > > even the most simple package created makes lintian to complain: > […] I will not be able to look into this at least before the week-end. So please beat me to it. -- Lunar.''`.

[Reproducible-builds] [report] Week 22 in Stretch cycle

What happened in the [1]reproducible builds effort this past week: Toolchain fixes * Ben Hutchings uploaded linux-tools/4.2-1 which makes the tarball generated by genorig.py reproducible. Packages fixed The following 22 packages became reproducible due to changes in their

Re: [Reproducible-builds] Adding a 'c' build to test with DEB_BUILD_OPTIONS=nocheck ?

Chris Lamb: > I just ran into yet another package where the contents can vary > depending on whether the tests are run or not. > > As an example, without tests a given Python package entirely vanilla and > is thus reproducible in our toolchain. However, executing the tests > creates various

[Reproducible-builds] Week 21 in Stretch cycle

What happened in the [1]reproducible builds effort this week: Media coverage Nathan Willis covered [2]our DebConf15 status update in Linux Weekly News. Access to non-LWN subscribers will be given on Thursday 24th. Linux Journal published a [3]more general piece last Tuesday.

Re: [Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

Ximin Luo: > > Implementation-wise, getting the hash of the .dsc in the .buildinfo is > > going to be very tricky. dpkg does not know about what's available in > > the archive. It just knows about packages which are or were installed. > > > > `apt-cache showsrc [pkg]` has the right information

[Reproducible-builds] Bug#799690: file: regression in MIME encoding lookups

Package: file Version: 1:5.25-1 Severity: important Hi! The latest upload of file broke diffoscope test suite. With file/1:5.24-2: $ file --mime-encoding tests/data/binary1 tests/data/binary1: binary With file/1:5.25-1: $ file --mime-encoding tests/data/binary1

[Reproducible-builds] package uploaded to our repo

dpkg_1.18.3.0~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

Re: [Reproducible-builds] Bug#774274: fontforge: please allow scripts to set the font modification time

Jérémy Bobbio: > For font compilation to be deterministic, we need a way to set the font > modification time to a defined value instead of the current time. > > We thus add a new function “SetModificationTime” to the scripting language. > It takes a single string argument looking l

Re: [Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

Ximin Luo: > With our current .buildinfo setup, the above process is more > complicated, because we *only* store hashes of the binary build > environment. I'm sorry but this is not accurate regarding the current specification [1]. It says: Build-Environment List of all packages forming

Re: [Reproducible-builds] [Debian Wiki] Update of "ReproducibleBuilds/TimestampsProposal" by BenBoeckel

Daniel Kahn Gillmor: > Wiki page: > > - EXECUTE_PROCESS(COMMAND "date" "-u" "-d @${SOURCE_DATE_EPOCH}" > > "+%d/%m/%Y" OUTPUT_VARIABLE BUILD_DATE) > […] > Is there a reason above that this example code to translate from > SOURCE_DATE_EPOCH to a build date doesn't produce ISO-8601-compliant >

[Reproducible-builds] [report] Week 20 in Stretch cycle

[ Chris Lamb suggested to post the weekly reports that has been so far ] [ available on Planet Debian to the mailing-list. Please tell us if] [ you think that's not a good idea.] What happened in the [1]reproducible builds effort this week: Media

[Reproducible-builds] Bug#788364: libmagic1: misdetect some Coreboot images as text

retitle 788364 diffoscope: garbled output when comparing some Coreboot images clone 788364 -1 reassign -1 libmagic1 severity -1 libmagic1 normal retitle -1 libmagic1: misdetect Coreboot images as text files thanks Hi Christoph, diffoscope is the tool that we have created as part of the

[Reproducible-builds] Bug#797525: Bug#797525: diffoscope: multiarch mode

Control: retitle -1 diffoscope: provide a way to ignore all differences in control.tar Jérémy Bobbio: > Jakub Wilk: > > I want to use diffoscope to compare two "Multi-Arch: same" debs of the same > > version but different architecture, to see differences that will

[Reproducible-builds] Bug#797759: Bug#797759: diffoscope: tar.gz and tar.bz2 archives compared wrongly

Control: retitle -1 diffoscope: implement fuzzy-matching across containers Control: severity -1 wishlist Michele Alessandrini: > When comparing tar.gz or tar.bz2 archives containing text files, some > of which different, the output is a binary diff. Perhaps it only > applies decompression and

Re: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

Santiago Vila: > Excluding .pot files from what is considered to be the "source" might > be part of the problem. See tor-monitor upstream's reaction, for example: https://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20150824/15.html Quoting Alan from there: > I

[Reproducible-builds] package uploaded to our repo

dpkg_1.18.3~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

Re: [Reproducible-builds] SOURCE_DATE_EPOCH specification document

Chris Lamb: Mattia wrote: After a hint from doko, I've started work on an official-looking spec for SOURCE_DATE_EPOCH Lamby pointed out that this is not something debian-related, so it would be great to have it outsite a debian.{org,net} site. OTOH also the howto is not strictly

[Reproducible-builds] Bug#796039: diffoscope: please recognize big-endian Haskell .hi files

Package: diffoscope Severity: normal diffoscope currently doesn't know how to parse Haskell .hi files written on big-endian architectures as such. This should be fixed. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism

Re: [Reproducible-builds] Reproducibility vs signatures

Ben Hutchings: On Mon, 2015-08-03 at 10:27 +0200, Jérémy Bobbio wrote: Ben Hutchings: At some point we're hopefully going to support Secure Boot on amd64. That means there will be a signed kernel image (separate from the current linux-image packages) and a signed GRUB image

Re: [Reproducible-builds] Reproducibility vs signatures

Ben Hutchings: At some point we're hopefully going to support Secure Boot on amd64. That means there will be a signed kernel image (separate from the current linux-image packages) and a signed GRUB image. The kernel modules in the linux-image packages will also be signed, probably with an

[Reproducible-builds] package uploaded to our repo

debbindiff_28.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

Re: [Reproducible-builds] proposal: store information in one place instead of multiple ones

Johannes Schauer: here are several questions I have which, for me boil down to information being duplicated and stored in different locations, leading to possible confusion for contributors and added work when adding new bugs and issues: Before I go further with answering: it seems you

  1   2   3   >