Hi Balint, On 2020-08-14 17:13, Balint Reczey wrote: > Hi Aurelien, > > On Fri, Aug 14, 2020 at 11:26 AM Aurelien Jarno <[email protected]> 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 [email protected] http://www.aurel32.net
