python-popcon source package counts

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 a

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

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. A

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

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 SOUR

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

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 someth

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

Daniel Kahn Gillmor: > On Wed 2016-08-24 07:20:00 -0400, Ximin Luo wrote: >> 2. Define another variable SOURCE_ROOT to be set to the top-level >> source dir, and patch GCC to use this as the default value for >> debug-prefix-map (and the analogue for other languages / tools).

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

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: [Reproducible-builds] Minimising work needed for this build-path issue

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 value fo

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

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: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output

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 mysel

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

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 > https://tests.reproducible-builds.org/debian/

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

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: [Reproducible-builds] More lazy-loading for diffoscope html output

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 I

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

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 a

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

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

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

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*

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

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 largel

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

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 signatur

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

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 <87vb

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

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 wi

[Reproducible-builds] Reprotest week 59 blog comments

> 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 definition

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

Thorsten Glaser: > Ximin Luo dixit: > >> needs to more clearly distinguish between the build and the host >> environment - like how compilers do. So for example, here the "most >> correct" solution would be to add a HOST_POSIX_SHELL and default this >

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

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,

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

(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 i

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

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 system

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

+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] Better popcon stats for source packages

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

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

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/

[Reproducible-builds] Better popcon stats for source packages

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 th

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

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

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

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 p

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

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] Bug#824182: codeblocks: please make the build reproducible (timestamps)

Fabian Wolff: > [1] says that setting and exporting SOURCE_DATE_EPOCH in debian/rules > is "a last resort to be avoided where possible", but I guess that if > we export with ?=, it should be fine. > > [..] > > [1] > https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Setting_the_variab

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

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] Bug#824182: codeblocks: please make the build reproducible (timestamps)

(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 @$(SOURCE

Re: [Reproducible-builds] SORCE_DATE_EPOCH_TEX_PRIMITIVES

(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,

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

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 mayb

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

Jérémy Bobbio: > 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" > > Grea

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

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 deci

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

Satyam Zode: > Hi, all ! > I am Satyam Zode, I am GSoC student intern (http://satyamz.github.io > /blog/2016/05/08/google-summer-of-code-2016-with-debian > -reproducible-builds-introduction/). > I am trying to understand the problem "Allow users to ignore arbitrary > differences" ( --ignore-profil

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

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/56034877E1

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

2001 From: Ximin Luo 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 count of that, as

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

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

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

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 S

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

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] .buildinfo should contain source hashes (as well as binary hashes)

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] .buildinfo should contain source hashes (as well as binary hashes)

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

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

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, /bin

Re: [Reproducible-builds] SOURCE_DATE_EPOCH specification document

On 27/08/15 15:57, Ximin Luo wrote: > > In the meantime I'll push some other minor edits too. > I ended up making some more changes, rewording some things, adding considerations of more corner cases on implementors' sides, and more precise language from RFC 2119. Feel fre

Re: [Reproducible-builds] SOURCE_DATE_EPOCH specification document

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: > > https://reproducible.debian.net/specs/sour

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

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

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

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 th

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

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 i

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

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 differ

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

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 exi

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

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/

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

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 base

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

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 forma

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

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 coul

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

On 10/06/15 12:58, Brendan O'Dea wrote: > On 10 June 2015 at 20:54, Ximin Luo wrote: >> On 10/06/15 12:41, Brendan O'Dea wrote: >>> On 10 June 2015 at 01:59, Ximin Luo wrote: >>>> SOURCE_DATE = "$(date -d "$(dpkg-parsechangelog --count 1 -SD

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

On 10/06/15 12:41, Brendan O'Dea wrote: > On 10 June 2015 at 01:59, Ximin Luo wrote: >> Given the above, I think it would still be good to define SOURCE_DATE as I >> originally suggested: >> >> SOURCE_DATE = "$(date -d "$(dpkg-parsechangelog --count 1 -S

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

On 06/06/15 16:39, Holger Levsen wrote: > Hi, > > On Freitag, 5. Juni 2015, Daniel Kahn Gillmor wrote: >> My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should >> take the opportunity to define this as strictly and narrowly as possible >> (i.e. end in a 'Z', none of the other off

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

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 B

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

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' > 2015-06-04T13

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

On 09/04/15 11:08, Mattia Rizzolo wrote: > On Apr 9, 2015 10:37 AM, "Holger Levsen" > 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: https://gitweb.torproje

[Reproducible-builds] General plan for reproducible timestamps in documentation

TL;DR: see https://gitweb.torproject.org/debian/flashproxy.git/diff/?id=92add337b86303a1&id2=8f7d498ac729086c^ The idea: 1. We have dh (and/or other tools) set a standard environment variable, SOURCEDATE, according to the package's changelog 2. We create wrappers that use "faketime -f" to run v

<    1   2   3