Bug#864619: marked as done (RM: flashplugin-nonfree-extrasound/0.0.svn2431-6)

[Debian Bug Tracking System]

Your message dated Mon, 12 Jun 2017 22:27:10 +
with message-id 
and subject line remove flashplugin-nonfree-extrasound
has caused the Debian Bug report #864619,
regarding RM: flashplugin-nonfree-extrasound/0.0.svn2431-6
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.)


-- 
864619: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864619
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: rm

flashplugin-nonfree-extrasound should be removed from stretch since:
- the functionality of the package is adding Esound (removed from
  Debian several releases ago) and OSS (mostly obsolete on Linux,
  src:oss4 is not in stretch) support to Flash,
- looking at bugs like #573846 it is unclear whether it still works at all,
- and flashplugin-nonfree was recently removed from stretch
--- End Message ---
--- Begin Message ---
Added removal hint for flashplugin-nonfree-extrasound.--- End Message ---

Bug#864617: marked as done (RM: vtkdata/5.8.0-1)

[Debian Bug Tracking System]

Your message dated Mon, 12 Jun 2017 22:25:19 +
with message-id 
and subject line remove vtkdata
has caused the Debian Bug report #864617,
regarding RM: vtkdata/5.8.0-1
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.)


-- 
864617: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: rm

The maintainer filed RC bug
  #864452 vtkdata: do not ship in stretch
vtkdata is useless with vtk (5.8) gone. There is vtk6 in stretch.

There are no dependency problems.

Andreas
--- End Message ---
--- Begin Message ---
Added removal hint for vtkdata.--- End Message ---

Bug#864617: RM: vtkdata/5.8.0-1

[Andreas Beckmann]

On 2017-06-11 20:04, Adrian Bunk wrote:
> On Sun, Jun 11, 2017 at 07:28:55PM +0200, Andreas Beckmann wrote:
>> Package: release.debian.org
>> Severity: normal
>> Tags: stretch
>> User: release.debian@packages.debian.org
>> Usertags: rm
>>
>> The maintainer filed RC bug
>>   #864452 vtkdata: do not ship in stretch
>> ...
> 
> This RC bug does *not* come from the maintainer. [1]

Correct, but from an uploader of the team maintained (and now removed)
src:vtk package, that was supposedly the former user of that package.
Given the last upload in 2012, vtkdata was probably never brought under
team maintenance.


Andreas

Re: unblocking for stretch point release?

[Jonathan Wiltshire]

Hi,

On 2017-06-12 18:46, Andreas Metzler wrote:

I first understood the latest mail to -announce ("Planned release of
stretch") to mean that propagation from sid to stretch is not possible
anymore (except for critical fixes).


Correct.

However now that I am in a position of wanting to get something into 
the

1st point release I am wondering whether that is true (and I need to
prepare an additional upload for proposed updated) or whether
propagation from sid to stretch r1 is possible.


Please wait for the release, and then follow the usual procedure [1] for 
a stable update.
You can prepare the upload and open the bug now if you like, but it 
won't get a response for a while yet.


1: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: otrs2_3.3.9-3+deb8u1_amd64.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_merged.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_arm64.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_armel.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_armhf.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_i386.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_mips.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_mipsel.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_powerpc.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_ppc64el.changes
  ACCEPT
Processing changes file: perl_5.20.2-3+deb8u7_s390x.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_allonly.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_amd64.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_arm64.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_armel.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_armhf.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_i386.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_mips.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_mipsel.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_powerpc.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_ppc64el.changes
  ACCEPT
Processing changes file: sudo_1.8.10p3-1+deb8u4_s390x.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_amd64.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_arm64.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_armel.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_armhf.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_i386.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_mips.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_mipsel.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_powerpc.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_ppc64el.changes
  ACCEPT
Processing changes file: tnef_1.4.9-1+deb8u3_s390x.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_amd64.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_arm64.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_armel.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_armhf.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_i386.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_mips.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_mipsel.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_powerpc.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_ppc64el.changes
  ACCEPT
Processing changes file: zookeeper_3.4.5+dfsg-2+deb8u2_s390x.changes
  ACCEPT

unblocking for stretch point release?

[Andreas Metzler]

Hello,

I first understood the latest mail to -announce ("Planned release of
stretch") to mean that propagation from sid to stretch is not possible
anymore (except for critical fixes).

However now that I am in a position of wanting to get something into the
1st point release I am wondering whether that is true (and I need to
prepare an additional upload for proposed updated) or whether
propagation from sid to stretch r1 is possible.

cu Andreas
PS: (Just for completeness sake: This mail was triggered by Gnutls
CVE-2017-7507.)
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Processed: Re: Bug#864655: stretch-pu: package trafficserver/7.0.0-5+deb9u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + stretch moreinfo
Bug #864655 [release.debian.org] stretch-pu: package 
trafficserver/7.0.0-5+deb9u1
Added tag(s) moreinfo and stretch.

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

Bug#864655: stretch-pu: package trafficserver/7.0.0-5+deb9u1

[Adam D. Barratt]

Control: tags -1 + stretch moreinfo

On 2017-06-12 14:58, Aron Xu wrote:

I'd like to apply the attached patch as first pu for trafficserver in
stretch, it fixes the build on kfreebsd and arm architectures.


It doesn't look like any of those changes have made it to unstable yet; 
tagging appropriately.


By "arm architectures", I assume in practice you mean armel? There 
appear to be arm64 and armhf packages in the archive already.


Regards,

Adam

Bug#864655: stretch-pu: package trafficserver/7.0.0-5+deb9u1

[Aron Xu]

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

I'd like to apply the attached patch as first pu for trafficserver in
stretch, it fixes the build on kfreebsd and arm architectures.


Regards,
Aron
diff --git a/debian/changelog b/debian/changelog
index 8c25b126..7ff51263 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+trafficserver (7.0.0-5+deb9u1) UNRELEASED; urgency=medium
+
+  * Update d/rules to reflect healthcheck being managed as a stable plugin
+  * Add a patch to fix kfreebsd build
+  * Add a patch to fix arm build
+
+ -- Jean Baptiste Favre   Mon, 29 May 2017 14:45:52 +0200
+
 trafficserver (7.0.0-5) unstable; urgency=medium
 
   * Add patch to fix arm* build. (Closes: #857389)
diff --git a/debian/patches/0007-fix_build_kfreebsd.patch 
b/debian/patches/0007-fix_build_kfreebsd.patch
new file mode 100644
index ..46f4ac8d
--- /dev/null
+++ b/debian/patches/0007-fix_build_kfreebsd.patch
@@ -0,0 +1,39 @@
+Description: Fix kfreebsd build skipping malloc_np.h include
+Author: Jean Baptiste Favre 
+Origin: other
+Last-Update: 2017-03-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/ts/ink_memory.cc
 b/lib/ts/ink_memory.cc
+@@ -27,7 +27,7 @@
+ #include "ts/Diags.h"
+ #include "ts/ink_atomic.h"
+ 
+-#if defined(freebsd)
++#if !defined(kfreebsd) && defined(freebsd)
+ #include  // for malloc_usable_size
+ #endif
+ 
+--- a/proxy/Plugin.cc
 b/proxy/Plugin.cc
+@@ -124,7 +124,7 @@ plugin_load(int argc, char *argv[], bool validateOnly)
+   return false; // this line won't get called since Fatal brings down ATS
+ }
+ 
+-#if defined(freebsd) || defined(darwin)
++#if (!defined(kfreebsd) && defined(freebsd)) || defined(darwin)
+ optreset = 1;
+ #endif
+ #if defined(__GLIBC__)
+--- a/proxy/http/remap/RemapConfig.cc
 b/proxy/http/remap/RemapConfig.cc
+@@ -902,7 +902,7 @@ remap_load_plugin(const char **argv, int argc, url_mapping 
*mp, char *errbuf, in
+   void *ih = NULL;
+   TSReturnCode res = TS_SUCCESS;
+   if (pi->fp_tsremap_new_instance) {
+-#if defined(freebsd) || defined(darwin)
++#if (!defined(kfreebsd) && defined(freebsd)) || defined(darwin)
+ optreset = 1;
+ #endif
+ #if defined(__GLIBC__)
diff --git a/debian/patches/0008-fix_build_armel.patch 
b/debian/patches/0008-fix_build_armel.patch
new file mode 100644
index ..4b12a506
--- /dev/null
+++ b/debian/patches/0008-fix_build_armel.patch
@@ -0,0 +1,42 @@
+--- a/plugins/header_rewrite/lulu.h
 b/plugins/header_rewrite/lulu.h
+@@ -48,9 +48,36 @@ uint16_t getPort(sockaddr const *s_socka
+ #define rmb() __asm__ __volatile__("sync" : : : "memory")
+ #define wmb() __asm__ __volatile__("" : : : "memory")
+ #elif defined(__arm__)
+-#define mb() __asm__ __volatile__("dmb" : : : "memory")
+-#define rmb() __asm__ __volatile__("dmb" : : : "memory")
+-#define wmb() __asm__ __volatile__("" : : : "memory")
++  #if defined(__ARM_ARCH_4__) \
++ || defined(__ARM_ARCH_4T__) \
++ || defined(__ARM_ARCH_5__) \
++ || defined(__ARM_ARCH_5E__)  \
++ || defined(__ARM_ARCH_5T__) \
++ || defined(__ARM_ARCH_5TE__) \
++ || defined(__ARM_ARCH_5TEJ__) \
++ || defined(__ARM_ARCH_6__) \
++ || defined __ARM_ARCH_6J__  \
++ || defined(__ARM_ARCH_6K__) \
++ || defined(__ARM_ARCH_6Z) \
++ || defined(__ARM_ARCH_6ZK__) \
++ || defined(__ARM_ARCH_6T2__)
++#if defined(__thumb__)
++  // This is just a placeholder and almost certainly not sufficient.
++  #define mb() __asm__ __volatile__ ("" : : : "memory");
++  #define rmb() __asm__ __volatile__("" : : : "memory")
++  #define wmb() __asm__ __volatile__("" : : : "memory")
++#else // defined(__thumb__)
++  int a = 0, b = 0;
++  #define mb() __asm__ __volatile__ ("mcr p15,0,%0,c7,c10,5" : : "r" (0) 
: "memory")
++  #define rmb() mb()
++  #define wmb() __asm__ __volatile__("" : : : "memory")
++#endif // defined(__thumb__)
++  #else
++// ARMv7 and later.
++#define mb() __asm__ __volatile__("dmb" : : : "memory")
++#define rmb() __asm__ __volatile__("dmb" : : : "memory")
++#define wmb() __asm__ __volatile__("" : : : "memory")
++  #endif
+ #elif defined(__mips__)
+ #define mb() __asm__ __volatile__("sync" : : : "memory")
+ #define rmb() __asm__ __volatile__("sync" : : : "memory")
diff --git a/debian/patches/series b/debian/patches/series
index e3a27b9c..9916d6ef 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -11,3 +11,5 @@
 0004-force-use-luajit-system-remove-lib-luajit.patch
 0005-fix_documentation_build.patch
 0006-fix_arm_build.patch
+0007-fix_build_kfreebsd.patch
+0008-fix_build_armel.patch
diff --git a/debian/rules b/debian/rules
index 2c8a1169..8f33657f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,7 @@ override_dh_auto_install:
 ifneq ($(DEB_HOST_ARCH_OS),linux)
# Remove Linux-specific plugin

Bug#864650: transition: mumps

[Drew Parsons]

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

With stretch released, we plan to upgrade our numerical computational
packages:
scalapack to 2.0.2
mumps to 5.1.1
scotch to 6.0
etc

This transition request concerns mumps. It has been behaving itself in
experimental and is enthusiastic to play with the big kids in unstable.

Ben file:

title = "mumps";
is_affected = .depends ~ "libmumps-4.10.0" | .depends ~ "libmumps-5.1.1";
is_good = .depends ~ "libmumps-5.1.1";
is_bad = .depends ~ "libmumps-4.10.0";


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

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

Processed: closing 797462

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 797462
Bug #797462 [release.debian.org] jessie-pu: package whois/5.2.10
Marked Bug as done
> thanks
Stopping processing here.

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

Bug#860967: marked as done (release.debian.org: discourage unblock requests for targeted fixes for RC bugs)

[Debian Bug Tracking System]

Your message dated Mon, 12 Jun 2017 05:59:00 +
with message-id <8bdbd3d9-e848-77aa-7445-94ede9f13...@thykier.net>
and subject line Re: Bug#860967: release.debian.org: discourage unblock 
requests for targeted fixes for RC bugs
has caused the Debian Bug report #860967,
regarding release.debian.org: discourage unblock requests for targeted fixes 
for RC bugs
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.)


-- 
860967: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860967
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal

Hello release team,

Niels told me on IRC that the release team would prefer not to receive
an unblock request for targeted fixes of RC bugs, because they check the
list of RC bugs in testing with fixes in unstable regularly, and so the
unblock request is merely communications overhead.  The only exception
is for packages with udebs, as the unblock request is a place to request
an ACK from d-i.

It would be useful to have this info in the freeze policy, or somewhere
else in release.d.o.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Sean Whitton:
> Package: release.debian.org
> Severity: normal
> 
> Hello release team,
> 
> Niels told me on IRC that the release team would prefer not to receive
> an unblock request for targeted fixes of RC bugs, because they check the
> list of RC bugs in testing with fixes in unstable regularly, and so the
> unblock request is merely communications overhead.  The only exception
> is for packages with udebs, as the unblock request is a place to request
> an ACK from d-i.
> 
> It would be useful to have this info in the freeze policy, or somewhere
> else in release.d.o.
> 
> [...]

Hi,


I have thought some more about it.  While it could be a minor
optimization of our workflow, it has some corner cases, where this
change would be actively harmful.

So I retract the idea and leave the workflow at the current "file an
unblock request if you want it to migrate".

Thanks,
~Niels--- End Message ---