From atler at pld-linux.org  Wed Oct  1 19:17:07 2025
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 1 Oct 2025 19:17:07 +0200
Subject: [packages/cage] up to 0.2.1
In-Reply-To: <d6dfb9dbe25b9f3d314b1234548ad33f56de4df5_refs_heads_master@pld-linux.org>
References: <399378da2c5811c40dac3e5c58da55eaa880a134_refs_heads_master@pld-linux.org>
 <d6dfb9dbe25b9f3d314b1234548ad33f56de4df5_refs_heads_master@pld-linux.org>
Message-ID: <3qzw6jwmjicw6k5if2c5yy3xjdtbzgzfe26vcap26rh3euhljg@7omlq2bv7ifb>

On 01.10.2025 18:26, atler wrote:
> commit d6dfb9dbe25b9f3d314b1234548ad33f56de4df5
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Wed Oct 1 18:26:10 2025 +0200
> 
>     up to 0.2.1

This effectively renders wlroots0.18 obsolete and hence
wlroots0.18/wlroots0.18-devel/wlroots0.18-static packages can be dropped
after cage 0.2.1 lands in main.


From baggins at pld-linux.org  Fri Oct  3 23:49:39 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 3 Oct 2025 23:49:39 +0200
Subject: [packages/qt4] - qmake is broken with asserts not enabled
In-Reply-To: <3e8deb1d49a9bad20c38bdb7b40a2182df0b2ca8_refs_heads_master@pld-linux.org>
References: <4e9b10014f64cbfd5bd4f9844914841aa83917f3_refs_heads_master@pld-linux.org>
 <3e8deb1d49a9bad20c38bdb7b40a2182df0b2ca8_refs_heads_master@pld-linux.org>
Message-ID: <aOBE2DCc2EBM7kes@tachikoma>

I'm really sorry you've wasted your time fixing this, I should have
announced this beforehand.

I am going to delete qt4 from Th. It's dead. Almost anything depending
on it is dead. There is no point in keeping any and all of this.

On Thu, 02 Oct 2025, qboosh wrote:

> commit 3e8deb1d49a9bad20c38bdb7b40a2182df0b2ca8
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Thu Oct 2 21:16:48 2025 +0200
> 
>     - qmake is broken with asserts not enabled
> 
>  qt4.spec | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> ---
> diff --git a/qt4.spec b/qt4.spec
> index 7c31d82..e1b2b82 100644
> --- a/qt4.spec
> +++ b/qt4.spec
> @@ -159,6 +159,7 @@ BuildRequires:	libicu-devel >= %{icu_abi}
>  BuildRequires:	libicu-devel < %{next_icu_abi}
>  BuildRequires:	libjpeg-devel
>  BuildRequires:	libmng-devel >= 1.0.0
> +BuildRequires:	libnsl-devel
>  BuildRequires:	libpng-devel >= 2:1.0.8
>  BuildRequires:	libstdc++-devel
>  BuildRequires:	libtirpc-devel
> @@ -191,10 +192,11 @@ Obsoletes:	qt-utils < 6:3.3.3
>  Conflicts:	kdelibs <= 8:3.2-0.030602.1
>  BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>  
> -%define		_noautoreqdep	libGL.so.1 libGLU.so.1
>  %define		_noautostrip	'.*_debug\\.so*'
>  
>  %define		specflags	-fno-strict-aliasing -Wno-deprecated
> +# at least qmake is broken without asserts enabled (two cases with "Q_ASSERT(function_blocks.pop() == defined);")
> +%define		filterout_cpp	-DNDEBUG -DQT_NO_DEBUG
>  
>  %define		_qtdir		%{_libdir}/qt4
>  
> ================================================================
> 
> ---- gitweb:
> 
> http://git.pld-linux.org/gitweb.cgi/packages/qt4.git/commitdiff/3e8deb1d49a9bad20c38bdb7b40a2182df0b2ca8
> 
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit

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


From qboosh at pld-linux.org  Sat Oct  4 21:22:24 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 4 Oct 2025 21:22:24 +0200
Subject: [packages/qt4] - qmake is broken with asserts not enabled
In-Reply-To: <aOBE2DCc2EBM7kes@tachikoma>
References: <4e9b10014f64cbfd5bd4f9844914841aa83917f3_refs_heads_master@pld-linux.org>
 <3e8deb1d49a9bad20c38bdb7b40a2182df0b2ca8_refs_heads_master@pld-linux.org>
 <aOBE2DCc2EBM7kes@tachikoma>
Message-ID: <20251004192224.GA29806@mail>

On Fri, Oct 03, 2025 at 11:49:39PM +0200, Jan R?korajski wrote:
> I'm really sorry you've wasted your time fixing this, I should have
> announced this beforehand.

Anyway, I did it also for myself.

> I am going to delete qt4 from Th. It's dead. Almost anything depending
> on it is dead. There is no point in keeping any and all of this.

I bet some packages currently linked with qt4 are worth keeping - maybe
some of them have newer versions supporting qt5+.

BTW, Fedora, which is the first to drop unmaintained software, hasn't
dropped qt4 yet (qt.spec):
https://src.fedoraproject.org/rpms/qt/commits/rawhide

But if you don't want it, I could abstain from sending qt4 depending
stuff to builders.


PS. it seems ftp ran out of space again...


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


From atler at pld-linux.org  Fri Oct 10 19:56:24 2025
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 10 Oct 2025 19:56:24 +0200
Subject: SSE2 required for i686 targets in rust >= 1.86
In-Reply-To: <aIFHMnYBCtfNMLBK@tachikoma>
References: <pxtz3qajmqlrrr2dyq5theknvrojjfan3lryowwbsj4i5kdboh@rkxrvhxkjvdh>
 <20250723190136.GA32274@mail> <aIFHMnYBCtfNMLBK@tachikoma>
Message-ID: <b3inun65aeyzezig6qguiimidvprvow6uwo6vvdd7q76azhfff@k7ybnga66tjv>

On 23.07.2025 22:33, Jan R?korajski wrote:
> On Wed, 23 Jul 2025, Jakub Bogusz wrote:
> 
> > On Fri, May 16, 2025 at 12:27:34PM +0200, Jan Palus wrote:
> > > Starting with rust 1.86 binaries built for i686 (including rustc itself)
> > > require SSE2 instructions (refer to release notes for rationale). The
> > > question is how we'd like to handle this:
> > > 
> > > 1. Change target to i586-unknown-linux-gnu for i686.
> > >    i586-unknown-linux-gnu is "Tier 2 platform without host tools" so
> > >    we'd need to build both i686-unknown-linux-gnu for tools which would
> > >    require SSE2 as well as i586-unknown-linux-gnu.
> > > 
> > > 2. Put "Requires: cpuinfo(sse2)" possibly through some %rust_req macro
> > >    in every package utilizing rust
> > > 
> > > 3. Change our baseline for i686 so SSE2 is mandatory and do nothing.
> > > 
> > > Any other ideas are welcome.
> > 
> > 1 looks like big PITA, so I'd go with 2...
> 
> Considering that more and more ~base libraries are being ported to rust
> and ix86 *hardware* is practically obsolete and barely exists, the only
> real choice is 3.
> 
> Let's face it, we have i686 not to run on i686 hw, but for random
> binaries not available on x86_64.

Thing is if we just accept sse2 in i686, we could just as well add
-msse2 to %{rpmcflags}/%{rpmcxxflags} but then it's no longer "i686" --
it's effectively "pentium4" target. I'm not gonna make that call though
so I'll stick to 2. for the time being. If someone wants to add -msse2
feel free to do so.


From arekm at maven.pl  Fri Oct 10 20:42:09 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Fri, 10 Oct 2025 20:42:09 +0200
Subject: SSE2 required for i686 targets in rust >= 1.86
In-Reply-To: <b3inun65aeyzezig6qguiimidvprvow6uwo6vvdd7q76azhfff@k7ybnga66tjv>
References: <pxtz3qajmqlrrr2dyq5theknvrojjfan3lryowwbsj4i5kdboh@rkxrvhxkjvdh>
 <20250723190136.GA32274@mail> <aIFHMnYBCtfNMLBK@tachikoma>
 <b3inun65aeyzezig6qguiimidvprvow6uwo6vvdd7q76azhfff@k7ybnga66tjv>
Message-ID: <dc3f6ca4-3315-477a-99e6-af9543d155d8@maven.pl>

On 10/10/2025 19:56, Jan Palus wrote:

> Thing is if we just accept sse2 in i686, we could just as well add
> -msse2 to %{rpmcflags}/%{rpmcxxflags} but then it's no longer "i686" --
> it's effectively "pentium4" target. I'm not gonna make that call though
> so I'll stick to 2. for the time being. If someone wants to add -msse2
> feel free to do so.

I would drop i686 entirely... Do we have any i686 users? (or devs that 
need i686).

(Personally I still have few i686 installations but all are on x86_64 
hosts; I have zero 32bit only hardware here).

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


From atler at pld-linux.org  Fri Oct 10 21:38:49 2025
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 10 Oct 2025 21:38:49 +0200
Subject: SSE2 required for i686 targets in rust >= 1.86
In-Reply-To: <dc3f6ca4-3315-477a-99e6-af9543d155d8@maven.pl>
References: <pxtz3qajmqlrrr2dyq5theknvrojjfan3lryowwbsj4i5kdboh@rkxrvhxkjvdh>
 <20250723190136.GA32274@mail> <aIFHMnYBCtfNMLBK@tachikoma>
 <b3inun65aeyzezig6qguiimidvprvow6uwo6vvdd7q76azhfff@k7ybnga66tjv>
 <dc3f6ca4-3315-477a-99e6-af9543d155d8@maven.pl>
Message-ID: <dmryfhe2lzoiamnbc2xap7ys4wobz4f7x64fjhlbkaip4kvuwk@2tsfamu24own>

On 10.10.2025 20:42, Arkadiusz Mi?kiewicz via pld-devel-en wrote:
> On 10/10/2025 19:56, Jan Palus wrote:
> 
> > Thing is if we just accept sse2 in i686, we could just as well add
> > -msse2 to %{rpmcflags}/%{rpmcxxflags} but then it's no longer "i686" --
> > it's effectively "pentium4" target. I'm not gonna make that call though
> > so I'll stick to 2. for the time being. If someone wants to add -msse2
> > feel free to do so.
> 
> I would drop i686 entirely... Do we have any i686 users? (or devs that need
> i686).
> 
> (Personally I still have few i686 installations but all are on x86_64 hosts;
> I have zero 32bit only hardware here).

i686 is still useful on x86_64 to run old 32-bit binary software and games.


From qboosh at pld-linux.org  Fri Oct 10 21:58:36 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 10 Oct 2025 21:58:36 +0200
Subject: SSE2 required for i686 targets in rust >= 1.86
In-Reply-To: <dmryfhe2lzoiamnbc2xap7ys4wobz4f7x64fjhlbkaip4kvuwk@2tsfamu24own>
References: <pxtz3qajmqlrrr2dyq5theknvrojjfan3lryowwbsj4i5kdboh@rkxrvhxkjvdh>
 <20250723190136.GA32274@mail> <aIFHMnYBCtfNMLBK@tachikoma>
 <b3inun65aeyzezig6qguiimidvprvow6uwo6vvdd7q76azhfff@k7ybnga66tjv>
 <dc3f6ca4-3315-477a-99e6-af9543d155d8@maven.pl>
 <dmryfhe2lzoiamnbc2xap7ys4wobz4f7x64fjhlbkaip4kvuwk@2tsfamu24own>
Message-ID: <20251010195836.GA17669@mail>

On Fri, Oct 10, 2025 at 09:38:49PM +0200, Jan Palus wrote:
> On 10.10.2025 20:42, Arkadiusz Mi?kiewicz via pld-devel-en wrote:
> > On 10/10/2025 19:56, Jan Palus wrote:
> > 
> > > Thing is if we just accept sse2 in i686, we could just as well add
> > > -msse2 to %{rpmcflags}/%{rpmcxxflags} but then it's no longer "i686" --
> > > it's effectively "pentium4" target. I'm not gonna make that call though
> > > so I'll stick to 2. for the time being. If someone wants to add -msse2
> > > feel free to do so.
> > 
> > I would drop i686 entirely... Do we have any i686 users? (or devs that need
> > i686).
> > 
> > (Personally I still have few i686 installations but all are on x86_64 hosts;
> > I have zero 32bit only hardware here).
> 
> i686 is still useful on x86_64 to run old 32-bit binary software and games.

And on e.g. old 4GiB machine x86_64 binaries are no-go...


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


From baggins at pld-linux.org  Sat Oct 11 12:36:09 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 11 Oct 2025 10:36:09 +0000
Subject: The vulkan enchillada
Message-ID: <aOozGdDlUht74Neb@starbug.lan>

Can someone explain which vulkan packages are correct and current?
There are (lower letter) packages like vuilkan-sdk that seem to be some
old versions and (capital letter) Vulkan-Tools seemingly built from the
same source, newerm but they don't seem to have the same functionality?

Can we have some clarity on this? Maybe, at least, capitalization
unification? Can some of the packages ve deleted?

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


From baggins at pld-linux.org  Sat Oct 11 14:31:12 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 11 Oct 2025 14:31:12 +0200
Subject: [packages/cage] up to 0.2.1
In-Reply-To: <3qzw6jwmjicw6k5if2c5yy3xjdtbzgzfe26vcap26rh3euhljg@7omlq2bv7ifb>
References: <399378da2c5811c40dac3e5c58da55eaa880a134_refs_heads_master@pld-linux.org>
 <d6dfb9dbe25b9f3d314b1234548ad33f56de4df5_refs_heads_master@pld-linux.org>
 <3qzw6jwmjicw6k5if2c5yy3xjdtbzgzfe26vcap26rh3euhljg@7omlq2bv7ifb>
Message-ID: <aOpKVd_xBx9jvAWW@tachikoma>

On Wed, 01 Oct 2025, Jan Palus wrote:

> On 01.10.2025 18:26, atler wrote:
> > commit d6dfb9dbe25b9f3d314b1234548ad33f56de4df5
> > Author: Jan Palus <atler at pld-linux.org>
> > Date:   Wed Oct 1 18:26:10 2025 +0200
> > 
> >     up to 0.2.1
> 
> This effectively renders wlroots0.18 obsolete and hence
> wlroots0.18/wlroots0.18-devel/wlroots0.18-static packages can be dropped
> after cage 0.2.1 lands in main.

Ack, cage 0.2.1 in ready, removed wlroots0.18.

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


From qboosh at pld-linux.org  Wed Oct 15 21:59:27 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 15 Oct 2025 21:59:27 +0200
Subject: The vulkan enchillada
In-Reply-To: <aOozGdDlUht74Neb@starbug.lan>
References: <aOozGdDlUht74Neb@starbug.lan>
Message-ID: <20251015195927.GA22100@mail>

On Sat, Oct 11, 2025 at 10:36:09AM +0000, Jan R?korajski wrote:
> Can someone explain which vulkan packages are correct and current?
> There are (lower letter) packages like vuilkan-sdk that seem to be some
> old versions and (capital letter) Vulkan-Tools seemingly built from the
> same source, newerm but they don't seem to have the same functionality?
> 
> Can we have some clarity on this? Maybe, at least, capitalization
> unification? Can some of the packages ve deleted?

vulkan-sdk.spec is some very old version.
Its source repo has been split, some of components have been refactored
(e.g. ValidationLayers).

Vulkan-*.spec have Obsoletes for most of vulkan-sdk.spec parts, but so
far I haven't found what happend to DebugLayers.
Maybe we could just obsolete it.


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


From qboosh at pld-linux.org  Sat Oct 18 19:46:46 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 18 Oct 2025 19:46:46 +0200
Subject: [packages/doxygen] Up to 1.14.0
In-Reply-To: <502c656a635359794a32aa04f556d51c1bc8e563_refs_heads_master@pld-linux.org>
References: <92223dab11e5130c804fd58aa331c575c2b5ec9e_refs_heads_master@pld-linux.org>
 <502c656a635359794a32aa04f556d51c1bc8e563_refs_heads_master@pld-linux.org>
Message-ID: <20251018174646.GA11520@mail>

Does this version work with ancient texlive in PLD?


On Sat, Oct 18, 2025 at 02:33:17PM +0200, arekm wrote:
> commit 502c656a635359794a32aa04f556d51c1bc8e563
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Sat Oct 18 14:32:56 2025 +0200
> 
>     Up to 1.14.0
> 
>  doxygen-doc.patch |  21 ------
>  doxygen.spec      |  19 +++---
>  flex2.6.patch     | 197 ------------------------------------------------------
>  3 files changed, 9 insertions(+), 228 deletions(-)
> ---

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


From arekm at maven.pl  Sat Oct 18 21:49:38 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Sat, 18 Oct 2025 21:49:38 +0200
Subject: [packages/doxygen] Up to 1.14.0
In-Reply-To: <20251018174646.GA11520@mail>
References: <92223dab11e5130c804fd58aa331c575c2b5ec9e_refs_heads_master@pld-linux.org>
 <502c656a635359794a32aa04f556d51c1bc8e563_refs_heads_master@pld-linux.org>
 <20251018174646.GA11520@mail>
Message-ID: <30d8e369-20bb-4faf-9344-3c05c34e92e4@maven.pl>

On 18/10/2025 19:46, Jakub Bogusz wrote:
> Does this version work with ancient texlive in PLD?

>>      Up to 1.14.0
>>
>>   doxygen.spec      |  19 +++---

No idea. I'll remove it until that's known.

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


From qboosh at pld-linux.org  Sun Oct 26 16:16:36 2025
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 26 Oct 2025 16:16:36 +0100
Subject: no-network build policy rules
Message-ID: <20251026151636.GA14659@mail>

I found that there are different meanings of "no network usage":
1) builders cannot use external resources/hosts, which is enforced by
  non-functional resolv.conf
2) but `unshare --net` introduced recently in builder script does even
  more: it disables the use of localhost connections (binding/connecting
  to lo interface/127.0.0.1/8 addresses)

Many more test suites rely on loopback connections working than using
external resources, so there are many (esp. python or perl modules,
openssl, openssh, git etc.) packages which can be built fine on builders,
but not with builder script (without --bnet).

How should be packages (and their default tests options) prepared, to
compy with 1) or 2)?


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


From arekm at maven.pl  Sun Oct 26 16:33:21 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Sun, 26 Oct 2025 16:33:21 +0100
Subject: no-network build policy rules
In-Reply-To: <20251026151636.GA14659@mail>
References: <20251026151636.GA14659@mail>
Message-ID: <d0a04985-0cab-4523-aef4-97c25195a6eb@maven.pl>

On 26/10/2025 16:16, Jakub Bogusz wrote:
> I found that there are different meanings of "no network usage":
> 1) builders cannot use external resources/hosts, which is enforced by
>    non-functional resolv.conf
> 2) but `unshare --net` introduced recently in builder script does even
>    more: it disables the use of localhost connections (binding/connecting
>    to lo interface/127.0.0.1/8 addresses)
> 
> Many more test suites rely on loopback connections working than using
> external resources, so there are many (esp. python or perl modules,
> openssl, openssh, git etc.) packages which can be built fine on builders,
> but not with builder script (without --bnet).
> 
> How should be packages (and their default tests options) prepared, to
> compy with 1) or 2)?

Best would be 2 but with configured loopback. Unfortunately that doesn't 
seem to be possible via unshare for a unprivileged user.

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


From atler at pld-linux.org  Mon Oct 27 01:33:01 2025
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 27 Oct 2025 01:33:01 +0100
Subject: no-network build policy rules
In-Reply-To: <20251026151636.GA14659@mail>
References: <20251026151636.GA14659@mail>
Message-ID: <ddvcvtdccbb2ilwbabzfzdqtmjznid2chvke4jdryes3u5lecb@lgvrorkpfydr>

On 26.10.2025 16:16, Jakub Bogusz wrote:
> I found that there are different meanings of "no network usage":
> 1) builders cannot use external resources/hosts, which is enforced by
>   non-functional resolv.conf
> 2) but `unshare --net` introduced recently in builder script does even
>   more: it disables the use of localhost connections (binding/connecting
>   to lo interface/127.0.0.1/8 addresses)
> 
> Many more test suites rely on loopback connections working than using
> external resources, so there are many (esp. python or perl modules,
> openssl, openssh, git etc.) packages which can be built fine on builders,
> but not with builder script (without --bnet).
> 
> How should be packages (and their default tests options) prepared, to
> compy with 1) or 2)?

My attempt at adding ip address to loopback interface landed on
`netns-with-lo-addr` branch. I'm not particularly proud of it but it
seems to work. I would appreciate second look and comments.


From arekm at maven.pl  Mon Oct 27 10:50:54 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Mon, 27 Oct 2025 10:50:54 +0100
Subject: no-network build policy rules
In-Reply-To: <ddvcvtdccbb2ilwbabzfzdqtmjznid2chvke4jdryes3u5lecb@lgvrorkpfydr>
References: <20251026151636.GA14659@mail>
 <ddvcvtdccbb2ilwbabzfzdqtmjznid2chvke4jdryes3u5lecb@lgvrorkpfydr>
Message-ID: <bab59ca2-0f55-4f40-a68d-13ce68472c49@maven.pl>

On 27/10/2025 01:33, Jan Palus wrote:
> On 26.10.2025 16:16, Jakub Bogusz wrote:
>> I found that there are different meanings of "no network usage":
>> 1) builders cannot use external resources/hosts, which is enforced by
>>    non-functional resolv.conf
>> 2) but `unshare --net` introduced recently in builder script does even
>>    more: it disables the use of localhost connections (binding/connecting
>>    to lo interface/127.0.0.1/8 addresses)
>>
>> Many more test suites rely on loopback connections working than using
>> external resources, so there are many (esp. python or perl modules,
>> openssl, openssh, git etc.) packages which can be built fine on builders,
>> but not with builder script (without --bnet).
>>
>> How should be packages (and their default tests options) prepared, to
>> compy with 1) or 2)?
> 
> My attempt at adding ip address to loopback interface landed on
> `netns-with-lo-addr` branch. I'm not particularly proud of it but it
> seems to work. I would appreciate second look and comments.

Seems to be working. It would be probably best to try to move that to 
external wrapper like pld-nonetwork.(py|sh)

Wrapper could be then be used in builder script but also in 
PLD_Builder/rpm_builder.py:build_rpm(() call as our binary builders do 
not use builder script.

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


From arekm at maven.pl  Mon Oct 27 11:02:48 2025
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Mon, 27 Oct 2025 11:02:48 +0100
Subject: no-network build policy rules
In-Reply-To: <bab59ca2-0f55-4f40-a68d-13ce68472c49@maven.pl>
References: <20251026151636.GA14659@mail>
 <ddvcvtdccbb2ilwbabzfzdqtmjznid2chvke4jdryes3u5lecb@lgvrorkpfydr>
 <bab59ca2-0f55-4f40-a68d-13ce68472c49@maven.pl>
Message-ID: <5eb95b44-08f5-49ed-9df9-c853aa7d00ce@maven.pl>

On 27/10/2025 10:50, Arkadiusz Mi?kiewicz wrote:
> PLD_Builder/ 
> rpm_builder.py:build_rpm(() call as our binary builders do not use 
> builder script.

That probably won't be simple though. chroot is involved on builders.

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


From baggins at pld-linux.org  Tue Oct 28 22:13:50 2025
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 28 Oct 2025 22:13:50 +0100
Subject: no-network build policy rules
In-Reply-To: <5eb95b44-08f5-49ed-9df9-c853aa7d00ce@maven.pl>
References: <20251026151636.GA14659@mail>
 <ddvcvtdccbb2ilwbabzfzdqtmjznid2chvke4jdryes3u5lecb@lgvrorkpfydr>
 <bab59ca2-0f55-4f40-a68d-13ce68472c49@maven.pl>
 <5eb95b44-08f5-49ed-9df9-c853aa7d00ce@maven.pl>
Message-ID: <aQEyDtMAPdHc5FMJ@tachikoma>

On Mon, 27 Oct 2025, Arkadiusz Mi?kiewicz via pld-devel-en wrote:

> On 27/10/2025 10:50, Arkadiusz Mi?kiewicz wrote:
> > PLD_Builder/ 
> > rpm_builder.py:build_rpm(() call as our binary builders do not use 
> > builder script.
> 
> That probably won't be simple though. chroot is involved on builders.

If we're going all out with a wrapper, we can as well try using
ushare --root --mount instead of chroot.

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