Project

General

Profile

Housekeeping #3385

[qt5-webkit]: dropped from arch - many dependents

bill-auger - 2 months ago - . Updated 27 days ago.

Status:
in progress
Priority:
broken
Assignee:
% Done:

0%


Description

we should decide to keep or drop these as a set - some are relatively popular (calibre, freecad, marble, quassel, qutebrowser) - calibre and qutebrowser are already frozen versions, due to support for webkit being dropped upstream

IIRC, signon-ui is integral to a complete KDE/plasma DE - it may be the only relatively essential webkit dependent; but we will need to investigate whether/how signon-ui could be made to function with neither webengine nor webkit present

$ sudo parabola-dependents -v qt5-webkit
updating database ....
package: 'qt5-webkit' not found - creating dummy package
dummy package 'qt5-webkit' created
querying database ....
compiling results for (103) dependents ....
searching abslibre ....

direct and transitive parabola dependents:
  [qt5-webkit]  <- pcr-testing/anki-ccbc
  [qt5-webkit]  <- libre/bibletime
  [qt5-webkit]  <- libre/calibre3
  [qt5-webkit]  <- libre/freecad
  [qt5-webkit]  <- libre/marble-common
  [qt5-webkit]  <- nonprism/openshot
  [qt5-webkit]  <- libre/parley
  [qt5-webkit]  <- pcr/pythonqt
  [qt5-webkit]  <- pcr/qt5-quick1
  [qt5-webkit]  <- qt5-quick1 <- maliit-framework <- pcr/maliit-plugins
  [qt5-webkit]  <- libre/quassel-client
  [qt5-webkit]  <- libre/quassel-monolithic
  [qt5-webkit]  <- libre/qutebrowser
  [qt5-webkit]  <- pcr/rstudio-desktop
  [qt5-webkit]  <- libre/sigil
  [qt5-webkit]  <- libre/signon-ui
  [qt5-webkit]  <- signon-ui <- kaccounts-integration <- libakonadi <- akonadi <- libre/kde-development-environment-meta
  [qt5-webkit]  <- signon-ui <- kaccounts-integration <- purpose <- nonprism/choqok
  [qt5-webkit]  <- signon-ui <- kaccounts-integration <- purpose <- libre/okular
  [qt5-webkit]  <- signon-ui <- kaccounts-integration <- purpose <- okular <- libre/kile
  [qt5-webkit]  <- signon-ui <- kaccounts-integration <- purpose <- plasma-browser-integration <- libre/plasma-meta
  [qt5-webkit]  <- libre/supercollider

Related issues

Related to Packages - Bug #3420: [qt5-webkit]: rebuild against latest qt5-base (x86_64)fixed

Actions

History

#1

Updated by bill-auger 2 months ago

  • Assignee set to bill-auger
  • Description updated (diff)
#2

Updated by bill-auger 2 months ago

arch dropped webkit support in 'python-pyqt5'; which broke 'qutebrowser', for example - technically, it dropped "itself" trivially, simply due to the missing libs at build time - so to restore webkit support fully, i had to adopt two new packages ('python-pyqt5' and 'qt5-webkit') - the major cost foreseen, is that one or both will likely need to be rebuilt often (as qt5-base rolls)

generally, the future is bleak for probably all of these old favorites - some are already frozen; and QT6 has already begun displacing QT5, for example - like many, this librefication treatment probably has a shelf-life - OTOH, it is likely that people would complain more about calibre or qutebrowser being broken or missing, than the frozen webkit

#3

Updated by gap 2 months ago

bill-auger I thank you for maintaining Parabola and I commend your dedication to fixing these problems which are overlooked -- or all to often not even cared about in the first place -- by most distro maintainers, but this situation of Parabola having to systematically modify, or libre-ify, packages is getting out of hand.
As I remember mentioning on one of these discussions a while ago, the root cause of these problems is that they're not libre in the first place, and no amount of after-the-fact patching is going to change that.
Unless we actively make efforts to cooperate with upstream projects, these after-the-fact-patch scenarios are only going to become more frequent and more severe.

I seriously do not believe we can fix an ethical problem upstream with technical modifications downstream.
I genuinely believe the most efficient use of our resources is to communicate and cooperate with upstream projects rather than to try to overcome the ever-growing mountain of librefication patches.
That's not to mention that fixing issues upstream helps all downstream distros, whereas Parabola patches are, as far as I know, only utilised by Parabola and possibly Hyperbola.
This is also absurd because the other libre software distros don't share patches and either duplicate effort or miss out entiely on fixing issues another distro fixes.

Spending our time and effort on this flavour of librefication, involving the removal of functionality which depends on proprietary software, also makes Parabola less usable in comparison to other distros and makes the tradeoff of freedom versus functionality less appealing, which reduces our potential audience, popularity, number of new users, and ultimately number of contributors who could help us fix these issues in the first place.
That's not to say we shouldn't do it, just that we should bear in mind that this is a side-effect of our strategy.

We're stuck between a rock and a hard place.
Perhaps we should make efforts to coordinate with the FSF and other libre software distros, restore the working group, and make genuine, long-lasting change.
Our current strategy of librefication is totally unsustainable and depends on bill-auger doing most of the work.

#4

Updated by bill-auger about 2 months ago

that is a bit too strong - anyone can do the first 99% of the work - the work is done by whoever has the time and publishes and/or documents the knowledge - i am around often enough to do the final 1% of any project; even if i were the only parabola dev

As I remember mentioning on one of these discussions a while ago, the root cause of these problems is that they're not libre in the first place, and no amount of after-the-fact patching is going to change that.

that may be true for artworks; though overall, i have characterized it more the opposite - indeed, one may not patch and re-distribute something non-free; but in practice, most of the blacklisted packages are 100% libre (ie: the four freedoms) in arch upstream - most FSDG conflicts/treatments are not related to licensing (ie: they are patch-able)

#5

Updated by GNUtoo 27 days ago

gap wrote:

I seriously do not believe we can fix an ethical problem upstream with technical modifications downstream.
I genuinely believe the most efficient use of our resources is to communicate and cooperate with upstream projects rather than to try to overcome the ever-growing mountain of librefication patches.
That's not to mention that fixing issues upstream helps all downstream distros, whereas Parabola patches are, as far as I know, only utilised by Parabola and possibly Hyperbola.
This is also absurd because the other libre software distros don't share patches and either duplicate effort or miss out entiely on fixing issues another distro fixes.

It really depends. Some stuff is best fixed upstream, some can't so they need to be fixed downstream.

When upstream doesn't want fixes, we could instead try to either create new upstream projects (like linux-libre), or reuse some upstream project to deblob additional things (I managed to do that for u-boot in Libreboot, but recently Leah introduced nonfree software in Libreboot, so we're in the process of spinning up an FSDG compliant version of Libreboot to fix that).

If you take debootstrap for instance, the best is to upstream support for Trisquel (PureOS support is upstreamed now), and to either just rm the scripts of the non-fsdg distros or if we interpret the FSDG very broadly, remove the repositories that are not 100% free (and ideally also remove those who refer to nonfree repositories, have spyware/drm in them etc), and if the later is used, people can document which repositories are 100% free and the potential issue they have on the Libreplanet wiki. So in either cases it's easier to remove non-fsdg distros downstream (there is almost 0 maintenance if it's done right).

Another way would be to increase collaboration between FSDG distributions and other distributions with strict licensing policies (like Debian for instance).

Here a summary of the solutions:
Solution Short term effects Long term effects
Fixing in Parabola very fast to fix Painful maintenance, tend to be outdated
Coordinating between
FSDG distributions
very fast to fix but complicated to setup collaboration
Fixing upstream Can be time consuming Often 0 maintenance, or very few maintenance
Creating a new upstream Very time consuming:
* deciding on project
architecture
* website setup
* collaboration
infrastructure:
mailing lists, etc
* Require some maintenance
* can get easy coolaboration

I've started to work on some wiki pages like Group:Software/FSDG_distributions that document FSDG distributions differences as a start.

So far we also have articles that help collaboration:

Spending our time and effort on this flavour of librefication, involving the removal of functionality which depends on proprietary software, also makes Parabola less usable in comparison to other distros and makes the tradeoff of freedom versus functionality less appealing, which reduces our potential audience, popularity, number of new users, and ultimately number of contributors who could help us fix these issues in the first place.

That isn't necessarily an issue. If someone makes it easy enough for users to install problematic programs removed from Parabola, then it's not an issue anymore:
  • Parabola doesn't ship these programs so users won't be confused and think that they are OK or that they somewhat respect Parabola policies and the FSDG.
  • People that really need them are on their own and can still install them if they want, but since they won't be provided by Parabola, we can hope that they are aware of the known issues and also that there might be unknown issues as well. For instance if we remove Chromium because there is nonfree software in it, then there is no need to look at the precise licensing, or to look for malware, spyware etc. So some issues might be missed because we usually stop at the first issues found.

That's not to say we shouldn't do it, just that we should bear in mind that this is a side-effect of our strategy.

The reduction of the potential audience is not a given. Some people prefer clean software. Some have use cases that don't allow that yet.

Though what we can do is try to collaborate more with other FSDG distros for sure.

Guix for instance has a fix that seems to work for phoronix-test-suite that is better than the one we have in Parabola. We could reuse their fix.

But at the end of the day to do all these things we need help from people to do the work, and that's mainly what is lacking. If we do quick fixes it's also because we cannot allocate time to do the proper fixes. With more help we could do things properly and unsure that Parabola doesn't get unmaintainable over time.

We also accept PKGBUILDs in bug reports, patchs reviews in the mailing list. And people that are not Parabola hackers yet can also help reviewing things as we also have a backlog of reviews to do.

We also need to bugreport in other FSDG distributions: some of the issues found (and even fixed) in Parabola also appear in other distros. Some don't (Guix doesn't have free culture requirement for instance). And here users could help a lot if they only report bugs that look somewhat valid.

For instance if people report bugs asking to remove Iceweasel because it can connect to Facebook (a nonfree service) or to remove libimobiledevice because it can connect to an iphone (that runs a nonfree OS) then we'd probably have some relationship issue to deal with, which mean more work.

These readings can help to put things into perspective:

Perhaps we should make efforts to coordinate with the FSF and other libre software distros, restore the working group, and make genuine, long-lasting change.

The issue is also how to do that. If more users and developers help us coordinating by opening bugs reports on other distributions, that could help if the bug reports are not bogus, and that can actually work for real.

As far as I know, Other (non FSDG) distributions also had issues coordinating with patches. Openembedded/Yocto for instance had shared interests with Debian because Debian also supported ARM and other architectures pretty well, but I'm not sure they really manage to collaborate in ways that we can replicate as they probably tried to create new resources that didn't get enough contribution.

But here if users help making the link between distributions (by bugreporting) and the Libreplanet wiki (by editing, pointing to bugreports, etc), then it could work for real as it woudn't put additional burden on contributors that already have too much to do.

Here the contributors would be pointed to issues and fixes in the bug reporting system of the distributions they contribute to, so it will be work as usual, and maybe it could save a lot of time if patches are already available in other distributions.

Denis.

#6

Updated by bill-auger 27 days ago

  • Related to Bug #3420: [qt5-webkit]: rebuild against latest qt5-base (x86_64) added
#7

Updated by bill-auger 27 days ago

just a side-note - i created an epic ticket for these rebuilds #3421 - so any of these we want to keep maintaining, will likely need to be added to #3421

Also available in: Atom PDF