Re: glibc 2.32 packaging
On 2020-08-18 22:53, Aurelien Jarno wrote:
> Hi Balint,
>
> On 2020-08-14 17:13, Balint Reczey wrote:
> > Hi Aurelien,
> >
> > On Fri, Aug 14, 2020 at 11:26 AM Aurelien Jarno <aurelien@aurel32.net> wrote:
> > >
> > > Hi,
> > >
> > > On 2020-08-14 00:18, Balint Reczey wrote:
> > > > Hi,
> > > >
> > > > I plan landing 2.32 in Ubuntu in the next weeks and I'd happily
> > > > contribute to the Debian packaging as well.
> > >
> > > Thanks!
> > >
> > > > The Ubuntu packaging repository is at:
> > > > https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/glibc/+git/glibc
> > > >
> > > > There is a also staging one with WIP branches:
> > > > https://code.launchpad.net/~rbalint/ubuntu/+source/glibc/+git/glibc
> > >
> > > Before starting packaging 2.32, we need to do the nsl and rpc
> > > transitions, that's why nothing has been started on 2.32 yet. I think
> > > that has to be done in 2 steps:
> > > - nsl transition: packaging libnsl [1] and libnss-nis [2] and build
> > > glibc without --enable-obsolete-nsl. I have started working on libnsl,
> > > but unfortunately all rdeps don't build. I have stopped working on
> > > that this week, I think I'll find some time to work on that next
> > > week, then I'll push my work to git.
> > > - rpc transition: we need to package rpcsvc-proto and build without
> > > --enable-obsolete-rpc. I have also starting working on that, but then
> > > realized we have to take care of nsl first.
> >
> > I agree that splitting the tasks ahead to three steps minimizes impact
> > at any given during the transitions but also makes the overall impact
> > staying with us longer. In Ubuntu we would like to have 2.32 in 20.10,
> > thus I'm aiming at doing the transition with the 2.32 switch.
> > If you have WIP packages you would be kind enough to share them on
> > Salsa I'd happily help with those, too. Otherwise I'll need to go
> > ahead and package them from scratch, too, to start testing the
> > transition in a PPA.
>
> Ok. I have finished with the libnsl and libnss-nis* packages, they are
> on salsa in the glibc-team. I'll now try again to rebuild all rdeps and
> if everything works, I'll upload them to experimental.
I have uploaded all those packages to experimental, they are now in NEW.
We have a small issue with libnss-nis which doesn't build on Hurd [1],
let's hope we can fix it while the package sits in NEW.
> > > > Aurelien, I'd also be interested in the rpcsvc-proto package you
> > > > mentioned earlier [1] and I'd start maintaining it if Josue is not
> > > > interested immediately.
> > >
> > > Let's wait a bit from a possible answer from Josue given it's a holiday
> > > period.
> >
> > I'll happily hand over the packages to Josue if he is interested, but
> > next week I need to start testing the rpcsvc-proto package and if you
> > could share the initial packaging that would help a bit and would not
> > harm anyone I think .
>
> We don't need a maintainer for now, the package should not be in the
> archive until we are ready for the transition as it basically conflicts
> with libc6-dev.
>
> Now that I am done with the libnsl and libnss-nis* packages, I'll finish
> the rpcsvc-proto packaging, and I'll push it to salsa the same way.
I have pushed rpcsvc-proto to salsa [2]. I have chosen to have a single
binary package, while for example fedora is using one package for the
headers and one for rpcgen. As rpcsvc-proto is Multiarch: foreign, I am
not sure it is worth having 2 binary packages.
We can probably decide later anyway as it is enough to detect all the
FTBFS that need to be fixed. It seems we have many packages to port to
TI RPC. As it happens often the packaging is the easy part!
I have started to fill a few bugs [3].
Regards,
Aurelien
[1] https://github.com/thkukuk/libnss_nis/issues/9
[2] https://salsa.debian.org/aurel32/rpcsvc-proto
[3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=rpc-removal;users=debian-glibc@lists.debian.org
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: