Bug#796345: [pkg-mono-group] Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Jo Shields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 31/12/15 20:33, Jo Shields wrote:
> 
> 
> On 31/12/15 18:48, Julien Cristau wrote:
>> 3 packages from the mono-tools source break due to a dep on 
>> libmono-cecil-private-cil (<< 3.2.9): gendarme, mono-tools-devel,
>>  mono-tools-gui.  AFAICT that needs a sourceful upload of 
>> mono-tools.
> 
>> I might go ahead and force this in anyway, and fix up the
>> leftover pieces afterwards.
> 
> Break it.
> 
> I need a new upstream tag of mono-tools to fix this (it's not just
> a rebuild of what we have, and I don't see the point in
> backporting dozens of commits against what's in Sid), and the
> upstream release manager for Mono open source stuff is off on
> paternity leave. And his cover for the next month appears to be off
> celebrating new year. Next week, with any luck.

FYI i have just uploaded mono-tools 4.2, which builds fine on Sid.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWiT7CAAoJEMkPnLkOH60MDx0H/ivaWUBjyKWWWMW/q/fO6pen
p9bbLGjXXbu+SDN3na503hvtR8hB8UzLRqcpmO32ngz9CqiUotwuhNXIawM3REOX
HTSOnBmIeRPiE/mAsHoLDjTMCaTFjvxalNjq31Z6Kmst+dTo+r6k8Bjyt1LLUXZI
v/v7NNY6i34BTQr8fIQw6soaDcEEUlFUvjUtR4pNNKqBQmAdB9CQDN0MvA+lCGGp
rbVA3f5n/ByoUPlwy7u01v6yTTr0O5GdzXSJOJZHDzuf5vkdLLSY1Ws9Aho9PeQM
aHWzyQk/0HizedIc5tWaskmh4oRt3MFYf/aEuwhegpvODbrwZs587PYo5M4qYOI=
=F5Ao
-END PGP SIGNATURE-

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Julien Cristau]

On Thu, Dec 31, 2015 at 19:11:03 +0100, Julien Cristau wrote:

> On Thu, Dec 31, 2015 at 02:55:53 +0100, Emilio Pozuelo Monfort wrote:
> 
> > Last britney run had this:
> > 
> > * amd64: ganglia-nagios-bridge, gendarme, icinga, icinga-core, 
> > icinga-dbg,
> > kde-full, kdepim, kleopatra, libccs-perl,
> > libicsharpcode-nrefactory-cecil5.0-cil, libicsharpcode-nrefactory-cil-dev,
> > libicsharpcode-nrefactory-csharp5.0-cil, 
> > libicsharpcode-nrefactory-ikvm5.0-cil,
> > libicsharpcode-nrefactory-xml5.0-cil, libicsharpcode-nrefactory5.0-cil,
> > libmono-debugger-libs-cil-dev, libmono-debugger-soft-cil, 
> > libmono-debugging-cil,
> > libmono-debugging-soft-cil, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4,
> > mono-tools-devel, mono-tools-gui, nrefactory-samples, perl-modules, sdb,
> > syslog-nagios-bridge, wnn7egg
> [...]
> > 
> > powerpc needs some cleanup for the mono bits, it seems. e.g. 
> > libgdk3.0-cil-dev
> > should have been removed on that architecture but is still present there.
> > 
> > icinga needs ageing.
> > 
> > There are some arch:all packages that break (see amd64/i386). Maybe some 
> > can be
> > removed or need ageing.
> > 
> > Unfortunately I have run out of time and can't look at this anymore. If 
> > someone
> > can take it up and try to get things fixed, and eventually force it (to 
> > ignore
> > cruft / libccs-perl), that'd be great. Otherwise I can keep looking at it 
> > when I
> > get back.
> > 
> Looking now... There's a number of badly timed uploads getting in the
> way, at least courier, inn2, icinga and gnumeric.  I'll see where this
> all gets me.
> 
On the mono side I end up with
remove nrefactory/5.3.0+20130718.73b6d0f-2 
mono-debugger-libs/0+20131201.3459502-1 sdb/1.2-1

3 packages from the mono-tools source break due to a dep on
libmono-cecil-private-cil (<< 3.2.9): gendarme, mono-tools-devel,
mono-tools-gui.  AFAICT that needs a sourceful upload of mono-tools.

I might go ahead and force this in anyway, and fix up the leftover
pieces afterwards.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Julien Cristau]

On Thu, Dec 31, 2015 at 02:55:53 +0100, Emilio Pozuelo Monfort wrote:

> On 30/12/15 21:06, Niko Tyni wrote:
> > On Wed, Dec 30, 2015 at 12:49:50PM +0100, Emilio Pozuelo Monfort wrote:
> >> We're almost there. The last britney run reported:
> >>
> >> * ppc64el: cyrus-dev, libccs-perl, libcyrus-imap-perl, libdcmtk4-dev,
> >> libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2, 
> >> oar-restful-api
> > 
> > Awesome, thanks for your work!
> > 
> >> So the only real issue is libccs-perl. I am pondering a `force-hint
> >> perl/5.22.1-3 mono/4.2.1.102+dfsg2-5' now to finish this. Otherwise 
> >> someone else
> >> will have to look at this, or this will have to wait. Any thoughts?
> > 
> > I guess you're mainly looking for input from other release team members,
> > but FWIW: fine by me to force it in now, I think it's cooked long enough :)
> 
> Last britney run had this:
> 
> * amd64: ganglia-nagios-bridge, gendarme, icinga, icinga-core, icinga-dbg,
> kde-full, kdepim, kleopatra, libccs-perl,
> libicsharpcode-nrefactory-cecil5.0-cil, libicsharpcode-nrefactory-cil-dev,
> libicsharpcode-nrefactory-csharp5.0-cil, 
> libicsharpcode-nrefactory-ikvm5.0-cil,
> libicsharpcode-nrefactory-xml5.0-cil, libicsharpcode-nrefactory5.0-cil,
> libmono-debugger-libs-cil-dev, libmono-debugger-soft-cil, 
> libmono-debugging-cil,
> libmono-debugging-soft-cil, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4,
> mono-tools-devel, mono-tools-gui, nrefactory-samples, perl-modules, sdb,
> syslog-nagios-bridge, wnn7egg
[...]
> 
> powerpc needs some cleanup for the mono bits, it seems. e.g. libgdk3.0-cil-dev
> should have been removed on that architecture but is still present there.
> 
> icinga needs ageing.
> 
> There are some arch:all packages that break (see amd64/i386). Maybe some can 
> be
> removed or need ageing.
> 
> Unfortunately I have run out of time and can't look at this anymore. If 
> someone
> can take it up and try to get things fixed, and eventually force it (to ignore
> cruft / libccs-perl), that'd be great. Otherwise I can keep looking at it 
> when I
> get back.
> 
Looking now... There's a number of badly timed uploads getting in the
way, at least courier, inn2, icinga and gnumeric.  I'll see where this
all gets me.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#796345: [pkg-mono-group] Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Jo Shields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 31/12/15 18:48, Julien Cristau wrote:
> 3 packages from the mono-tools source break due to a dep on 
> libmono-cecil-private-cil (<< 3.2.9): gendarme, mono-tools-devel, 
> mono-tools-gui.  AFAICT that needs a sourceful upload of
> mono-tools.
> 
> I might go ahead and force this in anyway, and fix up the leftover 
> pieces afterwards.

Break it.

I need a new upstream tag of mono-tools to fix this (it's not just a
rebuild of what we have, and I don't see the point in backporting
dozens of commits against what's in Sid), and the upstream release
manager for Mono open source stuff is off on paternity leave. And his
cover for the next month appears to be off celebrating new year. Next
week, with any luck.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWhZErAAoJEMkPnLkOH60MvH0H/3As3e5i+K3sva4dmThxONp5
AdMlNlxvxSSaPdI9MbNLkFDZoxIlA4iFcYYPRxUDawI1ECBluK1gGUCtioGWBFd9
bVxvFku+5kGTa/KhR36Cb/h5LZg8KDCB8kEk1eEhDYfCpeA/98OKPbwElkApwibk
sJz24ETP4pQFkcVL3zwytBD1typ7YZLFPn3wVrocIuMOclBT3id7C7/CC8SL+/cV
fONXZSdd4ABvV7Qp0GH03HGkWdxSXhwE4Yx3rPSwZfIQKUhpJCW7I8c5gR4484iS
rYp8PHk7u7h/tvCsja8iKRtuoZ8zX/+n2BqdNiI0M9RxfDeceLSqEOH9hfbSgmY=
=kakV
-END PGP SIGNATURE-

Bug#796345: [pkg-mono-group] Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Jo Shields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 31/12/15 18:48, Julien Cristau wrote:
> On the mono side I end up with remove
> nrefactory/5.3.0+20130718.73b6d0f-2
> mono-debugger-libs/0+20131201.3459502-1 sdb/1.2-1

Just pushed a fix for this to Sid
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWhY6vAAoJEMkPnLkOH60MBIkIAL3c0ywig1INqGbrPmNUNMjE
yRp2Ky8KUuoFHvpjCEwkmAK88sYt7CpN5ZEaChPQSrP+lihUTMzE1oU7cesBCEdU
XebZ0VBAVdO8K/t5G1nSbcNOQV7vkg3TMmYWFukh96Ob30URE7qACSU6EyKw6h1w
cE2UW/Q3zAzCCTAjcVcHL9UlBJGi0Xy2whNXqv2+FMMaOKbBQN0+p/GM6aGYXFC7
l/zsLJZBaVTJJkX96Yeg3BbY71v9m9ujCRCnY6I8Pqqba219x4GzLSzuOb5t7JNA
Kws3/GshLccQr2Lh3oJ8X7ObPfSUlnn1SEfMKy13wohb9lH//kHUGPTfiUVPhF0=
=TlOr
-END PGP SIGNATURE-

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Niko Tyni]

On Wed, Dec 30, 2015 at 12:49:50PM +0100, Emilio Pozuelo Monfort wrote:
> We're almost there. The last britney run reported:
> 
> * ppc64el: cyrus-dev, libccs-perl, libcyrus-imap-perl, libdcmtk4-dev,
> libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2, oar-restful-api

Awesome, thanks for your work!

> So the only real issue is libccs-perl. I am pondering a `force-hint
> perl/5.22.1-3 mono/4.2.1.102+dfsg2-5' now to finish this. Otherwise someone 
> else
> will have to look at this, or this will have to wait. Any thoughts?

I guess you're mainly looking for input from other release team members,
but FWIW: fine by me to force it in now, I think it's cooked long enough :)
-- 
Niko Tyni   nt...@debian.org

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 30/12/15 21:06, Niko Tyni wrote:
> On Wed, Dec 30, 2015 at 12:49:50PM +0100, Emilio Pozuelo Monfort wrote:
>> We're almost there. The last britney run reported:
>>
>> * ppc64el: cyrus-dev, libccs-perl, libcyrus-imap-perl, libdcmtk4-dev,
>> libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2, oar-restful-api
> 
> Awesome, thanks for your work!
> 
>> So the only real issue is libccs-perl. I am pondering a `force-hint
>> perl/5.22.1-3 mono/4.2.1.102+dfsg2-5' now to finish this. Otherwise someone 
>> else
>> will have to look at this, or this will have to wait. Any thoughts?
> 
> I guess you're mainly looking for input from other release team members,
> but FWIW: fine by me to force it in now, I think it's cooked long enough :)

Last britney run had this:

* amd64: ganglia-nagios-bridge, gendarme, icinga, icinga-core, icinga-dbg,
kde-full, kdepim, kleopatra, libccs-perl,
libicsharpcode-nrefactory-cecil5.0-cil, libicsharpcode-nrefactory-cil-dev,
libicsharpcode-nrefactory-csharp5.0-cil, libicsharpcode-nrefactory-ikvm5.0-cil,
libicsharpcode-nrefactory-xml5.0-cil, libicsharpcode-nrefactory5.0-cil,
libmono-debugger-libs-cil-dev, libmono-debugger-soft-cil, libmono-debugging-cil,
libmono-debugging-soft-cil, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4,
mono-tools-devel, mono-tools-gui, nrefactory-samples, perl-modules, sdb,
syslog-nagios-bridge, wnn7egg
* i386: d-i-meta-faux, ganglia-nagios-bridge, gendarme, icinga, icinga-core,
icinga-dbg, kde-full, kdepim, kleopatra, libccs-perl,
libicsharpcode-nrefactory-cecil5.0-cil, libicsharpcode-nrefactory-cil-dev,
libicsharpcode-nrefactory-csharp5.0-cil, libicsharpcode-nrefactory-ikvm5.0-cil,
libicsharpcode-nrefactory-xml5.0-cil, libicsharpcode-nrefactory5.0-cil,
libmono-debugger-libs-cil-dev, libmono-debugger-soft-cil, libmono-debugging-cil,
libmono-debugging-soft-cil, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4,
mono-tools-devel, mono-tools-gui, nrefactory-samples, perl-modules, sdb,
syslog-nagios-bridge, wnn7egg
* arm64: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg, kleopatra,
libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge
* armel: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg, kleopatra,
libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge
* armhf: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg, kleopatra,
libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge
* mips: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg, kleopatra,
libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge
* mipsel: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg, kleopatra,
libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge
* powerpc: banshee, banshee-dbg, banshee-extension-lastfmfingerprint,
banshee-extension-lirc, banshee-extension-mirage, banshee-meego, bareftp,
cowbell, fsgateway, ganglia-nagios-bridge, gnome-do, gnome-subtitles,
gtk-sharp2-gapi, gtk-sharp3, gtk-sharp3-gapi, icinga, icinga-core, icinga-dbg,
kleopatra, libapache2-mod-mono, libatk3.0-cil, libcairo1.10-cil, libccs-perl,
libgdcm-cil, libgdk3.0-cil, libgdk3.0-cil-dev, libgio3.0-cil, libgio3.0-cil-dev,
libglade2.0-cil, libglade2.0-cil-dev, libglib2.0-cil, libglib2.0-cil-dev,
libglib3.0-cil, libglib3.0-cil-dev, libgnome-keyring1.0-cil,
libgnome-keyring1.0-cil-dev, libgnome2.0-cil-dev, libgnome2.24-cil,
libgpod-cil-dev, libgtk-dotnet3.0-cil, libgtk-dotnet3.0-cil-dev, libgtk2.0-cil,
libgtk2.0-cil-dev, libgtk3.0-cil, libgtk3.0-cil-dev, libmono-fuse-cil,
libmono-profiler-gui-thread-check, libpango3.0-cil, libperl5.20, libvtkgdcm-cil,
libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge, tangerine, tangerine-dbg,
tomboy
* ppc64el: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg,
kleopatra, libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4,
syslog-nagios-bridge
* s390x: ganglia-nagios-bridge, icinga, icinga-core, icinga-dbg, kleopatra,
libccs-perl, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, syslog-nagios-bridge


powerpc needs some cleanup for the mono bits, it seems. e.g. libgdk3.0-cil-dev
should have been removed on that architecture but is still present there.

icinga needs ageing.

There are some arch:all packages that break (see amd64/i386). Maybe some can be
removed or need ageing.

Unfortunately I have run out of time and can't look at this anymore. If someone
can take it up and try to get things fixed, and eventually force it (to ignore
cruft / libccs-perl), that'd be great. Otherwise I can keep looking at it when I
get back.

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

We're almost there. The last britney run reported:

* ppc64el: cyrus-dev, libccs-perl, libcyrus-imap-perl, libdcmtk4-dev,
libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2, oar-restful-api

Of those:

libdcmtk4-dev, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2 are
cruft, so should be removed at the end of the run

oar-restful-api is not in testing as I removed oar. I guess britney is trying to
add it as my removal hint is for the old version that was in testing. I'll
update it for the new version that is trying to enter now, so this shouldn't be
a problem (and in any case, we could remove it afterwards).

cyrus-dev, libcyrus-imap-perl should be fixed in the next run with my
cyrus-imapd-2.4 urgent.

libccs-perl is the one that we would break, as has already been discussed.

So the only real issue is libccs-perl. I am pondering a `force-hint
perl/5.22.1-3 mono/4.2.1.102+dfsg2-5' now to finish this. Otherwise someone else
will have to look at this, or this will have to wait. Any thoughts?

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Wed, Dec 30, 2015 at 12:49:50PM +0100, Emilio Pozuelo Monfort wrote:
> We're almost there. The last britney run reported:
> 
> * ppc64el: cyrus-dev, libccs-perl, libcyrus-imap-perl, libdcmtk4-dev,
> libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2, oar-restful-api
> 
> Of those:
> 
> libdcmtk4-dev, libperl5.20, libvtkgdcm-java, libvtkgdcm2.4, linux-perf-4.2 are
> cruft, so should be removed at the end of the run
> 
> oar-restful-api is not in testing as I removed oar. I guess britney is trying 
> to
> add it as my removal hint is for the old version that was in testing. I'll
> update it for the new version that is trying to enter now, so this shouldn't 
> be
> a problem (and in any case, we could remove it afterwards).
> 
> cyrus-dev, libcyrus-imap-perl should be fixed in the next run with my
> cyrus-imapd-2.4 urgent.
> 
> libccs-perl is the one that we would break, as has already been discussed.
> 
> So the only real issue is libccs-perl. I am pondering a `force-hint
> perl/5.22.1-3 mono/4.2.1.102+dfsg2-5' now to finish this. Otherwise someone 
> else
> will have to look at this, or this will have to wait. Any thoughts?

This sounds sane to me. As already discussed the actual user impact on
breaking libccs-perl should be minimal, and it looks like the HA team
are on the way to resolving that. I guess avoiding blockages in
testing until that can be fixed properly is unnecessary.

Thanks for all your work on this!

Cheers,
Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Sun, Dec 06, 2015 at 11:10:54PM +, Dominic Hargreaves wrote:
> Niko has uploaded 5.22.1-RC3 to experimental and we should see
> 5.22.1 final in a few days.
> 
> I'm rebuilding all the packages involved in the perlapi transition
> against 5.22.1, and spotted a couple of issues which I've marked as
> blockers. I've uploaded a delayed fix for the courier issue (#804603)
> and the other one I've spotted so far has been redhat-cluster, which
> I presume we'll just remove from testing given its recent track
> record?
> 
> Once 5.22.1 final has been released, I don't think there is anything
> else stopping us from uploading that to unstable, assuming that no
> more problems come to light first.

Current status: 5.22.1 is still looking likely in the next few days.
As of now this bug is blocked by the following:

#807492: libmath-bigint-gmp-perl: FTBFS on 32 bit platforms

This is a fairly new bug and there is a fix pending - we would
ideally get some feedback from upstream, but if not we can upload it
at around the same time as perl.

As I already mentioned, redhat-cluster currently FTBFS, and has done
since August, so I don't think we should block on that.

Emilio, do you agree with this assessment? If so can we upload
5.22.1 to unstable when it's released?

I think we should probably do a d-d-a mail either now or at the time
of the upload, so I'll do that once you give the go-ahead.

Cheers,
Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Sun, Dec 13, 2015 at 12:43:07PM +, Dominic Hargreaves wrote:
> On Sun, Dec 06, 2015 at 11:10:54PM +, Dominic Hargreaves wrote:
> > Niko has uploaded 5.22.1-RC3 to experimental and we should see
> > 5.22.1 final in a few days.
> > 
> > I'm rebuilding all the packages involved in the perlapi transition
> > against 5.22.1, and spotted a couple of issues which I've marked as
> > blockers. I've uploaded a delayed fix for the courier issue (#804603)
> > and the other one I've spotted so far has been redhat-cluster, which
> > I presume we'll just remove from testing given its recent track
> > record?
> > 
> > Once 5.22.1 final has been released, I don't think there is anything
> > else stopping us from uploading that to unstable, assuming that no
> > more problems come to light first.
> 
> Current status: 5.22.1 is still looking likely in the next few days.
> As of now this bug is blocked by the following:
> 
> #807492: libmath-bigint-gmp-perl: FTBFS on 32 bit platforms
> 
> This is a fairly new bug and there is a fix pending - we would
> ideally get some feedback from upstream, but if not we can upload it
> at around the same time as perl.
> 
> As I already mentioned, redhat-cluster currently FTBFS, and has done
> since August, so I don't think we should block on that.
> 
> Emilio, do you agree with this assessment? If so can we upload
> 5.22.1 to unstable when it's released?
> 
> I think we should probably do a d-d-a mail either now or at the time
> of the upload, so I'll do that once you give the go-ahead.

5.22.1 is now released upstream.

Cheers,
Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 13/12/15 13:43, Dominic Hargreaves wrote:
> As I already mentioned, redhat-cluster currently FTBFS, and has done
> since August, so I don't think we should block on that.

We can't remove it from testing as lvm2 depends on it, so this really is a 
blocker.

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Thu, Dec 03, 2015 at 01:22:13PM +0100, Emilio Pozuelo Monfort wrote:
> On 03/12/15 13:15, Dominic Hargreaves wrote:
> > On Wed, Dec 02, 2015 at 07:08:55PM +0100, Emilio Pozuelo Monfort wrote:
> >>> On Wed, Dec 02, 2015 at 11:09:09AM +, Dominic Hargreaves wrote:

> >>> I've tested the packages which were blocked by libapache2-mod-perl2
> >>> today, and filed two new bug reports, against libembperl-perl[1] and
> >>> libapache-gallery-perl[2]. The former unfortunately has a history of
> >>> breaking with new perl releases and fixes may not be forthcoming;
> >>> it also has a low and diminishing popcon, so I think at this stage we
> >>> should not let it block our transition.
> >>>
> >>> The latter is a trivial fix (and does not block the transition as
> >>> it's an arch:all package); I expect it will be fixed either by the
> >>> maintainer, or by NMU, soon.

I've uploaded that now.

> >>> I will try some real world testing with the new libapache2-mod-perl2
> >>> package in sid/perl 5.20 later this week, and then I think we can plan
> >>> to go ahead with the transition after that - as soon as this weekend
> >>> if other ongoing transitions allow?
> >>
> >> Yeah, that's probably fine. Let us know how your tests go.

I've tested the new mod_perl+RT with perl 5.20 and perl 5.22, and it
all went well, so I've pushed the new mod_perl to sid this evening.

> > Niko reminded me that 5.22.1 is due out as soon as the weekend, and
> > it would make sense to transition with that rather than have to 
> > build a mini-transition in later. So we'll work to integrate that
> > into experimental with suitable QA before the transition, if that's
> > okay with you. I think that should only delay things by a couple of
> > days.
> 
> Sure, that sounds better indeed. Let's do that.

Niko has uploaded 5.22.1-RC3 to experimental and we should see
5.22.1 final in a few days.

I'm rebuilding all the packages involved in the perlapi transition
against 5.22.1, and spotted a couple of issues which I've marked as
blockers. I've uploaded a delayed fix for the courier issue (#804603)
and the other one I've spotted so far has been redhat-cluster, which
I presume we'll just remove from testing given its recent track
record?

Once 5.22.1 final has been released, I don't think there is anything
else stopping us from uploading that to unstable, assuming that no
more problems come to light first.

Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Wed, Dec 02, 2015 at 07:08:55PM +0100, Emilio Pozuelo Monfort wrote:
> On 02/12/15 17:48, Dominic Hargreaves wrote:
> > On Wed, Dec 02, 2015 at 11:09:09AM +, Dominic Hargreaves wrote:
> >> On Wed, Dec 02, 2015 at 01:24:29AM +0100, Axel Beckert wrote:
> >>> Hi,
> >>>
> >>> Emilio Pozuelo Monfort wrote:
>  On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
> > That'd only leave us with the apache bug.
> 
>  There's a patch available for that now, right?
> >>>
> >>> Yes. It has been included in the upload to experimental 1.5 days ago:
> >>> https://packages.qa.debian.org/liba/libapache2-mod-perl2/news/20151130T194855Z.html
> >>
> >> I will run some test builds with perl 5.22, that package, and the packages
> >> build-depending on libapache2-mod-perl2 over the next day or so. Then
> >> hopefully we can really get this transition under way!
> > 
> > I've tested the packages which were blocked by libapache2-mod-perl2
> > today, and filed two new bug reports, against libembperl-perl[1] and
> > libapache-gallery-perl[2]. The former unfortunately has a history of
> > breaking with new perl releases and fixes may not be forthcoming;
> > it also has a low and diminishing popcon, so I think at this stage we
> > should not let it block our transition.
> > 
> > The latter is a trivial fix (and does not block the transition as
> > it's an arch:all package); I expect it will be fixed either by the
> > maintainer, or by NMU, soon.
> > 
> > I will try some real world testing with the new libapache2-mod-perl2
> > package in sid/perl 5.20 later this week, and then I think we can plan
> > to go ahead with the transition after that - as soon as this weekend
> > if other ongoing transitions allow?
> 
> Yeah, that's probably fine. Let us know how your tests go.

Niko reminded me that 5.22.1 is due out as soon as the weekend, and
it would make sense to transition with that rather than have to 
build a mini-transition in later. So we'll work to integrate that
into experimental with suitable QA before the transition, if that's
okay with you. I think that should only delay things by a couple of
days.

Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 03/12/15 13:15, Dominic Hargreaves wrote:
> On Wed, Dec 02, 2015 at 07:08:55PM +0100, Emilio Pozuelo Monfort wrote:
>> On 02/12/15 17:48, Dominic Hargreaves wrote:
>>> On Wed, Dec 02, 2015 at 11:09:09AM +, Dominic Hargreaves wrote:
 On Wed, Dec 02, 2015 at 01:24:29AM +0100, Axel Beckert wrote:
> Hi,
>
> Emilio Pozuelo Monfort wrote:
>> On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
>>> That'd only leave us with the apache bug.
>>
>> There's a patch available for that now, right?
>
> Yes. It has been included in the upload to experimental 1.5 days ago:
> https://packages.qa.debian.org/liba/libapache2-mod-perl2/news/20151130T194855Z.html

 I will run some test builds with perl 5.22, that package, and the packages
 build-depending on libapache2-mod-perl2 over the next day or so. Then
 hopefully we can really get this transition under way!
>>>
>>> I've tested the packages which were blocked by libapache2-mod-perl2
>>> today, and filed two new bug reports, against libembperl-perl[1] and
>>> libapache-gallery-perl[2]. The former unfortunately has a history of
>>> breaking with new perl releases and fixes may not be forthcoming;
>>> it also has a low and diminishing popcon, so I think at this stage we
>>> should not let it block our transition.
>>>
>>> The latter is a trivial fix (and does not block the transition as
>>> it's an arch:all package); I expect it will be fixed either by the
>>> maintainer, or by NMU, soon.
>>>
>>> I will try some real world testing with the new libapache2-mod-perl2
>>> package in sid/perl 5.20 later this week, and then I think we can plan
>>> to go ahead with the transition after that - as soon as this weekend
>>> if other ongoing transitions allow?
>>
>> Yeah, that's probably fine. Let us know how your tests go.
> 
> Niko reminded me that 5.22.1 is due out as soon as the weekend, and
> it would make sense to transition with that rather than have to 
> build a mini-transition in later. So we'll work to integrate that
> into experimental with suitable QA before the transition, if that's
> okay with you. I think that should only delay things by a couple of
> days.

Sure, that sounds better indeed. Let's do that.

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 02/12/15 17:48, Dominic Hargreaves wrote:
> On Wed, Dec 02, 2015 at 11:09:09AM +, Dominic Hargreaves wrote:
>> On Wed, Dec 02, 2015 at 01:24:29AM +0100, Axel Beckert wrote:
>>> Hi,
>>>
>>> Emilio Pozuelo Monfort wrote:
 On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
> That'd only leave us with the apache bug.

 There's a patch available for that now, right?
>>>
>>> Yes. It has been included in the upload to experimental 1.5 days ago:
>>> https://packages.qa.debian.org/liba/libapache2-mod-perl2/news/20151130T194855Z.html
>>
>> I will run some test builds with perl 5.22, that package, and the packages
>> build-depending on libapache2-mod-perl2 over the next day or so. Then
>> hopefully we can really get this transition under way!
> 
> I've tested the packages which were blocked by libapache2-mod-perl2
> today, and filed two new bug reports, against libembperl-perl[1] and
> libapache-gallery-perl[2]. The former unfortunately has a history of
> breaking with new perl releases and fixes may not be forthcoming;
> it also has a low and diminishing popcon, so I think at this stage we
> should not let it block our transition.
> 
> The latter is a trivial fix (and does not block the transition as
> it's an arch:all package); I expect it will be fixed either by the
> maintainer, or by NMU, soon.
> 
> I will try some real world testing with the new libapache2-mod-perl2
> package in sid/perl 5.20 later this week, and then I think we can plan
> to go ahead with the transition after that - as soon as this weekend
> if other ongoing transitions allow?

Yeah, that's probably fine. Let us know how your tests go.

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Wed, Dec 02, 2015 at 11:09:09AM +, Dominic Hargreaves wrote:
> On Wed, Dec 02, 2015 at 01:24:29AM +0100, Axel Beckert wrote:
> > Hi,
> > 
> > Emilio Pozuelo Monfort wrote:
> > > On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
> > > > That'd only leave us with the apache bug.
> > > 
> > > There's a patch available for that now, right?
> > 
> > Yes. It has been included in the upload to experimental 1.5 days ago:
> > https://packages.qa.debian.org/liba/libapache2-mod-perl2/news/20151130T194855Z.html
> 
> I will run some test builds with perl 5.22, that package, and the packages
> build-depending on libapache2-mod-perl2 over the next day or so. Then
> hopefully we can really get this transition under way!

I've tested the packages which were blocked by libapache2-mod-perl2
today, and filed two new bug reports, against libembperl-perl[1] and
libapache-gallery-perl[2]. The former unfortunately has a history of
breaking with new perl releases and fixes may not be forthcoming;
it also has a low and diminishing popcon, so I think at this stage we
should not let it block our transition.

The latter is a trivial fix (and does not block the transition as
it's an arch:all package); I expect it will be fixed either by the
maintainer, or by NMU, soon.

I will try some real world testing with the new libapache2-mod-perl2
package in sid/perl 5.20 later this week, and then I think we can plan
to go ahead with the transition after that - as soon as this weekend
if other ongoing transitions allow?

Cheers,
Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Damyan Ivanov]

-=| Dominic Hargreaves, 02.12.2015 16:48:39 + |=-
> I will try some real world testing with the new libapache2-mod-perl2
> package in sid/perl 5.20 later this week, and then I think we can plan
> to go ahead with the transition after that - as soon as this weekend
> if other ongoing transitions allow?

I have installed a hand-built package with sid/perl 5.20 on my work 
computer and will use it for the ongoing development. That probably 
won't cover all the ways it may break, but at least it will provide 
some testing in somewhat real world environment prior the sid upload.

Thanks Niko and Steve!


signature.asc
Description: Digital signature

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

On Wed, Dec 02, 2015 at 01:24:29AM +0100, Axel Beckert wrote:
> Hi,
> 
> Emilio Pozuelo Monfort wrote:
> > On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
> > > That'd only leave us with the apache bug.
> > 
> > There's a patch available for that now, right?
> 
> Yes. It has been included in the upload to experimental 1.5 days ago:
> https://packages.qa.debian.org/liba/libapache2-mod-perl2/news/20151130T194855Z.html

I will run some test builds with perl 5.22, that package, and the packages
build-depending on libapache2-mod-perl2 over the next day or so. Then
hopefully we can really get this transition under way!

Thanks,
Dominic.

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
> That'd only leave us with the apache bug.

There's a patch available for that now, right?

Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Axel Beckert]

Hi,

Emilio Pozuelo Monfort wrote:
> On 30/10/15 14:34, Emilio Pozuelo Monfort wrote:
> > That'd only leave us with the apache bug.
> 
> There's a patch available for that now, right?

Yes. It has been included in the upload to experimental 1.5 days ago:
https://packages.qa.debian.org/liba/libapache2-mod-perl2/news/20151130T194855Z.html

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[gregor herrmann]

On Fri, 30 Oct 2015 21:00:21 +0100, Emilio Pozuelo Monfort wrote:

> >> That'd only leave us with the apache bug.
> > Ack, that's my impression as well.
> What about libtest-refcount-perl ? Does it have to build-depend on the 
> RC-buggy
> libdevel-findref-perl ?

Nope its' optional.
Fixed version uploaded; thanks for noticing!


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Yoro-Kery Goro: Mory


signature.asc
Description: Digital Signature

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[intrigeri]

Hi,

Emilio Pozuelo Monfort wrote (30 Oct 2015 13:34:21 GMT) :
> #787446 - libdevel-findref-perl: has one rdep and one build-rdep:

> Checking reverse dependencies...
> # Broken Depends:
> libtest-bdd-cucumber-perl: libtest-bdd-cucumber-perl

> # Broken Build-Depends:
> libtest-bdd-cucumber-perl: libdevel-findref-perl

Thanks fot the heads up.

Devel::FindRef is optional since Test::BDD::Cucumber 0.36 ⇒ I've just
pushed changes to Vcs-Git that drop the hard {build,run}time
dependencies. Lots of Tails -specific code is tested with
Test::BDD::Cucumber, so I'll try to keep it in the archive.

Cheers,
-- 
intrigeri

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

So of the blockers:

#787912 - can be removed together with its one rdep, not a blocker
#787499 - can be removed together with its one rdep, not a blocker

#787493 - libapache-mod-perl: blocker

#787446 - libdevel-findref-perl: has one rdep and one build-rdep:

Checking reverse dependencies...
# Broken Depends:
libtest-bdd-cucumber-perl: libtest-bdd-cucumber-perl

# Broken Build-Depends:
libtest-bdd-cucumber-perl: libdevel-findref-perl
libtest-refcount-perl: libdevel-findref-perl (>= 1.430)

libtest-bdd-cucumber-perl has no rdeps and could be removed.

libtest-refcount-perl has lots of rdeps. However it doesn't depend on
libdevel-findref-perl. Is the build-dependency necessary? If not, then #787446
wouldn't be a blocker.

That'd only leave us with the apache bug.

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 01/10/15 02:22, Emilio Pozuelo Monfort wrote:
> I want to finish python 3.5 and ruby 2.2. After that, it could happen at any
> time I think (I have to look if the packages affected by the libstdc++
> transition have been renamed).

Doesn't look like there are any remaining conflicts with the libstdc++6
transition, so that shouldn't be a blocker.

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[gregor herrmann]

On Fri, 30 Oct 2015 14:34:21 +0100, Emilio Pozuelo Monfort wrote:

> #787493 - libapache-mod-perl: blocker

There's recent work on a patch in the upstream bug:
https://rt.cpan.org/Public/Bug/Display.html?id=101962

I'm optimistic this will be sorted out soon.
 
> That'd only leave us with the apache bug.

Ack, that's my impression as well.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones


signature.asc
Description: Digital Signature

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 30/10/15 18:59, gregor herrmann wrote:
> On Fri, 30 Oct 2015 14:34:21 +0100, Emilio Pozuelo Monfort wrote:
> 
>> #787493 - libapache-mod-perl: blocker
> 
> There's recent work on a patch in the upstream bug:
> https://rt.cpan.org/Public/Bug/Display.html?id=101962

Yeah I saw that.

> I'm optimistic this will be sorted out soon.

Cool.

>> That'd only leave us with the apache bug.
> 
> Ack, that's my impression as well.

What about libtest-refcount-perl ? Does it have to build-depend on the RC-buggy
libdevel-findref-perl ?

Cheers,
Emilio

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Dominic Hargreaves]

Hello all,

Here is a quick update on progress since my last update on 7th Sept:

The current stats for this transition are as follows:

*  Number of binNMUs needed: 570[1] (was 571)
*  Number of arch:any packages which FTBFS with perl 5.22: 7 (was 8)
   * 1 fix pending; 6 needing more work or removal.
   * libapache2-mod-perl2 remains problematic, but there has been
 some progress in upstream svn.
 * Removing it temporarily appears to be an option. I suspect
   that upstream will be able to work on it again after the
   release of perl 5.22.1
   * we have agreed to not support libcoro-perl with perl 5.22[2]
   * libdata-dump-streamer-perl, libb-hooks-op-check-entersubforcv-perl,
 libdata-alias-perl and libdevel-findref-perl all need investigation;
 no activity upstream. Probably libdata-dump-streamer-perl has the
 biggest impact
*  Number of arch:all packages which FTBFS with perl 5.22: 9
   (was 19)[3], with uploads pending for 2 of those
   * needing work: libdebug-client-perl, padre, libpoe-api-peek-perl,
 libtest-checkchanges-perl, mysql-5.5 (but this is an apparently
 abandoned variant), libb-lint-perl, libmodule-info-perl

I'm continuing rebuilds of arch:any packages which depend on perlapi-*
or libperl* daily, so the test repository[4] remains almost up-to-date
with the archive. Problem reports welcome (to me), and of course further
testing (in a controlled, development environment) of packages you use is
welcome.

Niko pointed out that some upgrade testing would not go amiss, so that
is a discrete task for anyone who is interested.

perl in experimental has had some minor fixes in 5.22.0-4 and there
is one more minor change queued in git.

5.22.1 is starting to happen upstream[5] so there is an ongoing task
to track that and possibly update our package; but this doesn't need
to be entangled with the transition.

The proposed change to policy has now been updated and is ready to file
against debian-policy at the time of the transition[6].

Release team: can we upgrade the FTBFS bugs to RC now so they get
a bit more attention, and do you have a feeling for when you might
be ready for the perl transition?

Cheers,
Dominic (for the perl and pkg-perl teams)

[1] 
[2] 
[3] 

[4] 
[5] 
[6] 

Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Emilio Pozuelo Monfort]

On 30/09/15 23:27, Dominic Hargreaves wrote:
> Hello all,
> 
> Here is a quick update on progress since my last update on 7th Sept:

Thanks.

> Release team: can we upgrade the FTBFS bugs to RC now so they get
> a bit more attention

Yes.

> and do you have a feeling for when you might
> be ready for the perl transition?

I want to finish python 3.5 and ruby 2.2. After that, it could happen at any
time I think (I have to look if the packages affected by the libstdc++
transition have been renamed). Although we have some other requests, so we'll
see. But if you keep shortening the list of problematic stuff, then this may get
acked very soon :)

Cheers,
Emilio