Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
I tried to use sbuild with --no-arch-all --no-arch-any --source-only-changes and upload the result, so we’ll see how it goes. If it doesn’t go through, I’ll do the full fledged build tomorrow. O. -- Ondřej Surý ond...@sury.org > On 13 Apr 2019, at 18:04, Ivo De Decker wrote: > > Control: tags -1 pending > > Hi, > > On 4/13/19 5:56 PM, Ondřej Surý wrote: >> the omission was not intentional, just a result of travel, family and >> gaveling to remember too many things at once. > > No worries :) > >> I’ll try to do a new upload when the kids fall asleep. I agree that fixing >> buster is the only priority, I can handle the rest. It should be fairly easy >> as there’s no new upstream release for 7.0, so I’ll just follow different >> numbering schemes for external (7.0.33-<1,inf)) vs stretch >> (7.0.33-0+deb7u<1,inf), so the conflict will be (<< 7.0.33-1~ and it should >> just work fine. > > That sounds good, thanks! I tagged this bug pending. > > Please note that there's also the autopkgtest for symfony which succeeds with > the old php in testing, but feels with the new version in unstable (bugs > #926883). That will need some kind of fix to allow the new php to migrate. > > Cheers, > > Ivo
Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
Control: tags -1 pending Hi, On 4/13/19 5:56 PM, Ondřej Surý wrote: the omission was not intentional, just a result of travel, family and gaveling to remember too many things at once. No worries :) I’ll try to do a new upload when the kids fall asleep. I agree that fixing buster is the only priority, I can handle the rest. It should be fairly easy as there’s no new upstream release for 7.0, so I’ll just follow different numbering schemes for external (7.0.33-<1,inf)) vs stretch (7.0.33-0+deb7u<1,inf), so the conflict will be (<< 7.0.33-1~ and it should just work fine. That sounds good, thanks! I tagged this bug pending. Please note that there's also the autopkgtest for symfony which succeeds with the old php in testing, but feels with the new version in unstable (bugs #926883). That will need some kind of fix to allow the new php to migrate. Cheers, Ivo
Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
Hi,
the omission was not intentional, just a result of travel, family and gaveling
to remember too many things at once.
I’ll try to do a new upload when the kids fall asleep. I agree that fixing
buster is the only priority, I can handle the rest. It should be fairly easy as
there’s no new upstream release for 7.0, so I’ll just follow different
numbering schemes for external (7.0.33-<1,inf)) vs stretch
(7.0.33-0+deb7u<1,inf), so the conflict will be (<< 7.0.33-1~ and it should
just work fine.
Ondrej
--
Ondřej Surý
> On 13 Apr 2019, at 15:00, Ivo De Decker wrote:
>
> Hi,
>
>> On Wed, Apr 03, 2019 at 09:15:28PM +0200, Andreas Beckmann wrote:
>>> On 2019-04-03 13:45, Ondřej Surý wrote:
>>> Hi Andreas,
>>>
>>> there will be new upstream release of PHP 7.3 this week, so I’ll handle it
>>> as one batch, ok?
>
> I see you uploaded this new version to unstable without a fix for this bug.
>
>>> I just wonder if there’s a way how to fix that without breaking
>>> co-installability with php7.0-curl from external repositories.
>>
>> How does such a package look like? What dependencies does it have?
>> What's the versioning scheme?
>
> Do you have a pointer to those external repositories?
>
> If we can find a nice solution, that would be ok, but if not, I think fixing
> this issue in buster is more important than supporting external repositories.
>
>> We could try a Breaks: libcurl3 in php7.3-common.
>> ... trying ...
>> Nope, that only make it worse.
>>
>> Is stretch getting new php 7.0 point releases? In that case we can't
>> have a versioned
>> Breaks: php7.0-curl (<< external-repo-version-newer-than-stretch)
>> that will continue to be valid. (Unless the external repo versions come
>> with an epoch)
>>
>>> What if we fixed this in php7.0-curl package? (I keep separate sources for
>>> it.)
>>
>> I don't think there is much fixable in php7.0-curl, its the
>> libcurl{3->4} transition biting us here ...
>>
>> The big hammer that should work is
>> gcc-8-base: Breaks: libcurl3
>> but it's a completely unrelated package ...
>
> That doesn't seem like a realistic solution.
>
> Cheers,
>
> Ivo
>
Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
Hi,
On Wed, Apr 03, 2019 at 09:15:28PM +0200, Andreas Beckmann wrote:
> On 2019-04-03 13:45, Ondřej Surý wrote:
> > Hi Andreas,
> >
> > there will be new upstream release of PHP 7.3 this week, so I’ll handle it
> > as one batch, ok?
I see you uploaded this new version to unstable without a fix for this bug.
> > I just wonder if there’s a way how to fix that without breaking
> > co-installability with php7.0-curl from external repositories.
>
> How does such a package look like? What dependencies does it have?
> What's the versioning scheme?
Do you have a pointer to those external repositories?
If we can find a nice solution, that would be ok, but if not, I think fixing
this issue in buster is more important than supporting external repositories.
> We could try a Breaks: libcurl3 in php7.3-common.
> ... trying ...
> Nope, that only make it worse.
>
> Is stretch getting new php 7.0 point releases? In that case we can't
> have a versioned
> Breaks: php7.0-curl (<< external-repo-version-newer-than-stretch)
> that will continue to be valid. (Unless the external repo versions come
> with an epoch)
>
> > What if we fixed this in php7.0-curl package? (I keep separate sources for
> > it.)
>
> I don't think there is much fixable in php7.0-curl, its the
> libcurl{3->4} transition biting us here ...
>
> The big hammer that should work is
> gcc-8-base: Breaks: libcurl3
> but it's a completely unrelated package ...
That doesn't seem like a realistic solution.
Cheers,
Ivo
Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
On 2019-04-03 13:45, Ondřej Surý wrote:
> Hi Andreas,
>
> there will be new upstream release of PHP 7.3 this week, so I’ll handle it as
> one batch, ok?
That's fine.
> I just wonder if there’s a way how to fix that without breaking
> co-installability with php7.0-curl from external repositories.
How does such a package look like? What dependencies does it have?
What's the versioning scheme?
We could try a Breaks: libcurl3 in php7.3-common.
... trying ...
Nope, that only make it worse.
Is stretch getting new php 7.0 point releases? In that case we can't
have a versioned
Breaks: php7.0-curl (<< external-repo-version-newer-than-stretch)
that will continue to be valid. (Unless the external repo versions come
with an epoch)
> What if we fixed this in php7.0-curl package? (I keep separate sources for
> it.)
I don't think there is much fixable in php7.0-curl, its the
libcurl{3->4} transition biting us here ...
The big hammer that should work is
gcc-8-base: Breaks: libcurl3
but it's a completely unrelated package ...
Andreas
Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
Hi Andreas, there will be new upstream release of PHP 7.3 this week, so I’ll handle it as one batch, ok? I just wonder if there’s a way how to fix that without breaking co-installability with php7.0-curl from external repositories. What if we fixed this in php7.0-curl package? (I keep separate sources for it.) Ondrej -- Ondřej Surý ond...@sury.org > On 23 Mar 2019, at 16:50, Andreas Beckmann wrote: > > Followup-For: Bug #925106 > > Hi, > > next round, let's add a Breaks: gforge-common (<< 6), too. > That's the version from jessie (there is no gforge-common in stretch, so > the jessie version may be kept installed on long grown system upgrades), > which will fail to remove under php7.3: > > Removing gforge-shell-postgresql (5.3.2+20141104-3+deb8u3) ... > PHP Deprecated: Methods with the same name as their class will not be > constructors in a future version of PHP; Error has a deprecated constructor > in /usr/share/gforge/common/include/Error.class.php on line 36 > PHP Fatal error: Cannot declare class Error, because the name is already in > use in /usr/share/gforge/common/include/Error.class.php on line 36 > dpkg: error processing package gforge-shell-postgresql (--remove): > installed gforge-shell-postgresql package pre-removal script subprocess > returned error exit status 255 > > This happens in multiple gforge packages, but can be prevented by > uninstalling it before php7.3 gets installed. > > > Andreas >
Bug#925106: php7.3-common: please add Breaks: php7.0-curl, gforge-common (<< 6)
Followup-For: Bug #925106
Hi,
next round, let's add a Breaks: gforge-common (<< 6), too.
That's the version from jessie (there is no gforge-common in stretch, so
the jessie version may be kept installed on long grown system upgrades),
which will fail to remove under php7.3:
Removing gforge-shell-postgresql (5.3.2+20141104-3+deb8u3) ...
PHP Deprecated: Methods with the same name as their class will not be
constructors in a future version of PHP; Error has a deprecated constructor in
/usr/share/gforge/common/include/Error.class.php on line 36
PHP Fatal error: Cannot declare class Error, because the name is already in
use in /usr/share/gforge/common/include/Error.class.php on line 36
dpkg: error processing package gforge-shell-postgresql (--remove):
installed gforge-shell-postgresql package pre-removal script subprocess
returned error exit status 255
This happens in multiple gforge packages, but can be prevented by
uninstalling it before php7.3 gets installed.
Andreas
diff -Nru php7.3-7.3.3/debian/changelog php7.3-7.3.3/debian/changelog
--- php7.3-7.3.3/debian/changelog 2019-03-07 20:43:34.0 +0100
+++ php7.3-7.3.3/debian/changelog 2019-03-19 04:03:09.0 +0100
@@ -1,3 +1,14 @@
+php7.3 (7.3.3-2) UNRELEASED; urgency=medium
+
+ * php7.3-common: Add Breaks against php7.0-curl for smoother upgrades from
+stretch. (Closes: #925106)
+ * php7.3-common: Add Breaks against gforge-common from jessie which uses a
+deprecated constructor syntax.
+ * Deterministically generate debian/control by sorting the extension
+packages.
+
+ -- Andreas Beckmann Tue, 19 Mar 2019 04:03:09 +0100
+
php7.3 (7.3.3-1) unstable; urgency=medium
* New upstream version 7.3.3
diff -Nru php7.3-7.3.3/debian/php-common.substvars.extra
php7.3-7.3.3/debian/php-common.substvars.extra
--- php7.3-7.3.3/debian/php-common.substvars.extra 2019-03-07
20:43:34.0 +0100
+++ php7.3-7.3.3/debian/php-common.substvars.extra 2019-03-19
04:03:09.0 +0100
@@ -1 +1 @@
-php-common:Breaks=php7.2-sodium
+php-common:Breaks=php7.0-curl, php7.2-sodium, gforge-common (<< 6)
diff -Nru php7.3-7.3.3/debian/rules php7.3-7.3.3/debian/rules
--- php7.3-7.3.3/debian/rules 2019-03-07 20:43:34.0 +0100
+++ php7.3-7.3.3/debian/rules 2019-03-19 04:03:09.0 +0100
@@ -607,7 +607,7 @@
debian/control: debian/control.in debian/rules debian/changelog
debian/source.lintian-overrides debian/rules.d/* debian/php-module.control.in
$(SED) -e "s/@PHP_VERSION@/$(PHP_NAME_VERSION)/g" -e
"s/@BUILT_USING@/$(BUILT_USING)/g" >$@ <$<
- for ext in $(ext_PACKAGES); do \
+ for ext in $(sort $(ext_PACKAGES)); do \
package=php$(PHP_NAME_VERSION)-$${ext}; \
description=$$(eval echo \$${$${ext}_DESCRIPTION}); \
echo >>$@; \
