Bugzilla Bug 80944

With the exception of bugs in pilot-link and mpeglib that I have filed, all of
kde-meta builds on amd64 here.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Portage 2.0.51-r15 (default-linux/amd64/2005.0, gcc-3.4.3,
glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.10-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.4 [2.3.4 (#1, Jan 16 2005, 12:39:31)]
dev-lang/python:     2.3.4
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r2
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-O2 -pipe -mtune=k8"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/mail/dspam /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe -mtune=k8"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X aalib acpi alsa apache2 arts artswrappersuid audiofile berkdb
bitmap-fonts cdr crypt cups cyrus dvd fam flac font-server foomaticdb gif gpm
gtk imlib ipv6 java jp2 jpeg kde libclamav libwww lm_sensors lzw lzw-tiff motif
multislot mysql ncurses nls nptl offensive oggvorbis opengl oss pam perl pic
png
python qt readline samba sasl slang ssl tcltk tcpd tetex tiff truetype
truetype-fonts type1-fonts usb userlocales xml2 xmms xpm xrandr xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY

We don't have amd64 people on the kde team. The main amd64@ team is handling
keywording and the like.
Anyway, you'll have beta2 to test in a few days :-)

> We don't have amd64 people on the kde team.

Why?

Because none donated us an Athlon64/AthlonFX/Opteron system. :P

BTW, Dan was only saying that usually bug related to KEYWORDING should be submitted to the various arch herds (like amd64@gentoo.org, x86@gentoo.org, sparc@gentoo.org etc...).

Thanks for your help in testing all the ebuilds.

I am not in the KDE herd, but am in the amd64 and sci herds. I handle a lot of
the KDE stuff on amd64 now. I will try to take a look at these when I have time
- might wait for beta 2 though, I have already tested the beta1 monolothic
builds. Please assign to amd64@gentoo.org in future and we will try to get to
them in a timely fashion.

Still not fixed with rc1.

Hey - I am working on it. I have been away at FOSDEM, busy and ill ;) I am
currently testing kdebase-meta and all its deps for rc1. If I can verify it all
compiles and works properly I will keyword kdebase-meta and its deps initially,
moving on to the rest after that.

Dan Armak - some of the deps for the kdebase-meta-rc1.ebuild did not have rc1
ebuilds, so I had to copy them from the beta2 ebuild - have you just not
finished the refresh yet, or has something else happened?

No no no. They're supposed to stay at beta2. Don't copy them to rc1. Those are
packages that weren't changed in beta2->rc1. (Getting the right system of deps
in place for this to work correctly wasn't fun...)

The point is to save people's recompiling time, and keywording time too. After
you keyword all of rc1 you won't have many new packages to keyword for 3.4.0
final. I can see though we're going to have to answer a lot of user questions
about this...

We've already decided to make 3.4.0 (i.e. final) ebuilds for all
packages, even though most of them won't have changed since rc1. It'd be too
confusing for users to get a mix of 3.4.0, rc1 and a few beta2 packages.

What we really need is a 'versionmove' update instruction :-)

I saw in the ebuilds that they seemed to have stuff about rc1 in the beta 2
ebuild, but when I keyworded and unmasked them the dep still was not satisfied
until I copied them. I am tired - so I will try again tomorrow then.

I get what you mean though about minimising recompilation, but portage seeemed
unable to satisfy the deps on the fresh install...

kdebase-meta-3.4.0_rc1 and all of its deps are marked ~amd64 now. I have tested
this set up, and it seems to work well. Please test it out. I will mark by meta
package and deps as and when I get time to test and process them.

Re: comment 9: meaning the problem described in comment 8 (unsatisfied deps)
is gone? If not, please give more details.

I think it was just me - I went back to it, did as you said and the deps now
seemed to be getting satisfied. I have keyworded rc1 or beta2 if rc1 was not
there and satisfied all of kdebase-meta's deps and it seemed to compile and
work fine.

I would like some more independent testing of the split ebuilds though, and
will continue to keyword the rest as I get time to test and keyword them.

kdepim-meta-3.4.0_rc1 and all of its deps are now keyworded ~amd64.

kdegames-meta-3.4.0_rc1 is now marked ~amd64, along with all of its deps.

I have keyworded kdenetwork-meta-3.4.0-rc1 and kdegraphics-meta-3.4.0-rc1 and
all of their deps.

I have keyworded kdeutils-meta-3.4.0-rc1 and kdetoys-meta-3.4.0-rc1 + deps now
too. Deps still appear unsatisfied until the beta2 is keyworded, then all works
just fine on my test system and chroot.

kdeartwork-meta-3.4.0-rc1 + deps marked ~amd64.

I have marked kdeaddons-meta-3.4.0-rc1 and kdewebdev-meta-3.4.0-rc1 ~amd64,
along with their deps.

I have marked kdeedu-meta-3.4.0-rc1 and kdeadmin-meta-3.4.0-rc1 ~amd64 now,
along with their deps. Nearly there now!

Just marked kdesdk-meta-3.4.0_rc1 and its deps ~amd64 - only three more -metas
to test and mark ~amd64 now!

kdeaccessibility-meta-3.4.0_rc1 and deps marked now. I can't mark
kdebindings-meta until bug 84197 is fixed, as this is a dep of it. Only
kdemultimedia-meta-3.4.0_rc1 is required now to mark the kde-meta ebuild
~amd64.

Ah... Don't want to get you down, but I'm committing the 3.4.0 (final) ebuilds
now... :-)

Tarballs will be available Wednesday, but we can provide them to any
Gentoo devs who want to start keywording before then.

Most packages didn't really change, but since this is the first split ebuilds
release and the users aren't used to it, we've bumped the version numbers on
all packages regardless, as discussed previously. So you're going to have to
keyword everything all over again. Sorry about that, but at least there won't
be much new testing to it.

Could you provide me with the tarballs? Email/IRC me - I would like to have
everything keyworded and ready for the final release. I was about to start
keywording the last few rc1 ebuilds - but I will hold off if you are committing
the final ebuils. Please keep the ~amd64 keyword in all ebuilds where it is
already present.

Thanks!

Just working my way through the new commit you made - and lots of my keywords
seem to have been dropped on the final ebuilds :( I am working my way through,
but I have had to add them back to most of the ebuilds.

Sorry - it seems to only have affected kdelibs, and the -meta ebuilds. I think
most of the smaller ones are still keyworded. Working my way through them all
now, and I will add back in as necessary.

Ugh, sorry about that. I think I may have re-added the amd64 keywords only to
the ebuilds that existed in rc1 and had them (i.e. not the ones whose latest
version was beta2).

You also managed to keyword a couple I hadn't keyworded too. The games which
depend on the arts USE flag, kasteroids is actually crashing here so I have
marked it -amd64 for now. Crashes whenever L is pressed to lauch! Otherwise it
seems to be working quite well for what I have tested so far.

Created an attachment (id=53509) [edit]
files/kasteroids-3.4.0-keypressfix.patch

Created an attachment (id=53510) [edit]
kasteroids-3.4.0.ebuild.diff

Dan, I have added two attachments for a patched kasteroids. This gets rid of
the crasher for me. I didn't want to commit the fix as it is not my package -
if you could test and commit (or tell me it is OK to commit) I can have
kde-meta keyworded too.

Thanks.

Everything should be keyworded now for kde-meta except for kdegames-meta due to
kasteroids. I have reported the patch upstream for kasteroids, and someone has
commented that it may not be the right solution and I don't program games in
KDE. It works for me(TM).

http://bugs.kde.org/show_bug.cgi?id=101542

In my testing so far kasteroids is the only crasher, the rest seem to be
working well AFAIK.

I've had very little free time this past week and will continue that way for
the next two weeks... At least then I've a vacation...
I've found kde.org bug #101542 where you've submitted this patch....
I've reproduced the bug and the patch does work for me (on x86). However it's
obviously a workaround not a fix (replaces a dynamic_cast with a (type) cast),
and I don't have time to find and fix the real problem... So I don't want to
apply it as-is unless noone else has time to fix it in a better way, either.

Created an attachment (id=53926) [edit]
files/kasteroids-3.4.0-keypressfix.patch

Updated patch, also submitted upstream. I have done some more research on the
issue and this patch seems to be much cleaner. Check it is a key press/release
event and then statically cast it - this is theoretically more efficient, all
the function does and best of all - it works.

Otherwise I could do with someone pointing me to a good guide/book to educate
me further in this area.

Please see the upstream bug - it appears that this issue is related to KDE's
support of visibility, and our backported visibility patches in GCC 3.4. So no
patching of kasteroids is strictly necessary, as it should work once the
visibility stuff is sorted. Right now dynamic_cast is broken, and this could be
causing other problems elsewhere too.

There is a hackish patch upstream now, we could remove the visibility stuff
from GCC as it seems to cause a lot of issues, or wait on an upstream patch for
this. I am recompiling gcc without visibility patches, and am then going to
rebuild KDE to confirm this - the patch also seemed to work in my testing
chroot.

KDE team - would you like me to open another bug on this issue? It isn't really
amd64 keywording anymore - that is done apart from kasteroids. I would like to
check out how many other problems clear up without the visibility stuff too.

I've opened it, I've set it as a dependency on that bug :)
I've also posted the patches which could fix it.

I committed the patched eclasses a little earlier. Now marking the last three 
ebuilds ~amd64 as they work when visibility is disabled. KDE 3.4 meta split 
ebuilds should all be marked ~amd64 if I haven't missed any.