Re: DrKonqi backtrace generation broken with gdb 7.8
Am Freitag, 10. Oktober 2014, 19:20:21 schrieb Albert Astals Cid: > > > -Exec=gdb -nw -n -batch -x %tempfile -p %pid %execpath > > > +Exec=gdb -nw -n -batch -ex "mt set target-async off" -ex "attach > > > %pid" -x %tempfile %execpath > > > > > > BatchCommands=set width 200\nthread\nthread apply all bt > > > > Upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17446 > > Upstream commit (probably): > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ec5670becb3f9 > > 78f 4d2f4df252ad0cbf805e37a > > > > One could also attempt to backport that. > > I'd say that makes more sense than us changing our code because someone > else introduced a regression. > > Opinions? > A change/backport/patch/update in a core system package is always harder to push through on distro level than a corresponding change in a desktop environment application. Please don't rely on the gdb backport. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [kde-promo] The name of Applications 4.14 + 1 - how about splitting into 4-part and 5-part
Am Sonntag, 20. Juli 2014, 20:52:26 schrieb Albert Astals Cid: > > No, the confusion comes because that name is too large and confusing. If i > way "KDE Releases Applications 14.12" there's no confusion, basically it > means that "KDE" has released some applications that have a global name of > 4.12. > Hehe... read it again, notice something? :) > We have had "single application version number" being different from > "bundled applications global version number" for a long time, i'm > surprised why this is suddenly a problem we need to discuss about. Because no user ever cared. The distribution package? was called kmail-4.12.3 (or maybe kmail2-4.12.3) The version number in bugzilla? 4.12.3 ... Someone ask you "which kmail version do you use" and you reply (imprecisely) kmail2, or "4.12.3", or "the one from 4.12.3". -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [kde-promo] The name of Applications 4.14 + 1 - how about splitting into 4-part and 5-part
> > Care to elaborate on why would it create less confusion? > > "KDE Releases Some Applications 4.17 and Some Applications 5.2" looks like > a pretty confusing news headline to me :D > Well that's a level of confusion that we've already caused. So people are *maybe* already used to it. (The full version would be something like "KDE releases bugfix release Workspace 4.11.17, something else 4.14.4, and Applications 4.17.1, combined with the brand-new Applications 5.0.1 ported to the sexy new KDE Frameworx.") (No I dont really believe in "no more release will happen" statements. :) -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [kde-promo] The name of Applications 4.14 + 1 - how about splitting into 4-part and 5-part
> > > * My suggestion is call it "KDE Applications $YEAR.$MONTH", i.e. if we > > > keep [...] > okular-14.12.0.tar.xz contains Okular 0.21.0 > kate-14.12.0.tar.xz contains Kate 3.15.0 > konsole-14.12.0.tar.xz contains Konsole 2.15.0 > kdepim-14.12.0.tar.xz contains KMail 5.0.0 Alternative suggestion... please consider splitting the release into a 4 and a 5 part (which are released together)! This would have the big advantage that each tarball / resulting RPM / ... immediately indicates what "stage" of KDE it belongs to. It would create much less confusion than the introduction of a new additional numbering scheme. (Yes I realize it may involve work.) -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
> El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K. Huettel va > escriure: > > Practically this just means that what used to be the stable branch now > > becomes the distribution patch collection. > > No, it means that you use the next release as you would do now since it will > have the bug you found fixed, or do you guys have a distribution patch > collection for firefox? > Bad example, our stable users are running Firefox Extended Support Release. (There still is a patch collection, which afaics however mostly targets arch compatibility (alpha, freebsd), library unbundling and build system fixes.) -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
Am Sonntag 27 April 2014, 15:15:32 schrieb David Faure: > > We ended up settling on the "one month cycle, no branch" option because we > think it should address the constraints above. In a more detailed way here > is what we mean by "one month cycle, no branch": > * Everything is developed in master, so each release will contain a few new > features and bugfixes; Practically this just means that what used to be the stable branch now becomes the distribution patch collection. (how about having some branch namespace on the kde git repositories for distro packaging teams? :) -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.13 tars are available
Am Donnerstag, 10. April 2014, 12:00:58 schrieb Jonathan Riddell: > Albert has kindly tarred up candidate tars for KDE SC 4.13, available now > to packagers on depot.kde.org. > > Jonathan Marble python bindings don't build. In file included from /var/tmp/portage/kde- base/marble-4.13.0/work/marble-4.13.0_build/src/bindings/python/sip/sipmarblepart3.cpp:7:0: /var/tmp/portage/kde- base/marble-4.13.0/work/marble-4.13.0/src/bindings/python/sip/AbstractDataPluginItem.sip:51:33: fatal error: MarbleRunnerMana ger.h: No such file or directory #include ^ compilation terminated. make[2]: *** [src/bindings/python/CMakeFiles/python_module_PyKDE4_marble.dir/sip/sipmarblepart3.o] Error 1 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: baoo_file_extractor crashes
Am Sonntag, 6. April 2014, 19:12:48 schrieb Albert Astals Cid: > > > > Here's another biggish problem: > > https://bugs.launchpad.net/ubuntu/+source/baloo/+bug/1301742 > > baloo_file_extractor crashed with SIGSEGV in size() > > That's not pim related, let's drop kdepim mailing list from further emails > in this sub-thread. > > > The bug report is on Ubuntu, but using Gentoo I have about 4000 > > baloo_file_extractor corefiles too, checking two at random displayed the > > same backtrace. > > Can you check if we have any bug on bugs.kde.org about it? > There were two existing crash reports on b.k.o, but the backtraces did not match. I've filed bug 333133. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: PIM is not good. Would adding an extra RC help?
Am Samstag, 5. April 2014, 16:40:24 schrieb Albert Astals Cid: > ** Please CC me and r-t list, i'm not subscribed to pim list. ** > > Hello guys, as I hope you all know this Wednesday we are supposed to tag > the final release for 4.13. > > I am sending this email to ask for opinions on the value of adding an extra > RC and delaying the 4.13.0 release for at least a week. > > I'm going to explain why I'd like this to happen. > > Since the update to 4.13 Beta I've been having lots of CPU and I/O problems > in pim related stuff, most notably akonadi_baloo_indexer, > akonadi_maildir_resource & friends. > Here's another biggish problem: https://bugs.launchpad.net/ubuntu/+source/baloo/+bug/1301742 baloo_file_extractor crashed with SIGSEGV in size() The bug report is on Ubuntu, but using Gentoo I have about 4000 baloo_file_extractor corefiles too, checking two at random displayed the same backtrace. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Review Request 115519: Do not use KDE_VERSION_STRING for workspace applications
Excellent thanks! Am Freitag 07 Februar 2014, 11:33:54 schrieb Martin Gräßlin: > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115519/ > --- > > (Updated Feb. 7, 2014, 11:33 a.m.) > > > Status > -- > > This change has been marked as submitted. > > > Review request for kde-workspace and Release Team. > > > Repository: kde-workspace > > > Description > --- > > Workspace is no longer synced with kdelibs releases. Thus if compiled > against e.g. 4.12 we want our workspace apps to still be 4.11. > > > Diffs > - > > kwin/clients/oxygen/demo/main.cpp 83d9d83 > kwrited/kwrited.cpp cab2d6b > plasma/desktop/shell/main.cpp ea3d43d > startkde.cmake 30d5ab5 > statusnotifierwatcher/statusnotifierwatcher.cpp 97ae164 > systemsettings/app/main.cpp 78109e0 > kstyles/oxygen/config/main.cpp 5a5286e > kstyles/oxygen/demo/main.cpp 005395b > ksysguard/gui/ksysguard.cpp 2ad34f2 > config-workspace.h.cmake b3ba37d > khotkeys/kcm_hotkeys/kcm_hotkeys.cpp 389a361 > kinfocenter/main.cpp c28f7cf > krunner/main.cpp 6eac316 > kscreensaver/kblank_screensaver/blankscrn.cpp 99ef649 > kscreensaver/krandom_screensaver/random.cpp 4047184 > > Diff: https://git.reviewboard.kde.org/r/115519/diff/ > > > Testing > --- > > compiled with 4.12.60 kdelibs and looked at e.g. startkde and systemsettings > which have now 4.11.6. > > > Thanks, > > Martin Gräßlin -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail andreas.huet...@ur.de http://www.akhuettel.de/ http://www.physik.uni-r.de/forschung/huettel/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Automatic creation of version information on bugs.kde.org
Am Mittwoch, 5. Februar 2014, 12:59:12 schrieb Andreas K. Huettel: > > Open systemsettings, go into menu, "About systemsetting". The dialog window > displays "Version 4.12.0, under KDE 4.12.1" (seems like I havent finished > some update, me bad). > err, suspicion, could the displayed systemsettings version number be the version of kdelibs that the app was built against? (since nothing in 4.11.5 depends on 4.12.1 over 4.12.0, it's possible that the upgrade systemsettings-4.11.4 -> 5 ran before the upgrade kdelibs-4.12.0 -> 1 here. just an idea...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Automatic creation of version information on bugs.kde.org
> I noticed that somehow the versions in bugzilla get updated once we had an > SC release. I don't know who does it, but I assume that someone on the > list knows who does it :-) > > So a small request: please exclude the kde-workspace products for the > 4.12.x releases. Even better: change it to generate a 4.11.x version ;-) Open systemsettings, go into menu, "About systemsetting". The dialog window displays "Version 4.12.0, under KDE 4.12.1" (seems like I havent finished some update, me bad). ... now I (since I know better) check with the package manager and see kde- base/systemsettings-4.11.5 ... Running kinfocenter, go into menu "About kinfocenter", the dialog window displays "Version 4.12.0, under KDE 4.12.1" ... now I (since I know better) check with the package manager and see, ah well, you know what I mean. Please, dont. It'll generate even more confusion with users. In this case IMHO the additional work burden is on your side. if you want to fiddle around with the versioning system, you'll have to bear with the bug reports and the information you provided in your applications. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.12.1 tarballs
Am Freitag, 10. Januar 2014, 01:31:09 schrieb Albert Astals Cid: > Hi, > > The tarballs for the 4.12.1 release are now available in the usual > location. > Builds fine here too (Gentoo). (didn't test kdepim-4.12 yet on this box, but kdepim-4.4 builds fine against it too, with minor adjustments... :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.11.3 tarballs
Am Sonntag, 3. November 2013, 16:39:17 schrieb Albert Astals Cid: > > > > There is something seriously weird going on in the log. If other people > > can build pykde4 fine, it may be a Gentoo specific problem. > > [Python-related stuff is really transparent only to the Gentoo Python > > team, I'll ask them. Bunch of wizards. :|] > > Does this help? > > Cheers, > Albert Sorry for the noise. This was a purely home-made Gentoo pykde4 problem. Ignore it; we fixed it. (Without detailed background there is absolutely no obvious connection between error message and what went wrong. I still don't understand what exactly happend, but it's an unpredicted interaction between python and cmake build scripts.) -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.11.3 tarballs
Albert Astals Cid wrote: >El Diumenge, 3 de novembre de 2013, a les 14:16:13, Andreas K. Huettel >va >escriure: >> Am Sonntag, 3. November 2013, 13:27:51 schrieb Albert Astals Cid: >> > > >base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonplugin >> > > f >> > > act ory.cpp:28: /usr/include/python3.2/object.h:402:23: error: >expected >> > > unqualified-id before ‘;’ token >> > >> > This is not useful, tell us what command is giving this error. >> >> Here's a longer snippet from a -j1 verbose build log. Full log here: >> http://dev.gentoo.org/~dilfridge/pykde4-4.11.3-build.log.bz2 >> >> There is something seriously weird going on in the log. If other >people can >> build pykde4 fine, it may be a Gentoo specific problem. >[Python-related >> stuff is really transparent only to the Gentoo Python team, I'll ask >them. >> Bunch of wizards. :|] > >Does this help? > >Cheers, > Albert Same error now in G with 4.11.2, fault is ours. Do Not delay & please forward this Mail - A -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.11.3 tarballs
e/qnamespace.h:45, from /usr/include/qt4/QtCore/qobjectdefs.h:45, from /usr/include/qt4/QtCore/qobject.h:47, from /usr/include/qt4/QtCore/qcoreapplication.h:45, from /usr/include/qt4/QtCore/QCoreApplication:1, from /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:21: /usr/include/features.h:166:0: note: this is the location of the previous definition In file included from /usr/include/python3.2/Python.h:67:0, from /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:28: /usr/include/python3.2/object.h:402:23: error: expected unqualified-id before ‘;’ token /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:121:10: warning: unused parameter ‘args’ [-Wunused-parameter] /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp: In function ‘int kdemain(int, char**)’: /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:356:30: error: cannot convert ‘char*’ to ‘wchar_t*’ for argument ‘1’ to ‘void Py_SetProgramName(wchar_t*)’ /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:360:26: error: cannot convert ‘char**’ to ‘wchar_t**’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t**)’ /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:391:40: error: ‘PyString_FromString’ was not declared in this scope /var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:354:15: warning: unused variable ‘pyLib’ [-Wunused-variable] make[2]: *** [kpythonpluginfactory/CMakeFiles/kpython2.7pluginfactory.dir/kpythonpluginfactory.cpp.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3_build-' make[1]: *** [kpythonpluginfactory/CMakeFiles/kpython2.7pluginfactory.dir/all] Error 2 make[1]: Leaving directory `/var/tmp/portage/kde- base/pykde4-4.11.3/work/pykde4-4.11.3_build-' make: *** [all] Error 2 * ERROR: kde-base/pykde4-4.11.3::kde failed (compile phase): * emake failed * -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.11.3 tarballs
Am Freitag, 1. November 2013, 19:53:58 schrieb Torgny Nyblom:
> Hi,
>
> The tarballs for the 4.11.3 release are now available in the usual
> location.
>
> I've not compiled them so please report any issues you find.
>
> sha1 sums and revisions/hashes are attached.
>
> /Regards
> Torgny
PyKDE4 fails with the following error:
In file included from /usr/include/python3.2/Python.h:67:0,
from /var/tmp/portage/kde-
base/pykde4-4.11.3/work/pykde4-4.11.3/kpythonpluginfactory/kpythonpluginfactory.cpp:28:
/usr/include/python3.2/object.h:402:23: error: expected unqualified-id before
‘;’ token
The relevant part of object.h reads:
397 typedef struct{
398 const char* name;
399 int basicsize;
400 int itemsize;
401 int flags;
402 PyType_Slot *slots; /* terminated by slot==0. */
403 } PyType_Spec;
Not sure where the problem really is but it smells like a namespace
collision...
--
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: 4.11.0 tarballs available (for packagers)
Am Freitag, 9. August 2013, 13:55:38 schrieb Rex Dieter: > On 08/09/2013 05:47 AM, Andreas K. Huettel wrote: > > Am Donnerstag, 8. August 2013, 01:58:01 schrieb Albert Astals Cid: > >> The tarballs can be found in their usual embargo location (available > >> only to packagers) > > > > Marble python bindings fail to build. > > Tracked here, > https://bugs.kde.org/show_bug.cgi?id=322573 > ... and the fix was pushed, see bug report (have not tested it myself yet). Time to re-roll marble? -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.11.0 tarballs available (for packagers)
Am Donnerstag, 8. August 2013, 01:58:01 schrieb Albert Astals Cid: > The tarballs can be found in their usual embargo location (available only > to packagers) Marble python bindings fail to build. [MarbleAbstractRunner.h: file or directory not found] In file included from /var/tmp/portage/kde- base/marble-4.11.0/work/marble-4.11.0_build/src/bindings/python/sip/sipmarblepart1.cpp:7:0: /var/tmp/portage/kde- base/marble-4.11.0/work/marble-4.11.0/src/bindings/python/sip/AbstractDataPluginItem.sip:46:34: schwerwiegender Fehler: MarbleAbstractRunner.h: Datei oder Verzeichnis n icht gefunden Kompilierung beendet. In file included from /var/tmp/portage/kde- base/marble-4.11.0/work/marble-4.11.0_build/src/bindings/python/sip/sipmarblepart0.cpp:7:0: /var/tmp/portage/kde- base/marble-4.11.0/work/marble-4.11.0/src/bindings/python/sip/AbstractDataPluginItem.sip:46:34: schwerwiegender Fehler: MarbleAbstractRunner.h: Datei oder Verzeichnis n icht gefunden Kompilierung beendet. -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review35686 --- Just for the record, we've added this patch in Gentoo since 4.10.5 (to get rid of the security issue in > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110962/ > --- > > (Updated June 11, 2013, 9:28 p.m.) > > > Review request for KDE Graphics, Release Team and Gilles Caulier. > > > Description > --- > > Instead of using an embedded copy of LibRaw, look for an external LibRaw as > mandatory dependency with a new CMake module and using its variables. > > Considering some LibRaw versions seem to be underlinked and not linking to > OpenMP, link it manually in libkdcraw to overcome such lack. > > Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by > KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as > otherwise LIBRAW_BUILDLIB would conflict with LibRaw. > > Once this RR is approved, I will remove the libraw code copy and the CMake > modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. > > > This addresses bug 307146. > http://bugs.kde.org/show_bug.cgi?id=307146 > > > Diffs > - > > CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd > cmake/modules/FindLibRaw.cmake PRE-CREATION > libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce > libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b > > Diff: http://git.reviewboard.kde.org/r/110962/diff/ > > > Testing > --- > > Compiles fine with both LibRaw 0.14.7 and 0.15.1. > > > Thanks, > > Pino Toscano > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review34192 --- I can't comment on the code, but switching to an external libraw is definitely a good idea, see also https://secunia.com/advisories/53547/ - Andreas K. Huettel On June 11, 2013, 9:28 p.m., Pino Toscano wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110962/ > --- > > (Updated June 11, 2013, 9:28 p.m.) > > > Review request for KDE Graphics, Release Team and Gilles Caulier. > > > Description > --- > > Instead of using an embedded copy of LibRaw, look for an external LibRaw as > mandatory dependency with a new CMake module and using its variables. > > Considering some LibRaw versions seem to be underlinked and not linking to > OpenMP, link it manually in libkdcraw to overcome such lack. > > Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by > KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as > otherwise LIBRAW_BUILDLIB would conflict with LibRaw. > > Once this RR is approved, I will remove the libraw code copy and the CMake > modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. > > > This addresses bug 307146. > http://bugs.kde.org/show_bug.cgi?id=307146 > > > Diffs > - > > CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd > cmake/modules/FindLibRaw.cmake PRE-CREATION > libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce > libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b > > Diff: http://git.reviewboard.kde.org/r/110962/diff/ > > > Testing > --- > > Compiles fine with both LibRaw 0.14.7 and 0.15.1. > > > Thanks, > > Pino Toscano > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Soft feature freeze exception for DrKonqi
Am Donnerstag, 30. Mai 2013, 14:53:41 schrieb Jekyll Wu:
> 于 2013年05月30日 18:39, Andreas K. Huettel 写道:
>
> The reality is: bugs.kde.org (since upgrading to bugzilla 4.2.5 at
> least one month ago) has already been rejecting any attempt against
> disabled versions. It is not DrKonqi that is doing the rejection
> (although that was my initial plan). The point of my current proposal
> is just to improve the usability issue caused by that bugzilla
> rejecting behavior: inform users as early as possible that
> bugs.kde.org will reject this report , instead of wasting their time
> and telling them in the last minute.
OK that clarifies the situation, and it's a good plan.
> > Is there some functionality around to re-direct the report to
> > another bugtracker (optionally only if it is not matched)?
>
> If we redirect those reports to another bug tracker (say
> bugs2.kde.org), who are expected and willing to read those reports
> from disabled/outdated versions ?
I was thinking more about a messge roulghly like (packagers please don't shoot
me immediately) "This version is too old and the KDE developers do not accept
bug reports about it anymore. If you would like to submit the report to the
${Distribution} bugtracker, please press continue, otherwise please abort."
I could imagine implementing this by providing a central place in the code
where distros *can* if they want set a "secondary bugzilla" and maybe some
description string- which if present is offered exactly and only when the
primary one cannot be used.
However, probably the entire mechanism is too much tied into the specific
structure of the KDE bugtracker (products, versions, ...).
In any case, this is offtopic for here by now (but feel free to cc me if a
future discussion is started, I'm not yet subscribed to kde-core-devel again.)
Cheers, A
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Soft feature freeze exception for DrKonqi
Am Donnerstag, 30. Mai 2013, 13:06:24 schrieb Martin Graesslin: ... > * DrKonqi is too smart, it doesn't recognize the orig report anymore, but > only the duplicates. Points taken... then how about, could drkonqui maybe try to "walk back the duplicates chain on bugzilla"? In any case, this is probably offtopic for here and now. Cheers, Andreas signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Soft feature freeze exception for DrKonqi
Hi Jekyll et al., (cc'ing packagers too) > That DrKonqi feature is preventing users creating reports against > disabled versions as early as possible in the reporting process. That is > a quite necessary change IMO to deal with the usability problem caused > by bugzilla's recent nice behavior of rejecting any attempt against > disabled versions. > > See https://bugs.kde.org/show_bug.cgi?id=315073 for more background > information , and https://git.reviewboard.kde.org/r/110687/ for the > proposed patch. Reality check... people do use outdated versions. Especially since there are things like distributions around. (And I'm talking more about those that do proper stable releases every few years than about Gentoo.) Are the crash reports at least matched against fixed bugs? (I.e. "This backtrace is a duplicate of ... and the report has been closed as fixed in a newer version of KDE?") Is there some functionality around to re-direct the report to another bugtracker (optionally only if it is not matched)? (This all of course depends on how you handle which versions are disabled in Bugzilla.) Cheers, Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
Am Samstag, 27. April 2013, 09:51:19 schrieb Aaron J. Seigo:
> On Friday, April 26, 2013 18:36:07 Scott Kitterman wrote:
> > It matters less that workspace is frozen if applications aren't, but
> > unlike
> > kdelibs, users see the workspace.
>
> yes. which is why we don't want to just ship a 4.12 and 4.13 with virtually
> no changes to kde-workspace without an explanation for why development has
> suddenly stopped.
>
> we will continue working on bug fixes and other polishing and improvement
> work, we just won't be focusing feature work there. i'd rather be straight
> forward with our users as to why this is happening.
This all sounds *exactly* like the discussion when kdelibs went into
maintenance mode. And even there, the sudden change of policies ("current
branch is not master anymore, version numbers do not increase") lead to a big
mess.
Please, everyone, do not confuse policies and practicalities.
I fully support the idea that larger parts of "what used to be called KDE"
enter maintenance mode for easing the transition to "frameworkx". This is a
*policy*.
However, there is _absolutely_ _no_ _need_ that new rules (i.e. "no new
features, only bugfixes") must lead to changes in versioning scheme. Or even
changes in branch names. Just declare "master only accepts bugfixes in modules
a,b,c from now on".
By re-organizing versioning and packaging scheme again, you are just making
things difficult again for yourself and the rest of the world.
I am all for just continuing the current release and release numbering
process, with the same types of git branches, while just behind the scences
declaring more and more parts "feature-frozen".
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
Am Dienstag, 12. Februar 2013, 22:05:00 schrieb Martin Gräßlin: > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > This whole thread was about stable tars, not RC or Beta. > > Sorry at least to me that was not obvious. (thread started on 31. of > January, doesn't mention minor releases, so I assumed it meant the > upcoming release of 4.10) - all I wrote so far was explicitly for the case > of a 4.x.0 release. > > > What was found > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > Reported not in bug reports, but more a discussion on IRC, see if anyone > > was aware, sometimes ml, again, just checking if it was a known/accepted > > regression. > > status quo is that currently the branches are basically untested. Here > personally I would love to get more testing as I never like pushing to > branch (let's push to master, if nobody screams in two weeks, let's > backport). [shameless plug] Use Gentoo, it's trivial here since the install process is basically the same whether git (any branch) or tarball. Our packager team mostly runs live builds, and adapts the packaging instructions there first, which is then copied to the release version. [/shameless plug] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
Am Montag, 11. Februar 2013, 00:24:51 schrieb Albert Astals Cid: > El Diumenge, 10 de febrer de 2013, a les 08:15:40, Martin Gräßlin va escriure: > > On Saturday 09 February 2013 23:08:50 Albert Astals Cid wrote: > > > Of course another option is lifting the requirement for the > > > pre-packages not being publicly available, after all the packages will > > > most likely be the real thing, so if everyone agrees it is better > > > lifting this requirement, we can do it, the fact that *I* personally > > > like it the way it is doesn't mean it's the better way. > > > > With my bugzilla user hat on I'm afraid of that. It would mean we get bug > > reports for an unreleased version. That's bound to create confusion - we > > would not be able to trust the version field any more. In case of a > > re-spin it will get just worse - different tar balls with the same > > version information. > > Another option is just release the tarballs once and don't do any respin at > all. After all we have build.kde.org that builds the stuff so we are kind > of "confident" it builds, if anything fails to build or something big is > found we can add it as a note (+ kde-packager mail) to the info page like > we did with the nepomuk thing for 4.10.0 http://kde.org/info/4.10.0.php > > That seems like a "sensible" compromise to me. > > * We release only one tarball > * Distros still can pick up build or bugfixes (as they will do anyway > either we include them in a respin tarball or not) > * We can "silently" release the *only one* tarball a few days in advance > to get distros to package for the release day > > Comments? > Actually, I think the current procedure is OK as it is. Sure, things can go wrong sometime, but as long as someone of the knowledgeable upstream developers cares and quickly codes a fix or workaround, that is not really a big problem. No distro will stick with "vanilla tarballs" just for the fun of it if upstream has accepted a patch that solves a real problem into the stable/bugfix branch. [As for the longer testing... well, 1) in the case of .0 versions, that's what betas and rc's are for, and 2) in the case of .X versions, X>0, well, it's called the "stable branch" for a reason- don't mess with it! [Actually I've been working on automatically extracting some statistics how large a percentage of the code is changed between git tags, since I was curious how well "the code converges" in different packages. Will finish this once I get around to it... (No Perl.)]] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Exception for Dolphin - KFileMetadataWidget
Just a question- > I wanted to fix this with 4.10, so I copied most of the widget to nepomuk > -widgets and named it Nepomuk2::FileMetadataWidget. Seems like now (compared to 4.9) it is not possible anymore to deactivate the semantic desktop (nepomuk) features during build completely and still keep dolphin. Intentional or accidental? Only asking so we write the dependencies correctly. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Akonadi-Nepomuk Feeder Improvements
Am Freitag, 28. Dezember 2012, 21:02:37 schrieb Christian Mollekopf: > On Friday 28 December 2012 18.58:55 laurent Montel wrote: > > Perhaps you can create a review on https://git.reviewboard.kde.org it's > > more easy to see diff and comment. > > https://git.reviewboard.kde.org/r/107989/ > > Cheers, > Christian Seriously. I know I'm probably just putting my foot in my mouth once more here, but: What are betas and rc's for, if not for stabilizing code and progressing to smaller and smaller non-intrusive changes? If you decide do kick out and replace a large chunk of code between rc1 and rc2, 2 weeks before release, you may as well re-label the 4.10.0 release "beta1". -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
libkdcraw api compatibility?
Hi, it seems like there are api-incompatible changes in libkdcraw-4.9.80 (compared to 4.9.x). /var/tmp/portage/media- gfx/digikam-2.9.0/work/digikam-2.9.0/core/utilities/cameragui/devices/umscamera.cpp: In member function ‘virtual bool Digikam::UMSCamera::getThumbnail(const QString&, const QString&, QImage&)’: /var/tmp/portage/media- gfx/digikam-2.9.0/work/digikam-2.9.0/core/utilities/cameragui/devices/umscamera.cpp:227:5: error: ‘loadDcrawPreview’ is not a member of ‘KDcrawIface::KDcraw’ No problem inside KDE proper, and I also know that digikam-3_betaX and kipi- plugins-3_betaX is fixed. However... Are there any other known third-party consumers for that? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
Am Freitag, 27. Juli 2012, 22:03:48 schrieb Alexander Neundorf: > I think I mostly agree. It sounds like the correct thing to do. > I'm aware that this may somewhat contradict my posts to the versioning > discussions on kde-frameworks... > > But basically, if a library has not changed, I agree that it's version > number should also not change. > Still all can be released again, so you can get everything at once if you > need. > Then let's please get back to the important point: you will need to specify exactly "what fits together". Before the versioning starts to disagree. -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail m...@akhuettel.de http://www.akhuettel.de/research/ http://www.physik.uni-r.de/forschung/huettel/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
> > In the case of Gentoo, we start our work of doing a new KDE release by > > bumping the ebuild (Gentoo package format) version - for example we > > bump kdelibs-4.8.3 to kdelibs-4.8.4 or kate- to kate-4.8.95. > > As the name of the tarball that we try to download is based on the > > package version, if you have a > > So you guys have some artificial version 4.x.49. which downloads > sources from a branch and builds them? Artificial in not released by kde? > > So everyone out there having this version does not really know which > version he has? Because it depends on when he built? These versions are hardmasked and usually not visible to users. The build log contains timestamp and git commit hash of every repository involved, and is a hard requirement so we even look at a bug report. BTW, this actually makes Gentoo a great distribution for KDE development, you can very easily run newest master and it's fully integrated with the distribution package management. > > Can i interpret that that you guys would get problems too if we would not > release all our packages with 4.9.2 . Remember we are talking about leaving > unchanged packages out of the release on minor releases! > See separate mail, yes right now we're relying on same version number for all of KDE. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Am Dienstag 03 Juli 2012, 19:25:13 schrieb Michael Jansen: > > I really would like to have some input of real packagers here. I am > inclined to say if noone speaks up now they have to live with whatever we > come up afterwards. I am not caring for people who only complain after > stuff is done when they kept silent while it was discussed and designed. > > INPUT guys. NOW. > It probably helps if you cc the packager mailing list. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Am Samstag 30 Juni 2012, 15:29:37 schrieb Albert Astals Cid: > > > For KDE would say someone else should decide. We could make a release > > 4.8.80.1 if we have to repackage stuff. But the packagers distros should > > give input here. I think they should say what is the easiest for them to > > handle. > > I'm sure having a micro release is going to break their scripts that just > expect 3 numbers. Breaking the scripts once, with a well-thought-out change, is perfectly fine... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Am Mittwoch 27 Juni 2012, 17:39:03 schrieb Michael Jansen: > On Monday, June 25, 2012 01:16:05 AM Albert Astals Cid wrote: > > That works fine for me, though unfortunately we usually have to > > re-package some tarballs due to fixes that are needed into the release. > > How do you fit this particularity into this way of working? > > With my config manager head on i say "NEVER rerelease a version". Which in > our case includes everything that has been downloaded/used by anone not > you (You=Packager). Very strong agreement. If you want to re-release something, add an extra .x to the version number. > > > I see one problem. As you can see the changed version information is > > > only committed AFTER build and test in this setup. That can take quite > > > some time. In a project as big as ours that opens the possibility that > > > during that time some else commits a change. Which makes it impossible > > > for the script to commits its change. > > > > > > 1. Solution: Branch. The Script could create a branch for the release. > > > > Creating a branch for release would also probably "fix" the problem i > > spoke in the previous paragraph * Create a branch. * Build and test that branch. * Tag the release on that branch. * Merge the branch back into master / whatever it comes from. > > I am btw. wondering that noone objected yet to this. I seem to remember > someone was unhappy about dirk branching some 4.8.x release. I don't > remember where and why. Dunno. It was just funny, because, functionality-wise, master became 4.8 and 4.8 became 4.8.X. > > > > 2. Solution: Lock the repo (A no go in my opinion) > > > > Yeah, locking kills babies Ack. Not that it affects me, but the KDE developers will probably object to locking, with good reason. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Am Dienstag 03 Juli 2012, 19:30:23 schrieb Michael Jansen: > I am just wondering about the distros again. Say i release KDE SC 4.9.2 and > of all our packages only 10% got really changes. I wonder how that affects > the workload if we force a release of the 90% unchanged ones. Or do they > need them to be released? Gentoo case: Assuming nothing else is broken, the workload for the packagers of bumping every package from 4.9.1 to 4.9.2 is near zero. (Running a script over a git tree.) The main disadvantage is that all users will have to re- download all sources. But then, we're as a source based distro maybe a special case. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Am Mittwoch 27 Juni 2012, 17:21:28 schrieb Michael Jansen: > > This is partly still under discussion. > > > > However the currently implemented solution is that each framework has a > > versions number, but that version number can be upgraded in all > > frameworks at the same time, using a script. > > > > A future framework on top of all others, could provide the version number > > for all apps, much like the current kdeversion.h. Basically it would be > > the "SC" number, and not the version number of the libs themselves, as > > is currently the case. > > But that SC number would be a lie. Because you only assume all modules are > installed in the versions that were release as SC X.Y . You have no idea if > the user or distro uses older or newer versions for some libraries, modules > or apps. So that number has no information value. Perhaps some marketing > value. But in bug reports it is useless. Right now, in Gentoo we're basically relying on the fact that all kde sc packages that are installed have the same exact version (modulo local Gentoo revbumps with patches). However, this is not a "must". If you want, you can give each and every small component of (what used to be) KDE a separate version number. But... *before* you do this, you'll need to define exactly what dependencies you will require across the *entire* software set, taking into account version numbers! Right now, if someone installs (on Gentoo) gwenview-4.8.4, this pulls in as a dependency libkonq-4.8.4. Now, this is likely overspecified, and we might be fine with libkonq-4.8.*. So, a general rule for the moment may be gwenview- X.Y.Z requires libkonq-X.Y.*. Now, please give me the specifications for the new version numbering first, before you start using them! In particular also... what are major, minor, bugfix releases, what do you want to enforce in a dependency freeze, ... Cheers... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Am Mittwoch 20 Juni 2012, 21:30:23 schrieb Michael Jansen: > > 1. Add the version information into all of our modules in a way that a > outside script can get it. Some kind of file for example that is included > by the toplevel CMakeLists.txt and only contains the version information. Sounds good. > 2. Make the necessary build-system changes to use this version information > for the .SO names. Makes no sense, because soversions are already different. Better completely decouple from package version. > 3. Make it a rule that there is no other place allowed to contain version > information. If you need it somewhere else use cmakes configure_file(). > Btw. the version information should contain a human readable part > 4.8.3-beta2 too. (For the kdepims out there). Sounds good. > 5. Add a file into our modules that describe what to pack/ignore for our > source distributions. This contains the "removestuff" script parts from > kde- common/release. Use a file-format that is extensible (JSON, xml, > ...). And add possibly more (time will tell) Sounds very good. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8.5 planning
Am Donnerstag 05 Juli 2012, 19:51:41 schrieben Sie: > > As i see that you are on the release-team list. May i ask why you voice > your objections the exact same moment someone wants to try something we > discussed here on the list for quite some time instead of actively > participating this to the discussion before? Because I have a real life and a real job. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE 4.8.5 planning
> > > Hi, > > > > > > I guess with all the kdelibs mess we should redo another 4.8.5 > > > release. Does > > > anyone have suggestions for a release plan? > > > > > > I would like to do tagging either tomorrow morning or in the last > > > July week, > > > as I'm on vacation in between. > > > > > > Any preference? > > > > Will that be a "normal" release (i.e. full KDE SC) or just kdelibs? > > This might be a nice time to try only releasing the packages that have > changes. Please dont change that within stable series. Also, *before* you start doing partial releases, please present an exact definition of the dependencies *between versions*. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8.5 planning
> Hi, > > I guess with all the kdelibs mess we should redo another 4.8.5 release. Does > anyone have suggestions for a release plan? > > I would like to do tagging either tomorrow morning or in the last July week, > as I'm on vacation in between. > > Any preference? > Please no unnecessary hurry... having more time to doublecheck occasionally pays off! :) -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Proposed adjustments to our release cycles
> > know the current state of the release and commit new features or new > > strings when we are frozen, and that's with just one release schedule, i > > can imagine the mess with N different release schedules > > "Always summer in trunk". As long as releases are not created from the > master branch it should be fine. On the other hand nobody should commit > without a review anyway, so just commit and push without proper > communication with the core developer group is so wrong in the first place > That's actually not the whole problem. How will the feature releases of the constantly evolving frameworks interact with the dependency freezes of the applications?! Remember that for distributions it's far better to stick to bugfix releases of core libraries for a while, but feature upgrades of single applications may be easily doable. Now that means that * either the core libraries plus all the applications will get frozen in a distribution, because newer applications would need newer libraries * or we get into branching / #IFDEF madness, because older libraries require other codepathis in applications Thoughts? Cheers, Andreas -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail andreas.huet...@ur.de http://www.akhuettel.de/research/ http://www.physik.uni-r.de/forschung/huettel/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
monthly Gentoo KDE team meeting
Howdy all, just for general information the Gentoo KDE team has its monthly public meeting again next week, to be precise, #gentoo-meetings on freenode, thursday, 21 June 2012 19:00 utc Agenda can be found here (work in progress): http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2012-06;hb=HEAD Cheers! Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Nepomuk crashes in 4.8.4 fixed in KDE/4.8.x branch
Am Donnerstag 14 Juni 2012, 01:31:18 schrieb Albert Astals Cid: > Vishesh "fixed" the KDE/4.8.x branch of kdelibs. Can you guys verify it > also fixes the issues for you? > > If so, what's the next step? Release an early 4.8.5? Repackage 4.8.4 > kdelibs? > > Ideas? > > Cheers, > Albert While I fully agree that the changes requiring the newer soprano should not have been there in the first place, I'm now a bit confused... what is, for our users, actually the better solution? * Upgrade Soprano to the beta version, and stick with the original Nepomuk 4.8.4 code (since, afaik, the changes were made to address some bug?) * Keep Soprano as is and use Vishesh's revert? /me is confused, maybe someone knowledgeable on the code details could comment... in the end it probably boils down to "How big are the changes in Soprano"? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] smokekde build failures in beta2 tarballs:
Am Sonntag 10 Juni 2012, 23:20:48 schrieb Tom Albers: > - Oorspronkelijk bericht - > > > The version number seems to suggest otherwise, but 2.7.57 is more > > recent > > than 2.7.6. > > I'm slightly confused by this remark. Would anyone have the same idea when > we release KDE 4.10 after KDE 4.9 ? > Well the Perl crowd does stuff like "version number is treated as float"... not that I approve of that... imho most people will interpret it correctly. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Fwd: smokekde build failures in beta2 tarballs:
Am Sonntag 10 Juni 2012, 22:34:21 schrieb Arno Rehn: > > Oops, seems I overlooked that. Thanks for pointing it out again, I'll > > have a look. > > Fixed in > > http://commits.kde.org/smokegen/7b67ac626f27e1d405ab92a2d2a8bb91ffa98c2d Excellent, thanks! Fix confirmed, and all of 4.8.90 now builds and installs fine on Gentoo. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Am Sonntag 10 Juni 2012, 15:27:55 schrieb Albert Astals Cid: > > > > - - Before announcing the tarballs, build the whole thing at least once. > > We do that, that's why we have a week before the release where packagers > get access to pre-release tarballs. > I hope you're not too serious about that. None of us distribution packagers is actually using the unmodified build scripts. So there are lots of additional problem sources. Yes they are our problems then, but it would be helpful to know that "it could work". (It is not hard. Take one reasonably fast box with some sane average defaults. Install what (according to release notes) should be installed. make install. Come back in a few hours and inform whoever's module failed.) That aside, I think a few build failures in a >pre-release< >beta< tarball the size of KDE should not be a problem. After all, we want to help, and we still have some time figuring out solutions to problems. What I am worrying much more about is 1) confusion about dependencies (Soprano, SDO, Qt): e.g, in an ideal world, there would be a dependency freeze some time before the release, and it would only be allowed to use dependencies actually released publically at *that* time. 2) my feeling of a different perception of "stable" between packagers and developers -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Notifying project teams (was: Re: kde-runtime does not finds kactivites)
Am Sonntag 10 Juni 2012, 00:52:28 schrieb Andreas Pakulat: > > Basically the same goes to all the rest of your mails, if things don't > build, the first person to speak to is the corresponding development > team/maintainer so such problems get fixed asap. > That is a reasonable suggestion, however please let me answer with a reasonable suggestion of my own: I'm usually not following the day-to-day development of, say, kdebindings. Which means I am not subscribed to the kde-bindings mailing list. However, this list is the correct place, I guess, to report kde-bindings issues. When I post something there, it's first held for moderator approval, which may take a while. For every single e-mail. For every kde team e-mail list. Again. Mailman has this great feature of "whitelisting" senders even if they are not subscribers. Would you consider as a policy eventually whitelisting people with an obvious distro e-mail address on the public project mailing lists? Does not have to be automatical and on the first try... it's just annoying if you get your third "... awaits moderator approval" mail from the same list... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: smokekde build failures in beta2 tarballs:
> On 06/09/2012 11:52 PM, Manuel Tortosa wrote:
> > Compiled with Soprano support, using the soprano needed for nepomuk core,
> > so 2.7.56:
> >
> > Scanning dependencies of target smokesoprano
> > [ 5%] Building CXX object
> > soprano/CMakeFiles/smokesoprano.dir/smokedata.o In file included from
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/soprano/smokedata.cpp:1:0:
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/soprano/soprano_includes.h:54:31: fatal
> > error: soprano/tcpclient.h: No such file or directory
> > compilation terminated.
> > make[2]: *** [soprano/CMakeFiles/smokesoprano.dir/smokedata.o] Error 1
> > make[1]: *** [soprano/CMakeFiles/smokesoprano.dir/all] Error 2
> > make[1]: *** Waiting for unfinished jobs
This can be fixed by applying the patch to soprano that restores abi/api
compatibility (the tcpclient stub, posted here on the mailinglist).
http://mail.kde.org/pipermail/release-team/2012-May/005746.html
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=dev-
libs/soprano/files/soprano-2.7.56-
tcpclient.patch;h=2b04f668033bcfdfcf331e696f11543369352f2e;hb=HEAD
Soprano maintainers, ping, could we please get a new release that we can
depend on?
> > Compiled with -DWITH-Soprano=OFF:
> >
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp:3801:196: error: no matching
> > function for call to '__smokekdeui::x_KFontDialog::getFontDiff(QFont&,
> > QFlags, const QFlags,
> > QWidget*, Qt::CheckState*)'
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp:3801:196: note: candidate is:
> > In file included from /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/kdeui_includes.h:58:0,
> >
> > from /chakra/desktop-unstable/kdebindings-
> >
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp:2:
> > /usr/include/kfontdialog.h:171:14: note: static int
> > KFontDialog::getFontDiff(QFont&, KFontChooser::FontDiffFlags&, const
> > DisplayFlags&, QWidget*, Qt::CheckState*)
> > /usr/include/kfontdialog.h:171:14: note: no known conversion for
> > argument 2 from 'QFlags' to
> > 'KFontChooser::FontDiffFlags& {aka QFlags&}'
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp: In static member function
> > 'static void __smokekdeui::x_KFontDialog::x_29(Smoke::Stack)':
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp:3806:206: error: no matching
> > function for call to '__smokekdeui::x_KFontDialog::getFontDiff(QFont&,
> > QFlags, const QFlags,
> > QWidget*, Qt::CheckState*)'
> > /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp:3806:206: note: candidate is:
> > In file included from /chakra/desktop-unstable/kdebindings-
> > smokekde/src/smokekde-4.8.90/kdeui/kdeui_includes.h:58:0,
> >
> > from /chakra/desktop-unstable/kdebindings-
> >
> > smokekde/src/smokekde-4.8.90/kdeui/x_6.cpp:2:
> > /usr/include/kfontdialog.h:171:14: note: static int
> > KFontDialog::getFontDiff(QFont&, KFontChooser::FontDiffFlags&, const
> > DisplayFlags&, QWidget*, Qt::CheckState*)
> > /usr/include/kfontdialog.h:171:14: note: no known conversion for
> > argument 2 from 'QFlags' to
> > 'KFontChooser::FontDiffFlags& {aka QFlags&}'
> > make[2]: *** [kdeui/CMakeFiles/smokekdeui.dir/x_6.o] Error 1
> > make[2]: *** Waiting for unfinished jobs...
That looks like the same failure I reported earlier on.
http://mail.kde.org/pipermail/release-team/2012-June/005868.html
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Am Samstag 09 Juni 2012, 12:57:16 schrieb Aaron J. Seigo: > > now, i really don't understand the use of words like stupid and dumb. I'll leave the fist fighting to others, and would like to apologize for my choice of words. I still dont think the decision to freeze master was a good or necessary one. It's perfectly reasonable to say "hey let's only do bugfix/minimal changes to *any* kdelibs branch for now, even if for everyone's convenience we keep the usual branch structure". That would be a practical decision, not a political one. In the worst case you'll end up with two identical, redundant branches. In the best case a few things (like the mentioned udisks2 support) could creep into master, as backport from the frameworks. (Gentoo would like to drop udisks too in favour of udisks2, or so I'm told from its maintainer. Adding the redhat patch has been on my todo list for a couple of weeks already.) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Am Samstag 09 Juni 2012, 12:37:28 schrieb Albert Astals Cid: > > You are all making noise out of nothing, the amount of changes is in the > same order of magnitude of other releases. > > Please stop let's stop throwing shit to the other side of the fence and > start being constructive Actually you're right with this point, I apologize. Reading the git log, the changes are indeed same order of mangnitude as before. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Am Samstag 09 Juni 2012, 12:10:40 schrieb Modestas Vainius: > Hello, > > On šeštadienis 09 Birželis 2012 13:01:20 Albert Astals Cid wrote: > > > here at Debian we had a really bad experience with 4.8.4. While 4.8.3 > > > was pretty good, 4.8.4 seemed like a huge step backwards in terms of > > > stability (random crashes there and there). After quick investigation > > > of kdelibs 4.8.4 I found the following: > > > > > > > > > I don't know yet if any other modules from 4.8.4 has been > > > mis-packaged in the same way > > > > There's no mispackaging. If you followed the list or read the archives > > before blaming people of wrong doing you'd know that kdelibs for 4.8.4 > > and 4.8.80 actually come from the same branch. > > Thank you for pushing a bunch of untested huge changes in the "minor" point > release. Really appreciated. Exactly. Thumbs up. Making KDE more stable and predictable than ever. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Am Samstag 09 Juni 2012, 11:58:44 schrieb Kevin Kofler: > On Saturday 09 June 2012, Modestas Vainius wrote: > > I don't know yet if any other modules from 4.8.4 has been > > mis-packaged in the same way > > Due to the permanent feature freeze of kdelibs 4, there is actually no > difference between kdelibs 4.8.4 and 4.8.80/4.8.90 other than the version > number, they both come from the 4.8 branch (which itself was originally the > 4.7 branch). > > Yes, it's stupid, but it's how the kdelibs maintainers want things to be. > :-( > As an outsider who does not really (have to) know how much he puts his foot in his mouth with that, let me confirm that it's really an extremely dumb idea. The regular mess at release time speaks volumes. I would even go so far as to suggest that the kdelibs maintainers get together and do some creative merging, reverting and branching to make kdelibs from now on follow the same workflow as the rest of kde again. With Git that is certainly possible. Which obviously does not mean that suddenly all of kdelibs should be rewritten or broken. However, imposing this branch weirdness on everyone else for pure political reasons is just wrong. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9 beta2 packages available
> I have not tried the packages are buildable so testing more than welcome
> :-)
OK, next try. By now I've built nearly whole of 4.8.90. Only thing where I'm
stuck now is smokekde:
/var/tmp/portage/kde-
base/smokekde-4.8.90/work/smokekde-4.8.90_build/kdeui/x_6.cpp: In static
member function 'static void __smokekdeui::x_KFontDialog::x_14(Smoke::Stack)':
/var/tmp/portage/kde-
base/smokekde-4.8.90/work/smokekde-4.8.90_build/kdeui/x_6.cpp:3731:216: error:
no matching function for call to
'__smokekdeui::x_KFontDialog::getFontDiff(QFont&,
QFlags, const QFlags,
QWidget*, Qt::CheckState*)'
/var/tmp/portage/kde-
base/smokekde-4.8.90/work/smokekde-4.8.90_build/kdeui/x_6.cpp:3731:216: note:
candidate is:
/usr/include/kfontdialog.h:171:14: note: static int
KFontDialog::getFontDiff(QFont&, KFontChooser::FontDiffFlags&, const
DisplayFlags&, QWidget*, Qt::CheckState*)
/usr/include/kfontdialog.h:171:14: note: no known conversion for argument 2
from 'QFlags' to 'KFontChooser::FontDiffFlags& {aka
QFlags&}'
... and a few more like this. Full build log is at
http://dev.gentoo.org/~dilfridge/smokekde-4.8.90.log
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9 beta2 packages available
Am Freitag 08 Juni 2012, 19:20:21 schrieb Andreas K. Huettel: > Am Freitag 08 Juni 2012, 01:57:59 schrieb Albert Astals Cid: > > I have not tried the packages are buildable so testing more than welcome > > > > :-) > > The dolphin git and svn plugins fail to link here, probably an underlinking > or linking order issue. Excerpt from the build log follows, the full log > is at https://gist.github.com/2896963 > Actually I think you can ignore my e-mail, this is a Gentoo-specific problem... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9 beta2 packages available
Am Freitag 08 Juni 2012, 01:57:59 schrieb Albert Astals Cid: > I have not tried the packages are buildable so testing more than welcome > :-) The dolphin git and svn plugins fail to link here, probably an underlinking or linking order issue. Excerpt from the build log follows, the full log is at https://gist.github.com/2896963 [...] /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90_build/dolphin-plugins/svn/moc_fileviewsvnplugin.cpp:106: undefined reference to `KVersionControlPlugin2::qt_metacall(QMetaObject::Call, int, void**)' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: In function `FileViewSvnPlugin::qt_metacast(char const*)': /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90_build/dolphin-plugins/svn/moc_fileviewsvnplugin.cpp:101: undefined reference to `KVersionControlPlugin2::qt_metacast(char const*)' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: (.data.rel.ro._ZTI17FileViewSvnPlugin[typeinfo for FileViewSvnPlugin]+0x10): undefined reference to `typeinfo for KVersionControlPlugin2' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: (.data.rel.ro._ZTV17FileViewSvnPlugin[vtable for FileViewSvnPlugin]+0x88): undefined reference to `KVersionControlPlugin2::versionState(KFileItem const&)' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: (.data.rel.ro._ZTV17FileViewSvnPlugin[vtable for FileViewSvnPlugin]+0x90): undefined reference to `KVersionControlPlugin2::contextMenuActions(KFileItemList const&)' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: (.data.rel.ro._ZTV17FileViewSvnPlugin[vtable for FileViewSvnPlugin]+0x98): undefined reference to `KVersionControlPlugin2::contextMenuActions(QString const&)' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: (.data.rel.ro+0x0): undefined reference to `KVersionControlPlugin2::staticMetaObject' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin.o: In function `FileViewSvnPlugin': /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/svn/fileviewsvnplugin.cpp:63: undefined reference to `KVersionControlPlugin2::KVersionControlPlugin2(QObject*)' CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin.o: In function `FileViewSvnPlugin::slotShowUpdatesToggled(bool)': /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/svn/fileviewsvnplugin.cpp:392: undefined reference to `KVersionControlPlugin2::itemVersionsChanged()' [...] var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:414: undefined reference to `KVersionControlPlugin2::errorMessage(QString const&)' /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:408: undefined reference to `KVersionControlPlugin2::operationCompletedMessage(QString const&)' /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:409: undefined reference to `KVersionControlPlugin2::itemVersionsChanged()' CMakeFiles/fileviewgitplugin.dir/fileviewgitplugin.o: In function `FileViewGitPlugin::execGitCommand(QString const&, QStringList const&, QString const&, QString const&, QString const&)': /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:597: undefined reference to `KVersionControlPlugin2::infoMessage(QString const&)' CMakeFiles/fileviewgitplugin.dir/fileviewgitplugin.o: In function `FileViewGitPlugin::slotOperationCompleted(int, QProcess::ExitStatus)': /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:540: undefined reference to `KVersionControlPlugin2::errorMessage(QString const&)' /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:542: undefined reference to `KVersionControlPlugin2::operationCompletedMessage(QString const&)' /var/tmp/portage/kde-base/dolphin-plugins-4.8.90/work/dolphin- plugins-4.8.90/dolphin-plugins/git/fileviewgitplugin.cpp:543: undefined reference to `KVersionControlPlugin2::itemVersionsChanged()' [...] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Request for delaying 4.8.4 request
> What do you expect to be in the .5 release? I as a developer already > deleted my local KDE/4.8 branch as the release schedule said there won't > be any 4.8 release any more. I expect that also other developers are > able to read the schedule and do their planning according to it. > > Even if I had the local branch around, I would probably no longer push > any changes to 4.8. From a bugfixing perspective we are concentrating on > 4.9 and it becomes more and more difficult to test anything on 4.8, > especially once 4.9 is branched. The time spend backporting to 4.8 is > quite high compared to the benefits of the bugfix to go into that > release. Certainly there will be some fixes that are developed and/or applied for example by distributions or with help from them. After all some people will actually run 4.8 now and not immediately switch to 4.9. :) Being able to collect them somewhere with review would be a huge bonus, and could in the end lead to a 4.8.5 release. Making KDE even more stable and user-friendly! -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Calling off Beta1
> El Dimarts, 29 de maig de 2012, a les 19:31:37, Kevin Kofler va escriure: > > On Tuesday 29 May 2012, Albert Astals Cid wrote: > > > Blame the soprano developers and the nepomuk developers for not > > > respecting > > > the dependency freeze. > > > > Oh by the way, this is not the first time a prerelease of the KDE SC > > depends on a git snapshot of Soprano, either (sadly). So it's not so big > > a catastrophe to warrant canceling the entire release! > > I'm the release dude now, I've decided I don't want to release tarballs that > depend on something that does not exist. > > You can volunteer if you don't like how I'm doing the work and let the rest > of the release team decide who they want doing the job. > > Cheers, > Albert Meh. Come on. 1) I fully support the idea that at a freeze things should be frozen. This was not ideal in the past, and it's great that you want to change it. Having a soprano version plus tarball to depend on is a great idea. 2) However, how about giving people one release to get used to new things? So far some rules have been ignored, next time people will know that rules will not be ignored, fine. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE 4.8.0 tarballs (try#1)
> they are split into subtarballs now, following git module split. [...] > > I'm sorry, I can not maintain two sets of tarballs, it is just too much time > that I don't have. Thanks Dirk. That's perfectly fine... just tell us please, so there is no confusion. :) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8.0 tarballs (try#1)
Am Freitag 20 Januar 2012, 00:43:18 schrieb Eric Hameleers: > > Indeed, kdeutils was split, into ark, filelight, kcalc, kcharselect, > kdf, kfloppy, kgpg, printer-applet, kremotecontrol, ktimer, kwallet, > superkaramba, sweeper, ksecrets. > > And the same is true for kdeaccessibility. > That one split up into jovie, kaccessible, kmag, kmouth, kmousetool. > > Cheers, Eric Right... now the question is, are the combined tarballs going away with 4.8.0 or will they exist in the future again (as in 4.7.97)? No problem in principle with either thing here, it would just be nice to know. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8.0 tarballs (try#1)
Am Mittwoch 18 Januar 2012, 22:15:12 schrieb Arkadiusz Miśkiewicz: > On Wednesday 18 of January 2012, Dirk Mueller wrote: > > Hi, > > > > I didn't even smoketest them yet, but I just finished generating and > > uploading the first set of 4.8.0 tarballs. > > > > Please report any blocker issues or compilation issues either to > > kde-packager or release-team > > You really, really need to fix your scripts :) > > kdeaccessibility and kdeutils are traditionally missing. Ping? :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Potential data loss with bug 289945
The problem seems to be in kwin - if you keep kontact running and replace the window manager by f.ex. executing in a konsole "fvwm --replace", suddenly drag and drop works fine... Am Mittwoch 11 Januar 2012, 10:45:34 schrieb Myriam Schweingruber: > Hi all, > > Since the release of KDE 4.8 approaches fast, I would like to notify > you about https://bugs.kde.org/show_bug.cgi?id=289945 > > I raised the severity of that bug to grave as it can lead to data > loss. So far it is only reproducible with KDE 4.8, starting once I > upgraded to beta and still around with RC2. > > Find below a little discussion I had with Rolf Eike this morning in > #kde-devel: > > looks like you are involved in bug 289945 somehow > sort of, yes, I had that problem with RC1 > bug 291050 has a comment saying it's a dupe > I remember having seen this on my laptop, too > for me it always opened the dragged mails in kate > it chooses whatever open window is on the same desktop, for > me it tried to open stuff in Chromium > since this can lead to data loss and leakage of sensible > information I would vote for raising the severity of this bug > the problem is with the focus I think > yes, sounds like a very good idea > no, I can surely say it doesn't > I have only one window per virtual desktop > kate is always on #6, kontact on #1 > oh, so even cross virtual desktop? Choosing whatever it > finds that is open? Ouch > so while this likely has to do something with focus, it's not > related to the same desktop > no idea, maybe it's just the last application that had focus > before or whatever > > Somebody suggested in a comment of that bug that it might be related > to Qt, but I didn't change my Qt version since quite some time, the > only change was my upgrade to KDE 4.8 beta, currently RC2 > > Thank you for looking into this > > Regards, Myriam -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Tags for recent releases are missing in the git repositories of kdelibs and kde-workspace
May I please also ask for the 4.7.4 tags?! The tags are pretty useful for e.g. checking if a fix has been included in a release... TIA, Andreas Am Donnerstag 08 Dezember 2011, 16:10:46 schrieb Nicolás Alvarez: > > Situation remains. The 4.7.80 tags I mentioned are still missing, and > *nothing* has 4.7.4 tags, even though both versions are officially > released now. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Requesting freeze exception for JtG
> > From my first e-mail: > > --8<--- (snip) > --8<--- > > Also, making the patch non-invasive means the visibility of Join the > Game plummets. > > I'm quite disappointed people have spent more time answering e-mails > than testing the code. Please. We all read your first e-mail. However, I'd like to point out that you are the one trying to get around the well-known rules. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Commit IDs for 4.7.2
Hiya, in general it would be great if you could tag 4.7.2 and push the tags out... at least kdepim-runtime does not have it yet. Thanks, Andreas Am Freitag, 7. Oktober 2011, 13:27:33 schrieb Javier Llorente: > Hello! > > Could anyone please tell me the commit IDs for kde-runtime, kde-workspace > and kdelibs (4.7.2 final release)? > > Thanks! :) > Javier > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-graphics-devel] kdegraphics 4.6.4 tarball contains the wrong okular
Am Mittwoch 22 Juni 2011, 15:15:06 schrieb Dirk Mueller: > > Is it good to wait until next week when 4.6.5 is to be done to clean that > up or should we do an intermediate 4.6.4.1 release? > Releasing it with 4.6.5 is a good plan. More time to prepare and check... :) Thanks for all your hard work, I guess you're the one who gets hit most by the git migration. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
> > So forget about monolithic tarballs please. It is clouding the issue. > Exactly. Having a larger number of small tarballs can be just fine if done properly. But, they should still have the same release schedule, version number, and should be tested to work together. I.e. released as a working whole, not released as an assembly of hopefully working pieces. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.6.4 heads up
Am Donnerstag 09 Juni 2011, 12:28:01 schrieb Sebastian Kügler: > Hi, > > As I'm just back from Randa (and the needed sleep afterwards), 4.6.4 is not > out yet Just one quick question- in the kdeedu module, both libkdeedu and kalzium have a libscience subdir and build/install it, and the source code is (slightly) different. Which one should we take? I suspect kalzium/libscience because a typo is fixed there... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
> I just read a very good novel where all such talk about "Software Collection" > or "Platform" was aptly called "commercial bulshytt". I think many of us, > including your "only-users", would appreciate it if you all there upstream > would just stick to KDE, because that is what everyone uses. Nothing else. > Not on-topic for this list at all, nor relevant for this thread... That is not true. The large majority of your _userbase_ does not identify themselves with, say, solid, okular, libkipi, phonon, and krosspython. Maybe some technically minded people are huge enthusiasts about plasma. In the end, however, what people are talking about is the entity KDE, and what people appreciate is its entirety as desktop environment. Not a development library framework. "Software Collection" at least had that still half-way in mind. Even plasma will by most people be perceived as "the desktop of KDE". Please don't misunderstand me, of course for software developers the viewpoint is a bit different, but I'm talking about users here. In the end, you will be perceived for what you release - and here we get back to this list. KDE lives from being a consistent whole. Eric Hameleers already made some very valid points there. Breaking KDE up does not help, and the coordinated releases were/are a great thing. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
Dear KDE upstream, > Since KDE is the community, how can we do a KDE 4.8? And then Platform will > call itself 5 if I understood correctly. So how do we call a new release > schedule then? I just read a very good novel where all such talk about "Software Collection" or "Platform" was aptly called "commercial bulshytt". I think many of us, including your "only-users", would appreciate it if you all there upstream would just stick to KDE, because that is what everyone uses. Nothing else. > > Are you serious that you want to decouple the release of our > > frameworks from > > each other? THat would create a huge mess, extreme amounts of > > overhead, be > > very destructive to our community... This puzzles me as I know how > > much you > > love KDE. > > What does my love for KDE have to do with it? I think it's good for KDE to > let each module set their freezes on their own, depending on which work > flow they will adapt. If we decide it early the module maintainers have > time enough to get used to creating the schedule. Basically this is nothing but a dissolution of the KDE project as a whole. Sure, we'll end up with a lot of projects using and enhancing kdelibs (or whatever becomes of that), but there will be no coherence anymore. > We can set a preferred release day twice a year, which every module can > work to if they like. > We can still package and release them if you like, that's independent of > the schedules. That both makes no sense. Suggestion 1 fails completely with the "if they like" part, since we all know already how much pain the "out of sync kdepim" caused. Suggestion 2 fails with the "independent of the schedules" part, because you can't release somthing that is not stabilized and tested. Please try to get some sense back... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: modular kdelibs: packagers' view
> As far as Exherbo is concerned, we are in favour of more modularity. Of > course, it should be thought through *before* you do it and, once decided, > be pushed through in *one* major step, not as the current git migration > (which you should finally and, if need be, forcefully push through, too) > in "baby steps". Indeed. And please ***> do not start with it <*** before finishing the git migration, thinking about and deciding on the splitting of the rest of KDE, as otherwise everything will just end up as One Uncontrollable Mess. -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
On Friday 01 April 2011 21:47:44 Dirk Mueller wrote: > I just finished uploading the first set of tarballs. BTW, the files are public on ftp.kde.org now... Intention or accident? :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
FYI, Andriy Rysin identified the problem and committed a fix. It would be great if this could still go into 4.6.2. From the bug report: --- Comment #4 From Andriy Rysin 2011-04-03 04:33:48 (-) [reply] --- Git commit 754b4aee80ef521433c8179bca122c22135f5118 by Andriy Rysin. Committed on 03/04/2011 at 04:27. Pushed by rysin into branch 'master'. Fix null pointer crash when no rules found; add unit test BUG: 269961 M +1-1kcontrol/keyboard/flags.cpp M +3-0kcontrol/keyboard/tests/flags_test.cpp http://commits.kde.org/kde-workspace/754b4aee80ef521433c8179bca122c22135f5118 On Saturday 02 April 2011 22:25:02 Andreas K. Huettel wrote: > Just as update, this problem occurs *ONLY* if the little flag for switching > keyboard layouts is activated. > > No keyboard layout switcher in kicker -> no segfaults of screenlocker. > > On Saturday 02 April 2011 20:33:43 Andreas K. Huettel wrote: > > Not a build problem, but definitely a blocker: kscreenlocker segfaults > > more or less immediately after the first keypress/mouse movement, > > leaving the screen unlocked again... > > > > Also filed now as bug 269961 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
Just as update, this problem occurs *ONLY* if the little flag for switching keyboard layouts is activated. No keyboard layout switcher in kicker -> no segfaults of screenlocker. On Saturday 02 April 2011 20:33:43 Andreas K. Huettel wrote: > Not a build problem, but definitely a blocker: kscreenlocker segfaults more > or less immediately after the first keypress/mouse movement, leaving the > screen unlocked again... > > Also filed now as bug 269961 > -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
Not a build problem, but definitely a blocker: kscreenlocker segfaults more or less immediately after the first keypress/mouse movement, leaving the screen unlocked again... Also filed now as bug 269961 Application: KDE-Bildschirmsperre (kscreenlocker), signal: Segmentation fault [KCrash Handler] #6 QString::operator== (this=0x18, other=...) at tools/qstring.cpp:2150 #7 0x7ff910173489 in qStringComparisonHelper (layout=..., variant=..., rules=0x0) at /usr/include/qt4/QtCore/qstring.h:922 #8 operator== (layout=..., variant=..., rules=0x0) at /usr/include/qt4/QtCore/qstring.h:925 #9 getDisplayText (layout=..., variant=..., rules=0x0) at /var/tmp/portage/kde- base/systemsettings-4.6.2/work/systemsettings-4.6.2/kcontrol/keyboard/flags.cpp:119 #10 0x7ff910173f5b in Flags::getLongText (layoutUnit=..., rules=0x0) at /var/tmp/portage/kde- base/systemsettings-4.6.2/work/systemsettings-4.6.2/kcontrol/keyboard/flags.cpp:127 #11 0x7ff910170277 in LayoutWidget::layoutChanged (this=0x24f7950) at /var/tmp/portage/kde- base/systemsettings-4.6.2/work/systemsettings-4.6.2/kcontrol/keyboard/layout_widget.cpp:101 #12 0x7ff910170524 in LayoutWidget::LayoutWidget (this=0x24f7950, parent=) at /var/tmp/portage/kde- base/systemsettings-4.6.2/work/systemsettings-4.6.2/kcontrol/keyboard/layout_widget.cpp:61 #13 0x7ff910170d75 in KPluginFactory::createInstance (parentWidget=, parent=, args=...) at /usr/include/kpluginfactory.h:473 #14 0x7ff921e0db50 in KPluginFactory::create (this=0x256a790, iface=0x7ff920e687c0 "QWidget", parentWidget=, parent=0x7fff6d9e9790, args=..., keyword=) at /var/tmp/portage/kde- base/kdelibs-4.6.2/work/kdelibs-4.6.2/kdecore/util/kpluginfactory.cpp:203 #15 0x0041b1e2 in create (this=0x7fff6d9e9790, parent=, plugin=, text=...) at /usr/include/KDE/../kpluginfactory.h:503 #16 PasswordDlg::PasswordDlg (this=0x7fff6d9e9790, parent=, plugin=, text=...) at /var/tmp/portage/kde- base/krunner-4.6.2/work/krunner-4.6.2/krunner/lock/lockdlg.cc:122 #17 0x004165b6 in LockProcess::checkPass (this=0x7fff6d9eaac0) at /var/tmp/portage/kde- base/krunner-4.6.2/work/krunner-4.6.2/krunner/lock/lockprocess.cc:1173 #18 0x00417945 in LockProcess::x11Event (this=0x7fff6d9eaac0, event=0x7fff6d9ea710) at /var/tmp/portage/kde- base/krunner-4.6.2/work/krunner-4.6.2/krunner/lock/lockprocess.cc:1383 #19 0x7ff922f76b6e in publicx11Event (this=, _event=0x7fff6d9ea710) at /var/tmp/portage/kde- base/kdelibs-4.6.2/work/kdelibs-4.6.2/kdeui/kernel/kapplication.cpp:918 #20 KApplication::x11EventFilter (this=, _event=0x7fff6d9ea710) at /var/tmp/portage/kde- base/kdelibs-4.6.2/work/kdelibs-4.6.2/kdeui/kernel/kapplication.cpp:969 #21 0x7ff92082698e in qt_x11EventFilter (ev=0x7fff6d9ea710) at kernel/qapplication_x11.cpp:436 #22 0x7ff920836c71 in QApplication::x11ProcessEvent (this=, event=0x7fff6d9ea710) at kernel/qapplication_x11.cpp:3276 #23 0x7ff920861df2 in x11EventSourceDispatch (s=0x2389130, callback=, user_data=) at kernel/qguieventdispatcher_glib.cpp:146 #24 0x7ff91aebeb61 in g_main_dispatch (context=0x2388e40) at gmain.c:2149 #25 g_main_context_dispatch (context=0x2388e40) at gmain.c:2702 #26 0x7ff91aec2a98 in g_main_context_iterate (context=0x2388e40, block=, dispatch=, self=) at gmain.c:2780 #27 0x7ff91aec2c4c in g_main_context_iteration (context=0x2388e40, may_block=1) at gmain.c:2843 #28 0x7ff92164a4c3 in QEventDispatcherGlib::processEvents (this=0x23845d0, flags=) at kernel/qeventdispatcher_glib.cpp:415 #29 0x7ff92086176e in QGuiEventDispatcherGlib::processEvents (this=0x18, flags=) at kernel/qguieventdispatcher_glib.cpp:204 #30 0x7ff92161d232 in QEventLoop::processEvents (this=, flags=) at kernel/qeventloop.cpp:149 #31 0x7ff92161d614 in QEventLoop::exec (this=0x7fff6d9eaa30, flags=) at kernel/qeventloop.cpp:201 #32 0x7ff92162168b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009 #33 0x004259ca in main (argc=, argv=) at /var/tmp/portage/kde- base/krunner-4.6.2/work/krunner-4.6.2/krunner/lock/main.cc:198 On Friday 01 April 2011 21:47:44 Dirk Mueller wrote: > Hi, > > I just finished uploading the first set of tarballs. > > kdegraphics probably does not build yet, but other than that, I see good > intermediate results already. > > Please report any serious issues or build failures with those tarballs to > me. > > Thanks, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
Hi, ksnapshot and kruler try to install their docs into the same nonsense directory "/usr/share/doc/HTML/en/doc", leading to file collisions. Cheers, Andreas On Friday 01 April 2011 21:47:44 Dirk Mueller wrote: > Hi, > > I just finished uploading the first set of tarballs. > > kdegraphics probably does not build yet, but other than that, I see good > intermediate results already. > > Please report any serious issues or build failures with those tarballs to > me. > > Thanks, > Dirk > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.1 tarballs (try #1) uploaded
> > Please be especially aware if anything is lost in those tarballs > > (missing) that should have been there since 4.6.0. the splitting was not > > changed so it should be a drop-in replacement. > > Hm, so where is konsole now (as it is missing from kdebase tarball) ? It seems like the layout of the kdebase tarball changed. For comparison: huettel@pinacolada ~/tmp $ ls -la kdebase-4.6.0 insgesamt 116 drwxr-xr-x 3 huettel huettel 4096 20. Jan 23:28 . drwxr-xr-x 4 huettel huettel 4096 26. Feb 18:33 .. -rw-r--r-- 1 huettel huettel 111 19. Jan 23:05 AUTHORS -rw-r--r-- 1 huettel huettel 674 19. Jan 23:05 CMakeLists.txt -rw-r--r-- 1 huettel huettel 18273 19. Jan 23:05 COPYING -rw-r--r-- 1 huettel huettel 20403 19. Jan 23:05 COPYING.DOC -rw-r--r-- 1 huettel huettel 26527 19. Jan 23:05 COPYING.LIB -rw-r--r-- 1 huettel huettel 680 19. Jan 23:05 CTestConfig.cmake -rw-r--r-- 1 huettel huettel 3999 19. Jan 23:05 KDEBaseNightly.cmake -rw-r--r-- 1 huettel huettel 5624 19. Jan 23:05 Mainpage.dox -rw-r--r-- 1 huettel huettel 8770 19. Jan 23:05 README drwxr-xr-x 15 huettel huettel 4096 20. Jan 23:27 apps huettel@pinacolada ~/tmp $ ls -la kdebase-4.6.1 insgesamt 84 drwxr-xr-x 15 huettel huettel 4096 26. Feb 10:41 . drwxr-xr-x 4 huettel huettel 4096 26. Feb 18:33 .. -rw-r--r-- 1 huettel huettel 1425 25. Feb 23:33 CMakeLists.txt -rw-r--r-- 1 huettel huettel 541 25. Feb 22:55 CTestConfig.cmake -rw-r--r-- 1 huettel huettel 367 25. Feb 22:55 ConfigureChecks.cmake -rw-r--r-- 1 huettel huettel 1289 25. Feb 22:55 Mainpage.dox -rw-r--r-- 1 huettel huettel 461 25. Feb 22:55 README -rw-r--r-- 1 huettel huettel 2671 25. Feb 22:55 config-apps.h.cmake drwxr-xr-x 7 huettel huettel 4096 25. Feb 23:33 doc drwxr-xr-x 3 huettel huettel 4096 25. Feb 22:55 dolphin drwxr-xr-x 3 huettel huettel 4096 25. Feb 22:55 kdepasswd drwxr-xr-x 2 huettel huettel 4096 25. Feb 22:55 kdialog drwxr-xr-x 3 huettel huettel 4096 25. Feb 23:33 keditbookmarks drwxr-xr-x 2 huettel huettel 4096 25. Feb 23:33 kfind drwxr-xr-x 19 huettel huettel 4096 25. Feb 23:33 konq-plugins drwxr-xr-x 12 huettel huettel 4096 25. Feb 23:33 konqueror drwxr-xr-x 5 huettel huettel 4096 25. Feb 23:33 konsole drwxr-xr-x 2 huettel huettel 4096 25. Feb 23:33 kwrite drwxr-xr-x 3 huettel huettel 4096 25. Feb 22:55 lib drwxr-xr-x 7 huettel huettel 4096 25. Feb 23:33 nsplugins drwxr-xr-x 3 huettel huettel 4096 25. Feb 22:55 plasma huettel@pinacolada ~/tmp $ Should we adapt our build scripts / ebuilds, or do you want to change the tarball so it follows the same structure as 4.6.0 ? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDEPIM 4.4.10 Planning
Distributions may want to keep the "stable" KDEPIM 4.4.* until dust has settled down a bit. So saying "final bugfix release" probably just means "you maintain from now on". Which is of course not so great... Cheers, Andreas On Thursday 13 January 2011 14:27:19 Allen Winter wrote: > Howdy, > > I think we'll make one final bugfix release for 4.4 and then we'll be done > forever with the 4.4 series. > > Target date for tagging and release is 26 January 2011, but I'm very flexible > with this date. > > If anyone has time to fix some of the more notorious bugs -- especially > regressions > that may have occurred with 4.6 kdelibs|kdepimlibs -- please don't hesitate > to do so. > > Comments? Objections? > > -Allen > ___ > Kde-packager mailing list > kde-packa...@kde.org > https://mail.kde.org/mailman/listinfo/kde-packager > -- Andreas K. Huettel Gentoo Linux developer - kde, sci, sunrise dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
