Hello Rex, >So, we (kde-sign, Qt maintainers) generally update strategically where it >makes sense to warrant the time investment in doing so. I understand. Also that some people contribute it in their free time/or paid time (but not mandatory to contribute), which of course means a lot. I understand that packaging is a fairly time consuming task. Back in the days when I used openSUSE and OBS I built the Unity desktop environment and maintained it a release and a half IIRC (30+ packages where some require custom vendor patches), different from what the distribution (gnome, the patches) uses. Another contributor chenxialong packaged it at that time for Fedora on OBS from the same repository (because doing something more sophisticated than (cross) build a simple package is not possible using Fedora tools, but todays requirements are) so a lot of the packaging effort was shared. As (re)build takes some time it is nice to edit some things (spec files) from the web interface, on your phone from the gym or on another computer very easily possible in OBS. I think that something similar would attract people to contribute to the packaging in Fedora in general. >Bumping Qt versions is... a fairly difficult process in fedora, >unfortunately. I understand, but there are some things that concern me. I would like to use secure Qt (5.14) with all security critical fixes (and new functions) built for Fedora. As a User of Fedora I would like to contribute and others to contribute as a packager but I do not see tools that provide the minimum requirements to do so. (a Web Interface for spec file editing, multiple repos e.g for Qt). As a Linux enthusiast I am deeply concerned with a far better (and long term easier to maintain) technical solution being suppressed either by incapable management, "I just work there" mentality or people who prefer to spend hours of work they are used too instead of 5 minutes work that's new for them (reminds me of systemd somehow). >Bumping Qt versions is... a fairly difficult process in fedora, >unfortunately. Introducing a new Qt version could be very simple I think: 1) Branch all Qt related packages (it should be with a one line command or using a web interface) 2) Edit package version number (with a per project (like Qt:5.14.1 project) macro - 1 digit changed/or two) 3) Wait for packages to be published into repo (and that repo contains all packages - without spec change - that use Qt priv headers). 4) Fix eventual build failures due to re based patches etc. 5) optional: Press push to start a request to get this merged into main repo. >Bumping Qt versions is... a fairly difficult process in fedora, >unfortunately. Would a workflow similar to the one described allow speed up providing the newest Qt optionally in let's say qt5.14/x86_64/{rawhide, f32, f31. f30} but keeping the main repo unchanged if desired? Would you say that the current build system maybe needs improving or a rework to provide kde-sign, Qt maintainers and you you with a slightly less difficult process? Would you agree that having the possibility for users to choose a different Qt version from a different versioned repo may help testing and improve quality? Would you and the kde-sign, Qt maintainers say that the workflow described above maybe is exactly what is needed (OBS)? Br, Damian On Wed, Jan 29, 2020 at 6:32 PM Rex Dieter <rdieter@xxxxxxxxxxxx> wrote: > > Damian Ivanov wrote: > > > But it's not the only CVE fixed with Qt 5.14.1 > > The point is that there is other software using Qt which doesn't start > > with K even though K works just fine with 5.14 by the experience of other > > distributions. > > Bumping Qt versions is... a fairly difficult process in fedora, > unfortunately. The primary reason is that there are many packages that use > Qt private api's the require rebuilding for every release. Quick check just > now in rawhide is that a full Qt5 version update requires (re)building at > least 78 packages. > > So, we (kde-sign, Qt maintainers) generally update strategically where it > makes sense to warrant the time investment in doing so. > > -- Rex > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx