Bug#910669: glibc: Please remove transitional package multiarch-support

2019-07-24 Thread Boyuan Yang
在 2019-07-24三的 19:00 +0200,Aurelien Jarno写道:
> On 2019-07-24 12:01, Boyuan Yang wrote:
> > Control: severity -1 normal
> > Control: tag -1 - wontfix
> > X-Debbugs-CC: aurel...@aurel32.net
> > 
> > Hi Aurelien and other Debian glibc maintainers,
> > 
> > With Debian Buster released, I think now we are absolutely safe to have
> > package multiach-support removed from Sid (and thus Testing). There's no
> > other
> 
> Agreed, that will be done in one of the next uploads of the glibc
> package.

Thanks!

> > package in Sid (and Testing) currently depends on it. I can help submit a
> 
> That is true for testing.
> 
> For sid there is still:
> - hidrd on armel, armhf, ppc64el and s390x
> - librevisa on s390x
> 
> For experimental there is still:
> - poti on armel, armhf ans 390x
> 
> 
> > removal request to FTP Masters if you find it okay.
> 
> There is no need to submit a removal request for that. What is needed is
> to upload a new version of the glibc package without multiarch-support.
> Then it will be removed once no other packages depends on it in the
> archive. OTOH you can help to get the above packages removed by filling
> a removal request to FTP masters.

Oops I forgot to check architectures other than amd64 (and that such removal
do not need to involve FTP Masters). With those reverse dependencies left,
multiarch-support could become a leftover cruft on certain architectures if
those old packages are not removed; anyway it should be checked later after
new glibc upload.


Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part


Bug#910669: glibc: Please remove transitional package multiarch-support

2019-07-24 Thread Boyuan Yang
Control: severity -1 normal
Control: tag -1 - wontfix
X-Debbugs-CC: aurel...@aurel32.net

Hi Aurelien and other Debian glibc maintainers,

With Debian Buster released, I think now we are absolutely safe to have
package multiach-support removed from Sid (and thus Testing). There's no other
package in Sid (and Testing) currently depends on it. I can help submit a
removal request to FTP Masters if you find it okay.

Regards,
Boyuan Yang


On Tue, 9 Oct 2018 17:01:03 +0200 Aurelien Jarno  wrote:
> control: severity -1 + wishlist
> control: tag -1 + wontfix
> 
> On 2018-10-09 10:17, Boyuan Yang wrote:
> > Source: glibc
> > Version: 2.27-6
> > X-Debbugs-CC: aure...@debian.org d...@debian.org
> > Severity: normal
> > 
> > Hi Aurelien, Matthias and Debian glibc maintainers,
> > 
> > As previously discussed in
> > https://lists.debian.org/debian-science/2018/08/msg00050.html ,
> > I think it's time to completely remove multiarch-support from Sid (and
> > thus Buster).
> 
> That was my original plan, however the release team rejected that plan
> on IRC. A few packages in Stretch still depends on multiarch-support, so
> that might cause issues with apt during upgrade to Buster. This can
> therefore be only removed after Buster is released. Tagging the bug as
> wontfix in the meantime.
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: This is a digitally signed message part


Bug#910669: glibc: Please remove transitional package multiarch-support

2018-10-09 Thread Boyuan Yang
Source: glibc
Version: 2.27-6
X-Debbugs-CC: aure...@debian.org d...@debian.org
Severity: normal

Hi Aurelien, Matthias and Debian glibc maintainers,

As previously discussed in
https://lists.debian.org/debian-science/2018/08/msg00050.html ,
I think it's time to completely remove multiarch-support from Sid (and
thus Buster).

There's already no package in Sid (on amd64 platform) that depends on
multiarch-support. There is still one left in experimental
(openjdk-7-jre-headless) however it was due to its FTBFS in
experimental. Openjdk-7's source package has already removed it.
Please see https://bugs.debian.org/906117 for its details.

I do hope we could get rid of multiarch-support before Buster freeze.

P.S. doko: is it possible that #906117 eventually gets solved? That
would undoubtedly be helpful.

--
Regards,
Boyuan Yang