Please abstain from starting a pointless discussion here or asking when there will be KDE 4.1 ebuilds in the Gentoo repository. For reference you may want to read bug 233301. Thank you.
Could you create a status matrix of all packages in KDE 4.1 and mark each of them as DONE, TESTING and TODO. Then users could see what's the status and do not ask stupid questions. Similar thing is done for instance in the Nouveau project (http://nouveau.freedesktop.org/wiki/FeatureMatrix).
I put together a quick page that somewhat resembles a feature matrix, and is automagically updated twice a day, it's here: http://skrypuch.com/kde4/ It compares the packages found in the kde-portage overlay with the packages found in the kdesvn-portage overlay to arrive at an estimate. I'm not sure how reasonable this estimate is, but it's probably better than nothing.
(In reply to comment #2) > I put together a quick page that somewhat resembles a feature matrix, and is > automagically updated twice a day, it's here: > > http://skrypuch.com/kde4/ Thanks for working on the matrix. That might help users getting a feeling of how things are evolving. I would suggest people also follow the overlay git page http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary and http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=shortlog > It compares the packages found in the kde-portage overlay with the packages > found in the kdesvn-portage overlay to arrive at an estimate. I'm not sure how > reasonable this estimate is, but it's probably better than nothing. > If you don't mind, please be sure to compare only the packages with the 4.1 ebuilds. One example of a package that doesn't matter is kdenetwork-kfile-plugins.
(In reply to comment #3) > If you don't mind, please be sure to compare only the packages with the 4.1 > ebuilds. One example of a package that doesn't matter is > kdenetwork-kfile-plugins. > I tweaked the page so that it excludes directories that only have version 9999 ebuilds in them. It also now excludes directories that don't have ebuilds in them at all, such as Documentation.
Great work Neil :) Just one thing, i think you should remove apps like k3b, koffice, digikam, amarok which i doubt they'll write the ebuilds now (also because stuff like koffice 2 and amarok 2 aren't released yet as final :) ). Probably also the kde-misc, media-video, mail-client, net-im, net-p2p and x11-themes. But i'd like Vicetto about these ;) btw, thanks for the work :)
Great!
Today (27/08) kde 4.1.1 will probably be tagged and the next week will be released. What will the gentoo kde team do? I mean, i don't know if it's useful to release the 4.1.0 when the 4.1.1 is released, maybe is better to wait something more and release directly the 4.1.1 (as i think that from the 4.1.0 to the 4.1.1 the ebuilds are mostly the same, just a fast check that everything works and maybe little modifications). What do you think?
(In reply to comment #7) > Today (27/08) kde 4.1.1 will probably be tagged and the next week will be > released. What will the gentoo kde team do? Yes, we're not going to put 4.1 in the tree, but 4.1.1. The ebuilds for 4.1 are almost done, kde-3.5.10 should be available soon, EAPI-2 is on the works, cmake-2.6 is being tested and we're going to have a look at the eclasses soon. We'll start bumping ebuilds to 4.1.1 in the overlay as soon as we can, so 4.1 is getting closer to be on the tree.
(In reply to comment #8) > > Yes, we're not going to put 4.1 in the tree, but 4.1.1. > The ebuilds for 4.1 are almost done, kde-3.5.10 should be available soon, > EAPI-2 is on the works, cmake-2.6 is being tested and we're going to have a > look at the eclasses soon. > We'll start bumping ebuilds to 4.1.1 in the overlay as soon as we can, so 4.1 > is getting closer to be on the tree. > The sooner it gets into portage official, the better, I'd much rather avoid using overlays (though the kdesvn-portage overlay has done a wonderful job), it just makes things simpler.
We've already started the work for 4.1.1.
4.1.1 just released. You ready, KDE-team?
(In reply to comment #11) > 4.1.1 just released. > You ready, KDE-team? > Please see the bug description: "Please abstain from starting a pointless discussion here or asking when there will be KDE 4.1 ebuilds in the Gentoo repository. For reference you may want to read bug 233301. Thank you."
(In reply to comment #12) > Please see the bug description: > > "Please abstain from starting a pointless discussion here or asking when there > will be KDE 4.1 ebuilds in the Gentoo repository. For reference you may want to > read bug 233301. Thank you." > Yes, I know. I just informed you that 4.1.1 released.
(In reply to comment #13) > Yes, I know. I just informed you that 4.1.1 released. Don't worry about the gentoo's kde herd missing it, they are pretty well informed about releases.
When looking at http://skrypuch.com/kde4/ one sees that KDE seems to be almost in the three. But some applications are missing e.g. app-cdr/k3b app-editors/kile app-office/koffice media-video/kplayer media-video/kplayer kde-misc/kblogger I think the overlay would be much more interesting, if these only 6! ebuilds where added. Since applications like k3b or koffice or kile might be those with which most users do their daily work. 6 ebuilds should not be too difficult to write, aren't they?
The problem with that applications is that there aren't stable version (even betas!!!) already, and more important, if you install any of those from svn you can see that are terrible broken already so they cannot make a snapshot.
If there aren't stable versions of the remaining applications, then they must not have been included as part of the KDE 4.1.1 release. If those packages had been included as part of the KDE 4.1.1 release, then there WOULD be stable versions of them. Therefore, KDE 4.1.1 (which then would not include the unstable packages like K3b, Kile, and KOffice) should be released into Portage without further delay. Delaying the rest of KDE 4.1.1 while waiting for a few pseudo-third-party stragglers to stabilize is nonsense. Is there anyone on the KDE herd that can give us a straight answer? I know comments here in this bug report aren't going to speed along the release, but SOME STATUS REPORT from the KDE herd would put a lot of us at ease. Even if they are actually working non-stop, it appears to the rest of us on the outside that they are twiddling their thumbs. Where's the official release schedule? The Gentoo Foundation as a whole is acting very unprofessionally about this.
(In reply to comment #17) > If there aren't stable versions of the remaining applications, then they must > not have been included as part of the KDE 4.1.1 release. If those packages had > been included as part of the KDE 4.1.1 release, then there WOULD be stable > versions of them. Therefore, KDE 4.1.1 (which then would not include the > unstable packages like K3b, Kile, and KOffice) should be released into Portage > without further delay. Delaying the rest of KDE 4.1.1 while waiting for a few > pseudo-third-party stragglers to stabilize is nonsense. AFAIK, these apps aren't blockers on the kde 4.1.1 release on the portage tree. Ebuilds are being tested in the kde-testing overlay, and they haven't been released yet due to the developers not being completely satisfied with the current ebuilds and for some wider questions involving portage that are scheduled to be discussed in the next council today, I think. Let them take the time to produce a quality release. > > Is there anyone on the KDE herd that can give us a straight answer? I know > comments here in this bug report aren't going to speed along the release, but > SOME STATUS REPORT from the KDE herd would put a lot of us at ease. Even if > they are actually working non-stop, it appears to the rest of us on the outside > that they are twiddling their thumbs. Where's the official release schedule? > The Gentoo Foundation as a whole is acting very unprofessionally about this. > Please see the first post in this bug and the bug that is linked there. Pressing the developers will not make the release faster nor better.
> Is there anyone on the KDE herd that can give us a straight answer? I know > comments here in this bug report aren't going to speed along the release, but > SOME STATUS REPORT from the KDE herd would put a lot of us at ease. Even if > they are actually working non-stop, it appears to the rest of us on the outside > that they are twiddling their thumbs. Where's the official release schedule? > The Gentoo Foundation as a whole is acting very unprofessionally about this. > Just to clarify, as the Foundation isn't responsible for package maintenance, if one thought so, it would be the Gentoo Project being unprofessional. The KDE team members have made quite a few comments in this bug, its predecessor, blogs and on the #gentoo-kde channel.
cruzki wrote: The problem with that applications is that there aren't stable version (even betas!!!) I remember having compiled Kile last spring shortly after KDE4.0 came out and I thought it was pretty stable at that time (I believe Kde 2.0.4 onwards can be compiled with KDE4. Now, Kile 2.0.5 seems to exist in the three. One reason for the observed stability might be, that Kile will be almostly the same after porting to KDE4.1. But I think regardless if these applications are stable or not, if KDE4.1 is put in the three, one should at least include hard-masked versions of Kile and/or k3b. (another thing might be with kdevelop. Since that is indeed in a stage, where I wasn't able even to compile)
Sorry, the sentence: I believe Kde 2.0.4 onwards can be compiled with KDE4. Should mean: I believe Kile 2.0.4 onwards can be compiled with KDE4 based systems
(In reply to comment #19) > The KDE team members have made quite a few comments in this bug, its > predecessor, blogs and on the #gentoo-kde channel. Could you (or someone) post some links to places where we users can check on the status of getting the KDE 4.1.1 ebuilds finished? Neil Skrypuch's status page is only marginally informative, as it doesn't have any running commentary on what is being accomplished and why the ebuilds are still not considered to be of sufficient quality for release. Is there a ticket tracker somewhere showing what needs to be fixed/completed? Is there a calendar? Who is organizing the effort? Do they have a development blog? Information please!
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=shortlog "Neil Skrypuch's status page is only marginally informative" If you had followed links on his web page, you would come across this exact link. Stop being a child. It will be ready when it is ready (tm). KDE team is still working on the ebuilds, so wait patiently or install Ubuntu if you don't care about release quality. Or if you want your system damaged in process. And for the last time: use Gentoo forums to discuss anything different than the ebuilds itself. Lots of people are subscribed to this bug and it's becoming irritating to hear your whining.
by the way, I see that only Digikam_beta 2 seems to be in the overlay? Now Beta 3 came out, It should not be too difficult to change the ebuild: http://www.digikam.org/
(In reply to comment #24) > by the way, I see that only Digikam_beta 2 seems to be in the overlay? > > Now Beta 3 came out, It should not be too difficult to change the ebuild: > http://www.digikam.org/ > Beta 3 wont be included, because it is working only with 4.2 snapshots. Digikam people obviously aim for release with 4.2 :]
I guess we'll be seeing 4.1.2 as the first release instead :) (Tagged 24th September, release 1st of October)
you are such an optimistic guy :-)
I have a question for KDE Gentoo team. The things on Gentoo forum are being slowly cleared up regarding KDE 4. I've created a guide and got it sticky in Desktop Environment: http://forums.gentoo.org/viewtopic-t-708282.html It's some kind of overview about overlays and KDE 4 portage version/status. As it's possible that KDE4-related posting will be less chaotic and random from now on - are you guys interested in having exclusive 'support' thread for your overlay? [kde-testing]. Link to that thread would be added to guide mentioned, with some description.
I have just installed kde 4.1.1 from the kde-portage repository and I have noticed one error. The kdebase-startkde package installed the file called "4" instead of "kde-4" (or kde-4.1?) into the directory /etc/X11/Sessions/.
Please could you add the net-ftp/kftpgrabber ebuild into the list at http://skrypuch.com/kde4/? I have made an ebuild for it (#238393).
(In reply to comment #30) > Please could you add the net-ftp/kftpgrabber ebuild into the list at > http://skrypuch.com/kde4/? I have made an ebuild for it (#238393). > Based on earlier comments, I had the page not display ebuilds that only have CVS (9999) versions, as they're likely not keeping 4.1 from being pushed into Portage. It'll appear if there's at least one non-9999 version of it.
(In reply to comment #31) > Based on earlier comments, I had the page not display ebuilds that only have > CVS (9999) versions, as they're likely not keeping 4.1 from being pushed into > Portage. It'll appear if there's at least one non-9999 version of it. OK, I understand. I have found one more problem. If I have installed kde4 side by side with kde-3, some programs don't want to compile (e.g. media-tv/mtvg). The problem is, that if it is trying to link files together: /bin/sh ../libtool --silent --mode=link --tag=CXX x86_64-pc-linux-gnu-g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -DNDEBUG -DNO_DEBUG -O2 -march=k8 -O2 -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -Wl,-O1 -o maxemumtvguide -R /usr/kde/3.5/lib64 -R /usr/qt/3/lib64 -R /usr/lib64 -R /usr/kde/3.5/lib64 -L/usr/lib64 -L/usr/qt/3/lib64 -L/usr/kde/3.5/lib64 -L/usr/kde/3.5/lib64 main.o maxemumtvguide.o mainwidget.o channel.o channelitem.o channelmaster.o channelview.o favourite.o favouritemaster.o parsemaster.o parser.o program.o programitem.o programmaster.o programview.o remindwindow.o trayicon.o updatedialog.o blistmaster.o searchview.o baseview.o completeview.o forumview.o prefsdialog.o wmainwidget.o waboutdialog.o wreminderdialog.o wupdatedialog.owrenamedialog.o wprefsdialog.o wnewuserdialog.o updatedialog.moc.o baseview.moc.o favouritemaster.moc.o programview.moc.o prefsdialog.moc.o mainwidget.moc.o blistmaster.moc.o channelview.moc.o channelitem.moc.o forumview.moc.o completeview.moc.o remindwindow.moc.o searchview.moc.o -lkdeui -lkio it is searching for libs first in -L/usr/lib64 and after that in -L/usr/kde/3.5/lib64. That's a problem if you have kde-4 installed in /usr! So, by my opinion, it is quite desired to have USE="kdeprefix" as a default. Then it can search for libs in /usr/lib64 (there are no kde libs) even before it search in /usr/kde/<kde_version>/lib64.
Re Comment #32: I would think that's a bug in the build systems of those packages. I beleive that they should be adding "$(kde4-config --prefix)/lib" to there linker path in order to compile and link correctly.
Before I open a seperate bug for this: kdevelop-3.5.3 does not seem to compile, complaining it cannot find a KDE >=3.4.0 (even thought kdelibs 3.5.10 is installed). Is that a known issue? Or do I just do something wrong?
Hi, i updated the ebuilds yesterday and i found two bugs: -kdm doesn't install his executable where the xdm init script expects (an error occurs in xdm start) - the yakuake 2.9.3 ebuild installs only the doc, it does not compile any executable. I hope this comments to be useful.
So - 4.1.2 it is, I presume, since release is on Wednesday. I hope the operation doesn't require more than just renaming the ebuilds.
I've been testing the kde 4.1.1 kde-testing ebuilds and they are working quite well. Yesterday, I've reemerged the entire @kde set without any issues. Hopefully, 4.1.2 will be an easy call from the current, high quality ebuilds.
(In reply to comment #37) > I've been testing the kde 4.1.1 kde-testing ebuilds and they are working quite > well. Yesterday, I've reemerged the entire @kde set without any issues. > Hopefully, 4.1.2 will be an easy call from the current, high quality ebuilds. > Please, could you try to recompile your KDE with USE="kdeprefix"? Few days ago (last week), I have tried to do that and some directories were installed with permissions 700 instead of 755. The consequence was, that there was no desktop effects and no screen savers in the list. It is bug in KDE-4 cmake files or in your ebuilds or in emerge (it was used portage-2.2_rc9)? Here is the complete list of the directories: /usr/kde/4.1/share: drwx------ 5 root root 128 2008-09-25 12:37 applnk /usr/kde/4.1/share/applnk: drwx------ 3 root root 88 2008-09-25 12:37 Development drwx------ 2 root root 48 2008-09-25 12:37 .hidden drwx------ 3 root root 80 2008-09-25 12:37 System /usr/kde/4.1/share/applnk/Development: drwx------ 2 root root 48 2008-09-25 12:37 X-KDE-KDevelopIDE /usr/kde/4.1/share/applnk/System: drwx------ 2 root root 48 2008-09-25 12:37 ScreenSavers /usr/kde/4.1/share/kde4/services/kresources: drwx------ 2 root root 512 2008-09-25 16:33 kabc drwx------ 2 root root 592 2008-09-25 16:33 kcal drwx------ 2 root root 192 2008-09-25 16:33 knotes /usr/kde/4.1/share/kde4/services drwx------ 2 root root 1104 2008-09-25 16:24 kaddressbook drwx------ 2 root root 712 2008-09-25 15:49 kconfiguredialog drwx------ 2 root root 256 2008-09-25 16:37 kontact drwx------ 2 root root 272 2008-09-25 16:37 korganizer drwx------ 5 root root 240 2008-09-25 16:29 kresources drwx------ 2 root root 1968 2008-09-25 20:21 kwin drwx------ 2 root root 752 2008-09-25 20:38 ScreenSavers drwx------ 2 root root 3336 2008-09-25 20:23 searchproviders drwx------ 2 root root 168 2008-09-25 20:46 ServiceMenus drwx------ 2 root root 216 2008-09-25 20:17 solidbackends drwx------ 2 root root 1008 2008-09-25 20:52 useragentstrings Btw. if I install KDE-4 into the default directory /usr (without USE="kdeprefix"), compilation of the gambas-2.8.2 failed (see bug #238483)! IMHO the USE="kdeprefix" should be as default (see also my previous comments here) because otherwise it could be a case of several problems for standard users.
Well, looks like that the KDE team is now pushing back things until 4.1.2 :( Should the summary be updated?
that "pushing back" look like its not beeing an issue as kde 4.1.2 ebulds are added to the tree currently, we just have to wait until the tarballs hit the offical mirrors when its finally released.
i had problems with download the 4.1.2 tarballs. sample: ftp://ftp.du.se/pub/mirrors/kde/stable/4.1.2/src/kdelibs-4.1.2.tar.bz2 the tarballs are found in moment there: http://websvn.kde.org/tags/KDE/4.1.2/ greets
(In reply to comment #41) > i had problems with download the 4.1.2 tarballs. > because kde 4.1.2 is not release yet.
Will checking out from the SVN and making a tar.bz2 out of that pass the MD5 tests in portage?
probably not. Just wait a few hours, those tarballs are currently being created/dispatched on mirrors.
Tarballs are available now.
Many - and big - thanks to the KDE team for this.
KDE 4.1.2 has been officially released now. Just a question: will the packages being unmasked or do I have to unmask them myself? Anyway, thank you very much for the ebuilds :-)
> KDE 4.1.2 has been officially released now. Just a question: will the packages > being unmasked or do I have to unmask them myself? here you have unmask and keywords files http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation
(In reply to comment #48) > > KDE 4.1.2 has been officially released now. Just a question: will the packages > > being unmasked or do I have to unmask them myself? > > here you have unmask and keywords files > http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation Well, yes, thanks, but this isn't the answer to my question: will the packages be unmasked soon (e.g. in a couple of hours) or do I have to unmask them myself? If they are being unmasked there's no reason to clutter package.unmask..
The 4.1.2 ebuilds should be unmasked soon, but until then use the kde-testing overlay package.unmask file. in reply to #49 Mark, if you use a /etc/portage/package.unmask dir, you can add the kde4 file there until the ebuilds are unmasked and after that you can safely remove the file.
BTW, i had to "git checkout -f -b 4.1.2 origin/4.1.2" and then ln -s /$OVERLAY/Documentation/package.unmask/kde* /etc/portage/package.unmask/ ln -s /$OVERLAY/Documentation/package.keywords /etc/portage/package.keywords/ Is this the right way to install it? Plans to merge with origin/master the 4.1.2 branch? Thanks!
Another thing, before starting upgrade to 4.1.2 (which is ongoing) i had installed 4.1.1 from this overlay with kdeprefix unset. Now at first try i had a problem during kdelibs's installation related to config-protect. Probably related to the files from 4.1.1 but seems strage, isn't emerge supposed to replace files during an upgrade? Anyhow, kdelibs installation went fine after setting: COLLISION_IGNORE="/usr /lib/modules" in /etc/make.conf Now my laptop is happily compiling kdepimlibs.
While installing =kde-meta-4.1.2 I realized that =app-crypt/qca-ossl-2.0.0_beta3 should depend on some package containing "qmake". Emerging =x11-libs/qt-core-4.4.2 worked fine for me.
(In reply to comment #51) The 4.1.2 branch was merged back into master. If you're not seeing that, then be sure to sync the overlay and switch back to HEAD. (In reply to comment #52) > Another thing, before starting upgrade to 4.1.2 (which is ongoing) i had > installed 4.1.1 from this overlay with kdeprefix unset. Now at first try i had > a problem during kdelibs's installation related to config-protect. Probably > related to the files from 4.1.1 but seems strage, isn't emerge supposed to > replace files during an upgrade? Anyhow, kdelibs installation went fine after > setting: > COLLISION_IGNORE="/usr /lib/modules" > in /etc/make.conf > Now my laptop is happily compiling kdepimlibs. > Please don't do that. That error was caused by you having 4.1.1 in SLOT 4 and 4.1.2 being in slot 4.1 The correct solution here is to remove the old ebuilds or update their slot. I'm for this, but we used kde-testing for testing a few things before we were finally able to reach a solution to our issues.
First thanks for the reply, (In reply to comment #54) > (In reply to comment #51) > The 4.1.2 branch was merged back into master. If you're not seeing that, then > be sure to sync the overlay and switch back to HEAD. Indeed, checked this morning and switched again to master > (In reply to comment #52) [...] > > COLLISION_IGNORE="/usr /lib/modules" > > in /etc/make.conf > > Now my laptop is happily compiling kdepimlibs. > > > > Please don't do that. That error was caused by you having 4.1.1 in SLOT 4 and > 4.1.2 being in slot 4.1 > The correct solution here is to remove the old ebuilds or update their slot. > I'm for this, but we used kde-testing for testing a few things before we were > finally able to reach a solution to our issues. > Heh, noticed that indeed they were in different slots so all made sense. While we are at it portages (or should i saw emerge's) support for slots seems really as an afterthought .. anyway,the usual "emerge -uDNv world" brought just part of the packages from 4.1.2 and left the others on 4.1.1 so i remained with an hybrid so had to unmerge kde*4* and now i started again from a clean situation. And this time setting kdeprefix too :) 7 ebuilds left to finish, let's see. Thanks for your suggestions anyway, i'll let you know the results.
I'm getting: * Digest verification failed: * /usr/portage/kde-base/kdebase-startkde/kdebase-startkde-4.1.2-r1.ebuild * Reason: Filesize does not match recorded size * Got: 4061 * Expected: 4064 Is anyone else seeing this, or is there something wrong with my mirror?
I was able to compile this without problems (In reply to comment #56) > I'm getting: > * Digest verification failed: > * /usr/portage/kde-base/kdebase-startkde/kdebase-startkde-4.1.2-r1.ebuild > * Reason: Filesize does not match recorded size > * Got: 4061 > * Expected: 4064 > > Is anyone else seeing this, or is there something wrong with my mirror? >
(In reply to comment #56) > I'm getting: > * Digest verification failed: > * /usr/portage/kde-base/kdebase-startkde/kdebase-startkde-4.1.2-r1.ebuild > * Reason: Filesize does not match recorded size > * Got: 4061 > * Expected: 4064 > > Is anyone else seeing this, or is there something wrong with my mirror? I had a similar error yesterday- also mismatching filesize - but not on startkde. (It was a package I hadn't installed). Could be a mirror problem indeed - try using another mirror :-)
Now that 4.1.2 has been put in the tree and unmasked, I'm closing this bug. Any issues related to 4.1.2 should be reported in a new bug. Any new bug related to kdeprefix should block bug 239356