From arekm at maven.pl  Tue Aug  7 10:31:25 2018
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 7 Aug 2018 10:31:25 +0200
Subject: [packages/postgrey] fixed pidfile header (used by systemd),
 do not wrap with daemon() - these date back to initial commi
In-Reply-To: <e8e7d086492bf6a39954fbddf6271ac95eacfcec_refs_heads_master@pld-linux.org>
References: <799e786352819daf034a49426fff9e5591ab8e4b_refs_heads_master@pld-linux.org>
 <e8e7d086492bf6a39954fbddf6271ac95eacfcec_refs_heads_master@pld-linux.org>
Message-ID: <201808071031.25532.arekm@maven.pl>

On Tuesday 07 of August 2018, gotar wrote:
> commit e8e7d086492bf6a39954fbddf6271ac95eacfcec
> Author: Tomasz Pala <gotar at pld-linux.org>
> Date:   Tue Aug 7 10:02:19 2018 +0200
> 
>   do not wrap with daemon()

why?

>     - these date back to initial commit; always remove lockfile on stop()
>  	# Check if the service is already running?
>  	if [ ! -f /var/lock/subsys/postgrey ]; then
>  		msg_starting postgrey
> -		daemon /usr/sbin/postgrey -d --pidfile=/var/run/postgrey.pid $OPTIONS
> +		/usr/sbin/postgrey -d --pidfile=/var/run/postgrey.pid $OPTIONS
>  		RETVAL=$?
>  		[ $RETVAL -eq 0 ] && touch /var/lock/subsys/postgrey

missing ok/fail now?

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From gotar at polanet.pl  Tue Aug  7 13:46:53 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 7 Aug 2018 13:46:53 +0200
Subject: [packages/postgrey] fixed pidfile header (used by systemd), do
 not wrap with daemon() - these date back to initial commi
In-Reply-To: <201808071031.25532.arekm@maven.pl>
References: <799e786352819daf034a49426fff9e5591ab8e4b_refs_heads_master@pld-linux.org>
 <e8e7d086492bf6a39954fbddf6271ac95eacfcec_refs_heads_master@pld-linux.org>
 <201808071031.25532.arekm@maven.pl>
Message-ID: <20180807114653.GA17328@polanet.pl>

On Tue, Aug 07, 2018 at 10:31:25 +0200, Arkadiusz Mi?kiewicz wrote:

>>   do not wrap with daemon()
> 
> why?

It daemonizes itself - what is the purpose of this function?

> missing ok/fail now?

Yes, already fixed.

-- 
Tomasz Pala <gotar at pld-linux.org>


From arekm at maven.pl  Tue Aug  7 14:05:46 2018
From: arekm at maven.pl (Arkadiusz =?iso-8859-2?q?Mi=B6kiewicz?=)
Date: Tue, 7 Aug 2018 14:05:46 +0200
Subject: [packages/postgrey] fixed pidfile header (used by systemd),
 do not wrap with daemon() - these date back to initial commi
In-Reply-To: <20180807114653.GA17328@polanet.pl>
References: <799e786352819daf034a49426fff9e5591ab8e4b_refs_heads_master@pld-linux.org>
 <201808071031.25532.arekm@maven.pl> <20180807114653.GA17328@polanet.pl>
Message-ID: <201808071405.46421.arekm@maven.pl>

On Tuesday 07 of August 2018, Tomasz Pala wrote:
> On Tue, Aug 07, 2018 at 10:31:25 +0200, Arkadiusz Mi?kiewicz wrote:
> >>   do not wrap with daemon()
> > 
> > why?
> 
> It daemonizes itself - what is the purpose of this function?

log things to syslog
say ok/fail
set proper limits based on sysconfig/xyz service file

daemon() in rc-scripts doesn't do any deamonization (unless additional options 
are specified). It's just a wrapper to nicely do all additional jobs.

> 
> > missing ok/fail now?
> 
> Yes, already fixed.


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From gotar at polanet.pl  Thu Aug  9 19:13:15 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 9 Aug 2018 19:13:15 +0200
Subject: [packages/postgrey] fixed pidfile header (used by systemd), do
 not wrap with daemon() - these date back to initial commi
In-Reply-To: <201808071405.46421.arekm@maven.pl>
References: <799e786352819daf034a49426fff9e5591ab8e4b_refs_heads_master@pld-linux.org>
 <201808071031.25532.arekm@maven.pl>
 <20180807114653.GA17328@polanet.pl>
 <201808071405.46421.arekm@maven.pl>
Message-ID: <20180809171315.GA23409@polanet.pl>

On Tue, Aug 07, 2018 at 14:05:46 +0200, Arkadiusz Mi?kiewicz wrote:

>> >>   do not wrap with daemon()
[...]
> daemon() in rc-scripts doesn't do any deamonization (unless additional options 
> are specified). It's just a wrapper to nicely do all additional jobs.

OK, reverted this part - I had problems running postgrey under systemd
SysV fallback, I hope this wrapping doesn't break things.

-- 
Tomasz Pala <gotar at pld-linux.org>


From arekm at maven.pl  Sat Aug 11 17:48:41 2018
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sat, 11 Aug 2018 17:48:41 +0200
Subject: qt5 build system
Message-ID: <201808111748.42045.arekm@maven.pl>


Hi,

does anyone have an idea why qt5 build system thinks we are not using gcc?

Example when trying to build qt5-qtwebengine.spec from master:

 
Qt WebEngine on Linux requires clang or GCC.
QtWebEngine will not be built.


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From baggins at pld-linux.org  Sat Aug 11 23:29:02 2018
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 11 Aug 2018 23:29:02 +0200
Subject: qt5 build system
In-Reply-To: <201808111748.42045.arekm@maven.pl>
References: <201808111748.42045.arekm@maven.pl>
Message-ID: <20180811212902.GA10685@tachikoma.lan>

On Sat, 11 Aug 2018, Arkadiusz Mi?kiewicz wrote:

> 
> Hi,
> 
> does anyone have an idea why qt5 build system thinks we are not using gcc?
> 
> Example when trying to build qt5-qtwebengine.spec from master:
> 
>  
> Qt WebEngine on Linux requires clang or GCC.
> QtWebEngine will not be built.

That build system just plain sucks.

It takes it from /usr/lib/qt5/mkspecs/common/g++-base.conf : QMAKE_COMPILER
We have it set to <arch>-pld-linux-gcc and that dumb QtWebEngine wants
'gcc' there. I'd just remove that stupid check in QtWebEngine.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From adwol at zonk.pl  Tue Aug 21 15:23:02 2018
From: adwol at zonk.pl (Adam Osuchowski)
Date: Tue, 21 Aug 2018 15:23:02 +0200
Subject: manual pages file names conflict in openssl 1.1 and heimdal 7.5
Message-ID: <20180821132302.6b8b4567@zonk.pl>

File names of manual pages for functions in openssl 1.1 conflict with
its equivalents in heimdal 7.5. Example:

        file /usr/share/man/man3/DES_cbc_cksum.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_cfb64_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_ecb3_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_ecb_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_ede3_cbc_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_is_weak_key.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_key_sched.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_pcbc_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_set_key.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
        file /usr/share/man/man3/DES_set_key_checked.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64

As it turns out, heimdal defines these functions with hc_ prefix and such
symbols exist in heimdal libraries, while names without hc_ prefix are made
through #define:

$ grep '^#define DES_.*_encrypt' /usr/include/hcrypto/des.h 
#define DES_cbc_encrypt hc_DES_cbc_encrypt
#define DES_cfb64_encrypt hc_DES_cfb64_encrypt
#define DES_ecb3_encrypt hc_DES_ecb3_encrypt
#define DES_ecb_encrypt hc_DES_ecb_encrypt
#define DES_ede3_cbc_encrypt hc_DES_ede3_cbc_encrypt
#define DES_encrypt hc_DES_encrypt
#define DES_pcbc_encrypt hc_DES_pcbc_encrypt
$ nm -D /lib64/libhcrypto.so.4 | grep 'DES_.*_encrypt'
0000000000018930 T hc_DES_cbc_encrypt
00000000000194b0 T hc_DES_cfb64_encrypt
0000000000018fd0 T hc_DES_ecb3_encrypt
00000000000188b0 T hc_DES_ecb_encrypt
0000000000019060 T hc_DES_ede3_cbc_encrypt
0000000000018c80 T hc_DES_pcbc_encrypt

What should be done in such a case, to make parallel installation of
openssl-devel-1.1 and heimdal-devel possible? I thought about adding
hc_ prefix to all heimdal man pages file names but maybe someone has
idea for better solution.


From baggins at pld-linux.org  Tue Aug 21 22:09:14 2018
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 21 Aug 2018 22:09:14 +0200
Subject: manual pages file names conflict in openssl 1.1 and heimdal 7.5
In-Reply-To: <20180821132302.6b8b4567@zonk.pl>
References: <20180821132302.6b8b4567@zonk.pl>
Message-ID: <20180821200914.GB10685@tachikoma.lan>

On Tue, 21 Aug 2018, Adam Osuchowski wrote:

> File names of manual pages for functions in openssl 1.1 conflict with
> its equivalents in heimdal 7.5. Example:
> 
>         file /usr/share/man/man3/DES_cbc_cksum.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_cfb64_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_ecb3_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_ecb_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_ede3_cbc_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_is_weak_key.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_key_sched.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_pcbc_encrypt.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_set_key.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
>         file /usr/share/man/man3/DES_set_key_checked.3 from install of openssl-devel-1.1.0h-1.x86_64 conflicts with file from package heimdal-devel-7.5.0-2.x86_64
> 
> As it turns out, heimdal defines these functions with hc_ prefix and such
> symbols exist in heimdal libraries, while names without hc_ prefix are made
> through #define:
> 
> $ grep '^#define DES_.*_encrypt' /usr/include/hcrypto/des.h 
> #define DES_cbc_encrypt hc_DES_cbc_encrypt
> #define DES_cfb64_encrypt hc_DES_cfb64_encrypt
> #define DES_ecb3_encrypt hc_DES_ecb3_encrypt
> #define DES_ecb_encrypt hc_DES_ecb_encrypt
> #define DES_ede3_cbc_encrypt hc_DES_ede3_cbc_encrypt
> #define DES_encrypt hc_DES_encrypt
> #define DES_pcbc_encrypt hc_DES_pcbc_encrypt
> $ nm -D /lib64/libhcrypto.so.4 | grep 'DES_.*_encrypt'
> 0000000000018930 T hc_DES_cbc_encrypt
> 00000000000194b0 T hc_DES_cfb64_encrypt
> 0000000000018fd0 T hc_DES_ecb3_encrypt
> 00000000000188b0 T hc_DES_ecb_encrypt
> 0000000000019060 T hc_DES_ede3_cbc_encrypt
> 0000000000018c80 T hc_DES_pcbc_encrypt
> 
> What should be done in such a case, to make parallel installation of
> openssl-devel-1.1 and heimdal-devel possible? I thought about adding
> hc_ prefix to all heimdal man pages file names but maybe someone has
> idea for better solution.

That is the right solution in this case.
I added that prefix for DES_* man pages in heimdal.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From adwol at zonk.pl  Tue Aug 21 22:41:43 2018
From: adwol at zonk.pl (Adam Osuchowski)
Date: Tue, 21 Aug 2018 22:41:43 +0200
Subject: manual pages file names conflict in openssl 1.1 and heimdal 7.5
In-Reply-To: <20180821200914.GB10685@tachikoma.lan>
References: <20180821132302.6b8b4567@zonk.pl>
 <20180821200914.GB10685@tachikoma.lan>
Message-ID: <20180821204143.6b8b4567@zonk.pl>

Jan R?korajski wrote:
> That is the right solution in this case.
> I added that prefix for DES_* man pages in heimdal.

Ok, thanks, but this is not DES_* man pages issue only. I put them only
as example. I commited fix for others, too.


From qboosh at pld-linux.org  Mon Aug 27 18:35:08 2018
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 27 Aug 2018 18:35:08 +0200
Subject: [packages/rpcbind] - use upstream systemd units (with patch);
 real life check wanted - use upstream make install
In-Reply-To: <20180718144401.GA27502@mail>
References: <b89fdff5c7bd73af7601113da4127f5d6b8a7a7a_refs_heads_master@pld-linux.org>
 <743aa2864e361cc9aabb9e1365975d257d2ff599_refs_heads_master@pld-linux.org>
 <929674db-e461-a160-b08a-19e338c31741@gmail.com>
 <20180718144401.GA27502@mail>
Message-ID: <20180827163508.GA19720@mail>

On Wed, Jul 18, 2018 at 04:44:01PM +0200, Jakub Bogusz wrote:
> On Thu, Jun 14, 2018 at 12:18:27PM +0200, Andrzej Zawadzki wrote:
> >    Hi!
> >    Doesn't work :-(
> >    [root at pld-template ~]# systemctl status nfslock
> >    0M nfslock.service - NFS file locking service
> >       Loaded: loaded (/lib/systemd/system/nfslock.service; enabled; vendor
> >    preset: enabled)
> >       Active: failed (Result: exit-code) since Thu 2018-06-14 10:42:18
> >    CEST; 4min 6s ago
> >      Process: 874 ExecStopPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0
> >    fs.nfs.nlm_udpport=0 (code=exited, status=254)
> >      Process: 815 ExecStart=/sbin/rpc.statd $STATDOPTIONS (code=exited,
> >    status=1/FAILURE)
> >      Process: 808 ExecStartPre=/usr/share/nfs-utils/nfslock.preconfig
> >    (code=exited, status=0/SUCCESS)
> >    cze 14 10:42:18 pld-template rpc.statd[826]: Failed to register (statd,
> >    1, udp): svc_reg() err: RPC: Success
> >    cze 14 10:42:18 pld-template rpc.statd[826]: Failed to register (statd,
> >    1, tcp): svc_reg() err: RPC: Success
> >    cze 14 10:42:18 pld-template rpc.statd[826]: Failed to register (statd,
> >    1, udp6): svc_reg() err: RPC: Success
> >    cze 14 10:42:18 pld-template rpc.statd[826]: Failed to register (statd,
> >    1, tcp6): svc_reg() err: RPC: Success
> >    cze 14 10:42:18 pld-template rpc.statd[826]: failed to create RPC
> >    listeners, exiting
> 
> Any ideas on the cause?

"err: RPC: Success" looks odd...

> >    cze 14 10:42:18 pld-template systemd[1]: nfslock.service: Control
> >    process exited, code=exited status=1
> >    cze 14 10:42:18 pld-template sysctl[874]: sysctl: cannot stat
> >    /proc/sys/fs/nfs/nlm_tcpport: No such file or directory
> >    cze 14 10:42:18 pld-template sysctl[874]: sysctl: cannot stat
> >    /proc/sys/fs/nfs/nlm_udpport: No such file or directory
> 
> Some module not loaded?

This is clear - all of nfs.init, nfsfs.init and nfslock.init call sysctl
on fs.nfs.nlm_{tcp,udp}port, but only nfs.init ensures proper module is
loaded.
These sysctls are defined in "lockd" module; nfs.init loads "nfsd" module,
which requires "lockd". But the other .init files don't load any module.


-- 
Jakub Bogusz    http://qboosh.pl/


From atler at pld-linux.org  Fri Aug 31 19:33:12 2018
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 31 Aug 2018 19:33:12 +0200
Subject: TEST build ERRORS: poppler.spec
In-Reply-To: <pld-builder.1535735973.986188.7361@ymir-builder>
References: <cc10764f-6d68-4d2f-ae47-2eea12b0cf60@pld.src.builder>
 <pld-builder.1535735973.986188.7361@ymir-builder>
Message-ID: <20180831173312.mbcyqovfqnmy3c6e@kalarepa>

On 31.08.2018 17:19, PLD th-x86_64 builder wrote:
> CMake Error at /usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake:90 (message):
>   The imported target "openjp2_static" references the file
> 
>      "/usr/lib64/libopenjp2.a"
> 
>   but this file does not exist.  Possible reasons include:
> 
>   * The file was deleted, renamed, or moved to another location.
> 
>   * An install or uninstall procedure did not complete successfully.
> 
>   * The installation package was faulty and contained
> 
>      "/usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake"
> 
>   but not all the files it references.

It appears that openjpeg2-devel requires both openjpeg2-static (libopenjp2.a)
and openjpeg2-progs (opj_decompress). Now is it valid to specify circular
dependency:

-devel: R: -static
-static: R: -devel

>From what I've gathered empirically poldek/RPM are smart enough to handle it. Any
other ideas? Disable static libs?


Regards
Jan


From qboosh at pld-linux.org  Fri Aug 31 19:39:08 2018
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 31 Aug 2018 19:39:08 +0200
Subject: TEST build ERRORS: poppler.spec
In-Reply-To: <20180831173312.mbcyqovfqnmy3c6e@kalarepa>
References: <cc10764f-6d68-4d2f-ae47-2eea12b0cf60@pld.src.builder>
 <pld-builder.1535735973.986188.7361@ymir-builder>
 <20180831173312.mbcyqovfqnmy3c6e@kalarepa>
Message-ID: <20180831173908.GA9202@mail>

On Fri, Aug 31, 2018 at 07:33:12PM +0200, Jan Palus wrote:
> On 31.08.2018 17:19, PLD th-x86_64 builder wrote:
> > CMake Error at /usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake:90 (message):
> >   The imported target "openjp2_static" references the file
> > 
> >      "/usr/lib64/libopenjp2.a"
> > 
> >   but this file does not exist.  Possible reasons include:
> > 
> >   * The file was deleted, renamed, or moved to another location.
> > 
> >   * An install or uninstall procedure did not complete successfully.
> > 
> >   * The installation package was faulty and contained
> > 
> >      "/usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake"
> > 
> >   but not all the files it references.
> 
> It appears that openjpeg2-devel requires both openjpeg2-static (libopenjp2.a)
> and openjpeg2-progs (opj_decompress). Now is it valid to specify circular
> dependency:
> 
> -devel: R: -static
> -static: R: -devel
> 
> >From what I've gathered empirically poldek/RPM are smart enough to handle it. Any
> other ideas? Disable static libs?

Hack openjpeg cmake stuff not to check for static library.

I made such changes in at least one package (I think two), but I don't
remember which one(s) currently... I'll try to recall (the same should be
done for llvm, so that not all components are required for
find_package(LLVM) to work).


-- 
Jakub Bogusz    http://qboosh.pl/


From qboosh at pld-linux.org  Fri Aug 31 19:56:10 2018
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 31 Aug 2018 19:56:10 +0200
Subject: TEST build ERRORS: poppler.spec
In-Reply-To: <20180831173908.GA9202@mail>
References: <cc10764f-6d68-4d2f-ae47-2eea12b0cf60@pld.src.builder>
 <pld-builder.1535735973.986188.7361@ymir-builder>
 <20180831173312.mbcyqovfqnmy3c6e@kalarepa> <20180831173908.GA9202@mail>
Message-ID: <20180831175610.GB9202@mail>

On Fri, Aug 31, 2018 at 07:39:08PM +0200, Jakub Bogusz wrote:
> On Fri, Aug 31, 2018 at 07:33:12PM +0200, Jan Palus wrote:
> > On 31.08.2018 17:19, PLD th-x86_64 builder wrote:
> > > CMake Error at /usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake:90 (message):
> > >   The imported target "openjp2_static" references the file
> > > 
> > >      "/usr/lib64/libopenjp2.a"
> > > 
> > >   but this file does not exist.  Possible reasons include:
> > > 
> > >   * The file was deleted, renamed, or moved to another location.
> > > 
> > >   * An install or uninstall procedure did not complete successfully.
> > > 
> > >   * The installation package was faulty and contained
> > > 
> > >      "/usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake"
> > > 
> > >   but not all the files it references.
> > 
> > It appears that openjpeg2-devel requires both openjpeg2-static (libopenjp2.a)
> > and openjpeg2-progs (opj_decompress). Now is it valid to specify circular
> > dependency:
> > 
> > -devel: R: -static
> > -static: R: -devel
> > 
> > >From what I've gathered empirically poldek/RPM are smart enough to handle it. Any
> > other ideas? Disable static libs?
> 
> Hack openjpeg cmake stuff not to check for static library.
> 
> I made such changes in at least one package (I think two), but I don't
> remember which one(s) currently... I'll try to recall (the same should be
> done for llvm, so that not all components are required for
> find_package(LLVM) to work).

Found: gflags.spec and opencv.spec


-- 
Jakub Bogusz    http://qboosh.pl/


From atler at pld-linux.org  Fri Aug 31 20:54:14 2018
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 31 Aug 2018 20:54:14 +0200
Subject: upgrade failed OK: openjpeg2.spec
In-Reply-To: <pld-builder.1535741089.581795.14433@naiad-pld>
Message-ID: <20180831185414.per77p2itotehzhc@kalarepa>

Thanks. Done.

One more related thing though - any idea why upgrade failed?

On 31.08.2018 18:44, PLD th-x86_64 builder wrote:
> upgrading packages
> error: Failed dependencies:
> 	openjpeg2-progs = 2.3.0-2 is needed by openjpeg2-devel-2.3.0-2.x86_64
> package upgrade failed


From qboosh at pld-linux.org  Fri Aug 31 21:25:32 2018
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 31 Aug 2018 21:25:32 +0200
Subject: upgrade failed OK: openjpeg2.spec
In-Reply-To: <20180831185414.per77p2itotehzhc@kalarepa>
References: <pld-builder.1535741089.581795.14433@naiad-pld>
 <20180831185414.per77p2itotehzhc@kalarepa>
Message-ID: <20180831192532.GC9202@mail>

On Fri, Aug 31, 2018 at 08:54:14PM +0200, Jan Palus wrote:
> Thanks. Done.
> 
> One more related thing though - any idea why upgrade failed?
> 
> On 31.08.2018 18:44, PLD th-x86_64 builder wrote:
> > upgrading packages
> > error: Failed dependencies:
> > 	openjpeg2-progs = 2.3.0-2 is needed by openjpeg2-devel-2.3.0-2.x86_64
> > package upgrade failed

Automatic upgrade after build is just "freshen" - won't install any new packages.

Anyway - are -progs really required for build, or only checked in cmake stuff
and can be disabled as well?


-- 
Jakub Bogusz    http://qboosh.pl/