Re: libc recently more aggressive about pthread locks in stable ?

[Lucas Nussbaum]

On 07/11/16 at 21:52 +0100, Lucas Nussbaum wrote:
> Hi,
> 
> On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > > supposed to be disabled via a microcode update.  I don't know whether
> > > glibc avoids using it on these processors if the microcode update is
> > > not applied.  (Linux doesn't appear to hide the feature flags.)
> > 
> > It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> > TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> > 
> > But anything else *will* attempt to use it, people query cpuid directly
> > for these things.  You need a hypervisor that filters cpuid().
> 
> How can one know what glibc does on a given CPU? (preferably without
> access to the hardware)

Answering myself, the relevant patch is
https://sources.debian.net/src/glibc/2.24-5/debian/patches/amd64/local-blacklist-for-Intel-TSX.diff/

Lucas

Re: More 5 november in the release schedule

[Christian Seiler]

On 11/08/2016 08:31 AM, Scott Kitterman wrote:
> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>> Christian Seiler  writes:
>>> Why? Any package currently in testing still has time to enter
>>> (until roughly end of this year), so it's not like there is no
>>> heads-up for people. And RC bugs don't lead to immediate
>>> removal from testing, you still have quite a bit of time until
>>> they actually cause removal of a package.
>>
>> The problem is if the maintainer is not responding to RC bug reports,
>> and you don't realize a package you depend on has RC bugs. This happened
>> several times to me during the last freeze.
> 
> I seem to get email when a package I maintain is marked for autoremoval 
> (regardless of whether it is an issue with my package or an rdepend).  That 
> and it showing up on your DDPO Packages overview ought to be enough to be 
> forewarned, I would have thought.

Yes, especially since autoremovals are not instantaneous, but for
packages with rdeps (and the rdeps themselves) will happen at
least 30 days in the future - and you will get an email in time.
(For packages without rdeps it's 15 days. Plus IIRC a week delay
after a bug was initially marked RC before autoremoval is even
triggered, but I might be wrong about that last part.)

30 days within the deep freeze should be plenty enough - and as I
said: if the problem is more complicated, just talk to the release
team _while the package is still in testing_.

The goal of autoremovals is to provide an incentive for people
to deal with problems in their packages _early_. My experience
with the release team is that they are very willing to consider
many different solutions if you talk to them early enough. They
just don't want people coming along 4 months into the freeze and
telling them "er, yeah, my package got removed 3 months ago, and
I just didn't care about it until now, and during the entire
freeze it didn't really receive much testing, but pretty please
could it be included again?"

And as I said previously: if a maintainer of a dependency of yours
doesn't care: NMUs for RC bugs have a far lower threshold - even
0-day NMUs are possible if the maintainer is really completely
asleep. (DevRef 5.11.1)

Regards,
Christian

Bug#843616: ITP: nixstatsagent -- Nixstats server monitoring agent

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 

* Package name: nixstatsagent
  Version : 1.0.0
  Upstream Author : NIXStats 
* URL : https://github.com/vfuse/nixstatsagent
* License : BSD Simplified License
  Programming Lang: Python
  Description : NixStats server monitoring agent

NixStats (https://nixstats.com) is a web service of monitoring and displaying 
statistics 
of your server performance similar to NodeQuery.
..
This package contains the agent software and a default set of useful plugins.

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Mon, 07 Nov 2016, Lucas Nussbaum wrote:
> On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > > supposed to be disabled via a microcode update.  I don't know whether
> > > glibc avoids using it on these processors if the microcode update is
> > > not applied.  (Linux doesn't appear to hide the feature flags.)
> > 
> > It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> > TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> > 
> > But anything else *will* attempt to use it, people query cpuid directly
> > for these things.  You need a hypervisor that filters cpuid().
> 
> How can one know what glibc does on a given CPU? (preferably without
> access to the hardware)
> 
> I could try to run an archive rebuild on hardware where glibc leverages
> TSX to see what happens.

IMHO it would be better to instrument the locks in glibc with asserts,
instead.  You could use anything to test for pthread API violations,
then.

That said, if you are going to test Intel TSX for real, you need a
Desktop Skylake-based Core i5/i7 or Xeon E3v5 that reports "RTM" in
/proc/cpuinfo.  Some won't.

Not every Skylake model will have it enabled in the first place, and
apparently the firmware can (and some _do_) disable it, especially on
the mobile side.

Please ensure the Skylake firmware has microcode 0x9d/0x9e or later, or
install the latest version of the non-free intel-microcode package.  The
risk of unpredictable behaviour is quite real otherwise, and could mess
up the test results (and corrupt data).

Skylake errata are a nightmare. Note the AVX, AVX2, eDRAM (L4?), and TSX
ones, as well as the power-management ones:

http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v5-spec-update.pdf
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf

Don't attempt to test TSX with perf or intel PT running.  perf is likely
to cause too many aborts, and Intel PT is an errata hell.

As for Broadwell, I don't know which processors would still have TSX
enabled in the first place when running the latest microcode, and we
blacklist most of them in glibc anyway (because almost all Broadwell-*
specification updates list it as either unavailable or unusable), so
they're not a very viable option to test this.

-- 
  Henrique Holschuh

Re: call for participation - Debian contributors survey, 1st ed.

[Henrique de Moraes Holschuh]

On Mon, 07 Nov 2016, Stefano Zacchiroli wrote:
> On Mon, Nov 07, 2016 at 11:22:42PM +0100, Joerg Jaspert wrote:
> > No logging or name is needed, with the set of questions in this survey
> > one only needs a bit of knowledge of Debian and its people to identify a
> > high amount of the survey takers, I think. (I still took it)
> 
> This is becoming an FAQ, so let me address it here instead of just
> waiting for the blog post including its answer to be written.
> 
> Yep, you're absolutely right. And this is in fact why we included in the
> survey announcement a promise to distribute the results only in
> aggregate form, because cross-referencing with Debian info it would be
> easy to deanonymize people.
> 
> So the "thread model" here is not "untrusted/byzantine survey
> organizers" (if you don't trust the organizers you're probably screwed
> anyhow, as we could be lying about not logging IP address or HTTP
> referrers, after all).  The "threat model" is rather: "untrusted readers
> of published survey *results*", which we will aggregate to avoid
> deanonymization.

The threat model is leakage of the non-aggregated survey data, actually.
Which is not only dependent on the survey platform and its handling of
the survey data, but also on the security of said data *after* it leaves
the survey platform.

-- 
  Henrique Holschuh

Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

Dear list,

We are about to push the new lirc to stable. As-is, the package declares 
a dependency on systemd and thus rightfully fails to build on kfreebsd 
platforms. This is a pity since the core software lirc builds fine at 
least on FreeBSD 10.3.


However, lirc contains all sorts of systemd stuff: tweaks in 
rules/dh_auto_install, systemd configuration files, one or two tools. 
The configure script copes with all this and builds a different set of 
files on freebsd.


I'm now trying to wrap my head around how to conditionalize a packet 
such as lirc. I'm coming from Fedora/RPM and used to just spread some

%ifarch in the spec file. Now, is something similar possible in debian?

In particular:
  - How can I handle that kfreebsd should install a different set of files?
  - Is it possible to conditionalize the rules file w r t platform?
  - If so, how?


Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Henrique de Moraes Holschuh]

On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote:
> I'm now trying to wrap my head around how to conditionalize a packet 
> such as lirc. I'm coming from Fedora/RPM and used to just spread some
> %ifarch in the spec file. Now, is something similar possible in debian?

It should be possible, yes.  I am not the best one to explain how, so I
will leave the actual answer to someone that could do it better.  

That said, I think you could get either better (or faster) help on
debian-ment...@lists.debian.org (which I added to Cc:). It is a list
specific to help new maintainers, and doubts about packaging corner
cases are routinely handled there.

-- 
  Henrique de Moraes Holschuh 

Bug#843633: ITP: gnome-shell-extension-disconnect-wifi -- disconnect wifi extension for GNOME shell

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-disconnect-wifi
  Version : 3.22.14
  Upstream Author : Gopi Sankar Karmegam
* URL : https://github.com/kgshank/gse-disconnect-wifi
* License : GPL-3+
  Programming Lang: JavaScript
  Description : disconnect wifi extension for GNOME shell

By default, GNOME Shell doesn't allow you to disconnect from wifi without 
disabling
it completely. This extension adds a menu item that lest you quickly disconnect
from the current wifi network.

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 14:13, Henrique de Moraes Holschuh wrote:

On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote:

I'm now trying to wrap my head around how to conditionalize a packet
such as lirc. I'm coming from Fedora/RPM and used to just spread some
%ifarch in the spec file. Now, is something similar possible in debian?



That said, I think you could get either better (or faster) help on
debian-ment...@lists.debian.org (which I added to Cc:). It is a list
specific to help new maintainers, and doubts about packaging corner
cases are routinely handled there.


Thanks for reply. That said, I'm aware of both lists and posting to 
devel was a deliberate choice. So, if anyone has an actual reply on the 
original post [1], please reply on -devel so we don't run into 
cross-posting problems.



Cheers!

--alec

[1] https://lists.debian.org/debian-devel/2016/11/msg00288.html

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Vincent Danjean]

  Hi,

Le 08/11/2016 à 13:39, Alec Leamas a écrit :
> I'm now trying to wrap my head around how to conditionalize a packet such as 
> lirc. I'm coming from Fedora/RPM and used to just spread some
> %ifarch in the spec file. Now, is something similar possible in debian?

It should be. Here are some quick ideas to improve:

> In particular:
>   - How can I handle that kfreebsd should install a different set of files?

Most (all?) dh_... config files can be executable. See dh-exec(1)
for example.

>   - Is it possible to conditionalize the rules file w r t platform?

GNUMake allows to define conditional parts. Here is an example from owfs:

DEB_HOST_ARCH_OS:=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
ifeq ($(DEB_HOST_ARCH_OS),linux)
CONFIGURE_OPTIONS += --enable-w1
else
CONFIGURE_OPTIONS += --disable-w1
endif

  Regards,
Vincent

>   - If so, how?
> 
> 
> Cheers!
> 
> --alec
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 14:48, Vincent Danjean wrote:

  Hi,

Le 08/11/2016 à 13:39, Alec Leamas a écrit :

I'm now trying to wrap my head around how to conditionalize a packet such as 
lirc. I'm coming from Fedora/RPM and used to just spread some
%ifarch in the spec file. Now, is something similar possible in debian?



It should be. Here are some quick ideas to improve:



  - Is it possible to conditionalize the rules file w r t platform?



GNUMake allows to define conditional parts. Here is an example from owfs:

DEB_HOST_ARCH_OS:=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
ifeq ($(DEB_HOST_ARCH_OS),linux)
CONFIGURE_OPTIONS += --enable-w1
else
CONFIGURE_OPTIONS += --disable-w1
endif


This is exactly what I was looking for here, thanks!


Cheers!

--alec

Bug#843643: ITP: libmoox-buildargs-perl -- Perl role for saving the instantiation arguments

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libmoox-buildargs-perl
  Version : 0.02
  Upstream Author : Aran Deltac 
* URL : https://metacpan.org/release/MooX-BuildArgs
* License : Artistic or GPL-1
  Programming Lang: Perl
  Description : Perl role for saving the instantiation arguments

It is often useful to be able to access the arguments that were
used to create an object in their unadulterated form, before any
coercions or init_args have changed them.  The MooX::BuildArgs role
provides the arguments via the "build_args" attribute.

This package is needed as a dependency for the upcoming ITPs of
my MooX::Role::CloneSet package and, ultimately, my lintian-sort
tool (https://devel.ringlet.net/textproc/lintian-sort/).
I intend to maintain it within the pkg-perl team.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 14:56, Jens Reyer wrote:


Hi Alec [answering on debian-mentor


Hi Jens! thanks for reply! We are in cross-posting hell... redirecting 
to debian-devel



On 08.11.2016 13:39, Alec Leamas wrote:

In particular:
  - How can I handle that kfreebsd should install a different set of

files?

Never done that, but I guess use dh-exec filtering in the
debian/*.install files.


Trying to understand the debhelper, dh-exec  and dh-exec-subst
manpages. However, I just don't get it. All these tools seems to be 
about changing the actual location of certain files by substituting 
various variables with corresponding values.


However, my need is to actually *remove* some files from e. g., 
debian/install since they are not built on kfreebsd. How could I do this?



Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 15:31, Jens Reyer wrote:

On 08.11.2016 15:13, Alec Leamas wrote:




On 08/11/16 14:56, Jens Reyer wrote:


Hi Alec [answering on debian-mentor


Hi Jens! thanks for reply! We are in cross-posting hell... redirecting
to debian-devel


Yup, but I agree with Henrique that mentors would've been the right
list, anyway.


So do I. Next time...



On 08.11.2016 13:39, Alec Leamas wrote:



However, my need is to actually *remove* some files from e. g.,
debian/install since they are not built on kfreebsd. How could I do this?


The dh-exec-filter manpage should help. I assume you want something like:

debian/install:
#! /usr/bin/dh-exec
[!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package


A code search [1] showed that syslog-ng does this, so that package might
be worth looking at.

Greets
jre


[1]
https://codesearch.debian.net/search?q=path%3Adebian%2F.*install+kfreebsd-any



Ah... thanks. There are some great tools in the Debian toolchain 
(codesearch!).  This looks like "problem solved". Thanks!



--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Michael Biebl]

Am 08.11.2016 um 14:48 schrieb Vincent Danjean:

> DEB_HOST_ARCH_OS:=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)

dpkg-dev includes some ready to use makefile snippets which you can
include like

include /usr/share/dpkg/architecture.mk

to just get DEB_HOST_ARCH_OS etc, or

include /usr/share/dpkg/default.mk


This requires dpkg-dev (>= 1.16.1)
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Jens Reyer]

On 08.11.2016 15:13, Alec Leamas wrote:
> 
> 
> 
> On 08/11/16 14:56, Jens Reyer wrote:
> 
>> Hi Alec [answering on debian-mentor
> 
> Hi Jens! thanks for reply! We are in cross-posting hell... redirecting
> to debian-devel

Yup, but I agree with Henrique that mentors would've been the right
list, anyway.


>> On 08.11.2016 13:39, Alec Leamas wrote:
>>> In particular:
>>>   - How can I handle that kfreebsd should install a different set of
>> files?
>>
>> Never done that, but I guess use dh-exec filtering in the
>> debian/*.install files.
> 
> Trying to understand the debhelper, dh-exec  and dh-exec-subst
> manpages. However, I just don't get it. All these tools seems to be
> about changing the actual location of certain files by substituting
> various variables with corresponding values.
> 
> However, my need is to actually *remove* some files from e. g.,
> debian/install since they are not built on kfreebsd. How could I do this?

The dh-exec-filter manpage should help. I assume you want something like:

debian/install:
#! /usr/bin/dh-exec
[!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package


A code search [1] showed that syslog-ng does this, so that package might
be worth looking at.

Greets
jre


[1]
https://codesearch.debian.net/search?q=path%3Adebian%2F.*install+kfreebsd-any

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Christian Seiler]

> However, my need is to actually *remove* some files from e. g.,
> debian/install since they are not built on kfreebsd. How could I do
> this?

cat > debian/$FOO.install <

Bug#843648: ITP: libmoox-role-cloneset-perl -- Perl Moo role for creating updated copies of immutable objects

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libmoox-role-cloneset-perl
  Version : 0.1.0
  Upstream Author : Peter Pentchev 
* URL : https://metacpan.org/release/MooX-Role-CloneSet
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl Moo role for creating updated copies of immutable 
objects

MooX::Role::CloneSet is a role for immutable objects, providing an easy
way to create a new object with some modified properties.  It provides
the cset() method that creates a new object with the specified changes,
shallowly copying all the rest of the original object's properties.

This package is needed as a dependency for the upcoming ITP of
my lintian-sort tool (https://devel.ringlet.net/textproc/lintian-sort/).
I intend to maintain it within the pkg-perl team.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 08/11/2016 à 15:13, Alec Leamas a écrit :

> 
> Trying to understand the debhelper, dh-exec  and dh-exec-subst 
> manpages. However, I just don't get it. All these tools seems to
> be about changing the actual location of certain files by
> substituting various variables with corresponding values.
> 
> However, my need is to actually *remove* some files from e. g., 
> debian/install since they are not built on kfreebsd. How could I do
> this?


You could you debian/install.ARCH files (see man debhelper).

Alternatively, if dh-exec is not enough for you (or you don't get how to
use it), debian/install can be a shell script (or a script in whatever
language, really) that outputs what debian/install should be if it was
not a script:

#! /bin/sh
set -e

if [some condition] then
  echo conditional line
  echo conditional line
fi

echo next line of debian/install
echo next line of debian/install
echo next line of debian/install

exit 0

Regards, Thibaut
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYIeYZAAoJEJOUU0jg3ChARhkP/3eJwlj+CaA7EdtViDHJYKeJ
hUdlVcgEiotaRIb1gCGzUEsLWvVh+NCveRDJiLoy3Fz7zMsEWi5bXBFOb4q6RupS
3aOenXYcX65oJdDOGA3SqUJ5xZQYDKdsbYYq0fantI9XWfu4Jow5biok2nQtL4oi
FS6bBcTkTMxz6zesV4jzxzzS452EmXaVgqwkvz1WUyNQ5rbUScuhF2H8zEpSbEZC
7+dCLqH7nLtWn6OemK/yLdPYrdb+I7wZml33XoB+sC3FPqySvXlfeNBDjIMApDlp
F5Y7cYfUArCrmaPXy4Ra6OHBqBpxhWAt+K3GfAzRC4FOwSb3S54kIKWiRF6aQPmx
ejdBPNtecW2faB2F19gy/tJh9xgUjkKdkTEoMTe8rw1//eJC1wOSstd9WVRPFgce
wZzC8PWOpG+EqODlkeueI+C/LfOhWzFVGEYm9VcJiZ1y9LA/CqaWw/ln8/bGzpTW
7Mt3CW565uQCwM/MjoF8BjO5McC3wShd5MIwNkDUmA19tmSEdoP46vUoenk32Qcc
+4beGjjrubd1SNcDINLN7P9Z2VZ+1/uziBFhXCNOKDI8n2N5Uh+qUbWC0IBFH+EW
qwMQlgLL/MaZBUOaPgh8wYVHCtX31sXCd3/z/T6saFJGCKe+6sauxPpfENA958j3
5uzn4q+EfwT8q4ke9/2g
=nnbQ
-END PGP SIGNATURE-

Bug#843652: ITP: lintian-sort -- reproducibly sort the Lintian tool's output

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: lintian-sort
  Version : 0.1.0
  Upstream Author : Peter Pentchev 
* URL : https://devel.ringlet.net/textproc/lintian-sort/
* License : BSD-2-clause
  Programming Lang: Perl
  Description : reproducibly sort the Lintian tool's output

The lintian-sort tool reorders the messages reported by the lintian(1)
Debian package analysis tool so that they are kept in the same order
between successive builds.  This minimizes the changes that the package
maintainer sees using a file comparison tool (like diff(1)) to check if
any new problems have appeared or any of the old ones have been fixed.

The lintian-sort tool keeps any additional information (lines starting
with "N:") together with the tags they describe; however, it takes care to
put the final "N: 5 tags overridden" message (along with any follow-up
descriptive lines) at the end.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 15:40, Christian Seiler wrote:

However, my need is to actually *remove* some files from e. g.,
debian/install since they are not built on kfreebsd. How could I do
this?


cat > debian/$FOO.install <

OK, got it. Thanks!


That said, if you're using dh-systemd, that shouldn't be necessary.


I'm using dh_systemd_enable...


dh-systemd is a noop on kfreebsd-* and hurd-i386. Also, I just
checked and noticed that I am installing the systemd service in my
packages also on FreeBSD/Hurd so far, and it doesn't FTBFS. I
should probably drop it there (because it's useless), but other
than a tiny amount of disk space it doesn't hurt either. (Obviously
an init script is also present, but not exclusively for non-Linux
ports.)


If it was just the systemd files... I used them as an example. There are 
also some utilities which depends on systemd.



If your package FTBFS, there is probably something else going on
on non-Linux platforms. What is the exact error you're experiencing?


There is no FTBS since the package has a systemd dependency which makes 
the package unbuildable on freebsd. First step is t get rid of that on 
non-linux platfroms, but this is not that hard.



Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 15:50, Thibaut Paumard wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 08/11/2016 à 15:13, Alec Leamas a écrit :



Trying to understand the debhelper, dh-exec  and dh-exec-subst
manpages. However, I just don't get it. All these tools seems to
be about changing the actual location of certain files by
substituting various variables with corresponding values.

However, my need is to actually *remove* some files from e. g.,
debian/install since they are not built on kfreebsd. How could I do
this?



You could you debian/install.ARCH files (see man debhelper).

Alternatively, if dh-exec is not enough for you (or you don't get how to
use it), debian/install can be a shell script (or a script in whatever
language, really) that outputs what debian/install should be if it was
not a script:


OK, the means three ways:

   -  debian/install.ARCH
   -  Using dh-exec/dh-filter
   -  Using a general script.

One of these should certainly work. Thanks for all help!


Cheers!

--alec

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Samuel Thibault]

Thibaut Paumard, on Tue 08 Nov 2016 15:50:01 +0100, wrote:
> Le 08/11/2016 à 15:13, Alec Leamas a écrit :
> > Trying to understand the debhelper, dh-exec  and dh-exec-subst 
> > manpages. However, I just don't get it. All these tools seems to
> > be about changing the actual location of certain files by
> > substituting various variables with corresponding values.
> > 
> > However, my need is to actually *remove* some files from e. g., 
> > debian/install since they are not built on kfreebsd. How could I do
> > this?
> 
> You could you debian/install.ARCH files (see man debhelper).

But it often means duplicating the content, while dh-exec allows to just
put conditionals.

Samuel

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Samuel Thibault]

Jens Reyer, on Tue 08 Nov 2016 15:31:00 +0100, wrote:
> The dh-exec-filter manpage should help. I assume you want something like:
> 
> debian/install:
> #! /usr/bin/dh-exec
> [!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package

For linuxish things, please use

[linux-any] debian/some-linux-only-file /usr/lib/my-package

So that both kfreebsd, hurd, and any future port, get the fix.

Samuel

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Alec Leamas]

On 08/11/16 16:05, Samuel Thibault wrote:

Jens Reyer, on Tue 08 Nov 2016 15:31:00 +0100, wrote:

The dh-exec-filter manpage should help. I assume you want something like:

debian/install:
#! /usr/bin/dh-exec
[!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package


For linuxish things, please use

[linux-any] debian/some-linux-only-file /usr/lib/my-package

So that both kfreebsd, hurd, and any future port, get the fix.


Yup. Been there, done that.

Cheers!

--alec

Re: Bug#843652: ITP: lintian-sort -- reproducibly sort the Lintian tool's output

[Adam Borowski]

On Tue, Nov 08, 2016 at 05:12:30PM +0200, Peter Pentchev wrote:
> * Package name: lintian-sort
>   Description : reproducibly sort the Lintian tool's output
> 
> The lintian-sort tool reorders the messages reported by the lintian(1)
> Debian package analysis tool so that they are kept in the same order
> between successive builds.  This minimizes the changes that the package
> maintainer sees using a file comparison tool (like diff(1)) to check if
> any new problems have appeared or any of the old ones have been fixed.
> 
> The lintian-sort tool keeps any additional information (lines starting
> with "N:") together with the tags they describe; however, it takes care to
> put the final "N: 5 tags overridden" message (along with any follow-up
> descriptive lines) at the end.

Wouldn't it be much better to apply this change to lintian itself?

-- 
Americans: write-in Cthulhu/Dagon today.  They're still lesser evils than
both of your leading candidates this year.

Bug#843668: ITP: drizzle -- Dithered image combination for Python

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-devel@lists.debian.org

* Package name: drizzle
  Version : 1.1
  Upstream Author : Bernie Simon 
* URL : http://spacetelescope.github.io/drizzle/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Dithered image combination for Python

 The drizzle library is a Python package for combining dithered images
 into a single image. This library is derived from code used in
 drizzlepac. Like drizzlepac, most of the code is implemented in the C
 language. The biggest change from drizzlepac is that this code passes
 an array that maps the input to output image into the C code, while
 the drizzlepac code computes the mapping by using a Python
 callback. Switching to using an array allowed the code to be greatly
 simplified.

The package is an upcoming astropy affiliated package and will be
maintained by the Debian Astro Team. A git repository is created at

https://anonscm.debian.org/git/debian-astro/packages/drizzle.git

Best regards

Ole

Re: Bug#843668: ITP: drizzle -- Dithered image combination for Python

[Clint Byrum]

Excerpts from Ole Streicher's message of 2016-11-08 17:24:44 +0100:
> Package: wnpp
> Severity: wishlist
> Owner: Ole Streicher 
> X-Debbugs-Cc: debian-as...@lists.debian.org, debian-devel@lists.debian.org
> 
> * Package name: drizzle
>   Version : 1.1
>   Upstream Author : Bernie Simon 
> * URL : http://spacetelescope.github.io/drizzle/
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Dithered image combination for Python
> 

There was already a drizzle:

https://tracker.debian.org/pkg/drizzle

It's a somewhat defunct fork of MySQL, but I'd definitely suggest to
upstream to change that name to avoid confusion.

In the mean time, I suggest naming the source package python-drizzle.

Re: libc recently more aggressive about pthread locks in stable ?

[Ian Jackson]

Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive about 
pthread locks in stable ?"):
> That said, I am not going to propose any changes to the glibc blacklist
> at this time, unless new information about how well Intel TSX really
> works in Broadwell becomes available.

So you think that the situation with jessie is OK ?

To be fair the only things which I have noticed broken so far are
ghostscript and ogg123 but I'm hardly a typical user.  My footprint
probably involves many fewer multithreaded programs.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Tue, Nov 8, 2016, at 15:39, Ian Jackson wrote:
> Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive
> about pthread locks in stable ?"):
> > That said, I am not going to propose any changes to the glibc blacklist
> > at this time, unless new information about how well Intel TSX really
> > works in Broadwell becomes available.
> 
> So you think that the situation with jessie is OK ?

I better clarify what I meant, sorry about that.

Please take my comment above as in "I am not going to request that the
Broadwell blacklist in glibc be reduced at this time" just because we
got a microcode update that likely fixes any lingering defects in
Broadwell Intel TSX or properly disables it.  

I.e. my comment was about the correctness of the Intel TSX
implementation in up-to-date Broadwell, and not about the misuse of the
libpthreads API that causes programs with shoddy/broken locking to crash
with a SIGSEGV.

I don't think the situation in jessie is OK in the "things that misuse
libpthreads will crash" sense.  However, without some sort of test run,
we don't know how bad it really is, either.  I fear it might be bad, but
I would love to be pleasantly surprised that people did get libpthreads
locking right most of the time...

-- 
  Henrique de Moraes Holschuh 

Re: DEP14 policy for two dots

[Ian Jackson]

Ian Jackson writes ("Re: DEP14 policy for two dots"):
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > On Fri, 04 Nov 2016, Ian Jackson wrote:
> > > My proposal is reversible.  It does not need to be extensible.
> > 
> > So what about "..."? Would it give ".#.#."?
> 
> Yes.  I said (fixing my bug):
> 
>  > Insert "#":
>  >- between each pair of adjacent dots
>  >- after any trailing dot
>  >- before any leading dot
>   - after the `.' of a trailing `.lock'
> 
> The latter is necessary because git reserves .lock.  (!)
> The summary is `add # after any troublesome dot' (discounting leading
> dots which you say are now illegal in Debian).
> 
> I'm running some exhaustive tests to check that this rule is
> sufficient, because I'm not sure I trust the git docs.

I have now:

 * Read the code in git upstream master.  It's not particularly easy
   to analyse conclusively, but I'm pretty sure it doesn't have any
   special cases which involve longer strings than ".lock".  I felt I
   was able to identify the manpage rule corresponding to each element
   of the logic.

 * Conducted an exhaustive search of all strings of length 6
   or less.  Specifically, I generated all strings of between
   zero and 6 characters from this set (in C notation):

   "0123456789"
   "abcdefghijklmnopqrstuvwxyz"
   "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
   ".-+:~"

   filtered them by whether the `parseversion' function in
   dpkg likes them, escaped them with the following perl
   script

 #!/usr/bin/perl -pw
 use strict;

 y/:~/%_/;
 s/\.(?=\.|$|lock$)/.#/g;

   prepended "refs/tags/" to each one and fed them to
   git-check-ref-format (modified to run in a pipe mode).

   I also verified that when I don't escape ".lock", my exhaustive
   search correctly detects the illegal ref name "refs/tags/1.lock"
   genrated by version "1.lock" (and similar).

> The reverse rule is to convert _ and % and delete all #.

Quoted for completeness.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

What to do when a maintainer is blocking maintenance for stretch?

[Peter Colberg]

Dear Debian developers,

A package with a password-changing daemon I am using with a webmail
interface has not seen an upload for 6 years. As a result, minor bugs
have been accumulating at a steady pace, until the package was finally
removed from testing in July due to an FTBFS. Since the maintainer had
been inactive for so long and had not responded to the corresponding
RC bug, I offered to help improve the package back in September.

The maintainer did not respond, so I contacted the MIA team, which
succeeded instantly in getting a response from the maintainer that
they were still active. However, since the maintainer continued to
not respond to the RC bug or to my offer to help, I uploaded an NMU
to DELAYED/7 via sponsorship by debian-mentors.

The package is now back in testing. It is riddled with less-than-RC
issues relating to security, inaccurate licensing, and other QA issues
flagged by lintian. As an alternative to inetd, I would like to ship
a systemd unit that restricts the privileges of the daemon, which runs
as root and currently (unnecessarily) listens on all interfaces.

Improving the package would require significant changes that are not
appropriate for a minimal NMU. With the maintainer not responding to
anything other than MIA requests to retain their maintainer status,
is there any other way to get the package back in shape for stretch?

Regards,
Peter

Re: More 5 november in the release schedule

[Christian Seiler]

On 11/08/2016 08:47 PM, Adrian Bunk wrote:
> On Tue, Nov 08, 2016 at 02:31:04AM -0500, Scott Kitterman wrote:
>> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>>> Christian Seiler  writes:
 Why? Any package currently in testing still has time to enter
 (until roughly end of this year), so it's not like there is no
 heads-up for people. And RC bugs don't lead to immediate
 removal from testing, you still have quite a bit of time until
 they actually cause removal of a package.
>>>
>>> The problem is if the maintainer is not responding to RC bug reports,
>>> and you don't realize a package you depend on has RC bugs. This happened
>>> several times to me during the last freeze.
>>
>> I seem to get email when a package I maintain is marked for autoremoval 
>> (regardless of whether it is an issue with my package or an rdepend).  That 
>> and it showing up on your DDPO Packages overview ought to be enough to be 
>> forewarned, I would have thought.
> 
> For dependencies that is correct.
> 
> But there is currently no kind of notification in place if a 
> build-dependency of your package is scheduled for autoremoval.
> 
> When a build dependency of your package is actually removed from 
> testing, you are also not getting any notification.
> 
> If your build dependency gets removed from testing on Christmas Day
> or later, your package will anyway not be in stretch.

Then this just means that autoremovals should not only take
into account dependencies but also build dependencies,
because then the maintainer would be notified of that fact.

Regards,
Christian

Bug#843699: ITP: opensvc -- Tools to drive OpenSVC services

[Jean-Michel Kelbert]

Package: wnpp
Severity: wishlist
Owner: "Jean-Michel Kelbert" 

* Package name: opensvc
  Version : 1.8
  Upstream Author : Christophe Varoqui 
* URL : http://www.opensvc.com
* License : GPL
  Programming Lang: Python
  Description : Tools to drive OpenSVC services

OpenSVC is a 'service' manager, as in clustered service manager,
designed for real-world heterogeneous datacenters and large-scale
operations orchestrator (disaster recovery, for example).

Services are collections of resources (virtual machine, ip, disk
groups, filesystems, file synchronizations, and application
launchers).

Services can be started, stopped and queried for status,
providing a consistent command set for wildly different
service integration types.

Service configurations, status and logs are pushed to a
central database coupled to a web front-end (collector).

Services can be administered using the stand-alone
GPLv2 software stack deployed on the nodes
(nodeware), or through the web-front end.

Re: Bug#843668: ITP: drizzle -- Dithered image combination for Python

[Ole Streicher]

Clint Byrum  writes:
> Excerpts from Ole Streicher's message of 2016-11-08 17:24:44 +0100:
>> Package: wnpp
>> * Package name: drizzle [...]
>
> There was already a drizzle:
>
> https://tracker.debian.org/pkg/drizzle
>
> It's a somewhat defunct fork of MySQL, but I'd definitely suggest to
> upstream to change that name to avoid confusion.

Wouldn't work.

drizzle is the usual name for a certain type of weighted image
combination, invented from STScI and in use since several years. This is
not going to change. And on pypi, the name was not taken before.

I am not sure how long we want to care about the names of dead
software, especially for not-so-common pieces.

> In the mean time, I suggest naming the source package python-drizzle.

I'll do that. In any case, it will take the "drizzle" namespace of
Python.

Cheers

Ole

Bug#843708: ITP: openha -- Easy high availability clustering

[Jean-Michel Kelbert]

Package: wnpp
Severity: wishlist
Owner: "Jean-Michel Kelbert" 

* Package name: openha
  Version : 0.5.0
  Upstream Author : Christophe Varoqui 
* URL : http://www.opensvc.com
* License : GPL
  Programming Lang: C
  Description : High availability clustering hearbeat

OpenHA heartbeat daemon which proposes multiple multicast heartbeat
paths using a mix of IP and SCSI, and has a flexible trigger support

It can be used with OpenSVC to build and High Availibity solution.

-- 
Jean-Michel Kelbert


signature.asc
Description: PGP signature

Re: misleading timestamps in binnmus

[Guillem Jover]

Hi!

On Tue, 2016-11-08 at 22:41:09 +, Ian Jackson wrote:
> I see the python2.7 source package does this:
> 
>  LAST_CHANGE := $(shell dpkg-parsechangelog -S Date)
>  export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d 
> '$(LAST_CHANGE)')
>  export BUILD_TIME := $(shell LC_ALL=C date -u +'%H:%M:%S' -d 
> '$(LAST_CHANGE)')
> 
> Is this a recommended recipe ?

I think this should be fine. There's also SOURCE_DATE_EPOCH, that
dpkg-buildpackage honors and otherwise sets now, which can be also
retrieved with «dpkg-parsechangelog -STimestamp», but that should not
be needed here anyway, because…

> AIUI a buildd doing a binnmu will not
> modify the debian/changelog file.

… the changelogs do get a new entry, otherwise everything would fall
apart. Something like this:

,---
zlib (1:1.2.8.dfsg-2+b3) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Recompile static libraries with PIE

 -- amd64 / i386 Build Daemon (x86-grnet-01) 
  Sat, 16 Aug 2014 15:12:11 +0100
`---

But I just noticed that the timestamp in this entry seemed suspect,
and it indeed is, as the last maintainer upload was this:

,---
zlib (1:1.2.8.dfsg-2) unstable; urgency=low

  * Drop zlib-bin package as minizip has now been packaged separately,
delay due to lack of notice regarding upload (closes: #753070).

 -- Mark Brown   Sat, 16 Aug 2014 15:12:11 +0100
`---

> The result is that the file timestamps will be lies after a binnmu.  I
> think this is quite undesirable.  Less careful backup programs than
> mine wouldn't notice.  The results would then be a corrupted backup,
> which would break when restored.  There are probably other bad
> consequences.

So the actual problem is that the last timestamp gets reused for the
binNMUs, which seems totally bogus to me. This needs to be fixed in
whatever is injecting the binNMU entries on the buildds.

Thanks,
Guillem

Re: [MBF] Obsoleting bzip2 compression in .deb packages

[Guillem Jover]

Hi!

On Tue, 2016-08-02 at 13:47:49 +0200, Guillem Jover wrote:
> On Wed, 2016-07-06 at 03:19:40 +0200, Guillem Jover wrote:
> > I'd like to obsolete bzip2 (and lzma) as .deb compressors when building
> > binary packages. dpkg-deb currently emits warnings, this would turn them
> > into errors. For lzma it's fine in Debian as the archive has never
> > accepted them. For bzip2 there are currently 31 source packages that
> > produce some binary packages using that compressor:
> > 
> > 
> > 
> > Unpacking *will* keep being supported for the forseeable future so that
> > we can examine old binaries, in the same way dpkg-deb still supports
> > format 0.939000.
> > 
> > I'm attaching the prospective dd-list, and the template bug report. I'd
> > like do the MBF in 1 or 2 weeks, and turn the warnings into errors in
> > the first dpkg release after 1 or 2 months from now. I'm easy if people
> > would like more or less time?
> 
> Thanks to Adam Borowski who handled the QA team packages!
> 
> I've done the MBF [M], and I'm planning on turning the compressor
> deprecation warnings into errors in the first dpkg release happening
> after two weeks from now, at which point I'll upgrade the remaining bugs
> to serious.
> 
>   [M] 
> 

This happened now with the dpkg 1.18.11 upload.

Thanks,
Guillem

Re: misleading timestamps in binnmus

[Ian Jackson]

Guillem Jover writes ("Re: misleading timestamps in binnmus"):
> I think this should be fine. There's also SOURCE_DATE_EPOCH, that
> dpkg-buildpackage honors and otherwise sets now, which can be also
> retrieved with «dpkg-parsechangelog -STimestamp», but that should not
> be needed here anyway, because…
> 
> > AIUI a buildd doing a binnmu will not
> > modify the debian/changelog file.
> 
> … the changelogs do get a new entry, otherwise everything would fall
> apart. Something like this:

I found in the relevant python package that there was a separate
changelog.amd64.  But indeed:

> So the actual problem is that the last timestamp gets reused for the
> binNMUs, which seems totally bogus to me. This needs to be fixed in
> whatever is injecting the binNMU entries on the buildds.

The same is true for libpython2.7-stdlib.

I've dropped the reproducible-builds list and added
debian-wb-team@l.d.o in the hope that they may be able to point us in
the right direction.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: misleading timestamps in binnmus

[Johannes Schauer]

Hi all,

Quoting Ian Jackson (2016-11-08 21:48:12)
> Guillem Jover writes ("Re: misleading timestamps in binnmus"):
> > So the actual problem is that the last timestamp gets reused for the
> > binNMUs, which seems totally bogus to me. This needs to be fixed in
> > whatever is injecting the binNMU entries on the buildds.
> 
> The same is true for libpython2.7-stdlib.
> 
> I've dropped the reproducible-builds list and added
> debian-wb-team@l.d.o in the hope that they may be able to point us in the
> right direction.

it might be sbuild at fault here. Looking at the code that adds the binNMU
entries about here:

http://sources.debian.net/src/sbuild/0.72.0-2/lib/Sbuild/Build.pm/#L2045

It seems that sbuild indeed re-uses the timestamp from the last
debian/changelog entry in the binNMU changelog entry.

Please file a bug report against sbuild with an explanation of what should be
the correct behaviour that sbuild should follow here, i.e. which date should
sbuild put into the binNMU entry and why?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#843717: ITP: tablator -- Universal table translator for astronomy

[Walter Landry]

Package: wnpp
Severity: wishlist
Owner: Walter Landry 

* Package name: tablator
  Version : 1.0.0
  Upstream Author : Walter Landry 
* URL : https://github.com/Caltech-IPAC/tablator
* License : GPL
  Programming Lang: C++
  Description : Universal table translator for astronomy

Tablator is a utility for converting tables in astronomy into
different formats.  Tablator can read and write tables in fits, ipac
table, hdf5, votable, json, json5, csv, and tsv, and can write html.
The emphasis is on speed, so all conversions are done in memory.

Bug#843718: ITP: golang-github-tideland-golib -- collection of misc Go packages

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-tideland-golib
  Version : 4.12.0-1
  Upstream Author : Frank Mueller 
* URL : https://github.com/tideland/golib
* License : BSD-3-clause
  Programming Lang: Go
  Description : Tideland Go Library

 The Tideland Go Library contains a set of useful Google Go packages for
 different purposes. They include:
 .
  - Audit: Support for unit tests with mutliple different assertion types
and functions to generate test data.
  - Cache: Lazy loading and caching of values.
  - Collections: Different additional collection types like ring buffer,
stack, tree, and more.
  - Errors: Detailed error values.
  - Etc: Reading and parsing of SML-formatted configurations including
substituion of templates.
  - Feed (Atom): Atom feed client.
  - Feed (RSS): RSS feed client.
  - Identifier: Identifier generation, like UUIDs or composed values.
  - Logger: Flexible logging.
  - Loop: Control of goroutines and their possible errors. Additional
option of recovering  in case of an error or a panic. Sentinels can
monitor multiple loops and restart them all in case of an abnormal end
of one of them.
  - Map/Reduce: Map/Reduce for data analysis.
  - Monitoring: Monitoring of execution times, stay-set indicators, and
configurable system variables.
  - Numerics: Different functions for statistical analysis.
  - Redis Client: Client for the Redis database.
  - Scene: Context-based shared data access, e.g. for web sessions or in cells.
  - Scroller: Continuous filtered reading/writing of data.
  - SML: Simple Markup Language, looking lispy, only with curly braces.
  - Sort: Parallel Quicksort.
  - Stringex: Helpful functions around strings extending the original
strings package.
  - Timex: Helpful functions around dates and times.
  - Version: Documentation of semantic versions.

Re: More 5 november in the release schedule

[Paul Wise]

On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:

> Right. We want auto-removals to be useful for the release process, so that we
> don't end up with a thousand of RC bugs in testing when we freeze, most of 
> them
> on packages that nobody cares about, not even their maintainers.
>
> However, we don't want auto-removals to drop your package behind your back. If
> that happens, that's a bad thing and you should let us know so we can fix
> things. auto-removals should notify the maintainer in advance, and only act
> after a reasonable period of time.
>
> The "packages can't re-enter testing during the freeze" is an incentive so 
> that
> maintainers don't wait to fix a package after a few months, and so that we 
> don't
> have to go and remove them manually. This way you know that something is going
> to happen if you don't act, yet you should have a reasonable amount of time to
> do something. Hopefully this helps have a short(er) freeze, which is good for
> everyone.

FYI, it looks like at least buildd stuff (IIRC that uses dose3),
rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
on jessie until the affected packages reach stretch-backports as a
result of the autoremovals stuff:

https://lists.debian.org/debian-services-admin/2016/10/msg2.html

I guess alioth will remain on wheezy too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: More 5 november in the release schedule

[Brian May]

Scott Kitterman  writes:

> I seem to get email when a package I maintain is marked for autoremoval 
> (regardless of whether it is an issue with my package or an rdepend).  That 
> and it showing up on your DDPO Packages overview ought to be enough to be 
> forewarned, I would have thought.

That will help in some cases, but not all cases.

Can't remember what happened for my particular cases. I should look up
the details and refresh my memory, but out of time now.

One situation I can think of: If for example the package is not yet in
testing, you will not get notified that it depends on a broken package
and as such will not get into testing. So you can mistakenly think it is
a simple package, it has no bugs, and not realize it isn't in testing.

Another situation: You are not listed as the maintainer of the package
you really care about, and the real maintainer ignores the autoremoval
notifications. Other people looking at the package bug reports (there
may be none) may not realize it is pending autoremoval.
-- 
Brian May