All,
Many of the TDE services will be going offline for scheduled maintenance
20:00 08/31/2013. A full list of affected services is:
* QuickBuild
* Web Services
* Bug Tracker
* GIT System
* IRC Bot
* Etherpad
* Patchwork
* LiveCD Builder
* Automated Builds
The mailing lists will remain active, and I will send another announcement
when services have been restored.
Thank you for your patience during this process!
Tim
>I hate to be a pest, but what is the status of this project?
>
>Thanks!
I've been running build sets every day for a few days. No build
failures or easily noticeable usability issues. Slavek gets the
final say but I believe he wants to incorporate a handful of minor
tweaks we discovered yesterday. Likely we are ready to start
pushing patches Real Soon Now. :-)
Darrell
Tim, Slavek,
Perhaps the convert kde3->tde script could be updated to include
renaming *.kdevelop files to *.tdevelop?
That would include updating po(t), Doxyfile, doxygen files, etc.,
such as KDevelop->TDevelop; although we should be careful not to
modify "About" strings that credit the original KDevelop team
members.
Darrell
tquic crashes during build of tdebase/tdeioslaves. I'm not sure if it's a
bug or something wrong about my system...
Any ideas?
Build log in the attachment.
Hi there,
today I run into a FTBFS when building libraries/pytdeextensions on debian/testing (jessie).
The package actually compiles, but the building process actually fails after that when invoking "dh_python".
dh_python -ppytdeextensions-trinity
make: dh_python: Command not found
I tracked down the problem to be in the file "debian/python-distutils-jaunty.mk", where "dh_python2" needs to
be invoked instead of "dh_python" and prepared a patch for it.
While looking at the problem I also spotted that the patch "11_fix_get_libdir_name.diff" was out-of-sync with
the code by 63 lines, so I updated the patch to point to the correct line.
With both patches, the package builds correctly.
I don't know if you are having the same problem I had. The nightly built package is not ready at the time
of writing (it is schedule for building in a few hours), so I can't compare.
I don't know whether the patch for "dh_python" breaks the building for debian/wheezy, since last year I didn't have any
problem compiling in such environment. If so, a separate entry needs to be created in the tde-packaging for
debian/jessie (instead of pointing to wheezy) and the patch added to the "libraries/pytdeextensions" files.
Cheers
Michele
>Not for R14.0.0, but we can look into it for R14.1.0. We will
>need some
>degree of upstream cooperation in various projects so as not to
>break
>things like automatic tdesudo prompts for administrative programs.
In hindsight, there might not be many changes. I grepped the
sources and there are not many || tests. As you just mentioned,
Slavek also previously explained to me that some of the || tests
are necessary to support non-TDE su/sudo apps.
Darrell
While reviewing the upcoming patch set for LIB_K* -> LIB_TDE* I
noticed some things.
There are a handful of spots in the sources where readEntry looks
for X-TDE-* || X-KDE-*. We can't blindly change all such
occurrences because many are legitimate, such as the tdebase/applnk
files that support KDE4 menus and some occasional spots where code
is supporting both TDE and KDE4 (such as su). Yet I think in many
of those || tests we can eliminate the test for readEntry X-KDE-*.
I don't see this as an urgent issue and I'll open a bug report if
asked. We can resolve those || tests in R14.0.1 or R14.1.0.
Comments? Thoughts?
Darrell
>> When do you think this update will be completed?
>
>I'm working hard on it. Because by using
>convert_existing_kde3_app_to_tde were
>found some hidden and omissed mistakes, patches are larger =>
>require more
>effort to verify. Completed it should be on a Sunday evening.
I'm helping Slavek review the patch set. Hopefully later today we
both start full build sets to check for both compiling and
usability issues. A full build set at my end takes about 9.5 hours.
Darrell
>I'll do it.
>
>Because the change must be reflected also in
>convert_existing_kde3_app_to_tde,
>I can use this script to update all modules.
>
>The change relates to:
>+ LIB_KDNSSD
>+ LIB_KIMPROXY
>+ LIB_KIO
>+ LIB_KPARTS
>+ LIB_KSPELL
>+ LIB_KSYCOCA
>+ LIB_KUNITTEST
>+ LIB_KUTILS
>
>If I missed some, please let me know.
Looks like common/admin/acinclude.m4.in might help, starting at
line 2315:
AC_SUBST(LIB_KDED, $lib_kded)
AC_SUBST(LIB_TDECORE, "-ltdecore")
AC_SUBST(LIB_TDEUI, "-ltdeui")
AC_SUBST(LIB_KIO, "-ltdeio")
AC_SUBST(LIB_KJS, "-lkjs")
AC_SUBST(LIB_SMB, "-lsmb")
AC_SUBST(LIB_KAB, "-lkab")
AC_SUBST(LIB_TDEABC, "-ltdeabc")
AC_SUBST(LIB_TDEHTML, "-ltdehtml")
AC_SUBST(LIB_KSPELL, "-ltdespell")
AC_SUBST(LIB_KPARTS, "-ltdeparts")
AC_SUBST(LIB_TDEPRINT, "-ltdeprint")
AC_SUBST(LIB_KUTILS, "-ltdeutils")
AC_SUBST(LIB_TDEPIM, "-ltdepim")
AC_SUBST(LIB_KIMPROXY, "-ltdeimproxy")
AC_SUBST(LIB_KNEWSTUFF, "-lknewstuff")
AC_SUBST(LIB_KDNSSD, "-ltdednssd")
AC_SUBST(LIB_KUNITTEST, "-ltdeunittest")
# these are for backward compatibility
AC_SUBST(LIB_KSYCOCA, "-ltdeio")
AC_SUBST(LIB_TDEFILE, "-ltdeio")
From that list we can find the following:
LIB_KIO
LIB_KSPELL
LIB_KPARTS
LIB_KUTILS
LIB_KIMPROXY
LIB_KDNSSD
LIB_KUNITTEST
LIB_KSYCOCA
That list matches your list.
Do you need help with the patching?
Darrell
