I've put in a booth request now. No devroom, though -- that would take some non-zero coordination with GNOME or other desktops, and I don't think we have the time or energy for that just now.

For *3B*, that's an attempt to quantify "you must be active in promo". Maybe it quantifies "you must be active in promo and do more than just push the button on social media accounts". I think *10* provides a mechanism to handle inactivity. Where exactly is the unfairness? Someone who takes on only high-effort tasks does more work to qualify for *3B*, but they could also do a low-effort one once, if the high-effort ones are all failing.

Tangentially related: kde-promo mailing list administration. That doesn't give any posting power, at best it gives the power to filter out posts by non-members to that list (e.g. you can stop spam, and very very rarely stop actual mail from non-subscribers). Right now Lydia and I do that (small) bit of administration, but it should be added to the "things promo keeps track of".

The neon part perhaps belongs here, but as a Calamares ticket it should be elsewhere.

Sorry, this is getting very confusing:

Totals: 44 passed, 2 failed, 0 skipped, 0 blacklisted, 225ms

This shows up in the unit tests. Whether it has any effect in real life is unknown. FreeBSD often -- sometimes, maybe, depending on FS setup and layout -- has /home -> /usr/home or /home -> usr/home, and of course there could be weird user setups as well where .cache is symlinked to a different location with more disk space. In any case, this is triggering unit-test failures in the CI, so cleaning it up to consistently compare the same kind of filename is a good thing. I'll give this a test on my home system and give a shout when I have.

Stuff we need

.. the CMake error is because a55b13c3f3a5ba4ab081dbf5f0493d35a39a743c does not have an endif() added in the new if-clause.

I also spotted some discussion of this on IRC. I think the fwupd is now optional everywhere since a55b13c3f3a5ba4ab081dbf5f0493d35a39a743c . However, current git master gives me:

Looks sensible to me: when the ratio is small, 5.6E-4 is not very informative for many people, while 0.00056 might be (and with 2 places precision, I'd hope it becomes 0.00).

• Start systemsettings; under *workspace*, *startup and shutdown*, find *background services*.
• Untick the box for *Drive Ejector*; also check status is *not running*, click *stop* button if it is still running.
• Insert CD, pick *open in file manager* from the device notifier popup
• Check that it's mounted, from a konsole
• Press button on CD drive: no result
• Choose eject from device notifier: CD is ejected

It's not clear to me what this revision is trying to change (in terms of user-visible behavior) or how to test the change; what I've written above is current behavior on FreeBSD 11 with Plasma 5.12.5; HAL is running.

Since the ticket is rather unclear on what functionality is being tested, or how:

Use the right place (sorry Christophe, to use a Dutch phrase:
I must have been looking with my nose).

Something to consider, though, is that it might perhaps be useful to have kdnssd build -- without a backend -- for environments where there is no real dnssd and any service discovery returns "not found". Requiring a backend makes that impossible.

The FindFFmpeg CMake module uses pkg-config modversions to determine the overall version. These don't match the notion of "FFmpeg release 3.1" because the libraries are versioned separately. For instance:

Comments directed at licensing and non-Linux cases.

What you could do, is to ask on the distributions@k.o list, to find out who ships what. FreeBSD, for instance, has /usr/local/lib/libavformat.so.57.83.100 so that looks like it would be ok. Debian stable, on the other hand ..

The real insight is in https://bugs.kde.org/show_bug.cgi?id=381850 from Alexandre Martins. I'm mostly messing around trying to auto-set the socketbuffer size correctly.

Since you're using a global variable to accumulate ${numberOfProcesses} worth of po-files in one go, you should definitely clear out the variable when that bunch has been processed, or you'll grind through each po file more than once (with a growing command-list, too). You might consider the earlier version of the patch, which removes the global variable for a function parameter.

Accepted as "doesn't hurt the non-Linux crowd, since they all live in the #ifndef Q_OS_LINUX branch"

Given the other reviews (which just drop this function), this one should be abandoned. tcberner@?

The question is mostly: does the existing (complicated) code do anything that QStorageInfo doesn't? Because switching to QStorageInfo gives us the functionality on FreeBSD for free (even if it's not useful because we'll never have btrfs).

I'm so happy :)

To assess the problem, you could static_assert that st_dev and st_ino are size 4 or less. That would tell you if any system right now is losing information. (Typo in the comment in statBufToId() btw).

@rominf was debugging this on IRC. In Qt 5.7, the QAction constructor gained a default value for explicit QAction(QObject *parent = nullptr);. It did not have this in Qt 5.6. This patch adds the argument to the constructor, so that Spectacle compiles with Qt 5.6. An alternative would be to bump the Qt requirement to 5.7, but that leaves LTS distro's in the cold (actually, Spectacle's CMakeLists requires Qt 5.4).

In D10450#204623, @kossebau wrote:

"This (hopefully) fixes the build failure noticed in the FreeBSD (and some linuxes)" - leaves the question: why should it exactly fix it? :)

Associated bug https://bugs.kde.org/show_bug.cgi?id=389982

Already done by @staniek

Already done by @staniek

To understand the expected output better: suppose something says "platforms: All", like kcontacts. If there's no actual build configured in CI for that something, for FreeBSD, it will say "FreeBS is a disabled platform". The message can probably be improved, then. And how about checking the reverse, too? CI builds that are not listed in the metainfo? (if that can even happen)

Seems sensible from a packaging and release standpoint, so I'll say "LGTM", but I don't really like it from an application-versioning standpoint since releases happen regularly regardless of changes in the application itself.

LGTM. Better in Breeze (there's a little less padding before the radio buttons), Fusion and Win95 themes.

Careful use of -platform minimal allows running the tool with no changes to the code or kcm.

We should be cautious in mixing up what Calamares (not a KDE project) does with what the desktop environment might do. For background, Calamares can be used in two ways:

• as a system installer; you boot a live CD or memory stick, and install some (Linux) system to a hard disk
• as a system configurator; you boot a newly purchased laptop and it starts into a "newuser" which reconfigures the system with the user preferences (and login name) you give

Here's what it looks like in the implementation.

There's a bit of a background here -- and thanks, Jens, for mocking something up and thanks Andy for thinking along on the actual text. Calamares is used by various distro's. Some want it to phone home at the end of installation. Some, like Debian derivatives, have the Debian machine-tracking stuff which can be enabled/disabled. Some could enable KDE's User Tracking stuff that Volker was working on over the summer. So there are quite some technical differences between the options -- we can hide all that in the descriptions (behind the ? button) I suppose. I use "tracking" because that's the kind of scary word *I* want to see, encouraging me to turn it off -- I can totally understand using a more friendly word on the distro's side, who want people to turn it *on*.

FindGraphviz.cmake uses DOT as well for finding the version of GraphViz that is installed -- not that the current module or code supports checking hthat version, but it's there.

Should be done by fixing the contents of ${graphviz_LIBRARIES}{ instead.

The fix is to make ${graphviz_LIBRARIES} contain the full paths to the libraries (as is common with find_library() calls) instead of naming libs suitable for use with -l. This requires another approach (I';ll still suggest fixing up the version-checking code,though).

Missed 4 other dependency-loop files.