Re: Update to Gitlab 16.0

[Nicolás Alvarez]

El mar, 23 may 2023 a la(s) 08:10, Ben Cooksley (bcooks...@kde.org) escribió:
>
> Gitlab is also triallng a new navigation experience, for which the 
> documentation can be found at 
> https://docs.gitlab.com/ee/tutorials/left_sidebar/index.html

You can switch to the new navigation UI by clicking your avatar on the
top right corner, and enabling "New navigation".

Please try it and submit feedback to GitLab! The earlier they get
feedback, the less you will complain when it gets rolled out to
everyone :)

-- 
Nicolás

Re: What happened to "Allow commits from members who can merge to the target branch."?

[Nicolás Alvarez]

El lun, 27 jun 2022 a la(s) 19:09, Simon Redman (si...@ergotech.com)
escribió:

> Hi all,
>
> Previously when making a PR, I was able to select a checkbox to allow
> others to merge to my PR branch:
>
>
> Now, that box seems to have vanished.
>
> Did I miss a discussion about removing this feature? It's super useful so
> that I can do small fixups to a stale PR and then merge it.
>
>
The feature should be still there. In which specific merge request did you
see the checkbox missing?

-- 
Nicolás

Re: Reviewing the process for giving people commit rights

[Nicolás Alvarez]

El vie, 1 abr 2022 a la(s) 12:29, Nate Graham (n...@kde.org) escribió:
>
> Hello folks,
>
> When someone is proposed to get commit access, currently a sponsor
> proposes it, the intended recipient contacts sysadmin, sysadmin reviews,
> and then asks the sponsor if it's okay. This process essentially only
> allows for sysadmin review, since the sponsor has already implicitly
> approved by virtue of being the sponsor.
>
> This caused a problem recently in KWin. A new contributor was given
> commit rights very soon after he appeared, and then immediately after
> that, he inappropriately merged a not-fully-reviewed an un-accepted
> merge request
> (https://invent.kde.org/plasma/kwin/-/merge_requests/1980). It seems
> that he did not have a sense of the cultural norms around committing to
> KDE repos, and giving him commit access was probably premature.
>
> I'd like to propose that we need to make the commit access review
> process open to review by more people so that we can flag issues like
> this sooner. Maybe kde-core-devel?

I would like to add that GitLab has made it *significantly* easier to
contribute without commit access. Think about what it was like in
Phabricator era (or even Reviewboard). Apart from the well known UX
issues with submitting reviews and the arc tool, once something was
approved, the author had to explicitly say they didn't have access,
the approver had to manually grab the diff and commit it with the
right author info, etc. Sometimes the reviewer would approve and wait
for the author to commit it (without knowing they didn't have commit
access) while the author waited for something to happen not knowing
what was the next step.

Now the author can just push to a fork and the reviewer can just click
Merge. For a casual contributor, they could well continue submitting
GitLab review requests forever, rather than this being necessarily a
path towards being granted commit access in the future.

Given that, if we have other reasons to change the process of granting
commit access, I don't think it would be a significant barrier to
contributions. I'm not necessarily *advocating* that we add more
restrictions to granting commit access, I just want to point out that
if we have to, we can now *afford* to do so. I don't think we could
before GitLab.

-- 
Nicolás
KDE Sysadmin Team

Re: Updates to sysadmin/repo-metadata - project topics

[Nicolás Alvarez]

It turns out the syncing of topics is giving this error, I guess it
doesn't like "Qt" as a topic:

422 {"message": "Validation Failed", "errors": ["Topics must start
with a lowercase letter or number, consist of 35 characters or less,
and can include hyphens."], "documentation_url": "https://docs.git
hub.com/rest/reference/repos#replace-all-repository-topics"}

And since the hook fails after getting the error, it doesn't even push
the commits...

-- 
Nicolás

El lun, 21 feb 2022 a la(s) 09:02, Johnny Jazeix (jaz...@gmail.com) escribió:
>
> Hi,
>
> Isn't the synchro handled automagically? There has been a few commits in the 
> last week pushed in invent.kde.org 
> (https://invent.kde.org/education/gcompris/-/commits/master) but as you say 
> they are not in the GitHub mirror.
>
> Cheers,
>
> Johnny
>
> Le lun. 21 févr. 2022 à 11:11, Ben Cooksley  a écrit :
>>
>> On Mon, Feb 21, 2022 at 5:41 AM Johnny Jazeix  wrote:
>>>
>>> Hi,
>>
>>
>> Hi Johnny,
>>
>>>
>>>
>>> Thanks for the feature!
>>>
>>> I've added some for GCompris 
>>> (https://invent.kde.org/sysadmin/repo-metadata/-/commit/43a83ede83402ca906a3ae85f84db1c4b27f3c2a)
>>>  but I don't see them in https://github.com/KDE/gcompris. Is there 
>>> something to trigger so they can appear?
>>
>>
>> We only sync changes to GitHub when the repository is pushed to, and it 
>> looks like GCompris itself hasn't been pushed to since you made that change.
>> Once you do that the changes will be synced.
>>
>>>
>>>
>>> Cheers,
>>>
>>> Johnny
>>
>>
>> Cheers,
>> Ben
>>
>>>
>>>
>>> Le dim. 13 févr. 2022 à 10:47, Alexander Semke  a 
>>> écrit :

 On Montag, 7. Februar 2022 11:05:26 CET Ben Cooksley wrote:
 > Once specified in sysadmin/repo-metadata, this information will be
 > propagated to your GitHub project mirror to aid in the discoverability of
 > your project. See
 > https://invent.kde.org/sysadmin/repo-metadata/commit/f54a6b2837f3fdfd6237257
 > ee948449306b58567 and https://github.com/KDE/labplot for an example of 
 > this.
 Thanks, Ben!

 Cheers,
 Alexander

Re: Genderidentity

[Nicolás Alvarez]

El jue, 6 ene 2022 a la(s) 14:20, Sandro Knauß (skna...@kde.org) escribió:
>
> Sorry, that follow the side discussion, that has not connected to the
> translation problem in first place.
>
> > yes, the aim is to have 2 distinct sets for the pedagogical point of view,
> > it's a bit more complicated.
>
> Me personally is not and was never ok with the gender the society gave me. And
> I fight hard against the binary gender thinking everywhere. And I'm very happy
> that we finally have a third Gender option for official documents in Germany
> called non-binary (German: Divers). Today I had some with public authorities
> about something else, but they were aware of this and didn't put me
> automatically into the binary gender box. I was very amazed.
>
> And than I read about this thread, that a program that is made for kids is
> teaching them the binary gender system and are telling me that is a good thing
> from a pedagogical point of view: Sorry NO! This is discriminating and making
> it less likely that we will overcome with the discrimination.
>
> I know it is hard but we should find a separation attribute, that is not
> discriminating e.g. color of cloths.

There is a time and place to teach kids about the complexity of gender
and I don't think an exercise about arithmetic/counting is the right
place.
https://en.wikipedia.org/wiki/Lie-to-children

-- 
Nicolás

Re: State of server-side retrace of KDE crashes?

[Nicolás Alvarez]

El jue, 16 dic 2021 a la(s) 19:28, Lyubomir Parvanov
(liubomi...@gmail.com) escribió:
>
> On Arch the situation with the debug symbols is tragic for the bad, we get 
> the first bugs (and the first fixes), but we can't report bugs that are hard 
> to reproduce because we have to reinstall the whole goddamn apps for symbols 
> to work and then to pray to God to be able to reproduce the bug again.
> There were some talks about adding a server-side retrace service for KDE, 
> what's the latest status quo? I really believe that KDE would be way more 
> stable if this was existing...

If Arch doesn't have symbol packages, where would KDE's magic retrace
server get the symbols matching your exact Arch binaries?

--
Nicolás

Re: OCS Providers File - High Numbers of Requests

[Nicolás Alvarez]

El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) escribió:
>
> On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
>  wrote:
> >
> > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> > escribió:
> > >
> > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > It has recently come to our attention that the number of queries being 
> > > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml 
> > > > on a day to day basis has gotten to the point where it is causing 
> > > > issues with server responsiveness to other traffic. This is perhaps 
> > > > best summarised by the following:
> > > >
> > > > root@nicoda /var/log/apache2 # ls -lah ...
> > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > > >
> > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > > 4,222,343
> > > >
> > > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > > average - peaks are much higher by many magnitudes), which seems 
> > > > extremely excessive given that this file is only supposed to be 
> > > > retrieved by KDE software when GHNS functionality is triggered. That is 
> > > > supported by the substantial size difference it has over 
> > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager 
> > > > (on Neon) to check for whether they have a working internet connection 
> > > > - which i'd expect to be the site receiving the most traffic.
> > > >
> > > > As such, I therefore suspect we have bug(s) in software that makes use 
> > > > of GHNS functionality.
> > > >
> > > > It would therefore be appreciated if we could please review the 
> > > > software in question to determine whether it is operating correctly. 
> > > > Given that it usually runs in the background on user systems, i'd 
> > > > especially appreciate it if a detailed review could be conducted on 
> > > > Discover and other software that conducts package management operations 
> > > > or assists in managing updates.
> > > >
> > > > Unfortunately all these applications submit a fairly useless user agent 
> > > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > > > information. If we could get information on the software that is 
> > > > originating the request added to the user agent to assist in 
> > > > investigating these issues in the future that would be extremely 
> > > > helpful.
> > > >
> > > > Thanks,
> > > > Ben
> > >
> > > That's correct. Discover fetches them at startup. It's necessary to be
> > > able to check if there are updates on KNS-provided resources.
> > >
> > > Incidentally,  I was looking into this yesterday incidentally. We
> > > could see if caching is broken somehow. A request will still be needed
> > > though to check if the cache is out of date.
> >
> > Caching seems to be working, since the vast majority of the requests
> > are returning 304 Not Modified.
> >
> > However in *many* cases I see a single IP making multiple requests in
> > the same second, and doing it again the next minute. Here's one IP
> > address picked randomly:
> >
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021

Re: OCS Providers File - High Numbers of Requests

[Nicolás Alvarez]

El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) escribió:
>
> On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
>  wrote:
> >
> > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> > escribió:
> > >
> > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > It has recently come to our attention that the number of queries being 
> > > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml 
> > > > on a day to day basis has gotten to the point where it is causing 
> > > > issues with server responsiveness to other traffic. This is perhaps 
> > > > best summarised by the following:
> > > >
> > > > root@nicoda /var/log/apache2 # ls -lah ...
> > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > > >
> > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > > 4,222,343
> > > >
> > > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > > average - peaks are much higher by many magnitudes), which seems 
> > > > extremely excessive given that this file is only supposed to be 
> > > > retrieved by KDE software when GHNS functionality is triggered. That is 
> > > > supported by the substantial size difference it has over 
> > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager 
> > > > (on Neon) to check for whether they have a working internet connection 
> > > > - which i'd expect to be the site receiving the most traffic.
> > > >
> > > > As such, I therefore suspect we have bug(s) in software that makes use 
> > > > of GHNS functionality.
> > > >
> > > > It would therefore be appreciated if we could please review the 
> > > > software in question to determine whether it is operating correctly. 
> > > > Given that it usually runs in the background on user systems, i'd 
> > > > especially appreciate it if a detailed review could be conducted on 
> > > > Discover and other software that conducts package management operations 
> > > > or assists in managing updates.
> > > >
> > > > Unfortunately all these applications submit a fairly useless user agent 
> > > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > > > information. If we could get information on the software that is 
> > > > originating the request added to the user agent to assist in 
> > > > investigating these issues in the future that would be extremely 
> > > > helpful.
> > > >
> > > > Thanks,
> > > > Ben
> > >
> > > That's correct. Discover fetches them at startup. It's necessary to be
> > > able to check if there are updates on KNS-provided resources.
> > >
> > > Incidentally,  I was looking into this yesterday incidentally. We
> > > could see if caching is broken somehow. A request will still be needed
> > > though to check if the cache is out of date.
> >
> > Caching seems to be working, since the vast majority of the requests
> > are returning 304 Not Modified.
> >
> > However in *many* cases I see a single IP making multiple requests in
> > the same second, and doing it again the next minute. Here's one IP
> > address picked randomly:
> >
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021

Re: OCS Providers File - High Numbers of Requests

[Nicolás Alvarez]

El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) escribió:
>
> On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
>  wrote:
> >
> > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> > escribió:
> > >
> > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > It has recently come to our attention that the number of queries being 
> > > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml 
> > > > on a day to day basis has gotten to the point where it is causing 
> > > > issues with server responsiveness to other traffic. This is perhaps 
> > > > best summarised by the following:
> > > >
> > > > root@nicoda /var/log/apache2 # ls -lah ...
> > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > > >
> > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > > 4,222,343
> > > >
> > > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > > average - peaks are much higher by many magnitudes), which seems 
> > > > extremely excessive given that this file is only supposed to be 
> > > > retrieved by KDE software when GHNS functionality is triggered. That is 
> > > > supported by the substantial size difference it has over 
> > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager 
> > > > (on Neon) to check for whether they have a working internet connection 
> > > > - which i'd expect to be the site receiving the most traffic.
> > > >
> > > > As such, I therefore suspect we have bug(s) in software that makes use 
> > > > of GHNS functionality.
> > > >
> > > > It would therefore be appreciated if we could please review the 
> > > > software in question to determine whether it is operating correctly. 
> > > > Given that it usually runs in the background on user systems, i'd 
> > > > especially appreciate it if a detailed review could be conducted on 
> > > > Discover and other software that conducts package management operations 
> > > > or assists in managing updates.
> > > >
> > > > Unfortunately all these applications submit a fairly useless user agent 
> > > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > > > information. If we could get information on the software that is 
> > > > originating the request added to the user agent to assist in 
> > > > investigating these issues in the future that would be extremely 
> > > > helpful.
> > > >
> > > > Thanks,
> > > > Ben
> > >
> > > That's correct. Discover fetches them at startup. It's necessary to be
> > > able to check if there are updates on KNS-provided resources.
> > >
> > > Incidentally,  I was looking into this yesterday incidentally. We
> > > could see if caching is broken somehow. A request will still be needed
> > > though to check if the cache is out of date.
> >
> > Caching seems to be working, since the vast majority of the requests
> > are returning 304 Not Modified.
> >
> > However in *many* cases I see a single IP making multiple requests in
> > the same second, and doing it again the next minute. Here's one IP
> > address picked randomly:
> >
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > [22/Sep/2021

Re: OCS Providers File - High Numbers of Requests

[Nicolás Alvarez]

El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) escribió:
>
> On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > It has recently come to our attention that the number of queries being 
> > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> > day to day basis has gotten to the point where it is causing issues with 
> > server responsiveness to other traffic. This is perhaps best summarised by 
> > the following:
> >
> > root@nicoda /var/log/apache2 # ls -lah ...
> > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> >
> > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > 4,222,343
> >
> > Based on those numbers we're looking at 48-49 requests per second (on 
> > average - peaks are much higher by many magnitudes), which seems extremely 
> > excessive given that this file is only supposed to be retrieved by KDE 
> > software when GHNS functionality is triggered. That is supported by the 
> > substantial size difference it has over networkcheck.kde.org - which is 
> > used by plasma-nm and NetworkManager (on Neon) to check for whether they 
> > have a working internet connection - which i'd expect to be the site 
> > receiving the most traffic.
> >
> > As such, I therefore suspect we have bug(s) in software that makes use of 
> > GHNS functionality.
> >
> > It would therefore be appreciated if we could please review the software in 
> > question to determine whether it is operating correctly. Given that it 
> > usually runs in the background on user systems, i'd especially appreciate 
> > it if a detailed review could be conducted on Discover and other software 
> > that conducts package management operations or assists in managing updates.
> >
> > Unfortunately all these applications submit a fairly useless user agent 
> > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > information. If we could get information on the software that is 
> > originating the request added to the user agent to assist in investigating 
> > these issues in the future that would be extremely helpful.
> >
> > Thanks,
> > Ben
>
> That's correct. Discover fetches them at startup. It's necessary to be
> able to check if there are updates on KNS-provided resources.
>
> Incidentally,  I was looking into this yesterday incidentally. We
> could see if caching is broken somehow. A request will still be needed
> though to check if the cache is out of date.

Caching seems to be working, since the vast majority of the requests
are returning 304 Not Modified.

However in *many* cases I see a single IP making multiple requests in
the same second, and doing it again the next minute. Here's one IP
address picked randomly:

[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304

This continues for hours. And it's not an isolated case; again, the IP
I searched 

Re: OCS Providers File - High Numbers of Requests

[Nicolás Alvarez]

El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) escribió:
>
> On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > It has recently come to our attention that the number of queries being 
> > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> > day to day basis has gotten to the point where it is causing issues with 
> > server responsiveness to other traffic. This is perhaps best summarised by 
> > the following:
> >
> > root@nicoda /var/log/apache2 # ls -lah ...
> > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> >
> > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > 4,222,343
> >
> > Based on those numbers we're looking at 48-49 requests per second (on 
> > average - peaks are much higher by many magnitudes), which seems extremely 
> > excessive given that this file is only supposed to be retrieved by KDE 
> > software when GHNS functionality is triggered. That is supported by the 
> > substantial size difference it has over networkcheck.kde.org - which is 
> > used by plasma-nm and NetworkManager (on Neon) to check for whether they 
> > have a working internet connection - which i'd expect to be the site 
> > receiving the most traffic.
> >
> > As such, I therefore suspect we have bug(s) in software that makes use of 
> > GHNS functionality.
> >
> > It would therefore be appreciated if we could please review the software in 
> > question to determine whether it is operating correctly. Given that it 
> > usually runs in the background on user systems, i'd especially appreciate 
> > it if a detailed review could be conducted on Discover and other software 
> > that conducts package management operations or assists in managing updates.
> >
> > Unfortunately all these applications submit a fairly useless user agent 
> > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > information. If we could get information on the software that is 
> > originating the request added to the user agent to assist in investigating 
> > these issues in the future that would be extremely helpful.
> >
> > Thanks,
> > Ben
>
> That's correct. Discover fetches them at startup. It's necessary to be
> able to check if there are updates on KNS-provided resources.
>
> Incidentally,  I was looking into this yesterday incidentally. We
> could see if caching is broken somehow. A request will still be needed
> though to check if the cache is out of date.

Caching seems to be working, since the vast majority of the requests
are returning 304 Not Modified.

However in *many* cases I see a single IP making multiple requests in
the same second, and doing it again the next minute. Here's one IP
address picked randomly:

[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304

This continues for hours. And it's not an isolated case; again, the IP
I searched 

Re: OCS Providers File - High Numbers of Requests

[Nicolás Alvarez]

El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) escribió:
>
> On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > It has recently come to our attention that the number of queries being 
> > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> > day to day basis has gotten to the point where it is causing issues with 
> > server responsiveness to other traffic. This is perhaps best summarised by 
> > the following:
> >
> > root@nicoda /var/log/apache2 # ls -lah ...
> > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> >
> > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > 4,222,343
> >
> > Based on those numbers we're looking at 48-49 requests per second (on 
> > average - peaks are much higher by many magnitudes), which seems extremely 
> > excessive given that this file is only supposed to be retrieved by KDE 
> > software when GHNS functionality is triggered. That is supported by the 
> > substantial size difference it has over networkcheck.kde.org - which is 
> > used by plasma-nm and NetworkManager (on Neon) to check for whether they 
> > have a working internet connection - which i'd expect to be the site 
> > receiving the most traffic.
> >
> > As such, I therefore suspect we have bug(s) in software that makes use of 
> > GHNS functionality.
> >
> > It would therefore be appreciated if we could please review the software in 
> > question to determine whether it is operating correctly. Given that it 
> > usually runs in the background on user systems, i'd especially appreciate 
> > it if a detailed review could be conducted on Discover and other software 
> > that conducts package management operations or assists in managing updates.
> >
> > Unfortunately all these applications submit a fairly useless user agent 
> > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > information. If we could get information on the software that is 
> > originating the request added to the user agent to assist in investigating 
> > these issues in the future that would be extremely helpful.
> >
> > Thanks,
> > Ben
>
> That's correct. Discover fetches them at startup. It's necessary to be
> able to check if there are updates on KNS-provided resources.
>
> Incidentally,  I was looking into this yesterday incidentally. We
> could see if caching is broken somehow. A request will still be needed
> though to check if the cache is out of date.

Caching seems to be working, since the vast majority of the requests
are returning 304 Not Modified.

However in *many* cases I see a single IP making multiple requests in
the same second, and doing it again the next minute. Here's one IP
address picked randomly:

[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304
[22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304

This continues for hours. And it's not an isolated case; again, the IP
I searched 

Re: Should we change how we approve developer account requests?

[Nicolás Alvarez]

El lun, 16 de ago. de 2021 a la(s) 13:50, Nate Graham (n...@kde.org) escribió:
> While writing an email in support of a recent request for developer
> access that I encouraged someone to apply for, it struck me as odd that
> the sponsor can approve. I would expect the sponsor to approve or else
> they would not have sponsored the application in the first place!

It's not that odd :) We as sysadmins don't know if you're actually
sponsoring them until you reply approving the request, since people
can request developer access and enter any name as the sponsor. That's
pretty much what the approval is for, to confirm you did encourage
them to apply.

In fact we have gotten responses like "I actually don't know who this
is" or "I have been working with this person but I think this request
is premature, they should continue working via MRs for now". Or us
sysadmins looking at the contribution history and applying some extra
judgement ("you said you approve but I only see one patch from them,
are you sure?" or otherwise asking the sponsor for more info). I don't
remember that ever ending in disagreement between the sponsor and the
admin though.

> Instead, wouldn't it make more sense to require other non-sponsors to
> approve too? This would create a meaningful review process and prevent
> one person from approving all their friends willy-nilly.

...but you're right that this still means dev access requests are
approved by 1 person (the sponsor), and if you think that should
change, that's a valid discussion to have with the wider community.

--
Nicolás
KDE Sysadmin Team

Re: Issue with translation in Dolphin

[Nicolás Alvarez]

El mar, 1 de jun. de 2021 a la(s) 03:16, Johnny Jazeix
(jaz...@gmail.com) escribió:
>
>
>
> Le lun. 31 mai 2021 à 21:47, Albert Astals Cid  a écrit :
>>
>> El dilluns, 31 de maig de 2021, a les 21:22:52 (CEST), Johnny Jazeix va 
>> escriure:
>> > Hi,
>> >
>> > French translation team received a bug (
>> > https://bugs.kde.org/show_bug.cgi?id=437856) for a translation issue within
>> > Dolphin.
>> >
>> > The issue resides in this code:
>> > https://invent.kde.org/system/dolphin/-/blob/master/src/kitemviews/kfileitemmodel.cpp#L2182-2194
>> > where we expect "'Earlier on' , " to be translated with something
>> > like "'translated text' , ".
>> >
>> > In French, we have translated this single quote to French guillemets "«
>> > translated text » , ".
>> >
>> > Looking at the code, can you confirm it should be kept with single quotes
>> > instead? If yes, does having a translator comment would help avoiding the
>> > issue?
>>
>> Yes, the code needs ' since it's passed to QDateTime::toString.
>>
>> The quotes are not shown to the user, they are used to mark a section as 
>> "this is text, just pass it though, don't try to do MMM or  substitution 
>> here".
>>
>
> Thanks for confirming, I've updated it.
>
>> Given that the translation comment is already already very long, what would 
>> you suggest?
>>
>
> "Keep the words between single quotes in single quotes"? I'm not sure if 
> French is an exception here on changing the single quotes sometimes to 
> guillemets. If this is the only times we have a bug filled for it, maybe it's 
> not needed to add a new comment.

Maybe this should use a comment instead of the translation context,
since it's getting so long?
https://api.kde.org/frameworks/ki18n/html/prg_guide.html#ctxt_extc

-- 
Nicolás

Re: Shall we condense the bots' commit announcements

[Nicolás Alvarez]

El mar, 25 de may. de 2021 a la(s) 21:59, Frederik Schwarzer
(schwar...@kde.org) escribió:
>
> Hi,
>
> I would not object to this change. Maybe keep the longer versions in
> #kde-commits?

Currently the script first creates the message to send for the commit,
and then sends it to multiple channels. Sending a different message
(shorter vs longer) to different channels for a given commit is doable
but would need some extensive refactoring to the code.

> Another thought I had was that GIT_SILENT messages could be omitted.
> Maybe also worth considering?

Seems this is already possible in the configuration, per channel. Some
channels have notify_silent=False:
https://invent.kde.org/sysadmin/irc-notifications/-/blob/master/gateway/notifications.cfg

-- 
Nicolás

> Cheers
> Frederik
>
>
> On 5/25/21 11:25 PM, Nate Graham wrote:
> > Hello all,
> >
> > Recently we removed the commit announcement bots from the #plasma and
> > #kwin chatrooms because we felt their output was too noisy. However for
> > the rooms where they are still active and announcing git commits, would
> > people appreciate it if the announcements were shorter?
> >
> > For example, instead of sending 5 messages (title, first three lines,
> > and URL) the announcement could send one message (something like title
> > and URL combined).
> >
> > Would anyone object to this change?
> >
> > Nate

Re: Restore SVN developer/commiter access

[Nicolás Alvarez]

El mié, 28 de abr. de 2021 a la(s) 08:24, Diniz Bortolotto
(diniz.bortolo...@gmail.com) escribió:
>
> Hi friends!
>
> I'm a translator/dev from ancient times. :-D
> I'm trying to get back to contributing to KDE. But, of course, I've lost my 
> old SSH keys.
>
> diniz@darkstar:/home$ ssh s...@svn.kde.org
> s...@svn.kde.org: Permission denied (publickey).
>
> Could someone help me to update that on the SVN server?
> I'm already in the /trunk/kde-common/accounts file. See below:
> 644diniz Diniz Bortolotto diniz.bortolo...@gmail.com
>
>
> I also updated SSH Key on https://identity.kde.org/ and 
> https://invent.kde.org/
> In advance I'm sending my new PubKey attached to this email to update SVN 
> server.
>
> Best regards!
> Diniz Bortolotto

Hello Diniz,

The process to periodically update SSH keys on the SVN server from
Invent is somewhat slow, so in order to speed it up, we have a list of
developers who actually need/use SVN, and we only update the keys for
those.

I have now added you to the list, and you should be able to connect to
s...@svn.kde.org.

PS: SSH keys on Identity don't do anything anymore, and the fact that
they're still there is confusing. If any PHP programmer wants to
contribute and remove them from the web UI, I'm happy to guide them.
Could be a good junior job for someone new to the community too.
https://invent.kde.org/websites/identity-kde-org/-/issues/2

--
Nicolás
KDE Sysadmin Team

Re: Is there (going to be) an auto-retracer service for KDE?

[Nicolás Alvarez]

El lun, 26 de abr. de 2021 a la(s) 08:07, Harald Sitter
(sit...@kde.org) escribió:
> Also going off on a tangent: On windows I understand the store already
> has crash tracking and all that stuff implemented, I expect the same
> is true for OSX?

macOS has crash tracking built in, but as far as I know it's only if
you're on the Mac App Store, which Krita isn't. If you distribute the
Mac app yourself, you have to deal with crash reporting yourself too.

-- 
Nicolás

Re: Requiring Qt 5.15 for KDE Frameworks 5?

[Nicolás Alvarez]

> El 27 mar. 2021, a la(s) 12:30, Fabian Vogt  escribió:
> Moin,
> 
> Am Samstag, 27. M?rz 2021, 14:11:38 CET schrieb David Faure:
> On samedi 27 mars 2021 12:51:37 CET Kai Uwe Broulik wrote:
 Hi everyone,
 during the ongoing KDE Frameworks 6 sprint we were just contemplating
 whether we can bump the required Qt dependency for Frameworks 5 to Qt 5.15.
 Reason being that Qt 5.15 includes a set of porting aids and
 forward-compatibility with Qt 6, such as version-less "Qt" rather than
 "Qt5" CMake target, various QStringView-related features, and so on.
 We would like to start working on KDE Frameworks 6 on Qt 6 but still
 keep Frameworks 5 supported with as little overhead as possible, i.e.
 not having a gazillion ifdefs or even dedicated branch, which we would
 likely need, should we have to continue supporting Qt 5.14 in the process.
 Are there any objections or concerns or potential release schedule
 conflicts if we did that?
>> While at it, can we also get your feedback on
>> * Requiring C++17
> 
> Which for GCC means at least g++ 9 in practice due to std::filesystem?

I think we need to be more specific and say what is the minimum compiler 
version. Maybe we can set g++8 as the minimum and use C++17 language features 
while avoiding std::filesystem.

But only if someone actually cares about keeping gcc8 support :)

-- 
Nicolás

Re: Safely storing an application's API keys

[Nicolás Alvarez]

> El 18 ene. 2021, a la(s) 08:22, Jean-Baptiste Mardelle  
> escribió:
> 
> Hi all,
> 
> For Kdenlive, we are planning to expand the use of online services to 
> download 
> ambiance music or videos for use in personal projects. To this purpose, most 
> online services provide us an API key that is used to identify our app 
> (Kdenlive) when querying their API.
> 
> Does anyone have experience / advice on how to protect these API keys so that 
> they are not publicly available ? Is there any KDE online service or 
> framework 
> helping to achieve that ?
> 
> Thanks in advance for your help,
> 
> Jean-Baptiste Mardelle

Protecting an API key on a locally-running application is impossible even for a 
closed source app. It's equivalent to the impossible task DRM intends to 
achieve (hiding the content decryption key from the user while decrypting 
content on their computer). If you give the application to the user, as opposed 
to running everything in a server, the key *will* be publicly available.

https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/imap/gmailpasswordrequester.cpp#0016

-- 
Nicolas

Re: Plugin development - old library version keeps being used after recompiling

[Nicolás Alvarez]

El sáb, 16 de ene. de 2021 a la(s) 04:50, David Lerch
(alemariusne...@gmail.com) escribió:
>
> Hey,
>
> I'm starting development of a ThumbCreator-based thumbnailer plugin
> based on kffmpegthumbnailer
> (https://github.com/dirkvdb/ffmpegthumbnailer/tree/master/kffmpegthumbnailer)
> and ffmpegthumbs (https://invent.kde.org/multimedia/ffmpegthumbs), and
> I have managed to get some simple code working in Dolphin.
>
> The problem is that some part of the system (some kind of KDE service
> cache?) seems to be caching my thumbnailer's shared library because
> when I change its code and recompile, the new changes don't seem to
> come into effect right away. I don't know what triggers it to
> eventually load the new version - it seems to just magically happen
> after a few minutes. Even if I restart Dolphin, disable and re-enable
> the thumbnailer in Dolphin, or run `kbuildsycoca5 --noincremental` -
> it doesn't seem to change anything. It's borderline impossible to
> develop when I can never be sure if it's running the old or the new
> version.
>
> My current code isn't online anywhere yet, but it's still mostly
> identical to kffmpegthumbnailer if that helps. I simply symlinked the
> .so-file in /usr/lib/x86_64-linux-gnu/qt5/plugins (so it should always
> see the newest version), the .desktop-file for the service in
> /usr/share/kservices5 and the .kcfg-file in /usr/share/config.kcfg.
>
> Can I maybe force KDE to reload the new library, or something similar?

KIO plugins run in separate processes, not inside Dolphin. There isn't
a "shared library cache", it's just the thumbnailer is still running
in the background.

The process will be shown as something like "thumbnail.so [kdeinit5]
thumbnail", as a child process of either kdeinit5, or of Dolphin (if
you used KDE_FORK_SLAVES as Meven suggested). Try "killall
thumbnail.so".

-- 
Nicolás

Re: Licensing - KGet

[Nicolás Alvarez]

El mar, 24 de nov. de 2020 a la(s) 19:37, Justin Zobel
(justin.zo...@gmail.com) escribió:
>
> Hey Team,
>
> Been doing bug triage on bugs.kde.org and I came across this one. I'm
> not going to touch it as licensing is a delicate subject.
>
> Can someone familiar with or working on the kget team please action
> this ticket, thanks.
>
> https://bugs.kde.org/show_bug.cgi?id=330881

I see you marked that as a duplicate of 322396, so I have posted my
non-legal-but-maybe-correct understanding there.

-- 
Nicolás

Re: Telemetry information in Plasma

[Nicolás Alvarez]

El lun., 9 de nov. de 2020 a la(s) 13:32, Aleix Pol (aleix...@kde.org) escribió:
> - BasicUsageStatistics
> Usage time
> Launches count (Discover)

Is "launches count" reset to 0 after each telemetry submission, or is
it cumulative / lifetime launch count?

> - DetailedUsageStatistics
> Panel Count (Plasma shell)
> Application Source Name (Discover)

What is Application Source Name? Is this actually implemented? The
database seems to have pure NULLs but I may be looking in the wrong
place.

-- 
Nicolás

Re: How do you deal with incomplete commits?

[Nicolás Alvarez]

El lun., 2 de nov. de 2020 a la(s) 15:01, David Hurka
(david.hu...@mailbox.org) escribió:
>
> > I ended up writing a local pre-commit hook, which has the advantage of
> > triggering on the commit directly after "the problem commit", thus
> > increasing the likelihood there is still a trivial way to sort
> > things out.
>
> It would probably be nice to have some post-checkout commit, with which you
> can spit you own WIP commit message in your face, right after you switch to
> your work branch.
>
> There are update.sample and post-update.sample, but my git knowledge is
> missing in this point. What is “update”?

You want 'post-checkout' for this. The 'update' and 'post-update'
aren't useful here, they are for the server-side of git push (see the
'githooks' manpage).

> And now that we discovered that this is possible: I would like to have the
> pre-commit hook globally, that would fit my workflow nicely. How can I do
> that? My home directory is unfortunately not a git repository. ;)

You can use ~/.gitconfig to change core.hooksPath to a central
directory, but then per-repository hooks will no longer work (search
hooksPath in the 'git-config' manpage). That's a shame, I hoped there
would be a way to have both global and per-repo hooks...

-- 
Nicolás

Re: How do you deal with incomplete commits?

[Nicolás Alvarez]

El sáb., 31 de oct. de 2020 a la(s) 15:19, Thomas Friedrichsmeier
(thomas.friedrichsme...@kdemail.net) escribió:
>
> Am Sat, 31 Oct 2020 17:09:22 +0100
> schrieb David Hurka :
> > Maybe you could write your own commit hook, which prevents commiting
> > anything when `git log --oneline` matches, say /\A INCOMPLETE/x.
>
> Hm, true, it doesn't have to be a server-side hook. Thanks for pointing
> me in the right direction.
>
> Thomas

I was going to try writing a client-side hook to block pushes if the
commit message has a certain keyword, but I found the pre-push.sample
included with git already does *exactly* that :D All you need to do is
rename .git/hooks/pre-push.sample to remove the .sample suffix.

-- 
Nicolás

Re: Commit hookscripts operating only on commits from email addresses associated with a Bugzilla account

[Nicolás Alvarez]

El jue., 13 de ago. de 2020 a la(s) 15:49, Nate Graham (n...@kde.org) escribió:
> On 8/13/20 12:19 PM, Ben Cooksley wrote:
> > The only way to implement what you are proposing would be to have all
> > Bugzilla actions from commit hooks take place as a 'Bot' user.
>
> That seems reasonable in the abstract, but this would mess with people's
> commit stats since their own Bugzilla accounts wouldn't get the credit
> for fixing bugs. :)
>
> So here's an idea: close the bug with the committer's own Bugzilla
> account when an account is found that matches the email address in the
> commit. Otherwise, use a bot account so that the bug at least gets
> closed as intended. Could that work?

I think it could work, but it's not that easy to implement :)
Currently the hook code blindly sends an email to
bug-cont...@bugs.kde.org, it's all asynchronous. It doesn't know if an
account exists, or what Bugzilla does with that email once received.
To know if an account exists, we would need to make it use the
Bugzilla API...

--
Nicolás

Re: Redundant packaging mailing lists

[Nicolás Alvarez]

El mar., 28 de jul. de 2020 a la(s) 14:02, Nate Graham (n...@kde.org) escribió:
>
> On 7/28/20 10:17 AM, Bernhard Rosenkraenzer wrote:
> > AFAIK distributi...@kde.org is a public list and 
> > kde-distro-packag...@kde.org is a closed list for people with access to 
> > milonia. I don't think anyone ever posted passwords or anything to k-d-p, 
> > so unless the announcement of early tarballs is considered sensitive, 
> > there's not really much of a need for a closed list.
> >
> > ttyl
> > bero
>
> What is "milonia"?
>
> If there's no need for this list, then yeah, perhaps we should close it
> down.

milonia is the server where download.kde.org is hosted. Some distro
packagers have ssh access to the server to download Frameworks and
Plasma tarballs early before they are publicly available on download.ko.


--
Nicolás

Re: KDiff3 1.8.3 Release Notes

[Nicolás Alvarez]

Hmm, I'm not sure if that's GPL-compliant (is it necessary to mention
license in the app description page?), but I would need to buy it to
be sure (do they provide license and pointer to source code in the
installed package?). The same publisher is selling 14 other FOSS apps
with similarly questionable license compliance...

-- 
Nicolás

El mar., 7 de jul. de 2020 a la(s) 11:37, Jonathan Riddell
(j...@jriddell.org) escribió:
>
> I'm writing up the app updates for July and want to include kdiff3.  I see a 
> version is available in the Microsoft Store.  Do you know who published that?
>
> https://www.microsoft.com/en-gb/p/kdiff-3-diff-utility/9ndvvx243rfh?activetab=pivot:overviewtab#
>
> Jonathan
>
>
> On Fri, 26 Jun 2020 at 20:05, Michael Reeves  wrote:
>>
>> KDiff3 1.8.3 is now released.
>> It can be found at https://download.kde.org/stable/kdiff3/
>> kdiff3-1.8.3.tar.xz.mirrorlist
>>
>> MacOS X and Windows 64 bit binaries have also been released.
>>
>> Known Issues/Limitations:
>>
>> *As of this time binary comparison has been temporarily disabled due to
>> stability concerns. I hope to have this back for the next major release.
>> *KIO integration is currently problematic. Some non-file protocols cause 
>> hangs/
>> crashes. This has been observed with "fish://". The issue is the result 
>> signal
>> from KIO. For reason unknown to me this is not always received by KDiff3.
>> This leads to abnormal behavior. Canceling such jobs should work as expected.
>> *KDiff3 due to multiple design issues is extremely inefficient both in terms 
>> of
>> speed and memory usage. This is a carry over from the old kde4 code base.
>> Work to fix this is being done in master but requires significant reworking.
>>
>> Fixes for this release:
>>
>> *Using kdiff3 as a difftool for git will no longer trigger errors on non-
>> existent files.
>> *Errors during directory comparison are properly queued so only one message
>> will appear.
>> *Fixes reload on issues Windows due to Qt behavior differences.
>> *Fixes crash when clipboard is not available.
>> *Full screen toggle has been reworked to avoid a problematic Qt API call.
>>
>> This also includes multiple stability fixes from 1.8.2.

Re: Gitlab Turn-off Issues

[Nicolás Alvarez]

El dom., 28 de jun. de 2020 a la(s) 19:02, Albert Astals Cid
(aa...@kde.org) escribió:
>
> El diumenge, 28 de juny de 2020, a les 22:29:06 CEST, Nicolás Alvarez va 
> escriure:
> > El dom., 28 de jun. de 2020 a la(s) 16:47, Nate Graham (n...@kde.org) 
> > escribió:
> > >
> > > On 6/28/20 12:28 PM, Ben Cooksley wrote:
> > > > On Mon, Jun 29, 2020 at 4:28 AM Allen Winter  wrote:
> > > >>
> > > >> Can we remove the Issues feature on all invent projects?
> > > >> We're starting to see more and more people adding Issues.
> > > >>
> > > >> For KOrganizer, bshah replaced Issues with Bugzilla.
> > > >>
> > > >> I very much doubt we want or are ready to replace Bugzilla.
> > > >
> > > > As has been discussed *far too many times* already, we have NO
> > > > INTENTION to replace Bugzilla at this stage.
> > > > This matter has been discussed on many threads, including on this list
> > > > in the past.
> > > >
> > > > Issues on Gitlab is intended to be the replacement for Phabricator 
> > > > Tasks.
> > > > Disabling them would leave projects with no developer task management
> > > > functionality, which would be highly undesirable as they are heavily
> > > > used by a number of projects.
> > > >
> > > > Your request to disable them for all KDE projects is therefore declined.
> > >
> > > The problem with this approach is that users familiar with GitHub or
> > > GitLab in other projects will not stop submitting bug reports using
> > > GitLab issues as long as it's turned on in its current form
> >
> > Hmm... Users familiar with GitHub in other projects will not stop
> > submitting pull requests on the KDE GitHub mirror as long as that's
> > turned on, and GitHub doesn't even let us turn off pull requests.
> > Should we get rid of the GitHub mirror? Or should we keep closing pull
> > requests and telling people to send their patches to Invent instead?
> > (This is only half-rhetoric, I actually wouldn't mind getting rid of
> > the GitHub mirror :P)
> >
> > > However the issue (har har) of users submitting bug reports and feature
> > > requests using GitLab issues is not likely to disappear without some
> > > kind of change.
> >
> > We can't easily change the label of the sidebar button. But what about
> > a banner like this:
> > https://invent.kde.org/games/kbounce/-/issues/new
> >
> > Do you think this would help?
>
> When creating an issue in gitlab.com you get a long wall of text saying what 
> you have to do https://i.imgur.com/ly2mU3M.png
>
> Could we have something like that by default saying "this is for developer 
> tasks for bugs/issues use bugs.kde.org" ?

Apparently that's not available in GitLab's free edition:
https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-merge-requests-and-issues--starter

--
Nicolás

Re: Gitlab Turn-off Issues

[Nicolás Alvarez]

El dom., 28 de jun. de 2020 a la(s) 17:29, Nicolás Alvarez
(nicolas.alva...@gmail.com) escribió:
> El dom., 28 de jun. de 2020 a la(s) 16:47, Nate Graham (n...@kde.org) 
> escribió:
> > However the issue (har har) of users submitting bug reports and feature
> > requests using GitLab issues is not likely to disappear without some
> > kind of change.
>
> We can't easily change the label of the sidebar button. But what about
> a banner like this:
> https://invent.kde.org/games/kbounce/-/issues/new
>
> Do you think this would help?

Okay, this was a banner showing: "Issues on KDE Invent are for
developers to keep track of ongoing work. If you want to report a bug
or request a feature, please go to the KDE bug tracker [link]". I
restricted it to only appear on kbounce's "new issue" page to test it.
However I just found that the banner text appears on the output of
"git push" to any repository (after the "This commit is available at:"
message), even if I restrict it to a single page on the web, so I just
turned the banner back off >_<

-- 
Nicolás

Re: Gitlab Turn-off Issues

[Nicolás Alvarez]

El dom., 28 de jun. de 2020 a la(s) 16:47, Nate Graham (n...@kde.org) escribió:
>
> On 6/28/20 12:28 PM, Ben Cooksley wrote:
> > On Mon, Jun 29, 2020 at 4:28 AM Allen Winter  wrote:
> >>
> >> Can we remove the Issues feature on all invent projects?
> >> We're starting to see more and more people adding Issues.
> >>
> >> For KOrganizer, bshah replaced Issues with Bugzilla.
> >>
> >> I very much doubt we want or are ready to replace Bugzilla.
> >
> > As has been discussed *far too many times* already, we have NO
> > INTENTION to replace Bugzilla at this stage.
> > This matter has been discussed on many threads, including on this list
> > in the past.
> >
> > Issues on Gitlab is intended to be the replacement for Phabricator Tasks.
> > Disabling them would leave projects with no developer task management
> > functionality, which would be highly undesirable as they are heavily
> > used by a number of projects.
> >
> > Your request to disable them for all KDE projects is therefore declined.
>
> The problem with this approach is that users familiar with GitHub or
> GitLab in other projects will not stop submitting bug reports using
> GitLab issues as long as it's turned on in its current form

Hmm... Users familiar with GitHub in other projects will not stop
submitting pull requests on the KDE GitHub mirror as long as that's
turned on, and GitHub doesn't even let us turn off pull requests.
Should we get rid of the GitHub mirror? Or should we keep closing pull
requests and telling people to send their patches to Invent instead?
(This is only half-rhetoric, I actually wouldn't mind getting rid of
the GitHub mirror :P)

> However the issue (har har) of users submitting bug reports and feature
> requests using GitLab issues is not likely to disappear without some
> kind of change.

We can't easily change the label of the sidebar button. But what about
a banner like this:
https://invent.kde.org/games/kbounce/-/issues/new

Do you think this would help?

--
Nicolás

Re: Winding down Phabricator

[Nicolás Alvarez]

Phabricator will stay running for now since there are many pending tasks and 
reviews on it. We also need to archive reviews for read-only access before we 
shut it down, which will take some time.

- You can continue using Phabricator tasks.

- Phabricator code reviews still work, but we *really* want people to use 
GitLab merge requests instead for new reviews. We may disable creation of new 
Phabricator reviews in the future.

- Automatic closing of tasks and reviews based on commit messages (like "Fixes 
T1234") doesn't work anymore, so you will have to close them manually.

-- 
Nicolas

> On 21 Jun 2020, at 13:21, L. E. Segovia  wrote:
> 
> Hi Ben,
> 
> We GSoC students (at least in the Krita project) have been requested to keep 
> track of our progress via Phabricator tasks. Must we manually link to changes 
> now?
> 
>> On 21/06/2020 03:38, Ben Cooksley wrote:
>> Hi all,
>> With the completion of Phase 1 of our move to Gitlab, all code review
>> activity should now be taking place on Gitlab, with only residual
>> reviews being cleaned out of Phabricator (which hopefully we're
>> already well underway with - please start this if you haven't already)
>> This leaves just Tasks left on Phabricator.
>> As interacting with repositories isn't a core requirement for this
>> functionality, we've now taken the step of disabling all repository
>> functionality on Phabricator.
>> This means that going forward, repositories will no longer be
>> browsable on Phabricator, nor will commit information be visible on
>> Phabricator. Additionally, actions normally taken via hooks (such as
>> "Differential Revision" and "Fixes Txxx") will no longer work.
>> Should anyone have any questions regarding this, please let us know.
>> Thanks,
>> Ben Cooksley
>> KDE Sysadmin
> 
> Best regards,
> 
> amyspark
> -- 
> amyspark  https://www.amyspark.me

Re: Discontinuing legacy infrastructure

[Nicolás Alvarez]

I have fixed this, for Krita alone.

I would need to write an automation script to fix it for all repos...

-- 
Nicolás

El lun., 15 de jun. de 2020 a la(s) 16:37, L. E. Segovia
(a...@amyspark.me) escribió:
>
> Hi Ben, hi everyone,
>
> I'm writing to let you know that since June 10 the Phabricator copy of
> Krita's repository is broken.
>
> The initialization log from the Manage repository page says:
>
>  > Pull of 'krita' failed: Command failed with error #128! COMMAND git
> ls-remote '' STDOUT (empty) STDERR fatal: remote error: Please
> use the https: protocol to connect to anongit
>
> so I think this change may have to do with it.
>
> I hope it can be solved soon, as I'm developing my GSoC project and
> cannot bind recent commits to the finished tasks.
>
> cc to the Krita mailing list to let them know as well.
>
> Best regards,
> amyspark
>
> On 11/06/2020 09:11, Ben Cooksley wrote:
> > Hi all,
> >
> > As previously announced by Sysadmin, following the Gitlab migration we
> > would be shutting down a number of services that were part of the old
> > Git infrastructure, as they were replaced with our new Gitlab based
> > infrastructure.
> >
> > This is a change which has now been actioned, and means the following:
> >
> > 1) git:// protocol support has now been discontinued
> >
> > Prior to the move to Gitlab, the anongit network offered access to our
> > repositories over both the git:// protocol as well as https://. This
> > has now been discontinued, and access is now provided solely via https
> > to ensure that connections cannot be intercepted and tampered with
> >
> > 2) CGit has been discontinued
> >
> > The CGit instance previously available at cgit.kde.org has now been
> > shutdown and is no longer available. All repository browsing should
> > now take place via Gitlab at https://invent.kde.org/
> >
> > 3) The anongit network in general has been discontinued
> >
> > Following the migration to Gitlab, all developers as well as automated
> > systems began to use the master server for their traffic exclusively.
> > Load monitoring since then has indicated that the system is fully
> > capable of handling this load without the assistance of any additional
> > systems.
> >
> > To avoid issues that have come up in the past (with people trying to
> > push to anongit, or systems being out of sync) it has been decided
> > that the anongit service is no longer providing benefit to us and as
> > such it has also been discontinued.
> >
> > A legacy compatibility redirector will continue to operate under the
> > hostname 'anongit.kde.org' for https urls and will redirect older
> > style urls to their replacement Gitlab equivalents.
> >
> > If anyone has any questions on the above, please let us know.
> >
> > Thanks,
> > Ben Cooksley
> > KDE Sysadmin
> >
> --
> amyspark https://www.amyspark.me

Re: Bridging #kde-devel on Freenode to Telegram

[Nicolás Alvarez]

El mié., 10 de jun. de 2020 a la(s) 20:16, Nicolás Alvarez
(nicolas.alva...@gmail.com) escribió:
>
> El mié., 10 de jun. de 2020 a la(s) 20:06, Carson Black
> (uhh...@gmail.com) escribió:
> >
> > Currently, #kde-devel is not set up with an IRC bridge to Telegram,
> > meaning users cannot access it from Telegram.
> >
> > Plugging it into our current bridge infrastructure would have the
> > following benefits:
> > - Telegram-only users (yes, those exist because neither IRC nor Matrix
> > are suitable for their needs and wants) don't have a room to discuss
> > KDE development stuff, and end up clogging other rooms with tangential
> > topics
> > - This lowers the barrier to entry for new contributors regarding
> > conversation both in terms of internet connections (IRC and Matrix
> > aren't very good regarding tolerance to bad internet for different
> > reasons) and in terms of user experience (IRC is ancient, Matrix is
> > often overwhelmed and laggy).
> > - Improving the coverage of the IRC bridge infrastructure allowing
> > contributors to freely choose what service they'd like to converse
> > with KDE with.
> >
> > If nobody has any objections to bridging #kde-devel to IRC, the bridge
> > bot will be set up to bridge https://t.me/kdedevel to #kde-devel.
>
> (Carson knows this but background for everyone else:)
>
> #kde-devel currently has an IRC ban on *@*/bot/*, which prevents any
> (properly identified) bots from joining, including our Telegram
> bridge. This block has been there since at least 2017 (probably *much*
> earlier, but that's the earliest I find in my IRC logs). I assume that
> ban is there for a reason, and I didn't want to remove it without some
> semblance of community agreement.
>
> Maybe someone remembers why bots are banned in #kde-devel?

Well, if there are no objections, I will remove the bot ban in
#kde-devel and set up the bridge tomorrow.

-- 
Nicolás

Re: Discontinuing legacy infrastructure

[Nicolás Alvarez]

El jue., 11 de jun. de 2020 a la(s) 19:31, David Hurka
(david.hu...@mailbox.org) escribió:
> I noticed that Reviewboard has been shut down. How much time will we have to
> migrate my junk from Phabricator?

Reviewboard was shut down last year...

> Personally I don’t like homepage redirects, but better than nothing. Of course
> it would be nice to let GitLab search for a commit hash. Doesn’t appear to be
> possible, right? Redirect to a page that describes how to search for commits?

Did cgit have a UI to paste a hash and search it? Or do you mean for
existing cgit URLs in the wild that link to commit hashes?

-- 
Nicolás

Re: Bridging #kde-devel on Freenode to Telegram

[Nicolás Alvarez]

El mié., 10 de jun. de 2020 a la(s) 20:06, Carson Black
(uhh...@gmail.com) escribió:
>
> Currently, #kde-devel is not set up with an IRC bridge to Telegram,
> meaning users cannot access it from Telegram.
>
> Plugging it into our current bridge infrastructure would have the
> following benefits:
> - Telegram-only users (yes, those exist because neither IRC nor Matrix
> are suitable for their needs and wants) don't have a room to discuss
> KDE development stuff, and end up clogging other rooms with tangential
> topics
> - This lowers the barrier to entry for new contributors regarding
> conversation both in terms of internet connections (IRC and Matrix
> aren't very good regarding tolerance to bad internet for different
> reasons) and in terms of user experience (IRC is ancient, Matrix is
> often overwhelmed and laggy).
> - Improving the coverage of the IRC bridge infrastructure allowing
> contributors to freely choose what service they'd like to converse
> with KDE with.
>
> If nobody has any objections to bridging #kde-devel to IRC, the bridge
> bot will be set up to bridge https://t.me/kdedevel to #kde-devel.

(Carson knows this but background for everyone else:)

#kde-devel currently has an IRC ban on *@*/bot/*, which prevents any
(properly identified) bots from joining, including our Telegram
bridge. This block has been there since at least 2017 (probably *much*
earlier, but that's the earliest I find in my IRC logs). I assume that
ban is there for a reason, and I didn't want to remove it without some
semblance of community agreement.

Maybe someone remembers why bots are banned in #kde-devel?

--
Nicolás

Re: Context information needed for isolated words

[Nicolás Alvarez]

>>> On 2 May 2020, at 08:12, Johan Ouwerkerk  wrote:
>> On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra  wrote:
>> Hi,
>> There is a widespread problem across many text strings to be translated: 
>> some isolated words are gender invariable in English, but not in many 
>> languages.
>> For example, let's consider this case of a cascade menu:
>> New
>>  Folder
>>  File
> 
> What prevents you from arbitrarily re-naming a particular top level
> entry? E.g. if you see "New", why not translate it as though it were
> "Create" if that makes your translation work more naturally?
> 
> I understand you'd want to stick as close as possible to the upstream
> default, but languages being languages no doubt someone will point out
> that verbs, too, could be conjugated differently depending on the
> object. Or aspect, time, mood, actor, tense, whether or not it is
> reflexive, medium, or otherwise. It could be that the verb might
> change completely: i.e that creating a new folder somehow requires a
> different translation of "create" than creating a new file would.
> Which might mean that "New > File" is much more appropriate as a
> starting point for *those* languages, because it avoids all the
> verb-related pitfalls.
> 
> English cares very little for any of that, so trying to account for it
> in English might only serve to render it clumsy and awkward.
> Conversely there are features which English is very particular about
> like articles which many other languages don't bother with at all.
> 
> All in all I think it is just easier if translation teams took some
> liberties to get the point across rather than hoping for English to
> become more like their native language. In particular this avoids most
> of the need for complicated rules about "what words to use when".

New is an adjective, if you translate it as a verb, in most places it will make 
no sense.

Suppose the string "New" is used in these two situations:

New
  File
  Folder

Messages received:
- Information regarding GitLab migration
- Context information needed for isolated words [New]

In the first case it's the action to create a new thing (file or folder), in 
the second case it indicates the second message is new. In some languages you 
may get away with using the same word, in some maybe not. "Nuevo" in Spanish 
makes sense in both cases, except that (as Eloy said) "Nuevo Carpeta" (new 
folder) has a gender mismatch.

But I don't think there is *any* language where you can translate "New" as the 
verb "Create" and have that work in both cases.

- Context information needed for isolated words [Create] ??

That's why the code needs to use i18nc, so that the two cases can be translated 
differently.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration

[Nicolás Alvarez]

> On 1 May 2020, at 15:17, Alexander Potashev  wrote:
> 
> On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
>> Use case 4 : Tom is a student in Germany and is interested in
>> contributing to wikitolearn, and he asks where can I find code of the
>> wikitolearn?
> 
> Hi,
> 
> I have a similar use case. Sometimes I need to share a URL to a
> project. For this purpose I used to share e.g.
> https://cgit.kde.org/releaseme.git/about
> 
> Does this migration make such permalinks impossible?
> 
> 
> From what I see, we lose permalinks because
> 1. cgit.kde.org will be discontinued
> 2. A once valid URL https://invent.kde.org/games/knetwalk may become
> unavailable if the project moves to another group, for example
> https://invent.kde.org/unmaintained/knetwalk

As I understand it, games/knetwalk will become a redirect to 
unmaintained/knetwalk, so the old link will still work. This is handled by 
GitLab automatically. Even on gitlab.com, if you rename a repository on your 
personal account or transfer it to another group or user, the old name will 
forward to the new one.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration

[Nicolás Alvarez]

> On 1 May 2020, at 15:17, Alexander Potashev  wrote:
> 
> On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
>> Use case 4 : Tom is a student in Germany and is interested in
>> contributing to wikitolearn, and he asks where can I find code of the
>> wikitolearn?
> 
> Hi,
> 
> I have a similar use case. Sometimes I need to share a URL to a
> project. For this purpose I used to share e.g.
> https://cgit.kde.org/releaseme.git/about
> 
> Does this migration make such permalinks impossible?
> 
> 
> From what I see, we lose permalinks because
> 1. cgit.kde.org will be discontinued
> 2. A once valid URL https://invent.kde.org/games/knetwalk may become
> unavailable if the project moves to another group, for example
> https://invent.kde.org/unmaintained/knetwalk

As I understand it, games/knetwalk will become a redirect to 
unmaintained/knetwalk, so the old link will still work. This is handled by 
GitLab automatically. Even on gitlab.com, if you rename a repository on your 
personal account or transfer it to another group or user, the old name will 
forward to the new one.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration

[Nicolás Alvarez]

> On 1 May 2020, at 15:17, Alexander Potashev  wrote:
> 
> On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
>> Use case 4 : Tom is a student in Germany and is interested in
>> contributing to wikitolearn, and he asks where can I find code of the
>> wikitolearn?
> 
> Hi,
> 
> I have a similar use case. Sometimes I need to share a URL to a
> project. For this purpose I used to share e.g.
> https://cgit.kde.org/releaseme.git/about
> 
> Does this migration make such permalinks impossible?
> 
> 
> From what I see, we lose permalinks because
> 1. cgit.kde.org will be discontinued
> 2. A once valid URL https://invent.kde.org/games/knetwalk may become
> unavailable if the project moves to another group, for example
> https://invent.kde.org/unmaintained/knetwalk

As I understand it, games/knetwalk will become a redirect to 
unmaintained/knetwalk, so the old link will still work. This is handled by 
GitLab automatically. Even on gitlab.com, if you rename a repository on your 
personal account or transfer it to another group or user, the old name will 
forward to the new one.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nicolás Alvarez]

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
(aa...@kde.org) escribió:
>
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > We have made a big fuss in the past about having different projects
> > > > that do the same thing and now we'll have that but also we'll have
> > > > several projects with the same name?
> > > > It really feels off to me and I wonder if this is related to the move to
> > > > gitlab.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> >
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> >
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> >
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> >
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
>
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?

Oh, your local path could be anywhere. It doesn't even need the same
name, you can put it in the same folder as the rest and call it
dial-thingy :)

This is about the server path (eg. the clone URL) looking redundant:
invent.kde.org/plasma-mobile/plasma-mobile-dialer.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nicolás Alvarez]

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
(aa...@kde.org) escribió:
>
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > We have made a big fuss in the past about having different projects
> > > > that do the same thing and now we'll have that but also we'll have
> > > > several projects with the same name?
> > > > It really feels off to me and I wonder if this is related to the move to
> > > > gitlab.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> >
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> >
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> >
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> >
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
>
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?

Oh, your local path could be anywhere. It doesn't even need the same
name, you can put it in the same folder as the rest and call it
dial-thingy :)

This is about the server path (eg. the clone URL) looking redundant:
invent.kde.org/plasma-mobile/plasma-mobile-dialer.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nicolás Alvarez]

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
(aa...@kde.org) escribió:
>
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > We have made a big fuss in the past about having different projects
> > > > that do the same thing and now we'll have that but also we'll have
> > > > several projects with the same name?
> > > > It really feels off to me and I wonder if this is related to the move to
> > > > gitlab.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> >
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> >
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> >
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> >
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
>
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?

Oh, your local path could be anywhere. It doesn't even need the same
name, you can put it in the same folder as the rest and call it
dial-thingy :)

This is about the server path (eg. the clone URL) looking redundant:
invent.kde.org/plasma-mobile/plasma-mobile-dialer.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration

[Nicolás Alvarez]

What repository website did it find? Phabricator, cgit, Invent, GitHub, or 
something else?

-- 
Nicolas

> El 28 abr. 2020, a la(s) 06:45, Ian Wadham  escribió:
> 
> Um, guys… Google is your friend...
> 
> I am a former KDE Games developer. I play KPatience quite a lot, as well as 
> other games to keep my brain active, especially during COVID-19 lockdown. 
> Recently I thought I could see where the answer lay to three bugs in the 
> solver(s), two in the Forty Eight variant and one, very recently reported, in 
> the Klondike variant. So I thought I would have a look at the source code to 
> see if my hypotheses might be correct and maybe work out a patch.
> 
> My first problem was to track down where the repos that I need are and how to 
> clone read-only copies. I didn’t even know what websites they are on any more 
> and KPatience is actually called kpat in the code (which I remembered). 
> However I can google “source code KDE KPatience” and the pat repository comes 
> up as the first hit, presumably because “KPatience” is used in the 
> repository’s description. Again “… card games” got the repo as hit 2 and “… 
> solitaire” (the American term for such games) got it as the first hit.
> 
> I have also found that several of the tricky cases mentioned earlier in this 
> thread can be resolved with Google search terms beginning “source code KDE 
> xxx”. For example, seeing xxx as “Plasma Mobile” get the repo as hit 2. And 
> just using “go” as xxx finds the Kigo repository as hit 3. Even a search with 
> xxx = “loderunner” finds the KGoldRunner repository as hit 1, even though 
> Loderunner is not mentioned in the repository’s description. I wonder how far 
> down repositories Google indexing goes. Even using xxx = “lode runner” (2 
> words), as suggested by Google, finds the KGoldrunner Handbook, though not 
> the repository. Still, a smart newbie might guess the name used for that type 
> of game in KDE and refine his source code search accordingly.
> 
> Even after I found the kpat repository, I could not understand where the 
> souce code was getting the card decks it uses. I knew from memory that they 
> are in some library somewhere, but there is no libkdecards. Googling with xxx 
> = something like “library cards” found the cards as a sub-directory of the 
> libkdegames repository.
> 
> So my suggestion is to keep whatever categories you like, including multiple 
> categories as required, as long as the category names are in plain English, 
> not KDE jargon. In addition, please continue to pepper repository 
> descriptions with search terms (words) that are easy for laymen and non-core 
> KDE developers to find.
> 
> Another possibility is to construct (automatically) a text-file “catalog” 
> with one line for each of the 1000+ repositories, containing (at least) the 
> repo name and description, but maybe other keywords. Then people could just 
> “grep” and “sort” it to find what they wanted. 
> 
> My 2 cents,
> Ian Wadham.
> 
>>> On 28 Apr 2020, at 2:46 pm, Bhushan Shah  wrote:
>> Hi Olivier,
>> On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote:
 Because in order to search for something, you need to know it exists.
 If you are just casually browsing, then the search can't help you.
>>> I don't think people casually browse our repos. What use case is more 
>>> likely to happen and do we want to support?
>> We don't really want to discard use-cases just because it does not suit
>> our workflow. That is not how we are going to gain new contributors, we
>> should value each contribution, be it drive-by contribution, or focused
>> contribution towards one single project.
>>> Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia 
>>> section. After carefully reading the code of two applications and three 
>>> libs he starts contributing to Elisa.
>>> Use case 2 : While using her Ubuntu installation of Elisa / while reading 
>>> on reddit about Elisa, Jerry decides to try to contribute to this 
>>> project/fix this bug that itches her and searches for it in KDE's forge.
>> Let me add a some more usecases, some of which I've been dealing with in
>> project I maintain.
>> Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma
>> Mobile applications source code
>> Use case 4 : Tom is a student in Germany and is interested in
>> contributing to wikitolearn, and he asks where can I find code of the
>> wikitolearn?
>> Suggestion offered by sysadmin team does not cater to one single
>> use-case, but offers a way to provide a solution to all 4 usecases. For
>> Plasma Mobile team or Wikitolearn team it would be much easier to refer
>> contributors to the https://invent.kde.org/plasma-mobile or
>> https://invent.kde.org/wikitolearn then tell them to go to
>> https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma
>> Mobile.
>>> On the other hand, I think the discussion about spotting open merge 
>>> requests (in a derived thread from this 

Re: Downtime for SVN - Action Required

[Nicolás Alvarez]

Translations are still in SVN, they have not moved to Git. We only
moved the SVN repository to a different server, and integrated SVN ssh
key management with the GitLab website.

-- 
Nicolás

El lun., 20 de abr. de 2020 a la(s) 19:56, Agron Selimaj
(as9902...@gmail.com) escribió:
>
> Guys I just need a little clarification for submitting translated file to the 
> gitlab repository.
>
> My first question is - is the migration over and can I submit translated 
> files?
>
> Second, with SVN all I did was commit (of course after compiling and other 
> tests). Now with Git, I fork + clone, translate and then send a merge 
> request? Right? Is there a guide for submitting po files?
>
> Third, I need a little git/kde geography. What path do I clone from, from 
> git? Is there an efficient path that concerns translations only or more 
> specifically albanian translations.
>
> Thanks,
> //Agron
>
>
>
>
> On Sat, Apr 18, 2020 at 6:36 AM Nicolás Alvarez  wrote:
>>
>> El dom., 12 de abr. de 2020 a la(s) 05:57, Ben Cooksley
>> (bcooks...@kde.org) escribió:
>> >
>> > Hi all,
>> >
>> > As you may be aware, KDE is currently undertaking a migration to Gitlab.
>> >
>> > As part of this, we also need to migrate our Subversion repository
>> > from the server it currently resides on to the new system that also
>> > hosts Gitlab. To simplify our systems we will also transition
>> > management of SSH keys to Gitlab when we do this.
>> >
>> > It is intended at this time that we perform the migration of the
>> > Subversion repository next weekend.
>> >
>> > We therefore need all holders of a Developer account, even if they
>> > only use our Subversion repository, to login to Gitlab and upload
>> > their SSH keys there.
>> >
>> > Our Gitlab instance can be found at https://invent.kde.org/ and you
>> > should be able to login there using your KDE Identity
>> > (identity.kde.org) details.
>> >
>> > Additionally, following this migration we will begin limiting access
>> > to the Subversion repository to those actively using it. The list of
>> > people whose access will be continued can be found at
>> > https://cgit.kde.org/repo-management.git/tree/svn-ssh-keys/users-list
>> >
>> > Should you still need access to the repository, but are not on the
>> > above list, please let us know by emailing sysad...@kde.org.
>> >
>> > If anyone has any questions on the above, please let us know.
>>
>> Hi all,
>>
>> I wanted to add that this server migration will also change the SSH
>> host keys for "svn.kde.org". After we switch servers, you will get the
>> nasty "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message from
>> ssh when you use SVN. To avoid this, you should add the new keys to
>> your ~/.ssh/known_hosts. You don't need to wait for the server switch,
>> you can add it now (keeping both old and new keys in the file) and it
>> will Just Work.
>>
>> I have added instructions for all these changes and the new ssh host
>> keys to the wiki:
>> https://community.kde.org/Infrastructure/Subversion/2020_Changes
>>
>> --
>> Nicolás
>> KDE Sysadmin Team

Re: Downtime for SVN - Action Required

[Nicolás Alvarez]

Translations are still in SVN, they have not moved to Git. We only
moved the SVN repository to a different server, and integrated SVN ssh
key management with the GitLab website.

-- 
Nicolás

El lun., 20 de abr. de 2020 a la(s) 19:56, Agron Selimaj
(as9902...@gmail.com) escribió:
>
> Guys I just need a little clarification for submitting translated file to the 
> gitlab repository.
>
> My first question is - is the migration over and can I submit translated 
> files?
>
> Second, with SVN all I did was commit (of course after compiling and other 
> tests). Now with Git, I fork + clone, translate and then send a merge 
> request? Right? Is there a guide for submitting po files?
>
> Third, I need a little git/kde geography. What path do I clone from, from 
> git? Is there an efficient path that concerns translations only or more 
> specifically albanian translations.
>
> Thanks,
> //Agron
>
>
>
>
> On Sat, Apr 18, 2020 at 6:36 AM Nicolás Alvarez  wrote:
>>
>> El dom., 12 de abr. de 2020 a la(s) 05:57, Ben Cooksley
>> (bcooks...@kde.org) escribió:
>> >
>> > Hi all,
>> >
>> > As you may be aware, KDE is currently undertaking a migration to Gitlab.
>> >
>> > As part of this, we also need to migrate our Subversion repository
>> > from the server it currently resides on to the new system that also
>> > hosts Gitlab. To simplify our systems we will also transition
>> > management of SSH keys to Gitlab when we do this.
>> >
>> > It is intended at this time that we perform the migration of the
>> > Subversion repository next weekend.
>> >
>> > We therefore need all holders of a Developer account, even if they
>> > only use our Subversion repository, to login to Gitlab and upload
>> > their SSH keys there.
>> >
>> > Our Gitlab instance can be found at https://invent.kde.org/ and you
>> > should be able to login there using your KDE Identity
>> > (identity.kde.org) details.
>> >
>> > Additionally, following this migration we will begin limiting access
>> > to the Subversion repository to those actively using it. The list of
>> > people whose access will be continued can be found at
>> > https://cgit.kde.org/repo-management.git/tree/svn-ssh-keys/users-list
>> >
>> > Should you still need access to the repository, but are not on the
>> > above list, please let us know by emailing sysad...@kde.org.
>> >
>> > If anyone has any questions on the above, please let us know.
>>
>> Hi all,
>>
>> I wanted to add that this server migration will also change the SSH
>> host keys for "svn.kde.org". After we switch servers, you will get the
>> nasty "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message from
>> ssh when you use SVN. To avoid this, you should add the new keys to
>> your ~/.ssh/known_hosts. You don't need to wait for the server switch,
>> you can add it now (keeping both old and new keys in the file) and it
>> will Just Work.
>>
>> I have added instructions for all these changes and the new ssh host
>> keys to the wiki:
>> https://community.kde.org/Infrastructure/Subversion/2020_Changes
>>
>> --
>> Nicolás
>> KDE Sysadmin Team

Re: Downtime for SVN - Action Required

[Nicolás Alvarez]

El dom., 12 de abr. de 2020 a la(s) 05:57, Ben Cooksley
(bcooks...@kde.org) escribió:
>
> Hi all,
>
> As you may be aware, KDE is currently undertaking a migration to Gitlab.
>
> As part of this, we also need to migrate our Subversion repository
> from the server it currently resides on to the new system that also
> hosts Gitlab. To simplify our systems we will also transition
> management of SSH keys to Gitlab when we do this.
>
> It is intended at this time that we perform the migration of the
> Subversion repository next weekend.
>
> We therefore need all holders of a Developer account, even if they
> only use our Subversion repository, to login to Gitlab and upload
> their SSH keys there.
>
> Our Gitlab instance can be found at https://invent.kde.org/ and you
> should be able to login there using your KDE Identity
> (identity.kde.org) details.
>
> Additionally, following this migration we will begin limiting access
> to the Subversion repository to those actively using it. The list of
> people whose access will be continued can be found at
> https://cgit.kde.org/repo-management.git/tree/svn-ssh-keys/users-list
>
> Should you still need access to the repository, but are not on the
> above list, please let us know by emailing sysad...@kde.org.
>
> If anyone has any questions on the above, please let us know.

Hi all,

I wanted to add that this server migration will also change the SSH
host keys for "svn.kde.org". After we switch servers, you will get the
nasty "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message from
ssh when you use SVN. To avoid this, you should add the new keys to
your ~/.ssh/known_hosts. You don't need to wait for the server switch,
you can add it now (keeping both old and new keys in the file) and it
will Just Work.

I have added instructions for all these changes and the new ssh host
keys to the wiki:
https://community.kde.org/Infrastructure/Subversion/2020_Changes

-- 
Nicolás
KDE Sysadmin Team

Re: Downtime for SVN - Action Required

[Nicolás Alvarez]

El dom., 12 de abr. de 2020 a la(s) 05:57, Ben Cooksley
(bcooks...@kde.org) escribió:
>
> Hi all,
>
> As you may be aware, KDE is currently undertaking a migration to Gitlab.
>
> As part of this, we also need to migrate our Subversion repository
> from the server it currently resides on to the new system that also
> hosts Gitlab. To simplify our systems we will also transition
> management of SSH keys to Gitlab when we do this.
>
> It is intended at this time that we perform the migration of the
> Subversion repository next weekend.
>
> We therefore need all holders of a Developer account, even if they
> only use our Subversion repository, to login to Gitlab and upload
> their SSH keys there.
>
> Our Gitlab instance can be found at https://invent.kde.org/ and you
> should be able to login there using your KDE Identity
> (identity.kde.org) details.
>
> Additionally, following this migration we will begin limiting access
> to the Subversion repository to those actively using it. The list of
> people whose access will be continued can be found at
> https://cgit.kde.org/repo-management.git/tree/svn-ssh-keys/users-list
>
> Should you still need access to the repository, but are not on the
> above list, please let us know by emailing sysad...@kde.org.
>
> If anyone has any questions on the above, please let us know.

Hi all,

I wanted to add that this server migration will also change the SSH
host keys for "svn.kde.org". After we switch servers, you will get the
nasty "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message from
ssh when you use SVN. To avoid this, you should add the new keys to
your ~/.ssh/known_hosts. You don't need to wait for the server switch,
you can add it now (keeping both old and new keys in the file) and it
will Just Work.

I have added instructions for all these changes and the new ssh host
keys to the wiki:
https://community.kde.org/Infrastructure/Subversion/2020_Changes

-- 
Nicolás
KDE Sysadmin Team

Re: Polish translation of "Cancel"

[Nicolás Alvarez]

El 15 abr. 2020, a la(s) 11:46, Nate Graham  escribió:
> 
> [+ kde-devel mailing list since I don't know if I got the right localization 
> mailing list and couldn't find a polish-specific one]
> 
> 
> Hello translators,
> I don't speak any Polish, but it's come to my attention that some native 
> Polish speakers are complaining about the Polish translation of the word 
> "Cancel", with no resolution on the issue: 
> https://bugs.kde.org/show_bug.cgi?id=404286
> 
> The bug has 150 votes and a lot of discussion. I think there's a fairly 
> strong argument in favor of consistency. Given that consistency was even 
> selected as an explicit KDE goal this year, my sense is that it would be good 
> to be consistent with the translation used by the wider software world, even 
> if it's maybe not perfect.

I started reading that bug report, then I realized how *incredibly long* it was 
and switched to fast skimming.

Is there a single person apart from NSLW who is in favor of Zaniechaj?

-- 
Nicolás

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El sáb., 11 de abr. de 2020 a la(s) 16:26, Johan Ouwerkerk
(jm.ouwerk...@gmail.com) escribió:
>
> On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
> >
> > Yes, the hostname git.kde.org will be fully retired as part of this 
> > transition.
> >
> > From my understanding kdesrc-build will automatically pick this up
> > once we update sysadmin/repo-metadata to show the new repository
> > paths.
> > This is something we'll confirm with mpyne though to ensure we can
> > make the cutover as smooth as possible.
> >
>
> Just to be clear, my understanding based on reading the
> `Updated/Git.pm` module is that KDE repo paths are abstracted via
> ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
> Currently the code manipulates the user's ~/.gitconfig to bind the
> correct mappings to the `kde:` prefix (this happens even before
> cloning sysadmin repos for metadata).
>
> So if my understanding of the code is correct, the entire switch over
> is transparent provided that kdesrc-build is updated beforehand to set
> the updated value for `pushInsteadOf`. We already have the same
> mechanism in place in kdesrc-build for ensuring that people use
> https://anongit.kde.org instead of git://anongit.kde.org when
> cloning/fetching.

Changing .gitconfig won't be enough, per-repo changes will still be
needed (although kdesrc-build could be updated to do those for you
too).

Currently if a project moves to gitlab, you need to change
g...@git.kde.org:kdenlive to g...@invent.kde.org:kde/kdenlive (note the
kde/ addition). If that was all, in principle you could use insteadOf
to map kde: to "g...@invent.kde.org:kde/". But depending on future
discussions about structure, it's possible that eg. kcoreaddons will
end up moving to frameworks/kcoreaddons rather than kde/kcoreaddons.

-- 
Nicolás

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El sáb., 11 de abr. de 2020 a la(s) 16:26, Johan Ouwerkerk
(jm.ouwerk...@gmail.com) escribió:
>
> On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
> >
> > Yes, the hostname git.kde.org will be fully retired as part of this 
> > transition.
> >
> > From my understanding kdesrc-build will automatically pick this up
> > once we update sysadmin/repo-metadata to show the new repository
> > paths.
> > This is something we'll confirm with mpyne though to ensure we can
> > make the cutover as smooth as possible.
> >
>
> Just to be clear, my understanding based on reading the
> `Updated/Git.pm` module is that KDE repo paths are abstracted via
> ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
> Currently the code manipulates the user's ~/.gitconfig to bind the
> correct mappings to the `kde:` prefix (this happens even before
> cloning sysadmin repos for metadata).
>
> So if my understanding of the code is correct, the entire switch over
> is transparent provided that kdesrc-build is updated beforehand to set
> the updated value for `pushInsteadOf`. We already have the same
> mechanism in place in kdesrc-build for ensuring that people use
> https://anongit.kde.org instead of git://anongit.kde.org when
> cloning/fetching.

Changing .gitconfig won't be enough, per-repo changes will still be
needed (although kdesrc-build could be updated to do those for you
too).

Currently if a project moves to gitlab, you need to change
g...@git.kde.org:kdenlive to g...@invent.kde.org:kde/kdenlive (note the
kde/ addition). If that was all, in principle you could use insteadOf
to map kde: to "g...@invent.kde.org:kde/". But depending on future
discussions about structure, it's possible that eg. kcoreaddons will
end up moving to frameworks/kcoreaddons rather than kde/kcoreaddons.

-- 
Nicolás

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El sáb., 11 de abr. de 2020 a la(s) 16:26, Johan Ouwerkerk
(jm.ouwerk...@gmail.com) escribió:
>
> On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
> >
> > Yes, the hostname git.kde.org will be fully retired as part of this 
> > transition.
> >
> > From my understanding kdesrc-build will automatically pick this up
> > once we update sysadmin/repo-metadata to show the new repository
> > paths.
> > This is something we'll confirm with mpyne though to ensure we can
> > make the cutover as smooth as possible.
> >
>
> Just to be clear, my understanding based on reading the
> `Updated/Git.pm` module is that KDE repo paths are abstracted via
> ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
> Currently the code manipulates the user's ~/.gitconfig to bind the
> correct mappings to the `kde:` prefix (this happens even before
> cloning sysadmin repos for metadata).
>
> So if my understanding of the code is correct, the entire switch over
> is transparent provided that kdesrc-build is updated beforehand to set
> the updated value for `pushInsteadOf`. We already have the same
> mechanism in place in kdesrc-build for ensuring that people use
> https://anongit.kde.org instead of git://anongit.kde.org when
> cloning/fetching.

Changing .gitconfig won't be enough, per-repo changes will still be
needed (although kdesrc-build could be updated to do those for you
too).

Currently if a project moves to gitlab, you need to change
g...@git.kde.org:kdenlive to g...@invent.kde.org:kde/kdenlive (note the
kde/ addition). If that was all, in principle you could use insteadOf
to map kde: to "g...@invent.kde.org:kde/". But depending on future
discussions about structure, it's possible that eg. kcoreaddons will
end up moving to frameworks/kcoreaddons rather than kde/kcoreaddons.

-- 
Nicolás

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El 11 abr. 2020, a la(s) 08:31, Johan Ouwerkerk  
escribió:
> 
> On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>> Should anyone have any questions on the above, please let us know.
> 
> Does the migration also mean that `git.kde.org` push URL will be
> retired and would need to be remapped to `invent.kde.org`?
> 
> In that case, it would be good to have a grace period after the
> initial migration to Gitlab so kdesrc-build (etc.) could be updated
> before the cut off date to perform this migration automatically for
> the user. I expect such a grace period would not need to last very
> long because the feature would be trivial to implement.

How would it work during the "grace period"? Keeping an outdated read-only 
mirror on the old URL? I have done some research into redirecting or remapping 
from the old URL to the new one so we can keep it working for a longer period 
of time, and it's harder than it seems... It can be done but I need to be 
convinced that it's actually necessary / worth the effort.

-- 
Nicolás
KDE Sysadmin Team

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El 11 abr. 2020, a la(s) 08:31, Johan Ouwerkerk  
escribió:
> 
> On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>> Should anyone have any questions on the above, please let us know.
> 
> Does the migration also mean that `git.kde.org` push URL will be
> retired and would need to be remapped to `invent.kde.org`?
> 
> In that case, it would be good to have a grace period after the
> initial migration to Gitlab so kdesrc-build (etc.) could be updated
> before the cut off date to perform this migration automatically for
> the user. I expect such a grace period would not need to last very
> long because the feature would be trivial to implement.

How would it work during the "grace period"? Keeping an outdated read-only 
mirror on the old URL? I have done some research into redirecting or remapping 
from the old URL to the new one so we can keep it working for a longer period 
of time, and it's harder than it seems... It can be done but I need to be 
convinced that it's actually necessary / worth the effort.

-- 
Nicolás
KDE Sysadmin Team

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El 11 abr. 2020, a la(s) 08:31, Johan Ouwerkerk  
escribió:
> 
> On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>> Should anyone have any questions on the above, please let us know.
> 
> Does the migration also mean that `git.kde.org` push URL will be
> retired and would need to be remapped to `invent.kde.org`?
> 
> In that case, it would be good to have a grace period after the
> initial migration to Gitlab so kdesrc-build (etc.) could be updated
> before the cut off date to perform this migration automatically for
> the user. I expect such a grace period would not need to last very
> long because the feature would be trivial to implement.

How would it work during the "grace period"? Keeping an outdated read-only 
mirror on the old URL? I have done some research into redirecting or remapping 
from the old URL to the new one so we can keep it working for a longer period 
of time, and it's harder than it seems... It can be done but I need to be 
convinced that it's actually necessary / worth the effort.

-- 
Nicolás
KDE Sysadmin Team

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Nicolás Alvarez]

El sáb., 21 de mar. de 2020 a la(s) 20:00, Johan Ouwerkerk
(jm.ouwerk...@gmail.com) escribió:
> Out of interest, apart from the amount of work it might take what
> would be the main blocker for using VMs and things like Vagrant boxes
> for FreeBSD as the next best thing to containers? I'd ask the same for
> Windows, but I imagine the answer is licensing costs.

We already use VMs for that. We obviously can't run a FreeBSD or
Windows in a container in a Linux host.

-- 
Nicolás

Re: Banning QNetworkAccessManager

[Nicolás Alvarez]

El jue., 20 de feb. de 2020 a la(s) 10:30, Allen Winter
(win...@kde.org) escribió:
>
> On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> > El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> > escriure:
> > > Additionally, improved documentation, a possible KNAM and/or driving the 
> > > QNAM
> > > changes upstream can still be done alongside this obviously.
> >
> > Also for Qt5 which will probably never be changed a clazy warning and 
> > making it easy to run clazy on gitlab CI would be great.
> >
>
> Krazy has a checker for QNetworkAccessManager use in Qt4 code.
> I could add a checker for Qt5 code if someone tells me what to look for
> (not that many people look at krazy reports. couldn't hurt. might help.

I started making a checker for this based on clang-static-analyzer.
Looks like clazy uses a different approach altogether by looking at
ASTs alone, so I don't think I can integrate into that...

-- 
Nicolás

Re: Banning QNetworkAccessManager

[Nicolás Alvarez]

El jue., 20 de feb. de 2020 a la(s) 10:30, Allen Winter
(win...@kde.org) escribió:
>
> On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> > El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> > escriure:
> > > Additionally, improved documentation, a possible KNAM and/or driving the 
> > > QNAM
> > > changes upstream can still be done alongside this obviously.
> >
> > Also for Qt5 which will probably never be changed a clazy warning and 
> > making it easy to run clazy on gitlab CI would be great.
> >
>
> Krazy has a checker for QNetworkAccessManager use in Qt4 code.
> I could add a checker for Qt5 code if someone tells me what to look for
> (not that many people look at krazy reports. couldn't hurt. might help.

I started making a checker for this based on clang-static-analyzer.
Looks like clazy uses a different approach altogether by looking at
ASTs alone, so I don't think I can integrate into that...

-- 
Nicolás

Re: Banning QNetworkAccessManager

[Nicolás Alvarez]

El jue., 20 de feb. de 2020 a la(s) 10:30, Allen Winter
(win...@kde.org) escribió:
>
> On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> > El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> > escriure:
> > > Additionally, improved documentation, a possible KNAM and/or driving the 
> > > QNAM
> > > changes upstream can still be done alongside this obviously.
> >
> > Also for Qt5 which will probably never be changed a clazy warning and 
> > making it easy to run clazy on gitlab CI would be great.
> >
>
> Krazy has a checker for QNetworkAccessManager use in Qt4 code.
> I could add a checker for Qt5 code if someone tells me what to look for
> (not that many people look at krazy reports. couldn't hurt. might help.

I started making a checker for this based on clang-static-analyzer.
Looks like clazy uses a different approach altogether by looking at
ASTs alone, so I don't think I can integrate into that...

-- 
Nicolás

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Nicolás Alvarez]

El sáb., 9 de nov. de 2019 a la(s) 19:48, Friedrich W. H. Kossebau
(kosse...@kde.org) escribió:
> FWIW, everytime I had to deal with translations as developer (like checking
> pot files as well as .po files contents) I found having the web interface and
> its browsing feature very valuable to quickly find what I was looking for,
> over having to locally mess around with svn commands and juggling between
> commandline & file viewers. Including url bookmarks for quick access to
> browsing certain sets of files.
>
> Incidents which I remember right now included:
> * finding out whether extraction scripts were working as intended
> * comparing translations seen by users over what they should see
>
> Are there any other KDE clients of the svn repos still around, besides
> translation system?
> Perhaps the "full clone" needed for WebSVN could be reduced to the translation
> subtrees, would that improve situation to a degree if possible? (well, you
> surely thought of this yourself, just in case)

This is unfortunately not possible. WebSVN needs a full copy of the
repository with its history, not a svn checkout, and that can't be
trimmed to a subtree. Or maybe you *can* extract a subtree, but then
you can't keep that in sync with new changes that appear in the master
repository. Even in git that's a giant pain.

-- 
Nicolás

Re: Commitfilter

[Nicolás Alvarez]

El lun., 3 de dic. de 2018 a la(s) 17:47, Christian David
(christian-da...@web.de) escribió:
>
> Hello,
>
> I still receive commit messages from commitfilter. How can I cancel that since
> https://commitfilter.kde.org does not work anymore.
>
> Best
> Christian

Hi Christian,

There is no self-serve way to do it anymore. I'll remove you manually,
sorry for the inconvenience.

-- 
Nicolás
KDE Sysadmin Team

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

[Nicolás Alvarez]

El 9 abr. 2018, a la(s) 15:35, Elvis Angelaccio  
escribió:

> On lunedì 9 aprile 2018 20:01:03 CEST, Nate Graham wrote:
>> Howdy folks,
> 
> Hi Nate,
> 
>> 
>> 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
> 
> Yes, since we stopped releasing kdelibs last November.
> 
>> add some more components to frameworks-kio, consolidate everything there
> 
> 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.

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.

-- 
Nicolás

Bad merge on dolphin.git rolled back

[Nicolás Alvarez]

FYI, someone accidentally merged master into stable in dolphin.git:
https://phabricator.kde.org/T8127

I rolled back Applications/17.12 to a618383df3. It's now missing:
- All the master commits that shouldn't have been there
- "Add icons to Edit menu" (D10503) which was probably targeted for
master only, but could be cherry-picked to 17.12 if that was the
intention
- a scripty change to a .desktop file, which I guess it will do again tomorrow

As usual, this may cause some disruption to people's local clones.
We've had to do this kind of git rewind more than once, but usually we
notice in hours. In this case the mistake was done 2 weeks ago and we
never noticed until now, so I guess more local clones will be
affected.

If you had any change pending push to dolphin 17.12 you'll have to rebase it.

(I feel like I had something else to mention but I'm too tired to remember)

-- 
Nicolás
KDE Sysadmin Team

Re: Code in peace or How to lint a complete repository?

[Nicolás Alvarez]

El 1 mar. 2018, a la(s) 15:04, Michael Heidelbach  escribió:

> On 28.02.2018 22:41, Elvis Angelaccio wrote:
> This may be right, but it looks weird to me:
> 
> -QMap positionDb;
> +QMap positionDb;
> 
In C++98 the ">>" is invalid, you need the space in "> >" for correct parsing. 
In C++11 this is handled correctly without needing a space. I think we require 
C++11 everywhere nowadays; I would remove the space.

-- 
Nicolás

Re: Code in peace or How to lint a complete repository?

[Nicolás Alvarez]

2018-02-28 6:57 GMT-03:00 Michael Heidelbach :
> Hi!
>
> Now that I saw https://phabricator.kde.org/D10905, I want to do something
> similar for baloo and baloo-widgets.
>
> I'd really like to that once and for all. Because applying coding style
> on-the-fly obscures real changes introduced.
>
> 1. Would it be reasonable?
> 2. Who would be willing to review such a huge diff?
> 3. How to apply KDE coding style most effectively?
>
>  (The astyle command given in Kdelibs Coding Style does not produce
> completely correct results:
> [this](const QUrl )  => [this](const QUrl & url)   instead of
> [this](const QUrl& url)
> Also the operators-at-beginning-of-line rule is not respected )
>
> 4. What about arcanist: any ready-made .arclint available?
>
> Cheers,
>
> Michael

Just one suggestion: Provide the settings and version number of the
tool you used, both in the review and in the commit message, so that
other people can reproduce the exact same result.

-- 
Nicolás

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

[Nicolás Alvarez]

2018-02-05 23:52 GMT-03:00 Nicolás Alvarez <nicolas.alva...@gmail.com>:
> 2018-02-05 23:46 GMT-03:00 Nate Graham <pointedst...@zoho.com>:
>> Any chance of resuscitation?
>>
>> Nate
>>
>
> Update taking longer than we expected, stay tuned :)

And we are back!

-- 
Nicolás
KDE Sysadmin Team

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

[Nicolás Alvarez]

2018-02-05 23:46 GMT-03:00 Nate Graham :
> Any chance of resuscitation?
>
> Nate
>

Update taking longer than we expected, stay tuned :)

-- 
Nicolás
KDE Sysadmin Team

Re: c++11 and workspace

[Nicolás Alvarez]

2017-08-17 17:15 GMT-03:00 Hugo Pereira Da Costa
:
>
>
> On 08/17/2017 10:09 PM, Thiago Macieira wrote:
>>
>> On Thursday, 17 August 2017 08:52:21 PDT Martin Flöser wrote:
>>>
>>> Am 2017-08-17 16:48, schrieb Hugo Pereira Da Costa:

 Hi,

 Quick question on the status of c++11 features that I can include in
 breeze. Are std::function allowed ?
>>>
>>> In workspace you can/should use C++11, KWin/master even requires C++14.
>>
>> Confirm if you mean the core language or the standard library.
>>
> As far as I am concerned, I was referring mostly to core language.
>

std::function is a standard library feature ;)

-- 
Nicolás

D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin

[Nicolás Alvarez]

nalvarez added a comment.


  Looks reasonable – although I wonder why on earth you're building KDE stuff 
on Cygwin...

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6762

To: winterz, skelly, #build_system, #windows
Cc: nalvarez, #frameworks, #build_system

D5788: Add syntax highlighting for YANG data modeling language

[Nicolás Alvarez]

nalvarez added a comment.


  I knew the text of RFCs was under a somewhat-restrictive license. I didn't 
know code snippets were explicitly excluded and BSD'd instead. We can work with 
that then :)

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5788

To: nalvarez, #kate, jkt, dhaumann
Cc: dhaumann, jkt, #frameworks

D5788: Add syntax highlighting for YANG data modeling language

[Nicolás Alvarez]

nalvarez added a comment.


  Sorry, I don't know enough about the language to provide a meaningful test. I 
made these highlighting rules on request by @jkt, partly translating the .vim 
file and partly reading the RFC, without even understanding what the language 
is for. I was hoping he could provide a test file, but he didn't reply to my 
highlight here or to my email...
  
  Should I commit anyway, without the test?

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5788

To: nalvarez, #kate, jkt, dhaumann
Cc: dhaumann, jkt, #frameworks

Re: Moving AtCore to Extragear

[Nicolás Alvarez]

Note that changing from GPL2 to GPL2-or-later needs agreement from all
the authors / copyright holders.

-- 
Nicolás

2017-05-26 7:34 GMT-03:00 Jonathan Riddell :
> LICENSE file is normally named COPYING in KDE repos
> More importantly the files are GPL 2 only, which isn't allowed in
> KDE's licence policy.  It should be changed to GPL 2 or later (or as
> approved by e.v.) https://community.kde.org/Policies/Licensing_Policy
> LICENSE and README.md both say it uses LGPL, which isn't the case,
> this should be made consistent.
> http://techbase.kde.org/Policies/Kdelibs_Coding_Style links are out of
> date in scripts/*
>
> Jonathan
>
>
>
>
> On 23 May 2017 at 14:17, Lays Rodrigues  wrote:
>> Good morning everyone,
>> For you that don't know me, I'm Lays Rodrigues, and I work with 3 more
>> guys(Patrick, Chris, Tomaz) on Atelier.
>> Atelier is a software for 3DPrinting that we are building inside KDE. So far
>> we have 10 months of work, and we are ready for the launch of our core, in
>> this case, is AtCore.
>> AtCore is the API responsible for all serial communication, and for
>> validating more of our work, we would like to launch the 0.1 version with
>> the next KDE Applications release.
>> I was told that Extragear applications don't need to follow KDE releases,
>> but we thought that would be better to follow the release schedule on the
>> first launches, so we can fix, for us, a deadline.
>> So for this first step, we want to move AtCore from the Playground to
>> Extragear, and launch it with its test client, where we can make the core
>> stronger, so when we launch Atelier, we know that everything will be stable.
>> Our targets are all Gnu/Linux distros, and we already have inside Craft a
>> port for Windows with packing configured and working.
>>
>> Well, so I would like to require this review and moving to Extragear.
>> This is my first KDE application, so I maybe kind of lost.
>>
>> P.s: You can find more info about the status of the project on my blog here.
>>
>> Thanks all,
>>
>> Ps.:2 I don't know if my first e-mail arrived, because I wasn't subscribed
>> to this mail list, if this is a duplicate, sorry.
>>

D5788: Add syntax highlighting for YANG data modeling language

[Nicolás Alvarez]

nalvarez created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  Add syntax highlighting for YANG data modeling language, based on yang.vim 
.
  
  Improvements from yang.vim:
  
  - Character escapes such as `\n` in `"foo\nbar"` are highlighted in a 
different color
  - `'foo\'bar'` is highlighted correctly (string ends at first `'` regardless 
of backslash). yang.vim wrongly interprets `\\` and `\'` as escapes in 
single-quoted strings.
  
  Regressions from yang.vim (which I may fix later):
  
  - Numbers don't have special highlighting and look like normal text.
  - "Dates" and "lengths" don't have special highlighting and look like normal 
strings.
  
  I also don't highlight identifiers starting with `xml` as an error (which 
yang.vim does), but it seems like that's a YANG 1.0 restriction that was 
removed in YANG 1.1.
  
  //Also// the XML code ended up unreadable with little whitespace. Hit me with 
that in code review.

TEST PLAN
  Manually tested with random samples copied from the RFC, comparing the result 
between Vim and KWrite. However those can't be used as test cases for licensing 
reasons. Perhaps @jkt can provide a usable test file?

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5788

AFFECTED FILES
  data/syntax/yang.xml

To: nalvarez, #kate, jkt
Cc: jkt, #frameworks

D5656: Adds method to force the reloading of a document

[Nicolás Alvarez]

nalvarez added a comment.


  I'm pretty sure this breaks ABI by adding a new virtual function... If an 
application was compiled against a previous version of KTextEditor and calls 
`documentSave()`, when run with a newer KTextEditor version (with this patch) 
it may end up calling the new `documentReload(ReloadDocument)`. With garbage in 
the first argument.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D5656

To: pedroarthurp, dfaure, brauch, dhaumann, cullmann
Cc: nalvarez, kwrite-devel, #frameworks

D5405: Create desktop file name based on organization domain unless set explicitely

[Nicolás Alvarez]

nalvarez added a comment.


  Are you saying the d-bus service name should be equal to the .desktop 
filename? I don't see where this requirement comes from.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D5405

To: stikonas, mpyne, kossebau, aacid, ltoscano
Cc: nalvarez, graesslin, mak, plasma-devel, kde-frameworks-devel, #frameworks, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol

D4234: Change algorithm for autobrace.

[Nicolás Alvarez]

nalvarez added a comment.


  Writing tests for this might not be easy, so even having passing tests for 
the current behavior would be very useful, as a first step.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D4234

To: cactus, #ktexteditor, mwolff
Cc: nalvarez, mwolff, anthonyfieroni, dhaumann, brauch, cullmann, kwrite-devel, 
#frameworks

Re: Review Request 119170: Include ntdd* headers to make Solid build without the Windows DDK

[Nicolás Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119170/
---

(Updated Feb. 25, 2017, 9:27 p.m.)


Status
--

This change has been discarded.


Review request for kdewin and Solid.


Repository: solid


Description
---

The `ntdd*.h` headers used in the Windows backend come with MSVC2013 and MinGW, 
but not with MSVC2010, you have to download and install the DDK separately, or 
grab the headers from MinGW or kdewin. I don't know if MSVC2012 has them or not.

I added the headers to Solid, in a subdirectory. There is a CMake check using 
`check_cxx_source_compiles` to see if the headers are present in the system. 
The bundled headers are only added to the include search paths if they aren't 
already found in the system. This is more robust than checking the MSVC version 
number.


Diffs
-

  src/solid/devices/CMakeLists.txt 9271ae1 
  src/solid/devices/backends/win/kdewin/ntddcdrm.h PRE-CREATION 
  src/solid/devices/backends/win/kdewin/ntddmmc.h PRE-CREATION 
  src/solid/devices/backends/win/kdewin/ntddstor.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/119170/diff/


Testing
---

Builds on MSVC2010 (didn't before) and MSVC2013 (did before).


Thanks,

Nicolás Alvarez

[Differential] [Commented On] D3850: Pass -fno-operator-names when supported

[Nicolás Alvarez]

nalvarez added a comment.


  This might be better solved by a krazy-like check, instead of making the 
compilation fail...

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3850

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kfunk, #frameworks, #build_system, ivan
Cc: nalvarez, thomasp, rakuco, elvisangelaccio

Re: Suggestion to Remove KFloppy and hold back K3b

[Nicolás Alvarez]

> On Feb 15, 2017, at 17:58, Wolfgang Bauer  wrote:
> 
> Am Mittwoch, 15. Februar 2017, 22:21:19 schrieb Martin Gräßlin:
>> Please do not consider starting a GUI application as root a possibility.
> 
> Ok, but partitionmanager does exactly that. It restarts itself as root if run 
> as user.
> So that instantly would rule out partionmanager as a proposed replacement, I 
> suppose.
> 
> But KFloppy is quite a simple application.
> There should not really be a special risk involved running it as root, but I 
> might be mistaken there.

Sounds like you're challenging Martin to write a take-over-machine exploit via 
root KFloppy, and I would bet money that he would succeed ;)

-- 
Nicolás

Re: CI trouble

[Nicolás Alvarez]

2017-02-04 16:19 GMT-03:00 David Faure :
> Today the CI seems capricious ;)
>
> - build.kde.org was down for a bit

Yep, Jenkins ran out of memory in the JVM. Restarted a while ago.

> - DNS problems in 
> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kparts%20master%20kf5-qt5/409/console

Bleh, no idea why this could be. I would have just triggered a
rebuild, but there is one queued already.

> - "QXcbConnection: Could not connect to display :99" problems in many cases 
> like 
> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kguiaddons%20master%20kf5-qt5/133/PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/kwordwraptest/

One possible reason is that Xvfb from a previous build didn't quit, or
quit but left a lock behind. However, Ben didn't find any stale locks
in either build node. Still investigating...

-- 
Nicolás

Re: Phabricator: All repositories registered - upcoming workflow changes

[Nicolás Alvarez]

2017-02-02 7:23 GMT-03:00 René J.V. Bertin :
> On Thursday February 2 2017 22:09:34 Ben Cooksley wrote:
>
>>For those who dismiss decay as an issue - problems with previous
>>Reviewboard upgrades not taking cleanly have resulted in some reviews
>>being damaged, causing their diffs to become unavailable. These sorts
>>of problems do happen.
>
> Yes, I bet they do, and I bet there are ways to prevent them from happening.
> Bitrot should not be an issue with the ready availability of ZFS (on Linux or 
> BSD, FreeNAS etc) and btrfs, and

You missed the point. This "bit rot" is not about disk damage but
about software incompatibility. ZFS doesn't help with that...

-- 
Nicolás

Re: CI Requirements - Lessons Not Learnt?

[Nicolás Alvarez]

> El 12 ene 2017, a las 14:54, Kevin Kofler  escribió:
> 
> Jan Kundrát wrote:
>> do you have some examples of distribution maintainers actually doing such
>> a stupid thing?
> 
> I've done it more than once. If the dependency that the latest upstream
> version wants is not available and will not be made available for whatever
> reason, reverting the dependency bump is really the only way. And the users
> will be no worse off than if we had stuck to the old version that did not
> have the changes I am reverting to begin with.

It is not true that users will be no worse off. An application could increase 
the dependency of libfoo to 1.3 and add code using a feature that was broken in 
1.2. If you then revert the version bump, you get code that uses the new 
feature but allows libfoo 1.2, where it's broken. Users are now worse off than 
if you had stuck to the old version.

-- 
Nicolás

Re: What's kde-core-devel for?

[Nicolás Alvarez]

> El 19 dic 2016, a las 06:24, Jan Kundrát  escribió:
> 
> KDE has expanded over the last few years to include projects which are not 
> based on kdelibs or kf5 (or even Qt). There are e-mails about new project 
> incubation, upcoming conferences and CFPs and other semi-social topics. I am 
> interested in these discussions and I thought that this is what k-c-d is for.

That could go to kde-community or kde-devel if k-c-d is removed. I would say 
kde-community fits better for those semi-social things.

-- 
Nicolás

Re: kconfig_compiler (Re: KDE Frameworks 5.29.0)

[Nicolás Alvarez]

> El 10 dic 2016, a las 17:10, David Faure  escribió:
> 
>> On samedi 10 décembre 2016 19:49:07 CET Martin Graesslin wrote:
>> So from my point of view breaking the incorrect behavior could be acceptable
>> here.
> 
> Yes, but after the next kdevplatform release, then, to avoid breaking 
> compilation of released code.
> 
> Is the kdevplatform bugfix getting into the final 16.12 release?
> If I read
> https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
> correctly, there's still time to sneak it in if needed, before Dec 15.

KDevPlatform and KDevelop are extragear ;)

The fix is already in the 5.0 branch, I guess we could release a v5.0.4 soon if 
needed.

-- 
Nicolás

[Differential] [Changed Subscribers] D3636: [kconfig_compiler] Improve documentation about Inherits

[Nicolás Alvarez]

nalvarez added inline comments.

INLINE COMMENTS

> README.dox:111
>Class the generated class inherits from. This class must inherit
> -  KConfigSkeleton.
> +  KConfigSkeleton and must provide an empty ctor, an ctor taking a QString 
> argument and a ctor taking
> +  a KSharedConfig::Ptr as argument.

an ctor -> a ctor.

Also, would it make sense to explain here what those arguments //are//, or is 
that explained later?

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D3636

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #frameworks, dfaure
Cc: nalvarez

Re: Discontinuing repository tarballs

[Nicolás Alvarez]

> El 23 nov 2016, a las 15:07, Albert Astals Cid  escribió:
> 
> El dimecres, 23 de novembre de 2016, a les 20:17:29 CET, Ben Cooksley va 
> escriure:
>> HI all,
>> 
>> As of late Sysadmin has been assessing what components of our
>> infrastructure are in active use and should be maintained going
>> forward.
>> 
>> As part of this it has come to our attention that the repository
>> tarballs offered by our anongit network (tar.gz files of our
>> repositories essentially) are effectively unused - with only 19 hits
>> being received by one mirror in the space of a week.
> 
> This is not about making the "git archive" command not work, right?
> 

No, this is about full-history tarballs. The idea is you can download the 
tarball over HTTP (which is even resumable if the download is interrupted), 
unpack it, and get the same as from a 'git clone'.

It's of questionable usefulness. If your Internet connection is so bad that you 
can't complete a normal 'git clone' in one go, you'll probably have other 
problems with our services anyway...

-- 
Nicolás

[Differential] [Commented On] D3091: Windows: Don't display error dialogs

[Nicolás Alvarez]

nalvarez added a comment.


  Meanwhile I'm skeptical of the need to "set it back". Is there any case where 
such error dialog boxes would be desirable? It seems like their existence is an 
ancient-app-compatibility thing. The documentation for `SetErrorMode` 
recommends setting `SEM_FAILCRITICALERRORS` at app startup and leaving it that 
way.

REVISION DETAIL
  https://phabricator.kde.org/D3091

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kfunk, #frameworks, brauch
Cc: nalvarez, broulik

Re: Review Request 127823: Allow building without strigi on Linux

[Nicolás Alvarez]

> On July 17, 2016, 6:26 p.m., Antonio Rojas wrote:
> > Ping... can someone with the appropriate powers approve and commit this? 
> > All strigi packages are being removed from KDE Applications 16.08, would be 
> > great to have the dependency removed here too for the matching kdelibs 
> > release.
> 
> Albert Astals Cid wrote:
> That's really a bad excuse, since what we're not shipping anymore is the 
> analizers, that have nothing to do with this code, and you can/should still 
> ship the analizers for your kdelibs4 users from the old version.
> 
> Antonio Rojas wrote:
> We are not going to ship unmaintained software which is unsupported 
> upstream. And once we drop the analyzers, this is the only thing that 
> prevents us from dropping strigi.

Isn't Qt4 unmaintained software which is unsupported upstream? Why are you 
still shipping it?


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127823/#review97507
---


On May 3, 2016, 9:06 a.m., Antonio Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127823/
> ---
> 
> (Updated May 3, 2016, 9:06 a.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Now that kde-workspace is obsolete and kdelibs is only used by some still 
> unported applications, it doesn't make sense to force using strigi anymore. 
> This will allow dropping this old unmaintained library from distributions.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e7b2bea 
> 
> Diff: https://git.reviewboard.kde.org/r/127823/diff/
> 
> 
> Testing
> ---
> 
> Builds with and without strigi, everything seems to work
> 
> 
> Thanks,
> 
> Antonio Rojas
> 
>

Re: Review Request 128160: Fix compilation with gcc6

[Nicolás Alvarez]

> On June 12, 2016, 3:31 p.m., Albert Astals Cid wrote:
> > the file contains only whitespace changes. Is that right?
> > 
> > Also i can't find that commit in solid.

Yes, that is right. `"foo"bar` is now interpreted as a C++11 user-defined 
string literal, and you need to add a space if you want it interpreted as 
`"foo"` compile-time concatenated with the expanded value of the macro `bar`.


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128160/#review96383
---


On June 12, 2016, 1:40 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128160/
> ---
> 
> (Updated June 12, 2016, 1:40 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This basically backports 3c38c2bba3dc2313fa95ff99c76aae3870e0a168
> from solid.
> 
> 
> Diffs
> -
> 
>   solid/solid/backends/shared/cpufeatures.cpp 
> baa1af21098d7c312d7a9176e216d9d0f8e3a7a6 
> 
> Diff: https://git.reviewboard.kde.org/r/128160/diff/
> 
> 
> Testing
> ---
> 
> Not enough to successfully compile with gcc-6, but at least one error less.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

Re: web server for appstream metadata screenshots

[Nicolás Alvarez]

2016-06-08 13:32 GMT-03:00 Yuri Chornoivan <yurc...@ukr.net>:
> написане Wed, 08 Jun 2016 19:27:23 +0300, Burkhard Lück
> <lu...@hube-lueck.de>:
>
>
>> Am Mittwoch, 8. Juni 2016, 12:45:13 CEST schrieb Nicolás Alvarez:
>>>
>>> 2016-06-08 8:33 GMT-03:00 Friedrich W. H. Kossebau <kosse...@kde.org>:
>>> >
>>> > Good idea, also when it comes to long-term availability of referenced
>>> > images>
>>> > :)
>>> >
>>> > It might make sense to reuse/share the screenshots with the ones used
>>> > for
>>> > the KDE app catalog we have at kde.org/applications/. For consistency
>>> > and
>>> > for efficiency.
>>> >
>>> > Not sure though what a stable url would be like, given people planning
>>> > to
>>> > rework kde.org (and thus those app catalog pages), so perhaps relying
>>> > on
>>> > the current screenshot urls used by kde.org/applications is not
>>> > perfect.
>>> The screenshots on kde.org/applications are stored in SVN and they are
>>> the main reason why I couldn't migrate that website to Git. I would
>>> prefer if you don't add even more there...
>>
>>
>> www/sites/www/screenshots (svn) has 176 pngs
>>
>> websites/edu-kde-org/ (git) has 1287 pngs
>>
>> master kf5 / doc[s] (git) folders have  2079 pngs
>>
>> master kde4 / doc[s] (git) folders have 1702 pngs
>>
>> I do not understand why the 176 pngs in www/sites/www/screenshots are a
>> problem for migration to git
>
>
> Hi,
>
> I might be wrong, but is the hotlinking to Phabricator/Git files
> (screenshots in this case) a good thing?

No, and we have warned people who do this, and even blocked requests
when they didn't remove the hotlinking.

But where are they being hotlinked here?

-- 
Nicolás

Re: web server for appstream metadata screenshots

[Nicolás Alvarez]

2016-06-08 12:50 GMT-03:00 Kai Uwe Broulik :
> Hi,
>
> I thought we agreed to keep artwork in SVN due to the penalty you get in Git 
> when storing large blobs.
>
> However given Breeze stuff is entirely in Git now, ...
>
> Cheers,
> Kai Uwe

Artwork, sure. But the screenshots and other large files are
preventing the website *code* from being moved to Git, because it's
all mixed together. And it's questionable whether such large files
should even be in SVN.

-- 
Nicolás

Re: web server for appstream metadata screenshots

[Nicolás Alvarez]

2016-06-08 8:33 GMT-03:00 Friedrich W. H. Kossebau :
> Am Mittwoch, 8. Juni 2016, 13:10:04 CEST schrieb Sebastian Kügler:
>> Hey,
>>
>> I've been adding appstream metadata to one of the apps I maintain, among
>> that are also screenshots, in the form of a URL. That means that I have to
>> put the screenshots on a webserver.
>>
>> Do we already have a canonical location for these screenshots? If not, let's
>> create one before we get people hosting them on imgur, their private
>> webserver or their router-behind-a-dsl-line. :)
>
> Good idea, also when it comes to long-term availability of referenced images
> :)
>
> It might make sense to reuse/share the screenshots with the ones used for the
> KDE app catalog we have at kde.org/applications/. For consistency and for
> efficiency.
>
> Not sure though what a stable url would be like, given people planning to
> rework kde.org (and thus those app catalog pages), so perhaps relying on the
> current screenshot urls used by kde.org/applications is not perfect.

The screenshots on kde.org/applications are stored in SVN and they are
the main reason why I couldn't migrate that website to Git. I would
prefer if you don't add even more there...

-- 
Nicolás

Re: Review Request 127972: Always update the Predicate parser from y/l sources

[Nicolás Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127972/#review95658
---


Ship it!




Not only I approve of this change, but I also wish it was done over all other 
KDE software using flex/bison.

- Nicolás Alvarez


On Mayo 20, 2016, 3:39 a.m., Pino Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127972/
> ---
> 
> (Updated Mayo 20, 2016, 3:39 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, kdewin, and 
> Lukáš Tinkl.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Turn Flex and Bison into required build dependencies, and use them to always 
> regenerate at build time the Predicate parser. This ensures that the parser 
> does not rot, and there is no more need to rely on autogenerated sources 
> added statically among the others.
> 
> Second commit: remove old generated files of Predicate parser
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 763e09cfeeebdc9e42b68e8ab6c9e29c54d3e741 
>   src/solid/CMakeLists.txt f2b43b27cb47531ed57b2eccafad8e67951b56b9 
>   src/solid/devices/CMakeLists.txt 9271ae1e36b67b112be54a6ff9c6fb76a8a0a824 
>   src/solid/devices/predicate_lexer.c 
> 3b5a0b90907baf1cd2631da4de650ec153d0f642 
>   src/solid/devices/predicate_parser.h 
> 68e25070d498f5a635489af51f4b772c5f374108 
>   src/solid/devices/predicate_parser.c 
> 6d35ff25f001a43cbfecacc11e7d7591bb4808f9 
> 
> Diff: https://git.reviewboard.kde.org/r/127972/diff/
> 
> 
> Testing
> ---
> 
> Builds fine with flex 2.6.0 and bison 3.0.4; `make test` passes too.
> 
> 
> Thanks,
> 
> Pino Toscano
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127122: [Kate] Back/Forward mouse buttons

[Nicolás Alvarez]

> On March 28, 2016, 5:22 p.m., Sven Brauch wrote:
> > Hmm. Do we really need code for that? Can't you simply assign those buttons 
> > to the forward / backward actions as shortcuts? Try setting them as 
> > alternate shortcuts by default.
> 
> Anthony Fieroni wrote:
> This code is needed. QKeySequence is about *only* for keyboard keys. 
> Mouse buttons *must* me handled by event, as far i know.
> 
> Sven Brauch wrote:
> Did you actually try that in the shortcut dialog? Please do. I don't have 
> a mouse with extra keys here right now ...
> 
> Kai Uwe Broulik wrote:
> Just tried, I cannot assign any mouse buttons to shortcuts, including 
> back/forward.
> 
> Anthony Fieroni wrote:
> Not only try, i saw the code in kxmlgui who set this shortcuts. It's used 
> QKeySequence who is keyboard specific. You can see the same code as this 
> patch in Dolphin for for/backward.
> 
> Sven Brauch wrote:
> Hmm, ok then. I'm undecided, let's wait for a few other opinions. On the 
> one hand, it sounds sensible, on the other hand I don't like hardcoded 
> shortcuts and the use case to switch documents with mouse is ... not a huge 
> one imo. Code looks ok.

My mouse has back/forward buttons (by tilting the scroll wheel sideways) and I 
find it super useful in a web browser. But if the buttons were supported in 
Kate, it's more likely I'd want to configure it for undo/redo rather than 
document switching.


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127122/#review94084
---


On March 28, 2016, 5:20 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127122/
> ---
> 
> (Updated March 28, 2016, 5:20 p.m.)
> 
> 
> Review request for Kate, KDE Frameworks, Christoph Cullmann, Dominik Haumann, 
> and Kåre Särs.
> 
> 
> Repository: kate
> 
> 
> Description
> ---
> 
> Show prev/next tab on mouse back/forward buttons
> 
> 
> Diffs
> -
> 
>   kate/katemainwindow.h ece0db8 
>   kate/katemainwindow.cpp f630e28 
> 
> Diff: https://git.reviewboard.kde.org/r/127122/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Product versions on bugs.kde.org

[Nicolás Alvarez]

2016-03-07 8:10 GMT-03:00 Jonathan Riddell :
> On Mon, Mar 07, 2016 at 09:25:40AM +0100, Kevin Funk wrote:
>> Is there a way to batch-modify those versions? Obviously noone wants to go
>> through the Bugzilla UI, adding versions one-by-one for each(!) framework.
>> /me found [1].
>>
>> PS: It's not just the case for frameworks, same applies to KDE Applications,
>> etc.
>>
>> Cheers,
>> Kevin
>>
>> [1] 
>> http://blog.asymptotic.co.uk/software-development-log/batch-modifying-bugzilla-milestones/
>>
>> --
>> Kevin Funk | kf...@kde.org | http://kfunk.org
>
>
> There's no API for this, I've no idea why not.

Just to confirm: There is indeed no API for this, not even in the new
Bugzilla 5.x which we don't have yet.

-- 
Nicolás

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

[Nicolás Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127169/#review92798
---


Ship it!




Looks like I totally misunderstood this change. It only changes the default if 
the project's `CMAKE_INSTALL_PREFIX` is the same as the prefix where Qt is 
installed, and in that case it does make sense to change the subpaths, since it 
won't put anything outside the given prefix. If Qt is in a different location 
(eg. self-built project in `~/local`, system Qt in `/usr`), nothing changes.

I was concerned because I have seen other projects always try to install stuff 
in eg. `/etc`, even if `CMAKE_INSTALL_PREFIX` is somewhere in `$HOME`, because 
some system daemon expects its config there. But that's not the case here :)

- Nicolás Alvarez


On Feb. 24, 2016, 2:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 2:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

[Nicolás Alvarez]

> On Feb. 24, 2016, 4:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.
> 
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining 
> about having to set this?
> 
> Also, I don't think I've seen enough specifics about the impact this has. 
> What moves where etc.
> 
> Aleix Pol Gonzalez wrote:
> 99% of our users use a setting that we don't enable by default? It's 
> definitely something to take into account.
> 
> In fact, if the creator of a system decided that Qt plugins go to 
> /usr/heaven/plugins, I don't really see why we should override the decision 
> and ask the user to configure each project specifically. I understand this 
> wouldn't make sense if they weren't sharing a prefix, as it's a complete 
> different thing.
> 
> An example is my installation. Qt decided to put the plugins in 
> `$prefix/lib/plugins`, cmake/ecm decides to put them in 
> `$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.
> 
> Stephen Kelly wrote:
> Sorry, just so I understand - The '99%' is referring to packagers 
> creating distro packages? 
> 
> Do we want to make 'create a distro package' the primary/default case in 
> kde buildsystems? Genuine question. Otherwise I don't understand your point 
> here I'm afraid. That would indeed mean we should set 
> CMAKE_INSTALL_PREFIX=/usr. Perhaps there are other things we should set too. 
> If you're suggesting we should do that, then maybe we really should. Is that 
> the suggestion?
> 
> I'd still like to see a list of what changes. What moves where etc, as a 
> result of this. You mentioned $prefix/lib/plugins to $prefix/lib64/plugins . 
> Is that everything? It's only plugins that are affected?
> 
> Aleix Pol Gonzalez wrote:
> `CMAKE_INSTALL_PREFIX=/usr` would be a whole different story, because 
> we'd be deciding on where the project is installed. The important thing is 
> that if the user decides that his project and Qt share the same prefix, those 
> should get plugins (and FWIW, anything that will be looked-up afterwards by 
> Qt) in the same place, by default.
> 
> Namely, that is that we're making sure is the same:
> 
> * KDE_INSTALL_QTPLUGINDIR: `qmake -query QT_INSTALL_PLUGINS`
> * KDE_INSTALL_QMLDIR: `qmake -query QT_INSTALL_QML`
> * KDE_INSTALL_QTQUICKIMPORTSDIR: `qmake -query IMPORTS_INSTALL_DIR`

Oh, what if the user *doesn't* have his project and Qt in the same prefix? Eg. 
Qt in /usr (system-provided) and his project in ~/local?


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127169/#review92739
---


On Feb. 24, 2016, 2:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 2:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

[Nicolás Alvarez]

> On Feb. 24, 2016, 4:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5

I don't think "all distros set it" is a valid argument for changing a default, 
otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default too.


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127169/#review92739
---


On Feb. 24, 2016, 2:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 2:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Policy regarding QtWebKit and QtScript

[Nicolás Alvarez]

> On Dec 25, 2015, at 10:28, Thomas Lübking  wrote:
> 
>> On Freitag, 25. Dezember 2015 12:42:26 CEST, Milian Wolff wrote:
>> 
>> Sorry, but how is "it takes long to compile" and argument for or against a 
>> piece of software if there is no feature equivalent alternative that takes 
>> less time to compile?
> 
> How demanding is it exactly?
> Considering Gentoo users, it could be quite a problem if it takes 32GB RAM or 
> something.
> 
> Cheers,
> Thomas

The linking step needs 4GB of RAM, which means it takes 40 minutes of 
swap-thrashing just to link if you're on a 4GB RAM system that can't dedicate 
100% to ld alone (the OS and disk cache need memory too!). I ended up renting 
an 8GB VPS for a few hours to compile a personally-patched Chromium.

But 4GB is not too much in this day and age. My computer is outdated.

Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced

[Nicolás Alvarez]

> El 8 dic 2015, a las 07:11, Jan Kundrát  escribió:
> 
> It is irrelevant what our personal preference is. The fact of life is that 
> there *are* mailing lists out there which perform these modifications, and 
> these MLs won't change their config despite changes on our side. If we start 
> rejecting these e-mails, well, our addresses will be unsubscribed from these 
> MLs and we won't be able to participate in relevant technical discussions. If 
> that happens, I'm afraid that the @kde.org e-mail addresses will no longer 
> provide their stated value.

Unfortunately, this is the mess that DMARC got us into:

It is irrelevant what our personal preference about doing modifications to 
messages is (like the tag in the subject). The fact of life is that there *are* 
mail providers out there (like Yahoo) which are already enforcing DMARC and may 
reject messages with such DKIM-breaking modifications, and these mail providers 
won't change their config to accommodate us.

Re: Why is C90 enforced in KDE?

[Nicolás Alvarez]

2015-12-06 12:54 GMT-03:00 Thomas Lübking :
> On Sonntag, 6. Dezember 2015 16:08:04 CEST, Antonio Rojas wrote:
>>
>> C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any
>> effect, since it is overriden by kdelibs (and by extra-cmake-modules in
>> KF5). What is the reason for this?
>
>
> I guess because of poor compiler support.
> One needs MSVC 2013 for at least *some* C99 support :-P
> (2015 should be somewhat complete, though)

I guess -std=c90 is used to make sure nobody accidentally introduces
C99 features that will break in older compilers. However, all
compilers we care about support // comments in C code... I didn't find
any way for gcc to allow // but disallow other C99 features.

Maybe we should use -std=gnuc90 -Wpedantic in gcc instead of -std=c90,
so that GNU extensions (including // comments) are allowed but give
warnings. Then we ignore warnings about // comments and pay attention
to others (in case someone accidentally introduces a GNU extension and
breaks the build in other compilers).

Of course, another way to get what we want is to not use -std=c90, but
have proper CI for MSVC. That way we'll know if someone adds
unsupported C99 features :)

-- 
Nicolás