On 2018-07-05 18:40:37, Brian May wrote:
> Antoine Beaupré writes:
>
>> I am skeptical as well, and yes, it's a dict (.items()), so it should
>> *not* return constant ordering. But I'm just telling you what I am
>> seeing here. The #mercurial devs proposed doing a sorted() here to
>> return consta
Antoine Beaupré writes:
> I am skeptical as well, and yes, it's a dict (.items()), so it should
> *not* return constant ordering. But I'm just telling you what I am
> seeing here. The #mercurial devs proposed doing a sorted() here to
> return constant order, but I am not sure it's a better soluti
Antoine Beaupré writes:
>> Sorry to keep on about this but I still think we are talking past each
>> other. You seem to be conflating and jumping between three separate
>> concerns:
>>
>> * A build that does not non-determistically fail in its testsuite (and
>>thus FTBFS randomly.).
>>
>
On 2018-07-04 11:06:19, Chris Lamb wrote:
>> @wireprotocommand('listkeys', 'namespace')
>> def listkeys(repo, proto, namespace):
>> d = repo.listkeys(encoding.tolocal(namespace)).items()
>> return pushkeymod.encodekeys(d)
>>
>> And in my tests this is returns as a list of tuples,
>> determ
Hi Antoine,
> > * A build that does not non-determistically fail in its testsuite (and
> >thus FTBFS randomly.).
> >
> > * Reliably detecting regressions ("introduce new…").
> >
> > * A bit-for-bit reproducible build - eg. your "test packages
> >unreproducible" note in data/dla-ne
On 2018-07-03 14:16:17, Antoine Beaupré wrote:
> On 2018-06-29 03:41:15, Chris Lamb wrote:
> In the meantime, I postponed working on the package as I had to move on
> to other things and there didn't seem to be a concensus on the packaged
> suggested. I'll go back to it now to see if I can fix the
On 2018-06-29 03:41:15, Chris Lamb wrote:
> Antoine,
>
>> >> I am not sure why the test suite fails nor why the output varies from
>> >> one build to the next. Once a package is built, however, it passes the
>> >> test suite reliably.
> […]
>> Sure. I guess I see this from the perspective of "does
Antoine,
> >> I am not sure why the test suite fails nor why the output varies from
> >> one build to the next. Once a package is built, however, it passes the
> >> test suite reliably.
[…]
> Sure. I guess I see this from the perspective of "does the actual fix
> work or not" as well. ;)
Sorry to
On 2018-06-28 23:04:59, Chris Lamb wrote:
> Hey Antoine,
>
>> I am not sure why the test suite fails nor why the output varies from
>> one build to the next. Once a package is built, however, it passes the
>> test suite reliably.
>
> That may be, but as we only (*) really care about the package bui
Hey Antoine,
> I am not sure why the test suite fails nor why the output varies from
> one build to the next. Once a package is built, however, it passes the
> test suite reliably.
That may be, but as we only (*) really care about the package building
reliably, *subsequent* runs of the testsuite
On 2018-06-28 21:56:07, Chris Lamb wrote:
> Hey Antoine, :)
>
>> The package I managed to build obviously passes that test suite, and
>> *reliably* [but] it might FTBFS on the buildds
>
> Thanks for working on this. :)
>
> I'm a bit lost by your wording; it "might" FTBFS on the buildds, it
> does n
Hey Antoine, :)
> The package I managed to build obviously passes that test suite, and
> *reliably* [but] it might FTBFS on the buildds
Thanks for working on this. :)
I'm a bit lost by your wording; it "might" FTBFS on the buildds, it
does not sound particularly reliable to me… and thus doesn't
Hi,
I have worked on porting the security issues fixed in wheezy into jessie
for the Mercurial package, as I previously mentioned here.
I was not able to make the package build reproducibly. The test suite
fails during the build because of an ordering issue in the `hg serve`
output and I cannot f
13 matches
Mail list logo
