Re: Retirement of IRC Services and KDETalk.net (Jabber)

[Nicolás Alvarez]

El dom, 21 may 2023 a la(s) 07:42, Christian (Fuchs) (k...@fuchsnet.ch) 
escribió:
> while I can't comment on the Jabber side, some questions about IRC and the
> Telegram bridges. The latter seems to be still in use in some of the more
> graphically oriented communities, e.g. quite a handful of people in the VDG
> chat seem to be using it, do we have numbers on that, also what services does
> that bridge to? The name suggests Mattermost (?), but I don't think we have
> that. Depending on which services it bridges to, some channels might like to
> have that. If it's none of importance, then yeah, probably that can be gone.

I think Matterbridge started as a Mattermost-IRC bridge, but now it
supports dozens of chat protocols and the name stuck; we never used it
for Mattermost. We are using it only for IRC-Telegram on some channels
which, as Kenny said, weren't migrated to the Matrix<->Telegram bridge
yet. I also had it bridging Libera+Freenode+Telegram for a day or two
when some people were still unaware of the move to Libera.

-- 
Nicolás

Re: Recurrent <5$ USD monthly subscription.

[Nicolás Alvarez]

Maybe we should consider liberapay? It allows donations as low as
€0.01/week (which is paid in advance to reduce payment processor
fees).

-- 
Nicolás

El lun, 27 feb 2023 a la(s) 20:02, Nate Graham (n...@kde.org) escribió:
>
> Hello Gary,
>
> I'm happy you're happy, and thanks for wanting to donate! You can make
> monthly donations of 3€ or more at
> https://kde.org/fundraisers/yearend2022. Any smaller than that and the
> fees start to eat into the donations too much, and you could instead
> consider a yearly donation in the amount you wanted to donate per month,
> multiplied by 12.
>
> Nate
>
>
>
> On 2/26/23 04:00, Gary Espitia wrote:
> > Hi;
> >
> > I use KDE and love the project; I want to, make recurring automatic
> > donations, but the minimum set in github is 5$USD. If there's any reward
> > I don't need it, I just want to be able to make the hassle-libre
> > donation but set it to the amount I consider for whatever reason
> > adequate, even if it's less than 5$USD a month.
> >
> >
> > Thank you for your attention.
> >

Re: Does KDE have a policy for shipping libraries licensed under the Apache license?

[Nicolás Alvarez]

Oops, I somehow misunderstood the question as being about iOS but it's 
actually Android. Do you work on both? Your name may be what confused me.

My reply should still be applicable anyway, other than the specific examples 
and references to Apple :)

> El 20 dic. 2022, a la(s) 01:41, Nicolás Alvarez  
> escribió:
> 
> (This is "as I understand it", not legal advice, I am not a lawyer, etc etc)
> 
> The system library clause is, for example, what lets KDE Connect (under the 
> GPL) link to the iOS system frameworks (under a proprietary license).
> 
> System libraries have nothing to do with the Apache situation. GPLv2 and 
> Apachev2 are incompatible due to the details of the patent termination terms, 
> while GPLv3 and Apachev2 are compatible, with no need to invoke the system 
> library clause. See https://www.apache.org/licenses/GPL-compatibility.html
> 
> A project under the GPLv3 can incorporate files under the Apache2 license, 
> and the combined work, like the compiled binary, will be considered to be 
> under the GPLv3. You have to be very careful during development to not copy 
> code from the GPLv3 files to the Apache2 files (the copyright holder would 
> need to explicitly consent to relicensing that code to Apache2) or viceversa 
> (copying Apache2 code into GPLv3 files would need to preserve the original 
> copyright/license/warranty notices).
> 
> A project under the GPLv3 can also link to a library under Apachev2, and then 
> things are even easier since you don't have to worry about pieces of code 
> getting copied between files (the library source code is not in your project 
> and you won't be modifying it).
> 
> I found more info here (especially about the complications in the non-library 
> case):
> https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
> 
> Note that the GPLv3 has the famous "anti-tivoization" clause (not present in 
> GPLv2) which requires, in some cases, distributing signing keys that let you 
> run the modified software, and this seems like it would clash with the App 
> Store. However, it is my understanding that this does *not* apply to App 
> Stores. It only applies when the software is shipped with a hardware device 
> and distributed along with the sale of the device. (The messy wording in the 
> GPLv3 is to avoid "but we're not really *selling* it" loopholes). Apple can't 
> put GPLv3 code in iOS itself, but third party apps should be fine.
> 
> Also, while you may want to say somewhere "KDE Connect for iOS is licensed 
> under the GPLv3", the individual source code files (at least those not 
> directly interacting with this library) can keep saying GPLv2/v3/eV. That 
> would let us copy code into other KDE projects without having to ask people 
> for relicensing just to add v2 again.
> 
> -- 
> Nicolas
> I'm not a FOSS lawyer, I just play as one on the Internet sometimes
> 
>> El 20 dic. 2022, a la(s) 00:47, Simon Redman  escribió:
>>  Hi Andrius,
>> 
>> Thanks for your input.
>> 
>> That is the textbook answer, but doesn't actually fit this case. GPLv3 is 
>> only compatible with Apache because it has an exclusion for system 
>> libraries, but KDE Connect is an Android app so there is no concept of 
>> system libraries.
>> 
>> It doesn't get to the core of the issue: What is KDE's position?
>> 
>> To take another angle:
>> If I assume the whole package falls under the "entire work", and if I 
>> package Apache v2 and my own GPL v2 code together, and distribute it, I'd 
>> have broken the GPLv2 license of my own code because I cannot relicence the 
>> Apache parts of the "whole work", but I'm not going to sue myself so there 
>> is no legal issue.
>> 
>> The simple example gets complicated when it's a global organization, and not 
>> just my code but the code of other contributors as well. But that's why I'm 
>> asking if there's a defined policy.
>> 
>> Thanks,
>> Simon
>> 
>> 
>> On December 19, 2022 5:54:38 PM EST, "Andrius Štikonas"  
>> wrote:
>>> 
>>> Hi,
>>> 
>>> Quick check seems to indicate that KDE Connect license is:
>>> 
>>> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
>>> Apache v2 licensed code is not compatible with GPL-2.0-only but
>>> is compatible with GPLv3. So by combining KDE Conenct with
>>> that library you lose right to redistribute the whole thing
>>> as GPL2 but you still have the right to redistribute combined code under
>>> 
>>> GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
>>> I.e. you a

Re: Does KDE have a policy for shipping libraries licensed under the Apache license?

[Nicolás Alvarez]

(This is "as I understand it", not legal advice, I am not a lawyer, etc etc)

The system library clause is, for example, what lets KDE Connect (under the 
GPL) link to the iOS system frameworks (under a proprietary license).

System libraries have nothing to do with the Apache situation. GPLv2 and 
Apachev2 are incompatible due to the details of the patent termination terms, 
while GPLv3 and Apachev2 are compatible, with no need to invoke the system 
library clause. See https://www.apache.org/licenses/GPL-compatibility.html

A project under the GPLv3 can incorporate files under the Apache2 license, and 
the combined work, like the compiled binary, will be considered to be under the 
GPLv3. You have to be very careful during development to not copy code from the 
GPLv3 files to the Apache2 files (the copyright holder would need to explicitly 
consent to relicensing that code to Apache2) or viceversa (copying Apache2 code 
into GPLv3 files would need to preserve the original copyright/license/warranty 
notices).

A project under the GPLv3 can also link to a library under Apachev2, and then 
things are even easier since you don't have to worry about pieces of code 
getting copied between files (the library source code is not in your project 
and you won't be modifying it).

I found more info here (especially about the complications in the non-library 
case):
https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

Note that the GPLv3 has the famous "anti-tivoization" clause (not present in 
GPLv2) which requires, in some cases, distributing signing keys that let you 
run the modified software, and this seems like it would clash with the App 
Store. However, it is my understanding that this does *not* apply to App 
Stores. It only applies when the software is shipped with a hardware device and 
distributed along with the sale of the device. (The messy wording in the GPLv3 
is to avoid "but we're not really *selling* it" loopholes). Apple can't put 
GPLv3 code in iOS itself, but third party apps should be fine.

Also, while you may want to say somewhere "KDE Connect for iOS is licensed 
under the GPLv3", the individual source code files (at least those not directly 
interacting with this library) can keep saying GPLv2/v3/eV. That would let us 
copy code into other KDE projects without having to ask people for relicensing 
just to add v2 again.

-- 
Nicolas
I'm not a FOSS lawyer, I just play as one on the Internet sometimes

> El 20 dic. 2022, a la(s) 00:47, Simon Redman  escribió:
>  Hi Andrius,
> 
> Thanks for your input.
> 
> That is the textbook answer, but doesn't actually fit this case. GPLv3 is 
> only compatible with Apache because it has an exclusion for system libraries, 
> but KDE Connect is an Android app so there is no concept of system libraries.
> 
> It doesn't get to the core of the issue: What is KDE's position?
> 
> To take another angle:
> If I assume the whole package falls under the "entire work", and if I package 
> Apache v2 and my own GPL v2 code together, and distribute it, I'd have broken 
> the GPLv2 license of my own code because I cannot relicence the Apache parts 
> of the "whole work", but I'm not going to sue myself so there is no legal 
> issue.
> 
> The simple example gets complicated when it's a global organization, and not 
> just my code but the code of other contributors as well. But that's why I'm 
> asking if there's a defined policy.
> 
> Thanks,
> Simon
> 
> 
> On December 19, 2022 5:54:38 PM EST, "Andrius Štikonas"  
> wrote:
>> 
>> Hi,
>> 
>> Quick check seems to indicate that KDE Connect license is:
>> 
>> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
>> Apache v2 licensed code is not compatible with GPL-2.0-only but
>> is compatible with GPLv3. So by combining KDE Conenct with
>> that library you lose right to redistribute the whole thing
>> as GPL2 but you still have the right to redistribute combined code under
>> 
>> GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
>> I.e. you are essentially dropping GPLv2 support and only keeping GPLv3.
>> So you must first check that you have no GPLv2 only dependencies.
>> 
>> Kind regards,
>> Andrius
>> 
>> 2022 m. gruodžio 19 d., pirmadienis 23:34:11 CET Simon Redman rašė:
>> > KDE Connect has had this PR languishing for a couple of years, with a
>> > question I am not able to answer.
>> > https://invent.kde.org/network/kdeconnect-android/-/merge_requests/192
>> >
>> > The author has added a (very useful) library, which happens to be
>> > licensed under the Apache v2 license.
>> >
>> > KDE Connect code is GPL-licensed. GPL section 2 says that the entire
>> > work must be distributed as GPL.
>> > https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
>> >
>> > In my eyes, the only meaningful part of the work is the source code, at
>> > which level the concept of distributing a library does not apply. The
>> > .apk that we give to users is just a convenience to them, they could
>> > just as well 

Re: The status of freenode (the IRC network used by KDE)

[Nicolás Alvarez]

Freenode has now set up new servers without migrating the
nickserv/chanserv databases, and will likely turn off the old servers
later. You could say freenode has shut down and there is now a new
network under its name. We don't have any registered channels in the
"new network", or even channel topics set.

Are we going to move to libera.chat already?

It has been more than three weeks since Andrew Lee took over. I'm
*done* waiting for Matrix to reconfigure the bridge. Leaving it
unbridged entirely is preferred to the current situation. You can't
say that would split the chat community because it's already split
anyway (there's more users in libera.chat KDE channels every day, as
of yesterday irccloud users couldn't use freenode anymore, #kde hasn't
been properly bridged for a long time, etc).

Just tell me when and I'll switch IrcsomeBot/sKreamer/pursuivant bots
to libera.chat, and update documentation (I already prepared commits
for 30+ repos for this). I can also bring IrcsomeBot into Matrix rooms
temporarily until the proper Matrix appservice is set up. But I will
not accept any more delays caused by Matrix/EMS. Let's get out of
freenode.

-- 
Nicolás

Re: The status of freenode (the IRC network used by KDE)

[Nicolás Alvarez]

El sáb, 22 de may. de 2021 a la(s) 21:17, Aleix Pol (aleix...@kde.org) escribió:
>
> On Wed, May 19, 2021 at 9:57 PM Aleix Pol  wrote:
> >
> > On Wed, May 19, 2021 at 7:45 PM Martin Flöser  wrote:
> > >
> > > Am Mittwoch, 19. Mai 2021, 10:34:26 CEST schrieb Christian:
> > > > Dear KDE community,
> > > >
> > > > KDE has been using the free services of the freenode IRC networks for a
> > > > little bit more than two decades, and hopefully happily and successfully
> > > > so.
> > >
> > > Thanks for informing us. This sounds horrible and must have been a very
> > > stressful time for all of you staffers.
> > >
> > > > Due to this leakage, Andrew Lee (former PIA/LTM, now shells.com)
> > > > learned of the new situation and asked democratically elected
> > > > freenode volunteers to step down from their position, as seen in the
> > > > logs linked on [4] [5] [6]
> > > > Therefore making the takover attempt and some details public.
> > >
> > > Given that this is driven by shells.com I think the KDE community should 
> > > step
> > > up and remove all references to shells.com. Their behavior in this case 
> > > goes
> > > clearly against our values.
> >
> > It seems to me that we are jumping to conclusions only based on hearsay.
> >
> > Today at the Board call we talked with Fuchs and Duffus about
> > Freenode. I've reached out to our Shells contact to see what's
> > happening and will be talking to them soon.
> > At this point the connection between this Freenode kerfuffle and
> > Shells is unclear to me, I'd prefer to understand what the situation
> > is before we ban them from our websites because they're somehow
> > related by blood.
> >
> > Aleix
>
> Hi everyone,
> We (Eike and I) had a short discussion with Shells's CEO and it
> doesn't seem like their relationship to freenode is all that tight as
> portrayed. I do not think we should fire them from being our sponsors
> or to try to work with us.
>
> This does not mean though that we should stay on freenode. If you ask
> me, our matrix instance has been solid enough for it to be the
> official way to join. If we bridge to one or another, I'd say it
> largely should follow wherever people are.
>
> This also does not mean that I believe Shells are above anyone else. I
> know they're observing this situation, let's see what they have in
> mind. They should be at Akademy, it's probably a good opportunity to
> discuss.
>
> Aleix

Could you please clarify: is Andrew Lee the current CEO of Shells and
the person you talked to?

-- 
Nicolás

Re: The status of freenode (the IRC network used by KDE)

[Nicolás Alvarez]

El mié, 19 de may. de 2021 a la(s) 14:53, Carl Schwan
(c...@carlschwan.eu) escribió:
>
> Le mercredi, mai 19, 2021 7:45 PM, Martin Flöser  a écrit 
> :
>
> > Am Mittwoch, 19. Mai 2021, 10:34:26 CEST schrieb Christian:
> >
> > > Dear KDE community,
> > > KDE has been using the free services of the freenode IRC networks for a
> > > little bit more than two decades, and hopefully happily and successfully
> > > so.
> >
> > Thanks for informing us. This sounds horrible and must have been a very
> > stressful time for all of you staffers.
> >
> > > Due to this leakage, Andrew Lee (former PIA/LTM, now shells.com)
> > > learned of the new situation and asked democratically elected
> > > freenode volunteers to step down from their position, as seen in the
> > > logs linked on [4] [5] [6]
> > > Therefore making the takover attempt and some details public.
> >
> > Given that this is driven byshells.com I think the KDE community should step
> > up and remove all references to shells.com. Their behavior in this case goes
> > clearly against our values.
>
> I agree and created two merge requests:
>
> * https://invent.kde.org/websites/kde-org/-/merge_requests/104
> * https://invent.kde.org/websites/neon-kde-org/-/merge_requests/8
>
> I would prefer if it's someone who was involved with setting this up that 
> merges
> these two MRs. CC Jonathan and Aleix

Aren't they sponsors? We can't *just* remove them from the website...

--
Nicolás

Re: Appreciation

[Nicolás Alvarez]

El jue, 25 de mar. de 2021 a la(s) 16:46, Thomas Lopez (m...@tlopez.cc) 
escribió:
> PS: Can you guys post a btc, eth, or ltc donation address on your github?

Unfortunately holding cryptocurrency is quite problematic (accounting,
etc) for the KDE eV non-profit organization, so we don't currently
have any way to accept such donations. Something I have done in the
past (for a different project/organization) is have someone else
donate money on my behalf and pay them back in BTC.

--
Nicolás

Re: RMS and open letter

[Nicolás Alvarez]

El mar, 23 de mar. de 2021 a la(s) 17:27, Jos van den Oever
(j...@vandenoever.info) escribió:
> "I think it is strange that, on the one hand, the tech world has been
> advocating for the rights of neurodivergent people – society should accept
> that people on the autism spectrum are different and that’s OK. But at the
> same time RMS has been attacked for some statements very probably stemming
> from his autism that, while they may seem a bit shocking and at odds with the
> mainstream, were not illegal or intentionally offensive."
> https://news.ycombinator.com/item?id=26535390

Stallman himself has denied having autism.

-- 
Nicolás

Re: Qt goes "commercial only! - what now?

[Nicolás Alvarez]

El jue, 7 de ene. de 2021 a la(s) 08:52, Mathias Homann
(mathias.hom...@opensuse.org) escribió:
>
> Am Donnerstag, 7. Januar 2021, 11:01:23 CET schrieb David Edmundson:
>
> > From a user point of view, there will be no impact.
>
> are you sure? To me it sounds as if only commercial "licensees" will have
> access to the latest sources and/or security fixes, which also won't get
> backported anymore...

Only commercial licensees will have access to backported fixes for Qt
5.15. There are no changes regarding access to Qt6. Qt 5.12 is LTS and
will keep getting public fixes until Dec 2021 too.

-- 
Nicolás

Re: ReCaptcha integration in an KDE application

[Nicolás Alvarez]

El sáb., 7 de nov. de 2020 a la(s) 18:58, Carl Schwan
(c...@carlschwan.eu) escribió:
>
> Le samedi, novembre 7, 2020 10:46 PM, Nicolás Alvarez 
>  a écrit :
>
> > El sáb., 7 de nov. de 2020 a la(s) 18:22, Carl Schwan
> > (c...@carlschwan.eu) escribió:
> >
> > > Hello folks,
> > > Tobias and I are developing a KDE matrix client using Kirigami
> > > and other KDE frameworks called NeoChat. This is a fork of another
> > > QML and now unmaintained Matrix client named Spectral.
> > > Tobias is currently implementing the account registration API
> > > and we found out that even if it isn't mandatory in the matrix
> > > spec, it is required to add ReCaptcha for connecting to most
> > > of the Matrix server (including kde.org, matrix.org and other
> > > major matrix servers).
> > > From a technical point of view, this would be quite painful to
> > > implement (adding a dependency to QtWebEngine) but most
> > > importantly this would require adding integration into a service
> > > that is not privacy-friendly, proprietary and monopolist. This
> > > is something that we think goes against the value of KDE. But at
> > > the same time, making it possible to register an account directly
> > > from NeoChat is something that is quite important in the user
> > > experience.
> > > So my questions to the community would be to know if there are
> > > already some precedent of KDE apps adding supports for ReCaptcha
> > > and if this is a good idea to support it?
> > > Thanks in advance for your answers,
> > > Cheers,
> > > Carl and Tobias
> >
> > Does Matrix really require "recaptcha"? I thought it had a protocol
> > for "whatever login/security mechanism the homeserver gives you, as a
> > webpage link".
>
> Basically from that, I read in this GitHub issue[1] is that recaptcha is
> not mendatory but it is the only service supported by synapse. Making
> all the big matrix servers require to talk with recaptcha to create new
> accounts.
>
> This is not about login (that works fine with NeoChat) but more about
> account registration.
>
> [1]: https://github.com/matrix-org/matrix-doc/issues/1281
> >

Well that's just absurd. The spec doesn't even say *how* you're
supposed to implement such a thing in a client. I'm not even sure if
this use case is supported/allowed by Google.

--
Nicolás

Re: KDE Apps name trademarks

[Nicolás Alvarez]

El jue., 9 de jul. de 2020 a la(s) 10:49, Christoph Cullmann
(christ...@cullmann.io) escribió:
> There is no evidence that this upload contains any virus/miner/...
>
> And even for the GPL it is enough if he provides the sources on request
> and only to the customers that bought the app.

That's not true:
- If I buy the app and it includes the source code, I'm allowed to
redistribute the binary, as long as I include the source code too
(GPLv2 §3.a).
- If it *doesn't* include the source code, then it has to include a
written offer to provide the source code "to any third party" (GPLv2
§3.b), and I'm allowed to redistribute the binary as long as I include
either the source code (§3.a), or pass along the offer for source code
that I got from the seller (§3.c). If you download it from me and I
include that offer, you can request the source from the seller, even
if you didn't buy the app from them.

-- 
Nicolás

Re: KDE Apps name trademarks

[Nicolás Alvarez]

El mié., 8 de jul. de 2020 a la(s) 15:28, Christoph Cullmann
(christ...@cullmann.io) escribió:
>
> On 2020-07-08 20:20, Ben Cooksley wrote:
> > On Thu, Jul 9, 2020 at 6:09 AM Christoph Cullmann
> >  wrote:
> >>
> >> On 2020-07-08 18:12, Jonathan Riddell wrote:
> >> > Recently we've noticed some KDE apps ending up on the Microsoft Store
> >> > uploaded by unknown third parties.  Maybe to up some credit score for
> >> > their developer account.  Maybe to install bitcoin  miners.  We don't
> >> > know the motivations.  Since it's all free software the licence allows
> >> > it.
> >>
> >> Hi,
> >>
> >> have you some links to these applications?
> >
> > I believe Jonathan will be referring to
> > https://www.microsoft.com/en-gb/p/kdiff-3-diff-utility/9ndvvx243rfh?activetab=pivot:overviewtab#
>
> Hi, thanks for the link.
>
> Guess such things are unavoidable.
>
> If the uploading person is some KDE community member, I assume one could
> talk with him/her/...

I doubt it's a KDE community member. Here are all their uploaded apps,
only one is KDE:
https://www.microsoft.com/en-us/search/shop/Apps?q=Dev+Packager

> Otherwise we must keep in mind we are open source and yes, this is
> possible.

Well, I don't know if the app is complying with the GPL. I would need
to purchase it to see if the downloaded package has the full GPL
license text, and the Corresponding Sources or a link to it. (Which,
by the way, I'm not sure if we're strictly following in our own
official uploads to the MS Store)

-- 
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: auto-comment on bugzilla when making an MR?

[Nicolás Alvarez]

El mié., 20 de may. de 2020 a la(s) 18:30, Filipe Saraiva
(fil...@kde.org) escribió:
>
> Em 20/05/2020 12:37, Nate Graham escreveu:
> > On 5/20/20 6:50 AM, Boudewijn Rempt wrote:
> >> On woensdag 20 mei 2020 14:33:42 CEST Filipe Saraiva wrote:
> >>> I like the idea, but I hope in future we use Gitlab issues as our tool
> >>> for bug management. :)
> >>
> >> This has been discussed to death before... The plan is to use the issues 
> >> to replace phabricator's tasks, not bugzilla.
> >
> > I'm pretty sure that migrating from Bugzilla to GitLab Issues will
> > happen eventually. GitLab Issues has a radically better UI for bug
> > reporting and its improved integration with the rest of GitLab will be a
> > really nice thing to have. Centralizing everything in GitLab would bring
> > real benefits.
> >
> > Speaking as an extensive bug triager, if it does indeed represent a
> > downgrade in terms of organization and workflow, then we will engage
> > with the GitLab people to get the issues fixed. They are pretty
> > responsive, and it's better than using a dead, unmaintained version of a
> > stagnant product.
> >
>
> Sure, in addition this adoption will provide all of these automation we
> need to implement to work in different tools, will be less work to
> sysadmin team in order to maintain an old product, and more.
>
> In fact, thinking about "KDE is all about apps" objective, the adoption
> of Gitlab issues for bug management is a interesting step. It will allow
> the community of a specific project work in more productive way than use
> a different tool for that task.
>
> But well, maybe it is a discussion for the future.
>

It's a discussion for months or years in the future. Please, we didn't
even finish with this migration.

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

[Nicolás Alvarez]

> El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt  escribió:
> 
> On woensdag 29 april 2020 15:16:12 CEST Adriaan de Groot wrote:
>>> On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote:
>>> We have gotten a request for namespacing from projects on multiple
>>> occassion, in cgit our workaround has always been that we prefix the
>>> repo name with namespace- (i.e wikitolearn-courses-backend).
>>> 
>>> While this works out with our current workflow, it is not really
>>> optimal. I've also mentioned various new contributor focused
>>> requirements which lead us to this proposal for structuring in previous
>>> emails.
>> 
>> 
>> Your mention of namespaces reminds me that there was **also** a discussion 
>> in 
>> this thread about workboards and reviews.
>> 
>> GitLab can have **one** workboard per group. So depending on how the 
>> categories / namespaces work out, we have choices in the overall number of 
>> workboards:
>> 
>> - one big one (flat)
>> - one per (sub)group / namespace
>> 
>> We should look at this as well. Arguments I've seen in this thread
>> 
>> - one big one is unmanageably large
>> - (sub)communities have asked for smaller (split) workboards
>> - split workboards make it harder to work over group boundaries
>> - one big one allows moving reviews and tasks to where they belong
> 
> Outch, that's a nasty one. I thought there was a workboard per repository... 
> And most of the proposed groups actually aren't really subcommunities in any 
> case, just bags of holding for vaguely similar projects.

My understanding is that there is a workboard per repository *and* another per 
group.

Now, how big do we make the group workboard? All of KDE? A smaller category? 
That is the question.

-- 
Nicolas

Re: Unused scratch/clones repositories cleanup

[Nicolás Alvarez]

El sáb., 25 de abr. de 2020 a la(s) 09:04, Bhushan Shah
(bs...@mykolab.com) escribió:
>
> Hello community,
>
> Curently there's about 1400 repositories in total under the, scratch/
> and clones/ namespace.
>
> https://cgit.kde.org/scratch/
> https://cgit.kde.org/clones/
>
> I am sure many people are using some of this repositories, but some are
> fairly inactive and unused. We would like to ask community members to
> go through their own personal repositories and clean-up the unused
> repositories. Instructions on how to delete or trash personal
> repositories can be found at:
>
> https://community.kde.org/Sysadmin/GitKdeOrgManual#Deleting_personal_repositories

It seems many people hit this error: note that the trash command needs
the repository name *without* the .git suffix.

-- 
Nicolás

Re: Qt, Open Source and corona

[Nicolás Alvarez]

El jue., 9 de abr. de 2020 a la(s) 09:01, Florian Bruhin
(m...@the-compiler.org) escribió:
> One possible reading of Olaf's original mail is that TQtC simply was bluffing
> in order to force "negotiations" about some other part of the agreement they
> don't like:
>
>   The Qt Company says that they are willing to reconsider the approach only if
>   we offer them concessions in other areas.
>
> Indeed, they now released a (very brief) announcement[2] claiming that they,
> apparently, never meant things that way:
>
>   There have been discussions on various internet forums about the future of 
> Qt
>   open source in the last two days. The contents do not reflect the views or
>   plans of The Qt Company.
>
>   The Qt Company is proud to be committed to its customers, open source, and
>   the Qt governance model.
>
> Needless to say, after more and more moves against the open-source side of Qt
> recently, I place a lot more trust in statements coming from KDE rather than
> those coming from TQtC...

I agree it's possible that "we're thinking about restricting ALL Qt
releases to paid license holders for the first 12 months" was just to
force our hand and make us give them other concessions, and that
they're not actually planning to do it.

But that's what the fork discussion is about. As Nate said, "we are
thinking of forking Qt" and having credible ability to do so, might
force *their* hand and make them take a step back. If then
negotiations go well, we don't need to actually fork. *Worst* case,
negotiations don't go well, and we have a head start on the forking
work.

-- 
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: Regarding KDE Privacy policy

[Nicolás Alvarez]

El sáb., 29 de feb. de 2020 a la(s) 11:00, Johan Ouwerkerk
(jm.ouwerk...@gmail.com) escribió:
>
> On Tue, Feb 25, 2020 at 9:06 PM Volker Krause  wrote:
> >
> > Not publishing the raw data right from the start was mainly a safety 
> > measure,
> > to give us a chance to review the data and fix de-anonymization issues 
> > should
> > any have slipped through.
> >
> > There's also technical limitations, the current system has no fine-grained
> > access control, not even read vs write access.
> >
> > For publishing aggregated data, I think that's already "allowed" right now,
> > just nobody has built an automated way of doing that yet.
> >
>
> What kind of views do we want? Histograms, averages, min/max, that
> sort of thing? In that case maybe something like
> https://grafana.com/grafana/ is a good idea.
> I'm assuming here that people would mostly want to get an
> idea/overview of a certain set of metrics, rather than manual querying
> or in-depth data analysis.

Grafana doesn't calculate averages or min/max. It sends arbitrary
queries from the browser to the database to make the database
calculate that, and then displays it in a nice graph.

We would need to do careful aggregation and anonymization on the
server, put that on a *separate database*, and let Grafana only access
that.

-- 
Nicolás

Re: Help with KDE PIM and Google Privacy Policies needed

[Nicolás Alvarez]

> On 6 Mar 2020, at 11:26, Martin Steigerwald  wrote:
> 
> Hi,
> 
> Martin Flöser - 06.03.20, 13:14:36 CET:
>> Am 2020-03-06 08:20, schrieb Nicolás Alvarez:
>>> Apple can give its million appstore apps access to Google calendar
>>> data, and Mozilla can let addons access email data, but we can't?
>>> What do they do differently?
>> 
>> The only thing they do differently is that they have a permission
>> system in place. Doesn't apply for Thunderbird of course which means
>> we should look at their privacy policy. Though we should never ask
>> Google "Why is Thunderbird allowed?" as we don't want that
>> Thunderbird gets access revoked.
> 
> I ask a different question:
> 
> Why – at all – rely on a provider who dictates on who gets access to it 
> and who does not? Why – at all – rely on a provider who by doing so 
> creates a walled garden?

That's something you should go ask the thousands of users complaining that they 
can't connect to GMail using KMail. They're the ones relying on the provider. 
Go to the bug report and tell them the solution to their KMail errors is to 
stop using Google services. That should go well :)

-- 
Nicolás
Sent from my GMail account ;)

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Nicolás Alvarez]

El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) escribió:
>
> Not knowing anything about the translation system we use... what are the
> blockers to moving it over to git?
>
> Nate

Not necessarily in order:
- Experiment conversion to git and see if the resulting repo(s) are of
a reasonable size (I vaguely recall seeing bad results with this)
- Convince and teach every translator to use git (expect lots of friction here)
- Make scripty use git instead of svn (likely lots of work)
- Some language teams have their own tooling (local for translation,
or web for statistics) that would need to be gitified too. For
example, the Spanish team developed KSvnUpdater.
- Update lots of documentation in different languages (eg.
https://es.l10n.kde.org/repositorio.php)

You may even need to migrate languages one by one (as you convince
each language team?), so in the meantime all tooling would need to
support both repos at the same time.

It doesn't sound like fun...

--
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: vote invitation sent out for goal voting

[Nicolás Alvarez]

El jue., 22 de ago. de 2019 a la(s) 22:13, Myriam Schweingruber
(myr...@kde.org) escribió:
> Any particular reason I got this survey request twice? That gives me 
> technically two votes, so there might be something wrong, especially if I am 
> not the only one who got this twice.

Did you get them on the same email address? Lydia sent it to all
developers and all mailing list subscribers. Maybe your developer
account and your mailing list subscription have different addresses,
so you got one on each.

--
Nicolás

Re: Anonymous contributions

[Nicolás Alvarez]

> On 16 Apr 2019, at 16:45, Boudewijn Rempt  wrote:
> 
>> On dinsdag 16 april 2019 21:38:04 CEST Ben Cooksley wrote:
>> 
>> This hook was implemented in the first place to ensure that people had
>> correctly setup Git on their local machine.
>> 
>> On some versions of Git (maybe all?) it will automatically use the local
>> user account name as the name.
>> 
>> This leads to people committing as "me", "user" and "nobody" without
>> meaning to, but which still leads to a situation in which the metadata of a
>> commit has ended up being useless.
>> 
>> I'd rather maintain a small list of exceptions for those who do have names
>> without a space in them to ensure that for the vast majority of our users
>> do correctly get informed they need to fix their local setup.
> 
> You could do a small blacklist of known wrong names like the ones you cite -- 
> but you will never be able to implement a hook that identifies a string as a 
> name correctly. I'm sorry -- but it's just impossible. 
> 
> It's also just not good manners to tell people their name isn't a real name: 
> and I think that allowing ourselves to accept every name except for things 
> like me, user, nobody, admin, root is more important than making sure we've 
> got correct metadata. 
> 
> Because none of us can actually be sure the metadata is correct anyway: 
> there's not just the impossibility of creating that identifies a string as a 
> name correctly, humans cannot do that either.

A blacklist won't work. The common wrong name due to misconfiguration would be 
if I commit as "nicolas" or "nalvarez" instead of "Nicolás Alvarez". That's a 
more common error than "user" or "root".

It seems easier to whitelist legitimate mononyms on request...

-- 
Nicolás

Re: Licensing policy change proposal

[Nicolás Alvarez]

> On 27 Jan 2019, at 15:04, Krešimir Čohar  wrote:
> 
> This email puts forth for your consideration a proposal to change our current 
> licensing policy to accommodate three more licenses that cover the new 
> photographic selection of wallpapers in https://phabricator.kde.org/D18078.
> 
> The licenses are:
> - the Pexels license: https://www.pexels.com/photo-license/

While I *personally* agree with this license, it will be probably considered 
non-free (because you can't resell the photo alone), in particular by Linux 
distributions.

> - the Unsplash license: https://unsplash.com/license, 
> https://en.wikipedia.org/wiki/Unsplash#License

Looks good to me. "The right to compile photos from Unsplash to replicate a 
similar or competing service" doesn't really affect us when we're using 
individual photos. I think it doesn't even concern copyright but "database 
rights". And everything else is basically CC0.

> - the Creative Commons Zero License: https://spdx.org/licenses/CC0-1.0.html

CC0 should be uncontroversial, it should be definitely allowed by our license 
policy.

IANAL etc.

-- 
Nicolás

Re: Flash on our websites?

[Nicolás Alvarez]

El 14 oct. 2018, a la(s) 17:22, Myriam Schweingruber  escribió:

> Hi there,
> 
> sorry for cross-posting, but I think the question is a really serious one
> 
> I agree I do not open the kde.org website very often, but I did so Saturday 
> when at the KDE booth in Dornbirn. Since I use a Flash blocker I was quite 
> surprised to get notified that the website tries to load Flash content (see 
> attached screenshot and inspection panel).
> 
> I really wonder why it is necessary for a Free Software Community like KDE to 
> use closed source technology on the very website where we promote Free 
> Software.
> 
> Best regards, Myriam

Click to allow the blocker to show the Flash element, and then show in the 
inspector where the actual Flash element is, rather than the blocker's 
placeholder. If you can't find it... it must be a bug in the blocker extension 
and there is indeed no Flash.

-- 
Nicolás

Re: compiling kde/qt apps for android

[Nicolás Alvarez]

El 7 oct. 2018, a las 02:25, Jos van den Oever  escribió:
> 
> KDE has a repo for F-Droid with 8 apps at the moment.
> https://origin.cdn.kde.org/android/fdroid/repo/

Linking to 'origin' bypasses the CDN and makes all requests hit our servers. 
Please don't :P Where did you even get that URL?

For the benefit of people who find this thread after we finally blocked access 
to the origin endpoint: https://cdn.kde.org/android/fdroid/repo/

-- 
Nicolás
KDE Sysadmin Team

Re: Replacement of KDE Identity

[Nicolás Alvarez]

2018-04-06 20:31 GMT-03:00 Ben Cooksley :
> On Sat, Apr 7, 2018 at 11:23 AM, Roman Gilg  wrote:
>> For the future a KDE owned online service for users to backup and sync
>> their KDE Apps / Plasma Workspace settings on multiple devices through
>> this new online identity system would be nice. Not sure how this
>> affects the requirements of this identity system.
>
> Hi Roman,
>
> This shouldn't change the requirements of the system, as users would
> authenticate with this future service the same way they'll
> authenticate to our other websites - using OAuth2 (or equivalent
> mechanism).
>
> Cheers,
> Ben

It does affect requirements slightly. Currently KDE Identity is for
people who participate in the community, even if it's as little as
asking questions in the forum. Letting people backup and sync their
settings means we're broadening the scope to "all users of KDE
software", which may have implications for scalability. It also makes
the "don't require usernames for login" requirement much more
important.

-- 
Nicolás

Re: List for job offers

[Nicolás Alvarez]

2018-02-18 9:57 GMT-03:00 Roman Gilg :
> I received last week a job offer for a project involving
> C++/Linux/Qt/QML via LinkedIn. I told the headhunter to write a mail
> to the kde-community list so other people in our community who are
> currently looking for such an opportunity could apply.
>
> He said that he sent a mail, but I didn't spot it in the list. Was the
> mail maybe rejected by the list admin because such job offers are not
> allowed on the kde-community list?

The message is still in the moderation queue, it has been neither
accepted nor rejected. Sometimes I login with the global-admin
password and reject obvious spam, but since I don't know if this is
allowed or not, I left that message untouched for the actual
moderators to decide.

But considering it has been queued for a week or two, maybe I should
just accept it, and if it's not welcome, people can complain later :)

-- 
Nicolás
KDE Sysadmin Team

Telegram-IRC bridge not working

[Nicolás Alvarez]

Hi people,

The KDE Telegram-IRC bridge bot is not working anymore, and after some
troubleshooting and upgrades uhh I think I managed to break it more.
Maybe it's a problem with Telegram's servers though. I'll do some more
testing later, but for now it's down.

If you need to talk in those IRC channels from your phone, I suggest
you try Matrix/Riot for now. Maybe you'll end up liking it :)

-- 
Nicolás
KDE Sysadmin Team

Re: FOSDEM retrospective

[Nicolás Alvarez]

2018-02-05 20:33 GMT-03:00 Luigi Toscano :
> And we can use also phabricator (again, only Akademy):
> https://phabricator.kde.org/calendar/export/3/

It says you're the only one with permissions to access that link.

-- 
Nicolás

Re: Babe project - Legal feedback

[Nicolás Alvarez]

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

As I understand it, some of these Babe features would involve KDE
servers; it's not fully peer-to-peer.

KTorrent is legal and has legal uses, and if its users use it for
illegal stuff, that's their problem. But if KDE ran a BitTorrent
tracker on its infrastructure and people used it for copyrighted
content, would we get in trouble? Even though (like ThePirateBay's
defense says) trackers don't host or distribute content, just tell
peers where the other peers are?

-- 
Nicolás

Re: FOSDEM - what to show?

[Nicolás Alvarez]

2018-01-26 16:04 GMT-03:00 Boudewijn Rempt :
> On Friday, January 26, 2018 1:11:56 PM CET Adriaan de Groot wrote:
>
>> What I don't have is a good idea of what to show; if those people who have
>> volunteered for the table do, that's really excellent. Otherwise, I'm
>> looking for input on what's new and neat in KDE (because what I personally
>> pay attention to is konsole and kdevelop, I have no idea; I'd be an
>> embarrasment presenting Krita for instance).
>
> I will bring goodies to give out or sell (all proceeds to be for KDE e.V.).
> Those will include art books, post-cards, A4 stickers, dvd's, pencil cases and
> maybe other stuff. It'll all be highly shiny and attractive, so don't worry
> about having to demo Krita.

Being able to demo Krita would be great though. Any artist attending? :)

-- 
Nicolás

Re: Input on privacy goal

[Nicolás Alvarez]

> On 19 Jan 2018, at 14:58, Sandro Knau�  wrote:
> 
> Hey,
> 
>>> Here are some thoughts on threat models for this, as a possible way to
>>> better capture what we want to achieve.
>>> 
>>> (1) Public Wifi
>>> 
>>> Assume anyone can see your Wifi network traffic (e.g. via recent
>>> vulnerabilities in WPA2). Using your device in such an environment should
>>> be safe and not compromise your privacy any more compared to using a
>>> wired network at home.
>>> 
>>> Possible counter-measures: Encrypted communication, VPN.
>> 
>> Since (I think) iOS 10, the Wi-Fi configuration gives pretty loud warnings
>> if you connect to an unsecured Wi-Fi network. Perhaps the Plasma
>> NetworkManager applet needs similar UI improvements in that area.
> 
> just to mark all non encrypted Wifi as insecure and mark everything with WPA2 
> as secure is too simple. The most bars I now have also a WPA2 secured Wifi, 
> you the the password by asking are looking into the papers laying around. But 
> I never would trust those encrypted Wifis. Everyone you have the password can 
> see my traffic, and as those bars never changing their password...

This is not quite true. Being in a WPA2 network where everyone knows the 
password is not equivalent to being in an unsecured network. If it's unsecured, 
traffic is in plaintext (unless, of course, higher level protocols do their own 
encryption, such as TLS). A WPA network transmits traffic encrypted with 
negotiated keys, and you can't passively intercept it and decrypt it even if 
you know the password.

It *might* be possible to do a man-in-the-middle by running your own access 
point with the same SSID and password, and get the victim to connect to you 
instead of the real one, but it's much harder to pull that off.

> I would 
> like to see a way to tell the computer "kontact and owncloud-client should 
> only be active for my home by default". Otherwise ask me, if they should go 
> online. And at second level it would be nice to say, if I'm not at my home 
> connection kontact should use this VPN to connect...

Ohh, I'm interested in this feature too, for a different reason: choosing which 
apps can connect to the network when I'm tethered to my phone and using my 
horribly limited 3G plan.

-- 
Nicolás

Re: Input on privacy goal

[Nicolás Alvarez]

> On 19 Jan 2018, at 11:30, Volker Krause  wrote:
> 
>> On Friday, 19 January 2018 14:49:58 CET Sebastian Kügler wrote:
>> I'd like to collect some more input from the wider KDE community about our
>> privacy goal for the next years. If you're unsure what I'm talking about,
>> please have a look at https://vizzzion.org/blog/2017/11/kdes-goal-privacy/
> 
> Here are some thoughts on threat models for this, as a possible way to better 
> capture what we want to achieve.
> 
> (1) Public Wifi
> 
> Assume anyone can see your Wifi network traffic (e.g. via recent 
> vulnerabilities in WPA2). Using your device in such an environment should be 
> safe and not compromise your privacy any more compared to using a wired 
> network at home.
> 
> Possible counter-measures: Encrypted communication, VPN.

Since (I think) iOS 10, the Wi-Fi configuration gives pretty loud warnings if 
you connect to an unsecured Wi-Fi network. Perhaps the Plasma NetworkManager 
applet needs similar UI improvements in that area.

> (2) Stolen Device
> (3) Mega Corporations ("Google")
> (4) Global Surveillance ("NSA")
> (5) Targeted Surveillance ("Snowden")
> 
> What else? Which of those do we want to address? Do you think that's a useful 
> approach to guide/validate our work?

We may need more stuff related to our own services. Do we have a privacy policy 
in all websites that need one? What can we use logs for?

And maybe we should have a proper internal policy of what info KDE sysadmins 
are allowed to peek into, and for what purposes.

-- 
Nicolás

Re: End of year fundraising campaign is now live

[Nicolás Alvarez]

I also think #7d7d7d over white background isn't enough contrast for
the main body text.

-- 
Nicolás

2017-12-16 15:50 GMT-03:00 Dominik Haumann :
> Hi,
>
> thanks for the initiative. Going to
> https://www.kde.org/fundraisers/yearend2017/ the title on this page
> has zero contrast: There is white text over the mostly white
> background image. Maybe change the font color to black? Or add some
> shadow effect?
>
> Greetings,
> Dominik
>
> On Fri, Dec 15, 2017 at 10:49 AM, Paul Brown  wrote:
>> Hello Everyone,
>>
>> The website for the end of year fundraising campaign is now live:
>>
>> https://www.kde.org/fundraisers/yearend2017/
>>
>> We need your help to give it some coverage. We have already posted to the
>> official Twitter, Facebook, Mastodon, G+ and also to Reddit.
>>
>> Twitter:
>> https://twitter.com/kdecommunity/status/941601027874312192
>>
>> Mastodon:
>> https://mastodon.technology/@kde/99177624080490539
>>
>> Facebook:
>> https://www.facebook.com/kde/posts/10155422236813918
>>
>> G+:
>> https://plus.google.com/b/105126786256705328374/+KdeOrg/posts/Feg1RykLD7n
>>
>> Reddit
>> https://www.reddit.com/r/linux/comments/7jypnv/
>> kde_launches_end_of_year_fundraising_campaign_to/
>>
>> https://www.reddit.com/r/kde/comments/7jypcu/
>> contribute_to_the_advancement_of_free_software/
>>
>> We would need re-tweets, shares, upvotes, etc. Also, anybody that would like
>> to comment on their blogs on the campaign, say, within a "looking back at
>> 2017" kind of post, we would be very happy to promote it too. Also if you can
>> think of any sites we should be posting this to, suggestions are very 
>> welcome.
>>
>> Let's push to make this a successful campaign!
>>
>> Cheers
>>
>> Paul
>> --
>> Promotion & Communication
>>
>> www: http://kde.org
>> Mastodon: https://mastodon.technology/@kde
>> Facebook: https://www.facebook.com/kde/
>> Twitter: https://twitter.com/kdecommunity
>>

Re: Added a resources page on community.ko

[Nicolás Alvarez]

> El 11 oct 2017, a las 07:18, Adriaan de Groot  escribió:
> 
> On Monday, October 9, 2017 3:49:12 PM EDT Olivier Churlaud wrote:
>> I wanted to share with you that I added a page for KDE talks and
>> resources on https://community.kde.org/Resources
> 
> Are you aware of https://www.kde.org/kdeslides/  and https://www.kde.org/
> stuff/ ? (Yes, very old-school, should probably have contents moved to your 
> new resources page)

Those large PDFs are one of the problems I hit when trying to move the KDE 
website from SVN to Git...

-- 
Nicolás

Re: Telemetry Policy - Remaining Questions

[Nicolás Alvarez]

2017-09-15 4:27 GMT-03:00 Volker Krause <vkra...@kde.org>:
> On Friday, 15 September 2017 05:23:44 CEST Nicolás Alvarez wrote:
>> From Mozilla documentation: "So when you say '63% of beta 53 has
>> Firefox set as its default browser', make sure you specify it is 63%
>> of *pings*, since it is only around 46% of clients. (Apparently users
>> with Firefox Beta 53 set as their default browser submit more
>> main-pings than users who don't)."
>
> That is something else though, that's the participation ratio on opt-in.
> Measuring that and determining its bias on the submitted data is indeed a
> challenge, but I don't see how unique ids help with that?

It has nothing to do with participation ratio; Firefox betas have
opt-out telemetry.

63% of Firefox Beta 53 telemetry records (which Mozilla calls "pings")
say it was set as the default browser. If you deduplicate using client
ID, it turns out 46% of distinct Firefox Beta 53 clients had it set as
the default browser. Thus, for some reason users who set it as the
default browser send a more frequent telemetry than those who didn't,
perhaps because they use the browser more.

-- 
Nicolás

Re: Telemetry Policy - Remaining Questions

[Nicolás Alvarez]

2017-09-14 15:56 GMT-03:00 Albert Astals Cid :
> El dijous, 14 de setembre de 2017, a les 0:20:57 CEST, Volker Krause va
> escriure:
>> The following questions were left unanswered in the previous thread (see
>> there for the full arguments if needed):
>>
>> (1) Should we allow opt-in tracking of unique identifiers?
>>
>> This was requested by Jaroslaw, as Kexi has this right now and the policy as
>> written right now would thus conflict with it.
>
> I missed this, what's the usecase of unique id data?

Without a unique ID, each time the app sends telemetry, the record is
independent and not correlated to previous records. Generating a
random "client ID" and persisting it in some file in $HOME, and
including it in the uploaded data, lets you calculate statistics per
client, which is more useful than per telemetry record.

It's hard to know how what percentage of users users have a setting
enabled if we don't have a client ID, since some users may send more
telemetry reports than others (for multiple reasons, including using
the app more often). If we have one, we can avoid double-counting
multiple reports from the same client.

>From Mozilla documentation: "So when you say '63% of beta 53 has
Firefox set as its default browser', make sure you specify it is 63%
of *pings*, since it is only around 46% of clients. (Apparently users
with Firefox Beta 53 set as their default browser submit more
main-pings than users who don't)."

-- 
Nicolás

Re: Telemetry Policy - Remaining Questions

[Nicolás Alvarez]

2017-09-13 19:20 GMT-03:00 Volker Krause :
> (1) Should we allow opt-in tracking of unique identifiers?
>
> This was requested by Jaroslaw, as Kexi has this right now and the policy as
> written right now would thus conflict with it.

My view is that we need opt-out telemetry with unique identifiers to
get useful conclusions out, but from what I saw in the big thread I
know this is an unpopular opinion.

> (2) Should we require/allow/forbid publication of the raw data?
>
> Publication was suggested by Martin F. Practically, this would have to allow
> for a certain delay, we can't have public access to live data. Suitable
> licensing options of the data would probably be CC0 or CC-BY-SA.

FWIW, Mozilla does not publish raw data. Mozilla employees can run
custom analyses on raw data (for cases where the public aggregated
data isn't enough), but I think even them can't just look at
individual records.

(Then again, Mozilla raw data contains unique identifiers, which can
make their privacy requirements stricter)

I also wouldn't want to "require" publication of raw data for
practical/technical reasons: until we implement some minimal
pseudo-telemetry pings, we don't even know how many active users we
have, so we can't estimate what's the total volume of raw data we will
end up collecting. It may end up needing extra server resources to
store and aggregate. I wouldn't want to also make said giant raw data
publicly available. Maybe it's technically possible, but I don't want
to already require/promise that we will do it.

-- 
Nicolás

Re: Telemetry Policy

[Nicolás Alvarez]

> El 24 ago 2017, a las 07:41, Jaroslaw Staniek  escribió:
> 
>> On 24 August 2017 at 11:10, Adriaan de Groot  wrote:
>> 
>> Curiously, there's a lot of "telemetry policy" news items popping up this
>> week, for instance:
>> 
>>Mozilla ponders making telemetry opt-out, 'cos hardly anyone opted in
>> 
>> (that's on the Register) and there were others. So it looks like 
>> communication
>> -- what's the data for, why is it collected, and what can happen to it -- is
>> key here.
>> 
>> [ade]
> 
> Speaking of that please let me play devil's advocate. In Europe,
> especially Poland all web sites/web apps that collect cookies must
> obtain permission to do that from the user. Interestingly there are
> usually OK buttons only so the message is only an information.
> Sometimes there is "Don't agree" button which is equal to close the
> site. So telemetry-like behavior even lacks opt-out.
> 
> [...]
> 
> I can imagine we would make our pages work without cookies and add
> opt-in buttons to each main site.
> 
> Now KDE context since there's visible call to make privacy our pillar topic:
> 1. Does www.kde.org for example use cookies?

Yes, and we show the comply-with-Europe-law banner letting the user know about 
those cookies. We also follow the browser Do Not Track setting and we don't 
collect statistics if that is set.

-- 
Nicolás
KDE Sysadmin Team

Re: radical proposal: move IRC to Rocket.Chat

[Nicolás Alvarez]

2017-08-08 17:52 GMT-03:00 Jonathan Riddell :
> On 8 August 2017 at 19:51, Christian Loosli  wrote:
>> Out of interest: what exactly does IRC lack? There are 4 things coming to 
>> mind
>> for me, all of them with my personal opinion:
>
> Option for full names, photos of people, timezone, e-mail addresses.
> Just a few of the useful and user friendly features I see looking at
> it now.
>
> Looking at #kde-devel just now it says:
> <-- swati_27 (uid130066@gateway/web/irccloud.com/x-abaollxcgicrxgwg)
> has quit (Quit: Connection closed for inactivity)
> <-- nowrep (~david@kde/developer/drosca) has quit (Quit: Konversation
> terminated!)
> <-- stikonas (~gentoo@wesnoth/translator/stikonas) has quit (Quit:
> Konversation terminated!)
> <-- soee_ (~s...@bmi112.neoplus.adsl.tpnet.pl) has quit (Quit:
> Konversation terminated!)
> --> soee (~s...@bmi112.neoplus.adsl.tpnet.pl) has joined #kde-devel
>
> Show that to most people and they'll just not want to know what it means

True, so the IRC client needs an option to hide the hostmask.

-- 
Nicolás

Re: Kubuntu and other KDE distribution's use of KDE infrastructure

[Nicolás Alvarez]

2017-01-08 5:02 GMT-03:00 Valorie Zimmerman :
> I'm writing at the request of the sysadmins, who would like to hear
> from the community about distributions' use of KDE infra.
>
> I'm part of the Kubuntu community and will use it as the example I know best.
>
> Kubuntu has some KDE wiki pages, found at
> https://community.kde.org/Kubuntu - for which we are very grateful.
> Ubuntu has a wiki we used to use, but between the awfulness of
> MoinMoin and the spam attacks on it, we love being at home at the KDE
> wikis.
>
> For some time we've been using notes.kde.org as well, and are planning
> how to use share.kde.org now that notes is closing down. We'll need to
> set up a Kubuntu group so that all Kubuntu team members who need
> access can actually access the shares. One of the advantages of using
> KDE infra over piratepad or so, is that we can add a password if
> necessary, and share among other KDE packagers if necessary.
>
> We are also interested in having a Phab instance for Kubuntu mostly
> for the todo/workboard. Right now, we're using Trello, but would
> prefer to use Free software if possible. And the beauty of Phabricator
> is that we can keep more of our "stuff" in one place. For instance, it
> includes a wiki as well, which we might use for packaging
> documentation. Very slick to have all our packaging stuff in one
> place.
>
> However, the sysadmins would like the KDE community support for this,
> since it could be seen as a "slippery slope." In addition, Ben
> Cooksley said, "we'll need to come up with some guidelines surrounding
> what distributions can ask us for, given the Manifesto / KDE Project
> rules.
>
> I would love to see more KDE distros getting cozy with the KDE
> community because I don't like to see fighting between packagers and
> developers, and communication is key.
>
> Our Manifesto [1] says: Being part of the international KDE community
> conveys certain benefits: Make use of KDE infrastructure for
> project hosting. I've noticed that some KDE projects do not use KDE
> infra, such as bugzilla, websites, and even mail lists. I thought the
> rule was that all KDE projects would move to KDE infra, so this
> surprised me.
>
> On the other hand, groups which are associated with the community but
> will never be "KDE projects" such as KDE distros, are not mentioned in
> the Manifesto. We do already host the KDE Packagers list [2], and
> Distributions list [3] which supports the Distribution Outreach
> Program [4].
>
> What do you say? Obviously we want to support KDE distributions. Where
> do we draw the line?

This is a general reply to the thread. With my sysadmin hat on: Giving
Kubuntu a Phabricator board is easy, takes negligible server
resources, takes little sysadmin human resources. I could just go and
do it.

The problem originating this discussion is: what do we do if another
KDE-related community (could be a community packaging KDE software for
another distro, or something else entirely) asks for a Phabricator
board too; after all, we helped Kubuntu with the Phabricator thing
before, right? Then someone some little space in our download servers
for beta packages or whatever. Not much storage, not much bandwidth.
Then someone wants to use share.kde.org. Then someone wants a VM to
compile packages for their distro. Then someone else wants
significantly more download server space.

Where do we stop? We have to draw the line somewhere, but I don't know
where. Perhaps making it case-by-case could be problematic, someone
could claim it's unfair to give X to Kubuntu and not give Y to them
because in their opinion Y doesn't need much more resources than X.
Must be Kubuntu favoritism!

But perhaps I'm being paranoid, and trying to define a strict policy
ahead of time will involve even worse bikeshedding and drama, and
case-by-case is good enough.

Maybe we just should create the Kubuntu task board and defer this
issue until the next such request comes. Maybe it will never come.

-- 
Nicolás
KDE Sysadmin Team

Re: Changes to the bugzilla workflow: 2 proposals

[Nicolás Alvarez]

> El 12 dic 2016, a las 03:39, Martin Gräßlin  escribió:
> 
> Am 2016-12-11 22:35, schrieb Luigi Toscano:
>> 
>> a) use the "needinfo" flag instead of the NEEDINFO status.
>> This is implemented on various instances of bugzilla (mozilla.org, 
>> redhat.com,
>> opensuse.org) and allows the requester to set a needinfo on one or more
>> specific user.
> 
> What does it mean to the state of "Open" bugs? What I like about the RESOLVED 
> NEEDSINFO is that it hides the bugs from my search lists. If the bugs would 
> still be shown, it would completely destroy the search for me (KWin currently 
> gets 1-3 crash reports by Arch users per day).

I think you would be able to change your searches to take "doesn't have a 
'needsinfo' flag" into account.

-- 
Nicolás

Re: Calligra stable releases not in Debian stable Jessi

[Nicolás Alvarez]

2016-09-30 6:31 GMT-03:00 Jaroslaw Staniek :
>
> Dear Debian contributors,
> I am maintainer of Kexi, one of Calligra apps.
> I've just noticed that in Debian stable Jessi the recent Calligra is 2.8.5
> which is 13 releases old. There are no updates to 2.8.7, and zero updates to
> 2.9.*.
>
> 2.8.5 is a July 2014 version. Due to security and stability issues it may be
> even better *not* to have this version released at all than receiving
> reports and users thinking that's the most recent version (this is my own
> opinion).
>
> When users run, say, a Raspberry, they see that old and unsupported (by us)
> version. So here Jessi distributes this unstable software despite many
> updates being available. I don't see the same issue with MySQL for example,
> which was updated just this month. Maybe a man power issue?
>
> I have questions then:
> - what happens?
> - what can be done to fix the situation?
> - how to coordinate better?
>

Jessie is frozen, I doubt Kexi 2.9 will ever be in 'jessie'. I don't
see how MySQL is different, the latest version from upstream is
5.7.15, Jessie has 5.5.52, it was upgraded from 5.5.50 because of a
specific security fix.

See this for the criteria to get an update in stable:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

Can you mention specific security bugs that 2.8.5 has? That could
justify bringing 2.8.7 in (or backporting the security fixes).

And maybe 2.9 could be in the 'jessie-backports' repository. But I
wouldn't expect it in 'jessie'.


Of course, this is in addition to the possible lack of manpower to do
such packaging :)

-- 
Nicolás

Re: Creating a map of KDE contributors?

[Nicolás Alvarez]

> El 23 sept 2016, a las 12:12, Thomas Pfeiffer  
> escribió:
> 
>> On 20.09.2016 14:06, Luigi Toscano wrote:
>>> On Tuesday, 20 September 2016 13:42:35 CEST Thomas Pfeiffer wrote:
>>> Hi everyone,
>>> I recently realized that unless you ask fellow KDE contributors personally
>>> where they live, you don't really know where over the world (or even in
>>> your home country) KDE is spread.
>>> 
>>> [...]
>>> 
>>> So, two questions:
>>> 1. Does that make sense to you?
>> 
>> We had a "heat-map" of committers in the old commit-digest:
>> https://commit-digest.kde.org/issues/2014-11-16/
>> So yes, it makes sense.
>> 
>> Also, for example:
>> https://www.debian.org/devel/developers.loc
>> 
>>> 2. If yes: Does anyone know of a piece of code that allows people to enter
>>> their city of residence and then show people on a map (ideally as an OSM
>>> overlay), or could otherwise maybe create it?
>> 
>> If it's not for the fact that sysadmin want to replace identity, a custom
>> field there with the city and/or coordinates and some script to grab them,
>> convert into geojson, and it's really easy (read: few lines of code) to setup
>> a map with leaflet.
>> 
>> http://leafletjs.com/examples/geojson.html
> 
> If I read the documentation [1] correctly, Phabricator (which would replace 
> Identity) allows custom fields in user profiles, so we could still do that.

Note it's not yet decided if we'll replace Identity with Phabricator or if 
we'll use something else.

(I was going to throw my opinion of such a replacement here, but I realized it 
would make this thread quickly go off topic)

-- 
Nicolás

Re: KDE Licensing Policy Updates

[Nicolás Alvarez]

2016-09-20 16:53 GMT-03:00 Jaroslaw Staniek <stan...@kde.org>:
>
>
> On 20 September 2016 at 21:42, Nicolás Alvarez <nicolas.alva...@gmail.com>
> wrote:
>>
>> 2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek <stan...@kde.org>:
>> >
>> >
>> > On 20 September 2016 at 21:19, Thomas Pfeiffer <thomas.pfeif...@kde.org>
>> > wrote:
>> >>
>> >> On 20.09.2016 19:52, Nicolás Alvarez wrote:
>> >>>
>> >>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell <j...@jriddell.org>:
>> >>>>
>> >>>> Added:
>> >>>> ''Applications which are intended to be run on a server'' can be
>> >>>> licenced under the GNU AGPL 3.0 or later
>> >>>> Rationale: KDE Store code is under AGPL
>> >>>> Question: should this be an option or a requirement for server
>> >>>> software?
>> >>>
>> >>> I agree with this change, but I think it should remain an option.
>> >>
>> >>
>> >> I would support making it mandatory, actually, or at least recommended,
>> >> because for an end user a web service based on GPL software is no
>> >> better
>> >> than one based on proprietary software, because they cannot tell what
>> >> software it is they're interacting with. Therefore, the AGPL closes an
>> >> important hole in FOSS web services.
>> >>
>> >> I don't feel very strongly about this, but to me it would make sense to
>> >> at
>> >> least recommend AGPL for web software we produce.
>> >>
>> >
>> > I see that too but also aren't we also limited here in one case: when
>> > our
>> > LGPL software is usable for services? What can we do with e.g. KF5? Move
>> > it
>> > to AGPL and add linking exception?
>> >
>> > Sorry if that's already solved some way.
>>
>> AGPL code can use GPL and
>> LGPL libraries.
>
>
> Sure but that's not the challenge.
> Rather: can an AGPL library be dynamically linked to a proprietary binary?

Certainly not. AGPL is like GPL in that sense, with the extra rule
that you must publish the source code even if you're only giving
access over the network and not distributing binaries.

I don't think an AGPL library makes much sense though.

-- 
Nicolás

Re: KDE Licensing Policy Updates

[Nicolás Alvarez]

2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek <stan...@kde.org>:
>
>
> On 20 September 2016 at 21:19, Thomas Pfeiffer <thomas.pfeif...@kde.org>
> wrote:
>>
>> On 20.09.2016 19:52, Nicolás Alvarez wrote:
>>>
>>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell <j...@jriddell.org>:
>>>>
>>>> Added:
>>>> ''Applications which are intended to be run on a server'' can be
>>>> licenced under the GNU AGPL 3.0 or later
>>>> Rationale: KDE Store code is under AGPL
>>>> Question: should this be an option or a requirement for server software?
>>>
>>> I agree with this change, but I think it should remain an option.
>>
>>
>> I would support making it mandatory, actually, or at least recommended,
>> because for an end user a web service based on GPL software is no better
>> than one based on proprietary software, because they cannot tell what
>> software it is they're interacting with. Therefore, the AGPL closes an
>> important hole in FOSS web services.
>>
>> I don't feel very strongly about this, but to me it would make sense to at
>> least recommend AGPL for web software we produce.
>>
>
> I see that too but also aren't we also limited here in one case: when our
> LGPL software is usable for services? What can we do with e.g. KF5? Move it
> to AGPL and add linking exception?
>
> Sorry if that's already solved some way.

AGPL code can use GPL and LGPL libraries.

-- 
Nicolás

Re: [kde-community] please explain: Users shouldn't have to buy in into "KDE" from mission ideas

[Nicolás Alvarez]

2016-07-09 13:35 GMT-03:00 sabayon11 :
> I read on
> https://community.kde.org/KDE/Mission/Brainstorming
> "AlexN: let me put it like this: let's prioritize following the host
> OS standards. Users shouldn't have to buy in into "KDE" if they just
> want to use e.g. kate, and kate shouldn't feel out of place under OSX
> or Windows (and they are working towards that). IMO the standalone
> kate-installer for Windows is a much better approach than the
> all-integrated KDE-on-Windows appraoch."
>
> Does it mean that I will be able to install Dolphin as stand-alone
> application on other graphic environments like Xfce, Cinammon, i.e.
> without all Plasma dependences like kde-runtime, etc.?
>
> Is it going to be really possible?

We don't even *have* a kde-runtime anymore. In KDE Frameworks 5 (first
released in July 2014!), each framework includes its own runtime
components where necessary, and doesn't depend on a monolithic
kde-runtime package. So what you want has been possible for quite a
while now.

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] DigitalOcean is now a sponsor!

[Nicolás Alvarez]

They gave us free credits expiring in a year. I'm pretty sure taking them away 
halfway through would be against their own ToS. If they change sponsorship 
policies, I believe the worst that can happen is that they don't renew it when 
the credits expire. So we'll have time to move the servers elsewhere if "change 
of management" happens.

Your concern is valid, but note that the situation is nothing new. We have 
similar sponsorship from other providers.

-- 
Nicolás
KDE Sysadmin Team

> El 6 jul 2016, a las 05:47, Helio Chissini de Castro  escribió:
> 
> I'm happy because the good reputation of Digital Ocean.
> 
> But, out of curiosity, will be some formal agreement about usage and possible 
> future changes be created ?
> 
> I mean, if we move some services of our infra to Digital Ocean, and for some 
> reason they are bought from some 
> bigger company or get new management direction saying no-go, how we should 
> deal with this subtle situations ?
> 
> []'s Helio
> 
>> On Wed, Jul 6, 2016 at 10:37 AM, Boudhayan Gupta  wrote:
>> On 6 July 2016 at 13:28, Thomas Pfeiffer  wrote:
>> > On 05.07.2016 21:36, Boudhayan Gupta wrote:
>> >>
>> >> Hi Guys,
>> >>
>> >> I'm excited to announce that DigitalOcean is sponsoring the KDE
>> >> Community. Under their open source software sponsoring programme [1],
>> >> they've very kindly set us up to use computing resources free of
>> >> charge.
>> >>
>> > Awesome news! Is this sponsorship already "public" from their side
>> > (I don't see KDE on the list you linked to)?
>> > And if it is: Would they like us to keep it low-profile or talk about it?
>> > My first gut reaction would be to head over to G+ and spread the good
>> > news, but of course I'd only do that if they want us to.
>> 
>> Go ahead! We'll make an official announcement on the dot in a few
>> days, but of course we'll concentrate more on how we use the resources
>> than on the sponsorship instead.
>> 
>> Don't make it an "official KDE announcement" though. A personal post
>> saying "this is crazy awesome!" is fine.
>> 
>> > Cheers,
>> > Thomas
>> 
>> -- Boudhayan
>> ___
>> kde-community mailing list
>> kde-community@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-community
> 
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] DigitalOcean is now a sponsor!

[Nicolás Alvarez]

Sorry, I don't understand what you're asking. They simply give us
servers, what we do with them is our (KDE sysadmin) problem.

You want to run a blog on KDE infra? We have blogs.kde.org for that :)

-- 
Nicolás

2016-07-05 17:59 GMT-03:00 Tomaz Canabrava :
> This is awesome. Do you know if we will also be able to use our aggregated
> blogs running on digital ocean or just the official kde services?
>
> Em 5 de jul de 2016 16:36, "Boudhayan Gupta"  escreveu:
>>
>> Hi Guys,
>>
>> I'm excited to announce that DigitalOcean is sponsoring the KDE
>> Community. Under their open source software sponsoring programme [1],
>> they've very kindly set us up to use computing resources free of
>> charge.
>>
>> DigitalOcean's droplets give us a certain amount of flexibility, and
>> allows us to make our infrastructure more efficient. We can, for
>> example, move some of the services that use low computing resources to
>> smaller droplets at DO, freeing up our bigger physical servers for
>> more demanding tasks. Over the next few months, we'll be making
>> changes to our infrastructure to most efficiently make use of our
>> added server capacity.
>>
>> One of the things we're looking at is using a droplet hosted at
>> DigitalOcean's Bangalore datacenter to serve as mirrors for our code
>> repositories for the Asia Pacific region. Currently all our code
>> repositories and mirrors are hosted in servers across continental
>> Europe, apart from on GitHub.
>>
>> Thanks,
>> Boudhayan Gupta
>> KDE Sysadmin
>>
>> [1] https://developers.digitalocean.com/opensource/
>> ___
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Cervisia?

[Nicolás Alvarez]

> El 5 jun 2016, a las 09:08, Martin Koller  escribió:
> 
>> On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> 
>> Some i18n issues:
>> 
>> It is a QApplication so you have to add the translators tab manually with 
>> aboutData.setTranslator
> 
> ok. what shall I write there (names, emails ?)
> 
> Isn't that a limited approach to name the translators in the sourcecode, since
> every new translation added will need a source change ?

No; you use something like i18n("TRANSLATOR NAME") (I don't remember the exact 
string), so that the name comes from the translation itself.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] possible foss alternative to telegram/slack

[Nicolás Alvarez]

2016-05-20 12:22 GMT-03:00 Thomas Pfeiffer <thomas.pfeif...@kde.org>:
> On Dienstag, 17. Mai 2016 12:33:25 CEST Nicolás Alvarez wrote:
>> 2016-05-17 5:55 GMT-03:00 Marco Martin <notm...@gmail.com>:
>> > Hi all,
>> > Right now many groups are using Telegram as their primary communication
>> > medium due to some limitations in IRC (mainly due to the ease of pasting
>> > images inline the channel and the lack of fancy mobile clients for IRC),
>> > there may be other valid reasons i'm not aware of
>> > today i randomly stumbled upon
>> > http://www.mattermost.org/
>> >
>> > it seems to tick all the boxes:
>> > * open source
>> > * we can self host an instance
>> > * fancy mobile and desktop apps
>> > * inline multimedia attachments into messages
>> > * and most important for us old farts: bridge to IRC :p
>> >
>> > didn't try it, just stumbled upon it but may be something to be
>> > considered?
>>
>> There is no sane option for fancy mobile apps. You either compile your
>> own apps, get a developer account on app stores ($99 for iOS, $25 for
>> Android), get them through the app store review process, and maintain
>> them forever; or you use the official Mattermost apps that are already
>> in app stores, and pay Mattermost $20/user/year to send push
>> notifications through their servers.
>
> Are you sure about this? From what I've read on their website, only encrypted
> push notifications need a subscription, which is not necessary for talking
> about Free Software anyway, if we're being honest.
> None of our current Telegram or IRC communication is encrypted, so why would
> we need encryption for Mattermost?
> I cannot see anywhere that the Android app only works at all with a
> subscription.

Do they have such thing as "non-encrypted push notifications"?

To send a push notification to the iOS app, you need to talk to
Apple's servers using a SSL client certificate they give to the
developer. For the official app, obviously only Mattermost's servers
have that certificate. Either you proxy your notifications through
them (which apparently costs money), or you put your own app in the
store and talk to Apple directly.

If you don't do either, the app would probably still work, but you get
no notifications while the app isn't open/active.

I don't know much about Android's push notification system (GCM) but I
think it works in the exact same way.

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] possible foss alternative to telegram/slack

[Nicolás Alvarez]

2016-05-17 5:55 GMT-03:00 Marco Martin :
> Hi all,
> Right now many groups are using Telegram as their primary communication medium
> due to some limitations in IRC (mainly due to the ease of pasting images
> inline the channel and the lack of fancy mobile clients for IRC), there may be
> other valid reasons i'm not aware of
> today i randomly stumbled upon
> http://www.mattermost.org/
>
> it seems to tick all the boxes:
> * open source
> * we can self host an instance
> * fancy mobile and desktop apps
> * inline multimedia attachments into messages
> * and most important for us old farts: bridge to IRC :p
>
> didn't try it, just stumbled upon it but may be something to be considered?

There is no sane option for fancy mobile apps. You either compile your
own apps, get a developer account on app stores ($99 for iOS, $25 for
Android), get them through the app store review process, and maintain
them forever; or you use the official Mattermost apps that are already
in app stores, and pay Mattermost $20/user/year to send push
notifications through their servers.

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Problems with KDE servers

[Nicolás Alvarez]

Hello KDE,

FYI, we are currently having hardware problems with an important
server, which hosts identity.kde.org and the @kde.org email server. It
has shut down for overheating twice in 24 hours (I have seen it
briefly hit 99°C, or maybe lm-sensors just doesn't show bigger
numbers!).

Both services are *currently* working, but KDE Identity is
CPU-throttled and I may disable it at any time if needed to keep
temperature under control. That is, I'm sacrificing Identity
performance and availability to keep the mailserver running.

We will hopefully move these critical services to another server soon.

In addition, notes.kde.org is currently unavailable too; it seems to
get stuck when Identity goes down. Unfortunately I have no access to
restart it.

-- 
Nicolás
KDE Sysadmin Team
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Telegram Relay Service

[Nicolás Alvarez]

2016-05-06 10:14 GMT-03:00 Luca Beltrame :
> Il giorno Fri, 6 May 2016 17:58:46 +0530
> Boudhayan Gupta  ha scritto:
>
>> IRC relay service. We now have the capability to sync messages both
>> ways between an IRC channel and a Telegram group.
>
> I'm not too thrilled by this, to be honest. There are a number of
> objections to the use of Telegram that come to my mind, but today I'm
> not bringing up licensing. The biggest problem with Telegram is that it
> is a clearly insecure[1,2] service. And with current times, yes, it does
> matter.

...why should I care about security here? It's a public group. No
matter how bad the encryption is, it's more secure than IRC. Plus, KDE
people are using Telegram whether it's bridged to IRC or not.

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] RFC: Distribution outreach program

[Nicolás Alvarez]

> On Feb 3, 2016, at 10:16, Martin Graesslin <mgraess...@kde.org> wrote:
> 
> On Wednesday, February 3, 2016 9:44:13 AM CET Nicolás Alvarez wrote:
>>>> On Feb 1, 2016, at 15:31, Cornelius Schumacher <schumac...@kde.org> wrote:
>>>> On Monday 01 February 2016 13:04:37 Sebastian Kügler wrote:
>>>> 
>>>> I'm not against automated testing at all, I just think it doesn't work at
>>>> the highest level and bears pitfalls of distros gaming the system, or
>>>> people actually care more about the number of points they get than the
>>>> actual user experience.
>>> 
>>> I think we have to readjust the perspective here a bit. I really
>>> appreciate
>>> Thomas' initiative because there definitely could be better collaboration
>>> between distributions and KDE. We have the common goal to get our software
>>> to users in the best possible shape. We shouldn't see that as a gaming,
>>> blaming, or judging, but we should see this as an opportunity to work
>>> together in a better way. How this is then expressed to the public is a
>>> second thought, and should be decided together with the distributions.
>>> 
>>> So defining and discussing criteria which make up a good experience,
>>> listing and communicating requirements, talking to each other about what
>>> is missing, what needs to be fixed, and where it should be fixed without
>>> playing upstream- downstream-ping-pong, sharing and possibly aligning
>>> roadmaps, all these things and more could happen through the distribution
>>> outreach program. This would be really wonderful.
>>> 
>>> In essence I think this is about better communication between KDE and
>>> distributions, so that we can productively work on what needs to be fixed,
>>> avoid misunderstandings, and keep a common momentum.
>> 
>> Here is an idea that shouldn't be novel but I have yet to see mentioned.
>> 
>> If you see a distro doesn't package KDE software correctly, doesn't
>> integrate with the system, doesn't provide a good user experience for
>> whatever reason... file a bug on the distro's bug tracker. Instead of
>> putting the distro on a user-facing "they don't do things good enough"
>> list.
> 
> You haven't seen this one proposed, because it just doesn't work. Do you 
> really think nobody reports bugs about incorrectly packaged stuff? Or that we 
> don't talk to the distros? Do you know how often we get answers like "well I 
> would like to, but we have $POLICY". I could give you examples like outdated 
> Qt in Kubuntu, broken cursors on Fedora, missing Wayland in openSUSE Leap, no 
> way to suspend in Devuan, etc. etc. - I could name you a $POLICY issue for 
> each distro.
> 
> Sorry once you have done this for years, you realize this approach doesn't 
> work. Personally I'm pretty fed up with the state our software is in, in 
> various distributions. I'm sick of having to take the blame for it. This 
> approach hasn't worked, we need to look for new ways.

So we're going to shame them into complying by leaving them out of a list? 
They'll pay attention to our wiki more than to their policies? Several people 
in this thread mentioned distro policies as a reason why this won't work, in 
fact.

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] FOSDEM wrapup

[Nicolás Alvarez]

Your reply sounds like you're taking it as criticism and it's not.
It's feedback to do better next time :)

-- 
Nicolás

2016-02-03 17:52 GMT-03:00 Jonathan Riddell :
> All of your points were taken care of to a greater or lesser degree.  If it
> didn't feel like it was all covered it's because I got no help in preparing
> it.  Planning needs to start in November and last minute requests for demos
> but without machines to show it on are no use.
>
> Jonathan
>
>
> On 3 February 2016 at 19:04, Adriaan de Groot  wrote:
>>
>> On Wednesday 03 February 2016 12:58:58 Jonathan Riddell wrote:
>> > We had a good presence at FOSDEM this year.  Here's some notes while I
>> > remember.
>> >
>> > Stall:
>> > One 1 short table this year.  We had a nice setup with ODROID board +
>> > HDMI
>> > monitor (alas it wasn't a monitor which could tilt) to demo low cost
>> > computers can run Plasma.  We had my laptop for KDE neon and a Nexus 5
>> > in a
>> > stand for Plasma Phone.  a4 display stands had colour sheets describing
>> > the
>> > three projects.  Me and David brought the kit on the train (which is
>> > faffy
>> > but much easier than taking kit on a plane) with Rohan bringing his
>> > ODROID.
>>
>> Thing to remember for next year:
>>  - extra power bar (3 outlets, maybe 5)
>>  - a good charger for the phone (charging from the laptop wasn't enough to
>> keep it on all the time)
>>
>>
>> > I bought two large display banners for KDE and KDE neon which I've taken
>> > back to my house, I need to reply to e.V. treasurer about getting those
>> > paid for.  I also bought stickers for KDE (name badges and to give away)
>> > and KDE neon and have taken the spares back home.  I also bought the
>> > money
>> > box, a4 display stands, pens, tape and brought power extensions.
>>
>> The name stickers were really nice (flying Konqui) and well received. It
>> made
>> up for out lack of uniformity at the stand (like many of the other stands
>> had
>> all their peeps in the same shirt).
>>
>>
>> > We had t-shirts which Jose brought along from those left over from
>> > Akademy
>> > as well as a money box and leaflets.
>>
>> The Frameworks leaflets were really useful to hand out as a means of
>> explaining
>> "these are libraries that everyone can use in their Qt applications".
>>
>> The T-shirts were a bit of a mixed bag. Some sizes were quite
>> underrepresented. The very nice KDE India T-shirts could have sold more --
>> which you point in the sales lists.
>>
>> > Saturday sales:
>> ...
>> > We took over 300euro on the Saturday which Jose took home.
>> > Sunday we ended up with over 320euro which Jose also took along with the
>> > sales figures.
>> >
>> > Jose can you post the sales figures here and confirm the amount you're
>> > transferring to e.v.?
>>
>> Don't forget the floats added to the cash box. You may consider mine my
>> cash
>> contribution to KDE e.V. for this year.
>>
>> > Saturday party:
>> > I booked the first floor of La Paon again in Grand Place.  No sponsors
>> > this
>> > year so I took 20euro off everyone who attended.  My guess of 200euro
>> > worth
>> > of finger food seemed to work very well.
>>
>> It was a bit short of chunchy greasy bits, though. I would have liked
>> something warm (or maybe I wasn't paying attention and it all got gobbled
>> up).
>> From a social perspective, perhaps an introduction could have been held. I
>> *think* I knew everybody there, but would have liked a moment to
>> double-check.
>>
>> > We had 22 people pay for food,
>> > less than last year I think which is to be expected since it was charged
>> > for.  After food was served I used the extra money to buy an additional
>> > couple of beers for everyone.
>>
>> The best and fastest way to get served was to hand the waiter a 20 and say
>> "beer". That meant no change, no fuss, no muss. And five decent beers.
>>
>> > We had three talks in the Desktop room (more than any other project I
>> > think) which were well received, KDE neon, WikiToLearn and CMakeDaemon.
>> >
>> > A telegram group was useful to keep in contact with people throughout
>> > the
>> > weekend.
>>
>> Yes, the group was very useful. Also note:
>>
>>  - there are *two* locations in Brussels with an Ibis Hotel next to a
>> Novotel
>>  - Grand Place is very large. A better meeting spot is "in front of Le Roy
>> on
>> Grand Place"
>>  - get a hotel around La Brouckere, it's very convenient for evenings and
>> for
>> gettting to the venue.
>>
>>
>> Some things I personally think would improve the stand:
>>  - double- and triple-check who is going to be at the stand. I know this
>> is
>> hard at FOSDEM. I tried to be there a bit, and felt confusedly guilty
>> about
>> also running off to talks or to hang out with Paul.
>>  - if you're *not* at the stand, it might be better to congregate
>> elsewhere.
>> We often had a knot of KDE-branded (e.g. name-sticker) people in the
>> corner --
>> me included -- who weren't accessible because of 

Re: [kde-community] Sprint: Reorganize the wikis

[Nicolás Alvarez]

2015-12-09 17:40 GMT-03:00 Olivier Churlaud :
> So joining in CERN would be easier.
>
> I have several small questions:
>
> - In https://sprints.kde.org/sprint/participate what should we check?
> WikiToLearn?

No, Aleix said he added a new "Wiki" category :)

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

[Nicolás Alvarez]

2015-08-17 3:55 GMT-03:00 Jos van den Oever j...@vandenoever.info:

 On Monday 17 August 2015 07:46:44 Martin Graesslin wrote:
  Hi community,
 
  over the last months I observed the following:
  * people not finding our git repositories

 Searching on ixquick:
 'calligra git' https://community.kde.org/Calligra/Git
 'kde git' https://community.kde.org/Sysadmin/GitKdeOrgManual
 'kwin git' https://github.com/faho/kwin-tiling
 'plasma git' https://community.kde.org/Plasma/Active/Development

 Searching on Google:
 'calligra git' https://community.kde.org/Calligra/Building/2
 'kde git' https://techbase.kde.org/Development/Git
 'kwin git'
 http://blog.martin-graesslin.com/blog/2014/04/kwin-moved-to-an-own-repository/
 'plasma git' - https://aur.archlinux.org/packages/plasma-desktop-git/

 On google the highest link to github was in position 4. Not too bad.

 There was no link to https://projects.kde.org/ or
 https://quickgit.kde.org/

 What part of the KDE infrastructures can be fixed to make the repositories
 easier to find?


http://quickgit.kde.org/robots.txt asks search engines not to index
quickgit at all.

http://projects.kde.org/robots.txt asks search engines not to index the
repository, but the project information, news, etc. should be indexable.
See https://www.google.com/search?q=site:projects.kde.org for stuff that
does get indexed currently.

Both of these blocks were done for server performance reasons: search
engines wer crawling the hell out of dynamically-generated repository
history and bringing our servers to their knees.

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Relicensing Effort

[Nicolás Alvarez]

2015-07-26 19:01 GMT-03:00 Boudhayan Gupta m...@baloneygeek.com:
 On 27 July 2015 at 01:23, David Faure fa...@kde.org wrote:
 On Saturday 21 February 2015 11:42:52 Dominik Haumann wrote:
 Hi all,

 some time ago, a relicensing effort was started to allow us also using
 the [L]GPLv3 [1]. The linked script (I just blogged about it again [2])
 indeed helped a lot when checking Kate's source code, for instance.

 1. Please add yourself to this script, if you have not done so.

 I'm not clear about something: Doesn't gplv2+ and lgplv2+ imply gplv23
 and lgplv23 respectively? What is the difference between GPLv2 or
 later and GPLv2 or GPLv3?

 If I mark myself as gplv2+ lgplv2+ +eV, what rights am I not giving to KDE?

I see two possible interpretations:

- Maybe gplv2+ implies gplv23, so your choice is actually between no
relicensing out of v2 or gplv23: I allow v2 or v3, or gplv2+: I
allow any GPL version, and saying gplv23:no gplv2+:yes doesn't make
sense.

- Or maybe gplv23:no gplv2+:yes means you agree with KDE relicensing
to GPLv2 or *any* later version, but you don't give KDE the right to
relicense as *only* GPLv2 or v3 which would forbid eg. the GPLv4
possibility; you explicitly want GPLv4 to be allowed.

I don't know if I'm being clear :)

Can someone confirm which of the interpretations would be correct?

-- 
Nicolás
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community