Bug#861103: unblock: nbd/1:3.15.2-3

[Cyril Brulebois]

Niels Thykier  (2017-04-25):
> Wouter Verhelst:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Please unblock package nbd
> > 
> > As of NBD 3.15, there is support for encrypted communication over TLS.
> > As part of that, the test suite adds a set of tests to verify that the
> > TLS functionality does not break.
> > 
> > However, one of the test certificates to perform those tests (which is
> > shipped with the source) was accidentally generated with a validity of
> > one year, and expired on the 19th of april (i.e., 5 days ago). This
> > causes nbd to FTBFS.
> > 
> > I would like to upload NBD with a new certificate having a validity of
> > 10 years, so that this problem will not reappear for the lifetime of
> > stretch.
> > 
> > (yes, I did verify whether all the other certificates are generated with
> > 10 years of validity, and they are)
> > 
> > [...]
> > 
> > unblock nbd/1:3.15.2-3
> > 
> > [...]
> 
> 
> Ack from here, CC'ing KiBi for a d-i ack.

Funniest source debdiff I've seen in a very long while, congrats!

And of course, no objections.
 

KiBi.


signature.asc
Description: Digital signature

Bug#861103: unblock: nbd/1:3.15.2-3

[Niels Thykier]

Wouter Verhelst:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package nbd
> 
> As of NBD 3.15, there is support for encrypted communication over TLS.
> As part of that, the test suite adds a set of tests to verify that the
> TLS functionality does not break.
> 
> However, one of the test certificates to perform those tests (which is
> shipped with the source) was accidentally generated with a validity of
> one year, and expired on the 19th of april (i.e., 5 days ago). This
> causes nbd to FTBFS.
> 
> I would like to upload NBD with a new certificate having a validity of
> 10 years, so that this problem will not reappear for the lifetime of
> stretch.
> 
> (yes, I did verify whether all the other certificates are generated with
> 10 years of validity, and they are)
> 
> [...]
> 
> unblock nbd/1:3.15.2-3
> 
> [...]


Ack from here, CC'ing KiBi for a d-i ack.

Thanks,
~Niels

Bug#857085: [Pkg-d-devel] Bug#857085: terminix FTBFS on armhf: Error executing /usr/bin/ldc2: Segmentation fault

[Iain Buclaw]

On 24 April 2017 at 20:04, Matthias Klumpp  wrote:
> Hi!
>
> Here is a short summary on the bug:
>
> 1) It only happens on Debian buildds, Fedora and Arch are not
> affected. I examined the build logs and the environments are
> relatively similar, with a notable difference for Fedora being that
> they build with GCC 7
>
> 2) The issue itself is an infinite loop in
> `TemplateInstance::needsCodegen` which shouldn't be possible, and
> upstream has no idea why it happens. Debugging the issue is really
> hard.
>
> 3) Suddenly we started to get the same bug reproducibly on i386
> buildds as well for LDC itself, see[1]. There, the bug is in the
> bootstrap process, which uses an older compiler that worked fine
> already for many Debian releases. This suggests that the actual issue
> might be in a different portion of the code, or something else has
> changed that is now triggering the issue.
>
> 4) Compiling LDC in a i386 chroot on an arm64 host always works
> without any issues - the problem appears only on the buildd (which
> itself is an amd64 host...).
>
> 5) The same applied to the crash on armhf which never happens when
> cross-compiling, but only on a real armhf machine.
>
> 6) The problem is not LDC being miscompiled during bootstrap, nor does
> compiling with LLVM 3.8 instead of 3.9 change anything.
>
> 7) The crash disappears when running in GDB (or valgrind)
>
> I am really out of ideas on this - upstream suggested some valgrinding
> and gdb-ing, but doing that is very cumbersome as the only place where
> I can reproduce this bug that isn't a Debian buildd is an armhf
> porterbox (and armhf is really slow...), and as soon as you run the
> application in gdb the crash vanishes.
>
> Creating a minimized testcase would take multiple weeks on armhf, and
> ultimately failed a few weeks back - but we uncovered another bug in
> the process, which was resolved meanwhile, so at least something good
> came out of it.
>
> Any help would be highly appreciated!
> Cheers,
> Matthias Klumpp
>
> [1]: 
> https://buildd.debian.org/status/fetch.php?pkg=ldc&arch=i386&ver=1%3A1.1.1-3&stamp=1493055455&raw=0
>

If running in gdb makes the problem go away, have you tried turning on
core dumps in buildd?

--
Iain.

Bug#861116: Re : Bug#861116: yadex crashes on startup

[nicolas . patrois]

Le 24/04/2017 22:19:33, Andre Majorel a écrit :

> Debian used to have a Yadex package but it was removed in 2004
> because it had been "without maintainer for over a year". You
> are trying to use a 14-year old binary on a new system.

OK, thanks.
Is there a similar package in Debian?

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des 
humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#861004: closed by Guido Günther (Re: Bug#861004: git-buildpackage: gbp buildpackage fails with nonsense errors when binary files have changed since last release)

[Guido Günther]

On Mon, Apr 24, 2017 at 08:41:16PM +0200, Guido Günther wrote:
> reopen 861004
> retitle 861004 Give folks a way to not care about dpkg-source and git 
> interaction
> severity 861004 wishlist
> 
> On Sun, Apr 23, 2017 at 11:22:23PM +0200, Guido Günther wrote:
> > On Sun, Apr 23, 2017 at 01:03:12PM -0700, Joshua Hudson wrote:
> > > I expect the tool to treat the provided git repository as the master
> > > source. This should result in not needing to fetch a source tarball at
> > > all.
> > 
> > It does. There's no need to fetch a tarball.
> > 
> > > 
> > > This tool was recommended to me for how to update a debian package to
> > > take a new upstream source. Apparently it can't actually do that.
> > 
> > It can and we're doing it all the time. Check
> > 
> > 
> > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT
> 
> There might be times where you don't want to follow correct packaging
> practice, especially when getting started and you first want to get a
> package so havng a mode for this might help. Patch forthcoming.
> 

Docs about the new mode are here:


http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.special.html#GBP.SPECIAL.SLOPPYTARBALL

Cheers,
 -- Guido

Bug#861004: [git-buildpackage/master] buildpackage: add sloppy mode to build upstream tarballs

[Guido Günther]

tag 861004 pending
thanks

Date:   Tue Apr 25 08:23:51 2017 +0200
Author: Guido Günther 
Commit ID: 000f92479367d6245be3bda9a662758009f87d14
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=000f92479367d6245be3bda9a662758009f87d14
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=000f92479367d6245be3bda9a662758009f87d14

buildpackage: add sloppy mode to build upstream tarballs

When starting with Debian _and_ git people often stumble over a mismatch
between what dpkg-source expects to be in the tarball and the generated
tarball for various reasons. Give them a way to say:
   "Use what I have on my current debian branch"
as upstream source.

Closes: #861004

  

Bug#861156: tt-rss: Needs new Dojo to render UI properly

[Matthew Gabeler-Lee]

Package: tt-rss
Version: 17.1+git20170410+dfsg-2
Severity: important

Since updating to the new 17.1 package of tt-rss, some parts of the UI no
longer render correctly.  Immediately noticeable is the feed icons are all
gone, despite the usual "clear cookies, shift-reload" after updates.

Scanning around, I find this thread that indicates upstream expects to have
Dojo 1.12, but Debian / this tt-rss package only has 1.11, so I suspect this
is the crux of the issue.

https://tt-rss.org/oldforum/viewtopic.php?f=10&t=4024

For reference, with the older Dojo, the immediate problem of feed icons
seems to be placing an  as a child of another , which no browser
will render AFAICT.  I suspect in the newer Dojo, the node it's placing the
image into is no longer another image.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/12 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 tt-rss depends on:
ii  dbconfig-common 2.0.8
ii  dbconfig-mysql  2.0.8
ii  debconf [debconf-2.0]   1.5.60
ii  init-system-helpers 1.47
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.16-3
ii  libjs-dojo-core 1.11.0+dfsg-1
ii  libjs-dojo-dijit1.11.0+dfsg-1
ii  libjs-scriptaculous 1.9.0-2
ii  libphp-phpmailer5.2.14+dfsg-2.3
ii  lsb-base9.20161125
ii  php 1:7.0+49
ii  php-mbstring1:7.0+49
ii  php-mysql   1:7.0+49
ii  php-php-gettext 1.0.12-0.1
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.16-3
ii  php7.0-cgi [php-cgi]7.0.16-3
ii  php7.0-cli [php-cli]7.0.16-3
ii  php7.0-json [php-json]  7.0.16-3
ii  php7.0-mbstring [php-mbstring]  7.0.16-3
ii  php7.0-pgsql [php-pgsql]7.0.16-3
ii  php7.0-xml [php-xml]7.0.16-3
ii  phpqrcode   1.1.4-2

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.25-3
ii  ca-certificates 20161130
ii  lighttpd [httpd]1.4.45-1
ii  php-curl1:7.0+49
ii  php-gd  1:7.0+49
ii  php7.0-curl [php-curl]  7.0.16-3
ii  php7.0-gd [php-gd]  7.0.16-3
ii  php7.0-mcrypt [php-mcrypt]  7.0.16-3

Versions of packages tt-rss suggests:
ii  php-apc  4.0.10-1
ii  php5-apcu [php-apc]  4.0.10-1
ii  sphinxsearch 2.2.11-1.1

-- Configuration Files:
/etc/default/tt-rss changed [not included]
/etc/tt-rss/apache.conf changed [not included]
/etc/tt-rss/config.php changed [not included]

-- debconf information excluded

Bug#794410: ISO with more firmwares might work

[Yu Wang]

Laterly I got some help and it seems there is a install iso that contains more 
firmwares, just like Ubuntu.
Since I can install Ubuntu 16.10 without problem, I think it should work.
For anyway interested, please search for "firmware-8.7.1-amd64-netinst.iso" and 
try.

Bug#860225: bind9: CVE-2017-3137: A response packet can cause a resolver to terminate when processing an answer containing a CNAME or DNAME

[Jan Sechovec (skudlik)]

Hello,

Debian Jessie, bind9  9:1:9.9.5.dfsg-9+deb8u10

Same problem, bind gets down after few hours... something has started 
abusing this vulnerability.


24-Apr-2017 23:21:22.592 resolver.c:4350: INSIST(fctx->type == 
((dns_rdatatype_t)dns_rdatatype_any) || fctx->type == 
((dns_rdatatype_t)dns_rdatatype_rrsig) || fctx->type == 
((dns_rdatatype_t)dns_rdatatype_sig)) failed, back trace

24-Apr-2017 23:21:22.592 #0 0x7eff74c11a00 in ??
24-Apr-2017 23:21:22.592 #1 0x7eff72ded8ea in ??
24-Apr-2017 23:21:22.592 #2 0x7eff744d314e in ??
24-Apr-2017 23:21:22.592 #3 0x7eff72e0fd5b in ??
24-Apr-2017 23:21:22.592 #4 0x7eff727c0064 in ??
24-Apr-2017 23:21:22.592 #5 0x7eff7218e62d in ??
24-Apr-2017 23:21:22.592 exiting (due to assertion failure)

The problem is for us really critical.

Thanks in advance,

Jan

Bug#860951: ejabberd: apparmor profile missing "m" perm for su

[Philipp Huebner]

Am 23.04.2017 um 17:01 schrieb Kees Cook:
> I've tried the diff but the problem remains: I still need "m" on the su in 
> the su
> subprofile.

I'll add it then,
thanks!

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#860923: src:dask: New upstream release

[Diane Trout]

FWIW

I pushed changes for dask to git, and created a sortedcollections
repository in python modules.

I tried to make updates to dask.distributed but had a merge conflict,
I'll have to look at resolving the git issues in my tomorrow (I'm in
US/Pacific, GMT-7/8)

Diane

Bug#851694: qemu: Formatting USB disks to EXT4 with nec-xhci USB controller fails with Buffer I/O fails

[Michael Tokarev]

24.04.2017 19:26, anonym wrote:
[]
>> I tried to reproduce this, but can not. What's needed to reproduce it?
> 
> Sorry for the complicated reproducer, but here goes:
> 
> 1. Download the latest Tails ISO image from: 
> http://dl.amnesia.boum.org/tails/stable/
> 2. Boot the Tails ISO image in a VM that has the nec-xhci USB controller
> 3. At the GDM greeter, configure an administration password (useful for 
> gathering debug info not accessible by the default user)
> 4. Attach a virtual USB drive of at least 4 GB capacity through nec-xhci
> 5. Start Tails Installer via the GNOME Applications menu -> Tails -> Tails 
> Installer
> 6. Install Tails to the USB drive
> 
> You'll notice that the installation never finishes, and you'll see the error 
> reported above via `sudo journalctl`.

The installation goes on just fine here. Installer creates a FAT32 filesystem
on the usb "stick", copies files there. After reboot the system boots fine
from the usb "stick".

Size of the hdd image which I used is 6Gb.

Here's the qemu commands I used:

qemu-img create foo 6G
qemu-system-x86_64 -enable-kvm -m 1G -cdrom tails-i386-2.12.iso \
 -device nec-usb-xhci,id=xhci \
 -drive file=foo,format=raw,id=foo,if=none \
 -device usb-storage,bus=xhci.0,drive=foo

What I'm doing wrong? :)

Thanks,

/mjt

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Lumin]

Hi Adam,

> It does look uploadable, yeah, even though there's a bunch of issues.  It's
> up to you whether you want to get it good first or to upload present state
> then improve it incrementally.  Please say what you prefer.

I updated the package again with the following changes:

 * changed Multi-Arch of the lib package to same
 * detect architecture in rules to privide HH_AARCH64 and HH_POWER
flag to upstream makefile,
which is possible to fix the arm64 and ppc64el builds. (oops, I
have no such machines to test)
 * added manpage highwayhash.3 (modified based on your snippet)
 * added autopkgtest script (using modified version of your sanity test code)

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

I think this package can be uploaded now. Further fix will be added
incrementally.

> The bad news is, it succeeded only on amd64.
>
> On other architectures, the closest it came on x32 (a non-release arch) --
> builds ok, fails only at dpkg-gensymbols due to symbol mismatches.
> One warning: left shift count >= width of type [-Wshift-count-overflow]
> sounds like it might be broken, though[1].
>
> On arm64 it fails with:
> g++: error: unrecognized command line option '-mavx2'
>
> On armhf there's both the shift width issue, and:
> error: #error "Port"
>
> On i386, all of the above, plus:
> error: '_mm_cvtsi64_si128' was not declared in this scope

The HH_POWER and HH_AARCH64 flags are possible to fix the ppc64{,el} build and
arm64 build. However, I'm not clear on upstream's attitude towards
32-bit architectures.

Actually I think 32-bit architectures are not my priority too, since
upstreams of my
deep learning packages don't put much attention on 32-bit architectures.

So I think this package can be uploaded now.

> I assume you neither have access to porterboxes nor an array of hardware at
> home (and qemu can be tricky), so it might be easiest for you to abuse the
> buildds or someone who can test.

I have only an amd64 machine, so I plan to abuse the buildd.

> Other issues:
>
> Please add:
> Multi-Arch: same
> to libhighwayhash0's section in the control file.  You install stuff to the
> proper paths so there's no reason for it to be not coinstallable.

Done.

> Some simple docs would be nice -- RTFSing the headers is not pretty.
> This could work:

Thank you for the manpage snippet, I've completed the manpage and
added it to the -dev package.

> Manually mucking with optimization variant selection provides only a very
> minor speedup, so I wouldn't bother describing those.  Especially that with
> gcc-6 per-ISA variants can be bound at library load time -- if the library
> uses that functionality it could eliminate the overhead altogether.  That's
> a matter for the upstream, though.

I have no intention to make a exhaustive list of interfaces in the
manpage, neither.
Four examples from upstream README should be enough for the manpage use.
(see highwayhash.3)

> Lemme share a sanity test I used:

The snippet is modified and used as autopkgtest :-)

Thank you for the suggestions which make the package in a better quality!

Bug#848694: libroken18-heimdal >= 1.7~git20150920 removed two symbols

[Brian May]

On Mon, Dec 19, 2016 at 04:53:59PM +0100, Sergio Gelato wrote:
> Upstream has renamed two symbols in libroken without bumping the API
> version number. These are base64_decode and base64_encode, now known as
> rk_base64_decode and rk_base64_encode. The change was made in 2014.
> 
> What I think this means is that newer libroken18-heimdal needs to declare
> Breaks: heimdal-clients (<< 1.7~git20150920),
>   heimdal-kdc (<< 1.7~git20150920),
>   heimdal-servers-x (<< 1.7~git20150920),
>   libheimbase1-heimdal ((<< 1.7~git20150920),
>   libhx509-5-heimdal (<< 1.7~git20150920),
>   yafc (<< 1.3.7-1~)
> 
> I hope I haven't missed anything; please double-check.

This bug appears to have got missed :-(

As far as I can tell, the packages in Jessie contain the old symbol.
Anything before Jessie doesn't matter anymore for sid.

For the record, I don't plan to do anything for the Stretch release at
this (late) stage.

yafc in unstable no longer is linked against Heimdal. heimdal-servers-x
no longer exists in testing (and probably suffers numerous security
issues).

It is possible to install the latest libraries from Stretch on a Jessie
system and not the clients; you *might* have for example have problems
if you continue running the Jessie heimdal-kdc with the libraries from
Stretch. However the solution is simple: upgrade the clients too. As it
recommended practise when updating from Stretch to Jessie in fact.

I have attempted to cause a crash by mixing Jessie heimdal-kdc with the
stretch version of libroken. Although not a comprehensive test, it seems
to work fine. I suspect the symbol is only used by HTTP operations,
which is rare configuration for the KDC.

It is not possible to install the latest clients without the latest
libraries.

After the Stretch release this bug is going to become irrelevant, as we
don't support upgrades from Jessie to Buster.
-- 
Brian May 

Bug#861155: RFS: mlucas/14.1-2 [RC]

[Alex Vong]

Package: sponsorship-requests
Severity: important

Hello mentors,

I am looking for a sponsor for my package "mlucas"

* Package name: mlucas
  Version : 14.1-2
  Upstream Author : Ernst W. Mayer 
* URL : 
* License : GPL-2+
  Section : math

It builds those binary packages:

  mlucas - program to perform Lucas-Lehmer test on a Mersenne number

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/mlucas


Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1-2.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

mlucas (14.1-2) unstable; urgency=medium

  * RC bug fix release (Closes: #860662), split big test into smaller ones
to avoid exhausting system resources.
  * Backport fix for undefined behavior from upstream.

 -- Alex Vong   Mon, 24 Apr 2017 16:16:28 +0800


Remark
==
I tried to reproduce the RC bug in a QEMU VM with 64 cores but was
unable to reproduce it precisely (pthread_create() dies with EAGAIN
instead of ENOMEM).

Recently, I find a similar bug[0], which will be fixed in the future by
splitting big test into smaller ones (the temporary fix is to disable
the test).

So I try to split a big test into 24 smaller ones and pthread_create()
doesn't die with EAGAIN anymore. However, I am not sure if the bug is
really fixed since I don't have a physical machine with 64 cores to test
on it.

Cheers,
Alex


signature.asc
Description: PGP signature

Bug#861154: xdotool: upcase Cyrillic letters are keyed as lowercase

[Andrei Mikhailov]

Package: xdotool
Version: 1:3.20160805.1-3
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   execution of the xdotool command
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   xdotool  key --delay 200 Cyrillic_A Cyrillic_BE Cyrillic_VE Cyrillic_GHE 
Cyrillic_DE Cyrillic_IE Cyrillic_IO Cyrillic_ZHE Cyrillic_ZE Cyrillic_I 
Cyrillic_SHORTI Cyrillic_KA Cyrillic_EL Cyrillic_EM Cyrillic_EN Cyrillic_O 
Cyrillic_PE Cyrillic_ER Cyrillic_ES Cyrillic_TE Cyrillic_U Cyrillic_EF 
Cyrillic_HA Cyrillic_TSE Cyrillic_CHE Cyrillic_SHA Cyrillic_SHCHA 
Cyrillic_HARDSIGN Cyrillic_YERU Cyrillic_SOFTSIGN Cyrillic_E Cyrillic_YU 
Cyrillic_YA
   * What was the outcome of this action?
   абвгдеёжзийклмнопрстуфхцчшщъыьэюя
   * What outcome did you expect instead?
   АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64
 (x86_64)

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

Versions of packages xdotool depends on:
ii  libc6 2.24-9
ii  libx11-6  2:1.6.4-3
ii  libxdo3   1:3.20160805.1-3

xdotool recommends no packages.

xdotool suggests no packages.

-- no debconf information

Bug#856685: the upstream bugs were closed last year

[積丹尼 Dan Jacobson]

THE UPSTREAM BUGS WERE CLOSED LAST YEAR.
BUT THEIR FIXES STILL DON'T FIX THE PROBLEM ON DEBIAN.
PLEASE SOMEONE FIX THIS.
I CAN BARELY SEE THE FONTS.

Bug#860429: (no subject)

[Michael Lustfield]

Ivo,

Thanks for providing direction! I believe I can get the updated package
produced and uploaded to unstable tomorrow. Once that's uploaded, I'll work on
an update for packer and figure out what else needs to be rebuilt.

-- 
Michael Lustfield

Bug#859655: (no subject)

[Michael Lustfield]

unblock request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860429
(with more discussion)

Bug#852040: Bug#825730: jessie-pu: package ca-certificates/20141019+deb8u3

[Andreas Beckmann]

On 2017-01-23 20:57, Michael Shuler wrote:
> Thanks for the follow up. I'll get this fixed and resubmit a new debdiff
> for stable update.

Ping?

Andreas

Bug#861153: reportbug: Architecture field split into two lines

[Paul Wise]

Package: reportbug
Version: 7.1.6
Severity: minor

The architecture field is currently split into two lines:

Architecture: amd64
 (x86_64)

With earlier versions of reportbug it was only one line:

https://bugs.debian.org/823456
Architecture: amd64 (x86_64)

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64
 (x86_64)

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

Versions of packages reportbug depends on:
ii  apt1.4
ii  python3-reportbug  7.1.6
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf-utils  1.5.60
ii  debsums2.2
pn  dlocate
ii  emacs24-bin-common 24.5+1-9
ii  exim4  4.89-2
ii  exim4-daemon-light [mail-transport-agent]  4.89-2
ii  file   1:5.29-3
ii  gir1.2-gtk-3.0 3.22.11-1
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.18-6
ii  python3-gi 3.22.0-2
ii  python3-gi-cairo   3.22.0-2
pn  python3-gtkspellcheck  
pn  python3-urwid  
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4
ii  file   1:5.29-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#861152: nagstamon: InsecureRequestWarning: Unverified HTTPS request is being made.

[Paul Wise]

Package: nagstamon
Version: 2.0.1-1
Severity: serious
Tags: security

When I run nagstamon from a terminal against the Debian nagios I get a
warning about unverified and thus insecure HTTPS requests being made:

https://nagios.debian.org/icinga/
https://dsa.debian.org/ (see here for guest login)

$ nagstamon 
...
/usr/lib/python3/dist-packages/urllib3/connectionpool.py:845: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64
 (x86_64)

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

Versions of packages nagstamon depends on:
ii  libqt5multimedia5-plugins5.7.1~20161021-2
ii  python3-bs4  4.5.3-1
ii  python3-dbus.mainloop.pyqt5  5.7+dfsg-5
ii  python3-pkg-resources33.1.1-1
ii  python3-psutil   5.0.1-1
ii  python3-pyqt55.7+dfsg-5
ii  python3-pyqt5.qtmultimedia   5.7+dfsg-5
ii  python3-pyqt5.qtsvg  5.7+dfsg-5
ii  python3-requests 2.12.4-1
pn  python3:any  

nagstamon recommends no packages.

nagstamon suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#861151: W: initramfs-tools configuration sets RESUME=UUID=... warning even though RESUME=none

[Arthur Marsh]

Package: initramfs-tools
Version: 0.129
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

set RESUME=none in /etc/initramfs-tools/initramfs.conf but
still get messages:

W: initramfs-tools configuration sets 
RESUME=UUID=604db355-002c-4f41-b31c-438fe788b26d
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/sda4
I: (UUID=0e388c35-a730-4a86-ac45-e11486b3e992)
I: Set the RESUME variable to override this.

As far as I can tell, on boot up there is no attempt to resume from that UUID.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 16M Mar 28  2015 /boot/initrd.img-4.0.0-rc5+119
-rw-r--r-- 1 root root 19M Feb 20 21:01 /boot/initrd.img-4.10.0
-rw-r--r-- 1 root root 20M Feb  5 13:20 /boot/initrd.img-4.10.0-rc6-amd64
-rw-r--r-- 1 root root 20M Feb 24 05:21 /boot/initrd.img-4.10.0-trunk-amd64
-rw-r--r-- 1 root root 19M Mar  7 19:33 /boot/initrd.img-4.11.0-rc1
-rw-r--r-- 1 root root 19M Mar 13 12:40 /boot/initrd.img-4.11.0-rc2
-rw-r--r-- 1 root root 19M Apr  3 15:49 /boot/initrd.img-4.11.0-rc5
-rw-r--r-- 1 root root 19M Apr 10 10:36 /boot/initrd.img-4.11.0-rc6
-rw-r--r-- 1 root root 19M Apr 16 16:32 /boot/initrd.img-4.11.0-rc6+
-rw-r--r-- 1 root root 19M Apr 18 19:26 /boot/initrd.img-4.11.0-rc7
-rw-r--r-- 1 root root 19M Apr 24 15:36 /boot/initrd.img-4.11.0-rc7+
-rw-r--r-- 1 root root 19M Apr 24 17:38 /boot/initrd.img-4.11.0-rc8
-rw-r--r-- 1 root root 19M Apr 25 12:46 /boot/initrd.img-4.11.0-rc8+
-rw-r--r-- 1 root root 18M Dec 15 05:05 /boot/initrd.img-4.9.0
-rw-r--r-- 1 root root 19M Mar 30 23:55 /boot/initrd.img-4.9.0-2-amd64
-rw-r--r-- 1 root root 25M Apr  1 11:37 /boot/initrd.img-4.9.0-2-grsec-amd64
-rw-r--r-- 1 root root 19M Mar 30 23:56 /boot/initrd.img-4.9.0-2-rt-amd64
-rw-r--r-- 1 root root 15M Mar 29  2015 /boot/initrd.img-rc5+116
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.11.0-rc8 root=UUID=39706f53-7c27-4310-b22a-36c7b042d1a1 
ro radeon.audio=1 page_owner=on

-- resume
# RESUME=/dev/sda5
RESUME='UUID=604db355-002c-4f41-b31c-438fe788b26d'
-- /proc/filesystems
btrfs
ext3
ext2
ext4
fuseblk
xfs
jfs
msdos
vfat
ntfs
minix
hfs
hfsplus
qnx4
ufs

-- lsmod
Module  Size  Used by
ufs73728  0
qnx4   16384  0
hfsplus   106496  0
hfs57344  0
minix  36864  0
ntfs  102400  0
vfat   20480  0
msdos  20480  0
fat65536  2 msdos,vfat
jfs   176128  0
xfs  1212416  0
libcrc32c  16384  1 xfs
dm_mod114688  0
cpuid  16384  0
arc4   16384  0
ecb16384  0
md416384  0
hmac   16384  1
nls_utf8   16384  4
cifs  692224  5
ccm20480  0
dns_resolver   16384  1 cifs
fscache65536  1 cifs
bnep   20480  2
bluetooth 561152  7 bnep
nfc   118784  0
rfkill 28672  7 bluetooth,nfc
cpufreq_userspace  16384  0
cpufreq_conservative16384  0
snd_hrtimer16384  1
cpufreq_powersave  16384  0
binfmt_misc20480  1
fuse  102400  2
snd_emu10k1_synth  20480  0
snd_emux_synth 40960  1 snd_emu10k1_synth
snd_seq_midi_emul  16384  1 snd_emux_synth
snd_seq_virmidi16384  1 snd_emux_synth
snd_seq_midi   16384  0
snd_seq_midi_event 16384  2 snd_seq_virmidi,snd_seq_midi
snd_seq65536  6 
snd_seq_virmidi,snd_seq_midi_event,snd_seq_midi_emul,snd_seq_midi,snd_emux_synth
max665016384  0
ib_iser49152  0
rdma_cm61440  1 ib_iser
iw_cm  40960  1 rdma_cm
ib_cm  45056  1 rdma_cm
ib_core   200704  4 ib_iser,ib_cm,rdma_cm,iw_cm
configfs   40960  2 rdma_cm
iscsi_tcp  20480  0
libiscsi_tcp   20480  1 iscsi_tcp
libiscsi   57344  3 ib_iser,libiscsi_tcp,iscsi_tcp
scsi_transport_iscsi98304  4 ib_iser,libiscsi,iscsi_tcp
parport_pc 28672  0
ppdev  20480  0
lp 20480  0
parport49152  3 lp,parport_pc,ppdev
ir_lirc_codec  16384  0
lirc_dev   20480  1 ir_lirc_codec
rtl2832_sdr36864  0
videobuf2_vmalloc  16384  1 rtl2832_sdr
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 24576  1 rtl2832_sdr
vide

Bug#861150: maint-guide: Please describe systemd debian/*.service file in section 5

[Boyuan Yang]

Source: maint-guide
Version: 1.2.38
Severity: minor

Debian switched to systemd since Jessie. dh_installinit tool now searches for
debian/*.service files besides debian/*.init and debian/*.default files.

Now that systemd is becoming popular, we should mention such mechanism in the
document.

Thanks!



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#861149: maint-guide: Please remove statements about DEHS service in section 5.22

[Boyuan Yang]

Source: maint-guide
Version: 1.2.38
Severity: minor

Section 5.22 mentioned the DEHS service.

According to https://wiki.debian.org/DEHS, it is closed since 2011. UDD is
being used instead.

Please update that section and remove related statements. Thanks!



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#861148: maint-guide: Please document .buildinfo files in section 6.1

[Boyuan Yang]

Source: maint-guide
Version: 1.2.38
Severity: minor

With patches around reproducible-builds effort merged into Debian packaging
toolchain, a .buildinfo file will appear in the build process.

This file should be mentioned or documented in section 6.1.

Thanks!



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#859384: current behaviour looks correct to me

[Adam Borowski]

> The HOME environment variable does not have to be present, programs
> must fall back to the value in the passwd file. $SHELL does not do this
> in the following two places.
>
>  * When running cd without any argument
>  * When expanding tilde (~) characters

Nope, there's nothing that says they "must" fall back to anything.  The very
docs you linked to:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_01
explicitly say the results are unspecified.  $HOME should be set by the
login environment, but if it's not set, you get to keep the pieces.

You filed copies of this bug on three shells: busybox[sh], dash, bash.
Their policies are:
* busybox: no superfluous features are added, often even required but
  non-important features get skipped
* dash: POSIXLY_CORRECT, even when POSIX and common sense disagree
Upstreams of those two will thus almost certainly reject such a change.
* bash: no particular policy
Yet, because the two other shells don't invent a fallback for missing $HOME,
adding it bash would introduce a difference in behaviour that can be avoided
by keeping status quo.

Thus, while I understand your reason (extra robustness for user error), I'd
recommend WONTFIXing all three copies of this bug.


Please say if I missed something.
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#861147: maint-guide: Please mention sbuild usage in section 6

[Boyuan Yang]

Source: maint-guide
Version: 1.2.38
Severity: wishlist

Sbuild is being used extensively around Debian besides the pbuilder family,
such as official buildd network, the mini-buildd package and so on.

It would be great if that section could mention the existence of sbuild family
(sbuild / sbuild-* / schroot).



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#861146: maint-guide: Please deprecate section 5.17 (debian/menu support)

[Boyuan Yang]

Source: maint-guide
Version: 1.2.38
Severity: normal

As per tech-ctte's decision on #741573, menu files are to be dropped if a
proper desktop file is provided.

Please document such changes and deprecate that section.

Thanks!



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#861145: openssl: SHA Extension routine is not called on new AMD cpu "Ryzen".

[Eric Desrochers]

Package: openssl
Version: 1.1.0e-1
Severity: normal

Dear Maintainer,

[Introduction]

AMD added support in their processors for SHA Extensions[1] (CPU flag: 
sha_ni[2]) starting with Ryzen[3] CPU. 
Note that Ryzen CPU come in 64bit only. Current OpenSSL version in Ryzens still 
calls SHA for SSSE3 routine as result a number of extensions were effectively 
masked on Ryzen and shows no improvement.

[1] /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 1
model name : AMD Ryzen 5 1600 Six-Core Processor
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 
constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni 
pclmulqdq monitor ssse3 fma cx16 sse
4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm 
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce 
topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall 
fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflusho
pt sha_ni xsaveopt xsavec xgetbv1 clzero arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

[2] - sha_ni: SHA1/SHA256 Instruction Extensions

[3] - https://en.wikipedia.org/wiki/Ryzen

All models support: x87, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, 
CLMUL, AVX, AVX2, FMA, CVT16/F16C, ABM, BMI1, BMI2, SHA.[5]


[Program to performs the CPUID check]

Reference :
https://software.intel.com/en-us/articles/intel-sha-extensions

 Availability of the Intel® SHA Extensions on a particular processor can be 
determined by checking the SHA CPUID bit in CPUID.(EAX=07H, ECX=0):EBX.SHA [bit 
29]. The following C function, using inline assembly, performs the CPUID check:

--
int CheckForIntelShaExtensions() {
   int a, b, c, d;

   // Look for CPUID.7.0.EBX[29]
   // EAX = 7, ECX = 0
   a = 7;
   c = 0;

   asm volatile ("cpuid"
:"=a"(a), "=b"(b), "=c"(c), "=d"(d)
:"a"(a), "c"(c)
   );

   // Intel® SHA Extensions feature bit is EBX[29]
   return ((b >> 29) & 1);
}
--

On CPU with sha_ni the program return "1". Otherwise it return "0".

[Upstream work]

- GitHub PR  : 
https://github.com/openssl/openssl/issues/2848 

- Repository : 
https://github.com/openssl/openssl.git

- Commits :
1aed5e1 crypto/x86*cpuid.pl: move extended feature detection.
## This fix moves extended feature detection past basic feature detection where 
it belongs.

f8418d8 crypto/x86_64cpuid.pl: move extended feature detection upwards.
## This commit for x86_64cpuid.pl addressed the problem, but messed up 
processor vendor detection.

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

Kernel: Linux 4.4.0-62-generic (SMP w/8 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#861144: maint-guide: Broken Vcs-Browser field in debian/control

[Boyuan Yang]

Source: maint-guide
Version: 1.2.38
Severity: minor

Good: https://anonscm.debian.org/git/ddp/maint-guide.git
Bad: https://anonscm.debian.org/git/dp/maint-guide.git

Please fix it in the following versions.

Thanks!



-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#851678: jessie-pu: package openchange/1:2.2-6+deb8u1

[Paul Wise]

On Mon, 2017-04-24 at 22:12 +0100, Adam D. Barratt wrote:

> That sounds okay, although I wonder if it's worth mentioning the unusual
> version progression in the changelog.

I've rebuilt the package including this additional changelog entry:

  * Use version -6+ instead of -5+ because samba-libs conflicts with
openchangeproxy (<< 1:2.2-6), making openchangeproxy -5+ uninstallable.

The result has been uploaded and is on its way to pu-new.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#818942: RFP: rein -- Rein client integration/staging tree

[Josue Ortega]

Hi Carlo,

Any advance with this?

I am interested to get this package into Debian, if you need some help with the
packaging let me now, if you need sponsor, I will be glad to upload your
package.

Best Regards

---
Josue Ortega
«Happy Hacking»
http://josueortega.org


signature.asc
Description: PGP signature

Bug#859760: Can't read CJK in tables

[積丹尼 Dan Jacobson]

SC> How can I reproduce the issue?

Press Download.
Select some tiny rectangle in Taiwan, then download it.
Now in Imagery menu, select NLSC Open Data WMTS.
You will see the mangled fonts of the words in the list.

Bug#861083: Fails to boot installed system

[Cyril Brulebois]

Matt Kraai  (2017-04-24):
> On Mon, Apr 24, 2017 at 11:30:26PM +0200, Cyril Brulebois wrote:
> > Matt Kraai  (2017-04-24):
> > > When I install Debian using the Stretch RC 3 release of the Debian
> > > installer on a Dell Inspiron 7348 2-in-1, the installer appears to be
> > > successful.  When I reboot the system and try to boot the installed
> > > system, however, the screen goes black after displaying "Loading
> > > initial ramdisk ..." and nothing else ever appears.  When I press a
> > > key, the keyboard lights up.  When I boot from a rescue disk, there
> > > are no post-installation log files in /var/log.
> > 
> > We're talking about /var/log/installer being missing? That would be a
> > first for me for an installation when the “Installation complete” screen
> > is displayed (that's shown by finish-install).
> 
> Sorry, I wasn't clear enough.  /var/log/installer exists, but there
> aren't any log messages in, say /var/log/messages or /var/log/syslog
> from when I tried to boot the installed system.  I've attached a tar
> file containing the contents of /var/log/installer.

Ah, OK. Thanks for the logs, they look rather good to me…

sda doesn't look like something too tricky:

Apr 24 13:07:58 kernel: [5.681021] ata1.00: configured for UDMA/133
Apr 24 13:07:58 kernel: [5.682381] scsi 0:0:0:0: Direct-Access ATA  
ST500LT012-1DG14 SDM1 PQ: 0 ANSI: 5
Apr 24 13:07:58 kernel: [5.713032] sd 0:0:0:0: [sda] 976773168 512-byte 
logical blocks: (500 GB/466 GiB)
Apr 24 13:07:58 kernel: [5.713035] sd 0:0:0:0: [sda] 4096-byte physical 
blocks
Apr 24 13:07:58 kernel: [5.713133] sd 0:0:0:0: [sda] Write Protect is 
off
Apr 24 13:07:58 kernel: [5.713136] sd 0:0:0:0: [sda] Mode Sense: 00 3a 
00 00
Apr 24 13:07:58 kernel: [5.713179] sd 0:0:0:0: [sda] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA
Apr 24 13:07:58 kernel: [5.775904]  sda: sda1 sda2 < sda5 >

Did you try some kernel command line parameters, like enabling debug,
disabling quiet, maybe disabling modesetting? You could also try adding
netconsole parameters to send kernel messages elsewhere if you're
getting no output at all.

Differences between installation and installed systems include: plain
init versus systemd, fbdev being used for Xorg in d-i; also, sometimes,
some modules are missing from the initrd because initramfs-tools didn't
include them (while d-i uses different codepaths to enable hardware
support). I assume yours is using the default MODULES=most anyway
(unless you tweaked it)?


KiBi.


signature.asc
Description: Digital signature

Bug#861143: ITP: hddemux -- An HTTP and DNS demultiplexer

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: hddemux
  Version : 0.1
  Upstream Author : Daniel Kahn Gillmor 
* URL : https://0xacab.org/dkg/hddemux
* License : GPL
  Programming Lang: C
  Description : An HTTP and DNS demultiplexer

hddemux listens on a stream and routes incoming clients to either an
HTTP backend or a DNS stream-based backend depending on the first
request to appear on the stream.

This is useful when making DNS-over-TLS (RFC 7858) connections that
appear to the network be HTTPS connections, for example, which makes
it easier to traverse a network that would prefer to block the user
from making DNS-over-TLS queries.

Bug#861127: RFP: elpa-multiple-cursors -- Multiple cursors for emacs.

[Antoine Beaupré]

On 2017-04-24 13:39:02, Sean Whitton wrote:
> Hello Antoine,
>
> On Mon, Apr 24, 2017 at 04:18:30PM -0400, Antoine Beaupre wrote:
>> As far as I know, there's nothing like it.
>
> The built-in support for keyboard macros is really the same thing.

Not for me it's not. :) Keyboard macros are different: they execute in
serial (multiple-cursors is in parallel) and they are "invisible",
non-interactive, which makes them harder to design and, to a certain
extend, therefore less flexible.

I still use keyboard macros for certain things, mind you, but for simple
stuff, mc is great.

> You should feel free to join the pkg-emacsen team on alioth and get
> these packaged :)

Yep, I'll probably just do that soon enough. :)

a.
-- 
If I can't dance, I don't want to be part of your revolution.
- Emma Goldman

Bug#861125: RFP: elpa-writegood-mode -- Minor mode for Emacs to improve English writing

[Nicholas D Steeves]

control: -1 owner
control: -1 retitle ITP: elpa-writegood-mode -- Minor mode for Emacs to improve 
English writing

Hi Antoine,

I'll do this one too, because it's something I'm interested in and
wish I had had as an undergrad.  Y-a-t'il une version française?
C'est quelque dont j'apprécierais énormément!

Cordially,
Nicholas


signature.asc
Description: Digital signature

Bug#861124: RFP: elpa-writeroom-mode -- distraction-free writing for Emacs

[Nicholas D Steeves]

control: owner -1
control: retitle -1 ITP: elpa-writeroom-mode -- distraction-free writing for 
Emacs

Hi Antoine,

I've been using a moderately customised local copy of writeroom-mode
forked from upstream many years ago, so of course I'd love to maintain
an official elpafied Debian package of it. :-)

How responsive is upstream to patches?  I find it really useful to
remove the fringes and margins when going from fullscreen to windowed,
and to have modeline enabled for fullscreen, for battery status,
clock, word count, etc, but to have these disabled for windowed.  One
of my other little personal projects is to change the font size when
going between windowed and fullscreen.  Do you know if tiling WMs
provide the necessary netwm hints for these to work properly?

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#861142: thunar: Problem bulk renaming photos by hour

[Marco]

Package: thunar
Version: 1.6.11-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Trying to rename a series of pictures, by date and time, with Thunar Bulk 
Rename. 

Typically, the hour is wrong, and the pictures end up unsorted. 

If you open the file properties, you can see that the actual time of the photo 
is correct, so Thunar Bulk Rename fails to extract the correct hour out of the 
file. 

It doesn't do with every file. Some files are incorrectly renamed.

Format used: %Y-%m-%d_%H-%M-%S_(ORIGINAL FILE NAME).JPG

Date and time from when the picture was taken.



-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-9
ii  libcairo2   1.14.8-1
ii  libdbus-1-3 1.10.18-1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-1+b1
ii  libpango-1.0-0  1.40.5-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.11-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1
ii  thunar-data 1.6.11-1

Versions of packages thunar recommends:
ii  dbus-x11 [dbus-session-bus]  1.10.18-1
ii  gvfs 1.30.4-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  thunar-volman0.8.1-2
ii  tumbler  0.1.31-2+b3
ii  xdg-user-dirs0.15-2+b1
ii  xfce4-panel  4.12.1-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#689508: ignore obsolete conffiles which are not owned by the package

[Axel Beckert]

Control: tag -1 - help + moreinfo

Hi Andreas,

thanks for the prompt feedback.

Andreas Beckmann wrote:
> On 2017-04-25 01:25, Axel Beckert wrote:
> > Holger suggested recently on IRC to try get that patch of yours to
> > Stretch.
> 
> I've been running debsums with that patch on my piuparts instance since
> I posted it, and it helped reducing weird errors (rerunning all the
> strange logs) :-)
> So I'm all for seeing it in stretch :-)

Ok, will work towards that.

> > Is the above an indicator for not doing so or rather showing how
> > important it would be? Can't tell, sorry.
> 
> It's a possible regression ... in a corner case and so far it only
> happened in a buggy package. Maybe it even revealed that buggy package.
> If it shows up elsewhere as a real regression, I'll dig further into it.

Ok.

Below is a suggested patch for a variant where the ignoring of
obsolete conffiles can be disabled with a commandline option.

I'd be very happy if you could test this patch on a known case and
tell me

A) if it is compatible with your patch (i.e. I didn't introduce a
   regression when adding the option)
B) turning this setting off really works as documented.

I'm currently doing these modifications in a feature branch at
https://anonscm.debian.org/cgit/pkg-perl/packages/debsums.git/log/?h=ignore-obsolete-689508
(There you'll also find the updated man page.)

The patch:

diff --git a/debsums b/debsums
index faee262..6043a1e 100755
--- a/debsums
+++ b/debsums
@@ -78,6 +78,7 @@ Options:
   is configured
  --no-prelink report changed ELF files even if prelink is
   configured
+ --no-ignore-obsolete don't ignore obsolete conffiles.
  --help   print this help, then exit
  --versionprint version number, then exit
 EOT
@@ -98,6 +99,7 @@ GetOptions (
 'locale-purge!'=> \my $localepurge,
 'prelink!' => \my $prelink,
 'ignore-permissions' => \my $ignore_permissions,
+'ignore-obsolete!'  => \my $ignore_obsolete,
 g  => sub { $gen_opt = 'missing' },
 help   => sub { print $help; exit },
 version=> sub { print version_info(); exit },
@@ -206,6 +208,9 @@ if (!defined $prelink or $prelink)
 ($prelink) = grep -x, map +("$_.bin", $_), '/usr/sbin/prelink';
 }
 
+# default is to use ignore obsolete conffiles, see #689508
+$ignore_obsolete = 1 unless defined $ignore_obsolete;
+
 $silent++ if $changed;
 
 my @debpath = '.';
@@ -262,7 +267,9 @@ my %replaced;
 $package_name{$field{"Package"}} = $field{"binary:Package"};
 }
 $installed{$field{"binary:Package"}}{Conffiles} = {
-map m!^\s*/(\S+)\s+([\da-f]+)!, split /\n/, $field{Conffiles}
+map m!^\s*/(\S+)\s+([\da-f]+)!,
+grep { not ($ignore_obsolete and / obsolete$/) }
+split /\n/, $field{Conffiles}
 } if $field{Conffiles};
 
 for (split /,\s*/, $field{Replaces})

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#843943: debian-cd: please mention the dinstall serial in a trace file

[Cyril Brulebois]

Steve McIntyre  (2017-04-25):
> Looks good (ish!) The code's fine, but I'll move it to the setup.git
> repo. The code in debian-cd/contrib is just a convenience copy for
> publishing what we do in the package.

Alright, thanks!

> >> Also, as as side question, do we prevent the mirror from being updated
> >> during the n-hours build of all images?
> >
> >Answer welcome. :)
> 
> Nope. For any given architecture build, we do ~all the parsing
> up-front so it's going to be consistent. But from one arch to the next
> it's possible that things will update.

It looks good enough, yeah; at least it seems to have worked just fine
so far. :-)

Thanks again.


KiBi.


signature.asc
Description: Digital signature

Bug#843943: debian-cd: please mention the dinstall serial in a trace file

[Steve McIntyre]

On Thu, Apr 13, 2017 at 02:43:24PM +0200, Cyril Brulebois wrote:
>Cyril Brulebois  (2016-11-11):
>> Since pettersson has a mirror with project/trace, which gives us access
>> to archive serial, it would be nice to have a look when the build starts
>> and to report this, maybe in a trace file alongside cdimage.debian.org?
>
>Here's a prospective and untested patch.
>
>ISTR we (ab)use cronjob.weekly for release builds, but feel free to
>test/adjust before pushing to the repository.

Looks good (ish!) The code's fine, but I'll move it to the setup.git
repo. The code in debian-cd/contrib is just a convenience copy for
publishing what we do in the package.

>> Also, as as side question, do we prevent the mirror from being updated
>> during the n-hours build of all images?
>
>Answer welcome. :)

Nope. For any given architecture build, we do ~all the parsing
up-front so it's going to be consistent. But from one arch to the next
it's possible that things will update.


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#689508: ignore obsolete conffiles which are not owned by the package

[Andreas Beckmann]

On 2017-04-25 01:25, Axel Beckert wrote:
> Holger suggested recently on IRC to try get that patch of yours to
> Stretch.

I've been running debsums with that patch on my piuparts instance since
I posted it, and it helped reducing weird errors (rerunning all the
strange logs) :-)
So I'm all for seeing it in stretch :-)

> Is the above an indicator for not doing so or rather showing how
> important it would be? Can't tell, sorry.

It's a possible regression ... in a corner case and so far it only
happened in a buggy package. Maybe it even revealed that buggy package.
If it shows up elsewhere as a real regression, I'll dig further into it.


Andreas

Bug#861057: Today I suddenly see swap warning

[積丹尼 Dan Jacobson]

Today I suddenly see:

Processing triggers for initramfs-tools (0.129) ...
update-initramfs: Generating /boot/initrd.img-4.9.0-2-amd64
W: initramfs-tools configuration sets 
RESUME=UUID=eff505d5-d5bf-4bba-8a07-f3d0d11018b9
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/sda9
I: (UUID=eff505d5-d5bf-4bba-8a07-f3d0d11018b9)
I: Set the RESUME variable to override this.
Processing triggers for libc-bin (2.24-10) ...
Processing triggers for menu (2.1.47+b1) ...

I have never messed with any of this.

Bug#689508: ignore obsolete conffiles which are not owned by the package

[Axel Beckert]

Hi Andreas,

Andreas Beckmann wrote:
> On 2017-04-21 02:20, Andreas Beckmann wrote:
> > The attached patch unconditionally excludes all obsolete conffiles.
> > Maybe that is not the optimal approach and a new command line option
> > should be used instead (and then we could discuss whether obsolete
> > conffiles should be ignored by default - I would say yes).
> 
> I don't know if this was now caused by my patch or if it happened
> before, but I've just seen this error (see #861136 for the piuparts log):
> 
> 1m58.2s ERROR: FAIL: debsums reports modifications inside the chroot:
>   /var/lib/dpkg/info/inn2-lfs.md5sums is empty but shouldn't!
> 
> At this point, the package owned
> * an obsolete conffile
> * a symlink /usr/share/doc/package -> target
> * the directories up to /usr/share/doc
> * but no regular files

Thanks for the details.

Holger suggested recently on IRC to try get that patch of yours to
Stretch.

Is the above an indicator for not doing so or rather showing how
important it would be? Can't tell, sorry.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#860923: src:dask: New upstream release

[Diane Trout]

Hello,

> > I'm pretty busy, so if you want to do it feel free, otherwise I
> > might
> > be able to get to it tongiht.
> 
> I can have a go at it during the week.

I had some free time while waiting for see if some multi-hours jobs to
are going to crash, and sortedcollections is pretty tiny, so I'm almost
done packaging it.



> I just wanted to be sure you were ok with me pushing heavier changes 
> than the little fixups I recently comitted.

As long as I know its happening and its being done by someone who knows
what they're doing its fine. (I peeked at a few of your other packages
first)

Though which package did you update? I tried fetching and didn't see
any new commits to dask or dask.distributed?

Do you know if there any easy of getting commit messages for packages
you're an uploader for?

Diane

Bug#861141: enchant: New upstream release (1.6.1)

[Laurent Bigonville]

Source: enchant
Version: 1.6.0-11
Severity: wishlist

Hi,

It seems that the upstream website has moved to
https://abiword.github.io/enchant/

There is a new release there:

1.6.1 (February 6, 2017)


Improvements to the enchant-ispell front-end, which is now a working ispell 
replacement.
Unit tests run on all platforms.
Various bug fixes and code clean-up.

Would be a good idea to package it I guess.

Regards,

Laurent Bigonville

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#861140: ITP: sortedcollections -- Python 3 Sorted Collections

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 

* Package name: sortedcollections
  Version : 0.5.3
  Upstream Author : Grant Jenks 
* URL : http://www.grantjenks.com/docs/sortedcollections/
* License : Apache-2.0
  Programming Lang: Python
  Description : Python 3 Sorted Collections

 SortedCollections is an Apache2 licensed Python sorted collections library.
 .
 Features
 
 .
   - Pure-Python
   - Depends on the SortedContainers module.
   - ValueSortedDict - Dictionary with (key, value) item pairs sorted by value.
   - ItemSortedDict - Dictionary with key-function support for item pairs.
   - OrderedDict - Ordered dictionary with numeric indexing support.
   - OrderedSet - Ordered set with numeric indexing support.
   - IndexableDict - Dictionary with numeric indexing support.
   - IndexableSet - Set with numeric indexing support.
 .
 This contains the Python 3 module

sortedcollections is a recently addeded dependency of dask.distributed.

Bug#825685: (no subject)

[Pablo Barciela]

Urmas, the bug you mentioned was already reported here:

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

Bug#861139: RFP: python-qt4 (with missing QtMultimedia module)

[Maurizio Berti]

Package: python-qt4
Severity: wishlist

QtMultimedia module is not installed by python-qt4, presumably because
previously the module has been moved a lot around by Qt development.
According to the following link, the module has been moved from Qt to
QtMobility, then renamed QtMultimediaKit.
https://bugs.launchpad.net/ubuntu/+source/python-qt4/+bug/590140

Unfortunally, I can't give much more information, I've written a PyQt4
based program that partly uses QtMultimedia, and today I received a report
about this.

Thanks

Bug#689508: ignore obsolete conffiles which are not owned by the package

[Andreas Beckmann]

On 2017-04-21 02:20, Andreas Beckmann wrote:
> The attached patch unconditionally excludes all obsolete conffiles.
> Maybe that is not the optimal approach and a new command line option
> should be used instead (and then we could discuss whether obsolete
> conffiles should be ignored by default - I would say yes).

I don't know if this was now caused by my patch or if it happened
before, but I've just seen this error (see #861136 for the piuparts log):

1m58.2s ERROR: FAIL: debsums reports modifications inside the chroot:
  /var/lib/dpkg/info/inn2-lfs.md5sums is empty but shouldn't!

At this point, the package owned
* an obsolete conffile
* a symlink /usr/share/doc/package -> target
* the directories up to /usr/share/doc
* but no regular files


Andreas

Bug#861137: xwindows crashes on startup with display with bad edid checksum

[Kenneth Howlett]

Package: xserver-xorg-video-nouveau
Version: 1.0.13-2

I installed amd64 stretch. When I booted into stretch for the first time,
it displayed some messages saying the EDID checksum was bad, then there was
a black screen with an arrow shaped cursor in the center. The computer did
not respond to the keyboard or mouse. I could not change to a different
virtual terminal. No login prompt was displayed, so the crash probably
occurred before the login prompt. Control-alternate-delete and
control-alternate-backspace had no effect.

The computer is hp pavilion a6110n with amd 64 bit cpu. Display 
controller is:


00:0d.0 VGA compatible controller [0300]: nVidia Corporation C61 
[GeForce 6150SE nForce 430] [10de:03d0] (rev a2)

Subsystem: Hewlett-Packard Company Device [103c:2a58]

The display has an invalid edid checksum. The display works fine
with any software which ignores the edid checksum.  In fedora 13, I have
been using the xorg nvidia driver which accepts option IgnoreEDIDChecksum in
xorg.conf, and the display works perfectly.

Stretch crashes in the same manner in recovery mode.

Adding kernel boot parameters nomodeset nouveau.modeset=0 caused stretch to
crash earlier in the boot process. The last message displayed on the screen
was KVM: disabled by bios.

Adding kernel boot parameters edid_strict=0 drm_edid_strict=0 
drm.edid_strict=0

had no effect. This option is for a proposed kernel patch at
https://lists.freedesktop.org/archives/dri-devel/2011-January/006778.html.
I do not know if that proposed kernel patch was ever accepted into the
kernel, and do not know the exact syntax, but I figured it would not hurt
to try.

Adding kernel boot parameter drm_kms_helper.edid_firmware=edid/1024x768.bin
had no effect.

Adding kernel boot parameter drm_kms_helper.edid_firmware=edid/1680x1050.bin
resulted in smaller text in the displayed error messages, but otherwise
stretch crashed the same.

I tried kernel boot parameter drm_kms_helper.edid_firmware=edid.bin.
/lib/firmware/edid.bin was a file created by the write edid to file function
of the nvidia utilities on fedora 13. This resulted in an error message
saying base block of edid firmware is invalid. I do not know if the edid
file generated by nvidia utilities is the correct format for the kernel. I
tried generating another edid file with get-edid, but get-edid failed.

I borrowed a display from a different computer, and stretch xwindows ran ok.

/var/log/syslog from the first boot to the first crash:
Apr 16 14:32:49 hpx2 systemd[1]: Started Create list of required static 
device nodes for the current kernel.
Apr 16 14:32:49 hpx2 systemd[1]: Starting Create Static Device Nodes in 
/dev...

Apr 16 14:32:49 hpx2 systemd-modules-load[215]: Inserted module 'lp'
Apr 16 14:32:49 hpx2 systemd-modules-load[215]: Inserted module 'ppdev'
Apr 16 14:32:49 hpx2 systemd-modules-load[215]: Inserted module 'parport_pc'
Apr 16 14:32:49 hpx2 systemd[1]: Started Load Kernel Modules.
Apr 16 14:32:49 hpx2 systemd[1]: Starting Apply Kernel Variables...
Apr 16 14:32:49 hpx2 systemd[1]: Mounted Huge Pages File System.
Apr 16 14:32:49 hpx2 systemd[1]: Mounted POSIX Message Queue File System.
Apr 16 14:32:49 hpx2 systemd[1]: Mounted Debug File System.
Apr 16 14:32:49 hpx2 systemd[1]: Started Remount Root and Kernel File 
Systems.

Apr 16 14:32:49 hpx2 systemd[1]: Starting Load/Save Random Seed...
Apr 16 14:32:49 hpx2 systemd[1]: Starting Flush Journal to Persistent 
Storage...

Apr 16 14:32:49 hpx2 systemd[1]: Starting udev Coldplug all Devices...
Apr 16 14:32:49 hpx2 systemd[1]: Started Apply Kernel Variables.
Apr 16 14:32:49 hpx2 systemd[1]: Started Load/Save Random Seed.
Apr 16 14:32:49 hpx2 systemd[1]: Started Flush Journal to Persistent 
Storage.

Apr 16 14:32:49 hpx2 systemd[1]: Started udev Coldplug all Devices.
Apr 16 14:32:49 hpx2 systemd[1]: Started Set the console keyboard layout.
Apr 16 14:32:49 hpx2 systemd[1]: Started Create Static Device Nodes in /dev.
Apr 16 14:32:49 hpx2 systemd[1]: Reached target Local File Systems (Pre).
Apr 16 14:32:49 hpx2 systemd[1]: Reached target Local File Systems.
Apr 16 14:32:49 hpx2 systemd[1]: Starting Set console font and keymap...
Apr 16 14:32:49 hpx2 systemd[1]: Starting Create Volatile Files and 
Directories...

Apr 16 14:32:49 hpx2 systemd[1]: Starting Raise network interfaces...
Apr 16 14:32:49 hpx2 systemd[1]: Starting udev Kernel Device Manager...
Apr 16 14:32:49 hpx2 systemd[1]: Started Set console font and keymap.
Apr 16 14:32:49 hpx2 systemd[1]: Started Create Volatile Files and 
Directories.

Apr 16 14:32:49 hpx2 systemd[1]: Starting Network Time Synchronization...
Apr 16 14:32:49 hpx2 systemd[1]: Starting Update UTMP about System 
Boot/Shutdown...
Apr 16 14:32:49 hpx2 systemd[1]: Started Update UTMP about System 
Boot/Shutdown.

Apr 16 14:32:49 hpx2 systemd[1]: Started Network Time Synchronization.
Apr 16 14:32:49 hpx2 systemd[1]: Reached target System Time Synchronized.
Apr 16 14:32:49 hpx2 systemd[1]: Reloading.
Apr 16 14:3

Bug#861136: inn2-lfs: radius.conf to inn-radius.conf migration never worked

[Andreas Beckmann]

Package: inn2-lfs
Version: 2.6.1-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed a strange error from debsums
after an upgrade in i386 from wheezy to jessie to stretch.

>From the attached log (scroll to the bottom...):

1m58.2s ERROR: FAIL: debsums reports modifications inside the chroot:
  /var/lib/dpkg/info/inn2-lfs.md5sums is empty but shouldn't!


Investigating this a bit further showed that inn2-lfs is still owning
the obsolete conffile /etc/news/radius.conf (so debsums seems to be
a bit wrong here, too).

Unfortunately all the migration code was never run since it used a wrong
version (2.5.3-3~) that predates wheezy (which has 2.5.3-3), so the
dpkg-maintscript-helper calls were all skipped during the upgrade from
wheezy to jessie.

Given that it is now too late to fix that for jessie, (and we wouldn't
want to "downgrade" *now* to the old conffile from wheezy in stretch),
I'd suggest to add for stretch
  dpkg-maintscript-helper rm_conffile /etc/news/radius.conf 2.6.1-3~ -- "$@"
(assuming you are uploading that as 2.6.1-3)
That will kill the unmodified conffile, but keep a backup in case
it had modifications.

Usually the transitional package could be removed by now (it has been
in jessie already), but given the "special" nature of this package ...


cheers,

Andreas


inn2-lfs_2.6.1-2.log.gz
Description: application/gzip

Bug#798430: M.oi.com.br

[alcione linhares domingues]

Enviado pelo meu Windows Phone

Bug#861135: qml-module-qtquick-controls2: should depend on templates

[Salvo Tomaselli]

Package: qml-module-qtquick-controls2
Version: 5.7.1-1
Severity: normal

Dear Maintainer,

I got this qml error:

file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/Label.qml:38 module 
"QtQuick.Templates" is not installed

so probably the package should depend on qml-module-qtquick-templates2

best

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages qml-module-qtquick-controls2 depends on:
ii  libc6 2.24-10
ii  libqt5core5a [qtbase-abi-5-7-1]   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5qml5 [qtdeclarative-abi-5-7-0]  5.7.1-2+b2
ii  libqt5quick5  5.7.1-2+b2
ii  libqt5quickcontrols2-55.7.1-1
ii  libqt5quicktemplates2-5   5.7.1-1
ii  libstdc++66.3.0-14

qml-module-qtquick-controls2 recommends no packages.

qml-module-qtquick-controls2 suggests no packages.

-- no debconf information

Bug#861134: slim: Reloads automatically and queries login-prompt after running window manager for some (a short) time

[Gordon Shumway]

Package: slim
Version: 1.3.6-5
Severity: important

Dear Maintainer,

   * Slim has been set up as the default display manager
   * After running the Window Manager (XFCE in my case) and working with
   it causes a sudden reload of Slim and (re-)querying the login prompt
   * So there is a login-prompt query over and over again

-- System Information:
Debian Release: 9.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: i386
 (i686)

Kernel: Linux 4.9.0-2-686-pae (SMP w/2 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 slim depends on:
ii  dbus   1.10.18-1
ii  debconf [debconf-2.0]  1.5.60
ii  libc6  2.24-10
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.1
ii  libgcc11:7-20161115-1
ii  libjpeg62-turbo1:1.5.1-2
ii  libpam0g   1.1.8-3.5
ii  libpng16-161.6.28-1
ii  libstdc++6 7-20161115-1
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxft22.3.2-1+b2
ii  libxmu62:1.1.2-2
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages slim recommends:
ii  xterm  327-2

Versions of packages slim suggests:
pn  scrot  
ii  xauth  1:1.0.9-1+b2

-- debconf information excluded

Bug#861098: Package Build

[Leonhard Weber]

Watched upstream location (PyPI) provides a strips away runtest.py
amongst other things. You had it pointing to GitHub temporarily? Looking
at those packages, they release the full source release.



signature.asc
Description: OpenPGP digital signature

Bug#861025: "sangs" should not be in the English dictionary

[Don Armstrong]

Control: retitle -1 sangs should be no lower than -80, probably -95, not -35
Control: tag -1 pending

On Sun, 23 Apr 2017, Josh Triplett wrote:
> The English dictionary includes the word "sangs". I can't find any
> evidence suggesting that this is a word in English, based on several
> different dictionaries. ("sang" is a word, but not one with a plural
> like that.)

Apparently, sang is the common name for /Panax quinquefolius/, and its
plural is sangs.

However, that's so obscure that it while it's reasonable to be in
-insane or possibly -huge, it definitely should not be in -35 where it
is currently.

https://git.donarmstrong.com/deb_pkgs/scowl.git/c/4d4ec is the fix for it.

-- 
Don Armstrong  https://www.donarmstrong.com

I'm wrong to criticize the valor of your brave men. It's important to
die for one's country when it means being the subject of a king who
wears a ruffled collar or a pleated one.
 -- Cyrano de Bergerac

Bug#857925: Issue is now irrelevant

[Boom Zoom]

After the release of 58.0.3029.81-1, this issue is no longer relevant, so
can be closed.

Bug#860819: piuparts(.d.o): detect_network_issues always finds issues in systemd-sysv and upstart…

[Andreas Beckmann]

On 2017-04-20 17:45, Holger Levsen wrote:
> - they both fail with "E: Version '2.88dsf-59' for 'sysvinit' was not found"

726669c38 post_distupgrade_base_cleanup: remove sysvinit from stretch


Andreas

Bug#860340: fancontrol: please add configuration file

[Aurelien Jarno]

control: tag -1 + wontfix

On 2017-04-16 09:07, Hans-J. Ullrich wrote:
> Package: fancontrol
> Version: 1:3.4.0-4
> Followup-For: Bug #860340
> 
> Dear Maintainer,
> 
> if you are willing to add a default configuration to fancontrol or maybe 
> better, build a package for EEEPC maybe names fancontrol-eeepc, here is my 
> improved /etc/fancontrol. This is working well for live-file-cd's as long
> as there are no related entries in /etc/modules. 

As said in the other mail, we are not going to handle the thousand of
machines who need fancontrol, and create one package for each of them,
with the risk of overheating hardware.

As there is already an eeepc-acpi-scripts package, maybe it can be added
there?

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#860686: [Android-tools-devel] Bug#860686: android-platform-external-doclava: FTBFS on i386: java.lang.StackOverflowError

[Hans-Christoph Steiner]

my guess is that this rebuild was done with limited RAM, since the
failure is:

"The system is out of resources."

Bug#860923: src:dask: New upstream release

[Ghislain Vaillant]

On 24/04/17 22:46, Diane Trout wrote:

On Mon, 2017-04-24 at 22:35 +0100, Ghislain Vaillant wrote:

On 24/04/17 22:26, Ghislain Vaillant wrote:

On 24/04/17 20:34, Diane Trout wrote:

I discovered dask.distributed added a dependency on a package not
in
Debian "sortedcollections" so I'll need to add that


We have sortedcontainers, so perhaps it would be worth
investigating
whether the dependency on sortedcollections can be substituted. The
former looks more mature and is already packaged, which is a plus.


Hang on, actually I might need what sortedcollections provides for
another package I have ITP'd. So, it might be well worth packaging.

Shall I do it, or do you want to go for it?


I'm pretty busy, so if you want to do it feel free, otherwise I might
be able to get to it tongiht.


I can have a go at it during the week.


Also if you want to help with dask that'd also be good. I'm following
the python teams git-dpm workflow

https://wiki.debian.org/Python/GitPackaging


Which we will eventually drop in favor of gbp soon, but that's fine for 
now (I am familiar with both).


I just wanted to be sure you were ok with me pushing heavier changes 
than the little fixups I recently comitted.


Ghis

Bug#860340: fancontrol: please add configuration file

[Aurelien Jarno]

On 2017-04-14 21:10, Hans-J. Ullrich wrote:
> Package: fancontrol
> Version: 1:3.4.0-4
> Severity: wishlist
> 
> Dear Maintainer,
> 
> it would be nice, if you could add a default configuration file 
> (/etc/fancontrol) to the package.

This not something possible, actually each machine needs a different
configuration file. We do not want to handle the thousands of different
configuration which exists in the work, and additionally they might
actually conflict and thus break hardware.

> This is useful, when used in livefile systems. In my case, I am regularly 
> building a kali livefile dvd
> for my EEEPC, who needs fancontrol and eeepc-acpi-scripts (so fancontrol or 
> eeepc-acpi-scripts should have the related dependency). 
> After install, it is necessary to use pwmconfig, to create /etc/fancontrol. 
> Without it, the fan will not run,
> and the cpu can be overheated. 
> 
> So, the solution is the following:
> 
> 1. Build the livefile with the command "acpi_osi=Linux" at grub (my part)
> 2. Take care of installing fancontrol and eeepc-acpi-scripts (my part)
> 3. Create /etc/fancontrol at installation (your part)

If your live CD is specific to EEEPC, why can't you actually include it
as part of the live CD creation in the step 3?

> If you like, you can use mine for example, it is running fine on EEEPC.
> 
> Here it is:
> 
> -
> 
> # Configuration file generated by pwmconfig, changes will be lost
> INTERVAL=5
> DEVPATH=hwmon0= hwmon2=devices/platform/eeepc
> DEVNAME=hwmon0=acpitz hwmon2=eeepc
> FCTEMPS= hwmon2/pwm1=hwmon0/temp1_input
> FCFANS= hwmon2/pwm1=
> MINTEMP= hwmon2/pwm1=55
> MAXTEMP= hwmon2/pwm1=65
> MINSTART= hwmon2/pwm1=50
> MINSTOP= hwmon2/pwm1=35
> MINPWM= hwmon2/pwm1=0
> MAXPWM= hwmon2/pwm1=255

As said above, this is specific to an EEEPC machine, or even one variant
of a EEEPC. At best it will make fancontrol to fail to start on all
non-EEEPC machine. At worst it might be incompatible with some other 
variants of EEEPC.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#860923: src:dask: New upstream release

[Diane Trout]

On Mon, 2017-04-24 at 22:35 +0100, Ghislain Vaillant wrote:
> On 24/04/17 22:26, Ghislain Vaillant wrote:
> > On 24/04/17 20:34, Diane Trout wrote:
> > > I discovered dask.distributed added a dependency on a package not
> > > in
> > > Debian "sortedcollections" so I'll need to add that
> > 
> > We have sortedcontainers, so perhaps it would be worth
> > investigating
> > whether the dependency on sortedcollections can be substituted. The
> > former looks more mature and is already packaged, which is a plus.
> 
> Hang on, actually I might need what sortedcollections provides for 
> another package I have ITP'd. So, it might be well worth packaging.
> 
> Shall I do it, or do you want to go for it?

I'm pretty busy, so if you want to do it feel free, otherwise I might
be able to get to it tongiht.

Also if you want to help with dask that'd also be good. I'm following
the python teams git-dpm workflow

https://wiki.debian.org/Python/GitPackaging

Diane

Bug#860980: libevdev-dev depends on libjs-jquery

[Stephen Kitt]

Hi Nathaniel,

On Sat, 22 Apr 2017 20:01:01 -0800, Nathaniel Chapman
 wrote:
>While trying to install libevdev-dev on a a commandline system
> (raspberry pi), I noticed that it depends on libjs-jquery. This seems
> inappropriate, and I could find no reason as to why this was set as a
> dependency, unless it is using that to generate documentation?

It’s used by the documentation: the HTML files use jQuery for some of their
functionality.

> The dependency also appears at
> https://packages.debian.org/jessie/libevdev-dev Is this as it's supposed to
> be?

That is at it’s supposed to be, packages.debian.org reflects the packages’
metadata.

Given the size of the documentation, I’ll split the package up into -dev and
-doc packages, which will fix the issue (but only in the next release of
Debian).

Regards,

Stephen


pgphIcNjjFb7R.pgp
Description: OpenPGP digital signature

Bug#861133: tf: please make the build reproducible

[Chris Lamb]

Source: tf
Version: 1:4.0s1-19
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: uname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that tf could not be built reproducibly as it embeds the output
of uname.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/debian-changes 2017-04-24 22:32:39.474929808 +0100
--- b/debian/patches/debian-changes 2017-04-24 22:42:05.953741865 +0100
@@ -855,16 +855,22 @@
  ### Stripping.
 --- tf-4.0s1.orig/unix/tfconfig
 +++ tf-4.0s1/unix/tfconfig
-@@ -66,7 +66,7 @@ X=''
+@@ -66,8 +66,12 @@ X=''
  if [ -z "$USER" ]; then USER=$LOGNAME; fi
  export USER
  
 -UNAME=`{ uname -s && uname -v && uname -r || uname -a; } 2>/dev/null`
+-echo "#define UNAME " \"$UNAME\" >&4
 +UNAME=`{ uname -smo; } 2>/dev/null`
- echo "#define UNAME " \"$UNAME\" >&4
++if test -n "$SOURCE_DATE_EPOCH"; then
++echo "#define UNAME \"\"" >&4
++else
++echo "#define UNAME " \"$UNAME\" >&4
++fi
  case "$UNAME" in
  "SunOS 5.4")
  
--- a/unix/tfconfig 2017-04-24 22:32:39.474929808 +0100
--- b/unix/tfconfig 2017-04-24 22:42:08.865755086 +0100
@@ -67,7 +67,11 @@
 export USER
 
 UNAME=`{ uname -smo; } 2>/dev/null`
-echo "#define UNAME " \"$UNAME\" >&4
+if test -n "$SOURCE_DATE_EPOCH"; then
+echo "#define UNAME \"\"" >&4
+else
+echo "#define UNAME " \"$UNAME\" >&4
+fi
 case "$UNAME" in
 "SunOS 5.4")
 echo "#define SUNOS_5_4" >&4

Bug#860921: RFS on hold

[Ghislain Vaillant]

control: tags -1 moreinfo

Putting this RFS on hold, as sortedcollections might provide the same 
functionality and is required elsewhere.


Ghis

Bug#860923: src:dask: New upstream release

[Ghislain Vaillant]

On 24/04/17 22:26, Ghislain Vaillant wrote:

On 24/04/17 20:34, Diane Trout wrote:

I discovered dask.distributed added a dependency on a package not in
Debian "sortedcollections" so I'll need to add that


We have sortedcontainers, so perhaps it would be worth investigating
whether the dependency on sortedcollections can be substituted. The
former looks more mature and is already packaged, which is a plus.


Hang on, actually I might need what sortedcollections provides for 
another package I have ITP'd. So, it might be well worth packaging.


Shall I do it, or do you want to go for it?

Ghis

Bug#861083: Fails to boot installed system

[Cyril Brulebois]

Matt Kraai  (2017-04-24):
> When I install Debian using the Stretch RC 3 release of the Debian
> installer on a Dell Inspiron 7348 2-in-1, the installer appears to be
> successful.  When I reboot the system and try to boot the installed
> system, however, the screen goes black after displaying "Loading
> initial ramdisk ..." and nothing else ever appears.  When I press a
> key, the keyboard lights up.  When I boot from a rescue disk, there
> are no post-installation log files in /var/log.

We're talking about /var/log/installer being missing? That would be a
first for me for an installation when the “Installation complete” screen
is displayed (that's shown by finish-install).

> I'd be happy to provide any more information that I can.

If there are really no logs after installation, maybe you could redo the
installation, check what's in /target/var/log/installer when that screen
is displayed, and save dmesg/syslog before rebooting?

Good luck.


KiBi.


signature.asc
Description: Digital signature

Bug#860923: src:dask: New upstream release

[Ghislain Vaillant]

On 24/04/17 20:34, Diane Trout wrote:

On Fri, 2017-04-21 at 23:08 +0100, Ghislain Antony Vaillant wrote:

Package: src:dask
Severity: wishlist

Dear Maintainer,

A new version of Dask is out (0.14.1) and is required for the latest
version of src:python-xarray. Please consider updating the packaging.

Thanks,
Ghis


I'm looking into it.


Great, thanks.


Dask 1.14's tests throws a few errors with distributed 1.14, and the
setup.py declares a dependency on distributed 1.16. I think I need a
breaks or conflicts in the dask 1.14 packaging against the older
dask.distributed package.


Perhaps a solution could be to use DEB_BUILD_PROFILES to simplify the 
bootstrapping of the Dask packages, since both depends on each other 
only for the testing stage, which can be disabled with the nocheck build 
profile.



I discovered dask.distributed added a dependency on a package not in
Debian "sortedcollections" so I'll need to add that


We have sortedcontainers, so perhaps it would be worth investigating 
whether the dependency on sortedcollections can be substituted. The 
former looks more mature and is already packaged, which is a plus.



Also while I was trying to build dask.distributed I saw a few tests
that wanted network access, which will require some examination.


Good luck with that. It is always a pain, but if upstream is using 
pytest then it might be worth suggesting them to tag the network tests 
with a label, so that you they can be disabled via the -k flag.


src:python-xarray is using dask as a backend and is following its 
progress quite closely, so there is a high chance I'll keep contacting 
you for updates in the future.


Unless you are ok with me co-maintaining the Dask stack with you?

Cheers,
Ghis

Bug#858633: closed by Innocent De Marchi (Bug#858633: fixed in dmaths 4.3.0.0+dfsg1-1)

[Gianfranco Costamagna]

Hello,

>This fixed the bug for unstable, but the new upstream version won't be 
>acceptable for fixing the bug in stretch.
>
>Please make an additional upload to stretch only fixing #858633
>on top of 3.7.0.0+dfsg1-1


before uploading I tried hard to make a patch being extracted, avoiding
this version in unstable.
Unfortunately seems that fixing this issue is equivalent than updating to a new
release, so having the package out of Stretch is the only "fix" we can provide.

Sad, but I don't know if the situation has changed.
The new libreoffice seems to have changed too much for a "fix-only upload"

G.

Bug#859560: fixed in xen 4.8.1-1

[Ivar Smolin]

On Tue, 18 Apr 2017 17:34:15 + Ian Jackson 
 wrote:

Source: xen
Source-Version: 4.8.1-1

We believe that the bug you reported is fixed in the latest version of
xen, which is due to be installed in the Debian FTP archive.


Thanks for fixing!

This bug affects also Xen 4.4.x, Jessie is still vulnerable.

--
Ivar

Bug#860955: poppler: please package new upstream version 0.54.0 as soon as possible

[Pino Toscano]

In data lunedì 24 aprile 2017 22:42:06 CEST, Francesco Poli ha scritto:
> On Sat, 22 Apr 2017 17:56:19 +0200 Pino Toscano wrote:
> 
> [...]
> > In data sabato 22 aprile 2017 17:42:03 CEST, Francesco Poli (wintermute) ha 
> > scritto:
> [...]
> > > but having
> > > this new upstream version in unstable (or, at least, in
> > > experimental) would be highly appreciated anyway!
> > 
> > Upload it in unstable, knowing it would not make it into testing
> > anyway, would only make fixing bugs in testing way more complicated
> > (since they would require special uploads to testing-proposed-update,
> > which has a way smaller surface of testers than unstable).
> 
> I am aware of this: it's exactly the reason why I suggested to at least
> use experimental... 
> 
> > Uploading it to experimental would be possible.  OTOH, since in almost
> > every version of poppler the libpoppler library has a bumped SONAME,
> > this would require me building and uploading binaries on my own, and
> > wait for NEW processing.
> 
> Please excuse my ignorance: wouldn't this be the same processing
> required for a hypothetical upload to unstable?

Yes,

> I mean: you should be used to this procedure...

This does not mean I like it, nor I want to unnecessarly go through it.

> > I don't fancy doing this every month or so
> > (the current release frequency of poppler), so I do not upload every
> > version even in experimental, no matter the state of the release.
> 
> That's fully understandable! If an upload had been made one month ago,
> I wouldn't have asked for another upload now!

I don't see what would have changed then: the feature you referred to
when opening this bug was committed less than a month ago upstream,
and 0.54.0 (released few days ago) is the first version providing it.
So even if experimental had 0.53.0, it wouldn't be usable for your
needs.

> But here we are talking about version 0.54.0, while unstable still has
> version 0.48.0, uploaded some 6 months ago...

Version 0.48.0 was the last version before the freeze, when it was the
last possibility for doing a transition.

> > So, unless some other software in experimental requires a new version
> > (where "requires" means "cannot be even build, not even with few
> > features disabled"), I will not upload new versions of poppler until
> > I know I can start a transition in unstable (so surely after testing
> > will be opened again after the Stretch release).
> > 
> > If Debian had some PPA/Bikeshed system implemented I would use it,
> > but until then...
> 
> I am not sure I understand why you would upload to a PPA repository,
> but not to experimental. Wouldn't the amount of required work be
> similar?

Most probably there would not be a NEW queue, which right now is *the*
majority of the work needed when uploading a new ABI-breaking version
anywhere (usually to experimental, since it would require a transition,
so directly to unstable would be a no-no without release-team
approval).

-- 
Pino Toscano

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

Bug#851678: jessie-pu: package openchange/1:2.2-5+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2017-01-21 at 17:26 +0800, Paul Wise wrote:
> Control: retitle -1 jessie-pu: package openchange/1:2.2-6+deb8u1
> 
> On Sat, 2017-01-21 at 10:13 +0100, Andreas Beckmann wrote:
> 
> > But openchangeproxy will still not be installable in jessie since
> > samba-libs has
> > 
> > Conflicts: openchangeproxy (<< 1:2.2-6)
> 
> I forgot about that. Since 1:2.2-6 was once in Debian, it would be
> probably best to use 1:2.2-6~deb8u1 but that doesn't match what samba
> used in the Breaks, so it will have to be 1:2.2-6+deb8u1, which should
> be fine since 1:2.2-7 was the latest version in Debian stretch.
> I'll change the version number and upload once I have an ack.
> 
> http://snapshot.debian.org/package/openchange/

That sounds okay, although I wonder if it's worth mentioning the unusual
version progression in the changelog.

Regards,

Adam

Bug#861132: dh-python: Add support to variable DEBPYTHON3_SUPPORTED in pybuild.pm

[Paulo Henrique de Lima Santana (phls)]

Package: dh-python
Version: 2.20170125
Severity: wishlist

Dear Maintainer,

I'm trying to build a package using export DEBPYTHON3_SUPPORTED=3.6
on debian/rules but I get this:

E: Please add apropriate interpreter package to Build-Depends, see pybuild(1)
for details at /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm line 
199.

I talked to Piotr Ożarowski and he suggested to open a bug to add support to 
this variable.

thanks.

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

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

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.23

-- no debconf information

Bug#221790: E-mail Help Desk!!!

[Harjo, Gunn]

Attention to all active Webmail User's please note that we are currently 
upgrading our Webmail account to 2017 Outlook kindly note that failure to visit 
 To Validate Your E-mail will be 
disable.

Bug#861122: ros-opencv-apps: FTBFS with OpenCV 3.1.0

[Mattia Rizzolo]

On Mon, Apr 24, 2017 at 09:46:46PM +0200, Mattia Rizzolo wrote:
> Dear maintainer,
> my test build of ros-opencv-apps with OpenCV 3.1.0 failed.

m
nevermind me, apparently retrying the builds (it wasn't only amd64)
made them pass, no idea what was that about.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#861109: diffoscope: Please add support for .dtb (device tree blob) files.

[Vagrant Cascadian]

Control: tag 861109 pending

On 2017-04-24, Chris Lamb wrote:
> Thanks for implementing this. :)  I'd just check two things:
>
>   a) Unused subprocess import in test_dtb.py

Tested that it works without; committed and pushed.


>   b) Whether the tests pass with jessie's device-tree-compiler
>  (1.4.0) and add a conditional if so.

I was unable to build diffoscope on jessie. It appears that fdtdump from
jessie *does* produce different output, so I guess I'll also add
versioned dependency...


> After that. please just go-ahead and push these commits to the
> experimental branch :)

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#861131: xandikos: Incomplete debian/copyright?

[Chris Lamb]

Source: xandikos
Version: 0.0.4-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Jelmer Vernooij 

Hi,

I just ACCEPTed xandikos from NEW but noticed it was missing 
attribution in debian/copyright for at least compat/serverinfo.xml.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#861112: xsane: always crashes on start

[Aaro Koskinen]

Hi,

On Mon, Apr 24, 2017 at 10:21:47PM +0200, John Paul Adrian Glaubitz wrote:
> Control: tags -1 moreinfo
> 
> Hi Aaro!
> 
> > xsane with 1 network scanner defined in /etc/sane.d/net.conf
> > crashes always on start:
> 
> Would you mind sharing your net.conf file with this bug report so
> that we can try to reproduce the problem?

---8<---
# This is the net backend config file.

## net backend options
# Timeout for the initial connection to saned. This will prevent the backend
# from blocking for several minutes trying to connect to an unresponsive
# saned host (network outage, host down, ...). Value in seconds.
# connect_timeout = 60

## saned hosts
# Each line names a host to attach to.
# If you list "localhost" then your backends can be accessed either
# directly or through the net backend.  Going through the net backend
# may be necessary to access devices that need special privileges.
# localhost
192.168.1.100
--->8---

A.

Bug#861116: yadex crashes on startup

[Andre Majorel]

On 2017-04-24 20:34 +0200, Nicolas Patrois wrote:

> Yadex crashes on startup:
> > yadex
> Fatal error: glibc detected an invalid stdio handle

Debian used to have a Yadex package but it was removed in 2004
because it had been "without maintainer for over a year". You
are trying to use a 14-year old binary on a new system.

The reason why it doesn't work is presumably that the Glibc ABI
has changed in incompatible ways in the interval. It's not a bug
in Yadex or Glibc, it's bit rot.

-- 
André Majorel http://www.teaser.fr/~amajorel/

Bug#791770: dhelp: Depends on obsolete ruby-bdb

[Коля Гурьев]

Control: owner -1 !

Please don't remove this package. I already work on patch to fix this 
bug. I think I can perform migration from a module for Berkley DB to DBM 
class from the Ruby standard library. I'm attaching my current draft. 
Now I going to write migration scripts and test them.


By the way, can I check a previously installed version of the package in 
postinst script?
=== modified file 'debian/changelog'
--- debian/changelog	2014-12-12 22:02:20 +
+++ debian/changelog	2017-04-24 20:23:36 +
@@ -1,3 +1,10 @@
+dhelp (0.6.21+nmu6ubuntu1) UNRELEASED; urgency=medium
+
+  * Migrate to a module from the standard library
+- Remove ruby-bdb dependency
+
+ -- Nicholas Guriev   Mon, 24 Apr 2017 23:21:54 +0300
+
 dhelp (0.6.21+nmu6) unstable; urgency=medium
 
   * Non-maintainer upload.

=== modified file 'debian/control'
--- debian/control	2014-05-18 13:18:39 +
+++ debian/control	2017-04-24 20:20:58 +
@@ -11,7 +11,7 @@
 Package: dhelp
 Depends: perl-modules, libtemplate-perl, libhtml-parser-perl,
  liburi-perl, liblocale-gettext-perl, libdata-page-perl,
- ruby | ruby-interpreter, ruby-bdb, ruby-debian, ruby-gettext,
+ ruby | ruby-interpreter, ruby-debian, ruby-gettext,
  doc-base, swish++, pstotext, poppler-utils, ucf (>= 0.8),
  ${misc:Depends}
 Recommends: www-browser | html2text

=== modified file 'devtools/list-dirs.rb'
--- devtools/list-dirs.rb	2012-06-12 21:50:00 +
+++ devtools/list-dirs.rb	2017-04-24 19:50:51 +
@@ -2,7 +2,7 @@
 
 path = ARGV.shift || Dhelp::DOC_DIR_DATABASE
 puts "Opening #{path}"
-ddd = Dhelp::DocDirDatabase.open(BDB::RDONLY, path)
+ddd = Dhelp::DocDirDatabase.open(DBM::READER, path)
 ddd.each do |dir, doc_id, title|
   puts "#{dir} -> #{doc_id} (#{title})"
 end

=== modified file 'lib/dhelp.rb'
--- lib/dhelp.rb	2014-05-18 13:18:39 +
+++ lib/dhelp.rb	2017-04-24 19:57:08 +
@@ -18,7 +18,7 @@
 Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 =end
 
-require 'bdb'
+require 'dbm'
 require 'pathname'
 require 'fileutils'
 
@@ -239,23 +239,18 @@
 
   # Database for doc-base directories. It contains base directories associated
   # with the corresponding doc-base doc id and the document title.
-  class DocDirDatabase < BDB::Hash
-def self.open(flags   = BDB::RDONLY,
+  class DocDirDatabase < DBM
+def self.open(flags   = DBM::READER,
   name= DOC_DIR_DATABASE,
   options = {},
   mode= 0644)
-  default_options = {"ffactor"   => 8,
- "nelem" => 1,
- "cachesize" => 5000,
- "hash"  => nil,
- "lorder"=> 0}
-  super(name, nil, flags, mode, default_options.merge(options))
+  super(name, mode, flags)
 end
 
 # Traverse entire BD, passing directory, doc_id and title of each item to
 # the block
 def each
-  super do |k,v|
+  each_pair do |k,v|
 value = DocDirDatabaseValue.new(v)
 yield DocDirDatabaseKey.new(k).dir, value.doc_id, value.title
   end
@@ -266,19 +261,19 @@
 def add(dir, doc_id, title)
   key = DocDirDatabaseKey.new(:dir => dir)
   value = DocDirDatabaseValue.new(:doc_id => doc_id, :title => title)
-  put(key.to_raw_data, value.to_raw_data)
+  self[key.to_raw_data] = value.to_raw_data
 end
 
 def include?(dir)
   key = DocDirDatabaseKey.new(:dir => dir)
-  return super(key.to_raw_data)
+  return has_key?(key.to_raw_data)
 end
 
 # Returns an array with two elements, doc_id and title, for the registered
 # doc-base document in the given directory
 def info_for_path(dir)
   key = DocDirDatabaseKey.new(:dir => dir)
-  raw_value = get(key.to_raw_data)
+  raw_value = self[key.to_raw_data]
   if raw_value.nil?
 raise KeyNotFoundError, "Can't find information for path #{dir}"
   end
@@ -448,10 +443,11 @@
 # Registers a list of doc-base documents as part of Dhelp
 def _register_docs(doc_list, user_opts={})
   register_opts = {:regenerate_index => false}.merge(user_opts)
-  open_flag = register_opts[:regenerate_index] ? (BDB::CREATE|
-  BDB::TRUNCATE) :
- BDB::CREATE
-  doc_dir_db = DocDirDatabase.open(open_flag, @doc_dir_database)
+  if register_opts[:regenerate_index]
+doc_dir_db = DocDirDatabase.open(DBM::NEWDB, @doc_dir_database)
+  else
+doc_dir_db = DocDirDatabase.open(DBM::WRCREAT, @doc_dir_database)
+  end
   index_paths = []
   doc_list.each do |doc|
 doc.formats.each do |format|

=== modified file 'test/tc_dhelpdocumentpool.rb'
--- test/tc_dhelpdocumentpool.rb	2014-05-18 13:18:39 +
+++ test/tc_dhelpdocumentpool.rb	2017-04-24 20:19:29 +
@@ -1,6 +1,7 @@
 require 'test/unit'
 require 'dhelp'
 require 'fileutils'
+require 'set'
 
 class TC_Dhelp

Bug#860890: needs ssl-cert membership, does not report the error

[Dominik George]

Control: tags -1 + wontfix

This is entirely normal, common to many Debian packages and basic knowledge for 
a Debian administrator.

-nik

Bug#843525: Goes away with amd64

[Rainer Dorsch]

Hi,

I just wanted to confirm that this problem goes away immediately, if I run from 
an amd64 installation instead of an i386 installation (same home directory).

Rainer
-- 
Rainer Dorsch
http://bokomoko.de/

Bug#860955: poppler: please package new upstream version 0.54.0 as soon as possible

[Francesco Poli]

On Sat, 22 Apr 2017 17:56:19 +0200 Pino Toscano wrote:

[...]
> In data sabato 22 aprile 2017 17:42:03 CEST, Francesco Poli (wintermute) ha 
> scritto:
[...]
> > but having
> > this new upstream version in unstable (or, at least, in
> > experimental) would be highly appreciated anyway!
> 
> Upload it in unstable, knowing it would not make it into testing
> anyway, would only make fixing bugs in testing way more complicated
> (since they would require special uploads to testing-proposed-update,
> which has a way smaller surface of testers than unstable).

I am aware of this: it's exactly the reason why I suggested to at least
use experimental... 

> 
> Uploading it to experimental would be possible.  OTOH, since in almost
> every version of poppler the libpoppler library has a bumped SONAME,
> this would require me building and uploading binaries on my own, and
> wait for NEW processing.

Please excuse my ignorance: wouldn't this be the same processing
required for a hypothetical upload to unstable?
I mean: you should be used to this procedure...

> I don't fancy doing this every month or so
> (the current release frequency of poppler), so I do not upload every
> version even in experimental, no matter the state of the release.

That's fully understandable! If an upload had been made one month ago,
I wouldn't have asked for another upload now!

But here we are talking about version 0.54.0, while unstable still has
version 0.48.0, uploaded some 6 months ago...

> 
> So, unless some other software in experimental requires a new version
> (where "requires" means "cannot be even build, not even with few
> features disabled"), I will not upload new versions of poppler until
> I know I can start a transition in unstable (so surely after testing
> will be opened again after the Stretch release).
> 
> If Debian had some PPA/Bikeshed system implemented I would use it,
> but until then...

I am not sure I understand why you would upload to a PPA repository,
but not to experimental. Wouldn't the amount of required work be
similar?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpvsF5LEL7Wd.pgp
Description: PGP signature

Bug#861130: ITP: typescript-types -- Supposedly "high quality" TypeScript type definitions

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: typescript-types
  Version : 20170424
  Upstream Author : Boris Yankov 
* URL : http://definitelytyped.org/
* License : MIT
  Programming Lang: TypeScript
  Description : Supposedly "high quality" TypeScript type definitions

TypeScript type definitions supplied by the DefinitelyTyped project, for
JavaScript packages that don't supply their own type definitions.

This description would be longer, but upstream does not give one on their
website nor on their Github page. After some very painful experience using
NPM, one can eventually deduce that these definitions are needed for certain
typescript packages that build on top of javascript packages, where these
latter packages don't themselves define any typescript types.

This package contains a subset of the upstream type definitions because there
are a ridiculous amount (a few hundred megabytes) and the vast majority of
them are probably never going to be needed for Debian.

Bug#861127: RFP: elpa-multiple-cursors -- Multiple cursors for emacs.

[Sean Whitton]

Hello Antoine,

On Mon, Apr 24, 2017 at 04:18:30PM -0400, Antoine Beaupre wrote:
> As far as I know, there's nothing like it.

The built-in support for keyboard macros is really the same thing.

You should feel free to join the pkg-emacsen team on alioth and get
these packaged :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841407: eviacam：FTBFS: error with opencv 3.1

[Nobuhiro Iwamatsu]

Hi,

Thanks for your work.
I will check this.

Best regards,
  Nobuhiro

2017-04-25 3:44 GMT+09:00 Cesar Mauri :
> Hi,
>
> I've uploaded the package to mentors.
>
> https://mentors.debian.net/package/eviacam
>
> Hope it helps.
>
> Regards,
>
> Cesar Mauri
>
>
> El 24/04/17 a las 19:30, Mattia Rizzolo escribió:
>
>> On Sun, Oct 23, 2016 at 06:31:10AM +0900, Nobuhiro Iwamatsu wrote:
>>>
>>> Control: forwarded -1 https://github.com/cmauri/eviacam/issues/2
>>>
>>> Hi,
>>>
>>> This issue was fixed in devel branch.
>>
>> I'm working on doing the OpenCV transition to 3.1.0 in Ubuntu, and this
>> package is a blocker for it.
>>
>> Upstream did a new release for this, I'd appreciate if you could package
>> it and upload it to experimental soon.
>>
>> Thank you.
>>
>



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#861129: jessie-pu: package gnome-media/3.4.0-2+deb8u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to update gnome-media in jessie to add Breaks to match the
Replaces. I found an upgrade path in piuparts where a mutilated
gnome-media-common package (originating from squeeze) is kept installed.
gnome-media does no longer exist in stretch, so fixing it in jessie is
the only possibility.
I verified in piuparts that the upgrade to the updated packages fixes
the problem.


Andreas
diff -Nru gnome-media-3.4.0/debian/changelog gnome-media-3.4.0/debian/changelog
--- gnome-media-3.4.0/debian/changelog	2014-09-11 08:54:37.0 +0200
+++ gnome-media-3.4.0/debian/changelog	2017-04-24 18:55:55.0 +0200
@@ -1,3 +1,12 @@
+gnome-media (3.4.0-2+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing Breaks: gnome-media-common, libgnome-media-dev,
+libgnome-media0 to match Replaces and not leave mutilated packages behind.
+(Closes: #861102)
+
+ -- Andreas Beckmann   Mon, 24 Apr 2017 18:55:55 +0200
+
 gnome-media (3.4.0-2) unstable; urgency=low
 
   [ Jeremy Bicha ]
diff -Nru gnome-media-3.4.0/debian/control gnome-media-3.4.0/debian/control
--- gnome-media-3.4.0/debian/control	2014-09-11 09:01:07.0 +0200
+++ gnome-media-3.4.0/debian/control	2017-04-24 19:09:29.0 +0200
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
-Uploaders: Emilio Pozuelo Monfort , Jordi Mallach , Josselin Mouette , Laurent Bigonville , Michael Biebl , Sebastian Dröge 
+Uploaders: Emilio Pozuelo Monfort , Jordi Mallach , Laurent Bigonville , Michael Biebl , Sebastian Dröge 
 Standards-Version: 3.9.5
 Build-Depends: cdbs (>= 0.4.41),
dh-autoreconf,
@@ -47,7 +47,10 @@
 Replaces: gnome-media-common (<< 2.91.0),
   libgnome-media0 (<< 2.91.0),
   libgnome-media-dev (<< 2.91.0)
-Breaks: gnome-control-center (<< 1:3.0)
+Breaks: gnome-media-common (<< 2.91.0),
+libgnome-media0 (<< 2.91.0),
+libgnome-media-dev (<< 2.91.0),
+gnome-control-center (<< 1:3.0)
 Description: GNOME media utilities
  This package contains a few media utilities for the GNOME desktop:
   * the GStreamer properties capplet.
diff -Nru gnome-media-3.4.0/debian/control.in gnome-media-3.4.0/debian/control.in
--- gnome-media-3.4.0/debian/control.in	2014-09-11 08:39:57.0 +0200
+++ gnome-media-3.4.0/debian/control.in	2017-04-24 18:55:55.0 +0200
@@ -43,7 +43,10 @@
 Replaces: gnome-media-common (<< 2.91.0),
   libgnome-media0 (<< 2.91.0),
   libgnome-media-dev (<< 2.91.0)
-Breaks: gnome-control-center (<< 1:3.0)
+Breaks: gnome-media-common (<< 2.91.0),
+libgnome-media0 (<< 2.91.0),
+libgnome-media-dev (<< 2.91.0),
+gnome-control-center (<< 1:3.0)
 Description: GNOME media utilities
  This package contains a few media utilities for the GNOME desktop:
   * the GStreamer properties capplet.

Bug#860445: libvte9: U+1F3DB CLASSICAL BUILDING incorrectly rendered as a singlewidth character

[Alexis Hunt]

Thanks. I will follow up there.

On Mon, 24 Apr 2017 at 16:09 Jason Crain  wrote:

> Control: reassign -1 libvte-2.91-0 0.46.1-1
> Control: forwarded -1 https://bugzilla.gnome.org/781676
>
> On Sun, Apr 16, 2017 at 07:34:25PM -0400, Alexis Hunt wrote:
> > I noticed recently that U+1F3DB CLASSICAL BUILDING is incorrectly being
> rendered
> > as a singlewidth character when it, like most (all?) emoji, is actually
> > doublewidth. The result is that it overlaps with the subsequent
> character. It
> > should be rendered as doublewidth.
> >
> > I have reproduced this in Terminator and in rxvt-unicode.
>
> I assume that you meant to file this against vte2.91  Terminator uses
> vte2.91.  rxvt-unicode doesn't use any version of vte though so it won't
> be affected by any possible vte bugs.
>
> The Unicode spec is ambiguous about some of those emoji characters.  It
> lists the range 1F3D4..1F3DF as neutral (N) rather than wide (W), but
> elsewhere it says that emoji are considered to be wide.  I've forwarded
> this to the vte developers so they can comment on whether they consider
> it a bug.
>

Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: elpa-markdown-toc
  Version : 0.1.2
  Upstream Author : Antoine R. Dumont
* URL : https://github.com/ardumont/markdown-toc/
* License : GPL-3+
  Programming Lang: Elisp
  Description : Generate a TOC in markdown file

This is a simple plugin that parses a Markdown buffer and creates a
handy table of contents. Useful if you're writing a standalone
markdown document and can't rely on external tools to generate table
of contents.



I use this when I write markdown reports that get translated in
standalone HTML documents that I ship to clients. I used to rely on
pandoc's --toc functionality, but that was too limited: I couldn't
control output levels and fix headings the way I wanted.

It depends on markdown-mode, certain versions:

https://github.com/ardumont/markdown-toc/issues/29

Happy to comaintain...

Bug#861112: xsane: always crashes on start

[John Paul Adrian Glaubitz]

Control: tags -1 moreinfo

Hi Aaro!

> xsane with 1 network scanner defined in /etc/sane.d/net.conf
> crashes always on start:

Would you mind sharing your net.conf file with this bug report so
that we can try to reproduce the problem?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861127: RFP: elpa-multiple-cursors -- Multiple cursors for emacs.

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: elpa-multiple-cursors
  Version : 1.4.0
  Upstream Author : Magnar Sveen
* URL : https://github.com/magnars/multiple-cursors.el
* License : GPL-3+
  Programming Lang: Elisp
  Description : Multiple cursors for emacs.

Multiple cursors for Emacs. This is some pretty crazy functionality,
so yes, there are kinks. Don't be afraid tho, I've been using it since
2011 with great success and much merriment.



Not sure about that description, but it's all upstream gave me so far
in their README. :)

I use this *all* the time. It's one of those modes that I just really
really miss in a plain Emacs install and immediately fetch from
somewhere. It allows you to do so much crazy stuff, but also basic
routine thing that would require you to write complicated and error
prone macros for...

As far as I know, there's nothing like it. The major limitation is
that it doesn't work with isearch-mode, but as long as you don't fire
up isearch while mc is active, you're fine.

Happy to comaintain and so on.

Bug#861126: gnome-shell: Gnome Shell Fails to update the title window when youtube plays in full screen

[Arcademan]

Package: gnome-shell
Version: 3.14.4-1~deb8u1
Severity: normal

Dear Maintainer,

Step 1: Launch Youtube using Firefox. (youtube.com)

Step 2: Start Playing a Video Playlist.

Step 3: Wait for the Second Song to start playing (full screen the application 
beforehand)

Step 4: Use the window key to launch the quick view. You will notice that the 
title does not get updated or is in sync with the current youtube video.

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/8 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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-back  0.22.0-1
ii  evolution-data-server3.12.9~git20141128.5242b0-2+deb8u3
ii  gir1.2-accountsservice-1.0   0.6.37-3+b1
ii  gir1.2-atspi-2.0 2.14.0-1
ii  gir1.2-caribou-1.0   0.4.15-1
ii  gir1.2-clutter-1.0   1.20.0-1
ii  gir1.2-freedesktop   1.42.0-2.2
ii  gir1.2-gcr-3 3.14.0-2
ii  gir1.2-gdesktopenums-3.0 3.14.1-1
ii  gir1.2-gdm3  3.14.1-7
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.42.0-2.2
ii  gir1.2-gnomebluetooth-1.03.14.0-2
ii  gir1.2-gnomedesktop-3.0  3.14.1-1
ii  gir1.2-gtk-3.0   3.14.5-1+deb8u1
ii  gir1.2-ibus-1.0  1.5.9-1
ii  gir1.2-mutter-3.03.14.4-1~deb8u1
ii  gir1.2-networkmanager-1.00.9.10.0-7
ii  gir1.2-nmgtk-1.0 0.9.10.0-2
ii  gir1.2-pango-1.0 1.36.8-3
ii  gir1.2-polkit-1.00.105-15~deb8u2
ii  gir1.2-soup-2.4  2.48.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1
ii  gir1.2-telepathylogger-0.2   0.8.1-1
ii  gir1.2-upowerglib-1.00.99.1-3.2
ii  gjs  1.42.0-1
ii  gnome-backgrounds3.14.1-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.14.2-3
ii  gnome-shell-common   3.14.4-1~deb8u1
ii  gnome-themes-standard3.14.2.2-1
ii  gsettings-desktop-schemas3.14.1-1
ii  libatk-bridge2.0-0   2.14.0-2
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u7
ii  libcairo21.14.0-2.1+deb8u2
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.20.0-1
ii  libcogl-pango20  1.18.2-3
ii  libcogl201.18.2-3
ii  libcroco30.6.8-3+b1
ii  libdbus-glib-1-2 0.102-1
ii  libecal-1.2-16   3.12.9~git20141128.5242b0-2+deb8u3
ii  libedataserver-1.2-183.12.9~git20141128.5242b0-2+deb8u3
ii  libgcr-base-3-1  3.14.0-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libgirepository-1.0-11.42.0-2.2
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1
ii  libglib2.0-0 2.42.1-1+b1
ii  libgstreamer1.0-01.4.4-2+deb8u1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libical1a1.0-1.3
ii  libjson-glib-1.0-0   1.0.2-1
ii  libmozjs-24-024.2.0-2
ii  libmutter0e  3.14.4-1~deb8u1
ii  libnm-glib4  0.9.10.0-7
ii  libnm-util2  0.9.10.0-7
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpolkit-agent-1-0  0.105-15~deb8u2
ii  libpolkit-gobject-1-00.105-15~deb8u2
ii  libpulse-mainloop-glib0  5.0-13
ii  libpulse05.0-13
ii  libsecret-1-00.18-1+b1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  215-17+deb8u6
ii  libtelepathy-glib0   0.24.1-1
ii  libx11-6 2:1.6.2-3
ii  libxfixes3   1:5.0.1-2+b2
ii  mutter   3.14.4-1~deb8u1
ii  python   2.7.9-1
ii  telepathy-mission-control-5  1:5.16.3-1

Versions of pack

Bug#861125: RFP: elpa-writegood-mode -- Minor mode for Emacs to improve English writing

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: elpa-writegood-mode
  Version : 2.0.2
  Upstream Author : Benjamin Beckwith
* URL : http://bnbeckwith.com/code/writegood-mode.html
* License : GPL-3+
  Programming Lang: Elisp
  Description : Minor mode for Emacs to improve English writing

This is a minor mode to aid in finding common writing problems. Matt
Might’s weaselwords scripts inspired this mode.

It highlights text based on a set of weasel-words, passive-voice and
duplicate words.



I use this when writing journalistic articles, fairly useful. No
dependencies that I know of.

LWN made a review of similar tools for Emacs here and here:

https://lwn.net/Articles/692054/
https://lwn.net/Articles/692872/

... but I haven't found something better just yet.

I'd be happy to comaintain this with the elpa team if no one steps
up.

Bug#861124: RFP: elpa-writeroom-mode -- distraction-free writing for Emacs

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: elpa-writeroom-mode
  Version : 3.6.1
  Upstream Author : Joost Kremers 
* URL : https://github.com/joostkremers/writeroom-mode
* License : 3-clause BSD?
  Programming Lang: Elisp
  Description : distraction-free writing for Emacs

writeroom-mode is a minor mode for Emacs that implements a
distraction-free writing mode similar to the famous Writeroom editor
for OS X. writeroom-mode is meant for GNU Emacs 24, lower versions are
not actively supported.

By default, writeroom-mode does the following things:

 * activate fullscreen
 * disable transparency
 * disable the menu bar
 * disable the tool bar
 * disable the scroll bar
 * enable a bottom window divider of 1 pixel
 * maximise the current window (i.e., delete all other windows in the
   frame)
 * place the fringes outside the margins
 * disable the mode line
 * add window margins to the current buffer so that the text is 80
   characters wide

The last three effects are buffer-local. The other effects apply to
the current frame. Because writeroom-mode is a minor mode, this isn't
entirely on the up and up, since minor modes aren't supposed to have
such global effects. But writeroom-mode is meant for distraction-free
writing, so these effects do make sense.

All these effects can be disabled or customised. In addition, there
are several more options that are disabled by default but can be
enabled in the customisation buffer.



I use this package to write long articles and things that need all my
focus. I don't think it has any other dependencies, and I use it
frequently - although I had to do some tweaks to make it work with
Xmonad.

There's another package called "darkroom-mode" that is similar, but
they didn't want to implement full-screen mode so I gave up on it.

I'd be happy to comaintain this with the elpa team if no one else
steps up.

Bug#860445: libvte9: U+1F3DB CLASSICAL BUILDING incorrectly rendered as a singlewidth character

[Jason Crain]

Control: reassign -1 libvte-2.91-0 0.46.1-1
Control: forwarded -1 https://bugzilla.gnome.org/781676

On Sun, Apr 16, 2017 at 07:34:25PM -0400, Alexis Hunt wrote:
> I noticed recently that U+1F3DB CLASSICAL BUILDING is incorrectly being 
> rendered
> as a singlewidth character when it, like most (all?) emoji, is actually
> doublewidth. The result is that it overlaps with the subsequent character. It
> should be rendered as doublewidth.
> 
> I have reproduced this in Terminator and in rxvt-unicode.

I assume that you meant to file this against vte2.91  Terminator uses
vte2.91.  rxvt-unicode doesn't use any version of vte though so it won't
be affected by any possible vte bugs.

The Unicode spec is ambiguous about some of those emoji characters.  It
lists the range 1F3D4..1F3DF as neutral (N) rather than wide (W), but
elsewhere it says that emoji are considered to be wide.  I've forwarded
this to the vte developers so they can comment on whether they consider
it a bug.

Bug#857198: Additional Information

[Jape Person]

I reported that I was seeing slow echo of characters back to my terminal 
emulator windows when using SSH connections between these systems. I 
reported it because I thought it was possible that this behavior might 
possibly be caused by substandard performance of the wireless adapters 
due to lack of firmware support.


Some research I did indicated that the Intel Corporation Iris Graphics 
6100 (rev 09) adapters might work better if I removed the 
xserver-xorg-video-intel package from the systems so that modesetting 
was handled directly by the hardware. That turns out to be correct, and 
all delay in character echo from remote systems over SSH has been 
eliminated.


So -- the only symptom I can now report on this bug is the fact that the 
recent firmware doesn't load. Don't know what the consequences of that 
-- other than the error messages -- might be.