| View previous topic :: View next topic |
| Author |
Message |
gohmdoree
Guru
Joined: 12 Oct 2004
Posts: 533
|
 Posted: Tue Jul 13, 2010 9:58 pm Post subject: |
 |
|
| Still in the process here, but no hiccups as I've had before. |
|
| Back to top |
|
 |
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Wed Jul 14, 2010 5:38 am Post subject: |
|
|
| Joseph_sys wrote: | I see it:
net-misc/nxclient-3.4.0.5 (=media-libs/libpng-1.2*
any work around it, or I have to have installed both Libpng-1.2 and 1.4 |
You need both as long as nxclient need the 1.2 version
_________________
|
|
| Back to top |
|
|
Joseph_sys
Advocate
Joined: 08 Jun 2004
Posts: 2716
Location: Edmonton, AB
|
| Posted: Thu Jul 15, 2010 8:10 pm Post subject: |
|
|
Your solution with libpng upgrade worked perfect on two of my machine, thank you.
But on one of my machines (main production one) I'm still using kde-3.5 (due to some package that are not available in kde-4).
Will I have any problem upgrading with libpng-1.4.3 running:
revdep-rebuild --library libpng12.so.0 |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1859
|
| Posted: Sat Jul 17, 2010 7:12 pm Post subject: |
|
|
I've only had one machine that's been synced since libpng-1.4.3 went stable. I had done an "emerge -auDvN system world" but had not done any revdep-rebuild.
I decided to go with Flameeye's suggested approach:
http://blog.flameeyes.eu/2010/06/29/stable-users-libpng-update
Before I did so however I temporarily unmerged opera, as many had mentioned it wanting to pull in 1.2...not sure if I needed that. I've also added --as-needed to my machines...wasn't even aware of that one.
His approach seemed to work perfectly...not a hitch. After I was done I reinstalled opera and everything's great. I'm confused by all the posts here referring to installing libpng 1.2 in a slot to get opera working. It's working fine for me without it...perhaps it has to do with use flags.
Tom |
|
| Back to top |
|
|
dsamersoff
n00b
Joined: 20 Feb 2007
Posts: 30
Location: St.Petersburg,Russia
|
| Posted: Sun Jul 18, 2010 7:12 am Post subject: |
|
|
Hit the same issue.
Three simlinks (below) solves the problem of packages with hardcoded refernces to png12 (e.g. vlc), but
of course it's not a good way.
This link have to be created by emerge libpng:1.2
libpng12.so -> libpng12.so.0
These dependency should be removed from offending package code
libpng12.la -> libpng14.la
pkgconfig/libpng12.pc -> libpng14.pc
_________________
*There will come soft rains ... |
|
| Back to top |
|
|
Angrychile
Apprentice
Joined: 27 Oct 2009
Posts: 235
|
| Posted: Mon Jul 19, 2010 4:49 pm Post subject: |
|
|
| I have a question. Why was this update added to portage if it had such an ability to break things...even when it isn't required by any packages yet? |
|
| Back to top |
|
|
dsamersoff
n00b
Joined: 20 Feb 2007
Posts: 30
Location: St.Petersburg,Russia
|
| Posted: Mon Jul 19, 2010 8:58 pm Post subject: |
|
|
There are three questions bother Russians in every hard situation like this one: who is guilty, what I should do, can I it chicken by hands. I guess the second question only make sense.
_________________
*There will come soft rains ... |
|
| Back to top |
|
|
Angrychile
Apprentice
Joined: 27 Oct 2009
Posts: 235
|
| Posted: Mon Jul 19, 2010 10:56 pm Post subject: |
|
|
| I know, I'm just frustrated after an almost complete day of work. I know I should be thankful that there is any way out at all ,and that those who know it are willing to share. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Wed Jul 21, 2010 6:09 pm Post subject: |
|
|
| Angrychile wrote: | | I know, I'm just frustrated after an almost complete day of work. I know I should be thankful that there is any way out at all ,and that those who know it are willing to share. |
I understand the frustration. And the pain.
As my {extremely limited} understanding goes in this instance, there are a variety of issues that all combined to make this unexpectedly painful. I still don't understand all I've read about it to be perfectly honest. Part of it has to do with how portage works. Part of it has to do because Gentoo as a distribution is not standardized on the "as-needed" flag. Part of it has to do with the general dependency issue of how you handle multiple versions of the same dependencies when various end user packages work only with disparate versions.
What makes libpng especially tough is that it's a core dependency for a lot of desktop packages ... and which has had a lot of security issues come to light recently. libpng is the standard library used to display Portable Network Graphics image files. i.e. 'png' pictures. Basically, any package which displays pngs uses this library. So security is a relatively 'high' priority which means related updates are a high priority.
On my main system, I have 85 packages which list libpng as a direct dependency. Some of these packages are pretty important dependencies for still other packages. For example: qt-gui-4* list libpng as a direct dependency. Which means virtually all kde packages are indirectly dependent. Other foundation type packages which list libpng as a direct dependency on my system include: gtk+-2*, webkit-gtk, DirectFB, imagemagick and lots more.
Don't forget that all these packages are independently developed with different goals. Many end user packages are developed with functionality first. Security and Distributor functionality is almost always an afterthought. After all, we're talking about literally thousands of packages with 10s of thousands of developers. Referring to all these independent groups and developers as "Upstream" should never allow anyone to forget how complicated this can be. The fact that things work as well as they do is simply amazing.
Also don't forget, the Gentoo devs basically have taken on the responsibility for backwards compatibility. In a sense, it's silly that still two versions of portage. It's not merely a matter of the difference between 'stable' and 'unstable'. The unstable branch of portage has been going on for a long, long time now {someone else will have to provide timing info}. As an end user, the most visible difference I see between the two is the support for preserved-rebuild functionality. Even though this isn't complete yet, the functionality present appears to be stable and useful enough to bring everyone up to at least this level. i.e. Some of the promised features are there and some aren't. This is just my opinion and I can {and probably am) not fully understanding what I'm reading.
When you combine security issues with a core desktop dependency, the question isn't going to be "Will any of our users suffer?" It'a a given that the answer is emphatically YES! Instead, the question is "How many of our users will suffer?" and the follow on question is "What can we do to reduce that suffering to the smallest number possible.
There are some apparent problems with how portage resolves complicated dependency issues. Based on my readings, I get the notion there is more than one complicated issue and there is disagreement on how to resolve some of them. The issues really do seem to be quite complex and would require a much, much longer post to begin to describe them.
We as Gentoo End Users can do a lot to help ourselves pro-actively. Based on my readings, these are the things I do to keep a clean system: - I accept the fact that 'emerge --sync && emerge -uND world' has limitations. I don't just run a world update and expect that everything will be a) hunky and b) dory. Gentoo devs have no control over "Upstream". Within the context of what Upstream provides, portage does a darn good job most times.
- edited to reflect changes to default profiles as of August 1, 2010 --
Prior to 2010-08-01, the 'as-needed' flag was not part of the default profile. If you're still running an older profile {for some reason you're not doing 'emerge --sync' any more ... } then add 'as-needed' like the shown partial listing from my make.conf file as an example: | Code: | #
# linker options
# -Wl,-O1 tells the linker to build larger hash tables
# -Wl,--as-needed tells linker to only included linked libraries where program actually needs symbols
LDFLAGS="-Wl,-O1 -Wl,--as-needed" |
On the other hand, post the 2010-08-01 default profile update which now includes 'as-needed', you either need to remove any line(s) setting LDFLAGS or change those line(s) to make your custom settings additive as this partial listing demonstrates: | Code: | #
# linker options
# -Wl,-O1 tells the linker to build larger hash tables
LDFLAGS="${LDFLAGS} -Wl,-O1" |
The directive to the linker to build larger hash tables is considered generally safe and results in {slightly} faster code with {slightly} more overhead.
Ensure that 'lafilefixer --justfixit' gets run regularly. One of the issues with portage is that unneeded .la files are not updated/removed for most ebuilds as they should be. This is one of those 'complicated issue' regarding things like how to keep backwards compatability with older ebuilds, when and where .la files should be dealt with during an ebuild process, what happens when packages are slotted and you have a mix of older and newer functionality ebuilds and yada-yada-yada. The immediate answer for us as end users is simply to run lafilefixer regularly. The current suggestion is to include the following in /etc/portage/bashrc: | Code: | post_src_install() {
lafilefixer "${D}"
} |
As a heads up: .la files are apparently due to be permanently dropped at some future time. I still don't personally understand all this but that is considered the future direction. Adding this snippet will be a 'good' thing for maintaining your long term sanity.
Run 'revdep-rebuild -i -p' after every emerge and especially after every 'emerge world'. This is more on the order of a 'safety net' for yourself.
After each time you run revdep-rebuild, also run 'emerge --depclean -p'. Inspect the packages to be removed for sanity, and then run 'emerge --depclean'. Because so few people do this, they end up trying to update essentially abandoned packages and forcing the dev's limited time trying to fix stuff which should be gone.
Read and deal with the emerge results messages. I have to be honest here. I still have problems with this myself.
Hope this helps! I'll add an update later with links to selected pertinent sources. {links added}
{edit July 21, 2010}
Reminder: One of the contributing factors for the pain of the libpng update has been that it is a direct dependency for many core packages. This means the effects of any bugs in libpng will propagate out to many, many packages. Some of which you may not expect on a first look. If you're interested, the following links are required reading:- PNG Reference Library: libpng - root of all things PNG
- Security Advisory for libpng-1.4.0 and earlier, 27 February 2010 - self explanatory
- Changes to Libpng from version 1.2.43 to 1.4.1 (February 25, 2010) - self explanatory - That said, it's an excellent read for understanding some of the source of upgrade issues. It's especially eye-opening when one thinks about things like 'backwards compatibility' and adding functionality to an existing core library. Really.
- libpng - lead page describing libpng - a 'must read' simply for the one paragraph write up describing the latest fixed libpng security vulnerability. The fix for this was release June 25, 2010. Hence the latest round of updates.
- Stable users' libpng update - "flameeyes" blog write up. Source for 'lafilefixer' suggestion among other things regarding updating libpng. In addition to the blog entry itself, it is enlightening to read the pair of comments marked "about 23 hours later". The first is a "heads up" regarding future libpng-1.5 from Upstream. The second is flameeyes response. Nothing at all bad or negative in either comment. But very informative.
_________________
People whom think M$ is mediocre, don't know the half of it.
Last edited by dufeu on Wed Aug 04, 2010 2:06 am; edited 1 time in total |
|
| Back to top |
|
|
rpil
Guru
Joined: 23 May 2008
Posts: 314
|
| Posted: Tue Jul 27, 2010 11:45 am Post subject: |
|
|
| Code: | funtoo drphibes # eix media-libs/libpng
[I] media-libs/libpng
Available versions:
(1.2) 1.2.44
(0) 1.4.3
Installed versions: 1.4.3(11:09:51 07/05/10)
Homepage: http://www.libpng.org/
Description: Portable Network Graphics library |
I have the 1.4.3 version of libpng. So, there is no upgrade issue.
Last two weeks, after the world update, I receive a message about preserved libs in my Funtoo installation thet need rebuilding:
| Code: | * - /usr/lib/libpng12.so.0.43.0
* used by /usr/bin/gnome-cups-add (net-print/gnome-cups-manager-0.33-r1)
* used by /usr/bin/gnome-cups-icon (net-print/gnome-cups-manager-0.33-r1)
* used by /usr/bin/gnome-cups-manager (net-print/gnome-cups-manager-0.33-r1)
* used by 107 other files
Use emerge @preserved-rebuild to rebuild packages using these libraries |
I give the command, it reinstalls, for example:
| Code: | funtoo drphibes # emerge -pv @preserved-rebuild
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-office/abiword-plugins-2.6.8 USE="cxx gnome jpeg pdf readline svg -debug -grammar -jabber -libgda -math -ots -thesaurus -wmf -wordperfect" 0 kB
[ebuild R ] gnome-base/gnome-panel-2.28.0 USE="policykit -doc -eds -networkmanager" 0 kB
[ebuild R ] net-print/gnome-cups-manager-0.33-r1 USE="-debug" 0 kB
[ebuild R ] mail-client/evolution-2.28.3.1 USE="crypt dbus hal ldap python ssl -exchange -gstreamer -kerberos -krb4 -mono -networkmanager -nntp -pda -profile" 0 kB
Total: 4 packages (4 reinstalls), Size of downloads: 0 kB
funtoo drphibes # |
Today's packages:
| Code: | !!! existing preserved libs:
>>> package: media-libs/libpng-1.4.3
* - /usr/lib/libpng12.so
* - /usr/lib/libpng12.so.0
* - /usr/lib/libpng12.so.0.43.0
* used by /usr/bin/gnome-cups-add (net-print/gnome-cups-manager-0.33-r1)
* used by /usr/bin/gnome-cups-icon (net-print/gnome-cups-manager-0.33-r1)
* used by /usr/bin/gnome-cups-manager (net-print/gnome-cups-manager-0.33-r1)
* used by 107 other files |
When it finishes, same message again! How can i get rid of this?
My PC arch is i686. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Tue Jul 27, 2010 1:40 pm Post subject: |
|
|
| rpil wrote: | | Code: | funtoo drphibes # eix media-libs/libpng
[I] media-libs/libpng
Available versions:
(1.2) 1.2.44
(0) 1.4.3
Installed versions: 1.4.3(11:09:51 07/05/10)
Homepage: http://www.libpng.org/
Description: Portable Network Graphics library |
I have the 1.4.3 version of libpng. So, there is no upgrade issue.
Last two weeks, after the world update, I receive a message about preserved libs in my Funtoo installation thet need rebuilding:
| Code: | * - /usr/lib/libpng12.so.0.43.0
* used by /usr/bin/gnome-cups-add (net-print/gnome-cups-manager-0.33-r1)
* used by /usr/bin/gnome-cups-icon (net-print/gnome-cups-manager-0.33-r1)
* used by /usr/bin/gnome-cups-manager (net-print/gnome-cups-manager-0.33-r1)
* used by 107 other files
Use emerge @preserved-rebuild to rebuild packages using these libraries |
|
This is due to an extra "libpng12" artifact being on your system. Go to page 7 of this thread and look for my first post on that page. It shows how I resolved this problem for me and it gives you the link to where Flameeyes discusses the problem on his blog.
Also read my post just before your post for more information and suggestions.
Everything you need to know is here starting from page 7 on this thread.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
rpil
Guru
Joined: 23 May 2008
Posts: 314
|
| Posted: Wed Jul 28, 2010 5:42 am Post subject: |
|
|
Well, thanks. About your first post in page 7, I tried to follow the Flameeyes' instructions, but from the first command I had this:
| Code: | funtoo drphibes # emerge -C =libpng-1.2*
* This action can remove important packages! In order to be safer, use
* `emerge -pv --depclean <atom>` to check for reverse dependencies before
* removing packages.
--- Couldn't find '=media-libs/libpng-1.2*' to unmerge.
>>> No packages selected for removal by unmerge |
As it seems, there is no libpng-1.2* in my system!
So?  |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Wed Jul 28, 2010 6:34 am Post subject: |
|
|
Then just continue with the next step, since the point was to remove it (the -C part) and you don't have it, you're good 
_________________
|
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Wed Jul 28, 2010 12:37 pm Post subject: |
|
|
| arnvidr wrote: | | Then just continue with the next step, since the point was to remove it (the -C part) and you don't have it, you're good |
What he said.
My expansion of Flameeyes' instructions are once libpng1.2 has been removed, to be sure that there are no libpng1.2 artifacts left. Hence the manual checking and removal of the /usr/lib*/libpng1.2* entries. Then run 'emerge -1 =libpng-1.4*'. Then run 'revdep-rebuild'.
The goal is to be sure that all packages that are dependent on libpng source use libpng-1.4. Once that is done, you can do the normal 'emerge -uND world'. If you have packages which require the libpng-1.2 binary such as opera or nxclient, portage will detect that and install the libpng-1.2 binary in a new slot for you.
After that, you should continue with 'emerge --sync && emerge -uND world' or whatever other normal updates you want to do.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
rpil
Guru
Joined: 23 May 2008
Posts: 314
|
| Posted: Fri Jul 30, 2010 6:39 pm Post subject: |
|
|
Well, I gave:
| Code: | rm -f /usr/lib/libpng1.2*
emerge -1 =libpng-1.4*
/usr/sbin/libpng-1.4.x-update.sh
revdep-rebuild |
and no more preserved libs. I guess it's OK now.
Thanks.  |
|
| Back to top |
|
|
EasterParade
l33t
Joined: 26 Jul 2003
Posts: 938
|
| Posted: Sat Jul 31, 2010 7:03 pm Post subject: |
|
|
Hey guys and gals,
This is a wee bit OT, but I just cannot resist:
| Quote: | Three simlinks (below) solves the problem of packages with hardcoded refernces to png12 (e.g. vlc), but
of course it's not a good way.
This link have to be created by emerge libpng:1.2
libpng12.so -> libpng12.so.0
These dependency should be removed from offending package code |
A quote from dsamersoff from Russia. How awfully true.
I have had libpng update woes on every box here on my network I´ve gotten over it on each one though it was time-consuming but I do enjoy his comment on the issue somehow. 
@dsamersoff
| Quote: | | There are three questions bother Russians in every hard situation like this one: who is guilty, what I should do, can I it chicken by hands. I guess the second question only make sense. |
I like this! Lovely! Good luck to you 
Please don´t misunderstand; just want to convey my sympathy and how I enjoyed your refreshing posting.
Greetings |
|
| Back to top |
|
|
rpil
Guru
Joined: 23 May 2008
Posts: 314
|
| Posted: Mon Aug 02, 2010 12:43 pm Post subject: |
|
|
After two days of peace, new "preserved libs"!
| Code: | !!! existing preserved libs:
>>> package: dev-libs/totem-pl-parser-2.30.1
* - /usr/lib/libtotem-plparser.so.12
* - /usr/lib/libtotem-plparser.so.12.4.5
* used by /usr/bin/totem (media-video/totem-2.28.5-r3)
* used by /usr/lib/python2.6/site-packages/gtk-2.0/totem/plparser.so (dev-python/totem-python-2.26.0)
>>> package: x11-libs/libxklavier-5.0
* - /usr/lib/libxklavier.so.15
* - /usr/lib/libxklavier.so.15.0.0
* used by /usr/bin/gkbd-indicator-plugins-capplet (gnome-base/libgnomekbd-2.28.2)
* used by /usr/bin/gnome-keyboard-properties (gnome-base/gnome-control-center-2.28.1-r2)
* used by /usr/lib/gnome-settings-daemon-2.0/libkeyboard.so (gnome-base/gnome-settings-daemon-2.28.2)
* used by 4 other files |
What is all about?
I downloaded gtk-theme-switch for my Funtoo fluxbox session (I have both Gnome & Fluxbox), Is a problem related to this? |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Mon Aug 02, 2010 3:57 pm Post subject: |
|
|
| rpil wrote: | After two days of peace, new "preserved libs"!
| Code: | !!! existing preserved libs:
>>> package: dev-libs/totem-pl-parser-2.30.1
* - /usr/lib/libtotem-plparser.so.12
* - /usr/lib/libtotem-plparser.so.12.4.5
* used by /usr/bin/totem (media-video/totem-2.28.5-r3)
* used by /usr/lib/python2.6/site-packages/gtk-2.0/totem/plparser.so (dev-python/totem-python-2.26.0)
>>> package: x11-libs/libxklavier-5.0
* - /usr/lib/libxklavier.so.15
* - /usr/lib/libxklavier.so.15.0.0
* used by /usr/bin/gkbd-indicator-plugins-capplet (gnome-base/libgnomekbd-2.28.2)
* used by /usr/bin/gnome-keyboard-properties (gnome-base/gnome-control-center-2.28.1-r2)
* used by /usr/lib/gnome-settings-daemon-2.0/libkeyboard.so (gnome-base/gnome-settings-daemon-2.28.2)
* used by 4 other files |
What is all about?
I downloaded gtk-theme-switch for my Funtoo fluxbox session (I have both Gnome & Fluxbox), Is a problem related to this? |
Nope. Not related at all.
What's going on is that portage is trying not to 'break' your system.
What's happening is that you're still on a learning curve regarding Gentoo, portage and how it all works.
The general case of "@preserved-rebuild" is due to inter-package dependencies. All you need to do is follow the instructions and run the emerge command at the bottom of the warning messages. Then you should be fine.
Because you're running a "Build from Source" distribution, each time you update @world, you're changing which versions of packages are dependent on each other. Portage does an excellent job of catching the majority of these changing version dependencies, but it's not possible to catch all of them. There are technical reasons for this beyond the scope of this discussion. Really. Part of it is forward dependencies, part of it is indirect dependencies, part of it are circular dependencies.
You probably have over a thousand different packages maintained by over 800 different groups {just educated guesses on my part}. There is almost no formal coordination between those groups. Portage is based upon rules of how things are supposed to work. Not all groups follow the rules. Hence the requirement for additional checks after upgrading @world etc.
After you update @world, portage tries to check 'after the fact' to see if anything was broken. That's what the @preserved-rebuild is all about.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
notageek
Tux's lil' helper
Joined: 05 Jun 2008
Posts: 135
Location: India
|
| Posted: Sun Aug 08, 2010 3:35 pm Post subject: |
|
|
Ok, I usually avoid updates until I know everything works. I didn't check it this time and ran the upgrade mindlessly.
I was trying to upgrade gnome when I ran into "The libpng Upgrade Problem".
I've since tried :
revdep-rebuild, which eventually fails
manually run emerge cairo
revdep-rebuild --library libpng12
emerge libpng:1.2
emerge -Duv gnome
and whole lot of emerge -r --skipfirst
A whole lot of packages refuse to emerge.
Running lafilefixer --justfixit right now.
Edit: Er, nevermind /usr/sbin/libpng-1.4.x-update.sh seems to have fixed it for me.
_________________
"Defeat is a state of mind. No one is ever defeated, until defeat has been accepted as a reality." -- Bruce Lee |
|
| Back to top |
|
|
tabanus
l33t
Joined: 11 Jun 2004
Posts: 638
Location: UK
|
| Posted: Sat Aug 14, 2010 1:24 pm Post subject: |
|
|
I emerged libpng-1.4, then started to follow these steps as directed in another post:
1. /usr/sbin/libpng-1.4.x-update.sh
2. emerge -1 pango cairo gtk+ libglade
3. revdep-rebuild --library libpng12.so.0
However, on the gtk+ emerge I get this error message:
| Code: | checking Pango flags... configure: error:
*** Pango not found. Pango built with Cairo support is required
*** to build GTK+. See http://www.pango.org for Pango information. |
my use flags (output of emerge -p):
[ebuild R ] x11-libs/pango-1.28.1 USE="X -debug -doc (-introspection) -test" 0 kB
[ebuild R ] x11-libs/cairo-1.8.10 USE="X opengl svg xcb (-aqua) -cleartype -debug -directfb -doc -glitz -lcdfilter" 0 kB
[ebuild U ] x11-libs/gtk+-2.20.1-r1 [2.18.9] USE="cups jpeg tiff (-aqua) -debug -doc (-introspection) -jpeg2k -test -vim-syntax -xinerama" 0 kB
re-emerging the already installed instance of gtk+ has the same error.
What to do?
EDIT: NVM, working now
_________________
Things you might say if you never took Physics: "I'm overweight even though I don't overeat." - Neil deGrasse Tyson |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Fri Sep 03, 2010 12:48 am Post subject: |
|
|
After upgrading to libpng-1.4.3 following this thread, the only problem I find is that eog can't show my .cr2 files anymore. It spits out
| Code: | | eog Incorrect count for "BitsPerSample" |
which I guess is something from libtiff. I tried re-emerging tiff, eog and libpng to no avail.
R. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Sat Sep 04, 2010 3:46 am Post subject: |
|
|
| potuz wrote: | | I tried re-emerging tiff, eog and libpng to no avail. |
You can run 'equery g eog' and see what other packages eog depends on. That might help you try track back the problem.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Sun Sep 05, 2010 11:01 am Post subject: |
|
|
| dufeu wrote: |
You can run 'equery g eog' and see what other packages eog depends on. That might help you try track back the problem. |
It seems that it is a bug with libtiff completely unrelated to libpng, will file an appropriate bug, sorry for spaming this thread.
R. |
|
| Back to top |
|
|
digler99
n00b
Joined: 01 Dec 2007
Posts: 16
|
| Posted: Sat Jul 23, 2011 6:46 pm Post subject: thank you! |
|
|
| thank you very much for this!! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
