On Mon, Oct 05, 2015 at 01:01:42PM +0200, Andreas Schwab wrote:

"Dr. Werner Fink" writes:

...

The configuration of ncurses dependes on having a working terminal.

What does screen provide that /dev/tty doesn't?

Screen does use a real pty/tty pair whereas in autobuild a simple redirect to plain /dev/tty is tested by tty(1) as not a tty. This had happen several times for several packages in past and therefore I use screen as tty wrapper. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

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:

...

Hi,

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 configuration. Also, I haven't seen that in other distributions.

...

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.

...

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. http://invisible-island.net/ncurses/announce-5.9.html

...

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?

...

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 /usr/lib(64)

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.

...

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. /usr/share/terminfo can not accessed due broken disk or in initrd.

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

...

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 properly?

...

8] why do we still build narrow character variant of libraries (in Factory/Tumbleweed/Leap)?

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)?

NO

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

...

10] why do we use different tack source? Are you aware of problems tack author see in openSUSE?

http://invisible-island.net/ncurses/tack.html (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...

...

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

https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines

Do you want become maintainer of ncurses?

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

With kind regards

Thank you for all your answers. Best regardsm Tomas Cech

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:

...

Hi,

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

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 %prep: 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 discussion.

...

...

...

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 -Wl,--as-needed" 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.

http://invisible-island.net/ncurses/announce-5.9.html

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 /usr/lib(64)

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. /usr/share/terminfo 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 properly?

Yes.

Could you please verify that? I prepared shell script http://sprunge.us/NTQj 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 Factory/Tumbleweed/Leap)?

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)?

NO

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?

http://invisible-island.net/ncurses/tack.html (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

https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines

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

On Monday 2015-10-05 12:29, Dr. Werner Fink wrote:

...

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

NO

But we already have that in 13.2 (libncurses5, libncurses6). So - issue marked solved. (If you meant two seaprate SRPMs, then I also go for "no", since both are easily buildable from the single tarball.)

...

10] why do we use different tack source? Are you aware of problems tack author see in openSUSE?

http://invisible-island.net/ncurses/tack.html (License versus Packaging)

Tack is not part of ncurses and Tack has a different License.

If it is not part of ncurses, then it should become its own .spec. (Like "which.spec" once did.) Irrespective of license. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2015-10-06 13:04, Tomáš Čech wrote:

...

But we already have that in 13.2 (libncurses5, libncurses6). So - issue marked solved. (If you meant two seaprate SRPMs, then I also go for "no", since both are easily buildable from the single tarball.)

1] not that easily 2] when you use ncurses-devel, it won't let you choose ABI version on RPM level

Oh yeah, ncurses5-devel / ncurses6-devel sounds like a good idea. Then again, we already have pkgconfig(ncurses{,w}{5,6}) so there is not soo much to be gained. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org