NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: audiofile_0.3.6-2+deb8u1_amd64.changes
  ACCEPT
Processing changes file: libdatetime-timezone-perl_1.75-2+2016e_amd64.changes
  ACCEPT
Processing changes file: libpdfbox-java_1.8.7+dfsg-1+deb8u1_amd64.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_allonly.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_amd64.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_arm64.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_armel.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_armhf.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_i386.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_mips.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: libxslt_1.1.28-2+deb8u1_s390x.changes
  ACCEPT
Processing changes file: tzdata_2016e-0+deb8u1_amd64.changes
  ACCEPT

Processed: Re: Bug#828227: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016e

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #828227 [release.debian.org] jessie-pu: package 
libdatetime-timezone-perl/1:1.75-2+2016e
Added tag(s) pending.

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

Bug#827288: jessie-pu: package audiofile/0.3.6-2

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2016-06-17 at 22:46 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-06-14 at 17:37 +0100, James Cowgill wrote:
> > This update fixes CVE-2015-7747 (#801102). The security bug is marked
> > no-DSA, so the security team asked me to submit it as a normal stable
> > update.
> > 
> > The patch is copied directly from this Ubuntu bug (and is already
> > applied in Ubuntu):
> > https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/1502721
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#828227: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016e

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-06-26 at 17:58 +0200, gregor herrmann wrote:
> On Sun, 26 Jun 2016 16:46:15 +0100, Adam D. Barratt wrote:
> 
> > On Sun, 2016-06-26 at 12:19 +0200, gregor herrmann wrote:
> > > I've prepared an update for libdatetime-timezone-perl in
> > > jessie{,-updates} to include the new data from the Olson db 2016e.
> > > This includes contemporary change for Egypt becoming effective on 7
> > > July.
> > 
> > Please go ahead.
> 
> Thank you! Uploaded.

Flagged for acceptance.

Regards,

Adam

Processed: Re: Bug#827288: jessie-pu: package audiofile/0.3.6-2

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #827288 [release.debian.org] jessie-pu: package audiofile/0.3.6-2
Added tag(s) pending.

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

Bug#816389: transition: php7.0

[Niels Thykier]

Ondřej Surý:
> Hi release team,
> 
> [...]
> 

Hi,


Just a quick drive-by clarification:

> And then finally remove src:php5 and src:php-json from testing and
> prevent it to migrate. (Strangely #815797 didn't stop src:php5 from
> migrating new versions from unstable to testing.)
> 
> Cheers,
> 

This is because #815797 is *not* a regression relative to testing (i.e.
it affects testing *and* unstable).  Only RC-bug regressions are
blocked, which it will be once php5 is removed from testing.

Thanks,
~Niels

Bug#828186: transition: rtaudio

[Jaromír Mikeš]

-- Původní zpráva --
Od: Emilio Pozuelo Monfort 
Komu: Jaromír Mikeš , 828...@bugs.debian.org
Datum: 26. 6. 2016 9:55:04
Předmět: Re: Bug#828186: transition: rtaudio

On 25/06/16 23:47, Jaromír Mikeš wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> new upstream rtaudio bumps SONAME, so we need to transition. 
> 
> Direct reverse dependencies are:
> 
> stk
> jacktrip
> mlt

> Did you test build them?

Hi,

I just did test build of packages above.
Location of header files changed from include to include/rtaudio so some easy 
patching will be needed.
Otherwise they build fine.

regards

mira

Bug#828187: transition: rtmidi

[Jaromír Mikeš]

On 25/06/16 23:49, Jaromír Mikeš wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> new upstream rtmidi bumps SONAME, so we need to transition.
> 
> Direct reverse dependencies are:
> 
> stk
> giada
> midisnoop
> milkytracker
>
>Did you test build them?

Hi,

I just did test build of packages above.
Location of header files changed from include to include/rtmidi so some easy 
patching will be needed.
I just get some trouble to build midisnoop but not because of rtmidi package. 
I am also maintainer of midisnoop and I don't see it as stopper for transition. 

regards

mira

Re: [Stretch] Status for architecture qualification

[Luca Filipozzi]

On Mon, Jun 27, 2016 at 04:35:03PM +0200, Wouter Verhelst wrote:
> (sorry for jumping in late here)
> 
> On Wed, Jun 15, 2016 at 07:51:55AM +0800, Paul Wise wrote:
> > On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:
> > 
> > > At the openmainframeproject EU meetup, it was indicated that SUSE
> > > joined with indication that Open Build Service might be able to use
> > > resources hosted by Marist.
> > > 
> > > I wonder if it makes sense to reach out, and see if there are
> > > resources available to use as porter boxes & build boxes. That way
> > > Debian might be able to get such donated resource available on ongoing
> > > basis and hopefully with some hw support.
> > 
> > Marist already support Debian with an s390x buildd:
> > 
> > ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> > "(sponsor=*marist*)"
> > https://db.debian.org/machines.cgi?host=zani
> > 
> > Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:
> > 
> > ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> > "(architecture=s390*)" sponsor
> 
> Given that we already seem to have three hardware sponsors for the s390x
> port, is this really a concern?

Our standard for buildd / porterboxen of a released architecture is:
- multiple machines (N + 1, N sufficient to handle the buildd / porter load)
- under warranty or post-warranty hardware support for the duration of their
  use as buildds / porterboxen including through the LTS timeframe
- located in multiple geographic locations (EU and NA, ideally)
- hosted by different hosting partners, each providing high availability
  (power, cooling, networking) and intelligent remote hands
- under Debian control and/or ownership; available & affordable 
- redundant disks and power supplies
- out-of-band service processor with power management or equivalent

Not satisfying the fifth bullet is a minor concern in the case of s390x.

> If we were to lose one sponsor, we'd still have two (and it would be
> reasonable to try to ensure that we get a new sponsor to replace the one
> lost).

Indeed.  The more redundnant sponsors, the less worrying is the concern.

> How about making it a requirement that there is some level of redundancy
> in sponsors for ports where hardware cannot be easily bought with Debian
> money? That would cover the s390x port as well as any potential other
> insanely-expensive-hardware port[1] that we might support now or in the
> future.

That is our requirement, effectively.  The mild concern has not blocked the
port from releasing.  That said, the concern should be documented.

> If push comes to shove, we could also talk to IBM. Pretty much all POWER
> hardware we have was sponsored by IBM; it's not unreasonable to assume they
> might be willing to also sponsor s390x time or hardware.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Re: [Stretch] Status for architecture qualification

[Wouter Verhelst]

(sorry for jumping in late here)

On Wed, Jun 15, 2016 at 07:51:55AM +0800, Paul Wise wrote:
> On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:
> 
> > At the openmainframeproject EU meetup, it was indicated that SUSE
> > joined with indication that Open Build Service might be able to use
> > resources hosted by Marist.
> > 
> > I wonder if it makes sense to reach out, and see if there are
> > resources available to use as porter boxes & build boxes. That way
> > Debian might be able to get such donated resource available on ongoing
> > basis and hopefully with some hw support.
> 
> Marist already support Debian with an s390x buildd:
> 
> ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> "(sponsor=*marist*)"
> https://db.debian.org/machines.cgi?host=zani
> 
> Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:
> 
> ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> "(architecture=s390*)" sponsor

Given that we already seem to have three hardware sponsors for the s390x
port, is this really a concern?

If we were to lose one sponsor, we'd still have two (and it would be
reasonable to try to ensure that we get a new sponsor to replace the one
lost).

How about making it a requirement that there is some level of redundancy
in sponsors for ports where hardware cannot be easily bought with Debian
money? That would cover the s390x port as well as any potential other
insanely-expensive-hardware port[1] that we might support now or in the
future.

If push comes to shove, we could also talk to IBM. Pretty much all POWER
hardware we have was sponsored by IBM; it's not unreasonable to assume
they might be willing to also sponsor s390x time or hardware.

[1] not that I know of any, but hey, you never know.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3

[Kurt Roeckx]

I guess I should just keep the SSLv2 symbols.  I assume you don't
have a problem with the other change?


Kurt

Bug#828097: transition: tidy

[Daniel James]

Hi Jeremy, hi Emilio,

You're right, the tidy-html5 source package is meant to replace the tidy
source package. I'm sorry for not following the correct procedure there;
this is my first attempt to update an orphaned package.

This new version is a major update but not a rewrite, as I understand
it. The upstream name changed, and also the soname of the library.

I'm currently preparing a packaging update to address #827891 #827716
and several other bugs.

Cheers!

Daniel

Bug#816389: transition: php7.0

[Ondřej Surý]

Hi release team,

since we are down to:

--cut here--
Checking reverse dependencies...
# Broken Depends:
galette: galette
zeroc-ice: php-zeroc-ice

# Broken Build-Depends:
php-guzzle: php5-cli
php5-curl
php-json: php5-dev
zeroc-ice: php5-dev (>= 5.4.0~rc6)

Dependency problem found.
--cut here--

Could you perhaps force this to finally finish the transition?

1. push zeroc-ice+mumble to migrate together
2. remove galette and its rdeps from testing (it would be auto-removed
on June 30 anyway)
3. remove php-guzzle + aws-sdk-for-php from testing (as auto-removal
doesn't seem to kick-in here)
 + gently push php-monolog from unstable into testing (perhaps just bump
 severity of existing upload from 5 to 2 days)

And then finally remove src:php5 and src:php-json from testing and
prevent it to migrate. (Strangely #815797 didn't stop src:php5 from
migrating new versions from unstable to testing.)

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

On Sat, Jun 25, 2016, at 23:04, Emilio Pozuelo Monfort wrote:
> On 15/06/16 09:56, Ondřej Surý wrote:
> > - php-guzzle - seems fixed to me, but dak still wants to remove the
> > package
> 
> Because it build-depends on php5-cli and php5-curl (for the testsuite it
> seems).
> 
> Cheers,
> Emilio