From atler at pld-linux.org  Mon Feb  3 11:06:48 2025
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 3 Feb 2025 11:06:48 +0100
Subject: [packages/meson] - install rpm macros for meson
 prep/build/install, rel 2
In-Reply-To: <181b4a43bc70a3d8032d2d79434a37df8ffcd867_refs_heads_master@pld-linux.org>
References: <e87f98e13a6fd0065e56c7cabd49f7a208bd27f4_refs_heads_master@pld-linux.org>
 <181b4a43bc70a3d8032d2d79434a37df8ffcd867_refs_heads_master@pld-linux.org>
Message-ID: <brmjqgz7jucehrlq6c7kwjxmoi73h47sle2pkjzhs5rhxywmhw@gsvkqpnczus3>

On 03.02.2025 10:10, baggins wrote:
> commit 181b4a43bc70a3d8032d2d79434a37df8ffcd867
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Mon Feb 3 09:59:20 2025 +0100
> 
>     - install rpm macros for meson prep/build/install, rel 2

Mind that these macros use %{_smp_build_ncpus} which requires
rpm.org >= 4.15 and is unconstrained by anything in our macros hence you
got "-j 56" instead of expected "-j 28" in glycin build.

Also --default-library=both is lost which otherwise defaults to
"shared".


From atler at pld-linux.org  Mon Feb  3 11:31:35 2025
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 3 Feb 2025 11:31:35 +0100
Subject: [packages/meson] - install rpm macros for meson
 prep/build/install, rel 2
In-Reply-To: <brmjqgz7jucehrlq6c7kwjxmoi73h47sle2pkjzhs5rhxywmhw@gsvkqpnczus3>
References: <e87f98e13a6fd0065e56c7cabd49f7a208bd27f4_refs_heads_master@pld-linux.org>
 <181b4a43bc70a3d8032d2d79434a37df8ffcd867_refs_heads_master@pld-linux.org>
 <brmjqgz7jucehrlq6c7kwjxmoi73h47sle2pkjzhs5rhxywmhw@gsvkqpnczus3>
Message-ID: <elpzwlshg4u5dsa7n673rttbz3npcdtsrh5o235zupwaaegpi6@wppss7lstgem>

On 03.02.2025 11:06, Jan Palus wrote:
> On 03.02.2025 10:10, baggins wrote:
> > commit 181b4a43bc70a3d8032d2d79434a37df8ffcd867
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Mon Feb 3 09:59:20 2025 +0100
> > 
> >     - install rpm macros for meson prep/build/install, rel 2
> 
> Mind that these macros use %{_smp_build_ncpus} which requires
> rpm.org >= 4.15 and is unconstrained by anything in our macros hence you
> got "-j 56" instead of expected "-j 28" in glycin build.
> 
> Also --default-library=both is lost which otherwise defaults to
> "shared".

We actually ship two %meson macros now... I guess we should settle on
single one. The one from meson does not set any compiler paths or flags
while ours does not make use of %{_vpath_*} macros.


From j.rekorajski at gmail.com  Mon Feb  3 11:38:42 2025
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Mon, 3 Feb 2025 11:38:42 +0100
Subject: [packages/meson] - install rpm macros for meson
 prep/build/install, rel 2
In-Reply-To: <elpzwlshg4u5dsa7n673rttbz3npcdtsrh5o235zupwaaegpi6@wppss7lstgem>
References: <e87f98e13a6fd0065e56c7cabd49f7a208bd27f4_refs_heads_master@pld-linux.org>
 <181b4a43bc70a3d8032d2d79434a37df8ffcd867_refs_heads_master@pld-linux.org>
 <brmjqgz7jucehrlq6c7kwjxmoi73h47sle2pkjzhs5rhxywmhw@gsvkqpnczus3>
 <elpzwlshg4u5dsa7n673rttbz3npcdtsrh5o235zupwaaegpi6@wppss7lstgem>
Message-ID: <CAKY5yHwVuvTxmT3QpPAEHifYDAS5y7Bzc735UYL7Gu1kHnrAUQ@mail.gmail.com>

On Mon, 3 Feb 2025 at 11:31, Jan Palus <atler at pld-linux.org> wrote:

> On 03.02.2025 11:06, Jan Palus wrote:
> > On 03.02.2025 10:10, baggins wrote:
> > > commit 181b4a43bc70a3d8032d2d79434a37df8ffcd867
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Mon Feb 3 09:59:20 2025 +0100
> > >
> > >     - install rpm macros for meson prep/build/install, rel 2
> >
> > Mind that these macros use %{_smp_build_ncpus} which requires
> > rpm.org >= 4.15 and is unconstrained by anything in our macros hence you
> > got "-j 56" instead of expected "-j 28" in glycin build.
> >
> > Also --default-library=both is lost which otherwise defaults to
> > "shared".
>
> We actually ship two %meson macros now... I guess we should settle on
> single one. The one from meson does not set any compiler paths or flags
> while ours does not make use of %{_vpath_*} macros.
>

Yeah, we need to iron out the wrinkles, but at least the macros make sense
now and
correctly build projects using meson as build system. With our macros it
was a mess
of setting up with meson and then building directly with ninja what
resulted in rebuilds
during install and hard to track build issues.

My take is that we need to update global macros to set compiler paths and
our rust tricks,
patch meson to comply with the rest of our macros and drop %meson macro from
PLD rpm global macros.

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


From qboosh at pld-linux.org  Wed Feb  5 19:39:12 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 5 Feb 2025 19:39:12 +0100
Subject: [packages/rpm-pld-macros] - big cleanup of the main macros -
 removed macros identical with upstream - added new hotness for bu
In-Reply-To: <0d35eeb25706bc93fd9419c3ab26567ce8e3c2ee_refs_heads_master@pld-linux.org>
References: <278f6f17d501af3b28bf5df91c0780198700adfc_refs_heads_master@pld-linux.org>
 <0d35eeb25706bc93fd9419c3ab26567ce8e3c2ee_refs_heads_master@pld-linux.org>
Message-ID: <20250205183912.GA843@mail>

On Wed, Feb 05, 2025 at 02:04:02AM +0100, baggins wrote:
>  
> -%configure {./configure \
> -	LDFLAGS="${LDFLAGS:-%rpmldflags}" \
> -	CFLAGS="${CFLAGS:-%rpmcflags}" \
> -	CXXFLAGS="${CXXFLAGS:-%rpmcxxflags}" \
> -	FFLAGS="${FFLAGS:-%rpmcflags}" \
> -	FCFLAGS="${FCFLAGS:-%rpmcflags}" \
> -	CPPFLAGS="${CPPFLAGS:-%rpmcppflags}" \
> -	%{?__cc:CC="%{__cc}"} \
> -	%{?__cxx:CXX="%{__cxx}"} \
> +%configure { \
> +  %{set_build_flags}; \
> +  ./configure \
>  	--host=%{_target_platform} \
>  	--build=%{_target_platform} \
>  	--prefix=%{_prefix} \


This change breaks invocation like:

bash %configure

if given configure is too bashish (now shebang change would be
required) - e.g. which.spec


BTW: please remember to bump macros BRs when switching specs to new
macros (>= 2.042, so bumping meson/ninja is not requred).


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


From atler at pld-linux.org  Thu Feb  6 13:54:01 2025
From: atler at pld-linux.org (Jan Palus)
Date: Thu, 6 Feb 2025 13:54:01 +0100
Subject: ERRORS: mozilla-firefox-bin.spec
In-Reply-To: <pld-builder.1738844534.722428.40087@naiad>
References: <82b13d2f-38a3-4e87-a661-42b40374236d@pld.src.builder>
 <pld-builder.1738844534.722428.40087@naiad>
Message-ID: <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>

On 06.02.2025 12:22, PLD th-x32 builder wrote:
> mozilla-firefox-bin.spec (HEAD): FAILED
...
> + exec nice -n 0 rpmbuild -bp --short-circuit --nodeps --define '_topdir /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define '_sourcedir %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define '_builddir %{_topdir}/BUILD' --target x32-pld-linux --define 'prep exit 0' /tmp/B.bco753jf/mozilla-firefox-bin.spec
> Building target platforms: x32-pld-linux
> Building for target x32-pld-linux
> warning: line 40: It's not recommended to have unversioned Obsoletes: Obsoletes:	mozilla-firebird
...
> + exec nice -n 0 rpmbuild -bb --define '__jobs 28' --define '_smp_mflags -j28' --define '_make_opts -Otarget' --define '_pld_builder 1' --define '_topdir /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define '_sourcedir %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define '_builddir %{_topdir}/BUILD' --target x32-pld-linux /tmp/B.bco753jf/mozilla-firefox-bin.spec
> Building target platforms: x32-pld-linux
> Building for target x32-pld-linux
> warning: line 40: It's not recommended to have unversioned Obsoletes: Obsoletes:	mozilla-firebird
> error: Signature expired on 2015-03-28 06:35:09
> Executing(%mkbuilddir): /bin/sh -e /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.Bou2cg
> + umask 022
> + cd /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> + test -d /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> + /bin/chmod -Rf a+rX,u+w,g-w,o-w /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> + /bin/rm '--interactive=never' -rf /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> + /bin/mkdir -p /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> + /bin/mkdir -p /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build/SPECPARTS
> + RPM_EC=0 
> + jobs -p
> + exit 0
> Executing(%prep): /bin/sh -e /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.X7RJbH

ExclusiveArch is no longer a thing in new rpm? Or why it didn't
error out here (spec has ExclusiveArch: i686 athlon %{x8664})?


From j.rekorajski at gmail.com  Thu Feb  6 15:35:28 2025
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Thu, 6 Feb 2025 15:35:28 +0100
Subject: ERRORS: mozilla-firefox-bin.spec
In-Reply-To: <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
References: <82b13d2f-38a3-4e87-a661-42b40374236d@pld.src.builder>
 <pld-builder.1738844534.722428.40087@naiad>
 <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
Message-ID: <CAKY5yHw-hLhmoFss1x7iXW5yVC0NxQTWL02wc52GZv+EArzvuQ@mail.gmail.com>

On Thu, 6 Feb 2025 at 14:00, Jan Palus <atler at pld-linux.org> wrote:

> On 06.02.2025 12:22, PLD th-x32 builder wrote:
> > mozilla-firefox-bin.spec (HEAD): FAILED
> ...
> > + exec nice -n 0 rpmbuild -bp --short-circuit --nodeps --define '_topdir
> /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define '_sourcedir
> %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define '_builddir
> %{_topdir}/BUILD' --target x32-pld-linux --define 'prep exit 0'
> /tmp/B.bco753jf/mozilla-firefox-bin.spec
> > Building target platforms: x32-pld-linux
> > Building for target x32-pld-linux
> > warning: line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes:      mozilla-firebird
> ...
> > + exec nice -n 0 rpmbuild -bb --define '__jobs 28' --define '_smp_mflags
> -j28' --define '_make_opts -Otarget' --define '_pld_builder 1' --define
> '_topdir /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define
> '_sourcedir %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define
> '_builddir %{_topdir}/BUILD' --target x32-pld-linux
> /tmp/B.bco753jf/mozilla-firefox-bin.spec
> > Building target platforms: x32-pld-linux
> > Building for target x32-pld-linux
> > warning: line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes:      mozilla-firebird
> > error: Signature expired on 2015-03-28 06:35:09
> > Executing(%mkbuilddir): /bin/sh -e
> /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.Bou2cg
> > + umask 022
> > + cd /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + test -d /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/chmod -Rf a+rX,u+w,g-w,o-w
> /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/rm '--interactive=never' -rf
> /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/mkdir -p /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/mkdir -p
> /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build/SPECPARTS
> > + RPM_EC=0
> > + jobs -p
> > + exit 0
> > Executing(%prep): /bin/sh -e /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.X7RJbH
>
> ExclusiveArch is no longer a thing in new rpm? Or why it didn't
> error out here (spec has ExclusiveArch: i686 athlon %{x8664})?
>

Parsing problem in builder script? Wild guess - it's looking at the last
error message.
rpm complained as expected.

Building target platforms: x32-pld-linux
Building for target x32-pld-linux
warning: line 40: It's not recommended to have unversioned Obsoletes:
Obsoletes: mozilla-firebird

RPM build warnings:
    line 40: It's not recommended to have unversioned Obsoletes: Obsoletes:
mozilla-firebird
checking BuildConflict-ing packages
rpm: Building target platforms: x32-pld-linux
rpm: Building for target x32-pld-linux
rpm: warning: line 40: It's not recommended to have unversioned Obsoletes:
Obsoletes: mozilla-firebird
rpm: error: Architecture is not included: x32
rpm: error: Signature expired on 2015-03-28 06:35:09
rpm:
rpm: RPM build warnings:
rpm:     line 40: It's not recommended to have unversioned Obsoletes:
Obsoletes: mozilla-firebird
no BuildConflicts found
checking BR
rpm: Building target platforms: x32-pld-linux
rpm: Building for target x32-pld-linux
rpm: warning: line 40: It's not recommended to have unversioned Obsoletes:
Obsoletes: mozilla-firebird
rpm: error: Architecture is not included: x32
rpm: error: Signature expired on 2015-03-28 06:35:09
rpm:
rpm: RPM build warnings:
rpm:     line 40: It's not recommended to have unversioned Obsoletes:
Obsoletes: mozilla-firebird
no BR needed

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


From atler at pld-linux.org  Thu Feb  6 15:45:34 2025
From: atler at pld-linux.org (Jan Palus)
Date: Thu, 6 Feb 2025 15:45:34 +0100
Subject: ERRORS: mozilla-firefox-bin.spec
In-Reply-To: <CAKY5yHw-hLhmoFss1x7iXW5yVC0NxQTWL02wc52GZv+EArzvuQ@mail.gmail.com>
References: <82b13d2f-38a3-4e87-a661-42b40374236d@pld.src.builder>
 <pld-builder.1738844534.722428.40087@naiad>
 <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
 <CAKY5yHw-hLhmoFss1x7iXW5yVC0NxQTWL02wc52GZv+EArzvuQ@mail.gmail.com>
Message-ID: <rlb4hs3efh7rk5tq23lvhafuhi7szmwthxavwsb2cgpsxo65yi@qip5atpxyxee>

On 06.02.2025 15:35, Jan R?korajski wrote:
> On Thu, 6 Feb 2025 at 14:00, Jan Palus <atler at pld-linux.org> wrote:
> 
> > On 06.02.2025 12:22, PLD th-x32 builder wrote:
> > > mozilla-firefox-bin.spec (HEAD): FAILED
> > ...
> > > + exec nice -n 0 rpmbuild -bp --short-circuit --nodeps --define '_topdir
> > /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define '_sourcedir
> > %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define '_builddir
> > %{_topdir}/BUILD' --target x32-pld-linux --define 'prep exit 0'
> > /tmp/B.bco753jf/mozilla-firefox-bin.spec
> > > Building target platforms: x32-pld-linux
> > > Building for target x32-pld-linux
> > > warning: line 40: It's not recommended to have unversioned Obsoletes:
> > Obsoletes:      mozilla-firebird
> > ...
> > > + exec nice -n 0 rpmbuild -bb --define '__jobs 28' --define '_smp_mflags
> > -j28' --define '_make_opts -Otarget' --define '_pld_builder 1' --define
> > '_topdir /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define
> > '_sourcedir %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define
> > '_builddir %{_topdir}/BUILD' --target x32-pld-linux

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > /tmp/B.bco753jf/mozilla-firefox-bin.spec
> > > Building target platforms: x32-pld-linux
> > > Building for target x32-pld-linux
> > > warning: line 40: It's not recommended to have unversioned Obsoletes:
> > Obsoletes:      mozilla-firebird
> > > error: Signature expired on 2015-03-28 06:35:09
> > > Executing(%mkbuilddir): /bin/sh -e
> > /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.Bou2cg
> > > + umask 022
> > > + cd /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > > + test -d /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > > + /bin/chmod -Rf a+rX,u+w,g-w,o-w
> > /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > > + /bin/rm '--interactive=never' -rf
> > /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > > + /bin/mkdir -p /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > > + /bin/mkdir -p
> > /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build/SPECPARTS
> > > + RPM_EC=0
> > > + jobs -p
> > > + exit 0
> > > Executing(%prep): /bin/sh -e /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.X7RJbH
> >
> > ExclusiveArch is no longer a thing in new rpm? Or why it didn't
> > error out here (spec has ExclusiveArch: i686 athlon %{x8664})?
> >
> 
> Parsing problem in builder script? Wild guess - it's looking at the last
> error message.
> rpm complained as expected.
> 
> Building target platforms: x32-pld-linux
> Building for target x32-pld-linux
> warning: line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes: mozilla-firebird
> 
> RPM build warnings:
>     line 40: It's not recommended to have unversioned Obsoletes: Obsoletes:
> mozilla-firebird
> checking BuildConflict-ing packages
> rpm: Building target platforms: x32-pld-linux
> rpm: Building for target x32-pld-linux
> rpm: warning: line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes: mozilla-firebird
> rpm: error: Architecture is not included: x32
> rpm: error: Signature expired on 2015-03-28 06:35:09
> rpm:
> rpm: RPM build warnings:
> rpm:     line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes: mozilla-firebird
> no BuildConflicts found
> checking BR
> rpm: Building target platforms: x32-pld-linux
> rpm: Building for target x32-pld-linux
> rpm: warning: line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes: mozilla-firebird
> rpm: error: Architecture is not included: x32
> rpm: error: Signature expired on 2015-03-28 06:35:09
> rpm:
> rpm: RPM build warnings:
> rpm:     line 40: It's not recommended to have unversioned Obsoletes:
> Obsoletes: mozilla-firebird
> no BR needed

from what I've checked builder looks at exit code alone. but more
interesting is why rpmbuild did proceed with actual build failing
in %install since no tarball was extracted in %prep


From qboosh at pld-linux.org  Thu Feb  6 17:42:34 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 6 Feb 2025 17:42:34 +0100
Subject: [packages/rpm-pld-macros] - big cleanup of the main macros -
 removed macros identical with upstream - added new hotness for bu
In-Reply-To: <20250205183912.GA843@mail>
References: <278f6f17d501af3b28bf5df91c0780198700adfc_refs_heads_master@pld-linux.org>
 <0d35eeb25706bc93fd9419c3ab26567ce8e3c2ee_refs_heads_master@pld-linux.org>
 <20250205183912.GA843@mail>
Message-ID: <20250206164234.GA18660@mail>

On Wed, Feb 05, 2025 at 07:39:12PM +0100, Jakub Bogusz wrote:
> On Wed, Feb 05, 2025 at 02:04:02AM +0100, baggins wrote:
> >  
> > -%configure {./configure \
> > -	LDFLAGS="${LDFLAGS:-%rpmldflags}" \
> > -	CFLAGS="${CFLAGS:-%rpmcflags}" \
> > -	CXXFLAGS="${CXXFLAGS:-%rpmcxxflags}" \
> > -	FFLAGS="${FFLAGS:-%rpmcflags}" \
> > -	FCFLAGS="${FCFLAGS:-%rpmcflags}" \
> > -	CPPFLAGS="${CPPFLAGS:-%rpmcppflags}" \
> > -	%{?__cc:CC="%{__cc}"} \
> > -	%{?__cxx:CXX="%{__cxx}"} \
> > +%configure { \
> > +  %{set_build_flags}; \
> > +  ./configure \
> >  	--host=%{_target_platform} \
> >  	--build=%{_target_platform} \
> >  	--prefix=%{_prefix} \
> 
> 
> This change breaks invocation like:
> 
> bash %configure
> 
> if given configure is too bashish (now shebang change would be
> required) - e.g. which.spec

And more cases:

2)

VAR=val %configure

(now needs to be changed to export before %configure)

3)

../%configure ...

(see e.g. apache.spec)

This has no obvious replacement.
In some cases maybe configure symlink would work, depending on source
directory detection (relative to $0 or relative to $0 realpath)


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


From qboosh at pld-linux.org  Thu Feb  6 17:47:30 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 6 Feb 2025 17:47:30 +0100
Subject: ERRORS: mozilla-firefox-bin.spec
In-Reply-To: <rlb4hs3efh7rk5tq23lvhafuhi7szmwthxavwsb2cgpsxo65yi@qip5atpxyxee>
References: <82b13d2f-38a3-4e87-a661-42b40374236d@pld.src.builder>
 <pld-builder.1738844534.722428.40087@naiad>
 <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
 <CAKY5yHw-hLhmoFss1x7iXW5yVC0NxQTWL02wc52GZv+EArzvuQ@mail.gmail.com>
 <rlb4hs3efh7rk5tq23lvhafuhi7szmwthxavwsb2cgpsxo65yi@qip5atpxyxee>
Message-ID: <20250206164730.GB18660@mail>

On Thu, Feb 06, 2025 at 03:45:34PM +0100, Jan Palus wrote:
[...]
> from what I've checked builder looks at exit code alone. but more
> interesting is why rpmbuild did proceed with actual build failing
> in %install since no tarball was extracted in %prep

One more rpm 4.20 change - it's not sufficied to place "#" before "%patch"
to disable it.
See last apache.spec build:

http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=apache&id=c4122fff-61d7-4f8f-80ba-c31ee811d0c6&action=tail

It seems that comment disables only printing "Patch #25" header, but not
applying patch itself.


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


From atler at pld-linux.org  Thu Feb  6 19:24:56 2025
From: atler at pld-linux.org (Jan Palus)
Date: Thu, 6 Feb 2025 19:24:56 +0100
Subject: [packages/libsoup3] - disable autobahn tests explicitly (with
 new meson macros auto features default to enabled); releas
In-Reply-To: <159dc91da656d9ea2b7bdfd78dc57616c7c0dac4_refs_heads_master@pld-linux.org>
References: <40877958cc73b20a54c4fa95612c680e210b66b4_refs_heads_master@pld-linux.org>
 <159dc91da656d9ea2b7bdfd78dc57616c7c0dac4_refs_heads_master@pld-linux.org>
Message-ID: <4awshyi7ewjoeowbog425elrgxvtnlinekl6xhz6lyzznmm424@eveeuy5b26kv>

On 06.02.2025 18:09, qboosh wrote:
> commit 159dc91da656d9ea2b7bdfd78dc57616c7c0dac4
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Thu Feb 6 17:44:14 2025 +0100
> 
>     - disable autobahn tests explicitly (with new meson macros auto features default to enabled); release 2
> 

I do hate this --auto-features=enabled default already. projects usually
ship sane defaults with "auto" ie Mesa screams at me now why I want
android bindings to be built... or it's very easy to have debugging options
enabled. Is anyone against changing it back to auto?


From j.rekorajski at gmail.com  Thu Feb  6 20:13:04 2025
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Thu, 6 Feb 2025 20:13:04 +0100
Subject: [packages/libsoup3] - disable autobahn tests explicitly (with new
 meson macros auto features default to enabled); releas
In-Reply-To: <4awshyi7ewjoeowbog425elrgxvtnlinekl6xhz6lyzznmm424@eveeuy5b26kv>
References: <40877958cc73b20a54c4fa95612c680e210b66b4_refs_heads_master@pld-linux.org>
 <159dc91da656d9ea2b7bdfd78dc57616c7c0dac4_refs_heads_master@pld-linux.org>
 <4awshyi7ewjoeowbog425elrgxvtnlinekl6xhz6lyzznmm424@eveeuy5b26kv>
Message-ID: <CAKY5yHy2uRK=FsOpt2hDGZsFr5U7R513quw9+=pR+K+ga905cg@mail.gmail.com>

On Thu, 6 Feb 2025, 19:40 Jan Palus, <atler at pld-linux.org> wrote:

> On 06.02.2025 18:09, qboosh wrote:
> > commit 159dc91da656d9ea2b7bdfd78dc57616c7c0dac4
> > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > Date:   Thu Feb 6 17:44:14 2025 +0100
> >
> >     - disable autobahn tests explicitly (with new meson macros auto
> features default to enabled); release 2
> >
>
> I do hate this --auto-features=enabled default already. projects usually
> ship sane defaults with "auto" ie Mesa screams at me now why I want
> android bindings to be built... or it's very easy to have debugging options
> enabled. Is anyone against changing it back to auto?
>

Go ahead. If you find rpm defaults bad then feel free to change them.


From baggins at pld-linux.org  Fri Feb  7 12:56:42 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 7 Feb 2025 12:56:42 +0100
Subject: [packages/rpm-pld-macros] - big cleanup of the main macros -
 removed macros identical with upstream - added new hotness for bu
In-Reply-To: <20250206164234.GA18660@mail>
References: <278f6f17d501af3b28bf5df91c0780198700adfc_refs_heads_master@pld-linux.org>
 <0d35eeb25706bc93fd9419c3ab26567ce8e3c2ee_refs_heads_master@pld-linux.org>
 <20250205183912.GA843@mail> <20250206164234.GA18660@mail>
Message-ID: <Z6X0-teCL6amzw8h@tachikoma.lan>

On Thu, 06 Feb 2025, Jakub Bogusz wrote:

> On Wed, Feb 05, 2025 at 07:39:12PM +0100, Jakub Bogusz wrote:
> > On Wed, Feb 05, 2025 at 02:04:02AM +0100, baggins wrote:
> > >  
> > > -%configure {./configure \
> > > -	LDFLAGS="${LDFLAGS:-%rpmldflags}" \
> > > -	CFLAGS="${CFLAGS:-%rpmcflags}" \
> > > -	CXXFLAGS="${CXXFLAGS:-%rpmcxxflags}" \
> > > -	FFLAGS="${FFLAGS:-%rpmcflags}" \
> > > -	FCFLAGS="${FCFLAGS:-%rpmcflags}" \
> > > -	CPPFLAGS="${CPPFLAGS:-%rpmcppflags}" \
> > > -	%{?__cc:CC="%{__cc}"} \
> > > -	%{?__cxx:CXX="%{__cxx}"} \
> > > +%configure { \
> > > +  %{set_build_flags}; \
> > > +  ./configure \
> > >  	--host=%{_target_platform} \
> > >  	--build=%{_target_platform} \
> > >  	--prefix=%{_prefix} \
> > 
> > 
> > This change breaks invocation like:
> > 
> > bash %configure
> > 
> > if given configure is too bashish (now shebang change would be
> > required) - e.g. which.spec
> 
> And more cases:
> 
> 2)
> 
> VAR=val %configure
> 
> (now needs to be changed to export before %configure)
> 
> 3)
> 
> ../%configure ...
> 
> (see e.g. apache.spec)
> 
> This has no obvious replacement.
> In some cases maybe configure symlink would work, depending on source
> directory detection (relative to $0 or relative to $0 realpath)

I addressed shell and dir in 2.043 macros with configuredir and
configureshell macros. configure2_13 already had parametrized dir override, btw.

The requirement to export vars is actually good side effect, this was
inconsistent with all other macros and confusing.

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


From arekm at maven.pl  Fri Feb  7 14:48:36 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Fri, 7 Feb 2025 14:48:36 +0100
Subject: The way for building python 3 modules currently
Message-ID: <cd20555b-587e-4523-b5d0-9931b2dbd0a2@maven.pl>


What's "the way" for building python3 modules for rpm usage currently?

setup.py is obsolete and all our macros use setup.py



I've started using:

%build
%{__python3} -m build --wheel --no-isolation --outdir build-3

%install
%{__python3} -m installer --destdir=$RPM_BUILD_ROOT build-3/*.whl

and it seems to be working but fedora for example uses different way via 
pip like in build_wheel() at
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/pyproject_wheel.py

then %pyproject_install to install files 
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/macros.pyproject

and finally
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/pyproject_save_files.py
to generate list of rpm spec files for usage in %files -f XYZ

Example usage of their macros:
https://src.fedoraproject.org/rpms/python-installer/blob/rawhide/f/python-installer.spec


What way makes sense for us?


Looks like there are tons of tools and ways to build python packages now 
and above are just two examples :-/

Debian uses some pybuild tool:
https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/pybuild.rst

Archlinux uses -m build/installer:
https://wiki.archlinux.org/title/Python_package_guidelines

Others - no idea.

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



From arekm at maven.pl  Sat Feb  8 13:53:27 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Sat, 8 Feb 2025 13:53:27 +0100
Subject: The way for building python 3 modules currently
In-Reply-To: <cd20555b-587e-4523-b5d0-9931b2dbd0a2@maven.pl>
References: <cd20555b-587e-4523-b5d0-9931b2dbd0a2@maven.pl>
Message-ID: <4789d506-47b7-4d0c-82cd-90811240916e@maven.pl>

On 07/02/2025 14:48, Arkadiusz Mi?kiewicz wrote:
> 
> What's "the way" for building python3 modules for rpm usage currently?
> 
> setup.py is obsolete and all our macros use setup.py
> 
> 
> 
> I've started using:
> 
> %build
> %{__python3} -m build --wheel --no-isolation --outdir build-3
> 
> %install
> %{__python3} -m installer --destdir=$RPM_BUILD_ROOT build-3/*.whl

... so added macros for that:
%py3_build_pyproject and %py3_install_pyproject

https://git.pld-linux.org/gitweb.cgi?p=packages/rpm-pld-macros.git;a=commit;h=3c0f261530e6f869174a8d6dbb2bc35ecbbc97e5

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


From baggins at pld-linux.org  Sat Feb  8 23:39:00 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 8 Feb 2025 23:39:00 +0100
Subject: rpm 4.20, sequoia OpenPGP and old packages
Message-ID: <Z6fdBC_qUF75To9w@tachikoma.lan>

TL;DR Packages with non-conformant OpenPGP signatures must be
resinstalled with --nosignature.

rpm 4.20 dropped the venerable rpmpgp custom library in favor of
rpm-sequoia (https://sequoia-pgp.org/). The side effect is that
sequoia is much stricter in validating signatures and fail if the
format is non-conformat to the standard. What it means is that
packages built with rpm5 cannot be installed and ones already
installed will cause errors and must be reinstalled.

The former problem is fixed, I have re-signed all packages in main
PLD Th repo.

The later is more involved, because rpm will barf without telling
which package ails it.

The easiest way to check if your system is affeted is to run
`rpm -qa --nosignature --qf ''` (which should output nothing) and watch
if you see errors like those at the end of this message.
In case you do, just run the below command, which will update rpm db
for every bad package with the corrected one.

rpm -qa --nosignature --qf '%{name}\n' | while read p ; do
  rpm -V --nofiledigest --nofiles --nodigest $p 2>&1 | \
    grep -Eoq "non-conformant OpenPGP implementation|no certificate was provided" && poldek -q --reinstall --justdb --pmopt=--nosignature $p
done

Final words - while we could stick to rpmpgp_legacy library for now,
since it still can be used after going through some hoops, it will not
be pssible in the future, so let's deal with this now.

Sample errors:

-----------------
error: rpmdbNextIterator: skipping h#    1292
Header DSA signature: BAD (header tag 267: invalid OpenPGP signature: Parsing an OpenPGP packet:
  Failed to parse Signature Packet
        because: Signature appears to be created by a non-conformant OpenPGP implementation, see <https://github.com/rpm-software-management/rpm/issues/2351>.
              because: Malformed MPI: leading bit is not set: expected bit 8 to be set in   100011 (23))
              Header SHA1 digest: OK
-----------------
error: Verifying a signature, but no certificate was provided:
  Signature fcf4 created at Thu Aug 16 07:33:10 2018 invalid: signature is not alive
        because: Expired on 2018-09-15T07:33:10Z
error: rpmdbNextIterator: skipping h#     881
Header V4 DSA/SHA1 Signature, key ID 61ac3fd4: BAD
Header SHA1 digest: OK
-----------------

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


From ngompa13 at gmail.com  Sat Feb  8 23:49:25 2025
From: ngompa13 at gmail.com (Neal Gompa)
Date: Sat, 8 Feb 2025 17:49:25 -0500
Subject: rpm 4.20, sequoia OpenPGP and old packages
In-Reply-To: <Z6fdBC_qUF75To9w@tachikoma.lan>
References: <Z6fdBC_qUF75To9w@tachikoma.lan>
Message-ID: <CAEg-Je8ETjBWGH_QRFCHpFY2=4-0BCPZimhZg-8rrWh7Ht=Kpw@mail.gmail.com>

On Sat, Feb 8, 2025 at 5:39?PM Jan R?korajski <baggins at pld-linux.org> wrote:
>
> TL;DR Packages with non-conformant OpenPGP signatures must be
> resinstalled with --nosignature.
>
> rpm 4.20 dropped the venerable rpmpgp custom library in favor of
> rpm-sequoia (https://sequoia-pgp.org/). The side effect is that
> sequoia is much stricter in validating signatures and fail if the
> format is non-conformat to the standard. What it means is that
> packages built with rpm5 cannot be installed and ones already
> installed will cause errors and must be reinstalled.
>

FWIW, the rpmpgp custom library still exists and is somewhat
maintained: https://github.com/rpm-software-management/rpmpgp_legacy

> The former problem is fixed, I have re-signed all packages in main
> PLD Th repo.
>
> The later is more involved, because rpm will barf without telling
> which package ails it.
>
> The easiest way to check if your system is affeted is to run
> `rpm -qa --nosignature --qf ''` (which should output nothing) and watch
> if you see errors like those at the end of this message.
> In case you do, just run the below command, which will update rpm db
> for every bad package with the corrected one.
>
> rpm -qa --nosignature --qf '%{name}\n' | while read p ; do
>   rpm -V --nofiledigest --nofiles --nodigest $p 2>&1 | \
>     grep -Eoq "non-conformant OpenPGP implementation|no certificate was provided" && poldek -q --reinstall --justdb --pmopt=--nosignature $p
> done
>
> Final words - while we could stick to rpmpgp_legacy library for now,
> since it still can be used after going through some hoops, it will not
> be pssible in the future, so let's deal with this now.
>

My understanding is that SUSE currently isn't interested in
rpm-sequoia, so it'll be around for a while yet. But in general, your
advice is correct from an rpm upstream perspective. Not to mention
that the DNF stack will depend on it too (for those who want to use it).




--
?????????/ Always, there's only one truth!


From atler at pld-linux.org  Sun Feb  9 13:04:37 2025
From: atler at pld-linux.org (Jan Palus)
Date: Sun, 9 Feb 2025 13:04:37 +0100
Subject: [packages/rpm] - started update to 4.20.0, x32 needs update for
 cmake
In-Reply-To: <56f242e3a926c2e4d64b7a83a5adf3d277d814b7_refs_heads_master@pld-linux.org>
References: <fd15f5ab3b9aaca6046c5d110cb968d9157fcaea_refs_heads_master@pld-linux.org>
 <56f242e3a926c2e4d64b7a83a5adf3d277d814b7_refs_heads_master@pld-linux.org>
Message-ID: <wiwzksx5digjpd7qxfodokd4f7uj3yc7hga3l5xjqa7uc2udvx@tgbzsv65xwvm>

On 25.11.2024 04:04, baggins wrote:
> commit 56f242e3a926c2e4d64b7a83a5adf3d277d814b7
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Mon Nov 25 02:19:43 2024 +0100
> 
>     - started update to 4.20.0, x32 needs update for cmake

...

> -# rpm checks for CPU type at runtime, but it looks better
> -%{__sed} -i \
> -	-e 's|@host@|%{_target_cpu}-%{_target_vendor}-%{_target_os}|' \
> -	-e 's|@host_cpu@|%{_target_cpu}|' \
> -	-e 's|@host_os@|%{_target_os}|' \
> -	macros.in

At least rust.spec relies on this sed expecting %{_host_cpu} == x32


From baggins at pld-linux.org  Sun Feb  9 14:10:24 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 9 Feb 2025 14:10:24 +0100
Subject: [packages/rpm] - started update to 4.20.0, x32 needs update for
 cmake
In-Reply-To: <wiwzksx5digjpd7qxfodokd4f7uj3yc7hga3l5xjqa7uc2udvx@tgbzsv65xwvm>
References: <fd15f5ab3b9aaca6046c5d110cb968d9157fcaea_refs_heads_master@pld-linux.org>
 <56f242e3a926c2e4d64b7a83a5adf3d277d814b7_refs_heads_master@pld-linux.org>
 <wiwzksx5digjpd7qxfodokd4f7uj3yc7hga3l5xjqa7uc2udvx@tgbzsv65xwvm>
Message-ID: <Z6ipQCBKPIsMRFhF@tachikoma.lan>

On Sun, 09 Feb 2025, Jan Palus wrote:

> On 25.11.2024 04:04, baggins wrote:
> > commit 56f242e3a926c2e4d64b7a83a5adf3d277d814b7
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Mon Nov 25 02:19:43 2024 +0100
> > 
> >     - started update to 4.20.0, x32 needs update for cmake
> 
> ...
> 
> > -# rpm checks for CPU type at runtime, but it looks better
> > -%{__sed} -i \
> > -	-e 's|@host@|%{_target_cpu}-%{_target_vendor}-%{_target_os}|' \
> > -	-e 's|@host_cpu@|%{_target_cpu}|' \
> > -	-e 's|@host_os@|%{_target_os}|' \
> > -	macros.in
> 
> At least rust.spec relies on this sed expecting %{_host_cpu} == x32

Bad luck, it was hidden inbetween configure invocations :/

Restored this and moved to prep so it won't get accidentally lost again.

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


From baggins at pld-linux.org  Tue Feb 11 23:49:59 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 11 Feb 2025 23:49:59 +0100
Subject: ERRORS: mozilla-firefox-bin.spec
In-Reply-To: <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
References: <82b13d2f-38a3-4e87-a661-42b40374236d@pld.src.builder>
 <pld-builder.1738844534.722428.40087@naiad>
 <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
Message-ID: <Z6vUF1gDqKwYHrjJ@tachikoma.lan>

On Thu, 06 Feb 2025, Jan Palus wrote:

> On 06.02.2025 12:22, PLD th-x32 builder wrote:
> > mozilla-firefox-bin.spec (HEAD): FAILED
> ...
> > + exec nice -n 0 rpmbuild -bp --short-circuit --nodeps --define '_topdir /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define '_sourcedir %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define '_builddir %{_topdir}/BUILD' --target x32-pld-linux --define 'prep exit 0' /tmp/B.bco753jf/mozilla-firefox-bin.spec
> > Building target platforms: x32-pld-linux
> > Building for target x32-pld-linux
> > warning: line 40: It's not recommended to have unversioned Obsoletes: Obsoletes:	mozilla-firebird
> ...
> > + exec nice -n 0 rpmbuild -bb --define '__jobs 28' --define '_smp_mflags -j28' --define '_make_opts -Otarget' --define '_pld_builder 1' --define '_topdir /tmp/B.bco753jf' --define '_specdir %{_topdir}' --define '_sourcedir %{_specdir}' --define '_rpmdir %{_topdir}/RPMS' --define '_builddir %{_topdir}/BUILD' --target x32-pld-linux /tmp/B.bco753jf/mozilla-firefox-bin.spec
> > Building target platforms: x32-pld-linux
> > Building for target x32-pld-linux
> > warning: line 40: It's not recommended to have unversioned Obsoletes: Obsoletes:	mozilla-firebird
> > error: Signature expired on 2015-03-28 06:35:09
> > Executing(%mkbuilddir): /bin/sh -e /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.Bou2cg
> > + umask 022
> > + cd /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + test -d /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/chmod -Rf a+rX,u+w,g-w,o-w /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/rm '--interactive=never' -rf /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/mkdir -p /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build
> > + /bin/mkdir -p /tmp/B.bco753jf/BUILD/mozilla-firefox-bin-135.0-build/SPECPARTS
> > + RPM_EC=0 
> > + jobs -p
> > + exit 0
> > Executing(%prep): /bin/sh -e /tmp/B.bco753jf/BUILD/tmp/rpm-tmp.X7RJbH
> 
> ExclusiveArch is no longer a thing in new rpm? Or why it didn't
> error out here (spec has ExclusiveArch: i686 athlon %{x8664})?

rpm 4.18:

$ rpmbuild -bp --short-circuit --nodeps --target x32-pld-linux --define 'prep exit 0'  nodejs.spec ; echo $?
Building target platforms: x32-pld-linux
Building for target x32-pld-linux
error: Architecture is not included: x32
1

vs rpm 4.20:

$ rpmbuild -bp --short-circuit --nodeps --target x32-pld-linux --define 'prep exit 0'  nodejs.spec ; echo $?
Building target platforms: x32-pld-linux
Building for target x32-pld-linux
0

That's how builder finds out if an arch is supported or not.

I'll look around if there is a better way or if that's an rpm bug.

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


From atler at pld-linux.org  Wed Feb 12 01:07:24 2025
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 12 Feb 2025 01:07:24 +0100
Subject: ERRORS: mozilla-firefox-bin.spec
In-Reply-To: <Z6vUF1gDqKwYHrjJ@tachikoma.lan>
References: <82b13d2f-38a3-4e87-a661-42b40374236d@pld.src.builder>
 <pld-builder.1738844534.722428.40087@naiad>
 <6qys37yrizitteyljg5utimgjaip66ge2zttxiarwr4uuxcbsn@aqzy2vl7vrmn>
 <Z6vUF1gDqKwYHrjJ@tachikoma.lan>
Message-ID: <5325k3uz3opsnfis5pushdlw52uc5lmusdmenlwy2zp5lbdwjw@525etnmt7p5c>

On 11.02.2025 23:49, Jan R?korajski wrote:
> rpm 4.18:
> 
> $ rpmbuild -bp --short-circuit --nodeps --target x32-pld-linux --define 'prep exit 0'  nodejs.spec ; echo $?
> Building target platforms: x32-pld-linux
> Building for target x32-pld-linux
> error: Architecture is not included: x32
> 1
> 
> vs rpm 4.20:
> 
> $ rpmbuild -bp --short-circuit --nodeps --target x32-pld-linux --define 'prep exit 0'  nodejs.spec ; echo $?
> Building target platforms: x32-pld-linux
> Building for target x32-pld-linux
> 0
> 
> That's how builder finds out if an arch is supported or not.
> 
> I'll look around if there is a better way or if that's an rpm bug.

This is absurd. Following commit:

https://github.com/rpm-software-management/rpm/commit/fd32a43e04814bd1f298977306ac1bcdc6c790d2

makes checkForValidArchitectures() part of finalizeSpec() which is only
called _after successful %install_. Makes no sense to me but who am I?

Sample:

$ rpm -E '%{_target_cpu}'                
aarch64

$ grep ExclusiveArch test.spec
ExclusiveArch:	%{x8664}

$ rpmbuild -bi test.spec; echo $?
Executing(%mkbuilddir): /bin/sh -e /home/users/builder/tmp/rpm-tmp.DlT3Ts
...
Executing(%prep): /bin/sh -e /home/users/builder/tmp/rpm-tmp.3IlqaP
...
Executing(%install): /bin/sh -e /home/users/builder/tmp/rpm-tmp.aAv0BZ
...
error: Architecture is not included: aarch64
error: parsing failed

RPM build errors:
    Architecture is not included: aarch64
    parsing failed
1




$ rpmbuild -bc test.spec; echo $?
Executing(%mkbuilddir): /bin/sh -e /home/users/builder/tmp/rpm-tmp.9xVo5N
...
Executing(%prep): /bin/sh -e /home/users/builder/tmp/rpm-tmp.MdXTKx
...
0


From atler at pld-linux.org  Wed Feb 12 12:23:01 2025
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 12 Feb 2025 12:23:01 +0100
Subject: rpm 4.20, sequoia OpenPGP and old packages
In-Reply-To: <Z6fdBC_qUF75To9w@tachikoma.lan>
References: <Z6fdBC_qUF75To9w@tachikoma.lan>
Message-ID: <5bjf3mqy2kbuyygop2sfqrxk6sajptvp2ley5ewhmzrmxpcnc2@sr6x75ws44jr>

On 08.02.2025 23:39, Jan R?korajski wrote:
> TL;DR Packages with non-conformant OpenPGP signatures must be
> resinstalled with --nosignature.
> 
> rpm 4.20 dropped the venerable rpmpgp custom library in favor of
> rpm-sequoia (https://sequoia-pgp.org/). The side effect is that
> sequoia is much stricter in validating signatures and fail if the
> format is non-conformat to the standard. What it means is that
> packages built with rpm5 cannot be installed and ones already
> installed will cause errors and must be reinstalled.
> 
> The former problem is fixed, I have re-signed all packages in main
> PLD Th repo.
> 
> The later is more involved, because rpm will barf without telling
> which package ails it.
> 
> The easiest way to check if your system is affeted is to run
> `rpm -qa --nosignature --qf ''` (which should output nothing) and watch
> if you see errors like those at the end of this message.
> In case you do, just run the below command, which will update rpm db
> for every bad package with the corrected one.
> 
> rpm -qa --nosignature --qf '%{name}\n' | while read p ; do
>   rpm -V --nofiledigest --nofiles --nodigest $p 2>&1 | \
>     grep -Eoq "non-conformant OpenPGP implementation|no certificate was provided" && poldek -q --reinstall --justdb --pmopt=--nosignature $p
> done

I finally found courage to upgrade to rpm 4.20 on one of my systems and
my oh my rpm upgrades got the most disruptive of all packages hands
down.

Anyway regarding above command it has some issues and I advise to use it
with care as in current shape it might be dangerous and possibly result
in broken system although that would manifest only in future.

The most problematic part is "--justdb" option. If user did a full:
`poldek --upgrade-dist` immediately followed by above command it likely
wouldn't have negative impact. But if user has older version of
reinstalled package the rpmdb will claim to have newer one while files
would not reflect it. That could pose a problem in future
installs/upgrades in which rpm would consider dependencies are satisfied
even though they're not in practice. I would advise to drop "--justdb".

The other problem is set of packages to be reinstalled is way too
excessive. I didn't check it in detail but about all packages qualified
for reinstallation. It's due to criteria considering any package having
error in rpm -V even though the error does not really consider given
package. Taking example from pld-devel-pl:

error: Failed dependencies:
        /usr/bin/pkg-config is needed by SDL2-devel-2.32.0-1.x86_64
There were errors

Likely `rpm -V SDL2-devel` produces signature error on this system (like
it did for me when doing `rpm -V rpm-sequoia-devel`) but in practice only
pkgconfig needed a reinstall.

As advised in github ticket mentioned in error message the criteria
should be on number following "h#" in:

error: rpmdbNextIterator: skipping h#    1292

package to be reinstalled determined by
`rpm -q --qf='%{name}\n' --querybynumber 1292`

All in all I had better experience with following command:

LC_ALL=C rpm -Va --nofiledigest --nofiles --nodigest 2>&1 | grep 'error: rpmdbNextIterator: skipping h#' | \
awk '{print $5}' | sort -u | xargs -r rpm -q --qf='%{name}\n' --nosignature --querybynumber | \
grep -vE 'package1buitmanuallyduetolicense|package2buitmanuallyduetolicense' | \
xargs -r poldek --reinstall --pmopt=--nosignature

packages built manually due to redistribution restrictions need to be
listed in third line and rebuilt/reinstalled.

I still fear how all this gonna look like on multilib system though...

> 
> Final words - while we could stick to rpmpgp_legacy library for now,
> since it still can be used after going through some hoops, it will not
> be pssible in the future, so let's deal with this now.
> 
> Sample errors:
> 
> -----------------
> error: rpmdbNextIterator: skipping h#    1292
> Header DSA signature: BAD (header tag 267: invalid OpenPGP signature: Parsing an OpenPGP packet:
>   Failed to parse Signature Packet
>         because: Signature appears to be created by a non-conformant OpenPGP implementation, see <https://github.com/rpm-software-management/rpm/issues/2351>.
>               because: Malformed MPI: leading bit is not set: expected bit 8 to be set in   100011 (23))
>               Header SHA1 digest: OK
> -----------------
> error: Verifying a signature, but no certificate was provided:
>   Signature fcf4 created at Thu Aug 16 07:33:10 2018 invalid: signature is not alive
>         because: Expired on 2018-09-15T07:33:10Z
> error: rpmdbNextIterator: skipping h#     881
> Header V4 DSA/SHA1 Signature, key ID 61ac3fd4: BAD
> Header SHA1 digest: OK
> -----------------
> 
> -- 
> Jan R?korajski                    | PLD/Linux
> SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


From arekm at maven.pl  Wed Feb 12 18:29:53 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Wed, 12 Feb 2025 18:29:53 +0100
Subject: rpm 4.20, sequoia OpenPGP and old packages
In-Reply-To: <5bjf3mqy2kbuyygop2sfqrxk6sajptvp2ley5ewhmzrmxpcnc2@sr6x75ws44jr>
References: <Z6fdBC_qUF75To9w@tachikoma.lan>
 <5bjf3mqy2kbuyygop2sfqrxk6sajptvp2ley5ewhmzrmxpcnc2@sr6x75ws44jr>
Message-ID: <4fae1947-ffa7-45c2-a4f6-d60773223d8f@maven.pl>

On 12/02/2025 12:23, Jan Palus wrote:

> I finally found courage to upgrade to rpm 4.20 on one of my systems and
> my oh my rpm upgrades got the most disruptive of all packages hands
> down.

There has to be some other route like removing bad signatures from local 
rpm db. Unsigned installed packages shouldn't be a problem, right?

But looks like this is not that simple since rpm sqlite db contains some 
binary blobs and not "sane" db structure.

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


From baggins at pld-linux.org  Wed Feb 12 19:58:52 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 12 Feb 2025 19:58:52 +0100
Subject: rpm 4.20, sequoia OpenPGP and old packages
In-Reply-To: <5bjf3mqy2kbuyygop2sfqrxk6sajptvp2ley5ewhmzrmxpcnc2@sr6x75ws44jr>
References: <Z6fdBC_qUF75To9w@tachikoma.lan>
 <5bjf3mqy2kbuyygop2sfqrxk6sajptvp2ley5ewhmzrmxpcnc2@sr6x75ws44jr>
Message-ID: <Z6zvbG2tGd42WuNO@starbug.lan>

On Wed, 12 Feb 2025, Jan Palus wrote:

> On 08.02.2025 23:39, Jan R?korajski wrote:
> > TL;DR Packages with non-conformant OpenPGP signatures must be
> > resinstalled with --nosignature.
> > 
> > rpm 4.20 dropped the venerable rpmpgp custom library in favor of
> > rpm-sequoia (https://sequoia-pgp.org/). The side effect is that
> > sequoia is much stricter in validating signatures and fail if the
> > format is non-conformat to the standard. What it means is that
> > packages built with rpm5 cannot be installed and ones already
> > installed will cause errors and must be reinstalled.
> > 
> > The former problem is fixed, I have re-signed all packages in main
> > PLD Th repo.
> > 
> > The later is more involved, because rpm will barf without telling
> > which package ails it.
> > 
> > The easiest way to check if your system is affeted is to run
> > `rpm -qa --nosignature --qf ''` (which should output nothing) and watch
> > if you see errors like those at the end of this message.
> > In case you do, just run the below command, which will update rpm db
> > for every bad package with the corrected one.
> > 
> > rpm -qa --nosignature --qf '%{name}\n' | while read p ; do
> >   rpm -V --nofiledigest --nofiles --nodigest $p 2>&1 | \
> >     grep -Eoq "non-conformant OpenPGP implementation|no certificate was provided" && poldek -q --reinstall --justdb --pmopt=--nosignature $p
> > done
> 
> I finally found courage to upgrade to rpm 4.20 on one of my systems and
> my oh my rpm upgrades got the most disruptive of all packages hands
> down.
> 
> Anyway regarding above command it has some issues and I advise to use it
> with care as in current shape it might be dangerous and possibly result
> in broken system although that would manifest only in future.
> 
> The most problematic part is "--justdb" option. If user did a full:
> `poldek --upgrade-dist` immediately followed by above command it likely
> wouldn't have negative impact. But if user has older version of
> reinstalled package the rpmdb will claim to have newer one while files
> would not reflect it. That could pose a problem in future
> installs/upgrades in which rpm would consider dependencies are satisfied
> even though they're not in practice. I would advise to drop "--justdb".
> 
> The other problem is set of packages to be reinstalled is way too
> excessive. I didn't check it in detail but about all packages qualified
> for reinstallation. It's due to criteria considering any package having
> error in rpm -V even though the error does not really consider given
> package. Taking example from pld-devel-pl:
> 
> error: Failed dependencies:
>         /usr/bin/pkg-config is needed by SDL2-devel-2.32.0-1.x86_64
> There were errors
> 
> Likely `rpm -V SDL2-devel` produces signature error on this system (like
> it did for me when doing `rpm -V rpm-sequoia-devel`) but in practice only
> pkgconfig needed a reinstall.
> 
> As advised in github ticket mentioned in error message the criteria
> should be on number following "h#" in:
> 
> error: rpmdbNextIterator: skipping h#    1292
> 
> package to be reinstalled determined by
> `rpm -q --qf='%{name}\n' --querybynumber 1292`
> 
> All in all I had better experience with following command:
> 
> LC_ALL=C rpm -Va --nofiledigest --nofiles --nodigest 2>&1 | grep 'error: rpmdbNextIterator: skipping h#' | \
> awk '{print $5}' | sort -u | xargs -r rpm -q --qf='%{name}\n' --nosignature --querybynumber | \
> grep -vE 'package1buitmanuallyduetolicense|package2buitmanuallyduetolicense' | \
> xargs -r poldek --reinstall --pmopt=--nosignature
> 
> packages built manually due to redistribution restrictions need to be
> listed in third line and rebuilt/reinstalled.

Thanks, updated wiki with your command.

> I still fear how all this gonna look like on multilib system though...

Looked fine to me, the thing is only very old packages have the problem.

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


From baggins at pld-linux.org  Wed Feb 12 20:03:37 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 12 Feb 2025 20:03:37 +0100
Subject: rpm 4.20, sequoia OpenPGP and old packages
In-Reply-To: <Z6zvbG2tGd42WuNO@starbug.lan>
References: <Z6fdBC_qUF75To9w@tachikoma.lan>
 <5bjf3mqy2kbuyygop2sfqrxk6sajptvp2ley5ewhmzrmxpcnc2@sr6x75ws44jr>
 <Z6zvbG2tGd42WuNO@starbug.lan>
Message-ID: <Z6zwiVm60k8OX8LY@starbug.lan>

On Wed, 12 Feb 2025, Jan R?korajski wrote:

> On Wed, 12 Feb 2025, Jan Palus wrote:
> 
> > On 08.02.2025 23:39, Jan R?korajski wrote:
> > > TL;DR Packages with non-conformant OpenPGP signatures must be
> > > resinstalled with --nosignature.
> > > 
> > > rpm 4.20 dropped the venerable rpmpgp custom library in favor of
> > > rpm-sequoia (https://sequoia-pgp.org/). The side effect is that
> > > sequoia is much stricter in validating signatures and fail if the
> > > format is non-conformat to the standard. What it means is that
> > > packages built with rpm5 cannot be installed and ones already
> > > installed will cause errors and must be reinstalled.
> > > 
> > > The former problem is fixed, I have re-signed all packages in main
> > > PLD Th repo.
> > > 
> > > The later is more involved, because rpm will barf without telling
> > > which package ails it.
> > > 
> > > The easiest way to check if your system is affeted is to run
> > > `rpm -qa --nosignature --qf ''` (which should output nothing) and watch
> > > if you see errors like those at the end of this message.
> > > In case you do, just run the below command, which will update rpm db
> > > for every bad package with the corrected one.
> > > 
> > > rpm -qa --nosignature --qf '%{name}\n' | while read p ; do
> > >   rpm -V --nofiledigest --nofiles --nodigest $p 2>&1 | \
> > >     grep -Eoq "non-conformant OpenPGP implementation|no certificate was provided" && poldek -q --reinstall --justdb --pmopt=--nosignature $p
> > > done
> > 
> > I finally found courage to upgrade to rpm 4.20 on one of my systems and
> > my oh my rpm upgrades got the most disruptive of all packages hands
> > down.
> > 
> > Anyway regarding above command it has some issues and I advise to use it
> > with care as in current shape it might be dangerous and possibly result
> > in broken system although that would manifest only in future.
> > 
> > The most problematic part is "--justdb" option. If user did a full:
> > `poldek --upgrade-dist` immediately followed by above command it likely
> > wouldn't have negative impact. But if user has older version of
> > reinstalled package the rpmdb will claim to have newer one while files
> > would not reflect it. That could pose a problem in future
> > installs/upgrades in which rpm would consider dependencies are satisfied
> > even though they're not in practice. I would advise to drop "--justdb".
> > 
> > The other problem is set of packages to be reinstalled is way too
> > excessive. I didn't check it in detail but about all packages qualified
> > for reinstallation. It's due to criteria considering any package having
> > error in rpm -V even though the error does not really consider given
> > package. Taking example from pld-devel-pl:
> > 
> > error: Failed dependencies:
> >         /usr/bin/pkg-config is needed by SDL2-devel-2.32.0-1.x86_64
> > There were errors
> > 
> > Likely `rpm -V SDL2-devel` produces signature error on this system (like
> > it did for me when doing `rpm -V rpm-sequoia-devel`) but in practice only
> > pkgconfig needed a reinstall.
> > 
> > As advised in github ticket mentioned in error message the criteria
> > should be on number following "h#" in:
> > 
> > error: rpmdbNextIterator: skipping h#    1292
> > 
> > package to be reinstalled determined by
> > `rpm -q --qf='%{name}\n' --querybynumber 1292`
> > 
> > All in all I had better experience with following command:
> > 
> > LC_ALL=C rpm -Va --nofiledigest --nofiles --nodigest 2>&1 | grep 'error: rpmdbNextIterator: skipping h#' | \
> > awk '{print $5}' | sort -u | xargs -r rpm -q --qf='%{name}\n' --nosignature --querybynumber | \
> > grep -vE 'package1buitmanuallyduetolicense|package2buitmanuallyduetolicense' | \
> > xargs -r poldek --reinstall --pmopt=--nosignature
> > 
> > packages built manually due to redistribution restrictions need to be
> > listed in third line and rebuilt/reinstalled.
> 
> Thanks, updated wiki with your command.
> 
> > I still fear how all this gonna look like on multilib system though...
> 
> Looked fine to me, the thing is only very old packages have the problem.

Just in case changing query format to '%{name}-%{version}-%{release}.%{arch}\n'
should do the trick.

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


From baggins at pld-linux.org  Fri Feb 21 23:55:44 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 21 Feb 2025 23:55:44 +0100
Subject: [packages/wlroots0.18] rename to wlroots0.18
In-Reply-To: <b58dea8d2398b217f33147fa9388e91fc580530c_refs_heads_master@pld-linux.org>
References: <43cab366c0a666cde81074e4f3095a49cfc57dfc_refs_heads_master@pld-linux.org>
 <b58dea8d2398b217f33147fa9388e91fc580530c_refs_heads_master@pld-linux.org>
Message-ID: <Z7kEcCDZoJBXj4ha@tachikoma.lan>

On Thu, 20 Feb 2025, atler wrote:

> commit b58dea8d2398b217f33147fa9388e91fc580530c
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Thu Feb 20 13:21:46 2025 +0100
> 
>     rename to wlroots0.18
> 
>  wlroots.spec => wlroots0.18.spec | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> ---
> diff --git a/wlroots.spec b/wlroots0.18.spec
> similarity index 99%
> rename from wlroots.spec
> rename to wlroots0.18.spec
> index 611d68d..40a38f2 100644
> --- a/wlroots.spec
> +++ b/wlroots0.18.spec

But why? There is absolutly no need for this prolifertion.
Especially for one, single, package.

Just because wayfire spec says < 18, does not mean we have to
create an incarnation of wlroots for it. Just use

https://github.com/WayfireWM/wayfire/commit/0f9d50d16e56f4527a5cc8d47e0ef7e2b29e1508

Please delete that package and update wlroots to latest version.

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


From atler at pld-linux.org  Sat Feb 22 00:15:56 2025
From: atler at pld-linux.org (Jan Palus)
Date: Sat, 22 Feb 2025 00:15:56 +0100
Subject: [packages/wlroots0.18] rename to wlroots0.18
In-Reply-To: <Z7kEcCDZoJBXj4ha@tachikoma.lan>
References: <43cab366c0a666cde81074e4f3095a49cfc57dfc_refs_heads_master@pld-linux.org>
 <b58dea8d2398b217f33147fa9388e91fc580530c_refs_heads_master@pld-linux.org>
 <Z7kEcCDZoJBXj4ha@tachikoma.lan>
Message-ID: <lhkdwxi5owdvida4cccxkpzjkskcz734fsipzylw5f6uh52wtp@w2k3d3lnsz2z>

On 21.02.2025 23:55, Jan R?korajski wrote:
> On Thu, 20 Feb 2025, atler wrote:
> 
> > commit b58dea8d2398b217f33147fa9388e91fc580530c
> > Author: Jan Palus <atler at pld-linux.org>
> > Date:   Thu Feb 20 13:21:46 2025 +0100
> > 
> >     rename to wlroots0.18
> > 
> >  wlroots.spec => wlroots0.18.spec | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > ---
> > diff --git a/wlroots.spec b/wlroots0.18.spec
> > similarity index 99%
> > rename from wlroots.spec
> > rename to wlroots0.18.spec
> > index 611d68d..40a38f2 100644
> > --- a/wlroots.spec
> > +++ b/wlroots0.18.spec
> 
> But why? There is absolutly no need for this prolifertion.
> Especially for one, single, package.

Because wlroots is known for introducing heavy changes with each and
every release and downstreams are known to seriously lag behind those
changes. cage in particular. wlroots maintainers recognized the problem
and renamed files to include major and minor version (libwlroots.so ->
libwlroots-0.18.so, wlroots.pc -> wlroots-0.18.pc, /usr/include/wlroots
-> /usr/include/wlroots-0.18) so different versions can be installed in
parallel without conflicts.

> Just because wayfire spec says < 18, does not mean we have to
> create an incarnation of wlroots for it. Just use
> 
> https://github.com/WayfireWM/wayfire/commit/0f9d50d16e56f4527a5cc8d47e0ef7e2b29e1508
> 
> Please delete that package and update wlroots to latest version.

Will do that tomorrow but I reserve my right to upgrade wlroots to ie
0.19 once it's released regardless of downstream status at the time.
Would cause no harm with separate specs but will result in broken deps
otherwise.


From baggins at pld-linux.org  Sat Feb 22 00:54:37 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 22 Feb 2025 00:54:37 +0100
Subject: [packages/wlroots0.18] rename to wlroots0.18
In-Reply-To: <lhkdwxi5owdvida4cccxkpzjkskcz734fsipzylw5f6uh52wtp@w2k3d3lnsz2z>
References: <43cab366c0a666cde81074e4f3095a49cfc57dfc_refs_heads_master@pld-linux.org>
 <b58dea8d2398b217f33147fa9388e91fc580530c_refs_heads_master@pld-linux.org>
 <Z7kEcCDZoJBXj4ha@tachikoma.lan>
 <lhkdwxi5owdvida4cccxkpzjkskcz734fsipzylw5f6uh52wtp@w2k3d3lnsz2z>
Message-ID: <Z7kSPRqwnkOD2YCL@tachikoma.lan>

On Sat, 22 Feb 2025, Jan Palus wrote:

> On 21.02.2025 23:55, Jan R?korajski wrote:
> > On Thu, 20 Feb 2025, atler wrote:
> > 
> > > commit b58dea8d2398b217f33147fa9388e91fc580530c
> > > Author: Jan Palus <atler at pld-linux.org>
> > > Date:   Thu Feb 20 13:21:46 2025 +0100
> > > 
> > >     rename to wlroots0.18
> > > 
> > >  wlroots.spec => wlroots0.18.spec | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > ---
> > > diff --git a/wlroots.spec b/wlroots0.18.spec
> > > similarity index 99%
> > > rename from wlroots.spec
> > > rename to wlroots0.18.spec
> > > index 611d68d..40a38f2 100644
> > > --- a/wlroots.spec
> > > +++ b/wlroots0.18.spec
> > 
> > But why? There is absolutly no need for this prolifertion.
> > Especially for one, single, package.
> 
> Because wlroots is known for introducing heavy changes with each and
> every release and downstreams are known to seriously lag behind those
> changes. cage in particular. wlroots maintainers recognized the problem
> and renamed files to include major and minor version (libwlroots.so ->
> libwlroots-0.18.so, wlroots.pc -> wlroots-0.18.pc, /usr/include/wlroots
> -> /usr/include/wlroots-0.18) so different versions can be installed in
> parallel without conflicts.

This makes more sense now. I still don't like it.
But, in this case I'll leave the choice up to you - either keep the
versioned package(s) and drop the unversioned one, or stick to one
unversioned package and update it once downstreams are ready.
There are just 3 packages depending on it, is it worth to keep a
different version of the library for each one and evetually have
orphaned, unused library in system and distro?

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


From atler at pld-linux.org  Sat Feb 22 15:35:44 2025
From: atler at pld-linux.org (Jan Palus)
Date: Sat, 22 Feb 2025 15:35:44 +0100
Subject: [packages/wlroots0.18] rename to wlroots0.18
In-Reply-To: <Z7kSPRqwnkOD2YCL@tachikoma.lan>
References: <43cab366c0a666cde81074e4f3095a49cfc57dfc_refs_heads_master@pld-linux.org>
 <b58dea8d2398b217f33147fa9388e91fc580530c_refs_heads_master@pld-linux.org>
 <Z7kEcCDZoJBXj4ha@tachikoma.lan>
 <lhkdwxi5owdvida4cccxkpzjkskcz734fsipzylw5f6uh52wtp@w2k3d3lnsz2z>
 <Z7kSPRqwnkOD2YCL@tachikoma.lan>
Message-ID: <iodn6o7cn3nf7ftfyyyqwu6hjxhe5jxbcz6xe4i3ap5dvsaycx@s7hvbqbjbksd>

On 22.02.2025 00:54, Jan R?korajski wrote:
> On Sat, 22 Feb 2025, Jan Palus wrote:
> 
> > On 21.02.2025 23:55, Jan R?korajski wrote:
> > > On Thu, 20 Feb 2025, atler wrote:
> > > 
> > > > commit b58dea8d2398b217f33147fa9388e91fc580530c
> > > > Author: Jan Palus <atler at pld-linux.org>
> > > > Date:   Thu Feb 20 13:21:46 2025 +0100
> > > > 
> > > >     rename to wlroots0.18
> > > > 
> > > >  wlroots.spec => wlroots0.18.spec | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > ---
> > > > diff --git a/wlroots.spec b/wlroots0.18.spec
> > > > similarity index 99%
> > > > rename from wlroots.spec
> > > > rename to wlroots0.18.spec
> > > > index 611d68d..40a38f2 100644
> > > > --- a/wlroots.spec
> > > > +++ b/wlroots0.18.spec
> > > 
> > > But why? There is absolutly no need for this prolifertion.
> > > Especially for one, single, package.
> > 
> > Because wlroots is known for introducing heavy changes with each and
> > every release and downstreams are known to seriously lag behind those
> > changes. cage in particular. wlroots maintainers recognized the problem
> > and renamed files to include major and minor version (libwlroots.so ->
> > libwlroots-0.18.so, wlroots.pc -> wlroots-0.18.pc, /usr/include/wlroots
> > -> /usr/include/wlroots-0.18) so different versions can be installed in
> > parallel without conflicts.
> 
> This makes more sense now. I still don't like it.
> But, in this case I'll leave the choice up to you - either keep the
> versioned package(s) and drop the unversioned one, or stick to one
> unversioned package and update it once downstreams are ready.
> There are just 3 packages depending on it, is it worth to keep a
> different version of the library for each one and evetually have
> orphaned, unused library in system and distro?

As a matter of fact I wanted to do upgrade in wlroots.spec just as you
suggested. I had the changes ready since sway 1.10 was released (late
October) and waited patiently until other compositors catch up. 7 months
after wlroots 0.18.0 was published wayfire still does not have a version
with wlroots 0.18.x support and I'm not really big fan of pulling ~1500L
patch that may work or may not. Situation is still not as dramatic (yet)
as with cage in wlroots 0.16/0.17 days which lacked release for 2 years.

While I'd prefer to have single spec too, I don't think holding back
other compositors which would benefit from new wlroots features is a
good choice only because one of them is slow to adapt. Hence the
decision to follow upstream direction with versioned library, which I
very much welcome, and reflect new naming in our packages too.

What I can offer from my side is to send an email with package removal
request for wlroots versions not being dependency of any other package
as I don't really care for them.

And while currently we have only 3 compositors packaged, this my change
with time making various wlroots versions availability more relevant.
Current list of projects using wlroots is a bit longer:

https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Projects-which-use-wlroots


From atler at pld-linux.org  Fri Feb 28 00:06:28 2025
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 28 Feb 2025 00:06:28 +0100
Subject: [packages/poldek] up to 0.44.0
In-Reply-To: <534b4046a44492fba55adafc0042fdeea2a51302_refs_heads_master@pld-linux.org>
References: <225c634408b0aae7b34c2c743230b3f7c2d3dada_refs_heads_master@pld-linux.org>
 <534b4046a44492fba55adafc0042fdeea2a51302_refs_heads_master@pld-linux.org>
Message-ID: <trlh2cp77smy6u27bzo3opbvjamtawxtfjq5usrbrd5zceqp7y@vvslp4fwf34h>

On 27.02.2025 11:28, mis wrote:
> commit 534b4046a44492fba55adafc0042fdeea2a51302
> Author: mis <mistoo at gmail.com>
> Date:   Thu Feb 27 10:25:46 2025 +0100
> 
>     up to 0.44.0

I might be missing something but what is the proper way to check all the
missing dependencies now? Previously I was using poldek -V and was under
impression following report is based on it too:

http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test

but with new version it just logs (somewhat surprisingly to stdout):

$ poldek -V
error: Nothing to do

I believe this commit disabled it:

https://github.com/poldek-pm/poldek/commit/8b61a91c19b001c1ff8ff36dd969b6a98a1c2f5f#diff-df481e79fe4131e98602792fdf4c0bab9459b9ccaf2aab510d00366e4716a706R896


From mis at pld-linux.org  Fri Feb 28 11:19:34 2025
From: mis at pld-linux.org (=?UTF-8?Q?Pawe=C5=82_Gajda?=)
Date: Fri, 28 Feb 2025 11:19:34 +0100
Subject: [packages/poldek] up to 0.44.0
In-Reply-To: <trlh2cp77smy6u27bzo3opbvjamtawxtfjq5usrbrd5zceqp7y@vvslp4fwf34h>
References: <225c634408b0aae7b34c2c743230b3f7c2d3dada_refs_heads_master@pld-linux.org>
 <534b4046a44492fba55adafc0042fdeea2a51302_refs_heads_master@pld-linux.org>
 <trlh2cp77smy6u27bzo3opbvjamtawxtfjq5usrbrd5zceqp7y@vvslp4fwf34h>
Message-ID: <a2bd717c-90cb-4365-826d-6fd6200e96d3@pld-linux.org>

On 2/28/25 00:06, Jan Palus wrote:
> On 27.02.2025 11:28, mis wrote:
>> commit 534b4046a44492fba55adafc0042fdeea2a51302
>> Author: mis <mistoo at gmail.com>
>> Date:   Thu Feb 27 10:25:46 2025 +0100
>>
>>      up to 0.44.0
> I might be missing something but what is the proper way to check all the
> missing dependencies now? Previously I was using poldek -V and was under
> impression following report is based on it too:
>
> http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
>
> but with new version it just logs (somewhat surprisingly to stdout):
>
> $ poldek -V
> error: Nothing to do
>
> I believe this commit disabled it:
>
> https://github.com/poldek-pm/poldek/commit/8b61a91c19b001c1ff8ff36dd969b6a98a1c2f5f#diff-df481e79fe4131e98602792fdf4c0bab9459b9ccaf2aab510d00366e4716a706R896

Right, I just forgot it. Restored in rel 3.