Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
On Friday, 25 October 2019 21:15:19 CEST, Friedrich W. H. Kossebau wrote:
Am Donnerstag, 24. Oktober 2019, 18:52:34 CEST schrieb laurent Montel:
Who told you that it will keep broken ?
If we show that it doesn't build we will fix it.
I don't see the problem. ...
The problem I see is availability of resources of people. And forcing them
into caring for deprecated API. This should be an opt-in for those happy to
work on deprecations once they appear.
It's especially annoying for packagers when testing new Qt versions. It's
just wasted time to backport patches for that with no real benefit at all.
I remember adding 30 patches (mostly to PIM packages) with one Qt update
just to keep stuff compileable and 5.14 needs a few of these again. So
please don't use -DQT_DISABLE_DEPRECATED_BEFORE=0x06 at least with
releases. It's as bad as an idea like using -Werror with released code.
I see that some of these were added/moved behind an "if (EXISTS
"${CMAKE_SOURCE_DIR}/.git")" so this mail might become obsolete, hopefully.
Cheers,
Heiko
21.04 release service schedule
Hello everyone, the release team agreed on a schedule for the upcoming release service 21.04: https://community.kde.org/Schedules/release_service/21.04_Release_Schedule Dependency freeze is in 5 weeks and feature freeze one after that. Get your stuff ready! Cheers, Heiko
KDE 21.08 dependency freeze in
Dependency freeze for KDE Gear 21.08 is in six days (July 8, 23:59 UTC), please make sure to update all the needed dependencies before that date. Next interesting dates: July 15: 21.08 Freeze and Beta (21.07.80) tag & release ... August 12: 21.08.0 Release More at: https://community.kde.org/Schedules/KDE_Gear_21.08_Schedule Regards, Heiko
Re: Is Krename buglist ABANDONED?
Hi,
On Thursday, 29 July 2021 00:01:15 CEST, Rafael Linux User wrote:
Someone wrote this is fhe right e-mail to ask about it and to take some
actions about the issue.
https://bugs.kde.org/show_bug.cgi?id=439293
it's just that time is a scarce resource and while krename works fine for
my purposes the codebase is not tiny and still has some cruft in need of
modernisation. For example, the bug you're likely referring to, is probably
best solved by porting to QXmlStream{Reader/Writer}, which already exists
locally but still needs some finishing touches and autotests.
That being said, any contribution to improve things would be welcome.
Cheers,
Heiko
KDE Gear 21.12 release branches created
Please make sure you commit anything you want to end up in the 21.12 releases to them. We're already past the dependency freeze, so no new dependencies or increasing of dependency versions in the stable branches. The feature freeze, tagging and release of the beta (21.11.80) is in four days,11 November. Next interesting dates: November 25: 21.12 RC (21.11.90) Tagging and Release December 2: 21.12 Tagging December 9: 21.12 Release Complete Schedule: https://community.kde.org/Schedules/KDE_Gear_21.12_Schedule Regards, Heiko
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sunday, 6 March 2022 19:32:57 CET, Neal Gompa wrote: This whole thing has been a terrible mess and it's extremely frustrating. It's caused problems for the development of the last couple of Fedora releases, too. Can we scale back the language please? I get that you're not happy, but calling the work of volunteers a terrible mess most likely won't motivate them any further and it isn't respectful at all. Furthermore, wearing my packager hat, I really disagree. I'm quite happy that I don't have to hunt Qt patches myself. Regards, Heiko
Re: Request to bump QT_MIN_VERSION to 5.15.2 for whole Plasma
Hello, On Sunday, 26 June 2022 13:52:23 CEST, Ömer Fadıl USTA wrote: Right now plasma projects' minimum depends on KF >5.90 and after KF5.86 its REQUIRED_QT_VERSION is 5.15.2 thus keeping QT_MIN_VERSION as 5.15.0 is meaningless and it also causes problems such as in this merge : https://invent.kde.org/utilities/konsole/-/merge_requests/689 So I am suggesting to bump all plasma project's QT_MIN_VERSION to 5.15.2 I will be glad to get some replies and want to hear what are your opinions about this that doesn't unreasonable, but konsole isn't released as part of Plasma (it gets released with KDE Gear) and if it's actually about Plasma this request should probably go to plasma-de...@kde.org Regards, Heiko
Re: Missing product versions in Bugzilla
On Sunday, 24 July 2022 01:15:09 CEST, Nate Graham wrote: IIRC, the release team takes care of updating product-versions of apps on Bugzilla using a script. CCing them. Yes, we do. At least for projects passing their version number to project() in CMakeLists.txt [1] and if the project name matches the product name in bugzilla or has an bugzilla entry in repo-metadata.git, e.g. something like [2]. Unfortunately Laurent sometime increases the versions for all PIM repos prematurely, as in before we release the tarballs to the public, which means the script adds yy.mm.expected_version + 1 in these cases. Which should account for most of the missing versions below. There are more versions missing for kmail because the capability and information to do the kmail2 <-> kmail was only contributed by Sandro at some point in the past. On 7/23/22 16:10, Glen Ditchfield wrote: I've noticed an assortment of missing versions for different products: |kontact | 5.20.1 5.17.2 5.16.2 | |kmail2 | 5.20.1 5.18.3 5.18.2 5.18.1 5.18.0 | || 5.17.3 5.17.2 5.17.1 5.17.0| |korganizer | 5.20.1 5.17.2 5.16.2 | ... I added these versions manually. Regards, Heiko [1] https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning#Bugzilla_versions [2] https://invent.kde.org/sysadmin/repo-metadata/-/commit/bfbd371087b756e6d069e32e6753dfaf810e0bbd
Re: New releases for bugfixes
On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote: From the git-archive manual page: «git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.» Before anybody tries that *now*, at least for Gear the tarballs are currently created with git archive --remote=kde:$repo $branch .. So they currently won't have that information. Regards, Heiko
Bringing Cantata under the KDE umbrella?
Hi, Cantata is a Qt based MPD client, which was archived by its original author [1]. I started some porting to Qt6 but I wondered (and was asked in #kde-devel today) if it would make sense to move it to KDE's infrastructure? Despite being archived, it still works quite nicely. And while there are already a few music players on invent, there is none with support for MPD. Would anybody object to bringing it under the KDE umbrella? Regards, Heiko [1] https://github.com/CDrummond/cantata/
Re: Bringing Cantata under the KDE umbrella?
On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote: El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko Becker va escriure: Cantata is a Qt based MPD client, which was archived by its original author [1]. I started some porting to Qt6 but I wondered (and was asked in #kde-devel today) if it would make sense to move it to KDE's infrastructure? Despite being archived, it still works quite nicely. And ... My only 2 concerns are: * Is anyone going to work on it? I guess you? Yes. * Can we have an agreement by the original author so we can take over the trademark? I mailed him about it and will share the reply here. Regards, Heiko
Re: Bringing Cantata under the KDE umbrella?
On Monday, 20 February 2023 13:18:02 CET, Aleix Pol wrote: On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker wrote: Part of the incubation process is to gather what's the team working on it. https://community.kde.org/Incubator/Projects/DescriptionTemplate It feels wrong to incubate a project that is already out of development. Especially when we already have a number of music players... The original author just switched to LMS, which apparently suited his usecase better. Considering the responses in this thread and the 165 forks on github, I think it's not really too bold to assume there's still interest in Cantata though. If the team size is a critical problem, I could just do this on my personal github, see if its gets any traction and attracts helping hands and revisit this discussion at some point in the future. Regards, Heiko
Re: Bringing Cantata under the KDE umbrella?
On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote: My only 2 concerns are: * Is anyone going to work on it? I guess you? * Can we have an agreement by the original author so we can take over the trademark? I got an answer from him: "You are more than welcome for fork Cantata, move to KDE, and use the name, its all fine with me :) Glad someone wants to look after it." Regards, Heiko
Re: Bringing Cantata under the KDE umbrella?
On Tuesday, 21 February 2023 07:04:03 CET, Harald Sitter wrote: On Mon, Feb 20, 2023 at 1:18 PM Aleix Pol wrote: On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker wrote: ... +1. That said, what we could do is incubate into playground and see if we can assemble the required "Healthy team (healthy proportion of volunteers, inclusive towards new contributors, ideally more than one developer)" if not the incubation would simply fail. I just read a bit through the list of incubating/incubated projects and there are quite a few projects where the team size is exactly 1: TellySkout, Haruna, Homebrew, Mycroft, Snorenotify, BabeQt, KDiff3, Ikona, Kup, TotalReqall, GitKlient, libpercentualcolor (if the information on the wiki page is accurate of course). It feels wrong to incubate a project that is already out of development. Especially when we already have a number of music players... I feel like there is a bit of nuance here. AFAIK neither libvlc nor gstreamer have support for mpd so this does occupy a niche of its own. Now, whether that justifies having yet another UI instead of investing into backend abstraction of one of our existing UIs is another question entirely. A question I would expect to get an answer TBH. Why incubate cantata when we could make elisa or juk grow mpd support? There is a substantial amount of code in the UI. Most likely I'm influenced by my usecase, which mostly revolves around having a huge collection of music and listening to it, but I don't think juk is a good match for that. Its just seems to aim a simple player. Elisa is a bit better in that regard, and certainly looks fancy, but it still elides to much information or doesn't allow me to show it in the first place. And both are missing features Cantata has and I like to use. With all respect for the two players and their authors, but writing an MPD abstraction (which I suspect would not be anywhere near trivial) for them *and* improve them is just a too big task, sorry. (And I'm not sure, given my perceived scope of juk, if it even would be welcomed). That being said, abstractions and reuse would be nice. I can name at least three places where e.g. cover fetching is broken and not having to fix it in three places and maybe even three ways would be nice. Lyrics are a similar topic. Regards, Heiko
Re: Bringing Cantata under the KDE umbrella?
On Tuesday, 21 February 2023 16:23:54 CET, Sandro Knauß wrote: I really would love to see Cantata to be in KDE. At least try if it gets some momentum. But still you are doing the Qt6 port, so without any new features just in maintenance mode I see value in it. features like cached lyrics, lastfm, wikipedia, serverside playlists software written to export lyrics so that they are present when you switch to info-mode Oh all those features can be interesting for other music players, too! So maybe together with the other music players in KDE we can form an API and library and we only have one place to write it ;) That would indeed be a very welcome thing! Regards, Heiko
Usage of KF5/KF6 in targets and CMake config files outside of Frameworks
Hi, while looking at a MR for libkcddb (part of Gear) I wondered if the transition from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in target names and CMake config files for libraries that aren't acutally part of Frameworks. It always seemed a bit illogical and possibly confusing to me to have e.g. KF5Cddb as CMake config file and KF5::Cddb as target name, because it's masquerading to be part of something (Frameworks), which isn't actually true. Especially since we market Frameworks as a common group of libraries, with common rules and policies, which may only be followed in part (or maybe not at all) by other projects. Changing that obviously involves some (temporary) compatibility concerns, but that doesn't play any role with the move to Qt6/KF6. So I suggest to use the chance and get rid of said prefix with the upcoming porting. One example where this was done already some time ago is libkgapi: https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888b7f924a49 Regards, Heiko
Re: Proposal to deprecate KFloppy
On Friday, 28 April 2023 15:16:29 CEST, Nate Graham wrote: Does it work for *anyone* with a modern distro? If not, then I think archiving it makes sense. Time marches on. :) If it does work for *someone* with a modern distro then at the very least the UI needs to detect when it will be broken and tell this to the user in advance to prevent frustration. I think it depends on the floppy kernel module, which should provide the device nodes Jonathan seems to be missing. AFAIK this kernel module isn't needed for "modern" floppy drives connected via USB though, but only for the ancient internal ones. That being said, the kernel module is orphaned. My personal opionion is that that's enough to stop releasing it (after 23.04.3). I also removed it from my distro downstream in 2015 and nobody ever even mentioned it. Regards, Heiko On 4/28/23 06:49, Jonathan Riddell wrote: KFloppy is an old tool to format your floppy diskettes. We packaged KFloppy for the Snap store but it doesn't work, neither does it work for the apt packages. The code depends on features of Linux that do not seem to exist any more, expecting /dev/fd0 and other nodes in /dev. It also depends on having tools like fdformat around which are not packages for Ubuntu any more. I tested it with an external USB floppy drive. The most recent maintainer seems to be Wolfgang Bauer. Can we agree to archive it and stop releases?
Re: KDE Gear projects with failing CI (master)
On Tuesday, 4 July 2023 22:47:12 CEST, Albert Astals Cid wrote: Please work on fixing them, otherwise i will eventually remove the failing CI jobs, it is very important that CI is passing for multiple reasons. = MISC FAILURES (4 repos) = kontrast: * https://invent.kde.org/accessibility/kontrast/-/pipelines/429082 * Several building issues Fixed this (minus the general Android issue).
Suggestion to drop kopete from KDE Gear
Hello, I wanted to keep kopete at least buildable against recent version of its dependencies by removing some obsolete parts. But it occured to me that if I were to continue with that, there wouldn't be much left. It suffers from the same problems with dead or (at least dying) protocols I wrote down for ktp [1], so I'll just add some relevant things affecting kopete: - Contrary to ktp it doesn't use pidgin for ICQ/AIM, but a custom implementation, the result is the same. AIM ceased to exist and ICQ changed its protocol (and thus kopete silently fails to with the latter). - XMPP/Jabber allows to connect, but joining a room crashes kopete, which matches a bug report from 2019 [2] - winpopup was apparently discontinued after Windows XP - qq: I'm hesistant to give them my phone number to manually register an account (the link behind the register button times out). Pidgin removed support for this in 2011, which is roughly the same time a non-porting commit touched the code and there is a bug report that it indeed doesn't work [3] I didn't have/find an instance to test Bonjour and my distro doesn't provide a package for libmeanwhile, so no testing of these. In addition, it has a very long list of (partly very old) bugs [4] (no idea how many, bugzilla stops after 500), and my impression from testing a few is that many of them are easily reproduceably today. As much as I used kopete for chatting back in the day, I seriously think it's broken enough to stop shipping it with Gear, if nobody surprisingly steps up and does at least some basic maintenance. If you know anybody who's still around and cares for kopete, please feel free to bring this mail to their attention. Regards, Heiko [1] https://mail.kde.org/pipermail/release-team/2023-June/013080.html [2] https://bugs.kde.org/show_bug.cgi?id=412228 [3] https://bugs.kde.org/show_bug.cgi?id=460744 [4] https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=2429758&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=kopete&query_format=advanced
Re: QML: a packagers nightmare. Assistance please.
On Wednesday, 8 November 2023 12:48:32 CET, David Redondo wrote: So the situation right now is that plasma-workspace build depends on KWin and KWin has a runtime dependency on plasma-workspace. I think it's not a full cycle since installing plasma-workspace does not need anything from KWin but maybe it can cause problems for distributions? At least no problem here, our package can deal with a build-runtime cycle.
KDE Gear 24.02 bug fix releases and next Gear releases
Hi everyone, the question of the next Gear release (after 24.02) came up in #kde-devel yesterday evening. Due to this, it also occured to me that we haven't scheduled any bug fix releases for 24.02 itself. Which is a bit connected to the first question, because I guess we don't want too many stable branches at the same time (as in more than 1 really). I mostly see three options, but of course please chime if you think of something else: a) Continue with the usual dates, eg. 24.04 and 24.08. (or omitting 24.04 and continue with 24.08 right away) b) Continue with the usual interval, so 24.06, 24.10 and so on c) Slightly change the interval to come back to the proven schedule with its nice numbers divisible by 4, so something like, 24.05 and 24.08. Personally, I'd favour b) or c). I think a) is either too short or too long. Not sure how b) would interact with holiday schedules, exams or distro releases though. Regards, Heiko
Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
On Tuesday, 6 February 2024 22:24:22 CET, Albert Astals Cid wrote: Bad news: 3 repositories are still failing and 11 new repositories started failing kdialog - NEW * https://invent.kde.org/utilities/kdialog/-/pipelines/601189 * flatpak fails in icon-not-found kmag - NEW * https://invent.kde.org/accessibility/kmag/-/pipelines/601207 * flatpak fails in icon-not-found kbackup - NEW * https://invent.kde.org/utilities/kbackup/-/pipelines/601223 * flatpak fails in icon-not-found kirigami-gallery - NEW * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/601366 * flatpak fails in icon-not-found All of the above are fixed now.
Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)
On Tuesday, 20 February 2024 22:30:56 CET, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good News: 11 failing repositories from previous report got fixed Bad news: 3 repositories are still failing and 6 new repositories started failing [...] kmag - 2nd week * https://invent.kde.org/accessibility/kmag/-/pipelines/611893 * flatpak fails in icon-not-found Ah, forgot to cherry-pick to release/24.02, but did that now. klickety - 1st week * https://invent.kde.org/games/klickety/-/pipelines/611894 * appstream test fails in FreeBSD This needs https://github.com/ximion/appstream/commit/d3085b7d1492766f5d7bb5de210c2b11c2e1ead9 added to FreeBSD's appstream package (or a new appstream release).
Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)
On Tuesday, 20 February 2024 22:30:56 CET, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good News: 11 failing repositories from previous report got fixed Bad news: 3 repositories are still failing and 6 new repositories started failing [...] korganizer - 1st week * https://invent.kde.org/pim/korganizer/-/pipelines/611898 * Linux build has linking problem A rebuild of kontactinterface has fixed this.
Re: AppStream Metadata with our releases
On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote: El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va escriure: 22.03.2024 17:22:33 Albert Astals Cid : ... It is some extra work (not a lot, but some). You're asking for the workflow of creating to be releases to be changed by creating the entry in the file earlier, that alone is a bit of work, but it has several other consequences: * https://apps.kde.org/okular/ shows releases from the appstream file (i think) meaning that the code should learn to ignore releases in the future. Arguably we would need also now, but given the data is added just a few days before the actual release i think users can understand "this release will happen soon)" compared to a thing one month in the future * What happens if we have to change the release date or release version number (hasn't happened in a good while, but wouldn't be a bad thing to prepare for it). We would need to update the string or date of an existing entry, as far as I know we don't have tooling for that (because we only add the data to the file when we're almost sure abiyt it). In addition I'm a litte bit wary of conflicts when cherry-picking the appstream changes between branches, which the script does after incrementing the version. I saw at least conflicts in itinerary's releases notes and e.g. kdeconnect's or okular's windows releases in the past, which isn't that much of a problem but it could become one with the 245 modules of gear (to be fair not all have appstream metadata (yet)). Otherwise I'd just miss the opportunity to trigger a CI build for everything again shortly before the release, but I'd guess that's easy to get over. Regards, Heiko
Re: AppStream Metadata with our releases
On Tuesday, 26 March 2024 17:39:25 CET, Volker Krause wrote: On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote: On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote: ... Sorry about that! I try to keep both branches in sync usually, if there is anything I can do/do differently to not impact your work I'm happy to do that of course. No worries, I didn't mean this as an accusation. Just a hint for future (possible mass) additions. Otherwise I'd just miss the opportunity to trigger a CI build for everything again shortly before the release, but I'd guess that's easy to get over. Albert seems to have an alternative way using API (?) for the weekly build status reports, I guess that could be reused/combined somehow? Indeed, we would just loose the conveniently timed rebuild, which seems acceptable and no problem at all with rather active projects. Regards, Heiko
Re: Should we stop distributing source tarballs?
On Thursday, 4 April 2024 13:07:42 CEST, Ben Cooksley wrote: [snip] As an additional aside - we don't currently GPG sign our Git tags, so there is nothing validating that the person who made the release is actually the person whose name is on it. With GPG signatures we can at least validate who owns the key. We *do* sign the tags for KF, Plasma and Gear. And IIRC releasme defaults to signing tags as well. Regards, Heiko
Re: Should we stop distributing source tarballs?
On Thursday, 4 April 2024 13:26:57 CEST, Sune Vuorela wrote: On 2024-04-04, Ben Cooksley wrote: I do also think it is nice if we get someone else to verify that the tarball we ship actually matches the tag. I think some people in distributions have already started looking into verifying that. Hopefully they'll be gentle with tooling that does this? I have only seen 'starting to look into it', not actually yet figuring out what to do with it. But as an approximation, I would expect 'does the tarball content match the tag?' 'can we easily and automatically explain the difference?' 'does it use autotools?' 'can autogenerated docs and stuff be moved to build time instead?' and other such things that might flag it differently and probably for manual inspections. I think we have stopped injecting translations at tarball creation time and our tarballs should actually match the git tags? Yes, that would be my expectation as well, tarballs should be identical to a checked out tag (minus the .git dir).
Re: Should we stop distributing source tarballs?
On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote: It seems a lot of people feel conservative in favor of tarballs, so maybe I aimed too far. At least I think the discussion brought some interesting points that we can explore further. Some I identified: - The tarballs should contain no changes with respect to git, or minimal changes obviously justifiable in a diff. Like I wrote earlier in this thread, this should hold true already since the translations are synced to git. - Tarballs should only be generated in a reproducible manner using scripts. Ideally by the CI only. - We should start to sign tarballs in the CI. The scripts already exists for the bundles and users of releasme. Letting the CI create tarballs seems indeed like a good way to reduce possibilities of human tampering. With regard to signing: At first I thought that it means something that the person responsible for the release is also signing the tarballs. But maybe there could even be two signatures in the future, one by CI and one by the release person (although that would probably mean a few challenges for the tooling). - We should start to sign commits and tags. Git recently made this super easy by allowing signing with the ssh keys that we all are already using to push things, so no excuses for not enabling this. We already sign commits for the 3 release bundles and users of relaseme. But I'm surprised about the total absence of social aspects of the xz incidence during this discussion. Admittedly we fall back to community maintenance if a maintainer becomes unavailable, so the exact xz scenario doesn't seem likely. But there are probably a few projects on the fringes. Do we have safeguards in place if a nefarious person tries to steps up as maintainer? Can we do something to help projects, which are struggling? Regards, Heiko
Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- Review request for Baloo. Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs - src/CMakeLists.txt de044025012ebcccb8a9c7293edfe045cc9b7856 src/file/CMakeLists.txt 4f9fb9dd6b0e680a5f70cfaeb3986000cb192acd Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Review Request 118439: Turn baloo's libraries into a framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118439/ --- Review request for Baloo. Repository: baloo Description --- This turns baloo's libraries into a framework to make it coinstallable with its KDE4 counterpart. As I've said in my first review request (https://git.reviewboard.kde.org/r/118438/) I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs - BalooConfig.cmake.in d389bfd69def803b3bceb1a79ce4c97e4ea4803e CMakeLists.txt fe6b24195eb39d9113004169bf119f4fe991e32b src/core/CMakeLists.txt 844100f5e3ac9aebfb0d267f63742d63d2ad2965 src/core/autotests/CMakeLists.txt d03b0a71848ea3a816d1d4c2ebcf1981e54ba710 src/core/tests/CMakeLists.txt f505379c4b0da41c68e1945f3ae3b7ddccd57910 src/file/lib/CMakeLists.txt 9bfafde198d5033bf1f1558aa7727d109b2c673d src/file/lib/autotests/CMakeLists.txt 0c20b65cf2302bdf1e39d9fc380fd371e699734e src/xapian/CMakeLists.txt 5fcfd090ae479a8a79a37a3e6d0b6246d971a916 Diff: https://git.reviewboard.kde.org/r/118439/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118439: Turn baloo's libraries into a framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118439/ --- (Updated June 11, 2014, 1:03 p.m.) Status -- This change has been marked as submitted. Review request for Baloo. Repository: baloo Description --- This turns baloo's libraries into a framework to make it coinstallable with its KDE4 counterpart. As I've said in my first review request (https://git.reviewboard.kde.org/r/118438/) I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs - BalooConfig.cmake.in d389bfd69def803b3bceb1a79ce4c97e4ea4803e CMakeLists.txt fe6b24195eb39d9113004169bf119f4fe991e32b src/core/CMakeLists.txt 844100f5e3ac9aebfb0d267f63742d63d2ad2965 src/core/autotests/CMakeLists.txt d03b0a71848ea3a816d1d4c2ebcf1981e54ba710 src/core/tests/CMakeLists.txt f505379c4b0da41c68e1945f3ae3b7ddccd57910 src/file/lib/CMakeLists.txt 9bfafde198d5033bf1f1558aa7727d109b2c673d src/file/lib/autotests/CMakeLists.txt 0c20b65cf2302bdf1e39d9fc380fd371e699734e src/xapian/CMakeLists.txt 5fcfd090ae479a8a79a37a3e6d0b6246d971a916 Diff: https://git.reviewboard.kde.org/r/118439/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
> On June 4, 2014, 2:55 p.m., Vishesh Handa wrote: > > I'm not too sure about this. I was planning on moving the runners, kcm and > > kioslaves out of the baloo repository and into plasma-desktop and > > plasma-workspace. This just leaves the executables, which IMO should > > overwrite the old ones, but that would be a problem, right? Well, splitting it out would work for us, too. So that leaves the binaries. If they shouldn't be renamed it would to nice to have a cmake option in order to decide if they should be build. That way we could provide packages with an option allowing the user to build and install the binaries for the version he wants (probably matching his version of Plasma workspaces). I'd be willing to adjust this patch to only make the building of binaries depending on a cmake option, if it's alright with you. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/#review59206 ------- On May 31, 2014, 11:54 a.m., Heiko Becker wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118438/ > --- > > (Updated May 31, 2014, 11:54 a.m.) > > > Review request for Baloo. > > > Repository: baloo > > > Description > --- > > The intention behind this review request is to make it easier to turn baloo > into a framework and make it coinstallable with its KDE4 counterpart in a > second review request. > > That being said I'm not exactly sure this is the way you guys want to go, but > I'd be willing to update my review request accordingly if you have other > plans to make it coinstallable. > > > Diffs > - > > src/CMakeLists.txt de044025012ebcccb8a9c7293edfe045cc9b7856 > src/file/CMakeLists.txt 4f9fb9dd6b0e680a5f70cfaeb3986000cb192acd > > Diff: https://git.reviewboard.kde.org/r/118438/diff/ > > > Testing > --- > > cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. > make > make install > > I've also built the frameworks branch of milou against it (needed a few > modifications). > > > Thanks, > > Heiko Becker > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
> On June 4, 2014, 2:55 p.m., Vishesh Handa wrote: > > I'm not too sure about this. I was planning on moving the runners, kcm and > > kioslaves out of the baloo repository and into plasma-desktop and > > plasma-workspace. This just leaves the executables, which IMO should > > overwrite the old ones, but that would be a problem, right? > > Heiko Becker wrote: > Well, splitting it out would work for us, too. So that leaves the > binaries. If they shouldn't be renamed it would to nice to have a cmake > option in order to decide if they should be build. That way we could provide > packages with an option allowing the user to build and install the binaries > for the version he wants (probably matching his version of Plasma workspaces). > > I'd be willing to adjust this patch to only make the building of binaries > depending on a cmake option, if it's alright with you. > > > Vishesh Handa wrote: > Just to confirm, this patch would also need to go in the KDE4 version as > well, right? Yes, something similar was done for kactivities: http://quickgit.kde.org/?p=kactivities.git&a=commitdiff&h=f6c2bddb07b43ca857098c5bb2661e236d07bb57 (and http://quickgit.kde.org/?p=kactivities.git&a=commitdiff&h=51de5b25d483c45f37918efd690ba1d6dd0c2388 for KF5). - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/#review59206 --- On May 31, 2014, 11:54 a.m., Heiko Becker wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118438/ > --- > > (Updated May 31, 2014, 11:54 a.m.) > > > Review request for Baloo. > > > Repository: baloo > > > Description > --- > > The intention behind this review request is to make it easier to turn baloo > into a framework and make it coinstallable with its KDE4 counterpart in a > second review request. > > That being said I'm not exactly sure this is the way you guys want to go, but > I'd be willing to update my review request accordingly if you have other > plans to make it coinstallable. > > > Diffs > - > > src/CMakeLists.txt de044025012ebcccb8a9c7293edfe045cc9b7856 > src/file/CMakeLists.txt 4f9fb9dd6b0e680a5f70cfaeb3986000cb192acd > > Diff: https://git.reviewboard.kde.org/r/118438/diff/ > > > Testing > --- > > cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. > make > make install > > I've also built the frameworks branch of milou against it (needed a few > modifications). > > > Thanks, > > Heiko Becker > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- (Updated June 18, 2014, 8:41 a.m.) Review request for Baloo. Changes --- The old patch didn't apply anymore. And as a notice: I don't have push access. Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs (updated) - src/CMakeLists.txt 810f6dcd97b5f3ff64962709efbfffec7fa9a257 src/file/CMakeLists.txt dd2e2b2a9fdddefe5568d51427cf69103b1bdd85 Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- (Updated Juli 11, 2014, 8:16 vorm.) Review request for Baloo. Changes --- I had to rebase again. And I have also no push access. Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs (updated) - src/CMakeLists.txt 810f6dcd97b5f3ff64962709efbfffec7fa9a257 src/file/CMakeLists.txt 72b56ea5fb63c1bece1b4959ea5bf7ee3af994b0 Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing (updated) --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- (Updated Juli 23, 2014, 9:29 vorm.) Review request for Baloo. Changes --- Included the search and pim plugins, move option to the root CMakeLists.txt. Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs (updated) - CMakeLists.txt abb494ae32ef27e0ca65da341f5d9a0b37f51645 src/CMakeLists.txt 810f6dcd97b5f3ff64962709efbfffec7fa9a257 src/file/CMakeLists.txt df96fd715866bd159822c5c19c597028fe0e26cd Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- (Updated Juli 25, 2014, 7:24 vorm.) Review request for Baloo. Changes --- Rebased on top of current changes Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs (updated) - CMakeLists.txt abb494ae32ef27e0ca65da341f5d9a0b37f51645 src/CMakeLists.txt 810f6dcd97b5f3ff64962709efbfffec7fa9a257 src/file/CMakeLists.txt b9b4a4cfa55dbbdb533dec0daf2e670406de19c1 Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- (Updated Aug. 1, 2014, 8:54 nachm.) Review request for Baloo. Changes --- Rebased on top of current changes another time. Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs (updated) - CMakeLists.txt abb494ae32ef27e0ca65da341f5d9a0b37f51645 src/CMakeLists.txt 810f6dcd97b5f3ff64962709efbfffec7fa9a257 src/file/CMakeLists.txt 7d384c51662a0b381e6fc861e8565c6da4af8525 Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118438: Add an option to only build baloo's libraries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118438/ --- (Updated Aug. 6, 2014, 2:31 p.m.) Status -- This change has been marked as submitted. Review request for Baloo. Repository: baloo Description --- The intention behind this review request is to make it easier to turn baloo into a framework and make it coinstallable with its KDE4 counterpart in a second review request. That being said I'm not exactly sure this is the way you guys want to go, but I'd be willing to update my review request accordingly if you have other plans to make it coinstallable. Diffs - CMakeLists.txt abb494ae32ef27e0ca65da341f5d9a0b37f51645 src/CMakeLists.txt 810f6dcd97b5f3ff64962709efbfffec7fa9a257 src/file/CMakeLists.txt 7d384c51662a0b381e6fc861e8565c6da4af8525 Diff: https://git.reviewboard.kde.org/r/118438/diff/ Testing --- cmake -DBALOO_LIBRARIES_ONLY:BOOL=TRUE .. make make install I've also built the frameworks branch of milou against it (needed a few modifications). Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Review Request 122219: Fix version number to 5.6.0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122219/ --- Review request for Baloo and Jonathan Riddell. Repository: baloo Description --- It was 5.5.95 before and should match Frameworks. Diffs - CMakeLists.txt 2d7af0b Diff: https://git.reviewboard.kde.org/r/122219/diff/ Testing --- Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 122219: Fix version number to 5.6.0
> On Jan. 23, 2015, 11:47 vorm., Vishesh Handa wrote: > > Yes, please. Sorry, forgot to mention I don't have commit access. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122219/#review74592 --- On Jan. 23, 2015, 10:04 vorm., Heiko Becker wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122219/ > --- > > (Updated Jan. 23, 2015, 10:04 vorm.) > > > Review request for Baloo and Jonathan Riddell. > > > Repository: baloo > > > Description > --- > > It was 5.5.95 before and should match Frameworks. > > > Diffs > - > > CMakeLists.txt 2d7af0b > > Diff: https://git.reviewboard.kde.org/r/122219/diff/ > > > Testing > --- > > > Thanks, > > Heiko Becker > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 122219: Fix version number to 5.6.0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122219/ --- (Updated Jan. 23, 2015, 12:08 p.m.) Status -- This change has been marked as submitted. Review request for Baloo and Jonathan Riddell. Repository: baloo Description --- It was 5.5.95 before and should match Frameworks. Diffs - CMakeLists.txt 2d7af0b Diff: https://git.reviewboard.kde.org/r/122219/diff/ Testing --- Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Review Request 124076: autotests: Use QTEST_GUILESS_MAIN
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124076/ --- Review request for Baloo. Repository: baloo Description --- ... to allow running the tests without a display server. Diffs - autotests/unit/file/basicindexingjobtest.cpp ab003b6 autotests/unit/file/fileindexerconfigtest.cpp ae88ea1 autotests/unit/file/filtereddiriteratortest.cpp 4447990 autotests/unit/file/kinotifytest.cpp 2261824 autotests/unit/file/metadatamovertest.cpp 18697b6 autotests/unit/file/pendingfilequeuetest.cpp 8f23fc3 autotests/unit/file/regularexpcachebenchmark.cpp 211faa5 autotests/unit/file/unindexedfileiteratortest.cpp f3b3f3f autotests/unit/lib/filemonitortest.cpp 57ed264 Diff: https://git.reviewboard.kde.org/r/124076/diff/ Testing --- All changed tests still ran successfully. Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 124076: autotests: Use QTEST_GUILESS_MAIN
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124076/ --- (Updated June 11, 2015, 11:22 p.m.) Status -- This change has been marked as submitted. Review request for Baloo. Changes --- Submitted with commit e2be53ea79be4598760be0596ad474abd03d0b73 by Heiko Becker to branch master. Repository: baloo Description --- ... to allow running the tests without a display server. Diffs - autotests/unit/file/basicindexingjobtest.cpp ab003b6 autotests/unit/file/fileindexerconfigtest.cpp ae88ea1 autotests/unit/file/filtereddiriteratortest.cpp 4447990 autotests/unit/file/kinotifytest.cpp 2261824 autotests/unit/file/metadatamovertest.cpp 18697b6 autotests/unit/file/pendingfilequeuetest.cpp 8f23fc3 autotests/unit/file/regularexpcachebenchmark.cpp 211faa5 autotests/unit/file/unindexedfileiteratortest.cpp f3b3f3f autotests/unit/lib/filemonitortest.cpp 57ed264 Diff: https://git.reviewboard.kde.org/r/124076/diff/ Testing --- All changed tests still ran successfully. Thanks, Heiko Becker >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Review Request 125818: Use KDE_INSTALL_FULL_DBUSINTERFACEDIR to install dbus interfaces
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125818/
---
Review request for Baloo and Vishesh Handa.
Repository: baloo
Description
---
Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- It's helpful on a multiarch layout where the prefix is /usr/${host}
but arch-independent files should still be installed to /usr/share.
Diffs
-
KF5BalooConfig.cmake.in 08413efa29290c37dc501cc2ec1eb86d13218981
src/dbus/CMakeLists.txt 44240ec643eef69f90b3832314ede46bca1820e5
src/dbus/fake/CMakeLists.txt c9735b3d176c4a3c7ee995dac0aa83a3b715bf7c
Diff: https://git.reviewboard.kde.org/r/125818/diff/
Testing
---
Successfully installed it with
-DCMAKE_INSTALL_PREFIX:PATH=/usr/x86_64-pc-linux-gnu and
-DCMAKE_INSTALL_FULL_DATAROOTDIR:PATH=/usr/share
Thanks,
Heiko Becker
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 125818: Use KDE_INSTALL_DBUSINTERFACEDIR to install dbus interfaces
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125818/
---
(Updated Okt. 27, 2015, 6:53 nachm.)
Review request for Baloo and Vishesh Handa.
Changes
---
Adjusted to match similar changes to kwallet
Summary (updated)
-
Use KDE_INSTALL_DBUSINTERFACEDIR to install dbus interfaces
Repository: baloo
Description (updated)
---
...and use PATH_VARS to make the config file work with absolute paths.
Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- By not hard-coding the packackage prefix, it's helpful on a multiarch
layout where the prefix is /usr/${host} but arch-independent files
should still be installed to /usr/share (i.e a level below the
prefix).
Diffs (updated)
-
CMakeLists.txt 9f719667902cd13257b59113f1eb8bb0e8515d28
KF5BalooConfig.cmake.in 08413efa29290c37dc501cc2ec1eb86d13218981
src/dbus/CMakeLists.txt 44240ec643eef69f90b3832314ede46bca1820e5
src/dbus/fake/CMakeLists.txt c9735b3d176c4a3c7ee995dac0aa83a3b715bf7c
Diff: https://git.reviewboard.kde.org/r/125818/diff/
Testing
---
Successfully installed it with
-DCMAKE_INSTALL_PREFIX:PATH=/usr/x86_64-pc-linux-gnu and
-DCMAKE_INSTALL_FULL_DATAROOTDIR:PATH=/usr/share
Thanks,
Heiko Becker
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 125818: Use KDE_INSTALL_DBUSINTERFACEDIR to install dbus interfaces
> On Okt. 27, 2015, 6:22 nachm., Vishesh Handa wrote:
> > I really have no idea about this. If you're sure about this go ahead.
I previously put up a review for kwallet:
https://git.reviewboard.kde.org/r/125819/ which has been accepted in the
meatime.
This also has been done for other frameworks. Two examples:
https://quickgit.kde.org/?p=knotifications.git&a=commit&h=6e04d368e400d7e5eedbc2ef4c2e9fab3a1a8052
https://quickgit.kde.org/?p=knotifications.git&a=commit&h=6e04d368e400d7e5eedbc2ef4c2e9fab3a1a8052
- Heiko
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125818/#review87535
---
On Okt. 27, 2015, 6:53 nachm., Heiko Becker wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125818/
> ---
>
> (Updated Okt. 27, 2015, 6:53 nachm.)
>
>
> Review request for Baloo and Vishesh Handa.
>
>
> Repository: baloo
>
>
> Description
> ---
>
> ...and use PATH_VARS to make the config file work with absolute paths.
>
> Two reasons to do this:
> - DBUS_INTERFACES_INSTALL_DIR is marked deprecated
> - By not hard-coding the packackage prefix, it's helpful on a multiarch
> layout where the prefix is /usr/${host} but arch-independent files
> should still be installed to /usr/share (i.e a level below the
> prefix).
>
>
> Diffs
> -
>
> CMakeLists.txt 9f719667902cd13257b59113f1eb8bb0e8515d28
> KF5BalooConfig.cmake.in 08413efa29290c37dc501cc2ec1eb86d13218981
> src/dbus/CMakeLists.txt 44240ec643eef69f90b3832314ede46bca1820e5
> src/dbus/fake/CMakeLists.txt c9735b3d176c4a3c7ee995dac0aa83a3b715bf7c
>
> Diff: https://git.reviewboard.kde.org/r/125818/diff/
>
>
> Testing
> ---
>
> Successfully installed it with
> -DCMAKE_INSTALL_PREFIX:PATH=/usr/x86_64-pc-linux-gnu and
> -DCMAKE_INSTALL_FULL_DATAROOTDIR:PATH=/usr/share
>
>
> Thanks,
>
> Heiko Becker
>
>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 125818: Use KDE_INSTALL_DBUSINTERFACEDIR to install dbus interfaces
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125818/
---
(Updated Oct. 27, 2015, 9:59 p.m.)
Status
--
This change has been marked as submitted.
Review request for Baloo and Vishesh Handa.
Changes
---
Submitted with commit f653fb6b7e30d7f2355b18c9feb917b525fddf65 by Heiko Becker
to branch master.
Repository: baloo
Description
---
...and use PATH_VARS to make the config file work with absolute paths.
Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- By not hard-coding the packackage prefix, it's helpful on a multiarch
layout where the prefix is /usr/${host} but arch-independent files
should still be installed to /usr/share (i.e a level below the
prefix).
Diffs
-
CMakeLists.txt 9f719667902cd13257b59113f1eb8bb0e8515d28
KF5BalooConfig.cmake.in 08413efa29290c37dc501cc2ec1eb86d13218981
src/dbus/CMakeLists.txt 44240ec643eef69f90b3832314ede46bca1820e5
src/dbus/fake/CMakeLists.txt c9735b3d176c4a3c7ee995dac0aa83a3b715bf7c
Diff: https://git.reviewboard.kde.org/r/125818/diff/
Testing
---
Successfully installed it with
-DCMAKE_INSTALL_PREFIX:PATH=/usr/x86_64-pc-linux-gnu and
-DCMAKE_INSTALL_FULL_DATAROOTDIR:PATH=/usr/share
Thanks,
Heiko Becker
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: building krita 3.1.1 with gcc6
Hi,
On 12/15/16 23:59, Andreas Müller wrote:
> I am maintaining a yocto/openembedded layer supporting kde/plasma for
> cross builds. Just tried to build krita 3.1.1 and got an error like
> that reported in [1].
>
> We had lots of erros in recent past and they were fixed by adding
> -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1'. Since this did not seem to work
> for krita I checked and found that there are lots of
>
> include_directories(SYSTEM ${FOO_DIR})
>
> in cmake files.
>
> For now I helped myself by a dirty
>
> sed -i 's:-isystem:-I:g' `find ${B} -name *.make`
>
> after cmake's configure but it would make packer's life easier to
> think about removing SYSTEM in (some) include_directories.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
besides the WONTFIX bug in gcc there's also a cmake bug [1]. You might
want to play with CMAKE_C{,XX}_IMPLICIT_INCLUDE_DIRECTORIES. The problem
is hidden for most people using default include dirs, but becomes
apparent when cross-compiling or using unusual include dirs.
Btw, as far as i know Krita has a mailing list of its own.
Cheers,
Heiko
[1] https://gitlab.kitware.com/cmake/cmake/issues/16291
Re: KDE Gear projects with failing CI (master) (2 July 2024)
On Wednesday, 3 July 2024 14:29:05 CEST, christ...@cullmann.io wrote: On 2024-07-03 12:59, Ben Cooksley wrote: On Wed, Jul 3, 2024 at 9:21 AM Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. ... Probably related to changes in Breeze to use RCC/QRC instead of installing icons on disk? Hmm, that would be rather strange, per default still all icons are installed, the lib is just there in addition. Yep. https://invent.kde.org/frameworks/breeze-icons/-/commit/3e2ad6c1a86f08ac9e1106b13b6ff5d458d313ed broke it. I forgot what minimum size flatpaks want, but we may want a larger size again. Regards, Heiko
Re: Changing dependencies for a project
On Wednesday, 10 July 2024 01:51:16 CEST, David Jarvie wrote: On Tuesday, 9 July 2024 23:47:30 BST Albert Astals Cid wrote: El dimarts, 9 de juliol del 2024, a les 22:12:40 (CEST), David Jarvie va escriure: ... If I'd created a merge request, it would presumably have just sat there unmergeable because of the missing CI dependency. How does a new dependency get added to the CI? I've changed everything I can find in the KAlarm repository relating to the dependencies, so is there something else I need to do to set up the new dependencies? You can a) file a sysadmin ticket or b) create a MR for https://invent.kde.org/sysadmin/ci-images/ adding the dependency to the images. It seems, judging from a quick look, that vlc is missing for the qt6 variants because it pulls in qt5. Regards, Heiko
Re: KDE Gear projects with failing CI (release/24.08) (22 October 2024)
On Wednesday, 23 October 2024 00:10:02 CEST, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Bad news: 6 repositories have started failing [...] falkon - NEW * https://invent.kde.org/network/falkon/-/pipelines/802220 * Missing shiboken files? I just fixed that here as well, it's a 6.8 regression. PySide6 needs https://code.qt.io/cgit/pyside/pyside-setup.git/commit/?h=6.8&id=12aba6c4dfafe191a4640e3ab755a1c7e2ddfc44 and https://code.qt.io/cgit/pyside/pyside-setup.git/commit/?h=6.8&id=cacc9c5803a6dec820dd46211a836453183c8dab
Re: KDE Gear projects with failing CI (master) (27 November 2024)
On Wednesday, 27 November 2024 22:09:28 CET, Heiko Becker wrote: kdenetwork-filesharing - NEW * https://invent.kde.org/network/kdenetwork-filesharing/-/pipelines/828032 * fails to compile * is this a regression from elsewhere? This repo hasn't change in a bit It has changed, at least the translations have. https://invent.kde.org/network/kdenetwork-filesharing/-/commit/56a75283dc9ce7ea3124e99c48950005050b445d is the commit which broke it. It took me a while to see it, but there's a quotation mark, which isn't closed: https://invent.kde.org/network/kdenetwork-filesharing/-/commit/56a75283dc9ce7ea3124e99c48950005050b445d Sorry, the second link should be https://invent.kde.org/network/kdenetwork-filesharing/-/commit/56a75283dc9ce7ea3124e99c48950005050b445d#a96fcda03499843cbc4d88bb92d76990fdef368f_228_233
Re: KDE Gear projects with failing CI (master) (27 November 2024)
On Wednesday, 27 November 2024 20:43:37 CET, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. [...] kdenetwork-filesharing - NEW * https://invent.kde.org/network/kdenetwork-filesharing/-/pipelines/828032 * fails to compile * is this a regression from elsewhere? This repo hasn't change in a bit It has changed, at least the translations have. https://invent.kde.org/network/kdenetwork-filesharing/-/commit/56a75283dc9ce7ea3124e99c48950005050b445d is the commit which broke it. It took me a while to see it, but there's a quotation mark, which isn't closed: https://invent.kde.org/network/kdenetwork-filesharing/-/commit/56a75283dc9ce7ea3124e99c48950005050b445d I'm not sure how to contact Belarusian translators though, there's no team on l10n.kde.org and there's no "be" component on bugs.kde.org Regards, Heiko
Re: Various KDE libraries are empty... is this a bug?
Hello George, On Friday, 27 December 2024 08:49:16 CET, George R Goffe wrote: Howdy, I have a Fedora 42 x86_64 system that's about 3 days old... "out of the box". I have added "groups" of packages to the system and am now receiving the below enclosed messages about libraries being empty. I sounds very much like a question for a Fedora channel. KDE doesn't ship these binaries. Regards, Heiko Please note that the problem is NOT related to the nco package. Thanks, George... dnf upgrade nco Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Reinstalling: nco x86_64 5.3.0-1.fc42 rawhide 9.9 MiB replacing nco x86_64 5.3.0-1.fc42 rawhide 9.9 MiB Transaction Summary: Reinstalling: 1 package Replacing: 1 package Total size of inbound packages is 4 MiB. Need to download 4 MiB. After this operation, 0 B extra will be used (install 10 MiB, remove 10 MiB). Is this ok [y/N]: [1/1] nco-0:5.3.0-1.fc42.x86_64 100% | 1.3 MiB/s | 4.1 MiB | 00m03s [1/1] Total 100% | 1.2 MiB/s | 4.1 MiB | 00m04s Running transaction [1/4] Verify package files 100% | 17.0 B/s | 1.0 B | 00m00s [2/4] Prepare transaction 100% | 0.0 B/s | 2.0 B | 00m03s [3/4] Reinstalling nco-0:5.3.0-1.fc42.x 100% | 7.6 MiB/s | 9.9 MiB | 00m01s Running post-install scriptlet: nco-0:5.3.0-1.fc42.x86_64 Finished post-install scriptlet: nco-0:5.3.0-1.fc42.x86_64 Scriptlet output: /sbin/ldconfig: File /lib64/libkdeinit4_kcmshell4.so is empty, not checked. /sbin/ldconfig: File /lib64/libmolletnetwork.so.4.14.38 is empty, not checke ... ldconfig: File /lib64/libkdeinit4_kcmshell4.so is empty, not checked. ldconfig: File /lib64/libmolletnetwork.so.4.14.38 is empty, not checked. ldconfig: File /lib64/libKF5Contacts.so.5.116.0 is empty, not checked. ldconfig: File /lib64/libKF5Contacts.so.5 is empty, not checked. ldconfig: File /lib64/libosp.so.5.0.0 is empty, not checked. ldconfig: File /lib64/libkactivities.so.6 is empty, not checked. ldconfig: File /lib64/libmolletnetwork.so.4 is empty, not checked. ldconfig: File /lib64/libosp.so.5 is empty, not checked. ldconfig: File /lib64/libkactivities.so.6.2.0 is empty, not checked. ldconfig: File /lib64/libknotifyplugin.so is empty, not checked. ldconfig: File /lib64/libkdeinit4_kglobalaccel.so is empty, not checked. ldconfig: File /lib64/libkdeinit4_kcmshell4.so is empty, not checked. ldconfig: File /lib64/libmolletnetwork.so.4.14.38 is empty, not checked. ldconfig: File /lib64/libKF5Contacts.so.5.116.0 is empty, not checked. ldconfig: File /lib64/libKF5Contacts.so.5 is empty, not checked. ldconfig: File /lib64/libosp.so.5.0.0 is empty, not checked. ldconfig: File /lib64/libkactivities.so.6 is empty, not checked. ldconfig: File /lib64/libmolletnetwork.so.4 is empty, not checked. ldconfig: File /lib64/libosp.so.5 is empty, not checked. ldconfig: File /lib64/libkactivities.so.6.2.0 is empty, not checked. ldconfig: File /lib64/libknotifyplugin.so is empty, not checked. ldconfig: File /lib64/libkdeinit4_kglobalaccel.so is empty, not checked. [4/4] Removing nco-0:5.3.0-1.fc42.x86_6 100% | 5.0 B/s | 79.0 B | 00m15s Running post-uninstall scriptlet: nco-0:5.3.0-1.fc42.x86_64 Finished post-uninstall scriptlet: nco-0:5.3.0-1.fc42.x86_64 Scriptlet output: /sbin/ldconfig: File /lib64/libkdeinit4_kcmshell4.so is empty, not checked. /sbin/ldconfig: File /lib64/libmolletnetwork.so.4.14.38 is empty, not checke ... Complete!
Re: KDE Gear projects with failing CI (master) (10 December 2024)
On Wednesday, 11 December 2024 00:08:48 CET, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: 2 repositories were fixed Bad news: 5 repositories started failing ksudoku - NEW * https://invent.kde.org/games/ksudoku/-/pipelines/836274 * craft mac jobs fail https://invent.kde.org/games/ksudoku/-/merge_requests/30 It was easy enough to fix, but it wouldn't have happened if Laurent would use Merge Requests... Regards, Heiko
Re: kde-builder: sphinx fails with "no module named sphinx.builders.qthelp
On Tuesday, 28 January 2025 23:45:22 CET, Alexander Neundorf wrote: I'm trying to build karchive using kde-builder, and it fails with sphinx, sphinx.builders.qthelp is missing. Where should this come from ? Or how can I disable this ? Whatever packages https://pypi.org/project/sphinxcontrib-qthelp/ for your distro, I'd say, or -DBUILD_QTHELP_DOCS=FALSE for ecm. Or -DBUILD_DOC=FALSE for a even more blunt solution. ecm should probably grow a check for that python module, besides the one for Sphinx itself. Regards, Heiko
Re: KDE Gear projects with failing CI (master) (29 July 2025)
On Tuesday, 29 July 2025 18:05:40 CEST, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. [...] artikulate - 2ND WEEK * https://invent.kde.org/education/artikulate/-/pipelines/998441 * freebsd build fails with https://bugreports.qt.io/browse/QTBUG-137196 I gently nudged FreeBSD to add https://code.qt.io/cgit/qt/qtdeclarative.git/commit/?h=6.9&id=672e6777e8e6a8fd86c7877075e7a8aa0ea0a31a to their qtdeclarative package, which appears to have fixed this. Regards, Heiko
