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 attachment 53509 [details, diff] files/kasteroids-3.4.0-keypressfix.patch
Created attachment 53510 [details, diff] 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 attachment 53926 [details, diff] 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.