Andreas Tille | 25 Oct 18:36 2014

Bug#766769: nmu: beast-mcmc_1.8.0-1

Severity: normal
User: <at>


as written on debian-mentors I was wondering why beast-mcmc does not
migrate.  Niels recommended that I should file a bug which I'm doing
hereby.  Remark:  In addition what Niels said below I would like to
mention that one of the binary packages is actually amd64 only:

  Package: libnucleotidelikelihoodcore0
  Architecture: amd64

I have no idea whether this might be the problem or the solution.

Kind regards


On 2014-10-25 13:00, Andreas Tille wrote:
> Hi,
> says:
>   beast-mcmc/i386 unsatisfiable Depends: libnucleotidelikelihoodcore0 (>= 1.8.0-1) 
> but I have asked ftpmaster for removal of beast-mcmc from arch i386 and
(Continue reading)

Mehdi Dogguy | 25 Oct 15:17 2014

Freeze-exception for Opam


I recently uploaded Opam 1.2.0~rc4 (for the first time in Debian)
a few days ago. It should be able to migrate, in time before the
freeze, in testing.

A short time after my upload, upstream released 1.2.0. I expected
1.2.0~rc4 to be close to 1.2.0. It turns out that both are generated
from the same git commit. I can live with 1.2.0~rc4 in Jessie but I
think that it will create some confusion among the users and won't be
ideal. Since there are no source changes, updating to 1.2.0 in Jessie
should be "harmless".

Dear team, would you allow me to upload 1.2.0 to Jessie after migration
of 1.2.0~rc4?




Thomas Goirand | 25 Oct 09:25 2014

OpenRC status in Jessie

Dear Release Team,

I thought it was best to write now, rather than after the freeze.

It's looking like we're falling a bit behind with OpenRC for Jessie. The
main reason is that I was taking care of it, but got busy with the
release of OpenStack Juno (which is currently in Experimental). Since,
some other DDs took a bit over my work, namely Ritesh Raj Sarraf (and
others). What worries me currently are the 2 RC bugs we have:

#765785 openrc: can't cope with dangling rc.d links
#763681 openrc: FTBFS[armel,armhf,ppc64el]

The first one can't really fully be attributed to OpenRC. In a normal
situation, there shouldn't be any rc.d dangling symlink, and that may
only happen because of bad postinst not removing them in other packages.
Never the less, this should be addressed, though I am not entirely sure
what we should do. Should we simply clean the /etc/rcX.d folders in the
preinst of OpenRC? Advices welcome. It shouldn't be so hard to fix...

The 2nd one is due to the dependency loop resolving not being written
fully correctly. This is a little bit more a concern, due to the fact
that it's a quite complex code. However, I'm convince that we can fix
the situation. Worst case, we could simply remove the patch, but this
isn't desirable in Debian (while it's ok upstream), because it's needed
due to lots of init scripts having bad LSB header dependencies (yes, we
don't "see" the consequences with sysv-rc...), and it's also needed for
parallel booting. In fact, this patch fixed the remaining issues when
doing concurrency booting, which is IMO important.

(Continue reading)


(Без темы)

Добрый день коллеги!
Я предлагаю услуги организации, которая занимается
таможенным оформлением: сантехники, керамики,
пластиковых труб, фитингов, насосов, пластмассы и
гранита) и доставкой по морю грузов из Китая за 30 дней.
Действует спецпредложение по таможенному
оформлению ниже рисков!
Сообщите, пожалуйста, заинтересованы ли в
комплексных услугах по доставке с растаможкой?
 с уважением, Борис Николаевич


To UNSUBSCRIBE, email to debian-release-REQUEST <at>
with a subject of "unsubscribe". Trouble? Contact listmaster <at>
Archive: <at>

Debian FTP Masters | 25 Oct 00:47 2014

NEW changes in stable-new

Processing changes file: mumble_1.2.3-349-g315b5f5-2.2+deb7u2_sparc.changes

Bas Couwenberg | 25 Oct 00:23 2014

Bug#766694: nmu: gdal_1.11.1+dfsg-1~exp1

Severity: normal
User: <at>
Usertags: binnmu

nmu gdal_1.11.1+dfsg-1~exp1 . ALL . experimental . -m "Rebuild for jpeg-turbo transition."

libgdal-dev in experimental is currently uninstallable, and is required to
build libgdal-grass 1.11.1 (#764951).

Kind Regards,


Rob Browning | 24 Oct 19:23 2014

Inclusion or exclusion of Emacs 24.4 (jessie)

I've uploaded emacs24 24.4+1-1 to experimental, and it seems fine on the
buildds now (at least the ones that have taken it):

And I suspect 24.4 may be easier to support, including the facility of
upstream help.  For what it's worth, they're quite responsive, and I
believe are in favor of inclusion.

But it does represent a large change right up against the freeze
migration threshold deadline (tomorrow?).


Rob Browning
rlb  <at> and  <at>
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Ole Streicher | 24 Oct 11:08 2014

Please rebuild starlink-ast


please put the package back into the build queue to overcome a non-reproducible build error:

 gb starlink-ast_8.0.2+dfsg-1 . armhf

Thank you


YunQiang Su | 24 Oct 08:48 2014

Please binNMU opal with new ptlib on mips64el and arm64


The previous version of ptlib didn't define P_64BIT for
ppc64el and arm64 (and mips64/mips64el), which make
opal ftbfs on these archs

  nmu opal_3.10.10~dfsg-2.2 . arm64 ppc64el -m "Build with ptlib with
P_64BIT defined, see: #748911"

Thibault Cohen | 24 Oct 04:40 2014

Shinken packages strange state


I don't really know if I write to the right persons

We think we have a problem with the last package of Shinken in FTP.

This package seems to be in strange state in the FTP.

It seems this is due to the transition from any to all.

We opened a bug here:
But we are not sure that is the good place to report this bug

Please note: with the migration from any to all we fix this bug:

I know you don't have a lot of time right now, but please help us to
fix this !

Thanks for your answer !

Thibault Cohen

Sam Hartman | 24 Oct 04:16 2014

Bug#766569: Please reduce time for freeradius 2.2.5+dfsg-0.2


FreeRADIUS upstream decided it would be a good idea to include a patch
requiring that the version of  OpenSSL and run-time was exactly the same
as the version of OpenSSL at build time.

Apparently ssh decided something similar in the past and we have a local
patch there to think differently for Debian.

I've adopted a similar approach in 2.2.5+dfsg-0.2.  My rationale is that
I trust our OpenSSL maintainers to bump the soname if they break the

Unfortunately, I didn't notice this before the latest OpenSSL update
entered Jessie.  So, the FreeRADIUS now in Jessie is completely useless;
it fails on startup.
I'd appreciate it if you would reduce the time so that 2.2.5+dfsg-0.2
can enter Jessie.

freeradius (2.2.5+dfsg-0.2) unstable; urgency=high

  * Disable OpenSSL version check; Debian will maintain ABI stability or
    change the soname, Closes: #765871
    * Non-Maintainer Upload

 -- Sam Hartman <hartmans <at>>  Thu, 23 Oct 2014 21:45:36 -0400