Bug#819530: Bad interation with libstdc++ transition.

[Niels Möller]

Adrian Bunk  writes:

> This sounds like a problem in apt to me, and I've seen issues like
> that before.
>
> What does apt say for
>   apt-get install -t testing libstdc++6 build-essential
> ?

The following packages have unmet dependencies:
 perl : Depends: perl-base (= 5.20.2-3+deb8u6) but 5.24.1~rc3-3 is to be 
installed
Depends: perl-modules (>= 5.20.2-3+deb8u6)
Recommends: rename but it is not going to be installed
 perl-base : Breaks: perl (< 5.24.1~rc3~) but 5.20.2-3+deb8u6 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

> If it gives an error, manually add the packages it cannot install on the 
> commandline, until you either found the actual dependency problem or apt
> found a way forward.

If I add perl too, it's back to uninstalling kde.

> When apt found a way forward, and if it still wants to remove packages 
> you want to keep, also add them on the commandline.

I tried that earlier, but gave up since the number of dependency
problems just seemed to grow. But if I keep doing that, without giving
up, I eventually find a resolution not uninstalling lots of packages
by using

apt-get install -t testing libstdc++6 build-essential perl kde-standard \
  juk libtag1v5 libtag1v5-vanilla akregator kio libkf5libkdepim-plugins \
  libkf5libkdepim5 libkf5wallet5 libkwalletbackend5-5 libkf5notifications5 \
  phonon4qt5 k3b vlc

Thanks! (Now remaining problem is that I don't have the needed 1GB+ available
space on /var, but I'll sort that out one way or the other).

I still think it's unfortunate that the libicu upgrade requires all of that.

Thanks for the help,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Bug#842206: nmu: Please binNMU bmusb against newer libusb-1.0

[Steinar H. Gunderson]

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

Hi,

bmusb can benefit strongly from being linked to libusb-1.0 (>= 2:1.0.21-1).
Do you think it would be possible to schedule a binNMU for all architectures?
Once upon a time, the format was something like

nmu bmusb_0.5.2-2 . ANY . -m "Rebuild against libusb-1.0 version with support 
for zerocopy USB."

Thanks!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#819530: Bad interation with libstdc++ transition.

[Adrian Bunk]

On Wed, Oct 26, 2016 at 10:39:08PM +0200, Niels Möller wrote:
> Hi,
> 
> as a user, I experience a pretty bad interaction between this transition
> and the recent libstdc++ transition.
> 
> I have a system with a mix of packages from stable and testing, which
> usually works fine. However, upgrading to the latest libstdc++ at this
> point breaks a lot of things due to gcc-6 C++ incompatibilities (which I
> don't fully understand, I usually don't care much about C++). What I see
> is that apt-get install -t testing libstdc++6 would have to uninstall
> *lots* of stuff, including build-essential, texlive, libreoffice and
> most of kde. So I don't want to do that at this time.
>...

This sounds like a problem in apt to me, and I've seen issues like
that before.

What does apt say for
  apt-get install -t testing libstdc++6 build-essential
?

If it gives an error, manually add the packages it cannot install on the 
commandline, until you either found the actual dependency problem or apt
found a way forward.

When apt found a way forward, and if it still wants to remove packages 
you want to keep, also add them on the commandline.

> Regards,
> /Niels

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Next d-i release

[Cyril Brulebois]

Philipp Kern  (2016-10-26):
> On 10/26/2016 08:24 PM, Cyril Brulebois wrote:
> > Samuel Thibault  (2016-10-23):
> >> We have the newer brltty release, 5.4, which provides support for some
> >> more devices, and fixes various issues. It has been tested for some time
> >> in experimental and sid now, so I feel quite safe about it, but it'd be
> >> probably useful to have it for testing in d-i sooner than later.
> > ACK, thanks. It migrated on its own already.
> 
> It'd also be nice if zipl-installer could still make it. #840230 is
> pretty nasty.

Yeah, I noticed already, but thanks for confirming/pointing that out:
| kibi@armor:~$ ssh respighi.debian.org head -6 hints/kibi
| # 2016-10-26
| # d-i Stretch Alpha 8
| unblock-udeb debootstrap/1.0.85
| urgent debootstrap/1.0.85
| unblock-udeb zipl-installer/0.0.35
| urgent zipl-installer/0.0.35


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i release

[Philipp Kern]

On 10/26/2016 08:24 PM, Cyril Brulebois wrote:
> Samuel Thibault  (2016-10-23):
>> We have the newer brltty release, 5.4, which provides support for some
>> more devices, and fixes various issues. It has been tested for some time
>> in experimental and sid now, so I feel quite safe about it, but it'd be
>> probably useful to have it for testing in d-i sooner than later.
> ACK, thanks. It migrated on its own already.

It'd also be nice if zipl-installer could still make it. #840230 is
pretty nasty.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#819530: Bad interation with libstdc++ transition.

[Niels Möller]

Hi,

as a user, I experience a pretty bad interaction between this transition
and the recent libstdc++ transition.

I have a system with a mix of packages from stable and testing, which
usually works fine. However, upgrading to the latest libstdc++ at this
point breaks a lot of things due to gcc-6 C++ incompatibilities (which I
don't fully understand, I usually don't care much about C++). What I see
is that apt-get install -t testing libstdc++6 would have to uninstall
*lots* of stuff, including build-essential, texlive, libreoffice and
most of kde. So I don't want to do that at this time.

Directly broken packages on my system are

$ aptitude search -F '%c %p %V' 
'?and(?installed,?reverse-breaks(?and(?name("libstdc\\+\\+6$"),?version("6\\.2\\..*"'
i libboost-date-time1.55.0 1.55.0+dfsg-3 
i libkolabxml1 1.0.2-2   
i libreoffice-core 1:4.3.3-2+deb8
i libstdc++6   4.9.2-10  
i libstdc++6:i386

This is the background, and now I would like to upgrade to libicu57,
because that blocks upgrade of wget, making it a "kept back" packet.
Dependency chain: wget-1.18 -> libpsl5 -> libicu57.

Now the interesting part: libicu57 has a dependency on libstdc++6 (>=
5.2). So it doesn't need gcc-6, gcc-5 is good enough. But the
libstdc++6 packages for gcc-5 are no longer in the archive, the only
versions available as far as I can find are 4.9.2-10 (which I have
installed), and 6.2.0-6, and the latter one breaks half of the world, as
described above. And then non-existence of version 5.x (x >= 2) of
libstdc++6 makes the libicu upgrade depend on upgrading libstdc++6 to
gcc-6, even though it shouldn' have to.

I've looked at the mirror I use, I'd expect libstdc++6 version 5.x to be
located in main/g/gcc-5/, but it's not there. I don't really understand
the process, but I guess the packages were deleted when gcc-6 migrating
to testing?

I don't know what to do about it, maybe it is an issue for the release
team, but I though I should raise the problem here first. To untangle
the transitions, one would need an libicu57 with a libstdc++6 dependency
which can be satisfied by some package which (i) is older than gcc-6 and
(ii) is actually installable from the package archive. Options I see
(not sure what's possible):

* Recompile libicu57 with gcc-4. 

* Resurrect gcc-5 libstdc++6 library packages in the archive.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. 
Internet email is subject to wholesale government surveillance.

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-10-26 21:31:26 [+0200], Kurt Roeckx wrote:
> > Is this situation
> > supported or should we expect things to break? This can easily happen if an 
> > app
> > links against a library libA which uses openssl 1.0, and against libB which 
> > uses
> > openssl 1.1.
> 
> When linking you actually get a warning.
> 
> As far as I know, it should only break when they use dlopen().
> They most likely won't be using dlvsym() in that case and then it
> can pick any version. It could of course also break if they do
> very weird things.

One of the weird things would be probably if libA allocate a SSL pointer
and passes it to libB.

> Kurt

Sebastian

Bug#827061: transition: openssl

[Kurt Roeckx]

On Wed, Oct 26, 2016 at 08:53:56PM +0200, Emilio Pozuelo Monfort wrote:
> 
> Adrian Bunk asked whether mixing both OpenSSL versions into the same address
> space works fine. Is OpenSSL using symbol versioning?

Yes, and all symbols have a different version name in 1.0.2 and
1.1.0. (What is actually the important thing.)

> Is this situation
> supported or should we expect things to break? This can easily happen if an 
> app
> links against a library libA which uses openssl 1.0, and against libB which 
> uses
> openssl 1.1.

When linking you actually get a warning.

As far as I know, it should only break when they use dlopen().
They most likely won't be using dlvsym() in that case and then it
can pick any version. It could of course also break if they do
very weird things.

But I guess we'll have to see if something breaks or not.


Kurt

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

On 26/10/16 10:55, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 25/10/16 20:09, Moritz Muehlenhoff wrote:
>> On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote:
>>> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote:

 I'm sorry but I'm going to have to nack this for Stretch, as much as I 
 like to
 approve transitions and get new stuff in. I have looked at the opened bugs 
 and
 I'm afraid this still is too disruptive. I have noticed that you have 
 forwarded
 some of them and sent patches, and I appreciate that. We can do this early 
 in
 the Buster cycle, so let's look at the status of this and prepare for the
 transition when Stretch gets released.
>>>
>>> Is having 2 version of OpenSSL in Stretch an option?
>>
>> We've discussed this within the security team and we'd be fine with
>> a one-time exception to have two openssl releases in stretch; the API
>> changes are clearly too invasive to cover the entire Debian archive,
>> but 1.1 also carries sufficiently important new features (like support
>> for chacha20/poly1305) to warrant the extra complexity.
>>
>> (It's the release team's call of course).
> 
> 19:46 <  nthykier> pochu: seen jmm_ reply to the libssl thread?
> 19:46 <  jcristau> adsb: yay for binary debdiffs in q-v!  thanks a bunch.
> 19:46 < pochu> yep
> 19:47 < pochu> nthykier: so my concern was there was a big risk that we
> wouldn't finish the transition intime, delaying the release. but if the 
> security
> team is fine with (potentially, as I'll try not to) shipping both, then we
> should be fine, and I think I'll ack it
> 19:48 < pochu> of course we'll still try to get rid of the old one
> 19:48 <  nthykier> ack, I think that just made me pro on doing that as well
> 19:48 < pochu> cool, good to see we're on the same page
> 
> So let's do this. Let's try to get it finished and only ship openssl 1.1. We
> still have three months until the full freeze, and depending on how many
> packages (and which ones, for risk management etc) are left to be fixed after
> that, I may be happy to grant exceptions. But worst case we just ship both.
> 
> But please, wait a little bit so that we can sort out the PIE fallout. You can
> start preparing the updates and upload to experimental to clear NEW if you 
> want.
> We'll let you know once it's ok to upload to sid.
> 
> BTW I noticed Fedora has started this transition as well, so they may have 
> some
> patches that we are missing in the BTS.
> 
> Also, please bump all the bugs to serious.

Adrian Bunk asked whether mixing both OpenSSL versions into the same address
space works fine. Is OpenSSL using symbol versioning? Is this situation
supported or should we expect things to break? This can easily happen if an app
links against a library libA which uses openssl 1.0, and against libB which uses
openssl 1.1.

Cheers,
Emilio

Processed: block 827061 with 828245 828348 828476

[Debian Bug Tracking System]

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

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

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

Re: Next d-i release

[Cyril Brulebois]

Samuel Thibault  (2016-10-23):
> We have the newer brltty release, 5.4, which provides support for some
> more devices, and fixes various issues. It has been tested for some time
> in experimental and sid now, so I feel quite safe about it, but it'd be
> probably useful to have it for testing in d-i sooner than later.

ACK, thanks. It migrated on its own already.


KiBi.


signature.asc
Description: Digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-26 19:03, Sebastiaan Couwenberg wrote:

On 10/26/2016 06:46 PM, Gilles Filippini wrote:
I've checked the build of every reverse dependencies. These few ones 
are of concern:

* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no 
reverse dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon 
about 300 - no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - 
rather low popcon
* ants : in progress; build depends on insighttoolkit4 - raher low 
popcon


From the above packages, the only real concern is pytables. A 
discussion is ongoing on debian-science@d.o, and I'm confident we'll 
find a solution before the Stretch freeze.


pytables does have several reverse dependencies, who in turn have
several reverse dependencies too. pytables in the dependency chain of
geopandas, having it removed from stretch would be very sad.


Ooops, sorry, I didn't noticed that. Actually I checked weeks ago and 
didn't remember there were reverse depends. My bad.
But as said above, I'm confident we'll find a solution for pytables 
before the Strtch freeze. It would be removed from testing only for a 
while.



insighttoolkit4 is in the dependency chain of otb, and like pytables
having it removed from stretch would be very sad. Even more than 
pytables.


I've successfully tested today a full insighttoolkit4 build for unstable 
on a stronger box than mine. I'll rebuild tomorrow against hdf5-1.10. 
I'm rather confident about this one too.


Thanks,

_g.

Bug#842177: transition: hdf5

[Sebastiaan Couwenberg]

On 10/26/2016 06:46 PM, Gilles Filippini wrote:
> I've checked the build of every reverse dependencies. These few ones are of 
> concern:
> * libsis-jhdf5-java : unmaintained upstream - low popcon
> * pytables : doesn't support new hdf5 API - popcon about 3000 - no reverse 
> dependencies
> * yorick-hdf5 : desing flaw - no support for 64bits integers - popcon about 
> 300 - no reverse dependencies
> * insighttoolkit4 : in progress; looking for a box with enough RAM - rather 
> low popcon
> * ants : in progress; build depends on insighttoolkit4 - raher low popcon
> 
> From the above packages, the only real concern is pytables. A discussion is 
> ongoing on debian-science@d.o, and I'm confident we'll find a solution before 
> the Stretch freeze.

pytables does have several reverse dependencies, who in turn have
several reverse dependencies too. pytables in the dependency chain of
geopandas, having it removed from stretch would be very sad.

insighttoolkit4 is in the dependency chain of otb, and like pytables
having it removed from stretch would be very sad. Even more than pytables.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Release Team,

I hereby request a transition slot for hdf5 1.10 currently in experimental. 
This release ships major changes and has its soname bumped from 10 to 100.

Ben file:

title = "hdf5";
is_affected = .depends ~ /libhdf5.*-10([^0]|$)/ | .depends ~ /libhdf5.*-100/;
is_good = .depends ~ /libhdf5.*-100/;
is_bad = .depends ~ /libhdf5.*-10([^0]|$)/;


I've checked the build of every reverse dependencies. These few ones are of 
concern:
* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no reverse 
dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon about 300 
- no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - rather low 
popcon
* ants : in progress; build depends on insighttoolkit4 - raher low popcon

- From the above packages, the only real concern is pytables. A discussion is 
ongoing on debian-science@d.o, and I'm confident we'll find a solution before 
the Stretch freeze.


Full report:
===[ Dependency level 0 ]=
hdf5:   binnmu OK
nanopolish: binnmu OK
octave-communications:  binnmu OK
===[ Dependency level 1 ]=
chemps2: hdf5   patch provided via #841954
field3d: hdf5   binnmu OK
freefem++: hdf5 binnmu OK
h5py: hdf5  binnmu OK
h5utils: hdf5   binnmu OK
hdf-eos5: hdf5  binnmu OK
ismrmrd: hdf5   patch provided via #841959
jhdf: hdf5  binnmu OK
libcgns: hdf5   binnmu OK
libgpiv: hdf5   patch provided via #841962
libmatio: hdf5  binnmu OK
libmstoolkit: hdf5  binnmu OK
libpdl-io-hdf5-perl: hdf5   patch provided via #841963
libsis-jhdf5-java: hdf5 KO hard coded hid_t as jint all over 
the source; upstream site dead (http://wiki-bsse.ethz.ch/)
libvigraimpex: hdf5 binnmu OK
mapsembler2: hdf5   binnmu OK
med-fichier: hdf5   patch provided via #841964
meep: hdf5  binnmu OK
meep-lam4: hdf5 binnmu OK
meep-mpi-default: hdf5  binnmu OK
meep-mpich2: hdf5   binnmu OK
meep-openmpi: hdf5  binnmu OK
mpb: hdf5   binnmu OK
ncbi-vdb: hdf5  binnmu OK
netcdf: hdf5binnmu OK
nexus: hdf5 binnmu OK
octave: hdf5binnmu OK
opengm: hdf5binnmu OK
pbseqlib: hdf5  binnmu OK
pytables: hdf5  KO - doesn't support hdf5-1.10 yet
r-cran-hdf5: hdf5   binnmu OK
seer: hdf5  binnmu OK
shark: hdf5 binnmu OK
shogun: hdf5FTBFS unrelated to hdf5 - not in 
testing - #809290
silo-llnl: hdf5 binnmu OK
slurm-llnl: hdf5binnmu OK
stimfit: hdf5   binnmu OK
tessa: hdf5 FTBFS unrelated to hdf5 - not in 
testing - #817690
trilinos: hdf5  binnmu OK
xdmf: hdf5  binnmu OK
yorick-hdf5: hdf5   KO Yorick doesn't support 64bits 
integers (hid_t)
===[ Dependency level 2 ]=
adios: hdf5 netcdf  binnmu OK
aster: hdf5 med-fichier FTBFS unrelated to hdf5 - not in 
testing - #837915
blasr: hdf5 pbseqlibbinnmu OK
cmor: hdf5 netcdf   binnmu OK
code-saturne: hdf5 libcgns med-fichier  binnmu OK
comet-ms: libmstoolkit  binnmu OK
deal.ii: hdf5 netcdf trilinos   BD uninstallable - not in testing
gdal: hdf5 netcdf   binnmu OK
grads: hdf5 netcdf  binnmu OK
grib-api: hdf5 netcdf   binnmu OK
labplot: hdf5 netcdfbinnmu OK
libminc: hdf5 netcdfpatch provided via #841970
mathgl: hdf5 octave binnmu OK
nco: netcdf binnmu OK
ncview: netcdf  binnmu OK
netcdf4-python: hdf5 netcdf binnmu OK
octave-netcdf: netcdf   binnmu OK
ovito: hdf5 netcdf  binnmu OK
paraview: hdf5 netcdf xdmf  binnmu OK
psi4: chemps2 hdf5  binnmu OK
pygpiv: hdf5 libgpivbinnmu OK
python-shogun: hdf5 shogun 

Processed (with 1 error): Re-add missing openssl transition blockers (see #820044)

[Debian Bug Tracking System]

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

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

[PATCH] Fix arguments to find

[Emilio Pozuelo Monfort]

We were getting:

find: Arguments to -type should contain only one letter

Fixes the urgency log cleanup.

Signed-off-by: Emilio Pozuelo Monfort 
---
 config/debian/daily.functions | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/debian/daily.functions b/config/debian/daily.functions
index 110aa82..0576733 100644
--- a/config/debian/daily.functions
+++ b/config/debian/daily.functions
@@ -62,5 +62,5 @@ function contributor() {
 # Clean up urgency log
 function cleanurgencylog() {
 log "Cleaning up urgency log"
-find /srv/ftp.debian.org/web/britney/urgencies -type -f -mtime +15 -delete
+find /srv/ftp.debian.org/web/britney/urgencies -type f -mtime +15 -delete
 }
-- 
2.9.3

Processed: libcrypt-openssl-dsa-perl block openssl 1.1 transition

[Debian Bug Tracking System]

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

> # This block by libcrypt-openssl-dsa-perl was wrongly removed
> block 827061 by 828384
Bug #827061 [release.debian.org] transition: openssl
827061 was blocked by: 841635
827061 was not blocking any bugs.
Added blocking bug(s) of 827061: 828384
> thanks
Stopping processing here.

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

Bug#842084: marked as done (nmu: openscad_2015.03-2+dfsg-1)

[Debian Bug Tracking System]

Your message dated Wed, 26 Oct 2016 11:47:53 +0200
with message-id 
and subject line Re: Bug#842084: nmu: openscad_2015.03-2+dfsg-1
has caused the Debian Bug report #842084,
regarding nmu: openscad_2015.03-2+dfsg-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.)


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

nmu openscad_2015.03-2+dfsg-1 . ANY . experimental . -m "Rebuild against cgal 
4.9."

Let's finish the cgal transition in experimental, too.


Andreas
--- End Message ---
--- Begin Message ---
On 25/10/16 20:43, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu openscad_2015.03-2+dfsg-1 . ANY . experimental . -m "Rebuild against cgal 
> 4.9."
> 
> Let's finish the cgal transition in experimental, too.

Scheduled.

Emilio--- End Message ---

Bug#842135: release.debian.org: nmu: slepc4py_3.7.0-2+b3

[Drew Parsons]

On Wed, 26 Oct 2016 10:37:40 +0200 Emilio Pozuelo Monfort  wrote:
> 
> Done, including deal.ii getdp slepc4py and dolfin.

Thanks.
 
> I don't quite understand why slepc and petsc have versioned packages
and use
> alternatives to provide the shared library, but I haven't looked
closely at it.
> Not sure I want to though :P


Since you asked ;) ...

PETSc upstream has arranged the library so that the preferred version
can be easily identified with env variable PETSC_DIR.

Each installation (referenced by PETSC_DIR) is patch specific, i.e. the
library is located in /usr/lib/petscdir/3.7.3 or
/usr/lib/petscdir/3.7.4 etc. This allows the "flexibility" of parallel
installation of different patch versions.

But the soname only contains the minor version, 3.7 not 3.7.4.

slepc just follows the structure of petsc.

I guess what you're asking is why upstream bothers providing patch-
specific installations when the soname is the same between them. 
Upstream will have to speak for themselves, but I could imagine that
doing it that way makes it easier to manage installations on high
performance supercomputers.  Installations on the supercomputers tend
to be conservative. They worry about differences in the results of
computations arising from different patch versions, even though the
client software will happily run with any version with the same soname.

Whatever upstream's reasons might be,  I've set up the Debian packaging
to reflect this patch-version "flexibility" provided by the upstream
directory structure.

Drew

Processed: Re: Bug#827061: transition: openssl

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #827061 [release.debian.org] transition: openssl
Added tag(s) confirmed.

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

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 25/10/16 20:09, Moritz Muehlenhoff wrote:
> On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote:
>> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote:
>>>
>>> I'm sorry but I'm going to have to nack this for Stretch, as much as I like 
>>> to
>>> approve transitions and get new stuff in. I have looked at the opened bugs 
>>> and
>>> I'm afraid this still is too disruptive. I have noticed that you have 
>>> forwarded
>>> some of them and sent patches, and I appreciate that. We can do this early 
>>> in
>>> the Buster cycle, so let's look at the status of this and prepare for the
>>> transition when Stretch gets released.
>>
>> Is having 2 version of OpenSSL in Stretch an option?
> 
> We've discussed this within the security team and we'd be fine with
> a one-time exception to have two openssl releases in stretch; the API
> changes are clearly too invasive to cover the entire Debian archive,
> but 1.1 also carries sufficiently important new features (like support
> for chacha20/poly1305) to warrant the extra complexity.
> 
> (It's the release team's call of course).

19:46 <  nthykier> pochu: seen jmm_ reply to the libssl thread?
19:46 <  jcristau> adsb: yay for binary debdiffs in q-v!  thanks a bunch.
19:46 < pochu> yep
19:47 < pochu> nthykier: so my concern was there was a big risk that we
wouldn't finish the transition intime, delaying the release. but if the security
team is fine with (potentially, as I'll try not to) shipping both, then we
should be fine, and I think I'll ack it
19:48 < pochu> of course we'll still try to get rid of the old one
19:48 <  nthykier> ack, I think that just made me pro on doing that as well
19:48 < pochu> cool, good to see we're on the same page

So let's do this. Let's try to get it finished and only ship openssl 1.1. We
still have three months until the full freeze, and depending on how many
packages (and which ones, for risk management etc) are left to be fixed after
that, I may be happy to grant exceptions. But worst case we just ship both.

But please, wait a little bit so that we can sort out the PIE fallout. You can
start preparing the updates and upload to experimental to clear NEW if you want.
We'll let you know once it's ok to upload to sid.

BTW I noticed Fedora has started this transition as well, so they may have some
patches that we are missing in the BTS.

Also, please bump all the bugs to serious.

Cheers,
Emilio

Bug#842137: marked as done (nmu: dolfin_2016.1.0-5)

[Debian Bug Tracking System]

Your message dated Wed, 26 Oct 2016 10:38:23 +0200
with message-id 
and subject line Re: Bug#842137: nmu: dolfin_2016.1.0-5
has caused the Debian Bug report #842137,
regarding nmu: dolfin_2016.1.0-5
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.)


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

nmu dolfin_2016.1.0-5 . amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32 alpha ppc64 . 
unstable . -m "Rebuild against slepc 3.7.3+dfsg1-2 (Provides virtual 
libslepc3.7, libslepc-complex-3.7)"

thanks

Provision of virtual packages libslepc3.7, libslepc-complex-3.7 makes
shlib dependencies more sane, reducing the urgency of binNMUs against
SLEPc in the future.

mips64el, sparc64 are already built against slepc 3.7.3+dfsg1-2


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 26/10/16 10:33, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu dolfin_2016.1.0-5 . amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32 alpha ppc64 . 
> unstable . -m "Rebuild against slepc 3.7.3+dfsg1-2 (Provides virtual 
> libslepc3.7, libslepc-complex-3.7)"
> 
> thanks
> 
> Provision of virtual packages libslepc3.7, libslepc-complex-3.7 makes
> shlib dependencies more sane, reducing the urgency of binNMUs against
> SLEPc in the future.
> 
> mips64el, sparc64 are already built against slepc 3.7.3+dfsg1-2

Done, see #842135.

Emilio--- End Message ---

Bug#842135: marked as done (nmu: slepc4py_3.7.0-2+b3)

[Debian Bug Tracking System]

Your message dated Wed, 26 Oct 2016 10:37:40 +0200
with message-id 
and subject line Re: Bug#842135: release.debian.org: asdasd
has caused the Debian Bug report #842135,
regarding nmu: slepc4py_3.7.0-2+b3
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.)


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

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Drew Parsons 
To: Debian Bug Tracking System 
Subject: nmu: slepc4py_3.7.0-2+b3
Message-ID: 
<147746397798.2727.2988347581649171064.report...@grendel.emerall.com>
X-Mailer: reportbug 6.6.6
Date: Wed, 26 Oct 2016 14:39:37 +0800

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

nmu slepc4py_3.7.0-2+b3 . amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32 . unstable . -m 
"Rebuild against slepc 3.7.3+dfsg1-2 (Provides virtual libslepc3.7, 
libslepc-complex-3.7)"

thanks

Provision of virtual packages libslepc3.7, libslepc-complex-3.7 makes
shlib dependencies more sane, reducing the urgency of binNMUs against
SLEPc in the future.

alpha, mips64el, ppc64, sparc64 are already built against 
slepc 3.7.3+dfsg1-2 

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

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

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 26/10/16 10:23, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> 
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> From: Drew Parsons 
> To: Debian Bug Tracking System 
> Subject: nmu: slepc4py_3.7.0-2+b3
> Message-ID: 
> <147746397798.2727.2988347581649171064.report...@grendel.emerall.com>
> X-Mailer: reportbug 6.6.6
> Date: Wed, 26 Oct 2016 14:39:37 +0800
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu slepc4py_3.7.0-2+b3 . amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32 . unstable . -m 
> "Rebuild against slepc 3.7.3+dfsg1-2 (Provides virtual libslepc3.7, 
> libslepc-complex-3.7)"
> 
> thanks
> 
> Provision of virtual packages libslepc3.7, libslepc-complex-3.7 makes
> shlib dependencies more sane, reducing the urgency of binNMUs against
> SLEPc in the future.
> 
> alpha, mips64el, ppc64, sparc64 are already built against 
> slepc 3.7.3+dfsg1-2 

Done, including deal.ii getdp slepc4py and dolfin.

I don't quite understand why slepc and petsc have versioned packages and use
alternatives to provide the shared library, but I haven't looked closely at it.
Not sure I want to though :P

Cheers,
Emilio--- End Message ---

Processed: nmu: slepc4py_3.7.0-2+b3

[Debian Bug Tracking System]

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

> retitle 842135 nmu: slepc4py_3.7.0-2+b3
Bug #842135 [release.debian.org] release.debian.org: asdasd
Changed Bug title to 'nmu: slepc4py_3.7.0-2+b3' from 'release.debian.org: 
asdasd'.
> thanks
Stopping processing here.

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

Bug#842137: nmu: dolfin_2016.1.0-5

[Drew Parsons]

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

nmu dolfin_2016.1.0-5 . amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32 alpha ppc64 . 
unstable . -m "Rebuild against slepc 3.7.3+dfsg1-2 (Provides virtual 
libslepc3.7, libslepc-complex-3.7)"

thanks

Provision of virtual packages libslepc3.7, libslepc-complex-3.7 makes
shlib dependencies more sane, reducing the urgency of binNMUs against
SLEPc in the future.

mips64el, sparc64 are already built against slepc 3.7.3+dfsg1-2


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

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

Bug#842135: release.debian.org: asdasd

[Drew Parsons]

Package: release.debian.org
Severity: normal

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Drew Parsons 
To: Debian Bug Tracking System 
Subject: nmu: slepc4py_3.7.0-2+b3
Message-ID: 
<147746397798.2727.2988347581649171064.report...@grendel.emerall.com>
X-Mailer: reportbug 6.6.6
Date: Wed, 26 Oct 2016 14:39:37 +0800

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

nmu slepc4py_3.7.0-2+b3 . amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32 . unstable . -m 
"Rebuild against slepc 3.7.3+dfsg1-2 (Provides virtual libslepc3.7, 
libslepc-complex-3.7)"

thanks

Provision of virtual packages libslepc3.7, libslepc-complex-3.7 makes
shlib dependencies more sane, reducing the urgency of binNMUs against
SLEPc in the future.

alpha, mips64el, ppc64, sparc64 are already built against 
slepc 3.7.3+dfsg1-2 

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

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

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

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

Re: status of tzdata package in stable and oldstable

[Erdem Bayer]

Hello

Thanks for fast response and actions, 2016h is in jessie now, this 
update was very important for turkish users.


Kind Regards
Erdem Bayer


On 10/25/2016 02:10 PM, Adam D. Barratt wrote:

On 2016-10-25 10:18, Erdem Bayer wrote:

According to #838781, Turkey has a significant timezone change at the
end of this month. Although both the 2016g and 2016h updates from IANA
has been in unstable and testing for a long time, these updates are
not included in stable and oldstable releases yet. Also the
tzdata-java package from the same tzdata source package is not
generated in testing, and this makes it impossible to update the
package manually from testing because of missing dependency of
tzdata-java. Could you please look into this and update the package to
stable and oldstable repos as soon as possible?


Debian's Release Team is not responsible for the oldstable 
distribution currently - you will need to contact the LTS team to 
discuss that. debian-release@lists.debian.org is also not a general 
support list. If you want to enquire about the status of a package in 
stable, contacting the package maintainer would be the most 
appropriate first port of call.


tzdata 2016h has been in testing for one day and in unstable for less 
than a week - that's really not "a long time". An update for stable 
will be available via the stable-updates repository within the next 
few days and will be announced on the debian-stable-announce list as 
usual.


Regards,

Adam