Mailing List Archive

ncurses; I think I wrecked my fresh install
The previous couple of attempts, the install on my XPS 8940 died on
rebuilding ncurses when I copied over my full USE string from my current
desktop and updated world. This time around, I did it in pieces. I
added some variables, and emerged update, rinse-lather-repeat.. This
time the problem happened when I added...

"-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower -xinerama"

to the USE string. The ncurses build died, followed immediately by
bash.

Grub doesn't seem to work properly, i.e networking and other bootup
stuff did not take effect. I booted from the install USB, and set up
ssh. When I reach the chroot part, I get...

livecd /mnt/gentoo # mount --types proc /proc /mnt/gentoo/proc
livecd /mnt/gentoo # mount --rbind /sys /mnt/gentoo/sys
livecd /mnt/gentoo # mount --make-rslave /mnt/gentoo/sys
livecd /mnt/gentoo # mount --rbind /dev /mnt/gentoo/dev
livecd /mnt/gentoo # mount --make-rslave /mnt/gentoo/dev
livecd /mnt/gentoo # chroot /mnt/gentoo /bin/bash
/bin/bash: error while loading shared libraries: libtinfow.so.6: cannot open shared object file: No such file or directory

Here's my USE string, which works fine on two other machines...

USE="X apng ffmpeg introspection jpeg opengl openmp png szip truetype x264 x265 xorg threads vala -acl -arp -arping -berkdb -bindist -bles -caps -chatzilla -cracklib -crypt -elogind -filecaps -gallium -gdbm -gmp-autoupdate -graphite -gstreamer -iconv -ipc -iptables -ipv6 -jemalloc3 -libav -libglvnd -llvm -manpager -nls -pam -pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower -xinerama"

Any ideas? I have 2 other computers where it works just fine. On the
new machine it dies. A re-install is one thing. I just want to make
sure it doesn't die again on me. On my other machines I tried...

equery b libtinfow.so.6

...and also...

find / -name libtinfow*

Zip/zilch/nada. This appears to be something unique on the new
install. Is this a clue?

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On Mon, 28 Dec 2020 at 22:37, Walter Dnes <waltdnes@waltdnes.org> wrote:
>On my other machines I tried...
>
> equery b libtinfow.so.6

I think you need to use full paths with equery b.

I combined it with whereis to confirm that /usr/lib/libtinfow.so.6
belongs to ncurses, so I guess what you need to figure out is why your
ncurses build failed. You don't mention anything about it, so post any
info you have.

Regards,
Arve
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
Walter Dnes wrote:
> The previous couple of attempts, the install on my XPS 8940 died on
> rebuilding ncurses when I copied over my full USE string from my current
> desktop and updated world. This time around, I did it in pieces. I
> added some variables, and emerged update, rinse-lather-repeat.. This
> time the problem happened when I added...
>
> "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower -xinerama"
>
> to the USE string. The ncurses build died, followed immediately by
> bash.
>
> Grub doesn't seem to work properly, i.e networking and other bootup
> stuff did not take effect. I booted from the install USB, and set up
> ssh. When I reach the chroot part, I get...
>
> livecd /mnt/gentoo # mount --types proc /proc /mnt/gentoo/proc
> livecd /mnt/gentoo # mount --rbind /sys /mnt/gentoo/sys
> livecd /mnt/gentoo # mount --make-rslave /mnt/gentoo/sys
> livecd /mnt/gentoo # mount --rbind /dev /mnt/gentoo/dev
> livecd /mnt/gentoo # mount --make-rslave /mnt/gentoo/dev
> livecd /mnt/gentoo # chroot /mnt/gentoo /bin/bash
> /bin/bash: error while loading shared libraries: libtinfow.so.6: cannot open shared object file: No such file or directory
>
> Here's my USE string, which works fine on two other machines...
>
> USE="X apng ffmpeg introspection jpeg opengl openmp png szip truetype x264 x265 xorg threads vala -acl -arp -arping -berkdb -bindist -bles -caps -chatzilla -cracklib -crypt -elogind -filecaps -gallium -gdbm -gmp-autoupdate -graphite -gstreamer -iconv -ipc -iptables -ipv6 -jemalloc3 -libav -libglvnd -llvm -manpager -nls -pam -pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower -xinerama"
>
> Any ideas? I have 2 other computers where it works just fine. On the
> new machine it dies. A re-install is one thing. I just want to make
> sure it doesn't die again on me. On my other machines I tried...
>
> equery b libtinfow.so.6
>
> ...and also...
>
> find / -name libtinfow*
>
> Zip/zilch/nada. This appears to be something unique on the new
> install. Is this a clue?
>


This is what I get here:


root@fireball / # equery b libtinfow.so.6
 * Searching for libtinfow.so.6 ...
sys-libs/ncurses-6.2-r1 (/lib64/libtinfow.so.6 -> libtinfow.so.6.2)
sys-libs/ncurses-6.2-r1 (/usr/lib/libtinfow.so.6 -> libtinfow.so.6.2)
root@fireball / # emerge -p sys-libs/ncurses

[ebuild   R    ] sys-libs/ncurses-6.2-r1:0/6::gentoo  USE="gpm
(split-usr) threads (tinfo) unicode -ada -cxx -debug -doc -minimal
-profile -static-libs -test -trace" ABI_X86="32 (64) (-x32)"



Does that info help any? 

Dale

:-)  :-) 
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On 2020-12-28 16:36-0500 "Walter Dnes" <waltdnes@waltdnes.org> wrote:

> The previous couple of attempts, the install on my XPS 8940 died on
> rebuilding ncurses when I copied over my full USE string from my
> current desktop and updated world. This time around, I did it in
> pieces. I added some variables, and emerged update,
> rinse-lather-repeat.. This time the problem happened when I added...
>
> "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower
> -xinerama"
>
> to the USE string. The ncurses build died, followed immediately by
> bash.
>
> […]
>
> livecd /mnt/gentoo # chroot /mnt/gentoo /bin/bash
> /bin/bash: error while loading shared libraries: libtinfow.so.6:
> cannot open shared object file: No such file or directory

Both the tinfo and the unicode use-flags are necessary if you need
libtinfow.so. From the ebuild:

if multilib_is_native_abi ; then
gen_usr_ldscript -a \
"${NCURSES_TARGETS[@]}" \
$(use tinfo && usex unicode 'tinfow' '') \
$(usev tinfo)
fi


Bash depends on readline. If readline was built with USE="unicode" it
depends on ncurses[unicode]. Try `chroot /mnt/gentoo /bin/busybox sh`.
Busybox doesn't depend on readline so that should work. However,
portage uses bash for ebuilds if I'm not mistaken. If you have a
computer with a compatible CPU and unicode disabled you could quickpkg
bash there and try to install it on the new computer. Or maybe copying
/bin/bash over is enough.

unicode is one of the useflags that are a real pain to disable after
install. :-(

Kind regards, tastytea

--
Get my PGP key with `gpg --locate-keys tastytea@tastytea.de` or at
<https://tastytea.de/tastytea.asc>.
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On Mon, Dec 28, 2020 at 11:52:21PM +0100, tastytea wrote
>
> Bash depends on readline. If readline was built with USE="unicode" it
> depends on ncurses[unicode]. Try `chroot /mnt/gentoo /bin/busybox sh`.
> Busybox doesn't depend on readline so that should work. However,
> portage uses bash for ebuilds if I'm not mistaken. If you have a
> computer with a compatible CPU and unicode disabled you could quickpkg
> bash there and try to install it on the new computer. Or maybe copying
> /bin/bash over is enough.
>
> unicode is one of the useflags that are a real pain to disable after
> install. :-(

I did another install<G>. At the very beginning, after selecting
profile I emerged gentoolkit, and used it to track down additional
dependencies. I put "-unicode" in USE in make.conf and eventually ended
up running...

emerge -1 readline
emerge -1 nano procps util-linux
emerge -1 ncurses

Note: the order is extremely important. This was just before the
point where the manual said to run...

emerge --ask --verbose --update --deep --newuse @world

...which emerged 24 items, and would likely have led to more dependencies.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
Hi Walter,

> "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower
> -xinerama"

mostly out of curiosity, why do you want to disable unicode support here?

This feels odd to me since utf8 has effectively become the standard encoding
over the past years.

Cheers,
Andreas

--
Andreas K. H?ttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On 2020-12-29, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> Hi Walter,
>
>> "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower
>> -xinerama"
>
> mostly out of curiosity, why do you want to disable unicode support here?
>
> This feels odd to me since utf8 has effectively become the standard encoding
> over the past years.

I switched to a "unicode enabled" install many years ago, and I'm
about as much the "cranky old Unix guy" as you can get: I think that
mutt in an xterm qualifies as "GUI email client".

--
Grant
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On Tue, Dec 29, 2020 at 05:11:36PM +0200, Andreas K. Huettel wrote
> Hi Walter,
>
> > "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower
> > -xinerama"
>
> mostly out of curiosity, why do you want to disable unicode support
> here?
>
> This feels odd to me since utf8 has effectively become the standard
> encoding over the past years.

I don't know if this has improved over the years, but my initial
experience with unicode was rather negative. The fact that text
files were twice as large wasn't a major problem in itself. The
real showstopper was that importing text files into spreadsheets
and text-editors and word processors failed miseraby.

I looked at a unicode text file with a binary viewer. It turns out
that a simple text string like "1234" was actually...

"1" binary-zero "2" binary-zero "3" binary-zero "4" binary zero, etc.

This padding explains why the file was twice as large, and also why
"a simple textfile import" failed miserably.

On top of that Cyrillic letters like "m", "i", "c", and "o" are
considered different from their English equivalants. Security experts
showed proof-of-cocept attacks where clicking on "microsoft.com" can
take you to a hostile domain (queue the jokes). I don't speak or read
or write any languages which have thousands of unique characters.
Seeing Chinese spam "as it was intended to be seen", is not a priority
for me.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On 2020-12-29, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Tue, Dec 29, 2020 at 05:11:36PM +0200, Andreas K. Huettel wrote
>> Hi Walter,
>>
>> > "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower
>> > -xinerama"
>>
>> mostly out of curiosity, why do you want to disable unicode support
>> here?
>>
>> This feels odd to me since utf8 has effectively become the standard
>> encoding over the past years.
>
> I don't know if this has improved over the years, but my initial
> experience with unicode was rather negative. The fact that text
> files were twice as large wasn't a major problem in itself. The
> real showstopper was that importing text files into spreadsheets
> and text-editors and word processors failed miseraby.

You must be talking about some sort of weird "wide" encoding (is there
such a thing as UTF-16?). I've never seen a file like that. Everybody
and everything uses UTF-8 these days and has for years. UTF-8 is a
superset of ASCII, and doesn't increase size of the file unless
non-ascii characters are used. Converting an ASCII file to UTF-8
encoding is a noop. An ASCII file _is_ UTF-8.

> I looked at a unicode text file with a binary viewer. It turns out
> that a simple text string like "1234" was actually...
>
> "1" binary-zero "2" binary-zero "3" binary-zero "4" binary zero, etc.
>
> This padding explains why the file was twice as large, and also why
> "a simple textfile import" failed miserably.

I've never seen a file like that. All the Unicode I run into is UTF-8,
and a UTF-8 file with the string "1234" is the same exact 4 bytes as
an ASCII file with the string "1234".

> On top of that Cyrillic letters like "m", "i", "c", and "o" are
> considered different from their English equivalants. Security experts
> showed proof-of-cocept attacks where clicking on "microsoft.com" can
> take you to a hostile domain (queue the jokes). I don't speak or read
> or write any languages which have thousands of unique characters.
> Seeing Chinese spam "as it was intended to be seen", is not a priority
> for me.
Re: Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On 30/12/20 01:04, Grant Edwards wrote:
> You must be talking about some sort of weird "wide" encoding (is there
> such a thing as UTF-16?). I've never seen a file like that. Everybody
> and everything uses UTF-8 these days and has for years. UTF-8 is a
> superset of ASCII, and doesn't increase size of the file unless
> non-ascii characters are used. Converting an ASCII file to UTF-8
> encoding is a noop. An ASCII file _is_ UTF-8.

There is utf-16 - MS's default version. They wrote their unicode support
*before* utf-8 really was a thing. So we have the nix's settling on an
8-bit char, and MS settling on a 16-bit char BEFORE that. Unbaking that
mess would be fun ...

So that file is probably something to do with MS and ASCII-16 :-)

Cheers,
Wol
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
> I don't know if this has improved over the years, but my initial
> experience with unicode was rather negative. The fact that text
> files were twice as large wasn't a major problem in itself. The
> real showstopper was that importing text files into spreadsheets
> and text-editors and word processors failed miseraby.
>
> I looked at a unicode text file with a binary viewer. It turns out
> that a simple text string like "1234" was actually...
> "1" binary-zero "2" binary-zero "3" binary-zero "4" binary zero, etc.

That's (as someone has already pointed out) UTF-16, which is the default for
some Windows tools (but understood in Linux too). (Even UTF-32 exists where
all characters are 4 byte wide, but I've never seen it in the wild.)

UTF-8 is normally used on Linux (and ASCII chars look exactly the same there);
even for "long characters" outside the ASCII range spreadsheets and word
processors should not be a problem anymore.

--
Andreas K. H?ttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
> On top of that Cyrillic letters like "m", "i", "c", and "o" are
> considered different from their English equivalants. Security experts
> showed proof-of-cocept attacks where clicking on "microsoft.com" can
> take you to a hostile domain (queue the jokes).

That's true, though registrars are filtering for it now. Also, I just checked,
e.g. firefox always builds with unicode support (it would have trouble with a
lot of websites otherwise).

(: ????po??un s?op osl? ?u??l? l??? ?no? u??? ¿s??? p??? no? u?? '??q

> I don't speak or read
> or write any languages which have thousands of unique characters.
> Seeing Chinese spam "as it was intended to be seen", is not a priority
> for me.

Not even Klingon?!

--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On 30/12/2020 16:35, Andreas K. Huettel wrote:
>> I don't know if this has improved over the years, but my initial
>> experience with unicode was rather negative. The fact that text
>> files were twice as large wasn't a major problem in itself. The
>> real showstopper was that importing text files into spreadsheets
>> and text-editors and word processors failed miseraby.
>>
>> I looked at a unicode text file with a binary viewer. It turns out
>> that a simple text string like "1234" was actually...
>> "1" binary-zero "2" binary-zero "3" binary-zero "4" binary zero, etc.
>
> That's (as someone has already pointed out) UTF-16, which is the default for
> some Windows tools (but understood in Linux too). (Even UTF-32 exists where
> all characters are 4 byte wide, but I've never seen it in the wild.)
>
> UTF-8 is normally used on Linux (and ASCII chars look exactly the same there);
> even for "long characters" outside the ASCII range spreadsheets and word
> processors should not be a problem anymore.
>
Following up on my previous answer, you need to separate in your mind
UTF the character set, and UTF-x the representation. When UTF was
introduced MS - in accordance with the thoughts of the time - thought
the future was a 16-bit char, which can store 32 thousand characters.
(Note that, BY DEFINITION, the high bit of a UTF character *must* be
zero. Just like standard ASCII.)

So MS and Windows uses UTF-16 as its encoding. Unix LATER went down the
route of UTF-8 which - I think - can only encode 16 thousand characters
in two bytes, but because most (western) text does encode successfully
in one byte is actually a major saving in network operations such as
email, web etc which is where Unix has traditionally been very strong.

But UTF-16 works very well for MS, because they are primarily desktop,
and UTF-16 means that there are very few multi-char characters. That
reduces pressure on CPU, which is a desktop-limited resource.

And lastly, very importantly, given that AT PRESENT all characters can
be encoded in 31 bits, UTF-32 the representation is equivalent to UTF
the character set. But should we need more than 2 billion characters,
there is nothing stopping us rolling out characters encoded in two
32-bit chars, and UTF-64.

Cheers,
Wol
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
On 30/12/2020 17:30, Andreas K. Huettel wrote:
> That's true, though registrars are filtering for it now. Also, I just checked,
> e.g. firefox always builds with unicode support (it would have trouble with a
> lot of websites otherwise).
>
> (: ????po??un s?op osl? ?u??l? l??? ?no? u??? ¿s??? p??? no? u?? '??q

Except something's wrong because eg "d" renders correctly upside down,
but "t" clearly has the wrong baseline, and looking at the serifs "l"
isn't upside down at all.

Cheers,
Wol
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
Am Mittwoch, 30. Dezember 2020, 20:01:32 EET schrieb antlists:
> On 30/12/2020 17:30, Andreas K. Huettel wrote:
> > That's true, though registrars are filtering for it now. Also, I just
> > checked, e.g. firefox always builds with unicode support (it would have
> > trouble with a lot of websites otherwise).
> >
> > (: ????po??un s?op osl? ?u??l? l??? ?no? u??? ¿s??? p??? no? u?? '??q
>
> Except something's wrong because eg "d" renders correctly upside down,
> but "t" clearly has the wrong baseline, and looking at the serifs "l"
> isn't upside down at all.

True. There is no "upside down" character set, this just relies on accidental
/ partial / best effort matches.

--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
Maybe I should've kept quiet. The unicode fanbois probably saw this
thread and decided to get heavy-handed. On my latest pretend update,
I'm getting 8 (eight) rebuilds with "(unicode*)" being the reason.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: ncurses; I think I wrecked my fresh install [ In reply to ]
Am Dienstag, 19. Januar 2021, 04:21:35 EET schrieb Walter Dnes:
> Maybe I should've kept quiet. The unicode fanbois probably saw this
> thread and decided to get heavy-handed. On my latest pretend update,
> I'm getting 8 (eight) rebuilds with "(unicode*)" being the reason.

That would've been me. And yes... where the impact is low (*) we'll enable it
unconditionally now.

Python relies on unicode being present, the default locale in stages is
C.UTF-8, ... too many central parts of the system just assume it's there.
You'll be assimilated, resistance is futile.

(*) In any case, if large libraries like ICU are needed for unicode support,
we'll keep a useflag, but in that case the flag is called e.g. icu.

--
Andreas K. H?ttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)