Bug#830839: ConnectionError: ('Connection aborted.', ResponseNotReady()) when using Session interface

[Roland Hieber]

Package: python-requests
Version: 2.10.0-2
Severity: important

Dear Maintainer,

if I try to re-use my requests.Session objects for more than one GET, I
get the above mentioned ConnectionError. Wireshark shows that my client
is sending a TCP RST segment to the server. I'm not sure whether this is
a bug in requests itself, or the underlying urllib3, or something else
on my system.

Here is my minimal, reproducable example:

$ python
Python 2.7.12 (default, Jun 29 2016, 08:18:26) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> session = requests.Session()
>>> url="http://rohieb.name;
>>> while True:
... print(url)
... r = session.get(url)
... 
http://rohieb.name
http://rohieb.name
Traceback (most recent call last):
File "", line 3, in 
File 
"/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 477, in get
return self.request('GET', url, **kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 465, in 
request
resp = self.send(prep, **send_kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 573, in send
r = adapter.send(request, **kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 415, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', 
ResponseNotReady())
>>> 

This behaviour is not present in a fresh virtualenv, which uses Python
2.7.12, requests 2.10.0, and urllib3 1.15.1 (multiple get() calls work
normally here).  A quick test shows that it also does not happen on
stable, but unfortunately, I don't have another testing/sid system to
reproduce this.

Cheers,

  Roland



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

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

Versions of packages python-requests depends on:
ii  ca-certificates  20160104
ii  python-chardet   2.3.0-2
ii  python-urllib3   1.15.1-2
pn  python:any   

python-requests recommends no packages.

Versions of packages python-requests suggests:
pn  python-ndg-httpsclient  
ii  python-openssl  16.0.0-1
ii  python-pyasn1   0.1.9-1
pn  python-socks

-- debconf-show failed

Bug#830180: PowerPC without altivec causes crash

[Mathieu Malaterre]

Control: tags -1 fixed-upstream

See: 
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/88#issuecomment-231820117

Bug#830811: mathic: Symbols file compatibility with -O3

[Doug Torrance]

Hi Steve,

On 07/11/2016 03:08 PM, Steve Langasek wrote:

The Ubuntu ppc64el port uses -O3 optimization for package builds by default.
Under -O3, there are a number of template symbols that are not exported in
libmathic because they wind up inlined instead.  As a result, mathic fails
to build with a mismatched symbols file error.

The attached patch has been applied in Ubuntu to mark these additional
symbols optional, since they are not part of the ABI, and allows the package
to build wherever -O3 is used.


Thanks for the report and patch!

I've pushed a new version including the patch to git [1] and have 
requested sponsorship.


Doug

[1] 
http://anonscm.debian.org/cgit/debian-science/packages/mathic.git/commit/?id=1401c746239b54e6d773a37ccbe2995c9556cd32

Bug#830837: gitlab: unversioned dependencies

[Dmitry Smirnov]

More dependencies should be versioned:

ruby-omniauth-google-oauth2 (>= 0.4.1~)
ruby-grape (>= 0.16.2~)
ruby-net-ssh (>= 1:3.0.1~)
ruby-method-source (>= 0.8.2-2~)
ruby-bcrypt (>= 3.1.11~)
ruby-rqrcode (>= 0.4.2-3~)
ruby-sasl (>= 0.0.3.3-2~)
ruby-ntlm (>= 0.3.4-2~)


ruby-bcrypt is an indirect dependency so lack of versioning is probably in 
"ruby-devise":


Bundler could not find compatible versions for gem "bcrypt":
  In Gemfile:   


devise (~> 4.0) was resolved to 4.1.1, which depends on 


  bcrypt (~> 3.0)   



Could not find gem 'bcrypt (~> 3.0)', which is required by gem 'devise (~>  


4.0)', in any of the sources.   




"ruby-rqcode" probably should be versioned in "ruby-rqrcode-rails3":


Bundler could not find compatible versions for gem "rqrcode":
  In Gemfile:   


rqrcode-rails3 (~> 0.1.7) was resolved to 0.1.7, which depends on   


  rqrcode (>= 0.4.2)



Could not find gem 'rqrcode (>= 0.4.2)', which is required by gem   


'rqrcode-rails3 (~> 0.1.7)', in any of the sources. 




"ruby-sasl" also is an indirect dependency:


Bundler could not find compatible versions for gem "pyu-ruby-sasl":
  In Gemfile:   


omniauth-ldap (~> 1.0.4) was resolved to 1.0.5, which depends on


  pyu-ruby-sasl (~> 0.0.3.2)



Could not find gem 'pyu-ruby-sasl (~> 0.0.3.2)', which is required by gem   


'omniauth-ldap (~> 1.0.4)', in any of the sources.


And more:


Bundler could not find compatible versions for gem "rubyntlm":
  In Gemfile:   


omniauth-ldap (~> 1.0.4) was resolved to 1.0.5, which depends on


  rubyntlm (~> 0.3.4)   



Could not find gem 'rubyntlm (~> 0.3.4)', which is required by gem  


'omniauth-ldap (~> 1.0.4)', in any of the sources.  




Finally even after satisfying all those dependencies attempt to install 
gitlab_8.9.0+dfsg-3 failed as follows:


Bundler could not find compatible versions for gem "rouge":
  In Gemfile:
rouge (>= 2.0.2, ~> 2.0)

gollum-lib (~> 4.2) was resolved to 4.2.0, which depends on
  rouge (~> 1.10)

Could not find gem 'rouge (~> 1.10)', which is required by gem 'gollum-lib 
(~>
4.2)', in any of the sources.


-- 
Regards,
 Dmitry Smirnov.

---

Honesty is a gift we can give to others. It is also a source of power and
an engine of simplicity. Knowing that we will attempt to tell the truth,
whatever the circumstances, leaves us with little to prepare for. We can
simply be ourselves.
-- Sam Harris



signature.asc
Description: This is a 

Bug#830838: nova-api does not start

[Serhii Yehorov]

Package: nova-api
Version: 2:13.1.0-1~bpo8+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Nova becames unusable after upgrade from backports to Mitaka.
Previous backported version 'Liberty' was working fine.
Seems like something wrong with python modules names. This is a nova-api.log:

2016-07-12 06:25:32.917 4672 WARNING oslo_reports.guru_meditation_report [-] 
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
2016-07-12 06:25:32.941 4672 CRITICAL nova [-] ImportError: No module named 
oslo.middleware
2016-07-12 06:25:32.941 4672 ERROR nova Traceback (most recent call last):
2016-07-12 06:25:32.941 4672 ERROR nova   File "/usr/bin/nova-api", line 10, in 

2016-07-12 06:25:32.941 4672 ERROR nova sys.exit(main())
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/cmd/api.py", line 57, in main
2016-07-12 06:25:32.941 4672 ERROR nova server = service.WSGIService(api, 
use_ssl=should_use_ssl)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/service.py", line 366, in __init__
2016-07-12 06:25:32.941 4672 ERROR nova self.app = 
self.loader.load_app(name)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/wsgi.py", line 497, in load_app
2016-07-12 06:25:32.941 4672 ERROR nova return deploy.loadapp("config:%s" % 
self.config_path, name=name)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
2016-07-12 06:25:32.941 4672 ERROR nova return loadobj(APP, uri, name=name, 
**kw)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
2016-07-12 06:25:32.941 4672 ERROR nova return context.create()
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2016-07-12 06:25:32.941 4672 ERROR nova return self.object_type.invoke(self)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2016-07-12 06:25:32.941 4672 ERROR nova **context.local_conf)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2016-07-12 06:25:32.941 4672 ERROR nova val = callable(*args, **kw)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/urlmap.py", line 160, in 
urlmap_factory
2016-07-12 06:25:32.941 4672 ERROR nova app = loader.get_app(app_name, 
global_conf=global_conf)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
2016-07-12 06:25:32.941 4672 ERROR nova name=name, 
global_conf=global_conf).create()
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2016-07-12 06:25:32.941 4672 ERROR nova return self.object_type.invoke(self)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2016-07-12 06:25:32.941 4672 ERROR nova **context.local_conf)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2016-07-12 06:25:32.941 4672 ERROR nova val = callable(*args, **kw)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/api/auth.py", line 74, in 
pipeline_factory
2016-07-12 06:25:32.941 4672 ERROR nova return _load_pipeline(loader, 
pipeline)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/api/auth.py", line 58, in _load_pipeline
2016-07-12 06:25:32.941 4672 ERROR nova filters = [loader.get_filter(n) for 
n in pipeline[:-1]]
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 354, in 
get_filter
2016-07-12 06:25:32.941 4672 ERROR nova name=name, 
global_conf=global_conf).create()
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 366, in 
filter_context
2016-07-12 06:25:32.941 4672 ERROR nova FILTER, name=name, 
global_conf=global_conf)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 458, in 
get_context
2016-07-12 06:25:32.941 4672 ERROR nova section)
2016-07-12 06:25:32.941 4672 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 517, in 
_context_from_explicit
2016-07-12 06:25:32.941 4672 ERROR nova value = import_string(found_expr)
2016-07-12 06:25:32.941 4672 ERROR nova   File 

Bug#830837: gitlab: fails to install: Could not find gem 'recaptcha'; unversioned dependencies

[Dmitry Smirnov]

Package: gitlab
Version: 8.8.2+dfsg-5
Severity: normal

GitLab fails to install on Jessie as follows:


Create database if not present
Make gitlab user owner of gitlab_production database...
ALTER DATABASE
Grant all privileges to gitlab user...
GRANT
NOTICE:  extension "pg_trgm" already exists, skipping
CREATE EXTENSION
Verifying we have all required libraries...
Could not find gem 'recaptcha' in any of the gem sources listed in your 
Gemfile
or available on this machine.
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 7
Errors were encountered while processing:
 gitlab


Strangely enough "ruby-recaptcha" is already installed but this error 
disappeared when I upgraded "ruby-recaptcha" to 0.4.0.

However another error emerged:


Verifying we have all required libraries...
Could not find gem 'six (~> 0.2.0)' in any of the gem sources listed in your
Gemfile or available on this machine.


Upgrade of "ruby-six" from 0.2.0-2 to 0.2.0-3 allowed to progress to next 
error:


Verifying we have all required libraries...
Could not find gem 'RedCloth (>= 4.2.9, ~> 4.2)' in any of the gem sources
listed in your Gemfile or available on this machine.


So I've upgraded "ruby-redcloth" (4.2.9-5+b3) over (4.2.9-4)

then 


Could not find gem 'rouge (>= 1.10.1, ~> 1.10)' in any of the gem sources 
listed
in your Gemfile or available on this machine.


but "ruby-rouge" 2.0.2-1 from "testing" is already installed so here it 
stuck...


Versioning dependencies as follows should address some of the problems:

ruby-recaptcha (>= 0.4.0~)
ruby-six (>= 0.2.0-3~)
ruby-redcloth (>= 4.2.9-5~)

However it does not solve "ruby-rouge" problem probably related to #830111.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
-- H. L. Mencken



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

Bug#828807: newlisp: FTBFS on powerpc: test suite segmentation fault

[Sergio Durigan Junior]

On Monday, July 11 2016, Aaron M. Ucko wrote:

> Sergio Durigan Junior  writes:
>
>> Right, so I've given this another try and, again, I am unable to
>> reproduce the bug.  I am using pizzetti.debian.org (porter box) to test,
>> and it is the only machine that I have access to.
>
> It looks like you accidentally got the wrong porterbox -- pizzetti is
> running ppc64, on which newlisp hasn't run into any trouble.  I was able
> to reproduce the problem on partch, which is running classic 32-bit
> powerpc; see below for the resulting backtrace.

Hm, you're right.  I'll get in touch with DSA and request access to
partch.  Thanks for the pointer.

>> Therefore, I am out of options for diagnosing this issue.  I see you're
>> a DD, so I'd appreciate some help here, because you probably have access
>> to the buildd machine that showed the failure.  Can you try to generate
>> a corefile there?
>
> FTR, access to actual buildds is limited to a handful of DDs actively
> involved in porting or system administration, and I am not among them.

Ops, didn't know that.

> Meanwhile, I noticed that #828805 is still a problem on the Hurd
> (porterbox exodar.debian.net).

I'll have to ask DSA about this one too.

> 
>
> Starting program: /home/ucko/newlisp/newlisp qa-dot
>
> Testing built-in functions ...
>   -> semaphore 
> Program received signal SIGSEGV, Segmentation fault.
> 0x1fd82e54 in semctl () from /lib/powerpc-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x1fd82e54 in semctl () from /lib/powerpc-linux-gnu/libc.so.6
> #1  0x20075cf8 in semaphore (sem_id=2457602, value=, 
> type=) at nl-filesys.c:2090
> #2  0x20075e10 in p_semaphore (params=) at nl-filesys.c:1996
> #3  0x2004d498 in evaluateExpression (cell=0x201b9b90) at newlisp.c:1580
> #4  0x20052ee8 in setDefine (symbol=0x20139760, params=, 
> type=) at newlisp.c:5166
> #5  0x200530d4 in p_set (params=) at newlisp.c:5104
> #6  0x2004d498 in evaluateExpression (cell=0x201b98c0) at newlisp.c:1580
> #7  0x20053f88 in p_and (params=0x201b98c0) at newlisp.c:6171
> #8  0x2004d498 in evaluateExpression (cell=0x201bcde0) at newlisp.c:1580
> #9  0x2004e348 in evaluateLambda (localLst=0x201bcde0, arg=, 
> newContext=) at newlisp.c:1901
> #10 0x2004d4d4 in evaluateExpression (cell=0x201bc150) at newlisp.c:1588
> #11 0x20052834 in p_apply (params=0x200e92a0) at newlisp.c:4732
> #12 0x2004d498 in evaluateExpression (cell=0x200ec350) at newlisp.c:1580
> #13 0x20051b08 in p_catch (params=0x200ec350) at newlisp.c:4500
> #14 0x2004d498 in evaluateExpression (cell=0x200ec400) at newlisp.c:1580
> #15 0x20053f88 in p_and (params=0x200ec400) at newlisp.c:6171
> #16 0x2004d498 in evaluateExpression (cell=0x200ec330) at newlisp.c:1580
> #17 0x20053e68 in p_evalBlock (params=0x200ec330) at newlisp.c:6123
> #18 0x2004d498 in evaluateExpression (cell=0x200ec4b0) at newlisp.c:1580
> #19 0x20053b18 in p_if (params=0x200ef520) at newlisp.c:5650
> #20 0x2004d498 in evaluateExpression (cell=0x200efc30) at newlisp.c:1580
> #21 0x20054184 in p_not (params=) at newlisp.c:6213
> #22 0x2004d498 in evaluateExpression (cell=0x200efd10) at newlisp.c:1580
> #23 0x20053a34 in p_if (params=0x200efd10) at newlisp.c:5638
> #24 0x2004d498 in evaluateExpression (cell=0x200efe00) at newlisp.c:1580
> #25 0x20055ea8 in evaluateBlock (cell=0x200efe00) at newlisp.c:5627
> #26 dolist (params=0x200efce0, doType=) at newlisp.c:6095
> #27 0x2004d498 in evaluateExpression (cell=0x200ef5c0) at newlisp.c:1580
> #28 0x2004e348 in evaluateLambda (localLst=0x200ef5c0, arg=, 
> newContext=) at newlisp.c:1901
> #29 0x2004d4d4 in evaluateExpression (cell=0x200eb100) at newlisp.c:1588
> #30 0x2004f040 in evaluateStream (stream=0xfffeedcc, outDevice=0, 
> flag=) at newlisp.c:1337
> #31 0x20052280 in loadFile (fileName=, offset=0, 
> linkFlag=, context=) at newlisp.c:3317
> #32 0x20047aa8 in main (argc=2, argv=0xfffef714) at newlisp.c:897

Thanks, that is helpful.  I'll investigate more later and come back as
soon as I find the fix to the problem.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#830104: screenfetch makes my terminal can not be opened again after closing

[susu]

On Wed, 6 Jul 2016 18:32:39 +0200 Hideki Yamane  

I use Gnome-terminal, I can not click the Close button to open the
Gnome-terminal again
> Hi,
> 
> > Package: screenfetch
> > Version: 3.7.0-1
> > Severity: important
> 
>  I'm using GNOME3, too.
> 
> > *** First, I need to explain my desktop environment is Gnome,
> 
> > when I open screenfatch in the terminal,
> > it is working, but when I close the terminal, 
> > I will not be able to restart my terminal work.
> 
>  unreproducible, please also provide below information.
> 
>  - Which terminal program (e.g. gnome-terminal)
>  - You "close" terminal, it means "exit" command or just click close
>button in window.
>  - What you mean "restart terminal work"? Close and open new terminal
>window or something?
>  - Do you run special utility like GNU screen, tmux or byobu?
> 
>  
> -- 
> Hideki Yamane 
> 
> 

Bug#830836: midori misses some command line commands. Must try again once or twice

[積丹尼 Dan Jacobson]

Package: midori
Version: 0.5.12~wk2-exp1
Severity: wishlist

Often with midori already fully running,
I do
$ midori http://SOME.WEB/PAGE
but nothing happens. Sometimes I need to go back to the shell and do the
same command one or two times more before midori suddely gets the
message and starts browsing the page. Otherwise it is just like I did
$ #midori ...
with a shell comment character in front.

It is sort of like "midori is too slow picking up the phone and misses
the interprocess call".

Or it didn't even notice the phone "ringing."

Maybe test on a slow system.

This didn't use to happen until this version.

Bug#827198: wordpress: Update nginx example configuration for php7

[Jeremy Bicha]

I didn't touch the debian/changelog because maintainers have different
opinions on how they want that handled.

Jeremy

Bug#828807: newlisp: FTBFS on powerpc: test suite segmentation fault

[Aaron M. Ucko]

Sergio Durigan Junior  writes:

> Right, so I've given this another try and, again, I am unable to
> reproduce the bug.  I am using pizzetti.debian.org (porter box) to test,
> and it is the only machine that I have access to.

It looks like you accidentally got the wrong porterbox -- pizzetti is
running ppc64, on which newlisp hasn't run into any trouble.  I was able
to reproduce the problem on partch, which is running classic 32-bit
powerpc; see below for the resulting backtrace.

> Therefore, I am out of options for diagnosing this issue.  I see you're
> a DD, so I'd appreciate some help here, because you probably have access
> to the buildd machine that showed the failure.  Can you try to generate
> a corefile there?

FTR, access to actual buildds is limited to a handful of DDs actively
involved in porting or system administration, and I am not among them.

Meanwhile, I noticed that #828805 is still a problem on the Hurd
(porterbox exodar.debian.net).



Starting program: /home/ucko/newlisp/newlisp qa-dot

Testing built-in functions ...
  -> semaphore 
Program received signal SIGSEGV, Segmentation fault.
0x1fd82e54 in semctl () from /lib/powerpc-linux-gnu/libc.so.6
(gdb) bt
#0  0x1fd82e54 in semctl () from /lib/powerpc-linux-gnu/libc.so.6
#1  0x20075cf8 in semaphore (sem_id=2457602, value=, 
type=) at nl-filesys.c:2090
#2  0x20075e10 in p_semaphore (params=) at nl-filesys.c:1996
#3  0x2004d498 in evaluateExpression (cell=0x201b9b90) at newlisp.c:1580
#4  0x20052ee8 in setDefine (symbol=0x20139760, params=, 
type=) at newlisp.c:5166
#5  0x200530d4 in p_set (params=) at newlisp.c:5104
#6  0x2004d498 in evaluateExpression (cell=0x201b98c0) at newlisp.c:1580
#7  0x20053f88 in p_and (params=0x201b98c0) at newlisp.c:6171
#8  0x2004d498 in evaluateExpression (cell=0x201bcde0) at newlisp.c:1580
#9  0x2004e348 in evaluateLambda (localLst=0x201bcde0, arg=, 
newContext=) at newlisp.c:1901
#10 0x2004d4d4 in evaluateExpression (cell=0x201bc150) at newlisp.c:1588
#11 0x20052834 in p_apply (params=0x200e92a0) at newlisp.c:4732
#12 0x2004d498 in evaluateExpression (cell=0x200ec350) at newlisp.c:1580
#13 0x20051b08 in p_catch (params=0x200ec350) at newlisp.c:4500
#14 0x2004d498 in evaluateExpression (cell=0x200ec400) at newlisp.c:1580
#15 0x20053f88 in p_and (params=0x200ec400) at newlisp.c:6171
#16 0x2004d498 in evaluateExpression (cell=0x200ec330) at newlisp.c:1580
#17 0x20053e68 in p_evalBlock (params=0x200ec330) at newlisp.c:6123
#18 0x2004d498 in evaluateExpression (cell=0x200ec4b0) at newlisp.c:1580
#19 0x20053b18 in p_if (params=0x200ef520) at newlisp.c:5650
#20 0x2004d498 in evaluateExpression (cell=0x200efc30) at newlisp.c:1580
#21 0x20054184 in p_not (params=) at newlisp.c:6213
#22 0x2004d498 in evaluateExpression (cell=0x200efd10) at newlisp.c:1580
#23 0x20053a34 in p_if (params=0x200efd10) at newlisp.c:5638
#24 0x2004d498 in evaluateExpression (cell=0x200efe00) at newlisp.c:1580
#25 0x20055ea8 in evaluateBlock (cell=0x200efe00) at newlisp.c:5627
#26 dolist (params=0x200efce0, doType=) at newlisp.c:6095
#27 0x2004d498 in evaluateExpression (cell=0x200ef5c0) at newlisp.c:1580
#28 0x2004e348 in evaluateLambda (localLst=0x200ef5c0, arg=, 
newContext=) at newlisp.c:1901
#29 0x2004d4d4 in evaluateExpression (cell=0x200eb100) at newlisp.c:1588
#30 0x2004f040 in evaluateStream (stream=0xfffeedcc, outDevice=0, 
flag=) at newlisp.c:1337
#31 0x20052280 in loadFile (fileName=, offset=0, 
linkFlag=, context=) at newlisp.c:3317
#32 0x20047aa8 in main (argc=2, argv=0xfffef714) at newlisp.c:897

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

Bug#805411: Claiming RFP

[Martín Ferrari]

retitle 805411 RFP: js-yaml -- Fast JavaScript YAML parser and dumper
noowner 805411
thanks

> I am packaging this, as I need it for another project. I will provide
> both the node version, and a browserified version.

So, this turned out to be more complicated. To have a properly working
browser version, it depends (transitively) on other 3 unpackaged JS
libraries. At the same time, the project I am working on accepted my
suggestion to drop this dependency. So I am withdrawing my ITP.

If anybody wants to continue, I have left and almost finished package at
https://anonscm.debian.org/git/collab-maint/js-yaml.js.git

-- 
Martín Ferrari (Tincho)

Bug#823971: +1

[Jan Braun]

control: retitle 823971 mutt: displays text/html raw instead of using mailcap

Eduard Bloch schrob:
> same here, the ability to read inline HTML parts without ugly
> workarounds is really missed.

There are two easy workarounds. The first is using "m".
Quoting TFM, Table 9.7. Default Attachment Menu Bindings:
  mforce viewing of attachment using mailcap
 Tview attachment as text
view attachment using mailcap entry if necessary
The second is setting "auto_view text/html" in your .muttrc , which
causes a rendered version of the html to be displayed instead of the raw
source.
HTH.

However, I still prefer the previous behaviour of, by default, spawning an
interactive browser for text/html. Thus I recompiled mutt 1.6.0-1 with
611410-no-implicit_autoview-for-text-html.patch , and can confirm it
builds cleanly and fixes this issue.

The patch was dropped due to dbug #816706, where Kevin McCarthy claims
 Fixed in https://dev.mutt.org/trac/ticket/3496 3 years ago.

Unfortunately, that ticket seems to have considered only
(implicit)autoview functionality, i.e. the question whether mutt
displays the raw html or the text result of a mime rule like
 text/html; /usr/bin/elinks -force-html -dump %s; copiousoutput; ...
The debian patch goes beyond that in providing the (default) behaviour
of actually opening the html in a browser via a rule like
 text/html; /usr/bin/elinks -force-html %s; needsterminal; ...

Please consider reinstating the patch.
Thanks,
Jan


signature.asc
Description: PGP signature

Bug#828140: WARNING **: /usr/lib/midori/libformhistory.so: cannot open shared object file: No such file or directory

[積丹尼 Dan Jacobson]

No. Now I see

(midori4:12377): Gtk-WARNING **: Theme parsing error: gtk3.css:2:31: The style 
property GtkButton:default-border is deprecated and shouldn't be used anymore. 
It will be removed in a future version

(midori4:12377): Gtk-WARNING **: Theme parsing error: gtk3.css:3:39: The style 
property GtkButton:default-outside-border is deprecated and shouldn't be used 
anymore. It will be removed in a future version

(midori4:12377): Gtk-WARNING **: Theme parsing error: gtk3.css:4:29: The style 
property GtkButton:inner-border is deprecated and shouldn't be used anymore. It 
will be removed in a future version

(midori4:12377): Gtk-WARNING **: Theme parsing error: gtk3.css:5:33: The style 
property GtkWidget:focus-line-width is deprecated and shouldn't be used 
anymore. It will be removed in a future version

(midori4:12377): Gtk-WARNING **: Theme parsing error: gtk3.css:6:30: The style 
property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. 
It will be removed in a future version

(midori4:12377): Gtk-WARNING **: Theme parsing error: gtk3.css:26:20: The 
:insensitive pseudo-class is deprecated. Use :disabled instead.

SDJ> Do you still see this bug with the new version in experimental?

Bug#827198: wordpress: Update nginx example configuration for php7

[Jeremy Bicha]

Control: tags -1 + pending

On Mon, Jul 11, 2016 at 10:24 PM, Craig Small  wrote:
>   Sure thing  just let me know when you do it.

Thanks. Done.

Jeremy

Bug#830835: bugwarrior: Missing man pages

[Roland Hieber]

Package: bugwarrior
Version: 1.4.0+git2016070901-1
Severity: normal
Tags: upstream

Dear Maintainer,

I could not find man pages for either `bugwarrior-pull`, `bugwarrior-uda`, or
`bugwarrior-vault`.  Also, I don't think upstream provides any.  It would be
nice to have any, so I'm filing this bug as per Debian Policy, Section 12.1 [0].
(But also see footnote 110 [1]!)

[0]: https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
[1]: https://www.debian.org/doc/debian-policy/footnotes.html#f110

Cheers,

  Roland

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

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

Versions of packages bugwarrior depends on:
ii  libjs-sphinxdoc   1.4.4-3
ii  python-bugzilla   1.2.2-1
ii  python-click  6.6-1
ii  python-dateutil   2.4.2-1
ii  python-dogpile.cache  0.5.7-2
ii  python-jinja2 2.8-1
ii  python-keyring9.1-1
ii  python-lockfile   1:0.12.2-1
ii  python-offtrac0.1.0-1
ii  python-requests   2.10.0-2
ii  python-six1.10.0-3
ii  python-taskw  1.1.0-2
ii  python-tz 2015.7+dfsg-0.1
ii  python-xdg0.25-4
pn  python:any

bugwarrior recommends no packages.

bugwarrior suggests no packages.

-- no debconf information

Bug#830834: Now that Debian tidy has been updated for html5, so should tidy-doc

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: t...@packages.debian.org
Package: tidy-doc
Version: 20121113git-1
Severity: wishlist

Now that Debian tidy has been updated for html5, so should tidy-doc.
And the former should Recommend the latter.

Bug#827198: wordpress: Update nginx example configuration for php7

[Craig Small]

Sorry Jeremy,
  Sure thing  just let me know when you do it.

- Craig

On Tue, 12 Jul 2016 12:21 Jeremy Bicha  wrote:

> Hi, it's been a month with no response.
>
> How about I just push this minor patch to collab-maint git?
>
> Thanks,
> Jeremy
>
-- 
Craig Small (@smallsees)   http://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#810290: Your mail

[Kunal Mehta]

Hi!

On 07/08/2016 04:03 PM, Nye Liu wrote:
> 1) Will upgrading from the legacy mediawiki 1.19.20 deb work seamlessly?

I tested the upgrade path from the old 1.19 package to my new (not yet
uploaded) 1.27 package on jessie, and for the most part, yes, it should
just work. The package has a new mediawiki.conf for Apache, so you might
need to resolve conflicts between what is enabled and what the package
now has.

Apart from that, you will need to manually perform the normal MediaWiki
upgrade steps[1] like running update.php and adjusting configuration.
Notably as of 1.24, skins must be registered in LocalSettings.php[2],
but that's pretty trivial I think.

Note that this was without any extensions enabled.

> 2) What about legacy mediawiki-extensions-*?
> 
> Currently, the mediawiki unstable/experimental deb conflicts with the
> legacy mediawiki-extensions-base

The extensions that are bundled with the MediaWiki tarball are now
included in the "mediawiki" package itself. This is a different set from
the ones in the mediawiki-extensions-base package though, I'm not sure
how that list was picked...

I'm still working on a plan to modernize the individual
mediawiki-extensions-* packages. MediaWiki has moved to a new system of
extension loading, and the old method of autoloading PHP files is
deprecated upstream, so we shouldn't continue to rely upon it.

[1] https://www.mediawiki.org/wiki/Manual:Upgrading
[2]
https://www.mediawiki.org/wiki/MediaWiki_1.24#Skins_no_longer_loaded_after_upgrade.3F

Bug#827198: wordpress: Update nginx example configuration for php7

[Jeremy Bicha]

Hi, it's been a month with no response.

How about I just push this minor patch to collab-maint git?

Thanks,
Jeremy

Bug#817437: dpkg-sig: Removal of debhelper compat 4

[Logan Rosen]

Package: dpkg-sig
Version: 0.13.1+nmu2
Followup-For: Bug #817437
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

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

  * debian/compat: Bump to 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru dpkg-sig-0.13.1+nmu2/debian/compat dpkg-sig-0.13.1+nmu2ubuntu1/debian/compat
--- dpkg-sig-0.13.1+nmu2/debian/compat	2014-06-10 11:37:24.0 -0400
+++ dpkg-sig-0.13.1+nmu2ubuntu1/debian/compat	2016-07-11 22:02:07.0 -0400
@@ -1 +1 @@
-4
+9
diff -Nru dpkg-sig-0.13.1+nmu2/debian/control dpkg-sig-0.13.1+nmu2ubuntu1/debian/control
--- dpkg-sig-0.13.1+nmu2/debian/control	2014-06-10 11:37:52.0 -0400
+++ dpkg-sig-0.13.1+nmu2ubuntu1/debian/control	2016-07-11 22:11:53.0 -0400
@@ -3,12 +3,12 @@
 Priority: optional
 Uploaders: Andreas Barth 
 Maintainer: Marc 'HE' Brockschmidt 
-Build-Depends: debhelper (>= 4), perl
+Build-Depends: debhelper (>= 9), perl
 Standards-Version: 3.6.2
 
 Package: dpkg-sig
 Architecture: all
-Depends: perl, gnupg, libdigest-md5-perl, libconfig-file-perl
+Depends: ${misc:Depends}, perl, gnupg, libdigest-md5-perl, libconfig-file-perl
 Suggests: ssh, libterm-readkey-perl
 Description: create and verify signatures on .deb-files
  dpkg-sig is a low-level tool for creation and verification of

Bug#830833: bugwarrior: IOError when starting bugwarrior-uda without a config file

[Roland Hieber]

Package: bugwarrior
Version: 1.4.0+git2016070901-1
Severity: minor
Tags: newcomer

Dear Maintainer,

the documentation says:

> For using this data in reports, it is recommended that you add these UDA
> definitions to your ~/.taskrc file. You can generate your list of UDA
> definitions by running the following command:
> 
> bugwarrior-uda

I was curious, so I ran `bugwarrior-uda`. But I did not create a config file
first, which seems to bother it:

$ bugwarrior-uda
Traceback (most recent call last):
File "/usr/bin/bugwarrior-uda", line 9, in 
load_entry_point('bugwarrior==1.4.0', 
'console_scripts', 'bugwarrior-uda')()
File "/usr/lib/python2.7/dist-packages/click/core.py", line 
716, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/click/core.py", line 
696, in main
rv = self.invoke(ctx)
File "/usr/lib/python2.7/dist-packages/click/core.py", line 
889, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python2.7/dist-packages/click/core.py", line 
534, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/bugwarrior/command.py", 
line 138, in uda
conf = load_config(main_section)
File "/usr/lib/python2.7/dist-packages/bugwarrior/config.py", 
line 169, in load_config
"utf-8",
File "/usr/lib/python2.7/codecs.py", line 896, in open
file = __builtin__.open(filename, mode, buffering)
IOError: [Errno 2] No such file or directory: 
'/home/rohieb/.config/bugwarrior/bugwarriorrc'

A clearer message about a missing config file would be more appropriate here.

This feature is probably suited to get familiar with the code base, which is the
reason why I tagged this bug report with "newcomer".

Cheers,

 - Roland

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

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

Versions of packages bugwarrior depends on:
ii  libjs-sphinxdoc   1.4.4-3
ii  python-bugzilla   1.2.2-1
ii  python-click  6.6-1
ii  python-dateutil   2.4.2-1
ii  python-dogpile.cache  0.5.7-2
ii  python-jinja2 2.8-1
ii  python-keyring9.1-1
ii  python-lockfile   1:0.12.2-1
ii  python-offtrac0.1.0-1
ii  python-requests   2.10.0-2
ii  python-six1.10.0-3
ii  python-taskw  1.1.0-2
ii  python-tz 2015.7+dfsg-0.1
ii  python-xdg0.25-4
pn  python:any

bugwarrior recommends no packages.

bugwarrior suggests no packages.

-- no debconf information

Bug#817432: distmp3: Removal of debhelper compat 4

[Logan Rosen]

Package: distmp3
Version: 0.1.9.ds1-4.6
Followup-For: Bug #817432
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

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

  * debian/compat: Bump to 9.
  * debian/control: Build-depend on debhelper (>= 9).
  * debian/rules:
- Use dh_prep instead of dh_clean -k.
- Add recommended build-arch and build-indep targets.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u distmp3-0.1.9.ds1/debian/compat distmp3-0.1.9.ds1/debian/compat
--- distmp3-0.1.9.ds1/debian/compat
+++ distmp3-0.1.9.ds1/debian/compat
@@ -1 +1 @@
-4
+9
diff -u distmp3-0.1.9.ds1/debian/control distmp3-0.1.9.ds1/debian/control
--- distmp3-0.1.9.ds1/debian/control
+++ distmp3-0.1.9.ds1/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Jesus Climent 
 Build-Depends-Indep: po-debconf
-Build-Depends: debhelper (>> 4.0.0), dpatch
+Build-Depends: debhelper (>= 9), dpatch
 Standards-Version: 3.6.1.0
 
 Package: distmp3
diff -u distmp3-0.1.9.ds1/debian/rules distmp3-0.1.9.ds1/debian/rules
--- distmp3-0.1.9.ds1/debian/rules
+++ distmp3-0.1.9.ds1/debian/rules
@@ -5,7 +5,9 @@
 
 include /usr/share/dpatch/dpatch.make
 
-build: patch
+build: build-arch build-indep
+build-arch: patch
+build-indep: patch
 
 clean: unpatch
 	dh_testdir
@@ -15,7 +17,7 @@
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	
 	dh_installdirs /usr/bin /etc
 	

Bug#822612:

[Jaxen Jackson]

What

Bug#829743: plinth: Needs breaks/replaces on freedombox-setup

[James Valleroy]

The attached patch implements this change. I checked that with this
change, plinth could be upgraded while freedombox-setup 0.9.1 is installed.

--
James
From 158f5fe11d8bc3d27f4c3393bb12d3cf34a37e9f Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Mon, 11 Jul 2016 20:37:22 -0400
Subject: [PATCH] Add breaks/replaces on freedombox-setup << 0.9.2~

---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 021afb6..02ac481 100644
--- a/debian/control
+++ b/debian/control
@@ -37,6 +37,8 @@ Vcs-Git: https://anonscm.debian.org/git/freedombox/plinth.git
 Vcs-Browser: https://anonscm.debian.org/gitweb/?p=freedombox/plinth.git;a=summary
 
 Package: plinth
+Breaks: freedombox-setup (<< 0.9.2~)
+Replaces: freedombox-setup (<< 0.9.2~)
 Architecture: all
 Depends: ${python3:Depends}
  , ${misc:Depends}
-- 
2.8.1



signature.asc
Description: OpenPGP digital signature

Bug#828807: newlisp: FTBFS on powerpc: test suite segmentation fault

[Sergio Durigan Junior]

Control: tags -1 + moreinfo

On Monday, July 04 2016, Aaron M. Ucko wrote:

> Sergio Durigan Junior  writes:
>
>> I can't reproduce this.  I believe it may have something to do with the
>> machine it was built.  I'll upload a fix for the other bugs soon, and
>> see how the ppc build performs.  Depending on the results I'll close
>> this bug.
>
> OK, thanks.  Alas, it looks like this failure's still occurring.  (The
> other builds look good, though a couple of non-release architectures ran
> into a dpkg-dev bug.)

Right, so I've given this another try and, again, I am unable to
reproduce the bug.  I am using pizzetti.debian.org (porter box) to test,
and it is the only machine that I have access to.

I noticed that the sid chroot available there does not have the version
of GCC being used by the buildd machine, so I decided to try to build
the package on experimental (with GCC 6)...  and it works as well!

Therefore, I am out of options for diagnosing this issue.  I see you're
a DD, so I'd appreciate some help here, because you probably have access
to the buildd machine that showed the failure.  Can you try to generate
a corefile there?

Last, but not least, it seems that this is not an issue with newLISP,
but rather an issue with some other program involved in the building
process.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#830486: gr-air-modes: FTBFS: No rule to make target 'swig/air_modes_swig.py'

[A. Maitland Bottoms]

I am preparing a gr-air-modes 0.0.2.c29eb60-1 which has uptream
swig fixes that I expect will address this.
(current gr-air-modes git HEAD)

Thanks for your interest in this package. Yes, it has caused
me to learn more about swig, and this bug showed up trying
to merge multiple github features along with my swig refactoring.
So while that fix was upstream for a month, I got distracted
by the recent gnuradio release of version 3.7.10 and my updating
of all my gnuradio related packages following that.

-Maitland

Bug#817318: compartment: Mandatory debian/compat for debhelper

[Logan Rosen]

Package: compartment
Version: 1.1.0-4
Followup-For: Bug #817318
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

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

  * debian/rules:
- Remove legacy DH_COMPAT export.
- Use dh_prep instead of dh_clean -k.
- Add recommended build-arch and build-indep targets.
- Don't allow clean to ignore errors.
  * debian/compat: Indicate compatibility level of 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u compartment-1.1.0/debian/rules compartment-1.1.0/debian/rules
--- compartment-1.1.0/debian/rules
+++ compartment-1.1.0/debian/rules
@@ -5,10 +5,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-# This is the debhelper compatability version to use.
-export DH_COMPAT=4
-
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 
@@ -24,14 +23,14 @@
 	rm -f build-stamp
 
 	# Add here commands to clean up after the build process.
-	-$(MAKE) clean
+	$(MAKE) clean
 
 	dh_clean
 
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	# Add here commands to install the package into debian/compartment
diff -u compartment-1.1.0/debian/control compartment-1.1.0/debian/control
--- compartment-1.1.0/debian/control
+++ compartment-1.1.0/debian/control
@@ -2,12 +2,12 @@
 Section: admin
 Priority: optional
 Maintainer: Javier Fernandez-Sanguino Pen~a 
-Build-Depends: debhelper
+Build-Depends: debhelper (>= 9)
 Standards-Version: 3.6.2
 
 Package: compartment
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: Confine services in a limited environment
  Compartment was designed to allow safe execution of privileged
  and/or untrusted executables and services. It has got all possible
only in patch2:
unchanged:
--- compartment-1.1.0.orig/debian/compat
+++ compartment-1.1.0/debian/compat
@@ -0,0 +1 @@
+9

Bug#817392: clex: Removal of debhelper compat 4

[Logan Rosen]

Package: clex
Version: 3.15-1
Followup-For: Bug #817392
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

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

  * debian/compat: Bump to 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u clex-3.15/debian/compat clex-3.15/debian/compat
--- clex-3.15/debian/compat
+++ clex-3.15/debian/compat
@@ -1 +1 @@
-4
+9
diff -u clex-3.15/debian/control clex-3.15/debian/control
--- clex-3.15/debian/control
+++ clex-3.15/debian/control
@@ -3,12 +3,12 @@
 Priority: optional
 Maintainer: Gabriel Puliatti 
 Uploaders: Rudy Godoy 
-Build-Depends: debhelper (>= 4.9.5), autotools-dev, cdbs, libncurses5-dev 
+Build-Depends: debhelper (>= 9), autotools-dev, cdbs, libncurses5-dev 
 Standards-Version: 3.7.2
 
 Package: clex
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: command line file manager which uses the ncurses library 
  Clex is a fully functional textual file-manager. It displays things 
  like permissions, date of creation, filesize and others when browsing a

Bug#830832: hashcat: FTBFS with dpkg-buildpackage -B

[Steve Langasek]

Package: hashcat
Version: 3.00-1
Severity: serious
Tags: patch
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Hi Daniel,

Your latest hashcat upload is failing to build on all autobuilders, because
your dh_fixperms override tries to chmod files that are only present when
building the arch-independent binary packages:

 debian/rules override_dh_fixperms
  make[1]: Entering directory '/«PKGBUILDDIR»'
  dh_fixperms
  chmod 644 debian/hashcat-data/usr/share/doc/hashcat-data/examples/example0.sh
  chmod: cannot access 
'debian/hashcat-data/usr/share/doc/hashcat-data/examples/example0.sh': No such 
file or directory
  debian/rules:16: recipe for target 'override_dh_fixperms' failed
  make[1]: *** [override_dh_fixperms] Error 1
  make[1]: Leaving directory '/«PKGBUILDDIR»'
  debian/rules:7: recipe for target 'binary-arch' failed

(https://buildd.debian.org/status/fetch.php?pkg=hashcat=amd64=3.00-1=1468257422)

Please see the attached patch, which corrects this error.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru hashcat-3.00/debian/rules hashcat-3.00/debian/rules
--- hashcat-3.00/debian/rules	2016-07-08 09:38:40.0 -0700
+++ hashcat-3.00/debian/rules	2016-07-11 18:07:00.0 -0700
@@ -12,7 +12,7 @@
 override_dh_installchangelogs:
 	dh_installchangelogs docs/changes.txt
 
-override_dh_fixperms:
+override_dh_fixperms-indep:
 	dh_fixperms
 	chmod 644 debian/hashcat-data/usr/share/doc/hashcat-data/examples/example0.sh
 	chmod 644 debian/hashcat-data/usr/share/doc/hashcat-data/examples/example400.sh

Bug#830815: New tests with libsdl2-2.0-0 (2.0.4+dfsg2-1) from stretch

[Sascha Reißner]

I have now installed libsdl2 from stretch on jessie and now the
functions for window risizing works all and the window flags show the
right values.
Only the functions SDL_GetWindowMaximumSize and SDL_GetWindowMinimumSize
store 0 at w and h.

-- 
Sascha Reißner 


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

Bug#822670: [debhelper-devel] Bug#822670: dh-systemd should be merged into debhelper

[Michael Biebl]

Am 12.07.2016 um 01:46 schrieb Tianon Gravi:
> On 11 July 2016 at 15:37, Raphael Hertzog  wrote:
>> A lintian check helps people to not introduce the mistake in new packages
>> as well whereas a bug report only helps already existing packages (but
>> will greatly help the conversion while lintian will not have that much
>> of an impact).
> 
> Speaking of lintian, what's the recommended way to make changes
> accommodating this transition, especially for packages for which a
> backport might be anticipated?  If "dh-systemd" is dropped from
> Build-Depends (simply "debhelper (>= 9.20160709~)"), lintian complains
> about "--with systemd" but "dh-systemd" missing,

What is the exact lintian warning you are talking about here,
https://lintian.debian.org/tags/maintainer-script-calls-systemctl.html ?

I think we just need to fix the output and also the wiki page along with
it to recommend a versioned b-dep on debhelper instead of dh-systemd.

As for backports to jessie: If that is of concern to you, just keep
using dh-systemd for now. It's not like we are dropping the dh-systemd
package anytime soon. I wouldn't use alternative b-deps fwiw.

Backporting this version of debhelper to jessie won't be trivial as this
also means a backport of init-system-helpers. The latter is not easily done.

This new lintian warning would only be informational and only show up in
pedantic mode. I would suggest bumping the prio only in buster.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#830831: Ships empty /usr/lib/liblognorm directory

[Michael Biebl]

Package: liblognorm2
Version: 1.1.2-1.1+b2
Severity: minor


The liblognorm2 package ships an empty /usr/lib/liblognorm directory.
This is due to debian/liblognorm2.dirs. You can safely drop this file,
it's not needed.

Regards,
Michael

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

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

Versions of packages liblognorm2 depends on:
ii  libc6   2.23-1
ii  libestr00.1.10-2
ii  libjson-c3  0.12-3

liblognorm2 recommends no packages.

liblognorm2 suggests no packages.

-- no debconf information

Bug#753510: fixed in liblognorm 1.0.1-3

[Michael Biebl]

Control: found -1 1.0.1-3

On Wed, 20 Aug 2014 13:19:46 + Pierre Chifflier 
wrote:
nistrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Format: 1.8
> Date: Wed, 20 Aug 2014 14:58:53 +0200
> Source: liblognorm
> Binary: liblognorm-dev liblognorm1
> Architecture: source amd64
> Version: 1.0.1-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Pierre Chifflier 
> Changed-By: Pierre Chifflier 
> Description:
>  liblognorm-dev - Log normalizing library
>  liblognorm1 - Log normalizing library 
> Closes: 753510
> Changes:
>  liblognorm (1.0.1-3) unstable; urgency=medium
>  .
>* Move lognormalizer exe to arch-specific directory, drop conflict against
>  liblognorm0, and make package Multi-arch:Same (Closes: #753510)


This does not really address the issue pointed out by Bastian, so I'm
reopening this bug report.

Installing the binary as
/usr/lib/$(DEB_HOST_MULTIARCH)/liblognorm/lognormalizer
still means you get the file conflict on each soname bump.

I would suggest moving the binary into a separate binary package, say
liblognorm-utils, as it is the cleanest solution after all.
The next soname bump (which will happen for the upcoming 1.1.4) is a
good opportunity to split the binary out into a new binary package as it
will have to pass NEW anyway in that case.

Regards,
Michael



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



signature.asc
Description: OpenPGP digital signature

Bug#759492: File conflicts between /bin and /usr/bin

[Felipe Sateler]

On Mon, 07 Mar 2016 15:56:31 +0100 Ansgar Burchardt  wrote:

> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).
>
> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.

I agree on both counts.

>
>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
>
>   In case a file gets moved between {path} andÂ
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

Seconded.

Saludos

Bug#829649: lintian: Spurious error: init.d-script-missing-dependency-on-remote_fs

[Felipe Sateler]

On Mon, 04 Jul 2016 22:27:20 -0400 "Roberto C. Sanchez"
 wrote:
> Package: lintian
> Version: 2.5.45
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> In preparing a new upstream release of the shorewall-init package, I
> found that lintian gave the following errors:
>
> E: shorewall-init: init.d-script-missing-dependency-on-remote_fs 
> etc/init.d/shorewall-init: required-start
> E: shorewall-init: init.d-script-missing-dependency-on-remote_fs 
> etc/init.d/shorewall-init: required-stop
>
> I checked with upstream was informed that shorewall-init doesn't work
> with NFS mount /usr and so assumes /usr is accessible without the need
> for $remote_fs in Required-Start and Required-Stop.  I inquired in
> #debian-devel on OFTC about this to see if it was OK to override.  I was
> told that this error is spurious as initramfs now mounts /usr and was
> suggested to file a bug report against lintian.
>

Moreover, booting without /usr mounted is now officially[1]
unsupported, so there is no point in playing /-/usr whack-a-mole.


[1] #830829

Saludos

Bug#830829: release-notes: Document that late-mounting /usr is not supported

[Felipe Sateler]

Package: release-notes
Severity: normal

It has been a long time since late-mounting /usr (ie, using only tools
in /) has been actually supported. In stretch, all initramfs generators
mount /usr if it is a separate mount, so that init receives both / and
/usr mounted.

Problems can occur if /usr is not pre-mounted due to:

1. Programs used during early boot require libraries or other files in
   /usr. (Example, #829127)
2. Udev rules might be invoked very early in the boot process, causing
   programs from /usr to be executed. (Example udev rules,
   90-alsa-restore.rules, 63-md-raid-arrays.rules, 39-usbmuxd.rules).

What does this mean for users? It means that if (1) you have /usr on its
own partition, and (2) you do not use an initramfs; then you should
start using one. All of the debian-provided initramfs generators will
generate a suitable one.

The release notes should document this requirement.

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

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

Bug#830486: gr-air-modes: FTBFS: No rule to make target 'swig/air_modes_swig.py'

[Steve Langasek]

I have seen this bug as well in Ubuntu.  I am at a loss to understand the
bug, however - particularly, why it should trigger on some architectures and
not others.

Astonishingly, when trying to debug this, I found that locally the bug was
unreproducible whenever I ran my build under /tmp.  When I moved the build
to /build, the bug was reproducible.

This looked like it might be a regression in cmake 3.5.2-2.  All of the
failed builds on https://buildd.debian.org/status/package.php?p=gr-air-modes
happened with 3.5.2-2.  Most of the successful builds happened with 3.5.2-1. 
However, armel and i386 succeeded even though they were using 3.5.2-2.  So
that's very confusing.

And if I downgrade cmake here, I still get a build failure.

So, perhaps a regression in some other build-dependency; but it's not
obvious to me which one.  (There has not been an update of swig.)

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


signature.asc
Description: PGP signature

Bug#822670: [debhelper-devel] Bug#822670: dh-systemd should be merged into debhelper

[Tianon Gravi]

On 11 July 2016 at 15:37, Raphael Hertzog  wrote:
> A lintian check helps people to not introduce the mistake in new packages
> as well whereas a bug report only helps already existing packages (but
> will greatly help the conversion while lintian will not have that much
> of an impact).

Speaking of lintian, what's the recommended way to make changes
accommodating this transition, especially for packages for which a
backport might be anticipated?  If "dh-systemd" is dropped from
Build-Depends (simply "debhelper (>= 9.20160709~)"), lintian complains
about "--with systemd" but "dh-systemd" missing, but if one tries to
do something more clever like "debhelper (>= 9.20160709~) |
dh-systemd", then we get ftp-master-rejects due to missing depends on
debhelper, and it feels hacky to go as far as "debhelper (>=
9.20160709~) | dh-systemd, debhelper (>= 9~)" (just to appease
lintian).

Apologies if resolving this is already part of what you were referring
to with "a lintian check". O:)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#830828: wfmath: Symbols file compatibility with -O3

[Steve Langasek]

Package: wfmath
Version: 1.0.2+dfsg1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Hi Olek,

The Ubuntu ppc64el port uses -O3 optimization for package builds by default. 
Under -O3, there are a number of additional template symbols that are not
exported in libwfmath because they wind up inlined instead.  As a result,
wfmath fails to build with a mismatched symbols file error.

The attached patch has been applied in Ubuntu to mark these additional
symbols optional, since they are not part of the ABI, and allows the package
to build wherever -O3 is used.

Thanks for considering the patch.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru wfmath-1.0.2+dfsg1/debian/libwfmath-1.0-1v5.symbols wfmath-1.0.2+dfsg1/debian/libwfmath-1.0-1v5.symbols
--- wfmath-1.0.2+dfsg1/debian/libwfmath-1.0-1v5.symbols	2016-07-11 02:32:53.0 -0700
+++ wfmath-1.0.2+dfsg1/debian/libwfmath-1.0-1v5.symbols	2016-07-11 15:47:58.0 -0700
@@ -605,11 +605,11 @@
  _ZN6WFMath9TimeStamp3nowEv@Base 0.3.11
  _ZN6WFMath9TimeStampC1Ellb@Base 0.3.11
  _ZN6WFMath9TimeStampC2Ellb@Base 0.3.11
- _ZN6WFMath9_miniball5BasisILi2EE4pushERKNS0_13Wrapped_arrayILi2EEE@Base 0.3.11
- _ZN6WFMath9_miniball5BasisILi3EE4pushERKNS0_13Wrapped_arrayILi3EEE@Base 1.0.0
- _ZN6WFMath9_miniball8MiniballILi2EE13move_to_frontESt14_List_iteratorINS0_13Wrapped_arrayILi2@Base 0.3.11
+ (optional=inline)_ZN6WFMath9_miniball5BasisILi2EE4pushERKNS0_13Wrapped_arrayILi2EEE@Base 0.3.11
+ (optional=inline)_ZN6WFMath9_miniball5BasisILi3EE4pushERKNS0_13Wrapped_arrayILi3EEE@Base 1.0.0
+ (optional=inline)_ZN6WFMath9_miniball8MiniballILi2EE13move_to_frontESt14_List_iteratorINS0_13Wrapped_arrayILi2@Base 0.3.11
  _ZN6WFMath9_miniball8MiniballILi2EE6mtf_mbESt14_List_iteratorINS0_13Wrapped_arrayILi2@Base 0.3.11
- _ZN6WFMath9_miniball8MiniballILi3EE13move_to_frontESt14_List_iteratorINS0_13Wrapped_arrayILi3@Base 1.0.0
+ (optional=inline)_ZN6WFMath9_miniball8MiniballILi3EE13move_to_frontESt14_List_iteratorINS0_13Wrapped_arrayILi3@Base 1.0.0
  _ZN6WFMath9_miniball8MiniballILi3EE6mtf_mbESt14_List_iteratorINS0_13Wrapped_arrayILi3@Base 1.0.0
  _ZN6WFMathdVILi2EEERNS_6VectorIXT_EEES3_f@Base 0.3.11
  _ZN6WFMathdVILi3EEERNS_6VectorIXT_EEES3_f@Base 0.3.11
@@ -1014,18 +1014,18 @@
  (regex)_ZNSt6vectorIN6WFMath5PointILi2EEESaIS2_EE17_M_default_appendE[jm]@Base 1.0.2
  _ZNSt6vectorIN6WFMath5PointILi2EEESaIS2_EE19_M_emplace_back_auxIIRKS2_EEEvDpOT_@Base 1.0.2
  _ZNSt6vectorIN6WFMath5PointILi2EEESaIS2_EE19_M_emplace_back_auxIJRKS2_EEEvDpOT_@Base 1.0.2
- _ZNSt6vectorIN6WFMath5PointILi2EEESaIS2_EEaSERKS4_@Base 0.3.11
+ (optional=inline)_ZNSt6vectorIN6WFMath5PointILi2EEESaIS2_EEaSERKS4_@Base 0.3.11
  _ZNSt6vectorIN6WFMath5PointILi3EEESaIS2_EE13_M_insert_auxIIRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base 1.0.0
  _ZNSt6vectorIN6WFMath5PointILi3EEESaIS2_EE13_M_insert_auxIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base 1.0.0
- _ZNSt6vectorIN6WFMath5PointILi3EEESaIS2_EEaSERKS4_@Base 1.0.0
+ (optional=inline)_ZNSt6vectorIN6WFMath5PointILi3EEESaIS2_EEaSERKS4_@Base 1.0.0
  (regex|optional=inline)_ZNSt6vectorIfSaIfEED[12]Ev@Base 0.3.12
  _ZNSt6vectorIfSaIfEE13_M_insert_auxIIRKfEEEvN9__gnu_cxx17__normal_iteratorIPfS1_EEDpOT_@Base 1.0.2
  _ZNSt6vectorIfSaIfEE13_M_insert_auxIJRKfEEEvN9__gnu_cxx17__normal_iteratorIPfS1_EEDpOT_@Base 1.0.2
  _ZNSt6vectorIfSaIfEE19_M_emplace_back_auxIIRKfEEEvDpOT_@Base 1.0.2
  _ZNSt6vectorIfSaIfEE19_M_emplace_back_auxIJRKfEEEvDpOT_@Base 1.0.2
- _ZNSt6vectorIfSaIfEE6insertEN9__gnu_cxx17__normal_iteratorIPKfS1_EERS4_@Base 1.0.2
+ (optional=inline)_ZNSt6vectorIfSaIfEE6insertEN9__gnu_cxx17__normal_iteratorIPKfS1_EERS4_@Base 1.0.2
  (regex)_ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPfSt6vectorIfSaIf[il]fNS0_5__ops15_Iter_less_iterEEvT_T0_SA_T1_T2_@Base 1.0.2
- _ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPfSt6vectorIfSaIfNS0_5__ops15_Iter_less_iterEEvT_S9_T0_@Base 1.0.2
+ (optional=inline)_ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPfSt6vectorIfSaIfNS0_5__ops15_Iter_less_iterEEvT_S9_T0_@Base 1.0.2
  _ZTIN6WFMath10ParseErrorE@Base 0.3.11
  _ZTIN6WFMath15ColinearVectorsILi2EEE@Base 0.3.11
  _ZTIN6WFMath15ColinearVectorsILi3EEE@Base 0.3.11
@@ -1042,5 +1042,5 @@
  _ZZN6WFMath5PointILi3EE4ZEROEvE9zeroPoint@Base 0.3.11
  _ZZN6WFMath6VectorILi2EE4ZEROEvE10zeroVector@Base 0.3.11
  _ZZN6WFMath6VectorILi3EE4ZEROEvE10zeroVector@Base 0.3.11
- _ZZN6WFMath8LogGammaIdEET_S1_E6coeffs@Base 1.0.0
- _ZZN6WFMath8LogGammaIfEET_S1_E6coeffs@Base 1.0.0
+ (optional=inline)_ZZN6WFMath8LogGammaIdEET_S1_E6coeffs@Base 1.0.0
+ (optional=inline)_ZZN6WFMath8LogGammaIfEET_S1_E6coeffs@Base 1.0.0

Bug#830827: RFS: wvstreams/4.6.1-9 [QA, RC]

[Gert Wollny]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "wvstreams"

 * Package name: wvstreams
   Version : 4.6.1-9
   Upstream Author : Net Integration Technologies Inc. et al. 
 * URL : https://github.com/apenwarr/wvstreams/
 * License : LGPL-2.1 
   Section : libs

It builds those binary packages:

 libuniconf4.6 - C++ network libraries for rapid application
    development
 libwvstreams-dev - Development libraries and header files for 
    libwvstreams4.6Package: sponsorship-requests
  libwvstreams4.6-base - C++ network libraries for rapid application 
    development
 libwvstreams4.6-doc - Documentation for WvStreams
 libwvstreams4.6-extras - C++ network libraries for rapid application
    development
 uniconf-tools - Tools to interface with UniConf
 uniconfd   - Server that manages UniConf elements

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

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


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

 dget -x https://mentors.debian.net/debian/pool/main/w/wvstreams/wvstre
ams_4.6.1-9.dsc

Changes since the last upload:

  * d/p/gcc-6: Patch to fix compilation with gcc-6, Closes: #811659
  * run 'cme fix dpkg-control', updated standards version to 3.9.8 
  * d/compat, d/control: update compat level to 9
  * d/watch: Point to new github source location 
  * d/control: add new Github home page
  * d/uniconfd.init: source /lib/lsb/init-functions if available
  * d/rules: Add and install overrides for missing manpage of dev test 
program and the Doxygen created embedded javascript library 
  * d/rules: remove irrelevant *.md5 files from -doc package

Regards,
Gert 

Bug#830826: dropbear: Wrong location of hostkeys listed in docs and changelog. Probably a typo.

[gryffus]

Package: dropbear
Version: 2016.73-1
Severity: minor
Tags: patch

Hello,

I have noticed typos in dropbear documentation. They were introduced by 
the 
https://anonscm.debian.org/cgit/collab-maint/dropbear.git/commit/?id=8af5b1482c16a30dbf07f3404e468f39fc738226 
commit.

I have included a patch that fixes them.

Thank you,
Lukas Krejza
From 0bbda036bc5de09461172dd4e52dc4c4a6a02e16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Luk=C3=A1=C5=A1=20Krejza?= 
Date: Mon, 11 Jul 2016 22:22:47 +
Subject: [PATCH 1/1] Fix typo in docs and changelog

---
 debian/changelog   | 2 +-
 debian/dropbear-initramfs.NEWS | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 7666ad6..2a363e4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,7 +20,7 @@ dropbear (2016.73-1) unstable; urgency=low
   * dropbear-run:
 + Use dh_installdirs to create /etc/dropbear.
   * dropbear-initramfs:
-+ Take host keys (resp. authorized_keys) from /etc/initramfs-tools instead
++ Take host keys (resp. authorized_keys) from /etc/dropbear-initramfs 
instead
   of /etc/initramfs-tools/etc/dropbear (resp.
   /etc/initramfs-tools/root/.ssh).
   These files are automatically moved on upgrade.
diff --git a/debian/dropbear-initramfs.NEWS b/debian/dropbear-initramfs.NEWS
index 62fb09c..c791f7b 100644
--- a/debian/dropbear-initramfs.NEWS
+++ b/debian/dropbear-initramfs.NEWS
@@ -1,6 +1,6 @@
 dropbear-initramfs (2016.73-1) unstable; urgency=low
 
-Host keys (resp. authorized_keys) are now taken from /etc/initramfs-tools
+Host keys (resp. authorized_keys) are now taken from 
/etc/dropbear-initramfs
 instead of /etc/initramfs-tools/etc/dropbear (resp.
 /etc/initramfs-tools/root/.ssh).
 These files are automatically moved on upgrade.
-- 
2.8.1

Bug#830824: (no subject)

[Antonio Russo]

Sorry, there is no 0.6.5.8 release. The fix does exist in the master branch, 
however.
(bc77ba7: OpenZFS 6513 - partially filled holes lose birth time)

Bug#817479: gkrellweather: Removal of debhelper compat 4

[Roland Hieber]

Control: tags 817479 +patch

On Wed, 9 Mar 2016 21:55:49 + Niels Thykier  wrote:
> Norbert Veber:
> > Feel free to do an NMU if you have the time.
> If you have a tested patch, I do can find a sponsor for you.

Here is a minimal patch that works for me. I am not even sure whether
the dh_clean -k -> dh_prep change is really necessary for the bump to dh
9, but dh_clean was complaining about deprecated options, so why not.
Package builds without further warnings and a quick test in gkrellm
shows no issues.


Cheers,
  Roland
diff --git a/gkrellweather-2.0.8/debian/compat b/gkrellweather-2.0.8/debian/compat
index b8626c4..ec63514 100644
--- a/gkrellweather-2.0.8/debian/compat
+++ b/gkrellweather-2.0.8/debian/compat
@@ -1 +1 @@
-4
+9
diff --git a/gkrellweather-2.0.8/debian/control b/gkrellweather-2.0.8/debian/control
index 84ab4f0..05db77e 100644
--- a/gkrellweather-2.0.8/debian/control
+++ b/gkrellweather-2.0.8/debian/control
@@ -1,7 +1,7 @@
 Source: gkrellweather
 Section: x11
 Priority: optional
-Build-Depends: debhelper (>= 4), gkrellm (>= 2.1.4), libglib2.0-dev, libgtk2.0-dev
+Build-Depends: debhelper (>= 9), gkrellm (>= 2.1.4), libglib2.0-dev, libgtk2.0-dev
 Maintainer: Norbert Veber 
 Standards-Version: 3.8.0
 
diff --git a/gkrellweather-2.0.8/debian/rules b/gkrellweather-2.0.8/debian/rules
index 4401f78..738a3fb 100755
--- a/gkrellweather-2.0.8/debian/rules
+++ b/gkrellweather-2.0.8/debian/rules
@@ -23,7 +23,7 @@ clean:
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	install -D -s -m 755 gkrellweather.so $(CURDIR)/debian/gkrellweather/usr/lib/gkrellm2/plugins/gkrellweather.so

Bug#822670: dh-systemd should be merged into debhelper

[Raphael Hertzog]

Hi,

On Tue, 12 Jul 2016, Michael Biebl wrote:
> With todays upload of src:init-system-helpers, the move from
> dh_systemd_* from dh-systemd to debhelper has been completed.
> Do you think we should do a MBF for getting the reverse
> build-dependencies updated to use a versioned b-dep on debhelper (>=
> 9.20160709) instead of dh-systemd? Or should we add a lintian check for now?

Both are fine I would say. But I would not file bugs until a debhelper
newer than 9.20160709 is in jessie-backports.

A lintian check helps people to not introduce the mistake in new packages
as well whereas a bug report only helps already existing packages (but
will greatly help the conversion while lintian will not have that much
of an impact).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#830825: ITP: python-openid-cla -- OpenID CLA extension for python-openid

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-openid-cla
  Version : 1.2
  Upstream Author : Patrick Uiterwijk 
* URL : https://github.com/puiterwijk/python-openid-cla
* License : BSD-3-clause
  Programming Lang: Python
  Description : OpenID CLA extension for python-openid

 Implementation of the OpenID CLA extension for python-openid.  The
 purpose of this extension is to allow retrieving a list of signed
 contributor license agreements.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#830818: docker.io: Apparmor support mismatch between docker.io and containerd

[Tianon Gravi]

reassign 830818 runc
thanks

On 11 July 2016 at 13:15, Bodo-Merle Sandor  wrote:
> On a system with apparmor enabled, starting up a container gives the 
> following error:
>
> docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime 
> error: could not synchronise with container process: apparmor: config 
> provided but apparmor not supported".

Oh, good catch!  We need to include the "apparmor" build tag when we
build runc so that it supports AppArmor (and I've reassigned this bug
accordingly).

Adding the following to "debian/rules" in src:runc _should_ be sufficient:

| override_dh_auto_build:
| dh_auto_build -- -tags apparmor


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#822670: dh-systemd should be merged into debhelper

[Michael Biebl]

Am 26.04.2016 um 11:24 schrieb Raphaël Hertzog:
> Package: dh-systemd,debhelper
> Severity: wishlist
> 
> Hello dh-systemd maintainers and debhelper maintainers,
> 
> with the adoption of systemd as default init system for quite a while now,
> it does not make sense that we have to Build-Depend on dh-systemd and use
> dh --with systemd to be able to properly manage systemd units.
> 
> Please work together to find a way to merge dh-systemd into the standard
> features of debhelper 

With todays upload of src:init-system-helpers, the move from
dh_systemd_* from dh-systemd to debhelper has been completed.
Do you think we should do a MBF for getting the reverse
build-dependencies updated to use a versioned b-dep on debhelper (>=
9.20160709) instead of dh-systemd? Or should we add a lintian check for now?

Comments welcome.

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



signature.asc
Description: OpenPGP digital signature

Bug#830824: [zfs-linux] Silently corrupted file in snapshots after send/receive

[Antonio Russo]

Package: zfs-dkms
Version: 0.6.5.7-1
Severity: grave

--- Please enter the report below this line. ---

See ZoL bug report.

https://github.com/zfsonlinux/zfs/issues/4809

aka Illumos 6513

Short summary: Pools with hole_birth feature enabled are susceptible to
irreversible damage interfering with, in particular, proper zfs send/receive
behavior. The bug fix is in 0.6.5.8, but does not repair damage already
inflicted to the pool.

>From the ZoL bugreport, user pcd1193182:

 > The fix for illumos 6513 will solve this problem, but not retroactively.
 > In other words, any pools that already have this state will not be fixed;
 > on such pools, the hole BPs already have their birth times set to zero,
 > and zfs has no way of telling which ones are bugged and which are right.
 > Any new pools, created after the fix has been applied, will work.

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Sean Whitton]

On Mon, Jul 11, 2016 at 05:13:22PM +, Gianfranco Costamagna wrote:
> src:setcolortemperature
> binary: sct
> 
> please choose one, and use the same, you can't usually expect users to install
> a package and expect a binary called in another way.
> 
> I seem to be pedantic, but I really like to have them called in the same way

Aren't there different rationales for source and binary package names?
This is what I have been thinking:

- source package name should be upstream's name, because it's the
  *source*
- binary package name is whatever makes most sense for someone typing
  apt-get

-- 
Sean Whitton

Bug#830823: ITP: golang-github-cznic-lldb -- low level database engine

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 rkt

   Package name: golang-github-cznic-lldb
Version: 1.0.0
Upstream Author: Jan Mercl <0xj...@gmail.com>
License: BSD-3-Clause
URL: https://github.com/cznic/lldb
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-cznic-lldb.git
Description: low level database engine
 lldb is Golang implementation of a low level database engine.


"cznic/lldb" now considered to be mature so it is no longer will
be a part of "cznic/ql".


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

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Sebastian Andrzej Siewior]

control: tags -1 + patch fixed-upstream upstream
control: forwarded -1 https://bugzilla.clamav.net/show_bug.cgi?id=11549

On 2016-07-08 10:57:02 [-0600], Will Aoki wrote:
> Posted at 
> ftp://ftp.umnh.utah.edu/general-temporary/clamav/var_lib_clamav.tar.bz2
thanks.

> After additional testing, I think the problem lies with
> local-js-sigs.ndb. WIth that file removed, clamav still dumps debug
> warnings (when configured per the clamd.conf in the tarball) but does
> not seem to leak file descriptors.

I took 2015.NHMU_.AccessionForm_distributed-2.pdf and the
local-js-sigs.ndb from the archive and could reproduce the bug on 0.99.2
without any further changes. I applied the patch from upstream's
bugzilla #11549 and I could not reproduce the issue anymore.

Sebastian

Bug#827929: csound FTBFS on hppa architecture

[Felipe Sateler]

Control: tags -1 - patch

On 22 June 2016 at 15:58, Helge Deller  wrote:
> Package: csound
> Version: 1:6.05~dfsg1-7
> Tags: patch
>
> csound fails to build on hppa, because hppa uses gcj as java compiler, and
> in interfaces/CMakeLists.txt it's hardcoded:
>   COMMAND ${JAVA_COMPILE} *.java -source 1.6 -target 1.6 -d .
>
> gcj does not accept the -source and -target options.
> Removing those fixes build on hppa.
>
> Failing log is here:
> https://buildd.debian.org/status/fetch.php?pkg=csound=hppa=1%3A6.05%7Edfsg1-7=1463527847
>
> Attached patch fixes it for hppa, but is probably not useable for other 
> architectures.

Right, we can't do this on other archs, we just depend on the default java.

> Is there any other possible work around for this problem ?

Maybe the java interface can be disabled on hppa? There are no reverse
dependencies on debian.

-- 

Saludos,
Felipe Sateler

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Gianfranco Costamagna]

Hi,


>K == Kelvin, not kilo.

this is what happens when one person is not using google :)
thanks you all!

G.

Bug#830822: RM: haskell-gloss [armel armhf] -- ROM; removed dependencies

[Clint Adams]

Package: ftp.debian.org

haskell-gloss needs to disappear from armel/armhf
(due to haskell-{openglraw,gluraw,glut,opengl})

Bug#792746: Upgrading to 4.0.8-1 kernel makes external monitors unusable

[Enrico Zini]

On Sat, May 28, 2016 at 06:21:34PM +0200, Enrico Zini wrote:

> When the problem happens, this appears on dmesg:
> [227725.132861] [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder 
> B FIFO underrun

This seems fixed in 4.6.0-1-amd64:

   $ uptime
22:44:00 up 6 days,  7:52,  1 user,  load average: 0.28, 0.34, 0.24
   $ dmesg|grep transcoder
   $ 


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#830521: nvme-cli: Fix regression in nvme-cli 32-bit compatibility

[Breno Leitao]

> Please consider
> applying this patch in Debian as well, and forward upstream as necessary.

Just got the patch accepted by upstream maintainer also.

 
https://github.com/linux-nvme/nvme-cli/commit/90f00efdd89866b5f4f389c0b0a7ca4305c76303

The other two off-the-tree patches were also accepted now.

 
https://github.com/linux-nvme/nvme-cli/commit/90f00efdd89866b5f4f389c0b0a7ca4305c76303
 
https://github.com/linux-nvme/nvme-cli/commit/e49f9a46589cdf7b56bc47ac609a99d648d80ae1

Bug#803456: Digikam 5.0.0 uploaded

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 10 de julio de 2016 2:01:04 P. M. ART Steve M. Robbins wrote:
> Hi,
> 
> I wanted to make people aware that I have uploaded Digikam 5.0.0 packages to
> Debian earlier today.

First of all: thanks a lot.
 
> I uploaded to experimental for staging for a few reasons:
> 
> 1. To work through the build issues on various architectures.
> 
> 2. The configuration files are in a new location, but digikam does no
> migration [1].  To the user, it appears you are starting from scratch and
> there is a risk of confusion -- the referenced bug is from someone who
> thought (mistakenly) that a migration procedure was required.  The bug also
> references possibly using a KF5 function KConfig::copyTo() to migrate the
> files, but then concludes that some digikam 4 settings cause digikam 5 to
> crash.  At this point, it seems that automatic migration is unsafe but that
> the initial configuration wizard should be augmented with text that
> describes the upgrade- from-4.x scenario better.  I'm seeking suggestions
> on what might be the best approach here.

I would for starters file an RC bug to the version in experimental so users 
know this before it gets installed (thanks to apt-listbugs). This would also 
make the bug more visible.

Then I guess it's either provide patches upstream or wait for a fix :-/

> 3. The showfoto internationalized docs are missing due to an upstream bug
> [2]. The bug is now patched upstream; however, the fix re-structures the
> source tarball so it is unclear whether this is easy to port into the
> current version; or better to wait for upstream 5.1.0 source tarball.

We still have time before the freeze, do you think a new upstream release will 
happen during this timeframe? Else it could be an upstream snapshot.

Thanks a lot Steve!


-- 
Those are my principles. If you don't like them I have others.
 -- Groucho Marx

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#830580: Please also add "Provides: vim"

[Josh Triplett]

Additional patch attached.
>From da7da47191265c5a376c7e32726941621e47e60c Mon Sep 17 00:00:00 2001
From: Josh Triplett 
Date: Mon, 11 Jul 2016 13:33:59 -0700
Subject: [PATCH 2/2] Provides: vim

This allows vim addon packages that depend on vim to run with neovim
without having vim installed.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 8d45c2c..9817588 100644
--- a/debian/control
+++ b/debian/control
@@ -32,6 +32,7 @@ Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}, neovim-runtime (= ${source:Version})
 Recommends: xsel | xclip, python-neovim, python3-neovim
 Suggests: ctags, vim-scripts
+Provides: vim
 Description: heavily refactored vim fork
  Neovim is a fork of Vim focused on modern code and features, rather than
  running in legacy environments.
-- 
2.8.1

Bug#830821: [cron] No error for out of range stepwise values

[Alex]

Package: cron
Version: 3.0pl1-127+deb8u1
Severity: normal

--- Please enter the report below this line. ---

When using stepwise notation, there is no cron-error when a step-size is
picked which is bigger than the max. value of the field.
E.g. the following entry is valid: */500 */400 */31 */12 */300 MyCommand
And will be interpreted as:  * * * Jan *

Actually I quess it does not make much sense to pick a step-size which
is bigger than max/2 ... or is there any use-case ? Personally I would
restrict it to max/2.

Just let me know how you want to restrict it, and I will provide a patch!

Cheers,
Alex

--- System information. ---
Architecture: amd64
Kernel: Linux 3.16.0-4-amd64

Debian Release: 8.4
500 stable-updates ftp2.de.debian.org
500 stable www.deb-multimedia.org
500 stable security.debian.org
500 stable ftp2.de.debian.org
500 stable ftp.de.debian.org
100 jessie-backports httpredir.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-==
libc6 (>= 2.7) |
libpam0g (>= 0.99.7.1) |
libselinux1 (>= 1.32) |
init-system-helpers (>= 1.18~) |
debianutils (>= 1.7) |
adduser |
lsb-base (>= 3.0-10) |
libpam-runtime (>= 1.0.1-11) |


Package Status (Version) | Installed
=-+-===
nscd |
nis |
libpam-mount |
libpam-ldap |
libnss-ldap |
libnss-ldapd |


Recommends (Version) | Installed
===-+-===
exim4 | 4.84.2-1
OR postfix | 2.11.3-1
OR mail-transport-agent |


Suggests (Version) | Installed
-+-===
anacron (>= 2.0-1) | 2.3-23
logrotate | 3.8.7-1+b1
checksecurity |

Bug#830820: ruby-grape-msgpack: FTBFS: grape/msgpack.rb:39:in `': uninitialized constant Grape::Formatter::Base (NameError)

[Chris Lamb]

Source: ruby-grape-msgpack
Version: 0.1.2-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-grape-msgpack fails to build from source in unstable/amd64:

  [..]

  Unpacking libyaml-0-2:amd64 (0.1.6-3) ...
  Selecting previously unselected package libruby2.3:amd64.
  Preparing to unpack .../libruby2.3_2.3.1-5_amd64.deb ...
  Unpacking libruby2.3:amd64 (2.3.1-5) ...
  Selecting previously unselected package ruby2.3.
  Preparing to unpack .../ruby2.3_2.3.1-5_amd64.deb ...
  Unpacking ruby2.3 (2.3.1-5) ...
  Selecting previously unselected package ruby.
  Preparing to unpack .../ruby_1%3a2.3.0+4_amd64.deb ...
  Unpacking ruby (1:2.3.0+4) ...
  Selecting previously unselected package rake.
  Preparing to unpack .../archives/rake_10.5.0-2_all.deb ...
  Unpacking rake (10.5.0-2) ...
  Selecting previously unselected package gem2deb-test-runner.
  Preparing to unpack .../gem2deb-test-runner_0.31_amd64.deb ...
  Unpacking gem2deb-test-runner (0.31) ...
  Selecting previously unselected package libgmpxx4ldbl:amd64.
  Preparing to unpack .../libgmpxx4ldbl_2%3a6.1.1+dfsg-1_amd64.deb ...
  Unpacking libgmpxx4ldbl:amd64 (2:6.1.1+dfsg-1) ...
  Selecting previously unselected package libgmp-dev:amd64.
  Preparing to unpack .../libgmp-dev_2%3a6.1.1+dfsg-1_amd64.deb ...
  Unpacking libgmp-dev:amd64 (2:6.1.1+dfsg-1) ...
  Selecting previously unselected package ruby2.3-dev:amd64.
  Preparing to unpack .../ruby2.3-dev_2.3.1-5_amd64.deb ...
  Unpacking ruby2.3-dev:amd64 (2.3.1-5) ...
  Selecting previously unselected package ruby-all-dev:amd64.
  Preparing to unpack .../ruby-all-dev_1%3a2.3.0+4_amd64.deb ...
  Unpacking ruby-all-dev:amd64 (1:2.3.0+4) ...
  Selecting previously unselected package ruby-setup.
  Preparing to unpack .../ruby-setup_3.4.1-9_all.deb ...
  Unpacking ruby-setup (3.4.1-9) ...
  Selecting previously unselected package gem2deb.
  Preparing to unpack .../gem2deb_0.31_amd64.deb ...
  Unpacking gem2deb (0.31) ...
  Selecting previously unselected package ruby-i18n.
  Preparing to unpack .../ruby-i18n_0.7.0-2_all.deb ...
  Unpacking ruby-i18n (0.7.0-2) ...
  Selecting previously unselected package ruby-json.
  Preparing to unpack .../ruby-json_1.8.3-1+b3_amd64.deb ...
  Unpacking ruby-json (1.8.3-1+b3) ...
  Selecting previously unselected package ruby-atomic.
  Preparing to unpack .../ruby-atomic_1.1.16-2+b6_amd64.deb ...
  Unpacking ruby-atomic (1.1.16-2+b6) ...
  Selecting previously unselected package ruby-thread-safe.
  Preparing to unpack .../ruby-thread-safe_0.3.5-3_all.deb ...
  Unpacking ruby-thread-safe (0.3.5-3) ...
  Selecting previously unselected package ruby-tzinfo.
  Preparing to unpack .../ruby-tzinfo_1.2.2-1_all.deb ...
  Unpacking ruby-tzinfo (1.2.2-1) ...
  Selecting previously unselected package ruby-activesupport.
  Preparing to unpack .../ruby-activesupport_2%3a4.2.6-1_all.deb ...
  Unpacking ruby-activesupport (2:4.2.6-1) ...
  Selecting previously unselected package ruby-blankslate.
  Preparing to unpack .../ruby-blankslate_3.1.3-1_all.deb ...
  Unpacking ruby-blankslate (3.1.3-1) ...
  Selecting previously unselected package ruby-builder.
  Preparing to unpack .../ruby-builder_3.2.2-4_all.deb ...
  Unpacking ruby-builder (3.2.2-4) ...
  Selecting previously unselected package ruby-hashie.
  Preparing to unpack .../ruby-hashie_3.4.4-1_all.deb ...
  Unpacking ruby-hashie (3.4.4-1) ...
  Selecting previously unselected package ruby-multi-json.
  Preparing to unpack .../ruby-multi-json_1.11.2-3_all.deb ...
  Unpacking ruby-multi-json (1.11.2-3) ...
  Selecting previously unselected package ruby-multi-xml.
  Preparing to unpack .../ruby-multi-xml_0.5.5-2_all.deb ...
  Unpacking ruby-multi-xml (0.5.5-2) ...
  Selecting previously unselected package ruby-mustermann19.
  Preparing to unpack .../ruby-mustermann19_0.4.3+git20160621-1_all.deb ...
  Unpacking ruby-mustermann19 (0.4.3+git20160621-1) ...
  Selecting previously unselected package ruby-rack.
  Preparing to unpack .../ruby-rack_1.6.4-3_all.deb ...
  Unpacking ruby-rack (1.6.4-3) ...
  Selecting previously unselected package ruby-rack-accept.
  Preparing to unpack .../ruby-rack-accept_0.4.5-3_all.deb ...
  Unpacking ruby-rack-accept (0.4.5-3) ...
  Selecting previously unselected package ruby-descendants-tracker.
  Preparing to unpack .../ruby-descendants-tracker_0.0.4-2_all.deb ...
  Unpacking ruby-descendants-tracker (0.0.4-2) ...
  Selecting previously unselected package ruby-ice-nine.
  Preparing to unpack .../ruby-ice-nine_0.11.2-1_all.deb ...
  Unpacking ruby-ice-nine (0.11.2-1) ...
  Selecting previously unselected package ruby-axiom-types.
  Preparing to unpack .../ruby-axiom-types_0.1.1-1_all.deb ...
  Unpacking ruby-axiom-types (0.1.1-1) ...
  Selecting previously unselected package ruby-coercible.
  Preparing to unpack .../ruby-coercible_1.0.0-2_all.deb ...
  

Bug#830819: resteasy: FTBFS: Could not resolve dependencies for project org.jboss.resteasy:tjws:jar:3.0.12.Final

[Chris Lamb]

Source: resteasy
Version: 3.0.12-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

resteasy fails to build from source in unstable/amd64:

  [..]

  Running hooks in /etc/ca-certificates/update.d...
  
  Adding debian:ACCVRAIZ1.pem
  Adding debian:ACEDICOM_Root.pem
  Adding debian:AC_Raíz_Certicámara_S.A..pem
  Adding debian:Actalis_Authentication_Root_CA.pem
  Adding debian:AddTrust_External_Root.pem
  Adding debian:AddTrust_Low-Value_Services_Root.pem
  Adding debian:AddTrust_Public_Services_Root.pem
  Adding debian:AddTrust_Qualified_Certificates_Root.pem
  Adding debian:AffirmTrust_Commercial.pem
  Adding debian:AffirmTrust_Networking.pem
  Adding debian:AffirmTrust_Premium.pem
  Adding debian:AffirmTrust_Premium_ECC.pem
  Adding debian:ApplicationCA_-_Japanese_Government.pem
  Adding debian:Atos_TrustedRoot_2011.pem
  Adding debian:Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
  Adding debian:Baltimore_CyberTrust_Root.pem
  Adding debian:Buypass_Class_2_CA_1.pem
  Adding debian:Buypass_Class_2_Root_CA.pem
  Adding debian:Buypass_Class_3_Root_CA.pem
  Adding debian:CA_Disig.pem
  Adding debian:CA_Disig_Root_R1.pem
  Adding debian:CA_Disig_Root_R2.pem
  Adding debian:CA_WoSign_ECC_Root.pem
  Adding debian:CFCA_EV_ROOT.pem
  Adding debian:CNNIC_ROOT.pem
  Adding debian:COMODO_Certification_Authority.pem
  Adding debian:COMODO_ECC_Certification_Authority.pem
  Adding debian:COMODO_RSA_Certification_Authority.pem
  Adding debian:Camerfirma_Chambers_of_Commerce_Root.pem
  Adding debian:Camerfirma_Global_Chambersign_Root.pem
  Adding debian:Certification_Authority_of_WoSign_G2.pem
  Adding debian:Certigna.pem
  Adding debian:Certinomis_-_Autorité_Racine.pem
  Adding debian:Certinomis_-_Root_CA.pem
  Adding debian:Certplus_Class_2_Primary_CA.pem
  Adding debian:Certum_Root_CA.pem
  Adding debian:Certum_Trusted_Network_CA.pem
  Adding debian:Chambers_of_Commerce_Root_-_2008.pem
  Adding 
debian:China_Internet_Network_Information_Center_EV_Certificates_Root.pem
  Adding debian:ComSign_CA.pem
  Adding debian:Comodo_AAA_Services_root.pem
  Adding debian:Comodo_Secure_Services_root.pem
  Adding debian:Comodo_Trusted_Services_root.pem
  Adding debian:Cybertrust_Global_Root.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_2009.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_EV_2009.pem
  Adding debian:DST_ACES_CA_X6.pem
  Adding debian:DST_Root_CA_X3.pem
  Adding debian:Deutsche_Telekom_Root_CA_2.pem
  Adding debian:DigiCert_Assured_ID_Root_CA.pem
  Adding debian:DigiCert_Assured_ID_Root_G2.pem
  Adding debian:DigiCert_Assured_ID_Root_G3.pem
  Adding debian:DigiCert_Global_Root_CA.pem
  Adding debian:DigiCert_Global_Root_G2.pem
  Adding debian:DigiCert_Global_Root_G3.pem
  Adding debian:DigiCert_High_Assurance_EV_Root_CA.pem
  Adding debian:DigiCert_Trusted_Root_G4.pem
  Adding debian:E-Tugra_Certification_Authority.pem
  Adding debian:EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem
  Adding debian:EC-ACC.pem
  Adding debian:EE_Certification_Centre_Root_CA.pem
  Adding debian:Entrust.net_Premium_2048_Secure_Server_CA.pem
  Adding debian:Entrust_Root_Certification_Authority.pem
  Adding debian:Entrust_Root_Certification_Authority_-_EC1.pem
  Adding debian:Entrust_Root_Certification_Authority_-_G2.pem
  Adding debian:Equifax_Secure_CA.pem
  Adding debian:Equifax_Secure_Global_eBusiness_CA.pem
  Adding debian:Equifax_Secure_eBusiness_CA_1.pem
  Adding debian:GeoTrust_Global_CA.pem
  Adding debian:GeoTrust_Global_CA_2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem
  Adding debian:GeoTrust_Universal_CA.pem
  Adding debian:GeoTrust_Universal_CA_2.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R4.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem
  Adding debian:GlobalSign_Root_CA.pem
  Adding debian:GlobalSign_Root_CA_-_R2.pem
  Adding debian:GlobalSign_Root_CA_-_R3.pem
  Adding debian:Global_Chambersign_Root_-_2008.pem
  Adding debian:Go_Daddy_Class_2_CA.pem
  Adding debian:Go_Daddy_Root_Certificate_Authority_-_G2.pem
  Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
  Adding debian:Hongkong_Post_Root_CA_1.pem
  Adding debian:IGC_A.pem
  Adding debian:IdenTrust_Commercial_Root_CA_1.pem
  Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem
  Adding debian:Izenpe.com.pem
  Adding debian:Juur-SK.pem
  Adding debian:Microsec_e-Szigno_Root_CA.pem
  Adding debian:Microsec_e-Szigno_Root_CA_2009.pem
  Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
  Adding debian:NetLock_Business_=Class_B=_Root.pem
  Adding debian:NetLock_Express_=Class_C=_Root.pem
  Adding debian:NetLock_Notary_=Class_A=_Root.pem
  Adding debian:NetLock_Qualified_=Class_QA=_Root.pem
  Adding 

Bug#830683: Missing dependency on module-udev?

[bugs-debian]

On Sun, 10 Jul 2016 23:37:01 -0300 Felipe Sateler 
wrote:
>
> Do you have disabled installation of Recommends?
>

Hi,

I guess he did, just like me, because installing recommends often leads
to a workload of useless packages.
Even if I totally understand that the packager is not expected to
support every configuration, maybe a line or two in NEWS.Debian should
be enough. I read each Changelog.Debian, I saw the split announcement,
but I totally missed the fact that it will render my system soundless.

Adrien

Bug#830817: qtdeclarative-opensource-src: FTBFS on m68k due to mismatched symbols file

[John Paul Adrian Glaubitz]

Source: qtdeclarative-opensource-src
Version: 5.6.1-4
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

qtdeclarative-opensource-src currently fails to build from source on m68k due 
to a mismatched symbols file [1]:

dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libqt5qml5/DEBIAN/symbols doesn't match 
completely debian/libqt5qml5.symbols
--- debian/libqt5qml5.symbols (libqt5qml5_5.6.1-4_m68k)
+++ dpkg-gensymbolsR2I92y 2016-07-10 08:54:27.0 +
@@ -1206,9 +1206,9 @@
  _ZN3QV412CompiledData7Binding13escapedStringERK7QString@Qt_5_PRIVATE_API 
5.4.0 1
  _ZN3QV412EvalFunction11static_vtblE@Qt_5_PRIVATE_API 5.2.0~beta1 1
  _ZN3QV412EvalFunction4callEPKNS_7ManagedEPNS_8CallDataE@Qt_5_PRIVATE_API 
5.6.0~beta 1
- (optional=templinst|arch=armel armhf hppa hurd-i386 i386 kfreebsd-i386 mips 
mipsel 
powerpc)_ZN3QV413MemoryManager11allocObjectINS_15BuiltinFunctionEPNS_16ExecutionContextEPNS_6StringEPFyPNS_11CallContextPNT_4DataET0_T1_T2_@Qt_5_PRIVATE_API
 5.6.0~beta 1
- (optional=templinst|arch=alpha mips mips64el 
powerpc)_ZN3QV413MemoryManager11allocObjectINS_6ObjectEEEPNT_4DataEPNS_13InternalClassEPS2_@Qt_5_PRIVATE_API
 5.6.0~beta 1
- (optional=templinst|arch=alpha armel armhf hppa hurd-i386 i386 kfreebsd-i386 
mips mips64el mipsel powerpc 
x32)_ZN3QV413MemoryManager11allocObjectINS_6ObjectEEEPNT_4DataEv@Qt_5_PRIVATE_API
 5.6.0~beta 1
+ 
(optional=templinst)_ZN3QV413MemoryManager11allocObjectINS_15BuiltinFunctionEPNS_16ExecutionContextEPNS_6StringEPFyPNS_11CallContextPNT_4DataET0_T1_T2_@Qt_5_PRIVATE_API
 5.6.0~beta 1
+ 
(optional=templinst)_ZN3QV413MemoryManager11allocObjectINS_6ObjectEEEPNT_4DataEPNS_13InternalClassEPS2_@Qt_5_PRIVATE_API
 5.6.0~beta 1
+ 
(optional=templinst)_ZN3QV413MemoryManager11allocObjectINS_6ObjectEEEPNT_4DataEv@Qt_5_PRIVATE_API
 5.6.0~beta 1
  _ZN3QV413MemoryManager12setGCBlockedEb@Qt_5_PRIVATE_API 5.2.0~beta1 1
  
(subst)_ZN3QV413MemoryManager26growUnmanagedHeapSizeUsageE{size_t}@Qt_5_PRIVATE_API
 5.5.1 1
  _ZN3QV413MemoryManager4markEv@Qt_5_PRIVATE_API 5.2.0~beta1 1
@@ -1676,7 +1676,7 @@
  
_ZN3QV46Object22defineReadonlyPropertyEPNS_6StringERKNS_5ValueE@Qt_5_PRIVATE_API
 5.5.0 1
  
_ZN3QV46Object22defineReadonlyPropertyERK7QStringRKNS_5ValueE@Qt_5_PRIVATE_API 
5.5.0 1
  _ZN3QV46Object22internalDeletePropertyEPNS_6StringE@Qt_5_PRIVATE_API 5.4.0 1
- (arch=!amd64 !hurd-i386 !i386 !kfreebsd-amd64 !kfreebsd-i386 
!x32)_ZN3QV46Object23setArrayLengthUncheckedEj@Qt_5_PRIVATE_API 5.6.0~beta 1
+#MISSING: 5.6.1-4# (arch=!amd64 !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !x32)_ZN3QV46Object23setArrayLengthUncheckedEj@Qt_5_PRIVATE_API 
5.6.0~beta 1
  _ZN3QV46Object29internalDeleteIndexedPropertyEj@Qt_5_PRIVATE_API 5.2.0~beta1 1
  _ZN3QV46Object3getEPKNS_7ManagedEPNS_6StringEPb@Qt_5_PRIVATE_API 5.6.0~beta 1
  
_ZN3QV46Object3putEPNS_15ExecutionEngineERK7QStringRKNS_5ValueE@Qt_5_PRIVATE_API
 5.5.0 1
@@ -2934,7 +2934,7 @@
  (optional=templinst|arch=alpha armel armhf powerpc ppc64 ppc64el 
s390x)_ZSt4swapI11QModelIndexEvRT_S2_@Qt_5 5.5.0
  (optional=templinst)_ZSt4swapI19QItemSelectionRangeEvRT_S2_@Qt_5 5.6.0~rc
  (optional=templinst|arch=alpha armel armhf powerpc ppc64 ppc64el 
s390x)_ZSt4swapIN6QQmlJS7Codegen6ResultEEvRT_S4_@Qt_5_PRIVATE_API 5.6.0~beta 1
- (optional=templinst|arch=armel armhf hurd-i386 i386 kfreebsd-i386 mips mipsel 
powerpc)_ZSt4swapIN8QVariant7PrivateEEvRT_S3_@Qt_5 5.0.2
+ (optional=templinst)_ZSt4swapIN8QVariant7PrivateEEvRT_S3_@Qt_5 5.0.2
  _ZTI10QQmlEngine@Qt_5 5.0.2
  _ZTI11QQmlBinding@Qt_5_PRIVATE_API 5.0.2 1
  _ZTI11QQmlCleanup@Qt_5_PRIVATE_API 5.0.2 1
dh_makeshlibs: failing due to earlier errors

Please use the diff provide above to update the symbols file.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=qtdeclarative-opensource-src=m68k=5.6.1-4=1468140958

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

Bug#830818: docker.io: Apparmor support mismatch between docker.io and containerd

[Bodo-Merle Sandor]

Package: docker.io
Version: 1.11.2~ds1-3
Severity: normal

Dear Maintainer,

On a system with apparmor enabled, starting up a container gives the following 
error:

docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime 
error: could not synchronise with container process: apparmor: config provided 
but apparmor not supported".


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

Kernel: Linux 4.3.0-1-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 docker.io depends on:
ii  adduser  3.115
ii  containerd   0.2.1~ds1-2
ii  init-system-helpers  1.37
ii  iptables 1.6.0-2
ii  libapparmor1 2.10.95-4
ii  libc62.23-1
ii  libdevmapper1.02.1   2:1.02.127-1
ii  libsqlite3-0 3.13.0-1
ii  libsystemd0  230-7
ii  runc 0.1.0+dfsg1-1

Versions of packages docker.io recommends:
ii  ca-certificates   20160104
pn  cgroupfs-mount | cgroup-lite  
ii  git   1:2.8.1-1
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages docker.io suggests:
ii  aufs-tools   1:3.2+20130722-1.1
ii  btrfs-progs  4.5.2-1
ii  debootstrap  1.0.81
pn  lxc  
pn  rinse
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#830816: mpdris2: GLib.Error: ... The name org.freedesktop.Notifications was not provided by any .service files (2)

[Ben Longbons]

Package: mpdris2
Version: 0.7+git20160206-1
Severity: normal

Dear Maintainer,

Suddenly, mpdris2 fails to start. Since normally mpdris2 just runs
constantly in the background, and I usually stay logged in, I'm not
sure how long this has been a problem.

2016-07-11 13:08:29,942 mpDris2 INFO: Using file:///home/ben/Music as music 
library path.
2016-07-11 13:08:29,942 mpDris2 INFO: Mutagen not available, covers in music 
files will be ignored.
2016-07-11 13:08:29,948 mpDris2 WARNING: Failed to connect to GNOME Settings 
Daemon. Media keys won't work.
Traceback (most recent call last):
  File "/usr/bin/mpDris2", line 1290, in 
mpd_wrapper.run()
  File "/usr/bin/mpDris2", line 275, in run
if self.my_connect():
  File "/usr/bin/mpDris2", line 342, in my_connect
self.timer_callback()
  File "/usr/bin/mpDris2", line 432, in timer_callback
self._update_properties(force=False)
  File "/usr/bin/mpDris2", line 703, in _update_properties
self.notify_about_track(new_meta, new_status['state'])
  File "/usr/bin/mpDris2", line 591, in notify_about_track
notification.notify(title, body, uri)
  File "/usr/bin/mpDris2", line 838, in notify
self._notification.show()
GLib.Error: g-dbus-error-quark: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files (2)


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

Kernel: Linux 4.6.0-1-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 mpdris2 depends on:
ii  dbus 1.10.8-1
ii  python   2.7.11-2
ii  python-dbus  1.2.4-1
ii  python-gi3.20.1-1
ii  python-mpd   0.3.0-4

Versions of packages mpdris2 recommends:
ii  gir1.2-notify-0.7  0.7.6-2

Versions of packages mpdris2 suggests:
ii  mpd  0.19.16-1

-- no debconf information

Bug#828140: WARNING **: /usr/lib/midori/libformhistory.so: cannot open shared object file: No such file or directory

[Sergio Durigan Junior]

On Saturday, June 25 2016, 積丹尼 Dan Jacobson wrote:

> Package: midori
> Version: 0.5.11-ds1-100~exp1
>
> ** (midori4:23531): WARNING **: /usr/lib/midori/libformhistory.so: cannot 
> open shared object file: No such file or directory
>
> ** (midori4:23531): WARNING **: /usr/lib/midori/libnsplugin-manager.so: 
> cannot open shared object file: No such file or directory

Do you still see this bug with the new version in experimental?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Kalle Olavi Niemitalo]

I have implemented the term changes almost as planned:

> * Copy the discard-output flag from the FLUSHO bit of
>   termios::c_lflag, when TIOCSETA, TIOCSETAW, or TIOCSETAF is
>   used.  This is term/users.c (set_state), I believe.  The GNU C
>   Library already defines FLUSHO in both  and
>   .

It was easier to delete the FLUSH_OUTPUT flag altogether and make
everything use the FLUSHO flag of termstate.c_lflag instead.
That way, the discard-output flag doesn't have to be separately
copied.  This change alone causes the discard-output flag to be
cleared in each new ssh session, and when bash is about to
display its prompt.  It's definitely an improvement.

> * Clear the discard-output flag when TIOCSTART is used.
>   This is term/users.c (S_tioctl_tiocstart), I believe.

Right, S_tioctl_tiocstart should clear FLUSHO, like it clears
USER_OUTPUT_SUSP except in a different variable.
I didn't test this part though.

> * Clear the discard-output flag when the user types almost any
>   other character, like the glibc documentation said.

That was the hardest part.  input_character should clear FLUSHO
on any character, unless:
(1) the character is the DISCARD character and it caused FLUSHO
to be set during the current call; or
(2) the character is the STOP character and it caused
USER_OUTPUT_SUSP to be set during the current call; or
(3) USER_OUTPUT_SUSP was already set on entry, and was not
cleared during the current call because the character is not
the START character and the IXANY mode is not set.
I implemented those at the end of input_character.  The code
detects (1) by checking whether FLUSHO is clear in the lflag
variable, which was copied from termstate.c_lflag at the
beginning of input_character.

Also, if input_character clears FLUSHO during the current call,
then any previously set FLUSHO must not prevent the current
character from being echoed.  I implemented that by making
echo_char clear FLUSHO unconditionally.  (This is similar to what
NetBSD does, except they also have some weird flag for tabs.)
echo_char is called only from within input_character (possibly
via reprint_line or erase_l), so the user must have typed
something if echo_char is called; and it is not called in the
cases (1)(2)(3) listed above.  (Arguably, it should be called in
case (1), but that is no problem if FLUSHO is set after the call
rather than before.)  If echoing is disabled, then echo_char is
not called so FLUSHO may remain set longer than usual, but it
will be cleared at the end of input_character anyway.

A Hurd developer advised me not to post the patches themselves
because I don't intend to assign copyright to the FSF.  The
diffstat (not counting the "prominent notices") is 18 insertions
and 7 deletions, and the FSF considers "around 15 lines of code"
the limit for a "tiny change".


pgpomQPr4d23H.pgp
Description: PGP signature

Bug#830815: libsdl2-2.0-0: SDL_RestoreWindow doesn't restore the window

[Sascha Reißner]

Package: libsdl2-2.0-0
Version: 2.0.2+dfsg1-6
Severity: normal

Dear Maintainer,

i write a program with SDL2 and when i resize the window, the content ins't
proportional.
So i wrote a function that will be called if F11 is pressed.

typedef struct visual_s {
SDL_Window *window;
…
} visual_t;

void set_proportion(visual_t *visual) {

int x, y, w, h, max_w, max_h;

SDL_GetWindowPosition(visual->window, , );
printf("Window pos  %d / %d!\n", x, y);

SDL_GetWindowSize(visual->window, , );
printf("Window size %d / %d!\n", w, h);

SDL_GetWindowMaximumSize(visual->window, _w, _h);
printf("Window max  %d / %d!\n", max_w, max_h);

SDL_RestoreWindow(visual->window);
SDL_SetWindowPosition(visual->window, x, y);

if (w * SCREEN_HEIGHT / SCREEN_WIDTH > h) {
w = h * SCREEN_WIDTH / SCREEN_HEIGHT;
SDL_SetWindowSize(visual->window, w, h);
printf("Window set to %d x %d!\n", w, h);
}

else if (h * SCREEN_WIDTH / SCREEN_HEIGHT > w) {
h = w * SCREEN_HEIGHT / SCREEN_WIDTH;
SDL_SetWindowSize(visual->window, w, h);
printf("Window set to %d x %d!\n", w, h);
}

else {
printf("Window is proportional!\n");
}
}

This function works great, if the window isn't maximized.
If i maximize the window (right most button at titlebar) and press F11,
the border of the window is still maximized. Only the content shift to the
right size.
So, i have insert the lines:

uint32_t flags;
flags = SDL_GetWindowFlags(visual->window);
printf("Window flags:  %08x\n", flags);

and it shows me:
Window flags:  0626

But the flag for SDL_WINDOW_MAXIMIZED is 0x0080
The function SDL_RestoreWindow looks also to the flags and will only act,
if SDL_WINDOW_MAXIMIZED or SDL_WINDOW_MINIMIZED is set.
So, it looks like the flags will not refrect the current state.

I have only tested on Debian jessie with libsdl2 2.0.2.
Don't know, if this bug is fixed in libsdl2 2.0.4.



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

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

Versions of packages libsdl2-2.0-0 depends on:
ii  libasound2  1.0.28-1
ii  libc6   2.19-18+deb8u4
ii  libpulse0   5.0-13
ii  libwayland-client0  1.6.0-2
ii  libwayland-cursor0  1.6.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  10.3.2-1+deb8u1
ii  libx11-62:1.6.2-3
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxi6  2:1.7.4-1+b2
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.4.3-2
ii  libxrandr2  2:1.4.2-1+b1
ii  libxss1 1:1.2.2-1
ii  libxxf86vm1 1:1.1.3-1+b1
ii  multiarch-support   2.19-18+deb8u4

libsdl2-2.0-0 recommends no packages.

libsdl2-2.0-0 suggests no packages.

-- no debconf information

Bug#829654: fcgiwrap git repository permissions

[Peter Colberg]

Hi Jordi,

It seems the collab-maint/fcgiwrap.git repository does not have the
right permissions. Some of the files and directories have the group
"Debian", which appears to be reserved to DDs.

Could you fix the permissions on alioth?

chgrp -R scm_collab-maint /git/collab-maint/fcgiwrap.git


Could you also add my UID to the upload ACL for fcgiwrap?

I will ping you for review before the upload.

Peter


signature.asc
Description: PGP signature

Bug#793387:

[Antonio Terceiro]

On Mon, Jul 04, 2016 at 11:25:34AM +0200, Daniel Scharon wrote:
> Hi,
> 
> can we still expect an update for stable that fixes this?

we could, but I need help as I explained earlier in this bug report.

> Or do we have to wait for a backport of the version in stretch (if that
> is in any way feasible)?

probably not happening as that would involve also backporting the entire
rails stack and quite a few other dependencies.


signature.asc
Description: PGP signature

Bug#830813: mrtg-ip-acct:error: Error reading /proc/net/dev

[Vincent van Leeuwen]

Package: mrtgutils
Version: 0.8.2
Severity: important

Dear Maintainer,


After installing mrtgutils 0.8.2 mrtg-ip-acct fails to load. Going back to 
version 0.8.1 solves the problem:

root@ur-quan:/var/cache/apt/archives# dpkg -i mrtgutils_0.8.1_i386.deb
dpkg: warning: downgrading mrtgutils from 0.8.2 to 0.8.1
(Reading database ... 185656 files and directories currently installed.)
Preparing to unpack mrtgutils_0.8.1_i386.deb ...
Unpacking mrtgutils (0.8.1) over (0.8.2) ...
Setting up mrtgutils (0.8.1) ...
Processing triggers for man-db (2.7.5-1) ...
root@ur-quan:/var/cache/apt/archives# mrtg-ip-acct vlan2
2944187517563
507067075054
  9:34pm  up 359 days,  2:45, 20 users,  load average: 0.51, 0.41, 0.30
ur-quan.vinz.nl
root@ur-quan:/var/cache/apt/archives# dpkg -i mrtgutils_0.8.2_i386.deb
(Reading database ... 185654 files and directories currently installed.)
Preparing to unpack mrtgutils_0.8.2_i386.deb ...
Unpacking mrtgutils (0.8.2) over (0.8.1) ...
Setting up mrtgutils (0.8.2) ...
Processing triggers for man-db (2.7.5-1) ...
root@ur-quan:/var/cache/apt/archives# mrtg-ip-acct vlan2
mrtg-ip-acct:error: Error reading /proc/net/dev
root@ur-quan:/var/cache/apt/archives#


I am running a slightly older kernel (4.0.0), no idea if that matters. A strace 
implies there is no problem opening /proc/net/dev:


root@ur-quan:/var/cache/apt/archives# strace mrtg-ip-acct vlan2
execve("/usr/bin/mrtg-ip-acct", ["mrtg-ip-acct", "vlan2"], [/* 31 vars */]) = 0
brk(NULL)   = 0x884f000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7727000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=82296, ...}) = 0
mmap2(NULL, 82296, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7712000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\206\1\0004\0\0\0"..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1791848, ...}) = 0
mmap2(NULL, 1800828, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb755a000
mprotect(0xb770b000, 4096, PROT_NONE)   = 0
mmap2(0xb770c000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b1000) = 0xb770c000
mmap2(0xb770f000, 10876, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb770f000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7559000
set_thread_area({entry_number:-1, base_addr:0xb7559940, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0 (entry_number:6)
mprotect(0xb770c000, 8192, PROT_READ)   = 0
mprotect(0x804a000, 4096, PROT_READ)= 0
mprotect(0xb774e000, 4096, PROT_READ)   = 0
munmap(0xb7712000, 82296)   = 0
brk(NULL)   = 0x884f000
brk(0x887)  = 0x887
open("/proc/net/dev", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7726000
read(3, "Inter-|   Receive   "..., 1024) = 1024
read(3, "   000 0  0 "..., 1024) = 629
read(3, "", 1024)   = 0
write(2, "mrtg-ip-acct:error: Error readin"..., 48mrtg-ip-acct:error: Error 
reading /proc/net/dev
) = 48
exit_group(2)   = ?
+++ exited with 2 +++
root@ur-quan:/var/cache/apt/archives#


Hope you can shed some light on this!

Kind regards,
Vincent van Leeuwen


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (400, 'unstable'), (300, 
'experimental')
Architecture: i386 (i686)

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

Versions of packages mrtgutils depends on:
ii  libc6  2.22-13

mrtgutils recommends no packages.

Versions of packages mrtgutils suggests:
pn  mrtg   
pn  mrtgutils-sensors  

-- no debconf information

Bug#830814: ThinkPad x260 keyboard backlight state not restored

[Joonas Kylmälä]

Package: gnome-settings-daemon
Version: 3.20.1-2
Severity: normal

When I resume Lenovo ThinkPad x260 from resume the keyboard
backlight's state doesn't get restored. So for example if the keyboard
is off (brightness is 0, the scale is 0-2) when going to sleep then
when resuming the keyboard backlight will be turned on (brightness =
1). So also if the brightness = 2 when going to sleep it will be
changed to 1 when resuming. I already faced this same bug in the
Fedora GNU/Linux distribution and filed the bug to
. There might be
some useful info to solve this problem.

In ubuntu they have made a patch to the same problem (included already
to Debian sid):
.
And the bug report for this patch:
. But for
ThinkPad 260 it didn't work.

Quote from Redhat Bugzilla:

"For me, x260 thinkpad, changing the line in gsd-power-manger.c to
 if (manager->priv->kbd_brightness_now < 0) {
didn't fix the problem."

"So the bug in my case is not in that particular piece of code because
it sets the kb backlight to max and for me it sets it to 1 (my kb
backlight is in scale of 0-2). It sets it to 1 nevertheless if it's
before going to sleep 0 or 2."

The ThinkPad x260's keyboard backlight is controlled with the module
thinkpad_acpi, in case that the bug might be there.

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

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

Bug#830579: [Pkg-xfce-devel] Bug#830579: xfce4: screen locked with screensaver disabled and nothing to configure it

[José Luis González]

On Mon, 11 Jul 2016 10:43:19 +0200
Yves-Alexis Perez  wrote:

> On Sat, 2016-07-09 at 19:10 +0200, José Luis González wrote:
> > My screen gets locked requiring username/password authentication to
> > unlock after some time even when screensaver is disabled and I see
> > nothing to configure it from locking.
> > 
> > After some research I see locking is now handled by light-locker, but
> > it seems the UI to change its settings (light-locker-settings) is not
> > available on my installation of XFCE.
> 
> There's no light-locker-settings in Xfce. Locking is done when the X11
> screensaver is activated (for example through DPMS). You might have configured
> it through the power manager settings.

I have screen power management enabled but nowhere it says it activates
the screensaver, so I'm confused. If screen blank, suspension
and poweroff are enabled the X11 screensaver is activated even though
there is none? When does it trigger, on blank? If so, why is there no
setting in light-locker to disable it? A user may want screen power
management but not screen lock on blank. If light-locker is enabled by
default on XFCE installations I understand there must be a user
intuitive way to disable it other than discovering that it's the
culprit of the lock and it must be disabled in Session and Start.

Thanks anyway for the explanation.

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[Martin von Wittich]

Hi Michael,

> I pulled the patch mentioned in this bug report into our jessie branch
> [1]. This means it will be part of the next stable release which is
> scheduled for the upcoming 8.6 point release.
> 
> I created debs which you can get from [2]. I versioned them so that the
> package will nicely upgrade once the final 215-17+deb8u5 reaches the
> stable archive.
> It would be great if you install and test those packages and report back.

Thanks! I've installed the new systemd packages on 10 of our 12 development 
VMs; I couldn't install them on the other two because those are i386. If you 
could provide i386 builds, I'll install them on those machines too.

It didn't take longer than a day for that issue to occur on at least one 
machine, so testing this shouldn't take too long. I've set up reminders on 
Wednesday and Friday so that I won't forget to report back.

Martin

Bug#830812: O: referencer

[Denis Laxalde]

Package: wnpp
Severity: normal

I intent to orphan referencer as I stopped using this software for a
couple of years now and am not able to maintain it in Debian anymore.
Upstream does not look very active either (no release for two years) so
I'm not sure it's really maintained after all.

Bug#830811: mathic: Symbols file compatibility with -O3

[Steve Langasek]

Package: mathic
Version: 1.0~git20160320-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Hi Doug,

The Ubuntu ppc64el port uses -O3 optimization for package builds by default. 
Under -O3, there are a number of template symbols that are not exported in
libmathic because they wind up inlined instead.  As a result, mathic fails
to build with a mismatched symbols file error.

The attached patch has been applied in Ubuntu to mark these additional
symbols optional, since they are not part of the ABI, and allows the package
to build wherever -O3 is used.

Thanks for considering the patch.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mathic-1.0~git20160320/debian/libmathic0v5.symbols mathic-1.0~git20160320/debian/libmathic0v5.symbols
--- mathic-1.0~git20160320/debian/libmathic0v5.symbols	2016-03-26 01:03:32.0 -0700
+++ mathic-1.0~git20160320/debian/libmathic0v5.symbols	2016-07-11 12:00:18.0 -0700
@@ -67,7 +67,7 @@
  _ZN6mathic16IntegerParameterD0Ev@Base 1.0~git20130827
  _ZN6mathic16IntegerParameterD1Ev@Base 1.0~git20130827
  _ZN6mathic16IntegerParameterD2Ev@Base 1.0~git20130827
- (arch=!arm64 !hppa)_ZN6mathic16createWithPrefixINS_6ActionEEESt10unique_ptrIT_St14default_deleteIS3_EERKNS_11NameFactoryIS3_EERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0~git20160320
+ (optional|arch=!arm64 !hppa)_ZN6mathic16createWithPrefixINS_6ActionEEESt10unique_ptrIT_St14default_deleteIS3_EERKNS_11NameFactoryIS3_EERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0~git20160320
  _ZN6mathic16displayExceptionERKSt9exception@Base 1.0~git20130827
  _ZN6mathic19reportInternalErrorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0~git20160320
  _ZN6mathic19reportInternalErrorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKcj@Base 1.0~git20160320
@@ -102,6 +102,7 @@
  _ZNK6mathic10HelpAction5topicB5cxx11Ev@Base 1.0~git20160320
  _ZNK6mathic11BitTriangle12getMemoryUseEv@Base 1.0~git20130827
  _ZNK6mathic11NameFactoryINS_6ActionEE15namesWithPrefixERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt6vectorIS8_SaIS8_EE@Base 1.0~git20160320
+ (optional)_ZNK6mathic11NameFactoryIPvE15namesWithPrefixERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt6vectorIS8_SaIS8_EE@Base 1.0~git20160320
  _ZNK6mathic13BoolParameter12argumentTypeB5cxx11Ev@Base 1.0~git20160320
  _ZNK6mathic13BoolParameter13valueAsStringB5cxx11Ev@Base 1.0~git20160320
  _ZNK6mathic13ColumnPrinter14getColumnCountEv@Base 1.0~git20130827
@@ -136,9 +137,9 @@
  (arch-bits=32)_ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_iS4_NS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_T0_SG_T1_T2_@Base 1.0~git20130827
  (arch-bits=64)_ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_lS4_NS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_T0_SG_T1_T2_@Base 1.0~git20130827
  _ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorIS7_SaIS7_NS0_5__ops15_Iter_less_iterEEvT_SF_T0_@Base 1.0~git20160320
- _ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_NS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_SF_T0_@Base 1.0~git20130827
+ (optional)_ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_NS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_SF_T0_@Base 1.0~git20130827
  (arch-bits=32)_ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_iNS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_SF_T0_T1_@Base 1.0~git20130827
- (arch-bits=64)_ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_lNS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_SF_T0_T1_@Base 1.0~git20130827
+ (optional|arch-bits=64)_ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPPN6mathic12CliParameterESt6vectorIS4_SaIS4_lNS0_5__ops15_Iter_comp_iterIPFbS4_S4_vT_SF_T0_T1_@Base 1.0~git20130827
  (arch=any-amd64 any-i386 s390x)_ZSt25__unguarded_linear_insertIN9__gnu_cxx17__normal_iteratorIPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorIS7_SaIS7_NS0_5__ops14_Val_less_iterEEvT_T0_@Base 1.0~git20160320
  _ZSt9__find_ifIN9__gnu_cxx17__normal_iteratorIPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorIS7_SaIS7_NS0_5__ops16_Iter_equals_valIKS7_EEET_SH_SH_T0_St26random_access_iterator_tag@Base 1.0~git20160320
  (arch=any-amd64 any-i386 arm64 s390x)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEOS8_PKS5_@Base 1.0~git20160320
@@ -146,7 +147,7 @@
  

Bug#830810: bind9: CVE-2016-6170: Improper restriction of zone size limit

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.9.5.dfsg-9
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for bind9.

CVE-2016-6170[0]:
| ISC BIND through 9.10.4-P1 allows primary DNS servers to cause a
| denial of service (secondary DNS server crash) via a large AXFR
| response, and possibly allows IXFR servers to cause a denial of
| service (IXFR client crash) via a large IXFR response and allows
| remote authenticated users to cause a denial of service (primary DNS
| server crash) via a large UPDATE message.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6170
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1353563

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#830809: knot: CVE-2016-6171: Improper restriction of zone size limit

[Salvatore Bonaccorso]

Source: knot
Version: 2.2.1-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.labs.nic.cz/labs/knot/issues/464

Hi,

the following vulnerability was published for knot.

CVE-2016-6171[0]:
Improper restriction of zone size limit 

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6171
[1] https://gitlab.labs.nic.cz/labs/knot/issues/464

Please adjust the affected versions in the BTS as needed. This does
not warrant a DSA, it is marked already as no-dsa in the
security-tracker.

Regards,
Salvatore

Bug#825678: openclonk: Please add StrategyGame category to desktop file

[Petter Reinholdtsen]

[Philipp Kern]
> And it was merged upstream.

Thank you very much.  I had a look at testing today, and OpenClonk is
one of the few dependencies of games-strategy still missing in the
games->strategy submenu in KDE. :)  I look forward to seing one more
menu entry show up where it belong. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#830807: qwt: Prepare a jessie-backports upload

[Lisandro Damián Nicanor Pérez Meyer]

I can also prepare the fix for the current FTBFS.

On 11 July 2016 at 15:43, Lisandro Damián Nicanor Pérez Meyer
 wrote:
> Source: qwt
> Version: 6.1.2-5
> Severity: wishlist
>
> Hi Gudjon! Would you mind if I do a jessie-backport of qwt?
>
> Thanks in advance, Lisandro.
>
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)



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

Bug#820060: Re: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Daniel McDonald]

Hi Steve,

Thanks for following up. As I understand it, this is an issue with either
h5py or libhdf5. We have not modified the behavior of these libraries, and
are using them in a very basic manner; endianness is outside of our control
here. It is possible the issue is related to (
https://github.com/h5py/h5py/issues/428) which appears to still be open.

Best,
Daniel

On Mon, Jul 11, 2016 at 11:42 AM, Steve Langasek  wrote:

> Hi folks,
>
> Please keep me on Cc:, the Debian BTS does not automatically cc: bug
> submitters :)
>
> > Andreas, my read of the bug report suggests that the issue across
> > architectures is h5py or hdf5.  The access being made is to an attribute
> > of an h5py object which happens within python and is a valid API
> > operation; testing locally I'd expect a different KeyError to be thrown
> > under normal operation.
>
> > Looking closer at one of the failing tests (offending call linked below),
> > you can see that this is on read of a hdf5 table that ships with the
> > biom-format project.
>
> >
> https://github.com/biocore/biom-format/blob/master/tests/test_table.py#L527-528
>
> > The implication is that this is happening when reading a table that ships
> > as part of the test code, suggesting that h5py or hdf5 are unable to
> > interact with the file as expected.  My take is that the failure we're
> > observing is a manifestation of a bug at a lower level.
>
> So it sounds like your test data is written in a little-endian format, but
> hdf5 on big-endian architectures is trying to read it in a big-endian
> format.  Is it defined somewhere that hdf5 data should be in an
> architecture-independent format (always little-endian)?
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developerhttp://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption

[Eriberto]

Thanks Mike. I will add a notice here[1].

[1] https://wiki.debian.org/Software%20that%20can't%20be%20packaged

Regards,

Eriberto

2016-07-10 15:15 GMT-03:00 Mike Gabriel :
> Control: close -1
> Control: tags -1 wontfix
>
> Hi Eriberto,
>
> On  So 10 Jul 2016 00:05:12 CEST, Eriberto Mota wrote:
>
>> Hi,
>>
>> What is the current status of this package?
>>
>> Regards,
>>
>> Eriberto
>
>
> Unfortunately, the ftp master team rejected the upload due to the dodgy
> license history of Veracrypt / Truecrypt:
>
> On  Fr 08 Jul 2016 02:00:09 CEST, Thorsten Alteholz wrote:
>
>> Hi Mike,
>>
>> unfortunately I have to reject your package.
>> According to [1] "(...)TrueCrypt seems to be reserving the right to sue
>> any licensee for copyright infringement, no matter whether they comply
>> with the conditions of the license or not. Based on this, our counsel
>> advised that above and beyond being non-free, software under this
>> license is not safe to use. (...)"
>>
>> So as Veracrypt is basically licensed with the TrueCrypt license, I think
>> it is better for Debian to not distribute such software, even in non-free.
>>
>>  Thorsten
>
>
> Thus closing this ITP and tagging as "won't fix". Unfortunately...
>
> Mike
>
>
> [1]
> https://lists.freedesktop.org/archives/distributions/2008-October/000276.html
>
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, herweg 7, 24357 fleckeby
> mobile: +49 (1520) 1976 148
> landline: +49 (4354) 8390 139
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>

Bug#830806: [Pkg-dns-devel] Bug#830806: nsd: CVE-2016-6173: Improper restriction of zone size limit

[Salvatore Bonaccorso]

Hi Ondrej,

On Mon, Jul 11, 2016 at 08:36:07PM +0200, Ondřej Surý wrote:
> Hi Salvatore,
> 
> the common agreement between DNS Vendors (that includes me) is that this
> shouldn't have been assigned CVE as it is an operational issue as you
> have an established trust between DNS master-slave for transfers. (And
> all DNS servers are affected.)
> 
> I don't think this really needs update in stable, but I would like to
> hear whether you think otherwise.

No I completely agree, we actually have marked all those already as
no-dsa (for src:nsd, src:pdns, src:bind9 and src:knot). But filling
those as well in BTS to have the reference in BTS.

Thanks for your quick response, amazing :-)

Salvatore

Bug#830808: pdns: CVE-2016-6172: Improper restriction of zone size limit

[Salvatore Bonaccorso]

Source: pdns
Version: 4.0.0~beta1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/PowerDNS/pdns/issues/4128

Hi,

the following vulnerability was published for pdns.

CVE-2016-6172[0]:
Improper restriction of zone size limit

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6172
[1] https://github.com/PowerDNS/pdns/issues/4128

Please adjust the affected versions in the BTS as needed.

As mentioned at DebConf, this is a minor issue which does not warrant
a DSA. But it will be nice if you can fix this via a Jessie point
release. Thanks a lot for your work on pdns!

Regards,
Salvatore

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

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

Bug#820060: Re: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Steve Langasek]

Hi folks,

Please keep me on Cc:, the Debian BTS does not automatically cc: bug
submitters :)

> Andreas, my read of the bug report suggests that the issue across
> architectures is h5py or hdf5.  The access being made is to an attribute
> of an h5py object which happens within python and is a valid API
> operation; testing locally I'd expect a different KeyError to be thrown
> under normal operation.

> Looking closer at one of the failing tests (offending call linked below),
> you can see that this is on read of a hdf5 table that ships with the
> biom-format project.

> https://github.com/biocore/biom-format/blob/master/tests/test_table.py#L527-528

> The implication is that this is happening when reading a table that ships
> as part of the test code, suggesting that h5py or hdf5 are unable to
> interact with the file as expected.  My take is that the failure we're
> observing is a manifestation of a bug at a lower level.

So it sounds like your test data is written in a little-endian format, but
hdf5 on big-endian architectures is trying to read it in a big-endian
format.  Is it defined somewhere that hdf5 data should be in an
architecture-independent format (always little-endian)?

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


signature.asc
Description: PGP signature

Bug#830807: qwt: Prepare a jessie-backports upload

[Lisandro Damián Nicanor Pérez Meyer]

Source: qwt
Version: 6.1.2-5
Severity: wishlist

Hi Gudjon! Would you mind if I do a jessie-backport of qwt?

Thanks in advance, Lisandro.

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

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

Bug#830806: [Pkg-dns-devel] Bug#830806: nsd: CVE-2016-6173: Improper restriction of zone size limit

[Ondřej Surý]

Hi Salvatore,

the common agreement between DNS Vendors (that includes me) is that this
shouldn't have been assigned CVE as it is an operational issue as you
have an established trust between DNS master-slave for transfers. (And
all DNS servers are affected.)

I don't think this really needs update in stable, but I would like to
hear whether you think otherwise.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Mon, Jul 11, 2016, at 20:30, Salvatore Bonaccorso wrote:
> Source: nsd
> Version: 4.1.10-1
> Severity: important
> Tags: security upstream patch
> Forwarded: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=790
> 
> Hi,
> 
> the following vulnerability was published for nsd.
> 
> CVE-2016-6173[0]:
> Improper restriction of zone size limit
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-6173
> [1] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=790
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.6.0-1-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)
> 
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#830806: nsd: CVE-2016-6173: Improper restriction of zone size limit

[Salvatore Bonaccorso]

Source: nsd
Version: 4.1.10-1
Severity: important
Tags: security upstream patch
Forwarded: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=790

Hi,

the following vulnerability was published for nsd.

CVE-2016-6173[0]:
Improper restriction of zone size limit

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6173
[1] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=790

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#830805: jessie-pu: package cacti/0.8.8b+dfsg-8+deb8u4

[Paul Gevers]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There are currently three CVE's open against the cacti package in jessie that
have a patch available¹. Non of the issues are severe enough to warrent a
security upload, but I still think it is a good idea to get this fixed in
jessie. Could you please consider the attached debdiff?

Paul

¹ The forth open CVE against cacti is open since 2009 and not likely to get 
fixed.

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEbBAEBCAAGBQJXg+VnAAoJEJxcmesFvXUK1cYH91B+Lolr1dE2yVXXeUWvGdlD
CDUl2sRWspaIcYkeFxFQv7FXlPnyTf8q6CXKUK6ALY/tV5GLWwTAHFuSF5rMEo5x
Dmiqm2yzZ5FIFcr7R6qfjaFK2nnKEix4HOxMK7wnVJq08n0UuHA6D5uRnRKmyJ/x
3Ves4ZNTMtlYOZZIMyyahODkqJFuKbFvnYzt4SnY/dQpwPnyxi1jkH9PjLHHyA8H
4Cxs1+rT58Zn4ZvskB2/JKzo0zAGwI7XA8PI6eacBoj7Gi42fJuAUUhWx/Qh3QwM
8DSpUZlNdJRWAfIS+MWn6S5zl41+GsYSIMBLVHalRBFSNeSH5XHQRmxMjVsHKQ==
=qmJ/
-END PGP SIGNATURE-
diff -Nru cacti-0.8.8b+dfsg/debian/changelog cacti-0.8.8b+dfsg/debian/changelog
--- cacti-0.8.8b+dfsg/debian/changelog	2016-02-24 20:47:55.0 +0100
+++ cacti-0.8.8b+dfsg/debian/changelog	2016-07-09 20:26:32.0 +0200
@@ -1,3 +1,15 @@
+cacti (0.8.8b+dfsg-8+deb8u5) jessie-proposed-updates; urgency=medium
+
+  [ Emilio Pozuelo Monfort ]
+  * debian/patches/CVE-2016-3172-sql-injection.patch:
++ CVE-2016-3172: Fix sql injection in tree.php (Closes: #818647)
+  * debian/patches/CVE-2016-3659-sql-injection.patch:
++ CVE-2016-3659: Fix sql injection in graph_view.php (Closes: #820521)
+  * debian/patches/CVE-2016-2313-authentication-bypass.patch:
++ CVE-2016-2313: Fix authentication bypass (Closes: #814353)
+
+ -- Paul Gevers   Sat, 09 Jul 2016 20:05:41 +0200
+
 cacti (0.8.8b+dfsg-8+deb8u4) jessie-security; urgency=high
 
   * CVE-2015-8377: Fix SQL Injection vulnerability in graphs_new.php
diff -Nru cacti-0.8.8b+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch cacti-0.8.8b+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch
--- cacti-0.8.8b+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch	1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8b+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch	2016-07-09 20:04:07.0 +0200
@@ -0,0 +1,23 @@
+Backport fix for CVE-2016-2313.
+
+This is http://svn.cacti.net/viewvc?view=rev=7770
+and https://github.com/Cacti/cacti/commit/6e5f3be49b3f52e30c88ec75a576f89bb72c4e52
+
+Bug: http://bugs.cacti.net/view.php?id=2656
+
+--- a/auth_login.php
 b/auth_login.php
+@@ -86,6 +86,13 @@
+ 		/* Locate user in database */
+ 		$user = db_fetch_row("SELECT * FROM user_auth WHERE username = " . $cnn_id->qstr($username) . " AND realm = 2");
+ 
++		if (!$user && read_config_option('user_template') == '0') {
++			cacti_log("ERROR: User '" . $username . "' authenticated by Web Server, but a Template User is not defined in Cacti.  Exiting.", false, 'AUTH');
++			$username = htmlspecialchars($username);
++			auth_display_custom_error_message("$username authenticated by Web Server, but a Template User is not defined in Cacti.");
++			exit;			
++		}
++
+ 		break;
+ 	case "3":
+ 		/* LDAP Auth */
diff -Nru cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
--- cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch	1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch	2016-07-09 20:04:07.0 +0200
@@ -0,0 +1,10 @@
+--- a/tree.php	2016/05/08 15:10:45	7804
 a/tree.php	2016/05/08 15:35:30	7805
+@@ -153,6 +153,7 @@
+ 	/* = input validation = */
+ 	input_validate_input_number(get_request_var("id"));
+ 	input_validate_input_number(get_request_var("tree_id"));
++	input_validate_input_number(get_request_var("parent_id"));
+ 	/*  */
+ 
+ 	if (!empty($_GET["id"])) {
diff -Nru cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch
--- cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch	1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8b+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch	2016-07-09 20:04:07.0 +0200
@@ -0,0 +1,13 @@
+--- a/lib/functions.php	2016/03/06 23:29:28	7800
 a/lib/functions.php	2016/05/08 14:41:02	7801
+@@ -2138,8 +2138,8 @@
+@arg $string - the original raw search 

Bug#829654: Overwrite Debian fcgiwrap git repository

[Jérémy Lal]

2016-07-11 20:10 GMT+02:00 Peter Colberg :

> Hi Jérémy,
>
> I am co-maintaining fcgiwrap together with its current maintainer
> Jordi (CC'd) and for this purpose converted the svn history to git.
> Now that I am about to upload the git repository to collab-maint, I
> found an existing fcgiwrap.git with commits by you from May 29, 2013.
>
> Would you be fine if we overwrite
>
> https://anonscm.debian.org/cgit/collab-maint/fcgiwrap.git
>
> with the contents of
>
> https://anonscm.debian.org/cgit/users/pc-guest/fcgiwrap.git
>
> The latter contains the full history of the package. I have verified
> that all of your debian/ changes had been integrated in similar form
> into the fcgiwrap package back then.
>

OK

Jérémy

Bug#812034: klick: FTBFS with GCC 6: needed for in-class initialization

[James Cowgill]

On Mon, 2016-07-11 at 20:01 +0200, Jaromír Mikeš wrote:
> 2016-01-20 5:41 GMT+01:00 Martin Michlmayr :
> > Package: klick
> > Version: 0.12.2-2
> > Severity: important
> > User: debian-...@lists.debian.org
> > Usertags: ftbfs-gcc-6
> > 
> > This package fails to build with GCC 6.  GCC 6 has not been
> > released
> > yet, but it's expected that GCC 6 will become the default compiler
> > for
> > stretch.
> > 
> > Note that only the first error is reported; there might be
> > more.  You
> > can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> > you can set CC=gcc-6 CXX=g++-6 explicitly.
>
> I'm trying fix this issue
> I added gcc-6 and g++-6 as build-deps and these lines to d/rules:
> export CC = gcc-6
> export CXX = g++-6
> 
> Not sure if I still missing something but package build fine this
> way...

scons seems to ignore the CC and CXX environment variables completely.
If I build klick with gcc/g++ from experimental I can reproduce the
FTBFS.

James

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

Bug#829654: Overwrite Debian fcgiwrap git repository

[Peter Colberg]

Hi Jérémy,

I am co-maintaining fcgiwrap together with its current maintainer
Jordi (CC'd) and for this purpose converted the svn history to git.
Now that I am about to upload the git repository to collab-maint, I
found an existing fcgiwrap.git with commits by you from May 29, 2013.

Would you be fine if we overwrite

https://anonscm.debian.org/cgit/collab-maint/fcgiwrap.git

with the contents of

https://anonscm.debian.org/cgit/users/pc-guest/fcgiwrap.git

The latter contains the full history of the package. I have verified
that all of your debian/ changes had been integrated in similar form
into the fcgiwrap package back then.

Regards,
Peter


signature.asc
Description: PGP signature

Bug#812034: klick: FTBFS with GCC 6: needed for in-class initialization

[Jaromír Mikeš]

2016-01-20 5:41 GMT+01:00 Martin Michlmayr :
> Package: klick
> Version: 0.12.2-2
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6
>
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
>
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.

Hi,

I'm trying fix this issue
I added gcc-6 and g++-6 as build-deps and these lines to d/rules:
export CC = gcc-6
export CXX = g++-6

Not sure if I still missing something but package build fine this way...

best regards

mira

Bug#830803: debian.org: Add python-popcon as a new dependency in pet.debian.net

[Lucas Kanashiro]

Package: debian.org
Severity: important
Tags: patch

Dear Maintainer,

We are improving the PET (Package Entropy Tracker) in pet.debian.net and now
we have python-popcon as a new dependency. I forgot this new dependency and
try to deploy in petrovas.d.o, and now the service is not running. I'll
appreciate if you can fix it ASAP.

Thanks!
Cheers.

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

Kernel: Linux 4.6.0-1-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)
>From 2ffbce6b8d4ca3ff0f387c3669517f1c4a8d15c8 Mon Sep 17 00:00:00 2001
From: Lucas Kanashiro 
Date: Mon, 11 Jul 2016 14:50:48 -0300
Subject: [PATCH] Add python-popcon as a new dependency on pet.debian.net

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index a709f92..2dfccc4 100644
--- a/debian/control
+++ b/debian/control
@@ -1047,6 +1047,7 @@ Depends: python-apt,
 	python-paste,
 	python-psycopg2,
 	python-pyramid,
+	python-popcon,
 	python-sqlalchemy,
 	python-subversion
 Description: metapackages for pet.debian.net dependencies
-- 
2.8.1

Bug#830804: atop: trap dived error in kernelo logs

[Francesco Potortì]

Package: atop
Version: 1.26-2+b1
Severity: normal

I have atop running in daemon mode and I often see this in the kernel
logs:

[4002813.353226] traps: atop[12867] trap divide error ip:4073c2 sp:7ffc772dcf10 
error:0 in atop[40+26000]

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

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

Versions of packages atop depends on:
ii  libc62.22-13
ii  libncurses5  6.0+20160319-2+b1
ii  libtinfo56.0+20160319-2+b1
ii  lsb-base 9.20160629
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages atop recommends:
ii  cron  3.0pl1-128

atop suggests no packages.

-- no debconf information

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Jakub Wilk]

* Gianfranco Costamagna , 2016-07-11, 17:13:

are you sure it is 6500K?

6500K should be equal to "650"


K == Kelvin, not kilo.

--
Jakub Wilk

Bug#827391: nvidia-driver: Add support to Nvidia GeForce 10xx GPUs w/ driver 367.27

[hikaru . debian]

It turned out, I had extra characters in my debian/rules file, most likely due
to a mistake while copying the patch from the wiki. This crippled my tar
command, but didn't make it completely useless.
So much for "following instructions". ;-)
Thanks for your patience!

In the end I manually installed these packages:

libegl1-nvidia_367.27-1_amd64.deb
libegl-nvidia0_367.27-1_amd64.deb
libgl1-nvidia-glx_367.27-1_amd64.deb
libgles1-glvnd-nvidia_367.27-1_amd64.deb
libgles2-glvnd-nvidia_367.27-1_amd64.deb
libglvnd-nvidia_367.27-1_amd64.deb
libglx0-nvidia_367.27-1_amd64.deb
libglx-nvidia0_367.27-1_amd64.deb
libnvidia-eglcore_367.27-1_amd64.deb
libnvidia-ml1_367.27-1_amd64.deb
nvidia-alternative_367.27-1_amd64.deb
nvidia-driver_367.27-1_amd64.deb
nvidia-driver-bin_367.27-1_amd64.deb
nvidia-kernel-dkms_367.27-1_amd64.deb
nvidia-kernel-support_367.27-1_amd64.deb
nvidia-vdpau-driver_367.27-1_amd64.deb
xserver-xorg-video-nvidia_367.27-1_amd64.deb


I also needed these packages from jessie-backports:

glx-alternative-nvidia
libvdpau1
nvidia-kernel-common
nvidia-modprobe


It wasn't necessary, but I thought it wouldn't hurt, to install
nvidia-installer-cleanup from the backports too.

Now I have this list of packages installed:

# dpkg -l | grep nvidia
ii  glx-alternative-nvidia0.7.3~bpo8+1 
amd64allows the selection of NVIDIA as GLX provider
ii  libegl-nvidia0:amd64  367.27-1 
amd64NVIDIA binary EGL libraries
ii  libegl1-nvidia:amd64  367.27-1 
amd64NVIDIA binary EGL stub libraries
ii  libgl1-nvidia-glx:amd64   367.27-1 
amd64NVIDIA binary OpenGL libraries
ii  libgles1-glvnd-nvidia:amd64   367.27-1 
amd64NVIDIA binary OpenGL|ES 1.x stub libraries
ic  libgles1-nvidia:amd64 340.96-1 
amd64NVIDIA binary OpenGL|ES 1.x libraries
ii  libgles2-glvnd-nvidia:amd64   367.27-1 
amd64NVIDIA binary OpenGL|ES 2.x stub libraries
ic  libgles2-nvidia:amd64 340.96-1 
amd64NVIDIA binary OpenGL|ES 2.x libraries
ii  libglvnd-nvidia:amd64 367.27-1 
amd64NVIDIA binary GL vendor neutral libraries
ii  libglx-nvidia0:amd64  367.27-1 
amd64NVIDIA binary GLX libraries
ii  libglx0-nvidia:amd64  367.27-1 
amd64Vendor neutral GL dispatch library -- libGLX
ii  libnvidia-eglcore:amd64   367.27-1 
amd64NVIDIA binary EGL core libraries
ii  libnvidia-ml1:amd64   367.27-1 
amd64NVIDIA Management Library (NVML) runtime library
ii  nvidia-alternative367.27-1 
amd64allows the selection of NVIDIA as GLX provider
ii  nvidia-driver 367.27-1 
amd64NVIDIA metapackage
ii  nvidia-driver-bin 367.27-1 
amd64NVIDIA driver support binaries
ii  nvidia-installer-cleanup  20151021+1~bpo8+1
amd64cleanup after driver installation with the nvidia-installer
ii  nvidia-kernel-common  20151021+1~bpo8+1
amd64NVIDIA binary kernel module support files
ii  nvidia-kernel-dkms367.27-1 
amd64NVIDIA binary kernel module DKMS source
ii  nvidia-kernel-support 367.27-1 
amd64NVIDIA binary kernel module support files
ii  nvidia-legacy-check   367.27-1 
amd64check for NVIDIA GPUs requiring a legacy driver
ii  nvidia-modprobe   358.09-1~bpo8+1  
amd64utility to load NVIDIA kernel modules and create device nodes
rc  nvidia-settings   340.46-2 
amd64tool for configuring the NVIDIA graphics driver
ii  nvidia-support20151021+1~bpo8+1
amd64NVIDIA binary graphics driver support files
ii  nvidia-vdpau-driver:amd64 367.27-1 
amd64Video Decode and Presentation API for Unix - NVIDIA driver
ii  xserver-xorg-video-nvidia 367.27-1 
amd64NVIDIA binary Xorg driver


I'm wondering about two things:

1. I still have libgles1-nvidia and libgles2-nvidia from 340 on my system,
while there are only libgles1-glvnd-nvidia and libgles2-glvnd-nvidia for 367.
Are the latter two packages equivalent to the former ones or should 

Bug#818820: ldc: FTBFS with libc 2.23: '::isnan' has not been declared

[Matthias Klumpp]

Control: fixed ! 1:1.1.0-1

This bug is resolved with the latest upload of LDC.

Cheers,
Matthias

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

Bug#830802: util-linux: CVE-2016-5011: Extended partition loop in MBR partition table leads to DOS

[Salvatore Bonaccorso]

Source: util-linux
Version: 2.28-5
Severity: important
Tags: security upstream patch fixed-upstream

Hi,

the following vulnerability was published for util-linux.

CVE-2016-5011[0]:
Extended partition loop in MBR partition  table leads to DoS

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-5011

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore