Bug#875199:

[Joshua Honeycutt]

Synergy can already build against Qt5. I've made the changes in my
repository to do so.

Currently upstream is transitioning to a new GUI (closed source.) I'm
waiting for a new release, but I expect it will probably remove the
current GUI completely (and the Qt dependency.)

If you would like me to go ahead and push another 1.8.8 release to
unstable please let me know.

Bug#876328: asterisk: CVE-2017-14603: RTP/RTCP information leak (AST-2017-008)

[Salvatore Bonaccorso]

Source: asterisk
Version: 1:13.17.1~dfsg-1
Severity: grave
Tags: patch security upstream

Hi,

the following vulnerability was published for asterisk.

CVE-2017-14603[0]:
followup-to AST-2017-005: RTP/RTCP information leak

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14603
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14603
[1] http://downloads.asterisk.org/pub/security/AST-2017-008.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#876320: qgis: Fails to load /usr/lib/qgis/plugins/libgrass*7.so

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 09/21/2017 02:38 AM, Nelson A. de Oliveira wrote:
> While loading QGIS it's possible to see in the log messages panel, in
> the Plugins tab:
> 
> =
> Failed to load /usr/lib/qgis/plugins/libgrassplugin7.so (Reason: Cannot load 
> library /usr/lib/qgis/plugins/libgrassplugin7.so: (libgrass_gis.7.2.1.so: 
> cannot open shared object file: No such file or directory))
> Failed to load /usr/lib/qgis/plugins/libgrassprovider7.so (Reason: Cannot 
> load library /usr/lib/qgis/plugins/libgrassprovider7.so: 
> (libgrass_gis.7.2.1.so: cannot open shared object file: No such file or 
> directory))
> Failed to load /usr/lib/qgis/plugins/libgrassrasterprovider7.so (Reason: 
> Cannot load library /usr/lib/qgis/plugins/libgrassrasterprovider7.so: 
> (libgrass_gis.7.2.1.so: cannot open shared object file: No such file or 
> directory))
> =
> 
> It seems that something needs to be updated/recompiled for the new grass
> version (7.2.2)?

qgis was built when 7.2.1 was still in unstable.

qgis will be moved to unstable this weekend and hence will pickup the
7.2.2 packages.

Kind Regards,

Bas

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

Bug#876321: game-data-packager: Space Quest 5 (gog) fails to build package, could not find 119.scr

[Alexandre Detiste]

tag: -1 +moreinfo

Hi,

I can't reproduce this bug.

I packaged several time from an already downloaded setup.exe &

I also simulated Lgogdownloader code path many times and it worked in all cases.
(see tools/fake_lgog.py, this is a tool to avoid nagging GoG servers all the 
time)

I don't know, maybe you are running out of space on /tmp ?

Please enable debugging by preprending DEBUG=1 in front of 
game-data-packager-command.
--verbose will also make innoextract be more verbose about it's operation.

Then --no-search can make a difference if GDP find somewhere an unexpected, 
invalid 119.scr.

In short: please provide a reproducible test case.

Thank you,

Greets,

Alexandre

Le mercredi 20 septembre 2017, 19 h 50 min 30 s CEST Charles L a écrit :
> Package: game-data-packager
> Version: 53
> Severity: normal
> 
> Dear Maintainer,
> 
> Space Quest 5 fails to build from gog sources. It downloads a fresh copy from 
> gog but something is amiss. 
> I tested the same commands in a stretch VM which has version 49.1, and that 
> was sucessful. Please let me
> know if I can be of furthar assistance.
> 
> 
> NFO:game_data_packager.build:spacequest5-en-data can be downloaded with 
> lgogdownloader
> Getting game names (1/1) 40 / 40
> Getting game info 1 / 1
> 2017-Sep-20 19:44:30 [Thread #0] Begin download: 
> setup_space_quest5_2.1.0.15.exe
> 2017-Sep-20 19:44:36 [Thread #0] Download complete: 
> setup_space_quest5_2.1.0.15.exe (@ 4.94MB/s)
> 2017-Sep-20 19:44:36 [Thread #0] Finished all tasks
> #0: Finished
> identifying 
> /tmp/gdptmp.fe17qb1t/space_quest_5_the_next_mutation/setup_space_quest5_2.1.0.15.exe
> ERROR:game_data_packager.build:could not find 119.scr:
>   expected:
> size:   13036 bytes
> md5:479163131da6d18adcf2960a993aa841
> sha1:   None
> sha256: None
> ERROR:game_data_packager.build:Unable to complete any packages because 
> downloads failed.
> 
> 

Bug#875781: initramfs-tools-core: /etc/initramfs-tools/initramfs.conf is not modified on upgrade/install/reconfigure

[Piviul]

Package: initramfs-tools
Version: 0.130
Followup-For: Bug #875781

Dear Maintainer,

the same happens to me. The file /etc/initramfs-tools/initramfs.conf of
initramfs-tools package is different from the one in my PC and I have never
modified it and even reinstalling the initramfs-tools package the
initramfs.conf is different from the one in the package:

$ diff etc/initramfs-tools/initramfs.conf /etc/initramfs-tools/initramfs.conf
23c23
< # BUSYBOX: [ y | n | auto ]
---
> # BUSYBOX: [ y | n ]
25,27c25
< # Use busybox shell and utilities.  If set to n, klibc utilities will be
used.
< # If set to auto (or unset), busybox will be used if installed and klibc will
< # be used otherwise.
---
> # Use busybox if available.
30c28
< BUSYBOX=auto
---
> BUSYBOX=y

Have a great day

Piviul



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 31M Sep 18 20:58 
/boot/initrd.img-4.11.0-1-686-pae.old-dkms
-rw-r--r-- 1 root root 33M Sep  9 18:43 /boot/initrd.img-4.12.0-1-686-pae
-rw-r--r-- 1 root root 28M Jul  2  2016 
/boot/initrd.img-4.5.0-2-686-pae.old-dkms
-rw-r--r-- 1 root root 28M Oct  2  2016 
/boot/initrd.img-4.6.0-1-686-pae.old-dkms
-rw-r--r-- 1 root root 29M Nov 16  2016 
/boot/initrd.img-4.7.0-1-686-pae.old-dkms
-rw-r--r-- 1 root root 30M Dec 25  2016 
/boot/initrd.img-4.8.0-1-686-pae.old-dkms
-rw-r--r-- 1 root root 30M Feb 23  2017 
/boot/initrd.img-4.8.0-2-686-pae.old-dkms
-rw-r--r-- 1 root root 31M Mar  8  2017 
/boot/initrd.img-4.9.0-1-686-pae.old-dkms
-rw-r--r-- 1 root root 31M Jun  2 06:19 
/boot/initrd.img-4.9.0-2-686-pae.old-dkms
-rw-r--r-- 1 root root 31M Jul 14 07:37 
/boot/initrd.img-4.9.0-3-686-pae.old-dkms
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.12.0-1-686-pae 
root=UUID=246e415c-b337-4743-af3a-b56e02f4a28b ro quiet resume=/dev/sda5

-- resume
RESUME=UUID=753d7a40-5f4a-448b-8e66-eebea3cb4aff
-- /proc/filesystems
ext3
ext2
ext4
fuseblk

-- lsmod
Module  Size  Used by
rfcomm 49152  4
fuse   90112  3
bnep   20480  2
joydev 20480  0
hid_logitech   32768  0
ff_memless 16384  1 hid_logitech
usbhid 45056  0
uas20480  0
usb_storage49152  1 uas
iTCO_wdt   16384  0
intel_rapl 20480  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
kvm_intel 192512  0
kvm   438272  1 kvm_intel
wl   6152192  0
irqbypass  16384  1 kvm
btusb  40960  0
snd_hda_codec_hdmi 40960  1
crc32_pclmul   16384  0
btrtl  16384  1 btusb
btbcm  16384  1 btusb
btintel16384  1 btusb
snd_hda_codec_realtek69632  1
intel_cstate   16384  0
snd_hda_codec_generic65536  1 snd_hda_codec_realtek
bluetooth 409600  31 btrtl,btintel,bnep,btbcm,rfcomm,btusb
intel_uncore   86016  0
intel_rapl_perf16384  0
cfg80211  446464  1 wl
snd_hda_intel  32768  5
ecdh_generic   28672  1 bluetooth
pcspkr 16384  0
snd_hda_codec  90112  4 
snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
sg 28672  0
lpc_ich24576  0
rfkill 20480  5 bluetooth,cfg80211
mfd_core   16384  1 lpc_ich
snd_hda_core   53248  5 
snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
snd_hwdep  16384  1 snd_hda_codec
shpchp 32768  0
snd_soc_rt5640 73728  0
snd_soc_ssm456716384  0
snd_soc_rl6231 16384  1 snd_soc_rt5640
snd_soc_core  159744  2 snd_soc_ssm4567,snd_soc_rt5640
snd_compress   20480  1 snd_soc_core
snd_pcm81920  6 
snd_hda_intel,snd_hda_codec,snd_hda_core,snd_soc_rt5640,snd_hda_codec_hdmi,snd_soc_core
snd_timer  28672  1 snd_pcm
dw_dmac16384  0
snd57344  20 
snd_compress,snd_hda_intel,snd_hwdep,snd_hda_codec,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek,snd_soc_core,snd_pcm
battery20480  0
elan_i2c   28672  0
dw_dmac_core   24576  1 dw_dmac
snd_soc_sst_acpi   16384  0
soundcore  16384  1 snd
snd_soc_sst_match  16384  1 snd_soc_sst_acpi
evdev  20480  27
acpi_pad   16384  0
acpi_als   16384  0
kfifo_buf  16384  1 acpi_als
industrialio   49152  2 acpi_als,kfifo_buf
binfmt_misc20480  1
coretemp   16384  0
parport_pc 28672  0
ppdev  20480  0
lp 20480  0
parport36864  3 lp,parport_pc,ppdev
ip_tables  20480  0
x_tables   20480  1 ip_tables
autofs436864  2
ext4 

Bug#876327: ITP: newsboat -- text mode rss feed reader with podcast support

[Nikos Tsipinakis]

Package: wnpp
Severity: wishlist
Owner: Nikos Tsipinakis 

* Package name: newsboat
  Version : 2.10
  Upstream Author : Alexander Batischev
* URL : https://www.newsboat.org
* License : MIT/X Consortium
 Programming Lang : C++
 Description  : text mode rss feed reader with podcast support

 newsboat is an actively maintained for of newsbeuter, an innovative RSS feed
 reader for the text console.  It supports OPML import/exports, HTML rendering,
 podcast (podboat), offline reading, searching and storing articles to your
 filesystem, and many more features.

 Its user interface is coherent, easy to use, and might look
 common to users of mutt and slrn.

Bug#875842: User error

[Theppitak Karoonboonyanan]

Control: notfound -1 0.30-1

This appears to be my mistake. After checking im-config script
for ibus (/usr/share/im-config/data/21_ibus.rc), im-config already
attempts to use ibus GTK IM Module when available, and falls back
to XIM otherwise. My system just happenned to have libqt5gui5
installed, and the ibus package alternative dependencies were just
satisfied without ibus-gtk. When I install ibus-gtk manually,
GTK_IM_MODULE is properly set to "ibus" as desired.

So, I'm closing this bug as notfound. Sorry for the noise.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#876326: ITP: emacs-db -- database interface and sample implementation for Emacs Lisp

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: emacs-db
  Version : 0.0.6+git20140421.b3a423f
  Upstream Author : Nic Ferrier 
* URL : https://github.com/nicferrier/emacs-db
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : database interface and sample implementation for Emacs Lisp

I am packaging this as part of the dependency chain for nov-el, another
ITP of mine.

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848841: Was fixed in 0.111

[James Cameron]

Was fixed in Sugar 0.111

-- 
James Cameron

Bug#861052: Is fixed

[James Cameron]

Problem was in sugar-browse-activity, and was fixed for v201, latest
is v201.2.

-- 
James Cameron
http://quozl.netrek.org/

Bug#876325: texlive-latex-extra: File lt3graph.sty contains references to obsolete function \prop_get:cn

[Caraffini Diego]

Package: texlive-latex-extra
Version: 2017.20170818-1
Severity: important

Dear Maintainer,

While compling a document that uses pkgloader I received the following
message:

{\str_if_eq:nnT {##2}{##4}{\__graph_map_successors_tokens_aux:nnv {##\ETC.
! Forbidden control sequence found while scanning use of \__cs_generate_from_si
gnature:nnNNNn.
 
\par 
l.1229 {#3} {#5} {\prop_get:cn
  {\__graph_tl:nnn{graph}{#1}{vertices}}...

Further investigation revealed that the function \prop_get:cn was
removed sometime ago from expl3, but two references are still present in
the file l3graph.sty

NOTE: I have submitted apatch upstream;
https://github.com/mhelvens/latex-lt3graph/pull/7

minimal tex example:


\documentclass[12pt]{book}
\RequirePackage{pkgloader}
\LoadPackagesNow%
\begin{document}
\end{document}

Steps to reproduce:
1. save the example to file test.tex
2. run pdflatex
  pdflatex test
3. observe the issue manifest as described.

Expected result:
no error message and compilation continues to completion.

Best regards
Diego


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2857 Sep 18 18:08 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Aug 17 01:38 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 17 22:46 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 17 22:46 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 23 14:59 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 17 22:46 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 17 22:46 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5068 Sep 18 18:07 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 16  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 23 14:59 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-1
ii  tex-common 6.09
ii  texlive-base   2017.20170818-1
ii  texlive-binaries   2017.20170613.44572-6
ii  texlive-latex-recommended  2017.20170818-1
ii  texlive-pictures   2017.20170818-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2017.20170818-1
ii  texlive-latex-extra-doc2017.20170818-1
ii  texlive-plain-generic  2017.20170818-1

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.21-1
pn  libspreadsheet-parseexcel-perl  
ii  

Bug#876324: ITP: emacs-kv -- key/value data structure functions for Emacs Lisp

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: emacs-kv
  Version : 0.0.19+git20140108.7211484
  Upstream Author : Nic Ferrier 
* URL : https://github.com/nicferrier/emacs-kv
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : key/value data structure functions for Emacs Lisp

I am packaging this as part of the dependency chain for nov-el, another
ITP of mine.

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#875952: moon-lander: contains unlicensed images (and perhaps sounds)

[Adam Borowski]

> Package: moon-lander
> Version: 1:1.0-5+b1
> Severity: serious
> Justification: Policy 2.2.1

> images/backgrounds contains NASA photos which aren’t DFSG-free AFAIK.
> The sound files in sounds don’t have a documented origin.

Could you please name any of these images which are not in the Public
Domain?

As for sounds, eagle_has_landed.wav obviously comes from NASA as well;
the rest are trivial sound effects that could be either made by the game
authors' or come from any typical source of such assets.  As they're too
generic to search for, I'd say an assumption they are legitimately covered
by the license unless there's any evidence to the contrary is reasonable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Bug#876323: texlive-latex-extra: Changes in expl3 break pkgloader.sty

[Caraffini Diego]

Package: texlive-latex-extra
Version: 2017.20170818-1
Severity: important

Dear Maintainer,

Today, I tried to recompile  a file that uses pkgloader.sty after some time.

pdflatex outputs the message:

LaTeX error: "kernel/non-base-function"

After some investigation I found out that a change in how expl3 macro
\cs_new:Nn works, has turned a previously working line to an error.
(see: https://www.tug.org/pipermail/latex3-commits/2016-August/001050.html)

I submitted a patch (pending review) for pkgloader to the upstream repository:
https://github.com/mhelvens/latex-pkgloader/pull/11

minimal tex example:


\documentclass[12pt]{book}
\RequirePackage{pkgloader}
\LoadPackagesNow%
\begin{document}
\end{document}

Steps to reproduce:
1. save the example to file test.tex
2. run pdflatex
  pdflatex test
3. bugs from a different file may be triggered, 
  press return until the message:

  LaTeX error: "kernel/non-base-function"
is displayed.

Expected result:
there sould be no message about non-base-function.


Best regards
Diego

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2857 Sep 18 18:08 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Aug 17 01:38 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 17 22:46 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 17 22:46 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 23 14:59 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 17 22:46 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 17 22:46 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5068 Sep 18 18:07 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 16  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 23 14:59 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-1
ii  tex-common 6.09
ii  texlive-base   2017.20170818-1
ii  texlive-binaries   2017.20170613.44572-6
ii  texlive-latex-recommended  2017.20170818-1
ii  texlive-pictures   2017.20170818-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2017.20170818-1
ii  texlive-latex-extra-doc2017.20170818-1
ii  texlive-plain-generic  2017.20170818-1

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.21-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.2.0+dfsg-1

Versions of packages 

Bug#876322: ITP: nov-el -- Emacs mode for viewing EPUB files

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: nov-el
  Version : 0.2.0
  Upstream Author : Vasilij Schneidermann 
* URL : https://github.com/wasamasa/nov.el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : Emacs mode for viewing EPUB files

I intend to maintain this under the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#872847: fritzing: fails to bulid against libgit2 0.26.0

[peter green]

It appears that git_remote_connect has added a new parameter called "proxy" of 
type git_proxy_options in the second to last position.

Unfortunately the documentation seems to be very thin on the ground. In 
particular it says nothing about whether this new parameter can simply be set 
to NULL or if it needs some other kind of handling. So I went digging in the 
libgit2 source.

git_remote_connect seems to do some kind of version check on the proxy options if 
they are not null which suggests that they can be NULL. it then passes them off to 
t->connect.

Afaict for the standard transports t->connect will point to git_smart__connect 
which passes the proxy options to git_proxy_options_dup and fails if 
git_proxy_options_dup fails.

And it appears that git_proxy_options_dup succeeds if the source is NULL 
filling in a default set of proxy options.

So it looks like it is safe to set the "proxy" parameter to NULL.

ccing the libgit2 maintainers so they can check my analysis and preferablly get 
some statements on this added to the documentation.

I have tested that setting the new parameter to NULL makes the package build. I 
have not tested it beyond that. I have uploaded the change to raspbian.

No immediate intent to NMU in Debian but if I get positive feedback on the 
patch I may do so later.

diff -Nru fritzing-0.9.3b+dfsg/debian/changelog 
fritzing-0.9.3b+dfsg/debian/changelog
--- fritzing-0.9.3b+dfsg/debian/changelog   2017-01-23 16:27:29.0 
+
+++ fritzing-0.9.3b+dfsg/debian/changelog   2017-09-21 02:21:45.0 
+
@@ -1,3 +1,10 @@
+fritzing (0.9.3b+dfsg-4+rpi1) buster-staging; urgency=medium
+
+  * Set new "proxy" parameter in git_remote_connect to NULL (Closes: 872847)
+  * Bump libgit2 build-dependency to >= 0.25 due to above patch.
+
+ -- Peter Michael Green   Thu, 21 Sep 2017 02:21:45 
+
+
 fritzing (0.9.3b+dfsg-4) unstable; urgency=medium
 
   * created a shell script to launch fritzing with a special pwd.
diff -Nru fritzing-0.9.3b+dfsg/debian/control 
fritzing-0.9.3b+dfsg/debian/control
--- fritzing-0.9.3b+dfsg/debian/control 2016-11-01 12:05:59.0 +
+++ fritzing-0.9.3b+dfsg/debian/control 2017-09-21 02:21:45.0 +
@@ -11,7 +11,7 @@
libqt5svg5-dev,
zlib1g-dev,
libboost-dev,
-   libgit2-dev (>= 0.24.1),
+   libgit2-dev (>= 0.25),
sqlite3
 Standards-Version: 3.9.8
 Vcs-Browser: https://bazaar.launchpad.net/~ehbello/fritzing/debian/changes
diff -Nru fritzing-0.9.3b+dfsg/debian/patches/add-proxy-parameter.diff 
fritzing-0.9.3b+dfsg/debian/patches/add-proxy-parameter.diff
--- fritzing-0.9.3b+dfsg/debian/patches/add-proxy-parameter.diff
1970-01-01 00:00:00.0 +
+++ fritzing-0.9.3b+dfsg/debian/patches/add-proxy-parameter.diff
2017-09-21 02:21:45.0 +
@@ -0,0 +1,14 @@
+Description:  Set new "proxy" parameter in git_remote_connect to NULL
+Author: Peter Michael Green 
+
+--- fritzing-0.9.3b+dfsg.orig/src/version/partschecker.cpp
 fritzing-0.9.3b+dfsg/src/version/partschecker.cpp
+@@ -123,7 +123,7 @@ bool PartsChecker::newPartsAvailable(con
+  */
+ git_strarray customheaders;
+ customheaders.count = 0;
+-error = git_remote_connect(remote, GIT_DIRECTION_FETCH, , 
);
++error = git_remote_connect(remote, GIT_DIRECTION_FETCH, ,NULL, 
);
+ if (error) {
+ partsCheckerResult.partsCheckerError = PARTS_CHECKER_ERROR_REMOTE;
+ partsCheckerResult.errorMessage = QObject::tr("Unable to access 
network site for '%1'. %2").arg(repoPath).arg(sBoilerPlate1);
diff -Nru fritzing-0.9.3b+dfsg/debian/patches/series 
fritzing-0.9.3b+dfsg/debian/patches/series
--- fritzing-0.9.3b+dfsg/debian/patches/series  2017-01-23 16:27:29.0 
+
+++ fritzing-0.9.3b+dfsg/debian/patches/series  2017-09-21 02:21:45.0 
+
@@ -4,3 +4,4 @@
 git-remote-connect.patch
 no-isystem-for-gcc6.patch
 fritzing.desktop.patch
+add-proxy-parameter.diff

Bug#876148: ust: FTBFS w/GCJ (on hppa)

[Aaron M. Ucko]

Michael Jeanson  writes:

> The ust java bindings won't build with gcj, however they are optional
> and not required for a normal use of ust. I'd like to just disable them
> on platforms that don't have an openjdk port, I added a 'nojava' [1]
> build profile [2] to the packaging code that could be used for that but
> I haven't found a way to have it auto-enabled for hppa builds.

Sounds good!  AFAICT, it *technically* works to add a conditional

  export DEB_BUILD_PROFILES += nojava

near the top of debian/rules.  However, that's kind of a hack, so I
suppose it would be better to specify !hppa alongside  in
debian/control[1] and have debian/rules consult a private variable
conditionalized on both the architecture and the profile:

  ifeq ($(filter nojava,$(DEB_BUILD_PROFILES))$(filter hppa,$(DEB_HOST_ARCH)),)
java_ok = 1
  endif

  ifeq ($(java_ok),1)
  # ...
  endif

Thanks!

[1] [!hppa]  in Build-Depends, Architecture: !hppa 
for the relevant binary packages.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#876321: game-data-packager: Space Quest 5 (gog) fails to build package, could not find 119.scr

[Charles L]

Package: game-data-packager
Version: 53
Severity: normal

Dear Maintainer,

Space Quest 5 fails to build from gog sources. It downloads a fresh copy from 
gog but something is amiss. 
I tested the same commands in a stretch VM which has version 49.1, and that was 
sucessful. Please let me
know if I can be of furthar assistance.



NFO:game_data_packager.build:spacequest5-en-data can be downloaded with 
lgogdownloader
Getting game names (1/1) 40 / 40
Getting game info 1 / 1
2017-Sep-20 19:44:30 [Thread #0] Begin download: setup_space_quest5_2.1.0.15.exe
2017-Sep-20 19:44:36 [Thread #0] Download complete: 
setup_space_quest5_2.1.0.15.exe (@ 4.94MB/s)
2017-Sep-20 19:44:36 [Thread #0] Finished all tasks
#0: Finished
identifying 
/tmp/gdptmp.fe17qb1t/space_quest_5_the_next_mutation/setup_space_quest5_2.1.0.15.exe
ERROR:game_data_packager.build:could not find 119.scr:
  expected:
size:   13036 bytes
md5:479163131da6d18adcf2960a993aa841
sha1:   None
sha256: None
ERROR:game_data_packager.build:Unable to complete any packages because 
downloads failed.


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

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

Versions of packages game-data-packager depends on:
ii  fakeroot1.22-1
ii  python3 3.5.3-3
ii  python3-debian  0.1.30
ii  python3-yaml3.12-1+b1

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  53

Versions of packages game-data-packager suggests:
pn  arj
ii  binutils   2.29.1-1
ii  cabextract 1.6-1+b1
ii  cdparanoia 3.10.2+debian-11+b2
pn  dynamite   
ii  gcc4:7.2.0-1d1
pn  gdebi | gdebi-kde  
ii  gir1.2-gdkpixbuf-2.0   2.36.10-1
ii  innoextract1.6-1+b2
pn  lgc-pg 
ii  lgogdownloader 3.2-1+b1
pn  lhasa | jlha-utils | lzh-archiver  
ii  make   4.1-9.1
ii  p7zip-full 16.02+dfsg-4
ii  steam  1.0.0.54-2
pn  steamcmd   
pn  unace-nonfree  
ii  unar   1.10.1-2
ii  unrar  1:5.5.8-1
pn  unshield   
ii  unzip  6.0-21
ii  vorbis-tools   1.4.0-10+b1
pn  xdelta 

-- no debconf information

Bug#876320: qgis: Fails to load /usr/lib/qgis/plugins/libgrass*7.so

[Nelson A. de Oliveira]

Package: qgis
Version: 2.14.19+dfsg-1~exp1
Severity: normal

Hi!

While loading QGIS it's possible to see in the log messages panel, in
the Plugins tab:

=
Failed to load /usr/lib/qgis/plugins/libgrassplugin7.so (Reason: Cannot load 
library /usr/lib/qgis/plugins/libgrassplugin7.so: (libgrass_gis.7.2.1.so: 
cannot open shared object file: No such file or directory))
Failed to load /usr/lib/qgis/plugins/libgrassprovider7.so (Reason: Cannot load 
library /usr/lib/qgis/plugins/libgrassprovider7.so: (libgrass_gis.7.2.1.so: 
cannot open shared object file: No such file or directory))
Failed to load /usr/lib/qgis/plugins/libgrassrasterprovider7.so (Reason: Cannot 
load library /usr/lib/qgis/plugins/libgrassrasterprovider7.so: 
(libgrass_gis.7.2.1.so: cannot open shared object file: No such file or 
directory))
=

It seems that something needs to be updated/recompiled for the new grass
version (7.2.2)?

Thank you!

Best regards,
Nelson

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

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

Versions of packages qgis-plugin-grass depends on:
ii  grass-core7.2.2-1
ii  libc6 2.24-17
ii  libexpat1 2.2.3-1
ii  libgcc1   1:7.2.0-5
ii  libgdal20 2.2.1+dfsg-2+b2
ii  libgeos-c1v5  3.5.1-3
ii  libproj12 4.9.3-2
ii  libqca2   2.1.3-1
ii  libqgis-analysis2.14.19   2.14.19+dfsg-1~exp1
ii  libqgis-app2.14.192.14.19+dfsg-1~exp1
ii  libqgis-core2.14.19   2.14.19+dfsg-1~exp1
ii  libqgis-gui2.14.192.14.19+dfsg-1~exp1
ii  libqgisgrass7-2.14.19 2.14.19+dfsg-1~exp1
ii  libqscintilla2-12v5   2.9.3+dfsg-5
ii  libqt4-network4:4.8.7+dfsg-11
ii  libqt4-sql4:4.8.7+dfsg-11
ii  libqt4-svg4:4.8.7+dfsg-11
ii  libqt4-xml4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libqtwebkit4  2.3.4.dfsg-9.1
ii  libqwt6abi1   6.1.2-6
ii  libspatialindex4v51.8.5-5
ii  libspatialite74.3.0a-5+b1
ii  libsqlite3-0  3.20.1-1
ii  libstdc++67.2.0-5
ii  qgis  2.14.19+dfsg-1~exp1
ii  qgis-plugin-grass-common  2.14.19+dfsg-1~exp1
ii  qgis-provider-grass   2.14.19+dfsg-1~exp1

qgis-plugin-grass recommends no packages.

qgis-plugin-grass suggests no packages.

-- debconf-show failed

Bug#684707: Acknowledgement (unattended-upgrades: Add a distro_release macro)

[Balint Reczey]

Control: fixed -1 0.80

Hi Russel,

On Wed, 15 Aug 2012 11:19:37 +1000 Russell Stuart
 wrote:
> On Tue, 2012-08-14 at 15:10 +0200, Michael Vogt wrote:
> > I removed this example for now and added codename based matching in
> > python-apt,unattended-upgrades in the debian-experimental bzr branch.
>
> Wow! Thanks. Looks like you've addressed all my wishes.

This seems to be fixed long time ago.

Cheers,
Balint

Bug#867988: nasm - fixed upstream

[Michał Mirosław]

These seem to be fixed in upstream:
https://bugzilla.nasm.us/show_bug.cgi?id=3392414
https://bugzilla.nasm.us/show_bug.cgi?id=3392415

Best Regards,
Michał Mirosław

Bug#875535: [Pkg-d-devel] Bug#875535: closed by Matthias Klumpp <m...@debian.org> (Re: Bug#875878: ldc 1.3 doesn't build any of it's reverse dependencies)

[Matthias Klumpp]

2017-09-20 5:28 GMT+02:00 Nobuhiro Iwamatsu :
> Hi,
>
> sambamba package has not fixed this problem with ldc 1:1.4.0-1.
> Also, I confirmed that diet-ng fixed this problem.

This is a different bug:
https://github.com/ldc-developers/ldc/issues/2300#issuecomment-330947562

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#876319: plasma-nm: Apply button doesn't become enabled when making changes to wired interfaces

[Rubin Abdi]

Package: plasma-nm
Version: 4:5.10.5-2
Severity: normal

Dear Exuberant Maintainer,

When making edits to an existing wired connection (built in ethernet,
USB, doesn't matter) the "Apply" button doesn't enabled itself (stays
grayed out). Clicking on "Ok" will not save changes.

If I go to an existing wifi connection, whatever edits I make will
enable the "Apply" button and save my changes when clicked.

I should note that the out loud remark I stated right before I hit this
bug was, "Wow, the network connections panel's gotten refreshed!" This
issue didn't exist with the old version of this panel.

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

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

Versions of packages plasma-nm depends on:
ii  kio 5.37.0-2
ii  libc6   2.24-17
ii  libkf5completion5   5.37.0-2
ii  libkf5configcore5   5.37.0-2
ii  libkf5configwidgets55.37.0-2
ii  libkf5coreaddons5   5.37.0-2
ii  libkf5dbusaddons5   5.37.0-2
ii  libkf5declarative5  5.37.0-2
ii  libkf5i18n5 5.37.0-2
ii  libkf5iconthemes5   5.37.0-2
ii  libkf5itemviews55.37.0-2
ii  libkf5kdelibs4support5  5.37.0-2
ii  libkf5kiowidgets5   5.37.0-2
ii  libkf5modemmanagerqt6   5.37.0-2
ii  libkf5networkmanagerqt6 5.37.0-2
ii  libkf5notifications55.37.0-2
ii  libkf5service-bin   5.37.0-2
ii  libkf5service5  5.37.0-2
ii  libkf5solid55.37.0-2
ii  libkf5wallet-bin5.37.0-2
ii  libkf5wallet5   5.37.0-2
ii  libkf5widgetsaddons55.37.0-2
ii  libkf5windowsystem5 5.37.0-2
ii  libkf5xmlgui5   5.37.0-2
ii  libopenconnect5 7.08-1
ii  libqca-qt5-22.1.3-1
ii  libqt5core5a5.9.1+dfsg-9
ii  libqt5dbus5 5.9.1+dfsg-9
ii  libqt5gui5  5.9.1+dfsg-9
ii  libqt5network5  5.9.1+dfsg-9
ii  libqt5qml5  5.9.1-6
ii  libqt5quick55.9.1-6
ii  libqt5widgets5  5.9.1+dfsg-9
ii  libqt5xml5  5.9.1+dfsg-9
ii  libstdc++6  7.2.0-5
ii  mobile-broadband-provider-info  20170903-1
ii  network-manager 1.8.2-1
ii  plasma-framework5.37.0-2
ii  qml-module-org-kde-kcoreaddons  5.37.0-2

plasma-nm recommends no packages.

Versions of packages plasma-nm suggests:
pn  network-manager-openconnect  
ii  network-manager-openvpn  1.2.8-2
ii  network-manager-pptp 1.2.4-2
ii  network-manager-vpnc 1.2.4-4

-- no debconf information

Bug#876100: fixed in nvidia-graphics-drivers 375.82-4

[Andreas Beckmann]

On 20.09.2017 20:39, Jiri Palecek wrote:

>>     * Prevent mixing libgl1-nvidia-glx with libgl1-nvidia-glvnd-glx.
>>     * Use versioned Provides/Breaks/Replaces on the packages also
>> built from
>>   src:libglvnd s.t. they cannot be satisfied by virtual packages
>> provided
>>   from src:mesa (<< 17).  (Closes: #875683, #876100)
> I don't understand. How does this solve issue 876100? The problem was
> that nvidia wasn't coinstallable with eg. libegl1-mesa-dev in its
> current version, and it is still so. Could you explain?


I just tried again in a minimal sid chroot and didn't encounter any problems:

# apt-get install --install-recommends nvidia-driver
[...]
(successfully installed)

# apt-get install libglvnd-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libglvnd-core-dev
The following NEW packages will be installed:
  libglvnd-core-dev libglvnd-dev
0 upgraded, 2 newly installed, 0 to remove and 10 not upgraded.
Need to get 0 B/16.3 kB of archives.
After this operation, 80.9 kB of additional disk space will be used.
Do you want to continue? [Y/n]  
[...]
(successfully installed)

# ls -lad $(dpkg -L libglvnd-dev)
ls: cannot access 'diverted': No such file or directory
ls: cannot access 'by': No such file or directory
ls: cannot access 'glx-diversions': No such file or directory
ls: cannot access 'to:': No such file or directory
ls: cannot access 'diverted': No such file or directory
ls: cannot access 'by': No such file or directory
ls: cannot access 'glx-diversions': No such file or directory
ls: cannot access 'to:': No such file or directory
ls: cannot access 'diverted': No such file or directory
ls: cannot access 'by': No such file or directory
ls: cannot access 'glx-diversions': No such file or directory
ls: cannot access 'to:': No such file or directory
drwxr-xr-x  22 root root  440 Sep 20 22:51 /.
drwxr-xr-x  10 root root  200 Mar 25  2013 /usr
drwxr-xr-x  40 root root  880 Sep 20 22:54 /usr/lib
lrwxrwxrwx   1 root root   15 Sep 12 07:32 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so -> libEGL.so.1.0.0
lrwxrwxrwx   1 root root   14 Sep 12 07:32 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root   18 Sep 12 07:32 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2.0.0
drwxr-xr-x  26 root root 9300 Sep 20 22:56 /usr/lib/x86_64-linux-gnu
lrwxrwxrwx   1 root root   49 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libEGL.so 
-> /etc/alternatives/glx--libEGL.so-x86_64-linux-gnu
lrwxrwxrwx   1 root root   48 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libGL.so 
-> /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
lrwxrwxrwx   1 root root   52 Sep 20 22:56 
/usr/lib/x86_64-linux-gnu/libGLESv2.so -> 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu
lrwxrwxrwx   1 root root   15 Sep 12 07:32 /usr/lib/x86_64-linux-gnu/libGLX.so 
-> libGLX.so.0.0.0
lrwxrwxrwx   1 root root   22 Sep 12 07:32 
/usr/lib/x86_64-linux-gnu/libGLdispatch.so -> libGLdispatch.so.0.0.0
lrwxrwxrwx   1 root root   18 Sep 12 07:32 
/usr/lib/x86_64-linux-gnu/libOpenGL.so -> libOpenGL.so.0.0.0
drwxr-xr-x  79 root root 1580 Sep 20 22:54 /usr/share
drwxr-xr-x 397 root root 8640 Sep 20 22:56 /usr/share/doc
drwxr-xr-x   2 root root   80 Sep 20 22:56 /usr/share/doc/libglvnd-dev
-rw-r--r--   1 root root  914 Sep 12 07:32 
/usr/share/doc/libglvnd-dev/changelog.Debian.gz
-rw-r--r--   1 root root 4697 Sep 12 07:32 /usr/share/doc/libglvnd-dev/copyright

# apt-get install libegl1-mesa-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libdrm-dev libpthread-stubs0-dev libwayland-bin libwayland-dev libx11-dev 
libx11-xcb-dev libxau-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev 
libxcb-present-dev libxcb-randr0 libxcb-randr0-dev libxcb-render0-dev
  libxcb-shape0 libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev 
libxcb1-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev 
libxshmfence-dev libxxf86vm-dev x11proto-core-dev x11proto-damage-dev 
x11proto-dri2-dev
  x11proto-fixes-dev x11proto-gl-dev x11proto-input-dev x11proto-kb-dev 
x11proto-xext-dev x11proto-xf86vidmode-dev xorg-sgml-doctools xtrans-dev
Suggested packages:
  libxcb-doc libxext-doc
Recommended packages:
  libx11-doc
The following NEW packages will be installed:
  libdrm-dev libegl1-mesa-dev libpthread-stubs0-dev libwayland-bin 
libwayland-dev libx11-dev libx11-xcb-dev libxau-dev libxcb-dri2-0-dev 
libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0 
libxcb-randr0-dev
  libxcb-render0-dev libxcb-shape0 libxcb-shape0-dev libxcb-sync-dev 
libxcb-xfixes0-dev libxcb1-dev libxdamage-dev libxdmcp-dev libxext-dev 
libxfixes-dev libxshmfence-dev libxxf86vm-dev x11proto-core-dev 
x11proto-damage-dev
  x11proto-dri2-dev x11proto-fixes-dev x11proto-gl-dev x11proto-input-dev 
x11proto-kb-dev 

Bug#876318: kexec-tools: fails to parse kcore on 4.1.2.0

[Dominique Martinet]

Package: kexec-tools
Version: 1:2.0.14-1
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
Tying to load a kexec kernel fails with this kind of errors:

Starting kdump-tools:
Unknown type (Reserved) while parsing /sys/firmware/memmap/5/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/1/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/6/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/4/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/2/type. Please 
report this as bug. Using RANGE_RESERVED now.
ELF core (kcore) parse failed
Cannot load /var/lib/kdump/vmlinuz
failed to load kdump kernel ... failed!
failed to load kdump kernel

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

Upgrading to 2.0.15 fixes the issue upstream.

(fwiw, ubuntu appears to have done a similar upgrade recently as well,
here:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5245110.html
)


-- System Information:
Distributor ID: PureOS
Description:PureOS GNU/Linux 8
Release:8
Codename:   green
Architecture: x86_64

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

Versions of packages kexec-tools depends on:
ii  debconf   1.5.63
ii  libc6 2.24-17
ii  lsb-base  9.20161125
ii  zlib1g1:1.2.8.dfsg-5

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information excluded

Bug#863734: unblock: gnupg2/2.1.18-8

[Adam D. Barratt]

On Thu, 2017-09-21 at 00:24 +0200, Georg Faerber wrote:
> On 17-07-15 23:29:09, Cyril Brulebois wrote:
> > Adam D. Barratt  (2017-07-13):
> > > Finally, unless I missed one when checking back through the
> > > thread, we
> > > also need a d-i ack.
> > 
> > From a few quick tests, spotted no issues in d-i.
> 
> So...any chance of getting this into 9.2?
> 

Well, my original mail a couple of months ago asked for things other
than the d-i ack, which is why the above quote starts "finally", and
there doesn't appear to have been any response to those points. You
didn't send your mail to the person who can actually provide them. I've
fixed the latter point by adding a CC.

To save digging them out:


I'm assuming that there haven't been any relevant regressions or
follow-up fixes since the -8 upload?

In any case, we can't simply transplant -8 to p-u, so would need to see
a debdiff for either a -6+deb9u1 or -8~deb9u1 upload (depending on how
you structure the changelog), built against and tested on stretch,
before confirming an upload.


Regards,

Adam

Bug#876316: file: buggy magic: mistakes many things (including .gz) as "DOS/MBR boot sector"

[Ximin Luo]

Control: forcemerge -1 849782 849783
Control: retitle -1 buggy magic: mistakes many things (including .gz, .apk) as 
"DOS/MBR boot sector" since 2012-2013 "filesystem improvements"

Ximin Luo:
> [..]
> 
> I git cloned https://github.com/file/file and ran my tests:
> 
> [..]
> $ git bisect run sh -c 'git clean -fdx && git reset --hard && autoreconf -i 
> && ./configure && make && src/file -m magic/magic:magic/magic.mgc 
> ../control.tar.gz | grep -i gzip; x=$?; git reset --hard; git clean -fdx; 
> exit $x'
> [..]
> 51ceb2bd7a728fb307f190ee68fe53cd0392fb28 is the first bad commit
> commit 51ceb2bd7a728fb307f190ee68fe53cd0392fb28
> Author: Christos Zoulas 
> Date:   Fri Oct 12 16:10:39 2012 +
> 
> from Joerg Jenderek
> Hi,
> 2 files (TDSK-5120x32b.img and TDSK-5120x64b.img ) in directory bootsector
> are characterized wrong ( see output bootsector-5.11.txt) .
> [..]
> :04 04 b0a083f5b8453b812de42749e612aff7673b42f3 
> ef0015db2bdd886d15d6993c66d6562fed5572e6 Mmagic
> bisect run success
> 

Repeating this process for Hans' APK example:

https://people.debian.org/~infinity0/repro/Zom-15.1.0-alpha-5-zomrelease-release-unsigned.apk

git bisect gives us a different commit:

3989f2e0a063c6a1ab58ebb34f34f12adc45efd4 is the first bad commit
commit 3989f2e0a063c6a1ab58ebb34f34f12adc45efd4
Author: Christos Zoulas 
Date:   Thu Mar 14 01:38:30 2013 +

filesystems detail patch from joerg jenderek

:04 04 775d171259ca46632f42ddb923fca2fb4de26499 
0c62e47e47b692e100d61b015015421e5e27829e M  magic
bisect run success

But it's from the same person and in the same topic ("improving" detection of 
filesystems).

X

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

Bug#876317: ruby-moneta: build-depends on default-mysql-server but relies on mariadb interfaces

[Steve Langasek]

Package: ruby-moneta
Version: 1.0.0-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear maintainer,

Recent versions of ruby-moneta have been failing to build in Ubuntu because
you have switched the build-depency of the package from mysql-server to
default-mysql-server and at the same time have begun using mariadb-specific
interfaces:

RUBYLIB=/<>/debian/ruby-moneta/usr/lib/ruby/vendor_ruby:. 
GEM_PATH=debian/ruby-moneta/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 debian/ruby-tests.rb
mysql_install_db: [ERROR] unknown option '--rpm'
2017-09-09 09:53:02 [ERROR]   Unrecognized options
Unable to start the test MySQL server.
ERROR: Test "ruby2.3" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-moneta returned 
exit code 1
debian/rules:15: recipe for target 'binary' failed

  https://launchpad.net/ubuntu/+source/ruby-moneta/1.0.0-1/+build/13271049

This failure happens because Ubuntu's default-mysql-server is mysql, not
mariadb, and mysql does not implement this '--rpm' option.

default-mysql-server is only a reasonable build dependency if you don't care
about which implementation you have.  Since ruby-moneta depends on
interfaces that are only available from the mysql-server package, you should
build-depend on mysql-server directly.

With the attached patch, ruby-moneta builds successfully in Ubuntu.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-moneta-1.0.0/debian/control ruby-moneta-1.0.0/debian/control
--- ruby-moneta-1.0.0/debian/control2017-08-19 07:56:07.0 -0700
+++ ruby-moneta-1.0.0/debian/control2017-09-20 15:03:36.0 -0700
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 10~),
gem2deb
 Build-Depends-Indep: lsof,
- default-mysql-server,
+ mariadb-server,
  netcat,
  ruby-activesupport (>= 2:3.2.11~),
  ruby-fog,

Bug#863734: unblock: gnupg2/2.1.18-8

[Georg Faerber]

On 17-07-15 23:29:09, Cyril Brulebois wrote:
> Adam D. Barratt  (2017-07-13):
> > Finally, unless I missed one when checking back through the thread, we
> > also need a d-i ack.
> 
> From a few quick tests, spotted no issues in d-i.

So...any chance of getting this into 9.2?

Thanks & cheers,
Georg


signature.asc
Description: Digital signature

Bug#875282: diffoscope: AttributeError: 'NoneType' object has no attribute 'get_member'

[Ximin Luo]

Mattia Rizzolo:
> [..]
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 
> 102, in control
> control_file = 
> self.as_container.control_tar.as_container.lookup_file('./control')
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 
> 78, in control_tar
> return specialize(member.as_container.get_member('content'))
> AttributeError: 'NoneType' object has no attribute 'get_member'
> 

This is caused by #876316, file misdetects control.tar.gz as "DOS/MBR boot 
sector". The rest of deb.py assumes that the detection always succeeds 
correctly and does stuff like ".get_member" without checking whether it failed.

In the meantime I'll see if I can get diffoscope to work around this somehow.

X

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

Bug#876316: file: buggy magic: mistakes many things (including .gz) as "DOS/MBR boot sector", caused by commit 51ceb2bd7a728fb307f190ee68fe53cd0392fb28

[Ximin Luo]

Ximin Luo:
> [..] One example is attached.
> 

Whoops, here it is attached for real.

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


control.tar.gz
Description: application/gzip

Bug#871441: apparmor: Including tunables/sys to tunables/global?

[John Johansen]

On 09/20/2017 07:32 AM, intrigeri wrote:
> Control: tag -1 + upstream
> 
> Hi,
> 
> Vincent Blut:
>> /etc/apparmor.d/tunables/proc being part of
>> /etc/apparmor.d/tunables/global, I’m wondering if there are any reasons
>> preventing the sysfs pseudo file system location variable (defined in
>> /etc/apparmor.d/tunables/sys) from being included as well?
> 
> Good question! I have no idea.
> 
> I see that tunables/sys was introduced in 2012 by John (Cc'ed) as part
> of a commit that adds "abstractions to support the apparmor api".
> On my system, nothing uses these abstractions nor the @{sys} tunable.
> So I admit I have no idea what problem @{sys} is meant to solve.
> If it _is_ useful then it should be used everywhere instead of /sys/,
> which requires quite some work for no obvious (to me) benefit.
> 
> John, what do you think?
> 
yeah, I think it would be worth starting to do the conversion of
/sys/ to @{sys} as has been done with /proc/ to @{proc}

with that said I haven't ever seen sys mounted somewhere different
than /sys/ where I have seen that for proc.

The big win of course is when fstype conditionals land at which
point @{sys} could be further restricted to be /sys/ with and
fs type of sysfs or even allowing disconnected access to sysfs.

As for why this was introduced as part of the api abstraction
profile management is done through sys and you probably haven't
seen it because its not currently common to confine services
doing profile management.

I expect that will change more in the future as we open up policy
namespaces more, which will safely allow users and applications
to load their own policy.

Bug#876316: file: buggy magic: mistakes many things (including .gz) as "DOS/MBR boot sector", caused by commit 51ceb2bd7a728fb307f190ee68fe53cd0392fb28

[Ximin Luo]

Package: file
Version: 1:5.32-1
Severity: important
Tags: upstream
Control: affects -1 diffoscope

Dear Maintainer,

(I would have filed this upstream but their bug tracker was down.)

In developing diffoscope we've come across many cases of file(1) misdetecting
other things as DOS/MBR boot sector. I've been dismissing these as corner cases
but now there are just too many to ignore. One example is attached.

$ file control.tar.gz 
control.tar.gz: DOS/MBR boot sector; partition 1 : ID=0xd8, [..]

I git cloned https://github.com/file/file and ran my tests:

| (master)$ git clean -fdx && git reset --hard && autoreconf -i && ./configure 
&& make && src/file -m magic/magic:magic/magic.mgc ../control.tar.gz
| [..]
| ../control.tar.gz: DOS/MBR boot sector; partition 1 : [..]

After some experimenting I found a good commit:

| $ git checkout FILE5_00
| $ git clean -fdx && git reset --hard && autoreconf -i && ./configure && make 
&& src/file -m magic/magic:magic/magic.mgc ../control.tar.gz
| [..]
| ../control.tar.gz: gzip compressed data, from Unix, max compression

So we have a good and a bad revision, let's run a git-bisect then.

$ git bisect start
$ git bisect good FILE5_00
$ git bisect bad origin/master 
$ git bisect run sh -c 'git clean -fdx && git reset --hard && autoreconf -i && 
./configure && make && src/file -m magic/magic:magic/magic.mgc 
../control.tar.gz | grep -i gzip; x=$?; git reset --hard; git clean -fdx; exit 
$x'
[..]
51ceb2bd7a728fb307f190ee68fe53cd0392fb28 is the first bad commit
commit 51ceb2bd7a728fb307f190ee68fe53cd0392fb28
Author: Christos Zoulas 
Date:   Fri Oct 12 16:10:39 2012 +

from Joerg Jenderek
Hi,
2 files (TDSK-5120x32b.img and TDSK-5120x64b.img ) in directory bootsector
are characterized wrong ( see output bootsector-5.11.txt) .
[..]
:04 04 b0a083f5b8453b812de42749e612aff7673b42f3 
ef0015db2bdd886d15d6993c66d6562fed5572e6 M  magic
bisect run success

X

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

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

Versions of packages file depends on:
ii  libc6  2.24-17
ii  libmagic1  1:5.32-1
ii  zlib1g 1:1.2.8.dfsg-5

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#874529: And here is the commit that fixes it.

[Eliot Blennerhassett]

https://github.com/GNOME/gdm/commit/60447f2016cd873b0a62a5885687d7b3a8538d11#diff-daf9735fd40f92ad94e330eeab3c99a7

Bug#874529: Additional logs and dbus transaction.

[Eliot Blennerhassett]

I don't think this is Mate-specific.  I'm seeing it with regular Gnome
desktop.

This issue discusses the same problem.
https://github.com/linuxmint/cinnamon-screensaver/issues/221

The seat name, which should be "seat0" is "seat0allow-timed-login"
I have spent a couple of hours trawling through source code (online),
but haven't reached a conclusion.

I recorded this information when the problem occurs.

>From journal:
Sep 20 16:36:18 eliot gdm-launch-environment][5815]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by eliot(uid=0)
Sep 20 16:36:18 eliot gdm-launch-environment][5815]:
pam_systemd(gdm-launch-environment:session): Failed to create session:
No seat 'seat0allow-time

>From dbus-monitor:

method call time=1505903552.055414 sender=:1.2159 ->
destination=org.freedesktop.login1 serial=2
path=/org/freedesktop/login1; interface=org.freedes
ktop.login1.Manager; member=CreateSession
   uint32 120
   uint32 26182
   string "gdm-launch-environment"
   string "x11"
   string "greeter"
   string ""
   string "seat0allow-timed-login"
   uint32 0
   string "/dev/tty2"
   string ""
   boolean false
   string ""
   string ""
   array [
   ]
method call time=1505903552.055571 sender=:1.2 ->
destination=org.freedesktop.DBus serial=11645
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=GetConnectionUnixUser
   string ":1.2159"
method return time=1505903552.055612 sender=org.freedesktop.DBus ->
destination=:1.2 serial=4321 reply_serial=11645
   uint32 0
error time=1505903552.055699 sender=:1.2 -> destination=:1.2159
error_name=org.freedesktop.login1.NoSuchSeat reply_serial=2
   string "No seat 'seat0allow-timed-login' known"

Bug#876274: wordpress: 9 security bugs in wordpress 4.8.1 and earlier

[Craig Small]

On Thu, 21 Sep. 2017, 07:15 Salvatore Bonaccorso  wrote:

> Are you going to request CVEs for those?
>
> have you identified already the issue -> fixing commit mappings?
>
Hi Salvatore,

Already started talking with Kurt from DWF about the CVE. I am hoping there
will be a new improved setup for the next round of bugs.

Not started the mappings yet but it's on my list. The WPvuln guy has mapped
only the first SQLi.

  - Craig
-- 
Craig Small https://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#870819: gdisk: New upstream version 1.0.3 available

[Guillaume Delacour]

Hi,

On Sat, 5 Aug 2017 16:12:54 +0200 Christoph Biedl
 wrote:
> Package: gdisk
> Version: 1.0.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> upstream released a new version recently. Looking into the changes I
> found the following:
> 
> | Fixed a major bug that caused invalid partition tables to be generated
> | under some conditions.
> 
> In my humble opinion this justifies a swift upload of the new version.
> There are also some interesting changes listed for 1.0.2

I've prepared a new version on mentors and have such bug reports against
upstream code to changes/discuss. I've asked upstream some help to
triage them.

If no news received in the next few days, i'll try to contact my sponsor
to upload the new upstream release "as is".

> 
> Christoph
> 

-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#876315: CVE-2017-14339

[Moritz Muehlenhoff]

Source: yadifa
Severity: grave
Tags: security

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14339

Cheers,
Moritz

Bug#876274: wordpress: 9 security bugs in wordpress 4.8.1 and earlier

[Salvatore Bonaccorso]

Hi Craig,

On Wed, Sep 20, 2017 at 10:20:16PM +1000, Craig Small wrote:
> Source: wordpress
> Version: 4.8.1+dfsg-1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Wordpress 4.8.2 is out which fixes 9 security issues[1]

Are you going to request CVEs for those?

have you identified already the issue -> fixing commit mappings?

Regards,
Salvatore

Bug#702963: gdisk doesn't align the end of partition

[Guillaume Delacour]

Hi,

On Wed, 13 Mar 2013 17:11:32 +0400 sergio  wrote:
> Package: gdisk
> Version: 0.8.5-1
> Severity: important
> 
> gdisk doesn't align the end of partition:
> 
> 
> % dd if=/dev/zero of=test count=22
> % /sbin/gdisk test
> 
> Command (? for help): o
> This option deletes all partitions and creates a new protective MBR.
> Proceed? (Y/N): Y
> 
> Command (? for help): n
> Partition number (1-128, default 1): 
> First sector (34-199968, default = 2048) or {+-}size{KMGTP}: 
> Last sector (2048-199968, default = 199968) or {+-}size{KMGTP}: 
> 
> 

Sorry for my very late answer. Did you reproduce that on Debian 9
Stretch with release 1.0.1 ? Upstream has made many improvements in this
release.

-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#778325: sgdisk --new changes given end sector parameter when using a unit for the start sector

[Guillaume Delacour]

Hi,

On Fri, 13 Feb 2015 15:31:32 + Fabian Niepelt
 wrote:
[...]
>
> I'm on Debian 7.0, amd64.
> 

Sorry for the lack of answer. Do you have the same problem on Debian
Stretch with version 1.0.1 ?

-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#876033: primusrun doesn't find libGL.so.1

[Luigi Curzi]

Hi,

On Wed, 20 Sep 2017 11:40:29 +0100 Luca Boccassi  wrote:
> On Sun, 2017-09-17 at 18:17 +0200, Luigi wrote:
> > Package: primus
> > Version: 0~20150328-4
> > Severity: grave
> > Justification: renders package unusable
> >
> > i installed primus, bumblebee and bumblebee-nvidia; i launched
> > primusrun but i obtained this output:
> > $ primusrun glxgears -info
> > /usr/bin/primusrun: riga 41: attenzione: command substitution:
> > ignored null byte in input
> > primus: fatal: failed to load any of the libraries: /usr/lib/x86_64-
> > linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-
> > gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> > /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared
> > object file: No such file or directory
> > /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object
> > file: No such file or directory
> > /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such
> > file or directory
> >
> > In my system libGL.so.1 is located in these directories:
> > ~$ locate libGL.so.1
> > /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
> > /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
> > /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.0.0
> > /usr/lib/x86_64-linux-gnu/libGL.so.1
> > /usr/lib/x86_64-linux-gnu/primus/libGL.so.1
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (990, 'unstable'), (50, 'experimental')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> > LANGUAGE= (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages primus depends on:
> > ii  bumblebee  3.2.1-16
> > ii  primus-libs0~20150328-4
> > ii  socat  1.7.3.2-1
> > ii  xserver-xorg-core  2:1.19.3-2
> >
> > Versions of packages primus recommends:
> > pn  primus-libs-ia32  
> >
> > primus suggests no packages.
> >
> > -- no debconf information
>
> Hi,
>
> Could you please try again with nvidia-driver 375.82-4 that was just
> uploaded to unstable? There are some fixes w.r.t. compatibility with
> mesa+glvnd

i tried, but it didn't work; i got same error.

Bug#876033: primusrun doesn't find libGL.so.1

[Luigi Curzi]

On Wed, 20 Sep 2017 01:10:56 +0200 Bernd Vaske  wrote:
Hello,

> the problem comes from the transition of mesa to glvnd.
> A workaround is to link the missing libs from
>
> /usr/lib/x86_64-linux-gnu/libGL.so.1 to
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
> and
> /usr/lib/i386-linux-gnu/libGL.so.1 to
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
>
> That will result in primusrun starting again but most likely resulting
> in a black window for the application which is started.
>
> To get primusrun to work properly you have to start it with
> __GLVND_DISALLOW_PATCHING=1
>
> example:
>
> __GLVND_DISALLOW_PATCHING=1 primusrun glxgears
>

this solution works.
Thank you.

Bug#876314: stretch-pu: package trace-cmd/2.6-0.1+b1

[Sebastian Andrzej Siewior]

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

trace-cmd in Stretch segfaults on certain traces in newer kernels. I
would prefer to update to 2.6.1 but that diff is isn't small [0].
I was able to locate one patch in 2.6.1 which handles the error
condition and so avoids the segfault. I propose this patch as a stable
update.

[0] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=867440;filename=trace-cmd-2.6.1-0.1-nmu.diff;msg=10
59 files changed, 4625 insertions(+), 1482 deletions(-)

Sebastian
diff -Nru trace-cmd-2.6/debian/changelog trace-cmd-2.6/debian/changelog
--- trace-cmd-2.6/debian/changelog  2016-07-17 12:40:56.0 +
+++ trace-cmd-2.6/debian/changelog  2017-09-20 19:51:23.0 +
@@ -1,3 +1,10 @@
+trace-cmd (2.6-0.1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix segfault while processing certain trace files (Closes: #867440).
+
+ -- Sebastian Andrzej Siewior   Wed, 20 Sep 2017 
21:51:23 +0200
+
 trace-cmd (2.6-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
trace-cmd-2.6/debian/patches/0002-tools-lib-traceevent-Add-checks-for-returned-EVENT_E.patch
 
trace-cmd-2.6/debian/patches/0002-tools-lib-traceevent-Add-checks-for-returned-EVENT_E.patch
--- 
trace-cmd-2.6/debian/patches/0002-tools-lib-traceevent-Add-checks-for-returned-EVENT_E.patch
1970-01-01 00:00:00.0 +
+++ 
trace-cmd-2.6/debian/patches/0002-tools-lib-traceevent-Add-checks-for-returned-EVENT_E.patch
2017-09-20 19:50:33.0 +
@@ -0,0 +1,64 @@
+From 02e85fa19d4aed68d6a3a0cd21b9d4ce1f55025a Mon Sep 17 00:00:00 2001
+From: Dean Nelson 
+Date: Thu, 20 Aug 2015 11:16:32 -0400
+Subject: [PATCH] tools lib traceevent: Add checks for returned EVENT_ERROR
+ type
+
+Running the following perf-stat command on an arm64 system produces the
+following result...
+
+  [root@aarch64 ~]# perf stat -e kmem:mm_page_alloc -a sleep 1
+Warning: [kmem:mm_page_alloc] function sizeof not defined
+Warning: Error: expected type 4 but read 0
+  Segmentation fault
+  [root@aarch64 ~]#
+
+The second warning was a result of the first warning not stopping
+processing after it detected the issue.
+
+That is, code that found the issue reported the first problem, but
+because it did not exit out of the functions smoothly, it caused the
+other warning to appear and not only that, it later caused the SIGSEGV.
+
+Signed-off-by: Dean Nelson 
+Reviewed-by: Steven Rostedt 
+Acked-by: Namhyung Kim 
+Cc: Jiri Olsa 
+Cc: Peter Zijlstra 
+Link: 
http://lkml.kernel.org/r/20150820151632.13927.13791.email-sent-by-dnelson@teal
+Signed-off-by: Arnaldo Carvalho de Melo 
+Signed-off-by: Steven Rostedt 
+---
+ event-parse.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/event-parse.c b/event-parse.c
+index e3b026a3d7fc..a4aed20f071c 100644
+--- a/event-parse.c
 b/event-parse.c
+@@ -1746,6 +1746,9 @@ process_cond(struct event_format *event, struct 
print_arg *top, char **tok)
+   type = process_arg(event, left, );
+ 
+  again:
++  if (type == EVENT_ERROR)
++  goto out_free;
++
+   /* Handle other operations in the arguments */
+   if (type == EVENT_OP && strcmp(token, ":") != 0) {
+   type = process_op(event, left, );
+@@ -2005,6 +2008,12 @@ process_op(struct event_format *event, struct print_arg 
*arg, char **tok)
+   goto out_warn_free;
+ 
+   type = process_arg_token(event, right, tok, type);
++  if (type == EVENT_ERROR) {
++  free_arg(right);
++  /* token was freed in process_arg_token() via *tok */
++  token = NULL;
++  goto out_free;
++  }
+ 
+   if (right->type == PRINT_OP &&
+   get_op_prio(arg->op.op) < get_op_prio(right->op.op)) {
+-- 
+2.14.1
+
diff -Nru trace-cmd-2.6/debian/patches/series 
trace-cmd-2.6/debian/patches/series
--- trace-cmd-2.6/debian/patches/series 2016-07-17 12:40:56.0 +
+++ trace-cmd-2.6/debian/patches/series 2017-09-20 19:51:11.0 +
@@ -1 +1,2 @@
 0001-trace-cmd-Use-python2.7-for-executable-name.patch
+0002-tools-lib-traceevent-Add-checks-for-returned-EVENT_E.patch

Bug#873872: font-manager FTBFS with vala 0.36

[Jeremy Bicha]

Dear maintainer,

I've prepared an NMU for font-manager (versioned as 0.7.3-1.1) to fix
this RC bug and uploaded it to DELAYED/9. Please feel free to tell me
if I should delay it longer.

https://bugs.debian.org/873872

Thanks,
Jeremy Bicha
From 985397017cda10c295ba951cac76c766a59639a0 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 20 Sep 2017 16:05:21 -0400
Subject: [PATCH 3/3] Finalize changelog

---
 debian/changelog | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9a034a4..975424a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+font-manager (0.7.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add add-ref-keyword.patch, fix-incompatible-types.patch:
+- Backport git patches to fix build with vala 0.36 (Closes: #873872)
+  * Update Vcs fields
+
+ -- Jeremy Bicha   Wed, 20 Sep 2017 16:05:07 -0400
+
 font-manager (0.7.3-1) unstable; urgency=medium
 
   * Imported Upstream version 0.7.3:
-- 
2.14.1

Bug#876313: jessie-pu: package dput/0.9.6.4+deb8u1

[Ansgar Burchardt]

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

[ X-Debbugs-Cc'ed dput maintainer ]

I prepared an update for dput to point security uploads to
ftp.security.upload.d.o instead of security-master.d.o, see
attached diff.

I'll skip on dput-ng as it fails to build from source in Jessie (tests
fail with "UnsupportedDistribution: Unsupported release precise";
probably easy to fix, but not motivated).

Ansgar
diff -Nru dput-0.9.6.4/debian/changelog dput-0.9.6.4+deb8u1/debian/changelog
--- dput-0.9.6.4/debian/changelog   2013-07-19 13:08:40.0 +0200
+++ dput-0.9.6.4+deb8u1/debian/changelog2017-09-20 21:32:45.0 
+0200
@@ -1,3 +1,10 @@
+dput (0.9.6.4+deb8u1) jessie; urgency=medium
+
+  * dput.cf: replace security-master.d.o with ftp.upload.security.d.o
+(Closes: #863348)
+
+ -- Ansgar Burchardt   Wed, 20 Sep 2017 21:32:45 +0200
+
 dput (0.9.6.4) unstable; urgency=low
 
   [ Salvatore Bonaccorso ]
diff -Nru dput-0.9.6.4/dput.cf dput-0.9.6.4+deb8u1/dput.cf
--- dput-0.9.6.4/dput.cf2013-07-19 11:54:33.0 +0200
+++ dput-0.9.6.4+deb8u1/dput.cf 2017-09-20 21:32:33.0 +0200
@@ -56,7 +56,7 @@
 # pre_upload_command   = /path/to/some/script
 
 [security-master]
-fqdn   = security-master.debian.org
+fqdn   = ftp.security.upload.debian.org
 method = ftp
 incoming   = /pub/SecurityUploadQueue
 login  = anonymous
@@ -66,7 +66,7 @@
 pre_upload_command = /usr/share/dput/helper/security-warning
 
 [security-master-unembargoed]
-fqdn   = security-master.debian.org
+fqdn   = ftp.security.upload.debian.org
 method = ftp
 incoming   = /pub/OpenSecurityUploadQueue
 login  = anonymous

Bug#857792: icedove-bidiui needs to become thunderbird-bidiui

[Carsten Schoenert]

Dear Maintainers of bidiui,

On Wed, Mar 15, 2017 at 12:44:20AM -0400, Jonathan Joseph Chiarella wrote:
> Package: icedove-bidiui
> Version: 0.9.7-1
> 
> Debian is returning to the upstream branding of Mozilla's Firefox and
> Thunderbird.
> 
> Most Thunderbird packages have been renamed from "icedove" to
> "thunderbird" (and from "iceowl" plugin to "lightning"), but one
> remaining package is icedove-bidiui, which needs to be renamed as
> "thunderbird-bidiui.

your package is referencing to Icedove within short and long
description. The package has also a Depends on icedove >= 2.0 which will
be unresolvable with a upload of thunderbird packages 1:52.5.0-1 as we
planning to remove the currently existing transitional packages starting
with this version in unstable/testing.
While writing this report the version in unstable/testing of thunderbird
is 1:52.3.0-4. Mozilla is planning to release Firefox (Thunderbird)
52.5.0 on 2017-11-14.

https://wiki.mozilla.org/RapidRelease/Calendar

Please rework the control file for src:bidiui to get the package still
available in testing.

I plan to raise the importance to important after preparing and pushing
Thunderbird 52.4.0 to unstable and to serious with 52.5.0.

Regards and Thanks
Carsten (on behalf of maintaining src:icedove)

Bug#876311: barbican: French debconf translation update

[Alban Vidal]

Package: barbican
Version: 1_3.0.0-3
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of barbican debconf templates to French.
# Copyright (C) 2013, 2017, French l10n team 

# This file is distributed under the same license as the BARBICAN package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: barbican 1_3.0.0-3\n"
"Report-Msgid-Bugs-To: barbi...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 12:10+\n"
"PO-Revision-Date: 2017-09-11 07:05+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../barbican-api.templates:2001
msgid "Register Barbican in the Keystone endpoint catalog?"
msgstr ""
"Voulez-vous enregistrer Barbican dans le catalogue de points d'accès "
"Keystone ?"

#. Type: boolean
#. Description
#: ../barbican-api.templates:2001
msgid ""
"Each OpenStack service (each API) should be registered in order to be "
"accessible. This is done using \"keystone service-create\" and \"keystone "
"endpoint-create\". This can be done automatically now."
msgstr ""
"Chaque service d'OpenStack (chaque API) doit être enregistré pour être "
"accessible. Cela peut être fait en utilisant « keystone service-create » et "
"« keystone endpoint-create ». Cela peut être fait automatiquement maintenant."

#. Type: boolean
#. Description
#: ../barbican-api.templates:2001
#| msgid ""
#| "Note that you will need to have an up and running Keystone server on "
#| "which to connect using the Keystone authentication token."
msgid ""
"Note that you will need to have an up and running Keystone server on which "
"to connect using a known admin project name, admin username and password. "
"The admin auth token is not used anymore."
msgstr ""
"Veuillez noter que vous aurez besoin d'un serveur Keystone fonctionnel sur "
"lequel vous pouvez vous connecter en utilisant un nom de projet connu "
"d'administrateur, le nom d'utilisateur de l'administrateur ainsi que son mot "
"de passe. Le jeton d'authentification d'administration n'est plus utilisé."

#. Type: string
#. Description
#: ../barbican-api.templates:3001
msgid "Keystone server IP address:"
msgstr "Adresse IP du serveur Keystone :"

#. Type: string
#. Description
#: ../barbican-api.templates:3001
msgid ""
"Please enter the IP address of the Keystone server, so that barbican-api can "
"contact Keystone to do the Barbican service and endpoint creation."
msgstr ""
"Veuillez indiquer l'adresse IP du serveur Keystone, pour que l'API de "
"Barbican puisse contacter Keystone pour établir le service Barbican et créer "
"un point d'accès."

#. Type: string
#. Description
#: ../barbican-api.templates:4001
#| msgid "Keystone authentication token:"
msgid "Keystone admin name:"
msgstr "Nom de l'administrateur Keystone :"

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: password
#. Description
#: ../barbican-api.templates:4001 ../barbican-api.templates:5001
#: ../barbican-api.templates:6001
msgid ""
"To register the service endpoint, this package needs to know the Admin "
"login, name, project name, and password to the Keystone server."
msgstr ""
"Pour enregistrer le service de point d'accès, ce paquet a besoin de "
"connaître le nom de connexion de l'administrateur, son nom, le nom du "
"projet, ainsi que le mot de passe du serveur Keystone."

#. Type: string
#. Description
#: ../barbican-api.templates:5001
msgid "Keystone admin project name:"
msgstr "Nom du projet administrateur Keystone :"

#. Type: password
#. Description
#: ../barbican-api.templates:6001
msgid "Keystone admin password:"
msgstr "Mot de passe administrateur Keystone :"

#. Type: string
#. Description
#: ../barbican-api.templates:7001
msgid "Barbican endpoint IP address:"
msgstr "Adresse IP du point d'accès Barbican :"

#. Type: string
#. Description
#: ../barbican-api.templates:7001
msgid "Please enter the IP address that will be used to contact Barbican."
msgstr ""
"Veuillez indiquer l'adresse IP qui sera utilisée pour contacter Barbican."

#. Type: string
#. Description
#: ../barbican-api.templates:7001
msgid ""
"This IP address should be accessible from the clients that will use this "
"service, so if you are installing a public cloud, this should be a public IP "
"address."
msgstr ""
"Cette adresse IP doit être accessible depuis les clients qui utiliseront ce "
"service, donc si vous installez un nuage public, elle devra être une adresse "
"IP publique."

#. Type: string
#. 

Bug#876312: sahara: French debconf translation update

[Alban Vidal]

Package: sahara
Version: 1_5.0.0-3
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of sahara debconf templates to french.
# Copyright (C) 2013, 2017, French l10n team 

# This file is distributed under the same license as the sahara package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: sahara 1_5.0.0-3\n"
"Report-Msgid-Bugs-To: sah...@packages.debian.org\n"
"POT-Creation-Date: 2016-04-05 11:12+0200\n"
"PO-Revision-Date: 2017-09-11 07:05+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../sahara-common.templates:2001
msgid "Set up a database for Sahara?"
msgstr "Voulez-vous installer une base de données pour Sahara ?"

#. Type: boolean
#. Description
#: ../sahara-common.templates:2001
msgid ""
"No database has been set up for Sahara to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Aucune base de données n’est configurée que Sahara puisse utiliser. Avant "
"de continuer, assurez-vous de disposer des informations suivantes :"

#. Type: boolean
#. Description
#: ../sahara-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" – le type de base de données que vous souhaitez utiliser ;\n"
" – le nom d'hôte du serveur de base de données (ce serveur doit accepter les "
"connexions TCP depuis cette machine) ;\n"
" – un nom d'utilisateur et un mot de passe pour accéder à cette base de "
"données."

#. Type: boolean
#. Description
#: ../sahara-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Si certains de ces prérequis sont manquants, ignorez cette option et "
"exécutez l'application avec la prise en charge de SQLite standard."

#. Type: boolean
#. Description
#: ../sahara-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"sahara-common\"."
msgstr ""
"Vous pouvez modifier ce réglage plus tard en lançant « dpkg-reconfigure -"
"plow sahara-common »."

#. Type: string
#. Description
#: ../sahara-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nom d'hôte du serveur d'authentification :"

#. Type: string
#. Description
#: ../sahara-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Veuillez indiquer le nom d'hôte de votre serveur d'authentification. En "
"général, c'est également le nom d'hôte de votre Service d'Identité "
"d'OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../sahara-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nom du projet (« tenant ») sur le serveur d'authentification :"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../sahara-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Veuillez indiquer le nom du projet (« tenant ») sur le serveur "
"d’authentification."

#. Type: string
#. Description
#: ../sahara-common.templates:5001
msgid "Authentication server username:"
msgstr "Nom d'utilisateur pour le serveur d'authentification :"

#. Type: string
#. Description
#: ../sahara-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Veuillez indiquer le nom d'utilisateur à utiliser sur le serveur "

Bug#876310: murano: French debconf translation update

[Alban Vidal]

Package: murano
Version: 1_3.0.0-6
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of murano debconf templates to French.
# Copyright (C) 2013, 2017, French l10n team 

# This file is distributed under the same license as the MURANO package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: murano 1_3.0.0-6\n"
"Report-Msgid-Bugs-To: mur...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:48+\n"
"PO-Revision-Date: 2017-09-11 07:05+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../murano-common.templates:2001
msgid "Set up a database for Murano?"
msgstr "Voulez-vous installer une base de données pour Murano ?"

#. Type: boolean
#. Description
#: ../murano-common.templates:2001
msgid ""
"No database has been set up for Murano to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Aucune base de données n’est configurée que Murano puisse utiliser. Avant de "
"continuer, assurez-vous de disposer des informations suivantes :"

#. Type: boolean
#. Description
#: ../murano-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" – le type de base de données que vous souhaitez utiliser ;\n"
" – le nom d'hôte du serveur de base de données (ce serveur doit accepter les "
"connexions TCP depuis cette machine) ;\n"
" – un nom d'utilisateur et un mot de passe pour accéder à cette base de "
"données."

#. Type: boolean
#. Description
#: ../murano-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Si certains de ces prérequis sont manquants, ignorez cette option et "
"exécutez l'application avec la prise en charge de SQLite standard."

#. Type: boolean
#. Description
#: ../murano-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"murano-common\"."
msgstr ""
"Vous pouvez modifier ce réglage plus tard en lançant « dpkg-reconfigure -"
"plow murano-common »."

#. Type: string
#. Description
#: ../murano-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nom d'hôte du serveur d'authentification :"

#. Type: string
#. Description
#: ../murano-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Veuillez indiquer le nom d'hôte de votre serveur d'authentification. En "
"général, c'est également le nom d'hôte de votre Service d'Identité "
"d'OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../murano-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nom du projet (« tenant ») sur le serveur d'authentification :"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../murano-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Veuillez indiquer le nom du projet (« tenant ») sur le serveur "
"d’authentification."

#. Type: string
#. Description
#: ../murano-common.templates:5001
msgid "Authentication server username:"
msgstr "Nom d'utilisateur pour le serveur d'authentification :"

#. Type: string
#. Description
#: ../murano-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Veuillez indiquer le nom d'utilisateur à utiliser sur le serveur "

Bug#876309: glare: French debconf translation update

[Alban Vidal]

Package: glare
Version: 0.1.0-3
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of glare debconf templates to French.
# Copyright (C) 2013, 2017, French l10n team 

# This file is distributed under the same license as the glare package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: glare 0_1.0-3\n"
"Report-Msgid-Bugs-To: gl...@packages.debian.org\n"
"POT-Creation-Date: 2016-09-30 16:26+0200\n"
"PO-Revision-Date: 2017-09-11 07:05+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid "Set up a database for Glare?"
msgstr "Voulez-vous installer une base de données pour Glare ?"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"No database has been set up for Glare to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Aucune base de données n’est configurée que Glare puisse utiliser. Avant "
"de continuer, assurez-vous de disposer des informations suivantes :"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" – le type de base de données que vous souhaitez utiliser ;\n"
" – le nom d'hôte du serveur de base de données (ce serveur doit accepter les "
"connexions TCP depuis cette machine) ;\n"
" – un nom d'utilisateur et un mot de passe pour accéder à cette base de "
"données."

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Si certains de ces prérequis sont manquants, ignorez cette option et "
"exécutez l'application avec la prise en charge de SQLite standard."

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"glare\"."
msgstr ""
"Vous pouvez modifier ce réglage plus tard en lançant « dpkg-reconfigure -"
"plow glare »."

#. Type: string
#. Description
#: ../glare-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nom d'hôte du serveur d'authentification :"

#. Type: string
#. Description
#: ../glare-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Veuillez indiquer le nom d'hôte de votre serveur d'authentification. En "
"général, c'est également le nom d'hôte de votre Service d'Identité "
"d'OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../glare-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nom du projet (« tenant ») sur le serveur d'authentification :"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../glare-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Veuillez indiquer le nom du projet (« tenant ») sur le serveur "
"d’authentification."

#. Type: string
#. Description
#: ../glare-common.templates:5001
msgid "Authentication server username:"
msgstr "Nom d'utilisateur pour le serveur d'authentification :"

#. Type: string
#. Description
#: ../glare-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Veuillez indiquer le nom d'utilisateur à utiliser sur le serveur "
"d'authentification."

#. Type: password
#. 

Bug#875881: linux: CVE-2017-1000251

[Julien Aubin]

On Sat, 16 Sep 2017 16:40:24 +0200 Julien Aubin 
wrote:
> 2017-09-15 21:03 GMT+02:00 Christoph Anton Mitterer :
>
> > On Fri, 2017-09-15 at 19:18 +0100, Ben Hutchings wrote:
> > > Probably less critical than you think, since we enable
> > > CONFIG_CC_STACKPROTECTOR.
> >
> > Well... yes, but it wouldn't be the first time in history, that such
> > defence could then also be circumvented in the next evolution of an
> > exploit :-)
> >
> > But of course you can lower the bug severity if you think this is
> > appropriate.
> >
> > Cheers
>
>
> Looks like such issue has been found, stack clash is back :
> https://security-tracker.debian.org/tracker/CVE-2017-1000379

Could you please backport the fix to stable ?

Thanks !

Bug#876148: ust: FTBFS w/GCJ (on hppa)

[Michael Jeanson]

On 2017-09-18 21:54, Aaron M. Ucko wrote:
> Source: ust
> Version: 2.9.1-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source
> User: debian-h...@lists.debian.org
> 
> Builds of ust with GCJ (to which default-jdk necessarily still boils
> down on hppa, admittedly not a release architecture) have been failing:
> 
>   CLASSPATH=.:./.${CLASSPATH:+":$CLASSPATH"} gcj -C -d . -source 1.6 -target 
> 1.6   org/lttng/ust/LTTngUst.java
>   gcj: error: 1.6: No such file or directory
>   gcj: error: 1.6: No such file or directory
>   gcj: error: unrecognized command line option '-source'; did you mean 
> '-fsource='?
>   gcj: error: unrecognized command line option '-target'; did you mean 
> '-ftarget='?
>   Makefile:510: recipe for target 'classnoinst.stamp' failed
>   make[4]: *** [classnoinst.stamp] Error 1
> 
> Could you please take a look?  If building with GCJ is infeasible,
> please specifically require OpenJDK so that autobuilders for GCJ-only
> architectures (i.e., hppa) don't bother trying to cover ust.
> 
> Thanks!
> 

Hi,

The ust java bindings won't build with gcj, however they are optional
and not required for a normal use of ust. I'd like to just disable them
on platforms that don't have an openjdk port, I added a 'nojava' [1]
build profile [2] to the packaging code that could be used for that but
I haven't found a way to have it auto-enabled for hppa builds.

Michael

[1]
https://github.com/debian-lttng/lttng-ust/commit/b72deebefe21f4b8f884502cc72e18752bb66ba6
[2] https://wiki.debian.org/BuildProfileSpec

Bug#876308: libxml2 FTBFS: rename: "Unknown option: vf"

[Helmut Grohne]

Source: libxml2
Version: 2.9.4+dfsg1-4
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

libxml2 fails to build from source in sid/amd64:

| make[2]: Leaving directory 
'/<>/libxml2-2.9.4+dfsg1/builddir/main/python2.7-dbg'
| prename -vf 's/(?>/libxml2-2.9.4+dfsg1'
| debian/rules:147: recipe for target 'binary-arch' failed
| make: *** [binary-arch] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
status 2

Helmut

Bug#860268: .desktop files can hide malware in Nautilus

[Phil Wyett]

On Wed, 2017-09-20 at 17:30 +, Donncha O'Cearbhaill wrote:
> Phil Wyett:
> > On Wed, 2017-09-13 at 15:32 +, Donncha O'Cearbhaill wrote:
> > > Phil Wyett:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Please note that the debdiff I provided was essentially a raw backport
> > > > > for
> > > > > testing and I thought it may have issues. It was never meant as a
> > > > > 'here it
> > > > > is,
> > > > > all done' patch ready for submission as a stable update.
> > > > > 
> > > > > I am a little busy at the moment, but if I can help here, I will.
> > > > > 
> 
> I have created a backport patch targeting Nautilus 3.22.3 which contains
> the cherry-picked translations for the new UI string.
> 
> It adds a line to the debian/control file to remove the pre-built .mo
> translation files which were included in the upstream source release. I
> also needed to add gettext as a build dependency. With this patch the
> .mo/.gmo files should be rebuilt with the new strings during the Debian
> package build.
> 
> I have tested the backported Nautlius package with Tails 3.1 which is
> based on Debian stable. The English and localised interface is displayed
> correctly.
> 
> Ideally this backport would be ready for Tails 3.2 which is schedule to
> be released early next week.
> 
> Please let me know if I need to make any further changes.
> 
> Regards,
> Donncha

Hi,

Sorry, been busy, so not had chance to get back to this.

Tested on English, German and French and all Ok.

Attached is updated debdiff, adding credit.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57Adiff -Nru nautilus-3.22.3/debian/changelog nautilus-3.22.3/debian/changelog
--- nautilus-3.22.3/debian/changelog	2017-03-09 02:39:58.0 +0100
+++ nautilus-3.22.3/debian/changelog	2017-09-13 22:22:40.0 +0200
@@ -1,3 +1,12 @@
+nautilus (3.22.3-1.1) stretch; urgency=high
+
+  * Non-maintainer upload.
+  * Backport desktop file trust patch from upstream. (Closes: #860268).
+- Initial patch by Phil Wyett 
+- Translations additions by Donncha O'Cearbhaill 
+
+ -- Phil Wyett   Fri, 01 Sep 2017 23:43:51 +0100
+
 nautilus (3.22.3-1) unstable; urgency=medium

   * New upstream release.
diff -Nru nautilus-3.22.3/debian/control nautilus-3.22.3/debian/control
--- nautilus-3.22.3/debian/control	2017-03-09 02:39:58.0 +0100
+++ nautilus-3.22.3/debian/control	2017-09-20 17:58:00.0 +0200
@@ -31,7 +31,8 @@
gobject-introspection (>= 0.9.12-4~),
libgirepository1.0-dev (>= 0.10.7-1~),
libglib2.0-doc,
-   libgtk-3-doc
+   libgtk-3-doc,
+   gettext
 Homepage: https://wiki.gnome.org/action/show/Apps/Nautilus
 Vcs-Browser: https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/nautilus/
 Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/nautilus/
diff -Nru nautilus-3.22.3/debian/control.in nautilus-3.22.3/debian/control.in
--- nautilus-3.22.3/debian/control.in	2016-12-10 02:59:53.0 +0100
+++ nautilus-3.22.3/debian/control.in	2017-09-20 14:52:48.0 +0200
@@ -27,7 +27,8 @@
gobject-introspection (>= 0.9.12-4~),
libgirepository1.0-dev (>= 0.10.7-1~),
libglib2.0-doc,
-   libgtk-3-doc
+   libgtk-3-doc,
+   gettext
 Homepage: https://wiki.gnome.org/action/show/Apps/Nautilus
 Vcs-Browser: https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/nautilus/
 Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/nautilus/
diff -Nru nautilus-3.22.3/debian/patches/desktop_file_trust.patch nautilus-3.22.3/debian/patches/desktop_file_trust.patch
--- nautilus-3.22.3/debian/patches/desktop_file_trust.patch	1970-01-01 01:00:00.0 +0100
+++ nautilus-3.22.3/debian/patches/desktop_file_trust.patch	2017-09-14 15:26:27.0 +0200
@@ -0,0 +1,943 @@
+From 1630f53481f445ada0a455e9979236d31a8d3bb0 Mon Sep 17 00:00:00 2001
+From: Carlos Soriano 
+Date: Mon, 6 Feb 2017 18:47:54 +0100
+Subject: mime-actions: use file metadata for trusting desktop files
+
+Currently we only trust desktop files that have the executable bit
+set, and don't replace the displayed icon or the displayed name until
+it's trusted, which prevents for running random programs by a malicious
+desktop file.
+
+However, the executable permission is preserved if the desktop file
+comes from a compressed file.
+
+To prevent this, add a metadata::trusted metadata to the file once the
+user acknowledges the file as trusted. This adds metadata to the file,
+which cannot be added unless it has access to the computer.
+
+Also remove the SHEBANG "trusted" content we were 

Bug#876307: RFP: libjs-jquery-fileupload -- file upload widget for jQuery

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: libjs-jquery-fileupload
  Version : v9.19.1
  Upstream Author : Sebastian Tschan
* URL : https://github.com/blueimp/jQuery-File-Upload
* License : MIT
  Programming Lang: JavaScript
  Description : file upload widget for jQuery

File Upload widget with multiple file selection, drag support,
progress bars, validation and preview images, audio and video for
jQuery. Supports cross-domain, chunked and resumable file uploads
and client-side image resizing. Works with any server-side platform
(PHP, Python, Ruby on Rails, Java, Node.js, Go etc.) that supports
standard HTML form file uploads.

Bug#876306: gnucash FTBFS: object class 'Transaction' has no property named 'bogus'

[Steve Langasek]

Package: gnucash
Version: 1:2.6.17-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Hi Dmitry,

The gnucash package has been failing to build in Ubuntu with a test failure,
and I have reproduced this failure in Debian unstable:

  /engine/Transaction/xaccTransScrubGainsDate_gains_dirty: **
ERROR:utest-Transaction.c:452:test_gnc_transaction_set_get_property: assertion 
failed (check1->hits == 1): (0 == 1)
 (gnc.engine) [xaccSplitEqualCheckBal] balances differ: 10/1000 vs 
20/1000
 (GLib-GObject) g_object_set_is_valid_property: object class 
'Transaction' has no property named 'bogus'
 (GLib-GObject) g_object_set_is_valid_property: object class 
'Transaction' has no property named 'bogus'
OK
  /engine/Transaction/gnc transaction set/get property:FAIL
GTester: last random seed: R02Sa8a1794f6622116b0a513984cbbbcc0f
Makefile:1926: recipe for target 'test-nonrecursive' failed
make[7]: *** [test-nonrecursive] Terminated

  https://launchpad.net/ubuntu/+source/gnucash/1:2.6.17-1/+build/13058180

This looks like a brittle test that has broken as a result of implementation
details in gobject; I don't see any reason why the gnucash test suite should
be testing the specific text of the error message returned by gobject when
performing a disallowed operation.  The gnucash implementation never relies
on the contents of this error string anywhere else, and it's not the
business of the gnucash testsuite to be testing the behavior of gobject
instead of its own.

So I think this particular test (or this aspect of the test) should be
dropped.  But in the meantime, here is a patch that fixes the test failure
on Debian and Ubuntu.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnucash-2.6.17/debian/patches/fix-test-for-gobject-messages.patch 
gnucash-2.6.17/debian/patches/fix-test-for-gobject-messages.patch
--- gnucash-2.6.17/debian/patches/fix-test-for-gobject-messages.patch   
1969-12-31 16:00:00.0 -0800
+++ gnucash-2.6.17/debian/patches/fix-test-for-gobject-messages.patch   
2017-09-20 11:43:37.0 -0700
@@ -0,0 +1,31 @@
+Description: fix test case to work with newer gobject
+ glib 2.54 changes the error string returned by a particular wrong call
+ to g_object_set().  gnucash's testsuite relies on matching the exact
+ text of this error string.  This is a wrong thing for the testsuite to do
+ - nothing in gnucash outside of the testsuite relies on this behavior, and
+ it's testing behavior of glib not of gnucash - but for the moment, here is
+ a patch that updates the expected string to match current glib.
+Author: Steve Langasek 
+
+Index: gnucash-2.6.17/src/engine/test/utest-Transaction.c
+===
+--- gnucash-2.6.17.orig/src/engine/test/utest-Transaction.c
 gnucash-2.6.17/src/engine/test/utest-Transaction.c
+@@ -412,7 +412,7 @@
+   "GNR", "", 240), *t_curr = NULL;
+ Timespec now = timespec_now (), *t_entered = NULL, *t_posted = NULL;
+ time_t secs = (time_t)now.tv_sec;
+-gchar *msg1 = "g_object_set_valist: object class " _Q "Transaction' has 
no property named " _Q "bogus'";
++gchar *msg1 = "g_object_set_is_valid_property: object class " _Q 
"Transaction' has no property named " _Q "bogus'";
+ gchar *msg2 = g_strdup_printf ("[xaccTransSetDateInternal] addr=%p set 
date to %" G_GUINT64_FORMAT ".%09ld %s",
+txn, now.tv_sec, now.tv_nsec, ctime 
());
+ GLogLevelFlags loglevel1 = G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL;
+@@ -453,7 +453,7 @@
+ g_assert_cmpint (check2->hits, ==, 2);
+ 
+ g_free (check1->msg);
+-check1->msg = g_strdup ("g_object_get_valist: object class " _Q 
"Transaction' has no property named " _Q "bogus'");
++check1->msg = g_strdup ("g_object_get_is_valid_property: object class " 
_Q "Transaction' has no property named " _Q "bogus'");
+ g_object_get (G_OBJECT (txn),
+   "num", _num,
+   "description", _desc,
diff -Nru gnucash-2.6.17/debian/patches/series 
gnucash-2.6.17/debian/patches/series
--- gnucash-2.6.17/debian/patches/series2016-12-21 13:24:42.0 
-0800
+++ gnucash-2.6.17/debian/patches/series2017-09-20 11:19:43.0 
-0700
@@ -1 +1,2 @@
 hardening-fortify.patch
+fix-test-for-gobject-messages.patch


signature.asc
Description: PGP signature

Bug#737796: may be use the newly proposed License-grant field

[tobi]

Am Dienstag, den 19.09.2017, 08:21 +0200 schrieb Dominique Dumont:
> On Monday, 18 September 2017 22:48:30 CEST you wrote:
> > I like this new feature and would be in favour making it real.
> 
> err, I'm not sure which new feature you refer to .. :-/
> 
> Do you mean the "support Files: paragraph with both abbreviated names
> and 
> license paragraph" or the new License-Grant field ?

License-Grant.

srry for the confusion.

> All the best

Bug#876305: polygen: FTBFS with ocaml 4.05.0

[Ralf Treinen]

Source: polygen
Version: 1.0.6.ds2-14
Severity: serious

polygen FTBFS with ocaml 4.05.0:

ocamlc -c -unsafe check.ml -o check.cmo
File "check.ml", line 40, characters 59-62:
Error: This expression has type elt -> Prelude.Prelude.symbol
   but an expression was expected of type elt -> elt
   Type Prelude.Prelude.symbol = string is not compatible with type
 elt = Prelude.Prelude.symbol * Err.loc option 

-Ralf.

Bug#773561: Can we discuss?

[jft]

How are u doing?

Bug#876304: O: xsddiagram -- XML Schema Definition (XSD) diagram viewer

[Mathieu Malaterre]

Package: wnpp
Severity: normal

I intend to orphan xsddiagram, I have not used anymore for at least a
couple of years. I believe there are still some users out there, since
this is the only open-source GUI for displaying XSD.

Description is:

 XSD Diagram is a XML Schema Definition (XSD) diagram viewer
 .
 Features:
  - Display the elements, the groups and the attributes
  - Show the text/HTML documentation of element and attribute when available
  - Print the diagram
  - Export the diagram to SVG, PNG, JPG and EMF (EMF only with Windows)
  - Zoom the diagram with the mouse wheel while holding the control key
  - XML validation based on the loaded XSD file
  - Registration in the Windows Explorer contextual menu (for Windows only)
  - Drag'n drop a xsd file or url on the main window header
 - Command line image generation

Bug#790204: gnucash: depends on libwebkitgtk-1.0-0 which is deprecated

[Micha Lenk]

Hi Dmitry (Debian package maintainer for Gnucash)

as you certainly know the Gnucash package in Debian build-depends on the
Gwenhywfar library for use by the AqBanking importer module. Current
releases of the Gwenhywfar library only supported Gtk2. Following the
upstream commits, I noticed a few days ago three commits contributed by
John Ralls, that were added to support Gtk3 too.

In an effort to support the transition from Gtk2 to Gtk3, I've just
added these patches to the libgwenhywfar package in Debian and uploaded
it to experimental as libgwenhywfar 4.18.0-2. This upload adds the new
binary packages libgwengui-gtk3-dev and libgwengui-gtk3-0. I would
appreciate if this package could get some testing, e.g. by uploading a
beta release of Gnucash to experimental.

I hope this helps us all to verify early that we didn't miss anything
during the transition from Gtk2 to Gtk3, and to find any related bugs as
early as possible.

Best regards,
Micha

Bug#876100: fixed in nvidia-graphics-drivers 375.82-4

[Jiri Palecek]

On 20.9.2017 08:51, Andreas Beckmann wrote:

  nvidia-graphics-drivers (375.82-4) unstable; urgency=medium
  .
* Prevent mixing libgl1-nvidia-glx with libgl1-nvidia-glvnd-glx.
* Use versioned Provides/Breaks/Replaces on the packages also built from
  src:libglvnd s.t. they cannot be satisfied by virtual packages provided
  from src:mesa (<< 17).  (Closes: #875683, #876100)
I don't understand. How does this solve issue 876100? The problem was 
that nvidia wasn't coinstallable with eg. libegl1-mesa-dev in its 
current version, and it is still so. Could you explain?


Regards
    Jiri Palecek

Bug#870906: ITP: pynmea2 - pynmea2 is a python library for the NMEA 0183 protocol

[Herbert Fortes]

Hi Joachim Langenbach,


> 
> thanks for your hints. Hopefully this time, I got all of them ;-) I have some 
> questions related to some of your hints:
> 
>> There are some adjusts to do:
>>
>> debian/compat:
>>
>> - instead of '9' put '10' (number only)
>>
>> debian/control:
>>
>>  - Build-Depends entry: python3-all-dev can be removed.
>>'cowbuilder' builds the package without it.
>>  - lintian needs an update. You can put '4.1.0'.
> 
> I only found 4.0.1 (at 
> https://www.debian.org/doc/debian-policy/upgrading-checklist.html). Are there 
> any other sources to find the most recent standards 
> version? However, I used 4.1.0 in my new upload.

Read here:
https://lists.debian.org/debian-devel-announce/2017/08/msg7.html


> 
>>  - Testsuite can be removed. There is no 'debian/tests' dir.
> 
> I added the testsuite, because it should run the python tests included in 
> pynmea2 sources. Did I understand testsuite the wrong way here? (Removed it 
> in 
> my upload)

autopkgtest is a CI (Debian Continuous Integration). Read about it here:

https://ci.debian.net/doc/file.TUTORIAL.html

I honestly do not remember about the tests during build of the package
you did. But the build system "Automatically detects the command to run 
the test suite."

Read here:
https://wiki.debian.org/Python/LibraryStyleGuide

I will 'dget' your package.



Regards,
Herbert


> 
> Regards,
> 
> Joachim
> 
>>  - Architecture: should be 'all'. (any is for programs like C, C++)
>>  - Depends entry: '${shlibs:Depends}' can be removed.
>>  - Provides entry can be removed.
>>
>> debian/copyright:
>>
>> - Debian entry is missing. The file should look like this:
>>
>>  Files: *
>>  Copyright: (C) 2013-2017 Tom Flanagan 
>>  License: MIT
>>
>>  Files: debian/*
>>  Copyright: 2017 Your-name-here ||
>>  License: Choose-one (usually upstream choice)
>>
>>  License: MIT
>>  Permission is hereby granted, free of charge, to any person obtaining
>>  blababla
>>
>>  License: (If you choose something different add here)
>>  blablabla
>>  a copy of this software and associated documentation files
>>
>>
>> debian/rules:
>>  
>> - I said about cleaning SOÛRCES.txt. You did right. But
>>   I learned something that looks better. Instead of an
>>   override_dh_auto_clean, 'egg-info' can be ignored if
>>   we use 'debian/source/options' file. One line in the
>>   file:
>> |
>>
>>  extend-diff-ignore="^[^/]+\.egg-info/"
>>
>> | 
>>
>>   Just in case, please see:
>>  
>> https://anonscm.debian.org/cgit/debian-science/packages/python-meshio.git/t
>> ree/debian/source/options
>>
>>
>> That's it. Let me know when you when the package
>> is ready.
>>
>>
>>
>> regards,
>> Herbert
> 

Bug#853154: suricata: Filesystem location of rule files

[Arturo Borrero Gonzalez]

On Mon, 30 Jan 2017 12:16:42 +0100 Sascha Steinbiss  wrote:
>
> the suricata package is currently configured by default to store its
> rules files in /etc/suricata/rules, which as a subdirectory under /etc
> is meant to hold 'static' files according to FHS section 3.7 [1]. While
> it is not strongly defined what exactly is meant by the term 'static',
> one might argue that a frequent updates of the rules files from an
> external source (e.g. via oinkmaster or pulledpork, which is quite
> common) might disqualify them as being largely static.
>
> As a suitable alternative location, one might think of something along
> the lines of /var/lib/suricata/rules -- FHS states that the contents of
> /var/lib should reflect a program’s variable internal state while
> running [2], and the rules may be a special case here (as they change
> the internal state of Suricata only when loaded or reloaded). It is also
> stated that the user should never need to modify these files, but I am
> not sure whether this also includes using a specific automation tool
> such as oinkmaster or pulledpork for that purpose.
> Still, this sounds like the best option. Any comments?
>
>
> [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html
> [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s08.html

Hi,

thinking again about this, I believe you are right.

However, this movement is something I would like to coordinate with
upstream (CC'ing Victor),
since it doesn't make sense to me to point in Debian to one location
while Suricata upstream points to another (in docs, recommendations,
defaults, etc.)

@Victor, any comment?

Using /var/lib/suricata/rules sounds good to me.

Bug#876279: AutoReply: Re: Bug#876279: Debian mirror mirror.math.princeton.edu: out-of-date, synscript

[Computer Doctor Queue via RT]

Greetings,

This message has been automatically generated in response to the creation of a
trouble ticket regarding Re: Bug#876279: Debian mirror
mirror.math.princeton.edu: out-of-date, synscript, a summary of which appears
below.

There is no need to reply to this message right now. Your ticket has been
assigned an ID of [Compudoc #1997].

Please include the string [Compudoc #1997] in the subject line of all future
correspondence about this issue. To do so, you may reply to this message.

Thank you,

--

On Wed, 20 Sep 2017, Benjamin A. Rose via RT wrote:

> We do not use custom stuff to mirror projects, in this case ftpsync. I use
> puppet to manage all this stuff, so one-offs which will require me to spend
> time on this are a non-starter to be on our 20-gigabit connected server. I 
> have
> told SourceForge the same thing, and they are no longer mirrored by us.

Unfortunately, a plain rsync is not sufficient to mirror Debian
correctly and provide apt and other clients with a good chance that it
will find a consistent mirror, nor does it help downstream mirrors to
also obtain a consistent mirror.

As such, plain rsync are not something we recommend people run or offer.


Regarless,

> I am showing the following rsync targets have not had errors in quite some
> time:
[..]
> Are there more appropriate rsync targets we can use that are tier-0 instead of
> hitting these tier-1 targets? If whitelisted for rsync I will change the
> targets and hopefully that will fix the issues.

your mirror *is* out of date.

http://mirror.math.princeton.edu/pub/debian/project/trace/
https://mirror-master.debian.org/status/mirror-info/mirror.math.princeton.edu.html

Your upstream however, is current.

https://mirror-master.debian.org/status/mirror-info/mirrors.pdx.kernel.org.html


Cheers,
Peter
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#876303: linux-source-4.9 kernel regression eeepc-wmi

[Oscon]

Package: linux-source-4.9

Version: >=4.9.25

eeepc-wmi doesn't work with my Eee PC netbook (Asus X101) after kernel upgrade 
from 3.14.79 to 4.9.y. So some Eee WMI hotkeys don't work with the new kernel.

kern.log:

---

[1.043620] eeepc_wmi: Found legacy ATKD device (ASUS010)
[1.043632] eeepc_wmi: WMI device present, but legacy ATKD device is also 
present and enabled
[1.043650] eeepc_wmi: You probably booted with acpi_osi="Linux" or 
acpi_osi="!Windows 2009"
[1.043662] eeepc_wmi: Can't load eeepc-wmi, use default acpi_osi 
(preferred) or eeepc-laptop

evtest output:

Available devices:
/dev/input/event0:  Lid Switch
/dev/input/event1:  Sleep Button
/dev/input/event2:  Power Button
/dev/input/event3:  Power Button
/dev/input/event4:  Video Bus
/dev/input/event5:  AT Translated Set 2 keyboard
/dev/input/event6:  HDA Intel Headphone
/dev/input/event7:  SynPS/2 Synaptics TouchPad



eeepc-laptop is not good for Asus X101. It works only with acpi_osi=Linux, but 
the KEY_BRIGHTNESSDOWN and KEY_BRIGHTNESSUP don't work in this case.

I have to use eeepc-wmi.

The patch "Use acpi_dev_found() " is the cause of the problem. /part of 
vanilla kernel/

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/platform/x86/eeepc-wmi.c?h=v4.9.51

...

I removed this patch from my kernel source, and eeepc_wmi works correct.:


kern.log:

[1.048511] input: Eee PC WMI hotkeys as /devices/platform/eeepc-
wmi/input/input5

evtest output:

Available devices:
/dev/input/event0:  Lid Switch
/dev/input/event1:  Sleep Button
/dev/input/event2:  Power Button
/dev/input/event3:  Power Button
/dev/input/event4:  Video Bus
/dev/input/event5:  Eee PC WMI hotkeys
/dev/input/event6:  AT Translated Set 2 keyboard
/dev/input/event7:  HDA Intel Headphone
/dev/input/event8:  SynPS/2 Synaptics TouchPad

I suggest to remove the bad patch /for example with attachment/ from the 
kernel source .

I am using Debian GNU/Linux 8.9, 4.9.25/4.9.30 based kernel and libc6 
2.19-18+deb8u10.

Thanks
Oscondiff -Nrup linux-source-4.9-limbo/drivers/platform/x86/eeepc-wmi.c linux-source4925/drivers/platform/x86/eeepc-wmi.c
--- linux-source-4.9-limbo/drivers/platform/x86/eeepc-wmi.c	2017-04-27 07:11:26.0 +
+++ linux-source4925/drivers/platform/x86/eeepc-wmi.c	2017-09-18 11:06:57.0 +
@@ -204,10 +204,30 @@ static void eeepc_wmi_key_filter(struct
 	}
 }
 
+static acpi_status eeepc_wmi_parse_device(acpi_handle handle, u32 level,
+		 void *context, void **retval)
+{
+	pr_warn("Found legacy ATKD device (%s)\n", EEEPC_ACPI_HID);
+	*(bool *)context = true;
+	return AE_CTRL_TERMINATE;
+}
+
+static int eeepc_wmi_check_atkd(void)
+{
+	acpi_status status;
+	bool found = false;
+
+	status = acpi_get_devices(EEEPC_ACPI_HID, eeepc_wmi_parse_device,
+  , NULL);
+
+	if (ACPI_FAILURE(status) || !found)
+		return 0;
+	return -1;
+}
+
 static int eeepc_wmi_probe(struct platform_device *pdev)
 {
-	if (acpi_dev_found(EEEPC_ACPI_HID)) {
-		pr_warn("Found legacy ATKD device (%s)\n", EEEPC_ACPI_HID);
+	if (eeepc_wmi_check_atkd()) {
 		pr_warn("WMI device present, but legacy ATKD device is also "
 			"present and enabled\n");
 		pr_warn("You probably booted with acpi_osi=\"Linux\" or "

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[Carsten Schoenert]

Hi *,

On Wed, Sep 20, 2017 at 06:18:03PM +0200, intrigeri wrote:
... 
> > Sure works for me, thanks for proposing this sensible workflow!
> 
> OK, glad we're on the same page :)
> 
> Let's wait for Ulrike's input before closing this bug though.
> 
> Ulrike, what do you think?
> 
> FTR I've just requested commit access to the Vcs-Git of src:icedove,
> which if granted might streamline the process a bit more :)

I'm fine with that workflow too for now.

Some small update on what src:icedove maintainer(s) is or will be.
I've talked with Christoph some days ago and he informed me he hasn't
enought time and will currently not work very active on Thunderbird
packages in the next future. So we decided that we just switch the
maintainer for src:icedove and I will step in as the main active
maintianer. That's no big change as I've done this mainly for over a
year. Guido isn't working on packaging new versions.

I have no great experience with AppArmor (but Christoph also not), Guido
don't want to do much for Thunderbird due time constraints. I'm happy he
is doing all the LTS work on Thunderbird packages.

So in the long turn I think it's better to migrate the AppArmor profile
for Thunderbird to AppArmor itself? Otherwise we can stay on the status
quo and intrigeri is performing the needed changes for the profile
inside the Thunderbird packaging.

Regards
Carsten

Bug#876302: RFS: openssl-ibmca/1.4.0-1 [ITP]

[Paulo Ricardo Paz Vital]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "openssl-ibmca"

* Package name : openssl-ibmca
  Version : 1.4.0-1
  Upstream Author : openCryptoki Project
* URL : https://github.com/opencryptoki/openssl-ibmca
* License : Apache-2.0
  Section : libs

It builds those binary packages:
openssl-ibmca - libica engine for OpenSSL

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/openssl-ibmca

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/o/openssl-ibmca/openssl-ibmca_1.4.0-1.dsc


Changes since the last upload:
openssl-ibmca (1.4.0-1) unstable; urgency=medium
 * Initial release. Closes: #813772
-- Paulo Vital  Wed, 20 sep 2017 11:18:57 -0300

Regards, Paulo Vital
-- 
Paulo Vital

Bug#857798: Please add an AppArmor profile for Pulseaudio

[Felipe Sateler]

On Wed, Mar 15, 2017 at 1:57 PM, Ulrike Uhlig  wrote:
> Hi Felipe,
>
 + # install apparmor profile
 + cp debian/apparmor/usr.bin.pulseaudio
 debian/pulseaudio/etc/apparmor.d/usr.bin.pulseaudio

 This would install the file with whatever umask is currently set.
>>>
>>> Thanks for making this clear.
>>> Yes. root:root 644 is correct.
>>
>> Thanks. I have changed this to install -m 644 instead of cp.
>
> Perfect.
>
>> BTW, I still would like an answer to this question:
>>
>> Wouldn't that benefit be best achieved if the profile was shipped
>> by (pulse) upstream?
>>
>> AFAICT, this file should be distro-agnostic, so it should be safe to
>> ship in the upstream package, wouldn't it?
>
> The apparmor profile itself could indeed be part of the upstream package.
>
> Currently, these profiles are worked on collectively by people from
> Ubuntu, Debian/Tails and OpenSuSe and we use a shared Git repository
> between our three distributions.
>
> For torbrowser-launcher we upstreamed the profile for example, also
> because upstream is very responsive about patches. But I have no other
> examples in mind where this would be the case.
>
> Would you care to ask upstream if they'd like to include it?

Better late than never, I have asked upstream and they are receptive
to adding the profile there. Could you please propose a patch on the
upstream mailing list?

https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


-- 

Saludos,
Felipe Sateler

Bug#792101: Bug# [...]

[PICCORO McKAY Lenz]

also the behaviour explained at the end of my previous mail* was apllied
perfectly to the KDE4 and KDE3 packages! in the past... for squeeze, etch
and sarge*

if as progress of depends and policy analisis progress, users like me we
can test in the way aditions or remotions was made over the main objetiv,
the gitea/gogs package..

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-09-20 13:49 GMT-04:00 PICCORO McKAY Lenz :

> 2017-09-19 20:31 GMT-04:00 Michael Lustfield :
>
>> To be blunt, I struggled very hard to follow the text you wrote..
>> especially
>> true for the github bug report. I have done my best to understand what the
>> intended message was, but if I misunderstood then I apologize in advance.
>>
> sorry for my english and you indestand almost all
>
>> On Mon, 18 Sep 2017 14:55:12 -0400
>> PICCORO McKAY Lenz  wrote:
>> > 1) makde a package that only use the downloaded sources that ship all
>> > depends
>>
>> This sounds like you're suggesting that we actually make use of content
>> within
>> the vendor/ directories. If that's the case then we'll need to discuss
>> DFSG in a
>> bit more depth because this will cause a clear violation.In fact, I'm
>> aware of sources within gogs/gitea that *DOES* *NOT* meet DFSG,
>>
> right but only in a part.. i mean made the package and progressl
> Make the package, and progressively go removing or adding dependencies and
> objects according to what is going to work, for example in the case of
> dependency: if today xxx.yyy is provided then in the already made gogs
> package removing the xxx.yyy reference build in source, about the DFSG can
> be check as being used it, due some maybe drop important funtionality
>
> Each dependency needs to be individually packaged and reviewed for DFSG
>> standards. This work has revealed a lot of issues that have now been
>> resolved
>> (in Gitea). Unfortunately, the author/owner of gogs has no interest in
>> adopting
>> these changes. (details need not be repeated here)
>>
> I also noted that gitea solved some problems inherints from gogs, but i
> also noted that on every new releaqse as they introduced fixeds, same
> amount of issues are newer due new features or bigfixeds itself
>
> this can be a problem.., the differences between gogs and gitea are more
> deep in development model but in funtionallity are pretty same..
>
>
>> > the other way its that do not make usage of thos depends pacakges that
>> > change too many in the time!
>> I didn't follow this at all.
>>
> gogs and gitea used a specific commits of that depends.. and taking in
> consideration that packages on debian are "too older or too newer" respect
> the necesary..
> so then, maybe we need a special packages mades for those? sound like a
> duplication of work, but some examples maybe are owncloud and roundcube
>
>
>> packaging I have been working on offers a gogs meta package that selects
>> gitea.
>> This does not mean gitea is pretending to be gogs. It is a
>> relatively-compatible alternative.
>>
> i dont think this would be a good idea. its better a good made
> separation.. no relation
>
>
> > gogs are focused on simplicity, no new features and only security fixeds
>> > gitea are focused on new features and changes too many ..
>>
>> This is very much *not* the difference between the two. Gitea is a fork
>> of gogs
>> that was created for entirely different reasons. Many of those reasons
>> are why
>> gogs is not likely to ever exist in Debian repos.
>>
> i already know about the problem that raised the fork of gitea.. but gitea
> are not a separate project different rom gogs.. the differences between
> funtionalities are few, but in development are too many...
>
>
>> Conforming to Debian policy does not come later, it comes first. Until I
>> have a
>> proper Debianized package, I will not release Gitea into Debian. I /do/
>> however, have a lot of progress made and only a few more new dependencies
>> that
>> need to pass through NEW.
>>
> as i mention, to se real progress and funtionality (and if some ot the
> current depends are not fit) we suggest Make the package, and progressively
> go removing or adding dependencies and objects according to what is going
> to work, for example in the case of dependency: if today xxx.yyy is
> provided then in the already made gogs package removing the xxx.yyy
> reference build in source, about the DFSG can be check as being used it,
> due some maybe drop important funtionality
> so you can made all of then in a personal repository in alliot or in
> opensuse build service--
>
>
>> If you would like to help, check out the "(un)reproducible" column here:
>> https://udd.debian.org/dmd/?michael%40lustfield.net#versions
>
> the complete log need DH_VERVOSE=1 due the test fail does not have a good
> trace... the debug output only had pointer addresses, i cannot setup better
> trace..
>
> seems are realted to 64 bit addresses, so i 

Bug#876238: gcc-cross-support: FTBFS, wants to regenerate debian/control with more and renamed packages

[Andreas Beckmann]

On 20.09.2017 06:16, Helmut Grohne wrote:
> So while there hasn't been any upload, progress is not stuck. I'd like
> to keep the package (rc buggy as it is) in experimental for a while
> though. I hope that doesn't cause too much pain to you.

No problem. Now it's documented that this package still has a purpose.
(I just did a rebuild of experimental and I'm slowly processing the
failures. There is some quite old cruft that no longer builds... That is
at least getting RC bugs now.)


Andreas

Bug#780606: Bug# [...]

[PICCORO McKAY Lenz]

2017-09-19 20:31 GMT-04:00 Michael Lustfield :

> To be blunt, I struggled very hard to follow the text you wrote..
> especially
> true for the github bug report. I have done my best to understand what the
> intended message was, but if I misunderstood then I apologize in advance.
>
sorry for my english and you indestand almost all

> On Mon, 18 Sep 2017 14:55:12 -0400
> PICCORO McKAY Lenz  wrote:
> > 1) makde a package that only use the downloaded sources that ship all
> > depends
>
> This sounds like you're suggesting that we actually make use of content
> within
> the vendor/ directories. If that's the case then we'll need to discuss
> DFSG in a
> bit more depth because this will cause a clear violation.In fact, I'm
> aware of sources within gogs/gitea that *DOES* *NOT* meet DFSG,
>
right but only in a part.. i mean made the package and progressl
Make the package, and progressively go removing or adding dependencies and
objects according to what is going to work, for example in the case of
dependency: if today xxx.yyy is provided then in the already made gogs
package removing the xxx.yyy reference build in source, about the DFSG can
be check as being used it, due some maybe drop important funtionality

Each dependency needs to be individually packaged and reviewed for DFSG
> standards. This work has revealed a lot of issues that have now been
> resolved
> (in Gitea). Unfortunately, the author/owner of gogs has no interest in
> adopting
> these changes. (details need not be repeated here)
>
I also noted that gitea solved some problems inherints from gogs, but i
also noted that on every new releaqse as they introduced fixeds, same
amount of issues are newer due new features or bigfixeds itself

this can be a problem.., the differences between gogs and gitea are more
deep in development model but in funtionallity are pretty same..


> > the other way its that do not make usage of thos depends pacakges that
> > change too many in the time!
> I didn't follow this at all.
>
gogs and gitea used a specific commits of that depends.. and taking in
consideration that packages on debian are "too older or too newer" respect
the necesary..
so then, maybe we need a special packages mades for those? sound like a
duplication of work, but some examples maybe are owncloud and roundcube


> packaging I have been working on offers a gogs meta package that selects
> gitea.
> This does not mean gitea is pretending to be gogs. It is a
> relatively-compatible alternative.
>
i dont think this would be a good idea. its better a good made separation..
no relation


> gogs are focused on simplicity, no new features and only security fixeds
> > gitea are focused on new features and changes too many ..
>
> This is very much *not* the difference between the two. Gitea is a fork of
> gogs
> that was created for entirely different reasons. Many of those reasons are
> why
> gogs is not likely to ever exist in Debian repos.
>
i already know about the problem that raised the fork of gitea.. but gitea
are not a separate project different rom gogs.. the differences between
funtionalities are few, but in development are too many...


> Conforming to Debian policy does not come later, it comes first. Until I
> have a
> proper Debianized package, I will not release Gitea into Debian. I /do/
> however, have a lot of progress made and only a few more new dependencies
> that
> need to pass through NEW.
>
as i mention, to se real progress and funtionality (and if some ot the
current depends are not fit) we suggest Make the package, and progressively
go removing or adding dependencies and objects according to what is going
to work, for example in the case of dependency: if today xxx.yyy is
provided then in the already made gogs package removing the xxx.yyy
reference build in source, about the DFSG can be check as being used it,
due some maybe drop important funtionality
so you can made all of then in a personal repository in alliot or in
opensuse build service--


> If you would like to help, check out the "(un)reproducible" column here:
> https://udd.debian.org/dmd/?michael%40lustfield.net#versions

the complete log need DH_VERVOSE=1 due the test fail does not have a good
trace... the debug output only had pointer addresses, i cannot setup better
trace..

seems are realted to 64 bit addresses, so i disable the checks and try to
reproduce with the included in gogs, and does not able to reproduce.. due
in the sources only 64 bit adreses are used--

take in consideration that amount of go developer used 64bit by default, so
more i386 setups are need, but current debian does not fit my need on i385
(too many req) so i used squeeze and in this setup are running well gogs..
gitea does not!


> --
> Michael Lustfield
>

Bug#875892: apache2 needs attach_disconnected

[Guido Günther]

Hi,
On Wed, Sep 20, 2017 at 04:50:08PM +0200, intrigeri wrote:
> Control: reassign -1 libapache2-mod-apparmor
> Control: tag -1 + upstream
> Control: forwarded -1 
> https://code.launchpad.net/~intrigeri/apparmor/apache2-attach_disconnected/+merge/331065
> 
> Hi,
> 
> Guido Günther:
> > Patch attached (I'd send this upstream but bzr).
> 
> Thanks, forwarded!
> 
> Does libapache2-mod-apparmor break apache2 startup when the profile is
> in complain mode (the default)? If yes, then I'll cherry-pick this.
> Otherwise it'll wait for the next upstream release (I'm trying to
> focus on policy that's enabled by default).

The default is confined so next upstream release is perfectly o.k. from
my side. Thanks for forwarding this!
 -- Guido

Bug#860268: .desktop files can hide malware in Nautilus

[Donncha O'Cearbhaill]

Phil Wyett:
> On Wed, 2017-09-13 at 15:32 +, Donncha O'Cearbhaill wrote:
>> Phil Wyett:

 Hi,

 Please note that the debdiff I provided was essentially a raw backport for
 testing and I thought it may have issues. It was never meant as a 'here it
 is,
 all done' patch ready for submission as a stable update.

 I am a little busy at the moment, but if I can help here, I will.


I have created a backport patch targeting Nautilus 3.22.3 which contains
the cherry-picked translations for the new UI string.

It adds a line to the debian/control file to remove the pre-built .mo
translation files which were included in the upstream source release. I
also needed to add gettext as a build dependency. With this patch the
.mo/.gmo files should be rebuilt with the new strings during the Debian
package build.

I have tested the backported Nautlius package with Tails 3.1 which is
based on Debian stable. The English and localised interface is displayed
correctly.

Ideally this backport would be ready for Tails 3.2 which is schedule to
be released early next week.

Please let me know if I need to make any further changes.

Regards,
Donncha
diff -Nru nautilus-3.22.3/debian/changelog nautilus-3.22.3/debian/changelog
--- nautilus-3.22.3/debian/changelog2017-03-09 02:39:58.0 +0100
+++ nautilus-3.22.3/debian/changelog2017-09-13 22:22:40.0 +0200
@@ -1,3 +1,10 @@
+nautilus (3.22.3-1.1) stretch; urgency=high
+
+  * Non-maintainer upload.
+  * Backport desktop file trust patch from upstream. (Closes: #860268).
+
+ -- Phil Wyett   Fri, 01 Sep 2017 23:43:51 +0100
+
 nautilus (3.22.3-1) unstable; urgency=medium

   * New upstream release.
diff -Nru nautilus-3.22.3/debian/control nautilus-3.22.3/debian/control
--- nautilus-3.22.3/debian/control  2017-03-09 02:39:58.0 +0100
+++ nautilus-3.22.3/debian/control  2017-09-20 17:58:00.0 +0200
@@ -31,7 +31,8 @@
gobject-introspection (>= 0.9.12-4~),
libgirepository1.0-dev (>= 0.10.7-1~),
libglib2.0-doc,
-   libgtk-3-doc
+   libgtk-3-doc,
+   gettext
 Homepage: https://wiki.gnome.org/action/show/Apps/Nautilus
 Vcs-Browser: 
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/nautilus/
 Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/nautilus/
diff -Nru nautilus-3.22.3/debian/control.in nautilus-3.22.3/debian/control.in
--- nautilus-3.22.3/debian/control.in   2016-12-10 02:59:53.0 +0100
+++ nautilus-3.22.3/debian/control.in   2017-09-20 14:52:48.0 +0200
@@ -27,7 +27,8 @@
gobject-introspection (>= 0.9.12-4~),
libgirepository1.0-dev (>= 0.10.7-1~),
libglib2.0-doc,
-   libgtk-3-doc
+   libgtk-3-doc,
+   gettext
 Homepage: https://wiki.gnome.org/action/show/Apps/Nautilus
 Vcs-Browser: 
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/nautilus/
 Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/nautilus/
diff -Nru nautilus-3.22.3/debian/patches/desktop_file_trust.patch 
nautilus-3.22.3/debian/patches/desktop_file_trust.patch
--- nautilus-3.22.3/debian/patches/desktop_file_trust.patch 1970-01-01 
01:00:00.0 +0100
+++ nautilus-3.22.3/debian/patches/desktop_file_trust.patch 2017-09-14 
15:26:27.0 +0200
@@ -0,0 +1,941 @@
+From 1630f53481f445ada0a455e9979236d31a8d3bb0 Mon Sep 17 00:00:00 2001
+From: Carlos Soriano 
+Date: Mon, 6 Feb 2017 18:47:54 +0100
+Subject: mime-actions: use file metadata for trusting desktop files
+
+Currently we only trust desktop files that have the executable bit
+set, and don't replace the displayed icon or the displayed name until
+it's trusted, which prevents for running random programs by a malicious
+desktop file.
+
+However, the executable permission is preserved if the desktop file
+comes from a compressed file.
+
+To prevent this, add a metadata::trusted metadata to the file once the
+user acknowledges the file as trusted. This adds metadata to the file,
+which cannot be added unless it has access to the computer.
+
+Also remove the SHEBANG "trusted" content we were putting inside the
+desktop file, since that doesn't add more security since it can come
+with the file itself.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=777991
+
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860268
+ .
+ nautilus (3.22.3-1.1) stretch; urgency=high
+ .
+   * Non-maintainer upload.
+   * Backport desktop file trust patch from upstream. (Closes: #860268)
+Author: Phil Wyett 
+---
+
+--- a/src/nautilus-directory-async.c
 b/src/nautilus-directory-async.c
+@@ -30,6 +30,7 @@
+ #include "nautilus-global-preferences.h"
+ #include "nautilus-link.h"
+ #include "nautilus-profile.h"
++#include "nautilus-metadata.h"
+ #include 
+ #include 
+ #include 
+@@ -3580,13 +3581,17 @@
+ {
+ 

Bug#875683: nvidia-graphics-drivers: libGL.so.1 missing with libglvnd libs

[Andreas Beckmann]

On 16.09.2017 19:25, Luca Boccassi wrote:
>> I tried a hack (r7481) s.t. this should now work with mesa 13 in
>> testing. Some provides are disabled, so lib*-glvnd-nvidia* won't work
>> as
>> a substitute for the corresponding package from src:libglvnd.
> 
> Thanks, this works on Stretch now.

Cleaned this up a bit and uploaded it.
In stretch, the lib*-glvnd-nvidia* packages will be used, in sid the
packages from src:libglvnd. In sid it is currently (due to some disabled
provides) not possible to use the lib*-glvnd-nvidia* packages as a
replacement for src:libglvnd packages for use with mesa packages.
I hope that doesn't cause migration blockage.


Andreas

Bug#876279: Debian mirror mirror.math.princeton.edu: out-of-date, synscript

[Peter Palfrader]

On Wed, 20 Sep 2017, Benjamin A. Rose via RT wrote:

> We do not use custom stuff to mirror projects, in this case ftpsync. I use
> puppet to manage all this stuff, so one-offs which will require me to spend
> time on this are a non-starter to be on our 20-gigabit connected server. I 
> have
> told SourceForge the same thing, and they are no longer mirrored by us.

Unfortunately, a plain rsync is not sufficient to mirror Debian
correctly and provide apt and other clients with a good chance that it
will find a consistent mirror, nor does it help downstream mirrors to
also obtain a consistent mirror.

As such, plain rsync are not something we recommend people run or offer.


Regarless,

> I am showing the following rsync targets have not had errors in quite some
> time:
[..]
> Are there more appropriate rsync targets we can use that are tier-0 instead of
> hitting these tier-1 targets? If whitelisted for rsync I will change the
> targets and hopefully that will fix the issues.

your mirror *is* out of date.

http://mirror.math.princeton.edu/pub/debian/project/trace/
https://mirror-master.debian.org/status/mirror-info/mirror.math.princeton.edu.html

Your upstream however, is current.

https://mirror-master.debian.org/status/mirror-info/mirrors.pdx.kernel.org.html


Cheers,
Peter
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#795431: Fix for #795431 v2

[Vincas Dargis]

Patch v2.
=== modified file 'debian/control'
--- debian/control	2017-09-19 06:19:23 +
+++ debian/control	2017-09-20 16:40:37 +
@@ -30,7 +30,7 @@
 Replaces: fcitx-data (<< 1:4.2.9.1-1ubuntu2)
 Suggests: apparmor-profiles, apparmor-profiles-extra, apparmor-utils
 Description: user-space parser utility for AppArmor
- This provides the system initialization scripts needed to use the
+ apparmor provides the system initialization scripts needed to use the
  AppArmor Mandatory Access Control system, including the AppArmor Parser
  which is required to convert AppArmor text profiles into machine-readable
  policies that are loaded into the kernel for use with the AppArmor Linux
@@ -49,9 +49,10 @@
 Architecture: all
 Depends: apparmor (>= 2.8.96~2535-0ubuntu1~), ${misc:Depends}
 Description: profiles for AppArmor Security policies
- This provides various AppArmor profiles that have not been shipped by
- the packages they provide confinement for. By default, they ship in
- complain mode so that users can test and choose which are desired.
+ apparmor-profiles provides various AppArmor profiles that have not
+ been shipped by the packages they provide confinement for. By default,
+ they ship in complain mode so that users can test and choose which are
+ desired.
 
 Package: libapparmor-dev
 Section: libdevel
@@ -59,9 +60,9 @@
 Multi-Arch: same
 Depends: libapparmor1 (= ${binary:Version}), ${misc:Depends}
 Description: AppArmor development libraries and header files
- This package provides the development libraries and header files needed to
- link against the AppArmor changehat and log parsing functions. Also
- includes the manpages for library functions.
+ libapparmor-dev package provides the development libraries and header
+ files needed to link against the AppArmor changehat and log parsing
+ functions. Also includes the manpages for library functions.
 
 Package: libapparmor1
 Section: libs
@@ -69,18 +70,18 @@
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: changehat AppArmor library
- This package provides the shared library used for making use of the
- AppArmor profile and changehat functionality, as well as common log
- parsing routines.
+ libapparmor1 package provides the shared library used for making use
+ of the AppArmor profile and changehat functionality, as well as common
+ log parsing routines.
 
 Package: libapparmor-perl
 Section: perl
 Architecture: any
 Depends: ${perl:Depends}, ${shlibs:Depends}, ${misc:Depends}
 Description: AppArmor library Perl bindings
- This provides the Perl module that contains the language bindings
- for the AppArmor library, libapparmor, which were autogenerated via
- SWIG.
+ libapparmor-perl provides the Perl module that contains the language
+ bindings for the AppArmor library, libapparmor, which were autogenerated
+ via SWIG.
 
 Package: libapache2-mod-apparmor
 Pre-Depends: ${misc:Pre-Depends}
@@ -88,26 +89,26 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: changehat AppArmor library as an Apache module
- This provides the Apache module needed to declare various differing
- confinement policies when running virtual hosts in the webserver
- by using the changehat abilities exposed through libapparmor.
+ libapache2-mod-apparmor provides the Apache module needed to declare
+ various differing confinement policies when running virtual hosts in the
+ webserver by using the changehat abilities exposed through libapparmor.
 
 Package: libpam-apparmor
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: changehat AppArmor library as a PAM module
- This provides the PAM module needed to declare various differing
- confinement policies when starting PAM sessions by using the
+ libpam-apparmor provides the PAM module needed to declare various
+ differing confinement policies when starting PAM sessions by using the
  changehat abilities exposed through libapparmor.
 
 Package: apparmor-notify
 Architecture: all
 Depends: libapparmor-perl, ${perl:Depends}, ${misc:Depends}, libnotify-bin
 Description: AppArmor notification system
- This package provides a utility to display AppArmor denial messages via
- desktop notifications. The utility can also be used to generate summary
- reports.
+ apparmor-notify package provides a utility to display AppArmor denial
+ messages via desktop notifications. The utility can also be used to
+ generate summary reports.
 
 Package: python-libapparmor
 Section: python
@@ -115,9 +116,9 @@
 Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
 XS-Python-Version: ${python:Versions}
 Description: AppArmor library Python bindings
- This provides the Python module that contains the language bindings
- for the AppArmor library, libapparmor, which were autogenerated via
- SWIG.
+ python-libapparmor provides the Python module that contains the language
+ bindings for the AppArmor library, libapparmor, which were autogenerated
+ via SWIG.
 

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Jonas Meurer]

Hey PEB, hey Barry,


Am 07.09.2017 um 12:55 schrieb Jonas Meurer:
> Am 07.09.2017 um 12:37 schrieb Pierre-Elliott Bécue:
>> I have some news.
>>
>> Mattia (mapreri on IRC) gave me a first review of my package>> with plenty 
>> small fixes to apply. I didn't have time until
>> now because of some deadlines in my PhD work.

Hope that your PhD work is going well.

>> I'll jump back in at the end of the week.
>>
>> Barry was in the middle of a rush AFAIR, and for now I got little news.
> 
> that's great to hear. I'll wait for your fixes and give the packages
> another try afterwards. Just drop me a note and I'll do further review.

I found some time to work on mailman3-core and mailmanclient packages
during the last days. You find the latest packaging status in the repos at

https://github.com/P-EB/mailman3-core
https://anonscm.debian.org/cgit/python-modules/packages/mailmanclient.git/

In my eyes the mailman3-core and mailmanclient packages are in shape for
getting uploaded by now (hyperkitty & postorius still need some love).

@barry: I could do the uploads but as you're PEB's sponsor so far you
might want to do that yourself. Maybe you also want to review the latest
changes to the packages? That would be awesome.

In any case, let me know what procedure you prefer. I'll wait for PEB's
and your feedback before any further steps.

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#876301: captagent: Broken init script

[Guillem Jover]

Package: captagent
Version: 6.1.0.20-3
Severity: serious

Hi!

The init script provided in this package is broken. It fails when
stopping an already stopped daemon, which can make package removal
fail.

It also incorrectly considers these failure modes, and reports it
as such. And is doing redundant checks with ps when those could be
completely off-loaded to start-stop-daemon.

(Ideally the init script would use the LSB output functions.)

Thanks,
Guillem

Bug#876279: Debian mirror mirror.math.princeton.edu: out-of-date, synscript

[Benjamin A. Rose via RT]

Hello,

We do not use custom stuff to mirror projects, in this case ftpsync. I use
puppet to manage all this stuff, so one-offs which will require me to spend
time on this are a non-starter to be on our 20-gigabit connected server. I have
told SourceForge the same thing, and they are no longer mirrored by us.

I am showing the following rsync targets have not had errors in quite some
time:

debian:
remotesrc: "rsync://mirrors.kernel.org/debian"
localdest: "/var/www/html/pub/debian"
extracommand: "date -u >
/var/www/html/pub/debian/project/trace/mirror.math.princeton.edu; chmod 755
/var/www/html/pub/debian/project/trace/mirror.math.princeton.edu"
debian-archive:
remotesrc: "rsync://archive.debian.org/debian-archive"
localdest: "/var/www/html/pub/debian-archive"
extracommand: "date -u >
/var/www/html/pub/debian-archive/project/trace/mirror.math.princeton.edu; chmod
755 /var/www/html/pub/debian-archive/project/trace/mirror.math.princeton.edu;
ln /var/www/html/pub/debian-archive/project/trace/master
/var/www/html/pub/debian-archive/project/trace/archive.debian.org"
debian-cd:
remotesrc: "rsync://mirror.rit.edu/debian-cd"
localdest: "/var/www/html/pub/debian-cd"
extracommand: "date -u >
/var/www/html/pub/debian-cd/project/trace/mirror.math.princeton.edu; chmod 755
/var/www/html/pub/debian-cd/project/trace/mirror.math.princeton.edu"

Are there more appropriate rsync targets we can use that are tier-0 instead of
hitting these tier-1 targets? If whitelisted for rsync I will change the
targets and hopefully that will fix the issues.

Thanks,
Ben



On 09/20/2017 08:57 AM, Peter Palfrader via RT wrote:

  Wed Sep 20 08:57:12 2017: Request 1995 
(https://problem.math.princeton.edu/Ticket/Display.html?id=1995)
  was acted upon by wea...@debian.org (mailto:wea...@debian.org).

   Transaction:  Ticket created by [1]wea...@debian.org 
  

   

   

   
  1. mailto:wea...@debian.org   
   
 Queue:  General
  
   Subject:  Bug#876279: Debian mirror mirror.math.princeton.edu: 
out-of-date,
  synscript 
   
 Owner:  Nobody 
  
Requestors:  [1]wea...@debian.org   
  

   

   

   
  1. mailto:wea...@debian.org   
   
Status:  new
  
Ticket URL:  
[1]https://problem.math.princeton.edu/Ticket/Display.html?id=1995

   

   

   
  1. 
https://problem.math.princeton.edu/Ticket/Display.html?id=1995


  Package: mirrors
  User: mirr...@packages.debian.org  (mailto:mirr...@packages.debian.org)  
Usertags: mirror-problem may-auto-close
  Control: submitter -1   mirr...@debian.org  (mailto:mirr...@debian.org)  
  Hi,
  
  according to our monitoring [1], your mirror hasn't updated in several
  days.  Please investigate.
  
  Also,
  o The trace file at
  
http://mirror.math.princeton.edu/pub/debian/project/trace/mirror.math.princeton.edu
does not contain much information.
  
Please use our ftpsync script to mirror Debian.
  
Using a modern ftpsync ensures updates are done in the correct order
so apt clients don't get confused.   In particular, it processes
translations, contents, and more files that have been added to the
archive in recent years in the correct stage.  It also should produce
trace files that contain more information that is useful for us.
  
  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz  
  Cheers,
  Peter
  
  1:   
https://mirror-master.debian.org/status/mirror-info/mirror.math.princeton.edu.html
  
  -- 
  |  .''`.   ** Debian **
Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/   | `. `'  Operating System
  |   `-  https://www.debian.org/  

Bug#876300: libsundials-dev: libsundials-serial-dev is gone

[Paolo Greppi]

Package: libsundials-dev
Version: 2.7.0+dfsg-2
Severity: normal

Dear Maintainer,

on stretch libsundials-serial-dev is available.

With the update 2.7.0 release this is not available anymore. I assume it
is replaced by libsundials-dev.

Should there be a  transitional package to ease the migration ?

Thanks, Paolo

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

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

Versions of packages libsundials-dev depends on:
ii  cmake  3.9.1-1
ii  gfortran   4:7.2.0-1d1
ii  libhypre-dev   2.11.1-4
ii  libsundials-arkode12.7.0+dfsg-2
ii  libsundials-cvode2 2.7.0+dfsg-2
ii  libsundials-cvodes22.7.0+dfsg-2
ii  libsundials-ida2   2.7.0+dfsg-2
ii  libsundials-idas1  2.7.0+dfsg-2
ii  libsundials-kinsol22.7.0+dfsg-2
ii  libsundials-nvecparallel-hypre22.7.0+dfsg-2
ii  libsundials-nvecparallel-mpi2  2.7.0+dfsg-2
ii  libsundials-nvecparallel-openmp2   2.7.0+dfsg-2
ii  libsundials-nvecparallel-petsc22.7.0+dfsg-2
ii  libsundials-nvecparallel-pthread2  2.7.0+dfsg-2
ii  libsundials-nvecserial22.7.0+dfsg-2
ii  mpi-default-dev1.9
ii  petsc-dev  3.7.6+dfsg1-3
ii  pkg-config 0.29-4+b1

libsundials-dev recommends no packages.

libsundials-dev suggests no packages.

-- no debconf information

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[intrigeri]

Hi!

Simon Deziel:
> On 2017-09-20 11:26 AM, intrigeri wrote:
>>> My only concern is what to do when those new rules are stalled
>>> waiting on review? Could they be integrated to the Debian version while
>>> waiting for the official merge? If yes, I think that's the best of both
>>> worlds.
>> 
>> For the record I generally don't wait for upstream to review'n'merge
>> before I apply fixes to AppArmor policy in Debian packages I maintain:
>> the "upstream first" moto does matter to me, but in practice I define
>> it as "submit upstream first and then upload to Debian" rather than as
>> "wait for upstream to ACK my proposed changes before fixing the
>> problem our users are complaining about". So yeah, I think we can
>> definitely have the best of both worlds :)
>> 
>> Now, wrt. Thunderbird specifically: so far, AFAIK the maintainers of
>> src:icedove in Debian haven't bothered taking stuff from upstream's
>> apparmor-profiles.git directly. Instead, they are kind enough to apply
>> any reasonable update we (= mostly Ulrike, but I'm sure she would not
>> mind if you and I gave her a hand) ask them to take.
>> 
>> So I would suggest we forward them any update we think should go in
>> Debian, as soon as we've submitted it upstream, without waiting for
>> upstream to review. Now, let's keep in mind that these changes will go
>> straight to Debian *stable* in the next security upload — if I'm not
>> mistaken). So perhaps a little bit of peer-review would be in order.
>> For example, assuming one of us three sends a merge request to
>> Launchpad, as soon as any of the other two ACKs it, we ask the
>> src:icedove maintainers to take it. I.e. we piggy pack on the existing
>> upstream review process and tools and save some paperwork.
>> 
>> Deal?

> Sure works for me, thanks for proposing this sensible workflow!

OK, glad we're on the same page :)

Let's wait for Ulrike's input before closing this bug though.

Ulrike, what do you think?

FTR I've just requested commit access to the Vcs-Git of src:icedove,
which if granted might streamline the process a bit more :)

Cheers,
-- 
intrigeri

Bug#876299: pcre3: ftbfs on s390x, test failures

[Matthew Vernon]

tags -1 moreinfo
quit

Hi,

> Test 2: API, errors, internals, and non-Perl stuff (not UTF-16)
> Segmentation fault
> 
> ** Test 2 requires a lot of stack. If it has crashed with a
> ** segmentation fault, it may be that you do not have enough
> ** stack available by default. Please see the 'pcrestack' man
> ** page for a discussion of PCRE's stack usage.
> 
> FAIL RunTest (exit status: 1)

Could you try re-running this test on s390x with a higher stack limit
set, please?

Thanks,

Matthew

Bug#873503: broadcom-sta: Please backport 6.30.223.271-7 to stretch and jessie (sloppy)

[Roger Shimizu]

Control: tags -1 +patch pending

On Mon, Aug 28, 2017 at 10:24 PM, Roger Shimizu  wrote:
>
> Since kernel 4.11 already hit stretch-bpo and jessie-bpo-sloppy,
> please kindly help to update the dkms driver, too.

I uploaded with DELAYED/5-day.
And here's release commits. Thanks!

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
From 3a73d04669da99d087d1ce03eaebd84f43db1b8d Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Mon, 28 Aug 2017 22:27:46 +0900
Subject: [PATCH 1/2] Rebuild as 6.30.223.271-7~bpo9+1 for stretch-backports

---
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index f0a8680..0855b34 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+broadcom-sta (6.30.223.271-7~bpo9+1) stretch-backports; urgency=medium
+
+  * Rebuild for stretch-backports.
+
+ -- Roger Shimizu   Mon, 28 Aug 2017 22:27:06 +0900
+
 broadcom-sta (6.30.223.271-7) unstable; urgency=medium
 
   * Added 19-linux412.patch to support Linux kernel 4.12
From d7df0737d3d8fe66d5bb82b74ef53519a4577e2a Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Thu, 21 Sep 2017 00:04:35 +0900
Subject: [PATCH 2/2] Rebuild as 6.30.223.271-7~bpo8+1 for
 jessie-backports-sloppy

---
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 0855b34..5102b78 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+broadcom-sta (6.30.223.271-7~bpo8+1) jessie-backports-sloppy; urgency=medium
+
+  * Rebuild for jessie-backports-sloppy.
+
+ -- Roger Shimizu   Thu, 21 Sep 2017 00:03:34 +0900
+
 broadcom-sta (6.30.223.271-7~bpo9+1) stretch-backports; urgency=medium
 
   * Rebuild for stretch-backports.

Bug#875029: [lightdm] Future Qt4 removal from Buster

[Boyuan Yang]

X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org lisan...@debian.org

Hello,

I noticed that you are planning to remove Qt components of lightdm from 
Debian's lightdm. In fact, pkg-deepin team has a planned package that needs 
Qt5-based liblightdm-qt as (build-)dependency. See bug #871840 [1]. In case 
you might be curious, we have a dependency graph too. [3]

Ubuntu already provides liblightdm-qt5 for quite a few days with newer version 
of lightdm. I am wondering if you could take a look at lightdm package 
downstream and merge their changes. [2]

Please keep me informed about future plans of lightdm on this problem.

Regards,
Boyuan Yang

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871840
[2] https://launchpad.net/ubuntu/+source/lightdm
[3] https://anonscm.debian.org/git/pkg-deepin/pkg-deepin.git/plain/depgraph/
pkg-deepin-dep.svg

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

Bug#876299: pcre3: ftbfs on s390x, test failures

[Matthias Klose]

Package: src:pcre3
Version: 2:8.39-5
Severity: serious
Tags: sid butcher

ftbfs on s390x, test failures

/usr/bin/make check VERBOSE=1
make[1]: Entering directory '/<>'
/usr/bin/make  check-am
make[2]: Entering directory '/<>'
/usr/bin/make
make[3]: Entering directory '/<>'
/usr/bin/make  all-am
make[4]: Entering directory '/<>'
make[4]: Leaving directory '/<>'
make[3]: Leaving directory '/<>'
/usr/bin/make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: pcrecpp_unittest
PASS: pcre_scanner_unittest
PASS: pcre_stringpiece_unittest
FAIL: RunTest
PASS: RunGrepTest
=
   PCRE 8.39: ./test-suite.log
=

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: RunTest
=


PCRE C library tests using test data from ./testdata
PCRE version 8.39 2016-06-14

 Testing 8-bit library 

Test 1: Main functionality (Compatible with Perl >= 5.10)
  OK
  OK with study
Test 2: API, errors, internals, and non-Perl stuff (not UTF-8)
  OK
  OK with study
Cannot test locale-specific features - none of the 'fr_FR', 'fr' or
'french' locales exist, or the "locale" command is not available
to check for them.

Test 4: UTF-8 support (Compatible with Perl >= 5.10)
  OK
  OK with study
Test 5: API, internals, and non-Perl stuff for UTF-8 support
  OK
  OK with study
Test 6: Unicode property support (Compatible with Perl >= 5.10)
  OK
  OK with study
Test 7: API, internals, and non-Perl stuff for Unicode property support
  OK
  OK with study
Test 8: DFA matching main functionality
  OK
  OK with study
Test 9: DFA matching with UTF-8
  OK
  OK with study
Test 10: DFA matching with Unicode properties
  OK
  OK with study
Test 11: Internal offsets and code size tests
  OK
  OK with study
Test 12: JIT-specific features (when JIT is available)
  Skipped because JIT is not available or not usable
Test 13: JIT-specific features (when JIT is not available)
  OK
Test 14: Specials for the basic 8-bit library
  OK
  OK with study
Test 15: Specials for the 8-bit library with UTF-8 support
  OK
  OK with study
Test 16: Specials for the 8-bit library with Unicode propery support
  OK
  OK with study
Test 17: Specials for the basic 16/32-bit library
  Skipped when running 8-bit tests
Test 18: Specials for the 16/32-bit library with UTF-16/32 support
  Skipped when running 8-bit tests
Test 19: Specials for the 16/32-bit library with Unicode property support
  Skipped when running 8-bit tests
Test 20: DFA specials for the basic 16/32-bit library
  Skipped when running 8-bit tests
Test 21: Reloads for the basic 16/32-bit library
  Skipped when running 8-bit tests
Test 22: Reloads for the 16/32-bit library with UTF-16/32 support
  Skipped when running 8-bit tests
Test 23: Specials for the 16-bit library
  Skipped when running 8/32-bit tests
Test 24: Specials for the 16-bit library with UTF-16 support
  Skipped when running 8/32-bit tests
Test 25: Specials for the 32-bit library
  Skipped when running 8/16-bit tests
Test 26: Specials for the 32-bit library with UTF-32 support
  Skipped when running 8/16-bit tests

 Testing 16-bit library 

Test 1: Main functionality (Compatible with Perl >= 5.10)
  OK
  OK with study
Test 2: API, errors, internals, and non-Perl stuff (not UTF-16)
Segmentation fault

** Test 2 requires a lot of stack. If it has crashed with a
** segmentation fault, it may be that you do not have enough
** stack available by default. Please see the 'pcrestack' man
** page for a discussion of PCRE's stack usage.

FAIL RunTest (exit status: 1)


Testsuite summary for PCRE 8.39

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log

Makefile:2618: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[Simon Deziel]

Hi intrigeri,

On 2017-09-20 11:26 AM, intrigeri wrote:
>> My only concern is what to do when those new rules are stalled
>> waiting on review? Could they be integrated to the Debian version while
>> waiting for the official merge? If yes, I think that's the best of both
>> worlds.
> 
> For the record I generally don't wait for upstream to review'n'merge
> before I apply fixes to AppArmor policy in Debian packages I maintain:
> the "upstream first" moto does matter to me, but in practice I define
> it as "submit upstream first and then upload to Debian" rather than as
> "wait for upstream to ACK my proposed changes before fixing the
> problem our users are complaining about". So yeah, I think we can
> definitely have the best of both worlds :)
> 
> Now, wrt. Thunderbird specifically: so far, AFAIK the maintainers of
> src:icedove in Debian haven't bothered taking stuff from upstream's
> apparmor-profiles.git directly. Instead, they are kind enough to apply
> any reasonable update we (= mostly Ulrike, but I'm sure she would not
> mind if you and I gave her a hand) ask them to take.
> 
> So I would suggest we forward them any update we think should go in
> Debian, as soon as we've submitted it upstream, without waiting for
> upstream to review. Now, let's keep in mind that these changes will go
> straight to Debian *stable* in the next security upload — if I'm not
> mistaken). So perhaps a little bit of peer-review would be in order.
> For example, assuming one of us three sends a merge request to
> Launchpad, as soon as any of the other two ACKs it, we ask the
> src:icedove maintainers to take it. I.e. we piggy pack on the existing
> upstream review process and tools and save some paperwork.
> 
> Deal?

Sure works for me, thanks for proposing this sensible workflow!

Regards,
Simon

Bug#848335: Filo should be removed from Debian after Stretch release since it is unmaintained and can be replaced

[Andreas Tille]

control: reassign -1 ftp.debian.org
control: retitle -1 ROM filo

Hi ftpmasters,

as this bug log says:

   Filo should be removed from Debian after Stretch release since it is
   unmaintained and can be replaced 

So please remove this package from unstable.

Kind regards and thanks for your ftpmaster work

  Andreas.

-- 
http://fam-tille.de

Bug#855346: thunderbird: Can't open attachments with AppArmor profile enforced

[intrigeri]

Carsten Schoenert:
> On Sun, Sep 03, 2017 at 10:36:23AM +0200, intrigeri wrote:
>> By the way, IIRC Carsten told me that I could push such fixed directly
>> to the Vcs-Git. I've just tried to push my branch there, and was told:
[...]
> seems you have no access rights though.
[...]
> Should be solvable by getting access to the pkg-mozilla group on alioth.

I've just requested access :)

Bug#876298: ITP: golang-github-nightlyone-lockfile -- Handle locking via pid files

[Martin Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martín Ferrari 

* Package name: golang-github-nightlyone-lockfile
  Version : 0.0~git20170804.0.6a197d5-1
  Upstream Author : Ingo Oeser
* URL : https://github.com/nightlyone/lockfile
* License : Expat
  Programming Lang: Go
  Description : Golang library to handle locking via pid files

 Package lockfile handles pid file based locking. While a sync.Mutex helps
 against concurrency issues within a single process, this package is designed
 to help against concurrency issues between cooperating processes or
 serializing multiple invocations of the same process. You can also combine
 sync.Mutex with Lockfile in order to serialize an action between different
 goroutines in a single program and also multiple invocations of this program.

This is a new dependency for prometheus 2.0.

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[intrigeri]

Hi,

Simon Deziel:
> I think we ended up with the current situation because merge
> proposals in apparmor-profiles are not reviewed quickly enough
> (and/or I'm not patient enough).

Understood! But that should not be a blocker, see below.

> On 2017-09-03 03:01 AM, intrig...@debian.org wrote:
>> I see two options to fix this confusing situation.
>> 
>> A. Use lp:apparmor-profiles as the upstream
[...]
>> B. Use Simon's repository as the upstream
[...]

> I'm OK with A and wouldn't mind sending any new rules to the official
> repo.

Excellent, thanks a lot :)

> My only concern is what to do when those new rules are stalled
> waiting on review? Could they be integrated to the Debian version while
> waiting for the official merge? If yes, I think that's the best of both
> worlds.

For the record I generally don't wait for upstream to review'n'merge
before I apply fixes to AppArmor policy in Debian packages I maintain:
the "upstream first" moto does matter to me, but in practice I define
it as "submit upstream first and then upload to Debian" rather than as
"wait for upstream to ACK my proposed changes before fixing the
problem our users are complaining about". So yeah, I think we can
definitely have the best of both worlds :)

Now, wrt. Thunderbird specifically: so far, AFAIK the maintainers of
src:icedove in Debian haven't bothered taking stuff from upstream's
apparmor-profiles.git directly. Instead, they are kind enough to apply
any reasonable update we (= mostly Ulrike, but I'm sure she would not
mind if you and I gave her a hand) ask them to take.

So I would suggest we forward them any update we think should go in
Debian, as soon as we've submitted it upstream, without waiting for
upstream to review. Now, let's keep in mind that these changes will go
straight to Debian *stable* in the next security upload — if I'm not
mistaken). So perhaps a little bit of peer-review would be in order.
For example, assuming one of us three sends a merge request to
Launchpad, as soon as any of the other two ACKs it, we ask the
src:icedove maintainers to take it. I.e. we piggy pack on the existing
upstream review process and tools and save some paperwork.

Deal?

Cheers,
-- 
intrigeri

Bug#876297: ITP: diffview-el -- view diffs in side-by-side format

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: diffview-el
  Version : 1.0
  Upstream Author : Mitchel Humpherys 
* URL or Web page : https://github.com/mgalgs/diffview-mode
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : view diffs in side-by-side format

Render a unified diff (top/bottom) in an easy-to-comprehend side-by-side
format. This comes in handy for reading patches from mailing lists (or
from whencever you might acquire them).

Bug#795431: Fix for #795431

[Vincas Dargis]

On 2017.09.20 17:08, intrigeri wrote:

I think something like "apparmor-profiles provides […]" would solve
the problem.


OK, I will provide another patch, thanks for clarification. I though
"This" is style error in English, and this tiny change would be enough.

Bug#876296: ITP: golang-github-oklog-ulid -- Universally Unique Lexicographically Sortable Identifier (ULID) in Go

[Martin Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martín Ferrari 

* Package name: golang-github-oklog-ulid
  Version : 0.3.0+git20170117.6.66bb656-1
  Upstream Author : OK Log
* URL : https://github.com/oklog/ulid
* License : Apache-2.0
  Programming Lang: Go
  Description : Universally Unique Lexicographically Sortable Identifier 
(ULID) in Go

 A Go port of alizain/ulid (https://github.com/alizain/ulid) with binary
 format implemented.

 A ULID is a replacement for GUID/UUIDs with some useful properties:
 .
  * Lexicographically sortable.
  * Compatible with UUID/GUIDs.
  * Very fast generation.
  * Canonically encoded as a 26 character string.

This is a new dependency for prometheus 2.0.

Bug#876295: gsettings-qt: FTBFS on sparc64: test segmentation fault

[Aaron M. Ucko]

Source: gsettings-qt
Version: 0.1+16.04.20170729-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-sp...@lists.debian.org

The build of gsettings-qt for sparc64 (admittedly not a release
architecture) failed:

  make[3]: Entering directory 
'/<>/gsettings-qt-0.1+16.04.20170729/tests'
  /<>/gsettings-qt-0.1+16.04.20170729/tests/target_wrapper.sh  ./test 
 -import "/<>/gsettings-qt-0.1+16.04.20170729/tests/.."
  JIT is disabled for QML. Property bindings and animations will be very slow. 
Visit https://wiki.qt.io/V4 to learn about possible solutions for your platform.
  Segmentation fault
  Makefile:362: recipe for target 'check' failed
  make[3]: *** [check] Error 139

I don't have further details, but perhaps you can reproduce the
problem on the sparc64 porter box notker.debian.net if and when it
comes back online.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#875890: Please consider shipping /etc/apparmor.d/usr.sbin.mysqld from upstream

[intrigeri]

Hi,

Guido Günther:
> it would be great if the package would ship upstream's profile (even if
> only in complain mode like upstream does). This would help to iron out
> the issues in the profile.

I notice that mariadb-server-10.1 ships
/usr/share/mysql/policy/apparmor/usr.sbin.mysqld (that comes from
Ubuntu).

Is upstream's profile something else?

Note that Ubuntu's profiles are sometimes better suited for usage on
Debian than upstream's, especially when upstream uses a different
distro as their primary development platform. Now, of course ideally
distros would contribute to the upstream profile instead of
maintaining their own, as it's started to happen for libvirt :)

> The current file file that starts like:
> […]
> is a bit discouraging.

Indeed. FTR Ubuntu has been shipping enforced by default AppArmor
policy for MySQL since 2008, so I would expect it to be super robust
and I *guess* that it should work almost as-is for MariaDB.

Any pointer to the "several problems for users" that have been caused
by AppArmor?

Cheers,
-- 
intrigeri

Bug#876294: ruby-rblineprof: FTBFS on hurd-i386 and kfreebsd-i386: test_real fails

[Aaron M. Ucko]

Source: ruby-rblineprof
Version: 0.3.7-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

Builds of ruby-rblineprof for the non-release architectures hurd-i386
and kfreebsd-i386 (but for whatever reason not any other architectures,
even i386 or kfreebsd-amd64) have been failing:

  LineProfTest: 
test_cpu:   .: (0.01)
test_method:
.: (1.00)
test_objects:   
.: (0.00)
test_real:  
F
  
===
  Failure:
<1000> -/+ <600> was expected to include
<1>.

Relation:
<<1000>-<600>[400.0] <= <1000>+<600>[1600.0] < <1>>
  test_real(LineProfTest)
  /<>/test/test_lineprof.rb:12:in `test_real'
9: end
   10: 
   11: line = profile[__FILE__][__LINE__-3]
=> 12: assert_in_delta 1000, line[0], 600
   13: assert_equal 1, line[2]
   14:   end
   15: 
  
===

(Above output from hurd-i386; kfreebsd-i386 is similar, but line[0] is
1996 there and the timing details of course vary.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#870906: ITP: pynmea2 - pynmea2 is a python library for the NMEA 0183 protocol

[Joachim Langenbach]

Hi Herbert,

thanks for your hints. Hopefully this time, I got all of them ;-) I have some 
questions related to some of your hints:

> There are some adjusts to do:
> 
> debian/compat:
> 
> - instead of '9' put '10' (number only)
> 
> debian/control:
> 
>  - Build-Depends entry: python3-all-dev can be removed.
>'cowbuilder' builds the package without it.
>  - lintian needs an update. You can put '4.1.0'.

I only found 4.0.1 (at 
https://www.debian.org/doc/debian-policy/upgrading-checklist.html). Are there 
any other sources to find the most recent standards 
version? However, I used 4.1.0 in my new upload.

>  - Testsuite can be removed. There is no 'debian/tests' dir.

I added the testsuite, because it should run the python tests included in 
pynmea2 sources. Did I understand testsuite the wrong way here? (Removed it in 
my upload)

Regards,

Joachim

>  - Architecture: should be 'all'. (any is for programs like C, C++)
>  - Depends entry: '${shlibs:Depends}' can be removed.
>  - Provides entry can be removed.
> 
> debian/copyright:
> 
> - Debian entry is missing. The file should look like this:
> 
>  Files: *
>  Copyright: (C) 2013-2017 Tom Flanagan 
>  License: MIT
> 
>  Files: debian/*
>  Copyright: 2017 Your-name-here ||
>  License: Choose-one (usually upstream choice)
> 
>  License: MIT
>  Permission is hereby granted, free of charge, to any person obtaining
>  blababla
> 
>  License: (If you choose something different add here)
>  blablabla
>  a copy of this software and associated documentation files
> 
> 
> debian/rules:
>  
> - I said about cleaning SOÛRCES.txt. You did right. But
>   I learned something that looks better. Instead of an
>   override_dh_auto_clean, 'egg-info' can be ignored if
>   we use 'debian/source/options' file. One line in the
>   file:
> |
> 
>  extend-diff-ignore="^[^/]+\.egg-info/"
> 
> | 
> 
>   Just in case, please see:
>  
> https://anonscm.debian.org/cgit/debian-science/packages/python-meshio.git/t
> ree/debian/source/options
> 
> 
> That's it. Let me know when you when the package
> is ready.
> 
> 
> 
> regards,
> Herbert



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

Bug#876293: postgresql-common: pg_upgradecluster needs to copy wal_level earlier

[Magnus Hagander]

Package: postgresql-common
Version: 184.pgdg90+1
Severity: important

For the link based method to upgrade standby servers, wal_level needs to be set
to replica *before* pg_upgrade is run on the cluster (but after initdb).
pg_upgradecluster currenlty copies the settings file over *after* the pg_upgrade
command has finished.

I think the best way to deal with this is to have pg_upgradecluster specifically
copy the setting for wal_level between the call to initdb and the call to
pg_upgrade. Another way could be to include it in the call to pg_createcluster.

Putting a small script in /etc/postgresql-common/pg_upgradecluster.d to run at
the init step to edit the configfile and replace the wal_level parameter fixes
the probem, so doing it at the same place as the init step is a working 
position.
However, it should of course not be needed to put a script in for such basic
functionality.

Finally, I believe that this requirement should only affect PostgreSQL <10, 
since
the defualt wal_level has changed there. I hvae not verified this part of the
claim.


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

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

Versions of packages postgresql-common depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
ii  init-system-helpers   1.48
ii  lsb-base  9.20161125
ii  postgresql-client-common  184.pgdg90+1
ii  procps2:3.3.12-3
ii  ssl-cert  1.0.39
ii  ucf   3.0036

Versions of packages postgresql-common recommends:
ii  logrotate  3.11.0-0.1

Versions of packages postgresql-common suggests:
ii  libjson-perl  2.90-1

-- debconf information excluded