Re: MegaRelease Freezes - Re: Release schedule proposal for the February MegaRelease
On Tue, Sep 26, 2023 at 12:29 AM Albert Astals Cid wrote: > > El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va > escriure: > > https://community.kde.org/Schedules/February_2024_MegaRelease > > > > Beta 1 is during Qt World Summit that is not ideal but I guess doable? > > > > I'll answer to this email with a few other emails things i thing we have to > > discuss to try to organize the discusion earlier. > > Do we want common times for dependency/feature/string freezes for all the 3 > products or different for each of them? > > I have no particular opinion. I'd say that by nature KF needs to freeze before Plasma & Apps. I don't think there's any difference between apps and Plasma. I'll include the Plasma and Frameworks lists JIC. Aleix
Re: KUserFeedback as framework for KF6
+1 On Sat, Jul 15, 2023 at 10:39 PM wrote: > > Hi, > > several of our projects use it, like Plasma and Kate. > > Can we make it a framework for KF6? > > Then we have finally regular releases that include bug fixes. > > Is there some opposition to do that? > I asked in the past but there was just no reaction. > > Greetings > Christoph
Re: kf6 vs. kf5 conflict report
On Wed, Mar 8, 2023 at 3:13 PM Nicolas Fella wrote: > > On 3/8/23 14:02, Harald Sitter wrote: > > with kf6 progressing nicely here's a first conflict report of files > > that appear in both kf6 and kf5 under the same name. this largely > > affects translations and docs it seems. this list may not be entirely > > comprehensive, I've only thrown together a script in a couple minutes. > > Thanks Harald! > > > one question is whether ECM should be co-installable, not sure if that > > has been discussed > > It has come up, and the answer seems to be "No, it will not be > coinstallable". This implies that ECM master will continue to support > Qt5/KF5, but that should not be a huge burden. > > > report for /usr: > > https://collaborate.kde.org/s/3gz2KfoGLsS4TF5 > > > > furthermore the following files outside /usr clash between kf6 and 5: > > '/etc/xdg/accept-languages.codes' > > '/etc/xdg/kshorturifilterrc' > > '/etc/xdg/autostart/baloo_file.desktop' > > '/lib/udev/rules.d/61-kde-bluetooth-rfkill.rules' > > > > HS If ECM master has to support KF5, why do we have a kf5 branch? In fact, I'm pretty sure I switched it eventually because there were regressions. Aleix
Re: Splitting KGlobalAccel interface and runtime
On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens wrote: > > Hello, > > On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote: > > On 2/13/23 22:05, Nicolas Fella wrote: > > > Hi, > > > > > > the kglobalaccel framework currently contains two pieces: kglobalacceld, > > > the runtime component that manages global shortcuts, and an > > > application-side library to interact with it. > > > > > > The two communicate with each other via DBus. On X11 there is a > > > standalone kglobalacceld5 process providing the interface, on Wayland > > > the runtime is linked into KWin and thus the kwin_wayland process > > > provides the interface. > > > > > > The current architecture has a number of downsides: > > > > > > - Any call to the KGlobalAccel library may DBus-activate the > > > kglobalacceld5 process, which may be undesired on Desktop other than > > > Plasma since it competes with their native shortcut system. We tried > > > fixing that by making such calls no-op on !Plasma, but that broke things > > > for people that did want it to run, for example people using KWin with > > > LXQt, because KWin relies on KGlobalAccel for shortcuts > > > > > > - We want to keep the dependencies of the interface library minimal, > > > which is inconvenient for the development of the runtime part. For > > > example we really want to use KIO::ApplicationLauncherJob in the > > > runtime, but currently can't, because that would introduce a dependency > > > cycle in Frameworks (KIO depends on KXmlGui, which depends on > > > KGlobalAccel, which would depend on KIO) > > > > > > - Coinstallability of KF5 and KF6. Conceptually there can only be one > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install a > > > kglobalacceld this is going to be problematic. This also means that a > > > KF6-based kglobalacceld must work with a KF5 interface library > > > > > > - Other shortcut daemon implementations. Since somewhat recently there > > > is an XDG Portal for global shortcuts. Platforms like Windows and macOS > > > also have ways for applications to register global shortcuts. While we > > > are currently not using any of these it's very well possible that we > > > would eventually want to use the KGlobalAccel interface library to > > > interact with those. Having the kglobalacceld runtime in the same > > > frameworks therefore doesn't feel right. > > > > > > To address these issues I suggest we split out the runtime part of > > > kglobalaccel into its own project, under the Plasma release group, > > > because that's primarily where it's used/supported. The interface > > > library would remain in frameworks. We have a similar situation with > > > activities, where the manager (kactivitymanagerd) is in Plasma and the > > > interface is in Frameworks. When doing this we'd also change the way how > > > kglobalacceld is started away from DBus activation towards explicitly > > > starting it as part of the Plasma startup. This avoids accidentally > > > launching it when it shouldn't be but still allows to explicitly start > > > outside of Plasma if really wanted. It would also allow for greater > > > flexibility in the development of the runtime, especially around > > > dependency constraints. > > > > > > It wouldn't automatically solve the coinstallability problem of KF5 and > > > KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still > > > conflict with a Plasma-provided kglobalacceld, but it's at least > > > conceptually less messy since it's clear that the Plasma-provided one > > > would be the preferred one to use. > > > > > > Thoughts about this? > > > > +1 > > > > There's one caveat though: given that the library and the runtime parts > > will have different release schedules, we will have to be careful about > > protocol changes. Perhaps we could borrow a thing or two from activities? > > Or... move both runtime and API on the Plasma side? This way no problem of > different release schedules and it makes it clear that using it ties you to a > specific desktop anyway? > > With a quick grep it looks like most of the users are already shipped with > Plasma or desktop specific anyway. Granted that leaves with a couple of tough > nuts to crack though. > > Regards. That would make sense. FWIW, on Wayland the kglobalaccel API as it is right now is Plasma-specific. Then there's the XDG Desktop Portals Global Shortcuts spec that should be implemented on apps. So it could make sense to rethink what kglobalaccel is to us. That said, this is quite a bit of work and I'm not sure it should be a top priority. Aleix
On ECMDeprecationSettings
Hi Frederik, I wonder if it would make sense to have the ECMDeprecationSettings calls in KDEFrameworkCompilerSettings rather than in each separate framework in a copy-paste manner. As is we need to merge a ton of MRs with copy-pasted contents anyway. Aleix
Re: KF6 meeting notes 2022-04-12
Hi Volker, Thanks a lot for the notes! It makes it easier to follow the work even if I'm unable to join lately. One question, how does co-installability affect flatpak? If anything, the environment is much more controlled so it shouldn't matter that much (?). Aleix On Tue, Apr 12, 2022 at 9:24 PM Volker Krause wrote: > > https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/3 > > https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/131 > - needs review/feedback > - interesting part is openColorScheme() in kcolorschemehelpers_p.h > - existing benchmark in the tests shows no change > - might not work with Plasma's accent color feature, as that uses kdeglobals > - possible approach: store only the accent color in kdeglobals, next to the > color scheme name, and move the colors kcm color mixing code for this to > KColorScheme > > https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/ > 3#note_425424 > - QDesktopWidget porting details noted in the issue > - plasma-framework builds, plasma-workspace only blocked by kwayland-server > issues with the QDesktopWidget uses resolved > - plasma-desktop's biggest issue is the kdelibs4support use in the date/times > KCM > > https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/ > 3#note_431116 > - two people in favor on mailing list, no objections, so let's go with this > > https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/ > 3#note_431647 > - only two applets access KPackage this way, so impact would be quite minimal > - let's do it > > Co-installability/co-usability of KIO slaves with different major versions > - kio-extras is not going to be co-installable could be a problem for this > - also affects previews, context menu plugins, etc > - everything plugin related is in versioned locations, so this is actually co- > installable > - similar problem with Ark's file manager integration plugins > - when transitioning those to 6 would degrade 5-based consumers > - probably needs kio-extras to be co-installable after all > - for cases like ark, we might want a "plugins only" build flag, in 5 already > - also helps with Flatpak bundling > > next meeting: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/ > issues/4
Re: RFC: Frameworks headers install location
Back when we did KF5, what we tried to do was mainly to make sure kde4
code still compiled after the big split.
I think that stanradrising how they're placed within submodules of
include/KF6 is a good idea.
The fact that headers from some repositories can be included using the
project name is more an artifact of time than a feature. Those that
are meant to be used that way (e.g. Plasma or Purpose), are already
namespaced within "include/KF*/".
Ensuring that no KF6 project brings "include/KF6" as its include
directories will be a useful cleanup.
Aleix
On Tue, Apr 5, 2022 at 4:19 PM Ahmad Samir wrote:
>
> Hello.
>
> - In KF5, ECM, magically, added /usr/include/KF5/ to the CMake targets
> interface include directories
> (IIUC for reasons of backwards compatibility, which was necessary in the 4-5
> transition era, I could
> be wrong because I wasn't around at that time :))
>
> - While building KF against Qt6, this suddenly broke building in some modules
> due to #include
> directives not finding the headers, as /usr/include/KF6/ didn't have the same
> magic-injection
> treatment as KF5
>
> - To fix the issue, proper paths had to be added to targets interface include
> directories so that
> module A linking against module B will have the proper include paths to
> search for headers
>
> - The typical include dir layout for a KF module is:
> /usr/include/KF*/ModuleName/{ForwardingHeaderA,headera.h}
>
> e.g. KCMutils, #include , and /usr/include/KF5/KCMUtils added
> to KCMutils target
> include dirs.
>
> - If there is a namespace, the original plan was to guard the include paths,
> by making them match
> the C++ namespaces, e.g.:
> /usr/include/KF*/ModuleName/NameSpace/ForwardingHeaderA
> /usr/include/KF*/ModuleName/namespace/headera.h
>
> e.g. KSynatxHighlighting:
> /usr/include/KF*/KSyntaxHighlighting/
> /usr/include/KF*/KSyntaxHighlighting/KSyntaxHighlighting/Repository
> /usr/include/KF*/KSyntaxHighlighting/ksyntaxhighlighting/repository.h
>
>
> There are some issues with the namespace use-case:
> - On case-insensitive and/or case-preserving filesystems (which still exist
> in 2022...) extra care
> has to be taken so that installation actually works, as you can't have two
> dirs in the same path
> with the same name but different cases
> - Compiler warnings when using e.g. #include
> if the dir that was
> installed first was ksyntaxhighlighting, and all files ended up there (and
> vice-versa, e.g. if the
> CamelCase dir got installed first #include
> would give a warning)
> - A more complicated layout
>
> The proposal is to change the layout when there is a namespace:
> - Only have one dir, /usr/include/KF*/ModuleName/NameSpace/, where all
> headers (ForwadingHeaders and
> lowercase.h ones) are installed
>
>
> Pros:
> - less complicated layout/setup (simpler CMake code)
> - all KDE namespaces are CamelCase, we don't have any that are lower case
> - we promote/encourage using FowardingHeaders everywhere; that's what we use
> in our own code and
> what the API docs advise to use
>
> Cons:
> - The case not matching when using , but as
> I said above the
> argument for this is mitigated by the fact that all our namespaces are
> CamelCase
>
> If we agree with that change this will be for KF6 so as not to break source
> compatibility for KF5.
>
> Best regards,
> Ahmad Samir
Re: portal drag and drop helpers and where to put them
Maybe the alternative would be to use the kdbusaddons for this? It seems to me like there's no kcoreaddons things being done. To make it more weird and complex, if we think of K*Addons frameworks an extension to their Qt* counterpart, I guess it should be abstracted behind something in QtGui, although I agree that in this case it would be rather messy to have it in KGuiAddons. 0'02€ from Aleix On Mon, Apr 11, 2022 at 11:46 PM Albert Astals Cid wrote: > > El dimecres, 6 d’abril de 2022, a les 13:28:50 (CEST), Harald Sitter va > escriure: > > https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212 > > > > To get sandboxed apps to work with drag and drop we need to have drags > > take a roundtrip through xdg-desktop-portal and unfortunately enough > > that needs to happen by passing an open fd into the relevant API, > > presumably to demonstrate that the sender actually can open the file > > they want to send. To that end the sender would call a helper > > function to extend qmimedata with the relevant transfer context and > > the receiver needs to reverse that to get to (potentially in-sandbox) > > paths again. > > > > On top of that there's also the fact that we can drag and drop remote > > sources so we kind of also need to first mount remote urls into the > > file system using kio-fuse :( > > > > All in all it's very broad in scope and requires a dependency on > > qtdbus so I'm not sure kcoreaddons is necessarily the place for this > > to live, at the same time we have related API here already so in the > > interest of keeping related things together kcoreaddons kind of makes > > the most sense. In particular since the existing helper function for > > the receiver already existed meaning we get a lot of applciations to > > support this without further changes. > > > > Thoughts would be much appreciated > > Not an expert on the matter but since noone is saying anything let me say > something to see if can spark some more discussion :D > > Personally I think an optional QtDBus dependency in kcoreaddons for this > purpose is acceptable. The systems that need portal-based-drag-n-drop require > dbus, so that's a no brainer for them. The systems where dbus is "strange" > like Android or Windows don't need this feature so it's more than fine to not > provide it. > > Cheers, > Albert > > > > > HS > > > > > >
Re: Critical Denial of Service bugs in Discover
On Sat, Mar 5, 2022 at 8:36 AM Ben Cooksley wrote: > On Fri, Mar 4, 2022 at 12:49 AM Aleix Pol wrote: > >> I'd say wireshark is too low level for what the problem is here. We are >> talking about having too many HTTP requests for specific URLs. >> > > Correct, I guess the difference in our approaches comes from a "before > release" to a "monitor after release" angle to things. > I'd like to see increased scrutiny during the development process as well > to make sure that we release code that operates properly from Day 1. > A way to do this could be using commit hooks that do not allow to reach certain services. (which we discussed in private chat). We could also analyse at cmake time the knsrc files we install, but this has a very limited and specific scope. > I can think two main measures: >> - Trigger an alarm (an e-mail notification?) if there's a specific >> UserAgent that has a specific portion of the queries we have in a specific >> day in the services we care about. >> - Offer plots to see how queries by UserAgent evolve over the last couple >> of months (or couple of years). >> > > At the moment our ability to analyse our logs is somewhat limited by our > Privacy Policy - https://kde.org/privacypolicy/ > Currently we don't have any provision for long term storage of > this information even on an aggregated basis - so we would need to update > this first. > Hopefully the NDA should help here and it doesn't seem all that far away. I know Neofytos and Ade have been working on it lately. The second issue there is that we are transitioning users to contact a CDN > based endpoint (which is substantially more scalable). > This does mean we lose visibility on data such as User Agents and the URLs > being impacted though as we only get aggregated data unless we ask for > raw logs - which makes implementing something like what you've described > much harder. > That does seem like a stopper. Still, it seems like it's not that big of a problem when there is a CDN, so we better worry about the other cases. Aleix
Re: Critical Denial of Service bugs in Discover
I'd say wireshark is too low level for what the problem is here. We are talking about having too many HTTP requests for specific URLs. I can think two main measures: - Trigger an alarm (an e-mail notification?) if there's a specific UserAgent that has a specific portion of the queries we have in a specific day in the services we care about. - Offer plots to see how queries by UserAgent evolve over the last couple of months (or couple of years). Aleix On Thu, Mar 3, 2022 at 9:59 AM Ben Cooksley wrote: > On Thu, Mar 3, 2022 at 8:41 AM Aleix Pol wrote: > >> (dropping the distros list) >> >> @sysadmin have you been able to look into any tools we devs can have to >> make sure this situation doesn't repeat in the future? >> > > Hi Aleix, > > To be honest i've been struggling to think of ways that we could detect > this on the server side prior to it becoming a massive issue. > By the time an issue is evident server side it is usually much too late. > > The main tools i'd usually recommend would be the standard tools you would > use for monitoring the network activity of any application - such as > Wireshark. > > Is there something you were thinking of specifically in terms of us being > able to provide? > > Thanks, > Ben > > >> >> Aleix >> >> On Thu, Feb 10, 2022 at 1:10 PM Aleix Pol wrote: >> >>> On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley wrote: >>> > >>> > >>> > >>> > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol wrote: >>> >> >>> >> [Snip] >>> >> >>> >> We still haven't discussed here is how to prevent this problem from >>> >> happening again. >>> >> >>> >> If we don't have information about what is happening, we cannot fix >>> problems. >>> > >>> > >>> > Part of the issue here is that the problem only came to Sysadmin >>> attention very recently, when the system ran out of disk space as a result >>> of growing log files. >>> > It was at that point we realised we had a serious problem. >>> > >>> > Prior to that the system load hadn't climbed to dangerous levels (> >>> number of CPU cores) and Apache was keeping up with the traffic, so none of >>> our other monitoring was tripped. >>> > >>> > If you have any thoughts on what sort of information you are thinking >>> of that would be helpful. >>> >>> We could have plots of the amount of queries we get with a KNewStuff/* >>> user-agent over time and their distribution. >>> >>> > It would definitely be helpful though to know when new software is >>> going to be released that will be interacting with the servers as we will >>> then be able to monitor for abnormalities. >>> >>> We make big announcements of every Plasma release... (?) >>> >>> >> Is there anything that could be done in this front? The issue here >>> >> could have been addressed months ago, we just never knew it was >>> >> happening. >>> > >>> > >>> > One possibility that did occur to me today would be for us to >>> integrate some kind of killswitch that our applications would check on >>> first initialisation of functionality that talks to KDE.org servers. >>> > This would allow us to disable the functionality in question on user >>> systems. >>> > >>> > The check would only be done on first initialization to keep load low, >>> while still ensuring all users eventually are affected by the killswitch >>> (as they will eventually need to logout/reboot for some reason or another). >>> > >>> > The killswitch would probably work best if it had some kind of version >>> check in it so we could specify which versions are disabled. >>> > That would allow for subsequent updates - once delivered by >>> distributions - to restore the functionality (while leaving it disabled for >>> those who haven't updated). >>> >>> The file we are serving here effectively is the kill switch to all of >>> KNewStuff. >>> >>> Aleix >>> >>
Re: Critical Denial of Service bugs in Discover
(dropping the distros list) @sysadmin have you been able to look into any tools we devs can have to make sure this situation doesn't repeat in the future? Aleix On Thu, Feb 10, 2022 at 1:10 PM Aleix Pol wrote: > On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley wrote: > > > > > > > > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol wrote: > >> > >> [Snip] > >> > >> We still haven't discussed here is how to prevent this problem from > >> happening again. > >> > >> If we don't have information about what is happening, we cannot fix > problems. > > > > > > Part of the issue here is that the problem only came to Sysadmin > attention very recently, when the system ran out of disk space as a result > of growing log files. > > It was at that point we realised we had a serious problem. > > > > Prior to that the system load hadn't climbed to dangerous levels (> > number of CPU cores) and Apache was keeping up with the traffic, so none of > our other monitoring was tripped. > > > > If you have any thoughts on what sort of information you are thinking of > that would be helpful. > > We could have plots of the amount of queries we get with a KNewStuff/* > user-agent over time and their distribution. > > > It would definitely be helpful though to know when new software is going > to be released that will be interacting with the servers as we will then be > able to monitor for abnormalities. > > We make big announcements of every Plasma release... (?) > > >> Is there anything that could be done in this front? The issue here > >> could have been addressed months ago, we just never knew it was > >> happening. > > > > > > One possibility that did occur to me today would be for us to integrate > some kind of killswitch that our applications would check on first > initialisation of functionality that talks to KDE.org servers. > > This would allow us to disable the functionality in question on user > systems. > > > > The check would only be done on first initialization to keep load low, > while still ensuring all users eventually are affected by the killswitch > (as they will eventually need to logout/reboot for some reason or another). > > > > The killswitch would probably work best if it had some kind of version > check in it so we could specify which versions are disabled. > > That would allow for subsequent updates - once delivered by > distributions - to restore the functionality (while leaving it disabled for > those who haven't updated). > > The file we are serving here effectively is the kill switch to all of > KNewStuff. > > Aleix >
Re: Critical Denial of Service bugs in Discover
On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley wrote: > > > > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol wrote: >> >> [Snip] >> >> We still haven't discussed here is how to prevent this problem from >> happening again. >> >> If we don't have information about what is happening, we cannot fix problems. > > > Part of the issue here is that the problem only came to Sysadmin attention > very recently, when the system ran out of disk space as a result of growing > log files. > It was at that point we realised we had a serious problem. > > Prior to that the system load hadn't climbed to dangerous levels (> number of > CPU cores) and Apache was keeping up with the traffic, so none of our other > monitoring was tripped. > > If you have any thoughts on what sort of information you are thinking of that > would be helpful. We could have plots of the amount of queries we get with a KNewStuff/* user-agent over time and their distribution. > It would definitely be helpful though to know when new software is going to > be released that will be interacting with the servers as we will then be able > to monitor for abnormalities. We make big announcements of every Plasma release... (?) >> Is there anything that could be done in this front? The issue here >> could have been addressed months ago, we just never knew it was >> happening. > > > One possibility that did occur to me today would be for us to integrate some > kind of killswitch that our applications would check on first initialisation > of functionality that talks to KDE.org servers. > This would allow us to disable the functionality in question on user systems. > > The check would only be done on first initialization to keep load low, while > still ensuring all users eventually are affected by the killswitch (as they > will eventually need to logout/reboot for some reason or another). > > The killswitch would probably work best if it had some kind of version check > in it so we could specify which versions are disabled. > That would allow for subsequent updates - once delivered by distributions - > to restore the functionality (while leaving it disabled for those who haven't > updated). The file we are serving here effectively is the kill switch to all of KNewStuff. Aleix
Releasing knewstuff 5.91.1
Hi David Faure, As you might have seen, there has been some changes to mitigate a problem with how some applications are accessing our servers. https://invent.kde.org/frameworks/knewstuff/-/commit/c8165b7a0d622e318b3353ccf257a8f229dd12c9 https://invent.kde.org/frameworks/knewstuff/-/commit/e1c6f2bf383876a31cd3e3f9e6edcaa19dc0a7dd We sent an e-mail to distributions asking if they could backport the offending patches and some asked if we could do a patch release of knewstuff which I'd say makes sense. David, would you be able to look into it? Thanks in advance! Aleix
Re: Critical Denial of Service bugs in Discover
On Tue, Feb 8, 2022 at 7:00 PM Ben Cooksley wrote: > > On Tue, Feb 8, 2022 at 4:24 AM Aleix Pol wrote: >> >> On Sat, Feb 5, 2022 at 10:16 PM Ben Cooksley wrote: >> > >> > Hi all, >> > >> > Over the past week or so Sysadmin has been dealing with an extremely high >> > volume of traffic directed towards both download.kde.org and >> > distribute.kde.org. >> > >> > This traffic volume is curious in so far that it is directed at two paths >> > specifically: >> > - distribute.kde.org/khotnewstuff/fonts-providers.xml >> > - download.kde.org/ocs/providers.xml >> > >> > The first path is an "internal only" host which we were redirecting a >> > legacy path to prior to the resource being relocated to cdn.kde.org. The >> > second path has been legacy for numerous years now (more than 5) and is >> > replaced by autoconfig.kde.org. >> > It is of extreme concern that these paths are still in use - especially >> > the ocs/providers.xml one. >> > >> > The volume of traffic has reached an extent that to prevent the server >> > disk filling up we have had to disable logging for those two sites. Whilst >> > dependent on the time of day the server is currently dealing with the >> > current volume of requests, which is far outside normal specifications: >> > >> > 555 requests/sec - 4.5 MB/second - 8.3 kB/request - .739199 >> > ms/request >> > >> > Analysis of a fragment of logs (comprising just a few minutes of traffic) >> > reveals the following: >> > >> > 63 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" >> > "KNewStuff/5.89.0-discoverupdate/5.23.5" >> > 64 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" >> > "KNewStuff/5.89.0-discoverupdate/5.23.4" >> > 104 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" >> > "KNewStuff/5.90.0-discoverupdate/5.23.90" >> > 105 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" >> > "KNewStuff/5.88.0-discoverupdate/5.23.5" >> >1169 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" >> > "KNewStuff/5.86.0-plasma-discover-update/" >> >1256 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" >> > "KNewStuff/5.90.0-discoverupdate/5.23.5" >> >2905 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "Mozilla/5.0" >> > >> > 86 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 200 6773 "-" >> > "Mozilla/5.0" >> > 130 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "KNewStuff/5.89.0-discoverupdate/5.23.5" >> > 136 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "KNewStuff/5.89.0-discoverupdate/5.23.4" >> > 197 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "KNewStuff/5.88.0-discoverupdate/5.23.5" >> > 199 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "KNewStuff/5.90.0-discoverupdate/5.23.90" >> >2624 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "KNewStuff/5.86.0-plasma-discover-update/" >> >2642 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "KNewStuff/5.90.0-discoverupdate/5.23.5" >> >6117 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" >> > "Mozilla/5.0" >> > >> > This indicates that the bug lies solely within Plasma's Discover component >> > - more precisely it's updater. >> > >> > Examining the origin of these requests has indicated that some clients are >> > making requests to these paths well in excess of several times a minute >> > with a number of IP addresses appearing more 60 times in a 1 minute sized >> > sample window. >> > >> > Given that Sysadmin has raised issues with this component and it's >> > behaviour in the past, it appears that issues regarding the behaviour of >> > the OCS componentry within Discover remain unresolved. >> > >> > Due to the level of distress this is causing our systems, I am therefore >> > left with no other option other
Re: Critical Denial of Service bugs in Discover
On Sat, Feb 5, 2022 at 10:16 PM Ben Cooksley wrote: > > Hi all, > > Over the past week or so Sysadmin has been dealing with an extremely high > volume of traffic directed towards both download.kde.org and > distribute.kde.org. > > This traffic volume is curious in so far that it is directed at two paths > specifically: > - distribute.kde.org/khotnewstuff/fonts-providers.xml > - download.kde.org/ocs/providers.xml > > The first path is an "internal only" host which we were redirecting a legacy > path to prior to the resource being relocated to cdn.kde.org. The second path > has been legacy for numerous years now (more than 5) and is replaced by > autoconfig.kde.org. > It is of extreme concern that these paths are still in use - especially the > ocs/providers.xml one. > > The volume of traffic has reached an extent that to prevent the server disk > filling up we have had to disable logging for those two sites. Whilst > dependent on the time of day the server is currently dealing with the current > volume of requests, which is far outside normal specifications: > > 555 requests/sec - 4.5 MB/second - 8.3 kB/request - .739199 > ms/request > > Analysis of a fragment of logs (comprising just a few minutes of traffic) > reveals the following: > > 63 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" > "KNewStuff/5.89.0-discoverupdate/5.23.5" > 64 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" > "KNewStuff/5.89.0-discoverupdate/5.23.4" > 104 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" > "KNewStuff/5.90.0-discoverupdate/5.23.90" > 105 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" > "KNewStuff/5.88.0-discoverupdate/5.23.5" >1169 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" > "KNewStuff/5.86.0-plasma-discover-update/" >1256 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" > "KNewStuff/5.90.0-discoverupdate/5.23.5" >2905 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "Mozilla/5.0" > > 86 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 200 6773 "-" > "Mozilla/5.0" > 130 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "KNewStuff/5.89.0-discoverupdate/5.23.5" > 136 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "KNewStuff/5.89.0-discoverupdate/5.23.4" > 197 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "KNewStuff/5.88.0-discoverupdate/5.23.5" > 199 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "KNewStuff/5.90.0-discoverupdate/5.23.90" >2624 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "KNewStuff/5.86.0-plasma-discover-update/" >2642 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "KNewStuff/5.90.0-discoverupdate/5.23.5" >6117 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" > "Mozilla/5.0" > > This indicates that the bug lies solely within Plasma's Discover component - > more precisely it's updater. > > Examining the origin of these requests has indicated that some clients are > making requests to these paths well in excess of several times a minute with > a number of IP addresses appearing more 60 times in a 1 minute sized sample > window. > > Given that Sysadmin has raised issues with this component and it's behaviour > in the past, it appears that issues regarding the behaviour of the OCS > componentry within Discover remain unresolved. > > Due to the level of distress this is causing our systems, I am therefore left > with no other option other than to direct the Plasma Discover developers to > create and release without delay patches for all versions in support, as well > as for all those currently present in any actively maintained distributions, > that disable all OCS functionality in the Discover updater. Distributions are > requested to treat these patches as security patches and to distribute them > to users without delay. > > In 24 hours time Sysadmin will be making a posting to kde-announce requesting > that users immediately cease use of the Discover update client as it is > creating a Denial of Service attack on our infrastructure. I feel like your response here is out of proportion. Last time we had this conversation, my impression was that the problem was addressed for the most part. If you wanted people working on KNewStuff, Attica or OCS to take any actions, we needed to at the very least have information about you are complaining before you burst out into mailing lists and the likes. In terms of actual solutions this in would probably help to some extent. We never merged it because it's not great design but good results is more important than good design. At the moment they're in their way in but it will take time until it hits users. https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141/ https://invent.kde.org/plasma/discover/-/merge_requests/165/ These were of course not the only mitigation solutions put into place back then. In fact many of them were geared towards
Re: KF6 meeting notes 2022-01-18
> anyone wants to approve that? :) Done On Tue, Jan 18, 2022 at 5:44 PM Volker Krause wrote: > > https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/223 > - so https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/ > 222 instead after all? > - anyone wants to approve that? :) > - once this is in, we need to review the state of unit tests for all > frameworks again > > KQuickCharts > - Arjen has looked into porting to QtShaderTools > - needs some smaller changes to the actual shaders > - build system changes are manageable, but multiple files for a single shader > are a problem (needs concatenating via CMake before passing to QtShaderTools) > - not gotten to actually loading the shaders yet > > https://phabricator.kde.org/T15127#269860 (KF6 status update) > - KWayland still needs the include path fix > - Plasma 6 Sprint in Feb/Mar > - verify that the new QML module system is QML-API compatible, if not we need > to do that transition before the first KF6 release > - transitioning to https://invent.kde.org/frameworks/extra-cmake-modules/-/ > merge_requests/170 now should help with that
KF6 tasks for SoK
Hey, I was thinking that maybe it would be a good opportunity to put some KF6 tasks for SoK. It could be a good way to get people integrated since the tasks are fairly well laid out and we'd be offering a mentor so newcomers can join and know they won't be on their own. What do you think? https://community.kde.org/SoK/Ideas/2022 Aleix
Re: KDE CI: Plasma » plasma-framework » kf5-qt5 FreeBSDQt5.15 - Build # 644 - Still Failing!
Does anyone know why we are having this problem all of a sudden? I cannot
reproduce on my system.
Plasma Workspace is failing the same:
https://build.kde.org/job/Plasma/job/plasma-workspace/job/kf5-qt5%20SUSEQt5.15/1800/
Aleix
On Mon, Oct 18, 2021 at 1:18 PM CI System wrote:
> *BUILD FAILURE*
> Build URL
> https://build.kde.org/job/Plasma/job/plasma-framework/job/kf5-qt5%20FreeBSDQt5.15/644/
> Project: kf5-qt5 FreeBSDQt5.15
> Date of build: Mon, 18 Oct 2021 11:15:42 +
> Build duration: 2 min 2 sec and counting
> * CONSOLE OUTPUT *
> [...truncated 914 lines...]
> [2021-10-18T11:17:43.057Z] :162:1: note: expanded from here
> [2021-10-18T11:17:43.057Z] KSERVICE_DEPRECATED_VERSION_5
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z]
> /usr/home/jenkins/install-prefix/include/KF5/KService/kservice_export.h:380:57:
> note: expanded from macro 'KSERVICE_DEPRECATED_VERSION_5'
> [2021-10-18T11:17:43.057Z] #define KSERVICE_DEPRECATED_VERSION_5(minor,
> text) KSERVICE_DEPRECATED_VERSION_5_##minor(text)
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z] :163:1: note: expanded from here
> [2021-10-18T11:17:43.057Z] KSERVICE_DEPRECATED_VERSION_5_87
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z]
> /usr/home/jenkins/install-prefix/include/KF5/KService/kservice_export.h:376:50:
> note: expanded from macro 'KSERVICE_DEPRECATED_VERSION_5_87'
> [2021-10-18T11:17:43.057Z] # define KSERVICE_DEPRECATED_VERSION_5_87(text)
> KSERVICE_DECL_DEPRECATED_TEXT(text)
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z]
> /usr/home/jenkins/install-prefix/include/KF5/KService/kservice_export.h:220:61:
> note: expanded from macro 'KSERVICE_DECL_DEPRECATED_TEXT'
> [2021-10-18T11:17:43.057Z] #define KSERVICE_DECL_DEPRECATED_TEXT(text)
> __attribute__ ((__deprecated__(text)))
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.622Z] [ 68%] Linking CXX shared library
> ../../../bin/libplatformcomponentsplugin.so
> [2021-10-18T11:17:43.622Z] [ 68%] Building CXX object
> src/plasma/CMakeFiles/KF5Plasma.dir/dataengineconsumer.cpp.o
> [2021-10-18T11:17:43.622Z] [ 68%] Built target platformcomponentsplugin
> [2021-10-18T11:17:43.622Z] [ 68%] Building CXX object
> src/plasma/CMakeFiles/KF5Plasma.dir/service.cpp.o
> [2021-10-18T11:17:43.890Z]
> /usr/home/jenkins/workspace/Plasma/plasma-framework/kf5-qt5
> FreeBSDQt5.15/src/plasma/private/applet_p.cpp:184:105: error: no viable
> conversion from 'QStringList' to 'const QString'
> [2021-10-18T11:17:43.890Z] const QStringList provides =
> q->pluginMetaData().value(QStringLiteral("X-Plasma-Provides"),
> QStringList());
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:265:5:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'QChar' for 1st argument
> [2021-10-18T11:17:43.890Z] QString(QChar c);
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:273:12:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'QString &&' for 1st argument
> [2021-10-18T11:17:43.890Z] inline QString(QString && other) noexcept :
> d(other.d) { other.d = Data::sharedNull(); }
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:967:29:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'QStringDataPtr' for 1st argument
> [2021-10-18T11:17:43.890Z] Q_DECL_CONSTEXPR inline QString(QStringDataPtr
> dd) : d(dd.ptr) {}
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:973:5:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'const char *' for 1st argument
> [2021-10-18T11:17:43.890Z] QString(const char *ch);
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:974:5:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'const QByteArray &' for 1st argument
> [2021-10-18T11:17:43.890Z] QString(const QByteArray );
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z]
> /usr/local/include/qt5/QtCore/qstring.h:1067:17: note: candidate
> constructor not viable: no known conversion from 'QStringList' to
> 'QLatin1String' for 1st argument
> [2021-10-18T11:17:43.890Z] inline QString::QString(QLatin1String aLatin1)
> : d(fromLatin1_helper(aLatin1.latin1(), aLatin1.size()))
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z]
> /usr/local/include/qt5/QtCore/qstring.h:1093:17: note: candidate
> constructor not viable: no known conversion from 'QStringList' to 'const
> QString &' for 1st argument
> [2021-10-18T11:17:43.890Z] inline QString::QString(const QString )
> noexcept : d(other.d)
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:264:14:
> note: explicit constructor is not a candidate
>
Re: OCS Providers File - High Numbers of Requests
On Fri, Sep 24, 2021 at 8:26 PM Ben Cooksley wrote: > > On Sat, Sep 25, 2021 at 12:34 AM Aleix Pol wrote: >> >> On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez >> wrote: >> > >> > El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) >> > escribió: >> > > >> > > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez >> > > wrote: >> > > > >> > > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) >> > > > escribió: >> > > > > >> > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley >> > > > > wrote: >> > > > > > >> > > > > > Hi all, >> > > > > > >> > > > > > It has recently come to our attention that the number of queries >> > > > > > being handled for the endpoint >> > > > > > https://autoconfig.kde.org/ocs/providers.xml on a day to day basis >> > > > > > has gotten to the point where it is causing issues with server >> > > > > > responsiveness to other traffic. This is perhaps best summarised >> > > > > > by the following: >> > > > > > >> > > > > > root@nicoda /var/log/apache2 # ls -lah ... >> > > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 >> > > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 >> > > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 >> > > > > > >> > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l >> > > > > > 4,222,343 >> > > > > > >> > > > > > Based on those numbers we're looking at 48-49 requests per second >> > > > > > (on average - peaks are much higher by many magnitudes), which >> > > > > > seems extremely excessive given that this file is only supposed to >> > > > > > be retrieved by KDE software when GHNS functionality is triggered. >> > > > > > That is supported by the substantial size difference it has over >> > > > > > networkcheck.kde.org - which is used by plasma-nm and >> > > > > > NetworkManager (on Neon) to check for whether they have a working >> > > > > > internet connection - which i'd expect to be the site receiving >> > > > > > the most traffic. >> > > > > > >> > > > > > As such, I therefore suspect we have bug(s) in software that makes >> > > > > > use of GHNS functionality. >> > > > > > >> > > > > > It would therefore be appreciated if we could please review the >> > > > > > software in question to determine whether it is operating >> > > > > > correctly. Given that it usually runs in the background on user >> > > > > > systems, i'd especially appreciate it if a detailed review could >> > > > > > be conducted on Discover and other software that conducts package >> > > > > > management operations or assists in managing updates. >> > > > > > >> > > > > > Unfortunately all these applications submit a fairly useless user >> > > > > > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain >> > > > > > any further information. If we could get information on the >> > > > > > software that is originating the request added to the user agent >> > > > > > to assist in investigating these issues in the future that would >> > > > > > be extremely helpful. >> > > > > > >> > > > > > Thanks, >> > > > > > Ben >> > > > > >> > > > > That's correct. Discover fetches them at startup. It's necessary to >> > > > > be >> > > > > able to check if there are updates on KNS-provided resources. >> > > > > >> > > > > Incidentally, I was looking into this yesterday incidentally. We >> > > > > could see if caching is broken somehow. A request will still be >> > > > > needed >> > > > > though to check if the cache is out of date. >> > > > >> > > > Caching seems to be working, since the v
Re: OCS Providers File - High Numbers of Requests
On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez wrote: > > El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) > escribió: > > > > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez > > wrote: > > > > > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) > > > escribió: > > > > > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > > > > > > > Hi all, > > > > > > > > > > It has recently come to our attention that the number of queries > > > > > being handled for the endpoint > > > > > https://autoconfig.kde.org/ocs/providers.xml on a day to day basis > > > > > has gotten to the point where it is causing issues with server > > > > > responsiveness to other traffic. This is perhaps best summarised by > > > > > the following: > > > > > > > > > > root@nicoda /var/log/apache2 # ls -lah ... > > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > > > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > > > > 4,222,343 > > > > > > > > > > Based on those numbers we're looking at 48-49 requests per second (on > > > > > average - peaks are much higher by many magnitudes), which seems > > > > > extremely excessive given that this file is only supposed to be > > > > > retrieved by KDE software when GHNS functionality is triggered. That > > > > > is supported by the substantial size difference it has over > > > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager > > > > > (on Neon) to check for whether they have a working internet > > > > > connection - which i'd expect to be the site receiving the most > > > > > traffic. > > > > > > > > > > As such, I therefore suspect we have bug(s) in software that makes > > > > > use of GHNS functionality. > > > > > > > > > > It would therefore be appreciated if we could please review the > > > > > software in question to determine whether it is operating correctly. > > > > > Given that it usually runs in the background on user systems, i'd > > > > > especially appreciate it if a detailed review could be conducted on > > > > > Discover and other software that conducts package management > > > > > operations or assists in managing updates. > > > > > > > > > > Unfortunately all these applications submit a fairly useless user > > > > > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any > > > > > further information. If we could get information on the software that > > > > > is originating the request added to the user agent to assist in > > > > > investigating these issues in the future that would be extremely > > > > > helpful. > > > > > > > > > > Thanks, > > > > > Ben > > > > > > > > That's correct. Discover fetches them at startup. It's necessary to be > > > > able to check if there are updates on KNS-provided resources. > > > > > > > > Incidentally, I was looking into this yesterday incidentally. We > > > > could see if caching is broken somehow. A request will still be needed > > > > though to check if the cache is out of date. > > > > > > Caching seems to be working, since the vast majority of the requests > > > are returning 304 Not Modified. > > > > > > However in *many* cases I see a single IP making multiple requests in > > > the same second, and doing it again the next minute. Here's one IP > > > address picked randomly: > > > > > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > > [22/Sep/2021:06:27:58 +] "GET /ocs/p
Re: OCS Providers File - High Numbers of Requests
On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez wrote: > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) > escribió: > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > > > Hi all, > > > > > > It has recently come to our attention that the number of queries being > > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on > > > a day to day basis has gotten to the point where it is causing issues > > > with server responsiveness to other traffic. This is perhaps best > > > summarised by the following: > > > > > > root@nicoda /var/log/apache2 # ls -lah ... > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > > 4,222,343 > > > > > > Based on those numbers we're looking at 48-49 requests per second (on > > > average - peaks are much higher by many magnitudes), which seems > > > extremely excessive given that this file is only supposed to be retrieved > > > by KDE software when GHNS functionality is triggered. That is supported > > > by the substantial size difference it has over networkcheck.kde.org - > > > which is used by plasma-nm and NetworkManager (on Neon) to check for > > > whether they have a working internet connection - which i'd expect to be > > > the site receiving the most traffic. > > > > > > As such, I therefore suspect we have bug(s) in software that makes use of > > > GHNS functionality. > > > > > > It would therefore be appreciated if we could please review the software > > > in question to determine whether it is operating correctly. Given that it > > > usually runs in the background on user systems, i'd especially appreciate > > > it if a detailed review could be conducted on Discover and other software > > > that conducts package management operations or assists in managing > > > updates. > > > > > > Unfortunately all these applications submit a fairly useless user agent > > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > > > information. If we could get information on the software that is > > > originating the request added to the user agent to assist in > > > investigating these issues in the future that would be extremely helpful. > > > > > > Thanks, > > > Ben > > > > That's correct. Discover fetches them at startup. It's necessary to be > > able to check if there are updates on KNS-provided resources. > > > > Incidentally, I was looking into this yesterday incidentally. We > > could see if caching is broken somehow. A request will still be needed > > though to check if the cache is out of date. > > Caching seems to be working, since the vast majority of the requests > are returning 304 Not Modified. > > However in *many* cases I see a single IP making multiple requests in > the same second, and doing it again the next minute. Here's one IP > address picked randomly: > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:11
Re: OCS Providers File - High Numbers of Requests
On Thu, Sep 23, 2021 at 1:54 PM Aleix Pol wrote: > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > Hi all, > > > > It has recently come to our attention that the number of queries being > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a > > day to day basis has gotten to the point where it is causing issues with > > server responsiveness to other traffic. This is perhaps best summarised by > > the following: > > > > root@nicoda /var/log/apache2 # ls -lah ... > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > 4,222,343 > > > > Based on those numbers we're looking at 48-49 requests per second (on > > average - peaks are much higher by many magnitudes), which seems extremely > > excessive given that this file is only supposed to be retrieved by KDE > > software when GHNS functionality is triggered. That is supported by the > > substantial size difference it has over networkcheck.kde.org - which is > > used by plasma-nm and NetworkManager (on Neon) to check for whether they > > have a working internet connection - which i'd expect to be the site > > receiving the most traffic. > > > > As such, I therefore suspect we have bug(s) in software that makes use of > > GHNS functionality. > > > > It would therefore be appreciated if we could please review the software in > > question to determine whether it is operating correctly. Given that it > > usually runs in the background on user systems, i'd especially appreciate > > it if a detailed review could be conducted on Discover and other software > > that conducts package management operations or assists in managing updates. > > > > Unfortunately all these applications submit a fairly useless user agent > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > > information. If we could get information on the software that is > > originating the request added to the user agent to assist in investigating > > these issues in the future that would be extremely helpful. > > > > Thanks, > > Ben > > That's correct. Discover fetches them at startup. It's necessary to be > able to check if there are updates on KNS-provided resources. > > Incidentally, I was looking into this yesterday incidentally. We > could see if caching is broken somehow. A request will still be needed > though to check if the cache is out of date. > > Or we can prefer the cached version of the file for a few days and > assume they don't change that much. > > I've seen some of them point at > "https://download.kde.org/ocs/providers.xml;, I don't know if this is > any better. > > Aleix https://invent.kde.org/frameworks/attica/-/merge_requests/15/ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141 https://invent.kde.org/plasma/discover/-/merge_requests/165 This should lessen the problem from Discover's side. Still that one providers.xml request at startup remains. Aleix
Re: OCS Providers File - High Numbers of Requests
On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > Hi all, > > It has recently come to our attention that the number of queries being > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a > day to day basis has gotten to the point where it is causing issues with > server responsiveness to other traffic. This is perhaps best summarised by > the following: > > root@nicoda /var/log/apache2 # ls -lah ... > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > 4,222,343 > > Based on those numbers we're looking at 48-49 requests per second (on average > - peaks are much higher by many magnitudes), which seems extremely excessive > given that this file is only supposed to be retrieved by KDE software when > GHNS functionality is triggered. That is supported by the substantial size > difference it has over networkcheck.kde.org - which is used by plasma-nm and > NetworkManager (on Neon) to check for whether they have a working internet > connection - which i'd expect to be the site receiving the most traffic. > > As such, I therefore suspect we have bug(s) in software that makes use of > GHNS functionality. > > It would therefore be appreciated if we could please review the software in > question to determine whether it is operating correctly. Given that it > usually runs in the background on user systems, i'd especially appreciate it > if a detailed review could be conducted on Discover and other software that > conducts package management operations or assists in managing updates. > > Unfortunately all these applications submit a fairly useless user agent > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > information. If we could get information on the software that is originating > the request added to the user agent to assist in investigating these issues > in the future that would be extremely helpful. > > Thanks, > Ben That's correct. Discover fetches them at startup. It's necessary to be able to check if there are updates on KNS-provided resources. Incidentally, I was looking into this yesterday incidentally. We could see if caching is broken somehow. A request will still be needed though to check if the cache is out of date. Or we can prefer the cached version of the file for a few days and assume they don't change that much. I've seen some of them point at "https://download.kde.org/ocs/providers.xml;, I don't know if this is any better. Aleix
Re: Raising KF5 version a bit earlier
Ah, no. I thought it was still pending. Seems like it worked for everyone after all. All good, sorry for the noise. Aleix On Sat, Jul 24, 2021 at 2:30 PM Friedrich W. H. Kossebau wrote: > Am Samstag, 24. Juli 2021, 13:58:56 CEST schrieb Aleix Pol: > > Hi, > > Would it be possible to get the version bump in master a bit earlier in > > this cycle? > > > https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/2a39f0b235c24 > > 2592ae6658f33e7fc7b547f8c6d > > Please note that the bump of the dependency version to 5.85 (so not just > the > version itself) had already been done on July 15th, given we asked David > to do > so before in https://invent.kde.org/frameworks/extra-cmake-modules/-/ > merge_requests/150 > <https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/150> > > See e.g. > https://invent.kde.org/frameworks/kpackage/-/commit/ > 0e03365fe2674c229ff8c93a353c7c9ce0302afb > > Are there some repos which missed out here? > > Cheers > Friedrich > > >
Raising KF5 version a bit earlier
Hi, Would it be possible to get the version bump in master a bit earlier in this cycle? https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/2a39f0b235c242592ae6658f33e7fc7b547f8c6d This change made it so the setting will only be used when the version is actually 5.85 and I think it would be good to make sure we are testing them a bit before as we work on the frameworks. Cheers! Aleix
Re: Problem with ksycoca not being regenerated under flatpak
On Sun, Jun 20, 2021 at 11:29 AM Albert Astals Cid wrote: > > El diumenge, 13 de desembre de 2020, a les 22:15:26 (CEST), Albert Astals Cid > va escriure: > > El dissabte, 12 de desembre de 2020, a les 22:59:58 CET, David Faure va > > escriure: > > > Time flies, sorry for the delay. > > > > > > On samedi 12 septembre 2020 19:44:45 CET Albert Astals Cid wrote: > > > > flatpak mounts all files as if created on January 1st 1970. > > > > > > Isn't that a bug in itself? Why doesn't it preserve mtimes? > > > > I don't know, because reasons i guess, i never fully understood the answers > > i got on the flatpak mailing list > > > > https://lists.freedesktop.org/archives/flatpak/2020-October/002049.html > > > > https://lists.freedesktop.org/archives/flatpak/2020-November/002057.html > > > > > > > > > This has the unfortunate effect that when we add new plugins to a > > > > flatpak > > > > (i.e. we just added markdown preview support in kate), they are not seen > > > > because ksycoca doesn't feel the need to regenerate itself (the sycoca > > > > file > > > > for flatpak is written "outside" flatpak container and thus has a newer > > > > date). > > > > > > > > I remember talking about this probably a year ago at least with Aleix, > > > > but i > > > > guess we did not come up with any solution since it's still broken :D > > > > > > > > I don't know much about sycoca, but can we make it so the cache always > > > > get > > > > regenerated on app launch when run under flatpak? > > > > > > Is there no way to manually "touch" a directory after adding new files? > > > > > > Otherwise, the hack you have in mind could be implemented as in the > > > attached > > > patch. Untested, except that it compiles. > > > > I'll test the patch at some point, thanks for caring :) > > So I did *not* test the patch, but I got someone else to test it > https://github.com/flathub/org.kde.kdenlive/issues/118#issuecomment-864382857 > > And it seems to solve the problem :) > > Big question left is, should we apply that patch you made directly in > KService or do you prefer we apply it only when compiling the flatpak runtime? I would much prefer if we didn't patch in the packaging. If there's risk in having this outside of flatpak, I'd ifdef it. Aleix
Re: Respin request for KIO
Merci beaucoup, David! :) On Sat, Jun 12, 2021 at 10:26 AM David Faure wrote: > > On vendredi 11 juin 2021 20:50:12 CEST Aleix Pol wrote: > > Hi David, > > It would be good that > > https://invent.kde.org/frameworks/kio/-/commit/3bc92c23dd3456bb18efd44968fab > > f32dd9c3402 was included since 9c9c8df545ab5bd2362e7c01467d3875d79f30ce is > > also inside and it fixes a regression. > > > > Sorry for the inconvenience and thank you very much! > > Just in time ;) > Done: > > kio v5.83.0-rc2 > db88cf59dd46aebff4072e714dda5a5554a8d699 > faa5a519e0cccb7197a4025f4b267a7683b49ad9d03e730a57969f33072f51c1 > sources/kio-5.83.0.tar.xz > > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > >
Respin request for KIO
Hi David, It would be good that https://invent.kde.org/frameworks/kio/-/commit/3bc92c23dd3456bb18efd44968fabf32dd9c3402 was included since 9c9c8df545ab5bd2362e7c01467d3875d79f30ce is also inside and it fixes a regression. Sorry for the inconvenience and thank you very much! Aleix
Re: KGlobalAccel on non-Plasma systems
On Tue, Apr 6, 2021 at 5:30 PM Nicolas Fella wrote: > > Hi, > > we received a few reports [1] [2] from people using non-Plasma systems > that the kglobalaccel5 process was started, leading to clashes with the > native global shortcut system. > > This seems to happen when apps call some API of KGlobalAccel which > results in the kglobalaccel5 process to be DBus-activated. > > This brings me to the question of whether there is a use case for using > KGlobalAccel on non-Plasma systems at all. While technically > KGlobalAccel should work on all X11 systems most (all?) desktop > environments have their own way of global shortcut handling that we > should not interfere with. On Wayland it is only working in combination > with KWin. On systems that do not use X11 (Windows, macOS, Android) it > is most likely not useful at all. api.kde.org lists only Linux and > FreeBSD as supported, but the code contains special casing for non-Unix > platforms and for macOS. > > At the recent Frameworks sprint we talked about better communicating > whether a given Framework is truly a cross-platform/cross-desktop > library or an implementation detail of Plasma/used for integrating with > Plasma [3]. It seems to me that KGlobalAccel falls into the latter > category. > > If we agree that KGlobalAccel is only relevant when running Plasma we > should take the necessary steps to ensure it does not get activated in a > non-Plasma environment to avoid nasty side effects. Clearly defining the > scope would also help frameworks and app developers make technical > decisions and would allow to clean up some unneeded code. > > Thoughts? > > Cheers > > Nico > > [1] https://bugs.kde.org/show_bug.cgi?id=435420 > > [2] https://bugs.kde.org/show_bug.cgi?id=430691 > > [3] https://phabricator.kde.org/T14294 > Hi Nico, It makes a lot of sense. And TBH, my first thought was "h n". But then it kind of does make sense. KGlobalAccel has a lot of logic to centralise these shortcuts settings and in practice it's nothing that would be realistically mappable to a non-Plasma system. So in general, yes. +1 Aleix
Plasma Wayland Protocols 1.2.0
Hello everyone, We have just released a new 1.2 version that includes some extra interfaces that will be necessary in the next KF5 release as well as Plasma 5.22. You can find it here: https://download.kde.org/stable/plasma-wayland-protocols/plasma-wayland-protocols-1.2.0.tar.xz.mirrorlist Thanks! Aleix
Re: KDE Frameworks 6 - Virtual Sprint setup
On Fri, Jan 29, 2021 at 5:24 PM Adam Szopa wrote: > > Hello, > > I've been talking with David Faure about setting up a Sprint focused on KF6 > work. Some of the topics would include: > > - Reviewing the KF6 board (https://phabricator.kde.org/project/board/310/[1]): > > -- Clean up > > -- Tagging Junior Jobs > > - Working out a structure/process for handling: > > -- "Stuck" tasks > > -- Unit test regressions > > - Decide the 5.15 minimum requirement bump timeline > > - Decide on a 6 branching strategy and timeline > > - Decide if/how ECM should support multiple Qt versions > > > That's just an example list - the wiki should include the up to date and > detailed topics. > > > The Sprint will use the KDE BBB instance - same tech that powered last years > Akademy; I'll coordinate that with our sysadmins to have it available. > > > As for the date and length, usually Virtual Sprints are a weekend thing. I'd > > love to hear from you if that sounds OK, and which weekend would be workable > > for you (how soon can we get this started) and your preferred availability > > hours. I'll set up a poll later to pinpoint the final timing. > > > Thanks, > > - Adam +1! :)
Re: KACL from KIO isn't really POSIX-compliant
On Wed, Dec 2, 2020 at 10:47 AM Gleb Popov <6year...@gmail.com> wrote: > > Hello everyone. > > I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support POSIX > ACLs, and failed. This is because KACL's code uses non-standard > Linux-specific acl_* functions. I tried implementing them using standard ones > and it turned out to be impossible, mainly because types like acl_t are > opaque to the user of the library. > > For instance, there is no standard acl_get_perm() function and it is > impossible to implement it without getting into acl_permset_t. > > Now I'm a bit unsure how to solve this. I can implement non-standard > functions in FreeBSD's libc without touching KACL code, or I can rewrite the > KACL class to be truly POSIX-compliant. The latter seems to be a better idea > on the first look, but it'd require keeping track of all the permission flags > set (again, because there is no acl_get_perm()) inside. This will turn KACL > class from being a tiny acl_* wrapper into a beefy chunk of code, but at > least we won't lie that it is POSIX-compliant. > > Any thoughts? > > P.S. Please CC me, as I'm not subscribed. Adding Adriaan who has been working on KDE+FreeBSD things. Aleix
Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?
On Tue, Dec 1, 2020 at 1:30 PM Jonathan Riddell wrote: > > Not from KDE neon of course, we're on 5.15. And not from the KDE snaps build > either. But I suppose there's more than just Linux distros to consider as we > ship apps using KDE frameworks on Flatpak, Android, Windows, even Mac to > ponder too. > > Jonathan > > > On Tue, 1 Dec 2020 at 12:14, Friedrich W. H. Kossebau > wrote: >> >> Hi, >> >> last week KDE Frameworks master saw a bump in the required/expected minimal >> Qt >> version to Qt 5.13, following rules once agreed and noted here: >> https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements >> >> I would like to challenge that former decision though and propose to instead >> go straight to Qt 5.14 as minimum requirement now. >> >> >> QUESTION: >> Would any of the distributions have an issue with requiring Qt 5.14 instead >> of >> Qt 5.13? >> >> >> From some quick checks using https://repology.org/ it seems that any >> distribution versions which currently use Qt 5.13 have also settled on some >> older KF version, so will not update to just KF 5.77 and thus be screwed. >> >> Motivation: >> * KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no unit tests) >> * Qt 5.14 added some new API, chance to miss out when using that in new code >> * C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14, 0) variants >> * QML: no need to do hard-to-read generation tricks to support < Qt 5.14 >> * Qt 5.13 went out-of-support in June >> * App bundle builders would rather use some recent Qt 5.14/5.15 >> >> So by restraining to Qt 5.13 as minimum version IMHO we would make/keep life >> complicated for KF contributors without adding any value for anyone. >> >> With most of KDE Frameworks in my local checkout: >> grep "QT_VERSION_CHECK(5, 14, 0)" frameworks/*/src -r 2>/dev/null | \ >> grep "QT_VERSION " | wc -l >> gives me "92", so there are quite some code variants which need support in >> current code. >> >> From the emails at least in >> https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html I >> could not see a discussion whether Qt 5.13 makes >> sense at all now, seems mainly the algorithm was applied. I propose to match >> the result to known real world needs now. Or teach me what I have missed here >> :) >> >> Cheers >> Friedrich For Flatpak it's not a problem either, We've had 5.15 for a while. Any distro shipping 5.13 right now (and 5.14 in 9 days) is doing a disservice to its users anyway, since upstream isn't supporting it either. https://en.wikipedia.org/wiki/Qt_version_history#Qt_5 Aleix
Re: Stepping down as KRunner maintainer
Thanks to the both of you for the work done! :) Updated the metainfo file of the krunner framework: https://invent.kde.org/frameworks/krunner/commit/621ca6e3b2e518a546c1ac8651cfb2cfd4c25122 Aleix On Thu, Oct 8, 2020 at 10:32 PM Nicolas Fella wrote: > > Thanks for all your work Kai and congratulations Alexander, this is well > deserved! > > Cheers > > Nico > > On 08.10.20 19:17, Kai Uwe Broulik wrote: > > Hi everyone, > > > > you might not even have known this but officially I have been KRunner's > > maintainer for several years at this point :-) > > > > However, I have decided to step down as its maintainer as I believe won't > > be able to really move KRunner forward for KF6 despite a grand vision [1] > > for a lack of time and, frankly, motivation. > > > > Therefore, I'd like to pass the torch to Alexander Lohnau. He's bringing > > many fresh ideas to the table and is very enthusiastic about making KRunner > > shine again. He's also surely done more in the past months than I did in > > the past years and so it's only fair to not have his ambitions hindered by > > my unresponsiveness on code reviews. > > > > Alexander, thank you again for hosting that KRunner BoF at your first ever > > Akademy - the stage is yours ;-) > > > > Cheers > > Kai Uwe > > > > [1] https://phabricator.kde.org/T12031
D29872: Provide methods to register SecretAgent to NetworkManager with capabilities, specifically with NM_SECRET_AGENT_CAPABILITY_VPN_HINTS
apol abandoned this revision. apol added a comment. https://invent.kde.org/frameworks/networkmanager-qt/-/merge_requests/2 REPOSITORY R282 NetworkManagerQt REVISION DETAIL https://phabricator.kde.org/D29872 To: apol, jgrulich, enriquem Cc: ngraham, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
D29872: Provide methods to register SecretAgent to NetworkManager with capabilities, specifically with NM_SECRET_AGENT_CAPABILITY_VPN_HINTS
apol commandeered this revision. apol added a reviewer: enriquem. REPOSITORY R282 NetworkManagerQt REVISION DETAIL https://phabricator.kde.org/D29872 To: apol, jgrulich, enriquem Cc: ngraham, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
D29872: Provide methods to register SecretAgent to NetworkManager with capabilities, specifically with NM_SECRET_AGENT_CAPABILITY_VPN_HINTS
apol added a comment. We have moved to gitlab, now patches should be uploaded here: https://invent.kde.org/frameworks/networkmanager-qt Sorry for the change (@jgrulich can still review it, but it's better to have everything in the new infrastructure). The patch itself looks okay to me. REPOSITORY R282 NetworkManagerQt REVISION DETAIL https://phabricator.kde.org/D29872 To: enriquem, jgrulich Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: Dropping the moderation by default flag
El dt., 21 de jul. 2020, 21:16, Albert Astals Cid va escriure: > Hi, this list has an unusual setting [for kde mailing lists] inherited > from kde-core-devel that is that even subscribed people get moderated, and > then the list moderator can decide to clear the moderate flag for each > person one by one. > > I'm proposing to change that because: > * it's non consistent with the rest of kde mailing lists > * as moderator of this list i don't think i've seen ever any spam coming > from a subscribed member. > > Opinions? > > Cheers, > Albert > +1 I've been moderating this mailing list too, nothing fishy ever happened that was prevented by this setting. Aleix >
Re: Frameworks support for Qt 5.12
On Wed, Jul 15, 2020 at 6:13 PM Nicolas Fella wrote: > > Hi, > > I received a question on how long KF5 will continue to support Qt 5.12. > > Given that 5.12 is an LTS release according to our policy it would be > supported "until the next Qt release after the next Qt release", which > would be 5.16, which will never exist. > > Our policy states "With Qt6 this changes a little bit again. To avoid > supporting 5.12 LTS and 5.15 LTS for ever, 5.15 LTS will be the minimum > required version 18 months after its release.". This however does not > answer what will happen with 5.12. > > If I remember correctly our intention when formalizing this was to > extrapolate the hypothetical releases and apply the existing rules to > it. This would mean that by the time Qt 5.16 would be released (6 months > after Qt 5.15) KF5 would drop support for Qt 5.12 and require 5.13. > > Is my interpretation of this correct? If so the wiki page should be > updated with this information. It means that 5.12 support will be discontinued, much like it is right now for any older Qt release. FWIW I am not sure it makes a lot of sense to stay with 5.12 for much more though, I think supporting at least 5.14 soon would allow us to remove several workarounds and warnings at least on QML code which we will need solved anyway looking into the Qt 6. Aleix
Re: Deprecate KRandomSequence ?
On Mon, Jun 29, 2020 at 10:27 PM Albert Astals Cid wrote: > > QRandomGenerator is very similar in which you can give it a seed and get > randomness out of it. > > Things that QRandomGenerator doesn't have: > * getBool(); -> should be easy enough to port to bounded(2) == 1 > * randomize(QList) -> We could add namespace function in KRandom > * modulate() -> Couldn't find any user, so no worries if we drop it > > Benefits of deprecation: > * Less manintaince > > Problems of deprecation: > * Moving from KRadomSequence(FIXED_SEED) to QRandomGenerator(FIXED_SEED) > will probably generate a different sequence, so if you need to 100% generate > the same sequence for all your app versions (e.g. for a game or something) > moving may not be "possible" > > Ideas? Comments? +1 makes sense to me. If an application was relying on the random application sequence, it probably has bigger problems. It can always be hardcoded into the application too. Aleix
D27338: Provide an initial implementation for input-method-unstable-v1
apol abandoned this revision. apol added a comment. https://invent.kde.org/plasma/kwayland-server/-/merge_requests/31 REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D27338 To: apol, #kwin, #frameworks Cc: davidedmundson, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D22362: Port keystates to use QtWayland's generator
apol abandoned this revision. apol added a comment. Moved to invent for kwayland-server REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D22362 To: apol, #kwin Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: KEmoticons, emoticons kcm
On Sun, May 24, 2020 at 3:09 AM Sandro Knauß wrote: > Hi, > > > Now while I know why this exists, it feels like it's more of a thing > > of the past from when people wrote :) instead of . > > Okay now I feeling old :-) - I don't even know how to create a unicode > smiley, that's why I always create these :-) smileys. > > hefee > If you use any stable Plasma you'll get the emoji selector by pressing meta+.(dot). Aleix
Re: New Framework Review: KDAV
On Sun, May 24, 2020 at 8:52 AM Volker Krause wrote: > > The remaining issues that didn't change ABI anymore (movable value types, hide > private methods/slots inside the private classes, etc) have long since been > addressed. > > I think there's two possible time slots to actually execute the move to > frameworks now: > * ASAP, for the June release. > * For the July release, just in time for the 20.08 dependency freeze. > > Opinions? > > Thanks, > Volker > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > Thanks for the review! We are cutting it close again with the 20.04 > > deadline, but fortunately most of these findings aren't ABI-breaking :) > > > > The result was discussed in more detail at the (virtual) PIM sprint, summary > > below for the record. > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > Hello, > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > > > would be classified as a functional tier 3 framework. > > > > > > > > So far we have fixed a number of obvious ABI-compatibility issues, > > > > removed > > > > QtXml[Patterns] usage from the public interface and relicensed GPL parts > > > > (apart from a bit of test code) to LGPL. The next step would be a more > > > > thorough review to identify changes necessary before becoming a > > > > Framework. > > > > > > > > To avoid the last minute invasive changes we ended up doing for > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > - identify and implement all necessary changes to the API and ABI until > > > > the > > > > 20.04 Application release (that includes the still necessary move to the > > > > KF5 library namespace). > > > > > > I'm likely late to the party, but here is what I found by looking at KDAV > > > > > > master today (first day of the KDE PIM sprint): > > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > > > moving them to the d-pointer, for the slots we're using type safe connects > > > so they don't even need to be marked as slots at all; > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > * Is it worth making DavCollection moveable? It's only copyable right > > > now; > > > > Probably yes, that's new API with no ABI break, so we can do that post 20.04 > > as well. > > > > > * We might want to do something about "ctag" in DavCollection it's a bit > > > > > > obscure as a name (and the API doc doesn't help), also it seems to not be > > > an official standard (while being widely supported) and there's the > > > sync-token mechanism which has a RFC (RFC6578); > > > > I have no idea what ctag is (I am only doing the technical work needed to > > turn this into a framework, I didn't write this library). > > > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > > just > > > > > > be my ignorance but I find it surprising that it is solely based on a > > > property mechanism); > > > > I think this is to be able to control which properties get changed, rather > > than sending the full set of them. > > > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on > > > > > > its collectionDiscovered signal, is it really necessary? if it has to > > > stay, > > > shouldn't be at least documented? or at least a safer type than int? > > > > Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/ > > D28566 > > > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using > > > Q_DECLARE_PRIVATE; > > > > That's due to using KJob as a base directly. > > > > Subsequent discussion suggested this should be a KCompositeJob, David is > > taking care of this. > > > > > * KDAV::Error would benefit from more apidox; > > > > Yes, not blocked by the 20.04 freeze though. > > > > > * Is it worth making DavItem moveable? It's only copyable right now; > > > > See above, same as DavCollection. > > > > > * Same comment about etag for DavItem than the ctag one for DavCollection > > > > See above, same as ctag. > > > > > * I'd be tempted to move all the protected methods of DavJobBase on its > > > d- > > > > > > pointer, the job subclasses would have access to them anyway, it'd make > > > sense to put them protected in the header only if we expect subclasses > > > outside of the lib (and I doubt this is actually supported); > > > > ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean > > this up after 20.04. > > > > > * It needs to decide between Qt smart pointers or STL ones I think, found > > > a > > > > > > bit of both so far (I'd lean toward STL ones but maybe that's just me); > > > > Also fixed by https://phabricator.kde.org/D28562. > > > > > * Make DavUrl moveable?
KEmoticons, emoticons kcm
Hi, I was looking through some Plasma code and I saw that we have some fairly old emoticons KCM using KF5Emoticons. Now while I know why this exists, it feels like it's more of a thing of the past from when people wrote :) instead of . While keeping it around for the few apps that might still use it (ktp? kopete?) could make sense, I'm afraid it's probably making it confusing for the users who expect this to actually allow them to customise their but won't. Do you think it would make sense to deprecate the framework and remove the KCM? If some application still uses it, they can integrate the kcm temporarily until their users come to terms that is the new :). Aleix
D28235: Add a simpler example
apol closed this revision. REPOSITORY R216 Syntax Highlighting REVISION DETAIL https://phabricator.kde.org/D28235 To: apol, vkrause, cullmann Cc: cullmann, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, demsking, sars, dhaumann
D26524: configmodule: Make sure the kcm information is loaded when the qml is created
apol added a comment. hmmm. Ping @mart. :) what do you suggest we do? REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D26524 To: apol, #plasma, #frameworks Cc: mart, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28235: Add a simpler example
apol added a comment. Should I understand this is not desired and that I should abandon it? I know it's not going to make a big difference to the project but it was hard for me to adopt it in the first place. REPOSITORY R216 Syntax Highlighting REVISION DETAIL https://phabricator.kde.org/D28235 To: apol, vkrause Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann
D29540: plasmawindowmodel: Expose the internal id to the model
apol abandoned this revision. apol added a comment. Will move to gitlab REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D29540 To: apol Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29810: Don't use setenv after fork
apol added inline comments.
INLINE COMMENTS
> kcrash.cpp:823
> +char** environ_end;
> +for(environ_end = environ; *environ_end; ++environ_end);
> +
Use {} instead of ; for readability.
REPOSITORY
R285 KCrash
REVISION DETAIL
https://phabricator.kde.org/D29810
To: jpalecek, #frameworks
Cc: apol, anthonyfieroni, kde-frameworks-devel, LeGast00n, cblack, michaelh,
ngraham, bruns
D29802: Require out-of-source builds
apol accepted this revision. REPOSITORY R266 Breeze Icons BRANCH require-in-source-build (branched from master) REVISION DETAIL https://phabricator.kde.org/D29802 To: ngraham, #frameworks, #vdg, ognarb, davidre, apol Cc: ltoscano, davidre, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29745: look for kded as runtime dep
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO BRANCH kded REVISION DETAIL https://phabricator.kde.org/D29745 To: sitter, dfaure, apol Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29631: [android] Allow specifying APK install location
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules BRANCH androinstall REVISION DETAIL https://phabricator.kde.org/D29631 To: nicolasfella, #frameworks, #android, apol, vkrause Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29600: Fix build with KF set to EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R242 Plasma Framework (Library) BRANCH fixbuildwithoutdeprecated REVISION DETAIL https://phabricator.kde.org/D29600 To: kossebau, #plasma, mart, apol Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29631: [android] Allow specifying APK install location
apol added a comment. +1 overall, good idea. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D29631 To: nicolasfella, #frameworks, #android, apol, vkrause Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29631: [android] Allow specifying APK install location
apol added inline comments.
INLINE COMMENTS
> Android.cmake:93
> #
> -# The APK would then be found in ``myapp_build_apk/bin`` in the build
> directory.
> +# You can specify the APK output directory by setting
> ANDROID_APK_INSTALL_DIR.
> +# Otherwise the APK can be found in ``myapp_build_apk/`` in the build
> directory.
ANDROID_APK_INSTALL_DIR should be between quotes like other variables.
Also I'd call the variable ANDROID_APK_OUTPUT_DIR. We have an install concept
already.
> ECMAndroidDeployQt.cmake:85
> add_custom_target(install-apk-${QTANDROID_EXPORTED_TARGET}
> COMMAND adb install -r
> "${EXPORT_DIR}/${QTANDROID_EXPORTED_TARGET}-${CMAKE_ANDROID_ARCH_ABI}.apk"
> )
Needs adapting.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D29631
To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy,
michaelh, ngraham, bruns
D29511: Label: Add ping-pong logic
apol added a comment. I feel like this could break Labels unknowingly. Maybe it would make sense to have an extra scrollToFit (?) property or even another separate component to do that. Seeing things bouncing without the author intending could be worse than having the text cut off. REPOSITORY R242 Plasma Framework (Library) REVISION DETAIL https://phabricator.kde.org/D29511 To: patrickelectric, #plasma, #vdg, ognarb, davidedmundson Cc: apol, davidedmundson, ognarb, cblack, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
Re: RFC: relative executables in desktop files
On Sun, Apr 26, 2020 at 1:36 PM David Faure wrote: > > During the review of https://phabricator.kde.org/D29170 the following > question surfaced again: should it be possible for a desktop file to refer to > an executable that is in the "current directory", for some definition of that > term. At least, outside of $PATH. > > In my opinion, in a GUI program started graphically, the notion of "current > dir" (QDir::currentPath()) has no meaning. The user can't see it and can't > change it. When starting the program from the command line it does serve a > purpose for command line arguments, but IMHO not after that (e.g. if you > navigate to another dir in dolphin, QDir::currentPath() still points to the > directory you started dolphin from). > > There is however another "current directory" that might make more sense when > starting a desktop file: the directory of the desktop file itself. > > There are actual use cases for that, see this very old request on the XDG > mailing-list: > https://lists.freedesktop.org/archives/xdg/2011-April/011883.html > > AFAICS this discussion has 3 possible outcomes: > > * We do not support starting executables that are not in $PATH, end of story. > That was actually what I had in mind when writing the code initially, any use > of API that also looked in the current directory (like QFileInfo::exists) was > accidental. Unless I'm mistaken, this is how it's been until now. It's also > what the XDG spec [1] says. > > * We support launching executables relative to the desktop file, > transparently. In the same directory, put a copy of dolphin called dolphin2, > and a copy of org.kde.dolphin.desktop modified to say Exec=dolphin2, and > clicking on the desktop file starts dolphin2. That's what my current revision > of D29170 does. > I'm wondering if this is the right thing to do though. > After all, on the command line "foo" doesn't start a local executable called > foo, only ./foo does that. Except for people who add "." to $PATH, but that's > generally not recommended (security, accidental use of wrong binary). > > * We could also adopt the above proposal from the xdg list, which is that > Exec=foo only looks in $PATH, while Exec=./foo only looks in the directory of > the desktop file. > > (I'm purposefully excluding the 4th option, resolving relative to > QDir::currentPath() which as explained at the top, would be nonsense IMHO) > > Thoughts? One thing to note, which is probably easy to support: at the moment in kwin we're relying on certain apps to be defined in absolute paths for some security measures. Just supporting $PATH makes most sense to me, there's increasingly other ways to distribute software that abstract XDG out (e.g. snap, appimage and flatpak). Weird custom uses should become increasingly more rare over time. Aleix
D28882: Create protocol to manage video feeds
apol added a comment. Moving to kwayland-server REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson, zzag Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28882: Create protocol to manage video feeds
apol abandoned this revision. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson, zzag Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29540: plasmawindowmodel: Expose the internal id to the model
apol created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. apol requested review of this revision. REVISION SUMMARY It allows to use this class together with the screencast protocol. It's public API on the window anyway so it should probably be exposed. TEST PLAN Used it with the other screencast patches for convenience. REPOSITORY R127 KWayland BRANCH master REVISION DETAIL https://phabricator.kde.org/D29540 AFFECTED FILES src/client/plasmawindowmodel.cpp src/client/plasmawindowmodel.h To: apol Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29445: [KOpenWithDialog] When pointing at a non-executable file print more meaningful error
apol added inline comments.
INLINE COMMENTS
> kopenwithdialog.cpp:1006
> // Ensure that the typed binary name actually exists (#81190)
> if (QStandardPaths::findExecutable(binaryName).isEmpty()) {
> +// Maybe it exists but isn't executable
This patch D29170 suggests that
findExecutable won't find non-executables.
Something's wrong.
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D29445
To: broulik, #frameworks, #vdg
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29406: Add X-KDE-Original-Executable to Applications properties
apol added a comment. > If I understand correctly, it is necessary to use dbus spectacle in this case, so that dbus can manage the application instance and make sure we end up with only one, whether we launch the app, use a shortcut or launch from command line. I don't think that's a good reason. We have lots of applications that do that without having to be launched by dbus: plasmashell, krunner, yakuake, etc. It's done by using KDBusService. REPOSITORY R309 KService REVISION DETAIL https://phabricator.kde.org/D29406 To: meven, #frameworks, davidedmundson, apol, bport Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29405: [PoC] Make notifications work without a notifyrc file
apol added a comment. What's the advantage? Won't this make it harder to put together the notifications kcm? REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D29405 To: nicolasfella, #frameworks, broulik, vkrause Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29406: Add X-KDE-Original-Executable to Applications properties
apol added a comment. This should be documented somewhere, as is it's really confusing. I'm not sure it wouldn't be better to have spectacle launched again there instead of going through dbus (which is a change I admittedly don't understand very well). REPOSITORY R309 KService REVISION DETAIL https://phabricator.kde.org/D29406 To: meven, #frameworks, davidedmundson, apol, bport Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29396: Suppress find_package_handle_standard_args package name mismatch warning.
apol accepted this revision. apol added a comment. This revision is now accepted and ready to land. This will make our configure steps readable again. Thanks! REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D29396 To: xuetianweng, #frameworks, #build_system, apol Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29201: KCMUtils: Add option to append service file to list of arguments
apol added a comment. I have the feeling there's a missing piece here. Would it make sense to always pass it? Would it regress in any way? At the very least, on the API documentation, explain why one would want that. REPOSITORY R295 KCMUtils REVISION DETAIL https://phabricator.kde.org/D29201 To: alex, #plasma, ngraham, meven, broulik Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29361: KCrash: remove debug output which breaks unittests from using ~/.qttest/config for categorized logging
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R285 KCrash BRANCH master REVISION DETAIL https://phabricator.kde.org/D29361 To: dfaure, kossebau, davidedmundson, apol Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 7:18 AM Ben Cooksley wrote: > > On Fri, May 1, 2020 at 4:38 PM Nate Graham wrote: > > > > > > > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > > >> Am I the only person that just has all the repos on the same folder? I > > >> thought it was the common thing to do :? > > > > > > I do too > > > > Same here. kdesrc-build's default settings do this, and download all > > repos into ~/kde/src without any of the levels of hierarchy. This would > > seem to require unique repo names, no? > > Not necessarily. > > Git allows you to override the name that the local folder is called > when cloning, so there is no reason why we can't specify something in > the metadata to override the local name that the folder gets called in > your local checkout folder. > This would allow for example: > > - frameworks/kcoreaddons on Gitlab continues to be called > 'kcoreaddons' in your local checkout folder > - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout > folder > > This allows for the URLs on Gitlab to make sense, while simultaneously > allowing your local source checkout folders to continue to work in the > manner in which they do currently. > Note that we do not expect people to hit this in many cases - this is > about giving us the flexibility for the long term without imposing > unnecessary bureaucracy and limits on projects within the KDE > umbrella. > > Automated tooling such as kdesrc-build and the proposed clone script > (that searches in namespaces) should be able to handle this without > much issue. > In the case of manually done clones, it is reasonable to expect people > to know what they're doing with their clones, and name them > appropriately in the event they have a collision. > > Does this sound acceptable? Okay, if that's necessary, we'll have to do it. We'll appreciate simpler bureaucracy. Aleix
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 1:08 AM Nicolás Alvarez wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > (aa...@kde.org) escribió: > > > > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va > > escriure: > > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić wrote: > > > > > > > > > We have made a big fuss in the past about having different projects > > > > > that do the same thing and now we'll have that but also we'll have > > > > > several projects with the same name? > > > > > It really feels off to me and I wonder if this is related to the move > > > > > to > > > > > gitlab. > > > > > > > > +1 to both sentiments - that projects should have different names and > > > > that > > > > this is a bit off topic for the gitlab migration. > > > > > > The projects *DO* have very different names. That *HAS NOT* changed. > > > To use the example Bhushan gave above, one is called Plasma Mobile > > > Dialer and the other one is called Maui Dialer. > > > > > > With the current git.kde.org setup, we have a flat namespace, so all > > > repositories if the name appears to be generic (as dialer is) have to > > > be namespaced by prefixing of the repository name. > > > > > > With Gitlab however we will now namespaces that group repositories, > > > making the prefixing unnecessary and as some projects have complained > > > about, duplicative. > > > > > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your > > > path, which just looks silly. > > > > Am I the only person that just has all the repos on the same folder? I > > thought it was the common thing to do :? I do too > Oh, your local path could be anywhere. It doesn't even need the same > name, you can put it in the same folder as the rest and call it > dial-thingy :) And then you'll have to have a modified build script to account for thingy because KDE can't stay consistent at naming. I suggest not to use the gitlab transition to make such an important change. Aleix
2 new repositories: plasma-wayland-protocols and kwayland-server
Hi everyone, After long discussions, we have broken kwayland into 3 pieces so we can work and improve kwin_wayland without having to extend our stable framework constantly. This of course comes together with an updated policy with regards to where things should be developed with the goal of only adding Wayland protocol implementation public interfaces in the cases that will be shared among several users. This then includes 2 new repositories: kdesupport/plasma-wayland-protocols kde/workspace/kwayland-server The first should be released independently whenever we have a new protocol, the latter only together with the rest of Plasma. Over the next months we'll adapt KWayland as well to depend on plasma-wayland-protocols and deprecate some of its parts that are now duplicated. Anything compiling against kwayland for now is fine and will continue to work. It still needs to be installed. All 3 are co-installable. Sorry for the extra work of caring for the extra repositories. We are convinced it will be worth it in the long run. Best regards, Aleix
Re: Information regarding upcoming Gitlab Migration: clarifications
On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah wrote: > > Good afternoon, > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > replies] > > I want to clarify some bits for which we have gotten a questions about, > > - Non unique naming: There's some teams which prefer if we dropped the > namespace- part from their name which we have added. While currently > this does not result in the naming conflict right away, we realize > this will cause it at one point, for example, > > maui-dialer -> maui/dialer > plasma-dialer -> plasma-mobile/dialer > > To minimize the impact of the Gitlab move we won't be doing such > renames which introduce non-unique names right away. But we would > prefer if the existing tooling or infrastructure is ready for this > kind of cases at later point. Only way to enforce non-unique naming is > one big KDE/ subgroup which we want to avoid. > > Current naming in the repo-metadata branch[1] I've pointed does not > reflect those renames, as we are not planning to do those renames > right away during gitlab move, but at a later stage. We have made a big fuss in the past about having different projects that do the same thing and now we'll have that but also we'll have several projects with the same name? It really feels off to me and I wonder if this is related to the move to gitlab. > - Existing configurations: we want to reduce impact on existing release > schedule, and existing developer workflow, therefore we will continue > to privide the existing anongit.kde.org and git.kde.org (although this > will be read-only) with current flat structuring for 3 weeks after > actual migration, which will keep the existing scripts/clones working > enough to give developers time to change to the new structure. > > We will also try to provide a script which allows you to migrate your > existing clones to new repo paths and as mentioned by Ben in other > message, potentially a git-kde script which would allow you to clone > individual repository without knowing it's namespace (provided that > there is no conflict of it's name). like "git kde karchive" IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. I feel like these things make us look distant, it's important that people's skills translate automatically when they want to get started. > - Translations: we will co-ordinate with the translations team to let > them adapt their tooling to updated structure as this requires changes > on their side how translations are stored in svn repository Thanks! :)
D29278: Port KWin to KWaylandServer
This revision was automatically updated to reflect the committed changes. Closed by commit R108:3a9d7a6e9d75: Port KWin to KWaylandServer (authored by apol). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D29278?vs=81574=81575#toc REPOSITORY R108 KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29278?vs=81574=81575 REVISION DETAIL https://phabricator.kde.org/D29278 AFFECTED FILES CMakeLists.txt abstract_client.cpp abstract_client.h abstract_output.cpp abstract_output.h abstract_wayland_output.cpp abstract_wayland_output.h autotests/CMakeLists.txt autotests/integration/dont_crash_cursor_physical_size_empty.cpp autotests/integration/globalshortcuts_test.cpp autotests/integration/idle_inhibition_test.cpp autotests/integration/input_stacking_order.cpp autotests/integration/internal_window.cpp autotests/integration/lockscreen.cpp autotests/integration/maximize_test.cpp autotests/integration/plasmawindow_test.cpp autotests/integration/pointer_constraints_test.cpp autotests/integration/pointer_input.cpp autotests/integration/scene_opengl_shadow_test.cpp autotests/integration/scene_qpainter_shadow_test.cpp autotests/integration/scene_qpainter_test.cpp autotests/integration/test_helpers.cpp autotests/integration/transient_placement.cpp autotests/integration/xdgshellclient_test.cpp autotests/integration/xwayland_input_test.cpp autotests/integration/xwayland_selections_test.cpp autotests/mock_effectshandler.h autotests/test_window_paint_data.cpp composite.cpp debug_console.cpp decorations/decorationbridge.cpp effects.cpp effects.h effects/backgroundcontrast/contrast.cpp effects/backgroundcontrast/contrast.h effects/blur/blur.cpp effects/blur/blur.h effects/desktopgrid/desktopgrid.cpp effects/slidingpopups/slidingpopups.cpp events.cpp idle_inhibition.cpp idle_inhibition.h input.cpp keyboard_input.cpp keyboard_repeat.cpp libkwineffects/CMakeLists.txt libkwineffects/kwineffects.cpp libkwineffects/kwineffects.h linux_dmabuf.cpp linux_dmabuf.h main.cpp main_wayland.cpp platform.cpp platform.h platformsupport/scenes/opengl/CMakeLists.txt platformsupport/scenes/opengl/abstract_egl_backend.cpp platformsupport/scenes/opengl/abstract_egl_backend.h platformsupport/scenes/opengl/egl_dmabuf.cpp platformsupport/scenes/opengl/egl_dmabuf.h plugins/platforms/drm/drm_backend.cpp plugins/platforms/drm/drm_inputeventfilter.cpp plugins/platforms/drm/drm_output.cpp plugins/platforms/drm/drm_output.h plugins/platforms/drm/egl_stream_backend.cpp plugins/platforms/drm/egl_stream_backend.h plugins/platforms/drm/remoteaccess_manager.cpp plugins/platforms/drm/remoteaccess_manager.h plugins/platforms/fbdev/fb_backend.cpp plugins/platforms/hwcomposer/hwcomposer_backend.cpp plugins/platforms/hwcomposer/hwcomposer_backend.h plugins/platforms/virtual/virtual_backend.cpp plugins/platforms/virtual/virtual_output.cpp plugins/platforms/wayland/egl_wayland_backend.cpp plugins/platforms/wayland/wayland_backend.cpp plugins/platforms/wayland/wayland_output.cpp plugins/platforms/x11/windowed/x11windowed_backend.cpp plugins/platforms/x11/windowed/x11windowed_output.cpp plugins/scenes/opengl/scene_opengl.cpp plugins/scenes/opengl/scene_opengl.h plugins/scenes/qpainter/scene_qpainter.cpp plugins/scenes/qpainter/scene_qpainter.h pointer_input.cpp pointer_input.h scene.cpp scene.h shadow.cpp shadow.h tablet_input.cpp toplevel.cpp toplevel.h touch_input.cpp virtualdesktops.cpp virtualdesktops.h virtualkeyboard.cpp wayland_cursor_theme.cpp wayland_server.cpp wayland_server.h xdgshellclient.cpp xdgshellclient.h xkb.cpp xkb.h xwl/clipboard.cpp xwl/clipboard.h xwl/databridge.cpp xwl/databridge.h xwl/dnd.cpp xwl/dnd.h xwl/drag_wl.cpp xwl/drag_wl.h xwl/drag_x.cpp xwl/drag_x.h xwl/selection_source.cpp xwl/selection_source.h xwl/transfer.cpp xwl/transfer.h To: apol, #kwin, #plasma, #frameworks, davidedmundson, zzag Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29278: Port KWin to KWaylandServer
apol updated this revision to Diff 81574. apol added a comment. Address @zzag's comments REPOSITORY R108 KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29278?vs=81521=81574 BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 AFFECTED FILES CMakeLists.txt abstract_client.cpp abstract_client.h abstract_output.cpp abstract_output.h abstract_wayland_output.cpp abstract_wayland_output.h autotests/CMakeLists.txt autotests/integration/dont_crash_cursor_physical_size_empty.cpp autotests/integration/globalshortcuts_test.cpp autotests/integration/idle_inhibition_test.cpp autotests/integration/input_stacking_order.cpp autotests/integration/internal_window.cpp autotests/integration/lockscreen.cpp autotests/integration/maximize_test.cpp autotests/integration/plasmawindow_test.cpp autotests/integration/pointer_constraints_test.cpp autotests/integration/pointer_input.cpp autotests/integration/scene_opengl_shadow_test.cpp autotests/integration/scene_qpainter_shadow_test.cpp autotests/integration/scene_qpainter_test.cpp autotests/integration/test_helpers.cpp autotests/integration/transient_placement.cpp autotests/integration/xdgshellclient_test.cpp autotests/integration/xwayland_input_test.cpp autotests/integration/xwayland_selections_test.cpp autotests/mock_effectshandler.h autotests/test_window_paint_data.cpp composite.cpp debug_console.cpp decorations/decorationbridge.cpp effects.cpp effects.h effects/backgroundcontrast/contrast.cpp effects/backgroundcontrast/contrast.h effects/blur/blur.cpp effects/blur/blur.h effects/desktopgrid/desktopgrid.cpp effects/slidingpopups/slidingpopups.cpp events.cpp idle_inhibition.cpp idle_inhibition.h input.cpp keyboard_input.cpp keyboard_repeat.cpp libkwineffects/CMakeLists.txt libkwineffects/kwineffects.cpp libkwineffects/kwineffects.h linux_dmabuf.cpp linux_dmabuf.h main.cpp main_wayland.cpp platform.cpp platform.h platformsupport/scenes/opengl/CMakeLists.txt platformsupport/scenes/opengl/abstract_egl_backend.cpp platformsupport/scenes/opengl/abstract_egl_backend.h platformsupport/scenes/opengl/egl_dmabuf.cpp platformsupport/scenes/opengl/egl_dmabuf.h plugins/platforms/drm/drm_backend.cpp plugins/platforms/drm/drm_inputeventfilter.cpp plugins/platforms/drm/drm_output.cpp plugins/platforms/drm/drm_output.h plugins/platforms/drm/egl_stream_backend.cpp plugins/platforms/drm/egl_stream_backend.h plugins/platforms/drm/remoteaccess_manager.cpp plugins/platforms/drm/remoteaccess_manager.h plugins/platforms/fbdev/fb_backend.cpp plugins/platforms/hwcomposer/hwcomposer_backend.cpp plugins/platforms/hwcomposer/hwcomposer_backend.h plugins/platforms/virtual/virtual_backend.cpp plugins/platforms/virtual/virtual_output.cpp plugins/platforms/wayland/egl_wayland_backend.cpp plugins/platforms/wayland/wayland_backend.cpp plugins/platforms/wayland/wayland_output.cpp plugins/platforms/x11/windowed/x11windowed_backend.cpp plugins/platforms/x11/windowed/x11windowed_output.cpp plugins/scenes/opengl/scene_opengl.cpp plugins/scenes/opengl/scene_opengl.h plugins/scenes/qpainter/scene_qpainter.cpp plugins/scenes/qpainter/scene_qpainter.h pointer_input.cpp pointer_input.h scene.cpp scene.h shadow.cpp shadow.h tablet_input.cpp toplevel.cpp toplevel.h touch_input.cpp virtualdesktops.cpp virtualdesktops.h virtualkeyboard.cpp wayland_cursor_theme.cpp wayland_server.cpp wayland_server.h xdgshellclient.cpp xdgshellclient.h xkb.cpp xkb.h xwl/clipboard.cpp xwl/clipboard.h xwl/databridge.cpp xwl/databridge.h xwl/dnd.cpp xwl/dnd.h xwl/drag_wl.cpp xwl/drag_wl.h xwl/drag_x.cpp xwl/drag_x.h xwl/selection_source.cpp xwl/selection_source.h xwl/transfer.cpp xwl/transfer.h To: apol, #kwin, #plasma, #frameworks, davidedmundson Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29278: Port KWin to KWaylandServer
apol marked an inline comment as done. REPOSITORY R108 KWin BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 To: apol, #kwin, #plasma, #frameworks, davidedmundson Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29278: Port KWin to KWaylandServer
apol created this revision. apol added reviewers: KWin, Plasma, Frameworks. Herald added a project: KWin. Herald added a subscriber: kwin. apol requested review of this revision. REVISION SUMMARY Away from KWayland::Server and KF5WaylandServer. TEST PLAN Builds, ran nested session REPOSITORY R108 KWin BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 AFFECTED FILES CMakeLists.txt abstract_client.cpp abstract_client.h abstract_output.cpp abstract_output.h abstract_wayland_output.cpp abstract_wayland_output.h autotests/CMakeLists.txt autotests/integration/dont_crash_cursor_physical_size_empty.cpp autotests/integration/globalshortcuts_test.cpp autotests/integration/idle_inhibition_test.cpp autotests/integration/input_stacking_order.cpp autotests/integration/internal_window.cpp autotests/integration/lockscreen.cpp autotests/integration/maximize_test.cpp autotests/integration/plasmawindow_test.cpp autotests/integration/pointer_constraints_test.cpp autotests/integration/pointer_input.cpp autotests/integration/scene_opengl_shadow_test.cpp autotests/integration/scene_qpainter_shadow_test.cpp autotests/integration/scene_qpainter_test.cpp autotests/integration/test_helpers.cpp autotests/integration/transient_placement.cpp autotests/integration/xdgshellclient_test.cpp autotests/integration/xwayland_input_test.cpp autotests/integration/xwayland_selections_test.cpp autotests/mock_effectshandler.h autotests/test_window_paint_data.cpp composite.cpp debug_console.cpp decorations/decorationbridge.cpp effects.cpp effects.h effects/backgroundcontrast/contrast.cpp effects/backgroundcontrast/contrast.h effects/blur/blur.cpp effects/blur/blur.h effects/desktopgrid/desktopgrid.cpp effects/slidingpopups/slidingpopups.cpp events.cpp idle_inhibition.cpp idle_inhibition.h input.cpp keyboard_input.cpp keyboard_repeat.cpp libkwineffects/CMakeLists.txt libkwineffects/kwineffects.cpp libkwineffects/kwineffects.h linux_dmabuf.cpp linux_dmabuf.h main.cpp main_wayland.cpp platform.cpp platform.h platformsupport/scenes/opengl/CMakeLists.txt platformsupport/scenes/opengl/abstract_egl_backend.cpp platformsupport/scenes/opengl/abstract_egl_backend.h platformsupport/scenes/opengl/egl_dmabuf.cpp platformsupport/scenes/opengl/egl_dmabuf.h plugins/platforms/drm/drm_backend.cpp plugins/platforms/drm/drm_inputeventfilter.cpp plugins/platforms/drm/drm_output.cpp plugins/platforms/drm/drm_output.h plugins/platforms/drm/egl_stream_backend.cpp plugins/platforms/drm/egl_stream_backend.h plugins/platforms/drm/remoteaccess_manager.cpp plugins/platforms/drm/remoteaccess_manager.h plugins/platforms/fbdev/fb_backend.cpp plugins/platforms/hwcomposer/hwcomposer_backend.cpp plugins/platforms/hwcomposer/hwcomposer_backend.h plugins/platforms/virtual/virtual_backend.cpp plugins/platforms/virtual/virtual_output.cpp plugins/platforms/wayland/egl_wayland_backend.cpp plugins/platforms/wayland/wayland_backend.cpp plugins/platforms/wayland/wayland_output.cpp plugins/platforms/x11/windowed/x11windowed_backend.cpp plugins/platforms/x11/windowed/x11windowed_output.cpp plugins/scenes/opengl/scene_opengl.cpp plugins/scenes/opengl/scene_opengl.h plugins/scenes/qpainter/scene_qpainter.cpp plugins/scenes/qpainter/scene_qpainter.h pointer_input.cpp pointer_input.h scene.cpp scene.h shadow.cpp shadow.h tablet_input.cpp toplevel.cpp toplevel.h touch_input.cpp virtualdesktops.cpp virtualdesktops.h virtualkeyboard.cpp wayland_cursor_theme.cpp wayland_server.cpp wayland_server.h xdgshellclient.cpp xdgshellclient.h xkb.cpp xkb.h xwl/clipboard.cpp xwl/clipboard.h xwl/databridge.cpp xwl/databridge.h xwl/dnd.cpp xwl/dnd.h xwl/drag_wl.cpp xwl/drag_wl.h xwl/drag_x.cpp xwl/drag_x.h xwl/selection_source.cpp xwl/selection_source.h xwl/transfer.cpp xwl/transfer.h To: apol, #kwin, #plasma, #frameworks Cc: kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29256: [server] Introduce mapped() signal
apol accepted this revision. REPOSITORY R127 KWayland BRANCH introduce-mapped-signal REVISION DETAIL https://phabricator.kde.org/D29256 To: zzag, #kwin, davidedmundson, apol Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29079: android: include the architecture on the apk name
This revision was automatically updated to reflect the committed changes. Closed by commit R240:fca97c036c8d: android: include the architecture on the apk name (authored by apol). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29079?vs=80829=81480 REVISION DETAIL https://phabricator.kde.org/D29079 AFFECTED FILES toolchain/ECMAndroidDeployQt.cmake To: apol, #android, #frameworks, nicolasfella Cc: vkrause, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29256: [server] Introduce mapped() signal
apol added inline comments. INLINE COMMENTS > zzag wrote in surface_interface.cpp:333 > We can't use != because mapped() will be emitted each time a new buffer is > attached to the surface. I don't understand, ^ and != are logically equivalent, ^ is the bitwise counterpart. Am I missing something? REPOSITORY R127 KWayland BRANCH introduce-mapped-signal REVISION DETAIL https://phabricator.kde.org/D29256 To: zzag, #kwin, davidedmundson Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29256: [server] Introduce mapped() signal
apol added a comment. +1 INLINE COMMENTS > surface_interface.cpp:333 > const bool childrenChanged = source->childrenChanged; > +const bool visibilityChanged = bool(source->buffer) ^ > bool(target->buffer); > bool sizeChanged = false; Using != would probably be more readable and accurate (we're don't need it to be bitwise, we're assuming bool changes it to 1 or 0). REPOSITORY R127 KWayland BRANCH introduce-mapped-signal REVISION DETAIL https://phabricator.kde.org/D29256 To: zzag, #kwin, davidedmundson Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: Splitting KWayland
On Mon, Apr 27, 2020 at 2:57 PM Aleix Pol wrote: > > Hi, > As discussed in the meeting last week, I've been looking into the split. > > Here's what I was thinking of, please tell me if there's something > massively important I'm missing. > > The idea would be to start working on it after kwayland and other kf5 > have been tagged next week (?). > > Something I was wondering too is that I guess the new repos should end > up in invent? Although neither plasma or kf5 are there. > So maybe not? > > There's a couple of questions below as well, thoughts would be welcome > > Aleix > > git clone kde:kwayland > mv kwayland plasma-wayland-protocols > cd plasma-wayland-protocols > git rm -r autotests/ docs/ tests/ src/ > # fix build > # close https://phabricator.kde.org/T13024 > > git clone kde:kwayland > mv kwayland/ kwayland-server > git rm -r src/client/ > # namespace KWayland::Server -> namespace KWaylandServer > # fix build > # remove server tests? > # see to move things to KWin? > # close https://phabricator.kde.org/T13025 > > git clone kde:kwayland > # deprecate all KWayland::Server > # remove server tests? Here's an implementation of above: https://invent.kde.org/apol/plasma-wayland-protocols https://invent.kde.org/apol/kwayland-server My suggestion as next steps is to turn these into proper KDE repositories in its own right soon and develop master kwin and plasma overall against these. When 5.19 needs releasing, then the wayland protocol would be included in KF5. Can someone take a look and tell me if it's what they expected? If so I'll proceed to request the repositories and start talking to the different stakeholders. Aleix
D29231: [WIP] Add keyboard_shortcuts_inhibit protocol
apol added inline comments.
INLINE COMMENTS
> keyboard_shortcuts_inhibit_interface.cpp:144
> +QPair key(surface, seat);
> +if (m_inhibitors.contains(key)) {
> +return m_inhibitors[key];
Just `return m_inhibitors.value({ surface, seat })` to save a look-up and a few
lines of code.
REPOSITORY
R127 KWayland
REVISION DETAIL
https://phabricator.kde.org/D29231
To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh,
ngraham, bruns
D28882: Create protocol to manage video feeds
apol added a comment. > In future, it might be faster to put up just the interface xml for review first. @davidedmundson @zzag I don't really see how it would have made a difference, you only decided to review it 7 to 10 days after I first submitted it. 路 > What about using existing wl_output objects? The add_source event can be simplified quite a lot (even maybe dropped). For windows, we could use string handles. So your proposal would be to pass a random resource id or string and see what the compositor spits back? My intention was to keep the protocol auto-contained to some extent so every client doesn't need to track windows and screens to be able to request a stream. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson, zzag Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29231: [WIP] Add keyboard_shortcuts_inhibit protocol
apol added a comment. Code looks good overall, I'd say you'll get to polish the weird bits when developing the kwin side. In fact, this probably could be implemented within kwin considering what we discussed last week. We could remove the weirdness we have to keep its ABI. INLINE COMMENTS > keyboard_shortcuts_inhibit_interface.cpp:25 > +Private(Display *display, SurfaceInterface *surface, SeatInterface > *seat, KeyboardShortcutsInhibitorInterface* q) > +: zwp_keyboard_shortcuts_inhibitor_v1(*display, s_version) // TODO > check we want to use display > +, q(q) You'll want to connect it to the respective client here, it's not a global anymore. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D29231 To: bport, zzag, davidedmundson, apol Cc: crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28882: Create protocol to manage video feeds
apol updated this revision to Diff 81341. apol added a comment. Address review comments REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28882?vs=81113=81341 BRANCH master REVISION DETAIL https://phabricator.kde.org/D28882 AFFECTED FILES autotests/server/CMakeLists.txt autotests/server/test_screencasting.cpp src/client/CMakeLists.txt src/client/protocols/screencast.xml src/client/registry.cpp src/client/registry.h src/client/screencasting.cpp src/client/screencasting.h src/server/CMakeLists.txt src/server/display.cpp src/server/display.h src/server/screencasting_interface.cpp src/server/screencasting_interface.h To: apol, #kwin, jgrulich, davidedmundson Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28882: Create protocol to manage video feeds
apol marked 2 inline comments as done. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Splitting KWayland
Hi, As discussed in the meeting last week, I've been looking into the split. Here's what I was thinking of, please tell me if there's something massively important I'm missing. The idea would be to start working on it after kwayland and other kf5 have been tagged next week (?). Something I was wondering too is that I guess the new repos should end up in invent? Although neither plasma or kf5 are there. So maybe not? There's a couple of questions below as well, thoughts would be welcome Aleix git clone kde:kwayland mv kwayland plasma-wayland-protocols cd plasma-wayland-protocols git rm -r autotests/ docs/ tests/ src/ # fix build # close https://phabricator.kde.org/T13024 git clone kde:kwayland mv kwayland/ kwayland-server git rm -r src/client/ # namespace KWayland::Server -> namespace KWaylandServer # fix build # remove server tests? # see to move things to KWin? # close https://phabricator.kde.org/T13025 git clone kde:kwayland # deprecate all KWayland::Server # remove server tests?
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 12:55 PM Ben Cooksley wrote: > > On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol wrote: > > > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah wrote: > > > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > > > replies] > > > > > > Hello Community members, > > > > > > In view of upcoming Gitlab migration, we sysadmin team wants to share > > > the recommended structuring for the repositories on Gitlab. > > > > > > We had multiple options, > > > > > > - Flat structure: In this option we would have everything under one > > > single namespace/group: https://invent.kde.org/kde/knetwalk > > > - Subgroups under top-level group: In this option we would have a groups > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk > > > - Groups at top level: In this option we would establish a series of > > > groups at the top level, e.g. https://invent.kde.org/games/knetwalk > > > > > > We have discussed this with small but representative group of > > > contributors or maintainers, and based on their suggestions, we > > > recommend that we go with option 3. Having sub-groups at top level will > > > allow us to, > > > > > > - Provides good visibility on all reviews, tasks and other items within > > > the groups/modules we define > > > - Provides improvements to discoverability of projects > > > - Makes it possible for groups of projects to establish a group level > > > task board should it fit their needs (for tracking a release for > > > instance) > > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested > > > in option 2 is duplicative considering the Gitlab instance is under > > > kde.org. > > > - The discoverability of projects is maximised, as there is no need to > > > open the top level ‘KDE’ group before going into the subgroup. > > > > > > I've worked on draft "move" of the current set of the repositories in > > > their respective subgroups at the repo-metadata project's branch [1]. > > > You can browse the directory structure to get idea of how final > > > structure on Gitlab would look like. > > > > > > If we don't have any objections we would like to implement this next > > > week and move projects to https://invent.kde.org. > > > > > > Thanks! > > > Bhushan for sysadmin team > > > > > > [1] > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > > > Does this mean that to clone it we'll have to go "git clone > > kde:games/knetwalk" or something along the lines? > > Yes. > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > it's already uncomfortable for me to remember the URL for some of the > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > problem and I personally don't see the advantage. > > So you'd rather that we have no way to easily see a list of just > Plasma / Frameworks / PIM / etc reviews? > (See https://invent.kde.org/groups/kde/-/merge_requests for an example > of the problem) > > Not to mention the fact that there will be several hundred > repositories all in one group, so they will be completely > undiscoverable to anyone outside of our community. > > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > krita graphics or its own thing? > > > > I really prefer when I don't have to guess this kind of things when > > fetching a repository. > > There is always the search on Gitlab, and you can keep a checkout of > sysadmin/repo-metadata for grepping on. I don't know, I've always felt that the nesting we have nowadays stemmed from svn's tree structure more than convenience. I don't have the feeling I'd use that feature and I'm happy to convinced otherwise. While discoverability would be an incentive, I don't know if it will make a difference since it would be especially useful to see how repositories relate one to another, but it's something we generally split explicitly through frameworks so I don't see that will help much, other than for the very big suites (kdepim, plasma, etc). I know you don't like it when I do this, but: https://gitlab.gnome.org/explore/groups < gnome kept all the programs under the same group https://gitlab.freedesktop.org/explore/groups < didn't, but they have projects that have very little overlap of contributors Aleix
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah wrote: > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > replies] > > Hello Community members, > > In view of upcoming Gitlab migration, we sysadmin team wants to share > the recommended structuring for the repositories on Gitlab. > > We had multiple options, > > - Flat structure: In this option we would have everything under one > single namespace/group: https://invent.kde.org/kde/knetwalk > - Subgroups under top-level group: In this option we would have a groups > under KDE namespace: https://invent.kde.org/kde/games/knetwalk > - Groups at top level: In this option we would establish a series of > groups at the top level, e.g. https://invent.kde.org/games/knetwalk > > We have discussed this with small but representative group of > contributors or maintainers, and based on their suggestions, we > recommend that we go with option 3. Having sub-groups at top level will > allow us to, > > - Provides good visibility on all reviews, tasks and other items within > the groups/modules we define > - Provides improvements to discoverability of projects > - Makes it possible for groups of projects to establish a group level > task board should it fit their needs (for tracking a release for > instance) > - Makes the most semantic sense, as the ‘KDE’ top level group suggested > in option 2 is duplicative considering the Gitlab instance is under > kde.org. > - The discoverability of projects is maximised, as there is no need to > open the top level ‘KDE’ group before going into the subgroup. > > I've worked on draft "move" of the current set of the repositories in > their respective subgroups at the repo-metadata project's branch [1]. > You can browse the directory structure to get idea of how final > structure on Gitlab would look like. > > If we don't have any objections we would like to implement this next > week and move projects to https://invent.kde.org. > > Thanks! > Bhushan for sysadmin team > > [1] > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent Does this mean that to clone it we'll have to go "git clone kde:games/knetwalk" or something along the lines? If that's the case I'd much prefer if we didn't do this, at the moment it's already uncomfortable for me to remember the URL for some of the repos (e.g. is it sysadmin/ or not?), this will only increase the problem and I personally don't see the advantage. e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is krita graphics or its own thing? I really prefer when I don't have to guess this kind of things when fetching a repository. Aleix
D29216: Remove dead code since KF5.0: mount/umount devices in their contextmenu
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO BRANCH 2020_04_remove_dead_solid_code REVISION DETAIL https://phabricator.kde.org/D29216 To: dfaure, apol, broulik Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29181: Use KFileMetaData for XAttr support instead of private reimplementation
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D29181 To: bruns, #baloo, ngraham, apol Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
D28882: Create protocol to manage video feeds
apol updated this revision to Diff 81113. apol added a comment. Refactor the protocol as suggested by David and Vlad REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28882?vs=80984=81113 BRANCH master REVISION DETAIL https://phabricator.kde.org/D28882 AFFECTED FILES autotests/server/CMakeLists.txt autotests/server/test_screencasting.cpp src/client/CMakeLists.txt src/client/protocols/screencast.xml src/client/registry.cpp src/client/registry.h src/client/screencasting.cpp src/client/screencasting.h src/server/CMakeLists.txt src/server/display.cpp src/server/display.h src/server/screencasting_interface.cpp src/server/screencasting_interface.h To: apol, #kwin, jgrulich, davidedmundson Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28882: Create protocol to manage video feeds
apol marked an inline comment as done. apol added inline comments. INLINE COMMENTS > davidedmundson wrote in screencast.xml:31 > this is racey with create. Any suggestion on how to do it better? REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28882: Create protocol to manage video feeds
apol updated this revision to Diff 80984. apol added a comment. Also propagate the buffer size, it's important for the client to know what buffer size it will have. REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28882?vs=80801=80984 BRANCH master REVISION DETAIL https://phabricator.kde.org/D28882 AFFECTED FILES autotests/server/CMakeLists.txt autotests/server/test_screencasting.cpp src/client/CMakeLists.txt src/client/protocols/screencast.xml src/client/registry.cpp src/client/registry.h src/client/screencasting.cpp src/client/screencasting.h src/server/CMakeLists.txt src/server/display.cpp src/server/display.h src/server/screencasting_interface.cpp src/server/screencasting_interface.h To: apol, #kwin, jgrulich Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29102: Prefer QIcon::pixmap(QWindow*, ...) overload
This revision was automatically updated to reflect the committed changes. Closed by commit R242:25ce2b90dab1: Prefer QIcon::pixmap(QWindow*, ...) overload (authored by apol). REPOSITORY R242 Plasma Framework (Library) CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29102?vs=80908=80945 REVISION DETAIL https://phabricator.kde.org/D29102 AFFECTED FILES src/declarativeimports/core/iconitem.cpp src/declarativeimports/core/windowthumbnail.cpp To: apol, #plasma, #frameworks, davidedmundson Cc: davidedmundson, ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
D29102: Prefer QIcon::pixmap(QWindow*, ...) overload
apol created this revision. apol added reviewers: Plasma, Frameworks. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. apol requested review of this revision. REVISION SUMMARY It takes into account the dpi of the screen we're rendering to. Other overloads assume the window is nullptr and will use the primary screen's dpi which can change almost randomly. TEST PLAN Icons still look fine even if I drag windows from a screen to another. REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D29102 AFFECTED FILES src/declarativeimports/core/iconitem.cpp src/declarativeimports/core/windowthumbnail.cpp To: apol, #plasma, #frameworks Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29097: Adapt FindKF5 to stricter checks in newer find_package_handle_standard_args
apol added a comment. +1 makes sense REPOSITORY R240 Extra CMake Modules BRANCH avoidnewwarningsinfindkf5 REVISION DETAIL https://phabricator.kde.org/D29097 To: kossebau, #frameworks, #build_system, cgiboudeaux Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29063: Fix testpackage-appstream: XDG_DATA_DIRS needs to be explicitly extended
apol accepted this revision. apol added a comment. This revision is now accepted and ready to land. Looks like an improvement REPOSITORY R290 KPackage BRANCH fixXDG_DATA_DIRSextending REVISION DETAIL https://phabricator.kde.org/D29063 To: kossebau, #frameworks, mart, apol, sitter, bcooksley Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29079: android: include the architecture on the apk name
apol created this revision. apol added reviewers: Android, Frameworks. Herald added projects: Frameworks, Build System. Herald added subscribers: kde-buildsystem, kde-frameworks-devel. apol requested review of this revision. REVISION SUMMARY Makes them easier to use afterwards. TEST PLAN Tested locally REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D29079 AFFECTED FILES toolchain/ECMAndroidDeployQt.cmake To: apol, #android, #frameworks Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29062: Port KToolInvocation::kdeinitExecWait to QProcess
apol accepted this revision.
apol added inline comments.
This revision is now accepted and ready to land.
INLINE COMMENTS
> kded.cpp:67
>
> static void runKonfUpdate()
> {
The function has a typo, should be `runKConfUpdate`, no?
REPOSITORY
R297 KDED
REVISION DETAIL
https://phabricator.kde.org/D29062
To: broulik, davidedmundson, #frameworks, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
