Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[Remi Collet]

Le 29/04/2024 à 11:32, domi...@wombacher.cc a écrit :

On 04/24/2024 4:21 PM CEST Remi Collet  wrote:



I suspect you may need awscrt extension which is quite
a nightmare as it bundles tons of libaws-*


You suspect right, "aws/aws-crt-php": "^1.2.3".


https://git.remirepo.net/cgit/rpms/php/pecl/php-pecl-awscrt.git/tree/


Wow cool, thanks for sharing. Is there a reasons you didn't use your package to 
create one for Fedora? It looks like you did all the heavy lifting already.

What I can already tell: I opened a can of worms with my wish to keep 
php-aws-sdk3 alive. It will be a challenge but a good learning opportunity too.


As I said, because of bundled libraries

And also lack or PHP reviewers
I already have tons of packages waiting for review for months

Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[Remi Collet]

Le 24/04/2024 à 11:41, domi...@wombacher.cc a écrit :


I'm not in the packager group yet and looking for a Sponsor to completed the 
onboarding process.
Afterwards I want to become the maintainer of the orphaned packages 
php-aws-sdk3 [1], php-ralouphie-getallheaders [2] and php-guzzlehttp-guzzle6 
[3].
My main motivation is to keep the php-aws-sdk3 package alive.
The other two are orphaned dependencies that I'm willing to adopt too.


I can probably help for PHP reviews

Notice:

- php-ralouphie-getallheaders: this is a compat layer  providing a 
missing function in PHP < 7.3 for php-fpm users


Please check you really still need it ;)

- php-guzzlehttp-guzzle6: this was version 6

A new package is probably needed for version 7

See https://bugzilla.redhat.com/show_bug.cgi?id=1982627
(this stalled review was for 7.3.0, current is 7.8.1)

- php-aws-sdk3: is really outdated (3.191.10 => 3.305.1)

New version probably have different dependencies

I suspect you may need awscrt extension which is quite
a nightmare as it bundles tons of libaws-*

https://git.remirepo.net/cgit/rpms/php/pecl/php-pecl-awscrt.git/tree/



Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

PHP without 32-bit

[Remi Collet]

Hi,

https://fedoraproject.org/wiki/Changes/php_no_32_bit

Most work is done
https://bodhi.fedoraproject.org/updates/FEDORA-2024-88e69f401c

All extensions have also been rebuilt

3 packages need to be fixed

- libvpx8 waiting for PR #1
- flamegraph waiting for PR #1
- swig waiting for PR #7


Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)

[Remi Collet]

Le 17/04/2024 à 18:37, Maxwell G a écrit :

On Wed Apr 17, 2024 at 16:38 +0100, Aoife Moloney wrote:
Thank you for submitting this!


I agree we’ll have to get rid of redis in the future, and than such a 
switch will make a strong statement about our disapproval to redis about 
this License change.


But I also think this is a bit early (F41)

- Valkey is very young, and they is no proof it will be best choice

- Redis 7.2 is still there and maintained (even version 6.2 and 7.0 are 
maintained), and keeping it have no security issue.


So I’m -1 for F41 and probably +1 for F42


Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: convert everything to rpmautospec?

[Remi Collet]

Le 08/04/2024 à 18:43, Michael J Gruber a écrit :


How absurd!


That is rude, and ONLY your PoV.


To summarize, there is no agreement on a unique
workflow, and having one to become the only allowed
seems to me as a terrible idea.


Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: convert everything to rpmautospec?

[Remi Collet]

Le 07/04/2024 à 17:15, Zbigniew Jędrzejewski-Szmek a écrit :

Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
   (e.g. when they want to push some fix or separately from other
work)
- people submitting pull requests against src.fp.o MAY also
   include a conversion in the pull request and packagers SHOULD
   merge it.


Big -1 to all

git log IS NOT a package changelog

Read https://keepachangelog.com/en/1.1.0/



Remi

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PHP-DEV] base64_encode without padding

[Remi Collet]

Le 13/03/2024 à 17:06, Remi Collet a écrit :


   PHPAPI extern zend_string *php_base64_encode_ex
     (const unsigned char *, size_t, zend_long flags);


This is done in master

No change in user-land
and no plan from me.


Remi

Re: Redis will no longer be OSS... now what?

[Remi Collet]

Le 21/03/2024 à 19:19, Scott Williams a écrit :

can we really continue to ship redis-7 in Fedora 40 if we can't patch and maintain it? 


I don't see any problem keeping Redis 7.2
in Fedora 40 and up for a while.

And having some alternatives (keydb...), to be installed
simultenously (especially for tests)

Then wait for stabilization of the community.


Remi


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PHP-DEV] base64_encode without padding

[Remi Collet]

Le 14/03/2024 à 21:31, Yasuo Ohgaki a écrit :


Please add PHP_BASE64_URL flag also.


This is another feature, out of the scope of this PR


Remi

Re: [PHP-DEV] base64_encode without padding

[Remi Collet]

Le 14/03/2024 à 12:46, Dik Takken a écrit :


Only I would strongly prefer a boolean argument over a flag.


Make sense.
PR updated

Re: [PHP-DEV] base64_encode without padding

[Remi Collet]

Link to the PR  https://github.com/php/php-src/pull/13698

[PHP-DEV] base64_encode without padding

[Remi Collet]

I think padding should be optional (on by default to keep BC)

Of course in user land, simple to write

  $enc = trim(base64_encode('foo'), '=');

This proposal allow to simply use

  $enc = base64_encode('foo', PHP_BASE64_NO_PADDING);

And also expose it for extension as

  PHPAPI extern zend_string *php_base64_encode_ex
(const unsigned char *, size_t, zend_long flags);


Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635

It may seems ugly to add and remove th padding char

Is a RFC needed for such a minor feature ?


Remi

Re: [PHP-DEV] New "PECL"

[Remi Collet]

Le 05/12/2023 à 14:45, Derick Rethans a écrit :

https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo

In this first stage, we would like to invite you in commenting on the
document (either inline, or here).


As inline requires a Google account...

> priority (optional): The installation "priority".

1/ I don't like this name which is ambiguous

higher value seems to give higher priority
which lower are loaded first

This prefix, used in various linux distro,
is really a "load order", needed when using --enable-rtld-now

So I proprose "load order" instead

2/ values

Default value can be 40 or max(requirement) + 10

In Fedora where we use this for years we have
(IIRC debian have different practice)

0-19 for zend_extension
10 for opcache
15 for xdebug
20-39 for php-src extension
20 for most
30 if requirement (ex: pdo drivers)
40-99 for other (pecl...)
40 for igbinary, msgpack
50 for redis which use igbinary, msgpack


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PECL-DEV] Publish Aerospike PHP extension to PECL

[Remi Collet]

Le 27/11/2023 à 20:36, Sachin Venkatesha Murthy a écrit :

Hello!

I am Sachin, a developer at Aerospike. I maintain the PHP client for
Aerospike. I'd like to introduce you to the Aerospike PHP client extension,
a PHP SDK which is an extension written in Rust for the Aerospike NoSQL
database system. This is a newer Aerospike PHP client that was built as a
Rust extension to support PHP 8 and newer versions. It is designed to be
efficient and reliable, providing a straightforward interface to interact
with the Aerospike database from your PHP codebase.

*GitHub Repository: Aerospike PHP Client
*

*Current Status:*

It is currently still in the alpha release stage but we plan on releasing
the final version very soon. We had released it on packagist but we want to
transition to PECL as soon as possible as it's the right way to install
Rust/C based PHP extensions.


LICENSE file is missing

AFAIK, pecl command needs a config.m4 and build using
phpize && ./configure && make

A simple minimal config.m4 with a Makefile.frag should
be able to run what is need for cargo build

BTW, rust :(  ~800MB used for build

Remi



Documentation is provided in the Readme.md as well as php stubs with php
docs are provided.

It would be great if this library could be accepted as a part of the PECL
repository.

Thanks and Regards,

Sachin



--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Remi Collet]

Le 27/11/2023 à 14:23, Frederic Berat a écrit :

I made a mass rebuild of the packages that directly depend on libxml2, 
and found 115 packages (out of 621) with build failure correlated to the 
libxml2 update.


I see PHP in the failure report

The issue is fixed upstream
https://github.com/php/php-src/commit/8a95e616b91ac0eeedba90a61e36e652919763f2


The patch is in 8.3.0 in rawhide
(and will be in 8.2.14 in F39 in 3 weeks)


Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PHP-DEV] PHP-8.1 closed for bug fixes, security fixes only

[Remi Collet]

Le 10/11/2023 à 20:57, Ben Ramsey a écrit :

Hi, all!

According to the supported versions page[^1] (and our release process 
documentation), active support for PHP-8.1 ends on 25 Nov 2023. Since our 
release cycle has a release falling on 23 Nov, this means PHP 8.1.26 is the 
last bug-fix release for the 8.1 series. Following PHP 8.1.26, PHP 8.1 will be 
in security maintenance mode.

I know there was some confusion around this, and I apologize that we didn’t 
make this clear earlier (though the dates have been posted for a while ;-) ).

PHP 8.1.26RC1 was technically the last chance to get in bug fixes and have them 
tested prior to the release on 23 Nov.

Unfortunately, we’ve had a few bug fixes merged into the PHP-8.1 branch since 
yesterday, and I’ll work with Patrick and others on figuring out what to do 
with these.


Sorry to have push such fix (zip ext)
Feel free to revert
(IMHO this is really a minor issue for very specific usage)

IIRC on previous versions, the branch was close on date (25th)
which means we have 1 more bugfix version for such late fixes


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Release cycle update

[Remi Collet]

Le 10/11/2023 à 17:51, Jakub Zelenka a écrit :

Hello,

I would like to propose a new process RFC for updates to PHP release cycle:

https://wiki.php.net/rfc/release_cycle_update



> Extending security support by one year

+1

> Allowing recent regression fixes during security support

As regression are often discovered quickly, 12 months is perhaps too 
much. BTW, such fix will need RM approval, so


+1

> Disallowing new features completely in RC and bug fixing release

+1

With RM exception

> Allow feature that do not require RFC in beta

+1

With RM approval

> Reduce number of RC to 4

Yes pre-release cycle is long
But RC time is used by other project for test/fix
especially for pecl extension to fix compatibility

IMHO 4 months seems fine for minor version (e.g. 8.4)
but not enough for major version (e.g. 9.0)

> The changes will apply immediately on the all currently supported 
branches from PHP-8.1.
> It means that PHP-8.0 would get an extra year of security fixes if 
that proposal is accepted.


Hmm... this sentence is ambiguous  ;)
Should be 8.1 for both, right ?


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [Rpm-maint] [rpm-software-management/rpm] Make rpmfiSetFX() return code meaningful (318efba)

[Remi Collet]

Make sense

Was affected, trying to build test code developed on 4.18 on EL-8 and EL-9
Finally have to ignore the return value for now

=> 
https://git.remirepo.net/cgit/tools/php-rpminfo.git/commit/?id=9f7298ac633f610af96b0b915e49596bb5520aeb

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/318efbaec80a90f1d9ac76d0cd433f6ea3c103fa#commitcomment-132215177
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: libsodium mass rebuild DONE

[Remi Collet]

Le 05/10/2023 à 08:10, Remi Collet a écrit :

Le 04/10/2023 à 15:43, Remi Collet a écrit :

Hi,

I start working on libsodium update from 1.0.18 to 1.0.19


Mass rebuild started in f40-build-side-75054


23 builds in new update
https://bodhi.fedoraproject.org/updates/FEDORA-2023-9190538ec0

2 packages already FTBFS

0ad
et

2 packages reported as FTBFS

warzone2100 
https://bugzilla.redhat.com/show_bug.cgi?id=2242267

folly
https://bugzilla.redhat.com/show_bug.cgi?id=2242256

folly also affects fbthrift, fizz, mcrouter, wangle

3 packages needs a rebuild in RPMfusion

megasync
qtox
ripcord


Regards,
Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libsodium mass rebuild

[Remi Collet]

Le 04/10/2023 à 15:43, Remi Collet a écrit :

Hi,

I start working on libsodium update from 1.0.18 to 1.0.19


Mass rebuild started in f40-build-side-75054




Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libsodium upcoming update (soname change ?)

[Remi Collet]

Hi,

I start working on libsodium update from 1.0.18 to 1.0.19

Upstream bump the soname from 23 to 26
which means this will only happen in Rawhide

BTW, I don't see any change in API justifying this
https://rpms.remirepo.net/compat_reports/libsodium/1.0.18_to_1.0.19/compat_report.html

So I asked upstream for clarification
https://github.com/jedisct1/libsodium/issues/1317

According to answer I will build new version in a side-tag
with dependencies



Other eyes welcome

Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PHP 8.3 mass rebuild - Done

[Remi Collet]

Le 03/10/2023 à 07:39, Remi Collet a écrit :

Hi,

https://fedoraproject.org/wiki/Changes/php83

Mass rebuild is started in f40-build-side-74920


Mass rebuild is done and update pushed in stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-246a5cdcbe

Single FTBFS (already reported, not related to PHP)
mapserver-8.0.1-6.fc40
https://bugzilla.redhat.com/show_bug.cgi?id=2241706

58 Builds:
php-8.3.0~RC3-2.fc40
libguestfs-1.51.7-2.fc40
libkolabxml-1.2.0-19.fc40
mlt-7.18.0-4.fc40
php-ast-1.1.0-6.fc40
php-facedetect-1.2.0-0.34.20201021git2a8974b.fc40
php-geos-1.0.0-28.fc40
php-libvirt-0.5.7-1.fc40
php-maxminddb-1.11.0-11.fc40
php-pecl-amqp-2.1.0-2.fc40
php-pecl-apcu-5.1.22-6.fc40
php-pecl-apfd-1.0.3-9.fc40
php-pecl-dio-0.2.1-5.fc40
php-pecl-ds-1.4.0-7.fc40
php-pecl-event-3.0.8-5.fc40
php-pecl-fann-1.2.0~RC2-5.fc40
php-pecl-gearman-2.1.0-12.fc40
php-pecl-geoip-1.1.1-24.fc40
php-pecl-gmagick-2.0.6~RC1-10.fc40
php-pecl-http-4.2.4-2.fc40
php-pecl-igbinary-3.2.14-1.fc40
php-pecl-imagick-3.7.0-9.fc40
php-pecl-inotify-3.0.0-9.fc40
php-pecl-ip2location-8.2.0-3.fc40
php-pecl-json-post-1.1.0-9.fc40
php-pecl-krb5-1.1.5-3.fc40
php-pecl-lzf-1.7.0-8.fc40
php-pecl-mailparse-3.1.6-2.fc40
php-pecl-mcrypt-1.0.6-3.fc40
php-pecl-memcache-8.2-3.fc40
php-pecl-memcached-3.2.0-7.fc40
php-pecl-mongodb-1.16.2-2.fc40
php-pecl-msgpack-2.2.0-3.fc40
php-pecl-oauth-2.0.7-13.fc40
php-pecl-pcov-1.0.11-7.fc40
php-pecl-pq-2.2.2-3.fc40
php-pecl-raphf-2.0.1-13.fc40
php-pecl-redis5-5.3.7-6.fc40
php-pecl-rpminfo-0.7.0-2.fc40
php-pecl-rrd-2.0.3-10.fc40
php-pecl-selinux-0.6.0-7.fc40
php-pecl-ssdeep-1.1.0-18.fc40
php-pecl-ssh2-1.4-3.fc40
php-pecl-uopz-7.1.1-9.fc40
php-pecl-uuid-1.2.0-11.fc40
php-pecl-var-representation-0.1.4-4.fc40
php-pecl-xattr-1.4.0-13.fc40
php-pecl-xdebug3-3.3.0~alpha2-1.fc40
php-pecl-xmldiff-1.1.3-9.fc40
php-pecl-xmlrpc-1.0.0~rc3-8.fc40
php-pecl-yac-2.3.1-8.fc40
php-pecl-zip-1.22.2-2.fc40
php-phpiredis-1.0.1-14.fc40
php-smbclient-1.1.1-3.fc40
php-zmq-1.1.3-27.fc40
php-zstd-0.13.1-2.fc40
remctl-3.18-9.fc40
uwsgi-2.0.22-6.fc40


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

PHP 8.3 mass rebuild

[Remi Collet]

Hi,

https://fedoraproject.org/wiki/Changes/php83

Mass rebuild is started in f40-build-side-74920




Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Remi Collet]

Le 26/09/2023 à 19:32, Carlos O'Donell a écrit :


In version 8.3 (F40) we'll includes the UTC definition
in our patch to use system tzdata, UTC being use
as the fallback value.


I'm curious; what does this patch look like?


(trivial) patch to our system tzdata patch attached

In short, if file is missing use bundled content

Full patch for PHP 8.3:
https://git.remirepo.net/cgit/rpms/scl-php83/php.git/plain/php-8.3.0-systzdata-v24.patch

Remi


P.S. IMHO, allowing removal of tzdata for PHP doesn't make any sense
as most app will fail badly (runtime exception) because of missing
TZ when upstream use a bundle copy of the full database, so this can
never happen, so this will create another RPM specific problem
(when upstream is opposed to our change, for years)From db0a54781ce95dbbe7adbf26346322075794a931 Mon Sep 17 00:00:00 2001
From: Remi Collet 
Date: Fri, 22 Sep 2023 15:56:38 +0200
Subject: [PATCH] add internal UTC if tzdata is missing

---
 ext/date/lib/parse_tz.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/ext/date/lib/parse_tz.c b/ext/date/lib/parse_tz.c
index 648d16c12c..ec196a98b6 100644
--- a/ext/date/lib/parse_tz.c
+++ b/ext/date/lib/parse_tz.c
@@ -35,6 +35,17 @@
 
 #include "php_scandir.h"
 
+static const unsigned char internal_utc[] = {
+0x54, 0x5a, 0x69, 0x66, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x55, 0x54, 0x43, 0x00, 0x54, 0x5a, 0x69, 0x66, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
+0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x55, 0x54, 0x43, 0x00, 0x0a, 0x55, 0x54, 0x43,
+0x30, 0x0a
+};
+
 #else
 #define TIMELIB_SUPPORTS_V2DATA
 #define TIMELIB_SUPPORT_SLIM_FILE
@@ -934,6 +945,9 @@ static void create_zone_index(timelib_tzdb *db)
 
 qsort(db_index, index_next, sizeof *db_index, sysdbcmp);
 
+	if (!index_next) {
+		db_index[index_next++].id = strdup("UTC");
+	}
 	db->index = db_index;
 	db->index_size = index_next;
 
@@ -1040,7 +1054,12 @@ static char *map_tzfile(const char *timezone, size_t *length)
 
 	fd = open(fname, O_RDONLY);
 	if (fd == -1) {
-		return NULL;
+		if (strcmp(timezone, "UTC")) {
+			return NULL;
+		} else {
+			*length = sizeof(internal_utc);
+			return internal_utc;
+		}
 	} else if (fstat(fd, ) != 0 || !is_valid_tzfile(, fd)) {
 		close(fd);
 		return NULL;
@@ -,7 +1130,7 @@ const timelib_tzdb *timelib_builtin_db(void)
 	if (timezonedb_system == NULL) {
 		timelib_tzdb *tmp = malloc(sizeof *tmp);
 
-		tmp->version = "0.system";
+		tmp->version = "0";
 		tmp->data = NULL;
 		create_zone_index(tmp);
 		retrieve_zone_version(tmp);
@@ -1144,7 +1163,9 @@ int timelib_timezone_id_is_valid(const char *timezone, const timelib_tzdb *tzdb)
 		if (timezone[0] == '\0' || strstr(timezone, "..") != NULL) {
 			return 0;
 		}
-
+		if (!strcmp(timezone, "UTC")) {
+			return 1;
+		}
 		if (system_location_table) {
 			if (find_zone_info(system_location_table, timezone) != NULL) {
 /* found in cache */
@@ -1274,7 +1295,9 @@ timelib_tzinfo *timelib_parse_tzfile(const char *timezone, const timelib_tzdb *t
 			}
 
 			/* Now done with the mmap segment - discard it. */
-			munmap(memmap, maplen);
+			if (memmap != internal_utc) {
+munmap(memmap, maplen);
+			}
 		} else {
 #endif
 		if (type == TIMELIB_TZINFO_PHP) {
-- 
2.41.0

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Remi Collet]

Le 25/09/2023 à 10:38, Vít Ondruch a écrit :


Dne 22. 09. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a):

On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

This probably answers my question. So heads up to others.

Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):

Was this implemented in past days? I am asking because this FTBFS
suggest so:

https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40

Yes. The change was done in rawhide a while ago, but it got pushed to F39
only recently, see 
https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.



Dealing now with FTBFS rubygem- packages, the change proposal briefly 
mentions: "In June of 2021, we proposed creating a new tzdata 
sub-package that would only provide the UTC timezone.". I assume that 
this have not happened, but I don't remember why and it seems that this 
could be helpful.


We have the same issue with PHP and lot of recent FTBFS

timezone is really mandatory for PHP

In version 8.3 (F40) we'll includes the UTC definition
in our patch to use system tzdata, UTC being use
as the fallback value.

Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

[Remi Collet]

more results on ARM:

RK3399 - Cortex-A7x

Cost 10: 10.694221 total (0.106942 per hash)
Cost 11: 21.360409 total (0.213604 per hash)
Cost 12: 42.692786 total (0.426928 per hash)

RK3399 - Cortex-A5x

Cost 10: 15.146773 total (0.151468 per hash)
Cost 11: 30.272059 total (0.302721 per hash)
Cost 12: 60.607128 total (0.606071 per hash)

Ampere Altra

Cost 10: 6.286994 total (0.062870 per hash)
Cost 11: 13.056349 total (0.130563 per hash)
Cost 12: 25.230312 total (0.252303 per hash)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

[Remi Collet]

Le 21/09/2023 à 19:26, Tim Düsterhus a écrit :

Hi

I just opened the vote for the "Increasing the default BCrypt cost" RFC. 
The RFC contains a two votes, one primary vote that requires a 2/3
majority to pass and a secondary vote deciding on the new costs with a 
simple majority. Voting runs 2 weeks until 2023-10-05 17:45 UTC.


Please find the following resources for your references:


Tested on ARM (Neoverse-N1)

Cost 9: 5.175103 total (0.051751 per hash)
Cost 10: 10.325875 total (0.103259 per hash)
Cost 11: 20.627759 total (0.206278 per hash)
Cost 12: 41.231114 total (0.412311 per hash)
Cost 13: 82.437880 total (0.824379 per hash)
Cost 14: 164.851835 total (1.648518 per hash)


So 11 seems reasonable.

Remi



RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023
Discussion Thread: https://externals.io/message/121004
Feedback by a Hashcat team member on Fediverse: 
https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075


Best regards
Tim Düsterhus



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[Remi Collet]

Le 13/09/2023 à 10:50, Derick Rethans a écrit :

Hi,

In a recent chat between the PHP Foundation developers, we discussed
unbundling several extensions.


ext/imap


+1



ext/pspell


+1


There are other replacements, ispell, and hunspell, but they don't seem
to be compatible API-wise. The PECL extension "enchant" was supposed
to be able to use with all of these, but is also no longer maintained
(last release in 2009, https://pecl.php.net/package/enchant).


Notice that enchant is part of php-src (since 5.3)
and use libenchant v2 which is actively maintained.
Support for v1 is still there and should probably be dropped


ext/oci8


+1


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: F40 Change Proposal:PHP 8.3 (Self Contained)

[Remi Collet]

Le 11/09/2023 à 19:12, Aoife Moloney a écrit :

The discussion thread to provide feedback on this proposed change can be found 
here 
https://discussion.fedoraproject.org/t/f40-change-proposal-php-8-3-self-contained/89611/1


Please don't use above link

Please use this ML for questions/feedback


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The new Change discussion process is painful

[Remi Collet]

Le 13/09/2023 à 08:09, Adam Williamson a écrit :

On Wed, 2023-09-13 at 05:51 +0200, Kevin Kofler via devel wrote:

Hi,

it is really a pain that the Change discussion is now hidden in a web forum
behind a web link, instead of happening right here in this mailing list. It
was promised that Discourse would NOT replace the mailing lists, but that is
effectively no longer the case. Can this "Discourse for Change discussion"
experiment please be stopped? It has no advantages and only adds a useless
layer of indirection.


I don't really understand what you mean. AFAICT, every Change that has
been announced at
https://discussion.fedoraproject.org/c/project/changes/89 has also been
announced at
https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedoraproject.org/
, so nothing has been replaced.


Sadly it seems there is some email issues

For a few days, tons of messages are lost
so, I also don't receive any of the recent change announcements

BTW, I agree this dual channel is terrible for discussion

I personally don't follow discussion.fpo
too much tools kills simplicity


Remi



 From there, it's up to people where they see and respond to them. If
more people are responding in discourse than on the mailing list, that
would seem to suggest that there *is* a reason to announce things
there...

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PHP-DEV] Bad debug build usage

[Remi Collet]

Le 11/09/2023 à 09:20, Remi Collet a écrit :

Hi,


According to https://bugs.php.net/bugs-generating-backtrace.php

 > To get a backtrace with correct information you must have PHP 
configured with --enable-debug!


Perhaps a better wording is

  To get a backtrace with correct information you must have
  a non stripped PHP binary


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Bad debug build usage

[Remi Collet]

Hi,


According to https://bugs.php.net/bugs-generating-backtrace.php

> To get a backtrace with correct information you must have PHP 
configured with --enable-debug!


This seems wrong.

Of course you can use GDB against any build of PHP


Result: for some time, I noticed people asking about issues
in debug build, when they don't need such build.

IMHO, debug builds are for PHP and extensions developers
as this mode add more checks (assert) but is not suitable
for other usages.



Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [rawhide] ICU upgrade to 73.2

[Remi Collet]

Hi,

Le 12/07/2023 à 10:15, Frantisek Zatloukal a écrit :
I'd submitted the side-tag for merging to f39 base: 
https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c 



There are a bunch of packages missing, 


I notice mongo-c-driver 1.24.1-2 is NOT in the update

I just push and update to 1.24.2-1 there,
but not launch any build.

Can you take care of it, or tell me when icu73 will be in buildroot


Thanks,
Remi

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADS UP: Update to geos-3.12.0 in rawhide

[Remi Collet]

Le 06/07/2023 à 15:53, Sandro Mani a écrit :

Hi

I'm updating to geos-3.12.0 in rawhide, which carries a soname bump. I'm 
building geos-3.12.0 in f39-build-side-69654 and will rebuild the 
following dependencies:


osgearth
vfrnav
mingw-osgearth


It seems you miss some,

On Fedora 37

# dnf repoquery --whatrequires 'libgeos_c.so.1()(64bit)'
GMT-0:6.4.0-2.fc37.x86_64
R-rgeos-0:0.5.9-1.fc37.x86_64
gdal-libs-0:3.5.2-1.fc37.x86_64
geos-devel-0:3.11.0-2.fc37.x86_64
grass-0:8.2.1-1.fc37.x86_64
grass-libs-0:8.2.1-1.fc37.x86_64
librttopo-0:1.1.0-10.fc37.x86_64
libspatialite-0:5.0.1-15.fc37.x86_64
mapserver-libs-0:7.6.4-19.fc37.x86_64
osgearth-0:3.2-10.fc37.x86_64
php-geos-0:1.0.0-24.fc37.x86_64
player-0:3.1.0-41.fc37.x86_64
postgis-0:3.2.2-1.fc37.x86_64
postgis-client-0:3.2.2-1.fc37.x86_64
postgis-gui-0:3.2.2-1.fc37.x86_64
postgis-upgrade-0:3.2.2-1.fc37.x86_64
python3-basemap-0:1.3.7-1.fc37.x86_64
python3-cartopy-0:0.21.1-1.fc37.x86_64
python3-shapely-0:1.8.5.post1-1.fc37.x86_64
qgis-0:3.26.1-2.fc37.x86_64
spatialite-gui-0:2.1.0-0.14.beta1.fc37.x86_64


Remi

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Something for a python maintainer for nihtest

[Remi Collet]

Hi,

libzip have switch from old perl test suite
to a new python based one using nihtest

https://github.com/nih-at/nihtest
https://pypi.org/project/nihtest/


As I don't want to dig in python packaging
and as there is probably enough python guys here
is there is one king enough to look at this one ?

libzip may be updated to 1.10.0 without this,
but without its test suite, which seems a bad idea


Thanks
Remi


P.S. of course I may try to help, after initial
packaging to update to newer version when needed
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[PHP-WEBMASTER] [web-php] master: add CVE in ChangeLog

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2023-06-22T08:10:49+02:00

Commit: 
https://github.com/php/web-php/commit/8a48cca42f48b6d13d6b03b25ac38132c271c6c0
Raw diff: 
https://github.com/php/web-php/commit/8a48cca42f48b6d13d6b03b25ac38132c271c6c0.diff

add CVE in ChangeLog

Changed paths:
  M  ChangeLog-8.php


Diff:

diff --git a/ChangeLog-8.php b/ChangeLog-8.php
index 66d642039..b3401c397 100644
--- a/ChangeLog-8.php
+++ b/ChangeLog-8.php
@@ -66,7 +66,7 @@
 
 Soap:
 
-  Fixed bug GHSA-76gg-c692-v2mw (Missing error check and insufficient 
random bytes in HTTP Digest authentication for SOAP).
+  Fixed bug GHSA-76gg-c692-v2mw (Missing error check and insufficient 
random bytes in HTTP Digest authentication for SOAP). (CVE-2023-3247)
   Fixed bug  (make test fail 
while soap extension build).
 
 SPL:
@@ -890,7 +890,7 @@
 
 Soap:
 
-  Fixed bug GHSA-76gg-c692-v2mw (Missing error check and insufficient 
random bytes in HTTP Digest authentication for SOAP).
+  Fixed bug GHSA-76gg-c692-v2mw (Missing error check and insufficient 
random bytes in HTTP Digest authentication for SOAP). (CVE-2023-3247)
   Fixed bug  (make test fail 
while soap extension build).
 
 SPL:
@@ -2285,7 +2285,7 @@
 
 Soap:
 
-  Fixed bug GHSA-76gg-c692-v2mw (Missing error check and insufficient 
random bytes in HTTP Digest authentication for SOAP).
+  Fixed bug GHSA-76gg-c692-v2mw (Missing error check and insufficient 
random bytes in HTTP Digest authentication for SOAP). (CVE-2023-3247)
 
 
 

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Modules without MBS

[Remi Collet]

Le 13/06/2023 à 18:32, Petr Pisar a écrit :

Hello,

as it seems that module build infrastructure isn't getting any better, as
modular YUM repositories are going to be deconfigured
,
there is a time to look at different ways how to package alternative content.


Another way/proposal

Keep "modularity", but drop MBS

1/ create a stream package which defines few needed stuff

mostly
- %dist => .module+name+stream.distro
- %modularitylabel

and possibly the .yaml template

2/ modify createrepo

so all the packages with modularitylabel=name:stream:*
are be part of name:stream module


Done.

And we have something which works and have been heavily tested

Yes this is a 1 level only modularity.



P.S. §1 is what MBS does somehow magically
and packager know what to build, in which order,
something that MBS also try to magically compute
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modules without modularity

[Remi Collet]

Le 14/06/2023 à 14:14, Petr Pisar a écrit :

V Wed, Jun 14, 2023 at 10:19:27AM +0200, Remi Collet napsal(a):

Your approach will move complexity back to packagers.


Yes. That's because the problem has a complexity and the complexity needs to
live somewhere. With modularity it was in MBS and in modular filtering part of
DNF.


For memory, all RPMs (even modular ones) are build with rpmbuild ;)
mbs is only the "common" way, but not the "simple" way to build modular 
packages ;)




An extension of the stack will require the specific stream (build and run)



The extension can add build- and run-time dependenices on packages from that
stream. However, that will effectively make the extension part of the stream.
In that case a maintainer of the extension should including it into the
stream. That, by a the proposed recommendations, would change an RPM name of
the extension. I guess that Fedora would insist on this name change as
Fedora's packaging guidelines now insist on nonmodular packages to only depend
on nonmodular content.


Yes, make sense
I was thinking of all C extensions (php-pecl-* and some other)
which have a dependency on php(zend-abi) which is related to
version, and possibly build options (nts, zts, debug...)



On the other hand, I can imagine that packages (especially top-level
applications) which are not a logical part of any specific stream but depends
on that nondefault stream, will retain its original name and simply users will
have to switch the stream with "--allowerasing". It's the fragmentation of
well-integrated Fedora Christopher (?) wrote in this thread. In his eyes there
is no need for applications like that.


Yes, for now we use dependency on php(language)
Usually we only require for minimal version (ex: php(language) >= 8.0)
but sometime range dependency make sense
(ex: roundcubemail which explicitly have a test for maximal version)


BTW, my preferred solution: keep building real modular packages ;)
don't reinvent the wheel.
In all cases, Fedora community won't like it.



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modules without modularity

[Remi Collet]

Hi,

Le 13/06/2023 à 18:32, Petr Pisar a écrit :


I spent some time thinking how to approximate the nice features with current
state of RPM, Koji, and DNF and come up with this approach
. 


First thanks for your work on this

I also thinking a lot about this, and this is a nightmare

I must say that I'm terribly sad we have to reinvent the wheel.

I'm still a big fan of SCL and I still build them for Fedora
to be able to install multiple versions simultaneously

# LANG=C dnf list php??
Installed Packages
php74.x86_64 7.4-3.fc37.remi
php80.x86_64 8.0-3.fc37.remi
php81.x86_64 8.1-4.fc37.remi
php82.x86_64 8.2-5.fc37.remi
php83.x86_64 8.3-1.fc37.remi

Complexity is for packagers and users.

I'm also a big fan of modules.
It just works well.

# dnf module list php
Remi's Modular repository - Fedora 37 - x86_64
Name Stream   Profiles   Summary 


php  remi-7.4 common [d], devel, minimal PHP
php  remi-8.0 common [d], devel, minimal PHP
php  remi-8.1 [e] common [d], devel, minimal PHP
php  remi-8.2 common [d], devel, minimal PHP

Complexity is only for build system.

I will probably never understand hostility from the community
against this (bad feeling because of initial broken implementation ?)

Perhaps Fedora, with its very short life, don't really needs alternative
versions, while a long life distro obviously needs it.

Your approach will move complexity back to packagers.

I'm also very concerned by the "vendor" approach

It seems possible using some stream---
(or  being  vendor-number, as with module)

It seems also need to manage dependency with a stack or with a specific 
stream.


Ex:
An application will require the default stack (build and run)
An extension of the stack will require the specific stream (build and run)

What about CI ?

An application will be build will one stream (default)
but we probably need to test it with all available streams.

And perhaps have to use (because not compatible with 3)
Requires: (stream-stack-default or stream-stack-2)


What about reviews ?

If I want to create  stream-stack-3, with 100 packages ?

For now, there is a review exception for compatibility packages
for "older" version, but not for newer version.



Only my initial comments

Regards,
Remi


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaning Laminas framework

[Remi Collet]

Hi,

I have orphaned the Laminas packages and few others
This will break some doctrine and symfony packages


Remi



P.S. List (probably more later)

php-doctrine-migrations
php-friendsofphp-proxy-manager-lts
php-laminas-authentication
php-laminas-barcode
php-laminas-cache
php-laminas-captcha
php-laminas-cli
php-laminas-code
php-laminas-code4
php-laminas-config
php-laminas-config3
php-laminas-console
php-laminas-crypt
php-laminas-db
php-laminas-di
php-laminas-di3
php-laminas-diactoros
php-laminas-diactoros2
php-laminas-diagnostics
php-laminas-dom
php-laminas-escaper
php-laminas-eventmanager
php-laminas-feed
php-laminas-file
php-laminas-filter
php-laminas-form
php-laminas-form3
php-laminas-http
php-laminas-httphandlerrunner
php-laminas-hydrator
php-laminas-hydrator3
php-laminas-hydrator4
php-laminas-i18n
php-laminas-i18n-resources
php-laminas-inputfilter
php-laminas-json
php-laminas-json-server
php-laminas-ldap
php-laminas-loader
php-laminas-log
php-laminas-mail
php-laminas-math
php-laminas-memory
php-laminas-mime
php-laminas-modulemanager
php-laminas-mvc
php-laminas-mvc-console
php-laminas-mvc-form
php-laminas-mvc-i18n
php-laminas-mvc-middleware
php-laminas-mvc-plugin-fileprg
php-laminas-mvc-plugin-flashmessenger
php-laminas-mvc-plugin-identity
php-laminas-mvc-plugin-prg
php-laminas-mvc-plugins
php-laminas-navigation
php-laminas-paginator
php-laminas-permissions-acl
php-laminas-permissions-rbac
php-laminas-progressbar
php-laminas-psr7bridge
php-laminas-recaptcha
php-laminas-router
php-laminas-serializer
php-laminas-server
php-laminas-servicemanager
php-laminas-servicemanager-di
php-laminas-session
php-laminas-soap
php-laminas-stdlib
php-laminas-stratigility
php-laminas-tag
php-laminas-test
php-laminas-text
php-laminas-uri
php-laminas-validator
php-laminas-view
php-laminas-xml
php-laminas-xml2json
php-laminas-xmlrpc
php-laminas-zendframework-bridge
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

EPEL-9 terrible updates (dav1d, libavif...)

[Remi Collet]

It looks like EPEL-9 is managed like rawhide.


1/ dav1d 1.0.0 update (also in F37)

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-40bb8ce9c5

This introduce a soname change breaking lot of stuff
including libavif (from EPEL) and packages in RPMFusion

2/ libavif 0.11.1 update (only in Rawhide)

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-385df27ee1

This fix the issue with libdav1d, but introduce another soname bump


This is a real nightmare.

** Please, manage EPEL-9 like a "stable" branch. **

soname change should be avoid,
if not possible (security exception ?) should be properly managed
and, at least, announced


/me is disappointed


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Change update - Missing identifier for XDebug

[Remi Collet]

Le 10/11/2022 à 13:48, Miroslav Suchý a écrit :

Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):



What is the process to ask for a new SPDX id ?


Open an issue for

https://gitlab.com/fedora/legal/fedora-license-data


Done as https://gitlab.com/fedora/legal/fedora-license-data/-/issues/95



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Change update - Missing identifier for XDebug

[Remi Collet]

I'm searching for License identifier for php-pecl-xdebug
which was "BSD"

It is based on PHP-3.0 which is based on BSD-3-Clause

What should I use ?
What is the process to ask for a new SPDX id ?


Thanks,
Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PHP version 8.2 mass rebuild - Done

[Remi Collet]

Le 05/10/2022 à 08:03, Remi Collet a écrit :

Hi,

https://fedoraproject.org/wiki/Changes/php82

As the feature is approved by Fesco
I start working on the mass rebuild

Will use the f38-build-side-58889 side tag


Mass rebuild done
=> https://bodhi.fedoraproject.org/updates/FEDORA-2022-69f3d6aa4a

Retired: php-pecl-couchbase3

version 3 is not compatible, need version 4, not (yet) packaged.


Remi


P.S. build list:

php-8.2.0~RC3-1.fc38
graphviz-6.0.1-2.fc38
libguestfs-1.49.4-2.fc38
libkolabxml-1.2.0-13.fc38
mapserver-8.0.0-2.fc38
mlt-7.8.0-3.fc38
php-ast-1.1.0-2.fc38
php-facedetect-1.2.0-0.28.20201021git2a8974b.fc38
php-geos-1.0.0-25.fc38
php-libvirt-0.5.6-3.fc38
php-maxminddb-1.11.0-6.fc38
php-pecl-amqp-1.11.0-4.fc38
php-pecl-apcu-5.1.22-3.fc38
php-pecl-apfd-1.0.3-5.fc38
php-pecl-dio-0.2.0-9.fc38
php-pecl-ds-1.4.0-4.fc38
php-pecl-event-3.0.7-3.fc38
php-pecl-fann-1.2.0~RC1-4.fc38
php-pecl-gearman-2.1.0-8.fc38
php-pecl-geoip-1.1.1-20.fc38
php-pecl-gmagick-2.0.6~RC1-6.fc38
php-pecl-http-4.2.3-5.fc38
php-pecl-igbinary-3.2.7-4.fc38
php-pecl-imagick-3.7.0-5.fc38
php-pecl-inotify-3.0.0-6.fc38
php-pecl-ip2location-8.1.1-8.fc38
php-pecl-json-post-1.1.0-5.fc38
php-pecl-krb5-1.1.4-9.fc38
php-pecl-lzf-1.7.0-4.fc38
php-pecl-mailparse-3.1.4-2.fc38
php-pecl-mcrypt-1.0.5-3.fc38
php-pecl-memcache-8.0-6.fc38
php-pecl-memcached-3.2.0-3.fc38
php-pecl-mongodb-1.14.1-2.fc38
php-pecl-msgpack-2.2.0~RC1-4.fc38
php-pecl-oauth-2.0.7-9.fc38
php-pecl-pcov-1.0.11-4.fc38
php-pecl-pq-2.2.0-5.fc38
php-pecl-raphf-2.0.1-10.fc38
php-pecl-redis5-5.3.7-3.fc38
php-pecl-rpminfo-0.6.0-6.fc38
php-pecl-rrd-2.0.3-6.fc38
php-pecl-selinux-0.6.0-4.fc38
php-pecl-ssdeep-1.1.0-15.fc38
php-pecl-ssh2-1.3.1-6.fc38
php-pecl-uopz-7.1.1-6.fc38
php-pecl-uuid-1.2.0-8.fc38
php-pecl-var-representation-0.1.2-2.fc38
php-pecl-xattr-1.4.0-9.fc38
php-pecl-xdebug3-3.2.0~alpha3-1.fc38
php-pecl-xmldiff-1.1.3-6.fc38
php-pecl-xmlrpc-1.0.0~rc3-4.fc38
php-pecl-yac-2.3.1-4.fc38
php-pecl-yaml-2.2.2-5.fc38
php-pecl-zip-1.21.1-2.fc38
php-phpiredis-1.0.1-10.fc38
php-smbclient-1.0.6-7.fc38
php-zmq-1.1.3-23.fc38
php-zstd-0.11.0-5.fc38
remctl-3.18-3.fc38
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

PHP version 8.2 mass rebuild

[Remi Collet]

Hi,

https://fedoraproject.org/wiki/Changes/php82

As the feature is approved by Fesco
I start working on the mass rebuild

Will use the f38-build-side-58889 side tag

Please ping me on IRC or by mail if something
special needed for one of your packages.


Remi


P.S.: dnf repoquery --whatrequires 'php(api)'
mlt-php-0:7.8.0-2.fc37.x86_64
php-ast-0:1.1.0-1.fc38.x86_64
php-facedetect-0:1.2.0-0.27.20201021git2a8974b.fc37.x86_64
php-geos-0:1.0.0-24.fc37.x86_64
php-kolabformat-0:1.2.0-12.fc37.x86_64
php-libguestfs-1:1.49.4-1.fc37.x86_64
php-libvirt-0:0.5.6-2.fc37.x86_64
php-mapserver-0:8.0.0-1.fc38.x86_64
php-maxminddb-0:1.11.0-5.fc37.x86_64
php-pecl-amqp-0:1.11.0-3.fc37.x86_64
php-pecl-apcu-0:5.1.22-2.fc38.x86_64
php-pecl-apfd-0:1.0.3-4.fc37.x86_64
php-pecl-couchbase3-0:3.2.1-4.fc37.x86_64
php-pecl-dio-0:0.2.0-8.fc37.x86_64
php-pecl-ds-0:1.4.0-3.fc37.x86_64
php-pecl-event-0:3.0.7-2.fc37.x86_64
php-pecl-fann-0:1.2.0~RC1-3.fc37.x86_64
php-pecl-gearman-0:2.1.0-7.fc37.x86_64
php-pecl-geoip-0:1.1.1-19.fc37.x86_64
php-pecl-gmagick-0:2.0.6~RC1-5.fc37.x86_64
php-pecl-http-0:4.2.3-4.fc38.x86_64
php-pecl-igbinary-0:3.2.7-3.fc37.x86_64
php-pecl-imagick-0:3.7.0-4.fc38.x86_64
php-pecl-inotify-0:3.0.0-5.fc37.x86_64
php-pecl-ip2location-0:8.1.1-7.fc37.x86_64
php-pecl-json-post-0:1.1.0-4.fc37.x86_64
php-pecl-krb5-0:1.1.4-8.fc37.x86_64
php-pecl-lzf-0:1.7.0-3.fc37.x86_64
php-pecl-mailparse-0:3.1.4-1.fc38.x86_64
php-pecl-mcrypt-0:1.0.5-2.fc37.x86_64
php-pecl-memcache-0:8.0-5.fc37.x86_64
php-pecl-memcached-0:3.2.0-2.fc37.x86_64
php-pecl-mongodb-0:1.14.1-1.fc38.x86_64
php-pecl-msgpack-0:2.2.0~RC1-3.fc37.x86_64
php-pecl-oauth-0:2.0.7-8.fc38.x86_64
php-pecl-pcov-0:1.0.11-3.fc37.x86_64
php-pecl-pq-0:2.2.0-4.fc37.x86_64
php-pecl-raphf-0:2.0.1-9.fc37.x86_64
php-pecl-redis5-0:5.3.7-2.fc37.x86_64
php-pecl-rpminfo-0:0.6.0-5.fc37.x86_64
php-pecl-rrd-0:2.0.3-5.fc37.x86_64
php-pecl-selinux-0:0.6.0-3.fc37.x86_64
php-pecl-ssdeep-0:1.1.0-14.fc37.x86_64
php-pecl-ssh2-0:1.3.1-5.fc37.x86_64
php-pecl-uopz-0:7.1.1-5.fc37.x86_64
php-pecl-uuid-0:1.2.0-7.fc37.x86_64
php-pecl-var-representation-0:0.1.2-1.fc38.x86_64
php-pecl-xattr-0:1.4.0-8.fc37.x86_64
php-pecl-xdebug3-0:3.1.5-2.fc37.x86_64
php-pecl-xmldiff-0:1.1.3-5.fc37.x86_64
php-pecl-xmlrpc-0:1.0.0~rc3-3.fc37.x86_64
php-pecl-yac-0:2.3.1-3.fc37.x86_64
php-pecl-yaml-0:2.2.2-4.fc37.x86_64
php-pecl-zip-0:1.21.1-1.fc38.x86_64
php-phpiredis-0:1.0.1-9.fc37.x86_64
php-smbclient-0:1.0.6-6.fc37.x86_64
php-zmq-0:1.1.3-22.fc37.x86_64
php-zstd-0:0.11.0-4.fc37.x86_64
remctl-php-0:3.18-2.fc37.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[PHP-WEBMASTER] [web-php] master: add missing CVEs

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2022-09-30T09:12:35+02:00

Commit: 
https://github.com/php/web-php/commit/e1aab133e05732fddae4cb8a2135344e1a64566f
Raw diff: 
https://github.com/php/web-php/commit/e1aab133e05732fddae4cb8a2135344e1a64566f.diff

add missing CVEs

Changed paths:
  M  ChangeLog-8.php


Diff:

diff --git a/ChangeLog-8.php b/ChangeLog-8.php
index f951e1231..6f890fd7b 100644
--- a/ChangeLog-8.php
+++ b/ChangeLog-8.php
@@ -914,7 +914,7 @@
   Fixed bug  (Crash in 
ZEND_RETURN/GC/zend_call_function) (Tim Starling)
   Fixed bug  (Segmentation 
fault on script exit #9379).
   Fixed bug  (LSP error in 
eval'd code refers to wrong class for static type).
-  Fix #81727 (Don't mangle semantically meaningful HTTP var names).
+  : Don't mangle HTTP variable names that clash 
with ones that have a specific semantic meaning. (CVE-2022-31629)
 
 DOM:
 
@@ -935,7 +935,7 @@
 
 Phar:
 
-  Fix #81726 (DOS when using quine gzip file).
+  : phar wrapper: DOS when using quine gzip file. 
(CVE-2022-31628)
 
 PDO_PGSQL:
 

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PECL-DEV] Maintenance of the scrypt extension

[Remi Collet]

Le 13/07/2022 à 14:39, Máté Kocsis a écrit :

Hi All,

I'm writing here because the scrypt extension (
https://pecl.php.net/package/scrypt) is apparently unmaintained since a
long time. I filed https://github.com/DomBlack/php-scrypt/issues/62 asking
for releasing PHP 8 support around 1.5 months ago, but I got no response
from the maintainer.

As I'm relying on this extension heavily, I'd like to continue
its maintenance. That's why I forked the repo and made a few "cosmetic"
changes which are in line with the conventions used in PHP 8.0+ (properly
declared param and return types, exceptions instead of fatal errors, better
error messages).

So my question is how I could make my version of scrypt available in PECL?
Could we upload it as scrypt2 or is there a better alternative?


Or simply take ownership of this extension on pecl and move to new sources.

Especially if no answer from Dominic.


Remi



Regards,
Máté Kocsis



--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-WEBMASTER] [web-php] master: drop entry for reverted fix

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2022-07-08T07:27:58+02:00

Commit: 
https://github.com/php/web-php/commit/22ea1e2e6f6569e040ad92445c7a20749a2b0bd0
Raw diff: 
https://github.com/php/web-php/commit/22ea1e2e6f6569e040ad92445c7a20749a2b0bd0.diff

drop entry for reverted fix

Changed paths:
  M  ChangeLog-8.php


Diff:

diff --git a/ChangeLog-8.php b/ChangeLog-8.php
index 71121b2bc..a8a95ba48 100644
--- a/ChangeLog-8.php
+++ b/ChangeLog-8.php
@@ -74,10 +74,6 @@
 
   Fixed handling of single-key connection strings.
 
-SPL:
-
-  Fixed bug  (Different results 
for seek() on SplFileObject and SplTempFileObject).
-
 Zip:
 
   Fixed bug  (ZipArchive::close 
deletes zip file without updating stat cache).

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP-8.1 branch seems broken

[Remi Collet]

Hi,

In PHP 8.1:

This branch is 1 commit ahead, 7 commits behind master.


This seems terribly wrong, looks like was merged from master
(NEWS file have 8.2 entries)


Can some GIT expert check and fix that ?


Regards,
Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-WEBMASTER] [web-php] master: refresh keyring

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2022-05-25T10:05:02+02:00

Commit: 
https://github.com/php/web-php/commit/1af2d1a4408c7519964a3626e3c5aeeef9648303
Raw diff: 
https://github.com/php/web-php/commit/1af2d1a4408c7519964a3626e3c5aeeef9648303.diff

refresh keyring

Changed paths:
  M  distributions


Diff:

diff --git a/distributions b/distributions
index bad4feb59..efc4b726e 16
--- a/distributions
+++ b/distributions
@@ -1 +1 @@
-Subproject commit bad4feb5924b2efdfa09b687afb264e98b077ed8
+Subproject commit efc4b726e98cd02d37c5b8c2e91a39304db23fd6

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [8.2] Release Manager Election

[Remi Collet]

Le 18/05/2022 à 20:45, Ben Ramsey a écrit :


Our 8.2 “rookie” release managers are:

* Sergey Panteleev
* Pierrick Charron



Congrats to Sergei and Pierrick!


Do you have a twitter account ?


Cheers,
Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: Question about Fedora Package Naming

[Remi Collet]

Le 19/02/2022 à 13:58, Hirotaka Wakabayashi via devel a écrit :

Hello, I have a question about Fedora Package Naming.

php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version 
by upstream. The latest version is 7.4.1.
https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzle 

https://github.com/guzzle/guzzle#version-guidance 



In this situation, if I want to package the 7.4.1. version, should the 
package name be php-guzzlehttp-guzzle7? Or should I submit a patch to 
change the php-guzzlehttp-guzzle version? I think php-guzzlehttp-guzzle 
should be upgraded because EOL products potentially contain security 
issues, but most users probably doesn't know the package is EOL or not 
when they install it.


Notice: PHP libraries usually follow semver, so major version means
breaking changes. i.e. v5, v6 and v7 are not compatible.

For guzzle, we have

php-guzzlehttp-guzzle6 version 6.5.5
php-guzzlehttp-guzzle  version 5.3.4
php-guzzle-Guzzle  version 3.9.3 (retired)

IMHO, we should always use version in name
even if the package name doesn't really matter as we should
always use virtual provides, php-composer(guzzlehttp/guzzle) and range 
dependencies.


OK, I know Fedora policy prefers to create "compat" packages
for old versions, but this is a nightmare to maintain as each
update will break everything

if "php-foo" provides a library v1 in /usr/share/php/Foo
a major update will break other packages

creating a compat "php-foo1" in /usr/share/php/Foo1
won't help (other package will have to be fixed)

keeping the compat "php-foo1" in /usr/share/php/Foo
and update the "php-foo" to use /usr/share/php/Foo2
may work, but is really confusing.

BTW I start thinking using system libraries in PHP app
was a interesting adventure, but it also means fightning with
php and composer usage, where everything is bundled in each project.

In the near future a lot of PHP system libraries are going to
be removed from Fedora repository because of fail to build or
fail to install. And there is not enough maintainers to fix them.
(I'm working on building a list I will post on "php-devel" ML)

To be clear nobody uses PHP system libraries directly.

Users needs app (composer, phpMyAdmin, nextcloud, wordpress...)

Developers only use composer to install project dependencies
in the project directory.

As I already said elsewhere, I'm sad, but I'm tired to fight
with PHP projects which don't care of system wide installation
and don't support them, and don't want them, and to fight with
Fedora which don't care of the PHP stack.


Remi





Regards,
Hirotaka


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Tracked as https://bugzilla.redhat.com/show_bug.cgi?id=2048565
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Hi,

Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :
That error means that there is difference in the target attribute or 
#pragma

GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.


Command is

$ gcc -IZend/ -I/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/ 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/include 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/main 
-I/home/remi/rpmbuild/BUILD/php-8.1.2 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/date/lib 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/date/lib 
-I/usr/include/libxml2 -I/usr/include/enchant-2 -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 
-I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/mbstring/libmbfl 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/mbstring/libmbfl 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/ext/mbstring/libmbfl/mbfl 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ext/mbstring/libmbfl/mbfl 
-I/usr/include/pspell -I/usr/include/editline 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/TSRM 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/Zend 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/main 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/Zend 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/TSRM 
-I/home/remi/rpmbuild/BUILD/php-8.1.2/build-cgi/ -fno-common 
-Wstrict-prototypes -Wformat-truncation -Wlogical-op -Wduplicated-cond 
-Wno-clobbered -Wall -Wextra -Wno-strict-aliasing -Wno-unused-parameter 
-Wno-sign-compare -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables 
-fstack-clash-protection -fno-strict-aliasing -Wno-pointer-sign 
-fvisibility=hidden -Wimplicit-fallthrough=1 -DZEND_SIGNALS 
-DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -c 
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c -MMD -MF 
Zend/zend_execute.dep -MT Zend/zend_execute.lo -fPIC -DPIC -o 
Zend/.libs/zend_execute.o

In file included from /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend.h:36,
from /home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c:26:
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_variables.h: In function 
‘ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER’:
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
inlining failed in call to ‘always_inline’ ‘zval_ptr_dtor_nogc’: target 
specific option mismatch

32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
| ^~
In file included from 
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/home/remi/rpmbuild/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: 
called from here

8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
| ^~~

preprocessed sources:

https://server.famillecollet.com/nextcloud/s/6txXHtdnGYfnC37/download?path=%2F=pre.txt.bz2



Any help welcome, as I really don't see what is wrong there

Remi





Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :

On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:

Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :

gcc 12 snapshot has landed as the system compiler into rawhide today.


PHP is now FTBFS on s390x only
https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437


Any help welcome,
Remi


P.S. from build.log


/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: inlining
failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
option mismatch
32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
   |^~
In file included from
/builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
from here
  8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
   | ^~~


That error means that there is difference in the target attribute or #pragma
GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.


Still failing with 12.0.1-0.2 recently built on rawhide

Trying to disabled the always_inline don't solves the problem
(same issue with memcpy call)

Sorry, but I have no idea how to check the "target" used
can't find anything in the source code
and don't have (simple) access to s390x computer


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

[Remi Collet]

Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :

Hi!

gcc 12 snapshot has landed as the system compiler into rawhide today.


PHP is now FTBFS on s390x only
https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437


Any help welcome,
Remi


P.S. from build.log


/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function 
'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
inlining failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target 
specific option mismatch

   32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
  |^~
In file included from 
/builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: 
called from here

 8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
  | ^~~
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: hiredis soname bump

[Remi Collet]

Le 18/01/2022 à 02:53, Kevin Fenzi a écrit :

ok, so I made the sidetag (f36-build-side-49618) and rebuilt things,
but of course now there's 4 more erroring packages (I guess due to gcc12?).
Any help welcomed. :)


php-phpiredis is also broken, but sadly not detected during the build

I open a upstream PR to fix this and run a new build


Cheers,
Remi




P.S. minimal test is broken with recent change in PHP :(


+ : Minimal load test for NTS extension
+ /usr/bin/php --no-php-ini --define 
extension=/builddir/build/BUILDROOT/php-phpiredis-1.0.1-6.fc36.arm/usr/lib/php/modules/phpiredis.so 
--modules

+ grep phpiredis
Warning: PHP Startup: Unable to load dynamic library 
'/builddir/build/BUILDROOT/php-phpiredis-1.0.1-6.fc36.arm/usr/lib/php/modules/phpiredis.so' 
(tried: 
/builddir/build/BUILDROOT/php-phpiredis-1.0.1-6.fc36.arm/usr/lib/php/modules/phpiredis.so 
(/builddir/build/BUILDROOT/php-phpiredis-1.0.1-6.fc36.arm/usr/lib/php/modules/phpiredis.so: 
undefined symbol: redisReplyReaderGetError), 
/usr/lib/php/modules//builddir/build/BUILDROOT/php-phpiredis-1.0.1-6.fc36.arm/usr/lib/php/modules/phpiredis.so.so 
(/usr/lib/php/modules//builddir/build/BUILDROOT/php-phpiredis-1.0.1-6.fc36.arm/usr/lib/php/modules/phpiredis.so.so: 
cannot open shared object file: No such file or directory)) in Unknown 
on line 0



This is also fixed (stricter grep pattern)

+ : Minimal load test for NTS extension
+ /usr/bin/php --no-php-ini --define 
extension=/dev/shm/BUILDROOT/php-phpiredis-1.0.1-4.fc35.remi.8.0.x86_64/usr/lib64/php/modules/phpiredis.so 
--modules

+ grep '^phpiredis$'
phpiredis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [PHP-DEV] how to add annotations to an extension function

[Remi Collet]

Le 12/01/2022 à 11:28, Brett McBride a écrit :

Hello,
I'm pretty stuck, trying to make an existing PHP extension
(google/protobuf) compatible with php 8.1 [1] whilst retaining
backwards-compatibility (ideally back to 7.0, but that might be
negotiable). I'm not a C programmer, and definitely not a PHP extension
developer.
Some methods in the extension implement Iterator and ArrayAccess, and with
8.1 show deprecation notices, eg:

Deprecated: Return type
of Google\Protobuf\Internal\RepeatedField::offsetGet($index) should either
be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the
#[\ReturnTypeWillChange] attribute should be used to temporarily
suppress the notice in Unknown on line 0

Given that the mixed type is new, I know I can't add it directly as a
return type without breaking BC, so my next thought was that I could try to
find a method that can create an annotation, and conditionally add it. On
php-general, I was pointed at the "zend_add_attribute" method, and I am
hopeful that something like this might work, if I knew how to call the
method:


See the ZEND_BEGIN_ARG_WITH_TENTATIVE_RETURN_* macros
used to declare the method arginfo

Ex: 
https://github.com/php-kafka/php-simple-kafka-client/blob/main/metadata_collection.stub.php


used to generate

https://github.com/php-kafka/php-simple-kafka-client/blob/main/metadata_collection_arginfo.h

And with compatibility hack for older version

https://github.com/php-kafka/php-simple-kafka-client/blob/main/metadata_collection.c#L44


Cheers,
Remi



#if PHP_VERSION >= 80100
zend_add_attribute("returntypewillchange")
#endif

Failing that, I'm after any guidance on whether anybody thinks this can be
done, or a pointer to some prior art I can borrow heavily from would be
amazing!

Thanks in advance.

[1] 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Drop support for libmysql with mysqli

[Remi Collet]

Le 24/12/2021 à 18:32, Kamil Tekiela a écrit :

Hi Internals,

I would like to propose dropping support for libmysql from mysqli and ask
for opinions on how this could be best achieved.


+1 to drop support for libmysql.

Simply do it in the next version "8.2"
will be in version documentation announcement



Remi


P.S. one more point, IIRC License is not compatible
with php one (GPL) despite there is a FOSS exception
for Linux.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: Non-responsive maintainer hubbitus (Pavel Alexeev)

[Remi Collet]

Le 21/12/2021 à 15:47, Remi Collet a écrit :

Hi,

Pavel is non responsive for a while

Already managed 4 years ago
https://pagure.io/fesco/issue/1758


I've been maintaining for a while

- php-pecl-gmagick
- php-pecl-imagick
- php-pecl-xmldiff

Do you I need to follow the full workflow,
or a fesco ticket is enough ?


Non-responsive maintainer bugs

php-pecl-imagick https://bugzilla.redhat.com/show_bug.cgi?id=2034917
php-pecl-gmagick https://bugzilla.redhat.com/show_bug.cgi?id=2034918
php-pecl-xmldiff https://bugzilla.redhat.com/show_bug.cgi?id=2034916
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Non-responsive maintainer hubbitus (Pavel Alexeev)

[Remi Collet]

Hi,

Pavel is non responsive for a while

Already managed 4 years ago
https://pagure.io/fesco/issue/1758


I've been maintaining for a while

- php-pecl-gmagick
- php-pecl-imagick
- php-pecl-xmldiff

Do you I need to follow the full workflow,
or a fesco ticket is enough ?



Regards,
Remi

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Non-responsive maintainer check for kaigai

[Remi Collet]

Hi,

This is a non-responsive maintainer check for kaigai

I've been maintaining php-pecl-selinux for a while
and I've also taken upstream lead developement for it
See https://pecl.php.net/package/selinux

Filed a bug for EPEL-9 branch
https://bugzilla.redhat.com/show_bug.cgi?id=2030545

Filed a bug for Non-responsive maintainer
https://bugzilla.redhat.com/show_bug.cgi?id=2034627

Also emailed kaigai about this.


Does anyone know how to contact kaigai?
Direct email and bug reports have had no response.

Thanks and regards,

Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange build chain issue (GCC ?)

[Remi Collet]

Le 19/11/2021 à 11:39, Mamoru TASAKA a écrit :


Related source code on libraqm:
https://github.com/HOST-Oman/libraqm/blob/master/src/raqm.c#L1726

So with HAVE_FT_GET_TRANSFORM defined, libraqm is doing some
"transformation", perhaps some rotation of something.



Confirmed and reported https://github.com/HOST-Oman/libraqm/issues/141

Great thanks for the help, I miss this condition...


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Strange build chain issue (GCC ?)

[Remi Collet]

This first affects libraqm, and so its users
so libgd
so php

Initial report https://github.com/libgd/libgd/issues/790
Tracked as https://bugzilla.redhat.com/show_bug.cgi?id=2022957


In short
libraqm is broken on F35
same version works as expected on F34
F34 version works on F35

So, really looks like a build issue


Any idea help welcome


Remi


P.S. I temporarily disable libraqm usage from gd to
workaround this issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Plan for EPEL-9

[Remi Collet]

As both RHEL-9 Beta and CentOS 9 Stream are available,
what are the plan for EPEL-9 ?


I really this should be available ASAP to be
available to our users at GA time.


Regards,
Remi
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] ImageMagick-6.9.12.28

[Remi Collet]

Le 31/10/2021 à 22:44, Luya Tshimbalanga a écrit :

Hello team,

ImageMagick is updated 6.9.12.28 on Rawhide and got side tag as 
35-build-side-47231. For my understanding, the following packages 
(including those from RPM Fusion) may need a rebuild based on these 
dependencies:



fedora php-pecl-imagick


Building php-pecl-imagick-3.5.1-2.fc35 for f35-build-side-47231
Done



Remi


as proven packager as this package is mostly orphaned
(owner is unresponsive)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] PHP 8.1 mass rebuild - Done

[Remi Collet]

Le 28/10/2021 à 10:50, Remi Collet a écrit :


Mass rebuild is in progress in f36-build-side-47161
which already have php-8.1.0~RC5-1.fc36


Mass rebuild done

58/63 packages were built with success and
are now available in rawhide

See: https://bodhi.fedoraproject.org/updates/FEDORA-2021-610b3547a3

FTBFS for

#2018180php-facedetect
php-pecl-ds
php-pecl-solr2
php-zmq
#2018182libguestfs



Cheers,

Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[HEADS UP] PHP 8.1 mass rebuild

[Remi Collet]

Hi,

I started working on PHP 8.1 on F36/Rawhide
https://fedoraproject.org/wiki/Changes/php81

Mass rebuild is in progress in f36-build-side-47161
which already have php-8.1.0~RC5-1.fc36

I will try to take care of most extensions
so please don't build any, or use the side tag
and please tell me.


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Rawhide] ImageMagick-6.9.12-26 available

[Remi Collet]

Le 28/10/2021 à 08:33, l...@fedoraproject.org a écrit :



On 2021-10-27 10:21 a.m., "Antonio T. sagitter" 
 wrote:
Use a side-tag 
(https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages), 
please.


Done. '''
Side tag 'f36-build-side-47153' (id 47153) created.
Use 'fedpkg build --target=f36-build-side-47153' to use it.
Use 'koji wait-repo f36-build-side-47153' to wait for the build repo to 
be generated > '''


I don't see any value for using a side tag for a patch release 
(6.9.12.25 to 6.9.12.27)


This make sense when major changes happen, so when library soname change.

OK, with this strange library this may happen in patch version (4th 
digit), but should only be in 3rd digit bump, in which case installation
directory also change and may require more work (e.g. 
/usr/lib64/ImageMagick-6.9.12)



Remi



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Rawhide] ImageMagick-6.9.12-26 available

[Remi Collet]

Le 27/10/2021 à 01:42, Luya Tshimbalanga a écrit :

Hello team,

  I would like to let you know ImageMagick-6.9.12-26 recently landed 
upstream.
Learning from the previous experiences, I or my co-maintainer are 
planning to commit and build this package for Rawhide only in about a 
week, so the following maintainers of the respective packages will need 
to get in sync:


Again, this list is not the right one,
looks like you check what requires "ImageMagick" (the commands)
but not "ImageMagick-libs" (the libraries)




NsCDE
a2ps
anyremote
c-graph
caja-image-converter
chordpro-abc
conky-manager
darktable-tools-noise
devedeng
dvd-slideshow
epix
fbida
ffmulticonverter
freewrl
geeqie
gscan2pdf
gyazo
jumpnbump-menu
latex2rtf
libpst
lives
lyx
mediawiki
mtpaint
nautilus-image-converter
nemo-image-converter
perl-Graphics-TIFF-tests
perl-PDF-API2-tests
perl-PDF-Builder-tests
perl-Panotools-Script
playonlinux
rubygem-mini_magic
rubygem-rmagick
shutter
texlive-graphicxpsd
variety
vfrnav-utils
w3m-img
wdune


The scratch-build is successful on 
https://koji.fedoraproject.org/koji/taskinfo?taskID=77869076 meaning 
proven packagers are welcome to commit the changes.  Let know if anyone 
has a question.


Regards,


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ImageMagick update

[Remi Collet]

Le 15/10/2021 à 10:22, Remi Collet a écrit :

This list is not complete, at least php-pecl-imagick is missing
and this one is broken by recent changes...



# dnf repoquery --whatrequires ImageMagick-libs

ImageMagick
R-magick
WINGs-libs
autotrace
chafa
converseen
digikam-libs
dmtx-utils
dvdauthor
eom
gtatool-imagemagick
inkscape
libopenshot
php-pecl-imagick
psiconv
pstoedit
q-magick
rss-glx
rubygem-rmagick
synfig
synfigstudio
vips
xine-lib-extras
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ImageMagick update

[Remi Collet]

Le 15/10/2021 à 10:05, Luya Tshimbalanga a écrit :

Hello everyone,

ImageMagick is now pushed to 6.9.12.25 as a long-overdue update [1] for 
all releases except EPEL8 branch, which I do not use (co-maintainer 
welcome). Affected packages below may need to rebuild:


Sorry, but such update, with soname change is not acceptable in stable 
branches.


If really wanted, you have to create a grouped update for all packages


NsCDE
a2ps
anyremote
c-graph
caja-image-converter
chordpro-abc
conky-manager
darktable-tools-noise
devedeng
dvd-slideshow
epix
fbida
ffmulticonverter
freewrl
geeqie
gscan2pdf
gyazo
jumpnbump-menu
latex2rtf
libpst
lives
lyx
mediawiki
mtpaint
nautilus-image-converter
nemo-image-converter
perl-Graphics-TIFF-tests
perl-PDF-API2-tests
perl-PDF-Builder-tests
perl-Panotools-Script
playonlinux
rubygem-mini_magick
rubygem-rmagick
shutter
texlive-graphicxpsd
variety
vfrnav-utils
w3m-img
wdune


This list is not complete, at least php-pecl-imagick is missing
and this one is broken by recent changes...


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers

[Remi Collet]

Le 07/09/2021 à 11:51, Miro Hrončok a écrit :

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know 
for sure



php-EasyRdf orphan   1 weeks ago
php-Faker orphan 1 weeks ago
php-JMSParser orphan 1 weeks ago
php-JsonSchema    orphan, remi 1 


Checking the first ones... I don't see any of them orphaned in pagure
still owned by Shawn Iwinski

Do I miss something ?


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[PHP-DEV] Minor security improvement

[Remi Collet]

In phar default signature is still SHA-1
which is no more considered add secure


Proposal: switch to SHA256 by default

https://github.com/php/php-src/pull/7341

Old algo are not removed, at least they
are required to check old archives.

Perhaps could make sense to raise a warning
when used


In smp, auth protocol only support MD5 and SHA-1

rfc-7860 recommends SHA256 and SHA512

https://github.com/php/php-src/pull/7342


As minor self-contained change, probably don't
worth an RFC.


Please comment on PR


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: Plan to orphan (retire ?) the Horde stack

[Remi Collet]

Le 30/07/2021 à 09:00, Remi Collet a écrit :

Hi,

https://www.horde.org/

The horde stack is a huge set of >100 packages
Lot of them are FTBFS as not ready for PHP 9

The project is not very active, and their seems to
be a major rewrite, with namespace, and using composer.

The project is still maintained for security
but using old PHP (so fine for Fedora <=34 and EPEL)


I plan to orphan all the package in the next day
or perhaps only retire them from rawhide


112 packages retired from Rawhide

php-channel-horde and php-horde-*


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Plan to orphan (retire ?) the Horde stack

[Remi Collet]

Hi,

https://www.horde.org/

The horde stack is a huge set of >100 packages
Lot of them are FTBFS as not ready for PHP 9

The project is not very active, and their seems to
be a major rewrite, with namespace, and using composer.

The project is still maintained for security
but using old PHP (so fine for Fedora <=34 and EPEL)


I plan to orphan all the package in the next day
or perhaps only retire them from rawhide



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[PHP-WEBMASTER] [web-php] master: 8.0.9 tarballs

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2021-07-29T15:11:31+02:00

Commit: 
https://github.com/php/web-php/commit/d567df3bd4118ab373a12c4a4ca693c82974b569
Raw diff: 
https://github.com/php/web-php/commit/d567df3bd4118ab373a12c4a4ca693c82974b569.diff

8.0.9 tarballs

Changed paths:
  M  distributions


Diff:

diff --git a/distributions b/distributions
index 62bfd4743..6e41a88b7 16
--- a/distributions
+++ b/distributions
@@ -1 +1 @@
-Subproject commit 62bfd47431f7649aa832c99798634a3a41cd89ae
+Subproject commit 6e41a88b7e5fefd06d11260bd24c9803bf3ba3f0

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Review swaps: A bunch of PHP libraries

[Remi Collet]

Le 16/07/2021 à 10:39, Christopher Engelhard a écrit :

Hi all,
I finally found some time to unbundle all the 3rdparty PHP/composer
libraries from the nextcloud package.

The bad news is that due to their various dependency trees, I now have a
total of 24 new packages that need reviewing.
The good news is that I think quite a few of them will be generally
useful beyond just nextcloud.

They are all fairly small & simple PHP libraries, build without issues
and are basically identical in terms of packaging. If there are people
out there who'd like to try their hand at reviewing for the first time,
one of these might be a good place to start.


From a quick look, for all these packages
it seems useful to include upstream test suite
by pulling a git snapshot (common practice in PHP to workaround
the stupid .gitattributes usage)

Unbundling make sense when we can run CI (Koschei) and ensure
changes in the PHP stack (ex PHP 8.0 in F35 or 8.1 in F36) don't break

Also use range dependencies everywhere (even if a single version 
packaged), this can change in the future.


I should be able to review (or help) on this set of reviews.

the PHP SIG mailing list (php-devel@...) is probably a better
place if you have any question about PHP specific packaging


Remi



Obviously, if you need something reviewed in return, I'd be happy to do
that.

Full list of links is below, but to make it easier for people
- I set up a dependency tree (
https://bugzilla.redhat.com/buglist.cgi?bug_id=1981857_id_type=anddependson=tvp_id=12016550
) so you can pick a leaf.
- I made a copr repository (
https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/packages/ ) that
has builds for all of these, including fedora-review/rpmlint logs (and a
big thank you to whoever made that last bit possible in Copr, that was
*extremely* useful). The repo also contains a few forks of existing
packages, ignore those :) .

Best,
Christopher

List of links:
https://bugzilla.redhat.com/show_bug.cgi?id=1982616
https://bugzilla.redhat.com/show_bug.cgi?id=1982618
https://bugzilla.redhat.com/show_bug.cgi?id=1982619
https://bugzilla.redhat.com/show_bug.cgi?id=1982621
https://bugzilla.redhat.com/show_bug.cgi?id=1982624
https://bugzilla.redhat.com/show_bug.cgi?id=1982627
https://bugzilla.redhat.com/show_bug.cgi?id=1982629
https://bugzilla.redhat.com/show_bug.cgi?id=1982630
https://bugzilla.redhat.com/show_bug.cgi?id=1982631
https://bugzilla.redhat.com/show_bug.cgi?id=1982632
https://bugzilla.redhat.com/show_bug.cgi?id=1982633
https://bugzilla.redhat.com/show_bug.cgi?id=1982635
https://bugzilla.redhat.com/show_bug.cgi?id=1982636
https://bugzilla.redhat.com/show_bug.cgi?id=1982637
https://bugzilla.redhat.com/show_bug.cgi?id=1982638
https://bugzilla.redhat.com/show_bug.cgi?id=1982639
https://bugzilla.redhat.com/show_bug.cgi?id=1982640
https://bugzilla.redhat.com/show_bug.cgi?id=1982643
https://bugzilla.redhat.com/show_bug.cgi?id=1982645
https://bugzilla.redhat.com/show_bug.cgi?id=1982646
https://bugzilla.redhat.com/show_bug.cgi?id=1982647
https://bugzilla.redhat.com/show_bug.cgi?id=1982648
https://bugzilla.redhat.com/show_bug.cgi?id=1982651
https://bugzilla.redhat.com/show_bug.cgi?id=1982652





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)

[Remi Collet]

FYI

https://fedoraproject.org/wiki/Changes/libmemcached-awesome


libmemcached 1.0.18 have been retired from Rawhide

libmemcached-awesome 1.1.0 is now available



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)

[Remi Collet]

Le 06/07/2021 à 20:28, David Cantrell a écrit :

On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote:
On Tue, Jul 6, 2021 at 12:29 PM David Cantrell  
wrote:


On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:
>https://fedoraproject.org/wiki/Changes/libmemcached-awesome
>
>== Summary ==
>Switch from libmemcached to libmemcached-awesome
>
>== Owner ==
>* Name: [[User:Remi| Remi Collet]]
>* Email: remi at fedoraproject dot org
>
>== Detailed Description ==
>
>libmemcache 1.0.18 was released in February 2014, so hasn't received
>an update for 7 years.
>
>libmemcache-awesome is a fork providing same libraries, tools with
>API/ABI compatibility.
>
>== Benefit to Fedora ==
>
>Rely on a maintained project.
>
>
>
>== Scope ==
>* Proposal owners: Check Koschei status. Test with latest version to
>ensure compatibility. Work with upstream on bug fixing. Needed mass
>rebuild (C extensions) done by change owner.
>
>* Other developers: N/A (not a System Wide Change)
>* Release engineering:
>* Policies and guidelines: N/A (not a System Wide Change)
>* Trademark approval: N/A (not needed for this Change)
>
>
>== Upgrade/compatibility impact ==
>N/A (not a System Wide Change)
>
>== How To Test ==
>
>* install and play with your application
>
>== User Experience ==
>
>Developers and system administrators will have the great benefit or
>running a maintained library.
>
>
>== Dependencies ==
>
>All php-* packages (and some *-php)
>
>== Contingency Plan ==
>* Contingency mechanism: Drop not compatible packages.
>* Contingency deadline: N/A (not a System Wide Change)
>* Blocks release? N/A (not a System Wide Change)
>
>== Documentation ==
>
>* [https://awesomized.github.io/libmemcached/ Upstream documentation]
>

The change proposal indicates this is a drop-in API replacement
project, but will this introduce a new package named
'libmemcached-awesome' and we let libmemcached go out to pasture?  Or
is this changing the Source0 of the libmemcached package to just use
this new upstream?

If the former, will the new package provide proper Provides/Conflicts
against the existing libmemcached package or are there plans to allow
both to be installed at the same time?


From what I can tell, you can't have both installed in parallel, so I
think I'd prefer to see the Source0 in libmemcached change to the fork
rather than introducing a new source package and complicating things.


That's more or less the direction I was going with this thought.

If we are fairly confident libmemcached is dead upstream, then I see
no reason to just replace Source0 with the active project.  On the
other hand, we have seen projects come back from what appears to be a
dead upstream and then you have a name conflict and/or confusion.
Also we do have naming policy for Fedora packages that at least
encourages the package name to match the upstream project name in
cases where that will work.

I don't know the state of libmemcached and whether or not it will come
back to life (or if it's even dead upstream).  With that in mind, I
would prefer to see:

     * Addition of libmemcached-awesome as a new package
     * libmemcached-awesome Provides libmemcached
     * libmemcached-awesome Obsoletes libmemcached
     * Orphan libmemcached


That the plan (new package named, as the project, libmemcached-awesome)

FYI, the rename was an explicit requirement of the old project author.


Additionally, if any packages carry a Requires or dynamic dependency
on libmemcached, those should be updated to libmemcached-awesome.  The
lazy way would be to add Epoch: 1 to libmemcached-awesome and let
libmemcached fade away.


libmemcached will be retired, everything provided by "libmemcached" is 
now provided byt the new one




Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)

[Remi Collet]

Le 26/06/2021 à 02:39, Go Kudo a écrit :

Hello Internals.

RFC has been reorganized for finalization.

https://wiki.php.net/rfc/rng_extension


1st I dislike the name "random_ext", why this "_ext" part ?

2nd why not following the standard process ?

1/ publish on pecl
2/ merge in php-src if enough success and good feedback


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-WEBMASTER] [web-php] master: 8.0.8 is security

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2021-07-01T15:02:45+02:00

Commit: 
https://github.com/php/web-php/commit/533603bf3ff62aa60dde1fe5aa065a5f5d94
Raw diff: 
https://github.com/php/web-php/commit/533603bf3ff62aa60dde1fe5aa065a5f5d94.diff

8.0.8 is security

Changed paths:
  M  archive/entries/2021-07-01-2.xml
  M  releases/8_0_8.php


Diff:

diff --git a/archive/entries/2021-07-01-2.xml b/archive/entries/2021-07-01-2.xml
index 7ee087e18..83909ef8f 100644
--- a/archive/entries/2021-07-01-2.xml
+++ b/archive/entries/2021-07-01-2.xml
@@ -9,7 +9,7 @@
   
   
   
-http://www.w3.org/1999/xhtml;>The PHP development team 
announces the immediate availability of PHP 8.0.8. This is a bug fix 
release.
+http://www.w3.org/1999/xhtml;>The PHP development team 
announces the immediate availability of PHP 8.0.8. This is a security 
release.
 
 All PHP 8.0 users are encouraged to upgrade to this version.
 
diff --git a/releases/8_0_8.php b/releases/8_0_8.php
index 46249e2d6..639207b24 100644
--- a/releases/8_0_8.php
+++ b/releases/8_0_8.php
@@ -5,7 +5,7 @@
 ?>
 PHP 8.0.8 Release Announcement
 
-The PHP development team announces the immediate availability of PHP 8.0.8. 
This is a bug fix release.
+The PHP development team announces the immediate availability of PHP 8.0.8. 
This is a security release.
 
 All PHP 8.0 users are encouraged to upgrade to this version.
 

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.0.8 Released!

[Remi Collet]

Le 01/07/2021 à 13:35, Gabriel Caruso a écrit :

The PHP development team announces the immediate availability of PHP
8.0.8. This is a bugfix release.


Should read: This is a security and bugfix release


Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: building against epel8 modules

[Remi Collet]

Le 24/06/2021 à 15:33, Matthew Miller a écrit :

On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote:

P.S. yes, I'm really disappointed by how Fedora evolves,
not being able to use a proper build system (modules aware)


If you could wave a magic wand here, what would a proper build system look
like?


I'm fine with current tooling (Koji)

I only like to be able to build additional packages for existing modules
(e.g. php extensions in EPEL for php streams in RHEL) so
in some new module (php-extras) or better in the same one (php)

In short being able to run "fedpkg module build" from
https://src.fedoraproject.org/modules/php-extras/tree/7.3
(work is ready for months)

I still don't understand what Frankenstein buildroot we are using.

2 lines in a mock file allow to be aware of modules...

modules=1
...
config_opts['module_enable'] = ['php:7.4', ...

2h of work to find the proper configuration and
I was able to build such packages since the day RHEL-8-Beta
was made publicly available, in May 2018... 3 years ago
and still waiting for something to happen in EPEL

Ex:
https://rpms.remirepo.net/temp/epel-temp.repo
And mock configuration
https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: building against epel8 modules

[Remi Collet]

Le 23/06/2021 à 10:57, Nico Kadel-Garcia a écrit :

I can't find *anyone* who likes modularity. 


I like modules !

BTW

Community have killed SCL
Community is killing modules

EPEL-8 is IMHO partially broken,
and perhaps should be consider as dead.


> I'm devoutly hoping that it is discarded for RHEL 9.

I rather hope than EPEL-9 will be better
and available for "Beta" time.


Remi


P.S. yes, I'm really disappointed by how Fedora evolves,
not being able to use a proper build system (modules aware)
in 2 years, while everyone else seems to be able to
do it quite shortly (CentOS, Alma, Rocky, Oracle...)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [PECL-DEV] Adding tentative extra data structures (Teds) as a PECL

[Remi Collet]

Le 21/06/2021 à 19:34, tyson andre a écrit :

Hi,

I'd like to add my recent iterable RFC and data structure proposals I'm working 
on as a PECL.
https://github.com/TysonAndre/pecl-teds/
(I plan to publish alpha releases initially)



No objection from me

+1


Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PECL-DEV] Adding var_representation as a PECL

[Remi Collet]

Le 17/06/2021 à 03:31, tyson andre a écrit :

Hi,

My recent RFC to add var_representation to core failed 9-10 recently with 
conflicting objections.

I'd like to add this as a PECL.
Are there any objections?


None from me

+1

Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PECL-DEV] I would like to take over PAM extension which is inactive since 2009

[Remi Collet]

Hi,

Le 26/05/2021 à 07:28, Amish a écrit :

Hello,

My name is Amish and I am located in India and a coder since about 23 
years or so.


I would like to take over PAM extension located at 
https://pecl.php.net/package/PAM. The package is inactive since 2009.


I have improved the code to make it ready for PHP 7/8 at Github. And 
also added some additional features.


https://github.com/amishmm/php-pam


I noticed version 2.2.1 have been published on pecl

So, questions

1/ Where are the sources ?

Seems the linked github project is outdated (on 2.1 there) and no 
package.xml




2/ Supported versions

You say 7/8 but package.xml states > 8.0
Is it expected (will be nice to have all maintained versions)



3/ ZTS

Looks like ZTS support is not ready
Segfault when  run with extension enabled

(gdb) bt
#0  zend_post_startup () at 
/usr/src/debug/php-7.4.20-1.fc33.remi.x86_64/Zend/zend.c:1015
#1  0x5577a59d in php_module_startup (sf=, 
additional_modules=, num_additional_modules=)

at /usr/src/debug/php-7.4.20-1.fc33.remi.x86_64/main/main.c:2373
#2  0x55877cc1 in php_cli_startup (sapi_module=) 
at /usr/src/debug/php-7.4.20-1.fc33.remi.x86_64/sapi/cli/php_cli.c:410
#3  0x5563f45b in main (argc=6, argv=0x55e1b230) at 
/usr/src/debug/php-7.4.20-1.fc33.remi.x86_64/sapi/cli/php_cli.c:1326




Cheers,
Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Remi Collet]

Le 04/06/2021 à 16:36, Ben Morss via internals a écrit :


... I created a PR to propagate libgd's AVIF
support into PHP's bundled gd fork...


Does it really make sense to keep maintaining this fork ?

Having to maintain 2 (quite) different code and picking
piece from one to other seems a waste of energy.

I really think that we'll need to re-sync bundled gd
with upstream and only keep it as an alternative for
people without system gd (and perhaps even drop it later)


My 0.02cts

Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [scl.org] Is Software Collections abandoned?

[Remi Collet]

On Tue, 11 May 2021 at 07:14, Jan Staněk > wrote:

Hi all,
currently, I'm not aware of any collections planned for CentOS 8;
modularity/AppStream is the prefferred way forward.



Le 11/05/2021 à 14:12, Stephen John Smoogen a écrit :

So Red Hat does and does not seem to support collections on RHEL-8. The 
CentOS Stream of 8 ships with two software collections gcc-toolset-9 and 
gcc-toolset-10 which are newer gcc collections than the base one. 



"scl-utils" is still available in RHEL-8 (and CentOS-8)

So, it is possible to build Software collections

For ex, I'm used to build PHP 5.6 to 8.0 as SCL for RHEL-8 [1]


But, indeed, GCC 9 and 10 are the only ones maintained by RH
and modularity is the new way (for now) to provides new
versions of applications / languages.


Notice: but scl-utils in Fedora is broken and doesn't work anymore


Remi



[1] as I think SCL, allowing multiple versions to be installed
simultaneously, is a great feature, very valuable for dev



--
rcol...@redhat.com | Senior Software Engineer / BaseOS / WebStack team
GPG Key: 0x29F16A18
Fingerprint: 5A0E 6F54 D94D 5732 69EE  E3FF 614A 6905 29F1 6A18

___
SCLorg mailing list
SCLorg@redhat.com
https://listman.redhat.com/mailman/listinfo/sclorg

Re: [PHP-DEV] Bugsnet

[Remi Collet]

Le 09/05/2021 à 08:48, Joe Watkins a écrit :


Having moved our workflow to github, now seems to be the time to seriously
consider retiring bugsnet for general use, and using the tools that are
waiting for us - Github Issues.


Please NO

This mean we will drop ownership on all data and history about bug.



Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PECL-DEV] Re: [External] : Re: [PECL-DEV] New PECL Extension, mysqlnd based

[Remi Collet]

Please provide LICENSE file in pecl package

Else anyone dsitributing it will violate the license terms


Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

[PECL-DEV] Re: [External] : Re: [PECL-DEV] New PECL Extension, mysqlnd based

[Remi Collet]

Le 10/05/2021 à 11:27, Filip Janiszewski a écrit :

Hi Remi,

Yes, it should work only with 8.0 onward, the source code has not been released 
yet to a public repository, we're working here to create a mirror of our 
private repo on github so that the code will be available.

As for the KRB5 issue, what OS/release are you using to build the code? I might 
have to check for compatibility issues and fix them.


Fedora 32, 33, 34
RHEL 7, 8

Remi



Thanks a lot

From: Remi Collet 
Sent: Monday, May 10, 2021 11:21 AM
To: pecl-dev@lists.php.net ; Filip Janiszewski 

Subject: [External] : Re: [PECL-DEV] New PECL Extension, mysqlnd based


Also krb5 support seems broken

  PKG_CHECK_MODULES([KRB5], [libkrb5])

Which library provides this

  PKG_CHECK_MODULES([KRB5], [krb5])

Seems better (build passes), but cannot be loaded

  modules/mysqlnd.so: undefined symbol: GSS_C_NT_USER_NAME


Remi



--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PECL-DEV] New PECL Extension, mysqlnd based

[Remi Collet]

Le 10/05/2021 à 11:21, Remi Collet a écrit :


Also krb5 support seems broken

     PKG_CHECK_MODULES([KRB5], [libkrb5])

Which library provides this

     PKG_CHECK_MODULES([KRB5], [krb5])

Seems better (build passes), but cannot be loaded

     modules/mysqlnd.so: undefined symbol: GSS_C_NT_USER_NAME


Remi




Fixed by a simple

  PHP_SUBST(MYSQLND_SHARED_LIBADD)



Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PECL-DEV] New PECL Extension, mysqlnd based

[Remi Collet]

Also krb5 support seems broken

PKG_CHECK_MODULES([KRB5], [libkrb5])

Which library provides this

PKG_CHECK_MODULES([KRB5], [krb5])

Seems better (build passes), but cannot be loaded

modules/mysqlnd.so: undefined symbol: GSS_C_NT_USER_NAME


Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PECL-DEV] New PECL Extension, mysqlnd based

[Remi Collet]

Le 22/04/2021 à 10:23, Filip Janiszewski a écrit :

Hi,

I would like to publish a new extension on PECL, the proposed name is 
mysqlnd_ngen (where ngen stands for next gen) and it would contain mysqlnd, 
mysqli and pdo (forked from php and bundled in one extension with building 
scripts that will prepare the 3 extension builds which the user can load into 
php instead of the original version in the repo) with a bunch of modifications 
that Oracle (Where I work and on behalf of which I'm submitting the request) is 
providing and that are expected to be used from hopefully community and 
certainly corporate users. (Like, support for specific auth mechanism like 
kerberos, or support for high availability, topology discover etc).

I can login to PECL (fjanisze) and I saw that before submitting a new package 
request I should inquiry this list for comments, so here I'm, please comment 
for further details or suggestions on different names - The maintainer of the 
repo would be me and the extension will be up to date with php-8.0.


I noticed thant mysqlnd_ngen 8.0.25 was released

BTW, despite https://pecl.php.net/package/mysqlnd_ngen
claims it is compatible with 7.1+, build fails with 7.x

Seems to be PHP 8 only


More, there is no link to sources repository



Remi

--
PECL development discussion Mailing List (https://pecl.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-WEBMASTER] [web-php-distributions] master: Update keyring with ram...@php.net key

[Ben Ramsey via Remi Collet]

Author: Ben Ramsey (ramsey)
Committer: Remi Collet (remicollet)
Date: 2021-04-28T06:42:42+02:00

Commit: 
https://github.com/php/web-php-distributions/commit/625b2bf7be0369d8d0b1d728e56a09c549078444
Raw diff: 
https://github.com/php/web-php-distributions/commit/625b2bf7be0369d8d0b1d728e56a09c549078444.diff

Update keyring with ram...@php.net key

Changed paths:
  M  php-keyring.gpg


Diff:

diff --git a/php-keyring.gpg b/php-keyring.gpg
index 058c10d..870d816 100644
--- a/php-keyring.gpg
+++ b/php-keyring.gpg
@@ -1,367 +1,415 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
 
-mQINBGBlop0BEADECekUKq62YGCekiH8yT7At8xXdNAv1MS0KGmogEBxD5xEII5w
-D6pL7KUhOzKZsgKIW1M11ZwzvsnMc5yJC89MmI7P5talQeoUzMPz5Q9dBC6AOpt6
-Jv9hNb0ECO/FN8N3rwYFZRi8wSF1ii1+2bAUpuMaD5g/ZporDLDNMYakM1bhptCP
-NYLypCJVhzwfk6lFgabw8JiHQkbhorO/NdDgSmjJk0P63YYNU2GSJ2T343rlvqGf
-C6rOMN3H5srg22ykDfG9UHdnfZScJLnSOioSMh+7lNBdRnhyIIvYWSWWXJ5Q4qrX
-B2eWGBFBxMw+qzwC9C6FBaUunT+AxXIfEeKAaVvF044Ngc38GUQr9SLiIHeh4RFH
-Llo+UBjIuobghf9llQxKBrPyt9isoftSYODjjqbiz9P2Kr7ETgDG3WPNMaaUdsjD
-LaUyT4bOWgspGfH3xyhLIeFRr4vsRSMLjhhJal6ACxT2rPDfg+Y15yUEdf9s3pHo
-vWIjOow16bNEiAoQS+rxtOXLmul+Svu9WBx5Q6FLm2/rY4iB8hWLcxHtTzzIi5el
-7QHapZS6lEL8vjHB4HajTiFPhcW1g1ow7WeYZQ3WfrCJc93rBsJf80EDHUXU7I3D
-bhJTnZdqTJi5QPAr4STPiJB1bCB6aJy7QajdCG68PkodZF9LBHI5H6w0iQARAQAB
-tChQYXRyaWNrIEFsbGFlcnQgPHBhdHJpY2thbGxhZXJ0QHBocC5uZXQ+iQJOBBMB
-CAA4FiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmBlop0CGwMFCwkIBwIGFQoJCAsC
-BBYCAwECHgECF4AACgkQGZ+d/vb/uv3C6BAAm4xcCydOTabgSx1rVHroho7HeGaz
-j2FO2gnddOQ4/TP9jz3rqYnRmn+2OGh/viNHA34Sj1HRVzham5d0vplo6bpqVziF
-ixP7Xds7WE0RcU/vQ4XeyK2EdpzzBKF1660F1cZb8NxHybsJc6w1Z1ACVticJveC
-3bNOngNOvGZhU/him0GxAFC1pOoeU7QrRQagcSSqTk9ts565S+8EDJ5IS+KyU7F5
-IJBqQFcVVE4qiN33RBuLpcWU29lbM+AEeytVEq6imCI2p80ArP+fmu6FlwjhIp2e
-LvOa/0IuIE7w/+qrO1r1a/nbPrr0yA9Ex84MmvtD2kboBkICb32goJRK1f9p0oYG
-d+7SbH+/RsjIrthJan/yXiKiK6UGzTjF5nVL1PqcwQavLyTaqUStwYjn0MBHTxo4
-Bsqz/jZbvQSjF6nHynBLwpLIJ9MK4XvxsN3Fe/e661hv4DUCIeym756yMmxyBxc1
-E9iu5AUENRDRpTNWuext49fqLVldiQ9RNJGzoe70rywlD6avl1MRp7byzMPF832Y
-+qU0ZuwpzbUKxfA4mFQiBTprfaC1nvGriD8D0NgdjWNI+EqLarkkxtyRDarOuXXv
-NeFUhIRw9N5tDRBy7dhLbj6T+YCogYKuVKcW0s5/ow9O0vwml5b1+K7Kzaylv+ke
-GqaUJ69t1rwJS0u5Ag0EYGWinQEQAMtkmceUjt18RD62FYost0ul3QxkE66AKpaN
-h1R8vz05jrRbYLcuvOB97COI0vEHPC+qaARjJBRG2VXujTgslW3I7UHZvtlBhCgL
-qC74pXnP7zDUQ6zob4wg11r9DJ2NCTzKYKGCAZ0e1a0bNNnkrWOz57zAmCQXTSf1
-gLGSTP6MkIrUvvDve+1i9LSph5rVRXGYYb5wGx9D0ZvB5GXpO9KOWYu2XubqHVyk
-YNCufLKn/Kt840tvLW1DfaUyF8fT1cA8eklYJ+G/12i+Ace1vgquhqPzZQBnPYl7
-ZGftImIAIu97NYQVNkxYKWe2UeochW2Zqye3OHPOAroTUgfrsOBZHebzaegumZti
-UcA4uY0Gw5hEZ185Abbwvbk/cetZX0A+KTB08eDj/S0ouA3OEHrI7p2Pkez9hGwk
-PQmf1f5wI1qw/lVMs4WxkPgnWLyNPxuuV/9/fruo617doUA9Crs4Vg++kVj9zQnQ
-Pp5vcUcLF96NVAvhhXhuDcc5QbKdR4EbAeDJAnD8tjQt0J6OiTKVBmvsOPwfiXdv
-rHzlSElIpGgiKf5zxpeIjv/YIlsUMAi/eyi/IywCFL4bKe3EiliagCXSOupEKvoJ
-YJoWXVOOHfGsn6lEJKRNWr04BIdSoBvnfYHdO34MnPCuV/iq1AMXPujuU8ZcyfFg
-tb8oRrtBABEBAAGJAjYEGAEIACAWIQTx9pIjj7wWZuWlzNQZn53+9v+6/QUCYGWi
-nQIbDAAKCRAZn53+9v+6/ccvD/0RXb7doLc6YilekZcEqtvvCrgo/ZDbda1tjRbp
-QGyLy9J9whIdD7G7lSoGILSd8U18gCL7PZq96tGq75CDy89u0vI+IQ1WemRlfrBZ
-b5qkSOGO2Yr/VYVxxjZbtYiM44aJyrehhA3MCvwzyP27iclH7N0XsXgJOF1p3AVE
-fuXHhAVSbR3tkLPe7osXKyDUgUCuvJIPLSglCqPHsm95Xch8PpUXJRemPpFnsPIl
-qDKu/vfIrDMZtnEFBog/afjA6sqmC8X2BTKF6Tiv8KKy0divkwsmdAq+We0vkkIM
-q1PMc2UkDLv8DujpF4TXMvBXO3AWoKPDNt6L7zMUdymto5TIIA9WsIbn+aGTfbfS
-flJlhlzJ53nyzl/x9ukFabwp7jjF6Vyh7KYMQE6ob16JWTo+AZY3mvKoUXw6jwGo
-naBjNkuR9Em/IyjXDx0tiKKaNPdVh8Tg8pcGNt3ssroEKWqLrUjWlrso/+QPeH2G
-l5+NjQYSIcQOcYo/MGuiikA9GJu088+IgJ8bmTiFgMuq/ZLAuQ6gkpZBQXAN2hVI
-kV6H5IJwp8lbyf8GG0qBCk9Va03+PZjhZLu/fb9EzVmhyX95cENYNUE7QXQplsJZ
-qchsBbjgQE38DWiZKT7uyRhZUCUD3h9ZIsYo63NrQNoA+xkz9tub+4cXQV6iJi/G
-qeBTcpkCDQRZJWLpARAAvbQko56DbN7nDgPUT3ynLivOyQ/Y3XrdlFLMOAx3fx8J
-q7d0+1iqB9RsEafrnufr816nRUWeIBvu7YL1LDrTW+a4dtm0wbFCHhrL5v6JiZ7V
-whUIWHH47ZNOKd6rYCeTxo2WoQkWIOGkNrRqdjG/GrhbhT7B7Thy1kAi+70EobDf
-ZhJBMwEGZ5/UGC/iL00FUirEcvF3B2GVZNrk9sUGNi75ALnFhdE641NiydiBXXqX
-NPo89cWrAUdGn0/WHHB6UB+cPMjlvvaP5+wYjB34E9LATHSgnylaEK0HtArBZ6nP
-/leDbJx5MlK23yoiBZvjTrqSDKS+vwPiJMuWKYyCFBz7lS+lQGOsJuOt1iPBT5Pj
-bRnpJvY6iEsYq5GFrCBKGbQq8nAvDdIlGxqvHi2HQvXsFOXWoAnSxsJw72Izr8x9
-eei04hP0r66tqtJAQwGuwkxkZU/trIA/PaJe90LQFVCbLffZVRzJiC9XFeB1Kbzp
-UyR0XbDelYZT68Ornvtr5mLBfOm2J4urzB+iiZ5olmtcIo2DtMIkqYbU1wGtBxPx
-01foUm/WwkW8oqcHapBHmo/LCnMffl8jcVTpVH6PKUGZy0U3etRb4/rEk0hG6PeW
-uYItFg58jbYmnyhLy8Wpe1cmrWwHAhHCw2AFR33zS4OH5uB9+RzdGEKVLfkrlcEA
-EQEAAbQaUmVtaSBDb2xsZXQgPHJlbWlAcGhwLm5ldD6JAj4EEwECACgFAlklYukC
-GwMFCQ0oaIAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJENyf+NPuWvJ/TiUP
-/R7bmeATDzAxRlT1GfQz9He+Axf0HE9FddNU63SGfdkeLqeeg7+NHY40GXNlvQZq
-T1Ra/7+qnY2qXTx+b75mrZ0A8/5yDn6NYsD1hs75ip2wwUOKiV+yXej3Q/2KK3A/
-tLTkDSiyBhPWRUJ0vNIs/Ymkxs70ChEChDLoEEn95BtzQRBqikAbE06wUDlCd4PM
-Oondv6ibaw0Wy/U7glO+w6cfR1AJ44/yMZb3eEUA2vwQmMxmCZQsk7GlVt6nOwyI
-f6UWnarbMIIUhE7ZekkqPch7aGDhk8VzulIpCxBPJojpWjj0KwvYQg/i0hnOUITS
-wRCnrNJe/cPZMPamfV34eKcP4X9TeDt5Dx8lINKvUGl9VyrYoI01HKXX9iqvC7ZQ
-etKeNHmRNnVd09dV/q3J996RUlzHkyXmjSh16HhnL2v4MmVbb4vIiYarcPUDlJMU

[PHP-WEBMASTER] [web-php-distributions] master: Add Patrick Allaert key in keyring

[Patrick Allaert via Remi Collet]

Author: Patrick Allaert (patrickallaert)
Committer: Remi Collet (remicollet)
Date: 2021-04-27T15:06:53+02:00

Commit: 
https://github.com/php/web-php-distributions/commit/77428ac30937316a152ad9103d26df11f1b74aaf
Raw diff: 
https://github.com/php/web-php-distributions/commit/77428ac30937316a152ad9103d26df11f1b74aaf.diff

Add Patrick Allaert key in keyring

Changed paths:
  M  php-keyring.gpg


Diff:

diff --git a/php-keyring.gpg b/php-keyring.gpg
index b5318b2..058c10d 100644
--- a/php-keyring.gpg
+++ b/php-keyring.gpg
@@ -1,320 +1,367 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
 
-mQINBFklYukBEAC9tCSjnoNs3ucOA9RPfKcuK87JD9jdet2UUsw4DHd/Hwmrt3T7
-WKoH1GwRp+ue5+vzXqdFRZ4gG+7tgvUsOtNb5rh22bTBsUIeGsvm/omJntXCFQhY
-cfjtk04p3qtgJ5PGjZahCRYg4aQ2tGp2Mb8auFuFPsHtOHLWQCL7vQShsN9mEkEz
-AQZnn9QYL+IvTQVSKsRy8XcHYZVk2uT2xQY2LvkAucWF0TrjU2LJ2IFdepc0+jz1
-xasBR0afT9YccHpQH5w8yOW+9o/n7BiMHfgT0sBMdKCfKVoQrQe0CsFnqc/+V4Ns
-nHkyUrbfKiIFm+NOupIMpL6/A+Iky5YpjIIUHPuVL6VAY6wm463WI8FPk+NtGekm
-9jqISxirkYWsIEoZtCrycC8N0iUbGq8eLYdC9ewU5dagCdLGwnDvYjOvzH156LTi
-E/Svrq2q0kBDAa7CTGRlT+2sgD89ol73QtAVUJst99lVHMmIL1cV4HUpvOlTJHRd
-sN6VhlPrw6ue+2vmYsF86bYni6vMH6KJnmiWa1wijYO0wiSphtTXAa0HE/HTV+hS
-b9bCRbyipwdqkEeaj8sKcx9+XyNxVOlUfo8pQZnLRTd61Fvj+sSTSEbo95a5gi0W
-DnyNtiafKEvLxal7VyatbAcCEcLDYAVHffNLg4fm4H35HN0YQpUt+SuVwQARAQAB
-tBpSZW1pIENvbGxldCA8cmVtaUBwaHAubmV0PokCPgQTAQIAKAUCWSVi6QIbAwUJ
-DShogAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ3J/40+5a8n9OJQ/9HtuZ
-4BMPMDFGVPUZ9DP0d74DF/QcT0V101TrdIZ92R4up56Dv40djjQZc2W9BmpPVFr/
-v6qdjapdPH5vvmatnQDz/nIOfo1iwPWGzvmKnbDBQ4qJX7Jd6PdD/YorcD+0tOQN
-KLIGE9ZFQnS80iz9iaTGzvQKEQKEMugQSf3kG3NBEGqKQBsTTrBQOUJ3g8w6id2/
-qJtrDRbL9TuCU77Dpx9HUAnjj/Ixlvd4RQDa/BCYzGYJlCyTsaVW3qc7DIh/pRad
-qtswghSETtl6SSo9yHtoYOGTxXO6UikLEE8miOlaOPQrC9hCD+LSGc5QhNLBEKes
-0l79w9kw9qZ9Xfh4pw/hf1N4O3kPHyUg0q9QaX1XKtigjTUcpdf2Kq8LtlB60p40
-eZE2dV3T11X+rcn33pFSXMeTJeaNKHXoeGcva/gyZVtvi8iJhqtw9QOUkxRDvGB+
-FEUId3Z1yAu7ZAz6qiUCgxK/VJ6/kBb+YYR8K4FHLmNOd5KoiTerKQu423uuMYlY
-fBHpVZ9YuEJQnTEpizFEeOgaixx5RDLnoPsd/x59VS9eaaKotTPbW/rEp7SvbKj0
-dR5WMfGyd/OJrcWVZy8/Kh5Mc/4KOHD+JGAp0bE113TkEEoTZ8gNHFdLdv52V9eX
-UkeT5IxyThZBkUy6palDM8A5vaf6Eet8xOLy9XG5Ag0EWSVi6QEQAKujAODvsdbt
-5n1dO29Nj5htbmt6M2A7eOjt7yUj4UMtBaGOA08O0DVA8MJkvepMq9AJBXHZMi9D
-ycw3rxBHQDqHJJMwghu3RoQw1y5Wym7LiLhoWSU/wK0BrKOULBwh+kS6udKA4oWr
-V/gr0JGmfdL8dZjBF10kHCfCcjcjWtmIp2GRaoOKTlHCviNmRxzyqba7zE0Zc2ma
-Q/4w98BI83GqD1bT8gF/5qwSI1hecBwt9oS7EbZ1ZiE8SSE8Gr6OR3p5UNHbzqxU
-Wy8W4r3qulCLc6g1LPXP1V59cMxX9jQJ7lSdv0k8C6Lb6t9Wm8G63hNYgRCAmNW5
-EnqieTrx45K9vqoqfQK6Apfy0UoOquiuK7QClT3wBd7kmyKsCfV0bwRA/fV/sC1R
-niu8PV7CRk9ryudUXycKq33pSkrOfZjFIQhCqdJkVc2MPbAuj2pOMutKwGKRq/Mt
-3O8nEfGqWaJPa36C6dhlPqjEGTIEk5P493DzM7fj5VVIWyUrI8Vm9FslSvzILcON
-HMtKtRs2cRYA085NKDXGN7i5Am7L7ZONfqVs3V493ICwmALzeSULNLiMtX+ESQfd
-WCS3Hosnjbc6INDg9BRhFt5MEWJ/qchM3g4NQuukqtOYsiEUw8bCzepwJxXplvNY
-u0yQDxvP+0RzjMozruVz3VoHeyf6rSWvABEBAAGJAiUEGAECAA8FAlklYukCGwwF
-CQ0oaIAACgkQ3J/40+5a8n/8gg//a75gXQ4csiDUTsUndb94EXqraffmMcT5oCzf
-cP+Mecbuv3G8oQZeLRchsW2i4QecnvPwrXAJcF8kJuN/KZLyeh21PWBy55wo/2nb
-wOvQockXpK5yVeuc3DmdTaxDnW9u3QpSwbvkEyoCpeHH6rZ1wjqn8Qi1k7njC4qg
-XpRrLQdRsS5ULXpf3IM+vaxbQ5avVnNRu5zMA6M/0reL0RSjgMfnk+3AwLCtuMiy
-1aStCe8V7Y60/oauk+IZA1VJlSz2n3675YD7TkTZKkYIYZHTBw3ZPVJo08jdRUXt
-GJjpOyyWVjP7GMKvZuQVWqcFyc8QHHaIPDLkdi7B9YFPWqfwJPBfUXcdzjAXI7N4
-XsSEeMm8S8SC4FKCidioP/A+bamKcONHUuZ+AztvLh24ZTkqzA/sRRYpbMGUQzpc
-DbastuXG66s3e9pJa0R14011A4bofy6Ureh9q6TQNOkNegUUdjbGSd1bfNIdQXRH
-0+LBV1oaY//v+aBjswy4hJ5oXmQj5jQKFitRCP9jzueyDdMJZ0j0Hhh4ItCzFV5z
-IKtWiy7pRp1DXq9LjoyWeeLfKu+HrEGjMwyTGJiMjcL7oCHeiV/a+fY92wpUrY1/
-mRVLqKqDIA6/iEL2DVf21U7rXY26xxvf4QFImZaYLwKQYLe8TOOjDA/I9bR1JJmh
-54yw10CZAg0EXP+o8QEQAOt/faLOy1ltLfFcIRJo0o/tS9eEcofNUDxDNeT9Q61F
-2oMXi7uxRpnnJu69/9AgN5urM4aSL/amfIn5NSmT2JCkFHhcSb367UX3Hw3sNWJ6
-eGp7JePowEb9OhnTsJBuxIslZLUj8n9IRqi2snkIZqg5dnMTybjzvCTkgyEoJN96
-1PeP0AVgNkUS0ibQdzGbqWPWekb2DLMMkW3GClkJamdPYmeCA6nnjqZf2LiFhApf
-/fW6RBKKhQ/bTZaWmPpg8tooU+kVnvuLnn20lnxRI8aRnfsdXHAiiqlYmIIBJdG8
-PkutEWkvucRDhvcJ7ka1UZ1XvRG02MNvsTHQ7AWhZdKryz2P+ugX3g/omaQP3Tdg
-a7Diy1pOwifcgoKB8S9fORjC20DcuvO2wnlVBgyAReejisxgQO2yYlumfl1ZFV9e
-pYvdPEwZy8ugyLWCKmBZkoBggGL4gJrKtb/3VTnXaXQMw1uEXx+RawTaKWDPdhbM
-BfDbQzflbLcFgFEANiA1932MD4piFfsRvHm4FQC8u51pAHbBRj6GZFCWvseS5/Fl
-Dhd+5DGzbYXf7gXpcng2djFOvxG/s+eBjloo58Npe255U8rGrSfPJdHXs5jdDkPG
-J90mg4zCjVbPpIn6lZQIUoqd/3iAOP9z9waf0VrWpMzfZ1f31FVoHOobuhczOqM3
-ABEBAAG0JURlcmljayBSZXRoYW5zIDxncGdAZGVyaWNrcmV0aGFucy5ubD6JAlQE
-EwEKAD4WIQRaUogHgfdVYIv4FfyRDetG9T6jEgUCXP+peQIbAwUJEswDAAULCQgH
-AgYVCgkICwIEFgIDAQIeAQIXgAAKCRCRDetG9T6jEjUFD/9pntL8QAV66p/blK/9
-PQs/h1oqO1t2/dNWpQ9WpiCkuFvHCrNbzXuahxECh+TXfy5WCrsirmoCliq3yxu3
-YLjQBFQsmt81KhYk+9coewQ/Er71FE6oKU3reHx1vLK/qyGIL611FT62+FOQ781X
-zDgQTtUARTNWUuiewPBHlZpssrGHN+gj6GG/wgesjHuxtaZxPbaqKAOIYh8H6297
-fU3ksyiGyk3Lh7RoGsSKLKf3t/3hWVItMz1QECiwQNa51B3o1W/XAEWUEiBaSwW1
-GhhgSUozbmpaEDlj5xwrk8vchevvgeE6C1iwea/Z0Lu9HHaHdtbS7adgTKa8iopK
-TejiKuSqY+trgBg7uW/5YYW0FebaeYMWm4SMn6ApywuiTB8FbKaSBtV7A7XDOCGh
-Zd25eTpdPhtL7ja7ttXvcnRjB0ded4T5eX7M1gpFkIR18O9vPryGV

Re: matio: Not announced soname change in stable branch

[Remi Collet]

Le 05/04/2021 à 23:19, Gwyn Ciesla via devel a écrit :

Updates are now in flight for kst, libASL, openmeeg, and vips, for f34 and f33. 
gtatool is retired and FTBFS, so I left it alone.


Looks like the same happens today in Fedora 32


Remi





--
Gwyn Ciesla
she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, April 5, 2021 8:29 AM, Gwyn Ciesla via devel 
 wrote:


My apologies; 1.5.18 fixes a few CVEs, and the subsequent releases fixed 
regressions. I'm usually much more scrupulous about soname changes. I've added 
versioning to the solib's %files line in the spec, and will take care of the 
broken packages.




--
Gwyn Ciesla
she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie




Sent with ProtonMail Secure Email.




‐‐‐ Original Message ‐‐‐
On Friday, April 2, 2021 11:45 PM, Remi Collet fed...@famillecollet.com wrote:




It looks like matio have been updated in Fedora 33





https://bodhi.fedoraproject.org/updates/FEDORA-2021-0933889858





 From matio 1.5.17 with soname 9
To matio 1.5.21 with soname 11





This doesn't seems acceptable, or, at least, should be managed





Used by:





gtatool-matlab-0:2.2.3-6.fc33.x86_64
kst-0:2.0.8-29.fc33.x86_64
libASL-0:0.1.7-24.fc33.x86_64
openmeeg-0:2.4.2-0.8.fc33.x86_64
vips-0:8.9.2-1.fc33.x86_64





Remi





P.S. and an "empty" bodhi description seems also bad





devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure





devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[web-qa] master: 8.0.5RC1

[Remi Collet]

Author: Remi Collet (remicollet)
Date: 2021-04-16T11:38:24+02:00

Commit: 
https://github.com/php/web-qa/commit/fb387e525438d9f49956caa3e6eab3f645079ee1
Raw diff: 
https://github.com/php/web-qa/commit/fb387e525438d9f49956caa3e6eab3f645079ee1.diff

8.0.5RC1

Changed paths:
  M  include/release-qa.php


Diff:

diff --git a/include/release-qa.php b/include/release-qa.php
index c8198b4..a45fd6d 100644
--- a/include/release-qa.php
+++ b/include/release-qa.php
@@ -70,15 +70,15 @@
 ],
 ],
 
-'8.0.4' => [
+'8.0.5' => [
 'active'  => true,
 'release' => [
 'type'   => 'RC',
 'number' => 1,
-'sha256_gz'  => 
'30562034a57a9c347b103fbf1617fc2d3fc4f1bd197e84e1827239524883b5d3',
-'sha256_bz2' => 
'399af14c9251e651b478d4633638b99585bde2e45baf9ecacf9fa84c4cfb2c7a',
-'sha256_xz'  => 
'df693aad4cb3967a85dc8470674562e65333239a47162ee24e9c534ef0559cdc',
-'date'   => '18 Mar 2021',
+'sha256_gz'  => 
'344bde64fb10f7b8a335c242dd18804ff0c51e4bf7b4290dca846bb73727b76f',
+'sha256_bz2' => 
'2eee3ff188e2a1ecf09ccf98653ff1f418c3311a8b843afa7a0b5f68fe51f7d7',
+'sha256_xz'  => 
'9edd6be5e5700628d2ed9e9526530eab736c8ebc653df20b0d7b7e48ace4866c',
+'date'   => '15 Apr 2021',
 'baseurl'=> 'https://downloads.php.net/~carusogabriel/',
 ],
 ],