Re: wheezy-security to wheezy-lts transition

[Guido Günther]

Hi Mortiz,
On Mon, Feb 22, 2016 at 11:28:48PM +0100, Moritz Mühlenhoff wrote:
> On Mon, Feb 22, 2016 at 06:42:20PM +0100, Guido Günther wrote:
> > Hi Adam,
> > On Sat, Feb 20, 2016 at 02:27:27PM +, Adam D. Barratt wrote:
> > > [apologies to anyone who's ended up with three copies of this; the
> > > original got eaten due to a misconfiguration on my side - please only
> > > reply to this copy]
> > > 
> > > Hi,
> > > 
> > > As I understand it, the plan is for wheezy-lts to re-use
> > > security.d.o:wheezy/updates directly, rather than a separate suite on
> > > ftp-master. Is that correct?
> > 
> > I think so. See
> > 
> > 
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=prep-wheezy-lts;users=debian-...@lists.debian.org
> 
> While these two are long-standing enhancement bugs which would make
> the security team work much easier, they are unrelated to the plan
> outlined above.

I'm confused now. Arent these two bugs requirements to implement 
1) and 3) from Raphael's BoF summary:

   1/ the ftpmasters would reconfigure the suite to drop the "policy queue"
   in front of the repositories so that uploads are immediately accepted
   exactly like the current squeeze-lts repository (Ansgar told us this
   was easy to do)
   This solves problems 4 and 1 because LTS members no longer need shell
   access if there is "approval" step in the workflow.

   3/ the ftpmasters will fix dak to also send the ACCEPTED mails to the
   person who signed the upload (this was already part of their plans
   even before this discussion, this now gives them one reason more
   to actually do it before the Wheezy LTS period start, aka in February
   2016)

> That plan was mentioned during the DebConf BoF, but I'm not aware that anyone
> is working on that and I'm unsure whether it's feasible to implement
> in time?

> Especially since even far simpler changes like the two mentioned above are
> open for quite a long time.

I'm happy to help here but besides setting up my own dak and testing the
provided patches I'm not sure how.

Cheers,
 -- Guido

Processed: Re: Bug#815613: wheezy-pu: package clamav/0.99+dfsg-0+deb7u2

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #815613 [release.debian.org] wheezy-pu: package clamav/0.99+dfsg-0+deb7u2
Added tag(s) confirmed.

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

Bug#815613: wheezy-pu: package clamav/0.99+dfsg-0+deb7u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2016-02-22 at 23:18 +0100, Sebastian Andrzej Siewior wrote:
> In order to address the Sparc fallout in the Wheezy update (#814544),
> here is the fix. This patch is also part of last unstable upload
> (0.99+dfsg-2) and pending for Jessie (0.99+dfsg-0+deb8u2, #815598).

Please go ahead.

Regards,

Adam

Re: wheezy-security to wheezy-lts transition

[Moritz Mühlenhoff]

On Mon, Feb 22, 2016 at 06:42:20PM +0100, Guido Günther wrote:
> Hi Adam,
> On Sat, Feb 20, 2016 at 02:27:27PM +, Adam D. Barratt wrote:
> > [apologies to anyone who's ended up with three copies of this; the
> > original got eaten due to a misconfiguration on my side - please only
> > reply to this copy]
> > 
> > Hi,
> > 
> > As I understand it, the plan is for wheezy-lts to re-use
> > security.d.o:wheezy/updates directly, rather than a separate suite on
> > ftp-master. Is that correct?
> 
> I think so. See
> 
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=prep-wheezy-lts;users=debian-...@lists.debian.org

While these two are long-standing enhancement bugs which would make
the security team work much easier, they are unrelated to the plan
outlined above.

That plan was mentioned during the DebConf BoF, but I'm not aware that anyone
is working on that and I'm unsure whether it's feasible to implement in time?

Especially since even far simpler changes like the two mentioned above are
open for quite a long time.

Cheers,
Moritz

Bug#815613: wheezy-pu: package clamav/0.99+dfsg-0+deb7u2

[Sebastian Andrzej Siewior]

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

In order to address the Sparc fallout in the Wheezy update (#814544),
here is the fix. This patch is also part of last unstable upload
(0.99+dfsg-2) and pending for Jessie (0.99+dfsg-0+deb8u2, #815598).

Sebastian
diff -Nru clamav-0.99+dfsg/debian/changelog clamav-0.99+dfsg/debian/changelog
--- clamav-0.99+dfsg/debian/changelog   2016-02-18 04:02:24.0 +0100
+++ clamav-0.99+dfsg/debian/changelog   2016-02-22 23:06:12.0 +0100
@@ -1,3 +1,10 @@
+clamav (0.99+dfsg-0+deb7u2) oldstable; urgency=medium
+
+  * Add libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch to get the
+testsuite passed on sparc. It also seem avoid invalid loads on ARMv5 cpus.
+
+ -- Sebastian Andrzej Siewior   Mon, 22 Feb 2016 
23:05:03 +0100
+
 clamav (0.99+dfsg-0+deb7u1) oldstable; urgency=medium
 
   [ Andreas Cadhalpun ]
diff -Nru clamav-0.99+dfsg/debian/.git-dpm clamav-0.99+dfsg/debian/.git-dpm
--- clamav-0.99+dfsg/debian/.git-dpm2016-02-12 20:46:38.0 +0100
+++ clamav-0.99+dfsg/debian/.git-dpm2016-02-22 23:06:12.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-94ee2eaadaedd8160a123737fa554be6acb8b761
-94ee2eaadaedd8160a123737fa554be6acb8b761
+b470f97a68f64348adbd019ffcbff49fe155454f
+b470f97a68f64348adbd019ffcbff49fe155454f
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 clamav_0.99+dfsg.orig.tar.xz
diff -Nru 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
--- 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  1970-01-01 01:00:00.0 +0100
+++ 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  2016-02-22 23:06:12.0 +0100
@@ -0,0 +1,94 @@
+From b470f97a68f64348adbd019ffcbff49fe155454f Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Sat, 20 Feb 2016 15:53:48 +0100
+Subject: libclamav: yara: avoid unaliged access to 64bit variable
+
+The derefence of an unaligned 64bit variable results in a SIGBUS abort
+on 32bit SPARC. ARMv5 CPUs seem to perform the load but load garbish.
+This memcpy() workaround forces the compiler to do something that works
+on even if the data was not properly aligned. For X86 it means no
+change. ARM on other hand will produce slightly different code depending
+on the CPU used.
+
+Patch-Name: libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ libclamav/yara_exec.c | 18 +-
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/libclamav/yara_exec.c b/libclamav/yara_exec.c
+index dbd7ae8..808a030 100644
+--- a/libclamav/yara_exec.c
 b/libclamav/yara_exec.c
+@@ -184,7 +184,7 @@ int yr_execute_code(
+ #endif
+ 
+   case OP_PUSH:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(r1);
+ break;
+@@ -194,38 +194,38 @@ int yr_execute_code(
+ break;
+ 
+   case OP_CLEAR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1] = 0;
+ break;
+ 
+   case OP_ADD_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ mem[r1] += r2;
+ break;
+ 
+   case OP_INCR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1]++;
+ break;
+ 
+   case OP_PUSH_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(mem[r1]);
+ break;
+ 
+   case OP_POP_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(mem[r1]);
+ break;
+ 
+   case OP_SWAPUNDEF:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ if (r2 != UNDEFINED)
+@@ -540,7 +540,7 @@ int yr_execute_code(
+ 
+ // r1 = number of arguments
+ 
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ // pop arguments from stack and copy them to args array
+@@ -854,7 +854,7 @@ int yr_execute_code(
+ 
+ #if REAL_YARA //not supported ClamAV
+   case OP_IMPORT:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ FAIL_ON_ERROR(yr_modules_load(

Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Sebastian Andrzej Siewior]

On 2016-02-22 21:43:45 [+], Adam D. Barratt wrote:
> Please go ahead.
Thanks, done.

> Regards,
> 
> Adam

Sebastian

Bug#807274: wheezy-pu: package ca-certificates/20130119+deb7u2

[Michael Shuler]

On 02/20/2016 06:53 AM, Adam D. Barratt wrote:
> For reference, neither the above nor the message opening the bug made it
> to debian-release, presumably for size reasons.

Thanks for the follow up.

> Looking at the diff:
> 
> diff -Nru ca-certificates-20130119+deb7u1/debian/config 
> ca-certificates-20130119+deb7u2/debian/config
> --- ca-certificates-20130119+deb7u1/debian/config 2014-09-24 
> 12:57:57.0 -0500
> +++ ca-certificates-20130119+deb7u2/debian/config 1969-12-31 
> 18:00:00.0 -0600
> 
> I'm assuming that wasn't intentional?

This is the unintentional result of building from a clean git checkout.
I'll have to pull the old generated debian/config from the existing
source package. This file has since been added to the clean target.

This Wheezy package is going to suffer from the same regression as in
Jessie, currently. Please, leave this bug report in "moreinfo", if
that's OK, or just close this and I'll open a new report. I will need to
create an updated diff that includes the removed 1024-bit CA
certificates, once I'm sure that's working correctly in Jessie.

-- 
Kind regards,
Michael

Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2016-02-22 at 22:09 +0100, Sebastian Andrzej Siewior wrote:
> In order to address the Sparc fallout in the Wheezy update (#814544), here
> is the fix for Jessie. This patch is also part of last unstable upload
> (0.99+dfsg-2).

Please go ahead.

Regards,

Adam

Processed: Re: Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #815598 [release.debian.org] jessie-pu: package clamav/0.99+dfsg-0+deb8u2
Added tag(s) confirmed.

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

Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Sebastian Andrzej Siewior]

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

In order to address the Sparc fallout in the Wheezy update (#814544), here
is the fix for Jessie. This patch is also part of last unstable upload
(0.99+dfsg-2).

Sebastian
diff -Nru clamav-0.99+dfsg/debian/changelog clamav-0.99+dfsg/debian/changelog
--- clamav-0.99+dfsg/debian/changelog   2015-12-14 21:44:42.0 +0100
+++ clamav-0.99+dfsg/debian/changelog   2016-02-22 21:15:44.0 +0100
@@ -1,3 +1,10 @@
+clamav (0.99+dfsg-0+deb8u2) stable; urgency=medium
+
+  * Add libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch to get the
+testsuite passed on sparc. It also seem avoid invalid loads on ARMv5 cpus.
+
+ -- Sebastian Andrzej Siewior   Mon, 22 Feb 2016 
21:12:51 +0100
+
 clamav (0.99+dfsg-0+deb8u1) stable; urgency=medium
 
   [ Andreas Cadhalpun ]
diff -Nru clamav-0.99+dfsg/debian/.git-dpm clamav-0.99+dfsg/debian/.git-dpm
--- clamav-0.99+dfsg/debian/.git-dpm2015-12-11 21:20:24.0 +0100
+++ clamav-0.99+dfsg/debian/.git-dpm2016-02-22 21:15:44.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-1cc3015d9abdb6a121251aab899dc1baf3117baf
-1cc3015d9abdb6a121251aab899dc1baf3117baf
+bbc0790fa239ec754ca1693244acacd2e55f97b5
+bbc0790fa239ec754ca1693244acacd2e55f97b5
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 clamav_0.99+dfsg.orig.tar.xz
diff -Nru 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
--- 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  1970-01-01 01:00:00.0 +0100
+++ 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  2016-02-22 21:15:44.0 +0100
@@ -0,0 +1,94 @@
+From bbc0790fa239ec754ca1693244acacd2e55f97b5 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Sat, 20 Feb 2016 15:53:48 +0100
+Subject: libclamav: yara: avoid unaliged access to 64bit variable
+
+The derefence of an unaligned 64bit variable results in a SIGBUS abort
+on 32bit SPARC. ARMv5 CPUs seem to perform the load but load garbish.
+This memcpy() workaround forces the compiler to do something that works
+on even if the data was not properly aligned. For X86 it means no
+change. ARM on other hand will produce slightly different code depending
+on the CPU used.
+
+Patch-Name: libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ libclamav/yara_exec.c | 18 +-
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/libclamav/yara_exec.c b/libclamav/yara_exec.c
+index dbd7ae8..808a030 100644
+--- a/libclamav/yara_exec.c
 b/libclamav/yara_exec.c
+@@ -184,7 +184,7 @@ int yr_execute_code(
+ #endif
+ 
+   case OP_PUSH:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(r1);
+ break;
+@@ -194,38 +194,38 @@ int yr_execute_code(
+ break;
+ 
+   case OP_CLEAR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1] = 0;
+ break;
+ 
+   case OP_ADD_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ mem[r1] += r2;
+ break;
+ 
+   case OP_INCR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1]++;
+ break;
+ 
+   case OP_PUSH_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(mem[r1]);
+ break;
+ 
+   case OP_POP_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(mem[r1]);
+ break;
+ 
+   case OP_SWAPUNDEF:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ if (r2 != UNDEFINED)
+@@ -540,7 +540,7 @@ int yr_execute_code(
+ 
+ // r1 = number of arguments
+ 
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ // pop arguments from stack and copy them to args array
+@@ -854,7 +854,7 @@ int yr_execute_code(
+ 
+ #if REAL_YARA //not supported ClamAV
+   case OP_IMPORT:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ FAIL_ON_ERROR(yr_modules_load(
diff -Nru clamav-0.99+dfsg/debian/patches/series 

Re: wheezy-security to wheezy-lts transition

[Adam D. Barratt]

On Mon, 2016-02-22 at 18:42 +0100, Guido Günther wrote:
> Hi Adam,
> On Sat, Feb 20, 2016 at 02:27:27PM +, Adam D. Barratt wrote:
[...]
> > If so then we need to consider how the transition works in the short
> > term. For example, the final point release of oldstable occurs after
> > security support ceases, so that we can fold in as many of the remaining
> > packages from the security archive as possible, including those that
> > failed to build on some architectures originally - it would be confusing
> > if we ended up pulling in any packages that were actually from
> > wheezy-lts, or even having those appear in oldstable-new.
> 
> What would that involve? A flag day when the usual uploads to s.d.o for
> wheezy stop and the point release is made? Or can we just stop
> forwarding packages to oldstable-new at that day and that point release
> can happen at a later date while the LTS uploads to s.d.o already start?

I was assuming the latter. Some input from ftp-master and the Security
Team r.e. feasibility would be helpful there.

Regards,

Adam

Bug#815517: jessie-pu: package unbound/1.4.22-3+deb8u1

[Robert Edmonds]

Adam D. Barratt wrote:
> On 2016-02-22 0:09, Robert Edmonds wrote:
> >diff --git a/debian/changelog b/debian/changelog
> >index af91f28..2c6d115 100644
> >--- a/debian/changelog
> >+++ b/debian/changelog
> >@@ -1,3 +1,10 @@
> >+unbound (1.4.22-3+deb8u1) jessie; urgency=medium
> >+
> >+  * iterator/iter_hints.c: Update hints for H.ROOT-SERVERS.NET
> >+(Closes: #815370)
> 
> Please go ahead.

Uploaded, thanks!

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

Bug#815036: transition: msgpack-c

[Emilio Pozuelo Monfort]

Tracker at https://release.debian.org/transitions/html/msgpack-c.html

On 21/02/16 16:54, James McCoy wrote:
> On Wed, Feb 17, 2016 at 11:46:53PM -0500, James McCoy wrote:
>> FTBFS:
>>
>> * webdis:
>>   + #811343 filed with patch
>> * tmate:
>>   + New upstream version is needed
>>   + Will file a bug for this
> 
> Filed #815381.
> 
>> * kumofs:
>>   + configure script expects the C++ library (libmsgpack) and therefore
>> fails
>>   + Trivial patch to remove that expectation leads to a compile failure
>> due to mixing code with C and C++ linkage
>>   + No upstream activity in 5+ years
>>   + Debian maintainer MIA
> 
> Given the above and a popcon of 5, should an RM bug be filed?

Yeah I'd say so.

Emilio

Bug#812887: transition: iptables

[Emilio Pozuelo Monfort]

On 21/02/16 19:39, Andreas Henriksson wrote:
> Hello!
> 
> On Sun, Feb 07, 2016 at 04:23:25PM +, Jonathan Wiltshire wrote:
>> On Wed, Jan 27, 2016 at 04:58:41PM +0100, Arturo Borrero Gonzalez wrote:
>>> iptables 1.6.0 has been released and we plan to include it in debian.
>>>
>>> The libxtables binary package name has been changed from libxtables10 to
>>> libxtables11. However, this change seems to affect very few packages (if 
>>> any).
>>>
>>> Since an upload to experimental was done, a transition was set up [0].
>>> Following the instructions [1] for transition, I've build-tested all
>>> reverse build-deps of iptables and they seem to build simply fine:
>>>
>>>  * xtables-addons: no problems
>>>  * connman: no problems
>>>  * west-chamer: no problems
>>>
>>> So, I ask for a transition slot to upload iptables 1.6.0 to unstable.
>>
>> The transition completed.
> 
> Please also binNMU iproute2 to build against the new libxtables and
> pick up a new recommends, or the 'ipt' module will be/stay broken.

Scheduled.

Cheers,
Emilio

Re: wheezy-security to wheezy-lts transition

[Guido Günther]

Hi Adam,
On Sat, Feb 20, 2016 at 02:27:27PM +, Adam D. Barratt wrote:
> [apologies to anyone who's ended up with three copies of this; the
> original got eaten due to a misconfiguration on my side - please only
> reply to this copy]
> 
> Hi,
> 
> As I understand it, the plan is for wheezy-lts to re-use
> security.d.o:wheezy/updates directly, rather than a separate suite on
> ftp-master. Is that correct?

I think so. See


https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=prep-wheezy-lts;users=debian-...@lists.debian.org

> If so then we need to consider how the transition works in the short
> term. For example, the final point release of oldstable occurs after
> security support ceases, so that we can fold in as many of the remaining
> packages from the security archive as possible, including those that
> failed to build on some architectures originally - it would be confusing
> if we ended up pulling in any packages that were actually from
> wheezy-lts, or even having those appear in oldstable-new.

What would that involve? A flag day when the usual uploads to s.d.o for
wheezy stop and the point release is made? Or can we just stop
forwarding packages to oldstable-new at that day and that point release
can happen at a later date while the LTS uploads to s.d.o already start?

The planned date for wheezy LTS to start is 26th of April:

https://wiki.debian.org/LTS

Cheers,
 -- Guido

Bug#796947: jessie-pu: package s3ql/2.11.1+dfsg-2

[Nikolaus Rath]

On Feb 20 2016, Julien Cristau  wrote:
> On Sat, Aug 29, 2015 at 13:46:54 -0700, Nikolaus Rath wrote:
>> On Aug 29 2015, "Adam D. Barratt"  wrote:
>> > On Tue, 2015-08-25 at 19:29 -0700, Nikolaus Rath wrote:
>> >> Would it be acceptible to upload a fix for #792685 to jessie?
>> >> 
>> >> In short, the S3QL version currently in jessie is unable to read file
>> >> system created with the S3QL version in wheezy. All stored data thus
>> >> becomes inaccessible unless one installs an intermediate version (that
>> >> is currently not available in Debian).
>> >> 
>> >> The proposed patch forward-ports the necessary capability from an
>> >> intermediate S3QL version.
>> >> 
>> >> An update package can be downloaded from
>> >> http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_2.11.1+dfsg-3.dsc
>> >
>> > Can we have a debdiff of the proposed package against the s3ql version
>> > currently in Jessie, please?
>> 
>> Here it is.
>> 
> Sorry for the delay.  Please adjust the changelog entry's distribution
> to say "jessie", not "jessie-updates", and then feel free to upload.

Just uploaded to ftp-master.


Thanks,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Processed: forcibly merging 811031 815235

[Debian Bug Tracking System]

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

> forcemerge 811031 815235
Bug #811031 [fglrx-driver] fglrx-driver: missing support for xserver 1.18 
(xorg-video-abi-20)
Bug #811031 [fglrx-driver] fglrx-driver: missing support for xserver 1.18 
(xorg-video-abi-20)
Marked as found in versions fglrx-driver/1:15.12-2.
Bug #815235 [fglrx-driver] [fglrx-driver] Remove if install xserver-xorg-core 
1.8.1-1
808735 was blocked by: 811031
808735 was not blocking any bugs.
Added blocking bug(s) of 808735: 815235
Marked as found in versions fglrx-driver/1:15.9-4.
Added tag(s) stretch, upstream, and sid.
Merged 811031 815235
> thanks
Stopping processing here.

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

Processed: Re: Bug#815520: jessie-pu: package fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #815520 [release.debian.org] jessie-pu: package 
fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1
Added tag(s) confirmed.
> clone -1 -2
Bug #815520 [release.debian.org] jessie-pu: package 
fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1
Bug 815520 cloned as bug 815561
> retitle -1 jessie-pu: package fglrx-driver/1:15.9-4~deb8u2
Bug #815520 [release.debian.org] jessie-pu: package 
fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1
Changed Bug title to 'jessie-pu: package fglrx-driver/1:15.9-4~deb8u2' from 
'jessie-pu: package fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1'
> retitle -2 xvba-video_0.8.0-9+deb8u1
Bug #815561 [release.debian.org] jessie-pu: package 
fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1
Changed Bug title to 'xvba-video_0.8.0-9+deb8u1' from 'jessie-pu: package 
fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1'

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

Bug#815520: jessie-pu: package fglrx-driver/1:15.9-4~deb8u2 xvba-video_0.8.0-9+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed
Control: clone -1 -2
Control: retitle -1 jessie-pu: package fglrx-driver/1:15.9-4~deb8u2
Control: retitle -2 xvba-video_0.8.0-9+deb8u1

On 2016-02-22 1:05, Andreas Beckmann wrote:

the last fglrx-driver update in jessie brought a small regression:
updates with xvba-va-driver installed fail due to a file overwrite
conflict (#813427).
xvba-va-driver is currently uninstallable in jessie.
xvba-va-driver is no longer needed as a separate package, instead
libfglrx-amdxvba1 brings equivalent files.

We need to update both packages to fix this issue.

The updated src:fglrx-driver package adds proper Breaks+Replaces 
against

the xvba-va-driver package currently in jessie.

The updated src:xvba-video package turns xvba-va-driver into an
installable empty dummy package. That's less intrusive than removing it
while ensuring that a clean upgrade path exists.

Let's do the discussion with this one bug here and clone it once it
reached confirmed state.


Looks okay to me.

Assuming that the install and upgrade paths have been tested (I imagine 
they have :-), please go ahead.



Regards,

Adam

Processed: Re: Bug#815517: jessie-pu: package unbound/1.4.22-3+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #815517 [release.debian.org] jessie-pu: package unbound/1.4.22-3+deb8u1
Added tag(s) confirmed.

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

Bug#815517: jessie-pu: package unbound/1.4.22-3+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2016-02-22 0:09, Robert Edmonds wrote:
The unbound package in jessie has outdated root DNS server address 
hints
for h.root-servers.net, see #815370. I'd like to upload a new version 
to

jessie with the following changes.

Thanks!

diff --git a/debian/changelog b/debian/changelog
index af91f28..2c6d115 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+unbound (1.4.22-3+deb8u1) jessie; urgency=medium
+
+  * iterator/iter_hints.c: Update hints for H.ROOT-SERVERS.NET
+(Closes: #815370)


Please go ahead.

Regards,

Adam

Bug#815526: marked as done (RM: nvidia-graphics-modules/304.131+3.2.0+1)

[Debian Bug Tracking System]

Your message dated Mon, 22 Feb 2016 10:02:56 +0100
with message-id <20160222090256.ga13...@betterave.cristau.org>
and subject line Re: Bug#815060: Encouraging removal of nvidia kernel modules 
from Debian non-free archive.
has caused the Debian Bug report #815526,
regarding RM: nvidia-graphics-modules/304.131+3.2.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.)


-- 
815526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815526
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ftp.debian.org, src:nvidia-graphics-modules
Severity: normal

The nvidia-graphics-modules provides pre-compiled non-free
kernel modules. Several lawyers and people believe this to
be a violation of the GPL license used by the kernel.

This interpretation is consistent with our position on ZFS
modules, which we also ship in source code only.

As such, the work is not distributable and should be
removed from the archive in all suites, ASAP.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.
--- End Message ---
--- Begin Message ---
On Mon, Feb 22, 2016 at 03:25:32 +0100, Andreas Beckmann wrote:

> Control: reassign -1 ftp.debian.org
> Control: clone -1 -2 -3
> Control: reassign -2 release.debian.org
> Control: tag -2 jessie
> Control: retitle -2 RM: nvidia-graphics-modules/340.96+3.16.0+1
> Control: reassign -3 release.debian.org
> Control: tag -3 wheezy
> Control: retitle -3 RM: nvidia-graphics-modules/304.131+3.2.0+1
> 
> Hi all,
> 
> thanks for your reasoning.
> 
> Bye-bye prebuilt modules.
> 
I'd rather we left (old)stable well alone.

Cheers,
Julien--- End Message ---

Bug#815525: marked as done (RM: nvidia-graphics-modules/340.96+3.16.0+1)

[Debian Bug Tracking System]

Your message dated Mon, 22 Feb 2016 10:02:56 +0100
with message-id <20160222090256.ga13...@betterave.cristau.org>
and subject line Re: Bug#815060: Encouraging removal of nvidia kernel modules 
from Debian non-free archive.
has caused the Debian Bug report #815525,
regarding RM: nvidia-graphics-modules/340.96+3.16.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.)


-- 
815525: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815525
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ftp.debian.org, src:nvidia-graphics-modules
Severity: normal

The nvidia-graphics-modules provides pre-compiled non-free
kernel modules. Several lawyers and people believe this to
be a violation of the GPL license used by the kernel.

This interpretation is consistent with our position on ZFS
modules, which we also ship in source code only.

As such, the work is not distributable and should be
removed from the archive in all suites, ASAP.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.
--- End Message ---
--- Begin Message ---
On Mon, Feb 22, 2016 at 03:25:32 +0100, Andreas Beckmann wrote:

> Control: reassign -1 ftp.debian.org
> Control: clone -1 -2 -3
> Control: reassign -2 release.debian.org
> Control: tag -2 jessie
> Control: retitle -2 RM: nvidia-graphics-modules/340.96+3.16.0+1
> Control: reassign -3 release.debian.org
> Control: tag -3 wheezy
> Control: retitle -3 RM: nvidia-graphics-modules/304.131+3.2.0+1
> 
> Hi all,
> 
> thanks for your reasoning.
> 
> Bye-bye prebuilt modules.
> 
I'd rather we left (old)stable well alone.

Cheers,
Julien--- End Message ---