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:
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'
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
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
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
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
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
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
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
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
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
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
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:
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,
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
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
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
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
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
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
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
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
+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.
>
>
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
> 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
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
(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
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
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
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
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
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
(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
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) +%
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
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
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
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
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
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
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.
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
>
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
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.
>
>
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...
>
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…
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
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:
---
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
&
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
>
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
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
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
>
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
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
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.
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,
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
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
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
>
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
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
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:
>
>
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
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
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
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
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,
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
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
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
Control: affects -1 disorderfs
Control: affects -1 devscripts
Control: affects -1 reprotest
debrepro from devscripts, and reprotest, both use disorderfs. When cleaning up
a build, they try to unmount the disorderfs filesystem using `fusermount -u`
which doesn't work inside an schroot since it
Daniel Kahn Gillmor:
> Hi all--
>
> On Mon 2016-11-14 12:13:00 -0500, Ximin Luo wrote:
>> A GPG signature with a 4096-bit key is about 800 bytes in base 64:
>>
>> http://ftp.debian.org/debian/dists/sid/ (has 2 signatures, if you use `gpg
>> --list-packets`)
>
Chris Lamb:
> Ximin Luo wrote:
>
>> This minimal solution still depends on 3rd-party services being available to
>> host the files. A much better solution is for the FTP archive to *also* store
>> the signed buildinfo files, somewhere safe that can be recovered when needed
Ximin Luo:
> Daniel Kahn Gillmor:
>> On Thu 2016-10-27 11:18:00 -0400, Ximin Luo wrote:
>>> So, I can implement option B fairly easily, but there is one ugly fact
>>> about the syntax that we should think about. The way that GCC does it,
>>> it means you can't
1 - 100 of 217 matches
Mail list logo
