Bug#867373: aspell: random crash (SIGSEGV) when run from git gui

[Paul Wise]

Package: aspell
Version: 0.60.7~20110707-3+b2
Severity: normal
File: /usr/bin/aspell

I had git gui open and accidentally right clicked on a misspelled word.
git gui then informed me that aspell crashed. I have MALLOC_CHECK_=2
and MALLOC_PERTURB_=$((RANDOM % 255 + 1)) set, so that is probably why
the backtrace mentions malloc_check. If the backtrace below is not
useful, please close this bug report.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/1000/8113-1000-1000-11-1499318705-chianamo--usr-bin-aspell.core 
/usr/bin/aspell
[New LWP 8113]
Core was generated by `aspell --mode=none --encoding=utf-8 pipe'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  malloc_consolidate (av=av@entry=0x7f6710d27b00 ) at 
malloc.c:4219
4219malloc.c: No such file or directory.
#0  malloc_consolidate (av=av@entry=0x7f6710d27b00 ) at 
malloc.c:4219
#1  0x7f6710a06dca in _int_malloc (av=av@entry=0x7f6710d27b00 , 
bytes=bytes@entry=1025) at malloc.c:3488
#2  0x7f6710a07b38 in malloc_check (sz=1024, caller=) at 
hooks.c:295
#3  0x7f6711c6e85b in acommon::ObjStack::ObjStack (this=0x7ffc5e8b0ce8, 
chunk_s=, align=) at common/objstack.cpp:20
#4  0x7f6711c7dc6d in (anonymous namespace)::Working::Working (p=, w=..., l=0x563f3ca8afd0, m=0x563f3ca77cc0, this=0x7ffc5e8b0bf0) at 
modules/speller/default/suggest.cpp:286
#5  (anonymous namespace)::SuggestImpl::suggest (this=0x563f3ca797b0, 
word=) at modules/speller/default/suggest.cpp:1325
#6  0x7f6711c8dbd4 in aspeller::SpellerImpl::suggest (this=, 
word=...) at modules/speller/default/speller_impl.cpp:133
#7  0x7f6711cb567a in acommon::aspell_speller_suggest (ths=0x563f3ca77cc0, 
word=, word_size=) at lib/speller-c.cpp:148
#8  0x563f3b2e2a56 in pipe () at prog/aspell.cpp:891
#9  0x563f3b2da828 in main (argc=4, argv=) at 
prog/aspell.cpp:417

Thread 1 (LWP 8113):
#0  malloc_consolidate (av=av@entry=0x7f6710d27b00 ) at 
malloc.c:4219
fb = 0x7f6710d27b28 
maxfb = 0x7f6710d27b50 
p = 0x563f3ca7d510
nextp = 0x563f3ca7d910
unsorted_bin = 0x7f6710d27b58 
first_unsorted = 
nextchunk = 0x563f3ca7d550
size = 64
nextsize = 
prevsize = 
nextinuse = 
bck = 
fwd = 
#1  0x7f6710a06dca in _int_malloc (av=av@entry=0x7f6710d27b00 , 
bytes=bytes@entry=1025) at malloc.c:3488
nb = 1040
idx = 64
bin = 
victim = 
size = 
victim_index = 
remainder = 
remainder_size = 
block = 
bit = 
map = 
fwd = 
bck = 
errstr = 0x0
__func__ = "_int_malloc"
#2  0x7f6710a07b38 in malloc_check (sz=1024, caller=) at 
hooks.c:295
victim = 
#3  0x7f6711c6e85b in acommon::ObjStack::ObjStack (this=0x7ffc5e8b0ce8, 
chunk_s=, align=) at common/objstack.cpp:20
No locals.
#4  0x7f6711c7dc6d in (anonymous namespace)::Working::Working (p=, w=..., l=0x563f3ca8afd0, m=0x563f3ca77cc0, this=0x7ffc5e8b0bf0) at 
modules/speller/default/suggest.cpp:286
No locals.
#5  (anonymous namespace)::SuggestImpl::suggest (this=0x563f3ca797b0, 
word=) at modules/speller/default/suggest.cpp:1325
sug = {<(anonymous namespace)::Score> = {lang = 0x563f3ca8afd0, 
original = {word = { = {_vptr.OStream = 0x563f3b4f6c90 
}, begin_ = 0x563f3cab7970 "BLS", 'D' , "C", end_ = 0x563f3cab7973 'D' , "C", storage_end_ 
= 0x563f3cab79b0 "C", static npos = 2147483647}, lower = { = 
{_vptr.OStream = 0x563f3b4f6c90 }, begin_ = 
0x563f3cab8d00 "bls", 'D' , , end_ 
= 0x563f3cab8d03 'D' , , 
storage_end_ = 0x563f3cab8d40 , static npos = 
2147483647}, clean = { = {_vptr.OStream = 0x563f3b4f6c90 
}, begin_ = 0x563f3cab8a00 "bls", 'D' , "O\020", end_ = 0x563f3cab8a03 'D' , "O\020", 
storage_end_ = 0x563f3cab8a40 "O\020", static npos = 2147483647}, soundslike = 
{ = {_vptr.OStream = 0x563f3b4f6c90 }, begin_ = 0x563f3cab8960 "BLS", end_ = 0x563f3cab8963 "", 
storage_end_ = 0x563f3cab89a0 "[\017", static npos = 2147483647}, case_pattern 
= aspeller::AllUpper}, parms = 0x563f3ca797e8}, threshold = 1, try_harder = 0, 
edit_dist_fun = 0x0, max_word_length = 0, sp = 0x563f3ca77cc0, 
scored_near_misses = {data_ = empty std::__cxx11::list}, near_misses = {data_ = 
empty std::__cxx11::list}, near_misses_final = 0x7ffc5e8b0e00, temp_end = 
0x563f3ca77df8 "", buffer = {chunk_size = 1024, min_align = 8, first = 0x1, 
first_free = 0x0, reserve = 0x563f3ca7d4d0, top = 0x3 , bottom = 0x563f3caa7300 "Я\250, first_free = 0x3, reserve = 0x7f6711ca1e89 
, top 
= 0x563f3ca8dec8 "\310ި, static dont_count = 
, check_info = {{next = 0x3, word = {str_ = 0x7ffc5e8b0e20 "", 
size_ = 1672838912}, pre_strip_len = -8400, pre_add_len = 15528, pre_add = 0x3 
, suf_strip_len = 27792, 

Bug#833379: hardinfo: please make the build reproducible

[Burt P.]

Hardinfo changed to CMake some time ago, the patch does not apply. The
problem may not even exist in newer versions.

-- 
Burt

Bug#867361: sitesummary: Fix autopkgtest to work in environments with http_proxy set

[Petter Reinholdtsen]

Thank you Steve, for looking into autopkgtest failures. :)

[Steve Langasek]
> FWIW this does fix the problem with the test talking to the wrong server,
> but the test still fails as shown at
> .

Hm, look like a race condition:

autopkgtest [01:08:03]: test test-server-client: [---
/var/lib/sitesummary
/var/lib/sitesummary/tmpstorage
/var/lib/sitesummary/tmpstorage/127.0.0.1-2017-07-06T01:08:03-2349-sitesummary
/var/lib/sitesummary/tmpstorage/127.0.0.1-2017-07-06T01:08:03-2349-sitesummary.tar.gz
/var/lib/sitesummary/www
/var/lib/sitesummary/www/index.html
/var/lib/sitesummary/entries
error: did not find entry
info: terminating script
autopkgtest [01:08:04]: test test-server-client: ---]

It look like the server is still busy unpacking the submitted entry, and
have not yet had time to move the relevant files under entries/.

Anyone got any idea how we can best avoid the race?  'sleep 10' seem
like such a crude solution...

-- 
Happy hacking
Petter Reinholdtsen

Bug#866759: stretch-pu: package protozero/1.5.1-1+deb9u1

[Sebastiaan Couwenberg]

On 07/03/2017 11:36 AM, Cyril Brulebois wrote:
> Bas Couwenberg  (2017-07-01):
>> protozero 1.5.1 in stretch contains a serious bug that was fixed in
>> 1.5.2. The fix has been cherry-picked and I'd like to upload this
>> proposed-update.
>>
>> >From the changelog and patch description:
>>
>> "
>>  This fixes a rather embarrassing bug in the equality operator of the
>>  data_view class. The equality operator is actually never used in the
>>  protozero code itself, but users of protozero might use it. This is a
>>  serious bug that could lead to buffer overrun type problems.
>> "
>>
>> The issue was pointed out by the upstream author in:
>>
>>  https://lists.debian.org/debian-gis/2017/07/msg0.html
> 
> Ah right, \0 characters are fun…
> 
> This looks good to me, but we'll need to wait until 1.5.2-1 has reached
> testing before accepting this from stretch-new; either upload now, and
> ping when it's migrated; or upload when it's migrated, and ping us right
> afterwards.
Ping. protozero (1.5.2-1) migrated to testing today, and protozero
(1.5.1-1+deb9u1) was uploaded a few days ago.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#867366: installation-reports: Kernel panic: null pointer derefence at (null), first boot after install

[Ed Peguillan III]

This same issue appears to be referenced here: 
http://forums.debian.net/viewtopic.php?f=17=133564


I followed the instructions and prevented the kernel from using 
nouveau.ko and I booted successfully. I suppose this bug can be closed, 
but it's still a problem that required manual intervention, so I'm not 
sure what to do as far as filing a bug in the appropriate place.


I also don't really know what it means to not be able to use nouveau 
drivers.


I got this far thanks to reddit user /u/akas84, our discussion is here: 
https://www.reddit.com/r/debian/comments/6liq1m/kernel_panic_null_pointer_dereference_first_boot/?st=j4ryrztn=2226543c


They suggest the problem is with nouveau. What can I do in the meantime?

Thanks

On Wed, 05 Jul 2017 22:00:14 -0500 Ed Peguillan III 
 wrote:

> Package: installation-reports
> Severity: critical
> Tags: d-i
> Justification: breaks the whole system
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> Image of panic (after installing stable): https://i.imgur.com/4uTKicf.jpg
>
> I reformatted my computer and tried installing Debian Testing.
> The very first reboot led to the kernel panic shown in the imgur image. I
> reformatted again, this time trying Debian 9.0 Stable from the link
> given in "Image version": debian-9.0.0-amd64-netinst.iso. I got the
> exact same kernel panic shown in the imgur image.
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> I simply installed Debian stable and rebooted.
>
> * What was the outcome of this action?
>
> I got a kernel panic about 6.7 seconds after booting. No time to
> login or anything, it seems to happen instantaneously after the tty
> shows the "login:" prompt.
>
> * What outcome did you expect instead?
>
> I hoped to have a working system.
>
> -- Package-specific info:
>
> Boot method: USB
> Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.0.0-amd64-netinst.iso

> Date: 5 July, 2017
>
> Machine: Motherboard: Gigabyte EP45-UD3P (I can get more information if
> needed)
>
> Partitions: 
>
> During install, I wiped and created a new partition table on the hard
> drive to hold Debian. I created a single extended partition covering the
> entire drive, then a single ext4 partition covering that entire extended
> partition. This partition served as mountpoint for /. I set root's
> reserved block percentage to 0%.
>
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
>
> ALL WERE OK
>
> Initial boot: [O]
> Detect network card: [ ]
> Configure network: [ ]
> Detect CD: [ ]
> Load installer modules: [ ]
> Clock/timezone setup: [ ]

Bug#867054: Please hold

[Julien Puydt]

Hi,

this package needs to be reworked ; I'll do it later today but in the
meantime, please don't sponsor it as-is.

Sorry,

Snark on #debian-js

Bug#867372: RFS: lfm/3.1-1

[Daniel Echeverry]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: lfm
* Version : 3.1-1
   Upstream Author : Iñigo Serna
 * URL : https://inigo.katxi.org/devel/lfm/
 * License : GPL-3.0+
   Section : utils

 It builds those binary packages:

lfm   - simple but powerful file manager for the UNIX console

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/l/lfm/lfm_3.1-1.dsc

 More information about hello can be obtained from
 https://inigo.katxi.org/devel/lfm/

 Changes since the last upload:

  * New upstream release.
  * All patches are refreshed.
  * debian/control
+ Bump standard versions 4.0.0 (no changes)
+ Change debhelper to 10 in B-D.
  * debian/copyright
+ Extend copyright holder years.
  * debian/compat
+ Switch compat level 9 to 10.

  Regards,
  Daniel Echeverry

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#867270: ITA: babl/0.1.28-4

[Keng-Yu Lin]

2017-07-05 21:47 GMT+08:00 Andrey Rahmatullin :
> On Wed, Jul 05, 2017 at 09:26:46PM +0800, Keng-Yu Lin wrote:
>> Thanks for providing the information.
>> Title is fixed. The original maintainer of this orphaned package is
>> included in the mail receivers.
> Please also fix the title of #866873 (and please don't top-post).

Done. Thanks!

Bug#867371: src:lasagne: Unneeded python3-all-dev build-depends

[Scott Kitterman]

Package: src:lasagne
Version: 0.1+git20160728.8b66737-3
Severity: important

python and python3-lasagne are arch:all packages with no compiled content.
They do not need the python/python3 dev packages to build.  We use build-
depends on python3-all-dev and python3-dev to track which package need
rebuilding for a python3 transition and as far as I can determine, this one
does not.  Including them when not needed makes tracking transitions harder.

Not including a patch for the trivial change of changing the build-depends on
python3-all-dev to python3-all.

Marking important because of the potential for impact on transition planning.

Scott K

Bug#867370: src:theano: Unnecessary python3-all-dev build-depends complicate transition

[Scott Kitterman]

Package: src:theano
Version: 0.8.2-6
Severity: important

As far as I can tell, python3-theano does not install any compiled content
that requires access to the Python headers (e.g. Python.h).  As a result, the
package build-depend on python3-all-dev is excessive.  We use build-depends on
python3-all-dev and python3-dev to track which package need rebuilding for a
python3 transition and as far as I can determine, this one does not.

I rebuilt the package without any python-dev package installed and the result,
according to debdiff, was identical.

Not including a patch for the trivial change of changing the build-depends on
python3-all-dev to python3-all.

Marking important because of the potential for impact on transition planning.

Scott K

Bug#866026: volunteer for pygpgme to python[3]-gpg pivot

[draeath]

One month does not seem like a lot of turnaround time for this. Does this
package have an active maintainer? I'm willing to look into updating this
and providing a patch, but I might need some handholding on the process
side. (I'm familiar with casual site-local usage of debuild, but I do not
currently have a PGP key I can readily sign anything with)

This would be my first time contributing more than bug reports.

I'd imagine this package does see some use, as it's currently the only good
way to hook Dropbox into the Mate desktop without dragging a whole lot of
gnome3 components along for the ride.

Regards,
Paul Bransford

Bug#867369: radare2: CVE-2017-10929

[Salvatore Bonaccorso]

Source: radare2
Version: 0.9.6-1
Severity: important
Tags: security upstream patch
Forwarded: https://github.com/radare/radare2/issues/7855

Hi,

the following vulnerability was published for radare2.

CVE-2017-10929[0]:
| The grub_memmove function in shlr/grub/kern/misc.c in radare2 1.5.0
| allows remote attackers to cause a denial of service (heap-based buffer
| overflow and application crash) or possibly have unspecified other
| impact via a crafted binary file, possibly related to a read overflow
| in the grub_disk_read_small_real function in kern/disk.c in GNU GRUB
| 2.02.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-10929
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10929
[1] https://github.com/radare/radare2/issues/7855
[2] 
https://github.com/radare/radare2/commit/c57997e76ec70862174a1b3b3aeb62a6f8570e85

Regards,
Salvatore

Bug#695517: lfm: after executing a file, needing a refresh of pans

[Daniel Echeverry]

tags 695517 + moreinfo unreproducible
thanks

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#867280: dput: mentors.debian.net should allow UNRELEASED packages

[Ben Finney]

Control: tags -1 + confirmed

On 05-Jul-2017, Tom Fitzhenry wrote:

> mentors.debian.net allows UNRELEASED packages[0], but the
> mentors.debian.net block in /etc/dput.cf does not allow UNRELEASED
> packages.

Thank you for the report.

More specifically, the default ‘allowed_distributions’ (in the
‘DEFAULT’ section) specifically excludes “UNRELEASED”, and the
‘mentors.debian.net’ section does not override that option.

> Alleviating the need for prospective maintainers to create
> ~/.dput.cf is one step towards a smoother contribution experience.

I think the regular expression should not allow every value. I will
look for a pattern that is still restrictive while also allowing
“UNRELEASED”.

-- 
 \ “Dyslexia means never having to say that you're ysror.” |
  `\—anonymous |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#867368: systemd-udevd: delays boot for 2+ minutes when LVM PV is inside a LV

[Rob Leslie]

Package: udev
Version: 232-25
Severity: important
File: /lib/systemd/systemd-udevd

Dear Maintainer,

After upgrading to stretch I've discovered that some machines are taking a
long time to boot -- more than two minutes -- with no immediately obvious
cause. For example:

> % systemd-analyze
> Startup finished in 2min 55.491s (kernel) + 13.076s (userspace) = 3min 8.568s

During most of this time, nothing appears on the console except a cursor.
Kernel and system logs show nothing to pinpoint the issue other than long
time gaps, e.g.:

> [3.194336] clocksource: Switched to clocksource tsc
> [  121.499692] md: linear personality registered for level -1

Adding 'debug' to the kernel command line however I got this clue:

> [   64.386629] systemd-udevd[88]: seq 905 '/devices/virtual/block/dm-5' is 
> taking a long time

After some further investigation it appears the problem stems from having an
LVM PV inside another LV. Here is how I am able to recreate the problem on a
fresh stretch install:

> # lvcreate -n pvtest -L 1g $vg
> # pvcreate /dev/$vg/pvtest

(where $vg is some existing volume group name)

Now rebooting the system will result in the long boot delay.

This sort of setup did not cause any problems in jessie. An obvious workaround
is not to put PVs inside other LVs, but this is sometimes a convenient
arrangement and I would hope it could be made to work without an excessive
boot delay.

Thanks.


-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser  3.115
ii  dpkg 1.18.24
ii  libacl1  2.2.52-3+b1
ii  libblkid12.29.2-1
ii  libc62.24-11+deb9u1
ii  libkmod2 23-2
ii  libselinux1  2.6-3+b1
ii  libudev1 232-25
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3
ii  util-linux   2.29.2-1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  232-25

-- no debconf information

Bug#867299: [Pkg-zfsonlinux-devel] Bug#867299: Bug#867299: zfs-dkms: Unable to expand a pool when underlying vdev has grown.

[Craig Sanders]

On Thu, Jul 06, 2017 at 01:44:27AM +0800, Aron Xu wrote:
> It's not advisable to grow a pool by increasing the vdev size, but rather
> you can add more vdevs to the pool to grow it in capacity, and it would be
> safer for your underlying data.

you can add vdevs and you can also replace the devices in a vdev with larger
devices.  Adding vdevs is faster and less work but it needs to be understood
that vdevs can never be removed once added, you will have permanently changed
the structure of your pool. Replacing the devices within a vdev requires each
drive to be replaced individually and is slow, tedious work with a lot of time
spent waiting for one resilver to finish before you can proceed with the next.


To increase the size of a vdev you have to replace ALL of its block devices
(disks, partitions, logical volumes, files, etc) with larger ones using the
'zpool replace' command.

When all devices in a vdev have been replaced with larger devices, the vdev
and thus the zpool will increase in size. e.g. to increase a raid-z made up
of 4x1TB drives to 4x2TB drives, you have to replace each drive, **one at a
time**.

The zpool will only gain the extra storage capacity when ALL drives in a vdev
have been replaced.  The same is true for, e.g., a 2-drive mirror vdev. the
same is true for a single-drive vdev with no redundancy, but it only has one
device so only one has to be replaced of course.

i.e. If have a 2x1TB mirror vdev and only replace one of the drives with a 2TB
drive, the vdev will still be only 1TB in size.  It won't become a 2TB vdev
(or increase in size at all) until you replace the 2nd 1TB drive with another
2TB or larger drive.

To enlarge a vdev that has a single 20GB device to one with 40GB, you have
to use 'zpool replace' to replace the original 20GB device with a new 40GB
device.  Note that if you simply 'zpool add' a new 40GB device to the pool you
will end up with what is effectively a RAID-0 of two vdevs, a 20GB vdev and a
40GB vdev...you do not want to do this.

from the zpool man page:


   zpool replace [-f] [-o property=value] pool old_device [new_device]

   Replaces old_device with new_device. This is equivalent to
   attaching new_device, waiting for it to resilver, and then
   detaching old_device.

   The size of new_device must be greater than or equal to the minimum
   size of all the devices in a mirror or raidz con‐ figuration.

   new_device is required if the pool is not redundant. If new_device
   is not specified, it defaults to old_device.  This form of
   replacement is useful after an existing disk has failed and has
   been physically replaced. In this case, the new disk may have the
   same /dev path as the old device, even though it is actually a
   different disk.  ZFS recognizes this.

   -f Forces use of new_device, even if its appears to be in use. Not
  all devices can be overridden in this manner.

   -o property=value Sets the given pool properties. See the
  "Properties" section for a list of valid properties that can be
  set.  The only property supported at the moment is ashift.  Do
  note that some properties (among them ashift) are not inherited
  from a previous vdev. They are vdev specific, not pool specific.



Note that for large pools with lots of drives it is faster and simpler and
less prone to human error (and disk failures while resilvering) to create a
completely new, larger, zpool, use 'zfs send' to transfer the contents of the
old pool, and then retire the old one.

craig

--
craig sanders 

Bug#817054: lfm crash at launch (or while using it)

[Daniel Echeverry]

tags 817054 + moreinfo unreproducible
thanks

Hi

Could you try with lfm 3.0?

Regards.

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

You Cc:-ed "BOINC Developers Mailing List "
but that rejected my reply with:

> You must subscribe to this email list in order to post to it.

Please don't Cc lists which require subscription in messages to Debian
bugs.

And if you want the list to see my reply, please forward it.

Cheers,
Olly

Bug#867361: sitesummary: Fix autopkgtest to work in environments with http_proxy set

[Steve Langasek]

On Wed, Jul 05, 2017 at 05:02:43PM -0700, Steve Langasek wrote:
> Package: sitesummary
> Version: 0.1.28
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu artful ubuntu-patch

> Dear maintainers,

> Thanks for the work on improving the autopkgtest for sitesummary in recent
> uploads.

> In Ubuntu, sitesummary has been stuck at version 0.1.21 because this is the
> last version of the package with an autopkgtest that didn't confirm the
> results on disk; and the autopkgtest does not actually correctly test
> sitesummary in an Ubuntu environment because http_proxy is set on our test
> runners and so the test case is talking to a squid proxy instead of to the
> local apache.

> I have just uploaded the attached patch to Ubuntu, which should make the
> autopkgtest work in the face of http_proxy (results will soon be visible at
> http://autopkgtest.ubuntu.com/packages/s/sitesummary/artful/amd64).

> Please consider including the patch in Debian as well.

FWIW this does fix the problem with the test talking to the wrong server,
but the test still fails as shown at
.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#867365:

[Gavin Lambert]

Apologies for the formatting of the prior message -- I was expecting
reportbug --bodyfile to either accept the message as-is or start an editor
after prepending the template.  Its current behaviour seems entirely
unhelpful.

Anyway, possibly this is related to #867259 (or #867262, which seems to be
a dupe).  Did someone upstream break serial ports in general?

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

On Wed, Jul 05, 2017 at 05:53:14PM +0200, Christian Beer wrote:
> I'm not sure I fully understand the issue. So I'll try to explain what I
> understood.
> 
> Debian is going to remove the package "libwebkitgtk-1.0-0" in testing
> (buster) which will also remove the package "libwxgtk-webview3.0-0v5"
> which is a dependency for package "boinc-manager" which means
> "boinc-manager" will have a broken dependency.
> 
> One possible fix is to rebuild the package "libwxgtk-webview3.0-0v5"
> using GTK3 which means all wxWidgets packages need to be rebuilt too.
> Since "boinc-manager" is the only package using
> "libwxgtk-webview3.0-0v5" you want to rather drop webview support on
> Debian than rebuilding wxWidgets.

That's rather misinterpreting the situation.

We can't sanely release libwebkitgtk-1.0-0 with buster, because its
not been maintained for ages, and that's highly problematic for a
browser stack.  But the buster release is likely be 1.5-2 years from
now so we have time to address this.

To switch to a maintained version of webkitgtk we need to migrate to
using wxWidgets built with GTK3.  The "rebuild" part is easy, but
switching to GTK3 is known to cause incompatibilities with some programs
using wxWidgets, or at least it's known it did - the problems may have
been fixed by newer versions of wxWidgets and/or those programs.  But
we can't know without a lot of testing.

The libwebkitgtk-1.0-0 maintainer suggested just dropping
libwxgtk-webview3.0-0v5 now, so I asked Gianfranco how that would
affect boinc (I had no idea if it was a key feature, or some optional
extra - it seems more the former) since if we drop it now, it will
affect users of boinc from Debian unstable and testing until the
transition to wx with GTK3 is ready to begin.

For some reason he's chosen to escalate this to boinc upstream, whereas
really it's more of an internal Debian issue.

> So our (BOINC's) options are rather limited in order to keep
> "boinc-manager" working on Debian. We can start to look for an
> alternative to wxWebView or disable it on Debian. But disabling is not
> an option since we use wxWebView to communicate to the users of
> boinc-manager via this simple but effective in-app browser. We also have
> a tool that uses wxWebView to show a HTML page as a screensaver which is
> easy for scientific projects to use.

There's wxHtmlWindow which comes as standard, but it's not a full
web stack (e.g. no javascript, doesn't really support CSS IIRC).

> Please correct me if I'm wrong and/or give some more options. I'm a bit
> puzzled as to the fact that this feature of wxWidgets is not used by
> more packages. Is there a history available which packages depended on
> "libwxgtk-webview3.0-0v5" in the past so one can find out what they did?

Debian doesn't track such history explicitly.  If you really want to
know I think you'd have to mine that information from
snapshot.debian.org (which would involve fetching and unpacking a lot of
package files).

I think poedit did briefly (perhaps only in experimental) but it dropped
it.  Gianfranco is also involved in maintaining that, so probably knows
the details.  I'm not aware of any other package that has, and the
webview package was only created because boinc used it.

Cheers,
Olly

Bug#867367: imagemagick: CVE-2017-10928

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: patch security upstream fixed-upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/539

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-10928[0]:
| In ImageMagick 7.0.6-0, a heap-based buffer over-read in the
| GetNextToken function in token.c allows remote attackers to obtain
| sensitive information from process memory or possibly have unspecified
| other impact via a crafted SVG document that is mishandled in the
| GetUserSpaceCoordinateValue function in coders/svg.c.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-10928
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10928
[1] https://github.com/ImageMagick/ImageMagick/issues/539

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#867366: installation-reports: Kernel panic: null pointer derefence at (null), first boot after install

[Ed Peguillan III]

Package: installation-reports
Severity: critical
Tags: d-i
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?

Image of panic (after installing stable): https://i.imgur.com/4uTKicf.jpg

I reformatted my computer and tried installing Debian Testing.
The very first reboot led to the kernel panic shown in the imgur image. I
reformatted again, this time trying Debian 9.0 Stable from the link
given in "Image version": debian-9.0.0-amd64-netinst.iso. I got the
exact same kernel panic shown in the imgur image.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I simply installed Debian stable and rebooted.

   * What was the outcome of this action?

   I got a kernel panic about 6.7 seconds after booting. No time to
   login or anything, it seems to happen instantaneously after the tty
   shows the "login:" prompt.

   * What outcome did you expect instead?

   I hoped to have a working system.

-- Package-specific info:

Boot method: USB
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.0.0-amd64-netinst.iso
Date: 5 July, 2017

Machine: Motherboard: Gigabyte EP45-UD3P (I can get more information if
needed)

Partitions: 

During install, I wiped and created a new partition table on the hard
drive to hold Debian. I created a single extended partition covering the
entire drive, then a single ext4 partition covering that entire extended
partition. This partition served as mountpoint for /. I set root's
reserved block percentage to 0%.

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

ALL WERE OK

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

Comments/Problems: All parts of the install completed successfully, but
I don't think Debian was installed properly, or there is some other
issue that needs to be resolved. I get a kernel panic upon the first
boot after install.



No indications given during the install that anything was wrong.
-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

IT may be difficult to get you these logs. I'll try to get them via an
Ubuntu liveUSB or something.

Once you have filled out this report, mail it to sub...@bugs.debian.org.


**
** THE HARDWARE SUMMARY BELOW IS NOT FOR THE AFFECTED SYSTEM,
** ONLY FOR THE COMPUTER I SUBMITTED THE REPORT FROM.
**

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170620-00:06"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux steinsgate 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core 
processor DRAM Controller [8086:0154] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd 
Gen Core processor PCI Express Root Port [8086:0151] (rev 09)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen 
Core processor Graphics Controller [8086:0166] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21f4]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM 
Gigabit Network Connection [8086:1502] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: 

Bug#851371: libllvm3.9-dbg: lots of "Could not find DWO" and "in read in psymtab, but not in symtab" warnings

[Nicolás Alvarez]

This doesn't prevent breakpoints, but it seems to prevent inspecting
local variables. Running "bt full" in gdb says "no locals" for every
stack frame in LLVM or Clang libraries.

By the way, this bug seems to be related:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1413646

-- 
Nicolás

Bug#867104: wanna-build issue with src:perl versioned Provides

[Guillem Jover]

On Wed, 2017-07-05 at 23:02:52 +0300, Adrian Bunk wrote:
> On Wed, Jul 05, 2017 at 09:30:05PM +0200, Ralf Treinen wrote:
> > I guess I am not the only one who does not understand the consequences
> > of versionend provides, and what they mean exaxtly. Part of the problem
> > is of course that policy is still at the state of unversionend provides
> > only. I think it would be useful for many people in the project if the
> > consequences of versionend provides could be documented somewhere. For
> > instance on the dpkg wiki pages (and announcing this on debian-devel),
> > until this finds its way into policy. For instance, here are some questions
> > I have been asking myself:

This should ideally (and in principle) be all documented in the dpkg man
pages or other accompanying documents, as dpkg and its behavior should
stand alone, given that in some cases those diverge from Debian Policy,
either because of policy trailing or because policy only allows a subset
of it, and because dpkg is used beyond Debian and its policy. So I'd
consider any such omission a bug.

And in this particular case this is indeed not very well covered, and
specifically the dependency behavior in general is very thin. Something
I had already started to work on a couple of weeks ago. For starters,
I'm going to be moving all dependency information into a new
deb-dependency(7) man page (or similar), where I'll expand on the
arch-qualified and versioned Provides behaviors among others.

The three relevant commits are:

  
  
  

BTW you might also be intersted in the battery of functional tests
covering versioned Provides in:

  
  

> > 1) policy is obviously outdated when saying that a versionend dependency (or
> > conflict) only concerns relations to real packages, not virtual ones.
> > Assume we have:
> > 
> > Package: a
> > Version: 42
> > 
> > Package: b
> > Version: 73
> > Provides: a (=42)
> > 
> > Certainly, a dependency on a (=42) can be satisfied by any of these two?

Yes, satisfied.

> > 2) Assume we have:
> > 
> > Package: a
> > Depends: v (=1)
> > 
> > Package: b
> > Provides: v
> > 
> > Am I right that a cannot be installed, as b does not satisfy its
> > dependency?

Yes, unsatisfied.

> > 3) Assume we have
> > 
> > Package: a
> > Depends: v
> > 
> > Package: b
> > Provides: v (=1)
> > 
> > That one seems easy: b satisfies the dependency of a on v, so a can be
> > installed?

Yes, satisfied.

> > 4)
> > 
> > Package: a
> > Conflicts: v
> > 
> > Package: b
> > Provides: v (=1)
> > 
> > Are a and b in conflict?

Yes, conflicted.

> > 5)
> > 
> > Package: a
> > Conflicts: v (=1)
> > 
> > Package: b
> > Provides: v
> > 
> > I guess there is no conflict ?

Yes, unconflicted.

> 6)
> 
> Package: a
> Depends: p (>= 1), p (<< 2)
> 
> Package: b
> Provides: p (=1)
> 
> Package: c
> Provides: p (=2)
> 
> When a and b are installed, can c be installed without removing a?

Yes, because b is enough to satisfy the dependency. This is not a
Conflicts/Breaks field after all.

I think all of Ralf cases are already covered by the functional test
suite, I've just added the one from Adrian.

  

Thanks,
Guillem

Bug#867365: 8250_moxa: interferes with hardware

[Gavin Lambert]

Source: linux
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * 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 ***

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: root 
To: Debian Bug Tracking System 
Subject: 8250_moxa: driver causes hardware fault
Message-ID: <149930682178.1976.1310054348253285119.reportbug@nexusnpu>
X-Mailer: reportbug 7.1.7
Date: Thu, 06 Jul 2017 02:07:01 +

Source: linux
Version: 4.9.30-2+deb9u2
Severity: normal

Dear Maintainer,

After upgrading to this kernel version, my Moxa CP-132EL serial card no longer 
works correctly.

Specifically, when an application requested a baud rate of 115200, the baud 
rate actually used was 123600 (or thereabouts), and when requesting a baud rate 
of 921600, the baud rate actually used was 100 (which this card isn't 
supposed to even be capable of).

I am using the official vendor driver for this card, via a DKMS wrapper package 
that I wrote myself.  The wrapper can be found at 
https://github.com/uecasm/mxser.git (and a link to the vendor code can be found 
there too).

It appears that even loading the 8250_moxa driver causes the fault -- if it is 
loaded at boot, then I rmmod it and modprobe the mxupcie vendor driver, the 
fault remains.

(Trying to use the 8250_moxa driver by itself does not work; while it 
recognises the hardware it does not appear to communicate at any baud rate.)

I can work around the problem by blacklisting the 8250_moxa driver.

The problem also does not occur with linux-image-4.9.0-2-amd64 (4.9.13-1 
2017-02-27), which is the kernel I had been using prior to this -- it appears 
that the 8250_moxa driver was disabled in that configuration.

So it appears this driver is faulty and I would suggest disabling it again.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#867364: base: wlan configuration error crashes entire driver

[Markus]

Package: base
Severity: normal

Dear Maintainer,


I was configuring automatic wlan connectivity for my RasPi with PIXEL (Debian 
based).
I manipulated the wpa_supplicant file in /etc/wpa_supplicant directory just to
change connection priorities and made a spelling error. I Forgot closing
bracket "}" for one of the connections (the first one). When I rebooted the 
device, I found out that I had no wlan connectivity. Not only were the 
preset connections obviously missing, since the wpa_supplicant file was
effectively corrupted, but the whole wifi driver seemed to have crashed and
I could not connect to or even see any networks nearby. In fact the device
(RasPi 3 that has an inbuild wifi module) seemed to have no wifi device.

This was completely fixed by addign the missing bracket.

I thought to report this as it seems to me at least that in this kind of a 
situation the wifi driver should be able to recover from corrupted 
configuration 
file and possibly give a prompt that it indeed is corrupted, and
continue as is with default settings.



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

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

Bug#867192: [Pkg-dns-devel] Bug#867192: let systemd know about the pid file

[Daniel Kahn Gillmor]

On Tue 2017-07-04 11:52:17 -0400, Simon Deziel wrote:

> When unbound is stopped, its PID file is left behind causing subsequent
> service starts to complain like that:
>
>  unbound[178]: [178:0] warning: did not exit gracefully last time (124)
>
> Please find a patch that tells systemd where the PID is so that it can
> delete it once unbound is stopped.

Wouldn't it be preferable to not create a pidfile at all if it's not
needed?

--dkg

Bug#867135: ejabberd install fails with NO_NEW_PRIVILEGES exit code

[ozzloy]

not sure if relevant, but this initially happened during an upgrade from
jessie to stretch.

i figured the line "PrivateDevices=\n" maybe cleared whatever value the
variable held before.  maybe that used to be the case?

you're welcome for the bugreport!  i hope it's an actual bug and therefore
useful to have this here, and not just something specific to my system,
turning this into personal tech support and wasting other people's space
and time.
(free tech support, woo!)

thanks!

Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Wed, Jul 05, 2017 at 09:55:06PM +0200, Martin Steigerwald wrote:
> Dear Maintainer.
> 
> I know of this:
> 
> > Vim will load $VIMRUNTIME/defaults.vim if the user does not have a vimrc.
> > This happens after /etc/vim/vimrc(.local) are loaded, so it will override
> > any settings in these files.
> But the settings in "defaults.vim" IMHO are just *completely* broken for 
> several reasons:
> 
> 1) Maybe due to a bug in Vim regarding mouse handling with "set mouse=a" Vim 
> is just madly moving around the cursor and doing whatelse not for easily a 
> minute in a lot of freshly installed Debian 9 VMs accesses via SSH and screen 
> from Plasma´s Konsole terminal emulator.

These problems are more typically due to people/software setting
incorrect values for $TERM and/or related options in Vim ('ttymouse',
'term', etc.).  Vim can only act on the information it has, so when
that's incorrect -- garbage in, garbage out.

That being said, "set mouse=a" _is_ one setting I argued against
upstream.  I would encourage you to post your experiences and reasoning
against that setting to v...@vim.org.  I'd rather see this changed
upstream instead of piecewise changing parts of defaults.vim.

> 2) Activated mouse handling breaks copy and paste text from Plasma´s 
> clipboard 
> by… auto-indenting and what else not. I know of "set nopaste" (or what else 
> it 
> was called)… but having to activate it is an additional nuisance.

This should actually behave better once I'm able to upload a newer
version of Vim, since it knows how to use bracketed paste mode.

> 3) Vim wordwraps by default now. I wonder about how many admins will break 
> config files with long lines accidently by that new default behaviour.

I don't see anything in defaults.vim that changes 'textwidth' from its
default value of 0, so I'm not sure what you're experiencing here.
Maybe ":verbose set textwidth?" will help next time you run into this
issue.

> I think it is broken behaviour, that "defaults.vim" is loaded *after* 
> "vimrc.local". The sane default would be this order:
> 
> 1. Global vim configuration
> 2. /etc/vim/vimrc.local
> 3. $HOME/.vimrc

This _is_ the behavior.  The _only_ way that defaults.vim is used is
when $HOME/.vimrc doesn't exist.

Note that /etc/vim/vimrc.local is a Debian-specific extension of the
system-wide vimrc, to avoid conffile prompts during upgrades, so 1 & 2
are the same thing.

defaults.vim is intentionally loaded _after_ $HOME/.vimrc so that Vim
can choose not to load it when $HOME/.vimrc exists.  The situation
you're running into is that you don't have $HOME/.vimrc and therefore
are having the system-wide values adjusted by defaults.vim.

That behavior is the entire reason why I added documentation to
/etc/vim/vimrc (which one has to read to know about vimrc.local) about
how to deal with defaults.vim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#799934: [Aptitude-devel] Bug#800570: Bug#799934: aptitude: Package metadata disappears for upgradable installed packages

[Guillem Jover]

On Wed, 2017-07-05 at 14:57:25 +0200, Axel Beckert wrote:
> nandhp wrote:
> > Since there's been no activity on this bug for a couple of years, I just
> > wanted to mention that this happened to me a few days ago when I
> > upgraded to stretch. When running aptitude after upgrading the
> > distribution, obsolete/locally created packages had descriptions and
> > metadata from other packages, or even none at all in some cases.
> > 
> > However, the problem went away on its own for me too.
> 
> Thanks for the notice. I haven't seen this issue for quite a while.
> And at least the last few times I remember having noticed it, it was
> either only in derivatives (Kali IIRC) or with 3rd party repositories.
> 
> So I wonder if its related to the repository format.
> 
> Does it happen for you with official Debian repositories or with 3rd
> party repositories?

I'm not sure if this was also directed at me, but in any case, I don't
think I've ever stopped experiencing this from time to time. And it's
always been with packages coming from the main Debian archive. Although
I do have a single personal repo with a handful of packages.

Thanks,
Guillem

Bug#866511: kernel BUG at nvme/host/pci.c

[Andreas Pflug]

Am 05.07.17 um 19:31 schrieb Ben Hutchings:
> Control: reassign -1 src:linux 4.9.30-2+deb9u2
> Control: tag -1 upstream patch moreinfo
>
> On Thu, 2017-06-29 at 19:30 +0200, Andreas Pflug wrote:
>> Package: linux-image-4.9.0-3-amd64
>>
>> Version: 4.9.30-2+deb9u2
>>
>> When starting an ancient Windows Server 2003 virtual machine on a fully
>> updated stretch host, the host will crash repeatably about 10 seconds
>> after start. Kernel logging was implemented over netconsole, so I could
>> capture the kernel output stating
>>
>> kernel BUG at /build/linux-9uDFZV/linux-4.9.30/drivers/nvme/host/pci.c:495!
> A single log line is rarely enough to be useful...
>
>> Hardware is dual E5-2620v4 on Supermicro 10DRI-T with two SAMSUNG
>> MZQLW960HMJP-3 NVME disks (mdadm RAID-1).
>>
>> drivers/nvme/host/pci.c wasn't changed up to 4.11.8, the crashing
>> function nvme_setup_prps still the same in 4.12rc7, so I guess the bug
>> is still there.
> ...but I happened to see a fix that mentioned this function.
>
> This should make its way into a stable update eventually, but perhaps
> you could confirm that the attached patch fixes your problem by
> following these instructions:
> https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

The description of the patch seems very promising, but using the
4.9.30-2+deb9u2a~test kernel the bug happens as well.
Log is attached, cut after 460 lines: the last trace on CPU15 is
repeated all over again, eventually leading to "Fixing recursive fault
but reboot is needed!"

Regards,
Andreas
Jul  6 02:19:43 xen2 [20341.128619] [ cut here ]
Jul  6 02:19:43 xen2 [20341.128653] kernel BUG at 
/usr/src/kernel/linux-4.9.30/drivers/nvme/host/pci.c:495!
Jul  6 02:19:43 xen2 [20341.128684] invalid opcode:  [#1] SMP
Jul  6 02:19:43 xen2 [20341.128702] Modules linked in:
Jul  6 02:19:43 xen2  xt_physdev
Jul  6 02:19:43 xen2  br_netfilter
Jul  6 02:19:43 xen2  iptable_filter
Jul  6 02:19:43 xen2  xen_netback
Jul  6 02:19:43 xen2  xen_blkback
Jul  6 02:19:43 xen2  netconsole
Jul  6 02:19:43 xen2  configfs
Jul  6 02:19:43 xen2  bridge
Jul  6 02:19:43 xen2  xen_gntdev
Jul  6 02:19:43 xen2  xen_evtchn
Jul  6 02:19:43 xen2  xenfs
Jul  6 02:19:43 xen2  xen_privcmd
Jul  6 02:19:43 xen2  iTCO_wdt
Jul  6 02:19:43 xen2  iTCO_vendor_support
Jul  6 02:19:43 xen2  mxm_wmi
Jul  6 02:19:43 xen2  intel_rapl
Jul  6 02:19:43 xen2  sb_edac
Jul  6 02:19:43 xen2  edac_core
Jul  6 02:19:43 xen2  x86_pkg_temp_thermal
Jul  6 02:19:43 xen2  intel_powerclamp
Jul  6 02:19:43 xen2  coretemp
Jul  6 02:19:43 xen2  crct10dif_pclmul
Jul  6 02:19:43 xen2  crc32_pclmul
Jul  6 02:19:43 xen2  ghash_clmulni_intel
Jul  6 02:19:43 xen2  intel_rapl_perf
Jul  6 02:19:43 xen2  pcspkr
Jul  6 02:19:43 xen2  i2c_i801
Jul  6 02:19:43 xen2  i2c_smbus
Jul  6 02:19:43 xen2  joydev
Jul  6 02:19:43 xen2  ast
Jul  6 02:19:43 xen2  ttm
Jul  6 02:19:43 xen2  drm_kms_helper
Jul  6 02:19:43 xen2  drm
Jul  6 02:19:43 xen2  i2c_algo_bit
Jul  6 02:19:43 xen2  ixgbe
Jul  6 02:19:43 xen2  e1000e
Jul  6 02:19:43 xen2  ptp
Jul  6 02:19:43 xen2  sg
Jul  6 02:19:43 xen2  mdio
Jul  6 02:19:43 xen2  pps_core
Jul  6 02:19:43 xen2  nvme
Jul  6 02:19:43 xen2  nvme_core
Jul  6 02:19:43 xen2  mei_me
Jul  6 02:19:43 xen2  ehci_pci
Jul  6 02:19:43 xen2  ioatdma
Jul  6 02:19:43 xen2  lpc_ich
Jul  6 02:19:43 xen2  ehci_hcd
Jul  6 02:19:43 xen2  mfd_core
Jul  6 02:19:43 xen2  mei
Jul  6 02:19:43 xen2  shpchp
Jul  6 02:19:43 xen2  dca
Jul  6 02:19:43 xen2  wmi
Jul  6 02:19:43 xen2  acpi_power_meter
Jul  6 02:19:43 xen2  8021q
Jul  6 02:19:43 xen2  garp
Jul  6 02:19:43 xen2  mrp
Jul  6 02:19:43 xen2  stp
Jul  6 02:19:43 xen2  llc
Jul  6 02:19:43 xen2  button
Jul  6 02:19:43 xen2  ipmi_si
Jul  6 02:19:43 xen2  ipmi_devintf
Jul  6 02:19:43 xen2  ipmi_msghandler
Jul  6 02:19:43 xen2  drbd
Jul  6 02:19:43 xen2  lru_cache
Jul  6 02:19:43 xen2  sunrpc
Jul  6 02:19:43 xen2  ip_tables
Jul  6 02:19:43 xen2  x_tables
Jul  6 02:19:43 xen2  autofs4
Jul  6 02:19:43 xen2  ext4
Jul  6 02:19:43 xen2  crc16
Jul  6 02:19:43 xen2  jbd2
Jul  6 02:19:43 xen2  fscrypto
Jul  6 02:19:43 xen2  ecb
Jul  6 02:19:43 xen2  mbcache
Jul  6 02:19:43 xen2  raid10
Jul  6 02:19:43 xen2  raid456
Jul  6 02:19:43 xen2  libcrc32c
Jul  6 02:19:43 xen2  crc32c_generic
Jul  6 02:19:43 xen2  async_raid6_recov
Jul  6 02:19:43 xen2  async_memcpy
Jul  6 02:19:43 xen2  async_pq
Jul  6 02:19:43 xen2  async_xor
Jul  6 02:19:43 xen2  xor
Jul  6 02:19:43 xen2  async_tx
Jul  6 02:19:43 xen2  evdev
Jul  6 02:19:43 xen2  hid_generic
Jul  6 02:19:43 xen2  usbhid
Jul  6 02:19:43 xen2  hid
Jul  6 02:19:43 xen2  raid6_pq
Jul  6 02:19:43 xen2  raid0
Jul  6 02:19:43 xen2  multipath
Jul  6 02:19:43 xen2  linear
Jul  6 02:19:43 xen2  bcache
Jul  6 02:19:43 xen2  dm_mod
Jul  6 02:19:43 xen2  raid1
Jul  6 02:19:43 xen2  md_mod
Jul  6 02:19:43 xen2  sd_mod
Jul  6 02:19:43 xen2  crc32c_intel
Jul  6 02:19:43 xen2  aesni_intel
Jul  6 02:19:43 xen2  aes_x86_64
Jul  6 02:19:43 xen2  

Bug#867307: syntax/debcontrol.vim: please provide value "javascript" for field "Section"

[James McCoy]

On Wed, Jul 05, 2017 at 06:02:29PM +0200, Johannes Schauer wrote:
> Currently, the value "javascript" is not accepted by the syntax
> highlighting for debian/control files for the "Section" field even
> though "javascript" is a valid section name:

That was supposed to be fixed in 2:8.0.0134-1, but I botched the change.
"java" is being matched first and making it so the "javascript" part of
the regex is never reached.

I needed to update the file for Build-(Conflicts|Depends)-Arch anyway,
so I'll send the javascript fix upstream along with that.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#862827: licensecheck: MPL check too simple, causes false positives

[Jonas Smedegaard]

Hi Axel,

Quoting Axel Beckert (2017-05-17 15:19:48)
> the attached file is reported by licensecheck as follows:
> 
>   /tmp/dns.h: MPL GPL (v2 or later) (with incorrect FSF address)
> 
> But the only line in which the string "MPL" appears is this line:
> 
>   #define DNS_SE_CHK_NOTIMPL  0x0008
> 
> (The original example with which I ran into that issue is
> https://github.com/gamelinux/passivedns/blob/master/src/dns.h)
> 
> Please check at least that MPL is matched as word and not as simple
> substring, i.e. "\bMPL\b" or similar. But preferable the check should be
> still a little bit more sophisticated than that.

I finally took some time for this issue, and believe to have nailed it: 
Patterns now no longer consist only of abbreviation, but will need at 
least another word in front (either "the", or where applicable "gnu", or 
both), and those abbreviation patterns not part of a larger version 
pattern (like "LGPL" part of "LGPLv2") also now has a \b as stop-gap.  
Ideally the version stuff would be integral to the pattern, but that is 
for a later refactoring - these minor changes should catch most 
annoyances like the one reported, I believe.

3.0.30 was released to CPAN few hours ago, and when reports from 
cpantesters arrive (assuming their are not bad) I'll release to Debian.

Thanks for reporting!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#867137: mariadb-server-10.1: mariadb install fails with NO_NEW_PRIVILEGES

[ozzloy]

steps that allowed me to successfully install mariadb-server
- put the following contents into the mariadb service unit file
#+BEGIN_SRC
[Service]
PrivateDevices=false
NoNewPrivileges=false

#+END_SRC
- install mariadb-server

example:
ozzloy:~/ $ sudo systemctl edit mariadb.service
ozzloy:~/ $ cat /etc/systemd/system/mariadb.service.d/override.conf
[Service]
PrivateDevices=false
NoNewPrivileges=false

ozzloy:~/ $ sudo apt-get install -y mariadb-server


* summary of actions
- attempted mariadb-server install fails without override.conf
- uninstall mariadb-server-10.1
- add mariadb systemd configuration
- clean install mariadb-server with override.conf in place ahead of time


* full output of terminal, broken into sections
##
##
** attempted mariadb-server install fails without override.conf
ozzloy:~/ $ sudo rm /etc/systemd/system/mariadb.service.d/override.conf
ozzloy:~/ $ sudo apt-get install -y mariadb-server
[16:11:46]
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  galera-3 mariadb-server-10.1 mariadb-server-core-10.1 socat
Suggested packages:
  mariadb-test netcat-openbsd tinyca
The following NEW packages will be installed:
  galera-3 mariadb-server mariadb-server-10.1 mariadb-server-core-10.1 socat
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/11.8 MB of archives.
After this operation, 109 MB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package galera-3.
(Reading database ... 228172 files and directories currently installed.)
Preparing to unpack .../galera-3_25.3.19-2_amd64.deb ...
Unpacking galera-3 (25.3.19-2) ...
Selecting previously unselected package mariadb-server-core-10.1.
Preparing to unpack .../mariadb-server-core-10.1_10.1.23-9+deb9u1_amd64.deb
...
Unpacking mariadb-server-core-10.1 (10.1.23-9+deb9u1) ...
Selecting previously unselected package socat.
Preparing to unpack .../socat_1.7.3.1-2+b1_amd64.deb ...
Unpacking socat (1.7.3.1-2+b1) ...
Selecting previously unselected package mariadb-server-10.1.
Preparing to unpack .../mariadb-server-10.1_10.1.23-9+deb9u1_amd64.deb ...
/var/lib/mysql: found previous version 10.1
Unpacking mariadb-server-10.1 (10.1.23-9+deb9u1) ...
Selecting previously unselected package mariadb-server.
Preparing to unpack .../mariadb-server_10.1.23-9+deb9u1_all.deb ...
Unpacking mariadb-server (10.1.23-9+deb9u1) ...
Setting up mariadb-server-core-10.1 (10.1.23-9+deb9u1) ...
Setting up socat (1.7.3.1-2+b1) ...
Setting up galera-3 (25.3.19-2) ...
Processing triggers for systemd (232-25) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up mariadb-server-10.1 (10.1.23-9+deb9u1) ...
Job for mariadb.service failed because the control process exited with
error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
invoke-rc.d: initscript mysql, action "start" failed.
● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-07-05 16:12:24 PDT;
15ms ago
  Process: 22411 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS
$_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited,
status=227/NO_NEW_PRIVILEGES)
  Process: 22319 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ]
&& VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl
set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
status=0/SUCCESS)
  Process: 22315 ExecStartPre=/bin/sh -c systemctl unset-environment
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 22312 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d
/var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 22411 (code=exited, status=227/NO_NEW_PRIVILEGES)

Jul 05 16:12:24 ozzloy.lifeafterking.org systemd[1]: Starting MariaDB
databas…..
Jul 05 16:12:24 ozzloy.lifeafterking.org systemd[22411]: mariadb.service:
Fai…nt
Jul 05 16:12:24 ozzloy.lifeafterking.org systemd[1]: mariadb.service: Main
pr…ES
Jul 05 16:12:24 ozzloy.lifeafterking.org systemd[1]: Failed to start
MariaDB …r.
Jul 05 16:12:24 ozzloy.lifeafterking.org systemd[1]: mariadb.service: Unit
en…e.
Jul 05 16:12:24 ozzloy.lifeafterking.org systemd[1]: mariadb.service:
Failed …'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package mariadb-server-10.1 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mariadb-server:
 mariadb-server depends on mariadb-server-10.1 (>= 10.1.23-9+deb9u1);
however:
  Package mariadb-server-10.1 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 

Bug#867363: d/t/basic: do not assume local filesystem size supports ocfs2 blocksize

[Nishanth Aravamudan]

Package: ocfs2-tools
Version: 1.8.5-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

- d/t/basic: do not assume local filesystem blocksize will support
  the mkfs.ocfs2 blocksize (e.g., 4k disks will not support a 1k
  blocksize).

Thanks for considering the patch.

*** /tmp/tmpUzk4dx/ocfs2-tools_1.8.5-1ubuntu1.debdiff
diff -Nru ocfs2-tools-1.8.5/debian/tests/basic 
ocfs2-tools-1.8.5/debian/tests/basic
--- ocfs2-tools-1.8.5/debian/tests/basic2016-10-21 09:24:13.0 
-0700
+++ ocfs2-tools-1.8.5/debian/tests/basic2017-07-05 17:21:52.0 
-0700
@@ -16,7 +16,7 @@
 
 # test tools
 echo "=== mkfs ==="
-mkfs.ocfs2 --force --mount local $DISK 2>&1
+mkfs.ocfs2 --force --mount local --block-size $(stat -f $DISK --format='%s') 
$DISK 2>&1
 
 echo "=== fsck ==="
 yes | fsck.ocfs2 -f -y -F $DISK 2>&1


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

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

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#867362: isc-dhcp-server: DHCP server does not start after upgrade to Stretch

[Lasse Leegaard]

Package: isc-dhcp-server
Version: 4.3.5-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   Upgrade from an fully updated Jessie to Stretch. DHCP server was working 
before upgrade
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I have tested a Jessie->Stretch upgrade on a minimal installation and 
also did a fresh installation of isc-dhcp-server after upgrade
   * What was the outcome of this action?
   isc-dhcp-server does not start even with a default config
   * What outcome did you expect instead?
   I would have expected that the server would start with default config 
and also with my rather simple configuration


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

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

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  debianutils4.8.1.1
ii  libc6  2.24-11+deb9u1
ii  libdns-export162   1:9.10.3.dfsg.P4-12.3
ii  libirs-export141   1:9.10.3.dfsg.P4-12.3
ii  libisc-export160   1:9.10.3.dfsg.P4-12.3
ii  lsb-base   9.20161125

Versions of packages isc-dhcp-server recommends:
ii  isc-dhcp-common  4.3.5-3
ii  policycoreutils  2.6-3

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  
pn  policykit-1   

-- debconf information:
  isc-dhcp-server/interfaces:

Bug#865303: LibreOffice Writer still closes silently on 32-bit Stretch and Sid

[Ben Hutchings]

On Mon, 2017-07-03 at 19:36 +0300, Nrbrtx wrote:
> Last fixes are great for Scilab and C-Java test program from launchpad bug (
> https://bugs.launchpad.net/bugs/1700270),
> but LibreOffice Writer still closes silently on 32-bit Debian:
> 1. Debian 9 (stretch) with linux-image 4.9.30-2+deb9u2, but works with
> 4.9.30.2.
> 2. Debian sid with linux-image 4.11.6-1, but works with 4.9.30-2.
> 
> Please note:
> 1. Libreoffice Writer works normally if I manually disable Java on 32bit
> Debian (Libreoffice: Tools -> LibreOffice -> Advanced -> uncheck 'Use a
> Java runtime environment'. It reports here
> /usr/lib/jvm/java-8-openjdk-i386/jre).
> 2. Libreoffice Writer run normally on 64-bit Debian 9 with latest kernel
> (4.9.30-2+deb9u2).
> 
> So there is a problem between new kernel and Libreoffice Java bindings on
> 32-bits.
> Guys from Manjaro (
> https://forum.manjaro.org/t/libreoffice-writer-fail-after-system-upgrade-solved/26623)
> say, that it is 32bit problem too.
> Guys from Arch have had the same problem with Libreoffice 5.2.7 (see
> https://bbs.archlinux.org/viewtopic.php?id=227597).
> 
> 
> Please fix LibreOffice Writer problem on 32bit Debian.

I've been discussing this regression with upstream develo[pers.  It's
now understood and we have several possible fixes but we have not yet
settled on the best one.

You should also be able to work around it by temporarily disabling the
Stack Clash fix using the kernel parameter stack_guard_gap=1

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Bug#867361: sitesummary: Fix autopkgtest to work in environments with http_proxy set

[Steve Langasek]

Package: sitesummary
Version: 0.1.28
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear maintainers,

Thanks for the work on improving the autopkgtest for sitesummary in recent
uploads.

In Ubuntu, sitesummary has been stuck at version 0.1.21 because this is the
last version of the package with an autopkgtest that didn't confirm the
results on disk; and the autopkgtest does not actually correctly test
sitesummary in an Ubuntu environment because http_proxy is set on our test
runners and so the test case is talking to a squid proxy instead of to the
local apache.

I have just uploaded the attached patch to Ubuntu, which should make the
autopkgtest work in the face of http_proxy (results will soon be visible at
http://autopkgtest.ubuntu.com/packages/s/sitesummary/artful/amd64).

Please consider including the patch in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sitesummary-0.1.28/debian/tests/test-server-client 
sitesummary-0.1.28ubuntu1/debian/tests/test-server-client
--- sitesummary-0.1.28/debian/tests/test-server-client  2017-01-07 
04:36:53.0 -0800
+++ sitesummary-0.1.28ubuntu1/debian/tests/test-server-client   2017-07-05 
16:56:28.0 -0700
@@ -14,6 +14,8 @@
 LC_ALL=C
 export LC_ALL
 
+unset http_proxy
+
 # Installing the binary packages should set up apache on localhost and
 # the cgi script for the sitesummary collector.  But some times the
 # install does not do this, because the apt system is sorting the

Bug#866629: debian-installer: Installer showes Debootstrap Error debian stretch live installation

[Brian Potkin]

On Thu 06 Jul 2017 at 02:13:57 +0530, Prahlad Yeri wrote:

> On Wed, 5 Jul 2017 20:24:20 +0100
> Brian Potkin  wrote:
> 
> > On Thu 06 Jul 2017 at 00:35:21 +0530, Prahlad Yeri wrote:
> > 
> > > Can confirm this bug on the live installer - tried both XFCE and
> > > LXDE versions.
> > > 
> > > Never expected such goof up on a debian stable version!
> > > Granted that its just released, but we do go through ages of testing
> > > before reaching stable, don't we? The reason a user comes to debian
> > > in the first place is stability. If you don't even get that, then
> > > what is the rationale for using debian stable against something
> > > like Ubuntu LTS where you get both stability and newer packages?  
> > 
> > Your question (after the rhetorical first one) is probing. Debian has
> > never had bugs before. We do not know how this managed to creep in. We
> > will try better.
> 
> Sorry, didn't intend to hurt your feelings, just trying to raise my
> concerns as a user and trying to understand the process. I don't know
> how the testing process works at debian, but If I were making the point
> release of a distro, one of the basic things I'd check is whether the
> ISO installs work on an actual physical machine (not in a VM) - and
> doing so would have helped catch this bug as there are usually no
> network resources (like wifi, etc.) configured at boot time that could
> have provided internet connectivity (in which case, it used to work and
> the bug wasn't apparent).

I subscribe to and read -user, where quite a large number of posts have
recently discussed the state of installing from a live image. I have
also seen reports of the efforts being made to mitigate the situation,
particularly by Steve McIntyre. So I became a bit grumpy, a mood which
is not good when contributing to a bug report. Apologies if I gave the
impression user contributions are unwelcome.

Perhaps

  https://lists.debian.org/debian-devel/2017/06/msg00335.html

brings some perspective to the matter. The more users who use live
images and report bugs in the pre-release phase, the better the image
quality will become.

-- 
Brian.




> 
> I understand that bugs are a part of the linux distro life cycle, but
> I did not expect something as basic as an install process to falter.
> But again, maybe I'm wrong about the bug being so apparent, and its
> just easy to say this in hindsight.
> 
> No offence meant, have a nice day!
> 
> -- 
> Regards,
> Prahlad

Bug#837031:

[Fabián Inostroza]

Hi,

It's me again, somebody in the gnome bug report (see [1]) found the commit
that caused this behaviour, could the Debian mantainers apply a patch to
revert that commit?, there is no activity
from GNOME developers in the bug report (don't know if they talk about it
in mailing lists).

This single click behaviour also happens when selecting a drive on "Other
places" of the file dialog.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=758065#c19

Bug#832940: submitter's address bounces

[Adam Borowski]

- Forwarded message from Mail Delivery System  
-
From: Mail Delivery System 
To: kilob...@angband.pl

  j...@ubuntubsd.org
all relevant MX records point to non-existent hosts

- End forwarded message -

And indeed:
http://ubuntubsd.org is a working redirect to www.ubuntubsd.org which
doesn't exit (no A/ records).

ubuntubsd.org has MX mail.ubuntubsd.org, which has no A/ records either.


-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#867359: xfce4-pulseaudio-plugin icon is too large

[Sebastian Pochert]

Package: xfce4-pulseaudio-plugin
Version: 0.2.5-1
Severity: minor
Tags: patch

Dear Maintainer,

the icon of the plugin is larger than the icons of other xfce4-panel plugins.

It can be fixed with
"#pulseaudio-button { padding: 3px; }"
in
~/.config/gtk-3.0/gtk.css

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

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

Versions of packages xfce4-pulseaudio-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-12
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.20-1
ii  libdbus-glib-1-2 0.108-2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgtk-3-0   3.22.16-1
ii  libkeybinder-3.0-0   0.3.1-1
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpulse-mainloop-glib0  10.0-2
ii  libpulse010.0-2
ii  libxfce4panel-2.0-4  4.12.1-2
ii  libxfce4ui-2-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

Versions of packages xfce4-pulseaudio-plugin recommends:
ii  pavucontrol  3.0-3.1
ii  pulseaudio   10.0-2

xfce4-pulseaudio-plugin suggests no packages.

Bug#867360: tomboy: either drop gmime or switch to mimekit?

[Daniel Kahn Gillmor]

Package: tomboy
Version: 1.15.4-1
Control: affects -1 gmime

I note that tomboy Depends on libgmime-2.6-cil.

gmime's upstream (Jeffrey Stedfast) has dropped support for mono in the
latest major release (3.0.0), and recommends transitioning to MimeKit
instead (which is also maintained by Jeffrey).

  http://www.mimekit.net/

I recommend that tomboy either switch to MimeKit (which is not currently
packaged for debian -- perhaps it needs an ITP) or drop the use of gmime
altogether (e.g. by patching out the Evolution Note Addin).

  --dkg

Bug#867358: golang-github-pelletier-go-toml FTBFS on mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address

[Adrian Bunk]

Source: golang-github-pelletier-go-toml
Version: 1.0.0-1
Severity: serious

https://buildd.debian.org/status/package.php?p=golang-github-pelletier-go-toml=sid

...
   dh_auto_test -a -O--buildsystem=golang
go test -v -p 4 github.com/pelletier/go-toml 
github.com/pelletier/go-toml/cmd github.com/pelletier/go-toml/cmd/tomljson 
github.com/pelletier/go-toml/cmd/tomll github.com/pelletier/go-toml/query
go build github.com/davecgh/go-spew/spew: /usr/bin/mips-linux-gnu-gccgo-7: 
waitid: bad address
FAILgithub.com/pelletier/go-toml [build failed]
?   github.com/pelletier/go-toml/cmd[no test files]
...

Bug#867357: ratbagd FTBFS: Dependency "python3" not found

[Adrian Bunk]

Source: ratbagd
Version: 0.4-1
Severity: serious

https://buildd.debian.org/status/package.php?p=ratbagd=sid

...
ative dependency libudev found: YES 233
Native dependency libsystemd found: YES 233
Native dependency libratbag found: YES 0.9.0
Library m found: YES
Configuring ratbagd.service using configuration
Configuring org.freedesktop.ratbag1.service using configuration
Dependency python3 found: NO

Meson encountered an error in file meson.build, line 134, column 0:
Dependency "python3" not found

Bug#867345: gmime transition to 3.0

[Daniel Kahn Gillmor]

Package: src:gmime
Severity: wishlist
Control: affects -1 gmime
Control: clone -1 -2
Control: reassign -2 asterisk 1:13.14.1~dfsg-2
Control: retitle -2 asterisk: please transition to gmime 3.0
Control: clone -1 -3
Control: reassign -3 balsa 2.5.3-2
Control: retitle -3 asterisk: please transition to gmime 3.0
Control: clone -1 -4
Control: reassign -4 gambas3 3.9.2-1
Control: retitle -4 gambas3: please transition to gmime 3.0
Control: clone -1 -5
Control: reassign -5 geary v0.11.3-1
Control: retitle -5 geary: please transition to gmime 3.0
Control: clone -1 -6
Control: reassign -6 grilo-plugins 0.3.4-2
Control: retitle -6 grilo-plugins: please transition to gmime 3.0
Control: clone -1 -7
Control: reassign -7 mail-notification 5.4.dfsg.1-14
Control: retitle -7 mail-notification: please transition to gmime 3.0
Control: clone -1 -8
Control: reassign -8 maildir-utils 0.9.18-1
Control: retitle -8 maildir-utils: please transition to gmime 3.0
Control: clone -1 -9
Control: reassign -9 notmuch 0.24.2-2
Control: retitle -9 notmuch: please transition to gmime 3.0
Control: clone -1 -10
Control: reassign -10 pan 0.141-2
Control: retitle -10 pan: please transition to gmime 3.0
Control: clone -1 -11
Control: reassign -11 pinot 1.05-1.2
Control: retitle -11 pinot: please transition to gmime 3.0
Control: clone -1 -12
Control: reassign -12 totem-pl-parser 3.10.8-1
Control: retitle -12 totem-pl-parser: please transition to gmime 3.0
Control: block -1 with -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12

Hi there!

The your debian package build-depends on libgmime-2.6-dev.

gmime 3.0.1 is now in debian unstable, and it provides libgmime-3.0-dev.
Version 3 of gmime has been in debian experimental for a couple months
now.

Please try to convert your debian packages to use libgmime-3.0-dev in
unstable if possible, so that we can avoid shipping gmime 2.6 in buster.

If you run into trouble with the transition, you might want to take a
look at gmime's porting guide from 2.6 to 3.0:

 https://github.com/jstedfast/gmime/blob/master/PORTING

If this transition won't be possible for your package, please follow up
to this bug report and we can discuss options.  It would be great to not
have to keep gmime 2.6 in debian buster, but i will keep that option
open just in case something is really unportable.

You might also be interested in:

https://release.debian.org/transitions/html/auto-gmime.html

Regards,

--dkg

Bug#832940: can't reproduce

[Adam Borowski]

Control: tags -1 +unreproducible moreinfo

Hi!
I can't seem to reproduce your problem -- neither by running dbus-daemon nor
by reading the code.  It seems to work fine for me.

In fact, both start-stop-daemon and supervise-daemon do the following:
  for (i = getdtablesize() - 1; i >= 3; --i)
  close(i);
and unless I'm missing something, that's the only code that closes a
descriptor it did not open.

I've tried 0.21-1 and 0.27-1; most of my testing was on Linux but I tried
kfreebsd as well.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#820519: sitecopy: fails to accept SSL certificates issued by a CA (Let's Encrypt)

[Francesco Poli]

Control: severity -1 grave


On Mon, 24 Apr 2017 21:57:06 +0200 Francesco Poli wrote:

> On Sun, 19 Feb 2017 12:34:20 +0100 Francesco Poli wrote:
> 
> > On Fri, 4 Nov 2016 19:33:04 +0100 Francesco Poli wrote:
> > 
> > > On Fri, 04 Nov 2016 08:07:44 +0100 Christian Marillat wrote:
> > > 
> > > > On 02 nov. 2016 23:22, Francesco Poli  wrote:
> [...]
> > > > > Do you mean that I should notice that no new upstream version has been
> > > > > released since 2008?
> > > > 
> > > > Yes.
> > > 
> > > Well, that does not imply that a bug report on the Debian BTS should be
> > > left unanswered.
> > > 
> > > Is upstream really unresponsive?
> > > Have you tried forwarding my bug report upstream?!?
> > > In case upstream is indeed unresponsive, you could still fix the bug
> > > yourself, or seek help from someone else...
> > 
> > Ping?
> 
> Second ping?

Help!

On my up-to-date Debian buster box, I am no longer able to update
websites via webdav over SSL:

  $ sitecopy --update MYSITE
  sitecopy: Updating site `MYSITE' (on www.example.org in 
/dav/MYSITE/html-MYSITE/)
  sitecopy: Error: Certificate verification error: signed using insecure 
algorithm

I am still able to access the webdav server via cadaver, which does not
complain about insecure certificates, hence I assume that nothing
important changed on the server side.

I can't understand why, but sitecopy stopped working at all with webdav
over SSL.

Please help me to pinpoint the issue and/or suggest an alternative tool
that does a similar job (and supports webdav over SSL).

Looking forward to hearing back from you.
Bye.


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


pgp5mw0ZGhU3Q.pgp
Description: PGP signature

Bug#867344: intel-gpu-tools: silently dropped intel-gen4asm

[Sebastian Ramacher]

Package: intel-gpu-tools
Version: 1.19-1
Severity: important

intel-gen4asm is missing since 1.19-1. Interestingly enough, a simply rebuild
of the package causes intel-gen4asm to be built and installed. Please ensure
that this binary is always included in the package.

Cheers

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (650, 'unstable-debug'), (650, 'buildd-unstable'), (650, 
'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#867343: pgmodeler: does not support postgresql 9.6 servers

[Felipe Sateler]

Package: pgmodeler
Version: 0.8.2-1+b1
Severity: important

Pgmodeler can't connect to 9.6 servers, complaining that it is an
unsupported version.

Apparently the newer betas do support it[1].

[1] 
https://github.com/pgmodeler/pgmodeler/commit/9dc083587d296126a0f90d1525259704487c0e0e


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

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

Versions of packages pgmodeler depends on:
ii  libc6 2.24-12
ii  libgcc1   1:7.1.0-8
ii  libgl1-mesa-glx [libgl1]  17.1.4-1
ii  libpq59.6.3-3
ii  libqt5core5a  5.7.1+dfsg-4
ii  libqt5gui55.7.1+dfsg-4
ii  libqt5network55.7.1+dfsg-4
ii  libqt5printsupport5   5.7.1+dfsg-4
ii  libqt5svg55.7.1~20161021-2+b2
ii  libqt5widgets55.7.1+dfsg-4
ii  libstdc++67.1.0-8
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-3
ii  pgmodeler-common  0.8.2-1

pgmodeler recommends no packages.

pgmodeler suggests no packages.

-- no debconf information

Bug#867298: [Pkg-javascript-devel] Bug#867298: npm2deb: please bump debhelper and Standards-Version

[Jonas Smedegaard]

Quoting Johannes Schauer (2017-07-05 21:16:38)
> Quoting Jonas Smedegaard (2017-07-05 21:04:44)
> > Quoting Johannes Schauer (2017-07-05 18:26:40)
> > > Maybe I misunderstand but this bug report is not about "changing" 
> > > or "bumping" anything.
> > > 
> > > Since npm2deb creates the *initial* Debian packaging, the 
> > > situation where we start with a lower Standards-Version and then 
> > > have to verify changes before we can "bump" the Standards-Version 
> > > doesn't arise.
> > 
> > Right, this is not about single package bumping as I confusingly 
> > wrote, but instead about automated processing where it is even 
> > _more_ important to verify that the claimed Standards-Version is 
> > accurately applied, and even _more_ important to consider if newest 
> > shiny denhelper really is needed!
> 
> Lets not conflate the two issues. I assume that it's uncontroversial 
> that the newest Standards-Version should be emitted because it doesn't 
> make sense to pick any old policy version and then require the 
> maintainer to bump the version bit by bit, right?

If npm2deb maintainers has only verified that the tool comply with some 
older version of Debian Policy, then indeed the burden is on each 
maintainer using the tool to verify that the generated package comply 
with a different (newer) release of Debian Policy.

I am not against this being addressed. My point is just that addressing 
it involves actually checking that newer release of Debian Policy and 
ensuring that the tool complies with it.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#867341: xymonnet buffer overflow, breaking all network tests, when using ipv6 addresses for ping/conn test

[Nicolas Marot]

Package: xymon
Version: 4.3.28-2
Severity: normal

Dear Maintainer,


   * I was using xymon 4.3.0~beta2.dfsg-9.1+deb7u1 on Debian wheezy 7.11 and 
successfully ping some ipv6 hosts with conn6 test
   * I am migrating to xymon 4.3.28-2 on Debian 9 and conn6 does not work 
anymore (tests are purple)
 So I decided to put my ipv6s to conn=worst,ipv4,ipv6 like
conn=worst,163.172.93.135,2001:bc8:318d:100::1
   * I tried also with brakets around [ipv6]
   * I noticed all networks tests gone purple and reading xymonnet log, I 
discovered buffer overflow 



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

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

Versions of packages xymon depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc-ares2 1.12.0-1
ii  libc6  2.24-11+deb9u1
ii  libldap-2.4-2  2.4.44+dfsg-5
ii  libpcre3   2:8.39-3
ii  librrd81.6.0-1+b2
ii  libssl1.1  1.1.0f-3
ii  lsb-base   9.20161125
ii  perl   5.24.1-3
ii  xymon-client   4.3.28-2

Versions of packages xymon recommends:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u1
ii  nginx-full [httpd-cgi]  1.10.3-1

Versions of packages xymon suggests:
ii  rrdtool  1.6.0-1+b2

-- Configuration Files:
/etc/apache2/conf-available/xymon.conf changed [not included]
/etc/xymon/alerts.cfg changed [not included]
/etc/xymon/analysis.cfg changed [not included]
/etc/xymon/client-local.cfg changed [not included]
/etc/xymon/protocols.cfg changed [not included]

-- debconf information:
  hobbit-client/automatic-xymon-migration: true

Bug#867342: tor: /usr/bin/obfs4proxy fails to load under default combination of apparmor execution permission PUx and systemd NoNewPrivileges=Yes hardening

[Jason J. Ayala P.]

Package: tor
Version: 0.2.9.11-1~deb9u1
Severity: important

Dear Maintainer,

I was debugging why obfs4proxy was failing to load in Debian 9 (Whonix 14 
developers), 
without any helpful error messages in the log. I notice that if I changed the 
AA execution
permissions in abstractions/tor for obfsproxy to ix instead of PUx, it loads. I 
also
noticed that if I commented out or changed the systemd hardening flag 
NoNewPrivileges
inside systemd/system/tor@default.service, obfs4proxy also successfully loads.

I have no idea why or where to find any error message from systemd or apparmor 
about
the failure to load /usr/bin/obfs4proxy.

I also don't know how the hardening NoNewPrivileges and the apparmor execution
permission PUx interact to cause the failure to load obfs4proxy.

But changing PUx to ix AND/OR changing NoNewPrivileges to blank or YES, allows
obfs4proxy to load and tor to connect to an obfs4 bridge.

For now, I created a workaround for Whonix users that simply disables 
NoNewPrivileges.

-- System Information:
Distributor ID: Whonix
Description:Whonix GNU/Linux 9.0 (stretch)
Release:9.0
Codename:   stretch
Architecture: x86_64

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

Versions of packages tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libseccomp2  2.3.1-2.1
ii  libssl1.11.1.0f-3
ii  libsystemd0  232-25
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages tor recommends:
ii  logrotate3.11.0-0.1
ii  tor-geoipdb  0.2.9.11-1~deb9u1
ii  torsocks 2.2.0-1

Versions of packages tor suggests:
ii  apparmor-utils   2.11.0-3
pn  mixmaster
ii  obfs4proxy   0.0.7-1+b2
ii  obfsproxy0.2.13-2
pn  socat
ii  tor-arm  1.4.5.0-1.1
pn  torbrowser-launcher  

-- Configuration Files:
/etc/apparmor.d/abstractions/tor changed [not included]
/etc/apparmor.d/system_tor changed [not included]
/etc/default/tor changed [not included]
/etc/tor/torrc changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/systemd/system/tor@default.service (from tor package)

Bug#867302: licensecheck: incorrectly parses multi-line copyright notices

[Jonas Smedegaard]

Quoting Ximin Luo (2017-07-05 21:17:00)
> Jonas Smedegaard:
> > [..]
> > 
> > Have a look (if interested) at /usr/share/perl5/String/Copyright.pm 
> > and in particular the (huge when expanded) $signs_and_more_re at 
> > line 138.
> > 
> > [..]
> 
> Thanks for the tips! I'm not sure if you got my other follow-ups to 
> the bug report - I did in fact find String::Copyright, but I didn't 
> know about the history nor plans for it, so thanks for filling me in 
> on that.
> 
> At any rate, here is an updated version of my patch, along with some 
> test cases for Sage's copyright notices.
> 
> I did try to think of a way to achieve the same logic *inside* the 
> massive $re regexes. However I don't think this is possible, at least 
> with my current approach - which tries to be conservative in order to 
> adapt to humans being annoyingly inconsistent.
> 
> What it does is, it joins subsequent lines only when the indent is 
> greater than the main line (with the "Copyright" part). This means I 
> have to call length() in an expression-replacement, which I don't 
> think is possible to do inside a normal regex...

I did see your other emails, but only after I posted my initial reply (I 
am slow at writing emails).

I have now published App::Licensecheck 3.0.30 to CPAN, and if it 
survives CPANtesters inspections then I will release that to Debian.  
That release does not fix the topic of this bugreport, but it does fix a 
bug in that String::Copyright expects plain text as input but was passed 
text with comment markers by App::Licensecheck.  Which seems is what 
complicates your patch, so I will ask you to please try again with that 
newer App::Licensecheck to see how much you can reduce the patch.

If you want to try with the 3.0.30 release before it gets packaged for 
Debian, you can do it like this:

  sudo apt install cpanminus
  cpanm App::Licensecheck
  export PATH="$HOME/perl5/bin:$PATH"
  export PERL5LIB="$HOME/perl5/lib/perl5"

...and when done exploring (assuming you want _any_ local CPAN gone):

  rm -rf ~/perl5 ~/.cpanm

NB! It is easiest for me if you file a new bugreport for each separate 
issue - e.g. the one of not matching double-dashed year ranges.  Fine if 
you work on a patch that addresses multiple issues, but still safer to 
report the issues separately, so that I don't accidentally miss fixing 
some of it, e.g. if I choose to resolve things differently than with 
your tested patch..


> As for speed:
> 
> # with the patch
> $ time debian/rules debian/licensecheck.copyright
> licensecheck -l250 -i ^sage/build/ -r --deb-machine --merge-licenses sage > 
> "debian/licensecheck.copyright"
> 
> real0m35.318s
> user0m35.204s
> sys 0m0.056s
> 
> # without the patch
> $ time debian/rules debian/licensecheck.copyright
> licensecheck -l250 -i ^sage/build/ -r --deb-machine --merge-licenses sage > 
> "debian/licensecheck.copyright"
> 
> real0m31.168s
> user0m31.040s
> sys 0m0.076s

Thanks :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#867339: cups: Greek translation

[Vangelis Skarmoutsos]

Package: cups
Version: 2.2.3-2
Followup-For: Bug #867339

...and the .po file



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

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

Versions of packages cups depends on:
ii  cups-client2.2.3-2
ii  cups-common2.2.3-2
ii  cups-core-drivers  2.2.3-2
ii  cups-daemon2.2.3-2
ii  cups-filters   1.14.0-2
ii  cups-ppdc  2.2.3-2
ii  cups-server-common 2.2.3-2
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.21~dfsg-1
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-12
ii  libc6  2.24-12
ii  libcups2   2.2.3-2
ii  libcupscgi12.2.3-2
ii  libcupsimage2  2.2.3-2
ii  libcupsmime1   2.2.3-2
ii  libcupsppdc1   2.2.3-2
ii  libgcc11:7.1.0-7
ii  libstdc++6 7.1.0-7
ii  libusb-1.0-0   2:1.0.21-2
ii  poppler-utils  0.48.0-2
ii  procps 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon 0.6.32-2
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.14.0-2
ii  printer-driver-gutenprint5.2.12-2

Versions of packages cups suggests:
ii  cups-bsd   2.2.3-2
pn  cups-pdf   
ii  foomatic-db20161201-1
ii  hplip  3.17.6+repack0-1+b1
ii  printer-driver-hpcups  3.17.6+repack0-1+b1
ii  smbclient  2:4.6.5+dfsg-3
ii  udev   233-9

-- debconf information excluded
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the cups package.
# FIRST AUTHOR Vangelis Skarmoutsos , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: cups\n"
"Report-Msgid-Bugs-To: c...@packages.debian.org\n"
"POT-Creation-Date: 2016-12-20 08:55+0100\n"
"PO-Revision-Date: 2017-07-06 00:45+0300\n"
"Language: el\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Vangelis Skarmoutsos \n"
"Language-Team: \n"
"X-Generator: Poedit 2.0.2\n"

#. Type: boolean
#. Description
#: ../cups-bsd.templates:2001
msgid "Do you want to set up the BSD lpd compatibility server?"
msgstr "Θέλετε να ρυθμίσετε τον BSD lpd  εξυπηρετητή συμβατότητας;"

#. Type: boolean
#. Description
#: ../cups-bsd.templates:2001
msgid ""
"The CUPS package contains a server that can accept BSD-style print jobs and "
"submit them to CUPS. It should only be set up if other computers are likely "
"to submit jobs over the network via the \"BSD\" or \"LPR\" services, and "
"these computers cannot be converted to use the IPP protocol that CUPS uses."
msgstr ""
"Το πακέτο CUPS περιέχει έναν εξυπηρετητή που μπορεί να δεχτεί εργασίες "
"εκτύπωσης BSD-στυλ και να τις υποβάλλει στο CUPS. Πρέπει να ρυθμιστεί μόνο "
"αν άλλοι υπολογιστές είναι πιθανό να υποβάλουν εργασίες μέσω δικτύου με τις "
"υπηρεσίες \"BSD\" ή \"LPR\", και αυτοί οι υπολογιστές δεν μπορούν να "
"μετατραπούν ώστε να χρησιμοποιούν το πρωτόκολλο IPP, που χρησιμοποιείται "
"από το CUPS."

#. Type: boolean
#. Description
#: ../cups.templates:2001
msgid "Do you want CUPS to print unknown jobs as raw jobs?"
msgstr ""
"Θέλετε το CUPS να εκτυπώνει άγνωστες εργασίες ως ανεπεξέργαστες εργασίες;"

#. Type: boolean
#. Description
#: ../cups.templates:2001
#, fuzzy
msgid ""
"The Internet Printing Protocol (IPP) enforces a MIME type for all print "
"jobs. Since not all sources of print jobs can attach an appropriate type, "
"many jobs get submitted as the MIME type application/octet-stream and could "
"be rejected if CUPS cannot guess the job's format."
msgstr ""
"Το Διαδικτυακό Πρωτόκολλο Εκτύπωσης (IPP) εφαρμόζει ένα τύπο MIME για όλες "
"τις εργασίες εκτύπωσης. Καθώς δεν μπορούν όλες οι πηγές εργασιών εκτύπωσης "
"να προσαρτήσουν τον κατάλληλο τύπο, πολλές εργασίες υποβάλλονται ως MIME "
"type application/octet-stream και μπορεί να απορριφθούν αν το CUPS δεν "
"μπορέσει να μαντέψει την μορφή της εργασίας."

#. Type: boolean
#. Description
#: ../cups.templates:2001
msgid ""
"CUPS can handle all such jobs as \"raw\" jobs, which causes them to be sent "
"directly to the printer without processing."
msgstr ""
"Το CUPS μπορεί να χειριστεί όλες τις παρεμφερείς εργασίες ως "
"\"ανεπεξέργαστες\" εργασίες, το οποίο τις αναγκάζει να αποσταλούν απ' "
"ευθείας στον εκτυπωτή χωρίς επεξεργασία."

#. Type: boolean
#. Description
#: ../cups.templates:2001
msgid ""
"It is recommended to choose this option if the server will be accepting "
"print jobs from Windows 

Bug#867339: cups: Greek translation

[Vangelis Skarmoutsos]

Package: cups
Version: 2.2.3-2
Severity: wishlist
Tags: l10n

Dear Maintainer,

Please include Greek translation to the package.



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

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

Versions of packages cups depends on:
ii  cups-client2.2.3-2
ii  cups-common2.2.3-2
ii  cups-core-drivers  2.2.3-2
ii  cups-daemon2.2.3-2
ii  cups-filters   1.14.0-2
ii  cups-ppdc  2.2.3-2
ii  cups-server-common 2.2.3-2
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.21~dfsg-1
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-12
ii  libc6  2.24-12
ii  libcups2   2.2.3-2
ii  libcupscgi12.2.3-2
ii  libcupsimage2  2.2.3-2
ii  libcupsmime1   2.2.3-2
ii  libcupsppdc1   2.2.3-2
ii  libgcc11:7.1.0-7
ii  libstdc++6 7.1.0-7
ii  libusb-1.0-0   2:1.0.21-2
ii  poppler-utils  0.48.0-2
ii  procps 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon 0.6.32-2
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.14.0-2
ii  printer-driver-gutenprint5.2.12-2

Versions of packages cups suggests:
ii  cups-bsd   2.2.3-2
pn  cups-pdf   
ii  foomatic-db20161201-1
ii  hplip  3.17.6+repack0-1+b1
ii  printer-driver-hpcups  3.17.6+repack0-1+b1
ii  smbclient  2:4.6.5+dfsg-3
ii  udev   233-9

-- debconf information excluded

Bug#867340: Contains binary files without corresponding source

[Josh Triplett]

Package: i965-va-driver
Severity: serious

This bug applies to both stretch (1.7.3) and buster/sid (1.8.3).

i965-va-driver contains many binary compiled shaders with no
corresponding source. The Debian package needs to strip them out, which
may require modifying the driver to avoid requiring them.

A quick bit of scripting, to look for files of the form '*.g*b' without
a corresponding '*.asm' or '*.g*a' file, turned up the following list
from 1.8.3:

src/shaders/brc/bsw/hme_downscale_genx_0.g8b
src/shaders/brc/bsw/hme_genx_0.g8b
src/shaders/brc/bsw/vp8_brc_init_genx_0.g8b
src/shaders/brc/bsw/vp8_brc_reset_genx_0.g8b
src/shaders/brc/bsw/vp8_brc_update_genx_0.g8b
src/shaders/brc/bsw/vp8_enc_genx_0.g8b
src/shaders/brc/bsw/vp8_enc_genx_1.g8b
src/shaders/brc/bsw/vp8_enc_genx_2.g8b
src/shaders/brc/bsw/vp8_intra_distortion_genx_0.g8b
src/shaders/brc/bsw/vp8_mpu_genx_0.g8b
src/shaders/brc/bsw/vp8_tpu_genx_0.g8b
src/shaders/brc/skl/hme_downscale_genx_0.g9b
src/shaders/brc/skl/hme_genx_0.g9b
src/shaders/brc/skl/vp8_brc_init_genx_0.g9b
src/shaders/brc/skl/vp8_brc_reset_genx_0.g9b
src/shaders/brc/skl/vp8_brc_update_genx_0.g9b
src/shaders/brc/skl/vp8_enc_genx_0.g9b
src/shaders/brc/skl/vp8_enc_genx_1.g9b
src/shaders/brc/skl/vp8_enc_genx_2.g9b
src/shaders/brc/skl/vp8_intra_distortion_genx_0.g9b
src/shaders/brc/skl/vp8_mpu_genx_0.g9b
src/shaders/brc/skl/vp8_tpu_genx_0.g9b
src/shaders/h264/mc/avc_mc.g4b
src/shaders/post_processing/gen75/sharpening_h_blur.g75b
src/shaders/post_processing/gen75/sharpening_unmask.g75b
src/shaders/post_processing/gen75/sharpening_v_blur.g75b
src/shaders/post_processing/gen8/conv_nv12.g8b
src/shaders/post_processing/gen8/sharpening_h_blur.g8b
src/shaders/post_processing/gen8/sharpening_unmask.g8b
src/shaders/post_processing/gen8/sharpening_v_blur.g8b
src/shaders/post_processing/gen9/conv_nv12.g9b
src/shaders/post_processing/gen9/conv_p010.g9b
src/shaders/post_processing/gen9/pa_to_pa.g9b
src/shaders/post_processing/gen9/pa_to_pl2.g9b
src/shaders/post_processing/gen9/pa_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_pa.g9b
src/shaders/post_processing/gen9/pl2_to_pl2.g9b
src/shaders/post_processing/gen9/pl2_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_rgbx.g9b
src/shaders/post_processing/gen9/pl3_to_pa.g9b
src/shaders/post_processing/gen9/pl3_to_pl2.g9b
src/shaders/post_processing/gen9/pl3_to_pl3.g9b
src/shaders/post_processing/gen9/rgbx_to_nv12.g9b

1.7.3 contains the following shorter list:

src/shaders/h264/mc/avc_mc.g4b
src/shaders/post_processing/gen75/sharpening_h_blur.g75b
src/shaders/post_processing/gen75/sharpening_unmask.g75b
src/shaders/post_processing/gen75/sharpening_v_blur.g75b
src/shaders/post_processing/gen8/sharpening_h_blur.g8b
src/shaders/post_processing/gen8/sharpening_unmask.g8b
src/shaders/post_processing/gen8/sharpening_v_blur.g8b
src/shaders/post_processing/gen9/pa_to_pa.g9b
src/shaders/post_processing/gen9/pa_to_pl2.g9b
src/shaders/post_processing/gen9/pa_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_pa.g9b
src/shaders/post_processing/gen9/pl2_to_pl2.g9b
src/shaders/post_processing/gen9/pl2_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_rgbx.g9b
src/shaders/post_processing/gen9/pl3_to_pa.g9b
src/shaders/post_processing/gen9/pl3_to_pl2.g9b
src/shaders/post_processing/gen9/pl3_to_pl3.g9b
src/shaders/post_processing/gen9/rgbx_to_nv12.g9b

Bug#867338: RFS/ITP: node-rollup-plugin-json/2.3.0-1

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-rollup-plugin-json"

 * Package name: node-rollup-plugin-json
   Version : 2.3.0-1
   Upstream Author : Rich Harris
 * URL : https://github.com/rollup/rollup-plugin-json
 * License : Expat
   Section : web

  It builds those binary packages:

node-rollup-plugin-json - rollup plugin to convert JSON files to ES6
modules

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

  https://mentors.debian.net/package/node-rollup-plugin-json


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

dget -x
https://mentors.debian.net/debian/pool/main/n/node-rollup-plugin-json/node-rollup-plugin-json_2.3.0-1.dsc

  It is packaged within the Debian JavaScript Maintainer team repositories:

  Vcs-Git:
https://anonscm.debian.org/git/pkg-javascript/node-rollup-plugin-json.git
  Vcs-Browser:
https://anonscm.debian.org/cgit/pkg-javascript/node-rollup-plugin-json.git

Thanks,

Snark on #debian-js

Bug#862363: jessie-pu: package dwww/1.12.1+deb8u1

[Robert Luberda]

reopen 862363 !
thanks

Cyril Brulebois writes:

>> Could you please approve this change and allow Adrian to proceed with
>> the NMU?
>>
>> It fixes a pretty old bug in dwww that was recently made visible (and
>> thus made dwww mostly unusable) due to the security upload of apache2
>> into jessie.
> 
> This is the kind of things that should have been in the pu request. This
> should also be mentioned in the changelog. Fixing bugs is great, but
> providing explanations while doing so is even better.
> 

I can see that Adrian has closed the bug report, so I've just prepared
another version of the patch:


diff --git a/debian/changelog b/debian/changelog
index d30cd60..48f6a8d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dwww (1.12.1+deb8u1) jessie; urgency=medium
+
+  * Fix an old typo in the `Last-Modified' header name that prevents dwww
+from working correctly on systems running the latest available jessie
+version of apache2, which as a part its security update for
CVE-2016-8743
+started enforcing HTTP headers conformance with the appropriate
standards
+(closes: #850016, #850885).
+
 dwww (1.12.1) unstable; urgency=medium

   * apache.conf: add an `Alias /dwww /var/www/dwww' line to accommodate
diff --git a/scripts/dwww-convert b/scripts/dwww-convert
index a9792c5..d296d32 100755
--- a/scripts/dwww-convert
+++ b/scripts/dwww-convert
@@ -327,7 +327,7 @@ sub PrintHeaders() { # {{{
 print "Content-type: $mime_type" . (defined $mime_charset ? ";
charset=$mime_charset\n" : "\n");
 my @stat = stat( $filename );
 my $mtime = $stat[9];
-print "Last modified: " . gmtime($mtime) . "\n";
+print "Last-modified: " . gmtime($mtime) . "\n";
 print "Content-Disposition: inline; filename=\"$base_name\"\n";
 print "\n";
 } # }}}


Would this be accepted? If yes, could you please let me know how should
I upload this, as I haven't uploaded anything to stable for ages?

Regards,
robert

Bug#867337: reportbug: remove unused imports

[Markus Hackspacher]

Package: reportbug
Version: 6.6.3
Severity: minor
Tags: patch

Dear Maintainer,

have a untested patch, a diff file from 51f0ae6 add `a11y` tag.



-- Package-specific info:
** Environment settings:
INTERFACE="gtk2"

** /home/mar/.reportbugrc:
reportbug_version "6.6.3"
mode standard
ui gtk2
email "markushackspac...@gmail.com"
smtphost "smtp.gmail.com"
smtpuser "markushackspacher"
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt   1.0.9.8.4
ii  python2.7.9-1
ii  python-reportbug  6.6.3
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf-utils  1.5.56
pn  debsums
pn  dlocate
ii  emacs24-bin-common 24.4+1-5
ii  exim4  4.84.2-2+deb8u4
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u4
ii  file   1:5.22+15-2+deb8u3
ii  gnupg  1.4.18-7+deb8u3
ii  python-gtk22.24.0-4
ii  python-gtkspell2.25.3-13
pn  python-urwid   
ii  python-vte 1:0.28.2-5
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.8.4
ii  python-debian 0.1.27
ii  python-debianbts  1.12
pn  python:any

python-reportbug suggests no packages.

-- no debconf information
diff --git a/reportbug/checkversions.py b/reportbug/checkversions.py
index c7cf01c..97f6794 100644
--- a/reportbug/checkversions.py
+++ b/reportbug/checkversions.py
@@ -22,12 +22,7 @@
 #  SOFTWARE.
 
 import sys
-import os
-import re
 import urllib.request, urllib.error, urllib.parse
-import gc
-import time
-import gzip
 
 from . import utils
 from .urlutils import open_url
@@ -38,7 +33,6 @@ from reportbug.exceptions import (
 # needed to parse new.822
 from debian.deb822 import Deb822
 from debian import debian_support
-from functools import reduce
 
 RMADISON_URL = 'https://qa.debian.org/madison.php?package=%s=on'
 INCOMING_URL = 'http://incoming.debian.org/'
diff --git a/reportbug/debbugs.py b/reportbug/debbugs.py
index 1c65075..0c9df49 100644
--- a/reportbug/debbugs.py
+++ b/reportbug/debbugs.py
@@ -31,10 +31,8 @@ import io
 import glob
 import os
 import re
-import time
 import urllib.request, urllib.parse, urllib.error
 import textwrap
-import pprint
 # SOAP interface to Debian BTS
 import debianbts
 from collections import defaultdict
diff --git a/reportbug/ui/gtk2_ui.py b/reportbug/ui/gtk2_ui.py
index fe97201..2d24b73 100644
--- a/reportbug/ui/gtk2_ui.py
+++ b/reportbug/ui/gtk2_ui.py
@@ -62,7 +62,7 @@ from queue import Queue
 import threading
 import textwrap
 
-from reportbug.exceptions import NoPackage, NoBugs, NoNetwork, NoReport
+from reportbug.exceptions import NoPackage, NoBugs
 from reportbug import debbugs
 from reportbug.urlutils import launch_browser
 
diff --git a/reportbug/ui/urwid_ui.py b/reportbug/ui/urwid_ui.py
index 0443c6c..e8b5061 100644
--- a/reportbug/ui/urwid_ui.py
+++ b/reportbug/ui/urwid_ui.py
@@ -28,13 +28,11 @@ import re
 import getpass
 from reportbug.exceptions import (
 UINotImportable,
-NoPackage, NoBugs, NoNetwork, NoReport,
+NoPackage, NoBugs, NoReport,
 )
 from reportbug.urlutils import launch_browser
 from .text_ui import (
 ewrite,
-spawn_editor,
-system
 )
 from reportbug import VERSION
 
diff --git a/reportbug/utils.py b/reportbug/utils.py
index 8139668..1f669d7 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -27,7 +27,7 @@ import platform
 
 try:
 import pwd
-from .tempfiles import TempFile, tempfile_prefix, cleanup_temp_file
+from .tempfiles import TempFile, cleanup_temp_file
 except ImportError as e:
 if platform.system() == 'Windows':
 pass
@@ -41,7 +41,6 @@ import subprocess
 import pipes
 
 from .urlutils import open_url
-from string import ascii_letters, digits
 
 # Paths for dpkg
 DPKGLIB = '/var/lib/dpkg'
diff --git a/setup.py b/setup.py
index 9674b71..222370d 100755
--- a/setup.py
+++ b/setup.py
@@ -2,8 +2,6 @@
 
 from setuptools import setup
 import reportbug
-import os
-import glob
 
 # i18n = []
 # for lang in glob.glob('*.po'):
diff --git a/test/test_debbugs.py b/test/test_debbugs.py
index 28d4df0..1c8cedf 100644
--- a/test/test_debbugs.py
+++ b/test/test_debbugs.py
@@ -6,7 +6,6 @@ from 

Bug#543548: coq-doc-pdf: bookmarks and links for table of contents

[Hendrik Tews]

found 543548 coq-doc/8.4pl4-2
forwarded 543548 https://coq.inria.fr/bugs/show_bug.cgi?id=5636
thanks

Hi,

as others have noticed, the reference manual contains the
bookmarks and the links for some while already. However, the FAQ,
the Tutorial and the RecTutorial do not.

Hendrik

Bug#867336: higan: Higan Segmentation fault

[Paulo]

Package: higan
Version: 098-2+b1
Severity: important

Dear Maintainer,

I just tried to play higan but it didn't work. When I ran shows a message
segmentation fault. please look the output from terminal bellow

paulo@stretch:~$ higan
Gtk-Message: Failed to load module "canberra-gtk-module"
Segmentation fault

thanks in advanced for you time spend to helps us




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

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

Versions of packages higan depends on:
ii  libao41.2.2-1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u1
ii  libcairo2 1.14.8-1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglib2.0-0  2.50.3-2
ii  libgomp1  6.3.0-18
ii  libgtk2.0-0   2.24.31-2
ii  libgtksourceview2.0-0 2.10.5-3
ii  libopenal11:1.17.2-4+b2
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libpulse0 10.0-1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libstdc++66.3.0-18
ii  libudev1  232-25
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxv12:1.0.11-1

higan recommends no packages.

higan suggests no packages.

-- no debconf information

Bug#867335: stretch-pu: package systemd/232-25

[Michael Biebl]

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

Hi,

I'd like to make a stable upload for systemd.

All changes are already in unstable.
An annotated changelog follows:

systemd (232-25+deb9u1) stretch; urgency=medium

  [ Dimitri John Ledkov ]
  * Fix out-of-bounds write in systemd-resolved.
CVE-2017-9445 (Closes: #866147, LP: #1695546)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch-proposed=986c0be9809e6234680c001b731c5b3099f41c1c

That's probably the most important one to get into stretch.
The security team wanted us to fix this issue via a stable upload.

  [ Michael Biebl ]
  * Be truly quiet in systemctl -q is-enabled (Closes: #866579)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch-proposed=c18ed0fce975e268ebf80e2a89e870d51f9ce7b7

One line patch, regression potential is very low.

  * Improve RLIMIT_NOFILE handling.
Use /proc/sys/fs/nr_open to find the current limit of open files
compiled into the kernel instead of using a hard-coded value of 65536
for RLIMIT_NOFILE. (Closes: #865449)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch-proposed=920ec17f9390e1bef8e68be52cb153b462bb921d

This was requested by a user to be backported to stretch.

  [ Nicolas Braud-Santoni ]
  * debian/extra/rules: Use updated U2F ruleset.
This ruleset comes from Yubico's libu2f-host. (Closes: #824532)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch-proposed=f4644056a65e31ab60da2586fa994ef2285bbc73

This updates the list of devices which are U2F capable.
I expect the regression potential to be very low.

The changes shouldn't affect the installer. CCed debian-boot nonetheless for
a KiBi ack.

Full debdiff is attached.

Regards,
Michael

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index d3789db..fe1e79f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+systemd (232-25+deb9u1) stretch; urgency=medium
+
+  [ Dimitri John Ledkov ]
+  * Fix out-of-bounds write in systemd-resolved.
+CVE-2017-9445 (Closes: #866147, LP: #1695546)
+
+  [ Michael Biebl ]
+  * Be truly quiet in systemctl -q is-enabled (Closes: #866579)
+  * Improve RLIMIT_NOFILE handling.
+Use /proc/sys/fs/nr_open to find the current limit of open files
+compiled into the kernel instead of using a hard-coded value of 65536
+for RLIMIT_NOFILE. (Closes: #865449)
+
+  [ Nicolas Braud-Santoni ]
+  * debian/extra/rules: Use updated U2F ruleset.
+This ruleset comes from Yubico's libu2f-host. (Closes: #824532)
+
+ -- Michael Biebl   Wed, 05 Jul 2017 22:31:25 +0200
+
 systemd (232-25) unstable; urgency=medium
 
   * hwdb: Use path_join() to generate the hwdb_bin path.
diff --git a/debian/extra/rules/70-debian-uaccess.rules 
b/debian/extra/rules/70-debian-uaccess.rules
index 18d6137..f94948c 100644
--- a/debian/extra/rules/70-debian-uaccess.rules
+++ b/debian/extra/rules/70-debian-uaccess.rules
@@ -1,19 +1,22 @@
-# FIDO u2f devices for two-factor authentication; current clients access the
-# device directly
-ACTION!="add|change", GOTO="fido_u2f_end"
-SUBSYSTEM!="hidraw", GOTO="fido_u2f_end"
-KERNEL!="hidraw*", GOTO="fido_u2f_end"
+# this udev file should be used with udev 188 and newer
+ACTION!="add|change", GOTO="u2f_end"
 
-# FIDO u2f devices, until there is a proper kernel driver
-ATTRS{idVendor}=="1050", 
ATTRS{idProduct}=="0113|0114|0115|0116|0120|0402|0403|0406|0407|0410", 
TAG+="uaccess"
+# Yubico YubiKey
+KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", 
ATTRS{idProduct}=="0113|0114|0115|0116|0120|0402|0403|0406|0407|0410", 
TAG+="uaccess"
 
-# Happlink (formaly Plug-Up) Security KEY
-ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", TAG+="uaccess"
+# Happlink (formerly Plug-Up) Security KEY
+KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="2581", 
ATTRS{idProduct}=="f1d0", TAG+="uaccess"
 
-# Neowave Keydo
-ATTRS{idVendor}=="1e0d", ATTRS{idProduct}=="f1d0", TAG+="uaccess"
+#  Neowave Keydo and Keydo AES
+KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1e0d", 
ATTRS{idProduct}=="f1d0|f1ae", TAG+="uaccess"
 
 # HyperSecu HyperFIDO
-ATTRS{idVendor}=="096e", ATTRS{idProduct}=="0880", TAG+="uaccess"
+KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e|2ccf", 
ATTRS{idProduct}=="0880", TAG+="uaccess"
 
-LABEL="fido_u2f_end"
+# Feitian ePass FIDO
+KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e", 
ATTRS{idProduct}=="0850", TAG+="uaccess"
+
+# JaCarta U2F

Bug#867334: ITP: node-rollup-plugin-json -- rollup plugin to convert JSON files to ES6 modules

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-rollup-plugin-json
  Version : 2.3.0
  Upstream Author : Rich Harris
* URL : https://github.com/rollup/rollup-plugin-json
* License : Expat
  Programming Lang: JavaScript
  Description : rollup plugin to convert JSON files to ES6 modules
 This rollup plugin provides functions to convert JSON files
 to ECMAScript version 6 modules.
 .
 Node.js is an event-based server-side JavaScript engine.


This package is needed for rollup, which I need to update quite a few
packages in Debian.

Snark on #debian-js

Bug#841369: Change icon image for CQRLOG

[asciiwolf]

As far as I know, /usr/share/icons/theme_name/*x*/apps/ is a standard location 
and is respected by most desktop environments.

Bug#863631: Also affects sympa: trashes configuration on update without asking

[Daniel Gnoutcheff]

Control: found -1 6.1.23~dfsg-2+deb8u1

I've experienced this on jessie as well when upgrading from
6.1.23~dfsg-2 to 6.1.23~dfsg-2+deb8u1 for the 8.7 point release.

The listmaster directive in /etc/sympa/sympa.conf got clobbered, locking
me out of my own server until I tracked this down.



signature.asc
Description: OpenPGP digital signature

Bug#867214: git-buildpackage: Strange format of commit message added by import-orig

[Robert Luberda]

Guido Günther writes:

> Using past tense was indeed a bad choice.  I deliberately avoided the
> terme "merge" here since we're not using the git merge machinery but
> build the tree ourself (see --merge-mode in gbp-import-orig(1)). 

I used "merge" in my proposal, because technically the resulting commit
is a merge commit, as it contains two parents, and the way it was
produced could still be deducted from the second part of the commit message.
However I won't insist on that, i.e. using "update" instead of "merge"
is OK, as long as the commit message does not start with a sentence
artificially split in the middle with an empty line.

> What about:>
>   Update upstream source from tag 'upstream/20170702'
>  
>   Update to upstream version 20170702
>   with Debian dir 43f841d7950f0587745d57c8c87fd79e1aed60dd.
> 

It looks great to me!

Thanks,
robert

Bug#856170: molly-guard: hostname should not be case-sensitive

[Simó Albert i Beltran]

I rewrite it without the option:

https://gitlab.com/sim6/molly-guard/compare/master...sim6_hostname_case_insensitive_always

I will try to create a new version of the package.
Thanks!

Bug#866629: debian-installer: Installer showes Debootstrap Error debian stretch live installation

[Prahlad Yeri]

On Wed, 5 Jul 2017 20:24:20 +0100
Brian Potkin  wrote:

> On Thu 06 Jul 2017 at 00:35:21 +0530, Prahlad Yeri wrote:
> 
> > Can confirm this bug on the live installer - tried both XFCE and
> > LXDE versions.
> > 
> > Never expected such goof up on a debian stable version!
> > Granted that its just released, but we do go through ages of testing
> > before reaching stable, don't we? The reason a user comes to debian
> > in the first place is stability. If you don't even get that, then
> > what is the rationale for using debian stable against something
> > like Ubuntu LTS where you get both stability and newer packages?  
> 
> Your question (after the rhetorical first one) is probing. Debian has
> never had bugs before. We do not know how this managed to creep in. We
> will try better.

Sorry, didn't intend to hurt your feelings, just trying to raise my
concerns as a user and trying to understand the process. I don't know
how the testing process works at debian, but If I were making the point
release of a distro, one of the basic things I'd check is whether the
ISO installs work on an actual physical machine (not in a VM) - and
doing so would have helped catch this bug as there are usually no
network resources (like wifi, etc.) configured at boot time that could
have provided internet connectivity (in which case, it used to work and
the bug wasn't apparent).

I understand that bugs are a part of the linux distro life cycle, but
I did not expect something as basic as an install process to falter.
But again, maybe I'm wrong about the bug being so apparent, and its
just easy to say this in hindsight.

No offence meant, have a nice day!

-- 
Regards,
Prahlad

Bug#867104: wanna-build issue with src:perl versioned Provides

[Ralf Treinen]

On Wed, Jul 05, 2017 at 11:02:52PM +0300, Adrian Bunk wrote:

> 6)
> 
> Package: a
> Depends: p (>= 1), p (<< 2)
> 
> Package: b
> Provides: p (=1)
> 
> Package: c
> Provides: p (=2)
> 
> When a and b are installed, can c be installed without removing a?

Excellent. The fact that real packages can be installed in only one
version is used to encode an interval constraint: "p(>=1), p(<<2)" 
means "p in some version between 1 (inclusive) and 2 (eclusive)".
Now, this breaks down with virtual packages since they can be
installed in multiple versions at the same time.

-Ralf.

Bug#867333: gnome-shell slows down over time

[Rob Johnson]

Package: gnome-shell
Version: 3.22.3-3
Severity: important

Dear Maintainer,

Over time, window and workspace operations (e.g. switching to overview mode,
switching between workspaces, switching focus from one window to another) get
slower.  Immediately after logging in on a freshly booted system, all these
operations are very fast and smooth.  After several hours, they become very
slow.  Switching to overview mode is particularly slow -- there is often a 2-3
second delay between the time I press the overview key and the time when the
screen shows any change at all.  At that point, it immediately jumps to the
overview without any visible animation.

When performance is slow, gnome-shell CPU usage is generally higher than when
performance is good, but it's not pinned at 100%.  Chrome and chromium also
tend to use more CPU when performance is slow, but killing them does not
improve performance of gnome-shell operations.  In fact, closing all windows
does not restore gnome-shell performance.

The same problem happens for both gnome on X and gnome on Wayland.

Restarting gnome-shell (via Alt-F2 r) does not help.  Logging out does not
help.  Restarting gdm does not help.  Rebooting restores performance.

I have verified that the system is not swapping.

Machine is a Dell Precision 5510 laptop.  Output of lspci given below.  Gnome
system info states that gnome is using the Intel graphics, not the NVIDIA
controller.

Thanks for your help!

Best,
Rob

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev
07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor
Thermal Subsystem (rev 07)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI
Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal
subsystem (rev 31)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial
IO I2C Controller #0 (rev 31)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial
IO I2C Controller #1 (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI
#1 (rev 31)
00:16.3 Serial controller: Intel Corporation Sunrise Point-H KT Redirection
(rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller
[AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1
(rev f1)
00:1c.1 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #2
(rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9
(rev f1)
00:1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13
(rev f1)
00:1d.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #15
(rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1000M] (rev ff)
02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI
Express Card Reader (rev 01)
04:00.0 Non-Volatile memory controller: Device 1c5c:1285



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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=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-backend]  0.26.0-2+b1
ii  evolution-data-server3.22.7-1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-atspi-2.0 2.22.0-6
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-freedesktop   1.50.0-1+b1
ii  gir1.2-gcr-3 3.20.0-5.1
ii  gir1.2-gdesktopenums-3.0 3.22.0-1
ii  gir1.2-gdm-1.0   3.22.3-3
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gnomebluetooth-1.03.20.1-1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-gweather-3.0  3.20.4-1
ii  gir1.2-ibus-1.0  1.5.14-3
ii  gir1.2-mutter-3.03.22.3-2
ii  gir1.2-networkmanager-1.01.6.2-3
ii  gir1.2-nmgtk-1.0 1.4.4-1
ii  

Bug#841369: Change icon image for CQRLOG

[Colin Tuckley]

On 05/07/17 21:16, asciiw...@seznam.cz wrote:
> Oh, I see what is probably causing the issue. The icons in
> /usr/share/icons are installed to a wrong path. They should be installed
> in /usr/share/icons/hicolor/*x*/apps/, not /usr/share/icons/cqrlog/*x*/.

No, they need to be in /usr/share/icons/hicolor/*x*/apps/ for *your* desktop

For other desktop systems they need to be in the current places.

I have a new package in work that will put them in both places.

Colin

-- 
Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903

I am the girl-next-door's imaginary boyfriend.

Bug#867332: RFS/ITP: node-rollup-plugin-string/2.0.2-1

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-rollup-plugin-string"

 * Package name: node-rollup-plugin-string
   Version : 2.0.2-1
   Upstream Author : Bogdan Chadkin
 * URL : https://github.com/TrySound/rollup-plugin-string
 * License : Expat
   Section : web

  It builds those binary packages:

node-rollup-plugin-string - Nodejs code to convert text files to modules

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

  https://mentors.debian.net/package/node-rollup-plugin-string

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

dget -x
https://mentors.debian.net/debian/pool/main/n/node-rollup-plugin-string/node-rollup-plugin-string_2.0.2-1.dsc


  It is packaged within the Debian JavaScript Maintainers team:

Vcs-Git:
https://anonscm.debian.org/git/pkg-javascript/node-rollup-plugin-string.git
Vcs-Browser:
https://anonscm.debian.org/cgit/pkg-javascript/node-rollup-plugin-string.git


  Thanks,

Snark on #debian-js

Bug#867283: Crash in glibc's mktime in low-memory situations

[Johannes Schultz]

(Mail was initially only sent to Carlos, sorry for that :))

> If you have the opportunity please file a match bug with upstream at
> sourceware.org/bugzilla. That way upstream is made aware of the issue.

The bug is now being tracked at:
https://sourceware.org/bugzilla/show_bug.cgi?id=21716

Bug#856170: molly-guard: hostname should not be case-sensitive

[Francois Marier]

On 2017-07-05 at 20:26:03, Simó Albert i Beltran wrote:
> The tr command is introducing a dependency of coreutils package.

I think it's fine to add a dependency on coreutils.

> I can change the default value of the option, but if you prefer I will
> remove the option.

Yes, I think we don't need the option. Let's make it case insensitive all of
the time.

Francois

-- 
https://fmarier.org/

Bug#867101: refcard: Build-dependency pdfjam no longer available

[Holger Wansing]

Control: tags -1 + pending


Adrian Bunk  wrote:
> Source: refcard
> Version: 9.0.4
> Severity: serious
> Tags: buster sid
> 
> The texlive-extra-utils package ships still ships pdfjam but
> no longer provides it in the dependencies.

Replaced pdfjam by texlive-extra-utils in the package dependencies.

Marking this bug as pending.

Thanks


Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#841369: Change icon image for CQRLOG

[asciiwolf]

Oh, I see what is probably causing the issue. The icons in /usr/share/icons
are installed to a wrong path. They should be installed in /usr/share/icons/
hicolor/*x*/apps/, not /usr/share/icons/cqrlog/*x*/.

Bug#867331: molly-guard: guards against successful shutdown

[Thorsten Glaser]

Package: molly-guard
Version: 0.6.4

When ALWAYS_QUERY_HOSTNAME=true is uncommented in
/etc/molly-guard/rc the system suddenly no longer
cleanly shuts down.

I ssh in, do a “sudo poweroff”, enter the hostname,
and it keeps running. On the console, I see molly-
guard asking for the hostname AGAIN, from sendsigs.

When entering the hostname on the console (luckily
it was my spare laptop at home, not some remote box)
the system then shut down.

Debian sid/i386 as of an hour or so ago, sysvinit.

Bug#867283: Crash in glibc's mktime in low-memory situations

[Johannes Schultz]

Am 05.07.2017 um 21:56 schrieb Carlos O'Donell:

I agree.

If you have the opportunity please file a match bug with upstream at
sourceware.org/bugzilla. That way upstream is made aware of the issue.


Sure, I'll report the bug there.

Cheers,
Johannes

Bug#867314: openjdk-8-jre-headless: openjdk unwinder for gdb crashes

[Joshua Campbell]

The problem seems to be solved by

ln -s /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
/usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64

On Wed, Jul 5, 2017 at 10:36 AM, Joshua Charles Campbell
 wrote:
> Package: openjdk-8-jre-headless
> Version: 8u131-b11-2
> Severity: normal
>
> Dear Maintainer,
>
> When running python code that calls the JVM via JNI GDB can't install the
> openjdk unwinder.
>
> When running gdb --args python -m jcc --jar some-jar-file.jar and then running
> (just make a virtualenv, pip install jcc, and point it at some jar file):
>
> Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Installing openjdk unwinder
> Traceback (most recent call last):
>   File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-
> amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 52, in 
> class Types(object):
>   File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-
> amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 66, in Types
> nmethodp_t = gdb.lookup_type('nmethod').pointer()
> gdb.error: No type named nmethod.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe47f22b4 in ?? ()
> (gdb) bt
> #0  0x7fffe47f22b4 in ?? ()
> #1  0x0246 in ?? ()
> #2  0x7fffe47f2160 in ?? ()
> #3  0x7fffc8c0 in ?? ()
> #4  0x7fffc860 in ?? ()
> #5  0x7600d075 in VM_Version::get_processor_features() ()
>from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> Expected outcome: an actual stacktrace.
>
>
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers stable
>   APT policy: (990, 'stable'), (40, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages openjdk-8-jre-headless depends on:
> ii  ca-certificates-java  20170531+nmu1
> ii  java-common   0.58
> ii  libc6 2.24-11+deb9u1
> ii  libcups2  2.2.1-8
> ii  libfontconfig12.11.0-6.7+b1
> ii  libfreetype6  2.6.3-3.2
> ii  libgcc1   1:6.3.0-18
> ii  libjpeg62-turbo   1:1.5.1-2
> ii  liblcms2-22.8-4
> ii  libnss3   2:3.26.2-1.1
> ii  libpcsclite1  1.8.20-1
> ii  libstdc++66.3.0-18
> ii  libx11-6  2:1.6.4-3
> ii  libxext6  2:1.3.3-1+b2
> ii  libxi62:1.7.9-1
> ii  libxrender1   1:0.9.10-1
> ii  libxtst6  2:1.2.3-1
> ii  multiarch-support 2.24-11+deb9u1
> ii  util-linux2.29.2-1
> ii  zlib1g1:1.2.8.dfsg-5
>
> openjdk-8-jre-headless recommends no packages.
>
> Versions of packages openjdk-8-jre-headless suggests:
> ii  fonts-dejavu-extra2.37-1
> pn  fonts-indic   
> ii  fonts-ipafont-gothic  00303-16
> ii  fonts-ipafont-mincho  00303-16
> pn  fonts-wqy-microhei
> pn  fonts-wqy-zenhei  
> ii  libnss-mdns   0.10-8
>
> -- no debconf information



-- 
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

Bug#867104: wanna-build issue with src:perl versioned Provides

[Adrian Bunk]

On Wed, Jul 05, 2017 at 09:30:05PM +0200, Ralf Treinen wrote:
>...
> I guess I am not the only one who does not understand the consequences
> of versionend provides, and what they mean exaxtly. Part of the problem
> is of course that policy is still at the state of unversionend provides
> only. I think it would be useful for many people in the project if the
> consequences of versionend provides could be documented somewhere. For
> instance on the dpkg wiki pages (and announcing this on debian-devel),
> until this finds its way into policy. For instance, here are some questions
> I have been asking myself:
> 
> 1) policy is obviously outdated when saying that a versionend dependency (or
> conflict) only concerns relations to real packages, not virtual ones.
> Assume we have:
> 
> Package: a
> Version: 42
> 
> Package: b
> Version: 73
> Provides: a (=42)
> 
> Certainly, a dependency on a (=42) can be satisfied by any of these two?
> 
> 2) Assume we have:
> 
> Package: a
> Depends: v (=1)
> 
> Package: b
> Provides: v
> 
> Am I right that a cannot be installed, as b does not satisfy its
> dependency?
> 
> 3) Assume we have
> 
> Package: a
> Depends: v
> 
> Package: b
> Provides: v (=1)
> 
> That one seems easy: b satisfies the dependency of a on v, so a can be
> installed?
> 
> 4)
> 
> Package: a
> Conflicts: v
> 
> Package: b
> Provides: v (=1)
> 
> Are a and b in conflict?
> 
> 5)
> 
> Package: a
> Conflicts: v (=1)
> 
> Package: b
> Provides: v
> 
> I guess there is no conflict ?

6)

Package: a
Depends: p (>= 1), p (<< 2)

Package: b
Provides: p (=1)

Package: c
Provides: p (=2)

When a and b are installed, can c be installed without removing a?

> Cheeers -Ralf.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#867283: Crash in glibc's mktime in low-memory situations

[Carlos O'Donell]

On Wed, Jul 5, 2017 at 1:43 PM, Johannes Schultz  wrote:
>
>> None of the internal assertions in tzfile.c have to do with low
>> memory, they have to do with logical consistency and expected
>> outcomes.
>
> Okay, so let's look at the stack trace again and where it failed.
> The failing line 779 in __tzfile_compute is:
>
> if (__tzname[0] == NULL)
> {
> assert (num_types == 1); // <-- boom
>
> So, where is __tzname[0] being set? Depending on the path taken, it can be
> either of these:
>
> line 627: __tzname[0] = NULL; // initial value
> line 646: __tzname[0] = __tzstring (_names[types[i].idx]);
> line 686: __tzname[0] = __tzstring (zone_names);
> line 756: __tzname[dst] = __tzstring (_names[idx]);
>
> Internally, __tzstring calls malloc. If malloc fails, it returns NULL.
> So it is entirely possible that this assertion will fail because of an
> out-of-memory situation.

Perfect, in which case it *should* be fixed to make this more robust in the
face of low memory.

> No of course this is bad, but so far the integrity has not been compromised.

Agreed.

> It just means that the function really should return with an error now. As
> far as I can see there are currently no facilities for returning an error in
> this particular function, but I guess it really should be able to propagate
> allocation failures to the library functions that call it, so that those can
> return an error to the user (if that is part of their API contract, that
> is).

I agree.

If you have the opportunity please file a match bug with upstream at
sourceware.org/bugzilla. That way upstream is made aware of the issue.

As far as I can see we probably need to fix all cases of __tzstring returning
NULL and do something appropraite. It only ever returns NULL on ENOMEM.

Cheers,
Carlos.

Bug#863711: playonlinux: The current PlayOnLinux package version is outdated

[asciiwolf]

PlayOnLinux v4.2.12 was released two weeks ago.

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Dear Maintainer.

I know of this:

> Vim will load $VIMRUNTIME/defaults.vim if the user does not have a vimrc.
> This happens after /etc/vim/vimrc(.local) are loaded, so it will override
> any settings in these files.

But the settings in "defaults.vim" IMHO are just *completely* broken for 
several reasons:

1) Maybe due to a bug in Vim regarding mouse handling with "set mouse=a" Vim 
is just madly moving around the cursor and doing whatelse not for easily a 
minute in a lot of freshly installed Debian 9 VMs accesses via SSH and screen 
from Plasma´s Konsole terminal emulator.

2) Activated mouse handling breaks copy and paste text from Plasma´s clipboard 
by… auto-indenting and what else not. I know of "set nopaste" (or what else it 
was called)… but having to activate it is an additional nuisance.

3) Vim wordwraps by default now. I wonder about how many admins will break 
config files with long lines accidently by that new default behaviour.

These defaults may be somewhat suitable for a desktop editor, but for Vim I 
think they are just plain broken. So I kindly ask you reconsider applying this 
broken configuration… or at least consider restoring a sane order in which Vim 
applies configuration:

I think it is broken behaviour, that "defaults.vim" is loaded *after* 
"vimrc.local". The sane default would be this order:

1. Global vim configuration
2. /etc/vim/vimrc.local
3. $HOME/.vimrc

The current order is a cross disrespect and paternalism for the local site 
admin.

The order vim uses now makes it necessary for me to add

let g:skip_defaults_vim = 1

to *any* newly installed Debian 9 system.

In addition to "screen" this is the second new default config that breaks 
existing setups.

Thank you,
-- 
Martin

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

Bug#867293: janus-demos: please move janus-demos from contrib to main

[Johannes Schauer]

On Wed, 05 Jul 2017 16:36:15 +0200 Johannes Schauer  wrote:
> the janus-demos package is currently in contrib because the JavaScript it
> ships references scripts which are hosted on cdnjs.cloudflare.com instead of
> versions packaged in Debian.

What must also not be forgotten is to remove all references to:

https://s3.amazonaws.com/github/ribbons/forkme_left_darkblue_121621.png


signature.asc
Description: signature

Bug#845548: GNOME Software catalog entry missing for PlayOnLinux

[asciiwolf]

This issue was fixed in PlayOnLinux v4.2.11.

Bug#866778: lsb-release: lsb_release --all displays inconsistent information

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix 

Le samedi, 1 juillet 2017, 18.38:28 h CEST GT a écrit :
>* What led up to the situation?
> use of the command lsb_release --all
> 
> :~$ lsb_release --all
> 
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux oldstable-updates (sid)
> Release:oldstable-updates
> Codename:   sid
> 
> 
>* What outcome did you expect instead?
> 
> An accurate report:
> :~$ cat /usr/lib/os-release
> 
> PRETTY_NAME="Debian GNU/Linux buster/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
> 
> 
> why lsb-release diplays sid while i am using buster?

lsb-release cannot _know_ that you're u sing buster and not sid, as the
/usr/lib/os-release file (as shipped by base-files) contains this "buster/
sid" string (you also find this in /etc/debian_version, which is what 
lsb_release.py uses). That's specifically made to avoid having to have one 
base-files package per suite, which would make base-files more of a special 
package than it already is.

As, technically, a set of "unstable" packages could also be a valid set of 
"testing" packages (5 days without bugs or uploads later, for instance), 
it's impossible to guess from the files on the system whether it's running 
"testing" or "unstable".

And finally, don't rely on lsb_release's output for anything non-stable; 
it's bound to be unreliable, by construction. One should really rely on 
feature-detection rather than version-matching.

Hereby closing as not-a-bug.

Cheers,
OdyX

Bug#867330: mutt doesn't display mailboxes

[David Lawyer]

Package: mutt
Version:1.8.3+neomutt20170609-2

When I type c to change mailboxes , I see the message ('?' for list).  Yet
if I type ? I don't see the long list of my mailboxes but instead see my
incoming mailbox dave (path: /var/spool/mail/dave).  I want to see the
mailboxes in ~/Mail.

I had to reinstall the old mutt_1.7.1-5_i386.deb to get it to work right.

Bug#867104: wanna-build issue with src:perl versioned Provides

[Ralf Treinen]

Hi everybody,

On Wed, Jul 05, 2017 at 03:01:10AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2017-07-04 at 23:30:37 +0300, Niko Tyni wrote:
> > On Tue, Jul 04, 2017 at 10:18:08PM +0200, Ralf Treinen wrote:
> > > On Tue, Jul 04, 2017 at 10:29:35PM +0300, Niko Tyni wrote:
> > > > On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote:
> > > > 
> > > > > thanks for having figured that out. I tend to believe that dose is 
> > > > > right
> > > > > in this case. Since it is not possible to install at the same
> > > > > time two different versions of the same real package, the same should
> > > > > IMHO hold when one is real and the other virtual. Why should this be
> > > > > possible?
> 
> Because it follows the same principle that you can have installed both
> the real package and various virtual packages providing that one. This
> just takes this further and gives it version(s) too.

OK, that's a good point.

> > > So, that means that something like
> > > 
> > > Depends: p (=1), p (=2)
> > > 
> > > suddenly becomes satisfiable (when there is one real package p and
> > > one virtual package)? Would you also allow to have the packages p
> > > and q installed at the same time, in the following situation:
> > > 
> > > Package: p
> > > Version: 1
> > > Provides: v (=1)
> > > 
> > > Package: q
> > > Version: 1
> > > Provides: v (=2)
> 
> Yes, this is correct.

Alright, I see now why this makes sense.

> > > If yes this seems to me a quite drastic change of the meaning of 
> > > package relations. Has this been discussed somewhere?
> 
> Not in recent times, no, the bug requesting versioned provides was a
> bit aged. But the semantics are IMO the obvious ones, and I'm actually
> a bit surprised they are surprising! :)

I guess I am not the only one who does not understand the consequences
of versionend provides, and what they mean exaxtly. Part of the problem
is of course that policy is still at the state of unversionend provides
only. I think it would be useful for many people in the project if the
consequences of versionend provides could be documented somewhere. For
instance on the dpkg wiki pages (and announcing this on debian-devel),
until this finds its way into policy. For instance, here are some questions
I have been asking myself:

1) policy is obviously outdated when saying that a versionend dependency (or
conflict) only concerns relations to real packages, not virtual ones.
Assume we have:

Package: a
Version: 42

Package: b
Version: 73
Provides: a (=42)

Certainly, a dependency on a (=42) can be satisfied by any of these two?

2) Assume we have:

Package: a
Depends: v (=1)

Package: b
Provides: v

Am I right that a cannot be installed, as b does not satisfy its
dependency?

3) Assume we have

Package: a
Depends: v

Package: b
Provides: v (=1)

That one seems easy: b satisfies the dependency of a on v, so a can be
installed?

4)

Package: a
Conflicts: v

Package: b
Provides: v (=1)

Are a and b in conflict?

5)

Package: a
Conflicts: v (=1)

Package: b
Provides: v

I guess there is no conflict ?

Cheeers -Ralf.

Bug#867329: ITP: node-rollup-plugin-string -- Nodejs code to convert text files to modules

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-rollup-plugin-string
  Version : 2.0.2
  Upstream Author : Bogdan Chadkin 
* URL : https://github.com/TrySound/rollup-plugin-string
* License : Expat
  Programming Lang: JavaScript
  Description : Nodejs code to convert text files to modules
 This plugin for rollup turns text files into modules ready to be
 imported.
 .
 Node.js is an event-based server-side JavaScript engine.


This is needed to package rollup, which I need to update other packages
I have.

Snark on #debian-js

Bug#867328: jessie-pu: package libclamunrar/0.99-0+deb8u3

[Sebastian Andrzej Siewior]

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

This is an update to Jessie with a patch from git which fixes
CVE-2012-6706. The final clamav release is planned for the end of July,
this is the only commit in the libclamunrar part so far.

Sebastian
diff -Nru libclamunrar-0.99/debian/changelog libclamunrar-0.99/debian/changelog
--- libclamunrar-0.99/debian/changelog	2016-12-16 21:38:26.0 +0100
+++ libclamunrar-0.99/debian/changelog	2017-07-05 21:20:40.0 +0200
@@ -1,3 +1,10 @@
+libclamunrar (0.99-0+deb8u3) oldstable; urgency=medium
+
+  * Cherry pick fix for arbitrary memory write. CVE-2012-6706
+(Closes: #867223).
+
+ -- Sebastian Andrzej Siewior   Wed, 05 Jul 2017 21:20:40 +0200
+
 libclamunrar (0.99-0+deb8u2) stable; urgency=medium
 
   * Add patches from upstream bugzilla bb11600 and bb11601 to fix out of band
diff -Nru libclamunrar-0.99/debian/.git-dpm libclamunrar-0.99/debian/.git-dpm
--- libclamunrar-0.99/debian/.git-dpm	2016-12-16 21:38:26.0 +0100
+++ libclamunrar-0.99/debian/.git-dpm	2017-07-05 21:19:45.0 +0200
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-e677e64787390c59bdb925be08113ebf47aed869
-e677e64787390c59bdb925be08113ebf47aed869
+bced92bf269023e533fa3433f57205aa77c40eec
+bced92bf269023e533fa3433f57205aa77c40eec
 87f93791ab6959fd522bdf0b1211ff0480cff4c7
 87f93791ab6959fd522bdf0b1211ff0480cff4c7
 libclamunrar_0.99.orig.tar.xz
diff -Nru libclamunrar-0.99/debian/patches/series libclamunrar-0.99/debian/patches/series
--- libclamunrar-0.99/debian/patches/series	2016-12-16 21:38:26.0 +0100
+++ libclamunrar-0.99/debian/patches/series	2017-07-05 21:19:45.0 +0200
@@ -2,3 +2,4 @@
 bb11600_pt2.patch
 bb11601.patch
 bb11601_pt2.patch
+unrar-adding-proposed-changes-to-fix-RAR-VMSF_DELTA-.patch
diff -Nru libclamunrar-0.99/debian/patches/unrar-adding-proposed-changes-to-fix-RAR-VMSF_DELTA-.patch libclamunrar-0.99/debian/patches/unrar-adding-proposed-changes-to-fix-RAR-VMSF_DELTA-.patch
--- libclamunrar-0.99/debian/patches/unrar-adding-proposed-changes-to-fix-RAR-VMSF_DELTA-.patch	1970-01-01 01:00:00.0 +0100
+++ libclamunrar-0.99/debian/patches/unrar-adding-proposed-changes-to-fix-RAR-VMSF_DELTA-.patch	2017-07-05 21:19:45.0 +0200
@@ -0,0 +1,173 @@
+From bced92bf269023e533fa3433f57205aa77c40eec Mon Sep 17 00:00:00 2001
+From: Mickey Sola 
+Date: Thu, 29 Jun 2017 14:02:03 -0400
+Subject: unrar - adding proposed changes to fix RAR VMSF_DELTA Filter
+ Signedness error
+
+CVE: CVE-2012-6706: arbitrary memory write
+BTS: #867223
+Patch-Name: unrar-adding-proposed-changes-to-fix-RAR-VMSF_DELTA-.patch
+---
+ libclamunrar/unrarvm.c | 55 ++
+ 1 file changed, 29 insertions(+), 26 deletions(-)
+
+diff --git a/libclamunrar/unrarvm.c b/libclamunrar/unrarvm.c
+index 102fe2ebf044..b21e242fa72b 100644
+--- a/libclamunrar/unrarvm.c
 b/libclamunrar/unrarvm.c
+@@ -213,9 +213,9 @@ void rarvm_addbits(rarvm_input_t *rarvm_input, int bits)
+ 
+ unsigned int rarvm_getbits(rarvm_input_t *rarvm_input)
+ {
+-	unsigned int bit_field = 0;
++unsigned int bit_field = 0;
+ 
+-	if (rarvm_input->in_addr < rarvm_input->buf_size) {
++if (rarvm_input->in_addr < rarvm_input->buf_size) {
+ bit_field = (unsigned int) rarvm_input->in_buf[rarvm_input->in_addr] << 16;
+ if (rarvm_input->in_addr+1 < rarvm_input->buf_size) {
+ bit_field |= (unsigned int) rarvm_input->in_buf[rarvm_input->in_addr+1] << 8;
+@@ -314,10 +314,10 @@ static unsigned int *rarvm_get_operand(rarvm_data_t *rarvm_data,
+ 	}
+ }
+ 
+-static unsigned int filter_itanium_getbits(unsigned char *data, int bit_pos, int bit_count)
++static unsigned int filter_itanium_getbits(unsigned char *data, unsigned int bit_pos, unsigned int bit_count)
+ {
+-	int in_addr=bit_pos/8;
+-	int in_bit=bit_pos&7;
++	unsigned int in_addr=bit_pos/8;
++	unsigned int in_bit=bit_pos&7;
+ 	unsigned int bit_field=(unsigned int)data[in_addr++];
+ 	bit_field|=(unsigned int)data[in_addr++] << 8;
+ 	bit_field|=(unsigned int)data[in_addr++] << 16;
+@@ -326,10 +326,10 @@ static unsigned int filter_itanium_getbits(unsigned char *data, int bit_pos, int
+ 	return(bit_field & (0x>>(32-bit_count)));
+ }
+ 
+-static void filter_itanium_setbits(unsigned char *data, unsigned int bit_field, int bit_pos, int bit_count)
++static void filter_itanium_setbits(unsigned char *data, unsigned int bit_field, unsigned int bit_pos, unsigned int bit_count)
+ {
+-	int i, in_addr=bit_pos/8;
+-	int in_bit=bit_pos&7;
++	unsigned int i, in_addr=bit_pos/8;
++	unsigned int in_bit=bit_pos&7;
+ 	unsigned int and_mask=0x>>(32-bit_count);
+ 	and_mask=~(and_mask<

Bug#867302: licensecheck: incorrectly parses multi-line copyright notices

[Ximin Luo]

Jonas Smedegaard:
> Quoting Ximin Luo (2017-07-05 20:07:00)
>> This breaks some of my test cases; attached is an updated patch. It 
>> gives good results for Sage:
> 
> The patch relaxes the $dash_re regex to match multiple dashes.  Can you 
> provide me an example of where that is useful?
> 

Yes, if you look at copyright-test.sh that I just sent in that other email, and 
run it in the sage/ directory of the sagemath package, you'll see that this 
$dash_re is useful for src/sage/modular/modform/all.py:

#   Copyright (C) 2004--2006 William Stein 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#867298: [Pkg-javascript-devel] Bug#867298: npm2deb: please bump debhelper and Standards-Version

[Johannes Schauer]

Quoting Jonas Smedegaard (2017-07-05 21:04:44)
> Quoting Johannes Schauer (2017-07-05 18:26:40)
> > Maybe I misunderstand but this bug report is not about "changing" or
> > "bumping" anything.
> > 
> > Since npm2deb creates the *initial* Debian packaging, the situation 
> > where we start with a lower Standards-Version and then have to verify 
> > changes before we can "bump" the Standards-Version doesn't arise.
> 
> Right, this is not about single package bumping as I confusingly wrote, 
> but instead about automated processing where it is even _more_ important 
> to verify that the claimed Standards-Version is accurately applied, and 
> even _more_ important to consider if newest shiny denhelper really is 
> needed!

Lets not conflate the two issues. I assume that it's uncontroversial that the
newest Standards-Version should be emitted because it doesn't make sense to
pick any old policy version and then require the maintainer to bump the version
bit by bit, right?

> > Furthermore, I'd argue that any tool which auto-generates Debian packaging
> > data should use the current and/or recommended packaging practices.
> > According to the debhelper man page, compatibility level 10 is the
> > "recommended mode of operation".
> I am aware that the developers of debhelper promote newest major version -
> that does not change my plea about being more conservative: Use the debhelper
> compatibility level supported in oldstable (currently 9), unless some feature
> requiring a newer compatibility level is needed.

I will leave the choice about the right debhelper version to the npm2deb
maintainers.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#867302: licensecheck: incorrectly parses multi-line copyright notices

[Ximin Luo]

Jonas Smedegaard:
> [..]
> 
> Have a look (if interested) at /usr/share/perl5/String/Copyright.pm and 
> in particular the (huge when expanded) $signs_and_more_re at line 138.
> 
> [..]

Thanks for the tips! I'm not sure if you got my other follow-ups to the bug 
report - I did in fact find String::Copyright, but I didn't know about the 
history nor plans for it, so thanks for filling me in on that.

At any rate, here is an updated version of my patch, along with some test cases 
for Sage's copyright notices.

I did try to think of a way to achieve the same logic *inside* the massive $re 
regexes. However I don't think this is possible, at least with my current 
approach - which tries to be conservative in order to adapt to humans being 
annoyingly inconsistent.

What it does is, it joins subsequent lines only when the indent is greater than 
the main line (with the "Copyright" part). This means I have to call length() 
in an expression-replacement, which I don't think is possible to do inside a 
normal regex...

As for speed:

# with the patch
$ time debian/rules debian/licensecheck.copyright
licensecheck -l250 -i ^sage/build/ -r --deb-machine --merge-licenses sage > 
"debian/licensecheck.copyright"

real0m35.318s
user0m35.204s
sys 0m0.056s

# without the patch
$ time debian/rules debian/licensecheck.copyright
licensecheck -l250 -i ^sage/build/ -r --deb-machine --merge-licenses sage > 
"debian/licensecheck.copyright"

real0m31.168s
user0m31.040s
sys 0m0.076s

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
--- /usr/share/perl5/String/Copyright.pm.old	2016-11-30 20:08:44.0 +0100
+++ /usr/share/perl5/String/Copyright.pm	2017-07-05 21:02:01.060002642 +0200
@@ -104,7 +104,7 @@
 my $comma_re
 	= qr/$blank_re*,$blank_or_break_re|$blank_or_break_re,?$blank_re*/;
 my $dash_re
-	= qr/$blank_re*[-˗‐‑‒–—―⁃−﹣－]$blank_or_break_re*/;
+	= qr/$blank_re*[-˗‐‑‒–—―⁃−﹣－]+$blank_or_break_re*/;
 my $owner_intro_re   = qr/\bby$blank_or_break_re/;
 my $owner_prefix_re  = qr/[(*<@[{]/;
 my $owner_initial_re = qr/[^\s!\"#$%&'()*+,.\/:;<=>?@[\\\]^_`{|}~]/;
@@ -135,6 +135,8 @@
 my $years_re= qr/$yearspan_re(?:$comma_re$yearspan_re)*/;
 my $owners_re   = qr/$owner_prefix_re*$owner_initial_re\S*(?:$blank_re*\S+)*/;
 
+my $line_preamble_re
+	= qr/(?:#|\/\/|\/\*)?\s*/;
 my $signs_and_more_re
 	= qr/(?:$chatter_re.*|$signs_re(?::$blank_or_break_re|$comma_re)$broken_sign_re?($years_re?$comma_re?$owner_intro_re?$owners_re?)|(?:\n|\z))/;
 
@@ -155,6 +157,14 @@
 
 		# stringify objects
 		$copyright = "$copyright";
+		# concatenate multi-line notices together
+		my $old_copyright;
+		do {
+			$old_copyright = $copyright;
+			$copyright =~ s/((?:^|\n)$line_preamble_re)($signs_and_more_re,?)\n($line_preamble_re)/
+			(length $4 <= length $1)? "$1$2\n$4":
+			(sub{ shift =~ m{(?:\band|,)$}; })->($2)? "$1$2 ": "$1$2, "/eg;
+		} while ($copyright ne $old_copyright);
 
 		# TODO: also parse @_ - but each separately!
 		my @block;


copyright-test.sh
Description: application/shellscript

Bug#866629: debian-installer: Installer showes Debootstrap Error debian stretch live installation

[Brian Potkin]

On Thu 06 Jul 2017 at 00:35:21 +0530, Prahlad Yeri wrote:

> Can confirm this bug on the live installer - tried both XFCE and LXDE
> versions.
> 
> Never expected such goof up on a debian stable version!
> Granted that its just released, but we do go through ages of testing
> before reaching stable, don't we? The reason a user comes to debian in
> the first place is stability. If you don't even get that, then what is
> the rationale for using debian stable against something like Ubuntu LTS
> where you get both stability and newer packages?

Your question (after the rhetorical first one) is probing. Debian has
never had bugs before. We do not know how this managed to creep in. We
will try better.

Bug#867302: licensecheck: incorrectly parses multi-line copyright notices

[Jonas Smedegaard]

Quoting Ximin Luo (2017-07-05 20:07:00)
> This breaks some of my test cases; attached is an updated patch. It 
> gives good results for Sage:

The patch relaxes the $dash_re regex to match multiple dashes.  Can you 
provide me an example of where that is useful?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#867326: ctermd is not compiled with devpts breaking decnet terminal support

[Adam Pigg]

Package: dnet-progs
Version: 2.64

When connecting to a linux box from a VMS box using the cterm protocol
from DECNet, the error message:

No ptys available for connection

is returned.

This comes from a codepath in ctermd.c which shouldnt be taken, which
tries to open traditional pty devices from a static /dev.  If cterm is
compiled with -DDNETUSE_DEVPTS then devpts is used.  Unfortunately the
check for devpts in Makefile.common int he package root is incorrect,
and looks for libutil.so in an incorrect location in modern systems.

Fixing Makefile.common to search for libutil.so in
/usr/lib/x86_64-linux-gnu/libutil.so fixes the check and compiles
ctermd correctly, making it use the devpts codepath and allowing
connection from VMS.

Bug#867302: licensecheck: incorrectly parses multi-line copyright notices

[Jonas Smedegaard]

Quoting Ximin Luo (2017-07-05 20:07:00)
> Ximin Luo:
> > Control: tags -1 + patch
> > Control: reassign -1 libstring-copyright-perl
> > Control: affects -1 + licensecheck
> > 
> > Looks like I can do this by editing /usr/share/perl5/String/Copyright.pm as 
> > follows:
> > 
> >   # stringify objects
> >   $copyright = "$copyright";
> > + $copyright =~ s/(,|\band)\s*\n(?:#|\/\/|\/\*)?\s*/$1 /g;
> > 
> > Please test and apply if it's good!
> > 
> 
> This breaks some of my test cases; attached is an updated patch. It gives 
> good results for Sage:
> 
> $ licensecheck -l200 --copyright src/sage/plot/arrow.py 
> src/sage/combinat/words/paths.py src/sage/sets/finite_set_maps.py 
> src/sage/modular/modform/all.py
> src/sage/plot/arrow.py: GPL
>   [Copyright: 2006 Alex Clemesha , William Stein 
> , 2008 Mike Hansen , 2009 Emily Kirkman]
> 
> src/sage/combinat/words/paths.py: GPL (v2 or later)
>   [Copyright: 2009 Sebastien Labbe , / 2008 Arnaud bergeron 
> ,]
> 
> src/sage/sets/finite_set_maps.py: GPL
>   [Copyright: 2010 Florent Hivert ,]
> 
> src/sage/modular/modform/all.py: GPL
>   [Copyright: 2004-2006 William Stein ]
> 
> It's a little complicated - it uses replacement expressions. If you can think 
> of a better way of doing it, please let me know!

Thanks!

I thought you wrote you were not into perl ;-)

I will take a closer look and get back to you on this.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#867298: [Pkg-javascript-devel] Bug#867298: npm2deb: please bump debhelper and Standards-Version

[Jonas Smedegaard]

Quoting Johannes Schauer (2017-07-05 18:26:40)
> Quoting Jonas Smedegaard (2017-07-05 17:46:19)
> > Quoting Johannes Schauer (2017-07-05 17:15:46)
> > > Standards-Version 3.9.8 is outdated. npm2deb should generate version 
> > > 4.0.0 instead.
> > Just to avoid misunderstanding: Standards-Version should *only* be 
> > changed as a *result* of verifying that said the package comply with 
> > said version of Debian Policy.
> > 
> > 
> > > The current recommended compat level for debhelper is 10. npm2deb 
> > > should use that one instead of compat level 9.
> > Please bump debhelper compatibility level only when really needed, 
> > to help ease backportability (to _any_ environment, not only 
> > backport.debian.org).
> 
> Maybe I misunderstand but this bug report is not about "changing" or 
> "bumping" anything.
> 
> Since npm2deb creates the *initial* Debian packaging, the situation 
> where we start with a lower Standards-Version and then have to verify 
> changes before we can "bump" the Standards-Version doesn't arise.

Right, this is not about single package bumping as I confusingly wrote, 
but instead about automated processing where it is even _more_ important 
to verify that the claimed Standards-Version is accurately applied, and 
even _more_ important to consider if newest shiny denhelper really is 
needed!


> Furthermore, I'd argue that any tool which auto-generates Debian 
> packaging data should use the current and/or recommended packaging 
> practices. According to the debhelper man page, compatibility level 10 
> is the "recommended mode of operation".

I am aware that the developers of debhelper promote newest major version 
- that does not change my plea about being more conservative: Use the 
debhelper compatibility level supported in oldstable (currently 9), 
unless some feature requiring a newer compatibility level is needed.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature