On Wed, 2017-01-04 at 20:33 +0100, Michael Biebl wrote:
> Am 04.01.2017 um 19:53 schrieb Margarita Manterola:
>
> > Can we accelerate the removal of non key packages, please?
> >
> > One example: https://tracker.debian.org/pkg/libsigc++-1.2 migrated to
> > testing on Dec 29th even though it has
Am 04.01.2017 um 19:53 schrieb Margarita Manterola:
> Can we accelerate the removal of non key packages, please?
>
> One example: https://tracker.debian.org/pkg/libsigc++-1.2 migrated to
> testing on Dec 29th even though it has an RC bug that was intended to
> keep it out of it.
>
> For
Hi,
On Fri, Dec 30, 2016 at 5:25 AM, Emilio Pozuelo Monfort
wrote:
> We thought about rolling back to the previous state, but that means testing
> users who have already upgraded would need to manually downgrade... which
> is not
> good.
>
> So we may just wait for the
Niels Thykier writes ("Re: Migration despite an RC bug?"):
> An exception in my experience: In process is cheaper when the
> (de)compressor is available in the PerlIO Layer as native C code.
> Notable example being libperlio-gzip-perl where you use "open(my $fd,
> '<
On Tue, 03 Jan 2017, Niels Thykier wrote:
> An exception in my experience: In process is cheaper when the
> (de)compressor is available in the PerlIO Layer as native C code.
> Notable example being libperlio-gzip-perl where you use "open(my $fd,
> '<:gzip', $file)".
> At least that was the case
Niels Thykier writes:
> Russ Allbery:
>> I've done extensive benchmarking of this in Perl for a different
>> project and yes, fork and exec of an external compresser is *way*
>> faster than using a library. I suspect the Perl compress libraries are
>> making extraneous data
Russ Allbery:
> [...]
>> I wouldn't have expected that either, but it appeared to be 4-5 times
>> slower than the equivalent code with fork a decompressor, which is why I
>> swapped it out. [I didn't bother to benchmark them, because the
>> differences between them was so stark.]
>
> I've done
On Tue, 03 Jan 2017, Russ Allbery wrote:
> If you're using DB_File, I think you have to use the explicit put()
> and get() API instead of the tied magical hash in order to get error
> reporting.
That matches what documentation I've found so far.
Instead of really working on hacking this out,
Don Armstrong writes:
> On Tue, 03 Jan 2017, Ian Jackson wrote:
>> Also, have you checked whether your DB library properly throws errors
>> on writes to a tied hash ?
> I don't know whether it does or not; I went looking to see whether you
> could trap errors on untie(), and
On Tue, 03 Jan 2017, Ian Jackson wrote:
> The result is that you ignore nonzero exit status from your
> decompression program. My theory for the incident we are discussing is
> that your decompressor got a SIGTERM, and your script got EOF on the
> pipe.
Yeah, this is likely it. Thanks for
Don Armstrong writes ("Re: Migration despite an RC bug?"):
> On Sat, 31 Dec 2016, Ian Jackson wrote:
> > I've debugged a lot of this kind of thing. Point me at your
> > (pre-just-fixed) code and I might spot it ?
>
> These two are how I think I've fixed it:
On Sat, 31 Dec 2016, Ian Jackson wrote:
> Don Armstrong writes ("Re: Migration despite an RC bug?"):
> > I'm still not quite sure how the script was failing. The outer shell
> > invocation which calls a perl script to do the versioning database
> > update is run w
Don Armstrong writes ("Re: Migration despite an RC bug?"):
> I'm still not quite sure how the script was failing. The outer shell
> invocation which calls a perl script to do the versioning database
> update is run with set -e, and the perl script should exit with non-zero
&g
On Thu, 29 Dec 2016, Christoph Biedl wrote:
> Emilio Pozuelo Monfort wrote...
>
> > Unforunately, the BTS exported a broken/incomplete RC bug list, and britney
> > used
> > that and didn't see that some packages had an RC bug, so it allowed them to
> > migrate.
>
> Ouch, that's quite a
Hi,
2016-12-30 12:53 GMT+01:00 Guillem Jover :
> Hi!
>
> On Fri, 2016-12-30 at 09:25:20 +0100, Emilio Pozuelo Monfort wrote:
>> On 29/12/16 23:36, Christoph Biedl wrote:
>> > Emilio Pozuelo Monfort wrote...
>> >> Unforunately, the BTS exported a broken/incomplete RC bug list,
Hi!
On Fri, 2016-12-30 at 09:25:20 +0100, Emilio Pozuelo Monfort wrote:
> On 29/12/16 23:36, Christoph Biedl wrote:
> > Emilio Pozuelo Monfort wrote...
> >> Unforunately, the BTS exported a broken/incomplete RC bug list, and
> >> britney used
> >> that and didn't see that some packages had an RC
On 29/12/16 23:36, Christoph Biedl wrote:
> Emilio Pozuelo Monfort wrote...
>
>> Unforunately, the BTS exported a broken/incomplete RC bug list, and britney
>> used
>> that and didn't see that some packages had an RC bug, so it allowed them to
>> migrate.
>
> Ouch, that's quite a nightmare.
Emilio Pozuelo Monfort wrote...
> Unforunately, the BTS exported a broken/incomplete RC bug list, and britney
> used
> that and didn't see that some packages had an RC bug, so it allowed them to
> migrate.
Ouch, that's quite a nightmare. While I'm curious to learn how this
happened and what is
Emilio Pozuelo Monfort writes:
> On 29/12/16 17:24, Ole Streicher wrote:
>> Hi,
>>
>> the python-numpy package in unstable has an RC bug:
>>
>> https://bugs.debian.org/849196
>>
>> however, today it migrated to testing, the migration status still says
>> however "valid
On 29/12/16 17:24, Ole Streicher wrote:
> Hi,
>
> the python-numpy package in unstable has an RC bug:
>
> https://bugs.debian.org/849196
>
> however, today it migrated to testing, the migration status still says
> however "valid candidate".
>
> I thought that RC bugs would prevent packages
Hi,
the python-numpy package in unstable has an RC bug:
https://bugs.debian.org/849196
however, today it migrated to testing, the migration status still says
however "valid candidate".
I thought that RC bugs would prevent packages from migration -- what is
the exception here?
Best regards
21 matches
Mail list logo