NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: libmateweather_1.8.0-2+deb8u1_arm64.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_armel.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_armhf.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_mips.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_mipsel.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: libmateweather_1.8.0-2+deb8u1_i386.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_s390x.changes
  ACCEPT

Re: Planning for d-i Stretch Alpha 9

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2016-11-21):
> Ben Hutchings  (2016-11-20):
> > Yes, there will be an ABI bump in the next upload to unstable
> > (probably within the next week).
> 
> Thanks! I'll wait for that to happen & migrate to testing before
> preparing for the next d-i release.

FWIW linux migrated a few days ago so I'll start working on a release
as soon as my free time permits. Probably somewhen around Christmas.

As usual (sadly) I'm way behind reading/checking what happens on
debian-boot@ so feel free to mention specific things you would want me
to notice, through a mail cc'd to .


KiBi.


signature.asc
Description: Digital signature

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: game-music-emu_0.5.5-2+deb8u1_amd64.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_arm64.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_armel.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_armhf.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_i386.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_mips.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: game-music-emu_0.5.5-2+deb8u1_s390x.changes
  ACCEPT
Processing changes file: libmateweather_1.8.0-2+deb8u1_amd64.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_arm64.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_amd64.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_armel.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_armhf.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_i386.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_mips.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: libupnp_1.6.19+git20141001-1+deb8u1_s390x.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_amd64.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_arm64.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_armel.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_armhf.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_i386.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_mips.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: php5_5.6.29+dfsg-0+deb8u1_s390x.changes
  ACCEPT

Processed: Re: Bug#847921: jessie-pu: package libmateweather/1.8.0-2+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #847921 [release.debian.org] jessie-pu: package 
libmateweather/1.8.0-2+deb8u1
Added tag(s) pending.

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

Bug#847921: jessie-pu: package libmateweather/1.8.0-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2016-12-14 at 19:45 +, Mike Gabriel wrote:
> Hi Adam,
> 
> On  Mi 14 Dez 2016 20:28:04 CET, Adam D. Barratt wrote:
> 
> > Control: tags -1 -moreinfo +confirmed
> >
> > On Wed, 2016-12-14 at 13:01 +, Mike Gabriel wrote:
> >> Hi Adam,
> >>
> >> On  Mo 12 Dez 2016 14:07:37 CET, Adam D. Barratt wrote:
> >>
> >> > Control: tags -1 + moreinfo
> >> >
> >> > On 2016-12-12 11:30, Mike Gabriel wrote:
> >> >> The weather data provider service weather.noaa.gov is a discontinued
> >> >> service. This update
> >> >> switches libmateweather over to using aviationweather.gov. In Debian
> >> >> jessie, this fixes
> >> >> the MATE weather report applet. Currently, the applet displays no
> >> >> data at all.
> >> >
> >> > The BTS metadata for #846900 indicates that the bug affects the
> >> > package in unstable as well. If that's correct, please update
> >> > unstable first; if it's not, please fix the metadata.
> >> >
> >> > Regards,
> >> >
> >> > Adam
> >>
> >> Any more feedback on this? Is anything else needed to get this j-pu
> >> processed further?
> >
> > Some patience? :-p
> 
> Sorry!
> 
> > There's only so many hours in the day and I can't always find time for
> > Debian work every day.
> 
> Don't get me wrong. You are doing an AWESOME job on the release team.  
> Thanks for giving your time to it. You presence on the team gives  
> Debian such a high reliability. Thank you for that
> 
> > Please go ahead.
> 
> Just uploaded the _source.changes to j-pu.

Flagged for acceptance.

Regards,

Adam

Bug#843701: jessie-pu: package boinc/7.4.23+dfsg-1

[Gianfranco Costamagna]

control: tags -1 -moreinfo




Hi,
>Your mail client mangled the diff.



sorry for that

> the diff is simple:> +  [ Tom Downes ]
> +  * Fix OOM_ADJ handling with a backportable approach
> +(Closes: #843663)
> 
> ^^ a typo in a variable name was preventing OOM_ADJ from being correctly set 
> in the init script
> 

What's the impact of that bug?

when kernel is OOM, boinc tasks should be killed before other tasks.
boinc is something that shouldn't impact the rest of the system
(voluntary computing), so it runs with lower nice level, and should
be killed before other programs in case the system gets out of memory.

this typo was preventing the second OOM handling to be correctly set, so people 
might have got
some other program killed instead of a boinc task.

>How can that possibly work?  The init script doesn't have an X>display...

this is a known problem/issue, usually people can do GPU computing with a 
reload of the boinc-client
daemon, in this case the init system picks the X server up.
(this is how things should work, I'm clueless about such stuff and I avoid 
touching it when it
"works")

thanks for the review,

G.

Processed: Re: Bug#843701: jessie-pu: package boinc/7.4.23+dfsg-1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 -moreinfo
Bug #843701 [release.debian.org] jessie-pu: package boinc/7.4.23+dfsg-1
Removed tag(s) moreinfo.

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

Processed: Re: Bug#828471: opensc: FTBFS with openssl 1.1.0

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #828471 [src:opensc] opensc: FTBFS with openssl 1.1.0
Severity set to 'important' from 'serious'
> unblock 827061 by -1
Bug #827061 [release.debian.org] transition: openssl
827061 was blocked by: 828290 828348 828342 828599 828561 828296 844254 828609 
828258 828558 828082 828517 828493 844920 828264 828580 828248 828322 828510 
828426 844213 828548 835786 827068 828279 828567 828466 828422 828597 828581 
828418 844815 828503 828486 828436 828526 844366 828319 828514 844018 844836 
828461 828497 828411 828549 828381 828591 828435 828402 828532 828325 828587 
828565 828360 828297 828321 828359 828301 828485 828407 835799 828328 828334 
828399 828341 828259 836419 828583 828250 844928 828618 835585 828570 828304 
828281 845729 828366 828595 828374 828401 828251 828611 828349 835789 828425 
828468 828544 828615 828496 828554 828127 828547 828531 828380 828563 828234 
844301 828545 835796 828605 844936 828267 822380 828594 844838 844951 828479 
835804 828318 828389 844949 828616 844706 828303 808669 828292 828447 837960 
828268 844975 828492 828283 828443 828302 828254 828465 828551 828574 844926 
845106 828502 828351 828284 828488 828530 828369 828516 828527 828393 828552 
844347 835797 828555 828450 828249 828362 828310 828478 828589 828445 828446 
828274 828495 828315 828487 844904 844800 828231 828372 828588 828395 828083 
814600 828246 828346 828289 828417 828499 828606 828240 828306 828275 828235 
828420 828298 828376 828139 828330 828511 828610 843682 828308 828368 828280 
828452 828449 828356 828520 828421 828438 828529 844870 828506 828568 844906 
828314 843852 828405 828521 828333 828559 828263 828512 828244 828490 828278 
828444 828388 844663 828355 828509 828460 828367 846113 828585 828363 828400 
843871 828433 828439 828269 828573 828607 828577 835798 828398 828619 828505 
828537 828602 828462 828371 828576 844311 828560 828442 828453 828596 828564 
828472 828533 828228 828546 828358 844909 828617 828536 828265 845030 828524 
828282 828603 844907 828387 828428 828612 843988 828457 828390 828448 828424 
828344 809271 828480 828410 828541 828300 828320 828535 828404 828469 828311 
828451 835811 828257 828562 828473 828463 828270 828385 828373 844845 828534 
828601 828613 828540 843532 828332 828476 828331 828365 828566 828515 828458 
828397 828484 828256 828455 828288 828335 828291 828441 828377 828598 844833 
828293 835549 828523 828431 828470 828243 835793 828239 828294 828414 828412 
828391 828409 835785 828432 828375 828382 828584 828578 828543 828336 828241 
828489 828378 828354 828419 828316 828525 844948 828253 828593 828556 828542 
828590 844271 828620 828237 828394 835790 828459 828295 844947 828550 828519 
828252 828323 828429 828416 828326 828364 841635 828572 828233 828440 844345 
828379 828507 828608 828427 828491 828307 828579 828464 828508 829452 828309 
828340 828392 828403 828232 828352 828277 828614 828538 828337 828518 828305 
828361 828575 828339 845016 828347 828338 828287 828276 828423 844664 828456 
828434 828285 828604 829465 828396 828286 828586 828313 844931 828528 828553 
828471 828317 828571 828482 844534 828539 828504 828454 828370 835794 828273 
828569 828494 828501 828500 828242 828272 828262 828600 828383 828350 828582 
828229 828430 828357 828343 844916 844503 828324 828437 828271 828592 828261 
828230 844234 828415 846769 828474 844877 844945 835800 828406 828386 828238 
828255 828260 828345 828467 828384
827061 was not blocking any bugs.
Removed blocking bug(s) of 827061: 828471

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

Re: piuparts blocking testing migration

[Dominic Hargreaves]

On Sat, Dec 17, 2016 at 10:03:40AM +0100, Julien Cristau wrote:
> On Fri, Dec 16, 2016 at 22:38:16 +, Dominic Hargreaves wrote:
> 
> > Hi,
> > 
> > I must have missed the memo, but according to
> > 
> > https://qa.debian.org/excuses.php?package=ircd-hybrid
> > 
> > this package is not migrating because of a piuparts failure.
> > In fact, the failure is not caused by irc-hybrid directly, but because
> > of this bug in openssl:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689490
> > 
> I've told britney to ignore that failure for the next run.

Great, thanks!

Dominic.

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi,

2016-12-17 10:17 GMT+01:00 Julien Cristau :
> On Sat, Dec 17, 2016 at 09:20:40 +0100, Bálint Réczey wrote:
>
>> >> >> Considering that we are already in the transition freeze I suggest
>> >> >> going with enabling bindnow for all architectures in dpkg and
>> >> >> for Stretch+1 the responsibility of setting some hardening flags
>> >> >> could be transferred to gcc.
>> >> >> IMO this is not a transition because the change does not affect
>> >> >> package interdependencies.
>> >> >
>> >> > Is there any update on this?
>> >
>> > I've not seen any reply from the release team, no. And as explicitly
>> > mentioned before multiple times now, this has the potential to impact
>> > the release by introducing subtle and possibly hard to spot errors at
>> > *run-time*, which might be triggered by simple a upload or a binNMU w/o
>> > the maintainer being in the loop and knowing they have enabled bindnow.
>> > So I want the release team to be involved in ACKing this potentially
>> > release breaking change.
>>
>> I would like to kindly ask the Release Team to share its position on the
>> bindnow question since Guillem don't seem to let this move forward
>> without that.
>>
> That is very much not happening for stretch.

This is a bit terse and a bit late but DD-s are still free to enable
bindnow per package in the next 7 days.

Affected packages:
https://lintian.debian.org/tags/hardening-no-bindnow.html

Thanks,
Balint

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Antoine Beaupré]

On 2016-12-17 05:34:35, Julien Cristau wrote:
> On Thu, Nov 24, 2016 at 14:52:44 -0500, Antoine Beaupré wrote:
>
>> On 2016-11-24 13:04:21, Julien Cristau wrote:
>> > On Tue, Aug  9, 2016 at 11:50:27 -0400, Antoine Beaupré wrote:
>> >
>> >> This is a tentative of opening the discussion regarding a more regular
>> >> update of the youtube-dl package in Debian stable.
>> >> 
>> > TBH I think this should never have reached stable in the first place...
>> 
>> So what should happen now? Should it be removed from stretch?
>> 
>> What do we do with the version that *is* in testing?
>> 
>> Isn't that what volatile (now -updates) was designed for?
>> 
>> https://lists.debian.org/debian-volatile-announce/2012/msg0.html
>> 
>> It explicitly mentions:
>> 
>> """
>>  * Fixes to leaf packages that were broken by external changes (e.g.
>>video downloading tools and tor).
>> """
> 
> So once upon a time libquvi-scripts was supposed to help with that, by
> being a relatively self-contained set of per-site lua scripts that could
> get updated and then used by a variety of packages.  Unfortunately that
> appears to be dead, so I'm not sure what to suggest nowadays.

Yeah, I was a user of libquvi-scripts. I even prodded joeyh so that he
implements support for it in git-annex so that we could have URL-backed
youtube videos in there... Only to discover it would rot like that...

It's too bad, really: quvi was the right approach - but youtube-dl seems
to have won the race. It supports more platforms and keeps up with the
changes.

Really, it's an algorithmic problem: you can't just push that stuff in
metadata and treat it as simple databases that need to be independently
of the main program logic...

A.

-- 
In god we trust, others pay cash.
- Richard Desjardins, Miami

Bug#845304: transition: libxtables12

[Julien Cristau]

On Sat, Dec 17, 2016 at 10:35:44 +, Simon McVittie wrote:

> On Sat, 17 Dec 2016 at 10:14:43 +0100, Julien Cristau wrote:
> > On Tue, Dec 13, 2016 at 15:56:47 +, Simon McVittie wrote:
> > > Please could someone from the release team set up a manual tracker that
> > > also looks at Recommends?
> > > 
> > Done.
> 
> Thanks, but this doesn't seem to be correct: it has
> 
> Affected: .build-depends ~ /libxtables-dev/
> 
> but that only finds one package, nftables. I think the other packages
> indirectly build-depend on libxtables-dev via the transitional
> iptables-dev?
> 
> Affected: .build-depends ~ /iptables-dev/ | .build-depends ~ 
> /libxtables-dev/
> 
> might be a better affected set? Or the affected set could be based on
> the good and bad expressions, like it is in the automatic tracker.
> 
Updated, thanks.

Cheers,
Julien

Bug#847273: jessie-pu: package mapserver/6.4.1-5

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 12/17/2016 12:43 PM, Julien Cristau wrote:
> On Fri, Dec 16, 2016 at 09:47:12 +0100, Sebastiaan Couwenberg wrote:
> 
>> On 12/06/2016 10:00 PM, Sebastiaan Couwenberg wrote:
>>> Sorry for the outdated debdiff, for p-u the distribution has been
>>> changed to stable.
>>
>> With mapserver (7.0.3-1) having migrated to testing and the subsequent
>> update of the backport, CVE-2016-9839 is now fixed everywhere except in
>> jessie itself. I'd like to fix that, can I go ahead?
>>
> That has apparently been known for over two and a half years, is there a
> particular reason this is now urgent?

It wasn't known widely until recently, and the MapServer developers
asked me to update the package now that the fixed releases have been
published.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Processed: Re: Bug#847273: jessie-pu: package mapserver/6.4.1-5

[Debian Bug Tracking System]

Processing control commands:

> tags -1 - moreinfo
Bug #847273 [release.debian.org] jessie-pu: package mapserver/6.4.1-5
Removed tag(s) moreinfo.

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

Re: Transition to SQLAlchemy 1.1.x

[Julien Cristau]

On Sun, Nov 27, 2016 at 21:16:46 +0100, Bernd Zeimetz wrote:

> sqlalchemy 1.0 is in maintenance mode only and will receive only
> critical updates, so we clearly want to have 1.1 in stretch.
> 
That's not at all clear, to be honest.  I do think Thomas has a point.

Cheers,
Julien

Processed: Re: Bug#847273: jessie-pu: package mapserver/6.4.1-5

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #847273 [release.debian.org] jessie-pu: package mapserver/6.4.1-5
Added tag(s) moreinfo.

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

Bug#847273: jessie-pu: package mapserver/6.4.1-5

[Julien Cristau]

Control: tag -1 moreinfo

On Fri, Dec 16, 2016 at 09:47:12 +0100, Sebastiaan Couwenberg wrote:

> On 12/06/2016 10:00 PM, Sebastiaan Couwenberg wrote:
> > Sorry for the outdated debdiff, for p-u the distribution has been
> > changed to stable.
> 
> With mapserver (7.0.3-1) having migrated to testing and the subsequent
> update of the backport, CVE-2016-9839 is now fixed everywhere except in
> jessie itself. I'd like to fix that, can I go ahead?
> 
That has apparently been known for over two and a half years, is there a
particular reason this is now urgent?

Cheers,
Julien

Processed: Re: Bug#845263: jessie-pu: package w3m/0.5.3-19+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tag -1 confirmed
Bug #845263 [release.debian.org] jessie-pu: package w3m/0.5.3-19+deb8u1
Added tag(s) confirmed.

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

Bug#845263: jessie-pu: package w3m/0.5.3-19+deb8u1

[Julien Cristau]

Control: tag -1 confirmed

On Thu, Nov 24, 2016 at 20:03:47 +0900, Tatsuya Kinoshita wrote:

> w3m (0.5.3-19+deb8u1) jessie; urgency=medium
> 
>   * New patch 901_ucsmap.patch to fix array index (closes: #820162)
>   * New patch 902_johab1.patch to fix array index (closes: #820373)
>   * New patch 903_input-type.patch to fix null deref [CVE-2016-9430]
>   * New patch 904_form-update.patch to fix overflow
> [CVE-2016-9423] [CVE-2016-9431]
>   * New patch 905_textarea.patch to fix heap write [CVE-2016-9424]
>   * New patch 906_form-update.patch to fix bcopy size [CVE-2016-9432]
>   * New patch 907_iso2022.patch to fix array index [CVE-2016-9433]
>   * New patch 908_forms.patch to fix null deref [CVE-2016-9434]
>   * New patch 909_button-type.patch to fix rodata write [CVE-2016-9437]
>   * New patch 910_input-alt.patch to fix null deref [CVE-2016-9438]
>   * New patch 911_rowcolspan.patch to fix stack smashing [CVE-2016-9422]
>   * New patch 912_i-dd.patch to fix uninit values
> [CVE-2016-9435] [CVE-2016-9436]
>   * New patch 913_tabwidth.patch to fix heap corruption [CVE-2016-9426]
>   * New patch 914_curline.patch to fix near-null deref [CVE-2016-9440]
>   * New patch 915_table-alt.patch to fix near-null deref [CVE-2016-9441]
>   * New patch 916_anchor.patch to fix heap write
> [CVE-2016-9425] [CVE-2016-9428]
>   * New patch 917_strgrow.patch to fix potential heap buffer corruption
> [CVE-2016-9442]
>   * New patch 918_form-value.patch to fix null deref [CVE-2016-9443]
>   * New patch 919_form-update.patch to fix buffer overflow
> [CVE-2016-9429] [CVE-2016-9621]
>   * New patch 920_table.patch to fix stack overflow [CVE-2016-9439]
> (closes: #844726)
>   * New patch 921_cotable.patch to fix null deref
> (additional fix for #844726)
>   * New patch 922_lineproc.patch to fix null deref [CVE-2016-9622]
>   * New patch 923_tagproc.patch to fix null deref [CVE-2016-9623]
>   * New patch 924_curline.patch to fix near-null deref [CVE-2016-9624]
>   * New patch 925_lineproc.patch to fix stack overflow [CVE-2016-9625]
>   * New patch 926_indent-level.patch to fix stack overflow [CVE-2016-9626]
>   * New patch 927_symbol.patch to fix array index [CVE-2016-9627]
>   * New patch 928_form-id.patch to fix null deref [CVE-2016-9628]
>   * New patch 929_anchor.patch to fix null deref [CVE-2016-9629]
>   * New patch 930_tbl-mode.patch to fix null deref [CVE-2016-9631]
>   * New patch 931_parse-url.patch to fix buffer overflow [CVE-2016-9630]
>   * New patch 932_ucsmap.patch to fix buffer overflow [CVE-2016-9632]
>   * New patch 933_table-level.patch to fix out of memory [CVE-2016-9633]
> 
>  -- Tatsuya Kinoshita   Thu, 24 Nov 2016 19:49:18 +0900
> 
> Please let me know if I can upload it.
> 
Kind of looks like this is papering over code that was written for a
different era :/

Please go ahead.

Cheers,
Julien

Bug#843701: jessie-pu: package boinc/7.4.23+dfsg-1

[Julien Cristau]

Control: tag -1 moreinfo

On Tue, Nov  8, 2016 at 21:12:32 +, Gianfranco Costamagna wrote:

> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: jessie
> Severity: normal
> 
> Boinc has a functionality problem in stable, the fix is already backported 
> and I did upload
> a new version in unstable a few hours ago
> (just to make it backportable with older kernels)
> 
Your mail client mangled the diff.

> the diff is simple:
> +  [ Tom Downes ]
> +  * Fix OOM_ADJ handling with a backportable approach
> +(Closes: #843663)
> 
> ^^ a typo in a variable name was preventing OOM_ADJ from being correctly set 
> in the init script
> 
What's the impact of that bug?

> 
> +  [ Mike Brennan  ]
> +  * Fix xhost syntax. (Closes: #841665)
> ^^ this is a potential security issue that still affects stable, so I would 
> like to also address it.
> 
How can that possibly work?  The init script doesn't have an X
display...

Cheers,
Julien

Processed: Re: Bug#843701: jessie-pu: package boinc/7.4.23+dfsg-1

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #843701 [release.debian.org] jessie-pu: package boinc/7.4.23+dfsg-1
Added tag(s) moreinfo.

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

Bug#841234: jessie-pu: package libiberty/20141014-1

[Julien Cristau]

Control: tag -1 moreinfo

On Tue, Oct 18, 2016 at 20:32:56 +0200, Anton Gladky wrote:

> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> libiberty needs to be updated in Jessie, because the newer version
> fixes many security issues:
> 
> CVE-2016-4487 CVE-2016-4488 CVE-2016-4489 CVE-2016-4490
> CVE-2016-4492 CVE-2016-4493 CVE-2016-2226 CVE-2016-6131
> 
What makes it impossible to backport just the fixes for the above
issues, rather than importing a full new upstream release?  A short
description of the issues so we don't have to look them up would also
have been helpful.

Thanks,
Julien

Processed: Re: Bug#841234: jessie-pu: package libiberty/20141014-1

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #841234 [release.debian.org] jessie-pu: package libiberty/20141014-1
Added tag(s) moreinfo.

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

Processed: Re: Bug#840643: jessie-pu: package cups/1.7.5-11+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #840643 [release.debian.org] jessie-pu: package cups/1.7.5-11+deb8u1
Added tag(s) moreinfo.

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

Bug#840643: jessie-pu: package cups/1.7.5-11+deb8u1

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Oct 13, 2016 at 16:28:58 +0200, Didier 'OdyX' Raboud wrote:

> We've been made aware that CUPS' SSL as of Jessie (and Wheezy, but I'll see
> this with the LTS team) is vulnerable to POODLE.
> 
> Here come:
> - patch;
>   str4476-disable-sslv3-and-rc4-by-default.patch
> - git commit series;
>   0001-Disable-SSLv3-and-RC4-by-default-to-address-POODLE-v.patch
>   0002-Refresh-patches.patch
>   0003-cups-1.7.5-11-deb8u2-Debian-release.patch
> - and debdiff
>   cups_1.7.5-11+deb8u2.debdiff
> 
The debdiff is the one we tend to look at, but it looks like it was not
attached.

Cheers,
Julien

Bug#845304: transition: libxtables12

[Simon McVittie]

On Sat, 17 Dec 2016 at 10:14:43 +0100, Julien Cristau wrote:
> On Tue, Dec 13, 2016 at 15:56:47 +, Simon McVittie wrote:
> > Please could someone from the release team set up a manual tracker that
> > also looks at Recommends?
> > 
> Done.

Thanks, but this doesn't seem to be correct: it has

Affected: .build-depends ~ /libxtables-dev/

but that only finds one package, nftables. I think the other packages
indirectly build-depend on libxtables-dev via the transitional
iptables-dev?

Affected: .build-depends ~ /iptables-dev/ | .build-depends ~ 
/libxtables-dev/

might be a better affected set? Or the affected set could be based on
the good and bad expressions, like it is in the automatic tracker.

S

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Julien Cristau]

On Thu, Nov 24, 2016 at 14:52:44 -0500, Antoine Beaupré wrote:

> On 2016-11-24 13:04:21, Julien Cristau wrote:
> > On Tue, Aug  9, 2016 at 11:50:27 -0400, Antoine Beaupré wrote:
> >
> >> This is a tentative of opening the discussion regarding a more regular
> >> update of the youtube-dl package in Debian stable.
> >> 
> > TBH I think this should never have reached stable in the first place...
> 
> So what should happen now? Should it be removed from stretch?
> 
> What do we do with the version that *is* in testing?
> 
> Isn't that what volatile (now -updates) was designed for?
> 
> https://lists.debian.org/debian-volatile-announce/2012/msg0.html
> 
> It explicitly mentions:
> 
> """
>  * Fixes to leaf packages that were broken by external changes (e.g.
>video downloading tools and tor).
> """
> 
So once upon a time libquvi-scripts was supposed to help with that, by
being a relatively self-contained set of per-site lua scripts that could
get updated and then used by a variety of packages.  Unfortunately that
appears to be dead, so I'm not sure what to suggest nowadays.

Cheers,
Julien

Re: [Piuparts-devel] piuparts blocking testing migration

[Andreas Beckmann]

On 2016-12-17 10:03, Julien Cristau wrote:
> I've told britney to ignore that failure for the next run.

Do we have a list of packages blocked from migration by piuparts only?
I might go through that list frequently and file RC bugs or request
piuparts-ignore hints.


Andreas

Bug#847081: transition: libgig

[Jaromír Mikeš]

Od: Julien Cristau 

"On Mon, Dec 5, 2016 at 13:39:56 +0100, Jaromír Mikeš wrote: 

> Package: release.debian.org 
> Severity: normal 
> User: release.debian@packages.debian.org 
> Usertags: transition 
> 
> Hi, 
> new upstream release of libgig bumps SONAME, so we need to transition. 
> I know we have a transition freeze, but this release is already quite old 
and would shame not have it in upcoming debian release. 

If it's already quite old and it's that important then it should have 
been uploaded before the transition freeze, not a month after... "
 

Hi Julien,




yes you are right it should be uploaded sooner ... but I haven't been 
uploader of these packages before.

I started work on them with this uploadcin believe I can upload them in time
and save the situation.

Also quite long time has been taken to sort out some issues with upstream ..
. that's delayed me :(




best regards




mira

Bug#824872: jessie-pu: package nspr/2:4.12-2+deb8u1

[Julien Cristau]

On Tue, Jun 28, 2016 at 12:38:15 +0200, Guido Günther wrote:

> Hi Julien,
> On Tue, Jun 28, 2016 at 11:46:06AM +0200, Julien Cristau wrote:
> > On Sun, May 29, 2016 at 14:58:51 +0200, Guido Günther wrote:
> > 
> > > Upstream has an internal test suite which we enabled for the package
> > > builds in nspr as well as nss (+ some autopkg smoke test in nss
> > > itself). Howver I don't know as to what extend ABI compatibility is
> > > tested upstream. Hopefully Mike (cc:) may have some input on this.
> > > 
> > > In order get some ideas about ABI compatibility myself I ran
> > > abi-compliance-tester. The results for both NSS and NSPR are also
> > > attached. We would do that on all point release updates.
> > > 
> > > Note that the only (as to my understanding) serious regression has been
> > > pointed out by Florian as well:
> > > 
> > > https://lists.debian.org/debian-lts/2015/11/msg00037.html
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1260698
> > > 
> > > and it's unclear if this part of the ABI. The API break (removal of
> > > CERT_FindCertURLExtension) is bogus since the symbol was not exported.
> > > 
> > I don't understand why you seem to be talking about ABI stability
> > issues.  There are other kinds of bugs.
> 
> The "other kind of bugs" were the reason why I enabled the test suites
> in nss/nspr and started to add some autpkg tests. What else would you
> expect?
> 
> We could also add (and run) autopkg tests for reverse dependencies of
> nss/nspr over time.

How many of the nss/nspr reverse dependencies in stable have meaningful
autopkgtests?  Overall my confidence in our QA abilities for stable
updates is pretty low, so I'm not wild about routinely upgrading
libraries to major new versions.  Regressions in stable point releases
that need follow-on fixes are a major PITA.

Cheers,
Julien

Re: [Pkg-utopia-maintainers] Bug#848024: Bug#848024: Fails to connect after upgrade to openvpn 2.4

[Alberto Gonzalez Iniesta]

On Sat, Dec 17, 2016 at 10:46:46AM +0100, Julien Cristau wrote:
> On Tue, Dec 13, 2016 at 19:19:53 +0100, Michael Biebl wrote:
> 
> > Am 13.12.2016 um 18:22 schrieb Michael Biebl:
> > > Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=776045
> > > 
> > > Am 13.12.2016 um 18:02 schrieb Michael Biebl:
> > >> Am 13.12.2016 um 16:53 schrieb Alberto Gonzalez Iniesta:
> > >>> Hi there,
> > >>>
> > >>> The --tls-remote was removed in OpenVPN 2.4, and was already marked as
> > >>> DEPRECATED in OpenVPN 2.3. From OpenVPN 2.3's manpage:
> > >>>
> > >>> Please  also note: This option is now deprecated.  It will be removed
> > >>> either in OpenVPN v2.4 or v2.5.  So please make sure you support the new
> > >>> X.509  name formatting  described  with  the  --compat-names option as
> > >>> soon as possible by updating your configurations to use
> > >>> --verify-x509-name instead.
> > >>>
> > >>> IMHO this should have been fixed in network-manager-openvpn before 2.4
> > >>> arrived.
> > >>
> > >> Ok, thanks for the info.
> > >> I've cloned this bug report for openvpn. It needs a versioned Breaks
> > >> against network-manager-openvpn once a fixed version has been uploaded, 
> > >> to
> > >> avoid breakage on partial uploads.
> > >>
> > >> I'll ping you once such a version is available.
> > > 
> > > I've blocked the two bugs accordingly and forwarded the issue to upstream.
> > 
> > Looking at https://codesearch.debian.net/search?q=tls-remote
> > there are possibly more packages which are affected.
> > Have you notified them about this and/or checked that they are not affected?
> > 
> > I'm not sure if it's a bit late at this point of the release cycle to
> > introduce such a change in openvpn. I've CCed the release-team on their
> > input on this, i.e. whether we want openvpn in stretch 2.4 and how the
> > removal of tls-remote should be handled.
> > 
> Now is not the time to make incompatible changes affecting other
> packages?  How hard would it be to provide backwards compatibility here?

Hi Julien, the change does not affect other packages, but setups
using a deprecated option. A note will be added to NEWS.Debian.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Processed: tagging 784373

[Debian Bug Tracking System]

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

> tags 784373 + moreinfo
Bug #784373 [release.debian.org] jessie-pu: package ceph/0.80.11-1 (pre 
approval)
Added tag(s) moreinfo.
> thanks
Stopping processing here.

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

Bug#844264: release.debian.org: Please clarify "Packages must autobuild without failure"

[Julien Cristau]

On Thu, Dec 15, 2016 at 21:19:23 +0100, Santiago Vila wrote:

> Any progress on this?
> 
> In case it helps, I made a list of bugs in this FTBFS-randomly category:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org
> 
> In almost all cases, the failure happens because there is a test which
> fails.
> 
> So: Why do we allow tests to make the package to fail if we then do
> not consider the failure to be RC?
> 
> IMO, either the program is ok when the test fails, or it's not.
> 
I'm afraid it's more nuanced than this, and trying to make it all white
or all black is not helpful.

Cheers,
Julien

Re: [Pkg-utopia-maintainers] Bug#848024: Bug#848024: Fails to connect after upgrade to openvpn 2.4

[Julien Cristau]

On Tue, Dec 13, 2016 at 19:19:53 +0100, Michael Biebl wrote:

> Am 13.12.2016 um 18:22 schrieb Michael Biebl:
> > Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=776045
> > 
> > Am 13.12.2016 um 18:02 schrieb Michael Biebl:
> >> Am 13.12.2016 um 16:53 schrieb Alberto Gonzalez Iniesta:
> >>> Hi there,
> >>>
> >>> The --tls-remote was removed in OpenVPN 2.4, and was already marked as
> >>> DEPRECATED in OpenVPN 2.3. From OpenVPN 2.3's manpage:
> >>>
> >>> Please  also note: This option is now deprecated.  It will be removed
> >>> either in OpenVPN v2.4 or v2.5.  So please make sure you support the new
> >>> X.509  name formatting  described  with  the  --compat-names option as
> >>> soon as possible by updating your configurations to use
> >>> --verify-x509-name instead.
> >>>
> >>> IMHO this should have been fixed in network-manager-openvpn before 2.4
> >>> arrived.
> >>
> >> Ok, thanks for the info.
> >> I've cloned this bug report for openvpn. It needs a versioned Breaks
> >> against network-manager-openvpn once a fixed version has been uploaded, to
> >> avoid breakage on partial uploads.
> >>
> >> I'll ping you once such a version is available.
> > 
> > I've blocked the two bugs accordingly and forwarded the issue to upstream.
> 
> Looking at https://codesearch.debian.net/search?q=tls-remote
> there are possibly more packages which are affected.
> Have you notified them about this and/or checked that they are not affected?
> 
> I'm not sure if it's a bit late at this point of the release cycle to
> introduce such a change in openvpn. I've CCed the release-team on their
> input on this, i.e. whether we want openvpn in stretch 2.4 and how the
> removal of tls-remote should be handled.
> 
Now is not the time to make incompatible changes affecting other
packages?  How hard would it be to provide backwards compatibility here?

Cheers,
Julien

Bug#847636: Re: unblock node-cpr

[Julien Cristau]

On Sun, Dec 11, 2016 at 17:06:50 +0530, Pirate Praveen wrote:

> On ഞായര്‍ 11 ഡിസംബര്‍ 2016 04:59 വൈകു, Pirate Praveen wrote:
> > Like my previous reply. Won't FTBFS be considered as affecting the
> > package, then it needs to be documented.
> 
> The announcement said "Should your upload to unstable include security fixes 
> or fixes for severe bugs, we file an unblock bug asking for us to lower the 
> required age." I was under the impression that all RC bugs qualify. It would 
> have been better if it said (severity grave or critical then there wouldn't 
> have been any confusion).
> 
> 
As far as testing is concerned, that upload doesn't fix a RC bug there,
since the package, and thus the bug, is not in testing.

Cheers,
Julien

Re: usrmerge (#810158)

[Julien Cristau]

On Thu, Dec  8, 2016 at 21:37:43 +, Nicholas Bamber wrote:

> Do you see any issue with my downgrading #810158 (again!). With usrmerge not
> even in testing I don't see why this is an issue.
> 
Yes, I would consider that bug RC for stretch.  Is there any particular
reason you insist on blocking that change?

Cheers,
Julien

Bug#847081: transition: libgig

[Julien Cristau]

On Mon, Dec  5, 2016 at 13:39:56 +0100, Jaromír Mikeš wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> new upstream release of libgig bumps SONAME, so we need to transition.
> I know we have a transition freeze, but this release is already quite old and 
> would shame not have it in upcoming debian release.

If it's already quite old and it's that important then it should have
been uploaded before the transition freeze, not a month after...

Cheers,
Julien

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Julien Cristau]

On Sat, Dec 17, 2016 at 09:20:40 +0100, Bálint Réczey wrote:

> >> >> Considering that we are already in the transition freeze I suggest
> >> >> going with enabling bindnow for all architectures in dpkg and
> >> >> for Stretch+1 the responsibility of setting some hardening flags
> >> >> could be transferred to gcc.
> >> >> IMO this is not a transition because the change does not affect
> >> >> package interdependencies.
> >> >
> >> > Is there any update on this?
> >
> > I've not seen any reply from the release team, no. And as explicitly
> > mentioned before multiple times now, this has the potential to impact
> > the release by introducing subtle and possibly hard to spot errors at
> > *run-time*, which might be triggered by simple a upload or a binNMU w/o
> > the maintainer being in the loop and knowing they have enabled bindnow.
> > So I want the release team to be involved in ACKing this potentially
> > release breaking change.
> 
> I would like to kindly ask the Release Team to share its position on the
> bindnow question since Guillem don't seem to let this move forward
> without that.
> 
That is very much not happening for stretch.

Cheers,
Julien

Bug#845304: transition: libxtables12

[Julien Cristau]

On Tue, Dec 13, 2016 at 15:56:47 +, Simon McVittie wrote:

> Please could someone from the release team set up a manual tracker that
> also looks at Recommends?
> 
Done.

Cheers,
Julien

Re: piuparts blocking testing migration

[Julien Cristau]

On Fri, Dec 16, 2016 at 22:38:16 +, Dominic Hargreaves wrote:

> Hi,
> 
> I must have missed the memo, but according to
> 
> https://qa.debian.org/excuses.php?package=ircd-hybrid
> 
> this package is not migrating because of a piuparts failure.
> In fact, the failure is not caused by irc-hybrid directly, but because
> of this bug in openssl:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689490
> 
I've told britney to ignore that failure for the next run.

Cheers,
Julien

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi Guillem,

2016-12-17 3:14 GMT+01:00 Guillem Jover :
> On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote:
>> 2016-12-13 9:29 GMT+01:00 Bálint Réczey :
>> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey :
>> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover :
>> >>> My mine concern is and has always been that bindnow changes the
>> >>> run-time behavior (instead of the build-time one) and could break
>> >>> things such as dlopen() on shared libraries or plugins and similar.
>> >>> And detecting problems becomes harder, and reverting this change
>> >>> iff we notice that it breaks too much might imply rebuilding an
>> >>> unspecified number of packages. So in a way it feels kind of like
>> >>> a transition?
>> >>>
>> >>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
>> >>> default in gcc for a long time, but also relro, stack-protector and
>> >>> fortify. Which would seem to imply this might not break that much?
>> >>> (I'm not sure why we are not enabling all those in gcc in Debian
>> >>> too, but that's probably a different conversation to have if at all.)
>> >>
>> >> Lucas already performed the archive-wide rebuild with bindnow
>> >> enabled by dpkg and we have not observed breakages specific to
>> >> bindnow. IMO this is mostly due to packages already disabling
>> >> bindnow through dpkg-buildflags.
>
> But you didn't do the requested archive-wide autopkgtest run (because
> "it was hard"), and even though the coverage is not great it would
> be better than nothing. Requested in this case because bindnow changes
> the *run-time* behavior, which is not visible or noticable in normal
> circumstances by just *building* packages.

I'm surprised you raise the autopkgtest run question.

Have you missed my email about this?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12

2016-10-10 14:06 GMT+02:00 Balint Reczey :
> Dear Guillem,
>
> On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey  
> wrote:
> ...
>> Dear Guillem,
>>
>> As a continuation of the discussions [1][2] on debian-devel I'm
>> attaching the simple patch that implements enabling the bindnow
>> hardening flags.
>>
>> I'm continuing with the rebuild/autopkgtest tests according to
>> the Dpkg FAQ, hence the moreinfo tag.
>
> The rebuild (with PIE and bindnow enabled) resulted ~1000 FTBFS
> cases from which all seem to be related to enabling PIE by
> default [3].
>
> ~70 of the filed related bugs [4] are still open.
>
> Since the rebuild was run with tests enabled this seems to be a
> good indication that we can expect very few breakages from
> enabling bindnow by default.
>
> Running autopkgtest would need more work as AFAIK there is no
> automated method for doing it like rebuilds [5].
>
> I'm wondering if you find the autopkgtest round necessary for
> this change.

You never answered, but I thought you read the whole bug history.

I asked for clarification then because the on 13 Aug you added the
following line to dpkg FAQ which does not seem to be a strong
requirement:
* For flags that change run-time semantics, ideally an additional run
of the autopkgtest for packages that ship them (although this cannot
be deemed conclusive as our coverage is not great yet).
( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff=28=29 )

I would say it would have been really nice to provide a feedback about
your position two months ago because I could set up something to run
the aforementioned autopkgtest run in addition to the archive wide
rebuild which included all build-time tests, but you can still add your
answer to the bug report.

>
>> >> Considering that we are already in the transition freeze I suggest
>> >> going with enabling bindnow for all architectures in dpkg and
>> >> for Stretch+1 the responsibility of setting some hardening flags
>> >> could be transferred to gcc.
>> >> IMO this is not a transition because the change does not affect
>> >> package interdependencies.
>> >
>> > Is there any update on this?
>
> I've not seen any reply from the release team, no. And as explicitly
> mentioned before multiple times now, this has the potential to impact
> the release by introducing subtle and possibly hard to spot errors at
> *run-time*, which might be triggered by simple a upload or a binNMU w/o
> the maintainer being in the loop and knowing they have enabled bindnow.
> So I want the release team to be involved in ACKing this potentially
> release breaking change.

I would like to kindly ask the Release Team to share its position on the
bindnow question since Guillem don't seem to let this move forward
without that.

Thanks,
Balint

>
> I guess this is "The current PIE situation is already an unholy mess"
> (which I'll cover in another mail), so let's make the mess bigger
> approach to releasing the distribution…
>
>> > We are running out of time...
>>
>> I have uploaded a dpkg NMU with