Re: [packages/rpm-pld-macros] - version 1.752: "noarchpackage" macro to cut down boilerplate

2020-10-04 Thread Jan Rękorajski 
On Fri, 02 Oct 2020, qboosh wrote:

> commit 0b4ebb8c0a63e29ec47b0e6d4f78c9f2759a5a9c
> Author: Jakub Bogusz 
> Date:   Fri Oct 2 17:11:47 2020 +0200
> 
> - version 1.752: "noarchpackage" macro to cut down boilerplate

> 
>  macros.pld  | 8 
>  rpm-pld-macros.spec | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> ---
> diff --git a/rpm-pld-macros.spec b/rpm-pld-macros.spec
> index 4bb0e55..0aa5cf4 100644
> --- a/rpm-pld-macros.spec
> +++ b/rpm-pld-macros.spec
> @@ -1,4 +1,4 @@
> -%define  rpm_macros_rev  1.751
> +%define  rpm_macros_rev  1.752
>  %define  find_lang_rev   1.40
>  # split into individual X_prov_ver if there is a reason to desync
>  %define  prov_ver4.15
> diff --git a/macros.pld b/macros.pld
> index ed5a896..93386d5 100644
> --- a/macros.pld
> +++ b/macros.pld
> @@ -521,6 +521,14 @@ Provides: %{1} = 
> %{?epoch:%{epoch}:}%{?version:%{version}}%{?release:-%{release}
>  %_ver_lt()   %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo $?) -ne 
> 2; echo $?)
>  %_ver_ge()   %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo $?) -eq 
> 2; echo $?)
>  
> +# noarch subpackage helper
> +# BuildRequires: rpmbuild(macros) >= 1.752
> +%noarchpackage \
> +%if %{_ver_ge '%{_rpmversion}' '4.6'} \
> +BuildArch:   noarch \
> +%endif \
> +%{nil}
> +
>  %apache_modules_api %{expand:%%global apache_modules_api %(awk '/#define 
> MODULE_MAGIC_NUMBER_MAJOR/ {print $3}' /usr/include/apache/ap_mmn.h 
> 2>/dev/null || echo ERROR)}%apache_modules_api
>  
>  # sgml macros

Wht do we even have this junk? Is *anyone* running such an ancient rpm
that does not understand noarch subpackages?

We should just remove the condition instead of trying to make it prettier.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: OK: rust.spec

2020-10-04 Thread Jan Rękorajski 
On Sun, 04 Oct 2020, PLD th-x32 builder wrote:

> rust.spec (auto/th/rust-1.44.1-2): OK
> 
> --- rust.spec:auto/th/rust-1.44.1-2:
> upgrading packages
> Build-Time: user:22480.24s sys:327.35s real:7031.10s (faults io:17 
> non-io:47582180)
> 
> Files queued for ftp:
>   13348158 rust-debuginfo-1.44.1-2.x32.rpm
>  10224 zsh-completion-cargo-1.44.1-2.x32.rpm
>   8428 bash-completion-cargo-1.44.1-2.x32.rpm
>4034573 cargo-1.44.1-2.x32.rpm
>   14821218 rust-doc-1.44.1-2.noarch.rpm
>   8969 rust-lldb-1.44.1-2.noarch.rpm
>  10439 rust-gdb-1.44.1-2.noarch.rpm
>   9304 rust-debugger-common-1.44.1-2.noarch.rpm
>   56994390 rust-1.44.1-2.x32.rpm
>410 rust-1.44.1-2.src.rpm.uploadinfo

Unfortunately this build does not produce x32 output.

Sample from building librsvg on x32:

libtool: link:  x86_64-pld-linux-gnux32-gcc -shared  -fPIC -DPIC  -pthread -O2 
-fstack-protector-strong -mtune=generic -march=x86-64 -Wl,-Bsymbolic-functions 
-Wl,--as-needed
+-Wl,--no-copy-dt-needed-entries -Wl,-z -Wl,relro -Wl,-z -Wl,combreloc   
-pthread  librsvg/.libs/2_la-librsvg-features.o librsvg/.libs/2_la-rsvg-base.o 
librsvg/.libs/2_la-rsvg-handle.o
+librsvg/.libs/2_la-rsvg-pixbuf.o  -Wl,--whole-archive ./.libs/librsvg_c_api.a 
-Wl,--no-whole-archive  -lcairo-gobject -lgdk_pixbuf-2.0 -lgio-2.0 
/usr/libx32/libxml2.so -L/usr/libx32
+/usr/libx32/liblzma.so -lpthread -lpangocairo-1.0 -lcairo -lpangoft2-1.0 
-lpango-1.0 -lgobject-2.0 -lglib-2.0 /usr/libx32/libfontconfig.so 
/usr/libx32/libexpat.so /usr/libx32/libuuid.so
+/usr/libx32/libfreetype.so /usr/libx32/libbz2.so /usr/libx32/libpng16.so -lz 
-lharfbuzz /usr/libx32/libbrotlidec.so /usr/libx32/libbrotlicommon.so -lm -ldl 
-Wl,-soname -Wl,librsvg-2.so.2
+-Wl,-version-script -Wl,.libs/librsvg-2.ver -o .libs/librsvg-2.so.2.47.0
/usr/bin/ld: i386:x86-64 architecture of input file 
`./.libs/librsvg_c_api.a(rsvg_c_api-1bb89e3c1c21f1fa.rsvg_c_api.28lfa0sz-cgu.0.rcgu.o)'
 is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`./.libs/librsvg_c_api.a(rsvg_c_api-1bb89e3c1c21f1fa.rsvg_c_api.28lfa0sz-cgu.1.rcgu.o)'
 is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`./.libs/librsvg_c_api.a(rsvg_c_api-1bb89e3c1c21f1fa.rsvg_c_api.28lfa0sz-cgu.10.rcgu.o)'
 is incompatible with i386:x64-32 output
[... and so on for all files ...]

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Strange multilib `poldek -i` behaviour [Re: OK: COMMAND]

2020-10-04 Thread Jakub Bogusz 
I tried to execute:
`poldek -iv openssl-devel-1.1.1g-1.x86_64 zlib-devel-1.2.11-2.x86_64`
And why it refused with "equal version installed"?

`rpm -q openssl-devel zlib-devel` returned:

openssl-devel-1.1.1g-1.x32
zlib-devel-1.2.11-2.x32

Adding `--force` helped (but only -devel packages were installed,
I must have installed openssl.x86_64 manually).


On Sun, Oct 04, 2020 at 12:23:09PM +, PLD th-x32 builder wrote:
> COMMAND (): OK
> 
> --- COMMAND::
> Build-Time: user:2.00s sys:0.18s real:2.22s (faults io:0 non-io:30899)
> 
> 
> 
> *** buildlog for COMMAND
> Loading [pndir]th-x86_64...
> Loading [pndir]th-x86_64-ready...
> Loading [pndir]th-x86_64-test...
> 22166 packages read
> openssl-devel-1.1.1g-1.x86_64: equal version installed, skipped
> zlib-devel-1.2.11-2.x86_64: equal version installed, skipped
> Nothing to do
> Begin-PLD-Builder-Info
> Build-Time: user:2.00s sys:0.18s real:2.22s (faults io:0 non-io:30899)
> 
> End-PLD-Builder-Info
> 

-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en