Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field

[Ben Finney]

On 20-Aug-2017, Sean Whitton wrote:
> - please strip the rewordings that you've made to other parts of the
>   document, so this patch addresses this bug alone.
> 
>   If you want to make those changes, please file separate 'informative'
>   bugs against debian-policy; these do not need to be seconded and are
>   applied at the discretion of the policy editors.

Done, reported as bug#874090.

-- 
 \ “[T]he question of whether machines can think … is about as |
  `\ relevant as the question of whether submarines can swim.” |
_o__)  —Edsger W. Dijkstra |
Ben Finney 


signature.asc
Description: PGP signature

Bug#874093: RM: debian-zh-faq -- ROM; unmaintained; dead upstream

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org

The native debian package debian-zh-faq is long unmaintained and recently
orphaned by original uploader (this package is team-maintained in Debian
Chinese Team). The content of the document is largely useless.

As per previous announcement in Chinese Team, we intend to remove this package
from the archive now. [1]

There are no hard reverse dependencies for the package; tasksel recommends it
from Chinese tasks and I will file bugs to remove it soon (not a blocker).

source package: debian-zh-faq
binary packages: debian-zh-faq-s debian-zh-faq-t

% LANG=C apt rdepends debian-zh-faq-s
debian-zh-faq-s
Reverse Depends:
Recommends: task-chinese-s

% LANG=C apt rdepends debian-zh-faq-t
debian-zh-faq-t
Reverse Depends:

[1] https://lists.debian.org/debian-chinese-gb/2017/08/msg00015.html

Regards,
Boyuan Yang

Bug#874091: ITP: ruby-peek-redis -- Provide a peek into the Sidekiq calls made within your Rails application.

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

from rubygems.org/gems/peek-sidekiq
dependency of gitlab 9.5













signature.asc
Description: OpenPGP digital signature

Bug#874092: RFS: flake8-docstrings/1.1.0-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: flake8-docstrings
  Version : 1.1.0-1
  Upstream Author : Simon Andre and Ian Cordasco
* URL : https://gitlab.com/pycqa/flake8-docstrings
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/git/python-modules/packages/flake8-docstrings.git

Changes since the last upload:

  * Initial release. (Closes: #864527)

Regards,
Ghis

Bug#874090: debian-policy: Clarify wording of some passages

[Ben Finney]

Package: debian-policy
Version: 4.1.0.0
Severity: minor
Tags: patch

Howdy all,

I have made some minor clarifying changes while working on another bug
report.

These changes do not have any substantive effect on the intended
meaning of the passages, only to clarity of expression.

The output of ‘git request-pull’ for these changes:

=
The following changes since commit b9684c285afd148b102fc76f566175712cbfacac:

  in Testsuite:, add hints to explain some terminology (2017-09-02 08:25:56 
-0700)

are available in the git repository at:

  bign...@git.debian.org:public_git/debian-full/debian-policy.git 
wip/maintenance/wording-clarifications

for you to fetch changes up to 1bf68292ff9f8617a79d974a54a9e58372644d3e:

  Clarify a potential contradiction in which files have what license. 
(2017-09-03 14:24:36 +1000)


(from the branch description for wip/maintenance/wording-clarifications local 
branch)

Clarify and re-word some passages.


Ben Finney (6):
  Separate some longer passages into paragraphs.
  Link terms to their definitions.
  Clarify “makes no sense” by instead stating why it is not acceptable.
  Correct reference specifically to fields in a paragraph.
  Use tighter phrasing of copyright holders and license grant.
  Clarify a potential contradiction in which files have what license.

 copyright-format-1.0.xml | 117 ---
 1 file changed, 69 insertions(+), 48 deletions(-)
=

-- 
 \   “I have a map of the United States; it's actual size. It says |
  `\‘1 mile equals 1 mile’. Last summer, I folded it.” —Steven |
_o__)   Wright |
Ben Finney 
From 06a043b3c8edf7765d3dc9b469aed8d467e0cfbb Mon Sep 17 00:00:00 2001
From: Ben Finney 
Date: Sun, 3 Sep 2017 14:23:55 +1000
Subject: [PATCH 1/6] Separate some longer passages into paragraphs.

---
 copyright-format-1.0.xml | 91 
 1 file changed, 54 insertions(+), 37 deletions(-)

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index 2eef301b..e40a710a 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -167,12 +167,16 @@
   
 Formatted text fields use the same rules as the long description
 in a package's Description field in Debian
-control files.  In some but not all cases, the first line may have
-special meaning as a synopsis, similar to how the
-Description field uses the first line for the
-short description. See Debian Policy's section 5.6.13, 
+  
+In some but not all cases, the first line may have special
+meaning as a synopsis, similar to how the
+Description field uses the first line for
+the short description. See Debian Policy's section 5.6.13,
+https://www.debian.org/doc/debian-policy/ch-controlfields#s-f-Description;>Description,
-for details.  For example, Disclaimer is a
+for details. For example, Disclaimer is a
 formatted text field that has no special first line, and
 License is a formatted text field where the
 first line indicates the short name or names of the licenses.
@@ -246,16 +250,22 @@
   
 The Copyright and License
 fields in the header paragraph may complement
-but do not replace the Files paragraphs.  If
+but do not replace the Files paragraphs. If
 present, they summarise the copyright notices or redistribution
-terms for the package as a whole.  For example, when a work
-combines a permissive and a copyleft license,
-License can be used to clarify the license
-terms for the combination.  Copyright and
-License together can also be used to document a
-compilation copyright and license.  It is
-possible to use only License in the header
-paragraph, but Copyright alone makes no sense.
+terms for the package as a whole.
+  
+  
+For example, when a work has a grant of license under both a
+permissive and a copyleft license, License can
+be used to clarify the license terms for the combination.
+Copyright and License
+together can also be used to document a compilation
+copyright and license.
+  
+  
+It is valid to use License in the header
+paragraph without an accompanying Copyright
+field, but Copyright alone makes no sense.
   
 
   
@@ -320,7 +330,8 @@ License: GPL-3+
 
 Files: */*.1
 Copyright: 2010 Manuela Manpager
-License: GPL-2+
+License: GPL-2+
+
 
   In this example, all files are copyright by the upstream and licensed
   under the GPL, version 2 or later, with three 

Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more

[Paul Hardy]

Chris,

On Sat, Sep 2, 2017 at 1:41 PM, Chris Lamb  wrote:
> Paul,
>
>> Oh, I see.  Personally, my only concern was that a lintian error would
>> prevent an uploaded, released package from migrating to testing.
>
> Hm? Lintian has no effect on migrations from unstable to testing.

I never knew that, mainly because I never tried getting a package
uploaded in that state.  The whole thing caught me off guard.

> ...
> See #870722. This was fixed in 4th August in:
>
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=126157380dc0eba302f3d476b1cffc13f968c207

That is great.  The next lintian release should be able to close this
bug then, unless Stefan disagrees.

Thank you!


Paul Hardy

Bug#874089: ITP: pipewire -- libraries for the PipeWire multimedia server

[Jeremy Bicha]

On Sat, Sep 2, 2017 at 10:33 PM, Jeremy Bicha  wrote:
> PipeWire [1] is an optional dependency of mutter 3.26 to enable
> experimental Remote Desktop support in GNOME on Wayland.

https://wiki.gnome.org/Projects/Mutter/RemoteDesktop

Thanks,
Jeremy Bicha

Bug#874089: ITP: pipewire -- libraries for the PipeWire multimedia server

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: jbi...@ubuntu.com

Package Name: pipewire
Version: 0.1.4
Upstream Author : Wim Taymans
License : LGPL-2+
Programming Lang: C

Description: libraries for the PipeWire multimedia server - documentation
 PipeWire is a server and user space API to deal with multimedia
 pipelines. This includes:

 - Making available sources of video (such as from a capture devices or
   application provided streams) and multiplexing this with clients.
 - Accessing sources of video for consumption.
 - Generating graphs for audio and video processing.

Other Info
--
PipeWire [1] is an optional dependency of mutter 3.26 to enable
experimental Remote Desktop support in GNOME on Wayland. But its
ambitions are greater: "PipeWire now aims at unifying linux Audio and
Video." [2]

The author gave a talk recently at GUADEC about PipeWire. [3]

The Debian GNOME team intends to maintain this package.

Work-in-progress packaging is at
https://anonscm.debian.org/git/pkg-gnome/pipewire.git

[1] https://github.com/wtay/pipewire/
[2] https://blogs.gnome.org/uraeus/2017/06/20/fedora-workstation-26-and-beyond/
[3] https://2017.guadec.org/talks-and-events/#abstract-opentalk8-pipewire

Thanks,
Jeremy Bicha

Bug#874088: sddm: cannot log in as root

[William Melgaard]

Package: sddm
Version: 0.14.0-4
Severity: serious
Tags: security
Justification: Policy 2.5

Dear Maintainer,

apt-get dist-upgrade from jessie to stretch, followed by synaptic package
manager installation of sddm-theme-elarun provided a splash screen with a blank
block for user.
Providing "root" as the user, with appropriate password did not result in a
login.

Double check of /etc/kde4/kdm/kdmrc found AllowRootLogin=true

Inability to log in as root qualifies as "important" in accordance with the
Debian policy manual section 2.5.




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

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

Versions of packages sddm depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libpam0g  1.1.8-3.6
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5qml55.7.1-2+b2
ii  libqt5quick5  5.7.1-2+b2
ii  libstdc++66.3.0-18
ii  libsystemd0   232-25+deb9u1
ii  libxcb-xkb1   1.12-1
ii  libxcb1   1.12-1
ii  qml-module-qtquick2   5.7.1-2+b2
ii  x11-common1:7.7+19
ii  xserver-xephyr [xserver]  2:1.19.2-1+deb9u1
ii  xserver-xorg [xserver]1:7.7+19

Versions of packages sddm recommends:
ii  libpam-systemd 232-25+deb9u1
ii  sddm-theme-debian-elarun [sddm-theme]  0.14.0-4
ii  sddm-theme-debian-maui [sddm-theme]0.14.0-4

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.8.4-1

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#874087: dummydroid: no documentation as to how to make hardware profiles

[shirish शिरीष]

Package: dummydroid
Version: 1.2-1
Severity: normal

Dear Maintainer,

Using dpkg -L dummydroid was able to find out about couple of hardware
profiles given as examples, namely -

/usr/share/doc/dummydroid/examples/ASUS_ZenFone2_x86.prop
/usr/share/doc/dummydroid/examples/Azpen_A727.prop
/usr/share/doc/dummydroid/examples/Google_Nexus_5_Copperhead.prop
/usr/share/doc/dummydroid/examples/Google_Nexus_6.prop
/usr/share/doc/dummydroid/examples/Motorola_Moto_G_1st_gen.prop.gz
/usr/share/doc/dummydroid/examples/Samsung_Galaxy_Note_2_CyanogenMod.prop

Could you provide some information to figure out how to fill in these
profiles and more importantly how to run with those profiles.

Having no manpages severly impinges how the application can be used by
a regular joe.

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

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

Versions of packages dummydroid depends on:
ii  default-jre [java8-runtime]2:1.8-59
ii  jarwrapper 0.61
ii  libhttpclient-java 4.5.3-1
ii  libhttpcore-java   4.4.6-1
ii  openjdk-8-jre [java8-runtime]  8u141-b15-3

dummydroid recommends no packages.

dummydroid suggests no packages.

-- no debconf information

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

Bug#874086: lugaru: often crashes on exit (SIGSEGV)

[Paul Wise]

Package: lugaru
Version: 1.2-1
Severity: normal
Usertags: crash

I often (but not always) get crashes on exit from lugaru, for example:

$ lugaru 
--
Lugaru HD: The Rabbit's Foot, by Wolfire Games and the OSS Lugaru project.

Licensed under the GPL 2.0+ and CC-BY-SA 3.0 and 4.0 licenses.
More information, updates and bug reports at http://osslugaru.gitlab.io

Version 1.2 [Debian 1.2-1] -- None build
--

Loading config
Loading 1 accounts
Loading account 0/1
writing account 1/1 (pabs)
AL lib: (EE) alc_cleanup: 1 device not closed
Segmentation fault (core dumped)
$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/1000/15301-1000-1000-11-1504402229-chianamo--usr-games-lugaru.core 
/usr/games/lugaru
[New LWP 15329]
[New LWP 15328]
[New LWP 15301]
Core was generated by `lugaru'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  _mm_store_ps (__A=..., __P=0x7fb8d3019000) at 
/usr/lib/gcc/x86_64-linux-gnu/6/include/xmmintrin.h:973

warning: Source file is more recent than executable.
973   *(__v4sf *)__P = (__v4sf)__A;
[Current thread is 1 (LWP 15329)]
#0  _mm_store_ps (__A=..., __P=0x7fb8d3019000) at 
/usr/lib/gcc/x86_64-linux-gnu/6/include/xmmintrin.h:973
#1  SetupCoeffs (Counter=0, IrSize=22022, hrtfparams=, 
OutCoeffs=0x7fb8d3017770) at ./Alc/mixer_sse.c:87
#2  MixHrtf_SSE (OutBuffer=0x56066a9a2ba0, data=0x56066a99aba0, Counter=0, 
Offset=752640, OutPos=0, IrSize=22022, hrtfparams=0x0, hrtfstate=0x0, 
BufferSize=0) at ./Alc/mixer_inc.c:34
#3  0x in ?? ()

Thread 3 (LWP 15301):
#0  0x7fb8d7694468 in _fini () from 
/usr/lib/x86_64-linux-gnu/libsndfile.so.1
No symbol table info available.
#1  0x7fb8dfc98e88 in _dl_fini () at dl-fini.c:240
l = 0x7fb8dfe65ed8
maps = 0x7ffe37c33670
i = 
l = 
nmaps = 
nloaded = 
ns = 0
do_audit = 
__PRETTY_FUNCTION__ = "_dl_fini"
#2  0x7fb8ddb26940 in __run_exit_handlers (status=0, listp=0x7fb8dde885d8 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:83
atfct = 
onfct = 
cxafct = 
f = 
#3  0x7fb8ddb2699a in __GI_exit (status=) at exit.c:105
No locals.
#4  0x7fb8ddb112e8 in __libc_start_main (main=0x56066872a8b0 , argc=1, argv=0x7ffe37c33a88, init=, fini=, rtld_fini=, stack_end=0x7ffe37c33a78) at 
../csu/libc-start.c:325
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -932282033704220143, 
94585522147200, 140729833962112, 0, 0, -6845646354732758511, 
-6885242910918915567}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 
0x7ffe37c33a98, 0x7fb8dfeae170}, data = {prev = 0x0, cleanup = 0x0, canceltype 
= 935541400}}}
not_first_call = 
#5  0x56066872cfaa in _start ()
No symbol table info available.

Thread 2 (LWP 15328):
#0  0x7fb8ddbd066d in poll () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x7fb8dcb87c91 in poll (__timeout=10, __nfds=3, __fds=0x56066a8b6f20) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
No locals.
#2  poll_func (ufds=0x56066a8b6f20, nfds=3, timeout=10, 
userdata=0x56066a94) at pulse/thread-mainloop.c:69
mutex = 0x56066a94
#3  0x7fb8dcb794a1 in pa_mainloop_poll (m=m@entry=0x56066a940070) at 
pulse/mainloop.c:844
__func__ = "pa_mainloop_poll"
__PRETTY_FUNCTION__ = "pa_mainloop_poll"
#4  0x7fb8dcb79b3e in pa_mainloop_iterate (m=0x56066a940070, 
block=, retval=0x0) at pulse/mainloop.c:926
r = 0
#5  0x7fb8dcb79bf0 in pa_mainloop_run (m=0x56066a940070, 
retval=retval@entry=0x0) at pulse/mainloop.c:944
r = 
#6  0x7fb8dcb87bd9 in thread (userdata=0x56066a8bce70) at 
pulse/thread-mainloop.c:100
m = 0x56066a8bce70
mask = {__val = {18446744067267100671, 18446744073709551615 }}
prev_mask = {__val = {0, 140432005233812, 5, 0, 0, 140431970011024, 
140431787650368, 140432005264287, 8825501086245354106, 8825501086245354106, 
7959303351591398243, 7882826979255612277, 7308602655095616878, 
32487697137033837, 7809924986204808562, 8439809899347272559}}
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0, 5, 0, 1, 140432007193536, 94585557926048, 0, 0, 
140432007194392, 140431787649904, 7997987660, 140432007193536, 140431787649888, 
140431963451630, 2296172972, 4294967295}}, sa_flags = 0, sa_restorer = 0x0}
#7  0x7fb8d903c2c8 in internal_thread_func (userdata=0x56066a8bc910) at 
pulsecore/thread-posix.c:81
t = 0x56066a8bc910
#8  0x7fb8dd4c3494 in start_thread (arg=0x7fb8d2d17700) at 
pthread_create.c:333
__res = 
pd = 0x7fb8d2d17700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140431787652864, 
6846332829884008977, 0, 

Bug#868488: RFS: sokochez/0.6.2-1 ITP

[Adam Borowski]

Please keep 868...@bugs.debian.org in To: or CC: so there's a record of
review done and that others can chime in too.

On Sat, Sep 02, 2017 at 10:24:43PM +0200, Baptiste Pouget wrote:
> Thank you for your help !
> I now have fixed the issues you mentionned.
> Is there any issue left or is my package ready ?

There's no manpage for sokochez-story, nor a hint what's the difference
between it and sokochez.

And, how do you even run it?  No matter what options I give to it, the
result is:
[~]$ sokochez /usr/share/games/sokochez/maps/clear/nivoo.txt 
Sokochez Help
Usage : [flags] level[s]
-e : editor mode 
-h : print help 

Changing
bool editor;
bool help;
to
bool editor = 0;
bool help = 0;
makes it at least start, but I did not pore over the code to see what other
uninitialized variables you might have.

As the package doesn't work when built using the packaging you provided --
have you ever tested it?

None of provided documentation suggests what the game's objective is nor
what are its rules are.

The package's description could use some fleshing out -- at least mentioning
the user interface (curses-like) would be good.  I'd also change the wording
of "two players game" -- it suggests it's meant to be played by two people
while the puzzle instead has two player-controlled characters.


But in general -- while the packaging is not far from being acceptable, the
contents don't strike me as very useful in the present shape.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#842432: ruby2.3 security update

[Antonio Terceiro]

Hello,

On Wed, Nov 16, 2016 at 02:48:03AM +0100, Christian Hofstaedtler wrote:
> Hi,
> 
> * Salvatore Bonaccorso  [161116 01:46]:
> > Source: ruby2.3
> > [...]
> > [0] https://security-tracker.debian.org/tracker/CVE-2016-7798
> > [1] https://github.com/ruby/openssl/issues/49
> > [2] 
> > https://github.com/ruby/openssl/commit/8108e0a6db133f3375608303fdd2083eb5115062
> 
> I'm attaching a potential patch against ruby2.3 2.3.2. Any review
> would be most welcome.

On Fri, Jun 16, 2017 at 09:17:37AM +0200, Salvatore Bonaccorso wrote:
> Source: ruby2.3
> Version: 2.3.3-1
> Severity: important
> Tags: upstream security patch
> 
> Hi,
> 
> the following vulnerability was published for ruby2.3.
> 
> CVE-2015-9096[0]:
> | Net::SMTP in Ruby before 2.4.0 is vulnerable to SMTP command injection
> | via CRLF sequences in a RCPT TO or MAIL FROM command, as demonstrated
> | by CRLF sequences immediately before and after a DATA substring.
> 
> 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-2015-9096
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9096
> [1] 
> https://github.com/ruby/ruby/commit/0827a7e52ba3d957a634b063bf5a391239b9ffee

On Thu, Aug 31, 2017 at 12:15:00PM +0200, Raphael Hertzog wrote:
> Source: ruby2.3
> X-Debbugs-CC: t...@security.debian.org 
> secure-testing-t...@lists.alioth.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> the following vulnerabilities were published for ruby2.3. They affect rubygems
> more specifically.
> 
> CVE-2017-0902[0]:
> DNS issue
> 
> CVE-2017-0901[1]:
> overwrite any file
> 
> CVE-2017-0900[2]:
> query command
> 
> CVE-2017-0899[3]:
> ANSI escape issue
> 
> Some patches are available here:
> https://www.ruby-lang.org/en/news/2017/08/29/multiple-vulnerabilities-in-rubygems/
> 
> The fixes should also be available in (upcoming) ruby 2.3.5 and ruby 2.4.2.
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2017-0902
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0902
> [1] https://security-tracker.debian.org/tracker/CVE-2017-0901
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0901
> [2] https://security-tracker.debian.org/tracker/CVE-2017-0900
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0900
> [3] https://security-tracker.debian.org/tracker/CVE-2017-0899
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0899
> 
> Please adjust the affected versions in the BTS as needed.

On Fri, Sep 01, 2017 at 07:24:24AM +0200, Salvatore Bonaccorso wrote:
> Source: ruby2.3
> Version: 2.3.3-1
> Severity: grave
> Tags: upstream patch security
> 
> Hi,
> 
> the following vulnerability was published for ruby2.3.
> 
> CVE-2017-14064[0]:
> | Ruby through 2.2.7, 2.3.x through 2.3.4, and 2.4.x through 2.4.1 can
> | expose arbitrary memory during a JSON.generate call. The issues lies in
> | using strdup in ext/json/ext/generator/generator.c, which will stop
> | after encountering a '\0' byte, returning a pointer to a string of
> | length zero, which is not the length stored in space_len.
> 
> 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-14064
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14064
> [1] https://bugs.ruby-lang.org/issues/13853
> [2] 
> https://github.com/flori/json/commit/8f782fd8e181d9cfe9387ded43a5ca9692266b85


I have prepared an updated ruby2.3 package that handles all of the above
issues, which are all pending security bugs in the BTS. Package builds
fine and autopkgtest passes, what is good because all of the patches
applied include automated tests for the issues they fix.

Attached you will find a full diff between the version in stretch and
the one I intend to upload, plus the individual patches for your
convenience. Security team: I'm waiting on your ACK.

Fixing this in unstable/buster will take longer, because the current
version there does not build with GCC 7. Take into account that ruby2.3
won't be shipped in buster anyway, it will only stay there until we
transition to ruby2.5.
diff --git a/debian/changelog b/debian/changelog
index 01d9695b..068662c7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,32 @@
+ruby2.3 (2.3.3-1+deb9u1) stretch-security; urgency=high
+
+  * Fix arbitrary heap exposure problem in the JSON library (Closes: #873906)
+[CVE-2017-14064]
+- Backported for Ruby 2.3 by Hiroshi SHIBATA 
+  https://bugs.ruby-lang.org/issues/13853
+  * Fix multiple 

Bug#874085: =======> UNRECOGNIZED OPTION: U <=======

[積丹尼 Dan Jacobson]

Package: smartmontools
Version: 6.5+svn4324-1
File: /etc/smartd.conf

# grep -- -U /etc/smartd.conf
#/dev/sdc -H -C 0 -U 0 -m ad...@example.com
#   -U ID   Report if Offline Uncorrectable count non-zero
#   -a  Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198
# except for -C and -U, where ID = 0 turns them off.

# journalctl|egrep -- -U\|' U '
Sep 03 08:52:09 jidanni6 systemd[392]: smartd.service: Executing: 
/usr/sbin/smartd -n -U 198+
Sep 03 08:52:10 jidanni6 smartd[392]: ===> UNRECOGNIZED OPTION: U <===

# smartd -h|grep -c -- -U
0

Bug#763822: distributing .buildinfo files (Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master)

[Paul Wise]

On Sat, 2017-09-02 at 21:48 +, Holger Levsen wrote:

> > So I suppose we talk about 13 GB[1] of static content in about 1.7M
> > files. Is that something that could be distributed through
> > static.debian.org if there are concerns around inodes for the main
> > mirrors? Given that they would be accessed mostly rarely[2]?
> > 
> > [1] 7.7kB (75%ile as mentioned in the referenced bug) * 55000 binary
> > packages * 10 architectures * 3 versions - so quite conservatively

I had a quick look at the (currently) 4 systems behind static.d.o and
it looks like they can all take the extra space and inodes. senfter
only has 48GB space left but we can expand the storage there.
mirror-csail only has 64M inodes available, but should be fine.

One concern might be the rsync time for 1.7M inodes, I'm not sure if
our static setup does sites in parallel.

There might be other factors here that I'm not aware of, hopefully
other DSA folks can fill them in.

Are these files going to only be available for the versions of packages
that exist in the archive right now, or is it going to be a historical
archive of all Debian build information forever?
paralel
What kind of growth per year are we expecting?

> using static.debian.org seems to be a good idea to me, what would be needed 
> to make
> this happen?

Some patches to files in dsa-puppet to define the service:

modules/roles/manifests/static_mirror.pp
modules/roles/misc/static-components.yaml
modules/roles/templates/static-mirroring/vhost/static-vhosts-simple.erb
modules/sudo/files/sudoers

https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/

> or, we could put them in a git repo instead, and use git.debian.org…

It strikes me as quite a lot of data for one git repo :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#857123: lintian: warning about missing classpath is confusing

[Markus Koschany]

Control: tags -1 - moreinfo

Hey,

I am the bug reporter and asked that question, so I'm not quite sure
what else is needed to resolve this issue.

I don't see the point in keeping the check in its current state, so
better remove it for now until someone who really works with Java
packages comes up with a better plan.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#867730: Fwd: Bug#867730 closed by Hans-Christoph Steiner <h...@eds.org> (Bug#867730: fixed in dummydroid 1.2-1)

[Phil Morrell]

Dear maintainer,

Thank you for fixing the issue I reported with a new upload.

Given the package is completely unusable in Stretch, I was intending
to ask you to provide a backport, or perhaps a -proposed-updates
targeted patch. However, when I looked into the release notes for v1.2
[Let there be hackjob], I'm concerned that would be impossible and I
wonder if a removal from stable is more appropriate?

[Let there be hackjob]:
http://blog.onyxbits.de/let-there-be-hackjob-dummydroid-updated-646/

> DummyDroid v1.2 is a case of “it compiles, ship it”. Cobbled together by
> merging in some code from Raccoon, compiled by guessing how the
> build process was suppose to work, using a source tree that’s in disarray
--
Phil Morrell

Bug#868673: sqldeveloper-package: diff for NMU version 0.2.4+nmu1

[Phil Morrell]

Hello Michael,

As the last upload sponsor for sqldeveloper-package (though admittedly
in 2012), would you consider sponsoring the NMU I prepared?

It's a targeted fix for #868673 which makes it unusable in Stretch. If
possible I'd also like it in stretch-proposed-updates, presumably only
after it's reached testing?
--
Phil Morrell

Bug#874081: borgbackup: Won't start: ImportError: /usr/lib/python3/dist-packages/borg/crypto.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf

[Gianfranco Costamagna]

control: reassign -1 src:python3.5
control: forcemerge -1 873921

G.

On Sun, 3 Sep 2017 00:21:31 +0300 Sami Liedes  wrote:
> Package: borgbackup
> Version: 1.0.11-3
> Severity: normal
> 
> Merely starting borg after upgrading to python3.5 3.5.4-3 fails:
> 
> 
> $ borg
> Traceback (most recent call last):
>   File "/usr/bin/borg", line 11, in 
> load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 564, 
> in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2662, 
> in load_entry_point
> return ep.load()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, 
> in load
> return self.resolve()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2322, 
> in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in 
> from .helpers import Error, location_validator, archivename_validator, 
> format_line, format_time, format_file_size, \
>   File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in 
> from . import crypto
> ImportError: 
> /usr/lib/python3/dist-packages/borg/crypto.cpython-35m-x86_64-linux-gnu.so: 
> undefined symbol: PyFPE_jbuf
> 
> 
> I believe this is related to this change in python3.5:
> 
> 
> python3.5 (3.5.4-3) unstable; urgency=medium
> 
>   * Stop building the fpectl extension.
>   * Break python3-numpy (<< 1:1.12.1-3.1), referencing the now missing fpectl
> modules. Addresses: #873791.
> 
>  -- Matthias Klose   Thu, 31 Aug 2017 14:22:39 +0200
> 
> 
> There is a mail on debian-python about this change, expecting possible
> breakage:
> 
>https://lists.debian.org/debian-python/2017/09/msg0.html
> 
>   Sami
> 
> 
> -- 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.7 (SMP w/8 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.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 borgbackup depends on:
> ii  fuse   2.9.7-1



signature.asc
Description: OpenPGP digital signature

Bug#874084: linux-image-4.9.0-3-armmp-lpae: fails to boot on Olimex A20

[Lucas Nussbaum]

Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: important

Hi,

This kernel fails to boot on a Olimex A20 board.

The HDMI output just runs black. I tried to use netconsole but it's in too
early boot. I don't have a serial console for that device.  I'll try to make a
video recording of the output tomorrow. (it was unreadable without using
boot_delay)

The jessie 3.16 kernel worked fine.
Kernel 3.10 failed to boot with the same(?) problem.
Kernel 3.11 and 3.12 worked fine.

- Lucas


Here is the output of a *successful* boot with kernel 4.12:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.12.0-1-armmp-lpae 
(debian-ker...@lists.debian.org) (gcc version 6.4.0 20170805 (Debian 6.4.0-3) ) 
#1 SMP Debian 4.12.6-1 (2017-08-12)
[0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: Olimex A20-OLinuXino-LIME2
[0.00] Memory policy: Data cache writealloc
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 16 MiB at 0x7f00
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c10ea400, node_mem_map 
ef6f9000
[0.00]   DMA zone: 1728 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] psci: probing for conduit method from DT.
[0.00] psci: Using PSCI v0.1 Function IDs from DT
[0.00] percpu: Embedded 17 pages/cpu @ef6bc000 s37772 r8192 d23668 
u69632
[0.00] pcpu-alloc: s37772 r8192 d23668 u69632 alloc=17*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260416
[0.00] Kernel command line: console=ttyS0,115200 console=tty0 fb=false
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 990340K/1048576K available (8192K kernel code, 1044K 
rwdata, 2380K rodata, 2048K init, 337K bss, 41852K reserved, 16384K 
cma-reserved, 245760K highmem)
[0.00] Virtual kernel memory layout:
   vector  : 0x - 0x1000   (   4 kB)
   fixmap  : 0xffc0 - 0xfff0   (3072 kB)
   vmalloc : 0xf080 - 0xff80   ( 240 MB)
   lowmem  : 0xc000 - 0xf000   ( 768 MB)
   pkmap   : 0xbfe0 - 0xc000   (   2 MB)
   modules : 0xbf00 - 0xbfe0   (  14 MB)
 .text : 0xc0008000 - 0xc0a0   (10208 kB)
 .init : 0xc0e0 - 0xc100   (2048 kB)
 .data : 0xc100 - 0xc11052c4   (1045 kB)
  .bss : 0xc110c9e8 - 0xc1160f70   ( 338 kB)
[0.00] ftrace: allocating 30750 entries in 91 pages
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 
4398046511097ns
[0.21] Switching to timer-based delay loop, resolution 41ns
[0.002218] clocksource: timer: mask: 0x max_cycles: 0x, 
max_idle_ns: 79635851949 ns
[0.003087] clocksource: hstimer: mask: 0x max_cycles: 0x, 
max_idle_ns: 12741736309 ns
[0.003912] Console: colour dummy device 80x30
[0.004554] console [tty0] enabled
[0.004602] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 48.00 BogoMIPS (lpj=96000)
[0.004646] pid_max: default: 32768 minimum: 301
[0.004930] Security Framework initialized
[0.004965] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.005023] AppArmor: AppArmor disabled by boot time parameter
[0.005124] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.005153] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.006149] CPU: Testing write buffer coherency: ok
[0.006616] /cpus/cpu@0 missing clock-frequency property
[0.006659] /cpus/cpu@1 missing clock-frequency property
[0.006689] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.007192] Setting up static identity map for 0x4020 

Bug#869968: erlang-lager: FTBFS on alpha, hurd-i386, kfreebsd-amd64 and sparc64 due to failing eunit tests

[Philipp Huebner]

> several different eunit tests fail on some of the ports,
> namely alpha, hurd-i386, kfreebsd-amd64, and sparc64, due to failing eunit
> tests, see
> https://buildd.debian.org/status/package.php?p=erlang-lager=sid

Meanwhile the build on sparc64 has succeeded for some reason.

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



signature.asc
Description: OpenPGP digital signature

Bug#763822: distributing .buildinfo files (Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master)

[Holger Levsen]

On Mon, Jul 03, 2017 at 07:23:29PM +0200, Philipp Kern wrote:
> > Not yet.  We people from the reproducible team couldn't find a way to
> > usefully talk to ftp-masters people, whom never replied to any of the
> > questions in the thread at #763822 (they only did some quick comments on
> > IRC, and we have been left on guessing what they would like…).
> > 
> > Anyhow, .buildinfo files are stored in ftp-master, just not exported to
> > the mirrors, you can find them in
> > coccia.debian.org:/srv/ftp-master.debian.org/.
> 
> So I suppose we talk about 13 GB[1] of static content in about 1.7M
> files. Is that something that could be distributed through
> static.debian.org if there are concerns around inodes for the main
> mirrors? Given that they would be accessed mostly rarely[2]?
> 
> [1] 7.7kB (75%ile as mentioned in the referenced bug) * 55000 binary
> packages * 10 architectures * 3 versions - so quite conservatively
> [2] So supposedly a CDN wouldn't bring a lot of benefit as individual
> files aren't likely to be hit frequently.

using static.debian.org seems to be a good idea to me, what would be needed to 
make
this happen?

or, we could put them in a git repo instead, and use git.debian.org…

feedback welcome.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#873746: crash backtrace

[Thomas Dickey]

On Fri, Sep 01, 2017 at 08:53:29PM +0200, Sven Joachim wrote:
> For the reference, this bug has been reported originally at
> https://bugzilla.redhat.com/show_bug.cgi?id=1484290.  Thomas said he
> could not reproduce it, but the crash happens with the current version
> in unstable.
> 
> Here is a backtrace from "infotocap POC12" after rebuilding tic with
> -O0, so that the variables are not all optimized out:

Reproducing it depends on the architecture and options (thanks for the
reminder: I was able to reproduce this using 32-bit Debian9 with the
options corresponding to the Debian package - needed both of those...)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#874083: RM: libdivecomputer -- ROM; Not really interesting

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

Hello

Could you please remove libdivecomputer from the archive?
The main consumer was subsurface that we removed from the archive and the 
popcorn
is only 24...

Thanks
S

Bug#874081: borgbackup: Won't start: ImportError: /usr/lib/python3/dist-packages/borg/crypto.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf

[Sami Liedes]

Package: borgbackup
Version: 1.0.11-3
Severity: normal

Merely starting borg after upgrading to python3.5 3.5.4-3 fails:


$ borg
Traceback (most recent call last):
  File "/usr/bin/borg", line 11, in 
load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 564, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2662, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2322, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in 
from .helpers import Error, location_validator, archivename_validator, 
format_line, format_time, format_file_size, \
  File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in 
from . import crypto
ImportError: 
/usr/lib/python3/dist-packages/borg/crypto.cpython-35m-x86_64-linux-gnu.so: 
undefined symbol: PyFPE_jbuf


I believe this is related to this change in python3.5:


python3.5 (3.5.4-3) unstable; urgency=medium

  * Stop building the fpectl extension.
  * Break python3-numpy (<< 1:1.12.1-3.1), referencing the now missing fpectl
modules. Addresses: #873791.

 -- Matthias Klose   Thu, 31 Aug 2017 14:22:39 +0200


There is a mail on debian-python about this change, expecting possible
breakage:

   https://lists.debian.org/debian-python/2017/09/msg0.html

Sami


-- 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.7 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.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 borgbackup depends on:
ii  fuse   2.9.7-1
ii  libacl12.2.52-3+b1
ii  libc6  2.24-17
ii  liblz4-1   0.0~r131-2+b1
ii  libssl1.1  1.1.0f-5
ii  python33.5.3-3
ii  python3-llfuse 1.2+dfsg-1+b1
ii  python3-msgpack0.4.8-1+b1
ii  python3-pkg-resources  36.2.7-2

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

Bug#874082: gdisk: gpt.h header file lacks matching compiler directive

[Alison Chaiken]

Package: gdisk
Version: 0.8.10-2
Severity: normal
Tags: upstream patch

Dear Maintainer,

The header file gpt.h should include a matching pair of compiler
directives regarding packing, but only includes one.  The bug persists
in the latest version from git.  The very simple fix is appended.  (I
hope.)

-- Alison Chaiken
   ali...@she-devel.com

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

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

Versions of packages gdisk depends on:
ii  libc6 2.19-18+deb8u10
ii  libgcc1   1:4.9.2-10
ii  libncursesw5  5.9+20140913-1+b1
ii  libpopt0  1.16-10
ii  libstdc++64.9.2-10
ii  libtinfo5 5.9+20140913-1+b1
ii  libuuid1  2.25.2-6

Versions of packages gdisk recommends:
ii  groff-base  1.22.2-8

gdisk suggests no packages.

-- no debconf information
>From da96fce13c759dc17068e5a8094f5e23aa662527 Mon Sep 17 00:00:00 2001
From: Alison Chaiken 
Date: Sat, 2 Sep 2017 12:28:55 -0700
Subject: [PATCH] turn packing back off in GPT header file

The file gpt.h includes a pragma to turn on packing, but not a
matching directive to turn it back off.

Suggested-by: Jamal Benbrahim 
Signed-off-by: Alison Chaiken 
---
 gpt.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gpt.h b/gpt.h
index e9afd06..7a0714b 100644
--- a/gpt.h
+++ b/gpt.h
@@ -57,6 +57,7 @@ struct GPTHeader {
uint32_t partitionEntriesCRC;
unsigned char reserved2[GPT_RESERVED];
 }; // struct GPTHeader
+#pragma pack()
 
 // Data in GPT format
 class GPTData {
-- 
2.1.4

Bug#874078: lintian: improve binary-file-built-without-LFS-support info field

[Chris Lamb]

tags 874078 + pending
thanks

Thanks Bound; applied in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=f40064ca2ec72bbed05eba25b87aaea4c13ccb20


Regards,

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

Bug#874080: hdparm v9.51 please document how to restart

[b17]

Package: hdparm
Version: 9.51+ds-1
Severity: wishlist

Dear Maintainer,
I know I must be missing something, but I just can't find the way to get 
hdparm to return to /etc/hdparm.conf initial state.

There is no init script, no service file?

I have looked at the man pages for hdparm and hdparm.conf and read 
what's available in /usr/share/doc/hdparm.  Looked at some closed bugs 
from the changelog, and i see when the init script was removed, but didn't 
understand exactly why.

Also I used find and located the /lib/udev/hdparm script and also the 
/lib/systemd/system-sleep/hdparm script, which runs the 
/usr/lib/pm-utils/power.d/95hdparm-apm script...

but holy cow, I'm not sure I want to go around popping scripts by trial 
and error with a util like hdparm, sounds risky.

There must be a simple way, after adjusting settings with /sbin/hdparm to 
return to default initialization found in /etc/hdparm.conf but I can't find 
it.

TIA,
bw

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

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

Versions of packages hdparm depends on:
ii  libc6 2.24-11+deb9u1
ii  lsb-base  9.20161125

Versions of packages hdparm recommends:
ii  powermgmt-base  1.31+nmu1

Versions of packages hdparm suggests:
pn  apmd  

-- no debconf information

Bug#874079: ITP: r-cran-readstata13 -- Functions to read and write 'Stata' files

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-readstata13
  Version : 0.9.0-1
  Upstream Author : Jan Marvin Garbuszus, Sebastian Jeworutzki
* URL or Web page : https://github.com/sjewo/readstata13
* License : GPL-2
  Description : R functions to read and write 'Stata' files


This R package is now a (Build-)Depends of the existing package
r-cran-rcmdrmisc which is itself a (Build-)Depends of r-cran-rcmdr which has
been in Debian for probably 15 years.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874078: lintian: improve binary-file-built-without-LFS-support info field

[Boud Roukema]

Package: lintian
Version: 2.5.52
Severity: normal
Tags: patch lfs

Dear Maintainers,


CONTEXT:

Mpgrafic-0.3.15-1 is flagged with the binary-file-built-without-LFS-support 
lintian

flag despite my attempts to follow the lintian recommendations, after having
searched for LFS info in obvious places:
https://lintian.debian.org/full/debian-astro-maintain...@lists.alioth.debian.org.html#mpgrafic

Discussion at this other lintian bug looks like it will solve the mpgrafic
LFS bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871956


PROBLEM:

Version 2.5.52 of the binary-file-built-without-LFS-support section of
binaries.desc has two problems that make applying LFS support
corrections difficult for someone (such as me) who is not yet familiar
with LFS, AC_SYS_LARGEFILES and their portability:

(i) It says in one sentence that we must "ensure _FILE_OFFSET_BITS is
defined and set to 64", but in the following sentence that
"this can be done by using the AC_SYS_LARGEFILE macro with autoconf".
However, AC_SYS_LARGEFILE does not seem to define _FILE_OFFSET_BITS
on amd64, since it does not seem to be needed.

In other words, these two sentences are contradictory. Either lintian
should request everyone to hardwire everything with _FILE_OFFSET_BITS and
recommend *not* using AC_SYS_LARGEFILE, or it needs to indicate that
_FILE_OFFSET_BITS is not needed on all systems and that AC_SYS_LARGEFILE
can decide on which systems _FILE_OFFSET_BITS is needed.

(ii) I have not been able to find good documentation to give more
hints on functions that may need to be modified, or even better, on
functions that only need to be modified for some architectures
(pwrite, pread in the case of mpgrafic). So a brief comment in the
lintian info field could help improve the probability of people
responding to the warning rather than ignoring it.

I'm setting this as a normal level bug, because the aim of lintian
is not only to warn package maintainers, but also to help them
fix problems.


PATCH:

My proposed updated second paragraph is here:

 To support large files, code review might be needed to make sure that
 those files are not slurped into memory or mmap(2)ed, and that correct
 64-bit data types are used (ex: off_t instead of ssize_t), etc.  Once
 that has been done ensure, if needed, that _FILE_OFFSET_BITS
 is defined and
 set to 64 before the relevant files are included. This can be done
 conditionally by
 using the AC_SYS_LARGEFILE macro with autoconf, or by appending
 the output of getconf LFS_CFLAGS and getconf LFS_LDFLAGS
 to CFLAGS and LDFLAGS respectively. Functions such
 as pwrite and pread should be replaced by pwrite64 and pread64 in
 cases where _FILE_OFFSET_BITS is defined and set to 64.

I'm also attaching it as a patch file.

Cheers
Boud

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)--- checks/binaries.desc.orig	2017-06-17 17:38:57.0 +0200
+++ checks/binaries.desc	2017-09-02 21:57:08.929153000 +0200
@@ -439,11 +439,15 @@
  To support large files, code review might be needed to make sure that
  those files are not slurped into memory or mmap(2)ed, and that correct
  64-bit data types are used (ex: off_t instead of ssize_t), etc.  Once
- that has been done ensure _FILE_OFFSET_BITS is defined and
- set to 64 before the relevant files are included.  This can be done by
+ that has been done ensure, if needed, that _FILE_OFFSET_BITS
+ is defined and
+ set to 64 before the relevant files are included. This can be done
+ conditionally by
  using the AC_SYS_LARGEFILE macro with autoconf, or by appending
  the output of getconf LFS_CFLAGS and getconf LFS_LDFLAGS
- to CFLAGS and LDFLAGS respectively.
+ to CFLAGS and LDFLAGS respectively. Functions such
+ as pwrite and pread should be replaced by pwrite64 and pread64 in
+ cases where _FILE_OFFSET_BITS is defined and set to 64.
  .
  Take into account that even if this tag is not emitted, that does not
  mean the binary is LFS-safe (ie. no OOM conditions, file truncation

Bug#864257: python3-sleekxmpp: TLS certificate verification fails

[W. Martin Borgert]

> I have created a single fix point release v1.3.3 for this bug

Thanks! Just uploaded to Debian, problem (hopefully) solved!


signature.asc
Description: PGP signature

Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more

[Chris Lamb]

Paul,

> Oh, I see.  Personally, my only concern was that a lintian error would
> prevent an uploaded, released package from migrating to testing.

Hm? Lintian has no effect on migrations from unstable to testing.

> I did not think it should be a lintian error, because not having the
> file does not violate Debian Policy.

See #870722. This was fixed in 4th August in:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=126157380dc0eba302f3d476b1cffc13f968c207

:)


Regards,

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

Bug#776376: dict-gazetteer2k: please make the build reproducible

[Chris Lamb]

Hi,

I've re-uploaded dict-gazetteer2k 1.0.0-5.4 to unstable; ie. without
DELAYED/X as it just went through that, but I needed to add the lintian
override for it to get past dak's autorejects.

The changelog entry is:
  
  dict-gazetteer2k (1.0.0-5.4) unstable; urgency=medium
  
* Non-maintainer upload.
* Make the build reproducible. (Closes: #776376)
* Override "empty-binary-package" Lintian warning for dict-gazetteer2k to
  avoid dak autoreject.

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for dict-gazetteer2k_1.0.0-5.3 dict-gazetteer2k_1.0.0-5.4

 debian/dict-gazetteer2k.lintian-overrides |2 ++
 dict-gazetteer2k-1.0.0/debian/changelog   |9 +
 dict-gazetteer2k-1.0.0/debian/rules   |3 +++
 3 files changed, 14 insertions(+)

diff -u dict-gazetteer2k-1.0.0/debian/changelog 
dict-gazetteer2k-1.0.0/debian/changelog
--- dict-gazetteer2k-1.0.0/debian/changelog
+++ dict-gazetteer2k-1.0.0/debian/changelog
@@ -1,3 +1,12 @@
+dict-gazetteer2k (1.0.0-5.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make the build reproducible. (Closes: #776376)
+  * Override "empty-binary-package" Lintian warning for dict-gazetteer2k to
+avoid dak autoreject.
+
+ -- Chris Lamb   Fri, 18 Aug 2017 09:04:37 -0700
+
 dict-gazetteer2k (1.0.0-5.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dict-gazetteer2k-1.0.0/debian/rules dict-gazetteer2k-1.0.0/debian/rules
--- dict-gazetteer2k-1.0.0/debian/rules
+++ dict-gazetteer2k-1.0.0/debian/rules
@@ -35,6 +35,8 @@
$(PYTHON) zipswriter.py
$(PYTHON) placeswriter.py
$(PYTHON) countieswriter.py
+   # Ensure deterministic mtime for dictzip to inherit
+   touch --date='@$(SOURCE_DATE_EPOCH)' *.dict
dictzip *.dict
 
touch build-stamp
@@ -93,6 +95,7 @@
dh_installcron
dh_installman
dh_installinfo
+   dh_lintian
 #  dh_undocumented
dh_installchangelogs -A
dh_link
--- dict-gazetteer2k-1.0.0.orig/debian/dict-gazetteer2k.lintian-overrides
+++ dict-gazetteer2k-1.0.0/debian/dict-gazetteer2k.lintian-overrides
@@ -0,0 +1,2 @@
+# This package only pulls in dependencies
+dict-gazetteer2k binary: empty-binary-package

Bug#855942: qt 5.9 is in unstable :-)

[Rémi Letot]

Hi,

just a ping to let you know that qt 5.9 seems to have landed in unstable.

Thanks a lot for your work,
--
Rémi

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Boud Roukema]

hi Adam, all,

On Sat, 2 Sep 2017, Adam Borowski wrote:


AC_SYS_LARGEFILE on i386 (linux) for mpgrafic-0.3.15-1 apparently does *not*
always do the right thing:


You call it but don't actually use what it returns:

mpicc -DHAVE_CONFIG_H -I.  -I..  -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2
   -fdebug-prefix-map=/<>=.  -fstack-protector-strong -Wformat
   -Werror=format-security -c -o parallel_io.o parallel_io.c

#define _XOPEN_SOURCE 500
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

You don't include "config.h" anywhere.


You're right - thanks for spotting that :).


Nope, you use pwrite() not pwrite64() -- on i386 you need the latter to get
LFS; they're aliases only on amd64, x32 and so on.


OK, so config.h + p(read|write)64 should hopefully solve the mpgrafic
bug. I initially tried hardwiring pwrite64 and pread64 (compiling on
amd64), but got "warning: implicit declaration of function ‘pwrite64’
[-Wimplicit-function-declaration]". My understanding is that
_FILE_OFFSET_BITS and __USE_FILE_OFFSET64 are *not* set for amd64 by
AC_SYS_LARGEFILE, and instead only set for some systems, such as i386.
The following should correctly work together with AC_SYS_LARGEFILE, it
seems to me.

Does this look OK?

#ifndef __USE_FILE_OFFSET64
  i_stat=pwrite(fd,buffer,size,offset);
#else
  i_stat=pwrite64(fd,buffer,size,offset);
#endif

#ifndef __USE_FILE_OFFSET64
  i_stat = pread(fd,buffer,size,offset);
#else
  i_stat = pread64(fd,buffer,size,offset);
#endif



But in any case, even if it had been indeed a false positive, it'd be a
different bug.


I think I should post a lintian bug for improving the info field for
the LFS unsafe detection - I spent quite a bit of time searching for how
to handle this, and having more detailed information could help other
debian contributors respond more easily to built-without-LFS-support
warnings.

Cheers
Boud

Bug#833012: OpenPGP signature mangling rule for auto/default

[Sean Whitton]

On Fri, Sep 01 2017, Sean Whitton wrote:

> Shouldn't there be a '$' in the first one, too?

Er, I was too tired when I wrote this.

Patch LGTM, though of course needs testing.  Thanks again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#874077: clutter-1.0: build tests fail on Debian but pass on Ubuntu

[Jeremy Bicha]

Source: clutter-1.0
Version: 1.26.2+dfsg-2
Severity: important
Tags: help
Affects: mutter

The clutter build tests fail on Debian but pass on Ubuntu. Therefore,
I will be ignoring tests failures for clutter on Debian. (Because
mutter basically includes a fork of clutter, it has the same problem.)

First, make sure that libgl1-mesa-dri is installed. ( libgl1-mesa-glx
will soon depend on it but that change hasn't reached unstable yet.)

All of the tests fail with errors like this:

---

ERROR: actor-anchors


(actor-anchors:21072): GLib-CRITICAL **: g_strsplit: assertion 'string
!= NULL' failed
Segmentation fault
ERROR: actor-anchors - missing test plan
ERROR: actor-anchors - exited with status 139 (terminated by signal 11?)

-

I believe that indicates that the test crashed.

Here's a full build log:

https://buildd.debian.org/status/fetch.php?pkg=clutter-1.0=amd64=1.26.2%2Bdfsg-2=1504202716

gnome-shell 3.25 build tests also fail on Debian but pass on Ubuntu.
Perhaps a similar cause?

Thanks,
Jeremy Bicha

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

> Please update Standards-Version to he current version.
Done.
This triggers a warning in lintian, which only knows about 4.0.0
This warning is displayed also by other packages already in Debian and
nobody put in place an override for this warning so I though I should do
the same.
Debian policy 4.1.0 §4.15 is about reproducibility, which I was
already targeting,
but it is not 100% clear how can I be sure that my package is reproducible.
I built the package twice and the binary packages are identical, but I don't
know if this is enough.
Priority from extra to optional is now part of the policy so this is
reflected in
the changelog.

> Shipping files like /usr/share/pixmaps/new.svg seems very wrong, they
> should be in a package-specific dir (and not under /usr/share/pixmaps).
All icons are now moved in /usr/share/cyclograph/icons with the exception
of the application icon, which is now also in 48x48 as required by freedesktop
specifications. A couple more sizes have been provided in png format.

> Qt frontend doesn't work: ImportError: cannot import name 'QtWebEngineWidgets'
Added the missing dependency to qtwebengine

> You shouldn't use the full icon paths in .desktop Icon, definitely not
> ones for 32x32.
I ran desktop-file-validate and it mislead me to add the full path,
The file extension should have been removed, and now they are.

Regards
--
Federico

Bug#874076: user does not use raid but cannot delete package

[積丹尼 Dan Jacobson]

Package: mdadm
Version: 4.0-1

User gets message:

> "CD" == Cron Daemon  writes:

CD> Subject... if [ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ]; 
then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
CD> checkarray: E: MD subsystem not loaded, or /proc unavailable.

User sees in
https://serverfault.com/questions/454307/checkarray-e-md-subsystem-not-loaded-or-proc-unavailable/455971
that he should purge mdadm.

The following packages have unmet dependencies:
 libblockdev-mdraid2 : Depends: mdadm (>= 3.3.2) but it is not going to be 
installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) gvfs [1.30.4-1+b1 (now, unstable)]
2) gvfs-backends [1.30.4-1+b1 (now, unstable)]
3) gvfs-daemons [1.30.4-1+b1 (now, unstable)]
4) libblockdev-mdraid2 [2.12-2 (now, unstable)]
5) udisks2 [2.7.2-2 (now, unstable)]

Accept this solution? [Y/n/q/?]

The user does not use any "raid disks".

Bug#874075: qemu-system: ssh documented, but not implemented

[Marc Lehmann]

Package: qemu-system
Version: 1:2.8+dfsg-6+deb9u2
Severity: normal

Dear Maintainer,

running the example from the qemu-system manpage:

   qemu-system-i386 -drive file=ssh://user@host/path/to/disk.img

results in:

   qemu-system-i386: -drive file=ssh://user@host/path/to/disk.img: Unknown 
protocol 'ssh'

likewise other attempts to use the ssh protocol.

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

Kernel: Linux 4.4.84-040484-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system depends on:
ii  qemu-system-arm1:2.8+dfsg-6+deb9u2
ii  qemu-system-mips   1:2.8+dfsg-6+deb9u2
ii  qemu-system-misc   1:2.8+dfsg-6+deb9u2
ii  qemu-system-ppc1:2.8+dfsg-6+deb9u2
ii  qemu-system-sparc  1:2.8+dfsg-6+deb9u2
ii  qemu-system-x861:2.8+dfsg-6+deb9u2

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.

[Hannes von Haugwitz]

Hi,

Is there any progress with packaging qutebrowser?

Best regards

Hannes

Bug#874074: ld.so: TLS relocations against local symbols don't work on powerpc, sparc and sparc64

[James Clarke]

Package: libc6
Version: 2.24-17
Tags: upstream patch
Forwarded: https://sourceware.org/ml/libc-alpha/2017-09/msg00120.html
User: debian-sp...@lists.debian.org
Usertags: sparc sparc64
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-sp...@lists.debian.org, debian-powe...@lists.debian.org

Hi,
On the above architectures, TLS relocations against local symbols do not
work properly, crashing with SIGBUS or SIGSEGV on accessing the variable
in question. This is only a problem when using gold, as bfd will
optimise the relocations (since it knows the symbol cannot be pre-empted
by one in another object) to not refer to a symbol at all. I have
written a test script, available at [0].

The above patch has been tested on powerpc and sparc64 using my test
script, as well as on sparc64 using my local experimental GHC with
native code generation support, where the problem was first seen.

Regards,
James

[0] http://paste.debian.net/plain/984146

Bug#864257: python3-sleekxmpp: TLS certificate verification fails

[bear]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have created a single fix point release v1.3.3 for this bug

branch:
  https://github.com/fritzy/SleekXMPP/tree/release_1.3.3
source tarball:
  https://github.com/fritzy/SleekXMPP/archive/sleek-1.3.3.tar.gz
PyPI release:

https://pypi.python.org/pypi?:action=display=sleekxmpp=1.3.
3
commit with patch applied:

https://github.com/fritzy/SleekXMPP/commit/65db8c39dd57e691c89b491afb6aa
22f6bc05eff

Not sure how you need this to be setup - let me know if you need
something else.

On Tue, 29 Aug 2017 12:55:28 -0400 bear  wrote:
> I'm one of the maintainers for SleekXMPP - thanks for reporting
> this bug .
> 
> I'm going to be working on getting your patch into the code and
> make a release so it can be used by package maintainers.
> 
> thanks!
> 
> 

- -- 

bear
xmpp agitator; ops curmudgeon; generalist
http://bear.im/about
http://bear.im/pubkey.txt
0A93 9BA7 8203 FCBC 58A9 E8B5 9D1E 0661 8EE5 B4D8
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZqvaJAAoJEJ0eBmGO5bTY734P/jRCwA2QQ8hu9PJXKyWl78v9
I6Rk3Hm77t/j3KnXDkAt0FEycN4IZr7c8O7EV/DB8ANHOb7Og+mEXOHhE4mGwESZ
EUfm5L4pB/XIp78s88nNQdFSBcS8JFffu5PZvoSNUEefwPZZQtrBiasYDGFR24tq
oMVa9aTkabbWzcsJOn2qUgTooMODo8/Qg+1XLtPneBwGDcjzEDeoNH8QwWKrMwEO
hobKepv/o2GCy2QPD7HAlcAl5fxQhy/JlAVj0VyjNujJJqsOrrIRZpsWGoHlHOJH
YNr1ymVkHkbvzp5NwwXfzWvkiT4GFm+c1GIPkBQxeYgauybhJpwsGVmLqk4tQkoR
A0G67etKfxJZKjuX3uD+RkIAzTsND0iGZbr7ClcESfOuGcgg3CuOtN9RzHVplA5R
PH3zZMwSHVfRtG4M8eorzKML/c3kI13SiWP57+ROP9aK+owkOFeDv83eFkzKE7Es
b1+S7dxLX4WPM7RcfY4J8hdIV1pqPqP5s54mBZw1hcd84PGMWE4GC+gp0gXclq41
R2e//CQIan7JNmI/9qYI3hh5TBdB1YZQaZxIo8SCd6sCNiv0rDlYOD5q4o6JK5eg
Xia0XSHOBYivShgiBuhog/Mlr9wPWnpwt09/R+36+29OYkkx2izleN8i7oKU7O/m
rx6R4RrfyRLnqNSjbVLY
=Oeqr
-END PGP SIGNATURE-

Bug#874073: camorama: .gnome2 ownership discovered after loading camorama

[Ross]

Package: camorama
Version: 0.19-5+b1
Severity: normal
Tags: d-i

Dear Maintainer,

   * What led up to the situation?
  I installed camorama using synaptic.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  camorama would not start from menu.
  camorama would not start from terminal as user.
  camorama started from terminal using sudo.

   * What was the outcome of this action?
  discovered that ~/.gnome2 owner and group were set to root instead of 
user 

   * What outcome did you expect instead?
  ~/.gnome2 should be owned by the user, not root.
  It is unclear when/how ~/.gnome2 was created or changed to be owned by 
root.  
  Problem was discovered when I installed camorama, but it may have 
pre-existed.
  This is a fairly new (~2 weeks) installation of stretch with mate desktop
  Camorama had loaded and worked without incident on prior installation of 
jessie-mate on same hardware.
  Note that the desktop is Mate in case that played a part in this issue.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/3 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 camorama depends on:
ii  gconf-service   3.2.6-4+b1
ii  gconf2  3.2.6-4+b1
ii  libc6   2.24-11+deb9u1
ii  libgconf-2-43.2.6-4+b1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglade2-0 1:2.6.4-2
ii  libglib2.0-02.50.3-2
ii  libgnome-2-02.32.1-5+b1
ii  libgnomeui-02.24.5-3.1
ii  libgnomevfs2-0  1:2.24.4-6.1+b2
ii  libgtk2.0-0 2.24.31-2
ii  libv4l-01.12.5-1

camorama recommends no packages.

camorama suggests no packages.

-- no debconf information

Bug#874072: ITP: node-filesize -- nodejs module which provides a simple way to get a human readable file size string from a number (float or integer) or string.

[Rahulkrishnan R A]

Package: wnpp
Severity:  whishlist
Owner: 'Rahulkrishnan R A' 


*Package Name  :  node-filesize
 Version  :  3.5.10
 Upstream Author  : avoidwork
*URL  :  *https://*github.com/avoidwork/filesize.js
*Licence  : BSD-3-Clause
*Programming Lang : JavaScript
*Description : It provides a simple way to get a human readable file size
string  from a number (float or integer) or string.

I am packaging node-filesize

Bug#874029: uscan: please support signature file containing list of signatures

[Jérémy Lal]

2017-09-02 19:54 GMT+02:00 James McCoy :

> On Sat, Sep 02, 2017 at 09:58:43AM +0200, Jérémy Lal wrote:
> > The typical example i have under the hand is:
> > https://nodejs.org/dist/v6.3.1/
> > https://nodejs.org/dist/v6.3.1/SHASUMS256.txt
> > https://nodejs.org/dist/v6.3.1/SHASUMS256.txt.asc
>
> The subject confused me a bit.  This appears to be a list of the hashes
> of each file, and this list of hashes is signed.  That's quite different
> than the current signature handling, which expects a signature of the
> archive and verifies the archive against that signature.
>


Indeed ! Hence the feature request !

Jérémy

Bug#874071: fail2ban: Fails to start after Jessie to Stretch upgrade due to sshd being enabled in /etc/fail2ban/jail.d/defaults-debian.conf

[Florian Schlegel]

Package: fail2ban
Version: 0.9.6-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 I upgraded my system from Jessie to Stretch.
 #767119 enables ssh jail in /etc/fail2ban/jail.d/defaults-debian.conf

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Disabling the SSH jail in /etc/fail2ban/jail.d/defaults-debian.conf
 fixed the problem.

   * What was the outcome of this action?
 fail2ban does not start. Here is an example. The same happened when
 I try to start it manually:

 Aug 31 01:15:52 vbox systemd[1]: apt-daily-upgrade.timer: Adding 25min
 818.405ms random time.
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Control process
 exited, code=exited status=255
 Aug 31 01:15:52 vbox systemd[1]: Failed to start Fail2Ban Service.
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Unit entered failed
 state.
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Failed with result
 'exit-code'.
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Service hold-off time
 over, scheduling restart.
 Aug 31 01:15:52 vbox systemd[1]: Stopped Fail2Ban Service.
 Aug 31 01:15:52 vbox systemd[1]: Starting Fail2Ban Service...
 Aug 31 01:15:52 vbox fail2ban-client[1464]: WARNING 'filter' not defined
 in 'sshd'. Using default one: ''
 Aug 31 01:15:52 vbox fail2ban-client[1464]: WARNING No filter set for
 jail sshd
 Aug 31 01:15:52 vbox fail2ban-client[1464]: WARNING 'filter' not defined
 in 'sshd'. Using default one: ''
 Aug 31 01:15:52 vbox fail2ban-client[1464]: ERROR  Failed during
 configuration: Bad value substitution: option 'action' in section 'sshd'
 contains an interpolation key 'port' which is not a valid option name.
 Raw value: '%(action_)s'
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Control process
 exited, code=exited status=255
 Aug 31 01:15:52 vbox systemd[1]: Failed to start Fail2Ban Service.
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Unit entered failed
 state.
 Aug 31 01:15:52 vbox systemd[1]: fail2ban.service: Failed with result
 'exit-code'.

   * What outcome did you expect instead?
 fail2ban should start even if the SSH jail is enabled in
 /etc/fail2ban/jail.d/defaults-debian.conf or this option should be
 disabled on systems where this problem occurs.


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

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

Versions of packages fail2ban depends on:
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
ii  python3  3.5.3-1

Versions of packages fail2ban recommends:
ii  iptables   1.6.0+snapshot20161117-6
ii  python 2.7.13-2
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd233-1
ii  whois  5.2.15

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
pn  monit
ii  rsyslog [system-log-daemon]  8.24.0-1

-- Configuration Files:
/etc/fail2ban/action.d/blocklist_de.conf changed [not included]
/etc/fail2ban/jail.conf changed [not included]
/etc/fail2ban/jail.d/defaults-debian.conf changed [not included]

-- no debconf information

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 2 September 2017 at 19:23, Steve Cotton wrote:
| If I may ask, "why do you want to spend the developer time to rebuild only 46
| packages, when there's already an infrastructure that does it for you, at the
| cost of rebuilding all 516"?

Because in my 20+ years with Debian, we generally opted for the technically
correct solution rather than what one may call the nuclear option.

I still happen to believe in proper engineering, which is why I went through
the trouble of finely documenting what is needed here:

http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

The change in R is still not an abi change but simple a (in hindsight) less
than perfect implementation requiring a small subset (less than 10%) of
packages to be rebuilt. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874029: uscan: please support signature file containing list of signatures

[James McCoy]

On Sat, Sep 02, 2017 at 09:58:43AM +0200, Jérémy Lal wrote:
> The typical example i have under the hand is:
> https://nodejs.org/dist/v6.3.1/
> https://nodejs.org/dist/v6.3.1/SHASUMS256.txt
> https://nodejs.org/dist/v6.3.1/SHASUMS256.txt.asc

The subject confused me a bit.  This appears to be a list of the hashes
of each file, and this list of hashes is signed.  That's quite different
than the current signature handling, which expects a signature of the
archive and verifies the archive against that signature.

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

Bug#865368: torsocks: procmail spawned by mpop in torsocks fails with "Operation not permitted"

[intrigeri]

Control: tag -1 - moreinfo
Control: tag -1 forwarded dgou...@ev0ke.net

Hi David!

Can you please have a look at this bug report?

Full discussion and debug log: https://bugs.debian.org/865368

Please let us know if you need additional info :)

Nick:
>> 1. try to reproduce with torsocks 2.2.0-2 (that landed in sid
>>yesterday);

> I can reproduce exactly the same thing with 2.2.0-2

>> 2. if this still fails, retry with `torsocks --debug' so I have more
>>information to forward upstream.

> Done, log attached.

> 1503579551 DEBUG torsocks[29232]: Logging subsytem initialized. Level 5, file 
> (null), time 1 (in init_logging() at torsocks.c:303)
> 1503579551 DEBUG torsocks[29232]: Config file not provided by 
> TORSOCKS_CONF_FILE. Using default /etc/tor/torsocks.conf (in 
> config_file_read() at config-file.c:543)
> 1503579551 DEBUG torsocks[29232]: Config file setting tor address to 
> 127.0.0.1 (in conf_file_set_tor_address() at config-file.c:298)
> 1503579551 DEBUG torsocks[29232]: Config file setting tor port to 9050 (in 
> conf_file_set_tor_port() at config-file.c:254)
> 1503579551 DEBUG torsocks[29232]: [config] Onion address range set to 
> 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
> 1503579551 DEBUG torsocks[29232]: Config file /etc/tor/torsocks.conf opened 
> and parsed. (in config_file_read() at config-file.c:572)
> 1503579551 DEBUG torsocks[29232]: [fclose] Close caught for fd 3 (in 
> tsocks_fclose() at fclose.c:45)
> 1503579551 DEBUG torsocks[29232]: [onion] Pool init with subnet 127.42.42.0 
> and mask 24 (in onion_pool_init() at onion.c:104)
> 1503579551 DEBUG torsocks[29232]: [onion] Pool initialized with base 0, 
> max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
> 1503579551 DEBUG torsocks[29232]: [fclose] Close caught for fd 3 (in 
> tsocks_fclose() at fclose.c:45)
> 1503579551 DEBUG torsocks[29236]: Logging subsytem initialized. Level 5, file 
> (null), time 1 (in init_logging() at torsocks.c:303)
> 1503579551 DEBUG torsocks[29236]: Config file not provided by 
> TORSOCKS_CONF_FILE. Using default /etc/tor/torsocks.conf (in 
> config_file_read() at config-file.c:543)
> 1503579551 DEBUG torsocks[29236]: Config file setting tor address to 
> 127.0.0.1 (in conf_file_set_tor_address() at config-file.c:298)
> 1503579551 DEBUG torsocks[29236]: Config file setting tor port to 9050 (in 
> conf_file_set_tor_port() at config-file.c:254)
> 1503579551 DEBUG torsocks[29236]: [config] Onion address range set to 
> 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
> 1503579551 DEBUG torsocks[29236]: Config file /etc/tor/torsocks.conf opened 
> and parsed. (in config_file_read() at config-file.c:572)
> 1503579551 DEBUG torsocks[29236]: [fclose] Close caught for fd 3 (in 
> tsocks_fclose() at fclose.c:45)
> 1503579551 DEBUG torsocks[29236]: [onion] Pool init with subnet 127.42.42.0 
> and mask 24 (in onion_pool_init() at onion.c:104)
> 1503579551 DEBUG torsocks[29236]: [onion] Pool initialized with base 0, 
> max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
> 1503579551 DEBUG torsocks[29236]: [close] Close caught for fd 0 (in 
> tsocks_close() at close.c:33)
> 1503579551 DEBUG torsocks[29236]: [close] Close caught for fd 3 (in 
> tsocks_close() at close.c:33)
> 1503579551 DEBUG torsocks[29237]: Logging subsytem initialized. Level 5, file 
> (null), time 1 (in init_logging() at torsocks.c:303)
> 1503579551 DEBUG torsocks[29237]: Config file not provided by 
> TORSOCKS_CONF_FILE. Using default /etc/tor/torsocks.conf (in 
> config_file_read() at config-file.c:543)
> 1503579551 DEBUG torsocks[29237]: Config file setting tor address to 
> 127.0.0.1 (in conf_file_set_tor_address() at config-file.c:298)
> 1503579551 DEBUG torsocks[29237]: Config file setting tor port to 9050 (in 
> conf_file_set_tor_port() at config-file.c:254)
> 1503579551 DEBUG torsocks[29237]: [config] Onion address range set to 
> 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
> 1503579551 DEBUG torsocks[29237]: Config file /etc/tor/torsocks.conf opened 
> and parsed. (in config_file_read() at config-file.c:572)
> 1503579551 DEBUG torsocks[29237]: [fclose] Close caught for fd 3 (in 
> tsocks_fclose() at fclose.c:45)
> 1503579551 DEBUG torsocks[29237]: [onion] Pool init with subnet 127.42.42.0 
> and mask 24 (in onion_pool_init() at onion.c:104)
> 1503579551 DEBUG torsocks[29237]: [onion] Pool initialized with base 0, 
> max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
> 1503579551 DEBUG torsocks[29237]: [close] Close caught for fd 3 (in 
> tsocks_close() at close.c:33)
> 1503579551 DEBUG torsocks[29237]: [close] Close caught for fd 3 (in 
> tsocks_close() at close.c:33)
> 1503579551 DEBUG torsocks[29237]: [onion] Destroying onion pool containing 0 
> entry (in onion_pool_destroy() at onion.c:148)
> 1503579551 DEBUG torsocks[29237]: [fclose] Close caught for fd 2 (in 
> tsocks_fclose() at fclose.c:45)
> 1503579551 DEBUG torsocks[29236]: [close] Close caught for fd 

Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

[Andrey Rahmatullin]

libopagent.so should be in -dev.
I think /etc/ld.so.conf.d/oprofile-jit.conf should be in oprofile-jit.
I think you had a .symbols file for libopagent1, you should use it again.
You should use debian/tmp instead of . in find commands in d/rules.
Your .html files are size 0, because you haven't adjusted B-D.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#863596: mytop can't installed

[Yvan Taviaud]

> - download mariadb-client-10.1.deb, extract mytop binary, copy it in
> /usr/bin/ (as defined in the .deb)

For those who'll try this, here's what I did:
- download the deb
- extract it with «dpkg-deb -x»
- copy the mytop command to /usr/local/bin
- comment out the line 129:
   - unshift @ARGV, split "\n", `$my_print_defaults client mytop`;
   - else the connection always fails on Percona XtraDB Cluster. I narrow
it down with a diff to mytop 1.91, Jessie version.
   - did it with: sed -i s/unshift/\#unshift/ path/to/mytop

I'll stick to it until mytop goes back... in a new package mysql-utils? It
could be paired with mysqltuner and tools like that :-)

HTH,
Yvan.

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Lisandro Damián Nicanor Pérez Meyer]

On 2 September 2017 at 12:11, Alex ARNAUD  wrote:
> Le 02/09/2017 à 16:28, Lisandro Damián Nicanor Pérez Meyer a écrit :
>>
>> I'm really open to suggestions. at-spi2-core is being installed by default
>> on
>> standard installations, so we are inflicting a huge performance drawback
>> to
>> most of our users. On the other hand people needing a11y really need to
>> get
>> this on as simple as possible.
>
>
> Primary, could you explain why you tell us that?

Because it's at-spi2-core the package which sets the variable.

> In which case you've
> noticed issue? I'm running Debian 8.9 with QT accessibility enabled without
> any performance issue.

Look at the upstream thread I linked in the first mail. Allan happens to be the
developer behind the relevant Qt code.

>> I'm pretty sure that if all the interested parties try we can find a good
>> technical solution to this.
>
>
> Indeed. I wait to reproduce and to understand your use-case before to
> participate to a debate to figure out your issue.

Basically: Qt issuing all the necessary messages for a11y in machines
not needing a11y makes a lot
of cpu power waste, whether you notice it or not.

So we have a huge user base wasting power for something they don't
need. I'm pretty sure we can find a way to
avoid that happen and at the same time letting people who need a11y
easily turn it on.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#868558: nmu: multiple r-* packages

[Steve Cotton]

On Sat, Sep 02, 2017 at 08:20:00AM -0500, Dirk Eddelbuettel wrote:
> On 2 September 2017 at 14:57, Steve Cotton wrote:
> | On Thu, Aug 10, 2017 at 12:03:06PM -0500, Dirk Eddelbuettel wrote:
> | > So I continue to argue [2] that we should rebuild these 46, not force all 
> 516.
> | 
> | If I may ask, "why?".
> 
> Because R 3.4.1 is blocked from entering testing.

I should have been more specific with my question.

If I may ask, "why do you want to spend the developer time to rebuild only 46
packages, when there's already an infrastructure that does it for you, at the
cost of rebuilding all 516"?

Regards,
Steve

Bug#874070: rtpproxy: CVE-2017-14114

[Salvatore Bonaccorso]

Source: rtpproxy
Version: 1.2.1-1.1
Severity: grave
Tags: upstream security

Hi,

the following vulnerability was published for rtpproxy.

CVE-2017-14114[0]:
| RTPproxy through 2.2.alpha.20160822 has a NAT feature that results in
| not properly determining the IP address and port number of the
| legitimate recipient of RTP traffic, which allows remote attackers to
| obtain sensitive information or cause a denial of service
| (communication outage) via crafted RTP packets.

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-14114
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14114
[1] https://rtpbleed.com

Regards,
Salvatore

Bug#857060: Hunk #1 FAILED at 231

[Ludovico Cavedon]

package ntopng
tags 857060 + unreproducible
thanks

Hi Jean-Christophe,

On Tue, Mar 7, 2017 at 5:36 PM jean-christophe manciot <
actionmysti...@gmail.com> wrote:

> [...]
>
dpkg-source: info: applying log-filename.patch
> dpkg-source: info: applying no-librt.patch
> dpkg-source: info: applying use-system-ndpi.patch
>
[...]
> dpkg-source: info: building ntopng using existing
> ./ntopng_2.4+dfsg1.orig.tar.gz
> patching file configure.seed
> Hunk #1 FAILED at 231.
> 1 out of 1 hunk FAILED
> dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
> dpkg-source: info: if patch 'no-librt.patch' is correctly applied by
> quilt, use 'quilt refresh' to update it
>
>
I was unable to reproduce this issue, even with a clean clone of the repo
and resetting master to the debian/2.4+dfsg1-2 tag.
Maybe some had gone wrong with the creation of
ntopng_2.4+dfsg1.orig.tar.gz? Maybe because of
https://bugs.debian.org/857590?

Thanks,
Ludovico

Bug#873903: Wheezy update of libidn?

[Tim Rühsen]

On Freitag, 1. September 2017 16:51:18 CEST Raphael Hertzog wrote:
> Dear maintainer(s),
> 
> The Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of libidn:
> https://security-tracker.debian.org/tracker/source-package/libidn
> 
> Would you like to take care of this yourself?

Hi Raphaël,

I asked Ondřej Surý (ond...@debian.org, now in CC) yesterday to do the 
packaging for libidn and libidn2, especially with those CVEs in mind.
And he seems willing, so just coordinate to not do the work twice.

Background: the current maintainers are either hindered by private issues 
(Simon, si...@josefsson.org) or not enough into packaging any more to stem it 
(me).

Personally, I can only offer any help from upstream (things can be fastly done 
if you contact me or better if you open an issue on either libidn or libidn2).

> 
> If yes, please follow the workflow we have defined here:
> https://wiki.debian.org/LTS/Development
> 
> If that workflow is a burden to you, feel free to just prepare an
> updated source package and send it to debian-...@lists.debian.org
> (via a debdiff, or with an URL pointing to the source package,
> or even with a pointer to your packaging repository), and the members
> of the LTS team will take care of the rest. Indicate clearly whether you
> have tested the updated package or not.
> 
> If you don't want to take care of this update, it's not a problem, we
> will do our best with your package. Just let us know whether you would
> like to review and/or test the updated package before it gets released.

I appreciate any work that you do on packaging libidn/libidn2 and if it's ok 
for you, take me out of the review process (I just know too little about 
Debian packaging to review/judge anything from you experts).

Just coordinate with Ondřej.

With Best Regards, Tim


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

Bug#874010: libzip: CVE-2017-14107: memory allocation failure in _zip_cdir_grow (zip_dirent.c)

[Thomas Klausner]

libzip-1.3.0 fixing this and another CVE is now available.
 Thomas

On Fri, Sep 01, 2017 at 11:14:02PM +0200, Salvatore Bonaccorso wrote:
> Source: libzip
> Version: 0.11.2-1.2
> Severity: important
> Tags: security upstream patch fixed-upstream
> 
> Hi,
> 
> the following vulnerability was published for libzip.
> 
> CVE-2017-14107[0]:
> | The _zip_read_eocd64 function in zip_open.c in libzip before 1.3.0
> | mishandles EOCD records, which allows remote attackers to cause a
> | denial of service (memory allocation failure in _zip_cdir_grow in
> | zip_dirent.c) via a crafted ZIP archive.
> 
> 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-14107
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14107
> [1] 
> https://blogs.gentoo.org/ago/2017/09/01/libzip-memory-allocation-failure-in-_zip_cdir_grow-zip_dirent-c/
> [2] 
> https://github.com/nih-at/libzip/commit/9b46957ec98d85a572e9ef98301247f39338a3b5
> 
> Regards,
> Salvatore
> 

Bug#874069: bash: consecutive spaces vanish from a variable in here strings

[Andre Wobst]

Package: bash
Version: 4.4-5
Severity: normal

Dear Maintainer,

I noticed a change in how here strings using a bash variable effect consecutive
spaces compared to earlier debian releases. Consider the following example:

#!/bin/bash
info='a  b'
/bin/cat - <<< $info
/bin/cat - <<< "$info"
/bin/echo $info
/bin/echo "$info"

The result is:

a  b
a  b
a b
a  b

However, on Debian 8, and also various other systems I have at hand, the output 
is:

a b
a  b
a b
a  b

I consider the result I get on Debian 9 to be wrong, but bascially I'm puzzled
about the difference. To me it looks like being related to the different bash
versions, with the newer version being broken, but I might be wrong, though.

Best,


André

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

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

Versions of packages bash depends on:
ii  base-files   9.9+deb9u1
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u1
ii  libtinfo56.0+20161126-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#749826: Documenting `Multi-Arch: foreign`

[Simon McVittie]

On Sat, 02 Sep 2017 at 08:44:14 -0700, Sean Whitton wrote:
> On Sun, Aug 20 2017, Helmut Grohne wrote:
> > A common theme with such cases is to resort to `Multi-Arch: allowed`
> > (e.g. make), but that has the downside of requiring most consumers to
> > attach the :any annotation and that it can never be switched back
> > (because :any dependencies on packages not marked M-A:allowed are
> > unsatisfiable).

That seems like it might be a bug (or design flaw if you prefer). If a
package (build-)depends on foo:any, it is saying "I am only using the
arch-indep parts of foo's interface", whatever those are.

Perhaps a dependency on foo:any by (for example) bar:mips should
always be satisfiable by foo:mips (as though the :any had been omitted),
regardless of foo's multi-arch status? This would bring it back to the
same meaning as omitting the :any, in the trivial case where only one
architecture is enabled.

Perhaps a dependency on foo:any should always be satisfiable by foo:all,
regardless of foo's multi-arch status? (which must be either no or
foreign in this case I think)

Perhaps a dependency on foo:any should be satisfiable by any instance
of foo that is Multi-Arch: foreign? (In this case the :any is completely
redundant, because foreign sets up a similar situation from the other end)

> > * If there is such a conflict, but the relevant packages are not
> >   coinstallable due to package relations, is that ok? Example: libc6
> >   has such a conflict on /lib/ld.so.1 for mips and mipsel.
> >   (Presently, you get an unpack error here.)
> 
> If libc6's use is legitimate then it seems we'd need to include this as
> an exception.

libc6's use is mandated by the distro-independent mips* ABIs, so we
can't avoid it (unless we are willing to make binaries built on
Debian mips unusable on other distros, including older Debian, by
defining a Debian-specific ELF interpreter like
/lib/mips-linux-gnu/ld.so.1).

> > I think "the files installed by ``Architecture: all`` packages always
> > provide architecture-independent interfaces." is too broad. The counter
> > example is haskell-devscripts-minimal. This needs to be weakened
> > somehow.

I would argue that these interfaces are architecture-independent from
the perspective of the package's (lack of) architecture. What they
are not independent of is the *build machine* architecture, just like
running uname -m or inspecting /proc/cpuinfo aren't independent of the
build machine architecture. This is certainly a problem for
cross-compilation, but it isn't the same issue as in dpkg or pkg-config,
where the architecture for which dpkg or pkg-config was built gets
hard-coded into its installed files (as the output of --print-architecture
or part of the default search path, respectively).

> > For instance, the policy should make it
> > clear that marking libmdds-dev `Multi-Arch: foreign` (fictional, see
> > #843023) would be a policy violation.

It is not clear to me that doing so *should* be a policy violation. If
libmdds-dev contains only headers (no shared or static library), and it
exposes architecture-independent libboost-dev headers (but no Boost
shared or static library), is there really anything wrong with having
libboost-dev from "the wrong architecture"?

S

Bug#874014: base-installer: Please use common kernel for all subarchitectures on m68k

[Ben Hutchings]

On Sat, 2017-09-02 at 00:20 +0200, John Paul Adrian Glaubitz wrote:
> Source: base-installer
> Version: 1.171
> Severity: normal
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: m68k
> 
> Hello!
> 
> base-installer currently fails to find a suitable kernel on any
> m68k system during install because it tries to install different
> kernels depending on the subarchitecture.
> 
> Since we have just a common kernel for m68k these days, this
> mechanism no longer works and the kernel installation fails.
> 
> With the attached patch, the kernel/m68k.sh script has been modified
> to use a common kernel on m68k. The corresponding test in kernel/tests/
> m68k has been updated as well.

Why delete the old flavours from the 'unusable' list in the test?

Ben.

> Please consider applying the patch for the next upload.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
   - John
Lennon



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

Bug#838288: mailman: diff for NMU version 1:2.1.23-1.1

[Florz]

Control: tags 838288 + pending

Dear maintainer,

I've prepared an NMU for mailman (versioned as 1:2.1.23-1.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru mailman-2.1.23/debian/changelog mailman-2.1.23/debian/changelog
--- mailman-2.1.23/debian/changelog 2016-09-13 18:01:59.0 +0200
+++ mailman-2.1.23/debian/changelog 2017-09-02 00:42:19.0 +0200
@@ -1,3 +1,10 @@
+mailman (1:2.1.23-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixed broken dependencies in SpamAssassin.py (Closes: #838288)
+
+ -- Florian Schlegel   Sat, 02 Sep 2017 00:42:19 +0200
+
 mailman (1:2.1.23-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mailman-2.1.23/debian/contrib/SpamAssassin.py 
mailman-2.1.23/debian/contrib/SpamAssassin.py
--- mailman-2.1.23/debian/contrib/SpamAssassin.py   2016-09-13 
18:01:59.0 +0200
+++ mailman-2.1.23/debian/contrib/SpamAssassin.py   2017-09-02 
00:42:19.0 +0200
@@ -28,7 +28,6 @@
 from Mailman import Errors
 from Mailman.Logging.Syslog import syslog
 from Mailman.Handlers import Hold
-from Mailman.Handlers.Moderate import matches_p
 
 SPAMD_HOST= getattr(mm_cfg, 'SPAMASSASSIN_HOST', '')
 DISCARD_SCORE = getattr(mm_cfg, 'SPAMASSASSIN_DISCARD_SCORE', 10)
@@ -78,7 +77,7 @@
 if MEMBER_BONUS != 0:
 for sender in msg.get_senders():
 if mlist.isMember(sender) or \
-   matches_p(sender, mlist.accept_these_nonmembers, 
mlist.internal_name()):
+   mlist.GetPattern(sender, mlist.accept_these_nonmembers, 
at_list='accept_these_nonmembers'):
 score -= MEMBER_BONUS
 break
 

Bug#874068: ABI breakage without shared library renaming

[Sébastien Villemot]

Package: libffcall1
Version: 1.13-0.1
Severity: serious
Control: affects -1 clisp libmlpcap-ocaml

Symbol __vacall_r has been dropped from libffcall1 in version 1.13-0.1 and,
contrary to my expectations, this symbol is used by reverse-dependencies
(clisp, libmlpcap-ocaml).

Upstream does not track ABI, so the right fix is to rename the shared library
package (and make it conflict with the old one).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[Tobias Frost]

Am 2. September 2017 15:37:59 MESZ schrieb Carlos Maddela :
>This bug should have been marked done, as it already has been uploaded
>by Tobias Frost. I'm not opposed to adopting the package.
>

That's great! Just prepare another upload for the adoption and I'll sponsor it 
again.


>On 02/09/17 23:29, Mattia Rizzolo wrote:
>> On Sat, Sep 02, 2017 at 03:23:46PM +0200, roucaries bastien wrote:
>>> I can sponsor but I will need to be the maintainer of this package
>not debian-qa
>> ?
>> *you* will need to be the maintainer?  That doesn't make sense for QA
>> upload.
>>
>> BTW, QA uploads do keep Debian QA as maintainer, see
>>
>https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload
>>


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

[Holger Levsen]

Hi Guillem,

On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
> > during discussing #844431 it became clear, that some information about the
> > running kernel should be included in .buildinfo files, as this can affect 
> > the
> > build.
> 
> It is actually not very clear to me. The examples provided there seem
> bogus:
> 
> * Any build that relies on the currently running kernel for the
>   resulting object is broken, and needs to be fixed. The host kernel
>   might/should/will have nothing to do with the build one.
> * Builds that embed build kernel information should be fixed to not
>   do that, as that information should be irrelevant for the generated
>   object.
> * Builds breaking on kernel changing the version schema should only
>   affect things such as kernel modules or similar, anything else is
>   also broken. Any kernel version checks, if at all, should always
>   be done at run-time.
> * Builds breaking due to disabled functionality in the current running
>   kernel should be considered broken. In case of the test suite
>   failing, that should be fixed to skip those tests gracefully. In
>   case of the build system breaking, that should be reworked to not
>   use that functionality (which I'd assume is unportable?).

good points. (just having information on the kernel *can* be helpful, even
though it *should* not matter, but when it (wrongly) does, it is helpful…)
 
> > For a start, including the output of "uname -s -r -v -m -i -o" (so basically
> > uname -a without the hostname) would be better than the current status quo,
> > though it would probably be even nicer to also include a hash of
> > /proc/config.gz or maybe even the whole thing.
> 
> In addition to the above, I'm actually somewhat uncomfortable with this
> request, as it looks like a massive privacy leak. Compared to package
> lists and versions, which are actually requested by the package being
> built and might not have anything to do with the main system this
> build was being run on (say a chroot for example), or might get deleted
> immediately after the build. The kernel tends to be a system-wide
> resource, that even if upgraded does not mean it will be running (until
> a reboot).

on reflection I agree that the privacy implications are too bad.

[more insightful stuff I cannot disagree with removed.]
 
> Given all the above, I'm inclined to just close the report? :)

Probably, maybe, just please keep it open for another week or two for now, so 
others can chime in…

Thanks!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#749826: Documenting `Multi-Arch: foreign`

[Sean Whitton]

Hello Helmut,

On Sun, Aug 20 2017, Helmut Grohne wrote:

>> - I couldn't figure out how to include this text, because I didn't
>>   understand it:
>> 
>> For instance, using dpkg --print-architecture can be used to emit the
>> native architecture even though dpkg is marked Multi-Arch:
>> foreign. Similarly, calling pkg-config (without a prefix) will behave
>> differently on different architectures as its search path is
>> architecture-dependent even thoug pkg-config is marked Multi-Arch:
>> foreign.
>> 
>>   Are you saying that packages that depend or implicitly depend on dpkg
>>   or pkg-config cannot be Multi-arch: foreign, although dpkg and
>>   pkg-config themselves are Multi-arch: foreign?  Why are dpkg and
>>   pkg-config Multi-arch: foreign, if they provide these
>>   architecture-dependent interfaces?
>
> Those are very good questions and clarifying them will lead to a better
> understanding of what we have to put into policy. You do understand that
> "dpkg --print-architecture" is part of dpkg's interface. Yet its out
> varies with its architecture. Taking this strictly would indeed imply
> that dpkg is wrongly marked. Similarly, running pkg-config may result in
> architecture-dependent paths and thus our strict interpretation would
> result in rejecting the foreign marking.
>
> A common theme with such cases is to resort to `Multi-Arch: allowed`
> (e.g. make), but that has the downside of requiring most consumers to
> attach the :any annotation and that it can never be switched back
> (because :any dependencies on packages not marked M-A:allowed are
> unsatisfiable).
>
> This is where I thought about README.multiarch:
>
>> - I didn't include your TODO about README.multiarch; let me know whether
>>   you have a more concrete idea about the purpose of that file
>
> It can document assumptions one makes about users of a package. For
> instance, we expect dpkg users to use `dpkg --print-architecture`
> diagnostically only. Similarly, we expect that package builds call
> pkg-config if they mean the build architecture and they need to call
> $(DEB_HOST_GNU_TYPE)-pkg-config if they mean the host architecture.
> Indeed that happens automatically for autotools projects that happen to
> use PKG_CHECK_MODULES or PKG_PROG_PKG_CONFIG (i.e. most). It also
> happens for cmake when built with dh_auto_build.
>
> Let me give a counter example to illustrate more of the point.
> haskell-devscripts-minimal is an `Architecture: all` package with some
> shell scripts. Sounds like a good candidate for `Multi-Arch: foreign`.
> When you look at /usr/share/haskell-devscripts/Dh_Haskell.sh though, you
> see that functions such as cpu(), os(), etc. specifically introspect the
> build architecture by using the build architecture ghc. Such usage is
> not ok for `Multi-Arch: foreign` (#769377).
>
> I believe that policy should encourage some uniform way to document the
> intended interface as we have several cases where this is not obvious.
> README.multiarch may be that way. In particular, using a package in a
> way not permitted by such README.multiarch would need to be a policy
> violation on its own. For instance, one could depend on a shared library
> and declare it an implementation detail. Relying on the transitive
> dependency would then be considered a policy violation.

Rather than introduce the new terminology 'intended interface', which we
would definitely have to define, how about something like this:

If all a package's architecture-dependent interfaces are listed in
README.multiarch, the package is not considered to have any
architecture-dependent interfaces for the purposes of determining
whether it may be labelled Multi-Arch: foreign.

Then we have a separate section explaining what to put in
README.multiarch, and explaining how depending package maintainers
must respond to the information in that file.

>> - after we've got text documenting the other possible values of the
>> Multi-Arch: field, we might want to promote the list of things to
>> consider out of the Multi-Arch: foreign subsubsection.  It should
>> become clear once we've got that other text together.
>
> Indeed, documenting `Multi-Arch: same` may be easier (or not). For the
> purpose of defining it, we shall call Debian binary packages for
> different architectures with equal binary package name and version
> "instances" of a package. I currently see the following requirements:
>
>  * It must not be used on `Architecture: all` packages (though I wish
>you could ;).
>
>  * Given any two instances of a package and any filename, that filename
>must be non-existent in at least one package or the type (directory /
>regular file / etc.) must match and when the filename refers to a
>regular file, the contents must be bitwise equal in both instances.
>
>This point deserves some more thought as it has some pitfalls:
>
> * If there is such a conflict, but the relevant packages are not
>  

Bug#720177: `git debrebase` UI

[Sean Whitton]

Hello Ian,

Your explanations in the e-mail to which I'm replying helped me a lot --
thanks.

On Tue, Aug 22 2017, Ian Jackson wrote:

>> debrebase needs to warn the user that they should expect to see non-ff
>> push errors from git until they finish the debrebase.  It might even
>> leave behind a hook so that after the non-ff push error, there could be
>> a hint about finishing the debrebase, but that might be too unpleasant
>> to implement.
>
> By `finish the debrebase' you mean `turn the branch from Stripped to
> Pushed or Pushable by adding a psuedomerge'.

Yes.

> By `during push' I meant `during dgit push'.  But of course in a
> post-dsc world, there would only be `git push' so there would have to
> be an invocation of `git-debrebase'.  The most natural implementation
> seems to me to be `git-debrebase push'.
>
> I don't know what potential hook you are talking about.  I don't think
> there is a facility for extending `git push' in this way.

.git/hooks/pre-push.sample seems to be the place.

>> > I think you are proposing to expose A, B and D to the user and to
>> > hide C by somehow always reattaching a pseudomerge after each
>> > rebase.  But I don't think git-rebase can do that.
>> 
>> Why not?
>
> Suppose we are in state Rebasing.  Ie we are in the middle of
> `git-rebase' (whether stopped due to -i or a conflict or something).
> The user deals with whatever it is, and runs `git-rebase --continue'.
>
> Suppose there are no further reasons to stop.  git-rebase will
> generate the linear branch appropriately.  But I am not aware of any
> way to cause git-rebase to make an appropriate pseudomerge before
> returning control to the user.
>
> git-rebase --preserve-merges is no good, because even aside from the
> weirdness mentioned in the BUGS section of git-rebase(1), there is no
> way to tell git how the pseudomerge should be generated.
>
> (thoughts)
>
> Hrm.  I guess we could feed git-rebase an `exec' thing in its
> instruction list.  This might work, but there is another problem with
> the model which tries to hide the state Stripped from the user.
>
>> > Ie, the user might do
>> >   git-debrebase -i --autosquash
>> 
>> I don't understand this command.  In my head, debrebase performs two
>> atomic operations: (i) laundering the branch; and (ii) reattaching the
>> pseudomerge before push.
>
> I think you mean, it performs, in any one invocation, one of those two
> operations.  (i) takes the branch from most states I discuss above to
> Stripped and (ii) takes the branch from Stripped to Pushed or
> Pushable.
>
> But this is asking the user to do extra typing: they have to run
> `git-debrebase launder' before running `git-rebase -i'.  Worse, if
> they forget to do so they will get some kind of strange mess where
> git-rebase tries to reapply the pseudomerge as a cherry pick.
>
> Better to let the user get into the habit of always saying
> `git-debrebase'.  Additionally, `git-debrebase' knows what the correct
> rebase point is.  (Assuming the user does not want to rewrite changes
> to debian/; if they do they need to take more manual control.)
>
> So in my imagination, git-debrebase is usually a wrapper around
> git-rebse which magically knows the right base.
> [...]
>> If I'm on the right lines, it might be unwise to wrap `git rebase`.  Git
>> users are pretty good at that command; if we leave them to invoke it,
>> they stand a better chance of understanding the whole workflow.  But I'm
>> not sure.
>
> That is a plausible argument.  The problem is that git-rebase is a
> bit of a footgun - more so in the presence of pseudomerges.

I think that my concerns about failing to leverage user's existing
understanding of git-rebase(1) can be answered by doing the following:

  - state that git-debrebase(1) is ONLY: a wrapper around git-rebase(1)
that magically knows the base
  - have ALL arguments to git-debrebase(1) get passed straight to
git-rebase(1), i.e., no subsubcommands
  - move the other functionality (`git debrebase push`, new upstream
version command) to other subcommands of `git`, e.g. `git
debpush`, `git debnewupstream` etc.

The point of this is to make it much easier to get a grip on exactly
what `git debrebase` does.  That is a foundational piece of
understanding of the workflows surrouding these tools.

It might seem inelegant to have multiple subcommands (especially `git
debpush` which sounds almost like `dgit push`) but I think that it's a
price worth paying.  There's also a mnemonic at work: "ah, `git
debrebase` is a wrapper around `git rebase`, and `git debpush` is a
wrapper around `git push`".

>> I'm also confused about what `git debrebase --continue` could mean.
>> (ii) will always end the debrebase, but `git rebase --continue` doesn't
>> always end the rebase.  Is this another case where debrebase is wrapping
>> a plain rebase?
>
> `git-debrebase --continue' is a hypothetical wrapper around
> `git-rebase --continue' which arranges to reattach the psuedomerge.
> It 

Bug#874065: unrar-free: Should unrar-free be removed from the archive? Alternatives (libarchive) exists; unmaintained upstream

[Salvatore Bonaccorso]

Source: unrar-free
Severity: important

Hi

Given the discussion from
http://www.openwall.com/lists/oss-security/2017/08/20/1 (I filled
separate bugs about the individual issues), should unrar-free be
removed from unstable and thus not be included in buster?

This has the consequence that there are broken dependencies which
first needs to be either resolved or removed as well along:

cut-cut-cut-cut-cut-cut-
dak rm --suite=sid -n -R unrar-free
Will remove the following packages from sid:

unrar-free | 1:0.0.1+cvs20140707-1 | source, hurd-i386
unrar-free | 1:0.0.1+cvs20140707-1+b2 | amd64, arm64, armel, armhf, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x

Maintainer: Ying-Chun Liu (PaulLiu) 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
forensics-extra: forensics-extra
python-rarfile: python-rarfile
python3-rarfile

Dependency problem found.

cut-cut-cut-cut-cut-cut-

Regards,
Salvatore

Bug#874067: tendermint-go-common: github homepage says "DEPRECATED (moved to tendermint/tmlibs)"

[Edward Betts]

Source: tendermint-go-common
Severity: minor

Dear Maintainer,

The homepage for this package is https://github.com/tendermint/go-common

It features this message: "DEPRECATED (moved to tendermint/tmlibs)"

Maybe the homepage needs updating, or tmlibs needs packaging.

Regards,
--
Edward.

Bug#874066: tendermint-go-merkle: project home page has moved

[Edward Betts]

Source: tendermint-go-merkle
Severity: minor

Dear Maintainer,

The package homepage is set to https://github.com/tendermint/go-merkle

If you visit the github page you'll see a note that says:

"DEPRECATED (moved to merkleeyes/iavl and tendermint/tmlibs)"

Thanks,
-- 
Edward.

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[Tobias Frost]

Am 2. September 2017 15:35:14 MESZ schrieb roucaries bastien 
:

>It is a huge changelog for a qa upload.

QA uploads are not limited in terms of changes. Contraire it should fix as much 
as possible. Adopting is great but not required.


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#874064: add --exclude-non-installed option

[積丹尼 Dan Jacobson]

Package: apt-show-versions
Version: 0.22.7

Man page says

   OPTIONS
   If you don't give any options the status of all installed packages is
   printed.

This is no longer true,

$ apt-show-versions
abiword:amd64/unstable 3.0.2-3 uptodate
abiword:i386 not installed
...

Therefore a new option, --exclude-non-installed, or
--include-non-installed is needed.

Or the man page should be revised, and mention if
| grep -v 'not installed$'
is the best way to exclude non installed.

Bug#834667: django-modeltranslation: FTBFS in testing (type object 'TestModel' has no attribute '_deferred')

[Herbert Fortes]

Hi,

It seems that this bug was fixed by the upstream. Just
need to upgrade to the last release. (5 Apr - 0.12.1)
I can do that if you allow 
me.

==
ERROR: setUpClass (modeltranslation.tests.tests.ModeltranslationTransactionTest)
--
Traceback (most recent call last):

|

[...]

 File "/<>/modeltranslation/translator.py", line 427, in register
opts = self._get_options_for_model(model, opts_class, **options)
  File "/<>/modeltranslation/translator.py", line 547, in 
_get_options_for_model
if model._deferred:
AttributeError: type object 'TestModel' has no attribute '_deferred'


Please check:

 - https://github.com/deschler/django-modeltranslation/issues/381



Regards,
Herbert

|

Bug#874063: [PATCH] Document.pod minor cleanup including rendered column alignment

[Dan Jacobson]

Package: libxml-libxml-perl
Version: 2.0128+dfsg-3
Severity: wishlist
File: /usr/lib/x86_64-linux-gnu/perl5/5.26/XML/LibXML/Document.pod

--- /usr/lib/x86_64-linux-gnu/perl5/5.26/XML/LibXML/Document.pod
2016-07-24 17:05:45.0 +0800
+++ /tmp/Document.pod   2017-09-02 21:47:47.571038913 +0800
@@ -243,8 +243,6 @@
 returns the XML as a byte string in the original encoding of the document (see
 the actualEncoding() method)! This means you can simply do:
 
-
-
   open my $out_fh, '>', $file;
   print {$out_fh} $doc->toString;
 
@@ -345,7 +343,6 @@
 You may also pass in a L<< XML::LibXML::Dtd >> object, to validate 
against an external DTD:
 
 
-
   if (!$dom->is_valid($dtd)) {
warn("document is not valid!");
}
@@ -359,7 +356,7 @@
 valid it will throw an exception containing the error. This allows you much
 better error reporting than simply is_valid or not.
 
-Again, you may pass in a DTD object
+Again, you may pass in a DTD object.
 
 
 =item documentElement
@@ -462,10 +459,9 @@
 not be expanded to a real entity reference unless it is a predefined entity
 
 
-
   my $string = "";
-   $some_element->appendText( $string );
-   print $some_element->textContent; # prints "foo;"
+  $some_element->appendText( $string );
+  print $some_element->textContent; # prints "foo;"
 
 
 =item createInternalSubset
@@ -477,29 +473,25 @@
 need to add the created node explicitly to the document.
 
 
-
   my $document = XML::LibXML::Document->new();
-   my $dtd  = $document->createInternalSubset( "foo", undef, "foo.dtd" );
+  my $dtd  = $document->createInternalSubset( "foo", undef, "foo.dtd" );
 
 will result in the following XML document:
 
 
-
   
-   
+  
 
 By setting the public parameter it is possible to set PUBLIC DTDs to a given
 document. So
 
 
-
   my $document = XML::LibXML::Document->new();
   my $dtd  = $document->createInternalSubset( "foo", "-//FOO//DTD FOO 
0.1//EN", undef );
 
 will cause the following declaration to be created on the document:
 
 
-
   
   
 

Bug#874061: unrar-free: null pointer dereference

[Salvatore Bonaccorso]

Source: unrar-free
Version: 1:0.0.1+cvs20140707-1
Severity: grave
Tags: security upstream

Hi

>From http://www.openwall.com/lists/oss-security/2017/08/20/1


Issue 3: Null pointer

A malformed input file can cause a null pointer read.

==3328==ERROR: AddressSanitizer: SEGV on unknown address 0x0020 (pc 
0x0051ed2c bp 0x00278b18 sp 0x7fffc410e300 T0)
==3328==The signal is caused by a READ memory access.
==3328==Hint: address points to the zero page.
#0 0x51ed2b in DecodeNumber /f/unrar-gpl/unrar/src/unrarlib.c:1649:16
#1 0x5186f5 in Unpack /f/unrar-gpl/unrar/src/unrarlib.c:1148:4
#2 0x511c47 in ExtrFile /f/unrar-gpl/unrar/src/unrarlib.c:799:10
#3 0x510b02 in urarlib_get /f/unrar-gpl/unrar/src/unrarlib.c:303:13
#4 0x50b249 in unrar_extract_file /f/unrar-gpl/unrar/src/unrar.c:343:8
#5 0x50be32 in unrar_extract /f/unrar-gpl/unrar/src/unrar.c:483:9
#6 0x50c69c in main /f/unrar-gpl/unrar/src/unrar.c:556:14
#7 0x7f0a337df4f0 in __libc_start_main (/lib64/libc.so.6+0x204f0)
#8 0x419e19 in _start (/r/unrar-gpl/unrar+0x419e19)

Regards,
Salvatore


unrar-gpl-nullptr.rar
Description: application/rar

Bug#874062: [PATCH] clarify --filename-only is not a directory excluder

[積丹尼 Dan Jacobson]

Package: dlocate
Version: 1.07+nmu1
Severity: wishlist

--- /tmp/dlocate.1  2017-09-02 22:53:55.852378173 +0800
+++ /tmp/dlocate.1.new  2017-09-02 22:56:53.899209145 +0800
@@ -156,11 +156,13 @@
 .SH OPTIONS
 .TP
 .BR \-\^\-filename\-only
-Only output file names when searching for files
+Only output file and directory names when searching for files. Omit
+the "package:" prefix.
 
 .TP
 .BR \-\^\-package\-only
-Only output package names when searching for files
+Only output package names when searching for files. Omit file and
+directory names.
 
 .TP
 .BR \-w ", " \-\^\-word\-regexp

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Alex ARNAUD]

Le 02/09/2017 à 16:28, Lisandro Damián Nicanor Pérez Meyer a écrit :

I'm really open to suggestions. at-spi2-core is being installed by default on
standard installations, so we are inflicting a huge performance drawback to
most of our users. On the other hand people needing a11y really need to get
this on as simple as possible.


Primary, could you explain why you tell us that? In which case you've 
noticed issue? I'm running Debian 8.9 with QT accessibility enabled 
without any performance issue.



I'm pretty sure that if all the interested parties try we can find a good
technical solution to this.


Indeed. I wait to reproduce and to understand your use-case before to 
participate to a debate to figure out your issue.


Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Bug#874059: unrar-free: directory traversal vulnerability

[Salvatore Bonaccorso]

Source: unrar-free
Version: 1:0.0.1+cvs20140707-1
Severity: grave
Tags: security upstream

Hi

>From http://www.openwall.com/lists/oss-security/2017/08/20/1

Issue 1: Directory Traversal

Creating a rar v2 archive with path names of the form ../[filename]
will unpack them into the upper directory.

Attached Hanno's POC.

Regards,
Salvatore


unrar-gpl-directory-traversal.rar
Description: application/rar

Bug#874060: unrar-free: stack overread vulnerability

[Salvatore Bonaccorso]

Source: unrar-free
Version: 1:0.0.1+cvs20140707-1
Severity: grave
Tags: security upstream

Hi

>From http://www.openwall.com/lists/oss-security/2017/08/20/1 

Issue 2: Stack overread

A malformed archive can cause a stack overread, detectable with asan.
This issue doesn't happen reliably, I haven't investigated further.

==2585==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7fff76184120 at pc 0x00445d25 bp 0x7fff76183ef0 sp 0x7fff761836a0
READ of size 519 at 0x7fff76184120 thread T0
#0 0x445d24 in __interceptor_strchr.part.33 (/r/unrar-gpl/unrar+0x445d24)
#1 0x516d0d in stricomp /f/unrar-gpl/unrar/src/unrarlib.c:851:19
#2 0x511613 in ExtrFile /f/unrar-gpl/unrar/src/unrarlib.c:745:20
#3 0x510b02 in urarlib_get /f/unrar-gpl/unrar/src/unrarlib.c:303:13
#4 0x50b249 in unrar_extract_file /f/unrar-gpl/unrar/src/unrar.c:343:8
#5 0x50be32 in unrar_extract /f/unrar-gpl/unrar/src/unrar.c:483:9
#6 0x50c69c in main /f/unrar-gpl/unrar/src/unrar.c:556:14
#7 0x7f632d3834f0 in __libc_start_main (/lib64/libc.so.6+0x204f0)
#8 0x419e19 in _start (/r/unrar-gpl/unrar+0x419e19)

Address 0x7fff76184120 is located in stack of thread T0 at offset 544 in frame
#0 0x516c1f in stricomp /f/unrar-gpl/unrar/src/unrarlib.c:844

  This frame has 2 object(s):
[32, 544) 'S1'
[608, 1120) 'S2' <== Memory access at offset 544 partially
underflows this variable

Regards,
Salvatore


unrar-gpl-stack-overread.rar
Description: application/rar

Bug#874058: python3-zeep: Syntax error when trying to install python3-zeep

[Sterling Hubbard]

Package: python3-zeep
Version: 0.23.0-2~8jessie+1
Severity: important

Dear Maintainer,

I get a syntax error when I attempt to install python3-zeep. The package
description says it's compatible with python3.4 however it has been
suggested to me that the syntax used in installation is only valid in
python3.5.

Setting up python3-zeep (0.23.0-2~8jessie+1) ...
  File "/usr/lib/python3/dist-packages/zeep/asyncio/transport.py",
line 34
async def _load_remote_data_async():
^
SyntaxError: invalid syntax

  File "/usr/lib/python3/dist-packages/zeep/asyncio/bindings.py",
line 8
async def send(self, client, options, operation, args, kwargs):
^
SyntaxError: invalid syntax

dpkg: error processing package python3-zeep (--configure):
 subprocess installed post-installation script returned error exit
status 1

Thanks.

-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages python3-zeep depends on:
ii  python3-appdirs  1.3.0-2
ii  python3-cached-property  1.3.0-2~8jessie+1
ii  python3-defusedxml   0.4.1-2
ii  python3-freezegun0.1.18-1
ii  python3-isodate  0.5.0-1
ii  python3-lxml 3.4.0-1
ii  python3-pkg-resources33.1.1-1~bpo8+1
ii  python3-requests 2.11.1-1~bpo8+1
ii  python3-six  1.10.0-3~bpo8+1
ii  python3-tz   2012c+dfsg-0.1
pn  python3:any  

python3-zeep recommends no packages.

python3-zeep suggests no packages.

-- no debconf information

Bug#873962: sweethome3d: Random crash when opening/manipulating a file

[Markus Koschany]

Am 01.09.2017 um 20:38 schrieb Ludovic Lebègue:
> Hi,
> 
> I attached a screencast of how sweethome3d crashed.
> When I tried again I had a java crash log file was generated :
> hs_err_pid6245.log (attached). 
> 
> Tell me if you need me to do some other tests.

Hi,

thanks for your screencast. It looks like we both use similar setups,
Debian Testing and GNOME 3. However I am unable to reproduce the crash
on my system and I presume it is related to our graphic stack. I'm still
using an old Radeon card with the respective open source driver whereas
you are using a Nvidia card and the nouveau driver. The crash appears
definitely related to graphics functions but I don't know exactly how to
proceed here. I believe opening an upstream bug report for OpenJDK and
reassigning the package to src:openjdk-8 would be in order.

We also had some trouble with the Java AWT wrapper. Could you try to
disable the line

assistive_technologies=org.GNOME.Accessibility.AtkWrapper

in /etc/java-8-openjdk/accessibility.properties

and tell us whether it makes any difference for you?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#874056:

[H.-Dirk Schmitt]

Problem is that the init-script is using /usr/sbin/pure-ftpd-wrapper
for the startup.

This wrappers ignores the file /etc/pure-ftpd/pure-ftpd.conf.

So a removal of /etc/pure-ftpd/pure-ftpd.conf will help to avoid the
mess of confusion.

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 2 de septiembre de 2017 16:18:16 -03 Sebastian Humenda wrote:
> Hi
> 
> Lisandro Damián Nicanor Pérez Meyer schrieb am 02.09.2017, 11:02 -0300:
> >According to [upstream] setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
> >huge negative performace impact on Qt, so it should not be enabled by
> >default. And, if I understand correctly, this is the current behavior.
> >
> >Upstream suggested that maybe we should try to only set this variable if
> >the appropriate hardware is found. Do you have any ideas on how we could
> >achieve this?
> 
> This is not a good idea, because not all screen reader users have dedicated
> hardware. Users only using speech for navigation would be without Qt a11y.
> Couldn't we detect whether a screen reader (Orca) is installed, or is this a
> default on Desktop systems, these days?

I'm really open to suggestions. at-spi2-core is being installed by default on 
standard installations, so we are inflicting a huge performance drawback to 
most of our users. On the other hand people needing a11y really need to get 
this on as simple as possible.

I'm pretty sure that if all the interested parties try we can find a good 
technical solution to this.

-- 
Confucius say: He who play in root, eventually kill tree.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#874057: ITP: node-setprototypeof -- Small polyfill for Object.setprototypeof

[Kartik Kulkarni]

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

* Package name: node-setprototypeof
  Version : 1.0.3
  Upstream Author : Wes Todd
* URL : https://github.com/wesleytodd/setprototypeof
* License : ISC
  Programming Lang: JavaScript
  Description : Small polyfill for Object.setprototypeof
  A simple cross platform implementation to set the prototype of
  an instianted object.
  .
  Supports all modern browsers and
  at least back to IE8.
  .
  Node.js is an event-based server-side JavaScript engine.

  It is a dependency of gitlab 9

  I am not a debian member and would like to maintain this package for
a long term
  and would like to join the javascript maintainers group, Praveen had
agreed to sponsor this package.

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[Mattia Rizzolo]

On Sat, Sep 02, 2017 at 03:35:14PM +0200, roucaries bastien wrote:
> I means that I will
> prefer that carlos maddela will become the maint of this package.
> 
> It is a huge changelog for a qa upload.

Oh, I see what you mean now.
Well, I understand your point, even if I don't deem it necessary :)

-- 
regards,
Mattia Rizzolo

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

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Sebastian Humenda]

Hi

Lisandro Damián Nicanor Pérez Meyer schrieb am 02.09.2017, 11:02 -0300:
>According to [upstream] setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
>huge negative performace impact on Qt, so it should not be enabled by
>default. And, if I understand correctly, this is the current behavior.
>
>Upstream suggested that maybe we should try to only set this variable if
>the appropriate hardware is found. Do you have any ideas on how we could
>achieve this?
This is not a good idea, because not all screen reader users have dedicated
hardware. Users only using speech for navigation would be without Qt a11y.
Couldn't we detect whether a screen reader (Orca) is installed, or is this a
default on Desktop systems, these days?

Cheers
Sebastian


signature.asc
Description: PGP signature

Bug#874056: pure-ftpd - configuration file not used: /etc/pure-ftpd/pure-ftpd.conf

[H.-Dirk Schmitt]

Package: pure-ftpd
Version: 1.0.46-1

The pure-ftpd package is installing the configuration file /etc/pure-
ftpd/pure-ftpd.conf.


This file isn't used by the init-script - see journal:

Sep 02 16:04:35 nermal pure-ftpd[15002]: Starting ftp server: Running:
/usr/sbin/pure-ftpd -l pam -E -u 1000 -J HIGH -O clf:/var/log/pure-
ftpd/transfer.log -8 UTF-8 -B


So any changes due this file are useless.


So please either remove this file to avoid confusions for the users or
change the init-script to use it 

Bug#874055: RM: fprobe-ulog -- RoQA; useless with kernels 3.17+

[Adam Borowski]

Package: ftp.debian.org
Severity: normal

Hi!
This package requires ULOG, which has been removed from the kernel in commit
7200135bc1e61f1437dc326ae2ef2f310c50b4eb (in 3.17).  Thus, there's no point
in keeping it anymore.

Technically, it's possible to run Buster with Jessie's kernel (3.16), but
fixing the FTBFS is not worth anyone's tuits.

Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Lisandro Damián Nicanor Pérez Meyer]

Package: at-spi2-core
Version: 2.24.1-2
Severity: important

According to [upstream] setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
huge negative performace impact on Qt, so it should not be enabled by
default. And, if I understand correctly, this is the current behavior.

Upstream suggested that maybe we should try to only set this variable if
the appropriate hardware is found. Do you have any ideas on how we could
achieve this?

[upstream]


Trying to improve everyone's experience, Lisandro.

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

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

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.24.1-2
ii  libc6  2.24-17
ii  libdbus-1-31.11.16+really1.10.22-1
ii  libglib2.0-0   2.53.6-1
ii  libx11-6   2:1.6.4-3
ii  libxtst6   2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

Bug#874053: ITP: node-encodeurl -- Encode URL to a percent-encoded form

[Kartik Kulkarni]

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

* Package name: node-encodeurl
  Version : 1.0.1
  Upstream Author : Douglas Christopher Wilson
* URL : https://github.com/pillarjs/encodeurl#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Encode URL to a percent-encoded form
  Encode a URL to a percent-encoded form, excluding already-encoded
  sequences.
  .
  Encodeurl will take an already-encoded URL and
  encode all the non-URL code points (as UTF-8 byte sequences).
  .
  This encode is meant to be "safe" and does not throw errors.
  It will try as hard as it can to properly encode the given URL,
  including replacing any raw, unpaired surrogate pairs with the
  Unicode replacement character prior to encoding.
  .
  Node.js is an event-based server-side JavaScript engine.

  It is a dependency of gitlab 9

  I am not a debian member and would like to maintain this package for
a long term
  and would like to join the javascript maintainers group, Praveen had
agreed to sponsor this package.

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[roucaries bastien]

On Sat, Sep 2, 2017 at 3:29 PM, Mattia Rizzolo  wrote:
> On Sat, Sep 02, 2017 at 03:23:46PM +0200, roucaries bastien wrote:
>> I can sponsor but I will need to be the maintainer of this package not 
>> debian-qa
>
> ?
> *you* will need to be the maintainer?  That doesn't make sense for QA
> upload.
>
> BTW, QA uploads do keep Debian QA as maintainer, see
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload

Sorry send for a phone with french correction. I means that I will
prefer that carlos maddela will become the maint of this package.

It is a huge changelog for a qa upload.

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

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[Carlos Maddela]

This bug should have been marked done, as it already has been uploaded
by Tobias Frost. I'm not opposed to adopting the package.


On 02/09/17 23:29, Mattia Rizzolo wrote:
> On Sat, Sep 02, 2017 at 03:23:46PM +0200, roucaries bastien wrote:
>> I can sponsor but I will need to be the maintainer of this package not 
>> debian-qa
> ?
> *you* will need to be the maintainer?  That doesn't make sense for QA
> upload.
>
> BTW, QA uploads do keep Debian QA as maintainer, see
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload
>




signature.asc
Description: OpenPGP digital signature

Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

[Roberto Oliveira]

Hi Andrey,

I found something wrong in the last version I sent, so I just sent a
new version.

So in case you already did a "dget -x", please, do it again.


Regards,
Roberto Oliveira.

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[Mattia Rizzolo]

On Sat, Sep 02, 2017 at 03:23:46PM +0200, roucaries bastien wrote:
> I can sponsor but I will need to be the maintainer of this package not 
> debian-qa

?
*you* will need to be the maintainer?  That doesn't make sense for QA
upload.

BTW, QA uploads do keep Debian QA as maintainer, see
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#868558: nmu: multiple r-* packages

[Steve Cotton]

On Thu, Aug 10, 2017 at 12:03:06PM -0500, Dirk Eddelbuettel wrote:
> But the whole point of my bug report, and write up, is that
> 
>46
> 
> out of 516 package need a rebuild.
> 
> So I continue to argue [2] that we should rebuild these 46, not force all 516.

If I may ask, "why?".

When you find yourself sending this to the debian-devel mailing
list ...

> - I filed it on July 16.
> - I followed up on July 29.
> - I followed up on August 6.
> - I answered a question on August 10.
> - I followed up on August 19.
> - I answered a question on August 26, and followed up on August 26.
>
> I am at wits end.
> 
> Dirk

... please, consider the price it's having on your sanity.

It seems that the whole set of R packages is 0.5GB of binaries.
By comparison, a minor bugfix in texlive-bin results in a 1GB
download for anyone who's installed it from Unstable.

Regards,
Steve

Bug#868962: Reported upstream (Was: Bug#868962: python-skbio: FTBFS: Test failures)

[Andreas Tille]

Hi,

I have reported the issue upstream:

   https://github.com/biocore/scikit-bio/issues/1531

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[roucaries bastien]

I can sponsor but I will need to be the maintainer of this package not debian-qa

On Wed, Aug 30, 2017 at 6:01 PM, Carlos Maddela  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "liboauth"
>
>  * Package name: liboauth
>Version : 1.0.3-1
>Upstream Author : Robin Gareus 
>  * URL : http://liboauth.sourceforge.net/
>  * License : Expat
>Section : libs
>
>   It builds these binary packages:
>
> liboauth-dev - C library implementing OAuth Core 1.0a API (development 
> files)
> liboauth0  - C library implementing OAuth Core 1.0a API (runtime)
>
>   To access further information about this package, please visit the 
> following URL:
>
>   https://mentors.debian.net/package/liboauth
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/libo/liboauth/liboauth_1.0.3-1.dsc
>
>   More information about my changes can be obtained from this git repo:
>   https://github.com/e7appew/pkg-liboauth.git.
>
>   Changes since the last upload:
>
>   * QA upload.
>   * New upstream release [1.0.3].
>   * Bump Standards-Version to 4.1.0 and debhelper compat level to 10.
>   * debian/control:
> - Update maintainer to Debian QA Group.
> - Update VCS URLs to use secure protocols.
> - Mark liboauth-dev package as Multi-Arch: same.
> - Rewrite package descriptions. Thanks to Martin Eberhard Schauer
>   and Justin B Rye. (Closes: #654334)
> - Perform wrap-and-sort.
> - Add build dependency on curl.
>   * debian/rules:
> - Simplify clean-up rule.
> - Build with all hardening flags set.
> - Suppress warnings about use of deprecated functions.
> - Enable LFS support on 32-bit architectures.
>   * Update library's symbols file to include the functions available
> when built with command-line curl feature.
>   * Suppress debian-watch-may-check-gpg-signature Lintian warning.
>   * debian/copyright:
> - Update details.
> - Remove redundancy.
> - Use Expat as license identifier, in preference to MIT, since
>   it matches this specifically.
>   * debian/patches/*:
> - Regenerate with git-buildpackage.
> - Drop 01_fix_manpage_spelling_errors.patch already applied upstream.
> - Fix newly detected typos in man page.
> - Update configure.ac for Autoconf 2.69.
> - Update Makefile.am files for Automake 1.15.
>
>   Regards,
>Carlos Maddela
>

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 2 September 2017 at 14:57, Steve Cotton wrote:
| On Thu, Aug 10, 2017 at 12:03:06PM -0500, Dirk Eddelbuettel wrote:
| > But the whole point of my bug report, and write up, is that
| > 
| >46
| > 
| > out of 516 package need a rebuild.
| > 
| > So I continue to argue [2] that we should rebuild these 46, not force all 
516.
| 
| If I may ask, "why?".

Because R 3.4.1 is blocked from entering testing.

"Our priorities are our users".

I personally do not care [1] but _I_ have been asked by R Core (as their
usual contact person for things Debian, which some of them use) why the
current R is still on in testing.

I am only trying to help...
 
| When you find yourself sending this to the debian-devel mailing
| list ...
| 
| > - I filed it on July 16.
| > - I followed up on July 29.
| > - I followed up on August 6.
| > - I answered a question on August 10.
| > - I followed up on August 19.
| > - I answered a question on August 26, and followed up on August 26.
| >
| > I am at wits end.
| > 
| > Dirk
| 
| ... please, consider the price it's having on your sanity.

An email every couple of weeks is nothing. If you want to question my sanity,
look at my github commits, my CRAN uploads and my r-cran-* uploads. You'd
have a much better point.
| 
| It seems that the whole set of R packages is 0.5GB of binaries.
| By comparison, a minor bugfix in texlive-bin results in a 1GB
| download for anyone who's installed it from Unstable.

What's the point?  I am not talking about texlive. I am talking about a
perfectly modular problem that is solvable.

But I am done here it seems.  No point talking to windmills.

Dirk

[1] We have active backports at CRAN for the actual 'r-base' packages, and I
happen to install all of CRAN I use in /usr/local/lib/R/site-library to have
a faster update cadence.  So I *personally* do not care.  But I want my users
to have it in testing if they want it.  Seemingly we can't have that.

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#870089: Buggy boot Debian 9.x

[John Legg]

In addition to the previously submitted issue, some more info...

CPU fan runs 24/7 and never shut off.
If I connect my USB hub and it's three USB tuners, boot fails 8 out of 
ten times.
It goes into some type of race condition, blank screen and CPU fan 
running at full speed.
Or keeps looping through previously submitted issues forever.
Please note NONE of these issued are/were present under Debian 8 Jessie, 
except the fan running 24/7.

Just for the heck of, wiped the hard disk, install openSUSE 42.3 and it 
works flawlessly!
NONE of the above issues.
CPU fan cycles off like it should
Makes no difference what peripherals I connect, it still boots flawlessly.

Well there you go, hope you can resolve this and make Debian usable again

Bug#874052: pbuilder: B20autopkgtest, hook script fails within a Jessie chroot due bashism

[Carsten Schoenert]

Package: pbuilder
Version: 0.228.8
Severity: normal

Dear Maintainer,

I heavily use the hook script B20autopkgtest from the shipped examples scripts
within pbuilder package within my local builds to test potentially uploads of
packages.

And this works perfectly within current chroot environments for unstable
ans also for Stretch. But within a Jessie chroot the hook script is
failing due some bashism inside without a shebang of /bin/bash

> ...
> dpkg-genchanges: not including original source code in upload
> I: copying local configuration
> I: user script /home/pbuilder/build/cow.13852/tmp/hooks/B20autopkgtest 
> starting
> + cd /build/icedove-52.3.0/debian/..
> + [ ! -f debian/tests/control ]
> + [ ! -f debian/files ]
> + [ -n  ]
> + unset newpid_name
> + apt-cache policy newpid
> + grep -q newpid:
> + echo The newpid package seems to be available, considering for installation
> The newpid package seems to be available, considering for installation
> + newpid_name=newpid
> /tmp/hooks/B20autopkgtest: 65: /tmp/hooks/B20autopkgtest: Bad substitution

Using checkbashism is showing exactly this line using Bash syntax.

> carsten@i5:/usr/share/doc/pbuilder/examples  $ checkbashisms B20autopkgtest 
> possible bashism in B20autopkgtest line 65 (bash arrays, ${name[0|*|@]}):
> apt-get install -y "${APTGETOPT[@]}" autopkgtest apt-utils pbuilder 
> $newpid_name

I changed the shebang to using /bin/bash and the script is also working in a
Jessie chroot again.

Regards
Carsten

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

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

Versions of packages pbuilder depends on:
ii  debconf  1.5.63
ii  debootstrap  1.0.91
ii  dpkg-dev 1.18.24
ii  wget 1.19.1-4

Versions of packages pbuilder recommends:
ii  devscripts  2.17.9
pn  eatmydata   
ii  fakeroot1.22-1
ii  iproute24.9.0-1
ii  net-tools   1.60+git20161116.90da8a0-1
ii  sudo1.8.20p2-1

Versions of packages pbuilder suggests:
ii  cowdancer   0.85
pn  gdebi-core  

-- debconf information:
  pbuilder/mirrorsite: http://ftp.de.debian.org/debian/
  pbuilder/rewrite: false
  pbuilder/nomirror: