Tim, All,
tdebase failed to build due to what looks like a cmake error during the install process. The error was:
-- Installing: /build/pkg/opt/trinity/share/apps/konqueror/icons/crystalsvg/16x16/actions/kde6.png -- Installing: /build/pkg/opt/trinity/include/konqsidebarplugin.h -- Installing: /build/pkg/opt/trinity/share/config/konqsidebartng.rc -- Installing: /build/pkg/opt/trinity/share/services/konq_sidebartng.desktop CMake Error at konqueror/sidebar/cmake_install.cmake:56 (FILE): file INSTALL cannot find "/build/src/tdebase/konqueror/sidebar/.version". Call Stack (most recent call first): konqueror/cmake_install.cmake:205 (INCLUDE) cmake_install.cmake:54 (INCLUDE)
make: *** [install] Error 1
GRRR - 1:55 down the tubes.... Help?
Tim, All,
tdebase failed to build due to what looks like a cmake error during the install process. The error was:
-- Installing: /build/pkg/opt/trinity/share/apps/konqueror/icons/crystalsvg/16x16/actions/kde6.png -- Installing: /build/pkg/opt/trinity/include/konqsidebarplugin.h -- Installing: /build/pkg/opt/trinity/share/config/konqsidebartng.rc -- Installing: /build/pkg/opt/trinity/share/services/konq_sidebartng.desktop CMake Error at konqueror/sidebar/cmake_install.cmake:56 (FILE): file INSTALL cannot find "/build/src/tdebase/konqueror/sidebar/.version". Call Stack (most recent call first): konqueror/cmake_install.cmake:205 (INCLUDE) cmake_install.cmake:54 (INCLUDE)
make: *** [install] Error 1
GRRR - 1:55 down the tubes.... Help?
-- David C. Rankin, J.D.,P.E.
That seems odd...can you post the full build log?
Also, you don't need to rebuild from scratch (unless you were using an automated chroot builder)...
Tim
On 03/04/2012 02:37 AM, Timothy Pearson wrote:
Tim, All,
tdebase failed to build due to what looks like a cmake error during the install process. The error was:
-- Installing: /build/pkg/opt/trinity/share/apps/konqueror/icons/crystalsvg/16x16/actions/kde6.png -- Installing: /build/pkg/opt/trinity/include/konqsidebarplugin.h -- Installing: /build/pkg/opt/trinity/share/config/konqsidebartng.rc -- Installing: /build/pkg/opt/trinity/share/services/konq_sidebartng.desktop CMake Error at konqueror/sidebar/cmake_install.cmake:56 (FILE): file INSTALL cannot find "/build/src/tdebase/konqueror/sidebar/.version". Call Stack (most recent call first): konqueror/cmake_install.cmake:205 (INCLUDE) cmake_install.cmake:54 (INCLUDE)
make: *** [install] Error 1
GRRR - 1:55 down the tubes.... Help?
-- David C. Rankin, J.D.,P.E.
That seems odd...can you post the full build log?
Also, you don't need to rebuild from scratch (unless you were using an automated chroot builder)...
Tim
Yep, seemed odd to me. I have posted both the build.log and package.log files for your here:
http://www.3111skyline.com/dl/dt/tde/err/tde-tdebase-build+package.log.tar.b...
It looks like there is a cmake file that is telling cmake to pull in a .version file that doesn't exist. Who knows - gremlins :)
Let me know if you need me to post anything else to help. And, yes, I'm building in a union filesystem chroot environment so, unfortunately, I'll have to do it all over again :)
On 03/04/2012 02:55 AM, David C. Rankin wrote:
That seems odd...can you post the full build log?
Also, you don't need to rebuild from scratch (unless you were using an automated chroot builder)...
Tim
Yep, seemed odd to me. I have posted both the build.log and package.log files for your here:
http://www.3111skyline.com/dl/dt/tde/err/tde-tdebase-build+package.log.tar.b...
It looks like there is a cmake file that is telling cmake to pull in a .version file that doesn't exist. Who knows - gremlins :)
Let me know if you need me to post anything else to help. And, yes, I'm building in a union filesystem chroot environment so, unfortunately, I'll have to do it all over again :)
Tim,
I included the rest of the Cache files and CMakeFiles for the build failure too. They are here:
http://www.3111skyline.com/dl/dt/tde/err/build/CMakeFiles/
http://www.3111skyline.com/dl/dt/tde/err/build/CMakeCache.txt
http://www.3111skyline.com/dl/dt/tde/err/build/cmake_install.cmake
Let me know if I've missed something. Thanks!
On 03/04/2012 03:00 AM, David C. Rankin wrote:
On 03/04/2012 02:55 AM, David C. Rankin wrote:
That seems odd...can you post the full build log?
Also, you don't need to rebuild from scratch (unless you were using an automated chroot builder)...
Tim
Yep, seemed odd to me. I have posted both the build.log and package.log files for your here:
http://www.3111skyline.com/dl/dt/tde/err/tde-tdebase-build+package.log.tar.b...
It looks like there is a cmake file that is telling cmake to pull in a .version file that doesn't exist. Who knows - gremlins :)
Let me know if you need me to post anything else to help. And, yes, I'm building in a union filesystem chroot environment so, unfortunately, I'll have to do it all over again :)
Tim,
I included the rest of the Cache files and CMakeFiles for the build failure too. They are here:
http://www.3111skyline.com/dl/dt/tde/err/build/CMakeFiles/
http://www.3111skyline.com/dl/dt/tde/err/build/CMakeCache.txt
http://www.3111skyline.com/dl/dt/tde/err/build/cmake_install.cmake
Let me know if I've missed something. Thanks!
AARGH! Nevermide, I figured it out. The tarball I created stripped . files to avoid .git directories, it stripped .version as well -- duh....
On 03/04/2012 03:00 AM, David C. Rankin wrote:
On 03/04/2012 02:55 AM, David C. Rankin wrote:
That seems odd...can you post the full build log?
Also, you don't need to rebuild from scratch (unless you were using an automated chroot builder)...
Tim
Yep, seemed odd to me. I have posted both the build.log and package.log files for your here:
http://www.3111skyline.com/dl/dt/tde/err/tde-tdebase-build+package.log.tar.b...
It looks like there is a cmake file that is telling cmake to pull in a .version file that doesn't exist. Who knows - gremlins :)
Let me know if you need me to post anything else to help. And, yes, I'm building in a union filesystem chroot environment so, unfortunately, I'll have to do it all over again :)
Tim,
I included the rest of the Cache files and CMakeFiles for the build failure too. They are here:
http://www.3111skyline.com/dl/dt/tde/err/build/CMakeFiles/
http://www.3111skyline.com/dl/dt/tde/err/build/CMakeCache.txt
http://www.3111skyline.com/dl/dt/tde/err/build/cmake_install.cmake
Let me know if I've missed something. Thanks!
AARGH! Nevermide, I figured it out. The tarball I created stripped . files to avoid .git directories, it stripped .version as well -- duh....
-- David C. Rankin, J.D.,P.E.
That would definitely explain it. I have found CMake to be very, very reliable compared to Autotools (though this may just be due to the quality of the work that Serghei did :-)), and usually problems that show up in the CMake builds are due to code problems or operator error. ;-)
Tim
On 03/04/2012 02:14 PM, Timothy Pearson wrote:
That would definitely explain it. I have found CMake to be very, very reliable compared to Autotools (though this may just be due to the quality of the work that Serghei did :-)), and usually problems that show up in the CMake builds are due to code problems or operator error. ;-)
Tim
I have been absolutely amazed at how brilliantly TDE is building. After going through the pain of transferring all the build scripts to use TQt3 and picking through all the patches.tar.bz2 files to eliminate unneeded patches, TDE is building great. I can't wait to actually load it on a box and try it :)
The challenge will be finishing the cmake conversion for the applications and other packages so that all apps, addons, plugins, styles, decorations, etc.. are building as well. It will just take time, but it is coming along.
It would be great to get to a point where the major transitions (eg: from Qt to TQt, etc..) is done and troubleshot -- to spend 30 days under a code-freeze and just work on getting all the applications, addons, etc.. building. Those little 'niceties' are what has always make kde3 stand out as a desktop. It will do the same for TDE as well.
On 03/04/2012 02:14 PM, Timothy Pearson wrote:
That would definitely explain it. I have found CMake to be very, very reliable compared to Autotools (though this may just be due to the quality of the work that Serghei did :-)), and usually problems that show up in the CMake builds are due to code problems or operator error. ;-)
Tim
I have been absolutely amazed at how brilliantly TDE is building. After going through the pain of transferring all the build scripts to use TQt3 and picking through all the patches.tar.bz2 files to eliminate unneeded patches, TDE is building great. I can't wait to actually load it on a box and try it :)
The challenge will be finishing the cmake conversion for the applications and other packages so that all apps, addons, plugins, styles, decorations, etc.. are building as well. It will just take time, but it is coming along.
It would be great to get to a point where the major transitions (eg: from Qt to TQt, etc..) is done and troubleshot -- to spend 30 days under a code-freeze and just work on getting all the applications, addons, etc.. building. Those little 'niceties' are what has always make kde3 stand out as a desktop. It will do the same for TDE as well.
This is part of the plan already. :-) I envision at least part of that to be a soft freeze, where any bugs found during the freeze can be patched, but nothing else can be touched.
Also, I hope that once everything is building again on TQt3 (which should be very quickly) , the other developers here will start looking at the bugtracker again and send in more patches. ;-)
Tim
This is part of the plan already. :-) I envision at least part of that to be a soft freeze, where any bugs found during the freeze can be patched, but nothing else can be touched.
I like that idea. With the envisioned R14 release date still a couple of months down the road, a short soft freeze now will allow us all to stabilize and verify all packages build against TQt3. In other words, everybody stops tweaking and tinkering for a few days and only verify the building process. :)
Right now seems that every other day or so one package or another will not fully build without an error. When we get through the temporary freeze, we can focus on the bugzilla but all have comfort knowing that tqt build issues have been addressed.
Also, I hope that once everything is building again on TQt3 (which should be very quickly), the other developers here will start looking at the bugtracker again and send in more patches. ;-)
Please send the word when your first pass is complete. I am supposed to push some minor patches but have been waiting to update my local tree to run one more build pass. I did not want to waste time trying to build with known build issues. :)
Actually, until last week I was building all core, main (including tdebindings), and a dozen Applications packages with only a few build issues (bug reports filed). My big obstacle has been building the tdebindings support packages.
I propose a team goal that R14 is not released with any unresolved Blocker, Critical, or Major bug reports. Possibly even add 40 to 50% of the Normal reports too. Is this doable? Agreeable?
Darrell
On 03/04/2012 03:01 PM, Darrell Anderson wrote:
This is part of the plan already. :-) I envision at least part of that to be a soft freeze, where any bugs found during the freeze can be patched, but nothing else can be touched.
I like that idea. With the envisioned R14 release date still a couple of months down the road, a short soft freeze now will allow us all to stabilize and verify all packages build against TQt3. In other words, everybody stops tweaking and tinkering for a few days and only verify the building process. :)
Right now seems that every other day or so one package or another will not fully build without an error. When we get through the temporary freeze, we can focus on the bugzilla but all have comfort knowing that tqt build issues have been addressed.
As of right-now, I have Arch building without error on TQt3 through tdebase, including the following:
15:07 nirvana:~/tde> ls -1 pkg/x86_64/ hal-0.5.14-8-x86_64.pkg.tar.xz hal-info-0.20091130-1-any.pkg.tar.xz libutempter-1.1.5-3-x86_64.pkg.tar.xz tde-arts-3513_tqt-1-x86_64.pkg.tar.xz tde-dbus-tqt-1-3513_tqt-1-x86_64.pkg.tar.xz tde-dbus-tqt-3513_tqt-1-x86_64.pkg.tar.xz tde-libart-lgpl-3513_tqt-1-x86_64.pkg.tar.xz tde-libcaldav-0.6.2_tqt-1-x86_64.pkg.tar.xz tde-libcarddav-0.6.2_tqt-1-x86_64.pkg.tar.xz tde-tdebase-3513_tqt-1-x86_64.pkg.tar.xz (built with upower enabled) tde-tdelibs-3513_tqt-1-x86_64.pkg.tar.xz tde-tqca-tls-3513_tqt-1-x86_64.pkg.tar.xz tde-tqt3-3.8.8.d_git-1-x86_64.pkg.tar.xz tde-tqtinterface-3513_tqt-8-x86_64.pkg.tar.xz tde-tqtinterface-3513_tqt-9-x86_64.pkg.tar.xz
The only package in the tdebase dependency line that won't build is avahi-tqt. Then I'll look at the packages that I had building on svn a year ago:
trinity-app-amarok trinity-app-d3lphin trinity-app-gtk-qt-engine trinity-app-knetworkmanager trinity-app-style-qtcurve trinity-kdegraphics trinity-kdepim trinity-kdevelop trinity-kdewebdev
Also, I hope that once everything is building again on TQt3 (which should be very quickly), the other developers here will start looking at the bugtracker again and send in more patches. ;-)
Please send the word when your first pass is complete. I am supposed to push some minor patches but have been waiting to update my local tree to run one more build pass. I did not want to waste time trying to build with known build issues. :)
Actually, until last week I was building all core, main (including tdebindings), and a dozen Applications packages with only a few build issues (bug reports filed). My big obstacle has been building the tdebindings support packages.
I propose a team goal that R14 is not released with any unresolved Blocker, Critical, or Major bug reports. Possibly even add 40 to 50% of the Normal reports too. Is this doable? Agreeable?
Darrell
+1 - we will sell no wine until it's time....
There is a huge unrecognized benefit in taking a few extra weeks to clean everything up before a release compared to the time/manpower required after release to correct bugs easily squashed before release. R14 should be as clean as we can make it :)
I propose a team goal that R14 is not released with any
unresolved Blocker, Critical, or Major bug reports. Possibly even add 40 to 50% of the Normal reports too. Is this doable? Agreeable?
+1 - we will sell no wine until it's time....
There is a huge unrecognized benefit in taking a few extra weeks to clean everything up before a release compared to the time/manpower required after release to correct bugs easily squashed before release. R14 should be as clean as we can make it :)
Curious, I ran some queries in the bugzilla. Here are the number of unresolved open bug reports in the aforementioned categories:
Blocker: 22 (11 with patches) Critical: 24 (2 with patches) Major: 67 (4 with patches) Normal: 144 (9 with patches)
Total of the above: 257
Total bug reports related to building/compiling: 36
Total open unresolved bug reports, all levels, not tagged as wishes or enhancement reports: 346
How many of these bug reports remain current and valid remains to be seen.
Enhancement/wish list requests: 116
Proposed R14 release date per wiki: Spring 2012. June 19 is the last day of spring, which means 104 days. To resolve all Blocker, Critical, Major and 50% of Normal bug reports means 185 bug reports resolved. That means 1.8 bug reports per day. To resolve all Normal bugs in the same period means 2.5 bug reports per day. To resolve all unclosed bug reports means 3.3 bug reports per day. Assuming no new bug reports being filed.
Darrell
I propose a team goal that R14 is not released with any
unresolved Blocker, Critical, or Major bug reports. Possibly even add 40 to 50% of the Normal reports too. Is this doable? Agreeable?
+1 - we will sell no wine until it's time....
There is a huge unrecognized benefit in taking a few extra weeks to clean everything up before a release compared to the time/manpower required after release to correct bugs easily squashed before release. R14 should be as clean as we can make it :)
Curious, I ran some queries in the bugzilla. Here are the number of unresolved open bug reports in the aforementioned categories:
Blocker: 22 (11 with patches) Critical: 24 (2 with patches) Major: 67 (4 with patches) Normal: 144 (9 with patches)
Total of the above: 257
Total bug reports related to building/compiling: 36
Total open unresolved bug reports, all levels, not tagged as wishes or enhancement reports: 346
How many of these bug reports remain current and valid remains to be seen.
Enhancement/wish list requests: 116
Proposed R14 release date per wiki: Spring 2012. June 19 is the last day of spring, which means 104 days. To resolve all Blocker, Critical, Major and 50% of Normal bug reports means 185 bug reports resolved. That means 1.8 bug reports per day. To resolve all Normal bugs in the same period means 2.5 bug reports per day. To resolve all unclosed bug reports means 3.3 bug reports per day. Assuming no new bug reports being filed.
Darrell
Yep, not doable by any means. Blocker reports will be fixed for R14.0, not sure about the rest...
Tim
Yep, not doable by any means. Blocker reports will be fixed for R14.0, not sure about the rest...
Unless others come forward and help. We don't need miracles, just a few people. :)
And not even long term. Just a short period where we hack in a serious manner. To those who are interested, I'm almost always available to help troubleshoot and test patches. :)
Darrell
On 03/04/2012 06:22 PM, Darrell Anderson wrote:
Unless others come forward and help. We don't need miracles, just a few people. :)
And not even long term. Just a short period where we hack in a serious manner. To those who are interested, I'm almost always available to help troubleshoot and test patches. :)
Darrell
I'm in -- I'm not a whiz kid at debugging, but I'm willing to take a look and see if I can help. I guess that means just looking through the bug reports to see what falls in the category of "might be able to help fix it"?
I'm open to your suggestions of which ones to start looking at...
On Monday 05 of March 2012 01:37:24 David C. Rankin wrote:
I'm in -- I'm not a whiz kid at debugging, but I'm willing to take a look and see if I can help. I guess that means just looking through the bug reports to see what falls in the category of "might be able to help fix it"?
I'm open to your suggestions of which ones to start looking at...
It would certainly help pass the list of reported bugs and verify that they are still valid. In doing so, it would probably also could conclude the issues that are specific to the version already unsupported distributions.
Detection of duplicate reports could also help in reducing the number of open bugs.
Slávek --
On 03/04/2012 05:49 PM, Timothy Pearson wrote:
Yep, not doable by any means. Blocker reports will be fixed for R14.0, not sure about the rest...
Tim
I'll have to look at tracker a bit more to see if it is already there, but what would really be helpful is a list of which bugs are considered priority:
Blockers - obviously
(Other Categories - many times reporters just guess)
So if we had a "Top 10 list of non-blockers to fix" - it would at least give the clueless some direction.
I'll have to look at tracker a bit more to see if it is already there, but what would really be helpful is a list of which bugs are considered priority:
Blockers - obviously
(Other Categories - many times reporters just guess)
So if we had a "Top 10 list of non-blockers to fix" - it would at least give the clueless some direction.
Here is a query of all open unresolved bug reports:
http://bugs.pearsoncomputing.net/bugzilla/buglist.cgi?query_format=advanced&...
After running the query, sort by selecting a column heading link.
A top ten list is going to be subjective. :) Ignoring anything build related, which I presume will get fixed before R14, here is my own list of usability issues:
*** Any bug report about bad sym links 392 Desktop Device Icon Placement 385 Unmounted removable device icons do not appear on the desktop 372 Storage media applet doesn't show usb stick at session startup 692 Kate: focus is broken when using the --use parameter 756 Konqueror: Does not update file pane with file changes 301 Kompare does not maintain a correct mru list 259 Kompare does not always terminate properly, leaving the process running 293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 640 .kthemestylerc.lock is created in $TDEDIR/share/config 560 Akregator no longer displays icons next to feed titles 251 Kicker/panel has no configuration option to stop scrolling among apps 688 TDE won't start the first time with Nvidia proprietary drivers installed 650 Kompare: add a method to merge/transfer only one line within a chunk 230 Amarok Keyboard Shortcuts Do Not Work Correctly 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware 247 KPersonalizer: Add support for left-handed mouse users 386 Show Desktop behavior 614 Provide a professional message box for the TDE Write Daemon
Darrell
On 03/04/2012 07:15 PM, Darrell Anderson wrote:
Here is a query of all open unresolved bug reports:
http://bugs.pearsoncomputing.net/bugzilla/buglist.cgi?query_format=advanced&...
After running the query, sort by selecting a column heading link.
A top ten list is going to be subjective. :) Ignoring anything build related, which I presume will get fixed before R14, here is my own list of usability issues:
*** Any bug report about bad sym links 392 Desktop Device Icon Placement 385 Unmounted removable device icons do not appear on the desktop 372 Storage media applet doesn't show usb stick at session startup 692 Kate: focus is broken when using the --use parameter 756 Konqueror: Does not update file pane with file changes 301 Kompare does not maintain a correct mru list 259 Kompare does not always terminate properly, leaving the process running 293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 640 .kthemestylerc.lock is created in $TDEDIR/share/config 560 Akregator no longer displays icons next to feed titles 251 Kicker/panel has no configuration option to stop scrolling among apps 688 TDE won't start the first time with Nvidia proprietary drivers installed 650 Kompare: add a method to merge/transfer only one line within a chunk 230 Amarok Keyboard Shortcuts Do Not Work Correctly 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware 247 KPersonalizer: Add support for left-handed mouse users 386 Show Desktop behavior 614 Provide a professional message box for the TDE Write Daemon
Darrell
that's what we needed -- thanks Darrell!
On Monday 05 of March 2012 00:38:44 Darrell Anderson wrote:
Proposed R14 release date per wiki: Spring 2012. June 19 is the last day of spring, which means 104 days. To resolve all Blocker, Critical, Major and 50% of Normal bug reports means 185 bug reports resolved. That means 1.8 bug reports per day. To resolve all Normal bugs in the same period means 2.5 bug reports per day. To resolve all unclosed bug reports means 3.3 bug reports per day. Assuming no new bug reports being filed.
Darrell
I also try to contribute - three errors on KTorrent I merged into one and I have already upload the patch. Now only waiting to commit to git... :)
Slávek --
I also try to contribute - three errors on KTorrent I merged into one and I have already upload the patch. Now only waiting to commit to git... :)
And thank you! I'm learning C++ yet I get so frustrated with my lack of C++ skills. :)
If we had a couple of additional C++ hackers we could reduce the bug list considerably. If we could get a person or two with make and configure experience, many of those related bug reports would disappear too.
Darrell
-
Darrell Anderson -
David C. Rankin -
Slávek Banko -
Timothy Pearson