Re: [kde-community] Cervisia?
On Sep 26, 2015 9:22 PM, "Jeremy Whiting" <jpwhit...@kde.org> wrote: > > Martin, > > Michael Reeves reeves...@gmail.com mentioned he would be interested in > helping also, maybe the two of you can get it ported away from > Qt3Support, then ported to Qt5/Kf5 ? > > thanks, > Jeremy > Sounds like a plan. I don't have write access to the repo. I too have limited time. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: Discourse
On Tue, Oct 30, 2018, 6:50 AM Paul Adams wrote: > On Tue, 30 Oct 2018 at 11:42, Ben Cooksley wrote: > > If you're running 10,000+ microservice instances, then you can have > > the teams of people needed to maintain the necessary overhead > > This is true. Also not your original point: you claimed that Docker > containers were generally unsuitable for production > The overhead is generally not that huge: you build, sign and upload > your images to registry you run. This is no different than when you > build, sign and upload your custom-built distro packages. > > Yes, running something like Openstack cause some additional overhead. > > > We delegate management of sites to people who look after them (where > > it makes sense) as it helps people get things done. > > They are essentially the "admin" of that specific site/service, but > > won't have root on the actual server that runs it. > > Good approach. It is by no means incompatible with running services in > a container. > You can give specific system users membership of a docker group, > allowing them to start/stop/deploy etc. You then control which > containers the user is actually allowed to manipulate in registry > config. > > Perhaps I am missing something? > Care would have to taken to insure such users can only use specific pre defined option sets. Otherwise the ability to run docker is equivalent to root access to the real file system via. --mount or --volumes. Probably other routes as well. Not hard to mitigate with the right setup. > > -- > Paul J. Adams > PhD MIEEE MBCS CITP > > GPG: 07DD 0812 Paul James Adams >
Re: Bugzilla template problems
That sounds a lot better. Even on Linux kf5!=plasma . On Thu, Oct 4, 2018, 12:19 PM Andrew Crouthamel wrote: > Why not just something generic: > > SOFTWARE/OS VERSIONS > Windows: > MacOS: > Linux/KDE Plasma: > (available in About System) > KDE Plasma Version: > KDE Frameworks Version: > Qt Version: > > Andrew Crouthamel > > ‐‐‐ Original Message ‐‐‐ > On Thursday, October 4, 2018 12:13 PM, Nate Graham wrote: > > > Can the template be overridden on a per-project basis? > > > > Nate > > > > On 10/04/2018 07:48 AM, Boudewijn Rempt wrote: > > > > > Hi, > > > This section: > > > SOFTWARE VERSIONS > > > (available in About System) > > > KDE Plasma Version: > > > KDE Frameworks Version: > > > Qt Version: > > > In the template I've never seen filled out. One problem, of course, is > that > > > it's really plasma centric. Most of my users don't use plasma, and > don't have > > > an "About System" app that shows this information. Is there are a way > to > > > reformulate this so we won't confuse our users? > > >
Re: KDE evaluating migration to GitLab
Hope it goes well kdiff3 is currently using gitlab's ci in addition to the kde ci. On Tue, Jan 15, 2019, 5:32 PM Neofytos Kolokotronis Hello everyone, > > we would like to inform all of you that a team consisting of the KDE > sysadmin, e.V. board and onboarding goal members has been in talks with > Gitlab about a possible migration of KDE from Phabricator (and perhaps > other tools that can be replaced by it) to a self-hosted GitLab CE > instance. Some further information can be found here: > https://gitlab.com/gitlab-org/gitlab-ce/issues/53206. > > We have been holding regular calls with Gitlab and the discussion has > been going very well, with GitLab being very reactive to our questions > and requests. The KDE e.V. members are kept up to date after every call. > > Thanks to the great work put in by sysadmin, we now have an initial > setup of GitLab available for testing: https://invent.kde.org/ . > > Several KDE projects are currently helping us test the implementation > and workflows. These have been chosen for being: > - Small in number of contributors involved and not having complex and > very large code repositories > - Rather active (so they can test things), but not rely heavily on > Phabricator or have regular deadlines to catch so their workflow doesn't > break > - Willing to go through the initial hurdles and help with testing and > gathering feedback. > > The results of this evaluation are meant to eventually be released to > the wider KDE community, along with a recommendation from the people > involved. Where we go from there will depend on the outcome of the > discussion this is meant to jump-start in an informed way. > > We tried to keep this under the radar until we had some solid feedback > from the testing phase. The news however broke out recently on Reddit: > 1. > > https://www.reddit.com/r/kde/comments/adnmd7/kde_is_considering_a_migration_to_gitlab/ > 2. > > https://www.reddit.com/r/linux/comments/ado2c8/kde_is_considering_a_migration_to_gitlab/ > To avoid any confusion and misunderstandings, but most importantly to > start the discussion within the wider KDE community, we thought it would > be better to communicate this in a more official way to everyone. > > If you are new to GitLab the list of available features can prove > helpful: https://about.gitlab.com/features/ > > Here are some answers to the FAQs we received so far: > - Why not use the GitLab Enterprise version? >KDE is commited to only using software under a FOSS license. > - Why a new switch? We switched to Phabricator a few years ago. >We hope that GitLab will prove to offer a variety of features that > will improve our workflow in the longt-erm and will lower the barrier > for new contributors joining us. > - Why GitLab and not another option? >We know there are other solutions available (gitea.io, sr.ht, > pagure.io to name a few) but we chose GitLab as they have been working > closely with other FOSS projects (including Debian, GNOME) and we hope > they can offer us a feature-filled solution and a great partnership > going forward. > > Feel free to ask any further questions here. > > Let's have a productive testing phase and discussion! > > Cheers, > Neofytos > on behalf of the team involved in the discussions > >
Re: Closing NEEDSINFO bugs after 30 days
I would definitely have a warning message posted when this is about to happen. I have no objection as.long is clear what information is needed. I would be inclined to do this manually even if the system doesn't. On Mon, Sep 17, 2018, 2:39 PM Scott Harvey wrote: > Can Bugzilla be configured to add boilerplate to the email that goes out > with a NEEDSINFO that reads "This bug report will be closed after 30 > days unless blah blah blah"? > > >
Re: Updated Apps Website
Why does every page contain a self referential home page link. If no homepage is provided why make this a link at all. On Wed, Jun 26, 2019, 4:35 AM Kevin Funk wrote: > On Wednesday, 5 June 2019 13:07:35 CEST Jonathan Riddell wrote: > > The new KDE Applications website is now up > > > > https://kde.org/applications/ > > > > The old one was a manual task of keeping the metadata up to date while > this > > one scans builds from build.kde.org and git in search of appstream > > appdata.xml files and converts them into the required info. > > Nice job! <3 > > Regards, > Kevin > > > Technical info at > > https://community.kde.org/KDE.org/applications > > > > If you see mistakes, go and fix them by updating the appstream files. > > These files are also used in distro packages and appstores and new > > container packages so a fix there goes a long way. > > > > https://community.kde.org/Guidelines_and_HOWTOs/AppStream > > > > Icons come from Breeze. If you see an issue with an icon I'm sure the > > Breeze folks would be happy for a fix > > https://bugs.kde.org/show_bug.cgi?id=407527 > > > > Future work is to make the content more pretty and relevant. Adding in > non > > app projects in some way. Adding in version numbers and release notes > and > > other features supported by appstream. Workboard at > > https://phabricator.kde.org/project/board/196/ > > > > KDE needs to up its game for the support it provides for our > applications, > > here's to a great future for them :) > > > > Jonathan > > > -- > Kevin Funk | kf...@kde.org | http://kfunk.org
Re: Updated Apps Website
Don't know what was happening before but it seems to fixed now. On Wed, Jun 26, 2019, 8:11 AM Michael Reeves wrote: > Why does every page contain a self referential home page link. If no > homepage is provided why make this a link at all. > > On Wed, Jun 26, 2019, 4:35 AM Kevin Funk wrote: > >> On Wednesday, 5 June 2019 13:07:35 CEST Jonathan Riddell wrote: >> > The new KDE Applications website is now up >> > >> > https://kde.org/applications/ >> > >> > The old one was a manual task of keeping the metadata up to date while >> this >> > one scans builds from build.kde.org and git in search of appstream >> > appdata.xml files and converts them into the required info. >> >> Nice job! <3 >> >> Regards, >> Kevin >> >> > Technical info at >> > https://community.kde.org/KDE.org/applications >> > >> > If you see mistakes, go and fix them by updating the appstream files. >> > These files are also used in distro packages and appstores and new >> > container packages so a fix there goes a long way. >> > >> > https://community.kde.org/Guidelines_and_HOWTOs/AppStream >> > >> > Icons come from Breeze. If you see an issue with an icon I'm sure the >> > Breeze folks would be happy for a fix >> > https://bugs.kde.org/show_bug.cgi?id=407527 >> > >> > Future work is to make the content more pretty and relevant. Adding in >> non >> > app projects in some way. Adding in version numbers and release notes >> and >> > other features supported by appstream. Workboard at >> > https://phabricator.kde.org/project/board/196/ >> > >> > KDE needs to up its game for the support it provides for our >> applications, >> > here's to a great future for them :) >> > >> > Jonathan >> >> >> -- >> Kevin Funk | kf...@kde.org | http://kfunk.org > >
Re: General Infrastructure Maintainability: API and EBN
Some of what ebn is doing in terms of linting c/c++ code would be better moved to clazy/clang-tidy plugins. The current scan for functions such open false positives for strings and comments. This is just open example of the limits imposed by not having a compilers eye view of the code. I personally don't care for having an extra place to check for errors. Clazy can run automatically on each build so warnings show up in your ide not just on some website. On Sat, Nov 9, 2019, 10:28 AM Elvis Angelaccio wrote: > > > On 09/11/19 01:33, Ben Cooksley wrote: > > Hi all, > > Hi Ben > > > > > Over the past number of years one of the tasks the Sysadmin team has > > worked on has been improving the overall maintainability of our > > systems, with a significant number of specialised cronjobs, exceptions > > and hidden linkages being eliminated. > > > > That is with one great exception: api.kde.org and ebn.kde.org. > > > > Both of these are suffering from an extreme amount of digital bitrot > > and special casing and in general are now in a condition where I > > cannot say for certain whether it would be possible to replicate the > > setup on a new system without us experiencing some degree of breakage > > (some of which we may not discover until weeks/months afterwards). > > > > In addition, the current setup relies on an old-fashioned overnight > > reprocessing of all repositories, which is inefficient and resource > > expensive. A more modern approach would have the various projects api > > documentation generated on a delayed cycle from relevant branches as > > part of something like a CI job (but not part of the actual CI > > workflow itself). > > > > For this one, i'm not certain on the best path forward at this stage, > > however the current state of affairs cannot continue. We have tried > > over the past few years to find people to work on a replacement for > > the tooling involved, but alas we've yet to have success here. > > > > Thoughts anyone? > > I'd say api.kde.org is too important to let it go. The EBN is less > important but still useful, I still see people pushing EBN-based fixes > once in a while. > > Have we ever tried to use a GSoC project to modernize either of them? If > not, would it make sense to try next year? > > > > > Regards, > > Ben > > Cheers, > Elvis > >
Re: Sysadmin Load Reduction: Subversion Infrastructure
On Sat, Nov 9, 2019, 4:21 PM Friedrich W. H. Kossebau wrote: > Am Samstag, 9. November 2019, 21:35:47 CET schrieb Ben Cooksley: > > On Sun, Nov 10, 2019 at 9:14 AM Friedrich W. H. Kossebau > > > > wrote: > > > Am Samstag, 9. November 2019, 19:16:20 CET schrieb Ben Cooksley: > > > > On Sun, Nov 10, 2019 at 6:04 AM Ingo Klöcker > wrote: > > > > > On Samstag, 9. November 2019 01:20:01 CET Ben Cooksley wrote: > > > > > > On top of this, i'd also like to remove commit access to it for > > > > > > everyone but translators and those who need to work on the small > > > > > > number of websites remaining on Subversion and only provision > this > > > > > > for > > > > > > people on an as-needed basis. > > > > > > > > > > > > In the next year or so i'd expect the remaining websites to > complete > > > > > > their migrations to Git, after which only translators would > receive > > > > > > access. > > > > > > > > > > Restricting access to the translations repository is against the > > > > > letter of > > > > > our manifesto which states > > > > > "All source materials are hosted on infrastructure available to and > > > > > writable by all KDE contributor accounts" > > > > > https://manifesto.kde.org/commitments.html > > > > > > > > > > AFAIK, "all source materials" includes translations. > > > > > > > > > > There are a few reasonable exceptions for this requirement, e.g. > for > > > > > the > > > > > sources of our websites, but I don't see a good reason for > restricting > > > > > access to the translations. > > > > > > > > > > I think restricting access to the translations will create a > precedent > > > > > for > > > > > restricting access to other source materials and undermines the > values > > > > > stated in our manifesto. Therefore, I don't think we should go down > > > > > this > > > > > route. > > > > > > > > The access isn't being *restricted* at all. > > > > It is just something you have to request be enabled separately, and > it > > > > won't be withheld from anyone with a developer account should they > > > > feel they need it. > > > > > > This is a model we also see with rights to kick off build jobs on > > > build.kde.org, and I think it does not work out: > > > having to beg for access and having to wait for access being granted > is an > > > obstacle. > > > Even more when this is nowhere documented, but a secret traded only in > > > people's minds. > > > > As a general principle, filing a Sysadmin ticket has always been the > > way to get access to systems (developer accounts being the only > > exception), and the same applies to the CI system. Hence why there is > > no explicit documentation around this. > > It stays an obstacle for everyone on first contact though. And makes one > feel > in begging position, when one should not, by ideas of the manifesto. > And often enough one needs access _now_, instead of having to hope some > sysadmin is around in the near time. > > > > So, by default there are de-facto restrictions experienced, and they > get > > > in > > > the way of developer work-flows. > > > > It's a bit unusual that a lack of access to the CI system would impact > > someone's workflow, as the CI system is supposed to automatically > > trigger itself. > > Do you have a specific scenario in mind here? > > The usual scenarios where one needs to manually trigger build jobs: > a) build metadata changed (e.g. dependencies) > b) builds failed for bko-internal issues > c) branches changed, need manual first-run trigger > > All things normal developers want or need to do once in a while, if they > care > for their project on KDE CI. > > > > My 2 cent on this matter when it comes to conditions decided about. > > > > > > Otherwise, thanks for all the admin work you are doing here once again > :) > > > > > > Cheers > > > Friedrich, who only an hour ago had to help someone kicking off builds > > > jobs on CI, as he once got the access granted after poking a few times > > > informally... > > Fortunately switching to Gitlab CI will resolve that specific scenario > > (needing the DSL Job run when a release is being made) as the DSL Job > > will be rendered unnecessary. > > "When a release is being made" should mean, when a new stabe branch has > been > created, I guess? That would be an improvement. Still leaves scenarios a) > & b). > > Cheers > Friedrich > > > As far as b) goes I had just this scenario with kdiff3 on the new gitlab > ci. I was able to manually restart the job without sysadmin intervention. > It's even possible to have gitlab automatically retry for such errors. > That's what I have done for kdiff3.
Re: Trying to reach out the maintainer of kde-servicemenus-rootactions
I have some local patches on my machine that revive dolphin and Kate compatibility for 19.04+. On Sat, Dec 7, 2019, 8:16 AM Clemens Toennies wrote: > Hi Shinjo, > > what imdeed seems to be odd is that it looks like there's no real source > repository for this. Even AUR seems to be using a "clone" git repo where > they put the code: > https://aur.archlinux.org/packages/kde-servicemenus-rootactions/ > > Maybe one idea is to add a new repo on KDE and continue development / > translations if the current author is on hiatus, then add it back as new > entry to the store with also pointing to the original. > > Greetings, Clemens. > On Dec 3, 2019 22:53, "Shinjo Park" wrote: > >> Hi all, >> >> Recently one of Korean translator had reached me for the upstram >> inclusion of >> Korean translation of root actions servicemenu [1]. Tried to contact the >> author directly but all the known email addresses got bounced back, so >> asked >> me for some help. Even from my sight, I couldn't easily locate the >> repository >> and the author's comment there seems to be stopped in the last year. Can >> anyone help us regarding upstreaming the translation? >> >> [1] https://store.kde.org/p/998469/ >> >> Best regards, >> Shinjo >> >> >>
SPDX License Headers (for Kdiff3)
I would like to SPDX headers for kdiff3 going forward. Currently there three different header formats in use. There only two licenses involved GPLv2+ and BSD two clause. I am mainly concerned with the GPLv2+ headers which are bulky and generate false email tag warnings on ebn.
Re: Information regarding upcoming Gitlab Migration
On Wed, Apr 29, 2020, 10:19 AM Boudewijn Rempt wrote: > 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: > Not sure what your referring to but kdiff3 has a workboard setup that is not group level. I'll have another look at how this is setup. > > > - 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. > > -- > https://www.valdyas.org | https://www.krita.org > > >
Re: Information regarding upcoming Gitlab Migration
If your looking for an example of a project/repo level workboard look here. https://invent.kde.org/kde/kdiff3/-/boards. Just did a quick check this is indeed specific to kdiff3. Labels can also be created at this level. The board is completely customizable. On Wed, Apr 29, 2020, 11:21 AM Michael Reeves wrote: > > > On Wed, Apr 29, 2020, 10:19 AM Boudewijn Rempt wrote: > >> 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: >> > > Not sure what your referring to but kdiff3 has a workboard setup that is > not group level. I'll have another look at how this is setup. > > > >> > - 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. >> >> -- >> https://www.valdyas.org | https://www.krita.org >> >> >>
Re: Announcing MyKDE
Anything supporting TOTP should work. That's the protocol underlying Google Authenticator. On android Google's app is the most instantly recognizable for must people. In fact its pre-installed on some phones. On Sat, Oct 3, 2020, 8:56 AM Raghavendra Kamath wrote: > Hi Shinjo, > > On Saturday, 3 October, 2020 3:40:16 PM IST Shinjo Park wrote: > > Just my 2 cents, on the 2FA registration page I wish there should be > tools > > other than Google Authenticator listed. Not only tools for other platform > > (e.g. Plasma Mobile - do we have one? Sailfish, iOS, ...) but also F/OSS > in > > Android. At least there is Aegis [1] on F-Droid which seems to be an > > actively developed free replacement of Google Authenticator. > > I used Andotp [1] and it worked. It is Free software and is available in > fdroid for android devices. > > Thank you > > [1] https://f-droid.org/en/packages/org.shadowice.flocke.andotp/ > > -- > Raghavendra Kamath > > > >
Re: KDE Apps name trademarks
On Wed, Jul 22, 2020, 4:01 AM Ben Cooksley wrote: > On Wed, Jul 22, 2020 at 7:16 AM Albert Vaca Cintora > wrote: > > > > > > > But if there are situations where third parties are living off our > good name, > > > we should fight this. We already have the rights to do so. > > > > Should we? Isn't that the same that RedHat, SUSE, Canonical, etc. do? > What's wrong with charging for our apps as a distributor? > > There isn't anything wrong with charging for our applications as a > distributor. > > The potential problem arises if they portray themselves as an > 'official' version, which is a label only we can provide. > It is especially problematic if the binary they've packaged contains > malware or other alterations that have a negative impact on the user > experience, which users will attribute to us, not the distributor of > the software. > > The situation with Redhat/SUSE/Canonical is also slightly different, > as we already have an established relationship with all three of > those. This includes them receiving early access to our releases along > with them being subscribed to our security pre-announce service. > > In this case, the vendor in question has not made contact in any form with > us. > Just quick note the version of kdiff3 on the windows store carries the old icon. This seems to imply it was made before kdiff3 joined kde. Like during the 4 year lapse of maintainership. Let's make sure we have all the facts here. > > Cheers, > Ben >
Re: KDE Apps name trademarks
As current maintainer of kdiff3 I would oppose trade mark enforce ment. Unless we have clear proof this is an altered version. I am perpared to push out my own free download if noone in this community wants the job. That will end the current problem quite nicely. On Thu, Jul 9, 2020, 10:27 AM Jack wrote: > On 7/9/20 9:48 AM, Christoph Cullmann wrote: > > On 2020-07-09 14:18, Jonathan Riddell wrote: > >> On Thu, 9 Jul 2020 at 12:29, Christoph Cullmann > >> wrote: > >> > >>> You might be able to do that, but as soon as you start to try to > >>> keep > >>> people > >>> from using the names, the cost-free, bureaucracy-free and layer free > >>> > >>> zone ends. > >> > >> Sending an e-mail to the Microsoft store doesn't need to cost > >> anything, and it would have more effect if there can be a claim of > >> trademark. Claiming copyright infringement as discussed on this > >> thread is also sensible but it does need more work and will need at > >> least the cost of buying kdiff3 from their store. > > > > Hi, > > > > sending just a mail will for sure not be enough, as the license allows > > anybody to upload our stuff there. > > > > You can start to claim that the name is trademarked but then this will > > only work if the other party doesn't claim it is not or that we don't > > have > > a policy that forbids to upload something with that name + get money > > for it. > I think the suggestion of a letter to Microsoft was about the potential > copyright violation, not about trademark. They could confirm whether or > not there is an offer of source code within the package without having > to buy it. >
Re: KDE Apps name trademarks
For kdiff3 this would be a starting point. https://phabricator.kde.org/T9580 On Wed, Jul 8, 2020, 2:34 PM Martin Floeser wrote: > Am 2020-07-08 18:12, schrieb Jonathan Riddell: > > 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. > > Honestly I don't think we should try to get software from Microsoft > Store based on trademark. As you already notice our license allows this. > And even more on Linux it's the normal way that someone else distributes > our software. Back in the days SuSE even sold our software. It's even > common that our distributors apply patches to our software. So we > shouldn't treat the Microsoft Store different to Linux distributions. > > Granted I consider it as a huge problem that the Microsoft Store might > contain copies of our software with malware. But to that we have > solutions: the GPL. We can demand the source code from those > distributors. If they don't comply: even better, than we have something! > If they comply and our software is reproducible, we can verify that the > uploaded binary is not tampered with (and that it doesn't comply to > GPL). Yes, that puts work on our shoulders. If our software doesn't > build reproducible, we need to fix that. > > Otherwise I suggest that we bring all our software in the Microsoft > Store to ensure we at least uploaded it. If we have it uploaded and > someone else uploads it as well, we can still ask Microsoft to do > something about it. I hope that Microsoft is interested in not > distributing malware and removes copies of open source projects or adds > links to the original authors. After all Microsoft really tries to be on > the good side currently, so we should try ;-) > > Cheers > Martin >
Re: KDiff3 release
On Mon, May 3, 2021, 2:02 PM Ben Cooksley wrote: > On Tue, May 4, 2021 at 12:51 AM Carl Schwan wrote: > >> Le lundi, mai 3, 2021 2:30 PM, Adriaan de Groot a écrit : >> >> > On Monday, 3 May 2021 13:00:11 CEST kde-announce-apps-requ...@kde.org >> wrote: >> > >> > > 1. KDiff3 1.9.0 released (Michael Reeves) >> > > >> > > From: Michael Reeves reeves...@gmail.com >> > > KDiff3 1.9.0 is now released. >> > > It can be found at https://download.kde.org/stable/kdiff3/ >> > > kdiff3-1.9.0.tar.xz.mirrorlist >> > >> > Yay! This reached our (FreeBSD) packaging yesterday because the >> tarballs went >> > up on the download site. It leaves me slightly scratching my head, >> because >> > of inconsistencies -- that's why I'm CC'ing kde-community, where "All >> about >> > the Apps" is a KDE goal topic and it's good to get more exposure. >> > >> > > Partial Change log: >> > >> > So, KDiff3 is not part of the KDE Gear process. That's cool -- that's >> why we >> > get separate release announcements for it :) >> > >> > I see there's a tag on invent, but no GitLab-style release. Have you >> > considered doing those as well? It's one way of making release notes >> easier to >> > find (not just hidden on a mailing list like this one). >> >> This might sound like a good idea but isn't one. The gitlab-style release >> has >> the problem that they don't include the translations and the solution is >> to add >> a link to the actual tarball. But this also creates confusion because >> then there >> are two tarballs with different content for the same release. :( There >> are some >> ideas on how to fix it and I think the localization team would appreciate >> a helping >> hand (or two). See https://phabricator.kde.org/T13519 > > > Gitlab now supports creating a release from an existing tag, so it is now > possible for us to add translations as part of the tagging process and have > them picked up in a Gitlab-style release (I believe this is what David does > for Frameworks already) > How would this work for extragrear? > > >> >> >> > The AppData release info was bumped, but only on the release branch; >> that >> > means that KDE's apps pages (e.g. https://apps.kde.org/kdiff3/) still >> show >> > outdated information. >> >> While at it, it's also a good practice to add a link to the announcement >> and >> some data like links to the tarballs/exe/appimage/... The appstream >> documentation has more info >> about it: >> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases >> >> apps.kde.org will show most of the optional information if available. >> I'm looking >> into making this release information also available as RSS feeds. It's >> also available >> as part of the apps.kde.org semi-public API: >> https://apps.kde.org/appdata/org.kde.kontrast.json >> >> While at it I would like to point out to >> https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge_requests/3 >> , >> since the AppStream updater used by the release service removes this >> precious >> information and this is why I stopped adding them to Kontrast AppStream >> file :( >> >> > >> > I'm a bit confused by the (AppData) "homepage" URL, since that leads >> round- >> > aboutly to the apps page; I think my confusion is because that URL is >> shown as >> > "project homepage" on apps.kde.org, but doesn't effectively do >> anything. (So >> > it's more a website-generator confusion than about your specific app) >> >> Yeah, this is a problem on the website generator side. If someone is >> interested >> to fix it, it probably just needs to add some if condition here: >> >> https://invent.kde.org/websites/apps-kde-org/-/blob/master/layouts/applications/single.html#L225 >> >> This documentation might help you: https://gohugo.io/functions/in/. >> Patch welcome :D >> >> > Hopefully my comments & questions can lead to better releases for all, >> both >> > Gear and independents without saddling you with any additional work. >> > >> > [ade] >> >> >> > Cheers, > Ben >
Re: Proposal unify back our release schedules
For the same reason they are sometimes seen as convenient this type of container format can be a pain when a security patch or bug fix needs to be propagated to every app that uses a library on an individual basis. Also some app image formats like flatpak are very restrictive by default on what they allow an app to do. Something to think about as we will get bugs related to that if app images become the primary distribution mechanism. Apr 24, 2024 1:56:30 PM Martin Flöser : > Am Freitag, 19. April 2024, 11:04:33 CEST schrieb Carl Schwan: >> Currently this is just a proposal, not a vote proposal or anything like >> that. I'll be happy to receive positive or negative feedback on this idea. > > Reading through the proposal and the discussion, I think we need to think a > little bit outside of the box. I have the feeling that most devs still see > Linux distributions as the primary way to distribute our software. I do not > think that this is universal true anymore and if we move away from it, this > would open up way new possibilities. > > Let's assume for apps we see Flathub/Snaps/Windows Store/whatever store as our > primary distribution channel, this would give us quite some advantages: > > * less duplicated work for distributions > * no problems with "this framework release is not packaged yet" > * no overwhelmed work for distributions due to too many packages need to be > updated > * no need to push an update if nothing changed > * no random "this pulls in KDE" due to incorrect packaging > * always up to date software for our users > * no bad experience due to missing (optional) dependencies > * easy release for the maintainers without needing a release team (what about > a Gitlab create release pipeline the maintainer can press) > > So this would totally open up a new way to release and distribute "Gear". And > with Gear being easily available for everyone this would also give the > possibility to move things into Plasma which belong into Plasma, but haven't > been for "this is an app and also usable on other desktop". What comes in my > mind is everything that are essential apps for a decent desktop experience: > > * dolphin > * spectacle > * an image viewer (gwenview/koko, etc.) > * okular > * ... > > Those could still be apps, but be released together with Plasma, thus also > tightly integrate with Plasma while at the same time be distributed through > other channels. > > Such a model should also help with the development experience. I read a few > comments about it being a problem on depending on frameworks master - I agree > that is a problem. But not so much if there is always an up to date > development container available to pull and hack on. If apps are > containerized, their build environment can also be containerized. > > So my suggestion: think about more than just the release cycle and the > alignment of the releases if you are going to touch this (hot) topic. > > Cheers > Martin signature.asc Description: PGP signature
Re: Qt goes "commercial only! - what now?
Really this is just eol for qt5. On Thu, Jan 7, 2021, 4:55 AM Mathias Homann wrote: > Hi, > > https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/ > https://bugreports.qt.io/browse/QTQAINFRA-4121 > https://lists.qt-project.org/pipermail/development/2021-January/040799.html > > ...what is that going to mean for KDE/Plasma? > > Cheers > MH > -- > Mathias Homann > mathias.hom...@opensuse.org > OBS: lemmy04 > Jabber (XMPP): le...@tuxonline.tech > IRC: [Lemmy] on freenode and ircnet (bouncer active) > telegram: https://telegram.me/lemmy98 > keybase: https://keybase.io/lemmy > gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Re: Retiring Phabricator - Migrating tasks to Gitlab
What's the plan for sys admin tickets currently needed to publish releases? May 26, 2023 5:10:43 PM Ben Cooksley : > On Fri, May 26, 2023 at 9:31 AM Nate Graham wrote: >> On 5/23/23 03:48, Ben Cooksley wrote:> Also, in Phabricator, Tasks >> have no real "home"; they just have project >>> tags, and they can have multiple such tags to be able to belong to >>> multiple projects. For example "VDG" and also "Plasma". Such a Task >>> shows up in both projects' workboards. But in GitLab, Issues need to >>> live in one place and only one place. So for such Phab tasks, we would >>> need a way to determine the single new home of the Task in GitLab, and >>> perhaps tag them with global-scope labels or something? >>> >>> >>> Yes, we would need to do a deconflicting process there. >>> Any thoughts on the best approach to that? >> >> At least in the case where a Task is tagged with VDG and also something >> else, it probably makes sense to have it live on GitLab in the >> "something else" project/group/etc. Back in the Phab days, we used to >> tag everything VDG-relevant with the VDG tag, but on Gitlab it probably >> makes more sense to just CC the "@teams/vdg" group instead. > > Excellent, sounds like we've got a path forward then. > > I will look at publishing a list of projects this weekend (separate thread) > so people can nominate the project that should receive those issues. > Note that if existing projects don't really fit (because it is for a > collection of projects) we may want to consider use of something like was > setup for KF6 (https://invent.kde.org/teams/frameworks-devs/kf6-workboard for > instance) > >> >> Nate > > Cheers, > Ben signature.asc Description: PGP signature
