[gentoo-user] !!!!

[Alan Grimes]

Like a stupid dumbfuck, I tried to update my machine today....

tortoise ~ # revdep-rebuild
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot
open shared object file: No such file or directory
tortoise ~ # ufed
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory

Couldn't determine EPREFIX and PORTDIR from Portage
INIT failed--call queue aborted.
tortoise ~ #

!!!!

GOOD JOB, PENGUINS!!!
I won't even be able to reboot my machine!!!

A+ configuration management....


--
IQ is a measure of how stupid you feel.

Powers are not rights.

[Jeff Smelser]

What did you update? Nothing I remember recently came out to break like this.

[Dale]

Did you update ncurses by any chance? According to a look up, that file
belongs to that package. I might also add, I don't have that file here
at all. Sort of odd that I don't have it but portage works fine here.

Dale

:-) :-)

[Meik Frischke]

Seems like ncurses was recompiled without the "tinfo" use flag. You could try booting up a rescue system and unpack a precompiled bash package from another (trusted) system to get your machine working again and continue from there.

[Dale]

That would make sense.  Just a FYI tho, I don't have that USE flag enabled here either.

[ebuild   R    ] sys-libs/ncurses-5.9-r3:5::gentoo  USE="gpm unicode -ada -cxx -debug -doc -minimal -profile -static-libs -tinfo -trace" ABI_X86="32 (64) (-x32)" 0 KiB 

This may be one of those times where having the binaries for older packages would come in handy.  Just find it, untar it and then fix it so that it works right. 

Dale

:-)  :-) 

[Grant Edwards]

On 2015-08-18, Dale <rdale...@gmail.com> wrote:

> Alan Grimes wrote:

>> tortoise ~ # revdep-rebuild
>> /bin/bash: error while loading shared libraries: libtinfo.so.5: cannot
>> open shared object file: No such file or directory

[...]

> Did you update ncurses by any chance? According to a look up, that
> file belongs to that package. I might also add, I don't have that
> file here at all. Sort of odd that I don't have it but portage works
> fine here.

I don't have any libtinfo.<whatever> on any of my systems either. By
default, I don't think a separate libtinfo is built. One suggestion I
saw for this problem (on a different distro) is to symlink libtinfo to
libncurses.

--
Grant Edwards grant.b.edwards Yow! Edwin Meese made me
at wear CORDOVANS!!
gmail.com

[Jeremi Piotrowski]

On Tue, 18 Aug 2015, Dale wrote:
> Grant Edwards wrote:
> > On 2015-08-18, Dale <rdale...@gmail.com> wrote:
> > I don't have any libtinfo.<whatever> on any of my systems either. By
> > default, I don't think a separate libtinfo is built. One suggestion I
> > saw for this problem (on a different distro) is to symlink libtinfo to
> > libncurses.

Ncurses can be compiled as a single library or as two (ncurses + tinfo),
in either case all the symbols are present on the system it's just a
question of where they are located.

Many packages are not prepared to handle the seperate tinfo library, we
have many bugs in the bugzilla that deal with tracking down such build
failures and correcting them. But this is the first I hear of anyone
having a problem with the reverse.

Symlinking libtinfo to libncurses *should* work, or atleast seems like a
valid rescue attempt.


> Maybe we will get some replies from the OP soon.

Would help, I too don't recall any serious updates lately.

[Dale]

Grant Edwards wrote:
> On 2015-08-18, Dale <rdale...@gmail.com> wrote:
>> Alan Grimes wrote:
>>> tortoise ~ # revdep-rebuild
>>> /bin/bash: error while loading shared libraries: libtinfo.so.5: cannot
>>> open shared object file: No such file or directory
> [...]
>
>> Did you update ncurses by any chance? According to a look up, that
>> file belongs to that package. I might also add, I don't have that
>> file here at all. Sort of odd that I don't have it but portage works
>> fine here.
> I don't have any libtinfo.<whatever> on any of my systems either. By
> default, I don't think a separate libtinfo is built. One suggestion I
> saw for this problem (on a different distro) is to symlink libtinfo to
> libncurses.
>

I did a google search, I got three or four hits. That sort of makes me
think that there is a bad setting somewhere. Since no one else has
posted about this, I doubt a dev did it because if they did, I'd think
others would be hitting this problem too.

Maybe we will get some replies from the OP soon.

Dale

:-) :-)

[walt]

In addition to the suggestions already made by other posters, it's good
to keep busybox in mind. Depending on how you boot your machine, there
is usually a way you can pass 'init=/bin/bb' to the kernel at boot time.

You can do wonderful stuff with busybox when you're in a bind.

[Dale]

And for the future, this could be very handy.

FEATURES="buildpkg"

That goes in or added to the current line in make.conf. That little
thing has saved my bacon more than once.

Dale

:-) :-)

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 19/08/15 10:41, Dale wrote:
>
> And for the future, this could be very handy.
>
> FEATURES="buildpkg"
>
> That goes in or added to the current line in make.conf. That
> little thing has saved my bacon more than once.
>

For system-critical packages when all other hope is lost, there's also

http://packages.gentooexperimental.org/packages/

I haven't seen anything that says exactly what packages this provides,
but I would assume @system.
- --
wraeth <wra...@wraeth.id.au>
GnuPG Key: B2D9F759
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXT01gACgkQXcRKerLZ91nkgQD5AXDsupX07+3AitX013BJiQct
tB7+6vD+lly0X8qmICQA/jj0PJJzPqWeBX+zW8orxZ0ngZ2Pqf6UhdAS1djQGA/o
=/glH
-----END PGP SIGNATURE-----

[John Campbell]

On 08/18/2015 05:29 PM, walt wrote:
> On Tue, 18 Aug 2015 15:52:53 -0400
> Alan Grimes <ALON...@verizon.net> wrote:
>

> In addition to the suggestions already made by other posters, it's good
> to keep busybox in mind. Depending on how you boot your machine, there
> is usually a way you can pass 'init=/bin/bb' to the kernel at boot time.
>
> You can do wonderful stuff with busybox when you're in a bind.

I haven't really been following this closely but I haven't seen any
suggestion to use "emerge -1 --quiet=y smart-live-rebuild" to remove
the offending curses output. Hopefully emerge doesn't check/use curses
unless it's producing actual output.

[walt]

On Tue, 18 Aug 2015 18:03:31 -0700
John Campbell <jdc...@cox.net> wrote:

> I haven't really been following this closely but I haven't seen any
> suggestion to use "emerge -1 --quiet=y smart-live-rebuild" to remove
> the offending curses output. Hopefully emerge doesn't check/use
> curses unless it's producing actual output.

A very obscure hint, and I like it :) I have no trouble emerging
packages (at the moment) so I emerged app-portage/smart-live-rebuild,
which dragged in eselect-package-manager as a dependency.

'eselect package-manager list' shows only portage as installed, even
though I now also have porthole and smart-live-rebuild installed too.

Do you see something different?

[John Campbell]

On 08/18/2015 06:38 PM, walt wrote:
> On Tue, 18 Aug 2015 18:03:31 -0700
> John Campbell <jdc...@cox.net> wrote:
>

>> I haven't really been following this closely but I haven't seen any
>> suggestion to use "emerge -1 --quiet=y smart-live-rebuild" to remove
>> the offending curses output. Hopefully emerge doesn't check/use
>> curses unless it's producing actual output.
>

> A very obscure hint, and I like it :) I have no trouble emerging
> packages (at the moment) so I emerged app-portage/smart-live-rebuild,
> which dragged in eselect-package-manager as a dependency.
>
> 'eselect package-manager list' shows only portage as installed, even
> though I now also have porthole and smart-live-rebuild installed too.
>
> Do you see something different?

I only have portage as a manager. You probably have to re-emerge
porthole to get it to show up.

Your problem seems to be a portage/ncurses mismatch. Once you fix that
you should be able to at least see the output from your initial
"smart-live-rebuild"

Whenever I have a problem with python throwing out library mismatch
errors I look to emerge everything from the program to the library.
Something along the way has probably lost it's library... And as
python's an interpreted language revdep-rebuild won't find it.

Do you get different output from "emerge @smart-live-rebuild" than from
"smart-live-rebuild"? I personally don't use the "smart-live-rebuild"
script but instead rely on the "emerge @smart-live-rebuild" set. But
that's just my preference and really shouldn't make any difference.

How about "emerge --color=n --nospinner -p @smart-live-rebuild" Color
and spinners are the only things in portage that should be using curses.

Maybe "emerge --quiet=y -a @smart-live-rebuild"

[Fernando Rodriguez]

On Wednesday, August 19, 2015 12:14:46 AM Jeremi Piotrowski wrote:
> On Tue, 18 Aug 2015, Dale wrote:
> > Grant Edwards wrote:
> > > On 2015-08-18, Dale <rdale...@gmail.com> wrote:
> > > I don't have any libtinfo.<whatever> on any of my systems either. By
> > > default, I don't think a separate libtinfo is built. One suggestion I
> > > saw for this problem (on a different distro) is to symlink libtinfo to
> > > libncurses.
>
> Ncurses can be compiled as a single library or as two (ncurses + tinfo),
> in either case all the symbols are present on the system it's just a
> question of where they are located.
>
> Many packages are not prepared to handle the seperate tinfo library, we
> have many bugs in the bugzilla that deal with tracking down such build
> failures and correcting them. But this is the first I hear of anyone
> having a problem with the reverse.

It could happen if the tinfo flag is removed (perhaps as an attempt to build
one of the many broken packages). If the tinfo library is not preserved
everything that linked against it stops working. That's one of the many
problems with the current approach to this use flag (patching the multitude of
broken packages). I patched my ncurses ebuild to build and install both a full
ncurses along with a tinfo library, that causes the most packages to link
against curses only so no rebuild is necessary after removing the use flag,
everything builds ok and only binary packages use libtinfo. I posted the patch
on the tinfo tracker but no one seems interested.

> Symlinking libtinfo to libncurses *should* work, or atleast seems like a
> valid rescue attempt.

It's worth a shot, but it doesn't work for all packages. I think it depends on
the linking order.

PS: There's a post by wraeth on this thread, is anybody having problems
opening it? kmail crashes everytime I try.

--
Fernando Rodriguez

[Dale]

Fernando Rodriguez wrote:
> PS: There's a post by wraeth on this thread, is anybody having
> problems opening it? kmail crashes everytime I try.

It opens fine here. It's short and has a GnuPG v2 signature attached at
the bottom. Could that be the cause of the problem? I don't see
anything else in the message.

Dale

:-) :-)

[wraeth]

On 19/08/15 15:26, Fernando Rodriguez wrote:
> PS: There's a post by wraeth on this thread, is anybody having problems
> opening it? kmail crashes everytime I try.

Does this (unsigned) message cause kmail to crash?

[J. Roeleveld]

Opens fine here as well, using kmail 4.14.8

--
Joost

[Fernando Rodriguez]

On Wednesday, August 19, 2015 4:03:59 PM wraeth wrote:
> On 19/08/15 15:26, Fernando Rodriguez wrote:
> > PS: There's a post by wraeth on this thread, is anybody having problems
> > opening it? kmail crashes everytime I try.
>
> Does this (unsigned) message cause kmail to crash?
>

No, that's it. I also noticed after sending my last message that the Sign and
Encrypt toolbar buttons are greyed out. I'll figure it out tomorrow.

--
Fernando Rodriguez

[wraeth]

The only other distinct thing I can see about my message in this thread
is that mine had a URL in the body (excluding email addresses above
quotes). Would one of you mind posting something with a URL in it?

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 19/08/15 16:31, Fernando Rodriguez wrote:

> The akonadictl magic fixed it. I tried it before, I think it worked
> now because I closed kmail first :)
>

And your messages are coming through signed now, too.

Though I don't use KDE, can you describe what Akonadi black arts fixed
it? May come in handy for others who get the same issue.
- --

wraeth <wra...@wraeth.id.au>
GnuPG Key: B2D9F759

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXUJAoACgkQXcRKerLZ91n3vgD9G0wwtznoNGMQJdgVYYmxewdC
U7ZPIGFuwf08tyQ77VYA/jI+4LPMgN63+8YzIJlK1lKnKbUYqsPmdWidW768uWR6
=gcwH
-----END PGP SIGNATURE-----

[Fernando Rodriguez]

On Wednesday, August 19, 2015 2:25:20 AM Fernando Rodriguez wrote:

The akonadictl magic fixed it.
I tried it before, I think it worked now because I closed kmail first :)

--
Fernando Rodriguez

[J. Roeleveld]

random URL:

http://xkcd.com/386/

[J. Roeleveld]

On Wednesday, August 19, 2015 04:37:03 PM wraeth wrote:
> On 19/08/15 16:31, Fernando Rodriguez wrote:
> > On Wednesday, August 19, 2015 2:25:20 AM Fernando Rodriguez wrote:
> >> On Wednesday, August 19, 2015 4:03:59 PM wraeth wrote:
> >>> On 19/08/15 15:26, Fernando Rodriguez wrote:
> >>>> PS: There's a post by wraeth on this thread, is anybody
> >>>> having problems opening it? kmail crashes everytime I try.
> >>>
> >>> Does this (unsigned) message cause kmail to crash?
> >>
> >> No, that's it. I also noticed after sending my last message that
> >> the Sign
> >
> > and
> >
> >> Encrypt toolbar buttons are greyed out. I'll figure it out
> >> tomorrow.
> >
> > The akonadictl magic fixed it. I tried it before, I think it worked
> > now because I closed kmail first :)
>
> And your messages are coming through signed now, too.
>
> Though I don't use KDE, can you describe what Akonadi black arts fixed
> it? May come in handy for others who get the same issue.

> --
> wraeth <wra...@wraeth.id.au>
> GnuPG Key: B2D9F759

My guess would be:
# akonadictl restart
?

I changed over to using postgresql instead of mysql for akonadi and I have not
had any issues requiring a restart of akonadi since. (Granted, only a few days
so far, but suspend-to-disk was problematic before the change)

--
Joost

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I aprove of this random URL! :D

That being said, turns out it was related to some Akonadi
wonderfulness with gpg configuration - resolved now by some as-yet
undefined black magic.
- --

wraeth <wra...@wraeth.id.au>
GnuPG Key: B2D9F759

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXUJz0ACgkQXcRKerLZ91kNlgD/ZjZbrlkmrJsvRnf2ws5JqE7U
guxWy2UI1JKj81fMDVwA/R3GqL2Ze57WpU/wcVzk6cDc7zXdGdQJ9MsmhsYD+2+v
=Bowj
-----END PGP SIGNATURE-----

[Fernando Rodriguez]

Yes, I forgot to type the restart part. I'll have to give postgresql a shot
cause I need to restart quite often when using this account (imap with a lot
of folders). On another box I got a POP3 account and an IMAP with a few
folders and rarely need to restart. Never had this specific problem before
though. It usually just stops downloading emails.
--
Fernando Rodriguez

[J. Roeleveld]

How I currently have it:
1) Postgresql running globally
2) useraccount/database for akonadi
3) configured akonadi to use the global database (eg. NOT started by akonadi)

If you let akonadi start the database, it doesn't perform that well.

--
Joost

[Marc Joliet]

Am Tue, 18 Aug 2015 20:13:53 -0700
schrieb John Campbell <jdc...@cox.net>:

> And as
> python's an interpreted language revdep-rebuild won't find it.

Huh? If Python is the problem, I would think it's because its C implementation
uses dlopen(3) instead of linking at build time (which could apply to anything).

--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[Jeremi Piotrowski]

On Tue, 18 Aug 2015, John Campbell wrote:
> On 08/18/2015 06:38 PM, walt wrote:
> > On Tue, 18 Aug 2015 18:03:31 -0700
> > John Campbell <jdc...@cox.net> wrote:
> >
> > > I haven't really been following this closely but I haven't seen any
> > > suggestion to use "emerge -1 --quiet=y smart-live-rebuild" to remove
> > > the offending curses output. Hopefully emerge doesn't check/use
> > > curses unless it's producing actual output.

From the initial post it seems that the binary that has a problem is
bash/sh. They are both linked against tinfo/ncurses. And since portage
runs using bash... you see where I'm going with this. You could maybe use
a different shell (although I can't imagine a shell not using the terminal
capabilities ;) ), but still wouldn't be able to use portage.

> Maybe "emerge --quiet=y -a @smart-live-rebuild"

Smart live rebuild only deals with live ebuilds. How would it help in this
case?

[John Campbell]

>> Maybe "emerge --quiet=y -a @smart-live-rebuild"
>

> Smart live rebuild only deals with live ebuilds. How would it help in this
> case?

It seems I miss-remembered from the first post, looking back I see it
was revdep-rebuild, not smart-live-rebuild.

[Grant Edwards]

On 2015-08-19, John Campbell <jdc...@cox.net> wrote:

> How about "emerge --color=n --nospinner -p @smart-live-rebuild" Color
> and spinners are the only things in portage that should be using curses.

IMO, emerge should not be doing stuff like that for two reasons:

1) It's broken: the assumptions made about what colors are actually
legible is wrong if you use terminals with white backgrounds. I
have to turn off colors just to make the default output legible.

2) It introduces dependencies like this which should be minimized in
something as central to the system as emerge.

--
Grant Edwards grant.b.edwards Yow! I haven't been married
at in over six years, but we
gmail.com had sexual counseling every
day from Oral Roberts!!

[Mick]

Anyone cares to explain what is a "live ebuild"?

Then I may be able to understand what @smart-live-rebuild may be useful for.
:-/

--
Regards,
Mick

[Alec Ten Harmsel]

A "live ebuild" is an ebuild that pulls the code to build straight from
whatever version control the developers are using, so you always have
the latest and greatest.

Alec

[Alan McKinnon]

they usually have version number -9999

--
Alan McKinnon
alan.m...@gmail.com

[Jeremi Piotrowski]

portage has no way of knowing if the repository the package comes from
has been updated without fetching the sources and this is done during the
merge process. So portage has no knowledge of the state of live-ebuild
packages prior to starting a merge - it doesn't know if they have been
updated upstream, so it does nothing to them during normal updates.

To update them you can use the set @live-rebuild. But this causes live
packages to be unconditionally rebuilt even if they haven't changed.

Smart-live-rebuild deals with this by updating the repositories and then
only re-emerging packages that have been changed.

[Grant Edwards]

On 2015-08-19, Alec Ten Harmsel <al...@alectenharmsel.com> wrote:
> On Wed, Aug 19, 2015 at 08:55:16PM +0100, Mick wrote:
>
>> Anyone cares to explain what is a "live ebuild"?

> A "live ebuild" is an ebuild that pulls the code to build straight
> from whatever version control the developers are using, so you always
> have the latest and greatest.

Well, always the latest anyway. :)

One thing to remember with such an ebuild is that you can do two
identical "emerge" commands a few seconds apart using the exact same
ebuild file and end up with two different versions of whatever you're
building. That can make troubleshooting things like USE flags rather,
ah, entertaining. Some "live" ebuilds try to ameliorate this problem
by grabbing a daily or weekly snapshot instead of the "head".

Another thing to remember is that portage doesn't keep track of what
version was fetched, so once you've installed a "live" ebuild, it
won't ever get updated no matter how many subsequent changes have been
commited to the version control system.

--
Grant Edwards grant.b.edwards
at
gmail.com

[Mick]

On Wednesday 19 Aug 2015 21:22:02 Jeremi Piotrowski wrote:
> On Wed, 19 Aug 2015, Alan McKinnon wrote:
> > On 19/08/2015 21:58, Alec Ten Harmsel wrote:
> > > On Wed, Aug 19, 2015 at 08:55:16PM +0100, Mick wrote:
> > >> On Wednesday 19 Aug 2015 10:28:48 Jeremi Piotrowski wrote:
> > >>> Smart live rebuild only deals with live ebuilds. How would it help in
> > >>> this case?
> > >>
> > >> Anyone cares to explain what is a "live ebuild"?
> > >>
> > >> Then I may be able to understand what @smart-live-rebuild may be
> > >> useful for.
> > >>
> > >> :-/
> > >

> > > A "live ebuild" is an ebuild that pulls the code to build straight from
> > > whatever version control the developers are using, so you always have
> > > the latest and greatest.
> > >
> > > Alec
> >
> > they usually have version number -9999
>
> portage has no way of knowing if the repository the package comes from
> has been updated without fetching the sources and this is done during the
> merge process. So portage has no knowledge of the state of live-ebuild
> packages prior to starting a merge - it doesn't know if they have been
> updated upstream, so it does nothing to them during normal updates.
>
> To update them you can use the set @live-rebuild. But this causes live
> packages to be unconditionally rebuilt even if they haven't changed.
>
> Smart-live-rebuild deals with this by updating the repositories and then
> only re-emerging packages that have been changed.

Thank you all, I learned something new today. :-)

I would usually only update -9999 packages when I want to get a later version
and with some trepidation because the latest isn't always the greatest.

So, it has always been a manual exercise for me.
--
Regards,
Mick

[Lee]

This has operator error written all over it especially given this operator's level of maturity.

On Aug 18, 2015 1:32 PM, "Jeff Smelser" <trad...@gmail.com> wrote:

What did you update? Nothing I remember recently came out to break like this.

On Tue, Aug 18, 2015 at 2:52 PM, Alan Grimes <ALON...@verizon.net> wrote:

Like a stupid dumbfuck, I tried to update my machine today....

tortoise ~ # revdep-rebuild
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot
open shared object file: No such file or directory
tortoise ~ # ufed
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory
sh: error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory

Couldn't determine EPREFIX and PORTDIR from Portage
INIT failed--call queue aborted.
tortoise ~ #

!!!!

GOOD JOB, PENGUINS!!!
I won't even be able to reboot my machine!!!

A+ configuration management....


--
IQ is a measure of how stupid you feel.

Powers are not rights.

[Neil Bothwick]

On Wed, 19 Aug 2015 15:10:40 +0000 (UTC), Grant Edwards wrote:

> IMO, emerge should not be doing stuff like that for two reasons:
>
> 1) It's broken: the assumptions made about what colors are actually
> legible is wrong if you use terminals with white backgrounds. I
> have to turn off colors just to make the default output legible.

That's why there is the option to choose appropriate colours
in /etc/portage/color.map.


--
Neil Bothwick

C:\DOS\SYSTEM\OS2\UTILITIES\DOCS\HELP\WHERE\THE\F$#%\AM\I???