Bug#941837: texlive-fonts-extra: file conflice with (older) texlive-fonts-extra-links

[Ansgar Burchardt]

Package: texlive-fonts-extra
Version: 2019.20190930-2
Severity: serious

Hi,

when upgrading in Debian testing I saw the following error message:

+---
| Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ...
| dpkg: error processing archive 
/tmp/apt-dpkg-install-h6VDTu/50-texlive-fonts-extra_2019.20190930-2_all.deb 
(--unpack):
|  trying to overwrite 
'/usr/share/texlive/texmf-dist/fonts/opentype/arkandis/berenisadf/BerenisADFProSC-Bold.otf',
 which is also in package texlive-fonts-extra-links 2019.20190830-1
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
+---

It looks like texlive-fonts-extra is missing a (versioned) Replaces on
texlive-fonts-extra-links.

Thanks for maintaining LaTeX in Debian,
Ansgar

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'buildd-unstable'), 
(300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-fonts-extra depends on:
it  tex-common6.12
ii  texlive-base  2019.20190930-1

Versions of packages texlive-fonts-extra recommends:
ii  fonts-adf-accanthis0.20190904-1.1
ii  fonts-adf-berenis  0.20190904-1.1
ii  fonts-adf-gillius  0.20190904-1.1
ii  fonts-adf-universalis  0.20190904-1.1
ii  fonts-cabin1.5-2
ii  fonts-comfortaa3.001-2
ii  fonts-croscore 20181227-1
ii  fonts-crosextra-caladea20130214-2
ii  fonts-crosextra-carlito20130920-1
ii  fonts-dejavu-core  2.37-1
ii  fonts-dejavu-extra 2.37-1
ii  fonts-ebgaramond   0.016-1
ii  fonts-ebgaramond-extra 0.016-1
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  fonts-freefont-otf 20120503-9
ii  fonts-freefont-ttf 20120503-9
ii  fonts-gfs-artemisia1.1-5
ii  fonts-gfs-complutum1.1-6
ii  fonts-gfs-didot1.1-6
ii  fonts-gfs-neohellenic  1.1-6
ii  fonts-gfs-olga 1.1-5
ii  fonts-gfs-solomos  1.1-5
ii  fonts-go   0~20170330-1
ii  fonts-junicode 1.002-1
ii  fonts-lato 2.0-2
ii  fonts-linuxlibertine   5.3.0-4
ii  fonts-lobstertwo   2.0-2
ii  fonts-noto-hinted  20181227-1
ii  fonts-noto-mono20181227-1
ii  fonts-oflb-asana-math  000.907-6
ii  fonts-open-sans1.11-1
ii  fonts-roboto-unhinted  2:0~20170802-3
ii  fonts-sil-gentium  20081126:1.03-2
ii  fonts-sil-gentium-basic1.102-1
ii  fonts-sil-gentiumplus  5.000-2
ii  fonts-sil-gentiumplus-compact  5.000-2
ii  fonts-stix 1.1.1-4
iu  texlive-fonts-extra-links  2019.20190930-2
ii  texlive-fonts-recommended  2019.20190930-1
iu  texlive-latex-extra2019.20190930-2

Versions of packages texlive-fonts-extra suggests:
ii  cm-super 0.3.4-15
iu  texlive-fonts-extra-doc  2019.20190930-2

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.6.1

Versions of packages texlive-fonts-extra is related to:
it  tex-common6.12
ii  texlive-binaries  2019.20190605.51237-3

-- debconf information excluded

Bug#941273: runit: FTBFS (looks like endless loop)

[Ansgar Burchardt]

Package: src:runit
Version: 2.1.2-34
Severity: serious

I noticed that the last runit build is already taking over 13h on
buildds.  The hppa build log[1] looks like the build failed due to an
endless loop.

I asked the other builds to be killed.

Ansgar

  [1] 
https://buildd.debian.org/status/fetch.php?pkg=runit&arch=hppa&ver=2.1.2-34&stamp=1569581954&raw=0

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Ansgar Burchardt]

Michael Biebl writes:
> On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt  wrote:
>> I'm just a GNOME user, but from gdm3's changelog the default was
>> switched to Wayland in July 2017 (or August 2017 for unstable).  I
>> myself only noticed the switch after reading it happened somewhere on
>> the internet shortly after it happened.
[...]
> When you talk about "gdm3's default", what exactly do you mean: the
> display technology gdm is using or the type of GNOME session that is
> started as default?

I meant the GNOME session; that is the only thing that changed in
July/August 2017 as gdm itself used Wayland already before as far as I
understand.

For something that has been the default for almost two years to be
switched back two weeks before the release there has to be some really
huge issues for me.  Any change will not see much testing given the time
after all and risks new regressions.

Ansgar

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Ansgar Burchardt]

Jonathan Dowland writes:
> So far as I am aware there is still radio silence from active GNOME
> packaging team members regarding this issue. No comment yet on the
> patch I adapted, positive or negative; this bug (#927667) remains
> at an RC severity.
>
> I've not yet read all the thread that Samuel linked to[1] but it looks
> like it leans in favour of preserving the current default (xorg).
>
> I'm copying -release team to see if they have any (new) opinions on
> the matter. Otherwise I guess it's up to someone to prepare an NMU
> upload, which I will *try* to look at in the next few days, but can't
> make any guarantees.

I'm just a GNOME user, but from gdm3's changelog the default was
switched to Wayland in July 2017 (or August 2017 for unstable).  I
myself only noticed the switch after reading it happened somewhere on
the internet shortly after it happened.

Switching the default back two weeks before the release seems too late
for me.  The largest issue seems to be accessibility, but as far as I
understand we already recommend a different desktop environment for
that.  I don't think that warrants changes that would only see very
little testing by now :-/

Ansgar

Bug#926215: dune-pdelab: FTBFS with gcc 8.3

[Ansgar Burchardt]

On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote:
> [ Ansgar: If you still can reproduce the assertion failure, please
> file
>   a new bug. It's better not to mix different issues in the same report ].

The other assertion failure I had also disappeared this week.  Not sure
if there is a real bug, but I don't have time to look at this too much.

Before it was reproducible, unless I rebuilt dune-grid which made the
problem in dune-pdelab go away as well...

Ansgar

Bug#926215: dune-pdelab: FTBFS with gcc 8.3

[Ansgar Burchardt]

Control: reassign -1 src:dune-pdelab 2.6~20180302-1
Control: retitle -1 dune-pdelab: testpk fails with assertion failure

On Mon, 2019-04-08 at 08:42 +0200, Ansgar Burchardt wrote:
> This is a bug in dune-istl, though I'm not quite sure I understand
> what
> is exactly wrong.  Renaming the template argument from `T` to `T1` in
> the definition of `prolongateVector` makes the problem go away, but the
> name of template arguments shouldn't really matter?
> 
> There is also a template argument `T` in the generic version of the
> `Transfer` class...  Maybe that results in the confusion in some way?

That problem went away with a GCC update, but there is still a problem
with a test in dune-pdelab that now fails...  Not sure yet if the
problem is in dune-grid or dune-pdelab for that one, reassigning to
dune-pdelab for now:

+---
| check_mesh: checking mesh 'DUNE AlbertaGrid'
| checking done; no error detected
| AlbertaGrid< 2, 2 > created from macro grid file 
'/<>/dune/pdelab/test/grids/ldomain.al'.
| GridParameterBlock: Parameter 'refinementedge' not specified, defaulting to 
'ARBITRARY'.
| testpk: 
/build/dune-grid-yp9bpw/dune-grid-2.6.0/dune/grid/albertagrid/elementinfo.hh:488:
 bool Dune::Alberta::ElementInfo::isLeaf() const [with int dim = 2]: 
Assertion `!(*this) == false' failed.
+---

Ansgar

Bug#917535: debian-archive-keyring: ftp-master key for buster

[Ansgar Burchardt]

Niels Thykier writes:
> We need new archive signing keys for buster, so we can include them in
> a debian-archive-keyring upload before the buster release.

The two keys are prepared; I'm waiting for a few more signatures from
other ftp masters.

FWIW they will be:

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
  5E61B217265DA9807A23C5FF4DFAB270CAA96DFA
uid   [  full  ] Debian Security Archive Automatic Signing Key 
(10/buster) 
sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]
  5237CEEEF212F3D51C74ABE0112695A0E562B32A

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
  80D15823B7FD1561F9F7BCDDDC30D7C23CBBABEE
uid   [  full  ] Debian Archive Automatic Signing Key (10/buster) 

sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]
  0146DC6D4A0B2914BDED34DB648ACFD622F3D138

and are also signed by the old signing key.

Ansgar


signature.asc
Description: PGP signature

Bug#926215: dune-pdelab: FTBFS with gcc 8.3

[Ansgar Burchardt]

Control: reassign -1 src:dune-istl 2.6.0-2
Control: affects -1 src:dune-pdelab

Santiago Vila writes:
> /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches 
> 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const 
> Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T, const 
> Dune::Amg::SequentialInformation&, const Redist&)'
>  Transfer::prolongateVector(const 
> AggregatesMap& aggregates,
>  ^~~~
> /usr/include/dune/istl/paamg/transfer.hh:62:19: note: candidates are: 
> 'template template static void 
> Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const 
> Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const 
> Dune::Amg::SequentialInformation&)'
>static void prolongateVector(const AggregatesMap& aggregates, 
> Vector& coarse, Vector& fine,
>^~~~
> /usr/include/dune/istl/paamg/transfer.hh:57:19: note: 
> 'template template static void 
> Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const 
> Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const 
> Dune::Amg::SequentialInformation&, const Redist&)'
>static void prolongateVector(const AggregatesMap& aggregates, 
> Vector& coarse, Vector& fine,
>^~~~
> /usr/include/dune/istl/paamg/transfer.hh:50:11: note: 'class 
> Dune::Amg::Transfer' defined here
>  class Transfer
>^

This is a bug in dune-istl, though I'm not quite sure I understand what
is exactly wrong.  Renaming the template argument from `T` to `T1` in
the definition of `prolongateVector` makes the problem go away, but the
name of template arguments shouldn't really matter?

There is also a template argument `T` in the generic version of the
`Transfer` class...  Maybe that results in the confusion in some way?

Ansgar

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Ansgar Burchardt]

On Wed, 20 Mar 2019 15:59:40 + Dimitri John Ledkov 
 wrote:
> On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar Burchardt  wrote:
> > Hi,
> >
> > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> > than just libpq5: just looking at a small sample of the direct rdeps of
> > libssl1.1, one can find the following GPL-licensed programs linking it:
> >
> >   cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete
> >
> 
> Cryptsetup has a linking exception for OpenSSL:
> https://tracker.debian.org/media/packages/c/cryptsetup/changelog-22.1.0-2

It has half of an exception.  COPYING includes the following:

+---
| In addition, as a special exception, the copyright holders give
| permission to link the code of portions of this program with the
| OpenSSL library under certain conditions as described in each
| individual source file, and distribute linked combinations
| including the two.
+---

But the "certain conditions as described in each individual source
file" are nowhere to be found; instead source files only say they are
licensed under GPL (without any exception).

Also, libcryptsetup12 has GPL-2+ rdeps (w/o any exception).  So the
problem only gets ever larger...

Examples:

  libcryptsetup12
  -> cryptmount (GPL-2+, no exception)

  libcryptsetup12
  -> libvolume-key1 (GPL-2, no exception)
  -> libblockdev-crypto2 (LGPL-2.1+, no problem)
  -> udisks2 (GPL-2+, no exception)

And indeed:

+---
| % ldd /usr/lib/udisks2/udisksd | grep libssl
| libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7ff0c6009000)
+---

Ansgar

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Ansgar Burchardt]

Hi,

On Wed, 2019-03-20 at 16:31 +0100, Ansgar Burchardt wrote:
> the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> than just libpq5: just looking at a small sample of the direct rdeps
> of
> libssl1.1, one can find the following GPL-licensed programs linking
> it:
> 
>   cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete
> 
> Also amanda-client, validns as they contain patches in d/patches
> licensed under the GPL.
> 
> There are probably lots more, especially when you start looking at
> libraries (and their whole dependency trees).
> 
> There is also cups which was reported to switch to Apache-2 which is
> also GPL-2-incompatible...  That has lots of rdeps too (including for
> example all GTK applications).

Also Python programs which often use libssl and are GPL-licensed.

> Fedora treats OpenSSL as a "system library"[1].  I would guess they
> might do the same for libcups too.

I also came up with another interesting problem:  libgcc and other low-
level runtime libraries are licensed under GPL-3+-with-some-exception. 
However for a GPL-2-only program FOO with *no* system library
exception, the complete source code would include libgcc and would
require libgcc do be available under a GPL-2-compatible license...  The
runtime exception from libgcc doesn't help as FOO would need an
exception...

(I.e. the same problem just with libgcc instead of libssl)

Ansgar

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Ansgar Burchardt]

Hi,

the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
than just libpq5: just looking at a small sample of the direct rdeps of
libssl1.1, one can find the following GPL-licensed programs linking it:

  cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete

Also amanda-client, validns as they contain patches in d/patches
licensed under the GPL.

There are probably lots more, especially when you start looking at
libraries (and their whole dependency trees).

There is also cups which was reported to switch to Apache-2 which is
also GPL-2-incompatible...  That has lots of rdeps too (including for
example all GTK applications).

Fedora treats OpenSSL as a "system library"[1].  I would guess they
might do the same for libcups too.

Ansgar

  [1] 
https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F

Bug#922202: src:mandos: modifies d/control during build

[Ansgar Burchardt]

Package: src:mandos
Version: 1.8.3-2
Severity: serious

d/rules modifes d/control during build:

```
override_dh_shlibdeps-arch:
[...]
dpkg --compare-versions $$gnutls_version lt 3.6.0 \
&& sed --in-place --expression='s/libgnutls28-dev (>= 3\.6\.6) 
| //' debian/control
```

Please don't modify d/control in any way that is automatically run
during build; see also the "CDBS" entry of [1].

Ansgar

  [1] https://ftp-master.debian.org/REJECT-FAQ.html

Bug#916957: julia (source): missing source for contrib/windows/7zS.sfx

[Ansgar Burchardt]

Package: src:julia
Version: 0.7.0-2
Severity: serious

Hi,

the source for contrib/windows/7zS.sfx seems to be missing.  As the
file is probably not needed for Debian, it could just be removed from
Debian's source tarball.

Ansgar

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Hi,

Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie  wrote:
>> >   - What is the problem? (broken build for which packages? Just R?)
>> 
>> The problem we're aware of is:
>> 
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl) and hard-code it into their output (for example the #! line
>> of the bash scripts in quilt).
>
>  Can we check and track this behavior in our packages?

The Reproducible Builds project was so kind to help and now runs one
build in a non-merged-/usr and a second build in a merged-/usr
environment.  Packages that hardcode the path to utilities, but would
pick up the wrong one in a merged-/usr environment will result in a
difference between the two builds and can thus be found.

See [1] for an overview of issues found this way; as the entire archive
was already rebuilt in this setup, there shouldn't be many more issues
of this type that we don't know about[2].

Not all of these differences even cause issues as in a few packages the
utility with the hardcoded path is not even used at all.

Bug reports were already submitted for over half the packages, often
including a simple patch (usually something like adding BASH=/bin/bash
to dh_auto_configure).

So we look to be on a good track to address the remaining issues.

I don't think that the debootstrap default has to be reverted
temporarily again to deal with this: there are only very few packages
causing problems and these should have a patch soon.

In addition one has to actually built one of the very few packages in a
merged-/usr environment and then install them in a non-merged-/usr
environment to actually trigger the problem and debootstrap already
defaults to non-merged-usr for buildd chroots for now.

Ansgar

  [1] 
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
  [2] https://bugs.debian.org/914897#81

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Adam Borowski writes:
> On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
>> In very rare cases (an estimated 0.3% of the archive or so).  I'm fairly
>> confident that for more than 0.3% of the archive something can go wrong
>> when building in non-clean environments.
>
> Your figure of ~80 packages counts only packages which went through a
> reproducible-builds rebuild.

So only all?

> We later learned only a part of the archive got rebuilt since the bad
> debootstrap backport.

Yes, some packages were not yet rebuilt in testing, but having them
rebuilt in unstable is enough.

>> We had the discussion (usrmerge as default) already quite some time
>> ago.  Why start again at zero?  As a random reference, the D-I Stretch
>> RC 1 release announcement explicitly stated:
>> 
>> +---
>> |  * The switch to merged-/usr as the default setting for debootstrap
>> |was reverted since it uncovered a number of important issues which
>> |might not be all fixed in time for stretch. This setting is
>> |expected to come back as the default at the beginning of the next
>> |release cycle.
>> +---
>> 
>> And just that happened (except a bit later).
>
> Except that the change went live only on 2018-11-10, then waited until
> buildds recreated their chroots, then until dinstall and mirror push...

No, anyone using testing/unstable to setup a new build chroot since June
should have gotten a merged-/usr chroot.  That no issues were found
earlier is probably related to there being not so many issues.

  (Fun fact: there are ~3k debootstrap installations on
  testing/unstable, compared to 6.2k on stable and 2k on oldstable
  according to popcon.)

Anyway, buildds are not using merged-/usr, so there is no problem with
them.

> and the sky started falling immediately after that.

Hmm, two packages or so were reported to be broken.  That is a quite
high standard for "sky falling".

What would you call an upload that breaks more packages?  The monthly
apocalypse which we deal with just fine?

>> You could have easily asked the tech-ctte back then (or even before)
>> instead of waiting until shortly before the Buster freeze and after
>> people invested more work.
>
> It was only shortly before the Buster freeze that we saw this change in
> action!  Had the switch get flipped sooner we'd have a chance to see the
> results.  By now, it's much too late to fix things before the freeze
> (and I don't see how they could be fixed even had we two years of
> time).

You keep saying that it is too late to fix anything or that it is too
much work, but why do you think so?  I've looked at patching packages
and how many packages need changes and it does not seem much work;
indeed after a week about half of the packages already have a (usually
trivial) patch.

If you think it is too much work or too many things break, please at
least give an estimate of what you are talking about...  I feel like
only one side is doing any research here.

> By now, all we can do is damage control.  Which can be a hasty force-merge
> or a hasty revert.  Unless you can somehow make dpkg-dev omniscient.

If we keep merged-/usr as default then we can /recommend/ people to
install usrmerge to switch to merged-/usr; reducing the difference
between newly-installed and existing setups is a good idea IMHO.  I
think I filed a report for this two years ago.

Maybe we should also mention somewhere that it might be useful to not
switch build environments (yet).

Ansgar

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported.  In this case someone would have
>> to write a unusrmerge program to convert systems with merged-/usr to
>> systems with unmerged-/usr.
>
> Currently merged-usr is broken because it can build packages which do
> not work on non-merged-usr systems.

In very rare cases (an estimated 0.3% of the archive or so).  I'm fairly
confident that for more than 0.3% of the archive something can go wrong
when building in non-clean environments.

> It would be quite wrong (both technically and socially) to react to
> this lack of foresight,

The reported problems are not really unexpected...

> lack of consultation,

It was discussed on -devel@ several times.  I think LWN also reported
about merged-/usr developments in Debian more than once, it wasn't a
secret cabal development.

So where is the lack of consultation?

> and lack of testing, by pressing forward.

It has been tested for quite a while.

A helpful new test was recently added by the Reproducible Builds project
which allowed to identify most problematic packages.

What is technically and socially wrong is reverting a change after a
small issue was found which is already in the process of getting fixed
for most packages.

> When we have stopped generating more lossage, we can start to think
> about whether we want to transition to usrmerge as default, whether to
> make it mandatory, and if so how the transition should be handled, and
> on what timescale.

We had the discussion (usrmerge as default) already quite some time
ago.  Why start again at zero?  As a random reference, the D-I Stretch
RC 1 release announcement explicitly stated:

+---
|  * The switch to merged-/usr as the default setting for debootstrap
|was reverted since it uncovered a number of important issues which
|might not be all fixed in time for stretch. This setting is
|expected to come back as the default at the beginning of the next
|release cycle.
+---

And just that happened (except a bit later).

You could have easily asked the tech-ctte back then (or even before)
instead of waiting until shortly before the Buster freeze and after
people invested more work.

Making it mandatory or not is an unrelated decision.  That can easily
just come later.

> We need the space to discuss those options properly without being
> distracted by what is IMO currently a crisis in stretch-backports and
> buster.

There is no such crisis.  There was also enough time to discuss this in
the last years or even since June (when it was enabled by default
again)...

Ansgar

Bug#915511: ucspi-tcp: package broken

[Ansgar Burchardt]

Source: ucspi-tcp
Version: 1:0.88-4
Severity: grave

>From /usr/bin/date@:

+---
| /build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/tcpclient 
-RHl0 -- "${1-0}" 13 sh -c 'exec 
/build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/delcr <&6' | 
cat -v
+---

Similar for other scripts.

[ This bug report was sponsored by usrmerge. ]

Ansgar

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

"Alexander E. Patrakov" writes:
> Ansgar Burchardt wrote:
>> Making the feature default was discussed years ago which you are surely
>> aware of. It's not mandatory.
>
> Unfortunately I have to disagree here. Merged /usr is already,
> de-facto, mandatory for everyone who installs Debian Testing using the
> official netinst CD.

Yes, but the "make merged-/usr mandatory" refers only to require to
merge /usr on upgrades; nobody has asked for there to be an installer
option (and I don't think it would be useful).

Ansgar

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Adam Borowski writes:
> On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> I believe the difference between those is less than between suboptions of 1
> and 3, but then, as an opponent of 2 as a whole I'm biased.
>
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported.
>
> They'd be exactly as supported as they are today.  Ie -- they'll continue to
> work,

Yes.

> and continue to be useless for building packages without a clean
> chroot.

Oh?  What makes you think so?

You are free to correct my earlier estimate about the number of
problems.  So long I'll assume I'm not totally wrong.  If I'm wrong by a
factor of 3, then 99% of the packages will just build fine.

And fixing any problem is in most cases straightforward.

>> In this case someone would have to write a unusrmerge program to convert
>> systems with merged-/usr to systems with unmerged-/usr.
>> Such a program doesn't exist yet and is probably more complicated than
>> usrmerge: for example how would it know that a /sbin/iptables ->
>> /usr/sbin/iptables symlink would have to be created when unmerging the
>> system?  Moving files from /usr to / is also more likely to run out of
>> disk space (if separate partitions are used for /usr and /).
>>
>> I'm not sure how long it would take to get this right and so agree that
>> (2) or (3b) or (3a-with-support-in-buster) are reasonable choices.
>
> unusrmerge would still be still far less work than continuing with 2.

Why do you think so?  Trivial patches for the remaining few packages
seem easier.

> Yet I don't understand your claim why 1 or 3a w/o usrmerge-in-buster
> would cause any problems.  In fact, they require no work at all (in
> Buster's cycle) beyond an upload of debootstrap.

Unless someone builds a package in an already existing install...  If
not being able to build packages in existing installations is not a
problem, I'm even less sure what the problem with merged-/usr by default
is supposed to be?

Ansgar

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>> 
>> 1. no usrmerge
>>   1a. no moves at all (no effort needed!)
>>   1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and unmerged-usr
>> 3. mandatory usrmerge
>>   3a. by Bullseye
>>   3b. by Buster
>> 
>> Unless the TC decides for 2., all this work will be a pure waste of yours
>> and maintainers' time.
>
> ...One thing I fear here, that's also not being clearly debated AFAICT
> (although the "urgency" of this report points in the right direction)
> is that if the TC decides towards anything but 2 or 3b, we will have a
> hard time reaching and following through the freeze targets proposed
> by the Release Team. Which is something we don't want.

I don't think this list is good as (2) doesn't say anything about the
question asked originally (the default) and (3a) doesn't say anything
about what happens for Buster.

Currently implemented is (2) + default to merged-/usr for new
installations.

Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
systems would no longer be supported.  In this case someone would have
to write a unusrmerge program to convert systems with merged-/usr to
systems with unmerged-/usr.

Such a program doesn't exist yet and is probably more complicated than
usrmerge: for example how would it know that a /sbin/iptables ->
/usr/sbin/iptables symlink would have to be created when unmerging the
system?  Moving files from /usr to / is also more likely to run out of
disk space (if separate partitions are used for /usr and /).

I'm not sure how long it would take to get this right and so agree that
(2) or (3b) or (3a-with-support-in-buster) are reasonable choices.

>> With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in
>> 3a "for now").  With 3b you need some way to make sure existing systems are
>> converted (also with 3a except for far more time for testing).
>
> I agree with your assessment. There are still too many mails I haven't
> read, though, and I cannot commit my hypothetical vote so far, but I
> think the sanest way will be to revert the change in debootstrap.

So (2) with the default to non-merged-/usr or (3a)?

I'm not sure why (2) should not default to merged-/usr though.

Ansgar

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
> > do
> > this at all" years later.
> 
> We were told it would be optional.  Unfortunately it turns out that
> the design is broken and it cannot sensibly be made optional.

There is no indication of that.  So I'll assume the design isn't
broken.

You aren't entitled to just claim that.

> Nor does a failure to review and object to your design of an optional
> feature mean that you are entitled to assume consent for making the
> feature default or mandatory.

Making the feature default was discussed years ago which you are surely
aware of. It's not mandatory.

> The problem comes when a niche optional feature, with wide-ranging
> implications, is suddenly promoted to the default, without proper
> consultation and without a proper transition plan.

It wasn't made "suddenly" the default.

Ansgar

Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.

There is no "urgent action" required (unlike, say, for the last glibc
update).

If you don't want support for merged-/usr, could you please discuss this
back in 2016 or before that?  Also I feel a general discussion would
probably just be too long-winded and touch too many unrelated issues;
there is not even a terse list of claimed problems.

It is very demotivating to have discussed and implemented something
mostly years ago, for people then to come and complain "let's not do
this at all" years later.

Maybe we should also revisit Multi-Arch now that we know that
`Multi-Arch: foreign` relations as implemented can result in non-booting
systems...

Or really revisit the init system question before people file bugs that
require further urgent action for little gain (it's probably too late in
the release cycle to push in elogind anyway).  There is also the
question if it is still worth to spend maintainer efforts to ship
sysvinit scripts if this means we lose the advantages of declarative
service files (which means far more work than merged-/usr changes)...

We could also open a tech-ctte bug for secure boot before I spend any
more time on it (there are still a few things).  Luckily having this
discussion delays me spending time on the remaining things I wanted to
look at, so at least not more time is wasted.  (Not that I currently
have too much time for Debian anyway, and secure boot is quite a lot of
work for something I don't need...)

Ansgar

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Marc Haber writes:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time. My question was about the distant future, and not the current
> snapshot of things.

If anything then /usr would be the prefix for all packages; nothing
would be installed to /bin, /sbin or /lib.  (And there is no /share or
/local.)

But this is obviously only possible if non-merged-/usr is not supported
at all as that would mean shipping only /usr/bin/sh and no /bin/sh; the
/bin -> /usr/bin symlink would then be required.

Ansgar

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Marc Haber writes:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
>> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
>> > Will binaries move from /usr/bin to /bin? Or will binaries move from
>> > /bin to /usr/bin?
>> 
>> A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
>> /bin/grep will make that binary end up in /usr/bin/grep; but the
>> /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
>> directly or /bin/grep through the symlink.
>
> And where will the binaries and up on an un-usrmerged system with a
> dedicated /usr? in /usr, I hope?

They won't move on a system that doesn't have merged-/usr.  /bin/bash
will stay in /bin/bash.  If you switch to a merged-/usr (for example by
installing usrmerge) then they will be moved to /usr.

Ansgar

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>>   directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what will happen when a package
> built on a usrmerged System will be installed on a non-usrmerged system?
>
> Will binaries move from /usr/bin to /bin? Or will binaries move from
> /bin to /usr/bin?

They will be installed in the place the package installs them.  Note
that there are no /bin -> /usr/bin symlink in the staging area where the
package is built (i.e. debian/${package} or debian/tmp).

Packages have to continue shipping binaries in /bin unless we decide to
make merged-/usr mandatory and convert existing systems.

Ansgar

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was enabled by default for a short time
> in stretch).  It took >5 months for someone to find a problem this time
> which is pretty good for any change.

So, I went through all reproducible build failures in unstable without
notes and added notes for differences caused by building in merged-/usr
vs non-merged-/usr packages.  Together with what other people tagged,
about 60 problems were found.  (The oldest rebuild result for unstable
is 17 days old, the merged-/usr variation was deployed before that[1].)

  [1] https://bugs.debian.org/901473#43

There might be some more that as diffoscope had problems or the diff was
too large for some packages (but I'll assume that in this case
merged-/usr is not the only problem the package had).

This should cover all packages that had no other problems and were
reproducible before, that is about 80% of the archive.

Assuming the rate is similar for packages which have other reproducible
build problems, I would expect 60 / 80*20 = 15 more problems.

I haven't looked at build failures, but I would expect these to be
usually not caused by merged-/usr.

So an estimated ~80 packages which might need adjustments for building
correctly in both merged-/usr and non-merged-/usr.  I guess less than
for the average new release of GCC ;-)

The problems are usually easy to fix by passing an explicit path the the
package's configure script at build time; of course there might be some
package where it is more complicated.

Ansgar

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
> 
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
> default now, or are you OK letting the TC decide on this subject?

There were discussions about enabling this by default years ago, I
don't think minor issues should be a reason to delay this change.

Note that it has been delayed for after the stretch release as there
were major issues back then (it was enabled by default for a short time
in stretch).  It took >5 months for someone to find a problem this time
which is pretty good for any change.

Ansgar

Bug#914897: affects private debs too

[Ansgar Burchardt]

Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not convinced this is a good idea: it seems like it causes as many
> problems as it solves. It's effectively a gradual implementation of
> making merged /usr mandatory, with a lot of moving parts (places where
> it could go wrong) and a lot of packages and maintainers needing to be
> involved, but without the simpler end result of *actually* merging /usr.

Well, people don't like the simpler solution that someone else
proposed...

> We've been migrating from non-multiarch to multiarch for more than 5
> years and have still not got there, so I'm not confident that ad-hoc
> migration from unmerged to merged /usr would go any quicker.

Migrating /{s,}bin involves far fewer packages (only ~200 binary
packages).  There is still /lib though.

> It can also cause the same failure modes with hard-coded executable paths
> as merged /usr. Let's suppose we migrated grep from /bin to /usr/bin in
> the way you suggest during the Debian 11 release cycle. If a package that
> hard-codes the compile-time grep path (again, consider gzip, #914907)
> is built with the new grep, it won't work correctly with the old grep
> during a partial upgrade from Debian 10 to 11; but I don't see how it
> would pick up a versioned Depends on the new grep without manual action
> from the dependent package's maintainer, which isn't going to scale well.

You will always have this problem with partial upgrades unless *every*
package depends on a package that would ensure that the system has all
binaries previously in /bin also in /usr/bin.

In particular, if we want to treat this as a (release critical) bug,
iptables or any other package ever moving from /bin to /usr/bin (or the
other way) will always be buggy, regardless of any merged-/usr.  Same
for any binary ever moving between .../bin and .../sbin.

Ansgar

Bug#914897: affects private debs too

[Ansgar Burchardt]

Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping any packages that
>> > > aren't built on buildds.
>> > 
>> > It would be quite a radical departure for Debian to no longer support
>> > "I built this package for my mate to install on their computer".
>>
>> For the case of locally built binaries, bringing any problem
>> that usrmerge would hit to the light would be preferable.
>
> Any checks you can do may test only packages that reached the Debian
> archive.  We can discipline DDs, be it by requiring source-only, or by
> catching misbuilt packages, but we can't do anything for local packages.
>
> And these in a good part are not based on Debian sources.
>
> I for one use a .deb package to distribute my .bashrc to machines under my
> control.  Joe from a derivative named Debuntituan provides an
> uber-proprietary-drivers package to his users.  Any PPA.  A company-wide
> repo.  Etc, etc.

Debian is not responsible how third parties build their packages.  We
don't even exclude /usr/local/bin from PATH when building packages...

(If you care about distributions not doing the same as Debian, one would
need to patch every package to build & work on both merged-/usr and
non-merged-/usr systems no matter what Debian does...)

> Thus: sorry but there is no way we can possibly support usrmerged and
> non-usrmerged systems at the same time.  Usrmerge is not viable without a
> flag day.

Oh, it's possible.  It makes life a bit harder than a flag day or clear
commitment to one setup, but so does supporting multiple init systems
(so the advantages of, for example, easier maintenance by having
declarative definitions is lost).

Regardless of debootstrap defaults or flag days, we could also consider
moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
/{s,}bin; this does not need a flag day.  That is useful either way as:
a) some people will use /usr/bin/${x} instead of /bin/${x} anyway (they
don't have to come from Debian), and b) it would also make supporting
merged-/usr and non-merged-/usr simpler as the programs would always be
available in both locations.

Some packages such as iptables have already done this ad-hoc.

I'm toying around with ideas for a dh_usrmove tool which would allow to
easily add this to existing packages.  That would also allow to drop it
later in one go should one in the far future require the /bin ->
/usr/bin symlink.

Ansgar

Bug#905674: #905674: please describe ftpmasters' official position

[Ansgar Burchardt]

On Sat, 2018-09-15 at 14:04 +0200, Adam Borowski wrote:
> It would be nice if we had an official ftpmasters' position.  So far, all
> we have are remarks on IRC.
> 
> The case here is the package "parallel" having recentlish grown a demand for
> either a citation or 1€.  This is explicitely forbidden by the GPL FAQ:
> https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation
> and interpreting the request as a demand rather than mere suggestion is
> reinforced by the alternative being a (high) monetary fee rather than
> nothing.
> 
> The issue has been raised by multiple people on multiple bug trackers.

Vague references ("multiple bug trackers") aren't really helpful.  I'm
not going to search for "multiple bug trackers" somewhere on the
internet.

> Unless my analysis is wrong, I see the following options: either
> 
> * the demand is considered a part of the license, in which case the package
>   needs to be moved to non-free or removed from the archive completely
>   (depending whether the demand is considered overriding a part of the GPL3
>   or being a conflicting addition)

It isn't in d/copyright and one of the copyright holders seems to have
said that this isn't a legal requirement (in 
https://bugs.debian.org/905674#27).  The other copyright holder is the
FSF which also don't think this should be a requirement as you cited
above.

> * the demand is a part of the code only.  It then can be removed (as it
>   causes practical problems like #884793), against express wishes of the
>   upstream -- although in this case, per the legal demands made by upstream
>   in newer versions, we'd need to rename the package[1][2].

Which legal demands?

Ansgar
  (Shouldn't GNU parallel at least cite Perl itself? :-) )

Bug#907483: grub-efi-*-signed-template: `Built-Using` must refer to source packages

[Ansgar Burchardt]

Package: grub-efi-amd64-signed-template
Version: 2.02+dfsg1-5
Severity: serious

The `Built-Using` field of the source template refers to binary
packages instead of source packages.  This makes dak reject the upload
of the signed packages:

+---
| grub-efi-amd64-signed_1+2.02+dfsg1+5_amd64.deb: Built-Using refers to 
non-existing source package grub-efi-amd64-bin (= 2.02+dfsg1-5)
+---[ grub-efi-amd64-signed_1+2.02+dfsg1+5_amd64.changes.reason ]

(same for ia32/i386 and arm64)

Ansgar

Bug#906351: dune-istl: FTBFS in buster/sid (error: static assertion failed)

[Ansgar Burchardt]

Control: tag -1 fixed-upstream confirmed
Control: forwarded -1 
https://gitlab.dune-project.org/core/dune-istl/merge_requests/216

Santiago Vila writes:
> /usr/include/c++/8/bits/stl_tree.h:457:21: error: static assertion failed: 
> comparison object must be invocable as const
>static_assert(is_invocable_v _Key&>,
>  ^

GCC 8 is stricter than earlier versions here.  It should already be
fixed upstream
(https://gitlab.dune-project.org/core/dune-istl/merge_requests/216).

I'll look at backporting the changes to the Debian package in the next
days.

Ansgar

Bug#905482: fwupd-amd64-signed-template: invalid Depends (syntax error)

[Ansgar Burchardt]

Package: fwupd-amd64-signed-template
Version: 1.1.0-6
Severity: serious

There is still one syntax error in the `Depends` field of the source
package template (the `}`):

Depends: ..., fwupd (= 1.1.0-6})
 ^^^

This resulted in a build failure for fwupd-amd64-signed[1].

Ansgar

  [1] 
https://buildd.debian.org/status/fetch.php?pkg=fwupd-amd64-signed&arch=amd64&ver=1.1.0%2B6&stamp=1533456833&raw=0

Bug#905471: fwupd-amd64-signed-template: conflicting source package name

[Ansgar Burchardt]

Package: fwupd-amd64-signed-template
Version: 1.1.0-5
Severity: serious

>From the code signing service:

+---
| dpkg-source: error: source package has two conflicting values - 
fwupd-amd64-signed and fwupd-signed-amd64
+---

d/changelog and d/control use different source package names.

This should be reproducible by just invoking `dpkg-source -b` in the
template directory (or a copy of it).

Ansgar

Bug#905468: fwupd-amd64-signed-template: invalid Build-Depends (syntax error)

[Ansgar Burchardt]

Package: fwupd-amd64-signed-template
Version: 1.1.0-4
Severity: serious

The source template for code signing contains invalid Build-Depends:

Build-Depends: ... fwupd (= ) [amd64]

The version is missing.  The same problem occurs in `Depends` too:

Depends: ... fwupd (= })

Ansgar

Bug#903581: valgrind can't read debug info from binaries built with -z separate-code

[Ansgar Burchardt]

Hi,

I can confirm that the patch referenced at [1] seems to fix the problem
(upstream commit 64aa729bfae71561505a40c12755bd6b55bb3061).

I'll try to prepare a NMU for valgrind; maybe already this evening if I
have time. The package isn't usable in the current state.

Ansgar

  [1] https://bugs.debian.org/903581#15

Bug#902385: blacs-pvm-test: depends on removed package blacs-test-common

[Ansgar Burchardt]

Control: clone 902385 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: blacs-pvm -- RoQA; blacs-test-common depends on removed 
package; PVM no longer used for parallel computing
Control: severity -2 normal

Muammar El Khatib writes:
> On Mon, Jun 25, 2018 at 3:00 PM Ansgar Burchardt  wrote:
[...]
>> blacs-pvm-test depends on blacs-test-common which was just removed
>> (#886711).
>>
>> I wonder if blacs-pvm is still useful? pvm was orphaned (#824403) and I
>> don't know anyone still using PVM for parallel computations.
>
> Given that blacs-test-common was removed and honestly PVM does not
> seem to be used for parallel computing, it makes lots of sense to me
> that blacs-pvm should be removed, too.  By the way, I have just seen
> it's been marked as AUTORM and will be removed anyway. Then, no
> actions to take it back into Debian archive might be the right thing
> to do.

The automatic removal is only from testing.  There still needs to be a
manual removal request to remove the package also from unstable; the
beginning of this mail should take care of creating one.

Ansgar

Bug#902409: grep-excuses: uses YAML::Syck in a unsafe way

[Ansgar Burchardt]

Package: devscripts
Version: 2.18.3
Severity: grave
File: /usr/bin/grep-excuses
Tags: patch security

grep-excuses uses YAML::Syck without telling YAML::Syck to not bless
objects which might lead to running code the author of grep-excuses
might not have intended to run.

The attached patch tells grep-excuses to tell YAML::Syck to not point
a loaded gun towards your foot (even though this might be against the
UNIX philosophy of shooting on feet).

See also #862475.

Ansgar
--- scripts/grep-excuses.pl 2018-03-06 15:42:39.0 +0100
+++ /usr/bin/grep-excuses   2018-06-26 09:57:34.499148292 +0200
@@ -32,6 +32,8 @@
 
 eval {
require YAML::Syck;
+   no warnings 'once';
+   $YAML::Syck::LoadBlessed = 0;
 };
 
 if ($@) {

Bug#902385: blacs-pvm-test: depends on removed package blacs-test-common

[Ansgar Burchardt]

Package: blacs-pvm-test
Version: 1.1-21+b1
Severity: serious

blacs-pvm-test depends on blacs-test-common which was just removed
(#886711).

I wonder if blacs-pvm is still useful? pvm was orphaned (#824403) and I
don't know anyone still using PVM for parallel computations.

Ansgar

Bug#902041: openmpi: broken on armel

[Ansgar Burchardt]

FWIW, the same program also hangs on powerpc (partch.d.o).

Ansgar

Bug#902041: openmpi: broken on armel

[Ansgar Burchardt]

Source: openmpi
Version: 3.1.0-7
Severity: serious

OpenMPI seems to be very broken on armel.  The C++ program below hangs
often at a random iteration on abel.d.o (in a sid_armel-dchroot).

I built the program using `mpic++ -Wall -std=c++14 -o test test.cc` and
ran it with two ranks `mpirun -np 2 ./test`.

Ansgar



#include 

#include 

int main(int argc, char** argv)
{
MPI_Init(&argc, &argv);

int rank, size;
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);

for (int j = 0; j < 1024; ++j) {

std::cout << "j = " << j << std::endl;

MPI_Request req[2];

const char out[4] = {1, 2, 3, 4};
char in[4];

int dest = (rank + 1) % size;
int source = (size + rank - 1) % size;

MPI_Isend(out, 4, MPI_BYTE, dest, 0, MPI_COMM_WORLD, &req[0]);
MPI_Irecv(in, 4, MPI_BYTE, source, 0, MPI_COMM_WORLD, &req[1]);

MPI_Waitall(2, req, MPI_STATUSES_IGNORE);
}

MPI_Finalize();
return 0;
}

Bug#881009: src:clips: typo in maintainer address (.og instead of .org)

[Ansgar Burchardt]

Source: clips
Source-Version: 6.30-3
Tags: sid
Severity: serious

> Source: clips
> Binary: clips libclips libclips-dev clips-common clips-doc
[...]
> Version: 6.30-4
[...]
> Maintainer: Javier Fernández-Sanguino Peña 
> Changed-By: Javier Fernández-Sanguino Peña 

The maintainer has a typo (missing the "r" in ".org") and causes
bounces.

Ansgar

Bug#874337: src:gr-iio: maintainer address bounces

[Ansgar Burchardt]

Source: gr-iio
Version: 0.2.36-1
Severity: serious

[ X-Debbugs-Cc'ed last uploader. ]

The maintainer address for gr-iio bounces (same for libad9361 and
libiio), see below.

Ansgar

> Delivery has failed to these recipients or groups:
>
> Paul Cercueil (paul.cercu...@analog.com)
> The e-mail address you entered couldn't be found. Please check the 
> recipient's e-mail address and try to resend the message. If the problem 
> continues, please contact your helpdesk.
>
>
>
>
>
>
>
> Diagnostic information for administrators:
>
> Generating server: analog.com
>
> paul.cercu...@analog.com
> #550 5.1.1 RESOLVER.ADR.RecipNotFound; not found 
> ##rfc822;paul.cercu...@analog.com
>
> Original message headers:
>
> Received: from nwd2feex2.utm.analog.com (137.71.25.64) by
>  NWD2HUBCAS9.ad.analog.com (10.64.69.109) with Microsoft SMTP Server (TLS) id
>  14.3.210.2; Tue, 5 Sep 2017 00:35:13 -0400
> Received: from localhost.localdomain (localhost [127.0.0.1])by
>  nwd2feex2.utm.analog.com (Postfix) with SMTP id 3xmYmK47Pcz3jp7c   for
>  ; Tue,  5 Sep 2017 00:35:13 -0400 (EDT)
> Received: from nwd2mta4.analog.com (nwd2mta2.analog.com [137.71.25.57]) by
>  nwd2feex2.utm.analog.com (Postfix) with ESMTPS id 3xmYmK237Rz3jp7Y for
>  ; Tue,  5 Sep 2017 00:35:13 -0400 (EDT)
> Received: from NAM01-SN1-obe.outbound.protection.outlook.com
>  (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) by
>  nwd2mta4.analog.com (8.13.8/8.13.8) with ESMTP id v854ZCi0011334
> (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)  for
>  ; Mon, 4 Sep 2017 21:35:12 -0700
> Received: from BN3PR03CA0055.namprd03.prod.outlook.com (10.167.1.143) by
>  CO2PR03MB2360.namprd03.prod.outlook.com (10.166.93.20) with Microsoft SMTP
>  Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
>  15.20.13.10; Tue, 5 Sep 2017 04:35:11 +
> Received: from BN1AFFO11FD010.protection.gbl (2a01:111:f400:7c10::182) by
>  BN3PR03CA0055.outlook.office365.com (2a01:111:e400:7a4d::15) with Microsoft
>  SMTP Server (version=TLS1_2,
>  cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10 via
>  Frontend Transport; Tue, 5 Sep 2017 04:35:10 +
> Authentication-Results: spf=none (sender IP is 209.87.16.33)
>  smtp.mailfrom=ftp-master.debian.org; analog.com; dkim=none (message not
>  signed) header.d=none;analog.com; dmarc=none action=none
>  header.from=ftp-master.debian.org;
> Received-SPF: None (protection.outlook.com: ftp-master.debian.org does not
>  designate permitted sender hosts)
> Received: from muffat.debian.org (209.87.16.33) by
>  BN1AFFO11FD010.mail.protection.outlook.com (10.58.52.70) with Microsoft SMTP
>  Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
>  15.1.1385.11 via Frontend Transport; Tue, 5 Sep 2017 04:35:10 +
> Received: from [138.16.160.17] (helo=fasolo.debian.org) from C=NA,ST=NA,L=Ankh
>  Morpork,O=Debian SMTP,OU=Debian SMTP
>  CA,CN=fasolo.debian.org,EMAIL=hostmas...@fasolo.debian.org (verified)  by
>  muffat.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)  
>   (Exim
>  4.89)  (envelope-from )id 
> 1dp5Zs-0007CU-2h;
>  Tue, 05 Sep 2017 04:35:08 +
> Received: from dak by fasolo.debian.org with local (Exim 4.84_2)
> (envelope-from )id 
> 1dp5Zr-000GDk-3Y; Tue, 05
>  Sep 2017 04:35:07 +
> X-FireEye: Clean
> From: Debian FTP Masters 
> To: "A. Maitland Bottoms" , Paul Cercueil
> 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: gr-iio
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: gr-iio_0.2.36-1_amd64.changes ACCEPTED into unstable
> Message-ID: 
> Date: Tue, 5 Sep 2017 04:35:07 +
> X-EOPAttributedMessage: 0
> X-EOPTenantAttributedMessage: eaa689b4-8f87-40e0-9c6f-7228de4d754a:0
> X-MS-Office365-Filtering-HT: Tenant
> X-Forefront-Antispam-Report: 
> CIP:209.87.16.33;IPV:NLI;CTRY:CA;EFV:NLI;SFV:NSPM;SFS:(6009001)(8196002)(299032)(428002)(50944005)(199003)(288314003)(54524002)(189002)(7596002)(305945005)(345774005)(23676002)(50466002)(7636002)(42882006)(311042)(90996001)(47776003)(287071)(46656002)(356003)(83832001)(246002)(9686003)(106466001)(575784001)(57986006)(626005)(566031)(83796002)(63266004)(101416001)(189998001)(9746002)(34003)(93136999)(105586002)(9786002)(50986999)(8666007)(1096003)(8676002)(54356999)(2440051);DIR:INB;SFP:;SCL:1;SRVR:CO2PR03MB2360;H:muffat.debian.org;FPR:;SPF:None;PTR:muffat.debian.org;A:1;MX:1;LANG:en;
> X-MS-PublicTrafficType: Email
> X-MS-Office365-Filtering-Correlation-Id: 1c3d5ef7-753f-475d-5b01-08d4f4177e3c
> X-Microsoft-Antispam: 
> UriScan:;BCL:0;PCL:0;RULEID:(30500095)(30013595)(30501095)(300135300095)(22001)(23075)(30502095)(300135100095)(30503095)(300135400095)(71702078)(30504095)(300135200095)(30505095)(300135600095)(300

Bug#870203: dune-grid FTBFS on mips: test-ug (Timeout)

[Ansgar Burchardt]

Control: severity -1 important

Adrian Bunk writes:
>   Start 31: test-ug
> 31/60 Test #31: test-ug 
> ...***Timeout 300.02 sec

Yes, saw the same issue also on PowerPC.  I haven't found time to look
at this yet and have asked for dune-grid and rdeps to be removed from
mips and powerpc for now (#869688).  I'm downgrading the bug as the
removal will make this non-RC.

Ansgar

Bug#870076: src:chrony: maintainer address bounces

[Ansgar Burchardt]

Source: chrony
Severity: serious
Tags: sid

The maintainer address for chrony bounces, see below.

Ansgar

Mail Delivery System  writes:

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   vincent.deb...@free.fr
> all hosts for 'free.fr' have been failing for a long time and were last 
> tried after this message arrived
>
> Reporting-MTA: dns; mailly.debian.org
>
> Action: failed
> Final-Recipient: rfc822;vincent.deb...@free.fr
> Status: 5.0.0
>
> From: Debian FTP Masters 
> Subject: chrony_3.2~pre1-1_source.changes ACCEPTED into experimental
> To: Vincent Blut ,  
> Date: Wed, 26 Jul 2017 09:49:13 + (3 days, 3 hours, 58 minutes ago)
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Tue, 25 Jul 2017 21:13:22 +0200
> Source: chrony
> Binary: chrony
> Architecture: source
> Version: 3.2~pre1-1
> Distribution: experimental
> Urgency: medium
> Maintainer: Vincent Blut 
> Changed-By: Vincent Blut 
> Description:
>  chrony - Versatile implementation of the Network Time Protocol
> Changes:
>  chrony (3.2~pre1-1) experimental; urgency=medium
>  .
>* Import upstream version 3.2-pre1:
>  - Please see /usr/share/doc/chrony/changelog.gz for the release notes.
>  .
>* debian/patches/*:
>  - Remove allow_getpid_in_seccomp_filter.patch and update the series file
>  accordingly.
>  .
>* debian/tests/upstream-simulation-test-suite:
>  - Run tests in multiple iterations.
> Checksums-Sha1:
>  c143c9dd7137693a6f7926408f37a7b2231c5a49 1921 chrony_3.2~pre1-1.dsc
>  7c58a02ae12bcb79c02317f21ba2b109c510d04b 431211 chrony_3.2~pre1.orig.tar.gz
>  8caa238c519bc1ce4cf95da2fff8e49b838671c1 26840 
> chrony_3.2~pre1-1.debian.tar.xz
> Checksums-Sha256:
>  57459cec5ba526d3109c55ed75db474bb285b9a4bd34b25961fa3f191c5d0ba0 1921 
> chrony_3.2~pre1-1.dsc
>  3c6fa2fe71ba670955498dcecab6a57c0b4ed8bc5a761629e96cd6038946942f 431211 
> chrony_3.2~pre1.orig.tar.gz
>  91e3ba7b227341f1d546d402f8a9723878770c99be5a11dda531def9d04cbce1 26840 
> chrony_3.2~pre1-1.debian.tar.xz
> Files:
>  f86c00f85f65a62944962753bdb3e3f3 1921 net optional chrony_3.2~pre1-1.dsc
>  58f8b1b439f5d1a8084a2668b8284b25 431211 net optional 
> chrony_3.2~pre1.orig.tar.gz
>  d30b8043850bcd2cabbbf03cacd30bb0 26840 net optional 
> chrony_3.2~pre1-1.debian.tar.xz
>
>
>
> Thank you for your contribution to Debian.
> --

Bug#870075: src:pdf-presenter-console: maintainer address bounces

[Ansgar Burchardt]

Source: pdf-presenter-console
Tags: sid
Severity: serious

The maintainer address for pdf-presenter-console bounces, see below.

Ansgar

Mail Delivery System  writes:

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   ba...@pearlmutter.net
> SMTP error from remote mail server after end of data:
> host eforward1.registrar-servers.com [162.255.118.61]:
> 550 The sending IP (209.87.16.33) is listed on https://spamrl.com as a 
> source of viruses.
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
> Received: from [138.16.160.17] (helo=fasolo.debian.org)
>   from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
> CA,CN=fasolo.debian.org,EMAIL=hostmas...@fasolo.debian.org (verified)
>   by muffat.debian.org with esmtps 
> (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
>   (Exim 4.84_2)
>   (envelope-from )
>   id 1da8ve-0007gk-Aw; Tue, 25 Jul 2017 23:07:50 +
> Received: from dak by fasolo.debian.org with local (Exim 4.84_2)
>   (envelope-from )
>   id 1da8vd-0007ze-69; Tue, 25 Jul 2017 23:07:49 +
> From: Debian FTP Masters 
> To: b...@debian.org (Barak A. Pearlmutter)
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: pdf-presenter-console
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: pdf-presenter-console_4.0.7-2_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Tue, 25 Jul 2017 23:07:49 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Tue, 25 Jul 2017 11:52:59 +0100
> Source: pdf-presenter-console
> Binary: pdf-presenter-console
> Architecture: source amd64
> Version: 4.0.7-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Barak A. Pearlmutter 
> Changed-By: Barak A. Pearlmutter 
> Description:
>  pdf-presenter-console - multi-monitor presentation tool (ala Keynote) for 
> PDF files
> Changes:
>  pdf-presenter-console (4.0.7-2) unstable; urgency=medium
>  .
>* Merge upstream fixes, should address various video bugs
> Checksums-Sha1:
>  07614ac6e31622d9898e813ce83b3b4ddc7ae4dc 2121 
> pdf-presenter-console_4.0.7-2.dsc
>  94f9ae370a0b72a0025f0a744bad77f8683a2db2 22752 
> pdf-presenter-console_4.0.7-2.debian.tar.xz
>  3b8a9698fd6cdfa26663c3133d73680a5c312ff4 511658 
> pdf-presenter-console-dbgsym_4.0.7-2_amd64.deb
>  eda545d2c0a411d5ab345cc2ceea22b475c4c2a2 13625 
> pdf-presenter-console_4.0.7-2_amd64.buildinfo
>  6b5a6ab31ce9b45b05132a59fddfda905f560544 122206 
> pdf-presenter-console_4.0.7-2_amd64.deb
> Checksums-Sha256:
>  aa86b068ae4d6dfc09eac11144cc8bd9f77a3f032af1b8d75244949216be342a 2121 
> pdf-presenter-console_4.0.7-2.dsc
>  00efc12400b5008d3920a2193de9d9493b5ed85c511a5e403893dae8bf35e028 22752 
> pdf-presenter-console_4.0.7-2.debian.tar.xz
>  f205ad19715c4ff8411c02da0efe5cd958e49c33464a42daa23ffea6b3bfd6aa 511658 
> pdf-presenter-console-dbgsym_4.0.7-2_amd64.deb
>  9222700cac8c1419d9938b4fb5b9c607de096349e076878f25628d68efcd7acf 13625 
> pdf-presenter-console_4.0.7-2_amd64.buildinfo
>  f849f0da91a69ea812e49f1348214b9eb25b2dd93b6c966cfc2c1e5856eb3407 122206 
> pdf-presenter-console_4.0.7-2_amd64.deb
> Files:
>  887ed1868a6d1ecaff73a4e375e1d8fc 2121 graphics extra 
> pdf-presenter-console_4.0.7-2.dsc
>  96d01013e0df59e2d3fdc3f72647987b 22752 graphics extra 
> pdf-presenter-console_4.0.7-2.debian.tar.xz
>  ce72664bdc2cde39fa350c707cfb5146 511658 debug extra 
> pdf-presenter-console-dbgsym_4.0.7-2_amd64.deb
>  54490afddb34e7e04416389e45d3dffc 13625 graphics extra 
> pdf-presenter-console_4.0.7-2_amd64.buildinfo
>  54332e294f9acbb379a0e4b664ef0bda 122206 graphics extra 
> pdf-presenter-console_4.0.7-2_amd64.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#868057: davmail_4.8.0.2479-2_amd64.changes REJECTED, why

[Ansgar Burchardt]

Hi,

On Mon, 2017-07-17 at 13:19 +0200, Geert Stappers wrote:
> Currently I don't know what I do wrong
> while uploading davmail 4.8.0.2479-2

The upload did not include the source package.

> Upload of davmail 4.8.0.2479-1 did happen.
> It did in include the orig.tar.gz
> 
> Upon my first upload of davmail 4.8.0.2479-2 there was a reject
> message
> saying source was missing.
> 
> Upload tool I'm using is dput from dput-ng.
> 
> I invoke `dput $PACKAGE_VERSION.changes`
> 
> The .changes files was generated by `sbuild -A`
> It mentions only   .deb  and .buildinfo
> (It does _not_ mention  .orig.tar.gz  nor .debian.tar.xz )
> 
> Not knowning how to tell sbuild that it should include .debian.tar.xz
> in the .changes, I did include it by manually editting the .changes

Please don't manually edit the .changes file. It is easy to get wrong
which is what happened here.

I think recent versions of sbuild have an option to also build the
source package and have it in the generated .changes.

> Did sign the .changes file.
> 
> dput did warn me about davmail 4.8.0.2479-2 allready being uploaded.
> I did a rename of the dput upload file locally
> ( mv davmail_4.8.0.2479-2_amd64.ftp-master.upload davmail_4.8.0.2479-
> 2_amd64.ftp-master.upload.0 )
> 
> dput was succesfull
> ( $ cat davmail_4.8.0.2479-2_amd64.ftp-master.upload
> Successfully uploaded davmail_4.8.0.2479-2_all.deb to ftp.upload.debi
> an.org for ftp-master.
> Successfully uploaded davmail_4.8.0.2479-2_amd64.buildinfo to ftp.upl
> oad.debian.org for ftp-master.
> Successfully uploaded davmail_4.8.0.2479-2.debian.tar.xz to ftp.uploa
> d.debian.org for ftp-master.
> Successfully uploaded davmail_4.8.0.2479-2_amd64.changes to ftp.uploa
> d.debian.org for ftp-master.
> )
> 
> I was expecting an ACCEPTED auto-response, but did get
> 
>    Invalid dsc file: 'NoneType' object has no attribute 'check'

That particular error message isn't very helpful and a bug in dak, but
the problem is that the source package is not included in the upload. 
Please rebuild the package and make sure the source package is included
in the generated .changes.

Ansgar

Bug#865109: tryton-*: maintainer address bounces

[Ansgar Burchardt]

Package: tryton-modules-production-routing
Severity: serious
Version: 4.4.0-1
X-Debbugs-Cc: Mathias Behrle 

Hi,

please fix the maintainer address, see attachment.

Ansgar
--- Begin Message ---
This is the mail system at host mail.virtual-things.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

 (expanded from
): host mail.alioth.debian.org[5.153.231.21]
said: 550 Administrative prohibition (in reply to RCPT TO command)
Reporting-MTA: dns; mail.virtual-things.org
X-Postfix-Queue-ID: 87C301C00E81
X-Postfix-Sender: rfc822; ftpmaster@ftp-master.debian.org
Arrival-Date: Mon, 19 Jun 2017 11:33:10 + (UTC)

Final-Recipient: rfc822; tryton-debian@lists.alioth.debian.org
Original-Recipient: rfc822;maintainers@debian.tryton.org
Action: failed
Status: 5.0.0
Remote-MTA: dns; mail.alioth.debian.org
Diagnostic-Code: smtp; 550 Administrative prohibition
--- Begin Message ---
tryton-modules-production-routing_4.4.0-1_amd64.changes uploaded successfully 
to localhost
along with the files:
  tryton-modules-production-routing_4.4.0-1.dsc
  tryton-modules-production-routing_4.4.0.orig.tar.gz
  tryton-modules-production-routing_4.4.0-1.debian.tar.xz
  tryton-modules-production-routing_4.4.0-1_all.deb
  tryton-modules-production-routing_4.4.0-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)
--- End Message ---
--- End Message ---

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Ansgar Burchardt]

Source: aiccu
Version: 20070115-17
Severity: serious

SixXS will shutdown on 2017-06-06[1].  Unless there are other tunnel
providers used with aiccu, it seems useless to include in stretch.
>From a quick glance at [2], SixXS is the only provider using AYIYA and
TIC which is what I believe aiccu implements.

Ansgar

  [1] 
  [2] 

Bug#860830: debian-archive-keyring: ftp-master key for stretch

[Ansgar Burchardt]

Please include the new automatic signing keys for 9/stretch.  The keys
are signed by the current ftp masters and the previous archive signing
keys.

They were announced at [1].

Ansgar

  [1] https://lists.debian.org/debian-devel-announce/2017/05/msg1.html

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBFkjME4BEACatcbzE9EaIKMmiS3OmcrooZZUI4pGtJcFqCNBOP3qvxUEq9Tk
4XPY8EARDGdwy2rMc12ywoc5FMzNwXiC3RpUNHnNhY+zau18q9CQx8UR02NDFWQq
AwaDSF4WU1GBVBMWgtxfIwAQGl/qOr+aSVtJCnEOTA/YiZPNw/wpA7r2g6EHYcce
a5srr7F15a6OxzDdPXlfoJuoSXMZUHpJIqG0UOo7NPkxPGRoHO2yGPS1DWKy3egG
xm718DwaIWee+mfJrcqT0ZFH4n5po1BJVj+8TcqE4YlkN/z4p0zI/XAxNCR2wGV2
6cCQ8laEgwG33rPp+N3G/FeJchYTFvL7zDtdYKbBPVeaJh2kROnqbVVN5kZBVEXB
QNbXKuK6/TPiQeI+8anA9WflI19lzkzl29L7hsM9ornk7+wtu9P2hu3eEUgjjBli
Ujisw8s0aTPB5QsMCjSownwZ0ucqj+07nYVsPU2wK8x6A7p6Cg2SCPnjbX8jUb3Z
wyn0yi4SWceW9a+LW6wdGarMGbu+Lm6in8pK93u7mE/D4AskUVz1yLyiNO9WBXPq
GyTocqXKXTutHKhhSwY9CyEw1+SRzXXyHPmRunRULTgZHLOaydK6ekzBOe1Yp9Zk
hLvon6fgOhJTsokv27QCSw8ILbQPGF9qJWFQfYZhT4QCufmPaFgBpJOdewARAQAB
iQJOBB8BCgA4FiEE4c8g3f/kuJ6AJljx4LEYlPZq7JgFAlkjMMkXDIABgOl28UpQ
ikjpyj/pvDciUsoc+WQCBwAACgkQ4LEYlPZq7JiCcw/+NxzyntWMM/b/eIMedzZK
Zyq7Mo6vgFxT57wAloMtLu0WS9oETTH/+/9+fHPmkYxCX1HTNKpdY2KbjiZC/gAY
vJ8iGWredwIls2UyW4fegzRLNvWLZmUBbLg0WaTIQ9JZwa2Rw/q6Z0pe0tfb44oX
lpps0WA/OZCWXYVO2rhOzoiQulqdmHgwdcLA29BnpqBY1R8/LMDsfPLnJu7AFqgM
CQpnjIGRH6ZxF2TNUSdljUbIOultEeIvxtxosF1u0r20mg46aaKDpr0ANiR/Ojaj
YoeHZc39fyubSrhIyQuk4rDisrJod63MJ9x9upAc9H3qz71QjpwpVXPDxereWULO
17qN3hjjZd23CBdRv8HjRKQoFagUnxlrat1t+/yJCENzX6eX8wBs0vVCSmbtbSp7
y+0BK4fyjDKCdiyKh1TiAnQ1Po/xICGr4Sa6Wohq2TeWXz4VlRnaQeCIwa4Kk6T/
3VTQbNxn7Uiy9ec8aR+1YMGUBDG/k3s6K1PWLdJtSVgao8MkQYeKcQk/sgGSFPh8
SkTy7CnSjK/gQP8NC5fFDWpatGpnDr9qsQwzMnUVYWNZQMQ+LJHPnXRyusr3M+Gh
4muVW1wmyjNLhtEYjJJnbv9bVVv2HFVXOWGiXY4hnj01xkHf3885Qq5ORWl1FMnU
lcqUcFsB6a1CCPGxNTJQhgKJAk4EHwEKADgWIQThzyDd/+S4noAmWPHgsRiU9mrs
mAUCWSMwyRcMgAH7+r21QbXclVvZum7bFs9bsSUlxAIHAAAKCRDgsRiU9mrsmK2H
D/9frYP6KRecLNMzLJGe6MB/1DbqIud1/kzd/jHRo3e4Dz8cls29N03HskLE4jTf
BXKAhUmRI52aMCioY/K03rZLaR++/GMIdnF7O4Ks7P203J4/CudmXQvz3Rby22lC
RCp3Wsx2DqFgpc1V5SjmdDxzEs3fwKJ0B8YOMyibyUaLfwaxRfiTsWmRF192WzCM
/B1tmJDLIqwq/xxzxmiqzrxBWq3JIxH1PzrGbWvAE0gfBJHgw/2HHO4PAG9Lj+AV
HHPV/9xhXdbF/KnnKUGtd9lssNleWlc5LeM0ix2pU/QrZx7c+CBW+142jQcZ58X6
QvHTKBkImI7y3kMCUOs+UbxKnFsRBRduMLvIpXJVXukV3QvRn+9riITPIcviF4ni
F6V2NQ+ONrvMOK2s6VdfgMS7c4Azuyt4SJSEzBhHu+VTVnMZCBiKvZtRL5XX85ZF
DDkN62Bwa+F36lTiOBWOecSQykCyOKcnn0jKrSgDOk08qE7Nzl2SPdlpza0/bk2u
6i8o3mrmdO02OqC9vJum6M4Pn2HHrkPzAtSs11E7ogcZghPxnGCekGQNekHx9DKM
mv8W+SZf4b1KD1EKECeNLZ0QHQMjU3AYBav+Mq9IXIlwFZL85BYLUAWfrCnqf/gV
CTiy9yKdQ4WIr9XR+zywDigAZqJ5PxwBh1+phrkoWUfsLokCTgQfAQoAOBYhBOHP
IN3/5LiegCZY8eCxGJT2auyYBQJZIzDJFwyAATCZEb6pZtBhMFMEVxG05f8VsP2C
AgcAAAoJEOCxGJT2auyYWHAP/jlmSZQI/dnrYTT0ZtZA0k3sCaaOApWmno4Jm1+p
QzxBJyVXC/7em3D/Wb3B4XpQKnkWOGz3XtEf4LNPhrW1n6nLFOLctprGwnlZihBp
tmidEvvFKCa5exv4WOVyat5jLttNJ6o4O0BJHmUJG/wAVSjfWi2KgVXZEnz/wts8
KFXc06RCgavIATmlC5QqD87U5ezKJdY0HY/A8uT9aBJ3KFdzj5MnZOzr2RJcEtWU
UE1HHxqJS7POQVMUWK/7nABUKjzpQg8Hn7VNom553Lf8yk+OLl0x7+bS/8tZltZ/
zkIqzUmpPk1QSf5b4JOryJye0ZV60TtbI7juXi2VV41gcHxd7EMkF4PAMtHF/rNM
n/sR4LLXPnQk71zqOScYpMBDQ0FikQ7UuUT35iJAX3u7mWYL0P4h3NBlPmRLg9W3
k/g5KRBLJ2U9Ba+i3UIRva8tUGz/EluzOCUcSbIEMNkaNyt4ktO3PaIzAzdVdxYk
IWV6NUj92vSBJvXinzIjyXTk9Tjfuf4hLo15C+1c9P0+XkpKzpvW1ycpIUVH9QSZ
afC1e45EXSkD0AV+y6ihJf4PWddgGb3ZeWarcp2QL/ll3XoBdEGfxOQJ1Py2nfIS
HxVrl5AxoEJ9q+4YO5xysAV4f+UFKvS4snJtRztOYBKM0/4pup41u4V8oGWLRUOC
d/GitEdEZWJpYW4gQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDkvc3Ry
ZXRjaCkgPGZ0cG1hc3RlckBkZWJpYW4ub3JnPokCVAQTAQoAPhYhBOHPIN3/5Lie
gCZY8eCxGJT2auyYBQJZIzBOAhsDBQkPCZwABQsJCAcDBRUKCQgLBRYCAwEAAh4B
AheAAAoJEOCxGJT2auyYKFoP/R5ijjBRlLpClTvhk5p1pE/cJbMAHd1Y7x09iSN3
nT222tx4Zk3wVnP/1puJNkOxW7btMuUNz6Y4DolLpAa71hq3NOsTGz+5PL8ZFBoi
lIN2iOpfzqIFLASM0Pz6X+twV3ZyE1PZmfzLAu8OWm4kt1v3qJVtWN/5dHbjTqMt
vUc28VX1di51zWTs+3b/SDC+KN98i9W64JUiHPcLL6b2Y44fDszDDVVExwtPrPk0
VU+et4/uWmhcdEIEb91MIEsLAUJIBqcGTZU7Gymxupa3vApT6UUxfNKkVCGDN5dk
zFKkS6p2NEQjtIPNAheBwUfHqSDeN+EW4IuQxHZ92o+XGFMHqU29Vy81sPkGvKkG
EIL12iMpW9hDTbjO/+v695o3tVo/h1b0NSZP3Jk4I3iDBpAcUEYarxoOung2K1fC
QYH7R+7hy3lnRP36s9za6rEbik0c4XRvyYaYq7npGEq4CqhcKgRhZqVcy2Zmymcw
MqR1wLSxEmbREQZfBCFh5zpVC+kmRHfXCmZyAfDwLgGuMDVL7piCW5DqpC04Ks7M
Uj/r1O5hyMEjIzcdATVBMNJmdOPw7d0vqgBUizj0Y/e8RhmY8mkmy1zoI1HU7JfF
eKNnK/I2KYUop0qV0+bEFcu0RiEFVMP5cw4L2QAr1Y39XJNFU3v7IujRZXkxLn+H
6l4HiQJVBBABCAA/FiEE+/q9tUG13JVb2bpu2xbPW7ElJcQFAlkknnUhGmh0dHA6
Ly9ncGcuZ2FubmVmZi5kZS9wb2xpY3kudHh0AAoJENsWz1uxJSXE0z8P/3wl5xqi
wO8sHcMtPXRoOMGRBGlXN/GWbEuqOxaN4lVko+sqGTineW0nk6bx9zhTFDCXjEpK
da6M8Tc7V/cQoEyrV7btFolrb1KPKl5cVTsxKbLSJO79VgN9CZdrv8xS1VsI6SW/
7euwZmdjYCnOqs049uAxmeZU3HI/yjaOowhDDHAXRvzzbMTN5Y8aWqE1Sv/ndnb+
qHDq0Xh6hX0iS+Szx7KIGDLsgPPPjvEfsfmXVhYrWPdB4KXIeOcISehblxxU9FCE
JmArB0txQtW595m/Gn5ntVbiyHhrhNlGYT+6D1Fsw3q1l9kIzj8ro2/yRcZ/JRot
w5j5bMbYatQGoxmaBr9AaHCyUmmQEwfQFqBDnOBrV2XwLlurIX3ZvkQQVy5e4ysp
9K8lAd5X4k3sKOSca9HooIcK8szc48aUijHabzOzU459qrds5iX10q0L5It1FqLp
obg2l3wLWU7XwAP6K7m6LcvSa+2QqJmh72SBLd6xPCQAdwwUgdfzjovxTpdQu+3u
5NX+ud4uc+WP8bEG1oT

Bug#760414: [ola] Some sources are not included in your package

[Ansgar Burchardt]

Ansgar Burchardt writes:
>> This case is the same as when we deal with a convenience copy of a
>> library that ships with a program: you don't need to remove the
>> convenience copy, but you do need to ensure it isn't used.
>
> If the convenience copy comes without source, it should be removed as
> well (or source provided, either way is fine).

And just as a further comment: one of the reasons we want this is that
it is much easier to be sure that source is always available is when it
is always available, even for artifacts that /should/ not be used.  And
when reviewing one doesn't have to try and figure out if it will be used
or not.

It often turns out they are used after all (by accident) as it looks to
be the case here as well.

Ansgar

Bug#850229: openmpi-bin: default for oversubscription changed

[Ansgar Burchardt]

On Thu, 2017-02-09 at 00:05 +0100, Santiago Vila wrote:
> In either case I'm setting this to serious again because it makes
> packages to fail on single-CPU systems, and having more than one CPU
> is
> definitely *not* part of the build-essential definition.

It is not, but trying to build packages below a path that includes
whitespace or shell metacharacters is also not forbidden by the build-
essential definition.  Or on strange filesystems not fully following
POSIX semantics.

I think all of these are however uncommon configurations these days and
wouldn't treat either as serious in my packages.

Ansgar

Bug#850229: dune-grid: FTBFS (not enough slots available)

[Ansgar Burchardt]

Control: reassign -1 openmpi-bin 2.0.2~git.20161225-8
Control: severity -1 important
Control: retitle -1 openmpi-bin: default for oversubscription changed

Santiago Vila writes:
> Package: src:dune-grid
> Version: 2.5.0-1
> Severity: serious
>
> Dear maintainer:
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
[...]
> Status:FAILED
> Output:
>
> --
>There are not enough slots available in the system to satisfy the 
> 2 slots
>that were requested by the application:
>  test-yaspgrid-yaspfactory-1d
>
>Either request fewer slots for your application, or make more 
> slots available
>for use.
>
> --

This looks like OpenMPI changed its default for oversubscription: it
seems to now default to not allowing starting more processes than cores
available (cores, not threads even).  The man page still documents the
`--nooversubscribe` option, though `mpirun --help` shows a
`--oversubscribe` option (which is not understood by older versions).

Other implementations of `mpirun` (mpich) don't seem to understand this
option either, but seem to allow oversubscription by default (like older
versions of OpenMPI).  So one cannot pass the new option to `mpirun`
unconditionally.

I think it is a bug in OpenMPI to just change this default; at least
there should be a way to control this via an environment variable so one
doesn't have to provide OpenMPI-specific options to `mpirun`.

Ansgar

Bug#850229: dune-grid: FTBFS (not enough slots available)

[Ansgar Burchardt]

On Thu, 2017-01-05 at 12:59 +0200, Graham Inggs wrote:
> On 05/01/2017 12:05, Santiago Vila wrote:
> > Status:FAILED
> > Output:
> >    --
> > 
> >    There are not enough slots available in the system to
> > satisfy the 2 slots
> >    that were requested by the application:
> >  test-yaspgrid-yaspfactory-1d
> > 
> >    Either request fewer slots for your application, or make
> > more slots available
> >    for use.
> >    --
> > 
> 
> I started seeing similar errors in other MPI applications since the 
> upload of openmpi 2.0.2~ to unstable.
> 
> The solution was to add --oversubscribe to the mpirun command line, 

Yes, it looks like OpenMPI changed the default :-/

> The bug should be reproducible with sbuild on a single CPU virtual
> > machine.
> > It always fail for me (I tried 10 times in different autobuilders).
> 
> If I understand correctly, --oversubscribe should be needed in your
> case where you have fewer CPUs than the number of processes
> requested, but I was seeing the errors even when there were more than
> enough CPUs available.

On my laptop with 4 cores + HT (so 8 threads), I see `mpirun` complain
once I start more than 4 processes, i.e. more processes than real
cores.  Did you count threads or cores when you tried?

Ansgar

Bug#849064: src:gkremldk: maintainer address bounces

[Ansgar Burchardt]

Source: gkremldk
Source-Version: 0.9.7-2
Severity: serious

[ Last uploader and sponsor in X-Debbugs-Cc ]

The maintainer address for gkremldk bounces, see below.

As the last maintainer upload was 2007 and this is the only package
(still) listing him as the maintainer, I wonder if he is still active.

Ansgar

Mail Delivery System writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   xaiki+...@cxhome.ath.cx
> Unrouteable address
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> Subject: gkremldk_0.9.7-2.2_source.changes ACCEPTED into unstable
[...]
> Date: Sun, 18 Dec 2016 23:33:32 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Fri, 16 Dec 2016 23:48:23 +0100
> Source: gkremldk
> Binary: gkrellm-mldonkey
> Architecture: source
> Version: 0.9.7-2.2
> Distribution: unstable
> Urgency: medium
> Maintainer: Niv Altivanik (Debian Packages) 
> Changed-By: Christoph Biedl 
> Description:
>  gkrellm-mldonkey - mldonkey plugin for gkrellm2
> Closes: 817480
> Changes:
>  gkremldk (0.9.7-2.2) unstable; urgency=medium
>  .
>* Non-maintainer upload
>* Bump debhelper compat level to 10. Closes: #817480
> Checksums-Sha1:
>  4d1247252cb699b1b317ce6137405c6a195c1de7 1736 gkremldk_0.9.7-2.2.dsc
>  469e95886ac47fe83582c671ffb7666bdffd88f7 2223 gkremldk_0.9.7-2.2.diff.gz
> Checksums-Sha256:
>  8638098ef5754b4bf1e2e950c31fdcef140acffdab5e16fbc33ae8da68dbe889 1736 
> gkremldk_0.9.7-2.2.dsc
>  334236f454f0b3c4678061f92ed2aac303bf01bf3c463603cc876269b1776c59 2223 
> gkremldk_0.9.7-2.2.diff.gz
> Files:
>  51090378f383b9753c5a2aa32e4a5f58 1736 x11 optional gkremldk_0.9.7-2.2.dsc
>  966c935553187abbbcfdf9f106c38182 2223 x11 optional gkremldk_0.9.7-2.2.diff.gz
>
>
>
> Thank you for your contribution to Debian.

Bug#849062: src:gplaycli: maintainer address bounces; no human uploader

[Ansgar Burchardt]

Source: gplaycli
Source-Version: 0.2.1-1
Severity: serious

The maintainer address for gplaycli bounces, see below.  There is also
no human uploader.

Ansgar

Mail Delivery System  writes:
>   matl...@matlink.fr
> all relevant MX records point to non-existent hosts
>
> -- This is a copy of the message, including all the headers. --
[...]
> Subject: gplaycli_0.2.1-1_source.changes ACCEPTED into unstable
[...]
> Date: Wed, 21 Dec 2016 21:04:05 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Tue, 20 Dec 2016 15:40:55 +0100
> Source: gplaycli
> Binary: gplaycli
> Architecture: source
> Version: 0.2.1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Matlink 
> Changed-By: Matlink 
> Description:
>  gplaycli   - Google Play downloader command line interface
> Changes:
>  gplaycli (0.2.1-1) unstable; urgency=medium
>  .
>* New upstream release.
> Checksums-Sha1:
>  eea48920b2ebec46f38150056708a39db2b95bba 1603 gplaycli_0.2.1-1.dsc
>  0f4e7a889bb059aea1a24788d943fcbc90d06842 66096 gplaycli_0.2.1.orig.tar.gz
>  a04b720a9f46f9f5cc7600a3549726bcb0d1a2f5 11120 gplaycli_0.2.1-1.debian.tar.xz
> Checksums-Sha256:
>  90d50eb8acfe1a58f0f7ae8fd6d42f08fc5c179a07b109089aa69f50679b67c7 1603 
> gplaycli_0.2.1-1.dsc
>  4153ffc11d8c849239928e5c2ea748347d37387adf9499e75409a02f67da438d 66096 
> gplaycli_0.2.1.orig.tar.gz
>  1e2333ad4ff31fd127d6d3ea5e751496f958c225313dc3c9aaea5b2d24837c59 11120 
> gplaycli_0.2.1-1.debian.tar.xz
> Files:
>  1ba2ffd65276a5782c26cc221ae606b9 1603 utils optional gplaycli_0.2.1-1.dsc
>  7de69baa966cbacc3c1500d3615a50ff 66096 utils optional 
> gplaycli_0.2.1.orig.tar.gz
>  ad1773ef73c2d20b0c64ecb8445f357f 11120 utils optional 
> gplaycli_0.2.1-1.debian.tar.xz
>
>
>
> Thank you for your contribution to Debian.

Bug#849063: src:haskell-mode: maintainer address bounces

[Ansgar Burchardt]

Source: haskell-mode
Source-Version: 16.1-1
Severity: serious

The maintainer address for haskell-mode bounces, see below.

Ansgar

Mail Delivery System writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   mornf...@debian.org
> Unrouteable address
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> Subject: haskell-mode_16.1-1_amd64.changes ACCEPTED into unstable
[...]
> Date: Mon, 19 Dec 2016 15:06:08 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Mon, 19 Dec 2016 14:57:00 +0100
> Source: haskell-mode
> Binary: haskell-mode
> Architecture: source all
> Version: 16.1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Petr Rockai 
> Changed-By: Barak A. Pearlmutter 
> Description:
>  haskell-mode - major mode for editing Haskell in Emacs
> Changes:
>  haskell-mode (16.1-1) unstable; urgency=medium
>  .
>* New upstream release
>* dh10 is --parallel by default
>* Simplify build scripts for simpler (more rational) upstream build process
> Checksums-Sha1:
>  05b91d7084b714b9be01a8b3c68cb3e23963d9f5 2068 haskell-mode_16.1-1.dsc
>  58a961f5f4c0875872e00955a1c4b30c2b4125ae 1192866 
> haskell-mode_16.1.orig.tar.gz
>  b9b882d7a264e26486d3f5822f075a6f41cce344 7068 
> haskell-mode_16.1-1.debian.tar.xz
>  09c911faa3e41fcb70b261c68f15c1d3fa3a1d43 186822 haskell-mode_16.1-1_all.deb
>  b6a4a9ca50e6a33c4fdd775dbec59c0cc00ca12a 8726 
> haskell-mode_16.1-1_amd64.buildinfo
> Checksums-Sha256:
>  80dd211625990d5caca065db86221b924a54f5cffed2dadd5537983fc69b9954 2068 
> haskell-mode_16.1-1.dsc
>  109d9a0070825745c20f590c7fd0a1d2bb873d931db5ecc7deea317ab864d43c 1192866 
> haskell-mode_16.1.orig.tar.gz
>  35156763f487ecb606bab0bbbf8856816b327b2696a9d677810002a0d5577c7a 7068 
> haskell-mode_16.1-1.debian.tar.xz
>  cc26fac3d18be32235f099edf67820aa346819dbcc07e2023261e85fd6b0df55 186822 
> haskell-mode_16.1-1_all.deb
>  60fcabdec9da4b769a1124c1aae5eafc801109f0246bcfcd38d35e064db12c34 8726 
> haskell-mode_16.1-1_amd64.buildinfo
> Files:
>  d48155b79c893e1540961c2981e8c6be 2068 haskell optional 
> haskell-mode_16.1-1.dsc
>  2ad24b91681a6eda4e3384f4851bd3ad 1192866 haskell optional 
> haskell-mode_16.1.orig.tar.gz
>  800f1f6ecefe4cd24f73e68787e8e980 7068 haskell optional 
> haskell-mode_16.1-1.debian.tar.xz
>  3664c12ab0882ef4337dcfa1d05f3e0f 186822 haskell optional 
> haskell-mode_16.1-1_all.deb
>  3d5e9c5d43233f0e571e66b26efe2c59 8726 haskell optional 
> haskell-mode_16.1-1_amd64.buildinfo
>
>
>
> Thank you for your contribution to Debian.

Bug#836525: debootstrap: doesn't support arch-qualified dependencies

[Ansgar Burchardt]

Hi,

there is a second implementation of pkgdetails in C (part of the base-
installer source package).  I assume that would also need to be patched
to ignore architecture qualifications?

Ansgar

Bug#838327: dune-pdelab: FTBFS in testing (error: cannot convert 'mem_usage_t*' to 'GlobalLU_t*')

[Ansgar Burchardt]

Santiago Vila writes:
> /usr/include/dune/istl/superlu.hh: In static member function 'static void 
> Dune::SuperLUSolveChooser::solve(superlu_options_t*, SuperMatrix*, 
> int*, int*, int*, char*, double*, double*, SuperMatrix*, SuperMatrix*, void*, 
> int, SuperMatrix*, SuperMatrix*, double*, double*, double*, double*, 
> mem_usage_t*, SuperLUStat_t*, int*)':
> /usr/include/dune/istl/superlu.hh:172:34: error: cannot convert 
> 'mem_usage_t*' to 'GlobalLU_t*' for argument '19' to 'void 
> dgssvx(superlu_options_t*, SuperMatrix*, int*, int*, int*, char*, double*, 
> double*, SuperMatrix*, SuperMatrix*, void*, int, SuperMatrix*, SuperMatrix*, 
> double*, double*, double*, double*, GlobalLU_t*, mem_usage_t*, 
> SuperLUStat_t*, int*)'
>   memusage, stat, info);
>   ^

That looks like an API change in SuperLU.  The following changelog entry
for SuperLU 5.0 looks related:

+---
|  Remove 'static' variable 'Glu' in *gstrf.c, instead, pass it as an argument.
+---[ http://crd-legacy.lbl.gov/~xiaoye/SuperLU/changes.html ]

I wouldn't be surprised if `GlobalLU_t` and `Glu` were related; will try
to look at this.

Ansgar

Bug#838228: src:lakai: maintainer address bounces

[Ansgar Burchardt]

Source: lakai
Version: 0.1-1
Severity: serious

The maintainer address for lakai bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   f...@agnula.org
> No Such User Here
>
> Reporting-MTA: dns; server211.web-hosting.com
>
> Action: failed
> Final-Recipient: rfc822;f...@agnula.org
> Status: 5.0.0
>
> From: Debian FTP Masters 
> Subject: lakai_0.1-1.1_source.changes ACCEPTED into unstable
> To: Gustavo Soares de Lima , Free Ekanayaka 
> ,  
> Date: Sat, 17 Sep 2016 23:48:29 + (18 hours, 6 minutes, 38 seconds ago)
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Wed, 07 Sep 2016 16:41:52 +
> Source: lakai
> Binary: lakai
> Architecture: source
> Version: 0.1-1.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Free Ekanayaka 
> Changed-By: Gustavo Soares de Lima 
> Description:
>  lakai  - transfers samples between a PC and an AKAI sampler
> Closes: 449603 450202 817516 835651
> Changes:
>  lakai (0.1-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* debian/compat:
>- Update level to 9. (Closes: #817516)
>* debian/control:
>- Added Homepage. (Closes: #835651)
>- Bumped level debhelper to 9.
>- Bumped Standards-Version to 3.9.8.
>* debian/watch:
>- Update. (Closes: #449603, #450202).
> Checksums-Sha1:
>  eb85a022cc9c158c575d0dd8d43e7076c804bc5d 1617 lakai_0.1-1.1.dsc
>  245deda9478e93c005f0a93182b7b806317422b6 2299 lakai_0.1-1.1.diff.gz
> Checksums-Sha256:
>  4b94353b8c53f3cd0ed9cf30c96afdde349d528c24c6f8d76dd835ffe5932b5e 1617 
> lakai_0.1-1.1.dsc
>  811672d01e70007ca2c2631d4149b9efe44289a32cd033ae88af4e87765c37a4 2299 
> lakai_0.1-1.1.diff.gz
> Files:
>  ad8d9d6e95cd7de55b83b9a0d7228f5c 1617 sound optional lakai_0.1-1.1.dsc
>  15b143eaaa70c852ed5d02f935464f9a 2299 sound optional lakai_0.1-1.1.diff.gz
>
>
>
> Thank you for your contribution to Debian.
> --

Bug#833327: xmldiff: maintainer address bounces

[Ansgar Burchardt]

Source: xmldiff
Version: 0.6.10-2
Severity: serious

[ Uploaders X-Debbugs-Cc'ed ]

The maintainer address for xmldiff bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   afayo...@debian.org
> Unrouteable address
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Alexandre Fayolle , John Paul Adrian Glaubitz 
> 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: xmldiff
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: xmldiff_0.6.10-2.2_amd64.changes ACCEPTED into unstable
> Message-Id: [...]
> Date: Wed, 03 Aug 2016 04:34:49 +
>
> Mapping sid to unstable.
>
> Accepted:
>
> Format: 1.8
> Date: Wed, 03 Aug 2016 05:59:29 +0200
> Source: xmldiff
> Binary: xmldiff xmldiff-xmlrev
> Architecture: source amd64 all
> Version: 0.6.10-2.2
> Distribution: sid
> Urgency: medium
> Maintainer: Alexandre Fayolle 
> Changed-By: John Paul Adrian Glaubitz 
> Description:
>  xmldiff- tree to tree correction between xml documents
>  xmldiff-xmlrev - xmldiff output formatter
> Closes: 822039
> Changes:
>  xmldiff (0.6.10-2.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Add build-arch and build-indep targets to debian/rules to fix
>  FTBFS with newer versions of dpkg (Closes: #822039)
> Checksums-Sha1:
>  2f0f87aa9d1ad8190ea6073dc564e5ec718242b7 1981 xmldiff_0.6.10-2.2.dsc
>  c939c67aa97b2fd1d087308e6183674ac5fb5071 4404 xmldiff_0.6.10-2.2.diff.gz
>  562b85a2a148ea226f1a0b99a425cf76f274c8e1 11038 
> xmldiff-dbgsym_0.6.10-2.2_amd64.deb
>  d069ddb7d738dd9c14e14b882eb7b52ab2787b95 8646 
> xmldiff-xmlrev_0.6.10-2.2_all.deb
>  39246abfce47bec773312a488692ea6ce0e96968 43726 xmldiff_0.6.10-2.2_amd64.deb
> Checksums-Sha256:
>  04f1dba94436a7cd282acca063e697680d2c103633fea4f348183e2a481409dd 1981 
> xmldiff_0.6.10-2.2.dsc
>  5e404657e73eae4e67cfcfff23433a4d73f77034cf4c1461e0276e3193ab4b1f 4404 
> xmldiff_0.6.10-2.2.diff.gz
>  4675477b1a512f31e84880534c384bb5a794d7a0a10323d4b775d0b28bb351cf 11038 
> xmldiff-dbgsym_0.6.10-2.2_amd64.deb
>  6302573638935240ed56a8bf6d398331cfa57529a014432fa116d31ec4a00fe5 8646 
> xmldiff-xmlrev_0.6.10-2.2_all.deb
>  1e27b93b3ce05763dbe8e48eb3181436031d15cc22dab739164688d8a9b0a876 43726 
> xmldiff_0.6.10-2.2_amd64.deb
> Files:
>  5b2d7bb27c8910d25fafa327e9bbd9e2 1981 misc optional xmldiff_0.6.10-2.2.dsc
>  5356d53d2116dc3b7341c08510787368 4404 misc optional 
> xmldiff_0.6.10-2.2.diff.gz
>  6394766b9020e8039387fd8c3d140d2a 11038 debug extra 
> xmldiff-dbgsym_0.6.10-2.2_amd64.deb
>  851e76ecc29b2e570f3609b0de9e1234 8646 misc optional 
> xmldiff-xmlrev_0.6.10-2.2_all.deb
>  1b74a41206b3165d40cfab6df1b79a4d 43726 misc optional 
> xmldiff_0.6.10-2.2_amd64.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#832329: python-qrcode: maintainer address bounces

[Ansgar Burchardt]

Source: python-qrcode
Version: 5.0.1-1
Severity: serious

[ Cc'ed comaintainers ]

The maintainer address for python-qrcode bounces, see below.

Ansgar

Mail Delivery System writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   cornelius.koel...@lsexperts.de
> SMTP error from remote mail server after RCPT 
> TO::
> host mutt.lsexperts.de [91.208.83.25]: 450 4.1.1 
> :
> Recipient address rejected: unverified address:
> Address lookup failed. For assistance, see domain whois information.  
> Please provide the following information in your problem report:
>  time (Jul 24 00:13:02), client (82.195.75.114) and server 
> (mutt.lsexperts.de).:
> retry timeout exceeded
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: =?utf-8?q?Cornelius_K=C3=B6lbel_=28Debian_Packaging=29?= 
> , Thomas Goirand 
[...]
> Subject: python-qrcode_5.0.1-1.1_amd64.changes ACCEPTED into unstable, 
> unstable
> Message-Id: 
> Date: Tue, 19 Jul 2016 22:00:11 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Wed, 13 Jul 2016 12:31:48 +
> Source: python-qrcode
> Binary: python-qrcode python3-qrcode
> Architecture: source all
> Version: 5.0.1-1.1
> Distribution: unstable
[...]

Bug#830986: libjs-handlebars: missing source

[Ansgar Burchardt]

Source: libjs-handlebars
Version: 1.3.0-1
Severity: serious
Control: clone -1 -2
Control: reassign -2 ruby-handlebars-assets
Control: found -2 2:0.23.0-2
Control: block -2 by -1

Hi,

I briefly looked into the package due to the discussion on -devel@ and
the ctte bug.  The source for the javascript code seems to be missing:
it contains generated lexer/parser code, see the upstream source at

  https://github.com/wycats/handlebars.js/blob/v1.3.0/src/handlebars.l

(Just search for "yytext" in handlebars-v1.3.0.js
or vendor/assets/javascripts/handlebars.js for ruby-handlebar-assets.)

That seems to be a bit more than just concatenating files.

Ansgar

Bug#823345: golang-logrus: maintainer address bounces

[Ansgar Burchardt]

Source: golang-logrus
Version: 0.10.0-1
Severity: serious

The maintainer address for golang-logrus bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   j...@docker.com
> SMTP error from remote mail server after RCPT TO::
> host aspmx.l.google.com [2a00:1450:400c:c09::1a]:
> 550-5.1.1 The email account that you tried to reach does not exist. 
> Please try
> 550-5.1.1 double-checking the recipient's email address for typos or
> 550-5.1.1 unnecessary spaces. Learn more at
> 550 5.1.1  https://support.google.com/mail/answer/6596 gg1si106659wjd.214 
> - gsmtp
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Jessie Frazelle , =?utf-8?q?Mart=C3=ADn_Ferrari?= 
> 
[...]
> Subject: golang-logrus_0.10.0-1_amd64.changes ACCEPTED into unstable
[...]
> Date: Tue, 03 May 2016 18:22:07 +

Bug#816897: sbuild --build-dep-resolver=aptitude will install packages from untrusted sources

[Ansgar Burchardt]

Package: sbuild
Version: 0.68.0-1
Severity: serious
Tags: security

sbuild --build-dep-resolver=aptitude will install packages from
untrusted sources. I'm building a backports of dune-geometry in a
freshly created jessie-backports chroot. For this I added a local apt
repository

  deb file:///srv/apt/ansgar/pub jessie-backports main

to the chroot's sources.list (there is a bind mount setup too). The
signing key was *not* installed yet (as I forgot to do so).

Building the package with

  $ /usr/bin/sbuild -j8 -d jessie-backports -A \
--build-dep-resolver=aptitude dune-geometry_2.4.1-1~bpo8+1.dsc

made apt in the chroot complain as expected:

+---
| W: GPG error: file: jessie-backports InRelease: The following signatures
| couldn't be verified because the public key is not available:
| NO_PUBKEY 4618504DFB3AD1E0
+---

But to my surprise, the aptitude solver went on to install packages from there:

+---
| aptitude -y --without-recommends -o Dpkg::Options::=--force-confold
| -o Aptitude::CmdLine::Ignore-Trust-Violations=false [...]
| install sbuild-build-depends-dune-geometry-dummy:amd64
| [...]
| The following actions will resolve these dependencies:
|
|   Install the following packages:
| 1)  libdune-common-dev [2.4.1-1~bpo8+1 ()]
| [...]
| Selecting previously unselected package libdune-common-dev:amd64.
| Preparing to unpack .../libdune-common-dev_2.4.1-1~bpo8+1_amd64.deb ...
| Unpacking libdune-common-dev:amd64 (2.4.1-1~bpo8+1) ...
| [...]
| Setting up libdune-common-dev:amd64 (2.4.1-1~bpo8+1) ...
| [...]
| Package versions: [...] libdune-common-dev_2.4.1-1~bpo8+1 [...]
+---

I'm not sure if this is an issue with sbuild calling aptitude or with
aptitude. Feel free to reassign to aptitude (aptitude 0.6.11-1+b1 was
installed in the chroot).

(This was before the dune-common backport reached the archive.)

Ansgar

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (100, 'buildd-unstable'), 
(100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.2.4
ii  libsbuild-perl  0.68.0-1
ii  perl5.22.1-7

Versions of packages sbuild recommends:
ii  debootstrap  1.0.79
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.17.1-1+b1

-- no debconf information

Bug#815592: gpicview: maintainer address bounces

[Ansgar Burchardt]

Source: gpicview
Severity: serious
Tags: sid
X-Debbugs-Cc: Ulises Vitulli 

The maintainer address for gpicview bounces, see below.

Ansgar

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   lxde-deb...@lists.lxde.org
> SMTP error from remote mail server after RCPT 
> TO::
> host lists.lxde.org [2a03:b0c0:2:d0::41:c001]:
> 550 5.1.1 : Recipient address rejected:
> User unknown in local recipient table
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Debian LXDE Maintainers , Ulises Vitulli 
> 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: gpicview
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: gpicview_0.2.5-1_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Mon, 22 Feb 2016 12:19:37 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Mon, 22 Feb 2016 08:37:24 -0300
> Source: gpicview
> Binary: gpicview gpicview-dbg
> Architecture: source amd64
> Version: 0.2.5-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian LXDE Maintainers 
> Changed-By: Ulises Vitulli 
> Description:
>  gpicview   - lightweight image viewer
>  gpicview-dbg - lightweight image viewer (debug)
> Changes:
>  gpicview (0.2.5-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Bump up standards version.
> Checksums-Sha1:
>  a2496d0403c12e1a5736bcde22c40324ecc0da12 2001 gpicview_0.2.5-1.dsc
>  6741b107c190574abd4ae31f281462b0536e495a 349536 gpicview_0.2.5.orig.tar.xz
>  20da681eb0a776683e3ca4420aa0075d9f14ffb9 30320 gpicview_0.2.5-1.debian.tar.xz
>  c4cc5070516c694124d3a80bd595b1072d94d9b2 161610 
> gpicview-dbg_0.2.5-1_amd64.deb
>  c61abe92e299ef42a3d1c0a1c11474b289294191 139852 gpicview_0.2.5-1_amd64.deb
> Checksums-Sha256:
>  e125350e27096c5388bb91bcd9ea07a057a13c6719fa0b21103e56315b8fb0e9 2001 
> gpicview_0.2.5-1.dsc
>  38466058e53702450e5899193c4b264339959b563dd5cd81f6f690de32d82942 349536 
> gpicview_0.2.5.orig.tar.xz
>  ef180d3ae981577959040772e917756b0484c914c91b4c7223cd0714db587b58 30320 
> gpicview_0.2.5-1.debian.tar.xz
>  3a55c137f4f4bbe2e5c77d1e402882eb6033f889d69da7a05aeb21e4cc37e396 161610 
> gpicview-dbg_0.2.5-1_amd64.deb
>  d6a0bad0f2c6378d9ab41ba952969a6bb7f3dcce4515a736f1435937aa07abf6 139852 
> gpicview_0.2.5-1_amd64.deb
> Files:
>  f795b6047e72aa2f04361e17258aa4e2 2001 graphics optional gpicview_0.2.5-1.dsc
>  26be9b0c5a234f1afe7d83d02a4a33f4 349536 graphics optional 
> gpicview_0.2.5.orig.tar.xz
>  81c9be8b4c7a0757194d649c3dae290b 30320 graphics optional 
> gpicview_0.2.5-1.debian.tar.xz
>  0e9c10c8a3cd93d23865f91063d529ff 161610 debug extra 
> gpicview-dbg_0.2.5-1_amd64.deb
>  f57e88941182d0b392a00a072b13ba36 139852 graphics optional 
> gpicview_0.2.5-1_amd64.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#815105: dalvik-exchange: abuses Conflicts

[Ansgar Burchardt]

Package: dalvik-exchange
Version: 6.0.1+r16-2
Severity: serious

Please don't abuse Conflicts: to "solve" the issue of multiple packages
shipping the same binary, see
https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries
as mentioned in #814149.

Ansgar

Bug#813164: This is, in fact, dangerous

[Ansgar Burchardt]

Wouter Verhelst  writes:
> With the ls version before this change, J. Random Inexperienced Hacker
> would see that there are multiple file names on a single line in the
> output of ls, decide that ls output is too difficult to parse, and move
> on to something else (probably find or some such).
>
> With the ls version after this change, J. Random Inexperienced Hacker
> might decide that the quoted nature of the ls output is *ideal* for
> parsing, add something along the lines of
> INPUT=$(ls /path/to/input/directory)
> to his script, and think he's safe against filenames with spaces in them
> ("because ls quotes output").

J Random Inexperienced Hacker already does this in the present day
though.

> The default enabling of the -C option when ls is connected to a terminal
> doesn't do harm (and in fact discourages this kind of unsafe behaviour).
> However, showing characters that aren't part of a filename in ls output
> *by default* is confusing and (as the above shows) potentially
> dangerous.

ls already showed characters that aren't part of a filename *before*
this change:

  $ ls /tmp/a
  a  a

Neither filename contains a question mark, and the filenames are
actually not identical.

One could argue that "ls" should give an error when it encounters any
character that might need quoting instead of enabling quoting by
default. (And this is probably also true when output does not go to a
terminal: at least printing \n as part of a filename is pretty much
always broken.)

Ansgar

Bug#812970: init-system-helpers and file-rc: error when trying to install together

[Ansgar Burchardt]

Control: reassign -1 file-rc/0.8.17,sysv-rc/2.88dsf-59.3
Control: retitle -1 sysv-rc and file-rc: error when trying to install together

Ralf Treinen  writes:
> Package: file-rc,init-system-helpers

This is actually a conflict between file-rc and sysv-rc.  The one
between file-rc and init-system-helpers should have been fixed:

> Setting up sysv-rc (2.88dsf-59.3) ...
> Selecting previously unselected package file-rc.
> (Reading database ... 11028 files and directories currently installed.)
> Preparing to unpack .../file-rc_0.8.17_all.deb ...
> Adding 'diversion of /usr/sbin/update-rc.d to 
> /usr/sbin/update-rc.d.init-system-helpers by file-rc'
> Adding 'diversion of /usr/sbin/invoke-rc.d to 
> /usr/sbin/invoke-rc.d.init-system-helpers by file-rc'
> Adding 'diversion of /usr/share/man/man8/update-rc.d.8.gz to 
> /usr/share/man/man8/update-rc.d.8.gz.init-system-helpers by file-rc'
> Adding 'diversion of /usr/share/man/man8/invoke-rc.d.8.gz to 
> /usr/share/man/man8/invoke-rc.d.8.gz.init-system-helpers by file-rc'

There are diversions for the files in both file-rc and
init-system-helpers.

> Unpacking file-rc (0.8.17) ...
> dpkg: error processing archive /var/cache/apt/archives/file-rc_0.8.17_all.deb 
> (--unpack):
>  trying to overwrite '/etc/init.d/README', which is also in package sysv-rc 
> 2.88dsf-59.3

However file-rc also contains files conflicting with sysv-rc which are
not handled correctly.

Ansgar

Bug#811522: proposed RM: jenkins -- RoQA; multiple security issues, FTBFS, unmaintained in Debian

[Ansgar Burchardt]

Package: jenkins
Severity: serious

Hi,

the jenkins package in Debian has multiple open security issues[1][2]
and fails to build with Groovy 2[3].  It also is quite outdated
(Debian: 1.565.3 released upstream mid-2014; current version: 1.644
from Jan 2016 with lots of releases inbetween).

Jenkins also isn't part of a stable release (currently only in
unstable).

I suggest to remove the package from Debian.  If there are no
objections, I'll reassign the request to the ftp.debian.org pseudo-
package later.

I'm also wondering if "jenkins-memory-monitor" should also be removed
at the same time or if it is also useful without jenkins?

Ansgar

  [1] 
  [2] 
  [3] 

Bug#810673: proposed RM: mountall -- RoQA; only used by upstart which was removed

[Ansgar Burchardt]

Package: mountall
Version: 2.54
Severity: serious
Tags: sid

upstart was removed from Debian and Michael Biebl pointed out that the
"mountall" tool was only packaged for use with it.  So it should
probably be removed as well.

Besides upstart, apt-cache rdepends shows only cgroupfs-mount, but the
current version only suggests mountall.

If there are no objections, I'll reassign the removal request to ftp.d.o
later.

Ansgar

Bug#809843: autopsy: maintainer address bounces

[Ansgar Burchardt]

Source: autopsy
Source-Version: 2.24-1.1
Tags: sid
Severity: serious

The maintainer address for autopsy bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   martig...@debian.org
> Unrouteable address
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Lorenzo Martignoni , Andreas Metzler 
> 
[...]
> Subject: autopsy_2.24-1.1_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Mon, 04 Jan 2016 13:48:49 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Sun, 20 Dec 2015 14:02:36 +0100
> Source: autopsy
> Binary: autopsy
> Architecture: source all
> Version: 2.24-1.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Lorenzo Martignoni 
> Changed-By: Andreas Metzler 
> Description:
>  autopsy- graphical interface to SleuthKit
> Closes: 803030
> Changes:
>  autopsy (2.24-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Use "find -perm /x" instead of "find -perm +x". Closes: #803030
> Checksums-Sha1:
>  fb773608c2f05c00b655128e947f0ec6672f8bb6 1679 autopsy_2.24-1.1.dsc
>  f74dbb489b381c8c30a1642b3829566ba67ae631 15145 autopsy_2.24-1.1.diff.gz
>  1ab49e0a0b826e0b737e870c1956a3d3f9566b43 335922 autopsy_2.24-1.1_all.deb
> Checksums-Sha256:
>  436232a66253ab4b21e2798c8a746ac48e8d2103e3bc6154c84a99e7d9b7721f 1679 
> autopsy_2.24-1.1.dsc
>  9f62099bac1a85a5a4941df12c9ffcf2360d6a7b077d2807737523466db377cd 15145 
> autopsy_2.24-1.1.diff.gz
>  3d0bafd82970a08c0f03c67772aa9c4942f55ac82c059ab8f23ef2c8bc83825e 335922 
> autopsy_2.24-1.1_all.deb
> Files:
>  29e35b5081ef364448140d3a4dc1504f 1679 admin optional autopsy_2.24-1.1.dsc
>  c3c59d64e6c6cdd525e20bafe1f1787d 15145 admin optional 
> autopsy_2.24-1.1.diff.gz
>  0e461602f3f72ea560c7490063fe5e8f 335922 admin optional 
> autopsy_2.24-1.1_all.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#809625: empire-hub: maintainer address bounces

[Ansgar Burchardt]

Source: empire-hub
Version: 1.0.2.1+nmu1
Severity: serious

The maintainer address for empire-hub bounces, see below.

Ansgar

mailer-dae...@anu.edu.au (Mail Delivery System) writes:
> This is the mail system at host mailpmx5.anu.edu.au.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>The mail system
>
> : host maildrop.anu.edu.au[130.56.66.75] said: 550
> 5.1.1 ... User unknown (in reply to RCPT TO
> command)
>
> Reporting-MTA: dns; mailpmx5.anu.edu.au
> X-Postfix-Queue-ID: C2933801A5
> X-Postfix-Sender: rfc822; envel...@ftp-master.debian.org
> Arrival-Date: Sat,  2 Jan 2016 04:48:51 +1100 (AEDT)
>
> Final-Recipient: rfc822; drake.diedr...@anu.edu.au
> Original-Recipient: rfc822;drake.diedr...@anu.edu.au
> Action: failed
> Status: 5.1.1
> Remote-MTA: dns; maildrop.anu.edu.au
> Diagnostic-Code: smtp; 550 5.1.1 ... User unknown
>
> From: Debian FTP Masters 
> Subject: empire-hub_1.0.2.1+nmu1_source.changes ACCEPTED into unstable
> To: Drake Diedrich , Raphael Mota Ramos 
> ,  
> Date: Fri, 01 Jan 2016 17:48:47 + (7 hours, 38 minutes, 42 seconds ago)
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Sun, 20 Dec 2015 10:50:13 -0200
> Source: empire-hub
> Binary: empire-hub
> Architecture: source
> Version: 1.0.2.1+nmu1
> Distribution: unstable
> Urgency: medium
> Maintainer: Drake Diedrich 
> Changed-By: Raphael Mota Ramos 
> Description:
>  empire-hub - Empire protocol multiplexer
> Closes: 800179
> Changes:
>  empire-hub (1.0.2.1+nmu1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Update DH level to 9 to avoid a FTBFS. (Closes: #800179)
>* debian/compat: created.
>* debian/control:
>   - Added the ${msic:Depends} variable to provide the
> right install dependencies.
>   - Bumped Standards-Version to 3.9.6.
>* debian/rules: changed the install to put the final
>  files in right place.
> Checksums-Sha1:
>  d0c10700d0e67d94c8fa20830a927d1bed101971 1417 empire-hub_1.0.2.1+nmu1.dsc
>  9e35cf2c8219cc41691d20701c1aa2a37dbbc38b 16854 empire-hub_1.0.2.1+nmu1.tar.gz
> Checksums-Sha256:
>  66ad14e0a649fc13c4e2c2e33d46db054b7b66b21c5727b68478111dd8049a18 1417 
> empire-hub_1.0.2.1+nmu1.dsc
>  2cfc0e7bc132aabfe518893d0548e33d3462188b44b27a3a965bc7aeb0253e16 16854 
> empire-hub_1.0.2.1+nmu1.tar.gz
> Files:
>  79b7e9a2bc95f7b555ded7acaf993673 1417 games optional 
> empire-hub_1.0.2.1+nmu1.dsc
>  30ffb431fea26bab6941709bcd9cb777 16854 games optional 
> empire-hub_1.0.2.1+nmu1.tar.gz
>
>
>
> Thank you for your contribution to Debian.
> --

Bug#808126: simpletal: maintainer address bounces

[Ansgar Burchardt]

Source: simpletal
Severity: serious
Tags: sid

The maintainer address for simpletal bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   jen...@rulim.de
> SMTP error from remote mail server after RCPT TO::
> host aspmx.l.google.com [2607:f8b0:400e:c00::1b]:
> 550-5.1.1 The email account that you tried to reach does not exist. 
> Please try
> 550-5.1.1 double-checking the recipient's email address for typos or
> 550-5.1.1 unnecessary spaces. Learn more at
> 550 5.1.1  https://support.google.com/mail/answer/6596 
> wi4si16656301pab.220 - gsmtp
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> From: Debian FTP Masters 
> To: Igor Stroh , Mattia Rizzolo 
[...]
> Subject: simpletal_4.1-8_source.changes ACCEPTED into unstable
> Message-Id: 
> Date: Tue, 15 Dec 2015 00:35:41 +
>
[...]
> Maintainer: Igor Stroh 
> Changed-By: Mattia Rizzolo 

Bug#807760: cfflib: maintainer address bounces

[Ansgar Burchardt]

Source: cfflib
Tags: sid
Severity: serious

The maintainer address for cfflib bounces, see below.

Ansgar

Mail Delivery System writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   deb...@unidesign.ch
> SMTP error from remote mail server after RCPT TO::
> host unidesign.ch [194.126.200.43]: 550 No Such User Here"
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Stephan Gerhard , Mattia Rizzolo 
[...]
> Subject: cfflib_2.0.5-1.1_source.changes ACCEPTED into unstable
> Message-Id: 
> Date: Sat, 12 Dec 2015 00:18:58 +

Bug#807114: python-acme: needs python-openssl >= 0.15, but dependency is unversioned

[Ansgar Burchardt]

Source: python-acme
Version: 0.1.0-1
Severity: serious

python-acme needs at least version 0.15 of python-openssl.  This is
reflected in the Build-Depends, but the binary packages have an
unversioned dependency on python-openssl.

Trying to use the letsencrypt client with older versions of
python-openssl results in an error, see
https://github.com/letsencrypt/letsencrypt/issues/885

Ansgar

Bug#805610: python-lamson: maintainer address bounces

[Ansgar Burchardt]

Source: python-lamson
Tags: sid
Severity: serious
X-Debbugs-Cc: David Watson 

The maintainer address for python-lamson bounces:

+---
| This message was created automatically by mail delivery software.
|
| A message that you sent could not be delivered to one or more of its
| recipients. This is a permanent error. The following address(es) failed:
|
|   da...@kutoken.com
| Unrouteable address
+---

Ansgar

Bug#804654: magit: maintainer address bounces

[Ansgar Burchardt]

Source: magit
Severity: serious

The maintainer address for src:magit bounces. It should probably be
@lists.alioth.d.o.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   pkg-emacsen-add...@lists.debian.org
> SMTP error from remote mail server after RCPT 
> TO::
> host bendel.debian.org [2001:41b8:202:deb:216:36ff:fe40:4002]:
> 550 5.1.1 :
> Recipient address rejected: User unknown in virtual alias table
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Debian Emacs addons team , 
> =?utf-8?q?R=C3=A9mi_Vanicat?= 
[...]
> Maintainer: Debian Emacs addons team 

Bug#800744: setuptools-scm: maintainer address bounces

[Ansgar Burchardt]

Source: setuptools-scm
Version: 1.8.0-1
Tags: sid
Severity: serious
X-Debbugs-Cc: Tristan Seligmann 

[ CC'ed the sponsor. ]

The maintainer address for setuptools-scm bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   julien.pu...@laposte.net
> retry timeout exceeded
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Julien Puydt , 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: setuptools-scm
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: setuptools-scm_1.8.0-1_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Fri, 02 Oct 2015 09:22:14 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Fri, 02 Oct 2015 11:02:33 +0200
> Source: setuptools-scm
> Binary: python-setuptools-scm python3-setuptools-scm
> Architecture: source all
> Version: 1.8.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Julien Puydt 
> Changed-By: Julien Puydt 
> Description:
>  python-setuptools-scm - blessed package to manage your versions by scm tags 
> for Python 2
>  python3-setuptools-scm - blessed package to manage your versions by scm tags 
> for Python 3
> Changes:
>  setuptools-scm (1.8.0-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Put myself as sole maintainer.
> Checksums-Sha1:
>  3affc1728a7a2c01b0180ba18857c05f88867aeb 1904 setuptools-scm_1.8.0-1.dsc
>  03fdbb5f2023407c23ef38080a823cb195e51e01 14491 
> setuptools-scm_1.8.0.orig.tar.bz2
>  4faf34d58e69c4e2b24c0d4d6eaaeb96d72a84b6 1980 
> setuptools-scm_1.8.0-1.debian.tar.xz
>  852d03ad9087e845acb59a04d0c42747894bc330 11162 
> python-setuptools-scm_1.8.0-1_all.deb
>  336c4ec992aa760a01362f86226e7432ac5dbe57 11222 
> python3-setuptools-scm_1.8.0-1_all.deb
> Checksums-Sha256:
>  3d0544e1c27aa0f3daa29ab937630670d8202f768d72dae999ab7dd95dfee067 1904 
> setuptools-scm_1.8.0-1.dsc
>  ddbf365e60e5f8e3f86fe117edeee4a7e1dd8ce7a9337951c9c163e7c506e602 14491 
> setuptools-scm_1.8.0.orig.tar.bz2
>  f9d59eb303a38938fd4e6711ada750e22f0a59a7e9740e9355a1575d4e5730f1 1980 
> setuptools-scm_1.8.0-1.debian.tar.xz
>  07536d6b29950962ce5d2d1a7a55df578687a85de42ba0ef0a7d102e29a1de5d 11162 
> python-setuptools-scm_1.8.0-1_all.deb
>  9ad126c0eb8a41b03026ec3c1e62047627c8541483f9eb9d55fdf78ed9e296ed 11222 
> python3-setuptools-scm_1.8.0-1_all.deb
> Files:
>  f3e9b52ce3a3284431e19ca82aa65718 1904 python optional 
> setuptools-scm_1.8.0-1.dsc
>  49e83e8fee9ac1d356a634707a62e294 14491 python optional 
> setuptools-scm_1.8.0.orig.tar.bz2
>  c78a7e983d26861795f71cf5963ac69e 1980 python optional 
> setuptools-scm_1.8.0-1.debian.tar.xz
>  df8b0b1ce185038c5985752eaf0947cb 11162 python optional 
> python-setuptools-scm_1.8.0-1_all.deb
>  c41c236a261172aa8d7cf0ff7041a375 11222 python optional 
> python3-setuptools-scm_1.8.0-1_all.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#798413: ftp.debian.org: Source-only uploads which FTBFS on Arch: all buildd require NEW processing in next upload

[Ansgar Burchardt]

Control: retitle -1 dak cruft-report should check Package-List field
Control: severity -1 normal

Santiago Vila  writes:
> When a source-only upload fails to build from source in the
> "Arch: all" autobuilder [1], the system seems to think that the source
> does no longer provide such Arch: all packages.

The cruft report does think so after some time (meh, heuristics are bad)
and packages are then removed by the ftp team after some time.

The proper solution is probably to have the cruft-report check the
source package's Package-List field that lists all packages built (and
on which architecture they are built).

Ansgar

Bug#797941: src:pbnj: maintainer address bounces

[Ansgar Burchardt]

Source: pbnj
Severity: serious
Tags: sid

The maintainer address for pbnj bounces, see below.

Given the package was last uploaded by the maintainer in 2007, maybe the
package should be orphaned?

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   ja...@ccs.neu.edu
> SMTP error from remote mail server after RCPT TO::
> host amber.ccs.neu.edu [129.10.116.51]: 550 unknown user
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: ja...@ccs.neu.edu (Joshua D. Abraham), gregor herrmann 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: pbnj
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: pbnj_2.04-4.1_sourceonly.changes ACCEPTED into unstable
> Message-Id: 
> Date: Mon, 31 Aug 2015 17:23:33 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Wed, 26 Aug 2015 18:37:26 +0200
> Source: pbnj
> Binary: pbnj
> Architecture: source
> Version: 2.04-4.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Joshua D. Abraham 
> Changed-By: gregor herrmann 
> Closes: 795637
> Description: 
>  pbnj   - a suite of tools to monitor changes on a network
> Changes:
>  pbnj (2.04-4.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Fix "FTBFS with perl 5.22 in experimental (MakeMaker changes)":
>  use DESTDIR in debian/rules.
>  (Closes: #795637)
> Checksums-Sha1: 
>  e639e9d6ffbf13ce22995a8d5dc3f98846f2d7d1 1959 pbnj_2.04-4.1.dsc
>  0a497e7c312526937613ff9238cbb7be0562293f 2841 pbnj_2.04-4.1.diff.gz
> Checksums-Sha256: 
>  717239508ec532f3f59e5f520efb511aa9e756680c358ca22237cdba294ab572 1959 
> pbnj_2.04-4.1.dsc
>  16f0653da19de1b6e2819ebd67a59fb047196320927b4674af612ce8d1594821 2841 
> pbnj_2.04-4.1.diff.gz
> Files: 
>  3563b6f8fab4f91601346ce046338bcb 1959 net optional pbnj_2.04-4.1.dsc
>  6b6fd5e1386e11c477ffa7647c632485 2841 net optional pbnj_2.04-4.1.diff.gz
>
>
>
> Thank you for your contribution to Debian.

Bug#797940: src:dh-elpa: maintainer address bounces

[Ansgar Burchardt]

Source: dh-elpa
Source-Version: 0.0.5
Severity: serious
X-Debbugs-Cc: David Bremner 

The maintainer address bounces. I guess the list is on
@lists.*alioth*.d.o, not @lists.d.o.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   pkg-emacsen-add...@lists.debian.org
> SMTP error from remote mail server after RCPT 
> TO::
> host bendel.debian.org [2001:41b8:202:deb:216:36ff:fe40:4002]:
> 550 5.1.1 :
> Recipient address rejected: User unknown in virtual alias table
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Debian Emacs addons team , David 
> Bremner 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: dh-elpa
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: dh-elpa_0.0.5_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Tue, 01 Sep 2015 22:48:40 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Tue, 01 Sep 2015 19:09:51 -0300
> Source: dh-elpa
> Binary: dh-elpa
> Architecture: source all
> Version: 0.0.5
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Emacs addons team 
> Changed-By: David Bremner 
> Description:
>  dh-elpa- Debian helper tools for packaging emacs lisp extensions
> Changes:
>  dh-elpa (0.0.5) unstable; urgency=medium
>  .
>* Use debian/.debhelper/elpa for temp files. This allows easier
>  debugging.
>* Add a check for ${elpa_name}-pkg.el in multi-file packages
>* Link all top level files/directories into flavour directory, not
>  just *.el
> Checksums-Sha1:
>  420e8199d3209bf93e9d0638850115225c2f397c 1322 dh-elpa_0.0.5.dsc
>  b9186e0a45e93b7b866be9b1dc35f4e323d7516b 6538 dh-elpa_0.0.5.tar.gz
>  96a54ce03351565dbdf677517dd63a5d3cd4072e 9168 dh-elpa_0.0.5_all.deb
> Checksums-Sha256:
>  7eedff75b9bccfefab070b50c65cee8285407f86b8ac5ac7fe3b595795ffc226 1322 
> dh-elpa_0.0.5.dsc
>  6a271064ef771a37e5294fc8aecdde5c704002e75d452cf15e692f076db2601d 6538 
> dh-elpa_0.0.5.tar.gz
>  15d36252953837d9479b7ce2323e3984732ede8b0ac6eac6b5e87816998b486e 9168 
> dh-elpa_0.0.5_all.deb
> Files:
>  79a210e59db78409cdbad319021e3285 1322 devel optional dh-elpa_0.0.5.dsc
>  a9528cafcfb0db785d409287c12c26e4 6538 devel optional dh-elpa_0.0.5.tar.gz
>  3a823e8fa1341519abb0b30e760e34ce 9168 devel optional dh-elpa_0.0.5_all.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#797937: src:company-mode: maintainer address bounces

[Ansgar Burchardt]

Source: company-mode
Source-Version: 0.8.12-1
Severity: serious
X-Debbugs-Cc: David Bremner 

The maintainer address bounces. I guess the mailing list is
@lists.*alioth*.d.o, not @lists.d.o

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   pkg-emacsen-add...@lists.debian.org
> SMTP error from remote mail server after RCPT 
> TO::
> host bendel.debian.org [2001:41b8:202:deb:216:36ff:fe40:4002]:
> 550 5.1.1 :
> Recipient address rejected: User unknown in virtual alias table
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
[...]
> To: Debian Emacs addons team , David 
> Bremner 
> X-DAK: dak process-policy
> X-Debian: DAK
> X-Debian-Package: company-mode
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: company-mode_0.8.12-1_amd64.changes ACCEPTED into unstable, unstable
> Message-Id: 
> Date: Wed, 02 Sep 2015 11:00:09 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Fri, 21 Aug 2015 08:49:22 +0200
> Source: company-mode
> Binary: elpa-company
> Architecture: source all
> Version: 0.8.12-1
> Distribution: unstable
> Urgency: low
> Maintainer: Debian Emacs addons team 
> Changed-By: David Bremner 
> Description:
>  elpa-company - Modular in-buffer completion framework for Emacs
> Changes:
>  company-mode (0.8.12-1) unstable; urgency=low
>  .
>* Initial release
> Checksums-Sha1:
>  f0bd5eb142b188af633e25977e8d2db32957a3f5 1786 company-mode_0.8.12-1.dsc
>  0860d609f9104d44cc7cb9eb77483d9e2ad039d7 70379 
> company-mode_0.8.12.orig.tar.gz
>  feb789ffdf148afc174bffd3233466d50ecf07cb 2124 
> company-mode_0.8.12-1.debian.tar.xz
>  c7b280175261cc9e6b926c227d962044e4032152 59064 elpa-company_0.8.12-1_all.deb
> Checksums-Sha256:
>  f2505da463ec877e39e79000bcea4074205707b5fa4a9d5ce05f8b9f08371ea1 1786 
> company-mode_0.8.12-1.dsc
>  67937eda92a617f29091874b00aed04b4b48e8f18accf7bcb56ec64287f3d07d 70379 
> company-mode_0.8.12.orig.tar.gz
>  9e2864dd3165d60550d62fe4cbdb44eb51f2a41b2ffe77d3f1e79160df60 2124 
> company-mode_0.8.12-1.debian.tar.xz
>  d9fb689cb40f74cc494e3b3bf5cd16310dfddd9acd5470fcdefb64d18b2866b0 59064 
> elpa-company_0.8.12-1_all.deb
> Files:
>  445341b13c4df78b91f46edc555448c0 1786 lisp optional company-mode_0.8.12-1.dsc
>  2b4a286d666ca0e00c62b94aa52e7984 70379 lisp optional 
> company-mode_0.8.12.orig.tar.gz
>  4d8f36367727501b8f14bc2bb36a9f76 2124 lisp optional 
> company-mode_0.8.12-1.debian.tar.xz
>  b65e72310ee229009eb84f7d3c287f18 59064 lisp optional 
> elpa-company_0.8.12-1_all.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#795963: dune-istl: FTBFS: bcrsimplicitbuild.cc:269:51: error: no match for 'operator<<'

[Ansgar Burchardt]

Control: tag -1 upstream fixed-upstream
Control: fixed -1 2.4~20150506gee6e5f6-1

> dune-istl fails to build from source on unstable/amd64:
>
>   [..]
>
>   bcrsimplicitbuild.cc: In function 'int testEntryConsistency()':
>   bcrsimplicitbuild.cc:269:51: error: no match for 'operator<<' (operand
>   types are 'std::basic_ostream' and 'std::ostream {aka
>   std::basic_ostream}')
>std::cerr<<"ERROR: Entries are not consistent"<
Date:   Sat Nov 29 07:59:44 2014 +0100

Fix wrong std::cerr at end of output.

It should be std::endl.
Courtesy of GCC 5-svn, it refuses to compile these.

Ansgar

Bug#795242: incomplete copyright information

[Ansgar Burchardt]

Package: src:coin3
Version: 3.1.4~abc9f50-9
Severity: serious

debian/copyright is incomplete. At least the license and copyright
information for the embedded copy of expat that lintian warns about is
missing.

Ansgar

Bug#795241: source package contains *.exe without source

[Ansgar Burchardt]

Package: src:coin3
Version: 3.1.4~abc9f50-9
Severity: serious

The source package contains *.exe files for which the source seems to
be missing. Please make sure the source is included or exclude them
from the upstream tarball.

  coin3-3.1.4~abc9f50/cfg/*.exe

Ansgar

Bug#793959: src:libbio-das-lite-perl: maintainer address bounces

[Ansgar Burchardt]

Source: libbio-das-lite-perl
Source-Version: 2.04-1.2
Tags: sid
Severity: serious

The maintainer address for libbio-das-lite-perl bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   holl...@eaglegenomics.com
> SMTP error from remote mail server after RCPT 
> TO::
> host aspmx.l.google.com [2a00:1450:400c:c00::1a]:
> 550-5.1.1 The email account that you tried to reach does not exist. 
> Please try
> 550-5.1.1 double-checking the recipient's email address for typos or
> 550-5.1.1 unnecessary spaces. Learn more at
> 550 5.1.1  https://support.google.com/mail/answer/6596 
> pm7si6964450wjb.185 - gsmtp
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
[...]
> From: Debian FTP Masters 
> To: Richard Holland , Damyan Ivanov 
> 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: libbio-das-lite-perl
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: libbio-das-lite-perl_2.04-1.2_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Wed, 29 Jul 2015 10:49:10 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Fri, 24 Jul 2015 10:30:47 +
> Source: libbio-das-lite-perl
> Binary: libbio-das-lite-perl
> Architecture: source all
> Version: 2.04-1.2
> Distribution: unstable
> Urgency: medium
> Maintainer: Richard Holland 
> Changed-By: Damyan Ivanov 
> Description:
>  libbio-das-lite-perl - implementation of the BioDas protocol
> Closes: 789062
> Changes:
>  libbio-das-lite-perl (2.04-1.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Add explicit build dependency on libmodule-build-perl
>  Closes:  #789062 -- FTBFS with perl 5.22
> Checksums-Sha1:
>  49923b1a999ee8bfab25c522bebdafa63448adf1 2242 
> libbio-das-lite-perl_2.04-1.2.dsc
>  24276ed021f1d4e39bfacc0342513f3538bd8e72 1948 
> libbio-das-lite-perl_2.04-1.2.diff.gz
>  781e521b728d12b8be16d749a65941831c26e201 25182 
> libbio-das-lite-perl_2.04-1.2_all.deb
> Checksums-Sha256:
>  c8871f7e8f7970e6fd5749edc2c8cfc90123204d7b80b82fb4d624a1260dcf02 2242 
> libbio-das-lite-perl_2.04-1.2.dsc
>  4f7499748dca0e6948903457c4e12402519aa2434a92be11522b26b95438ab95 1948 
> libbio-das-lite-perl_2.04-1.2.diff.gz
>  0d7dc636645cff067bce61dab4775f3557ddeee28692a2b831998168c0516ec2 25182 
> libbio-das-lite-perl_2.04-1.2_all.deb
> Files:
>  ae9ce310ae727d5c9d699d5a7cf2396d 2242 perl optional 
> libbio-das-lite-perl_2.04-1.2.dsc
>  602d2136281ab0e8eb06b8424df527ce 1948 perl optional 
> libbio-das-lite-perl_2.04-1.2.diff.gz
>  fd07a3867e164b5e826e511c677332af 25182 perl optional 
> libbio-das-lite-perl_2.04-1.2_all.deb
>
>
>
> Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#793411: src:btcheck: maintainer address bounces

[Ansgar Burchardt]

Source: btcheck
Source-Version: 1.9-1
Tags: sid
Severity: serious

The maintainer address for btcheck bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   h...@ig.com.br
> SMTP error from remote mail server after HELO muffat.debian.org:
> host mx.ig.com.br [177.153.23.241]: 503 5.7.0 Error:
> access denied for unknown[206.12.19.146]
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
[...]
> From: Debian FTP Masters 
> To: Herbert Parentes Fortes Neto 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: btcheck
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: btcheck_1.9-1_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Thu, 23 Jul 2015 17:19:07 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Tue, 21 Jul 2015 10:57:53 -0300
> Source: btcheck
> Binary: btcheck
> Architecture: source amd64
> Version: 1.9-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Herbert Parentes Fortes Neto 
> Changed-By: Herbert Parentes Fortes Neto 
> Description:
>  btcheck- downloaded data checker and a torrent file content viewer
> Changes:
>  btcheck (1.9-1) unstable; urgency=medium
>  .
>* New upstream release.
>* debian/copyright update.
>* debian/watch updated.
> Checksums-Sha1:
>  13305e356001a990f99ccc7734753031aebded79 1823 btcheck_1.9-1.dsc
>  4db90adf16e35ba5022a77198c46b86879de8b2c 161564 btcheck_1.9.orig.tar.gz
>  6d08a1dfcd69635c1e50b37ab2c2761b2f0ec513 2332 btcheck_1.9-1.debian.tar.xz
>  65b12db7dc840a4e92177e22d8fdf3570c827a6a 14134 btcheck_1.9-1_amd64.deb
> Checksums-Sha256:
>  e756a8cedf54595903572c48d71244b0eb66492ceed1cc63dd6cf5851d15da55 1823 
> btcheck_1.9-1.dsc
>  fb6a3a5a8e4dc41be48c316b8b9406a5a85119bf7e693fb81bf4afd6194cdfd2 161564 
> btcheck_1.9.orig.tar.gz
>  94e6a0ccc46e2c1a038028085fe63894d3bc03876745aa4235b59a3cb27fd456 2332 
> btcheck_1.9-1.debian.tar.xz
>  46a76dffe905af57426d99c007a2e88679618797e71fe28dc0095d1f5e568f41 14134 
> btcheck_1.9-1_amd64.deb
> Files:
>  003339c64c08d5ba7a204e02d0004864 1823 utils optional btcheck_1.9-1.dsc
>  7c150a3c10a7aeb12b749c3b6bff853f 161564 utils optional 
> btcheck_1.9.orig.tar.gz
>  66cf3fe81f0ea249b2214501efb48755 2332 utils optional 
> btcheck_1.9-1.debian.tar.xz
>  2ea3b61080cb1c3c1205e9a42688f8c3 14134 utils optional btcheck_1.9-1_amd64.deb
>
>
>
> Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#793091: src:checkbox-ng: maintainer address bounces

[Ansgar Burchardt]

Source: checkbox-ng
Source-Version: 0.18-2
Tags: sid
Severity: serious
X-Debbugs-Cc: Zygmunt Krynicki , 


The maintainer address for src:checkbox-ng bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   checkbox-...@lists.launchpad.net
> SMTP error from remote mail server after RCPT 
> TO::
> host polevik.canonical.com [91.189.95.64]: 550 unknown user
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
[...]
> From: Debian FTP Masters 
> To: Checkbox Developers , Zygmunt Krynicki 
> ,  
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: checkbox-ng
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: checkbox-ng_0.18-2_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Thu, 09 Jul 2015 18:48:58 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Thu, 09 Jul 2015 19:58:33 +0200
> Source: checkbox-ng
> Binary: checkbox-ng checkbox-ng-service python3-checkbox-ng 
> python3-checkbox-ng-doc
> Architecture: source all
> Version: 0.18-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Checkbox Developers 
> Changed-By: Zygmunt Krynicki 
> Description:
>  checkbox-ng - PlainBox based test runner
>  checkbox-ng-service - CheckBox D-Bus service
>  python3-checkbox-ng - PlainBox based test runner (Python 3 library)
>  python3-checkbox-ng-doc - PlainBox based test runner (documentation)
> Changes:
>  checkbox-ng (0.18-2) unstable; urgency=medium
>  .
>* Add fix-tests-on-python35 patch to use inspect.Signature.from_callable
>  instead of deprecated from_function in Python >= 3.5 (LP: #1473093)
> Checksums-Sha1:
>  f9e45c39b4922b13b6c9534e4f95d17c2c4e48d9 2482 checkbox-ng_0.18-2.dsc
>  8ace1d7d4748373d815d87e8fae296176d726c30 8072 
> checkbox-ng_0.18-2.debian.tar.xz
>  5211ff39255add5cc5885c321a46e9fdccb924a9 4278 
> checkbox-ng-service_0.18-2_all.deb
>  e639e1222d04dc490003c6ebe29e892b0b434751 17290 checkbox-ng_0.18-2_all.deb
>  5c0270cb1668a24a183c0623be8053d11e06b4c3 40736 
> python3-checkbox-ng-doc_0.18-2_all.deb
>  39ed2d6f55f529b27df63c25433d19eab13a695a 50676 
> python3-checkbox-ng_0.18-2_all.deb
> Checksums-Sha256:
>  a8770d60c56a087261b9a4394f21c8148f6766bf5a33983bbe12e40663b41423 2482 
> checkbox-ng_0.18-2.dsc
>  67c3c028cd6ae3a9316683701fedcb4421320447d9881ed68449955f831840d5 8072 
> checkbox-ng_0.18-2.debian.tar.xz
>  71eb256fa25a0ef5211e56247f8d4e4143bdde8462722f98a37d7a4b48f90ca5 4278 
> checkbox-ng-service_0.18-2_all.deb
>  e75094b3bc757e0ab8e3a2b7d921b302d1d6deedc04e064475958ed0a811b69b 17290 
> checkbox-ng_0.18-2_all.deb
>  d6ee7dbcff18fe7650ae86c440d30a076436cc7b821b0ea26a73356f3e6ed909 40736 
> python3-checkbox-ng-doc_0.18-2_all.deb
>  bfb282bc71fb13fdd8816b16b00d1c55a39c50d604cad957ec7a9b73ddda2ff4 50676 
> python3-checkbox-ng_0.18-2_all.deb
> Files:
>  9ee501577304f2291ee3988314087a39 2482 utils optional checkbox-ng_0.18-2.dsc
>  a84989d8be304fb459a7320e57a6f736 8072 utils optional 
> checkbox-ng_0.18-2.debian.tar.xz
>  10272dbf806dc70913e4f5910e8dbac8 4278 utils optional 
> checkbox-ng-service_0.18-2_all.deb
>  2ed1e32090f2804242540be41cc6fe18 17290 utils optional 
> checkbox-ng_0.18-2_all.deb
>  d2d6245965183e7897f197ca68c76ffd 40736 doc extra 
> python3-checkbox-ng-doc_0.18-2_all.deb
>  9123cf61ddfd5aa1a03159c0bdbf595a 50676 utils optional 
> python3-checkbox-ng_0.18-2_all.deb
>
>
>
> Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#793090: src:ipgrab: maintainer address bounces

[Ansgar Burchardt]

Source: ipgrab
Source-Version: 0.9.10-1
Tags: sid
Severity: serious
X-Debbugs-Cc: Martin Michlmayr 

The maintainer address for ipgrab bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   ebros...@netgarage.org
> SMTP error from remote mail server after RCPT TO::
> host mail.netgarage.org [176.9.4.150]: 550 5.1.1 :
> Recipient address rejected: User unknown in virtual mailbox table
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
[...]
> From: Debian FTP Masters 
> To: Dennis Krzyzaniak , Martin Michlmayr 
> ,  
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: ipgrab
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: ipgrab_0.9.10-1.1_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Thu, 16 Jul 2015 18:19:36 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Thu, 16 Jul 2015 11:04:54 -0400
> Source: ipgrab
> Binary: ipgrab
> Architecture: source amd64
> Version: 0.9.10-1.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Dennis Krzyzaniak 
> Changed-By: Martin Michlmayr 
> Description:
>  ipgrab - tcpdump-like utility that prints detailed header information
> Closes: 739562 777917
> Changes:
>  ipgrab (0.9.10-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Fix build failure with GCC 5.  Patch from Tim Potter. (Closes: #777917)
>* Fix build failure with clang.  Patch from Arthur Marble. (Closes:
>  #739562)
> Checksums-Sha1:
>  be0724d0efbd33c7988b7c87993bbb97a503707a 1683 ipgrab_0.9.10-1.1.dsc
>  0338a725d887b5521f0f19d222f4034b4cc2fd18 5360 ipgrab_0.9.10-1.1.debian.tar.xz
>  6bdda64e591328a01d293712909dbbb39a605d11 82254 ipgrab_0.9.10-1.1_amd64.deb
> Checksums-Sha256:
>  52f18304d9b7a15ef2f7f666308e320289381b9eefed4d67a785ad3b541ac176 1683 
> ipgrab_0.9.10-1.1.dsc
>  0ebb6bade0171faa1d658d97bf31da00536d6529382ffd13ea04e7fb9293f705 5360 
> ipgrab_0.9.10-1.1.debian.tar.xz
>  b0797d6ec228244f86768e45b416e3e8378c190adf83b93b733c16e1779193b2 82254 
> ipgrab_0.9.10-1.1_amd64.deb
> Files:
>  3dd2e264c33483d4cc6779eae8cd62d0 1683 net optional ipgrab_0.9.10-1.1.dsc
>  192a57a8ea634a524ab693df3b1e7a12 5360 net optional 
> ipgrab_0.9.10-1.1.debian.tar.xz
>  e6c7cb8cbe5c07cbc4cc5ae7fa5899f1 82254 net optional 
> ipgrab_0.9.10-1.1_amd64.deb
>
>
>
> Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#793088: src:glipper: maintainer address bounces

[Ansgar Burchardt]

Source: glipper
Source-Version: 2.4-5
Severity: serious
Tags: sid
X-Debbugs-Cc: Andrew Starr-Bochicchio 

The maintainer address for glipper bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   josernestodav...@ubuntu.com
> SMTP error from remote mail server after RCPT 
> TO::
> host mx.canonical.com [91.189.94.145]: 550 5.1.1 
> :
> Recipient address rejected: User unknown in virtual alias table
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
[...]
> From: Debian FTP Masters 
> To: =?utf-8?q?Jos=C3=A9_Ernesto_D=C3=A1vila_Pantoja?= 
> ,  
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: glipper
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: glipper_2.4-5_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Mon, 20 Jul 2015 03:34:37 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Fri, 17 Jul 2015 16:53:57 -0600
> Source: glipper
> Binary: glipper
> Architecture: source all
> Version: 2.4-5
> Distribution: unstable
> Urgency: medium
> Maintainer: José Ernesto Dávila Pantoja 
> Changed-By: José Ernesto Dávila Pantoja 
> Description:
>  glipper- Clipboard manager for GNOME
> Closes: 724599
> Changes:
>  glipper (2.4-5) unstable; urgency=medium
>  .
>* debian/control:
>  - Bump Standards-Version to 3.9.6.
>  - Added dh-python to Build-Depends.
>  .
>[ Thanks Ernesto Domato ]
>* debian/patches:
>  - Update the autostart-only-in-gnome.txt path
>to include the MATE desktop (Closes: #724599).
> Checksums-Sha1:
>  8ed1d12c1db863b0549ffc95eef2da0ede449694 2010 glipper_2.4-5.dsc
>  edb0abdc5c257140d09f8fc295191d575c5349c7 20188 glipper_2.4-5.debian.tar.xz
>  5ec6b6efbaa647d2bb29c0ebd155b1ccf9559f55 50688 glipper_2.4-5_all.deb
> Checksums-Sha256:
>  270962b8e9bd923c1f47d0ce385e49dfdd96ac45b08eb2f92c08f65247dad0b9 2010 
> glipper_2.4-5.dsc
>  e7e740123619790d3f42dacd28f31ecc2ec57033e34f3642994299a49f47c24c 20188 
> glipper_2.4-5.debian.tar.xz
>  016514d83323ef0c5d517c46676241f52140b4393ddadb3e999f8b1d7caa8de6 50688 
> glipper_2.4-5_all.deb
> Files:
>  075709154d170e40e7452c847a3c5f11 2010 utils optional glipper_2.4-5.dsc
>  9938eb69eaf6a42fb94134461cb38d7b 20188 utils optional 
> glipper_2.4-5.debian.tar.xz
>  c8dfcc6ea187538b310e6a682e03ee73 50688 utils optional glipper_2.4-5_all.deb
>
>
>
> Thank you for your contribution to Debian.


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#790561: After upgrading udev from 215-18 to 220-7 or 221-1, the system is unbootable afterwards

[Ansgar Burchardt]

Axel Beckert  writes:
> Michael Biebl wrote:
>> Am 30.06.2015 um 17:52 schrieb Klaus Ethgen:
>> > # CONFIG_FHANDLE is not set
>> 
>> E.g. that one is missing.
>> If you compile your own kernel, you should make sure all requirements
>> listed at [1] are met. I didn't check all other options, but your
>> problem is most likely related to that.
>
> In the past the udev package IIRC checked for such issues in preinst
> and refused to upgrade if it found newly required configurations not
> being present.
>
> Any reason why this hasn't been done in this case?

udev.preinst looks like it tries to do so (check_kernel_features), but
it depends on several factors:

 - /proc/kallsyms needs to be present for the symbols check. This might
   not be enabled on custom kernels.
 - udev must be active

There is even a check for CONFIG_FHANDLE:

- open_by_handle_at(2)  (CONFIG_FHANDLE)

But I wouldn't trust it too much; after all this check is probably not
the most tested part of the package...

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#789544: src:mistune: maintainer address bounces

[Ansgar Burchardt]

Source: mistune
Severity: serious
X-Debbugs-Cc: Julien Puydt , 
python-modules-t...@lists.alioth.debian.org, mity...@debian.org

The maintainer address for src:mistune bounces. Looks like the wrong
domain.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   python-modules-t...@lists.debian.org
> SMTP error from remote mail server after RCPT 
> TO::
> host bendel.debian.org [2001:41b8:202:deb:216:36ff:fe40:4002]:
> 550 5.1.1 :
> Recipient address rejected: User unknown in virtual alias table
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> From: Debian FTP Masters 
> To: Debian Python Modules Team , Julien 
> Puydt ,  
> X-DAK: dak process-policy
> X-Debian: DAK
> X-Debian-Package: mistune
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: mistune_0.6-1_amd64.changes ACCEPTED into unstable, unstable
> Message-Id: 
> Date: Sun, 21 Jun 2015 23:00:17 +
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Wed, 17 Jun 2015 11:25:13 +0200
> Source: mistune
> Binary: python-mistune python3-mistune
> Architecture: source all
> Version: 0.6-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Modules Team 
> Changed-By: Julien Puydt 
> Description:
>  python-mistune - Markdown parser for Python 2
>  python3-mistune - Markdown parser for Python 3
> Closes: 779472
> Changes:
>  mistune (0.6-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #779472)
> Checksums-Sha1:
>  31f91e9b7a96094e5e9fe57fb3605ffb0609dccc 2070 mistune_0.6-1.dsc
>  a29f7a3e584c9874c8a51201bfaad1f091d83665 47026 mistune_0.6.orig.tar.gz
>  c6305f2dcfdcd1d33641e7a1b358a424ec4b06f3 1920 mistune_0.6-1.debian.tar.xz
>  d4e08438d93889b2ad0e9127c86f28ff13ad0bd1 13288 python-mistune_0.6-1_all.deb
>  7721345747f8dc6dd19cb878aa923212abca0d2f 13372 python3-mistune_0.6-1_all.deb
> Checksums-Sha256:
>  dfc8f4f4cf1c3ceda1ad8529cd18ce3ea473a0ed2966bb3c6f4ff37f60941eb6 2070 
> mistune_0.6-1.dsc
>  d54a69365d01bc97412a39c11674a8aae3f333586e91f38895cc1ad818e13dc5 47026 
> mistune_0.6.orig.tar.gz
>  4be4f1ecbd48ce10b03e7cf5d7c0b636674c007dccf7b161cca09340d90752a0 1920 
> mistune_0.6-1.debian.tar.xz
>  ec75a1154ed204de95adfe24ac05e38e9af9a27b2849e34fc1c430ed3ab7191e 13288 
> python-mistune_0.6-1_all.deb
>  e75c9728579422dcbdb597d4e9260758f3f1efcdb8d34b308deefe5bf54dd1a3 13372 
> python3-mistune_0.6-1_all.deb
> Files:
>  954bd566e70395a36ead264fdd5a149c 2070 python optional mistune_0.6-1.dsc
>  9df3a09eeb3440f9fd50b08133fdbf9c 47026 python optional 
> mistune_0.6.orig.tar.gz
>  f362ce841929ba9c5ce95421eefbec61 1920 python optional 
> mistune_0.6-1.debian.tar.xz
>  e5e3d91b3b88d4911654ef0f15ea4eee 13288 python optional 
> python-mistune_0.6-1_all.deb
>  36693be1b2d965128484795249405498 13372 python optional 
> python3-mistune_0.6-1_all.deb
>
>
>
> Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782835: gparted: maintainer address bounces

[Ansgar Burchardt]

Source: gparted
Severity: serious
Tags: sid

The maintainer address for gparted bounces, see below.

Ansgar

mailer-dae...@fiordland.canonical.com (Mail Delivery System) writes:
> This is the mail system at host fiordland.canonical.com.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>The mail system
>
>  (expanded from ): host
> cdptpa-pub-iedge-vip.email.rr.com[107.14.166.70] said: 554 Invalid
> recipient (in reply to RCPT TO command)
>
> Reporting-MTA: dns; fiordland.canonical.com
> X-Postfix-Queue-ID: 3101998
> X-Postfix-Sender: rfc822; envel...@ftp-master.debian.org
> Arrival-Date: Wed, 15 Apr 2015 22:34:02 + (UTC)
>
> Final-Recipient: rfc822; ps...@cfl.rr.com
> Original-Recipient: rfc822;ps...@ubuntu.com
> Action: failed
> Status: 5.0.0
> Remote-MTA: dns; cdptpa-pub-iedge-vip.email.rr.com
> Diagnostic-Code: smtp; 554 Invalid recipient
>
> From: Debian FTP Masters 
> Subject: gparted_0.19.0-2.1_source.changes ACCEPTED into unstable
> To: Phillip Susi , Michael Gilbert ,  
> 
> Date: Wed, 15 Apr 2015 22:33:59 + (2 days, 15 hours, 41 minutes ago)
>
>
>
> Accepted:
>
> Format: 1.8
> Date: Sun, 12 Apr 2015 18:31:55 +
> Source: gparted
> Binary: gparted
> Architecture: source
> Version: 0.19.0-2.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Phillip Susi 
> Changed-By: Michael Gilbert 
> Description:
>  gparted- GNOME partition editor
> Closes: 781716
> Changes:
>  gparted (0.19.0-2.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Apply upstream fix to prevent automounting during partitioning on systems
>  using udisks2 (closes: #781716).
> Checksums-Sha1:
>  2f4cc1d1f81a865f584819d681ffcbe72afb2fc1 2629 gparted_0.19.0-2.1.dsc
>  e56087d236730f0a26affd455b9997f5cc3b9e29 20643 
> gparted_0.19.0-2.1.debian.tar.bz2
> Checksums-Sha256:
>  0922f647d72a4cbc7d78744fda57054836086f5b117ff3eccadf6b30a59d7ed0 2629 
> gparted_0.19.0-2.1.dsc
>  c34d7df3d083d7a3f223ea5c1b0e08bfa219f8765d9360e4d17710d9ac27042a 20643 
> gparted_0.19.0-2.1.debian.tar.bz2
> Files:
>  41d014bed830d546f20262652c3bb8ae 2629 gnome optional gparted_0.19.0-2.1.dsc
>  a0e6a0a498932c6c74ada923cb444832 20643 gnome optional 
> gparted_0.19.0-2.1.debian.tar.bz2
>
>
>
> Thank you for your contribution to Debian.
> --


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782806: sugar-toolkit-0.98: maintainer address bounces

[Ansgar Burchardt]

Source: sugar-toolkit-0.98
Severity: serious
Tags: sid
X-Debbugs-Cc: Jonas Smedegaard 

The maintainer address for sugar-toolkit-0.98 bounces, see below.

Ansgar

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   debian-olpc-de...@lists.alioth.debian.org
> SMTP error from remote mail server after RCPT 
> TO::
> host lists.alioth.debian.org [5.153.231.21]: 550 Unrouteable address
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Debian OLPC , Jonas Smedegaard 
> 
[...]
> Subject: sugar-toolkit-0.98_0.98.1-2_amd64.changes ACCEPTED into experimental
> Message-Id: 
> Date: Sat, 11 Apr 2015 09:35:44 +


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782805: gwhois: maintainer address bounces

[Ansgar Burchardt]

Source: gwhois
Severity: serious
X-Debbugs-Cc: juli...@holzt.de
Tags: sid

The maintainer address for gwhois bounces, see below.

Ansgar

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   deb...@julijane.de
> SMTP error from remote mail server after RCPT TO::
> host julijane.de [144.76.244.226]: 550  Relaying 
> denied (#5.7.1)
>
> -- This is a copy of the message, including all the headers. --
[...]
> To: Juliane Holzt ,  
[...]
> Subject: gwhois_20120626-1_amd64.changes ACCEPTED into unstable
> Message-Id: 
> Date: Fri, 17 Apr 2015 22:18:58 +


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781595: xdeb: disables apt's signature checks

[Ansgar Burchardt]

Package: src:xdeb
Version: 0.6.6
Severity: grave
Tags: security

According to xdeb's documentation it uses apt to download source
packages and defaults to using the system's sources.list, that is
usually remote repositories.

However xdeb disables apt's signature checking:

+---
| apt_pkg.config.set('APT::Get::AllowUnauthenticated', str(True))
+---[ http://sources.debian.net/src/xdeb/0.6.6/aptutils.py/?hl=159#L159 ]

I assume (but did not verify) that this means xdeb will not complain
about a compromised remote repository and build potentially malicous
packages.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781594: pybit: disables apt's signature checking (and uses remote repository)

[Ansgar Burchardt]

Package: src:pybit
Version: 1.0.0-2.1
Severity: grave
Tags: security

pybit disables apt's signature checks when retrieving source packages:

+---
| url = "deb-src http://cdn.debian.net/debian %s main " % 
buildreq.get_suite()
| os.write(src_list, url)
| cfg_str = "-o Apt::Get::AllowUnauthenticated=true -o Dir=%s -o 
Dir::State=%s -o Dir::Etc::SourceList=%s/sources.list -o Dir::Cache=%s" % \
+---[ 
http://sources.debian.net/src/pybit/1.0.0-2.1/pybitclient/apt.py/?hl=50#L50 ]

As can be seen, it also includes a remote repository in the
sources.list that could be target of a MitM attack.

I assume (but did not verify) that pybit then proceeds to build the
source package, possibly executing arbitrary code in case the
connection to cdn.debian.net was compromised.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659015: apt-build disables apt's signature verification

[Ansgar Burchardt]

Axel Beckert  writes:
> I've though observed two possibly minor issues with it:
>
> * An existing /etc/apt/sources.list.d/apt-build.list is not updated to
>   add "[trusted=yes]".

Could probably be added in postinst (apt-build.list is not a conffile),
e.g. something like

  sed -i 's/^deb file:/deb [trusted=yes] file:/'

or something more strict to make sure it doesn't touch other
repositories.

> * Upon purge and (re)installation, I had the "deb" line twice in
>   /etc/apt/sources.list.d/apt-build.list and it's not clear to me why.

The filename is generated differently in postinst and postrm:

+---
|   eval $(apt-config shell sourceslist Dir::Etc::sourcelist/f)
|   eval $(apt-config shell sourcesparts Dir::Etc::sourceparts/d)
|   aptbuildsource="$sourcesparts"apt-build.list
+---[ postinst ]

+---
|   eval $(apt-config shell etcdir Dir::Etc)
|   eval $(apt-config shell sourceslist Dir::Etc::sourcelist)
|   eval $(apt-config shell sourcesparts Dir::Etc::sourceparts)
|   sourceslist=/"$etcdir""$sourceslist"
|   sourcesparts=/"$etcdir""$sourcesparts"
|   aptbuildsource="$sourcesparts"/apt-build.list
+---[ postrm ]

> I've not yet done much testing, so any feedback is welcome. I'll
> definitely do some more testing before uploading that fix.

I can't give to much feedback as I don't use apt-build myself. Just
noticed the thread on -security@.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781075: sbuild: Breaks d-i build by assuming it is a deb

[Ansgar Burchardt]

Hi,

On 03/24/2015 10:12 AM, Aurelien Jarno wrote:
> There have been other changes committed to this branch, so we should
> decide if they are jessie material or not. I have added Ansgar in Cc for
> that.

There are two other one-line changes:

- sbuild-createchroot: set profile=sbuild also for tar-based chroots
  https://bugs.debian.org/769289

  This makes tar-based chroots consistent with directory-based chroots.
  Reportedly not setting profile=sbuild means /dev/shm is not mounted,
  causing build failures.

  Should be included.

- sbuild-dumpconfig: sort keys of dumped hashes

  This just sorts options in the documentation (during build). Harmless
  to include, but makes the build reproducible. Has no effect at
  runtime.

  I don't think it's worth reverting this.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org