Re: Default location of the settings file on windows when using KXmlGuiWindow/KMainWindow

[Albert Astals Cid]

El dijous, 7 de desembre de 2017, a les 22:13:21 CET, Alexander Semke va 
escriure:
> Hi all,
> 
> https://bugs.kde.org/show_bug.cgi?id=387626
> we've got this problem reported and I don't see how to easily fix this.
> LabPlot's MainWindow inherits from KXmlGuiWindow. When saving the auto
> settings in KMainWindow, KSharedConfig::openConfig() is used which uses
> QStandardPaths::GenericConfigLocation for the location:
> https://api.kde.org/frameworks/kconfig/html/classKSharedConfig.html#a3282086
> 49f2e3f0ee895c9b11aa82205
> 
> According to the problem description in this ticket, I assume this is a
> valid request since it makes a lot of sense to me, we have to use
> QStandardPaths::AppDataLocation for the location of the config file. Do
> I need to set here KMainWindow::setAutoSettings() with a KConfig having
> the proper name and location? I'd actually expect this to be done by the
> underlying framework(s)...
> 
> We read the settings in many places via KSharedConfig::openConfig()
> which also defaults to the same rc file under
> QStandardPaths::GenericConfigLocation. For all our custom and
> application specific settings we can of course provide AppDataLocation
> explicitely but this also looks to me like not the most optimal solution
> since we'd need to touch the code at many places. How is this handled in
> other KF5-applications? Can somebody share some best practices here?

You may try the kde windows list if noone answers here.

Cheers,
  Albert

> 
> 
> Thanks and Regards,
> Alexander

Re: DownloadDialog for Latte Layouts

[Albert Astals Cid]

El dimecres, 3 de gener de 2018, a les 10:30:49 CET, Michail Vourlakos va 
escriure:
> Hello,
> 
> I am trying to support the KNS3::DownloadDialog in Latte in order for the
> user to be able to download Latte Layouts from store.kde.org from inside
> Latte... But I cant get it to work, the DownloadDialog shows the message
> 
> Could not find category "Latte Layouts"
> 
> or when I change it to 417 based on:
> https://store.kde.org/browse/cat/417/ord/latest/
> 
> Could not find category "417"
> 
> 
> Do you have any ideas what is needed to work?

Without seeing your code is really hard to figure out what's wrong.

Do you have a branch with that code?

Cheers,
  Albert

> 
> 
> regards,
> michail

Re: Looking for mentor for new KDE developer

[Albert Astals Cid]

El dilluns, 8 de gener de 2018, a les 8:15:54 CET, Ben Cooksley va escriure:
> Hi all,
> 
> Just following up on this - is there anyone who is looking into
> helping Christian here?

I don't understand why we're forcing this "he needs a mentor". As Dominik 
says, he seems to know stuff since he actually ported the code.

If he needs help with "kde bureaucracy stuff" it means that we actually need 
to improve our onboarding documentation, so instead of giving him someone he 
can ask things in private, we should try to improve that documentation, or at 
least answer the questions in this list so they are public and can be 
referenced in the future.

I will be happy to answer any question he may have related to that (and 
hopèfully I know the question)

Regarding the "In addition, translations would need to be imported into our 
infrastructure, or recovered from our SVN history. That needs intervention by 
our i18n experts, possibly before the code is imported." that Nicolás 
mentioned, yes, that needs the i18n team helping, but that's what the kde-
i18n-doc mailing list is for, unless the mentor was part of the i18n team that 
wouldn't get solved anyway.

Cheers,
  Albert

> 
> Thanks,
> Ben Cooksley
> KDE Sysadmin

Re: Looking for mentor for new KDE developer

[Albert Astals Cid]

El dilluns, 8 de gener de 2018, a les 0:07:00 CET, Albert Astals Cid va 
escriure:
> El dilluns, 8 de gener de 2018, a les 8:15:54 CET, Ben Cooksley va escriure:
> > Hi all,
> > 
> > Just following up on this - is there anyone who is looking into
> > helping Christian here?
> 
> I don't understand why we're forcing this "he needs a mentor". As Dominik
> says, he seems to know stuff since he actually ported the code.
> 
> If he needs help with "kde bureaucracy stuff" it means that we actually need
> to improve our onboarding documentation, so instead of giving him someone
> he can ask things in private, we should try to improve that documentation,
> or at least answer the questions in this list so they are public and can be
> referenced in the future.
> 
> I will be happy to answer any question he may have related to that (and
> hopèfully I know the question)
> 
> Regarding the "In addition, translations would need to be imported into our
> infrastructure, or recovered from our SVN history. That needs intervention
> by our i18n experts, possibly before the code is imported." that Nicolás
> mentioned, yes, that needs the i18n team helping, but that's what the kde-
> i18n-doc mailing list is for, unless the mentor was part of the i18n team
> that wouldn't get solved anyway.

P.S: I guess that was my long way of saying "i can be his mentor if we really 
need to write someone elses name in the 'who to blame if he screws up' list".

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > Thanks,
> > Ben Cooksley
> > KDE Sysadmin

Re: Kamoso in KDE Applications

[Albert Astals Cid]

El dijous, 11 de gener de 2018, a les 17:01:52 CET, Aleix Pol va escriure:
> Hey,
> I'd like to move it there. It's in extragear/multimedia now and I keep
> forgetting to release as often as I should.
> 
> But the application is working, maintained and developed.
> 
> Thoughts?

I'm not vey happy about the copied code of QtGStreamer.

Why did you decide to copy it?

Cheers,
  Albert

> Aleix

Re: Making Purpose part of KF5

[Albert Astals Cid]

El dijous, 11 de gener de 2018, a les 2:15:06 CET, Aleix Pol va escriure:
> On Thu, Nov 9, 2017 at 5:10 PM, Aleix Pol  wrote:
> > Hi,
> > I would like to include Purpose [1] into the frameworks umbrella.
> > It's been around for a while now, used by few applications and
> > reasonably stable.
> > 
> > Any thoughts?
> > 
> > Aleix
> > 
> > [1] https://phabricator.kde.org/source/purpose/
> 
> So... can I play along?
> Can we take the 3 months of silence as a yes?

Totally, silent acclamation.

Cheers,
  Albert

> 
> Aleix

Re: Kamoso in KDE Applications

[Albert Astals Cid]

El divendres, 12 de gener de 2018, a les 3:51:03 CET, Aleix Pol va escriure:
> On Thu, Jan 11, 2018 at 7:44 PM, Albert Astals Cid  wrote:
> > El dijous, 11 de gener de 2018, a les 17:01:52 CET, Aleix Pol va escriure:
> >> Hey,
> >> I'd like to move it there. It's in extragear/multimedia now and I keep
> >> forgetting to release as often as I should.
> >> 
> >> But the application is working, maintained and developed.
> >> 
> >> Thoughts?
> > 
> > I'm not vey happy about the copied code of QtGStreamer.
> > 
> > Why did you decide to copy it?
> 
> It's unmaintained, I had sent several fixes that went in but never got
> released. So if you used it with master Kamoso worked but stable
> didn't.

Ok so you decided to fork it instead of becoming the upstream maintainer, fair 
enough i guess.

But maybe you should rename
   ./src/elements/gstqtvideosink/CMakeLists.txt:66:install(TARGETS gst$
{QTVIDEOSINK_NAME} DESTINATION ${CMAKE_INSTALL_LIBDIR}/gstreamer-$
{GSTREAMER_ABI_VERSION})
so that it does not conflict with what other distros may be shipping from the 
"real" QtGStreamer ?

Also can you please get a build on https://build.kde.org/ going ?

Cheers,
  Albert

> 
> Aleix

Re: New KDE application

[Albert Astals Cid]

El dimecres, 10 de gener de 2018, a les 23:49:06 CET, Sayan Biswas va 
escriure:
> Hi,

Hi

> 
> A very happy new year to all. Hope you guys are doing good. :)
> 
> Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a
> new application in KDE, and we were hoping to get an opinion on it.
> 
> The central idea behind the app will be to manage the expenses of a
> group of users. As a user, you can create one or more groups, add
> members to them, and add entries for expenses for a given group. You
> can also check the outstanding balances and choose to settle-up with one
> or more members. There will be options for fine-tuning a given entry -
> decide who all have born the total expenditure and by what
> proportions, how should the total expense be divided among the members
> (equally/specific amounts/etc), add pictures for receipts, add
> comments, and so on and so forth.

So somthing like a Splitwise Free Software clone, have you checked if one 
already exists? I know starting is half the fun, but maybe joining an existing 
project that does something similar and help them build a desktop application 
would also be nice.


> We are planning to start off with desktop application with a decentralised
> approach, i.e. the users will hold the data of the shared expenses. Now
> again, there is a possibility of tampering with the expenditure so we might
> need to set a centralised archived or something similar data set to
> maintain the integrity and persistence of a transaction. We are open to
> opinions and discussions for this also. Further to that we will be building
> mobile application for the users ease of usage and add expenditure on the
> go. After all, mobiles are more widely used by user than desktop
> application.
> 
> 
> For settling up we were thinking of integrating some standard payment
> gateways (PayPal, etc) but I am not sure of how much of this
> integration is possible in KDE. 

I don't understand this question, just open a webview to paypal and be done?

> Until then we can just maintain a
> transaction record indicating that members A and B have settled up. We
> were also considering developing a cryptocurrency (we could call it
> KCoin or something) that would serve as a means of payment. Opinions
> are welcome in this particular segment as possibilities can be immense.

There are 1432 cryptocurrencies around, why would you do yet another one?

> 
> As for maintaining the ledgers, we wanted to implement it using
> blockchain, but again, I am not sure if it can be done in KDE, or if
> we have some libraries that support blockchain implementation, etc.

What do you exactly mean by "it can be done in KDE"?

> An application like this comes in handy when a group of people need to
> manage their regular expenses, and we thought it might be a good idea
> to have something similar in KDE. The target audience for this will be
> college groups, work groups, school groups, etc whoever is entitled to
> shared expenditure. We would love to get your feedback, mainly on the
> feasibility of the features mentioned above.

Sure those applications make sense as shown by the millions of free as in beer 
version of them you can find in the mobile appstores, having a Free one 
totally makes sense.

Cheers,
  Albert

> 
> 
> Regards,
> Sayan

Re: Kamoso in KDE Applications

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 4:05:05 CET, Aleix Pol va escriure:
> On Sun, Jan 14, 2018 at 11:31 PM, Albert Astals Cid  wrote:
> > El divendres, 12 de gener de 2018, a les 3:51:03 CET, Aleix Pol va 
escriure:
> >> On Thu, Jan 11, 2018 at 7:44 PM, Albert Astals Cid  wrote:
> >> > El dijous, 11 de gener de 2018, a les 17:01:52 CET, Aleix Pol va 
escriure:
> >> >> Hey,
> >> >> I'd like to move it there. It's in extragear/multimedia now and I keep
> >> >> forgetting to release as often as I should.
> >> >> 
> >> >> But the application is working, maintained and developed.
> >> >> 
> >> >> Thoughts?
> >> > 
> >> > I'm not vey happy about the copied code of QtGStreamer.
> >> > 
> >> > Why did you decide to copy it?
> >> 
> >> It's unmaintained, I had sent several fixes that went in but never got
> >> released. So if you used it with master Kamoso worked but stable
> >> didn't.
> > 
> > Ok so you decided to fork it instead of becoming the upstream maintainer,
> > fair enough i guess.
> > 
> > But maybe you should rename
> > 
> >./src/elements/gstqtvideosink/CMakeLists.txt:66:install(TARGETS gst$
> > 
> > {QTVIDEOSINK_NAME} DESTINATION ${CMAKE_INSTALL_LIBDIR}/gstreamer-$
> > {GSTREAMER_ABI_VERSION})
> > so that it does not conflict with what other distros may be shipping from
> > the "real" QtGStreamer ?
> 
> I did, the code looks a bit weird but I didn't want to change it too
> much from upstream.
> We have this:
> set(QTVIDEOSINK_NAME kamoso-qt5videosink)

Ah, i see.

Ok, personally i don't have any objection to adding yet another app to KDE 
Applications, anyone else has something to comment?

Cheers,
  Albert

> 
> > Also can you please get a build on https://build.kde.org/ going ?
> 
> Yes, just requested it.
> 
> Thanks!
> Aleix

Re: New KDE application

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 13:00:13 CET, Rahul Chowdhury va 
escriure:
> On Mon, Jan 15, 2018 at 5:25 AM, Albert Astals Cid  wrote:
> > El dimecres, 10 de gener de 2018, a les 23:49:06 CET, Sayan Biswas va
> > 
> > escriure:
> >> Hi,
> > 
> > Hi
> 
> Hi,
> 
> >> A very happy new year to all. Hope you guys are doing good. :)
> >> 
> >> Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a
> >> new application in KDE, and we were hoping to get an opinion on it.
> >> 
> >> The central idea behind the app will be to manage the expenses of a
> >> group of users. As a user, you can create one or more groups, add
> >> members to them, and add entries for expenses for a given group. You
> >> can also check the outstanding balances and choose to settle-up with one
> >> or more members. There will be options for fine-tuning a given entry -
> >> decide who all have born the total expenditure and by what
> >> proportions, how should the total expense be divided among the members
> >> (equally/specific amounts/etc), add pictures for receipts, add
> >> comments, and so on and so forth.
> > 
> > So somthing like a Splitwise Free Software clone, have you checked if one
> > already exists? I know starting is half the fun, but maybe joining an
> > existing project that does something similar and help them build a
> > desktop application would also be nice.
> 
> Yes, the idea is very much similar to Splitwise. They do not have any
> desktop version yet.
> We wanted to have some similar free desktop application in KDE.
> 
> >> We are planning to start off with desktop application with a
> >> decentralised
> >> approach, i.e. the users will hold the data of the shared expenses. Now
> >> again, there is a possibility of tampering with the expenditure so we
> >> might
> >> need to set a centralised archived or something similar data set to
> >> maintain the integrity and persistence of a transaction. We are open to
> >> opinions and discussions for this also. Further to that we will be
> >> building
> >> mobile application for the users ease of usage and add expenditure on the
> >> go. After all, mobiles are more widely used by user than desktop
> >> application.
> >> 
> >> 
> >> For settling up we were thinking of integrating some standard payment
> >> gateways (PayPal, etc) but I am not sure of how much of this
> >> integration is possible in KDE.
> > 
> > I don't understand this question, just open a webview to paypal and be
> > done?
> Not just open a webview or redirect to some paypal webpage in a
> browser, but handle the entire transaction from the application itself
> with some third party integration like PayU. If we could integrate one
> or more such payment services/e-wallets with the application and
> handle the paments it would be great.

Honestly, up to you, but opening a webview is easier and more secure, or at 
least you shift the blame to paypal if they have a hackable page. Rolling up 
your own payment code means it's much more easy to make a mistake and get 
hacked like it seems happened to oneplus.

Cheers,
  Albert

Re: KDE and Google Summer of Code 2018

[Albert Astals Cid]

El divendres, 19 de gener de 2018, a les 10:42:44 CET, Marco Martin va 
escriure:
> On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham  wrote:
> > I've submitted an idea for System Settings: Improve handling for touchpads
> > and mice with Libinput
> 
> Speaking of systemsettings, would be a good fit porting to qml some
> medium-to-big kcm?

What's the actual benefit of that porting?

Cheers,
  Albert

> --
> Marco Martin

Re: kdesu - console output and password keeping

[Albert Astals Cid]

El dijous, 18 de gener de 2018, a les 10:44:04 CET, Milian Wolff va escriure:
> Hey all,
> 
> We've recently integrated kdesu into hotspot [1] to be able to record
> profile data as root. This is required to get access to some "advanced"
> performance counters and trace points, most notably the sched:sched_switch
> tracepoint required for off-CPU profiling.
> 
> Now, my colleague originally used kdesudo which doesn't seem to be alive (?)
> upstream. I've seen there's some bzr repo that the kubuntu people seem to
> use. But in KDE proper, only kdesu is available. So I used that instead but
> it has a severe limitation: I cannot show the command output _and_ enable
> password keeping:
> 
> $ man kdesu
> .
>-t
>Enable terminal output. This disables password keeping. This is
> largely for debugging purposes; if you want to run a console mode app, use
> the standard su instead.
> .
> 
> I don't quite get why one would want to use standard su - we want to show a
> graphical dialog to the user and enable password keeping. Can someone
> explain this limitation? Is there some other alternative we could use?

I guess the suggestion would be to use the polkit stuff?

Cheers,
  Albert

> Essentially we run the following command right now, which shows what we
> need to do:
> 
> kdesu -u root -t --attach $winId -- \
> perf record -o $outputfile <...more args...> -- \
> runuser -u $non-root-user -- \
> $userapp $userargs
> kdesu -u root -t --attach $winId --
> chown $non-root-user:$non-root-group $outputfile
> 
> This triggers two password prompts, which is unfortunate I think.
> 
> Thanks
> 
> [1]: https://github.com/KDAB/hotspot

Re: save and restore the geometry of KMainWindow

[Albert Astals Cid]

El dimarts, 30 de gener de 2018, a les 21:06:02 CET, Alexander Semke va 
escriure:
> On 30.01.2018 16:38, Milian Wolff wrote:
> > This works for me:
> > https://github.com/KDAB/hotspot/blob/4d1177d1631902dce1dd82f53553e97a7544b
> > 1fa/ src/mainwindow.cpp#L162
> 
> Thanks, that helped. I was using
> restoreGeometry(group.readEntry("geometry").toLatin1()) instead of
> 
> restoreGeometry(group.readEntry("geometry", QByteArray())) ... Hotspot
> is a nice tool by the way :-)
> 
> Why not to add this logic to KMainWindow and to make this automatically
> available for all/many KDE applications?
> 
> The state is already saved and restored there. Why not to do the same
> for the geometry?

I think that it's generally frowned upon putting your position on screen 
because it means "you know too much".

Basically it's supposed to be the window manager task, not your app.

Also i think that may not work on wayland because of the above reason (can 
easily be wrong)

Cheers,
  Albert

Re: Babe project - Legal feedback

[Albert Astals Cid]

El dissabte, 3 de febrer de 2018, a les 18:07:27 CET, Camilo Higuita Rodriguez 
va escriure:
> Hi,everyone
> 
> I'd like to discuss something with the community, and maybe get some legal
> input:
> 
> As some of you might already know I'm working on a open online platform to
> share music information between users, such as public playlists, comments
> on tracks and on the playback progress like soundcloud, share popular music
> suggestions, metadata, and discovery of new music from another users with
> integration with YouTube and Spotify etc... the platform will be integrated
> into Babe music player and could be use in any other music player
> 
> The legal matter comes here:
> 1- I would like to either have the option to *stream live* the music an
> user is currently listening to to a group of friends. here the music file
> isn't being storaged in the audience computer...
> How ilegal is it? How illegal is to stream live, but privately, copyrighted
> music?  and how illegal is it to stream owns music content to a selected
> group of friends?
> 
> 2- If the stream part wouldn't be enought problem, I'd also like to sync a
> user playlist marked as public to some other friends, that would mean to
> share music files between users, and technically downloading another users
> music files. How illegal is this part? how illegal is to share a music file
> for example, in a conversation in telegram or whatsapp, or even how illegal
> is it to send a mp3 to a friend over an email or even over google drive?
> 
> I'd like to get feedback about this issues.
> 
> As the project is going to be hosted by the KDE community this streaming
> part won't be implemented to avoid legal issues, but however I would like
> to have this discussion to get as many feedback as possible.

I am not sure you're approaching this the right way.

For me it doesn't really matter if users can do illegal stuff with our 
software, what matters is that the software is legal and that it has legal 
uses (see KTorrent).

What I think you should be asking yourself is "will I/KDE be in problems for 
shipping this sofware?" more than "can my user pontentially get in trouble for 
using my sofware to do illegal stuff?".

Cheers,
  Albert

> 
> Thank you.
> 
> Camilo

Re: Babe project - Legal feedback

[Albert Astals Cid]

El dissabte, 3 de febrer de 2018, a les 21:26:24 CET, Nicolás Alvarez va 
escriure:
> 2018-02-03 17:07 GMT-03:00 Albert Astals Cid :
> > El dissabte, 3 de febrer de 2018, a les 18:07:27 CET, Camilo Higuita
> > Rodriguez> 
> > va escriure:
> >> Hi,everyone
> >> 
> >> I'd like to discuss something with the community, and maybe get some
> >> legal
> >> input:
> >> 
> >> As some of you might already know I'm working on a open online platform
> >> to
> >> share music information between users, such as public playlists, comments
> >> on tracks and on the playback progress like soundcloud, share popular
> >> music
> >> suggestions, metadata, and discovery of new music from another users with
> >> integration with YouTube and Spotify etc... the platform will be
> >> integrated
> >> into Babe music player and could be use in any other music player
> >> 
> >> The legal matter comes here:
> >> 1- I would like to either have the option to *stream live* the music an
> >> user is currently listening to to a group of friends. here the music file
> >> isn't being storaged in the audience computer...
> >> How ilegal is it? How illegal is to stream live, but privately,
> >> copyrighted
> >> music?  and how illegal is it to stream owns music content to a selected
> >> group of friends?
> >> 
> >> 2- If the stream part wouldn't be enought problem, I'd also like to sync
> >> a
> >> user playlist marked as public to some other friends, that would mean to
> >> share music files between users, and technically downloading another
> >> users
> >> music files. How illegal is this part? how illegal is to share a music
> >> file
> >> for example, in a conversation in telegram or whatsapp, or even how
> >> illegal
> >> is it to send a mp3 to a friend over an email or even over google drive?
> >> 
> >> I'd like to get feedback about this issues.
> >> 
> >> As the project is going to be hosted by the KDE community this streaming
> >> part won't be implemented to avoid legal issues, but however I would like
> >> to have this discussion to get as many feedback as possible.
> > 
> > I am not sure you're approaching this the right way.
> > 
> > For me it doesn't really matter if users can do illegal stuff with our
> > software, what matters is that the software is legal and that it has legal
> > uses (see KTorrent).
> > 
> > What I think you should be asking yourself is "will I/KDE be in problems
> > for shipping this sofware?" more than "can my user pontentially get in
> > trouble for using my sofware to do illegal stuff?".
> 
> As I understand it, some of these Babe features would involve KDE
> servers; it's not fully peer-to-peer.
> 
> KTorrent is legal and has legal uses, and if its users use it for
> illegal stuff, that's their problem. But if KDE ran a BitTorrent
> tracker on its infrastructure and people used it for copyrighted
> content, would we get in trouble? Even though (like ThePirateBay's
> defense says) trackers don't host or distribute content, just tell
> peers where the other peers are?

That's much more of a dark gray area and I would strongly advise KDE having 
anything to do with servers involved in that.

Cheers,
  Albert

KDE Applications 18.04 release schedule

[Albert Astals Cid]

Hi people, 

So that you know this is the release schedule the release team agreed on.

https://community.kde.org/Schedules/Applications/18.04_Release_Schedule

Cheers,
  Albert

Re: Closing old Plasma 4 bugs

[Albert Astals Cid]

El diumenge, 11 de febrer de 2018, a les 4:06:58 CET, Nate Graham va escriure:
> + kde-devel to widen the conversation
> 
> On 02/10/2018 05:48 PM, Nicolás Alvarez wrote:
> > Meanwhile... maybe you can do some loud blog posts calling for triagers?
> > :)
> 
> Sounds good. Before then, we need to clean up the wiki page for this:
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
> 
> It's thorough and mostly up to date, but huge and intimidating. I've
> been working to improve it, but assistance would be appreciated
> 
> 
> Problem #2: the fact that you need to ask permission before gaining
> write access to other people's hugs is a gigantic blockade to getting
> more community bug triaging. A LibreOffice bug triager came by recently
> and explained that they got an enormous amount more community bug
> triaging by moving away from this policy and only locking down a few
> things (like the priority and assignee, I think) and leaving the rest
> open. He said that in particular it was a big boost to the number of
> bugs (correctly) marked as duplicates and closed as fixed.
> 
> Thoughts?

We could give it a try worst case scenario if we see it doesn't work we can 
always revert, after all worst is we have to reopen/unduplicate some bugs, no?

Cheers,
  Albert

> 
> Nate

Re: Telepathy VS Kopete

[Albert Astals Cid]

El divendres, 23 de febrer de 2018, a les 16:15:03 CET, Valerio Pachera va 
escriure:
> Hi all, I noticed on my debian stretch koped is installed.
> I was expecting to see telepathy.
> 
> Kde plasma 5.8.6 and kde framework 5.28.0.
> 
> Is telepathy the default IM program on kde 5?

I feel this is off topic for kde-devel since this is not a development 
question.

There's no such thing as "default IM program" and there's no such thing as 
"KDE 5".

Best Regards,
  Albert

Re: CI fails to build my last commit in a file I did not change

[Albert Astals Cid]

El dijous, 1 de març de 2018, a les 10:25:51 CET, Michael Heidelbach va 
escriure:
> Hi!
> 
> Applications baloo-widgets kf5-qt5 FreeBSDQt5.9/
>  kf5-qt5%20FreeBSDQt5.9/>
> 
> What to do now?

I think that is because 
https://build.kde.org/view/CI%20Management/job/Dependency%20Build%20Applications%20kf5-qt5%20FreeBSDQt5.9/
failed, i've triggered a new build.

Cheers,
  Albert

> 
> Cheers,
> 
> Michael

Re: Global Dependency and Release Freeze

[Albert Astals Cid]

El divendres, 2 de març de 2018, a les 11:34:30 CET, Ben Cooksley va escriure:
> Hi all,
> 
> Due to a snowball of various dependency bumps and other tickets which
> have been submitted over the past few days, i'm imposing a global
> dependency freeze upon all KDE projects.
> 
> In addition to this, due to the workload these also create, I am also
> imposing a total release freeze on all Extragear projects. Requests
> for tarballs to be released will not be actioned while the freeze is
> imposed. It would be appreciated if people could please hold off on
> filing those.

If you need handling the moving of packages i can lend a hand there since 
AFAIU I already have access to all the places needed.

Cheers,
  Albert

> 
> Sysadmin needs time to catch up and get the CI system back into a
> settled state following changes to Windows and FreeBSD images, in
> addition to sorting out the other tickets we have received over the
> past few days some of which will require some time to deal with.
> 
> Requests for exceptions to these freezes are not available, however we
> will endeavour to lift them as soon as is practicable.
> 
> Regards,
> Ben Cooksley
> KDE Sysadmin

March 15, 2018: KDE Applications 18.04 Dependency Freeze

[Albert Astals Cid]

So what the subject says, get your dependencies in ASAP.

Cheers,
  Albert

Re: Q_ASSERT(!FalseSecurity)

[Albert Astals Cid]

El dissabte, 10 de març de 2018, a les 10:37:12 CET, Sven Brauch va escriure:
> Hi,
> 
> On 03/10/2018 09:53 AM, Michael Heidelbach wrote:
> > Am I getting something wrong? Or is
> > 
> >"Q_ASSERT(m_writeTrans);
> > 
> >m_writeTrans->commit();"
> > 
> > providing false security?
> 
> a lot of KDE code is written this way. It will end up crashing in both
> debug and release, but in debug the message will be clearer. I think
> this makes sense for cases where you think it is very unlikely that the
> condition will not be met. I also think adding the conditional
> everywhere often makes debugging harder because it prevents the crash.

That's the important part, sure, adding an if will make it not crash, but most 
probably it won't do what you wanted either.

So instead of a clear crash that you can get reported and hopefully fixed, you 
get the app misbehaving but it's not so obvious to the user so you may not get 
a report and it may never be fixed.

Cheers,
  Albert

> 
> Best,
> Sven

Re: March 15, 2018: KDE Applications 18.04 Dependency Freeze

[Albert Astals Cid]

El dissabte, 10 de març de 2018, a les 10:41:03 CET, Michael Heidelbach va 
escriure:
> On 10.03.2018 10:39, Albert Astals Cid wrote:
> > So what the subject says, get your dependencies in ASAP.
> > 
> > Cheers,
> > 
> >Albert
> 
> Hi Albert!
> 
> What exactly is a dependency freeze?

Should have included the link, my bad

https://community.kde.org/Schedules/Applications/18.04_Release_Schedule#Thursday.2C_March_15.2C_2018:_KDE_Applications_18.04_Dependency_Freeze

Cheers,
  Albert

> 
> Cheers,
> 
> Michael

Re: Is it possible to mock an external drive (for unit testing)?

[Albert Astals Cid]

El dissabte, 10 de març de 2018, a les 18:27:51 CET, Michael Heidelbach va 
escriure:
> Hi!
> 
> Is it? How?
> 
> Do examples exist?

You'll really need to be more specific, my initial answer would be, why would 
you care if something is a external drive?

Cheers,
  Albert

> 
> 
> Thanks in advance,
> 
> Michael

Re: KF5 Conversion problems

[Albert Astals Cid]

El diumenge, 11 de març de 2018, a les 14:40:56 CET, Robin Atwood va escriure:
> On Sunday 11 March 2018, Michael Pyne wrote:
> > > Yes, but the problem is the /usr/include/kdialog.h when it should be
> > > finding /usr/include/KF5/KDELibs4Support/kdialog.h. I have
> > > find_package(Qt5 Widgets... already.
> > 
> > Sounds like 2 problems I think.
> > 
> > First you need to fix the kdialog.h include in your software (or help
> > us identify where it is broken in the KF5 build system).  Is your build
> > system already looking for KF5::KDELibs4Support, and marking your build
> > target as depending on that library?
> > 
> > Even with this incorrect kdialog, you would think it would still find
> > the right QDialog though.  That's why it sounds like there's 2 problems.
> > I think the issue here is that there is no longer a QtGui/QDialog.  The
> > right path would be in QtWidgets/QDialog with Qt5.  It's better (and now
> > recommended) just to use a '#include ' (and in general,
> > #include ).
> 
> I added KF5::KDE4Support to the target link libraries and that problem went
> away. This raises the problem: how do I know which link libraries I need? Is
> there a list of dependencies somewhere?

That's kind of a weird question.

You know which libraries you need to link to because you're using classes that 
reside in them.

How do i know that I need to link to QtWidget? 
Because you're using QLabel and the documentation says so.

How do you know that I need to link to KConfigWidgets?
Because you're using KColorScheme and the documentation says so.

Cheers,
  Albert


> 
> Thanks
> Robin

Re: Would it be good if I became baloo's maintainer?

[Albert Astals Cid]

El dijous, 15 de març de 2018, a les 9:40:34 CET, Michael Heidelbach va 
escriure:
> Hi!
> 
> Getting the stuff I do for baloo reviewed takes a lot of time and poking
> others. That is considerably slowing me down.
> 
> I'm seriously thinking of becoming the maintainer for baloo (and maybe
> baloowidgets). Then it would be easier for me to commit those patches I
> consider as harmless e.g unit tests. Unless somebody else jumped in I
> intended to maintain baloo eventually anyway. I would do it now(!)
> mainly for practical reasons. Due to my lack of experience with c++, the
> KDE way of using it and the KDE infrastructure in general I'm somewhat
> reluctant. Questions arise:
> 

I don't think we really have this codified anywhere so this are *my* answers, 
not KDE's

>   * What exactly does it mean to be the maintainer of a project and what
> tasks come with it?

You'll be "the project manager", meaning people expect you to know answer 
questions (or find someone to answer them), review patches (or find someone to 
review them), triage/fix bugs (or find someone to triage/fix them), i.e. 
basicaly you say "i will take responsability of getting this in reasonable 
shape either by doing it myself or getting people to do it" and do the boring 
stuff.

>   * What responsibilities come with it?

You commit to do the above stuff.

>   * How is that done practically?

You say "I'm the maintainer now" and noone else disagrees. i.e. it's mostly 
peoples agreement that make you the maintainer, not you claiming to be. And if 
there's a aboutdata line in the main.cpp you flip yourself from developer to 
maintainer (take into account the i18n freezes)

>   * Do you think it's a good idea to have a newbie maintaining a project
> as deeply integrated into KDE as baloo?

The newbie-ness is not a critical factor (it is important of course), the 
important part is "do you want to become the maintainer because you like the 
title?" then you're not a good candidate. Also you need to make sure of 
knowing our procedures a bit, and making sure you don't become "crazy with 
power" and start doing things that you wouldn't be doing before. Basically 
being the maintainer doesn't give you "more power", just gives you "more 
responsability", not sure if that makes sense.

>   * What should be my general attitude towards that task?

I am not sure i understand this question, but the general "be nice with 
people" applies for "attitude"

> 
> 
> Please give me your advice,

Hope the answers made sense :)

Cheers,
  Albert

> 
> Michael

KDE Applications 18.04 branches created

[Albert Astals Cid]

Make sure you commit anything you want to end up in the 18.04 release to them 
:)

We're already past the dependency freeze.

The Freeze and Beta is this Thursday 22 of March.

More interesting dates
 April 5: KDE Applications 18.04 RC (18.03.90) Tagging and Release
 April 12: KDE Applications 18.04 Tagging
 April 19: KDE Applications 18.04 Release

https://community.kde.org/Schedules/Applications/18.04_Release_Schedule

Cheers,
  Albert

Re: major memory leak

[Albert Astals Cid]

El dilluns, 26 de març de 2018, a les 21:40:18 CEST, Jonathan Willis va 
escriure:
> I couldn't find a bug ticket service for kde plasma development, so
> apologies if this is the wrong place.

bugs.kde.org

Re: AMOR maintenance

[Albert Astals Cid]

El dimecres, 28 de març de 2018, a les 2:04:40 CEST, Stefan Yohansson va 
escriure:
> Hi guys,
> 
> I recently opened an AMOR diff review and ask about the maintainer on irc
> but no one knows who is maintaining and I think the project is orphan right
> now. (correct me if I am wrong)
> 
> here is my patch: https://phabricator.kde.org/D11475
> 
> I have several themes for AMOR and a lot of ideas like include a theme
> manager (like another kde applications)
> 
> so if you guys think it is a good idea, I am able to maintain the project.
> Just let me know what should I do.
> 
> btw, thanks for all the good work on KDE framework.

I've added David and Dan to the review since they are the ones that touched 
the code recently, if you don't get any answer from them in say a week please 
answer here again and let's see what we can do.

Cheers,
  Albert

Re: Trouble with tool bars

[Albert Astals Cid]

El divendres, 30 de març de 2018, a les 17:36:32 CEST, Robin Atwood va 
escriure:
> My first KDE4 to KF5 port has gone well and the app now compiles and runs
> without any warning messages. :) However, I am now trying to improve some
> things. I have a tool bar which is created by the XML support:
> 
> 
> 
>   
>   
> 
> 
> 
>   Filter Toolbar
> 
> 
> 
> 
> I want to add a short-cut to one of the tool bars but I don't have a QAction
> for it. I tried listing the contents of actionCollection()->actions() but
> neither of the tool bars appeared. How do I find the QAction?

QAction for what? showing/hiding the toolbar?

> 
> Secondly I want to give a line-edit widget in one of the tool bars focus
> when the bar becomes visible, so I tried:
> 
> connect( toolBar( fTB ), &KToolBar::visibilityChanged, this,
> &KmTail::toolBarVisible );
> 
> There are no runtime warning messages but the slot is never driven. What am
> I missing?

Is the code available somewhere online? Much easier to try to help you if we 
can look at it.

Cheers,
  Albert

> 
> Thanks
> Robin

Re: Unable to compile KWidgetsAddons

[Albert Astals Cid]

El dijous, 29 de març de 2018, a les 15:53:25 CEST, Nate Graham va escriure:
> In trying to test out a KWidgetsAddons patch, I find that I'm unable to
> compile it on KDE Neon dev unstable the code due to a CMake error:

Have you tried a clean build?

Cheers,
  Albert


> 
> 
> CMake Error in autotests/CMakeLists.txt:
>No known features for CXX compiler
> 
>"GNU"
> 
>version 5.4.0.
> 
> Full output available at https://paste.kde.org/piyy4wsnl
> 
> 
> My g++ version looks okay:
> 
> $ g++ --version
> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
> Copyright (C) 2015 Free Software Foundation, Inc.
> 
> 
> Nate

Re: Unable to compile KWidgetsAddons

[Albert Astals Cid]

El dissabte, 31 de març de 2018, a les 22:56:26 CEST, Nate Graham va escriure:
> On 03/31/2018 02:55 PM, Albert Astals Cid wrote:
> > El dijous, 29 de març de 2018, a les 15:53:25 CEST, Nate Graham va 
escriure:
> >> In trying to test out a KWidgetsAddons patch, I find that I'm unable to
> > 
> >> compile it on KDE Neon dev unstable the code due to a CMake error:
> > Have you tried a clean build?

Can you paste.kde.org the full log?

Cheers,
  Albert

> 
> Yes.
> 
> Nate

Re: Unable to compile KWidgetsAddons

[Albert Astals Cid]

El dissabte, 31 de març de 2018, a les 23:16:12 CEST, Nate Graham va escriure:
> On 03/31/2018 03:05 PM, Albert Astals Cid wrote:
> > El dissabte, 31 de març de 2018, a les 22:56:26 CEST, Nate Graham va 
escriure:
> >> On 03/31/2018 02:55 PM, Albert Astals Cid wrote:
> >>> El dijous, 29 de març de 2018, a les 15:53:25 CEST, Nate Graham va
> > 
> > escriure:
> >>>> In trying to test out a KWidgetsAddons patch, I find that I'm unable to
> >>> 
> >>>> compile it on KDE Neon dev unstable the code due to a CMake error:
> >>> Have you tried a clean build?
> > 
> > Can you paste.kde.org the full log?
> 
> https://paste.kde.org/pjqbr1rvr

That is not a full log from a clean build.

Cheers,
  Albert

> 
> Nate

Re: Unable to compile KWidgetsAddons

[Albert Astals Cid]

El dissabte, 31 de març de 2018, a les 23:30:31 CEST, Nate Graham va escriure:
> On 03/31/2018 03:28 PM, Albert Astals Cid wrote:
> > El dissabte, 31 de març de 2018, a les 23:16:12 CEST, Nate Graham va 
escriure:
> >> On 03/31/2018 03:05 PM, Albert Astals Cid wrote:
> >>> El dissabte, 31 de març de 2018, a les 22:56:26 CEST, Nate Graham va
> > 
> > escriure:
> >>>> On 03/31/2018 02:55 PM, Albert Astals Cid wrote:
> >>>>> El dijous, 29 de març de 2018, a les 15:53:25 CEST, Nate Graham va
> >>> 
> >>> escriure:
> >>>>>> In trying to test out a KWidgetsAddons patch, I find that I'm unable
> >>>>>> to
> >>>>> 
> >>>>>> compile it on KDE Neon dev unstable the code due to a CMake error:
> >>>>> Have you tried a clean build?
> >>> 
> >>> Can you paste.kde.org the full log?
> >> 
> >> https://paste.kde.org/pjqbr1rvr
> > 
> > That is not a full log from a clean build.
> 
> Well, I don't get to the build part because this is an error in cmake.

I'm asking for the full cmake log after cleaning your build directory, because 
the first line of a cmake log should be

(kdesrc) tsdgeos@xps:~/devel/kde/kwidgetsaddons/build:master$ cmake ..
-- The C compiler identification is GNU 7.3.1

not 

--

Looking at your cmake log i'm 97% sure it's not a clean build directory you're 
using.

Cheers,
  Albert

> 
> Nate

Re: Trouble with tool bars

[Albert Astals Cid]

El diumenge, 1 d’abril de 2018, a les 16:00:09 CEST, Robin Atwood va escriure:
> On Sunday 01 April 2018, Albert Astals Cid wrote:
> > El divendres, 30 de març de 2018, a les 17:36:32 CEST, Robin Atwood va
> > 
> > escriure:
> > > I want to add a short-cut to one of the tool bars but I don't have a
> > > QAction for it. I tried listing the contents of
> > > actionCollection()->actions() but neither of the tool bars appeared. How
> > > do I find the QAction?
> > 
> > QAction for what? showing/hiding the toolbar?
> 
> I want to add a shortcut and connect to the triggered() signal. I tried
> adding my own menu action to show/hide the toolbar but then I still get a
> duplicate action under "Toolbars Shown" which is automatically generated.
> Can that be suppressed? Doco for kpartgui seems a bit sparse and some
> attributes (noEdit, shortcut) don't seem to do anything.

I guess the code is your documentation at that point if you think things 
aren't working.

Cheers,
  Albert

> 
> Thanks
> Robin

Re: Can a GSoC 2018 student attend Akademy 2018?

[Albert Astals Cid]

El dimarts, 24 d’abril de 2018, a les 18:00:40 CEST, Dileep Sankhla va 
escriure:
> Thank you. So if not cfp, how can I participate at Akademy ?

You attend and learn like everyone else does

> I can't decide
> the dates and the events there.

https://akademy.kde.org/2018/program

> Secondly, I can't get a link to form to submit for travel reimbursement.
> May you please explain the process a little bit?

https://mail.kde.org/pipermail/kde-community/2017q4/004211.html

> 
> Thanks
> Dileep
> 
> On Apr 24, 2018 20:53, "Stefan Derkits"  wrote:
> > Hi Dileep,
> > 
> > On 2018-04-24 17:06, Dileep Sankhla wrote:
> > > I am a GSoC 2018 student under KDE Community and I want to attend
> > > Akademy 2018 to be held in Vienna, Austria from 11-17 August. I have
> > > checked the webpage and found that the last date for proposal has been
> > > passed away (March 12).
> > 
> > That was the end date for the CfP.
> > 
> > > Is it still possible to attend Akademy during GSoC period (final mentor
> > > evaluation phase) with travel reimbursement?
> > 
> > The first round for travel support is already over, but there is gonna
> > be a second round, with a deadline of 31st of May.
> > Until then you can still apply for Travel Support at
> > https://reimbursements.kde.org/
> > 
> > Stefan

Re: kcm-grub2 on kf5

[Albert Astals Cid]

El dilluns, 14 de maig de 2018, a les 14:27:26 CEST, Alexander Volkov va 
escriure:
> 14.05.2018 14:32, Luigi Toscano пишет:
> > Jonathan's answer says everything, the tl;dr version is: it's up to you.
> > Right now kcm-grub2 is an application with its own release cycle (what was
> > knows as "extragear").
> > 
> > Did you contact the old maintainer just to check if he is still interested
> > with helping?
> 
> Thanks for the help.
> I just sent him an email.
> Unfortunately, I did not notice that there is a kf5 fork of kcm-grub2:
> https://github.com/maz-1/grub2-editor
> Now the question is which one is preferable?

You're working with upstream, he is not, so yours is better, but maybe you 
want to contact him so he can work with you on the upstream version?

Cheers,
  Albert

Re: Stepping down as maintainer for breeze/oxygen kstyle and deco

[Albert Astals Cid]

El diumenge, 3 de juny de 2018, a les 21:20:29 CEST, Hugo Pereira Da Costa va 
escriure:
> Title says it all.
> 
> No need for long explanations, I am just not enjoying it any more.
> Time to move on, sorry.

Thanks for all the work you did.

Hope you enjoy the next thing :)

Cheers,
  Albert

> 
> Best of luck,
> 
> Hugo

Re: Removing code from kdeexamples dir

[Albert Astals Cid]

El diumenge, 10 de juny de 2018, a les 8:23:43 CEST, Luiz Romário Santana Rios 
va escriure:
> From what I can see, the kdeexamples repo is mostly unmaintained (the
> last useful commit dates back to 2014), the master branch only
> contains KDE 4 code and the frameworks-scratch branch is just as
> ancient.
> 
> I propose the following:
> 1. Create a branch (or tag) called master-unmaintained, master-old or
> whatever you prefer, pointing to the current HEAD
> 2. Obliterate everything from the repo, leaving only a
> 
> README.unmaintained file, reading:
> > This repository is unmaintained. To see the code, checkout the
> > master-unmaintained branch
> Most (if not all) the examples would have to be deleted anyway if
> someone wanted to revive this repo, so I say we don't have a lot to
> lose in terms of git history either.
> 
> Opinions?

You don't need a branch, you can just remove everything and tell people the 
hash they can checkout if they're interested in kdelibs4 code.

Ideally we would have a maintained kdeexamples dir, but since we don't your 
solution seems sensible.

Also ask sysadmins to move it to the "virtual" unmaintained module, though 
maybe it is already.

Cheers,
  Albert

KDE Applications 18.08 release schedule

[Albert Astals Cid]

Hi people, 

So that you know this is the release schedule the release team agreed on.

https://community.kde.org/Schedules/Applications/18.08_Release_Schedule

Cheers,
  Albert

Re: Adding Kirigami Gallery to kde-sdk

[Albert Astals Cid]

El diumenge, 24 de juny de 2018, a les 1:18:45 CEST, David Edmundson va 
escriure:
> What would be the situation for releases?

If it's part of kdesdk gets released with KDE Applications like all the other 
kdesdk repos.

Cheers,
  Albert

Limiting who can create v${NUMBER}.${NUMBER}.${NUMBER} tags in KDE Applications git repos

[Albert Astals Cid]

Hi, would anyone be against limiting who can create 
v${NUMBER}.${NUMBER}.${NUMBER}
i.e. tags that look like our release tags to members of the release team for 
the KDE Applications git repositories?

Rationale: Some distros build from git tags so creating a "release looking 
tag" is for them like "using the release tarball" and we already limit who can 
upload release tarballs to the download.kde.org so it would be a similar 
restriction but for the git side.

Cheers,
  Albert

KDE Applications 18.08 branches created

[Albert Astals Cid]

Make sure you commit anything you want to end up in the 18.08 release to them 


We're already past the dependency freeze.

The Freeze and Beta is this Thursday 19 of July.

More interesting dates
 August  2: KDE Applications 18.08 RC (18.07.90) Tagging and Release
 August  9: KDE Applications 18.08 Tagging
 August 16: KDE Applications 18.08 Release

https://community.kde.org/Schedules/Applications/18.08_Release_Schedule

Cheers,
  Albert

Re: strange behavior of KCookieServer

[Albert Astals Cid]

El divendres, 13 de juliol de 2018, a les 17:20:10 CEST, Stefano Crocco va 
escriure:
> Hello to everyone,

Hi, given that KCookieServer is part of the KIO framework I am suggesting you 
resend this email to kde-frameworks-de...@kde.org where the KIO people are more 
prone to read this.

Cheers,
  Albert

> in my ongoing attempt to integrate Konqueror and QWebEngine, I'm still 
> struggling with a way to share cookies between QWebEngineCookieStore and 
> KCookieServer. While investigating this issue, I found a problem when adding 
> cookies to KCookieServer by hand which doesn't seem happen when using 
> Konqueror with either KHTML or KWebKitPart. I think I know how I could solve 
> (or work around) this issue but I don't understand why it's happening and I'd 
> like some insight about this.
> 
> The isssue I noticed concerns cookies with an "expire" field and I believe, 
> after looking at the code for KCookieJar and KCookieServer, it is related to 
> time zone handling by KCookieJar.
> 
> I live in Italy, so my time zone is CEST, which (unless I'm mistaken) means 
> GTM+2. If now (16:30 CEST, 14:30 GMT), a web page sent me a cookie which 
> should expire in 30 minutes (17:00 CEST, 15:00 GMT), it would have an 
> "expires" field like "expires: Fri, 13-Jul-2018 15:00:00 GMT".
> 
> I tried to add such a cookie from the command line, like this:
> 
> qdbus org.kde.kcookiejar5 /modules/kcookiejar addCookies http://xyz.it "Set-
> Cookie: test=hello; expires=Fri, 13-Jul-2018 15:00:00 GMT; domain=.xyz.it; 
> path=/" 0
> 
> but in the cookies page in System Settings doesn't show the cookie. If I 
> change the "expires" field in the cookie so that the hour becomes 17:00:00, 
> the 
> cookie is added.
> 
> The problem, I believe, is that KCookieJar::parseDate calls 
> QLocale::toDateTime, which seems to create a QDateTime with the local time 
> zone (in my case, CEST). This means that the cookie expire date, which was in 
> GMT, is interpreted as if it were in CEST and, of course, the cookie is 
> considered expired.
> 
> Thanks in advance for any help in understanding what's happening.
> 
> Stefano
> 
> 
> 

Re: Arch Linux Update Notifier for KDE

[Albert Astals Cid]

El diumenge, 15 de juliol de 2018, a les 19:49:06 CEST, Michael Harris va 
escriure:
> Hey all I wanted to help generate awareness for an Update Notifier plasmoid 
> for Arch Linux and possibly create an online blog post to help people know 
> about it.

Hey!

I wanted to give you some comment on the content of the page.

You're calling the software "KDE Plasmoid" in two places in Readme.md

Given that KDE is a group of people (from kde.org) by calling it "KDE Plasmoid" 
it may give the impression that is actually a Plasmoid written by the KDE 
people themselves.

I would like to suggest that you change that "KDE Plasmoid" to just "Plasmoid", 
what do you think?

Also in the "Requires:" section you write "KDE desktop environment", which is 
correct, as it needs a desktop environment written by KDE, but not as accurate 
as possible.

I would like to suggest that you change that "KDE desktop environment" to 
"Plasma desktop environment", what do you think?

On the code side, are you thinking about enabling this for translations? I see 
you're missing a few i18n calls.

Cheers,
  Albert

> 
> For those who don't know Arch Linux has you manually upgrade packages through 
> the terminal.
> 
> My Plasmoid is a front end for it.
> 
> You can checkout my github page for screenshots and more information.
> 
> https://github.com/I-Dream-in-Code/kde-arch-update-plasmoid
> 
> Current Features:
> 
> * change refresh interval
> * turn version numbers on and off
> * show upgrade in konsole or yakauke
> * AUR support
> * Custom Icon Support
> 
> This affects not just Arch Linux itself but Arch-based distributions. 
> 
> 
> 
> 

Re: Adding Kirigami Gallery to kde-sdk

[Albert Astals Cid]

El dijous, 9 d’agost de 2018, a les 12:06:18 CEST, Luigi Toscano va escriure:
> Albert Astals Cid ha scritto:
> > El diumenge, 24 de juny de 2018, a les 1:18:45 CEST, David Edmundson va
> > escriure:
> >> What would be the situation for releases?
> > 
> > If it's part of kdesdk gets released with KDE Applications like all the 
> > other
> > kdesdk repos.
> 
> kirigami-gallery was added to kdesdk in sysadmin/repo-metadata, but it's not 
> yet in the list of the modules officially shipped as part of KDE Applications 
> (sysadmin/release-tools).
> 
> Do we have a final decision on this?

uh oh.

So there's no packages for it for KDE Applications 18.08 being released next 
week.

Marco, is it fine for you if we get it out with 18.12 or you really wanted to 
be in 18.08?

Cheers,
  Albert

> 
> Ciao
> 

Re: Adding Kirigami Gallery to kde-sdk

[Albert Astals Cid]

I talked with Marco at akademy and he says it's fine not to include it for
KDE Applications 18.08.

Cheers,
  Albert

El dj., 9 ag. 2018 , 23:14, Albert Astals Cid  va escriure:

> El dijous, 9 d’agost de 2018, a les 12:06:18 CEST, Luigi Toscano va
> escriure:
> > Albert Astals Cid ha scritto:
> > > El diumenge, 24 de juny de 2018, a les 1:18:45 CEST, David Edmundson va
> > > escriure:
> > >> What would be the situation for releases?
> > >
> > > If it's part of kdesdk gets released with KDE Applications like all
> the other
> > > kdesdk repos.
> >
> > kirigami-gallery was added to kdesdk in sysadmin/repo-metadata, but it's
> not
> > yet in the list of the modules officially shipped as part of KDE
> Applications
> > (sysadmin/release-tools).
> >
> > Do we have a final decision on this?
>
> uh oh.
>
> So there's no packages for it for KDE Applications 18.08 being released
> next week.
>
> Marco, is it fine for you if we get it out with 18.12 or you really wanted
> to be in 18.08?
>
> Cheers,
>   Albert
>
> >
> > Ciao
> >
>
>
>
>
>

Re: Port Kppp to Qt5

[Albert Astals Cid]

 Apparently network/modem manager can't replace kppp just yet it 
seemshttps://bugzilla.gnome.org/show_bug.cgi?id=348330
We had one user at least saying he needed 
ithttps://mail.kde.org/pipermail/kde-gardening/2017-July/000142.html
Do you use kppp?
Because if you don't, I am afraid that given how "hardware dependant" kppp is, 
doing "it compiles" porting may not be good enough.
Cheers,  Albert

En lunes, 13 de agosto de 2018 8:37:08 CEST, Sergio Carlavilla 
 escribió:  
 
  
Hi,

I want to know if port Kppp to Qt5 is useful or the functionality are 
integrated in plasma-nm.

Bye.
   

Re: network connectivity with proxy

[Albert Astals Cid]

El divendres, 14 de setembre de 2018, a les 18:04:59 CEST, Thiago Macieira va 
escriure:
> On Wednesday, 12 September 2018 04:17:35 PDT Harald Sitter wrote:
> > If I am not mistaken Qt already looks in the environment variables for
> > http_proxy, https_proxy etc. etc. (I don't think Plasma sets those
> > from the KCM though). To that end a no-code solution is setting those.
> > Obviously that's not very integrated in plasma.
> 
> The correct way is to configure your system properly. Qt will use libproxy 
> and 
> will get the settings.

So this should be a bug reported against systemsettings or kded or something 
then?

Cheers,
  Albert

Re: auto QString(Builder) considered VERY HARMFUL -> use clazy, especially before releases

[Albert Astals Cid]

El dijous, 27 de setembre de 2018, a les 21:01:13 CEST, Friedrich W. H. 
Kossebau va escriure:
> Am Donnerstag, 27. September 2018, 20:08:54 CEST schrieb Andreas Hartmetz:
> > Today I fixed the third or so crash in KDE software due to the following
> > pattern:
> > 
> > const auto str = someString + anotherString;
> > 
> > What happens is that the type of str ends up being QStringBuilder
> > instead of QString. The QStringBuilder is destroyed after the semicolon,
> > and all access to "str" produces undefined behavior.
> 
> The QStringBuilder actually survives as long as str is in scope, but the 
> references it potentially takes from someString or anotherString (if e.g. 
> some 
> temporary QString object as returned from QStringLiteral or other QString-
> returning methods) will be no longer valid after the scope of the expression 
> is left.
> So if str is finally resolved to a real QString, those references are 
> dangling 
> and non-funny things happen.
> 
> > While I'm not a particularly big fan of using auto to hide variable
> > types anyway, this kind of usage is just wrong and must be avoided.
> > Please take care.
> 
> Care can be done e.g. by deploying clazy with auto-unexpected-qstringbuilder:
> 
> clazy-standalone \
>   -checks=auto-unexpected-qstringbuilder  -p   
> 
> See
> https://phabricator.kde.org/source/clazy/browse/master/docs/checks/README-auto-unexpected-qstringbuilder.md?as=remarkup
> https://phabricator.kde.org/source/clazy/browse/master/README.md?as=remarkup
> 
> One would recommend to run clazy over your code at least before releases, to 
> catch all kind of potential issues :)

Or since this is a crasher, just run your app and it'll crash?

Or even better, add autotests that exercise the code and they'll crash too?

Cheers,
  Albert

> 
> Cheers
> Friedrich
> 
> 
> 

KDE Applications 18.12 release schedule

[Albert Astals Cid]

Hi people, 

So that you know this is the release schedule the release team agreed on.

https://community.kde.org/Schedules/Applications/18.12_Release_Schedule

Dependency freeze is in *two* weeks and feature free one after that. Get your 
stuff ready!

Cheers,
  Albert

KDE Applications 18.12 branches created

[Albert Astals Cid]

Make sure you commit anything you want to end up in the 18.12 release to them 

We're already past the dependency freeze.

The Freeze and Beta is this Thursday 15 of November.

More interesting dates
 November 29: KDE Applications 18.12 RC (18.11.90) Tagging and Release
 December  6: KDE Applications 18.12 Tagging
 December 13: KDE Applications 18.12 Release

https://community.kde.org/Schedules/Applications/18.12_Release_Schedule

Cheers,
  Albert

Re: Question about KNewStuff *.knsrc files and manualy installation

[Albert Astals Cid]

El dimecres, 21 de novembre de 2018, a les 17:36:47 CET, Никита Сиргиенко va 
escriure:
> For example, we have KDE Aplication program with knsrc files for
> KNS3::DownloadDialog (from KHotNewStuff - KDE Framework).
> Acording to documentation (
> https://api.kde.org/frameworks/knewstuff/html/classKNS3_1_1DownloadDialog.html,
> "Detailed Description")  KNewStuff searchs knsrc files only in /etc/xdg
> directory.
> It works good for packages from repository, because in this case, if we
> install knsrc files using KDE_INSTALL_CONFDIR, in package the files will be
> in /etc/xdg.
> But, if we build and install the program from source, we have some
> problems: we could don't change CMAKE_INSTALL_PREFIX (/usr/local/ by
> default) or change it to /opt, for example. And in this cases
> KDE_INSTALL_CONFDIR will be different from /etc/xdg.
> And DownloadDialog can't found our knsrc files.
> So, anyone know good solution for this problem, except obvious passing
> cmake the confdir variable to code as preprocessor variable and using
> dialog constructor with  path to configuration file?

Install to whatever prefix you want and just define XDG_CONFIG_DIRS to it.

Or just source the prefix.sh file created on your build dir that already sets 
that environment variable correctly.

Cheers,
  Albert

> 
> Best Regards,
> Nikita
> 

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Albert Astals Cid]

El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va 
escriure:
> On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote:
> > Can't you just configure the CI to use Qt 5.10? I think it's not good to
> > hardcode an "overzealous" (for lack of a better word) Qt version in
> > projects that don't require them AND I think that one should support the
> > current LTS release in as many projects as possible as a general rule of
> > principle.
> > 
> > There's a reason why those LTS releases exist and that should probably be
> > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why
> > kdelibs4 was split up)!
> 
> Which is exactly why 5.11.3 (released today) should be picked. It contains 
> all 
> fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to 
> 5.10.1 means regressing all those fixes.

It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10.

Of course users should be using 5.11.3, but that's a different story.

Cheers,
  Albert

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Albert Astals Cid]

El dimarts, 4 de desembre de 2018, a les 20:13:43 CET, Ben Cooksley va escriure:
> On Wed, Dec 5, 2018 at 7:22 AM Albert Astals Cid  wrote:
> >
> > El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va 
> > escriure:
> > > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote:
> > > > Can't you just configure the CI to use Qt 5.10? I think it's not good to
> > > > hardcode an "overzealous" (for lack of a better word) Qt version in
> > > > projects that don't require them AND I think that one should support the
> > > > current LTS release in as many projects as possible as a general rule of
> > > > principle.
> > > >
> > > > There's a reason why those LTS releases exist and that should probably 
> > > > be
> > > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why
> > > > kdelibs4 was split up)!
> > >
> > > Which is exactly why 5.11.3 (released today) should be picked. It 
> > > contains all
> > > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to
> > > 5.10.1 means regressing all those fixes.
> >
> > It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10.
> >
> > Of course users should be using 5.11.3, but that's a different story.
> 
> So you'd prefer we move to Qt 5.10 then, and then do another move to
> 5.11 when Frameworks moves it's bar up?

Personally, yes, it's much easier to detect apps requiring 5.11 API when they 
don't pretend to (not sure there's much new api in 5.11 but anyhow). I mean in 
an ideal world we'd compile each app with their required min Qt version to 
detect those things, but since that's not possible with the current setup let's 
settle for the smallest possible version.

And Frameworks requiring 5.11 is still kind of far no?

Cheers,
  Albert

> 
> >
> > Cheers,
> >   Albert
> >
> >
> 
> Regards,
> Ben

Re: [QUESTION] KIO slave-socket shortcut - does it exist?

[Albert Astals Cid]

El dimarts, 4 de desembre de 2018, a les 16:37:34 CET, Smits Katze va escriure:
> Background: I want to sandbox KDE apps and need to understand better how
> KIO works.
> 
> My current level of understanding is that apps ask klauncher/kdeinit for a
> KIO slave if they need one. Then either kdeinit spawns a new slave process,
> or there is already an idle slave and it is reused. Idle slaves kill
> themselves after a couple of minutes if no request is coming in.
> Communication between the slave and the app happens via a socket, usually
> to find in /run/user/$UID.
> 
> The question is if, or rather when, it is possible to shortcut this
> process. Do slaves, especially idle ones, accept commands issued by third
> programs via these sockets? Try to take the perspective of an evil-minded
> adversary.

Do you mean this as a security issue?

Albert

> 
> Thank you very much!
> 

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Albert Astals Cid]

El dimecres, 5 de desembre de 2018, a les 19:38:12 CET, Allan Sandfeld Jensen 
va escriure:
> On Dienstag, 4. Dezember 2018 18:10:44 CET Thiago Macieira wrote:
> > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote:
> > > Can't you just configure the CI to use Qt 5.10? I think it's not good to
> > > hardcode an "overzealous" (for lack of a better word) Qt version in
> > > projects that don't require them AND I think that one should support the
> > > current LTS release in as many projects as possible as a general rule of
> > > principle.
> > > 
> > > There's a reason why those LTS releases exist and that should probably be
> > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why
> > > kdelibs4 was split up)!
> > 
> > Which is exactly why 5.11.3 (released today) should be picked. It contains
> > all fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7
> > to 5.10.1 means regressing all those fixes.
> 
> Yeah, the only sensible option is to support the last LTS release and the 
> latest non-LTS release. Moving from 5.9 to 5.10 is backwards, and kdepim 
> moving to an insecure unsupported Qt version should not be encouraged.

Nobody is moving to an insecure unsupported Qt version.

Albert

> 
> 'Allan
> 
> 

Re: Contributing

[Albert Astals Cid]

El divendres, 7 de desembre de 2018, a les 10:42:12 CET, Jonathan Aquilina va 
escriure:
> Check out tux kart

When someone asks for "any KDE game", tux kart is not the answer.

The answer is games.kde.org and kde-games-de...@kde.org mailing list.

Cheers,
  Albert

> 
> Sent from my iPhone
> 
> > On 07 Dec 2018, at 00:01, Filip Sasic  wrote:
> > 
> > Hi everyone,
> > I got an university assignment to contribute to open source game project.I 
> > was wandering if anyone could recommend me any KDE game project that needs 
> > improving or refer me to someone I could talk directly about this. 
> > Thanks in advance.
> > P.S. sorry if this isn't right place for this, I am new here  
> 

Re: Kleopatra devel

[Albert Astals Cid]

El divendres, 7 de desembre de 2018, a les 17:01:54 CET, Luc Lalonde va 
escriure:
> Hello,
> 
> I would like to help with development with the Kleopatra/GPG4win project.

If noone answers here try at the kdepim mailing list

https://mail.kde.org/mailman/listinfo/kde-pim

Cheers,
  Albert

> 
> Would there be someone available for mentoring as this is the first time
> I get involved in a KDE project.
> 
> Thank You!
> 
> 

Re: Kopete and Libjingle

[Albert Astals Cid]

El divendres, 14 de desembre de 2018, a les 17:19:26 CET, Jonathan Riddell va 
escriure:
> 
> This patch needs tested for Kopete
> https://phabricator.kde.org/D13231
> 
> But I don't know how to test it.  Does anyone use jabber and video 
> conferencing through it with libjingle?
> 
> I signed up for accounts at this server
> https://jabber.hot-chilli.net/forms/create/ and I can send messages
> from Kopete but messages don't arrive in Kopete when sent from their
> web client.  And I see no options to use video conference in Kopete as
> would use Jingle.
> 
> If there's nobody who uses this any more I think we should remove Kopete to 
> unmaintained.

Why would you move kopete to unmaintained? 

Because libjingle support fails? 

Worst case scenario, just remove libjingle support in the jabber protocol.

Cheers,
  Albert

> 
> Jonathan
> 

Re: i18n po files : Hooks for number of arguments on SVN

[Albert Astals Cid]

El dimecres, 19 de desembre de 2018, a les 10:11:10 CET, Simon Depiets va 
escriure:
> Hello,
> I'm facing an issue with translation of kdeconnect_android, their
> res/values/strings.xml ressources file contains :
> 
> 
> File: %1s
> (File %2$d of %3$d) : %1$s
> 
> 
> Understandably (in KDE/QT context), the SVN commit pre-hook rejects this
> plural form message because the singular contains 1 argument and the plural
> form 3 arguments. However for an Android app this seems like a valid
> construct.
> 
> How does the SVN pre-commit hook work and how customizable is it ?

It's not customizable because the .po[t] file is wrong, it's marked as c-format 
and it's not.

See https://marc.info/?t=15436768611&r=1&w=2 

Cheers,
  Albert

> Is there a way to add/detect a tag in the context which would then disable
> this specific check ?
> Else I guess the kdeconnect team has to find a way to add %2 and %3 as
> dummy argument in the singular string or the translation teams cannot
> commit singular forms.
> Regards
> 

Re: Troubles with icon themes

[Albert Astals Cid]

El dimecres, 23 de gener de 2019, a les 4:48:10 CET, Jonathan Schultz va 
escriure:
> Hello KDE developers,
> 
> I wonder if someone can help me work out what is going on here.
> 
> I have build some KDE applications (konsole and okular) from source using 
> kdesrc-build, using QT5 version 5.11.3 also built from sources. The 
> applications build and run, but do not load the icons used in the UI. I have 
> the following lines in ~/.config/kdeglobals:
> 
> > [Icons]
> > Theme=oxygen
> 
> and running strace on the application reveals that it is finding and crawling 
> the oxygen icon theme directories. However, if I rename the oxygen theme 
> directory to hicolor then the application does find the icons correctly.
> 
> I have written a trivial Qt test, using 'QIcon::setThemeName("oxygen")' to 
> set the theme and it works fine.
> 
> I also note that kiconfinder5 also finds the icons in the oxygen directory.
> 
> I've tried some reverse-engineering/debugging but succeeded only in getting 
> lost in the code.
> 
> One thing I suspect it that the problem might be related to my development 
> environment, which is a sandboxed Docker container with no display manager 
> installed. I understand that KDE tries to work out what icon theme is already 
> in use by an installed display manager, so perhaps this environment is 
> somehow triggering some unexpected (by me at least) behaviour.

Your application is in docker, so it won't pick up your ~/.config/kdeglobals, 
that is outside docker how would it be picked up?

Or you mean you ~/.config/kdeglobals is also inside your docker container?

Cheers,
  Albert

> 
> Thanks as always.
> 
> Jonathan
> 
> 

Re: Building KDE statically

[Albert Astals Cid]

El divendres, 22 de febrer de 2019, a les 4:57:42 CET, Jonathan Schultz va 
escriure:
> Hello KDE developers,
> 
> If anyone is interested, here is a brief report on something I have been 
> working on in my spare time.

Since at least part of this involves frameworks, you may want to send this to 
the frameworks devel mailing list. Maybe you get some more answers/traction 
there.

Cheers,
  Albert

> 
> TLDR: Here are some scripts to build KDE frameworks and okular statically 
> using gcc/musl and cross-building for mingw: 
> https://github.com/jschultz/kde-static Look in the file patch-kde.sh to see 
> the interesting stuff.
> 
> I've been working on an application based largely on okular that I would like 
> to be able to deploy as simply as possible for users with no technical 
> expertise. For this purpose, and despite its well-known down-sides I thought 
> that a static build would be helpful.
> 
> So I started building KDE frameworks and other okular dependencies using 
> kdesrc-build and working out what would need to change to make a static 
> build. It turned out to be more painstaking but less complicated than I had 
> imagined.
> 
> It all happens inside Docker containers built on voidlinux, which I chose 
> because it handles musl natively and has a build process simple enough for me 
> to understand. No doubt there are good reasons to use a different Linux 
> distro but so be it.
> 
> Most of the patches are simply to make CMake handle static dependencies. A 
> few deal with ad hoc issues that arose out of static building. The most 
> complicated was linking okular's plugins statically, which involved a bit of 
> build hacking, but nothing too dreadful (IMHO).
> 
> I've made all the patches backwards-compatible, ie they have no effect on a 
> conventional build using shared libraries.
> 
> I took some shortcuts in working out which static libraries to include, ie 
> basically all libraries are included on all link operations, and we count on 
> the linker to leave out those that aren't required.
> 
> I also put in some cross-building stuff. Since kdesrc-build seems not to do a 
> good job with host applications required for the building process, I just 
> pre-built those and put the executables in the repository. Not all of 
> frameworks cross-builds, but enough to link okular does.
> 
> What it produces:
> 
> An static okular executable with the following generator plugins: poppler, 
> kimgio, dvi, tiff, xps, ooo, fb, comicbook, fax, plucker, txt is about 88MB 
> in size. I understand that this might be reduced, possibly by as much as 80%, 
> by using Link-Time Optimisation (LTO). Even as it is, it starts and runs 
> noticeably faster than a conventional build. Cross-building, a mingw32 
> okular.exe is around 58MB and a mingw64 73MB.
> 
> Still some problems: it can't save files because (if I understand correctly) 
> kio uses slave processes that are also based on plugins which would need to 
> be linked statically.
> 
> What's next: Cross-building for MacOS. Using craft instead of kdesrc-build.
> 
> So feel free to hit me up with suggestions, interest or if anyone is 
> interested in incorporating any of this into the mainline of KDE development.
> 
> Cheers,
> Jonathan
> 
> 

Re: Gitlab Evaluation & Migration

[Albert Astals Cid]

El dimecres, 27 de febrer de 2019, a les 20:12:55 CET, Eike Hein va escriure:
> 
> On 2/27/19 4:38 AM, Nate Graham wrote:
> > It's really pretty nice. But  Gitlab has a 
> > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, 
> > people without commit access won't just be able to start hacking with the 
> > source checkout that kdesrc-build downloads, or else they won't be able to 
> > push their branch to any remotes and create a Merge Request.
> 
> No, this is not correct.

Can we enable the upload diff by email option? I know it's not the best UI but 
for some people that have trouble understanding git remotes it may help?

https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email

Cheers,
  Albert

Re: ffmpegthumbnailer

[Albert Astals Cid]

El diumenge, 3 de març de 2019, a les 17:41:57 CET, Nate Graham va escriure:
> Howdy folks,
> We have https://cgit.kde.org/ffmpegthumbs.git, which is not very actively 
> developed.
> 
> There is also this upstream project 
> https://github.com/dirkvdb/ffmpegthumbnailer which appears to be more 
> actively developed.

How is this upstream?

Cheers,
  Albert

> 
> It seems kind of wasteful to have two projects that do exactly the same 
> thing, each with few resources and low levels of interest. What do folks 
> think about approaching the maintainer of the project on GitHub and asking if 
> they want to merge with ours? Or should we abandon ours and tell distros to 
> package his instead? Or are there good reasons to keep ours separate that I'm 
> not aware of?
> 
> Nate
> 
> 

Re: ffmpegthumbnailer

[Albert Astals Cid]

El dimarts, 5 de març de 2019, a les 0:00:36 CET, mark rimon va escriure:
> Hello,
>   i just wanted to ask what should i do to be accepted ?

You want to be accepted where?

Cheers,
  Albert

> Thanls
> 
> 
> From: kde-devel  on behalf of Albert Astals Cid 
> 
> Sent: Monday, March 4, 2019 8:43 PM
> To: kde-devel@kde.org
> Cc: Nate Graham; kfm-devel
> Subject: Re: ffmpegthumbnailer
> 
> El diumenge, 3 de març de 2019, a les 17:41:57 CET, Nate Graham va escriure:
> > Howdy folks,
> > We have https://cgit.kde.org/ffmpegthumbs.git, which is not very actively 
> > developed.
> >
> > There is also this upstream project 
> > https://github.com/dirkvdb/ffmpegthumbnailer which appears to be more 
> > actively developed.
> 
> How is this upstream?
> 
> Cheers,
>   Albert
> 
> >
> > It seems kind of wasteful to have two projects that do exactly the same 
> > thing, each with few resources and low levels of interest. What do folks 
> > think about approaching the maintainer of the project on GitHub and asking 
> > if they want to merge with ours? Or should we abandon ours and tell distros 
> > to package his instead? Or are there good reasons to keep ours separate 
> > that I'm not aware of?
> >
> > Nate
> >
> >
> 
> 
> 
> 
> 

Re: ffmpegthumbnailer

[Albert Astals Cid]

El dimarts, 5 de març de 2019, a les 16:45:21 CET, mark rimon va escriure:
> In KDE project in GSoC 2019

In my *personal opinion* you almost disqualified yourself.

Two reasons:
 * There's plenty of literature of how GSOC works, you not being able to use a 
search engine to find it shows a big lack of initiative.
 * You totally misused this mailing list, learning how to communicate properly 
is key.

So please, read about GSOC by yourself, and then if you really can't find the 
answer to a question, send a proper email.

Best of luck,
  Albert

> 
> 
> From: kde-devel  on behalf of Albert Astals Cid 
> 
> Sent: Tuesday, March 5, 2019 1:49 AM
> To: kde-devel@kde.org
> Subject: Re: ffmpegthumbnailer
> 
> El dimarts, 5 de març de 2019, a les 0:00:36 CET, mark rimon va escriure:
> > Hello,
> >   i just wanted to ask what should i do to be accepted ?
> 
> You want to be accepted where?
> 
> Cheers,
>   Albert
> 
> > Thanls
> >
> > 
> > From: kde-devel  on behalf of Albert Astals Cid 
> > 
> > Sent: Monday, March 4, 2019 8:43 PM
> > To: kde-devel@kde.org
> > Cc: Nate Graham; kfm-devel
> > Subject: Re: ffmpegthumbnailer
> >
> > El diumenge, 3 de març de 2019, a les 17:41:57 CET, Nate Graham va escriure:
> > > Howdy folks,
> > > We have https://cgit.kde.org/ffmpegthumbs.git, which is not very actively 
> > > developed.
> > >
> > > There is also this upstream project 
> > > https://github.com/dirkvdb/ffmpegthumbnailer which appears to be more 
> > > actively developed.
> >
> > How is this upstream?
> >
> > Cheers,
> >   Albert
> >
> > >
> > > It seems kind of wasteful to have two projects that do exactly the same 
> > > thing, each with few resources and low levels of interest. What do folks 
> > > think about approaching the maintainer of the project on GitHub and 
> > > asking if they want to merge with ours? Or should we abandon ours and 
> > > tell distros to package his instead? Or are there good reasons to keep 
> > > ours separate that I'm not aware of?
> > >
> > > Nate
> > >
> > >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 

Re: Fuzzing KDE software

[Albert Astals Cid]

El dimecres, 6 de març de 2019, a les 20:20:03 CET, alcinos va escriure:
> Hello,
> 
> As some of you might have heard, we have been rewriting significantly some
> key components of Kdenlive over the past couple years, in an effort to
> improve stability, testability, and separation of concerns between the view
> and the model.
> 
> As part of this effort, on top of traditional unit-tests (none existed
> before the rewrite), I have been looking at fuzzing as a way to push the
> code to its limit. For those who are not familiar with it, fuzzing is a
> testing technique that essentially consists in generating a lot of random
> inputs and feeding them to a target program in an attempt to generate
> unintended behaviours (memoryleak, crash,...). This technique has an
> excellent track record of finding bugs and vulnerabilites, even in well
> tested softwares (see eg. https://llvm.org/docs/LibFuzzer.html#trophies)
> 
> In the case of Kdenlive, we generate a lot of operations that the user
> could execute on the timeline, and simulate them in the model, to check for
> robustness over unexpected action sequences.
> Note that this kind of testing doesn't explicitly test for correctness (it
> doesn't check whether a clip is correctly moved after a move operation for
> example), but try to get the software to crash, if there is a way to make
> that happen. Also, we have some internal checking mechanisms that
> periodically ensure that the model is in a sane state, and the invariants
> are respected. So if things go wrong with respect to that, it will also be
> caught by the fuzzer.
> 
> This approach has already led to the discovery of several bugs in kdenlive,
> although the parts covered by the fuzzer are still fairly limited.
> 
> Are any other projects in KDE using that technique? In order for it to be
> useful, it pretty much needs to be run continuously (I've been running it a
> bit on my laptop, but it's not very practical). Some companies offer such
> service for free for OSS, under some conditions: see for eg:
> https://github.com/google/oss-fuzz and https://fuzzbuzz.io/pricing,
> although I'm not sure whether Kdenlive would meet the requirements for
> either of those. Is there any way we could do this inside the KDE
> infrastructure instead?

We (KDE Security team, but here basically just me) are running kcodecs and 
kimageformats in oss-fuzz.

I can help you with the setup if you want.

Cheers,
  Albert

> Ideally, this are the requirements for such a
> service:
> 
>- Continuous running
>- Git hook to get the latest code
>- Automatic bug deduplication and reporting
>- (optional) Coverage report to ensure the fuzzing is effective.
> 
> Google open-sourced most of its tooling for fuzzing at scale on a cluster,
> so there is no need to start from scratch.
> 
> What are your thoughts?
> 
> Best regards,
> Nicolas Carion
> 

Re: Fuzzing KDE software

[Albert Astals Cid]

El dijous, 7 de març de 2019, a les 1:56:47 CET, alcinos va escriure:
> Le mer. 6 mars 2019 à 20:36, Albert Astals Cid  a écrit :
> 
> > El dimecres, 6 de març de 2019, a les 20:20:03 CET, alcinos va escriure:
> > > Hello,
> > >
> > > As some of you might have heard, we have been rewriting significantly
> > some
> > > key components of Kdenlive over the past couple years, in an effort to
> > > improve stability, testability, and separation of concerns between the
> > view
> > > and the model.
> > >
> > > As part of this effort, on top of traditional unit-tests (none existed
> > > before the rewrite), I have been looking at fuzzing as a way to push the
> > > code to its limit. For those who are not familiar with it, fuzzing is a
> > > testing technique that essentially consists in generating a lot of random
> > > inputs and feeding them to a target program in an attempt to generate
> > > unintended behaviours (memoryleak, crash,...). This technique has an
> > > excellent track record of finding bugs and vulnerabilites, even in well
> > > tested softwares (see eg. https://llvm.org/docs/LibFuzzer.html#trophies)
> > >
> > > In the case of Kdenlive, we generate a lot of operations that the user
> > > could execute on the timeline, and simulate them in the model, to check
> > for
> > > robustness over unexpected action sequences.
> > > Note that this kind of testing doesn't explicitly test for correctness
> > (it
> > > doesn't check whether a clip is correctly moved after a move operation
> > for
> > > example), but try to get the software to crash, if there is a way to make
> > > that happen. Also, we have some internal checking mechanisms that
> > > periodically ensure that the model is in a sane state, and the invariants
> > > are respected. So if things go wrong with respect to that, it will also
> > be
> > > caught by the fuzzer.
> > >
> > > This approach has already led to the discovery of several bugs in
> > kdenlive,
> > > although the parts covered by the fuzzer are still fairly limited.
> > >
> > > Are any other projects in KDE using that technique? In order for it to be
> > > useful, it pretty much needs to be run continuously (I've been running
> > it a
> > > bit on my laptop, but it's not very practical). Some companies offer such
> > > service for free for OSS, under some conditions: see for eg:
> > > https://github.com/google/oss-fuzz and https://fuzzbuzz.io/pricing,
> > > although I'm not sure whether Kdenlive would meet the requirements for
> > > either of those. Is there any way we could do this inside the KDE
> > > infrastructure instead?
> >
> > We (KDE Security team, but here basically just me) are running kcodecs and
> > kimageformats in oss-fuzz.
> >
> > I can help you with the setup if you want.
> >
> I'm worried that Kdenlive may not meet oss-fuzz's requirements: "a
> significant user base and/or be critical to the global IT infrastructure"
> (the latter is definitely false, the former is subjective).
> If we do meet the requirements, any help setting this up would be greatly
> appreciated. If I understand correctly, since we already have a fuzz-target
> in the repo, the only thing we need is to have the project build in the
> docker image?

Yes, make sure it builds and runs on their docker system, it's going to be 
tricky since you need to compile everything statically (not sure if you already 
do that).

And honestly, kdenlive has a significant user base if you ask me, so don't 
pre-disqualify yourself, if they disagree, let them say it, not you.

Cheers,
  Albert

> 
> To Boudewijn Rempt: if you want some technical details about how it's done
> for Kdenlive, feel free to ask! I guess a similar approach could be taken
> for Krita, if the architecture permits it.
> The code is located here:
> https://invent.kde.org/kde/kdenlive/tree/refactoring_timeline/fuzzer
> 
> Cheers,
> Nicolas
> 
> 
> > Cheers,
> >   Albert
> 
> 
> > > Ideally, this are the requirements for such a
> > > service:
> > >
> > >- Continuous running
> > >- Git hook to get the latest code
> > >- Automatic bug deduplication and reporting
> > >- (optional) Coverage report to ensure the fuzzing is effective.
> > >
> > > Google open-sourced most of its tooling for fuzzing at scale on a
> > cluster,
> > > so there is no need to start from scratch.
> > >
> > > What are your thoughts?
> > >
> > > Best regards,
> > > Nicolas Carion
> > >
> >
> >
> >
> >
> >
> 

Re: Gitlab Evaluation & Migration

[Albert Astals Cid]

El dilluns, 11 de març de 2019, a les 22:46:33 CET, Eike Hein va escriure:
> Hi,
> 
> I have a request.
> 
> In the evaluation lately, I've seen some people unhappy with the merge 
> commits created when merging merge requests that can't be 
> fast-forwarded, as it clutters the repo history. While I personally 
> don't mind much, I can see the point coming from the squash-and-rebase 
> workflow Phabricator had.
> 
> It turns out that GitLab has a feature to disallow non-fast-forward 
> merges and show a rebase button instead:
> 
> https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
> 
> https://gitlab.com/gitlab-org/gitlab-ce/issues/20076
> 
> Could we enable this?

I asked for this too, i thought it had been enabled at some point, but i guess 
not.

So +1

Cheers,
  Albert

> 
> 
> Cheers,
> Eike
> 

KDE Applications 19.04 Dependency Freeze will be in effect at the end of the UTC day (in 1.5 hours)

[Albert Astals Cid]

https://community.kde.org/Schedules/Applications/19.04_Release_Schedule#Thursday.2C_March_14.2C_2019:_KDE_Applications_19.04_Dependency_Freeze

>From this moment on it is not allowed to add new dependencies or bump 
>dependencies versions. It is possible to get an exception for this. Post the 
>patch to phabricator and add the release-team as reviewer. We will check if 
>the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a 
version of a dependency that is higher than currently checked for in the build 
system, you need to have committed this change before this date. 


Cheers,
  Albert

KDE Applications 19.04 branches created

[Albert Astals Cid]

Make sure you commit anything you want to end up in the 19.04 release to them  
[***]

We're already past the dependency freeze.

The Freeze and Beta is this Thursday 21 of March.

More interesting dates
 April 4: KDE Applications 19.04 RC (19.03.90) Tagging and Release
 April 11: KDE Applications 19.04 Tagging
 April 18: KDE Applications 19.04 Release

https://community.kde.org/Schedules/Applications/19.04_Release_Schedule

Cheers,
  Albert


[***] Except for kdenlive, they're having a sprint that ends this weekend so we 
decided together with them i'll create their branch on Monday

Re: Announcement text for the KDE Applications 19.04 release

[Albert Astals Cid]

El dimarts, 19 de març de 2019, a les 1:32:44 CET, Christoph Feck va escriure:
> Hello developers,
> 
> the Applications/19.04 branches have been created, which means the
> branches are feature-frozen. Our first release for 2019 is nearing!

Christoph made a small mistake reading the schedule here, the feature freeze is 
still not there and it's coming in 2 days, but yeah you should really really be 
sure you're commiting all your stuff to Applications/19.04 ASAP otherwise we'll 
be a bit upset when come friday and we can't build stuff ;)

Cheers,
  Albert

> 
> Please help our promotion team to write an announcement text that
> summarizes all the work that went into KDE Applications since our 18.12
> release.
> 
> I created https://phabricator.kde.org/T10636 which has a link for the
> Etherpad document at https://notes.kde.org/p/applications_19.04_new_features
> 
> Please fill this document in the next few days.
> 
> 

Re: lgtm integration (automated detection of bugs and problems for programming languages)

[Albert Astals Cid]

El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz Canabrava va escriure:
> Hello kdevelopers,
> 
> I'v come to know the lgtm.com this week and started to enjoy it quite
> a bit. It provides code analisys for various languages like c/c++ /
> java / javascript / python, transforming code to data and extracting
> information using a QL Schema + Deep learning.
> 
> It's opensource

Is it? I can't seem to find the code.

> , and *already* runs thru all the kde codebase because
> our code has a mirror on github (but it also supports gitlab,
> bitbucket). Some of the code from kde can't be analized yet because of
> unmatched dependencies, but here's an example of a software we all
> know and love, being analized by their tools.
> 
> https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list
> 
> I belive we should get in contact with them and ask for a ~formal~
> partnership and integrate this into our phab / gitlab instances.

I'm a bit hesitant about it's quality. 

It complains about 
https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1
If you read the description it'd seem it's a memory leak.
That's because it doesn't understand QObject ownership and that 
deleting a parent will delete its children.

It says this is an error 
https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1
It's not, i'll agree it's not very common to do this comparison, but 
it's valid code

It says this is a noop 
https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1
It's not, qRegisterMetaType does things

So I'm happy that those results are out there, but given the amount of 
false/questionable positives i found in 5 minutes of looking at it, I'd be very 
careful of giving it to "the general population", that may just propose changes 
because a tool told them to.

Cheers,
  Albert


> 
> Tomaz
> 

Re: lgtm integration (automated detection of bugs and problems for programming languages)

[Albert Astals Cid]

El dijous, 21 de març de 2019, a les 20:31:34 CET, Tomaz Canabrava va escriure:
> Em qui, 21 de mar de 2019 às 19:48, Albert Astals Cid 
> escreveu:
> 
> > El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz Canabrava va
> > escriure:
> > > Hello kdevelopers,
> > >
> > > I'v come to know the lgtm.com this week and started to enjoy it quite
> > > a bit. It provides code analisys for various languages like c/c++ /
> > > java / javascript / python, transforming code to data and extracting
> > > information using a QL Schema + Deep learning.
> > >
> > > It's opensource
> >
> > Is it? I can't seem to find the code.
> >
> > > , and *already* runs thru all the kde codebase because
> > > our code has a mirror on github (but it also supports gitlab,
> > > bitbucket). Some of the code from kde can't be analized yet because of
> > > unmatched dependencies, but here's an example of a software we all
> > > know and love, being analized by their tools.
> > >
> > > https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list
> > >
> > > I belive we should get in contact with them and ask for a ~formal~
> > > partnership and integrate this into our phab / gitlab instances.
> >
> > I'm a bit hesitant about it's quality.
> >
> > It complains about
> > https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1
> > If you read the description it'd seem it's a memory leak.
> > That's because it doesn't understand QObject ownership and that
> > deleting a parent will delete its children.
> >
> > It says this is an error
> > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1
> > It's not, i'll agree it's not very common to do this comparison,
> > but it's valid code
> >
> > It says this is a noop
> > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1
> > It's not, qRegisterMetaType does things
> >
> > So I'm happy that those results are out there, but given the amount of
> > false/questionable positives i found in 5 minutes of looking at it, I'd be
> > very careful of giving it to "the general population", that may just
> > propose changes because a tool told them to.
> >
> > Cheers,
> >   Albert
> >
> 
> They are already working in two of the bugs that you described - reported
> by the subsurface team.
> 
> The source for parts of the tools are here:
> 
> https://github.com/Semmle/ql
> 
> And of course as any tool that is starting there will be errors.

Sure, i never said it's useless, in fact it did find some mismatched 
free/delete/delete[] calls in both okular and poppler.

I just want to make sure we don't tell people "these are bugs, go fix them", 
because then people will take the tool at 100% correct rate value, when it's 
not that kind of tool.

Cheers,
  Albert

> 
> 
> >
> > >
> > > Tomaz
> > >
> >
> >
> >
> >
> >
> 

Re: lgtm integration (automated detection of bugs and problems for programming languages)

[Albert Astals Cid]

El divendres, 22 de març de 2019, a les 7:43:09 CET, Tomaz Canabrava va 
escriure:
> On Thu, Mar 21, 2019 at 9:27 PM Albert Astals Cid  wrote:
> >
> > El dijous, 21 de març de 2019, a les 20:31:34 CET, Tomaz Canabrava va 
> > escriure:
> > > Em qui, 21 de mar de 2019 às 19:48, Albert Astals Cid 
> > > escreveu:
> > >
> > > > El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz Canabrava va
> > > > escriure:
> > > > > Hello kdevelopers,
> > > > >
> > > > > I'v come to know the lgtm.com this week and started to enjoy it quite
> > > > > a bit. It provides code analisys for various languages like c/c++ /
> > > > > java / javascript / python, transforming code to data and extracting
> > > > > information using a QL Schema + Deep learning.
> > > > >
> > > > > It's opensource
> > > >
> > > > Is it? I can't seem to find the code.
> > > >
> > > > > , and *already* runs thru all the kde codebase because
> > > > > our code has a mirror on github (but it also supports gitlab,
> > > > > bitbucket). Some of the code from kde can't be analized yet because of
> > > > > unmatched dependencies, but here's an example of a software we all
> > > > > know and love, being analized by their tools.
> > > > >
> > > > > https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list
> > > > >
> > > > > I belive we should get in contact with them and ask for a ~formal~
> > > > > partnership and integrate this into our phab / gitlab instances.
> > > >
> > > > I'm a bit hesitant about it's quality.
> > > >
> > > > It complains about
> > > > https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1
> > > > If you read the description it'd seem it's a memory leak.
> > > > That's because it doesn't understand QObject ownership and that
> > > > deleting a parent will delete its children.
> > > >
> > > > It says this is an error
> > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1
> > > > It's not, i'll agree it's not very common to do this comparison,
> > > > but it's valid code
> > > >
> > > > It says this is a noop
> > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1
> > > > It's not, qRegisterMetaType does things
> > > >
> > > > So I'm happy that those results are out there, but given the amount of
> > > > false/questionable positives i found in 5 minutes of looking at it, I'd 
> > > > be
> > > > very careful of giving it to "the general population", that may just
> > > > propose changes because a tool told them to.
> > > >
> > > > Cheers,
> > > >   Albert
> > > >
> > >
> > > They are already working in two of the bugs that you described - reported
> > > by the subsurface team.
> > >
> > > The source for parts of the tools are here:
> > >
> > > https://github.com/Semmle/ql
> > >
> > > And of course as any tool that is starting there will be errors.
> >
> > Sure, i never said it's useless, in fact it did find some mismatched 
> > free/delete/delete[] calls in both okular and poppler.
> >
> > I just want to make sure we don't tell people "these are bugs, go fix 
> > them", because then people will take the tool at 100% correct rate value, 
> > when it's not that kind of tool.
> 
> I opened bug reports to them:
> 
> https://github.com/Semmle/ql/issues/1153
> this one I'm not convinced yet.
> 
> https://github.com/Semmle/ql/issues/1154
> this one it seems that it was not false positive.

Interesting, wonder if that was always the case or just started happening 
recently.

Thanks for helping figure it out :)

Cheers,
  Albert

> 
> :)
> 
> > Cheers,
> >   Albert
> >
> > >
> > >
> > > >
> > > > >
> > > > > Tomaz
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> 

Re: kipi-plugins standalone release

[Albert Astals Cid]

El dijous, 18 d’abril de 2019, a les 16:23:00 CEST, Jonathan Riddell va 
escriure:
> kipi-plugins used to be released standalone but in 2015 it moved to be part
> of Digikam releases.  Libkipi itself is released as part of KDE
> Applications.  Digikam has now stopped including kipi-plugins in its
> releases but they are still used by Gwenview and maybe Spectacle and
> kphotoalbum so we should keep them around until everything has moved onto
> replacements such as Purpose or Digikam's new plugins.
> 
> So I propose a standalone release with version 5.9.1
> 
> Here's a tar I made just now with version not yet bumped
> http://embra.edinburghlinux.co.uk/~jr/tmp/kipi-plugins-5.9.0.tar.xz
> 
> Then I propose we move it into KDE Applications so the release gets done
> regularly and it's alongside libkipi and use the KDE Apps 19.04 style
> version numbers.
> 
> Does that make sense?

For KDE Applications 19.08 sure, adding it for KDE Applications 19.04.1 would 
be a bit weird.

Cheers,
  Albert

> Also note to self Gwenview asks to install photolayoutseditor plugin when
> it can't find any but that plugin was removed ages ago.
> 
> Jonathan
> 

May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

We have a huge list of playground kde4 repos that are being processed for l10n.

This takes some resources that make no sense since you should really not be 
developing for KDE4 anymore, and if you really really really need it, it 
shouldn't be in playground.

So on May 10 i'll make sure scripty doesn't waste CPU on them.

Cheers,
  Albert

P.S: Anyone interested in the list https://ghostbin.com/paste/823jo

Re: May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

El diumenge, 21 d’abril de 2019, a les 17:47:47 CEST, Luigi Toscano va escriure:
> Christoph Feck ha scritto:
> > On 04/21/19 12:47, Albert Astals Cid wrote:
> >> We have a huge list of playground kde4 repos that are being processed for 
> >> l10n.
> >>
> >> This takes some resources that make no sense since you should really not 
> >> be 
> >> developing for KDE4 anymore, and if you really really really need it, it 
> >> shouldn't be in playground.
> >>
> >> So on May 10 i'll make sure scripty doesn't waste CPU on them.
> >>
> >> Cheers,
> >>   Albert
> >>
> >> P.S: Anyone interested in the list https://ghostbin.com/paste/823jo
> 
> Maybe we could move the code of everything-nepomuk and everything-plasma 4 to 
> unmaintained.

My immediate goal is not to waste CPU power processing old code every day for 
no reason, but yes, that probably makes sense too.

Cheers,
  Albert

> 
> > 
> > https://cgit.kde.org/smaragd.git/tree/CMakeLists.txt says that 
> > playground-artwork_smaragd is a KF5 repo. Where does the KDE4 detection 
> > come 
> > from?
> 
> trunk/l10n-kde4 tracks the "0.0" branch:
> 
> {"stable": "none", "trunk": "0.0", "stable_kf5": "none", "trunk_kf5": 
> "master"}
> 
> Happy Easter too!
> 
> Ciao
> 

Re: May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

El dilluns, 22 d’abril de 2019, a les 21:11:12 CEST, Zoltan Padrah va escriure:
> Albert Astals Cid  ezt írta (időpont: 2019. ápr. 21., V,
> 13:48):
> 
> > We have a huge list of playground kde4 repos that are being processed for
> > l10n.
> >
> > This takes some resources that make no sense since you should really not
> > be developing for KDE4 anymore, and if you really really really need it, it
> > shouldn't be in playground.
> >
> > So on May 10 i'll make sure scripty doesn't waste CPU on them.
> >
> > Cheers,
> >   Albert
> >
> > P.S: Anyone interested in the list https://ghostbin.com/paste/823jo
> >
> >
> >
> Hi,
> 
> as I see KTechLab ( playground-devtools_ktechlab ) is in that list. Its
> latest release still depends on KDE4 and its KF5 port is still work in
> progress.
> 
> Can you delay its removal from l10n support until the first KF5 release?

Are you going to do another kde4 release? Hope not, so then we can just track 
the KF5 branch and that's it?

Cheers,
  Albert

> 
> Best regards,
> 
>  Zoltan
> 

Re: May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

El dimarts, 23 d’abril de 2019, a les 12:59:21 CEST, Zoltan Padrah va escriure:
> Albert Astals Cid  ezt írta (időpont: 2019. ápr. 23., K,
> 1:17):
> 
> > El dilluns, 22 d’abril de 2019, a les 21:11:12 CEST, Zoltan Padrah va
> > escriure:
> > > Can you delay its removal from l10n support until the first KF5 release?
> >
> > Are you going to do another kde4 release? Hope not, so then we can just
> > track the KF5 branch and that's it?
> >
> >
> 
> Hopefully there will be no need for another KDE4 release -- I can only
> imagine it happening if there is a critical issue which needs to be fixed.
> So for now I'm comfortable to say that there will be no next KDE4 release.
> 
> In the long term I want to have KF5 in master; currently there is just a
> work-in-progress branch for KF5, which doesn't even compile. Do you prefer
> to track that branch or disable l10n for KTechLab for now and I will ask
> for re-enabling it when master will build with KF5?

I guess we can let the kde4 master branch live a bit more.

What's the name of your KF5 branch? Maybe we can help with the porting :)

Anything in particular you're stuck with?

Cheers,
  Albert

> 
> 
> 
> 
> > Cheers,
> >   Albert
> >
> > >
> > > Best regards,
> > >
> > >  Zoltan
> > >
> >
> >
> >
> >
> >
> 

Re: Are KDE applications extensible with Javascript like Plasma is?

[Albert Astals Cid]

El dissabte, 27 d’abril de 2019, a les 13:45:04 CEST, Aleix Pol va escriure:
> On Fri, Apr 26, 2019 at 5:41 PM Christopher Patti  wrote:
> >
> > I am after understanding in a general sense how KDE applications can be 
> > extended at runtime. Are there particular Qt classes that enable this?
> >
> > Let me ask a more concrete question that may be easier to answer - can you 
> > give me an example of a KDE app that's extensilble?
> >
> > Thanks in advance for taking the time to answer these questions.
> >
> > -Chris
> >
> >
> > On Wed, Apr 24, 2019, at 6:43 PM, Aleix Pol wrote:
> > > On Wed, Apr 24, 2019 at 10:57 PM Christopher Patti  wrote:
> > > >
> > > > Hi all. I hope you'll forgive a potentially ignorant question, but I'm 
> > > > curious about something that confuses a lot of people.
> > > >
> > > > I'd love to be able to 'script' KDE applications at runtime.
> > > >
> > > > It *looks* like you can do this at least with the Plasma desktop using 
> > > > Javascript:
> > > >
> > > > https://userbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting
> > > >
> > > > Is it possible to do something similar with KDE apps as well?
> > > >
> > > > Thanks for tolerating a newbie question.
> > >
> > > Hi Christopher,
> > > Some applications can be extended using JavaScript, but not every 
> > > application.
> > >
> > > What are you after?
> > > Aleix
> > >
> 
> https://doc.qt.io/qt-5/qjsengine.html

Also 
https://api.kde.org/frameworks/kross/html/index.html

Cheers,
  Albert

ktechlab KF5 - was - Re: May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

El dijous, 2 de maig de 2019, a les 16:51:46 CEST, Zoltan Padrah va escriure:
> Meanwhile: the latest code I've pushed to the KF5 branch compiles, but it
> crashes immediately.

Doesn't compile for me.

There's at least some includes for files that don't exist anymore (see attached 
patch).

Bessdes that there's some missing libraries (i.e. gui uses khtml_part.h but 
doesn't link to KF5::Html)
and there's also a weird loop in which stuff in src/gui/ uses stuff from just 
src/ and that is bad given how src/gui wants to be its own static library.

Cheers,
  Albert

> 
> 
> 
> 
> >
> > Ciao
> > --
> > Luigi
> >
> 

diff --git a/src/flowparts/pinmapping.cpp b/src/flowparts/pinmapping.cpp
index a7ea9ea5..52bf895a 100644
--- a/src/flowparts/pinmapping.cpp
+++ b/src/flowparts/pinmapping.cpp
@@ -21,7 +21,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/src/gui/programmerdlg.cpp b/src/gui/programmerdlg.cpp
index 9effc713..63fd88f2 100644
--- a/src/gui/programmerdlg.cpp
+++ b/src/gui/programmerdlg.cpp
@@ -21,7 +21,6 @@
 
 #include 
 #include 
-#include 
 
 
 class ProgrammerWidget : public QWidget, public Ui::ProgrammerWidget {
diff --git a/src/ktechlab.cpp b/src/ktechlab.cpp
index 9aec209d..e64ead51 100644
--- a/src/ktechlab.cpp
+++ b/src/ktechlab.cpp
@@ -47,7 +47,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

Re: ktechlab KF5 - was - Re: May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

El dilluns, 13 de maig de 2019, a les 22:06:44 CEST, Zoltan Padrah va escriure:
> Albert Astals Cid  ezt írta (időpont: 2019. máj. 12., V,
> 22:31):
> 
> > El dijous, 2 de maig de 2019, a les 16:51:46 CEST, Zoltan Padrah va
> > escriure:
> > > Meanwhile: the latest code I've pushed to the KF5 branch compiles, but it
> > > crashes immediately.
> >
> > Doesn't compile for me.
> >
> > There's at least some includes for files that don't exist anymore (see
> > attached patch).
> >
> >
> Thanks for looking into this. As soon as I have some time I will apply more
> fixes to the code.
> 
> I assume that the code compiles for me and not for you because I still have
> the kdelibs4-dev packages installed, thus the headers are found from KDE4.
> 
> Your patch looks good to me, feel free to apply it.

Done

> 
> 
> > Bessdes that there's some missing libraries (i.e. gui uses khtml_part.h
> > but doesn't link to KF5::Html)
> > and there's also a weird loop in which stuff in src/gui/ uses stuff from
> > just src/ and that is bad given how src/gui wants to be its own static
> > library.
> >
> >
> Around building `src/gui` is a lot of breakage, not just because of
> circular dependencies, but also because the generated headers from Qt .ui
> files are included in other directories and cmake fails to detect
> dependencies between the generated headers and the files from other
> directories which include them. For KDE4 I've just made a script which
> generated headers from `src/gui` first and run make only after that; the
> same issue still happens in KF5 but I want to fix it somehow. My best idea
> is to move files around, remove circular dependencies and modify files to
> do not include generated files in different directories / static
> libraries...

My suggestion would be not to use that many static libraries if you're having 
trouble with the circular dependencies between them.

Just start by building everything into a big blob, and once you have it 
building, see if you can chop it in different pieces.

Cheers,
  Albert

> 
> 
> 
> > Cheers,
> >   Albert
> >
> >
> Best regards,
> 
>  Zoltan
> 
> 
> 
> > >
> > >
> > >
> > >
> > > >
> > > > Ciao
> > > > --
> > > > Luigi
> > > >
> > >
> >
> >
> 

KAuth helper in flatpak - was - Re: Smb4K flatpak build fails due to KAuth helper

[Albert Astals Cid]

El divendres, 31 de maig de 2019, a les 13:05:04 CEST, Alexander Reinholdt va 
escriure:
> Has anyone on this list successfully packaged a program with a KAuth helper 
> included? Or is it impossible to install a KAuth helper into a flatpak? Help 
> is much appreciated.

I think that's the main question, does a KAuth helper make sense in a flatpak 
app?

Given that flatpak apps are [supposed to be] sandboxed, personally I don't 
think it makes sense for them to let you have elevated permissions.

Elevated permissions to what if you're in a sandbox and can't see anything 
anyway?

But I have to say my knowledge of flatpak is not very deep.

Aleix? Jan?

Do the flatpak people have a list where it make sense asking/discussing this?

Cheers,
  Albert

Re: rsibreak release?

[Albert Astals Cid]

El dimecres, 5 de juny de 2019, a les 18:38:36 CEST, Jonathan Riddell va 
escriure:
> Is there any interest in making an rsibreak release?  

My next "release rsibreak" reminder is on June 18.

Cheers,
  Albert

> The current release
> has no appstream metadata in it so Discover can not find it to install on
> the new kde apps website.
> 
> Jonathan
> 

Re: Old source files without license header?

[Albert Astals Cid]

Tried LinkedIn ?

Seems to be this guy

https://www.linkedin.com/in/thorsten-st%C3%A4rk-6082755/

Worst case scenario i know someone that works at SAP currently so we could try 
to contact him via internal work email if linkedin fails

Cheers,
  Albert

El dimarts, 11 de juny de 2019, a les 19:50:08 CEST, Alexander Potashev va 
escriure:
> Hi,
> 
> Two weeks ago I tried to contact a former developer of KTimeTracker
> [1] to license two files under GPL. I got no response from him since
> then, but may be we can assume the license is still GPLv2...
> 
> The reasons why it might be OK to just add a GPLv2 license header
> without asking:
>  1. When these "unlicensed" files were committed into KDE SVN
> repository in 2009, the root directory for KTimeTracker sources also
> contained a COPYING file with GPLv2 terms. This could imply that
> anything committed under the directory is automatically licensed under
> GPLv2.
>  2. According to GPLv2+, it's illegal to modify a GPLv2+ project and
> not license it under GPLv2 or later version. Thus, assuming the author
> didn't intend to break the license, we may consider two cases:
>- he intended to license the modified version as GPLv2 (but forgot
> to add the headers into the files),
>- he intended to relicense the modified version as GPLv3. However
> the other files are still under GPLv2, thus this case can't be right.
> 
> IANAL, so what do you think - is it OK to just add GPLv2 license
> headers to files that never had them?
> 
> 
> [1] https://mail.kde.org/pipermail/kde-pim/2019-May/024740.html
> 
> 

KDE Applications 19.08 release schedule

[Albert Astals Cid]

Hi people, 

So that you know this is the release schedule the release team agreed on.

https://community.kde.org/Schedules/Applications/19.08_Release_Schedule

Dependency freeze is in *two* weeks and feature free one after that. Get your 
stuff ready!

Cheers,
  Albert

Re: RFC: Running clang-format across all Plasma (and more?) repos

[Albert Astals Cid]

El dijous, 11 de juliol de 2019, a les 16:18:08 CEST, David Edmundson va 
escriure:
> One topic discussed at the recent Plasma sprint was that we should run
> a code formatting tool (clang-format) over all our repos to ease all
> future review comments about whitespace.
> 
> All new contributions simply have to run the same tool and we get
> consistent code without having to comment on every minor thing in a
> review individually.
> 
> I've written up a wall of text outlining steps, challenges etc.
> https://phabricator.kde.org/T11214
> 
> Does anyone have any thoughts / objections?

If we don't get some sort of precommit hook or "Merge Request" stage support 
it'll be somewhat useless.

"No one" will run the tool manually before doing a commit, this means that 
you'll need to run the tool every N months because commits go ignoring the 
format. I don't think that'd be sustainable in the long runo

I know "automation" is in your plan, but AFAICS only as optional, i don't 
really think that's optional.

Cheers,
  Albert

> 
> David
> 

KDE Applications 19.08 branches created

[Albert Astals Cid]

Make sure you commit anything you want to end up in the 19.08 release to them

We're already past the dependency freeze.

The Freeze and Beta is this Thursday 18 of July.

More interesting dates
 August 1, 2019: KDE Applications 19.08 RC (19.07.90) Tagging and Release
 August 8, 2019: KDE Applications 19.08 Tagging
 August 15, 2019: KDE Applications 19.08 Release

https://community.kde.org/Schedules/Applications/19.08_Release_Schedule

Cheers,
  Albert

Re: Looking for incubator sponsor for Ikona

[Albert Astals Cid]

El dijous, 1 d’agost de 2019, a les 2:44:16 CEST, Carson Black va escriure:
> Greetings,

Hi

> 
> I have been working on a utility called Ikona. Ikona is an application
> with a simple goal - to be a companion to a full fledged editor in
> helping the user design icons. It shows the icons in just about any
> way you want them shown - against a wallpaper, solid background,
> transparent background on a wallpaper, over the KDE HIG, small, big,
> you name it. It also bundles icon templates with sizes and pixel grids
> preconfigured to allow designers to start working on an icon
> immediately without having to set up a canvas. There is also
> functionality for displaying the Breeze color palette and allowing
> easy access to copy its color codes.
> 
> Before anyone asks, no, this does not attempt to do the same thing as
> Cuttlefish. Cuttlefish lists the active icon theme, while Ikona
> displays an icon while it is being worked on by a designer, and
> provides facilities to help icon designers.
> 
> Currently, the team is just me, myself, and I. Considering the
> simplicity of the application, that's all I really see it needing for
> the near future. You can only display an icon so many different ways.
> 
> The project is currently hosted on GitHub, but does not make use of
> any Github-specific features, allowing a change to an open source
> service to be as simple as changing the remote URL and pushing. If it
> needs to be changed before hopping onto KDE infrastructure, I could
> simply just throw it onto Gitlab's Gitlab instance.
> 
> That being said, I'm looking for someone to sponsor Ikona for
> incubation. Anyone would be much appreciated.

I can help you with that. I'll send you an email in private.

First thing i came across, ikona idles at 12% CPU usage here.

Can you reproduce that?

Cheers,
  Albert

> 
> Current URL: https://github.com/Appadeia/ikona
> 
> -- Carson Black [pontaos/appadeia]
> 

Re: SQL Query tool - incubator

[Albert Astals Cid]

El divendres, 9 d’agost de 2019, a les 14:45:23 CEST, Miroslav Špehar va 
escriure:
> Hi all,
> 
> i would like to check if there is some interest into including SQL tool
> into KDE and helping with development. So far the project has (had) two
> developers, me and asw-dev (from github, do not know his actual name).
> 
> This was started because, afaik, there is no application in Qt5 that fits
> into KDE that provides this functionality.
> 
> Anyhow, the code and how it looks like is here:
> https://github.com/mispp/goat
> Some things are missing, some things are not working best, but overall it
> does work.

Your code doesn't build.

CMake Error at CMakeLists.txt:19 (add_executable):
  Cannot find source file:

src/ConnectionStandardItem.cpp

> Incubator requirements, per point:
> 
>- Compliance with the KDE Manifesto -> this is currently hosted on
>github, but it is not a problem to move it to kde infrastructure (gitlab)
>- Governance similar to the other KDE projects -> i cant really judge
>this since this has been a small effort. what does this exactly mean?

It means that once you joing KDE it's not yours anymore, it's ours, because you 
are now us.

>- Clear product vision -> product vision is described in readme. not
>sure if this enough.
>- Healthy team (healthy proportion of volunteers, inclusive towards new
>contributors, ideally more than one developer) -> this is one of the
>issues. reason for reaching out is lack of developer time.

Having a small team is "ok but not great".

But what's not going to happen for you importing your code to KDE's gitlab is 
that suddenly you get 10 new contributors (unless you do some noise about the 
app and sell it to developers) everyone here is already very busy.

I see that the last "code" commit was 10 months ago, that makes me a bit scared 
to be honest.

Cheers,
  Albert

>- Uses English for code and communication -> ok
>- Continuity agreement must be in place with KDE e.V. for domains and
>trademarks if the authors disappear -> ok
>- Recommended to attend Akademy -> this generally is ok, but cannot
>promise since i have to take days off for this.
> 
> According to asw-dev, it is ok to put it into KDE incubator if the license
> stays the same (GPLv3), so this could be a potential issue i guess.
> 
> Let me know what you think.
> 
> BR, Miroslav.
> 

Re: SQL Query tool - incubator

[Albert Astals Cid]

El dimecres, 14 d’agost de 2019, a les 14:24:09 CEST, Miroslav Špehar va 
escriure:
> Hi Albert,
> 
> > El divendres, 9 d’agost de 2019, a les 14:45:23 CEST, Miroslav Špehar va 
> > escriure:
> > > Hi all,
> > >
> > > i would like to check if there is some interest into including SQL tool
> > > into KDE and helping with development. So far the project has (had) two
> > > developers, me and asw-dev (from github, do not know his actual name).
> > >
> > > This was started because, afaik, there is no application in Qt5 that fits
> > > into KDE that provides this functionality.
> > >
> > > Anyhow, the code and how it looks like is here:
> > > https://github.com/mispp/goat
> > > Some things are missing, some things are not working best, but overall it
> > > does work.
> >
> > Your code doesn't build.
> >
> > CMake Error at CMakeLists.txt:19 (add_executable):
> >   Cannot find source file:
> >
> > src/ConnectionStandardItem.cpp
> 
> Probably not with cmake. I tried to convert .pro into cmake, but didnt
> manage to do it since i never touched cmake before.
> To be honest, i actually do not need cmake since qmake works just
> fine, so i just left it for later in the state it is... The idea was
> to move to cmake since kde uses it.

Oh, then remove the file, or fix it, but don't leave it there for people like 
me to try to use it, fail and then be sad.

> 
> > > Incubator requirements, per point:
> > >
> > >- Compliance with the KDE Manifesto -> this is currently hosted on
> > >github, but it is not a problem to move it to kde infrastructure 
> > > (gitlab)
> > >- Governance similar to the other KDE projects -> i cant really judge
> > >this since this has been a small effort. what does this exactly mean?
> >
> > It means that once you joing KDE it's not yours anymore, it's ours, because 
> > you are now us.
> 
> Very clear explanation. I would suggest using this sentence in the wiki page.
> 
> > >- Clear product vision -> product vision is described in readme. not
> > >sure if this enough.
> > >- Healthy team (healthy proportion of volunteers, inclusive towards new
> > >contributors, ideally more than one developer) -> this is one of the
> > >issues. reason for reaching out is lack of developer time.
> >
> > Having a small team is "ok but not great".
> 
> Not great, not terrible :)
> 
> > But what's not going to happen for you importing your code to KDE's gitlab 
> > is that suddenly you get 10 new contributors (unless you do some noise 
> > about the app and sell it to developers) everyone here is already very busy.
> 
> Yes, i am aware of that. one can hope at least for at least some
> casual commits and/or advice / internal design help..
> If not to the application itself, maybe in KPart if someone helps with
> replacement of the custom component with KPart one.
> But one of the reasons for joining into the community is to have support, 
> right?

Yes, we will try to help you, but unless you have a good selling story, people 
are not going to show up and develop stuff.

> 
> > I see that the last "code" commit was 10 months ago, that makes me a bit 
> > scared to be honest.
> >
> > Cheers,
> >   Albert
> 
> Yes, this is actually an issue. I reached the point where it
> more-or-less worked for me, some other design aspects i had an issue
> with, so i kinda just thought to left it for a while.
> I am thinking to put some effort into it once kubuntu 19.10 (plasma
> 5.17?) comes out, so let's see if i get distracted with stuff like
> golang/rust.
> 
> As i said, this is just a check to see what you guys think about this
> idea, especially since there is no alternative for this development
> tool in kde ecosystem (not considering jetlabs and java apps).
> I can also keep it as it is and come back when it is more mature.

This last paragraph leaves me with a "i don't know what to say" feeling, it 
seems that it works for you, which is nice, but if you want to move from "pet 
project" to "this is something i want people to use" you can't say "let's see 
if i get distracted" because what we don't want is to incubate projects to have 
them just die the second after they join.

So I guess the real question here is, how commit are you to make this a serious 
project? One where you make releases and tell the world "hey there's this nice 
thing, come and use it" and then take all the [potentially negative] feedback 
and try to make the app better, and then rinse and repeat.

Cheers,
  Albert

> 
> Thanks for reading.
> 
> Best regards,
> Miroslav.
> 

Re: Flatpak/Snap/Appimage BoF at Akademy

[Albert Astals Cid]

El dilluns, 26 d’agost de 2019, a les 16:58:34 CEST, Aleix Pol va escriure:
> On Mon, Aug 26, 2019 at 6:58 AM Jan Grulich  wrote:
> >
> > Hi,
> >
> > do we want to do another Flatpak/Snap/Appimage BoF at Akademy this year? 
> > From
> > my side it definitely can be useful and we can also have new people around
> > this time and help them to package their applications if anyone is 
> > interested.
> >
> > Which day would you prefer? There is AGM on Monday and a daytrip on 
> > Wednesday,
> > while most of the Tuesday is taken by Plasma, which is where I expect most 
> > of
> > the people. Does Thursday sound good to you?
> 
> Works for me, yes.

I'll be around on Thursday too :)

Cheers,
  Albert

> 
> See you in Milan!
> Aleix
> 

Re: RFC: Apps using KF5 & deprecated API - preferred flags to disable/enable warnings and/or API?

[Albert Astals Cid]

El dilluns, 9 de setembre de 2019, a les 19:28:11 CEST, Friedrich W. H. 
Kossebau va escriure:
> Hi,
> 
> developer using KDE Frameworks libraries in your projects, how would you like 
> to be able to control warnings about deprecated API in those libraries? Or 
> control the visibility of deprecated API to your code when building?
> 
> There is a prototype to enhance KDE Frameworks API, so developers building 
> against KDE Frameworks libraries could use flags like
> 
> -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0xXYZ
> -DKF_DEPRECATED_WARNINGS_SINCE=0xXYZ
> -DKF_NO_DEPRECATED_WARNINGS
> -DKF_NO_DEPRECATED

Can you explain what are they supposed to do?

When we understand their purpose we may suggest better names?

i have the feeling the last two do kind of opposite things though the names are 
very similiar?

Cheers,
  Albert


> as well as individual specializations per library, e.g.
> -DKCOREADDONS_DISABLE_DEPRECATED_BEFORE_AND_AT=0xXYZ
> -DKCOREADDONS_DEPRECATED_WARNINGS_SINCE=0xXYZ
> -DKCOREADDONS_NO_DEPRECATED_WARNINGS
> -DKCOREADDONS_NO_DEPRECATED 
> 
> following the similar macros introduced with Qt 5.13.
> 
> Additionally this feature also would allow to do custom builds of the KF 
> libraries without code for the deprecated API:
> -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=0xXYZ
> So apps bundling the libraries (AppImage, APK, DMG, etc) could save a bit on 
> size, if they do not need the deprecated API.
> 
> This prototype is ECMGenerateExportHeader, up at https://phabricator.kde.org/
> D23789
> 
> So, would those macros be useful to you in your KF5-using projects?
> Where would you like things differently?
> 
> Cheers
> Friedrich
> 
> 
> 

Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

[Albert Astals Cid]

I find the merge behavior to be not what we've been doing in phabricator so 
given the idea is to maintain our workflows i'd appreciate if we can agree on 
continue doing the same.

https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html

Opinions?

Cheers,
  Albert

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

[Albert Astals Cid]

El dimarts, 15 d’octubre de 2019, a les 9:16:48 CEST, Frederik Schwarzer va 
escriure:
> 
> Am 14.10.2019 22:51 schrieb Johan Ouwerkerk:
> > On 14.10.2019 21:22, Frederik Schwarzer wrote:
> >> If however, master had seen commits as well, fast-forwarding is
> >> performing a rebase ... is that correct?
> > 
> > The workflow would be: whenever master is updated, you rebase your
> > local feature/work branch and force-push to the remote copy of the
> > feature/work branch.
> 
> This is exactly the problem I see.
> I create a branch.
> I start to use, let's say ... KDialog in my feature as KDialog has been 
> used throughout the application and make 20 commits.
> Now on master, someone merges a branch that replaces all the KDialogs 
> with overlays and removes all KDialog includes.
> So if I rebase on that, all my 20 commits will fail to build. Checking 
> out an older revision to test something will not work.
> Now I will fix my latest revision and merge to master. Still: 19 commits 
> are not compiling anymore.
> 
> Or am I missing something here?
> 
> How would we deal with that? Is "short-lived branches" (as you stated 
> below) enough to reduce the risk?

You have the same problem with arc, arc rebases, so if we had no problem until 
now, we have no problem now.

Cheers,
  Albert

> 
> Cheers
> Frederik
> 
> 
> 

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 19:27:07 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 7:18 AM Alexander Potashev  
> wrote:
> >
> > сб, 9 нояб. 2019 г. в 03:20, Ben Cooksley :
> > > This would include the shutdown of WebSVN in particular, which when
> > > coupled with the shutdown of our two CGit instances would also allow
> > > for us to eliminate an entire virtual machine from our systems.
> >
> > Will there be any web interface for SVN after shutdown of WebSVN?
> >
> > Can we assume https://phabricator.kde.org/source/svn/ remains
> > available during the next 10 years?
> >
> 
> Phabricator's browser will be retired as part of the shutdown of
> Phabricator, which will take place once Gitlab has assumed
> responsibility for code hosting and review, and the tasks have been
> migrated from Phabricator.
> 
> Should WebSVN be shutdown as well, then there would be no web
> interface to our SVN repository.

That's not acceptable.

Cheers,
  Albert

> 
> >
> > I'm not sure what use case Luigi has in mind, but among Russian l10n
> > team we often use WebSVN to refer to specific SVN revisions, for
> > example: https://websvn.kde.org/?view=revision&revision=1555342
> >
> > --
> > Alexander Potashev
> 
> Regards,
> Ben
> 

Re: Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 18:47:57 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 12:29 AM Luigi Toscano  
> wrote:
> >
> > Ben Cooksley ha scritto:
> > > Hi all,
> > >
> > > In the category of code related services, Sysadmin currently supports
> > > a wide-ranging number of services (which makes sense given the nature
> > > of the community). Some of these however may no longer be in use or
> > > will be duplicative of other services following the transition to
> > > Gitlab.
> > >
> > > In the category of duplicative, we have our two CGit instances at
> > > cgit.kde.org and packaging.neon.kde.org. Prior to Gitlab, these were
> > > justifiable as there was no other way of browsing scratch/clone
> > > repositories over the web.
> > >
> > > With the migration to Gitlab however all repositories will become
> > > browsable through it, meaning it no longer makes sense to offer two
> > > browsers that provide the exact same information (with Gitlab having
> > > greater capabilities). I'd therefore like to shut both of these down
> > > once Code Hosting has transitioned to Gitlab.
> >
> > Luckily we tried to use commits.kde.org as generic redirect. Will the 
> > generic
> > redirect commits.kde.org be updated to point to the proper repository? It 
> > may
> > be complicated if the new structure contains the namespaces for each
> > repository, but we need to keep it working.
> 
> The commits.kde.org redirector is intended to provide permanent links,
> so yes it will be updated to redirect people to Gitlab instead once
> the switch to Gitlab is completed.
> 
> >
> > >
> > > In the category of no longer in use, we have the compatibility
> > > generator for the kde_projects.xml file. This was introduced when we
> > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > keeping services that needed to discover a list of KDE Projects
> > > functional.
> > >
> > > As we've since migrated to using YAML files within the
> > > sysadmin/repo-metadata repository for both the CI System and
> > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > checkouts) there shouldn't to my knowledge be anything still relying
> > > on this (aside from perhaps scripty).>
> > > I'd therefore like to shut this generator down as well, along with the
> > > compaibility redirector running at projects.kde.org (given that it has
> > > been some time since we were using that site, and many projects have
> > > moved around in the virtual structure since then, making the redirects
> > > it is able to offer useless)
> >
> > Two points:
> > - scripty still uses the XML file and we may need some time to migrate.
> 
> I feared this may have been the case. What sort of timeline are we
> looking at in terms of switching scripty over?

Over to what?

Cheers,
  Albert

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 21:22:16 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 8:37 AM Albert Astals Cid  wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 19:27:07 CET, Ben Cooksley va 
> > escriure:
> > > On Sun, Nov 10, 2019 at 7:18 AM Alexander Potashev  
> > > wrote:
> > > >
> > > > сб, 9 нояб. 2019 г. в 03:20, Ben Cooksley :
> > > > > This would include the shutdown of WebSVN in particular, which when
> > > > > coupled with the shutdown of our two CGit instances would also allow
> > > > > for us to eliminate an entire virtual machine from our systems.
> > > >
> > > > Will there be any web interface for SVN after shutdown of WebSVN?
> > > >
> > > > Can we assume https://phabricator.kde.org/source/svn/ remains
> > > > available during the next 10 years?
> > > >
> > >
> > > Phabricator's browser will be retired as part of the shutdown of
> > > Phabricator, which will take place once Gitlab has assumed
> > > responsibility for code hosting and review, and the tasks have been
> > > migrated from Phabricator.
> > >
> > > Should WebSVN be shutdown as well, then there would be no web
> > > interface to our SVN repository.
> >
> > That's not acceptable.
> 
> Mind explaining why?

Because we use it in l10n.kde.org to link to po files.

> Bear in mind that there is a cost both in terms of infrastructure, and
> people time to maintain a service such as WebSVN.

We have money, we don't have to shut down things we use because there is a cost.

Cheers,
  Albert

> This includes having to maintain a mirror of the repository on the
> machine that runs WebSVN, along with the associated infrastructure for
> allowing that mirroring to happen on the master server.
> 
> >
> > Cheers,
> >   Albert
> 
> Regards,
> Ben
> 
> >
> > >
> > > >
> > > > I'm not sure what use case Luigi has in mind, but among Russian l10n
> > > > team we often use WebSVN to refer to specific SVN revisions, for
> > > > example: https://websvn.kde.org/?view=revision&revision=1555342
> > > >
> > > > --
> > > > Alexander Potashev
> > >
> > > Regards,
> > > Ben
> > >
> >
> >
> >
> >
>