Re: glibc 2.32 packaging

2020-08-20 Thread Aurelien Jarno
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  
> > 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
aurel...@aurel32.net http://www.aurel32.net



Re: glibc 2.32 packaging

2020-08-18 Thread Aurelien Jarno
Hi Balint,

On 2020-08-14 17:13, Balint Reczey wrote:
> Hi Aurelien,
> 
> On Fri, Aug 14, 2020 at 11:26 AM Aurelien Jarno  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.

> > > On Salsa there is no branch yet for 2.32 as I see and I'm wondering if
> > > there is a git repository which accepts merge proposals.
> > >
> > > I think setting up CI on Salsa would also be useful, at least I use it
> > > for most of my packages.
> >
> > We haven't enabled MR on salsa as nobody really monitors it and we don't
> > want things to bitrot there. We can enable it, but it should not become
> > a duplication of the BTS.
> 
> I'd happily open MRs and open bugs referring to them as the proposed patches.
>
> I've forked the glibc repository but I can't enable CI for my fork
> presumably because it is not enabled in the original repo either.
> Could you please enable CI setting the configuration file to
> debian/gitlab-ci.yml or something else under debian/ ? This should not
> impact the main repo since the config file is not present but would
> let me experiment in my fork.

I have enabled MR and CI in the glibc project.

> > > 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.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Re: glibc 2.32 packaging

2020-08-14 Thread Balint Reczey
Hi Aurelien,

On Fri, Aug 14, 2020 at 11:26 AM Aurelien Jarno  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.

> > On Salsa there is no branch yet for 2.32 as I see and I'm wondering if
> > there is a git repository which accepts merge proposals.
> >
> > I think setting up CI on Salsa would also be useful, at least I use it
> > for most of my packages.
>
> We haven't enabled MR on salsa as nobody really monitors it and we don't
> want things to bitrot there. We can enable it, but it should not become
> a duplication of the BTS.

I'd happily open MRs and open bugs referring to them as the proposed patches.

I've forked the glibc repository but I can't enable CI for my fork
presumably because it is not enabled in the original repo either.
Could you please enable CI setting the configuration file to
debian/gitlab-ci.yml or something else under debian/ ? This should not
impact the main repo since the config file is not present but would
let me experiment in my fork.

> > 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 .

Cheers,
Balint

>
> Cheers,
> Aurelien
>
> [1] https://github.com/thkukuk/libnsl
> [2] https://github.com/thkukuk/libnss_nis
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
--
Balint Reczey
Ubuntu & Debian Developer



Re: glibc 2.32 packaging

2020-08-14 Thread Aurelien Jarno
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.
 
> On Salsa there is no branch yet for 2.32 as I see and I'm wondering if
> there is a git repository which accepts merge proposals.
>
> I think setting up CI on Salsa would also be useful, at least I use it
> for most of my packages.

We haven't enabled MR on salsa as nobody really monitors it and we don't
want things to bitrot there. We can enable it, but it should not become
a duplication of the BTS.

> 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.

Cheers,
Aurelien

[1] https://github.com/thkukuk/libnsl
[2] https://github.com/thkukuk/libnss_nis

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



glibc 2.32 packaging

2020-08-13 Thread Balint Reczey
Hi,

I plan landing 2.32 in Ubuntu in the next weeks and I'd happily
contribute to the Debian packaging as well.

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

On Salsa there is no branch yet for 2.32 as I see and I'm wondering if
there is a git repository which accepts merge proposals.

I think setting up CI on Salsa would also be useful, at least I use it
for most of my packages.

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.

Cheers,
Balint

[1] https://lists.debian.org/debian-glibc/2020/08/msg00026.html
-- 
Balint Reczey
Ubuntu & Debian Developer