[DONE] Re: Dependency freeze exception request for kdevelop & kdev-php on kdevelop-pg-qt
Am Montag, 22. Juli 2024, 17:00:41 MESZ schrieb Heiko Becker: > On Monday, 22 July 2024 01:44:13 CEST, Albert Astals Cid wrote: > > El diumenge, 21 de juliol del 2024, a les 21:49:50 (CEST), Friedrich W. H. > > > > Kossebau va escriure: > >> Hi, > >> > >> I have to request an exception to the Gear 24.08 dependency freeze for > >> kdevelop & kdev-php: > >> > >> There is a hard dependency on a yet to be released version of > >> kdevelop-pg-qt > >> (on own release schedule, not part of Gear). ... > > > > Seems reasonable to me regarding the KDE Gear plans. > > +1 sounds like the best alternative out of the current situation. Thanks. So now have executed the plan we agreed on on #kde-devel for today: * did a release of kdevelop-pg-qt 2.3.0 (tagged, tarballs waiting for upload) * merged MRs to bump the min. required kdevelop-pg-qt to 2.3, both kdev-php but also kdevelop, for consistency and to narrow the supported combinations Cheers Friedrich
Dependency freeze exception request for kdevelop & kdev-php on kdevelop-pg-qt
Hi, I have to request an exception to the Gear 24.08 dependency freeze for kdevelop & kdev-php: There is a hard dependency on a yet to be released version of kdevelop-pg-qt (on own release schedule, not part of Gear). That sadly so far was shadowed by KDE CI setup and local installations of development versions. See https://invent.kde.org/kdevelop/kdev-php/-/merge_requests/21 for a respective dependency bump prepared for kdev-php. One for kdevelop would follow once the plan is approved. kdevelop-pg-qt 2.3 release would also happen the next days by me. Background: kdevelop (qmake plugins) & kdev-php use kdevelop-pg-qt to generate some parsing code. The currently released versions of kdevelop-pg-qt have Qt5-only code in the deployed utility headers, which are used from the generated code (e.g. QString::midRef). While kdevelop-pg-qt got prepared for Qt6 already in 2022, the release was delayed waiting for the Qt6 ports of the only known consumers kdevelop & kdev- php, for some potential synchronization of any Qt6-related changes. And by the time it had been forgotten all the released version still only are Qt5-only. Cheers Friedrich
Re: Moving KGraphViewer & Massif Visualizer to KDE Gear (-> 24.08)
Am Dienstag, 16. April 2024, 00:46:55 MESZ schrieb Friedrich W. H. Kossebau: > Hi, > > I would like to propose moving both KGraphViewer (invent.kde.org/graphics/ > kgraphviewer) & Massif Visualizer (invent.kde.org/sdk/massif-visualizer) to > the KDE Gear release bundle on next occasion. > > Both are rather stable in their feature-set and "community-maintained". > As such community maintenance, they just got finally their Qt6 port > completed and turned Qt6-only in the master branches. So after discussion the "next occasion" would be 24.08, and until then some stand-alone releases will happen (currently prepared). In case of positive decision on the proposal for Gear inclusion, prepared already some respective MRs: https://invent.kde.org/sysadmin/release-tools/-/merge_requests/49 https://invent.kde.org/sysadmin/release-tools/-/merge_requests/50 Cheers Friedrich
Re: Moving KGraphViewer & Massif Visualizer to KDE Gear
Am Dienstag, 16. April 2024, 01:02:09 MESZ schrieb Heiko Becker: > On Tuesday, 16 April 2024 00:46:55 CEST, Friedrich W. H. Kossebau wrote: > > I would like to propose moving both KGraphViewer (invent.kde.org/graphics/ > > kgraphviewer) & Massif Visualizer (invent.kde.org/sdk/massif-visualizer) > > to > > the KDE Gear release bundle on next occasion. > > > > Both are rather stable in their feature-set and "community-maintained". > > As such community maintenance, they just got finally their Qt6 > > port completed > > and turned Qt6-only in the master branches. > > > > Ideally the "next occasion" would already be KDE 24.05, if that > > would be still > > acceptable given the history of the repos. > > > > While adding more work onto the Gear release managers already now, it > > would > > save individuals (like myself) from trying to do custom > > releases work, where > > otherwise the Gear release automation could free some time to e.g. do any > > needed regression finding & fixing. > > How about a compromise: I'll do stand-alone releases for both and we have > enough time for feedback before Gear 24.08? Thanks for the offer, Heiko. "Works for me" when it comes to trying to avoid release work :P so would happily pick up that. >From a pragmatic world approach I would still think that... anyway, main motive is to get the Qt6 ports of both out next and have releases "automated"/"schedule-forced" as ensured perspective :) Even more with the bad fonts finally fixed while at it, which annoyed me for years. So in case the last-minute door to 24.05 will not open here after any more discussion, would then approach you about further steps directly, thanks again. Guess I would get serious here around end of April, for some rough planning from my side. New version numbers had already been set in the code (and also registered at bugs.kde.org), just letting current code changes sink in a bit (and be processed by the good bloody-edge consumers) before moving on :) Cheers Friedrich
Moving KGraphViewer & Massif Visualizer to KDE Gear
Hi, I would like to propose moving both KGraphViewer (invent.kde.org/graphics/ kgraphviewer) & Massif Visualizer (invent.kde.org/sdk/massif-visualizer) to the KDE Gear release bundle on next occasion. Both are rather stable in their feature-set and "community-maintained". As such community maintenance, they just got finally their Qt6 port completed and turned Qt6-only in the master branches. Ideally the "next occasion" would already be KDE 24.05, if that would be still acceptable given the history of the repos. While adding more work onto the Gear release managers already now, it would save individuals (like myself) from trying to do custom releases work, where otherwise the Gear release automation could free some time to e.g. do any needed regression finding & fixing. Cheers Friedrich
Re: Warehouse keeper game Skladnik into KDE Gear (for 24.05)
Am Freitag, 23. Februar 2024, 00:31:23 CET schrieb Albert Astals Cid: > El divendres, 23 de febrer de 2024, a les 0:29:14 (CET), Albert Astals Cid > va > escriure: > > El divendres, 16 de febrer de 2024, a les 21:47:10 (CET), Heiko Becker va > > > > escriure: > > > On Monday, 12 February 2024 18:23:15 CET, Friedrich W. H. Kossebau wrote: > > > > I propose to move Skladnik to KDE Gear for 24.05 to rejoin the set of > > > > KDE > > > > games again, which it already was part of in KDE 1-3 times (by the > > > > name > > > > KSokoban). > > > > > > > > It just passed kde(re)review, and before has seen recent releases, by > > > > some > > > > 0.5.0 last year, and this year some translations update 0,5,1. > > > > It also has just turned Qt6/KF6-only and will see a 0.5.2 release with > > > > that > > > > right after Mega6 (planning for Feb. 29th). > > > > > > > > Prepared respective MRs: > > > > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/47/diff > > > > s > > > > > > To avoid confirmation by missing objections: I'm in favour of Skladnik > > > joining Gear. > > > > My silent approval reminder was set on the 26, but i guess we can add it > > already :) > > Forgot to say, please make sure the version number is auto incrementing. > > Cheers, > Albert Thanks. Yes, patch is locally ready, will turn into MR now to keep available online for when needed. As said before, first though on Feb 29th a 0.5.2 release is planned (KF6/Qt6- only & small bits), using the non-Gear versioning still. Cheers Friedrich
Warehouse keeper game Skladnik into KDE Gear (for 24.05)
Hi, I propose to move Skladnik to KDE Gear for 24.05 to rejoin the set of KDE games again, which it already was part of in KDE 1-3 times (by the name KSokoban). It just passed kde(re)review, and before has seen recent releases, by some 0.5.0 last year, and this year some translations update 0,5,1. It also has just turned Qt6/KF6-only and will see a 0.5.2 release with that right after Mega6 (planning for Feb. 29th). Prepared respective MRs: https://invent.kde.org/sysadmin/release-tools/-/merge_requests/47/diffs For some history and more info about this game, see last release announcement https://mail.kde.org/pipermail/kde-announce-apps/2024-January/005782.html Cheers Friedrich
Respin request for K18n (was: Re: KDE Frameworks 5.115.0)
Hi David, Am Samstag, 3. Februar 2024, 16:49:11 CET schrieb David Faure: > Dear packagers, > > KDE Frameworks 5.115.0 has been uploaded to the usual place. Could you please respin Ki18n with this commit that unbreaks KCountrySubdivision with newest iso-codes 4.16? Upstream incompatible data scheme change, only discovered now, and that version is already out there in the wilds with many rolling release distributions. https://invent.kde.org/frameworks/ki18n/-/commit/ 3327283e921627368b4545551d8d6443e24ef897 Cheers Friedrich
Re: Collection of packaging notes
Am Mittwoch, 1. November 2023, 13:30:03 CET schrieb Jonathan Riddell: > One quick question, is naming non-frameworks libKF6foo really a problem we > need to fix? Given all the other issues... What is in a name... usually some semantics. We could also call random libraries libdsafwef or libPlasmaFoo (while unrelated to Plasma), would that be a good idea? If not, then why not fix any misnaming while we change names anyway. Cheers Friedrich
KDE Gear "6.0" status update: all 40 games & 2 libs now Qt6-only in master
Hi, just a quick heads-up to keep more people in the loop: all the 40 game apps & 2 game libs covered by KDE Gear starting today are now Qt6-only in their master branches. And thus can/will be released based on Qt6/ KF6 in the KDE Gear "6.0" 24.02 release. So the section "Games" can be checked off WRT Qt6 porting for KDE Gear. For libkdegames I plan to use the window of opportunity with API/ABI changes to consolidate some things, e.g. * Rename Kg* classes to KGame*, to iron out some historic artifacts https://invent.kde.org/games/libkdegames/-/merge_requests/30 * Split-off QWidgets API into separate library, to prepare more QML work in the years to come Cheers Friedrich
Re: KDE Frameworks 5.109.0 (KWayland build break on QMetaType::Bool): MR merged
Am Mittwoch, 9. August 2023, 13:44:47 CEST schrieb Friedrich W. H. Kossebau: > Am Mittwoch, 9. August 2023, 12:21:23 CEST schrieb Friedrich W. H. Kossebau: > > Am Mittwoch, 9. August 2023, 10:31:23 CEST schrieb Christophe Marin: > > > On samedi 5 août 2023 16:52:45 CEST David Faure wrote: > > > > Dear packagers, > > > > > > > > KDE Frameworks 5.109.0 has been uploaded to the usual place. > > > > > > > > Public release next Saturday. > > > > > > > > Thanks for the packaging work! > > > > > > kwayland fails to build on stable openSUSE releases: > -> > https://invent.kde.org/frameworks/kwayland/-/merge_requests/102 up for > comments. Now in. So, David, could you please add https://invent.kde.org/frameworks/kwayland/-/ commit/75b8e91df8eaacffdf21a6154a6d20b20e1f1fd3 to KWayland 5.109 release? Thanks Friedrich
Re: KDE Frameworks 5.109.0 (KWayland build break on QMetaType::Bool): MR up
Am Mittwoch, 9. August 2023, 12:21:23 CEST schrieb Friedrich W. H. Kossebau: > Am Mittwoch, 9. August 2023, 10:31:23 CEST schrieb Christophe Marin: > > On samedi 5 août 2023 16:52:45 CEST David Faure wrote: > > > Dear packagers, > > > > > > KDE Frameworks 5.109.0 has been uploaded to the usual place. > > > > > > Public release next Saturday. > > > > > > Thanks for the packaging work! > > > > kwayland fails to build on stable openSUSE releases: -> https://invent.kde.org/frameworks/kwayland/-/merge_requests/102 up for comments. Cheers Friedrich
Re: KDE Frameworks 5.109.0
Am Mittwoch, 9. August 2023, 10:31:23 CEST schrieb Christophe Marin: > On samedi 5 août 2023 16:52:45 CEST David Faure wrote: > > Dear packagers, > > > > KDE Frameworks 5.109.0 has been uploaded to the usual place. > > > > Public release next Saturday. > > > > Thanks for the packaging work! > > kwayland fails to build on stable openSUSE releases: > > from /home/abuild/rpmbuild/BUILD/kwayland-5.109.0/src/server/display.cpp:57: > /home/abuild/rpmbuild/BUILD/kwayland-5.109.0/build/src/server/ > KF5WaylandServer_autogen/include/moc_display.cpp:81:33: error: expected > unqualified-id before 'int' > QMetaType::Void, QMetaType::Bool,2, > ^ > /home/abuild/rpmbuild/BUILD/kwayland-5.109.0/build/src/server/ > KF5WaylandServer_autogen/include/moc_display.cpp:81:33: error: expected '}' > before 'int' > In file included from > /home/abuild/rpmbuild/BUILD/kwayland-5.109.0/src/server/ display.cpp:729:0: > /home/abuild/rpmbuild/BUILD/kwayland-5.109.0/build/src/server/ > KF5WaylandServer_autogen/include/moc_display.cpp:98:1: error: expected > declaration before '}' token > }; Such failures had been seen when the notorious X headers with its "#define Bool int" had been pulled in by something before. A tad surprising of X headers are used with KWayland though :P Sorry for the breakage, had hoped anyone would catch any issues in the 4 weeks before 5.109 tagging. Not sure how to best approach this: find the offender in openSUSE Leap which pulls in the X headers (assuming they are the cause here as well) or just do a general fix in display.cpp. Given so far no-one seems to have ran into the issue on KDE CI & elsewhere, would prefer to see if that can be handled Leap- side? Talking to krop on #opensuse-kde ATM. Cheers Friedrich
Re: KDE Gear 22.08.0: respin request for ksudoku
Am Mittwoch, 17. August 2022, 23:02:11 CEST schrieb Albert Astals Cid: > El dimecres, 17 d’agost de 2022, a les 12:50:05 (CEST), Friedrich W. H. > > Kossebau va escriure: > > Hi, > > > > there was a last-minute bug report about ksudoku being unusable due to > > broken theme data loading on systems with symlinks in system data dirs. > > Handled by a last-minute fix 8) > > > > So please include this commit with the 22.08.0 tarball of ksudoku: > > https://invent.kde.org/games/ksudoku/-/commit/ > > fc9adcdd5eb843bc3024aa71787ea5de5950a14d > > tarball file updated > > ksudoku > branch > release/22.08 > git commit > fc9adcdd5eb843bc3024aa71787ea5de5950a14d > sha256sum > 903a9ba60a4ee5ab9ac1da92a156e6be1edfa9a0e171ed9eaf99c415e6ce7b6e Thanks, for this and the other one, Albert. Cheers Friedrich
KDE Gear 22.08.0: respin request for kigo
Found one other with that broken bad theme id handling: Please include this commit with the 22.08.0 tarball of kigo: https://invent.kde.org/games/kigo/-/commit/ af9a37d8fc1cd5a8ea4f1c1120063e11a1c924c8 Cheers Friedrich
KDE Gear 22.08.0: respin request for ksudoku
Hi, there was a last-minute bug report about ksudoku being unusable due to broken theme data loading on systems with symlinks in system data dirs. Handled by a last-minute fix 8) So please include this commit with the 22.08.0 tarball of ksudoku: https://invent.kde.org/games/ksudoku/-/commit/ fc9adcdd5eb843bc3024aa71787ea5de5950a14d (currently checking all other games if they also need such a fix-up, but might be the only one) The bug actually was triggered by a systematic issue in libkdegames, which screws up the theme id config entry on such systems, resulting in a reset to the default on next start. Not critical, but in case you are interested, a related MR waits for more review and testing :) https://invent.kde.org/games/libkdegames/-/merge_requests/20 Cheers Friedrich
KIO 5.91respin to consider, MR still open
Hi, there is a regression in ApplicationLauncherJob when starting DBusActivatable services with URLs, those are lost when activating/launching the app currently. Which would be a regression to before, when the apps was simply directly launched as new process, but with the URLs arguments. As a hotfix there is currently only a MR around (review needed): https://invent.kde.org/frameworks/kio/-/merge_requests/752 Thanks for all the release work, sadly also with extra hours now. Cheers Friedrich PS: Just in case that got unnoticed, there would be also a request for a knewstuff 5.91 respin, see https://marc.info/?l=kde-frameworks-devel&m=164445401017044&w=2
Re: Including KDevelop in KDE Gear (for 21.12)
Am Samstag, 30. Oktober 2021, 07:08:13 CEST schrieb Friedrich W. H. Kossebau: > Am Samstag, 30. Oktober 2021, 00:35:59 CEST schrieb Albert Astals Cid: > > What's the story with kdevelop-pg-qt? > > kdevelop-pg-qt has been released on its own separate schedule. Being a > rather feature-complete tool and only used for the soon to be legacy qmake > plugin support in KDevelop, there is no need for changes there. (now you see I myself only build kdevelop repeatedly, not the PHP support plugin, because no web dev, and my pre-morning-coffee grep skills suck) And also used for kdev-php. Still, no need for continuous releases of kdevelop-pg-qt. Cheers Friedrich
Re: Including KDevelop in KDE Gear (for 21.12)
Am Samstag, 30. Oktober 2021, 00:35:59 CEST schrieb Albert Astals Cid: > What's the story with kdevelop-pg-qt? kdevelop-pg-qt has been released on its own separate schedule. Being a rather feature-complete tool and only used for the soon to be legacy qmake plugin support in KDevelop, there is no need for changes there. > What's the plan for auto-increasing version numbers on release? So far the prepared fallback plan is to use own major & minor version and for the patchlevel use the calculated "compact release service version number" (doing a 2-digit padding for the micro number though to ensure ever increasing numbers also with KDE Gear Beta & RC versions). There is on-going discussion/tinkering to find a way for nicer patchlevel numbers, or perhaps just switch completely to KDE Gear version and find some other way to describe plugin ABI/API version. No promising candidates for now, so either we sort something out in time latest for 21.12 RC, or just stick with the fallback plan for the time being. You might be referring to my considerations on #kde-sysadmin about a new ever- increasing KDE Gear release version number variable to e.g. derive a patchlevel from by an offset. That is for now back to the drawing board (TODO section, >= y 2022), needs more thought and also investigations into the use cases of other plugin API providing products in KDE Gear, to have a proper generic solution one day. Cheers Friedrich
Re: Including KDevelop in KDE Gear (for 21.12)
Am Freitag, 29. Oktober 2021, 21:33:00 CEST schrieb Jonathan Riddell: > KDevelop did used to be part of the KDE SC releases and at some point > separated. So one query is why did that release schedule separation happen This must have been before my active involvement with KDevelop, so perhaps Aleix, Milian or someone else around that time can tell? Though are you sure about your memories? Would not match mine, IIRC at least post-KDE3 KDevelop always was its own group, never was part of the SC bundle. Any chance you mixed this up with Okteta, seeing my name? > and would it happen again? No plans known by the current contributors. Cheers Friedrich
Including KDevelop in KDE Gear (for 21.12)
Hi, we would like to switch KDevelop from its own release schedule to KDE Gear, starting with 21.12. This includes the following repositories: * https://invent.kde.org/kdevelop/kdevelop * https://invent.kde.org/kdevelop/kdev-python * https://invent.kde.org/kdevelop/kdev-php This switch to have schedule finding and basic release work provided by the good release team workers is to deal with current KDevelop contributors rather looking at writing code than planning releases, and should then restore a continuous stream of fixes and improvements to the users. And with some packagers also help with reaction time on new releases, as they now can plan for the whole year. While KDevelop and the Python & PHP support plugins should be rather mature, please still given them a quick sanity check whether the KDevelop bubble has not developed too far from what could be considered standard in other KDE Gear apps. Cheers Friedrich
Re: KDE Gear and hotfix releases, how to see whether a user has the hotfix?
Am Montag, 25. Oktober 2021, 22:50:22 CEST schrieb Heiko Becker: > On Monday, 25 October 2021 01:57:58 CEST, Friedrich W. H. Kossebau wrote: > > CAN WE HAVE KDE GEAR DO INDIVIDUAL AND VERSIONED HOTFIX RELEASES? > > > > So ideally KDE Gear has an option to do intermediate hotfix releases of > > individual software as well, with proper identifier in the version. > > > > Two challenges I see: > > a) a simple way to run the KDE Gear scripts for an individual package > > There is, to some degree, at least to create a single tarball. That's how > respins are handled. > > > b) have an extended KDE Gear version scheme, to be able to denote any > > additional hotfix releases (e.g. for tag, package name, UI version > > strings). > I haven't actually looked and tested if any of the tooling would break with > the next scheduled release, but assuming the version is changed manually > for the hotfix release, I don't see why we couldn't have yy.mm.[0-3]a (and > b, c,..) if needed. I will see to come up with some example of such a need, and then would play around to see what is needed, by using what I find in https://invent.kde.org/ sysadmin/release-tools. Should come up with a related phabricator task to develop this into a solution. Ideally that should also yield some documentation which then could be used by people who need an emergency release. Cheers Friedrich
Re: KDE Gear and hotfix releases, how to see whether a user has the hotfix?
Am Dienstag, 26. Oktober 2021, 01:00:23 CEST schrieb Albert Astals Cid: > El dilluns, 25 d’octubre de 2021, a les 1:57:58 (CEST), Friedrich W. H. Kossebau va escriure: > > E.g. how can users & developers later know in > > a consistent way if an instance of the software really has the hotfix, or > > if some issue seen by the user has another cause? > > You can never 100 % trust that a package from a distribution is 100% the > code upstream, every distribution is more or less liberal with having > patches (and rightfully so, i'm not saying it's a bad practice, I mean we > literally ask them to do so :D). Yes, that what I referred to by the "(at least when it comes to the hotfix)" earlier, assuming they usually would not wipe out again any fixes :) But then, distributions are called "distributions" because most of the time they surely favour being able to package sources 1:1 without having to do any patching :) ((For everyone else making use of the FLOSS nature and heavily patch things, we would want to have users of that also deal with that distribution/operating system for that fork instead of upstream.)) > But I would like to say: > * We've seem to be doing quite well without needing this for "almost > decades" Quite well, unless one from a developer POV had to spend time in discussiog bug reports with users to find if they are using packages which have patch x or y already applied (and help them how to find out). And users time/energy wasted in such discussions also sad. > * I fear that the possibility of "endless re-rolls" may make > people test/review code less because "we can always re-roll the package if > it breaks" Same fear here, though then I think people are already shaming themselves enough now when having to ask for distributions adding patches, so I would think the same applies for having to ask for extra releases. Something to watch for in any case to not becoming a habit and approaching the cause, if so. Then the use-cases I had in mind were less bad developers on our side, but rather emergencies triggered externally: * a dependency changes behaviour in a new version, with severe effects in our software * a security flaw gets published So things which are not/less in our control, yet need instant handling. And some mean to denote the very version that has a fix, so end-to-end communication (user <-> developers) is simple. Same like having a system to extinct fires :) We do not want fires, but we know they can happen in accidents, so we better have something prepared to handle it when needed. > * If we would be going to be doing this, I would personally > prefer if the person that made that code mistake is the responsible for > rolling out the packages and not the release engineer (that is Heiko for > the most part). Doing a release every month is already quite some work. Agreed, would be better to have people take responsibility and not live off the free work from others in such cases, that should help in case of own slacking earlier. Even more when main release workers are not around, but things need to be handled soonish. Cheers Friedrich
KDE Gear and hotfix releases, how to see whether a user has the hotfix?
Hi, (distributions as CC: as they are stakeholders on the matter) while discussing a potential move to KDE Gear (or rather, the great automatic Release service part), the question came up how cases of urgent fixes are handled, especially when it comes to identifying products at users whether they have a respectively fixed version. USE CASE: the application Foo gets released as version 2.1.3. A day after release a security issue is found. A hotfix is quickly written and pushed to the repository. The patch-level version is bumped, new release is done the same day. The version number in the tarball name, the one of the packages created by distributions and the one displayed by the application at runtime all properly tell whether this is a version with the hotfix or not. So both users and developers know they talk about the same variant of the software (at least when it comes to the hotfix). KDE GEAR: BREAKING EXPECTATIONS If Foo was to released with KDE Gear, the same experience should be possible. Right now though this seems not easily possible, due to the strict scheme in the schedule as well as the version data used. ASKING DISTRIBUTIONS TO JUST PATCH? It seems a practice is post-release to simply ping the distributions on the distributions ML, point them to a commit to apply as patch and be done. But does that work good enough? E.g. how can users & developers later know in a consistent way if an instance of the software really has the hotfix, or if some issue seen by the user has another cause? Digging into distribution-specific packaging to find which patches are applied is not considered a sensible solution not only by me. Also might distributions/packagers fancy real source tarballs w/ matching tags over adding custom patches in the package specs. WAITING WEEKS FOR NEXT SCHEDULED RELEASE? Alternatively waiting up to a full month until the next patch release gets out in such cases also seems not user-friendly (and not developer-friendly, when they have to face the issue reports of users as result in the meantime). CAN WE HAVE KDE GEAR DO INDIVIDUAL AND VERSIONED HOTFIX RELEASES? So ideally KDE Gear has an option to do intermediate hotfix releases of individual software as well, with proper identifier in the version. Two challenges I see: a) a simple way to run the KDE Gear scripts for an individual package b) have an extended KDE Gear version scheme, to be able to denote any additional hotfix releases (e.g. for tag, package name, UI version strings). I know this will make things more complicated for KDE Gear. But it makes more things easier at other places later. And once in place, it hopefully should not cost more. Should be in bed now, but sending off to trigger your initial reactions and thoughts and comments. More from me later the week. Cheers Friedrich
Re: Fwd: Last Minute Dolphin Merge
Am Freitag, 6. August 2021, 02:18:20 CEST schrieb Nate Graham: > I know we didn't get our ducks in a row earlier, and I apologize for > that, but > I feel very strongly that this needs to go into 21.08. If it does not, > then we're shipping a controversial behavior change to users in 21.08 > with no way to go back to the previous behavior. > > May I CC you all on the bug reports we're bound to receive? :p Such threatening does not serve anything, even more when before seemingly knowingly ignoring rules like feature freeze and string freeze. Rules are for everyone, there are no developers more equal than others in our code farm hopefully. Instead I proppse to set the default config flag to match the old behaviour. If that is not possible, it has to be hard-coded then. There is always a next feazzre release a few months later thanks to release service. Rushing things in last minute and breaking the rules harms the rules and quality of the products. Let#s leave that to bad companies. Cheers Friedrich
Proposal: noting (rough) branching date in Gear schedule
Hi, TL;DR Let's document the rough date for branching in the Gear schedule, so it's less a surprise and can be planned with. Other than Plasma and KDE Frameworks, with KDE Gear the branching on a new main release does not happen the same day as the Beta tagging, but some time before, given the amount of work involved with the big amount of repos which needs a bigger time window, where those doing the work cannot easily be sure to be able to do that on a certain day when the schedule is planned and agreed on months/weeks before. Right now the schedule simply omits any mention of the branching (cmp. e.g. https://community.kde.org/Schedules/KDE_Gear_21.08_Schedule). And I might not be the only one who is caught by surprise every time :) because one forgot what happened 3 months before and also mixes things up with how Plasma & KF do it. And as by tendency one usually has some MRs around which should get in before feature freeze setting in, the branching can get in the way, despite the information being given post-branching usually by email and blog post (E_NOTREADMLANDPLANETINTIME). As Albert and Heiko, as just discussed on irc, think they should be able to at least commit to planning the branching between dependency freeze and Beta tagging, I hereby propose to have the rough branching date officially documented in the schedule from now on. Cheers Friedrich
Re: Request for crash-fixing KDNSSD 5.79.1 (was: Re: KDE Frameworks 5.79.0)
Am Montag, 15. Februar 2021, 22:50:24 CET schrieb David Faure: > On lundi 15 février 2021 19:07:14 CET Friedrich W. H. Kossebau wrote: > > David, can you please do a 5.79.1 KDNSSD release with that commit cherry- > > picked? Given this crash is happening during startup of some apps, so one > > cannot even disable zeroconf usage in the UI as temporary workaround where > > possible, it is a rather grave experience for those affected. > > Done: > > kdnssd v5.79.1 > f4a4b9be96e416ef9bbf0475f4bc861085abd137 > 9716aeed43b794948a78444ea645ba14f24f13395d410a78a68b1f8428f51898 > sources/kdnssd-5.79.1.tar.xz Merci Friedrich
Request for crash-fixing KDNSSD 5.79.1 (was: Re: KDE Frameworks 5.79.0)
Am Samstag, 6. Februar 2021, 14:15:27 CET schrieb David Faure: > Dear packagers, > > KDE Frameworks 5.79.0 has been uploaded to the usual place. > > New frameworks: none this time. I introduced a regression in KDNSSD for 5.79.0 which results in crashes on startup or whenever zeroconf activation happens, reportedly at least for knotes, ktorrent & kfourinline, but surely also any other KDNSSD-using application, due to a bad pointer casting in central classes. See https://bugs.kde.org/show_bug.cgi?id=432949 Commit 8c14803908a2a718fa0716fb98506aebda1fed46 fixes that, with first confirmations, by reverting the cause which was a change from static_cast to (macro-blurred, but no real excuse) reinterpret_cast. See https://invent.kde.org/frameworks/kdnssd/-/merge_requests/3 David, can you please do a 5.79.1 KDNSSD release with that commit cherry- picked? Given this crash is happening during startup of some apps, so one cannot even disable zeroconf usage in the UI as temporary workaround where possible, it is a rather grave experience for those affected. Cheers Friedrich
Include Konversation in Release Service for 20.12
Dear Release Service team, I would like to ask for the inclusion of Konversation in the Release Service automation. Konversation had lost active release management two years ago, as life shifts things. Yet small fixes and improvements have been getting into the repository all the time, and of course it would be good to have those flushed out to users in a timely manner. Even more as long as IRC is still a thing for some ;) While I stepped in in the last weeks to do some manual releases 1.7.6 & 1.7.7 after the 2 years release pausing to give the current stable branch some release care and signs of vitality, I do not have resources planned to continue to do so, same for the other occasional Konversation contributors. So as discussed on the mailinglist in September (see https://mail.kde.org/ pipermail/konversation-devel/2020-September/007074.html) Konversation would be candidate for getting releases cared for by the Release Service team now, please :) Current master branch should be fairly up-to-date to modern coding standards, e.g. no usage of deprecated API of Qt < 5.15 or of latest KF, also using SPDX- compatible license headers as well as Qt's categorized logging now. So it's not some old body of legacy code kept on life care, but some brushed- over well-working software with a stable feature base with moderate size of open bug reports :) Please see for the current code here and give it a quick check for things if it meets everything that it should for being covered by Release Service: https://invent.kde.org/network/konversation For the version schema, current proposal is up at https://invent.kde.org/network/konversation/-/merge_requests/24 Cheers Friedrich
Include markdownpart in Release Service for 20.12
Hi, As you might remember, markdownpart is a(nother) Markdown viewer KParts plugin, which allows KParts-using software to display files in Markdown format in the rendered target format. It mainly is a wrapper around the abilities of QTextDocument's Markdown support introduced with Qt 5.14. Example users of it are Ark, Krusader, Kate's preview plugin & Konqueror. See it being used with Kate's preview plugin here: https://cdn.kde.org/screenshots/markdownpart/markdownpart.png markdownpart passed kdereview this August, and after the small detour into the domain of self-managed releases for some quick feedback-based turn-around as potentially useful, with though just one release done (0.1.1), I would like to ask now for the originally planned inclusion of markdownpart into the Release Service starting with 20.12. It would then be a similar position as the graphics/svgpart project. See also summary email of kdereview phase in August this year: https://marc.info/?l=kde-release-team&m=159822183205198&w=2 Once included I would push a respective commit to make use of the RELEASE_SERVICE_* version variables. For reference, the project is located at https://invent.kde.org/utilities/markdownpart Cheers Friedrich
[DONE] Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
Hi, Am Samstag, 15. August 2020, 19:20:53 CEST schrieb Friedrich W. H. Kossebau: > what is markdownpart you ask? A KParts plugin allowing to view markdown > documents rendered e.g. in Kate's preview plugin, Ark, Krusader or > Konqueror, being mainly a wrapper around QTextDocument::setMarkdown & > QTextBrowser. See here it being used with Kate's preview plugin: > https://cdn.kde.org/screenshots/markdownpart/markdownpart.png > Note (edit: updated): Qt 5.14 minimum needed > > I would like to propose markdownpart for a move into community maintenance > mode and becoming part of release service managed projects starting with RS > 20.12. It would match graphics/svgpart in the mode (whose code mode BTW is > aöso similar, mainly a wrapper around QSvgRenderer & QGraphicsView). Am Montag, 24. August 2020, 00:30:13 CEST schrieb Friedrich W. H. Kossebau: > Small plan change here: > given 20.12 is quite some weeks away still, markdownpart should move post- > kdereview first into extragear, for one or two releases with the initial > feedback added and especially translations, and only then enter release > service latest in November before the repo freeze. Thanks everyone for their review & comments. Without any open objections or todos, I am now executing the sketchecd plan: * move markdownpart into extragear/utils today * do official string freeze on trunk today * do a 0.1.1 release on Monday, September 21st from trunk (so translators have 3 weeks occasion to add support for their locale) * move into release service set before November (waiting a bit after 0.1.1 in chance bugs are reported which should be fixed in a release before 20.12) Cheers Friedrich
Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
Am Samstag, 15. August 2020, 19:20:53 CEST schrieb Friedrich W. H. Kossebau: > Note: for now Qt 5.15-only, 5.14 possible but untested. BTW, thanks to feedback the min dependencies are now lowered to Qt 5.14 & KF 5.66. > I would like to propose markdownpart for a move into community maintenance > mode and becoming part of release service managed projects starting with RS > 20.12. It would match graphics/svgpart in the mode (whose code mode BTW is > aöso similar, mainly a wrapper around QSvgRenderer & QGraphicsView). Small plan change here: given 20.12 is quite some weeks away still, markdownpart should move post- kdereview first into extragear, for one or two releases with the initial feedback added and especially translations, and only then enter release service latest in November before the repo freeze. Makes sense? Otherwise thanks for review & feedback so far. Seems there have no obstacles come up so far, so upcoming Saturday markdownpart can then leave the current stage, and would go to extragear/utils, right into preparation of first full release. Cheers Friedrich
Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
Am Freitag, 21. August 2020, 23:34:03 CEST schrieb Albert Astals Cid: > El dilluns, 17 d’agost de 2020, a les 23:04:44 CEST, Friedrich W. H. Kossebau va escriure: > > But not my call, after all I offer this to KDE community for adoption, sou > > your choice. > > I'm a bit concerned about this being "abandonware" from birth, but seems > there's relative interest from the community to collectively maintain it so > not going to complain if this ends up in release service. Thanks for statement, Albert. Cheers Friedrich
Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
Hi Elvis, Am Montag, 17. August 2020, 22:43:37 CEST schrieb Elvis Angelaccio: > On 15/08/20 19:20, Friedrich W. H. Kossebau wrote: > > Hi, > > > > what is markdownpart you ask? A KParts plugin allowing to view markdown > > documents rendered e.g. in Kate's preview plugin, Ark, Krusader or > > Konqueror, being mainly a wrapper around QTextDocument::setMarkdown & > > QTextBrowser. See here it being used with Kate's preview plugin: > > https://cdn.kde.org/screenshots/markdownpart/markdownpart.png > > Note: for now Qt 5.15-only, 5.14 possible but untested. > > > > I would like to propose markdownpart for a move into community maintenance > > mode and becoming part of release service > > Hi Friedrich, > > why not merge this plugin into kate instead? Let me answer with another question: why with Kate and not with Ark or with Krusader or with Konqueror or any other potential KParts plugin user where Markdown viewing often is useful? Bundling with Kate would be a rather random choice IMHO. And a) make it challenging for packagers to split out an independent packager for the markdown kpart with all the files belonging to it b) make it harder for anyone interested in hacking on it, as they would have to also care about the whole Kate repo and its complete build system, when they just want to improve the markdown viewer e.g. for Ark. But not my call, after all I offer this to KDE community for adoption, sou your choice. Cheers Friedrich
KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
Hi, what is markdownpart you ask? A KParts plugin allowing to view markdown documents rendered e.g. in Kate's preview plugin, Ark, Krusader or Konqueror, being mainly a wrapper around QTextDocument::setMarkdown & QTextBrowser. See here it being used with Kate's preview plugin: https://cdn.kde.org/screenshots/markdownpart/markdownpart.png Note: for now Qt 5.15-only, 5.14 possible but untested. I would like to propose markdownpart for a move into community maintenance mode and becoming part of release service managed projects starting with RS 20.12. It would match graphics/svgpart in the mode (whose code mode BTW is aöso similar, mainly a wrapper around QSvgRenderer & QGraphicsView). The code lives at https://invent.kde.org/utilities/markdownpart since yesterday. I consider the project stable & done already though, given there are no more features I want myself and given it is based on existing code: mainly a copy of KMarkdownWebView, which itself was inspired/driven by e.g. KWebKit/ KWebEngine KParts code. Some small glitches are with the search tool and incremental search sometimes, but that might be a bug in QTextDocument/QTextBrowser. I have written this plugin mainly because "I could :P" and some people might like it, less because I want to use this myself everyday (personally dislike Markdown). So I would be interested to pass maintenance over into community domain, or interested individuals if there are. Otherwise it would be a candidate for the attic. Today I released a first 0.1.0 version to make it spread and find users who fancy it: https://mail.kde.org/pipermail/kde-announce-apps/2020-August/005597.html Try yourself by building and installing with "kdesrc-build markdownpart" and picking "Markdown View (markdownpart)" as preferred embedding plugin for "text/markdown" in System Settings' File Associations submodule (part of "Applications"). So I hereby move markdownpart into kdereview mode. Please give the code some eyeball times and comment for good and bad or missing stuff and whether you agree if this should become part of KDE community-managed set of software. Also hoping to see someone offering themselves to adopt this project as caring maintainer. BACKGROUND You might know the KParts plugin from KMarkdownWebView for the same purpose (https://invent.kde.org/utilities/kmarkdownwebview). It had been written 3 years ago as quick&dirty solution, with an important statement in the README: "The software should serve as intermediate solution until some native Qt-based implementation is done." While there has been some native variant present meanwhile via the Okular Markdown support for some time, and available via the Okular KParts plugin, the paged display of Okular might not meet the desire of some to see the Markdown document rendered as single adaptive page. With QTextDocument having gotten some native markdown-parsing support in Qt 5.14, some recent discussion about whether to include KMarkdownWebView (and the QWeb* dependencies it brings) into Kate app bundles for the preview feature triggered me to give it a try to write a QTextDocument-based variant. Which turned out to be simple to do in an evening, and so here we are. Cheers Friedrich
Re: Dropping libkgeomap from release service 20.12 - was - Re: libkgeomap
Am Samstag, 8. August 2020, 00:41:27 CEST schrieb Albert Astals Cid: > This needs to go to release-team which is where the dropping/adding stuff is > discussed. > > Sending there. > > Friedrich, you're the lastest one that did changes, even they are mostly > gardening ones. What's your opinion? No objections to move this to the attics for unused/unmaintained stuff. I would have proposed this myself even before (when some weeks ago I did a walk over of all libs to make them appear on api.kde.org using kapidox), but still saw it used by kphotoalbum IIRC. If that is gone now, and lxr.kde.org tells me as of now nothing does have the string "kgeomap" in a CMakeLists.txt file anymore both in unstable & stable branches besides the lib sources itself, here my +1 for that move. Cheers Friedrich
Deprecation hickup in KParts part.h needs fix (Re: KDE Frameworks 5.72.0)
Hi David, Am Samstag, 4. Juli 2020, 19:47:21 CEST schrieb David Faure: > Dear packagers, > > KDE Frameworks 5.72.0 has been uploaded to the usual place. > > New framework: KDAV. > > Public release next Saturday. > > Thanks for the packaging work! Please pick up 720e5946a1e9c11fc2fdab25d6493f64c80247e4 for KParts, it fixes a mismatch of deprecation wrapping. Cheers Friedrich
Re: Request for ktexteditor patch release
Am Freitag, 15. Mai 2020, 12:03:08 CEST schrieb David Faure: > On vendredi 15 mai 2020 11:01:04 CEST Friedrich W. H. Kossebau wrote: > > Hi, > > > > I would like to ask for a 5.70 patch release for ktexteditor, with > > 972da14f486a83556e192d09bb18a2500728895a cherry-picked. > > > > Not a crasher, but preventing the pickup of any global view setting > > changes > > after a kate/kdevelop session close & open cycle for existing document > > views, which has been hit and reported by a few people already the last > > days. > > Thanks for the notification. Done: > > ktexteditor v5.70.1 > 5e6ea19f95a36e21473c00a8d30cbea0f150a13f > c7b568e75c147161992f8875fe36fb46885bccddb63c22edaf81071583f4204c > sources/ktexteditor-5.70.1.tar.xz Merci. > Please add a description of the bug in www/info/kde-frameworks-5.70.0.php > (or give me a patch if you can't push). No checkout of the respective repo, so possibly fastest if I give you the raw data here: * KTextEditor global view setting changes ignored after session reopening (Kate, KDevelop) https://bugs.kde.org/show_bug.cgi?id=421375 > Also, please make sure to write a unittest for this regression so we catch > it next time. Yup. Cheers Friedrich
Request for ktexteditor patch release
Hi, I would like to ask for a 5.70 patch release for ktexteditor, with 972da14f486a83556e192d09bb18a2500728895a cherry-picked. Not a crasher, but preventing the pickup of any global view setting changes after a kate/kdevelop session close & open cycle for existing document views, which has been hit and reported by a few people already the last days. Cheers Friedrich
[FIXED] Re: calligra/3.2 branch not yet pushed/created?
Am Freitag, 24. April 2020, 13:40:24 CEST schrieb Dag: > On 24-04-2020 13:19, Friedrich W. H. Kossebau wrote: > > Hi Dag, > > > > congrats for another release. > > > > One question though: > > I see you updated kde-build-metdata & repo-metadata to set > > "calligra/3.2" as > > new stable branch. > > > > Just: there is no such branch yet pushed to the central calligra repo > > it > > seems? Any chance you forgot that? > > Thanks, never do branches anymore so messed it up, > hopefully ok this time. Yes, looks good, CI now currently working through new builds of calligra stable using the calligra/3.2 branch :) Cheers Friedrich
calligra/3.2 branch not yet pushed/created? (was: Re: Calligra stable version 3.2.0 released)
Hi Dag, congrats for another release. One question though: I see you updated kde-build-metdata & repo-metadata to set "calligra/3.2" as new stable branch. Just: there is no such branch yet pushed to the central calligra repo it seems? Any chance you forgot that? I noticed because I wanted to help out with having KDE CI adapt to the new branch (as currently KDE CI needs some manual help each branching time, sadly unknown/forgotten by most release managers), and now see the stable calligra build failing, due to no branch found. BTW, as release manager of a product you want to make sure you can do the KDE CI care yourself, by requesting the needed "Start build" rights from KDE admin (do from https://phabricator.kde.org/tag/build.kde.org/) and then on branching follow the guidelines given at https://community.kde.org/ReleasingSoftware#Branching which links to https://community.kde.org/Infrastructure/ Continuous_Integration_System#Updating_builds_on_switching_the_.22stable. 22_branch Cheers Friedrich
Re: 2 kirigami fixes for a point release
Am Dienstag, 18. Februar 2020, 04:03:05 CET schrieb Nate Graham: > On 2020-02-16 14:43, Albert Astals Cid wrote: > > Maybe i explain myself wrongly, i'm not blaming distros at all. > > > > They made a decision, we/I may agree with them or not, that's *my/our* > > problem, what I was disagreeing is to us having to do extra work because > > someone elses (the distros) decision. > We already do this: it's called the Plasma LTS product. :-) It's been > specifically created to cater to various distros' desires for an > extended-support product they can ship to users of their own LTS releases. > > However all the autotests in the world will not resolve the fundamental > incompatibility between the Plasma LTS product, which is built around > the release model of extended, ongoing bugfix releases, and Frameworks, > which is built around a rolling release model with no bugfix releases at > all. For one, distribution seem to be just fine with that. And it should be them to complain if they cannot make use of Plasma LTS to create a product endorsed by their distribution/operating system flavour users. Why would the package and use Plasma otherwise, if not to create a usable product. They simply create their own KF LTS, by backporting patches which they define important enough to the version of KF they use. Like they do for all the other software where they pinpointed to a certain version and where upstream does not do a matching LTS, starting with the Linux kernel. And as said before, the Plasma team could just maintain some LTS version of KF next to the normal master release branch and the normal releases. That branch could then even be synced with the release schedule pf Plasma LTS, incl. the lifespan, Is there a list of Plasma LTS usages in distributions which are horrible because of important fixes to KF not being backported? Or is this more a theoretical problem you are afraid of seeing the current quality hick-up? Cheers Friedrich
Re: 2 kirigami fixes for a point release
Sorry, no time to rewrite to make this short. Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham: > [+ frameworks and plasma mailing lists] > > On 2020-02-12 11:31, Albert Astals Cid wrote: > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure: > >> On another note, I have to admit I'm starting to doubt how well our LTS > >> Plasma product works without a corresponding LTS frameworks release to > >> support it. We can fix bugs in software that uses the Plasma release > >> schedule till the cows come home, but if the bug is in Frameworks, users > >> are stuck with it forever since LTS distros don't typically ship new > >> Frameworks releases. Yes, this has been questioned a few times. Also seeing Plasma LTS used together with a non-LTS Qt is a bit strange. But somehow it seems there has not been enough pain for those using the Plasma LTS to change something. Possibly because distributions simply backport important bug fixes for KF themselves, kind of maintaining their own KF LTS version of the KF version they pinpointed to when they froze the ingredients to their OS. Because they are used to do this for other projects as well, and so miss this could be done in cooperation with upstream. IMHO distributions using Plasma LTS, Plasma team & other stakeholders should team up here and maintain a matching LTS branch of Frameworks together at the central KDE repos together. Well, and a version also satisfying other clients of KF, like non-workspace applications from KDE. It's not a reason to change normal KF release cycle. BTW, we release our software in variants of GPL. We give distributions lots of rights by that license to do with the source code what they like, not what pleases us as authors. So we want to do cooperation here, not get into any form of commandeering them, as it starts sounding elsewhere in this thread. If unsatisfied with the quality, make Plasma a trademark and hand it out only to distributions which are complying with the standards the Plasma team is fine with ;) Oh, look, an iceweasel is running over there... ;) > >> Yes yes, they should, and all that--but they don't. > >> > >> It seems like we either need to: > >> - Work on convincing these distros to ship Frameworks versions in a > >> rolling manner to their LTS users > >> - Provide an LTS Frameworks product that can receive bugfixes and get > >> point releases, to support the Plasma LTS product > >> - Stop misleadingly offering a Plasma LTS product, since everything in > >> it that comes from Frameworks isn't actually LTS > > > > This should not matter, Plasma LTS is built on *lots* of other libraries > > that are not LTS either. > > > > If it matters is because the quality of KF5 releases are not good, that's > > what should be fixed IMHO. > Yes, the Frameworks 5.67 release was indeed was quite buggy and > regression-filled from a Plasma perspective :( > > However buggy releases are the proximate cause, not the root cause. We > have to ask: what causes buggy releases? > > I would argue that bugginess is baked into the Frameworks product by > virtue of its very fast one-month release cycle and lack of beta > periods, as there are for apps and Plasma. No matter how diligent patch > review is, regressions always sneak in; that's why QA and beta-testing > exist. This assumes the master branch of KF modules serves the purpose of beta testing. My understanding is: it does not. And could not be, for the very reason you gave, too little time and too few testers. The master branch's purpose is mainly to collect all changes for the next release, and serve as reference when merging dependent changes across multiple repos for CI. It should be in the state of "always releaseable". Which also means patches going in should have seen a beta period by the people doing the patches _before_ merging them, and be well understood in their potential side-effects. Yes, this also means that for cross-repo/products developer should have first done some testing for some time with locally patched variants of all affected repos, if unsure about their changes (say, removing an unused variable is well understood in effect scope and does not need lots of testingi). But by default crowd-sourcing the QA to fellow developers also working against current master and wanting to test-drive their own changes is not the way to go. For one they do not know they should test certain things and thus might not even get close to things, thus not do any testing, or it will conflict with their own work, when they cannot be sure it was their own change or someone else's which breaks things, wasting efforts in finding causes. Needing longer beta test phases also hints that some product is not well understood or designed, and things fall apart easily. That needs fixing of the product itself, to become reliably maintainable and expandable. Looking at the reasoning for the recent requests for KF tarb
Re: 19.12 Beta releases tarballs are available
Am Samstag, 16. November 2019, 09:51:37 CET schrieb laurent Montel:
> Le vendredi 15 novembre 2019, 23:43:42 CET Tobias C. Berner a écrit :
> > Hi there
> >
> > I noticed three issues so far in the tarballs while building:
> > kate: https://people.freebsd.org/~tcberner/logs/kate-19.11.80.log
> > (fails to build, trunk succeeds)
> > messagelib:
> > https://people.freebsd.org/~tcberner/logs/messagelib-19.11.80_1.log
> > (missing header, build fails)
>
> I compiled from scratch and it works fine.
> CI didn"t report problem.
>
> This header is autogenerated see in build/messageviewer/src/MessageViewer/
> DKIMKeyRecord
It is autogenerated on condition "if (${Qca-qt5_FOUND})"
While the build log linked above states:
--- 8< ---
-- The following OPTIONAL packages have not been found:
* Qca-qt5 (required version >= 2.1.0), Qt Cryptographic Architecture,
Needed for dkim support.
--- 8< ---
So if libqca is optional by design, the include of DKIMKeyRecord & Co. also
needs to be conditioned on whether libqca is used in the build.
(though possibly the FreeBSD packages also want to use libqca rather? still,
messagelib needs a fix as long as this is optional :) )
Cheers
Friedrich
Doxygen 1.8.16 creates broken qhp files, upstream patch available for testing (was: Re: KDE Frameworks 5.62.0)
Am Montag, 16. September 2019, 01:44:55 CEST schrieb Bernhard Rosenkraenzer: > Hi, > kdeclarative QCH docs fail to build here: > > /usr/bin/doxygen > [...]/kdeclarative-5.62.0/build/src/KF5Declarative_ECMQchDoxygen.config > Error in line 233: Opening and ending tag mismatch. > > The generated TOC file seems to be bogus. > > $ xmllint build/src/KF5Declarative_ECMQchDoxygen/html/index.qhp > build/src/KF5Declarative_ECMQchDoxygen/html/index.qhp:233: parser error : > Opening and ending tag mismatch: toc line 7 and section > ^ > build/src/KF5Declarative_ECMQchDoxygen/html/index.qhp:234: parser error : > Opening and ending tag mismatch: filterSection line 5 and toc > ^ > build/src/KF5Declarative_ECMQchDoxygen/html/index.qhp:500: parser error : > Opening and ending tag mismatch: QtHelpProject line 2 and filterSection > > ^ > build/src/KF5Declarative_ECMQchDoxygen/html/index.qhp:501: parser error : > Extra content at the end of the document > ^ > > Doxygen 1.8.16, Qt 5.13.1 > > Disabling QCH docs works, but obviously isn't the right thing to do. Does > this happen for anyone else? Antonio Rojas has hit this before and invested into researching the issue, see https://bugs.kde.org/show_bug.cgi?id=411690 There seems a patch against doxygen proposed by a doxygen maintainer at the linked doxygen issue to test (myself not involved here currently, just pointing to what I have seen). Cheers Friedrich
RFC: KDE server/service/location for public gpg keys of tarball signers & Co.
Hi, those of you who make use of signed tarballs/binaries/other files on the consumer side: Please tell your use-case for accessing and using the public keys of the signers, and what the options are you would like to see supported on KDE side. Do so directly on the related task on Phabricator: https://phabricator.kde.org/T11304 Also curious if the pure keys are fine, or if you would fancy whatever support for keys signed by others, for some "KDE web of trust", given that the global SKS system seems without a future, from what I understood. Myself have not really experience in making use of signatures, but doing signed tarballs for some KDE projects myself since some time, I would prefer some sane organized place to put my key, also would prefer to know the signing overhead makes sense by being relied on by at least some, in a proper way ;) So: please head over to https://phabricator.kde.org/T11304 and share your wisdom/needs. TIA & Cheers Friedrich
Re: Remove bundle wrapper, give public to all products, call it "Greater KDE Software Release Day" (was: Re: KDE Applications rename to KDE Apps Bundle)
Hi Jonathan,
Am Samstag, 11. Mai 2019, 19:54:20 CEST schrieb Jonathan Riddell:
> The purpose of the bundle is that it takes the release process out of the
> hands of projects which don't want to do that bit of faff. It's a nice
> service to those projects. It's very successful at that and I don't see
> any purpose in discussing changing what can be included or what should be
> included.
na, you got me wrong here. That proposal about removing the bundle wrapper is
not about changing the process and shifting work. It is solely about changing
the communication to the public/users about what is released those days.
Instead of saying "we release A (which contains X, Y, Z)" one would say "we
release X, Y, Z.".
And for the internal work there would be some dedicated name to refer to this
release work group ("Fourmonthsgroup" or better).
> Nobody has an interest in separating it up. My only objective
> is to give it a slightly more descriptive name which is catchy for the
> public.
What do you mean by "catchy"? For whom should it be catchy and compared to
what? IMHO a catchy name for something which only exists in the release news,
but no-where else (at least in user experience, when using apps they do not
know what belongs to this bundle) only makes things worse, as every time one
says "Bundle name" one does not say the actual names of the actual software
modules, while its those which endusers only see.
And as long as "Itsy Bitsy Teenie Weenie KDE Sofware Modules" still means a
random collection software, where no-one really knows what is inside besides
some fanboys, this does not improve things when trying to inform users that a
new version of their favourite application is out. And at the same time
trying to tell others that all those different applications exist and what
their normal names are.
"Kontact", "Dolphin", "Gwenview", "Konsole", "Rocs", "Cantor", "Kate",
"Okular", "Kdenlive" should be the catchy names. no?
Cheers
Friedrich
Remove bundle wrapper, give public to all products, call it "Greater KDE Software Release Day" (was: Re: KDE Applications rename to KDE Apps Bundle)
Am Freitag, 10. Mai 2019, 22:47:08 CEST schrieb Luigi Toscano: > Il 10.05.2019 21:56 Nate Graham ha scritto: > > On 5/10/19 12:07 AM, Luigi Toscano wrote: > >> I strongly object this solution. "Apps bundle" is just another > >> generic > >> name which does not solve the issue of people distinguishing between > >> "all applications/projects by KDE" and "that specific set of stuff > >> (not > >> just applications) released together every 4 months". > > > > I think the root cause is that the bundle's contents *are* arbitrary. > > Why is Konsole in the bundle but Yakuake isn't? Why is Kdenlive in, > > but > > Digikam isn't? JuK vs Elisa? Why isn't Discover in it? > > > > No name will succeed in differentiating the contents because right > > now > > there's nothing to differentiate. To solve this problem, we'd need to > > either be more inclusive and try to get as many apps as possible into > > the bundle, or else clearly define what the bundle is and then be > > more > > exclusive, removing apps that don't fit that definition. > > The name does not need to differentiate the content. The name should be > a) unique enough so that searching for it would hit just its page > b) distinct enough from generic words like "Application", "Apps" and so > on. The reason for that is to make sure that people don't confuse this > bundle with "all the applications and libraries developed by KDE", which > is a common source of confusion. > > This has nothing to do with the content shipped with the bundle. As before I think the whole concept of this named meta bundle is broken, and actually destructive: it covers and hides away the names of all the products actually released that day, those names which will appear on the display's of the users' devices and in the software installation manager and in the manuals, while the release bundle product is no longer interesting after the release news has been sung. Releases are the one time where one can make a splash and get names into news tag lines which are also read by people not yet using those software products created in the KDE community. Don't we want to see "Kontact", "Dolphin", "Gwenview", "Konsole", "Rocs", "Cantor", "Kate", "Okular" in the headlines and be known by & familiar to more people? And even if we still continue to use the concept of bundle products, we would be better off to have separate bundles per software domain: One for all the games. One for all the PIM/communication software. One for all the education software. One for all the science software. One for all the system tools. One for all the software development utils. With one separate news item per bundle. To give more representation to all the software products in this big box, and catching more people's attention due to more keywords. Currently any release news with this thing called KDE Applications is totally missing to emphasize the rich set of software which exists, as only a few make it into the spotlight, due to news nature and people's attention capabilities. And this while many of them are multi-platform and not bound to "KDE==Plasma" as it is still in many people's heads, if we like it or not. >From what I remember, the current situation is also due to developers over the years not having supported the release dudes with information about changes in all the products (other than the commit changelog which makes hardly good news text to spread), so they just gave up and did a simple one- news-item-with-all-we-got, But from a promo POV, this is a total miss-out to make people aware of all the software. IMHO this release cycle group of software should get an KDE-internal name for the release cycle group, like the group of software with independent release cycle still is referenced as "Extragear". So admins and release managers have an id to use when talking about this group. Perhaps something like "Fourmonthsgroup" :) And the day when that software in the big synchronized release cycle group gets releases could be called "Greater KDE Software Release Day". Cheers Friedrich
Re: Respin (was: Re: KDE Applications 19.03.90 (19.04-rc) packages available for packagers)
Am Freitag, 5. April 2019, 12:55:53 CEST schrieb Christoph Feck: > On 04/05/19 11:21, laurent Montel wrote: > > Le vendredi 5 avril 2019, 11:08:43 CEST Antonio Rojas a écrit : > >> kidentitymanagenement doesn't build due to -DQT_NO_FOREACH > > Thanks Antonio for the heads up! Funny the CI didn't hit the error. CI uses latest KDE Frameworks (updated on weekly base for the "Application" builds). And current master of KConfig has seen the respective clean-up some time ago, so the base builds had picked up that. CI does _not_ check build against the min dependency version of KDE Frameworks (which also differs across the different projects bundled in "KDE Applications" and the related "Applications" build group on CI). So we are partially flying blind WRT buildability against declared dependencies. Cheers Friedrich
PSA: KDE CI: How-To for stable branch switches being picked up
Hi KDE project maintainers, tl;dr https://community.kde.org/Infrastructure/Continuous_Integration_System now tells how to make sure KDE CI picks up your new "stable" branch Some days ago I found that a few products on KDE CI in the "Extragear" section had not seen builds of their stable branches for some months (I remember at least Krita & Kexi), despite being under good development. Reason was that for those products a needed step had not been done after the "stable" branches were switched to new ones: manually triggering an initial build with the new branch (needed with current CI logic). To make KDE CI less a black magic box but more a controlled tool for KDE developers, please find some documentation about the steps needed to be done for build.kde.org on switching the stable branch here: https://community.kde.org/Infrastructure/ Continuous_Integration_System#Updating_builds_on_switching_the_.22stable. 22_branch Already linked from https://community.kde.org/ReleasingSoftware#Branching Please update & improve where needed (it's a wiki... ;) ). Cheers Friedrich
Moving Okteta from KDE Applications to [Extragear] after KA 17.12
Hi, since some time I have been thinking about an independent release cycle for Okteta, given I have some ideas/plans for refactoring/rework which might need some independence from KDE Application release cycle policies. Also did the development cycles of the past for Okteta result in some rows of releases with 0 changes, besides a version bump :) So hereby finally I ask for Okteta to be no longer included with KDE Application releases starting with KA 18.04. I would keep it for now in the repo hierarchy path "kde/kdesk/okteta" until the last 17.12 release has been done, and only then switch to extragear/ something (in sync with translation managers as usual). Okay? My very big thanks to Albert and also Christoph for having taking the burden of all the release work all those years and in such a reliable way. You made my developer life very comfortable, and put the bar very high :) Cheers Friedrich
Re: What to do with the repos we don't ship anymore in KDE Applications 17.12
Am Sonntag, 12. November 2017, 20:33:49 CET schrieb Albert Astals Cid: > My suggestions: > > Broken -> unmaintained > * blogilo > > Not needed -> unmaintained > * jovie > * kaccessible > * ksaneplugin > > No commit for years -> unmaintained > * kremotecontrol > * kppp > * kfilereplace > > Want to release on their own -> extragear > * kstars > > Some activity but no KF5 port -> extragear > * kopete > * kscd Just in case it might have been missed: Once this has been decided, please do not forget to update sysadmin/repo- metadata as needed (cmp. "Moving Projects" at https://cgit.kde.org/sysadmin/repo-metadata.git/about/ ) Mentioning as I was wondering right now why blogilo was still listed on CI, until I realized that the repo is still listed as kde/pim project in repo- metadata, so CI decided on keeping it (despite no info from build-metadata, asking CI maintainers about that curiousity). Cheers Friedrich
Re: KDE Applications 17.08.1 packages available for packagers
Am Dienstag, 5. September 2017, 10:51:43 CEST schrieb Ben Cooksley: > Minuet fails because it does not use ECM, and is therefore not > building with ASAN enabled. Because ASAN is contagious and Frameworks > is built with ASAN enabled, Minuet fails to compile. A similar issue > impacts Marble (which is disabled on the FreeBSD CI as it causes > issues for the Dependency Build jobs which the whole system depends on > to function properly). > > There are only two fixes for this: 1) Using ECM in both of those > projects or 2) Fixing Frameworks/ECM to pass along the enablement of > ASAN to anything which uses Frameworks. > > This is not a compile time issue on Linux due to how ASAN works on > Linux (however the binaries produced won't be usable unless ASAN is > injected into the binary using LD_PRELOAD) There is a third fix option: Fixing ECM code to support the dynamic lib option with ASAN also with clang as compiler, instead of resulting in different behaviour (gcc using -shared- libasan, clang not) which in the aftermath then prevents LD_PRELOAD injection from helping on freebsd. >From https://github.com/google/sanitizers/wiki/AddressSanitizer Q: When I link my shared library with -fsanitize=address, it fails due to some undefined ASan symbols (e.g. asan_init_v4)? A: Most probably you link with -Wl,-z,defs or -Wl,--no-undefined. These flags don't work with ASan unless you also use -shared-libasan (which is the default mode for GCC, but not for Clang). Right now https://cgit.kde.org/extra-cmake-modules.git/tree/modules/ ECMEnableSanitizers.cmake#n164 only tries to dump (half of) the conflicting linker flags in case of clang, where instead it should possibly see to add the flag -shared-libasan. Though that might mean some juggling with supported clang versions, which made me stay away from trying to propose a fix (besides not having that much clue about ASan and clang :) ). Cheers Friedrich
Re: marble_qt.qm installed in wrong paths (was: Re: KDE Applications 17.04.1 packages available for packagers)
Am Mittwoch, 10. Mai 2017, 02:07:18 CEST schrieb Friedrich W. H. Kossebau: > Am Dienstag, 9. Mai 2017, 20:32:03 CEST schrieb Luigi Toscano: > > Tobias C. Berner ha scritto: > > > * marble seems to have moved its localization to > > > $PREFIX/share/marble/data/locale/ar/marble_qt.qm > > > instead of > > > $PREFIX/share/locale/ar/marble_qt.qm > > > > This specific change is something done by marble, copying Friedrich who > > implemented it. > > ... and who failed with that, as some accidentally left old qm files in the > system dir had fooled him when testing if loading the qm files works > (obviously without also checking the path used separately). > > https://phabricator.kde.org/D5792 should fix this. Fix is now in as https://phabricator.kde.org/ R34:efcfaa36f97f9d6fc5b5799545753fe6d488a19f Albert, could you please respin the marble tarball? Sorry for the breakage & extra work. Cheers Friedrich
marble_qt.qm installed in wrong paths (was: Re: KDE Applications 17.04.1 packages available for packagers)
Am Dienstag, 9. Mai 2017, 20:32:03 CEST schrieb Luigi Toscano: > Tobias C. Berner ha scritto: > > * marble seems to have moved its localization to > > $PREFIX/share/marble/data/locale/ar/marble_qt.qm > > instead of > > $PREFIX/share/locale/ar/marble_qt.qm > > This specific change is something done by marble, copying Friedrich who > implemented it. ... and who failed with that, as some accidentally left old qm files in the system dir had fooled him when testing if loading the qm files works (obviously without also checking the path used separately). https://phabricator.kde.org/D5792 should fix this. Cheers Friedrich
Re: KDE Applications 17.04.0 packages available for packagers
Hi, Am Montag, 17. April 2017, 10:39:55 CEST schrieb Heinz Wiesinger: > On Monday, 17 April 2017 10:01:29 CEST Harald Sitter wrote: > > On Sun, Apr 16, 2017 at 5:44 PM, Eric Hameleers wrote: > > > On Fri, 14 Apr 2017, Albert Astals Cid wrote: > > >> At the usual location. > > >> > > >> Haven't had time to compile yet, will start now. > > >> > > >> REVISIONS_AND_HASHES file at https://paste.kde.org/ptskor7sa > > >> > > >> Public release next week thursday. > > >> > > >> Cheers, > > >> > > >> Albert > > > > > > After compiling marble, I end up with these library files and links: > > > > > > $ ll /usr/lib64/libmarblewidget-qt5.so* > > > lrwxrwxrwx 1 root root 25 Apr 16 13:07 > > > /usr/lib64/libmarblewidget-qt5.so -> libmarblewidget-qt5.so.27* > > > -rwxr-xr-x 1 root root 7854768 Apr 16 12:56 > > > /usr/lib64/libmarblewidget-qt5.so.0.26.20* > > > lrwxrwxrwx 1 root root 30 Apr 16 13:07 > > > /usr/lib64/libmarblewidget-qt5.so.27 -> libmarblewidget-qt5.so.0.26.20* > > > > > > Why the ".so.27"? As a result, digikam (compiled against marble 16.12.3) > > > complains with "error while loading shared libraries: > > > libmarblewidget-qt5.so.26" > > > > > > Looking at the library name "libmarblewidget-qt5.so.0.26.20" I would > > > expect > > > the symlink to end on 26, instead of 27. > > > > marble does not maintain their ABIs as such they increase their > > soversions every feature release. > > That's fine, that's not the problem though. The problem is that version > numbers don't match. Checking git I think a commit bumping marble to a > stable version (0.27.0 instead of 0.26.20, which marks a development > version) is missing. > > CC'ing Friedrich who did the bump last time for Applications 16.12. Maybe he > can clarify. I am currently inactive in Marble development, also have not tracked 17.04 preparations. Passing on to official Marble maintainers :) Perhaps this issue is another indication that Marble should switch to an independent release cycle, given the lack of resources to properly prepare KDE Application releases? Given Marble Maps app (the mobil navigation app) releases already on an own cycle, perhaps the rest of Marble should follow there, as it also is all the same repo... IMHO. But not my call. Cheers Friedrich
KDiagram 2.6.0 released
Hi, KDiagram 2.6.0 has been tagged and is now available on the KDE servers. http://download.kde.org/stable/kdiagram/2.6.0/src/ kdiagram-2.6.0.tar.xz.mirrorlist commit 56aaece273f615da52e2f7ddd93c4b04d66c2fed sha256 02788dad7e15c64b74a2d1073c5910469ab4cf46ba905030c1713dce45981882 KDiagram is the bundle of KChart (library for creating all kind of charts) and KGantt (library for creating Gantt diagrams). Known users of either of those libraries are ... ... already: * Massif Visualizer ... in upcoming release: * KMyMoney * KDE PIM EventViews & IncidenceEditor * Calligra Plan & chart component ... perhaps in some upcoming release: * KReport/Kexi For some background info on KDiagram see https://marc.info/?l=kde-core-devel&m=142335191017238&w=2 Cheers Friedrich
Re: KDGantt2 was replaced by kdiagram in master (for 16.12)
Am Dienstag, 1. November 2016, 22:22:27 CET schrieb Sandro Knauß: > Hey, > > > I don't think KDAB intends to release it at all, so you guys can release > > it > > any way you want. > > Now I'm getting confused. Friedrich actually told me that he is planing a > release of kdiagram for next Monday (7th November). Any such confusion hopefully can be resolved by the introduction email for kdiagram from last year: https://marc.info/?l=kde-core-devel&m=142335191017238&w=2 > @Friedrich: Please subscribe me to any release mailing list or what you do > to promote the release. That would be kde-distro-packagers and/or release-team, so you would be subscribed already? Cheers Friedrich
Re: KDGantt2 was replaced by kdiagram in master (for 16.12)
Hi Sandro, Am Dienstag, 1. November 2016, 16:03:23 CET schrieb Sandro Knauß: > Hey, > > As KDEPIM release manager I wanted to pop this up again. For the upcoming > release of KDEPIM we need to release kdiagram somehow. Either we request a > inclusion into KDE Applications or are there other plans for this? As > Laurent told kdiagram is a library from KDAB, so maybe there are other > release cycles. > > For sure we request a remove for kdgantt2 for the upcoming Applications > release. Plan is to have kdiagram stay in extragear, not many changes planned currently, so does not make sense to release it every time with KA. (First) release of kdiagram is already scheduled and prepared, should happen upcoming Monday, 7th November, so in time for dependency freeze of KA 16.12. Pardon for not making more noise about it, sent the respective announcement only in private email to involved people and to the kde-i18n-doc list (me being the release responsible for kdiagram). Cheers Friedrich
Re: Status of libkface & libkgeomap
Am Mittwoch, 26. Oktober 2016, 09:49:53 CEST schrieb Andreas Sturmlechner: > On Friday, 29 July 2016 at 22:48, Gilles Caulier wrote: > > Andreas, > > > > Same situation for libkgeomap. This library can be also moved to > > extragear-libs as only kphotoalbum use it. > > > > Best > > Gilles Caulier > > Just bringing this up again before 16.12 freeze for consideration. I'm > obviously not the one to decide, and I'm not aware of the motivation behind > making it part of KDE Applications initially. > > libkgeomap recently got some commits, Those commits were done by me, but only to bring the code up-to-date with current Marble code. Those commits do not change the fact that there might be no maintainer and only kphotoalbum be using it. Cheers Friedrich
KDE Applications: ease fetching catalogs for a tag, adding file "subdirs" again
Hi, how are the translation catalogs tagged on releases of KDE Applications? I would like to get back the file "subdirs" with the tagged catalogs, the file which list the names of all locales for which there are catalogs present. So one can do a custom packaging based on a tag directly from the repositories again (was possibly in KDE4 times, so expectations are high :) ) I hope this is done by a script? Happy to provide a patch. Background: on releases of KDE Applications the catalogs are currently tagged in svn, see e.g. https://websvn.kde.org/tags/Applications/16.08.0/kde-l10n/5/ which has the snapshot of all the catalogs as used with the KA 16.08.0 release. Which is following what used to be done in the "KDE" times, e.g. https://websvn.kde.org/tags/KDE/4.12.0/kde-l10n/ But other then before those tags/Applications/ folders no longer contain that file "subdirs". That one is only present in the trunk and branches folders. And this very file is used by packaging scripts, to simplify fetching of the catalogs (e.g. releaseme or create_tarball_kf5.rb). Now, those two scripts listed seem to have no problem. That is, because they only work against trunk/ and branches/ folders (from what I saw). Which is surely fine on release day, when the state of the catalogs should be close to the state of the code. But I hit this problem while porting a custom build script from its KDE4 version to the KDE Application/KF5 worlds. That script does rely on the tags for the catalogs. As it would support use-cases like a custom branch based on a certain tag, with special support for a some custom platform only added weeks after the official release. Those custom builds for custom platforms would be ideally made directly from the repositories also when it comes to translation catalogs, because: * could happen weeks after release time, so catalogs in the branch run the risk of no longer being in sync with the code of the tag (e.g. due to a bug fix changing message ids) * with KDE Applications currently all translations are in one separate tarball for all of KDE Applications, so would be some overhead to download everything and to do the work to extract just the catalogs one needs Especially as this worked fine in KDE4 times, and just needs that "subdirs" file which should be easy to generate and which is not expensive to have in svn as well. Not having the "subdirs" file might spoil the purpose of having those catalog tags in svn at all. What other use of the tags is there? (Though in general tagging the state which ends up in a release is nice to have, just seems not general standard with translations for all KDE projects?) IMVHO if we have those tags, we should also put the "subdirs" file there, to help use-cases as those custom-tag-based-from-repo builds. So, where do I need to hack on to provide a patch? :) Cheers Friedrich
Re: Which liist to use for non-KF5/non-Plasma/non-Applications product prerelease announcement to packagers?
Am Montag, 30. Mai 2016, 23:09:11 CEST schrieb Albert Astals Cid: > El dilluns, 30 de maig de 2016, a les 18:14:40 CEST, Friedrich W. H. > Kossebau > va escriure: > > Hi, > > > > for those libs/apps which are not released as part of "KF5", "Plasma" or > > "Applications", but with own release management/cycle, where would general > > KDE products interested packagers expect the announcements to be done? > > For the announcements themselves > https://mail.kde.org/mailman/listinfo/kde-announce-apps > is in my opinion the correct list. > > For pre-announcements besides the usual email to kde-i18n-doc so translators > can give a final touch to translations i guess release-team wouldn't be bad > to use (for "big things", nobody really cares today if i'm going to release > rsibreak tomorrow). Hm, why are you releasing rsibreak at all if you think nobody really cares about it? And are Gentoo users your only target group? :) We need to solve the following for the "small" and the "big" projects (especially as there is no definition what is "big"). which I thought would be in the interest of all project maintainers, well, then at least many: the big majority of the target group for the releases of KDE products are not people who compile things themselves. But people who are looking for and are relying on ready-to-install binaries/packages. Agreed? And releases are done by us usually by just releasing tarballs with source code, so nothing the majority can make use of. That is changing these days, more and more KDE projects are also providing binaries themselves. Still, usually not for the classic linux/bsd/whatever distributions, where we, the KDE projects, rely on the packagers belonging to those linux distributions to do the packaging. And no matter if big or small, if KDE products have packages created for those linux/bsd/whatever distributions, they should be available on the day of the release (if possible, but packagers might be busy with other things after all). That is the very day when the release news will go around in the respective circles interested in that kind of software. That is the whole purpose of making a news item of the release, isn't it. Distro packagers, your call as well, please tell where and how you expect the "big" and "small" projects to ping you in time for the upcoming release and the tarballs to use for creating packages, so you have them ready in time for official release news? Think of Krita, KDevelop, Kexi, Calligra, Digikam, KXStitch, RSIBreak, GCompris, Kile, Krusader, Massif Visualizer, Kamoso, Yakuake, KMyMoney, Skrooge, Konversation, kdeconnect-kde, Krecipes, Kronometer, snorenotify, Purpose, Zanshin, and more I am missing here... how do you find out if there is new stuff to be distributed by you? And how would you like to find out about it? Or tell also if you do not care, even as rolling release distribution, and would rather like to see the KDE projects invest into appimages/flatpack/snap, when it comes to individual apps, libs and plugins we KDE projects create. Motivation: I do not expect the average packager to have the time to follow all communication of all the projects they are doing packages from to find out when there is a new package to be created, at least this is my experience. So my hope is that by having a dedicated channel for just the "tarball uploaded, release planned for day xyz, please ping if you have packages that can be mentioned in the release news or report packaging problems" chances will be improved that users of linux distributions can have their packages on release day, in links from the release news. Like it starts to be the case for Windows and OSX, which hurts for what I am here. Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Which liist to use for non-KF5/non-Plasma/non-Applications product prerelease announcement to packagers?
Hi, for those libs/apps which are not released as part of "KF5", "Plasma" or "Applications", but with own release management/cycle, where would general KDE products interested packagers expect the announcements to be done? I see two mailinglists which might be the proper place, but from the existing announcements done on these lists I am not sure which one should be the one. release-team seems "KF5", "Plasma" or "Applications" only, but that might be only because other release managers are too shy to post there? So, where should Krita, KDevelop, Kexi, Calligra, Digikam & Co. do their release announcements to packagers, so they can start to do packaging in time for the release day? Compare also the official mailinglist descriptions: "About Kde-distro-packagers This list is used to coordinate issues amongst and between KDE developers and distribution packagers. This is a public list." https://mail.kde.org/mailman/listinfo/kde-distro-packagers "About release-team This mailing list is a contact point and a discussion list for people involved in or who are interested in helping with coordinating and creating KDE source releases." https://mail.kde.org/mailman/listinfo/release-team Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08 RC is out
Hi Eric, Am Freitag, 28. August 2015, 07:41:19 schrieb Eric Hameleers: > On Mon, 10 Aug 2015, Rex Dieter wrote: > > Rex Dieter wrote: > >> Rex Dieter wrote: > >>> Raymond Wooninck wrote: > On Thursday 06 August 2015 22:21:52 Albert Astals Cid wrote: > > I failed to use the proper CC when publishing it in kde.org this > > afternoon. > > > > Any feedback? Is anyone actually compiling this or the Beta packages? > > Hi Albert, > > I have compiled KDE Applications 15.08 RC for openSUSE and have the > following failures: > > 1) libkgeomap will no longer compile as that it requires the > >>> > >>> Qt4/KDE4 > >>> > version of Marble, but Marble is now Qt5/KF5 based. > >>> > >>> It's been possible to ship both Qt4 and Qt5 based libmarblewidget for > >>> awhile, but it seems that marble devs disabled Qt4 support only > >>> recently. > >> > >> Sorry, this statement of mine was incorrect... it is still possible to > >> build both Qt4 and Qt5 versions from the latest marble sources (seems the > >> methodology changed, I'll sort that out with marble devs and report back > >> on the details). > > > > We came up with a quick fix, > > http://quickgit.kde.org/?p=marble.git&a=commit&h=5a7b3daeaab324c2c6f3ffdba > > 69a14dc959b3331 > > > > So subsequent marble builds that include that commit will build for Qt5 > > (by > > default), and for Qt4 if you set 'cmake -DQT5BUILD=OFF' > > > > -- Rex > > I tried "-DQT5BUILD=OFF" and a lot more. > No matter what I try, the moc from Qt5 eventually gets picked and I > end with errors "this file was generated using the moc from 5.5.0". Last time I ran into such a problem with for unknown reasons Qt5'c moc being picked up, it was due to some cmake config files for Qt5-based projects being wrongly picked up, whose identifier name was the same as used for the Qt4- based version of that project (happened for me while having an early devel version of Okular/KF5 installed, when the identifier was still named like the one for the kdelibs4 version, "Okular", so the Calligra/kdelibs4 build would always try to use moc-qt5. Meanwhile Okular/KF5 has a proper "Okular5" id :) ). That cmake config file then injected moc-qt5 into the build. So check all find_package() calls and see if any of the ids used there has a cmake config file for the Qt5-based variant on your system, which would be picked over the Qt4-based variant with the same name (or even over a Find*.cmake file). Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[okteta] [Bug 345010] kasten soversion got lowered in Apps 15.04 and master
https://bugs.kde.org/show_bug.cgi?id=345010 Friedrich W. H. Kossebau changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||http://commits.kde.org/okte ||ta/2dce794c44ac72758ee5c60a ||355e3685c287a114 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Friedrich W. H. Kossebau --- Git commit 2dce794c44ac72758ee5c60a355e3685c287a114 by Friedrich W. H. Kossebau. Committed on 11/03/2015 at 18:21. Pushed by kossebau into branch 'Applications/15.04'. Fix lost explicit setting of soversions for Kasten libs M +1-0libs/kasten/controllers/CMakeLists.txt M +1-0libs/kasten/core/CMakeLists.txt M +1-0libs/kasten/gui/CMakeLists.txt http://commits.kde.org/okteta/2dce794c44ac72758ee5c60a355e3685c287a114 -- You are receiving this mail because: You are on the CC list for the bug. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Who is using "-Bsymbolic-functions" for their packages?
Am Dienstag, 28. Mai 2013, 07:55:06 schrieben Sie:
> On Tuesday 28 May 2013 at 01:40:54, Friedrich W. H. Kossebau wrote:
> > Am Donnerstag, 23. Mai 2013, 19:55:43 schrieb Kevin Kofler:
> > > How about we start shipping a shared QtUitools instead? I really don't
> > > see
> > > the point of having this be a static library (in fact, I have been
> > > advocating forcing it to be shared in Fedora, so far without success),
> > > it
> > > only causes problems and does not seem to have any practical benefits
> > > (also
> > > considering that the rest of Qt is shared).
> >
> > "We" = ? KDE? You mean, we should create a libkuitools.so and simply wrap
> > the problem? Hm, could be a solution indeed.
>
> Sorry, "we" = packagers (seeing how this is kde-packagers, but I forgot that
> this is also cross-posted to release-team, so I wasn't clear, sorry).
(only my reply was the first to cc: release-team, but was not clear to me in
any case)
Hm, but that means that everybody who packages KDE SC does so, and I am not
sure too many will be happy to diverge more from upstream, not only because of
the extra maintenance needed.
So ideally we deal with that directly in KDE code, so it is consistently
handled at a central place. Thus my proposal patch at
http://git.reviewboard.kde.org/r/110563/ ("hide symbols from static lib
QtUitools.a (generically by new macro KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)"
which I would really love to get in for 4.10.4 (tomorrow) + a related patch to
kdebindings. So please give that patch another review today!
Cheers
Friedrich
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Who is using "-Bsymbolic-functions" for their packages?
Am Donnerstag, 23. Mai 2013, 19:55:43 schrieb Kevin Kofler:
> Hi,
>
> On Thursday 23 May 2013 at 17:51:02, Friedrich W. H. Kossebau wrote:
> > in a discussion about a crash fix patch the opinion was uttered that the
> > linker flag "-Bsymbolic-functions" should not be used, because it might
> > change the symbol-lookup behaviour in a way that developers do not expect.
> > See https://git.reviewboard.kde.org/r/110563/ ("Crash fix: hide symbols
> > from static lib QtUitools.a (generically by new macro
> > KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)")
No other packagers are using -Bsymbolic-functions?
> [...]
>
> > In any case,
> > take this also as note that currently there is a problem with QtUitools.a
> > being linked into shared libs with all symbols exported (and thus clashing
> > if that way ending multiple times loaded into the same process), you
> > better
> > do whatever patch to hide those symbols, and not only in kdelibs.
>
> How about we start shipping a shared QtUitools instead? I really don't see
> the point of having this be a static library (in fact, I have been
> advocating forcing it to be shared in Fedora, so far without success), it
> only causes problems and does not seem to have any practical benefits (also
> considering that the rest of Qt is shared).
"We" = ? KDE? You mean, we should create a libkuitools.so and simply wrap the
problem? Hm, could be a solution indeed.
Cheers
Friedrich
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: okteta binary compatibility
Am Donnerstag, 22. November 2012, 15:12:29 schrieb Jonathan Riddell: > Hi, I've noticed some missing symbols in okteta in 3.9.80 so I think it's > not binary compatible and should have its soname bumped > > SONAME: libokteta1gui.so.1 > #MISSING: 4:4.9.80# > _ZN6Okteta20OffsetColumnRenderer9setFormatENS_12OffsetFormat6FormatE@Base > 4:4.7.90 SONAME: libkasten2okteta1controllers.so.1 > #MISSING: 4:4.9.80# > _ZN7Kasten210StructTool12setByteOrderENS_21StructViewPreferences13EnumByteO > rder4typeE@Base 4:4.8.90 #MISSING: 4:4.9.80# > _ZN7Kasten218StringsExtractTool12setCharCodecERK7QString@Base 4:4.8.90 > #MISSING: 4:4.9.80# _ZN7Kasten220ViewStatusController9fixWidthsEv@Base > 4:4.8.90 Meh, forgot about these changes. Will see to make it backwards-compatible at least, as otherwise I would need to change quite some more stuff. Should be fixed during the upcoming WE. Thanks for the report, Jonathan. Is there an easy way/tool to check ABI changes myself as developer, so packagers can be saved from the need to report such things upstream? Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request for adding new plugin for Dolphin
Am Samstag, 10. November 2012, 21:03:15 schrieb Martin Andersen: > Hi, > > > > Of course review is a good thing, and Martin's review request did > > > already get a couple of suggestions for improvements. It just wasn't > > > clear to me if telling the wider world is required/makes sense in this > > > case, or if having it reviewed by the people who work on the area is > > > enough - I think that not everyone reading kde-core-devel wants to be > > > informed about every little thing. But actually, either way is fine > > > for me. However, seeing that the hard feature freeze is already in > > > place, it might have to wait until KDE/4.10 branches are created > > > anyway. > > Thank you Frank and Fredrich for the review comments, this will improve the > code. In a second round it could be nice with more rewievers, and I would > like to inform kde-core-devel if this is appropriated. Ideally there would be also testers of your code, because looking through the code is one thing, seeing it working is another :) Dropping a note to kde-core-devel is recommended, both for entering kdereview and the final result of the review. But to increase the chance to find someone who also uses Perforce and has a real interest in your plugin and thus could give it some serious testing with real-life scenarios (so you know it not just Works for You™), you could also blog about it on planetkde.org (or ask Frank or me to forward/host a blog post from you, which we happily will do). At least I would have a better feeling to say "Please import to kdesdk" if there are a few reports of people who say "Great and useful stuff, works for me!" > > I thought we had granted an feature freeze excemption for this (or that's > > what > > i understood from the previous mails in this thread). > > I glad that you like my new plugin and wants this include in the release. > I'm currently working on fixing a bug that makes this Plugin almost > unusable in suntan situations as too many files are marked as not under > version control. > I will try to fix this in the coming days, but I will not be able to test > the result before week 47. The fix will affect only one of the public > functions (beginRetrieval()), however I will make it up to someone else to > decide if this is still acceptable for KDE 4.10 or if the plugin will have > to wait for 4.11. While a good rule is "Release often and early" perhaps it might be a good idea to do this release often and early on your own in the early stages, outside of KDE SC/kdesdk. This is also recommended in the Lifecycle policy that Albert already referenced: "When you have made one of more releases and want to continue to develop it, the term 'playground' does no longer apply to you. That is the right time to move out of here.", see http://techbase.kde.org/Policies/Application_Lifecycle#Stage_2:_Stable So given the timing and the issues you still see yourself I tend to propose to delay the inclusion into the kdesdk module for version 4.11. Instead for now you should do a little drum-roll (e.g. by blogging about your plugin) and make small releases on your own and upload the tarballs to places like kde-apps.org where chances are high that people will look for it if they need it and also give you feedback. You could use the category "Utilities/KDE Filemanager" (http://kde- apps.org/index.php?xcontentmode=284) or whichever you might find more suited, people surely will use the search tools. Doing releases on your own for the next half year also enables you to ignore restrictions on UI strings and features, so the feedback/patches you get from other users can be integrated the moment you have time to work on it. Then, after this small maturing process, everyone will feel better to have the Perforce plugin to be officially part of kdesdk. Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request for adding new plugin for Dolphin
Hi, Am Montag, 5. November 2012, 21:50:01 schrieb Albert Astals Cid: > El Dilluns, 5 de novembre de 2012, a les 20:47:51, Martin Andersen va > > escriure: > > On Mon, Nov 5, 2012 at 8:00 PM, Albert Astals Cid wrote: > > > El Diumenge, 4 de novembre de 2012, a les 19:05:57, Martin Andersen va > > > > > > escriure: > > > > Hi, > > > > > > Hi > > > > > > > I have made a Perforce version control plugin for Dolphin [1]. > > > > > > > > I know that we are in soft feature freeze. Will it be possible to > > > > include > > > > this plugin in KDE 4.10? This request is supported by Frank > > > > Reininghaus. > > > > > > What's the intended destination (as in repo)? > > > > http://websvn.kde.org/trunk/KDE/kdesdk/dolphin-plugins/ > > > > > What's the impact if the code was horribly wrong and crashy? Would it > > > crash > > > dolphin all the time? Or just when perforce was used? Or when you > > > entered > > > a > > > folder that is a perforce checkout? > > > > It will have no impact if the plugin is dissabled. > > When the plugin is enabled the constructor will be called and the function > > FileViewPerforcePlugin::fileName() will be called. > > Only when entering a folder under perforce control the remaining code will > > be active. > > No objection from me. At least you'd need kdesdk coordinator approval too. > Friedrich are you reading this? Will have a look until Friday. Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
How to process/update "Mimetype=" entries in .desktop files on install?
Hi, (follow-ups please only to kde-devel) I am looking for a way to deal with the issue that the list of supported mimetypes for some programs depends on the installed i/o plugins. E,g, Marble and most Calligra programs have this problem. Simply hardcoding all possibly supported mimetypes only leaves bad impressions if a program is started for a file after e.g. a click on the file in the file manager, but then gives an error message after starting that it cannot read the file. It is not only about the i/o plugins created at build time. But some distributions also tend to put single i/o plugins in different packages, so just updating the "Mimetype=" entry in the .desktop file on build-time (by generating another .desktop file) before it is installed will not work for these. So how can this problem be solved? Is it possible to update the installed desktop file of a programs on install of another package, like another input plugin? How would this need to be noted in our sources, so it would happen automatically, or that packagers know they have to add something to the post- install part of the input plugin package? Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Review Request: add note about Oxygen Icons to README.packagers
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106114/ --- Review request for KDE Runtime and Release Team. Description --- As discussed in the thread "The misterious case of oxygen-icons" there is an undocumented (de-facto) run-time depedency of kdelibs and kde-runtime on the Oxygen Icons (http://mail.kde.org/pipermail/release-team/2012-August/006364.html). Which should be better officially documented. This patch adds a note about the run-time need for Oxygen Icons to kde-runtime/README.packagers. Okay to commit both to master and 4.9 branch? Diffs - README.packagers 67705c7 Diff: http://git.reviewboard.kde.org/r/106114/diff/ Testing --- Thanks, Friedrich W. H. Kossebau ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: The misterious case of oxygen-icons
Am Donnerstag, 16. August 2012, 18:22:46 schrieb Rex Dieter:
> On 08/16/2012 06:14 PM, Albert Astals Cid wrote:
> > Do we really have a runtime dependency on oxygen-icons? My limited
> > knowledge in the matter is that icon names are standarized thus you can
> > use oxygen-icons or AlbertAwesomeImages (aai for friends) and it'll still
> > work.
> >
> > Can someone with more knowledge confirm or reject?
>
> technically no, but in practical terms yes.
>
> 1. it's used as a fall back icon theme
> 2. if not present, many many icons will be missing all over
And many many icons missing would be a big bug, no? :) So I would consider
this also theoretically a dependency.
To cite myself from the thread on calligra-devel, the code which makes Oxygen
the fallback icon theme is this, cmp.
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kdeui/icons/kiconloader.cpp#L603
--- 8< ---
void KIconLoaderPrivate::addBaseThemes(KIconThemeNode *node, const QString
&appname)
{
// Quote from the icon theme specification:
// The lookup is done first in the current theme, and then recursively
// in each of the current theme's parents, and finally in the
// default theme called "hicolor" (implementations may add more
// default themes before "hicolor", but "hicolor" must be last).
//
// So we first make sure that all inherited themes are added, then we
// add the KDE default theme as fallback for all icons that might not be
// present in an inherited theme, and hicolor goes last.
addInheritedThemes(node, appname);
addThemeByName(KIconTheme::defaultThemeName(), appname);
addThemeByName("hicolor", appname);
}
--- 8< ---
where KIconTheme::defaultThemeName() is like:
--- 8< ---
QString KIconTheme::defaultThemeName()
{
return QLatin1String("oxygen");
}
--- 8< ---
As there is no Oxygen icon subset just for icons used by kdelibs/kde-runtime,
kdelibs/kde-runtime needs a certain version of the complete oxygen-icons.
And as said, programs using kdelibs/kde-runtime, like Calligra or Okteta,
would need to know what icons they can expect and what icons not, so they know
for which icons they need to install their own copies, just to make sure they
are present.
So anybody objecting to document oxygen-iconset as a hard dependency in
README.packagers in kde-runtime?
Cheers
Friedrich
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: The misterious case of oxygen-icons
Hi, Am Donnerstag, 16. August 2012, 23:28:18 schrieb Albert Astals Cid: > I am quite confused as about how we handle oxygen-icons release wise. > > First some facts: > * Technically oxygen-icons is not part of the SC since it lives in > trunk/kdesupport and not in trunk/KDE/ > http://websvn.kde.org/trunk/kdesupport/oxygen-icons/ > * We release oxygen-icons with the SC > > http://download.kde.org/stable/4.9.0/src/oxygen-icons-4.9.0.tar.xz.mirrorli > st * We tag oxygen-icons with the SC > http://websvn.kde.org/tags/KDE/4.9.0/oxygen-icons/ > * We do *not* branch oxygen-icons > http://websvn.kde.org/branches/KDE/4.9/ > http://websvn.kde.org/branches/kdesupport/ > > So my confusion is two fold: > * Why are we releasing it with the SC if it's not part of it? > * Why is it not branched? > > And related to the second: > * What should we package with the tarball of oxygen-icons for KDE SC 4.9.1? Another question from me: Where is the minimum dependency of kdelibs/kde-runtime on oxygen-icons documented? As it is a run-time dependecy it is absent from the build system checks from what I see, but I could also not find any README.packagers which lists oxygen- icons as hard dependency. Seems packagers create a hard dependency on oxygen- icons package anyway, but still would be nice to have that documented (to have something to refer to). This question came up today for Calligra if the dependency on a certain kdelibs also implicitely brings in the Oxygen icon set, so the icons can be expected to be available. Cheers Friedrich ___ 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, 20:17:56 schrieb Wulf C. Krueger: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10.06.2012 15:27, Albert Astals Cid wrote: > >> - - 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. > > No, that's for us packagers to "do our thing". What you give us > should, as a rule, build and install properly. > Of course, we'll notify you if things are broken but that should be > the exception, not the rule. > > Nor should offloading the burden of QA to us be the rule. You > shouldn't just throw untested tarballs at our feet and hope for the best. Hm. Somebody needs to be the first/one to test the tarballs. Who should that be? And what environment should she/he use? And should all other packagers simply wait until a first packager has tried to create packages from the tarballs? With regard to QA, all the tarballs are created from snapshots of the branches that the developers build from, all the time. So if there are problems they ideally would have already been found (and fixed) by the developers. Just that developers have usually not the exact build environment which there is for a package build, which is also different for each distribution. Take the problems Rex today reported for kdesdk and Fedora as example. E.g. I build kdesdk once a week or so. Never saw his problem. And surely no other kdesdk developer has. Some things only turn up at packaging time, for a given distribution setup. Please also remember that the size and complexity of the software released as KDE SC has become quite large compared to KDE3 times, so a few more issues at release times are to be expected. Surely still everyone would like 0 issues :) For the dependencies on not-released versions, that is indeed something that is annoying, should not have happened and should have been catched before. But as I understood Allen & Co. are working on a system to improve in that area, right? > Rght. It's all my perception only and KDE has no issues at all. ;-) Nobody claims there are no issues. There are indeed quite a few. But it's simply nobody but us (and for me packagers are part of the KDE community, why else would they care for KDE software) who needs to fix them, as these are all our itches :) Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesdk cmake-bustage, kde4_add_plugin
Hi Rex,
Am Sonntag, 10. Juni 2012, 13:00:37 schrieb Rex Dieter:
> On 06/10/2012 12:41 PM, Rex Dieter wrote:
> > Seems some odd cmake borkage is going on trying to build kdesdk-4.8.90
> > (4.8.80 suffered the same, but I hadn't noticed then), in that any
> > modules using kde4_add_plugin seem to not get compiled with -fPIC
> > properly, and fail linking, for example,
> >
> > dolphin-plugins:
> > /usr/bin/ld:
> > CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o: relocation
> > R_X86_64_32 against `_ZN17FileViewSvnPlugin16staticMetaObjectE' can not
> > be used when making a shared object; recompile with -fPIC
>
> ...
>
> > blindly replacing kdesdk toplevel CMakeLists.txt with that from 4.8.4
> > makes things happy again.
> So, more data:
>
> ... = a bunch of -I... includes not relevant,
>
> 4.8.4 gets compiled as:
>
> cd .../kdesdk-4.8.4/build/dolphin-plugins/svn && /usr/lib64/ccache/c++
> -DMAKE_FILEVIEWSVNPLUGIN_LIB -D_BSD_SOURCE -D_XOPEN_SOURCE=500
> -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT
> -DKDE_DEPRECATED_WARNINGS -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=48
> -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS
> -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
> -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security
> -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common
> -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
> -Werror=return-type -fvisibility-inlines-hidden -O2 -g -DNDEBUG
> -DQT_NO_DEBUG -fPIC ... -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o
> CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o -c
> /home/rdieter1/pkgs.fedoraproject.org/kdesdk/foo/kdesdk-4.8.4/build/dolphin-
> plugins/svn/fileviewsvnplugin_automoc.cpp
>
> and in 4.8.90 this get's compiled with:
>
> cd .../kdesdk-4.8.90/build/dolphin-plugins/svn && /usr/lib64/ccache/c++
> -DMAKE_FILEVIEWSVNPLUGIN_LIB -DQT_NO_STL -DQT_NO_CAST_TO_ASCII
> -D_REENTRANT -DKDE_DEPRECATED_WARNINGS
> -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=48 -DQT_USE_FAST_CONCATENATION
> -DQT_USE_FAST_OPERATOR_PLUS -O2 -g -DQT_NO_DEBUG ...
> -D_LARGEFILE64_SOURCE -o
> CMakeFiles/fileviewsvnplugin.dir/fileviewsvnplugin_automoc.o -c
> /home/rdieter1/pkgs.fedoraproject.org/kdesdk/foo/kdesdk-4.8.90/build/dolphin
> -plugins/svn/fileviewsvnplugin_automoc.cpp
>
>
> many differences (mostly flags being removed), but most noticeable
> causing the immediate issue was -fPIC
>
> any advice, clues, suggestions?
Can you try if the attached patch helps at least for the dolphin-plugins? Have
not investigated, but could be the effective difference.
When doing my development builds I could not yet see your problem though, need
to check.
kdesdk is currently trying to get in shape for the migration to git and for
that has already done some changes to the buildsystem trying to make all
submodules build stand-alone.
Cheers
FriedrichIndex: kdesdk/dolphin-plugins/CMakeLists.txt
===
--- kdesdk/dolphin-plugins/CMakeLists.txt (Revision 1299631)
+++ kdesdk/dolphin-plugins/CMakeLists.txt (Arbeitskopie)
@@ -4,6 +4,8 @@
include(KDE4Defaults)
include(MacroLibrary)
+set(CMAKE_REQUIRED_DEFINITIONS ${_KDE4_PLATFORM_DEFINITIONS} -DQT_STRICT_ITERATORS)
+
add_definitions (${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
add_definitions(-DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS)
include_directories (${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES} ${KDEPIMLIBS_INCLUDE_DIR})
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Why are 4.8.80 packages already out in the wild?
Am Montag, 4. Juni 2012, 18:01:29 schrieb Martin Gräßlin: > On Monday 04 June 2012 15:18:11 Kevin Kofler wrote: > > On Monday 04 June 2012, Sebastian Kügler wrote: > > > That means that people report bugs against different incarnations of the > > > same packages, which makes bugs hard to find -- it doesn't work as we > > > can't verify the exact state of the code a bug is filed against. > > > > That almost never makes a difference in practice, and when it does, the > > developers are (or should be) aware of the respin and ask to make sure. > > (If > > the reporter is the packager, he/she'll definitely know whether the > > package > > already uses a respun tarball, if not, he/she can provide the exact > > version > > of the distro package and the distro packager can tell you what tarball > > was > > used. And in any case, we always issue a new build with the respun tarball > > as soon as possible.) > > I must admit that I find your answer strange. Given that the whole thread > had been started by a developer because he sees a problem in exactly that > thing, it's quite strange that I get told that there is no problem at all. > > Please note that working as a developer is quite different to working as a > distro packager. Yes your distro packages have very precise versions, yes > our versions, too - once they are released. And that's the difference to > the distro packages, before the release it is not known what the version > is. (Btw. shipping patches upstream does not know about is as bad - even in > development versions nobody should use). > > Now what appears to be no problem is a problem. It is causing work for > developers when the version information is wrong. It is causing work if we > have to ask again for the version information. Furthermore it is not said > that a developer knows about a respin tarball. Please note that unlike you, > I as a developer have no access to the tarball before release and the > developers don't get a mail in their inbox telling them that the tarball > has been recreated. Developers have to actively monitor the release team > mailinglist and I'm quite sure that not everybody is subsribed to this > list. > > The whole thing becomes even more complex if we consider the perfect case of > bug triaging. How should a triager know that the developers fixed a bug > which caused a respin of the package? > > I hope you understand that what you describe as a non-issue, is issue enough > that I started the thread. So yeah either I have no clue about what I do, > or maybe, maybe it is an issue in fact. For me the issue as you described it seems to be that it is not so easy to map the version of the binary/package back to the version of the sources, ideally even a git/svn commit id (and the ids of any patches downstream has applied). This issue is even a bigger problem if your fellow developers compile your code from scratch and then file a bug by version "Compiled from sources". Should happen much more often, no? :) Could this issue not be solved by somehow getting the real source code version id(s) into the binary/package info? Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
tags/unmaintained/4 trunk/KDE/kdesdk
SVN commit 1296353 by kossebau: Move kdesdk/kdeaccounts-plugin to tags/unmaintained/4 This old KABC-based plugin creating a read-only addressbook resource has been replaced by the new Akonadi-based plugin in kdepim-runtime/resources/kdeaccounts but this one was forgotten to be removed before. Moving to unmaintained as agreed here: http://lists.kde.org/?l=kde-sdk-devel&m=133746896417053&w=2 CCMAIL: kde-...@kde.org CCMAIL: kde-sdk-de...@kde.org CCMAIL: release-team@kde.org M +3 -0 tags/unmaintained/4/README A tags/unmaintained/4/kdeaccounts-kabcplugin (directory) M +0 -4 trunk/KDE/kdesdk/CMakeLists.txt D trunk/KDE/kdesdk/kdeaccounts-plugin (directory) --- tags/unmaintained/4/README #1296352:1296353 @@ -19,6 +19,9 @@ * kbugbuster a frontend to KDE's bugzilla +* kdeaccounts-kabcplugin +KABC-based addressbook plugin wrapping the data from kde-commons/accounts + * kdessh a frontend to ssh --- trunk/KDE/kdesdk/CMakeLists.txt #1296352:1296353 @@ -51,10 +51,6 @@ macro_optional_add_subdirectory(lokalize) endif(HUNSPELL_FOUND OR WIN32) -if(KDEPIMLIBS_FOUND) - macro_optional_add_subdirectory(kdeaccounts-plugin) -endif(KDEPIMLIBS_FOUND) - if(LIBKONQ_FOUND) macro_optional_add_subdirectory(dolphin-plugins/svn) macro_optional_add_subdirectory(dolphin-plugins/git) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] kdepim-runtime/resources/kdeaccounts vs. kdesdk/kdeaccounts-plugin
Hi Volker, Am Samstag, 19. Mai 2012, 19:07:32 schrieb Volker Krause: > On Saturday 19 May 2012 04:23:18 Friedrich W. H. Kossebau wrote: > > I am curious about the relation between > > > > kdepim-runtime/resources/kdeaccounts * > > > > and > > > > kdesdk/kdeaccounts-plugin **. > > > > Does the Akonadi-based plugin in kdepim-runtime officially replace the > > KABC- based plugin in kdesdk? > > yes > > > * https://projects.kde.org/projects/kde/kdepim- > > runtime/repository/revisions/master/show/resources/kdeaccounts > > ** http://websvn.kde.org/trunk/KDE/kdesdk/kdeaccounts-plugin/ > > > > If so, should kdesdk/kdeaccounts-plugin not better be removed to > > tags/unmaintained/4? > > IMHO yes, actually I somehow thought the old one was gone already. > > > Or should kdepim-runtime/resources/kdeaccounts better be moved to > > kdesdk/kdeaccounts-plugin? > > > > At least to me it looks strange if in the same SC release, like the next > > 4.9, there is both a kdeaccounts plugin for Akonadi and still the old > > plugin for the deprecated KABC system. > > > > I am asking because currently the migration of kdesdk to git is prepared, > > and ideally only useful stuff gets the work needed for the migration. > > makes sense, perfect time for droping the old one then Alright. So I will move kdesdk/kdeaccounts-plugin to tags/unmaintained/4/kdeaccounts-kabc on Wednesday, May 23th, in the European evening, unless anyone objects. INHO this does not conflict with any rules of the release schedule, this submodule simply got forgotten to be removed after the introduction of the Akonadi-based plugin variant. Not a perfect time, but better late then never. Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8 RC1 (4.7.95) tarballs uploaded (try#1)
Vendredi, le 23 décembre 2011, à 13:46, Andreas Pakulat a écrit: > On 23.12.11 10:55:42, Sebastian Kügler wrote: > > On Friday, December 23, 2011 02:54:00 Kevin Kofler wrote: > > > 2. The released version of KDevelop doesn't build against the new > > > okteta headers. Not sure whether that's intentional, but it breaks > > > things in any case. If the incompatibility is intentional, we need an > > > updated KDevelop. > > > > Please make sure Okteta and KDevelop authors know about this. > > They are, in fact Friedrich already fixed. And differently than I said > before, its also in the 4.2 branch. So distro's can easily pull the > patch: > > http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-December/0419 > 13.html Right, thanks Andreas for pointing out :) Only pushed the needed commits a few days ago to have the Okteta plugin for KDevelop to also support the upcoming version of Okteta, both for master/4.3 and 4.2, but did forget to notify you packagers, pardon me. For 4.2 it is commit https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/revisions/1a0aeb55ff099d31fd6fe4f7e02c70f8c5f122ea If there are any problems, please just ping me by email so I could see to fix them, I should be able to spare time away for any issues also the next days. > There's not going to be another 4.2.x release afaik. Cheers Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves
Hi, too bad noone was up to push it finally into kde-runtime when it was ready for it, but let's pick it up again now: Mardi, le 26 avril 2011, à 14:53, Nikhil Marathe a écrit: > Hi, > > KDE SC 4.7 soft feature freeze is close, and I would like to propose > the UPnP MediaServer KIO slave > (https://projects.kde.org/projects/playground/base/kio-upnp-ms/) be > included into the set of kio slaves shipped with kde-runtime. The > slave was created as part of GSoC 2010 - Amarok and KDE UPnP support > and it was decided that it should be merged into kde-runtime at some > point. > > A couple of reasons I believe the slave is now ready for standard release > is: 1) HUpnp (http://herqq.org/news.html) - the Qt based UPnP library used > by the slave has a stable API and ABI with the release of 1.0.0 about 3 > weeks ago. > 2) The slave has been considerably simplified and single threaded, and > stable now. > 3) The slave is independent and can be conditionally compiled and > installed if HUpnp is installed. kdelibs already contains a > FindHUpnp.cmake to find the HUpnp library. > 4) The Solid UPnP backend (enabled in 4.7, again if HUpnp is found) > automatically launches UPnP media servers in the file manager with the > slave. 4b) And that Places integration of 4) will be useless if there is no upnp-ms kio-slave, people would click on the mediaserver icon but see nothing in the list 5) It is also used by Amarok since 2.4.0 (if found) 6) It adds no further dependencies than there are with kdelibs (i.e. HUpnp as optional library, if not found the kio-slave will be simply skipped). So UPnP support in Solid is aligned with kio-upnp-ms here. > My exams get over this week and I can ensure that krazy checks pass > and the code is cleaned up some more. But then Nikhil had his job life interfering, so could not spend any time on pushing this request forward :( I did a short code review, looked fine (could not comment on HUPnP usage, but who can besides Nikhil?), and some code optimization patches I did even got merged by Nikhil meanwhile. > There is inline documentation where required, and the search and > browse API documentation exists. There is no user > manual since it is a slave. I am confident about having it ready by > hard feature freeze. I also would consider it ready for first serious usage. After all it will enable all KIO-enabled programs to access the media content on UPnP media servers out there (e.g. Xbox), at least to a certain degree. So, release-team, what would you think about an exception to still include the upnp-ms kio-slave in kde-runtime 4.7? After all it was ready, just noone replied to him besides Kevin and me both saying "Keep it coming!". It does not affect any other code, as it is an isolated kio-slave. Might not even be compiled if some distro has not yet HUpnp packages. But if there are HUpnp packages the Places integration (Dolphin/filedialog) for UPnP media servers will be useless without this kio-slave. So distros would have to install this kio-slave anyway. So it might make sense to have the kio-slave already in kde-runtime, instead of extragear, where I would like to push it otherwise, so it can be released together with the SC 4.7 officially and distros know about this additional feature/kio-slave. If you say No (understandable): What is the process to make the playground/base repo of kio-upnp-ms an extragear/base repo in times of git repos? Could not find it documented on techbase, pointers welcome. And how would that repo be marked that it should be included in the SC 4.7 release process? If you say Yes (would be welcome): Tomorrow/Today evening (wednesday, 29 june) I would see to create a branch from kde-runtime master where the commit history of the kio-upnp-ms repo is merged (been there, done that), have that reviewed by someone and then backport that merge to 4.7 branch. Okay? Cheers Friedrich -- Desktop Summit 2011 in Berlin - Registered already? - www.desktopsummit.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Raphael getting new kdeutils coordinator (was: Re: [PATCHES] Remove some content from the utils.kde.org website)
Hi, Lundi, le 23 mai 2011, à 23:29, Friedrich W. H. Kossebau a écrit: > Dimanche, le 22 mai 2011, à 22:29, Raphael Kubo da Costa a écrit: > > On Sunday 22 May 2011 00:22:01 Friedrich W. H. Kossebau wrote: > > > Seems since Okteta moved out of kdeutils my activity here has > > > decreased. But that is more than compensated by you :) > > > To make things official, can I hand over to you the title of > > > coordinator for kdeutils, incl. mailing list moderation? > > > > If nobody objects, that would be fine to me :) > > Great, thanks. So let's wait six more days for any objection (or Hurrays :) > ), then put the Kdeutils Coordinator star on your chest next sunday. Missed to do so on sunday, but here you are now: * :P Thanks again for taking on the task, good to know it in your hands. CC:ing the release-team for a heads-up on this person's change, also just updated the info on http://techbase.kde.org/Projects/Release_Team#Coordinator_List Thanks also to the other kdeutils contributors, was a fun job all the time! Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Filelight moved into kdeutils (was: Re: Filelight into kdereview (again))
Hi, Jeudi, le 30 septembre 2010, à 01:36, Martin Sandsmark a écrit: > On Sunday 26. September 2010 01.25.22 Friedrich W. H. Kossebau wrote: > > No, I meant when the mouse moves over the next item which could be > > selected in the filelight view. Currently that one is selected instantly > > if there is a mouse event over the item. That way you have to move your > > mouse pretty fast out of the window so it does not trigger a single > > event over anything else in the view to prevent to have another item > > selected. Hm, the menu comparison seems a bad one currently, at least > > with Oxygen. There selection of new items in it is now done also > > instantly. But I remember there is a time-delay possible, to be able to > > go with the mouse cursor directly to lower parts of the submenu just > > opened, i.e. with passing other items of the parent menu for a few > > milliseconds without having them triggered, so the submenu is not > > switched, to that one of the menu item you only wanted to pass. > > > > Got a better idea what I mean? > > I think so, but won't this make the UI feel nonresponsive or sluggish? Depends on the length of the timeout. If it is about close to the time a user needs to control the stopping and correct positioning of her mouse on the item she is interested in, she should not really notice. > > If you like, okay. Removing the root of evil still preferred if possible. > > ;) > > Well, the root is removed, I'm just not guaranteed that Filelight isn't run > with an old version of Solid, was my idea. :-) Understandable. Then, could be controlled by min-version-needed ;) Still I would like to get you into not covering errors which should not be there and are in our reach :) > > Please also help out with > > http://lists.kde.org/?l=kde-i18n-doc&m=127851249725448&w=2 > > as Alexander requested, some i18nc with proper comment should do. > > Done. i18n_c_ ;) You might also want to take a look at http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics to help translators creating even better strings :) > > The minimum-height-bigger-than-my-screen-resolution seems a problem only > > experienced by Albert so far, so I consider that something to be solvable > > after the move. > > Yeah, I've been unable to reproduce it here. I asked him to try to > reproduce without a filelightrc (informally on IRC), but I don't think he > ever came back to me. See same thread, Albert there said he tried without, same error. Let's see what others can/have to report. > > Will you do the move yourself, or do you want me to do that? > > I just did it, hope I didn't screw up anything. :-) No, seems all fine :) > > Will add a section on utils.kde.org for it, or do you plan to keep the > > old/current homepage for it? Max Howell still involved in filelight? > > Max has moved on to greener pastures, so to speak. :-) > I don't have a page for it at the moment, so a section on utils.kde.org > would probably be nice. Okay, will do something tomorrow or during weekend. Dear Albert (cc: via release-team), could you once again help with moving of translation files? Quite some movement in/out kdeutils these days :) Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE
Vendredi, le 24 septembre 2010, à 01:34, Albert Astals Cid a écrit: > A Dijous, 23 de setembre de 2010, Friedrich W. H. Kossebau va escriure: > > SVN commit 1178758 by kossebau: > > > > Moving Okteta, the hex editor, from kdeutils to kdesdk > > > > As agreed in discussion on kde-core-devel: > > http://lists.kde.org/?l=kde-core-devel&m=128501857422609&w=2 > > > > Dear master(s) of translation, could you please also move the > > translations? > > Moved. Thanks, Albert! Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE
SVN commit 1178758 by kossebau:
Moving Okteta, the hex editor, from kdeutils to kdesdk
As agreed in discussion on kde-core-devel:
http://lists.kde.org/?l=kde-core-devel&m=128501857422609&w=2
Dear master(s) of translation, could you please also move the translations?
CCMAIL: release-team@kde.org, kde-utils-de...@kde.org, alex.richard...@gmx.de,
ma...@kde.org
M +4 -0 kdesdk/CMakeLists.txt
M +1 -0 kdesdk/README
M +3 -0 kdesdk/doc/CMakeLists.txt
A kdesdk/doc/okteta (directory)
A kdesdk/okteta (directory)
M +1 -4 kdesdk/okteta/kasten/controllers/view/print/printtool.cpp
M +0 -3 kdeutils/CMakeLists.txt
M +0 -2 kdeutils/Mainpage.dox
M +0 -3 kdeutils/README
M +0 -3 kdeutils/doc/CMakeLists.txt
D kdeutils/doc/okteta (directory)
D kdeutils/okteta (directory)
--- trunk/KDE/kdesdk/CMakeLists.txt #1178757:1178758
@@ -33,6 +33,9 @@
macro_optional_find_package(HUNSPELL)
macro_log_feature(HUNSPELL_FOUND "HUNSPELL" "Library used for stemming"
"http://hunspell.sourceforge.net/"; FALSE "" "Required to build Lokalize.")
+macro_optional_find_package( QCA2 )
+macro_log_feature( QCA2_FOUND "QCA2" "Qt Cryptographic Architecture"
"http://delta.affinix.com/qca"; FALSE "2.0.0" "Needed for most of the algorithms
of the checksum tool in Okteta." )
+
add_definitions (${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories (${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES}
${KDEPIMLIBS_INCLUDE_DIR})
@@ -56,6 +59,7 @@
macro_optional_add_subdirectory(kpartloader)
macro_optional_add_subdirectory(strigi-analyzer)
macro_optional_add_subdirectory(kioslave)
+macro_optional_add_subdirectory(okteta)
check_c_source_compiles("
#include
--- trunk/KDE/kdesdk/README #1178757:1178758
@@ -14,6 +14,7 @@
* kstartperf, startup time measurement for KDE apps
* KUIViewer, display user interface (.ui) files from Qt Designer
* lokalize, computer-aided i18n translation
+* okteta, hex editor
* poxml, translates DocBook XML files using gettext po files
* swappo, reads PO file and reverses direction of translations
* umbrello, GUI for diagramming Unified Modelling Language (UML)
--- trunk/KDE/kdesdk/doc/CMakeLists.txt #1178757:1178758
@@ -21,6 +21,9 @@
if(BUILD_lokalize)
add_subdirectory(lokalize)
endif()
+if(BUILD_okteta)
+ add_subdirectory(okteta)
+endif()
if(BUILD_poxml)
add_subdirectory(poxml)
endif()
--- trunk/KDE/kdesdk/okteta/kasten/controllers/view/print/printtool.cpp
#1178743:1178758
@@ -32,13 +32,10 @@
#include
// Okteta core
#include
-// KDE Utils
-#include
// KDE
#include
#include
#include
-#include
// Qt
#include
#include
@@ -86,7 +83,7 @@
if( printDialog->exec() )
{
QString creator = QString::fromLatin1( "Print Plugin for Okteta " );
// no i18n(), keep space at end as separator
-creator += KDEUTILS_VERSION_STRING; // TODO: change to
OKTETA_VERSION_STRING
+// creator += KDEUTILS_VERSION_STRING; // TODO: change to
OKTETA_VERSION_STRING
printer.setCreator( creator );
FramesToPaperPrinter framesPrinter;
--- trunk/KDE/kdeutils/CMakeLists.txt #1178757:1178758
@@ -24,8 +24,6 @@
endif(X11_FOUND)
macro_optional_find_package( GMP )
macro_log_feature( GMP_FOUND "GMP" "The GNU Multiple Precision Arithmetic
Library" "http://gmplib.org/"; FALSE "" "Required for building KCalc.")
-macro_optional_find_package( QCA2 )
-macro_log_feature( QCA2_FOUND "QCA2" "Qt Cryptographic Architecture"
"http://delta.affinix.com/qca"; FALSE "2.0.0" "Needed for most of the algorithms
of the checksum tool in Okteta." )
macro_log_feature( QT_QTXMLPATTERNS_FOUND "QtXmlPatterns" "Qt support for
XPath, XQuery, XSLT and XML Schema validation"
"http://doc.trolltech.com/latest/qtxmlpatterns.html"; FALSE "" "Required to
build kremotecontrol." )
# --- programs ---
@@ -50,7 +48,6 @@
macro_optional_add_subdirectory( kgpg )
macro_optional_add_subdirectory( ktimer )
macro_optional_add_subdirectory( kwallet )
-macro_optional_add_subdirectory( okteta )
macro_optional_add_subdirectory( sweeper )
if( X11_FOUND AND QIMAGEBLITZ_FOUND)
--- trunk/KDE/kdeutils/Mainpage.dox #1178757:1178758
@@ -22,8 +22,6 @@
(http://utils.kde.org/projects/ktimer";>Homepage) - execute
programs after some time
- KDE Wallet Manager
(http://utils.kde.org/projects/kwalletmanager";>Homepage) - KDE
wallet management tool
-- Okteta
- (http://utils.kde.org/projects/okteta";>Homepage) - Hex editor
- Printer Applet
(http://utils.kde.org/projects/printer-applet";>Homepage) -
Applet to view current print jobs and configure new printers.
- SuperKaramba
--- trunk/KDE/kdeutils/README #1178757:1178758
@@ -39,9 +39,6 @@
* kwallet
KDE wallet management tool
-* okteta
-binary file editor
-
* printer-applet
a system tray utility that shows current print jobs, shows printer
warnings and errors and shows when printers that have
Okteta plugin translation files also needed for KDevelop 4.1 branch (was: Re: Import of Okteta plugin to KDevelop master branch done)
Mercredi, le 1 septembre 2010, à 23:04, Friedrich W. H. Kossebau a écrit: > Masters of translation: > Could you please move the translation of at least the desktop file of the > okteta plugin to the proper place for KDevelop? If you haven't done already > like magically as always :) > They currently exist for trunk/kdereview/okteta-kdevelop4-plugin/ and are > imported to > http://gitorious.org/kdevelop/kdevelop/trees/master/utils/okteta Update: Have been imported to the master branch before 4.1 was branched today, so are also needed for http://gitorious.org/kdevelop/kdevelop/trees/4.1/utils/okteta Thanks Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Import of Okteta plugin to KDevelop master branch done (was: Re: Request for review: Okteta plugin 0.1.0 for KDevelop 4.0)
Lundi, le 30 août 2010, à 21:36, Andreas Pakulat a écrit: > On 30.08.10 21:07:40, Friedrich W. H. Kossebau wrote: > > Dimanche, le 29 août 2010, à 23:00, Andreas Pakulat a écrit: > > > On 29.08.10 20:50:46, Andreas Pakulat wrote: > > > > On 26.08.10 02:19:41, Friedrich W. H. Kossebau wrote: > > > > > Jeudi, le 26 août 2010, à 02:05, Andreas Pakulat a écrit: > > > > > > > Who would do the import into the kdevelop git repo? Would be > > > > > > > nice it history could be preserved... > > > > > > > > > > > > As I still have an rsync of KDE's svn I could probably do that. > > > > > > I'll sync that up over the weekend and start working on > > > > > > conversion rules > > > > > > > > > > Great, thanks. > > > > > > > > Sorry to say, but the weekend turned out to be rather hectic so I > > > > didn't get around to do anything for that. As the deadline for new > > > > features for 4.1 is wednesday I don't think I'll have enough time to > > > > add the plugin to kdevelop. Maybe someone else has the time? > > > > Otherwise I'll be happy to do it after the 4.1 branching. > > > > > > Ok, scratch that, seems like I'll be able to do at least one run of the > > > svn->git conversion tonight. If all goes well that may already be the > > > last. > > > > As http://gitorious.org/kdevelop/kdevelop does not show a activity by you > > it means that it failed? > > No it just means that running the rsync took longer than I thought, then > the svn->git conversion needs time and finally I also needed to sleep a > bit and work a bit ;) Well, would have left six bits still :P > I'm done now and its pushed. Thanks. Imagine me happy. :) BTW: I will skip my idea with a separate release of the plugin for KDevelop 1.0, no time and no private interest. Masters of translation: Could you please move the translation of at least the desktop file of the okteta plugin to the proper place for KDevelop? If you haven't done already like magically as always :) They currently exist for trunk/kdereview/okteta-kdevelop4-plugin/ and are imported to http://gitorious.org/kdevelop/kdevelop/trees/master/utils/okteta I will remove the plugin files from kdereview next. Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
One post-4.5.0 patch to fix the freeze of kded on first use of the network:/ kio-slave
Dear packagers, please consider backporting the following commit to your 4.5.0 packages: http://websvn.kde.org/?revision=1160391&view=revision It fixes a total freeze of kded if the network:/ kio-slave is first invoked. The kio-slave calls its kded module networkwatcher via D-Bus, kded loads the module on demand (as configured since 4.5), but the module itself also does a D-Bus call in its initialisation which seems blocked by a mutex hold by kded due to the D-Bus call which triggered the load of the module initially -> deadlock. Sorry about the late notification. I am short of time and with messed up computers currently, so my short testing missed to see this in time, and it seems nobody else who tested the network:/ kio-slave was ambitious enough to report this. Will also blog about this problem. Thanks Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Unannounced optional runtime dependency for SC 4.5: Cagibi 0.1 in kdesupport
Hi Maciej, Mardi, le 20 juillet 2010, à 05:29, Maciej Mrozowski a écrit: > On Tuesday 13 of July 2010 23:04:26 Friedrich W. H. Kossebau wrote: > > Hi, > > > > due to a broken laptop and other real life circumstances I completely > > missed to announce in time another, while optional and at runtime, > > dependency for the SC 4.5 release, for the network:/ kio-slave in > > > > kdebase/runtime/kioslave/network: > > Cagibi 0.1(.0) from kdesupport (tagged in /tags/cagibi/0.1.0) > > > > Cagibi is a daemon for SSDP (the discovery part of UPnP) and, if > > accessable via D-Bus, used to also show UPnP devices/services in the > > network:/ kio-slave listings, otherwise silently ignore that data > > source. If the url info is present, a click on the UPnP device/service > > item will forward the user to the web interface of the respective > > device/service, e.g. of the router or media server. > > > > There is no cmake check (yet), as I had no idea how to test for a service > > only accessed via D-Bus (direct D-Bus calls, no D-Bus api xml installed > > yet to test for). So you won't have noticed this dependency from the > > builds. > > > > I (and some users) might be happy if you still consider adding Cagibi as > > official optional dependency, also by adding it to > > tags/kdesupport-for-4.5 > > > > :) If not, no harm is done, but it would be good to get this stuff out in > > I'm afraid you would need to release official cagibi source tarball to have > it considered by distro packagers (especially before adding it as a > buildsystem dependency). Until then likely nobody is going to pick it up. Alright, thanks for the hint. Uploaded a tarball + lsm file to ftp://upload.kde.org/incoming/stable/KDE4.x with the implicite request (by lsm primay-site entry) to put this tarball to fto://ftp.kde.org/pub/kde/stable/cagibi As this is my first time uploading to upload.kde.org since many years, anything else I need to do which is not described in the files on the ftp server? Once the tarball is published there I should also make a more formal announcemen on kde-announce and o my blog, too, I guess. Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Unannounced optional runtime dependency for SC 4.5: Cagibi 0.1 in kdesupport
Hi, due to a broken laptop and other real life circumstances I completely missed to announce in time another, while optional and at runtime, dependency for the SC 4.5 release, for the network:/ kio-slave in kdebase/runtime/kioslave/network: Cagibi 0.1(.0) from kdesupport (tagged in /tags/cagibi/0.1.0) Cagibi is a daemon for SSDP (the discovery part of UPnP) and, if accessable via D-Bus, used to also show UPnP devices/services in the network:/ kio-slave listings, otherwise silently ignore that data source. If the url info is present, a click on the UPnP device/service item will forward the user to the web interface of the respective device/service, e.g. of the router or media server. There is no cmake check (yet), as I had no idea how to test for a service only accessed via D-Bus (direct D-Bus calls, no D-Bus api xml installed yet to test for). So you won't have noticed this dependency from the builds. I (and some users) might be happy if you still consider adding Cagibi as official optional dependency, also by adding it to tags/kdesupport-for-4.5 :) If not, no harm is done, but it would be good to get this stuff out in the wild finally. Thanks and Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
trunk
SVN commit 1081252 by kossebau:
changed: moved the Bookmarks plasmoid from kdereview to kdeplasma-addons
reviewed in this thread:
http://lists.kde.org/?l=kde-core-devel&m=126325889824270
Dear masters of translation, could you move the translation data accordingly?
Thanks!
CCMAIL:release-team@kde.org
M +1 -0 KDE/kdeplasma-addons/applets/CMakeLists.txt
A KDE/kdeplasma-addons/applets/bookmarks (directory)
kdereview/plasma/applets/bookmarks#1081251
M +0 -1 KDE/kdeplasma-addons/applets/bookmarks/generalconfigeditor.cpp
M +0 -1 kdereview/plasma/applets/CMakeLists.txt
D kdereview/plasma/applets/bookmarks (directory)
--- trunk/KDE/kdeplasma-addons/applets/CMakeLists.txt #1081251:1081252
@@ -11,6 +11,7 @@
add_subdirectory(bball)
add_subdirectory(binary-clock)
add_subdirectory(blackboard)
+add_subdirectory(bookmarks)
add_subdirectory(bubblemon)
add_subdirectory(calculator)
add_subdirectory(charselect)
--- trunk/KDE/kdeplasma-addons/applets/bookmarks/generalconfigeditor.cpp
#1081251:1081252
@@ -39,7 +39,6 @@
mBookmarkFolderAddress(bookmarkManager->root().address()),
mBookmarkManager(bookmarkManager)
{
-
QVBoxLayout* pageLayout = new QVBoxLayout(this);
pageLayout->setMargin(0);
--- trunk/kdereview/plasma/applets/CMakeLists.txt #1081251:1081252
@@ -1,2 +1 @@
macro_optional_add_subdirectory(adjustableclock)
-macro_optional_add_subdirectory(bookmarks)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
tags/unmaintained/4 tags/unmaintained/4/kdessh trunk/KDE/kdeutils
SVN commit 1067536 by kossebau:
Moved kdessh to tags/unmaintained/4
Reasons:
* did not work since 4.0 (stub program on remote was not in $PATH)
* has no maintainer
* no real use (with ssh doing X11-forwarding)
* does not integrate with KWallet or ssh-agent
* keeps password in unsecured memory
CCMAIL: release-team@kde.org,kde-utils-de...@kde.org
M +3 -0 tags/unmaintained/4/README
A tags/unmaintained/4/kdessh (directory)
trunk/KDE/kdeutils/kdessh#1067529
M +2 -2 tags/unmaintained/4/kdessh/kdessh.cpp
M +0 -1 trunk/KDE/kdeutils/CMakeLists.txt
M +0 -2 trunk/KDE/kdeutils/Mainpage.dox
M +0 -3 trunk/KDE/kdeutils/README
D trunk/KDE/kdeutils/kdessh (directory)
--- tags/unmaintained/4/README #1067535:1067536
@@ -16,6 +16,9 @@
* kbabel
for translating po files
+* kdessh
+a frontend to ssh
+
* kenolaba
* kfouleggs
--- tags/unmaintained/4/kdessh/kdessh.cpp #1067529:1067536
@@ -71,7 +71,7 @@
options.add("+host", ki18n("Specifies the remote host"));
options.add("+command", ki18n("The command to run"));
options.add("u ", ki18n("Specifies the target uid"));
-options.add("s ", ki18n("Specify remote stub location"),
"kdesu_stub");
+options.add("s ", ki18n("Specify remote stub location"),
"kdesu_stub4");
options.add("n", ki18n("Do not keep password"));
options.add("q", ki18n("Stop the daemon (forgets all passwords)"));
options.add("t", ki18n("Enable terminal output (no password keeping)"));
@@ -184,7 +184,7 @@
}
QByteArray password;
-if (needpw != 0)
+if (needpw == SshProcess::SshNeedsPassword)
{
KDEsshDialog *dlg = new KDEsshDialog(host, user, stub,
proc.prompt(), keep && !terminal);
--- trunk/KDE/kdeutils/CMakeLists.txt #1067535:1067536
@@ -38,7 +38,6 @@
if(KDE4Workspace_FOUND)
macro_optional_add_subdirectory( kdelirc )
endif(KDE4Workspace_FOUND)
-macro_optional_add_subdirectory( kdessh )
macro_optional_add_subdirectory( kdf )
# K3Process
macro_optional_add_subdirectory( kfloppy )
--- trunk/KDE/kdeutils/Mainpage.dox #1067535:1067536
@@ -12,8 +12,6 @@
(http://utils.kde.org/projects/kcharselect";>Homepage) - Select
special characters from any fonts and put them into the clipboard
- KDELirc
(http://utils.kde.org/projects/kdelirc";>Homepage) - Front end
to lirc, the Linux Infrared Remote Control system
-- kdessh
- (http://utils.kde.org/projects/kdessh";>Homepage) - Front end to
ssh
- KDiskFree
(http://utils.kde.org/projects/kdf";>Homepage) - like 'df', a
graphical free disk space viewer
- KFloppy
--- trunk/KDE/kdeutils/README #1067535:1067536
@@ -24,9 +24,6 @@
* kcharselect
select special characters from any fonts and put them into the clipboard
-* kdessh
-front end to ssh
-
* kdf
like 'df', a graphical free disk space viewer
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Request for deprecation of KDESu::SshProcess and removal of kdesu_stub/kdessh
Hi,
KDESu::SshProcess (in kdelibs) and the commandline shell for it, kdessh (in
kdeutils) are horribly broken (as in: do not work and may be insecure) and (at
least for me) seem not easy to be fixed.
I guess most of you do not even know these things exist, so:
kdessh is a wrapper to ssh and, instead of executing the original remote
command, first (via KDESu::SshProcess) fires up kdesu_stub on the remote
computer to setup the environment variables as needed for a better integration
into the local session, only then executes the original command.
Additionally it also caches the passwords (but does not use KWallet).
It is not working at all currently, as this commit
"Move kdesu_stub to libexec"
http://websvn.kde.org/?view=revision&revision=666108
moved kdesu_stub out of the $PATH, so the ssh server will not find it.
Is there a chance somebody remembers why it was moved to ? And not
perhaps renamed kdesu_stub to kdesu_stub4? Or just have it conflict with the
KDE 3 version, like e.g. KWrite has a conflict, too.
The class KDESu::SshProcess/StubProcess itself has a wild mixtures of
undocumented return values, seems to forget about child processes in some
conditions, has password strings in unsecured memory, does not reuse the
running ssh connection after testing for password needs, does not do a proper
check for false passwords and whatelse.
From lxr.kde.org it seems kdessh is the only user of KDESu::SshProcess,
besides kvpnc in playground/network (no idea about its state). And with zero
reports about this problem on b.k.o kdessh also seems without any users.
As noone has ever had a closer look at kdessh until now (starting kdessh did
nothing, including no obvious harm, so it got ignored), including the kdeutils
coordinator (who is writing here) it was only now decided to move kdessh from
kdeutils to tags/unmaintained after the Beta2 release. Sorry for any
inconvenience.
Additionally the class KDESu::SshProcess in kdelibs should be marked as
deprecated. Perhaps it could be even removed, as I do not think anyone is
using this class/these symbols?
Also kdesu_stub does no longer needed to be built and installed, as long as it
ends in lib/kde4/libexec.
Still I think such a utility for the integrated execution of remote programs
is nice to have. But with X11-forwarding-enabled ssh client/servers and ssh-
agent/-add it should perhaps have another approach, including integration of
KWallet. I also wonder how much remote X clients can and should be integrated
in the local session at all, including the Session D-Bus?
Cheers
Friedrich
PS: In case you are interested find attached two patches which made kdessh at
least working again, until I found SshProcess too broken to continue to clean
up for all possible conditions. Patches do s/magic numbers/enums/g, renames
kdesu_stub to kdesu_stub4 and installes it to bin/ again, code style cleanup,
more caring for child processes.
--
Okteta - KDE Hex Editor - http://utils.kde.org/projects/okteta
Index: kdelibs/kdesu/ssh.h
===
--- kdelibs/kdesu/ssh.h (Revision 1063492)
+++ kdelibs/kdesu/ssh.h (Arbeitskopie)
@@ -29,8 +29,11 @@
const QByteArray &command = QByteArray());
~SshProcess();
-enum Errors { SshNotFound=1, SshNeedsPassword, SshIncorrectPassword };
+enum Errors { NoError=0, SshNeedsNoPassword=0, SshNotFound=1, SshNeedsPassword, SshIncorrectPassword };
+enum ExtendedErrors { GeneralError=-1 };
+enum ExecType { NormalExec=0, PasswordCorrectCheck=1, PasswordNeededCheck=2 };
+
/**
* Sets the target host.
*/
@@ -59,7 +62,7 @@
/**
* Executes the command.
*/
-int exec(const char *password, int check=0);
+int exec(const char *password, int check=NormalExec);
QByteArray prompt() const;
QByteArray error() const;
@@ -69,6 +72,7 @@
virtual QByteArray displayAuth();
private:
+enum SshResult { SshProtocolError=-1, SshNoError=0, StoppedAtPasswordPrompt=1, SshOtherError=255 };
int ConverseSsh(const char *password, int check);
protected:
Index: kdelibs/kdesu/stub.cpp
===
--- kdelibs/kdesu/stub.cpp (Revision 1063492)
+++ kdelibs/kdesu/stub.cpp (Arbeitskopie)
@@ -105,95 +105,101 @@
int StubProcess::ConverseStub(int check)
{
-QByteArray line, tmp;
-
+// stub header
while (1)
{
- line = readLine();
- if (line.isNull())
- return -1;
+QByteArray line = readLine();
+if (line.isNull()) {
+return StubProtocolError;
+}
- if (line == "kdesu_stub")
- {
- // This makes parsing a lot easier.
- enableLocalEcho(false);
- if (check) writeLine("stop");
- else writeLine("ok");
- break;
- }
+if (line == "kdesu_stub") {
+// This makes parsing a lot easier.
+enableLocalEcho(false);
+writeL
Re: i18n focused beta or RC
Jeudi, le 23 juillet 2009, à 12:51, Sebastian Kügler a écrit: > On Thursday 23 July 2009 12:26:23 Anne-Marie Mahfouf wrote: > > My proposal went unoticed or ignored but I propose that for the next > > release cycle we focus testers to try a beta or RC in different languages > > so that i18N problems can be detected earlier than for this 4.3 release. > > I propose that the announcement draws attention to testers on the > > importance of i18n. At the same time it would also put in light all the > > hard work (and believe me, it's really hard) done by hundreds of > > translators. > > So for 4.4 I'd like a beta or RC "babel" released to focus on this area. > > Good idea. Can you remind me when we're that far? I tend to forget things > in half a year. ... Perhaps all the information about how to do a release could be noted down somewhere, to prevent forgetting and helping with the bus number? E.g. at http://techbase.kde.org/Policies , section Procedures? Cheers Friedrich -- Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Is trunk dependant of Qt 4.5 or not, as of now?
Hi, I am confused if it is okay to add Qt4.5-dependant code to trunk, without an ifdef. What is the official policy? Is there one? There should be. I have no opinion in this regard, so I don't request the one or the other, just a need for clarity :) The update of qt-copy to Qt 4.5 could be understood as "depending on 4.5 now", but that was done without any official notice to the simple developers as I am (at least it passed me without notice), so I don't know about the complete scope of that change. Could there please be an official announcement for the developers in trunk? And, if I may wish, it would be nice if such changes could be scheduled and announced in the future, so everyone can prepare and isn't catched by surprise. Like Alex so nicely warns^Winforms about CMake dependancy changes :) Which are the official communication channels today, perhaps I just listen on the wrong ones? Thanks Friedrich -- Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: A Proposal: EOL 4.1, Branch 4.2, Start 4.3
Am Freitag, 5. Dezember 2008, um 11:44 Uhr, schrieb Lucas Murray: > You said it yourself: bug fixing is top priority, why make it more > difficult? I am against prematurely thawing trunk as quite a few > developers will shift from bug fixing into feature development (I can > see myself doing this) even if they know they will let some bugs get > into 4.2 that could have been avoided. Trunk should remain in whatever > mode that will benefit the top priority--if feature additions are top > then it's thawed, if it's bug fixing then it's frozen. > > RC 1 is a good thawing date (Maybe even a week before it), not beta 2. +1 Let's first make 4.2 release ready (as candidate at least), only then shift to the next target (e.g. see my very own recent fixes to kdelibs (more to come), I would not have done them if I could work on new features for Okteta already in trunk, and I guess I don't differ too much from others here). Friedrich -- Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Putting Playground in some order
Hi,
should we get some more structure into Playground? I fear it will otherwise
end in the state kdenonbeta has been before if it isn't already: Lot's of
started projects, but most of them dead code, making people uninterested in
looking into it at all.
Take for example playground/utils:
http://websvn.kde.org/trunk/playground/utils/?sortby=date
There are currently 45 projects inside. 18 haven't seen any activity since
seven month and more, only 8 have seen activity in the last four month
besides scripty. There is also a mix of KDE 3 and KDE 4 dependencies.
So I would like to propose to have some little policy for playground:
a) Projects which have been without a commit for more than five month are
moved to
tags/unmaintained/playground/$submodule/{3,4}
if the authors/maintainers do not oppose within a month.
b) KDE3 based projects are moved to branches/playground/kde3/$submodule/ (cmp.
branches/extragear/kde3/$submodule)
By keeping only active projects in playground third-parties like translators,
dashboard maintainers or check drivers (cmp. *) do not spend their resources
on dead things. And splitting of the KDE3 based ones should have been done
long time ago.
*
http://englishbreakfastnetwork.org/krazy2/index.php?component=playground&module=utils
Then the toplevel structure of trunk/playground does not exactly reflect the
current KDE modules:
accessibility/
artwork/
base/
bindings/
devtools/
edu/
games/
graphics/
ioslaves/
multimedia/
network/
office/
pim/
sysadmin/
utils/
While trunk/KDE consists of:
kde-common/
kdeaccessibility/
kdeadmin/
kdeartwork/
kdebase/
kdebindings/
kdeedu/
kdegames/
kdegraphics/
kdelibs/
kdemultimedia/
kdenetwork/
kdepim/
kdesdk/
kdetoys/
kdeutils/
kdevelop/
kdewebdev/
Extragear is not matched exactly, too:
base/
graphics/
libs/
multimedia/
network/
pim/
plasma/
sdk/
security/
utils/
Is this intended, or should the submodules be restructured to match the main
KDE modules? Matching the main modules would make it straigthforward to have
the module coordinator also care for the corresponding playground submodule.
Perhaps extragear structure should be aligned to the main modules, too?
Because projects in playground could rather end there.
Motivation:
I want to give the projects in playground/utils some more visibilty by adding
them to utils.kde.org, e.g. to show useful overviews of development status,
similar to
http://utils.kde.org/projects/kwalletmanager/development.php
So people are aware what is happening and do not continue to do things like
implementing three power manager applets independently, like currently
happening.
But this would mean binding of playground/utils to kdeutils. I am not sure if
this is a good idea.
Comments, please?
Friedrich
--
Okteta - KDE Hex Editor, coming to you with KDE 4.1
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Policies regarding version numbers of programs and libs
Hi, module kdeutils coordinator here. Techbase lists [T] as a function of module coordinators to "help with release preparation (eg. update application version numbers)". So I am now looking to update the programs and libs version numbers for the module kde-utils. But I wonder if there is a (inofficial) policy regarding version numbers (for non-extragear modules)? My current question is: When should a version number be changed and how? For every new KDE release, following the increasing in the version number of KDE, even if the code did not change at all? I just send an email to kde-utils-devel which argues "Yes" with the reasoning: a) Dependencies have changed (kde(pim)libs of same release), new translations b) bug reports use version number of program and not of the KDE release c) using KDE_VERSION_STRING and GENERIC_LIB_*VERSION has that effect, too. How do other modules handle this? [T] http://techbase.kde.org/Projects/Release_Team#Coordinator_List Thanks Friedrich -- Okteta - KDE Hex Editor, coming to you with KDE 4.1 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RC1 release criteria
Am Dienstag, 8. Juli 2008, um 11:36 Uhr, schrieb Dirk Mueller: > Hi, > > so the time of RC1 tagging has come (tonight/tomorrow). I would like to > hear comments/list of todo items from each module maintainer that would > block RC1. Late, but for the record: No blockers known in kdeutils. Friedrich -- Okteta - KDE Hex Editor, coming to you with KDE 4.1 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: the future of kdetoys
Am Freitag, 9. Mai 2008, um 13:01 Uhr, schrieb Stefan Böhmann: > > > 8. kteatime > > > I ported this application to KDE4 and took care of it since then. > > > > No objections to moving kteatime into kdeutils, if Friedrich is ok with > > that. Or to extragear. > > Ok - I prefer to move kteatime and amor to extragear/utils. Just curious: Why extragear and not a base package like kdeutils? Or kdegames for amor? kdetoys could also be revived as container for all the rather entertaining resourcekilller^Wanimations^Wscreensaver plugins or window FXs, so amor would give a lead to all them there. Most important: I propose to delay 4.1 until there is an eyes plasmoid in kdebase. It would be a shame and a break with the X/KDE traditions if there isn't. It would be right outrageous. I would stop using Linux and go back to Win98. Alright, there is http://www.kde-apps.org/content/show.php/KEyes?content=51493 for a save. But it doesn't use any kdelibs, just don't think of Plasma... Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
