From baggins at pld-linux.org  Sat Jun  8 23:55:27 2024
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 8 Jun 2024 23:55:27 +0200
Subject: freshness report not updating
In-Reply-To: <sybialowziugfj2rxtqexmjawgwtlogjtg5cbn3c73grd2uxpx@3xxdowfmphgo>
References: <sybialowziugfj2rxtqexmjawgwtlogjtg5cbn3c73grd2uxpx@3xxdowfmphgo>
Message-ID: <ZmTTLwJtjtloFn8W@tachikoma>

On Sun, 05 May 2024, Jan Palus wrote:

> Looks like new entries don't appear in freshness report
> (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although
> interestingly old items that made it to the list disappear after they
> were sent to builders.

The problem is that SPECS pseudorepo has not been updated since May 1st,
probably due to disk space issues. I'll see if I can do something with
it.

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


From baggins at pld-linux.org  Tue Jun 11 09:41:24 2024
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 11 Jun 2024 09:41:24 +0200
Subject: freshness report not updating
In-Reply-To: <ZmTTLwJtjtloFn8W@tachikoma>
References: <sybialowziugfj2rxtqexmjawgwtlogjtg5cbn3c73grd2uxpx@3xxdowfmphgo>
 <ZmTTLwJtjtloFn8W@tachikoma>
Message-ID: <Zmf/F6txvuoJ37sw@starbug.lan>

On Sat, 08 Jun 2024, Jan R?korajski wrote:

> On Sun, 05 May 2024, Jan Palus wrote:
> 
> > Looks like new entries don't appear in freshness report
> > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although
> > interestingly old items that made it to the list disappear after they
> > were sent to builders.
> 
> The problem is that SPECS pseudorepo has not been updated since May 1st,
> probably due to disk space issues. I'll see if I can do something with
> it.

Took me a while, but problem solved.

The SPECS repo had a stale lock preventing it from being updated (???)

There was a second issue, the Refs repo had (i) grown to enormous size
and (ii) has been badly damaged to the point that git gc consistently
failed. Since Refs.git is just a tracker of all refs in packages repos,
I could and did recreate it from scratch saving 25G of space
(free went up from 3.7G to 32G).

Since we only really care about the HEAD state of Refs.git it would ge
good to prune it more regularly, so that we don't end up in this state
again.

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


From atler at pld-linux.org  Tue Jun 11 15:56:22 2024
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 11 Jun 2024 15:56:22 +0200
Subject: freshness report not updating
In-Reply-To: <Zmf/F6txvuoJ37sw@starbug.lan>
References: <sybialowziugfj2rxtqexmjawgwtlogjtg5cbn3c73grd2uxpx@3xxdowfmphgo>
 <ZmTTLwJtjtloFn8W@tachikoma> <Zmf/F6txvuoJ37sw@starbug.lan>
Message-ID: <7ohcnyzxgjntncgv3w4k55ti7lrr62dsyz2vzl2xjtvni4fcm4@kuhjxkezlzwd>

On 11.06.2024 09:41, Jan R?korajski wrote:
> On Sat, 08 Jun 2024, Jan R?korajski wrote:
> 
> > On Sun, 05 May 2024, Jan Palus wrote:
> > 
> > > Looks like new entries don't appear in freshness report
> > > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although
> > > interestingly old items that made it to the list disappear after they
> > > were sent to builders.
> > 
> > The problem is that SPECS pseudorepo has not been updated since May 1st,
> > probably due to disk space issues. I'll see if I can do something with
> > it.
> 
> Took me a while, but problem solved.
> 
> The SPECS repo had a stale lock preventing it from being updated (???)
> 
> There was a second issue, the Refs repo had (i) grown to enormous size
> and (ii) has been badly damaged to the point that git gc consistently
> failed. Since Refs.git is just a tracker of all refs in packages repos,
> I could and did recreate it from scratch saving 25G of space
> (free went up from 3.7G to 32G).
> 
> Since we only really care about the HEAD state of Refs.git it would ge
> good to prune it more regularly, so that we don't end up in this state
> again.

Thanks!


From baggins at pld-linux.org  Sat Jun 15 22:34:25 2024
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 15 Jun 2024 22:34:25 +0200
Subject: The horrible mess called PHP
Message-ID: <Zm36fvmkhN88Wh8b@tachikoma>

Tho whoever is interested in PHP.

TL;DR Make PHP packaging sustainable or all versioned php packages will
be deleted and replaced by a single php package tracking head.

The current model of packaging PHP runtime is not sustainable.

The dependencies are a complete mess, packages (build)require
php-something, but none of the versioned phpXY-something provides
this.

This leads to a lot of manual labor when rebuilding php-pecl
packages (run this magical command for managing installed deps
and pray it works).

This also leades to even worse mess for PEAR packages. The dependency
generator needs /usr/bin/php and it gets a random one, if it gets
anything at all.

If there is a real need to keep old versions of php, then whoever needs
this, please figure out a packang model that won't require enormous
cognitive load on anyone trying to deal with randmon php packages.

You have been warned,
Your maintainer
-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From arekm at maven.pl  Sun Jun 16 09:48:31 2024
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=C5=9Bkiewicz?=)
Date: Sun, 16 Jun 2024 09:48:31 +0200
Subject: The horrible mess called PHP
In-Reply-To: <Zm36fvmkhN88Wh8b@tachikoma>
References: <Zm36fvmkhN88Wh8b@tachikoma>
Message-ID: <b27ebf9e-aad5-481b-84e2-cbd7246c5b37@maven.pl>

On 15/06/2024 22:34, Jan R?korajski wrote:

> TL;DR Make PHP packaging sustainable or all versioned php packages will
> be deleted and replaced by a single php package tracking head.

I'm using almost all old PHPs, including old 4 one. DON'T delete these.

(I'm using few pear packages, too)

> 
> The current model of packaging PHP runtime is not sustainable. >
> The dependencies are a complete mess, packages (build)require
> php-something, but none of the versioned phpXY-something provides
> this.

Be more specific and I'll try to fix things related to php packages. Now 
I have to guess what are you talking about.

> This leads to a lot of manual labor when rebuilding php-pecl
> packages (run this magical command for managing installed deps
> and pray it works).
> 
> This also leades to even worse mess for PEAR packages. The dependency
> generator needs /usr/bin/php and it gets a random one,

Does output that it produces depend on php version? AFAIK any php is ok 
for it to produce the same output.

> if it gets
> anything at all.

But you did disable dependency generator for PEAR

Author: Jan R?korajski <baggins at pld-linux.org>
Date:   Sat Oct 17 10:02:30 2020 +0200
- disable php pear dependency generators - ver 1.753

and that causes now that rebuilding pear packages produce new packages 
that do not provide things that existing packages want.

If you disabled this to get rid of pear specific deps then all pear 
packages need to be rebuild.

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



From baggins at pld-linux.org  Sun Jun 16 10:30:28 2024
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 16 Jun 2024 10:30:28 +0200
Subject: The horrible mess called PHP
In-Reply-To: <b27ebf9e-aad5-481b-84e2-cbd7246c5b37@maven.pl>
References: <Zm36fvmkhN88Wh8b@tachikoma>
 <b27ebf9e-aad5-481b-84e2-cbd7246c5b37@maven.pl>
Message-ID: <Zm6ipDmXnZuLw+bw@starbug.lan>

On Sun, 16 Jun 2024, Arkadiusz Mi?kiewicz via pld-devel-en wrote:

> On 15/06/2024 22:34, Jan R?korajski wrote:
> 
> > TL;DR Make PHP packaging sustainable or all versioned php packages will
> > be deleted and replaced by a single php package tracking head.
> 
> I'm using almost all old PHPs, including old 4 one. DON'T delete these.
> 
> (I'm using few pear packages, too)
> 
> > 
> > The current model of packaging PHP runtime is not sustainable. >
> > The dependencies are a complete mess, packages (build)require
> > php-something, but none of the versioned phpXY-something provides
> > this.
> 
> Be more specific and I'll try to fix things related to php packages. Now 
> I have to guess what are you talking about.

$ builder -bi -R php-pear-PEAR.spec
[...]
Install dependencies: php-pcre php-xml
Loading [pndir]th-test...
Loading [pndir]th-test...
Loading [pndir]th-ready...
Loading [pndir]th-ready...
Loading [pndir]th...
Loading [pndir]th...
34536 packages read
Removed 2036 duplicate packages from available set
error: php-pcre: no such package
error: php-xml: no such package

Because spec:

%define php_name php%{?php_suffix}
[...]
BuildRequires: %{php_name}-pcre

Basically you need to set %php_suffix manually. This should be automated
at the spec level. Maybe something akin to what I did for kernel
packages. Or maybe "pick the latest runtime if not overriden" at macro
definition level.

And to make it better, all php runtimes should be parallel-installable,
including devel, excluding /usr/bin/php link.

> > This leads to a lot of manual labor when rebuilding php-pecl
> > packages (run this magical command for managing installed deps
> > and pray it works).
> > 
> > This also leades to even worse mess for PEAR packages. The dependency
> > generator needs /usr/bin/php and it gets a random one,
> 
> Does output that it produces depend on php version? AFAIK any php is ok 
> for it to produce the same output.

I have no idea, never used PHP. The script looks pretty generic, tho.

> > if it gets
> > anything at all.
> 
> But you did disable dependency generator for PEAR
> 
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sat Oct 17 10:02:30 2020 +0200
> - disable php pear dependency generators - ver 1.753
> 
> and that causes now that rebuilding pear packages produce new packages 
> that do not provide things that existing packages want.
> 
> If you disabled this to get rid of pear specific deps then all pear 
> packages need to be rebuild.

Hah, good point. I might have disabled it because of dependency problems
seteaming from constant installs/removals of the php runtime.

I'm going to reenable that and test if it still works.

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


From baggins at pld-linux.org  Sun Jun 16 10:48:58 2024
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 16 Jun 2024 10:48:58 +0200
Subject: The horrible mess called PHP
In-Reply-To: <Zm6ipDmXnZuLw+bw@starbug.lan>
References: <Zm36fvmkhN88Wh8b@tachikoma>
 <b27ebf9e-aad5-481b-84e2-cbd7246c5b37@maven.pl>
 <Zm6ipDmXnZuLw+bw@starbug.lan>
Message-ID: <Zm6m+qvE4ieW80f2@starbug.lan>

On Sun, 16 Jun 2024, Jan R?korajski wrote:

> On Sun, 16 Jun 2024, Arkadiusz Mi?kiewicz via pld-devel-en wrote:
> 
[...]
> > 
> > But you did disable dependency generator for PEAR
> > 
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Sat Oct 17 10:02:30 2020 +0200
> > - disable php pear dependency generators - ver 1.753
> > 
> > and that causes now that rebuilding pear packages produce new packages 
> > that do not provide things that existing packages want.
> > 
> > If you disabled this to get rid of pear specific deps then all pear 
> > packages need to be rebuild.
> 
> Hah, good point. I might have disabled it because of dependency problems
> seteaming from constant installs/removals of the php runtime.
> 
> I'm going to reenable that and test if it still works.

Ok, we have two dependency generators for php pear. One written in perl
and that one seem to work, and the second in php that seems to be
completely broken:

Runtime version 7.4.

First:

PHP Warning:  require_once(PHP/CompatInfo.php): failed to open stream: No such file or directory in /usr/lib/rpm/php.req.php on line 123
PHP Fatal error:  require_once(): Failed opening required 'PHP/CompatInfo.php' (include_path='.:/usr/share/pear:/usr/share/php') in /usr/lib/rpm/php.req.php on line 123

After installing php-pear-PHP_CompatInfo:

PHP Parse error:  syntax error, unexpected 'new' (T_NEW) in /usr/share/pear/Event/Dispatcher.php on line 249

I'll reenable the old one and we'll deal with the problems as they
appear.

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


From baggins at pld-linux.org  Thu Jun 20 23:17:22 2024
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Thu, 20 Jun 2024 23:17:22 +0200
Subject: The horrible mess called PHP
In-Reply-To: <b27ebf9e-aad5-481b-84e2-cbd7246c5b37@maven.pl>
References: <Zm36fvmkhN88Wh8b@tachikoma>
 <b27ebf9e-aad5-481b-84e2-cbd7246c5b37@maven.pl>
Message-ID: <ZnScYvfWnGFWRUl5@tachikoma.lan>

On Sun, 16 Jun 2024, Arkadiusz Mi?kiewicz via pld-devel-en wrote:

[...]
> 
> But you did disable dependency generator for PEAR
> 
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sat Oct 17 10:02:30 2020 +0200
> - disable php pear dependency generators - ver 1.753
> 
> and that causes now that rebuilding pear packages produce new packages 
> that do not provide things that existing packages want.
> 
> If you disabled this to get rid of pear specific deps then all pear 
> packages need to be rebuild.

I think I know why I disabled it back then.
With rpm5, the dependency generators could be selected by hand in the
spec, this is not the case with rpm.org. Now, that dependency generator
is run on every package, it picks up a lot of BS that has to be excepted
with _noautoreq_pear - see latest updates to zabbix and occ packages.

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