Re: Email server update - migration from Mailman 2
Am Montag, 6. Februar 2023 02:28:19 CET schrieb Neal Gompa: Most people expect normal proportional fonts when reading mail, not monospaced text. Even my email client doesn't show email in monospaced text by default. But using a proportional font breaks: * complex indentation, as I had already mentioned, * nicely aligned text tables, * ASCII art drawings, making mails using any of those display incorrectly. All those constructs can come up in technical discussions among tech-savvy persons such as here on kde-core-devel. (We are not "most people".) Keep in mind that code is usually displayed using a monospace font, too, and that e-mails on KDE mailing lists are likely to contain code snippets. I see no technical advantage in using a proportional font by default, only drawbacks. (And for those who want it, a JavaScript-heavy interface such as HyperKitty could make it switchable with one click and/or keypress. E.g., in KNode, you just push the X button on your keyboard to switch instantly. Wheeras Trojitá just always uses a monospace font for plaintext (non-HTML) e-mail.) And finally, HyperKitty is largely unusable without JavaScript. If you turn off JavaScript, significant portions of the interface just do not work, whereas Pipermail was completely free from client-side code. This is a regression in browser compatibility and in accessibility. HyperKitty also uses cookies, Pipermail does not. This is an unreasonable demand. Most of the internet does not function without JavaScript today. Most of the Internet is broken, so let us break our site too? There are browsers that by design do not handle JavaScript, such as lynx. Such browsers are used in various accessibility-related contexts, as well as in emergency situations. E.g., what if KDE Plasma fails to start up for you, you are stuck in text mode, and you are looking for a solution on KDE mailing lists using lynx? And the JavaScript-heavy stuff does not just require any JavaScript, but tends to require a very recent browser, refusing to work even on maintained LTS branches of browsers, such as QtWebEngine LTS (which is public and FOSS unlike the rest of Qt LTS). Some websites have already started breaking on QtWebEngine 5.15 LTS, e.g.: * the Nextcloud PDF viewer: https://github.com/nextcloud/files_pdfviewer/issues/684 * Discourse: https://forum.manjaro.org/t/new-version-of-discourse-dropped-support-for-qtwebengine-5-15-lts/132543 The reasons why they stopped working are pretty spurious in both cases: Nextcloud could trivially (a one-line change) switch to the "legacy" branch of PDF.js which is compatible with many more browsers than the default build (and I also blame PDF.js for not making the "legacy" build the default, the current default build is only suitable for bundling in, e.g., Firefox and NOT for the web!), and the stricter browser check in Discourse appears to be entirely unnecessary (since it works when I adblock the browser-detection script). If the same were to happen with HyperKitty, that would be a particularly serious issue for KDE mailing lists because Falkon is the official KDE browser and currently stuck on QtWebEngine 5.15 LTS. (Moving to Qt 6 will be needed to get a newer Chromium again, unless someone makes, e.g., QtWebEngine 6.2 LTS work with Qt 5 somehow.) I do not see how or why it is unreasonable to expect something that has worked without JavaScript for decades to keep working without JavaScript. There are things for which it may be necessary, but displaying static mailing list archives is not. Broken links sound like a showstopper to me. […] openSUSE developed a way to map legacy discussions on mlmmj to HyperKitty, while Fedora just retained the old Pipemail static pages. Either works. So either solution would need to be implemented on KDE mailing lists too. Kevin Kofler
Re: Email server update - migration from Mailman 2
On Sun, Feb 5, 2023 at 7:21 PM Kevin Kofler wrote: > > Ben Cooksley wrote: > > 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/) > > This already shows one of the issues: The archive links contain unescaped e- > mail addresses which get mangled by third-party mail filters such as the > Gmane one, breaking the links. > > > It appears to be a substantial improvement in all regards over Mailman 2, > > and therefore I intend to upgrade to that at this stage. > > Unfortunately, there are several usability issues with the Mailman 3 archive > interface, known as HyperKitty. Fedora (the GNU/Linux distribution) was one > of the first projects to switch to it (and it was originally developed by a > Fedora developer), so I have run into a bunch of them. There was > unfortunately little to no interest in fixing them when I reported them. > > The worst was that indentation in the mails was completely lost. Though > looking at the Python 3.12.0 alpha 2 announcement: > https://mail.python.org/archives/list/python-...@python.org/thread/M2ZJ3BAPJKVLU3XUTFEQXTNQOOJWWZRT/ > (hoping the link will not get mangled), at least this seems to have been > fixed. The indentation still looks wrong though because the mails are > displayed using a proportional font rather than a fixed-sized one as in > Pipermail (the Mailman 2 archive interface). > Most people expect normal proportional fonts when reading mail, not monospaced text. Even my email client doesn't show email in monospaced text by default. > Time stamps use strange formats. The front page shows me time stamps of the > form "Di Nov 15, 2:02 nachm.", which is not a valid way to format times in > German. (We do not use 12-hour times in Austria.) I did bring that to the > attention of the (at the time) main HyperKitty developer when this was > deployed in Fedora, but it does not seem to have been addressed. Somebody > filed a bug asking for the time format to be configurable, also mentioning > this issue: > https://gitlab.com/mailman/hyperkitty/-/issues/357 > and it has been open mostly untouched for a year and a half. Also, a request > to always show the date next to the time was simply turned down: > https://gitlab.com/mailman/hyperkitty/-/issues/299 > which is IMHO also a usability regression compared to Pipermail. > > And finally, HyperKitty is largely unusable without JavaScript. If you turn > off JavaScript, significant portions of the interface just do not work, > whereas Pipermail was completely free from client-side code. This is a > regression in browser compatibility and in accessibility. HyperKitty also > uses cookies, Pipermail does not. > This is an unreasonable demand. Most of the internet does not function without JavaScript today. > > - 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. > > Broken links sound like a showstopper to me. Either keeping the static pages > up or somehow setting up a redirect mapping (I believe it has been done at > least once by some project, but it does not seem to be currently deployed in > Fedora at least, they are using what I assume to be a static copy of the old > archives) is IMHO required. > openSUSE developed a way to map legacy discussions on mlmmj to HyperKitty, while Fedora just retained the old Pipemail static pages. Either works. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: New repo in kdereview: PlasmaTube
Hi Albert,
> qrc:/SettingsPage.qml:54: ReferenceError: logout is not defined
Fixed.
> qrc:/videoplayer/VideoControls.qml:186: TypeError: Cannot read property
> 'formatList' of undefined
Fixed.
> You're also mixing tr() and i18n() in your C++ code, please move it all to
> i18n
Should be fixed now.
> LocalizedString::setApplicationDomain("tokodon");
Fixed.
Thanks,
Devin
On Sun, Feb 5, 2023 at 4:16 AM Albert Astals Cid wrote:
>
> El dissabte, 4 de febrer de 2023, a les 19:14:20 (CET), Devin va escriure:
> > Hi everyone,
> >
> > I would like to put PlasmaTube through kdereview:
> >
> > https://invent.kde.org/multimedia/plasmatube
> >
> > PlasmaTube is a YouTube client for both mobile and desktop.
>
> These two warnings seem like you should fix them
> qrc:/SettingsPage.qml:54: ReferenceError: logout is not defined
>There's no logout anywhere
>
> qrc:/videoplayer/VideoControls.qml:186: TypeError: Cannot read property
> 'formatList' of undefined
>As far as I can see the video property of VideoControls is a MpvObject
> which doesn-t have a video property
>
>
> KLocalizedString::setApplicationDomain("tokodon");
>This application is not tokodon ;)
>
> You're also mixing tr() and i18n() in your C++ code, please move it all to
> i18n
>
>
> Cheers,
> Albert
>
>
> >
> > Thanks,
> > Devin
>
>
>
>
Re: Downtime Notice: Bugzilla - bugs.kde.org
On Mon, Feb 6, 2023 at 2:30 AM Thomas Baumgart wrote: > On Sonntag, 5. Februar 2023 12:06:16 CET Ben Cooksley wrote: > > > Hi all, > > > > This migration has now been completed this evening, and Bugzilla should > be > > up and running now in its new home. > > > > As part of this I did have to apply a patch to correct Bugzilla's use of > > Perl's email libraries, so please report any issues you see in case other > > parts of the codebase have also bitrotted and broken. > > At some point in the not too distant future we may need to evaluate a > > replacement platform to Bugzilla if upstream does not release a newer > > version. > > I noticed, that a bug was not closed based on a commit though it should > have > been. Here's the console log of the push > > Enumerating objects: 9, done. > Counting objects: 100% (9/9), done. > Delta compression using up to 12 threads > Compressing objects: 100% (5/5), done. > Writing objects: 100% (5/5), 504 bytes | 504.00 KiB/s, done. > Total 5 (delta 4), reused 0 (delta 0), pack-reused 0 > remote: The commits in this series can be viewed at: > remote: > https://invent.kde.org/office/kmymoney/commit/4d5599ca64795245a2f5fa4d4e5203364c74619c > remote: Closing bug 464055 > remote: > remote: To create a merge request for 5.1, visit: > remote: > https://invent.kde.org/office/kmymoney/-/merge_requests/new?merge_request%5Bsource_branch%5D=5.1 > remote: > To ssh://invent.kde.org/office/kmymoney.git >3f8e65e56..4d5599ca6 HEAD -> 5.1 > > but on https://bugs.kde.org/show_bug.cgi?id=464055 the commit cannot be > seen > and the status did not change :( > It seems that in your particular instance your domain is protected by a DMARC policy that flags any email which fails SPF validation for quarantine. Which our mail infrastructure happily did - preventing the changes from being made to the bug. I've tweaked the Bugzilla hooks so that they'll evade SPF restrictions now which should help with that hopefully. Good news is because it was quarantined, your hook trigger email could be released - which i've now done. Thanks, Ben > > -- > > Regards > > Thomas Baumgart > > - > There are two rules for success in life: > Rule 1: Don't tell people everything you know. > - >
Re: Gitlab update, 2FA now mandatory
Kevin Kofler wrote: > What am I expected to use with my PinePhone? Does > https://apps.kde.org/keysmith/ work? To answer my own question: Yes, Keysmith works, both on the desktop (and notebook) and on the PinePhone. It is also easily possible to synchronize the keyring between different devices using Keysmith just by copying ~/.config/org.kde.keysmith/Keysmith.conf to the other device over SFTP. Then any of the devices can be used to generate the TOTP. (They will generate the exact same one-time passwords, I can see it by running both instances in parallel.) GNOME Secrets (formerly known as Password Safe) also works on the PinePhone (which is useful because that app can also store the permanent password, and is mobile-friendly unlike KWalletManager, though I presume it will also work fine on desktops/notebooks). If I enter the same secret there, it also generates the exact same one-time passwords. Kevin Kofler
Re: ghostwriter is ready for your review
Megan wrote: > It's definitely not supposed to look like that. I tried a fresh install > on my machine (removing and rebuilding from scratch) but could not > replicate the issue. It's supposed to be using Font Awesome's font > glyphs for the icons, since they are easily styled along with the normal > text in QSS/CSS. I also double checked that I don't have Font Awesome > installed as a font. Weird. You probably have some other font that incorporates Font Awesome glyphs (or equivalent glyphs for the same code points). There are several "nerd fonts" that try to be supersets of multiple icon fonts including Font Awesome. What is sure is that if you use icon fonts in the application, it has a dependency on the font, or a font, any font, providing those icons. That dependency must be documented. And you also need to explicitly set the font of those buttons to Font Awesome or to whatever compatible font you decide to depend on. While fontconfig sometimes automatically falls back to the correct font when it hits a character not supported in the default font, there are reasons why that can fail, especially for private use area characters like the Font Awesome ones. And other operating systems might not even attempt to fall back to a font that actually provides the icon. Windows at least used to have no such fallback mechanism, though I have not used it for years, so that might have changed since. Kevin Kofler
Re: Email server update - migration from Mailman 2
Ben Cooksley wrote: > 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/) This already shows one of the issues: The archive links contain unescaped e- mail addresses which get mangled by third-party mail filters such as the Gmane one, breaking the links. > It appears to be a substantial improvement in all regards over Mailman 2, > and therefore I intend to upgrade to that at this stage. Unfortunately, there are several usability issues with the Mailman 3 archive interface, known as HyperKitty. Fedora (the GNU/Linux distribution) was one of the first projects to switch to it (and it was originally developed by a Fedora developer), so I have run into a bunch of them. There was unfortunately little to no interest in fixing them when I reported them. The worst was that indentation in the mails was completely lost. Though looking at the Python 3.12.0 alpha 2 announcement: https://mail.python.org/archives/list/python-...@python.org/thread/M2ZJ3BAPJKVLU3XUTFEQXTNQOOJWWZRT/ (hoping the link will not get mangled), at least this seems to have been fixed. The indentation still looks wrong though because the mails are displayed using a proportional font rather than a fixed-sized one as in Pipermail (the Mailman 2 archive interface). Time stamps use strange formats. The front page shows me time stamps of the form "Di Nov 15, 2:02 nachm.", which is not a valid way to format times in German. (We do not use 12-hour times in Austria.) I did bring that to the attention of the (at the time) main HyperKitty developer when this was deployed in Fedora, but it does not seem to have been addressed. Somebody filed a bug asking for the time format to be configurable, also mentioning this issue: https://gitlab.com/mailman/hyperkitty/-/issues/357 and it has been open mostly untouched for a year and a half. Also, a request to always show the date next to the time was simply turned down: https://gitlab.com/mailman/hyperkitty/-/issues/299 which is IMHO also a usability regression compared to Pipermail. And finally, HyperKitty is largely unusable without JavaScript. If you turn off JavaScript, significant portions of the interface just do not work, whereas Pipermail was completely free from client-side code. This is a regression in browser compatibility and in accessibility. HyperKitty also uses cookies, Pipermail does not. > - 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. Broken links sound like a showstopper to me. Either keeping the static pages up or somehow setting up a redirect mapping (I believe it has been done at least once by some project, but it does not seem to be currently deployed in Fedora at least, they are using what I assume to be a static copy of the old archives) is IMHO required. Kevin Kofler
Re: Downtime Notice: Bugzilla - bugs.kde.org
On Sonntag, 5. Februar 2023 12:06:16 CET Ben Cooksley wrote: > Hi all, > > This migration has now been completed this evening, and Bugzilla should be > up and running now in its new home. > > As part of this I did have to apply a patch to correct Bugzilla's use of > Perl's email libraries, so please report any issues you see in case other > parts of the codebase have also bitrotted and broken. > At some point in the not too distant future we may need to evaluate a > replacement platform to Bugzilla if upstream does not release a newer > version. I noticed, that a bug was not closed based on a commit though it should have been. Here's the console log of the push Enumerating objects: 9, done. Counting objects: 100% (9/9), done. Delta compression using up to 12 threads Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 504 bytes | 504.00 KiB/s, done. Total 5 (delta 4), reused 0 (delta 0), pack-reused 0 remote: The commits in this series can be viewed at: remote: https://invent.kde.org/office/kmymoney/commit/4d5599ca64795245a2f5fa4d4e5203364c74619c remote: Closing bug 464055 remote: remote: To create a merge request for 5.1, visit: remote: https://invent.kde.org/office/kmymoney/-/merge_requests/new?merge_request%5Bsource_branch%5D=5.1 remote: To ssh://invent.kde.org/office/kmymoney.git 3f8e65e56..4d5599ca6 HEAD -> 5.1 but on https://bugs.kde.org/show_bug.cgi?id=464055 the commit cannot be seen and the status did not change :( -- Regards Thomas Baumgart - There are two rules for success in life: Rule 1: Don't tell people everything you know. - signature.asc Description: This is a digitally signed message part.
Re: New repo in kdereview: PlasmaTube
El dissabte, 4 de febrer de 2023, a les 19:14:20 (CET), Devin va escriure:
> Hi everyone,
>
> I would like to put PlasmaTube through kdereview:
>
> https://invent.kde.org/multimedia/plasmatube
>
> PlasmaTube is a YouTube client for both mobile and desktop.
These two warnings seem like you should fix them
qrc:/SettingsPage.qml:54: ReferenceError: logout is not defined
There's no logout anywhere
qrc:/videoplayer/VideoControls.qml:186: TypeError: Cannot read property
'formatList' of undefined
As far as I can see the video property of VideoControls is a MpvObject
which doesn-t have a video property
KLocalizedString::setApplicationDomain("tokodon");
This application is not tokodon ;)
You're also mixing tr() and i18n() in your C++ code, please move it all to
i18n
Cheers,
Albert
>
> Thanks,
> Devin
Re: Downtime Notice: Bugzilla - bugs.kde.org
Hi all, This migration has now been completed this evening, and Bugzilla should be up and running now in its new home. As part of this I did have to apply a patch to correct Bugzilla's use of Perl's email libraries, so please report any issues you see in case other parts of the codebase have also bitrotted and broken. At some point in the not too distant future we may need to evaluate a replacement platform to Bugzilla if upstream does not release a newer version. Thanks, Ben On Sun, Jan 29, 2023 at 11:22 PM Ben Cooksley wrote: > Hi Community, > > This email is advance notice that Bugzilla will be unavailable for several > hours this coming weekend as part of a server migration. > > Due to the size of the Bugzilla database it is anticipated that it will > take several hours to take a final backup copy from the old system and then > import it on the new system. > > An import was done somewhat recently of a bugs.kde.org backup snapshot > into bugstest.kde.org, which will allow for content to be accessed for > older bugs during this downtime. > > Please let me know if there are any queries on this. > > Regards, > Ben Cooksley > KDE Sysadmin >
