Bug#930494: unblock: rootskel/1.131

2019-06-13 Thread Samuel Thibault
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

As mentioned in #930493, I have re-measured the minimum memory
contraints of d-i, and the g-i part is in rootskel, as attached here,
could you unblock it?

unblock rootskel/1.131

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

Kernel: Linux 5.1.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru rootskel-1.129/debian/changelog rootskel-1.131/debian/changelog
--- rootskel-1.129/debian/changelog 2019-04-20 02:24:53.0 +0200
+++ rootskel-1.131/debian/changelog 2019-06-13 21:28:44.0 +0200
@@ -1,3 +1,24 @@
+rootskel (1.131) unstable; urgency=medium
+
+  * Team upload
+  * Remove spurious files.
+
+ -- Samuel Thibault   Thu, 13 Jun 2019 21:28:44 +0200
+
+rootskel (1.130) unstable; urgency=medium
+
+  * Team upload
+
+  [ Cyril Brulebois ]
+  * Remove Christian Perrier from Uploaders, with many thanks for all
+his contributions over the years! (Closes: #927486)
+
+  [ Samuel Thibault ]
+  * src/lib/debian-installer.d/S60frontend: Update gtk memory limit, now with
+encryption support which eats a lot.
+
+ -- Samuel Thibault   Thu, 13 Jun 2019 20:39:11 +0200
+
 rootskel (1.129) unstable; urgency=medium
 
   * S50entropy-source: start haveged when appropriate, to avoid entropy
diff -Nru rootskel-1.129/debian/control rootskel-1.131/debian/control
--- rootskel-1.129/debian/control   2019-03-08 15:21:53.0 +0100
+++ rootskel-1.131/debian/control   2019-06-02 13:29:14.0 +0200
@@ -2,7 +2,7 @@
 Section: debian-installer
 Priority: standard
 Maintainer: Debian Install System Team 
-Uploaders: Colin Watson , Bastian Blank 
, Christian Perrier , Steve McIntyre 
<93...@debian.org>
+Uploaders: Colin Watson , Bastian Blank 
, Steve McIntyre <93...@debian.org>
 Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.7.0), linux-libc-dev (>= 
2.6.38) [linux-any]
 Vcs-Browser: https://salsa.debian.org/installer-team/rootskel
 Vcs-Git: https://salsa.debian.org/installer-team/rootskel.git
diff -Nru rootskel-1.129/src/lib/debian-installer.d/S60frontend 
rootskel-1.131/src/lib/debian-installer.d/S60frontend
--- rootskel-1.129/src/lib/debian-installer.d/S60frontend   2017-02-11 
22:24:40.0 +0100
+++ rootskel-1.131/src/lib/debian-installer.d/S60frontend   2019-06-02 
13:28:52.0 +0200
@@ -31,14 +31,14 @@
case "$(archdetect)" in
# Tested with Uyghur
powerpc/*|amd64/*)
-   local MEMLIMIT=310 ;;   # is 316864kB, qemu -m 327
+   local MEMLIMIT=766 ;;   # is 783460kB, qemu -m 800
kfreebsd-amd64/*)
# See Bug#783775 for derivation.
local MEMLIMIT=144 ;;   # is 147456kB, qemu -m 256
hurd-i386/*)
local MEMLIMIT=750 ;;   #  qemu -m 750
*)
-   local MEMLIMIT=281 ;;   # is 287732kB, qemu -m 293
+   local MEMLIMIT=534 ;;   # is 546188kB, qemu -m 550
esac
 
if [ $(get_mem) -lt $MEMLIMIT ] ; then


Bug#930493: unblock: lowmem/1.47

2019-06-13 Thread Samuel Thibault
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

Now that things have settled down, I have re-measured the minimum memory
contraints of d-i and thus uploaded a new version of lowmem with the
attached changes, could you unblock it?

It can be noted that the minimum have changed quite a lot because I
changed the test a bit: we were not testing with encryption support
previously, and it happens to require quite a lot of memory.

I have also added ignoring a lintian error about missing translations,
since lowmem conditions are precisely when we want to drop translations
:)

unblock lowmem/1.47

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

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

-- 
Samuel
 r: et la marmotte, elle écrit un papier IPDPS
diff -Nru lowmem-1.46/debian/changelog lowmem-1.47/debian/changelog
--- lowmem-1.46/debian/changelog2018-08-28 18:00:17.0 +0200
+++ lowmem-1.47/debian/changelog2019-06-13 20:28:13.0 +0200
@@ -1,3 +1,17 @@
+lowmem (1.47) unstable; urgency=medium
+
+  * Team upload
+
+  [ Cyril Brulebois ]
+  * Remove Christian Perrier from Uploaders, with many thanks for all
+his contributions over the years! (Closes: #927570)
+
+  [ Samuel Thibault ]
+  * Update limits.
+  * source.lintian-overrides: Ignore untranslated templates.
+
+ -- Samuel Thibault   Thu, 13 Jun 2019 20:28:13 +0200
+
 lowmem (1.46) unstable; urgency=medium
 
   * Team upload
diff -Nru lowmem-1.46/debian/control lowmem-1.47/debian/control
--- lowmem-1.46/debian/control  2018-08-10 21:22:39.0 +0200
+++ lowmem-1.47/debian/control  2019-06-02 14:23:59.0 +0200
@@ -2,7 +2,6 @@
 Section: debian-installer
 Priority: optional
 Maintainer: Debian Install System Team 
-Uploaders: Christian Perrier 
 Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.9.0)
 Vcs-Browser: https://salsa.debian.org/installer-team/lowmem
 Vcs-Git: https://salsa.debian.org/installer-team/lowmem.git
diff -Nru lowmem-1.46/debian/source.lintian-overrides 
lowmem-1.47/debian/source.lintian-overrides
--- lowmem-1.46/debian/source.lintian-overrides 2018-08-10 21:22:39.0 
+0200
+++ lowmem-1.47/debian/source.lintian-overrides 2019-06-13 20:28:13.0 
+0200
@@ -1 +1,2 @@
 lowmem source: not-using-po-debconf
+lowmem source: untranslatable-debconf-templates
diff -Nru lowmem-1.46/debian-installer-startup.d/S15lowmem 
lowmem-1.47/debian-installer-startup.d/S15lowmem
--- lowmem-1.46/debian-installer-startup.d/S15lowmem2018-08-10 
21:22:39.0 +0200
+++ lowmem-1.47/debian-installer-startup.d/S15lowmem2019-06-02 
14:21:18.0 +0200
@@ -25,9 +25,9 @@
min=39
;;
amd64)
-   level1=163 # MT=166348, qemu: -m 178
-   level2=163 # MT=166348, qemu: -m 178
-   min=163# MT=166348, qemu: -m 178
+   level1=483 # MT=494300, qemu: -m 550
+   level2=273 # MT=279260, qemu: -m 300
+   min=145# MT=148188, qemu: -m 170
;;
arm|armel|armhf)
# Update needed
@@ -42,9 +42,9 @@
min=18
;;
i386)
-   level1=135 # MT=137688, qemu: -m 145
-   level2=135 # MT=137688, qemu: -m 145
-   min=135# MT=137688, qemu: -m 145
+   level1=386 # MT=394604, qemu: -m 400
+   level2=237 # MT=242628, qemu: -m 250
+   min=109# MT=110956, qemu: -m 120
;;
mips)
# Update needed
@@ -88,11 +88,10 @@
level2=44 # MT=44376, qemu: -m 104
min=30# MT=30040, qemu: -m 90
;;
-   # Update needed
hurd-i386)
level1=499 # qemu: -m 500
level2=409 # qemu: -m 410
-   min=364# qemu: -m 365
+   min=389# qemu: -m 390
;;
*)
level1=64
diff -Nru lowmem-1.46/README lowmem-1.47/README
--- lowmem-1.46/README  2018-08-10 21:22:39.0 +0200
+++ lowmem-1.47/README  

Bug#929214: release.debian.org - Add package constraint for cloud images

2019-06-13 Thread Bastian Blank
Hi

On Wed, Jun 12, 2019 at 08:01:08PM +0200, Bastian Blank wrote:
> On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote:
> > If you create such a package, having a binary per architecture as you
> > describe, should do what you want. It can be added to the list as soon as it
> > is in testing.
> Okay, thank you.

A quick question:

Will britney choke if we list conflicting packages as dependencies?

Something like this:
| Depends: exim4, postfix

Regards,
Bastian

-- 
Death, when unnecessary, is a tragic thing.
-- Flint, "Requiem for Methuselah", stardate 5843.7



Bug#930490: unblock: exim4/4.92-8

2019-06-13 Thread Andreas Metzler
forgot the diff ...
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files only in first set of .debs, found in package exim4-daemon-heavy-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/34/a72aedf4830a64e9961936f0a93b3622cea618.debug

Files only in first set of .debs, found in package exim4-daemon-light-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/16/688cb8a676f11335e1024842d2a40f8a46c0e3.debug

Files only in first set of .debs, found in package eximon4-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/fa/ceba3b71bca811aa3fbfb78e57ab48cdbf8f82.debug

New files in second set of .debs, found in package exim4-daemon-heavy-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d5/aaad5b8de78f401c35c3c4bf1df0aa93e70bcc.debug

New files in second set of .debs, found in package exim4-daemon-light-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/0c/787f2ab182ef325414f50a2410be0d7d032c29.debug

New files in second set of .debs, found in package eximon4-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/6c/8920f1a04a04ae113141c38137cca0ad2fe624.debug


Control files of package exim4: lines which differ (wdiff format)
-
Depends: debconf (>= 1.4.69) | cdebconf (>= 0.39), exim4-base (<< 
[-4.92-7.1),-] {+4.92-8.1),+} exim4-base (>= [-4.92-7),-] {+4.92-8),+} 
exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom, debconf (>= 0.5) 
| debconf-2.0
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-base: lines which differ (wdiff format)
--
Installed-Size: [-1623-] {+1624+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-base-dbgsym: lines which differ (wdiff format)
-
Depends: exim4-base (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-config: lines which differ (wdiff format)

Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-heavy: lines which differ (wdiff format)
--
Installed-Size: [-1477-] {+1473+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-heavy-dbgsym: lines which differ (wdiff 
format)
-
Build-Ids: [-34a72aedf4830a64e9961936f0a93b3622cea618-] 
{+d5aaad5b8de78f401c35c3c4bf1df0aa93e70bcc+}
Depends: exim4-daemon-heavy (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-light: lines which differ (wdiff format)
--
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-light-dbgsym: lines which differ (wdiff 
format)
-
Build-Ids: [-16688cb8a676f11335e1024842d2a40f8a46c0e3-] 
{+0c787f2ab182ef325414f50a2410be0d7d032c29+}
Depends: exim4-daemon-light (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-dev: lines which differ (wdiff format)
-
Version: [-4.92-7-] {+4.92-8+}

Control files of package eximon4: lines which differ (wdiff format)
---
Version: [-4.92-7-] {+4.92-8+}

Control files of package eximon4-dbgsym: lines which differ (wdiff format)
--
Build-Ids: [-faceba3b71bca811aa3fbfb78e57ab48cdbf8f82-] 
{+6c8920f1a04a04ae113141c38137cca0ad2fe624+}
Depends: eximon4 (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}
diff -Nru exim4-4.92/debian/changelog exim4-4.92/debian/changelog
--- exim4-4.92/debian/changelog 2019-05-07 19:44:23.0 +0200
+++ exim4-4.92/debian/changelog 2019-06-08 17:37:43.0 +0200
@@ -1,3 +1,24 @@
+exim4 (4.92-8) unstable; urgency=low
+
+  * Pulled from exim-4.92+fixes branch:
++ 75_11-GnuTLS-fix-tls_out_ocsp-under-hosts_request_ocsp.patch
+  Fix expansion of $tls_out_ocsp under hosts_request_ocsp.
++ 75_12-GnuTLS-fix-the-advertising-of-acceptable-certs-by-th.patch
+  When tls_verify_certificates was set to a directory 

Bug#930491: unblock: gnutls28/3.6.7-4

2019-06-13 Thread Andreas Metzler
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gnutls28. This upload cherry-picks the
recommended fixes[1] from upstream latest stable release (3.6.8) and fixes
#929907.

+ 40_rel3.6.8_01-gnutls_srp_entry_free-follow-consistent-behavior-in.patch
  The gnutls_srp_set_server_credentials_function can be used with the 8192
  parameters as well.
  https://gitlab.com/gnutls/gnutls/issues/761
+ 40_rel3.6.8_05-lib-nettle-fix-carry-flag-in-Streebog-code.patch
  Fix calculation of Streebog digests (incorrect carry operation in
  512 bit addition).
+ 40_rel3.6.8_10-ext-record_size_limit-distinguish-sending-and-receiv.patch
  Fix compatibility of GnuTLS 3.6.[456] server with GnuTLS 3.6.7 client.
  Closes: #929907
+ 40_rel3.6.8_15-Apply-STD3-ASCII-rules-in-gnutls_idna_map.patch
  Apply STD3 ASCII rules in gnutls_idna_map() to prevent hostname/domain
  crafting via IDNA conversion.
  https://gitlab.com/gnutls/gnutls/issues/720
+ 40_rel3.6.8_20-pubkey-remove-deprecated-TLS1_RSA-flag-check.patch
  Fixed bug preventing the use of gnutls_pubkey_verify_data2() and
  gnutls_pubkey_verify_hash2() with the GNUTLS_VERIFY_DISABLE_CA_SIGN
  flag.
  https://gitlab.com/gnutls/gnutls/issues/754

(explain the reason for the unblock here)

(include/attach the debdiff against the package in testing)

unblock gnutls28/3.6.7-4

cu Andreas

[1] https://lists.gnutls.org/pipermail/gnutls-help/2019-June/004552.html
I have left out the fix for the DH security hardening measure in this
upload as adds new symbols.
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files only in first set of .debs, found in package libgnutls-dane0-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d5/67cd17694664c4204ff158450183359925afb1.debug

Files only in first set of .debs, found in package libgnutls-openssl27-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/6c/cd7f2e8735b2f7448f0757271b8413bbaac807.debug

Files only in first set of .debs, found in package libgnutls30-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/fe/becd51bb621afd4a8f0352f55d6c2ed96df57a.debug

New files in second set of .debs, found in package libgnutls-dane0-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d3/28298de34135fca5f236357f2f2dd56cb109f3.debug

New files in second set of .debs, found in package libgnutls-openssl27-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/fe/4c3c0c38af44779c38ae5d1e187b6250f7afe0.debug

New files in second set of .debs, found in package libgnutls30-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/4d/66d28cd2e7537e1e1d2905595b260226b22ad2.debug


Control files of package gnutls-bin: lines which differ (wdiff format)
--
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package gnutls-bin-dbgsym: lines which differ (wdiff format)
-
Depends: gnutls-bin (= [-3.6.7-3)-] {+3.6.7-4)+}
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package gnutls-doc: lines which differ (wdiff format)
--
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-dane0: lines which differ (wdiff format)
---
Depends: libgnutls30 (= [-3.6.7-3),-] {+3.6.7-4),+} libc6 (>= 2.14), 
libunbound8 (>= 1.8.0)
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-dane0-dbgsym: lines which differ (wdiff 
format)
--
Build-Ids: [-d567cd17694664c4204ff158450183359925afb1-] 
{+d328298de34135fca5f236357f2f2dd56cb109f3+}
Depends: libgnutls-dane0 (= [-3.6.7-3)-] {+3.6.7-4)+}
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-openssl27: lines which differ (wdiff format)
---
Depends: libgnutls30 (= [-3.6.7-3),-] {+3.6.7-4),+} libc6 (>= 2.14)
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-openssl27-dbgsym: lines which differ (wdiff 
format)
--
Build-Ids: [-6ccd7f2e8735b2f7448f0757271b8413bbaac807-] 
{+fe4c3c0c38af44779c38ae5d1e187b6250f7afe0+}
Depends: libgnutls-openssl27 (= [-3.6.7-3)-] 

Bug#930490: unblock: exim4/4.92-8

2019-06-13 Thread Andreas Metzler
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package exim4. This upload pulls 5 patches from upstream
GIT:
+ 75_11-GnuTLS-fix-tls_out_ocsp-under-hosts_request_ocsp.patch
  Fix expansion of $tls_out_ocsp under hosts_request_ocsp.
+ 75_12-GnuTLS-fix-the-advertising-of-acceptable-certs-by-th.patch
  When tls_verify_certificates was set to a directory instead of a file
  exim/GnuTLS would still send out the list of accepted certificates,
  This did not match documented behavior.
+ 75_13-Use-dsn_from-for-success-DSN-messages.-Bug-2404.patch
  The dsn_from option was not used for DSN success messages.
+ 75_14-Fix-smtp-response-timeout.patch
  Fix the timeout on smtp response to apply to the whole response instead
  of resetting for every byte received.
+ 75_15-Fix-detection-of-32b-platform-at-build-time.-Bug-240.patch
  https://bugs.exim.org/show_bug.cgi?id=2405
  ${eval } was broken on 32bit archs.

unblock exim4/4.92-8

Thanks, cu Andreas



Processed: Re: Bug#930324: unblock: nageru/1.8.4-2

2019-06-13 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 930324 -moreinfo
Bug #930324 [release.debian.org] unblock: nageru/1.8.4-2
Removed tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
930324: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930324
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#930324: unblock: nageru/1.8.4-2

2019-06-13 Thread Steinar H. Gunderson
tags 930324 -moreinfo
thanks

>>> I unblocked it, but noticed it's stuck behind gcc-8. Can you prepare a
>>> testing-proposed-updates upload?
>> 
>> Sure! I'll upload tonight.
> Please remove the moreinfo tag when the package is available to be
> unblocked.

nageru 1.8.4-1+buster1 uploaded.

/* Steinar */
-- 
Homepage: https://www.sesse.net/



Bug#928185: unblock: openjdk-11/11.0.3+7-4

2019-06-13 Thread Matthias Klose
On 12.06.19 20:38, Paul Gevers wrote:
> Hi Matthias,
> 
> On 12-06-2019 10:33, Emmanuel Bourg wrote:
>> I talked to Matthias on IRC yesterday, he was ok with the +really
>> version in unstable only as a testbed for a tpu upload with a sane version.
> 
> Can you explain why, please?

because we had so much fun with rants about versioning questions for OpenJDK.
Just avoiding that would be nice.



Processed: Re: Bug#930371: unblock: dbus/1.12.16-1

2019-06-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 confirmed
Bug #930371 [release.debian.org] unblock: dbus/1.12.16-1
Added tag(s) confirmed.

-- 
930371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#930371: unblock: dbus/1.12.16-1

2019-06-13 Thread Paul Gevers
Control: tags -1 confirmed

Hi Simon,

On 11-06-2019 17:23, Simon McVittie wrote:
> Please unblock package dbus to fix CVE-2019-12749. I forgot to set high
> urgency, so you might want to adjust its age-days too.

You have an autopkgtest that passed, so it is already at two days.

> Filtered and full diffs are attached (the former has Autotools noise
> removed). As usual, I'm happy to revert anything that -release can't
> accept, because the whole 1.12.x branch exists for the benefit of
> distros with a bugfix-only policy (but having said that, everything
> in this particular version is either CVE-2019-12749, tests for it,
> or release preparation).

This looks acceptable to me. So I'll unblock it from our side.

> dbus builds udebs, so this will need an ack from debian-boot (although
> from comments on #929132 it isn't clear to me whether the udebs are
> actually used for anything).

As it isn't fully clear to me either, I'll wait for d-i anyways.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]

2019-06-13 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Mo,

On 09-06-2019 05:41, Mo Zhou wrote:
> Following
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u
> I've not uploaded it yet but asking for permission first.

Thanks.

> Fix a GRAVE stable RC due to linux's unexporting several
> fpu-related symbols:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929
> 
> This is the very only purpose of this upload.
> The solution in this upload is cherry-picked from upstream,
> which directly disable the SIMD thing for linux (>= 4.19.38).
> 
> I scanned the rest historical patches we have applied to
> zfs 0.7.12. Some of them fix crashes and segfaults but they
> don't look fatal enough and would inflate the debdiff hence
> incur rejection. Let's forget them.
> 
> I've tested this patch on Buster with a manually-built
> 4.19.48 kernel (make defconfig, make, make bindeb-pkg).
> 
> Full source:
> https://people.debian.org/~lumin/upload/zfs-linux_0.7.12-2+deb10u1_source.changes
> Debdiff: attached.
> 
> (include/attach the debdiff against the package in testing)
> 
> unblock zfs-linux/0.7.12-2+deb10u1

We are not promising to unblock the package, but we recognize it that
you can't help it that the kernel is breaking your package in the
future. So please upload to tpu, have the package built and please
solicit people to test the package. Please report back with the results.

Paul



signature.asc
Description: OpenPGP digital signature


Processed: Re: Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]

2019-06-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 moreinfo
Bug #930238 [release.debian.org] unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]
Added tag(s) moreinfo.

-- 
930238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#930467: unblock (pre-approval): mu-editor/1.0.2+dfsg-2.1

2019-06-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 moreinfo
Bug #930467 [release.debian.org] unblock (pre-approval): 
mu-editor/1.0.2+dfsg-2.1
Added tag(s) moreinfo.

-- 
930467: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930467
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#930467: unblock (pre-approval): mu-editor/1.0.2+dfsg-2.1

2019-06-13 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Peter,

On 13-06-2019 10:34, plugwash wrote:
> Recently I became aware of two issues in mu-editor. A tool for beginning
> python programmers.
> 
> I was informed that the "debug" button in mu-editors default python mode was
> broken in the Debian packaged version of mu. While this does not render
> the software totally unusable it is a pretty major deficiency.
> 
> The cause of the breakage is that the debug helper program 
> /usr/share/mu-editor/mu-debug.py fails to find the python module mu.app
> due to not having /usr/share/mu-editor in it's sys.path. The main mu 
> executable
> is in /usr/share/mu-editor, so it finds the modules through the default 
> sys.path[0], but the debug helper script is in /usr/share/mu-editor/mu so it
> does not find them. My fix was to make the debug helper script modify 
> sys.path[0] before importing mu.app.
> 
> While working on the above issue I discovered that the clean target did not
> clean up completely (in violation of policy 4.9) and this was making working 
> on
> the package irritating, so I added some extra rm commands to clean up the 
> stray
> files.
> 
> Is there any chance of getting at least the first and preferablly both of 
> these
> fixes into buster?
> 
> A debdiff is attatched. 
> 
> unblock mu-editor/1.0.2+dfsg-2.1

These bugs are not RC. You filed the bug today. Please coordinate with
the maintainer first before filing unblock bugs for an NMU so quickly.
And fix your bug meta-data please.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

2019-06-13 Thread Arnaud Rebillout
On 6/13/19 3:31 PM, Paul Gevers wrote:
> Control: retitle -1 unblock: docker.io [pre-approval]
> Control: tags -1 moreinfo
>
> Hi Arnaud,
>
> On 10-06-2019 06:44, Arnaud Rebillout wrote:
>> I'm about to upload a fix for #929662 "docker.io: CVE-2018-15664", but
>> before I do that I'd like to ask a question to the release team.
>>
>> For now in testing we have docker.io 18.09.1, and on top of that I've
>> been importing upstream patches to fix RC bugs, because from what I
>> understand from the Policy, that's what I should do.
> During the freeze we only want targeted fixes for bugs of severity
> important and higher (BTS definition) [freeze-policy], yes
>
>> The 18.09 series of docker is a so-called "LTS", and that's exactly why
>> it's THIS release in particular that I targeted for Buster, rather than
>> a more recent release. Every now and then upstream releases a new dot
>> release, the latest to date is 18.09.6 (released in May).
> ... but it's possible that new upstream releases *are* targeted bug
> fixes. However, ...
>
>> According to the upstream changelog, these are mostly fixes. And to get
>> an idea of the volume, between 18.09.1 to 18.09.6, there was 142
>> commits, which is rather small compared to the size of docker's codebase.
> you as the maintainer have to do the checking. And, "mostly" doesn't
> qualify. 142 is *not* small at this moment of the release [last-weeks].
>
>> So it seems to me that upstream really only adds fixes to the 18.09
> ^^^ I'd like you to make that assertion much stronger.
> Convince yourself 100%, so you can convince us. Is there a LTS policy
> that describes what upstream considers acceptable? Does it align with
> our bug severity important or higher? Do they test thoroughly? Etc...
>
>> series, and I also think that our users would be better served if they
>> could have the latest version of this series in Buster, rather than what
>> I'm doing now: only patching 18.09.1 with whatever bug was reported in
>> Debian and marked RC, and ignoring all the other bugs that were reported
>> and fixed upstream.
> I care for bugs that are reported in the Debian BTS, but that doesn't
> mean that it's all we care about. We have had multiple unblock requests
> where the maintainer was evaluating the changes done upstream and
> convinced themselves that they all qualified. By doing the evaluation
> they were often able to convince us. In some cases they didn't. I can
> only assume that a lot of unblock requests were not filed because the
> maintainer couldn't convince themselves.
>
>> Hence I'd like to ask the release team if they think it would be
>> suitable to unblock docker.io to allow the version 18.09.6 to be
>> uploaded in Buster? Or, better, wait for the next 18.09.7 that will
>> include the CVE fix, probably in the next days?
> Upstream releases are not acceptable at this moment in the release.
> After what I wrote above, obviously with the exception where you can
> convince yourself and us that *everything* in the release is qualifying
> our freeze criteria [freeze-policy]. However, if at this moment in the
> freeze [last-weeks] you need so many changes, I seriously wonder if your
> package should be in buster (in general, not necessarily valid for
> docker.io)
>
>> Or should I just stick to 18.09.1, and only upload a new debian version
>> that only includes the CVE fix?
> You'll get an unblock much easier.


I'll go this way then :)

Thanks for taking some time to give such a detailed answer, not only for
docker.io but more generally to get a better grasp on what's suitable or
not during the freeze.

I won't audit the whole 142 commits, even less convince myself or anyone
about what it brings on the table, so I'll stick to fixing the CVE that
is opened at the moment.

Thanks,

  Arnaud



Bug#930324: unblock: nageru/1.8.4-2

2019-06-13 Thread Paul Gevers
Control: tags -1 moreinfo confirmed

On 12-06-2019 16:12, Steinar H. Gunderson wrote:
> On Wed, Jun 12, 2019 at 04:06:30PM +0200, Ivo De Decker wrote:
>>> Please unblock package nageru
>> I unblocked it, but noticed it's stuck behind gcc-8. Can you prepare a
>> testing-proposed-updates upload?
> 
> Sure! I'll upload tonight.

Please remove the moreinfo tag when the package is available to be
unblocked.

Thanks.

Paul



signature.asc
Description: OpenPGP digital signature


Processed: Re: Bug#930324: unblock: nageru/1.8.4-2

2019-06-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 moreinfo confirmed
Bug #930324 [release.debian.org] unblock: nageru/1.8.4-2
Added tag(s) confirmed and moreinfo.

-- 
930324: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930324
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#930277: marked as done (unblock: gdcm_2.8.8-9)

2019-06-13 Thread Debian Bug Tracking System
Your message dated Thu, 13 Jun 2019 10:39:57 +0200
with message-id <6a98bb1f-4cec-9c8c-59b5-aec147f43...@debian.org>
and subject line Re: unblock: gdcm_2.8.8-9
has caused the Debian Bug report #930277,
regarding unblock: gdcm_2.8.8-9
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
930277: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930277
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gdcm-2.8.8-9 

The package is testing gdcm-2.8.8-6 FTBFS on some architectures
(#929718) because the provided .symbols file changes depending on the
build dependencies.

With version gdcm-2.8.8-9 the symbols file is dropped again because
this seem so be the only viable approach to alliviate this problem when
it comes to C++ libraries.

Many thanks, 
Gert 

unblock gdcm/2.8.8-9

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.48-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff -Nru gdcm-2.8.8/debian/changelog gdcm-2.8.8/debian/changelog
--- gdcm-2.8.8/debian/changelog	2019-01-13 09:26:00.0 +0100
+++ gdcm-2.8.8/debian/changelog	2019-03-26 22:07:17.0 +0100
@@ -1,3 +1,24 @@
+gdcm (2.8.8-9) unstable; urgency=medium
+
+  * d/*.symbols: remove symbols file, with C++ libraries this
+just doesn't work well enough.
+
+ -- Gert Wollny   Tue, 26 Mar 2019 22:07:17 +0100
+
+gdcm (2.8.8-8) unstable; urgency=medium
+
+  * d/libvtkgdcm2.8a.symbols: Attempt to fix symbols on mips/mipsel
+
+ -- Gert Wollny   Tue, 26 Mar 2019 19:35:20 +0100
+
+gdcm (2.8.8-7) unstable; urgency=medium
+
+  [ Gianfranco Costamagna ]
+  * Fixup symbols file, mark as optional some symbols disappearing
+with a -O3 build
+
+ -- Gert Wollny   Fri, 08 Mar 2019 11:33:29 +0100
+
 gdcm (2.8.8-6) unstable; urgency=medium
 
   * d/p/fiX_charls_2: Fix compilation with CharLS-2.0
diff -Nru gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols
--- gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols	2019-01-13 09:26:00.0 +0100
+++ gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols	1970-01-01 01:00:00.0 +0100
@@ -1,1001 +0,0 @@
-libvtkgdcm.so.2.8 libvtkgdcm2.8a #MINVER#
-* Build-Depends-Package: libvtkgdcm2-dev
- (regex|c++|optional)^_ZNK?4gdcm9Attribute.*@Base$ 2.8.7
- (regex|c++|optional)^_ZNK?4gdcm7Element.*@Base$ 2.8.7
- (regex|c++|optional)^_ZN?St.*@Base$ 2.8.7
- _Z23vtkImageRGBToYBRExecuteIaEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIcEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIdEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIfEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIhEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIiEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIjEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIlEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteImEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIsEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteItEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIxEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIyEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIaEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIcEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIdEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIfEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIhEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIiEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIjEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIlEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- 

Bug#930467: unblock (pre-approval): mu-editor/1.0.2+dfsg-2.1

2019-06-13 Thread plugwash
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Recently I became aware of two issues in mu-editor. A tool for beginning
python programmers.

I was informed that the "debug" button in mu-editors default python mode was
broken in the Debian packaged version of mu. While this does not render
the software totally unusable it is a pretty major deficiency.

The cause of the breakage is that the debug helper program 
/usr/share/mu-editor/mu-debug.py fails to find the python module mu.app
due to not having /usr/share/mu-editor in it's sys.path. The main mu executable
is in /usr/share/mu-editor, so it finds the modules through the default 
sys.path[0], but the debug helper script is in /usr/share/mu-editor/mu so it
does not find them. My fix was to make the debug helper script modify 
sys.path[0] before importing mu.app.

While working on the above issue I discovered that the clean target did not
clean up completely (in violation of policy 4.9) and this was making working on
the package irritating, so I added some extra rm commands to clean up the stray
files.

Is there any chance of getting at least the first and preferablly both of these
fixes into buster?

A debdiff is attatched. 

unblock mu-editor/1.0.2+dfsg-2.1
diff -Nru mu-editor-1.0.2+dfsg/debian/changelog 
mu-editor-1.0.2+dfsg/debian/changelog
--- mu-editor-1.0.2+dfsg/debian/changelog   2019-02-28 02:43:16.0 
+
+++ mu-editor-1.0.2+dfsg/debian/changelog   2019-06-13 02:03:44.0 
+
@@ -1,3 +1,12 @@
+mu-editor (1.0.2+dfsg-2.1) unstable; urgency=medium
+
+  * Non-Maintainer upload.
+  * Adjust sys.path[0] in mu/mu-debug.py so that debugger works
+(Closes: 930457)
+  * Fix clean target.
+
+ -- Peter Michael Green   Thu, 13 Jun 2019 02:03:44 +
+
 mu-editor (1.0.2+dfsg-2) unstable; urgency=medium
 
   * d/gbp.conf: use pristine-tar
diff -Nru mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch 
mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch
--- mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch   
1970-01-01 00:00:00.0 +
+++ mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch   
2019-06-13 02:03:44.0 +
@@ -0,0 +1,24 @@
+Description:  Adjust sys.path[0] in mu/mu-debug.py so that debugger works
+ Debian installs mu-editor's modules in a directory that is not on the
+ global python path. mu-editor finds the modules through sys.path[0]
+ pointing at /usr/share/mu-editor, unfortunately for mu-debug.py 
+ sys.path[0] is /usr/share/mu-editor/mu, so the modules are not found
+ adjust sys.path[0] in mu-editor.py to fix this issue
+Author: Peter Michael Green 
+Last-Update: 2019-06-13
+Bug-Debian: https://bugs.debian.org/930457
+
+--- mu-editor-1.0.2+dfsg.orig/mu/mu-debug.py
 mu-editor-1.0.2+dfsg/mu/mu-debug.py
+@@ -1,6 +1,11 @@
+ #!/usr/bin/env python3
+ import os
+ import sys
++
++#Remove last path element from sys.path[0] so that mu modules can be found 
relative to this executable.
++import os.path
++sys.path[0] = os.path.dirname(sys.path[0])
++
+ from mu.app import debug
+ 
+ 
diff -Nru mu-editor-1.0.2+dfsg/debian/patches/series 
mu-editor-1.0.2+dfsg/debian/patches/series
--- mu-editor-1.0.2+dfsg/debian/patches/series  2019-02-28 02:43:16.0 
+
+++ mu-editor-1.0.2+dfsg/debian/patches/series  2019-06-13 02:03:44.0 
+
@@ -8,3 +8,4 @@
 remove-non-dfsg-images-from-docs
 remove-non-dfsg-resources
 test_app_icon_as_string
+mu-debug-alter-sys.path.patch
diff -Nru mu-editor-1.0.2+dfsg/debian/rules mu-editor-1.0.2+dfsg/debian/rules
--- mu-editor-1.0.2+dfsg/debian/rules   2019-02-28 02:43:16.0 +
+++ mu-editor-1.0.2+dfsg/debian/rules   2019-06-13 02:03:44.0 +
@@ -27,6 +27,9 @@
 override_dh_auto_clean:
dh_auto_clean
rm -rf docs/html
+   rm -f debian/mu-editor.1
+   rm -f debian/mu-editor.1.md
+   rm -rf .pytest_cache
 
 override_dh_auto_build:
dh_auto_build


Processed: Re: Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

2019-06-13 Thread Debian Bug Tracking System
Processing control commands:

> retitle -1 unblock: docker.io [pre-approval]
Bug #930293 [release.debian.org] unblock: docker.io/18.09.1+dfsg1-7
Changed Bug title to 'unblock: docker.io [pre-approval]' from 'unblock: 
docker.io/18.09.1+dfsg1-7'.
> tags -1 moreinfo
Bug #930293 [release.debian.org] unblock: docker.io [pre-approval]
Added tag(s) moreinfo.

-- 
930293: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930293
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

2019-06-13 Thread Paul Gevers
Control: retitle -1 unblock: docker.io [pre-approval]
Control: tags -1 moreinfo

Hi Arnaud,

On 10-06-2019 06:44, Arnaud Rebillout wrote:
> I'm about to upload a fix for #929662 "docker.io: CVE-2018-15664", but
> before I do that I'd like to ask a question to the release team.
>
> For now in testing we have docker.io 18.09.1, and on top of that I've
> been importing upstream patches to fix RC bugs, because from what I
> understand from the Policy, that's what I should do.

During the freeze we only want targeted fixes for bugs of severity
important and higher (BTS definition) [freeze-policy], yes

> The 18.09 series of docker is a so-called "LTS", and that's exactly why
> it's THIS release in particular that I targeted for Buster, rather than
> a more recent release. Every now and then upstream releases a new dot
> release, the latest to date is 18.09.6 (released in May).

... but it's possible that new upstream releases *are* targeted bug
fixes. However, ...

> According to the upstream changelog, these are mostly fixes. And to get
> an idea of the volume, between 18.09.1 to 18.09.6, there was 142
> commits, which is rather small compared to the size of docker's codebase.

you as the maintainer have to do the checking. And, "mostly" doesn't
qualify. 142 is *not* small at this moment of the release [last-weeks].

> So it seems to me that upstream really only adds fixes to the 18.09

^^^ I'd like you to make that assertion much stronger.
Convince yourself 100%, so you can convince us. Is there a LTS policy
that describes what upstream considers acceptable? Does it align with
our bug severity important or higher? Do they test thoroughly? Etc...

> series, and I also think that our users would be better served if they
> could have the latest version of this series in Buster, rather than what
> I'm doing now: only patching 18.09.1 with whatever bug was reported in
> Debian and marked RC, and ignoring all the other bugs that were reported
> and fixed upstream.

I care for bugs that are reported in the Debian BTS, but that doesn't
mean that it's all we care about. We have had multiple unblock requests
where the maintainer was evaluating the changes done upstream and
convinced themselves that they all qualified. By doing the evaluation
they were often able to convince us. In some cases they didn't. I can
only assume that a lot of unblock requests were not filed because the
maintainer couldn't convince themselves.

> Hence I'd like to ask the release team if they think it would be
> suitable to unblock docker.io to allow the version 18.09.6 to be
> uploaded in Buster? Or, better, wait for the next 18.09.7 that will
> include the CVE fix, probably in the next days?

Upstream releases are not acceptable at this moment in the release.
After what I wrote above, obviously with the exception where you can
convince yourself and us that *everything* in the release is qualifying
our freeze criteria [freeze-policy]. However, if at this moment in the
freeze [last-weeks] you need so many changes, I seriously wonder if your
package should be in buster (in general, not necessarily valid for
docker.io)

> Or should I just stick to 18.09.1, and only upload a new debian version
> that only includes the CVE fix?

You'll get an unblock much easier.

Paul

[freeze-policy] https://release.debian.org/buster/freeze_policy.html
[last-weeks]
https://lists.debian.org/debian-devel-announce/2019/06/msg3.html



signature.asc
Description: OpenPGP digital signature


Bug#929908: unblock: tomcat9/9.0.16-4

2019-06-13 Thread Paul Gevers
Control: tags -1 moreinfo confirmed

Hi Emmanuel,

> unblock tomcat9/9.0.16-4

Please upload the package soon and remove the moreinfo tag when it can
be unblocked.

Thanks.

Paul



signature.asc
Description: OpenPGP digital signature


Processed: Re: Bug#929908: unblock: tomcat9/9.0.16-4

2019-06-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 moreinfo confirmed
Bug #929908 [release.debian.org] unblock: tomcat9/9.0.16-4
Added tag(s) confirmed and moreinfo.

-- 
929908: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929908
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems