Re: RFC: Theming and styles of KDE applications
On Sun, May 5, 2024 at 8:37 AM wrote: > On 2024-05-04 21:56, Akseli Lahtinen wrote: > > On Saturday 4 May 2024 14:47:35 GMT+3 christ...@cullmann.io wrote: > >> My proposal: we enforce Breeze as icon set and style everywhere. And > >> we > >> provide still a way to overwrite that for the user, but if the user > >> didn't set something manually, idenpendent what the system propose, > >> we > >> just use Breeze. And we depend on that as dep e.g. in Kate, if you > >> install Kate, that icon set and theme is installed. > > > > +1. For me as someone who changes icons sometimes just to see and > > tinker > > around, > > i think this makes sense. We have reliable fallback, but we still allow > > users to customize things which is, well, our thing! :) > > > > And if the custom icons break i do not end up with broken apps, so > > i really do not see any downside here, as user or dev perspective. > > Yes, if some user switches a theme or style in our system settings > or in the application (like we do it with the color scheme switcher some > applications like Kate have) that is fine. > > But beside that, we should just force our default style and icon set, > like we do on Windows and macOS already, that will even make some > patches > and ifdef's useless we need now to sprinkle in all apps we really > support on > these platforms. > Definitely agree with this, having to add special handling to every application to get a good experience on that platform is not ideal. Having our Frameworks handle this in one place, with a consistent approach, will overall improve the quality of the experience users get with our software outside of a Plasma desktop environment (and reduce developer porting workload) - and might help break some of the age-old stigma that KDE apps have to be used with a KDE desktop environment. > > Greetings > Christoph > Cheers, Ben > > > > > - Akseli > > > > ps. I am bad with mailing lists, lets hope this sends to right place > > lol >
Mailing list unsubscription incident
Hi all, It has been brought to Sysadmin's attention that a number of subscribers to the konsole-devel mailing list were automatically unsubscribed from the list in the past few days. This was an action taken correctly by the system, albeit in error due to a number of badly formed emails that were sent to the list. These badly formed emails originated from KDE Bugzilla, and ended up being badly formed as a result of a user with a uniquely formatted name that contained a JSON string that was improperly handled by Bugzilla. The users name has now been expunged from their Bugzilla account to avoid continued repeats of this incident. If someone who has a degree of expertise with Perl (and familiarity with it's Email modules in particular, as the bug appears to be within those) and would like to assist with correcting this please contact Sysadmin. In the long term we expect this issue to be resolved as part of work Bugzilla upstream are currently doing (see https://www.bugzilla.org/blog/2023/08/26/bugzilla-celebrates-25-years/) Thanks, Ben
Please cleanup old forks
Hi all, As part of routine maintenance on Invent (Gitlab) i've been reviewing the total amount of space currently being consumed by repositories. At this time, the top 100 largest repositories on Invent (we have 14,000 or so for context) are consuming around 21% of the total space. It would therefore be good if we could please clean this up. To add a bit of context, we currently have around 140GB of repositories, and a further 30GB of pooled repository data (shared among the canonical repository and it's forks). Those top 100 repositories currently use 30GB of space - so as much as all of the pools. Forks of KDevelop and docs-krita-org feature heavily on the list of large repositories. Of particular interest are old forks (created more than 2-3 years ago) as these are often not participating in Gitlab's mechanism to reduce the disk space taken by forks (known as pool repositories). As an additional note: please do not fork a fork, as these forks-of-forks cannot participate in a pool and must carry a full copy of the upstream repository data. If you have a situation where a network of forks of forks has developed please consider options to resolve this. I know Krita at least has this situation presently with their fork of various parts of Qt that is being maintained in people's personal namespaces. Thanks, Ben
Re: Proposal unify back our release schedules
On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens wrote: > Hello, > > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote: > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > > > The example you give shows Plasma depending on Gear, this shouldn't > > > > happen, so > > > > I'd argue: let's fix that instead. > > > > In my opinion the same goes for Gear depending on Plasma. > > Agreed, just didn't want to muddy my message and so focused on only one > direction. But it's definitely a topic to explore as well. > > One thing I'm unsure for instance is: do we want to make Gear -> Plasma > dependencies completely forbidden? > > We might consider this going one step too far. I could understand if a > Gear > app wants to provide "more integration" in a Plasma session. So mandatory > Gear > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less > certain. > I've considered whether it was feasible to ban such dependencies in the past, however always ended up in the position that it wasn't feasible to do so. This will require a degree of projects being moved around, code being broken out into separate modules, etc. but I think it is solvable given enough commitment to do so. We probably need a home for "not quite Frameworks but shared libraries none the less" to make this achievable. The usual tripping points ended up being: - Various graphics and multimedia libraries such as libkdcraw, libkexiv2, etc - Various PIM libraries, often related to Akonadi integration for Workspace - Components of Workspace that were sitting over in Gear, such as Baloo (which shouldn't be used anywhere outside Plasma - yet is heavily integrated in Dolphin, which arguably really belongs in Plasma not Gear as well) - Applications that published components and libraries that were reusable by others such as Marble, Kompare and Okteta. - Addon collections that due to shared D-Bus interfaces ended up being both build and runtime dependencies (less so now, but kio-extras sits in this territory to a certain extent) - Components of Workspace, such as KSysguard that provide libraries whose functionality is used I'm not sure where KWin sits these days, but it's hard (and I mean very hard) dependency on KWindowSystem within Frameworks was a source of quite a bit of trouble in the past. Dolphin is a serial offender in the same department when it comes to KIO - it has a similarly hard dependency. > > > > > > * We currently don't have a stable branch for Framework and it > takes > > > > > often > > > > > up to one month for fixes to be deployed. The Framework releases is > > > > > also > > > > > not in sync with either Gear nor Plasma while these two modules > > > > > heavily > > > > > make use of Framework and contribute to Framework. > > > > > > Changing the Frameworks release cadence away from monthly isn't going > to > > > get fixes out any faster - as if you are using distribution packages it > > > still has to be packaged. > > > If anything it will make them take longer as the Frameworks release > would > > > end up being every couple of months instead of monthly? (you can always > > > build Frameworks locally if you need the fixes now) > > > > For (non-rolling) distributions that update packages on patch releases > but > > not on minor releases it would make a difference if there where patch > > releases of Frameworks. Not all distributions can follow and backport > > important fixes in Frameworks. At worst, users will have to suffer a bug > in > > Frameworks until the next LTS release. > > > > Regards, > > Ingo > -- > Kevin Ottens, http://ervin.ipsquad.net > > enioka Haute Couture - proud supporting member of KDE > https://hc.enioka.com/en Cheers, Ben
Re: Proposal unify back our release schedules
On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > Hello, > Hi all, > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker > here I > think. I'll try to add a couple of extra aspects to feed the thinking on > this > topic. > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > I know this might be a controversial idea, but I would like to propose > > reunify our release schedules. I feel like splitting our releases > schedules > > between Frameworks, Plasma and Gear is not working as well as we intended > > it to be when we split the releases schedules for Plasma 5. This is for > > multiple reasons: > > > > * We end up with 3 different products which are released at different > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package > from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues > which > need to be solved. > > The example you give shows Plasma depending on Gear, this shouldn't > happen, so > I'd argue: let's fix that instead. > Further cutting these links would be quite beneficial from a CI perspective, so i'm definitely in favour of this. Some of the most complicated bits of maintaining the system involve the interconnections between Gear / Plasma / Independent. Unfortunately libplasma / kpipewire / plasma-activities will be fairly hard to avoid if you're targeting certain types of integration. > > Aligning the release schedules would only hide such structural issues. > > This was one of the main engineering motives to split things up: when it > wasn't splitted this would stay hidden much longer everyone being comfy > with > it. > > Now it's creating pain: perfect, that makes the issue obvious, but it > should > be addressed not masked. > > This is in part what Volker highlighted pointing out this should be less > of a > problem with key components being moved to Plasma. Again, if there are > more, > let's just address them. > > So as pointed out by Sune and Volker: this is a feature (at least in the > Frameworks case) not a bug. > > > * This results in very frequent releases which creates a lot of work for > > distros and talking with some distro maintainers they seems to agree that > > having a big releases every 4 months is better than having constantly a > new > > minor or major release from either Framework, Gear or Plasma. > > This is a downstream relationship topic in this case. > > I'm honestly unsure where the problem is though. They could decide to pick > a > set of version for the three and focus on that. They don't have and never > had > to package every single version of KDE Frameworks. > > That being said it indicates to me that we're not good at communicating > which > KDE Frameworks version a given Plasma or Gear release targets. More > coordination and communication here would make sense. > > * We currently don't have a stable branch for Framework and it takes > often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > Changing the Frameworks release cadence away from monthly isn't going to get fixes out any faster - as if you are using distribution packages it still has to be packaged. If anything it will make them take longer as the Frameworks release would end up being every couple of months instead of monthly? (you can always build Frameworks locally if you need the fixes now) I should note that due to a combination of Gitlab configuration and various projects essentially having a hard dependency on Frameworks master (Plasma, Dolphin, looking at both of you) the CI system always supplies Frameworks master regardless of what is being built (the Gitlab configuration is fixable, but there isn't much motivation to do so when it will just cause issues and not be used) > > This is a QA and testing topic in this case. > > The intent is that master is the stable branch (as Luigi pointed out). If > it's > not stable in practice we're failing on testing on QA. So extra automated > tests, more QA and so on should be provided. Yes this is work but it has a > chance of increasing quality, changing the release cadence won't do > anything > about it. > > * We could have an unified LTS release including more than just Plasma. > This > > is something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps is > > not that helpful. > > This is a
Linking to Gitlab CD build results
Hi all, For those that have been experimenting with the Craft Continuous Delivery jobs on Gitlab, one of the many questions we've been receiving is how to best link to those from your websites. I'm happy to advise that going forward build results will now be published for release branches on mainline repositories at https://cdn.kde.org/ci-builds/. This location is fully scalable and can be freely linked to for the purpose of offering downloads of nightly builds of your projects. One key thing to note is that because Craft includes an incrementing number in the filename, you should link to the appropriate folder not the artifact directly. Additionally, please note that any slashes in branch names will be converted into dashes as part of the publishing process. Because this service is only available for release branches and master on mainline repositories, builds from personal forks, or from work branches on our mainline repositories will not be published here. Please note that this is not a home for permanent release builds. On making a release projects should download the latest build results (either from Gitlab directly or from cdn.kde.org/ci-builds/), validate them and then release them the same as any other tarball artifact. Older builds may be removed from cdn.kde.org/ci-builds/ on a periodic basis. With regards to Android and Flatpak, those will not be covered by those service. For Android builds, usage of our F-Droid repositories (at https://cdn.kde.org/android/) is recommended, while for Flatpak it is recommended to make use of the Flatpak repositories we publish at https://cdn.kde.org/flatpak/. These mechanisms are being preferred for these two as they are native to those two platforms (while Linux appimages, Windows installers and macOS images do not have those delivery mechanisms available). Thanks, Ben
Re: New blogs.kde.org website
On Mon, Mar 4, 2024 at 10:07 PM David Redondo wrote: > Am Sonntag, 3. März 2024, 13:27:56 CET schrieb Carl Schwan: > > Hello, > > > > The blogs.kde.org which was powered by Drupal previously was switched > to Hugo > > this week. This is mostly relevant to the people using or interested to > use > > blogs.kde.org for their blogging need. I wrote a bit more info about > this > > here: https://blogs.kde.org/2024/03/03/new-blogs.kde.org/ > > > > Happy blogging, > > Carl > > > > Cool stuff. I think we should finally redirect blogs.kde.org to > planet.kde.org in order to only have one entry point for KDE blogs. > I'm afraid that is not possible - blogs.kde.org provides hosting for people's blogs using Hugo and therefore cannot be redirected to planet.kde.org. > > David > > Cheers, Ben
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 11:35 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > > > Fair point, no sw is bugless. Although, from my shallow experience WINE > seems to have an excellent test suite. I remember reporting a regression > once, which turned out to be due to some obscure surfaces manipulation by > an old Heroes Ⅲ game. WINE devs not only quickly fixed that, but they also > added tests for that case, so I'd presume such regression is just not gonna > happen anymore. > > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > > > No idea, I saw their commentary on debugging issues they were having in > their unit tests in #kde-devel. > Those issues were due to a lack of permissions, specifically around the > interactive console - that is how I know some of our tests need those > additional permissions and why running as a scheduled task / system service > will not be sufficient for "fully working" CI tests on Windows. > > > Sorry, it seems there's some misunderstanding… Judging by what you say you > seem to be referring to the restrictions that Windows containers have on > Windows. But that was the point that started this thread, to which I > replied that running Linux containers with WINE might be a solution > What i'm referring to here is that KDE Connect interacts with various components of the system in order to do what it does. See for instance the ability to share Notifications between devices, or ability to act as a presenter device. That requires accessing various system level APIs which WINE very well may not support - and we wouldn't support a scenario of using it under WINE because there is a native Linux version already. > > Plus, we have to have native Windows to compile things anyway
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > No idea, I saw their commentary on debugging issues they were having in their unit tests in #kde-devel. Those issues were due to a lack of permissions, specifically around the interactive console - that is how I know some of our tests need those additional permissions and why running as a scheduled task / system service will not be sufficient for "fully working" CI tests on Windows. > > Plus, we have to have native Windows to compile things anyway as we need > to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be > built with MingW) > > > But I presume it can be built with Clang? In particular, Google Chrome on > Windows is being built with Clang — and Web Engine is basically a fork of > Chromium. > Qt 6 as a whole does not list Clang as a supported compiler - see https://doc.qt.io/qt-6/supported-platforms.html Given Windows is a bit strange in the first place, i'd be quite reluctant to step outside of what they list as supported. > > (and you cannot really mix MingW / MSVC binaries due to incompatible > compiler ABIs for C++ code) > > > Well, if for testing purposes Qt was pre-built with Clang, I guess there > won't be any ABI issues. > Would require that everything else we have is rebuilt, and that all downstream users of our Craft cache also switch to Clang. Note that like most open source projects, we don't know the full extent to which Craft is used outside of our own project. Historically we have seen through Microsoft provided data that dependencies which we built and signed have shown up in surprising places (such as Snoretoast - which was used by something Node.js based at one point or another I believe) Cheers, Ben
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 9:21 PM Volker Krause wrote: > On Saturday, 24 February 2024 04:31:49 CET Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > > On 2024-02-22, Nate Graham wrote: > > > > I've started pondering post-megarelease projects. We've spent so > long on > > > > porting and bugfixing that I think it might be useful to shift gears > to > > > > feature work, and I'd like to brainstorm potential large-scale > projects > > > > and gauge the level of interest in putting resources into them soon. > > > > > > A bit more from the devops end that I'd love to see people tackle: > > > - Ensure frameworks and app unit tests interacting with windows can > run > > > > > >on Windows. > > >More details: The following fails on our windows CI > > > > https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp > > >I find it weird that we are spending resources on putting things in > > >the windows store and making apps available on windows, but we can't > > >actually have passing tests in our CI. > > > > This unfortunately will not be easy to solve. > > And that's fine, we are in dreaming territory here anyway :) > > > One of the key things that we've learned out of doing CI, as has been > > showcased by FreeBSD in particular, is that the builders need to be > > ephemeral - that is only around for the build in question that is being > run. > > We're currently accomplishing this by using containers - via Podman (for > > Linux/Android/FreeBSD) and Docker (for Windows). > > > > Containers also offer us the advantage of allowing people to easily > > reproduce the CI environment on their local system without too much > trouble. > > > > For Windows however, Microsoft has limited the container stack to not > allow > > anything GUI related to work. The underlying libraries may be there, but > > the equivalent display server components are not operational. > > > > To complicate things further, on Windows certain permissions are > restricted > > to the interactive console and are not possible to do as either a > scheduled > > task or as a system service. > > Usage of existing Windows automation frameworks such as Powershell > Remoting > > or SSH will therefore not work if we want things to perfectly replicate a > > end user environment - because those will run the command(s) as part of a > > non-interactive session (even if the user we connect as is the same one > > logged in on the desktop console). > > > > Resolving this will therefore not only require running full sized Windows > > VMs (on an ephemeral basis to avoid the recently resolved issues that > used > > to plague FreeBSD), but would also need the VM to automatically login and > > spawn an agent as part of the interactive desktop session that we would > > connect to in order to run the CI tests. > > > > The spawning of a VM would require refactoring the setup of our poor CI > > workers (again - after they were only just recently completely rebuilt to > > allow the transition to Podman to fix flatpak-builder) to make use of > > something like: > > - > > > https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-l > > ibvirt/72713/5 - > > https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html > > > > We would still have to write the agent that receives our commands > > (something like > > https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) > > > > We would still have to solve the issue of how to share disk images among > > our nodes so they were built (ideally would be able to use Gitlab's > > Container Registry for this, which is something Tart can do - Tart being > a > > virtualisation management utility for ARM based Macs), as well as > > automating the installation of the various OSes we need to run this way. > > See > > > https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/autom > > ate-windows-setup?view=windows-11 for some notes on that for Windows. > > > > The big downside to all of that of course is that the worker nodes would > > take longer to startup, and it would make sharing build artifacts much > more > > difficult and/or less efficient. > > > > > - Find a way to run unit tests on android CI. > > > > Likewise, this is very non-trivial - from my understanding our tooling > > currently for building Android software is centered around it all b
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > Because Wine is not Windows either, and there could be subtle differences in how things run / interact with the system. Plus some of our software would like to test certain system level infrastructure (like say KDE Connect). Plus, we have to have native Windows to compile things anyway as we need to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be built with MingW) (and you cannot really mix MingW / MSVC binaries due to incompatible compiler ABIs for C++ code) Cheers, Ben
Re: Post-MegaRelease projects
On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > This unfortunately will not be easy to solve. One of the key things that we've learned out of doing CI, as has been showcased by FreeBSD in particular, is that the builders need to be ephemeral - that is only around for the build in question that is being run. We're currently accomplishing this by using containers - via Podman (for Linux/Android/FreeBSD) and Docker (for Windows). Containers also offer us the advantage of allowing people to easily reproduce the CI environment on their local system without too much trouble. For Windows however, Microsoft has limited the container stack to not allow anything GUI related to work. The underlying libraries may be there, but the equivalent display server components are not operational. To complicate things further, on Windows certain permissions are restricted to the interactive console and are not possible to do as either a scheduled task or as a system service. Usage of existing Windows automation frameworks such as Powershell Remoting or SSH will therefore not work if we want things to perfectly replicate a end user environment - because those will run the command(s) as part of a non-interactive session (even if the user we connect as is the same one logged in on the desktop console). Resolving this will therefore not only require running full sized Windows VMs (on an ephemeral basis to avoid the recently resolved issues that used to plague FreeBSD), but would also need the VM to automatically login and spawn an agent as part of the interactive desktop session that we would connect to in order to run the CI tests. The spawning of a VM would require refactoring the setup of our poor CI workers (again - after they were only just recently completely rebuilt to allow the transition to Podman to fix flatpak-builder) to make use of something like: - https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-libvirt/72713/5 - https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html We would still have to write the agent that receives our commands (something like https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) We would still have to solve the issue of how to share disk images among our nodes so they were built (ideally would be able to use Gitlab's Container Registry for this, which is something Tart can do - Tart being a virtualisation management utility for ARM based Macs), as well as automating the installation of the various OSes we need to run this way. See https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/automate-windows-setup?view=windows-11 for some notes on that for Windows. The big downside to all of that of course is that the worker nodes would take longer to startup, and it would make sharing build artifacts much more difficult and/or less efficient. > > - Find a way to run unit tests on android CI. > Likewise, this is very non-trivial - from my understanding our tooling currently for building Android software is centered around it all being cross compiled rather than being built on the native architecture it will be run on. Naturally tests cannot be run (unless you emulate, which I guess we could consider...) if the CPU architectures are not compatible. Even if you emulate though, I imagine we would need to provide a full Android system setup (including all of it's relevant bits of system infrastructure, such as it's display server DisplayFlinger) in order for tests to truly be of use. The path of least resistance is probably by making use of Google's existing Android emulator - although i've no idea how you would tie that into CI. We would need to have our build chains ready to build on a native system before we could think about this I think. Building Android x86/x64 wouldn't cover things off properly due as it won't reflect the actual CPUs being used on end-user devices (and ARM processors can expose issues that don't happen on x86/x64 based systems) > > - Make autotests guarding on all our CI's. > > - Clazy and clang-tidy and cppcheck on all our repositories in CI > > /Sune > Hopefully
Re: Retirement of Binary Factory
On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley wrote: > Hi all, > > For some time now we have been steadily working on getting our ability to > build everything that was previously built on the Binary Factory being > built on Gitlab. > > I'm now very happy to advise that it is now possible to perform all of > those builds on Gitlab (and depending on how far you configure it, go even > further than what was being done before). This transition to Gitlab builds > should also ensure we use resources more efficiently, as builds will only > take place when code actually changes (rather than every day - which is > what the Binary Factory did). > > As such, with Gitlab now able to replace it, I am scheduling the Binary > Factory for decommissioning in 2 weeks time. > Projects relying on signed binary builds of their project should therefore > look into migrating their builds immediately and without delay. > The Binary Factory, alongside it's two build servers, and the Flatpak repository it provided at https://distribute.kde.org/ has now been decommissioned. > > The legacy Flatpak repository at http://distribute.kde.org/ will also be > retired as part of this. Anyone still using this should migrate to the > per-application Flatpak repositories at https://cdn.kde.org/flatpak/ > noting that if you are adding the repository directly you may need to add > the KF6 runtime first. > > Redirects will not be provided from the older Binary Factory URLs as there > is no successor URL for many of the Binary Factory endpoints. > > Details on how to setup your project with binary builds can be found at > https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates > > For enabling signed builds of your project builds please see > https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/signing/README.md. > Please note that signing is only permitted on mainline repository branches > marked as protected within Gitlab (which is only done for release branches > such as master and release/24.04). If your project is missing from the > configuration please submit a merge request to sysadmin/ci-utilities. > > Signing services include publishing Android builds to our F-Droid > repositories (https://cdn.kde.org/android/), Flatpak repositories ( > https://cdn.kde.org/flatpak/), as well as the staging publishers that > upload draft submissions to Google Play and the Microsoft Store (for those > applications using those) - in addition to the actual signing of binaries > (supported for Linux Flatpak, Android, Windows and Mac). > > With regards to macOS, pending fixes in the upstream tooling we use > (rcodesign) the signing service will also be able to provide notarised > builds. > See https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/38 > for more information on that. > > At this time signing of Appimages to allow use with AppimageUpdate is not > supported, however to my knowledge this is not used anywhere in KDE outside > of Krita. > > Similarly, work on changing our GItlab configuration to protect tags will > be needed before we can perform signed builds on tags (see > https://docs.gitlab.com/ee/user/project/protected_tags.html). > Based on the documentation this should not be too difficult however so > i'll add that to the list to look into sooner rather than later (as making > this change also has implications for the CI system in general) > > Thanks, > Ben > > > Cheers, Ben
Re: KDE Contributor Niccolo Ve @niccolove Violates KDE’s Code of Conduct
On Thu, Feb 15, 2024 at 9:50 AM Paul Brown wrote: > On Wednesday, 14 February 2024 19:44:55 CET Johnny Jazeix wrote: > > Hi, > > > > the Community Working Group (https://community.kde.org/CWG) handles > these > > kind of topics, you should discuss the subject with them. > > Hi, > > I agree with Nate. No need to bother any KDE WG or team. This (entirely > made > up) (non)transgression happened (but really didn't) outside of KDE's > "jurisdiction", so to speak. > The originator of this email has been handed an MTA level ban from KDE.org mail infrastructure now. I see their mailing list membership has already been terminated, and was originally made using a name that has spread abusive content in other areas before. Regards, Ben > Cheers > > Paul > -- > Promotion & Communication > > www: https://kde.org > Mastodon: https://floss.social/@kde > Facebook: https://www.facebook.com/kde/ > Twitter: https://twitter.com/kdecommunity > LinkedIn: https://www.linkedin.com/company/kde > > >
Retirement of Binary Factory
Hi all, For some time now we have been steadily working on getting our ability to build everything that was previously built on the Binary Factory being built on Gitlab. I'm now very happy to advise that it is now possible to perform all of those builds on Gitlab (and depending on how far you configure it, go even further than what was being done before). This transition to Gitlab builds should also ensure we use resources more efficiently, as builds will only take place when code actually changes (rather than every day - which is what the Binary Factory did). As such, with Gitlab now able to replace it, I am scheduling the Binary Factory for decommissioning in 2 weeks time. Projects relying on signed binary builds of their project should therefore look into migrating their builds immediately and without delay. The legacy Flatpak repository at http://distribute.kde.org/ will also be retired as part of this. Anyone still using this should migrate to the per-application Flatpak repositories at https://cdn.kde.org/flatpak/ noting that if you are adding the repository directly you may need to add the KF6 runtime first. Redirects will not be provided from the older Binary Factory URLs as there is no successor URL for many of the Binary Factory endpoints. Details on how to setup your project with binary builds can be found at https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates For enabling signed builds of your project builds please see https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/signing/README.md. Please note that signing is only permitted on mainline repository branches marked as protected within Gitlab (which is only done for release branches such as master and release/24.04). If your project is missing from the configuration please submit a merge request to sysadmin/ci-utilities. Signing services include publishing Android builds to our F-Droid repositories (https://cdn.kde.org/android/), Flatpak repositories ( https://cdn.kde.org/flatpak/), as well as the staging publishers that upload draft submissions to Google Play and the Microsoft Store (for those applications using those) - in addition to the actual signing of binaries (supported for Linux Flatpak, Android, Windows and Mac). With regards to macOS, pending fixes in the upstream tooling we use (rcodesign) the signing service will also be able to provide notarised builds. See https://invent.kde.org/sysadmin/ci-notary-service/-/merge_requests/38 for more information on that. At this time signing of Appimages to allow use with AppimageUpdate is not supported, however to my knowledge this is not used anywhere in KDE outside of Krita. Similarly, work on changing our GItlab configuration to protect tags will be needed before we can perform signed builds on tags (see https://docs.gitlab.com/ee/user/project/protected_tags.html). Based on the documentation this should not be too difficult however so i'll add that to the list to look into sooner rather than later (as making this change also has implications for the CI system in general) Thanks, Ben
Re: What can we expect from our developers
On Mon, Jan 29, 2024 at 10:38 PM Sune Vuorela wrote: > On 2024-01-29, Jonathan Riddell wrote: > > This sort of comment makes me really sad. The All About the Apps goal, > > which in principle is still ongoing, was an attempt to get KDE developers > > to realise it was important not just to write apps but to actually make > > them available to users, I find it astonishing how we still don't have a > > culture where making our apps available to users is part of our > > responsibility. There's teams in KDE to help with all these formats. > > Sorry to complain here as the issue is larger than just this one app but > > it's so sad that nobody within KDE wants to help get users using our > > software directly. > > I think this is taking it too far. I think the goal is more about not > getting in the way of people who wants to do this. > > We need to draw a line somewhere about what we expect from *all* of our > developers. > > I don't think that we can expect all of our developers to be great at > * c++ > * qtquick > * cmake > * windows weirdness > * linux weirdness > * freebsd weirdness > * osx weirdness > * android weirdness > * packaging flatpaks, appimages, snaps, debs, rpm, .. for linux > * making osx installers > * making apk's > * making windows installers > Beside the domain of the application. > > Yet it is kind of what we are doing with having gating CI setups for > many of these, and adding more. > I'm quite a seasoned developer and I know I can't care for all of that. > I also don't have the time to care for all of these. > We also don't have extra manpower in the teams that knows about these to > help everywhere. > > We might have a goal about this, but this is just far too many thing to > be good at everything. > > I don't think we should shame individual developers for also realizing > this. > > But where should we draw the line ? > For the various platform weirdnesses, it really comes down to whether you as the team behind an application (even if that team is one person) are looking to support said platform in some way or another. If there is interest in supporting the application - then you'll need to resolve those weirdnesses for that platform - and can then usually build on that to get it packaged. If you are not, then it shouldn't be there. This is part of the reason why the KDE on Windows project transitioned to providing single installers for a specific application (using what is now called Craft) rather than the package manager type approach taken in the KDE 4 era. You can't just compile everything and hope the user experience will be good, as tuning does need to be done to deliver an optimised installer and to ensure that everything works properly (such as the application being able to find the various assets it needs such as icons, QML files, etc). The only exception to the above would be libraries or other shared components where other people depend on you (where even if you as a specific library aren't too concerned about say Android support, there may still be applications that use you that do care so you should continue to have CI for those platforms). >From my perspective it is unreasonable to require people to package for every platform/format under the sun. That comes with a caveat though - that if you are looking to get visibility for your software on other platforms (say Android and Windows) then you would need to look into the requisite packaging work for that platform (as it is unreasonable to expect the team that maintains Craft, etc to do that work). The same would apply for nightly Linux builds, where you'd be expected to look into the Appimage or Flatpak packaging. That isn't to say they wouldn't provide pointers or advice, but a degree of investment from your side in making it work seems to be a reasonable expectation. The good news here though is that Craft packaging is pretty good at being shared between platforms - so you can often get things like Windows and Linux Appimages for the price of one piece of work. In terms of the original goal that Jonathan was mentioning - my interpretation of it was to make this as pain free as possible to achieve. Something that we have mostly done through Gitlab CD systems, which have the ability to turn out Flatpak bundles, Linux Appimages, Android APKs and Windows installers and portable archives. > > /Sune > > Cheers, Ben
Re: Questions about real name policy
On Thu, Nov 2, 2023 at 7:55 AM Ben Bonacci wrote: > Hi Josh, > Hi Ben, > > According to the mailing list archives from 2020 [1], "there is no real > name policy on this mailing list (or any other KDE infrastructure.)" > However, according to the community wiki page last updated in October > 2022 [2], there is a git hook for authorship that states "A name is > considered valid if it is a full name – it should not be a username or > the first name of the person." > Those two statements don't conflict at all with each other, so not sure what the issue is here. In that mailing list thread, "real name" should be interpreted as the "legal name" that governments use when issuing identifying documents such as a driver's license, passport, etc. Full name (or as I have been using in this thread "proper name") simply means a name that has a first name and a family name (or surname as it is called in other places). A pseudonym can certainly still be a full name, however it would not be a real name. > > Perhaps a formal vote or the equivalent policy for handling these kinds > of questions should be held. Then, whatever the final verdict would be, > can be documented in the Code of Conduct or a similar document to make > the policy clear. > That is not required, this area is relatively well settled. > > Regards, > > Ben > Regards, Ben > > > [1] https://mail.kde.org/pipermail/kdepim-users/2020-June/013299.html > > [2] https://community.kde.org/Infrastructure/Git/Hooks#Authorship_metadata > > On 1/11/23 12:40, Josh wrote: > > Hello KDE community, > > > > I'm not sure if this is the best ML to post it in, but anyway - what is > our > > current stance on a real name policy? We were recently asked again in a > Matrix > > channel and the consensus seems to be "we don't know?" From what I can > tell, > > you *must* use your real name or else our git commit hooks will reject > any > > pushes. From some precursory web searches, people say to work around > this by > > putting spaces in the git username field. So it's allowed, but > unofficially? The > > git commit hook doesn't mention this work around I think. > > > > I have gotten more than zero complaints/questions about this policy, and > I've > > only been here for a year. When tracking down something "official", all > I've > > found is a few mentions on the Community wiki. If we dismissed the > policy, > > then we should update those commit hooks. These contributors are > starting to > > make non-trivial commits to projects I care about, so it would really > great if > > we can accommodate them. > > > > Whatever decision we make, can we document this somewhere so I can link > people > > to it? Preferably on kde.org, where it it's immutable and official > looking like > > our code of conduct. > > > > (If the reason is "it's because of relicensing", I have a hard time > tracking > > down people even when I know their full names. I would prefer better > reasons > > than that, if possible ) > > > > Thanks, > > Josh > > > > > -- > Ben Bonacci > https://benbonacci.com > C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976 > > Quote of the Day: "Dream big and dare to fail." - Norman Vaughan > >
Re: Questions about real name policy
On Thu, Nov 2, 2023 at 9:10 AM Joshua Goins wrote: > > You must use a proper name, otherwise the servers will reject it yes. > > > > However we have no way of enforcing a real name, so it really just needs > to > > be something you are known by. > > (ie. there is nothing to stop people from using pseudonyms) > > Thanks Ben for the background information, although it's not mentioned I'm > assuming the reason for the space in the name check (which I'm personally > fine > with) is because of spammers? And it's probably a really easy way to catch > easy mistakes like git using the name of the current user when it's not > set > up. > Nope. The check was added in far simpler times many many years ago, not long after KDE started moving to Git from SVN. Git versions in that era did not require you to explicitly set a name, and instead would inherit the name of your local user account (as from `id -un`). This was undesirable as many names are quite common and don't help identify you in the commit history, so we put the hook in place to ensure accidents didn't happen. There is still merit in this check, as we do want people to be using proper/identifiable names. > > I'm going to save this information for later, it would be helpful to write > up > a resource on this - especially the email part which is in my opinion is a > really important requirement. > > Thanks, > Josh > Cheers, Ben
Re: Questions about real name policy
On Wed, Nov 1, 2023 at 3:52 PM Richard Troy wrote: > > > > Date: Tue, 31 Oct 2023 21:40:48 -0400 > > From: Josh > > To: kde-community@kde.org > > Subject: Questions about real name policy > > > > Hello KDE community, > Hi Josh, > > > > I'm not sure if this is the best ML to post it in, but anyway - what is > > our current stance on a real name policy? We were recently asked again > > in a Matrix channel and the consensus seems to be "we don't know?" From > > what I can tell, you *must* use your real name or else our git commit > > hooks will reject any pushes. From some precursory web searches, people > > say to work around this by putting spaces in the git username field. So > > it's allowed, but unofficially? The git commit hook doesn't mention this > > work around I think. > You must use a proper name, otherwise the servers will reject it yes. However we have no way of enforcing a real name, so it really just needs to be something you are known by. (ie. there is nothing to stop people from using pseudonyms) That being said, for those who are looking to reference their work later it would be recommended to use your actual name as we won't rewrite repositories for people who want to change their name. (so being consistent, and ensuring that you will be happy with the name you have chosen in 5 years time is a good idea) If you have opted to adopt a name that does not contain spaces (and cause immense pain for yourself in the process as lots of places expect first and family names) then you will need to file a Sysadmin ticket to have your name be whitelisted within our systems. You must still follow normal conventions on capitalisation and other rules that would usually be enforced for names (so no numbers in it for instance). Do not workaround or otherwise attempt to bypass the commit hooks - they are enforcing rules and bypassing them is not permitted. On the relicensing point, a long lived contact email address is just as important here (if not almost more important). Please ensure you use an email address that will still be active in several years time. Use of throwaway addresses is also not permitted. Much like names, the server also performs a bunch of validation on your email address to ensure it is usable and valid. > > > > I have gotten more than zero complaints/questions about this policy, and > > I've only been here for a year. When tracking down something "official", > > all I've found is a few mentions on the Community wiki. If we dismissed > > the policy, then we should update those commit hooks. These contributors > > are starting to make non-trivial commits to projects I care about, so it > > would really great if we can accommodate them. > > > > Whatever decision we make, can we document this somewhere so I can link > > people to it? Preferably on kde.org, where it it's immutable and > > official looking like our code of conduct. > > > > (If the reason is "it's because of relicensing", I have a hard time > > tracking down people even when I know their full names. I would prefer > > better reasons than that, if possible ) > > > > Thanks, > > Josh > Cheers, Ben > > Hi Josh - and KDE community, > > I'm in this even more recently than you, but I hope this short reply is > worthwhile: > > I'm speaking here as a person who STRONGLY values online anonymity. > > That said, context is _everything._ My father was a state assistant > attorney general and I myself spent an entire year working as an unpaid > legal aide for the lawyers there. From that experience, and now, as a > person who's created a small software company, my response is that your > instincts are good: As you note, the licensing is really important here. > > My instincts say that this is clearly and unmistakably a question for a > lawyer who's both informed on the issues and cares about this project, > either because their paid or because they're committed in some other way. > > Regards, > Richard > > -- > Richard Troy, Chief Scientist > Science Tools Corporation > 510-717-6942 > rt...@sciencetools.com, http://ScienceTools.com/
Gitlab update and repository repack
Hi all, Just a brief update that our Gitlab instance has been updated to the latest patch revision this evening. There are no notable changes to it's functionality or bugfixes for us. I have also repacked all of the pool repositories this afternoon as part of regular maintenance on Gitlab. This should reduce the size of repository clones going forward. Cheers, Ben
Re: Phabricator task | formalizing a process for adding/removing services to KDE's infrastructure
On Fri, Aug 25, 2023 at 2:00 AM Joseph P. De Veaugh-Geiss wrote: > Hi again, > Hi Joseph, > > as promised, here's the link to the Phabricator task about formalizing a > process for adding/removing services to KDE's infrastructure: > >https://phabricator.kde.org/T16410 Just as a note for those evaluating this, our current systems have been quite slimmed down from what they once were a few years ago. The main areas where we are harbouring a degree of legacy services would sit in the chat space (with the likes of sKreamer, pursuivant and IrcsomeBot). That is something we've still got to deal with though. The only other space that is still being worked on that I can immediately think of would be apps.kde.org / develop.kde.org / the Wikis (with content moving from the Wikis to those two respectively). Depending on how far this goes, I could see Gitlab's Wiki functionality eventually replacing the wikis altogether. Hopefully in the next few months we will be able to sunset the Binary Factory, and then Phabricator after it which will bring everything under "one roof" as it were. Some work is still needed in the Drupal space to get us off those and on to something more modern (whether that be Wordpress or Hugo), but those are separate and if there is anyone who would like to take that on, please get in touch with me. (This is a pretty ideal task for someone who is looking to get involved once the platform decision is made) > > > I think having a formal process for this will help situations like we > are having now with Telegram, and prevent a proliferation of new > services/websites/etc. that use up resources, potentially fracture > communication, end up unmaintained, and so on. > Chat services have always been a difficult one to deal with unfortunately, so i'm not sure how much a process would have helped the Telegram issue (it might have reduced the pain to a certain degree, but there still would have been pain) > > Cheers, > Joseph > Cheers, Ben > > -- > Joseph P. De Veaugh-Geiss > KDE Internal Communications & KDE Eco Community Manager > OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F > Matrix: @joseph:kde.org > > Generally available Monday-Thursday from 10-16h CET/CEST. Outside of > these times it may take a little longer for me to respond. > > KDE Eco: Building Energy-Efficient Free Software! > Website: https://eco.kde.org > Mastodon: @be4foss@floss.social >
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
On Fri, Aug 25, 2023 at 3:12 AM Carl Schwan wrote: > On Tuesday, 22 August 2023 08:57:31 CEST Joseph P. De Veaugh-Geiss wrote: > > Hello KDE community, > > > > apologies for cross-posting! > > Please let's stop doing that, it's generating a lot of duplicated emails > for > everyone. Most people interested in this discussion are in the > kde-community > channel and if they are not we should encourage them to join it. No need > to > have this discussion in unrelated, purelly technical and low traffic > channel > like kde-framework, kde-core-devel or release-team. > The cross posting was started to ensure that everyone is well aware this is going to happen. As sysadmin I have had far too many people claim they weren't aware of something even when it was posted to many lists (including this one), so it is understandable why we are cross posting here. (A small handful of people even missed the notification about the Invent server move, even with the heavy handed cross post approach I took with that...) > > > The time has finally come: both Telegram <-> Matrix bridges will be shut > > down in 4 weeks on *Wednesday 20 September*. Let's start the > > co-ordination process now so everything goes as smoothly as possible. > > As one of the person who pushed quite hard a few years ago to improve our > Telegram bridging situation, I'm very unhappy with this decision and I > don't > say this as a Telegram fan. Far from that, I love decentralized and open > source social media and messaging platforms, I started developing NeoChat > and > Tokodon, I'm also quite involved around email client development and I'm > barelly using my Telegram account (both for kde or private usage). > > So why did I push for Telegram bridging in the past? First of all, > Telegram is > an amazing entry point for new contributors. People don't have to adopt a > new > messaging app to talk with us, which reduce the barrier considerably. > Particularly for newcommers, the more step they need to make to start > contributing and publish their first commit, the higher the chance they > give up > midway. And as far I know, we deseperably need more contributors, so we > are > shooting ourselves in the foot with this move. > > Even people who are contributing for a longer time sometimes prefer to > keep > communicating with Telegram, because it's easier or it's just the medium > they > use for most their communication and they prefer to keep like this instead > of > investing time and changing their habits. As much as I want more people to > adopt Matrix, this is perfectly understandable and forcing them to change > their habits as more change to loose them in the short to middle term as > active contributor. > > Another reason, why I pushed for a better telegram bridge years ago, was > because even if not everyone switch to Matrix, some people do which is a > net > gain in term of contributors and they might even be tempted to improve > NeoChat. > > Now on the technical issues: > > >* Telegram is not Free Software and has never been an official > > platform for KDE communications. However, it has been used unofficially > > in a number of areas. > > Gmail is also not Free Software and will allow people using a gmail > account > (booo) to communicate with us. Sure gmail still use a common standard to > communicate with us, but using bridges is a somewhat working alternative. > > >* EMS hosts KDE's Matrix instance and the current Telegram bridge, > > and the majority of issues our community have with Matrix are related to > > bridges. Due to the huge extra load and poor performance Telegram > > bridging has in the Matrix rooms, it was agreed with EMS that the bridge > > would be only run for about a year until people had time to migrate to > > Matrix. > > Why wasn't this communicate before that this was only temporary in > https://mail.kde.org/pipermail/kde-community/2021q2/006884.html ? > > I was completely unaware of that and I'm in the KDE IM ops room, the KDE/ > Matrix support room and in the KDE/Matrix VIP room. > > >* However, instead of people migrating away from Telegram, we have > > seen an increase in contributors using /both/ Matrix and Telegram, which > > has doubled the number of users we have to cope with. Having twice as > > many users as needed in the room slows everything down: longer joins, > > more state events for each user, higher chances of room state developing > > problems. > > The state events generated by the telegram bridge are in an order of > magnitude > less than the state events generated by the irc bridge since the telegram > users usually don't join and leave a room multiple times a day. And > similarly > a lot of IRC users also have a Matrix account. I wonder how many double > accounts there was actually, because to me it seems the issue was actually > that there was too many Matrix users in the room which was then causing > issue > with the IRC bridge. If we expect 100% (very unlikely) of the telegram
Infrastructure updates - collaborate.kde.org
Hi all, Just to provide a heads up, this afternoon i've updated our Nextcloud instance at collaborate.kde.org to the latest version. Should there be any issues please let us know. Thanks, Ben
Re: using gitlab ultimate
On Thu, Aug 3, 2023 at 1:31 AM Harald Sitter wrote: > Ahoy! > > How about we start using the gitlab ultimate rather than the free version? > > It'd give us access to some handy dandy features like > > - CI dashboard > - multiple MR assignees > - better issue boards > - epics & roadmaps > - dependency scanning support (for our supporting projects written in > ruby, go, python etc) > With regards to the above: The CI dashboards offered by Gitlab EE (Ultimate) would still be insufficient for our needs from what I can tell in the documentation. We need to be able to see down to the job level to separate based on platform / checks failing, which isn't supported functionality. For this we will need to develop something different and custom, and unlike the previous iterations won't be able to make use ot Grafana (as Gitlab CI statuses just isn't something that fits well within the Prometheus/Grafana model) With respect to dependency scanning, the core functionality is still available and the raw reports are published to Gitlab, what is missing is the visualisation (much like test reports on commits). For issue boards, we've yet to fully do that migration - but when we do switch off Phabricator and bring it's content into Gitlab - we can definitely look at asking for bits and pieces of functionality to be moved over as Eike mentioned. We were already successful in getting multiple boards moved over (for the project level). I have plans surrounding MR assignees, watch this space Much like the rest of the people who have commented here, I agree with the philosophy of continuing to only use Open Source Software to develop Open Source Software. > and that's just off the top of my head! > > What do you reckon? > > HS > Thanks, Ben
Re: ACTION REQUIRED - Gitlab and Subversion server migration
On Tue, Jul 25, 2023 at 1:35 AM Vít Pelčák wrote: > > ne 23. 7. 2023 v 12:01 odesílatel Ben Cooksley napsal: > >> Good morning KDE Developers, >> >> As many of you will be aware, today Gitlab and our Subversion repository >> were both migrated to a new home - on a more modern and more powerful >> server, which should better support future work. >> >> As a consequence the host key of the server has now changed, which means >> you will need to take steps on your system otherwise you won't be allowed >> to connect to the new server. >> >> Please ensure you run the following two commands to clear out any >> existing host keys: >> - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts >> - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts >> > > I suppose you meant > ssh-keygen -R svn.kde.org -f ~/.ssh/known_hosts > That is correct. > > right? > > Cheers, Ben
Re: ACTION REQUIRED - Gitlab and Subversion server migration
On Sun, Jul 23, 2023 at 10:59 PM Anna (cybertailor) Vyalkova < cyber+...@sysrq.in> wrote: > On 2023-07-23 22:01, Ben Cooksley wrote: > > Good morning KDE Developers, > > > > As many of you will be aware, today Gitlab and our Subversion repository > > were both migrated to a new home - on a more modern and more powerful > > server, which should better support future work. > > > > As a consequence the host key of the server has now changed, which means > > you will need to take steps on your system otherwise you won't be allowed > > to connect to the new server. > > Was it possible to transfer keys from the old server? > The SSH keys that belong to an individual developer were transferred across, however the host keys identify a server and therefore naturally change when the server is replaced. The only action needed on your part is clearing out the old host keys so the new ones can take effect. > > > Please ensure you run the following two commands to clear out any > existing > > host keys: > > - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts > > - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts > > > > Following these commands the next time you try to connect you will be > > prompted to confirm the new host key and trust it for use. For those who > > would like to confirm that host key, it is as follows: > > > > 256 SHA256:zHdK2R/S6s5Oj71N0s8LHWCXXsUt+DCztd+GjzW9KlU root@lerwini > > (ED25519) > > 256 SHA256:ZNBg4AkRxbt/N6xzpt7GbmmS78A3WFy5lz0l/cPHbcE root@lerwini > (ECDSA) > > 3072 SHA256:KxAoV6VsbKvAocFZCJlxtmPDScmUCRNiUiOCSXNSC/k root@lerwini > (RSA) > Cheers, Ben
ACTION REQUIRED - Gitlab and Subversion server migration
Good morning KDE Developers, As many of you will be aware, today Gitlab and our Subversion repository were both migrated to a new home - on a more modern and more powerful server, which should better support future work. As a consequence the host key of the server has now changed, which means you will need to take steps on your system otherwise you won't be allowed to connect to the new server. Please ensure you run the following two commands to clear out any existing host keys: - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts Following these commands the next time you try to connect you will be prompted to confirm the new host key and trust it for use. For those who would like to confirm that host key, it is as follows: 256 SHA256:zHdK2R/S6s5Oj71N0s8LHWCXXsUt+DCztd+GjzW9KlU root@lerwini (ED25519) 256 SHA256:ZNBg4AkRxbt/N6xzpt7GbmmS78A3WFy5lz0l/cPHbcE root@lerwini (ECDSA) 3072 SHA256:KxAoV6VsbKvAocFZCJlxtmPDScmUCRNiUiOCSXNSC/k root@lerwini (RSA) Please let us know, via either sysad...@kde.org or kde-de...@kde.org if you encounter any issues with the new system. Many thanks, Ben Cooksley KDE Sysadmin
Downtime notification - Gitlab server migration
Good morning all, This evening (UTC time) I will be moving Gitlab from the current system it is located on to a new server. This move is being undertaken to ensure we have the most up to date software stack, as well as take advantage of newer hardware that is both more efficient and more powerful (the existing server is around 4 years old or so). Based on performance benchmarks, the new system should have a significant performance uplift, which will help ensure we're able to support new workloads - such as the incoming migration of binary build jobs from the Binary Factory. This migration will take several hours unfortunately, during which time Gitlab will be completely unavailable. This includes read and write operations to Git repositories, authentication services for KDE.org sites that use Invent login, issues, wiki pages and everything else hosted by Gitlab. This migration will be undertaken from approximately 10pm UTC, Saturday 22nd July. Please let me know if you have any questions on the above. Cheers, Ben
Re: Recent spam attacks
On Mon, Jun 26, 2023 at 5:25 AM Johnny Jazeix wrote: > Hi, > is there a way to help with this spam except reporting it to the sysadmin > channel? > https://invent.kde.org/kpj > https://bugs.kde.org/show_bug.cgi?id=380007 and > https://bugs.kde.org/show_bug.cgi?id=402838 > https://community.kde.org/Special:Contributions/Kpj > There are a number of community members who are empowered when it comes to bugs.kde.org and our wikis, so mentioning it in #kde-devel and #kde-sysadmin is the best way to get it dealt with when a Sysadmin is not around. For invent.kde.org, that is something only a Sysadmin can handle i'm afraid as Gitlab does not have roles for anti-abuse functionality (it's full admin or nothing). I have now restored community.kde.org and techbase.kde.org from backups to reverse the vandalism to those sites, and all comments they made on bugs.kde.org have been blanked. With respect to invent.kde.org, their account(s) are now banned, and all content they created has been deleted. I have also blocked all three of their accounts on the Identity end, which will hopefully put an end to the majority of their abuse. Unfortunately as Bugzilla does not participate in the Identity system, it is not protected by the same mechanisms that I listed below. (Their third Identity account was registered with a Yandex address) > > > Thank you for your work. > > Cheers, > > Johnny > Thanks, Ben > > Le dim. 25 juin 2023 à 13:05, Ben Cooksley a écrit : > >> Hi all, >> >> As some of you may have noticed, over the last couple of days we have >> been experiencing some spam, with Phabricator heavily affected in addition >> to Gitlab and our Wikis. >> >> The spam wave should now have been all cleaned up, with offending content >> purged. My apologies to those that received the offensive material in >> question. >> >> In response to this, I have now applied the same blocking measures that >> were designed to defeat our movie spammers against this recent attacker. >> This means that Japan has now joined the list of countries considered >> "abusive" and is now subject to aggressive counter measures designed to >> defeat spam registrations. >> >> As such, people located within Japan may, depending on their specific >> situation, have issues registering on KDE Identity. People affected by >> those blocks should email sysad...@kde.org for assistance with getting >> manually registered. >> >> Please let me know if there are queries regarding this. >> >> Thanks, >> Ben >> >>
Recent spam attacks
Hi all, As some of you may have noticed, over the last couple of days we have been experiencing some spam, with Phabricator heavily affected in addition to Gitlab and our Wikis. The spam wave should now have been all cleaned up, with offending content purged. My apologies to those that received the offensive material in question. In response to this, I have now applied the same blocking measures that were designed to defeat our movie spammers against this recent attacker. This means that Japan has now joined the list of countries considered "abusive" and is now subject to aggressive counter measures designed to defeat spam registrations. As such, people located within Japan may, depending on their specific situation, have issues registering on KDE Identity. People affected by those blocks should email sysad...@kde.org for assistance with getting manually registered. Please let me know if there are queries regarding this. Thanks, Ben
Re: discuss announce forum forward to kde-announce list
On Thu, Jun 22, 2023 at 5:20 AM Heiko Becker wrote: > On Wednesday, 21 June 2023 19:08:38 CEST, Albert Astals Cid wrote: > > El dimecres, 21 de juny de 2023, a les 16:41:03 (CEST), Kenny Duffus va > > escriure: > >> On Wednesday, 21 June 2023 15:33:34 BST Jonathan Riddell wrote: ... > > > > Much better > > Indeed. IMHO, the purpose of kde-announce is to notify interested parties > about new releases from KDE. It does so well, without any noise. And I'd > prefer it to keep it that way, without any "why didn't you still fix my > pet > bug in this release" or "" comments. > It also already has several thousand people subscribed to it, and the most important part of an announcement channel is the audience. We wouldn't be able to transfer their data into Discourse as that would be using data for reasons other than what it was originally provided to us for. It therefore will need to be a mailing list -> Discourse posting. > > Regards, > Heiko > Thanks, Ben
Re: WikiToLearn repos on invent
On Mon, Jun 19, 2023 at 5:41 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > On 2023-06-15 11:13, Ben Cooksley wrote: > > On Thu, Jun 15, 2023 at 6:34 AM Christoph Cullmann (cullmann.io [1]) > > wrote: > > > >> On 2023-05-14 22:50, Christoph Cullmann (cullmann.io [1]) wrote: > >>> Hi, > >>> > >>> given the last activity is one or two years ago, > >>> would it make sense to move the stuff in > >>> > >>> https://invent.kde.org/wikitolearn > >>> > >>> to > >>> > >>> https://invent.kde.org/unmaintained > >>> > >>> and archive it there until it is revived? > >> > >> Given nobody objected, could that be done? > > > > All projects in the group have now been archived. > > Thanks, > > it still shows up prominently in the groups overview, > but I guess that can not be that easily fixed. > Correct, unfortunately groups cannot be archived and moving groups is also non-trivial. I've put it on my list to investigate options to move the entire WikiToLearn group to Unmaintained, however for now it will need to remain at top level. Thanks, Ben > > Greetings > Christoph > > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org >
Re: WikiToLearn repos on invent
On Thu, Jun 15, 2023 at 6:34 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > On 2023-05-14 22:50, Christoph Cullmann (cullmann.io) wrote: > > Hi, > > > > given the last activity is one or two years ago, > > would it make sense to move the stuff in > > > > https://invent.kde.org/wikitolearn > > > > to > > > > https://invent.kde.org/unmaintained > > > > and archive it there until it is revived? > > Given nobody objected, could that be done? > All projects in the group have now been archived. > > Thanks > Christoph > Cheers, Ben > > > > > Greetings > > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org >
Re: Kde Identity Register issue
I've responded to this off-list. Cheers, Ben On Thu, Jun 8, 2023 at 10:15 AM Aniketh 1920 wrote: > Hi, > I am not able to register in kde identity .It is showing Client rejected > by anti-spam identification measures > > Can you tell me how to register in your portal in a simple manner? >
Grafana Update
Good morning all, Just a small heads up that this afternoon i've completed migrating our Grafana instance that supports reporting for our Telemetry, as well as provides the CI dashboards to a new server. As part of this transition we've received updates to Grafana itself, as well as the Gitlab CI Pipelines Exporter that we use. Among other things, this means that our CI dashboards will now be able to start reporting on whether tests are failing / passing / etc. If anyone would like to look into changes to, or improvements to, the CI dashboards please get in touch and i'll give you the necessary permissions on Grafana. This is an area that anyone (even a non-developer who is keen to get involved) could certainly get into. The existing dashboards could definitely do with significant improvement (and are something I put together to show what could be done, rather than anything permanent). Thanks, Ben
Re: Retiring Phabricator - Migrating tasks to Gitlab
On Mon, May 29, 2023 at 1:29 AM Johannes Zarl-Zierl wrote: > Am Samstag, 27. Mai 2023, 23:13:08 CEST schrieb Ben Cooksley: > > On Sun, May 28, 2023 at 8:24 AM Johannes Zarl-Zierl < > johan...@zarl-zierl.at> > > wrote: > > > I'm fine with having columns be mapped as labels. > > > However, if it is easy to implement, having some columns be converted > to > > > milestones would be quite nice, since we have been using columns to > track > > > tasks related to our releases. > > > > I haven't started looking into the full detail of what is needed to bring > > detail across yet, however I imagine that may require a degree of extra > > work. > > I'll comment more on this once i've examined the Gitlab and Phabricator > > APIs I need to work with to do the data migration. > > If it helps, I can also do some manual cleanup on kphotoalbum after the > migration. If we're the only affected project, it is probably a better > investment of time for me to assigne ~40 issues to milestones than it is > for > you to develop an automated migration script... > Noted. Based on what i'm seeing so far (i'm looking into the bztogl tool, which was developed for the FDO move to Gitlab) this may end up being what we need to do. > > Cheers, > Johannes > Cheers, Ben
Re: Retiring Phabricator - Migrating tasks to Gitlab
On Sun, May 28, 2023 at 8:24 AM Johannes Zarl-Zierl wrote: > That's great news! > > Am Montag, 22. Mai 2023, 17:17:50 CEST schrieb Wolthera: > > Overall, I've noticed that milestones are best for collecting tasks > > related to a release or a defined project (Say, a new tool, importer > > or workflow), while the boards are better for if you need to track the > > state of multiple issues, because Gitlab Free doesn't allow filtering > > of issues on a board (only having columns for a specific issue label), > > which effectively makes it a different UI for the issue list. Because > > the board columns map to a label, it makes sense to have columns be > > converted to labels for the vast majority of projects, yes. > > I'm fine with having columns be mapped as labels. > However, if it is easy to implement, having some columns be converted to > milestones would be quite nice, since we have been using columns to track > tasks related to our releases. > I haven't started looking into the full detail of what is needed to bring detail across yet, however I imagine that may require a degree of extra work. I'll comment more on this once i've examined the Gitlab and Phabricator APIs I need to work with to do the data migration. > > Cheers, > Johannes > Cheers, Ben
Re: Retiring Phabricator - Migrating tasks to Gitlab
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
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Thu, May 25, 2023 at 1:06 AM Carl Schwan wrote: > On Monday, 22 May 2023 00:26:09 CEST argonel wrote: > Hi, > > > I would argue that the low usage is in part due to lack of awareness. > > It has a one-line mention on the "Internet Relay Chat" community wiki > > page (which wasn't added until 2019) that doesn't even explain the > > benefits of using it. > > > > IRC in combination with the BNC is much more suited to intermittent > > usage than Matrix is, which currently obligates the user to "be > > active" every 30 days, or risk (permanently!) losing access to the > > entirety of the history of all of their joined channels (even the > > parts for which they were present). The BNC happily buffers the text > > until your client is able to reconnect. As an example, this allowed me > > to read discussions that happened while I endured an extended power > > outage, even when Matrix had decided that I was idle for "too long". > > The requirement of not being inactive for 30 days is not due to Matrix. > Matrix > doesn't care about your inactivity, but his is actually a Libera.chat > policy, > which was a requirement for libera.chat authorizing the bridging. This is > the > same issue with the fact that when you join a room, you can't see the chat > history from before you joined the room. > > I understand that this requirement is due to some technical issues, as IRC > doesn't support having so many connections open at the same time but it's > a > bit wrong to blame Matrix for that. I do wonder why BNC is not affected by > this > policy, but I suppose it's because there are way less users using IRC. > Historically we were impacted by connection limit issues, and required (at the time) Freenode staff to grant us an iline to allow us to exceed the normal connection limits. We still had to throttle reconnections though - which made maintenance on the server that hosted the BNC very painful as it would take a good 2 hours or so for everyone to be reconnected. I just had a look and the number of active users remains the same - 6. > > Cheers, > Carl > Cheers, Ben
Re: Retiring Phabricator - Migrating tasks to Gitlab
On Tue, May 23, 2023 at 11:39 AM Nate Graham wrote: > Great, this will be a good thing to have behind us. > You can say that again. Phabricator is a bit of a nightmare to host - in large part because the entire content of our Subversion repository is indexed in it's database, which has resulted in it consuming ~400GB on disk. Along with it being unmaintained, i'll be very happy to archive it and shutdown that container. > Because workboards in GitLab are Label-driven via automation, I think we > would have to make each workboard column in Phabricator transform into a > custom label in GitLab so that Tasks' positions in workboards can be > preserved when they move to GitLab. > This aligns with what Johnny has mentioned and seems reasonable enough to me. In theory it shouldn't be too hard to automate. > > 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? The simplest would be to consider some projects to be the natural "home" for tasks (likely the app in question) while meta groups (such as VDG / Windows / Flatpak / etc) would only get a task if it was the only project on a task. > > In Gitlab, it's Labels all the way down... > Yes :) > > Nate > Cheers, Ben > > > On 5/21/23 03:14, Ben Cooksley wrote: > > Hi all, > > > > As many of you will undoubtedly be aware, we currently have a bit of a > > hybrid approach with our use of GitLab, with some projects/areas still > > making use of Phabricator as they await the final import of these tasks > > across to GitLab. > > > > That time has now arrived, as Phabricator is long since unmaintained and > > needs to be retired. > > > > The only question is how this is best structured. > > > > My thinking on this had been to establish a mapping of Phabricator > > project to Gitlab project (with some Gitlab projects possibly receiving > > multiple Phabricator projects). Where necessary we would create > > groups/projects under teams/ on invent.kde.org <http://invent.kde.org> > > to house these, otherwise they'd be imported into the mainline projects. > > > > For those projects currently using GitLab as a task tracking tool, any > > feedback you have on this would also be welcome. > > > > In terms of the migration, we'd be looking to retain as much information > > as possible, however things like the precise column a task has on a > > workboard would likely be lost. The actual content of the task including > > details such as time and authorship, along with any comments would be > > retained though. > > > > Thoughts? > > > > Thanks, > > Ben >
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Mon, May 22, 2023 at 8:39 PM Vincent Pinon wrote: > > Le 22/05/2023 à 10:24, Ben Cooksley a écrit : > > On Mon, May 22, 2023 at 10:05 AM argonel wrote: > >> On Sun, May 21, 2023 at 3:12 PM Ben Cooksley wrote: >> > >> > On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs) >> wrote: >> >> >> Bouncer wise: 30 connections isn't exactly none, especially if that >> contains >> >> active people. These would be forced to migrate to a service (and >> register at >> >> such) which is not under KDEs control and, as far as I am aware, has a >> >> mandatory registration. As far as memory serves some communities, >> e.g. I >> >> think krita, still had active devs / maintainers on IRC. >> > >> > >> > Yes, there is a cost-benefit analysis to all services we run however - >> and if there is a minimal number of people benefiting from it, sometimes it >> is time to retire a service. >> > >> > Note that the 30 I quoted was a count of TCP connections - so included >> inbound and outbound links. >> > The number of connected clients is much, much smaller - so it is >> possible there are some IRC connections still active for people that are no >> longer around, or who have moved to Matrix and not deactivated the BNC. >> >> I would argue that the low usage is in part due to lack of awareness. >> It has a one-line mention on the "Internet Relay Chat" community wiki >> page (which wasn't added until 2019) that doesn't even explain the >> benefits of using it. >> >> IRC in combination with the BNC is much more suited to intermittent >> usage than Matrix is, which currently obligates the user to "be >> active" every 30 days, or risk (permanently!) losing access to the >> entirety of the history of all of their joined channels (even the >> parts for which they were present). The BNC happily buffers the text >> until your client is able to reconnect. As an example, this allowed me >> to read discussions that happened while I endured an extended power >> outage, even when Matrix had decided that I was idle for "too long". >> > > Not sure what the bots do on the IRC side, but this kicking due to > inactivity is actually due to IRC and the bridging between it and Matrix. > It isn't an issue of Matrix itself as a protocol / software stack - it is > a limitation imposed on the Matrix side to help Libera.chat with connection > load. > > >> >> So instead of shuttering the service, I recommend that more attention >> be drawn to it. >> > > There are currently 114 people registered to use the BNC, so it appears to > be rather well known among our community members. > The decline in it's usage has correlated rather well with the rise of > Matrix, so it appears that those that favour a BNC type experience find > Matrix works just as well / better. > > Thanks, > Ben > > Hello, > > This conversation made me realize I still had BNC activated for my > account, despite not connecting to IRC anymore for long (and to matrix > neither recently, my participation is rather on pause for the moment). > > It is not clear on the BNC UI, nor on community wiki, how to close the > account. I just unregistered libera from BNC, but don't see how to > completely close the service for me? > > Thanks again for taking care of all these services! > You're not able to remove your own BNC account - please file a ticket and we'll action that. > Vincent > Cheers, Ben
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Mon, May 22, 2023 at 10:05 AM argonel wrote: > On Sun, May 21, 2023 at 3:12 PM Ben Cooksley wrote: > > > > On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs) > wrote: > > >> Bouncer wise: 30 connections isn't exactly none, especially if that > contains > >> active people. These would be forced to migrate to a service (and > register at > >> such) which is not under KDEs control and, as far as I am aware, has a > >> mandatory registration. As far as memory serves some communities, e.g. > I > >> think krita, still had active devs / maintainers on IRC. > > > > > > Yes, there is a cost-benefit analysis to all services we run however - > and if there is a minimal number of people benefiting from it, sometimes it > is time to retire a service. > > > > Note that the 30 I quoted was a count of TCP connections - so included > inbound and outbound links. > > The number of connected clients is much, much smaller - so it is > possible there are some IRC connections still active for people that are no > longer around, or who have moved to Matrix and not deactivated the BNC. > > I would argue that the low usage is in part due to lack of awareness. > It has a one-line mention on the "Internet Relay Chat" community wiki > page (which wasn't added until 2019) that doesn't even explain the > benefits of using it. > > IRC in combination with the BNC is much more suited to intermittent > usage than Matrix is, which currently obligates the user to "be > active" every 30 days, or risk (permanently!) losing access to the > entirety of the history of all of their joined channels (even the > parts for which they were present). The BNC happily buffers the text > until your client is able to reconnect. As an example, this allowed me > to read discussions that happened while I endured an extended power > outage, even when Matrix had decided that I was idle for "too long". > Not sure what the bots do on the IRC side, but this kicking due to inactivity is actually due to IRC and the bridging between it and Matrix. It isn't an issue of Matrix itself as a protocol / software stack - it is a limitation imposed on the Matrix side to help Libera.chat with connection load. > > So instead of shuttering the service, I recommend that more attention > be drawn to it. > There are currently 114 people registered to use the BNC, so it appears to be rather well known among our community members. The decline in it's usage has correlated rather well with the rise of Matrix, so it appears that those that favour a BNC type experience find Matrix works just as well / better. Thanks, Ben
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Mon, May 22, 2023 at 7:44 AM Christian wrote: > Am Sonntag, 21. Mai 2023, 21:12:25 CEST schrieb Ben Cooksley: > > Hi Ben, thanks for the answer, > > > Pursuivant is responsible for the announcement of commits and bugs. > > As of late we have only seen removals of this functionality (see > > > https://invent.kde.org/sysadmin/irc-notifications/-/commits/master?ref_type= > > heads) from channels, hence why i'm slating it for decommissioning. > > > > > Bouncer wise: 30 connections isn't exactly none, especially if that > > > contains > > > active people. These would be forced to migrate to a service (and > register > > > at > > > such) which is not under KDEs control and, as far as I am aware, has a > > > mandatory registration. As far as memory serves some communities, > e.g. I > > > think krita, still had active devs / maintainers on IRC. > > > > Yes, there is a cost-benefit analysis to all services we run however - > and > > if there is a minimal number of people benefiting from it, sometimes it > is > > time to retire a service. > > I guess we have at least found one community in KDE, a bigger one I'd say, > that spoke up that they are using it, so maybe best check with them first. > Also > given that so far the vast majority of answers was not in favour of > decommissioning, given the (from what I see) very low cost it should > probably > be re-evaluated. > Not sure which one of the several services i've referred to here that you're commenting on, so bit difficult to respond here, however: For the BNC, nobody from the Krita community is a user of it. sKreamer is as noted, impacted by the fact it cannot run on modern distributions. The only service it seems there is particular interest in some areas retaining is pursuivant? (which is probably best done by replacing it with a Maubot instance) > > Of course that doesn't apply to the systems that have to be replaced due > to > them no longer being maintained / supported, but unless we run into > security > issues it would be nice to have a, from what I gather already planned, > replacement before they are taken out. > > Kind regards, > > Christian > Cheers, Ben
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Mon, May 22, 2023 at 2:00 AM Kenny Duffus wrote: > On Sunday, 21 May 2023 10:37:45 BST Ben Cooksley wrote: > > Hi all, > > > > For some time now, the level of use of our IRC services - notably being > > Pursuivant and the Telegram Matterbridge, but also including sKreamer - > has > > been on the decline. > > > > I'd therefore like to permanently retire all three of these services. > > > > Depending on the level of community interest, we may opt to retain > > pursuivant however I'd like for it to be rebuilt as a Matrix native > service > > rather than being a continuation of our existing irker based bot that > > occasionally has issues and falls off. > > > > Given that we are now fairly well migrated to Matrix, the need to > maintain > > our Telegram bridging is much reduced, and I'd therefore like to retire > > that without replacement. > > > > Hi > > IRC is still a supported part of KDE Community's chat/IM alongside Matrix > and we don't have any plans for that to change > Sorry if it wasn't clear - the migration I was referring to was away from Telegram (which is what this bridge served). > > We are however looking at some options with Libera.chat staff on improving > the situation currently where we are using the Matrix Foundation managed > public Libera bridge that isn't getting as much support & maintenance as it > could perhaps do with, due to a lack of resources available on the Matrix > side. A current issue is us not being able to bridge new Rooms/channels > which disconnects some of our community and is not an acceptable long term > situation > > As Fuchs pointed out it isn't Mattermost that we use for Telegram > bridging. Telegram is currently mainly using a mautrix-telegram bridge run > for us by EMS, this was only ever planned as a short term service to aid in > getting the users in the unofficial Telegram rooms to migrate over to > Matrix. Some rooms are still using the legacy Telegram <> IRC <> Matrix > bridging due to issues with the number of users in some rooms and broken > permissions on the Telegram side > Yes, this Mattermost bridge is the legacy bridge. > > The current situation with Community members using Telegram is that the > majority also have Matrix accounts that they use to take part in other > chats. This results in > a duplication in users in lots of our rooms that has negative impacts on > Matrix and IRC having to handle all these extra users/connections. The > Telegram bridge is also a major source of spam coming into us and onto IRC. > There isn't anything we can do to properly manage this as we have no > control over how Telegram is operated. > > The current plan is for the Telegram bridge to be decommissioned later > this year. We may consider alternative options for some outreach related > channels, but within KDE it is redundant > > > In terms of sKreamer, it's primary utility has been to provide > > announcements of Forum posts and bugbot services. With Matrix providing > > site previews, and the Forum in imminent replacement by Discourse, both > of > > these are no longer necessary - so I'd like to retire it without > > replacement as well. > > > > The only remaining service of contention here is the BNC, which has > > significantly less use now than it did many years ago - with only 30 > active > > connections at the time of writing. It therefore appears to be of much > less > > need than it was in years past, and I'd also like to retire it as well. > > > > I personally think we should keep operating BNC as we still have a large > number of our community who choose to use IRC and it is a valued service to > them > At this time only 6 people are connected to the BNC, so it appears the majority of the community members joining via IRC are maintaining their own solution for permanent presence, or don't consider it necessary? > > > Finally, many years ago (prior to my time in Sysadmin) we started > providing > > Jabber services for the domains KDETalk.net and KDE.org. Due to abuse > > however, we have for a long time had to have registration on KDETalk.net > > disabled (KDE.org was always a manual registration). Much like the BNC, > > this appears to only have 19 active clients at the time of writing. As > our > > official channel for chat is essentially Matrix now, I would like to > retire > > this as well. > > > > Together, all of these retirements will allow us to retire one of our > > smaller DigitalOcean servers (the load all of these generate is > > computationally small and thus cheap, however they do occupy mental > > headspace that is better served focusing on other areas of our > > infrastructure). > > > > Comments on the above? > > Cheers, Ben > > > > -- > > Kenny > (Pronouns: he/him) > > >
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Sun, May 21, 2023 at 11:05 PM Halla Rempt wrote: > On zondag 21 mei 2023 11:37:45 CEST Ben Cooksley wrote: > > > Depending on the level of community interest, we may opt to retain > > pursuivant however i'd like for it to be rebuilt as a Matrix native > service > > rather than being a continuation of our existing irker based bot that > > occasionally has issues and falls off. > > For Krita, we're still using irc in preference to matrix, since matrix is > more complicated to use and not as reliable. > > We'd really miss the bots telling us about new bug reports and fill in the > title of a bug or phab task (though it would be great if it could also fill > in gitlab mr's titles...) > Unfortunately the bot codebase for sKreamer is unmaintained by upstream, and written in Ruby - meaning it cannot be run on newer operating systems (as they use a newer - and incompatible - Ruby). Hence why i'm looking at decommissioning it, as the server in question has reached end of life support from it's distribution. > > Halla > > > Cheers, Ben
Re: Retirement of IRC Services and KDETalk.net (Jabber)
On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs) wrote: > Hi Ben, Hey Christian, > > > 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. > We're simply using something from the Mattermost stack to perform the bridging, it has nothing else to do with Mattermost. This bridge is the legacy Telegram <-> IRC bridge. It's configuration can be seen at https://invent.kde.org/sysadmin/irc-notifications/-/blob/master/telegram-bridge/channels.json and does not appear to contain any graphics related groups. Either way, those channels should migrate to the Matrix provided bridge if they still need bridging (ideally the Telegram channels would be shutdown as they're a significant source of abuse) > > Skreamer / Pursuivant: I'd retire these when the replacement is there, and > not > before it. I also seem to have missed which part does the auto > announcement of > e.g. bug reports, since that was active / fetching, and if I understand > site > previews correctly, that is passive. As in: no automatic notice of new bug > reports, but only when someone / something actively links them, correct? > Pursuivant is responsible for the announcement of commits and bugs. As of late we have only seen removals of this functionality (see https://invent.kde.org/sysadmin/irc-notifications/-/commits/master?ref_type=heads) from channels, hence why i'm slating it for decommissioning. > > Bouncer wise: 30 connections isn't exactly none, especially if that > contains > active people. These would be forced to migrate to a service (and register > at > such) which is not under KDEs control and, as far as I am aware, has a > mandatory registration. As far as memory serves some communities, e.g. I > think krita, still had active devs / maintainers on IRC. > Yes, there is a cost-benefit analysis to all services we run however - and if there is a minimal number of people benefiting from it, sometimes it is time to retire a service. Note that the 30 I quoted was a count of TCP connections - so included inbound and outbound links. The number of connected clients is much, much smaller - so it is possible there are some IRC connections still active for people that are no longer around, or who have moved to Matrix and not deactivated the BNC. > > I understand that we'd like to remove old cruft, but some parts of this > seem > to be in active use and low maintenance, so personally I wouldn't sunset > them, > at least not before a proper replacement is in place and not just planned. > Kind regards, > > Christian Cheers, Ben > > > Am Sonntag, 21. Mai 2023, 11:37:45 CEST schrieb Ben Cooksley: > > Hi all, > > > > For some time now, the level of use of our IRC services - notably being > > Pursuivant and the Telegram Matterbridge, but also including sKreamer - > has > > been on the decline. > > > > I'd therefore like to permanently retire all three of these services. > > > > Depending on the level of community interest, we may opt to retain > > pursuivant however i'd like for it to be rebuilt as a Matrix native > service > > rather than being a continuation of our existing irker based bot that > > occasionally has issues and falls off. > > > > Given that we are now fairly well migrated to Matrix, the need to > maintain > > our Telegram bridging is much reduced, and i'd therefore like to retire > > that without replacement. > > > > In terms of sKreamer, it's primary utility has been to provide > > announcements of Forum posts and bugbot services. With Matrix providing > > site previews, and the Forum in imminent replacement by Discourse, both > of > > these are no longer necessary - so i'd like to retire it without > > replacement as well. > > > > The only remaining service of contention here is the BNC, which has > > significantly less use now than it did many years ago - with only 30 > active > > connections at the time of writing. It therefore appears to be of much > less > > need than it was in years past, and i'd also like to retire it as well. > > > > Finally, many years ago (prior to my time in Sysadmin) we started > providing > > Jabber services for the domains KDETalk.net and KDE.or
Re: Retiring Phabricator - Migrating tasks to Gitlab
On Sun, May 21, 2023 at 10:10 PM Johnny Jazeix wrote: > Hi, > Le dim. 21 mai 2023 à 11:15, Ben Cooksley a écrit : > >> Hi all, >> >> As many of you will undoubtedly be aware, we currently have a bit of a >> hybrid approach with our use of GitLab, with some projects/areas still >> making use of Phabricator as they await the final import of these tasks >> across to GitLab. >> >> That time has now arrived, as Phabricator is long since unmaintained and >> needs to be retired. >> >> The only question is how this is best structured. >> >> My thinking on this had been to establish a mapping of Phabricator >> project to Gitlab project (with some Gitlab projects possibly receiving >> multiple Phabricator projects). Where necessary we would create >> groups/projects under teams/ on invent.kde.org to house these, otherwise >> they'd be imported into the mainline projects. >> >> For those projects currently using GitLab as a task tracking tool, any >> feedback you have on this would also be welcome. >> >> In terms of the migration, we'd be looking to retain as much information >> as possible, however things like the precise column a task has on a >> workboard would likely be lost. The actual content of the task including >> details such as time and authorship, along with any comments would be >> retained though. >> >> > Would there be a way to convert some columns as labels? For example, we > have columns "Junior Jobs" that would be nice to have as a label. > We could probably bring the column names across as labels yes. > Also, some phabricator tasks have hierarchy, is there an equivalent in > gitlab? There are tasks in gitlab too but I'm not sure it is always the > equivalent. > Gitlab tasks can be related/linked together (and this can hopefully be brought across), however they cannot be flagged as blocking/being blocked by other tasks. The functionality to create a task hierarchy through blocked relationships is only available in Gitlab EE. > > Cheers, > > Johnny > Thanks, Ben > > >> Thoughts? >> >> Thanks, >> Ben >> >
Retirement of IRC Services and KDETalk.net (Jabber)
Hi all, For some time now, the level of use of our IRC services - notably being Pursuivant and the Telegram Matterbridge, but also including sKreamer - has been on the decline. I'd therefore like to permanently retire all three of these services. Depending on the level of community interest, we may opt to retain pursuivant however i'd like for it to be rebuilt as a Matrix native service rather than being a continuation of our existing irker based bot that occasionally has issues and falls off. Given that we are now fairly well migrated to Matrix, the need to maintain our Telegram bridging is much reduced, and i'd therefore like to retire that without replacement. In terms of sKreamer, it's primary utility has been to provide announcements of Forum posts and bugbot services. With Matrix providing site previews, and the Forum in imminent replacement by Discourse, both of these are no longer necessary - so i'd like to retire it without replacement as well. The only remaining service of contention here is the BNC, which has significantly less use now than it did many years ago - with only 30 active connections at the time of writing. It therefore appears to be of much less need than it was in years past, and i'd also like to retire it as well. Finally, many years ago (prior to my time in Sysadmin) we started providing Jabber services for the domains KDETalk.net and KDE.org. Due to abuse however, we have for a long time had to have registration on KDETalk.net disabled (KDE.org was always a manual registration). Much like the BNC, this appears to only have 19 active clients at the time of writing. As our official channel for chat is essentially Matrix now, I would like to retire this as well. Together, all of these retirements will allow us to retire one of our smaller DigitalOcean servers (the load all of these generate is computationally small and thus cheap, however they do occupy mental headspace that is better served focusing on other areas of our infrastructure). Comments on the above? Thanks, Ben
Retiring Phabricator - Migrating tasks to Gitlab
Hi all, As many of you will undoubtedly be aware, we currently have a bit of a hybrid approach with our use of GitLab, with some projects/areas still making use of Phabricator as they await the final import of these tasks across to GitLab. That time has now arrived, as Phabricator is long since unmaintained and needs to be retired. The only question is how this is best structured. My thinking on this had been to establish a mapping of Phabricator project to Gitlab project (with some Gitlab projects possibly receiving multiple Phabricator projects). Where necessary we would create groups/projects under teams/ on invent.kde.org to house these, otherwise they'd be imported into the mainline projects. For those projects currently using GitLab as a task tracking tool, any feedback you have on this would also be welcome. In terms of the migration, we'd be looking to retain as much information as possible, however things like the precise column a task has on a workboard would likely be lost. The actual content of the task including details such as time and authorship, along with any comments would be retained though. Thoughts? Thanks, Ben
Re: WikiToLearn repos on invent
On Mon, May 15, 2023 at 8:50 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > Hi, > Hi Christoph, > > given the last activity is one or two years ago, > would it make sense to move the stuff in > > https://invent.kde.org/wikitolearn > > to > > https://invent.kde.org/unmaintained > > and archive it there until it is revived? > What we would probably do in this instance is just archive the entire WikiToLearn group/namespace where it is right now (after updating descriptions to make it clear this is all unmaintained). If there are no objections i'm happy to proceed with doing this. > > Greetings > Christoph > Cheers, Ben > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org >
Re: Inactive mailing lists
On Sat, Apr 29, 2023 at 4:13 AM Volker Krause wrote: > Lists that seem obsolete based on their subject: > - kdepim-builds: this was intended to receive Jenkins CI build errors, a > problem we no longer have. > - khtml-cvs: KHTML is gone in KF6 > - kde-scm-interest: this was used for coordinating the migration to Git, > something that is long done. > For those lists that are unquestionably no longer in use, please file a ticket and we'll get them removed. The list kde-dashboard can join the above list as no longer in use. > > Regards, > Volker > Cheers, Ben > > On Donnerstag, 27. April 2023 23:42:47 CEST Joseph P. De Veaugh-Geiss > wrote: > > Cross-posting to the relevant mailing lists. > > > > To discuss, please answer to kde-community@kde.org. > > > > tl;dr There are several inactive or unused lists of the 181 mailing > > lists at KDE. What do we want to do with them? > > > > This is a post about inactive or unused mailing lists. For a general > > discussion about (active) mailing lists at KDE, please start a new > > thread or wait until I address that, likely in the very near future. > > > > _Inactive Mailing Lists_ > > > > For a better understanding of what works and what needs improvement in > > KDE's internal communications, I started by looking at the 181 mailing > > lists publicly listed at: > > > >https://mail.kde.org/mailman/listinfo/ > > > > Here I see 51 mailing lists which might be considered inactive, some of > > which were never used at all. There may be more to add to this upon > > further inspection, but these seem like a good place to start. > > > > By inactive I mean there has been very low or no activity in the past > > 2-3 years at least, and for most lists the last post was 4+ years ago. > > For several of these lists, there are long gaps in activity, often with > > no community responses to the most recent posts. > > > > The 51 mailing lists are included at the end of this email. > > > > Importantly, I know a list with infrequent activity is *not* the same as > > a list that has no activity. Some communities do not need regular > > communication for that community to be active. If you see your > > community's mailing list here and think it is a mistake, please let me > > know! My apologies in advance if this is the case. > > > > Crucially, do not interpret an inactive mailing list to mean a project > > is inactive. It only means the mailing list is not a frequently used > > channel of communication. There are many other channels for community > > discussion (e.g., Matrix, Discuss, etc.). > > > > _Some Questions To The KDE Community_ > > > > * What do we want to do with inactive or unused mailing lists? > > > > * Is there a policy for retiring inactive lists? I didn't see anything > > at the Community Wiki. [1] > > > > * Does KDE have internal infrastructure to archive mailing lists for > > posterity? I see kwrite-devel [2] archived old posts at the "Mailing > > list ARChives" [3]. > > > > * Do we want to nudge traffic from low activity mailing lists to > > somewhere with generally higher activity (specifically, I am thinking > > Discuss)? I can imagine being in a more active online space could > > increase general participation for otherwise low activity groups. > > > > _Inactive Lists: To Close Or Not To Close_ > > > > I am sure there are reasons both for and against closing mailing lists. > > Here are just some reasons I can think of to close inactive ones: > > > > * The more communication channels there are, the more fractured KDE's > > communication is. > > > > * It may not be obvious to new (or even old) contributors that a list > > is no longer in use, resulting in wasted energy signing up for an > > inactive one. > > > > * Trying to engage with an inactive list may reduce motivation for > > futher contributions from members, especially when posts go unanswered. > > > > * Moving some communities to more lively platforms may increase their > > overall activity. > > > > * There could be a slight efficiency/ecological benefit for KDE's > > server infrastructure by removing or deactivating unused services. > > > > Pleae keep in mind: I am not judging the value of any particular group > > by pointing out low activity, or arguing we need to close any specific > > list. If there is a reason -- any reason at all -- to keep a list open, > > then let's keep it open! I myself like mailing lists for various forms > > of communication (announcements, long-form discussion, information which > > I want to archive locally for future reference, etc.). > > > > If I made any mistakes in my summary here, please let me know. It is a > > challenge to go through 181 lists and not make any errors, though I > > tried my best not to. > > > > I look forward to reading your thoughts and suggestions! > > > > Cheers, > > Joseph > > > > [1] https://community.kde.org/Infrastructure/Mailing-Lists > > [2] https://mail.kde.org/mailman/listinfo/kwrite-devel > > [3]
Re: Inactive mailing lists
HI Joseph, Couple of things to note here: 1) Some of these mailing lists deliberately have archiving disabled, so Mailman's archives cannot be relied on to determine if a list is still active or not. This is particularly the case for *-bugs mailing lists. I should note though that there is alternative functionality within Bugzilla that can replicate this functionality, so a mailing list does not have to be used here (although some may prefer this for their email filters) 2) Some of these lists are certainly defunct (kde-dashboard for one) and can definitely be closed down 3) Some of the lists are commit filter lists which are no longer operating (khtml-cvs for one) and should be archived. Cheers, Ben On Fri, Apr 28, 2023 at 9:52 AM Joseph P. De Veaugh-Geiss wrote: > Cross-posting to the relevant mailing lists. > > To discuss, please answer to kde-community@kde.org. > > tl;dr There are several inactive or unused lists of the 181 mailing > lists at KDE. What do we want to do with them? > > This is a post about inactive or unused mailing lists. For a general > discussion about (active) mailing lists at KDE, please start a new > thread or wait until I address that, likely in the very near future. > > _Inactive Mailing Lists_ > > For a better understanding of what works and what needs improvement in > KDE's internal communications, I started by looking at the 181 mailing > lists publicly listed at: > >https://mail.kde.org/mailman/listinfo/ > > Here I see 51 mailing lists which might be considered inactive, some of > which were never used at all. There may be more to add to this upon > further inspection, but these seem like a good place to start. > > By inactive I mean there has been very low or no activity in the past > 2-3 years at least, and for most lists the last post was 4+ years ago. > For several of these lists, there are long gaps in activity, often with > no community responses to the most recent posts. > > The 51 mailing lists are included at the end of this email. > > Importantly, I know a list with infrequent activity is *not* the same as > a list that has no activity. Some communities do not need regular > communication for that community to be active. If you see your > community's mailing list here and think it is a mistake, please let me > know! My apologies in advance if this is the case. > > Crucially, do not interpret an inactive mailing list to mean a project > is inactive. It only means the mailing list is not a frequently used > channel of communication. There are many other channels for community > discussion (e.g., Matrix, Discuss, etc.). > > _Some Questions To The KDE Community_ > > * What do we want to do with inactive or unused mailing lists? > > * Is there a policy for retiring inactive lists? I didn't see anything > at the Community Wiki. [1] > > * Does KDE have internal infrastructure to archive mailing lists for > posterity? I see kwrite-devel [2] archived old posts at the "Mailing > list ARChives" [3]. > > * Do we want to nudge traffic from low activity mailing lists to > somewhere with generally higher activity (specifically, I am thinking > Discuss)? I can imagine being in a more active online space could > increase general participation for otherwise low activity groups. > > _Inactive Lists: To Close Or Not To Close_ > > I am sure there are reasons both for and against closing mailing lists. > Here are just some reasons I can think of to close inactive ones: > > * The more communication channels there are, the more fractured KDE's > communication is. > > * It may not be obvious to new (or even old) contributors that a list > is no longer in use, resulting in wasted energy signing up for an > inactive one. > > * Trying to engage with an inactive list may reduce motivation for > futher contributions from members, especially when posts go unanswered. > > * Moving some communities to more lively platforms may increase their > overall activity. > > * There could be a slight efficiency/ecological benefit for KDE's > server infrastructure by removing or deactivating unused services. > > Pleae keep in mind: I am not judging the value of any particular group > by pointing out low activity, or arguing we need to close any specific > list. If there is a reason -- any reason at all -- to keep a list open, > then let's keep it open! I myself like mailing lists for various forms > of communication (announcements, long-form discussion, information which > I want to archive locally for future reference, etc.). > > If I made any mistakes in my summary here, please let me know. It is a > challenge to go through 181 lists and not make any errors, though I > tried my best not to. > > I look forward to reading your thoughts and suggestions! > > Cheers, > Joseph > > [1] https://community.kde.org/Infrastructure/Mailing-Lists > [2] https://mail.kde.org/mailman/listinfo/kwrite-devel > [3] https://marc.info/ > > # Overview > > Of the 181 mailing lists listed publicly, I
Re: Github bridge broken?
Hi all, Just as a FYI for those wondering, I took a look and it seems to be syncing fine, not sure why Halla saw the outdated screenshot. Cheers, Ben On Sun, Apr 23, 2023 at 8:55 PM Halla Rempt wrote: > Hi, > > It looks like the github bridge has been broken for two weeks? Or was it > intentionally disabled? I don't care much about it, but I was using the > pulse statistics for our meeting documents. And if it's intentional, maybe > we should lock or hide or remove the repositories? > > Halla > >
Forks cleanup
Hi all, While doing some routine maintenance and system assessments on our Gitlab instance over the past week, it has become apparent that in certain circumstances the de-duplication of objects between parent repositories and their forks does not work correctly in some circumstances. While this isn't a significant issue as the system is well oversized to handle growth, it is causing backups to take longer than they should to run and makes certain estimates of future resource needs difficult to determine. It would therefore be appreciated if people could please remove any forks they are no longer using. If the fork in question is in the below list, please consider recreating your fork (by deleting it and creating a new one) when the opportunity next arises. This especially applies if you have a fork of any of the following projects: - websites/kde-org - graphics/krita - graphics/digikam - education/kstars - documentation/digikam-doc Thanks, Ben
Re: Website migrations
On Wed, Mar 8, 2023 at 8:49 PM Jasem Mutlaq wrote: > Hello Ben, > Hi Jasem, > > https://edu.kde.org/kstars still points to > https://apps.kde.org/categories/education/kstars which is 404 pages. > Shouldn't it point to https://apps.kde.org/kstars ? > This has all since been resolved. > > -- > Best Regards, > Jasem Mutlaq > Regards, Ben > > > > On Tue, Mar 7, 2023 at 9:13 PM Ben Cooksley wrote: > >> On Wed, Mar 8, 2023 at 4:04 AM Jasem Mutlaq >> wrote: >> >>> Hello Ben, >>> >> >> Hi Jasem, >> >> >>> >>> We need a permanent redirect from https://edu.kde.org/kstars to the new >>> address. Now users are reporting that KStars is unreachable from search >>> engines. There are numerous sites that are linked to >>> https://edu.kde.org/kstars and you can't expect thousands of websites >>> to update their URLs. >>> >> >> As mentioned in #kde-sysadmin this is now in place. >> >> >>> >>> -- >>> Best Regards, >>> Jasem Mutlaq >>> >> >> Regards, >> Ben >> >> >>> >>> >>> >>> On Mon, Feb 27, 2023 at 1:33 PM Ben Cooksley wrote: >>> >>>> Hi all, >>>> >>>> This is just a heads up that I have now completed the vast majority of >>>> the remaining site migrations from the old server (Nicoda) to the new >>>> server (Tyran). >>>> >>>> The below domains should now be showing their updated contents: >>>> rewrite zones/calligra-suite.org.zone (98%) >>>> rewrite zones/calligra.org.zone (98%) >>>> rewrite zones/commit-digest.com.zone (96%) >>>> rewrite zones/commit-digest.org.zone (96%) >>>> rewrite zones/desktopsummit.org.zone (96%) >>>> rewrite zones/digikam.org.zone (98%) >>>> rewrite zones/falkon.org.zone (96%) >>>> rewrite zones/frameworks.org.zone (98%) >>>> rewrite zones/inqlude.org.zone (98%) >>>> rewrite zones/k3b.org.zone (96%) >>>> rewrite zones/kaddressbook.com.zone (98%) >>>> rewrite zones/kaddressbook.org.zone (98%) >>>> rewrite zones/kate-editor.org.zone (96%) >>>> rewrite zones/kde-china.org.zone (96%) >>>> rewrite zones/kde-edu.org.zone (98%) >>>> rewrite zones/kde.be.zone (96%) >>>> rewrite zones/kde.ca.zone (96%) >>>> rewrite zones/kde.eu.zone (96%) >>>> rewrite zones/kde.gr.jp.zone (96%) >>>> rewrite zones/kde.in.zone (96%) >>>> rewrite zones/kde.it.zone (96%) >>>> rewrite zones/kde.org.pl.zone (87%) >>>> rewrite zones/kde.ru.zone (64%) >>>> rewrite zones/kdeedu.org.zone (98%) >>>> rewrite zones/kdeitalia.it.zone (96%) >>>> rewrite zones/kdenews.org.zone (96%) >>>> rewrite zones/kdenlive.org.zone (98%) >>>> rewrite zones/kdepim.com.zone (96%) >>>> rewrite zones/kdepim.org.zone (96%) >>>> rewrite zones/kexi-project.org.zone (96%) >>>> rewrite zones/kirogi.org.zone (95%) >>>> rewrite zones/kmymoney.org.zone (96%) >>>> rewrite zones/koffice.org.zone (96%) >>>> rewrite zones/konqueror.com.zone (99%) >>>> rewrite zones/konqueror.org.zone (98%) >>>> rewrite zones/kontact.org.zone (96%) >>>> rewrite zones/korganizer.org.zone (96%) >>>> rewrite zones/kphotoalbum.org.zone (98%) >>>> rewrite zones/krusader.org.zone (96%) >>>> rewrite zones/kstuff.org.zone (98%) >>>> rewrite zones/openraster.org.zone (98%) >>>> rewrite zones/planetkde.org.zone (98%) >>>> rewrite zones/plasma-active.org.zone (96%) >>>> rewrite zones/plasma-bigscreen.org.zone (96%) >>>> rewrite zones/plasma-desktop.org.zone (96%) >>>> rewrite zones/plasma-mobile.org.zone (96%) >>>> rewrite zones/qtcon.org.zone (97%) >>>> rewrite zones/rolisteam.org.zone (98%) >>>> rewrite zones/skrooge.org.zone (98%) >>>> >>>> Of all of our sites, that leaves only the following left to migrate: >>>> - kpdf.kde.org >>>> - kst-plot.kde.org >>>> - umbrello.kde.org >>>> - edu.kde.org >>>> - docs.kde.org >>>> >>>> I will be looking into refreshing the static copies made previously of >>>> KPDF and KstPlot tomorrow, after which they will be transferred, and will >>>> then do the necessary testing for docs.kde.org as well. >>>> >>>> Unfortunately umbrello.kde.org has a hard dependency on Capacity and >>>> is built in such a way that it is incompatible with being made static. >>>> That site will therefore be removed from DNS and discontinued. >>>> >>>> Likewise, from my understanding with one exception the entire contents >>>> of edu.kde.org are being replaced by redirects to apps.kde.org, so >>>> that site will not be cutover. >>>> KStars developers: you need to urgently resolve the site migration >>>> issues for edu.kde.org as I understand you are the blocker there, as >>>> the old server will not be kept online to serve edu.kde.org alone. >>>> >>>> Thanks, >>>> Ben >>>> >>>> >>>> >>>> >>>> >>>>
Re: Website migrations
On Wed, Mar 8, 2023 at 4:04 AM Jasem Mutlaq wrote: > Hello Ben, > Hi Jasem, > > We need a permanent redirect from https://edu.kde.org/kstars to the new > address. Now users are reporting that KStars is unreachable from search > engines. There are numerous sites that are linked to > https://edu.kde.org/kstars and you can't expect thousands of websites to > update their URLs. > As mentioned in #kde-sysadmin this is now in place. > > -- > Best Regards, > Jasem Mutlaq > Regards, Ben > > > > On Mon, Feb 27, 2023 at 1:33 PM Ben Cooksley wrote: > >> Hi all, >> >> This is just a heads up that I have now completed the vast majority of >> the remaining site migrations from the old server (Nicoda) to the new >> server (Tyran). >> >> The below domains should now be showing their updated contents: >> rewrite zones/calligra-suite.org.zone (98%) >> rewrite zones/calligra.org.zone (98%) >> rewrite zones/commit-digest.com.zone (96%) >> rewrite zones/commit-digest.org.zone (96%) >> rewrite zones/desktopsummit.org.zone (96%) >> rewrite zones/digikam.org.zone (98%) >> rewrite zones/falkon.org.zone (96%) >> rewrite zones/frameworks.org.zone (98%) >> rewrite zones/inqlude.org.zone (98%) >> rewrite zones/k3b.org.zone (96%) >> rewrite zones/kaddressbook.com.zone (98%) >> rewrite zones/kaddressbook.org.zone (98%) >> rewrite zones/kate-editor.org.zone (96%) >> rewrite zones/kde-china.org.zone (96%) >> rewrite zones/kde-edu.org.zone (98%) >> rewrite zones/kde.be.zone (96%) >> rewrite zones/kde.ca.zone (96%) >> rewrite zones/kde.eu.zone (96%) >> rewrite zones/kde.gr.jp.zone (96%) >> rewrite zones/kde.in.zone (96%) >> rewrite zones/kde.it.zone (96%) >> rewrite zones/kde.org.pl.zone (87%) >> rewrite zones/kde.ru.zone (64%) >> rewrite zones/kdeedu.org.zone (98%) >> rewrite zones/kdeitalia.it.zone (96%) >> rewrite zones/kdenews.org.zone (96%) >> rewrite zones/kdenlive.org.zone (98%) >> rewrite zones/kdepim.com.zone (96%) >> rewrite zones/kdepim.org.zone (96%) >> rewrite zones/kexi-project.org.zone (96%) >> rewrite zones/kirogi.org.zone (95%) >> rewrite zones/kmymoney.org.zone (96%) >> rewrite zones/koffice.org.zone (96%) >> rewrite zones/konqueror.com.zone (99%) >> rewrite zones/konqueror.org.zone (98%) >> rewrite zones/kontact.org.zone (96%) >> rewrite zones/korganizer.org.zone (96%) >> rewrite zones/kphotoalbum.org.zone (98%) >> rewrite zones/krusader.org.zone (96%) >> rewrite zones/kstuff.org.zone (98%) >> rewrite zones/openraster.org.zone (98%) >> rewrite zones/planetkde.org.zone (98%) >> rewrite zones/plasma-active.org.zone (96%) >> rewrite zones/plasma-bigscreen.org.zone (96%) >> rewrite zones/plasma-desktop.org.zone (96%) >> rewrite zones/plasma-mobile.org.zone (96%) >> rewrite zones/qtcon.org.zone (97%) >> rewrite zones/rolisteam.org.zone (98%) >> rewrite zones/skrooge.org.zone (98%) >> >> Of all of our sites, that leaves only the following left to migrate: >> - kpdf.kde.org >> - kst-plot.kde.org >> - umbrello.kde.org >> - edu.kde.org >> - docs.kde.org >> >> I will be looking into refreshing the static copies made previously of >> KPDF and KstPlot tomorrow, after which they will be transferred, and will >> then do the necessary testing for docs.kde.org as well. >> >> Unfortunately umbrello.kde.org has a hard dependency on Capacity and is >> built in such a way that it is incompatible with being made static. >> That site will therefore be removed from DNS and discontinued. >> >> Likewise, from my understanding with one exception the entire contents of >> edu.kde.org are being replaced by redirects to apps.kde.org, so that >> site will not be cutover. >> KStars developers: you need to urgently resolve the site migration issues >> for edu.kde.org as I understand you are the blocker there, as the old >> server will not be kept online to serve edu.kde.org alone. >> >> Thanks, >> Ben >> >> >> >> >> >>
Website migrations
Hi all, This is just a heads up that I have now completed the vast majority of the remaining site migrations from the old server (Nicoda) to the new server (Tyran). The below domains should now be showing their updated contents: rewrite zones/calligra-suite.org.zone (98%) rewrite zones/calligra.org.zone (98%) rewrite zones/commit-digest.com.zone (96%) rewrite zones/commit-digest.org.zone (96%) rewrite zones/desktopsummit.org.zone (96%) rewrite zones/digikam.org.zone (98%) rewrite zones/falkon.org.zone (96%) rewrite zones/frameworks.org.zone (98%) rewrite zones/inqlude.org.zone (98%) rewrite zones/k3b.org.zone (96%) rewrite zones/kaddressbook.com.zone (98%) rewrite zones/kaddressbook.org.zone (98%) rewrite zones/kate-editor.org.zone (96%) rewrite zones/kde-china.org.zone (96%) rewrite zones/kde-edu.org.zone (98%) rewrite zones/kde.be.zone (96%) rewrite zones/kde.ca.zone (96%) rewrite zones/kde.eu.zone (96%) rewrite zones/kde.gr.jp.zone (96%) rewrite zones/kde.in.zone (96%) rewrite zones/kde.it.zone (96%) rewrite zones/kde.org.pl.zone (87%) rewrite zones/kde.ru.zone (64%) rewrite zones/kdeedu.org.zone (98%) rewrite zones/kdeitalia.it.zone (96%) rewrite zones/kdenews.org.zone (96%) rewrite zones/kdenlive.org.zone (98%) rewrite zones/kdepim.com.zone (96%) rewrite zones/kdepim.org.zone (96%) rewrite zones/kexi-project.org.zone (96%) rewrite zones/kirogi.org.zone (95%) rewrite zones/kmymoney.org.zone (96%) rewrite zones/koffice.org.zone (96%) rewrite zones/konqueror.com.zone (99%) rewrite zones/konqueror.org.zone (98%) rewrite zones/kontact.org.zone (96%) rewrite zones/korganizer.org.zone (96%) rewrite zones/kphotoalbum.org.zone (98%) rewrite zones/krusader.org.zone (96%) rewrite zones/kstuff.org.zone (98%) rewrite zones/openraster.org.zone (98%) rewrite zones/planetkde.org.zone (98%) rewrite zones/plasma-active.org.zone (96%) rewrite zones/plasma-bigscreen.org.zone (96%) rewrite zones/plasma-desktop.org.zone (96%) rewrite zones/plasma-mobile.org.zone (96%) rewrite zones/qtcon.org.zone (97%) rewrite zones/rolisteam.org.zone (98%) rewrite zones/skrooge.org.zone (98%) Of all of our sites, that leaves only the following left to migrate: - kpdf.kde.org - kst-plot.kde.org - umbrello.kde.org - edu.kde.org - docs.kde.org I will be looking into refreshing the static copies made previously of KPDF and KstPlot tomorrow, after which they will be transferred, and will then do the necessary testing for docs.kde.org as well. Unfortunately umbrello.kde.org has a hard dependency on Capacity and is built in such a way that it is incompatible with being made static. That site will therefore be removed from DNS and discontinued. Likewise, from my understanding with one exception the entire contents of edu.kde.org are being replaced by redirects to apps.kde.org, so that site will not be cutover. KStars developers: you need to urgently resolve the site migration issues for edu.kde.org as I understand you are the blocker there, as the old server will not be kept online to serve edu.kde.org alone. Thanks, Ben
Re: Retirement of Capacity
Hi all, The time has just about arrived for us to make the switch over to the new server. The following sites will be turned into static HTML over the next 24-48 hours: conference2004.kde.org conference2005.kde.org akademy2006.kde.org akademy2007.kde.org akademy2008.kde.org akademy2009.kde.org kpdf.kde.org kst-plot.kde.org umbrello.kde.org marble.kde.org Following their conversion, the website repositories will then be archived - freezing them in time. >From what I understand, the following sites already have migration plans in place to switch to Hugo - if those could please be expedited that would be appreciated: edu.kde.org That leaves just one lone site making use of Capacity: docs.kde.org As docs.kde.org only uses Capacity for it's front page, and the majority of accesses are directly to the underlying documentation that site will remain unchanged however as Capacity will be unavailable in the new environment the index (which is the only part relying on Capacity) will not be functional. As it will take a week or so to ensure everything is settled in on the new site those two sites (edu and docs) will be left on the old server until it is necessary to shut them down. Please note that once the switch is done neither site will update from it's existing contents. Let me know if there are any queries on the above. Thanks, Ben
Updates to various web services
Good morning Community, Over the past 48 hours a number of services have been transferred from the former home to a new system, as part of Sysadmin's program to replace servers which are running older distribution releases (and to get us on newer hardware). This includes: - All Wikis (techbase, userbase, community and gcompris-cookbook) - All Wordpress sites (krita.org, kdenlive.org, labplot.kde.org, blog.neon.kde.org and mauikit.org) - All Drupal 7 sites (dot.kde.org, akademy.kde.org, blogs.kde.org and behindkde.org) - Our Website Statistics system, Matomo (stats.kde.org) - Our Survey Platform, Limesurvey (survey.kde.org) - The Season of KDE program management software (season.kde.org) As part of this, our Mediawiki instances were also upgraded to the latest LTS version (1.39.1) including associated plugins. In the case of the Translation side of the Wikis, a substantial update to them was required. Because the new server has no connection with Identity (as part of our efforts to decommission this service) the Akademy site was also switched to use classical Drupal authentication as part of this migration. Anyone who needs to login to akademy.kde.org will therefore need to perform a password reset before they can login. This is only a temporary measure as work is underway (as part of our elimination of Drupal efforts) to migrate the Akademy site to Hugo. Should you notice any issues with the above sites, please let us know. Many thanks, Ben
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Mon, Jan 16, 2023 at 12:08 PM Phu Hung Nguyen wrote: > On 15/01/2023 08:04, bcooks...@kde.org wrote: > > For blogs.kde.org, I am in two minds as to the best approach here, with > > Wordpress and Hugo both appearing as candidates for this site. > > Opinions welcome, especially if you are someone that currently uses it. > > I don't use this site, so I'm not gonna pick WordPress or Hugo. However, > if Hugo is selected, I can do the porting to Hugo. > At this point it is looking like Hugo may be the preferred candidate for blogs.kde.org, but we'll see if anyone else has a view first. > > Best, > Phu > Regards, Ben
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Mon, Jan 16, 2023 at 9:28 PM Milian Wolff wrote: > On Sonntag, 15. Januar 2023 08:04:18 CET Ben Cooksley wrote: > > Hi all, > > > > > In the case of KDevelop and Skrooge, it would make the most sense to > > convert them both into Hugo websites to minimise the long term > maintenance > > cost and to make them part of the KDE family of sites. > > If anyone would like to work on this please contact me and I will arrange > > for a sanitized database copy to be made available to you. > > > > In the event that doesn't happen, converting them into static sites seems > > like the best path forward. > > I agree, we really need to make the kdevelop website a static one. One way > or > another, can you please send me the database copy already such that we > keep > that state archived at least? > Sysadmin keeps an archive of all infrastructure we decommission, which this will be included in. It will sit alongside the old akademy2010-2012 Drupal 6 sites (since made static), a backup copy of Bugzilla made prior to the upgrade from 3.2, a backup copy of Reviewboard made prior to our transition to Phabricator and even a copy of our CVS repository (if there is a service we have discontinued, odds are it has ended up in the archive) I can send you a copy of the site database and files if you'd like though. > > Do we have a tool or someone with basic knowledge of converting from > Drupal 8 > to Hugo? I have limited time for this, but before the website gets nuked > completely, I'll try to find some time to at least get a basic static > version > out and up and running. But any help would be really appreciated on that > front. > https://github.com/danapsimer/drupal2hugo is your friend there I believe. > > Thanks > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Thanks, Ben
Re: Retirement of Capacity
On Mon, Jan 16, 2023 at 6:17 AM Eugen Mohr wrote: > Hi Ben > > We use https://docs.kde.org/trunk5/en/kdenlive/kdenlive/index.html and > https://docs.kde.org/stable5/en/kdenlive/kdenlive/index.html in Kdenlive > source code. > > What is the procedure to point direct from Kdenlive source code to: > https://docs.kdenlive.org/ and > https://docs.kdenlive.org/en/getting_started/quickstart.html ? > We'll need to address that in a separate thread as that is outside the scope of this thread, but it depends on what you are trying to achieve here. Thanks, Ben > Eugen > Am 15.01.2023 um 07:54 schrieb Jumpei Ogawa: > > Hi Ben, > > jp.kde.org is already replaced with Jekyll and it no longer depend on > Capacity. > > Best regards, > Jumpei > > On Sun, Jan 15, 2023, 15:37 Ben Cooksley wrote: > >> Hi all, >> >> Since time immemorial, KDE has had a custom PHP framework known as >> Capacity which we've used to build a good number of our websites. >> >> With the rise of Static Site Generators such as Jekyll and Hugo though, >> we've been phasing this out and given that Hugo especially is now well >> established as the go-to-tooling for building KDE websites, it is time we >> retire Capacity. >> >> In addition, in the next few weeks the current server for our >> static/capacity sites, Nicoda, will be replaced by a new system (Tyran) >> that is currently awaiting configuration and i'd very much prefer to not >> have to deploy legacy Capacity support there. >> >> I have checked our server configuration this evening and it looks like >> the following sites still rely on Capacity in some form or another: >> >> konversation.kde.org >> pe.kde.org >> marble.kde.org >> kmplayer.kde.org >> www.kde.org >> games.kde.org >> docs.kde.org >> czechia.kde.org >> freebsd.kde.org >> kmymoney.org >> edu.kde.org >> multimedia.kde.org >> ro.kde.org >> konqueror.org >> kpdf.kde.org >> jp.kde.org >> utils.kde.org >> events.kde.org >> kst-plot.kde.org >> conference2004.kde.org >> conference2005.kde.org >> akademy2006.kde.org >> akademy2007.kde.org >> akademy2008.kde.org >> akademy2009.kde.org >> www-staging.kde.org >> il.kde.org >> umbrello.kde.org >> krusader.org >> ev.kde.org >> okular.kde.org >> kdemail.net >> extragear.kde.org >> lakademy.kde.org >> kphotoalbum.org >> >> Having a quick look through the repositories/sites, I see: >> - Some that have already made the jump to Hugo/Jekyll (so likely just >> need their Capacity support switched off) >> - Some that are just redirects to apps.kde.org or elsewhere, and >> therefore just need Capacity support switched off (and probably the >> repository archived on invent.kde.org too) >> - Others where the site content is still in Subversion and the site talks >> about Maemo (eek!) >> - Others where the site content is many years out of date and it is >> probably best we just redirect it to www.kde.org / apps.kde.org. >> >> It would be appreciated if people could please take a look through these >> sites. >> >> For the akademy2xxx.kde.org sites, it would be nice if we could get >> their content migrated and incorporated into the new Hugo based >> akademy.kde.org site, but in the absence of that I will be turning them >> into static sites >> >> Many thanks, >> Ben >> >
Re: Retirement of Capacity
On Mon, Jan 16, 2023 at 7:02 AM Albert Astals Cid wrote: > El diumenge, 15 de gener de 2023, a les 7:36:03 (CET), Ben Cooksley va > escriure: > > Hi all, > > > > Since time immemorial, KDE has had a custom PHP framework known as > Capacity > > which we've used to build a good number of our websites. > > > > With the rise of Static Site Generators such as Jekyll and Hugo though, > > we've been phasing this out and given that Hugo especially is now well > > established as the go-to-tooling for building KDE websites > > > it is time we retire Capacity. > > Why? The code is there and it works. It seems we're giving ourselves lots > of > work for what is really just a "few" lines of PHP. > It's a bit more than that. On the server side, Capacity requires a very unique configuration that is often incompatible with other systems due to it requiring certain PHP settings be set (include path being particularly important) and needing directories aliased in. This often breaks other software, necessitating the use of a separate PHP FPM worker pool for Capacity, and specific configuration within that website Apache configuration. Given the shrinking list of sites using it, we're now reaching the point where it makes more sense to eliminate our use of it rather than continue to support it and the additional costs associated with it. Secondly, switching to Hugo allows us to utilise a common Aether theme and therefore share a common visual design language across our sites, creating consistency which is always a benefit. > > Cheers, > Albert > Thanks, Ben > > > > > In addition, in the next few weeks the current server for our > > static/capacity sites, Nicoda, will be replaced by a new system (Tyran) > > that is currently awaiting configuration and i'd very much prefer to not > > have to deploy legacy Capacity support there. > > > > I have checked our server configuration this evening and it looks like > the > > following sites still rely on Capacity in some form or another: > > > > konversation.kde.org > > pe.kde.org > > marble.kde.org > > kmplayer.kde.org > > www.kde.org > > games.kde.org > > docs.kde.org > > czechia.kde.org > > freebsd.kde.org > > kmymoney.org > > edu.kde.org > > multimedia.kde.org > > ro.kde.org > > konqueror.org > > kpdf.kde.org > > jp.kde.org > > utils.kde.org > > events.kde.org > > kst-plot.kde.org > > conference2004.kde.org > > conference2005.kde.org > > akademy2006.kde.org > > akademy2007.kde.org > > akademy2008.kde.org > > akademy2009.kde.org > > www-staging.kde.org > > il.kde.org > > umbrello.kde.org > > krusader.org > > ev.kde.org > > okular.kde.org > > kdemail.net > > extragear.kde.org > > lakademy.kde.org > > kphotoalbum.org > > > > Having a quick look through the repositories/sites, I see: > > - Some that have already made the jump to Hugo/Jekyll (so likely just > need > > their Capacity support switched off) > > - Some that are just redirects to apps.kde.org or elsewhere, and > therefore > > just need Capacity support switched off (and probably the repository > > archived on invent.kde.org too) > > - Others where the site content is still in Subversion and the site talks > > about Maemo (eek!) > > - Others where the site content is many years out of date and it is > > probably best we just redirect it to www.kde.org / apps.kde.org. > > > > It would be appreciated if people could please take a look through these > > sites. > > > > For the akademy2xxx.kde.org sites, it would be nice if we could get > their > > content migrated and incorporated into the new Hugo based > akademy.kde.org > > site, but in the absence of that I will be turning them into static sites > > > > Many thanks, > > Ben > > > > >
Re: Retirement of Capacity
On Sun, Jan 15, 2023 at 7:54 PM Jumpei Ogawa wrote: > Hi Ben, > > jp.kde.org is already replaced with Jekyll and it no longer depend on > Capacity. > Thanks for advising Jumpei, i've now removed the Capacity support from jp.kde.org. > > Best regards, > Jumpei > Thanks, Ben > > On Sun, Jan 15, 2023, 15:37 Ben Cooksley wrote: > >> Hi all, >> >> Since time immemorial, KDE has had a custom PHP framework known as >> Capacity which we've used to build a good number of our websites. >> >> With the rise of Static Site Generators such as Jekyll and Hugo though, >> we've been phasing this out and given that Hugo especially is now well >> established as the go-to-tooling for building KDE websites, it is time we >> retire Capacity. >> >> In addition, in the next few weeks the current server for our >> static/capacity sites, Nicoda, will be replaced by a new system (Tyran) >> that is currently awaiting configuration and i'd very much prefer to not >> have to deploy legacy Capacity support there. >> >> I have checked our server configuration this evening and it looks like >> the following sites still rely on Capacity in some form or another: >> >> konversation.kde.org >> pe.kde.org >> marble.kde.org >> kmplayer.kde.org >> www.kde.org >> games.kde.org >> docs.kde.org >> czechia.kde.org >> freebsd.kde.org >> kmymoney.org >> edu.kde.org >> multimedia.kde.org >> ro.kde.org >> konqueror.org >> kpdf.kde.org >> jp.kde.org >> utils.kde.org >> events.kde.org >> kst-plot.kde.org >> conference2004.kde.org >> conference2005.kde.org >> akademy2006.kde.org >> akademy2007.kde.org >> akademy2008.kde.org >> akademy2009.kde.org >> www-staging.kde.org >> il.kde.org >> umbrello.kde.org >> krusader.org >> ev.kde.org >> okular.kde.org >> kdemail.net >> extragear.kde.org >> lakademy.kde.org >> kphotoalbum.org >> >> Having a quick look through the repositories/sites, I see: >> - Some that have already made the jump to Hugo/Jekyll (so likely just >> need their Capacity support switched off) >> - Some that are just redirects to apps.kde.org or elsewhere, and >> therefore just need Capacity support switched off (and probably the >> repository archived on invent.kde.org too) >> - Others where the site content is still in Subversion and the site talks >> about Maemo (eek!) >> - Others where the site content is many years out of date and it is >> probably best we just redirect it to www.kde.org / apps.kde.org. >> >> It would be appreciated if people could please take a look through these >> sites. >> >> For the akademy2xxx.kde.org sites, it would be nice if we could get >> their content migrated and incorporated into the new Hugo based >> akademy.kde.org site, but in the absence of that I will be turning them >> into static sites >> >> Many thanks, >> Ben >> >
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Sun, Jan 15, 2023 at 10:21 PM Paul Brown wrote: > On Sunday, 15 January 2023 08:04:18 CET Ben Cooksley wrote: > > Hi all, > > > > For some time now it has been known to us that the upgrade path from one > > given Drupal major version to the next is usually a very difficult road > > with lots of breakage involved. > > The conversion from Drupal 7 or 8 to Drupal 9 is no different in this > > regard - basically being a content export and then reimport. > > > > Due to the level of disruption and risk of breakage involved this isn't > > something done lightly but with the end of support for Drupal 8 and the > > incoming end of support for Drupal 7 we need to take action on this > sooner > > rather later. > > > > At this time I'm only focusing on the smaller sites, so akademy.kde.org > (in > > the process of moving to Hugo) and dot.kde.org (to be figured out) are > out > > of scope for this email. > > > > We currently have the following sites running on Drupal 7/8: > > - dot.kde.org > > - akademy.kde.org > > - kdevelop.org > > - skrooge.org > > - behindkde.org > > - blogs.kde.org > > > > Given that promo is currently not making active use of the site, at this > > time my intention is to create a static archive of behindkde.org. > > > > In the case of KDevelop and Skrooge, it would make the most sense to > > convert them both into Hugo websites to minimise the long term > maintenance > > cost and to make them part of the KDE family of sites. > > If anyone would like to work on this please contact me and I will arrange > > for a sanitized database copy to be made available to you. > > > > In the event that doesn't happen, converting them into static sites seems > > like the best path forward. > > Hi Ben, > Hi Paul, > > Drupal is, not to put too fine a point on it, terrible in every > conceivable way > and we dread having to post to the dot. We welcome the transition away > from > it. > > Promo has repeatedly asked for WordPress to supersede Drupal for the Dot, > as > we have found creating content for a Hugo site (something we do at least > every > 2 months for KDE Gear and Plasma announcements) difficult, inflexible, > slow, > convoluted, and error-prone. So not much better than Drupal. > > As there are already several WordPress-based websites on the KDE > infrastructure, such as hattps://labplot.kde.org and https://kdenlive.org, > we > think that having this is not too much to ask. > As noted in my email we'll be tackling the Dot in a separate thread, this is about the smaller sites for now. Points duly noted though. > > Cheers > > Paul > Regards. Ben > -- > Promotion & Communication > > www: http://kde.org > Mastodon: https://floss.social/@kde > Facebook: https://www.facebook.com/kde/ > Twitter: https://twitter.com/kdecommunity > LinkedIn: https://www.linkedin.com/company/kde > > >
Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
Hi all, For some time now it has been known to us that the upgrade path from one given Drupal major version to the next is usually a very difficult road with lots of breakage involved. The conversion from Drupal 7 or 8 to Drupal 9 is no different in this regard - basically being a content export and then reimport. Due to the level of disruption and risk of breakage involved this isn't something done lightly but with the end of support for Drupal 8 and the incoming end of support for Drupal 7 we need to take action on this sooner rather later. At this time I'm only focusing on the smaller sites, so akademy.kde.org (in the process of moving to Hugo) and dot.kde.org (to be figured out) are out of scope for this email. We currently have the following sites running on Drupal 7/8: - dot.kde.org - akademy.kde.org - kdevelop.org - skrooge.org - behindkde.org - blogs.kde.org Given that promo is currently not making active use of the site, at this time my intention is to create a static archive of behindkde.org. In the case of KDevelop and Skrooge, it would make the most sense to convert them both into Hugo websites to minimise the long term maintenance cost and to make them part of the KDE family of sites. If anyone would like to work on this please contact me and I will arrange for a sanitized database copy to be made available to you. In the event that doesn't happen, converting them into static sites seems like the best path forward. For blogs.kde.org, I am in two minds as to the best approach here, with Wordpress and Hugo both appearing as candidates for this site. Opinions welcome, especially if you are someone that currently uses it. Comments/thoughts? Thanks, Ben
Retirement of Capacity
Hi all, Since time immemorial, KDE has had a custom PHP framework known as Capacity which we've used to build a good number of our websites. With the rise of Static Site Generators such as Jekyll and Hugo though, we've been phasing this out and given that Hugo especially is now well established as the go-to-tooling for building KDE websites, it is time we retire Capacity. In addition, in the next few weeks the current server for our static/capacity sites, Nicoda, will be replaced by a new system (Tyran) that is currently awaiting configuration and i'd very much prefer to not have to deploy legacy Capacity support there. I have checked our server configuration this evening and it looks like the following sites still rely on Capacity in some form or another: konversation.kde.org pe.kde.org marble.kde.org kmplayer.kde.org www.kde.org games.kde.org docs.kde.org czechia.kde.org freebsd.kde.org kmymoney.org edu.kde.org multimedia.kde.org ro.kde.org konqueror.org kpdf.kde.org jp.kde.org utils.kde.org events.kde.org kst-plot.kde.org conference2004.kde.org conference2005.kde.org akademy2006.kde.org akademy2007.kde.org akademy2008.kde.org akademy2009.kde.org www-staging.kde.org il.kde.org umbrello.kde.org krusader.org ev.kde.org okular.kde.org kdemail.net extragear.kde.org lakademy.kde.org kphotoalbum.org Having a quick look through the repositories/sites, I see: - Some that have already made the jump to Hugo/Jekyll (so likely just need their Capacity support switched off) - Some that are just redirects to apps.kde.org or elsewhere, and therefore just need Capacity support switched off (and probably the repository archived on invent.kde.org too) - Others where the site content is still in Subversion and the site talks about Maemo (eek!) - Others where the site content is many years out of date and it is probably best we just redirect it to www.kde.org / apps.kde.org. It would be appreciated if people could please take a look through these sites. For the akademy2xxx.kde.org sites, it would be nice if we could get their content migrated and incorporated into the new Hugo based akademy.kde.org site, but in the absence of that I will be turning them into static sites Many thanks, Ben
Re: GItlab update
On Mon, Jan 9, 2023 at 1:05 AM Thomas Baumgart wrote: > On Sonntag, 8. Januar 2023 11:03:09 CET Ben Cooksley wrote: > > > Hi all, > > > > This evening I updated our Gitlab instance at invent.kde.org to the > latest > > version - 15.7.1. > > The release notes for this can be found at > > https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/ > > > > Of particular note for folks are the following: > > - Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/ > > - Using a SSH key to sign your commits: > > https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/ > > - New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/ > (based > > on VS Code) > > > > Please note that the new VS Code based Web IDE is currently in beta, if > you > > experience issues with it you can disable it in your preferences: > > https://invent.kde.org/-/profile/preferences > > > > Should there be any issues, please let us know. > > As suggested by tsdgeos, not sure if it's related to/caused by the update > though: > > 11:37:28 bcooksley[m]: hi. any chance that CI pipelines are no > longer triggered after the gitlab update? > 11:38:20 though push does not yet show up on > https://invent.kde.org/dashboard/activity, so perhaps some processing > still happening? > 11:39:34 https://invent.kde.org/sdk/kdesvn/-/commits/master > shows the commits (4 min old), but > https://invent.kde.org/sdk/kdesvn/activity also does not yet show the push > 12:32:24 we also seem to be hitting some gitlab problem in > https://invent.kde.org/network/neochat/-/merge_requests/752 > 12:33:14 This looks similar to > https://invent.kde.org/office/kmymoney/-/merge_requests/191 > 12:34:33 I also noticed, that windows jobs take a long time to > setup and then fail. Now it doesn't even start after re-launch > 12:42:05 Kind of late for bcooksley[m] so i'd say answer his > email to the community mailing list? > This has now been corrected, apologies for the disruption. For those curious, Gitlab accomplishes the large part of it's processing using a background worker, Sidekiq. This background worker has a supervisor process, sidekiq-cluster, which launched successfully but was unable to spawn it's worker processes due to an issue with Bundler. That has been fixed now and it has caught up on all the missed processing. CI has approximately 200 jobs to work through at this time, which the nodes are busy working on at this very moment. Thanks, Ben > > -- > > Regards > > Thomas Baumgart > > - > An optimist laughs to forget. > A pessimist forgets to laugh. > - >
GItlab update
Hi all, This evening I updated our Gitlab instance at invent.kde.org to the latest version - 15.7.1. The release notes for this can be found at https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/ Of particular note for folks are the following: - Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/ - Using a SSH key to sign your commits: https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/ - New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/ (based on VS Code) Please note that the new VS Code based Web IDE is currently in beta, if you experience issues with it you can disable it in your preferences: https://invent.kde.org/-/profile/preferences Should there be any issues, please let us know. Thanks, Ben
Bugzilla server move
Hi all, As part of efforts to ensure our systems remain up to date and secure, we will soon need to move Bugzilla from it's existing home (based on Ubuntu 18.04) to it's new home (based on Ubuntu 22.04). To this end, this morning I moved over the Sandbox, bugstest.kde.org, to the new server. This is populated with the contents of our latest backup, taken approximately 24 hours ago. While i've done a reasonable degree of testing it would be appreciated if developers could please test their common workflows to ensure that none of them are broken by this move. DNS propagation is currently underway for bugstest.kde.org - you'll know if you have got the new server as it will have the same theme as bugs.kde.org (while the old server has an older theme). I'm particularly concerned that there may be breakage as Bugzilla has not been updated in many years now - which means there is a significant risk of bitrot having taken place. Among this is that Bugzilla is incompatible with MySQL 8 (necessitating use of MariaDB 10.6 instead). Please note that as the Bugzilla database is quite large it may take several hours to move it to the new system when we move bugs.kde.org itself so this is also a heads up that next weekend we're likely to have a downtime period of several hours as it is moved. Thanks, Ben
Re: Replacement of deino.kde.org
On Mon, Nov 28, 2022 at 7:34 PM Gilles Caulier wrote: > Hi Ben, > Hi Gilles, > > The network bandwidth is very very slow here to upload new files with > SFTP on files.kde.org : > > -- Compute package checksums for digiKam 7.9.0 > > File : digiKam-7.9.0-20221128T043841-x86-64-debug.appimage > Size : 523M > SHA256 sum : > 023c3657b0fdb19c8c82f4c2745f58ba68522d94e6370ed0a90f4f2579f6e1e5 > -- Cleanup older bundle AppImage files from files.kde.org > repository > > sftp> rm *-x86-64-debug.appimage* > -- Upload new bundle AppImage files to files.kde.org repository > > sending incremental file list > digiKam-7.9.0-20221128T043841-x86-64-debug.appimage > 5,439,488 0% 49.85kB/s3:01:19 > > I tried with a fiber connection or with 5G and it's always the same : > 50Kb/s > Of course my connection is very fast on the Internet in other cases. > I haven't seen speed issues with Tinami with anyone else so suspect the issue is ISP specific. There certainly aren't any restrictions on the server side, and Tinami and Deino are with the same hoster - Hetzner. I just did a test from my local system (where my ping to Europe is >300ms) and I get the following performance: ben@localhost:~/Downloads> scp testdata r...@tinami.kde.org: testdata 100% 331MB 3.8MB/s 01:27 As a starting point, please force usage of IPv4 as ISPs are notorious for getting IPv6 wrong (sftp -4 should do the trick if memory serves) > > Best regards > > Gilles Caulier > Cheers, Ben > Le dim. 27 nov. 2022 à 07:04, Ben Cooksley a écrit : > > > > Hi all, > > > > This migration has now been completed, and Tinami is now the canonical, > master copy of all resources previously hosted by Deino. > > This includes download.kde.org, files.kde.org, cdn.kde.org and > distribute.kde.org. > > > > Should there be any issues with access please let us know. > > > > Regards, > > Ben > > > > On Fri, Nov 25, 2022 at 6:49 AM Ben Cooksley wrote: > >> > >> Hi all, > >> > >> As part of Sysadmin's ongoing programme to ensure we remain on > supported releases for our servers, we have recently completed building out > tinami.kde.org, a system intended to replace deino.kde.org. > >> > >> Setup wise the system should be identical to Deino in all forms, and > continues to host the same services that it did before. This includes > account names and paths to where data is stored. > >> > >> Scripts should therefore only need a simple sed replacement of > deino.kde.org with tinami.kde.org to function as they did previously. > >> > >> The SSH Hostkeys are as follows: > >> 256 SHA256:OmgaQG1BzIUKNJ6aeuhf+Fb5W/WHrDyAbtJvK7lBjCo (ECDSA) > >> 256 SHA256:CMLG/mt8Lwwu7n2XTM9VpGjA4XWr/924M/WItfv/ABU (ED25519) > >> 3072 SHA256:oRCv04BPe3e9wzvj+/o3m+P1aafxVbhp2O+YEkpRHGU (RSA) > >> > >> If you could please validate that your access (and any other workflow) > works as expected that would be appreciated. > >> > >> At this time it is intended for tinami.kde.org to take over > responsibility from deino.kde.org this weekend. > >> > >> Please let us know if there are any queries. > >> > >> Many thanks, > >> Ben >
Email server update - migration from Mailman 2
Hi all, This evening I have been investigating our options surrounding Mailman 2 upgrade paths as part of an evaluation to replace our current primary mail server (Letterbox) which runs Ubuntu 20.04 with a newer system running 22.04. One of the consequences of this upgrade will be that we will be forced to migrate off Mailman 2 as it is no longer available and distributed in Ubuntu 22.04. The most likely candidate for this is naturally Mailman 3 (an instance of which can be found at https://mail.python.org/archives/list/python-...@python.org/) It appears to be a substantial improvement in all regards over Mailman 2, and therefore I intend to upgrade to that at this stage. Important considerations to note as part of this: - Existing list moderator and administrator passwords will cease to work, as Mailman 3 uses individual accounts to manage this - Mailman 3 uses a completely different URL format, so existing list archive links will likely be broken. It may be possible to retain static copies of the existing Pipermail archives to mitigate the impact of this but they won't be updated any further following the upgrade. Further information will be announced closer to the time. Thanks, Ben
Re: Replacement of deino.kde.org
Hi all, This migration has now been completed, and Tinami is now the canonical, master copy of all resources previously hosted by Deino. This includes download.kde.org, files.kde.org, cdn.kde.org and distribute.kde.org. Should there be any issues with access please let us know. Regards, Ben On Fri, Nov 25, 2022 at 6:49 AM Ben Cooksley wrote: > Hi all, > > As part of Sysadmin's ongoing programme to ensure we remain on supported > releases for our servers, we have recently completed building out > tinami.kde.org, a system intended to replace deino.kde.org. > > Setup wise the system should be identical to Deino in all forms, and > continues to host the same services that it did before. This includes > account names and paths to where data is stored. > > Scripts should therefore only need a simple sed replacement of > deino.kde.org with tinami.kde.org to function as they did previously. > > The SSH Hostkeys are as follows: > 256 SHA256:OmgaQG1BzIUKNJ6aeuhf+Fb5W/WHrDyAbtJvK7lBjCo (ECDSA) > 256 SHA256:CMLG/mt8Lwwu7n2XTM9VpGjA4XWr/924M/WItfv/ABU (ED25519) > 3072 SHA256:oRCv04BPe3e9wzvj+/o3m+P1aafxVbhp2O+YEkpRHGU (RSA) > > If you could please validate that your access (and any other workflow) > works as expected that would be appreciated. > > At this time it is intended for tinami.kde.org to take over > responsibility from deino.kde.org this weekend. > > Please let us know if there are any queries. > > Many thanks, > Ben >
Replacement of deino.kde.org
Hi all, As part of Sysadmin's ongoing programme to ensure we remain on supported releases for our servers, we have recently completed building out tinami.kde.org, a system intended to replace deino.kde.org. Setup wise the system should be identical to Deino in all forms, and continues to host the same services that it did before. This includes account names and paths to where data is stored. Scripts should therefore only need a simple sed replacement of deino.kde.org with tinami.kde.org to function as they did previously. The SSH Hostkeys are as follows: 256 SHA256:OmgaQG1BzIUKNJ6aeuhf+Fb5W/WHrDyAbtJvK7lBjCo (ECDSA) 256 SHA256:CMLG/mt8Lwwu7n2XTM9VpGjA4XWr/924M/WItfv/ABU (ED25519) 3072 SHA256:oRCv04BPe3e9wzvj+/o3m+P1aafxVbhp2O+YEkpRHGU (RSA) If you could please validate that your access (and any other workflow) works as expected that would be appreciated. At this time it is intended for tinami.kde.org to take over responsibility from deino.kde.org this weekend. Please let us know if there are any queries. Many thanks, Ben
Nextcloud update
Hi all, This afternoon I updated our Nextcloud instance to Nextcloud 25.0.1. This is mostly a bug fix release that should not affect your workflow. It does however make changes to CSS/JS files which will require a cache clear in order for your browser to pick them up. This can usually be accomplished with Shift + F5 in your browser of choice next time you access collaborate.kde.org. Please let us know if you experience any issues! Many thanks, Ben
Changes to Gitlab Operation
Hi all, This is a notice about a mostly "under the hood" change to how we are running Gitlab which will hopefully improve service going forward. Currently for those awake ih the very early European mornings you will have noticed a period where Gitlab becomes temporarily unavailable while it is restarted. This restart was necessary for two things: (a) To enable logs to be rotated; and (b) To restart Sidekiq, which over it's runtime leaks memory I have now switched us over to using systemd user units, which support the proper reloading of the corresponding Gitlab processes (unlike the init scripts) and also provide process supervision capability which has allowed for Gitlab's Sidekiq memory killer to be enabled. This means Gitlab itself should no longer become unavailable for 30-60 seconds every evening now, and overall performance of the system should be improved by having several gigabytes of system memory available to cache frequently accessed resources instead of containing Sidekiq memory leaks. If you notice any issues, please let us know. Thanks, Ben
Re: Update to Nextcloud
On Sun, Oct 30, 2022 at 10:35 PM Mathias Homann wrote: > Am Sonntag, 30. Oktober 2022, 10:30:37 CET schrieb Ben Cooksley: > > > > Excellent. I've just applied a fix - can you please try now? > > still the same - internal server error. > Different issue, but easily enough fixed. Hopefully it works now? > > > cheers > MH Thanks, Ben
Re: Update to Nextcloud
On Sun, Oct 30, 2022 at 10:17 PM Mathias Homann wrote: > Am Sonntag, 30. Oktober 2022, 10:05:47 CET schrieb Ben Cooksley: > > HI Mathias, > > > > Have you made use of the KDE Nextcloud instance at collaborate.kde.org > > before? > > > > I'm seeing some log entries that may explain this but they only apply to > > new users. > > then that is what it was - i haven't used it before. > Excellent. I've just applied a fix - can you please try now? Thanks, Ben > > Cheers > MH > -- > Mathias Homann > mathias.hom...@opensuse.org > Jabber (XMPP): le...@tuxonline.tech > Matrix: @mathias:eregion.de > IRC: [Lemmy] on freenode and ircnet (bouncer active) > keybase: https://keybase.io/lemmy > gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Re: Update to Nextcloud
HI Mathias, Have you made use of the KDE Nextcloud instance at collaborate.kde.org before? I'm seeing some log entries that may explain this but they only apply to new users. Cheers, Ben On Sun, Oct 30, 2022 at 9:49 PM Mathias Homann wrote: > Am Samstag, 29. Oktober 2022, 22:53:38 CET schrieb Ben Cooksley: > > Good morning all, > > > > This morning I updated our Nextcloud instance at > > https://collaborate.kde.org/ to make use of the latest version of > Nextcloud > > (v25, or as they call it in their marketing materials, Hub 3). > > > As part of this I also configured Nextcloud to make use of Invent > (Gitlab) > > authentication. > > I tried to log in with gitlab, all i got was internal server error... > > Cheers > MH > > -- > Mathias Homann > mathias.hom...@opensuse.org > Jabber (XMPP): le...@tuxonline.tech > Matrix: @mathias:eregion.de > IRC: [Lemmy] on freenode and ircnet (bouncer active) > keybase: https://keybase.io/lemmy > gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Update to Nextcloud
Good morning all, This morning I updated our Nextcloud instance at https://collaborate.kde.org/ to make use of the latest version of Nextcloud (v25, or as they call it in their marketing materials, Hub 3). While this change shouldn't bring much in the way of changes to features that we will notice it does appear to me at least to improve performance on initial load. As part of this I also configured Nextcloud to make use of Invent (Gitlab) authentication. When using this login flow your group memberships will now be synced from the corresponding team on Gitlab ( https://invent.kde.org/teams/) for those teams with shares. Should anyone have any issues with this please let us know. There were a small number of people (about 25, a few whose usernames I recognised) who had not logged into Gitlab when I did the migration, and therefore their accounts were not able to be linked. If this is you then you will receive an error regarding duplicate email addresses when logging into Nextcloud - please file a ticket and we will link your account. Many thanks, Ben
Re: Gitlab update, 2FA now mandatory
Hi all, Following some additional analysis of the situation I've now adjusted the policy surrounding enforced use of 2FA. Going forward it will only be enforced on people who are one of the following: - KDE Developers - KDE e.V. Members (including the Board) - KDE e.V. Staff (whether they be contractors or employees) In addition, 2FA may be enforced on any person who has access to a system that contains sensitive information, including but not limited to stats.kde.org, metrics.kde.org and collaborate.kde.org, or who has additional privileges on those systems outside of those granted to users by default. It may also be enforced if a person becomes involved in a project in a meaningful way (ie. a long term contributor) that does not result in them obtaining a developer account or access to sensitive information. Cheers, Ben
Re: Gitlab update, 2FA now mandatory
On Wed, Oct 26, 2022 at 1:32 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > On 2022-10-25 13:52, Ahmad Samir wrote: > > On 25/10/22 13:29, Harald Sitter wrote: > >> On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir > >> wrote: > >>> > >>> Can a first time contributor create a fork, create multiple/100 MR's > >>> and spin up CI jobs? if yes, > >>> then, first time contributors can disrupt the system. > >>> > >>> Weren't there some suspicious accounts that were using our gitlab > >>> instance for bitcoin mining (I > >>> could be wrong, I vaguely remember someone from Sysadmin team talking > >>> about something like that)? > >>> were these first time contributors or ones with developer accounts? > >> > >> I'm sure 2fa doesn't help with that (: > > > > I am not a cyber security expert, but isn't 2FA comparable to captcha > > stuff? it's not hard, but it takes some extra time. Which forum would a > > spammer target? the one with the "create account and login immediately" > > or the one with "create account, verify captcha hell, verify email > > address"? > > That is true, but did we have concrete issues with spam accounts? > 2FA and CAPTCHA's try to solve two totally different problems. Please do not try to conflate them with each other. CAPTCHA's are designed to prevent bots (and more recently other suspicious actors) from taking specific actions, such as registering accounts. Often CAPTCHA's are intended to block spammers. 2FA is designed to verify that a user is who they say they are - through confirming they are in possession of something (whether that be a TOTP Secret, or a Webauthn hardware token). It is intended to defeat phishing, where legitimate and innocent user accounts are compromised and abused by bad actors. > > And if yes, a one time captcha solving is a lot lower barrier the to > need to do 2fa auth for a trivial issue > Comment or merge request. > > At least for any part I work on in KDE the issue is manpower. > > Any step to make it more easier to help is good. > Any step to make it harder is bad. > > I see the point why we not work on GitHub, > I don't like to be dependent on some random company > that in worst case can randomly pull the plug. > > But I somehow don't understand why we need to enforce > this now even for new accounts without rights. > > I must confess I would like it even more if 2fa > would only be required on doing some action that > Is problematic and not just on any issue or merge > request comment. But I assume that is not feasible. > You are correct. 2FA forms part of the process of authentication - that is confirming the user is who they say they are. It therefore can only be applied at the time of login. > > Greetings > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org Regards, Ben
Re: Gitlab update, 2FA now mandatory
On Wed, Oct 26, 2022 at 12:22 AM Ahmad Samir wrote: > On 25/10/22 12:11, Carl Schwan wrote: > > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (cullmann.io) > a écrit : > > > > > >> On 2022-10-23 08:32, Ben Cooksley wrote: > >> > >>> Hi all, > >>> > >>> This afternoon I updated invent.kde.org [1] to the latest version of > >>> Gitlab, 15.5. > >>> Release notes for this can be found at > >>> https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ > >>> > >>> There isn't much notable feature wise in this release, however there > >>> have been some bug fixes surrounding the "Rebase without Pipeline" > >>> functionality that was introduced in an earlier update. > >>> > >>> As part of securing Invent against recently detected suspicious > >>> activity I have also enabled Mandatory 2FA, which Gitlab will ask you > >>> to configure next time you access it. This can be done using either a > >>> Webauthn token (such as a Yubikey) or TOTP (using the app of choice on > >>> your phone) > >>> > >>> Should you lose access to your 2FA device you can obtain a recovery > >>> token to log back in via SSH, see > >>> > https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh > >>> for more details on this. > >>> > >>> Please let us know if there are any queries on the above. > >> > >> > >> Hi, > >> > >> whereas I can see the security benefit, this raises the hurdle for one > >> time > >> contributors again a lot. > >> > >> Before you already had to register to get your merge request, > >> now you need to setup this too (or at least soon it is mandatory). > >> > >> I am not sure this is such a good thing. > >> > >> I see a point that one wants to avoid that e.g. somebody steals my > >> account > >> that has enough rights to delete all branches in the Kate repository via > >> the > >> web frontend. > >> > >> Could the 2FA stuff perhaps be limited to people with developer role or > >> such? > > > > Yes this would be ideal. We don't need to require 2fa for people who just > > started contributing or want to give some feedback on a MR/ticket. > > > > This should be possible with the following features: > > > https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group > > > > We can just require 2fa for developers because with great powers come > great > > responsibilities. > > > > Cheers, > > Carl > > > > Can a first time contributor create a fork, create multiple/100 MR's and > spin up CI jobs? if yes, > then, first time contributors can disrupt the system. > They certainly can, although it hasn't been an abuse pattern we have had to deal with so far. > > Weren't there some suspicious accounts that were using our gitlab instance > for bitcoin mining (I > could be wrong, I vaguely remember someone from Sysadmin team talking > about something like that)? > were these first time contributors or ones with developer accounts? > Bitcoin mining no. Trying to use a Docker container on our CI nodes as their own personal server by utilising a reverse shell, then abusing that access to compile their own Android image, yes. All aided by GitHub distributing the Docker image on their container registry and ignoring our abuse reports. > > > -- > Ahmad Samir > Regards, Ben
Re: Gitlab update, 2FA now mandatory
On Mon, Oct 24, 2022 at 11:56 PM Raghavendra Kamath wrote: > On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote: > > I > > have also enabled Mandatory 2FA, which Gitlab will ask you to configure > > next time you access it. > > Is the 2FA in KDE identity website same as this. The KDE identity shows a > grid > based system where you combine the grid and your password for 2FA. > > I have also already enabled 2FA for KDE identity with totp, does this > supersede it? > Gitlab will be replacing KDE Identity for authentication, so this 2FA setup supersedes that yes. Cheers, Ben > > > -- > Raghavendra Kamath > emblik.studio > > >
Re: Gitlab update, 2FA now mandatory
On Mon, Oct 24, 2022 at 12:16 PM Jack wrote: > On 2022.10.23 02:32, Ben Cooksley wrote: > > Hi all, > > > > This afternoon I updated invent.kde.org to the latest version of > > Gitlab, > > 15.5. > > Release notes for this can be found at > > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ > > > > There isn't much notable feature wise in this release, however there > > have > > been some bug fixes surrounding the "Rebase without Pipeline" > > functionality that was introduced in an earlier update. > > > > As part of securing Invent against recently detected suspicious > > activity I > > have also enabled Mandatory 2FA, which Gitlab will ask you to > > configure > > next time you access it. This can be done using either a Webauthn > > token > > (such as a Yubikey) or TOTP (using the app of choice on your phone) > > > > Should you lose access to your 2FA device you can obtain a recovery > > token > > to log back in via SSH, see > > > https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh > > for more details on this. > > > > Please let us know if there are any queries on the above. > > > > Thanks, > > Ben > Sorry to be dense, but without a webauthn token device, it seems I'm at > a total block if I don't have a phone (or don't have it with me.) Is > that correct, or is there some fine manual I need to read? > This will depend on whether it is a one-off situation or not. If it is a one-off situation, you can use one of your recovery codes (and if needed, obtain a fresh set of those via SSH as documented above) to login to Gitlab. If it is something that will happen on a more regular basis then setting up the TOTP application on a device you have regular access to (or obtaining a Webauthn token) would be recommended. > > Thanks. > > Jack > Thanks, Ben
Re: Gitlab update, 2FA now mandatory
On Mon, Oct 24, 2022 at 4:55 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > On 2022-10-23 08:32, Ben Cooksley wrote: > > Hi all, > > > > This afternoon I updated invent.kde.org [1] to the latest version of > > Gitlab, 15.5. > > Release notes for this can be found at > > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ > > > > There isn't much notable feature wise in this release, however there > > have been some bug fixes surrounding the "Rebase without Pipeline" > > functionality that was introduced in an earlier update. > > > > As part of securing Invent against recently detected suspicious > > activity I have also enabled Mandatory 2FA, which Gitlab will ask you > > to configure next time you access it. This can be done using either a > > Webauthn token (such as a Yubikey) or TOTP (using the app of choice on > > your phone) > > > > Should you lose access to your 2FA device you can obtain a recovery > > token to log back in via SSH, see > > > https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh > > for more details on this. > > > > Please let us know if there are any queries on the above. > > Hi, > Hi Christoph, > > whereas I can see the security benefit, this raises the hurdle for one > time > contributors again a lot. > > Before you already had to register to get your merge request, > now you need to setup this too (or at least soon it is mandatory). > > I am not sure this is such a good thing. > I see a point that one wants to avoid that e.g. somebody steals my > account > that has enough rights to delete all branches in the Kate repository via > the > web frontend. > That is something you actually can't do - at least not entirely :) Release branches are marked as protected within Gitlab, meaning that destructive operations will be blocked by Gitlab itself. Even if this was to be permitted by Gitlab, our hooks would intervene and ensure a backup of the branch was taken immediately before it was deleted - making the damage an inconvenience only as nothing would be lost. (See refs/backups/ in any Git repository on invent.kde.org, these refs are also protected by the hooks so they cannot be harmed) > > Could the 2FA stuff perhaps be limited to people with developer role or > such? It is technically possible to only apply the mandatory 2FA rules to only certain groups as Developer accounts are simply membership in teams/kde-developers. See https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group for the documentation on this. Given that we are using Invent for authenticating our various other services and the users of those aren't necessarily developers (while still having access to sensitive information) it seemed more prudent to enforce 2FA for everyone to ensure all our systems have a minimum baseline of industry best practice protection in place. This also avoids any issue when people are granted a developer account and suddenly find themselves subject to a new requirement. Thanks, Ben > > Greetings > Christoph > > > > > Thanks, > > Ben > > > > Links: > > -- > > [1] http://invent.kde.org > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org >
Gitlab update, 2FA now mandatory
Hi all, This afternoon I updated invent.kde.org to the latest version of Gitlab, 15.5. Release notes for this can be found at https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ There isn't much notable feature wise in this release, however there have been some bug fixes surrounding the "Rebase without Pipeline" functionality that was introduced in an earlier update. As part of securing Invent against recently detected suspicious activity I have also enabled Mandatory 2FA, which Gitlab will ask you to configure next time you access it. This can be done using either a Webauthn token (such as a Yubikey) or TOTP (using the app of choice on your phone) Should you lose access to your 2FA device you can obtain a recovery token to log back in via SSH, see https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh for more details on this. Please let us know if there are any queries on the above. Thanks, Ben
Updates to Wikis
Hi all, This evening I completed updates to our three Wikis - Userbase, Techbase and Community - which moved them on to the latest LTS version of Mediawiki. While this is only an incremental change and is not expected to have significant change, please let us know if you see anything broken. The one major change this update did bring was a transition from MyKDE authentication (using custom code) to Invent authentication (based off an upstream maintained extension) as part of our continued efforts to transition all services to using Invent (Gitlab) authentication across our services. One major benefit this brings us is that names and email addresses will now sync when changed on Gitlab to the Wikis (subject to a logout/login cycle to the wiki in question) which is something not previously available to us with either Identity, Phabricator or MyKDE login that the wikis have used. The transition should be fairly seamless however if you have used multiple email addresses in your time in the KDE Community there is the possibility it will create a new account for you on the wiki instead of finding your existing account. If this happens, please file a Sysadmin ticket and we will merge your wiki accounts (same applies if previous system changes have left you with duplicate accounts on the wikis) Thanks, Ben
Re: Drupal sites within KDE
On Tue, Aug 16, 2022 at 9:44 PM Paul Brown wrote: > On Tuesday, 16 August 2022 08:03:10 CEST Olaf Schmidt-Wischhöfer wrote: > > Hi Phu and Paul, > > > > here is a public demo of the Netlify CMS backend: > > https://cms-demo.netlify.com/#/ > > > > It appears that the workflow with publishing stages is optional, > dependent > > on configuration. > Hi Paul, > > That interface is nice and simple. I appeciate that. > > The problem is, as always, Markdown. Markdown is great for basic stuff. > Godsend, even. But try anything more complicated than the simplest layout, > say > (gasp!) tables with multiline cells. or having two images aligned side by > side, and prepare yourself to write raw HTML and CSS and have the 15 > minutes > you allocated to the job balloon into an hour. > Before we go down the road of saying no to Markdown based infrastructure, I did some searching around and it seems there is a plugin for Netlify that swaps out their editor for a different one that supports quite a bit more. See https://ui.toast.com/tui-editor for a demo of that editor. Does that resolve your concerns with functionality? > > Also, LabPlot, Kdenlive, "Adventures..." and a few more are already using > Wordpress, so I am not sure why I am having to argue so hard to get it > for > the Dot. At least from the users' point of view, it is clearly the best > option. > The main reason I believe Phu and Carl would like to see Hugo used is because it is easier to just maintain one theme - and not a variety of themes. This has bitten us severely in the past, so I can definitely appreciate their sentiment here. The other sites using Wordpress are usually devoted to specific applications - so it is easier for them to depart from our "common identity" rather than our core sites (like www.kde.org, dot.kde.org - which should have a common identity) I understand that work was done previously to migrate the Dot to Hugo as well, so it would be easier to reuse that work too. > > So, yeah, final answer: Wordporess, please. > > Cheers > > Paul > Thanks, Ben > -- > Promotion & Communication > > www: http://kde.org > Mastodon: https://mastodon.technology/@kde > Facebook: https://www.facebook.com/kde/ > Twitter: https://twitter.com/kdecommunity > LinkedIn: https://www.linkedin.com/company/kde > > >
Re: Drupal sites within KDE
Hi all, As an update to this, I have now: a) Redirected kde.nl and kde.in to kde.org b) Statically archived qtcon.org and amarok.kde.org That leaves Skrooge.org and BehindKDE.org to convert to Hugo and blogs.kde.org to convert to Wordpress still. Dot and Akademy are still to be resolved. Paul, if you could please take a moment to take a look at a Netlify CMS demo so we can assess it for deployment suitability for dot.kde.org that would be awesome. Thanks, Ben
Re: Drupal sites within KDE
On Fri, 12 Aug 2022, 6:53 am Paul Brown, wrote: > On Thursday, 11 August 2022 15:47:09 CEST Nate Graham wrote: > > On 8/11/22 06:05, Paul Brown wrote: > > > On Thursday, 11 August 2022 13:49:58 CEST Carl Schwan wrote: > > >> Personally after having to deal with Wordpress at work, I think it > offers > > >> an horrible developer experience with tons of plugin violating the > > >> spirit of the GPL, using PHP like it is still 00s (static and global > > >> variable everywhere, almost no OOP, no namespaces, weird naming > > >> convention e.g. $the_post, ...) and very poor internalization > > >> infrastructure. And so I wouldn't recommend it > > >> > > > :( > > > > > > Great interface for writers, though. As this is going to be used for > > > mostly > > > writing, that should be taken into account also. > > > > I agree with both of you: WP is kinda sucky for developers, but pretty > > great for users. That said, assuming those who maintain it don't have > > major problems (as Ben indicated) perhaps it would make sense as the > > direction to move in. > > > > Selfish detail: my weekly blog runs on Wordpress and I've been thinking > > of moving the "This Week in KDE" posts to KDE infrastructure and opening > > it up to more contributors, so having an existing WordPress instance > > that the content would be plugged into would ease the transition. > > ... And, all things considered, the current Drupal set up gives us the > worst > of both worlds: the writing interface is horrendous and buggy, its markup > inconsistent, the layout features non-existent, uploading and embedding > media > is tedious, and, according to the devs that have had to deal with its > backend, > it is bad there too. > > If compromise is a state where nobody is happy, well, that's Drupal. But > in a > bad way. > Based on the thread above it sounds like Drupal is something nobody is particularly happy with. Which means we definitely should switch to something else. Netlify I recall being mentioned previously - Paul could you take a look at it and see if it suits for Promo purposes? Static sites are much better from a scalability perspective so are preferred to dynamic ones from my side, but if Netlify doesn't work out it seems like WordPress might be our next best option (even if the code isn't the best) Cheers, Ben > Cheers > > Paul > -- > Promotion & Communication > > www: http://kde.org > Mastodon: https://mastodon.technology/@kde > Facebook: https://www.facebook.com/kde/ > Twitter: https://twitter.com/kdecommunity > LinkedIn: https://www.linkedin.com/company/kde > > >
Drupal sites within KDE
Hi all, As mentioned in an earlier email, I was going to look at connecting our Drupal sites to make use of Invent for authentication. While at initial glance a plugin to handle this did appear to exist, upon implementation it became apparent that this plugin would not be up to the task unfortunately - and no other plugin exists. This also brings up another issue as with one exception all of our Drupal sites run Drupal 7 which is now reaching the end of it's life, and most extensions are only being maintained for security fixes now. My understanding is that Drupal upstream intend to properly pull the plug on Drupal 7 sooner rather than later. We currently have the following sites on Drupal 7: - dot.kde.org - akademy.kde.org (and akademy-dev.kde.org) - amarok.kde.org - blogs.kde.org - kde.in - kde.nl - qtcon.org - skrooge.org - behindkde.org Given the age of the content on those sites, i'd like to suggest that we: a) Archive kde.nl and kde.in and redirect them both to KDE.org b) Turn QtCon.org into a static site c) For BehindKDE.org, Skrooge.org and amarok.kde.org look into converting them into Hugo based sites, but if that is not possible convert them into static sites as well. That will leave just blogs.kde.org, akademy.kde.org and dot.kde.org to contend with. Having looked into the process to perform a migration to a modern version of Drupal, it does not look pretty at all. See https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-6-or-7-to-drupal-9-or-later We should therefore assess whether it is prudent to continue to make use of Drupal, especially given the numerous security issues it has had and the poor upgrade path it tends to offer (Drupal 6 to 7 was not the nicest upgrade either if memory serves) Wordpress by contrast hasn't had major incidents in the past few years, and offers a rolling update model (the sites using it are running the most current release and have smoothly transitioned to it as time has gone on with no issues) Thoughts? Thanks, Ben
Re: Changes to login to Wordpress sites
On Tue, Aug 9, 2022 at 12:48 AM Scott Petrovic wrote: > hi Ben, > HI Scott, > > Thanks for getting that set up. I tested out both the Matomo site and the > WordPress krita.org and the "log in with OpenID" path works for me. > > Going forward, I guess we should try to do all our website logins with > this? Is there any page or documentation on how to get this going if we > decide to make a website in the future that needs this? I haven't done it > before, so not sure how technical it gets setting it up. I imagine it is > easier if you use a popular framework like WordPress or Drupal, but what if > we do something with a static site generator or something else that doesn't > have an easy plugin to set up? > This is standard OpenID Connect (an extension to the OAuth2 specification) so anything that supports that flow should support login via KDE Invent (Gitlab). Going forward all contributor focused sites should use this yes. Sites intended for users should supply their own login system. Not sure why a static site would need a login though. Cheers, Ben > > > > > > > On Mon, Aug 8, 2022 at 5:38 AM Ben Cooksley wrote: > >> Hi all, >> >> Continuing in the theme of migration of websites to using KDE Invent for >> login, this evening I migrated all 7 of our Wordpress sites to use KDE >> Invent login. >> >> You'll now find a "Login with OpenID Connect" link at the top of the >> login page on all of those sites. >> >> If you are an existing user of those sites, it would be appreciated if >> you could please try to login with the new method and confirm that all is >> working well. >> >> Much like with stats.kde.org, i'll be removing the connection to >> Identity from these sites once it has been confirmed that everything works >> correctly. >> >> Next up will be our Drupal sites - which given the activity on some of >> them may prompt a request to archive / redirect some of them elsewhere. >> Each of those requests will be given it's own email. >> >> Many thanks, >> Ben >> >
Changes to login to Wordpress sites
Hi all, Continuing in the theme of migration of websites to using KDE Invent for login, this evening I migrated all 7 of our Wordpress sites to use KDE Invent login. You'll now find a "Login with OpenID Connect" link at the top of the login page on all of those sites. If you are an existing user of those sites, it would be appreciated if you could please try to login with the new method and confirm that all is working well. Much like with stats.kde.org, i'll be removing the connection to Identity from these sites once it has been confirmed that everything works correctly. Next up will be our Drupal sites - which given the activity on some of them may prompt a request to archive / redirect some of them elsewhere. Each of those requests will be given it's own email. Many thanks, Ben
Re: Changes to login for stats.kde.org
Hi all, Thanks to everyone (who already had access) for confirming that everything worked as expected. I've now disabled support for KDE Identity based login on Matomo. If you haven't already and you previously have access it would be appreciated if you could go through the login flow so we can confirm that everything works, and to show that you still make use of the system. We'll likely do a cleanup of the system at some point to remove access for inactive people (given the sensitivity of website statistics) For those who didn't have access already, you'll need to file a Sysadmin ticket to be given access - please include details of the site(s) in question along with your relationship with that site and we'll sort you out. Thanks, Ben On Mon, Aug 8, 2022 at 10:56 AM Eugen Mohr wrote: > Same here, just click on the green banner and you are logged in. > > Thanks > > Eugen > > > Am 07.08.2022 um 18:18 schrieb Paul Brown: > > On Sunday, 7 August 2022 15:49:13 CEST Halla Rempt wrote: > > Works fine for me! > > Works here too. Nice and simple. A step up in convenience. Thanks Ben! > > Paul > > > On zondag 7 augustus 2022 12:27:28 CEST Ben Cooksley wrote: > > Hi all, > > As part of the previously approved move to Gitlab for unified login I've > now begun switching over our various sites to use Invent for > authentication, starting with stats.kde.org. > > Users of stats.kde.org will now find a "KDE Invent Login" button at the > bottom of the login window which should be used going forward. > > KDE Identity authentication has been left enabled for now - with its > removal scheduled to take place in the next week - so it would be > appreciated if everyone with access to stats.kde.org could please login > and > confirm they have no issues accessing the system. > > Many thanks, > Ben > >
Changes to login for stats.kde.org
Hi all, As part of the previously approved move to Gitlab for unified login I've now begun switching over our various sites to use Invent for authentication, starting with stats.kde.org. Users of stats.kde.org will now find a "KDE Invent Login" button at the bottom of the login window which should be used going forward. KDE Identity authentication has been left enabled for now - with its removal scheduled to take place in the next week - so it would be appreciated if everyone with access to stats.kde.org could please login and confirm they have no issues accessing the system. Many thanks, Ben
Re: Future of Web Single Sign On in KDE
On Wed, 20 Jul 2022, 12:39 am Kenny Duffus, wrote: > On 19 July 2022 13:46:36 CEST, "Joseph P. De Veaugh-Geiss" > wrote: > >Hello, > > > >On 7/18/22 17:47, Ingo Klöcker wrote: > >> One idea is to allow signing in with different commonly used identity > providers > >> (like Google, etc.) for our more user-centric websites where we cannot > expect > >> most people to have an account at invent.kde.org already. > >> > > > >Is there not a potential tracking issue with allowing Google or other > data-mining companies to be KDE's identity provider? [1] > > > > this is only suggested for the user facing sites. those with a > gitlab/identity account would login with that account to them as well as > our non user services > > however this doesn't seem to offer any good privacy respecting option for > our users to use > > >This seems to me to be at odds with KDE's vision: "A world in which > everyone has control over their digital life and enjoys freedom and > privacy." > > > >Of course one could argue it is the user's choice to use the service, but > embedding such services in KDE's infrastructure suggests our community > condones this kind of (potential) tracking. > > > > I agree > > education of privacy is something we also aim for and sending a message > that this is "normal" seems off > > Is there any other OIDC option that isn't good enough to replace identity > but could function ok for basic accounts for users? I know running more > stuff isn't great? > Our user facing sites were excluded from the original proposal. They will be outside our universal accounts system as there is only a small number of them (2 that I can think of - Forum and Bugzilla) and the benefit of linking them in is small (with colossal costs). Users will directly register on those sites. Cheers, Ben
Re: Future of Web Single Sign On in KDE
On Tue, Jul 19, 2022 at 7:41 AM Carl Schwan wrote: > on mobile so sorry for top posting > Hey Carl, > > fund.krita.org is using just plain oauth2 so it should be fine. Adding > more auth options should also not be too hard for fund.krita.org and > probably a good idea in any cases. > Awesome. Doesn't it also have functionality where it calls back to perform other actions (badges, etc) though? > > What I wonder though, is how you plan to do the migration. identity uses > the old username has unique identifier, something we want to move away > (main reasons is that people change names for various reasons). my.kde.org > uses a uuid instead and that makes it more future proof. It is possible to > use the uuid from my.kde.org in gitlab? I remember some big trouble with > the migration (and some nasty emails) and it would be good to avoid that > again. > With regards to UUIDs, as Gitlab does not support custom fields (for users anyway) we wouldn't be able to bring MyKDE UUIDs along, however we would be able to migrate to using Gitlab User IDs - which are do uniquely identify an account and which don't change. (see below API Docs) Migration wise - there would be a couple of approaches utilised here depending on the site and the number of impacted people. Allowing people to associate their account on a self-service basis, email based account matching as well as some mapping that we do ourselves are all on the table. > > Also did you consider using keycloak/freeIPA? These are very solid system > that provides oauth2, openid connect, saml and ldap. unfortunately like we > learned with mykde, oauth2 only is not really ideal, and openid connect, > saml and ldap are way more standardized. > Good news is that Gitlab fully supports OpenID Connect (which is really just standardised OAuth2) so we shouldn't have many issues there (see https://docs.gitlab.com/ee/integration/openid_connect_provider.html) Of the applications we deploy (or have looked to deploy) I don't recall any that offered SAML as an option that didn't also offer OpenID Connect as an option so I can't imagine that would be an issue (and SAML is fairly complex so it would be ideal if we could avoid that). Given the aim to support 2FA and minimize use of credentials (particularly outside of the "home site" used for managing them), LDAP has been ruled out as a protocol we would like to support going forward. With regards to Keycloak / FreeIPA, we've looked into these in the past a few times - each time ruling them out due to them being excessively complex as well as having a workflow for self-service that wasn't ideal (or was absent) (See https://www.keycloak.org/docs/latest/server_admin/#_webauthn for some of the involved complexity) > > Cheers, > Carl > Cheers, Ben > > > > Original Message > On Jul 18, 2022, 20:53, Ben Cooksley < bcooks...@kde.org> wrote: > > > On Tue, Jul 19, 2022 at 2:40 AM Halla Rempt wrote: > >> On zondag 17 juli 2022 11:54:27 CEST Ben Cooksley wrote: >> >> > I'd therefore like to move away from both Identity and MyKDE to Gitlab. >> >> What will that mean for fund.krita.org? That currently uses mykde, and >> that already is a problem for quite a few people to figure out how to >> create an account and login. >> > > The Krita Fund will need to be sorted out separately, as the Blender Fund > app from which it is sourced is fairly tightly coupled with Blender ID > (which is where MyKDE came from). > There is also the slight issue of it's dependence on Braintree. > > As Ingo points out though, for user focused sites allowing a variety of > login providers is likely the best path forward. > > >> Halla >> >> > Cheers, > Ben > > >
Re: Future of Web Single Sign On in KDE
On Tue, Jul 19, 2022 at 2:40 AM Halla Rempt wrote: > On zondag 17 juli 2022 11:54:27 CEST Ben Cooksley wrote: > > > I'd therefore like to move away from both Identity and MyKDE to Gitlab. > > What will that mean for fund.krita.org? That currently uses mykde, and > that already is a problem for quite a few people to figure out how to > create an account and login. > The Krita Fund will need to be sorted out separately, as the Blender Fund app from which it is sourced is fairly tightly coupled with Blender ID (which is where MyKDE came from). There is also the slight issue of it's dependence on Braintree. As Ingo points out though, for user focused sites allowing a variety of login providers is likely the best path forward. > Halla > > Cheers, Ben
Future of Web Single Sign On in KDE
Hi Community, Over the past few months, I've been contemplating what we need from an Identity replacement to meet the needs of our web services both now and into the future - especially given the current condition of Identity. This also involves evaluating whether this is something that truly needs to be completely custom - or whether it can be something off the shelf. As it is modern security best practice to not get people comfortable with logging in using their credentials on any site, the new service must be able to support this practice - with OAuth2 being the best placed in a modern context to do so. The list of requirements that results from this is: - User profiles that contain a name and email address(es) - Groups that users belong to, with the possibility of delegating management to non-Sysadmins - Support for strong 2FA methods (TOTP at a minimum, with U2F/FIDO2 being preferred) - Support for 'application passwords' to allow us to support systems that cannot handle OAuth2 based authentication (such as SMTP) On investigation most systems that are dedicated "identity providers" are both very heavy, complex and don't meet our needs very well (usually lacking self-service registration and password reset systems, as they're designed for corporate use). While they do tend to support other protocols for Identity Federation as well (like SAML) those aren't necessary for our purposes and simply create additional security risk. We are already running a very capable and well supported bit of software that can act as an OAuth2 provider (and ticks all the other above boxes) and has pre-existing support available for most of the web software we run though - Gitlab. Given that reinventing the wheel is both expensive and risky (requiring volunteer time to maintain, requiring us to keep on top of any security issues in the underlying stack ourselves, etc) i'm very much in favour of using something 'off the shelf'. Additionally some of the software we may want to use in the future is very likely to want to talk to Gitlab (to interact with issues, commit to repositories on behalf of users, etc) which requires that application to interface with Gitlab directly anyway. I'd therefore like to move away from both Identity and MyKDE to Gitlab. Because we are already populating most group information, as well as names and email addresses in Gitlab the 'migration' of data part of the equation is mostly completed already. When we finally 'cut the cord' and shutdown Identity people would need to perform a password reset to regain access but that would be the only point of pain. Those people who haven't logged into Gitlab by the point we 'cut the cord' would have their information deleted (unless they hold a Developer account or are an e.V. member in which case we would provision an account for them with their data) as the information would be considered to be information that is no longer required. The only risk I can see is that we would be putting quite a few eggs in one basket, however given the success of Gitlab I think that risk at this stage should be fairly minimal (and is no higher than if we went with something else off the shelf). Comments? Thanks, Ben
