Mailinglist Archive: opensuse-factory (1324 mails)

< Previous Next >
Re: [opensuse-factory] Re: ncurses spec
  • From: Tomáš Čech <sleep_walker@xxxxxxxxxxxx>
  • Date: Tue, 6 Oct 2015 11:46:54 +0200
  • Message-id: <20151006094450.GA21422@venom>
On Mon, Oct 05, 2015 at 03:17:07PM +0200, Dr. Werner Fink wrote:
On Mon, Oct 05, 2015 at 02:42:24PM +0200, Tomáš Čech wrote:
On Mon, Oct 05, 2015 at 12:29:55PM +0200, Dr. Werner Fink wrote:
>On Sat, Oct 03, 2015 at 08:02:35AM +0200, Tomáš *ech wrote:
>>first, this is no attempt for trolling or wasting your precious
>>time. I only see room for improvement and can't really understand why
>>you handle ncurses in so complicated and "messy" way.
>>I was looking recently into ncurses spec file and I was more than confused:
>>1] why do you use screen during build? is that still valid requirement
>> or it is some remnant of old dark ages?
>The configuration of ncurses dependes on having a working terminal.
>the screen utility is not from old dark ages but is still relevant.
>Is you declare screen as old dark age and you declare ncurses
>as old dark age.

Can you tell me which part depends? It sounds a bit crazy that library
to create access to terminals independent depends on terminal during

Also, I haven't seen that in other distributions.

less +/"checking if poll really works" configure

Interesting, it really makes a difference whether poll() or select()
is used. Still, it is something you can skip with one sed command in

sed -i 's@^cf_cv_working_poll=no@cf_cv_working_poll=yes@' configure

(You can check it in home:sleep_walker:branches:Base:System/ncurses.)

Do you think that we could drop the screen from spec file now?

Maybe it is also worth of some patch upstream, I'll try to start

>>2] is really necesary to probe options through cflags()? Are these
>> options still required? How can one find that `-Wl,--hash-size=8599'
>> is the right value?
>I do this to speed up the load of the libncurses by the runtime
>linker. And this speeds up a lot, more that 8599 is not worth
>AFAIHS from my last tests.

I see, I'm afraid that it answers only the third question and still
some comment in the spec could help.

Probing compiler capabilities sounds useful in some corner cases
outside (open)SUSE.

I had done this e.g also for the bash due to a bug report
of IBM that system(3) had become slow due our compile options
to harden programs against

I'm not arguing about validity of reasons why the flags are there but
I can't see reason why to probe them.

Could you just drop lines 314-339 and replace lines 354-357 with

# fix slow system(3) calls (bnc#...), hash-size found experimentally
LDFLAGS="$LDFLAGS -Wl,-O2 -Wl,-Bsymbolic-functions -Wl,--hash-size=8599

You could also drop 351-353.

>>3] do we really want backward compatibility with ncurses 5.4 in
>> Factory/Tumbleweed/Leap? If so, why don't we use %ifarch for the
>> check?
>We do! The API of ABI 6 is different and there will programs
>which requires ole ABI 5.

But recent ncurses 5 version is 5.9 (2011-04-04), version 5.4 is
from 2004-02-08.

I know that file.

So? Do you still think that openSUSE people care about compatibility
with 5.4? Evergreen's effort are caring about 11.4 (which is
~2011). Regular maintenace is caring about 13.2 (2014), there is no
point in maintaining compatibility here.

Can we just drop lines 362-374?

>>4] what security benefit is in wiping TMPDIR?
>What is wrong with this? Remember that there are people which
>building their own ncurses in their local setup.

How can one feel more secure after wiping TMPDIR full of public source
code and it's compiled objects?

What are you talking about? In the spec file there is bash code
which exports a TMPDIR for all tools used by the configure script.
This path is not part of the ncurses package.

Please, just drop 375-380, it doesn't belong there.

>>5] gpm-devel library is not changing that frequently to have there
>> heuristics to find proper location
>There are people which let system libraries move fro, /lib(64) to

So it is for people, who builds locally ncurses outside chroot and who
moves gpm library from /usr/lib(|64) to /lib(|64). I guess they can
handle themselves and we don't need to be prepared for them in spec.

I do not agree.

You don't agree that such users can do it manually or that my
description of the only usecase is not correct?

>>6] what is 'correct fallback.c'?
>Depends on the architecture. Do you have understood what fallback.c does?

No, I was working with the spec, not with the fallback.c. I'd add comment there.

>It provides the fallback of the most common terminals if e.g.
>can not accessed due broken disk or in initrd.

Sounds like really nice thing to have. Upstream didn't accept that?


Do you have understood my comment? The fallback.c is a configure option
and the terminals have been choosen to fit with the most common terminals
used at SLES and openSUSE.

Sorry for the confusion. It is really not obvious what fallback.c
related parts does and it took me a while to understand it. If not
anything else, comment would be great.

It seems that ncurses author intended to use --with-fallbacks=...
configure option but you needed to run this part manually.

You need tinfo library and tic to prepare fallback.c to be used in
tinfo library. So you create some working fallback.c (with empty
FALLBACK_LIST) to build tinfo and tic to generate proper fallback.c.

If this is correct it should be fixed in upstream, shouldn't it?

Also, you can skip this part completely when cross-compiling.

And it would be nice to adjust configure to allow setting BUILD_TIC
from command line, right (so this fallback.c problem would be required
to solve only when building ncurses for platform where there was no
previous version of ncurses).

>>7] is there any effect of applying the same configure options multiple times?
>Yes, it overrides the already applied configure options.

Yes, apparently. I should state my question better - is it required to build


Could you please verify that?

I prepared shell script to compare results of
three different runs and it produces the same output. Is it possible
that it was needed before and not anymore?

>>8] why do we still build narrow character variant of libraries (in
>Ask the people out there.

They take packages from Base:System - the change must start here.

>>9] what about generating two separate packages with separated ABI
>> version (ncurses5, ncurses6)?

Why, we're doing that for other packages and it is nice way how to
specify which version you need.

Provide ncurses-devel from ncurses5-devel and ncurses6-devel, but you
can still specify ncurses5-devel if your application is not compatible
with recent changes...

I asked also Tomas Chvatal about that and there is no apparent
problem. Is there some technical reason behind this or it is just
personal preference?

>>10] why do we use different tack source? Are you aware of problems tack
>> author see in openSUSE?
>> (License versus Packaging)
>Tack is not part of ncurses and Tack has a different License.
>Discuss this with Thomas E. Dickey and not with me.

There is tack tarball added to ncurses package (replacing the one in
ncurses). If it is not part of ncurses, why it is not in separate
package? It would also have correct license and give Dickey creadit
for this package at the same time...

I've taken the *last* tack version and historically tack was/is part
ncurses and I've discussed this solution with Thomas E. Dickey
and he agreed with this if the License is for tack GPL-2.0+
whereas ncurses is MIT. Thomas E. Dickey is very sensitive on
that. Beside this the terminfo action checker is very useful.

I see. It seems it can't be done better than the current status in
this case. Thank you for explanation.

>>11] we do have patches guidelines, they may help understand why we
>> keep patches for months and why that patches were not pushed to
>> upstream
>Do you want become maintainer of ncurses?

If it is the only way to do the clean up, yes, I don't mind.

You're not aware what this takes. But I'll ask my teamlead if
you will become member of the arch team. Please note that this
is a core package and there will be only *one* maintainer for
openSUSE as well as for SLES.

1] I'm aware that this is core package and that is also reason why I
_do_ care about it and I composed that long e-mail with all those
difficult words.

2] As I said, I'm interested in cleaning up the spec file. I don't
think I need to be maintainer to do that. I don't mind becomming
maintainer of ncurses in openSUSE but please understand that I'm
doing that in my free time as an active community member and this
not a bit related to L3 archeology I do for a living.

@Stefan: Now what is about Tomáš Čech as new member of the arch
team and maintainer of the package ncurses.

Finally interesting offer! Tell me when the transfer is arranged, I'm
starting packing. TIA.

Thank you for your time to answer all my questions.

< Previous Next >
Follow Ups