Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Helmut, On 2020-08-26 17:43, Helmut Grohne wrote: > Hi Vineet, > > On Wed, Aug 26, 2020 at 02:39:53PM +, Vineet Gupta wrote: > > Following up as ARC glibc port was merged upstream in 2.32. Can we now give > > rebootstrap a spin for ARC Debian enablement. > > That's great news. Unfortunately, it's not that easy yet. rebootstrap > requires the relevant software to be packaged for Debian and the glibc > packaging has only reached 2.31 yet. 2.32 is not even in experimental > yet. > > Trying rebootstrap with an experimental glibc is not entirely trivial, > but possible. > > Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to > experimental anytime soon? No it's not planned soon. glibc 2.32 has removed support for nsl and rpc, so we first have to do the transition to their replacement. That is libnsl, libnss-nis and libnss-nisplus for nsl, and rpcsvc-proto and libtirpc3 for rpc. The nsl transition is in good state, but the packages are stuck in NEW. We've started to work on the rpc transition, however there is a lot more work, we have at least ~50 packages that FTBFS and need to be manually patched to use libtirpc3 instead of the glibc implementation. We definitely need to use experimental to test those two transitions and ask for archive rebuilds, so it's not possible to upload a 2.32 package there. > Alternatively, can we segregate the relevant diff between 2.31 and 2.32 > and apply it to the unstable package without bumping the version? I don't think that's really possible, new ports introduced in version 2.32 will have all the symbol versions set to GLIBC_2.32. Regards, Aurelien PS Helmut: Once libnsl, libnss-nis and libnss-nisplus are out of NEW, you might want to see if they can be cross-built, and if that impacts the bootstrap process as the glibc packages are going to depend on those (in the same way as for the libxcrypt transition). -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: maintaining rpcsvc-proto / future of rpc in glibc
Hi Josue, On 2020-08-23 15:49, Josue Ortega wrote: > Hi Aurelien, > > On Thu, Aug 06, 2020 at 12:13:45PM +0200, Aurelien Jarno wrote: > > Hi Josue, > > > > I am contacting you as the maintainer of libtirpc. As you might be aware > > rpc support is dropped from glibc starting with version 2.32. libtirpc > > and rpcsvc-proto [1] are supposed to replace it. > > Thanks for the heads up > > > rpcsvc-proto is missing in Debian, I have packaged it locally to test > > how we can handle the transition. I am planning to open a WNPP bug soon. > > Are you interested to maintain it? Or co-maintain it with the glibc > > team? > > I am OK co-maintaining rpcsvc-proto with the glibc team. Thanks for your positive answer. I have pushed a preliminary version of the packaging on salsa [1]. You should have maintainer access to that project. Please feel free to do some changes if you feel them necessary. Here is the status: - So far 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. But other opinions are welcome. - I haven't done the ITP yet. - glibc 2.32 removed support for both nsl and rpc. We have been working first on the nsl transition which should be mostly ready by now, just sitting in NEW. We should prepare for the rpc transition, but I don't think we need to upload it yet to the archive, as the upload need to be coordinated with a glibc upload. - The idea is that when glibc is built without rpc support, the libc6-dev package depends on libtirpc-dev and rpcsvc-proto. - A few weeks ago I have identified packages that do not build once nsl and rpc are removed from glibc. Now we need to identify and fix the ones that still do not built when using libtirpc-dev and rpcsvc-proto. I have already submitted a few patches there [3]. Please also note that Balint Reczey also expressed interest in co-maintaining this package. Balint, is it still the case? If so, I'll also give you access to the project on salsa. Regards, Aurelien [1] https://salsa.debian.org/glibc-team/rpcsvc-proto [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=rpc-removal;users=debian-glibc@lists.debian.org [3] https://people.debian.org/~aurel32/glibc-rpc-nsl-removal/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
[Git][glibc-team/rpcsvc-proto][master] Update Uploader and Maintainers field, add VCS entries
Aurelien Jarno pushed to branch master at GNU Libc Maintainers / rpcsvc-proto Commits: cc5e6f51 by Aurelien Jarno at 2020-08-26T22:59:20+02:00 Update Uploader and Maintainers field, add VCS entries - - - - - 1 changed file: - debian/control View it on GitLab: https://salsa.debian.org/glibc-team/rpcsvc-proto/-/commit/cc5e6f511cc21be1ab56bfedb69347f963369341 -- View it on GitLab: https://salsa.debian.org/glibc-team/rpcsvc-proto/-/commit/cc5e6f511cc21be1ab56bfedb69347f963369341 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/rpcsvc-proto][master] 2 commits: New upstream version 1.4.2
Aurelien Jarno pushed to branch master at GNU Libc Maintainers / rpcsvc-proto Commits: 2ba969fa by Aurelien Jarno at 2020-08-02T13:38:25+02:00 New upstream version 1.4.2 - - - - - ab4b62ec by Aurelien Jarno at 2020-08-19T23:45:51+02:00 Add debian packaging - - - - - 5 changed files: - − .gitignore - + ABOUT-NLS - + INSTALL - + Makefile.in - NEWS View it on GitLab: https://salsa.debian.org/glibc-team/rpcsvc-proto/-/compare/e295c9a3b67752734995dfc057bfbf5313ed0d82...ab4b62ec562abb0036d50ea1c40117ca1013b29f -- View it on GitLab: https://salsa.debian.org/glibc-team/rpcsvc-proto/-/compare/e295c9a3b67752734995dfc057bfbf5313ed0d82...ab4b62ec562abb0036d50ea1c40117ca1013b29f You're receiving this email because of your account on salsa.debian.org.
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Vineet, On Wed, Aug 26, 2020 at 02:39:53PM +, Vineet Gupta wrote: > Following up as ARC glibc port was merged upstream in 2.32. Can we now give > rebootstrap a spin for ARC Debian enablement. That's great news. Unfortunately, it's not that easy yet. rebootstrap requires the relevant software to be packaged for Debian and the glibc packaging has only reached 2.31 yet. 2.32 is not even in experimental yet. Trying rebootstrap with an experimental glibc is not entirely trivial, but possible. Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to experimental anytime soon? Alternatively, can we segregate the relevant diff between 2.31 and 2.32 and apply it to the unstable package without bumping the version? Helmut
