Re: [Reproducible-builds] [Debian Wiki] Update of ReproducibleBuilds/TimestampsInDocumentationGeneratedByAsciidoc by jumapico

2015-04-09 Thread Ximin Luo
On 09/04/15 11:08, Mattia Rizzolo wrote: On Apr 9, 2015 10:37 AM, Holger Levsen hol...@layer-acht.org mailto:hol...@layer-acht.org wrote: Also, a bug should be filled against asciidoc to achieve that. What I'm doing is using faketime and setting PATH to include a asciidoc wrapper:

Re: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-04 Thread Ximin Luo
On 04/06/15 19:30, Daniel Kahn Gillmor wrote: What TZ should SOURCEDATE have? ISO8601 is capable of supplying a TZ as well, so the current time could be written in a wide variety of ways while meaning the same instant: 0 dkg@alice:~$ date '+%FT%T%z' date -u '+%FT%T%z'

Re: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-05 Thread Ximin Luo
On 05/06/15 04:19, Daniel Kahn Gillmor wrote: On Thu 2015-06-04 21:51:37 -0400, Brendan O'Dea wrote: Local times, and daylight savings are just too much of a PITA. Just use UTC and if builds on the first of the month are possibly different to the changelog, so be it. I agree with Brendan

Re: [Reproducible-builds] Bug#787444: Bug#787444: Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-10 Thread Ximin Luo
On 10/06/15 12:58, Brendan O'Dea wrote: On 10 June 2015 at 20:54, Ximin Luo infini...@pwned.gg wrote: On 10/06/15 12:41, Brendan O'Dea wrote: On 10 June 2015 at 01:59, Ximin Luo infini...@pwned.gg wrote: SOURCE_DATE = $(date -d $(dpkg-parsechangelog --count 1 -SDate) --iso-8601=seconds

Re: [Reproducible-builds] Bug#789648: apt-dater: please make the build reproducible

2015-06-23 Thread Ximin Luo
On 23/06/15 03:42, Dhole wrote: Source: apt-dater Version: 1.0.1+git20150119-1 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps Hi! While working on the “reproducible builds” effort [1], we have noticed that apt-dater could not be

Re: [Reproducible-builds] Bug#785624: Timestamps in manpages generated makes builds non-reproducible

2015-06-30 Thread Ximin Luo
Hi, We are trying to develop a standard environment variable for this purpose, please see: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal Any chance you can rewrite the patch to use SOURCE_DATE_EPOCH in unix timestamp format? The reason for preferring this over the ISO8601

Re: [Reproducible-builds] GSoC 2015 Week 5: Move forward reproducible builds

2015-06-30 Thread Ximin Luo
Hi Akira, In case you weren't aware before, we recently decided to try to promote the use of SOURCE_DATE_EPOCH as a standard environment variable for timestamps during builds. See https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal for details. Please write or amend your patches

Re: [Reproducible-builds] [RFC PATCH] Makefile: Add SOURCE_DATE_TZ

2015-08-03 Thread Ximin Luo
On 01/08/15 20:47, Paul Kocialkowski wrote: Le samedi 01 août 2015 à 22:32 +1200, Chris Packham a écrit : Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a build with a specific date timestamp. This allows the verification of source supplied with a pre-compiled binary. If

Re: [Reproducible-builds] [RFC PATCH] Makefile: Add SOURCE_DATE_TZ

2015-08-03 Thread Ximin Luo
On 02/08/15 00:02, Ximin Luo wrote: However, I am not sure that us at Reproducible Builds will actually adopt this variable. We haven't talked about it beyond my previous email [1], it was just me quickly skimming off my thoughts and firing off quick ideas. Whoops, I mean the _TZ variable

Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

2015-07-31 Thread Ximin Luo
On 31/07/15 07:25, Chris Packham wrote: The problem is that date -u implies UTC. So + is right if you do want the time to be displayed in UTC (for me living at +12/+13 UTC makes my head hurt because all the dates are yesterday). One of the main problems with human-readable date/time is

Re: [Reproducible-builds] Bug#791823: debhelper: set SOURCE_DATE_EPOCH env var for reproducible builds

2015-07-20 Thread Ximin Luo
On 12/07/15 12:03, Jérémy Bobbio wrote: Hi! Dhole: Also, in order to help reproducible builds, a fixed timezone is exported (TZ=UTC). I am not convinced this change is a good idea. While reviewing new uploads to the Debian archive, I have at least spotted these lines in exim4/4.86~RC4-1

Re: [Reproducible-builds] GSoC 2015 Week 8: Move forward reproducible builds

2015-07-21 Thread Ximin Luo
Hey, thanks for the report. Sorry in advance if this sounds like nitpicking - I notice that a lot of these patches use BUILD_DATE instead of SOURCE_DATE_EPOCH. Any reason for the difference? Consistency is a good principle in large-scale engineering. It is perhaps not worth it to change the

Re: [Reproducible-builds] GSoC 2015 Week 8: Move forward reproducible builds

2015-07-21 Thread Ximin Luo
On 21/07/15 14:33, Maria Valentina Marin wrote: Hi, On 07/21/2015 01:06 PM, Ximin Luo wrote: Sorry in advance if this sounds like nitpicking - I notice that a lot of these patches use BUILD_DATE instead of SOURCE_DATE_EPOCH. Any reason for the difference? I used this fix because

Re: [Reproducible-builds] SOURCE_DATE_EPOCH specification document

2015-08-27 Thread Ximin Luo
On 27/08/15 15:32, Chris Lamb wrote: Chris Lamb wrote: I plan to dump the rest of what's in my head today (depending on the level of sun) Sincere apologies that this took longer than promised, but I think I've reached a good point:

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

2015-09-20 Thread Ximin Luo
Hi list, BACKGROUND == One of the main points of reproducible builds is to enable DDC: http://www.dwheeler.com/trusting-trust/ To take an example, I can convince myself that my /bin/gcc5 corresponds exactly to the source code /src/gcc5, if I can: 1. assume that one of /bin/clang,

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

2015-09-21 Thread Ximin Luo
On 20/09/15 20:43, Jérémy Bobbio wrote: > Ximin Luo: >> With our current .buildinfo setup, the above process is more >> complicated, because we *only* store hashes of the binary build >> environment. > > [..] > > The idea to put a hash of the binary package in

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

2015-09-21 Thread Ximin Luo
On 20/09/15 19:22, Johannes Schauer wrote: > Hi, > > Quoting Ximin Luo (2015-09-20 18:49:16) >> Currently, to run a DDC test, we would have to read the buildinfo file, find >> the hashes of the binary build-deps, lookup the source packages that >> corresponds to the

Re: [Reproducible-builds] [PATCH] Have index_issues also show total popcon scores of each issue

2016-06-11 Thread Ximin Luo
Holger Levsen: > On Wed, May 11, 2016 at 04:14:53AM +0200, Ximin Luo wrote: >> Oh I forgot to mention, you'll need to install python3-popcon on the machine >> running jenkins for it to work. > > python3-popcon is not yet available in jessie-backports, someone need

Re: [Reproducible-builds] [tex-k] SORCE_DATE_EPOCH_TEX_PRIMITIVES

2016-06-10 Thread Ximin Luo
Karl Berry: > rename SOURCE_DATE_EPOCH_TEX_PRIMITIVES to a more generic name like > USE_CLOCK_SOURCE_DATE. > > I'm fine with that, or any other reasonable name for the second envvar. > Just tell me the name you want. > OK, we've talked a bit more about it and gotten consensus. How does

Re: [Reproducible-builds] [tex-k] SORCE_DATE_EPOCH_TEX_PRIMITIVES

2016-06-11 Thread Ximin Luo
Karl Berry: > How does FORCE_SOURCE_DATE sound? > > Fine by me. Shall I change the pdftex source? > > I don't much want to make a new release just for this, but it would be > fine (in fact preferable) to me if you made the change in Debian now. > Since after all the whole thing is for your

Re: [Reproducible-builds] Better popcon stats for source packages

2016-06-13 Thread Ximin Luo
Bill Allombert: > On Mon, Jun 13, 2016 at 03:17:18PM +0200, Ximin Luo wrote: >> Hi, >> >> At Reproducible Builds we just added popcon stats to our issues page, >> to help us better understand which issues to prioritise: >> https://tests.reproducible-bu

[Reproducible-builds] Better popcon stats for source packages

2016-06-13 Thread Ximin Luo
Hi, At Reproducible Builds we just added popcon stats to our issues page, to help us better understand which issues to prioritise: https://tests.reproducible-builds.org/debian/index_issues.html However, we work on source packages, but popcon data is based on binary packages. This means that

Re: [Reproducible-builds] [Groff] Reproducible dates in HTML/PDF/PS output files?

2016-06-13 Thread Ximin Luo
Ximin Luo: > Hi all, was this ever committed? I don't see it in the commit archives... > Hey, any news on this? The original thread I'm referring to is this one: https://lists.gnu.org/archive/html/groff/2015-11/msg00013.html X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5F

Re: [Reproducible-builds] [xz-devel] Re: xz-utils: make the selected POSIX shell stable accross build environments

2016-06-15 Thread Ximin Luo
+bugs-gnulib, reproducible-builds Lasse Collin: > On 2016-06-07 Ximin Luo wrote: >> I've attached a patch that makes m4/posix-shell.m4 try constant paths >> first. This should fix the issue. >> >> Upstream should also apply it - see more-stable-shell.patch. > >

Re: [Reproducible-builds] [xz-devel] Re: xz-utils: make the selected POSIX shell stable accross build environments

2016-06-15 Thread Ximin Luo
Thorsten Glaser: > Ximin Luo dixit: > >> bugs-gnulib, do you see any issue with this patch? The context is that > > [..] > > $CONFIG_SHELL should stay the ultimate instance. Users absolutely MUST > be able to override not-working-but-recognised-as-good-enough s

[Reproducible-builds] Reprotest week 59 blog comments

2016-06-17 Thread Ximin Luo
> For other packages, it's unclear to me whether I should specify them as > depends or recommends: they aren't dependencies in a strict sense, but > marking them as dependencies will make it easier to install a > fully-functional reprotest. You should specify these as Recommends, the

Re: [Reproducible-builds] Reprotest week 59 blog comments

2016-06-17 Thread Ximin Luo
Ceridwen: > On Fri, 2016-06-17 at 19:13 +0200, Ximin Luo wrote: >>> For other packages, it's unclear to me whether I should specify >>> them as depends or recommends: they aren't dependencies in a strict >>> sense, but marking them as dependencies will make it

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

2016-06-15 Thread Ximin Luo
(Did you mean to add debian-bugs-dist and Jonathan Nieder on purpose or by accident? I removed them, but feel free to add them back in.) Thorsten Glaser: >> proposed patch affect your scenario? This is not about CONFIG_SHELL, > > It is. Straight from your diff: > >> for gl_cv_posix_shell

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

2016-06-15 Thread Ximin Luo
Paul Eggert: > On 06/15/2016 01:44 PM, Ximin Luo wrote: >> In such a case, it is a bug to be using $POSIX_SHELL - which only tests for >> conformance with POSIX and not these "other bugs that make it unusable". > Gnulib can't test for all POSIX violations, only

Re: [Reproducible-builds] Ideas about TimestampsFromCPPMacros issue.

2016-02-11 Thread Ximin Luo
Juan Picca: > From the issue page > (https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros) > i see that the usage of SOURCE_DATE_EPOCH was > discouraged in the gcc-patches mailing list thread. > Hi Juan, I think that was not discouragement, it was just neutral discussion about the

Re: [Reproducible-builds] lua-ldoc --date/SOURCE_DATE_EPOCH

2016-04-06 Thread Ximin Luo
Alexis Bienvenüe: > Hi. > > lua-ldoc's maintainer added a --date option that helps reproducible > building. It is used by lua-penlight. > However, awesome and lua-posix don't use it already. > > What should you recommend? > 1) patch awesome and lua-posix to use --date > 2) patch lua-ldoc to add

Re: [Reproducible-builds] lua-ldoc --date/SOURCE_DATE_EPOCH

2016-04-06 Thread Ximin Luo
p...@passoire.fr: > Hi Ximin. > > Le 06/04/2016 13:17, Ximin Luo a écrit : >> The most preferable route would be to persuade upstream to accept patch (2). >> If they don't do that, then it's still worth doing option (2) over (1) > > Thanks for your answer. I will g

[Reproducible-builds] [PATCH] Have index_issues also show total popcon scores of each issue

2016-05-10 Thread Ximin Luo
From: Ximin Luo <infini...@debian.org> Date: Wed, 11 May 2016 04:11:21 +0200 Subject: [PATCH] Have index_issues also show total popcon scores of each issue We add extra columns in the table, that indicate: 1. the total popcon of each issue's packages 2. the total sqrt-popcon of that 3. the

Re: [Reproducible-builds] [PATCH] Have index_issues also show total popcon scores of each issue

2016-05-10 Thread Ximin Luo
Oh I forgot to mention, you'll need to install python3-popcon on the machine running jenkins for it to work. Ximin Luo: > Please see the attached patch. I haven't had a chance to test it but > hopefully you can fix any minor mistakes I made. > -- GPG: ed25519/56034877E1F87C35 GPG

Re: [Reproducible-builds] Bug#824182: codeblocks: please make the build reproducible (timestamps)

2016-05-17 Thread Ximin Luo
(sorry for repost, making sure the right people see this) Fabian Wolff: > -export DEB_CPPFLAGS_MAINT_APPEND=-DNDEBUG > +export DEB_CPPFLAGS_MAINT_APPEND=-DNDEBUG \ > + -DBUILD_DATE="\"\\\"`date -u -d @$(SOURCE_DATE_EPOCH) +%Y-%m-%d`\\\"\"" > \ > + -DBUILD_TIME="\"\\\"`date -u -d

Re: [Reproducible-builds] Bug#824182: codeblocks: please make the build reproducible (timestamps)

2016-05-17 Thread Ximin Luo
Ximin Luo: > (sorry for repost, making sure the right people see this) > > Fabian Wolff: >> -export DEB_CPPFLAGS_MAINT_APPEND=-DNDEBUG >> +export DEB_CPPFLAGS_MAINT_APPEND=-DNDEBUG \ >> +-DBUILD_DATE="\"\\\"`date -u -d @$(SOURCE_DATE_EPOCH) +%

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

2016-05-13 Thread Ximin Luo
Jérémy Bobbio: > 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 wh

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

2016-05-13 Thread Ximin Luo
Satyam Zode: > Yes! I'm looking at those issues but it seems those issues are more in > number. Frankly speaking, I'm not completely aware about many of those. > Hence, I'm requesting you all to give some suggestions (and may be list of > issues) so that I can start working on it further. > Or

Re: [Reproducible-builds] SORCE_DATE_EPOCH_TEX_PRIMITIVES

2016-05-15 Thread Ximin Luo
(I ask that everyone spend some undisturbed and unpressured time to read and digest what I'm about to write. Hopefully this way we can avoid unnecessary redundant replies that don't contribute new information and only risk adding fuel to any potential flamewars.) Alexis Bienvenüe: > Therefore,

Please review the draft for week 91's blog post

2017-01-27 Thread Ximin Luo
Sorry for the late one this week, we had an irregular schedule the past few weeks which screwed with my intuition on who was supposed to write it. https://reproducible.alioth.debian.org/blog/drafts/91/ Feel free to commit fixes directly to drafts/91.mdwn in

Bug#852013: Patch to prevent segfaults on signal

2017-01-29 Thread Ximin Luo
Brett Smith: > [..] > > I've also attached a script I used to help reproduce the issue. It > doesn't do so reliably, and it's not totally robust itself, but I found > it more reliable than trying to time timeout or a ^C right. > > [..] Hey Brett, could you also upload the ink*.tar files

Please review the draft for week 95's blog post

2017-02-20 Thread Ximin Luo
Hi all, This week's blog post draft is available for review: https://reproducible.alioth.debian.org/blog/drafts/95/ Feel free to commit fixes directly to drafts/95.mdwn in https://anonscm.debian.org/git/reproducible/blog.git/ I'll wait at least 24 hours from the time of this email for any

Re: would/Does it make sense to have .buildinfo feature into compiling tools as well ?

2017-02-14 Thread Ximin Luo
shirish शिरीष: > Dear all, > > My idea/suggestion may be crap but still please go through it. > > From whatever little I understand of reproducible builds, one of the > basic things it tries to do is have a .buildinfo file which can be > shared with the other person so that s(he) can use the

Bug#854723: diffoscope writes to arbitrary locations on disk based on the contents of an untrusted archive

2017-02-09 Thread Ximin Luo
Package: diffoscope Version: 67 Severity: grave Tags: patch security Justification: user security hole Dear Maintainer, 5fdfe91e71f1c520d902350b18f793b8c69d9118 introduced a security hole where diffoscope may write to arbitrary locations on disk depending on the contents of an untrusted archive.

Bug#852013: Patch to prevent segfaults on signal

2017-02-09 Thread Ximin Luo
The bug is closed, but I took a closer look at the issue to learn more about the situation. Chris' commit fixed the cleanup issue, but I think Brett's FIFO patch was probably also needed to deal with the segfaults. Brett Smith: > [..] While I was debugging, I added the line >

Bug#854723: diffoscope writes to arbitrary locations on disk based on the contents of an untrusted archive

2017-02-09 Thread Ximin Luo
Ximin Luo: > Chris Lamb: >> tags 854723 + pending >> thanks >> >>> diffoscope may write to arbitrary locations on disk depending on the >>> contents >>> of an untrusted archive >> >> We can actually avoid all edge-cases of sanitisation

Bug#854723: diffoscope writes to arbitrary locations on disk based on the contents of an untrusted archive

2017-02-09 Thread Ximin Luo
Chris Lamb: > tags 854723 + pending > thanks > >> diffoscope may write to arbitrary locations on disk depending on the contents >> of an untrusted archive > > We can actually avoid all edge-cases of sanitisation by simply not using > the supplied filename and maintaining our own mapping. > >

Re: diffoscope 77 in stretch or not?

2017-02-14 Thread Ximin Luo
Holger Levsen: > On Tue, Feb 14, 2017 at 09:38:51AM +1300, Chris Lamb wrote: >>> what did you plan on to do with diffoscope in regard to Debian's >>> stretch when you decided to work on it >> I didn't decide anything at all; I was enjoying the coding, adding >> features, tests, squashing bugs... >

Re: diffoscope 77 in stretch or not?

2017-02-15 Thread Ximin Luo
Holger Levsen: > On Tue, Feb 14, 2017 at 08:44:00PM +0000, Ximin Luo wrote: >> I do think it's OK to try to support diffoscope 67 for 2 years because it's >> been quite well tested. > > well, yes… but… > >> I understand that 77 fixes quite a lot of bugs over 67…

Please review the draft for week 93's blog post

2017-02-09 Thread Ximin Luo
https://reproducible.alioth.debian.org/blog/drafts/93/ Feel free to commit fixes directly to drafts/93.mdwn in https://anonscm.debian.org/git/reproducible/blog.git/ I will publish this in 24 hours. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE

Bug#855282: debsign: support .buildinfo files

2017-02-16 Thread Ximin Luo
Package: devscripts Version: 2.17.1 Severity: wishlist Dear Maintainer, dpkg since version 1.18.19 has been signing buildinfo files by default. debsign at the moment will ignore these and leave them unsigned. It would be good to support them. Ximin -- Package-specific info: ---

Bug#855273: diffoscope: still fails to clean up after SIGTERM

2017-02-16 Thread Ximin Luo
Mattia Rizzolo: > Package: diffoscope > Version: 77 > Severity: important > > So, yesterday we tried to re-enable artifacts saving on jenkins, and the > disc filled again because of GBs of temporary files left around. > > In a log the only message I see is: > > |Wed Feb 15 23:28:21 UTC 2017 I:

Re: Bug#855282: debsign: support .buildinfo files

2017-02-16 Thread Ximin Luo
Control: tags + patch Hi all, I've done an initial implementation here: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/log/?h=pu/debsign-buildinfo Please review! I haven't yet updated debrsign but I think that program is a bit pointless anyway, and have documented this in

Re: package uploaded to our repo

2017-02-13 Thread Ximin Luo
Holger Levsen: > Hi Chris, > > On Sun, Feb 12, 2017 at 09:09:54PM +, Chris Lamb wrote: >> python2.7_2.7.13-3~reproducible1.dsc has just been uploaded to >> https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain > > can you please explain why you did this? > Yes, it'd be good to

Bug#843811: strip-nondeterminism: does not strip nondeterminism from /SYM64/ ar entries

2017-02-13 Thread Ximin Luo
Chris Lamb: > Chris Lamb wrote: > >> Hi Ximin, >> >>> does not strip nondeterminism from /SYM64/ ar entries >> >> Can you clarify whether the attachments to the report are testcases; are >> the two files meant to be an input+expected pair, or… ? > > I've just noticed #781262 too FYI :) > > I

Re: [Reproducible-builds] Bug#781262: strip-nondeterminism: remove ar handler now?

2017-02-13 Thread Ximin Luo
Holger Levsen: > Hi, > > binutils 2.25-6 (which is long in testing + sid) made the build > reproducible (#774429). In that course that bug was cloned into #781262, > which asks for the ar handler of strip-nondeterminism to be removed. > > I'm slightly confused now, but (why) is binutils the only

Re: What do we really mean by "reproducible"?

2017-01-16 Thread Ximin Luo
Santiago Vila: > Greetings. > > Before I use this rationale more times in some discussions out there, I'd > like to be sure that there is a consensus. > > What's the definition of reproducible? It is more like A or more like B? > > A. Every time the package is attempted to build, the build

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

2016-08-21 Thread Ximin Luo
Jonathan McDowell: > On Sat, Aug 20, 2016 at 03:13:00PM +0000, Ximin Luo wrote: >> I have trouble imagining what could make Buildinfo.tgz hard, but make >> Buildinfo.xz easy - could you explain this in more detail, please? > > Debian's archive information is largely sto

Re: [Reproducible-builds] Bug#763822: Moving towards buildinfo on the archive network

2016-08-21 Thread Ximin Luo
Jonathan McDowell: > On Sun, Aug 21, 2016 at 04:01:00PM +0000, Ximin Luo wrote: >> You have this backwards. >> >> "Being able to verify individually who build each of the packages I'm >> running" >> >> is *exactly* what is required to *not* have

Re: [Reproducible-builds] Bug#763822: Moving towards buildinfo on the archive network

2016-08-21 Thread Ximin Luo
Ximin Luo: > Signatures provide a way to for us to aggregate public trust on binaries that > don't build themselves. So it's important to have multiple and *very direct* > meanings of what-is-being-signed, to avoid a transitive-trust situation. > I sent this in a rush; be

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

2016-08-20 Thread Ximin Luo
Hey, Lunar has stopped doing reproducible builds as a regular thing, and I'm taking over his previous responsibilities. I was also the main other person in formulating the ideas behind the "next iteration" of buildinfo, that dkg described in message #10 earlier in this thread, with Message-ID

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

2016-08-21 Thread Ximin Luo
Jonathan McDowell: > On Sat, Aug 20, 2016 at 03:13:00PM +0000, Ximin Luo wrote: >> Note that the builder is a *distinct entity* from the distribution. >> It's important to keep the *original* signature by B on C. It breaks >> our security logic, to strip the signature and

Re: [Reproducible-builds] More lazy-loading for diffoscope html output

2016-08-25 Thread Ximin Luo
Chris Lamb: >> https://people.debian.org/~infinity0/res/dfs-demo/ > > Like it! > > However, hould you object to making it show some — however small — diff on > page load? I am all behind lazy-loading of further chunks but I am certain > I will find it annoying to have to click «load diffs» when

[Reproducible-builds] More lazy-loading for diffoscope html output

2016-08-25 Thread Ximin Luo
Hey all, I made some changes to diffoscope to improve the html output for very large diffs. Previously, the default limits clashed with each other to make some features a bit useless - such as the lazy-loading-via-jquery behaviour. I've fixed this and also added the extra feature of splitting

Re: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output

2016-09-05 Thread Ximin Luo
Ximin Luo: > Chris Lamb: >>> https://people.debian.org/~infinity0/res/dfs-demo/ >> >> Like it! >> >> However, hould you object to making it show some — however small — diff on >> page load? I am all behind lazy-loading of further chunks but I am certain &

Re: Bug#836784: diffoscope: Several "Too much input for diff" on debian packages from unstable/amd64

2016-09-05 Thread Ximin Luo
Emanuel Bronshtein: > Source: diffoscope > Severity: normal > > Dear Maintainer, > > The packages "esajpip" & "aptly" & "nikwi" from unstable/amd64: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/esajpip.html >

Re: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output

2016-09-05 Thread Ximin Luo
Chris Lamb: > Hi Ximin, > >> https://people.debian.org/~infinity0/res/dfs-demo/index.html > > One quick bit of feedback is that the: > >" ... load diff (3 pieces, truncated) ... " > > links aren't always immediately obvious to my eyes/colour scheme. > > Indeed, I am sure I found find

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-05 Thread Ximin Luo
HW42: > Ximin Luo: >> [..] >> >> 1. Patch GCC to set debug-prefix-map to "$pwd=." by default (and the >> analogue for other languages / tools). >> >> This behaviour is concretely different from the current situation: >> during recurs

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-06 Thread Ximin Luo
HW42: > Ximin Luo: >> However the question is, do we want to do this every time an upstream >> saves CFLAGS somewhere? > [...] >> 2. Define another variable SOURCE_ROOT to be set to the top-level >> source dir, and patch GCC to use this as the default

Re: Bug#836784: diffoscope: Several "Too much input for diff" on debian packages from unstable/amd64

2016-09-06 Thread Ximin Luo
Holger Levsen: > Hi Ximin, > > On Mon, Sep 05, 2016 at 05:32:00PM +0000, Ximin Luo wrote: >> Hi Emanuel, try setting the --max-diff-input-lines flag to a higher value. >> In the next version we'll let "0" mean "unlimited" as well as having a >

Re: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output

2016-09-08 Thread Ximin Luo
Chris Lamb: >> Do you have a concrete suggestion? Otherwise I will just turn the >> background light pink, #f99. > > Something like that, although I'm not quite a fan of pink… > > I would definitely increase the padding and — to use a UI/UX term — to > increase the affordance that they are

Re: python-popcon source package counts

2016-09-13 Thread Ximin Luo
Hi all, I've uploaded this to DELAYED/12, the commits are here: https://github.com/infinity0/python-popcon I also took this chance to fix the existing RC bugs. X Ximin Luo: > Hi Bastian, > > I'm wondering if you could get around to this pull request soon? > > https://git

Re: Draft of blog post for week 72 in blog.git

2016-09-12 Thread Ximin Luo
Chris Lamb: >> (I've added two bits about t.r-b.o.) > > ACK, thank you. > >> looks nice & thanks for giving some time to review! > > Well, I would never publish without any review - just would prefer to > have given more! :) > > I regrettably ended up delaying further and have just published.

Re: Build path variation and __FILE__

2016-09-12 Thread Ximin Luo
HW42: > Sascha Steinbiss: >> a) Introducing something like -ffile-prefix-map similarly to >> -fdebug-prefix-map to address this issue. There is already an >> unreviewed patch for gcc submitted by an unrelated party [3] and I >> could try and raise awareness for this bug with the GCC devs. However,

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-12 Thread Ximin Luo
Daniel Kahn Gillmor: > On Fri 2016-09-09 01:33:00 +0200, HW42 wrote: >> According to codesearch.d.n it seems only SOURCE_DIR_ROOT isn't taken >> yet. (Google finds at least one case). > > thanks for looking, that's what i should have done in the first place. > >> also bikeshedding: I dislike

python-popcon source package counts

2016-09-12 Thread Ximin Luo
Hi Bastian, I'm wondering if you could get around to this pull request soon? https://github.com/venthur/python-popcon/pull/2 We would like it to make this page more accurate: https://tests.reproducible-builds.org/index_issues.html At the moment we are assuming that source and binary packages

Re: -fdebug-prefix-map

2016-10-06 Thread Ximin Luo
Samuel Thibault: > Hello, > > I have noticed that for reproducibility, gcc is now given > >-fdebug-prefix-map=/build-2nd/the-package-1.0=.· > > to avoid the debugging symbols to be depending on the path where the > package is built. But I'd say it can be really useful to have the >

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-19 Thread Ximin Luo
HW42: > Ximin Luo: >> Ximin Luo: >>> I'm going to suggest SOURCE_ROOT_DIR [..] >> >> OTOH, taking into account dkg's earlier point about overloading >> "root", perhaps SOURCE_BASE_DIR would be better. >> >> It is used quite heavily: >&g

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-17 Thread Ximin Luo
Ximin Luo: > I'm going to suggest SOURCE_ROOT_DIR [..] OTOH, taking into account dkg's earlier point about overloading "root", perhaps SOURCE_BASE_DIR would be better. It is used quite heavily: https://codesearch.debian.net/search?q=\bSOURCE_BASE_DIR\b but only by cmake

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-17 Thread Ximin Luo
HW42: >> I preferred the ${x}dir style instead of dir_${x} or ${x}_dir because >> of some existing conventions like >> >> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html > > Well, OTOH, freedesktop.org uses _DIR: > >

Please review blog post week 75 draft

2016-10-03 Thread Ximin Luo
https://reproducible.alioth.debian.org/blog/drafts/75/ Thanks in advance, X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Reproducible-builds mailing list

Re: misleading timestamps in binnmus

2016-11-08 Thread Ximin Luo
Ian Jackson: > I have just had my backups fail due to the following chain of events: > > * I had python2.7-stdlib:amd64 2.7.12-3 installed > * I did a backup > * I upgraded to python2.7-stdlib:amd64 2.7.12-3+b1 was built > * I did another backup, during which: > * Many files were not copied

Bug#843811: strip-nondeterminism: does not strip nondeterminism from /SYM64/ ar entries

2016-11-09 Thread Ximin Luo
Package: strip-nondeterminism Version: 0.028-1 Severity: important Dear Maintainer, strip-nondeterminism does not strip the /SYM64/ timestamp from the attached files, which are produced by building the glibc source package. This is probably also a bug in binutils, but I will need to check the

Bug#843925: dpkg-dev: dpkg-buildpackage should sign buildinfo files

2016-11-10 Thread Ximin Luo
Package: dpkg-dev Version: 1.18.13 Severity: important Dear Maintainer, We would like dpkg-buildpackage to clearsign the buildinfo files that are created. This allows them to be uploaded to services similar to keyservers, for auditing and attestation purposes, that may be run independently of

Re: Trial git-based task list

2016-11-10 Thread Ximin Luo
Holger Levsen: > Hi, > > I'm sorry if this sounds dismissive, but this thread (and evaluation) > has shown me, that being decentralised is not a feature I desire in a > tracker, on the contrary, it seems that decentralised has downsides > making me wish for a centralized tracker which I can use

Re: dietlibc; build path issue on ARM despite -fdebug-prefix-map

2016-11-05 Thread Ximin Luo
Christian Seiler: > [..] > > It appears as though gcc hard-codes the path for the startup file > on armhf, while it doesn't do so on x86. A simple way to try this > out, even without dietlibc: > > cat > hello.c < #include > > int main() > { > puts("Hello World!"); > return 0; > } > EOF

Re: Trial git-based task list

2016-10-24 Thread Ximin Luo
Daniel Shahaf: > Ximin Luo wrote on Mon, Oct 24, 2016 at 19:54:00 +: >> $ git pull >> $ ./task add "Some stuff" >> $ ./task add priority:H "Some more important stuff" >> $ git push > > And suppose the push gives an error because somebody el

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-24 Thread Ximin Luo
Daniel Kahn Gillmor: > On Mon 2016-10-24 16:18:00 -0400, Ximin Luo wrote: >> Almost, with two minor corrections: >> >> I picked SOURCE_ROOT_DIR; SOURCE_ROOT has 6395 pages of results in >> sources.debian.net and I didn't want to check that none of these are >>

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-25 Thread Ximin Luo
Ximin Luo: > [..] I was trying to come to agreement on the exact form the proposal should > take. > > The behaviour is already settled: > > if path.startswith(R): > newprefix = P or "." > path = newprefix + path[len(R):] > > [..] What I'm asking is

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-24 Thread Ximin Luo
Daniel Kahn Gillmor: > On Mon 2016-10-24 15:33:00 -0400, Ximin Luo wrote: >> HW42: >>> Btw: Do you know why currently debug-prefix-map maps the source dir to >>> '.'? (My guess is because that's the easiest in dpkg-buildflags) I think >>> for debugging

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-24 Thread Ximin Luo
HW42: > Daniel Kahn Gillmor: >> On Tue 2016-09-06 16:02:00 -0400, Ximin Luo wrote: >>> Thanks, I did see this a while ago and forgot about it. However it >>> does differ from the current proposal in an important way. >>> >>> Current proposal (2): GC

Trial git-based task list

2016-10-24 Thread Ximin Luo
Hey all, I prepared a basic issue tracker here: https://anonscm.debian.org/cgit/reproducible/tasks.git You can clone it, install taskwarrior, then work with it like $ git pull $ ./task add "Some stuff" $ ./task add priority:H "Some more important stuff" $ git push More docs are available in

Buildinfo in the Debian archive, updates

2016-11-14 Thread Ximin Luo
This email is a summary of some discussions that happened after the last post to bug #763822, plus some more of my own thoughts and reasoning on the topic. I think having the Debian FTP archive distribute unsigned buildinfo files is an OK intermediate solution, with a few tweaks: 1. the hashes

Please review draft for week 81's blog post

2016-11-14 Thread Ximin Luo
https://reproducible.alioth.debian.org/blog/drafts/81/ Feel free to commit fixes directly to drafts/81.mdwn in https://anonscm.debian.org/git/reproducible/blog.git/ I will publish this in 24 hours. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE

Re: Buildinfo in the Debian archive, updates

2016-11-14 Thread Ximin Luo
Ximin Luo: > [..] > > Now then, why does the FTP archive need to distribute buildinfo files at all? > It can simply store the signed files and distribute the hashes. Then > rebuilders > (people that want to verify our reproducibility claims) can download the > hashes &g

Please review draft for week 83's blog post

2016-11-28 Thread Ximin Luo
https://reproducible.alioth.debian.org/blog/drafts/83/ Short one this week, mostly because I did next to nothing (was moving apartment). Will be working much more this week :) Feel free to commit fixes directly to drafts/83.mdwn in https://anonscm.debian.org/git/reproducible/blog.git/ I will

Bug#846164: dpkg-dev: Have dpkg-genchanges support a source+buildinfo-only upload

2016-11-28 Thread Ximin Luo
Package: dpkg-dev Version: 1.18.15 Severity: wishlist Dear Maintainer, Currently one can do $ dpkg-buildpackage --changes-option=-S to do a binary build locally, but only upload the source package so that buildds build on all arches. Note that this command *does* generate a buildinfo file,

Re: Bug#821793: fusermount should not attempt to use /etc/mtab

2016-11-16 Thread Ximin Luo
Nikolaus Rath: > Can someone clarify if this is a bug in upstream fuse (which assumes > existence of /etc/mtab) or in the software that creates the chroots > without /etc/mtab? > > If someone can give me a decent source that states that /etc/mtab does > not need to exist, I'll be happy to change

Bug#844420: FTBFS: tests fail on hosts without network access

2016-11-15 Thread Ximin Luo
in all cases and the test returns 2. . Normally, such systems can still resolve "localhost." via nsswitch/getent and getaddrinfo is not suppose to attempt resolution of "localhost." anyways. Author: Ximin Luo <infini...@debian.org> Bug: TBD --- This patch header follows DE

Bug#844512: reprotest: make diffoscope optional

2016-11-16 Thread Ximin Luo
Package: reprotest Version: 0.3.2 Severity: wishlist Dear Maintainer, It would be good to make diffoscope optional. Sometimes for various reasons a developer might want to run reprotest inside a container/chroot/environment where they don't want to install diffoscope. Then reprotest should save

  1   2   3   >