Re: What can we expect from our developers

[Jonathan Riddell]

My opinion is that KDE project maintainers should aspire to get the
projects into the hands of users in a way which makes it a useful tool for
the user.  That means ensuring the projects are packaged and distributed
and updated.  That's a big ask of course especially from volunteers but it
would be the same of self hosted open source projects on Github or
commercial proprietary projects, the difference is we have a community
process where if you aren't sure how to achieve something there is probably
other people who can help out.  When I first took over Umbrello 20 years
ago I was surprised that as well as learning C++ and Qt I'd also need to
know some artwork and how to make it translatable and follow UI design.
Actually making it available to users through app stores is another ask for
sure but it's why I'd like that integrated into processes like the KDE Gear
release service so projects can offload some of the work.  There seems to
be minimal interest in this though which I worry keeps KDE projects back.

Jonathan

Re: Ready-to-use Docker images for KF6-based development ?

[Jonathan Riddell]

*Sure, the Neon unstable one should be ready to go*
*invent-registry.kde.org/neon/docker-images/plasma:unstable
*

*You can try Distrobox to give it a go in a more managed way *
https://community.kde.org/Neon/Containers

Or manually something like
docker run -ti --volume="$HOME/.Xauthority:/root/.Xauthority:rw"
--network=host -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=:0
--security-opt seccomp=unconfined
invent-registry.kde.org/neon/docker-images/plasma:unstable bash



On Mon, 29 Jan 2024 at 21:18, Alexander Neundorf  wrote:

> Hi,
>
> I'm still running a Qt5/KF5-based setup on my machine.
> Is there a ready-to-use docker image/Dockerfile which I could use to work
> on a
> KF6-based application, maybe something from KDE neon ?
>
> Sorry for the maybe stupid question
> Alex
>
>
>
>

Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino

[Jonathan Riddell]

On Sat, 27 Jan 2024 at 17:26, Friedrich W. H. Kossebau 
wrote:

> [ ] App packages in Flatpak, Snap, AppImages and Windows etc as appropriate
>
> Not involved with any of those packages/platforms, but I assume that
> checkbox
> is rather some kind of "nice to have", not blocking the process actually?
>

This sort of comment  makes me really sad. The All About the Apps goal,
which in principle is still ongoing, was an attempt to get KDE developers
to realise it was important not just to write apps but to actually make
them available to users, I find it astonishing how we still don't have a
culture where making our apps available to users is part of our
responsibility.  There's teams in KDE to help with all these formats.
Sorry to complain here as the issue is larger than just this one app but
it's so sad that nobody within KDE wants to help get users using our
software directly.

Jonathan

Re: PokiPoki in KDEReview

[Jonathan Riddell]

Do you have any intention to follow up on this Carson?

Jonathan


On Tue, 4 Jul 2023 at 13:52, Jonathan Riddell  wrote:

> I created an issue for this in line with the new kdereview process
>
> https://invent.kde.org/libraries/pokipoki/-/issues/1
>
> Jonathan
>
>
> On Wed, 26 Aug 2020 at 20:28, Carson Black  wrote:
>
>> Hi y'all!
>>
>> I'd like to see PokiPoki go through KDEReview and eventually end up
>> releasing as an extragear library.
>>
>> PokiPoki is a framework that aims to make persistent objects as
>> trivial to use as possible and provides other sugar functionality on
>> top of simply persisting objects, such as an undo/redo stack.
>>
>> From a code overview, PokiPoki is split into two main parts:
>> libpokipoki and pokic. libpokipoki is a small helper library that
>> provides types used by pokic while pokic is a code generator that
>> consumes .pokipoki files to generate a header-only library that can be
>> included in a project.
>>
>> libpokipoki is authored in C++ for obvious reasons, while pokic is
>> authored in Go due to the extensive text templating system used for
>> code generation and the lexer in the stdlib used for reading pokipoki
>> files.
>>
>> poki-compiler/parser/output.go will probably be the file that needs
>> most looking at, as it's responsible for the code generation.
>>
>> Cheers,
>> -- Carson Black
>>
>

Re: RKWard is in kdereview - again

[Jonathan Riddell]

I've created an issue for the kdereview process

https://invent.kde.org/education/rkward/-/issues/23

Jonathan


On Sat, 26 Mar 2022 at 20:34, Thomas Friedrichsmeier <
thomas.friedrichsme...@kdemail.net> wrote:

> Hi!
>
> KDE.org has been our home for a 7.5(!) years, now (after over a
> decade on sourceforge), but we still haven't left playground... After a
> lot of procrastination on that matter, a previous review failed due to
> lack of time on my part. Sorry! Now, finally, I'd like to ask you to
> start reviewing RKWard for inclusion into exragear / education, once
> more.
>
> RKWard is an easy to use and easily extensible IDE/GUI for R (a
> powerful language and environment for statistical computing, if you
> did not know it, yet). It aims to combine the power of the
> R-language with the ease of use of commercial statistics tools.
>
> RKWard is used productively on Linux/BSD, Mac, and Windows.
>
>
>
> Here's a summary of the critical comments we got in the previous round
> of review (https://marc.info/?l=kde-core-devel=153883367600690=2):
>
> Albert Astals Cid remarked
> (https://marc.info/?l=kde-core-devel=153912336114603=2):
>
> > the i18n folder seems like from the past and something you should not
> > need if in kde infrastructure. Could you delete it?
>
> We cannot easily get rid of this, entirely, as we are shipping
> (non-compiled) plugins that keep their message catalogs in relative
> paths, and thus we have to install .mo files to custom locations. Pino
> Toscano has helped to bring this more in line with standard KDE.org
> processes (https://invent.kde.org/education/rkward/-/merge_requests/2).
>
> > Also I'd suggest you compile enabling
> > -DECM_ENABLE_SANITIZERS="address;undefined"
>
> Thanks for the hint, did not know that switch. One effect of this is a
> lot of false positive "runtime errors", when casting a half-destroyed
> QObject* to its original (derived) type, in order to remove it from
> containers (e.g. a QHash of KActionCollection()s). Is there an elegant
> way around this?
>
> > There's a few memory leaks (reported at exit) that you may want to
> > have a look.
>
> I fixed a lot of that, but didn't work out all of them.
>
> > And there's also a few undefined behaviour warnings on exit, you've
> > them marked as "known" things but it'd be good if you could find a way
> > to fix them.
>
> Not quite sure what you were referring to, esp. what I may have marked
> as known behavior. I did fix several quirks at exit since this comment
> (and I keep introducing new ones, all the time).
>
> > Your help menu is for some reason missing the Change Language option,
> > i tried to do it a quick fix but could not, i would appreciate if you
> > could find a way to only define the extra actions and not all of them
> > (like we do for example in okular).
>
> I've added the switch application language option (in Settings rather
> than Help). Our help menu is perhaps more customized than meets the eye
> on first glance. For instance, we have an app-integrated help system
> instead of external handbook (at least as the primary documentation),
> and our bug report dialog is beefed up to include a lot of extra
> information by default (mostly importantly: version of R). I guess it
> would be possible to hack KHelpMenu this way, but at least at some
> point in the past it seemed cleaner to implement "from scratch" (but
> using the default actions, where applicable).
>
>
>
> Comments by Jonathan Riddel
> (https://marc.info/?l=kde-core-devel=153916691226377=2):
>
> > It installs two desktop files which creates duplicate menu entries
> > /usr/share/applications/org.kde.rkward-open.desktop
> > /usr/share/applications/org.kde.rkward.desktop
>
> Completed following suggestions by Thomas Baumgart and Meik Michalke:
> https://marc.info/?l=kde-core-devel=153942961310071=2
>
> > The .desktop files call it a "GUI for R" which is not a great
> > description, everything in the menu is a GUI.  I recommend "R
> > Statistical Programming" or "IDE for R" maybe.
>
> Renamed to Statistics with R, following Meik's suggestion
> (https://marc.info/?l=kde-core-devel=153942595709279=2).
>
> > I tidied up the files with the icon licence as they could easily be
> > lost.
>
> Done by Jonathan.
>
> > It depends on WebKit which is not supported, could this be ported to
> > WebEngine?
>
> Meanwhile, RKWard can be compiled to use QtWebEngine (and this is the
> default), but support for webkit has not been dropped, because MinGW is
> an important platform for us.
>
> > It's uncommon having debian/ packaging directly in the source and
> > there's also debian-official/ which could get confusing and
> > out-of-sync and messy.  I recommend moving them to another archive.
> > Storing the packaging in KDE neon Git would be cool as we already
> > have packaging for all the rest of KDE software.
>
> Meanwhile packaging has been taken over by the debian-qt-kde team
> (thank you so much!). Jonathan himself added RKWard to neon. We still
> 

Re: PokiPoki in KDEReview

[Jonathan Riddell]

I created an issue for this in line with the new kdereview process

https://invent.kde.org/libraries/pokipoki/-/issues/1

Jonathan


On Wed, 26 Aug 2020 at 20:28, Carson Black  wrote:

> Hi y'all!
>
> I'd like to see PokiPoki go through KDEReview and eventually end up
> releasing as an extragear library.
>
> PokiPoki is a framework that aims to make persistent objects as
> trivial to use as possible and provides other sugar functionality on
> top of simply persisting objects, such as an undo/redo stack.
>
> From a code overview, PokiPoki is split into two main parts:
> libpokipoki and pokic. libpokipoki is a small helper library that
> provides types used by pokic while pokic is a code generator that
> consumes .pokipoki files to generate a header-only library that can be
> included in a project.
>
> libpokipoki is authored in C++ for obvious reasons, while pokic is
> authored in Go due to the extensive text templating system used for
> code generation and the lexer in the stdlib used for reading pokipoki
> files.
>
> poki-compiler/parser/output.go will probably be the file that needs
> most looking at, as it's responsible for the code generation.
>
> Cheers,
> -- Carson Black
>

Re: KCGroups in KDEreview

[Jonathan Riddell]

I opened an issue in line with the new kdereview process

https://invent.kde.org/libraries/kcgroups/-/issues/1

Jonathan


On Sat, 21 Nov 2020 at 00:38, Albert Astals Cid  wrote:

> El divendres, 20 de novembre de 2020, a les 14:55:16 CET, Henri Chain va
> escriure:
> > Hello everyone,
> >
> > KCgroups has been moved to KDEReview !
> > What is that, you ask ? It's a library that wraps the systemd dbus API
> to
> > expose a higher-level concept of desktop application and allow control
> of its
> > system resource usage (CPU, RAM, IO, etc).
> >
> > It relies on the recent ability of plasma to launch applications in
> their own
> > systemd scopes, with correspond to cgroups and provides a more robust
> > definition for an application (more details at
> https://lwn.net/Articles/834329/
> > ) .
> >
> > The main use of the library is to expose related resource control
> settings for
> > those applications, at a user space level that other KDE applications
> and
> > frameworks can use, including consumption straight from QML as
> demonstrated in
> > the test application.
> >
> > KCgroups is intended to become a (Tier 1) framework. A first user of
> this
> > library might be the foreground window CPU booster daemon that is
> available
> > here:
> https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
> >
> > Packages are already available for both Neon and Arch Linux.
> >
> > Looking forward to your feedback and ideas for using this,
>
> I'm a bit scared about your optional class being there all in the main
> namespace. I'd suggest putting in some "namespace kcgroups{}" or name it
> kcgoptional or something.
>
> you have a few properties without NOTIFY, ideally you should either add it
> if they can change or mark them as CONSTANT if they can't.
>
> Cheers,
>   Albert
>
>
> > Henri
> >
> >
> >
>
>
>
>
>

Re: KQuickChatComponents in kdereview

[Jonathan Riddell]

I opened an issue in line with the new kdereview process
https://invent.kde.org/libraries/kquickchatcomponents/-/issues/1

Jonathan


On Fri, 31 Dec 2021 at 11:35, Janet Blackquill  wrote:

> Hi,
>
> KQuickChatComponents
> (https://invent.kde.org/libraries/kquickchatcomponents) is in
> kdereview now.
>
> It is a very small (as of now) library mostly containing a base bubble
> component offering a consistent bubble design, with a few variants
> built on top of the bubble offering common patterns of chat things
> with bubble backgrounds and layouts. Besides the timestamp component,
> that's pretty much it, since chat apps need to diverge heavily to
> accomodate their protocols. This library's purpose is mostly for
> getting KDE's plethora of QtQuick chat apps to converge on one (1)
> bubble design instead of a different look per app, as well as other
> details like the selection of shortcuts used for common chat app
> actions (see MR !2)
>
> -- Janet
>

Re: kpeoplevcard in kdereview

[Jonathan Riddell]

I opened an issue in line with the new kdereview process

https://invent.kde.org/pim/kpeoplevcard/-/issues/1

Jonathan


On Sat, 12 Jun 2021 at 14:56, Nicolas Fella  wrote:

> Hi,
>
> https://invent.kde.org/pim/kpeoplevcard is now in kdereview.
>
> kpeoplevcard is a data source plugin for KPeople that provides contacts
> based on VCard files on the disk. The 0.1 release has been in use in
> plasma-phonebook and kdeconnect-sms for a while, but I just realized it
> was never properly reviewed.
>
> I did some cleanup work to bring the repo up to standards, but in
> general the thing is rather "finished". There is a pending MR adding
> full REUSE compliance waiting for approval from the copyright holders.
>
> Cheers
>
> Nico
>
>

Re: Eloquens now on KDEREVIEW

[Jonathan Riddell]

I opened an issue in line with the new process
https://invent.kde.org/sdk/eloquens/-/issues/1

Jonathan


On Mon, 20 Jun 2022 at 21:30, Felipe Kinoshita  wrote:

> For those who don't know, Eloquens is a simple application targeted at
> developers/designers, it generates the lorem ipsum text and allows you to
> customize it a little bit like adding heading, bullet lists, etc...
>
> I would also like to ask if it would be possible for it to be released
> along with KDE Gear.
>
> Thanks,
> Felipe
>

Re: KSvg in kdereview

[Jonathan Riddell]

I opened an issue in line with the new process

https://invent.kde.org/frameworks/ksvg/-/issues/2

Jonathan


On Thu, 20 Apr 2023 at 09:26, Marco Martin  wrote:

> Hi all,
> A part of plasma-framewrok, which is the one to do SVG-based themes,
> has now been splitted in a standalone library which is intended to be
> a new framework in KF6 (all usages of the plasma-framework version
> will be ported once this officially lands, and then those classes will
> be removed)
> The repo for now lives in
> https://invent.kde.org/libraries/plasmasvg
>
> In the end it will be renamed in ksvg
>
> Comments? reviews?
>
>
> --
> Marco Martin
>

Re: XWayland Video Bridge in kdereview

[Jonathan Riddell]

I opened an issue in line with the new process

https://invent.kde.org/system/xwaylandvideobridge/-/issues/2



On Fri, 16 Jun 2023 at 17:44, Aleix Pol  wrote:

> Hi Everyone,
> As discussed by david in his blog post [1], we worked on the component
> in question to solve the problem of X11 applications that want to use
> the screencasting services on Wayland.
>
> https://invent.kde.org/system/xwaylandvideobridge
>
> While there's some corners to polish here and there, it's ready to be
> used by everyone who needs it. In fact, people are using it from the
> flatpak and distros want to ship it so we should probably make it
> easier and regulated through a proper release.
>
> First it should go through kdereview, then I'd suggest starting to
> release it with Plasma 5.27 in one of the minor releases. I don't
> think it's something we have done before but it doesn't add new
> dependencies and it has an impact in our product offering which is,
> incidentally, frozen due to the switch to *6.
>
> I would appreciate the review of the module, I guess the "how to
> release it" is something we can discuss in a couple of weeks once this
> is sorted.
>
> Thanks everyone!
> Aleix
>
> [1] https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/
>

Re: Move Licentia to KDEREVIEW

[Jonathan Riddell]

I opened an Issue in line with the new practice
https://invent.kde.org/sdk/licentia/-/issues/2


On Tue, 8 Nov 2022 at 02:14, Felipe Kinoshita  wrote:

> Yes, I'm still interested in working on them, just lost motivation because
> it was taking too long for someone to review it.
>
> On Thu, Nov 3, 2022, 09:44 Jonathan Riddell  wrote:
>
>> Same question on this one Felipe, are you still interested in working on
>> the app?  It seems stuck in kdereview with no recent development.
>>
>> Jonathan
>>
>>
>> On Fri, 8 Jul 2022 at 06:37, Felipe Kinoshita  wrote:
>>
>>> Hey, I'd like to move Licentia <https://invent.kde.org/sdk/licentia> to
>>> KDEREVIEW.
>>>
>>> Licentia is a simple app targeted at developers/creators who need to
>>> decide which license is suited to their projects, Licentia helps with that
>>> by listing a bunch of licenses, which with it's permissions, conditions and
>>> limitations, instructions about how to add a license to your project and a
>>> list of known projects that use said license.
>>>
>>> Thanks,
>>> Felipe.
>>>
>>

Re: Proposal for using gitlab for kdereview process

[Jonathan Riddell]

I've gone ahead an updated the Sanity checklist and updated the kde review
policy to ask people to make an Issue on gitlab labelled "KDE Review
Request"

https://community.kde.org/Policies/Application_Lifecycle#kdereview

So you can now find kdereview requests at
https://invent.kde.org/dashboard/issues?sort=created_date=opened_name[]=KDE+Review+Request

Which is linked from
https://community.kde.org/Policies/Application_Lifecycle#kdereview

I'll open Issues for outstanding kdereview projects.

Jonathan



On Mon, 19 Jun 2023 at 19:55, Jonathan Riddell  wrote:

> Seems using issues is more intuitive so I'll ask for a global group label
> for issues and update the process docs for kdereview and incubator.
>
> Incubator suggestion is here
> https://discuss.kde.org/t/proposal-kde-invent-based-incubator-process/
>
> Jonathan
>
>
> On Wed, 1 Mar 2023 at 08:27, David Redondo  wrote:
>
>> So there are two new kdereview requests using gitlab issues now instead
>> of my
>> more complicated idea of merge requests. I imagined a MR to have
>> advantages
>> for codereview but an issue seems to be less complicated (no need to have
>> an
>> empty orphan branch, etc..), so maybe we should go with that.
>>
>> David
>>
>>
>>

Re: XWayland Video Bridge in kdereview

[Jonathan Riddell]

I got this compiling on neon unstable.  Our kpipewire is qt6 so I'm not
sure how that affects it.  I don't have a way to test it quickly though.
https://build.neon.kde.org/job/jammy_unstable_neon-packaging_xwaylandvideobridge/

How come it's in the system group on invent if you want it to be part of
Plasma?

Jonathan



On Fri, 16 Jun 2023 at 17:44, Aleix Pol  wrote:

> Hi Everyone,
> As discussed by david in his blog post [1], we worked on the component
> in question to solve the problem of X11 applications that want to use
> the screencasting services on Wayland.
>
> https://invent.kde.org/system/xwaylandvideobridge
>
> While there's some corners to polish here and there, it's ready to be
> used by everyone who needs it. In fact, people are using it from the
> flatpak and distros want to ship it so we should probably make it
> easier and regulated through a proper release.
>
> First it should go through kdereview, then I'd suggest starting to
> release it with Plasma 5.27 in one of the minor releases. I don't
> think it's something we have done before but it doesn't add new
> dependencies and it has an impact in our product offering which is,
> incidentally, frozen due to the switch to *6.
>
> I would appreciate the review of the module, I guess the "how to
> release it" is something we can discuss in a couple of weeks once this
> is sorted.
>
> Thanks everyone!
> Aleix
>
> [1] https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/
>

Re: Proposal for using gitlab for kdereview process

[Jonathan Riddell]

Seems using issues is more intuitive so I'll ask for a global group label
for issues and update the process docs for kdereview and incubator.

Incubator suggestion is here
https://discuss.kde.org/t/proposal-kde-invent-based-incubator-process/

Jonathan


On Wed, 1 Mar 2023 at 08:27, David Redondo  wrote:

> So there are two new kdereview requests using gitlab issues now instead of
> my
> more complicated idea of merge requests. I imagined a MR to have
> advantages
> for codereview but an issue seems to be less complicated (no need to have
> an
> empty orphan branch, etc..), so maybe we should go with that.
>
> David
>
>
>

Re: XWayland Video Bridge in kdereview

[Jonathan Riddell]

I don't want to add it to the Plasma release for a bugfix version.  But
I'll happily release it alongside it.

Jonathan


On Mon, 19 Jun 2023 at 09:48, Sandro Knauß  wrote:

> Hey,
>
> > First it should go through kdereview, then I'd suggest starting to
> > release it with Plasma 5.27 in one of the minor releases. I don't
> > think it's something we have done before but it doesn't add new
> > dependencies and it has an impact in our product offering which is,
> > incidentally, frozen due to the switch to *6.
>
> With my Debian hat on: Please make sure nothing depend on this new
> application
> for 5.27.
> Background: We successfully could convinced the Debian release team, that
> it
> is safe to ship new minor Plasma releases to Debian stable with the result
> shipping 5.27.5 in bookworm (released some days ago). The main reason was
> that
> the minor releases are only bugfix releases and no new features are added.
> If you do not break this rule, that we can ship the minor releases to
> bookworm
> (without XWayland Video Bridge, as no new applications are allowed).
>
> Regards,
>
> hefee
>
>
>

Re: KDE Review: Arianna

[Jonathan Riddell]

The epub.js is not in preferred modifiable form.  It's cleartext but it's
not the source as anyone would want to edit it.  The comment at the end
says it comes from a mapping called sourceMappingURL=epub.js.map so the
full source of this should be included.

Jonathan


On Sat, 25 Feb 2023 at 13:59, Carl Schwan  wrote:
>
> Hi folks,
>
> I want to move Arianna to KDE review. Arianna is an ebook reader
> currently only supporting epubs. This is based on top of epub.js
> and QtWebEngine for the actualy rendering of ebooks as doing that
> from scratch in Qt would be too much work.
>
> The repo can be found here: https://invent.kde.org/graphics/arianna/
>
> I create a gitlab issue to track the progress of this:
> https://invent.kde.org/graphics/arianna/-/issues/1 Please free to add
> your comments as recently suggested in this mailing list.
>
> Cheers,
> Carl

Re: Re : New repo in kdereview: PlasmaTube

[Jonathan Riddell]

Oh yes now I remember it needs a new version of the fork yt-dlp, give that
it works fine.

So might be worth adding a compile time and/or runtime check for the right
version there.

Jonathan


On Mon, 27 Feb 2023 at 13:14, Jonathan Riddell  wrote:

> When I compile this and play a video I get an error suggesting youtube-dl
> isn't happy.  I'm using youtube-dl from Ubuntu which is versioned
> 2021.12.17-1 and looking at the
> https://ytdl-org.github.io/youtube-dl/download.html site that is the
> latest version
>
>
> Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
> kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed
> qrc:/videoplayer/VideoControls.qml:243:5: QML Dialog: Binding loop
> detected for property "implicitHeight"
> qrc:/videoplayer/VideoControls.qml:243:5: QML Dialog: Binding loop
> detected for property "implicitHeight"
> qrc:/components/Sidebar.qml:9:1: QML Sidebar: Binding loop detected for
> property "contentHeight"
> qrc:/videoplayer/VideoControls.qml:122: ReferenceError: UserPlaylistModel
> is not defined
> qrc:/videoplayer/VideoControls.qml:193: ReferenceError: UserPlaylistModel
> is not defined
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
> QML MouseArea: Binding loop detected for property "implicitHeight"
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
> QML MouseArea: Binding loop detected for property "implicitHeight"
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9:
> QML ListView: Binding loop detected for property "topMargin"
> Cannot load libcuda.so.1
> qrc:/videoplayer/VideoPlayer.qml:172:25: QML Image: Error decoding:
> https://inv.riverside.rocks/feed/popular: Unsupported image format
> qrc:/videoplayer/VideoControls.qml:193: ReferenceError: UserPlaylistModel
> is not defined
> qrc:/videoplayer/VideoControls.qml:122: ReferenceError: UserPlaylistModel
> is not defined
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
> QML MouseArea: Binding loop detected for property "implicitHeight"
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
> QML MouseArea: Binding loop detected for property "implicitHeight"
> [ytdl_hook] ERROR: [youtube] Y0H1l3XnEr8: Unable to extract uploader id;
> please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= ,
> filling out the appropriate issue template. Confirm you are on the latest
> version using
> yt-dlp -U
> [ytdl_hook] youtube-dl failed: unexpected error occurred
> No protocol handler found to open URL ytdl://Y0H1l3XnEr8
> The protocol is either unsupported, or was disabled at compile-time.
> [ytdl_hook] ERROR: [youtube] Y0H1l3XnEr8: Unable to extract uploader id;
> please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= ,
> filling out the appropriate issue template. Confirm you are on the latest
> version using
> yt-dlp -U
> [ytdl_hook] youtube-dl failed: unexpected error occurred
>
>
>
> On Fri, 24 Feb 2023 at 15:05, Carl Schwan  wrote:
>
>> Le samedi 4 février 2023 à 7:14 PM, Devin  a écrit :
>>
>> > Hi everyone,
>> >
>> > I would like to put PlasmaTube through kdereview:
>> >
>> > https://invent.kde.org/multimedia/plasmatube
>> >
>> > PlasmaTube is a YouTube client for both mobile and desktop.
>>
>> It has already been almost 3 weeks since Devin put plasmatube in
>> kdereview.
>> Does anyone have more feedback for Plasmatube? Any last objections before
>> moving it out of kde review? :p
>>
>> Cheers,
>> Carl
>> >
>> > Thanks,
>> > Devin
>>
>

Re: Re : New repo in kdereview: PlasmaTube

[Jonathan Riddell]

When I compile this and play a video I get an error suggesting youtube-dl
isn't happy.  I'm using youtube-dl from Ubuntu which is versioned
2021.12.17-1 and looking at the
https://ytdl-org.github.io/youtube-dl/download.html site that is the latest
version


Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed
qrc:/videoplayer/VideoControls.qml:243:5: QML Dialog: Binding loop detected
for property "implicitHeight"
qrc:/videoplayer/VideoControls.qml:243:5: QML Dialog: Binding loop detected
for property "implicitHeight"
qrc:/components/Sidebar.qml:9:1: QML Sidebar: Binding loop detected for
property "contentHeight"
qrc:/videoplayer/VideoControls.qml:122: ReferenceError: UserPlaylistModel
is not defined
qrc:/videoplayer/VideoControls.qml:193: ReferenceError: UserPlaylistModel
is not defined
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
QML MouseArea: Binding loop detected for property "implicitHeight"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
QML MouseArea: Binding loop detected for property "implicitHeight"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9:
QML ListView: Binding loop detected for property "topMargin"
Cannot load libcuda.so.1
qrc:/videoplayer/VideoPlayer.qml:172:25: QML Image: Error decoding:
https://inv.riverside.rocks/feed/popular: Unsupported image format
qrc:/videoplayer/VideoControls.qml:193: ReferenceError: UserPlaylistModel
is not defined
qrc:/videoplayer/VideoControls.qml:122: ReferenceError: UserPlaylistModel
is not defined
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
QML MouseArea: Binding loop detected for property "implicitHeight"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
QML MouseArea: Binding loop detected for property "implicitHeight"
[ytdl_hook] ERROR: [youtube] Y0H1l3XnEr8: Unable to extract uploader id;
please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= ,
filling out the appropriate issue template. Confirm you are on the latest
version using
yt-dlp -U
[ytdl_hook] youtube-dl failed: unexpected error occurred
No protocol handler found to open URL ytdl://Y0H1l3XnEr8
The protocol is either unsupported, or was disabled at compile-time.
[ytdl_hook] ERROR: [youtube] Y0H1l3XnEr8: Unable to extract uploader id;
please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= ,
filling out the appropriate issue template. Confirm you are on the latest
version using
yt-dlp -U
[ytdl_hook] youtube-dl failed: unexpected error occurred



On Fri, 24 Feb 2023 at 15:05, Carl Schwan  wrote:

> Le samedi 4 février 2023 à 7:14 PM, Devin  a écrit :
>
> > Hi everyone,
> >
> > I would like to put PlasmaTube through kdereview:
> >
> > https://invent.kde.org/multimedia/plasmatube
> >
> > PlasmaTube is a YouTube client for both mobile and desktop.
>
> It has already been almost 3 weeks since Devin put plasmatube in kdereview.
> Does anyone have more feedback for Plasmatube? Any last objections before
> moving it out of kde review? :p
>
> Cheers,
> Carl
> >
> > Thanks,
> > Devin
>

Re: Move Licentia to KDEREVIEW

[Jonathan Riddell]

Same question on this one Felipe, are you still interested in working on
the app?  It seems stuck in kdereview with no recent development.

Jonathan


On Fri, 8 Jul 2022 at 06:37, Felipe Kinoshita  wrote:

> Hey, I'd like to move Licentia  to
> KDEREVIEW.
>
> Licentia is a simple app targeted at developers/creators who need to
> decide which license is suited to their projects, Licentia helps with that
> by listing a bunch of licenses, which with it's permissions, conditions and
> limitations, instructions about how to add a license to your project and a
> list of known projects that use said license.
>
> Thanks,
> Felipe.
>

Re: Eloquens now on KDEREVIEW)

[Jonathan Riddell]

Hi Felipe, there doesn't seem to have been any movement on this for some
months, are you still interested in working on it?  If it's a useful app it
can be added to KDE gear to get releases done for example.

Jonathan


On Sat, 3 Sept 2022 at 10:40, Tomaz Canabrava  wrote:

> Hello All,
>
> All discussion was resolved by Felipe in the past few weeks,
> I Assume this is done, and should be moved out of KDE Review?
>
> Best.
>
>
> On Tue, Jun 28, 2022 at 4:54 PM Felipe Kinoshita 
> wrote:
>
>> friendly ping! :)
>>
>> On Wed, Jun 22, 2022 at 5:44 PM Felipe Kinoshita 
>> wrote:
>> >
>> > > Ah! I would suggest moving the conversion into the Controller then. As
>> > > far as kcfg, your Config object and your Settings.qml are concerned
>> > > they can be proper bools, it's only in the Controller that you have
>> > > the presentation requirement that bools must be 0/1. This saves you
>> > > the two-way conversion, in the Controller you only need to convert
>> > > bool=>int and the rest of the app can treat them as proper bools.
>> >
>> > Indeed, this makes much more sense.
>> >
>> > Fixed it now!
>> >
>> > Thanks,
>> > Felipe
>> >
>> > On Wed, Jun 22, 2022 at 10:10 AM Harald Sitter  wrote:
>> > >
>> > > On Wed, Jun 22, 2022 at 12:07 AM Felipe Kinoshita 
>> wrote:
>> > > >
>> > > > > Could you elaborate why your config.kcfg uses Ints for everything
>> when
>> > > > > you clearly want booleans (e.g. `Config.code == 1 ? true : false`)
>> > > >
>> > > > The API expects ones and zeros for its params, I chose to convert
>> them to
>> > > > booleans to make the API call easier to write and change.
>> > >
>> > > Ah! I would suggest moving the conversion into the Controller then. As
>> > > far as kcfg, your Config object and your Settings.qml are concerned
>> > > they can be proper bools, it's only in the Controller that you have
>> > > the presentation requirement that bools must be 0/1. This saves you
>> > > the two-way conversion, in the Controller you only need to convert
>> > > bool=>int and the rest of the app can treat them as proper bools.
>> > >
>> > > HS
>>
>

Re: Aura Browser in KDE Review

[Jonathan Riddell]

This is missing an Appstream file and the licencing isn't clear, it should
get SPDX licences.

Jonathan


On Fri, 26 Aug 2022 at 11:27, Aditya Mehra  wrote:

> Hi,
>
> Aura Browser is in KDE Review and would like to release it along with
> Plasma Bigscreen
>
> Aura browser is a web browser specifically designed to work with remote
> controls and key navigation for Plasma Bigscreen, it supports a virtual
> mouse cursor and multiple tabs it also includes a third party AdBlock from
> brave browser based on easy list.
>
> You can find the repository here:
> https://invent.kde.org/plasma-bigscreen/aura-browser
>
> Request to please review Aura Browser.
>
> Regards,
> Aditya
>

Re: Croutons in kdereview

[Jonathan Riddell]

Looks good, I've now packaged this for KDE neon unstable edition

https://build.neon.kde.org/view/3%20unstable%20%E2%98%A3%20git%20master/job/focal_unstable_neon-packaging_croutons/

Jonathan


On Sun, 29 Aug 2021 at 10:25, Janet Blackquill  wrote:

> Hello,
>
> https://invent.kde.org/libraries/croutons is in kdereview now
>
> Croutons is a library containing assorted functionality for dealing
> with asynchronous code in Qt, most notably a future type that can be
> passed into QML as a JavaScript Thennable (similarly to Qt IVI's
> PendingReply) and headers for C++20 coroutine integration for the
> Croutons Future types + some Qt types that make sense to co_await.
>
> The library is largely headers-only, sans the FutureBase, which has
> one (1) associated source file needing to be compiled into a binary.
>
> -- Janet
>

Re: kalendar desktop-mime-but-no-exec-code

[Jonathan Riddell]

Great thanks, I've packaged this now for neon's unstable edition
https://build.neon.kde.org/view/3%20unstable%20%E2%98%A3%20git%20master/job/focal_unstable_neon-packaging_kalendar/

Jonathan


On Wed, 27 Oct 2021 at 13:28, Claudio Cambra 
wrote:

> Hi Jonathan,
>
> We are now fully vendoring the required Kirigami Addons components, so
> this dependency is now eliminated.
>
> I have also pushed a commit that should fix the
> desktop-mime-but-no-exec-code error. Please let me know if you encounter
> any other issues.
>
> Thanks!
> Clau
>
> On Wed, Oct 27, 2021 at 1:51 PM Jonathan Riddell  wrote:
>
>> Packaging kalendar for neon I found an error
>>
>> desktop-mime-but-no-exec-code
>>
>> which means the .desktop file gives a mimetype but no way to launch it
>>
>> Also it depends on kirigami-addons which has not yet been released,
>> discussed at
>> https://mail.kde.org/pipermail/kde-core-devel/2021-October/091485.html
>>
>> Jonathan
>>
>

kalendar desktop-mime-but-no-exec-code

[Jonathan Riddell]

Packaging kalendar for neon I found an error

desktop-mime-but-no-exec-code

which means the .desktop file gives a mimetype but no way to launch it

Also it depends on kirigami-addons which has not yet been released,
discussed at
https://mail.kde.org/pipermail/kde-core-devel/2021-October/091485.html

Jonathan

Re: New repo in kdereview: kclock

[Jonathan Riddell]

I still don't see any attempt to get kirigami-addons through kdereview and
make a stable release (making a tag in invent isn't the same as making a
stable release).  Does anyone feel able to take enough ownership of it to
do that?  Else kclock and others will be forever stuck.

Jonathan


On Fri, 5 Mar 2021 at 02:04, hanyoung  wrote:

> Hello everyone!
> I want to move kclock to kdereview.
>
> https://invent.kde.org/plasma-mobile/kclock
>
> KClock is the alarm/clock app for Plasma Mobile. It consists of two parts,
> daemon and the client. The daemon communicates with powerdevil to register
> alarms, and provide DBus interface to interact with the client.
>
> Besides the daemon and the client, some plasmoids also included in the
> repo, although only one is enabled so far.
>
> Regards,
> Han
>

Re: New repo in kdereview: kclock

[Jonathan Riddell]

Although KClock now has a release published under stable (
https://download.kde.org/stable/plasma-mobile/21.05/) there is no stable
release of kirigami-addons and no kdereview submission.  That should be
fixed first.

Jonathan


On Thu, 13 May 2021 at 09:57, hanyoung  wrote:

> Kirigami Add-ons (a runtime dependency of kclock) now have a proper
> release. https://invent.kde.org/libraries/kirigami-addons
>
> regards,
> Han
>

Re: qqc2-breeze-stlye in KDE Review

[Jonathan Riddell]

No complaints so I've moved it to Plasma.  It has been included in the
Plasma 5.21 beta.

Jonathan


On Thu, 7 Jan 2021 at 09:29, Noah Davis  wrote:

> https://invent.kde.org/plasma/qqc2-breeze-style/
>
> qqc2-breeze-style is a Qt Quick Controls 2 style made with Qt Quick
> and Kirigami. It has a visual style that is meant to match the Visual
> Design Group's vision for Breeze.
>
> My motivations for making this include the following reasons.
>
> - Creating, iterating on and maintaining a Qt Quick/Kirigami based
> QQC2 style is relatively easy.
>
> - Plasma Mobile needs an efficient QQC2 style.
> - qqc2-breeze-style has better graphical performance than Plasma
> style/PC3 and qqc2-desktop-style. It doesn't depend on the speed of
> the Qt SVG renderer when rendering elements for the 1st time and most
> graphical elements are drawn with the GPU.
> - It has much better RAM usage than PC3, slightly better RAM usage
> than qqc2-desktop-style and about the same RAM usage as Material.
> After opening all pages of Kirigami Gallery, PC3 used 254MB,
> qqc2-desktop-style used 185MB, qqc2-breeze-style used 182MB and
> Material used 180MB. Take those numbers with a grain of salt since the
> absolute amount of RAM used can vary based on how much free RAM there
> is.
> - Its loading times are much better than PC3. I don't remember the
> exact number, but I'm pretty sure it took half as long to load Index
> (Maui file manager) on a PinePhone compared to PC3.
>
> - We occasionally have QQC2 style compatibility issues with 3rd party
> apps that don't force a specific QQC2 style and have been designed
> using other QQC2 styles. qqc2-breeze-style is much more compatible
> with the Default (Basic in Qt 6), Fusion and Material QQC2 styles than
> Plasma style/PC3 and qqc2-desktop-style, so 3rd party apps should be
> less likely to have issues with it. The Fusion QQC2 style will become
> the default QQC2 style on Linux in Qt 6, so I'd expect to see more
> apps designed for it in the future. Unless GNOME starts shipping an
> Adwaita QQC2 style, Fusion will probably be the QQC2 style that 3rd
> party desktop environment users see by default.
>
> - I'd like 3rd party app developers to be able to adopt the look of
> KDE apps even if they aren't part of KDE. As far as I know, there
> aren't that many open source QQC2 styles out there. The visuals of the
> Qt QQC2 styles are not terrible, but not very impressive either and
> the Material QQC2 style is not up to date with Material Design.
> qqc2-breeze-style could gain some popularity outside of KDE if it's
> easy for developers to use and proven on low power platforms like
> Plasma Mobile on the PinePhone.
>
> - Plasma style/PC3 is unfortunately limited by needing to be
> compatible with PC2 in order to not break existing Plasma themes. This
> makes it a fairly poor choice for anything but Plasmoids and anything
> else that doesn't need to be cross-platform or compatible with
> multiple QQC2 styles. Using SVGs for UI graphics has its advantages
> when you want to make something that isn't easy to make with just
> Rectangle/ShadowedRectangle. However, it seriously gets in the way for
> anything that can easily be made with just rectangles, which is most
> UI graphics in the style of Breeze. Plus, manually editing SVGs in a
> text editor to get the element IDs and CSS classes right is never fun.
>
> - qqc2-desktop-style is unfortunately limited by the fact that it gets
> most of its visuals from the system QStyle. This means there's no way
> for it to do things that would be basic in Qt Quick, such as
> animations and drawing shadows/glows/focus rings outside the bounds of
> buttons. Changing the visuals at all is harder in general due to the
> facts that the Breeze QStyle is massive and it's very easy to create
> serious issues in many apps that are hard to fix. See the struggles
> that went into making the new header area of the Breeze QStyle. In
> QML, this would have been easy.
>

Re: Kup in KDE Review

[Jonathan Riddell]

This looks great.  I think the other comments have covered the main issues
so I'll just make a cheeky feature request and suggest it gets the ability
to upload to cloud storage since I would guess that's the main way to do
backups these days.  Talking to Nextcloud or gdrive or AWS directly would
make it much more useful to have.

Jonathan


On Mon, 6 Apr 2020 at 21:01, Simon Persson 
wrote:

> Hello!
>
>
> Please help to review kup.
>
> It is a backup scheduler tightly integrated with plasma (has system
> setting kcm, systray plasmoid, kioslave). It supports saving backups
> either with bup or with rsync.
>
> It has been developed outside of KDE for many years and only now is
> being incubated.
>
> I am unsure if it should end up in extragear or some release service
> bundle. Perhaps people have an opinion on this?
>
> https://invent.kde.org/kde/kup
>
>
> Thanks,
>
> Simon
>
>

Re: CuteHMI in kdereview

[Jonathan Riddell]

I've moved cuteHMI back to playaround pending review of build system,
translation integration and getting some more readable introduction to the
project.

Jonathan


On Sun, 16 Feb 2020 at 22:07, Albert Astals Cid  wrote:

> El dijous, 13 de febrer de 2020, a les 11:00:27 CET, Michal Policht va
> escriure:
> > Yeah, I neglected translations a bit...
>
> Time to stop :)
>
> > I am going to implement adequate
> > Qbs module for extracting translations.
>
> No, that's not how it works. You need to use Messages.sh like the rest of
> us.
>
> Fortunately for you Yuri commited something already.
>
> Now, you need to figure out how to actually load and use those
> translations.
>
> To a regular project i would just suggest to use ecm_create_qm_loader like
> everyone else does, but since sadly you are using an unsupported build
> system, you're on your own.
>
> Cheers,
>   Albert
>
>
>

Re: CuteHMI in kdereview

[Jonathan Riddell]

The licencing looks a little unclear because the LICENSE file says LGPL 3
but there are some files which are GPL 3.  At least the GPL 3 text should
be in the top directory the README.md explain what it applies to.  For
bonus points a full LICENSES/ directory and SPDX descriptions in each file
is a major win (this is a new practice we are moving to for KDE Frameworks
which makes it much easier to understand licencing but as yet not many
projects have moved to it).

Jonathan


On Thu, 6 Feb 2020 at 20:22, Michal Policht  wrote:

> Hello there,
>
> CuteHMI (https://cutehmi.kde.org/) has been moved to kdereview.
>
> CuteHMI is meant to be a set of tools and components that help one to
> create QML-based HMI/SCADA software.
>
> The project has been started few years ago, because I couldn't find any
> open-source, QML-based HMI/SCADA framework I could put my things into.
>
> Regards
>
> Michal Policht
>
>
>

Re: plasma-nano and plasma-phone-components are now in kdereview

[Jonathan Riddell]

I've moved these into kde/workspace now for release with Plasma 5.18 (as
non LTS)

Jonathan


On Fri, 8 Nov 2019 at 07:09, Bhushan Shah  wrote:

> Hello!
>
> plasma-nano: https://invent.kde.org/kde/plasma-nano
> plasma-phone-components:
> https://invent.kde.org/kde/plasma-phone-components
>
> Two repos have been moved to kdereview, with final intended destinition
> being kde/workspace.
>
> plasma-nano is a minimal shell package which other shell package can
> extend, while plasma-phone-components is a shell package, look and feel
> and several other components which makes Plasma Mobile.
>
> Thanks
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
>

Re: KDE Itinerary in kdereview

[Jonathan Riddell]

Looking good

It's more common to name COPYING as COPYING.LIB when it is the LGPL

In the appdata file org.kde.itinerary.desktop  it's better to use
an id without the .desktop on the end since that's unnecessary

And it's missing the launchpable tag

org.kde.$NAME.desktop recommended, see
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-launchable


The wiki page should maybe be named after the app not the library
https://community.kde.org/KDE_PIM/KItinerary

Jonathan



On Sun, 8 Dec 2019 at 12:16, Volker Krause  wrote:

> Hi,
>
> KDE Itinerary has been moved to kdereview:
>
> Code: https://invent.kde.org/kde/itinerary
> Workboard: https://phabricator.kde.org/project/board/280/query/all/
>
> KDE Itinerary is a Kirigami-based mobile application for managing your
> itinerary as a timeline, including access to your travel documents,
> tickets
> and boarding passes, real-time updates for train connections, weather
> forecast
> along your trip, etc.
>
> Its destination for now is probably extragear/pim, but becoming part of
> the
> release service eventually would be desirable.
>
> There are binary factory nightly builds for Android and Flatpak for easy
> testing. It can import travel documents directly, but for the optimal
> experience this is best used together with the KMail Itinerary plug-in and
> a
> Nextcloud/DavDroid calendar or KDE Connect.
>
> Thanks,
> Volker

Re: KTimeTracker in kdereview

[Jonathan Riddell]

Licensing looks good :)

Jonathan


On Tue, 19 Nov 2019 at 04:20, Alexander Potashev 
wrote:

> Hi,
>
> KTimeTracker [1] has been moved to kdereview.
>
> KTimeTracker is a time tracker desktop application which is well
> suited for tracking labor time you spend on a specific
> project/feature/customer.
>
> Its latest release was made on 2015-07-01 as part of KDE PIM 4.14.10.
> Since then I ported KTimeTracker to Qt5/KF5, did a lot of refactoring
> and reworked some dialogs. The major changes since 4.14.10 are listed
> in [2].
>
> KDE CI is set up at [3].
>
> The project is currently in playground-pim, destination would be
> extragear-pim.
>
>
> [1] https://cgit.kde.org/ktimetracker.git
> [2] https://cgit.kde.org/ktimetracker.git/tree/ChangeLog.md
> [3] https://build.kde.org/job/Extragear/job/ktimetracker/
>
> --
> Alexander Potashev
>

Re: plasma-nano and plasma-phone-components are now in kdereview

[Jonathan Riddell]

On Sat, 9 Nov 2019 at 07:10, Christophe Giboudeaux 
wrote:

> On Friday, November 8, 2019 10:36:39 AM CET Alexander Potashev wrote:
> > пт, 8 нояб. 2019 г. в 10:10, Bhushan Shah :
> > > Hello!
> > >
> > > plasma-nano: https://invent.kde.org/kde/plasma-nano
> >
> COPYING.LIB contains the LGPL 2.1 license. The LGPL code in this repo is
> LGPL-2.0-or-later
>
> > > plasma-phone-components:
> > > https://invent.kde.org/kde/plasma-phone-components
>
> You also need the LGPL-2.0-or-later license in this repo.
>

More an aside but I never tend to bother with worrying about the difference
between LGPL 2.0 and 2.1 since it's essentially just a rename.  It would be
cleaner to update the files to say LGPL 2.1 which is what's recommended by
the licence policy
https://community.kde.org/Policies/Licensing_Policy

Great to see someone else care about licence review but :)

Jonathan

Re: KIOFuse in kdereview

[Jonathan Riddell]

This compiles for me but there's no install rule so nothing gets
installed,my ioslaves are unfused

Jonathan

Re: ELF Dissector in kdereview

[Jonathan Riddell]

Yay it's green!
https://build.neon.kde.org/view/3%20unstable%20%E2%98%A3%20git%20master/job/bionic_unstable_neon-packaging_elf-dissector/


On Wed, 30 Oct 2019 at 17:30, Volker Krause  wrote:

> This one probably even affects all 32bit builds with Capstone available,
> not
> just ARM. I've pushed a fix for this.
>
> Thanks!
> Volker
>
> On Wednesday, 30 October 2019 11:02:21 CET Jonathan Riddell wrote:
> > That seems to have worked, it's moved onto the next 32-bit error
> >
> >
> https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_
> > bin_armhf/8/console
> >
> > src/lib/disassmbler/disassembler.cpp:228:65: error: cannot convert
> > ‘uint64_t* {aka long long unsigned int*}’ to ‘size_t* {aka unsigned
> > int*}’ for argument ‘3’ to ‘bool cs_disasm_iter(csh, const uint8_t**,
> > size_t*, uint64_t*, cs_insn*)’*00:00:46*  if
> > (!cs_disasm_iter(handle, , , , insn)) {*00:00:46*
> >   ^
> >
> > Jonathan
> >
> > On Tue, 29 Oct 2019 at 18:27, Volker Krause  wrote:
> > > I haven't recently tested it on 32bit ARM, I pushed a possible fix
> using a
> > > similar approach that has been applied for x86 already. If that doesn't
> > > help I
> > > need to find a 32bit ARM setup again here to properly debug it.
> > >
> > > Regards,
> > > Volker
> > >
> > > On Tuesday, 29 October 2019 11:29:44 CET Jonathan Riddell wrote:
> > > > I'm getting a build failure for this on 32-bit arm
> > >
> > >
> https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissecto
> > > r_>
> > > > bin_armhf/7/console
> > > >
> > > > disassembler.cpp:149:34: error: ‘print_insn_little_arm’ was not
> > > > declared in this scope
> > > >
> > > > Is it expected to build on this architecture?  It builds fine on 64
> bit
> > >
> > > arm.
> > >
> > > > Jonathan
> > > >
> > > > On Sun, 27 Oct 2019 at 09:27, Volker Krause  wrote:
> > > > > Thanks again for the feedback, this has now been moved to
> > >
> > > extragear/sdk.
> > >
> > > > > On Saturday, 28 September 2019 13:01:11 CET Volker Krause wrote:
> > > > > > Hi,
> > > > > >
> > > > > > ELF Dissector has been moved to kdereview for the usual review
> > >
> > > process.
> > >
> > > > > > https://phabricator.kde.org/source/elf-dissector/
> > > > > >
> > > > > > ELF Dissector is a static analysis tool for ELF libraries and
> > > > >
> > > > > executables,
> > > > >
> > > > > > for doing things like inspecting forward and backward
> dependencies
> > >
> > > (on a
> > >
> > > > > > library or symbol level), identifying load-time performance
> > >
> > > bottlenecks
> > >
> > > > > > such as expensive static constructors or excessive relocations,
> or
> > >
> > > size
> > >
> > > > > > profiling of ELF files.
> > > > > >
> > > > > > ELF Dissector has been living in playground for more than 6 years
> > > > >
> > > > > because I
> > > > >
> > > > > > was sloppy following the right process. Since it's in active use
> by
> > > > > > a
> > > > >
> > > > > number
> > > > >
> > > > > > of people, is actively maintained and remains relevant and
> useful I
> > > > > > think
> > > > > > it's time to finally rectify this :)
> > > > > >
> > > > > > Regarding its final destination, extragear/sdk looks like the
> > > > > > obvious
> > > > > > candidate, as its such a niche tool that being part of the KDE
> > > > >
> > > > > Application
> > > > >
> > > > > > bundle is probably hard to argue. Once KDE Applications and the
> > >
> > > "release
> > >
> > > > > > service" are sufficiently decoupled, I'd of course be more than
> > >
> > > happy to
> > >
> > > > > > have it covered by the automatic release process.
> > > > > >
> > > > > > Regarding distribution, there is one annoying aspect, its
> dependency
> > >
> > > on
> > >
> > > > > > semi- public binutils API for accessing the C++ symbol demangling
> > >
> > > AST.
> > >
> > > > > That
> > > > >
> > > > > > works on conventional Linux distributions, but I failed to make
> it
> > >
> > > work
> > >
> > > > > as
> > > > >
> > > > > > a Flatpak due to that.
> > > > > >
> > > > > > Regarding portability, this currently only builds on ELF-based
> > >
> > > systems,
> > >
> > > > > > although theoretically this could be useful on a Windows host
> used
> > >
> > > for
> > >
> > > > > > embedded Linux development too. It's not impossible to make this
> > > > > > work
> > > > > > eventually I think, but it's probably quite some work.
> > > > > >
> > > > > > Thanks,
> > > > > > Volker
>
>

Re: KTrip in kdereview

[Jonathan Riddell]

There's a file called LICENSE with the text of the GPL 2.  We usually call
this COPYING in KDE.

Some of the source code files are under the LGPL 2+ so there should be a
copy of that licence too usually in a file called COPYING.LIB

Jonathan


On Tue, 29 Oct 2019 at 18:36, Nicolas Fella  wrote:

> Hi,
>
> KTrip (https://invent.kde.org/kde/ktrip) has been moved to kdereview.
>
> KTrip is a public transport assistant based on KPublicTransport targeted
> towards Plasma Mobile and Android. Currently it supports querying journeys
> between two locations as well as departures for a location but more
> advanced
> features are possible in the future.
>
> Nightly builds for Android are available on the binary factory (https://
> binary-factory.kde.org/view/Android/job/KTrip_android/).
>
> Destination would be extragear for now, but whatever comes out of KDE
> Applications might make sense.
>
> Cheers
>
> Nico
>
>
>

Re: ELF Dissector in kdereview

[Jonathan Riddell]

On Wed, 30 Oct 2019 at 10:02, Jonathan Riddell  wrote:

> That seems to have worked, it's moved onto the next 32-bit error
>
>
> https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_bin_armhf/8/console
>
> src/lib/disassmbler/disassembler.cpp:228:65: error: cannot convert ‘uint64_t* 
> {aka long long unsigned int*}’ to ‘size_t* {aka unsigned int*}’ for argument 
> ‘3’ to ‘bool cs_disasm_iter(csh, const uint8_t**, size_t*, uint64_t*, 
> cs_insn*)’*00:00:46*  if (!cs_disasm_iter(handle, , , 
> , insn)) {*00:00:46*  
> ^
>
>
>

I can probably get you access to our arm builder if that's useful

Jonathan

Re: ELF Dissector in kdereview

[Jonathan Riddell]

I'm getting a build failure for this on 32-bit arm

https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_bin_armhf/7/console

disassembler.cpp:149:34: error: ‘print_insn_little_arm’ was not
declared in this scope

Is it expected to build on this architecture?  It builds fine on 64 bit arm.


Jonathan





On Sun, 27 Oct 2019 at 09:27, Volker Krause  wrote:

> Thanks again for the feedback, this has now been moved to extragear/sdk.
>
> On Saturday, 28 September 2019 13:01:11 CET Volker Krause wrote:
> > Hi,
> >
> > ELF Dissector has been moved to kdereview for the usual review process.
> >
> > https://phabricator.kde.org/source/elf-dissector/
> >
> > ELF Dissector is a static analysis tool for ELF libraries and
> executables,
> > for doing things like inspecting forward and backward dependencies (on a
> > library or symbol level), identifying load-time performance bottlenecks
> > such as expensive static constructors or excessive relocations, or size
> > profiling of ELF files.
> >
> > ELF Dissector has been living in playground for more than 6 years
> because I
> > was sloppy following the right process. Since it's in active use by a
> number
> > of people, is actively maintained and remains relevant and useful I think
> > it's time to finally rectify this :)
> >
> > Regarding its final destination, extragear/sdk looks like the obvious
> > candidate, as its such a niche tool that being part of the KDE
> Application
> > bundle is probably hard to argue. Once KDE Applications and the "release
> > service" are sufficiently decoupled, I'd of course be more than happy to
> > have it covered by the automatic release process.
> >
> > Regarding distribution, there is one annoying aspect, its dependency on
> > semi- public binutils API for accessing the C++ symbol demangling AST.
> That
> > works on conventional Linux distributions, but I failed to make it work
> as
> > a Flatpak due to that.
> >
> > Regarding portability, this currently only builds on ELF-based systems,
> > although theoretically this could be useful on a Windows host used for
> > embedded Linux development too. It's not impossible to make this work
> > eventually I think, but it's probably quite some work.
> >
> > Thanks,
> > Volker
>
>

Re: ELF Dissector in kdereview

[Jonathan Riddell]

The file src/3rdparty/treemap/treemap.cpp is GPL while the rest of the
application is LGPL.  This makes the whole application copyable under only
the terms of the GPL.  It would be good to have COPYING moved to
COPYING.LIB and a GPL text put in COPYING.
src/ui/org.kde.elf-dissector.appdata.xml should also be changed to be
GPL-2.0-or-later

I couldn't compile it, I get:

[  2%] Building CXX object
src/lib/CMakeFiles/libelfdissector.dir/elf/elfdynamicentry.cpp.o
cd /home/jr/src/elf-dissector/elf-dissector/build/src/lib && /usr/bin/c++
 -DQT_CORE_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-I/home/jr/src/elf-dissector/elf-dissector/build/src/lib
-I/home/jr/src/elf-dissector/elf-dissector/src/lib
-I/home/jr/src/elf-dissector/elf-dissector/build/src/lib/libelfdissector_autogen/include
-I/home/jr/src/elf-dissector/elf-dissector/src
-I/home/jr/src/elf-dissector/elf-dissector/src/3rdparty
-I/home/jr/src/elf-dissector/elf-dissector/build -isystem
/usr/include/x86_64-linux-gnu/qt5 -isystem
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/libiberty -isystem /usr/include/libdwarf -isystem
/usr/include/capstone/..  -std=c++0x -fno-operator-names -fno-exceptions
-Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security
-Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor
-Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time
-Wsuggest-override -Wlogical-op -g -fvisibility=hidden
-fvisibility-inlines-hidden   -fPIC -std=gnu++14 -o
CMakeFiles/libelfdissector.dir/elf/elfdynamicentry.cpp.o -c
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicentry.cpp
In file included from /usr/include/c++/7/bits/stl_algo.h:59:0,
 from /usr/include/c++/7/algorithm:62,
 from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:142,
 from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:45,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QMetaType:1,
 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfsection.h:23,
 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfarraysection.h:21,
 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicsection.h:21,
 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicentry.cpp:19:
/usr/include/c++/7/cstdlib:75:15: fatal error: stdlib.h: No such file or
directory
 #include_next 
   ^~
compilation terminated.

but I do have the file /usr/include/c++/7/stdlib.h

Jonathan



On Sat, 28 Sep 2019 at 12:03, Volker Krause  wrote:

> Hi,
>
> ELF Dissector has been moved to kdereview for the usual review process.
>
> https://phabricator.kde.org/source/elf-dissector/
>
> ELF Dissector is a static analysis tool for ELF libraries and executables,
> for
> doing things like inspecting forward and backward dependencies (on a
> library
> or symbol level), identifying load-time performance bottlenecks such as
> expensive static constructors or excessive relocations, or size profiling
> of
> ELF files.
>
> ELF Dissector has been living in playground for more than 6 years because
> I
> was sloppy following the right process. Since it's in active use by a
> number
> of people, is actively maintained and remains relevant and useful I think
> it's
> time to finally rectify this :)
>
> Regarding its final destination, extragear/sdk looks like the obvious
> candidate, as its such a niche tool that being part of the KDE Application
> bundle is probably hard to argue. Once KDE Applications and the "release
> service" are sufficiently decoupled, I'd of course be more than happy to
> have
> it covered by the automatic release process.
>
> Regarding distribution, there is one annoying aspect, its dependency on
> semi-
> public binutils API for accessing the C++ symbol demangling AST. That
> works on
> conventional Linux distributions, but I failed to make it work as a
> Flatpak
> due to that.
>
> Regarding portability, this currently only builds on ELF-based systems,
> although theoretically this could be useful on a Windows host used for
> embedded Linux development too. It's not impossible to make this work
> eventually I think, but it's probably quite some work.
>
> Thanks,
> Volker

Re: Ruqola in KDE-review

[Jonathan Riddell]

Licence looks good :)

Jonathan


On Thu, 12 Sep 2019 at 08:20, laurent Montel  wrote:

> Hi,
> I would like to move ruqola to extragear/network.
> So I asked to sysadmin to move ruqola to kde-review (it was done).
>
> Ben told me that this period will start in 2 weeks.
>
> If you want to review it... :)
>
> Regards.
>
> --
> Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software
> Engineer
> KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08
> 53,
>  www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent
> software solutions
>
>
>

Re: kaudiocreator to unmaintained

[Jonathan Riddell]

On Thu, Jun 20, 2019 at 08:25:22AM +0200, Kevin Ottens wrote:
> Since I'd rather we have one project with a team size > 1 that two with a 
> team 
> size of 1, I'll retract my previous offer of reviving kaudiocreator and turn 
> my attention to audex instead. Hopefully we can get it out of playground and 
> into KDE Applications.

I've moved kaudiocreator to unmainatained.

Translators please do the necessary with translations.

Jonathan

Re: What means having an application in "KDE Applications"

[Jonathan Riddell]

On Sun, Jun 16, 2019 at 11:41:50PM +0200, Luigi Toscano wrote:
> Jonathan Riddell ha scritto:
> > On Fri, Jun 07, 2019 at 12:09:27AM +0200, Albert Astals Cid wrote:
> >> Can we please discuss what being in KDE Applications is first?
> >>
> >> You're telling apps they can join KDE Applications if they want, so to you 
> >> it's just "release as a service".
> >>
> >> I disagree, to me it's a "we as a community vouch to try to maintain this 
> >> to the best of our ability/time".
> >>
> >> So [to me] adding more things to KDE Applications needs at least a vague 
> >> consensus that it's worth making that kind of promise.
> > 
> > I think KDE should offer services to apps which want to be part of the
> > apps bundled release along with making the tars such as recommending
> > version number, promo, maybe helping out with packaging for Snaps and
> > Flatpaks and Appimage if there's teams happy to do that.  
> 
> I think that you are conflating the "help with the release" with the need for
> applications to be part of the bundle.
> 
> My dream is an automated server-side tarball generation, in a way that
> developers can simply ask to release from a specific tag and don't care about
> uploading the file to the right place on the incoming ftp/ssh server. But that
> service could exist independently from the bundle.

Automating any app releases more would be great.  But I tried to put much
of it into a CI for Plasma once and got stuck because there are access
needed stages that are hard to CI such as GPG signing tars, updating
version numbers, gpg signing and pushing tags.  Still there should be
some scope for improvements there.

Jonathan

Re: What means having an application in "KDE Applications"

[Jonathan Riddell]

On Fri, Jun 07, 2019 at 12:09:27AM +0200, Albert Astals Cid wrote:
> Can we please discuss what being in KDE Applications is first?
> 
> You're telling apps they can join KDE Applications if they want, so to you 
> it's just "release as a service".
> 
> I disagree, to me it's a "we as a community vouch to try to maintain this to 
> the best of our ability/time".
> 
> So [to me] adding more things to KDE Applications needs at least a vague 
> consensus that it's worth making that kind of promise.

I think KDE should offer services to apps which want to be part of the
apps bundled release along with making the tars such as recommending
version number, promo, maybe helping out with packaging for Snaps and
Flatpaks and Appimage if there's teams happy to do that.  But just
trying to get agreement on renaming the bundle shows to me that KDE
isn't ready to take on much more of a role such as maintainance.  I
think the most KDE could offer is to say that everything in the bundle
works as intended and once it bitrots enough that is no longer the
case then it will be kicked out.  I don't think worry that it can't be
maintianed should be a barrier to including an app.

Jonathan

Re: keurocalc status

[Jonathan Riddell]

On Thu, 6 Jun 2019 at 07:15, Eric Bischoff  wrote:

> Le mercredi 5 juin 2019, 18:23:50 CEST Jonathan Riddell a écrit :
> > keurocalc has been ported to KF5 but there seems to have been no release.
> > Does anyone plan to make a release?  Or should it go into KDE
> Applications?
> > Or should it be marked as unmaintained?
> It is maintained (by me), but I don't know how to "make a release". I
> would
> need help on that. With some help, I'd be happy to do it.
>

The easiest way to get it released is to ask for it to be moved into KDE
Applications and then that gets taken care of for you.

Otherwise it's a case of following the page here
https://community.kde.org/ReleasingSoftware
Much of it can be eased with the releaseme scripts which does the branching
and tarring and tagging for you.

Let me know if you need help.

Good luck with the surgery.

Jonathan

Re: konqueror.org

[Jonathan Riddell]

David and Stefano confirmed in private e-mail it was fine to switch it off
for now so that's what I've requested sysadmin to do.

Jonathan


On Thu, 6 Jun 2019 at 09:45, Albert Vaca Cintora 
wrote:

> Killing some satellite websites will ease the maintenance, though, so I'm
> with Jonathan. The screenshots being so old seem a prof to me that its
> being hard for us as a community to keep up with it.
>
> Albert
>
> On Sun, Jun 2, 2019, 12:34 Albert Astals Cid  wrote:
>
>> El dissabte, 1 de juny de 2019, a les 13:07:41 CEST, Jonathan Riddell va
>> escriure:
>> > Can you call konqueror.org website unmaintained?  The screenshots are
>> all
>> > from KDE 4 times.  We can just make it forward to the new
>> > kde.org/applications page instead
>>
>> Or just update the screenshots and all its contents are still valid and
>> much more complete than whatever is there in kde.org/applications.
>>
>> Cheers,
>>   Albert
>>
>> >
>> > Jonathan
>> >
>>
>>
>>
>>
>>

keurocalc status

[Jonathan Riddell]

keurocalc has been ported to KF5 but there seems to have been no release.
Does anyone plan to make a release?  Or should it go into KDE Applications?
Or should it be marked as unmaintained?

Jonathan

Re: Maintenance status of KMid?

[Jonathan Riddell]

There seems to be no Git repository for kmid and infact it's not part of
KDE but still on Sourceforge.  Please file a sysadmin ticket asking for the
bugs.kde.org product to be removed.

Jonathan



On Thu, 30 May 2019 at 15:17, Shinjo Park  wrote:

> Hi,
>
> I'd llike to ask whether KMid is maintained or not:
> - No release/significant commit since 2010
> - Already mentioned as "unmaintained" in a bug 359424 [1]
> - Still not migrated to git/KF5 yet
>
> [1] https://bugs.kde.org/show_bug.cgi?id=359424
>
> Best regards,
> Shinjo
>
>
>

Re: Maintenance status of KMid?

[Jonathan Riddell]

I would call that unmaintained.  I've marked it as unmaintained on the new
kde.org/applications site.  if you don't get a reply in a few days then
just move it to unmaintained in repo-metadata and kill the translations.

Jonathan


On Thu, 30 May 2019 at 15:17, Shinjo Park  wrote:

> Hi,
>
> I'd llike to ask whether KMid is maintained or not:
> - No release/significant commit since 2010
> - Already mentioned as "unmaintained" in a bug 359424 [1]
> - Still not migrated to git/KF5 yet
>
> [1] https://bugs.kde.org/show_bug.cgi?id=359424
>
> Best regards,
> Shinjo
>
>
>

konqueror.org

[Jonathan Riddell]

Can you call konqueror.org website unmaintained?  The screenshots are all
from KDE 4 times.  We can just make it forward to the new
kde.org/applications page instead

Jonathan

Re: Maintainence status of Kooka?

[Jonathan Riddell]

On Tue, 28 May 2019 at 16:22, Jonathan Marten  wrote:

> Adriaan de Groot  writes:
> > Kooka had its last release in 2011, as a KDE3 application. However,
> master is
> > a KF5-based application, with version number 0.90 in CMakeLists.txt. Is
> there
> > any intention to do a release? (That's mostly a question for Jonathan)
> We
> > revived it in FreeBSD packaging, calling current master 0.61.296 (from
> git
> > describe), but it feels a little weird to ship packages of unreleased
> > software.
>
> From my point of view (Kooka maintainer, not to be confused with
> Jonathan Riddell), I'd be happy to make Kooka "released".  As far as I
> am aware it is fully ported to KF5 and has no major outstanding bugs or
> issues.
>
> I'm assuming that this does not mean making it an official part of
> Applications, although it could adopt their YY.MM version numbering
> scheme for consitency.  It would be better to be included in what used
> to be called Extragear (now Self Released?).
>
>
It can be done as Self Released or just added into Applications whichever
you prefer.  Since you say you won't find time for releases until later
that suggets it might be easier to just get it into KDE Applications and
take the burden off your hands but however you wish.  If it's self released
you can use whatever version number you like (the same for Applications
although it's more tidy to use the Applications version).


> I'll start to work through the review process checklist
> (https://community.kde.org/ReleasingSoftware), and then try to submit
> Kooka to kdereview - although that probably won't be able to be until
> after the summer holidays.
>

It's best to start stuff like kdereview sooner rather than later since it
takes at least 2 weeks. The time taken for a kdereview isn't much but the
roundtrips needed for the conversations to happen can take ages.

Jonathan

Re: utils website

[Jonathan Riddell]

On Fri, 24 May 2019 at 18:49, Rolf Eike Beer 
wrote:

> Am Freitag, 24. Mai 2019, 18:14:07 CEST schrieb Jonathan Riddell:
> > Can we call https://utils.kde.org/ dead?
> >
> > I'm updating metadata for kde.org and it would be better to just have
> one
> > place to keep up to date
> > http://apps.kde.org.uk/applications/utilities/
>
> utils.kde.org has some more information, e.g. I have added an extra page
> how
> to set up kgpg to debug things. I'm not sure if the endless version lists
> are
> really of help, but we have them  So if you can migrate some more
> information over there, e.g. where to pick up the .po files and so on, I
> could
> imagine to accept. It would at least stop me forgetting to update the
> release
> version numbers 3 times a year.
>

Adding in version numbers into kde.org/applications means adding them into
appstream data files and it's a change I hope to make to the release
tooling sometime soon.

If there's extra info needed for KGpg that should probably go on
https://userbase.kde.org/KGpg rather than yet another website.

Jonathan

konsole website

[Jonathan Riddell]

can we call this site dead? https://konsole.kde.org/

Updating the metadata e.g.
http://apps.kde.org.uk/applications/system/org.kde.konsole

Jonathan

Re: kaudiocreator to unmaintained

[Jonathan Riddell]

I've not heard of audex.  It doesn't have appstream metadata and it's still
in playground so it doesn't feature on my radar.

Jonathan


On Fri, 24 May 2019 at 16:10, Bernd Steinhauser 
wrote:

> On 22/05/19 13:39, Jonathan Riddell wrote:
> > On Tue, 21 May 2019 at 17:48, Kevin Ottens  > <mailto:er...@kde.org>> wrote:
> >
> > > Will you make releases?
> >
> > I'd like it to be part of KDE Applications. Unlike Zanshin I'd
> rather have
> > this one tied to the Applications release cycle. That being said,
> it's been
> > eons since I had anything in the regular applications collection.
> Could
> > someone refresh me on what it entails to "make release"? Back in the
> day it
> > was fairly transparent, if that's still so low on work I can easily
> say
> > yes...
> > if not I'll have to evaluate.
> >
> >
> > Great, please work with Albert or whoever to get it into the KDE
> Applications
> > bundle.
> >
> > One of the first issues I see is the screenshot needs updating, this can
> be
> > done here
> > https://cgit.kde.org/websites/product-screenshots.git/tree/README.md
> > You may also want to update the metadata in the appstream .xml file,
> currently
> > it generates this:
> > http://apps.kde.org.uk/applications/unmaintained/org.kde.kaudiocreator
> >
> > Jonathan
> >
> Did you guys have a look at audex?
> Last time I looked at both audex and kaudiocreator, I found the former to
> be in
> a much better state.
> That's also why I put in some effort to port it to kf5 (at the time
> neither of
> the two was ported).
>
> Right now the main issue with audex is that the cover fetching doesn't
> work
> (since Google removed a related API), but apart from that it works very
> well.
>
> Of course, if you – for whatever reason – prefer kaudiocreator, feel free
> to
> continue with that one.
> Just wanted to point out that audex exists as well. ;)
>
> Cheers,
> Bernd
>

Re: kaudiocreator to unmaintained

[Jonathan Riddell]

On Tue, 21 May 2019 at 17:48, Kevin Ottens  wrote:

> > Will you make releases?
>
> I'd like it to be part of KDE Applications. Unlike Zanshin I'd rather have
> this one tied to the Applications release cycle. That being said, it's
> been
> eons since I had anything in the regular applications collection. Could
> someone refresh me on what it entails to "make release"? Back in the day
> it
> was fairly transparent, if that's still so low on work I can easily say
> yes...
> if not I'll have to evaluate.
>

Great, please work with Albert or whoever to get it into the KDE
Applications bundle.

One of the first issues I see is the screenshot needs updating, this can be
done here
https://cgit.kde.org/websites/product-screenshots.git/tree/README.md
You may also want to update the metadata in the appstream .xml file,
currently it generates this:
http://apps.kde.org.uk/applications/unmaintained/org.kde.kaudiocreator

Jonathan

Re: Review Request: plasma-thunderbolt

[Jonathan Riddell]

On Wed, May 15, 2019 at 03:27:07PM +0200, Daniel Vrátil wrote:
> plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt KCM 
> for Plasma. I initially submitted the code as a patch against plasma-desktop 
> [0], where it got reviewed, but it was ultimately decided to better put it 
> into a separate repository, since it's not just a KCM but also a library and 
> a 
> KDED module. I have backported all the changes from the Phabricator review 
> back to the repository, so the code in the repo is identical to the one in 
> the 
> Phab review (minus buildsystem changes and a small build fix for clang).
> 
> However, since this is still a new code, it must formally pass through 
> kdereview before I can submit it into Plasma as a new module.
> 
> Thus I'd kindly ask you to take one more look at the codebase [1] and let me 
> know if there are any more issues to fix, or if we can proceed to include 
> this 
> in the next Plasma release.

Installing the bolt package on Debian/Ubuntu/KDE neon I have this file
/usr/lib/x86_64-linux-gnu/boltd
But it is not found by FindBolt.cmake

I need to add this to the search path ${LIB_INSTALL_DIR}

Looks great but I don't have anything Thunderbolt so it's just a white box :)

Jonathan

Re: Kdiff3 renovation

[Jonathan Riddell]

Seems like there's two releases been made, congrats.
https://download.kde.org/stable/kdiff3/
There's been no announcement that I've seen, can you send one to the
kde-apps-announce@ list?
https://marc.info/?l=kde-announce-apps=1=201905=2

Jonathan


On Thu, 9 May 2019 at 16:19, Michael Reeves  wrote:

>
> Just a heads up kdiff3 is about to go through some major renovation.
> Currently file processing is extremely in efficient. There are at least
> three loops through the entirety of the data. Further more thee complete
> copies are kept in memory. Changing this will require almost a complete
> rewrite of the loading routines. These changes carry potential for breakage
> in kdiff3's compassion routines. I will try to avoid this but this area of
> kdiff3 is both complex and fragile. This is master only do to the extent of
> changes required.
>

Re: kaudiocreator to unmaintained

[Jonathan Riddell]

Do you plan to push this commit.  Will you make releases?

Jonathan


On Tue, 14 May 2019 at 21:57, Kevin Ottens  wrote:

> Hello,
>
> On Tuesday, 14 May 2019 17:39:30 CEST Luigi Toscano wrote:
> > On Tuesday, 14 May 2019 16:44:43 CEST Jonathan Riddell wrote:
> > > I'd like to propose moving kaudiocreator to unmaintained
> > >
> > > No commits since Mar 8 22:11:33 2017
> > >
> > > No releases in KF5 time
> > >
> > > Obsolete technology
> >
> > Copying also the last maintainer.
>
> In fact I have one local commit which I forgot to push... from Dec 2017. I
> wanted to brush it up a bit and have it released again. Yes, I buy CDs and
> rip
> them to mp3 or flac. Call me old school.
>
> Regards.
> --
> Kevin Ottens, http://ervin.ipsquad.net
>

Re: Move Simon to unmaintained

[Jonathan Riddell]

Mario seems to be the latest maintainer with cfeck and yourself also doing
work on it.

Jonathan


On Tue, 14 May 2019 at 16:38, Luigi Toscano 
wrote:

> On Tuesday, 14 May 2019 17:15:02 CEST Jonathan Riddell wrote:
> > I'd like to suggest moving Simon to unmaintained.
> >
> > It's still using kdelibs4
> >
> > No significant commits for a couple of years
>
>
>
> Simon has a specific story (KF5 port - did you contact the last
> maintainers?
>
>
> --
> Luigi
>
>
>

kimtoy to unmaintained

[Jonathan Riddell]

I'd like to suggest moving kimtoy to unmtaintained

Trivial bugs go unanswered
https://bugs.kde.org/show_bug.cgi?id=391555

No significant commits since 2016

No releases

Jonathan

kaudiocreator to unmaintained

[Jonathan Riddell]

I'd like to propose moving kaudiocreator to unmaintained

No commits since Mar 8 22:11:33 2017

No releases in KF5 time

Obsolete technology

krecipes to unmaintained

[Jonathan Riddell]

I'd like to propose moving krecipes to unmaintained.  It still uses
kdelibs4 and has had no feature commits since 2016.

Jonathan

ksnapshot to unmaintained

[Jonathan Riddell]

I'd like to propose moving ksnapshot to unmaintained, it's had no code
commits since 2017 and still uses KDElibs4 and the functionality is
replaced by Spectacle.

Jonathan

KDE Applications discussion

[Jonathan Riddell]

There is a discussion about KDE Applications process happening on an
untagged Phab work item

https://phabricator.kde.org/T10812

Jonathan

Re: RKWard is in kdereview

[Jonathan Riddell]

I've now moved this back to playground/edu/rkward as there had not been
movement on all the issues people had brought up and kdereview should only
last a couple months at most.  It would be great to see RKWard brought back
through kdereview and driven to release soon as it looks like a worthy
project.

Jonathan


On Sat, 6 Oct 2018 at 14:47, Thomas Friedrichsmeier <
thomas.friedrichsme...@ruhr-uni-bochum.de> wrote:

> Hi!
>
> KDE.org has been our home for a almost four years, now (after over a
> decade on sourceforge), but somehow I've kept procrastinating on the
> final step: Today I'd like to ask you to start reviewing RKWard for
> inclusion into exragear (coming from playground).
>
>
> RKWard is an easy to use and easily extensible IDE/GUI for R (a
> powerful language and environment for statistical computing, if you
> did not know it, yet). It aims to combine the power of the
> R-language with the ease of use of commercial statistics tools.
>
> RKWard is used productively on Linux/BSD, Mac, and Windows.
>
> We have quite a heavy code-base, and some of it dates back to the time
> when KDE 3.0 was still fresh. I guess reviewing this will not be an
> easy task, and honestly I have no idea where I would recommend you to
> start. So please just ask whatever you need to know, and I'll try my
> best to help you around.
>
> Looking forward to your feedback!
>
> Thomas Friedrichsmeier
> for the RKWard team
>

Re: liquidshell in kdereview

[Jonathan Riddell]

I've now moved this to extragear/base as there did not seem to be any more
political complaints and technical ones seemed fairly fixable.

Jonathan


On Mon, 15 Apr 2019 at 10:16, Martin Koller  wrote:

> On Sonntag, 14. April 2019 23:34:43 CEST Luca Beltrame wrote:
> > Il giorno Sun, 14 Apr 2019 16:43:54 +0200
> > Martin Koller  ha scritto:
> >
> > > The cmake file is the ultimate source for specifying what the
> > > application depends on. Adding this somewhere else will easily get
> >
> > READMEs can be useful for packagers instead of manually watching the
> > output of CMake or reading CMakelists.txt (fine for simpler projects,
> > but not for large ones).
>
> since in this case we are talking about required software,
> the packager will not get the app compiled.
> I assume this will hit his attention.
> I would understand that optional dependencies are different since the app
> would build but not with all options.
>
> --
> Best regards/Schöne Grüße
>
> Martin
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
>
>
>
>

Welcome CuteHMI

[Jonathan Riddell]

Please welcome CuteHMI to KDE, it has now passed incubator into Playground

description: CuteHMI is an open-source HMI (Human Machine Interface)
software written in C++ and QML, using Qt libraries as a framework.

https://community.kde.org/Incubator/Incubated_Projects

placeholder website: https://cutehmi.kde.org/

matrix:#cutehmi:kde.org

https://community.kde.org/File:Cutehmi.png

https://cgit.kde.org/cutehmi.git/

Jonathan

Re: [kde-core-devel] Extragear release files

[Jonathan Riddell]

On Fri, Apr 12, 2019 at 04:55:47PM -0400, Michael Reeves wrote:
> Where do release files go after sys admin moves them? Where would they be
> downloaded from?

Moved to the place on master.kde.org where is used for
download.kde.org.  Packagers have an account on master.kde.org to be
able to scp them off.  Others will need to wait for you to ask
sysadmin to make them public and they'll appear on download.kde.org.

Jonathan

Re: Symmy in kde-review

[Jonathan Riddell]

This has now moved into extragear/utils.

Jonathan

On Sat, 25 Nov 2017 at 13:31, Elvis Angelaccio  wrote:
>
> Hi,
> symmy has been moved to kde-review for the usual review process.
>
> It's a tiny frontend for the symmetric encryption functionality of GPG. It
> doesn't handle signing or public/private keys, as we already have kgpg or
> kleopatra for that.
>
> Symmy can be useful if you have to send some sensitive file to someone, of
> if you want to store it on some proprietary cloud service.
>
> It comes with a CLI application and plugins for GUI integration with
> Dolphin/Plasma.
>
> I'd like to move it to either extragear-utils or kde-utils, if everything
> looks good.
>
> Thanks,
> Elvis

Re: Symmy in kde-review

[Jonathan Riddell]

I'm bumping this thread again to get a decision on symmy passing
kdereview.  The technical problems have been fixed.  The question of
whether it would be better to add to kgpg is open but as it has not
been added to kgpg and nobody is planning to do so it's a moot point.
So give symmy a final review if you wish else I'll put it into
extragear.

Jonathan

On Sat, 25 Nov 2017 at 13:31, Elvis Angelaccio  wrote:
>
> Hi,
> symmy has been moved to kde-review for the usual review process.
>
> It's a tiny frontend for the symmetric encryption functionality of GPG. It
> doesn't handle signing or public/private keys, as we already have kgpg or
> kleopatra for that.
>
> Symmy can be useful if you have to send some sensitive file to someone, of
> if you want to store it on some proprietary cloud service.
>
> It comes with a CLI application and plugins for GUI integration with
> Dolphin/Plasma.
>
> I'd like to move it to either extragear-utils or kde-utils, if everything
> looks good.
>
> Thanks,
> Elvis

Re: KDiff3 1.8 release.

[Jonathan Riddell]

Groovy got it added to Neon dev unstable edition
https://build.neon.kde.org/job/bionic_unstable_forks_kdiff3/
I fixed the kcrash loading with it

Jonathan

On Sat, 16 Mar 2019 at 21:19, Michael Reeves  wrote:
>
>
>
> On Sat, Mar 16, 2019, 1:14 PM Jonathan Riddell  wrote:
>>
>> Looks good from a quick compile and run.
>>
>> I take it you have no access to the obsolete sourceforge webpage?
>>
>> I see Debian has a 1.7 release, where is that available?
>
> If it's truly 1.7 its based off a partial kf5 port that was never released. 
> Don't remember off hand who created. 1.7.90 would be an older version of my 
> code not officially released.
>>
>>
>> Do you have any access to update
>> https://www.linux-apps.com/content/show.php?content=9807 ?
>
>
> No.
>
>>
>>
>> I'm adding this to KDE neon dev unstable edition.
>>
>> Eike is the Debian packaging managed in a repo somewhere?  Are you
>> interested in making it part of the KDE Qt Debian team?
>
>
> Yes.
>
>>
>> Jonathan
>>
>>
>>
>> On Sat, 16 Mar 2019 at 14:11, Michael Reeves  wrote:
>> >
>> > Fixed now.
>> >
>> > On Thu, Mar 14, 2019, 4:31 AM Wolfgang Bauer  wrote:
>> >>
>> >> The latest change
>> >> (https://cgit.kde.org/kdiff3.git/commit/?id=638bd5a02893dde4a1927abd0c8a611b3b3ab6a1)
>> >> unfortunately breaks the build here:
>> >>
>> >> /usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld:
>> >> CMakeFiles/kdiff3part.dir/pdiff.cpp.o: in function
>> >> `debugLineCheck(Diff3LineList&, int, e_SrcSelector)':
>> >> /home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:82: undefined
>> >> reference to `kdeMain()'
>> >> /usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld:
>> >> /home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:96: undefined
>> >> reference to `kdeMain()'
>> >> ...
>> >> and so on.
>> >>
>> >> Kind Regards,
>> >> Wolfgang
>> >>

Re: welcome plasma-active-window-control

[Jonathan Riddell]

On Sat, Mar 16, 2019 at 07:55:16PM +0100, Roman Gilg wrote:
> On Sat, Mar 16, 2019 at 6:53 PM Jonathan Riddell  wrote:
> >
> > Just passed kdereview and moved into extra/base is Plasma Active Window 
> > Control.
> >
> > Plasma Active Window Control is a plasma widget that you can embed in
> > your panel to control your active window with e.g. close or maximise
> > operations.  Useful for decorationless window management.
> >
> > New maintainer is Chris Holland.  Do say hello.
> >
> > Jonathan
> 
> Hello,
> 
> do you have a link with some more information? Sounds neat.

Just the git repo and screenshot so far

https://cgit.kde.org/plasma-active-window-control.git/

https://cdn.kde.org/screenshots/plasma-active-window-control/active-window-control.png

Jonathan

welcome plasma-active-window-control

[Jonathan Riddell]

Just passed kdereview and moved into extra/base is Plasma Active Window Control.

Plasma Active Window Control is a plasma widget that you can embed in
your panel to control your active window with e.g. close or maximise
operations.  Useful for decorationless window management.

New maintainer is Chris Holland.  Do say hello.

Jonathan

Re: KDiff3 1.8 release.

[Jonathan Riddell]

Looks good from a quick compile and run.

I take it you have no access to the obsolete sourceforge webpage?

I see Debian has a 1.7 release, where is that available?

Do you have any access to update
https://www.linux-apps.com/content/show.php?content=9807 ?

I'm adding this to KDE neon dev unstable edition.

Eike is the Debian packaging managed in a repo somewhere?  Are you
interested in making it part of the KDE Qt Debian team?

Jonathan



On Sat, 16 Mar 2019 at 14:11, Michael Reeves  wrote:
>
> Fixed now.
>
> On Thu, Mar 14, 2019, 4:31 AM Wolfgang Bauer  wrote:
>>
>> The latest change
>> (https://cgit.kde.org/kdiff3.git/commit/?id=638bd5a02893dde4a1927abd0c8a611b3b3ab6a1)
>> unfortunately breaks the build here:
>>
>> /usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld:
>> CMakeFiles/kdiff3part.dir/pdiff.cpp.o: in function
>> `debugLineCheck(Diff3LineList&, int, e_SrcSelector)':
>> /home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:82: undefined
>> reference to `kdeMain()'
>> /usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld:
>> /home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:96: undefined
>> reference to `kdeMain()'
>> ...
>> and so on.
>>
>> Kind Regards,
>> Wolfgang
>>

KDE Review passes

[Jonathan Riddell]

Welcome the following projects which passed kdereview process

plasma-simplemenu now in selfrelease/extra and released on store.kde.org
pulseaudio-qt now in selfrelease/extra and released on download.kde.org
rust-qt-binding-generator now in selfrelease/extra
plasma-redshift-control now in selfrelease/extra

We really do need to sort out the terminology for
extragear/extra/self-released things.

Jontahan

Welcome Latte Dock to KDE

[Jonathan Riddell]

Latte is a dock based on plasma frameworks that provides an elegant
and intuitive experience for your tasks and plasmoids. It animates its
contents by using parabolic zoom effect and tries to be there only
when it is needed.

It's been part of KDE for a while but the incubation process stalled.
With the creation of a new home wiki page
https://community.kde.org/LatteDock and User wiki page
https://userbase.kde.org/LatteDock/ I've been able to set the
incubation to green.

Jonathan

Re: KDE Review reviews

[Jonathan Riddell]

On Thu, 7 Mar 2019 at 23:38, Albert Astals Cid  wrote:
>
> El dijous, 7 de març de 2019, a les 17:33:27 CET, Jonathan Riddell va 
> escriure:
> > I've made a list of kdereview projects and their current status as I
> > understand them and e-mailed the maintainers for updates
>
> Cool :)
>
> Do you think maybe it would have made more sense to do those update emails 
> here (in the original thread of emails) so they would also be public?

In general yes but I thought today I'd try the personal touch since
the public approach had stopped progressing, some progress has been
made.

Jonathan

KDE Review reviews

[Jonathan Riddell]

I've made a list of kdereview projects and their current status as I
understand them and e-mailed the maintainers for updates
https://community.kde.org/KDEReview
(this is linked from the lifecycle wiki page).

Feel free to help keep that page up to date.

I moved kpeg and kdot to unmaintained as they haven't had any activity
since we last discussed them in 2017.

Jonathan

Re: libqaccessibilityclient now in kdereview

[Jonathan Riddell]

On Thu, 7 Mar 2019 at 05:20, Friedrich W. H. Kossebau  wrote:
> Soon it will be 2 years that libqaccessibilityclient entered kdereview, and I
> just found it seems to be still in that state, at least by what repo-metadata
> claims and given no emails to the thread which sonud like review done
> I came across it when compiling kmag myself, where the optional dep on this
> exists.

Thanks for your fixes.  I just spoke to Frederik on IRC who says I can
the beaurocracy forward so I've filed a sysadmin ticket to move to
extragear/libs and I guess I'll make a 0.4.0 change once that happens
and try to get it onto build.kde.org.

Jonathan

Re: Move pulseaudio-qt to Extragear

[Jonathan Riddell]

If the issues and and Alberts have discussed are dealt with then this
can be moved to extragear and a release made. Let me know if you need
any help.

Jonathan

On Wed, 28 Nov 2018 at 12:40, Nicolas Fella  wrote:
>
> I've fixed the remaining clazy warnings.
>
> Cheers
>
> Nicolas
>
> On Mittwoch, 7. November 2018 00:48:31 CET Albert Astals Cid wrote:
> >
> > I proposed some small clazy fixes, but there's some more warnings that may
> > make sense having a look over.
> >
> > https://paste.kde.org/p5lhjhosn
> >
> > Cheers,
> >   Albert
>
>
>
>

Re: Move pulseaudio-qt to Extragear

[Jonathan Riddell]

nSeems to be all LGPL 2+3 or as approved by e.v. licence.  I'd remove
the COPYING file with the GPL text to avoid confusion.

Building with QCH seems to need this file renamed to allow stuff to
build with it
https://packaging.neon.kde.org/extras/pulseaudio-qt.git/tree/debian/patches/qch-target-cmake.diff?h=Neon/unstable
But the QCH cmake file is empty so I'm not sure it does anything anyway.

Otherwise all good looking at the build we added to KDE neon
https://build.neon.kde.org/job/bionic_unstable_extras_pulseaudio-qt/

kdeconnect now builds with the systemvolume plugin but I can't work
out how to get it to do anything
https://build.neon.kde.org/job/bionic_unstable_extras_kdeconnect/

Jonathan


On Mon, 5 Nov 2018 at 19:09, Nicolas Fella  wrote:
>
> Hi,
>
> together with David Rosca and Aleix Pol I have worked on extracting the
> libpulse abstraction from plasma-pa into a library [0][1]. It is
> currently optionally required by KDE Connect. plasma-pa and
> libtaskmanager will use it at some point in the future. Long-term plan
> is to move it to Frameworks, but until the required documentation and
> testing is done I'd like to move it to Extragear and make an initial
> release.
>
> Cheers
>
> Nicolas
>
> [0] https://phabricator.kde.org/T7994
>
> [1] https://cgit.kde.org/pulseaudio-qt.git
>

Re: RKWard is in kdereview

[Jonathan Riddell]

There's no appstream metainfo file nor product-screenshot
https://community.kde.org/Guidelines_and_HOWTOs/AppStream

Jonathan

On Sat, 6 Oct 2018 at 14:47, Thomas Friedrichsmeier
 wrote:
>
> Hi!
>
> KDE.org has been our home for a almost four years, now (after over a
> decade on sourceforge), but somehow I've kept procrastinating on the
> final step: Today I'd like to ask you to start reviewing RKWard for
> inclusion into exragear (coming from playground).
>
>
> RKWard is an easy to use and easily extensible IDE/GUI for R (a
> powerful language and environment for statistical computing, if you
> did not know it, yet). It aims to combine the power of the
> R-language with the ease of use of commercial statistics tools.
>
> RKWard is used productively on Linux/BSD, Mac, and Windows.
>
> We have quite a heavy code-base, and some of it dates back to the time
> when KDE 3.0 was still fresh. I guess reviewing this will not be an
> easy task, and honestly I have no idea where I would recommend you to
> start. So please just ask whatever you need to know, and I'll try my
> best to help you around.
>
> Looking forward to your feedback!
>
> Thomas Friedrichsmeier
> for the RKWard team

Re: RKWard is in kdereview

[Jonathan Riddell]

On Fri, Oct 12, 2018 at 10:03:16PM +0200, Thomas Friedrichsmeier wrote:
> Ok, will do. It may take me a while, though, as I'll have to be careful
> not to break our automated builds on our Ubuntu PPAs (as pointed out by
> Meik). But ideally, I'd also like to combine this step with handing
> over our official debian packaging (i.e. the "debian-official" folder)
> to the debian qt/kde-team.
> 
> Is there any hope for that, or what can I do to make that happen?

Talk to some folks on the team, maybe start with Scarlett (CCed) who is getting 
some good stuff into there.

Jonathan

Re: RKWard is in kdereview

[Jonathan Riddell]

I added it into Neon
https://packaging.neon.kde.org/neon-packaging/rkward.git/
https://build.neon.kde.org/view/1%20release%20⛰/job/bionic_release_neon-packaging_rkward/

It's the norm for Debian packages to have their packaging kept
separate from the upstream source including for PPAs, keeping them
together is quite confusing.

QGuiApplication should include ability for single instance application
rather than having separate .desktop files for it.

Jonathan


On Wed, 10 Oct 2018 at 17:33, Thomas Friedrichsmeier
 wrote:
>
> On Wed, 10 Oct 2018 18:24:38 +0200
> meik michalke  wrote:
> > how would it affect our various PPAs if there was no debian/
> > directory in the sources?
>
> In fact, we'd have to keep the debian packaging somewhere, and "merge"
> it into the sources while building (we do the same for translations in
> the PPAs, so the procedure itself is pretty clear). But we only need the
> "sloppy" variant of the packaging for this purpose (i.e. the one that
> just works, without trying to keep up the latest debhelper
> compatibility levels, and such; "debian" instead of "debian-official").
>
> Regards
> Thomas

Fwd: Elisa Music Player is in kdereview

[Jonathan Riddell]

In the docs it says
' (NOTE:  All documentation are licensed under the FDL,
 regardless of what license the application uses) -->
'
but the docs are under CC-BY-SA 4.0.  I guess this is from an old
template, do you remember where the template is?

Have you considered making upnp-player-qt a KDE project to get it more
exposure?  It could even be a Framework.
Then again README.packagers says
'UPnP/DLNA via unreleased UPNPQT library is currently broken. Please
consider not building it.'
It might be worth noting that in the cmake output even if it's not
found so people don't spend time looking for it.

I found it needed these runtime bits which aren't listed in the README.packagers
 qml-module-qtqml-models2,
 qml-module-org-kde-kcm,
 qml-module-qtquick-controls,
 qml-module-qtquick-dialogs,
 qml-module-qtquick-layouts,
 qml-module-qtquick2,

Do you have a GPG key published and able to sign tars?  This seems to
trip up a lot of developers at release time.

Well done on a great new app!

Jonathan



On 5 February 2018 at 19:35, Matthieu Gallien
 wrote:
> Hello,
>
> Elisa is now in kdereview and aiming for extragear/multimedia. We may (in 
> agreement with the module maintainer) move later to the Multimedia KDE 
> Applications module.
>
> It is a music player written with qml and a few KDE frameworks. It is 
> primarily intended to integrate with baloo but can also index music on its 
> own and open arbitrary files from command line or a file browser.
>
> We have worked on a vision to help clarify the what our intentions are:
>
> Elisa is a music player developed by the KDE community that strives to be 
> simple and nice to use. We also recognize that we need a flexible product to 
> account for the different workflows and use-cases of our users.
>
> We focus on a very good integration with the Plasma desktop of the KDE 
> community without compromising the support for other platforms (other Linux 
> desktop environments, Windows and Android).
>
> We are creating a reliable product that is a joy to use and respects our 
> users privacy. As such, we will prefer to support online services where users 
> are in control of their data.
>
> We also want to align our work with the goals that have been decided by the 
> whole KDE community.
>
> Best regards
>
> --
> Matthieu Gallien in the behalf of the Elisa team

Re: Latte Dock in review phase

[Jonathan Riddell]

Looks good from a brief look around I did from a packagers point of
view (so not looking at the code).

I'm unsure why it's both a plasmoid and a standalone binary, that
seems superfluous.  Maybe it's for use outwith Plasma.

docs/ directory seems unused

Green build in neon :)
https://build.neon.kde.org/job/xenial_unstable_kde-extras_latte-dock/

Jonathan


On 4 October 2017 at 22:00, Michail Vourlakos  wrote:
> Hello everyone,
>
> we decided to make Latte an active kde project and so now it is in review
> phase. I believe the best place to be is extragear because we would like to
> keep some independence for the first year concerning releases...
>
> What is Latte Dock?
>
> Latte is a project that is trying to provide a unified solution concering
> docks and panels for the user. To achieve this it provides,
> the Latte app, a Latte qml library, a Latte containment, a Latte plasmoid, a
> Latte shell that uses plasma shell as base and 2 applets (a separator and a
> specialized spacer)
>
> for more infos concerning the capabilities of the Latte suite you can find
> at:
> https://psifidotos.blogspot.nl/2017/04/latte-dock-v06-fresh-air.html
> https://psifidotos.blogspot.nl/2017/08/latte-dock-v07-tornado-is-coming.html
>
> the project before entering the kde infrastructure could be found at:
> https://github.com/psifidotos/Latte-Dock
>
> in review you can find our 0.7.1 version which is our stable version and the
> plan is that after we succeed in the review phase to release a 0.7.2 version
> only through kde infrastructure...
>
> regards,
> michail

Re: libqaccessibilityclient now in kdereview

[Jonathan Riddell]

Any progress or comment on the other issues raised?

Jonathan


On 26 July 2017 at 17:14, Frederik Gladhorn <gladh...@kde.org> wrote:
> Hi all,
>
> On onsdag 26. juli 2017 08.11.18 CEST Ben Cooksley wrote:
>> On Wed, Jul 26, 2017 at 9:18 AM, Mario Fux <kde...@unormal.org> wrote:
>> > Am Dienstag, 25. Juli 2017, 14:55:42 CEST schrieb Albert Astals Cid:
>> >
>> > Morning Albert
>>
>> Hi Mario,
>>
>> >> El dimarts, 25 de juliol de 2017, a les 13:25:39 CEST, Jonathan Riddell
>> >> va
>> >>
>> >> escriure:
>> >> > libqaccessibilityclient is now in kdereview.  It's in a git repo
>> >> > called libkdeaccessibilityclient but we filed a sysadmin request to
>> >> > rename it.
>> >> >
>> >> > We just released 0.2.0 in unstable (for some reason 0.1.1 was released
>> >> > in stable some years ago).
>> >>
>> >> Do we really have to keep the Qt4 compatibility or can we kill it?
>> >
>> > Please keep it for now as the next Simon release (0.5.0 which is on its
>> > way) is still Qt4 based.
>>
>> Simon is (for the moment at least) prohibited from depending on
>> libqaccessibilityclient, because Extragear (as well as Plasma and
>> Applications module) applications are not allowed to depend on code
>> which is in Playground or KDE Review.
>
> It's indeed completely optional and I'm not sure if the code in Simon is ready
> for prime time. Peter wrote it as an experiment (and it seems to more or less
> work), but I'm not sure how stable it actually is.
>
> Cheers,
> Frederik
>
>
>>
>> > Thx
>> > Mario
>>
>> Cheers,
>> Ben
>>
>> >> Cheers,
>> >>
>> >>   Albert
>> >>
>> >> > What is it?
>> >> > 
>> >> > Since it's hard to grasp all the bits related to accessibility, I'll
>> >> > try
>> >> > to
>> >> > explain what the lib is for.
>> >> > Most of the stack is part of Qt 5, so nothing to worry about, that's
>> >> > the
>> >> > part that lets applications expose their UI over DBus for AT-SPI, so
>> >> > they
>> >> > work nicely with assisitve tools (e.g. Orca). In accessibility
>> >> > language,
>> >> > the applications act as "servers" and the screen reader for example is
>> >> > a
>> >> > client.
>> >> >
>> >> > This library is for writing clients, so applications that are
>> >> > assistive,
>> >> > such as screen readers. It currently has two users: KMag and Simon.
>> >> > KMag can use it to follow the focus (e.g. when editing text, it can
>> >> > automatically magnify the part of the document where the cursor is.
>> >> >
>> >> > For Simon Listens, the use is to be able to let the user trigger menus
>> >> > and
>> >> > buttons by voice input.
>
>

libqaccessibilityclient now in kdereview

[Jonathan Riddell]

libqaccessibilityclient is now in kdereview.  It's in a git repo
called libkdeaccessibilityclient but we filed a sysadmin request to
rename it.

We just released 0.2.0 in unstable (for some reason 0.1.1 was released
in stable some years ago).

What is it?

Since it's hard to grasp all the bits related to accessibility, I'll try to
explain what the lib is for.
Most of the stack is part of Qt 5, so nothing to worry about, that's the part
that lets applications expose their UI over DBus for AT-SPI, so they work
nicely with assisitve tools (e.g. Orca). In accessibility language, the
applications act as "servers" and the screen reader for example is a client.

This library is for writing clients, so applications that are assistive, such
as screen readers. It currently has two users: KMag and Simon.
KMag can use it to follow the focus (e.g. when editing text, it can
automatically magnify the part of the document where the cursor is.

For Simon Listens, the use is to be able to let the user trigger menus and
buttons by voice input.

Re: Moving AtCore to Extragear

[Jonathan Riddell]

On Fri, Jun 23, 2017 at 08:22:39AM +1200, Ben Cooksley wrote:
> On Fri, Jun 23, 2017 at 7:56 AM, Luigi Toscano  
> wrote:
> > Albert Astals Cid ha scritto:
> >> El diumenge, 18 de juny de 2017, a les 9:48:07 CEST, Lays Rodrigues va
> >> escriure:
> >>> Hey guys, good morning. =D
> >>> Any more comments on AtCore code?
> >>> How the moving to Extragear work?
> >>
> >> Are you planning to at least answer my last comments saying "we don't 
> >> really
> >> care about that level of perfection"? (which is a fair position)
> >>
> >
> > In addition to Albert's comment, I noticed now (still going through the
> > backlog after vacation) that atcore use tr() for messages, but there is no
> > Messages.sh file to extract the strings (which should be called atcore_qt,
> > check the similar files in step or marble or in tier1 frameworks).
> >
> > Unfortunately the repository was already moved directly to extragear, and I
> > expressed already my disagreement about this move with still open questions.
> 
> I'm going to be reversing that move, as the repository hasn't cleared review.
> Additionally, the commit is technically wrong and was committed while
> I had noted objections on the review.

I'm terribly sorry about this, I guess I got ahead of myself.

The issue you pointed about updating the project path and deteling the 
repo-metadata entry in playground I did.

Luigi brought up an issue about translations but that was after I had moved it.

I see Albert has an outstanding question, Lays can you answer that?

Jonathan

Re: Kirigami in Frameworks

[Jonathan Riddell]

On 21 June 2017 at 15:00, Marco Martin  wrote:
> As there were no replies for quite a while, i assume there are no
> particular objections.
>
> so, how to proceed? what needs to be doe to do the actual move?

Does it comply with the policies (as much as they are relevant for QML)?
https://community.kde.org/Frameworks/Policies

Get David Faure to give his approval then see what the reponse to my
"who is authorised to move repos around?" thead is.
https://marc.info/?l=kde-core-devel=149806172721190=2

Jonathan

who is authorised to move repos around?

[Jonathan Riddell]

I'm unclear who is authorised to move git repos around, e.g. from
playground to kdereview to kde-extra

It used to be only sysadmins which seems like a political burden on a tech team.

Now anyone can edit repo-metadata.  So can anyone move repos around as
long as rules and conventions are followed?

I wonder if it should be a task moved to a team such as the release
team (but then that's not a well defined team).

I'm asked because I was asked to review atcore being moved around
https://phabricator.kde.org/D6318

Jonathan

Re: kdereview - qtcurve

[Jonathan Riddell]

On 16 June 2017 at 16:07, Yichao Yu  wrote:
> QtCurve is now in kdereview with the intention of being in extragear/base

You should set the stable branch to 1.9 in repo-metadata and ask
translator admins to make a stable branch for translations

Jonathan

Re: clazy is in kdereview

[Jonathan Riddell]

On 16 June 2017 at 15:24, Sérgio Martins  wrote:
> clazy is a clang plugin which allows clang to understand Qt semantics.
> You get more than 50 Qt related compiler warnings, ranging from
> unneeded memory allocations to misusage of API, including fix-its for
> automatic refactoring.

Looks very cool.

I renamed the copyright file to make it consistent with other KDE
repos and updated copyright info in man page as discussed.

Jonathan

Re: Moving AtCore to Extragear

[Jonathan Riddell]

On 18 June 2017 at 13:48, Lays Rodrigues  wrote:
> Hey guys, good morning. =D
> Any more comments on AtCore code?
> How the moving to Extragear work?

As discussed it should already be in kdereview, then it can go into extragear

See README.md in kde:sysadmin/repo-metadata for how to move

See https://techbase.kde.org/ReleasingExtragearSoftware for how to do releases

Jonathan

Re: Zanshin is in kdereview

[Jonathan Riddell]

On Mon, Jun 19, 2017 at 09:36:39PM +0200, Kevin Ottens wrote:
> Hello,
> 
> On Monday, 12 June 2017 16:48:26 CEST Jonathan Riddell wrote:
> > On 10 June 2017 at 14:08, Kevin Ottens <er...@kde.org> wrote:
> > >> You have a release script in scripts/release.sh, consider using
> > >> kde:releaseme as extracting translations can be quite faffy and
> > >> releaseme does all that for you.
> > > 
> > > I tried that recently but didn't manage to get it to work at all. Failed
> > > with a backtrace leading to some obscure Ruby dependency and got stuck.
> > > Any guidance is welcome there, I'm especially interested because of the
> > > translation extraction bits which I do a bad job at since the
> > > beginning...
> > releaseme shouldn't need any external dependencies except Ruby so post
> > us the backtrace and I'll take a look
> 
> After pulling again today it now works much better! :-)
> 
> Looks like I just didn't clone at the right time.
> 
> That said, there's something fishy with the signature:
> https://paste.kde.org/pgh6b1em7

releaseme doesn't do anything special with gpg, it just runs
 gpg2 --armor --detach-sign -o #{sigfile} #{file}

So does gpg2 work for you signing a text file?

Jonathan

Re: kio-stash is in KDE Review

[Jonathan Riddell]

Better as kio-extras in KDE Applications no?

Jonathan


On 19 June 2017 at 10:00, Arnav Dhamija  wrote:
> Thanks. I have fixed this and the kio-stash ioslave passes all the
> test cases on CI here:
> https://build-sandbox.kde.org/view/Extragear/job/Extragear%20kio-stash%20kf5-qt5%20SUSEQt5.9/
>
> The build log for the same can be found here:
> https://build-sandbox.kde.org/view/Extragear/job/Extragear%20kio-stash%20kf5-qt5%20SUSEQt5.9/11/timestamps/?time=HH:mm:ss=en_US
>
> I feel the ioslave is now ready to be shipped. The question is if it
> can be included as part of KDE Frameworks for the next major release
> or if it should be a separate package only in KDE Extra gear.
>
> On Mon, Jun 19, 2017 at 3:07 AM, Albert Astals Cid  wrote:
>> El dimecres, 14 de juny de 2017, a les 21:42:58 CEST, Arnav Dhamija va
>> escriure:
>>> Just to check I setup a brand new virtualbox with KDE Neon 5.8 LTS and
>>> ran the following commands after cloning the repo and creating a build
>>> directory:
>>>
>>> cmake -DCMAKE_INSTALL_PREFIX=/usr -DKDE_INSTALL_USE_QT_SYS_PATHS=TRUE ..
>>> make
>>
>> git code does not compile as of now.
>>
>> Cheers,
>>   Albert
>>
>>> sudo make install
>>> kdeinit5
>>>
>>> ..and then I ran the tests using 'ctest -v'. It passed slavetest with
>>> no issues (18 out of 18 tests passed). My guess why it doesn't work
>>> you is because you haven't run kdeinit5 after installing the ioslave.
>>> If not that, the testdaemon process might not have been successfully
>>> registered on the system D-Bus when thes test is run.
>>>
>>> Is there a way I can see if my test cases pass on KDE's CI
>>> infrastructure to narrow down the problem? If so, I will a sysadmin to
>>> do so.
>>>
>>> On Tue, Jun 13, 2017 at 4:16 AM, Albert Astals Cid  wrote:
>>> > El divendres, 9 de juny de 2017, a les 11:45:14 CEST, Arnav Dhamija va
>>> >
>>> > escriure:
>>> >> > Do you mean i have to manually start a process for the tests to
>>> >> > succeed?
>>> >>
>>> >> If installed correctly with kdeinit restarted and the Stash Daemon is
>>> >> running in kded5, it is not required. However, I cannot recall what
>>> >> steps are needed for this to happen as I think it requires a system
>>> >> restart or logout to do so.
>>> >>
>>> >> Hence, I have created a fallback testdaemon program which creates a
>>> >> daemon process for the Stash Daemon to run. This is launched
>>> >> automatically by the test suite if the test suite cannot find the
>>> >> Stash Daemon running in kded. I just patched it so that it finds the
>>> >> path to the testdaemon program correctly (it had the wrong path when
>>> >> you tested it). It should pass the test cases now with no manual
>>> >> invocation of the testdaemon process.
>>> >
>>> > Doesn't seem to work for me.
>>> >
>>> > https://paste.kde.org/ptnn5hhkt
>>> >
>>> > Cheers,
>>> >
>>> >   Albert
>>> >>
>>> >> On Fri, Jun 9, 2017 at 1:47 AM, Albert Astals Cid  wrote:
>>> >> > El dijous, 8 de juny de 2017, a les 16:25:02 CEST, Arnav Dhamija va
>>> >
>>> > escriure:
>>> >> >> Yes, I will file a sysadmin ticket for the same. Until I do so, could
>>> >> >> you send me the output of the test suite in a screenshot or as plain
>>> >> >> text?
>>> >> >>
>>> >> >> The ioslave works by storing a list of virtual files and folders in a
>>> >> >> process running in the KDED, communicating with it over D-Bus. Hence,
>>> >> >> some of the tests won't work unless a) the testdaemon process is
>>> >> >> started
>>> >> >
>>> >> > Do you mean i have to manually start a process for the tests to
>>> >> > succeed?
>>> >> >
>>> >> > If that is the case, that's not acceptable.
>>> >> >
>>> >> > Cheers,
>>> >> >
>>> >> >   Albert
>>> >> >>
>>> >> >> or b) the Stash KIO slave watcher is running in KDED. Usually
>>> >> >> it requires a restart of KDED and a kdeinit after installing the
>>> >> >> ioslave to have the Stash daemon running in KDED.
>>> >> >>
>>> >> >> On Thu, Jun 8, 2017 at 3:42 AM, Albert Astals Cid 
>> wrote:
>>> >> >> > El divendres, 26 de maig de 2017, a les 22:55:11 CEST, Arnav Dhamija
>>> >> >> > va
>>> >> >> >
>>> >> >> > escriure:
>>> >> >> >> Hi!
>>> >> >> >>
>>> >> >> >> I had made the kio-stash ioslave last year as part of my GSoC 2016
>>> >> >> >> Project. Now that most of the changes which I wished to make in
>>> >> >> >> Dolphin relevant to the ioslave are part of master, I wish to ship
>>> >> >> >> the
>>> >> >> >> ioslave soon.
>>> >> >> >>
>>> >> >> >> The project is now in KDE review and is awaiting feedback. The link
>>> >> >> >> for the same can be found here:
>>> >> >> >> https://phabricator.kde.org/R247:0f4dc333ac8469b36d1b3a1cedd0a6672a
>>> >> >> >> c90
>>> >> >> >> 7b8
>>> >> >> >>
>>> >> >> >> The source of the project can be found here:
>>> >> >> >> https://cgit.kde.org/kio-stash.git/
>>> >> >> >
>>> >> >> > Can you please get it covered by the CI?
>>> >> >> >
>>> >> >> > I have some of the tests failing but 

Re: Zanshin is in kdereview

[Jonathan Riddell]

On 10 June 2017 at 14:08, Kevin Ottens  wrote:
>> You have a release script in scripts/release.sh, consider using
>> kde:releaseme as extracting translations can be quite faffy and
>> releaseme does all that for you.
>
> I tried that recently but didn't manage to get it to work at all. Failed with
> a backtrace leading to some obscure Ruby dependency and got stuck. Any
> guidance is welcome there, I'm especially interested because of the
> translation extraction bits which I do a bad job at since the beginning...

releaseme shouldn't need any external dependencies except Ruby so post
us the backtrace and I'll take a look

>> On my KDE neon User Edition install if I run Kontact it appears fine
>> but on closing Kontact it crashes, this doesn't happen if I don't have
>> Zanshin installed.

http://paste.ubuntu.com/24841577/

Jonathan

Re: kio-stash is in KDE Review

[Jonathan Riddell]

In the git repo all the files are permission executable, they shouldn't be.

There's no documentation.  I'm unsure how hard a requirement this is these days.

Use title case for name in src/iodaemon/stashnotifier.json

When I use Dolphin to copy a file over I get a dialog daying "Could
not copy.", some more information here might be useful.  The daemon
wasn't loaded.

Dolphin gains a Stash button which splits the view and opens Stash
kioslave.  I'd expect that clicking it again would close the view but
it doesn't. (Dolphin code)

There's no Messages.sh to extract the strings.

Consider asking VDG for a new icon for this in Dolphin, currently it
uses the folder icon which isn't very informative.

Copy of GPL 2 needed in top directory called COPYING.

Use the GPL header with the URL in it rather than postal address so it
doesn't get out of date if FSF moves
https://community.kde.org/Policies/Licensing_Policy#GPL_Header

Nudge the KDE neon developers to add a build to Neon

Jonathan



On 26 May 2017 at 18:25, Arnav Dhamija  wrote:
> Hi!
>
> I had made the kio-stash ioslave last year as part of my GSoC 2016
> Project. Now that most of the changes which I wished to make in
> Dolphin relevant to the ioslave are part of master, I wish to ship the
> ioslave soon.
>
> The project is now in KDE review and is awaiting feedback. The link
> for the same can be found here:
> https://phabricator.kde.org/R247:0f4dc333ac8469b36d1b3a1cedd0a6672ac907b8
>
> The source of the project can be found here: 
> https://cgit.kde.org/kio-stash.git/
>
> Thanks.
>
> --
> arnav dhamija