Обсуждение: centos7, llvm and postgresql12-devel dependencies
Fails like:
Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12)
Requires: llvm-toolset-7-clang >= 4.0.1
--
Justin
Hi, On Thu, 2020-05-14 at 09:13 -0500, Justin Pryzby wrote: > Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12) > Requires: llvm-toolset-7-clang >= 4.0.1 CentOS: yum -y install centos-release-scl Will document later tonight on website. Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
Error: Package: postgresql11-devel-11.8-1PGDG.rhel7.x86_64 (pgdg11)
Requires: llvm-toolset-7-clang >= 4.0.1
Eric Joniec
-----Original Message-----
From: Justin Pryzby <pryzby@telsasoft.com>
Sent: Thursday, May 14, 2020 10:13 AM
To: Devrim Gündüz <devrim@gunduz.org>
Cc: pgsql-pkg-yum@postgresql.org
Subject: centos7, llvm and postgresql12-devel dependencies
Fails like:
Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12)
Requires: llvm-toolset-7-clang >= 4.0.1
--
Justin
This email message and any attachments are confidential. If you are not the intended recipient, please immediately
replyto the sender and delete the message from your email system. Thank you.
Hi, On Thu, 2020-05-14 at 16:32 +0000, Eric Joniec wrote: > Error: Package: postgresql11-devel-11.8-1PGDG.rhel7.x86_64 (pgdg11) > Requires: llvm-toolset-7-clang >= 4.0.1 https://www.postgresql.org/message-id/62a3ee0df236c2dc8948e20f683bd7667a2c0ad2.camel%40gunduz.org Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On Thu, May 14, 2020 at 09:13:26AM -0500, Justin Pryzby wrote:
> Fails like:
>
> Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12)
> Requires: llvm-toolset-7-clang >= 4.0.1
I'm not sure the reason or the details of the build process, but this kind of
thing has happened before, and I suggested that the build process should check
that the built packages are installable. Is that possible ?
For now, I threw this together. On C7 it shows:
$ cat yumpg-deps2
#! /bin/sh
set -e
x=`yum list |grep pgdg12`
x=`echo "$x" |awk '{print $1}'`
for a in $x
do
y=`yum deplist "$a"`
z=`echo "$y" |grep -FwB1 'Unsatisfied dependency'` &&
echo "$a" && echo "$z" |sed q
done
sh yumpg-deps2
postgis30_12.x86_64
dependency: geos38 >= 3.8.1
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: proj70 >= 7.0.1
Unsatisfied dependency
--
dependency: geos38 >= 3.8.1
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: proj70 >= 7.0.1
Unsatisfied dependency
postgis30_12-client.x86_64
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
postgresql12-devel.x86_64
dependency: llvm-toolset-7-clang >= 4.0.1
Unsatisfied dependency
--
dependency: llvm-toolset-7-clang >= 4.0.1
Unsatisfied dependency
postgis25_12.x86_64
dependency: geos38 >= 3.8.1
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: proj70 >= 7.0.1
Unsatisfied dependency
--
dependency: geos38 >= 3.8.1
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: proj70 >= 7.0.1
Unsatisfied dependency
postgis25_12-client.x86_64
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
postgis30_12.x86_64
dependency: geos38 >= 3.8.1
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: proj70 >= 7.0.1
Unsatisfied dependency
--
dependency: geos38 >= 3.8.1
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: proj70 >= 7.0.1
Unsatisfied dependency
postgis30_12-client.x86_64
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
postgis30_12-gui.x86_64
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
--
dependency: libproj.so.19()(64bit)
Unsatisfied dependency
postgresql12-devel.x86_64
dependency: llvm-toolset-7-clang >= 4.0.1
Unsatisfied dependency
--
dependency: llvm-toolset-7-clang >= 4.0.1
Unsatisfied dependency
powa_12-web.x86_64
dependency: python3-sqlalchemy
Unsatisfied dependency
dependency: python3-tornado >= 2.0
Unsatisfied dependency
--
dependency: python3-sqlalchemy
Unsatisfied dependency
dependency: python3-tornado >= 2.0
Unsatisfied dependen
--
Justin
Hi Justin, On Thu, 2020-05-14 at 14:57 -0500, Justin Pryzby wrote: > I'm not sure the reason History starts here: https://www.postgresql.org/message-id/20190316172635.GA16265%40telsasoft.com and here: https://www.postgresql.org/message-id/CAMsr%2BYGzuPv3qSBp3LCrc9SnYi%3DiHfijdjERNNufh75%2BYM-92g%40mail.gmail.com and then: https://redmine.postgresql.org/issues/5259 > or the details of the build process, but this kind of thing has > happened before, and I suggested that the build process should check > that the built packages are installable. Is that possible ? Of course they are installable. I just wrote a basic blog post about that (will also update the website) https://people.planetpostgresql.org/devrim/index.php?/archives/104-yum-users-some-devel-RPMs-require-a-new-repository.html > For now, I threw this together. On C7 it shows: <slip> You should also check common repo, AFAICS (+ the repo in the blog post) Cheers, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
Re: Devrim Gündüz > > or the details of the build process, but this kind of thing has > > happened before, and I suggested that the build process should check > > that the built packages are installable. Is that possible ? > > Of course they are installable. I just wrote a basic blog post about > that (will also update the website) > > https://people.planetpostgresql.org/devrim/index.php?/archives/104-yum-users-some-devel-RPMs-require-a-new-repository.html I'm probably doing something wrong, but I'm seeing that the packages are missing llvm 5, not 7: base | 3.1 kB 00:00:00 centos-sclo-rh | 3.0 kB 00:00:00 centos-sclo-sclo | 3.0 kB 00:00:00 extras | 2.5 kB 00:00:00 openlogic | 2.9 kB 00:00:00 pgdg-common | 2.9 kB 00:00:00 pgdg10 | 3.6 kB 00:00:00 pgdg11 | 3.6 kB 00:00:00 pgdg12 | 3.6 kB 00:00:00 pgdg95 | 3.6 kB 00:00:00 pgdg96 | 3.6 kB 00:00:00 runner_gitlab-runner/x86_64/signature | 862 B 00:00:00 runner_gitlab-runner/x86_64/signature | 1.0 kB 00:00:00 !!! runner_gitlab-runner-source/signature | 862 B 00:00:00 runner_gitlab-runner-source/signature | 951 B 00:00:00 !!! updates [...] --> Finished Dependency Resolution Error: Package: postgresql11-devel-11.8-1PGDG.rhel7.x86_64 (pgdg11) Requires: llvm5.0-devel >= 5.0 Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12) Requires: llvm5.0-devel >= 5.0 Christoph
On Thu, May 14, 2020 at 02:57:26PM -0500, Justin Pryzby wrote:
> On Thu, May 14, 2020 at 09:13:26AM -0500, Justin Pryzby wrote:
> > Fails like:
> >
> > Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12)
> > Requires: llvm-toolset-7-clang >= 4.0.1
This package is resolved as you mentioned, thanks.
But these others appear to be real issues.
I still think the build process should check installability.
Could it run rpm --test -U ?
> I'm not sure the reason or the details of the build process, but this kind of
> thing has happened before, and I suggested that the build process should check
> that the built packages are installable. Is that possible ?
>
> For now, I threw this together. On C7 it shows:
>
> $ cat yumpg-deps2
> #! /bin/sh
> set -e
>
> x=`yum list |grep pgdg12`
> x=`echo "$x" |awk '{print $1}'`
> for a in $x
> do
> y=`yum deplist "$a"`
> z=`echo "$y" |grep -FwB1 'Unsatisfied dependency'` &&
> echo "$a" && echo "$z" |sed q
> done
>
> sh yumpg-deps2
> postgis30_12.x86_64
> dependency: geos38 >= 3.8.1
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: proj70 >= 7.0.1
> Unsatisfied dependency
> --
> dependency: geos38 >= 3.8.1
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: proj70 >= 7.0.1
> Unsatisfied dependency
> postgis30_12-client.x86_64
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> postgresql12-devel.x86_64
> dependency: llvm-toolset-7-clang >= 4.0.1
> Unsatisfied dependency
> --
> dependency: llvm-toolset-7-clang >= 4.0.1
> Unsatisfied dependency
> postgis25_12.x86_64
> dependency: geos38 >= 3.8.1
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: proj70 >= 7.0.1
> Unsatisfied dependency
> --
> dependency: geos38 >= 3.8.1
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: proj70 >= 7.0.1
> Unsatisfied dependency
> postgis25_12-client.x86_64
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> postgis30_12.x86_64
> dependency: geos38 >= 3.8.1
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: proj70 >= 7.0.1
> Unsatisfied dependency
> --
> dependency: geos38 >= 3.8.1
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: proj70 >= 7.0.1
> Unsatisfied dependency
> postgis30_12-client.x86_64
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> postgis30_12-gui.x86_64
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> --
> dependency: libproj.so.19()(64bit)
> Unsatisfied dependency
> postgresql12-devel.x86_64
> dependency: llvm-toolset-7-clang >= 4.0.1
> Unsatisfied dependency
> --
> dependency: llvm-toolset-7-clang >= 4.0.1
> Unsatisfied dependency
> powa_12-web.x86_64
> dependency: python3-sqlalchemy
> Unsatisfied dependency
> dependency: python3-tornado >= 2.0
> Unsatisfied dependency
> --
> dependency: python3-sqlalchemy
> Unsatisfied dependency
> dependency: python3-tornado >= 2.0
> Unsatisfied dependen
>
> --
> Justin
Hi, On Thu, 2020-05-21 at 08:56 -0500, Justin Pryzby wrote: > I still think the build process should check installability. > > Could it run rpm --test -U ? What if I run a mock build first? Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On Thu, May 21, 2020 at 03:40:11PM +0100, Devrim Gündüz wrote: > On Thu, 2020-05-21 at 08:56 -0500, Justin Pryzby wrote: > > I still think the build process should check installability. > > > > Could it run rpm --test -U ? > > What if I run a mock build first? I'm not familiar with RPM building so not sure if I understand the issue or your question. Do you mean test that it builds correctly with mock (I just spend 2 minutes reading about it) and then rebuild some other way (rpmbuild?) A bunch of times there's been dependencies that can't be satisfied. Do we know why ? I think there should be a separate, clean build environments for each of centos6/7/8 and it seems like that's not the case. -- Justin
I've looked at the rpm repo a bit before, but it might would help (me) if you'd describe the build infrastructure that runs the scripts. -- Justin
Hi, On Thu, 2020-05-21 at 10:19 -0500, Justin Pryzby wrote: > > What if I run a mock build first? > > > I'm not familiar with RPM building so not sure if I understand the > issue or your question. https://blog.packagecloud.io/eng/2015/05/11/building-rpm-packages-with-mock/ So, back to the problem: From time to time, I test these packages in fresh VMs. That helps me to find missing requires, etc. I don't think this is a widespread issue, and building 250' packages in mock is not a simple task (given our hw resources) Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
Hi, On Thu, 2020-05-21 at 10:19 -0500, Justin Pryzby wrote: > A bunch of times there's been dependencies that can't be satisfied. Right. > Do we know why ? As long as the README files show me the necessary dependencies, I am fine. From time to time, I install packages on clean environments, to find any missing dependencies. During the build process, rpmbuild also gives us the dependency list as well. So, usually there is no need for testing on a clean environment, but still I check. > I think there should be a separate, clean build environments > for each of centos6/7/8 and it seems like that's not the case. Setting up a clean build environment for each build is possible, but will consume a lot of time and resources. I'm not inclined to set that up. Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On Sat, Jul 11, 2020 at 02:40:21PM +0000, redmine@postgresql.org wrote: > Issue #5645 has been updated by Devrim Gündüz. > It's throwing a lot of gcc errors. What errors ? -- Justin
On Sat, Jul 11, 2020 at 10:36:04AM -0500, Justin Pryzby wrote: > On Sat, Jul 11, 2020 at 02:40:21PM +0000, redmine@postgresql.org wrote: > > Issue #5645 has been updated by Devrim Gündüz. > > It's throwing a lot of gcc errors. > > What errors ? Sorry, I bungled the subject line while replying to multiple mails earlier.. I previously compiled sqlsmith successfully on ubuntu-b; I had to install autoconf-archive package. and just now on centos6 had to: #include <cstring> on c8, I get many c++ errors.. most of which are fixed like: PKG_CONFIG_PATH=/usr/pgsql-12/lib/pkgconfig ./configure CXX='g++ -std=gnu++17' and the conninfo hack here https://github.com/anse1/sqlsmith/issues/21 -- Justin
On Sat, Jul 11, 2020 at 05:26:34PM -0500, Justin Pryzby wrote: > on c8, I get many c++ errors.. most of which are fixed like: > PKG_CONFIG_PATH=/usr/pgsql-12/lib/pkgconfig ./configure CXX='g++ -std=gnu++17' > and the conninfo hack here > https://github.com/anse1/sqlsmith/issues/21 The other issues seem to be resolved by then downgrading to libpqxx-devel-6.4.5-1.rhel8.1 -- Justin
Hi Justin, On Sat, 2020-07-11 at 17:32 -0500, Justin Pryzby wrote: > The other issues seem to be resolved by then downgrading to > > libpqxx-devel-6.4.5-1.rhel8.1 I believe it is a bit late now, libpqxx is already v 7something. Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On Tue, Jul 28, 2020 at 04:48:01PM +0100, Devrim Gündüz wrote: > On Sat, 2020-07-11 at 17:32 -0500, Justin Pryzby wrote: > > The other issues seem to be resolved by then downgrading to > > > > libpqxx-devel-6.4.5-1.rhel8.1 > > I believe it is a bit late now, libpqxx is already v 7something. The change to compile is trivial, and libpqxx-6 warnings give the needed hints. https://github.com/anse1/sqlsmith/pull/33 -- Justin
Re: To Devrim Gündüz > > Of course they are installable. I just wrote a basic blog post about > > that (will also update the website) > > > > https://people.planetpostgresql.org/devrim/index.php?/archives/104-yum-users-some-devel-RPMs-require-a-new-repository.html > > I'm probably doing something wrong, but I'm seeing that the packages > are missing llvm 5, not 7: > > --> Finished Dependency Resolution > Error: Package: postgresql11-devel-11.8-1PGDG.rhel7.x86_64 (pgdg11) > Requires: llvm5.0-devel >= 5.0 > Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12) > Requires: llvm5.0-devel >= 5.0 I got that resolved, EPEL was missing for LLVM 5. But. Is it really intended that installing postgresql12-devel pulls in LLVM 5 AND 7 ? ---> Paket postgresql12-devel.x86_64 0:12.3-5PGDG.rhel7 markiert, um installiert zu werden --> Abhängigkeit llvm5.0-devel >= 5.0 wird für Paket postgresql12-devel-12.3-5PGDG.rhel7.x86_64 verarbeitet --> Abhängigkeit llvm-toolset-7-clang >= 4.0.1 wird für Paket postgresql12-devel-12.3-5PGDG.rhel7.x86_64 verarbeitet Christoph
Re: To Devrim Gündüz > Is it really intended that installing postgresql12-devel pulls in LLVM > 5 AND 7 ? > > ---> Paket postgresql12-devel.x86_64 0:12.3-5PGDG.rhel7 markiert, um installiert zu werden > --> Abhängigkeit llvm5.0-devel >= 5.0 wird für Paket postgresql12-devel-12.3-5PGDG.rhel7.x86_64 verarbeitet > --> Abhängigkeit llvm-toolset-7-clang >= 4.0.1 wird für Paket postgresql12-devel-12.3-5PGDG.rhel7.x86_64 verarbeitet Hmm, it seems that 7 is only some package version and it actually contains 5.0. Weird. Installing : llvm5.0-libs-5.0.1-7.el7.x86_64 1/24 Installing : llvm-toolset-7-runtime-5.0.1-4.el7.x86_64 2/24 Installing : llvm-toolset-7-llvm-libs-5.0.1-8.el7.x86_64 3/24 Installing : llvm-toolset-7-compiler-rt-5.0.1-2.el7.x86_64 4/24 Installing : llvm-toolset-7-libomp-5.0.1-2.el7.x86_64 5/24 Christoph
On Thu, May 14, 2020 at 02:57:26PM -0500, Justin Pryzby wrote: > On Thu, May 14, 2020 at 09:13:26AM -0500, Justin Pryzby wrote: > > Fails like: > > > > Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12) > > Requires: llvm-toolset-7-clang >= 4.0.1 > > I'm not sure the reason or the details of the build process, but this kind of > thing has happened before, and I suggested that the build process should check > that the built packages are installable. Is that possible ? > > For now, I threw this together. On C7 it shows: I also found this tool ; maybe it'd be helpful. rpm -qf `which repoclosure` yum-utils-1.1.31-52.el7.noarch RH7: time repoclosure -n -l base -l epel -l centos-sclo-rh -r pgdg-common -r pgdg13-updates-testing |less RH8: time repoclosure -n --disablerepo '*' --enablerepo=BaseOS --enablerepo=epel --check pgdg-common --check pgdg13-updates-testing|less I don't currently see any significant issue in the repos I've looked. I think you'd want to separately check each combination of the PG repos and their supported OS versions. -- Justin
On Tue, Sep 15, 2020 at 12:34:50PM -0500, Justin Pryzby wrote:
> On Thu, May 14, 2020 at 02:57:26PM -0500, Justin Pryzby wrote:
> > On Thu, May 14, 2020 at 09:13:26AM -0500, Justin Pryzby wrote:
> > > Fails like:
> > >
> > > Error: Package: postgresql12-devel-12.3-1PGDG.rhel7.x86_64 (pgdg12)
> > > Requires: llvm-toolset-7-clang >= 4.0.1
> >
> > I'm not sure the reason or the details of the build process, but this kind of
> > thing has happened before, and I suggested that the build process should check
> > that the built packages are installable. Is that possible ?
> >
> > For now, I threw this together. On C7 it shows:
>
> I also found this tool ; maybe it'd be helpful.
>
> rpm -qf `which repoclosure`
> yum-utils-1.1.31-52.el7.noarch
>
> RH7:
> time repoclosure -n -l base -l epel -l centos-sclo-rh -r pgdg-common -r pgdg13-updates-testing |less
> RH8:
> time repoclosure -n --disablerepo '*' --enablerepo=BaseOS --enablerepo=epel --check pgdg-common --check
pgdg13-updates-testing|less
This is currently complicates upgrading off of postgis alpha:
package: gdal32-libs-3.2.2-13.rhel7.x86_64 from pgdg-common
unresolved deps:
proj72 >= 0:8.0.0
I was able to install gdal32-libs by specifying the previous version
(yum is evidently too dumb to figure this out on its own).
--
Justin Pryzby
System Administrator
Telsasoft
+1-952-707-8581
Re: proj72 dependency (Re: centos7, llvm and postgresql12-devel dependencies)
От
Devrim Gündüz
Дата:
Hi, On Mon, 2021-03-22 at 08:35 -0500, Justin Pryzby wrote: > This is currently complicates upgrading off of postgis alpha: > > package: gdal32-libs-3.2.2-13.rhel7.x86_64 from pgdg-common > unresolved deps: > proj72 >= 0:8.0.0 > > I was able to install gdal32-libs by specifying the previous version > (yum is evidently too dumb to figure this out on its own). Just fixed after a bit series of updates. Sorry for the inconvenience. Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
Re: proj72 dependency (Re: centos7, llvm and postgresql12-devel dependencies)
От
Devrim Gündüz
Дата:
Hi, On Mon, 2021-03-22 at 08:35 -0500, Justin Pryzby wrote: > This is currently complicates upgrading off of postgis alpha: > > package: gdal32-libs-3.2.2-13.rhel7.x86_64 from pgdg-common > unresolved deps: > proj72 >= 0:8.0.0 > > I was able to install gdal32-libs by specifying the previous version > (yum is evidently too dumb to figure this out on its own). That was a packaging accident. Someone reported this in redmine, and already fixed. Long story short: No Proj 8+ on RHEL 7, because of compilation issues. Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR