Bug#850494: how to force a test that has breaks-testbed set?

[Evgeni Golov]

Package: autopkgtest
Version: 4.2.2
Severity: minor
Tags: upstream

Ohai,

the docs say:

breaks-testbed
The test, when run, is liable to break the testbed system. This
includes causing data loss, causing services that the machine is
running to malfunction, or permanently disabling services; it does
not include causing services on the machine to temporarily fail.

When this restriction is present the test will usually be skipped
unless the testbed's virtualisation arrangements are sufficiently
powerful, or alternatively if the user explicitly requests.

However, I could not find any docs how to "explicitly request" this.

Background: I am running the tests inside a docker container (on
travis-ci.org, via travis.debian.net) and that gets thrown away after
the tests anyways.

Regards
Evgeni

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.4~beta3
ii  libdpkg-perl1.18.18
ii  procps  2:3.3.12-3
ii  python3 3.5.1-4
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
ii  lxc  1:2.0.6-1
pn  lxd-client   
ii  qemu-system  1:2.8+dfsg-1
ii  qemu-utils   1:2.8+dfsg-1
ii  schroot  1.6.10-2+b2

-- no debconf information

Bug#850422: Are you sure you want to upload a release candidate of a new version of h5py?

[Gianfranco Costamagna]

Hello,


>Oh, I see what you are referring to. I am afraid I have not, and I am
>putting my faith on upstream staying as conservative as they have been
>with their releases since version 2.4.
>
>I reckon a transition has never been needed for h5py since I took over
>its maintenance, and I am crossing my fingers this won't be the case
>for its 34 rdepends now (compared to 403 for numpy nonetheless).


Lumin, can you please check caffe*?

I see 24 rdeps
reverse-depends -r unstable -b src:h5py |cut -f 2 -d " "|sort |uniq
caffe
caffe-contrib
glueviz
hdf-compass
hydroffice.bag
kineticstools
pbbarcode
pbgenomicconsensus
poretools
pyfai
pyfr
pymvpa2
python-biom-format
python-brainstorm
python-hdf5storage
python-mpop
python-neuroshare
python-pbcore
taurus
veusz
xmds2
yt

basic testing on some of them worked correctly, but I'm not sure about how to 
trigger h5py code

G.

Bug#846095: Status of package 'ruby-useragent'

[abhi.kuvalekar]

I am willing to work on the package 'ruby-useragent' but the ITP is assigned to 
you. Are you still working on this package? If not then I would work on this 
package.
Thank you.

Bug#850023: ImportError when importing ruamel.yaml

[Vincent Bernat]

 ❦  6 janvier 2017 22:51 GMT, Chris Lamb  :

> So, the binary package is missing a Depends on `python-typing`.
>
> However, it looks like this "should" work:
>
>install_requires=dict(
>[…]
>py27=["ruamel.ordereddict", "typing"],
>[…]
>)

This seems to only work if the package is installed at build time. I'll push a
fixed version soon.
-- 
The naked truth of it is, I have no shirt.
-- William Shakespeare, "Love's Labour's Lost"


signature.asc
Description: PGP signature

Bug#850257: xdotool fails to type: There are no windows on the stack

[Jochen Sprickerhof]

It's a Debian bug:

https://anonscm.debian.org/git/collab-maint/xdotool.git/tree/debian/patches/0003-Fixed-type-window-to-use-default-1-as-manpage-stated.patch?h=debian

Could you please revert it and publish a new version?

Upstream reverted it as well:

https://github.com/jordansissel/xdotool/issues/156#issuecomment-271068002

Cheers Jochen


signature.asc
Description: PGP signature

Bug#850493: ITP: node-co-with-promise -- generator async control flow goodness

[Ravishankar Purne]

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

* Package name: node-co-with-promise
  Version : 4.6.0
  Upstream Author : FIX_ME upstream author
* URL : https://github.com/tj/co
* License : Expat
  Programming Lang: JavaScript
  Description : generator async control flow goodness

Bug#850492: lokalize: missing dependancy

[Yuri Kozlov]

Package: lokalize
Version: 4:16.08.2-1
Severity: normal

Hello.

If no kinit5 installed in the system, then lokalize do not show PO files 
in the project overview.


-- 
Best Regards,
Yuri Kozlov

Bug#850491: slurm-llnl: CVE-2016-10030

[Salvatore Bonaccorso]

Source: slurm-llnl
Version: 14.03.9-5
Severity: grave
Tags: upstream patch security fixed-upstream
Justification: user security hole

Hi,

the following vulnerability was published for slurm-llnl.

CVE-2016-10030[0]:
| The _prolog_error function in slurmd/req.c in Slurm before 15.08.13,
| 16.x before 16.05.7, and 17.x before 17.02.0-pre4 has a vulnerability
| in how the slurmd daemon informs users of a Prolog failure on a compute
| node. That vulnerability could allow a user to assume control of an
| arbitrary file on the system. Any exploitation of this is dependent on
| the user being able to cause or anticipate the failure (non-zero return
| code) of a Prolog script that their job would run on. This issue
| affects all Slurm versions from 0.6.0 (September 2005) to present.
| Workarounds to prevent exploitation of this are to either disable your
| Prolog script, or modify it such that it always returns 0 ("success")
| and adjust it to set the node as down using scontrol instead of relying
| on the slurmd to handle that automatically. If you do not have a Prolog
| set you are unaffected by this issue.

I'm not to familiar with slurm, but looking at the description and
code this should be the case. It is fixed upstream.

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-2016-10030
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10030
[1] https://www.schedmd.com/news.php?id=178
[2] 
https://github.com/SchedMD/slurm/commit/92362a92fffe60187df61f99ab11c249d44120ee

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#850490: grub-common: Some chinese chars can't be displayed with the included unicode.pf2

[Zhang Jingqiang]

Package: grub-common
Version: 2.02~beta3-3
Severity: normal

Dear Maintainer,

Some chars such as "载" int the following grub.cfg file can't be displayed
with the font file /usr/share/grub/unicode.pf2.
I download the stable version grub-common_2.02-beta2-22+deb8u1_amd64 and
use the font file included in it, that char can be displayed correctly.

I install ttf-unifont package, and use `grub-mkfont -o unicode.pf2 `,
and use the result font file, the char is displayed, but there are some problems
with the font size as there's "underline" got displayed between lines.

The file size in current version is 1363163, while that is 2400500 in the 
stable version.
So I guess the current version doesn't contain all the unicode chars.

Just use the stable version is an acceptable solution for me,
though it may be better to regenerate one use the most recent version of 
unifont.

Thanks 

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda4 / ext4 rw,noatime,discard,errors=remount-ro,data=ordered 0 0
/dev/sda2 /boot ext2 
rw,noatime,nodiratime,block_validity,barrier,user_xattr,acl 0 0
/dev/sda5 /opt ext4 rw,noatime,discard,data=ordered 0 0
/dev/sda6 /home ext4 rw,noatime,discard,data=ordered 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
7255d155-fea2-42e5-9786-5e7285794cca
else
  search --no-floppy --fs-uuid --set=root 7255d155-fea2-42e5-9786-5e7285794cca
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=zh_CN
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
7255d155-fea2-42e5-9786-5e7285794cca
else
  search --no-floppy --fs-uuid --set=root 7255d155-fea2-42e5-9786-5e7285794cca
fi
insmod png
if background_image /usr/share/desktop-base/softwaves-theme/grub/grub-16x9.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-7255d155-fea2-42e5-9786-5e7285794cca' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
2df07543-1e50-4fb2-a2e9-10567cfdc928
else
  search --no-floppy --fs-uuid --set=root 
2df07543-1e50-4fb2-a2e9-10567cfdc928
fi
echo'载入 Linux 4.9.0-rc8-amd64 ...'
linux   

Bug#849637: not policy bugs

[Russell Coker]

On Friday, 6 January 2017 2:09:13 PM AEDT Laurent Bigonville wrote:
> I just retested myself and it's working with the kernel from unstable 
> (apparently you need >= 4.2) and the following line:
> 
> genfscon sysfs /devices/system/cpu/online
> gen_context(system_u:object_r:cpu_online_t,s0)
> 
> So yes it can be solved in the policy.

I just tried it again with that line in devices.te with kernel 4.8 and it 
didn't work for me.  Please send me a patch of exactly what you used.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#850489: RM: goiardi [s390x] -- RoM; ANAIS: left over of s390x golang removal

[Jordi Mallach]

Package: ftp.debian.org
Severity: normal

Hi ftp-master,

With the large removal of s390x arch-dep packages of golang bits, goiardi was
somehow left out, and is now having problems to transition due to missing
binaries.

Please remove goiardi/s390x.

Jordi

Bug#850488: RFS: groonga/6.1.3-1

[Kentaro Hayashi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: groonga
  Version : 6.1.3-1
  Upstream Author : Groonga Project 
* Url : http://groonga.org/
* Licenses: LGPL-2.1
  Section : database

It builds those binary packages:

  * groonga
  * groonga-server-common
  * groonga-server-gqtp
  * libgroonga-dev
  * libgroonga0
  * groonga-tokenizer-mecab
  * groonga-token-filter-stem
  * groonga-plugin-suggest
  * groonga-bin
  * groonga-httpd
  * groonga-doc
  * groonga-examples
  * groonga-munin-plugins

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

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

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga/groonga_6.1.3-1.dsc


More information about groonga can be obtained from
http://groonga.org/

Changes since last upload:

  * New upstream release.
  * debian/patches/fix-nginx-FTBFS-on-kfreebsd.patch
- Refresh patch to fix FTBFS on kFreeBSD.
  * debian/libgroonga0.install
- Drop removed file since Groonga 6.1.2.


pgpHGe9U7ZZZY.pgp
Description: PGP signature

Bug#850487: RFS: terminaltables/3.1.0-1 [ITP]

[Carl Suster]

Package: sponsorship-requests
Severity: wishlist
Control: block #850093 by -1
Control: block -1 by #850412

Dear mentors,

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

* Package name: terminaltables
  Version : 3.1.0-1
  Upstream Author : Robpol86 
* URL : https://github.com/Robpol86/terminaltables
* License : MIT
  Programming Lang: Python
  Description : Python library for printing tables to the console

I've packaged this because it is a dependency of flexget (ITP: #724718).
Note that this Build-Depends on colorclass (RFS: #850412) since it is used in
the test suite.

It builds those binary packages:

  python3-terminaltables - Python library for printing tables to the console
  python3-terminaltables-doc - Documentation for terminaltables table printer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/terminaltables/terminaltables_3.1.0-1.dsc


Cheers,
Carl

Bug#814313: group input is enough

[Adam Borowski]

> Ideally if root privs are to be dropped, logind is not available, and the
> input drivers will not have access to the input devices then the server
> could error out?  But I'm not sure if that's architecturally sane.  I
> guess the second best option would be, if logind is not present then the
> server perhaps should simply not drop root privs.

Alternatively it could setegid("input") when dropping root.  That's of
course worse than fine-grained access controls, but far better than
wholesale root privs.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#850486: xserver-xorg-core: please clarify NEWS.Debian wrt #814313

[Adam Borowski]

Package: xserver-xorg-core
Version: 2:1.19.0-3
Severity: wishlist

Hi!

Could you please edit NEWS.Debian for the benefit of non-systemd users?

It currently says just:
  * it relies on logind and libpam-systemd
which, according to my initial extensive but naive testing, isn't true:
everything works fine in typical use (aka using a login manager) even on
quite ancient hardware (userspace display access is needed only on ISA and
very earliest PCI graphics cards, present in machines hardly even supported
by Debian anymore -- plus hurd (not sure what's the coverage in kfreebsd)).

Only after ansgar's suggestion, I found out that it's "startx" that fails to
work.

Thus, could you please add such a clarification?  Such as:
- * it relies on logind and libpam-systemd
+ * it relies on logind and libpam-systemd (for startx but not *dm)

It'd help explain why the dependency on libpam-systemd is only a Recommends
and what are the consequencies of skipping it.  This especially matters as
systemd-shim is an unmaintained piece of poo that reportedly stopped working
even for folks for whom it used to work (that excludes me since the very
beginning).


Meow!

Bug#850485: diffoscope: APK support issues - traceback on existent directory & missing zipinfo & misleading apktool.yml file

[Emanuel Bronshtein]

Package: diffoscope
Version: 60
Severity: normal

Dear Maintainer,

3 issues regarding APK files (apk.py comparator) below:

#1 - Diffoscope fail to run on APKs if supplied via absolute paths.

Running: (using diffoscope from GIT)

/data/repbdiffs/repos/diffoscope/bin/diffoscope /tmp/1.apk /tmp/2.apk

Result:

Destination directory (/tmp/1.apk) already exists. Use -f switch if you want to 
overwrite it.
Traceback (most recent call last):
  File "/data/repbdiffs/repos/diffoscope/diffoscope/main.py", line 260, in main
sys.exit(run_diffoscope(parsed_args))
  File "/data/repbdiffs/repos/diffoscope/diffoscope/main.py", line 236, in 
run_diffoscope
parsed_args.path1, parsed_args.path2)
  File 
"/data/repbdiffs/repos/diffoscope/diffoscope/comparators/utils/compare.py", 
line 61, in compare_root_paths
return compare_files(file1, file2)
  File 
"/data/repbdiffs/repos/diffoscope/diffoscope/comparators/utils/compare.py", 
line 78, in compare_files
return file1.compare(file2, source)
  File "/data/repbdiffs/repos/diffoscope/diffoscope/comparators/utils/file.py", 
line 199, in compare
if hasattr(self, 'compare_details') or self.as_container:
  File "/data/repbdiffs/repos/diffoscope/diffoscope/comparators/utils/file.py", 
line 108, in as_container
self._as_container = self.__class__.CONTAINER_CLASS(self)
  File 
"/data/repbdiffs/repos/diffoscope/diffoscope/comparators/utils/archive.py", 
line 44, in __init__
self._archive = self.open_archive()
  File "/data/repbdiffs/repos/diffoscope/diffoscope/tools.py", line 50, in 
tool_check
return original_function(*args, **kwargs)
  File "/data/repbdiffs/repos/diffoscope/diffoscope/comparators/apk.py", line 
45, in open_archive
shell=False, stderr=None, stdout=subprocess.PIPE)
  File "/usr/lib/python3.5/subprocess.py", line 271, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['apktool', 'd', '-k', '-m', '-o', 
'/tmp/1.apk', '/tmp/1.apk']' returned non-zero exit status 1

it does work when running as:
cd /tmp && /data/repbdiffs/repos/diffoscope/bin/diffoscope 1.apk 2.apk

fix:
use temporary directory for apktool unpacking.

#2 - apktool.yml file created by apktool is shown as file from APK & contain 
input filenames (might be unrelated to files content)

apktool generate apktool.yml which contain metadata about the APK, more 
information:
https://ibotpeaches.github.io/Apktool/documentation/
but shown as file from APK which is incorrect, for example:
diffoscope 1.apk 2.apk
1.apk is: https://f-droid.org/repo/com.poinsart.votar_9.apk
2.apk is: https://verification.f-droid.org/com.poinsart.votar_9.apk

Result:

--- 1.apk
+++ 2.apk
├── apktool.yml
@@ -1,9 +1,9 @@
│  !!brut.androlib.meta.MetaInfo
│ -apkFileName: 1.apk
│ +apkFileName: 2.apk
│  compressionType: false
│  doNotCompress:
│  - arsc
│  isFrameworkApk: false
│  packageInfo: null
│  sdkInfo:
│minSdkVersion: '9'


it's better to show it as "APK metadata" (similar to "file list","metadata", 
etc..) instead of apktool.yml

also the apktool.yml contain the filename recevied by apktool at apkFileName 
field, thus if apktool was run directly on files supplied via command-line 
(instead of files inside archive) it will show difference that not related to 
APK content, example above and in:
https://verification.f-droid.org/org.sufficientlysecure.ical_54.apk.diffoscope.html

thus apkFileName field need to be striped from apktool.yml file. (the archive 
case is supported via zipinfo information, see next issue)

fix:
1. show apktool.yml difference as "APK metadata" instead of apktool.yml 
file
2. remove apkFileName field from apktool.yml result.

#3 missing zipinfo information

on ZIP files the zipinfo utility used to list files inside the archive (may 
contain difference in file-ordering/permissions/timestamps/etc..), but it is 
not used on APK files which are ZIP/JAR files.
for example, comparing the zipinfo on APKs:
https://f-droid.org/repo/com.nbossard.packlist_16.apk
https://verification.f-droid.org/com.nbossard.packlist_16.apk
show that there are new-files added & there is file-ordering issue, as happened 
before apk.py was added. (zip.py handled APK files)

fix:
use also the zipinfo mechanism as used currently on ZIP files via 
zip.py comparator on APK files.

Bug#846661: [Pkg-xfce-devel] Bug#846661: light-locker: screen remains black after unlock

[Gedalya]

On 12/07/2016 03:22 AM, Yves-Alexis Perez wrote:
> It's unlikely to be in light-locker/lightDM, try to check what's upgraded in
> the Xorg stack (xserver, driver etc.).
>
>

I've confirmed the problem appeared with systemd 232-1.
Downgrading to systemd 231-10 fixes everything.

This no doubt has to do with me refusing to use systemd as my init, using 
sysvinit instead.

This correlates with the shutdown, reboot, hibernate, suspend items grayed out 
in lightdm-gtk-greeter being grayed out, being unable to do anything with the 
network-manager applet inside the user session, etc.

These problems have come and gone multiple times in the last couple of years, 
but this particular issue with light-locker is a first for me.

See also #799890, #804165, #770885 to name a few.

Bug#850467: kodi: Wrong "device" path for lirc

[Alec Leamas]

On 07/01/17 02:57, Bálint Réczey wrote:




Hi,


A proper fix for this needs to be something accepted by upstream, I guess.


Kodi's build system allows setting the default device through a
./configure option
thus I think this does not have to be upstreamed.

Do you mean upstreaming a more complex device detection logic?


Hi...
Just syncing is of course the first, minimal step. But bottom line is 
that a lirc user could set the (typically secondary) device to anything, 
it's just a config file. So a compile-time setting will not make in the 
long run. Other apps e. g., mythTV has it as a runtime configuration, 
and that's the proper patch be it a part of a config file, the menu 
system or an environment variable.


It's only a fraction of the lirc users which doesn't use 
/run/lirc/lircd, but a fraction is not zerao.


Cheers!

Bug#849684: python-matplotlib: adequate reports broken symlink for python-matplotlib at jquery-ui.min.css

[Sandro Tosi]

control: reassign -1 libjs-jquery-ui

> have been /usr/share/javascript/jquery-ui/css/smoothness/ but
> unfortunately there is no ui.min.css even there.
>
> /usr/share/javascript/jquery-ui/css/smoothness> ll -h
>
> total 8.0K
> drwxr-xr-x 2 root root 4.0K 2016-11-10 16:06 .
> drwxr-xr-x 3 root root 4.0K 2015-09-28 08:49 ..

this is the problem: between 1.10.1 and 1.12.1 the directory contents
disappeared (current files list:
https://packages.debian.org/sid/all/libjs-jquery-ui/filelist) - please
libjs-jquery-ui maintainers have a look at this.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#850478: git-pbuilder deliberately deletes source.changes

[Russ Allbery]

James Clarke  writes:

> Currently, straight after git-pbuilder invokes pdebuild, it deletes
> ../*_source.changes, provided there is at least one such file, and the
> build was not done with -S. This causes two problems:

I did that originally for two reasons.  One, historically, the
*_source.changes file was completely worthless, since it was generated to
move the source package into the pbuilder chroot, where the source package
is then regenerated (and source-only builds weren't a thing).  So that
*_source.changes file has the wrong checksum for the *.dsc file, and is
entirely useless.  Two, I run gbp build-package and then want to view,
sign, and upload the corresponding changes file, and want to use *.changes
to refer to the one that's actually useful and uploadable.  Having another
changes file around requires typing quite a bit more of the file and
dealing with tab completion, and it's surprisingly irritating.

>  1. It ignores version numbers and package names, causing potential data
> loss, which I feel is justification enough for the Severity: important.

Yeah, it does that because I didn't know how to do better (and this
started life as my personal script for my workflow, and at the time all
*_source.changes files were garbage).

> In looking into this, I discovered that pdebuild itself actually
> ends up producing a _source.changes, since it calls
> dpkg-buildpackage -S to generate the dsc to copy into the chroot. I
> presume that the original intention of the deletion performed by
> git-pbuilder was to delete *this* changes file, since the dsc
> subsequently produced by the build inside the chroot will not be
> identical, but is copied back as part of the build, making the
> original _source.changes invalid.

Correct.

> Now, I'm of the view that dpkg-source -b should be used instead,
> which is what sbuild uses to create the dsc. This also has the
> advantage of not generating .buildinfo files (no annoying
> debian/files lingering after the build, either). Then the only
> _source.changes generated by pbuilder would be if the user requested
> it, and therefore having it deleted by git-pbuilder would be wrong.
> I should think changes like this are too late for Stretch, but
> perhaps for Buster (or experimental?) we could coordinate our
> efforts to get this to work?

Yeah, this seems reasonable to me.  Definitely happy to change
git-pbuilder once pdebuild is fixed to not produce the spurious and
useless *_changes.file.

-- 
Russ Allbery (r...@debian.org)   

Bug#838301: src:matplotlib: error when importing matplotlib.tests

[Sandro Tosi]

On Wed, Sep 21, 2016 at 5:59 AM, Ghislain Vaillant  wrote:
> Any idea where the issue could come from?

this happened mainly with the py3k package because it is more recent
than the py2 one: if you installed a brand new machine (or remove
--purge python-matplotlib) you'll see it also on on py2. I have a fix
that will be applied with the next upload

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#850467: kodi: Wrong "device" path for lirc

[Bálint Réczey]

Hi,

2017-01-06 21:27 GMT+01:00 Alec Leamas :
> On Fri, 06 Jan 2017 20:27:05 +0100 Thomas Renard  wrote:
>
>>
>> kodi is hard coded to the wrong "device" path to lirc.
>> The binary tries /dev/lircd but the "device" (which is a socket!)
>> can be found at /var/run/lirc/lircd.
>
> Hi!
>
> lirc maintainer speaking... note that the /var/run/lirc/lircd path just is a
> default configuration value from a lirc user's point of view. Specifically,
> in scenarios with several remotes (e. g., one doing ir blasting) the path
> could be something else. So, even if changing the hardcoded default will
> solve Thomas's  problem, it will not solve all users.

Thanks for the comments!
I plan syncing the default device with lirc in the next upload to at leas cover
users with default configuration.

>
> A proper fix for this needs to be something accepted by upstream, I guess.

Kodi's build system allows setting the default device through a
./configure option
thus I think this does not have to be upstreamed.

Do you mean upstreaming a more complex device detection logic?

Cheers,
Balint

Bug#850484: bind9utils: dnssec-keygen does not create valid successor keys for ECDSA KSKs

[Harry Robinson]

Package: bind9utils
Version: 1:9.9.5.dfsg-9+deb8u8
Severity: normal

Dear Maintainer,

I am trying to use dnssec-keygen to generate successor keys for a KSK rollover 
on my DNSSEC signed zone. When using dnssec-keygen with the -S operator, 
specifying the current KSK, the successor KSK is generated as a 'stub' file. 
This file contains only metadata, no key content, and is given the key ID 0.
After testing, I have determined that this occurs when attempting to rollover 
ECDSAP384SHA384 and ECDSAP256SHA256 keys. RSA key rollovers work as expected.
Attached is terminal output of my testing to replicate the bug:

a) Generate ECDSAP384SHA384 KSK & ZSK
b) Amend timing data of KSK
c) Attempt to generate successor key - fails - invalid stub keyfile generated

Repeat the above with an RSA KSK & ZSK - works OK, valid key generated.
Repeat the above with an ECDSAP256SHA256 KSK & ZSK - fails.

Begin terminal output:
--

root@rpi:/var/lib/bind/zones# cd internal/
root@rpi:/var/lib/bind/zones/internal# mkdir example.com/
root@rpi:/var/lib/bind/zones/internal# cd example.com/
root@rpi:/var/lib/bind/zones/internal/example.com# ls
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -a 
ECDSAP384SHA384 -3 -n ZONE -c IN -r /dev/urandom -P now -A now example.com
Generating key pair.
Kexample.com.+014+15094
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -a 
ECDSAP384SHA384 -3 -n ZONE -c IN -r /dev/urandom -P now -A now -f KSK 
example.com
Generating key pair.
Kexample.com.+014+61808
root@rpi:/var/lib/bind/zones/internal/example.com# ls
Kexample.com.+014+15094.key  Kexample.com.+014+61808.key
Kexample.com.+014+15094.private  Kexample.com.+014+61808.private
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-settime -I 20170110 
-D 20170110 Kexample.com.+014+61808
./Kexample.com.+014+61808.key
./Kexample.com.+014+61808.private
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -S 
Kexample.com.+014+61808 -i 2d
Generating key pair.
Kexample.com.+014+0
root@rpi:/var/lib/bind/zones/internal/example.com# ls
Kexample.com.+014+0.key  Kexample.com.+014+61808.key
Kexample.com.+014+15094.key  Kexample.com.+014+61808.private
Kexample.com.+014+15094.private
root@rpi:/var/lib/bind/zones/internal/example.com# rm *
root@rpi:/var/lib/bind/zones/internal/example.com# ls
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -a RSASHA256 
-b 2048 -f KSK example.com
Generating key 
pair...+++..+++
Kexample.com.+008+60019
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -a RSASHA256 
-b 1024 example.com
Generating key pair..++ 
..++
Kexample.com.+008+34614
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-settime -I 20170110 
-D 20170110 Kexample.com.+008+60019
./Kexample.com.+008+60019.key
./Kexample.com.+008+60019.private
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -S 
Kexample.com.+008+60019 -i 2d
Generating key pair..+++ 
...+++
Kexample.com.+008+00439
root@rpi:/var/lib/bind/zones/internal/example.com# rm *
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -a 
ECDSAP256SHA256 -f KSK example.com
Generating key pair.
Kexample.com.+013+35490
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -a 
ECDSAP256SHA256 example.com
Generating key pair.
Kexample.com.+013+41709
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-settime -I 20170110 
-D 20170110 Kexample.com.+013+35490
./Kexample.com.+013+35490.key
./Kexample.com.+013+35490.private
root@rpi:/var/lib/bind/zones/internal/example.com# dnssec-keygen -S 
Kexample.com.+013+35490 -i 2d
Generating key pair.
Kexample.com.+013+0

---
End terminal output

Sample output of 'stub' keyfile:

; This is a key-signing key, keyid 0, for example.com.
; Created: 20170107010646 (Sat Jan  7 01:06:46 2017)
; Publish: 2017010800 (Sun Jan  8 00:00:00 2017)
; Activate: 2017011000 (Tue Jan 10 00:00:00 2017)
example.com. IN DNSKEY 49409 3 13


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

Kernel: Linux 4.4.26-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)

Versions of packages bind9utils depends on:
ii  libbind9-901:9.9.5.dfsg-9+deb8u8
ii  libc6  2.19-18+deb8u6
ii  libcap21:2.24-8
ii  libcomerr2 1.42.12-2
ii  libdns100  1:9.9.5.dfsg-9+deb8u8

Bug#850329: [pkg-wine-party] Bug#850329: wine creates files with binary filenames

[Vincent Lefevre]

Control: reassign -1 autoconf 2.69-10
Control: retitle -1 autoconf generates code that can execute binary data as a 
shell script
Control: tags -1 -moreinfo -unreproducible
Control: severity -1 important

since this breaks Subversion in particular, requiring manual clean-up
of the directory (though the real culprit of the mess is dash).

On 2017-01-06 18:34:47 +0100, Jens Reyer wrote:
> are the tests that you run available somewhere, so that I can try to
> reproduce this?

I could reproduce it after removing the .wine directory, though it is
not necessarily related to wine at all (perhaps just a coincidence),
as I've now found the cause of the problem, and wine is not involved.
In a MPFR working copy (trunk), I just typed:

./configure --host=i586-mingw32msvc --disable-shared 
--with-gmp=/usr/local/gmp-mingw32 --enable-assert=full --enable-thread-safe

/usr/local/gmp-mingw32 is where a mingw32 version of GMP had been
installed last year, with:

$ ./configure --host=i586-mingw32msvc --disable-shared 
--prefix=/usr/local/gmp-mingw32 CC="i586-mingw32msvc-gcc 
-D__USE_MINGW_ANSI_STDIO"
$ make
$ make check LOG_COMPILER=wine
$ make install

Now, back to the problem, the following file was created by the
configure command in the MPFR directory:

-rw-r--r--  1 vlefevre vlefevre   0 2017-01-07 02:03:23 
pX\016\005\v\005\340\a\001\v\001\002\033\030*\004\340\024\0200\@\020\002\004\001\004\260\005\004}\030\006\003\@\001

In the config.log file, I can see:

configure:4348: checking whether we are cross compiling
configure:4356: i586-mingw32msvc-gcc -D__USE_MINGW_ANSI_STDIO -o conftest.exe 
-m32 -O2 -pedantic -fomit-frame-pointer -mtune=pentium -march=pentium  
-I/usr/local/gmp-mingw32/include  -L/usr/local/gmp-mingw32/lib conftest.c  >&5
configure:4360: $? = 0
configure:4367: ./conftest.exe
./conftest.exe: 1: ./conftest.exe: MZ
: not found
./conftest.exe: 2: ./conftest.exe: 
B/57X
@0B/70B
B/81
B/92
: not found
./conftest.exe: 1: ./conftest.exe: 
.text
: not found
./conftest.exe: 1: ./conftest.exe: Syntax error: word unexpected (expecting ")")
./conftest.exe: 1: ./conftest.exe: .data00
.rdata: not found
configure:4371: $? = 2
configure:4386: result: yes
./conftest.exe: 1: ./conftest.exe: 
.idata
: not found
./conftest.exe: 2: ./conftest.exe: 
[: not found

So, this is a bug in autoconf, which tries to execute a Windows
program, which is then interpreted by dash as a shell script:

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

but autoconf must have workarounds for known bugs, in particular
when the user has no control over the test like above.

Since --host is provided the check "whether we are cross compiling"
is useless, as one explicitly declares a cross-compilation:

  --host=HOST   cross-compile to build programs to run on HOST [BUILD]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#850483: truncated lines going off the right edge

[積丹尼 Dan Jacobson]

X-debbugs-Cc: Katsumi Yamaoka 
Package: w3m
Version: 0.5.3-34

$ w3m http://android.stackexchange.com/questions/142533/
has truncated lines going off the right edge.
Lynx works fine.

Bug#850482: nmu: ardour_1:5.5.0~dfsg-1

[James Cowgill]

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

Hi,

Please can ardour be binNMUed against fftw3 3.3.5-3. That version of
fftw3 tightens the package dependencies which is needed for a new API
used by ardour.

Thanks,
James


nmu ardour_1:5.5.0~dfsg-1 . ANY . unstable . -m "rebuild for stricter fftw3 
dependency"

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

Kernel: Linux 4.8.0-2-amd64 (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)



signature.asc
Description: OpenPGP digital signature

Bug#850419: [Pkg-javascript-devel] Bug#850419: Bug#850419: Local installation seems needed

[Jonas Smedegaard]

Quoting Pirate Praveen (2017-01-07 01:02:53)
> On വെള്ളി 06 ജനുവരി 2017 11:10 വൈകു, Bastien ROUCARIES wrote:
> > On Fri, Jan 6, 2017 at 6:39 PM, Bastien ROUCARIES
> >  wrote:
> >> On Fri, Jan 6, 2017 at 5:41 PM, Jonas Smedegaard  wrote:
> >>> How about patching the error message, as an intermediary step?
> >>
> >> How about adding an option --global to make grunt global
> > 
> > And even better add a environment variable GRUNT_FLAGS to pass flag to grunt
> 
> All of these are good options, we just need someone to write the code.
> I'm not well versed in javascript to write it myself.

Are you able to locate the error message string, and replace it with 
another string?  That, I believe, is all my suggestion requires.

No, sorry, I will not dive in and do it myself - I prioritize higher to 
get more of the ~400 packages under my wings in shape for Stretch.


 - Jonas

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

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

Bug#850481: RFS: pybind11/2.0.1-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: pybind11
  Version : 2.0.1-1
  Upstream Author : Wenzel Jakob 
* URL : https://github.com/pybind/pybind11
* License : BSD
  Section : libs

It builds those binary packages:

  pybind11-dev - seamless operability between C++11 and Python
  pybind11-doc - documentation for pybind11
  python-pybind11 - pybind11 helper module for Python 2
  python3-pybind11 - pybind11 helper module for Python 3

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pybind11/pybind11_2.0.1-1.dsc

Changes since the last upload:

  * New upstream release
  * Use missing sphinxdoc:Built-Using
substitution

Regards,
Ghislain Vaillant

Bug#850480: choqok: Posts to pump.io servers are escaped.

[Jason Riedy]

Package: choqok
Version: 1.6-1
Severity: important
Tags: upstream

All posts to my account at fmrl.me via choqok are fully escaped and nigh 
illegible.  See https://fmrl.me/jasonriedy .

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

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

Versions of packages choqok depends on:
ii  kio5.28.0-1
ii  libc6  2.24-8
ii  libgcc11:7-20161115-1
ii  libkf5attica5  5.28.0-1
ii  libkf5auth55.28.0-1
ii  libkf5bookmarks5   5.28.0-1
ii  libkf5codecs5  5.28.0-1
ii  libkf5completion5  5.28.0-1
ii  libkf5configcore5  5.28.0-1
ii  libkf5configgui5   5.28.0-1
ii  libkf5configwidgets5   5.28.0-1
ii  libkf5coreaddons5  5.28.0-1
ii  libkf5emoticons-bin5.28.0-1
ii  libkf5emoticons5   5.28.0-1
ii  libkf5globalaccel5 5.28.0-1
ii  libkf5guiaddons5   5.28.0-1
ii  libkf5i18n55.28.0-1
ii  libkf5itemviews5   5.28.0-1
ii  libkf5jobwidgets5  5.28.0-1
ii  libkf5kcmutils55.28.0-1
ii  libkf5kiocore5 5.28.0-1
ii  libkf5kiofilewidgets5  5.28.0-1
ii  libkf5kiowidgets5  5.28.0-1
ii  libkf5notifications5   5.28.0-1
ii  libkf5notifyconfig55.28.0-1
ii  libkf5parts5   5.28.0-1
ii  libkf5service-bin  5.28.0-1
ii  libkf5service5 5.28.0-1
ii  libkf5solid5   5.28.0-2
ii  libkf5sonnetcore5  5.28.0-1
ii  libkf5sonnetui55.28.0-1
ii  libkf5textwidgets5 5.28.0-1
ii  libkf5wallet-bin   5.28.0-3
ii  libkf5wallet5  5.28.0-3
ii  libkf5webkit5  5.28.0-1
ii  libkf5widgetsaddons5   5.28.0-1
ii  libkf5xmlgui5  5.28.0-1
ii  libqca-qt5-2   2.1.1-4
ii  libqca2-plugin-ossl2.1.1-4
ii  libqoauth2 2.0.1~1-2
ii  libqt5core5a   5.7.1+dfsg-2
ii  libqt5dbus55.7.1+dfsg-2
ii  libqt5gui5 5.7.1+dfsg-2
ii  libqt5network5 5.7.1+dfsg-2
ii  libqt5webkit5  5.7.1+dfsg-1
ii  libqt5widgets5 5.7.1+dfsg-2
ii  libqt5xml5 5.7.1+dfsg-2
ii  libstdc++6 7-20161115-1
ii  libtelepathy-qt5-0 0.9.6.1-6

choqok recommends no packages.

choqok suggests no packages.

-- no debconf information

Bug#846728: gcr: FTBFS: Test failures

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Hi Lucas

On Sat, 3 Dec 2016 08:41:49 +0100 Lucas Nussbaum  wrote:
> Source: gcr
> Version: 3.20.0-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161202 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

This is the error message from the log:

**
ERROR:gcr/test-gnupg-collection.c:214:test_reload: assertion failed:
(test->result)
FAIL: test-gnupg-collection 3 /gcr/gnupg-collection/reload
ERROR: test-gnupg-collection process failed: 250

I just tried to reproduce this in an up-to-date sid chroot and the
package built fine. The built was using gnupg_2.1.16-2 whereas my chroot
has 2.1.17-3. I wonder if that makes a difference.

Can you try to reproduce the issue?

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850478: git-pbuilder deliberately deletes source.changes

[James Clarke]

Package: git-buildpackage
Version: 0.8.9
Severity: important
X-Debbugs-Cc: Debian pbuilder maintenance team 


Disclaimer: These views are my own and not necessarily shared with
Mattia; he has the final say with regards to pbuilder :)

Hi,
Currently, straight after git-pbuilder invokes pdebuild, it deletes
../*_source.changes, provided there is at least one such file, and the
build was not done with -S. This causes two problems:

 1. It ignores version numbers and package names, causing potential data
loss, which I feel is justification enough for the Severity: important.
While it's a data loss bug, I don't think it's major enough to be RC.
(Please clone this if you want to separate this bug from the point
below...)

 2. I like being able to perform source-only uploads. While you can get
pbuilder to generate a source-only changes file for a source+binary
build with --changes-option=-S, this has the unfortunate side-effect
of not copying back the .deb files, since they aren't referenced by
the .changes. Also, the changes file is _arch.changes, which is
misleading, and having the real _arch.changes is useful. Thus, I
would like to have a --source-only-changes option which functions
like sbuild (the main dpkg-buildpackage invocation generates
_arch.changes, and then a manual dpkg-genchanges --build=source is
performed) so that users can get both from one build.

In looking into this, I discovered that pdebuild itself actually
ends up producing a _source.changes, since it calls
dpkg-buildpackage -S to generate the dsc to copy into the chroot. I
presume that the original intention of the deletion performed by
git-pbuilder was to delete *this* changes file, since the dsc
subsequently produced by the build inside the chroot will not be
identical, but is copied back as part of the build, making the
original _source.changes invalid.

Now, I'm of the view that dpkg-source -b should be used instead,
which is what sbuild uses to create the dsc. This also has the
advantage of not generating .buildinfo files (no annoying
debian/files lingering after the build, either). Then the only
_source.changes generated by pbuilder would be if the user requested
it, and therefore having it deleted by git-pbuilder would be wrong.
I should think changes like this are too late for Stretch, but
perhaps for Buster (or experimental?) we could coordinate our
efforts to get this to work?

This is not just hypothetical, either; I actually have patched
git-pbuilder[1] and pbuilder to implement this, but the implications
of the switch to dpkg-source -b would need to be discussed

I appreciate this is a lot of irrelevant details, but I hope by
explaining where we are and where I'd like to get to makes the issues
clear. A lot of this will end up going into a bug report against
pbuilder blocked by this tomorrow.

Regards,
James

[1] Commented out the 3-line if statement that deletes _source.changes

Bug#850479: steam: deletion of incompatible libraries from Steam Runtime not working correctly

[João Matos]

Package: steam
Source: steam
Version: 1.0.0.54-1
Tags: patch
Severity: important

Dear Maintainer,

In: https://sources.debian.net/src/steam/1.0.0.54-1/debian/script/steam/

Where it reads:
find $runtime -name libxcb.so\* \
   -o -name libgcc_s.so\* \
   -o -name libstdc++.so\* \
   -o -name libgpg-error.so\* \
   -delete

It should probably read this, instead:
find $runtime \( -name libxcb.so\* \
  -o -name libgcc_s.so\* \
  -o -name libstdc++.so\* \
  -o -name libgpg-error.so\* \
  \) -delete

Otherwise, find will only delete the libgpg-error files.

Thank you for your attention and sorry for any breach of etiquette on my 
part; I'm not too familiar with Debian's BTS.


João Matos

Bug#850419: [Pkg-javascript-devel] Bug#850419: Bug#850419: Local installation seems needed

[Pirate Praveen]

On വെള്ളി 06 ജനുവരി 2017 11:10 വൈകു, Bastien ROUCARIES wrote:
> On Fri, Jan 6, 2017 at 6:39 PM, Bastien ROUCARIES
>  wrote:
>> On Fri, Jan 6, 2017 at 5:41 PM, Jonas Smedegaard  wrote:
>>> How about patching the error message, as an intermediary step?
>>
>> How about adding an option --global to make grunt global
> 
> And even better add a environment variable GRUNT_FLAGS to pass flag to grunt

All of these are good options, we just need someone to write the code.
I'm not well versed in javascript to write it myself.



signature.asc
Description: OpenPGP digital signature

Bug#850422: Are you sure you want to upload a release candidate of a new version of h5py?

[Ghislain Vaillant]

On Fri, 2017-01-06 at 23:38 +0100, Andreas Tille wrote:
> Hi Gianfranco,
> 
> On Fri, Jan 06, 2017 at 09:33:31PM +, Gianfranco Costamagna wrote:
> > > > I wonder whether you want to upload this version of h5py to unstable
> > > > (rather than to experimental) since this seems to be a transition
> > > > and we are in transition freeze.
> > > > 
> > > 
> > > What do you mean by transition ? h5py has no abi and the changelog does 
> > > not mention any API breakage. Unless you had something else in mind ?
> > 
> > I also looked at the diff, and I didn't find ABI breakage...
> > did you see something I missed?
> 
> I mean that
> 
> $ apt-cache rdepends python-h5py | wc -l
> 34
> 
> packages depend from this package and I was burned by a similar issue
> when python-numpy was breaking one of my packages and other Debian
> Science members packages as well.  So did you tested whether all those
> rdepends will work with the new version?

Oh, I see what you are referring to. I am afraid I have not, and I am
putting my faith on upstream staying as conservative as they have been
with their releases since version 2.4.

I reckon a transition has never been needed for h5py since I took over
its maintenance, and I am crossing my fingers this won't be the case
for its 34 rdepends now (compared to 403 for numpy nonetheless).

Ghis

Bug#850084: jessie-pu: package asterisk/1:11.13.1~dfsg-2+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2017-01-06 at 21:03 +0100, Bernhard Schmidt wrote:
> On 05.01.2017 20:53, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2017-01-04 at 00:05 +0100, Bernhard Schmidt wrote:
> >> I would like to fix CVE-2016-9938 (Bug #847668) with the upcoming point 
> >> release. 
> >> The issue has been categorized no-dsa by the security team before.
> > 
> > Please go ahead.
> 
> Uploaded and processed, thanks.

Flagged for acceptance.

Regards,

Adam

Bug#604402: python-matplotlib-data: includes local copies of fonts

[Sandro Tosi]

some additional background info:

https://github.com/matplotlib/matplotlib/issues/6976
#843656, #831020

as to why we uses the bakoma fonts as shipped by mpl instead of the
ones provided by fonts-lyx

Bug#849869: jessie-pu: package unrtf/0.21.5-3

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2017-01-06 at 09:51 +0100, Willi Mann wrote:
> > Uploaded. Unfortunately, I realized after the upload that the debdiff
> > got bloated by my pbuilder build. I guess because unapply-patches is not
> > set. Let me know whether I should fix that.
> 
> False alarm- the diff is still fine. It just wasn't a good idea to
> compare the 2 unpacked versions of the source tree instead of using
> debdiff...

Flagged for acceptance.

Regards,

Adam

Bug#847273: jessie-pu: package mapserver/6.4.1-5

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 21:27 +0100, Sebastiaan Couwenberg wrote:
> On 01/05/2017 09:04 PM, Adam D. Barratt wrote:
> > On Tue, 2016-12-06 at 22:00 +0100, Sebastiaan Couwenberg wrote:
> >> Sorry for the outdated debdiff, for p-u the distribution has been
> >> changed to stable.
> > 
> > Please go ahead.
> 
> Thanks!

Flagged for acceptance.

Regards,

Adam

Bug#849698: jessie-pu: package python-crypto/2.6.1-5+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2017-01-06 at 15:58 +0100, Sebastian Ramacher wrote:
> Hi
> 
> On 2017-01-05 19:58:53, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Tue, 2017-01-03 at 14:05 +0100, Sebastian Ramacher wrote:
> > > Hi
> > > 
> > > On 2017-01-03 11:05:40, Sebastian Ramacher wrote:
> > > > On 2017-01-01 20:55:40, Sebastian Ramacher wrote:
> > [..]
> > > > > > 
> > > > > > On Thu, 2016-12-29 at 23:15 +0100, Sebastian Ramacher wrote:
> > > > > > > I'd like to fix CVE-2013-7459 (#849495) in jessie via the next 
> > > > > > > point release.
> > > > > > > The issue was marked as no-dsa.
> > > > > > > 
> > > > > > > The proposed debdiff is attached. The same patch was applied to 
> > > > > > > the package in
> > > > > > > unstable.
> > > > > > 
> > > > > > +  * Throw exception when IV is used with ECB or CTR (CVE-2013-7459)
> > [...]
> > > > Seems like python-paramiko broke in wheezy-lts (#850025). I will come 
> > > > back to
> > > > you once I've checked if stable is affected as well.
> > > 
> > > New debdiff is attached. Instead of throwing an exception the IV is simply
> > > ignored and a warning is displayed.
> > 
> > The patch itself still refers to exceptions in its metadata, fwiw.
> 
> Thanks, updated the metadata and explained the change compared to the original
> upstream patch.
> 
> > Please go ahead.
> 
> Uploaded with above change.

Flagged for acceptance in to p-u.

Regards,

Adam

Bug#841291: [Pkg-libvirt-maintainers] Bug#841291: libvirt-bin: qemu backport v2.6 needs a backported version of libvirt-bin in Jessie

[Peter Schaefer]

On Tue, 29 Nov 2016 18:18:18 +0100 Guido =?iso-8859-1?Q?G=FCnther?= 
 wrote:
> On Tue, Nov 29, 2016 at 10:17:07AM +0200, Mathieu Tarral wrote:
> >
> > Would you like to update libvirt to v1.3.1 then ?
> 
> We nned a proper backport, I've looked at this already a while back but
> will need time to finish it.

Much of the patch of the afm. commit is just test code which does not get used 
when building
the debian package. The patch against the relevant C-file can be rebased to 
apply to libvirt-1.2.9
as in jessie-proper; see below. That fixes the issue for me.

Regards,
 Peter

--- a/src/qemu/qemu_command.c   2017-01-06 23:04:47.562699747 +0100
+++ b/src/qemu/qemu_command.c   2017-01-06 23:13:08.320993263 +0100
@@ -467,6 +37,12 @@
 }

 virBufferEscape(, ',', ",", "%s,", source);
+
+if (disk->src->format > 0 &&
+disk->src->type != VIR_STORAGE_TYPE_DIR &&
+virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_FORMAT))
+virBufferAsprintf(, "format=%s,",
+  
virStorageFileFormatTypeToString(disk->src->format));
 }
 VIR_FREE(source);

@@ -3527,11 +3533,6 @@
_("transient disks not supported yet"));
 goto error;
 }
-if (disk->src->format > 0 &&
-disk->src->type != VIR_STORAGE_TYPE_DIR &&
-virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_FORMAT))
-virBufferAsprintf(, ",format=%s",
-  virStorageFileFormatTypeToString(disk->src->format));

 /* generate geometry command string */
 if (disk->geometry.cylinders > 0 &&

Bug#849962: jessie-pu: package libpng/1.2.50-2+deb8u3

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 19:51 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-01-02 at 17:27 +, Gianfranco Costamagna wrote:
> > CVE-2016-10087 is not worth a DSA, Security Team asked for a point release 
> > update.
> > 
> > diff -Nru libpng-1.2.50/debian/changelog libpng-1.2.50/debian/changelog
> > --- libpng-1.2.50/debian/changelog  2016-01-07 20:39:14.0 +0100
> > +++ libpng-1.2.50/debian/changelog  2017-01-02 18:24:35.0 +0100
> > @@ -1,3 +1,10 @@
> > +libpng (1.2.50-2+deb8u3) jessie; urgency=medium
> > +
> > +  * debian/patches/CVE-2016-10087.patch:
> > +- cherry-pick upstream fix for CVE-2016-10087
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#849865: jessie-pu: package postgresql-common/165+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 19:56 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2017-01-01 at 18:53 +0100, Christoph Berg wrote:
> > I would like to upload postgresql-common/165+deb8u2 with the diff
> > quoted below to jessie. It's fixing a data-loss bug, and a security
> > issue. The issues are already addresses in unstable (both in 178).
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#829606: jessie-pu: package duck/0.7+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2017-01-06 at 22:07 +0100, Simon Kainz wrote:
> Am 2017-01-06 um 22:04 schrieb Salvatore Bonaccorso:
> > Hi Simon
> > 
> > Looks you uploaded to the wrong host (security-master instead of
> > ftp-master), and the target distribution was set to jessie-security.
> > 
> > I have thus rejected the package on security-master.
> > 
> > So as Adam said, you need to change the target distribution to
> > 'jessie', then upload to ftp-master for the point release.
> 
> ok, sorry for the mess.
> 
> Will do as you suggested.

Flagged for acceptance.

Regards,

Adam

Bug#850301: xorg: Move from asciidoc to asciidoc-base as dependency

[Joseph Herlant]

Hi Julien,

I understand your frustration

On Fri, Jan 6, 2017 at 1:53 AM, Julien Cristau  wrote:

> Please revert the change in asciidoc instead.  It's unreasonable IMO to
> ask users (and I'm also talking about actual users, not just packages
> building man pages) to install latex stuff which most of them probably
> won't need.  If asciidoc merely Recommended the dblatex stuff, as (as
> far as I can tell) it used to, this would mostly go away.

dblatex was in the "Recommends" of asciidoc. By default the Recommends
packages are installed, so the actual users had that installation by
default before. That's the reason why asciidoc is now a dependency of
asciidoc-dbaltex.

What could be done would be to have asciidoc pulling asciidoc-base
instead of asciidoc-dbaltex. But that would impact the users relying
on the fact that dblatex was installed along with asciidoc before
(yes, there are users relying on that).

This split has been ask for several years now to be able to have a
package that don't have dblatex in the recommends.

> Also, whether something is in Recommends or not is irrelevant for
> build-depends, since Recommends are ignored for package builds.

Yes, I realized that after sending a few mails. Sorry for that confusion.

Joseph

Bug#849967: jessie-pu: package exim4/4.84.2-2+deb8u3

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 19:52 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-01-02 at 19:44 +0100, Andreas Metzler wrote:
> > I (and Heiko from exim upstream) would like to fix #845569 in jessie.
> > sid/testing already include the fix, it was part of 4.88~RC6.
> > 
> > The issue is a memleak in the GnuTLS code, the patch is a towo line
> > change. Heiko has provided a very nice writeup in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845569#20
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#849794: qtwebengine-opensource-src: FTBFS on buildd machines

[Santiago Vila]

On Sat, 31 Dec 2016, Scott Kitterman wrote:

> FTBFS bugs are only RC when there is an existing binary for the architecture.

That's not really accurate, because the binary could have been created
by "cheating" (for example, the package may have missing build-dependencies
but the uploaded packages were made in a chroot that had them installed).

What you mean here, I suppose, is that a FTBFS is not RC when the
failure only happens on architectures that were previously unsupported.

Logically, since this was the initial upload, the list of "supported
architetures" was initially empty.

Thanks.

Bug#157299: Pwd oi

[Sempre Fiel]

Password dades secretes administration oi

Enviado por Samsung Mobile

Bug#850305: dpmb: Move from asciidoc to asciidoc-base as dependency

[Joseph Herlant]

Hi Alex,

> BTW, the package asciidoc additionally also contains a lot of files in
> /etc/asciidoc/ related to tests. Are they important elsewhere except
> in conjunction with asciidoc-tests? (If not, I can file an according
> bug report, if you wish.)

I'll check that. Thanks. Yes, it would be great if you could file a
bug report for that. Thanks.

>> In addition to that, the xmlto package has been added to the
>> recommends of the asciidoc-base package in #692274, so it might not be
>> mandatory to have it in the buid-depends anymore.
>
> I'll check, thanks for the heads up!

Seems the build process ignores the recommends so you can ignore that part.

Bug#850381: phodav: Move from asciidoc to asciidoc-base as build dependency

[Joseph Herlant]

Hi Michael,


> While I have no real issue with the change itself, the timinig is odd.
>
> Isn't it a bit late to make such a disruptive change this close to the
> release and do a MBF? Has this been coordinated with the release team?
>
> Are they fine if packages get uploads for this?


The changes were in the repo since 2014 but the usual uploader lost
interest in the package so it never went through (I don't have upload
rights).
The split of the package has been released along with a fix for FTBS
and a fix for reproducibility.
This MBF I've done is really to be taken as wishlist, very minor in my
opinion and shouldn't be mandatory for the release.
No it has not been coordinated with the release team.

Joseph

Bug#849794: qtwebengine-opensource-src: FTBFS on buildd machines

[Santiago Vila]

severity 849794 serious
retitle 849794 qtwebengine-opensource-src: FTBFS in every arch (including 
"all") but amd64
thanks

On Sat, 31 Dec 2016, Boyuan Yang wrote:

> The root of FTBFS seems different on different architectures:
> 
> * i386: OOM
> * mips: "#error Please add support for your architecture in build/
> build_config.h"
> * armhf, armel: "fatal error: gnu/stubs-hard.h: No such file or directory"
> * kfreebsd: "Unknown platform. Qt WebEngine only supports Linux, Windows, and 
> OS X."
> * mipsel: "collect2: fatal error: ld terminated with signal 6 [Aborted]
> compilation terminated.
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc"

Well, you forgot the "all" architecture.

I tried to build this with "dpkg-buildpackage -A" and it failed as well:

https://people.debian.org/~sanvila/build-logs/qtwebengine-opensource-src/

[ Build failures in the "all" architecture are always serious.
  See Bug #830997 for details ].

If you prefer I could file a separate bug for this, but since this
report was already about unbuildability I thought it was simpler to
extend the scope and modify the subject as I did.

> I would suggest making a source-only upload (to experimental, maybe) after 
> applying fixes to test if the fixes are working correctly.
> 
> [0] https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src

Please make sure you try both "dpkg-buildpackage -A" and
"dpkg-buildpackage -B" before making another upload.

Thanks.

Bug#850023: ImportError when importing ruamel.yaml

[Chris Lamb]

Hi,

> ImportError when importing ruamel.yaml

So, the binary package is missing a Depends on `python-typing`.

However, it looks like this "should" work:

   install_requires=dict(
   […]
   py27=["ruamel.ordereddict", "typing"],
   […]
   )


Regards,

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

Bug#849845: [pkg-gnupg-maint] Bug#849845: Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

[shirish शिरीष]

Hi all,

I was able to get the new version -

─[$] sudo aptitude install gnupg=2.1.17-3 dirmngr=2.1.17-3
gpgv=2.1.17-3 gnupg-agent=2.1.17-3 gpgsm=2.1.17-3 scdaemon=2.1.17-3 -y

Installed it perfectly

─[$] apt-cache policy gnupg

[4:19:09]
gnupg:
  Installed: 2.1.17-3
  Candidate: 2.1.17-3
  Version table:
 *** 2.1.17-3 100
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 2.1.17-2 600
600 http://httpredir.debian.org/debian stretch/main amd64 Packages

I did see the changelog entry

┌─[shirish@debian] - [/usr/share/doc/gnupg] - [10069]
└─[$] zless changelog.Debian.gz

gnupg2 (2.1.17-3) unstable; urgency=medium

  * more bugfixes from upstream (improving but not yet closing: #849845)

 -- Daniel Kahn Gillmor   Tue, 03 Jan 2017 15:39:52 
-0500

But issue is still continuing -

─[$] gpg --keyserver pgp.mit.edu --recv-keys DAD95197

[4:22:18]
gpg: keyserver receive failed: No keyserver available

I tried multiple times with various other keys but didn't succeed.

So there's still work[TM] to be done .

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#850422: Are you sure you want to upload a release candidate of a new version of h5py?

[Andreas Tille]

Hi Gianfranco,

On Fri, Jan 06, 2017 at 09:33:31PM +, Gianfranco Costamagna wrote:
> >>I wonder whether you want to upload this version of h5py to unstable
> >>(rather than to experimental) since this seems to be a transition
> >>and we are in transition freeze.
> >>
> >
> >What do you mean by transition ? h5py has no abi and the changelog does not 
> >mention any API breakage. Unless you had something else in mind ?
> 
> I also looked at the diff, and I didn't find ABI breakage...
> did you see something I missed?

I mean that

$ apt-cache rdepends python-h5py | wc -l
34

packages depend from this package and I was burned by a similar issue
when python-numpy was breaking one of my packages and other Debian
Science members packages as well.  So did you tested whether all those
rdepends will work with the new version?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#850477: doveadm server sends incomplete certificate chain on tcps connection

[Juri Vitali]

Package: dovecot-core
Version: 1:2.2.13-12~deb8u1

Hi,
when configuring a doveadm listener service on a TCP port with SSL enabled, 
the server sends only the last certificate on the chain, instead of the 
complete chain.
The same server, when being contacted on IMAPS port, correctly sends the whole 
chain.

This issue is not present on the same upstream version (2.2.13), nor in the 
Debian jessie-backport version (1:2.2.26.0-4~bpo8+1), and impacts services as 
dsync mailbox replication (it complains about being unable to get issuer or 
local issuer certificate, depending on the certificate the sync client 
compares against).

Sample output from openssl s_client (the real domains are obfuscated for 
privacy reasons):
(doveadm port [15015]):
|$ openssl s_client -connect server.fqdn:15015
|CONNECTED(0003)
|depth=0 CN = mail.server.fqdn
|verify error:num=20:unable to get local issuer certificate
|verify return:1
|depth=0 CN = mail.server.fqdn
|verify error:num=21:unable to verify the first certificate
|verify return:1
|---
|Certificate chain
| 0 s:/CN=mail.server.fqdn
|   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
|---
...

|(IMAPS port [993]):
|$ openssl s_client -connect server.fqdn:993
|CONNECTED(0003)
|depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
|verify return:1
|depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
|verify return:1
|depth=0 CN = mail.server.fqdn
|verify return:1
|---
|Certificate chain
| 0 s:/CN=mail.server.fqdn
|   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
| 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
|   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
|---
...

This is the relevant output of dovecot -n:
|$ dovecot -n
|# 2.2.13: /etc/dovecot/dovecot.conf
|# OS: Linux 3.16.0-4-amd64 x86_64 Debian 8.6 
|auth_default_realm = server.fqdn
|auth_mechanisms = plain login
|doveadm_password = (redacted)
|doveadm_port = 15015
|mail_location = maildir:~/Maildir
|mail_plugins = " notify replication"
|namespace inbox { (removed) }
|passdb {
|  driver = pam
|}
|passdb {
|  args = username_format=%n /etc/vmail/%d/passwd
|  driver = passwd-file
|}
|plugin {
|  mail_replica = tcps:other.server.fqdn
|}
|protocols = " imap"
|service aggregator {
|  fifo_listener replication-notify-fifo {
|mode = 0666
|user = dovecot
| }
|  unix_listener replication-notify {
|mode = 0666
|user = dovecot
|  }
|}
|service auth {
|  unix_listener auth-client {
|group = Debian-exim
|mode = 0660
|  }
|}
|service doveadm {
|  inet_listener {
|port = 15015
|ssl = yes
|  }
|}
|service imap-login {
|  inet_listener imap {
|port = 143
|  }
|  inet_listener imaps {
|port = 993
|ssl = yes
|  }
|}
|service replicator {
|  process_min_avail = 1
|  unix_listener replicator-doveadm {
|mode = 0600
|  }
|}
|ssl = required
|ssl_cert = 

Bug#850434: Package for Debian Jessie

[Karsten Malcher]

Sorry - i have forgotten to write that this package is for Debian Jessie 
(Stable).
I didn't know how to address this to Backports.

At least i want to make this packages public available.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850433

Regards
Karsten

Bug#755545: Add glusterfs/libgfapi

[Gregory Auzanneau]

Dear Maintainer,

As finally, glusterfs was integrated to qemu (into qemu-block-extra) on 
12/28/2016 which close blocking bugs #775431 and #787112, is the 
integration of glusterfs to libvirt is possible now ?



Best regards,
Gregory Auzanneau

Bug#850476: icewm: Super+Space for execute commands within taskbar fails

[Awtul]

Package: icewm
Version: 1.3.8+mod+20161220-1
Followup-For: Bug #850476

Dear maintainer,

Please, also note that if I press Super+Space for run a command but for any 
reason I press Esc
for cancel, Ctrl+Alt+Left/Right for switch between workspaces won't work 
anymore; I also have 
to switch to another workspace using mouse for be able to use 
Ctrl+alt+left/right.

Cheers,

Awtul

Bug#850433: Package for Debian Jessie

[Karsten Malcher]

Sorry - i have forgotten to write that this package is for Debian Jessie 
(Stable).
I didn't know how to address this to Backports.

At least i want to make this packages public available.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850434

Regards
Karsten

Bug#850254: ITP: node-extract-zip -- unzip a zip file into a directory using 100% pure gluten-free organic javascript

[Holger Levsen]

On Fri, Jan 06, 2017 at 01:22:55PM -0800, Kunal Mehta wrote:
> The description comes from package.json's "description" field, which
> contained those words. I submitted an upstream pull request to remove
> it: .

Thank you, Kunal.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#746466: proofgeneral hijacks the emacs icon identity

[Jerome]

Hi,

FYI this bug is now also visible with KDE5 in stretch. The workaround 
(commenting

"StartupWMClass=Emacs" in the proogeneral.desktop file) works.

Thanks

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Erik Andresen]

Hi,

Agreed, sounds less intrusive. Confirmed working.

greetings,
Erik

Bug#780162: data loss causing default timeouts

[Nicholas D Steeves]

Hi,

I haven't seen the issue come up on the btrfs mailing list recently,
but in the year I've followed the list it has been fairly well
established that the default kernel SCT is too short for desktop-class
drives.  I haven't personally run into issues, because my drives have
7sec SCT ERC, and the default kernel SCT is 30sec.

In addition to linking to this bug, I referenced the following thread
on our wiki.d.o/btrfs page:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg53249.html

In my opinion, smartmontools should not default to attempting to
modify the SCT ERC of a drive.  Instead it should query the drive's
capabilities and only modify the kernel timeout if the query fails
(assume desktop drive) or returns a large value (proof of desktop
drive).  From what I gather, that would be sufficient to close this
bug.

The second issue seems like it needs a new (normal priority) bug to be
filed.  That bug might be a request for a debconf interface to
configure custom drive SCT ERC and kernel SCT values.  I imagine a
three column interface with device drive_SCT kernel_SCT columns would
do the trick.  This would be useful for following two cases:
  - tuning for greater performance (eg: read from redundant copy
instead of waiting 7 sec, for more consistent IOPS)
  - allows drives with firmware preconfigured for RAID to be used in
single disk volumes.  Eg: if a user buys a "NAS" drive with 7sec
SCT ERC, but wants maximum chance of recovery from read errors in
single drive configuration, then the drive's firmware timeout
should be reconfigured to something big like 120sec and the kernel
SCT should be bumped to 180sec; this is the expected behaviour
for single disk configuration.

A long time ago I read that too low kernel SCT values are also a
problem for ZFS, but of course the users who are hitting these
problems are using "desktop" drives with crippled firmware for RAID.

As I see it, this is an opportunity for Debian to distinguish itself
as exemplary, because other distributions have not yet addressed these
emerging issues.  Of course, those "in the know" have already
configured their systems correctly using rc.local...

Sincerely,
Nicholas


signature.asc
Description: Digital signature

Bug#781987: Regarding bug #781987 - dwww: All links are broken after clean install

[Jerome]

Hi,

I have a similar problem, but after an upgrade to stretch from jessie. 
The dwww installation used to work perfectly under jessie, but after 
upgrading dwww is only partially functional: links of the form 
"/cgi-bin/dwww/usr/share/doc/*" will fail with an apache2 internal 
server error 500. When looking at the apache log I get:



[Fri Jan 06 21:34:53.830541 2017] [http:error] [pid 6785:tid 
140419151554304] [client ::1:45220] AH02429: Response header name 'Last 
modified' contains invalid characters, aborting request, referer: 
http://localhost/dwww/


I have only very basic experience with apache, and increasing the log 
level to the maximum does not provide more useful information. In 
particular I can't get the content of the problematic header field from 
apache itself.


So I tried to call the dwww CGI directly, in /usr/lib/cgi-bin and as 
user www-data, with:
   QUERY_STRING=type=html REQUEST_METHOD=GET 
PATH_INFO=/usr/share/doc/python3.5/html/library/index.html 
HTTP_HOST=localhost HTTP_REFERER=http://localhost/dwww/ ./dwww


This generated what looks like proper output, the header is:
 Content-type: text/html
 Last modified: Tue Dec 13 14:16:35 2016
 Content-Disposition: inline; filename="index.html"

The 'Last modified' looks ok to me... Any idea on how to progress on 
this welcomed --- I have no experience in CGI development and only very 
basic Apache admin skill. Googling got me this far, but now I'm stuck.


Thanks

Bug#800707: systemd: Sytem hangs on shutdown when nfs-shares are mounted via autofs

[Wolf-Dieter Groll]

Dear Maintainer,

I just encountered the same problem after upgrading two laptops from
Xubuntu 14.04 LTS to the actual version of Debian Jessie. One running
the i386 version, the other amd64.

With Xubuntu autofs worked smoothly, but since the upgrade to jessie
shutdown fails as long as there are any mounted nfs-shares.

Shutting down brings up a black screen with a blinking cursor in the top
left corner on both systems. After a few minutes there is some output:

System 1 (i386):


 Starting Store Sound Card State...
[  OK  ] Started Store Sound Card State
[  OK  ] Started Synchronise Hardware Clock to System Clock
[  OK  ] Unmounted /autofs/nfs/QNAP/Backup
[  OK  ] Stopped target Network is Online
[  OK  ] Stopped target Network.
 Stopping LSB: Raise network interfaces
[  OK  ] Stopped target Remote File Systems (Pre).
[  OK  ] Stopped LSB: Raise network interfaces..
 Stopping Load/Save Random Seed...
[  OK  ] Stopped target Local File Systems.
 Unmounting /proc/fs/nfsd...
 Unmounting /etc/machine-id
 Unmounting /home...
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Unmounted /proc/fs/nfsd...
[  OK  ] Unmounted /etc/machine-id
[  OK  ] Unmounted /home...
[  OK  ] Reached target Unmount All Filesystems
[  OK  ] Stopped target Local File Systems (Pre).
 Stopping Create Static Device Nodes in /dev...
[  OK  ] Stopped Create Static Device Nodes in /dev.
 Stopping Remount Root and Kernel File Systems...
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown
[ 1647.145346] watchdog watchdog0: watchdog did not stop!


And the final output of the other system:

[  OK  ] Unmounted /autofs/nfs/QNAP/Backup
[  OK  ] Stopped target Network is Online
[  OK  ] Stopped target Network.
 Stopping LSB: Raise network interfaces
[  OK  ] Stopped target Remote File Systems (Pre).
[  OK  ] Stopped LSB: Raise network interfaces..
 Stopping Load/Save Random Seed...
[  OK  ] Stopped target Local File Systems.
 Unmounting /run/user/1000...
 Unmounting /run/user/120...
 Unmounting /proc/fs/nfsd...
 Unmounting /etc/machine-id...
 Unmounting /tmp...
 Unmounting /home...
[  OK  ] Stopped Load/Save Random Seed.
 Unmounting /var...
[  OK  ] Failed unmounting /var.
[  OK  ] Unmounted /run/user/1000.
[  OK  ] Unmounted /run/user/120.
[  OK  ] Unmounted /etc/machine-id.
[  OK  ] Unmounted /tmp.
[  OK  ] Unmounted /home.
[  OK  ] Unmounted /proc/fs/nfsd.
 Unmounting /dev/sdb1...
[  OK  ] Unmounted /dev/sdb1...
[  OK  ] Reached target Unmount All Filesystems
[  OK  ] Stopped target Local File Systems (Pre).
 Stopping Create Static Device Nodes in /dev...
[  OK  ] Stopped Create Static Device Nodes in /dev.
 Stopping Remount Root and Kernel File Systems...
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown

After this you have to remove the power (by pressing the power button
for a long time).
The systems won't shut down by themselves nor react on any keyboard or
touchpad entry.

Systemd should be able to shut down the system, even if there are faulty
or misbehaving services during shutdown.

Best regards
Wolf-Dieter Groll

Bug#850476: icewm: Super+Space for execute commands within taskbar fails

[Awtul]

Package: icewm
Version: 1.3.8+mod+20161220-1
Severity: normal

Dear Maintainer,

The built-in feature Super+Space for execute commands fails at second intent 
without switching 
to another workspace (I have to switch to another workspace for be able to use 
that feature again).

Thanks for your work,

Awtul


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

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

Versions of packages icewm depends on:
ii  fonts-dejavu-core   2.37-1
ii  icewm-common1.3.8+mod+20161220-1
ii  libc6   2.24-8
ii  libesd0 0.2.41-11
ii  libfontconfig1  2.11.0-6.7
ii  libgcc1 1:6.3.0-2
ii  libgdk-pixbuf2.0-0  2.36.2-1
ii  libglib2.0-02.50.2-2
ii  libice6 2:1.0.9-1+b1
ii  libsm6  2:1.2.2-1+b1
ii  libx11-62:1.6.4-2
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxrandr2  2:1.5.1-1

icewm recommends no packages.

icewm suggests no packages.

-- no debconf information

Bug#850469: dgit: Can't push: corrupted object

[Ian Jackson]

Nikolaus Rath writes ("Re: Bug#850469: dgit: Can't push: corrupted object"):
> On Jan 06 2017, Ian Jackson  wrote:
> >  2. If the faulty merge commit 1bc3c1e2d353 is at the top of your
> >  history and not buried in it, you can perhaps strip it off and try
> >  dgit push again with dgit 2.14.  You can use `git fsck --no-dangling'
> >  to check if that's the only faulty commit.
> 
> Ah, that must be the case then. So I used dgit for the first time and it
> immediately corrupted my history :-).

Sorry!

> I am not sure how to strip the commit though - as far as I can tell it
> exists in limbo without any associated branch...?

Oh, in that case you win.  I think if you install 2.14 or 2.16 and run
`dgit quilt-fixup' it will generate a fresh uncorrupted merge, then.

If so you can bump the revision to 1.1 and the push should work.

Ian.

Bug#850469: dgit: Can't push: corrupted object

[Ian Jackson]

Ian Jackson writes ("Re: Bug#850469: dgit: Can't push: corrupted object"):
> Oh, in that case you win.  I think if you install 2.14 or 2.16 and run
> `dgit quilt-fixup' it will generate a fresh uncorrupted merge, then.

Actually, I think this may be wrong wrong - maybe the merge is only
generated on push.

So maybe just trying again with 2.16 would work.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850422: Are you sure you want to upload a release candidate of a new version of h5py?

[Gianfranco Costamagna]

Hello

>>I wonder whether you want to upload this version of h5py to unstable
>>(rather than to experimental) since this seems to be a transition
>>and we are in transition freeze.
>>
>
>What do you mean by transition ? h5py has no abi and the changelog does not 
>mention any API breakage. Unless you had something else in mind ?


I also looked at the diff, and I didn't find ABI breakage...
did you see something I missed?

G.

Bug#850336: rmpi: FTBFS (Cannot find mpi.h header file)

[Santiago Vila]

Thanks for fixing this so quickly!

On Thu, Jan 05, 2017 at 08:13:37PM -0600, Dirk Eddelbuettel wrote:
> 
> On 6 January 2017 at 02:53, Santiago Vila wrote:
> | Hi.
> | 
> | I've triggered rebuilds in reproducible builds
> 
> Why? That wasn't what I asked you to do.
> 
> | and it also fails there:
> | 
> | https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rmpi.html
> 
> Well, doh. Computers and being deterministic and all that.

Well, to clarify a little bit, by "it also fails" I was referring
only to the fact that the package failed to build, and not to the
fact that it builds reproducibly or not. The URL was, then, just a
reference for the build failure which was independent from
buildd.debian.org and my own autobuilder.

I have a (personal) category of FTBFS bugs which fail randomly:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org

Since the failure of rmpi was not of this kind, you did not really
need my help to debug it, and I could continue reporting other bugs
(or going to bed, as it was late here :-). Sorry if it soundad like I
did not want to be helpful.

Thanks.

Bug#849020: jessie-pu: package systemd/215-17+deb8u6

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 13:30 +0100, Michael Biebl wrote:
> Am 05.01.2017 um 07:18 schrieb Adam D. Barratt:
> > Michael, please feel free to upload. 
> 
> Thanks. done
> 
> (I'm assuming that the resulting
> > package has had at least some testing on a jessie system already.)
> 
> I did test the invididual fixes in a jessie VM and lxc container, which
> included installing and running the final version of systemd_215-17+deb8u6.

Thanks for the confirmation.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#850422: Are you sure you want to upload a release candidate of a new version of h5py?

[Ghislain Vaillant]

Hi Andreas,

Le 6 janv. 2017 9:20 PM, "Andreas Tille"  a écrit :

Hi Ghislain,

I wonder whether you want to upload this version of h5py to unstable
(rather than to experimental) since this seems to be a transition
and we are in transition freeze.


What do you mean by transition ? h5py has no abi and the changelog does not
mention any API breakage. Unless you had something else in mind ?

Ghis

Bug#848829: jessie-pu: package nvidia-graphics-drivers-legacy-304xx/304.134-0~deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-12-31 at 17:17 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-12-20 at 03:09 +0100, Andreas Beckmann wrote:
> > for fixing CVE-2016-8826, CVE-2016-7382, CVE-2016-7389 in
> > nvidia-graphics-drivers-legacy-304xx we need to update to a new upstream
> > version.
> > 
> > The packaging contains further changes to
> > * switch from our manually maintained conftest.h (that had to be updated
> >   for each new upstream release) to using upstream's conftest.sh script
> >   instead. This required backporting several build system fixes for the
> >   kernel module.
> > * switch the source layout to have one .orig-$ARCH.tar.gz per
> >   architecture
> > * backport minor fixes and description updates from sid
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#846352: jessie-pu: package nvidia-graphics-drivers/340.98-1

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2017-01-04 at 14:00 +0100, Andreas Beckmann wrote:
> Control: retitle -1 jessie-pu: package nvidia-graphics-drivers/340.101-1
> 
> On 2016-12-31 18:36, Adam D. Barratt wrote:
> > On Wed, 2016-11-30 at 15:53 +0100, Andreas Beckmann wrote:
> >> again we have some CVEs in the proprietary nvidia driver:
> >> CVE-2016-7382, CVE-2016-7389: #846331
> 
> > Please go ahead; apologies for the delay.
> 
> I just uploaded the next upstream release 340.101 fixing another CVE:
> 
>   * New upstream legacy 340xx branch release 340.101 (2016-12-14).
> * Fixed CVE-2016-8826.  (Closes: #848195)
> * Improved compatibility with recent Linux kernels.
> 
> Some patches added/removed, but no further packaging changes over the
> big lot in 340.98.

Flagged for acceptance.

Regards,

Adam

Bug#850469: dgit: Can't push: corrupted object

[Nikolaus Rath]

On Jan 06 2017, Ian Jackson  wrote:
> Control: forcemerge 849041 -1
>
> Nikolaus Rath writes ("Bug#850469: dgit: Can't push: corrupted object"):
>> remote: dgit-repos-server: reject: corrupted object 
>> 1bc3c1e2d353386487d7d8e7740ebd21f369b107 (missing metadata)
>
> Unfortunately dgit 2.13 has a critical bug.  It generates corrupted
> commits.  See my message to d-d-a:
>   https://lists.debian.org/debian-devel-announce/2017/01/msg1.html
>
>> Help would be appreciated :-).
>> 
>> Is this version number really burned now, or can I still do an
>> upload with dput?
>
> It's worse than that.  Your git history needs to be rewritten.
> I will write in a moment with advice on what you should do about that.

I did read that message. But the affected package isn't in the list, and
I believe this is the first time that I'm actually uploading this
package with dgit.

> In the meantime, you have three choices:
>
>  1. Wait for advice from me on how to rewrite your history
>
>  2. If the faulty merge commit 1bc3c1e2d353 is at the top of your
>  history and not buried in it, you can perhaps strip it off and try
>  dgit push again with dgit 2.14.  You can use `git fsck --no-dangling'
>  to check if that's the only faulty commit.

Ah, that must be the case then. So I used dgit for the first time and it
immediately corrupted my history :-).

I am not sure how to strip the commit though - as far as I can tell it
exists in limbo without any associated branch...?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#849467: jessie-pu: package hplip/3.14.6-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2017-01-03 at 12:47 +, Adam D. Barratt wrote:
> On 2017-01-03 12:23, Didier 'OdyX' Raboud wrote:
> > Le mardi, 3 janvier 2017, 12.21:36 h CET Adam D. Barratt a écrit :
> >> You can't immediately re-use the version. Either we can reject the
> >> current package and you can then upload a fixed +deb8u1, or you can
> >> upload +deb8u2 which just adds the fix above.
> > 
> > It does make sense to re-use the same version, doesn't it? If so, 
> > please
> > reject, I'll upload after that.
> 
> There are advantages to both approaches.
> 
> In any case, I've asked dak to reject the current upload. Hopefully it 
> will action that soonish.

Re-uploaded and flagged for acceptance.

Regards,

Adam

Bug#850254: ITP: node-extract-zip -- unzip a zip file into a directory using 100% pure gluten-free organic javascript

[Kunal Mehta]

On 01/06/2017 05:04 AM, Holger Levsen wrote:
> On Thu, Jan 05, 2017 at 05:21:11PM +0530, Sumedh Pendurkar wrote:
>>   Description : unzip a zip file into a directory using 100% pure
>> gluten-free organic javascript
>  
> uhm, could you please remove that "gluten-free organic" from the short
> description? It comes across as offensive plus I also cannot see those
> terms at https://github.com/maxogden/extract-zip :/

The description comes from package.json's "description" field, which
contained those words. I submitted an upstream pull request to remove
it: .

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#850352: pristine-tar: perl errors, badly broken

[Tomasz Buchert]

> gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not found at 
> '../tarballs'

I cannot reproduce your problem.

I was able to successfully checkout texlive-bin_2016.20160513.41080.orig.tar.xz 
from
the textlive-bin repository using pristine-tar manually:

pristine-tar checkout ../texlive-bin_2016.20160513.41080.orig.tar.xz

and also via "gbp buildpackage -us -uc -rfakeroot" (I attach logs up to 
pristine-tar
invocation obtained with --git-verbose passed to gbp).

Please run gbp with --git-verbose and let me take a look.

Tomasz
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: /bin/true [] []
gbp:debug: ['git', 'status', '--porcelain']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'log', '--pretty=format:%H', '--grep=pristine-tar .* 
texlive-bin_2016.20160513.41080\\.orig.tar\\.', 'pristine-tar', '--']
gbp:debug: Found pristine-tar commit at 
'f89512d166e36a1d726b47f8fd891c4490e96b78'
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
'f89512d166e36a1d726b47f8fd891c4490e96b78^0']
gbp:debug: ['git', 'show', 
'--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', 
'-z', '--date=raw', '--no-renames', '--name-status', 
'f89512d166e36a1d726b47f8fd891c4490e96b78']
gbp:debug: Determined compression type 'xz'
gbp:debug: Looking for orig tarballs 
'texlive-bin_2016.20160513.41080.orig.tar.xz' at '../tarballs'
gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not found at 
'../tarballs'
gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar']
gbp:debug: /usr/bin/pristine-tar [] ['checkout', 
'/tmp/xxx/texlive-bin_2016.20160513.41080.orig.tar.xz']


signature.asc
Description: PGP signature

Bug#849488: Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2016-12-28 at 18:36 +, Adam D. Barratt wrote:
> [recipient list trimmed and sent to the release.d.o bug rather than the
> e2fsprogs one]
> 
> On Tue, 2016-12-27 at 19:56 +, Adam D. Barratt wrote:
> [...]
> > On Tue, 2016-12-27 at 12:31 -0500, Theodore Ts'o wrote:
> [...]
> > > Agreed, that seems to be the best way to handle things.  So that means
> > > we would need to do a binNMU for e2fsck-static/1.42.12-2 for the
> > > following architectures:
> > > 
> > > alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc
> > > 
> > > I've reassigned this to the release team to see if the Stable Release
> > > Managers agree (which hopefully they will).
> > 
> > Only three of those architectures - amd64, i386 and powerpc - are in
> > stable so are the only ones that are relevant as far as the release.d.o
> > bug is concerned. I've scheduled binNMUs for those; you'll have to
> > handle the others separately, or explain which Debian architectures you
> > actually meant (for instance, "arm" hasn't been used as a Debian
> > architecture name for several releases now).
> 
> Are binNMUs for any other architectures in stable required?

Answer came there none. However, I noticed that the libraries produced
by e2fsprogs are multi-arch:same, so I scheduled binNMUs for all
architectures in jessie, which have now been flagged for acceptance into
p-u.

Regards,

Adam

Bug#850214: jessie-pu: package jq/1.4-2.2

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 06:50 +, Adam D. Barratt wrote:
> On Thu, 2017-01-05 at 01:37 -0500, Harlan Lieberman-Berg wrote:
> > "Adam D. Barratt"  writes:
> > > On Thu, 2017-01-05 at 07:12 +0100, Salvatore Bonaccorso wrote:
> > >> Disclaimer: I'm not a member of release team, so this is not binding
> > >> statement :-)
> > 
> > Good advice is appreciated, no matter the source!
> > 
> > > What Salvatore said, please. :-)
> > 
> > Rebuilt with the corrected version.  debdiff attached.
> 
> Thanks; please go ahead. (That was implicit in the previous message, but
> I realise possibly not obvious.)

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-01-05 at 09:29 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 05 Jan 2017, Adam D. Barratt wrote:
> > On Fri, 2016-12-16 at 10:17 -0200, Henrique de Moraes Holschuh wrote:
> > > I would like to update the intel-microcode packages in stable to address
> > > several critical errata in newer Intel processors.
> > > 
> > > The updated packages being proposed in this bug report are identical to
> > > the ones in unstable/testing and jessie-backports, other than
> > > debian/changelog and version numbering.
> > > 
> > > These changes have been tested in unstable since 2016-11-09, in testing
> > > since 2016-11-15, and in jessie-backports since 2016-11-17, without any
> > > issues being reported.
> > 
> > Please go ahead.
> 
> Uploaded.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#850422: Are you sure you want to upload a release candidate of a new version of h5py?

[Andreas Tille]

Hi Ghislain,

I wonder whether you want to upload this version of h5py to unstable
(rather than to experimental) since this seems to be a transition
and we are in transition freeze.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#849538: jessie-pu: package ceph/0.80.7-2+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-12-31 at 17:08 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2016-12-28 at 11:38 +0100, Gaudenz Steinlin wrote:
> > I would like to update ceph with the next stable point release to fix
> > the 4 security issues listed below. These are all minor issues which did
> > not warrant a DSA on their own, but are still worth fixing.
> > 
> > https://security-tracker.debian.org/tracker/CVE-2016-9579
> > https://security-tracker.debian.org/tracker/CVE-2016-5009
> > https://security-tracker.debian.org/tracker/CVE-2016-7031
> > https://security-tracker.debian.org/tracker/CVE-2016-8626
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#843064: openssl: incompatibility for enc command between openssl 1.1.0b-2 and previous 1.0.x versions

[Sebastian Andrzej Siewior]

control: tags -1 pending

On 2016-11-07 14:33:38 [+0100], Marek Lukaszuk wrote:
> I'm following the conversation on openssl-dev mailing list. 
> I've checked the package changelog using "aptitude changelog openssl"
> before opening the ticket, so maybe putting it somewhere there would be
> a good thing, but probably news file and man page would help also lot.

I added something to the NEWS file [0]. I hope it does the job. The
manpage for enc says something about it but it might be hard to find…

[0] 
https://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/1.1.0/debian/NEWS?revision=871=markup

> Marek

Sebastian

Bug#850352: pristine-tar: perl errors, badly broken

[Tomasz Buchert]

On 06/01/17 11:48, Norbert Preining wrote:
> Package: pristine-tar
> Version: 1.37
> Severity: grave
> Justification: renders package unusable
> 
> HI all,
> 
> pristine-tar is somehow broken, to put it friendly:
> $ gbp buildpackage -us -uc -rfakeroot
> gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not found at 
> '../tarballs'
> gbp:error: Pristine-tar couldn't checkout 
> "texlive-bin_2016.20160513.41080.orig.tar.xz": Use of uninitialized value 
> $tarball in -e at /usr/bin/pristine-tar line 441.
> Use of uninitialized value $_[0] in substitution (s///) at 
> /usr/share/perl/5.24/File/Basename.pm line 180.
> fileparse(): need a valid pathname at /usr/bin/pristine-tar line 450.
> pristine-tar: failed to generate tarball
> $
> 
> But the files are in the pristine-tar branch
> $ git checkout pristine-tar
> $ ls texlive-bin_2016.20160513.41080*
> texlive-bin_2016.20160513.41080.orig.tar.xz.delta  
> texlive-bin_2016.20160513.41080.orig.tar.xz.id
> $
> 
> Thanks

Hi Norbert,
I assume the repo in question is 
https://anonscm.debian.org/cgit/debian-tex/texlive-bin.git.
I'm in the process of getting it and will try myself. But a few questions 
before:

  * can you run with -d/-v to get executed commands?
  * when did you notice the problem? the last upload was made in september so I 
wonder
how come we only see it now

In the meantime, I'll try to reproduce myself.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#829606: jessie-pu: package duck/0.7+deb8u1

[Simon Kainz]

Ah, sorry, i tried to follow [0], which then either is wrong or does not
apply in my case. Can someone enlighten me please.


[0]
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security

Am 2017-01-06 um 22:04 schrieb Salvatore Bonaccorso:
> Hi Simon
> 
> Looks you uploaded to the wrong host (security-master instead of
> ftp-master), and the target distribution was set to jessie-security.
> 
> I have thus rejected the package on security-master.
> 
> So as Adam said, you need to change the target distribution to
> 'jessie', then upload to ftp-master for the point release.

ok, sorry for the mess.

Will do as you suggested.

Bye,




> 
> Regards,
> Salvatore
> 



signature.asc
Description: OpenPGP digital signature

Bug#837800: Newer upstream version 2.7.1

[David Schiller]

Upstream is already at 2.7.1.
Any update on this?

Dave

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

Bug#850352: pristine-tar: perl errors, badly broken

[Norbert Preining]

Hi Tomasz,

Thanks for coming back. 

I'm away from my computer due to a long weekend here, but 
" Yes it is texlive-bin
* I guess I haven't done an upload since September 
" I cannot run with -d etc now, but will do when I'm back 

All the best 

Norbert 



On January 7, 2017 5:59:39 AM GMT+09:00, Tomasz Buchert  
wrote:
>On 06/01/17 11:48, Norbert Preining wrote:
>> Package: pristine-tar
>> Version: 1.37
>> Severity: grave
>> Justification: renders package unusable
>> 
>> HI all,
>> 
>> pristine-tar is somehow broken, to put it friendly:
>> $ gbp buildpackage -us -uc -rfakeroot
>> gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not
>found at '../tarballs'
>> gbp:error: Pristine-tar couldn't checkout
>"texlive-bin_2016.20160513.41080.orig.tar.xz": Use of uninitialized
>value $tarball in -e at /usr/bin/pristine-tar line 441.
>> Use of uninitialized value $_[0] in substitution (s///) at
>/usr/share/perl/5.24/File/Basename.pm line 180.
>> fileparse(): need a valid pathname at /usr/bin/pristine-tar line 450.
>> pristine-tar: failed to generate tarball
>> $
>> 
>> But the files are in the pristine-tar branch
>> $ git checkout pristine-tar
>> $ ls texlive-bin_2016.20160513.41080*
>> texlive-bin_2016.20160513.41080.orig.tar.xz.delta 
>texlive-bin_2016.20160513.41080.orig.tar.xz.id
>> $
>> 
>> Thanks
>
>Hi Norbert,
>I assume the repo in question is
>https://anonscm.debian.org/cgit/debian-tex/texlive-bin.git.
>I'm in the process of getting it and will try myself. But a few
>questions before:
>
>  * can you run with -d/-v to get executed commands?
>* when did you notice the problem? the last upload was made in
>september so I wonder
>how come we only see it now
>
>In the meantime, I'll try to reproduce myself.
>
>Cheers,
>Tomasz

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#829606: jessie-pu: package duck/0.7+deb8u1

[Salvatore Bonaccorso]

Hi Simon

Looks you uploaded to the wrong host (security-master instead of
ftp-master), and the target distribution was set to jessie-security.

I have thus rejected the package on security-master.

So as Adam said, you need to change the target distribution to
'jessie', then upload to ftp-master for the point release.

Regards,
Salvatore

Bug#849777: shutter: CVE-2016-10081: Insecure use of perl exec()

[Salvatore Bonaccorso]

Hi Dominique,

On Fri, Jan 06, 2017 at 07:33:07PM +0100, Dominique Dumont wrote:
> On Sat, 31 Dec 2016 12:39:57 +0100 Christoph Biedl  ulm.de> wrote:
> > Christoph Biedl wrote...
> > 
> > > The patch attached
> 
> Thanks.
> 
> I've tested the patch and it's fine.
> 
> I've also created a patch to replace all system("big string") calls to 
> system(@big_list) in all plugins to avoid similar problems.
> 
> I'll upload this soon :-) as a nmu :-(

Thanks.

Btw, it would be good/great to forward any applied patch to upstream.

Regards,
Salvatore

Bug#849845: [pkg-gnupg-maint] Bug#849845: Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

[Daniel Kahn Gillmor]

On Fri 2017-01-06 14:47:46 -0500, shirish शिरीष wrote:
> I can confirm Jaden's findings. Perhaps the content hasn't reached his
> mirror yet. It's same thing at my end. I just updated to see if the
> new version has come up at my end. (not even in sid/unstable)
>
> [$] apt-cache policy gpgv
>  [1:14:58]
> gpgv:
>   Installed: 2.1.17-2
>   Candidate: 2.1.17-2
>   Version table:
>  *** 2.1.17-2 600
> 600 http://httpredir.debian.org/debian stretch/main amd64 Packages
>   1 http://httpredir.debian.org/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> Timing is in IST. My last apt update run was about 5 minutes ago and I
> do know that the update mirrors are hit every 4 hours or more, so
> maybe in the next 4-8 hours the new binary might be available.

1 dkg@alice:~$ rmadison -a amd64 gpgv
gpgv   | 1.4.12-7+deb7u7 | oldstable   | amd64
gpgv   | 1.4.18-7+deb8u3 | stable  | amd64
gpgv   | 2.1.17-2| testing | amd64
gpgv   | 2.1.17-3| buildd-unstable | amd64
gpgv   | 2.1.17-3| unstable| amd64
0 dkg@alice:~$ 

I'm not sure what to make of this confusion, but it seems to be related
to the mirror network, not to the gnupg2 source package.  If it's still
a confusion or a problem for you in the next day, this might need to be
kicked over to the mirror network or the archive managers.

   --dkg

Bug#850475: Addition of --clear-sign alias breaks --clear

[Peter Palfrader]

Package: gnupg
Version: 2.1.17-2
Severity: normal

gpg's command line parser takes abbreviations for long options as
long as the option is uniquely identified.

So for decades "gpg --clear" has worked as shorthand for "gpg
--clearsign".

Now gpg has gotten a --clear-sign option as an alias for --clearsign,
and this breaks gpg --clear because it's no longer unambigious.

| weasel@orinoco:~$ echo fo | gpg --clear
| gpg: option "--clear" is ambiguous

Maybe you could also add a --clear alias, or maybe teach gpg that
both options that start with --clear are the same, so it is not, in
fact, ambigious.

Thanks for your consideration,
weasel

Bug#850431: History-rewriting handling is not quite complete

[Ian Jackson]

Control: retitle -1 git fetching must cope with downstream dsc copies
Control: severity -1 important

Currently when history rewriting has happened, a client fetching a
.dsc from a downstream gitless distro will not see the rewrites.  So
theose users may get the _wrong_ commits.

Also even if there has not been rewriting, there is not a good way for
the client to get the commits identified in some upstream .dsc.

I think more information will have to be put in the Dgit .dsc field.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#828556: sslscan: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2017-01-05 23:33:59 [+0100], Christoph Berg wrote:
> > why on libssl-dev (<< 1.1.0~)?
> 
> The | libssl-dev (<< 1.1.0~) part is there to enable backporting to
> jessie without having to revert libssl1.0-dev back to libssl-dev.

and I though that this is one of the changes you do when you intend to
backport a package. But now looking at some other packages I see that
more people did this :/ So I need to fix my tracker…

> > Otherwise I'm fine with it. I asked the release team & security if they
> > object adding openssl's source to sslscan and the release was not too
> > happy about it. With latest libssl1.0 upload sslscan won't be able to
> > detect 3des ciphers…
> 
> I guess with openssl 1.1 that would also be the case so it doesn't
> make a difference.

Yes. I did not imply to convert to 1.1 I just tried to point out some of
the limitations…

> Christoph

Sebastian

Bug#850469: dgit: Can't push: corrupted object

[Ian Jackson]

Control: forcemerge 849041 -1

Nikolaus Rath writes ("Bug#850469: dgit: Can't push: corrupted object"):
> remote: dgit-repos-server: reject: corrupted object 
> 1bc3c1e2d353386487d7d8e7740ebd21f369b107 (missing metadata)

Unfortunately dgit 2.13 has a critical bug.  It generates corrupted
commits.  See my message to d-d-a:
  https://lists.debian.org/debian-devel-announce/2017/01/msg1.html

> Help would be appreciated :-).
> 
> Is this version number really burned now, or can I still do an
> upload with dput?

It's worse than that.  Your git history needs to be rewritten.
I will write in a moment with advice on what you should do about that.

In the meantime, you have three choices:

 1. Wait for advice from me on how to rewrite your history

 2. If the faulty merge commit 1bc3c1e2d353 is at the top of your
 history and not buried in it, you can perhaps strip it off and try
 dgit push again with dgit 2.14.  You can use `git fsck --no-dangling'
 to check if that's the only faulty commit.

 3. Do a non-dgit upload.

In all of these cases I would recommend using a new version number.
Is there some reason why that's difficult ?  Reasoning about what can
safely be restarted in this anomalous situation is going to be
nontrivial.  If you choose one of the above options I can perhaps
think about it and advise.

Apologies for all the hassle.

Regards,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#849619: python-networkx: agressive use of Recommends

[Sandro Tosi]

On Wed, Dec 28, 2016 at 10:28 PM, Afif Elghraoui  wrote:
> There are many valid use cases of networkx on headless systems or where
> visualization is done by other, separate programs, possibly written in
> different languages where these currently recommended packages are not needed.

i consider the ability to generate graphical visualization of a graph
an important feature (not a core one), that's why those packages (all
required for visualization) are in Recommends. If you dont like them,
you can apt remove them or dont install recommends at all, but you are
not providing strong indication we should change this behavior (which
has been there since ~10 years).

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#850474: RFP: ZeroNet - Decentralized websites using Bitcoin crypto and BitTorrent network

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-privacy-maintain...@lists.alioth.debian.org

* Package name: zeronet
  Version : v0.5.0
  Upstream Author : HelloZeroNet
* URL : https://zeronet.io
* License : GPL-2
  Programming Lang: python
  Description : Decentralized websites using Bitcoin crypto and
BitTorrent network

long description:

Open, free and uncensorable websites, using Bitcoin cryptography and
BitTorrent network

license file:

https://github.com/HelloZeroNet/ZeroNet/blob/master/LICENSE

deb packaging:

https://github.com/HelloZeroNet/ZeroNet/issues/241

https://github.com/bashrc/zeronet-debian

Bug#850467: kodi: Wrong "device" path for lirc

[Alec Leamas]

On Fri, 06 Jan 2017 20:27:05 +0100 Thomas Renard  wrote:

>
> kodi is hard coded to the wrong "device" path to lirc.
> The binary tries /dev/lircd but the "device" (which is a socket!)
> can be found at /var/run/lirc/lircd.

Hi!

lirc maintainer speaking... note that the /var/run/lirc/lircd path just 
is a default configuration value from a lirc user's point of view. 
Specifically, in scenarios with several remotes (e. g., one doing ir 
blasting) the path could be something else. So, even if changing the 
hardcoded default will solve Thomas's  problem, it will not solve all 
users.


A proper fix for this needs to be something accepted by upstream, I guess.

Cheers!

--alec

Bug#789651: tacacs+: Incomplete systemd integration

[Bernhard Schmidt]

On Tue, Jun 23, 2015 at 11:20:26AM +0800, laalaa wrote:

Hi,

> Package: tacacs+
> Version: 4.0.4.27a-1
> Severity: normal
> 
> 
> Description:
> 
> tacacs+ is missing 'is-enabled' systemd integration:
>  
> # systemctl is-active tacacs_plus.service
> active
> 
> # systemctl enable tacacs_plus.service
> Synchronizing state for tacacs_plus.service with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d tacacs_plus defaults
> Executing /usr/sbin/update-rc.d tacacs_plus enable
> 
> # systemctl is-enabled tacacs_plus.service
> Failed to get unit file state for tacacs_plus.service: No such file or 
> directory
> 
> 
> Expected result:
> 
> # systemctl is-enabled tacacs_plus.service
> enabled
> 
> 
> Workaround:
> 
> Check if the link /etc/rc5.d/S02tacacs_plus exist or not, instead of using 
> 'systemctl is-enabled' command.

tacacs_plus in Debian has no systemd integration at all, only a LSB init
script.

The bug you see is a bug in systemd, see #760616. I doubt this will be
fixed for Jessie. It should work in Stretch due to improved systemd
behaviour.

Bernhard


signature.asc
Description: Digital signature

Bug#850473: gocryptfs: depends on golang -dev packages

[Abhijit Hoskeri]

Package: gocryptfs
Version: 1.2-1
Severity: normal

Dear Maintainer,

gocryptfs depends on development packages as given below: this pulls in
a large number of dependencies - is the dependency really necessary?

Thanks,
Abhijit


-- System Information:
Distributor ID: Ubuntu
Description:Ubuntu 14.04.1 LTS
Release:14.04
Codename:   trusty
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gocryptfs depends on:
ii  golang-github-jacobsa-crypto-dev  0.0~git2016.0.293ce0c-2
ii  golang-github-rfjakob-eme-dev 1.0-2
ii  libc6 2.24-8
ii  libssl1.1 1.1.0c-2

gocryptfs recommends no packages.

gocryptfs suggests no packages.

-- no debconf information

Bug#849266: [Pkg-lirc-maint] Bug#849266: Kodi problem

[Thomas Renard]

> That said, this is somewhat insane. That device is gone since very long.
> And given that everything in /dev is supposed to be handled by udev the
> old device really needs to be nuked. If it was some obscure app I could
> udnerstand it, but kodi...
> 

Reported kodi problem in #850467