builder or
>>> sbuild/pbuilder use a common tool to figure out the right lines for the
>>> sources.list inside the chroot. I just want to have .buildinfo support for
>>> sbuild in Stretch and if either solution is not in unstable soon, then my
>>> plan is to just ad
Johannes Schauer:
> Hi,
>
> On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <jo...@debian.org> wrote:
>> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <jo...@debian.org> wrote:
>>> But then on IRC, HW42 suggested to approach this problem dif
the source package now depends on
>>the exact right package versions and let the resolver figure out the rest
>>(thanks Benjamin for that idea)
>> - check whether the generated binaries produce the same checksum as given in
>>the supplied buildinfo f
Sebastian Humenda:
> Hi all
>
> I'd like to report and discuss with you an issue that I'm having with the
> reproducible builds page, linked from the QA page of a package of mine.
> My package, freedict, is affected by "unstable" builds. I suppose that's
> because
> the build time stamp is
Chris Lamb:
> Hey Johannes,
>
>> Multiple builds of the same source package will set SOURCE_DATE_EPOCH to
>> the same value but will result in a different Build-Date.
>
> ā¦ but that would mean that a reproducible build will result in .buildinfo
> files with different contents (varying on
Johannes Schauer:
> Hi,
>
> On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <jo...@debian.org> wrote:
>> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <jo...@debian.org> wrote:
>>> But then on IRC, HW42 suggested to approach this problem dif
Mattia Rizzolo:
> On Mon, Nov 07, 2016 at 01:41:00PM +0000, HW42 wrote:
>> I removed the filter from Reiner and replaced it with a 'sed' filtering
>> out the .buildinfo entries from the .changes file. So diffoscope should
>> not compare the .buildinfos (and the files re
Mattia Rizzolo:
> On Sun, Nov 06, 2016 at 10:04:00PM +0000, HW42 wrote:
>> (As I wrote an hour ago on irc,) See last 3 commit at
>> https://anonscm.debian.org/git/users/hw42-guest/jenkins.debian.net.git/
>
>
>> commit fdb7a50073ef9e3b8d22176b63817a78c928d73c
>&g
Chris Lamb:
> HW42 wrote:
[...]
>>> +Subkey-Type: ELG-E
>>> +Subkey-Length: 1024
>>
>> Huh?
>
> Suggestions welcome. I cribbed it from the internet.
[...]
> Just to re-iterate ā and I hope this comes across the right way! ā but
> the current state
> +sign_buildinfo() {
> + # Greate GPG key if it does not already exist
> + if ! gpg --list-secret-keys | grep -qs '^sec' >/dev/null 2>&1
Is this ever called concurrently?
> +Subkey-Type: ELG-E
> +Subkey-Length: 1024
Huh?
> mail -s "buildinfo from $NODE1"
Daniel Kahn Gillmor:
> On Tue 2016-10-25 08:29:00 -0400, Ximin Luo wrote:
>> Option A
>>
>> oldprefix = getenv("SOURCE_ROOT_DIR")
>> newprefix = getenv("SOURCE_ROOT_PREFIX") or "."
>>
>> Pros: Simple, easy to understand. Works almost exactly as
>> debug-prefix-map which has
Leo Famulari:
> On Fri, Oct 21, 2016 at 04:23:51PM +, Mattia Rizzolo wrote:
>> Though I'm using pytest 3.0.3.
>> That test is skipped by using pytest.mark.skip(), which I don't see in
>> the docs of pytest for 2.7.
>> The changelog of pytest tells me pytest.mark.skip() is recognized as a
>>
Daniel Shahaf:
> It would be better to report "json files are equal up to order of
> elements in an object (= hash, dictionary, associative array)", and to
> print the difference in a more readable way than a hex dump. (For
> example, a linewise diff of pretty-printed json.)
While at it, it
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
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
Holger Levsen:
> On Thu, Sep 15, 2016 at 04:38:00PM +0000, HW42 wrote:
>>> 3.16.0-4-amd64 is the kernel (so jessie standard), and the host this is
>>> running on is a profitbricks VM, so running on kvm.
>> I assume you have this kernel only installed on the VM not the c
Holger Levsen:
> On Thu, Sep 15, 2016 at 02:58:00PM +0000, HW42 wrote:
>> It fails to find a kernel for the VM image it creates on the fly:
>
> ah, wow.
>
>> diffoscope-qubes-debug:
>>> supermin: failed to find a suitable kernel (host_cpu=x86_64).
>
Holger Levsen:
> On Tue, Sep 13, 2016 at 03:35:58PM +0200, Holger Levsen wrote:
>> so I build an Qubes ISO, twice and ran diffoscope against it:
>
> just now I enabled debugging like this:
>
>> To see full error messages you may need to enable debugging.
>> Do:
>> export LIBGUESTFS_DEBUG=1
Since guestfs works by running a modified kernel in an VM to parse the
file system, I think it fails to start the VM (nested virt disabled,
OOM, ...).
So I think you should first try if guestfs works at all (without
diffoscope) and/or enable the debug loggin like suggested in the error
message.
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 ha
Chris Lamb:
>> Then I'd have expected it to fail also in the buildds...
>
> Oh, it *doesn't* fail in the buildds? Weird.
>
> Still, given that it's *this* particular test that fails it's almost
> certainly something along the lines I previously suggested (this test
> is deliberately designed to
Sascha Steinbiss:
> Hi all,
>
> Iād like to contribute to the build path discussion as well with a few
> observations I made when trying to fix reproducibility problems
> related to that in my packages. In addition to the problem already
> raised by Ximin concerning upstream storing CFLAGS in
Chris Lamb:
> tag 836732 + pending
> thanks
>
>> Not sure how much related they are, but I guess it means something given
>> that it's not in the English build.
>
> I don't really understand why that would be causing an error but we follow
> your assumption that the "return" that is causing the
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
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 for
> debug-prefix-map (and the analogue for other
Ximin Luo:
> Hi all,
>
> I'm thinking of ways to minimise the work needed to fix the build path
> issues that we're having.
>
> The present method is that dpkg-buildflags sets
> "-fdebug-prefix-map=$PWD=." into various *FLAGS envvars, and Make (or
> another build tool) will pass this to gcc.
Chris Lamb:
> Holger wrote:
>
>> I think regarding Debian releases, I'd recommend that we aim for
>> partially reproducible packages given known build paths
>
> I agree. We should, regrettably, define a fixed build path for stretch
> at this point in the release cycle.
I want to note that this
Thomas Schmitt:
> A new source of irreproducibility appeared: Future xorriso versions.
>
[...]
>
> I will of course try to keep such changes as rare as possible. But it
> cannot be totally guaranteed that the same input data and options will
> yield the same ISO with future versions of xorriso.
Daniel Kahn Gillmor:
> On Sun 2016-06-12 23:25:33 -0400, HW42 wrote:
>> as Mattia noticed dpkg-buildflags doesn't escape the build path in the
>> -fdebug-prefix-map CC argument when enabling the 'fixdebugpath' option.
>>
>> What assumptions does dpkg make ab
in different languages
(shell, Makefile). So if we want to support spaces in buildpaths this
need to be changed to an array. What do you think?
HW42
signature.asc
Description: OpenPGP digital signature
___
Reproducible-builds mailing list
Reproducible-builds
20160613T013823z-ff7bd155
The attached patch fixes this and should be stashed into the buildinfo
patch.
HW42
[0]:
https://anonscm.debian.org/git/reproducible/dpkg.git/commit/?id=0774d0244c94733d1480f7c246085ef02196f71a
[1]:
https://anonscm.debian.org/git/reproducible/dpkg.git/tree/scripts/Dpkg
, HW42
diff -urN a/debian/rules b/debian/rules
--- a/debian/rules 2016-06-13 01:27:12.0 +0200
+++ b/debian/rules 2016-06-13 01:20:28.447939088 +0200
@@ -46,7 +46,7 @@
touch configure
(cd build-tmp && CC='$(CC)' \
CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' LDFLAGS='$
image format which embeds timestamps which aren't set to
SOURCE_DATE_EPOCH [2]. See attached patch to fix this (might need some
cleanup before upstreaming).
[2]:
https://sources.debian.net/src/u-boot/2016.07~rc1%2Bdfsg1-1/tools/fit_image.c/#L55
HW42
--- a/tools/default_image.c
+++ b/tools/defau
Hi,
I think the current suite/arch list is a bit unintuitive since it is not
clear which suite/arch are built and which is currently shown.
See attached patches for a proposal to make it a bit nicer.
HW42
From be75eced896ff097ac68f510fd98be93aa5f8725 Mon Sep 17 00:00:00 2001
From: HW42 h
Chris Lamb:
After reading the disorderfs manpage I wonder if it's really already
suitable to build everything
This is a little awkward for me as I raised these concerns a couple of
times during the BoF but I did not want to temper anyone's enthusiasm in
the room. I therefore did not labour
Andrew Ayer:
On Wed, 26 Aug 2015 10:58:08 +0200
HW42 h...@ipsumj.de wrote:
Errors from close are not properly reported.
Probably don't hurt. Most programs ignore them anyway.
I think close() only fails if there's a disk error or you run out of
disk space/quota. Neither of these should
speculation (the only proper thing is
probably a (partial) archive rebuild to see what happens)
HW42
signature.asc
Description: OpenPGP digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http
37 matches
Mail list logo