Re: ncurses update to 6.0
On Fri, Aug 21, 2015 at 04:18:51PM +0200, Miroslav Lichvar wrote: > On Fri, Aug 21, 2015 at 12:18:15PM +0100, Tom Hughes wrote: > > According to http://www.gnu.org/software/ncurses/ the new ABI should include > > symbol versioning, which would hopefully avoid the need for a repeat of this > > pain in the future, but as far as I can see none of the symbols in the > > current F23 build are versioned? > > The new ncurses libs are in rawhide only. The symbol versioning is > disabled by default and it's not enabled it in our spec. Enabling it > is easy, but if we wanted to disable it later, it would require > immediate rebuild of all ncurses applications, so I'd like to be sure > it is a good idea before doing so. > > I'm not sure if it would be possible to use symbol versioning for > compatibility when there are changes in definition of structures like > cchar_t, as there are between ABI 5 and ABI 6. I think the upstream > intention is to use it to mark new symbols, not compatibility. > > Hiding private symbols is definitely useful, but with the versioning > itself I think there could be some drawbacks, e.g. binaries built on > distros using the versioning won't run on distros not using it. > > Also, the number of different versions the symbols use seems to be > quite large, so there could be an increase in the rpmdb and yum repo > sizes. I guess that's not really a problem. None of those are particularly strong reasons, and they could apply to any library, but versioned libraries are still strongly preferred. Delaying the switch gains nothing. Everything will have to be rebuilt after the switch anyway, so it seems reasonable to do it now since you want to rebuild stuff for the new library anyway. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On Fri, Aug 21, 2015 at 12:18:15PM +0100, Tom Hughes wrote: > According to http://www.gnu.org/software/ncurses/ the new ABI should include > symbol versioning, which would hopefully avoid the need for a repeat of this > pain in the future, but as far as I can see none of the symbols in the > current F23 build are versioned? The new ncurses libs are in rawhide only. The symbol versioning is disabled by default and it's not enabled it in our spec. Enabling it is easy, but if we wanted to disable it later, it would require immediate rebuild of all ncurses applications, so I'd like to be sure it is a good idea before doing so. I'm not sure if it would be possible to use symbol versioning for compatibility when there are changes in definition of structures like cchar_t, as there are between ABI 5 and ABI 6. I think the upstream intention is to use it to mark new symbols, not compatibility. Hiding private symbols is definitely useful, but with the versioning itself I think there could be some drawbacks, e.g. binaries built on distros using the versioning won't run on distros not using it. Also, the number of different versions the symbols use seems to be quite large, so there could be an increase in the rpmdb and yum repo sizes. I guess that's not really a problem. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On 04/08/15 11:33, Miroslav Lichvar wrote: The ncurses upstream has released a first 6.0 version few months ago. The default ABI version has changed to 6, which enables some extensions to allow more colors, mouse wheel, etc. The ABI version 5 is still supported and can be selected with a configure option. We should switch to the new ABI, but we will probably want to provide the old ABI 5 libs even when all Fedora ncurses applications are rebuilt with the new ABI to not break 3rd party packages. Dependency on libncurses.so.5 or libtinfo.so.5 is pretty common. As for updating the ncurses package, my current plan is to build the libs in both ABIs (so there are four builds total with the wide and narrow versions), use the ncurses-libs subpackage for the new ABI 6 libs and create a new subpackage for ABI 5 libs. What would be a good name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, or something else? According to http://www.gnu.org/software/ncurses/ the new ABI should include symbol versioning, which would hopefully avoid the need for a repeat of this pain in the future, but as far as I can see none of the symbols in the current F23 build are versioned? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On Tue, Aug 18, 2015 at 11:38:08PM +0100, Richard W.M. Jones wrote: > guestfish uses APIs from readline and libtinfo directly. It does not > use ncurses APIs directly. > So it is overlinked, but IIRC that's because you had to use > `-lreadline -lncurses' to make readline work properly on some old > systems. Yeah, that was needed to allow the applications to make a choice between libtermcap and libncurses. > Can we replace that with `-lreadline'? > > Are there any implications for a program which actually uses > termcap/libtinfo functions also? If guestfish does need the terminfo functions, I think it should be linked with libtinfo or libncurses (on systems where libtinfo is not separated from libncurses). -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On Thu, Aug 13, 2015 at 04:35:00PM +0200, Miroslav Lichvar wrote: > On Tue, Aug 04, 2015 at 12:33:42PM +0200, Miroslav Lichvar wrote: > > As for updating the ncurses package, my current plan is to build the > > libs in both ABIs (so there are four builds total with the wide and > > narrow versions), use the ncurses-libs subpackage for the new ABI 6 > > libs and create a new subpackage for ABI 5 libs. What would be a good > > name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, > > or something else? > > Ok, the new ncurses package is now in rawhide. The name of the ABI 5 > subpackage is ncurses-compat-libs. > > I've also rebuilt the readline package to pick up the new libtinfo. > Binaries that are linked with both readline and ncurses/libtinfo (e.g. > gdb, bc, sqlite3) will now load both versions of libtinfo into memory, > which I suspect could be a problem. I tried some of them and they > don't seem to crash, but we might want to rebuild the packages to be > safe anyway. > > Here is a list of packages that seem to have binaries like that. I > suspect a lot of them are linked with ncurses unnecessarily. > > libguestfs-tools-c-1.31.1-3.fc24: /usr/bin/guestfish guestfish uses APIs from readline and libtinfo directly. It does not use ncurses APIs directly. $ eu-readelf -d /usr/bin/guestfish | grep NEEDED NEEDEDShared library: [libconfig.so.9] NEEDEDShared library: [libreadline.so.6] NEEDEDShared library: [libncurses.so.5] NEEDEDShared library: [libtinfo.so.5] NEEDEDShared library: [libguestfs.so.0] NEEDEDShared library: [libxml2.so.2] NEEDEDShared library: [libm.so.6] NEEDEDShared library: [libgcc_s.so.1] NEEDEDShared library: [libpthread.so.0] NEEDEDShared library: [libc.so.6] $ nm -D /usr/bin/guestfish | grep readline U readline 002fdb30 B rl_readline_name $ nm -D /usr/bin/guestfish | grep tget U tgetent U tgetnum So it is overlinked, but IIRC that's because you had to use `-lreadline -lncurses' to make readline work properly on some old systems. Can we replace that with `-lreadline'? Are there any implications for a program which actually uses termcap/libtinfo functions also? > ocaml-omake-0.9.8.6-0.rc1.fc24.20: /usr/bin/cvs_realclean > ocaml-omake-0.9.8.6-0.rc1.fc24.20: /usr/bin/omake Not sure about this one - it seems to use both readline and ncurses, but it's quite a big complicated program. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On Tue, Aug 04, 2015 at 12:33:42PM +0200, Miroslav Lichvar wrote: > As for updating the ncurses package, my current plan is to build the > libs in both ABIs (so there are four builds total with the wide and > narrow versions), use the ncurses-libs subpackage for the new ABI 6 > libs and create a new subpackage for ABI 5 libs. What would be a good > name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, > or something else? Ok, the new ncurses package is now in rawhide. The name of the ABI 5 subpackage is ncurses-compat-libs. I've also rebuilt the readline package to pick up the new libtinfo. Binaries that are linked with both readline and ncurses/libtinfo (e.g. gdb, bc, sqlite3) will now load both versions of libtinfo into memory, which I suspect could be a problem. I tried some of them and they don't seem to crash, but we might want to rebuild the packages to be safe anyway. Here is a list of packages that seem to have binaries like that. I suspect a lot of them are linked with ncurses unnecessarily. Macaulay2-1.6-15.fc24: /usr/bin/M2 afpfs-ng-0.8.1-19.fc23: /usr/bin/afpcmd afpfs-ng-0.8.1-19.fc23: /usr/bin/afpgetstatus afpfs-ng-0.8.1-19.fc23: /usr/lib64/libafpclient.so.0.0.0 airinv-1.00.1-5.fc24: /usr/bin/AirInvClient airinv-1.00.1-5.fc24: /usr/bin/AirInvServer airinv-1.00.1-5.fc24: /usr/bin/airinv airinv-1.00.1-5.fc24: /usr/bin/airinv_parseInventory airinv-1.00.1-5.fc24: /usr/lib64/libairinv.so.1.00.1 airrac-1.00.1-4.fc24: /usr/bin/airrac airrac-1.00.1-4.fc24: /usr/lib64/libairrac.so.1.00.1 airtsp-1.01.2-4.fc24: /usr/bin/airtsp airtsp-1.01.2-4.fc24: /usr/lib64/libairtsp.so.1.01.2 apachetop-0.15.6-1.fc23: /usr/bin/apachetop apt-0.5.15lorg3.95-21.git522.fc24: /usr/bin/apt-shell asymptote-2.35-3.fc23: /usr/bin/asy avrdude-6.1-3.fc23: /usr/bin/avrdude bc-1.06.95-15.fc23: /usr/bin/bc bird-1.5.0-1.fc23: /usr/sbin/birdc bird6-1.5.0-1.fc23: /usr/sbin/birdc6 cadaver-0.23.3-10.fc23: /usr/bin/cadaver cego-2.20.21-3.fc23: /usr/bin/cego cego-2.20.21-3.fc23: /usr/bin/cgadm cego-2.20.21-3.fc23: /usr/bin/cgblow cego-2.20.21-3.fc23: /usr/bin/cgclt cego-2.20.21-3.fc23: /usr/bin/cglog cgdb-0.6.8-2.fc23: /usr/bin/cgdb compat-guile18-1.8.8-11.fc24: /usr/lib64/libguilereadline-v-17.so.17.0.3 compat-lua-5.1.5-3.fc23: /usr/bin/lua-5.1 crash-7.1.2-1.fc23: /usr/bin/crash ddd-3.3.12-22.fc23: /usr/bin/ddd folks-tools-0.11.1-3.fc24: /usr/bin/folks-inspect freehoo-3.5.3-19.20100314cvs.fc23: /usr/bin/freehoo freetalk-4.0-0.3.rc4.fc23: /usr/bin/freetalk freetds-0.91-15.git0a42888.fc22: /usr/bin/fisql freetds-0.91-15.git0a42888.fc22: /usr/bin/tsql ftp-0.17-69.fc23: /usr/bin/ftp fuse-afp-0.8.1-19.fc23: /usr/bin/afpfsd fuse-afp-0.8.1-19.fc23: /usr/bin/mount_afp gdb-7.9.90.20150717-12.fc24: /usr/bin/gdb gdl-0.9.5-9.fc24: /usr/bin/gdl gdl-python-0.9.5-9.fc24: /usr/lib64/python2.7/site-packages/GDL.so ghc-readline-1.0.3.0-7.fc23: /usr/lib64/ghc-7.8.4/readline-1.0.3.0/libHSreadline-1.0.3.0-ghc7.8.4.so glusterfs-cli-3.7.3-1.fc24: /usr/sbin/gluster glusterfs-server-3.7.3-1.fc24: /usr/lib64/glusterfs/3.7.3/xlator/features/snapview-server.so glusterfs-server-3.7.3-1.fc24: /usr/sbin/glfsheal gnokii-0.6.31-12.fc23: /usr/bin/gnokii gnubg-1.04.000-1.fc22: /usr/bin/bearoffdump gnubg-1.04.000-1.fc22: /usr/bin/gnubg gnubg-1.04.000-1.fc22: /usr/bin/makebearoff gnubg-1.04.000-1.fc22: /usr/bin/makehyper gnubg-1.04.000-1.fc22: /usr/bin/makeweights gnucap-0.35-16.fc23: /usr/bin/gnucap gnucap-0.35-16.fc23: /usr/bin/gnucap-modelgen gnugo-3.8-11.fc23: /usr/bin/gnugo gnurobots-1.2.0-16.fc23: /usr/bin/gnurobots gretl-1.10.1-3.fc23: /usr/bin/gretlcli guile-2.0.11-6.fc23: /usr/lib64/libguilereadline-v-18.so.18.0.0 hugs98-2006.09-23.fc24: /usr/bin/ffihugs hugs98-2006.09-23.fc24: /usr/bin/hugs hugs98-2006.09-23.fc24: /usr/bin/runhugs insight-7.8.50-6.20140827git.fc23: /usr/bin/insight ipmitool-1.8.15-4.fc23: /usr/bin/ipmitool ipmitool-1.8.15-4.fc23: /usr/sbin/ipmievd kawa-2.0-2.fc23: /usr/bin/kawa kitutuki-0.9.6-10.fc23: /usr/bin/kitutuki kitutuki-0.9.6-10.fc23: /usr/lib64/libkitutuki.so.1.0 ldapvi-1.7-21.fc23: /usr/bin/ldapvi libgda-tools-5.2.2-10.fc23: /usr/bin/gda-sql-5.0 libguestfs-tools-c-1.31.1-3.fc24: /usr/bin/guestfish librep-0.92.5-1.fc23: /usr/lib64/rep/rep/io/readline.so lua-5.3.0-4.fc23: /usr/bin/lua malaga-7.12-18.fc23: /usr/bin/malaga malaga-7.12-18.fc23: /usr/bin/mallex maloc-1.5-9.fc23: /usr/lib64/libmaloc.so.1.0.0 mdk-1.2.8-2.fc23: /usr/bin/gmixvm mdk-1.2.8-2.fc23: /usr/bin/mixasm mdk-1.2.8-2.fc23: /usr/bin/mixguile mdk-1.2.8-2.fc23: /usr/bin/mixvm ngspice-23-8.fc21: /usr/bin/ngmakeidx ngspice-23-8.fc21: /usr/bin/ngmultidec ngspice-23-8.fc21: /usr/bin/ngnutmeg ngspice-23-8.fc21: /usr/bin/ngproc2mod ngspice-23-8.fc21: /usr/bin/ngsconvert ngspice-23-8.fc21: /usr/bin/ngspice nickle-2.77-8.fc23: /usr/bin/nickle ocaml-omake-0.9.8.6-0.rc1.fc24.20: /usr/bin/cvs_realclean ocaml-omake-0.9.8.6-0.rc1.fc24.20: /usr/bin/omake octave-4.0.0-4.fc24: /usr/lib64/octave/4.0.0/liboctave.so.3.0.0 opendbx-utils-1.4.6-8.fc23: /usr/bin/odbx-sql pal-0.4
Re: ncurses update to 6.0
On Wed, Aug 05, 2015 at 08:34:56PM -0400, Neal Gompa wrote: > On Aug 5, 2015 2:55 AM, "Miroslav Lichvar" wrote: > > On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote: > > > Are you looking to do this for F23 branch and rawhide or just rawhide > > > and have it land in F24 when it is ready? Or is that still to be > > > determined. > > > > I was thinking about doing this in rawhide only with no > > ncurses-specific rebuilds. After the next mass rebuild everything > > that didn't FTBFS should be using the ABI 6 libs. > If you can provide both versions, I don't see a reason to not provide it in > Fedora 23 branch too. We could just not force a rebuild in the branch and > do that only in rawhide. I'm not sure, it seems odd to me to have packages in a Fedora release which change their dependencies (e.g. libncurses.so.5 -> libncurses.so.6) after rebuild. Are others ok with that? -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On Aug 5, 2015 2:55 AM, "Miroslav Lichvar" wrote: > > On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote: > > On 4 August 2015 at 04:33, Miroslav Lichvar wrote: > > > As for updating the ncurses package, my current plan is to build the > > > libs in both ABIs (so there are four builds total with the wide and > > > narrow versions), use the ncurses-libs subpackage for the new ABI 6 > > > libs and create a new subpackage for ABI 5 libs. What would be a good > > > name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, > > > or something else? > > > > > > > Are you looking to do this for F23 branch and rawhide or just rawhide > > and have it land in F24 when it is ready? Or is that still to be > > determined. > > I was thinking about doing this in rawhide only with no > ncurses-specific rebuilds. After the next mass rebuild everything > that didn't FTBFS should be using the ABI 6 libs. > > -- > Miroslav Lichvar > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct If you can provide both versions, I don't see a reason to not provide it in Fedora 23 branch too. We could just not force a rebuild in the branch and do that only in rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote: > On 4 August 2015 at 04:33, Miroslav Lichvar wrote: > > As for updating the ncurses package, my current plan is to build the > > libs in both ABIs (so there are four builds total with the wide and > > narrow versions), use the ncurses-libs subpackage for the new ABI 6 > > libs and create a new subpackage for ABI 5 libs. What would be a good > > name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, > > or something else? > > > > Are you looking to do this for F23 branch and rawhide or just rawhide > and have it land in F24 when it is ready? Or is that still to be > determined. I was thinking about doing this in rawhide only with no ncurses-specific rebuilds. After the next mass rebuild everything that didn't FTBFS should be using the ABI 6 libs. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On 4 August 2015 at 04:33, Miroslav Lichvar wrote: > The ncurses upstream has released a first 6.0 version few months ago. > The default ABI version has changed to 6, which enables some > extensions to allow more colors, mouse wheel, etc. The ABI version 5 > is still supported and can be selected with a configure option. > > We should switch to the new ABI, but we will probably want to provide > the old ABI 5 libs even when all Fedora ncurses applications are > rebuilt with the new ABI to not break 3rd party packages. Dependency > on libncurses.so.5 or libtinfo.so.5 is pretty common. > > As for updating the ncurses package, my current plan is to build the > libs in both ABIs (so there are four builds total with the wide and > narrow versions), use the ncurses-libs subpackage for the new ABI 6 > libs and create a new subpackage for ABI 5 libs. What would be a good > name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, > or something else? > Are you looking to do this for F23 branch and rawhide or just rawhide and have it land in F24 when it is ready? Or is that still to be determined. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
