Bug#911832: Bug#906643: transition: php7.3
On 07/11/2018 20:48, Ondřej Surý wrote: > I solved the doctrine bug, but php-symfony-polyfill 1.10.0 turned out to be > harder nut to crack: > > For reference: > > 1. I removed references for Normalizer::NONE as they were testing if the code > would "assert" (whatever that means in this context) > 2. There was mismatch between declaration of warning() function in > TestListener > 3. I commented out all IDNA2003 tests as I suspect that something has moved > to IDNA2008 and that's causing failure > > And then it started to be beyond my current understanding of the code and the > amount of time I would like to spend fixing it. Are there issues upstream about this? Emilio
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Paul, thank you for all the effort you have put into this. I understand and appreciate the effort. I am basically not objecting to whatever solution there will be, it is ultimately that package maintainer’s decision, and I am sorry I can’t be more helpful, but my free time is limited and all I wanted was to clear the packages preventing faster migration of php-defaults to testing (which I failed anyway because of that last package...) Thanks, Ondřej -- Ondřej Surý > On 9 Nov 2018, at 21:12, Paul Gevers wrote: > > Hi, > >> On 09-11-18 20:09, Ondřej Surý wrote: >> But somehow for this simple package I would just prefer to just bite >> the bullet once in a while, do binNMU and then suffer it through… My >> experience tells me that “the simpler the better” even if it’s not >> perfect. Perfect but complex tend to break in more mysterious way... > > Yes, except that for regressions there may be more people watch (like > me) that will not know these details and waste their time understanding. > > I've just triggered the combination now, but I am not happy yet with the > final outcome. > > Paul >
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Hi, On 09-11-18 20:09, Ondřej Surý wrote: > But somehow for this simple package I would just prefer to just bite > the bullet once in a while, do binNMU and then suffer it through… My > experience tells me that “the simpler the better” even if it’s not > perfect. Perfect but complex tend to break in more mysterious way... Yes, except that for regressions there may be more people watch (like me) that will not know these details and waste their time understanding. I've just triggered the combination now, but I am not happy yet with the final outcome. Paul signature.asc Description: OpenPGP digital signature
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Well, it’s either making the package binNMUable (using generic php-fpm test dependency) or recording the exact dependencies (using php7.3-fpm) or dynamically generating debian/tests/control like I do for php-defaults (which requires much more complex system). But somehow for this simple package I would just prefer to just bite the bullet once in a while, do binNMU and then suffer it through… My experience tells me that “the simpler the better” even if it’s not perfect. Perfect but complex tend to break in more mysterious way... If you can come up with something smarter, then I am sure the maintainer of the package would be all ears. Ondrej -- Ondřej Surý ond...@sury.org > On 9 Nov 2018, at 19:33, Paul Gevers wrote: > > Hi Ondřej, > > On 09-11-18 18:39, OndÅej Surý wrote: >> The versioned depends is needed only for autopkgtests and not for the >> package itself. So, I think the dependency is useless there. > > I misunderstood you then. Still, if a test case of a package requires a > different specific (minimum) version of some other package than the > package itself, the debian/tests/control file could (and in my opinion > should) document that. How could our migration software add the right > triggers otherwise? > > Paul > >> >> Ondrej >> -- >> Ondřej Surý >> >>> On 9 Nov 2018, at 10:37, Paul Gevers wrote: >>> >>> Hi, >>> >>> Hmm, I should read my backlog before replying. >>> On 08-11-18 22:53, Ondřej Surý wrote: But php-defaults and rss-bridge needs to go together. >>> >>> That is ok, but where is this coded in the dependencies? >>> I thought that runtime detection of default PHP version in autopkgtest would be overkill, so the socket path is hardcoded at the build-time. >>> >>> I don't consider runtime detection an issue here. The issue is that the >>> dependency system isn't notified of the relation AFAICT. Options I see >>> are that either rss-bridge needs to tell which version of php it needs, >>> or php-defaults needs to add a versioned breaks on rss-bridge. >>> >>> Paul >>> >> >
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Hi Ondřej, On 09-11-18 18:39, OndÅej Surý wrote: > The versioned depends is needed only for autopkgtests and not for the package > itself. So, I think the dependency is useless there. I misunderstood you then. Still, if a test case of a package requires a different specific (minimum) version of some other package than the package itself, the debian/tests/control file could (and in my opinion should) document that. How could our migration software add the right triggers otherwise? Paul > > Ondrej > -- > Ondřej Surý > >> On 9 Nov 2018, at 10:37, Paul Gevers wrote: >> >> Hi, >> >> Hmm, I should read my backlog before replying. >> >>> On 08-11-18 22:53, Ondřej Surý wrote: >>> But php-defaults and rss-bridge needs to go together. >> >> That is ok, but where is this coded in the dependencies? >> >>> I thought that runtime detection of default PHP version in autopkgtest >>> would be overkill, so the socket path is hardcoded at the build-time. >> >> I don't consider runtime detection an issue here. The issue is that the >> dependency system isn't notified of the relation AFAICT. Options I see >> are that either rss-bridge needs to tell which version of php it needs, >> or php-defaults needs to add a versioned breaks on rss-bridge. >> >> Paul >> > signature.asc Description: OpenPGP digital signature
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
The versioned depends is needed only for autopkgtests and not for the package itself. So, I think the dependency is useless there. Ondrej -- Ondřej Surý > On 9 Nov 2018, at 10:37, Paul Gevers wrote: > > Hi, > > Hmm, I should read my backlog before replying. > >> On 08-11-18 22:53, Ondřej Surý wrote: >> But php-defaults and rss-bridge needs to go together. > > That is ok, but where is this coded in the dependencies? > >> I thought that runtime detection of default PHP version in autopkgtest would >> be overkill, so the socket path is hardcoded at the build-time. > > I don't consider runtime detection an issue here. The issue is that the > dependency system isn't notified of the relation AFAICT. Options I see > are that either rss-bridge needs to tell which version of php it needs, > or php-defaults needs to add a versioned breaks on rss-bridge. > > Paul >
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Hi, Hmm, I should read my backlog before replying. On 08-11-18 22:53, Ondřej Surý wrote: > But php-defaults and rss-bridge needs to go together. That is ok, but where is this coded in the dependencies? > I thought that runtime detection of default PHP version in autopkgtest would > be overkill, so the socket path is hardcoded at the build-time. I don't consider runtime detection an issue here. The issue is that the dependency system isn't notified of the relation AFAICT. Options I see are that either rss-bridge needs to tell which version of php it needs, or php-defaults needs to add a versioned breaks on rss-bridge. Paul signature.asc Description: OpenPGP digital signature
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Hi Ondřej, On 08-11-18 22:47, Ondřej Surý wrote: >> On 9 Nov 2018, at 03:35, Paul Gevers wrote: >> >> You also uploaded (NMU) two revisions of rss-bridge. The last one is >> stuck in unstable because you broke the autopkgtest. > > Umm, no? > > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/rss-bridge/1281281/log.gz > https://ci.debian.net/packages/r/rss-bridge/unstable/amd64/ I should have phrased that differently. Your latest version fails it's autopkgtest when that version is installed in testing. https://ci.debian.net/packages/r/rss-bridge/testing/amd64/ https://qa.debian.org/excuses.php?package=rss-bridge As it passes in unstable, it is probably missing a versioned (test) dependency somewhere. > Also php-doctrine-data-fixture haven’t been run with php-doctrine-orm >= > 2.6.2+dfsg-2 yet in unstable. I just triggered that. > In testing ci, it passes now: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-data-fixtures/1284518/log.gz But in testing php-doctrine-data-fixtures was already passing. So it is good that updating doctrine still passed, but what we want to see if it passes with php-defaults/68. I'll trigger that combination shortly. Paul signature.asc Description: OpenPGP digital signature
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
But php-defaults and rss-bridge needs to go together. I thought that runtime detection of default PHP version in autopkgtest would be overkill, so the socket path is hardcoded at the build-time. Ondrej -- Ondřej Surý ond...@sury.org > On 9 Nov 2018, at 04:47, Ondřej Surý wrote: > > Hi Paul, > > >> On 9 Nov 2018, at 03:35, Paul Gevers wrote: >> >> You also uploaded (NMU) two revisions of rss-bridge. The last one is >> stuck in unstable because you broke the autopkgtest. > > Umm, no? > > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/rss-bridge/1281281/log.gz > https://ci.debian.net/packages/r/rss-bridge/unstable/amd64/ > > I made the package binNMUable… > > Also php-doctrine-data-fixture haven’t been run with php-doctrine-orm >= > 2.6.2+dfsg-2 yet in unstable. > > In testing ci, it passes now: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-data-fixtures/1284518/log.gz > > O. > -- > Ondřej Surý > ond...@sury.org
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Hi Paul, > On 9 Nov 2018, at 03:35, Paul Gevers wrote: > > You also uploaded (NMU) two revisions of rss-bridge. The last one is > stuck in unstable because you broke the autopkgtest. Umm, no? https://ci.debian.net/data/autopkgtest/unstable/amd64/r/rss-bridge/1281281/log.gz https://ci.debian.net/packages/r/rss-bridge/unstable/amd64/ I made the package binNMUable… Also php-doctrine-data-fixture haven’t been run with php-doctrine-orm >= 2.6.2+dfsg-2 yet in unstable. In testing ci, it passes now: https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-data-fixtures/1284518/log.gz O. -- Ondřej Surý ond...@sury.org
Bug#906643: Bug#911832: Bug#906643: transition: php7.3
Hi Ondřej, On 07-11-18 20:48, Ondřej Surý wrote: > I solved the doctrine bug, but php-symfony-polyfill 1.10.0 turned out to be > harder nut to crack: > > For reference: > > 1. I removed references for Normalizer::NONE as they were testing if the code > would "assert" (whatever that means in this context) > 2. There was mismatch between declaration of warning() function in > TestListener > 3. I commented out all IDNA2003 tests as I suspect that something has moved > to IDNA2008 and that's causing failure > > And then it started to be beyond my current understanding of the code and the > amount of time I would like to spend fixing it. You also uploaded (NMU) two revisions of rss-bridge. The last one is stuck in unstable because you broke the autopkgtest. On top of that, the autopkgtest in testing (your first version) still fails with php-defaults, but passes otherwise. Paul signature.asc Description: OpenPGP digital signature
Bug#906643: transition: php7.3
I solved the doctrine bug, but php-symfony-polyfill 1.10.0 turned out to be harder nut to crack: For reference: 1. I removed references for Normalizer::NONE as they were testing if the code would "assert" (whatever that means in this context) 2. There was mismatch between declaration of warning() function in TestListener 3. I commented out all IDNA2003 tests as I suspect that something has moved to IDNA2008 and that's causing failure And then it started to be beyond my current understanding of the code and the amount of time I would like to spend fixing it. Cheers, Ondrej -- Ondřej Surý On Tue, Nov 6, 2018, at 15:41, Emilio Pozuelo Monfort wrote: > On 21/10/2018 07:51, OndÅej Surý wrote: > > Thanks! All look good now. > > > > Now, if you can bump php-defaults, so it migrates earlier and kick > > kopanocore and php-mailparse from testing, and we could remove php7.2 from > > the archive and be done with this transition. > > php-defaults delay is caused by #912114 and #911832. > > Cheers, > Emilio
Bug#906643: transition: php7.3
On 21/10/2018 07:51, OndÅej Surý wrote: > Thanks! All look good now. > > Now, if you can bump php-defaults, so it migrates earlier and kick kopanocore > and php-mailparse from testing, and we could remove php7.2 from the archive > and be done with this transition. php-defaults delay is caused by #912114 and #911832. Cheers, Emilio
Bug#906643: transition: php7.3
Thanks! All look good now. Now, if you can bump php-defaults, so it migrates earlier and kick kopanocore and php-mailparse from testing, and we could remove php7.2 from the archive and be done with this transition. Thank you, Ondřej -- Ondřej Surý > On 20 Oct 2018, at 12:58, Emilio Pozuelo Monfort wrote: > >> On 19/10/2018 19:46, Ondřej Surý wrote: >> Hi, >> >> could you please binNMU these, I hand tested if they build now and they do: >> >> - owfs >> - php-facedetect >> - php-geos >> - php-horde-lz4 >> - php-luasandbox >> - remctl >> - uwsgi-plugin-php >> - wikidiff2 >> >> RC bug filled: >> - kopanocore >> - php-mailparse (doesn’t have support) >> >> - kopanocore also has changed symbols related to g++ transition, so it needs >> another fix >> >> Fixed since last time: >> - zeroc-ice >> - php-pinba > > Scheduled. > > Cheers, > Emilio
Bug#906643: transition: php7.3
On 19/10/2018 19:46, Ondřej Surý wrote: > Hi, > > could you please binNMU these, I hand tested if they build now and they do: > > - owfs > - php-facedetect > - php-geos > - php-horde-lz4 > - php-luasandbox > - remctl > - uwsgi-plugin-php > - wikidiff2 > > RC bug filled: > - kopanocore > - php-mailparse (doesn’t have support) > > - kopanocore also has changed symbols related to g++ transition, so it needs > another fix > > Fixed since last time: > - zeroc-ice > - php-pinba Scheduled. Cheers, Emilio
Bug#906643: transition: php7.3
Hi, could you please binNMU these, I hand tested if they build now and they do: - owfs - php-facedetect - php-geos - php-horde-lz4 - php-luasandbox - remctl - uwsgi-plugin-php - wikidiff2 RC bug filled: - kopanocore - php-mailparse (doesn’t have support) - kopanocore also has changed symbols related to g++ transition, so it needs another fix Fixed since last time: - zeroc-ice - php-pinba -- Ondřej Surý ond...@sury.org > On 9 Oct 2018, at 16:32, Emilio Pozuelo Monfort wrote: > > On 09/10/2018 15:56, Ondřej Surý wrote: >> Hi, >> >> Packages that need bump of the default PHP version, it just builds for the >> default version >> - kopanocore >> - owfs >> - php-facedetect >> - php-geos >> - php-horde-lz4 >> - php-luasandbox >> - remctl >> - uwsgi-plugin-php >> - wikidiff2 >> >> FTBFS related to PHP 7.3: >> - php-mailparse >> - php-pinba >> >> FTBFS unrelated to PHP 7.3: >> - zeroc-ice #910665 >> >> Uploaded fixed versions: >> - tideways >> - libvirt-php >> - xdebug >> - php-apcu-bc >> >> >> I think this is mostly sane status, so what about if I upload php-defaults >> with just PHP 7.3 to unstable, and we do the final round of binNMUs when it >> lands there? > > Sounds good. Go ahead. > > Emilio
Bug#906643: transition: php7.3
On 09/10/2018 15:56, Ondřej Surý wrote: > Hi, > > Packages that need bump of the default PHP version, it just builds for the > default version > - kopanocore > - owfs > - php-facedetect > - php-geos > - php-horde-lz4 > - php-luasandbox > - remctl > - uwsgi-plugin-php > - wikidiff2 > > FTBFS related to PHP 7.3: > - php-mailparse > - php-pinba > > FTBFS unrelated to PHP 7.3: > - zeroc-ice #910665 > > Uploaded fixed versions: > - tideways > - libvirt-php > - xdebug > - php-apcu-bc > > > I think this is mostly sane status, so what about if I upload php-defaults > with just PHP 7.3 to unstable, and we do the final round of binNMUs when it > lands there? Sounds good. Go ahead. Emilio
Bug#906643: transition: php7.3
Hi, Packages that need bump of the default PHP version, it just builds for the default version - kopanocore - owfs - php-facedetect - php-geos - php-horde-lz4 - php-luasandbox - remctl - uwsgi-plugin-php - wikidiff2 FTBFS related to PHP 7.3: - php-mailparse - php-pinba FTBFS unrelated to PHP 7.3: - zeroc-ice #910665 Uploaded fixed versions: - tideways - libvirt-php - xdebug - php-apcu-bc I think this is mostly sane status, so what about if I upload php-defaults with just PHP 7.3 to unstable, and we do the final round of binNMUs when it lands there? Cheers, Ondrej -- Ondřej Surý ond...@sury.org > On 8 Oct 2018, at 20:52, Emilio Pozuelo Monfort wrote: > > On 07/10/2018 20:21, Ondřej Surý wrote: >> Dammit, I completely forgot the phpapi change between the beta and the RC >> :(. Sorry about that. >> >> The good should be: 20180731 >> >> The bad should be: 20180606 and 20170718 >> >> e.g. those binNMUs were wasted time :( and they will need to be triggered >> again. Sorry for that. > > No problem. I updated the tracker and scheduled binNMUs again. > > Some modules fail to build against 7.3, see the tracker: > > https://release.debian.org/transitions/html/php7.3.html > > Cheers, > Emilio
Bug#906643: transition: php7.3
On 07/10/2018 20:21, Ondřej Surý wrote: > Dammit, I completely forgot the phpapi change between the beta and the RC :(. > Sorry about that. > > The good should be: 20180731 > > The bad should be: 20180606 and 20170718 > > e.g. those binNMUs were wasted time :( and they will need to be triggered > again. Sorry for that. No problem. I updated the tracker and scheduled binNMUs again. Some modules fail to build against 7.3, see the tracker: https://release.debian.org/transitions/html/php7.3.html Cheers, Emilio
Bug#906643: transition: php7.3
Dammit, I completely forgot the phpapi change between the beta and the RC :(. Sorry about that. The good should be: 20180731 The bad should be: 20180606 and 20170718 e.g. those binNMUs were wasted time :( and they will need to be triggered again. Sorry for that. Thanks, Ondrej -- Ondřej Surý On Sun, Oct 7, 2018, at 12:08, Emilio Pozuelo Monfort wrote: > On 02/10/2018 21:00, Emilio Pozuelo Monfort wrote: > > Control: tags -1 confirmed > > Control: forwarded -1 > > https://release.debian.org/transitions/html/php7.3.html > > > > On 19/08/2018 08:49, Ondřej Surý wrote: > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: transition > >> > >> Hi, > >> > >> with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2 > >> to PHP 7.3, so we have the latest PHP version in Debian buster, so the > >> security support can be provided by upstream as longest as possible. > > > > Since the transition has started, let's mark it as such. > > > >> title = "php7.3"; > >> is_affected = .depends ~ "phpapi-20170718" | .depends ~ "phpapi-20180606"; > >> is_good = .depends ~ "phpapi-20180606"; > >> is_bad = .depends ~ "phpapi-20170718"; > > > > I have added & ! .depends ~ "phpapi-20180606" to is_bad, so that packages > > that > > depend on both are marked as good and not as "partial" (both good and bad). > > Once > > we have things rebuilt and 7.2 support is dropped from -defaults, we can > > change > > the tracker and rebuild things again to lose 7.2 dependencies. If things > > don't > > take long (i.e. any ftbfs or other bugs are fixed promptly) I think we can > > finish this before the transition freeze. > > Should we add phpapi-20180731 to is_good? Packages are getting that now, > see e.g.: > > https://buildd.debian.org/status/fetch.php?pkg=php-propro=mipsel=2.1.0%2B1.0.2-1%2Bb1=1538764097=0 > > Emilio
Bug#906643: transition: php7.3
On 02/10/2018 21:00, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > Control: forwarded -1 https://release.debian.org/transitions/html/php7.3.html > > On 19/08/2018 08:49, Ondřej Surý wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi, >> >> with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2 >> to PHP 7.3, so we have the latest PHP version in Debian buster, so the >> security support can be provided by upstream as longest as possible. > > Since the transition has started, let's mark it as such. > >> title = "php7.3"; >> is_affected = .depends ~ "phpapi-20170718" | .depends ~ "phpapi-20180606"; >> is_good = .depends ~ "phpapi-20180606"; >> is_bad = .depends ~ "phpapi-20170718"; > > I have added & ! .depends ~ "phpapi-20180606" to is_bad, so that packages that > depend on both are marked as good and not as "partial" (both good and bad). > Once > we have things rebuilt and 7.2 support is dropped from -defaults, we can > change > the tracker and rebuild things again to lose 7.2 dependencies. If things don't > take long (i.e. any ftbfs or other bugs are fixed promptly) I think we can > finish this before the transition freeze. Should we add phpapi-20180731 to is_good? Packages are getting that now, see e.g.: https://buildd.debian.org/status/fetch.php?pkg=php-propro=mipsel=2.1.0%2B1.0.2-1%2Bb1=1538764097=0 Emilio
Bug#906643: transition: php7.3
Control: tags -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/php7.3.html On 19/08/2018 08:49, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2 > to PHP 7.3, so we have the latest PHP version in Debian buster, so the > security support can be provided by upstream as longest as possible. Since the transition has started, let's mark it as such. > title = "php7.3"; > is_affected = .depends ~ "phpapi-20170718" | .depends ~ "phpapi-20180606"; > is_good = .depends ~ "phpapi-20180606"; > is_bad = .depends ~ "phpapi-20170718"; I have added & ! .depends ~ "phpapi-20180606" to is_bad, so that packages that depend on both are marked as good and not as "partial" (both good and bad). Once we have things rebuilt and 7.2 support is dropped from -defaults, we can change the tracker and rebuild things again to lose 7.2 dependencies. If things don't take long (i.e. any ftbfs or other bugs are fixed promptly) I think we can finish this before the transition freeze. Cheers, Emilio
Bug#906643: transition: php7.3
Hi Emilio, I already started doing some extension builds pulling patches from Remi Collet: $ grep 7\\.3.*patches */debian/changelog php-amqp/debian/changelog: * Add PHP 7.3 patches (Courtesy of Remi Collet) php-memcached/debian/changelog: * Add PHP 7.3 compatibility patches (Courtesy of Remi Collet) php-msgpack/debian/changelog: * Add PHP 7.3 compatibility patches (Pulled from Remi's RPM repository) But I didn’t have a solid block of free time to do thorough testing yet. I’ll enable the PHP 7.3 in my deb.sury.org repositories and try rebuilding the packages when I clear the mistake that removed all packages from the repository (ARM packages are still building). Ondrej -- Ondřej Surý ond...@sury.org > On 2 Oct 2018, at 09:40, Emilio Pozuelo Monfort wrote: > > On 19/08/2018 08:49, Ondřej Surý wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi, >> >> with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2 >> to PHP 7.3, so we have the latest PHP version in Debian buster, so the >> security support can be provided by upstream as longest as possible. > > This sounds good, but I'd like to see 7.0 and 7.1 out of testing first. > > Also, have you done a rebuild? How many issues did you find? > > Cheers, > Emilio
Bug#906643: transition: php7.3
On 19/08/2018 08:49, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2 > to PHP 7.3, so we have the latest PHP version in Debian buster, so the > security support can be provided by upstream as longest as possible. This sounds good, but I'd like to see 7.0 and 7.1 out of testing first. Also, have you done a rebuild? How many issues did you find? Cheers, Emilio
Bug#906643: transition: php7.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2 to PHP 7.3, so we have the latest PHP version in Debian buster, so the security support can be provided by upstream as longest as possible. Ben file: title = "php7.3"; is_affected = .depends ~ "phpapi-20170718" | .depends ~ "phpapi-20180606"; is_good = .depends ~ "phpapi-20180606"; is_bad = .depends ~ "phpapi-20170718"; - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlt5EtxfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcKBXRAAkZapeLsm0iqa1gMKdOAgotkuf8cxxsGKtNBQ4s5LefvGXmbzFTEQRMzq 9XnIfvvoZIa2epbnfWLO5eESFfe+K+3L8uxE93AQvkYdV34Otd9uvUXOZHDHYSpf tmL8lEz0WzsiaTCplzBaTHee0334nhndl9YIrIE4LHWy8NYOPrbELgBsSI30vM4e eBgOrBanzXcf1pqfqlO9QTzYq3UAV8rQYM2OU/K+l9NHSR2IIs+DlTXJBbdkxrEb 65yQg1yrCrLoNfwhx2DEpzALSZD9hkTFIg+to7lsuCTSNYkjUqsiUhlMrfk9/dRh FjN6qI/pZShMjFrm8FRjd3xhGSLlxmmZ+lTLyoQhB3EiCaoPv+uRPStYzLQ4zADV LCy9GaFhMk2Yv1Lrak9XvWP1FpGNMLpxhQwItYpB61A7xk6UtRGhAcAkXoirwOeL +Snq491ogXhNMr3Am3GfgaT5MlOKlj4SjCoMxZH1Cnf+7mixGzUYqHcjIM8DvDhy kVKwDidL/kZ2Dzr6ltsT8u9/mgK9i4b7Y/j9QrM8Wb6DT2ayzjoVnTk0G/pAownX DpMCA2ftYk8UcZ521uGjau9k5LOf7dRaAOsKCcey7f4+egQqQQwT50bJYdfzz9JK DPpUhi/FRLO/skQL/pWjbl1vptMY3Um7UmKp4doUtbQ5beGYb+o= =Ov8A -END PGP SIGNATURE-
