Heads up: proj 7.2.0 + gdal 3.2.0

[Sandro Mani]

Hi

I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide shortly. 
I'll do a round of test builds in this copr [1], and then build 
everything (and rebuild dependent packages) in a rawhide side-tag and 
then merge it.

Affected dependent packages are

bes
cloudcompare
dans-gdal-scripts
gazebo
grass
gtatool
liblas
libgeotiff
libspatialite
mapnik
mapserver
merkaartor
ncl
opencv
osm2pgsql
osgearth
paraview
PDAL
postgis
python3-cartopy
python3-fiona
python3-pyproj
python3-rasterio
R-rgdal
qgis
qlandkartegt
qmapshack
qmaptool
qt-mobility-location
saga
spatialite-gui
vfrnav
vtk


Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/proj7/

[Tom Hughes]

On 05/11/2020 11:24, Sandro Mani wrote:

>  I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
> shortly. 
>  I'll do a round of test builds in this copr [1], and then build 
>  everything (and rebuild dependent packages) in a rawhide side-tag and 
>  then merge it. 
That's definitely going to cause some breakage as I believe proj 7 has
finally removed the old legacy API which at least some other things like
mapnik are still using.

I believe there is an upstream patch for mapnik now but I'll have to
see if it can be backported to the release version...

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Sandro Mani]

On 05.11.20 12:36, Tom Hughes wrote:
>  On 05/11/2020 11:24, Sandro Mani wrote:
>
> > I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
> > shortly. I'll do a round of test builds in this copr [1], and then 
> > build everything (and rebuild dependent packages) in a rawhide 
> > side-tag and then merge it.
>
>  That's definitely going to cause some breakage as I believe proj 7 has
>  finally removed the old legacy API which at least some other things like
>  mapnik are still using.
>
>  I believe there is an upstream patch for mapnik now but I'll have to
>  see if it can be backported to the release version...
>  
Yes indeed - I'll go through the breakages, see if newer upstream 
versions fix the problem, and then will post a list of packages which 
need to be updated and contact the respective maintainers.

Sandro

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Sandro Mani]

On 05.11.20 20:27, Sandro Mani wrote:
>  On 05.11.20 12:36, Tom Hughes wrote:
> > On 05/11/2020 11:24, Sandro Mani wrote:
> >
> >> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
> >> shortly. I'll do a round of test builds in this copr [1], and then 
> >> build everything (and rebuild dependent packages) in a rawhide 
> >> side-tag and then merge it.
> >
> > That's definitely going to cause some breakage as I believe proj 7 has
> > finally removed the old legacy API which at least some other things like
> > mapnik are still using.
> >
> > I believe there is an upstream patch for mapnik now but I'll have to
> > see if it can be backported to the release version...
> >
>  Yes indeed - I'll go through the breakages, see if newer upstream 
>  versions fix the problem, and then will post a list of packages which 
>  need to be updated and contact the respective maintainers.
>  
Soo, this opened a bit a can of worms, as qt-mobility (clearly being of 
the qt4 era dead upstream) is not going to support proj7. Only package 
requiring qt-mobility is qtwebkit, which in turn has a bit more users:

amarok-0:2.9.0-9.fc33.x86_64
arora-0:0.11.0-23.fc33.x86_64
brewtarget-0:2.1.0-16.fc33.x86_64
gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
kde-runtime-libs-0:17.08.3-15.fc33.i686
kde-runtime-libs-0:17.08.3-15.fc33.x86_64
kdelibs-6:4.14.38-23.fc34.i686
kdelibs-6:4.14.38-23.fc34.x86_64
kdelibs-webkit-6:4.14.38-23.fc34.i686
kdelibs-webkit-6:4.14.38-23.fc34.x86_64
knode-libs-0:4.14.10-44.fc33.i686
knode-libs-0:4.14.10-44.fc33.x86_64
krecipes-0:2.1.0-12.fc33.x86_64
ksysguard-libs-1:4.11.22-28.fc33.i686
ksysguard-libs-1:4.11.22-28.fc33.x86_64
libkfbapi-0:1.0-16.fc32.i686
libkfbapi-0:1.0-16.fc32.x86_64
python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
qlandkartegt-0:1.8.1-28.fc33.x86_64
qmc2-0:0.195-14.fc34.x86_64
qt-assistant-1:4.8.7-57.fc34.x86_64
qt-demos-1:4.8.7-57.fc34.x86_64
qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
qt-examples-1:4.8.7-57.fc34.i686
qt-examples-1:4.8.7-57.fc34.x86_64
qt4pas-0:2.5-21.fc33.i686
qt4pas-0:2.5-21.fc33.x86_64
qtscriptbindings-0:0.2.0-23.fc33.i686
qtscriptbindings-0:0.2.0-23.fc33.x86_64
qtwebkit-devel-0:2.3.4-32.fc34.i686
qtwebkit-devel-0:2.3.4-32.fc34.x86_64
rekonq-0:2.4.2-17.fc33.x86_64
timetablemate-0:0.10-0.24.20111204git.fc32.x86_64

So among this list, I see as end-user applications:

amarok - dead upstream music player
arora, rekonq: dead upstream browers, hardly a good idea to use them
brewtarget: has newer 2.3.0 release which supports Qt5
gambas3-gb-qt4-webkit: qt4 subpackages could just be dropped
krecipes: dead upstream
qlandkartegt: dead upstream
qmc2: latest trunk seems to support qt5
timetablemate -> kde-plasma-publictransport: Plasma 5 applet, with last 
update in 2013 apparently


Sooo, how about taking this as a pretext to just kick out all the qt4 
stuff? Debian has completed the move in March this year [1].

Opinions?

Thanks
Sandro

[1] https://wiki.debian.org/Qt4Removal

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Fabio Valentini]

On Thu, Nov 5, 2020 at 10:26 PM Sandro Mani <manisandro(a)gmail.com&gt; wrote:
>  On 05.11.20 20:27, Sandro Mani wrote:
>  >
>  > On 05.11.20 12:36, Tom Hughes wrote:
>  >> On 05/11/2020 11:24, Sandro Mani wrote:
>  >>
>  >>> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
>  >>> shortly. I'll do a round of test builds in this copr [1], and then
>  >>> build everything (and rebuild dependent packages) in a rawhide
>  >>> side-tag and then merge it.
>  >>
>  >> That's definitely going to cause some breakage as I believe proj 7 has
>  >> finally removed the old legacy API which at least some other things like
>  >> mapnik are still using.
>  >>
>  >> I believe there is an upstream patch for mapnik now but I'll have to
>  >> see if it can be backported to the release version...
>  >>
>  > Yes indeed - I'll go through the breakages, see if newer upstream
>  > versions fix the problem, and then will post a list of packages which
>  > need to be updated and contact the respective maintainers.
>  >
>  Soo, this opened a bit a can of worms, as qt-mobility (clearly being of
>  the qt4 era dead upstream) is not going to support proj7. Only package
>  requiring qt-mobility is qtwebkit, which in turn has a bit more users:
>
>  amarok-0:2.9.0-9.fc33.x86_64
>  arora-0:0.11.0-23.fc33.x86_64
>  brewtarget-0:2.1.0-16.fc33.x86_64
>  gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
>  kde-runtime-libs-0:17.08.3-15.fc33.i686
>  kde-runtime-libs-0:17.08.3-15.fc33.x86_64
>  kdelibs-6:4.14.38-23.fc34.i686
>  kdelibs-6:4.14.38-23.fc34.x86_64
>  kdelibs-webkit-6:4.14.38-23.fc34.i686
>  kdelibs-webkit-6:4.14.38-23.fc34.x86_64
>  knode-libs-0:4.14.10-44.fc33.i686
>  knode-libs-0:4.14.10-44.fc33.x86_64
>  krecipes-0:2.1.0-12.fc33.x86_64
>  ksysguard-libs-1:4.11.22-28.fc33.i686
>  ksysguard-libs-1:4.11.22-28.fc33.x86_64
>  libkfbapi-0:1.0-16.fc32.i686
>  libkfbapi-0:1.0-16.fc32.x86_64
>  python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
>  qlandkartegt-0:1.8.1-28.fc33.x86_64
>  qmc2-0:0.195-14.fc34.x86_64
>  qt-assistant-1:4.8.7-57.fc34.x86_64
>  qt-demos-1:4.8.7-57.fc34.x86_64
>  qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
>  qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
>  qt-examples-1:4.8.7-57.fc34.i686
>  qt-examples-1:4.8.7-57.fc34.x86_64
>  qt4pas-0:2.5-21.fc33.i686
>  qt4pas-0:2.5-21.fc33.x86_64
>  qtscriptbindings-0:0.2.0-23.fc33.i686
>  qtscriptbindings-0:0.2.0-23.fc33.x86_64
>  qtwebkit-devel-0:2.3.4-32.fc34.i686
>  qtwebkit-devel-0:2.3.4-32.fc34.x86_64
>  rekonq-0:2.4.2-17.fc33.x86_64
>  timetablemate-0:0.10-0.24.20111204git.fc32.x86_64
>
>  So among this list, I see as end-user applications:
>
>  amarok - dead upstream music player
>  arora, rekonq: dead upstream browers, hardly a good idea to use them
>  brewtarget: has newer 2.3.0 release which supports Qt5
>  gambas3-gb-qt4-webkit: qt4 subpackages could just be dropped
>  krecipes: dead upstream
>  qlandkartegt: dead upstream
>  qmc2: latest trunk seems to support qt5
>  timetablemate -> kde-plasma-publictransport: Plasma 5 applet, with last
>  update in 2013 apparently
>
>
>  Sooo, how about taking this as a pretext to just kick out all the qt4
>  stuff? Debian has completed the move in March this year [1].
>
>  Opinions? 
I, for one, would welcome getting rid of all that old cruft ...
especially if debian already has beaten us to the punch.
Could you pour your research into the Change Proposal wiki template
and propose this for F34? :)

Fabio

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Sandro Mani]

On 06.11.20 00:16, Fabio Valentini wrote:
>  On Thu, Nov 5, 2020 at 10:26 PM Sandro Mani
> <manisandro(a)gmail.com&gt; wrote:
> >
> > On 05.11.20 20:27, Sandro Mani wrote:
> >> On 05.11.20 12:36, Tom Hughes wrote:
> >>> On 05/11/2020 11:24, Sandro Mani wrote:
> >>>
> >>>> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
> >>>> shortly. I'll do a round of test builds in this copr [1], and then
> >>>> build everything (and rebuild dependent packages) in a rawhide
> >>>> side-tag and then merge it.
> >>> That's definitely going to cause some breakage as I believe proj 7 has
> >>> finally removed the old legacy API which at least some other things like
> >>> mapnik are still using.
> >>>
> >>> I believe there is an upstream patch for mapnik now but I'll have to
> >>> see if it can be backported to the release version...
> >>>
> >> Yes indeed - I'll go through the breakages, see if newer upstream
> >> versions fix the problem, and then will post a list of packages which
> >> need to be updated and contact the respective maintainers.
> >>
> > Soo, this opened a bit a can of worms, as qt-mobility (clearly being of
> > the qt4 era dead upstream) is not going to support proj7. Only package
> > requiring qt-mobility is qtwebkit, which in turn has a bit more users:
> >
> > amarok-0:2.9.0-9.fc33.x86_64
> > arora-0:0.11.0-23.fc33.x86_64
> > brewtarget-0:2.1.0-16.fc33.x86_64
> > gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
> > kde-runtime-libs-0:17.08.3-15.fc33.i686
> > kde-runtime-libs-0:17.08.3-15.fc33.x86_64
> > kdelibs-6:4.14.38-23.fc34.i686
> > kdelibs-6:4.14.38-23.fc34.x86_64
> > kdelibs-webkit-6:4.14.38-23.fc34.i686
> > kdelibs-webkit-6:4.14.38-23.fc34.x86_64
> > knode-libs-0:4.14.10-44.fc33.i686
> > knode-libs-0:4.14.10-44.fc33.x86_64
> > krecipes-0:2.1.0-12.fc33.x86_64
> > ksysguard-libs-1:4.11.22-28.fc33.i686
> > ksysguard-libs-1:4.11.22-28.fc33.x86_64
> > libkfbapi-0:1.0-16.fc32.i686
> > libkfbapi-0:1.0-16.fc32.x86_64
> > python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
> > qlandkartegt-0:1.8.1-28.fc33.x86_64
> > qmc2-0:0.195-14.fc34.x86_64
> > qt-assistant-1:4.8.7-57.fc34.x86_64
> > qt-demos-1:4.8.7-57.fc34.x86_64
> > qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
> > qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
> > qt-examples-1:4.8.7-57.fc34.i686
> > qt-examples-1:4.8.7-57.fc34.x86_64
> > qt4pas-0:2.5-21.fc33.i686
> > qt4pas-0:2.5-21.fc33.x86_64
> > qtscriptbindings-0:0.2.0-23.fc33.i686
> > qtscriptbindings-0:0.2.0-23.fc33.x86_64
> > qtwebkit-devel-0:2.3.4-32.fc34.i686
> > qtwebkit-devel-0:2.3.4-32.fc34.x86_64
> > rekonq-0:2.4.2-17.fc33.x86_64
> > timetablemate-0:0.10-0.24.20111204git.fc32.x86_64
> >
> > So among this list, I see as end-user applications:
> >
> > amarok - dead upstream music player
> > arora, rekonq: dead upstream browers, hardly a good idea to use them
> > brewtarget: has newer 2.3.0 release which supports Qt5
> > gambas3-gb-qt4-webkit: qt4 subpackages could just be dropped
> > krecipes: dead upstream
> > qlandkartegt: dead upstream
> > qmc2: latest trunk seems to support qt5
> > timetablemate -> kde-plasma-publictransport: Plasma 5 applet, with last
> > update in 2013 apparently
> >
> >
> > Sooo, how about taking this as a pretext to just kick out all the qt4
> > stuff? Debian has completed the move in March this year [1].
> >
> > Opinions?
>  I, for one, would welcome getting rid of all that old cruft ...
>  especially if debian already has beaten us to the punch.
>  Could you pour your research into the Change Proposal wiki template
>  and propose this for F34? :) 
Wait, I'll actually need to expand the analysis to include dependents of 
all these packages though, not just qtwebkit :) qtwebkit for sure it's 
time to remove, it likely has all sorts for security vulnerabilities. 
But I'll also expand the analysis to the entire qt4 stack and see what 
comes out.

Sandro

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Michael Catanzaro]

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1711519

(And related, but for Qt5: 
https://bugzilla.redhat.com/show_bug.cgi?id=1872819)

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Sandro Mani]

On 06.11.20 01:27, Michael Catanzaro wrote:
>  See also: https://bugzilla.redhat.com/show_bug.cgi?id=1711519 
Soo, initial change proposal for dropping qtwebkit:

https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval

Feedback welcome. I'll also post the link in the bug.

Sandro

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Christian Stadelmann]

Thank you for this proposal!

I found a small typo:
>  fro mother 
>  The following packages will be retired: 
>  arora
>  […]
>  rekonq 
Is there any reasons why they should retired and not also being obsoleted? (Just asking,
not suggesting. I don't really know the process but what happens if someone still has
arora installed, would that block the dist-upgrade to F34?)

For the two web browsers, you could add the info that their upstream is dead since years
too.

This is overdue since years and I am very happy that someone is picking it up! Thanks!

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Kevin Kofler]

Christian Stadelmann wrote:

> > The following packages will be retired:
> > arora
> > […]
> > rekonq
>  
>  Is there any reasons why they should retired and not also being obsoleted?
>  (Just asking, not suggesting. I don't really know the process but what
>  happens if someone still has arora installed, would that block the
>  dist-upgrade to F34?) 
The obvious replacement would be Falkon, which I maintain. I can easily add 
Obsoletes there.

        Kevin Kofler

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Michael Catanzaro]

On Fri, Nov 6, 2020 at 12:36 pm, Sandro Mani <manisandro(a)gmail.com&gt; 
wrote:
>  
>  On 06.11.20 01:27, Michael Catanzaro wrote:
> > 
> > See also: https://bugzilla.redhat.com/show_bug.cgi?id=1711519
>  
>  Soo, initial change proposal for dropping qtwebkit:
>  
>  https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval
>  
>  Feedback welcome. I'll also post the link in the bug. 
Well that only halfway removes QtWebKit. There is also the Qt5 version 
of the package that needs to be removed as well.

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Kevin Kofler]

Michael Catanzaro wrote:
>  Well that only halfway removes QtWebKit. There is also the Qt5
> version
>  of the package that needs to be removed as well. 
The Qt 5 version is less outdated and there is still hope that it can be 
brought up to date (upstream does not look dead: 
https://github.com/qtwebkit/qtwebkit ). It is also still used by more high-
profile software than the Qt 4 one (and at least one, FreeCAD, just recently 
moved from Qt 4 and Qt 4 WebKit to Qt 5 and Qt 5 WebKit).

        Kevin Kofler

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Michael Catanzaro]

There is one release so far this year, qtwebkit-5.212.0-alpha4, based 
on WebKitGTK 2.12. Security support for 2.12 ended in September 2016. 
So that is the status of your "less outdated" version. Applications 
will continue to depend on it indefinitely if they have no flag date to 
migrate.

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Kevin Kofler]

Michael Catanzaro wrote:
>  There is one release so far this year, qtwebkit-5.212.0-alpha4,
> based
>  on WebKitGTK 2.12. Security support for 2.12 ended in September 2016.
>  So that is the status of your "less outdated" version. 
The last Qt 4 WebKit was branched from WebKit master in early August 2012 
and the last release was 2.3.4 in October 2014, so 5.212 is 2 to 4 years 
less outdated. Hence, please understand that we are trying to get rid of the 
older (Qt 4) version first. We cannot do everything at once.

And I still think that for Qt 5 WebKit, we need to consider shipping a 
snapshot of the current development branch, based on WebKitGTK 2.27.1, 
instead of dropping the package entirely. If the snapshot works at all (even 
with bugs), it is better than dropping the package and losing all 
applications that depend on it.

        Kevin Kofler

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Kevin Kofler]

Sandro Mani wrote:
>  But I'll also expand the analysis to the entire qt4 stack and see
> what
>  comes out. 
Dropping the entire Qt 4 stack is a non-starter. I am keeping the qt4 
package secure with backported security fixes. I see no reason to drop it.

Qt4WebKit is a different matter, though I shall point out that:
* We already have plans to phase out Qt4WebKit, and there is a bug to track
  it.
* I do not see why we need your change page that only duplicates the tracker
  bug.
* I also do not see why you want to file that change page without first
  talking to the maintainers of the affected packages (in particular, me).
* You also unilaterally decided in your plan to retire some packages
  (kdepim4/knode, krecipes) that I maintain and for which I already have
  different plans.
* You also unilaterally decided in your plan to retire kde-workspace, which
  should not be necessary either.

        Kevin Kofler

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Sandro Mani]

On 06.11.20 13:00, Kevin Kofler via devel wrote:
>  Sandro Mani wrote:
> > But I'll also expand the analysis to the entire qt4 stack and see what
> > comes out.
>  Dropping the entire Qt 4 stack is a non-starter. I am keeping the qt4
>  package secure with backported security fixes. I see no reason to drop it.
>
>  Qt4WebKit is a different matter, though I shall point out that:
>  * We already have plans to phase out Qt4WebKit, and there is a bug to track
>     it.
>  * I do not see why we need your change page that only duplicates the tracker
>     bug.
>  * I also do not see why you want to file that change page without first
>     talking to the maintainers of the affected packages (in particular, me).
>  * You also unilaterally decided in your plan to retire some packages
>     (kdepim4/knode, krecipes) that I maintain and for which I already have
>     different plans.
>  * You also unilaterally decided in your plan to retire kde-workspace, which
>     should not be necessary either. 
Go easy there, I hit a problem, and proposed an analysis and a solution, 
posting it as draft with a request for feedback. No one unilateraly 
decided anything, as no decision has been taken.

Sandro

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Dominik 'Rathann' Mierzejewski]

On Thursday, 05 November 2020 at 22:26, Sandro Mani wrote:
[...]
>  > > On 05/11/2020 11:24, Sandro Mani wrote:
>  > > > I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide
>  > > > shortly. I'll do a round of test builds in this copr [1], and
>  > > > then build everything (and rebuild dependent packages) in a
>  > > > rawhide side-tag and then merge it. 
[...]
>  Soo, this opened a bit a can of worms, as qt-mobility (clearly being
> of the
>  qt4 era dead upstream) is not going to support proj7. 
Someone could package proj6 as a compatibility package if they need any
of the packages depending on qt-mobility.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Dan Horák]

On Thu, 5 Nov 2020 22:26:37 +0100
Sandro Mani <manisandro(a)gmail.com&gt; wrote:

>  
>  On 05.11.20 20:27, Sandro Mani wrote:
>  >
>  > On 05.11.20 12:36, Tom Hughes wrote:
>  >> On 05/11/2020 11:24, Sandro Mani wrote:
>  >>
>  >>> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
>  >>> shortly. I'll do a round of test builds in this copr [1], and then 
>  >>> build everything (and rebuild dependent packages) in a rawhide 
>  >>> side-tag and then merge it.
>  >>
>  >> That's definitely going to cause some breakage as I believe proj 7 has
>  >> finally removed the old legacy API which at least some other things like
>  >> mapnik are still using.
>  >>
>  >> I believe there is an upstream patch for mapnik now but I'll have to
>  >> see if it can be backported to the release version...
>  >>
>  > Yes indeed - I'll go through the breakages, see if newer upstream 
>  > versions fix the problem, and then will post a list of packages which 
>  > need to be updated and contact the respective maintainers.
>  >
>  Soo, this opened a bit a can of worms, as qt-mobility (clearly being of 
>  the qt4 era dead upstream) is not going to support proj7. Only package 
>  requiring qt-mobility is qtwebkit, which in turn has a bit more users:
>  
>  amarok-0:2.9.0-9.fc33.x86_64
>  arora-0:0.11.0-23.fc33.x86_64
>  brewtarget-0:2.1.0-16.fc33.x86_64
>  gambas3-gb-qt4-webkit-0:3.15.2-1.fc34.x86_64
>  kde-runtime-libs-0:17.08.3-15.fc33.i686
>  kde-runtime-libs-0:17.08.3-15.fc33.x86_64
>  kdelibs-6:4.14.38-23.fc34.i686
>  kdelibs-6:4.14.38-23.fc34.x86_64
>  kdelibs-webkit-6:4.14.38-23.fc34.i686
>  kdelibs-webkit-6:4.14.38-23.fc34.x86_64
>  knode-libs-0:4.14.10-44.fc33.i686
>  knode-libs-0:4.14.10-44.fc33.x86_64
>  krecipes-0:2.1.0-12.fc33.x86_64
>  ksysguard-libs-1:4.11.22-28.fc33.i686
>  ksysguard-libs-1:4.11.22-28.fc33.x86_64
>  libkfbapi-0:1.0-16.fc32.i686
>  libkfbapi-0:1.0-16.fc32.x86_64
>  python3-PyQt4-webkit-0:4.12.3-13.fc33.x86_64
>  qlandkartegt-0:1.8.1-28.fc33.x86_64
>  qmc2-0:0.195-14.fc34.x86_64
>  qt-assistant-1:4.8.7-57.fc34.x86_64
>  qt-demos-1:4.8.7-57.fc34.x86_64
>  qt-designer-plugin-webkit-1:4.8.7-57.fc34.i686
>  qt-designer-plugin-webkit-1:4.8.7-57.fc34.x86_64
>  qt-examples-1:4.8.7-57.fc34.i686
>  qt-examples-1:4.8.7-57.fc34.x86_64
>  qt4pas-0:2.5-21.fc33.i686
>  qt4pas-0:2.5-21.fc33.x86_64
>  qtscriptbindings-0:0.2.0-23.fc33.i686
>  qtscriptbindings-0:0.2.0-23.fc33.x86_64
>  qtwebkit-devel-0:2.3.4-32.fc34.i686
>  qtwebkit-devel-0:2.3.4-32.fc34.x86_64
>  rekonq-0:2.4.2-17.fc33.x86_64
>  timetablemate-0:0.10-0.24.20111204git.fc32.x86_64
>  
>  So among this list, I see as end-user applications:
>  
>  qlandkartegt: dead upstream 
ack, it's time to retire it


		Dan

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Kevin Kofler]

Sandro Mani wrote:
>  Soo, this opened a bit a can of worms, as qt-mobility (clearly being
> of
>  the qt4 era dead upstream) is not going to support proj7. 
Can't we get it to build without proj? Does QtWebKit or anything else 
actually need the parts that wrap proj?

        Kevin Kofler

qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

[Kevin Kofler]

Kevin Kofler via devel wrote:

>  Sandro Mani wrote:
> > Soo, this opened a bit a can of worms, as qt-mobility (clearly being of
> > the qt4 era dead upstream) is not going to support proj7.
>  
>  Can't we get it to build without proj? Does QtWebKit or anything else
>  actually need the parts that wrap proj? 
As far as I can tell, qt-mobility can be built with a bundled proj4:
https://code.qt.io/cgit/qt-mobility/qt-mobility.git/tree/src/3rdparty/proj
and this is what we should do to resolve this issue.

        Kevin Kofler

[Sandro Mani]

On 05.11.20 20:27, Sandro Mani wrote:
>  On 05.11.20 12:36, Tom Hughes wrote:
> > On 05/11/2020 11:24, Sandro Mani wrote:
> >
> >> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
> >> shortly. I'll do a round of test builds in this copr [1], and then 
> >> build everything (and rebuild dependent packages) in a rawhide 
> >> side-tag and then merge it.
> >
> > That's definitely going to cause some breakage as I believe proj 7 has
> > finally removed the old legacy API which at least some other things like
> > mapnik are still using.
> >
> > I believe there is an upstream patch for mapnik now but I'll have to
> > see if it can be backported to the release version...
> >
>  Yes indeed - I'll go through the breakages, see if newer upstream 
>  versions fix the problem, and then will post a list of packages which 
>  need to be updated and contact the respective maintainers.
>  
This is now done, I needed to updated pyproj and python-fiona, for the 
rest things went pretty smooth.

I haven't rebuild qlandkartegt which should be retired as per maintainer 
(CCed).

Sandro

[Jos de Kloe]

Thanks a lot for taking care of pyproj.

Jos

On 11/13/20 10:47 AM, Sandro Mani wrote:
> 
> On 05.11.20 20:27, Sandro Mani wrote:
>>
>> On 05.11.20 12:36, Tom Hughes wrote:
>>> On 05/11/2020 11:24, Sandro Mani wrote:
>>>
>>>> I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide 
>>>> shortly. I'll do a round of test builds in this copr [1], and then 
>>>> build everything (and rebuild dependent packages) in a rawhide 
>>>> side-tag and then merge it.
>>>
>>> That's definitely going to cause some breakage as I believe proj 7 has
>>> finally removed the old legacy API which at least some other things like
>>> mapnik are still using.
>>>
>>> I believe there is an upstream patch for mapnik now but I'll have to
>>> see if it can be backported to the release version...
>>>
>> Yes indeed - I'll go through the breakages, see if newer upstream 
>> versions fix the problem, and then will post a list of packages which 
>> need to be updated and contact the respective maintainers.
>>
> This is now done, I needed to updated pyproj and python-fiona, for the 
> rest things went pretty smooth.
> 
> I haven't rebuild qlandkartegt which should be retired as per maintainer 
> (CCed).
> 
> Sandro
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]