[PROJ] Calling for 7.0.1 release

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] Calling for 7.0.1 release

Devrim GÜNDÜZ-2

Hi,

Greetings first: I'm the PostgreSQL.org RPM packager for
RHEL/CentOS/Fedora/SLES.

This issue is blocking me to release 7.0 on RHEL 7:

https://github.com/OSGeo/PROJ/issues/2070

I found automake 1.6 on SLES, but RHEL 7 does not have it. I'm not too eager to
build a custom RPM just for that one.

So, any chance to release 7.0.1 earlier than planned? RHEL/CentOS 7 is a
majority of our user base, and this blocks other updates in the repo as well.

Thanks!

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Kristian Evers-2
Devrim,

Welcome to the list! We're always happy to hear from the packagers of PROJ.

As you may already be aware, the next release is scheduled for May 1st. I am
curious as to why this can't wait about a month to be dealt with? What are
the other packages that are blocked by this?

Ideally I would push out new packages maybe once a month but that is simply
not feasible for me to do. I can't set time aside that often to put out a new release.
We are currently doing bi-monthly releases which I think is rather frequent and
most importantly (to me) it fits my work schedule fairly well. With that said,
exceptions can be made, I just need the arguments to be convincing.

Best regards,
Kristian



-----Original Message-----
From: PROJ <[hidden email]> On Behalf Of Devrim Gündüz
Sent: 24. marts 2020 13:46
To: PROJ <[hidden email]>
Subject: [PROJ] Calling for 7.0.1 release


Hi,

Greetings first: I'm the PostgreSQL.org RPM packager for
RHEL/CentOS/Fedora/SLES.

This issue is blocking me to release 7.0 on RHEL 7:

https://github.com/OSGeo/PROJ/issues/2070

I found automake 1.6 on SLES, but RHEL 7 does not have it. I'm not too eager to
build a custom RPM just for that one.

So, any chance to release 7.0.1 earlier than planned? RHEL/CentOS 7 is a
majority of our user base, and this blocks other updates in the repo as well.

Thanks!

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Sebastiaan Couwenberg
In reply to this post by Devrim GÜNDÜZ-2
On 3/24/20 1:46 PM, Devrim Gündüz wrote:
> So, any chance to release 7.0.1 earlier than planned? RHEL/CentOS 7 is a
> majority of our user base, and this blocks other updates in the repo as well.

Why don't you just add a patch to the RPM package for the time being, we
did that for the Debian package:

 https://salsa.debian.org/debian-gis-team/proj/-/commit/8b7f0161d0786265362af5be6bedd2b001bad297

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2

Hi Sebastiaan,

On Tue, 2020-03-24 at 14:12 +0100, Sebastiaan Couwenberg wrote:
>
> Why don't you just add a patch to the RPM package for the time being, we
> did that for the Debian package:
>
>  
> https://salsa.debian.org/debian-gis-team/proj/-/commit/8b7f0161d0786265362af5be6bedd2b001bad297

I did, too:
https://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm/redhat/master/proj70/master/proj-7.0.0-sles12-pkgconfig.patch;h=33800266a9b8f7826a5ff6d499e12282ef8a45e7;hb=60ff67711307eb403fc1369aa5c92cccd86856fc

But this requires aclocal-1.6 to build -- which is not available on RHEL 7.

-HTH

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Kristian Evers-2

Hi Kristian,

On Tue, 2020-03-24 at 13:05 +0000, Kristian Evers wrote:
> Welcome to the list! We're always happy to hear from the packagers of PROJ.

Thanks!

> As you may already be aware, the next release is scheduled for May 1st. I am
> curious as to why this can't wait about a month to be dealt with? What are
> the other packages that are blocked by this?

I cannot comment on your release cycle (and respect that), but OTOH 7.0.0
cannot be built on RHEL 7, a major distro.

> Ideally I would push out new packages maybe once a month but that is simply
> not feasible for me to do. I can't set time aside that often to put out a new
> release. We are currently doing bi-monthly releases which I think is rather
> frequent and most importantly (to me) it fits my work schedule fairly well.
> With that said, exceptions can be made, I just need the arguments to be
> convincing.

I'm very excited to push Proj 7.0 to the community repos, so that people can
benefit from the new features -- but then there is that build failure. I would
not pester you if it was a Fedora 31 or RHEL 6 issue, but RHEL 7 is still very
widely used.

Regards,


--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Sebastiaan Couwenberg
In reply to this post by Devrim GÜNDÜZ-2
On 3/24/20 4:58 PM, Devrim Gündüz wrote:

> On Tue, 2020-03-24 at 14:12 +0100, Sebastiaan Couwenberg wrote:
>>
>> Why don't you just add a patch to the RPM package for the time being, we
>> did that for the Debian package:
>>
>>  
>> https://salsa.debian.org/debian-gis-team/proj/-/commit/8b7f0161d0786265362af5be6bedd2b001bad297
>
> I did, too:
> https://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm/redhat/master/proj70/master/proj-7.0.0-sles12-pkgconfig.patch;h=33800266a9b8f7826a5ff6d499e12282ef8a45e7;hb=60ff67711307eb403fc1369aa5c92cccd86856fc
>
> But this requires aclocal-1.6 to build -- which is not available on RHEL 7.
Then I don't really see how a 7.0.1 release is going to help unless you
don't retool the sources.

You can also patch proj.pc to have the expected patch to not require
automake to generate it for you.

Seems easy enough to workaround on systems where the toolchain is too old.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Sebastiaan Couwenberg
In reply to this post by Devrim GÜNDÜZ-2
On 3/24/20 5:01 PM, Devrim Gündüz wrote:
> I'm very excited to push Proj 7.0 to the community repos, so that people can
> benefit from the new features -- but then there is that build failure. I would
> not pester you if it was a Fedora 31 or RHEL 6 issue, but RHEL 7 is still very
> widely used.

The problem with RHEL 7 is that is was released in 2014 around the same
time as Ubuntu trusty which is EOL since 2019.

While RHEL 7 is still widely used, partially because you cannot easily
upgrade running systems to RHEL 8, its packages are quite old by now.

Packaging recent upstream releases on LTS distribution tends to have
these problems, and it's not shame to conclude that those recent
upstream releases cannot reasonably be provided on those LTS distributions.

We see this in UbuntuGIS for example too, it's becoming increasingly
difficult to backports geospatial packages to xenial (released in 2016),
QGIS being a prime example.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Greg Troxel-2
In reply to this post by Devrim GÜNDÜZ-2
Devrim Gündüz <[hidden email]> writes:

>> As you may already be aware, the next release is scheduled for May 1st. I am
>> curious as to why this can't wait about a month to be dealt with? What are
>> the other packages that are blocked by this?
>
> I cannot comment on your release cycle (and respect that), but OTOH 7.0.0
> cannot be built on RHEL 7, a major distro.

This is something I really do not understand.  It seems RHEL 7 is a
"long term stable" kind of thing, which intentionally has older
("stable") versions of software with bug fixes.  Presumably it has an
older version of proj already.

In general, expecting arbitrary current versions of things to build with
an arbitrary old set of things cannot work, especially when there are N
such expectations for N LTS distributions.   While I think it's good for
packages such as proj to avoid gratuitously requiring very recent
versions of dependencies, 6 years is a long time.

Do I understand correctly that RHEL 7 contains versions of software that
were current in 2014?
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Sebastiaan Couwenberg

Hi,

On Tue, 2020-03-24 at 17:05 +0100, Sebastiaan Couwenberg wrote:

> Then I don't really see how a 7.0.1 release is going to help unless you
> don't retool the sources.

I won't patch configure.ac. Is that an enough reason?

> You can also patch proj.pc to have the expected patch to not require
> automake to generate it for you.

Did you see the patch that I sent you in this thread?

Anyway, this is what I get after applying that patch:

make[1]: Entering directory `/home/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0'
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /var/lib/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0/missing aclocal-1.16 -I m4
/var/lib/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0/missing: line 81: aclocal-1.16: command not found
WARNING: 'aclocal-1.16' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <https://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <https://www.gnu.org/software/autoconf>
         <https://www.gnu.org/software/m4/>
         <https://www.perl.org/>
make[1]: *** [aclocal.m4] Error 127
make[1]: Leaving directory `/home/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0'
error: Bad exit status from /var/tmp/rpm-tmp.SWFIwE (%build)

> Seems easy enough to workaround on systems where the toolchain is too old.

You are missing a point from packaging point of view. A packager should not
need aclocal while building from tarball.

Regards,

--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Sebastiaan Couwenberg

Hi,

On Tue, 2020-03-24 at 17:13 +0100, Sebastiaan Couwenberg wrote:

> Packaging recent upstream releases on LTS distribution tends to have
> these problems, and it's not shame to conclude that those recent
> upstream releases cannot reasonably be provided on those LTS distributions.

That does not make much sense on my end. The PostgreSQL RPM repo tries to
provide recent versions of the dependencies. I can say that 7.0.1 will include
this fix, so?

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Greg Troxel-2

Hi Greg,

On Tue, 2020-03-24 at 13:11 -0400, Greg Troxel wrote:
> > I cannot comment on your release cycle (and respect that), but OTOH 7.0.0
> > cannot be built on RHEL 7, a major distro.
>
> This is something I really do not understand.  It seems RHEL 7 is a
> "long term stable" kind of thing, which intentionally has older
> ("stable") versions of software with bug fixes.  Presumably it has an
> older version of proj already.

The PostGIS packages that I build depend on "our" custom Proj version (6.3.1,
and working on 7.0.X now). So, I don't care whether it has an older proj or
not.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Sebastiaan Couwenberg
In reply to this post by Devrim GÜNDÜZ-2
On 3/24/20 9:42 PM, Devrim Gündüz wrote:
> On Tue, 2020-03-24 at 17:13 +0100, Sebastiaan Couwenberg wrote:
>
>> Packaging recent upstream releases on LTS distribution tends to have
>> these problems, and it's not shame to conclude that those recent
>> upstream releases cannot reasonably be provided on those LTS distributions.
>
> That does not make much sense on my end. The PostgreSQL RPM repo tries to
> provide recent versions of the dependencies. I can say that 7.0.1 will include
> this fix, so?

The you should consider automake a dependency that you need to provide
as well.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Sebastiaan Couwenberg
In reply to this post by Devrim GÜNDÜZ-2
On 3/24/20 9:41 PM, Devrim Gündüz wrote:
>> You can also patch proj.pc to have the expected patch to not require
>> automake to generate it for you.
>
> Did you see the patch that I sent you in this thread?

I did. It's the same commit we included in the Debian package.

That is not what I meant by patching proj.pc, you can add a patch to the
RPM package that creates the resulting proj.pc without needing autoconf
the generate it for you from proj.pc.in.

That way you remove the need for the newer aclocal.

> Anyway, this is what I get after applying that patch:
>
> make[1]: Entering directory `/home/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0'
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /var/lib/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0/missing aclocal-1.16 -I m4
> /var/lib/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0/missing: line 81: aclocal-1.16: command not found
> WARNING: 'aclocal-1.16' is missing on your system.
>          You should only need it if you modified 'acinclude.m4' or
>          'configure.ac' or m4 files included by 'configure.ac'.
>          The 'aclocal' program is part of the GNU Automake package:
>          <https://www.gnu.org/software/automake>
>          It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>          <https://www.gnu.org/software/autoconf>
>          <https://www.gnu.org/software/m4/>
>          <https://www.perl.org/>
> make[1]: *** [aclocal.m4] Error 127
> make[1]: Leaving directory `/home/pgsql/git/pgrpms/rpm/redhat/master/proj70/EL-7/proj-7.0.0'
> error: Bad exit status from /var/tmp/rpm-tmp.SWFIwE (%build)
So you need to provide a newer automake for your backports as well.

>> Seems easy enough to workaround on systems where the toolchain is too old.
>
> You are missing a point from packaging point of view. A packager should not
> need aclocal while building from tarball.

Debian packages call autoreconf to regenerate the autotools files as
part of the build process, it's considered a best practice. So from my
point of view packagers should call aclocal (via autoreconf) when
building upstream sources, whether from a VCS or tarball.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Sebastiaan Couwenberg

Hi,

On Wed, 2020-03-25 at 05:50 +0100, Sebastiaan Couwenberg wrote:
> The you should consider automake a dependency that you need to provide
> as well.

You have zero idea about RHEL world, right?

I hope this does not reflect the vision of the Proj community.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Devrim GÜNDÜZ-2

Hi,

On Tue, 2020-03-24 at 12:46 +0000, Devrim Gündüz wrote:
> So, any chance to release 7.0.1 earlier than planned? RHEL/CentOS 7 is a
> majority of our user base, and this blocks other updates in the repo as well.

I'm taking this request back. Sorry for the noise.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Sebastiaan Couwenberg
In reply to this post by Devrim GÜNDÜZ-2
On 3/25/20 11:18 AM, Devrim Gündüz wrote:
> On Wed, 2020-03-25 at 05:50 +0100, Sebastiaan Couwenberg wrote:
>> The you should consider automake a dependency that you need to provide
>> as well.
>
> You have zero idea about RHEL world, right?

You obviously don't know me, I'm actually quite familiar with the RHEL
world.

> I hope this does not reflect the vision of the Proj community.

It reflects my vision as a fellow PROJ packager.

My advise for yum.postgresql.org is to be much more conservative when it
comes to including dependencies that are not required for PostgreSQL or
its extensions. PostGIS does not require PROJ >= 6.

apt.postgresql.org used to include backports of gdal & geos, mostly for
postgis. Fortunately it doesn't do that any more. When you're providing
backports of core geospatial libraries you should also provide backports
of their dependent packages like spatialite, qgis, etc. Otherwise users
will have a bad time when postgresql is using a newer version than the
other packages they use.

Since geospatial support via postgis is only an extension for
postgresql, providing backports of geospatial libraries used by postgis
should be considered out of scope yum.postgresql.org.

Updating PROJ to >= 5 is also not appropriate for EPEL 7 because it's
too disruptive. yum.postgresql.org would do well with a similar
conservative policy.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Kristian Evers-2
In reply to this post by Devrim GÜNDÜZ-2
Devrim,

Please keep the discussion civil. We all come from different backgrounds and
complete knowledge on each other areas of expertise can't be expected. Both Bas
and Greg are experienced packagers in their respective Unix/Linux distributions
and they've given you as good advice as they can. There's no need to get snarky
if that advice doesn't apply to the RHEL world.

With that being said, I don't find it necessary to disturb the established
release schedule based on this bug. I agree that the 7.0.0 release has a flaw
but as far as I am aware it has been fixed in master and will be available in
about a month's time. If this was something that affected all packaging systems
it would be higher priority to get 7.0.1 out as fast as possible. This issue
should have been caught at the release candidate stage but unfortunately it
wasn't found soon enough. I would encourage you to keep an eye on coming release
candidates and report back your feedback when something doesn't work as
expected. We can only fix the problems if we are aware of them.

/Kristian



-----Original Message-----
From: PROJ <[hidden email]> On Behalf Of Devrim Gündüz
Sent: 25. marts 2020 11:18
To: Sebastiaan Couwenberg <[hidden email]>; [hidden email]
Subject: Re: [PROJ] Calling for 7.0.1 release


Hi,

On Wed, 2020-03-25 at 05:50 +0100, Sebastiaan Couwenberg wrote:
> The you should consider automake a dependency that you need to provide
> as well.

You have zero idea about RHEL world, right?

I hope this does not reflect the vision of the Proj community.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Even Rouault-2
In reply to this post by Devrim GÜNDÜZ-2
On mardi 24 mars 2020 20:41:09 CET Devrim Gündüz wrote:
> Hi,
>
> On Tue, 2020-03-24 at 17:05 +0100, Sebastiaan Couwenberg wrote:
> > Then I don't really see how a 7.0.1 release is going to help unless you
> > don't retool the sources.
>
> I won't patch configure.ac. Is that an enough reason?

Sorry if I got lost a bit in the arguments but why, as an interim workaround,
not create a tarball generated on something more recent than RHEL 7 with a
modern tooling chain, and use that to build on RHEL 7 ?

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Devrim GÜNDÜZ-2
In reply to this post by Sebastiaan Couwenberg

Hi,

On Wed, 2020-03-25 at 11:42 +0100, Sebastiaan Couwenberg wrote:
> You obviously don't know me, I'm actually quite familiar with the RHEL
> world.

I want to publicly apologize from you and from all of the list members.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Calling for 7.0.1 release

Mike Taves
Hi all,
Also apologies from my end too, as I'm responsible for the pkg-config
break for the 7.0.0 release [1]. The good news is that it was easy to
fix [2], and I've added further safeguards to do post-install checks
[3] using pkg-config (Unix-like) and CMake (Unix-like and Windows), so
we should be able to catch these types of bugs thru CI.

[1] https://github.com/OSGeo/PROJ/pull/1950
[2] https://github.com/OSGeo/PROJ/pull/2067
[3] https://github.com/OSGeo/PROJ/pull/2077
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj