luajit2 vs luajit - cleanup

[Ondřej Surý]

Hi Mo,

since you package the luajit 2.1 for the second time as luajit2,
could you also cleanup the mess you've created as there are
now two packages providing luajit 2.1? You are listed as
co-maintainer in the both packages, so the reason to package
luajit2 is elusive to me. Since there are fewer dependencies
for luajit2, it might be easier to just update luajit and drop
luajit2.

Ccing release and security teams - just FYI, not action needed,
but double packaging of the same library has both release
and security implications (more work).

### luajit

Checking reverse dependencies...
# Broken Depends:
lua-ljsyscall: lua-ljsyscall

# Broken Build-Depends:
bpfcc: libluajit-5.1-dev
   luajit
cantor: libluajit-5.1-dev
dnsjit: libluajit-5.1-dev
luajit
ettercap: libluajit-5.1-dev
knot-resolver: libluajit-5.1-dev
   luajit
lua-ljsyscall: luajit
luakit: libluajit-5.1-dev
luajit
nageru: libluajit-5.1-dev
neovim: luajit
obs-studio: libluajit-5.1-dev
openmw: libluajit-5.1-dev
satdump: libluajit-5.1-dev
snort: libluajit-5.1-dev
suricata: libluajit-5.1-dev
uftrace: libluajit-5.1-dev
uwsgi-plugin-luajit: libluajit-5.1-dev
vcmi/contrib: libluajit-5.1-dev
wrk: libluajit-5.1-dev
 luajit

Dependency problem found.

### luajit2

Checking reverse dependencies...
# Broken Depends:
lua-resty-core: lua-resty-core
lua-resty-lrucache: lua-resty-lrucache
luajit: libluajit-5.1-2 [s390x]
libluajit-5.1-dev [s390x]
luajit [s390x]

# Broken Build-Depends:
libnginx-mod-http-lua: libluajit2-5.1-dev
love: libluajit2-5.1-dev
sysbench: libluajit2-5.1-dev

Dependency problem found.

Thanks,
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#1037263: unblock: php8.2/8.2.7-1

[Ondřej Surý]

> On 9. 6. 2023, at 20:03, Paul Gevers  wrote:
> 
> Hi Ondřej,
> 
>> On 09-06-2023 18:58, Ondřej Surý wrote:
>> php8.2 8.2.7-1 is a security release, so it would be pretty
>> wrong to release bookworm with the old PHP.  I am sorry for
>> the timing, but that's just coincidence.
> 
> Sorry, but this is really about 1 week too late (we are in the quite periode 
> to prepare for tomorrow). From last weekend on security issues are handled by 
> the security team. Otherwise you can prepare a point release update, but 
> that's handled with different usertags and meta data.

I’ve already reached to the security team, so I guess we’ll handle it there. I 
didn’t know that bookworm-security has been open now.

Thanks,
Ondřej
--
Ondřej Surý  (He/Him)

> Paul

Bug#1037263: unblock: php8.2/8.2.7-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package php8.2

Hi,

php8.2 8.2.7-1 is a security release, so it would be pretty
wrong to release bookworm with the old PHP.  I am sorry for
the timing, but that's just coincidence.

[ Reason ]
This is in line with previous request as discussed in #1033492
and sanctioned by security team.

[ Impact ]
Releasing Debian bookworm with known security vulnerability.

[ Tests ]
There's autopkg tests and people are also using this already since yesterday
from my PPAs that usually has hundred thousands of users.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
The package itself is building right now and will be uploaded in hour or so.

unblock php8.2/8.2.7-1


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmSDWjtfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJ4ZBAAol2eQPvGxi5eLkPaJMwHGLCE0XysPDNQJUTRaiXncC0NiwaumvQyDmEs
HdbIwznbsKWGtCnusFvKj/JtqN4BJCFDNwZe9a8dhGkiTRi4HmZDvlW/p6fXD+gg
gCnQqXNSGWrfZgo4W1HUc1KPft/3kzkKFMsAFwV8mknagLttH2uRdzpgQzMFCEIk
3yPanlFbNhuCv4SUy//Bzp+txvBIE952TKqBbcUId6QquDs1SeppB0gIT5jOzQ6l
vJeKjGT8yGVn0MVOimVYVC1PuulI9BiWB53NN3v+2PikasmOcX6VoCmS6jJtNQqs
QryZAQiqYJzAEcqZM6/gGGLEwqYUaCoqu5aND5GwJAIsloo1YQSclUWUASEc+EKV
fujFL3LzuHksx1IXAstujp/ltuk8u2GIlWqMQxXaLJ+QC/S99EYmARaC8veX8m4t
q4/pacIcjtfBoUCm1mzWRFDpqxSwK/clnEFlrMHf5dB/9Gc17rpeKLdYIrz34Ke4
RywSG8VAq8pepGQ5/2oWCKfyOnBd78rjZ6cdegdT0WhtOO/c70GKRMspM0bnGkIZ
3e/GY65Cb64Axb+e/dX8smRYWhDMtuVL3LFgpRIoPS5tIwNaW3ADjr1Ed1roB5eS
il9Sf4cJkjTKZOHCB54MxtBnbgV5/DyX0pJijGp4iCLdL0y04/o=
=Yf9P
-END PGP SIGNATURE-

Bug#1034906: unblock: php8.2/8.2.5-2

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package php8.2

See the reasoning in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033492

Additional to the new upstream version, there are two fixes:

1. hardcoding the /bin/sed

2. the reproducible-builds tweak to the phar utility

Both are low-risk and I have reviewed all the changes myself.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

unblock php8.2/8.2.5-2


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmRKOJlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKEgBAAhyUzzB0qjxgcGhCdKGrkMGSiSBtBit2ulBDgAnkJaMfU6NeYiXCEKq2o
u18nD+H4zc+qlcIAU63ejQNXCx/uKzdgDdWPnnsuLeX8I2Kg5HNFo/6GMih+mhO3
BDUN5jNPWndsgik9NT5C00HKrKUQ95gj3+kraGn5noAFB6/STGWkiiV/DKW20mou
dETwoNMjGdYDT530HSiHeURZXjgUXwHyOlgJ5sgoDUzNnYjdhQEH+BcinwO+VQOr
516dUg2saT88M520Bg1zpdkm9qqsuNhjN2VBEaN4+G+qlWXERdfyVQK+AsXxf7t2
w62h9/pW+mdII2Nd579jjfNdroxU3JjnE0Tta7gtuDIVz3+CMXKRcyX8WylSDwer
O16RUUqsvKR+YBLSiOxDpDMXnuktspY6qEH9AXJIOGud9DMPwTL52VRchwH098Jg
D8kBIMziE8JNKs/M0486hBvyqM2tQGKw6h+dd+Ice6Gkag8K8gns1b58oe5QAx9I
1DHZlilwCgXHKXOvKA2HHsInW6aHWrTRCuxzlzA9XScDnQmGB3dnY7vo7g57c/4y
K/CTZDAkE+2gvZtWfOdHvrVZLQdmxAqS251CGFmEUy9vOzgBJdevf8VmjIb0lSAW
rVohQOajWJecKKd5meRc2TR7JJK9D4oefgxbd9i3vPpdP+jEhIc=
=OEcy
-END PGP SIGNATURE-

Bug#1033492: unblock: php8.2/8.2.4-1 ????

[Ondřej Surý]

> On 4. 4. 2023, at 21:14, Paul Gevers  wrote:
> 
> Sorry, that wasn't my intention. Maybe I should try to keep a better log, as 
> there's not many things "pre-negotiated". My memory isn't great. If you would 
> have pointed me at the earlier discussion, all would have been well I assume.

No need to apologise, we all do what we can. If there's anything I can do to 
help with the load, I am happy to do whatever I would have energy and time for. 
(I don't want to promise unicorns and rainbows :)).

On my side it's src:bind9 for both buster and bookworm and src:php7.4 for 
buster and src:php8.2 for bookworm.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



signature.asc
Description: Message signed with OpenPGP

Bug#1033492: unblock: php8.2/8.2.4-1 ????

[Ondřej Surý]

Hi Paul, Salvatore,

I've finally got some time here.

In all honesty, I thought that the pre-negotiated exception for PHP
does apply to all future Debian releases, so it did come as surprise
that I have to explain this again.

The quality of PHP in Debian has increased since we started using
upstream versions to fix security bugs.

The basic release policy is described here:
https://www.php.net/supported-versions.php

> Each release branch of PHP is fully supported for two years from its initial 
> stable release. During this period, bugs and security issues that have been 
> reported are fixed and are released in regular point releases.
> 
> After this two year period of active support, each branch is then supported 
> for an additional year for critical security issues only. Releases during 
> this period are made on an as-needed basis: there may be multiple point 
> releases, or none, depending on the number of reports.
> 
> Once the three years of support are completed, the branch reaches its end of 
> life and is no longer supported. A table of end-of-life branches is available.

There's also a process for introducing new features to the **major** releases: 
https://wiki.php.net/rfc, but that doesn't apply here as we are sticking with a 
single **major** release branch (PHP 8.2); no new features are introduced to 
the single release track.

Upstream makes a new release every four weeks 
(https://www.php.net/ChangeLog-8.php#8.2.4), but we generally only update to 
the releases that contain security fixes, and I don't use PU process to lighten 
the strain on the release team.

Apart from the upstream release process, all the PHP releases are regularly 
tested via external repositories that I maintain, so even the intermediate 
releases are thoroughly tested by hundreds of thousands or more - the Debian 
repository has 5+ TB of traffic and 150M+ hits; I have no statistics from the 
deployment, but any breakages are very quickly reported.

When the upstream security support ceases, I generally use Remi Collet's 
php-security repository to pull the security fixes for the last upstream 
release, as he's usually swift in preparing those.

Unblocking the latest php8.2 (8.2.4-1 and 8.2.5-1 next week) would be 
appreciated so the next Debian stable releases with the current PHP version.

Cheers,
Ondrej

On Tue, Mar 28, 2023, at 20:46, Salvatore Bonaccorso wrote:
Hi Paul,

On Sun, Mar 26, 2023 at 01:40:10PM +0200, Paul Gevers wrote:
> Hi Ondřej,
> 
> On 26-03-2023 08:36, Ondřej Surý wrote:
> > just a quick reply - PHP already has a security (and if I remember 
> > correctly release) team exception from the last time. So, we already had 
> > this talk about upstream policies.
> 
> I *suspect* the same, but because of the shear amount of work ongoing for
> the release team at the moment, I hope people can help point to the relevant
> information instead of us needing to find it.
> 
> It can obviously wait a couple of days, we're not *that* close to releasing
> yet.

if this helps on the decision: We would, similarly as done for
bullseye already, want to follow the upstream releases until supported
by upstream and then switch to cherry-pick security fixes only on top.

Ondrej can give a more detailed input, so please wait for his reply.

Regards,
Salvatore


--
Ondřej Surý (He/Him)
ond...@sury.org

Re: Bug#1033492: unblock: php8.2/8.2.4-1 ????

[Ondřej Surý]

Paul,

just a quick reply - PHP already has a security (and if I remember correctly 
release) team exception from the last time. So, we already had this talk about 
upstream policies.

I’m happy to fill the template though when it’s not Sunday.

Ondrej
--
Ondřej Surý  (He/Him)

> On 26. 3. 2023, at 8:15, Paul Gevers  wrote:
> 
> Package: release.debian.org
> Tags: moreinfo
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: ond...@sury.org
> Control: affects -1 src:php8.2
> 
> Dear Ondřej,
> 
> I just noticed that security bug 1031368 is fixed in unstable was fixed in 
> php8.2 version 8.2.3-1. That didn't migrate to testing because we're in the 
> freeze [1], you didn't request an unblock and (to be honest) I deferred when 
> I looked a while back because it involves a new upstream release. New 
> upstream versions are in principle against the freeze policy unless it's a 
> targeted-fix-only release. From a quick look at the upstream NEWS file, that 
> could very well be the case, can you confirm that? I'd like you to provide us 
> the usual information we use in the unblock process so I have added the 
> reportbug template below as an aid; the biggest question I have is: can you 
> point us at the upstream policy that explains what goes into their stable 
> releases?
> 
> php8.2 is a key package.
> 
> Paul
> 
> [1] https://release.debian.org/testing/freeze_policy.html#hard
> 
> Please unblock package php8.2
> 
> (Please provide enough (but not too much) information to help
> the release team to judge the request efficiently. E.g. by
> filling in the sections below.)
> 
> [ Reason ]
> (Explain what the reason for the unblock request is.)
> 
> [ Impact ]
> (What is the impact for the user if the unblock isn't granted?)
> 
> [ Tests ]
> (What automated or manual tests cover the affected code?)
> 
> [ Risks ]
> (Discussion of the risks involved. E.g. code is trivial or
> complex, key package vs leaf package, alternatives available.)
> 
> [ Checklist ]
>  [ ] all changes are documented in the d/changelog
>  [ ] I reviewed all changes and I approve them
>  [ ] attach debdiff against the package in testing
> 
> [ Other info ]
> (Anything else the release team should know.)
> 
> unblock php8.2/8.2.4-1
> 

Bug#1033034: unblock: libmemcached/1.1.4-1

[Ondřej Surý]

 memrm
-memslap
-memstat
-memtouch
+capable
+cat
+cp
+dump
+error
+exist
+flush
+parse
+ping
+rm
+slap
+stat
+touch
 )
 
 add_subdirectory(include)
diff -Nru libmemcached-1.1.3/CMakeVersions.txt 
libmemcached-1.1.4/CMakeVersions.txt
--- libmemcached-1.1.3/CMakeVersions.txt2023-02-03 11:59:40.0 
+0100
+++ libmemcached-1.1.4/CMakeVersions.txt2023-03-06 19:36:56.0 
+0100
@@ -2,9 +2,9 @@
 # libmemcached
 #
 
-set(LIBMEMCACHED_VERSION 1.1.3)
+set(LIBMEMCACHED_VERSION 1.1.4)
 set(LIBMEMCACHED_VERSION_INC 1.0)
-set(LIBMEMCACHED_VERSION_HEX 0x001001003)
+set(LIBMEMCACHED_VERSION_HEX 0x001001004)
 
 # libmemcached.so
 
diff -Nru libmemcached-1.1.3/contrib/bin/memaslap/CMakeLists.txt 
libmemcached-1.1.4/contrib/bin/memaslap/CMakeLists.txt
--- libmemcached-1.1.3/contrib/bin/memaslap/CMakeLists.txt  2023-02-03 
11:59:40.0 +0100
+++ libmemcached-1.1.4/contrib/bin/memaslap/CMakeLists.txt  2023-03-06 
19:36:56.0 +0100
@@ -9,7 +9,7 @@
 check_dependency(LIBEVENT event)
 
 if(HAVE_LIBEVENT AND HAVE_ATOMICS)
-add_executable(memaslap
+add_executable(aslap
 ms_main.c
 ms_conn.c
 ms_setting.c
@@ -17,19 +17,19 @@
 ms_stats.c
 ms_task.c
 ms_thread.c)
-target_include_directories(memaslap PRIVATE
+target_include_directories(aslap PRIVATE
 ${CMAKE_SOURCE_DIR}/include
 ${CMAKE_BINARY_DIR}/include
 ${CMAKE_SOURCE_DIR}/src
 ${CMAKE_BINARY_DIR}/src
 ${CMAKE_BINARY_DIR})
-target_link_libraries(memaslap PRIVATE libmemcached Threads::Threads 
${LIBEVENT} m)
-set_property(TARGET memaslap PROPERTY C_STANDARD 11)
+target_link_libraries(aslap PRIVATE libmemcached Threads::Threads 
${LIBEVENT} m)
+set_target_properties(aslap PROPERTIES C_STANDARD 11 OUTPUT_NAME 
${CLIENT_PREFIX}aslap)
 if(CMAKE_INSTALL_RPATH)
-set_target_properties(${CLIENT} PROPERTIES
+set_target_properties(aslap PROPERTIES
 INSTALL_RPATH 
${CMAKE_INSTALL_RPATH}/../${CMAKE_INSTALL_LIBDIR})
 endif()
-install(TARGETS memaslap
+install(TARGETS aslap
 RUNTIME COMPONENT bin DESTINATION ${CMAKE_INSTALL_BINDIR})
 endif()
 
diff -Nru libmemcached-1.1.3/debian/changelog 
libmemcached-1.1.4/debian/changelog
--- libmemcached-1.1.3/debian/changelog 2023-02-23 01:50:44.0 +0100
+++ libmemcached-1.1.4/debian/changelog 2023-03-06 19:38:02.0 +0100
@@ -1,3 +1,9 @@
+libmemcached (1.1.4-1) unstable; urgency=high
+
+  * New upstream version 1.1.4
+
+ -- Ondřej Surý   Mon, 06 Mar 2023 19:38:02 +0100
+
 libmemcached (1.1.3-3) unstable; urgency=medium
 
   * Prevent libmemcachedutil underlinking by removing the conditional
diff -Nru 
libmemcached-1.1.3/debian/patches/0001-Prevent-libmemcachedutil-underlinking-by-removing-th.patch
 
libmemcached-1.1.4/debian/patches/0001-Prevent-libmemcachedutil-underlinking-by-removing-th.patch
--- 
libmemcached-1.1.3/debian/patches/0001-Prevent-libmemcachedutil-underlinking-by-removing-th.patch
   2023-02-23 01:50:44.0 +0100
+++ 
libmemcached-1.1.4/debian/patches/0001-Prevent-libmemcachedutil-underlinking-by-removing-th.patch
   1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-From: =?utf-8?b?T25kxZllaiBTdXLDvQ==?= 
-Date: Thu, 23 Feb 2023 01:50:21 +0100
-Subject: Prevent libmemcachedutil underlinking by removing the conditional
- around target_link_libraries
-

- src/libmemcachedutil/CMakeLists.txt | 4 +---
- 1 file changed, 1 insertion(+), 3 deletions(-)
-
-diff --git a/src/libmemcachedutil/CMakeLists.txt 
b/src/libmemcachedutil/CMakeLists.txt
-index 78e87d3..49bc4e1 100644
 a/src/libmemcachedutil/CMakeLists.txt
-+++ b/src/libmemcachedutil/CMakeLists.txt
-@@ -23,9 +23,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL AppleClang)
-   LINK_FLAGS "-Wl,-undefined,dynamic_lookup"
-   )
- endif()
--if(MSVC OR MINGW)
--target_link_libraries(libmemcachedutil PUBLIC libmemcached)
--endif()
-+target_link_libraries(libmemcachedutil PUBLIC libmemcached)
- target_link_libraries(libmemcachedutil PUBLIC Threads::Threads)
- if(HAVE_LIBSASL)
- target_link_libraries(libmemcachedutil PUBLIC ${LIBSASL})
diff -Nru libmemcached-1.1.3/debian/patches/series 
libmemcached-1.1.4/debian/patches/series
--- libmemcached-1.1.3/debian/patches/series2023-02-23 01:50:44.0 
+0100
+++ libmemcached-1.1.4/debian/patches/series2023-03-06 19:38:02.0 
+0100
@@ -1 +0,0 @@
-0001-Prevent-libmemcachedutil-underlinking-by-removing-th.patch
diff -Nru libmemcached-1.1.3/debian/rules libmemcached-1.1.4/debian/rules
--- libmemcached-

Re: Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Ondřej Surý]

Hi,

we should also remove bind-dyndb-ldap from stable and add `Breaks: 
bind-dyndb-ldap (<< 11.10-2~)` to the next src:bind9 stable upload.

I can keep bind9-dev package so people can still install the dyndb plugin from 
the source.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Re: Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Ondřej Surý]

> On 12. 1. 2023, at 8:43, Salvatore Bonaccorso  wrote:
> 
> as bind-dyndb-ldap would be removed on 25th of january, which then
> should unblock the bind9 situation for unstable/bookworm AFAIU, should
> we ask for removal already earlier? Should it be kept at all, is it
> used? (popcon seems quite low, but that is not necessarily
> reflecting).

As far as I understand, it's part of FreeIPA.

> Optionally Domain Names can be managed using the integrated ISC Bind server.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Sorry for top posting…

It’s easier for me to wait as I don’t want use custom repository for my sbuild 
chroots. Hence the wait…

Ondrej
--
Ondřej Surý  (He/Him)

> On 11. 1. 2023, at 21:01, Paul Gevers  wrote:
> 
> Hi Ondřej,
> 
>> On 11-01-2023 20:42, Ondřej Surý wrote:
>> Now, what should I do about:
>> • Not built on buildd: arch amd64 binaries uploaded by ondrej
>> • Not built on buildd: arch all binaries uploaded by ondrej, a new 
>> source-only upload is needed to allow migration
>> Do I really have to reupload everything that had to pass NEW with no-change 
>> source-only upload?
> 
> I have already NMU'd one of them (no change source only), because yes, our 
> infrastructure currently doesn't enable us to do binNMU that survives for 
> arch:all (we can do arch:any).
> 
>>> yes, I will take care of those, I’m just uploading them in batches as the 
>>> dependencies require.
> 
> Just in case you aren't aware, if the problem is that Build-Dependencies 
> aren't available yet (because of your previous batch), you don't need to wait 
> with uploading. The buildd's will know what to do and the package will stay 
> in "Builds Dependencies unavailable" until their B-D's are built and 
> available on the buildd.
> 
> Paul

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hi,

and with that I've uploaded the php-memcached and php-redis to NEW.

I've also throw in couple more extensions:

- php-xmlrpc (unbundled from PHP 8.x)
- php-mcrypt (unbundled from PHP 8.x)
- php-maxminddb (replacement for php-geoip)

Are there any extra extensions that the people actually using PHP would like to 
have in Debian?

Now, what should I do about:

• Not built on buildd: arch amd64 binaries uploaded by ondrej
• Not built on buildd: arch all binaries uploaded by ondrej, a new 
source-only upload is needed to allow migration

Do I really have to reupload everything that had to pass NEW with no-change 
source-only upload?

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



> On 8. 1. 2023, at 22:41, Ondřej Surý  wrote:
> 
> Hi,
> 
> yes, I will take care of those, I’m just uploading them in batches as the 
> dependencies require. I’ll check all the errors tomorrow. It was just Sunday, 
> so I was not sitting by the computer. I expect to have everything solved next 
> week.
> 
> The Breaks have been added there since the last transition - there was a 
> tendency for the apt dependency solver to pick one package (say php-imagick) 
> from old PHP version and other one from new PHP version (say php-mysql). The 
> Breaks was the only solution we came with that worked. I can dig up some old 
> issues from the last transition.
> 
> Ondrej 
> --
> Ondřej Surý  (He/Him)
> 
>> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
>> 
>> Control: severity 1023370 serious
>> Control: severity 1023381 serious
>> 
>> Hi Ondřej,
>> 
>>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
>>>> On 12/15/22 20:15, Ondřej Surý wrote:
>>>> I think everything is mostly ready in experimental. I'll try to sort out
>>>> the rest of the missing extensions over the weekend (imagick, memcached,
>>>> redis and maybe few others).
>>> php-igbinary needs to be moved to unstable, php-apcu is built & installed 
>>> on all release architectures.
>>> php-raphf is also built & installed on all release architectures, but 
>>> php-pecl-http was not staged in experimental and will need to pass NEW.
>>> php-memcached and php-redis were not uploaded to experimental either.
>> 
>> I have a couple of questions:
>> 
>> I'm seeing that php-common has a Breaks on php8.1-common. Why is that? Is 
>> that really needed? It makes the migration a bit more complicated as it 
>> means that php8.1 has to be removed at the same time that php-common 
>> migrates.
>> 
>> Will you also take care of src:xdebug, next to php-pecl-http, php-memcached 
>> and php-redis as Bas suggested?
>> 
>> Paul

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hi,

yes, I will take care of those, I’m just uploading them in batches as the 
dependencies require. I’ll check all the errors tomorrow. It was just Sunday, 
so I was not sitting by the computer. I expect to have everything solved next 
week.

The Breaks have been added there since the last transition - there was a 
tendency for the apt dependency solver to pick one package (say php-imagick) 
from old PHP version and other one from new PHP version (say php-mysql). The 
Breaks was the only solution we came with that worked. I can dig up some old 
issues from the last transition.

Ondrej 
--
Ondřej Surý  (He/Him)

> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
> 
> Control: severity 1023370 serious
> Control: severity 1023381 serious
> 
> Hi Ondřej,
> 
>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
>>> On 12/15/22 20:15, Ondřej Surý wrote:
>>> I think everything is mostly ready in experimental. I'll try to sort out
>>> the rest of the missing extensions over the weekend (imagick, memcached,
>>> redis and maybe few others).
>> php-igbinary needs to be moved to unstable, php-apcu is built & installed on 
>> all release architectures.
>> php-raphf is also built & installed on all release architectures, but 
>> php-pecl-http was not staged in experimental and will need to pass NEW.
>> php-memcached and php-redis were not uploaded to experimental either.
> 
> I have a couple of questions:
> 
> I'm seeing that php-common has a Breaks on php8.1-common. Why is that? Is 
> that really needed? It makes the migration a bit more complicated as it means 
> that php8.1 has to be removed at the same time that php-common migrates.
> 
> Will you also take care of src:xdebug, next to php-pecl-http, php-memcached 
> and php-redis as Bas suggested?
> 
> Paul

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hey all,

I think everything is mostly ready in experimental. I'll try to sort out
the rest of the missing extensions over the weekend (imagick, memcached,
redis and maybe few others).

The bump from 8.x to 8.2 is relatively painless, so can we schedule the
transition in few days/weeks?

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



> On 10. 12. 2022, at 17:23, Ondřej Surý  wrote:
> 
> Hi Bas,
> 
> yes, in fact, I've mass uploaded[1] all the extensions to the experimental 
> today
> to be rebuilt with PHP 8.2
> 
> 1. It's kind of hackish, so it might take me couple of retries to figure out 
> the
> right mangling of the packages for the experimental uploads. So far, I hit
> the "empty-binary-package" auto-REJECTs and missing orig source. I hope
> that exp3 did hit the sweet spot, but even that there are couple NEW packages
> built from the source, so it might take some time to get them processed 
> through
> NEW queue.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@sury.org
> 
> 
> 
>> On 5. 12. 2022, at 16:33, Sebastiaan Couwenberg  wrote:
>> 
>> On 10/22/22 21:46, Ondřej Surý wrote:
>>> I'll be uploading the PECL extensions for PHP 8.2 to experimental as I will 
>>> update them
>>> for PHP 8.2 - I haven't started yet, but should be able to do before or 
>>> around the PHP 8.2.0
>>> release.
>> 
>> Do you plan to include php-imagick in this?
>> 
>> I had to rebuild it with php8.2 from experimental for icingaweb2.
>> 
>> Kind regards,
>> 
>> Bas
>> 
>> -- 
>> GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>> 
> 

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hi Bas,

yes, in fact, I've mass uploaded[1] all the extensions to the experimental today
to be rebuilt with PHP 8.2

1. It's kind of hackish, so it might take me couple of retries to figure out the
right mangling of the packages for the experimental uploads. So far, I hit
the "empty-binary-package" auto-REJECTs and missing orig source. I hope
that exp3 did hit the sweet spot, but even that there are couple NEW packages
built from the source, so it might take some time to get them processed through
NEW queue.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



> On 5. 12. 2022, at 16:33, Sebastiaan Couwenberg  wrote:
> 
> On 10/22/22 21:46, Ondřej Surý wrote:
>> I'll be uploading the PECL extensions for PHP 8.2 to experimental as I will 
>> update them
>> for PHP 8.2 - I haven't started yet, but should be able to do before or 
>> around the PHP 8.2.0
>> release.
> 
> Do you plan to include php-imagick in this?
> 
> I had to rebuild it with php8.2 from experimental for icingaweb2.
> 
> Kind regards,
> 
> Bas
> 
> -- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 

Bug#1014460: transition: php8.2

[Ondřej Surý]

I wanted to update PHP 8.2 in experimental today, but it seems that 
firebird-dev is in bad shape[1] as "All"[2] build failed

1. https://tracker.debian.org/pkg/firebird3.0 
<https://tracker.debian.org/pkg/firebird3.0>
2. 
https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=all=3.0.11.33637.ds4-1=1666553566=0
 
<https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=all=3.0.11.33637.ds4-1=1666553566=0>

I am going to fill serious bug now

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 22. 10. 2022, at 22:23, Ondřej Surý  wrote:
> 
> Hi Paul,
> 
> I don’t recall any major changes to the toolchain, but I’ll double check. I 
> switched some of the PECL extensions to use separate sources for different 
> PHP version, so I don’t have to bundle old versions with new in single 
> tarball, so it might be a good time to finish this, so bookworm has a cleaner 
> state of PECL extension packages.
> 
> Ondrej
> --
> Ondřej Surý  (He/Him)
> 
>> On 22. 10. 2022, at 16:56, Paul Gevers  wrote:
>> 
>> I also recall php toolchain changes in the last transition. If there are any 
>> pending toolchain changes, please make sure that they are deferred or 
>> migrated to testing already, before we start the transition.

Bug#1014460: transition: php8.2

[Ondřej Surý]

Hi Paul,

I don’t recall any major changes to the toolchain, but I’ll double check. I 
switched some of the PECL extensions to use separate sources for different PHP 
version, so I don’t have to bundle old versions with new in single tarball, so 
it might be a good time to finish this, so bookworm has a cleaner state of PECL 
extension packages.

Ondrej
--
Ondřej Surý  (He/Him)

> On 22. 10. 2022, at 16:56, Paul Gevers  wrote:
> 
> I also recall php toolchain changes in the last transition. If there are any 
> pending toolchain changes, please make sure that they are deferred or 
> migrated to testing already, before we start the transition.

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hey David,

I'll be uploading the PECL extensions for PHP 8.2 to experimental as I will 
update them
for PHP 8.2 - I haven't started yet, but should be able to do before or around 
the PHP 8.2.0
release.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 22. 10. 2022, at 16:25, David Prévot  wrote:
> 
> Hi Ondřej, Mike and Horde team, PHP PEAR and Composer team, and Release team.
> 
> Le 21/07/2022 à 13:22, David Prévot a écrit :
>> Le 14/07/2022 à 15:23, Paul Gevers a écrit :
>>> Control: forwarded -1 
>>> https://release.debian.org/transitions/html/php8.2.html
>> […]
>> php-defaults was updated in experimental, allowing us to spot some 
>> regressions thanks to autopkgtests.
> 
> There is a new URL/view, thanks Paul for the hint:
> 
> https://qa.debian.org/excuses.php?experimental=1=php-defaults
> 
> There are still over twenty packages that need fixing in the Horde camp, 
> probably most of them could use a “Restrictions: allow-stderr” workaround in 
> debian/tests/control.
> 
>> Thanks in advance if you can try and help fixing those issues. You’re more 
>> than welcome to report bugs against packages in order to document the 
>> problem, and eventual hints to get them fixed.
>> Severity: important
>> Control: block 1014460 by -1
> 
> I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and cacti), 
> am crossing fingers that the latest php-proxy-manager upload will fix its 
> issue, and hope that the recent issue that popped up with phpunit, 
> phpunit-type and php-doctrine-common (that looks similar) will fix itself 
> soon enough too (upstream being usually pretty reactive). php-log is still 
> not in testing, so not a blocker.
> 
> I believe there are no more blockers that could be spotted with debci. Since 
> not all packages have tests, and those tests can’t spot every regressions, 
> there will probably be more issues, but I believe it looks good for now 
> (especially compared to previous transitions). I believe the first (non RC) 
> PHP 8.2 release is expected upstream in a month, so, if that’s the targeted 
> version for Bookworm, I hope this transition could happen as soon as possible.
> 
> Ondřej, there were some missing php8.1-* packages that needed NEW processing 
> last time, have all php8.2-* packages been processed this time?
> 
> Regards
> 
> David



signature.asc
Description: Message signed with OpenPGP

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Ondřej Surý]

> On 21. 9. 2022, at 20:35, Adam D. Barratt  wrote:
> 
> Control: tags -1 + bullseye
> 
> On Wed, 2022-09-21 at 13:47 +0200, Ondřej Surý wrote:
>> nmu bind-dyndb-ldap_11.6-3 . ANY . bullseye . -m "rebuild for
>> bind9_9.16.33-1~deb11u1"
>> 
>> Hi,
>> 
>> after the bind9_9.16.33-1~deb11u1 is release to bullseye-security,
>> the
>> bind-dyndb-ldap plugin will require binNMU.
>> 
> 
> We can do that - once the packages are in p-u, because p-u chroots
> don't pull in packages from the security archive - but it will mean
> that users won't get the binNMUs until the next point release, which
> probably isn't until November now.
> 
> Is that OK?


Adding Paul, Salvatore and Timo into the bunch.

I honestly don't know because I don't use this package, but I think
it might prevent the users using the bind-dyndb-ldap users from
upgrading the bind9 package.

Should I then prepare a NMU for bullseye-security?

Looks like only viable solution long-term would be to build all the
bind plugins from the src:bind9 package, but it's too late for bullseye.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu bind-dyndb-ldap_11.6-3 . ANY . bullseye . -m "rebuild for 
bind9_9.16.33-1~deb11u1"

Hi,

after the bind9_9.16.33-1~deb11u1 is release to bullseye-security, the
bind-dyndb-ldap plugin will require binNMU.

Thank you,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmMq+bpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJKxBAAsovdusRtOgErSgRov2zpmDnjPjNJps5XT0LZ/T2Zxkrg6QaVEx4E+lR3
q+QZAZjP2vZ1RBmOB5q+Jitl4I7vuqJu76fkymF3xnApS2y+X9N3nWQf5Yi1OhVs
+KbM84kwgcBG/ZTwR9rU95EoqvD57g86QRbukv1igSfxeqKfSs6AzhL9aSbIzSeE
NpIiDEIOTjQ0FiAsxv8Ysbbu3GoYU4wvot6bIhdm1/ZIz2O1d3osPTfKw+XrEGIH
ZxtpnukoGnMHZcrzmScaZbY/NDPTFYtFty4/RuEc5IK4vVMlwiP4+QhEz1qBZTSa
KnrbNU5yjO7rcF5FP+OZlcN4OK2Ok1YIWMAezEw0e8+gezgTAZf6HyELiVu6LLsf
E/INo7JEpb5F6AzVp7tm4EaaiLOlANKsYveLvm/iDms9jp5gAHQRXQVTox7288yl
0YEB3jg0fIF1NMrqE30mZFmPCip444N4OBQnQR7y6nP004DS7MGGBKaOD4y86IRh
/Zz3Fku3os4lO3GkiwIKm/k5b49etBkVA72owHA32sRBHKdUxcUQLwtgXhNw4r2y
FVK1KoVrMxeVrhw0gpB1BSz2IldARFlxg8lBZHwOWCqiSoLWwGM+cxQ1+S2vQ9db
9rxphi2SwtBRP5lSNA9X4xhPFdmQT69Xzqs5dlHF/wGwJrlpJDE=
=UWAs
-END PGP SIGNATURE-

Bug#1020412: nmu: bind-dyndb-ldap_11.10-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu bind-dyndb-ldap_11.10-1 . ANY . unstable . -m "Rebuild for bind9_9.18.7-1"

Hey release team,

after the bind9_9.18.7-1 will get accepted to the unstable, the bind-dyndb-ldap
binnmu rebuild for both to migrate to testing.

Thank you,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmMq97dfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcK8XQ/9GjBfV7gYc1+1hVXjSVFnzpAoP5LflnkoMU0qh7pazy+tSI7iwYUeK2yB
N/lPeAx7dleu99EbXHMc/N67P43sfuhVAliIz1O6Iton0XzVF01gFhg6PEF6RwMK
/5roiWOejtr10tR0uswGPBGMEdtCrsbnX69ftlx2vKOeDxz94HQLzWvb4Kw2gU1+
5awUiE+q0Ttc/545rCLXBWckARYusYXUnXeI46+Jev08ZWt5vuQSf7K9vGLTkyMY
9gvHPqY2VNxopyuomB2EYcj1GI4YZK9+Iga7pa3mHyz7aeeli6hq7p3zTY+UOREx
TSjvochBLuc2/gFauRhoAly5C8E6tdAZuC9Jn5jRIJnblUFgr8lymrsWSVJnpKu4
fskIFqg+/Bf6yfFgkBNd89aHba2kLOj2YRyfyoYTABeJ3xFshpgSFpGwxOQoLckf
IWa+fqlFgsQaPkyZkTyyZNL/Fb0XPvFXlGT13ZVThDTk/w4lX3++QU/6S4sy442l
PCzlO181C91QDEAxIIbALnaBPjm87LM6USuXKcOZ9V8ZtGf4jgUGpoih3FHXh3dX
UmsovDC0Cd58LG8xMEqzTVcP/6dPLDCAyjDhPO5KQB3f+LNftQ3gaTGH6qIV2lHW
aU5tbnCuUVOM5qaxIPBPxPxMXr2nGdN7P5ZEhCeBc16wqfEBBnk=
=Yj/Y
-END PGP SIGNATURE-

Bug#1014460: transition: php8.2

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

to prevent the situation from the last time, I am kind of "starting"
the transition to PHP 8.2 now with PHP 8.2.0~alpha2.  I will be uploading
packages to experimental as I will be updating them to support PHP 8.2.

Ondrej

Ben file:

title = "php8.2";
is_affected = .depends ~ "phpapi-20210902" | .depends ~ "phpapi-20210903";
is_good = .depends ~ "phpapi-20210903";
is_bad = .depends ~ "phpapi-20210902";



-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmLFlsdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcL5Bg//eTOW8HuuF15R/5SPKReyizaG9oB75HIVUBWTwnovNcJx3UNvlpoGCrdK
jWEaAD+Pv9b321gZikPuauYgwT3N0sGeA7L51aRO1m4BCEvmOTnY6VbmLvS66KM9
AWZigYK+/ZLDxju5edAdhfA25a8GLeFuXHg9YZERmpIoZH+++iVFnNZtrWbJ+NB0
cpcMapq9jIkuz3qKKEccKFTCD1Yy63rCVgqaTWg0oHydKyx1n4OQjZhmDMOgHdPg
hgN+9Kc5YLYcK3ReyKCxaernWcPtP9Zw8JJx3b62EmvKV6fglWNMzt++dQhGzM+5
iwWHeAaR/UaGf43T1DtT4j55quUXRNaJda3GQ27xoBDZRf8k7LZSp+rnhUZDlNRe
fX2LYyCe2IBkATiKIa1A3JfuPf6/6i1OEXP6keMVgf9LdLSi+yGZ//DLy+ObhCOF
+Q0yBv8eYSpOUk4EChFCKBvLLVv+PDdo896FK1E0z42XpJvWVVHGJ8ZZ9IljnLM7
l8Ccnr4Iov9aETXWBE+seEV1P6G034yj6CxmSBgTnJ2gKJLhT/mLPbLfqZsl0saF
xwCyq03p1Xz1DZtZJXCFNNe2LV56vYYmvxs/EnrSN2jgziIKvHPQffl+QRVelbza
BJ7ZIWxDLmSJfdkJbd91PPKnPePkUo5WsMyCFI+PCNQjox7xeXk=
=jKgC
-END PGP SIGNATURE-

Bug#1010203: bullseye-pu: package bind9/1:9.16.28-1~deb11u1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ Reason ]

New upstream version update, the upstream CHANGES are:

--- 9.16.28 released ---

5856.   [bug]   The "starting maxtime timer" message related to outgoing
zone transfers was incorrectly logged at the ERROR level
instead of DEBUG(1). [GL #3208]

5852.   [func]  Add new "reuseport" option to enable/disable load
balancing of sockets. [GL #3249]

5843.   [bug]   When an UPDATE targets a zone that is not configured,
the requested zone name is now logged in the "not
authoritative" error message, so that it is easier to
track down problematic update clients. [GL #3209]

5836.   [bug]   Quote the dns64 prefix in error messages that complain
about problems with it, to avoid confusion with the
following dns64 ACLs. [GL #3210]

5834.   [cleanup]   C99 variable-length arrays are difficult to use safely,
so avoid them except in test code. [GL #3201]

5828.   [bug]   Replace single TCP write timer with per-TCP write
timers. [GL #3200]

5824.   [bug]   Invalid dnssec-policy definitions were being accepted
where the defined keys did not cover both KSK and ZSK
roles for a given algorithm.  This is now checked for
and the dnssec-policy is rejected if both roles are
not present for all algorithms in use. [GL #3142]

And the user-friendly release notes:

Notes for BIND 9.16.28
- --

New Features
~~~

- - Add a new configuration option ``reuseport`` to disable load balancing
  on sockets in situations where processing of Response Policy Zones
  (RPZ), Catalog Zones, or large zone transfers can cause service
  disruptions. See the BIND 9 ARM for more detail. :gl:`#3249`

Bug Fixes


- - Invalid ``dnssec-policy`` definitions, where the defined keys did not
  cover both KSK and ZSK roles for a given algorithm, were being
  accepted. These are now checked, and the ``dnssec-policy`` is rejected
  if both roles are not present for all algorithms in use. :gl:`#3142`

- - Handling of TCP write timeouts has been improved to track the timeout
  for each TCP write separately, leading to a faster connection teardown
  in case the other party is not reading the data. :gl:`#3200`

[ Impact ]

The package will be updated when there's a new BIND 9 release containing
security vulnerabilities.

[ Tests ]

Upstream runs automated test suite covering many different platforms and also
runs a manually-triggered more extensive checks in their CI platform.

[ Risks ]

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

There are two extra related changes:

* Drop the libldap2-dev Build-Depends (it's not used at all)

* Add more string dependency on libuv1

  There are new flags (as enum members) that are being used because the BIND 9
  is compiled with libuv1 >= 1.40.0, but this is something not caught by
  dpkg-gensymbols mechanism because that can look only at the exported symbols.

  When the flags that were available at the compile time are used with older
  libuv1 at runtime, it causes assertion failure with "invalid argument":

  udp.c:229: fatal error: uv_udp_init_ex failed: invalid argument

[ Other info ]

FTR I am BIND 9 packager and upstream at the same time.  There were no reports
of regressions from the users using BIND 9.16.28 from ISC provided packages or
compiled from source.

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmJntMRfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKkVg//QNOtb5iqRRuTAAz/Lqd3Sd6Vdvex3KxpeBt+a1PhEjM1RHntYAhifWMa
mmyIR0oCuxHLe8WbbJIuFKvktsV9aaRTKVF1HzLedSl0k3TY6lTyNemwZ7U159mF
wJavJ6CsFpYz5+K0HNoVI5/Rlaw/K890oyLtio4KLmfYai/eewsS5a9j0NDakw8S
GgBxJDWyCynf6PA1yuiUKEsb2QBLme2v/9pSTW3V72vZzgXZmDS8UryPX/FhMbX2
Aqn8h/llnsSfKv4zymygjdazoWNgqm+WGV+oB1dhmTnYqA0Uft9WQ/S4rdKdJLFp
+Atlo6eZv4CieMIMaFYT2u0D4YodWxb8jjoUVGlZbA44YLEh3VY56kiY64RpAWlV
UkXxGbBvsqjb7rvydX71uAX7ZjVNOb/VXRh73H6o8UTg8LnSSb1AawJHeEZURchM
aRkCQJR1pjxbgpSuk/ph5g3ErPNXdtH8cQ0Uw51blb5/lRSBZCjdBlqNWiVUhYgb
ImACk8koo/RxEqk1QVyiEpDX1fZ67LUXC5xTE2l0Nc3i/NKa5UYgc8+Tgs9JONjN
ywnGuG18TvrAWu0nhnprfwXyQhGBBbrvXzZQBiIm1UjxFj0m7BviQPvrY640C0dl
4rLkTgrmOAt/6HktZuDEY1JxXMUFmqLOyTWjevSAQMEF1LXFa+g=
=hs25
-END PGP SIGNATURE-

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

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 /usr/share/dh-php/pkg-pecl.mk

Yes, I agree that the toolchain changes caused too much trouble. Sorry for that.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 18. 1. 2022, at 19:30, Paul Gevers  wrote:
> 
> 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 part of the library 
> Section, migrating src:php-uploadprogress to testing will make one of its own 
> binary uninstallable. That's a regression, so britney will not allow it.
> 
> It's a bit of a bad timing to implement toolchain changes during a 
> transition. Can we next time please do these kind of changes in the toolchain 
> separately from a transition? This php8.1 transition is causing much more 
> issues that I expected.
> 
> How do you plan to fix this?
> 
> Paul



signature.asc
Description: Message signed with OpenPGP

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

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 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 done 
> a no change source only NMU upload of php-igbinary, but php-lua needs a real 
> upload.
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=php-defaults



signature.asc
Description: Message signed with OpenPGP

Bug#976811: transition: php8.1

[Ondřej Surý]

And done.

Bug#1003555: Acknowledgement (RM: php-geoip -- ROM; PHP 8 not supported)
Bug#1003556: Acknowledgement (RM: php-pinba -- ROM; PHP 8 not supported)
Bug#1003557: Acknowledgement (RM: php-propro -- ROM; PHP 8 not supported)
Bug#1003558: Acknowledgement (RM: php-stomp -- ROM; PHP 8 not supported)

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 10. 1. 2022, at 21:32, Paul Gevers  wrote:
> 
> Hi,
> 
> 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.
> 
> I missed that. I'll remove them from testing already.
> 
>> I’ll refill the missing RM bugs tomorrow.
> 
> Yes, please do, to also remove them from unstable.
> 
> Paul



signature.asc
Description: Message signed with OpenPGP

Bug#976811: transition: php8.1

[Ondřej Surý]

Hi Paul,

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.

I’ll refill the missing RM bugs tomorrow.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 10. 1. 2022, at 21:09, Paul Gevers  wrote:
> 
> Hi Ondřej,
> 
> Found via the transition tracker [0], just in case you forgot about them, 
> php-geoip [1], php-pinba [2], php-propro [3] php-stomp [4] and php-apcu-bc 
> [5] are awaiting new uploads from you for the transition and because of 
> source-only uploads.
> 
> Paul
> 
> [0] https://release.debian.org/transitions/html/php8.1.html
> [1] https://tracker.debian.org/pkg/php-geoip
> [2] https://tracker.debian.org/pkg/php-pinba
> [3] https://tracker.debian.org/pkg/php-propro
> [4] https://tracker.debian.org/pkg/php-stomp
> [5] https://tracker.debian.org/pkg/php-apcu-bc



signature.asc
Description: Message signed with OpenPGP

Bug#976811: [pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[Ondřej Surý]

Hmm, this might need same treatment as src:php-defaults. I will need to export 
the version-to-break somehow from the src:php-defaults. I’ll have to think 
about it for a while, but if you have another smart idea, please share it.

--
Ondřej Surý  (He/Him)

> On 9. 1. 2022, at 19:38, Paul Gevers  wrote:
> 
> Hi David,
> 
> On 08-01-2022 23:09, David Prévot wrote:
>>> I also see some autopkgtest regressions which have this (eg. [1, 2]):
>>> """
>>> PHPUnit requires the "dom" extension.
>>> """
>>> where should that get fixed?
>> There are several php7.4-* packages pulled in those logs, so it’s not really 
>> a surprise that doesn’t end well (php-xml 2:7.4+76 is probably not the 
>> expected version either).
> 
> Normally this points to an issue with the right versioned Depends or 
> versioned Breaks. This is important because some of these packages are 
> currently allowed to migrate to testing without php-defaults (were it not for 
> the autopgktest failure), and would break functionality in testing. We need 
> to find out how to fix that.
> 
> Paul

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

> 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 upload src:php-imagick, which seems to block some rebuilds in 
>> the current state.
>> I want to update the ben transition tracker file to catch these kind of 
>> packages. Should I add a "Depends on php7.4-common" to the "bad" list?
> 
> 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 packages that need new uploads), but e.g. wikidiff2 
> built fine *but disappeared* from the tracker. I looked at a build log [2] 
> and noticed that the binary has files in /etc/php8.1 (and not in 
> /etc/php7.4), but doesn't tell otherwise (in package relations) that it's 
> meant for php8.1 and not for php7.4. Why did that phpapi-* thing disappear? 
> Is that intended? The built binaries already migrated to testing, while the 
> default there is still php7.4. I assume we can consider php-wikidiff2 
> (partially?) broken now *in testing*? Same for php-luasandbox [3], php-geos 
> [4], and php-excimer [5] (which also FTBFS on mipsel).

This has been tracker as #1000233 and hopefully fixed in dh-php 4.4

> 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 also notice that quite some php packages grew a php7.4-* package in 
> unstable. Is the idea that that needs to be done for php8.1 too and that all 
> those packages require a round trip through NEW? If that's the case, next 
> time please prepare those in experimental, such that we don't need to wait 
> for processing of NEW during the transition. If that's not the case, please 
> upload new versions of those packages dropping the php7.4 package.

Yes, I rewrote the helper scripts for PECL based packages, and I haven’t 
realized this. The idea is to align the embedded extensions schema[a] with the 
externally (PECL) distributed extensions. This is bit tricky though, I was 
faced with two options:

1. Add all binary packages to debian/control directly and do the NEW queue
2. Generate all binary packages to debian/control during the build, but this 
would then require overrides (which I think doesn’t really scale)

> 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).

Currently, there are two types:

1. arch:any php- that contains the extension and the configuration - uses 
whatever build system is there
2. arch:all php- depending on arch:any phpX.Y- that uses 
/usr/share/dh-php/pkg-pecl.mk Makefile snippet which does a lot of “magic”, but 
so is a bit fragile as everything that is “magic” is.

Ondrej

a. Arch: any package php.- and Arch: all  package php- that 
depend on it
--
Ondřej Surý (He/Him)
ond...@sury.org

> Paul
> 
> [1] https://release.debian.org/transitions/html/php8.1.html
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=wikidiff2=amd64=1.13.0-1%2Bb1=1640981156=0
> [3] https://buildd.debian.org/status/package.php?p=php-luasandbox
> [4] https://buildd.debian.org/status/package.php?p=php-geos
> [5] https://buildd.debian.org/status/package.php?p=php-excimer
> [6] https://buildd.debian.org/status/package.php?p=php-horde-lz4
> [7] https://buildd.debian.org/status/package.php?p=php-wmerrors
> [8] https://buildd.debian.org/status/package.php?p=owfs



signature.asc
Description: Message signed with OpenPGP

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

> 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 Surý (He/Him)
ond...@sury.org

> On 1. 1. 2022, at 11:38, Sebastiaan Couwenberg  wrote:
> 
> 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 
>>> seems (because they depend on packages that need new uploads), but e.g. 
>>> wikidiff2 built fine *but disappeared* from the tracker. I looked at a 
>>> build log [2] and noticed that the binary has files in /etc/php8.1 (and not 
>>> in /etc/php7.4), but doesn't tell otherwise (in package relations) that 
>>> it's meant for php8.1 and not for php7.4. Why did that phpapi-* thing 
>>> disappear? Is that intended? The built binaries already migrated to 
>>> testing, while the default there is still php7.4. I assume we can consider 
>>> php-wikidiff2 (partially?) broken now *in testing*? Same for php-luasandbox 
>>> [3], php-geos [4], and php-excimer [5] (which also FTBFS on mipsel).
>> Previously the dh_php step would add the phpapi- dependency, however 
>> this was removed[1] and the new php-common dependency is added via 
>> pkg-pecl.mk[2]. The packaging for wikidiff2/luasandbox/excimer/wmerrors (all 
>> basically identical) only uses the dh_php step, and not pkg-pecl.mk.
> 
> The removal of the phpapi dependency should be reverted.
> 
> php-geos now only depends on: php-common (>= 1:7.0+33~)
> 
> But it installs files in /etc/php/8.1/mods-available and 
> /usr/lib/php/20210902 which are not provided by older php-common versions.
> 
> Kind Regards,
> 
> Bas
> 
> -- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

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 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
> Control: severity 977385 serious
> Control: severity 1000474 serious
> Control: severity 1002020 serious
> Control: severity 1000650 serious
> Control: severity 1002504 serious
> Control: severity 1000596 serious
> Control: severity 1000571 serious
> Control: severity 977373 serious
> 
> Hi Ondřej,
> 
> On 05-12-2021 22:11, Paul Gevers wrote:
>> I propose we can start the php8.1 transition around Christmas 2021. Does 
>> that work for you Ondřej?
> 
> Assuming you were OK with this timing, I propose you go ahead now.
> 
> Paul



signature.asc
Description: Message signed with OpenPGP

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

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, but the things beyond are sometimes too much.

Ondrej
--
Ondřej Surý  (He/Him)

> On 26. 11. 2021, at 15:30, David Prévot  wrote:
> 
> 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 checked that all [0] packages with a failing testsuite using PHP 8.1 
> from experimental [1] have now a bug (severity important, blocking the 
> current one) about this issue.
> 
> 0: *except*
>  - php-horde* packages (Mike and team CCed);
>  - packages not in testing (shouldn’t be a blocker);
>  - packages already fixed (come on, refresh! ;).
> 
> 1: 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults
> 
> For Horde packages, Paul already noticed many errors are “just” PHP 
> deprecations, so using “Restrictions: allow-stderr” in d/t/control should at 
> least allow to go one step further, even if we’re just hiding issues under 
> the carpet for now.
> 
>>> And I would prefer if we roughly agree on a timeframe when we start
>>> the transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it
>>> is ready upstream, so the ftp-masters have time, and keep uploading
>>> rcN versions (this will usually take few months) and start the
>>> transition right away when 8.2.0 is golden (December 2022). Would
>>> that work?
> 
> (keeping that part to inform Horde maintainers in the mean time).
> 
> Regards
> 
> David

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

> 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 version with your fix.

David, can we now agree on a timeframe when we start the transition?

And I would prefer if we roughly agree on a timeframe when we start the 
transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it is ready 
upstream, so the ftp-masters have time, and keep uploading rcN versions (this 
will usually take few months) and start the transition right away when 8.2.0 is 
golden (December 2022). Would that work?

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#976811: transition: php8.1

[Ondřej Surý]

I disagree, but I uploaded reverted package. It’s after release and we have two 
years before next release and a year before PHP 8.2, so unstable could be a bit 
unstable. It’s not like the bump from php7.4 to php8.1 is that large as it was 
from php5.6 to php7.0.

The transition to php8.x has been announced a year ago.

Ondrej
--
Ondřej Surý  (He/Him)

> On 19. 11. 2021, at 21:27, Paul Gevers  wrote:
> 
> Hi,
> 
>> On 19-11-2021 20:50, David Prévot wrote:
>>> Le 10/11/2021 à 05:16, Sebastian Ramacher a écrit :
>>> On 2021-09-05 19:26:39, Ondřej Surý wrote:
>>>> the PHP 8.1 RC1 was released, so I think it would be better to skip php8.0
>> […]
>>>> I’ll update this issue when I am ready.
>> It seems that php-defaults (85) was uploaded to unstable, pushing PHP 8.1 as 
>> default in unstable before this was even a default in experimental.
>> Did I miss some communication, has this transition already started?
> 
> Not that I'm aware of, and I don't think it's a good idea to have it started 
> already as there is so much fall out. Can this please be reverted and staged 
> in experimental first? Bugs filed for all issues with autopkgtest? Such that 
> there's a good overview (and fixes) *before* we transition?
> 
> Paul
> 

Bug#976811: transition: php8.0

[Ondřej Surý]

Hi Sebastian,

the PHP 8.1 RC1 was released, so I think it would be better to skip php8.0
and go directly with php8.1.  I do have the base package, but I haven’t tested
any extensions yet, but I do plan to do so in upcoming weeks.

I’ll update this issue when I am ready.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 5. 9. 2021, at 19:14, Sebastian Ramacher  wrote:
> 
> Hi Ondřej
> 
> On 2020-12-08 09:28:38 +0100, Ondřej Surý wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> 
>> Hi,
>> 
>> I would like to transition the PHP to version 8.0; it's not such a huge bump 
>> as
>> it was with 5.6 -> 7.0 and most of the packages that were compatible with PHP
>> 7.4 are working just fine with PHP 8.0.
>> 
>> I do have most of the extensions ready for PHP 8.0 either via new upstream 
>> version
>> or with patches.
> 
> bullseye was released so I think we can revisit this transition. What's
> the status here?
> 
> Cheers
> 
>> 
>> Ondrej
>> 
>> Ben file:
>> 
>> title = "php8.0";
>> is_affected = .depends ~ "phpapi-20190902" | .depends ~ "phpapi-20200930";
>> is_good = .depends ~ "phpapi-20200930";
>> is_bad = .depends ~ "phpapi-20190902";
>> 
>> 
>> -- System Information:
>> Debian Release: 10.7
>>  APT prefers stable-updates
>>  APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>> 
>> Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_IE:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> 
>> 
> 
> -- 
> Sebastian Ramacher

Bug#990261: release.debian.org: libyang 1.0.184-2 autopkgtest suite update

[Ondřej Surý]

Package: release.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

the libyang 1.0.184-2 in testing has a failure in the autopkgtest suite, but the
upstream version in unstable has already higher than the version in testing.
How do you want me to proceed?

The patch is very simple in this case (it just removes the python3-yang based
test) as the package is no longer available.

diff -Nru libyang-1.0.225/debian/tests/control 
libyang-1.0.225/debian/tests/control
- --- libyang-1.0.225/debian/tests/control  2021-03-08 15:39:56.0 
+0100
+++ libyang-1.0.225/debian/tests/control2021-06-20 15:59:05.0 
+0200
@@ -1,7 +1,3 @@
- -Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
"$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import yang; 
print(yang)" ; done
- -Depends: python3-all,
- - python3-yang
- -
 Tests: yanglint
 Depends: gzip,
  libyang-tools

Cheers,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmDUQ6RfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJ5rw//eI4N+MU4RJwgWyPS31hMgOWMNcMSMADnzweQQKkga+OeQyVZ6wJH0h+d
jMyuS9J1H6PFAIljJwlZAcKdR6rJK2TK/Ucm3LV12L3v8Z7ZQx8GRlJqhCZ6eRvc
sJPjOeVgmTV0igx/ee3hZ7+qug96W8Jpe4iTIAgAoJaITUq/1TDlgT1xZB5Ivc8Q
3Fu+VEbPMWcDtNvolnUqAp1lmPFJOAE7RgzAzb3UDzl/mtnBof7a3+a3eZcDxH7z
y5xp7CpIuJ/NPxewcfjEgrI++9aySj9RQj+qq/Ysc7eb45hVoKj/YRgFNBwaCkrW
dGKDsV5bJ+/1hCgFYj/P3mK0hSW8aPK2UZ0cSdbY9HhY9+gzX4pucZDcqDZesyat
zParFIWVrM+I215lYP4JFDlD1pt2GDWwOtB9DftAYnLRlTnIGpLGOkOYHJzTft4w
rffsRQ62Svb0nfub7iP5jVVTLo5bP/BHWGevS8uUMwwCex6Jx8Lt7Fd2eZlhAM4K
Bhe9S6dMbgxTNCM+hF2JdH7HHtaQC/DyaurcKD7WbgV1yt1kJr/UBQzm5Vs0JI/O
r2lR0m8X7QXUZgjRyMtSpjmjWWhKGuMU+57NA7V3g0IhLHS+R1bdW4bLEXB8yoj+
4pjFuZ8CSheL1JsjPbw4CzwCa3DAvCcvgrEj3k1Zf0u4jP4bCAM=
=qXSd
-END PGP SIGNATURE-

Bug#987776: Fwd: Bug#987776: unblock: bind9/1:9.16.15-1

[Ondřej Surý]

Missed the Cc: to BTS first time.
--
Ondřej Surý (He/Him)
ond...@sury.org

> Begin forwarded message:
> 
> From: Ondřej Surý 
> Subject: Re: Bug#987776: unblock: bind9/1:9.16.15-1
> Date: 17 May 2021 14:10:40 CEST
> To: Salvatore Bonaccorso 
> Cc: Paul Gevers , Debian Security Team 
> , Debian Release Team Discussion 
> 
> 
> Ok, here’s me adding little bit more of detail to the issue:
> 
> 0. I am the Director of DNS Engineering at ISC - so I am as close to the 
> upstream as one can be.
> 1. The most churn came from removing the upstream patches that fixed the XFR 
> timeouts. There was a bug when the TCP timeouts were not applied correctly 
> and `named` would drop the long transactions after the initial timeout. I 
> pulled the patches into the previous release directly from our git (after 
> they had been reviewed and merged) and dropped them in this release.
> 2. The other churn came from the NSEC3-iteration patches that again have been 
> reviewed in the upstream and merged to the respective branches before I 
> pulled them into the Debian package.
> 3. Since this BIND 9 release was a security release, the upstream (ISC) made 
> sure that only a minimal required set of changes would be included in this 
> current upstream stable release. The only non-security related stuff were 
> fixed in the DNSSEC KASP processing, a memory leak and fixes to the journal 
> upgrade processing[a].
> 
> a. As a matter of fact, we found just another edge condition here which might 
> cause IXFR to drop to AXFR when more than one journal transaction would be 
> used.  But that will have to be fixed separately later, as we (upstream) seem 
> to struggle with fixing all the weird edge conditions, so I want to be 100% 
> sure we got everything.
> 
> There’s another set of patches that I think we should pull into stable BIND 9 
> when the dust settles.  The BIND 9.16 recursive performance is really bad due 
> to the contention between new network threads and task threads.  The code has 
> just landed in our upstream 9.16 branch, so I’ll give it some time before 
> requesting the SRU, but I think it would be for benefit of all the users that 
> use BIND 9 as recursors.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@sury.org
> 
>> On 14. 5. 2021, at 9:15, Salvatore Bonaccorso  wrote:
>> 
>> Hi Ondrej,
>> 
>> On Fri, May 07, 2021 at 07:40:31AM +0200, Paul Gevers wrote:
>>> Hi Ondřej,
>>> 
>>> On 06-05-2021 22:41, Ondřej Surý wrote:
>>>> Hi Salvatore,
>>>> 
>>>> thanks for following up. I will try to follow up tomorrow. Basically,
>>>> the difference between the debian versions are because I pulled some
>>>> extra upstream patches into the previous version and now I dropped them
>>>> and pulled another set for the NSEC3 iterations issue.
>>>> 
>>>> With my upstream hat, the 9.16 is stable release and we pull only
>>>> important stuff into it. I am not asking for a long term exception as we
>>>> have with PHP, but I am asking for an exception now.
>>>> 
>>>> While I could pull all the important upstream changes to the “old”
>>>> release, it would be a charade as most of the stuff needs to be picked
>>>> up anyway.
>>> 
>>> 
>>> These comments helped:
>>> - Ondřej is upstream author too
>>> - delta is partially in patches that are in the new version upstream
>>> - 9.16 stable release with "only important stuff"
>>> 
>>> For future reference, the release team also has a non-public list:
>>> t...@release.debian.org. It better to not bet on one horse.
>>> 
>>> I've unblocked bind9 and aged it. I'd still appreciate the follow-up in
>>> the unblock request for the outside world (whatever you deem you can put
>>> into it) such that I can close it.
>> 
>> Thanks Paul for the unlbock.
>> 
>> Friendly ping :). Sorry I d not want to be annoying, but guess Paul
>> still would appreciate a followup to the public bug, OTOH I unerstand
>> we do not wat to raise too much awareness on the issues you pointed
>> out above.
>> 
>> So be assured, this will the last ping from my side on this regard.
>> 
>> Regards,
>> Salvatore
> 

Bug#987776: unblock: bind9/1:9.16.15-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package bind9

[ Reason ]
Upstream security release update of the bind9 package.

[ Impact ]
3 grave security issues would affect users.

[ Tests ]
Upstream has extensive unit and system test suite.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Patches to put limits on NSEC3 SHA1 iterations according to the I-D
draft-hardaker-dnsop-nsec3-guidance were pulled into the package.

unblock bind9/1:9.16.15-1

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmCKiCZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKbpQ//Skjxlqpe/XYzzp3v/3scGZ6G6sktk57wdVODLaCB0wpdd07d6ZtnENKy
H1yA0KU9k9rKuT2/xAAJ47XYaY8WUMy1LJHrkdTCVqPe018+2wlXsM5CV2geF+lY
ESlb1JlBC9XrVKuJsJush1T98fXiWjeRv496uKDIa9DMgfEmVA5vuAZ0o/RZY3Ij
a/bS/ujEdMPm85vqopenZzKdZ6ZXvMZs166DvNx0GwZ3d4rUWv6xCNiCGX08Rt3g
Y+JmF/ERE7OmBsSfcABf++PNVPuoiZY9uL5zaM2i7lThc6fdstEO093avVMWCZjt
TCuAugrd4uF5wyugxsm1onPCQG40W0n+Z7ks/VbW4LbYAdahu0rpVoG+nq8UlH1k
LnM1hXrG6Hw0K5J4ZuKKyNj54egSuX3n65EICFzywHZwDH/s1mcUEDf5VYUS723y
UDwXR3Otz5rtiVwIxX1ZnwC1FBB35VSIIVDzZ9PYzTkSYqCtq9it5aA9fuj2vBtC
SPaJYXn4IyYsg2nj64FlvkGgqcEUwLTfRhGmFpPI7t1ckEjzqdfKSoez/JVVwkEz
zCtSln/PJHyGNX/I2mlTEhrGHq1rTlcs5+26kQtVdHlIYgCkWX1nf6ctDknPFuOf
K4RCBY6xj+HC42Ni3KNjJp8/lI9d+zLccCW6H6EQNfyaWAW/4NU=
=Ac5X
-END PGP SIGNATURE-


bind9_9.16.15-1.debdiff.xz
Description: application/xz

Bug#983841: buster-pu: package libvirt-php/0.5.4-3+deb10u1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ Reason ]
The package update fixes segmentation fault caused by incomplete PHP 7.3 support
in the upstream package.

[ Impact ]
The PHP crashes when calling libvirt_node_get_cpu_stats (See #982804)

[ Tests ]
The fix was test by hand.

[ Risks ]
The patch is simple, previously the variable was incorrectly scoped.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable

[ Changes ]
* Just gbp.conf for new branch and new patch via gbp pq.

Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmA97YZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcIlwQ/+JWn4ybBu5ay6OaaP4T2fyEIWb0RAEPCfvHyDGwI76h5xdLLcSlJMfYIb
CcYBVsAx4dgACCVNWbK9/yThmUBwFzIYE7grNqWJqQ7UAWViIcu7mXE9UIvggkxH
AmY7G9aeSTFkiWSyu8dFHIBK98jSGOR+tIz9O+iwAHsoCedzkyDRPsPzCgCHHpZC
BNowJkvWQRONjkn4xQBX9ygIjT98MgeCHJI35wB32a16FXkwMA57ljimZuC5ATQn
HDygvfGAB2GPNQF0nLcUuumbB6E4mQgzIEa+yYb/fptNzTmR+xjQ1Ln+JE8UV7vZ
gzVi47AcbTxzoyrpW4Hwe9wpRHKO0AxNLpgEkwQRXPPeWf+pjEjaWfT+MtlhDIAR
7hcpsk7axoFuDH9GVTtfLtWtdqEsADNk1O+tspOjNu2v5i7JZCZ/jWfXH5NyAayT
pLbwDcbKo4WRdy9B5JRNebtIsgZJ0bm4HFcbUeI/M4w+OVij/m74Z2rc0RPE6T43
uqTf3qWagYh0QYMX3crEnimxqk62n/YfELTCN4+Iw2AGsrFrdT4U6uPS1tuH2bTH
YJq2IZ+ebjKa0JpNIp3IVxRl7TOEZHyseY+K/nL6wnbYMY1SqfN6AacQB8AKUo+q
6HJCngAPKf1j3Rrpebr0IQSrMKdUTe9KMwQ4q+YtIcnEGJ9VI0g=
=Drd8
-END PGP SIGNATURE-
diff -Nru libvirt-php-0.5.4/debian/changelog libvirt-php-0.5.4/debian/changelog
--- libvirt-php-0.5.4/debian/changelog  2018-10-09 15:30:47.0 +0200
+++ libvirt-php-0.5.4/debian/changelog  2021-03-02 08:27:12.0 +0100
@@ -1,3 +1,11 @@
+libvirt-php (0.5.4-3+deb10u1) buster; urgency=medium
+
+  * Add gbp.conf for debian/buster
+  * Add patch to fix segmentation fault in libvirt_node_get_cpu_stats
+(Closes: #982804)
+
+ -- Ondřej Surý   Tue, 02 Mar 2021 08:27:12 +0100
+
 libvirt-php (0.5.4-3) unstable; urgency=medium
 
   * Manually rebuild for PHP 7.3.0~rc2
diff -Nru libvirt-php-0.5.4/debian/gbp.conf libvirt-php-0.5.4/debian/gbp.conf
--- libvirt-php-0.5.4/debian/gbp.conf   2018-10-09 15:30:47.0 +0200
+++ libvirt-php-0.5.4/debian/gbp.conf   2021-03-02 08:27:12.0 +0100
@@ -1,3 +1,13 @@
+[DEFAULT]
+debian-branch = debian/buster
+debian-tag = debian/%(version)s
+upstream-branch = upstream
+upstream-tag = upstream/%(version)s
+pristine-tar = True
+
+[dch]
+meta = 1
+
 [import-orig]
 # those files should not be in the tarball
 filter = 
['CVS','*.bak','*~','*.orig','.cvsignore','.#*','autom4te/*','autom4te.cache/*','.svn','debian/*']
diff -Nru 
libvirt-php-0.5.4/debian/patches/0001-Don-t-rely-on-absolute-paths-in-tools-Makefile.am.patch
 
libvirt-php-0.5.4/debian/patches/0001-Don-t-rely-on-absolute-paths-in-tools-Makefile.am.patch
--- 
libvirt-php-0.5.4/debian/patches/0001-Don-t-rely-on-absolute-paths-in-tools-Makefile.am.patch
   2018-10-09 15:30:47.0 +0200
+++ 
libvirt-php-0.5.4/debian/patches/0001-Don-t-rely-on-absolute-paths-in-tools-Makefile.am.patch
   2021-03-02 08:27:12.0 +0100
@@ -1,4 +1,4 @@
-From: =?utf-8?q?Ond=C5=99ej_Sur=C3=BD?= 
+From: =?utf-8?b?T25kxZllaiBTdXLDvQ==?= 
 Date: Mon, 29 Aug 2016 12:11:14 +0200
 Subject: Don't rely on absolute paths in tools/Makefile.am
 
diff -Nru 
libvirt-php-0.5.4/debian/patches/0002-Fix-PHP7-VIRT_ARRAY_INIT-macro-implementation.patch
 
libvirt-php-0.5.4/debian/patches/0002-Fix-PHP7-VIRT_ARRAY_INIT-macro-implementation.patch
--- 
libvirt-php-0.5.4/debian/patches/0002-Fix-PHP7-VIRT_ARRAY_INIT-macro-implementation.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libvirt-php-0.5.4/debian/patches/0002-Fix-PHP7-VIRT_ARRAY_INIT-macro-implementation.patch
   2021-03-02 08:27:12.0 +0100
@@ -0,0 +1,53 @@
+From: Dawid Zamirski 
+Date: Mon, 8 Jul 2019 17:32:11 -0400
+Subject: Fix PHP7 VIRT_ARRAY_INIT macro implementation.
+
+This is a PHP 7 compatibilty macro which was segfaulting due to the
+temporary variable being defined in the do..while scoped block (to
+swallow semicolon for macros), e.g:
+
+zval *arr;
+VIRT_ARRAY_INIT(arr);
+VIRT_ADD_ASSOC_STRING(arr, "foo", "bar"); // <= segfault here
+
+The VIRT_ARRAY_INIT above was expanding to:
+do {
+  zval z_arr; // <= local scope definition
+  arr = _arr;
+  array_init(arr);
+} while (0)
+
+After this patch, the macro expands to:
+zval z_arr; // now defined in the scope of the macro caller
+do {
+arr = _arr;
+array_init(arr);
+} while (0)
+
+which solved the issue.
+
+Signed-off-by: Dawid Zamirski 
+Reviewed-by: Michal Privoznik 
+---
+ src/libvirt-php.h | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+

Bug#976811: transition: php8.0

[Ondřej Surý]

On Sun 7. 2. 2021 at 14:17 Moritz Muehlenhoff  wrote:

> On Sat, Feb 06, 2021 at 09:26:39PM +0100, Salvatore Bonaccorso wrote:
> > Otherwise there will be
> > expectation that both php7.4 and php8.0 will be covered by (security)
> > support in bullseye if we release with php8.0 included.
>
> Yeah, let's drop 8.0 then.


I concur, and I was planning to ask for removal after soft freeze kicks in,
so it could not migrate back, but RC bug that Salvatore filled is fine too.


> Cheers,
>     Moritz
>
-- 
--
Ondřej Surý

Bug#976811: transition: php8.0

[Ondřej Surý]

Thinking about it, security-wise it might be better. Microsoft will support the 
security backports to EOL versions of PHP 7.x, but they announced they won’t do 
it for PHP 8.x, so we are (maybe) bit more covered with PHP 7.4.

Ondrej
--
Ondřej Surý  (He/Him)

> On 15. 1. 2021, at 19:45, Moritz Mühlenhoff  wrote:
> 
> Am Thu, Jan 14, 2021 at 10:28:41AM +0100 schrieb Sebastian Ramacher:
>> I'm also CCing the security team for their input in case the have a
>> strong opinion on this transition.
> 
> It's fine. PHP 8 would have been great, but it is what it is.
> 
> Cheers,
>Moritz

Bug#976811: transition: php8.0

[Ondřej Surý]

I guess we are going to release with PHP 7.4 then.  Not the ideal choice,
but I will do whatever I can to support it.

However, I would like to get an official statement from the release team
what's their position, so we can go forward. Pretty please?

Also an advice on how to proceed next time this happens. The timing of our
freeze and new PHP release coincidentally goes together. Should I start the
transition with alpha/beta/rc instead of the first final release?


Ondrej

On Fri, 11 Dec 2020 at 18:01, Ondřej Surý  wrote:

> The main problem is the PHP release schedule:
> https://www.php.net/supported-versions.php
>
> If we release with PHP 7.4, the upstream security support will end sooner
> than security support for Debian bullseye. If we release with PHP 8.0 we
> will have full three years of upstream support.
>
> There’s still month before the transition freeze and we will have time to
> fix the downstream users after the transition is over.
>
> I think the transition is worth the trouble. Having official security
> support is important especially for PHP.
>
> Ondřej
> --
> Ondřej Surý  (He/Him)
>
> On 11. 12. 2020, at 17:38, David Prévot  wrote:
>
> Hi Ondřej,
>
> Le Tue, Dec 08, 2020 at 09:28:38AM +0100, Ondřej Surý a écrit :
>
> I would like to transition the PHP to version 8.0;
>
>
> The timing of this request makes me uneasy: php8.0 has been in Debian
> for less than a week, and we are a month away from the transition
> freeze.
>
> it's not such a huge bump as it was with 5.6 -> 7.0 and
>
>
> If I remember correctly, the 7.3 -> 7.4 was not a huge bump either, yet
> php7.4 packages were in Debian months before the actual transition
> happen, and it took months for the updated php-defaults to actually
> migrates into testing.
>
> most of the packages that were compatible with PHP
>
> 7.4 are working just fine with PHP 8.0.
>
>
> That does not match my experience as a maintainer of about a hundred
> packages relying on PHP. Many upstream are currently releasing updates
> to fix compatibility with PHP 8.0, and many more have not yet done so.
>
> I’m actually surprised to discover this request in the BTS without any
> prior communication with teams involved in PHP related packaging.
>
> For example, PHPUnit 8 as currently available in unstable and testing is
> expected to run on PHP 8 (thanks to upstream updates less than two weeks
> ago), yet “Please note that the code coverage functionality is not
> available for PHPUnit 8.5 on PHP 8.” (from upstream changelog 8.5.12).
> So shipping PHPUnit 8 with PHP 8 would mean having a major
> fonctionnality unavailable for the whole Bullseye life cycle. PHPUnit 9
> is available from experimental, yet uploading to unstable would mean
> having to deal with dozens of breakage (in the FTBFS form):
>
> https://release.debian.org/britney/pseudo-excuses-experimental.html#phpunit
>
> PHPUnit is just one example, but it seems unrealistic to ship version 9
> with Bullseye (I really abandonned this option months ago). Other
> packages will break (and I suspect the number of breakage will be high).
>
> This kind of disruptive change would hopefully be better suited early in
> the release cycle rather than just before the beginning of the freeze.
>
> That said, it would be nice to have an updated php-default in
> *experimental* to help have a grasp of the possible brekages.
>
> Regards
>
> David
>
>

Bug#976811: transition: php8.0

[Ondřej Surý]

And let me restate that it’s not my intent to make anyone’s life hell and
I am willing to help with any package (as usual). I am just trying to do
the most sane thing to do security and maintainer wise.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 12. 12. 2020, at 0:22, Holger Levsen  wrote:
> 
> On Fri, Dec 11, 2020 at 07:58:06PM +0100, Ondřej Surý wrote:
>> And done, and uploaded.
> 
> yay, thank you!
> 
> 
> --
> cheers,
>   Holger
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
> ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> ⠈⠳⣄



signature.asc
Description: Message signed with OpenPGP

Bug#976811: transition: php8.0

[Ondřej Surý]

And done, and uploaded.

--
Ondřej Surý  (He/Him)

> On 11. 12. 2020, at 19:52, Holger Levsen  wrote:
> 
> On Fri, Dec 11, 2020 at 07:43:00PM +0100, Ondřej Surý wrote:
>> Sorry, I was on my phone and missed that. Yes, I can do that.
> 
> :) & thank you!
> 
> 
> -- 
> cheers,
>Holger
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
> ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> ⠈⠳⣄

Bug#976811: transition: php8.0

[Ondřej Surý]

Sorry, I was on my phone and missed that. Yes, I can do that.

On Fri 11. 12. 2020 at 19:42 Holger Levsen  wrote:

> Hi Ondřej,
>
> On Fri, Dec 11, 2020 at 06:01:31PM +0100, Ondřej Surý wrote:
> > I think the transition is worth the trouble. Having official security
> support is important especially for PHP.
>
> as a comment from the sideline...
>
> > > On 11. 12. 2020, at 17:38, David Prévot  wrote:
> > > That said, it would be nice to have an updated php-default in
> > > *experimental* to help have a grasp of the possible brekages.
>
> you didn't reply to that - IMHO - sensible suggestion from David as
> a/the step forward. Maybe you missed it, maybe you disagree, maybe you are
> busy preparing those uploads? ;)
>
>
> --
> cheers,
> Holger
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
>  ⠈⠳⣄
>
> If secure encryption is outlawed, only criminals will have it.
>
-- 
--
Ondřej Surý

Bug#976811: transition: php8.0

[Ondřej Surý]

The main problem is the PHP release schedule: 
https://www.php.net/supported-versions.php

If we release with PHP 7.4, the upstream security support will end sooner than 
security support for Debian bullseye. If we release with PHP 8.0 we will have 
full three years of upstream support.

There’s still month before the transition freeze and we will have time to fix 
the downstream users after the transition is over.

I think the transition is worth the trouble. Having official security support 
is important especially for PHP.

Ondřej 
--
Ondřej Surý  (He/Him)

> On 11. 12. 2020, at 17:38, David Prévot  wrote:
> 
> Hi Ondřej,
> 
> Le Tue, Dec 08, 2020 at 09:28:38AM +0100, Ondřej Surý a écrit :
> 
>> I would like to transition the PHP to version 8.0;
> 
> The timing of this request makes me uneasy: php8.0 has been in Debian
> for less than a week, and we are a month away from the transition
> freeze.
> 
>> it's not such a huge bump as it was with 5.6 -> 7.0 and
> 
> If I remember correctly, the 7.3 -> 7.4 was not a huge bump either, yet
> php7.4 packages were in Debian months before the actual transition
> happen, and it took months for the updated php-defaults to actually
> migrates into testing.
> 
>> most of the packages that were compatible with PHP
>> 7.4 are working just fine with PHP 8.0.
> 
> That does not match my experience as a maintainer of about a hundred
> packages relying on PHP. Many upstream are currently releasing updates
> to fix compatibility with PHP 8.0, and many more have not yet done so.
> 
> I’m actually surprised to discover this request in the BTS without any
> prior communication with teams involved in PHP related packaging.
> 
> For example, PHPUnit 8 as currently available in unstable and testing is
> expected to run on PHP 8 (thanks to upstream updates less than two weeks
> ago), yet “Please note that the code coverage functionality is not
> available for PHPUnit 8.5 on PHP 8.” (from upstream changelog 8.5.12).
> So shipping PHPUnit 8 with PHP 8 would mean having a major
> fonctionnality unavailable for the whole Bullseye life cycle. PHPUnit 9
> is available from experimental, yet uploading to unstable would mean
> having to deal with dozens of breakage (in the FTBFS form):
> 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#phpunit
> 
> PHPUnit is just one example, but it seems unrealistic to ship version 9
> with Bullseye (I really abandonned this option months ago). Other
> packages will break (and I suspect the number of breakage will be high).
> 
> This kind of disruptive change would hopefully be better suited early in
> the release cycle rather than just before the beginning of the freeze.
> 
> That said, it would be nice to have an updated php-default in
> *experimental* to help have a grasp of the possible brekages.
> 
> Regards
> 
> David

Bug#976811: transition: php8.0

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I would like to transition the PHP to version 8.0; it's not such a huge bump as
it was with 5.6 -> 7.0 and most of the packages that were compatible with PHP
7.4 are working just fine with PHP 8.0.

I do have most of the extensions ready for PHP 8.0 either via new upstream 
version
or with patches.

Ondrej

Ben file:

title = "php8.0";
is_affected = .depends ~ "phpapi-20190902" | .depends ~ "phpapi-20200930";
is_good = .depends ~ "phpapi-20200930";
is_bad = .depends ~ "phpapi-20190902";


- -- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl/POTZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLQvA//ZgsLvoyZ4q/KCMJwee2MzyDtLBrdkKr435kOsBNiBgS1n68eXiEM6TsX
9B+hIYcq2XDXG600y60IiB2NJ3yQ2MptzO7J56mA5es834s9fM8yoxvqEObxld4z
YCNi/3By9MXiCOFwy2cLuohnTNLvvvPXD0vGreqWl7+nLBCPNaOQtgo5V/fo/1fA
XiTC/0fPlYyAF8I4ZRFtopc4MckOuKdQNoRuSrGNpqYmSWIFMTdnauhQFUK7l5/o
PRcL7uz3WTV7t/yA3cKZ+Q/2d8tp/dCiBNQHZ9DEtJSa/c9kYf6v2UtHSs/9Vg6O
o/Q8Ueprh1145C3kPdM0qmMM6imKKhpi0cZp3SL9OejqxWjias1I4frNbnNQl4/7
CDi914TKq3ILO6fRQ7vFXJMwl3pEogGSIR8abnDgHRiKirmwP3eA/KWfuQti81yE
PzW1VoS1YRXqJKBHQ0QaTxlin9HlzVyR5PsBdIHWXNeD/rnm9L0lloPyFeaUWeBX
PnJk+5qRHKV/DpsH4WGYF3lxyyC45GckBOmw3ZBIsD+u2rEfKd58hqSdsHvkqaBc
lKmO+lsjBjDuBVDpbr8lEmTGyRmbJZuVa+rxsMfdiLvDdeFUfj90fzqquOjxvDLu
i3pLyjmgcMPyrjfQrRd54j31rSE9zfcLHT44ImqYvlOUI4AHI4k=
=IbF+
-END PGP SIGNATURE-

Bug#960376: buster-pu: package libyang/0.16.105-1

[Ondřej Surý]

stream bug 752)
+
+ -- Ondřej Surý   Tue, 12 May 2020 09:02:56 +0200
+
 libyang (0.16.105-1) unstable; urgency=medium
 
   * upstream 0.16.105 (0.16-r3) release
diff -Nru libyang-0.16.105/debian/gbp.conf libyang-0.16.105/debian/gbp.conf
--- libyang-0.16.105/debian/gbp.conf1970-01-01 01:00:00.0 +0100
+++ libyang-0.16.105/debian/gbp.conf2020-05-12 09:02:56.0 +0200
@@ -0,0 +1,7 @@
+[DEFAULT]
+debian-branch = debian/buster
+upstream-branch = upstream/buster
+pristine-tar = True
+
+[dch]
+meta = 1
diff -Nru 
libyang-0.16.105/debian/patches/0001-parser-BUGFIX-long-identity-name-buffer-overflow.patch
 
libyang-0.16.105/debian/patches/0001-parser-BUGFIX-long-identity-name-buffer-overflow.patch
--- 
libyang-0.16.105/debian/patches/0001-parser-BUGFIX-long-identity-name-buffer-overflow.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libyang-0.16.105/debian/patches/0001-parser-BUGFIX-long-identity-name-buffer-overflow.patch
 2020-05-12 09:02:56.0 +0200
@@ -0,0 +1,253 @@
+Applied-Upstream: f6d684ade99dd37b21babaa8a856f64faa1e2e0d
+Author: Michal Vasko 
+Last-Update: 2019-12-22
+Description: parser BUGFIX long identity name buffer overflow
+ STRING_OVERFLOW (CWE-120)
+
+diff --git a/src/parser.c b/src/parser.c
+index 3303041d15e7..281a97aac6d6 100644
+--- a/src/parser.c
 b/src/parser.c
+@@ -979,7 +979,7 @@ lyp_precompile_pattern(struct ly_ctx *ctx, const char 
*pattern, pcre** pcre_cmp,
+  * @param[in] data2 If \p type is #LY_TYPE_BITS: (int *) type bit field 
length,
+  *#LY_TYPE_DEC64: (uint8_t *) number of 
fraction digits (position of the floating point),
+  *otherwise ignored.
+- * @return 1 if a conversion took place, 0 if the value was kept the same.
++ * @return 1 if a conversion took place, 0 if the value was kept the same, -1 
on error.
+  */
+ static int
+ make_canonical(struct ly_ctx *ctx, int type, const char **value, void *data1, 
void *data2)
+@@ -994,6 +994,8 @@ make_canonical(struct ly_ctx *ctx, int type, const char 
**value, void *data1, vo
+ uint64_t unum;
+ uint8_t c;
+ 
++#define LOGBUF(str) LOGERR(ctx, LY_EINVAL, "Value \"%s\" is too long.", str)
++
+ switch (type) {
+ case LY_TYPE_BITS:
+ bits = (struct lys_type_bit **)data1;
+@@ -1006,8 +1008,10 @@ make_canonical(struct ly_ctx *ctx, int type, const char 
**value, void *data1, vo
+ continue;
+ }
+ if (buf[0]) {
++LY_CHECK_ERR_RETURN(strlen(buf) + 1 + strlen(bits[i]->name) > 
buf_len, LOGBUF(bits[i]->name), -1);
+ sprintf(buf + strlen(buf), " %s", bits[i]->name);
+ } else {
++LY_CHECK_ERR_RETURN(strlen(bits[i]->name) > buf_len, 
LOGBUF(bits[i]->name), -1);
+ strcpy(buf, bits[i]->name);
+ }
+ }
+@@ -1025,7 +1029,7 @@ make_canonical(struct ly_ctx *ctx, int type, const char 
**value, void *data1, vo
+ 
+ case LY_TYPE_INST:
+ exp = lyxp_parse_expr(ctx, *value);
+-LY_CHECK_ERR_RETURN(!exp, LOGINT(ctx), 0);
++LY_CHECK_ERR_RETURN(!exp, LOGINT(ctx), -1);
+ 
+ module_name = NULL;
+ count = 0;
+@@ -1035,9 +1039,9 @@ make_canonical(struct ly_ctx *ctx, int type, const char 
**value, void *data1, vo
+ /* copy WS */
+ if (i && ((end = exp->expr + exp->expr_pos[i - 1] + 
exp->tok_len[i - 1]) != cur_expr)) {
+ if (count + (cur_expr - end) > buf_len) {
+-LOGINT(ctx);
+ lyxp_expr_free(exp);
+-return 0;
++LOGBUF(end);
++return -1;
+ }
+ strncpy([count], end, cur_expr - end);
+ count += cur_expr - end;
+@@ -1051,9 +1055,9 @@ make_canonical(struct ly_ctx *ctx, int type, const char 
**value, void *data1, vo
+ if (!module_name || strncmp(cur_expr, module_name, j)) {
+ /* print module name with colon, it does not equal to the 
parent one */
+ if (count + j > buf_len) {
+-LOGINT(ctx);
+ lyxp_expr_free(exp);
+-return 0;
++LOGBUF(cur_expr);
++return -1;
+ }
+ strncpy([count], cur_expr, j);
+ count += j;
+@@ -1062,17 +1066,17 @@ make_canonical(struct ly_ctx *ctx, int type, const 
char **value, void *data1, vo
+ 
+ /* copy the rest */
+ if (count + (exp->tok_len[i] - j) > buf_len) {
+-LOGINT(ctx);
+ lyxp_expr_free(exp);
+-return 0;
++LOGBUF(end);
++return -1;
+ }
+ strncpy([count], end, exp->tok_len[i] - j);
+   

Bug#954829: nmu: php-apcu_5.1.18+4.0.11-1+0~20191219.13+debian10~1.gbpa99079

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

the PHP 7.3 has been removed from unstable, could you please binNMU these?  This
should fix the remaining autopkgtests problems that prevent migration of
php-apcu and xdebug to testing.  Thanks, Ondrej

nmu php-amqp_1.9.4-3 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-apcu-bc_1.0.5-2 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-apcu_5.1.18+4.0.11-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-ast_1.0.6-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-ds_1.2.9-2 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-facedetect_1.1.0-19-g135c72a-1 . ANY . unstable . -m "Remove PHP 7.3 
support"
nmu php-gearman_2.0.6+1.1.2-7 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-geoip_1.1.1-5 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-gmagick_2.0.5~rc1+1.1.7~rc3-5 . ANY . unstable . -m "Remove PHP 7.3 
support"
nmu php-gnupg_1.4.0-6 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-guestfs_1:1.40.2-7+b3 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-http_3.2.3+2.6.0-4 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-igbinary_3.1.2+2.0.8-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-imagick_3.4.4-4 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-libvirt-php_0.5.5-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-lua_2.0.7+1.1.0-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-mailparse_3.0.4+2.1.7~dev20160128.orig-1 . ANY . unstable . -m "Remove 
PHP 7.3 support"
nmu php-memcache_4.0.5.2+3.0.9~20170802.e702b5f9-1 . ANY . unstable . -m 
"Remove PHP 7.3 support"
nmu php-memcached_3.1.4+2.2.0-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-mongodb_1.7.4-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-msgpack_2.1.0+0.5.7-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-oauth_2.0.5+1.2.3-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-pcov_1.0.6-2 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-pinba_1.1.1-3 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-propro_2.1.0+1.0.2-3 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-ps_1.4.1-1+b3 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-psr_1.0.0-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-radius_1.4.0~b1-10 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-raphf_2.0.1+1.1.2-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-redis_5.2.1+4.3.0-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-rrd_2.0.1+1.1.3-7 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-sass_0.7-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-solr_2.5.0+2.4.0-4 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-ssh2_1.2+0.13-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-stomp_2.0.2+1.0.9-3 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-tideways_5.0.2-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-uploadprogress_1.1.3-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-uuid_1.1.0-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-xdebug_2.9.3+2.8.1+2.5.5-1 . ANY . unstable . -m "Remove PHP 7.3 
support"
nmu php-yac_2.0.4+0.9.2-1 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-yaml_2.0.4+1.3.2-2 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-zeroc-ice_3.7.3-1+b2 . ANY . unstable . -m "Remove PHP 7.3 support"
nmu php-zmq_1.1.3-11 . ANY . unstable . -m "Remove PHP 7.3 support"

- -- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl55tXFfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKlHw//We0PVXmOo10iIFIvInHwfCa9s5HBDEHgdR4JyZE6KaAMsmNo943TFzv0
3Vmk9Ouog3rAlM3myrY0A5Ucgm8/F1C22a7GrqYpjwhezNOj85xywhbILE04ik8J
OFwRCItC5Fjjdq2s1zvPBhhEOQTp7kp20wxEv71t5qe156oEQDMWoECm4n5wNV7Q
kFkcnipP0Kf6VUeO+3tC36YuhnBA/a9zDsuWdxwIn+8OxVZaDMWUcEZHJdNOzf2T
FpScc0q6nxHfjXO8zjNcYI8tR+jOJ2hls8g6nZmJrIaaEuVMJcrqUha9NDcy3Uwr
M4HBqsOWPFOz3mh+xGZhcnm+hYe0vWGtrP0VrvaMS9P3uf0j79qlZTF/8xan02wU
AtliTJbFwJA0qEIZe/t9diycIHM2K45upOZ3CtP+VfmpTYyWrgOKZ/sWXl6+qFzT
HvhzgfBC7MorQLtkFJ9cpf8Qha5YuBdUnDNTzVWDjexAjSYr9zc4YhuCZv6SxZBI
nC0iqhT0D974C/uN42AdrF7oeJleBPAkJROomK2C7g5TeTb4coV1qYi6UbnnHAl7
Fbq6VPGyR8e0WM0W/gaoSgYh/4SWh2BkLjPmqtFEkwDLgpyUELznb2x2pPMiRMZH
5i9SqbFt2qFJRuIsvTTJIHp1eNLiWN3h3eWud4tVwByWkFsAfI8=
=8g6d
-END PGP SIGNATURE-

Bug#954746: nmu: isc-dhcp_4.4.1-2.1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu isc-dhcp_4.4.1-2.1 . ANY . unstable . -m "recompile to fix double 
libdns-export.so linking"

Hi,

the #954736 was filled as result of dhcpd crash, because of double link against
libdns-export.so.1109 and libdns-export.so.1110:

(sid-amd64)root@calcifer:/home/ondrej# ldd /usr/sbin/dhcpd
linux-vdso.so.1 (0x7ffe5236a000)
libeatmydata.so => /usr/lib/x86_64-linux-gnu/libeatmydata.so 
(0x7efc93c96000)
libdns-export.so.1109 => /lib/x86_64-linux-gnu/libdns-export.so.1109 
(0x7efc93a64000)
^^^
libisc-export.so.1105 => /lib/x86_64-linux-gnu/libisc-export.so.1105 
(0x7efc939eb000)
libirs-export.so.161 => /lib/x86_64-linux-gnu/libirs-export.so.161 
(0x7efc939dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7efc9381a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7efc93815000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 
(0x7efc93527000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7efc93506000)
libdns-export.so.1110 => /lib/x86_64-linux-gnu/libdns-export.so.1110 
(0x7efc932cb000)
^^^
libisccfg-export.so.163 => 
/lib/x86_64-linux-gnu/libisccfg-export.so.163 (0x7efc9329c000)
/lib64/ld-linux-x86-64.so.2 (0x7efc93da)

So, dhcpd links with libdns-export.so.1109, but libisccfg-export.so.163 links
with libdns-export.so.1110.  The symbols in libdns-export.so are not versioned,
hence the crash, because dns_g_mctx gets initialized in one library, but the
symbol in other library gets used (and not initialized).

Before I come with better fix, could you please binNMU isc-dhcp?

Ondrej

- -- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl530JNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcIdWw//c0hmBRlzxie2OA6wJlhHK8F3LE4Sc85oBlUTu/gNdvhOTsMMcBISHff7
AzfvRiINzNKx7/hmsFA9liPoE74n/O7fUnoCK7h6eDN9zqdhROSdvAuPneh1Mzl+
a0UcR7MXkuS6V8UTV+dqXuHrKAGLl05drEOrsZUt4z5WwP5Bzovia4JKwdE71/7H
uw2CKhlECKekstNlZ8UYrDNdxKPpNAetZ5i2eW1btJSNcvEQUO/FZDcP0IlG85Ef
Ya4STDBufv8SGZNNIjEPFtnOMVPhQHfcWoCqrbxW6xYRkcvlctxzAZy2gn/upPvK
Z2EEAkc0NCwIfCAtJQt5qUI4xt0JDmNgTgi2qKZvT5bYV+ijL6zEluMoiXuv7jMR
/Ss+uBSjyMqVb0mXscxeNvxTesNTlPqjvoQhCDwVW2SIiMaYBKOFLWra89Zl5yUK
iQjAq9SPthLJx9qersODy9kr5IocBcpcLPSDb82iYSFKrpqMEGL872ZSgt4glWhJ
iEbrGnTn/F52tUCgWoMvnqHstEdqkz05irk6EpGCPItnEeX94vlOwEulfPeKiuKU
ozL+igEZvj10Vik97TJPu4vrHoygVO4twvrWXRs+GyY/mxAtGpxhdjpnsjN0Tnl7
HDHhS8/RaxH/DoX8ni/l1io7ZJ7yOgKNCqwiEjU5i8K0E0GJ8mg=
=FyiS
-END PGP SIGNATURE-

Bug#952607: transition: php (soft transition)

[Ondřej Surý]

Hi Emilio,

It certainly won’t hurt, at least I can check what FTBFS and either fix it or 
fill
a bug.

I am bit confused about php-raphf and php-propro though - I guess a manual
check will be needed.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 16 Mar 2020, at 12:33, Emilio Pozuelo Monfort  wrote:
> 
> Hi Ondřej,
> 
> On 11/03/2020 09:57, Emilio Pozuelo Monfort wrote:
>> Ack, keep us updated on the progress here and let us know if you need 
>> anything.
>> I have added a ben tracker now, but it will take a bit to show up on the 
>> webserver.
> 
> Should I binNMU the remaining bad packages in the tracker? Or do those need
> source updates?
> 
> Cheers,
> Emilio



signature.asc
Description: Message signed with OpenPGP

Bug#953155: buster-pu: package bind9/1:9.11.5.P4+dfsg+1-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: buster, stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

recently, there was a bug #952946 filled against BIND 9 (and other packages)
about license problem with OASIS PKCS#11 (pkcs11.h) that has incompatible
license.  Upstream has already fixed that in the next upstream release to be due
in March and the question here is whether we want to do the dfsg to dfsg+1 bump
just because of the pkcs11.h header in both buster and stretch.

Thanks,
Ondrej

- -- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl5g1yxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJx+g/+MvoycUBOX4RnfL2lmlbX+Po/F/mN55uVYsT16TDPU1rAFTkNYvRfvCO6
hfRuOmzkA0bhGyD6Oy8JKVw6ukYZ/oDyS3YLY37pbpl9StCmHqfyzYo0G/iDSVhh
e9Df+MYfpf3l6y1+US4EfC0a2+fLbrT/1TNJicF5Bm0Nin61nm03ZRTY52LaLp5y
uBxFzpDMbwfs5L6hfqkpUbsUmXBamRiK0gnNTwaUmN48Zjv6hVoQJDe9Ho8hjwE4
RPyzCYXapzjWXl2NPjvhOEBOXg9UOdNCLv2vl2RYIpj1P6y56N+j4OP8qxW/9nTf
Ww3kdr4z+w71UlQAbklRuAMzXBVr4QuapirXCOhJz07Rxs9o+jCzZhPKmQlt4ON9
V1uVCGavJgJowX2frm4L+RrGHuU3JIuG6HaYVnyIXLUvQFnVqFXEKAmJzHe7HffD
ze+lCuMYfu6tJYXdtYoBzuf2f5L7DDNSZl2U/P3sNpYNityHzn6TjAUlkhegyXZx
41+qIX+m/xMT8fB2u0Cwvdgh8sTVT2EYdwGVjNK4DjQ+xy9F0GYG6ukSWI0Dh6/Y
i8ubmVAI1mu4qzuKAbDaexsP592wgGL62KSQRcgqcoIqxasLxHU8PYvWsbHu78kq
rheG3gA5ocj8GSxuvc/a+lQSKJIbSWjSntBkcneGgKc09xyK6pI=
=Buio
-END PGP SIGNATURE-

Bug#952607: transition: php (soft transition)

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I only recently discovered that reportbug ate all emails that had
postmaster@.  That and G-Suite changing MAIL FROM to
 when the original MAIL FROM was 
caused my previous emails on the PHP 7.3 -> 7.4 transition to be never
delivered.

Nevertheless I accidentaly uploaded php-defaults switching the default PHP
version to 7.4.  It doesn't make sense to switch it back as most of the affected
extensions have been already recompiled, and the change from 7.3 to 7.4 isn't
really that big, so it should not affect any existing PHP code base.

This is soft-transition, most of the extensions support both PHP 7.3 and 7.4 at
the same time.  I'll drop the 7.3 dependency when the extensions are rebuilt and
I am reasonably sure all the PHP packages are OK.

Ben file:

title = "php";
is_affected = .depends ~ "phpapi-20180731" | .depends ~ "phpapi-20190902";
is_good = .depends ~ "phpapi-20190902";
is_bad = ! .depends ~ "phpapi-20190902";

- -- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl5WlwdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJiWQ/+O14zWsHgvKBENt7y7+Shn+mZdXE6P+TW53hrtUKCA6C51pgp45soe2RB
aWnU624powdOVS4KBTlKVepqQlpzPAGJF+ySOkauzLtXECt/Ol26tUspT8WWlxjp
pN/lGF3rRDTvD96FEGfxXNA7xQRAlzWUvxpZTmVtblsDJOXOjINZX8/i+/GNswBc
x0xATLza+5t3UU+8q+aWvVpMPsTPcgojj9254r3oH4/XACM1w78BkUL9d+7zWXy3
BNLMeQydhl0ICznouwRC6EiEK74VJfxKS5IBBbg4wrbBTWrZhNWRlcMZgOpbyMDG
hMxp3MQZPrXs04z2aq8aTeNyfhJeycmCaszdDtKE2vCWpbl0BwOwONoKOqvPrpvT
fNiUmInUNb7YodgR10aPwWBJF4wiVP1BfZv3edSy+grN6lTD8yvHaUDSQWEideKq
sTpUZGMRYVcrdXCqNybRVQYTdUOOyBl0wNwNQnGfoCYQDOKuW7gPfzY7AqdYMdXD
2lMX2Ow+JxUGQTVfT9Fd3t7z7e13V7tsP/o9dYawvLPcqKmpGoHOAV1YsqNoSh4r
BdmtQOfP9/OIpoWj4kDbYB12nsWpbu2LQcGiuuG0QCwYEYsMBndvN5MRll7ItFcg
qp3tt9oUP9k4nhhhdasM9/tQ+VMjrOVB1cVstqmuI8Rn9x5fCx0=
=dUIS
-END PGP SIGNATURE-

Bug#952604: nmu: zeroc-ice_3.7.3-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu zeroc-ice_3.7.3-1 . ANY . unstable . -m "Rebuild for PHP 7.4 transition"

Hi, this is the last binary package affected by (unplanned) PHP 7.4 transition
and it compiles just fine, it only needs binNMU.

Thanks,
Ondrej

- -- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl5Wk/dfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJS6Q//WTX/aG6vRVGPuLYRkNLiwpruaCd8CLDuskQhSjgjbpnMvlJfgRvcfe/P
AYZPTquukAX3bHWGyyuharE2GMcHQXZ7/9y7RNj2VGqGL91ALGtIIrno5h5AfZxl
34dCcd4LnHSWAz9I1Df0TxfFhI/NYM5ltmAXgO51qHKTNGK2pPc4qMFlXJH75tek
we4Fz0VMleNI6r/QvQS48sKm0VwNNp9gVXn3EfoXFGNrZxkuB/ZgAJt7nbUlEyXL
J6HaBhSxNWZ1fTykzY8C6ZVPNGF+suqxNbddT2aU7+BlO3ZNZkW5pzuUZkCfrkph
LahfBsmEcOJf2PjpjG6FyYK53f3+uf14CaCycG6ixAvy7VXu9M12maCrUsPtrAdN
BIzrFRJkD66s89/QYyD73x4/COabeP9U+xeDN9uoOOeu0Eur66pbJZEUlQTkJ1lk
5enxudQNl0SypUYgJODrlNQ1TG082PXBB34GSfwoiucGF4gGub4dyTvpR87+79jn
gbvrt30RunYRcvZJ50y4g7Oe10Ypvq1RGEPEhkX0k1NiX5Sg0jjUJRXhzEHekWyr
5iAAYpLhyawvACKM9hqlwxEWuua9bjd7YxefdyMsqAzVzUX9mdcW1ju8w3w+AeVA
OXUq+ulFcKjzbj2K2fK7wwzYCoOcENaY5agHgAwVq/nG918qKwM=
=ExwB
-END PGP SIGNATURE-

Bug#924900: unblock: libzip/1.5.1-4

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package libzip

libzip 1.5.1-4 contains fix for upstream issue that
can result in corrupted archive, I was poked by upstream
to fix this in Debian buster:

> We've fixed a serious bug in AES encryption today. With some
> particular file sizes the HMAC would not be written, and incomplete
> files were in the archive.

Thanks,
Ondrej

unblock libzip/1.5.1-4

- -- 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.19.0-2-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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++uWcIFAlyPVFpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcIEcQ//V14C6SH49m2im4pTgZJWqu2LY9w/rQzWC0dNq6LX6EQDorrh2x+ntvMf
DtuDK8dKdcpBQsbUVdUueaHP1UjdK31GDLFB5ITW19yO3ohdc87rWKH+Uyk7r1rO
pogWyLp20W0WPfIStn2+RdnVGZ7JavVoe5n8htIKoKgG341EauJcRVg1Mmdpzn75
xMePY4/J6XA5XDIl5IHieNjwEx6o0ALQE+oEa9IIt2aUtLzCNXVm1fTvSigXa31n
I0lsbnblrp5HdK/a2vADXtmHTicli9hqhj/7btGPp29WuCaYmjfteUfnsuX6S8mh
ySm/S+Ar0ijB1N4y2xIgXkFdSailWm8b7TE3x6rJGcxJ/tb765j1xC77XrRPydqr
Gt3jOg5o2UogYGdVrfBg1szM5zUv2RzSrJj7JZ/VGs1UObj0kqTV0TcMmTcheO4p
9dCZP6fMdagOsTNXDPV8zzdEn2eOn6E7IBE7tL8cXk/YddouP4S6kh6SroGQERuB
Xh6V8ZAzFXx/9xXNYmnWHFgprYbVBRpXL78Fs4fZZq3oO28UdCKg9zpG8kX8lLxQ
XS7rxt3sxcX1ngAS13tBOkWoVOmerZD0nbdRicu2MlP+4Eh30AUI6cqEpbb6pVl+
brQzvxOqVhkPLwgyiylvyt/8sMpaVMbN/z/hOZmnSihiLf0EROg=
=9+Ee
-END PGP SIGNATURE-

Re: toulbar2: What will happen if testing migration takes longer than removal from testing

[Ondřej Surý]

Hi,

I believe that it was the case before that if the autoremoval was due a 
specific RC bug, any activity on that specific bug would reset the timer for 
autoremoval.

But it might have changed since… or my memory is failing me.

Cheers,
Ondrej

> On 19 Feb 2019, at 08:46, Andreas Tille  wrote:
> 
> Hi,
> 
> toulbar2 is
> 
>   Marked for autoremoval on 22 February: #916715
> 
> However, this bug was closed in
> 
> 
> toulbar2 (1.0.0+dfsg3-1.1) unstable; urgency=medium
> 
>  * Non-maintainer upload.
>  * Add the missing build dependency on zlib1g-dev. (Closes: #916715)
> 
> -- Adrian Bunk   Fri, 11 Jan 2019 13:47:51 +0200
> 
> 
> The problem is that the package did not migrated due to #920459 (doxygen
> currently breaks lots of packages and I wonder in general what will
> happen with those packages).  I now uploaded
> 
> 
> toulbar2 (1.0.0+dfsg3-2) unstable; urgency=medium
> ...
>  * Prevent generation of PDF documentation since otherwise toulbar2 does
>not build (see bug #920459).  This means should be reverted once doxygen
>is fixed.
> ...
> -- Andreas Tille   Mon, 18 Feb 2019 22:17:10 +0100
> 
> 
> Which enabled the build on all release architectures.
> 
> I'm simply wondering what will happen with toulbar2 (and other packages
> - I'm actually not that much involved in this, it is just a random
> Debian Science package) once it was removed from testing.  As far as I
> understood there will be no migrations from unstable to testing any more
> if there is no version of that package in testing.  Does that mean that
> the doxygen issues will kick several packages out of Buster or is there
> any way to prevent this?
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 

Bug#906643: Bug#911832: Bug#906643: transition: php7.3

[Ondřej Surý]

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

[Ondřej Surý]

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

[Ondřej Surý]

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: transition: php7.3

[Ondřej Surý]

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

[Ondřej Surý]

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

[Ondřej Surý]

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

[Ondřej Surý]

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#910136: nmu: php-ast_0.1.6-2

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu php-ast_0.1.6-2 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-geoip_1.1.1-2 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-gmagick_2.0.5~rc1+1.1.7~rc3-2 . ANY . unstable . -m "Rebuild for PHP 
7.3"
nmu php-gnupg_1.4.0-2 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-msgpack_2.0.2+0.5.7-5 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-propro_2.1.0+1.0.2-1 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-radius_1.4.0~b1-8 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-raphf_2.0.0+1.1.2-3 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-rrd_2.0.1+1.1.3-5 . ANY . unstable . -m "Rebuild for PHP 7.3"
nmu php-uuid_1.0.4-6 . ANY . unstable . -m "Rebuild for PHP 7.3"

Hi,

this is a first round of PHP 7.3 related binNMUs for PHP extensions
that I directly maintain, the other batch is waiting for PHP 7.3.0~rc2
to hit unstable that added Depends on libpcre2-dev to php7.3-dev.

And the rest either needs new upstream version, or a patch, so it will
be handled as separate upload.

Thanks,
Ondrej

- -- 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++uWcIFAlu0bG9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcL58xAAlt74VOGlzPN41LKjwpzYuOxnho7DqY/5HREFTwkSQC/YSH2ueGkVYnWe
ogazwX5Omffk2Ti7Q9e+3vomzsILJH8b1utDeUGiOslUAA6TUazKhxGqv15FggTz
tj+/tQecJ+Iwz9Ig0gbGLQdtIR+XsP3LrvDZ6Ca3Unxmd9TYEAPLFRBaxU7YVVsg
khhCV2dPYpNntALYkM81Eq3bV2uHeOGeco8qfBjBa1dB/AuvIYn6d/xe1VwGsFhD
80xnQFTvLuu+68SWBJF6iBJyYpmsLDoWpmTzre0UxRfjFFDvRWrksY2StYELgNhM
07nMGvysyXLPyHnqYENsBez7UPg6RwHS3q2PuJKDoyBCUMdcO6LavvhArr5wCWN3
5+IOyIIoRCWduQHC+0TY+x3anBoAOXHkFURLESZWD7T88c32Kp/jbMdxoYnEHH5O
UBBXqlSYsEfEvtiXSbrjfSggcrsZjvZgRZ3DriC8aUtbpw585vDCCSUUq8tXpXc7
CDMtSdCc3mYYinaS1jVPO8NB5ZeFkK5OB8H759fE2G9EU/xIjHzl7dNUbeeJ5WDq
hJw6vX7V70pjQNhqgpJKbXrYcBgppnqrjdeQhi0vEt9l2gaJ/R5DrwZdZibEMbL6
OkF/fUomSUxBXAF9GGWYnvutwe+ZFebDC7KoL9XNiU6n6BKLjIc=
=MDjY
-END PGP SIGNATURE-

Bug#906643: transition: php7.3

[Ondřej Surý]

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#910072: RM: php7.1/7.1.20-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

it looks like also PHP 7.1 can be removed from testing without adverse effects:

$ dak rm -nR --suite=testing php7.1
Will remove the following packages from testing:

libapache2-mod-php7.1 |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libphp7.1-embed |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.1 |   7.1.20-1 | source, all
php7.1-bcmath |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-bz2 |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-cgi |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-cli |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-common |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-curl |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-dba |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-dev |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-enchant |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-fpm |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-gd |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-gmp |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-imap |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-interbase |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.1-intl |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-json |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-ldap |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-mbstring |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.1-mcrypt |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-mysql |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-odbc |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-opcache |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-pgsql |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-phpdbg |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-pspell |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-readline |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.1-recode |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-snmp |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-soap |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-sqlite3 |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-sybase |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-tidy |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-xml |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-xmlrpc |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.1-xsl |   7.1.20-1 | all
php7.1-zip |   7.1.20-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian PHP Maintainers 

- --- Reason ---

- --

Checking reverse dependencies...
No dependency problem found.

Thanks,
Ondrej

- -- 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++uWcIFAluzSetfFIAALgAo

Bug#910071: RM: php7.0/7.0.31-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

it looks like PHP 7.0 can be removed from testing:

$ dak rm -nR --suite=testing php7.0
Will remove the following packages from testing:

libapache2-mod-php7.0 |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libphp7.0-embed |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.0 |   7.0.31-1 | source, all
php7.0-bcmath |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-bz2 |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-cgi |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-cli |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-common |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-curl |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-dba |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-dev |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-enchant |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-fpm |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-gd |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-gmp |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-imap |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-interbase |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.0-intl |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-json |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-ldap |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-mbstring |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.0-mcrypt |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-mysql |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-odbc |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-opcache |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-pgsql |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-phpdbg |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-pspell |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-readline |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
php7.0-recode |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-snmp |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-soap |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-sqlite3 |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-sybase |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-tidy |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-xml |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-xmlrpc |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
php7.0-xsl |   7.0.31-1 | all
php7.0-zip |   7.0.31-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian PHP Maintainers 

- --- Reason ---

- --

Checking reverse dependencies...
No dependency problem found.


Thanks,
Ondrej

- -- 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++uWcIFAluzSX1fFIAALgAo

Bug#906643: transition: php7.3

[Ondřej Surý]

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-

Bug#884109: stretch-pu: package mariadb-10.1/10.1.29-0+deb9u1

[Ondřej Surý]

Hi KiBI,

> On 10 Feb 2018, at 10:52, Julien Cristau <jcris...@debian.org> wrote:
> 
> Control: tag -1 moreinfo
> 
> Hi Ondřej,
> 
> On Mon, Dec 11, 2017 at 14:22:03 +, Ondřej Surý wrote:
> 
>> this is stretch-pu for mariadb-10.1.29 upstream release and couple of
>> fixes that creeped in stretch version just before freeze.
>> 
>> Fixes:
>> 
>> * #875708 - Add libconfig-inifiles-perl to mariadb-client-10.1 depends to 
>> fix mytop
>> 
> ok
> 
>> * Failing non-release archs were added to the list of architectures that are 
>> allowed
>>  to fail test
>> 
> that doesn't sound necessary in stable?  harmless though, so probably
> ok.
> 
>> * mips64el was added to a list of other mips* platforms allowed to fail the 
>> tests
>> 
> That's a bit confusing, where did the mips64el binaries we do have come
> from if tests are expected to fail?

mips and mipsel has been on this list since 2015 (10.0.23-1 debian release) as 
upstream doesn’t guarantee that the tests will pass on this platform, so the 
change just rectifies the situation after mips64el was added to the release 
architecture list.

As a side note: There has been recent work to move the whole suite to the 
autopkgtest suite instead of running it as a part of build process, and fix any 
failing tests on non-major platforms in asynchronous manner.

>> * I reverted upstream decision to use embedded pcre3 library as we
>>  need to fix #878107 and #876299 in jessie and stretch too
>> 
> Is there a plan for doing this?  I'm not seeing a pu request for pcre3.

I already offered Matthew Vernon help with pcre3, but it’s not my place to 
request pu for other people packages. As far as I remember this affects only 
edge cases on edge architectures, but it was broken before anyway, so we are 
basically just keeping status quo.

>> Upstream:
>> 
>> * There's couple of minor security fixes that doesn't warrant security
>>  update, but it should be updated nevertheless (this this pu request).
>> 
>> I'll send the debdiff in a reply to this email, so this message reaches the 
>> list.
>> 
> I'm seeing quite a bunch of patch noise, including dropping patch
> descriptions (and authorship), which seems less than helpful.  Can we
> please not?

I switched to gbp pq for patch management as it makes it easier for me to manage
the patches, but I can revert the most intrusive changes. Dropping the 
descriptions
and authorship was not intended.

Ondřej
--
Ondřej Surý
ond...@sury.org

Bug#872998: transition: php7.2

[Ondřej Surý]

Yes, please, go ahead, and I will fix any eventual build failures as it goes.

Ondrej
-- 
Ondřej Surý <ond...@sury.org>

On Sat, Jan 27, 2018, at 00:20, Emilio Pozuelo Monfort wrote:
> On 25/01/18 12:55, Emilio Pozuelo Monfort wrote:
> > Control: reopen -1
> > Control: retitle -1 transition: php7.2
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/php7.2.html
> > 
> > On 25/01/18 12:27, Debian Bug Tracking System wrote:
> >>  php-defaults (60) unstable; urgency=medium
> >>  .
> >>* Start the soft-transition to PHP 7.2 by adding 7.2 to a list of
> >>  supported versions and making PHP 7.2 the default Debian version
> >>  (Closes: #872998)
> > 
> > This is not fixed yet. Let's keep it open until the transition is finished.
> 
> Now that php7.2 is built and php-defaults has been updated, can I schedule the
> binNMUs?
> 
> Cheers,
> Emilio

Bug#872998: transition: PHP 7.0 to 7.1

[Ondřej Surý]

I should probably clarify that - I already have all (if not most) extensions 
supporting PHP 7.0, PHP 7.1 and PHP 7.2 ready, so I'll be uploading those along 
with the php-defaults upload.

Also I don't have any reports of neither PHP 7.1 nor PHP 7.2 breaking 
something. Perhaps except php-mcrypt being dropped from PHP 7.2.

Ondrej
-- 
Ondřej Surý <ond...@sury.org>

On Wed, Jan 24, 2018, at 18:29, Ondřej Surý wrote:
> Thank you!
> 
> I'll upload the updated php-defaults that sets PHP 7.2 as the default 
> PHP version as soon as it's built on all platforms.
> 
> O.
> -- 
> Ondřej Surý <ond...@sury.org>
> 
> On Tue, Jan 23, 2018, at 18:50, Emilio Pozuelo Monfort wrote:
> > On 05/01/18 15:54, Ondřej Surý wrote:
> > > I have just uploaded next round of PHP upstream releases including 7.2.1 
> > > that clears all d/copyright issues that ftp-masters had.
> > > 
> > > I responded to the REJECT email, so hopefully this will speed up the 
> > > process of accepting PHP 7.2 into the unstable.
> > 
> > I prodded them and it's accepted now.
> > 
> > Cheers,
> > Emilio

Bug#872998: transition: PHP 7.0 to 7.1

[Ondřej Surý]

Thank you!

I'll upload the updated php-defaults that sets PHP 7.2 as the default PHP 
version as soon as it's built on all platforms.

O.
-- 
Ondřej Surý <ond...@sury.org>

On Tue, Jan 23, 2018, at 18:50, Emilio Pozuelo Monfort wrote:
> On 05/01/18 15:54, Ondřej Surý wrote:
> > I have just uploaded next round of PHP upstream releases including 7.2.1 
> > that clears all d/copyright issues that ftp-masters had.
> > 
> > I responded to the REJECT email, so hopefully this will speed up the 
> > process of accepting PHP 7.2 into the unstable.
> 
> I prodded them and it's accepted now.
> 
> Cheers,
> Emilio

Bug#872998: transition: PHP 7.0 to 7.1

[Ondřej Surý]

I have just uploaded next round of PHP upstream releases including 7.2.1 that 
clears all d/copyright issues that ftp-masters had.

I responded to the REJECT email, so hopefully this will speed up the process of 
accepting PHP 7.2 into the unstable.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>

On Thu, Jan 4, 2018, at 18:42, Emilio Pozuelo Monfort wrote:
> On 16/12/17 10:57, Emilio Pozuelo Monfort wrote:
> > On 08/12/17 19:55, Emilio Pozuelo Monfort wrote:
> >> On 05/12/17 17:23, Ondřej Surý wrote:
> >>> Hi Emilio,
> >>>
> >>> the php-defaults has been uploaded some time ago, and some extensions
> >>> have already been rebuild.
> >>
> >> Ah, I didn't know we were ready to schedule binNMUs.
> >>
> >>> However with PHP 7.2 release, it might make sense to take this one step
> >>> further and add PHP 7.2 as the target for the transition (after it
> >>> passes NEW queue).
> >>
> >> Ok, that makes sense. Let's wait for 7.2 to clear NEW and for php-defaults 
> >> to be
> >> updated, then.
> > 
> > 7.2 is out of NEW now. Let me know when php-defaults is updated and we're 
> > ready
> > for some binNMUs.
> 
> Any update on this?
> 
> Cheers,
> Emilio

Bug#884109: stretch-pu: package mariadb-10.1/10.1.29-0+deb9u1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

this is stretch-pu for mariadb-10.1.29 upstream release and couple of
fixes that creeped in stretch version just before freeze.

Fixes:

* #875708 - Add libconfig-inifiles-perl to mariadb-client-10.1 depends to fix 
mytop

* Failing non-release archs were added to the list of architectures that are 
allowed
  to fail test

* mips64el was added to a list of other mips* platforms allowed to fail the 
tests

* I reverted upstream decision to use embedded pcre3 library as we
  need to fix #878107 and #876299 in jessie and stretch too

Upstream:

* There's couple of minor security fixes that doesn't warrant security
  update, but it should be updated nevertheless (this this pu request).

I'll send the debdiff in a reply to this email, so this message reaches the 
list.

Ondrej

- -- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-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)

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAloulIpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKpxg/+MylyvOm6JEzVr6O7AEZzRAuKYgfB3ULZtHMGZnDdl47ddwCyRoqEckLE
UycZQnttMb/FZIF8GKibr+hoFWl8Va791aWtnsGziMsu9a7v3yplbjrsmjji0smZ
b9B56mLvN97BDVPgeMIj7G6HQRe2xM8+RZQ020zPIzy9hNN4LKb5egzohHAq0h8W
vnIrB8gc0wm5AckAvJ3aWCKBUkh4tdHvJO36vJMbjgbxw2FZxK4hOD9WYaFo3RxO
yr2fsLSGkpxN+Y1wG2uleSMEPUwp/grHMUS388qbZy1+Crqz/9ULBvKFkKAHAj73
ym80GC8Y1479sO+vQuR92YOxPO/h2U3sGd/KThEc1FmvKfL7B31NMq4m49nfSHPF
vvh4gO9IxcDFfs5B/USV44Zb+9NFBL3yD+xDH1lYsAKmH7yJ541453YmJsFYXS9X
ZkHgLziUhxK41smAqlwFvT4GluQXU2hTXtwFi3AZclI4kq+iQckNYa8Ek/XSY1Bw
R63tHGoAPnbDz8S7Cah++FRimVm17eJNZwVxESTOR9mvewxpVZp2Hyv2+d6TgQfa
o0l4Csx77JthKtStjGjfI7XlWNVwi08RTk2INQcrLEdEGXwJ3XNBsy/AYGmzeuWF
v8KIBBPC5n4urStCrGou7klOsPavIywMA3K2tQgFDUjPru1wZYg=
=+7ql
-END PGP SIGNATURE-

Bug#882909: debdiff for 10.0.33-0+deb8u1

[Ondřej Surý]

Hi,

I will be attaching debdiff for mariadb-10.0 in a followup separate
email, so at least this message reaches debian-release.

Apart from new upstream release, I am rolling back upstream change that
would use embedded pcre3 library and refreshing patches.

Sorry I missed the deadline for next point release, but my IRL point
releases are sucking up all the energy I have left.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>

Bug#872998: transition: PHP 7.0 to 7.1

[Ondřej Surý]

I have a couple of updated PECL packages anyway, so there would be a
little binNMUs.

O.
-- 
Ondřej Surý <ond...@sury.org>

On Fri, Dec 8, 2017, at 19:55, Emilio Pozuelo Monfort wrote:
> On 05/12/17 17:23, Ondřej Surý wrote:
> > Hi Emilio,
> > 
> > the php-defaults has been uploaded some time ago, and some extensions
> > have already been rebuild.
> 
> Ah, I didn't know we were ready to schedule binNMUs.
> 
> > However with PHP 7.2 release, it might make sense to take this one step
> > further and add PHP 7.2 as the target for the transition (after it
> > passes NEW queue).
> 
> Ok, that makes sense. Let's wait for 7.2 to clear NEW and for
> php-defaults to be
> updated, then.
> 
> Cheers,
> Emilio

Bug#872998: transition: PHP 7.0 to 7.1

[Ondřej Surý]

Hi Emilio,

the php-defaults has been uploaded some time ago, and some extensions
have already been rebuild.

However with PHP 7.2 release, it might make sense to take this one step
further and add PHP 7.2 as the target for the transition (after it
passes NEW queue).

Ondrej
-- 
Ondřej Surý <ond...@sury.org>

On Mon, Dec 4, 2017, at 18:59, Emilio Pozuelo Monfort wrote:
> Hi Ondřej,
> 
> On 10/09/17 11:25, Emilio Pozuelo Monfort wrote:
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/php7.1.html
> > Control: tags -1 confirmed
> > 
> > On 23/08/17 15:18, Ondřej Surý wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: transition
> >>
> >> Hi,
> >>
> >> this is request for PHP 7.0 to PHP 7.1 transition.  In fact, I could
> >> make this a "soft" transition and build the PECL extensions for both
> >> PHP 7.0 and 7.1 for now, so the extensions are not immediately broken
> >> for people using PHP 7.0.  But I have no idea how to express that using
> >> Ben file syntax as it has to be something like:
> >>
> >> is_bad = .depends ~ "phpapi-20151012" & ! .depends ~ "phpapi-20160303";
> > 
> > We can do that. Supporting 7.0 and 7.1 simultaneously for a little while 
> > sounds
> > like a good idea.
> 
> What's the status of this transition?
> 
> Cheers,
> Emilio

Re: Bug#882681: mariadb-10.1 fails to propagate to testing

[Ondřej Surý]

Anyway, whoever fixed the migration deserves huge thanks!

Ondrej
-- 
Ondřej Surý <ond...@sury.org>

On Sun, Nov 26, 2017, at 17:06, Adam D. Barratt wrote:
> On Sun, 2017-11-26 at 16:22 +0100, Andreas Metzler wrote:
> > mariadb-10.1 1:10.1.29-6 seems to be stuck in sid. It does not
> > propagate to testing although
> > https://qa.debian.org/excuses.php?package=mariadb-10.1 lists it as
> > valid candidate.
> > 
> > Could you please check the cause?
> 
> There's a bit of backstory, but effectively: the mariadb-test binary
> package in testing is built from the mariadb-10.1 source package, and
> has strictly versioned dependencies on other binaries built from that
> source package. In unstable, the mariadb-10.2 source package builds the
> binary package instead, but FTBFS on several architectures so is not a
> candidate. The net result is that when britney tries to migrate mariadb
> -10.1 1:10.1.29-6, the mariadb-test binary package in testing becomes
> uninstallable, and the migration attempt is aborted.
> 
> Regards,
> 
> Adam
> 

Re: Bug#880393: libsasl2-modules-gssapi-heimdal seems built against MIT

[Ondřej Surý]

Hi Johan,

you are the first one to notice :).

There was a time shortly before stable freeze when Heimdal team
requested removal of heimdal from Debian (#837724), but instead this
activity woke up the upstream, so they released new upstream version
(#849706). Somewhere in between something went awry and the full Heimdal
support wasn't properly reinstated into cyrus-sasl2.

I am not sure whether this could be fixed in Debian stable as things
might break with sudden change. Ccing debian-release for advice.

Ondrej
-- 
Ondřej Surý <ond...@sury.org>

On Tue, Oct 31, 2017, at 08:33, Johan Wassberg wrote:
> Package: libsasl2-modules-gssapi-heimdal
> Version: 2.1.27~101-g0780600+dfsg-3
> Severity: important
> 
> Dear Maintainer,
> 
> I think something is fishy with the package
> "libsasl2-modules-gssapi-heimdal".
> I suspect that the package is built against MIT instead of Heimdal.
> 
> Trying to migrate a Xenial machine to Stretch I noticed a difference in
> behavior when using `saslauthd` in a Postfix chroot - configs that
> haven't been required before was now required and `saslauthd` is
> complaing about settings that I have never seen with our previous setup.
> We
> have always used the Heimdal Kerberos libraries and therefore always
> used "libsasl2-modules-gssapi-heimdal" for `saslauthd`.
> 
> Couldn't find any upstream changes in either Heimdal or Cyrus SASL which
> would explain my issuses so I went digging in the Debian package
> instead.
> Found that Heimdal was ripped out from the package(s) in October 24
> 2016:
> * 004977091b89363daa04301e89a045e7e2ffbad8
> * b9158ab7d2bc71a026d417982fee61bc854935f4
> * b334c34bce70f20d85ef0e86e79c6310b69f7345
> And added again on Dec 31:
> * f382638d18a1e1e75560076d0cb1482e0b4dc613
> 
> Unfortunately the package(s) has moved a lot between removal and
> reinstatement
> so I can't get a clean diff over the changes. But I suspect that the
> reinstatement didn't go as planned.
> 
> From Jessie:
> ```
> # dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25
> libsasl2-modules-gssapi-heimdal:amd64:
> /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25
> 
> # ldd /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25
> linux-vdso.so.1 (0x7fffc877e000)
> libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3
> (0x7fd5b206a000)
> libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26
> (0x7fd5b1ddb000)
> libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8
> (0x7fd5b1b2b000)
> libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18
> (0x7fd5b1915000)
> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
> (0x7fd5b16de000)
> libcrypto.so.1.0.0 =>
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7fd5b12e1000)
> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
> (0x7fd5b10dd000)
> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
> (0x7fd5b0ec6000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd5b0b1a000)
> libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0
> (0x7fd5b0911000)
> libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4
> (0x7fd5b06dc000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7fd5b04be000)
> libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0
> (0x7fd5b0295000)
> libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1
> (0x7fd5b0086000)
> libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5
> (0x7fd5afe39000)
> libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
> (0x7fd5afb7)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x7fd5af96c000)
> /lib64/ld-linux-x86-64.so.2 (0x7fd5b24ba000)
> 
> # strings /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 | egrep
> "MIT|HEIM"
> HEIMDAL_GSS_2.0
> ```
> 
> From Ubuntu Xenial:
> ```
> # dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25
> libsasl2-modules-gssapi-heimdal:amd64:
> /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25
> 
> # ldd /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25
> linux-vdso.so.1 =>  (0x7ffd967d4000)
> libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3
> (0x7f818c61c000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f818c252000)
> libhei

Re: KSK-2017 SUAs

[Ondřej Surý]

Adam, thanks for writing these. The texts look good to me with (or even 
without) Robert's changes.



On 9 September 2017 20:19:13 Robert Edmonds  wrote:


Adam D. Barratt wrote:

Hi,

It's not clear whether there will have been a stretch point release
before the KSK rollover in October, but there definitely won't have
been a jessie point release, and in any case we need to update unbound
in the next couple of days (to avoid new installs on stretch having
broken DNSSEC validation for the next month).

Assuming I've not missed any packages that have been updated, we need
four SUAs. I've included draft text for each below - review, comments
and suggestions welcome.


Hi, Adam:

Thanks for writing these! The text mostly looks good to me. The only nit
I have is that I would write "The keys used to authenticate the root DNS
zone" instead of "The keys used to [sign] the root DNS zone[s]".
Technically, there is a chain of signatures and the KSKs do not directly
sign the root zone, and there is only a singular root zone.

--
Robert Edmonds
edmo...@debian.org

Bug#873479: Bug#873481: jessie-pu: package bind9/9.9.5.dfsg-9+deb8u13.1

[Ondřej Surý]

Version fixed and uploaded. Thanks a lot.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Thu, Sep 7, 2017, at 19:34, Adam D. Barratt wrote:
> Control: tags -1 - d-i
> 
> On Mon, 2017-08-28 at 12:08 +0200, Ondřej Surý wrote:
> > Hi Adam,
> > 
> > thanks for the quick response.
> > 
> > On Mon, Aug 28, 2017, at 11:44, Adam D. Barratt wrote:
> [...]
> > > +bind9 (1:9.9.5.dfsg-9+deb8u13.1) jessie; urgency=high
> > > 
> > > Upload numbers are simple integers - 1:9.9.5.dfsg-9+deb8u14,
> > > please.
> > 
> > Lol, I had deb8u14 in the first compilation run, but changed it and
> > recompiled it again :).
> > 
> 
> With the version corrected to deb8u14, please go ahead.
> 
> Regards,
> 
> Adam

Bug#873481: jessie-pu: package bind9/9.9.5.dfsg-9+deb8u13.1

[Ondřej Surý]

Hi release and d-i teams,

can we please push this forward please and fast track the via 
jessie-updates? Both Jessie and Stretch are needed as September 11 is 
really close.


Thanks,
O.


On 28 August 2017 12:08:39 Ondřej Surý <ond...@debian.org> wrote:


Hi Adam,

thanks for the quick response.

On Mon, Aug 28, 2017, at 11:44, Adam D. Barratt wrote:

Control: tags -1 + confirmed d-i

On Mon, 2017-08-28 at 11:03 +0200, Ondřej Surý wrote:
> this is the jessie counterpart of bind9 update to KSK-2017.
>
> No other change has been done to the package.

Nonetheless, the udeb means that we need a d-i ack.


Is there anything I need to do to help the process?


+bind9 (1:9.9.5.dfsg-9+deb8u13.1) jessie; urgency=high

Upload numbers are simple integers - 1:9.9.5.dfsg-9+deb8u14, please.


Lol, I had deb8u14 in the first compilation run, but changed it and
recompiled it again :).

Cheers,
--
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

Bug#873481: jessie-pu: package bind9/9.9.5.dfsg-9+deb8u13.1

[Ondřej Surý]

Hi Adam,

thanks for the quick response.

On Mon, Aug 28, 2017, at 11:44, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On Mon, 2017-08-28 at 11:03 +0200, Ondřej Surý wrote:
> > this is the jessie counterpart of bind9 update to KSK-2017.
> > 
> > No other change has been done to the package.
> 
> Nonetheless, the udeb means that we need a d-i ack.

Is there anything I need to do to help the process?

> +bind9 (1:9.9.5.dfsg-9+deb8u13.1) jessie; urgency=high
> 
> Upload numbers are simple integers - 1:9.9.5.dfsg-9+deb8u14, please.

Lol, I had deb8u14 in the first compilation run, but changed it and
recompiled it again :).

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

Bug#865093: stretch-pu: package mariadb-10.1/10.1.26-0+deb9u1

[Ondřej Surý]

Adam,

thank you very much. I really appreciate the review.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Fri, Aug 25, 2017, at 15:22, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> Control: retitle -1 stretch-pu: package mariadb-10.1/10.1.26-0+deb9u1
> 
> On 2017-08-24 12:02, Ondřej Surý wrote:
> > here's the updated debdiff and rest of the files as sent to the
> > security team.
> 
> This mail never mail it to debian-release (presumably due to the size of 
> the attachments), so I'm replying via a copy from the BTS mbox. For 
> future reference, we only need the debdiff, not the whole source 
> package.
> 
> Looking through the diff, I'm assuming the changes we're looking at are 
> (at most):
> 
> +  * Add cracklib-runtime to Build-Depends to fix FTBFS
> +  * Merge mytop script improvements from src:mytop package (Original
> +patches by Philipp Matthias Hahn, Werner Detter, Olaf van der Spek,
> +and Steffen Zieger) (Closes: #864762)
> +  * Add @SYSTEMD_EXECSTARTPOST@ replacement token to mariadb@.service, 
> so
> +the /var/run/mysqld directory is created even for multi-server 
> setup
> +(Closes: #865083)
> +
> +  [ Andreas Beckmann ]
> +  * Fix FTBFS on 32-bit mips*
> +
> +  [ James Cowgill ]
> +  * Update C11 atomics to have correct semantics (Closes: #864774)
> +  * Disable jemalloc on mips*. (Closes: #864340)
> ...
> +  * Run invoke-rc.d mysql maintscript snippets only when running under
> +sysvinit (Closes: #864593)
> ...
> +  * Explicitly add dh_systemd_start snippets to mariadb-server-10.1
> +because it's all messed up with different name for sysvinit 
> ('mysql')
> +and systemd ('mariadb') (Closes: #865870)
> 
> The mytop changes are a little noisy, but I don't particularly want to 
> disect them, so let's just assume it's all fine. :)
> 
> Please feel free to go ahead with a security upload containing the above 
> changes, subject to any final confirmation etc. from the Security Team. 
> Please close this bug once the DSA has been released.
> 
> Regards,
> 
> Adam

Bug#873061: stretch-pu: package dnsviz/0.6.4-1+deb9u1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

this is another package in series KSK-2017 RZ DNSKEY rollover.

I pulled couple of patches from upstream git in between 0.6.4..0.6.6
release and the other option might just be to update to 0.6.6, because
the only thing left is basically some cosmetic changes + python3
compatibility we don't use yet.

Anyway this update add following upstream patches:

0001-Check-for-invalid-ECDSA-key.patch

- Adds extra checks for invalid ECDSA keys

0002-Add-IPv6-address-for-G-root.patch
0007-Update-b-root-IPv6-address.patch
0008-Use-root-hints-for-IP-to-name-mapping-of-root.patch

- root.hints updates related to the recent changes in the IP addresses
  of root servers

0004-Use-correct-constant-name.patch

- bugfix for a contact name

0005-Remove-the-interface-from-link-local-addresses.patch

- Removes link-local addresses from the list

0006-Add-newline.patch

- Cosmetic for output

0009-Handle-root-KSK-rollover.patch
0010-Correct-trust-anchor-errors.patch

- This is the KSK-2017 related changes

Cheers,
Ondrej

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (quilt)
Source: dnsviz
Binary: dnsviz
Architecture: all
Version: 0.6.4-1+deb9u1
Maintainer: Debian DNS Maintainers <pkg-dns-de...@lists.alioth.debian.org>
Uploaders: Robert Edmonds <edmo...@debian.org>, Ondřej Surý <ond...@debian.org>
Homepage: https://github.com/dnsviz/dnsviz
Standards-Version: 3.9.8
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-dns/dnsviz.git/
Vcs-Git: git://anonscm.debian.org/pkg-dns/dnsviz.git
Build-Depends: debhelper (>= 9~), dh-python, inkscape, python (>= 2.7~), 
python-dnspython (>= 1.11.0~), python-m2crypto (>= 0.24.0~), python-pygraphviz 
(>= 1.1~)
Package-List:
 dnsviz deb net optional arch=all
Checksums-Sha1:
 ef64d0ba7afd4062edd64a9ec4f79c5a91543815 233769 dnsviz_0.6.4.orig.tar.gz
 caf5f1fc86465b73c51f07a5f56e44c5cc1824dd 12976 
dnsviz_0.6.4-1+deb9u1.debian.tar.gz
Checksums-Sha256:
 900a81e94908405697753c1b714995985b366df9a45c9068f7864274d7821176 233769 
dnsviz_0.6.4.orig.tar.gz
 dfa1c6a7bdccc5d929c77a5cbd76d2a0f28aae49cc3648c9755ce405ca5df08a 12976 
dnsviz_0.6.4-1+deb9u1.debian.tar.gz
Files:
 317c3ca1396fa0d6c75c5a22725f53ce 233769 dnsviz_0.6.4.orig.tar.gz
 3aaa2caab3bd220a52dbfcf0dd608cad 12976 dnsviz_0.6.4-1+deb9u1.debian.tar.gz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlmef4hfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwfpnhAA2icQLzIxXEbXWNdcU11O9dIktey9eM6ERu8o4AcLttv1LDWHKEWyZ4/B
RsP9+flUcKv0zCueriJMaqfZduYPvT4XjaO1TVOtHt6jAvDfPyMV7zhIdIX3gu2W
l/DJyKLqXai8pOwRXbcvDsEUOeA1uH6/5kFkKV/ogWv1SlKa4t+H47yad02bguqH
E7LFPQI4q6/nBDmXk+3p9Owqk8+cy/qKqvIDUdkYI/SpoVO8bNG1stZJkU+6l/sN
TYqjBrAtkvpZ6y/q8sH+hdc46HGXnzG2Sk3iBQYPZFLK+nJzh3HI2VoRx13lcNQY
cH6aC/q/II8xudSEdPSNeWHhJt5QiXJlO3ean7QuTukwNQBDdnvm5w+Y5UlGPBfS
USTD2NSlbR1hlflfvowiv6knFVfrrl1CGvosyYBw5wKtm85QZjjKK0kOJKcC2Rwq
xuzXCHaDiiEdLX1iYV1V0wezI8Ip9QxEtcv+hjjTfM6F6lnjBauPoLQhwdXF3uVn
I2O2Zxj9vTbyGv5JjvokjZIui/UJ3hdwmX5ZghNz12SAM6bRGJ6L/RbvjxEEcUj9
9NtypfBgr9NEs4MfrKYV3oxNq1kTfUDFZ3g+p1qeL9jpii3EDVgdSovbr599iZER
Z4v+kVMrjLmroUFpSbMMY9c6pYNOj5BaL/Sro2tIefhuoO1rerQ=
=c9ZU
-END PGP SIGNATURE-


dnsviz_0.6.4-1+deb9u1.debian.tar.gz
Description: application/gzip
diff -Nru dnsviz-0.6.4/debian/changelog dnsviz-0.6.4/debian/changelog
--- dnsviz-0.6.4/debian/changelog   2016-11-01 15:19:12.0 +0100
+++ dnsviz-0.6.4/debian/changelog   2017-08-24 08:32:18.0 +0200
@@ -1,3 +1,10 @@
+dnsviz (0.6.4-1+deb9u1) stretch-updates; urgency=medium
+
+  * Cherry-pick upstream fixes related to root.hints and root.keys changes
+  * Update gbp.conf for debian/stretch branch
+
+ -- Ondřej Surý <ond...@debian.org>  Thu, 24 Aug 2017 08:32:18 +0200
+
 dnsviz (0.6.4-1) unstable; urgency=medium
 
   * Imported upstream version 0.6.4
diff -Nru dnsviz-0.6.4/debian/gbp.conf dnsviz-0.6.4/debian/gbp.conf
--- dnsviz-0.6.4/debian/gbp.conf2016-11-01 15:19:12.0 +0100
+++ dnsviz-0.6.4/debian/gbp.conf2017-08-24 08:32:18.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/sid
+debian-branch = debian/stretch
 
 [buildpackage]
 pristine-tar = True
diff -Nru dnsviz-0.6.4/debian/patches/0001-Check-for-invalid-ECDSA-key.patch 
dnsviz-0.6.4/debian/patches/0001-Check-for-invalid-ECDSA-ke

Bug#873053: stretch-pu: package dns-root-data/2017072601~deb9u1

[Ondřej Surý]

Package: release.debian.org
Tags: jessie
Followup-For: Bug #873053
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I forgot to attach debdiff and rest, so here it is.

Cheers,
Ondrej

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (native)
Source: dns-root-data
Binary: dns-root-data
Architecture: all
Version: 2017072601~deb8u1
Maintainer: Ondřej Surý <ond...@debian.org>
Uploaders: Robert Edmonds <edmo...@debian.org>
Homepage: https://data.iana.org/root-anchors/
Standards-Version: 3.9.5
Build-Depends: debhelper (>= 8.0.0), unbound-anchor, openssl, gnupg2, 
bind9utils, libxml2-utils
Package-List:
 dns-root-data deb misc optional arch=all
Checksums-Sha1:
 c8b6700a229c67c1187005c44bd5f966030c70ec 31064 
dns-root-data_2017072601~deb8u1.tar.xz
Checksums-Sha256:
 1ae53580769f181f0022a3044c3ee691f96bb37d99d706ae9ac25e263fc8dc06 31064 
dns-root-data_2017072601~deb8u1.tar.xz
Files:
 e0be2af69321592ca519e531cf84e7be 31064 dns-root-data_2017072601~deb8u1.tar.xz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlmeeHhfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwc7CQ/+PLjJ6bcKlUNNls7WPd23bgV5yxbQ2ddQxpUAVWCDWnUHO9QH9DWkskeN
Ag7q2RqobobkNQEzJTWD9bKbfxG0fFKCGfIAt9q+d1fP0q2mBL/aAhbYe2pAG+dq
P+xDV76X+eeeFYpB0z0gVnXt476R9h2a4LCNOINyUepSnex3Mr3fuJZNP4sPgVeQ
kBNvirBMpgLsKuwTGu9KUwrWp1k/oKv2pQbYTWT5ivugkPUpmdGyrYxSXWTmSmYt
pvUHQRsAn4f+HfiK2D10j51PylMMs/7KKCIOiatG4tyUD4WVWre24VIYTCBmp/NG
7CPjVL1m9MsyuggDJBqe42/d9TgRPCxguR46ER/FA1w+JRrT8dMsdK73hOAw/u76
nMyk1r8ElpszgEFWYV/94a3gqOs7n9o8w7FYWdjUCptfXWOdejvusdvKjSlefaLo
QOIDuZNznOLPzgA1ZZFqOf3Cci4Qq9MpTxUoRTfdXZXT1zu1AaXhxDTIIdPf0lxS
DyeyRdSv151yAuGHPantt3fedzOYc9nlAms2fxT6pq2b16i3Yr4nqUdjRNWdDcMR
efmAuWNlgzcj0QQe0tFd6iwueMsQ+Tvi0C1N7mIQHQs+Q+aJedJORxkGB0Jf0ajo
RTw55Wod5E5IFpVto5HMcVcszetYJP0HhKC7CrVFGJ9xhWuF7RA=
=Jo9S
-END PGP SIGNATURE-


dns-root-data_2017072601~deb8u1.tar.xz
Description: application/xz
diff -Nru dns-root-data-2014060201+2/debian/changelog 
dns-root-data-2017072601~deb8u1/debian/changelog
--- dns-root-data-2014060201+2/debian/changelog 2014-09-04 13:12:53.0 
+0200
+++ dns-root-data-2017072601~deb8u1/debian/changelog2017-08-23 
09:09:51.0 +0200
@@ -1,3 +1,11 @@
+dns-root-data (2017072601~deb8u1) jessie-updates; urgency=high
+
+  * Add KSK-2017 to root.key file
+  * Update root.hints to 2017072601 version
+  * Add gbp.conf for master-jessie branch
+
+ -- Ondřej Surý <ond...@debian.org>  Wed, 23 Aug 2017 09:09:51 +0200
+
 dns-root-data (2014060201+2) unstable; urgency=medium
 
   * Use full path for dnssec-dsfromkey (Closes: #760103)
diff -Nru dns-root-data-2014060201+2/debian/gbp.conf 
dns-root-data-2017072601~deb8u1/debian/gbp.conf
--- dns-root-data-2014060201+2/debian/gbp.conf  1970-01-01 01:00:00.0 
+0100
+++ dns-root-data-2017072601~deb8u1/debian/gbp.conf 2017-08-23 
09:09:51.0 +0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = master-jessie
diff -Nru dns-root-data-2014060201+2/root.hints 
dns-root-data-2017072601~deb8u1/root.hints
--- dns-root-data-2014060201+2/root.hints   2014-09-04 13:12:53.0 
+0200
+++ dns-root-data-2017072601~deb8u1/root.hints  2017-08-23 09:09:51.0 
+0200
@@ -1,90 +1,92 @@
-;   This file holds the information on root name servers needed to
+;   This file holds the information on root name servers needed to 
 ;   initialize cache of Internet domain name servers
 ;   (e.g. reference this file in the "cache  .  "
-;   configuration file of BIND domain name servers).
-;
+;   configuration file of BIND domain name servers). 
+; 
 ;   This file is made available by InterNIC 
 ;   under anonymous FTP as
-;   file/domain/named.cache
+;   file/domain/named.cache 
 ;   on server   FTP.INTERNIC.NET
 ;   -OR-RS.INTERNIC.NET
+; 
+;   last update: July 26, 2017 
+;   related version of root zone: 2017072601
+; 
+; FORMERLY NS.INTERNIC.NET 
 ;
-;   last update:June 2, 2014
-;   related version of root zone:   2014060201
-;
-; formerly NS.INTERNIC.NET
-;
-.360  IN  NSA.ROOT-SERVERS.NET.
+.360  NSA.ROOT-SERVERS.NET.
 A.ROOT-SERVERS.NET.  360  A 198.41.0.4
-A.ROOT-SERVERS.NET.  360    2001:503:BA3E::

Bug#873054: jessie-pu: package dns-root-data/2017072601~deb8u1

[Ondřej Surý]

Package: release.debian.org
Tags: stretch
Followup-For: Bug #873054
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I forgot to attach the debdiff and rest.  So here it is.

Cheers,
Ondrej

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (native)
Source: dns-root-data
Binary: dns-root-data
Architecture: all
Version: 2017072601~deb9u1
Maintainer: Debian DNS Maintainers <pkg-dns-de...@lists.alioth.debian.org>
Uploaders: Ondřej Surý <ond...@debian.org>, Robert Edmonds <edmo...@debian.org>
Homepage: https://data.iana.org/root-anchors/
Standards-Version: 3.9.6
Vcs-Browser: http://git.debian.org/?p=pkg-dns/dns-root-data.git;a=summary
Vcs-Git: git://git.debian.org/pkg-dns/dns-root-data.git
Build-Depends: debhelper (>= 8.0.0), unbound-anchor, openssl, ldnsutils, xml2
Package-List:
 dns-root-data deb misc optional arch=all
Checksums-Sha1:
 3311d724fe223d50ad34f6107d944212c2692ad5 14448 
dns-root-data_2017072601~deb9u1.tar.xz
Checksums-Sha256:
 43b7148030ef0b9d8fa72f2f2d06800b84ea3e89c7cc640b0544a20e15dd4f58 14448 
dns-root-data_2017072601~deb9u1.tar.xz
Files:
 7445edd0a28807f27c9437ea746b4272 14448 dns-root-data_2017072601~deb9u1.tar.xz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlmed6VfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwd1fQ/9Fal8meiW34morZkgU571//X7TWPn8yq1RqJWqH+MancIVhIqy/9BzTAn
Iq45u5+WDTjEX6fAb1A3yiAZLDxklEWobHgBdFCTu3dcLE1aloMYDvSDZFv57w7G
o5/Q4ykjXAqx/wxSemUIdPuwGl5ywJrXG8EiwDxhu+G7ASKaAF3wA6Najgqn4xRS
PeNWC6+fToS4rsWOVUhqYjtsfj53dqJtebyiTzUyUbaZJoIItlGIcwnHIyfr3lrh
FlZyKIa7BY5lyHf3wYJkaxHJKM0+aOImcxynq9iogaa9d/5GIF5Hqp612NYTlp0p
zPHKKaFUDT1NfZb/mNSUByQ90NtJ9XcCe4ptKuJPrdSewvvePOGx7Y50dsGD8DNV
6tXt1ocf4H34J1cT0r33tO+As60PPh/YZODlIMwDU/O53BfyPzwkfi6ZRfy8baHj
8zGz8h9CA2MVbotv07zF2dd6UTx1Ven/gHKQaruIaDoiC9srvzWdSLVx2COzljdR
vS1CmT+U7m3izH/5jgTpBgR2/fSxil0EuexUizbNNLfAaTKETlFcjBMo2yRXp8DV
rbJf09IEfJGgdIQAL5mq2XUMDcyUkpcweJgQCsq7K2bWCY1YJ9bLvesjwJEhK26H
dhqdwP2NcpjQ5K7kovpXnZterbGMI8PBemmf5IK/U3WSe2veL/E=
=yRTH
-END PGP SIGNATURE-
diff -Nru dns-root-data-2017041102/debian/changelog 
dns-root-data-2017072601~deb9u1/debian/changelog
--- dns-root-data-2017041102/debian/changelog   2017-06-06 12:54:28.0 
+0200
+++ dns-root-data-2017072601~deb9u1/debian/changelog2017-08-23 
09:37:36.0 +0200
@@ -1,3 +1,11 @@
+dns-root-data (2017072601~deb9u1) stretch-updates; urgency=high
+
+  * Update root.hints to 2017072601 version
+  * Add gbp.conf for master-stretch branch
+  * Change the state of KSK-2017 to VALID
+
+ -- Ondřej Surý <ond...@debian.org>  Wed, 23 Aug 2017 09:37:36 +0200
+
 dns-root-data (2017041102) unstable; urgency=high
 
   [ Robert Edmonds ]
diff -Nru dns-root-data-2017041102/debian/gbp.conf 
dns-root-data-2017072601~deb9u1/debian/gbp.conf
--- dns-root-data-2017041102/debian/gbp.conf1970-01-01 01:00:00.0 
+0100
+++ dns-root-data-2017072601~deb9u1/debian/gbp.conf 2017-08-23 
09:37:36.0 +0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = master-stretch
diff -Nru dns-root-data-2017041102/root.hints 
dns-root-data-2017072601~deb9u1/root.hints
--- dns-root-data-2017041102/root.hints 2017-06-06 12:54:28.0 +0200
+++ dns-root-data-2017072601~deb9u1/root.hints  2017-08-23 09:37:36.0 
+0200
@@ -1,92 +1,92 @@
-;   This file holds the information on root name servers needed to
+;   This file holds the information on root name servers needed to 
 ;   initialize cache of Internet domain name servers
 ;   (e.g. reference this file in the "cache  .  "
-;   configuration file of BIND domain name servers).
-;
+;   configuration file of BIND domain name servers). 
+; 
 ;   This file is made available by InterNIC 
 ;   under anonymous FTP as
-;   file/domain/named.cache
+;   file/domain/named.cache 
 ;   on server   FTP.INTERNIC.NET
 ;   -OR-RS.INTERNIC.NET
-;
-;   last update:April 11, 2017
-;   related version of root zone:   2017041101
-;
-; formerly NS.INTERNIC.NET
+; 
+;   last update: July 26, 2017 
+;   related version of root zone: 2017072601
+; 
+; FORMERLY NS.INTERNIC.NET 
 ;
 .360  NSA.ROOT-SERVERS.NET.
 A.ROOT-SERVERS.NET.  360  A 198.41.0.4
 A.ROOT-SERVERS.NET.  360    2

Bug#873054: jessie-pu: package dns-root-data/2017072601~deb8u1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

this is the dns-root-data update for DNSSEC Root Zone KSK-2017 (key tag
20326), that's needed for the packages that rely on dns-root-data for
bootstrapping DNSSEC Trust Anchors.

The root.hints has been updated to 2017072601 which should be update
as well.  I don't think the /usr/share/dns/root.hints is used anywhere
in Debian, so it should be safe update.

There will be another update after the former KSK has been removed from
trust anchors (around January 2018 or maybe even earlier when the former
KSK is removed from the RZ).

It was suggested in a discussion with a security team that this should
fasttrack via jessie-updates.

Cheers,
Ondrej

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#873053: stretch-pu: package dns-root-data/2017072601~deb9u1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

this is the dns-root-data update for DNSSEC Root Zone KSK-2017 (key tag
20326), that's needed for the packages that rely on dns-root-data for
bootstrapping DNSSEC Trust Anchors.

The root.hints has been updated to 2017072601 which should be update
as well.  I don't think the /usr/share/dns/root.hints is used anywhere
in Debian, so it should be safe update.

There will be another update after the former KSK has been removed from
trust anchors (around January 2018 or maybe even earlier when the former
KSK is removed from the RZ).

It was suggested in a discussion with a security team that this should
fasttrack via stretch-updates.

Cheers,
Ondrej

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#865093: stretch-pu: package mariadb-10.1/10.1.25-0+deb9u1

[Ondřej Surý]

Package: release.debian.org
Tags: stretch
Followup-For: Bug #865093
User: release.debian@packages.debian.org
Usertags: pu

Hi,

there has been another upstream release 10.1.26, so I am updating the
issue here.

I have also pulled one more fix.  While fixing the #864593 I have
introduced regression that prevented mysqld to be started when used
with systemd (tracked as #865870).  This has now been fixed and the
patch is attached to this message.

I would really appreciate if somebody could push this a little bit
forward as there's a security update pending depending on this.

Cheers,
Ondrej

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 9f49e4b494f3dad8c403972996f7a1ebceb4b34f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?= 
Date: Sat, 29 Jul 2017 22:20:28 +0200
Subject: [PATCH] Explicitly add dh_systemd_start snippets to
 mariadb-server-10.1 because it's all messed up with different name for
 sysvinit ('mysql') and systemd ('mariadb') (Closes: #865870)

---
 debian/mariadb-server-10.1.postinst | 8 ++--
 debian/mariadb-server-10.1.postrm   | 5 +
 debian/mariadb-server-10.1.prerm| 5 -
 debian/rules| 5 -
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/debian/mariadb-server-10.1.postinst 
b/debian/mariadb-server-10.1.postinst
index 7edb0f3a..43eed58e 100644
--- a/debian/mariadb-server-10.1.postinst
+++ b/debian/mariadb-server-10.1.postinst
@@ -167,9 +167,13 @@ fi
 
 #DEBHELPER#
 
+# Modified dh_systemd_start snippet that's not added automatically due 
/etc/init.d/mysql
+if [ -d /run/systemd/system ]; then
+   systemctl --system daemon-reload >/dev/null || true
+   deb-systemd-invoke start mariadb.service >/dev/null || true
 # Modified dh_installinit snippet to only run with sysvinit
-if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
-   if [ ! -e /run/systemd/system ] && [ -x "/etc/init.d/mysql" ]; then
+elif [ -x "/etc/init.d/mysql" ]; then
+   if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
invoke-rc.d mysql start || exit $?
fi
 fi
diff --git a/debian/mariadb-server-10.1.postrm 
b/debian/mariadb-server-10.1.postrm
index 81072b3c..3c822d39 100644
--- a/debian/mariadb-server-10.1.postrm
+++ b/debian/mariadb-server-10.1.postrm
@@ -47,4 +47,9 @@ if [ "$1" = "purge" ] && [ -f 
"/var/lib/mysql/debian-10.1.flag" ]; then
 
 fi
 
+# Modified dh_systemd_start snippet that's not added automatically due 
/etc/init.d/mysql
+if [ -d /run/systemd/system ]; then
+   systemctl --system daemon-reload >/dev/null || true
+fi
+
 exit 0
diff --git a/debian/mariadb-server-10.1.prerm b/debian/mariadb-server-10.1.prerm
index 8a96c186..23eb7d43 100644
--- a/debian/mariadb-server-10.1.prerm
+++ b/debian/mariadb-server-10.1.prerm
@@ -3,8 +3,11 @@ set -e
 
 #DEBHELPER#
 
+# Modified dh_systemd_start snippet that's not added automatically due 
/etc/init.d/mysql
+if [ -d /run/systemd/system ]; then
+   deb-systemd-invoke stop mariadb.service >/dev/null
 # Modified dh_installinit snippet to only run with sysvinit
-if [ ! -e /run/systemd/system ] && [ -x "/etc/init.d/mysql" ]; then
+elif [ -x "/etc/init.d/mysql" ]; then
invoke-rc.d mysql stop || exit $?
 fi
 
diff --git a/debian/rules b/debian/rules
index ef026c8b..5bce6ca7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -137,11 +137,14 @@ override_dh_systemd_enable:
dh_systemd_enable --name=mariadb
dh_systemd_enable --no-enable --name=mariadb@
 
+# Disable dh_systemd_start due /etc/init.d/mysql messing with the automatic 
snippets
+override_dh_systemd_start:
+   :
+
 # Start mysql at sequence number 19 before 20 where apache, proftpd etc gets
 # started which might depend on a running database server.
 override_dh_installinit-arch:
dh_installinit --name=mysql --no-start -- defaults 19 21
-   dh_systemd_start --no-restart-after-upgrade
 
 override_dh_installcron-arch:
dh_installcron --name mysql-server
-- 
2.11.0

Bug#872998: transition: PHP 7.0 to 7.1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

this is request for PHP 7.0 to PHP 7.1 transition.  In fact, I could
make this a "soft" transition and build the PECL extensions for both
PHP 7.0 and 7.1 for now, so the extensions are not immediately broken
for people using PHP 7.0.  But I have no idea how to express that using
Ben file syntax as it has to be something like:

is_bad = .depends ~ "phpapi-20151012" & ! .depends ~ "phpapi-20160303";

Thanks,
Ondrej

Ben file:

title = "php7.1";
is_affected = .depends ~ "phpapi-20151012" | .depends ~ "phpapi-20160303";
is_good = .depends ~ "phpapi-20160303";
is_bad = .depends ~ "phpapi-20151012";


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (800, 'unstable'), (500, 'unstable-debug'), 
(500, 'stable-debug'), (500, 'proposed-updates'), (1, 'experimental-debug'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#865093: [debian-mysql] stretch-pu review: package mariadb-10.1/10.1.24-0+deb9u1

[Ondřej Surý]

I have mariadb-10.1.25 in queue, but I am busy with IETF this week. I'll 
have some time on Wednesday, so I'll update this release bug during this 
week to newest upstream.


Ondřej


On 18 July 2017 09:12:12 Otto Kekäläinen  wrote:


2017-07-15 0:56 GMT+03:00 Ian Jackson :
...

of the package.  To clarify: the proposal is to upgrade from
10.1_10.1.23-9+deb9u1 to this 10.1.24-0+deb9u1.

I wasn't able to find the upstream changelog in the source package.
Admittedly I didn't look very hard - I eyeballed the source package.
There doesn't seem to be any discussion from the proponent to explain
what the upstream changes are and why (or whether) they are desirable.


https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.1.git/tree/debian/changelog

  * New upstream version 10.1.24, includes fixes for the following
high-priority regression fixes:
+ MDEV-11842: Fail to insert on a table where a field has no default
+ MDEV-12075: innodb_use_fallocate does not work in MariaDB
  Server 10.1.21

Ondrej can chip in himself on the priority of those items.

I don't know more, but I can reply on a generic level that MariaDB
release notes (summary) and full release notes can be found here:

https://mariadb.com/kb/en/mariadb/mariadb-10124-release-notes/
https://mariadb.com/kb/en/mariadb/mariadb-10124-changelog/

CVEs are listed here: https://mariadb.com/kb/en/mariadb/security/
Currently no known CVEs apply for 10.1.24 or 10.1.25, but quite often
it turns out afterwards that releases also fixed security issues.

Traditionally both MySQL and MariaDB have had their stable micro
releases go into stable updates of both Debian and Ubuntu. If these
upstreams decide it makes sense to make a stable micro release, then
usually it also makes sense for distros to ship them either via
security updates or via pu releases.

Bug#864283: unblock: dns-root-data/2017041102

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dns-root-data

Dear release team,

Robert Edmonds has prepared patch to fix the regression caused by
dns-root-data package in dnsmasq, so the root.ds format can now be
parsed by both dnsmasq in testing and in unstable.

Thanks goes to Robert to thinking better than me and preparing the
fix.

unblock dns-root-data/2017041102

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.4.0-67-generic (SMP w/24 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (native)
Source: dns-root-data
Binary: dns-root-data
Architecture: all
Version: 2017041102
Maintainer: Debian DNS Maintainers <pkg-dns-de...@lists.alioth.debian.org>
Uploaders: Ondřej Surý <ond...@debian.org>, Robert Edmonds <edmo...@debian.org>
Homepage: https://data.iana.org/root-anchors/
Standards-Version: 3.9.6
Vcs-Browser: http://git.debian.org/?p=pkg-dns/dns-root-data.git;a=summary
Vcs-Git: git://git.debian.org/pkg-dns/dns-root-data.git
Build-Depends: debhelper (>= 8.0.0), unbound-anchor, openssl, ldnsutils, xml2
Package-List:
 dns-root-data deb misc optional arch=all
Checksums-Sha1:
 141238e10aa94d20751b91f4d5362f6565e1ab30 14364 dns-root-data_2017041102.tar.xz
Checksums-Sha256:
 5c8d8a434e957a8c3b9e8e4ad92575157fa200a592201abb466a55d031973f55 14364 
dns-root-data_2017041102.tar.xz
Files:
 22198cdf516f1ff5ed9b3dbfa61b7c8a 14364 dns-root-data_2017041102.tar.xz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlk2i1lfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwePqRAAsMHGZi69ceLc1vzl+EpnnH8CAcWMhyDMGycAZo7eu4B8WwjRxB5XdLco
GB1nnHtCURoDYxnK49gU47nM1kjrE63irv4fnNYcfi7q+qG+Y6c93n5X6+7/cXqO
MH/I4eTifeSTWzRfvWV2IT+bZ9rkmVL+4pTwoP+X8Qo1x8WqwQVagxGjezpKkD/c
ztjHTQ/x7dgZm/cjRTgKstkDcIWxDNora2d1soAI9QLsQQmEUYxcIdL1blB+Aw28
CWL7MtkmdbglmA2k3mn5+Hxv9Sqh+WEawVoag01h9Vct/V1lzk7v+6j2tsuVsm4q
0ahlacmx+KNuwzalFE/lc3mtjmGY0Tfjvlls2sVwVtZi6eeemcBLqL03kxQ8pdZC
QQ2s+B/X/w1RvRZiR7moGrRmo3XUEltd6BX/lKhAnBRCHzaz+6ooIrXPcFcgM2qK
ER+eul7wBGj6W4TfqQimLTHkPEx5ANIGUftHL5bCR3T77O1FAgcTxRu4M1FeYJvp
hCaOnsE1Ld5DJ+o8IIBQ04y+CxkDzUfJWShoYnSE/UVkYUql85zxuCn/H0TlPU8a
z3RKt/jWQ1gt4/CBtXZn+KZNPJvMAZq6xzq0o4gJt7g1V8yrA2XKzDHxZU8jtvfY
6DCEcCNoj/C78dy2ZBx/0d+rsIH83UiqWN4GBfpmT3BfmI0f11g=
=hQRg
-END PGP SIGNATURE-
diff -Nru dns-root-data-2017041101/debian/changelog 
dns-root-data-2017041102/debian/changelog
--- dns-root-data-2017041101/debian/changelog   2017-05-29 14:05:37.0 
+0200
+++ dns-root-data-2017041102/debian/changelog   2017-06-06 12:54:28.0 
+0200
@@ -1,3 +1,11 @@
+dns-root-data (2017041102) unstable; urgency=high
+
+  [ Robert Edmonds ]
+  * Change DS creation to omit TTL and use spaces instead of tabs
+(Closes: #864016)
+
+ -- Ondřej Surý <ond...@debian.org>  Tue, 06 Jun 2017 12:54:28 +0200
+
 dns-root-data (2017041101) unstable; urgency=medium
 
   * Fix parse-root-anchors.sh in non-dash shells (Closes: #862252)
diff -Nru dns-root-data-2017041101/debian/rules 
dns-root-data-2017041102/debian/rules
--- dns-root-data-2017041101/debian/rules   2017-05-29 14:05:37.0 
+0200
+++ dns-root-data-2017041102/debian/rules   2017-06-06 12:54:28.0 
+0200
@@ -18,7 +18,7 @@
./parse-root-anchors.sh < root-anchors.xml > root-anchors.ds
 
# Create key from downloaded root.key
-   /usr/bin/ldns-key2ds -n -2 root.key > root.ds
+   /usr/bin/ldns-key2ds -n -2 root.key | sed -e 's/\t/ /g' -e 's/ 
172800//' > root.ds
 
# Compare the DS from root.key and from root-anchors.xml
diff root-anchors.ds root.ds
diff -Nru dns-root-data-2017041101/parse-root-anchors.sh 
dns-root-data-2017041102/parse-root-anchors.sh
--- dns-root-data-2017041101/parse-root-anchors.sh  2017-05-29 
14:05:37.0 +0200
+++ dns-root-data-2017041102/parse-root-anchors.sh  2017-06-06 
12:54:28.0 +0200
@@ -2,8 +2,6 @@
 
 unset ZONE KTAG ALGO DTYPE DIGEST
 
-TTL=172800
-
 export IFS="="
 xml2 | while read -r KEY VAL; do
 case "$KEY" in
@@ -17,7 +15,7 @@
echo "Missing some KeyDigest parameter"
exit 1
fi
-   printf "%s\t%s\tIN\tDS\t%s %s %s %s\n" "$ZONE" "$TTL" "$KTAG" 
"$ALGO" "$DTYPE" "$DIGEST"
+   printf "%s IN DS %s %s %s %s\n" "$ZONE" "$KTAG" "$ALGO" "$DTYPE&quo

Bug#864085: unblock: dnsmasq/2.76-5

[Ondřej Surý]

> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=44eb875a5ab2e3b862a6b2bc9fbbb919475d2107

Oh, and I would strongly recommend using [[:space:]] instead of [\t ] in
the sed expression, something like this:


Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

Bug#864085: unblock: dnsmasq/2.76-5

[Ondřej Surý]

Simon,

please let me know what would be the fixed version number and I'll issue
an update to dns-root-data to have "Breaks: dnsmasq (<<
)".

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Sun, Jun 4, 2017, at 19:54, Simon Kelley wrote:
> 
> 
> On 04/06/17 16:36, Jonathan Wiltshire wrote:
> > Control: tag -1 moreinfo
> > 
> > On Sun, Jun 04, 2017 at 09:58:44AM +0100, ? wrote:
> >> The dnsmasq package in testing has a serious problem when dns-root-data is
> >> installed, due to changes in the format of the dns-root-data files.
> >> The effect is to render dnsmasq unusable.
> > 
> > Bother.
> > 
> >> There are several serious bugs filed to this effect, but they should
> >> really be release-critical, eg 863896
> >>
> >> There are also several bugs in the DNSSEC validation code, which are fixed
> >> upstream, and really should be in stretch.
> >>
> >> Therefore, if we can get dnsmasq-2.77-1, currently in unstable, into 
> >> Stretch,
> >> that would be a Good Thing. If not, it will need a point release.
> > 
> > The delta from testing to unstable right now is not really suitable this
> > late in the process. I would prefer a targetted fix through t-p-u.
> 
> I understand.
> 
> > 
> > However, I wonder if that format change in dns-root-data risks problems in
> > other packages. Ondřej, is there any advantage to reverting that (keeping
> > the RC fix for parse-root-anchors.sh)?
> > 
> 
> The patch to fix this in dnsmasq is at :
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=44eb875a5ab2e3b862a6b2bc9fbbb919475d2107
> 
> (that regexp handles both old and new formats.)
> 
> Cheers,
> 
> Simon.
> 
> 

Bug#864085: unblock: dnsmasq/2.76-5

[Ondřej Surý]

Hi Jonathan,

On Sun, Jun 4, 2017, at 17:36, Jonathan Wiltshire wrote:
> However, I wonder if that format change in dns-root-data risks problems
> in other packages. Ondřej, is there any advantage to reverting that (keeping
> the RC fix for parse-root-anchors.sh)?

Unfortunately not. The Root Zone KSK Rollover is going to happen this
summer and reverting this would only postpone the problem.

And we will need the same update to happen in jessie (+ update for every
package not using dns-root-data), so the one thing I can do is to test
all reverse (Build-)Depends in jessie and stretch to make sure nothing
else obvious breaks.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

Bug#863626: unblock: dns-root-data/2017041101

[Ondřej Surý]

Hi Jonathan,

my mistake. Somehow I thought the 2017020200 has been already unblocked
for testing.

I did the 2017041101 build and unblock bug in parallel, and I have just
uploaded the package to unstable.

So for the 2015052300+h+1 -> 2017020200 changes:

* This fixes FTBFS because:
  a) ICANN/IANA doesn't provide OpenPGP signatures anymore
  b) The parsing was broken with introduction of second key

This includes changes in d/rules + new parse-root-anchors.sh script.

* Several dead-upstream ICANN files were removed from the package:
 - draft-icann-dnssec-trust-anchor.html
 - draft-icann-dnssec-trust-anchor.txt
 - icannbundle.p12
 - icann.pgp
 - root-anchors.p7s

(e.g. in fact it was a removal of ICANN-copyright document)

The licensing on ICANN files was acked by ftp-masters as OK.

$ diffstat dns-root-data_2017020200.debdiff

 /home/ondrej/tmp/wrtzCZn7bu/dns-root-data-2017020200/icann.pgp   
 |binary
 /home/ondrej/tmp/wrtzCZn7bu/dns-root-data-2017020200/icannbundle.p12 
 |binary
 /home/ondrej/tmp/wrtzCZn7bu/dns-root-data-2017020200/root-anchors.p7s
 |binary
 dns-root-data-2017020200/debian/changelog |
   14 
 dns-root-data-2017020200/debian/control   |
5 
 dns-root-data-2017020200/debian/dns-root-data.docs|
2 
 dns-root-data-2017020200/debian/rules |
   18 
 dns-root-data-2017020200/draft-icann-dnssec-trust-anchor.html |
  555 -
 dns-root-data-2017020200/draft-icann-dnssec-trust-anchor.txt  |
  560 --
 dns-root-data-2017020200/icannbundle.pem  |
  200 +--
 dns-root-data-2017020200/parse-root-anchors.sh|
   25 
 dns-root-data-2017020200/root-anchors.asc |
7 
 dns-root-data-2017020200/root-anchors.xml |
8 
 dns-root-data-2017020200/root.hints   |
8 
 dns-root-data-2017020200/root.key |
3 
 15 files changed, 117 insertions(+), 1288 deletions(-)

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver

On Mon, May 29, 2017, at 14:47, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Mon, May 29, 2017 at 02:17:30PM +0200, Ondřej Surý wrote:
> > the 2017041101 update of dns-root-data package contains:
> > 
> > - fixes to parse_root_data.sh script to unfail the non-dash
> >   shells - closes RC bug #862252 (use printf instead of echo command)
> > - update root.hints to 2017041101 version (no other change then version 
> > though)
> > - update root.key and d/rules to strip any timestamp, so the build is
> >   more or less reproducible (the get_orig_source still depends on
> >   upstream data at the time of the build, but it should be more
> >   reliable)
> > - little fixes to parse_root_data.sh script, as suggested by shellcheck:
> >   + use read -r instead of read on xml2 output data
> >   + use [:upper:]/[:lower:] instead of [A-Z]/[a-z] as tr argument
> >   + use [ a ] || [ b ] syntax instead of [ a -o b ]
> 
> This does not seem to reflect unstable right now; you have:
> 
> dns-root-data | 2015052300+h+1 | testing | source, all
> dns-root-data | 2017020200 | unstable| source, all
> 
> The delta therefore includes many more changes, including addition of an
> ICANN-copyright document with no (obvious) distribution license.
> 
> The RC bug that your request fixes is also still open, which will block
> migration anyway.
> 
> Thanks,
> 
> -- 
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> 


dns-root-data_2017020200.dsc
Description: Binary data


dns-root-data_2017020200.debdiff
Description: Binary data

Bug#863626: unblock: dns-root-data/2017041101

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dns-root-data

Dear release team,

the 2017041101 update of dns-root-data package contains:

- fixes to parse_root_data.sh script to unfail the non-dash
  shells - closes RC bug #862252 (use printf instead of echo command)
- update root.hints to 2017041101 version (no other change then version though)
- update root.key and d/rules to strip any timestamp, so the build is
  more or less reproducible (the get_orig_source still depends on
  upstream data at the time of the build, but it should be more
  reliable)
- little fixes to parse_root_data.sh script, as suggested by shellcheck:
  + use read -r instead of read on xml2 output data
  + use [:upper:]/[:lower:] instead of [A-Z]/[a-z] as tr argument
  + use [ a ] || [ b ] syntax instead of [ a -o b ]

unblock dns-root-data/2017041101

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.4.0-67-generic (SMP w/24 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (native)
Source: dns-root-data
Binary: dns-root-data
Architecture: all
Version: 2017041101
Maintainer: Debian DNS Maintainers <pkg-dns-de...@lists.alioth.debian.org>
Uploaders: Ondřej Surý <ond...@debian.org>, Robert Edmonds <edmo...@debian.org>
Homepage: https://data.iana.org/root-anchors/
Standards-Version: 3.9.6
Vcs-Browser: http://git.debian.org/?p=pkg-dns/dns-root-data.git;a=summary
Vcs-Git: git://git.debian.org/pkg-dns/dns-root-data.git
Build-Depends: debhelper (>= 8.0.0), unbound-anchor, openssl, ldnsutils, xml2
Package-List:
 dns-root-data deb misc optional arch=all
Checksums-Sha1:
 36bfc25763062a4ccc784ced1d821faf8a3f442e 14316 dns-root-data_2017041101.tar.xz
Checksums-Sha256:
 c88bb15f1e16dba1a525928e190999fdc70b16d06e40f2aa9c7b81c4740c30d5 14316 
dns-root-data_2017041101.tar.xz
Files:
 4982844cb0e3b0223fdc93bf9671adc3 14316 dns-root-data_2017041101.tar.xz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlksENtfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwf1vA/9HNXfzN7Z8tUuDm40HsXrCR6vK1KfGpcsoYkqZtyqEnkCSwCjzBCpuXzd
IO9bVVzQaUkzvxVK8Gq0hJaKri7BUKmgRTg9v8MmcIoqmmyi3TIxU5NFUbTgFwaj
qy47bq/gNVJUrYGQJssSE70fHv1iCwWT3Y3xHNdNJfkjiOqIgqgJwB7RzXcPZjgF
ZqzUWelV6vDUE1OsOCo2a8hLRGZa11qK/mbZ8eBhYOwVzf6S/z/tZ7L2y2oUEC3J
u2et1PweqCmQPNC2Xs9KRya9XdFBuMRt4x3EPHygG0u8sziioVaHeNgfNP66gU2g
FlADNfrgS7KLTwXlfHkJ1JLW5/9Zbce3HFdfNGBwESxWSPLJRhCVcycN3N/71T/h
aycV57+hG+rHGOsCdNa9c79KrriikrokBilA31NDmOH77wk6g88EhYtvG7TRbd3S
sCAYPdk06aIAz2V8nMOXATag5iLRrtdlcJaqvmpfB2NyrXWXOlgb0mTc912ACY6B
seDPD3OAmVG5ubOUkBSMyQj7tabjOKkHu+ioYOs3AEYVyIlFxfvle4GwPb6XLaze
gaf5ECU4UdZb/7ARKcX3PEL/UQXxIH3F7CExliqQZ/kqqXD0nWcS16I/BuW+YkwP
86k6ofr1/oxiHbdkFEQvSAocbv2GN74jO2R1Q6p7ptv7K4Ey8Og=
=pbH7
-END PGP SIGNATURE-
diff -Nru dns-root-data-2017020200/debian/changelog 
dns-root-data-2017041101/debian/changelog
--- dns-root-data-2017020200/debian/changelog   2017-03-22 09:06:08.0 
+0100
+++ dns-root-data-2017041101/debian/changelog   2017-05-29 14:05:37.0 
+0200
@@ -1,3 +1,12 @@
+dns-root-data (2017041101) unstable; urgency=medium
+
+  * Fix parse-root-anchors.sh in non-dash shells (Closes: #862252)
+  * Update to 2017041101 version of root zone
+  * Remove timestamps from root.key to make the build reproducible
+  * Shell syntax cleanup
+
+ -- Ondřej Surý <ond...@debian.org>  Mon, 29 May 2017 14:05:37 +0200
+
 dns-root-data (2017020200) unstable; urgency=medium
 
   * Update to 2016102001 version of the root.zone
diff -Nru dns-root-data-2017020200/debian/rules 
dns-root-data-2017041101/debian/rules
--- dns-root-data-2017020200/debian/rules   2017-03-22 09:06:08.0 
+0100
+++ dns-root-data-2017041101/debian/rules   2017-05-29 14:05:37.0 
+0200
@@ -32,6 +32,6 @@
/usr/sbin/unbound-anchor \
-a $(CURDIR)/root-auto.key \
-c $(CURDIR)/icannbundle.pem || echo "Check the root-auto.key"
-   < root-auto.key grep -Ev "^($$|;)" > root.key
+   < root-auto.key grep -Ev "^($$|;)" | sed -e 's/ ;;count=.*//' > root.key
rm root-auto.key
wget -O $(CURDIR)/root.hints "http://www.internic.net/domain/named.root;
diff -Nru dns-root-data-2017020200/parse-root-anchors.sh 
dns-root-data-2017041101/parse-root-anchors.sh
--- dns-root-data-2017020200/parse-root-anchors.sh  2017-03-22 
09:06:08.0 +0100
+++ dns-root-data-2017041101/parse-root-anchors.sh  20

Bug#863625: unblock: botan1.10/1.10.16-1

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package botan1.10

Dear release team,

botan1.10 1.10.16 contains only the fix for the RC bug #860072
(CVE-2017-2801: Incorrect comparison in X.509 DN strings) (+ changelog
entry + version bump), so I have decided to upload 1.10.16 directly
instead of patching the simple patch on top of 1.10.15.

(+ update to d/watch bundled to make it work again)

diffstat:

 botan_version.py  |6 +++---
 debian/changelog  |8 
 debian/watch  |2 +-
 doc/log.txt   |   10 ++
 src/alloc/alloc_mmap/mmap_mem.cpp |3 +--
 src/utils/parsing.cpp |2 ++
 6 files changed, 25 insertions(+), 6 deletions(-)

unblock botan1.10/1.10.16-1

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.4.0-67-generic (SMP w/24 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (quilt)
Source: botan1.10
Binary: botan1.10-dbg, libbotan-1.10-1, libbotan1.10-dev
Architecture: any
Version: 1.10.16-1
Maintainer: Ondřej Surý <ond...@debian.org>
Homepage: http://botan.randombit.net/
Standards-Version: 3.9.6
Vcs-Browser: http://anonscm.debian.org/?p=pkg-nlnetlabs/botan1.10.git
Vcs-Git: git://anonscm.debian.org/pkg-nlnetlabs/botan1.10.git
Build-Depends: debhelper (>= 9), libbz2-dev, libgmp3-dev, python, zlib1g-dev
Package-List:
 botan1.10-dbg deb debug extra arch=any
 libbotan-1.10-1 deb libs optional arch=any
 libbotan1.10-dev deb libdevel optional arch=any
Checksums-Sha1:
 697144c34b1bf77c5b2bc1ff4d08f69ee718782b 2711177 botan1.10_1.10.16.orig.tar.gz
 44fa04f97f5f5af94757774af5048a69f7a5725d 40872 
botan1.10_1.10.16-1.debian.tar.xz
Checksums-Sha256:
 6c5472401d06527e87adcb53dd270f3c9b1fb688703b04dd7a7cfb86289efe52 2711177 
botan1.10_1.10.16.orig.tar.gz
 c30b4631e788e6ec8c256c2eb6e572a4a31075e8563cfa7bcb05e68709e054d3 40872 
botan1.10_1.10.16-1.debian.tar.xz
Files:
 d0c88b523b5aeaaeaf7a3f39dd9d1f3e 2711177 botan1.10_1.10.16.orig.tar.gz
 d446e25344b6e0ad20f4ea390d619d97 40872 botan1.10_1.10.16-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlksDBdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwel5Q//WXrxeAk/nkyer1wymmhmlZ9mn79CInfKnvPeeT/OVDaljHfbC72X/W7/
Iphzb26ZBgFzbxXoIUarA4LWw9gz5TkIrW4jr8CO2lSShH9vVJ6IENCvYew9mrRe
ZctPI8mEkQL0NVsE9F//9p77aeuqM6sFhHEuW5HpuOg3HdrUjaRjrbFN1UHvhf0E
YeU3g15pwom6IwWwWpNTTXt/qXz+XGnTrZ6EjAzGX9nFeMUmlOYxZImRJNMW4xIp
++ixgm2AF21buKCqmzpVYe+nltUCcWI6VFC27XFDBZBcAg6kCo+vi2F4671ugRuu
bTLJ8r3+vfcaw1Il+zqUOybW5+d0+gxy9zS4DnnGY7zzbiwqtEPPBQP1c4+eXcoY
zUMeof3TvjNCcx4aViNRL9XXw5x2qKkdFfxND2MzpEaR+/I3bu3UG1+MIqVb1GaF
OqWBa+hx+NN+BhTJWl33LtDCEjw+f17OBKj4mVZgwVCalxSBLC2s7rTrj0DZ2f7L
fBhH7VTmjzbfnyudUnS6Joewu4nFqftUbT8eUJ8tg2ezqTiEw29pCgA5vI6mFQYE
sga1xfA6J1U3ZMgcyEfF7dlXC2Z4qtYXCmbT4KqS7mEA+r5GP9+TFnoSpEp0LCDU
rJBEYF0VnKfWUoQy+2SWKVRgyHSI0/GPhbYd4uP4wVTNjNYlHv0=
=Zz4K
-END PGP SIGNATURE-
diff -Nru botan1.10-1.10.15/botan_version.py botan1.10-1.10.16/botan_version.py
--- botan1.10-1.10.15/botan_version.py  2017-01-13 02:48:25.0 +0100
+++ botan1.10-1.10.16/botan_version.py  2017-04-05 03:07:02.0 +0200
@@ -1,11 +1,11 @@
 
 release_major = 1
 release_minor = 10
-release_patch = 15
+release_patch = 16
 
 release_so_abi_rev = 1
 
 # These are set by the distribution script
-release_vc_rev = 'git:f79e642ab8c09971968abdfe6990df6801711e1f'
-release_datestamp = 20170112
+release_vc_rev = 'git:3756c97d295d06ac19cec6736e05003afb10623e'
+release_datestamp = 20170404
 release_type = 'released'
diff -Nru botan1.10-1.10.15/debian/changelog botan1.10-1.10.16/debian/changelog
--- botan1.10-1.10.15/debian/changelog  2017-01-13 09:47:48.0 +0100
+++ botan1.10-1.10.16/debian/changelog  2017-05-29 13:45:02.0 +0200
@@ -1,3 +1,11 @@
+botan1.10 (1.10.16-1) unstable; urgency=high
+
+  * Update d/watch to match new upstream download directory
+  * New upstream version 1.10.16
++ [CVE-2017-2801]: Incorrect comparison in X.509 DN strings
+
+ -- Ondřej Surý <ond...@debian.org>  Mon, 29 May 2017 13:45:02 +0200
+
 botan1.10 (1.10.15-1) unstable; urgency=medium
 
   * New upstream version 1.10.15
diff -Nru botan1.10-1.10.15/debian/watch botan1.10-1.10.16/debian/watch
--- botan1.10-1.10.15/debian/watch  2017-01-13 09:47:48.0 +0100
+++ botan1.10-1.10.16/debian/watch  2017-05-29 13:45:02.0 +0200
@@ -1,2 +1,2 @@
 version=3
-http://files.randombit.net/bo

Bug#863624: unblock: lua-http/0.1-3

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lua-http

Dear release team,

the 0.1-3 update fixes two bugs:

- 0.1-1 package contained incorrect Breaks, this was fixed in 0.1-2
  but never uploaded to unstable

- 0.1-3 contains upstream patch to fix RC bug #863286 (HTTP Request
  string failed in non-comma-as-separator locales)

unblock lua-http/0.1-3

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.4.0-67-generic (SMP w/24 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (quilt)
Source: lua-http
Binary: lua-http
Architecture: all
Version: 0.1-3
Maintainer: Ondřej Surý <ond...@debian.org>
Homepage: https://github.com/daurnimator/lua-http
Standards-Version: 3.9.8
Vcs-Browser: https://anonscm.debian.org/git/pkg-lua/lua-http.git
Vcs-Git: git://anonscm.debian.org/pkg-lua/lua-http.git
Build-Depends: debhelper (>= 9), dh-lua, pandoc
Package-List:
 lua-http deb interpreters optional arch=all
Checksums-Sha1:
 b03216bb5c903b07678464664c142ff9c76833c0 116507 lua-http_0.1.orig.tar.gz
 36f72780773ad5752ce33568af9b30de0a582664 3452 lua-http_0.1-3.debian.tar.xz
Checksums-Sha256:
 4ba01edc7f02d49f98cf98883d7ad9b47f5e4c11dd95d5149f980f40ba12e546 116507 
lua-http_0.1.orig.tar.gz
 537488d3a5d918be5f5b625ca53582e318e66484f58f4d9cf034744219275696 3452 
lua-http_0.1-3.debian.tar.xz
Files:
 f5da73665fb3a13cd600e8b17e0c1bb9 116507 lua-http_0.1.orig.tar.gz
 2e5cbfb4a8dca99abf5fb33d5d4569fb 3452 lua-http_0.1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEMLkz2A/OPZgaLTj7DJm3DvT8uwcFAlksChtfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDMw
QjkzM0Q4MEZDRTNEOTgxQTJEMzhGQjBDOTlCNzBFRjRGQ0JCMDcACgkQDJm3DvT8
uwej0w//aN0E0k7GSSpB4wY/zaZWAG3x1fzY9diWU6HF7QvE+r4WDunVwXG8trW/
/JA1ilJfvCLkuBG9C0sFIiLWtkRVrGaZzudbEcEZvjMB4Q4QfvAbpG6v0SJzH8jA
TGj3YeF6IkSG9qUDB94o4pKTfiGEFIvdAP3UqHeJElsMYTMfN16O/HQ6VLC0C1lr
PG8aLnG+dik5eDtu8oopchRTHEj8iD7A0VMPK/7FN6VagaDpWm4F6+cEOq2IEqTj
gbrW4yJqHYEvc3OMhpQ9PiO+sJ8zHxD+z2fzHeXTz5AZQFLwWsZaPRZ6pC/mcvfx
91vZ0330zJ2Bm/dtZ7LSlUncB8gHTX16YiLc3uZc/A6wDM3x4i6LGaGYcr1DaVVv
hBpM7JoPmPFl31gue/MmY9wPe+JAzVKozPJs2aNoCgsrBFdyT3bUe6ZRkop9ITjb
VU0C2uKdxp7xl2+WDbTyKrkpgxVBI9TDwtwQHDIDZB/5qkLvkhHem0YCJZGBLFxa
yeNV97mOoinQp9haDHeBrbImSgNFY/hy+X+weDI8PfVp2s8AvM/DyfZQK8YafgJK
5m/YOQ4gMWIhPCPMdXy3onmYJuBAa2MehHlq+ZZGH83BrImIUmFqAN+D876NjnSh
MR/uHYAkxZK8njUwc2dRFrHVZ/v2SqAtxahBsXVXlE+nqgD8f+0=
=Wpip
-END PGP SIGNATURE-
diff -Nru lua-http-0.1/debian/changelog lua-http-0.1/debian/changelog
--- lua-http-0.1/debian/changelog   2016-12-19 13:13:38.0 +0100
+++ lua-http-0.1/debian/changelog   2017-05-29 13:39:46.0 +0200
@@ -1,3 +1,16 @@
+lua-http (0.1-3) unstable; urgency=medium
+
+  * Fix request building in locales with comma decimal separator
+(Closes: #863286) (Courtesy of Daurnimator)
+
+ -- Ondřej Surý <ond...@debian.org>  Mon, 29 May 2017 13:39:46 +0200
+
+lua-http (0.1-2) unstable; urgency=medium
+
+  * New lua-http breaks knot-resolver-module-http and not knot-resolver
+
+ -- Ondřej Surý <ond...@debian.org>  Tue, 20 Dec 2016 11:39:33 +0100
+
 lua-http (0.1-1) unstable; urgency=medium
 
   * Imported Upstream version 0.1
diff -Nru lua-http-0.1/debian/control lua-http-0.1/debian/control
--- lua-http-0.1/debian/control 2016-12-19 13:13:38.0 +0100
+++ lua-http-0.1/debian/control 2017-05-29 13:39:46.0 +0200
@@ -21,7 +21,7 @@
  lua-luaossl (>= 20161208),
  ${misc:Depends},
  ${shlibs:Depends}
-Breaks: knot-resolver (<< 1.2.0~)
+Breaks: knot-resolver-module-http (<< 1.2.0~)
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
 Description: HTTP library for Lua
diff -Nru 
lua-http-0.1/debian/patches/0001-http-h1_connection-Fix-request-building-in-locales-w.patch
 
lua-http-0.1/debian/patches/0001-http-h1_connection-Fix-request-building-in-locales-w.patch
--- 
lua-http-0.1/debian/patches/0001-http-h1_connection-Fix-request-building-in-locales-w.patch
 1970-01-01 01:00:00.0 +0100
+++ 
lua-http-0.1/debian/patches/0001-http-h1_connection-Fix-request-building-in-locales-w.patch
 2017-05-29 13:39:46.0 +0200
@@ -0,0 +1,32 @@
+From: daurnimator <q...@daurnimator.com>
+Date: Thu, 25 May 2017 11:04:32 +1000
+Subject: http/h1_connection: Fix request building in locales with comma
+ decimal separator
+
+Reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863286
+---
+ http/h1_connection.lua | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/http/h1_connection.lua b/http/h1_con