Bug#798584: jessie-pu: package chrony/1.30-2+deb8u1

[Vincent Blut]

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

Hi,

Please accept chrony 1.30-2+deb8u1 for the next Jessie point release;
it fixes a missing build dependency on libcap-dev which prevent user
from configuring chronyd to drop root privileges. That would close
#768803.

diff -Nru chrony-1.30/debian/changelog chrony-1.30/debian/changelog
--- chrony-1.30/debian/changelog2015-04-10 11:43:39.0 +0200
+++ chrony-1.30/debian/changelog2015-09-09 20:00:38.0 +0200
@@ -1,3 +1,10 @@
+chrony (1.30-2+deb8u1) jessie; urgency=medium
+
+  * Build depend on libcap-dev. Without it, chronyd can’t drop root
+privileges. (Closes: #768803)
+
+ -- Vincent Blut   Wed, 09 Sep 2015 19:50:09 +0200
+
 chrony (1.30-2) unstable; urgency=medium

   * With the following security bugfixes (Closes: #782160):
diff -Nru chrony-1.30/debian/control chrony-1.30/debian/control
--- chrony-1.30/debian/control 2015-04-09 00:05:48.0 +0200
+++ chrony-1.30/debian/control 2015-09-09 19:35:25.0 +0200
@@ -8,7 +8,8 @@
  texinfo, bison,
  libedit-dev,
  libnss3-dev,
- libtomcrypt-dev
+ libtomcrypt-dev,
+ libcap-dev
 Homepage: http://chrony.tuxfamily.org
 Vcs-Git: git://anonscm.debian.org/collab-maint/chrony.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/chrony.git

Cheers,
Vincent

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Please dak copy-installer 20150911

[Cyril Brulebois]

Hi,

FTPmasters, please sync the installer from sid to testing:

  dak copy-installer 20150911


I've done that part on the release side:

  urgent debian-installer/20150911


Thanks for your time.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#791128: marked as done (libhmsbeagle: library transition may be needed when GCC 5 is the default)

[Debian Bug Tracking System]

Your message dated Thu, 10 Sep 2015 23:26:48 +0100
with message-id <20150910222648.ga32...@lupin.home.powdarrmonkey.net>
and subject line Re: Bug#791128: libhmsbeagle: library transition may be needed 
when GCC 5 is the default
has caused the Debian Bug report #791128,
regarding libhmsbeagle: library transition may be needed when GCC 5 is the 
default
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.)


-- 
791128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791128
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:libhmsbeagle
Version: 2.1.2-1
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
and dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

What is needed:

 - Rebuild the library using g++/g++-5 from experimental. Note that
   most likely all C++ libraries within the build dependencies need
   a rebuild too. You can find the log for a rebuild in
 https://people.debian.org/~doko/logs/gcc5-20150701/
   Search for "BEGIN GCC CXX11" in the log.

 - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
   library API, and are used by the reverse dependencies of the
   library.

 - If there are no symbols matching __cxx11 or B5cxx11 in the symbols
   forming the library API, you should close this issue with a short
   explanation.
 
 - If there are no reverse dependencies, it should be the package
   maintainers decision if a transition is needed.  However this might
   break software which is not in the Debian archive, and built
   against these packages.

 - If a library transition is needed, please prepare for the change.
   Rename the library package, append "v5" to the name of the package
   (e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you
   have a soversion bump and you upload this version instead of the
   renamed package.  Prepare a patch and attach it to this issue (mark
   this issue with patch), so that it is possible to NMU such a
   package. We'll probably have more than hundred transitions
   triggered. Then reassign the issue to release.debian.org and
   properly tag it as a transition issue, by sending an email to
   cont...@bugs.debian.org:
   
 user release.debian@packages.debian.org
 usertag  + transition
 block  by 790756
 reassign  release.debian.org
   
 - If unsure if a transition is needed, please tag the issue with help
   to ask for feedback from other Debian developers.

The libstdc++6 transition will be a large one, and it will come with a
lot of pain.  Please help it by preparing the follow-up transitions.

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
--- End Message ---
--- Begin Message ---
Completed.

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

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



signature.asc
Description: Digital signature
--- End Message ---

Bug#791312: marked as done (xapian-core: library transition may be needed when GCC 5 is the default)

[Debian Bug Tracking System]

Your message dated Thu, 10 Sep 2015 23:28:45 +0100
with message-id <20150910222845.ga32...@lupin.home.powdarrmonkey.net>
and subject line Re: Bug#791312: xapian-core: library transition may be needed 
when GCC 5 is the default
has caused the Debian Bug report #791312,
regarding xapian-core: library transition may be needed when GCC 5 is the 
default
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.)


-- 
791312: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791312
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:xapian-core
Version: 1.2.21-1
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
and dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

What is needed:

 - Rebuild the library using g++/g++-5 from experimental. Note that
   most likely all C++ libraries within the build dependencies need
   a rebuild too. You can find the log for a rebuild in
 https://people.debian.org/~doko/logs/gcc5-20150701/
   Search for "BEGIN GCC CXX11" in the log.

 - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
   library API, and are used by the reverse dependencies of the
   library.

 - If there are no symbols matching __cxx11 or B5cxx11 in the symbols
   forming the library API, you should close this issue with a short
   explanation.
 
 - If there are no reverse dependencies, it should be the package
   maintainers decision if a transition is needed.  However this might
   break software which is not in the Debian archive, and built
   against these packages.

 - If a library transition is needed, please prepare for the change.
   Rename the library package, append "v5" to the name of the package
   (e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you
   have a soversion bump and you upload this version instead of the
   renamed package.  Prepare a patch and attach it to this issue (mark
   this issue with patch), so that it is possible to NMU such a
   package. We'll probably have more than hundred transitions
   triggered. Then reassign the issue to release.debian.org and
   properly tag it as a transition issue, by sending an email to
   cont...@bugs.debian.org:
   
 user release.debian@packages.debian.org
 usertag  + transition
 block  by 790756
 reassign  release.debian.org
   
 - If unsure if a transition is needed, please tag the issue with help
   to ask for feedback from other Debian developers.

The libstdc++6 transition will be a large one, and it will come with a
lot of pain.  Please help it by preparing the follow-up transitions.

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
--- End Message ---
--- Begin Message ---
Completed.

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

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



signature.asc
Description: Digital signature
--- End Message ---

Processed: tagging 796668

[Debian Bug Tracking System]

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

> tags 796668 - pending
Bug #796668 [release.debian.org] transition: log4cplus
Removed tag(s) pending.
> thanks
Stopping processing here.

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

Bug#798589: s3ql: please allow migration to testing

[Nikolaus Rath]

Package: release.debian.org
Severity: normal

Hello,

The s3ql package is not migrating to testing. As far as I understand,
this is because it's not building on armhf.

However, I think it would be a lot better to have s3ql in testing for
the other archituctures than not to have it in testing at all (there is
no S3QL version in testing at the moment).

Is this intended behavior?

If so, is there a way to make an exception here and allow migration?

Thanks!
-Nikolaus

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

[Nikolaus Rath]

Hi,

Please note that the majority of the patch affects only the "s3qladm
upgrade" command which jessie users will either use once (and then it
will have failed for them and they need this patch), or never (because
they don't need it). So I think these changes have extremely little
change of introducing new bugs for jessie users.

Only the one-line change at the end of the diff actually affects code
that is used by jessie users.

Best,
-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.«

Bug#798589: marked as done (s3ql: please allow migration to testing)

[Debian Bug Tracking System]

Your message dated Thu, 10 Sep 2015 21:08:47 +0100
with message-id <20150910200847.gh3...@lupin.home.powdarrmonkey.net>
and subject line Re: Bug#798589: s3ql: please allow migration to testing
has caused the Debian Bug report #798589,
regarding s3ql: please allow migration to testing
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.)


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

Hello,

The s3ql package is not migrating to testing. As far as I understand,
this is because it's not building on armhf.

However, I think it would be a lot better to have s3ql in testing for
the other archituctures than not to have it in testing at all (there is
no S3QL version in testing at the moment).

Is this intended behavior?

If so, is there a way to make an exception here and allow migration?

Thanks!
-Nikolaus
--- End Message ---
--- Begin Message ---
On Thu, Sep 10, 2015 at 01:00:27PM -0700, Nikolaus Rath wrote:
> The s3ql package is not migrating to testing. As far as I understand,
> this is because it's not building on armhf.

Your analysis is correct.

> However, I think it would be a lot better to have s3ql in testing for
> the other archituctures than not to have it in testing at all (there is
> no S3QL version in testing at the moment).
> 
> Is this intended behavior?

I'm not sure which behaviour you're asking about; the intended (and
correct, and visible) behaviour is to remove s3ql from testing because it
has an RC bug.
 
> If so, is there a way to make an exception here and allow migration?

It's not an exception, but if you want to not ship s3ql on armhf in Stretch
you can ask ftp-masters to remove it from sid, taking into account any
reverse dependencies.


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

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



signature.asc
Description: Digital signature
--- End Message ---

Bug#765639: wheezy-pu: openssl new upstream version

[Kurt Roeckx]

On Fri, Aug 21, 2015 at 07:31:53PM +0200, Kurt Roeckx wrote:
> On Sun, Jun 14, 2015 at 11:52:07AM +0200, Kurt Roeckx wrote:
> > On Sun, Jun 14, 2015 at 12:22:52PM +1000, Julien Cristau wrote:
> > > Is the policy for what gets included in the stable branches described
> > > somewhere?
> > 
> > It's documented at:
> > https://www.openssl.org/about/releasestrat.html
> > 
> > > What kind of automated or manual regression (or other)
> > > testing is done on the stable branches?
> > 
> > We have a test suite.  It does test a lot of the functionality,
> > but no test suite is perfect.
> > 
> > > What rate of changes are we talking about?
> > 
> > There have been about 300 commits so far this year in the
> > OpenSSL_1_0_1-stable branch, so averging about 2 per day.
> 
> So I'm still waiting for a reply to this.

Today I had yet an other request to backport some of the changes
that went into the stable releases.

Someone please make a decision, so that I know I can either upload
that, or annoy you with about 100 patches you get to review
instead.


Kurt

Bug#798589: s3ql: please allow migration to testing

[Adam D. Barratt]

On Thu, 2015-09-10 at 13:14 -0700, Nikolaus Rath wrote:
> Hi Jonathan,
> 
> On Sep 10 2015, Jonathan Wiltshire  wrote:
> > On Thu, Sep 10, 2015 at 01:00:27PM -0700, Nikolaus Rath wrote:
> >> The s3ql package is not migrating to testing. As far as I understand,
> >> this is because it's not building on armhf.
[...]
> >> If so, is there a way to make an exception here and allow migration?
> >
> > It's not an exception, but if you want to not ship s3ql on armhf in Stretch
> > you can ask ftp-masters to remove it from sid, taking into account any
> > reverse dependencies.
> 
> Hasn't s3ql *already* been removed from testing? At least this is what I
> conclude from https://tracker.debian.org/pkg/s3ql.

Yes. Jonathan said "remove it from sid", and that's what he meant.

adsb@franck:~$ dak ls s3ql -s unstable
s3ql   | 2.13+dfsg-1   | unstable   | source, armhf
s3ql   | 2.13+dfsg-2   | unstable   | source, amd64, arm64, armel, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x

If you want the package to migrate, the out-of-date armhf binary needs
to not be in unstable - either because you've asked ftp-master to remove
it, or because the package builds on armhf again.

Regards,

Adam

Bug#798589: s3ql: please allow migration to testing

[Adam D. Barratt]

On Thu, 2015-09-10 at 13:14 -0700, Nikolaus Rath wrote:
> I mean if it's intended that S3QL does not migrate to testing just
> because it doesn't build on one architecture.

No, there are many packages that don't build on all architectures and
migrate to testing routinely with no problems.

However, that's not the issue here. The issue is that it _used to_ build
on that architecture, and there are now out-of-date packages in
unstable.

Regards,

Adam

Re: Migration hint for cgsi-gsoap and lcgdm?

[Jonathan Wiltshire]

On Thu, Sep 10, 2015 at 08:21:21AM +0200, Mattias Ellert wrote:
> If cgsi-gsoap 1.3.8-1 and lcgdm 1.8.9-1+b2 would migrate together it
> wouldn't cause any breakage as far as I can tell, but doing the
> migration one package at a time will cause breakage irrespectively of
> which of the two migrates first. Can this be hinted?

It certainly looks that way; hint added.


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

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



signature.asc
Description: Digital signature

Bug#798589: s3ql: please allow migration to testing

[Nikolaus Rath]

Hi Jonathan,

On Sep 10 2015, Jonathan Wiltshire  wrote:
> On Thu, Sep 10, 2015 at 01:00:27PM -0700, Nikolaus Rath wrote:
>> The s3ql package is not migrating to testing. As far as I understand,
>> this is because it's not building on armhf.
>
> Your analysis is correct.
>
>> However, I think it would be a lot better to have s3ql in testing for
>> the other archituctures than not to have it in testing at all (there is
>> no S3QL version in testing at the moment).
>> 
>> Is this intended behavior?
>
> I'm not sure which behaviour you're asking about; 

I mean if it's intended that S3QL does not migrate to testing just
because it doesn't build on one architecture.

> the intended (and correct, and visible) behaviour is to remove s3ql
> from testing because it has an RC bug.

Hmm. I thought I took care of that. Which bug is that?
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=s3ql
lists only #792685 - but that only affects jessie and not sid/stretch.

>> If so, is there a way to make an exception here and allow migration?
>
> It's not an exception, but if you want to not ship s3ql on armhf in Stretch
> you can ask ftp-masters to remove it from sid, taking into account any
> reverse dependencies.

Hasn't s3ql *already* been removed from testing? At least this is what I
conclude from https://tracker.debian.org/pkg/s3ql.


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


signature.asc
Description: PGP signature

Bug#798589: s3ql: please allow migration to testing

[Jonathan Wiltshire]

On Thu, Sep 10, 2015 at 01:14:17PM -0700, Nikolaus Rath wrote:
> 
> Hi Jonathan,
> 
> On Sep 10 2015, Jonathan Wiltshire  wrote:
> > On Thu, Sep 10, 2015 at 01:00:27PM -0700, Nikolaus Rath wrote:
> >> The s3ql package is not migrating to testing. As far as I understand,
> >> this is because it's not building on armhf.
> >
> > Your analysis is correct.
> >
> >> However, I think it would be a lot better to have s3ql in testing for
> >> the other archituctures than not to have it in testing at all (there is
> >> no S3QL version in testing at the moment).
> >> 
> >> Is this intended behavior?
> >
> > I'm not sure which behaviour you're asking about; 
> 
> I mean if it's intended that S3QL does not migrate to testing just
> because it doesn't build on one architecture.
> 
> > the intended (and correct, and visible) behaviour is to remove s3ql
> > from testing because it has an RC bug.
> 
> Hmm. I thought I took care of that. Which bug is that?
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=s3ql
> lists only #792685 - but that only affects jessie and not sid/stretch.

At the time of removal the 'jessie' tag had not been added, and there was
also a second RC bug. The removal message does actually include such
information:

| Date: Tue, 11 Aug 2015 16:39:11 +
| To: 
| From: Debian testing watch 
| Subject: s3ql REMOVED from testing
| 
| FYI: The status of the s3ql source package
| in Debian's testing distribution has changed.
| 
|   Previous version: 2.13+dfsg-1
|   Current version:  (not in testing)
|   Hint: 
| # 790525,792685

s3ql will not return to Stretch as long as it doesn't build properly, so
that's what you should fix.

> >> If so, is there a way to make an exception here and allow migration?
> >
> > It's not an exception, but if you want to not ship s3ql on armhf in Stretch
> > you can ask ftp-masters to remove it from sid, taking into account any
> > reverse dependencies.
> 
> Hasn't s3ql *already* been removed from testing? At least this is what I
> conclude from https://tracker.debian.org/pkg/s3ql.

That's why I said 'sid'.




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

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



signature.asc
Description: Digital signature

Migration hint for cgsi-gsoap and lcgdm?

[Mattias Ellert]

Hi!

Version 1.3.8-1 of cgsi-gsoap has been a valid candidate for migration
to testing for some time, but hasn't done the migration yet. The "more
excuses" page says migrating the package would make four binary
packages built from the lcgdm source package uninstallable.

lcgdm in testing is at version 1.8.9-1+b1 and in unstable at version
1.8.9-1+b2.

If cgsi-gsoap 1.3.8-1 and lcgdm 1.8.9-1+b2 would migrate together it
wouldn't cause any breakage as far as I can tell, but doing the
migration one package at a time will cause breakage irrespectively of
which of the two migrates first. Can this be hinted?

Mattias



signature.asc
Description: This is a digitally signed message part