Bug#863470: ftp.debian.org: security sync must not exclude .buildinfo

[Ansgar Burchardt]

Rene Engelhard writes:
> So if I get this right any package having .buildinfo will fail at this stage.
>
> Which will get problematic in stretch security updates since anything built
> inside stretch will not only have the source but also the binary .buildinfo's.
>
> I think  this must be (somehow) fixed before stretch releases to be able
> to do security updates (well, sync them into s-p-u and not get lost and 
> needing
> manual recovery).

My current plan is to make dak handle .buildinfo files like .changes in
policy queues.  That is, store them in dists/${suite} and copy them into
the Process-Policy::CopyDir directory when the upload is accepted.

Maybe only copy them into dists/${suite} when CopyDir is set so this
only happens on sec-master and not for p-u on ftp-master.

Ansgar

Bug#864004: dune-grid: FTBFS, and cruft package, on hurd-i386

[Ansgar Burchardt]

clone 864004 -1 -2 -3 -4
retitle -1 RM: dune-grid-glue [hurd-i386] -- RoM; Build-Depends on package not 
available on hurd-i386
retitle -2 RM: dune-pdelab [hurd-i386] -- RoM; Build-Depends on package not 
available on hurd-i386
retitle -3 RM: dune-geometry [hurd-i386] -- RoM; Build-Depends on package not 
available on hurd-i386
retitle -4 RM: dune-common [hurd-i386] -- RoM; FTBFS, MPI does not work on 
hurd-i386
thanks

Ralf Treinen writes:
>> MPI does not work on hurd-i386.  I don't have time to fix MPI, so
>> removal it is.
>
> Thanks! The situation seems to be the same with
>
> libdune-grid-glue-2.3.0 (from source dune-grid-glue)
> libdune-pdelab-2.0.0 (from source dune-pdelab)
>
> can you also ask for removal of these two on hurd-i386?

Sure.

Ansgar

Bug#864004: dune-grid: FTBFS, and cruft package, on hurd-i386

[Ansgar Burchardt]

retitle 864004 RM: dune-grid [hurd-i386] -- RoM; FTBFS, MPI not working on 
hurd-i386
reassign 864004 ftp.debian.org

Ralf Treinen writes:
> dune-grid fails to build on hurd-i386 (unsatisfiable build-dependency on 
> libdune-common-dev), but did build in the past.
>
> As a consequence, we now have on hurd-i386 a crufty binary package
> libdune-grid-2.3.1, which is not installable. In case you decide not
> to fix the FTBFS, please consider asking for removal of
> libdune-grid-2.3.1:hurd-i386.

MPI does not work on hurd-i386.  I don't have time to fix MPI, so
removal it is.

Ansgar

Bug#863816: RM: ksh/93u+20120801-3.1

[Ansgar Burchardt]

On Wed, 31 May 2017 14:28:25 +0100 "Adam D. Barratt" wrote:
> On 2017-05-31 14:17, Christoph Martin wrote:
> > Please remove the recent non-maintainer upload from me of ksh with the
> > version 93u+20120801-3.1 . It has the wrong version number since the
> > last released version was 93u+20120801-2.
[...]
> > As soon as this version is removed I'll do a NMU with version -2.1
> 
> You can't make version numbers of published packages go backwards,
> so that would either need an epoch or a "really"-style version
> number.

Though there really is no need to reupload the package just to correct
the version.  Just ignore that one version number was skipped.

Ansgar

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#863718: libsbuild-perl: please do not recommend a mta

[Ansgar Burchardt]

Package: libsbuild-perl
Version: 0.73.0-4
Severity: normal

libsbuild-perl Recommends: exim4 | mail-transport-agent

This seems excessive as I suspect most people use sbuild to build
packages locally and don't need it to send mail.  Please consider
downgrading it to a Suggests.

The dependency should probably also be moved to the application that
will actually send mails (either sbuild or buildd) to be easier to
discover.

Ansgar

Bug#863348: dput: please use ftp.security.upload.debian.org for security uploads

[Ansgar Burchardt]

Package: dput
Version: 0.9.6.4
Severity: important

Some time ago we moved the upload queues away from ftp-master.d.o to
ftp.upload.d.o.  This allowed us to no longer run ftpd directly on
ftp-master.

The same will hopefully happen to security-master: eventually
security-master will no longer run a ftpd, but uploads will go via a
separate host.  For this to work, we will need tools to upload to
ftp.security.upload.debian.org (currently an alias for
security-master).

So please update the default dput.cf to upload security uploads to
ftp.security.upload.debian.org instead of directory to
security-master.debian.org.

Ansgar

Bug#863349: dput-ng: please use ftp.security.upload.debian.org for security uploads

[Ansgar Burchardt]

Package: dput-ng
Version: 1.8
Severity: important

Some time ago we moved the upload queues away from ftp-master.d.o to
ftp.upload.d.o.  This allowed us to no longer run ftpd directly on
ftp-master.

The same will hopefully happen to security-master: eventually
security-master will no longer run a ftpd, but uploads will go via a
separate host.  For this to work, we will need tools to upload to
ftp.security.upload.debian.org (currently an alias for
security-master).

So please update the default skel/profiles/security-master.json to
upload security uploads to ftp.security.upload.debian.org instead of
directory to security-master.debian.org.

Ansgar

Bug#863350: dupload: please use ftp.security.upload.debian.org for security uploads

[Ansgar Burchardt]

Package: dupload
Version: 2.8.2

Some time ago we moved the upload queues away from ftp-master.d.o to
ftp.upload.d.o.  This allowed us to no longer run ftpd directly on
ftp-master.

The same will hopefully happen to security-master: eventually
security-master will no longer run a ftpd, but uploads will go via a
separate host.  For this to work, we will need tools to upload to
ftp.security.upload.debian.org (currently an alias for
security-master).

So please update the default dupload.conf to upload security uploads to
ftp.security.upload.debian.org instead of directly to
security-master.debian.org.

Ansgar

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

Bug#863303: debian-archive-keyring: please remove old 6.0/squeeze key

[Ansgar Burchardt]

Package: debian-archive-keyring
Version: 2014.3

Please remove the old "6.0/squeeze" automatic signing key and the
squeeze release key from the active keys in
/usr/share/keyrings/debian-archive-keyring.gpg:

+---
| pub   rsa4096/0x64481591B98321F9 2010-08-07 [SC] [expires: 2017-08-05]
|   Key fingerprint = 0E4E DE2C 7F3E 1FC0 D033  800E 6448 1591 B983 21F9
| uid   Squeeze Stable Release Key 
|
| pub   rsa4096/0xAED4B06F473041FA 2010-08-27 [SC] [expires: 2018-03-05]
|   Key fingerprint = 9FED 2BCB DCD2 9CDF 7626  78CB AED4 B06F 4730 41FA
| uid   Debian Archive Automatic Signing Key (6.0/squeeze) 

+---

Ansgar

Bug#859867: [buildd-tools-devel] Bug#859867: Bug#859867: Please add a package which automatically configures sbuild for Debian packaging

[Ansgar Burchardt]

Hi,

Michael Stapelberg  writes:
> Doing it in a script is one more step. The point of this endavour is to
> make the setup as simple as possible.

I think creating a chroot in postinst is not good.  Mostly because
maintainer scripts should never fail, but this is too likely to fail
(for example when there are network connection issues).

Maintainer scripts must also *never* write to user home
directories. Besides security issues this will also make maintainer
scripts just fail.

Just providing a script in the existing sbuild package to more easily
setup a chroot with a standard configuration seems to be the better
option to me.

Ansgar

Bug#862073: ftpmaster.debian.org: Please POST .buildinfo files to buildinfo.debian.net

[Ansgar Burchardt]

Hi,

Chris Lamb writes:
> Attached is a patch submit .buildinfo files to buildinfo.debian.net,
> our experimental system for centrally storing .buildinfo files for
> analysis, retrieval, etc.  We almost have 2,000,000 files there.
>
> This patch supplements the existing filesystem archiving and simply
> performs a POST on the .buildinfo file itself.

I don't think dak should push things to external services while
processing uploads: the code runs as the privileged user (and ideally
doesn't talk to the external world) and we still need a second point
where .buildinfo files are pushed (in case the PUT fails for any
reason).

So we could implement only the second point and push .buildinfo files
asynchronous and as an unprivileged user.

Ansgar

Bug#862659: libparmetis-dev: misses dependency on libmetis-dev

[Ansgar Burchardt]

Package: libparmetis-dev
Version: 4.0.3-4+b4
Severity: important

/usr/include/parmetis.h has `#include `, but the
libparmetis-dev binary package has no dependency on a package
providing that include (libmetis-dev).

Ansgar

-- System Information:
Debian Release: 9.0
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages libparmetis-dev depends on:
ii  libparmetis4.0   4.0.3-4+b4
ii  mpi-default-dev  1.8

libparmetis-dev recommends no packages.

Versions of packages libparmetis-dev suggests:
pn  parmetis-doc  

-- no debconf information

Bug#858163: unblock: gitlab/8.13.11+dfsg-6

[Ansgar Burchardt]

Hi,

> You probably want something like:
>
> """
>   if su ${gitlab_user} -c 'psql gitlab_production -c ""'; then
>  su postgres -c "dropdb gitlab_production"
>   fi
> """

I believe maintainer scripts (and various other parts) should use
`runuser` instead of `su`.  It does not open PAM sessions which seems
to sometimes cause problems.

`/sbin/runuser` is already available in Jessie, so there should be no
issues with using it.

(Maybe one should add something to Policy about `runuser`?)

Ansgar

Bug#761348: ftp.debian.org: need machine-readable metadata about suites & repositories

[Ansgar Burchardt]

Hi,

On Fri, 2017-04-21 at 09:28 +0200, Michael Stapelberg wrote:
> pabs, what’s the current status on this? AFAICT, you mentioned you
> wanted to come up with a spec on the RepositoryFormat wiki page. I
> don’t
> see that on the RepositoryFormat wiki page yet.
> 
> Is there any way to help?
> 
> I’m also interested in this issue due to hardcoding in manpages.d.o,
> which I’ve now described on
> https://wiki.debian.org/SuitesAndReposExtension#manpages.debian.org

While a file in the archive itself will also be useful, some
information is also available via api.ftp-master.d.o.  For example some
information about suites:

  curl https://api.ftp-master.debian.org/suites

If people need more information avialable, we can add more bits.  

Some documentation is available on
https://ftp-master.debian.org/epydoc/dakweb.queries-module.html

Ansgar

Bug#859084: unblock: win32-loader/0.8.2

[Ansgar Burchardt]

Didier 'OdyX' Raboud  writes:
> ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing

Done.

Ansgar

Bug#856845: piuparts.debian.org: jessie2bpo has >400 packages in dependency-failed-testing status

[Ansgar Burchardt]

On Tue, 2017-03-21 at 16:45 +, Holger Levsen wrote:
> On Sun, Mar 19, 2017 at 05:31:16PM +0100, Michael Biebl wrote:
> > both systemd and udev need to be upgraded in lockstep:
> > 
> > a/ udev has Breaks/Replaces systemd (<< 224-2)
> > b/ systemd has a Breaks/Replaces udev (<< 228-5)
> > 
> > Forcing the upgrade of only one of the two will fail.
> 
> if this is the case, then I think the packages metadata *must*
> express this,
> probably by depending on the appropriate udev/systemd versions.
> 
> you cannot expect users to do the right thing by themselves ;-)

What should be wrong about the dependencies?

Note that you ask apt explicitly to break stuff (in the logs I see "
--force-yes" which is documented as potentially breaking systems; I
hope users don't use that).

Ansgar

Bug#855707: at: Runit integration

[Ansgar Burchardt]

Hi,

besides the patch containing unrelated changes, having an extra package
per service management system seems very far from ideal to me.  It was
possible for all of sysvinit/upstart/systemd to be handled by the same
package.  Why can't runit do this?

And having a separate package with just a file containing

  #!/bin/sh
  exec atd -f -d

seems way overkill...  See also the discussions on -devel@ about tiny
packages (for Javascript stuff, but that comes at least from upstream
and is not a Debian invention).

Ansgar

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#760414: [ola] Some sources are not included in your package

[Ansgar Burchardt]

severity 760414 serious
thanks

Wouter Verhelst writes:
> First of all, I wouldn't call minified javascript a "binary". I agree
> that it's not source, but that doesn't imply it's a binary (that is
> orthogonal to my point, but I want to point that out).

We misuse "binary" a bit in this context to refer to any form that is
not the preferred form of modification (source).  In some cases the
source might be "binary" too after all (for example images).

> Obviously what is in main needs to be DFSG-free; that implies it needs
> to have source available.

Yes, and source packages are distributed as part of "main".  So
everything inside a source package needs to have source provided as
well.  See also Scott's mail to d-d-a@ linked earlier.

> But nowhere in the DFSG do I see a strict requirement that the said
> source is part of the same source package. The fact that we have
> "Built-Using" would suggest the same; it shows that there are other
> cases where a source package does not contain the full source to a
> program.

Even in the case of "Built-Using" the source package should contain
sources for everything in the source package.  Only the corresponding
source for generated binary package is then more than just the implicit
default.

However there is no "Built-Using" for source packages.

> 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).

In addition:

> - The relevant libjs-* packages are what is in fact being used by the
>   ola package.

That doesn't seem to be the case.  ola doesn't (build-)depend on them,
but includes minified JS:

+---
| % dpkg-deb -c ola_0.10.3-1_amd64.deb | grep .min.js
| -rw-r--r-- root/root 12705 2017-01-18 18:25 
./usr/share/olad/www/new/js/app.min.js
| -rw-r--r-- root/root 15768 2017-01-18 18:25 
./usr/share/olad/www/new/js/app.min.js.map
| -rw-r--r-- root/root125551 2017-01-18 18:25 
./usr/share/olad/www/new/libs/angular/js/angular.min.js
| -rw-r--r-- root/root  4464 2017-01-18 18:25 
./usr/share/olad/www/new/libs/angular-route/js/angular-route.min.js
| -rw-r--r-- root/root 35452 2017-01-18 18:25 
./usr/share/olad/www/new/libs/bootstrap/js/bootstrap.min.js
| -rw-r--r-- root/root 84320 2017-01-18 18:25 
./usr/share/olad/www/new/libs/jquery/js/jquery.min.js
+---

Ansgar

Bug#853254: ftp.debian.org: please create stretch-backports suite

[Ansgar Burchardt]

Niels Thykier writes:
>> In preparation of the freeze, it would be nice if the stretch-backports
>> could be populated, with the same architectures as stretch.  If
>> possible, the new suite should not accept uploads until the actual
>> stretch release.
>
> Are there any news on this?  Currently, the DSA are waiting for this
> before starting their upgrade tests to stretch.

stretch-backports and jessie-backports-sloppy should appear on the
mirrors with the next dinstall run. (-sloppy at the same time as it is
the same work after all.)

They should reject uploads for now and the build queues on incoming.d.o
are not setup yet either.

Ansgar

Bug#852002: override: libncurses5:libs/important

[Ansgar Burchardt]

Control: retitle -1 override: libncurses5:libs/optional

Andreas Henriksson writes:
> On Fri, Jan 20, 2017 at 06:05:15PM +0100, Sven Joachim wrote:
> [...]
>> Please downgrade the priority so that libncurses5 does not get installed
>> in minimal chroots anymore and can be autoremoved in existing chroots by
>> apt.
>
> Subject says "override: libncurses5:libs/important" but please
> consider downgrading it to even lower than important!
>
> The important priority will pull it into a regular debootstrap.
> It's a library, why now have dependencies just pull it in if needed?!
>
> (Yes, sure there might be some important package depending on it
> and policy says yada, yada... but sooner or later policy
> will get fixed -> #758234 )

I agree that we should try to downgrade libraries to Priority: optional
if possible.

I would still like an ACK from the d-i team (X-Debbugs-Cc'ed).

Ansgar

Bug#855151: tasksel: should not be Priority: important

[Ansgar Burchardt]

Package: tasksel
Version: 3.39

tasksel is currently at Priority: important and thus installed in every
installation, including chroots installed via debootstrap.  It doesn't
seem a useful package to install in chroots though.

It would be nice if d-i would install tasksel (and maybe remove it at
the end of the installation again?) so the priority of the tasksel and
tasksel-data packages could be downgraded.

Ansgar

Bug#855150: override: blends-tasks: misc/optional

[Ansgar Burchardt]

Package: ftp.debian.org

blends-tasks is not used by d-i currently so there is no need to have it
included in the default install.

See also the discussion in #846002.

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#848574: openmpi: frequent segfault in linker on mips64el

[Ansgar Burchardt]

severity 848574 grave
thanks

This should probably be release-critical as mips64el is a release
architecture.

It was also mentioned in #-devel today that this causes build failures
in other packages, for example [1].

Ansgar

  [1] 

Bug#851400: systemd: Going into suspend yust after waking up

[Ansgar Burchardt]

Michael Fritscher writes:
> The problem is that if the system is on battery both on going to
> suspend and waking up, in 90% of the cases the system goes into
> suspend immediately again (few seconds). On the second try it works.
> I didn't set the system to go into suspend after some time...

Do you have acpid installed?  In that case both logind and acpid might
handle the event, see [1].

Ansgar

  [1] 

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Ansgar Burchardt]

Philip Hands writes:
> I stumbled across 'proot' while looking into the background for this,
> which seems to be able to provide the effect of a bind mount without
> needing root privilege, and would presumably deal with Ian's original
> problem quite nicely.

If you enable unprivileged user namespaces (the upstream kernel default;
disabled by a Debian patch if I remember correctly), you can just use
`unshare` and `mount --bind` on Linux:

  # echo 1 > /proc/sys/kernel/unprivileged_userns_clone

  $ unshare -r -m /bin/sh -c 'mount --bind /usr/bin/gpg /usr/bin/true; 
/usr/bin/true --version'
  gpg (GnuPG) 2.1.17
  [...]

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#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Ansgar Burchardt]

Control: retitle -1 release-notes: recommend installing usrmerge on upgrade to 
buster
Control: tag -1 - stretch + buster

The change in debootstrap to enable merged-/usr has been temporarily
reverted due to issues reported.  As it was only fixed quite late, we
won't re-enable merged-/usr for stretch.

As my recommendation to install usrmerge tries to keep newly-installed
and upgraded systems more in sync, I believe we should delay
recommending so until debootstrap goes back to merged-/usr, that is
until buster.

Ansgar

Bug#849903: [py3porters-devel] Python 2 in the default installation -- progress made!

[Ansgar Burchardt]

Daniel Kahn Gillmor writes:
> On Thu 2016-12-29 23:41:39 -0500, Stuart Prescott wrote:
>> one of the objectives for stretch was to reduce the number of Python 2
>> packages that are installed in common scenarios, instead having the
>> Python 3 stack take over. The "standard task" within tasksel is a
>> reasonable place to look.¹
>  [...]
>> python-gpg
>> python3-gpg
>
> fwiw, python-gpg and python3-gpg should not be Priority: standard, and
> they are indicated as such in the source packages.
>
>https://packages.qa.debian.org/g/gpgme1.0.html
>
> indicates that they're marked that way due to override files, but i
> don't think there'd be any objection from myself or any of the other
> pkg-gnupg-maint team (cc'ed here) if those overrides were removed.

There was an open bug about changing the overrides (#849903) and I just
set all packages built from gpgme1.0 to "Priority: optional".

I don't think there is any reason for the lib*-dev packages to be at
Priority: extra?

Ansgar

Bug#849287: RM: trilinos [mips64el] -- ROM; FTBFS

[Ansgar Burchardt]

Control: reopen -1
Control: retitle -1 RM: trilinos [mips64el] -- RoM; FTBFS

Either the script generating `removals.html` should figure this out or
`dak rm -B -a ${arch} ${source}` will remove all binaries of ${source}
built for ${arch}.

I think using the latter is much more readable than very long explicit
lists of packages :-)

Ansgar

Bug#849442: RM: dune-common [hurd-i386 kfreebsd-amd64 kfreebsd-i386 mips64el] -- RoM; OpenMPI broken on mips64el (#848574) and others

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: rm
Control: clone -1 -2 -3 -4 -5 -6
Control: retitle -2 RM: dune-geometry [mips64el kfreebsd-amd64 kfreebsd-i386 
mips64el] -- RoM; OpenMPI broken on mips64el (#848574) and others
Control: retitle -3 RM: dune-grid [mips64el kfreebsd-amd64 kfreebsd-i386 
mips64el] -- RoM; OpenMPI broken on mips64el (#848574) and others
Control: retitle -4 RM: dune-grid-glue [mips64el kfreebsd-amd64 kfreebsd-i386 
mips64el] -- RoM; OpenMPI broken on mips64el (#848574) and others
Control: retitle -5 RM: dune-pdelab [mips64el kfreebsd-amd64 kfreebsd-i386 
mips64el] -- RoM; OpenMPI broken on mips64el (#848574) and others
Control: retitle -6 RM: dune-uggrid [mips64el kfreebsd-amd64 kfreebsd-i386 
mips64el] -- RoM; OpenMPI broken on mips64el (#848574) and others

Please remove dune-* from mips64el.  OpenMPI is currently unusable on
mips64el, even trivial programs using it segfault very often in the
runtime linker (see #848574).

OpenMPI also does not work on kfreebsd (#846635), though that is marked
pending.  It also failed on Hurd which looked similar to the kfreebsd
issue.

Ansgar

Bug#849251: allow using sftp for uploads to ftp.debian.org

[Ansgar Burchardt]

"Adam D. Barratt" writes:
> On Sat, 2016-12-24 at 12:34 +0530, Pirate Praveen wrote:
>> package: ftp.debian.org
>> 
>> Currently I cannot upload big packages from my internet connection (its
>> reasonably good broadband in my area/India) because dput times out (its
>> a mess to clean that). I have to scp every time to a server and dput
>> from there because scp is more resilient to connection breaks.
>> 
>> If dput allowed using sftp, I could avoid this extra step. Please
>> consider adding sftp option.
>> 
>
> dput isn't maintained by ftp-master (and if it were it wouldn't be under
> the ftp.d.o meta-package); reassigning.
>
> (I imagine you simply want to use the "scp" method in dput.cf, but I'll
> leave that to the maintainers in case I'm missing something.)

dput seems to already support rsync which is probably a good choice when
one has connection problems as it should support continuing the upload.

I haven't used the `rsync` method so far though and there doesn't seem
to be a ready-to-use entry in the default dput.cf.

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#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#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#845254: unblock: win32-loader/0.8.0

[Ansgar Burchardt]

Didier 'OdyX' Raboud writes:
> Le lundi, 21 novembre 2016, 23.30:52 h CET Cyril Brulebois a écrit :
>> so feel free to let this package get into testing when it's copied over
>> by ftpmasters.
>
> Le lundi, 21 novembre 2016, 21.09:46 h CET Didier 'OdyX' Raboud a écrit :
>> 0.8.0 is long overdue in stretch, please let it migrate. ftpmaster: please
>> copy debian/tools/win32-loader/unstable into …/testing
>
> ftpmasters: ping ?

tools/win32-loader/testing/ now has win32-loader from Apr 21 2016. Sorry
for forgetting about this :/

Ansgar

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#848648: RM: python-ffc [amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x] -- RoQA; now an arch:all package

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: rm

Drew Parsons writes:
> ffc 2016.2.0-1 was uploaded to unstable nearly a week ago. 
> But python-ffc is still not showing up after an apt-get update, it's
> still stuck at 2016.1.0-1.
>
> We need the ffc update so we can complete the dolfin update to
> 2016.2.0.

When packages switch from arch-dep to arch-indep (arch: all), the old
binaries do not get removed automatically (yet) and need a manual
removal request.

The new arch:all binary package also gets "hidden": dak tries to keep
arch-indep and arch-dep packages in the exported view (Packages index)
at the same version to keep packages installable.  The arch-dep packages
often have a `Depends: ${arch-indep} (= ${source:Version})` relationship
that apt would not be able to satisfy otherwise as apt only considers
the newest version by default.

Ansgar

Bug#848607: nmu: dune-grid-glue_2.5.0~20161206g666200e-2, dune-pdelab_2.5.0~20161204gdb53a76-3

[Ansgar Burchardt]

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

Please schedule binNMUs for dune-grid-glue and dune-pdelab to have
them rebuilt against dune-grid 2.5.0-1.

  nmu dune-grid-glue_2.5.0~20161206g666200e-2 . ANY . unstable . -m "Rebuild 
against dune-grid 2.5.0."
  nmu dune-pdelab_2.5.0~20161204gdb53a76-3 . ANY . unstable . -m "Rebuild 
against dune-grid 2.5.0."

As issues with openmpi on mips64el (#848574) currently prevent
building of dune-common and dune-grid 2.5.0, a dep-wait would be nice
so the packages might get rebuilt later.

  dw dune-grid-glue_2.5.0~20161206g666200e-2 . ANY . unstable . -m 
"libdune-grid-dev (>= 2.5.0)"
  dw dune-pdelab_2.5.0~20161204gdb53a76-3 . ANY . unstable . -m 
"libdune-grid-dev (>= 2.5.0)"

Ansgar

Bug#848574: openmpi: frequent segfault in linker on mips64el

[Ansgar Burchardt]

Package: libopenmpi-dev
Version: 2.0.2~git.20161225-8
Severity: important

[ CC'ed debian-mips@ as a segfault in the linker might not be a bug in MPI ]

OpenMPI crashed frequenly in the runtime linker on mips64el, even for a
trivial program calling just MPI_Init and MPI_Finalize:

+---
| #include 
|
| int main(int argc, char** argv)
| {
|   MPI_Init(, );
|   MPI_Finalize();
|   return 0;
| }
+---[ test.cc ]

After building with `mpic++ -o test test.cc`, I often get the following
backtrace from the core file:

+---
| Core was generated by `./test'.
| Program terminated with signal SIGSEGV, Segmentation fault.
| #0  elf_machine_runtime_link_map (gpreg=, 
stub_pc=1099310712688)
| at ../sysdeps/mips/dl-trampoline.c:84
| 84../sysdeps/mips/dl-trampoline.c: No such file or directory.
| [Current thread is 1 (LWP 2837)]
| (gdb) bt
| #0  elf_machine_runtime_link_map (gpreg=, 
stub_pc=1099310712688)
| at ../sysdeps/mips/dl-trampoline.c:84
| #1  __dl_runtime_resolve (sym_index=151, return_address=, 
old_gpreg=, 
| stub_pc=1099310712688) at ../sysdeps/mips/dl-trampoline.c:125
| #2  0x00fff5e341ac in _dl_runtime_resolve () from /lib64/ld.so.1
| Backtrace stopped: frame did not save the PC
+---[ backtrace from `gdb ./test core` ]

I noticed as src:dune-common/2.5.0-1 failed on mips64el even though the last
upload build sucessfully.

Ansgar

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: mips64el (mips64)

Kernel: Linux 4.7.0-0.bpo.1-octeon (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libopenmpi-dev depends on:
ii  libc6   2.24-8
ii  libhwloc-dev1.11.5-1
ii  libhwloc5   1.11.5-1
ii  libibverbs-dev  1.2.1-2
ii  libopenmpi2 2.0.2~git.20161225-8
ii  openmpi-common  2.0.2~git.20161225-8

libopenmpi-dev recommends no packages.

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#796548: closing 796548

[Ansgar Burchardt]

Control: reopen -1
Control: found -1 2.1

On Wed, 2016-12-14 at 03:40 +, Wookey wrote:
> close 796548 2.0.4

emdebian-archive-keyring 2.1 still has "Priority: important" in
d/control.  (Not in the Packages index though as the archive software
overrides the provided priority.)

Ansgar

Bug#522163: standard for disabling daemons in /etc/default

[Ansgar Burchardt]

I agree that we should *not* encourage using some `ENABLE={yes,no}` in
/etc/default/* to disable a service.  This should be done via the
regular tools (update-rc.d; systemctl disable; ...).

So +1 for closing this bug as wontfix.

Ansgar

Bug#847315: apt-cacher: doesn't allow to download upstream signatures (*.asc)

[Ansgar Burchardt]

Mark Hindley writes:
> On Wed, Dec 07, 2016 at 10:06:52AM +0100, Ansgar Burchardt wrote:
>> apt-cacher doesn't allow to download upstream signatures which are
>> part of the source package.  For example, stunnel4 3:5.38-1 from unstable:
>
> Thanks for this.
>
> Could you add this configuration fragment to a file in /etc/apt-cacher/conf.d
> (all on one line, I can't seem to prevent my mailer from wrapping it)
>
> package_files_regexp =
> (?:(?:^|/)[a-z0-9][-+.a-z0-9]*_(?:\d+:)?[0-9][-+:.~a-zA-Z0-9]*(?:_(?:avr32|amd64|alpha|arm|arm64|armel|armhf|hppa|hurd-i386|i386|ia64|kfreebsd-amd64|kfreebsd-i386|m32r|m68k|mips|mipsel|netbsd-alpha|netbsd-i386|powerpc|powerpcspe|ppc64|s390|s390x|sh4|
> sparc|sparc64|x32|all)\.(?:u|d)?deb|\.dsc|\.tar(?:\.gz(?:\.asc)?|\.bz2|\.xz)|\.diff\.gz)|\.rpm|index\.db-.+\.gz|\.jigdo|
> \.template)$

That works for stunnel4, but looks like it only allows *.tar.gz.asc, but
should also allow for *.tar.bz2.asc and *.tar.xz.asc.

Ansgar

Bug#847315: apt-cacher: doesn't allow to download upstream signatures (*.asc)

[Ansgar Burchardt]

Package: apt-cacher
Version: 1.7.13
Severity: normal

apt-cacher doesn't allow to download upstream signatures which are
part of the source package.  For example, stunnel4 3:5.38-1 from unstable:

+---
| % apt-get source stunnel4
| [...]
| Skipping already downloaded file 'stunnel4_5.38-1.dsc'
| Skipping already downloaded file 'stunnel4_5.38.orig.tar.gz'
| Skipping already downloaded file 'stunnel4_5.38-1.debian.tar.xz'
| Need to get 811 B of source archives.
| Err:1 http://ftp.de.debian.org/debian stretch/main stunnel4 3:5.38-1 (asc)
|   403  Sorry, not allowed to fetch that type of file: 
stunnel4_5.38.orig.tar.gz.asc
| E: Failed to fetch 
http://ftp.de.debian.org/debian/pool/main/s/stunnel4/stunnel4_5.38.orig.tar.gz.asc
  403  Sorry, not allowed to fetch that type of file: 
stunnel4_5.38.orig.tar.gz.asc
| E: Failed to fetch some archives.
+---

Please allow retrieval of ${orig_tarball}.asc in addition to just
${orig_tarball}.

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.8.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-cacher depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  ed 1.10-2.1
ii  libdpkg-perl   1.18.15
ii  libfilesys-df-perl 0.92-6+b1
ii  libio-interface-perl   1.09-1+b2
ii  libipc-shareable-perl  0.61-1
ii  libnetaddr-ip-perl 4.079+dfsg-1+b1
ii  libsys-syscall-perl0.25-6
ii  libwww-curl-perl   4.17-3
ii  libwww-perl6.15-1
ii  lsb-base   9.20161125
ii  perl   5.24.1~rc4-1
ii  ucf3.0036
ii  update-inetd   4.43

Versions of packages apt-cacher recommends:
pn  libberkeleydb-perl
pn  libio-compress-lzma-perl  

Versions of packages apt-cacher suggests:
ii  libfreezethaw-perl   0.5001-1
ii  libio-socket-inet6-perl  2.72-2

-- debconf information excluded

Bug#758234: another nasty fallout of this requirement

[Ansgar Burchardt]

On Sat, 2016-12-03 at 06:33 +0100, Adam Borowski wrote:
> And to actually fix the issues, instead of merely dropping the
> mention and
> thus making the dependencies last forever because of inertia, I urge
> you to
> go all the way from "priority of rdepends MUST be raised" all the way
> to
> "priority of rdepends MUST NOT be raised, every package is to be
> evaluated
> only based on what it directly brings to the user (elevation possibly
> _moved_ to a metapackage/etc but never copied the other way)" (maybe
> just a
> SHOULD NOT for a transitional period).

I think this should be a "SHOULD NOT":

The main consumer of the priority information is the installer
(debootstrap) which has only a very limited dependency resolver.  It
might be necessary to raise the priority of dependencies to make sure
it does the right thing (I don't think we need this currently, but we
should keep the option open in case it turns out we need it).

Ansgar

Bug#845539: Avoid building documentation on arch-dep-only builds

[Ansgar Burchardt]

I don't maintain the package, but I was wondering:

With both override_dh_auto_configure-arch and -indep, what happens when
 building both arch-indep and arch-dep packages?

Ansgar

Bug#483754: [Popcon-developers] Bug#483754: overbroad Recommends

[Ansgar Burchardt]

Hi,

I agree that popularity-contest recommending a mta is a too large
dependency: popcon uses http by default and a mta would usually require
manual configuration to work properly.

Note that the default install no longer installs a MTA since some time.

(I just noticed when installing popcon in a container.)

Ansgar

Bug#834867: lintian: Please allow uniformly compressed .debs in Debian

[Ansgar Burchardt]

Control: tag -1 - moreinfo

Guillem Jover writes:
> As proposed on debian-devel [P], I'd like to switch dpkg-deb to
> generate uniformly compressed .debs by default soon. This would
> require for ftpmasters to agree, for lintian to stop emitting
> autoreject tags and I guess for a backport to be installed in
> ftp-master. I'm CCing ftpmasters so that they can voice in.
>
>   [P] 

Guillem said that this is already supported by tools in stable.  So I
think using xz for the control.tar member is okay.

Ansgar

Bug#843773: misleading timestamps in binnmus

[Ansgar Burchardt]

On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
> > It seems that sbuild indeed re-uses the timestamp from the last
> > debian/changelog entry in the binNMU changelog entry.
> 
> This has been done in an early attempt to make binNMUs co-installable 
> in a multiarch world:
> 
> ,
> > sbuild (0.62.2-1) unstable; urgency=low
> > [...]
> > - Improve binNMU handling to permit binNMUs for multiarch
> > packages
> >   (Closes: #620112).  Currently, binary NMUs use the current
> > date
> >   in the new changelog entry, but co-installable packages
> > require
> >   an identical changelog.  To avoid this, take the date from
> > the
> >   previous changelog entry to ensure the same date for all
> > binNMUs.
> > [...]
> >  -- Roger Leigh   Tue, 05 Apr 2011 10:46:49
> > +0100
> 
> `
> 
> Which did not help, because the changelog is not actually identical
> anyway.

The date from the last sourceful upload should probably still be used
for any date/time information included in generated files to ensure
they are identical on all architectures (or at least to try to do so).

If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
probably be set to the date of the last sourceful upload (instead of
just using the most recent changelog entry).

Ansgar

Bug#843809: check that executables don't link to libraries in /usr is broken wrt libsystemd-shared

[Ansgar Burchardt]

Michael Biebl writes:
> But now we have a different issue, ldd thinks, that liblz4 is in /lib.:
[...]
> This is because of merged-usr. This more or less renders the whole check
> useless once we build in a chroot which has been created with
> debootstrap --merged-usr
>
> Dunno, maybe we should just drop the check again. Thoughts?

I suppose one could ask dpkg where it thinks the library belongs to.

But as far as I understand, we require /usr is available early, that is
/usr must already be mounted by the initramfs if it is a separate
partition.  Making sure nothing in the root partition links against
libraries from /usr seems a moot exercise when /usr should already be
available even on non-merged-/usr systems.

Ansgar

Bug#841935: pbuilder: incorrect permissions on /dev/ptmx breaks openpty()

[Ansgar Burchardt]

Thorsten Glaser writes:
> … whereas all “new” chroots look like…
>
> ls: cannot access 'base.cow-xenial-amd64/dev/pts/ptmx': No such file or 
> directory
> lrwxrwxrwx 1 root root 8 Mai 10 14:10 base.cow-xenial-amd64/dev/ptmx -> 
> pts/ptmx
>
> … so I assume that something in debootstrap changed so that
> there is now a symlink created instead of a proper device node.
>
> Maybe the debootstrap maintainers can comment on this?

That looks like the same issue as I reported in sbuild in #817236 (which
severity maybe should be raised if this is an issue for more packages):
there needs to be a mount for /dev/pts to accommodate for the changes in
debootstrap (and optionally a bind mount for /dev/ptmx if there are
still old chroots around).

Ansgar

Bug#842873: dak: Rename ACCEPT(ED).* for rejected policy queue uploads

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertag: dak

Quoting from https://lists.debian.org/debian-backports/2016/11/msg1.html:

| The upload is "new" as the override for the package was lost in time and
| space.  I looked at the logs to find out why this happened:
|
|  - 20160619: uploaded to backports-new, overrides are added and the
|package is marked to be accepted, but dak ends up rejecting the
|package (Built-Using refers to another backported package that is not
|yet accepted).
|  - 20160704: unused override gets removed
|  - 20160725: package gets re-uploaded and accepted (as the package is
|still marked to be accepted from 20160619).
|
| So dak treats packages that are to be accepted, but rejected for other
| reasons, and later re-uploaded using the same version wrong.  It should
| probably remove the "accept" mark in this case.

ACCEPT.*, ACCEPTED.* should probably be renamed to something no longer
processed, e.g. ACCEPT-ERROR.*, in case an upload marked to be accepted
ends up getting rejected instead.

Or move ACCEPT.* to the database instead. And/or change how overrides
work ;)

Ansgar

Bug#842872: dak: logs override change, even though there is none

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertag: dak

dak logs an override change with every update of testing:

+---
| 20161101020255|check-overrides|dak|syncing 
override|testing|main|dsc|golang-github-fatih-color|source|misc|None|source|misc|None
+---

Even though the override shouldn't change all the time (and looks the
same in the log message).  This also spams the `audit.package_changes` table.

This doesn't happen for the binary package (golang-github-fatih-color-dev).

Ansgar

Bug#842869: dak: logs removing recent unused overrides, even though they are kept

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertag: dak
Severity: minor
Owner: Ansgar Burchardt <ans...@debian.org>

`dak check-overrides` logs the removal of recent unused overrides, even
though they are kept:

+---
| 2016-06.xz:20160620021215|check-overrides|dak|removing unused 
override|jessie-backports|main|dsc|golang-github-fatih-color|extra|misc|None
| 2016-06.xz:20160620021217|check-overrides|dak|removing unused 
override|jessie-backports|main|deb|golang-github-fatih-color-dev|extra|devel|None
| 2016-06.xz:20160620081236|check-overrides|dak|removing unused 
override|jessie-backports|main|dsc|golang-github-fatih-color|extra|misc|None
| 2016-06.xz:20160620081238|check-overrides|dak|removing unused 
override|jessie-backports|main|deb|golang-github-fatih-color-dev|extra|devel|None
[ ... ]
| 2016-07.xz:20160704021044|check-overrides|dak|removing unused 
override|jessie-backports|main|dsc|golang-github-fatih-color|extra|misc|None
| 2016-07.xz:20160704021046|check-overrides|dak|removing unused 
override|jessie-backports|main|deb|golang-github-fatih-color-dev|extra|devel|None
+---

We intentionally keep unused overrides for 14 days to allow buildds to
catch up.

It looks fairly easy to fix: in `dak/check_overrides.py` move the

created < now() - interval '14 days'

condition from the `DELETE` query into the `SELECT` finding unused
overrides (as a `recent` column or so) and only emit log entries when
the override is not recent.

Ansgar

Bug#835530: lxc: Repository used in Debian template doesn't work

[Ansgar Burchardt]

reassign 835530 mirrors
thanks

Dryden Personalis writes:
> Just bringing this to the attention of ftp.nl.debian.org.
>
> From a Dutch VPS (at Transip.nl) I was unable to bootstrap Jessie
> properly because after a short while in downloading required packages
> it would start to error out. When I put a short delay in between the
> individual wget requests (like 0.3 seconds) everything worked fine.

Reassigning to the mirrors pseudo-package.

In earlier messages you said you were using 'http.debian.net'? Is this
still the case or did you replace it with 'ftp.nl.debian.org'? If not, I
would try using 'ftp.nl.debian.org' directly to see whether the problem
is httpredir.d.o or the ftp.nl.d.o mirror.

Ansgar

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Ansgar Burchardt]

Package: release-notes
Tags: stretch

debootstrap enables merged-/usr by default since 1.0.85 (when installing
stretch or later only).  To match this on upgrades to stretch, I would
like to recommend installing `usrmerge` at the end of the upgrade.

Ansgar

Bug#841270: RFS: debrequest/0.2 ITP

[Ansgar Burchardt]

On Wed, 2016-10-19 at 10:19 +0300, Dmitry Bogatov wrote:
> * Package name: debrequest
>   Version : 0.2
>   Upstream Author : Dmitry Bogatov 
> * Url : https://anonscm.debian.org/cgit/users/kaction-gue
> st/debrequest.git

It might be more useful to add this to `devscripts` or some other
existing package rather than adding a new package.

Ansgar

Bug#821051: Need support for uploading and signing EFI executables

[Ansgar Burchardt]

Ben Hutchings writes:
> On Tue, 2016-10-18 at 22:55 +0200, Ansgar Burchardt wrote:
>> Is there any documentation how this is supposed to work?
>
> Nothing comprehensive as yet.  Where should it go?

It doesn't need to be comprehensive.  I just would like to understand
what needs to happen.

>> What uses the signatures the archive is planned to write to dists/*?
>
> Scripts for preparing the source packages that build signed binaries.
> (Which will probably be included in those source packages, but don't
> have to be.)

How does building signed binaries work? That sounds like the signature
gets merged into the binaries dak signed in some way?

>> It looks wrong to bypass embargoed for the signatures. We avoid showing
>> which packages will get security updates in the future.
>
> That's a fair point.  But they need to be findable by a maintainer who
> doesn't have access to embargoed packages in general.  How about using
> a hash of the changelog?

Wouldn't the maintainer need access to the embargoed binaries as well as
the signatures to prepare the signed version?

Ansgar

Bug#841181: debootstrap: Debootstrap fails to create new Ubuntu environment (Xenial, Yakety)

[Ansgar Burchardt]

Etienne Loks writes:
>* What led up to the situation?
>
> Installing an Ubuntu container fails with:

What is the command you run?  As you mention lxc below, is it
debootstrap or some lxc command?

> Aucune version du paquet lxcguest n'est disponible, mais il existe dans la
> base de données. Cela signifie en général que le paquet est manquant, qu'il
> est devenu obsolète ou qu'il n'est disponible que sur une autre source
>
> E: Le paquet « lxcguest » n'a pas de version susceptible d'être installée
> lxc_container: container creation template for osm failed
> lxc_container: Error creating container osm

Please use `export LC_ALL=C.UTF-8` when reporting bugs so error messages
are in English.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> After commenting the line installing the package lxcguest in
> /usr/share/lxc/templates/lxc-ubuntu the install is successful.

Ansgar

Bug#821051: Need support for uploading and signing EFI executables

[Ansgar Burchardt]

Steve McIntyre writes:
> As discussed with various people in the past, for UEFI Secure Boot to
> work we'll need changes in dak (and elsewhere?) to support upload and
> signing of EFI executables.
>
> Colin has pointed at the code in launchpad as inspiration:
>
> https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/uefi.py
> https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/tests/test_uefi.py
>
> We'd love to make this happen in time for stretch if at all possible.

Is there any documentation how this is supposed to work?

Which files do need to be signed? And by what key?

What uses the signatures the archive is planned to write to dists/*?

It looks wrong to bypass embargoed for the signatures. We avoid showing
which packages will get security updates in the future.

Is there a way to not pass the pin via command-line arguments as
currently implemented in [1]?

Ansgar

  [1] 

Bug#839046: debootstrap: enable --merged-usr by default

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.83

As mentioned earlier, I would like to see --merged-usr enabled by
default for Debian Stretch.  The last discussion on -devel@[1] was quite
positive; I had some additional positive feedback on IRC.

I'm not aware of any regressions so far, except for having forgotten to
add "jessie-kfreebsd" to the blacklist (a list of older releases that
don't support merged-/usr) and debootstrap 1.0.83 failing to bootstrap
squeeze[2].  Both are fixed in my changes targeted at 1.0.84[3].

So I would like to switch the default in debootstrap sooner rather than
later to give time to find some more bugs.  With this change, the
currently known bugs[4] should also be raised to "serious", but I don't
think any of them should be a blocker.

Ansgar

  [1] 
  [2] 
  [3] 
  [4] 

Bug#837649: debootstrap: Add support for Packages.xz

[Ansgar Burchardt]

Ansgar Burchardt writes:
> debootstrap should support archives that only provide Packages.xz.
>
> I'll try to take a look at implementing this soon.  From a quick glance
> it shouldn't be too difficult given several compression formats are
> already supported (bz2, gz, uncompressed).

I've prepared a patch for this[1].  It worked for me with both a
Packages.xz suite (stretch) and one only providing Package.bz2, but not
.xz (squeeze).

Ansgar

  [1] 
https://github.com/aburch/debootstrap/commit/1689d645aacb0bc3f9edb86526f67e776469942a

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Ansgar Burchardt]

tag 838388 + patch
thanks

Ansgar Burchardt writes:
> Ah, I'm to blame for that.  [1] added `-k` to the options passed to tar
> in order to avoid replacing the new symlinks from / to /usr with real
> directories.  However it looks like tar returns an error when there are
> actual file conflicts (as opposed to just symlink vs. directory).
>
> Only adding -k for newer distributions (i.e. the ones that merged-/usr
> supports) should work around the problem.

I pushed a patch implementing this to my debootstrap repository[2].  It
worked for Squeeze (w/o merged-/usr) and Stretch (w/ merged-/usr).

Ansgar

  [2] 
https://github.com/aburch/debootstrap/commit/5bb1da69596828821fe43b3ee63f733e4b8672e7

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Ansgar Burchardt]

Stephan Sürken writes:
> On Di, 2016-09-20 at 21:09 +0200, Julien Cristau wrote:
>> > It always exits here with exit code 2, without any further error
>> > message (not even when using --verbose).
>> >
>> There should be a log inside the target directory.
>
> ah, sure ;).
>
> debootstrap/debootstrap.log says:
>
> ---
> gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
> gpgv:using RSA key AED4B06F473041FA
> gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
> "
> gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
> gpgv:using RSA key 64481591B98321F9
> gpgv: Good signature from "Squeeze Stable Release Key 
> "
> tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to 'dash.1.gz': File 
> exists
> tar: ./bin/sh: Cannot create symlink to 'dash': File exists
> tar: Exiting with failure status due to previous errors

Ah, I'm to blame for that.  [1] added `-k` to the options passed to tar
in order to avoid replacing the new symlinks from / to /usr with real
directories.  However it looks like tar returns an error when there are
actual file conflicts (as opposed to just symlink vs. directory).

Only adding -k for newer distributions (i.e. the ones that merged-/usr
supports) should work around the problem.

Just --keep-directory-symlink would of course be ideal, but I doubt it
is supported everywhere (being a long option to start with).

Ansgar

  [1] 
https://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=6b79352a205a96cee441ae0c6247c4616097a517

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#837649: debootstrap: Add support for Packages.xz

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.82
Owner: Ansgar Burchardt <ans...@debian.org>
Control: block 818463 by -1

debootstrap should support archives that only provide Packages.xz.

I'll try to take a look at implementing this soon.  From a quick glance
it shouldn't be too difficult given several compression formats are
already supported (bz2, gz, uncompressed).

Ansgar

Bug#837185: debootstrap: fails with `dpkg-deb` and busybox' `tar`

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.82
Severity: minor

While testing other changes, I noticed that debootstrap fails when
using `dpkg-deb` together with busybox' `tar` implementation as
`dpkg-deb -f` passes additional options to `tar`.

I'm not sure if this happens in the real world (i.e. anyone has
`dpkg-deb` available, but busybox' tar instead of GNU's tar), but the
attached patch avoids the problem by calling the installed `dpkg-deb`
in the second stage.

(The patch should go in after the ones from #810301.)

Ansgar

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

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

Versions of packages debootstrap depends on:
ii  wget  1.18-2+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   2.1.14-5

debootstrap suggests no packages.

-- no debconf information
>From 316ba08b931e6f226b25c396b45b6add58b578e2 Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt <ans...@debian.org>
Date: Fri, 9 Sep 2016 23:03:23 +0200
Subject: [PATCH] Feign install of dpkg in second stage

Using the `dpkg-deb` extractor, or more precise `dpkg-deb -f`, together
with busybox' `tar` results in failure: `dpkg-deb` passes additional
options to `tar` that are not understood by busybox' implementation such
as `--warning=no-timestamp`.

We can avoid this by feigning the installation of `dpkg` in the second
stage. Here it is possible to call the installed `dpkg-deb` together
with the installed (GNU) `tar`.
---
 scripts/sid | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/sid b/scripts/sid
index 428c676..ceedd66 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -59,11 +59,15 @@ first_stage_install () {
 	fi
 
 	setup_devices
+}
+
+second_stage_install () {
+	setup_dynamic_devices
 
 	x_feign_install () {
 		local pkg="$1"
 		local deb="$(debfor $pkg)"
-		local ver="$(extract_deb_field "$TARGET/$deb" Version)"
+		local ver="$(in_target dpkg-deb -f "$deb" Version)"
 
 		mkdir -p "$TARGET/var/lib/dpkg/info"
 
@@ -77,10 +81,6 @@ Status: install ok installed" >> "$TARGET/var/lib/dpkg/status"
 	}
 
 	x_feign_install dpkg
-}
-
-second_stage_install () {
-	setup_dynamic_devices
 
 	x_core_install () {
 		smallyes '' | in_target dpkg --force-depends --install $(debfor "$@")
-- 
2.9.3

Bug#837075: debootstrap: does not validate `suite` parameter against Release file

[Ansgar Burchardt]

On Thu, 2016-09-08 at 16:09 +0200, Ansgar Burchardt wrote:
> 
> debootstrap should validate that ${suite} is listed in the Release
> file in either the Suite: or Codename: fields.  Additionally storing
> the codename in a variable would also be useful for suite-specific
> workarounds, such as [1].
> 
>   [1] <https://bugs.debian.org/810301#69>
> 

I've attached a patch that implements this.

AnsgarFrom 81ebc7df61e8a80915126351e01e016f6a57a52a Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt <ans...@debian.org>
Date: Thu, 8 Sep 2016 17:28:19 +0200
Subject: [PATCH 1/6] Validate SUITE against Release's Suite or Codename

Bug: https://bugs.debian.org/837075
---
 debian/changelog |  7 +++
 functions| 14 ++
 2 files changed, 21 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9a6412b..96a1dc9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debootstrap (1.0.83) UNRELEASED; urgency=medium
+
+  * functions: Validate that the requested suite is listed in the
+Release file's Suite or Codename field. (Closes: #837075)
+
+ -- Ansgar Burchardt <ans...@debian.org>  Thu, 08 Sep 2016 17:26:53 +0200
+
 debootstrap (1.0.82) unstable; urgency=medium
 
   [ Alex Bennée ]
diff --git a/functions b/functions
index 67701ee..336f220 100644
--- a/functions
+++ b/functions
@@ -512,6 +512,18 @@ extract_release_components () {
 	fi
 }
 
+CODENAME=""
+validate_suite () {
+	local reldest="$1"
+
+	CODENAME=$(sed -n "s/^Codename: *//p" "$reldest")
+	local suite=$(sed -n "s/^Suite: *//p" "$reldest")
+
+	if [ "$SUITE" != "$suite" ] && [ "$SUITE" != "$CODENAME" ]; then
+		error 1 WRONGSUITE "Asked to install suite %s, but got %s (codename: %s) from mirror" "$SUITE" "$suite" "$CODENAME"
+	fi
+}
+
 download_release_sig () {
 	local m1="$1"
 	local reldest="$2"
@@ -547,6 +559,8 @@ download_release_indices () {
 
 	download_release_sig "$m1" "$reldest" "$relsigdest"
 
+	validate_suite "$reldest"
+
 	extract_release_components $reldest
 
 	local totalpkgs=0
-- 
2.9.3

Bug#810301: merged /usr support for debootstrap

[Ansgar Burchardt]

On Thu, 2016-09-08 at 15:36 +0200, Ansgar Burchardt wrote:
> Could you use the "Codename" field from Release to normalize the
> suite name?  That should work even when the meaning of "stable"
> changes.

I've updated Marco's patch to include this change and prepared
everything as a Git series. The patches below should be applied after
the one I provided for #837075.

Additional testing is of course welcome.

Ansgar
From 55e2452198840684e64b7aad549c2cc92261a7be Mon Sep 17 00:00:00 2001
From: Marco d'Itri <m...@linux.it>
Date: Thu, 8 Sep 2016 17:34:14 +0200
Subject: [PATCH 2/6] Merged /usr support for debootstrap

---
 debootstrap   |  6 ++
 debootstrap.8 |  3 +++
 functions | 37 +
 scripts/sid   |  6 ++
 4 files changed, 52 insertions(+)

diff --git a/debootstrap b/debootstrap
index 4cea268..ea1d048 100755
--- a/debootstrap
+++ b/debootstrap
@@ -27,6 +27,7 @@ KEYRING=""
 DISABLE_KEYRING=""
 FORCE_KEYRING=""
 VARIANT=""
+MERGED_USR=""
 ARCH=""
 HOST_ARCH=""
 HOST_OS=""
@@ -100,6 +101,7 @@ usage()
   --variant=Xuse variant X of the bootstrap scripts
  (currently supported variants: buildd, fakechroot,
   scratchbox, minbase)
+  --no-merged-usrdo not make /{bin,sbin,lib}/ symlinks to /usr/
   --keyring=Kcheck Release files against keyring K
   --no-check-gpg avoid checking Release file signatures
   --force-check-gpg  force checking Release file signatures
@@ -302,6 +304,10 @@ if [ $# != 0 ] ; then
 			error 1 NEEDARG "option requires an argument %s" "$1"
 		fi
 		;;
+	--no-merged-usr)
+		MERGED_USR=no
+		shift
+		;;
 	--keyring|--keyring=?*)
 		if ! gpgv --version >/dev/null 2>&1; then
 			error 1 NEEDGPGV "gpgv not installed, but required for Release verification"
diff --git a/debootstrap.8 b/debootstrap.8
index 5864148..5eeaf04 100644
--- a/debootstrap.8
+++ b/debootstrap.8
@@ -84,6 +84,9 @@ The default, with no \fB\-\-variant=X\fP argument, is to create a base
 Debian installation in
 .IR TARGET .
 .IP
+.IP "\fB\-\-no-merged-usr\fP"
+Do not create /{bin,sbin,lib}/ symlinks pointing to their conterparts in /usr/.
+.IP
 .IP "\fB\-\-keyring=KEYRING\fP"
 Override the default keyring for the distribution being bootstrapped,
 and use
diff --git a/functions b/functions
index 336f220..f633f73 100644
--- a/functions
+++ b/functions
@@ -1136,6 +1136,43 @@ setup_dselect_method () {
 	esac
 }
 
+# Find out where the runtime dynamic linker and the shared libraries
+# can be installed on each architecture: native, multilib and multiarch.
+# This data can be verified by checking the files in the debian/sysdeps/
+# directory of the glibc package.
+#
+# This function must be updated to support any new architecture which
+# either installs the RTLD in a directory different from /lib or builds
+# multilib library packages.
+setup_merged_usr() {
+	if [ "$MERGED_USR" = "no" ]; then return 0; fi
+
+	local link_dir
+	case $ARCH in
+	hurd-*)	return 0 ;;
+	amd64)	link_dir="lib32 lib64 libx32" ;;
+	i386)	link_dir="lib64 libx32" ;;
+	mips|mipsel)
+			link_dir="lib32 lib64" ;;
+	mips64*|mipsn32*)
+			link_dir="lib32 lib64 libo32" ;;
+	powerpc)	link_dir="lib64" ;;
+	ppc64)	link_dir="lib32 lib64" ;;
+	ppc64el)	link_dir="lib64" ;;
+	s390x)	link_dir="lib32" ;;
+	sparc)	link_dir="lib64" ;;
+	sparc64)	link_dir="lib32 lib64" ;;
+	x32)	link_dir="lib32 lib64 libx32" ;;
+	esac
+	link_dir="bin sbin lib $link_dir"
+
+	local dir
+	for dir in $link_dir; do
+		ln -s usr/$dir $TARGET/$dir
+		mkdir -p $TARGET/usr/$dir
+	done
+}
+
  pkgdetails
 
 # NOTE
diff --git a/scripts/sid b/scripts/sid
index 7b32ac2..5866569 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -41,6 +41,12 @@ work_out_debs () {
 }
 
 first_stage_install () {
+	case $SUITE in
+		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
+		oldstable|stable) ;;
+		*) setup_merged_usr ;;
+	esac
+
 	extract $required
 
 	mkdir -p "$TARGET/var/lib/dpkg"
-- 
2.9.3

From 6b79352a205a96cee441ae0c6247c4616097a517 Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt <ans...@debian.org>
Date: Thu, 8 Sep 2016 17:30:17 +0200
Subject: [PATCH 3/6] Pass -k to tar when extracting packages

When installing with a merged /usr, the symlinks in / should not be
replaced with real directories when extracting the packages.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/functions b/functions
index f633f73..60aea99 100644
--- a/functions
+++ b/functions
@@ -821,7 +821,7 @@ extra

Bug#837075: debootstrap: does not validate `suite` parameter against Release file

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.81
Severity: normal

Running
  debootstrap ${suite} ${suite} ${mirror}
will install whatever the mirror serves as dists/${suite}, even when that
is not the requested suite.  This can easily be checked with a few Redirect
statements in a .htaccess file:

  Redirect /debian-wrong/pool http://ftp.de.debian.org/debian/pool
  Redirect /debian-wrong/dists/stable 
http://ftp.de.debian.org/debian/dists/unstable

Then
  debootstrap stable stable http://[...]/debian-wrong
will install unstable instead of stable.

debootstrap should validate that ${suite} is listed in the Release
file in either the Suite: or Codename: fields.  Additionally storing
the codename in a variable would also be useful for suite-specific
workarounds, such as [1].

Ansgar

  [1] 


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

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

Versions of packages debootstrap depends on:
ii  wget  1.18-2+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   2.1.14-5

debootstrap suggests no packages.

-- no debconf information

Bug#810301: merged /usr support for debootstrap

[Ansgar Burchardt]

On Thu, 7 Jul 2016 14:46:36 +0200 Marco d'Itri  wrote:
> On Jul 05, Cyril Brulebois  wrote:
> 
> > For those wondering (and AFAICT) it seems the only issue here is
how to
> > handle multilib, since multiarch is “hidden” below usr/lib (in
> > usr/lib/ subdirectories).
> Indeed.
> 
> > Actually, this means an architecture which isn't listed doesn't get
> > extra paths, and /lib might be enough for some ports, e.g. arm64.
> I do not expect that we will get any other multilib ports.
> 
> > It would seem a better idea to list all ports explicitly though.
> Why? See above.
> 
> > > >  first_stage_install () {
> > > > +   case $SUITE in
> > > > +   etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > > > +   oldstable|stable) ;;
> > > > +   *) setup_merged_usr ;;
> > > 
> > > This means “debootstrap stable” on stretch once it's released
is going
> > > to lead to different results compared to “debootstrap
stretch”.
> > That part remains to be fixed.
> Yes, but how? The current stable cannot work with a merged /usr, so 
> I expected that this would be changed just before stretch is
released.

Could you use the "Codename" field from Release to normalize the suite
name?  That should work even when the meaning of "stable" changes.

(Which makes me wonder: does debootstrap check that the suite it is
asked to install is either in the Release file's Suite or Codename
field?)

Ansgar

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ansgar Burchardt]

On Fri, 2016-08-26 at 12:38 -0400, Sam Hartman wrote:
> "Ansgar" == Ansgar Burchardt <ans...@debian.org> writes:
> 
> Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
> >> I think we want to reaffirm that policy section 9.3.2 and
> section
> Ansgar> 9.3.3
> >> represent current policy for init scripts, quoting
> particularly
> >> the following text from section 9.3.2:     Packages that
> >> include daemons for system services should place
> Ansgar> scripts
> >>   in `/etc/init.d' to start or stop services at boot time
> or
> Ansgar> during a
> >>   change of runlevel.
> 
> Ansgar> Does this really represent current policy?
> 
> Ansgar> As far as I can tell Policy still assumes that sysvinit
> is
> Ansgar> the default init system and everything else is an
> "alternate
> Ansgar> init system" (9.11).
> 
> There are many problems with regard to policy and init systems.  I
> believe that 9.3.2 on init scripts and 9.3.3 on update-rc.d are still
> our current policy and still solid.

I don't think so.  There is the larger issue that 9.3 only describes
init.d scripts, but doesn't mention the current default init system at
all.  But even for just describing those init.d scripts, it looks
fairly outdated:

Policy 9.3.3 looks really outdated: it talks about sequence numbers and
one should ask on d-devel@ to choose the right one; it also says that
update-rc.d will start services in runlevels 2-5 and stop them in 0,1,6
by default.  However the default runlevels and sequence numbers are
taken from the (required) LSB comments (directly or indirectly).  These
special comments are not mentioned anywhere.

How invoke-rc.d is invoked is also slightly outdated (the `which
invoke-rc.d` part), although there is a bug against Policy to drop that
bit.

9.3.2 suggests that editing the init script is neccessary to disable a
service without de-installing it: they are configuration files "to
disable a service without de-installing the package". That is a bad
example.

The `status` and `force-stop` options are not mentioned anywhere
(invoke-rc.d mentions them).  Though this is a minor issue.  Having
`try-restart` (from LSB) would also be nice...  It would also be nice
if "behave sensibly" would be better defined (for example LSB has
standard exit codes).

9.4 also looks outdated.  The functions in /lib/lsb/init-functions
should be used if consistent output is desired (as far as I know it
defaults to a different look for the messages, see /lib/lsb/init-
functions.d/20-left-info-blocks).

Init scripts should also really use /lib/lsb/init-functions which makes
supporting alternatives easier (take for example
/lib/lsb/init-functions.d/40-systemd).

Ansgar

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Ansgar Burchardt]

On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
> I think we want to reaffirm that policy section 9.3.2 and section
9.3.3
> represent current policy for init scripts, quoting particularly the
> following text from section 9.3.2:
> 
>  Packages that include daemons for system services should place
scripts
>  in `/etc/init.d' to start or stop services at boot time or
during a
>  change of runlevel.

Does this really represent current policy?

As far as I can tell Policy still assumes that sysvinit is the default
init system and everything else is an "alternate init system" (9.11).

I don't think Policy in its current form should be reaffirmed, but
should be updated to the current time instead. It should certainly
reflect that we changed the default init system some time ago (note
that Policy doesn't mention systemd anywhere).

(Related to that, Policy currently requires *all* packages to ship
sysvinit scripts that integrate with any alternative init system which
I am fairly sure also isn't current policy...)

Ansgar

Bug#835490: debian-policy: remove references to upstart

[Ansgar Burchardt]

Package: debian-policy
Severity: normal

Upstart is no longer part of Debian[1] nor actively maintained
upstream.  Policy should drop references to it as an alternative init
system.

I've attached a patch to remove section 9.11.1 (actually to replace it
with an empty stub to ensure there is no section 9.11.1 with different
contents in the future).

Ansgar

  [1] 
diff --git a/policy.sgml b/policy.sgml
index 9cd182b..3c75da9 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8553,47 +8553,8 @@ exec /usr/lib/foo/foo "$@"
   scripts and may not have a one-to-one correspondence with the init
   scripts.
 
-
-  Event-based boot with upstart
-
-	  
-Packages may integrate with the upstart event-based
-boot system by installing job files in the
-/etc/init directory.  SysV init scripts for which
-an equivalent upstart job is available must query the output of
-the command initctl version for the string
-upstart and avoid running in favor of the native
-upstart job, using a test such as this:
-	
-if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
-then
-	exit 1
-fi
-	
-  
-  
-Because packages shipping upstart jobs may be installed on
-systems that are not using upstart, maintainer scripts must
-still use the common update-rc.d and
-invoke-rc.d interfaces for configuring runlevels
-and for starting and stopping services.  These maintainer
-scripts must not call the upstart start,
-restart, reload, or stop
-interfaces directly.  Instead, implementations of
-invoke-rc.d must detect when upstart is running and
-when an upstart job with the same name as an init script is
-present, and perform the requested action using the upstart job
-instead of the init script.
-  
-  
-Dependency-based boot managers for SysV init scripts, such as
-startpar, may avoid running a given init script
-entirely when an equivalent upstart job is present, to avoid
-unnecessary forking of no-op init scripts.  In this case, the
-boot manager should integrate with upstart to detect when the
-upstart job in question is started or stopped to know when the
-dependency has been satisfied.
-  
+
+  (removed)
  
   
 

Bug#834831: RM: ttt -- RoQA; FTBFS, unmaintained in Debian

[Ansgar Burchardt]

Package: ftp.debian.org
Severity: normal

Please remove `ttt` from Debian. The package fails to build[1] and is
unmaintained (last NMU in 2014, last maintainer upload in 2003(!),
maintainer address bounces[2]).

Ansgar

  [1] https://bugs.debian.org/807738
  [2] https://bugs.debian.org/754453

Bug#834729: debtree: option to show source instead of binary packages

[Ansgar Burchardt]

Package: debtree
Version: 1.0.10
Severity: wishlist

It would be cool if `debtree` had an option to show source instead of
binary packages.  That is, build the graph using (build-)depends as
currently done, but then replace the binary packages with the source
package it is built from and collapse them.  The last step should also
remove dependencies from the source package on itself (that come from
one binary depending on another binary built from the same source
package).

This would be useful to simplify dependency trees for analysis. As an
example, deal.ii depends on trilinos-all-dev. The latter pulls in an
enormous number of packages all built from src:trilinos. Having just
"deal.ii -> trilinos" in the graph would be much more readable than
having all individual packages.

`skip` and `end` packages do not solve this as I would like to be able
to see trilinos' dependencies as well. Though it would be nice if
`skip` and `end` could also be specified by source package name.

Ansgar

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

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

Versions of packages debtree depends on:
ii  dctrl-tools  2.24-2
ii  libapt-pkg-perl  0.1.29+b5
ii  perl 5.22.2-3
ii  ucf  3.0036

Versions of packages debtree recommends:
ii  graphviz  2.38.0-14

debtree suggests no packages.

-- no debconf information

Bug#834602: dirmngr/gnupg: dependencies not strict enough

[Ansgar Burchardt]

Package: dirmngr
Version: 2.1.14-5
Severity: normal

The dependencies between dirmngr and gnupg2 are not strict enough and
allow installing non-working combinations, such as dirmngr=2.1.11-7
(from testing) and gnupg=2.1.14-5 (from unstable):

+---
| % gpg --search-keys [...]
| gpg: connecting dirmngr at '/run/user/[...]/gnupg/S.dirmngr' failed: IPC 
connect call failed
| gpg: error searching keyserver: No dirmngr
| gpg: keyserver search failed: No dirmngr
| 2 ~ % dpkg -l gnupg dirmngr
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
| |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
| ||/ Name Version Architecture
Description
| 
+++--===-===-=
| ii  dirmngr  2.1.11-7amd64   
server for managing certificate revocation lists
| ii  gnupg2.1.14-5amd64   GNU 
privacy guard - a free PGP replacement
| ~ % sudo apt install dirmngr/unstable
| [...]
| Preparing to unpack .../dirmngr_2.1.14-5_amd64.deb ...
| Unpacking dirmngr (2.1.14-5) over (2.1.11-7) ...
| Processing triggers for man-db (2.7.5-1) ...
| Setting up dirmngr (2.1.14-5) ...
| ~ % gpg --search-keys [...]
| [...]
| Keys 1-2 of 2 for "[...]".  Enter number(s), N)ext, or Q)uit > q
+---

Ansgar

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

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

Versions of packages dirmngr depends on:
ii  adduser3.115
ii  libassuan0 2.4.3-1
ii  libc6  2.23-4
ii  libgcrypt201.7.2-2
ii  libgnutls303.5.2-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.4-4
ii  libldap-2.4-2  2.4.42+dfsg-2+b2
ii  libnpth0   1.2-3
ii  lsb-base   9.20160629

Versions of packages dirmngr recommends:
ii  gnupg  2.1.14-5

Versions of packages dirmngr suggests:
ii  tor  0.2.8.6-2

-- no debconf information

Bug#829301: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#833757: Removed package(s) from unstable)

[Ansgar Burchardt]

reopen 829301
reassign 829301 libboost-iostreams1.61.0
clone 829301 -1
reassign -1 ftp.debian.org
retitle -1 override: libboost-iostreams1.61.0 libs optional

On Wed, 2016-08-17 at 00:49 +, Debian Bug Tracking System wrote:
> #829301: libboost-iostreams1.60.0: change Priority: to optional

This is still wrong in the new source package and we now have libboost-
iostreams1.61.0 with "Priority: important" in the archive :(

Ansgar

Bug#833640: [pkg-gnupg-maint] Bug#833640: gpg --recv-keys: does something for 5 minutes without any information

[Ansgar Burchardt]

Daniel Kahn Gillmor writes:
> On Thu 2016-08-11 03:25:00 -0400, Ansgar Burchardt wrote:
>> Ansgar Burchardt writes:
>>> I imported two keys using `gpg --recv-keys 0x... 0x...` (this is gpg2
>>> here) this morning. After reporting that both keys had been retrieved
>>> successfully, gpg decided to spend some minutes doing something: I
>>> think checking the trustdb.
>
> this sounds frustrating! It sounds to me like it is likely checking the
> trustdb that is taking this much time.  do you have a large keyring?

It has gotten fairly large (34 MB), but I don't think any regular
operation should take 5 minutes even with that. If I ask gpg to check
all signatures, fine, but just importing a key shouldn't cause gpg to
recheck *all* signatures if that takes this long: checking the
signatures of the newly imported key is enough.

> one thing you can do as a workaround is to put "no-auto-check-trustdb"
> in ~/.gnupg/gpg.conf
>
> If you do that, you'll get an alert when gpg thinks the trustdb needs
> updating, but you can decide when you want to schedule that lengthy
> process.   (when you do, you can just run "gpg --check-trustdb")

I think I'll try this.

>>> However there was no indication that gpg was supposed to still be
>>> doing anything. It would be nice if there was an informational message
>>> on the terminal for long-term operations: at least a note that this
>>> might take a while, ideally some sort of progress indication.
>>
>> The same happens when importing a single new signature:
>>
>> +---
>> | $ gpg --import < ${something}
>> | gpg: key [...] 3 new signatures
>> | gpg: Total number processed: 1
>> | gpg: new signatures: 3
>> | gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
>> | gpg: depth: 0  valid:   1  signed: 140  trust: 0-, 0q, 0n, 0m, 0f, 1u
>> | gpg: depth: 1  valid: 140  signed: 150  trust: 1-, 13q, 35n, 77m, 14f, 0u
>> | gpg: depth: 2  valid:  57  signed:  80  trust: 9-, 5q, 9n, 31m, 3f, 0u
>> | gpg: depth: 3  valid:   9  signed:  17  trust: 2-, 0q, 3n, 4m, 0f, 0u
>> | gpg: depth: 4  valid:   3  signed:   5  trust: 0-, 0q, 0n, 3m, 0f, 0u
>> | gpg: next trustdb check due at 2016-09-07
>> +---
>>
>> With gpg(2) taking quite a while:
>>
>> +---
>> | 11077 ?RLs4:49 gpg --import
>> +---
>
> your initial report was against gnupg2 -- 2.1.11-7, which shipped as
> /usr/bin/gpg2.  i see you using "gpg" here -- are you using the newer
> version of gnupg (in experimental) that ships as /usr/bin/gpg ?  or is
> "gpg" aliased to "gpg2" ?  or should this bug report be moved to the
> gnupg1 package?

It is gpg2: I have a gpg -> /usr/bin/gpg2 symlink in ~/bin to get some
more programs to use gpg2.

>> I guess I should no longer refresh the keyring or sign other people's
>> keys.  Who knows how long it will take for importing more than one new
>> signature or key. ;)
>
> :P -- rather, we should get this bug diagnosed and fixed :)
>
> a few diagnostic reports that would help me understand the state of your
> keyring would be to show me the output of:
>
> a)time gpg --with-colons --list-keys | grep -c ^pub:

+---
| % time gpg --with-colons --list-keys | grep -c '^pub:'
| 305
| gpg --with-colons --list-keys  1.82s user 0.02s system 99% cpu 1.833 total
| grep --color=auto -c '^pub:'  0.00s user 0.00s system 0% cpu 1.833 total
+---

> b)ls -la ~/.gnupg/pubring.*

+---
| -rw--- 1 [user] [group] 35331533 Aug 11 09:13 [~]/.gnupg/pubring.gpg
| -rw--- 1 [user] [group] 35331533 Aug 11 09:13 [~]/.gnupg/pubring.gpg~
+---

> c)gpg --export-ownertrust | grep -v '^#' | cut -f2 -d: | sort | uniq -c

See private mail.

Ansgar

Bug#833640: gpg --recv-keys: does something for 5 minutes without any information

[Ansgar Burchardt]

Ansgar Burchardt writes:
> I imported two keys using `gpg --recv-keys 0x... 0x...` (this is gpg2
> here) this morning. After reporting that both keys had been retrieved
> successfully, gpg decided to spend some minutes doing something: I
> think checking the trustdb.
>
> However there was no indication that gpg was supposed to still be
> doing anything. It would be nice if there was an informational message
> on the terminal for long-term operations: at least a note that this
> might take a while, ideally some sort of progress indication.

The same happens when importing a single new signature:

+---
| $ gpg --import < ${something}
| gpg: key [...] 3 new signatures
| gpg: Total number processed: 1
| gpg: new signatures: 3
| gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
| gpg: depth: 0  valid:   1  signed: 140  trust: 0-, 0q, 0n, 0m, 0f, 1u
| gpg: depth: 1  valid: 140  signed: 150  trust: 1-, 13q, 35n, 77m, 14f, 0u
| gpg: depth: 2  valid:  57  signed:  80  trust: 9-, 5q, 9n, 31m, 3f, 0u
| gpg: depth: 3  valid:   9  signed:  17  trust: 2-, 0q, 3n, 4m, 0f, 0u
| gpg: depth: 4  valid:   3  signed:   5  trust: 0-, 0q, 0n, 3m, 0f, 0u
| gpg: next trustdb check due at 2016-09-07
+---

With gpg(2) taking quite a while:

+---
| 11077 ?RLs4:49 gpg --import
+---

I guess I should no longer refresh the keyring or sign other people's
keys.  Who knows how long it will take for importing more than one new
signature or key. ;)

Ansgar

Bug#833640: gpg --recv-keys: does something for 5 minutes without any information

[Ansgar Burchardt]

Package: gnupg2
Version: 2.1.11-7
Severity: minor

I imported two keys using `gpg --recv-keys 0x... 0x...` (this is gpg2
here) this morning. After reporting that both keys had been retrieved
successfully, gpg decided to spend some minutes doing something: I
think checking the trustdb.

However there was no indication that gpg was supposed to still be
doing anything. It would be nice if there was an informational message
on the terminal for long-term operations: at least a note that this
might take a while, ideally some sort of progress indication.

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.6.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 gnupg2 depends on:
ii  dpkg   1.18.10
ii  gnupg-agent2.1.11-7
ii  install-info   6.1.0.dfsg.1-8
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.23-4
ii  libgcrypt201.7.2-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.4-3
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.13.0-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg2 recommends:
ii  dirmngr  2.1.11-7

Versions of packages gnupg2 suggests:
pn  gnupg-doc   
pn  parcimonie  
pn  xloadimage  

-- no debconf information

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#832372: override: brotli:utils/standard

[Ansgar Burchardt]

Control: tag -1 moreinfo

Tomasz Buchert  writes:
> The binary package brotli should be in utils per 
> https://bugs.debian.org/832191.
> This has been already changed in the last upload [1].
>
> [1] https://sources.debian.net/src/brotli/0.4.0%2Bdfsg-1/debian/control/

The subject also asks the priority to be changed to "standard". Is that
also your intention?

Ansgar

Bug#832575: dune-grid FTBFS on mips, mipsel (virtual memory exhausted)

[Ansgar Burchardt]

Hi,

On Wed, 2016-07-27 at 06:30 +, Daniel Knezevic wrote:
> Package dune-grid FTBFS on mips and mipsel with following error:
> virtual memory exhausted: Cannot allocate memory
> 
> build logs:
> https://buildd.debian.org/status/fetch.php?pkg=dune-grid=mips
> r=2.4.1-1=1466966398
> https://buildd.debian.org/status/fetch.php?pkg=dune-grid=mipsel;
> ver=2.4.1-1=1456760195
> 
> I tried to reduce ggc-min-expand to 20, and with this change package
> compiles for me.
> 
> With attached patch I was able to build dune-grid successfully for
> both mips and mipsel.

Thanks for your patch, but I'm not happy with fiddling with GCC
internals to get the package to compile. In addition upstream switched
to CMake so the patch won't apply as-is to the next release.

There is hopefully also a better solution coming upstream: the
problematic test is test-yaspgrid.cc which is huge, but there is
interest upstream to split it into multiple smaller tests[1]. I guess
this would also fix the build failure on mips(el).

Ansgar

  [1] 


signature.asc
Description: This is a digitally signed message part

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#831732: RFA: quvi -- command line program to extract video download links

[Ansgar Burchardt]

Package: wnpp
Severity: normal
Control: affects -1 quvi

I request an adopter for the quvi package. As most videos sites now
work with HTML5, I no longer use it myself.

The package description is:
 libquvi is a library to parse Adobe flash video download links. It
 supports Youtube and other similar video websites. It provides access
 to functionality and data through an API, and does not enable or
 require the use of the flash technology.
 .
 This package contains a command line program to extract and download
 video files using libquvi.

Bug#831271: src:python-pip: hardcoded list of packages in "Built-Using"

[Ansgar Burchardt]

Source: python-pip
Version: 8.1.2-2
Severity: important

python-pip hardcodes the list of Built-Using packages for python-pip-
whl in debian/control. Please generate the list automatically at build
time using the package versions actually used.

In particular this breaks building[1] the package automatically in
other environments, such as derivate distributions that like Debian
enfore the full source is present, including source packages referred
to via Built-Using.

Ansgar

  [1] Or actually accepting into the archive.

Bug#828084: Proposed patch to dak/debianqueued

[Ansgar Burchardt]

Hi,

Mathieu Parent  writes:
> See attached patch.
>
> This actually ignore files:
> - starting with a dot
> - containing a colon (See: #828084)

Thanks, I've applied your patch.

Ansgar

Bug#830894: override: initscripts:admin/optional

[Ansgar Burchardt]

tag 830894 + moreinfo
tag 830895 + moreinfo
tag 830901 + moreinfo
thanks

Michael Biebl writes:
> on a Debian stretch/unstable system using systemd as init system, the
> initscripts package is no longer required. We asked all packages with
> explicit dependencies to remove it and it is now possible to uninstall
> initscripts without any ill side-effects.
> update-rc.d has been updated to cope with the fact that the facilities
> defined by initscripts do not exist.
> It is therefor safe to no longer install the initscripts package by
> default.
>
> Please lower the priority of initscripts accordingly.

Let's ping -boot@ before the change.

Dear d-i maintainers, please ack the priority change to initscripts,
sysv-rc[1] and startpar[2] from "required" to "optional".

  [1] https://bugs.debian.org/830895
  [2] https://bugs.debian.org/830901

All three packages should get pulled in by "sysvinit-core" on systems
not using systemd.

Ansgar

Bug#830978: Browserified javascript and DFSG 2

[Ansgar Burchardt]

On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote:
> Or are you asking us to potentially overrule the ftpmasters inclusion
> of libjs-handlebars? Or potentially overrule the release managers
> determination of whether this particular bug is RC or not?
[...]
> I'd certainly be more comfortable if the ftpmasters and release 
> managers would weigh in here.

On the concrete case of libjs-handlebars: the JS files we distribute
seem to be generated by a parser-generator and thus certainly shouldn't
qualify as source. I filed a seperate bug for this to keep it apart
from the browserification issue, see [1].

  [1] https://bugs.debian.org/830986

The ftp team can only catch shipping generated source by chance as we
mostly just look at license headers.  Avoiding such issues by using
what upstream considers "source" already counts as a good reason to me.

For the general case, I haven't yet looked into what "browserified"
means exactly, but from skimming over the discussion on -devel@ it
sounded like it was a glorified "cat"?  In that case shouldn't one be
able to easily use "cat" instead of "grunt" to build the package from
the files upstream considers source?  If it is more than "cat", some
more information would be helpful.

Ansgar

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#830575: nspawn lacks a dependency on dbus

[Ansgar Burchardt]

On Mon, 2016-07-11 at 14:18 +0200, Michael Biebl wrote:
> Am 09.07.2016 um 18:33 schrieb Jan Engelhardt:
> > Package: systemd-container
> > Version: 230-5
> > 
> > nspawn fails to start the selected program. It appears to need
> > dbus, and Debian
> > is missing a Requires:. System has version "stretch main" listed in
> > apt
> > sources.list.
> 
> systemd has a Recommends: dbus, so I assume you have
> Recommends-installed-by-default disabled?

If systemd-container requires dbus to work at all, we could just add a
"Depends: dbus" there. We already did so for libpam-systemd (as logind
works only with dbus too).

Ansgar

Bug#534058: build-depends not available on amd64

[Ansgar Burchardt]

Steve Langasek  writes:
> There is now a provisional field that you can include in debian/control to
> indicate which architecture an architecture: all package needs to be built
> on: XS-Build-Indep-Architecture.

I thought it was going to be "Build-Architecture-Indep" from some
discussion in -devel@[1]?  Any reason why this was changed?

Ansgar

  [1] 

Bug#829301: libboost-iostreams1.60.0: change Priority: to optional

[Ansgar Burchardt]

Package: libboost-iostreams1.60.0
Severity: normal

Please change the Priority of libboost-iostreams1.60.0 to optional;
see also [1]. (Also even if it had rdeps, a high priority is rather
contraproductive IMHO, see [2].)

Ansgar

  [1] 
  [2] 

Bug#827907: RFS: evil/1.2.12-1 ITP

[Ansgar Burchardt]

On Fri, 2016-07-01 at 08:13 +, Sean Whitton wrote:
> On Thu, Jun 30, 2016 at 10:24:51PM +0200, Jakub Wilk wrote:
> > * Dmitry Bogatov , 2016-06-30, 22:28:
> > > * default configuration of pbuilder do not provide possibility to
> > > allocate
> > > pty
> > 
> > Sounds like a bug in pbuilder.
> > 
> > > So, question is whether it is possible to allocate pty on Debian
> > > build
> > > farm.
> > 
> > Yes.
> 
> It seems that vanilla sbuild has the same problem (tested locally and
> on
> deb-o-matic), so it seems like the buildds are using some special
> sbuild
> configuration to permit allocating ptys.
> 
> I would be grateful, Jakub, if you could try the build on your sbuild
> config before I file a bug against sbuild suggesting this be the
> default.  The repo, for your convenience:
> https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el

It depends on the version of debootstrap in use. See [1].

Ansgar

  [1]