KDM + ConsoleKit + Logind
Ahoys I was looking for some input on KDM+CK in a Logind world. When a system is using Logind I guess KDM+CK doesn't do much useful, so the question arose whether distributions with such a lineup should build without CK support. In short: If the rest of the system uses Logind, should KDM be built without CK support? Would building without CK support reduce user functionality, and if so aren't we then essentially requiring distributions that use KDM to continue using CK until Plasma Next comes along? (we are not communicating this very if this is the case). TIA HS
Re: KDM + ConsoleKit + Logind
On Mon, Feb 17, 2014 at 2:09 PM, Matthias Klumpp wrote: > 2014-02-17 13:55 GMT+01:00 Lukáš Tinkl : >> Dne 17.2.2014 11:51, Harald Sitter napsal(a): >> >>> Ahoys >>> >>> I was looking for some input on KDM+CK in a Logind world. When a >>> system is using Logind I guess KDM+CK doesn't do much useful, so the >>> question arose whether distributions with such a lineup should build >>> without CK support. In short: >>> >>> If the rest of the system uses Logind, should KDM be built without CK >>> support? >>> >>> Would building without CK support reduce user functionality, and if so >>> aren't we then essentially requiring distributions that use KDM to >>> continue using CK until Plasma Next comes along? (we are not >>> communicating this very if this is the case). >> Hi, >> I'm not entirely sure about kdm but for the rest of the code in >> kde-workspace (kworkspace, powerdevil et co.), login1 support is fairly >> complete and preferred over CK. > We are using a KDE 4.11 systemd running on pure logind in Tanglu > without any reported issues. KDM has multiseat patches applied, which > were taken from[1]. > We also adjusted some other dependencies, but that was just minor work > on the packaging. > So yes, you can use KDM with logind, but I am not sure that using it > at all will make sense long-term, since KDM is dead now. Right, but short of patching KDM to gain proper logind support, should one build with or without CK, i.e. does CK add anything useful if the rest of the system is not using it anyway? I mean, it's a crappy situation either way. The DM we ship with our workspace is not maintained and suggests usage of CK while the rest of the workspace really wants logind, so, not the most consistent requirement set to begin with. HS
Re: KDM + ConsoleKit + Logind
On Tue, Feb 18, 2014 at 2:30 AM, Rex Dieter wrote: > Harald Sitter wrote: > >> Right, but short of patching KDM to gain proper logind support, should >> one build with or without CK, > > build without it. > >> i.e. does CK add anything useful if the >> rest of the system is not using it anyway > > no. As I understand it, this is the only case where you'd want to consider > keeping CK support, if you had apps that still used the CK-api to check for > active sessions. Okey dokey, thanks guys. <3 HS
ECM uninstall target
alohas, I just ported phonon/five to ECM and noticed that apparently ECM does not have an include or something to introduce an uninstall target. Are there plans to introduce such a thing or am I simply blind and not seeing the already existing include? HS
kubuntu 14.04 and 4.13rc/final
salut, Kubuntu 14.04 is due for release on April 17 and since that is very close to 4.13 final tagging/release it is going to be a tight squeeze to get the final on the release ISO. While landing the final is very much the intended course of action there is a chance that we won't be able to make it. If your software has bugs in rc1 that were fixed meanwhile I'd be very happy if you could point that out so I can cherrypick all the changes from git and push them into the Kubuntu rc packaging. This is very much a fallback plan in case landing final does not work out, if it does everything will be fine either way. But we'd best cover our bases :) HS
Re: KDE Frameworks Release Cycle
On Mon, May 5, 2014 at 11:11 AM, Martin Klapetek wrote: > On Sun, May 4, 2014 at 6:36 PM, David Faure wrote: >> >> [Cross posting against my will...] >> >> On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote: >> > I understand that the big concern was about the testing: stable branches >> > did >> > not receive the same attention >> >> This is not the main concern. >> >> My main concern is that application developers prefer to work around bugs >> in >> KF5 (previously: kdelibs) rather than fix things at the right level, >> because >> "fixes in KF5 will only be available in 6 months, and I want the bug fixed >> now". >> >> Your suggestion (6-months "stable" release) brings us back to exactly >> that. >> >> We'd like to try something better. Monthly small increments. >> Never "big" changes that break things, they get cut into small increments >> too. >> So no reason to buffer changes for 6 months. > > > However this highly depends on the distro policies - if some of the big > distros say "we will not update KF5 every month because our policies", then > the 6 months buffer is just moved elsewhere, at the distro level because > they will update only with the new release. If the application makes a hard > requirement on some specific version (which would be the point of this), > then distros would not package that fixed app before there would be that > particular version of KF5, so I imagine the app developers would still work > around the bugs in their own code and release a minor version which the > distro would package. Or worse there would be patches at distro level. (please also note the relevant thread on the kde-release ML) You always have an arbitrary delay between when we release something and when a distro ships it, completely independent of our own cadence. Currently we may release every 6 months, that does not mean that distros do, nor does it mean that a distro releases according to our schedules. For example had Kubuntu stuck to their own feature freeze then Kubuntu 14.04 would have shipped with KDE Platform and Applications 4.12 rather than 4.13. So, a monthly release definitely resolves the presented argument of people having to do workarounds (well, at least redcues the scope). As the primary problem is that until a new kdelibs becomes available to all users of the bigger distributions you have to look at about a year, dependening on how our 6 month cadance aligns with the respective distro schedules. So, the distro might be to include $app 3 months after its release, but there is no new kdelibs yet, so $app is blocked because the next kdelibs release is in another 3 months, at which point $distro is in feature freeze... That being said, with a monthly release scheme: if a distro can pick up a new version of $app they can also pick up a new montly release for frameworks, and if they can't pick up a new version of $app then it doesn't matter anyway. So actually dependening on a very specific and very new version of a framework becomes less of a problem from an application developer POV; there's at most one month between $app release and the next frameworks release. HS
Re: SDDM-KCM In Review
On Mon, Oct 6, 2014 at 11:48 PM, Albert Astals Cid wrote: > There is no COPYING file (not sure if this one is mandatory or not, ask > Riddell) Mandatory it is. At least for just about all GNU licenses as they even explicitly mention that a full copy needs to accompany the source. HS
Re: Review Request 121083: Replace manual export files with CMake's generate_export_header
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121083/#review70761
---
This breaks the kde4 build as ECM is not being used there and
generate_export_header is not available without ECM.
- Harald Sitter
On Nov. 21, 2014, 10:47 p.m., Andrius da Costa Ribas wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121083/
> ---
>
> (Updated Nov. 21, 2014, 10:47 p.m.)
>
>
> Review request for kde-workspace and kdewin.
>
>
> Repository: oxygen
>
>
> Description
> ---
>
> These files currently use
>
> ```
> __attribute__((visibility("...")))
> ```
>
> which doesn't work on MSVC.
>
>
> Diffs
> -
>
> liboxygen/oxygen_config_export.h 02ea29d
> liboxygen/oxygen_export.h b8877a0
> liboxygen/CMakeLists.txt 69b7bd2
>
> Diff: https://git.reviewboard.kde.org/r/121083/diff/
>
>
> Testing
> ---
>
> Builds with msvc 2013 64bit
>
>
> Thanks,
>
> Andrius da Costa Ribas
>
>
Re: Review Request 121083: Replace manual export files with CMake's generate_export_header
> On Nov. 22, 2014, 12:18 a.m., Harald Sitter wrote:
> > This breaks the kde4 build as ECM is not being used there and
> > generate_export_header is not available without ECM.
>
> Andrius da Costa Ribas wrote:
> generate_export_header isn't in ECM, but in cmake itself
> (http://www.cmake.org/cmake/help/v3.0/module/GenerateExportHeader.html). Does
> kde4 required cmake version not support it? Should I revert this commit?
Ah, I was not aware of that. So the solution probably is to move the
include(GenerateExportheader) line outside the if-else for kf5/kde4
- Harald
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121083/#review70761
---
On Nov. 21, 2014, 10:47 p.m., Andrius da Costa Ribas wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121083/
> ---
>
> (Updated Nov. 21, 2014, 10:47 p.m.)
>
>
> Review request for kde-workspace and kdewin.
>
>
> Repository: oxygen
>
>
> Description
> ---
>
> These files currently use
>
> ```
> __attribute__((visibility("...")))
> ```
>
> which doesn't work on MSVC.
>
>
> Diffs
> -
>
> liboxygen/oxygen_config_export.h 02ea29d
> liboxygen/oxygen_export.h b8877a0
> liboxygen/CMakeLists.txt 69b7bd2
>
> Diff: https://git.reviewboard.kde.org/r/121083/diff/
>
>
> Testing
> ---
>
> Builds with msvc 2013 64bit
>
>
> Thanks,
>
> Andrius da Costa Ribas
>
>
Re: Review Request 121083: Replace manual export files with CMake's generate_export_header
> On Nov. 22, 2014, 12:18 a.m., Harald Sitter wrote:
> > This breaks the kde4 build as ECM is not being used there and
> > generate_export_header is not available without ECM.
>
> Andrius da Costa Ribas wrote:
> generate_export_header isn't in ECM, but in cmake itself
> (http://www.cmake.org/cmake/help/v3.0/module/GenerateExportHeader.html). Does
> kde4 required cmake version not support it? Should I revert this commit?
>
> Harald Sitter wrote:
> Ah, I was not aware of that. So the solution probably is to move the
> include(GenerateExportheader) line outside the if-else for kf5/kde4
>
> Albert Astals Cid wrote:
> Andrius: kdelibs4 has to work on cmake 2.8.9, when was that introduced?
If kubuntu packaging can be trusted it was there before that (e.g. was already
in 2.8.7)
- Harald
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121083/#review70761
---
On Nov. 21, 2014, 10:47 p.m., Andrius da Costa Ribas wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121083/
> ---
>
> (Updated Nov. 21, 2014, 10:47 p.m.)
>
>
> Review request for kde-workspace and kdewin.
>
>
> Repository: oxygen
>
>
> Description
> ---
>
> These files currently use
>
> ```
> __attribute__((visibility("...")))
> ```
>
> which doesn't work on MSVC.
>
>
> Diffs
> -
>
> liboxygen/oxygen_config_export.h 02ea29d
> liboxygen/oxygen_export.h b8877a0
> liboxygen/CMakeLists.txt 69b7bd2
>
> Diff: https://git.reviewboard.kde.org/r/121083/diff/
>
>
> Testing
> ---
>
> Builds with msvc 2013 64bit
>
>
> Thanks,
>
> Andrius da Costa Ribas
>
>
Re: kio-extras
On Thu, Jan 22, 2015 at 11:42 AM, Jonathan Riddell wrote: > kio-extras is currently released part of Plasma 5. It's need said > that it would be better to be part of applications because they're > plugins used by applications and typically not by the desktop. They are plugins used by kio... any app using kio can potentially use them, even if the app isn't aware of that (e.g. think of the file open dialog). That being said I am not sure workspace is the right place for some of them. If anything most of them should probably go into frameworks though. I'd find it very odd if the file open dialog suddenly can't access sftp. There's only a handful that actually aren't that useful. > With > Plasma 5.2 about to go out shall I ask for kio-extras to be moved and > if so into which module? As bshah's link points out there are dependencies of workspace bits to very specific slaves so they would definitely need splitting if kio-extras were to move to an application scope. HS
Re: Review Request 122404: [OS X]: draft support for audio in the IOKit backend
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122404/#review75306 --- I really think this code needs to be in phononserver or better yet Phonon itself (akin to the pulsesupport) or even better in VLC. The solid audiointerface stuff is gone in frameworks5, so ultimately this is a dead end. Equally phononserver is bound to go away at some point in the future and being replaced by listing exclusively what phonon reports (which in turn is pulseaudio listing || backend listing). So, enabling VLC to expose this information through the libvlc_audio_output_device enumerable would be the best course of action. If the VLC devs don't want that or whatever, then putting it in Phonon seems the most useful approach. - Harald Sitter On Feb. 3, 2015, 12:44 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122404/ > --- > > (Updated Feb. 3, 2015, 12:44 p.m.) > > > Review request for KDE Software on Mac OS X, kdelibs, Phonon, and Solid. > > > Repository: kdelibs > > > Description > --- > > While trying to bring a functional Multimedia kcm to OS X (see > https://git.reviewboard.kde.org/r/122403/), I realised that Solid's IOKit > backend doesn't currently support audio devices. > > This RR outlines the current state of my draft attempt to provide that > support. I'm handicapped by my lack of experience with both IOKit and Solid, > and would thus appreciate a helping hand. > > I'm currently at a stage where Solid returns a list representing the audio > devices present in my system, but apparently not with the correct metadata > for phononserver to consider them, despite the fact that I pretend all > devices to be pluripotent (i.e. AUDIOCONTROL|AUDIOINPUT|AUDIOOUTPUT) : > > ``` > kded(81671)/phonon (kded module) PhononServer::findDevices: Solid offers 5 > audio devices > kded(81671)/phonon (kded module) PhononServer::findDevices: Solid offers 0 > video devices > ... > kded(81671)/phonon (kded module) PhononServer::findDevices: groups: () > kded(81671)/phonon (kded module) PhononServer::findDevices: already found > devices: QSet() > kded(81671)/phonon (kded module) PhononServer::findDevices: Audio Playback > Devices: () > kded(81671)/phonon (kded module) PhononServer::findDevices: Audio Capture > Devices: () > kded(81671)/phonon (kded module) PhononServer::findDevices: Video Capture > Devices: () > kded(81671)/kded4 *Kded::loadModule: Successfully loaded module "phononserver" > ``` > > I'll add a more complete log as an attachment. > > > Diffs > - > > solid/solid/CMakeLists.txt a7f1f07 > solid/solid/backends/iokit/iokitdevice.cpp f113c16 > solid/solid/backends/iokit/iokitmanager.cpp fcd748e > solid/solid/devicemanager.cpp a465169 > > Diff: https://git.reviewboard.kde.org/r/122404/diff/ > > > Testing > --- > > On OS X 10.9.5/MacPorts with kdelibs 4.14.4 (git/master), kde4-runtime > (git/master) and kde4-workspace (git/master); phonon 4.8.3 with > phonon-backend-gstreamer 4.8.2 . > > > File Attachments > > > full trace with debug output > > https://git.reviewboard.kde.org/media/uploaded/files/2015/02/03/67a59590-84a4-4d30-88aa-332d9f068a2c__Solid-20150203.log > > > Thanks, > > René J.V. Bertin > >
Re: Kdenlive joining KDE Applications (in kdemultimedia?)
On Fri, Feb 13, 2015 at 5:31 PM, Vincent Pinon wrote: > So this mail is to get your feedback and prepare the move, if OK for you. It appears to me that at least once there is an mkpath call missing before trying to write a file http://i.imgur.com/QkDMTiC.jpg Also all buttons in the track editor have unavailable icons set. The branch looks decent other than that. MLT not having had a release worries me a bit though. That is pretty much a show-stopper. Do we have an approximate date for when they intend to release? HS
Re: Kdenlive joining KDE Applications (in kdemultimedia?)
On Wed, Feb 18, 2015 at 3:23 PM, Vincent Pinon wrote: > Le mercredi 18 février 2015, 10:03:28 Harald Sitter a écrit : >> MLT not having had a release worries me a bit though. That is pretty >> much a show-stopper. Do we have an approximate date for when they >> intend to release? > Release 0.9.4 was out on Monday :-) Splendid. +1 from me > So we should get it built on CI systems before changing CMakeFile, > who should we work with for this? Best file a sysadmin ticket I suppose. Or try to catch bcooksley on IRC. HS
Re: Review Request 122812: Fix BIC introduced in kdelibs 4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122812/#review77046 --- Ship it! Looks good. Also as for how to deal with kdelibs being broken: I would suggest to simply release 4.14.6.1 as a hotfix release with only this change (could be as trivial as repacking the tarball with the patch applied). Albert, would you be so kind? :) Short of a hotfix release I guess informing packagers is the next best thing we can do at this point. - Harald Sitter On March 4, 2015, 5:26 p.m., Andrea Iacovitti wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122812/ > --- > > (Updated March 4, 2015, 5:26 p.m.) > > > Review request for kdelibs and Albert Astals Cid. > > > Repository: kdelibs > > > Description > --- > > First of all sorry for that! > In commit c2046dd7064634d4d6ba50cafd8b1047bd133859 I introduced a BIC by > renaming public DOMString::trimSpaces() to DOMString::parsedUrl(). > However AFICT trimSpaces() was only used internally by khtml. > I can either revert the commit or apply this patch that reinstate old > DOMString::trimSpaces() and mark it as deprecated. > > > Diffs > - > > khtml/dom/dom_string.h 087f697 > khtml/dom/dom_string.cpp a3c4abd > > Diff: https://git.reviewboard.kde.org/r/122812/diff/ > > > Testing > --- > > > Thanks, > > Andrea Iacovitti > >
Re: kdesudo in git
On Thu, Aug 20, 2015 at 3:28 PM, Jonathan Riddell wrote: > On Thu, Aug 20, 2015 at 02:01:58PM +0200, Luigi Toscano wrote: >> Maybe it's possible to change kdesu to expose a "please cache this" property >> between backend and frontend (in a secure way). Better than keeping two >> programs for exactly the same thing. > > I couldn't work out a secure and easy way to do that when I looked at it > years ago, kdesudo works so we went with that. To be honest (and I realize I made this argument for the past 4 years but.. ;)) I am not sure one should put effort into this at all. That is to say the marginal advantage kdesudo offers over kdesu hardly seems worthwhile with su'ing things pretty much being one-off things and in an ideal world would be entirely replaced by polkitted built-in support (e.g. dolphin and applications doing file operations as a different user). In particular since wayland adoption will likely start in a year or so, at which point someone probably needs to port kdesudo to wayland and I really do not see that happening because the code base is perfectly hackish IIRC. So, I stand by what I said in the past. Give kdesu (which lives in libexec presently) a bin/kdesu wrapper that people can use to elevate random apps and let kdesudo die. If one finds themselves kdesuing so much that they get annoyed by the lack of caching they are probably on to a feature problem with whatever application they are kdesuing constantly and time had better been spent solving that problem rather than maintaining kdesudo or looking into making kdesu cache. HS
folder icons where should they be set
salut mes amis so this popped up https://bugs.kde.org/show_bug.cgi?id=352498 and GTK/Gnome rather seems to set the folder icon as part of their folder-display-component sort of thing (e.g. file open as well as file browsers and what not). it does so however *without* creating a .directory file hardcoding a relevant icon now the question is where this sort of thing needs to be implemented in our tech to get all folder displaying things to display the correct icon. being my confused self I am rather clueless as to where the correct place to implement this is, so any help on this would be very welcome. thanks HS
Re: folder icons where should they be set
On Fri, Sep 11, 2015 at 9:43 AM, Thomas Lübking wrote: > On Freitag, 11. September 2015 09:37:44 CEST, Harald Sitter wrote: >> >> http://freedesktop.org/wiki/Software/xdg-user-dirs/ > > > "Interesting" concept where the system keeps creating directories on the > user on login an requires him to vim ~/.config/userdirs.dirs to stop that... > > That's of course "supportable" but I would personally never install it. It is being employed by all mainstream distributions. Hence the desire of the VDG to theme these folders :) HS
Re: folder icons where should they be set
http://freedesktop.org/wiki/Software/xdg-user-dirs/ On Fri, Sep 11, 2015 at 8:57 AM, Thomas Lübking wrote: > On Freitag, 11. September 2015 00:16:35 CEST, Harald Sitter wrote: > >> being my confused self I am rather clueless as to where the correct >> place to implement this is, so any help on this would be very welcome. > > > http://www.linfo.org/etc_skel.html > > Guessing the "correct" folder icon by the directory name/path is rather > wonky. > I don't have ~/music or ~/images but somewhen (ages ago) created ~/MyFiles > and put subdirs for specific types there. > > So i rather have ~/MyFiles/Images than eg. "~/Images" or "~/My Images" or > "~/MyImages" or "~/Meine Bilder" - which is localized and that's the next > problem of "guessing" icons from directory names. > > A distro could possibly add downstream patches to dolphin and/or KFileItem > to match their autocreated paths (because they also patched useradd instead > of using /etc/skel?) but I doubt there's any way to do that upstream without > adding a *very* long and hackish list of path/icon mapping (ending up > incompatible with the hackish(?) list in gnome and totally not covering > other desktop environments. > > => simply follow the present standards to > a) create a $HOME structure > b) define directory icons etc. > > Cheers, > Thomas
Re: folder icons where should they be set
On Fri, Sep 11, 2015 at 9:00 AM, Kai Uwe Broulik wrote: > Hi, > > Aren't these XDG standard dirs you can even configure? Just show the folder > at XDG images with a pictures folder icon and so on. "Just" xD I did however find kfileitem.cpp which seems like the right place and I do have a prototype essentially acting as fallback if no .directory is set comparing the path of the item with qstandardpaths location. > If you use different folders without telling the system, it's your own fault > ;) +1
breeze repo to be split into breeze and breeze-icons come plasma 5.5
Some time between now and plasma 5.5 branching we will split the breeze icon theme from the breeze repo to its own breeze-icons repo. HS
qca-qt5 (qt5 branch) merge into qca (master branch)
ahoy ahoy qca-qt5 as a "thing" is a build time switch on the same source as qca (qt4). so, it is the same source base but depending on how you run cmake you either get the qt5 or the qt4 build. originally various adjustments had to be made to qca-qt5 to make it work reliably without conflicting with qca (qt4), there was however a very long discussion on whether or not that is the right thing to do which eventually ended in the maintainer stepping down [anyone wanna maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5 as a tarball was released which had the changes and could co-exist with the regular qca tarball. now, since qca essentially has no lead authority we could do what was the original intention here. i.e. make the qca source base build two distinct libraries for qt4 and qt5 that do not conflict in any form or fashion. this would be a simple `git merge qt5` and then we can release a qca tarball that replaces the old qca-qt5 tarball. Q: any objections to merging qca's qt5 branch into master and replacing the qt5 tarball with a new release that supports both qt4 and qt5? HS
Re: qca-qt5 (qt5 branch) merge into qca (master branch)
QCA's qt5 branch has now been merged back into master. master now behaves like qt5 did. If qt5 is found libqca-qt5 is built, if it isn't found qt4 is a requirement and libqca will be built. You can override this behavior by using the cmake option QT4_BUILD. Going to prep a tarball shortly. HS
Review Request 125529: switch kde4libs defaults from oxygen to breeze
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125529/ --- Review request for kdelibs and Jonathan Riddell. Repository: kdelibs Description --- This enables tighter integration with default Plasma 5 appearance in all cases, previously all KDE4 applications would be themed using the Plasma 5 Breeze style through a kconf_update script called kde4breeze. This util writes configs into the user home to make sure KDE4 apps appear breeze themed. Unfortunately this does not work with sudo'd applications as they would use a different HOME and thus use the Oxygen theme by default, making them not fit in with the rest of the default theming. The patch switches the default icon theme as well as widget style from oxygen to breeze. It also adjusts the hardcoded default color values in kcolorscheme from oxygen to breeze (thanks to Kai Uwe Broulik https://git.reviewboard.kde.org/r/124872/) Diffs - kdeui/colors/kcolorscheme.cpp a6650ace52117c4abcfc1893228dc23e3ab6299a kdeui/icons/kicontheme.cpp d9efbb0275e1094c887bb62382d5ddb4135684d7 kdeui/kernel/kstyle.cpp 95a71c24842338fbe6bf5128f6fb76029960b64a Diff: https://git.reviewboard.kde.org/r/125529/diff/ Testing --- Thanks, Harald Sitter
Re: Review Request 125529: switch kde4libs defaults from oxygen to breeze
> On Oct. 5, 2015, 2:46 p.m., Hrvoje Senjan wrote: > > As this is a behvioral change (well, closest categorisation), i would avoid > > merging this to kdelibs4, and mail kde-distro-packagers with a link to this > > review instead ;-) Yeah, I pretty much agree but I thought I'd post it all the same to see if someone actually strongly objects xD - Harald --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125529/#review86378 --- On Oct. 5, 2015, 2:21 p.m., Harald Sitter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125529/ > --- > > (Updated Oct. 5, 2015, 2:21 p.m.) > > > Review request for kdelibs and Jonathan Riddell. > > > Repository: kdelibs > > > Description > --- > > This enables tighter integration with default Plasma 5 appearance in all > cases, previously all KDE4 applications would be themed using the Plasma 5 > Breeze style through a kconf_update script called kde4breeze. This util > writes configs into the user home to make sure KDE4 apps appear breeze > themed. Unfortunately this does not work with sudo'd applications as they > would use a different HOME and thus use the Oxygen theme by default, making > them not fit in with the rest of the default theming. > The patch switches the default icon theme as well as widget style > from oxygen to breeze. > It also adjusts the hardcoded default color values in kcolorscheme from > oxygen to breeze > (thanks to Kai Uwe Broulik https://git.reviewboard.kde.org/r/124872/) > > > Diffs > - > > kdeui/colors/kcolorscheme.cpp a6650ace52117c4abcfc1893228dc23e3ab6299a > kdeui/icons/kicontheme.cpp d9efbb0275e1094c887bb62382d5ddb4135684d7 > kdeui/kernel/kstyle.cpp 95a71c24842338fbe6bf5128f6fb76029960b64a > > Diff: https://git.reviewboard.kde.org/r/125529/diff/ > > > Testing > --- > > > Thanks, > > Harald Sitter > >
Re: Review Request: Phonon KDED module: Improve finding virtual devices from ALSA
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100700/#review1562 --- phonon/kded-module/phononserver.cpp <http://git.reviewboard.kde.org/r/100700/#comment1342> Is this ever coming back? If not, please remove it completely, if it is please add a comment and ultimately a TODO or FIXME. phonon/kded-module/phononserver.cpp <http://git.reviewboard.kde.org/r/100700/#comment1343> Style: left curly brace goes on the same line as the start of the statement phonon/kded-module/phononserver.cpp <http://git.reviewboard.kde.org/r/100700/#comment1347> "Fix *the*" maybe? phonon/kded-module/phononserver.cpp <http://git.reviewboard.kde.org/r/100700/#comment1344> Style: left curly brace goes on the same line as the start of the statement phonon/kded-module/phononserver.cpp <http://git.reviewboard.kde.org/r/100700/#comment1345> Style: left curly brace goes on the same line as the start of the statement phonon/kded-module/phononserver.cpp <http://git.reviewboard.kde.org/r/100700/#comment1346> The rationale of this is not really convincing, if only the VLC backend has problems, then the VLC backend should change the name accordingly. Also Rémi Denis-Courmont indicated on the phonon-backends list that it should use plughw anyway. Please reevaluate and if possible at all move this logic to the phonon-vlc backend. - Harald On Feb. 21, 2011, 11:23 a.m., Casian Andrei wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/100700/ > --- > > (Updated Feb. 21, 2011, 11:23 a.m.) > > > Review request for KDE Runtime, Phonon, Phonon Backends, Harald Sitter, and > Trever Fischer. > > > Summary > --- > > Modifications on findVirtualDevices in PhononServer, to make it find usable > capture devices for Phonon-VLC, at least. Phonon audio capture works with the > provided devices. Also made a couple of mostly irelevant improvements. > > The Phonon KDED module was not providing any usable capture devices. Only > some iec958 digital devices showed up, which didn't work at all. VLC needs a > default analog ALSA device, like hw:CARD=SB, in my case. > > Solid is not returning any audio devices on my system. I do not know if it > works properly on other systems, but I will investigate further. > > This is the commit message: > > Phonon KDED module: Improve finding virtual devices from ALSA > > PhononServer was not finding any usable capture devices. It > was skipping almost all useful devices. Commented out the > block for skipping those. > > Prevent devices with empty names when their description > is empty. This should not happen, but it's just in case. > > Eliminate any front, center, rear, surround virtual devices from > capture device candidates. > > Additionaly, there will be only one device with an unique id, with > one or more access descriptors. > > Replace default: with hw: for capture devices, to enable capture > working with Phonon-VLC. > > Because Solid doesn't give me any audio devices, I cannot test for the cases > when it actually works. However, I believe that it doesn't work on most > systems. > > The other iec958 digital stuff devices show up as advanced. > > > Diffs > - > > phonon/kded-module/phononserver.cpp 44f857e > > Diff: http://git.reviewboard.kde.org/r/100700/diff > > > Testing > --- > > Restarted KDED and ran kcmshell4 phonon, viewed the audio devices. All looks > ok. No bogus devices. > > Tested the capture demos from Phonon (currently they have a buggy interface, > will be fixed), and they worked fine. Audio capture works ok with the > Phonon-VLC backend. Audio-video capture also works if you get around the > demo's interface bugs. > > Don't know what happens when Solid actually works for audio devices, if these > changes interfere with Phonon's functionality in that case. > Not tested on other systems to see if any bogus devices appear out of nowhere. > > Amarok still works :P > > > Screenshots > --- > > Capture devices in Phonon config > http://git.reviewboard.kde.org/r/100700/s/79/ > > > Thanks, > > Casian > >
Re: QZeitgeist and Phonon
On Tue, Mar 8, 2011 at 1:50 AM, John Layt wrote:
>> * What is QZeitgeist?
>> A library that neatly wraps the Zeitgeist dbus API with some QObjects.
>
> Has there been a stable release of qzeitgeist yet, or plans to make a stable
> release with a api/abi guarantee? I see it is in Gitorious, any plans to move
> it to KDE infrastructure or kdesupport and the KDE review that would include?
>
>> * Okay, but what is Zeitgeist?
>
> Could you also just touch on why Nepomuk isn't the right tool for this? I'm
> vaguely aware they are seen as complimentary (afaik Zeigeist == when , Nepomuk
> == what), but a reminder for those of us not following the semantic stuff
> would be good. How well do they integrate (if that even makes sense)?
I am sure others are more suited to answer this one.
>> * How does this fit into Phonon?
>
> Just to confirm this is an opt-in setting by the media player itself? I guess
> the players would need to make it very obvious an option in the api as I'm
> sure there's people who would hate for all their fluffy pink unicorn video
> viewing to get logged ;-)
While I fail to see why people would hate for fluffy pink unicorns to
get logged (:P) it is outside the scope of Phonon. However. From a
Phonon API perspective logging is opt-in per mediaobject by setting a
property on it.
IIRC that looks a bit like this:
MediaObject *mo = new MediaObject();
mo->setProperty("_p_LogPlayback", true);
Whether an application graphically exposes the setting to the user or
not is up to the application (keeping in mind that the option might in
fact do nothing depending on whether logging is actually available).
>> 1) It is a new *optional* build-time dependency. If Phonon is compiled with
>> QZeitgeist, but zeitgeist isn't installed, stuff still works. Once
>> zeitgeist is installed, the dbus interfaces work their magic.
>
> So just to confirm the build time dependencies for qzeitgeist itself are
> really only dbus and qt, you don't need Zeitgeist?
Right.
> What's the runtime footprint of zeitgeist itself? It appears to have a heavy
> dependency on python, gnome and gobject (at least that's what the openSUSE
> packages require)? Can it be stripped down to the most basic storage layer
> and api for lighter install and runtime requirements? Does it need yet
> another storage server to be running?
The minimal runtime dependency is python, python-dbus and
python-gobject. Which currently is what needs to be running to provide
the most basic storage layer (python) and api (python-dbus).
About the yet-another-storage-server problem... I guess this mostly
depends on whether Sebastian decides to store the data in nepomuk or
not. Should the data be stored in nepomuk I can imagine that zeitgeist
could just be turned into a request handler and forward the actual
data to nepomuk for storage.
>> 2) The zeitgeist developers (and even the Phonon devs) would absolutely
>> *love* to see more KDE apps use Zeitgeist. Its pretty cool.
>
> Cool indeed, even cooler if its nice and light and we get a KDE front-end for
> it :-)
I guess the KDE front-end comes naturally when nepomuk starts feeding
off zeitgeist data.
regards,
Harald
Re: Re: Future of KSysguard - removing remote monitoring
On Wed, Mar 9, 2011 at 12:55 AM, Alex Fiestas wrote: > Keep this feature as a plugin or something would be awesome, I've used this > feature in the past and it was very helpful. Yeah, surely not one the most important feature but *very* helpful if one stumbles upon a use case :D (actually I am right now using it to monitor the n900 under kubuntu mobile ^^) regards, Harald
Re: Git Feature Branch Naming Policy
On Tuesday 26 April 2011 15:52:18 John Layt wrote: > I'd prefer to see the gsoc branches under a common prefix in the main > project repo rather than as personal branches or repos: > > origin/gsoc2011// > > e.g. in kdelibs.git have "origin/gsoc2011/kdecore/astronomical-calendars" What if a student wishes to have multiple branches (which are of interest to the mentor)? origin/gsoc2011/// comes to mind, which looks rather insanely long :S -- Harald
Re: Help on .desktop files for oxygen
On Thursday 28 April 2011 09:26:52 Hugo Pereira Da Costa wrote: > For 4.7 I'd like to make this advanced tool available via kde' launcher > menu. > Good idea ? Bad idea ? Objections ? Personally I do not think if they are of genuine use, the options should be in SystemSettings; having a second application that manages system settings, even at smaller scope, seems confusing to me. > Also I guess need a .desktop file for that. > Never wrote such a thing before, so some other expert pair of eyes would > help. The values... > X-KDE-ServiceTypes=DBUS/InstantMessenger > X-DBUS-StartupType=Unique > X-DBUS-ServiceName=org.kde.konversation are probably not supposed to be there ;) GenericName and Name ought not be the same... Generic could be something like "Advanced Widget and Window Decoration Settings". Icon probably should be start-here-oxygen. General note about the Settings category: I think in a default setup only SystemSettings is listed in Settings (which will not make it show up in the menu at all), adding another application entry to the Settings category will make it show up in the menu... a menu with 2 entries (of which one is already listed by default in kickoff favorites *and* the kickoff computer tab) seems like bad default appearance to me *shrug* -- Harald
Re: Help on .desktop files for oxygen
On Thursday 28 April 2011 11:54:13 Hugo Pereira Da Costa wrote: > Having all the configuration featurs of oxygen-settings in > systemsettings is simply not an option (it has been discussed at length > among oxygen devs). It does not have to be in the existing KCMs ;) (i.e. see what Ben wrote). All I am saying is, not having a settings UI appear in SystemSettings but in the menu is rather confusing from a user POV. > > Icon probably should be start-here-oxygen. > > mmm. I'm confused. There is no "start-here-oxygen.png" icon in themes, > whereas there is an oxygen.png icon (well, in oxygen theme). But maybe I > should rather ship the icon (and install) with the application ? Oh my bad, I was thinking of start-here.png, which is not suitable. Basically I think there are 2 options here: a) ship your own icon b) use oxygen.png Latter is not very advisable iff you choose to have the app listed in the menu, as the implementation of the menu (think gnome-menu) is responsible for icon lookup, which of course then fails if the used icon set is not oxygen. For a KCM/SystemSettings entry that would be a none-issue as IIRC KIconLoader always tries to look for icons in oxygen as second to last option. So, if your desktop file is only used within a KApplication (such as SystemSettings) you can use any icon from the oxygen set knowing that it will always be displayed, if your desktop file can be used by non-KApps you will need to ship an icon for the application and install it to the hicolor theme. Also see [1]. > > General note about the Settings category: I think in a default setup > > only > > SystemSettings is listed in Settings (which will not make it show up in > > the menu at all), adding another application entry to the Settings > > category will make it show up in the menu... a menu with 2 entries (of > > which one is already listed by default in kickoff favorites *and* the > > kickoff computer tab) seems like bad default appearance to me *shrug* > > Fine with me (and I agree about your concern). > Any better Categories suggestion ? (or alternatively, where do I find > the list of available Categories) ? [3] contains a list of all registred cateogires. [2] is the main spec on desktop files, it points to other relevant specs as needed (which includes [1] and [3] of course ;)). I do still believe that integrating the app to show up within systemsettings rather than the menu would be the way to go though :) [1] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec- latest.html#install_icons [2] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec- latest.html [3] http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category- registry -- Harald
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Mon, Jun 6, 2011 at 10:29 PM, Ben Cooksley wrote: > On Tue, Jun 7, 2011 at 8:06 AM, Aaron J. Seigo wrote: >> On Tuesday, June 7, 2011 06:19:52 Ben Cooksley wrote: >>> The Moratorium would extend to all components of the KDE SC >>> distribution. Hence kde-core-devel. >> >> imho this is impossible, for the reasons Martin noted. >> >>> The components affected by the Moratorium - namely the Kernel, X and >>> ALSA interfaces are not easy to build. For those of us on non-rolling >> >> can you provide an answer to Kevin's initial question, namely: what are the >> actual cases that triggered this concern? e.g. what currently relies on a >> recent kernel, X or alsa? > > I have two examples, Phonon and KWin. > > First Phonon. The Xine backend has now been deprecated, and has. > already broken in applications such as Amarok. The VLC backend gives > me terrible skipping. Apparently upgrading to a newer version of VLC > is needed to use it - but that depends on XCB 1.6. I only have 1.5. > Phonon GStreamer - whilst installable, crashes applications on startup > - and is therefore unusable. This effectively removes the capability > to have multimedia playback using a KDE application. > > I tried (unsuccessfully unfortunately) to backport some of the fixes > which would fix the skipping in Phonon VLC - but that didn't work. I fail to see how this supports the point of having a moratorium, as only ALSA would be affected whereas in the presented cases it would appear that it is more of a user space library issue. regards, Harald
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 8:16 AM, Martin Gräßlin wrote: > On Mon, 13 Jun 2011 16:29:45 -0400, Shaun Reich > wrote: >> >> lightDM is also headed by my dear friend Canonical, as is clearly seen. > > Serious question: does anyone know if it requires Canonical's copyright > assignment to contribute to lightDM? If yes we can stop any further > discussion right here IMHO. robert_ancell: ahoy, is LightDM covered by the canonical contributor agreement? apachelogger, no robert_ancell: ever going to be? apachelogger, no apachelogger, the greeter we develop will be afaik, but the rest of it not > There are of course more issues to think about when considering using > something in our workspace that's developed by Canonical. What about we need > changes Canonical does not like for what reason ever? Who of us can work > with launchpad and bazaar? It's not the environment we are used to work with > (same true for GNOME devs who want to participate in development). Personal > opinion: if Canonical wants other to use it as real cross-desktop, the first > step should be move the code into freedesktop's git repository. Indeed, issues worth considering. I personally believe that "wanting to have something the other party does not" is really a global issue to all of free software. If I want Amarok to be able to remote control my space ship, but the Amarok developers do not, then there is little I can do about that as a non-contributor. Well, except for trying to convince them from the long-term advantage that such a feature would provide. If however I would want Phonon to have such a feature, it is more likely to get accepted as I am contributor to Phonon. I suppose it is a bit of a two class society for every project those-that-do-stuff vs. those-that-don't. While we should keep this in mind, I do not generally think that it is something to base decisions on. From the preemptive fear of not having 100% of control we'd otherwise have to clone every library we use. Well, actually even the OS. Hello KDEOS ;) I agree with your argument that code should be hosted in a FDO git repo, though I personally believe that Launchpad is from a management perspective much easier to use for small projects as it puts every aspect of management into the hands of the project itself (commit access to repos, bug management etc. etc.). So, I can completely understand why one would be using LP even as a freedesktop.org project/thing, even if I find it not sensible at all to do this while using the freedesktop.org website, thus fragmenting one's project *shrug*. But generally speaking I also see this is as a non-issue in terms of the discussion at hand. The hosting system in particular is an implementation detail of forming grounds to collaborate on. Now, to ask anyone to use a ground we are familiar with (vs. one the other party is), we'd first have to know that we want to collaborate. At any rate it probably does not make sense to take such things into account for any technical discussion as long as the system in use is easily accessible. Otherwise all of free software would be using Git, not because it is superior, but simply because everyone else does. regards, Harald
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 12:02 AM, Alex Fiestas wrote: > On Monday, June 13, 2011 10:24:22 PM Thomas Lübking wrote: >> Am Mon, 13 Jun 2011 21:34:56 +0200 >> >> schrieb Martin Gräßlin : >> > What does power management has to do with KDM? This belongs into >> > powerdevil where to my knowledge it should be handled fine, if >> > configured correctly. >> >> I guess he means: >> "autosuspension from KDM", ie. w/o being logged in at all - he >> started the system, didn't log in, talked a lot of meeting nonsense >> (tm), legged in - and the battery was sucked away. >> >> I won't comment on the preferred usage of advanced bioneural cpu to >> circumvent such issues in the first place, but this function does imho >> not belong into a DM but into some cron job (or whatever other daemon) >> that watches how long nobody has been logged in and *whether no relevant >> daemon is running* and then suspend the system after some time. > I don't really know what a DM should and should not do, so yes, a cron job > should do the work just fine. How would one do this using a cron job? :O >> This should also cover plymouth (the splashy replacement? really?) - >> but if you mean "bash", you'll require the feature (watching >> keystrokes) there, i think. >> >> Putting this into a DM is rather bad because there's no good default* >> and it's not a DM's job to watch other processes (while maybe other >> logins...) and manage some random blacklist on them. > I'm not sure what's needed to integrate a DM with plymouth (the splashy > replacement), though I know that KDM without patches doesn't have a smooth > transition. There is a patch from the Fedora team that won't be applied into > KDM because it is crappy (ossi says). IIRC the transition is straight forward. Essentially KDM just takes over the VT from plymouth and quits latter once the X server is up and running. Considering the Fedora patch is inferior, it makes me wonder why there was no superior solution created by those that know better. Are distributions not important enough stake holders of KDM? >> *you do not want to suspend your system because you didn't log in since >> (despite starting to runlevel 5...) there's currently some sshd up and >> you're logged into from somewhere else, or just because the machine runs >> a webserver as well... > The 95% of desktop users doesn't use either sshd or a webserver. So at least > this should be configurable. > > GDM loads the "gnome power management" to solve the issue, what KDM does? > can KDM maybe launch kded with some daemons? You'd still need to provide configuration for this, as the point about running servers still holds. IIf you are running a server of whatever kind on your machine and stay at DM while using it, you do not want to have the machine suspend for lack of interaction, so the simplest solution would be to provide an option in the DM KCM "do-not-break-me-server". As for the logged in on tty cas: If I am not mistaken that is exactly what ConsoleKit is supposed to solve. Every login shell you run should AFAIK result in a seat on ConsoleKit. So, except for the server use case that should cover the greater part of false suspension scenarios. > It may no be perfect but lightDM at least does some handling directly talking > to UPower, though I agree that DM is not the place to fix this issue. Agreed. As Tom pointed out, ideally we'd have a desktop independent daemon to take control over power management. By desktop independent I really mean "eventually cross-desktop" (as in: used in >1 desktop env). This would also allow applications to inhibit suspension (think video player) on every desktop that supports the daemon. Though, this is likely not going to happen any time soon, perhaps even never, so a sensible solution ought to be found. Even if not the most elegant, power management in the DM (or invoked by the DM, i.e. kded with powerdevil) seems like a good enough approach to solve the issue for the majority of desktops users. regards, Harald
Re: KDM plans and lightDM
On Tuesday 14 June 2011 17:42:55 Martin Gräßlin wrote: > On Tuesday 14 June 2011 10:35:49 Harald Sitter wrote: > > On Tue, Jun 14, 2011 at 8:16 AM, Martin Gräßlin wrote: > > > > There are of course more issues to think about when considering > > > using > > > something in our workspace that's developed by Canonical. What about > > > we need changes Canonical does not like for what reason ever? Who > > > of us can work with launchpad and bazaar? It's not the environment > > > we are used to work with (same true for GNOME devs who want to > > > participate in development). Personal opinion: if Canonical wants > > > other to use it as real cross-desktop, the first step should be > > > move the code into freedesktop's git repository. > > > > Indeed, issues worth considering. > > > > I personally believe that "wanting to have something the other party > > does not" is really a global issue to all of free software. If I want > > Amarok to be able to remote control my space ship, but the Amarok > > developers do not, then there is little I can do about that as a > > non-contributor. Well, except for trying to convince them from the > > long-term advantage that such a feature would provide. If however I > > would want Phonon to have such a feature, it is more likely to get > > accepted as I am contributor to Phonon. I suppose it is a bit of a two > > class society for every project those-that-do-stuff vs. > > those-that-don't. While we should keep this in mind, I do not > > generally think that it is something to base decisions on. From the > > preemptive fear of not having 100% of control we'd otherwise have to > > clone every library we use. Well, actually even the OS. Hello KDEOS ;) > > I don't think a comparison with libraries holds. We use libraries to build > applications including the DM. But the DM is part of our workspace > offering. Without a DM we no longer provide a complete workspace > experience. So this is a completely different toppic and cannot be compared > with our policies for libraries and other OS integration. Hm. Yeah. You are right. > To my knowledge this would also be a novelty that we replace a part of our > workspace with a 3rd party application. > > As a workspace developer I consider the possibility to align all our > workspace applications to our needs as very important. Let's just consider > we would want to start into an activity from the DM... My arguments might > seem far*fetched, but from an integrated workspace development point of > view, they aren't (at least IMHO). Agreed. Yet despite having complete control we did not manage to come up with a truly good workspace experience that starts at the DM (power management, good looks, I for one have yet to see a sane UI-wise integration of stuff like fingerprint auth, integration with the workspace like say MS Windows displaying unread mails etc.). So, yes, giving away control is certainly a dangerous thing, and needs to be well throught through and evaluated (if it should happen at all that is). Not just in terms of control but also in terms of feature parity. It certainly would hurt the image of the KDE workspace to switch from a capable, proven, well tested and mature DM to one that does not even measure in terms of features. Let alone reliability. With that in mind it certainly would be a good idea if everyone who threw up rants and whatnot to actually take a look at the status quo and see if lightdm is a viable alternative for antyhing, and if not how to make KDM provide the experience that we need to keep up with our competition. Perhaps we should actually first find out what we need? Regarding the control issue with regards to workspace integration though... Maybe I misunderstood the architecture of LightDM, but to me it seems that all workspace affecting parts would be in the greeter rather than the base of the DM (I figure that is what we have right now in KDM too). What would be "outsourced", if you will, is the actual logic of the DM, which for the better part has little to do with the workspace experience. We would still be in control of all the UI parts, and the DM logic part is certainly not where most of the valuable UI plunder should go (that also includes fancyness enabling technologies such as Plasma). Sure, regarding the actual display management we would be at the mercy of LightDM and its developers, but from a workspace point of view I reckon there is not all that much to be done in the DM logic. > > At any > > rate it probably does not make sense to take such things into account > > for any technical discussion as long as the system in use is easily > > accessible.
Re: KDM plans and lightDM
On Tuesday 14 June 2011 22:19:40 Martin Gräßlin wrote: > On Tuesday 14 June 2011 20:26:45 Harald Sitter wrote: > > > > Agreed. > > > > Yet despite having complete control we did not manage to come up with a > > truly good workspace experience that starts at the DM (power > > management, good looks, I for one have yet to see a sane UI-wise > > integration of stuff like fingerprint auth, integration with the > > workspace like say MS Windows displaying unread mails etc.). > > have these issues been raised in the past? How much on the UI layer is > possible after the Plasma integration? Has anyone tried to work on these > points? I have not the slightest idea. Perhaps we should start that, to the batcave, erm wiki! > Personally I have a completely flicker free boot experience from after GRUB > to desktop is ready to use on my openSUSE systems, so some of the needs are > not present for all and maybe just unknown. https://build.opensuse.org/package/files?package=kdebase4- workspace&project=openSUSE%3AFactory Search for KDM and be surprised. Considering a downstream applies 16 (!!!) patches to KDM, something must be wrong (without having looked at them in detail, supposedly some of them are just distro integration, although those perhaps also might be accomodated better). > And considering how often > especially Canonical changed the splash implementation over the last years, > I'm not surprised we don't run behind the latest idea ;-) Plymouth is also adopted by Fedora :P Considering the patch is like 30 lines or so, I do not think that is a valid excuse though :P > Oh and I consider > Plymouth as legacy as I'm quite sure somone will have the idea to replace > it with a Wayland Compositor (which would make much more sense). Ack. For getting that adopted by downstream Wayland first needed to come around. But yes, ultimately Wayland will eat all our graphics. > > So, yes, giving away control is certainly a dangerous thing, and needs > > to be well throught through and evaluated (if it should happen at all > > that is). Not just in terms of control but also in terms of feature > > parity. It certainly would hurt the image of the KDE workspace to > > switch from a capable, proven, well tested and mature DM to one that > > does not even measure in terms of features. Let alone reliability. > > My motto for Wayland is: DON'T BREAK THE DESKTOP! We should have that on all > such things ;-) +1 > > With that in mind it certainly would be a good idea if everyone who > > threw up rants and whatnot to actually take a look at the status quo > > and see if lightdm is a viable alternative for antyhing, and if not how > > to make KDM provide the experience that we need to keep up with our > > competition. > > > > Perhaps we should actually first find out what we need? > > I think that is the most important one. Look at what is needed. Personally I > guess that most of it will be fixed with the Plasma integration work. Should that ever get finished. Shaun? > Others will have to be evaluated for their actual need. I also think that > it might have been better to do that before suggesting a new DM ;-) Well, I can understand Alex' motivation, the issue he experienced is one that is quite awkard and painful and embarassing. [putting my Kubuntu hat on] Also, just to make one thing clear at UDS the consensus was to carry the entire discussion upstream and see if we can get KDM to become superior awesome. Apparently there is a rumor around that Kubuntu plans on switching to LightDM. That is not true, we are merely evaluating the options and what we can do to improve the pre-login experience. > > Regarding the control issue with regards to workspace integration > > though... Maybe I misunderstood the architecture of LightDM, but to me > > it seems that all workspace affecting parts would be in the greeter > > rather than the base of the DM (I figure that is what we have right now > > in KDM too). What would be "outsourced", if you will, is the actual > > logic of the DM, which for the better part has little to do with the > > workspace experience. We would still be in control of all the UI parts, > > and the DM logic part is certainly not where most of the valuable UI > > plunder should go (that also includes fancyness enabling technologies > > such as Plasma). Sure, regarding the actual display management we would > > be at the mercy of LightDM and its developers, but from a workspace > > point of view I reckon there is not all that much to be done in the DM > > logic. > > Well we don't know and I gave an example with Activity integration in my > last mail. And I could think of more,
Re: KDM plans and lightDM
On Tuesday 14 June 2011 14:55:58 Shaun Reich wrote: > How does lightDM even handle different authentication types? KDM has a > plugin system which handles different auth types (fingerprint, > winbindd, etc.). > > However, the fundamental flaw that I can see..is that at some level or > another, the UI/Greeter *has* to know what type of authentication type > it is. That is why KDM has plugins which wrap around PAM(sort of), so > that the interface can properly accommodate for the changes in auth > type. Note these plugins apply to the screensaver unlock dialog as > well. > > I've been toying with the idea in my head, of using the same Plasma > plugin (actually an applet + dataengine which wraps around a main, > more generic dataengine) in tandem with the Plasma integration with > the screensaver, that is currently present. I think it'd be quite > trivial for me to do this, too -- since I specifically tried to not > make assumptions. > > The plugins exist (both in the plasma frontend and regular kfrontend) > so that when it's in fingerprint mode..it won't show a textbox or any > useless stuff like that, and may additionally show a diagram of some > bloke wiping their finger across. (that's what the kdm plugin does > actually). > > Anyone familiar with the structure in lightDM care to enlighten? I am not sure it does right now. David Edmunson should know. -- Harald
Re: KDM plans and lightDM
On Tuesday 14 June 2011 15:37:25 Shaun Reich wrote: > On Tue, Jun 14, 2011 at 2:58 PM, Harald Sitter wrote: > > Should that ever get finished. Shaun? > > Good question ;-) > Yeah, it's in a pretty finished state, after my unintentional hiatus. > Mostly I've been cleaning stuff up(and yes, I've been actively > committing lately), so that the qml code can look the best. It already > runs plasma and qml and logs in, just have a few more things to do on > it. (kinda refactoring a bit so it doesn't come to bite me later on, > at the moment..) Groovey! > > In particular it is my personal believe that a strong separation between > > DM logic and desktop binding/integration magic is beneficial from a > > structural POV. That way you can easily swap the integration bits > > (QWidgets -> Plasma QGV stuff -> Plasma QML stuff?) around without > > having to poke into the DM stuff at all. > > Well, you see. You have to understand my frustration --> the thing is, > this *already* exists in KDM. And anything that is deemed > unsatisfactory(not everything's perfect, naturally) could easily be > changed of course. I very much understand your frustation. But also as downstream developer (and I count Alex in there too as he is very much aware of the advantages of a downstream POV) I get a lot of input with regards to what is not in the condition it should be to compete with other pre-login experiences. Be it from friends or people at fairs, whenever KDM comes up there are some major annoyances (though to put this into perspective: KDM does not come up as topic that often, which IMHO is still a bad thing as I'd rather have people go "uhh, your login thing is so awesome..."). So, to direct attention to the subject. I think the general scheme was to find out where to go with KDM and whether LightDM would be an option if all else fails. Find out how to make KDM rock the user's experience is primary objective, at least for me. > Everybody talks about it like it's some magical unicorn that hasn't > been spotted before, but the truth is, it's staring everyone in the > face. > > In fact, I have dealt directly with this separation when I've been > working on the Plasma frontend, and based some of it around the > original kfrontend (qwidget) code. So I don't see what the big deal > is, considering I've already worked with this myself... My argument was more in the general direction of moving things that we should not be heavily involved with elsewhere, and I believe that the larger DM logic is such an area. By outsourcing (what a nice word) this part in technology that is used by more than one party we get more exposure to actual production systems, thus more testing and in the end better quality in the long term (not that anything was wrong with the quality of KDM, just saying). Now, I reckon that XDM could, or perhaps should, have been exaclty that, though it did not quite work out. It still seems like a nice enough idea to share generally sharable things. To me, as someone who is not terribly knowledgeable in the area of display managers, it just seems like a waste of resource to have stuff implemented in not all that different ways on different ends (GDM and KDM). Though since there is no plan to have GDM replaced by LightDM on sytems other than Ubuntu this is all a bit moot. Even though I think sharing with part of the ecosystem is still better than no sharing at all. -- Harald
Re: grantlee-0.1.8 build failed on arm7
On Tue, Jun 21, 2011 at 9:20 AM, Rolf Eike Beer wrote: > Sune Vuorela wrote: >> diff --git a/templates/lib/abstractlocalizer.cpp >> b/templates/lib/abstractlocalizer.cpp index 4e5b15d..104d888 100644 >> --- a/templates/lib/abstractlocalizer.cpp >> +++ b/templates/lib/abstractlocalizer.cpp >> @@ -46,8 +46,8 @@ QString AbstractLocalizer::localize( const QVariant& >> variant ) const return localizeDateTime( variant.toDateTime() ); >> else if ( isSafeString( variant ) ) >> return localizeString( getSafeString( variant ).get() ); >> - else if ( variant.type() == QVariant::Double ) >> - return localizeNumber( variant.toDouble() ); >> + else if ( variant.type() == QVariant::Double || >> variant.type()==QMetaType::Float ) >> + return localizeNumber( >> variant.toReal() ); >> else if ( variant.canConvert( QVariant::LongLong ) ) >> return localizeNumber( variant.toInt() ); >> return QString(); > > So if it is a double you are truncating it to a float (on ARM). I don't know > if > that is intentional. qreal on arm is a float, whereas just about on every other platform it is double.
Re: smallish project needed
On Fri, Aug 12, 2011 at 3:26 PM, Mark wrote: > Ah oke. Just some idea i have now.. Right now someone is working on a > Phonon QML thing. SOMEONE? like seriously? :P I guess I need to work on my public image a bit :P
Re: smallish project needed
On Fri, Aug 12, 2011 at 4:09 PM, Stefan Majewsky wrote: > On Fri, Aug 12, 2011 at 3:58 PM, Mark wrote: >>> Dolphin is going in the QML direction? >>> Yes, I think a Juk rewritten in QML could be a good thing. >> >> Well, in that direction.. it's not written in QML or anything.. : >> http://ppenz.blogspot.com/2011/08/introducing-dolphin-20.html > > Of course it depends on the application. QML is not yet at the point > where writing a desktop file manager using it makes sense (see, for > example, tree models). For a media player, though, it can make a lot > of sense. I actually question the usefulness of Qt Quick for a file browser all together. I do not think you'd want to create a complex interface like that with Qt Quick as you'd basically end up implementing half the stuff in C++ anyway. It absolutely and totally makes sense for multimedia apps though, usually their interface is straight forward and needs the additional awesomeness. Just some random thoughts :) regards, Harald
Re: Where is kmix hidden?
On Fri, Aug 19, 2011 at 6:54 PM, Lukas Appelhans wrote: > I guess there were no efforts yet from the kdemultimedia team to make the > move. I did not realize we had to take care of the move seems a bit inconvenient.
Re: QML support in kde.org services
On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky wrote: > 2. api.kde.org doesn't show QML elements. Problem with this is that Doxygen does not support QML (yet anyway), actually I would not know how to make this work in a sane manner considering that plenty of QML elements will be directly based of a CPP object... (in phonon we actually have the documentation in the cpp object which implements the element). So, doing this in a meaningful way would likely require using qdoc for QML element documentation.
Re: KNotify-considerations for frameworks
On Fri, Sep 23, 2011 at 1:01 AM, Sune Vuorela wrote: > Consider doing some classes for Phonon to do audio notifications for > those who needs that or alternatively get a cross desktop audio > notification dbus spec, just like the galago spec and get the workspaces > to implement it. (Issue here might be that Gnome has chosen that one > need to link libcanberra for audio notifications) The latest state of random-exchange-of-thoughts on that matter: http://markmail.org/message/3yysp76oz7zjyr3t?q=kde-multimedia
Re: phonon javascript
On Thu, Feb 9, 2012 at 4:39 AM, Shaun Reich wrote: > anyone know how can i access phonon through javascript? javascript? qtscript you mean? I think you will need http://code.google.com/p/qtscriptgenerator/ for that
Re: Running tests faster..
On Tue, May 15, 2012 at 6:42 PM, David Faure wrote: > On Sunday 13 May 2012 00:04:43 Alexander Neundorf wrote: >> Hi, >> >> just a quick hint, maybe you don't know this yet: >> >> You can run tests using "make test". >> This will run test by test after each other. >> Internally this simply calls ctest. >> >> If you call ctest manually, you can use extra command line options, and, it >> supports -jN, as make does. >> >> So, if you have 4 cores, run >> ctest -j4 >> to have it execute 4 tests in parallel and save time this way. > > Save time... but at the expense of more failures, if the tests aren't ready > for this ;-) > > E.g. in kdelibs I get 3 more failures, due to ksycoca-related tests creating > and removing services that show up in other tests' queries, or other tests > reading and writing from the same shared files. > Any shared resource makes this impossible, but it's interesting to keep in > mind for the design of future unit tests. TBH, a test that depends on another test sounds like a bad test and should be fix. I am certain Kent Beck agrees ;) HS
Re: Proposed adjustments to our release cycles
Ahoy, On Fri, Jun 15, 2012 at 1:05 PM, Sebastian Kügler wrote: > Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and > Applications each with their own release cycles. Each of these releases would > be a set of tarballs of the latest stable versions of the application (or > codebase in more general). Would that not cause management overhead? Having >3 release schedules with >3 freezes of all kinds. If I were a translator working on different parts that would be somewhat ... entertaining. HS
Re: Proposed adjustments to our release cycles
On Sat, Jun 16, 2012 at 1:21 PM, Marco Martin wrote: > On Saturday 16 June 2012, Shaun Reich wrote: >> >> and the freezes would have to be *very* well communicated, because >> even now we run into issues with people not realizing that we're in >> string freeze or feature freeze. > > a part of the plan (kindof a consequency in the long term of the thing > described here) is that it would mean aiming to a state where there are nover > freezes (or well, master is always frozen, depends how you look at ;) > > master should always be in a releasable state, while the feature branches are > merged in an integration one before is well tested. How would one acquire testing on the integration branch? HS
Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)
On Thu, Aug 23, 2012 at 12:27 PM, David Edmundson wrote: > On Wed, Aug 22, 2012 at 11:53 PM, Matthias Klumpp > wrote: >> 2012/8/22 Albert Astals Cid : >>> El Dimecres, 22 d'agost de 2012, a les 13:58:57, David Edmundson va >>> escriure: As you're all probably aware I've been working on a new login manager for KDE [1]. Currently known as LightDM-KDE, named as it is based on the display manager backend LightDM [2]. >>> >>> How's the upstream of ligthdm? Have you worked with them? Do you feel it's >>> an >>> upstream open to our needs? >> Lightdm is NOT a Canonical project, it is developed by Robert Ancell >> and as far as I know there's no CLA to sign. (I haven't contributed to >> the project yet) From the very few moments I spoke to Robert I'd say >> working with him is really nice and there won't be problems. >> Regarding the Canonical-CLA-issue: I also had my bad experiences with >> this, so please, please, never do anything like this in KDE (again)! >> But for LightDM I have no objections, +1 from me for this! > > Anything that I'm proposing putting into KDE workspaces is the code in > KDE playground, it has _nothing_ to do with Canonical or upstream > LightDM, no CLAs, our git servers, our bugtracker, completely ours. > Has been since the start, always will be. This is the KCM and all the > front end code and the only part you'd ever really want to work on. > There's absolutely no > > I think the backend, LightDM, is now a Canonical project. It was > started by an employee in his free time to experiment whilst he > maintained GDM, and it became his day job. However that doesn't make > it bad, it's only the CLA that has a potential to be an issue. > > It is currently _NOT_ listed in the list of CLA covered projects > http://www.canonical.com/contributors. > > Assuming they made it covered, it's worth noting the Canonical CLA has > changed _significantly_ since those high profile "comments" that I > think you're referring to were made. Trolltech also have had a CLA, > and to me they seem pretty similar (though I'm not a lawyer). Even if > it was covered, this only puts it on par with libzeitgeist which is > already being utilized in KDE. In the absolutely worst case ever we > would fork the backend which remains LGPL and ship that. FWIW, last I talked to Robert about Canonical's involvement (which I believe was at UDS in May last year) only the greeters were to be covered by the CLA. HS
Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)
On Wed, Aug 29, 2012 at 2:59 AM, Thomas Lübking wrote: > but I'm willing to > be enlightened about the striking advances of this integration. https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/GuestAccount
Re: Review Request 110330: Make "Prompt on access" kwalletd setting apply in more situations
> On May 7, 2013, 8:15 p.m., Àlex Fiestas wrote: > > I'd like to enable this by default, most people I know from the community > > thinks alike. > > > > Code wise it makes sense. > > Eike Hein wrote: > For clarification: Do you mean enable (= prompt, already the default) or > disable (be silent)? > > Àlex Fiestas wrote: > Silent. > > App identification on wallet are as secure as nothing, so we better have > nothing and with that a better user experience. > > Volker Krause wrote: > Yes, please! +10 - Harald --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110330/#review32224 --- On May 6, 2013, 5:28 p.m., Eike Hein wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110330/ > --- > > (Updated May 6, 2013, 5:28 p.m.) > > > Review request for KDE Runtime and Harald Sitter. > > > Description > --- > > kwalletd has a "Prompt when an application accesses an open wallet" config > option. If this option is enabled (it is by default) any such access attempt > opens a dialog box asking the user to approve or deny the attempt, and > optionally remember the decision for the future. This patch moves the > evaluation of this config option into the codepath taken by any app > authorization check, in effect turning it into a "Prompt when an application > accesses a wallet" setting. > > The purpose is to allow distributions such as Kubuntu and Netrunner which > want to make KWallet mostly invisible during routine operations to disable > this setting by default and so avoid the user being prompted to grant > applications wallet access rights in more situations. (It should be pointed > out that application identity is apparently based on KAboutData information > anyway, and so the security of this system is dubious to begin with.) > > > In the interest of keeping the delta between upstream and downstream as small > as possible I'd say it makes sense to pick this up. > > > This diff is to be applied after the diff in: > https://git.reviewboard.kde.org/r/110328/ > > A patch rewording the checkbox label in kwalletmanager has been posted for > review here: https://git.reviewboard.kde.org/r/110331/ > > > Diffs > - > > kwalletd/kwalletd.cpp fa9fc11 > > Diff: http://git.reviewboard.kde.org/r/110330/diff/ > > > Testing > --- > > Test package for Kubuntu by Harald Sitter, operation verified at runtime. > > > Thanks, > > Eike Hein > >
Phonon4Qt5 & Phonon5 Branches
As you may be aware phonon supports building the phonon4 API against Qt5 by building the phonon4qt5 branch. Due to consolidation efforts at the Phonon sprint last weekend the phonon4qt5 transitional library is now merged into the master branch of both phonon and phonon-vlc (gstreamer blocked on pending gstreamer1 support merge) so the use of the phonon4qt5 branch is discouraged for all uses that do not require a build of phonon4qt5-gstreamer. To build Phonon4 with Qt5 support please use -DPHONON_BUILD_PHONON4QT5=ON. Please note that switching the CMakeCache from libphonon to libphonon4qt5 and vice versa is not supported, so you will need to rm CMakeCache.txt to switch. Once phonon-gstreamer also got the change the phonon4qt5 branches will be deleted and master is the only source for p4q5 builds then. The previous 'five' branch was replaced with a new one that actually constitutes what will become Phonon 5 as discussed last year in Randa. Additionally declarative/graphicsview support is not built by default anymore and building it is discouraged for the time being. HS
Re: Phonon4Qt5 & Phonon5 Branches
On Tue, Jun 4, 2013 at 12:47 AM, David Faure wrote: > On Wednesday 29 May 2013 16:13:23 Harald Sitter wrote: > > As you may be aware phonon supports building the phonon4 API against Qt5 > by > > building the phonon4qt5 branch. > > > > Due to consolidation efforts at the Phonon sprint last weekend the > > phonon4qt5 transitional library is now merged into the master branch of > > both phonon and phonon-vlc (gstreamer blocked on pending gstreamer1 > support > > merge) so the use of the phonon4qt5 branch is discouraged for all uses > that > > do not require a build of phonon4qt5-gstreamer. To build Phonon4 with Qt5 > > support please use -DPHONON_BUILD_PHONON4QT5=ON. Please note that > switching > > the CMakeCache from libphonon to libphonon4qt5 and vice versa is not > > supported, so you will need to rm CMakeCache.txt to switch. > > > > Once phonon-gstreamer also got the change the phonon4qt5 branches will be > > deleted and master is the only source for p4q5 builds then. > > > > The previous 'five' branch was replaced with a new one that actually > > constitutes what will become Phonon 5 as discussed last year in Randa. > > > > Additionally declarative/graphicsview support is not built by default > > anymore and building it is discouraged for the time being. > > Thanks for the note. > I'll update extragear/utils/kdesrc-build/kf5-qt5-build-include > > But apparently phonon-gstreamer doesn't build? > > CMake Warning at cmake/FindPhonon.cmake:9 (find_package): > Could not find a package configuration file provided by "Phonon" with any > of the following names: > > PhononConfig.cmake > phonon-config.cmake > > Add the installation prefix of "Phonon" to CMAKE_PREFIX_PATH or set > "Phonon_DIR" to a directory containing one of the above files. If > "Phonon" > provides a separate development package or SDK, be sure it has been > installed. > Call Stack (most recent call first): > CMakeLists.txt:7 (find_package) Yes, that's what I meant when I said that gstreamer is not yet updated ;) I have just pushed the appropriate changes, so phonon-gstreamer should now also build as expected when passing -DPHONON_BUILD_PHONON4QT5=ON. This now makes all phonon4qt5 branches obsolete and deprecated; they will be removed next week. HS
Re: Re: openSUSE packagers' take on the 3 month release cycle
On Tue, Jul 9, 2013 at 12:38 PM, Martin Gräßlin wrote: > On Tuesday 09 July 2013 06:33:21 Scott Kitterman wrote: >> On Tuesday, July 09, 2013 12:05:30 PM Àlex Fiestas wrote: >> > On Monday 08 July 2013 22:01:29 Andrea Scarpino wrote: >> > > We don't just run a sed rule on each spec (pkgbuild, in my case) file. >> > > We >> > > check for new dependencies (resp. dependencies not needed anymore), new >> > > modules (resp. modules not part of the SC anymore), build failure, >> > > etc... >> > >> > Can't we do something so you don't have to hunt this down but instead just >> > read a list? >> > >> > For build time dependencies, we could do something by looking for >> > find_package, and for runtime dependencies we should figure something out. >> > >> > Our projects are a mess when it comes to runtime dependencies, why don't >> > we >> > fix that for example? >> >> How would a run time only dependency be expressed? I've seen some people >> put them in find_package, which is wrong and then we end up having to patch >> it away. >> >> For build-time dependencies, particularly determining minimum version >> requirements, I end up reading CMakeLists.txt in my favorite editor. That's >> not ideal either. > what about having this information available in a standardized format, e.g. a > dependencies.xml? json is the new xml, so dependencies.json :P while in theory that is a nice idea (just like having a file listing all used licenses/copyright holders/whatever) I do not see such a file getting maintained reliably. certainly not unless cmake dependency tracking/detection is forcefully driven by that file. such that the only way to pull dependencies into a kde enabled cmake project is to use that file and prevent manual find_package calls, which would convenientely make related macros more accessible (macro_optional_find_package/macro_log_feature/etc.). but since that is rather restrictive and people probably wouldn't like it, perhaps the better way to go about this is to enhance cmake. for example have a dummy mode where it doesn't generate any files but simply catches all find_package calls and lists the thusly detected dependencies. that would probably "only' catch some 99% of dependencies; on the plus side it does not require someone to maintain a list of dependencies manually. of course it doesn't help with runtime dependencies but IIRC there was a discussion about how to express their requiredness through cmake anyway (such that a user compiling from source would know to install it and a distro doesn't need to install it for building purposes). if we were to have runtime dependencies expressable through cmake as well we could also list those in the dependency list so that packagers do not forget to add them. with frameworks in particular I suppose we need some approach to express which module can be enhanced by another module at runtime... I guess what I am saying is, instead of having a separate file to track dependencies, why not simply do it in cmake, where we need to check for them anyway (cmake could then generate a json file ;)). HS
Re: openSUSE packagers' take on the 3 month release cycle
On Tue, Jul 9, 2013 at 2:28 PM, Scott Kitterman wrote:
>>Could you please elaborate why the licensing stuff cannot be
>>automatically done?
>
> There I'd a licensecheck script that does this. It helps, but the results
> have to be checked and properly documented and so thete is still substantial
> manual work required. KDE packages are generally better about consistently
> documenting copyright and licensing, but we still find bugs and it's still a
> lot of work.
Mhh, I'd also like to add that the 10% false-positives/not detected
licenses are the ones that cause most headaches. Stuff like...
file.cpp:
> // Yo, BSD here.
> // << BSD boilerplate >>
>
> #include "foo.h"
>
> // This here code be borrowed from gnome-shell and be GPL 2.
> static int meow(void) { return 1; }
> // This be the end of all code borrowed from gnome-shell that be GPL 2.
First you'd need to find that (or hopefully not find it because it's
ewww). If you do however, the question is whether that is even
compatible, and if so, is there a complete copy of the GPL in the
source (as required by the license), ...
If all the cases of license were
<< copyright holders >>
<< license text >>
<< code >>
there would not be any problem. But reality diverges :(
HS
Re: openSUSE packagers' take on the 3 month release cycle
On Tue, Jul 9, 2013 at 2:34 PM, Vishesh Handa wrote: > On Tue, Jul 9, 2013 at 5:58 PM, Scott Kitterman wrote: >> There I'd a licensecheck script that does this. It helps, but the results >> have to be checked and properly documented and so thete is still substantial >> manual work required. KDE packages are generally better about consistently >> documenting copyright and licensing, but we still find bugs and it's still a >> lot of work. > > Can we as KDE developers do something to reduce this work load? We > could create git hooks which reject patches with incompatible > licesnses? Or something like that? > > Once the script has extracted the infromation, do you really need to > check it? Proper documentation can be automatically generated. (Unless > I'm missing something) > > My overall point is that this problem seems more of a technical one > than one related to release schedules. yes, not releated to schedules directly. the problem however is more social than anything. people mostly don't care enough. like not adding a fully copy of the GPL. if you buy some router running Linux you will get with it a printed copy of the GPL. if you download randomsoftware-1.0.tar.gz which is entirely GPL you have a good chance of not finding a full copy anywhere. git hooks certainly would improve the situation. but at the same time it will not solve the underlying issue, so I am reasonable certain that some people's approach to a failed audit on licensing will be to simply replace whatever license was rejected with one that will not get rejected even if doing so actually violates the original license. but as mentioned, the 90% that are easily parsed because they use standard license formatting etc are not really the problem (short of forgetting to include a GPL copy) it's the other 10% of random source copies or whatever. oh and on that note... an audit on full-license-copy-present actually would be nice, so it is harder to forget adding the full license copy ;) HS
Re: gdk_x_error (was: Re: [kile] [Bug 321759] Kile crashes when file is opened from menu)
On Tue, Jul 9, 2013 at 11:30 AM, Boudewijn Rempt wrote: > On Friday 05 July 2013 Jul 15:34:06 Sven Brauch wrote: >> >> 2. GDK installs a deadly X error handler, causing the application to >> >> exit, instead of "just" printing an error message. See multiple >> >> backtraces containing gdk_x_error[3] >> >> There have recently been similar reports for KDevelop, too. > > Phew... It got fixed, apparently: > > https://bugs.launchpad.net/ubuntu/+source/kile/+bug/1195007 FWIW in case anyone ever ends up doing stuff with the qgtkstyle (or gtk directly for that matter), you want to save and restore the error handlers such that the gdk handler does not remain set. like so: x11ErrorHandler qt_x_errhandler = XSetErrorHandler(0); QGtkStylePrivate::gtk_init (NULL, NULL); XSetErrorHandler(qt_x_errhandler); HS
Fwd: looking for phonon gstreamer maintainer
-- Forwarded message -- From: Harald Sitter Date: Mon, Sep 23, 2013 at 4:55 PM Subject: looking for phonon gstreamer maintainer To: "For discussion of multimedia (sound/video) issues under KDE" Ahoy, since everyone who ever was/is/wanted to be Phonon GStreamer maintainer is either busy or has no interest in it, the backend has as of right now no actual maintenance. If anyone wishes to step up and move the backend forward now is the time to do it. I'd like to note that this is not a one-man job though and I am going to continue to be supporting developer. In the unfortunate case that no one is willing enough we will have to look at the possibility of moving the backend out of the support scope, leaving Phonon VLC as the only actively supported backend on all platforms. As immediate result I will likely have to demote the backend's initial preference for the upcoming 4.7.0 release below Phonon VLC's. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 1:24 PM, Aaron J. Seigo wrote: > On Wednesday, September 25, 2013 12:35:25 Harald Sitter wrote: >> since everyone who ever was/is/wanted to be Phonon GStreamer >> maintainer is either busy or has no interest in it, the backend has as >> of right now no actual maintenance. > > you may not get much a reply without some more information: > > * is there some underlying reason why there is no interest in maintaining > Phonon GStreamer? e.g. is there a GStreamer annoyance that needs to be known > about / taken into consideration? I think it's just that one needs to be comfortable working with glib and have the time. Although I guess one could try to start using QtGst which should help with the glib thing a bit ;) Or perhaps everyone got headhunted after putting Linux multimedia on their public CV :O > * what are the real-world ramifications of not having GStreamer support? which > platforms might suffer due to a lack of integration / codec support / etc as a > result? GStreamer only ever was supported on *nix platforms meaning for the better part only Linux distributions would be affected by dropping GStreamer. We do however have VLC support and VLC runs on all platforms, so codec support would not suffer. Integration into the overall Linux based workspace on the other hand could become somewhat less optimal. GStreamer is directly used in various advanced use cases that cannot successfully be covered by abstractions (e.g. QtWebkit, Kamoso, Telepathy) so it is already a hard requirement for most workspace distributions, dropping GStreamer support would essentially mean that everyone will have to have GStreamer and VLC installed to get a complete Plasma workspace experience. Additionally there is a bunch of feature discrepencies between the two backends [1] that for example would make Amarok loose the newly introduced analyzer. At the same time incoming and resolved bug metrics suggest that the current GStreamer backend offers subpar quality (at least compared to the VLC backend) and thus degrades the workspace experience as a whole (it's not terribly entertaining if knotify explodes at login for example). So if it need be we'll have to make the not-optimal situation of VLC (for Phonon) and GStreamer (for other stuff) being both required work as best we can. It certainly beats offering an ever so random crash experience. > * what effort is currently required to support Phonon GStreamer? Is it stable > and needing continued testing and bug fixing maintenance; is it need of more > major surgery; is the big work ahead a port to Qt5 or a change in Phonon? Major surgery: yes. So, right now the backend supports GStreamer 0.10 which is deprected upstream in favor of 1.0, for which there is a branch that is mostly ported but apparently not working with complicated applications such as Amarok. That is probably what needs to be moved forward the most urgently as most distributions are looking to adopt 1.0 sometime soon, and right now Phonon GStreamer essentially forces distributions to also ship an upstream unsupported GStreamer version. Stable: not the word I would use. There are currently 37 bugs that are open/needsinfo of which a rather big chunk seems to be actual crashes (perhaps in GStreamer itself though). Since no one actively triaged them in quite a while it's hard to say how many of those are legit issues caused by Phonon GStreamer. All that being said. I am working on a Phonon5 version of libphonon featuring simplified API which will eventually need porting too, but not any time soon and if anything it also allows simplification of the backend code. So here is what I would do if I had the time and motivation to poke Phonon Gstreamer: a) finish the 1.0 port -> release this is actually a very good way to get used to the code and glib and gstreamer and learn about how phonon backends work b) rewrite the entire thing -> over the course of a couple of releases which greatly helps with getting rid of cruft accumulated over time. c) sip Margaritas while shooting the odd bug that appears once a month with a sniper rifle d) at some point port to phonon5 e) more of c Phonon backends are incredibly low maintenance if written well, except that Phonon GStreamer is not written well (at least in my opinion, and I am very opinionated about what good code looks like, so I may be wrong). Above steps are by the way what I did with Phonon VLC so I'll call it the 'apachelogger method'(tm) and assert it as the only way to make a phonon backend not suck donkey balls. [1] http://community.kde.org/Phonon/FeatureMatrix HS
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 3:38 PM, Daniel Nicoletti wrote: > I have a question: > > I had to write a Qt5 app for playing music/video some > time ago, and I have used QtMultimedia5, so far so good > QtMultimedia seems to provide everything I needed tho > it still uses gstreamer 0.10. AFAIK Phonon was created > due the lack of QtMultimedia, so now that it's there and > it's maintained shouldn't we drop Phonon, or even better > why is Phonon still important? > I googled trying to find their differences but I still have > this questioning... It has the most ludicrous API in all of multimedia. More to the point though Phonon was part of kdelibs4 as such it is needed to retain compatibility. Less so with frameworks5 though. Phonon was created because we did not want to bind kdelibs and core applications to one library we have no control over that then ends up breaking API (as gstreamer did shortly before that 0.9 -> 0.10), or falls apart (as arts did), or dies off (as xine did after it had been the default phonon backend for a while). At the same time there was need for a general purpose multimedia solution for KDE software, so Phonon came to be. Whether qtmultimedia should take that place for qt5 based kde software I do not know. API-wise I certainly wouldn't want to use it. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo wrote: > thanks for the swift and excellent response! muchly appreciated ... > > On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote: >> d) at some point port to phonon5 > > would it at all make sense to see if we can resuscitate this backend by just > going straight to (d)? does it make sense to port the existing code, or would > a start from scratch make sense? Starting from scratch is certainly a viable option. Going straight to d would not solve the problem for Phonon4, or Qt4 for that matter as Phonon5 is supposed to be exclusively Qt5. However from a backend POV there is not going to be a whole lot difference between the two versions as Phonon5's key element is getting rid of pointless API dynamics and through that simplifying the frontend API (like not having a mediagraph where in theory one could order nodes in any order and something reasonable should come out at the end). The heavy lifting code of setting a source, building a pipeline and making it create output should be largely the same. I personally would go for a rewrite but at the same time I am also very confident that starting from the existing code base would yield success. Torrie Fischer already rewrote a lot of the pipeline building and control logic a while ago, so it is most certainly not as bad as it used to be. At the very least there is stuff that can be salvaged for a possible rewrite. > given all the downsides to not having a *good* gstreamer 1.0 backend in your > report, this seems like a pretty important item. particularly for those of us > looking to bring software to mobile devices where having multiple media > middleware is not an awesome solution. There definitely are solid reasons for having a GStreamer backend, otherwise it would have gotten the boot like all the other broken backends years ago. While I had not originally thought of mobile devices, it certainly has even greater importance there. Regardless of the device though it would be a shame to loose the backend, so I really hope someone who enjoys HD videos steps up and volunteers to make software to play them (better) :) HS
Re: Fwd: looking for phonon gstreamer maintainer
On Wed, Sep 25, 2013 at 2:54 PM, Vadim Zhukov wrote: > * One more serious question: how well does this backend copes with (recent > versions of) GStreamer 1.x? It doesn't seeing as there is an unfinished porting branch. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Mon, Sep 30, 2013 at 3:11 AM, Weng Xuetian wrote: > Would it be easier to make phonon-gstreamer to use QtGstreamer and hence > also make someone to maintain QtGstreamer? No. Maintaining two things is more work than maintaining one ;) On top of that there are no real synergies between the two softwares. Yes they both abstract GStreamer, however QtGStreamer really just abstracts the glib/c wiring and replaces it with Qt/cpp wiring whereas Phonon GStreamer entirely abstracts the API. So, Phonon GStreamer could utilize QtGstreamer but all we would get from that is (as a Phonon GStreamer developer) a more convenient API to work with. Other than that it doesn't bring anything to the table as Phonon GStreamer still needed to do what it does now, which is abstracting the API. ^ This is actually why we did not pick up QtGstreamer when it was first released, it would be abstraction stacking without gain. HS P.S. I am a fan of abstracting abstractions regardless :P
Re: Fwd: looking for phonon gstreamer maintainer
On Fri, Oct 4, 2013 at 5:50 PM, Daniel Vrátil wrote: > On Wednesday 25 of September 2013 12:35:25 Harald Sitter wrote: >> -- Forwarded message -- >> From: Harald Sitter >> Date: Mon, Sep 23, 2013 at 4:55 PM >> Subject: looking for phonon gstreamer maintainer >> To: "For discussion of multimedia (sound/video) issues under KDE" >> >> >> >> Ahoy, >> >> since everyone who ever was/is/wanted to be Phonon GStreamer >> maintainer is either busy or has no interest in it, the backend has as >> of right now no actual maintenance. >> >> If anyone wishes to step up and move the backend forward now is the >> time to do it. I'd like to note that this is not a one-man job though >> and I am going to continue to be supporting developer. >> >> In the unfortunate case that no one is willing enough we will have to >> look at the possibility of moving the backend out of the support >> scope, leaving Phonon VLC as the only actively supported backend on >> all platforms. >> >> As immediate result I will likely have to demote the backend's initial >> preference for the upcoming 4.7.0 release below Phonon VLC's. > > Hi, > > in Fedora we have a big interest in keeping phonon-gstreamer alive, namely > because we can't ship phonon-vlc due to legal issues (you know, US company, > software patents and what not...) and our users would not probably be very > happy if we had no phonon working backend in Fedora KDE. > > So far we are happy with gstreamer-0.10, but we realize that sooner or later > we will have to start looking into supporting gstreamer-1.0. Even if we are > able to keep phonon with gstreamer-0.10 alive by patching the hell out of it > in downstream, at some point we will be forced to drop it, and then we would > have nothing to switch to. > > So I'm willing to help keeping phonon-gstreamer alive in upstream (I'm not > saying I'll be able to fix all the bugs) and slowly look into the gst-1.0 > port. > I'm not able to fully maintain yet another project (I already have more than > enough :-)), but as said above, I can contribute to keep it alive and push it > over the hill to gstreamer-1.0 (come on, how hard can it be? ;-)) That's great! Some progress is certainly better than no progress :D If you could hop on #kde-multimedia we can coordinate development etc. > Luckily for me, we have a GStreamer guy in the office, so I can get some help > from him if necessary :) Sebastian Dröge from GStreamer also offered to help, so we definitely have some GStreamer backing. Yay. HS
Re: Fwd: looking for phonon gstreamer maintainer
On Mon, Oct 7, 2013 at 2:36 PM, Jean-Baptiste Kempf wrote: > On 04 Oct, Daniel Vrátil wrote : >> in Fedora we have a big interest in keeping phonon-gstreamer alive, namely >> because we can't ship phonon-vlc due to legal issues (you know, US company, >> software patents and what not...) and our users would not probably be very > > This is a bit untrue, tbh and at the limit of FUD. > > libVLC and libVLCcore are not more patent-encumbered than > gstreamer-core. > > VLC, phonon-VLC and libVLC are based on modules loaded at runtime, like > gstreamer, QT, DShow and other multimedia frameworks (a contrario from > all-included players like mplayer) > Shipping a version without problematic modules is very doable and has > already been done. FWIW rdieter and j-b were able to clear up the confusion on IRC and apparently there now are plans to get vlc-without-patent-plugins into Fedora \o/ For anyone who is interested... libvlc* use $LIB/vlc/plugins/*/*.so to actually get demuxers/decoders/etc. a reasonable amount of containers and codecs (certainly some of the most important ones from a free software distribution's POV) are supported by vlc native implementations without usage of libav/ffmpeg/whatever. Any of the plugins can be dropped, which will naturally reduce feature or format support, but not impair libvlc's functionality at large. So a simple ldd check will tell you which plugins to exclude to get an ffmpeg-free package. ^ This is also how one can get smaller monolithic phonon-vlc binary packages BTW. Tomahawk for example strips a lot of the unused vlc plugins from their windows and osx binaries to reduce the size. HS
Re: Review Request 113242: Make UdevProcessor work with modern udev
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113242/#review41748 --- Ship it! confirmed working with older udev >>> solid-hardware query "Is Processor" udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:07' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:00' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:01' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:02' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:03' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:04' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:05' udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:06' - Harald Sitter On Oct. 14, 2013, 2:59 p.m., Àlex Fiestas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113242/ > ------- > > (Updated Oct. 14, 2013, 2:59 p.m.) > > > Review request for kdelibs, Rohan Garg and Harald Sitter. > > > Repository: kdelibs > > > Description > --- > > Make UdevProcessor work with latest udev by adding cpu subsytem and check if > sysdev exists or not. > > > Diffs > - > > solid/solid/backends/udev/udevmanager.cpp 94eab9d > solid/solid/backends/udev/udevprocessor.h 911bafa > solid/solid/backends/udev/udevprocessor.cpp 882a13d > > Diff: http://git.reviewboard.kde.org/r/113242/diff/ > > > Testing > --- > > > Thanks, > > Àlex Fiestas > >
Re: Adopting AppData in KDE?
On Sat, Nov 2, 2013 at 8:48 PM, Richard Hughes wrote: > On 2 November 2013 19:33, Albert Astals Cid wrote: >> What's the point in having an installer that hides more than half of the apps >> in the world that don't ship a file that is not a standard and doesn't seem >> to >> me it was developed as a standard? How is this useful to the end user? > > We want to showcase high quality applications with active upstream > maintainers. Who's doing the quality review? HS
Review Request 114298: prevent ksplashqml crash when a theme does not exist or cannot be loaded
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114298/ --- Review request for kde-workspace and Ivan Čukić. Repository: kde-workspace Description --- Do not crash when failing to load a theme, but instead exit. When failing to load the theme's qml file QDeclarativeView goes into error state, at which point we want to exit to prevent nullptr access problems. Diffs - ksplash/ksplashqml/SplashApp.cpp 7c528d056ee680f69a6d3d60d1dbeeae9d548846 Diff: http://git.reviewboard.kde.org/r/114298/diff/ Testing --- ksplashqml Foo --test -> sigsev without patch -> exits with patch Thanks, Harald Sitter
Re: Review Request 114298: prevent ksplashqml crash when a theme does not exist or cannot be loaded
> On Dec. 5, 2013, 12:23 a.m., Pino Toscano wrote: > > ksplash/ksplashqml/SplashApp.cpp, lines 148-150 > > <http://git.reviewboard.kde.org/r/114298/diff/1/?file=222537#file222537line148> > > > > What about just calling > > ::exit(2) > > to reach the stdlib function, avoiding the exitNow "wrapper"? So that's how one does that xD Thanks for the tip! - Harald --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114298/#review45154 ------- On Dec. 4, 2013, 1:54 p.m., Harald Sitter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/114298/ > --- > > (Updated Dec. 4, 2013, 1:54 p.m.) > > > Review request for kde-workspace and Ivan Čukić. > > > Repository: kde-workspace > > > Description > --- > > Do not crash when failing to load a theme, but instead exit. > > When failing to load the theme's qml file QDeclarativeView goes into error > state, at which point we want to exit to prevent nullptr access problems. > > > Diffs > - > > ksplash/ksplashqml/SplashApp.cpp 7c528d056ee680f69a6d3d60d1dbeeae9d548846 > > Diff: http://git.reviewboard.kde.org/r/114298/diff/ > > > Testing > --- > > ksplashqml Foo --test > > -> sigsev without patch > -> exits with patch > > > Thanks, > > Harald Sitter > >
Re: Review Request 114298: prevent ksplashqml crash when a theme does not exist or cannot be loaded
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114298/ --- (Updated Dec. 5, 2013, 10:14 a.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and Ivan Čukić. Repository: kde-workspace Description --- Do not crash when failing to load a theme, but instead exit. When failing to load the theme's qml file QDeclarativeView goes into error state, at which point we want to exit to prevent nullptr access problems. Diffs - ksplash/ksplashqml/SplashApp.cpp 7c528d056ee680f69a6d3d60d1dbeeae9d548846 Diff: http://git.reviewboard.kde.org/r/114298/diff/ Testing --- ksplashqml Foo --test -> sigsev without patch -> exits with patch Thanks, Harald Sitter
Review Request 114314: Fix traceback in Python runner plugins
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114314/ --- Review request for kde-workspace and KDE Bindings. Bugs: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1258088 http://bugs.kde.org/show_bug.cgi?id=https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1258088 Repository: kde-workspace Description --- Plamascript.Runner is the base of python krunner plugins. These plugins implement the C++ signals prepare, teardown, createRunOptions and reloadConfiguration in actual methods (the signal wiring happens in pyrunner.py which is the loading component). As a result of this calls to any of these methods will fall through to plasmascript.Runner whenever the actual runner does not implement them. However plasmascript.Runner is missing the implicit 'self' argument such that one gets silly python backtraces like File "/usr/share/kde4/apps/plasma_scriptengine_python/pyrunner.py", line 90, in reloadConfiguration self.pyrunner.reloadConfiguration() To prevent this from happening the functions now have the implicit self argument. Also see: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1258088 CCMAIL: 1258...@bugs.launchpad.net Diffs - plasma/generic/scriptengines/python/plasmascript.py 0ec38eb826cd8b7a052ed47081d05a3b644b03d1 Diff: http://git.reviewboard.kde.org/r/114314/diff/ Testing --- Simple runner plugin only implementing match, run and reloadConfiguration, each is called and no exceptions are thrown WRT attribute errors. from PyKDE4 import plasmascript from PyKDE4.plasma import Plasma from PyKDE4.kdeui import KIcon class KittehRunner(plasmascript.Runner): def match(self, context): print "match" def run(self, context, match): print "run" def reloadConfiguration(self): print "reloadConfig" def CreateRunner(parent): return KittehRunner(parent) Thanks, Harald Sitter
Re: Review Request 114314: Fix traceback in Python runner plugins
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114314/ --- (Updated Dec. 6, 2013, 9:12 a.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and KDE Bindings. Bugs: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1258088 http://bugs.kde.org/show_bug.cgi?id=https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1258088 Repository: kde-workspace Description --- Plamascript.Runner is the base of python krunner plugins. These plugins implement the C++ signals prepare, teardown, createRunOptions and reloadConfiguration in actual methods (the signal wiring happens in pyrunner.py which is the loading component). As a result of this calls to any of these methods will fall through to plasmascript.Runner whenever the actual runner does not implement them. However plasmascript.Runner is missing the implicit 'self' argument such that one gets silly python backtraces like File "/usr/share/kde4/apps/plasma_scriptengine_python/pyrunner.py", line 90, in reloadConfiguration self.pyrunner.reloadConfiguration() To prevent this from happening the functions now have the implicit self argument. Also see: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1258088 CCMAIL: 1258...@bugs.launchpad.net Diffs - plasma/generic/scriptengines/python/plasmascript.py 0ec38eb826cd8b7a052ed47081d05a3b644b03d1 Diff: http://git.reviewboard.kde.org/r/114314/diff/ Testing --- Simple runner plugin only implementing match, run and reloadConfiguration, each is called and no exceptions are thrown WRT attribute errors. from PyKDE4 import plasmascript from PyKDE4.plasma import Plasma from PyKDE4.kdeui import KIcon class KittehRunner(plasmascript.Runner): def match(self, context): print "match" def run(self, context, match): print "run" def reloadConfiguration(self): print "reloadConfig" def CreateRunner(parent): return KittehRunner(parent) Thanks, Harald Sitter
Re: http://techbase.kde.org/Development/Review_Board looks terribly complicated
On Mon, Dec 16, 2013 at 12:29 AM, Albert Astals Cid wrote: > adding a section before all that huge lists of hard > stuff just saying "You can code, do a git diff and upload the diff in the > webpage". oh my god, yes, please! HS
frameworks build instructions wrong / won't work with kubuntu 14.04
Alohas, tldr: in ubuntu 14.04 automoc will (currently does) fall over dead with a qt5 built according to frameworks build instructions. what to do? According to Ubuntu getting cmake to pick up the correct build binaries (outside system paths) via environment variables is not a sane way to do it and a toolchain file should be used instead. This is rendering the present build instructions [1] incompatible with Ubuntu/Kubuntu 14.04 as its cmake will pick up wrong Qt5 tools (moc etc.) and therefore fail to build anything with a Qt build created using the existing instructions. The related IRC discussion is further down. Thoughts on this? What do we do about it? [1] http://community.kde.org/Frameworks/Building from #kubuntu-devel: bug 1262273 bug 1262273 in cmake (Ubuntu) "2.8.12.1-1ubuntu2 broke automoc" [Undecided,New] https://launchpad.net/bugs/1262273 agateau: ^ in case you want to subscribe as well apachelogger: does project neon builds it's own qt5? apachelogger: and is it multiarched like the stock qt5 in ubuntu? apachelogger: cause in my tool chain I set an explicit path to qt5::moc apachelogger: does the cmake package has any patch? apachelogger: is proejct-neon-qt5 multiarched? apachelogger: if it isn't you are really ought to build project-neon-cmake, as cmake package in the distribution has been tailor specifically to the qt5 package as shipped in ubuntu. hm apachelogger: i think there are variables that you can export to make it act more like stock "cmake", i've made sure there is a fallback, but it's rather "opt-out" kind of thing as by default i enabled cross-compilation without modifying all sources. that's a bug -*- apachelogger puts on his kde developer hat apachelogger: what is the full path to "moc" in qt5? as in not the qtchooser one. -*- xnox adjusts my kubuntu-developer badge when working on kde libraries I often want to have my own qt build, this is not working properly on ubuntu :P xnox: /opt/project-neon5/bin/moc http://paste.ubuntu.com/6595065/ -*- xnox points out, that the correct interface, is to explicitely set QT5::moc in that case, in your toolchain file used for custom/prefix installed system libraries, as advised by CMake. apachelogger: you are pointing to the last resort path. in cmake there is Qt5::moc already set to a different location. Oo (as in the code path before that paste) why? -*- apachelogger fails to compute this just now xD apachelogger: because the one generated at qt5 package build-time is always wrong for the cross-compile case on Debian OS. I think the solution is to fix the qt5 cmake config, not hardcode stuff into cmake? apachelogger: thus, it's adjusted to the right one. Which is also, a wild guess, if you don't happen to use stock-cmake with stock-qt5. Both of them are failing to guess it at all times. i can guard my changes better, but your are exploiting implementation details of cmake here. and it's sad to see that project-neon is diverging so much. it's exploiting the fact that cmake is not supposed to hardcode stuff :P apachelogger: wrong. in CMake one should use a Toolchain file for any non-standard locations. Actual modules are, last fallback, not the first look up. apachelogger: if toolchain file sets all variables, none of the Find* foo modules are loaded, nor executed. apachelogger: please start using multiarch qt5 packaging then. I'll put it on my todo cause at the moment one can co-install qt5:i386 and qt5:amd64 which doesn't look possible with project-neon at all. apachelogger: when you'll do that, you will find your automoc broken, fyi ;-) apachelogger: what's your pkg-config? what's your location of .pc files? this should be passed to CMake via Toolchain file! export PKG_CONFIG_PATH := $(NEONDIR)/lib/pkgconfig:$(NEONDIR)/lib/$(DEB_HOST_MULTIARCH)/pkgconfig:$(PKG_CONFIG_PATH) xnox: build foo is here http://bazaar.launchpad.net/~neon/project-neon5/project-neon5-runtime/view/head:/opt/project-neon5/share/pkg-project-neon5/0/default-settings.mk apachelogger: cmake_defaults and all the LD_LIBRARY_PATH, PKG_CONFIG_PATH, QT_PLUGIN_PATH, QML2_IMPORT_PATH, are ought to live in a Toolchain file which is passed to CMake by default. apachelogger: anything else is fragile, and is free to be changed by CMake both upstream and distribution. apachelogger: a Toolchain file is the only contract-based interface to guarantee correct and expected compilation in CMake. xnox: you should probably raise that at kde-buildsys...@kde.org because that is the actuall way they expect things to be done apachelogger: Anybody who uses CMake and does reproducible builds is using Toolchain files (to e.g. enforce compiler versions / editions / pick this or that) it's pretty standard. apachelogger: it's not my problem at all, that project-neon builds chooses to have non-deterministic builds. ok apachelogger: CMake upstream, and Qt upstream, and KDE upstream all support deterministic builds, for a given environment. apachelogger:
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On Wed, Dec 18, 2013 at 6:09 PM, Harald Sitter wrote: > tldr: in ubuntu 14.04 automoc will (currently does) fall over dead > with a qt5 built according to frameworks build instructions. what to > do? xnox was nice enough to look into this in detail and identified the problem as having a much smaller scope than I had originally thought. In particular this should *not* affected non-distro Qt builds that are used in manual builds (i.e. not using dpkg build tools). A solution/improvement for the existing issue is being worked on and should work as expected in the final. HS
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On Thu, Dec 19, 2013 at 2:20 PM, Stephen Kelly wrote: > Harald Sitter wrote: > >> xnox was nice enough to look into this in detail and identified the >> problem as having a much smaller scope than I had originally thought. > > 1) What is the problem? Essentially this change: http://launchpadlibrarian.net/159659245/cmake_2.8.12.1-1ubuntu1_2.8.12.1-1ubuntu2.diff.gz As far as I understand it (which isn't very far) a) it includes ubuntu's MultiArchCross.cmake toolchain all the time for just about every cmake project b) semi-hardcodes qmake/moc/rcc to the system Qt path /usr/lib/$architecturetriplet/... when env DEB_HOST_MULTIARCH is set (which apparently is always the case when building a package on ubuntu) Should be fixed as per: http://launchpadlibrarian.net/160197164/cmake_2.8.12.1-1ubuntu2_2.8.12.1-1ubuntu3.diff.gz > 2) Why does the package creation result in broken cmake files generated from > the Qt tarball? The files (or rather paths set in there) are simply overridden as per the cross compilation stuff described above. Since you want the host architecture tooling (e.g. i386) but the qt cmake config would point to the target tooling (e.g. arm), so it's a matter of incomplete logic of when to force these values as the main env var is set all the time. But I suggest you ask xnox directly about the motivation behind the toolchain file. HS
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On Thu, Dec 19, 2013 at 7:45 PM, Dimitri John Ledkov wrote: > So I was very clueless why > Harald brought up that failing to build from source in his PPA build > to a such a wide audience, when it was entirely unwarranted. And also > in such a hasty manner, minutes after filing the bug in the > distribution without allowing any time for a fix to be written or > uploaded. >From the log I added to the original post: -*- xnox points out, that the correct interface, is to explicitely set QT5::moc in that case, in your toolchain file used for custom/prefix installed system libraries, as advised by CMake. apachelogger: you are pointing to the last resort path. in cmake there is Qt5::moc already set to a different location. [...] apachelogger: cmake_defaults and all the LD_LIBRARY_PATH, PKG_CONFIG_PATH, QT_PLUGIN_PATH, QML2_IMPORT_PATH, are ought to live in a Toolchain file which is passed to CMake by default. apachelogger: anything else is fragile, and is free to be changed by CMake both upstream and distribution. apachelogger: a Toolchain file is the only contract-based interface to guarantee correct and expected compilation in CMake. xnox: you should probably raise that at kde-buildsys...@kde.org because that is the actuall way they expect things to be done apachelogger: Anybody who uses CMake and does reproducible builds is using Toolchain files (to e.g. enforce compiler versions / editions / pick this or that) it's pretty standard. Since neon is basically doing what [1] & kdesrc-build describe, I understood that KDE is abusing CMake in a fragile manner. Since neither abusing nor fragile things are particularly likable I raised the topic here so things can be made !abusing and !fragile. Apparently I communicated that concern badly. [1] http://community.kde.org/Frameworks/Building HS
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On Thu, Dec 19, 2013 at 3:19 PM, Sune Vuorela wrote: > On 2013-12-19, Harald Sitter wrote: >> Should be fixed as per: >> http://launchpadlibrarian.net/160197164/cmake_2.8.12.1-1ubuntu2_2.8.12.1-1ubuntu3.diff.gz > > It looks a bit better, but it is still full of open questions like: Patches are still incomplete as xnox is still prototyping. I suggested that he should subscribe to kde-buildsystem so that I don't have to play middleman here :P HS
Re: Review Request 122403: [OS X] adaptations to phonon component.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122403/#review94639 --- Anyone wanna shipit this? I can't really test, but the code looks fine in general. - Harald Sitter On Feb. 3, 2015, 12:41 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122403/ > --- > > (Updated Feb. 3, 2015, 12:41 p.m.) > > > Review request for KDE Software on Mac OS X, KDE Runtime, Phonon, and Solid. > > > Repository: kde-runtime > > > Description > --- > > I'm trying to make the kcm_phonon Multimedia control panel more useful on OS > X, so that ideally users will be able to choose different devices for the > different playback (or recording) categories. > > This RR outlines the current state of my draft attempt to provide that > support. I'm handicapped by my lack of experience with both IOKit and Solid, > and would thus appreciate a helping hand. > > I'm currently at a stage where Solid returns a list representing the audio > devices present in my system, but apparently not with the correct metadata > for phononserver to consider them: > > ``` > kded(81671)/phonon (kded module) PhononServer::findDevices: Solid offers 5 > audio devices > kded(81671)/phonon (kded module) PhononServer::findDevices: Solid offers 0 > video devices > ... > kded(81671)/phonon (kded module) PhononServer::findDevices: groups: () > kded(81671)/phonon (kded module) PhononServer::findDevices: already found > devices: QSet() > kded(81671)/phonon (kded module) PhononServer::findDevices: Audio Playback > Devices: () > kded(81671)/phonon (kded module) PhononServer::findDevices: Audio Capture > Devices: () > kded(81671)/phonon (kded module) PhononServer::findDevices: Video Capture > Devices: () > kded(81671)/kded4 *Kded::loadModule: Successfully loaded module "phononserver" > ``` > > Companion RR for the (required) changes to kdelibs:solid which is probably > where most of the work will have to be done : > https://git.reviewboard.kde.org/r/122404/ . That RR also has a full output > log showing the available information about my devices. > > > Diffs > - > > phonon/CMakeLists.txt b6ba4ec > phonon/kcm/audiosetup.cpp 835799c > phonon/kded-module/hardwaredatabase e353eea > phonon/kded-module/phononserver.cpp 9a47423 > > Diff: https://git.reviewboard.kde.org/r/122403/diff/ > > > Testing > --- > > On OS X 10.9.5/MacPorts with kdelibs 4.14.4 (git/master), kde4-runtime > (git/master) and kde4-workspace (git/master). > > > Thanks, > > René J.V. Bertin > >
Re: Review Request 125529: switch kde4libs defaults from oxygen to breeze
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125529/ --- (Updated June 1, 2016, 8:44 a.m.) Status -- This change has been discarded. Review request for kdelibs and Jonathan Riddell. Repository: kdelibs Description --- This enables tighter integration with default Plasma 5 appearance in all cases, previously all KDE4 applications would be themed using the Plasma 5 Breeze style through a kconf_update script called kde4breeze. This util writes configs into the user home to make sure KDE4 apps appear breeze themed. Unfortunately this does not work with sudo'd applications as they would use a different HOME and thus use the Oxygen theme by default, making them not fit in with the rest of the default theming. The patch switches the default icon theme as well as widget style from oxygen to breeze. It also adjusts the hardcoded default color values in kcolorscheme from oxygen to breeze (thanks to Kai Uwe Broulik https://git.reviewboard.kde.org/r/124872/) Diffs - kdeui/colors/kcolorscheme.cpp a6650ace52117c4abcfc1893228dc23e3ab6299a kdeui/icons/kicontheme.cpp d9efbb0275e1094c887bb62382d5ddb4135684d7 kdeui/kernel/kstyle.cpp 95a71c24842338fbe6bf5128f6fb76029960b64a Diff: https://git.reviewboard.kde.org/r/125529/diff/ Testing --- Thanks, Harald Sitter
The curious case of stuck systemd poweroff
Hola! ever since systemd and or sddm started not killing all our session processes we have had problems of poweroff/reboot getting hung up waiting for processes to quit. Recently systemd then started sending them TERM by default, which in theory should make things behave as before, but more often than not it doesn't. The reason for this is meh to debug and altogether somewhat convoluted. So all that follows was partially inferred from numerous logging attempts. They all root in a simple fact: ksmserver is rubbish at its job and only terminates half the stuff in the session before handing over to the outside expecting the outside to deal with it. I found two likely holdup scenarios caused by this: a) procfoo is still running -> ksmserver hands over to systemd -> systemd stops sddm -> xserver stops -> procfoo now crashes because it does x-things (pretty sure [1] is an instance of this) -> kcrash jumps in -> drkonqi -> gdb -> procfoo wont react to anything but KILL now b) procfoo is still running -> ksmserver hands over to systemd -> procfoo survives without X (e.g. kio slave) -> procfoo crashes for (maybe unreleated) reasons such as qt bug because network is down -> kcrash gets hung up on recursion crashes handling for kdeinit5 or some other nonesense Long story short: if things crash, usually the TERM from systemd won't do anything. The way I see it ksmserver needs to properly TERM everything to protect against a). Kcrash additionally ought to not do anything when its session is in shutdown to guard against both a) and b) AND allow core dumps to be collected instead so there actually can be a trace of something having gone wong. Thoughts? I have no clue how we'd implement kcrash changes since that would have to somehow know if the session is active without doing business on the heap. For ksmserver we could probably lean on systemd to give a proc list of the session. [1] https://bugs.kde.org/show_bug.cgi?id=364340
Re: The curious case of stuck systemd poweroff
On Thu, Jul 14, 2016 at 3:43 PM, Andreas Hartmetz wrote: > Hello, > > Am Donnerstag, 14. Juli 2016, 11:11:26 CEST schrieb Harald Sitter: >> Hola! >> >> ever since systemd and or sddm started not killing all our session >> processes we have had problems of poweroff/reboot getting hung up >> waiting for processes to quit. >> Recently systemd then started sending them TERM by default, which in >> theory should make things behave as before, but more often than not it >> doesn't. >> >> The reason for this is meh to debug and altogether somewhat >> convoluted. So all that follows was partially inferred from numerous >> logging attempts. >> They all root in a simple fact: ksmserver is rubbish at its job and >> only terminates half the stuff in the session before handing over to >> the outside expecting the outside to deal with it. >> >> I found two likely holdup scenarios caused by this: >> >> a) procfoo is still running -> ksmserver hands over to systemd -> >> systemd stops sddm -> xserver stops -> procfoo now crashes because it >> does x-things (pretty sure [1] is an instance of this) -> kcrash jumps >> in -> drkonqi -> gdb -> procfoo wont react to anything but KILL now >> > Hah, that's a nice one. It should indeed be fixed in kcrash. > >> b) procfoo is still running -> ksmserver hands over to systemd -> >> procfoo survives without X (e.g. kio slave) -> procfoo crashes for >> (maybe unreleated) reasons such as qt bug because network is down -> >> kcrash gets hung up on recursion crashes handling for kdeinit5 or some >> other nonesense >> > It is not even clear that surviving processes need to be killed in case > of logout, which one also needs to consider. See below. > >> Long story short: if things crash, usually the TERM from systemd won't >> do anything. >> >> The way I see it ksmserver needs to properly TERM everything to >> protect against a). Kcrash additionally ought to not do anything when >> its session is in shutdown to guard against both a) and b) AND allow >> core dumps to be collected instead so there actually can be a trace of >> something having gone wong. >> > It is not really ksmserver's job to SIGTERM or even SIGKILL > applications. It implements XSMP which involves asking application > nicely to die. If they didn't, they were killed just fine until systemd > "improved" things. > Not everything participates in XSMP so ksmserver doesn't see all > processes in any case. > What systemd ought to do is: > - when shutting down, kill everything after a short timeout > - when logging out, don't kill anything (think of screen sessions and > such) > > This is a systemd problem. Before systemd it worked as described above > and it was good. > >> Thoughts? >> >> I have no clue how we'd implement kcrash changes since that would have >> to somehow know if the session is active without doing business on >> the heap. For ksmserver we could probably lean on systemd to give a >> proc list of the session. >> > So that would mean adding code on our side and integrating deeper with > systemd to unbreak systemd behavior. I think systemd should do its job > properly and get out of the way. so no useful input then. ok.
Re: The curious case of stuck systemd poweroff
On Thu, Jul 14, 2016 at 8:06 PM, Andreas Hartmetz wrote: > On Donnerstag, 14. Juli 2016 16:19:15 CEST Harald Sitter wrote: >> On Thu, Jul 14, 2016 at 3:43 PM, Andreas Hartmetz > wrote: >> > Hello, >> > >> > Am Donnerstag, 14. Juli 2016, 11:11:26 CEST schrieb Harald Sitter: >> >> Hola! >> >> >> >> ever since systemd and or sddm started not killing all our session >> >> processes we have had problems of poweroff/reboot getting hung up >> >> waiting for processes to quit. >> >> Recently systemd then started sending them TERM by default, which >> >> in >> >> theory should make things behave as before, but more often than not >> >> it doesn't. >> >> >> >> The reason for this is meh to debug and altogether somewhat >> >> convoluted. So all that follows was partially inferred from >> >> numerous >> >> logging attempts. >> >> They all root in a simple fact: ksmserver is rubbish at its job and >> >> only terminates half the stuff in the session before handing over >> >> to >> >> the outside expecting the outside to deal with it. >> >> >> >> I found two likely holdup scenarios caused by this: >> >> >> >> a) procfoo is still running -> ksmserver hands over to systemd -> >> >> systemd stops sddm -> xserver stops -> procfoo now crashes because >> >> it >> >> does x-things (pretty sure [1] is an instance of this) -> kcrash >> >> jumps in -> drkonqi -> gdb -> procfoo wont react to anything but >> >> KILL now> >> > Hah, that's a nice one. It should indeed be fixed in kcrash. >> > >> >> b) procfoo is still running -> ksmserver hands over to systemd -> >> >> procfoo survives without X (e.g. kio slave) -> procfoo crashes for >> >> (maybe unreleated) reasons such as qt bug because network is down >> >> -> >> >> kcrash gets hung up on recursion crashes handling for kdeinit5 or >> >> some other nonesense >> > >> > It is not even clear that surviving processes need to be killed in >> > case of logout, which one also needs to consider. See below. >> > >> >> Long story short: if things crash, usually the TERM from systemd >> >> won't do anything. >> >> >> >> The way I see it ksmserver needs to properly TERM everything to >> >> protect against a). Kcrash additionally ought to not do anything >> >> when >> >> its session is in shutdown to guard against both a) and b) AND >> >> allow >> >> core dumps to be collected instead so there actually can be a trace >> >> of something having gone wong. >> > >> > It is not really ksmserver's job to SIGTERM or even SIGKILL >> > applications. It implements XSMP which involves asking application >> > nicely to die. If they didn't, they were killed just fine until >> > systemd "improved" things. >> > Not everything participates in XSMP so ksmserver doesn't see all >> > processes in any case. >> > What systemd ought to do is: >> > - when shutting down, kill everything after a short timeout >> > - when logging out, don't kill anything (think of screen sessions >> > and >> > >> > such) >> > >> > This is a systemd problem. Before systemd it worked as described >> > above and it was good. >> > >> >> Thoughts? >> >> >> >> I have no clue how we'd implement kcrash changes since that would >> >> have to somehow know if the session is active without doing >> >> business on the heap. For ksmserver we could probably lean on >> >> systemd to give a proc list of the session. >> > >> > So that would mean adding code on our side and integrating deeper >> > with systemd to unbreak systemd behavior. I think systemd should do >> > its job properly and get out of the way. >> >> so no useful input then. ok. > > The hell are you talking about? The action items are: > - Disable kcrash during logout > - File upstream bug in systemd to stop with its ill-advised behavior > whats the bug?
Snappy sprint reporty musing
Hello sweeties! Last week Scarlett, Aleix, Matthias and I took to the Snappy sprint in Heidelberg to discuss how to make it the most useful for KDE. I'd like to give you an overview of what was discussed along with some background, so we are all on the same page. If you already know what Snappy is, you can skip the next paragraph. Snappy is one of them fancy new bundle packages: AppImage, Flatpak, Snappy. Out of those three Flatpak and Snappy are based on Linux Containers/CGroups/Namespace and that whole slew of magic. Simply put they are like docker. AppImage is not using this but seeks to have self-exectuable self-containing LD_LIBRARY_PATH'd programs. Snappy for the most part is 3 things: - a store REST API (of which the reference version is the ubuntu store) - a daemon on the system (snapd, imagine it like dockerd) - a .snap file containing the installed tree of an application (including deps, although that's going to change soon) Generally speaking the store bit isn't technically necessary, it is the primary means of distribution right now though. Shipping things users can use on Linux has been a pain in the rear since forever and these bundles are meant to change that. As such we as KDE should have a strong interest and presence in this field in the hopes of shaping a future that is useful to us. After all, we are one of the biggest source distributors, and the primary reason we don't also offer generic binary packages of our applications is because this never scaled and was altogether terrible to pull off from a KDE point of view. Unfortunately right now we are in a state of limbo with regards to bundles. Everything sort of makes sense but none of them allows us to do large scale building and shipping to users. Which means we need to spread our resources a bit to get good coverage for everything. Not spreading ourselves too thin certainly is a key concern though. With all that in mind, let's take a look at snappy. I think it is best if I don't get into too much detail of how exactly snaps are built or run, but the gist of it is that snaps get "packaged" from highlevel definitions describing what we expect to happen (e.g. cmake should run and then we should have usr/bin/kitten and put that in our snap). If you have seen how Flatpak does it... describing snaps looks very similar. Using fancy kernel tech the snaps at runtime then get isolated from the rest of the (userspace) system allowing them to be fully compatible with any base distribution (in theory anyway). Snappy right now has limited exposure as it is only available on Ubuntu (Unity). This is actively being worked on with main blockers being missing golang stacks (snapd is mostly written in Go), missing apparmor patches (pending upstreaming), and systems that don't use apparmor at all which I guess is the biggest hurdle (needs special kernel configurations). Overall there seems to be interest in having things work well everywhere, which is good of course. Additionally, there's also cool stuff in the works such as adding snap build support in the open build service (OBS). Snaps are generally built on a minimal ubuntu 16.04 core, which is the base they then also get run against. Technically I guess that isn't forced though (same as with Flatpak any old base could be used). This gives us an ever so sweet advantage with Snappy. We already have KDE neon which is based on Ubuntu 16.04! So, Scarlett and I built some high level mass automation of snap building on top of neon's existing deb binaries. Today we have most of the kf5 apps we have in neon also built as snaps for testing purposes. Not all of them work of course, but it's a start. And having them based off of the builds neon does anyway means they are dirt cheap in both developer and build time. Short-term this allows us to test and polish snaps. They are fairly large but that is more because of present snappy deficiencies than anything else (bound to be fixable very very soon). Mid-term I think we should get to a point where we have most of our KDE Applications available as high quality snaps and push them to the Ubuntu store. This store should eventually one supposes be exposed through the software center in Ubuntu (I am sure we can get something ironed out to get discover in Kubuntu also to support it somehow). This will probably require some policy discussion to make sure we only release highest quality snaps as we then have direct end-user exposure. But more on this at later time. The long-term target of course is to not have to base off of debs at all. A key component of this should become available soon in the form of what Snappy calls "content sharing". It's basically a way for us to have a "KF5" snap which gets shared by all apps that wish to use it. A shared library bundle, if you will. This will allow us to cheaply build applications via snappy's build tech and entirely bypass .debs. And also minimize the size of individual application snaps. Also right now building sn
Re: Snappy sprint reporty musing
On Tue, Jul 26, 2016 at 2:07 PM, Sebastian Kügler wrote: > On Tuesday, July 26, 2016 1:08:28 PM CEST Harald Sitter wrote: >> - a store REST API (of which the reference version is the ubuntu store) > > So something like this exists for flatpaks as well, and it's open source? For > snappy, we'd either have to use the ubuntu store (non-free, right?) or write > our own from scratch? > > Could you expand on the distribution mechanism? Right, so, this is actually where the two systems diverge the strongest in philosophy IMO. Flatpak distributes via repositories. Those are for all intents and purposes like any old rpm/deb repo a file tree of stuff the client may or may not want to retrieve. They are very much meant to be distributed. So, we would have a repo, GNOME would have a repo, LibreOffice would have a repo and the user (or her distribution) has to add the relevant repos to their system to gain access to the applications inside. Ultimately I think distros will have to manage a sane default pool of repos or this is going to end in tears ;) Snaps OTOH do not use repos but some "store" which is basically a REST API provider to do ultimately the same as a repo would do, albeit more "webby" as it is actually an API and not just a file tree. That by default doesn't exclude having multiple stores, the snappy team however sounded a lot like they want to keep it central-entity by default. Their point being that the user shouldn't have to go to KDE, GNOME, LO... to get access to their stuff, their stuff should simply be in a central store that would always be enabled. It's basically the equivalent of the Google Play store. The ubuntu store API thingy is apparently free though [1] there also is an example simple implementation [2]. I think the biggest problem here isn't so much the stores concept in and of itself, it's that the current snapd only can use one store at a time, which makes it awkward if a distributor doesn't want to use the Ubuntu store for whatever reason. Arguments can be made for either approach. In the end I hope we'll see a mushed together version. Fully distributed will likely get on people's nerves and at the same time fully centralized will probably raise eyebrows WRT trust and control. [1] https://github.com/snapcore/snapweb [2] https://github.com/noise/snapstore HS
Re: Snappy sprint reporty musing
On Tue, Jul 26, 2016 at 1:08 PM, Harald Sitter wrote: > Snappy right now has limited exposure as it is only available on > Ubuntu (Unity). This is actively being worked on with main blockers > being missing golang stacks (snapd is mostly written in Go), missing > apparmor patches (pending upstreaming), and systems that don't use > apparmor at all which I guess is the biggest hurdle (needs special > kernel configurations). Overall there seems to be interest in having > things work well everywhere, which is good of course. Additionally, > there's also cool stuff in the works such as adding snap build support > in the open build service (OBS). Since there is some confusion over this: Right now you can already install snapd on the big distros, and you can probably use snaps just fine. The problem is that sometimes those builds are unofficial (i.e. not from the main repositories) and they require kernels with suitable apparmor patches to make confinement actually work, so you potentially need untrusted/unsigned kernels to make this fly as well as on Ubuntu. This is rapidly improving however. For testing purposes you should be fine as long as you install snaps with `snap install --devmode yolo.snap` as that will mostly behave like a glorified container (do not that on some distros might actually need their security module disabled e.g selinux on fedora). For actual production use it's kinda meh still. HS
Re: Can't release applications
On Wed, Jul 27, 2016 at 12:27 PM, Luigi Toscano wrote: > On Wednesday, 27 July 2016 12:22:45 CEST Aleix Pol wrote: >> Hi, >> There's a major blocker when trying to release applications nowadays. >> To update the stable branch one needs to commit to the >> kde:sysadmin/repo-metadata.git repository, which can't be accessed by >> KDE Project maintainers. >> >> How can we solve this? > > When you release, don't you file sysadmin tickets anyway for uploading the > files and other steps? Metadata changes ought to happen before upload though. change stable branch in metadata ⬇ l10n freeze ⬇ tarball creation ⬇ upload & ticket ⬇ release HS
Re: What's kde-core-devel for?
On Thu, Dec 15, 2016 at 10:18 PM, Albert Astals Cid wrote: > In the old days it had kdelibs development discussion but not that that has > moved over to kde-frameworks-devel, waht's kde-core-devel for? *cough* http://markmail.org/thread/opcvfo5h7elrvqdl Everyone kinda agrees that there's one list too many between kde-core-devel and kde-frameworks-devel. Someone needs to file a sysadmin ticket and that person gets to decide whether kde-core-devel gets killed in favor of kde-frameworks-devel (and kde-devel) or vice versa. Discussing this is nothing but a bikeshed waste of time. kde-core-devel is an overly generic name. It being generic makes it an attractive dumping ground for just about anything that seems even remotely relevant to more than one development team, which is weird as there's probably lots of devs that aren't even subbed here (anymore). The way I see it kde-frameworks-devel has a specific discussion topic, kde-core-devel does not. It may have in principle at some point been about kdelibs but those days are long gone, probably in no small part due to its naming. kde-core-devel should be done away with, sending all kdelibs relevant topics to kde-frameworks since the knowledgeable people hang out there. General development discussion should happen on kde-devel as is already happening anyway. Release discussion should happen on release-team. If any topics are then left out in the cold we can open a new list kde-devel-community for random stuff that the developer community wishes to discuss. (FTR: this list gets konqueror reviews. very core :-/) HS
Re: Elisa is in kdereview
On Wed, Jun 21, 2017 at 11:15 PM, Matthieu Gallien wrote: > Hello, > On mercredi 21 juin 2017 23:01:23 CEST Albert Astals Cid wrote: >> El divendres, 16 de juny de 2017, a les 22:44:03 CEST, Matthieu Gallien va >> >> escriure: >> > Hello, >> > >> > Elisa is now in kdereview and aiming for extragear/multimedia. >> > >> > It is a music player from a design from Andrew Lake. >> > It is using Qt multimedia for playback and a few KDE frameworks. Its UI is >> > using Qml. >> > >> > Its aim is to be simple to use and hopefully in the future powerfull when >> > needed. >> > >> > It should be usable without needing online services but will use them in >> > the future. >> > >> > A few integration bits are missing with respect to Baloo before I can do a >> > release. Currently music can only be read if in its database that can be >> > filled by Baloo or a custom file indexer if Baloo is not there. >> >> That's kind of a weird design decision, basically i started elisa, it didn't >> see any of my music, i didn't find a way to add it, so i removed elisa. > > It is not a design decision but the current state. I want to also support the > "let's play this file now" use case. I just had not yet enough time to do it. > > I am also planning to add a "busy" indicator to show that Elisa is currently > getting tracks from Baloo or default music directory (as per QStandardPaths). > If no music is found, I also want to add a passive notification offering the > possibility to configure the path to use to search music. I even have a task > in > phabricator for that. > >> That'd be my workflow as a regular user. > > I am already convinced that first impression is important. At the same time, I > did request to move to extragear to get covered by CI and to get feedback from > kde-core-devel. I think it's fine. Not perfect, but good enough for starters. The error case handling could definitely be better (no baloo database, indexing in progress, baloo disabled, baloo broken, no music in database). User experience quirks aside, Elisa seems to be in really good shape. Builds. Plays music. I18n seems to be in order as well. HS
Re: http://commitfilter.kde.org/ ?
See http://markmail.org/thread/hekkp2rcdvir732q http://markmail.org/thread/b6neyhjak2h4g2yd On Sun, Oct 29, 2017 at 9:47 PM, Martin Koller wrote: > Should http://commitfilter.kde.org/ still exist ? > Currently I get "unknown host" > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > >
Re: Kdiff3 release.
this should help https://community.kde.org/ReleasingSoftware On Thu, Aug 2, 2018 at 9:25 AM Michael Reeves wrote: > > That's what I'm looking at doing. The translation need some minor updating. > In particular the docs were changed to correct some obsolete information > regarding windows and preprocessor command handling. > > On Tue, Jul 31, 2018, 5:26 AM Luigi Toscano wrote: >> >> Michael Reeves ha scritto: >> > What would be next step in getting a release setup fir kdiff3? Do we >> > have >> > documentation on the process? >> > >> >> Right now kdiff3 is logically placed in a group called historically >> "playground". The idea is: kick start the program, start few *unstable* >> releases, ask for a community review (see "kdereview") and then allow the >> program to have stable releases, either with its own cycle or as part of >> another "product". >> >> The workflow is described here: >> https://community.kde.org/Policies/Application_Lifecycle >> >> kdiff3 is a bit weird as it could have used the Incubator process and go >> directly to kdereview, but that's not too relevant now. >> >> You may want to release a first unstable release, then ask for a community >> review, or ask for a review first and then be moved to the relevant place and >> have stable releases. >> >> Ciao >> -- >> Luigi
Re: KDE's release script not functional on stable openSUSE
2.1 reached EOL almost 2 years ago. I suggest you ruby-build or rvm a newer version isolated from your system's. On Thu, Jan 24, 2019 at 11:29 AM Jaroslaw Staniek wrote: > > Hi Jonathan, > The releaseme tools require ruby 2.3 while openSUSE 42.3 depends on 2.1. And > it lacks multiple ruby version support (no RVM). > After forcibly switching to ruby 2.3 or 2.4 openSUSE stops being functional > because yast (core admin tool) depends on ruby 2.1. > Releaseme worked *great* but I had to roll back to 2.1, making the OS again > not capable to develop KDE software releases I work on. Advice welcome. > Maybe you know a way for isolated ruby installation or other workaround. > Maybe it would be best if such requirements were better suited for typical > capabilities. > Logs blow: > > releaseme/tarme.rb --version 3.1.91 --origin stable --from-config kdb > ..releaseme/lib/releaseme/requirement_checker.rb:116:in `check': Not all > requirements met. (RuntimeError) > from /home/jarek/dev/src/releaseme/lib/releaseme/requirements.rb:3:in > `' > from /home/jarek/dev/src/releaseme/lib/releaseme/logable.rb:28:in > `require_relative' > from /home/jarek/dev/src/releaseme/lib/releaseme/logable.rb:28:in ` (required)>' > from /home/jarek/dev/src/releaseme/lib/releaseme/cmakeeditor.rb:24:in > `require_relative' > from /home/jarek/dev/src/releaseme/lib/releaseme/cmakeeditor.rb:24:in > `' > from /home/jarek/dev/src/releaseme/lib/releaseme.rb:22:in > `require_relative' > from /home/jarek/dev/src/releaseme/lib/releaseme.rb:22:in ` (required)>' > from /home/jarek/dev/src/releaseme/tarme.rb:25:in `require_relative' > from /home/jarek/dev/src/releaseme/tarme.rb:25:in `' > - Ruby 2.3.0 or 2.4.0 or 2.5.0 or 2.6.0 required. > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - kde.org > KEXI: > : A visual database apps builder - kexi-project.org calligra.org/kexi > twitter.com/kexi_project facebook.com/kexi.project t.me/kexi_project > Qt Certified Specialist: > : linkedin.com/in/jstaniek
Re: CI system maintainability
On Thu, Mar 28, 2019 at 3:57 PM David Jarvie wrote: > I agree. Mandatory reviews might work if there is a team of active people > working on a project, but if there is only one person with real knowledge of > the code We do have common ownership of code, so if there is only one person with real knowledge of the code that is a problem in of itself... A problem which really should get solved... For example by having mandatory reviews so someone actually has to review code they know just as little about as everyone else, so in turn they now know a bit more and can more confidently do reviews ;) Now to be sure, I am not certain mandatory reviews are in fact the answer to the problem at hand, nor if they would in fact be possible to implement reliable. From personal experience I'll say that reviews almost always are worth it, even for the simple typo fixes. And I also almost find someone to give at least a casual review even when they know nothing of the code base. Sometimes perhaps even "I couldn't say if this change is good, but the code looks correct at least +1" is better than nobody having looked at the code at all. It ultimately also becomes a matter of busfactor. If nobody ever has reason to look at code with a single principal author the busfactor will never improve. HS
binary compatibility and qwidget::event
Hey our binary compatibility page [1] states that one should "reimplement event in QObject-derived classes, even if the body for the function is just calling the base class' implementation." Does anyone know the reason this helps maintain BC? [1] https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B HS
Re: binary compatibility and qwidget::event
But why was that BIC to begin with? Which of the "don'ts" did it violate? On Fri, Jul 12, 2019 at 11:18 AM Kai Uwe Broulik wrote: > > To avoid situations like [1] and [2] > > [1] > https://cgit.kde.org/kiconthemes.git/commit/?id=1e9af6c54470e890597739f8f2189b0743a00b6f > [2] > https://cgit.kde.org/kiconthemes.git/commit/?id=083bb8a80fd5941e6fcbaf1ec12a08d8f8c881a5 > > Am 12.07.19 um 11:14 schrieb Harald Sitter: > > Hey > > > > our binary compatibility page [1] states that one should > > > > "reimplement event in QObject-derived classes, even if the body for > > the function is just calling the base class' implementation." > > > > Does anyone know the reason this helps maintain BC? > > > > [1] > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B > > > > HS > > > > >
Re: binary compatibility and qwidget::event
That makes sense. Thanks all! :) On Fri, Jul 12, 2019 at 1:09 PM Volker Krause wrote: > > On Friday, 12 July 2019 11:24:35 CEST Harald Sitter wrote: > > But why was that BIC to begin with? Which of the "don'ts" did it violate? > > IIUC re-implementing a virtual method from a base class (in absence of > complications like multi-inheritance or co-variant return types) does not > change the ABI (it changes vtable content, but not vtable layout). > > It does however create cases where old binaries still call the old methods > (see https://community.kde.org/Policies/ > Binary_Compatibility_Issues_With_C%2B%2B#Adding_a_reimplemented_virtual_function). > That might not always be a relevant problem though. > > In my understanding this is the same for the final -> !final case discussed in > #plasma in this context. It does not impact the ABI at all (it does not even > change vtable content), but some optimizations in old binaries might no longer > reflect the new behavior. > > Regards, > Volker > > > On Fri, Jul 12, 2019 at 11:18 AM Kai Uwe Broulik > wrote: > > > To avoid situations like [1] and [2] > > > > > > [1] > > > https://cgit.kde.org/kiconthemes.git/commit/?id=1e9af6c54470e890597739f8f2 > > > 189b0743a00b6f [2] > > > https://cgit.kde.org/kiconthemes.git/commit/?id=083bb8a80fd5941e6fcbaf1ec1 > > > 2a08d8f8c881a5> > > > Am 12.07.19 um 11:14 schrieb Harald Sitter: > > > > Hey > > > > > > > > our binary compatibility page [1] states that one should > > > > > > > > "reimplement event in QObject-derived classes, even if the body for > > > > the function is just calling the base class' implementation." > > > > > > > > Does anyone know the reason this helps maintain BC? > > > > > > > > [1] > > > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2 > > > > B%2B > > > > > > > > HS >
Re: Possible to move some KF5 frameworks to invent?
On Mon, Aug 12, 2019 at 12:23 AM David Faure wrote: > > On dimanche 11 août 2019 22:14:19 CEST Albert Astals Cid wrote: > > without having your own fork of a repository, that is annoying for various > > reasons > > If creating a fork can be scripted, then that could be a fallback solution > (to the problem of "committing everywhere" like some of us do). https://docs.gitlab.com/ce/api/projects.html#fork-project there are gitlab CLIs in various languages which I expect already implement this in an easy to use fashion HS
Re: Possible to move some KF5 frameworks to invent?
On Tue, Aug 13, 2019 at 12:54 PM Ben Cooksley wrote: > > On Mon, Aug 12, 2019 at 11:48 PM David Faure wrote: > > > > On lundi 12 août 2019 13:04:29 CEST Ben Cooksley wrote: > > > On Mon, Aug 12, 2019 at 10:54 PM Albert Vaca Cintora > > > > > > wrote: > > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley wrote: > > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora > > > >> > > > >> wrote: > > > >> > Could we use sysadmin/repo-metadata to know which branch is stable > > > >> > and > > > >> > therefore should be protected and trigger the hooks for closing bugs, > > > >> > etc?>> > > > >> Unfortunately that only tells us what the current stable branch is - > > > >> it doesn't let us know what the other (either historical or up and > > > >> coming) stable branches are called. > > > > > > > > Maybe that is enough? IMO, it makes sense to not consider a bug is > > > > closed > > > > until the commit that fixes it has been merged to either master or the > > > > current stable branch. > > > > > > Unfortunately not, as both future and past stable branches have been > > > used in the past by distributions as a source of patches for those > > > maintaining LTS releases. > > > > > > Additionally, these branches are authoritative as to what we > > > previously released > > > > That's what tags are for, not branches. > > > > > and are needed in the event we need to make > > > another release of these branches. > > > > Right. But this only happens with recent stable branches, not > > really old stuff like "enterprise3". > > > > In any case, we should be able to make a list of stable branches, > > especially if we can use wildcards like Applications/*. > > Unfortunately the problem isn't with Frameworks, Applications and > Plasma - they're easy to handle and their naming can be scripted > without too much trouble. > The problem lies with Extragear, which has a large number of projects, > all of which have different rules for what a stable branch is named. As Albert said, the solution would be to establish a common scheme for protected branches. > For these, someone ends up with having to maintain and update that > list as needed. > > Maintaining this list would also be complicated because our hooks have > no idea whether Gitlab considers a branch protected or not - so either > our hooks handle whether force pushes are allowed or not, or we end up > duplicating the knowledge in two places. These are very solvable problems, even with a random-name schemes. We know which branches are/were used as trunk/stable and could have an automated system keeping tracking. We can also determine/manage which branches are marked protected on the gitlab side via the API. HS
rekonq to unmaintained
I'd like to suggest moving rekonq to unmaintained Its master branch is still kdelibs4, the frameworks branch hasn't seen any progress in 21 months. Hasn't had a release in years. Very unmaintained all in all. Any objections? HS
Re: rekonq to unmaintained
now unmaintained https://commits.kde.org/sysadmin/repo-metadata/67d487fe1262c65cbef2fdc0c10e80ad14fc22fc On Thu, Sep 12, 2019 at 3:45 PM Harald Sitter wrote: > > I'd like to suggest moving rekonq to unmaintained > > Its master branch is still kdelibs4, the frameworks branch hasn't seen > any progress in 21 months. Hasn't had a release in years. Very > unmaintained all in all. > > Any objections? > > HS
