[gentoo-amd64] kdelibs insanity

[gentoo-amd64] kdelibs insanity

[Mark Haney]

I'm beginning to wonder if Gentoo is right for me any more.  I swear,
the dependencies and USE flag changes are killing me.  Here's my latest fun:

I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this:

> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelibs
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[-debug,-qt3support]".
> !!! One of the following packages is required to complete your request:
> - x11-libs/qt-core-4.5.2 (Change USE: -qt3support)
> (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild])
> (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
> (dependency required by "kdelibs" [argument])
> 

So, based on that I need to change my USE flag for qt-core-4.5.2 to
[-qt3support], okay. I go into /etc/portage/package.use/monolithic to this:

x11-libs/qt-core -qt3support (actually I just comment out the line, but
in effect I'm removing qt3support from qt-core).

When I do so and I re-run the update I get this:

> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]".
> !!! One of the following packages is required to complete your request:                                        
> - x11-libs/qt-core-4.5.2 (Change USE: +qt3support)                                                             
> (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild])                                                   
> (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
> (dependency required by "kdelibs" [argument])

So, which is it?  It can't be both ways, and to be honest, trying to
figure out which file needs which USE flag on what day is getting kinda
silly.

-- 
Interdum feror cupidine partium magnarum Europae vincendarum

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Re: [gentoo-amd64] kdelibs insanity

[Volker Armin Hemmann]

On Donnerstag 30 Juli 2009, Mark Haney wrote:
> I'm beginning to wonder if Gentoo is right for me any more.  I swear,
> the dependencies and USE flag changes are killing me.  Here's my latest
> fun:
>
> I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this:
> > octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelib
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> >
> > emerge: there are no ebuilds built with USE flags to satisfy
> > "~x11-libs/qt-core-4.5.2[-debug,-qt3support]". !!! One of the following
> > packages is required to complete your request: - x11-libs/qt-core-4.5.2
> > (Change USE: -qt3support)
> > (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild])
> > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
> > (dependency required by "kdelibs" [argument])
>
> So, based on that I need to change my USE flag for qt-core-4.5.2 to
> [-qt3support], okay. I go into /etc/portage/package.use/monolithic to this:
>
> x11-libs/qt-core -qt3support (actually I just comment out the line, but
> in effect I'm removing qt3support from qt-core).
>
> When I do so and I re-run the update I get this:
> > emerge: there are no ebuilds built with USE flags to satisfy
> > "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]". !!! One of the
> > following packages is required to complete your request: -
> > x11-libs/qt-core-4.5.2 (Change USE: +qt3support)
> > (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild])
> > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
> > (dependency required by "kdelibs" [argument])
>
> So, which is it?  It can't be both ways, and to be honest, trying to
> figure out which file needs which USE flag on what day is getting kinda
> silly.

try syncing again. And masking qt3support fro qt-core is not enough. Either 
enable it globally or disable it globally - or add all your qt packages to 
package.use.

Re: [gentoo-amd64] kdelibs insanity

[Arttu V.]

On 7/30/09, Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> On Donnerstag 30 Juli 2009, Mark Haney wrote:
>> I'm beginning to wonder if Gentoo is right for me any more.  I swear,
>> the dependencies and USE flag changes are killing me.  Here's my latest
>> fun:
>>
>> I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this:
>> > octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelib
>> >
>> > These are the packages that would be merged, in order:
>> >
>> > Calculating dependencies... done!
>> >
>> > emerge: there are no ebuilds built with USE flags to satisfy
>> > "~x11-libs/qt-core-4.5.2[-debug,-qt3support]". !!! One of the following
>> > packages is required to complete your request: - x11-libs/qt-core-4.5.2
>> > (Change USE: -qt3support)
>> > (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild])
>> > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
>> > (dependency required by "kdelibs" [argument])
>>
>> So, based on that I need to change my USE flag for qt-core-4.5.2 to
>> [-qt3support], okay. I go into /etc/portage/package.use/monolithic to
>> this:
>>
>> x11-libs/qt-core -qt3support (actually I just comment out the line, but
>> in effect I'm removing qt3support from qt-core).
>>
>> When I do so and I re-run the update I get this:
>> > emerge: there are no ebuilds built with USE flags to satisfy
>> > "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]". !!! One of the
>> > following packages is required to complete your request: -
>> > x11-libs/qt-core-4.5.2 (Change USE: +qt3support)
>> > (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild])
>> > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
>> > (dependency required by "kdelibs" [argument])
>>
>> So, which is it?  It can't be both ways, and to be honest, trying to
>> figure out which file needs which USE flag on what day is getting kinda
>> silly.
>
> try syncing again. And masking qt3support fro qt-core is not enough. Either
> enable it globally or disable it globally - or add all your qt packages to
> package.use.

I don't think there is a need to sync. qt-core, qt-gui,qt-sql, and
qt-opengl just must all have either qt3support on or off, mixing them
with different USE flag settings won't work. Also, kde4-base.eclass
seems to require qt3support on, so there isn't much choice about
configuration here ... OP just hasn't gotten the whole mile, yet.

But you are right: OP should just enable qt3support in /etc/make.conf
-- or arduously list out at least the four qt-* packages with
qt3support enabled under his choice of files/dirs under /etc/portage
if he is a micromanagement-masochist.

About his pondering on whether Gentoo is right for him and about
Gentoo having been more and more work to maintain recently -- I
wholeheartedly agree. I just haven't found anything better, yet.

-- 
Arttu V.

Re: [gentoo-amd64] kdelibs insanity

[Alex Alexander]

You need to enable qt3support globally. Also make sure you have dbus
enabled for at least qt-gui.

Qt packages' USE defaults were changed recently (reduced to a bare
minimum) thats why you're hitting this.

--
Alex Alexander || wired
Gentoo Linux Developer
http://www.linuxized.com



On Thu, Jul 30, 2009 at 21:45, Mark Haney<mhaney@ercbroadband.org> wrote:
> I'm beginning to wonder if Gentoo is right for me any more.  I swear,
> the dependencies and USE flag changes are killing me.  Here's my latest fun:
>
> I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this:
>
>> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelibs
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[-debug,-qt3support]".
>> !!! One of the following packages is required to complete your request:
>> - x11-libs/qt-core-4.5.2 (Change USE: -qt3support)
>> (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild])
>> (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
>> (dependency required by "kdelibs" [argument])
>>
>
> So, based on that I need to change my USE flag for qt-core-4.5.2 to
> [-qt3support], okay. I go into /etc/portage/package.use/monolithic to this:
>
> x11-libs/qt-core -qt3support (actually I just comment out the line, but
> in effect I'm removing qt3support from qt-core).
>
> When I do so and I re-run the update I get this:
>
>> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]".
>> !!! One of the following packages is required to complete your request:
>> - x11-libs/qt-core-4.5.2 (Change USE: +qt3support)
>> (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild])
>> (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild])
>> (dependency required by "kdelibs" [argument])
>
> So, which is it?  It can't be both ways, and to be honest, trying to
> figure out which file needs which USE flag on what day is getting kinda
> silly.
>
> --
> Interdum feror cupidine partium magnarum Europae vincendarum
>
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
>
>

[gentoo-amd64] Re: kdelibs insanity

[Duncan]

"Arttu V." <arttuv69@gmail.com> posted
fecdbac60907301228s1ca607axbb6a6baec4350ee0@mail.gmail.com, excerpted
below, on  Thu, 30 Jul 2009 22:28:17 +0300:

> I don't think there is a need to sync. qt-core, qt-gui,qt-sql, and
> qt-opengl just must all have either qt3support on or off, mixing them
> with different USE flag settings won't work.

Exactly.  Remember, it's basically a single package, upstream.  So it's 
best to treat all split packages from it as a single unit, same C(XX)
FLAGS/LDFLAGS, same USE flags, for the whole package.

Also note that it doesn't work well to have the different parts be 
different upstream versions (IOW, the -rX number doesn't have to match, 
because that's Gentoo-only, but the upstream version, everything before 
the -rX number, should match).  If one is upgraded, all the others should 
be as well, to keep them all in sync.  Doing otherwise WILL mean 
problems.  For those routinely doing --deep upgrades, that won't be a 
problem as they'll all become available together and the --upgrade --deep 
will ensure they're all upgraded together.  Those not using --deep, 
however, will have to ensure that the versions stay synced, tho AFAIK the 
packages now use blocking of other versions to help ensure that remains 
the case.

> Also, kde4-base.eclass
> seems to require qt3support on, so there isn't much choice about
> configuration here ... OP just hasn't gotten the whole mile, yet.

Also correct.

FWIW, I don't pay attention to whether something's listed as a global USE 
flag or local, I decide which I want as the system default, and put that 
in my make.conf USE flags.  The only entries I have in package.use are 
then those where I want something other than the system default, for some 
reason.  In this case, qt3support was a no-brainer for me since I knew 
kde was going to require it, so qt3support went in make.conf as turned on.

BTW, I also strongly prefer to decide how I want my USE flags set, and 
put that in make.conf and for changes for individual packages, 
packages.use, regardless of whether they're turned on or not.  Thus, 
there's a decent number of -flag entries in my USE flags.  That way, I 
don't have to worry about profile changes or the defaults on individual 
packages changing, since I have the policy set system-wide to what I 
want, regardless of what the package or profile defaults are.  That saved 
me a lot of trouble when I switched from the desktop to the no-multilib 
profile, for instance, and to a lessor extent, saves me trouble /
whenever/ I upgrade profiles (when I upgraded to 2008.0, for instance).

It also would have saved a lot of trouble for the OP here, since Alex 
pointed out that the reason this is coming up is that the qt package 
defaults changed.

> But you are right: OP should just enable qt3support in /etc/make.conf --
> or arduously list out at least the four qt-* packages with qt3support
> enabled under his choice of files/dirs under /etc/portage if he is a
> micromanagement-masochist.

=:^)  It should be obvious from the above which I'd choose, make.conf, 
tho as I said, I actually prefer to set -flags in there as well, which 
might be called micromanagement too.  package.use is only for packages 
that I want flags that don't fit my chosen system defaults.

For example, I don't run aRTs and have the flag turned off system-wide, 
but have it turned on in package.use for kdelibs:3.5, as I have arts-
plugins-xine installed to generate video thumbnails, and it needs the 
arts flag turned on in kdelibs.  (Rant: I don't know why I have to have 
aRTs installed to get video thumbnails, as I said, I don't actually use 
aRTs, but that's the way the package is setup.  <shrug>)

> About his pondering on whether Gentoo is right for him and about Gentoo
> having been more and more work to maintain recently -- I wholeheartedly
> agree. I just haven't found anything better, yet.

I don't agree.  Gentoo's about the same as it has been, even lower work 
if anything for me recently.  But then again, I believe I use better 
management techniques than many users do -- at least better for me.  And 
as what was working for others seems to be causing issues now, perhaps 
they'd be better for them, as well.  <shrug>

As I said, I prefer deciding what I want for USE flags and setting that 
globally, either hard on or hard off, and only change that for specific 
packages.  And I always do --upgrade --deep --newuse, preferably syncing 
and running upgrades at least twice a week, so nothing on my system gets 
too stale -- including all the deep dependencies.  I'm ALWAYS at the 
latest unmasked (to ~arch since that's what I use) version, which I think 
helps even if it does mean a bit faster churn on deep dependencies than 
I'd otherwise have.  And, upgrading twice a week means I normally don't 
have many packages to upgrade (big kde upgrades being a huge exception, 
since that's /always/ well over 100 individual packages), so if something 
goes wrong, I find out about it right away, and it's pretty easy to 
figure out which package was the culprit.

After every upgrade, I run revdep-rebuild (of course with --pretend firt, 
or with --ask) and rebuild what's necessary (which is FAR less with as-
needed in LDFLAGS than it would be otherwise, but OTOH, the --upgrade --
deep means more frequent library upgrades, thus triggering revdep-
rebuilds in some cases).  The --deep --newuse on my upgrades by default 
definitely helps here too, as it helps keep the dependencies sorted out 
that would otherwise get screwed up due to USE flag changes not being 
reflected in what's actually installed.

I also run emerge --depclean (--ask or --pretend first) every time after 
the upgrade, and then another revdep-rebuild if I removed anything, just 
to be sure it didn't leave any dependency holes.

Of course I also do the etc-update, whether portage tells me to or not, 
just to be sure.

I expect I've saved myself a LOT of trouble over the years, due to a few 
basics like the above sysadmin policies.  With a modern multi-core CPU 
and at least a couple gigs RAM, Gentoo really isn't all that hard to keep 
up, provided you are serious enough about sysadminning to learn how to 
play it smart, not rough.  But that last bit is critical.  Gentoo 
provides the tools and manages the ebuilds, plus a good amount of 
documentation.  But it's not about hand-holding.  Gentoo expects users to 
be able to read docs and learn how to take best advantage of the tools 
provided.  If you're not ready to do that, Gentoo's really not the 
distribution for you.  I read that Ubuntu's pretty decent at making 
things brainless.  That may well be a better choice for those who aren't 
serious enough about their sysadminning to learn what the provided tools 
are and how to use them to best effect.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: kdelibs insanity

[Frank Peters]

>
> About his pondering on whether Gentoo is right for him and about Gentoo
> having been more and more work to maintain recently -- I wholeheartedly
> agree. I just haven't found anything better, yet.
> 

It hasn't been more and more work for me, but then I try to maintain
a minimalist system, which means I avoid these bloated, do-it-all-for-
everyone monstrosities like KDE or Gnome.  A simple window manager
is good enough for my purposes.

But what is meant by "better?"  If you seek to eliminate the work
of administration, that is, as I understand it, not the goal of Gentoo.
In order to customize a system to ones liking, one has to to understand
thoroughly how the system functions.  Gentoo facilitates customization
but it does not eliminate the need to understand -- and understanding
can involve a lot of work.  If the user is not willing to research and
explore, then the user should indeed be advised to seek elsewhere.

IMO, for one who seeks control and the ability to customize, there is
nothing better than Gentoo.  The only alternative is to build and
maintain a system independently, in the manner of Linux From Scratch.

But I've been down that road.  Until recently, I used to compile all
my own packages and completely administer my own personal "distribution."
It was a fair amount of work, but with the proper organization and
a lot of ambition ambition, it was quite feasible.  However, certain
developments in the Open Source world eventually served to dampen my enthusiasm.
The most significant of these developments was the splitting of the X Window
package from one into literally dozens of individual programs.  With
this change -- as well as several others that I won't mention -- the work
load slowly became more and more unbearable, and I realized that I would
not be able to continue doing it alone.  After considering a lot of
possibilities, I discovered Gentoo and realized that my needs could be
once again be fulfilled without the excessive burden.

It should also be considered that perhaps the upstream developers are
making things more difficult.  Many new packages that have been released
seem to break everything that depends on them.  For example, a new jpeg
library, version 7, was released recently (which has not yet made it
into Gentoo) that will require a rebuild of every program that processes
images, and this includes the extensive GTK package as it uses libjpeg
for its pixbuffer loader.  Another example is the new gcc compiler, version
4.4.x.  I have noticed that many packages will fail to compile with the
new version of gcc and this necessitates that the previous version, 4.3.3,
be also kept installed on the system.  Lastly, do I need to mention the
fiasco with the update of the xcb package for X Window?  Once again, a single
change has broken everything that has gone before.  It has to be admitted
that these upstream developers are not making life any easier for the
distribution maintainers.

But that's the nature of progress, I suppose.  Fortunately, Gentoo can give
the serious user a set of tools to better deal with these inevitable changes.

Frank Peters

[gentoo-amd64] Re: kdelibs insanity

[Duncan]

Frank Peters <frank.peters@comcast.net> posted
20090731010923.8875a3af.frank.peters@comcast.net, excerpted below, on 
Fri, 31 Jul 2009 01:09:23 -0400:

> It should also be considered that perhaps the upstream developers are
> making things more difficult.

No kidding!

> Many new packages that have been released
> seem to break everything that depends on them.  For example, a new jpeg
> library, version 7, was released recently (which has not yet made it
> into Gentoo) that will require a rebuild of every program that processes
> images, and this includes the extensive GTK package as it uses libjpeg
> for its pixbuffer loader.

Thanks for the warning!  I hadn't read anything about that one yet.

> Another example is the new gcc compiler,
> version 4.4.x.  I have noticed that many packages will fail to compile
> with the new version of gcc and this necessitates that the previous
> version, 4.3.3, be also kept installed on the system.

I routinely install any new gcc version before it's unmasked to ~arch.  
As such, I'm used to dealing with packages that won't yet compile with 
the new version, searching Gentoo and other bug systems for patches, 
etc.  Due to the hard work of many even before a public release (Gentoo 
toolchain folks and adventurous users try rebuilding with the rcs, and 
some routinely test weekly snapshots during development.  Debian as well 
tests, and many of our patches to make existing packages compile with new 
gcc versions come from there.  Fedora Rawhide, similarly, and I've 
actually worked with SuSE devs on testing a patch for an upstream package 
(pan) that I'm involved with upstream, myself.

But as we're talking about Gentoo tools making it easier, slotted gcc and 
gcc-config definitely belong on that list, as they SURE make it easier 
testing various new compilers, and switching back to the old one when 
necessary.  The process would be SERIOUSLY harder without this sort of 
Gentoo tools and slotted gcc.

> Lastly, do I need
> to mention the fiasco with the update of the xcb package for X Window? 
> Once again, a single change has broken everything that has gone before.

That one actually had FAR less effect on me than I expected.  From the 
Gentoo/X project discussion of things (in the tracking bug and on the 
desktop list, IIRC, the former discovered by reading the latter), I 
expected something on the size of the expat fiasco, but with virtually 
all X apps needing recompiled.  Never-the-less, I upgraded (again, while 
it was masked, actually, I grabbed it while it was still on the X 
overlay, IIRC), and things weren't anywhere NEAR that bad.  I think I had 
a half dozen, maybe a dozen packages to upgrade, instead of the couple 
hundred or so I expected.

But I expect what saved me on that was having -as-needed in LDFLAGS.  It 
really DOES make a HUGE difference.  The goal is eventually to make that 
the Gentoo default, but there's still a lot of packages that don't work 
with it, tho most of them have been patched or at least have filter-
ldflags called for it, so it doesn't hit users as much as it used to.  
Flame-eyes is the expert on -as-needed (it was his blog I discovered it 
on), and his tinder-box has really weeded out a bunch of issues both 
there and elsewhere.  That alone is a huge benefit to Gentoo, even if he 
didn't contribute huge amounts of fixes and technical help for other 
devs, which he does.  (Unfortunately, he reminds me a lot of my father 
and sister.  All three are extremely bright, genius level or close to it, 
all three workaholics -- they see so much to be done and so few able to 
do it, and try to do it all themselves!  And all three have the health 
problems that go with the territory.  All three of them have had to learn 
to deliberately slow down and pace themselves, after they got sick and 
nearly died from simply trying to do to much.)

For those who wish to try it, here's mine:

LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common"

The "now" bit people will likely want to avoid.  The others should be 
useful, tho there has been discussion about making them Gentoo default, 
and part of them may be default by now (they weren't when I added them, 
tho).

There are some others I've seen as well, but I don't know enough about 
them to use them.  For the ones above (covered in the ld manpage except 
for -Wl, in the gcc manpage, see below):

-Wl is actually a gcc option, telling it to pass what follows to the 
linker.  See the gcc manpage for this one.

-z,now (as opposed to -z,lazy) tells the linker to force all links to be 
resolved at initial program load.  This takes a bit more time /at/ 
initial load, but when an application would otherwise pause for 
additional library functions to load, it now doesn't have to.  It's thus 
a trade-off.  It also has a couple other effects.  Memory use will be 
slightly higher tho not too much, so I'd say it's probably best not to do 
unless you've 2 gigs RAM or more.  But the two effects I use it for are: 
(1) If a library or function from a library can't load, I'd prefer to see 
the error at startup, not later, when the program tries to load that 
bit.  This ensures that.  (2) There are certain somewhat narrow security 
benefits.  I won't attempt to explain them here and they are rather 
narrow, but given I have 8 gigs RAM so that's not an issue, and I 
considered the other aspects slightly positive, with no visible downside, 
I thought it worth it.

I've had this enabled for years, now, with no issues /except/ with the 
ati/radeon drivers when xorg split into modular packages.  I had to turn 
off -z,now for the xf86-ati-radeon package (using the /etc/portage/env/ 
method to do it for just that package) for awhile as a result.  They 
eventually patched the package to filter -z,now, and I'm not sure if it 
has been resolved upstream by now or not, but with the package patched to 
filter it, I don't have to worry about it now.

--as-needed tells the linker to only tag libraries it actually uses as 
NEEDED, not everything on the include line, or indirect dependencies like 
the libraries other libraries it is using use.  The result is that 
unnecessary linkages are avoided, and FAR fewer rebuilds need done when a 
library changes as a result.

I've had this enabled for quite some time now without many issues, 
probably as a result of flame-eyes' testing.  This one should therefore 
be pretty trouble-free now, and has a HUGE upside, but it does still have 
the potential to cause occasional issues on new or obscure packages.  But 
I really DO think the upside is worth it!

-O1 is much like the gcc -O optimization functions, but there's only the 
single -O1 level, for linking.  This one's newer, but I've had no 
problems with it at all, probably because it's commonly enabled and thus 
well tested.

Gentoo's former default for hash was --hash-style=both, but hash-
style=gnu along with -O1 and sort-common were proposed as new defaults.  
I'm not sure if they made it or not, but in any case, this one shouldn't 
be an issue on Linux at all, and I've certainly not had issues at all.  
The other alternative and linker default (before Gentoo's default kicks 
in) is hash-style=sysv.

--sort-common sorts symbols by their alignment size, >=16,8,4,2,1 bytes.  
This packs them tighter than they'd be be otherwise, due to alignment 
constraint issues, thus making for slightly smaller binaries.

I think the --as-needed will make the most difference, and I'm SURE it 
has saved me a LOT of pain, even with the xcb issue alone.  I absolutely 
believe it's worthwhile, and that the pain saved will MORE than make up 
for any occasional issues one /might/ run into with new or obscure 
individual packages.  Note that -Wl is actually a gcc option, telling it 
to pass what follows to the linker.  Thus, the format for /just/ as-
needed would be:

LDFLAGS="-Wl,--as-needed"

> It has to be admitted that these upstream developers are not making life
> any easier for the distribution maintainers.

> But that's the nature of progress, I suppose.  Fortunately, Gentoo can
> give the serious user a set of tools to better deal with these
> inevitable changes.

Agreed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: kdelibs insanity

[Mark Haney]

Duncan wrote:
> "Arttu V." <arttuv69@gmail.com> posted
> fecdbac60907301228s1ca607axbb6a6baec4350ee0@mail.gmail.com, excerpted
> below, on  Thu, 30 Jul 2009 22:28:17 +0300:
> 

> I expect I've saved myself a LOT of trouble over the years, due to a few 
> basics like the above sysadmin policies.  With a modern multi-core CPU 
> and at least a couple gigs RAM, Gentoo really isn't all that hard to keep 
> up, provided you are serious enough about sysadminning to learn how to 
> play it smart, not rough.  But that last bit is critical.  Gentoo 
> provides the tools and manages the ebuilds, plus a good amount of 
> documentation.  But it's not about hand-holding.  Gentoo expects users to 
> be able to read docs and learn how to take best advantage of the tools 
> provided.  If you're not ready to do that, Gentoo's really not the 
> distribution for you.  I read that Ubuntu's pretty decent at making 
> things brainless.  That may well be a better choice for those who aren't 
> serious enough about their sysadminning to learn what the provided tools 
> are and how to use them to best effect.
> 

Here's my take on this, since I am OP.  For the last year or two, I've
had, more and more, to go straight to ~arch for 'stable' packages.  This
 isn't so much about KDE4, which I /expected/ to be funky when it was
released, it's virtually everything else.  Unlike some people, or most,
if I read the list right, are already running ~amd64 on their systems.

I am not.

And I do not want to.  What's the point in having 'stable' when
virtually no packages are marked as such any more?  I've been running
qt4.5 for nearly a year now.  Isn't it about bloody time it gets marked
stable?  Hell, IIRC, KDE3.5.10 isn't even marked stable (or wasn't last
time I looked).

I make the comment about it being right for me because I have been
getting the feeling Gentoo is becoming 'Debian v2.0' by just leaving
everything useful in ~arch (or testing in Debian's case).

If it is STABLE, mark it as such.  Don't sit here and tell me, 'Oh just
run ~amd64 widget, it's stable'.

When I started with Gentoo in 2005/6, I could emerge -uD world and know
it'll pull in the latest stable packages and be done with it.  Now, I
have to watch because some packages aren't, some might need a downgrade
of a package, which I have to mask so it doesn't get downgraded, ad
infinitum.

To me, the distro is just feeling kinda sloppy on the back end.  No, I'm
not looking for a 'Ubuntu' experience.  That distro gives me heartburn.
 But, geez, I do expect packages to be moved from testing to stable
slightly more often than never.  I'm not trying to be overly critical
here, but the way things are going, it's getting /harder/ to maintain a
STABLE system now than it used to be.

And, FWIW, on topic, having qt3support globally makes no difference. I
still have a thousand bleeding hoops to jump through to fix all the
asinine blocks and dependencies.


-- 
Interdum feror cupidine partium magnarum Europae vincendarum

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Re: [gentoo-amd64] Re: kdelibs insanity

[Mark Haney]

Mark Haney wrote:

> 
> And, FWIW, on topic, having qt3support globally makes no difference. I
> still have a thousand bleeding hoops to jump through to fix all the
> asinine blocks and dependencies.
> 
> 

Do you really wanna see how bloody stupid this whole problem is with QT?
 Here's what I did:

emerge -C qt-svg qt-sql qt-dbus qt-qt3support qt-gui qt-core qt-test
qt-assistant


I figure this will get the system clean enough for me to actually do
something but stare at 20+ blocks.

Nope.

> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav qt-svg qt-sql qt-dbus qt-gui qt-core qt-test qt-assistant
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild     U ] dev-libs/openssl-0.9.8k-r1 [0.9.8k] USE="(sse2) zlib -bindist -gmp -kerberos -test" 0 kB
> [ebuild     U ] media-libs/libpng-1.2.38 [1.2.37] 514 kB                                                
> [ebuild     U ] dev-libs/glib-2.20.4 [2.18.4-r1] USE="-debug -doc -fam -hardened (-selinux) -xattr" 4,918 kB
> [ebuild     U ] media-libs/fontconfig-2.7.0 [2.6.0-r2] USE="-doc" 1,504 kB                                  
> [ebuild     U ] sys-apps/dbus-1.2.12 [1.2.3-r1] USE="X -debug -doc (-selinux) -test%" 1,538 kB              
> [ebuild     U ] net-print/cups-1.3.11 [1.3.10-r2] USE="X acl jpeg pam perl png python ssl -avahi -dbus -gnutls -java -kerberos -ldap -php -ppds -samba -slp -static -tiff -xinetd -zeroconf" LINGUAS="-de -en -es -et -fr -he -id -it -ja -pl -sv -zh_TW" 3,711 kB
> [ebuild     U ] dev-db/mysql-5.0.83 [5.0.70-r1] USE="berkdb community%* perl ssl -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -profiling% (-selinux) -static" 35,580 kB                                                       
> [ebuild  N    ] x11-libs/qt-core-4.5.2  USE="glib iconv qt3support ssl -debug -doc -pch" 113,297 kB                              
> [ebuild  N    ] x11-libs/qt-sql-4.5.2  USE="iconv mysql qt3support sqlite -debug (-firebird) -odbc -pch -postgres" 0 kB          
> [ebuild  N    ] x11-libs/qt-dbus-4.5.2  USE="-debug -pch" 0 kB                                                                   
> [ebuild     U ] x11-libs/qt-script-4.5.2 [4.5.1] USE="iconv -debug -pch (-custom-cxxflags%)" 0 kB                                
> [blocks b     ] <x11-libs/qt-script-4.5.2 ("<x11-libs/qt-script-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)                                                                            
> [ebuild  N    ] x11-libs/qt-test-4.5.2  USE="iconv -debug -pch" 0 kB                                                             
> [ebuild  N    ] x11-libs/qt-gui-4.5.2-r2  USE="accessibility cups dbus glib mng qt3support -debug -gtk -nas -nis -pch -raster -tiff -xinerama" 0 kB                                                                                                               
> [ebuild  N    ] x11-libs/qt-qt3support-4.5.2  USE="accessibility kde -debug -pch -phonon" 0 kB                                   
> [ebuild     U ] x11-libs/qt-webkit-4.5.2 [4.5.1] USE="kde -debug -pch (-custom-cxxflags%)" 0 kB                                  
> [ebuild  N    ] x11-libs/qt-svg-4.5.2  USE="iconv -debug -pch" 0 kB                                                              
> [ebuild  N    ] x11-libs/qt-assistant-4.5.2  USE="-debug -pch" 0 kB                                                              
> [blocks B     ] >x11-libs/qt-qt3support-4.5.1-r9999 (">x11-libs/qt-qt3support-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                               
> [blocks B     ] <x11-libs/qt-xmlpatterns-4.5.2 ("<x11-libs/qt-xmlpatterns-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)                                        
> [blocks B     ] >x11-libs/qt-test-4.5.1-r9999 (">x11-libs/qt-test-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                           
> [blocks B     ] >x11-libs/qt-script-4.5.1-r9999 (">x11-libs/qt-script-4.5.1-r9999" is blocking x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                                                 
> [blocks B     ] >x11-libs/qt-sql-4.5.1-r9999 (">x11-libs/qt-sql-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                             
> [blocks B     ] <x11-libs/qt-opengl-4.5.2 ("<x11-libs/qt-opengl-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)                                                  
> [blocks B     ] >x11-libs/qt-core-4.5.1-r9999 (">x11-libs/qt-core-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                           
> [blocks B     ] >x11-libs/qt-svg-4.5.1-r9999 (">x11-libs/qt-svg-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                             
> [blocks B     ] <x11-libs/qt-webkit-4.5.2 ("<x11-libs/qt-webkit-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)                                                                            
> [blocks B     ] >x11-libs/qt-gui-4.5.1-r9999 (">x11-libs/qt-gui-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                             
> [blocks B     ] >x11-libs/qt-dbus-4.5.1-r9999 (">x11-libs/qt-dbus-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                           
> [blocks B     ] >x11-libs/qt-webkit-4.5.1-r9999 (">x11-libs/qt-webkit-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1)                                                                                 
> [blocks B     ] >x11-libs/qt-assistant-4.5.1-r9999 (">x11-libs/qt-assistant-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)                                                 
> 
> Total: 17 packages (9 upgrades, 8 new), Size of downloads: 161,059 kB
> Conflict: 14 blocks (13 unsatisfied)                                 
> 


THIS, my friends, is utter stupidity.

-- 
Interdum feror cupidine partium magnarum Europae vincendarum

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Re: [gentoo-amd64] Re: kdelibs insanity

[Alex Alexander]

Something is fishy, those blocks are meant to tell you you're trying
to mix qt versions which is *not* supported.

There are a few things you can do to get rid of this once and for all:
- make sure your /var/lib/portage/world has no references to qt (4)
- make sure your emerge commands won't try to fetch only part of qt

>> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav qt-svg qt-sql qt-dbus qt-gui qt-core qt-test qt-assistant

why would you ever want to do that? its easy to end up with mixed versions :S

# remove all qt4 (not necessary, anyway)
emerge -aC `eix --only-names -I x11-libs/qt-`
# remove qt meta package just in case
emerge -aC x11-libs/qt:4
# let dependencies pull qt, don't pull it yourself...
emerge -avDuN world

http://www.linuxized.com/2009/06/upgrading-qt-libraries-in-gentoo-with-portage/

--
Alex Alexander || wired
Gentoo Linux Developer
http://www.linuxized.com


On Fri, Jul 31, 2009 at 15:49, Mark Haney<mhaney@ercbroadband.org> wrote:
> Mark Haney wrote:
>
>>
>> And, FWIW, on topic, having qt3support globally makes no difference. I
>> still have a thousand bleeding hoops to jump through to fix all the
>> asinine blocks and dependencies.
>>
>>
>
> Do you really wanna see how bloody stupid this whole problem is with QT?
>  Here's what I did:
>
> emerge -C qt-svg qt-sql qt-dbus qt-qt3support qt-gui qt-core qt-test
> qt-assistant
>
>
> I figure this will get the system clean enough for me to actually do
> something but stare at 20+ blocks.
>
> Nope.
>
>> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav qt-svg qt-sql qt-dbus qt-gui qt-core qt-test qt-assistant
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild     U ] dev-libs/openssl-0.9.8k-r1 [0.9.8k] USE="(sse2) zlib -bindist -gmp -kerberos -test" 0 kB
>> [ebuild     U ] media-libs/libpng-1.2.38 [1.2.37] 514 kB
>> [ebuild     U ] dev-libs/glib-2.20.4 [2.18.4-r1] USE="-debug -doc -fam -hardened (-selinux) -xattr" 4,918 kB
>> [ebuild     U ] media-libs/fontconfig-2.7.0 [2.6.0-r2] USE="-doc" 1,504 kB
>> [ebuild     U ] sys-apps/dbus-1.2.12 [1.2.3-r1] USE="X -debug -doc (-selinux) -test%" 1,538 kB
>> [ebuild     U ] net-print/cups-1.3.11 [1.3.10-r2] USE="X acl jpeg pam perl png python ssl -avahi -dbus -gnutls -java -kerberos -ldap -php -ppds -samba -slp -static -tiff -xinetd -zeroconf" LINGUAS="-de -en -es -et -fr -he -id -it -ja -pl -sv -zh_TW" 3,711 kB
>> [ebuild     U ] dev-db/mysql-5.0.83 [5.0.70-r1] USE="berkdb community%* perl ssl -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -profiling% (-selinux) -static" 35,580 kB
>> [ebuild  N    ] x11-libs/qt-core-4.5.2  USE="glib iconv qt3support ssl -debug -doc -pch" 113,297 kB
>> [ebuild  N    ] x11-libs/qt-sql-4.5.2  USE="iconv mysql qt3support sqlite -debug (-firebird) -odbc -pch -postgres" 0 kB
>> [ebuild  N    ] x11-libs/qt-dbus-4.5.2  USE="-debug -pch" 0 kB
>> [ebuild     U ] x11-libs/qt-script-4.5.2 [4.5.1] USE="iconv -debug -pch (-custom-cxxflags%)" 0 kB
>> [blocks b     ] <x11-libs/qt-script-4.5.2 ("<x11-libs/qt-script-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)
>> [ebuild  N    ] x11-libs/qt-test-4.5.2  USE="iconv -debug -pch" 0 kB
>> [ebuild  N    ] x11-libs/qt-gui-4.5.2-r2  USE="accessibility cups dbus glib mng qt3support -debug -gtk -nas -nis -pch -raster -tiff -xinerama" 0 kB
>> [ebuild  N    ] x11-libs/qt-qt3support-4.5.2  USE="accessibility kde -debug -pch -phonon" 0 kB
>> [ebuild     U ] x11-libs/qt-webkit-4.5.2 [4.5.1] USE="kde -debug -pch (-custom-cxxflags%)" 0 kB
>> [ebuild  N    ] x11-libs/qt-svg-4.5.2  USE="iconv -debug -pch" 0 kB
>> [ebuild  N    ] x11-libs/qt-assistant-4.5.2  USE="-debug -pch" 0 kB
>> [blocks B     ] >x11-libs/qt-qt3support-4.5.1-r9999 (">x11-libs/qt-qt3support-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] <x11-libs/qt-xmlpatterns-4.5.2 ("<x11-libs/qt-xmlpatterns-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)
>> [blocks B     ] >x11-libs/qt-test-4.5.1-r9999 (">x11-libs/qt-test-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] >x11-libs/qt-script-4.5.1-r9999 (">x11-libs/qt-script-4.5.1-r9999" is blocking x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] >x11-libs/qt-sql-4.5.1-r9999 (">x11-libs/qt-sql-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] <x11-libs/qt-opengl-4.5.2 ("<x11-libs/qt-opengl-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)
>> [blocks B     ] >x11-libs/qt-core-4.5.1-r9999 (">x11-libs/qt-core-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] >x11-libs/qt-svg-4.5.1-r9999 (">x11-libs/qt-svg-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] <x11-libs/qt-webkit-4.5.2 ("<x11-libs/qt-webkit-4.5.2" is blocking x11-libs/qt-gui-4.5.2-r2, x11-libs/qt-assistant-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2)
>> [blocks B     ] >x11-libs/qt-gui-4.5.1-r9999 (">x11-libs/qt-gui-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] >x11-libs/qt-dbus-4.5.1-r9999 (">x11-libs/qt-dbus-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>> [blocks B     ] >x11-libs/qt-webkit-4.5.1-r9999 (">x11-libs/qt-webkit-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1)
>> [blocks B     ] >x11-libs/qt-assistant-4.5.1-r9999 (">x11-libs/qt-assistant-4.5.1-r9999" is blocking x11-libs/qt-script-4.5.1, x11-libs/qt-opengl-4.5.1, x11-libs/qt-xmlpatterns-4.5.1, x11-libs/qt-webkit-4.5.1)
>>
>> Total: 17 packages (9 upgrades, 8 new), Size of downloads: 161,059 kB
>> Conflict: 14 blocks (13 unsatisfied)
>>
>
>
> THIS, my friends, is utter stupidity.
>
> --
> Interdum feror cupidine partium magnarum Europae vincendarum
>
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
>
>

Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Frank Peters]

On Fri, 31 Jul 2009 10:20:45 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 
> > Many new packages that have been released
> > seem to break everything that depends on them.  For example, a new jpeg
> > library, version 7, was released recently (which has not yet made it
> > into Gentoo) that will require a rebuild of every program that processes
> > images, and this includes the extensive GTK package as it uses libjpeg
> > for its pixbuffer loader.
> 
> Thanks for the warning!  I hadn't read anything about that one yet.
> 

FWIW, I need to continue this comment.

Since I process a lot of images, libjpeg is very important to me.  The new
jpeg-7 now includes arithmetic encoding which can produce smaller compressed
file sizes and there are also some changes to the scaling and quality features.
Unlike most Open Source packages, which are updated quite frequently (too
frequently?), jpeg-7 is the first new release since 1998.

Rather than wait for Gentoo to create the ebuilds for the new jpeg-7, I decided
to compile it myself and then list it in packages.provided.  In addition,
the old jpeg-6 shared objects were kept, but all the include files and
static libraries for linking would refer to the new jpeg-7.  In this way,
any update of a package that depends on libjpeg would be linked with the
new libraries, but any existing package that still needs jpeg-6 could be
left untouched.  I don't like to have to re-compile everything at once.  When
the time comes to update a package the new libraries will be available but until
then the old libraries will suffice.  (Gentoo is flexible enough to nicely
accomodate this.)

However, after emerging a new GTK+, which automatically then became linked
to the new jpeg-7 libraries, I noticed a severe problem.  Jpeg images viewed
using programs that depend on GTK+ -- and there are a lot of them -- were
strangely blurred and out of focus.  Doing some searching, I found this
thread that explains the problem:

http://bbs.archlinux.org/viewtopic.php?id=75529

The issue is with the new scaling methods in jpeg-7.  Programs such as firefox
and many others process images through GTK+ facilities, and GTK+ needs to be
patched before it can utilize the new jpeg-7.  AFAIK, the GTK+ people do not
even yet know about this issue.  Also, unless I am mistaken, any patch that
accommodates jpeg-7 will no longer function with jpeg-6.

So there ends my nice, neat plan to have both jpeg-7 and jpeg-6 together
serving my system.  The situation also illustrates how unanticipated problems
can easily be injected into this loose but wonderful conglomeration known
as Open Source software.

Frank Peters

Re: [gentoo-amd64] Re: kdelibs insanity

[Mark Haney]

Alex Alexander wrote:
> Something is fishy, those blocks are meant to tell you you're trying
> to mix qt versions which is *not* supported.
> 
> There are a few things you can do to get rid of this once and for all:
> - make sure your /var/lib/portage/world has no references to qt (4)
> - make sure your emerge commands won't try to fetch only part of qt
> 
>>> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav qt-svg qt-sql qt-dbus qt-gui qt-core qt-test qt-assistant
> 
> why would you ever want to do that? its easy to end up with mixed versions :S
> 
> # remove all qt4 (not necessary, anyway)
> emerge -aC `eix --only-names -I x11-libs/qt-`
> # remove qt meta package just in case
> emerge -aC x11-libs/qt:4
> # let dependencies pull qt, don't pull it yourself...
> emerge -avDuN world
> 
> http://www.linuxized.com/2009/06/upgrading-qt-libraries-in-gentoo-with-portage/
> 
> --
> Alex Alexander || wired
> Gentoo Linux Developer
> http://www.linuxized.com



But I'm not.  The packages I am trying to upgrade are the only packages
installed on my system.  I should uninstall packages that don't exist on
my system to make this work?

It doesn't matter, I finally just blew away everything and am starting over.




-- 
Interdum feror cupidine partium magnarum Europae vincendarum

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

[gentoo-amd64] Re: kdelibs insanity

[Duncan]

"Mark Haney" <mhaney@ercbroadband.org> posted
4A72E86B.7000205@ercbroadband.org, excerpted below, on  Fri, 31 Jul 2009
08:49:47 -0400:

> Do you really wanna see how bloody stupid this whole problem is with QT?
>  Here's what I did:
> 
> emerge -C qt-svg qt-sql qt-dbus qt-qt3support qt-gui qt-core qt-test
> qt-assistant
> 
> 
> I figure this will get the system clean enough for me to actually do
> something but stare at 20+ blocks.
> 
> Nope.
> 
>> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav qt-svg qt-sql qt-dbus
>> qt-gui qt-core qt-test qt-assistant

snippy snippy... (clipping the below to the relevant)

>> [ebuild     U ] x11-libs/qt-script-4.5.2 [4.5.1]
>> [blocks b     ] <x11-libs/qt-script-4.5.2
>> ("<x11-libs/qt-script-4.5.2" is blocking 

You missed one.  qt-script-4.5.1 is still installed, and it's blocking 
the others.  As I said, all bits of qt4 must be the same version, so to 
get 4.5.2, you can't have 4.5.1 installed.  Not a bit of it.

I believe portage could resolve it if all parts were 4.5.1 and it could 
upgrade them all to 4.5.2 at once, but with mixed versions, or with one 
bit of 4.5.1 and trying to pull the others, because it tries to install 
the latest available, it doesn't work because that blocks and portage 
isn't smart enough to know how to /safely/ resolve it. (Portage defaults 
to just spitting out the blockers and letting you resolve it, if it can't 
be SURE it can do so safely.)

Once you have all bits of qt4 either on the same version, or all removed, 
portage should be able to resolve things on its own.  

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: kdelibs insanity

[Alex Alexander]

On Fri, Jul 31, 2009 at 17:03, Mark Haney<mhaney@ercbroadband.org> wrote:
> But I'm not.  The packages I am trying to upgrade are the only packages
> installed on my system.  I should uninstall packages that don't exist on
> my system to make this work?

Not true, you had some Us in your output, like:
>> [ebuild     U ] x11-libs/qt-script-4.5.2 [4.5.1] USE="iconv -debug -pch (-custom-cxxflags%)" 0 kB

So perhaps there are (were) others installed there and portage
complained about mixing them :)

>
> It doesn't matter, I finally just blew away everything and am starting over.

Oh well :)

--
Alex Alexander || wired
Gentoo Linux Developer
http://www.linuxized.com

[gentoo-amd64] Re: kdelibs insanity

[Duncan]

"Mark Haney" <mhaney@ercbroadband.org> posted
4A72E4DC.2070106@ercbroadband.org, excerpted below, on  Fri, 31 Jul 2009
08:34:36 -0400:


> Here's my take on this, since I am OP.  For the last year or two, I've
> had, more and more, to go straight to ~arch for 'stable' packages.  This
>  isn't so much about KDE4, which I /expected/ to be funky when it was
> released, it's virtually everything else.  Unlike some people, or most,
> if I read the list right, are already running ~amd64 on their systems.
> 
> I am not.
> 
> And I do not want to.  What's the point in having 'stable' when
> virtually no packages are marked as such any more?  I've been running
> qt4.5 for nearly a year now.  Isn't it about bloody time it gets marked
> stable?  Hell, IIRC, KDE3.5.10 isn't even marked stable (or wasn't last
> time I looked).

Note that while Gentoo does provide the tools to mix stable and ~arch for 
those who wish to try, it's not well tested or supported.  All stable is 
supposed to be well tested, and all ~arch should be tested working at 
least on the Gentoo package maintainer's machines with all ~arch, but 
mixing the two is asking for trouble.

Meanwhile, one of the issues with stable (which people like me parse as 
stale with a "b" added... hmm... I like that description, I think I'll 
keep using it! =:^) is that it takes people to test it that are willing 
to stay as far back as stale is in general, so they're testing a stale 
install not an ~arch install, but who are also willing to test candidates 
for stale, ensure they work, and report them as working.

You say you have a big package.keywords file right now.  But have you 
been reporting as working packages as you install them, so that the 
Gentoo/amd64 folks know they are working?  (Maybe you are, I don't know, 
and I'm not saying you have to, but somebody has to, and those like me 
that want ~arch systems aren't going to be able to test with stale, and 
those who never install ~arch packages at all aren't going to be testing 
since they stick to stale, so the only ones left to test and report 
working are those who are mostly stale but do install the occasional not-
yet-stale package.

> I make the comment about it being right for me because I have been
> getting the feeling Gentoo is becoming 'Debian v2.0' by just leaving
> everything useful in ~arch (or testing in Debian's case).

I've never run Debian, and prefer not to run stale anyway, so can't 
honestly say, there.  But what I can say is that in all honesty, at least 
for me, if Gentoo/amd64 dropped stable all together (as is the case with 
a couple of the obscure archs, labeled 'experimental') it would only be 
beneficial to me, as that would be more testing and developer power for 
the ~arch I'm actually running.

But I'm not selfish enough to wish that on the folks running stable.  I'm 
just not interested in something that stale, is all, so it doesn't matter 
to me one way or the other.

> If it is STABLE, mark it as such.  Don't sit here and tell me, 'Oh just
> run ~amd64 widget, it's stable'.

They DO mark it as such, when they KNOW it's stale.  But they don't KNOW 
it's stale, unless it has been reasonably tested on an otherwise stale 
system, and the people willing to do that testing and actually report the 
results aren't so easy to come by, so it's taking longer to know it's 
stale.

> When I started with Gentoo in 2005/6, I could emerge -uD world and know
> it'll pull in the latest stable packages and be done with it.  Now, I
> have to watch because some packages aren't, some might need a downgrade
> of a package, which I have to mask so it doesn't get downgraded, ad
> infinitum.

Well, as I said, mixed stale and unstale isn't well tested or supported.  
But if it's marked stale and is removed, forcing a downgrade, there's a 
reason for it.  OTOH if you package.keyworded as specific version, and it 
goes away, then yes, portage will suggest a downgrade.  But that could 
only happen because it wasn't considered stale in the first place, and as 
an ~arch package with newer ones available, it can be removed.

> To me, the distro is just feeling kinda sloppy on the back end.  No, I'm
> not looking for a 'Ubuntu' experience.  That distro gives me heartburn.
>  But, geez, I do expect packages to be moved from testing to stable
> slightly more often than never.  I'm not trying to be overly critical
> here, but the way things are going, it's getting /harder/ to maintain a
> STABLE system now than it used to be.

It may indeed be getting harder to maintain a stale system.  I wouldn't 
know.  But what I can say is what I said above, the only way the packages 
are going to move to stale is if people on stale test them and say they 
work on stale.

> And, FWIW, on topic, having qt3support globally makes no difference. I
> still have a thousand bleeding hoops to jump through to fix all the
> asinine blocks and dependencies.

It's really not that bad.  As revealed in a different post, you had parts 
of and old qt4 blocking the newer version.  As I said, trying to do 
multiple versions of the qt4 components doesn't work.  It has to be all 
one version.  Again as I said, once it's all one version, if you do 
--update --deep, the system should pretty much take care of its own 
updates.  But it can't do that safely with split versions, and it'll have 
difficulty doing it if you don't run your updates with --deep, as well.

So you're breaking at least one and possibly two rules (in addition to 
running an unsupported partially ~arch and partially stale arch system), 
trying to have multiple qt4 versions, and possibly, trying to update 
without using --deep, thus only making more trouble for yourself.

If it's that far behind, why not run ~arch?  A number of users have 
reported that full ~arch has actually been more stable for them than 
partially stale, partially ~arch.  Either you want stale or you don't, 
and it doesn't appear you're satisfied with it, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-amd64] Re: New Jpeg-7 -- was Re: kdelibs insanity

[Duncan]

Frank Peters <frank.peters@comcast.net> posted
20090731094421.1f290168.frank.peters@comcast.net, excerpted below, on 
Fri, 31 Jul 2009 09:44:21 -0400:

> Also, unless I am mistaken, any patch that accommodates jpeg-7 will no
> longer function with jpeg-6.

Well, they should be able to #IFDEF it of necessary.  So a package that 
built against the one wouldn't work with the other, but could be compiled 
against either.  That's common enough...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Paul Hartman]

On Fri, Jul 31, 2009 at 8:44 AM, Frank Peters<frank.peters@comcast.net> wrote:
> Since I process a lot of images, libjpeg is very important to me.  The new
> jpeg-7 now includes arithmetic encoding which can produce smaller compressed
> file sizes and there are also some changes to the scaling and quality features.
> Unlike most Open Source packages, which are updated quite frequently (too
> frequently?), jpeg-7 is the first new release since 1998.
>
> Rather than wait for Gentoo to create the ebuilds for the new jpeg-7, I decided
> to compile it myself and then list it in packages.provided.  In addition,
> the old jpeg-6 shared objects were kept, but all the include files and
> static libraries for linking would refer to the new jpeg-7.  In this way,
> any update of a package that depends on libjpeg would be linked with the
> new libraries, but any existing package that still needs jpeg-6 could be
> left untouched.  I don't like to have to re-compile everything at once.  When
> the time comes to update a package the new libraries will be available but until
> then the old libraries will suffice.  (Gentoo is flexible enough to nicely
> accomodate this.)
>
> However, after emerging a new GTK+, which automatically then became linked
> to the new jpeg-7 libraries, I noticed a severe problem.  Jpeg images viewed
> using programs that depend on GTK+ -- and there are a lot of them -- were
> strangely blurred and out of focus.  Doing some searching, I found this
> thread that explains the problem:
>
> http://bbs.archlinux.org/viewtopic.php?id=75529
>
> The issue is with the new scaling methods in jpeg-7.  Programs such as firefox
> and many others process images through GTK+ facilities, and GTK+ needs to be
> patched before it can utilize the new jpeg-7.  AFAIK, the GTK+ people do not
> even yet know about this issue.  Also, unless I am mistaken, any patch that
> accommodates jpeg-7 will no longer function with jpeg-6.
>
> So there ends my nice, neat plan to have both jpeg-7 and jpeg-6 together
> serving my system.  The situation also illustrates how unanticipated problems
> can easily be injected into this loose but wonderful conglomeration known
> as Open Source software.

FWIW the newly-released gtk+ 2.16.6 of a coupel days ago still has the
problem with jpeg-7, but there was a patch in the gtk bugzilla that
fixed the problem for me:

Author: Romain Perier <mrpouet@gentoo.org>
Subject: Ensure gdk-pixbuf is backward compatible with jpeg6, even if
it's works with jpeg7
Date: 2009-09-01 10:27 UTC

---
 gdk-pixbuf/io-jpeg.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/gdk-pixbuf/io-jpeg.c b/gdk-pixbuf/io-jpeg.c
index cf8c9ed..9af55ba 100644
--- a/gdk-pixbuf/io-jpeg.c
+++ b/gdk-pixbuf/io-jpeg.c
@@ -921,8 +921,11 @@ gdk_pixbuf__jpeg_image_load_increment (gpointer data,
                                        return FALSE;
                                }
                        }
-
+#if JPEG_LIB_VERSION >= 70
+                       for (cinfo->scale_denom = 2;
cinfo->scale_denom <= 16; cinfo->scale_denom *= 2) {
+#else
                        for (cinfo->scale_denom = 2;
cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) {
+#endif
                                jpeg_calc_output_dimensions (cinfo);
                                if (cinfo->output_width < width ||
cinfo->output_height < height) {
                                        cinfo->scale_denom /= 2;

Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Paul Hartman]

On Wed, Sep 2, 2009 at 9:12 AM, Paul
Hartman<paul.hartman+gentoo@gmail.com> wrote:
> FWIW the newly-released gtk+ 2.16.6 of a coupel days ago still has the
> problem with jpeg-7, but there was a patch in the gtk bugzilla that
> fixed the problem for me:

Argh, the formatting got mangled. Sorry about that. Get it from here instead:
http://pastebin.com/f72debd44

Also, there was at least one package that needed to be rebuilt despite
the fact revdep-rebuild didn't think so: media-libs/sdl-image

I'm curious to know if there are any more out there hiding...

Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Mark Haney]

Paul Hartman wrote:

> 
> Also, there was at least one package that needed to be rebuilt despite
> the fact revdep-rebuild didn't think so: media-libs/sdl-image
> 
> I'm curious to know if there are any more out there hiding...
> 

Just for the record, did anyone else not get the OP to this reply? I'm
curious as to the problem the OP was having.


-- 
Non curo. Si metrum non habet, non est poema.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

[gentoo-amd64] Re: New Jpeg-7 -- was Re: kdelibs insanity

[Nikos Chantziaras]

On 09/02/2009 06:29 PM, Mark Haney wrote:
> Paul Hartman wrote:
>
>>
>> Also, there was at least one package that needed to be rebuilt despite
>> the fact revdep-rebuild didn't think so: media-libs/sdl-image
>>
>> I'm curious to know if there are any more out there hiding...
>>
>
> Just for the record, did anyone else not get the OP to this reply? I'm
> curious as to the problem the OP was having.

"was: Re: kdelibs insanity"

Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Paul Hartman]

On Wed, Sep 2, 2009 at 10:29 AM, Mark Haney<mhaney@ercbroadband.org> wrote:
> Paul Hartman wrote:
>
>>
>> Also, there was at least one package that needed to be rebuilt despite
>> the fact revdep-rebuild didn't think so: media-libs/sdl-image
>>
>> I'm curious to know if there are any more out there hiding...
>>
>
> Just for the record, did anyone else not get the OP to this reply? I'm
> curious as to the problem the OP was having.

Original of this branch of the thread was by Frank Peters on July 31.

Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Mark Haney]

Paul Hartman wrote:
> On Wed, Sep 2, 2009 at 10:29 AM, Mark Haney<mhaney@ercbroadband.org> wrote:
>> Paul Hartman wrote:
>>
>>> Also, there was at least one package that needed to be rebuilt despite
>>> the fact revdep-rebuild didn't think so: media-libs/sdl-image
>>>
>>> I'm curious to know if there are any more out there hiding...
>>>
>> Just for the record, did anyone else not get the OP to this reply? I'm
>> curious as to the problem the OP was having.
> 
> Original of this branch of the thread was by Frank Peters on July 31.
> 

Ah. Okay, /that's/ why I don't have the thread in my inbox.  I archive
off anything older than a month.  Thanks for clearing that up, I was
afraid our mail server was acting up.



-- 
Non curo. Si metrum non habet, non est poema.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415