Holger Levsen:
> On Wed, Dec 27, 2017 at 05:03:11PM +0100, Holger Levsen wrote:
>> On Tue, Dec 26, 2017 at 08:56:18AM +, Chris Lamb wrote:
>>> I believe there are enough people in (or around) our community who dislike
>>> Github (for a variety reasons not productive to debate/repeat again
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/139/
Feel free to commit fixes directly to drafts/139.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/137/
Feel free to commit fixes directly to drafts/137.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
https://reproducible.alioth.debian.org/debian/ocaml_4.05.0-10.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Axel Beckert:
> [..]
>
> Even "--fuzzy-threshold 0" to disable any "fuzzy-matching" (whatever
> that is in the context of diffoscope) didn't make a difference.
>
Actually, the problem is the other way round - control.tar.{gz,xz} have
different names and the contents aren't similar enough (I
Mike Hommey:
> On Thu, Oct 19, 2017 at 07:15:35PM +0900, Mike Hommey wrote:
>> Attached is my work in progress. I won't finish it right now because
>> it's getting late and I don't have all the optional tools to run the
>> test suite.
>>
>> It's worth noting that this changes the output, and the
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/135/
Feel free to commit fixes directly to drafts/135.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
https://reproducible.alioth.debian.org/debian/r-base_3.4.2.20171120-1.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Package: dpkg-dev
Version: 1.19.0.4
Severity: wishlist
Tags: patch
Dear Maintainer,
dpkg-buildpackage currently does not automatically list the source .dsc nor
its hash in the call to dpkg-genbuildinfo when doing a binary-only build. This
is understandable because in a binary-only build,
Holger Levsen:
> On Thu, Nov 16, 2017 at 10:06:00AM +0000, Ximin Luo wrote:
>> Ping, are you ready? I don't see any commits from you in the log...
>
> not yet & on a very bad internet connection atm.
>
> i will publish 133 once it's ready.
>
Hey, just a reminder tha
Lisandro Damián Nicanor Pérez Meyer:
> By the way: is there a macro or combination of macros which *default* value
> can be replaced in the use of __FILE__ without caussing regressions?
>
> Because if that's the case it's easier to convince upstream people that
> changing the usage goes in
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Yes, we do understand that your workaround solves the issue, but we do also
> understand that we should not be using this workaround in the first place.
>
> Guillem: the thread is long, but be sure that we Qt/KDE maintainers consider
> that this
Holger Levsen:
> On Tue, Nov 14, 2017 at 01:34:00PM +0000, Ximin Luo wrote:
>> This week's blog post draft is now available for review:
>> https://reproducible.alioth.debian.org/blog/drafts/133/
> [...]
>> I'll wait at least 24 hours from the time of thi
Lisandro Damián Nicanor Pérez Meyer:
> On miércoles, 15 de noviembre de 2017 20:35:00 -03 Ximin Luo wrote:
>> Lisandro Damián Nicanor Pérez Meyer:
>>> I was wanting to write this on a keyboard, but let me try on the phone and
>>> see if we can all agree in one
Lisandro Damián Nicanor Pérez Meyer:
> I was wanting to write this on a keyboard, but let me try on the phone and
> see if we can all agree in one point.
>
> There is one *excellent* method to settle this once and forever: submit the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and
Pino Toscano:
> [..]
>
>> In summary: in no document or standard, does it guarantee or imply
>> that __FILE__ can be taken to represent a real filesystem path.
>> Applications relying on this behaviour are broken and should not be
>> upset when things don't work. As documented in multiple places,
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Xi: you also mentioned that having to file hundreds of patchs seems
> impossible. Well, it seems so, but it is actually not that necessary. Please
> allow me to explain the idea.
>
Thanks for being less inflammatory than Pino.
I agree that
Pino Toscano:
> In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
>> You're using __FILE__ inappropriately, none of the documentation
>> guarantees or implies that you can access __FILE__ as a real
>> filesystem path. "Surely for relative paths" is
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/133/
Feel free to commit fixes directly to drafts/133.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Sorry, it is not realistic to force us to have a delta from upstream for no
> direct gain.
>
None of the solutions I suggested involve patching upstream, they would be done
in d/rules.
X
--
GPG: ed25519/56034877E1F87C35
GPG:
Pino Toscano:
> [..]
>
>> Well let's take a look at the standards:
>> [...]
>
> Even with different wordings, both describe basically the same
> behaviour. And yes, none of them says that __FILE__ is a full path,
> but surely for relative paths the combination of $srcdir + __FILE__
> will give
Pino Toscano:
> [..]
>
> This is not an annoyance, it is the crux of the problem! __FILE__ is
> something standard, with a very well defined behaviour, upon which
> people rely on: you cannot trash it from one day to another like this,
> saying "too bad" to all its users, even those using it
Pino Toscano:
> [..]
>
> A better approach here is to work on removing the invalid & abusing
> usages of __FILE__ from packages, just like it was done for __DATE__.
>
We in fact did not do the latter because it was easier to implement
SOURCE_DATE_EPOCH to fix the expansion of __DATE__, rather
Pino Toscano:
> [..]
>
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>QFINDTESTDATA)
>
>> I am not "blaming the user", but pointing to the fact that __FILE__
>> is being used in a surprising way here, which is not
Ximin Luo:
> [..]
>
> (maybe there are other options)
>
If all the test files reside underneath the same directory, like tests/, you
could:
4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests".
This should make the tests pass, whilst keeping
Ximin Luo:
> Ximin Luo:
>> [..]
>>
>> (maybe there are other options)
>>
>
> If all the test files reside underneath the same directory, like tests/, you
> could:
>
> 4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR
Adrian Bunk:
> Control: reassign -1 qtbase5-dev
> Control: reassign 876917 qtbase5-dev
> Control: reassign 876933 qtbase5-dev
> Control: forcemerge -1 876917 876933
> Control: retitle -1 QFINDTESTDATA uses __FILE__
> Control: severity -1 normal
> Control: affects -1 src:karchive src:ki18n
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/131/
Feel free to commit fixes directly to drafts/131.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
https://reproducible.alioth.debian.org/debian/r-base_3.4.2-2.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
gregor herrmann:
> [..]
>
> So I guess I'll stay with excluding domain_host for now.
>
> [..]
>
> It looks like currently both 0 and 1 cause problems :)
>
Yes, I've experienced this too. :( I'm hitting what I think might be a bug with
nsenter(1), but I have a potential workaround. It'll take
gregor herrmann:
> [..]
>
> I've now built a package from git HEAD (3efb86f), and .. hm .. I guess
> this bug is fixed, it's just that I'm running into another issue
> which seems related to another recent commit (the domain_host
> feature):
>
> [..]
>
> The recommended `echo 1 >
gregor herrmann:
> [..]
>
> So currently I have:
>
> - reprotest called as
> env -u TMPDIR -- reprotest --variations=+all,-build_path,-user_group
> --verbosity 1 . -- schroot default 2>&1 | [..]
>
Thanks, this helped me reproduce the bug locally. I was having trouble before,
because the
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/129/
Feel free to commit fixes directly to drafts/129.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
https://reproducible.alioth.debian.org/debian/r-base_3.4.2-1.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Daniel Kahn Gillmor:
> On Thu 2017-10-12 03:02:49 +0100, Chris Lamb wrote:
>
>> The GitHub repositories are read-only mirrors. If you are checking out
>> the code as a member of the Reproducible Builds team, then it makes more
>> sense to get it from Alioth, for example:
>>
>> $ git clone
gregor herrmann:
> [..]> dpkg-buildpackage: error: fakeroot not found, either install the
> fakeroot
> package, specify a command with the -r option, or run this as root
> [..]
>
> This seems to be related to the "sudo" use in the output above (or
> the funny output in the first line?), or
>
>
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/127/
Feel free to commit fixes directly to drafts/127.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
Mattia Rizzolo:
> [..]
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line
> 102, in control
> control_file =
> self.as_container.control_tar.as_container.lookup_file('./control')
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line
> 78,
Russ Allbery:
> [..] It does mean that discovery of any new
> such environment variable would require a change to our whitelist in
> approach (3), so there would be some lag and the whitelist would become
> long over time (with a corresponding testing load). But (3) does try to
> achieve that
Simon McVittie:
> On Mon, 18 Sep 2017 at 18:00:51 -0700, Vagrant Cascadian wrote:
>> [..]
>>
>> I consider unintended variables that affect the build output a bug, and
>> variables designed and intended to change the behavior of the toolchain
>> expected, reasonable behavior.
>
> There is a
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/125/
Feel free to commit fixes directly to drafts/125.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
https://reproducible.alioth.debian.org/debian/gcc-7_7.2.0-8.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
https://reproducible.alioth.debian.org/debian/gcc-7_7.2.0-3.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/123/
Feel free to commit fixes directly to drafts/123.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for
Vagrant Cascadian:
> On 2017-08-16, Ximin Luo wrote:
>> It looks like the GCC reviewer that looked at my patch this time
>> around, really doesn't like environment variables. They seem to be
>> happy to support the variable (including the syntax) as a command
Russ Allbery:
> Ximin Luo <infini...@debian.org> writes:
>
>> Fair enough. I actually spotted that but thought it was better to get
>> "something" into Policy rather than nitpick. I guess other people were
>> thinking similar things. Well, lesson lear
Bill Allombert:
> On Tue, Aug 15, 2017 at 07:49:55PM +, Holger Levsen wrote:
>> Also what you are saying ("a package that is reproducible according to the
>> policy definition must not show up as non-reproducible in tracker/DDPO based
>> on results from the reproducible infrastructure") doesnt
Hi list,
It looks like the GCC reviewer that looked at my patch this time around, really
doesn't like environment variables. They seem to be happy to support the
variable (including the syntax) as a command-line flag however.
The original patch fixed ~1800 packages, which were unreproducible
Federico Brega:
> Hello,
>
> I'm packaging an application making use of pyrcc5 and I noticed the
> nondeterminism it adds.
> I see[1] that this is currently description is not correct.
> You can see that pyrcc5 uses QHash, which is made to avoid algorithmic
> complexity attacks[2]
> introducing a
Sean Whitton:
> [..]
>
> Here is an updated patch addressing these. I reworded it to use
> 'recommended' and changed the tone to better suit policy.
>
> Thank you Ximin, Russ and Johannes!
>
>> "precisification" -> "more precise version"
>
> Our definition is not actually a /version/ of the
>
https://reproducible.alioth.debian.org/debian/gcc-7_7.1.0-13.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
https://reproducible.alioth.debian.org/debian/gcc-7_7.1.0-12.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/117/
Feel free to commit fixes directly to drafts/117.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
Control: tags -1 - pending
Hans-Christoph Steiner:
> [..]
>
> I'd like a way to force the file type in diffoscope. We are calling it
> from a build process, so we already know all files are going to be APKs.
> Also, I tried to get this added to libfile, but upstream is not willing
> to accept
r-base_3.4.1-2.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/115/
Feel free to commit fixes directly to drafts/115.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
Eric Dorland:
> Hi folks,
>
> I was trying to fix some unreproduciblity issues with automake and the
> problem of version.texi came to my attention and I haven't seen it
> come up before, but let me know if I just couldn't find it.
>
> According to
>
gcc-6_6.4.0-1.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
The current version of xz-utils built in current unstable does not seem to be
affected by this issue. Possibly we fixed gettext in the meantime to generate
reproducible timestamps.
It is still affected by #806331 for which I've already written a patch.
X
--
GPG: ed25519/56034877E1F87C35
GPG:
Package: diffoscope
Version: 83
Severity: wishlist
Dear Maintainer,
Several times people on IRC have asked about reprotest reporting file
permissions
differences when building files. This can be reproduced trivially:
$ reprotest 'touch x' x
[..]
│ │ │ -Access: (0644/-rw-r--r--) Uid: (
r-base_3.4.0.20170622-1.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/113/
Feel free to commit fixes directly to drafts/113.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
Adrian Bunk:
> On Thu, Jun 22, 2017 at 08:26:00AM +0000, Ximin Luo wrote:
>> ...
>> One way to give security that is independent of third parties, is to provide
>> some sort of mathematically-verifiable proof. However the world isn't at
>> that stage yet for com
Adrian Bunk:
> On Wed, Jun 21, 2017 at 10:09:00AM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> [..]
>>>
>>> How is that supposed to work when the compiler is not exactly identical?
>>>
>>> As an example, gcc-6 6.3.0-18 and gcc-6 6.3.0-19 w
Adrian Bunk:
> On Wed, Jun 21, 2017 at 09:28:00AM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote:
>>>> Hi Ian--
>>>>
>>>> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote:
&
gcc-6_6.3.0-19.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/111/
Feel free to commit fixes directly to drafts/111.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
Ximin Luo:
> Ximin Luo:
>> Package: diffoscope
>> Version: 78
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> diff(1) first reads the contents of one file then the next one:
>>
>> https://sources.debian.net/src/diffutils/1:3.5-3/src/io.
Ximin Luo:
> Package: diffoscope
> Version: 78
> Severity: normal
>
> Dear Maintainer,
>
> diff(1) first reads the contents of one file then the next one:
>
> https://sources.debian.net/src/diffutils/1:3.5-3/src/io.c/#L552
>
> This means that if the &qu
Package: diffoscope
Version: 78
Severity: normal
Dear Maintainer,
diff(1) first reads the contents of one file then the next one:
https://sources.debian.net/src/diffutils/1:3.5-3/src/io.c/#L552
This means that if the "files" are actually FIFOs connected to the output of a
process, as they are
Ian Jackson:
> [..]
>
>
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F
>
>
> As I wrote to Guillem, quoting the FAQ:
>
>> By default dpkg-buildpackage does active tasks such as cleaning via
>> debian/rules, and makes sure
dpkg_1.18.24.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
gcc-6_6.3.0-18.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Holger Levsen:
> control: found -1 3.4.0-1
> control: notfound -1 3.4.0-1.0~reproducible2
>
> Hi Dirk,
>
> I've asked Ximin to file this bug so that we have something to track and to
> refer in discussions…
>
> you wrote:
>
>> At work now with limited time, but I think I already told you twice
gcc-6_6.3.0-17.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Chris Lamb:
> Ximin Luo wrote:
>
>> How shall we handle this in the context of reproducible builds?
>
> Devil's advocate for a second - it is sufficient that the output
> appears on https://buildd.debian.org so anyone interested enough can
> look there.
>
&
I meant to send this to rb-general as well:
Ximin Luo:
> I've been reviewing Debian's "required" and "build-essential" package sets.
> One new issue that's come up, is that the gcc-6 and binutils packages both
> put test logs in their binary output.
>
> O
I've been reviewing Debian's "required" and "build-essential" package sets. One
new issue that's come up, is that the gcc-6 and binutils packages both put test
logs in their binary output.
Of course this has no chance of ever being reproducible, due to parallelism,
build paths, and many many
r-base_3.4.0-1.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/105/
Feel free to commit fixes directly to drafts/105.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
gcc-6_6.3.0-16.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
r-base_3.4.0-1.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/103/
Feel free to commit fixes directly to drafts/103.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
gcc-6_6.3.0-14.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
dpkg_1.18.23.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
gcc-6_6.3.0-12.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Ximin Luo:
> Hi all, I uploaded patched versions of dpkg and gcc-6 today.
>
> "Soon" (after all the schroots are updated) we should see how well this
> works. Hopefully we'll get to around 88-90% or so reproducibility again in
> sid; there are still some issues lik
Ximin Luo:
> Chris Lamb:
>> Ximin Luo wrote:
>>
>>> Hi all, I uploaded patched versions of dpkg and gcc-6 today.
>>>
>>> "Soon" (after all the schroots are updated) we should see how well
>>> this works
>>
>> Similar to the
Chris Lamb:
> Ximin Luo wrote:
>
>> Hi all, I uploaded patched versions of dpkg and gcc-6 today.
>>
>> "Soon" (after all the schroots are updated) we should see how well
>> this works
>
> Similar to the i386 issue yesterday, are we missing an armhf
Hi all, I uploaded patched versions of dpkg and gcc-6 today.
"Soon" (after all the schroots are updated) we should see how well this works.
Hopefully we'll get to around 88-90% or so reproducibility again in sid; there
are still some issues like [1] that aren't covered by these patches.
The
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/101/
Feel free to commit fixes directly to drafts/101.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
gcc-6_6.3.0-11.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
dpkg_1.18.23.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/99/
Feel free to commit fixes directly to drafts/99.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
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/97/
Feel free to commit fixes directly to drafts/97.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
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
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
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:
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…
1 - 100 of 217 matches
Mail list logo
