On Thu, Jan 20, 2022 at 03:38:43PM -0800, Bryce Harrington wrote:
> On Thu, Jan 20, 2022 at 09:42:47AM -0800, Bryce Harrington wrote:
> > On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> > > Hi Kunal,
> > >
> > > Thanks for the analysis.
> > >
> > > On 20-01-2022 10:56, Kunal Mehta
On Thu, Jan 20, 2022 at 09:42:47AM -0800, Bryce Harrington wrote:
> On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> > Hi Kunal,
> >
> > Thanks for the analysis.
> >
> > On 20-01-2022 10:56, Kunal Mehta wrote:
> > > > I can't tell what it may be trying to encode, but presumably it's
On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> Hi Kunal,
>
> Thanks for the analysis.
>
> On 20-01-2022 10:56, Kunal Mehta wrote:
> > > I can't tell what it may be trying to encode, but presumably it's either
> > > Main_Page or something used by Main_Page, which I'm guessing shoul
Hi Kunal,
Thanks for the analysis.
On 20-01-2022 10:56, Kunal Mehta wrote:
I can't tell what it may be trying to encode, but presumably it's either
Main_Page or something used by Main_Page, which I'm guessing should only
take a fraction of a second to encode. I suppose we could test
increasing
Hi,
On 1/19/22 14:08, Bryce Harrington wrote:
On Wed, Jan 19, 2022 at 09:58:52PM +0100, Paul Gevers wrote:
Hi Bryce,
On 19-01-2022 10:28, Bryce Harrington wrote:
With [4] applied, I'm seeing the following dumped on armhf:
## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
On Wed, Jan 19, 2022 at 09:58:52PM +0100, Paul Gevers wrote:
> Hi Bryce,
>
> On 19-01-2022 10:28, Bryce Harrington wrote:
>
> > With [4] applied, I'm seeing the following dumped on armhf:
> >
> > ## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
> > cat: /var/log/mediawiki/error
Hi Ondřej,
On 18-01-2022 20:31, Paul Gevers wrote:
On 18-01-2022 19:37, Ondřej Surý wrote:
the fix is simple, it was actually cruft from before when
uploadprogress didn’t support PHP 8.1:
https://sources.debian.org/src/php-uopz/7.1.1+6.1.2-5/debian/rules/#L3
https://sources.debian.org/src/php
Hi Bryce,
On 19-01-2022 10:28, Bryce Harrington wrote:
With [4] applied, I'm seeing the following dumped on armhf:
## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
cat: /var/log/mediawiki/error.log: No such file or directory
2022-01-19 09:16:57 autopkgtest-lxd-eeoxik autopkgt
On Sun, Jan 16, 2022 at 09:49:37PM -0800, Kunal Mehta wrote:
>
> Hi,
>
> On 1/16/22 11:52, Paul Gevers wrote:
> > On 12-01-2022 21:16, Paul Gevers wrote:
> > > Priority may lay with the mediawiki* regression on i386: "Internal
> > > Server Error" doesn't sound great, and other non-horde package.
Hi,
On 18-01-2022 19:37, Ondřej Surý wrote:
the fix is simple, it was actually cruft from before when uploadprogress didn’t
support PHP 8.1:
https://sources.debian.org/src/php-uopz/7.1.1+6.1.2-5/debian/rules/#L3
https://sources.debian.org/src/php-gnupg/1.5.1-1/debian/rules/#L3
I guess too.
Hi Paul,
the fix is simple, it was actually cruft from before when uploadprogress didn’t
support PHP 8.1:
diff --git a/debian/rules b/debian/rules
index 3a8ca25..1df1e86 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,3 +1,2 @@
#!/usr/bin/make -f
-PHP_DEFAULT_VERSION_OVERRIDE:=7.4
include /
Hi Ondřej,
I checked why e.g. src:php-uploadprogress isn't migrating. I think I
spotted a packaging mistake, probably coming from the toolchain.
php-uploadprogress Depends on php7.4-uploadprogress, but that package
isn't built anymore or provided by any binary package. As the binary
isn't par
Hi,
On 17-01-2022 06:49, Kunal Mehta wrote:
I don't have any i386 hardware, I tried pulling down a i386 Debian
unstable Docker container on my amd64 laptop and installing the
mediawiki+php8.1 packages on that but it didn't trigger the test
failure. Do you have any other suggestions/tips on how
php-lua filled RM #1003866, you can also kick it out of the testing.
> Checking reverse dependencies…
> No dependency problem found.
Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org
> On 16. 1. 2022, at 21:08, Paul Gevers wrote:
>
> Hi,
>
> One more thing.
>
> On 16-01-2022 20:52, Paul Gevers
Hi,
On 1/16/22 11:52, Paul Gevers wrote:
On 12-01-2022 21:16, Paul Gevers wrote:
Priority may lay with the mediawiki* regression on i386: "Internal
Server Error" doesn't sound great, and other non-horde package.
Did anybody already take a look at this [1, 2, 3]? It's the last thing
before
On Sun, Jan 16, 2022 at 08:52:28PM +0100, Paul Gevers wrote:
> Hi,
>
> On 12-01-2022 21:16, Paul Gevers wrote:
> > Priority may lay with the mediawiki* regression on i386: "Internal
> > Server Error" doesn't sound great, and other non-horde package.
>
> Did anybody already take a look at this [1,
Hi,
One more thing.
On 16-01-2022 20:52, Paul Gevers wrote:
It's the last thing
before I'll add a hint to ignore the autopkgtest regressions.
I see in the excuses [1] that some php-* package become uninstallable.
Those need to be fixed. php7.4-common will be removed (of course), I
have just
Hi,
On 12-01-2022 21:16, Paul Gevers wrote:
Priority
may lay with the mediawiki* regression on i386: "Internal Server Error"
doesn't sound great, and other non-horde package.
Did anybody already take a look at this [1, 2, 3]? It's the last thing
before I'll add a hint to ignore the autopkgte
Hi,
On 12-01-2022 15:56, David Prévot wrote:
In unstable (thanks for that), but it fails to migrate to testing, due
to the 'PHPUnit requires the "dom" extension.' issue.
Can’t find this issue. Did it go away by itself, or did you make any
change?
https://ci.debian.net/packages/p/php-doctrin
Hi Paul,
Le 11/01/2022 à 15:52, Paul Gevers a écrit :
On 10-01-2022 23:43, David Prévot wrote:
Le 10/01/2022 à 16:44, Paul Gevers a écrit :
On 10-01-2022 21:13, Ondřej Surý wrote:
I thought I filled RM bugs for all of them, but I found only
#1003055 for php-apcu-bc, something must went wrong.
Hi,
On 11-01-2022 20:52, Paul Gevers wrote:
There seems to be a new (unrelated?) FTBFS, so we need to figure it
out (or drop symfony from testing until then).
If that's OK with you/the team, I can check how much needs to be
removed doesn't seems like a lot of fun yet:
I stopped (the lis
Hi David,
On 10-01-2022 23:43, David Prévot wrote:
Le 10/01/2022 à 16:44, Paul Gevers a écrit :
On 10-01-2022 21:13, Ondřej Surý wrote:
I thought I filled RM bugs for all of them, but I found only
#1003055 for php-apcu-bc, something must went wrong.
Neither of these support PHP 8.x, and thos
Le 10/01/2022 à 16:44, Paul Gevers a écrit :
On 10-01-2022 21:13, Ondřej Surý wrote:
I thought I filled RM bugs for all of them, but I found only #1003055
for php-apcu-bc, something must went wrong.
Neither of these support PHP 8.x, and those packages should be removed.
Seems like that need
Hi,
On 1/8/22 13:38, Paul Gevers wrote:
php-wmerrors [7], owfs [8].
These two need upstream update.
I see no activity and no bug reports. Can somebody please update these
packages or file appropriate bugs?
Filed #1003432 for php-wmerrors, and am working on it upstream since
it's more inv
Hi,
Back from holidays.
On 01-01-2022 14:20, Ondřej Surý wrote:
Some rebuilds failed, e.g. php-horde-lz4 [6],
The FTBFS is unrelated to PHP 8.1 transition
php-wmerrors [7], owfs [8].
These two need upstream update.
I see no activity and no bug reports. Can somebody please update these
Hi,
Please enlighten me on the details of php packaging that I'm missing and that
we should be aware of for this (and future) transition(s).
Is it true that because the api is already provided in testing that we
now have some packages working with (and pulling in) php7.4 and some
with php8.
Hi
On 01-01-2022 14:20, Ondřej Surý wrote:
2. Generate all binary packages to debian/control during the build,
but this would then require overrides (which I think doesn’t really
scale)
If you mean (re)generating debian/control during build, that's not
allowed (albeit I can't quickly find a ref
> On 1. 1. 2022, at 9:01, Paul Gevers wrote:
>
> Hi,
>
> On 31-12-2021 21:25, Paul Gevers wrote:
>> Hi Ondřej, PHP PECL Maintainers,
>> On 31-12-2021 12:50, Ondřej Surý wrote:
>>> Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to
>>> PHP 8.1
>> Thanks.
>> Will you also
> The removal of the phpapi dependency should be reverted.
This has been now reverted in dh-php 4.4.
I’ve confirmed that it now correctly supports the old style unversioned packages
and the new-style (not yet completely finished) versioned packages, so I guess
it’s good to go.
Ondrej
--
Ondřej S
On 1/1/22 10:18, Kunal Mehta wrote:
On 1/1/22 00:01, Paul Gevers wrote:
It seems I don't understand how PHP packaging works. I scheduled
rebuilds of several packages that were yesterday on the tracker page
[1] when that still only had the phpapi-* listed. Several packages
can't be build yet it
Hi,
On 1/1/22 00:01, Paul Gevers wrote:
It seems I don't understand how PHP packaging works. I scheduled
rebuilds of several packages that were yesterday on the tracker page [1]
when that still only had the phpapi-* listed. Several packages can't be
build yet it seems (because they depend on
Hi,
On 31-12-2021 21:25, Paul Gevers wrote:
Hi Ondřej, PHP PECL Maintainers,
On 31-12-2021 12:50, Ondřej Surý wrote:
Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP
version to PHP 8.1
Thanks.
Will you also upload src:php-imagick, which seems to block some rebuilds
in the cu
Hi Ondřej, PHP PECL Maintainers,
On 31-12-2021 12:50, Ondřej Surý wrote:
Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to PHP
8.1
Thanks.
Will you also upload src:php-imagick, which seems to block some rebuilds
in the current state.
I want to update the ben trans
Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to PHP
8.1
Happy New Year everyone!
Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org
> On 28. 12. 2021, at 11:00, Paul Gevers wrote:
>
> Control: tags -1 confirmed
> Control: severity 1000574 serious
> Control: severity 100
Processing control commands:
> tags -1 confirmed
Bug #976811 [release.debian.org] transition: php8.1
Added tag(s) confirmed.
> severity 1000574 serious
Bug #1000574 [src:phpmyadmin-sql-parser] phpmyadmin-sql-parser: autopkgtest
fails with PHP8.1 (in experimental)
Severity set to 'serious' from 'i
Control: tags -1 confirmed
Control: severity 1000574 serious
Control: severity 1000593 serious
Control: severity 977403 serious
Control: severity 1000642 serious
Control: severity 1000654 serious
Control: severity 1000653 serious
Control: severity 1000619 serious
Control: severity 978457 serious
C
Hi all,
Bugs have been filed (with the exception of the horde stack, but they
are aware) of items we're aware of. Let's give the maintainers a month.
I propose we can start the php8.1 transition around Christmas 2021. Does
that work for you Ondřej?
Paul
OpenPGP_signature
Description: OpenP
Folks,
I just want say sorry that I was so grumpy. I am doing this for too long and I
am tired. Thanks for not picking fight with me.
I will try to do better, but still having a co-maintainer(s) that would help
with the administrivia would help a lot. I can handle most of the technical
stuff,
Hi,
Le 23/11/2021 à 15:57, Paul Gevers a écrit :> On 23-11-2021 11:52,
Ondřej Surý wrote:
[…]
Experimental is the ideal place to find that out. I does require
somebody to go through the regressions and file bug though, this doesn't
happen magically. I think David offered help there.
I’ve ch
Hi,
Le 23/11/2021 à 15:57, Paul Gevers a écrit :
On 23-11-2021 11:52, Ondřej Surý wrote:
On 22. 11. 2021, at 22:28, David Prévot wrote:
I’ve just uploaded a version with your fix.
Thanks a lot.
+1.
David, can we now agree on a timeframe when we start the transition?
[…] it's not up
Hi Ondřej,
On 23-11-2021 11:52, Ondřej Surý wrote:
On 22. 11. 2021, at 22:28, David Prévot wrote:
I’m happy to upload it if you or the release team agree. I don’t
mind if the transition gets started right now either (even if we
have no proper php8.1 as default in experimental to get a grasp of
> On 22. 11. 2021, at 22:28, David Prévot wrote:
>
> I’m happy to upload it if you or the release team agree. I don’t mind if the
> transition gets started right now either (even if we have no proper php8.1 as
> default in experimental to get a grasp of expected issues).
I’ve just uploaded a v
Hi Ondřej,
Le 22/11/2021 à 09:15, David Prévot a écrit :
Le 22/11/2021 à 08:45, Ondřej Surý a écrit :
> Or we could stop delaying the inevitable[1] and instead of bumping
> epoch just go ahead with the transition.
You don’t need to bump epoch
Please find attached a short debdiff that fixes
[ Ondřej, your last mail didn’t make it to the transition bug report,
neither did the previous one. FWIW, I can only see a blank one from your
“Apple Mail” MUA. ]
[ Here is a copy of the sources of your email. I reply after this copy
to try not to add more confusion. ]
Le 22/11/2021 à 10:26,
Le 22/11/2021 à 08:45, Ondřej Surý a écrit :
> Or we could stop delaying the inevitable[1] and instead of bumping
> epoch just go ahead with the transition.
You don’t need to bump epoch (especially on source package and every
binary ones) just to temporarily bump version of one binary package.
Hi Ondřej,
Le 19/11/2021 à 16:41, Ondřej Surý a écrit :
I disagree, but I uploaded reverted package.
Unfortunately, you also need to bump binary packages version. This
revert got rejected:
$ ssh coccia.debian.org cat
/srv/ftp-master.debian.org/queue/reject/php-defaults_87_all-buildd.change
Hi Ondřej,
Le 19/11/2021 à 16:41, Ondřej Surý a écrit :
I disagree, but I uploaded reverted package.
Thank you for your quick action. However, php-defaults 86 as just
uploaded reverted the default PHP version to 8.0, de facto starting a
transition you wanted to skip (and still making it impo
47 matches
Mail list logo
