DragonPlayer

[Nate Graham]

Hello all,
Sad to say, DragonPlayer seems dead-ish. It hasn't gotten any code 
changes since January of this year. Kubuntu has stopped shipping it by 
default, replacing it with VLC. Bugzilla tickets continue to pile up.


What's the way forward here? Should we look for a new maintainer or 
admit defeat and just recommend VLC or MPV or something else?


Nate Graham

Re: To start contributing to kde and participate in soK as a student.

[Nate Graham]

Welcome onboard, Siva!

In general, here are some links that might be useful to you:
- https://community.kde.org/Get_Involved
- https://community.kde.org/Get_Involved/development
- https://community.kde.org/Infrastructure/Phabricator

If you already use KDE software, you may have some ideas about what 
features you'd like to implement and bugs you'd like to fix. Great! If 
not, now's a great time to start using Plasma and KDE software, and 
here's a good list of usability and polish bugs that we're currently 
about to start focusing on:


https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=usability&keywords_type=allwords&list_id=1478494&order=product%2Cchangeddate%20DESC%2Cbug_status%20DESC%2Cresolution%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced

Let us know once you start working on something!

Nate Graham




On 12/15/2017 06:33 AM, Siva Kumaran wrote:
I am new to the organization and would like to participate in soK as a 
student.

I am quite familiar with c++.
Can you please guide me on how to proceed.

Re: Looking for mentor for new KDE developer

[Nate Graham]

On 01/04/2018 07:23 AM, Christian Gerloff wrote:

Hello all,

I've recently ported the unmaintained KDE application "KuickShow" to KDE
5 and plan to at least keep it working in the forseeable future.
In order to get a KDE developer account to maintain the application on
the KDE infrastructure, it was suggested that I first find a mentor in
case I have questions about infrastructure, development workflows,
translations and so on.

Would anyone be willing to do that?

Thanks,
Christian



Hi Christian,
Thanks for taking the initiative here! Would you consider using your 
talents to work on Gwenview instead of KuickShow? Gwenview is similarly 
unmaintained and in need of a new maintainer, but already using KF5 and 
more commonly used today. It might be better to standardize on a single 
image viewer to make sure we can have one really solid offering rather 
than diluting our limited resources among two that as a result both are 
crying out for more attention.


Nate

Re: Looking for mentor for new KDE developer

[Nate Graham]

We are still looking for a maintainer. Henrik Fehlauer is kindly helping 
Gwenview limp along--submitting many patches, and reviewing others. 
Peter Mühlenpfordt and I have also submitted a few patches. But it's 
mostly just maintenance work, not actual maintainership or technical 
leadership.


At this point Henrik seems like the natural candidate, but he's 
mentioned that he lacks the time. Maybe Blue Systems should hire him to 
do it... ;-)


Nate


On 01/14/2018 01:32 PM, Kai Bojens wrote:

Am 2018-01-04 15:35, schrieb Nate Graham:

Gwenview is similarly unmaintained and in need of a new maintainer, 
but already

using KF5 and more commonly used today.


Is there any ongoing discussion about its current development? The 
mailing list seems to be dead and the forum is filled with feature 
requests and user support.

Re: KDE and Google Summer of Code 2018

[Nate Graham]

I've submitted an idea for System Settings: Improve handling for 
touchpads and mice with Libinput


https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput

This is pretty important going forward since most distros are shipping 
with Libinput now, but our users aren't able to configure their devices 
without resorting to editing xorg config files using a different driver.


Nate


On 01/15/2018 06:13 AM, Dmitry Kazakov wrote:

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
mailto:valorie.zimmer...@gmail.com>> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

git repo issues

[Nate Graham]

Hello Ben (et al),
I've noticed that in the last hour, git commits don't seem to show up in 
the web interface. Examples:


https://phabricator.kde.org/D10143 -> commit shows up in git history, 
but does not appear on https://cgit.kde.org/baloo-widgets.git


https://phabricator.kde.org/D10131 -> commit shows up in git history, 
but does not appear on https://cgit.kde.org/discover.git


Mind taking a look?

Thanks!


Nate Graham

Re: git repo issues

[Nate Graham]

Thanks a bunch! Looks like the missing commits are tricking back into 
the web interface.


Nate


On 01/27/2018 12:23 PM, Ben Cooksley wrote:

On Sun, Jan 28, 2018 at 4:54 AM, Nate Graham  wrote:

Hello Ben (et al),


Hi Nate,


I've noticed that in the last hour, git commits don't seem to show up in the
web interface. Examples:

https://phabricator.kde.org/D10143 -> commit shows up in git history, but
does not appear on https://cgit.kde.org/baloo-widgets.git

https://phabricator.kde.org/D10131 -> commit shows up in git history, but
does not appear on https://cgit.kde.org/discover.git

Mind taking a look?


Some changes I made to the post-update hook (which trigger the anongit
propagation process) unfortunately had a typo, leading to the hook
failing.
I've now corrected that and are triggering the hook for all
repositories - this should get the system back in sync again.

Jenkins will be doing builds as it normally would as this triggering
takes place.



Thanks!


Nate Graham



Cheers,
Ben

Re: Baloo is not dead, it just smells a little funny

[Nate Graham]

Thanks Ben, and thanks Michael for this effort! Our users are really 
going to appreciate it. I plan to run promo on this to try to counteract 
some of the negativity out there.


While we're on the subject of Phabricator projects, Ben, do you think 
you could also create a formal project for Gwenview, too?


Nate

Re: Need enlightenment on bug 318998; Add option to exit after printing

[Nate Graham]

1. Yes. It looks like the original request was for an additional 
--print_and_exit option, which would quit after closing the print dialog.


2. it might be nice to control that with another option, actually. More 
flexibility.


Nate



On 02/01/2018 12:21 PM, Dileep Sankhla wrote:
Hello, I'm working on a bug in okular 
https://bugs.kde.org/show_bug.cgi?id=318998 and I'm unable to develop 
the clear understanding of the bug. Here is my question:


1. What does the issue actually mean - adding an option to automatically 
exit with

the exit code and message after acknowledging the print dialog when launched
with --print parameter or adding a separate parameter option as
--print_and_exit that do the same? Or is it something different? Confuse
between improving an existing parameter or adding a new parameter for 
the same.


2. Regarding the point 1, should the print dialog being shown or should 
it be without any GUI as the command line batch processing is 
specifically mentioned in the bug?



Thanks and Regards,
Dileep


‌

Re: Adding application to KDE and getting image of current

[Nate Graham]

I love the idea of annotations built into a screenshot tool! Our users 
have been asking for this.


However, I hate to be that guy, but have you considered extending 
Spectacle instead? Spectacle is mature, well-integrated into KDE Plasma, 
has all the features highlighted on 
https://github.com/DamirPorobic/ksnip (except for editing and 
annotation), and it's already shipped by default in all KDE distros that 
I'm aware of. Your work would have a hugely greater impact if you 
extended Spectacle instead!


Nate Graham



On 02/03/2018 05:30 AM, Damir Porobic wrote:

The link that gives a hint on what needs to be done is under the "Incubated Projects" 
section, I've expected it under "Incubation Process".
  
I've created a page based on the template and added a link to "Incubated Projects" under "Candidates", don't know if I was supposed to do that or someone else:

https://community.kde.org/Incubator/Projects/Ksnip
  
And here is the repo: https://github.com/DamirPorobic/ksnip
  
Was that so far correct and according to the process? If yes, what's supposed to happen next?


About the application, Ksnip is a screenshot annotation tool, which can also 
take screenshots itself. I've started to work on it as I was missing some tool 
to annotate screenshots which I have taken via Spectacle, which is a great 
screenshot tool, but as said, the annotation features were missing in my 
opinion.

Damir


Sent: Fri, 02 Feb 2018 12:52:01 -0800
From: pointedstick 
To: 
Subject: Re: Adding application to KDE and getting image of current
 cursor under wayland
Message-ID: <161584a51bb.10ff69e3b3883.5474288975285038...@zoho.com>
Content-Type: text/plain; charset="UTF-8"

 On Fri, 02 Feb 2018 11:50:13 -0800 Damir Porobic 
wrote 
  > Sorry, one more question regarding the incubator process. It's not obvious 
to me how one application/project becomes a Candidate?
  > On the link https://community.kde.org/Incubator/Incubation_Process it is 
mentioned what a Candidate needs to provide, but not where and in what form.

Starting here is a good bet!

What's the app you're proposing?

Nate


Sent: Fri, 2 Feb 2018 21:56:04 +0100
From: Luigi Toscano 
To: kde-devel@kde.org
Subject: Re: Adding application to KDE and getting image of current
 cursor under wayland
Message-ID: 
Content-Type: text/plain; charset=UTF-8

Damir Porobic ha scritto:

Sorry, one more question regarding the incubator process. It's not obvious to 
me how one application/project becomes a Candidate?
On the link https://community.kde.org/Incubator/Incubation_Process it is 
mentioned what a Candidate needs to provide, but not where and in what form.


With a written statement on a public place, like for example the kde-community
list. Here few past examples:

https://mail.kde.org/pipermail/kde-community/2013q4/000375.html
https://mail.kde.org/pipermail/kde-community/2014q1/000552.html
https://mail.kde.org/pipermail/kde-community/2014q2/000787.html
https://mail.kde.org/pipermail/kde-community/2015q2/001374.html

Which kind of application are we talking about?

Ciao

Re: Adding application to KDE and getting image of current

[Nate Graham]

I know, my answer sucks. I really do hate to have to bring it up. And I 
don't mean to throw cold water on your project or your enthusiasm! KSnip 
looks cool.


The thing is, single-developer projects tend to have a predictable 
lifecycle: lots of energy and progress in the beginning, then around 
year two or three, the developer loses interest or gets too busy, and 
then the app stagnates for a few years and finally dies of bit-rot. It 
isn't *always* the case, but I've seen it too many times to ignore the 
pattern.


Spectacle itself narrowly avoided this fate when community members took 
an interest and stepped up when its lead developer left at the beginning 
of 2017. It is now fairly healthy, under somewhat active development, 
and no longer so fragile.


With your development skills and current level of enthusiasm, I think 
Spectacle could advance very rapidly, and your work on it would benefit 
*every* KDE user very quickly. The alternative is that we have two 
screenshot apps, splitting development effort between the two and making 
both more fragile and likely to fail in response to developers losing 
interest.


I won't stand in the way of making KSnip a KDE app if others think 
approve, but I want to bring this up as a long-term strategic matter. I 
think we all benefit from having one really strong choice that's 
developed by many.


Nate Graham



On 02/03/2018 11:02 AM, Damir Porobic wrote:

Yeah, I was kind of afraid that you would say that.

When I started to work on the project I hadn't thought about extending any 
other projects, mostly due to my limited knowledge of Qt at that time. Now I 
have invested a lot of time and effort into this project and it seems to be 
working fine and users are happy.
Also, KSnip was written mostly with the idea to provide annotations and with 
Spectacle I see the focus on screenshots and I've got the feeling that it would 
require a lot of refactoring and wouldn't be doable just like that.

Regards,
Damir
  


Sent: Saturday, February 03, 2018 at 6:30 PM
From: "Nate Graham" 
To: kde-devel@kde.org
Subject: Re: Adding application to KDE and getting image of current
I love the idea of annotations built into a screenshot tool! Our users
have been asking for this.

However, I hate to be that guy, but have you considered extending
Spectacle instead? Spectacle is mature, well-integrated into KDE Plasma,
has all the features highlighted on
https://github.com/DamirPorobic/ksnip (except for editing and
annotation), and it's already shipped by default in all KDE distros that
I'm aware of. Your work would have a hugely greater impact if you
extended Spectacle instead!

Nate Graham



On 02/03/2018 05:30 AM, Damir Porobic wrote:

The link that gives a hint on what needs to be done is under the "Incubated Projects" 
section, I've expected it under "Incubation Process".

I've created a page based on the template and added a link to "Incubated Projects" under 
"Candidates", don't know if I was supposed to do that or someone else:
https://community.kde.org/Incubator/Projects/Ksnip[https://community.kde.org/Incubator/Projects/Ksnip]

And here is the repo: 
https://github.com/DamirPorobic/ksnip[https://github.com/DamirPorobic/ksnip]

Was that so far correct and according to the process? If yes, what's supposed 
to happen next?

About the application, Ksnip is a screenshot annotation tool, which can also 
take screenshots itself. I've started to work on it as I was missing some tool 
to annotate screenshots which I have taken via Spectacle, which is a great 
screenshot tool, but as said, the annotation features were missing in my 
opinion.

Damir


Sent: Fri, 02 Feb 2018 12:52:01 -0800
From: pointedstick 
To: 
Subject: Re: Adding application to KDE and getting image of current
cursor under wayland
Message-ID: <161584a51bb.10ff69e3b3883.5474288975285038...@zoho.com>
Content-Type: text/plain; charset="UTF-8"

 On Fri, 02 Feb 2018 11:50:13 -0800 Damir Porobic 
wrote 

Sorry, one more question regarding the incubator process. It's not obvious to 
me how one application/project becomes a Candidate?
On the link 
https://community.kde.org/Incubator/Incubation_Process[https://community.kde.org/Incubator/Incubation_Process]
 it is mentioned what a Candidate needs to provide, but not where and in what 
form.


Starting here is a good bet!

What's the app you're proposing?

Nate


Sent: Fri, 2 Feb 2018 21:56:04 +0100
From: Luigi Toscano 
To: kde-devel@kde.org
Subject: Re: Adding application to KDE and getting image of current
cursor under wayland
Message-ID: 
Content-Type: text/plain; charset=UTF-8

Damir Porobic ha scritto:

Sorry, one more question regarding the incubator process. It's not obvious to 
me how one application/project becomes a Candidate?
On the link 
https://community.kde.org/Incubator/Incubation_Proc

Re: Adding application to KDE and getting image of current

[Nate Graham]

Thanks so much for understanding! Spectacle currently has no formal 
maintainer, but myself and a few others are serving this role in a de 
facto capacity. The Spectacle Phabricator project 
(https://phabricator.kde.org/project/view/78/) would be a good place to 
coordinate. We would welcome a major code refactor if it would help us 
get this much-wanted feature.


FYI we already have an open UI redesign project 
(https://phabricator.kde.org/T7841). And look, somebody requested the 
exact feature you've already got some experience in implementing! ;) 
https://phabricator.kde.org/T6321


Happy coding,

Nate Graham


On 02/03/2018 01:15 PM, Damir Porobic wrote:

I do see your point here and it indeed makes sense. I could invest some time 
and add the annotation features (and eventually other stuff) to Spectacle. The 
lack of those features is actually the reason why we're having this discussion, 
so it would make sense to resolve them.
Does Spectacle have a maintainer at the moment? As said, I my opinion, 
Spectacle requires some redesign in order to provide annotations and be usable 
as other Screenshot application that are currently in use. With whom would I 
need to coordinate this. Don't want just to fork the repo, do all kind of 
changes to hear in the end that I can't or should do that. What would be my 
starting point?

Damir
  


Sent: Saturday, February 03, 2018 at 8:36 PM
From: "Nate Graham" 
To: kde-devel@kde.org
Subject: Re: Adding application to KDE and getting image of current
I know, my answer sucks. I really do hate to have to bring it up. And I
don't mean to throw cold water on your project or your enthusiasm! KSnip
looks cool.

The thing is, single-developer projects tend to have a predictable
lifecycle: lots of energy and progress in the beginning, then around
year two or three, the developer loses interest or gets too busy, and
then the app stagnates for a few years and finally dies of bit-rot. It
isn't *always* the case, but I've seen it too many times to ignore the
pattern.

Spectacle itself narrowly avoided this fate when community members took
an interest and stepped up when its lead developer left at the beginning
of 2017. It is now fairly healthy, under somewhat active development,
and no longer so fragile.

With your development skills and current level of enthusiasm, I think
Spectacle could advance very rapidly, and your work on it would benefit
*every* KDE user very quickly. The alternative is that we have two
screenshot apps, splitting development effort between the two and making
both more fragile and likely to fail in response to developers losing
interest.

I won't stand in the way of making KSnip a KDE app if others think
approve, but I want to bring this up as a long-term strategic matter. I
think we all benefit from having one really strong choice that's
developed by many.

Nate Graham



On 02/03/2018 11:02 AM, Damir Porobic wrote:

Yeah, I was kind of afraid that you would say that.

When I started to work on the project I hadn't thought about extending any 
other projects, mostly due to my limited knowledge of Qt at that time. Now I 
have invested a lot of time and effort into this project and it seems to be 
working fine and users are happy.
Also, KSnip was written mostly with the idea to provide annotations and with 
Spectacle I see the focus on screenshots and I've got the feeling that it would 
require a lot of refactoring and wouldn't be doable just like that.

Regards,
Damir


Sent: Saturday, February 03, 2018 at 6:30 PM
From: "Nate Graham" 
To: kde-devel@kde.org
Subject: Re: Adding application to KDE and getting image of current
I love the idea of annotations built into a screenshot tool! Our users
have been asking for this.

However, I hate to be that guy, but have you considered extending
Spectacle instead? Spectacle is mature, well-integrated into KDE Plasma,
has all the features highlighted on
https://github.com/DamirPorobic/ksnip (except for editing and
annotation), and it's already shipped by default in all KDE distros that
I'm aware of. Your work would have a hugely greater impact if you
extended Spectacle instead!

Nate Graham



On 02/03/2018 05:30 AM, Damir Porobic wrote:

The link that gives a hint on what needs to be done is under the "Incubated Projects" 
section, I've expected it under "Incubation Process".

I've created a page based on the template and added a link to "Incubated Projects" under 
"Candidates", don't know if I was supposed to do that or someone else:
https://community.kde.org/Incubator/Projects/Ksnip[https://community.kde.org/Incubator/Projects/Ksnip][https://community.kde.org/Incubator/Projects/Ksnip[https://community.kde.org/Incubator/Projects/Ksnip]]

And here is the repo: 
https://github.com/DamirPorobic/ksnip[https://github.com/DamirPorobic/ksnip][https://github.com/DamirPorobic/ksn

Re: Framework testing

[Nate Graham]

I'll tell you what I do, at the risk of embarrassing myself.

I do all my development in a KDE Neon VM. When I need to patch or test a 
framework, I make a snapshot in the VM in case things go bad, then 
deploy the patched/edited framework to /usr (`cmake 
-DCMAKE_PREFIX_PATH=/usr && make && sudo make install) and then open a 
program that uses the framework to test out the change. For 
baloo-widgets for example, the changes would be visible in Dolphin.


This is probably pretty caveman-level, but it works for me so far.

Nate


On 02/04/2018 02:27 PM, Marijo Mustac wrote:

Hi @all,

First of all I like to introduce myself. My name is Marijo I'm 26 years 
old and from Germany. My programming skills are limited to PHP until now 
but I would like to contribute to KDE in the near future. So far so good.


At the moment I work on some frameworks like KIO and baloo-widgets and 
encountered some problems. My first patch on Phabricator was easy going 
because it touched Dolphin - a stand alone application as you all know.


I posted my question already on Google+ and Mykola Krachkovsky was so 
kind to help Mr but unfortunately I didn't get it. He told me something 
about protocol files but I don't know it this is tackling my problem... 
I just want to know how can I test these frameworks where I made code 
adjustments? I can compile them and see if there are any errors but I 
until now I don't know how can I check if my code ist also working 
properly.


To be more precise let's say I am working on the KNewFileMenu from KIO 
and the MetaDataWidget from baloo-widgets, how does it work to test these?


I apologize it this is a stupid question but I didn't find an answer on 
my own.


Regards

Marijo

https://phabricator.kde.org/ seems to be down

[Nate Graham]

Any chance of resuscitation?

Nate

Re: Closing old Plasma 4 bugs

[Nate Graham]

+ 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?

Nate

Re: Closing old Plasma 4 bugs

[Nate Graham]

All right, so let's give it a shot. How about we make it so that normal 
users have full privilages except the following:


- Can't bulk change
- Can't change Importance field
- Can't re-open bugs in the CLOSED state

Nate



On 02/11/2018 09:17 AM, David Edmundson wrote:


Interesting. If the broader community is okay with this I see no
reason why we couldn't rearrange the permissions and how they're
currently setup.
I would prefer to restrict the bulk change tools to developers still
(as undoing the damage they do is much harder) but one-by-one changes
should be fine to release I think.

Totally fine with it, I think it'll really help. I've ended up filing 
quite a few sysadmin requests requesting editbugs be granted to various 
people.


I'd like it to keep it so that even if normal users can reopen bugs from 
resolved, they can't from closed.


David

Re: Closing old Plasma 4 bugs

[Nate Graham]

> On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:
> 
>> On Wed, Feb 21, 2018 at 9:34 AM, pointedstick  wrote:
>> I have editbugs power on bugs.kde.org, but cannot edit the Importance field
>> or mark a bug as CLOSED on bugstest.kde.org. I appear to have the new normal
>> permissions.
> 
> Thanks for confirming my testing Nate.
> 
> I've now gone ahead and rolled this out on bugs.kde.org.
> Everyone who had editbugs rights already (all 3,221 of us) have been
> made members of the new (fully empowered) contributors group.
> 
> If someone would like to announce this via a blog post please feel
> free to do so as I likely won't have time in the next few days to do
> so.

Fantastic! I'll do that. 

Nate

Re: Closing old Plasma 4 bugs

[Nate Graham]

On 02/21/2018 06:26 AM, Nate Graham wrote:




On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:


On Wed, Feb 21, 2018 at 9:34 AM, pointedstick  wrote:
I have editbugs power on bugs.kde.org, but cannot edit the Importance field
or mark a bug as CLOSED on bugstest.kde.org. I appear to have the new normal
permissions.


Thanks for confirming my testing Nate.

I've now gone ahead and rolled this out on bugs.kde.org.
Everyone who had editbugs rights already (all 3,221 of us) have been
made members of the new (fully empowered) contributors group.

If someone would like to announce this via a blog post please feel
free to do so as I likely won't have time in the next few days to do
so.


Fantastic! I'll do that.


Done: 
https://pointieststick.wordpress.com/2018/02/21/its-now-much-easier-to-be-a-bug-triager/


Nate

Re: Closing old Plasma 4 bugs

[Nate Graham]

I have also cleaned up the bug triaging page: 
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging


It's still a bit long, so any further editing to condense it a bit would 
be welcome.


Nate



On 02/21/2018 07:16 AM, Nate Graham wrote:



On 02/21/2018 06:26 AM, Nate Graham wrote:




On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:

On Wed, Feb 21, 2018 at 9:34 AM, pointedstick 
 wrote:
I have editbugs power on bugs.kde.org, but cannot edit the 
Importance field
or mark a bug as CLOSED on bugstest.kde.org. I appear to have the 
new normal

permissions.


Thanks for confirming my testing Nate.

I've now gone ahead and rolled this out on bugs.kde.org.
Everyone who had editbugs rights already (all 3,221 of us) have been
made members of the new (fully empowered) contributors group.

If someone would like to announce this via a blog post please feel
free to do so as I likely won't have time in the next few days to do
so.


Fantastic! I'll do that.


Done: 
https://pointieststick.wordpress.com/2018/02/21/its-now-much-easier-to-be-a-bug-triager/ 



Nate

Re: Plasma Vault and BUG:390830

[Nate Graham]

Maybe automatically disable indexing for cryfs and encfs volumes, no 
matters where they live? Vault allows you to change the default location 
of your vault, I believe.


Nate


On 02/24/2018 01:57 AM, Michael Heidelbach wrote:

Hi!

The best option to fix this bug is by excluding Vaults from being 
searched by baloo.


Do that, I need to know how to distinguish vaults from normal folders 
(and other mountpoints)


On first glance it appears they are all under ~/Vaults, please confirm. 
What about localization?



Cheers,

Michael

Re: Latte Dock and tangerine font

[Nate Graham]

Maybe create a Phabricator task and see which VDG people show up? Andres 
Betts was the primary creator of Falkon's logo; he's really great with 
that sort of thing.


Nate


On 02/27/2018 05:43 PM, Valorie Zimmerman wrote:

This discussion is icky to me.

1. I do not want to login to Github to discuss a KDE project

2. We are not engaging with the authors and maintainer to make this 
application fully within the KDE community (which includes licensing)


3. The discussion is about licensing instead of helping to improve the 
logo by bringing in the VDG. The VDG just created a kickass logo for 
Falkon; surely they can make something better than the Latte Dock 
present logo?


Valorie

On Tue, Feb 27, 2018 at 6:45 AM, Michail Vourlakos > wrote:


Jonathan can you please participate at:
https://github.com/psifidotos/Latte-Dock/issues/884#issuecomment-368876977


for this?

the ubuntu member I think responded there...

2018-02-27 14:52 GMT+02:00 Jonathan Riddell mailto:j...@jriddell.org>>:

On 27 February 2018 at 09:24, Michail Vourlakos
mailto:mvourla...@gmail.com>> wrote:
> Today I received from RikMills that Latte was rejected from ubuntu 
because
> it contains an OPL-licensed font (tangerine).
>
> The discussion is at: 
https://github.com/psifidotos/Latte-Dock/issues/884

>
> The font is used just for a label in the configuration window to draw 
the
> "Latte"  text at the top-left corner. I thought that an alternative 
could be
> to just screenshot the label in a png and use that one and drop 
totally the
> tangerine font distrubution through Latte code...
>
> Do you have any ideas what we can do for this and if this is 
acceptable for
> OPL?

Font licencing is a bit of a quagmire but I really don't see any
issue here.

The font is freely licenced and .ttf can be considered preferred
modifiable form so there's no freedom issue.

He says "Source embeds and uses at runtime a GPL-incompatible
(OPL-Licensed) font; "  but I see no embedding happening, it just
ships the file which doesn't make it a derived work.  Loading a font
file at runtime is done by every GUI program very often, it doesn't
make it a derived work so there's no effect on copyleft licencing
requirements.

I recommend Ubuntu discuss this with their archive admins to see why
they consider it a derived work.  I am an Ubuntu archive admin
and can
take part in that conversation if wanted.  If that doesn't get
anywhere then play a political workaround and just upload it without
the .ttf font, I presume the text where it's used will just fall
back
to some other font.  Maybe Latte-dock code can be changed to
explicitly fall back to a generic cursive font if it doesn't find it
but only if there's a desire to go out of the way for incorrectly
applied rules.

Jonathan





--
http://about.me/valoriez

Recent disk mounting regressions in Solid framework

[Nate Graham]

Howdy folks,
What are we going to do about https://bugs.kde.org/show_bug.cgi?id=391706?

This regression made it into a Manjaro release and was noticed by Igor 
Ljubuncic in 
https://www.dedoimedo.com/computers/manjaro-17-1-6-hakoila-plasma.html:


> Also, if you try to mount internal volumes (hard disks and/or
> partitions), even if you click only once, Dolphin will complain that
> the filesystem is already mounted rather than accessing it. So you
> waste time seeing both a bogus error and navigating to the right path.
> Why? Especially since this does NOT happen in KDE neon, also installed
> on this same box, with the same Plasma framework.

Looks like the Arch folks cherry-picked the patch, which is why Igor saw 
it in Manjaro despite using the same Frameworks version in Neon.


The regression was caused by the fix for a related regression 
(https://bugs.kde.org/show_bug.cgi?id=389479), which was caused by 
https://cgit.kde.org/solid.git/commit/?id=ed1e7f5fc5c083c17bd44e4220a35eae140f980b 
and 
https://cgit.kde.org/solid.git/commit/?id=1384f275ab2f1ad1841753ee163af6d1b0bb952b


I'm tempted to roll back this whole commit chain until we can figure out 
a non-breaking way to implement the feature.


Alternatively, does anyone have any ideas for how to sustainably fix the 
problems here?


Nate

Re: Recent disk mounting regressions in Solid framework

[Nate Graham]

On 03/19/2018 03:04 PM, David Edmundson wrote:

What is "the patch" you're referring to that Arch cherry-picked?


https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/solid&id=069d565428658007ba8f983a06c8cd776d702d18

I wonder if this is the cause, actually. Can any Arch users confirm?

Nate

Re: Re: major memory leak

[Nate Graham]

If you're using a slideshow as wallpaper or in a photo frame widget, then 
you're hitting https://bugs.kde.org/show_bug.cgi?id=368838. If so, try running 
plasmashell with "QSG_RENDER_LOOP=threaded" and see if that fixes the issue 
(and let us know if it does!).

Nate


 On Mon, 26 Mar 2018 14:05:39 -0700 Yunhe Guo  wrote  
>check if you are using some widgets. Remove all of them and see if that helps.
>
>Another thing to check is to use a single static image as wallpaper.
>
>
>You need to tell your plasma and framework version.
>
>
>Jonathan Willis  于 2018年3月26日周一 23:55写道：
>
>I couldn't find a bug ticket service for kde plasma development, so apologies 
>if this is the wrong place.
>
>
>I'm running into a major memory leak running kde plasma. After a few hours the 
>desktop environment consume about 20GB of RAM and continues to consume another 
>15GB of swap space. After that my operating system has to kill off 
>applications to make space. I added a couple snapshots to show you that 
>killing off the plasmashell reclaims the memory used.
>
>
>I'm running a thinkpad t570 with two monitors daisy chained to my laptop.
>
> 
> 
>

Unable to compile KWidgetsAddons

[Nate Graham]

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:



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

[Nate Graham]

On 03/29/2018 08:06 AM, David Edmundson wrote:

​Do you have that error for just that one framework?


Just for this framework.


> Make sure you've fetched any relevant build deps.

I have all the build deps that the Neon packaging knows about, at least:

$ sudo apt build-dep kwidgetsaddons
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 214 not upgraded.


Nate

Re: Unable to compile KWidgetsAddons

[Nate Graham]

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?


Yes.

Nate

Re: Unable to compile KWidgetsAddons

[Nate Graham]

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

Nate

Re: Unable to compile KWidgetsAddons

[Nate Graham]

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.

Nate

Re: Unable to compile KWidgetsAddons

[Nate Graham]

I'm somewhat embarrassed to admit that I was doing an in-source build 
and no amount of `make clean` and `rm CMakeCache.txt` fixed the problem, 
but doing a proper out-of-source build worked just fine. That'll teach me...


Nate


On 04/06/2018 02:58 AM, Kevin Funk wrote:

On Thursday, 29 March 2018 15:53:25 CEST Nate Graham wrote:

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:


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


Heya,

FYI: The compile-feature [1] is used by the CMake Config files installed by
Qt. For Qt it is used to figure out when and how to pass the i.e. the resp. `-
std=...` flag for GNU-like compilers for users of Qt.

Usually you get that kind of error in case you're trying to use an unsupported
compiler for which CMake doesn't know the availability of the C++ features. A
typical example is Android GCC.

I'm surprised you get that error by a standard GCC...? Would be nice to figure
out what's going wrong. Maybe `cmake --trace` or `cmake --debug-output` can
help.

Please check the following link for a work-around:
   https://stackoverflow.com/a/40256862/592636

[1] https://cmake.org/cmake/help/v3.8/manual/cmake-compile-features.7.html

Regards,
Kevin


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

bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Nate Graham]

Howdy folks,

Right now we have a lot of KIO bugs scattered around in various places:
- kio
- frameworks-kio
- kfile

Should we mark kio and kfile as not accepting new bugs, add some more 
components to frameworks-kio, consolidate everything there, and then eventually 
remove kio and kfile?

Nate

Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Nate Graham]

 On Mon, 09 Apr 2018 11:35:49 -0700 Elvis 
Angelaccio wrote  
 > Yes. 
 >  
 > Note that this is not kio-specific: every library in kdelibs that used to  
 > have its own bugzilla product should be "merged" with the new  
 > frameworks-xxx product (actual bugs still open should be moved, everything  
 > else should be closed). As you can guess, it requires a lot of work. 

Right, I was just bringing up KIO because it's a pretty high-profile example.


 > >and then eventually remove kio and kfile? 
 >  
 > What about old bugs? They should still belong to those products because  
 > that's where the bug used to be. So we cannot just delete them. 

Old bugs should be triaged and closed or moved. I've already started doing 
that. Can we at least hide the old products from view once they're empty?

Who has permission to create new components and mark existing products as not 
accepting new bugs? I'd like to gain those permissions myself, given my bug 
triaging activities (I'm #2 in closed bugs over the past 365 days: 
https://bugs.kde.org/weekly-bug-summary.cgi?tops=20&days=365).

Nate

Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Nate Graham]

Here's another thing that may need changing: the frameworks-kio product doesn't 
allow votes.

Nate



 On Mon, 09 Apr 2018 11:43:25 -0700 Nate Graham 
wrote  
 >  
 >  
 >  On Mon, 09 Apr 2018 11:35:49 -0700 Elvis 
 > Angelaccio wrote   
 >  > Yes.  
 >  >   
 >  > Note that this is not kio-specific: every library in kdelibs that used to 
 >   
 >  > have its own bugzilla product should be "merged" with the new   
 >  > frameworks-xxx product (actual bugs still open should be moved, 
 > everything   
 >  > else should be closed). As you can guess, it requires a lot of work.  
 >  
 > Right, I was just bringing up KIO because it's a pretty high-profile 
 > example. 
 >  
 >  
 >  > >and then eventually remove kio and kfile?  
 >  >   
 >  > What about old bugs? They should still belong to those products because   
 >  > that's where the bug used to be. So we cannot just delete them.  
 >  
 > Old bugs should be triaged and closed or moved. I've already started doing 
 > that. Can we at least hide the old products from view once they're empty? 
 >  
 > Who has permission to create new components and mark existing products as 
 > not accepting new bugs? I'd like to gain those permissions myself, given my 
 > bug triaging activities (I'm #2 in closed bugs over the past 365 days: 
 > https://bugs.kde.org/weekly-bug-summary.cgi?tops=20&days=365). 
 >  
 > Nate 
 >  
 > 
 > 

Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Nate Graham]

 On Mon, 09 Apr 2018 13:46:22 -0700 Nicolás 
Alvarez wrote  
 > Note that any changes will cause email notifications. If you close a fixed 
 > bug that's fine, but for mass-moving from kio -> frameworks-kio that would 
 > be just noise, especially annoying for old and already-closed bugs. You 
 > should coordinate with sysadmins to do such mass changes without sending 
 > email notifications. 

Right, I don't plan to do any mass-moves (especially not for closed bugs!), but 
rather to actually triage every bug one by one...

Nate

Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Nate Graham]

 On Mon, 09 Apr 2018 14:21:45 -0700 David 
Edmundson wrote  
 > > Not sure why this seems to be the case for some items. Maybe a sysadmin 
 > > can look into it?
 > 
 > Voting is deliberately turned off by some maintainers who find it 
 > destructive.
 > That's definitely the case for plasmashell and kwin. Please don't change it.

Actually KWin allows voting, but only gives users a single vote (which I think 
makes a lot of sense). Regardless, I would not and do not plan to make changes 
to any products in Bugzilla without contacting maintainers first.

Nate

Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Nate Graham]

Yep, just got my permissions, and I've pinged David Faure regarding the 
proposed changes.

Nate


 On Mon, 09 Apr 2018 14:42:11 -0700 David 
Edmundson wrote  
 > 
 > ​> Should we mark kio and kfile as not accepting new bugs, add some more  
 > components to frameworks-kio, consolidate everything there, and then  
 > eventually remove kio and kfile?
 > 
 > 
 > Most definitely on those first two points ++
 > 
 > I'm sure you'll get your editcomponents rights soon, but ping me if you want 
 > a hand.
 > 
 > 
 > 
 > As for bulk moving everything, I don't think it adds any value. Leaving them 
 > acts as an effective expunge policy.
 > 
 > 
 > 
 > David
 > 
 > 
 >  
 > 

Re: Flatpak packaging for stable releases

[Nate Graham]

I would strongly encourage it. Flathub is quickly becoming the de facto source 
for Flatpak apps, and all of GNOME’s apps are already there. It would be great 
to get some more KDE representation there too.

Nate

> On Apr 14, 2018, at 3:20 PM, Matthieu Gallien  
> wrote:
> 
> Hello,
> 
> I really appreciate the work that has gone into flatpak and the excellent 
> support for it in KDE and the KDE infrastructure for it.
> 
> I have an hard time understanding what is the best way to distribute a stable 
> release through flatpak.
> 
> I am not sure if the KDE flatpak repositories are supposed to also be used 
> for 
> stable releases.
> 
> I have seen a few KDE applications being also hosted on flathub. Is this the 
> way to go ?
> 
> Best regards
> 
> --
> Matthieu Gallien
> 
> 

Re: Changes to Phabricator review subscriptions

[Nate Graham]

1. What is the canonical way to be notified of Phabricator changes for 
projects you're interested in? Subscribe to that project's mailing list? 
Can you clarify what this means for someone who joins or "watches" a 
project in Phabricator? Should we stop doing that?


2. If someone is subscribed to the project's mailing list and also joins 
the project in Phabricator, will they continue to receive duplicate emails?


3. Who should be listed as reviewers for diffs? Only individual people? 
Nobody?


4. What does this mean for projects like Dolphin or Spectacle that don't 
have mailing lists?


Nate


On 05/09/2018 02:08 AM, Ben Cooksley wrote:

Hi all,

To improve the user experience around email and in-application
notifications from Phabricator, sysadmin have made some changes to the
configuration of our Herald rules.

Going forward, instead of subscribing projects to reviews, we will
only be subscribing mailing lists now. For those reviews which have
already been created, they will be updated to reflect the new practice
the next time they are changed.

This means that individual project members will no longer receive
notifications and emails for every single review or task change that
affects their project. Instead, they will only receive notifications
and emails for reviews they have been individually subscribed to.

To help this change take full effect, it would be appreciated if
people refrain from adding Projects as reviewers, as that will have
the effect of subscribing the Project to the review as well
(Phabricator does not require you specify a reviewer)

Should anyone have any questions regarding this, please open a thread
on the kde-devel@kde.org mailing list.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Changes to Phabricator review subscriptions

[Nate Graham]

Thanks for the responses, Ben.

I'm a bit concerned that all of this raises the barrier to entry for new 
contributors. Now they'll have to match up Phabricator projects with mailing 
lists, which do not have a 1:1 mapping. How is someone interested in Dolphin 
supposed to know that they need to subscribe to the kfm-dev mailing list to 
follow the development? It doesn't have the word "Dolphin" in it or even have a 
description set on https://mail.kde.org/mailman/listinfo. And Dolphin's own 
Phabricator page doesn't mention anything about it.

I appreciate the desire to cut down on duplicates and email overload (truly!) 
but are we sure this is the right approach? If we want to continue with this, 
I'd like to see some work put into updating our documentation on 
https://community.kde.org/Get_Involved/development#Communicating_with_the_team 
and https://community.kde.org/Infrastructure/Phabricator and for individual 
Phabricator project pages.

Also, was this discussed somewhere before the change was rolled out? I didn't 
see anything about it on kde-devel.

Nate



 On Wed, 09 May 2018 12:21:57 -0700 Ben Cooksley wrote 
---- 
 > On Thu, 10 May 2018, 02:08 Nate Graham,  wrote:
 > 
 > 1. What is the canonical way to be notified of Phabricator changes for 
 >  projects you're interested in? Subscribe to that project's mailing list? 
 >  Can you clarify what this means for someone who joins or "watches" a 
 >  project in Phabricator? Should we stop doing that?
 > 
 > 
 > 
 > 
 > I would recommend subscribing to the individual Projects mailing lists yes.
 > 
 > 
 > Joining or watching a Project would still result in email and notifications 
 > where the Project is a reviewer. Tasks are unaffected by this.
 > 
 > 
 >  
 >  2. If someone is subscribed to the project's mailing list and also joins 
 >  the project in Phabricator, will they continue to receive duplicate emails?
 > 
 > 
 > 
 > 
 > They shouldn't receive duplicates anymore. 
 > 
 > 
 > The only exception where duplicates would be received is if the user is 
 > individually subscribed to tasks or reviews.
 > 
 > 
 >  
 >  3. Who should be listed as reviewers for diffs? Only individual people? 
 >  Nobody?
 > 
 > 
 > 
 > 
 > Individuals. For smaller Projects it may still be practical for the Project 
 > to be the reviewer, however this does not scale for larger ones such as 
 > Frameworks and Plasma (where the complaints came from)
 > 
 > 
 >  
 >  4. What does this mean for projects like Dolphin or Spectacle that don't 
 >  have mailing lists?
 > 
 > 
 > 
 > 
 > Dolphin appears to be using the kfm-devel mailing list.
 > 
 > 
 > Projects that don't have mailing lists (and which are small by nature) will 
 > continue to have the Project subscribed for reviews.
 > 
 > 
 > 
 > 
 >  
 >  Nate
 > 
 > 
 > 
 > 
 > Cheers,
 > Ben
 > 
 > 
 >  
 >  
 >  On 05/09/2018 02:08 AM, Ben Cooksley wrote:
 >  > Hi all,
 >  > 
 >  > To improve the user experience around email and in-application
 >  > notifications from Phabricator, sysadmin have made some changes to the
 >  > configuration of our Herald rules.
 >  > 
 >  > Going forward, instead of subscribing projects to reviews, we will
 >  > only be subscribing mailing lists now. For those reviews which have
 >  > already been created, they will be updated to reflect the new practice
 >  > the next time they are changed.
 >  > 
 >  > This means that individual project members will no longer receive
 >  > notifications and emails for every single review or task change that
 >  > affects their project. Instead, they will only receive notifications
 >  > and emails for reviews they have been individually subscribed to.
 >  > 
 >  > To help this change take full effect, it would be appreciated if
 >  > people refrain from adding Projects as reviewers, as that will have
 >  > the effect of subscribing the Project to the review as well
 >  > (Phabricator does not require you specify a reviewer)
 >  > 
 >  > Should anyone have any questions regarding this, please open a thread
 >  > on the kde-devel@kde.org mailing list.
 >  > 
 >  > Regards,
 >  > Ben Cooksley
 >  > KDE Sysadmin
 >  > 
 >  
 >  
 > 
 > 
 >  
 > 

Re: Changes to Phabricator review subscriptions

[Nate Graham]

 On Wed, 09 May 2018 12:46:30 -0700 Luigi Toscano 
wrote  
 > Nate Graham ha scritto: 
 > > Thanks for the responses, Ben. 
 > >  
 > > I'm a bit concerned that all of this raises the barrier to entry for new 
 > > contributors. Now they'll have to match up Phabricator projects with 
 > > mailing lists, which do not have a 1:1 mapping. How is someone interested 
 > > in Dolphin supposed to know that they need to subscribe to the kfm-dev 
 > > mailing list to follow the development? It doesn't have the word "Dolphin" 
 > > in it or even have a description set on 
 > > https://mail.kde.org/mailman/listinfo. And Dolphin's own Phabricator page 
 > > doesn't mention anything about it. 
 >  
 > Then it's time to set the the description of the list then. 

Who has access to do that?

This is really an issue with information availability. It's all available in 
pieces in different places, rather than all "under one roof", so to speak. It's 
important to centralize wherever possible so that people get the full picture.

Nate

Re: Closing old Plasma 4 bugs

[Nate Graham]

No objections from me. It was definitely not the intention to prevent users 
from being able to report wishlist tickets, or to prevent DrKonqi from being 
able to correctly file crash bugs.

Nate


 On Fri, 11 May 2018 14:06:46 -0700 Christoph Feck wrote 
 
 > On 11.02.2018 20:52, Nate Graham wrote: 
 > > All right, so let's give it a shot. How about we make it so that normal 
 > > users have full privilages except the following: 
 > > 
 > > - Can't bulk change 
 > > - Can't change Importance field 
 >  
 > We now see regressions caused by this particular change: 
 > - new 'wishlist' tickets end up reported as 'normal' 
 > - crashes (even from DrKonqi) end up reported as 'normal' 
 >  
 > Manual intervention is needed to correct these wrong states, 
 > see https://bugs.kde.org/show_bug.cgi?id=391187 
 >  
 > Unfortunately, bugzilla does not differentiate between own tickets and 
 > changing tickets from others, and I doubt it was our intention to 
 > remove existing abilities, so I propose to revert the permissions for 
 > the 'Severity' field. 
 >  
 > Any objections? 
 >  
 > > - Can't re-open bugs in the CLOSED state 
 >  
 >  
 > 
 > 

Re: Closing old Plasma 4 bugs

[Nate Graham]

Kubuntu 18.04  has now now been out for a month, so if there are no 
further objections, I'll begin preparations for this Plasma 4 mass bug 
close.


Nate



On 02/14/2018 10:16 AM, Christoph Feck wrote:

On 10.02.2018 21:24, Nate Graham wrote:

Hello folks,
We have more than 2,500 Plasma 4 bugzilla tickets that we don't intend
to look at or triage. We've already prevented new tickets from being
filed, but it doesn't do anyone any good to just have the old ones
sitting there. My sense is that most of the relevant bugs and wishlist
items are already represented in the plasmashell product, so what do you
think about doing a mass-close?

I was thinking of closing them all with one of the following two
messages (top one for bugs, bottom one for wishlist items). What do you
think?

Nate







For bugs:
=

Hello!

This bug was filed for KDE Plasma 4, which reached end-of-support status
in October 2015. Developers have not been triaging Plasma 4 bugs since
that time. Happily, because KDE Plasma 5's desktop shell was been almost
completely rewritten for better performance and usability, it is likely
that this bug has already been resolved in Plasma 5. Additionally, bug
triaging resources are extremely limited; if you would like to get
involved in this effort, please see
https://community.kde.org/Get_Involved#Bug_Triaging

Accordingly, and we hope you understand why we must close this bug. If
the issue described  here is still present in KDE Plasma 5.12 or later,
please feel free to open a new ticket in the "plasmashell" product after
reading https://community.kde.org/Get_Involved/Bug_Reporting

Thanks for your understanding!

Nate Graham






For wishlist items:
===

Hello!

This feature request was filed for KDE Plasma 4, which reached
end-of-support status in October 2015. Developers have not been triaging
Plasma 4 requests since that time. Happily, because KDE Plasma 5's
desktop shell was been almost completely rewritten, it is likely that
this feature request has already been implemented in Plasma 5, or is no
longer applicable. Additionally, bug triaging resources are extremely
limited; if you would like to get involved in this effort, please see
https://community.kde.org/Get_Involved#Bug_Triaging

Accordingly, and we hope you understand why we must close this feature
request. If the requested feature is still not implemented in KDE Plasma
5.12 or later, please feel free to open a new ticket in the
"plasmashell" product after reading
https://community.kde.org/Get_Involved/Bug_Reporting

Thanks for your understanding!

Nate Graham



Hi Nate,

had that on my TODO list, but happy to see you taking over for this task.

I suggest to wait until Ubuntu 18.04 LTS is released, ideally a month 
longer to give people with LTS requirements time to update it.

Re: Closing old Plasma 4 bugs

[Nate Graham]

Yes, in fact I work for a company some of whose employees and customers 
use RHEL 7 (and 6, and 5, believe it or not...). In the end, I don't 
think it's relevant to us. KDE Plasma 4 wasn't the default shell in any 
of these distros anyway, so we are talking about an inherently old, 
niche use case. And anyway, Red Hat is expected to provide support for 
the very old software shipped in these distros, not upstreams like us.


Nate



On 05/26/2018 06:04 AM, Olivier Churlaud wrote:

Hello,

Just to remind you that companies using KDE/Plasma on RHEL7 are still using 
plasma 4.
I don't know if it has an impact but in case I wanted to point it out.

Cheers,
Olivier

Le samedi 26 mai 2018, 05:09:06 CEST Nate Graham a écrit :

Kubuntu 18.04  has now now been out for a month, so if there are no
further objections, I'll begin preparations for this Plasma 4 mass bug
close.

Nate



On 02/14/2018 10:16 AM, Christoph Feck wrote:

On 10.02.2018 21:24, Nate Graham wrote:

Hello folks,
We have more than 2,500 Plasma 4 bugzilla tickets that we don't intend
to look at or triage. We've already prevented new tickets from being
filed, but it doesn't do anyone any good to just have the old ones
sitting there. My sense is that most of the relevant bugs and wishlist
items are already represented in the plasmashell product, so what do you
think about doing a mass-close?

I was thinking of closing them all with one of the following two
messages (top one for bugs, bottom one for wishlist items). What do you
think?

Nate







For bugs:
=

Hello!

This bug was filed for KDE Plasma 4, which reached end-of-support status
in October 2015. Developers have not been triaging Plasma 4 bugs since
that time. Happily, because KDE Plasma 5's desktop shell was been almost
completely rewritten for better performance and usability, it is likely
that this bug has already been resolved in Plasma 5. Additionally, bug
triaging resources are extremely limited; if you would like to get
involved in this effort, please see
https://community.kde.org/Get_Involved#Bug_Triaging

Accordingly, and we hope you understand why we must close this bug. If
the issue described  here is still present in KDE Plasma 5.12 or later,
please feel free to open a new ticket in the "plasmashell" product after
reading https://community.kde.org/Get_Involved/Bug_Reporting

Thanks for your understanding!

Nate Graham






For wishlist items:
===

Hello!

This feature request was filed for KDE Plasma 4, which reached
end-of-support status in October 2015. Developers have not been triaging
Plasma 4 requests since that time. Happily, because KDE Plasma 5's
desktop shell was been almost completely rewritten, it is likely that
this feature request has already been implemented in Plasma 5, or is no
longer applicable. Additionally, bug triaging resources are extremely
limited; if you would like to get involved in this effort, please see
https://community.kde.org/Get_Involved#Bug_Triaging

Accordingly, and we hope you understand why we must close this feature
request. If the requested feature is still not implemented in KDE Plasma
5.12 or later, please feel free to open a new ticket in the
"plasmashell" product after reading
https://community.kde.org/Get_Involved/Bug_Reporting

Thanks for your understanding!

Nate Graham



Hi Nate,

had that on my TODO list, but happy to see you taking over for this task.

I suggest to wait until Ubuntu 18.04 LTS is released, ideally a month
longer to give people with LTS requirements time to update it.

Re: Closing old Plasma 4 bugs

[Nate Graham]

This work is done; all the bugs and feature requests in the plasma4 
product have been closed. Hope all of your inboxes survived the onslaught!


Nate



On 02/21/2018 07:21 AM, Nate Graham wrote:
I have also cleaned up the bug triaging page: 
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging


It's still a bit long, so any further editing to condense it a bit would 
be welcome.


Nate



On 02/21/2018 07:16 AM, Nate Graham wrote:



On 02/21/2018 06:26 AM, Nate Graham wrote:




On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:

On Wed, Feb 21, 2018 at 9:34 AM, pointedstick 
 wrote:
I have editbugs power on bugs.kde.org, but cannot edit the 
Importance field
or mark a bug as CLOSED on bugstest.kde.org. I appear to have the 
new normal

permissions.


Thanks for confirming my testing Nate.

I've now gone ahead and rolled this out on bugs.kde.org.
Everyone who had editbugs rights already (all 3,221 of us) have been
made members of the new (fully empowered) contributors group.

If someone would like to announce this via a blog post please feel
free to do so as I likely won't have time in the next few days to do
so.


Fantastic! I'll do that.


Done: 
https://pointieststick.wordpress.com/2018/02/21/its-now-much-easier-to-be-a-bug-triager/ 



Nate

Re: Flatpak/Snap BoF at Akademy

[Nate Graham]

I'd like to be there too!
Nate


On 06/28/2018 06:18 AM, Aleix Pol wrote:

On Thu, Jun 28, 2018 at 7:54 AM Jan Grulich  wrote:


Hi,

I would like to organize a BoF for Flatpak and Snap related stuff, to discuss
our support of sandboxing, plans for future and so on. I would like to know
whether there is an interest before booking a room for this.

Some stuff I can think of right now we can discuss:
* Flatpak and Snap support in Plasma Discover
   - current state
   - what is working, not working or need changes (I can think of new API for
transactions)
* Runtimes and packages
   - current state and plans
* Portals support
   - what is done and what is missing or needs to be improved for Snap
* Other stuff
   - like Flatpak/Snap support in KDevelop

I checked the schedule and there are already BoF planned so there are only few
slots available. I would suggest having this BoF at Tuesday in the morning so
it's not together with Plasma BoF or with KDE neon BoF at Tuesday afternoon.
At Wednesday there is Wayland BoF in the morning and a daytrip afternoon and
at Thursday people usually travel home (me included).

Let me know about your opinion.

Thank you


Hi Jan,
Tuesday sounds good, thanks for putting this together. Will be happy to join.

Cheers!
Aleix

Re: Submitting a distribution to wiki page

[Nate Graham]

It's a wiki; please feel free to add your distro to the list (following the 
pattern)!

Nate


  On Fri, 03 Aug 2018 13:23:05 -0700 Silvan Calarco 
 wrote  
 > Hello and sorry if this might be considered off-topic in this list, 
 >  
 > I've been looking at the page https://community.kde.org/Distributions for a  
 > link to ask about adding a kde-based distribution to the current list. 
 >  
 > The openmamba distribution I work on is a KDE based distro since a long time 
 >  
 > and while working on updating Plasma packages to 5.13.4 I've been thinking 
 > it  
 > could be worth to be added to that list. Can anybody in this list consider  
 > this or give me a reference for this kind of request? 
 >  
 > You may try this KDE-based distribution by getting the latest rolling livecd 
 >  
 > or livedvd available on the site https://openmamba.org. 
 >  
 > Thanks and best regards, 
 > Silvan 
 >  
 > --  
 > openmamba GNU/Linux @ https://openmamba.org 
 >  
 >  
 > 

Re: Contribute to KDE - Digikam

[Nate Graham]

[cc'ing digikam-devel]

Hello Jameer,

you might have a look at:
- https://community.kde.org/Get_Involved
- https://community.kde.org/Get_Involved/development

Nate



On 08/04/2018 02:27 PM, Jameer Babu wrote:
> Hello
>
> I am Jameer studying third year Computer Science and Engineering. I am
> very much attracted to KDE especially digikam. I am an open source
> enthusiast and would like to contribute. Please let me know how to start
> making contributions, how to set up the environment and other details
> required for contributing.
>
>
> --
> Jameer Babu
> CSE, Amrita University
> Github 

Re: new brain on team

[Nate Graham]

Welcome Bartosz!

you might have a look at https://community.kde.org/Get_Involved

If you're looking for specific projects that could serve as a good 
introduction, I would recommend tackling some junior-jobs bugs in 
Dolphin[1] Gwenview[2], Spectacle[3], or KIO[4].


To learn how to submit a patch, see 
https://community.kde.org/Infrastructure/Phabricator


Welcome aboard!

Nate


[1] 
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&keywords_type=allwords&list_id=1534821&product=dolphin&query_format=advanced


[2] 
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&keywords_type=allwords&list_id=1534822&product=gwenview&query_format=advanced


[3] 
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&keywords_type=allwords&list_id=1534823&product=Spectacle&query_format=advanced


[4] 
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&keywords_type=allwords&list_id=1534824&product=frameworks-kio&query_format=advanced





On 07/31/2018 06:27 AM, Bartosz Gertych wrote:

Hello KDE team
I have get your email from Ben Cooksley. I just started and I want to 
get involved in some projects. Could you find someting for me? I would 
like to improve my skills with qt and c++. I'm not a proffesional 
programmer, but also not a beginner.

Thanks for your time.
Regards
Bartosz

Re: KDE service for mounting storage resources

[Nate Graham]

On 08/26/2018 09:04 AM, Elvis Angelaccio wrote:

On venerdì 24 agosto 2018 19:37:26 CEST, Luca Carlon wrote:
Hello! For some projects I'd need some kind of "service" being able to 
mount resources like SMB shares, FTP, SFTP etc... I read about KIO a 
bit, but I'd need something that can be passed also to non-KIO 
applications.
I read the code of smb4k and it seems to do exactly what I need: using 
KAuth and mounting to some specific path. But this seems a bit tied to 
the specific application and only supporting SMB. What I'd need is 
some kind of service, a bit like udisks, in order to mount on request 
from other processes.
On IRC someone told me something like this may already be into Plasma: 
is there someone able to provide more info?

Thanks!
Regards.

Luca


Hi Luca,
as far as I know we only have KIO for that kind of job.


Hmm, as I understand it, Luca wants "something that can be passed also 
to non-KIO applications". Let me take the opportunity to mention 
https://bugs.kde.org/show_bug.cgi?id=75324, then I'll go away. :)


Nate

Re: The VDG

[Nate Graham]

On 09/20/2018 09:07 PM, Stef Bon wrote:

To start, we need a location on the Internet, starting with
documentation, where it's easy to write/create (2d at least) drawings
and formulas.

Do you agree?


We use Phabricator for this--both Maniphest Tasks and also Pholio 
Mockups (though we're still kind of trying to figure out how to use 
Pholio!).


Do you find that this stuff isn't working out for you?

Nate

Re: Proposal, Adopt .editorconfig in every project

[Nate Graham]

On 09/21/2018 04:40 AM, Tomaz Canabrava wrote:

Hello fellows.

In kde software we strive to be inclusive, that means that we don't 
enforce a coding style in every new project, nor do we adapt to newer 
styles on old software. This can create a bit of problems when we edit 
two projects at the same time.


For instance, on the KDE-Edu module, we can look at kalgebra, and it 
uses indentation of 4 space, while in blinken it uses a single tab 
indentation. Curently if I open kalgebra in any editor based on 
ktexteditor I will need to go to settings, change the tab behavior, edit 
kalgebra files, then go to settings, change tab behavior again, edit 
blinken files. That's too easy to miss. (I actualy missed and had to fix 
a review because of tabs / spaces).


Related, and another potential solution to the issue (at least for Kate 
users): https://bugs.kde.org/show_bug.cgi?id=109338


Nate

Re: New contributor seeking guidance

[Nate Graham]

Hello Remya,
We use phabricator.kde.org for patch submission. Here is the 
documentation for how to submit your patch: 
https://community.kde.org/Infrastructure/Phabricator


Nate


On 11/3/18 10:30 AM, Remya Krishnan wrote:

Hi all,

Thanks for the pointers. I have the following patch 
https://paste.kde.org/pphxfykd4 which fixes bug 
https://bugs.kde.org/show_bug.cgi?id=359084
I'd like someone to review the same to see if the patch is acceptable. 
What should I do next ?

With Regards,
Remya Krishnan,
GitHub |FOSS@Amrita 


Amrita University 

On Sat, Nov 3, 2018 at 5:58 PM gregor.mi.sw > wrote:




On 01.11.2018 13:16, Remya Krishnan wrote:
 > Hi all,
 > First of all, thanks for responding. I unknowingly subscribed for
digest mode but found the reply in
 > public mailing list archive:
https://marc.info/?l=kde-devel&m=154091462602641&w=2
 > 
 > I would like to work on https://bugs.kde.org/show_bug.cgi?id=359084.
 > 
 > If anyone could give me some guidance to start with, I would
appreciate it.  :)
 >
 > With Regards,
 > Remya Krishnan,
 > GitHub |FOSS@Amrita

 > Amrita University 
 >

Hi,

you would like to work on this KTurtle-Theme-Bug
(https://bugs.kde.org/show_bug.cgi?id=359084).

I am not into themeing myself but a a good start would be download
and build KTurtle on your
machine, e.g. by following this guide:
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source

While it is building, you could investigate the source code of the
editor componenent for places
that deal with colors and come back to us with specific questions.

Gregor

Re: Mockup Design Assets for KDE

[Nate Graham]

+visual-design

Nate


On 12/2/18 12:48 PM, Jacky Alcine wrote:

Hey y'all.

(posting this to two mailing lists as I'm a bit confused which is most useful)

Do we have an equivalent of this for KDE?

https://github.com/gnome-design-team/gnome-mockups-resources

I was debating just winging it in Qt Designer for a little bit but something
like the above allows people without Qt Designer to use other tools like
Pencil (https://pencil.evolus.vn/ + https://github.com/evolus/pencil) for
making mockups and design.

Also, do we have a place to submit mockups for application design and ideas
for KDE?

Re: Contributing to KDE is hard because of its build architecture

[Nate Graham]

On 12/9/18 10:51 AM, Martin Flöser wrote:

Am 2018-12-09 16:41, schrieb Konstantin Kharlamov:


Official way of building dependencies is using kdesrc-build. It has
multiple problems:


Hi Konstantin,

sorry for your bad experienced, but I think it would have been much 
easier. Assuming you are on a Debian based distribution the steps should 
just be:


* sudo apt build-dep kmail
* kdesrc-build kde-pim

I personally don't have all dependencies build from source, but just the 
one I develop. Everything else I do through distro packages. I would 
never try to build something like webengine from source, that's just a 
mess.


In fact, our official documentation even recommends grabbing 
dependencies using the package manager: 
https://community.kde.org/Get_Involved/development#Build_some_software


This is what I do too and it works great. You get the non-KDE 
dependencies from the distro, and build only the necessary KDE 
dependencies from source using kdesrc-build. It's generally very smooth.


Did you find the instructions at 
https://community.kde.org/Get_Involved/development difficult to follow 
or understand? I'm always interested in improving this documentation.


Nate

Re: Logout from kde and show a black page on Fedora 28 KDE Live x86_64 Virtual machine installed on Qemu and VMware

[Nate Graham]

Hello,
This is the development list. To report a bug, please use 
http://bugs.kde.org/ after reading 
https://community.kde.org/Get_Involved/Bug_Reporting


Nate


On 12/20/18 11:58 PM, su...@coretek.com.cn wrote:

Hi All!

I installed Fedora 28 KDE Live x86_64 as Virtual Machines  on Qemu/KVM 
and VMware.


If I input wrong password once on sddm login page . After I logout from 
*Fedora*, then the fedora always show me a black screen.


I worked on this problem for serveral days, but I failed.

Can Anyone help me to fix  this problem?


Thanks a lot!



su...@coretek.com.cn

LXR is inaccessible

[Nate Graham]

Hello Sysadmins,
https://lxr.kde.org/ is inaccessible right now. Any ETA on getting it 
back up?


Nate

Re: LXR is inaccessible

[Nate Graham]

Thanks Ben, can confirm that all is well now!

Nate


On 2/11/19 9:54 AM, Ben Cooksley wrote:

On Tue, Feb 12, 2019 at 5:23 AM Nate Graham  wrote:


Hello Sysadmins,
https://lxr.kde.org/ is inaccessible right now. Any ETA on getting it
back up?


Hi Nate,

Sorry for this - LXR went down when the physical host for it crashed
around 18 hours ago.
While the physical host was revived, the container that runs LXR
wasn't restarted.

I've now started it back up again.



Nate



Cheers,
Ben

Phabricator seems down

[Nate Graham]

Hello sysadmins,
https://phabricator.kde.org is not responding responding right now for 
myself and others. Can you give it a kick?


Thanks!

Nate

Re: Phabricator seems down

[Nate Graham]

Thanks, indeed it has.

Nate



On 2/12/19 10:22 AM, Ben Cooksley wrote:

On Wed, Feb 13, 2019 at 5:09 AM Nate Graham  wrote:


Hello sysadmins,


Hi Nate,


https://phabricator.kde.org is not responding responding right now for
myself and others. Can you give it a kick?


It appears to have corrected itself.



Thanks!

Nate



Regards,
Ben Cooksley
KDE Sysadmin

Phabricator is down

[Nate Graham]

Can someone give it a swift kick?

Thanks!

Nate

Re: What controls the default ordering of which application handles an opened file?

[Nate Graham]

On 11/16/17 6:29 AM, Harald Sitter wrote:

The KService frameworks supports a special desktop entry key [3]
`X-KDE-InitialPreference` meaning to solve this. It assigns a custom
preference score (higher=more preferred) to all mime types associated
with the desktop file.
To solve the problem with krita there probably needs to be a separate
krita desktop file which is `NoDisplay=true` and only associates with
the krita mimetype `MimeType=application/x-krita;` and sets
`X-KDE-InitialPreference=10` to gain preference over gwenview. This
will only impact kde-frameworks based software though, other xdg spec
compliant mimetype handlers do not necessarily respect our
InitialPreference score!

In the end I don't think there is a proper cross-desktop way of doing
this by default. Usually people simple set X-KDE-InitialPreference and
move on.

[1] 
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#mime-types
[2] 
https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html#associations
[3] 
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#kde-items

HS



I finally got around to implementing this, more than a year later. :)

Thanks for your help, Harald. You definitely pointed me in the right 
direction.


Here are the patches:
- https://phabricator.kde.org/D19120
- https://phabricator.kde.org/D19121

Nate

notes.kde.org having auth trouble

[Nate Graham]

Hello Sysadmin,
People are having trouble authenticating to any of the documents on 
notes.kde.org. It's rejecting everyone's credentials for all documents 
at the moment.


Would someone mind taking a look?

Nate

Re: Gitlab Evaluation & Migration

[Nate Graham]

  On Mon, 25 Feb 2019 09:54:26 -0700 Martin Flöser  
wrote  
 > You asked for comments. I gave comment that I'm not pleased about yet  
 > another transition. Please keep that in mind. It means learning and  
 > interrupted workflows for every one. If you have already decided and  
 > don't want anybody to point out that transitions are painful, please  
 > don't ask for comments. Instead say that sysadmins decided. That's at  
 > least honest - your reply gives me the feeling the decision is already  
 > done and negative feedback was not expected. Sorry to feel this way. 

I think it goes without saying that transitions are painful, so it doesn't seem 
necessary to point this out because it's obvious to anyone who's ever undergone 
a transition. The point of any transition is that the pleasure of the new 
system should outweigh the temporary pain involved in transitioning, and the 
permanent the pain imposed by the current system.

Like you, I have some reservations about Gitlab. I'm not thrilled about losing 
approve/request changes statuses (that's in the EE edition only right now). And 
gitlab's fork-the-repo workflow feels more awkward to me than Phab's 
patch-based workflow, and I have some questions regarding scalability and the 
kdesrc-build experience given that each of our 80+ frameworks has its own repo. 
There are also some UI issues associated with inline comments in merge requests 
that I'd like to see fixed.

But there is a lot of pain currently associated with Phab. Multi-commit chains 
are very difficult to do correctly. Updating patches to reflect changes in the 
origin is error-prone. The website's user interface and search are poor. 
Landing patches is time-consuming and error-prone. The review experience for 
patches that change SVG icons is terrible, and occasionally suffers from a bug 
that that makes certain patches impossible to review [1].

All of these issues are fixed with Gitlab in my experience testing our our 
evaluation instance on https://invent.kde.org.  Have you had a chance to try it 
out yet? I didn't notice any comments from you in 
https://notes.kde.org/p/gitlab-evaluation-notes

And I think there's value in listening to the outside world when people tell us 
that they prefer Gitlab's  workflow to Phab's system that attempts (and fails) 
to abstract away Git itself. The enormous popularity of Github means that this 
workflow is at the very least  familiar to a huge amount of developers, if not 
outright superior. If we ignore that, we risk losing newcomers over time 
because our system is just weird and awkward compared to the norm, no matter 
how good our documentation is--and I think it's pretty darn good right now.

And yes, the documentation will go stale and need to be updated. I'll do this 
for Gitlab just like I did for Phab [2].


[1] https://secure.phabricator.com/T1022
[2] 
https://community.kde.org/index.php?title=Infrastructure/Phabricator&action=history).


Nate

Re: Gitlab Evaluation & Migration

[Nate Graham]

  On Tue, 26 Feb 2019 02:02:08 -0700 Eike Hein  wrote  
 > How would GitLab impact the kdesrc-build experience? 

So this is the current kdesrc-build experience:
1. kdesrc-build [thing]
2. cd ~/kde/src[thing]
3. arc feature my-awesome-patch
4. Start hacking
5. kdesrc-build --no-src --resume-from [thing]
6. [test and make sure it works]
7. arc diff --create

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. Since Merge Requests from 
people without commit access have to come from a private fork, that means that 
in the above model, they need to use some web UI to first create a private 
fork, and then somehow tell kdesrc-build to check that out rather than the 
original repo.

Alternatively, perhaps kdesrc-build could check out the source from the 
original repo, but automatically create a second remote in each repo that 
corresponds to the private fork? Then people could hack in the original repo, 
but push their branches to the private remote fork for the purposes of creating 
a Merge Request.

All of this is probably technically solvable, but it seems like it will take 
some doing to ensure that the user experience is as good as it currently is 
today (IMO, of course!).

Nate

Re: Gitlab Evaluation & Migration

[Nate Graham]

  On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein  wrote  
 > 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. 
 >  
 > When you have a local git repository (be it your own or a clone), it can  
 > interact with any number of remote git repositories. 
 >  
 > When you do `git clone `, git automatically adds   
 > as a remote named "origin" to the local repository. But what "origin"  
 > points to can be changed at any time, or other remotes with other names  
 > can be added for pushing too. "origin" is just a convention. 
 >  
 > I.e. someone can totally do this: 
 > 1. use kdesrc-build to clone stuff 
 > 2. git checkout -b feature to make a feature branch 
 > 3. hack 
 > 4. make a private fork on gitlab 
 > 5. push to their fork from the clone they've been working in 
 >  
 > It's not necessary to fork first and clone your fork to get started. 

Thanks Eike, that makes e a lot of sense. Going to the website to fork each 
repo for the first time still adds an additional manual step compared to the 
status quo, so it would be nice if we can get kdesrc-build so set up forks 
automatically. That would be really slick.

Nate

Re: Gitlab Evaluation & Migration

[Nate Graham]

  On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley  wrote 
 
 > In terms of server load, it would be nice if the setup of forks was 
 > still something the developer had to initiate rather than being done 
 > automatically for every repository touched by kdesrc-build (I say this 
 > mainly as if we had 50 people fork just half of the mainline 
 > repositories we have, that's ~450GB of space used up - a massive 
 > scalability issue) 

This seems like a challenge that needs to be addressed regardless of whether or 
not kdesrc-build does it automatically, because people creating tons and tons 
of forks is guaranteed to happen anyway if we move to Gitlab. It seems 
non-optimal if having more people able to submit merge requests results in the 
potential to blow up our servers.

Nate

ffmpegthumbnailer

[Nate Graham]

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.

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

[Nate Graham]

  On Sun, 03 Mar 2019 09:58:56 -0700 Luigi Toscano 
 wrote 
 > Nate Graham ha scritto: 
 > > 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. 
 > >  
 > > 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? 
 >  
 > Right now, just dropping one for the other is not possible. 
 > Our one is a KIO thumbnailer. The other is a command line program. 

Thanks, that makes sense.

Nate

Re: Help regarding Getting involved (and GSoC)

[Nate Graham]

The #kde-devel channel on Freenode IRC/Matrix may be what you're looking for.

Nate


  On Thu, 07 Mar 2019 09:18:00 -0700 Abhinav Ananth  
wrote 
 > Hi,I have a few queries from the Get Involved page 
 > (https://community.kde.org/Get_Involved/development#Build_some_software) 
 > specifically from the build some software section.Can I ask here, or could I 
 > be redirected to some kde developers/mentors by getting their IRC nicks and 
 > I could take their help?
 > Regards,Abhinav(India)  

Re: Help regarding Getting involved (and GSoC)

[Nate Graham]

  On Thu, 07 Mar 2019 10:17:04 -0700 Abhinav Ananth  
wrote 
 > Thanks for the reply.Whom can I exactly contact amongst all the people there 
 > in that chat room? Someone you might know? Or maybe the mentors of some kde 
 > project under gsoc?

If you're looking for specific GSoC projects, check out 
https://community.kde.org/GSoC/2019/Ideas. That has specific people listed in 
it. Keep in mind that for GSoC and KDE in in general, you're expected to be a 
self-starter and not wait for a guru to assign you work though. :-)

Nate

Re: Concluding the Gitlab Discussion

[Nate Graham]

One thing I'd really like to not lose is the review status feature 
(approved/changes requested/etc). I've head that this is EE only. Is there any 
word on getting that added to our package?

Other than that, I think I think what Gitlab offers over Phabricator is either 
a significant win or else just something different that you can get used to 
quickly.

Nate


  On Tue, 19 Mar 2019 02:26:24 -0600 Ben Cooksley  wrote 

 > Hi all,
 > 
 > Over the past few weeks we've had a discussion on whether we'd like to
 > migrate from Phabricator to Gitlab, for handling both our code reviews
 > as well as internal tasks (user facing bug reports are explicitly out
 > of context at this time)
 > 
 > Based on the comments the overall consensus seems to be at this stage
 > to favour switching to Gitlab.
 > 
 > This however is subject to a caveat around multiple task boards, which
 > would be needed for larger projects to effectively coordinate amongst
 > the various sub-projects.
 > 
 > As part of the transition we will also arrange for the email interface
 > to be enabled (for emailing in patches) and for the default for merges
 > to be rebase when it's not a fast forward merge for all repositories.
 > 
 > Does anyone have any final comments?
 > 
 > In terms of the steps forward from here, Sysadmin will need a bit of
 > time to prepare various parts of the infrastructure for the transition
 > (such as the anongit network, which will need a full rebuild as part
 > of switching).
 > 
 > Once this is complete, we'll be in touch with more information on how
 > the transition will take place.
 > 
 > Thanks,
 > Ben Cooksley
 > KDE Sysadmin
 > 

Re: CI system maintainability

[Nate Graham]

With regards to the discussion about mandatory code review, I think it's 
important to avoid immediately rushing to create new policy as a result of a 
particular event or abuse. It's always tempting to try to put in place a rule 
that would have avoided the problem if it had existed and was being followed, 
but usually in these circumstances, existing rules or conventions were already 
being violated. So adding new ones usually doesn't help as much as people would 
want because they don't address the underlying issue of why rules are being 
broken in the first place.

In this case, it seems like the problem is that there are certain individuals 
or teams that are pushing risky, breaking changes without code review, and then 
ignoring failures in the CI. I think we might do well to try to answer the 
question of why that's happening before we create a new rule aimed at stopping 
it.

Nate

2019 Usability & Productivity sprint

[Nate Graham]

Howdy folks,
I'd like to bring people's attention to the 2019 Usability & Productivity 
sprint in Valencia, Spain on June 19th - June 26th: 
https://community.kde.org/Sprints/Usability_%26_Productivity/2019. We've got a 
fun and ambitious agenda planned 
(https://notes.kde.org/p/usability-productivity-sprint-2019), and there's still 
room for up to 6 more people at our venue. On that subject, it's being held at 
the same place and time as the Plasma sprint so participating in both is also a 
possibility.

Please don't hesitate to let me know if you're interested in attending!

Nate

Re: error kio-gdrive

[Nate Graham]

That looks like an issue with the distro or its current state rather than the 
code. You rebooted after updating, right?

If that doesn't help, please ask in a Neon-specific venue (mailing list, forum, 
IRC/Matrix channel, etc).

Nate


  On Fri, 26 Apr 2019 09:36:11 -0600 luis cardenas  
wrote 
 > 
 > With the latest kde-neon updates, kio-gdrive is delivering the following 
 > error
 > 
 > 
 > please, someone who can guide me to solve the problem
 > 

Re: Code Review: Spectacle

[Nate Graham]

  On Sun, 05 May 2019 13:57:49 -0600 Reindl Harald  
wrote 
 > 
 > 
 > Am 05.05.19 um 21:44 schrieb Boudhayan Gupta:
 > > Hi folks,
 > > 
 > > I've been hacking on Spectacle again :-P
 > 
 > if you are at it please bring back the sane behavior of "ksnapshot" to
 > make "remember selection" default *but not* between sessions

As of 19.04, it now is. :)

 > 
 > that worked so fine for all the years when you had to document some
 > process with a ton of screenshots step by step where the selection is
 > identical at every step
 > 
 > the same for "on click" - that makes no sense for a rectangle selection
 > in most cases

As of 19.04, this is now an optional but off-by-default feature. Feel free to 
turn it on. :)

Nate

Re: Code Review: Spectacle

[Nate Graham]

Thanks! Looks promising so far. A Phab review would be lovely, yes.

Nate


  On Sun, 05 May 2019 13:44:24 -0600 Boudhayan Gupta  wrote 

 > Hi folks,
 > I've been hacking on Spectacle again :-P
 > I wanted to refactor the platform backends to make it a little bit cleaner 
 > and more stateless, and also factor out invoking the rectangular cropper 
 > from the platform backend - so that it's now invoked by SpectacleCore rather 
 > than the backend. But mostly I did this to clean up the crap I wrote back in 
 > 2015 when I didn't know better.
 > I'm working on this in the bgupta/platform-backend-refactor branch. I 
 > haven't hooked up the rectangular cropper back yet, but everything else 
 > should work (I've tested the Xcb backend only, not Wayland). Still to do are:
 > * Hook up window title information* Hook up the rectangular cropper
 > After this the rectangular cropper should also "just work" on Wayland, or as 
 > best as fullscreen windows work on Wayland anyway.
 > I've been merging from master and I'll keep doing that, so a review should 
 > just be a matter of diffing the two branches. The folks who currently work 
 > on Spectacle regularly, I'd be obliged if you could take a look and see if 
 > anything's wrong, or just see what I'm doing with the code. If you want me 
 > to file a diff on Differential or something, I can also do that once I'm 
 > done with everything.
 > If no one bothers to review the code I'll finish everything up and merge to 
 > master sometime this week, but then if I end up causing a regression that I 
 > didn't notice... well, please review my code :-P (I'm also thinking about 
 > how to better unittest this code, but I don't have any good ideas yet).
 > Thanks,Boudhayan

Re: Code Review: Spectacle

[Nate Graham]

  On Sun, 05 May 2019 14:16:01 -0600 Reindl Harald  
wrote 
 > Am 05.05.19 um 22:12 schrieb Nate Graham:
 > > As of 19.04, this is now an optional but off-by-default feature. Feel free 
 > > to turn it on. :)
 > 
 > that's not the point
 > 
 > the point is that it makes sense for everything but *not* "rectangle
 > selection" and that i am tired after years now switch that checkbox on
 > and off for different use cases while before "Spectacle" all worked like
 > a charme out-of-the-box


I don't think you could have been switching that checkbox on for years since it 
was just added in the 19.04 release which came out a few days ago. But feel 
free to make the case that it should be on by default and submit a simple patch 
that does it. I don't really object, myself.

Nate

Re: Code Review: Spectacle

[Nate Graham]

  On Sun, 05 May 2019 14:44:14 -0600 Reindl Harald  
wrote 
 > what are you talking about?
 > 
 > * right next to delay there is a checkbox all the time "on click"
 > * you can switch that checkbox on for years (at least on Fedora)
 > * but it makes no sense apply it for every mode
 > * when i select a rectangle from my screen for a screenshot
 >   there is not point for an additional click
 > * in case of screenshot of a window there is a point by say what window

Maybe I've misunderstood you, in which case, I apologize for confusing the 
discussion. It might make more sense to clearly explain the request in the form 
of a bug report with clear Steps to Reproduce, Expected Results, and Observed 
Results.

https://community.kde.org/Get_Involved/Bug_Reporting

Thanks!

Nate

Re: Code Review: Spectacle

[Nate Graham]

  On Sun, 05 May 2019 14:49:11 -0600 Reindl Harald  
wrote 
 > > * right next to delay there is a checkbox all the time "on click"
 > > * you can switch that checkbox on for years (at least on Fedora)
 > > * but it makes no sense apply it for every mode
 > > * when i select a rectangle from my screen for a screenshot
 > >   there is not point for an additional click
 > > * in case of screenshot of a window there is a point by say what window
 > 
 > see screenshot if it makes it to the list, there is a red mark around
 > the checkbox

Ah, I was indeed confused, sorry. So you want that checkbox to be per-mode 
rather than global, or to only apply to the "Window Under Cursor" mode? Either 
way, please file a bug report to track this request. Thanks!

Nate

Re: Problems with setting up development environment (for new devs)

[Nate Graham]

Glad to hear you got it up and running. Would you mind submitting a bug 
report for the issue over at https://invent.kde.org/kde/kdesrc-build/issues?


Also, now's the best time for you to update the wiki page 
(https://community.kde.org/Get_Involved/development) to increase the 
clarify for anything you had a hard time with while it's all still fresh 
in your mind!


VM instructions would be nice too. I've been meaning to add those for a 
while now. If you start, I'll polish it up! :)


Nate


On 5/5/19 2:11 PM, veqz wrote:

Hi,

This weekend I finally managed to get around to set up a development 
environment:


1. VM with neon Development/Unstable Edition
2. Followed the guide at 
https://community.kde.org/Get_Involved/development:

   a. sudo apt install git cmake dialog
   b. Configuring git
   c. Setting up kdesrc-build (kdesrc-build --initial-setup)
   d. Installing all non-KDE dependencies from 
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Install_the_dependencies#KDE_neon.2C_Debian.2C_Ubuntu.2C_Kubuntu 


3. Tried to compile Dolphin: kdesrc-build dolphin --include-dependencies

Which mostly worked. This programme fails to build «gpgme» and 
«kdewebkit». After asking around on #kde-devel, meven, Jucato, and 
asturm helped guide me to simply exclude the Qt-parts from the 
.kdesrc-build.rc file. After this everything seems to run fine.


Just wanted to inform whoever might consider looking at it, that the 
official guide doesn't work quite like it should.


I've included the two log files which with the error output.

–Tore M. Havn

Re: Contribution

[Nate Graham]

On 5/26/19 7:36 AM, Harshita Sahai wrote:

Respected Sir/Ma'am
I would like to contribute to your community as I believe I have the 
required skill set to contribute and hence would like to be a part of 
your community.
Please do let me know about your GitHub profile or any version control 
where your code is available and I can start understanding the code and 
then start contributing.
I have a past experience with GirlScript Summer of code 2019 and have 
contributed to Open Genus IQ

https://iq.opengenus.org/author/harshita/
Hoping for a positive response.
Thank You.
Harshita Sahai


Hello Harshita,
I would recommend starting by reading the documentation on 
https://community.kde.org/Get_Involved and 
https://community.kde.org/Get_Involved/development


Nate

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

[Nate Graham]

On 6/2/19 4:37 AM, Albert Astals Cid wrote:

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.


Hmm, that seems like it would be quite a restriction on what a Flatpak 
app could accomplish. There must be a secure way to do this.


Nate

Re: KNewStuff problem - GSOC 2019

[Nate Graham]

On 6/5/19 7:51 AM, Ferencz Kovács wrote:
> [...]
it can be found, then it's gonna be added to the valid categories. Here 
 
the uplaodDialog checks whether there are any valid categories. Which 
apperantly there are not in my case, since I'm getting the Error message 
box from the previous function. Do you have any ideas why does this 
happen? Do I have to register the categories first somewhere? Thank you 
in advance. Every tip is more than welcome.


Yes, you first need to register a new category. See for example 
https://phabricator.kde.org/T10810


Nate

Re:Request for incubation of Kup backup system

[Nate Graham]

I've been using Kup and am very impressed. Its level of system integration 
makes it a good candidate for incubation IMO and I'm quite willing to be the 
sponsor.

Simon, you would need to move the project from Github to KDE infrastructure 
(Cgit, Bugzilla, Phabricator or Gitlab, etc.). Is that acceptable?

Nate


 On Tue, 11 Jun 2019 21:23:46 -0600 simon.pers...@mykolab.com wrote 


Hello!


I want to request for my software Kup to become a KDE project. Some
basic info about the project:

- It's a backup scheduler that offers syncronized (using rsync) and
versioned (using bup) backups.

- It targets users of Plasma desktop by being integrated into the system
rather than being a standalone app. Uses system settings KCM and plasma
systray applet.

- In development since 2011, after 2015 development slowed down but has
not stopped.

- Licensed under GPL 2+.

- Description, screenshots, ratings and comments over at
https://www.linux-apps.com/p/1127689/

- Source code at https://github.com/spersson/Kup/

- Basically only me doing development, other contributions have mostly
been by packaging people for build fixes.


I have read through incubator license policy wiki pages.


Also interesting to know is that I am considering replacing the bup
backend with rsync and hardlinks between snapshots. That is a pretty big
change that would allow me to address some old feature requests (like
being able to delete old snapshots automatically). I am thinking it
could be wise to do such a big change in connection with moving and
possibly renaming the project. The renaming would not be so much for
branding or awareness (the name Kup is never show to the user of the
software, you only see it in a package manager). Instead it would be
done to prevent users from unknowingly updating to the latest version
and only later finding that storage format has changed.

Please let me know how you think it could fit in.

Thanks,

Simon

Re: How is the Font DPI Scale stored?

[Nate Graham]

On 6/12/19 9:53 AM, Elias Mårtenson wrote:
On Wed, 12 Jun 2019 at 17:27, Christoph Feck > wrote:


https://wiki.archlinux.org/index.php/Font_configuration says:

$ xrdb -query | grep dpi
Xft.dpi:        144

You can read XResources via libxcb calls, code in Qt is here:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbscreen.cpp#n357

Note that this value is deprecated, because it isn't per-screen.


Thank you. That works beautifully. I do wonder, however, if it's 
deprecated, what is meant to replace it?


Qt Scaling in the KScreen KCM (System Settings > Display & Monitor > 
Displays > Scale Display)


Nate

Re: Request for incubation of Kup backup system

[Nate Graham]

Ping. Simon, do you want to move forward with migrating the source code 
to KDE infrastructure?


Also if you're not already subscribed to the kde-devel@kde.org mailing 
list, I would recommend that or else you won't see replies to this 
thread from people using "Reply List" rather than "Reply All".


Nate



On 6/11/19 10:48 PM, Nate Graham wrote:
I've been using Kup and am very impressed. Its level of system 
integration makes it a good candidate for incubation IMO and I'm quite 
willing to be the sponsor.


Simon, you would need to move the project from Github to KDE 
infrastructure (Cgit, Bugzilla, Phabricator or Gitlab, etc.). Is that 
acceptable?


Nate


 On Tue, 11 Jun 2019 21:23:46 -0600 *simon.pers...@mykolab.com * 
wrote 


Hello!


I want to request for my software Kup to become a KDE project. Some
basic info about the project:

- It's a backup scheduler that offers syncronized (using rsync) and
versioned (using bup) backups.

- It targets users of Plasma desktop by being integrated into the
system
rather than being a standalone app. Uses system settings KCM and plasma
systray applet.

- In development since 2011, after 2015 development slowed down but has
not stopped.

- Licensed under GPL 2+.

- Description, screenshots, ratings and comments over at
https://www.linux-apps.com/p/1127689/

- Source code at https://github.com/spersson/Kup/

- Basically only me doing development, other contributions have mostly
been by packaging people for build fixes.


I have read through incubator license policy wiki pages.


Also interesting to know is that I am considering replacing the bup
backend with rsync and hardlinks between snapshots. That is a pretty
big
change that would allow me to address some old feature requests (like
being able to delete old snapshots automatically). I am thinking it
could be wise to do such a big change in connection with moving and
possibly renaming the project. The renaming would not be so much for
branding or awareness (the name Kup is never show to the user of the
software, you only see it in a package manager). Instead it would be
done to prevent users from unknowingly updating to the latest version
and only later finding that storage format has changed.

Please let me know how you think it could fit in.

Thanks,

Simon

Re: Request for incubation of Kup backup system

[Nate Graham]

On 6/16/19 7:11 PM, Simon Persson wrote:

On 2019-06-17 06:48, Nate Graham wrote:
Ping. Simon, do you want to move forward with migrating the source 
code to KDE infrastructure?


Also if you're not already subscribed to the kde-devel@kde.org mailing 
list, I would recommend that or else you won't see replies to this 
thread from people using "Reply List" rather than "Reply All".


Nate

Yes I do. I just wanted to wait for the weekend to pass, giving people a 
chance to comment. I will contact you off-list and we can get started.


I am subscribed to kde-devel.

Thanks!



Perfect, thanks. I've replied and we can continue off-list.

For anyone else who's interested, the action is now taking place at 
https://community.kde.org/Incubator/Projects/Kup


Nate

Applications 19.08 release notes

[Nate Graham]

Howdy folks,

The deadline for KDE Applications 19.08 is fast approaching and we need 
release notes! I've created 
https://notes.kde.org/p/applications_19.08_new_features and done a first 
pass on populating it with notes, but more are needed.


If your awesome features and bugfixes will land in the Applications 
19.08 release, please add it to that document so it can be included in 
the release announcement -- ideally before July 29th (sorry for the 
short notice on this). That's not a hard deadline, but sooner is better 
to give our translators enough time to localize the final announcement.



Nate

Re: Portability of KDE Applications

[Nate Graham]

As far as I understand, this is the reason why AppImage was invented. 
KDE KDE apps can be packaged as AppImages, no problem. You might want to 
look into that.


Nate


On 8/21/19 2:36 PM, Никита Сиргиенко wrote:
Yes, but setting a few environment variables for each application start 
doesn't look very user friendly.


So, I hope, there is another solution.

ср, 21 авг. 2019 г. в 21:19, Francis Herne >:


On Wednesday, 21 August 2019 18:18:10 BST Никита Сиргиенко wrote:
 > Hi all,
 >
 > Has anyone had issues with KDE Apps (based on kde frameworks)
portability?
 >
 > I mean, the app can use different types of file: .rc, .knsrc, .png,
 > additinal binary files, etc
 > The problem appears, if you installed this files non standart
installetion
 > prefix, like /opt.
 >
 > Obviously, I can forward-pass installation prefix path, binary
path, etc
 > from Cmake to the aplication, but I am interested, is there
support for
 > situtation like this from KDE frameworks?
 >
 > Just an example: the app have a few .rc files for menus, can I set
 > additional search path for kde core addons (better from cmake,
but settings
 > path for example from main.cpp not bad too, if it need done only
one time),
 > and use not absolute path?
 >
 > I know, that Kde apps more target to kde platform, but the
application is a
 > part of KdeEdu project, and portability is very important for us
(for our
 > application), because we target for students, and the students often
 > haven't administration rights on work computers, used for education.
 >
 > Best Regards,
 > Nikita

Most KDE applications are very tolerant of unusual paths.

Besides the various prefixes at build/install time, you might need
to set
environment variables, particularly QT_PLUGIN_PATH and those
specified by
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

  - Francis H

Re: Taking over maintainership of libkscreen / KScreen

[Nate Graham]

On 9/14/19 12:36 PM, Roman Gilg wrote:

On Fri, Sep 13, 2019 at 3:47 PM David Edmundson

Generally I've found bugs better handled to go to
blah-product-b...@kde.org then have people use "user watching" in
bugzilla so N people can become the default assignee without needing
extra rights.


Yea, makes sense. Christophe Giboudeaux already changed the assignee
though he said on IRC. I don't know to what and asked him that but
haven't yet received reply. But either way it should be fine for now.


I see that the current assignee has been set to the 
kscreen-bugs-n...@kde.org mailing list. Having "-null" on the end 
implies to me that this mailing list is a black hole where bug reports 
get ignored forever.


Could we use a mailing list with friendlier name?

Nate

KMPlayer releases

[Nate Graham]

I just triaged a bug about KMPlayer's AppStream ID not working properly: 
https://bugs.kde.org/show_bug.cgi?id=412542


That the AppStream ID in current git master differs from the version in 
distro repos, which is a problem because KMPlayer hasn't had a release 
in 3 years. Luigi, Alexander, and Pino (CCd), you three have dome the 
most development recently; would either of you care to make a release?


Beyond that, is there any interest in adding it to the app 
bundle/release service/whatever-we're-going-to-start-calling-it-soon so 
that releases happen regularly and automatically and we don't go years 
without a release again?


Nate

Re: KMPlayer releases

[Nate Graham]

On 10/8/19 1:59 PM, Luigi Toscano wrote:

With the current pace of development, and given the fact that KMPlayer is the
only user of a deprecated framework (KMediaPlayer), I'd say it's not worth it
right. Should the development restart, we could re-evaluate this


In my experience, one often leads to the other: more releases means more 
development, not only vice versa.


Nate

Re: How to prevent users from opening GitLab issues?

[Nate Graham]

GitLab Issues are intended to be the replacement for Phabricator tasks 
and are not intended to be used for user bug reports. We can't disable 
this feature or else we lose the project task tracking functionality 
entirely, which would be a major regression compared to Phabricator.


Yes, it is very confusing to users, and yes, we are going to be dealing 
with users clogging it up with bug reports for the foreseeable future 
until we manage to rename Issues to "Project Tasks" or add a big banner 
directing users wanting to file bugs back to Bugzilla or something.


Nate



On 10/9/19 7:40 AM, Albert Vaca Cintora wrote:

As we transition to Gitlab, our users find two different ways of
reporting issues: in Bugzilla and in Gitlab. Since we don't have plans
to deprecate bugzilla, is there any way we can disable issues in Gitlab?

Albert

Re: How to prevent users from opening GitLab issues?

[Nate Graham]

On 10/10/19 3:28 AM, Ben Cooksley wrote:

Specifying a default issue template is an Enterprise Edition only
feature i'm afraid.
Please see 
https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-merge-requests-and-issues--starter
for more information


I must admit feeling rather frustrated that so may of the features which 
make a GitHub/GitLab style of platform desirable are EE-only. Our 
crippled CE version is missing these features as well as some of the 
features that Phabricator currently has, such batching review comments, 
formal approvals, strong relationships between tasks, and a web-based 
notification system that doesn't send you ten thousand emails a day.


Nate

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

[Nate Graham]

+1


Nate




 On Sun, 13 Oct 2019 14:57:20 -0600 aa...@kde.org wrote 


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: kdesrc-build on centos 8

[Nate Graham]

Hi Mike,
Yes, kdesrc-build is the officially-supported method of building KDE 
software from source yourself (i.e. if you're not a distro packager). If 
there is ever an EPEL or COPR repo for KDE stuff on CentOS 8, that would 
probably work too.


If you're using kdesrc-build and kwindowsystem can't find libxcb-devel 
despite it being installed, we'll need more info to debug, such as the 
full failure logs.


This will probably be a fairly interactive process, so you might get 
better help asking in the #kde-devel room on Freenode IRC or Matrix.


Nate


On 10/26/19 7:56 AM, Mike wrote:

Hi everyone!

As we know, there is no support for KDE5 in any of the EL distros. I
hope, that a "kdesrc-build" script - is the fastest way to get all I
need. Is anyone already doing any work on this?
I'm trying to build KDE, for Centos 8, but it still no success. I've
done some dirty hacks, like installing packages from Fedora 29 and
Centos 7, QT5 has been built, but the most important broken component
- is kwindowsystem. It can't find libxcb-devel, even though it is
installed.

Thanks in advance!

Re: Looking for Subtitle Composer sponsor

[Nate Graham]

Hello Mladen,
I would be happy to be your sponsor!

Per https://community.kde.org/Incubator#Candidate, we need you to 
provide the following information:


- A list of the people regularly committing to the project

- A plan to be in compliance with the KDE manifesto 
(https://manifesto.kde.org/index.html). In particular, you'll need to be 
okay moving your source code repo and other infrastructure away from 
GitHub and into KDE's GitLab instance at https://invent.kde.org.



Nate



On 11/7/19 5:44 AM, Mladen Milinkovic wrote:

Hello everyone

I'm maintainer of Subtitle Composer. It's an KF5 application to 
edit/create/translate/sync video subtitles.

I would like to start the process of joining KDE and I need a sponsor.
This was already proposed in https://phabricator.kde.org/T10034.
Application project page is here: https://github.com/maxrd2/SubtitleComposer 
and relative ticket is here
https://github.com/maxrd2/SubtitleComposer/issues/74

thanks,
  Mladen

Re: Looking for Subtitle Composer sponsor

[Nate Graham]

On 11/7/19 12:55 PM, Mladen Milinkovic wrote:

Hello Nate,

On 11/7/19 3:31 PM, Nate Graham wrote:

I would be happy to be your sponsor!

Thank you!


Per https://community.kde.org/Incubator#Candidate, we need you to provide the 
following information:

- A list of the people regularly committing to the project

That would be only me I believe. Right now I'm the only one with write 
permissions to repository.
There are occasional pull requests, but nothing regular. Most pull requests are 
translations which since recently are
pulled from crowdin.com.
This should be the list of contributors since Nov 2011: 
https://github.com/maxrd2/SubtitleComposer/graphs/contributors


- A plan to be in compliance with the KDE manifesto 
(https://manifesto.kde.org/index.html). In particular, you'll need
to be okay moving your source code repo and other infrastructure away from 
GitHub and into KDE's GitLab instance at
https://invent.kde.org.

Have already created account on https://invent.kde.org/users/milinkovic. Should 
I create a personal repository there for
the project?


Sysadmin will get one set up for you.

Sysadmin, can we have a repo to host 
https://github.com/maxrd2/SubtitleComposer on KDE's infrastructure?


Nate

Re: Looking for Subtitle Composer sponsor

[Nate Graham]

On 11/8/19 2:42 AM, Ben Cooksley wrote:

We'll need a ticket submitted for this (as emails can get lost, but
tickets cannot be lost).
If you could submit one at https://go.kde.org/systickets that would be
appreciated.


Done, I've filed https://phabricator.kde.org/T11998

Nate

Re: Looking for Subtitle Composer sponsor

[Nate Graham]

One thing I forgot before we set up the git repo: you will need a 
developer account. Please apply for one at 
https://community.kde.org/Infrastructure/Get_a_Developer_Account


Nate


On 11/7/19 12:58 PM, Nate Graham wrote:

On 11/7/19 12:55 PM, Mladen Milinkovic wrote:

Hello Nate,

On 11/7/19 3:31 PM, Nate Graham wrote:

I would be happy to be your sponsor!

Thank you!

Per https://community.kde.org/Incubator#Candidate, we need you to 
provide the following information:


- A list of the people regularly committing to the project
That would be only me I believe. Right now I'm the only one with write 
permissions to repository.
There are occasional pull requests, but nothing regular. Most pull 
requests are translations which since recently are

pulled from crowdin.com.
This should be the list of contributors since Nov 2011: 
https://github.com/maxrd2/SubtitleComposer/graphs/contributors


- A plan to be in compliance with the KDE manifesto 
(https://manifesto.kde.org/index.html). In particular, you'll need
to be okay moving your source code repo and other infrastructure away 
from GitHub and into KDE's GitLab instance at

https://invent.kde.org.
Have already created account on 
https://invent.kde.org/users/milinkovic. Should I create a personal 
repository there for

the project?


Sysadmin will get one set up for you.

Sysadmin, can we have a repo to host 
https://github.com/maxrd2/SubtitleComposer on KDE's infrastructure?


Nate