Bug#812343: user-error: Info file bbdb does not exist

[積丹尼 Dan Jacobson]

Package: bbdb3
Version: 3.1.2-5

h runs the command bbdb-info, which is an interactive compiled Lisp
function in `bbdb-com.el'.

It is bound to h,.

(bbdb-info)

Not documented.

user-error: Info file bbdb does not exist

Bug#812166: [PATCH] x86/mce: fix misleading indentation in init_nonfatal_mce_checker().

[Egger, Christoph]

On 22/01/16 15:47, Andrew Cooper wrote:
> On 22/01/16 14:38, Ian Campbell wrote:
>> Debian bug 812166[0] reported this build failure due to
>> Wmisleading-indentation with gcc-6:
>>
>> non-fatal.c: In function 'init_nonfatal_mce_checker':
>> non-fatal.c:103:2: error: statement is indented as if it were guarded by... 
>> [-Werror=misleading-indentation]
>>   switch (c->x86_vendor) {
>>   ^~
>>
>> non-fatal.c:97:5: note: ...this 'if' clause, but it is not
>>  if ( __get_cpu_var(poll_bankmask) == NULL )
>>  ^~
>>
>> I was unable to reproduce (xen builds cleanly for me with "6.0.0 20160117
>> (experimental) [trunk revision 232481]") but looking at the code the issue
>> above is clearly real.
>>
>> Correctly reindent the if statement.
>>
>> This file uses Linux coding style (infact the use of Xen style for
>> this line is the root cause of the wanring) so use tabs and while
>> there remove the whitespace inside the if as Linux does.
>>
>> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166
>>
>> Signed-off-by: Ian Campbell 
>> Cc: Christoph Egger 
>> Cc: Liu Jinsong 
> 
> Reviewed-by: Andrew Cooper 
> 

Acked-by: Christoph Egger 

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Bug#784448: Bumping severity to normal

[Lisandro Damián Nicanor Pérez Meyer]

severity 784449 normal
severity 784448 normal
severity 784612 normal
severity 784450 normal
severity 784451 normal
severity 784452 normal
severity 784453 normal
severity 784454 normal
severity 784456 normal
severity 784455 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.

-- 
Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we would all be jumping in dark rooms, chomping magic pills
and listening to electronic repeating music.
  Kristian Wilson, Nintendo Inc. 1989

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#812345: gitlab: Fails to install: "Could not find gem 'mysql2 (~> 0.3.16) ruby' in any of the gem sources listed in your Gemfile or available on this machine."

[Axel Beckert]

Package: gitlab
Version: 8.4.0+dfsg~rc2-1
Severity: serious
Justification: Fails to install

Hi,

installing gitlab on a mostly testing installation fails for me as
follows:

[...]
Setting up gitlab (8.4.0+dfsg~rc2-1) ...
Creating/updating gitlab user account...
adduser: Warning: The home directory `/usr/share/gitlab' does not belong to the 
user you are currently creating.
adduser: The user `gitlab' already exists.
Create database if not present
psql: FATAL:  database "gitlab_production" does not exist
psql: FATAL:  role "gitlab" does not exist
Create gitlab user with create database privillege...
CREATE ROLE
Make gitlab user owner of gitlab_production database...
ALTER DATABASE
Grant all privileges to gitlab user...
GRANT
Setting up environment varibales...
Verifying we have all required libraries...
Could not find gem 'mysql2 (~> 0.3.16) ruby' 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
Processing triggers for libc-bin (2.21-6) ...
Errors were encountered while processing:
 gitlab
[...]
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up gitlab (8.4.0+dfsg~rc2-1) ...
Creating/updating gitlab user account...
adduser: The user `gitlab' already exists.
Proceeding with existing gitlab user...
adduser: The user `gitlab' already exists.
Create database if not present
Make gitlab user owner of gitlab_production database...
ALTER DATABASE
Grant all privileges to gitlab user...
GRANT
Setting up environment varibales...
Verifying we have all required libraries...
Could not find gem 'mysql2 (~> 0.3.16) ruby' 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
find: Failed to restore initial working directory: /root: Permission denied
Errors were encountered while processing:
 gitlab

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (210, 'experimental'), (110, 
'buildd-unstable'), (105, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-trunk-amd64 (SMP w/1 CPU core)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  debconf [debconf-2.0]  1.5.58
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.5.0-1
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-1
ii  nodejs 4.2.4~dfsg-2
ii  postgresql 9.5+172
ii  postgresql-client  9.5+172
ii  postgresql-client-9.5 [postgresql-client]  9.5.0-2
ii  redis-server   2:3.0.6-1
ii  ruby   1:2.2.4
ii  ruby-ace-rails-ap  3.0.3-2
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store0.1.1-2
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-babosa1.0.2-1
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   1.0.1-1
ii  ruby-cal-heatmap-rails 3.5.1+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-1
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-colored   1.2-2
ii  ruby-colorize  0.7.7-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise3.5.2-3
ii  ruby-devise-async  0.9.0-1
ii  ruby-devise-two-factor 2.0.0-1
ii  ruby-diffy 3.0.6-1
ii  ruby-doorkeeper   

Bug#812344: simple-scan: segfault using Canon Lite 100 with simple-scan

[PICCORO McKAY Lenz]

Package: simple-scan
Version: 3.14.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

scaning with simple-scan got a message like "cannot retrieve image" or
"no valid scanner"
and then the program got to choose the scanner

in second try the program never start to scan and exit, in console
this its the dmesg output:

NOTE: in venenux or squeeze i recompile the sane and never got this
problem, only in wheeze and jeesie!

NOTE2: xsane works perfectly in wheeze and jeesie an dnever git this problem!

NOTE3: theres a reset of the port in "589572.965269" that maybe could
be a port usb problem: NO! xsane works well! and in same machine
venenux works well!

root@massenkoh:/home/debianuser# dmesg | tail
[589417.623987] usb 2-1-port6: unable to enumerate USB device
[589520.343242] usb 1-1.6: new high-speed USB device number 5 using ehci-pci
[589520.437469] usb 1-1.6: New USB device found, idVendor=04a9, idProduct=1904
[589520.437474] usb 1-1.6: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[589520.437477] usb 1-1.6: Product: CanoScan
[589520.437479] usb 1-1.6: Manufacturer: Canon
[589559.939391] scan-thread[19811]: segfault at 0 ip b1d7d97c sp
b414ff50 error 4 in libsane-genesys.so.1.0.24[b1d31000+7e000]
[589572.965269] usb 1-1.6: reset high-speed USB device number 5 using ehci-pci
[589577.928318] scan-thread[19859]: segfault at 0 ip b1ceb97c sp
b40eff50 error 4 in libsane-genesys.so.1.0.24[b1c9f000+7e000]
root@massenkoh:/home/debianuser#

libsane-extras are installed and no third party firmware are need for
Cannon lite 100 in any
of my debian either jeesie or squeeze or venenux!

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages simple-scan depends on:
ii  adwaita-icon-theme   3.14.0-2
ii  dbus-x11 1.8.20-0+deb8u1
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gconf-gsettings-backend [gsettings-backend]  3.2.6-3
ii  gnome-icon-theme-symbolic3.12.0-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u1
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libcolord2   1.2.1-1+b2
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u3
ii  libglib2.0-0 2.42.1-1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libgudev-1.0-0   215-17+deb8u2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libsane  1.0.24-8
ii  xdg-utils1.1.0~rc1+git20111210-7.4
ii  zlib1g   1:1.2.8.dfsg-2+b1

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information

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

Bug#784457: Bumping severity

[Lisandro Damián Nicanor Pérez Meyer]

severity 784457 normal
severity 784458 normal
severity 784459 normal
severity 784616 normal
severity 784460 normal
severity 784461 normal
severity 784462 normal
severity 784463 normal
severity 784464 normal
severity 784610 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.


-- 
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

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#812224: IndexError: list index out of range

[Jens Kubieziel]

* Axel Beckert schrieb am 2016-01-22 um 13:23 Uhr:
> The connection you've chosen, is that a wireless or a wired one? I
> suspect a wireless one.

Your suspicion is right. It's wireless.

-- 
Jens Kubieziel   http://www.kubieziel.de
My advice (which I'm quite sure someone else has given here previously):
Use the OS you're most comfortable with. All of them can be adequately
secured, and the administrator is in just about all cases the point of
vulnerability.  Charles Duffy

Bug#784470: Bumping severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 784468 normal
severity 784470 normal
severity 784471 normal
severity 784472 normal
severity 784473 normal
severity 784475 normal
severity 784476 normal
severity 784477 normal
severity 784479 normal
severity 784480 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.

-- 
Alas, I am dying beyond my means.
  Oscar Wilde, as he sipped champagne on his deathbed

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#784481: Bumping severity

[Lisandro Damián Nicanor Pérez Meyer]

severity 784481 normal
severity 784483 normal
severity 784485 normal
severity 784484 normal
severity 784486 normal
severity 784487 normal
severity 784490 normal
severity 784491 normal
severity 784493 normal
severity 784496 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.

-- 
For want of a nail, the shoe was lost;
For want of the shoe, the horse was lost;
For want of the horse, the rider was lost;
For want of the rider, the battle was lost;
For want of the battle, the kingdom was lost;
And all for the want of a horseshoe nail
  http://www.everything2.com/index.pl?node_id=1097943

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#740194: closed by Andreas Beckmann <a...@debian.org> (Re: ngspice: request to update to recent upstream release 26)

[Thomas Uhle]

Andreas, you are right that version 26 was released in July 2014, but 
AFAICS without compiling it with FFTW3 support which I also asked for.


Best regards,

Thomas Uhle

Bug#784498: Bumping severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 784498 normal
severity 784615 normal
severity 784501 normal
severity 784614 normal
severity 784502 normal
severity 784503 normal
severity 784505 normal
severity 784507 normal
severity 784508 normal
severity 784509 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.

-- 
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#812328: [Debian-med-packaging] Bug#812328: bcftools: fails to upgrade from 'jessie' - trying to overwrite /usr/share/man/man1/bcftools.1.gz

[Afif Elghraoui]

Hello,

على الجمعـة 22 كانون الثاني 2016 ‫04:12، كتب Andreas Beckmann:
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 

Thanks for reporting this. I had forgotten that bcftools used to be part
of samtools in older versions, so this breaks/replaces relation is in order.

regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#784510: Bumping severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 784510 normal
severity 784511 normal
severity 784512 normal
severity 784516 normal
severity 784518 normal
severity 784527 normal
severity 784529 normal
severity 784531 normal
severity 784559 normal
severity 784560 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.

-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

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#784513: Bumping severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 784619 normal
severity 784513 normal
severity 784514 normal
severity 784522 normal
severity 784523 normal
severity 784524 normal
severity 784525 normal
severity 784613 normal
severity 784532 normal
severity 784618 normal
thanks

Hi! As we intend to go further with this removal we are bumping it's severity.
If you need help please do not hesitate in replying to the bug, I am 
subscribed to it.

-- 
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem
and you will not get to space today.
  http://xkcd.com/1133/

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#809923: New package proposal: nordlicht

[Peter Spiess-Knafl]

Hi Sebastian!

Thank you very much for your review. Those were really some major flaws.

On 01/19/2016 12:54 PM, Sebastian Ramacher wrote:
> A new upstream version is available.

I managed to get most of this fixed upstream. I am just waiting for
another release, so that we don't need to have unnecessary patches.


> Why is linbpng-dev in Build-Depends? It doesn't seem to be used.

Removed it. Its not required you are right.

> Is there a reason libnordlicht0 and libnordlicht-dev are not
> multi-archified?

I provided some patches to upstream and will multi-archify the package
as soon as the new release is out.

https://github.com/cinemast/nordlicht/commit/4440b64eff581da855140867f6e9a8b0a599eaf0

> The library exports plenty of symbols that are not listed in
> nordlicht.h. Please hide those symbols (for example using
> __attribute__(visibility("hidden"))) and ideally get this fixed
> upstream.
> 

Fixed upstream:
https://github.com/nordlicht/nordlicht/commit/cc86cd362844700fced80ebcf443bb8f8a82c961

> nordlicht is overlinked:
> 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libavcodec-ffmpeg.so.56 (it uses none of the library's symbols) 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libavformat-ffmpeg.so.56 (it use s none of the library's symbols) 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libavutil-ffmpeg.so.54 (it uses none of the library's symbols) 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libswscale-ffmpeg.so.3 (it uses none of the library's symbols)
> 
> libnordlicht.so.0 is underlinked. Please link it against libm:
> 
> dpkg-shlibdeps: warning: symbol log10 used by
> debian/libnordlicht0/usr/lib/libnordlicht.so.0 found in none of the
> libraries

Fixed upstream:
https://github.com/nordlicht/nordlicht/commit/f69acc20599b8bf3edb8dd2986c1026b27af28a9


I will commit the missing changes about multi-arch support and a new
symbols file as soon as the new release is out.

Could you please than give it another chance?

Thank you and Greetings
Peter

Bug#812367: ITP: swift-bench -- benchmarking tool for Swift

[Ondřej Nový]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Nový" 

* Package name: swift-bench
  Version : 1.0
* URL : https://github.com/openstack/swift-bench
* License : Apache-2
  Programming Lang: Python
  Description : benchmarking tool for Swift

Swift Bench is simple tool for benchmarking OpenStack Swift cluster

As part of the pkg-openstack team, I am planning to package it.

Bug#811430: libjsoncpp-dev: Install jsoncppConfig.cmake to dev package.

[Ghislain Vaillant]

There is no need for one if the "jsoncppConfig.cmake" file is installed 
in the appropriate CMake package directory. See the CMake reference [1] 
for "config" mode.


[1] https://cmake.org/cmake/help/v3.0/command/find_package.html

Judging by the content of the root CMakeLists.txt, you will have to 
enable the JSONCPP_WITH_CMAKE_PACKAGE option for it to be generated and 
installed:


IF(JSONCPP_WITH_CMAKE_PACKAGE)
INSTALL(EXPORT jsoncpp
DESTINATION ${PACKAGE_INSTALL_DIR}/jsoncpp
FILEjsoncppConfig.cmake)
ENDIF()

Hope this helps.

Ghis


On 22/01/16 20:15, Peter Spiess-Knafl wrote:

Hi Ghis!

I just looked at the upstream source (current and newest one). I
couldn't find any FindModule for JsonCpp. Do you have a reference to it?

On 01/19/2016 10:51 AM, Ghislain Vaillant wrote:

Hi Peter, thanks for acknowledging the bug.

Feel free to have a look here for a working example:


https://anonscm.debian.org/cgit/debian-science/packages/clblas.git/tree/debian


I have also provided an autopkgtest for building the examples to
verify that the find modules was installed appropriately. You may
also want to check clfft, arrayfire... or any other cmake based
package that I personally maintain if you don't trust my advice.

FYI, I believe the pkgconfig file should also end-up in a multi-arch
path (usr/lib//pkgconfig) since it depends on a
multi-arch enabled variable (libdir). I am happy to file a different
bug for it if you want.


This is a different bug yes. Thank your for recognizing it.

Greetings
Peter

Bug#812370: RM: qmf -- ROM; unmaintained, no rdeps

[Felix Geyer]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove qmf from unstable.
There is no one looking after the package in Debian and it has no rdeps in the 
archive.

Upstream is still active [1] but we shouldn't carry around the old version.

Thanks,
Felix

[1] https://code.qt.io/cgit/qt-labs/messagingframework.git/

Bug#811572:

[Antonin Kral]

Hi David,

thanks a lot for the followup. I've forwarded info to upstream.

https://github.com/troglobit/libite/issues/2

Best,

Antonin

* David Malcolm  [2016-01-22 15:40] wrote:
> (I'm the upstream gcc author of -Wmisleading-indentation)
> 
> Looking at,
>   https://github.com/troglobit/libite/blob/master/lite.h#L134
> the code in question seems to be:
> 
> static inline int fisslashdir(char *dir)
> {
>if (!dir) return 0;
>if (strlen (dir) > 0) return dir[strlen (dir) - 1] == '/';
>  return 0;
> }
> 

Bug#811802: povray: FTBFS with GCC 6: multiple errors

[Martin Michlmayr]

* Andreas Beckmann  [2016-01-21 03:06]:
> I haven't looked into this, yet, but the most prominent change seems to
> be the default switch to -std=c++14. Have you tried rebuilding the
> failing packages with g++-6 -std=c++11/c++03/c++98/.../gnuXX (not sure
> whether the old ones are correctly spelled) to see if that succeeds
> somewhere? If additionally information is given like "But it builds
> successfully with g++6 -std=c++11" or "And it also fails with g++-6
> -std=c++AA/BB/CC/gnuXX/YY/ZZ" that should narrow the place where to
> start looking for this problem.

Sorry, I haven't done that.  I filed over 500 bugs so I cannot look at
every package in detail.  I could do it for yours but it sounds like
you have a pbuilder with g++-6 ready already (or ready soon) :)

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#442363: ITP: php-db-dataobject -- SQL Builder, Object Interface to Database Tables

[Bhuvan Krishna]

owner #442363 !
tag moreinfo



signature.asc
Description: OpenPGP digital signature

Bug#812372: ITP: vagrant-cachier -- share a common package cache among similar VM instances

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 

* Package name: vagrant-cachier
  Version : 1.2.1
  Upstream Author : Fabio Rehm
* URL : https://github.com/fgrehm/vagrant-cachier
* License : MIT
  Programming Lang: Ruby
  Package source  : https://github.com/eighthave/debian/vagrant-cachier
  Description : share a common package cache among similar VM instances

 A Vagrant plugin that helps you reduce the amount of coffee you drink
 while waiting for boxes to be provisioned by sharing a common package
 cache among similar VM instances. Kinda like vagrant-apt_cache or
 this magical snippet but targeting multiple package managers and
 Linux distros.

Bug#759703: Questions about Kea

[Adam Majer]

Hi Tomasz,

I'm packaging Kea right now, and hopefully I will have it ready by end
of the week. But I do have some questions and it would be beneficial
if you could answer them.

  1. Currently Kea has one combined config file. Since I would like to
  split the IPv4, Ipv6 and DDNS services into separate packages, is
  there any potential problem in splitting the config file into three
  distinct config files?


  2. Kea seem to be composed of a large number of dynamic
  libraries. Is there any particular reason to ship these in separate
  packages instead of one? Are there any libraries that are intended
  for users and not just internal usage?

  Also, some of the libraries do not contain all the symbols that they
  use. (you can use c++filt to change mangled names to readable ones)

Thanks,
Adam


dpkg-shlibdeps: warning: symbol _ZN3isc3dns6OpcodeC1Eh used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message11addQuestionERKNS0_8QuestionE used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol _ZN3isc3dns7Message6setQidEt used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message13setHeaderFlagENS1_10HeaderFlagEb used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns15SectionIteratorIN5boost10shared_ptrINS0_8QuestionD1Ev
used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message8setRcodeERKNS0_5RcodeE used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message9setOpcodeERKNS0_6OpcodeE used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol _ZNK3isc3dns7Message13beginQuestionEv
used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol _ZN3isc3dns7MessageC1ENS1_4ModeE used
by debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZNK3isc3dns15SectionIteratorIN5boost10shared_ptrINS0_8QuestiondeEv
used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: 9 other similar warnings have been skipped
(use -v to see them all)


-- 
Adam Majer
ad...@zombino.com

Bug#812368: openssh-server: sshd thinks PuTTY can't do diffie-hellman-group-exchange-sha256

[Brian Minton]

Package: openssh-server
Version: 1:7.1p2-2
Severity: normal

Dear Maintainer,

I'm trying to connect to my system from a Windows client using PuTTY.
The particular version of PuTTY I'm using is TortoisePlink 0.63.0.
from the Xpra distribution.  It supports the key exchange 
diffie-hellman-group-exchange-sha256, which OpenSSH also supports.
However, it seems to be blocked by OpenSSH's compatibility mode.

The pertinent line from the log:

debug2: Compat: skipping algorithm
"diffie-hellman-group-exchange-sha256" [preauth]

I'm attaching the complete log.  Note that I'm using sslh to forward ssh
traffic arriving on port 443 to localhost port 22.


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

Kernel: Linux 4.0.0 (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 openssh-server depends on:
ii  adduser 3.113+nmu3
ii  cdebconf [debconf-2.0]  0.201
ii  debconf [debconf-2.0]   1.5.58
ii  dpkg1.18.4
ii  init-system-helpers 1.24
ii  libaudit1   1:2.4.5-1
ii  libc6   2.21-6
ii  libcomerr2  1.42.13-1
ii  libgssapi-krb5-21.13.2+dfsg-4
ii  libkrb5-3   1.13.2+dfsg-4
ii  libpam-modules  1.1.8-3.2
ii  libpam-runtime  1.1.8-3.2
ii  libpam0g1.1.8-3.2
ii  libselinux1 2.4-3
ii  libssl1.0.2 1.0.2e-1
ii  libsystemd0 228-4
ii  libwrap07.6.q-25
ii  lsb-base9.20160110
ii  openssh-client  1:7.1p2-2
ii  openssh-sftp-server 1:7.1p2-2
ii  procps  2:3.3.11-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  ncurses-term  6.0+20151024-2
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
ii  molly-guard  0.6.2
ii  monkeysphere 0.37-3
ii  rssh 2.3.4-4+b1
ii  ssh-askpass  1:1.2.4.1-9
ii  ssh-askpass-gnome [ssh-askpass]  1:7.1p2-1
ii  ufw  0.34-2

-- debconf information:
  ssh/new_config: true
  ssh/vulnerable_host_keys:
  ssh/disable_cr_auth: false
* ssh/insecure_telnetd:
  ssh/insecure_rshd:
  ssh/encrypted_host_key_but_no_keygen:
* ssh/use_old_init_script: true
  openssh-server/permit-root-login: false
# /usr/sbin/sshd -dd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 1235
debug2: parse_server_config: config /etc/ssh/sshd_config len 1235
debug1: sshd version OpenSSH_7.1, OpenSSL 1.0.2e 3 Dec 2015
debug1: private host key #0: ssh-rsa 
SHA256:XXX
debug1: private host key #1: ssh-ed25519 
SHA256:XXX
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-dd'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 44436 on 127.0.0.1 port 22
debug1: Client protocol version 2.0; client software version 
PuTTY_Local:_Mar_19_2015_19:02:45
debug1: match: PuTTY_Local:_Mar_19_2015_19:02:45 pat 
PuTTY_Local:*,PuTTY-Release-0.5*,PuTTY_Release_0.5*,PuTTY_Release_0.60*,PuTTY_Release_0.61*,PuTTY_Release_0.62*,PuTTY_Release_0.63*,PuTTY_Release_0.64*
 compat 0x4000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1p2 Debian-2
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 32034
debug1: permanently_set_uid: 101/65534 [preauth]
debug2: compat_kex_proposal: original KEX proposal: 
curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 [preauth]
debug2: Compat: skipping algorithm "diffie-hellman-group-exchange-sha256" 
[preauth]
debug2: compat_kex_proposal: compat KEX proposal: curve25519-sha...@libssh.org 
[preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: curve25519-sha...@libssh.org [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-ed25519 [preauth]
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 [preauth]
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 [preauth]
debug2: 

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Nye Liu]

Package: nis
Version: 3.17-34
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

For some reason, even though $portmap is mentioned in /etc/init.d/nis as a
start prereq, ypbind is started BEFORE rpcbind.

This causes ypbind to NEVER properly start, and the bind_wait obviously cannot
ever succeed.

> Jan 22 12:51:01 compile1 kernel: [   22.330297] tg3 :02:00.0 eth0: Flow 
> control is on for TX and on for RX
> Jan 22 12:51:01 compile1 kernel: [   22.330416] IPv6: 
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> Jan 22 12:51:01 compile1 nis[461]: Setting NIS domainname to: xxx.xxx.xxx
...
> Jan 22 12:51:06 compile1 ypbind[615]: Unable to register (YPBINDPROG, 
> YPBINDVERS, udp).
...
> Jan 22 12:51:11 compile1 systemd[1]: Starting RPC bind portmap service...
> Jan 22 12:51:11 compile1 rpcbind[640]: rpcbind: xdr_/run/rpcbind/rpcbind.xdr: 
> failed
> Jan 22 12:51:11 compile1 rpcbind[640]: rpcbind: xdr_/run/rpcbind/portmap.xdr: 
> failed
> Jan 22 12:51:11 compile1 systemd[1]: Started RPC bind portmap service.
> Jan 22 12:51:11 compile1 systemd[1]: Reached target RPC Port Mapper.
...
> Jan 22 12:51:15 compile1 nis[461]: Starting NIS services: ypbindbinding to YP 
> server...failed (backgrounded).
> Jan 22 12:51:15 compile1 nis[461]: .
> Jan 22 12:51:15 compile1 systemd[1]: Started LSB: Start NIS client and server 
> daemons..

Note that the "RPC Port Mapper" target is only reached AFTER ypbind is started
(and fails)

This was working fine until somebody migrated /etc/init.d/rpcbind to
/lib/systemd/

-- Package-specific info:
nm-tool is not installed

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

Kernel: Linux 4.3.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/bash
Init: systemd (via /run/systemd/system)

Versions of packages nis depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  hostname   3.16
ii  libc6  2.21-6
ii  libdbus-1-31.10.6-1
ii  libdbus-glib-1-2   0.106-1
ii  libgdbm3   1.8.3-13.1
ii  libglib2.0-0   2.46.2-3
ii  libslp11.2.1-11
ii  lsb-base   9.20160110
ii  make   4.1-1
ii  netbase5.3
ii  rpcbind [portmap]  0.2.3-0.2

nis recommends no packages.

Versions of packages nis suggests:
pn  nscd  

-- debconf information excluded


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#759445: unmass: diff for NMU version 0.9-3.1

[Wookey]

Control: tags 759445 + pending

Dear maintainer,

I've prepared an NMU for unmass (versioned as 0.9-3.1) and uploaded it
to DELAYED/07. This fixes the bugs filed in 2014 to let it build on
newer architectures. Diff attached.

Regards.
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -u unmass-0.9/debian/changelog unmass-0.9/debian/changelog
--- unmass-0.9/debian/changelog
+++ unmass-0.9/debian/changelog
@@ -1,3 +1,11 @@
+unmass (0.9-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh-autoreconf to support new architectures
+(Closes: #759445 #735386 #759451)
+
+ -- Wookey   Fri, 22 Jan 2016 15:35:53 +
+
 unmass (0.9-3) unstable; urgency=low
 
   * Small fix, add missing comments. (Closes: #456108)
@@ -5,7 +13,7 @@
   * Update email address.
 
  -- Gürkan Sengün   Mon, 28 Apr 2008 11:01:46 +0200
- 
+
 unmass (0.9-2) unstable; urgency=low
 
   * Fix clean target in debian/rules. (Closes: #442754)
diff -u unmass-0.9/debian/control unmass-0.9/debian/control
--- unmass-0.9/debian/control
+++ unmass-0.9/debian/control
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Gürkan Sengün 
-Build-Depends: debhelper (>= 5)
+Build-Depends: debhelper (>= 5), dh-autoreconf
 Homepage: http://mirex.mypage.sk/index.php?selected=1#Unmass
 Standards-Version: 3.7.3
 
diff -u unmass-0.9/debian/rules unmass-0.9/debian/rules
--- unmass-0.9/debian/rules
+++ unmass-0.9/debian/rules
@@ -13,6 +13,7 @@
 configure: configure-stamp
 configure-stamp:
 	dh_testdir
+	dh_autoreconf
 	cd kdev && ./configure --prefix=/usr
 	touch configure-stamp
 
@@ -29,6 +30,7 @@
 	rm -f build-stamp configure-stamp
 	[ ! -f kdev/Makefile ] || $(MAKE) -C kdev clean
 	-rm -f kdev/config.log kdev/Makefile kdev/src/Makefile kdev/config.status kdev/config.h kdev/libtool
+	dh_autoreconf_clean
 	dh_clean 
 
 install: build
only in patch2:
unchanged:
--- unmass-0.9.orig/debian/autoreconf
+++ unmass-0.9/debian/autoreconf
@@ -0,0 +1 @@
+kdev
\ No newline at end of file


signature.asc
Description: Digital signature

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Mark Brown]

reassign 812371 rpcbind

On Fri, Jan 22, 2016 at 01:03:00PM -0800, Nye Liu wrote:
> Package: nis
> Version: 3.17-34
> Severity: critical
> Justification: breaks the whole system

> For some reason, even though $portmap is mentioned in /etc/init.d/nis as a
> start prereq, ypbind is started BEFORE rpcbind.

That sounds like an issue with the sysetmd conversion there, or possibly
with the systemd/sysvinit integration.  Note that I'm in the middle of
repackaging the nis programs, I just got the core yp-tools package in so
we should get that sometime next month hopefully. 

> This causes ypbind to NEVER properly start, and the bind_wait obviously cannot
> ever succeed.

It should eventually figure things out?


signature.asc
Description: PGP signature

Bug#812373: ITP: odhcp6c -- IPv6 DHCP and RA client from OpenWRT

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 

* Package name: odhcp6c
  Version : 1.1
  Upstream Author : Steven Barth 
* URL : https://github.com/sbyx/odhcp6c
* License : GPLv2
  Programming Lang: C
  Description : IPv6 DHCP and RA client from OpenWRT

odhcp6c is a minimal DHCPv6 and RA-client for use in embedded Linux
systems especially routers.  It is intended to comply with RFC7084.
Unlike isc-dhcp-client, it can be used with PPP links.

[I have yet to verify that it does actually work over PPP, but the
OpenWRT documentation implies that it does.]

Bug#812374: diaspora-common: Please allow use of another web server like apache2

[James Valleroy]

Package: diaspora-common
Severity: wishlist

Dear Maintainer,

Currently diaspora-common depends on nginx. It should be possible to run it
with apache2 instead (even if it requires some manual configuration).

Please consider changing the dependency to "nginx | httpd".




signature.asc
Description: OpenPGP digital signature

Bug#759703: Questions about Kea

[Tomek Mrugalski]

On 22.01.2016 20:58, Adam Majer wrote:
> Hi Tomasz,
> 
> I'm packaging Kea right now, and hopefully I will have it ready by end
> of the week. But I do have some questions and it would be beneficial
> if you could answer them.
Hi Adam!

Great to hear that! I'll do my best to help.

>   1. Currently Kea has one combined config file. Since I would like to
>   split the IPv4, Ipv6 and DDNS services into separate packages, is
>   there any potential problem in splitting the config file into three
>   distinct config files?
That's not necessarily true. You could use one config file for all of
them or three separate files if you want to. We provided a single config
file, because it seems to be easier to maintain for users who installed
from the source. But if you plan to split this into 3 packages, using 3
separate configs seems perfectly fine.

We did develop keactrl as a simple generic script for init.d-like
management that could work everywhere. It's perfectly fine to not use it
at all and replace it with Debian specific scripts.

On a related note, we're about to launch a kea-contrib repo on github.
Let me know if there are any Debian specific files that you'd like us to
host there. We'll put systemd scripts that were contributed by RedHat
guys. I recently installed Debian 8 which seems to be using sysvinit.
That's perfectly fine by me. I just wanted to mention that there are
systemd scripts if they're of any use for you.

>   2. Kea seem to be composed of a large number of dynamic
>   libraries. Is there any particular reason to ship these in separate
>   packages instead of one? Are there any libraries that are intended
>   for users and not just internal usage?
libkea-dhcp++ seems to be the only library that could be useful as a
standalone package. It provides generic DHCP operations, like open
sockets, parse and build DHCP options and packets etc. It is currently
used by DHCPv4 server, DHCPv6 server, dhcp-ddns daemon and perfdhcp
(which is a performance tool).

>   Also, some of the libraries do not contain all the symbols that they
>   use. (you can use c++filt to change mangled names to readable ones)
Thanks for this. I admit that I didn't know this tool. I will take a
closer look. Due to family reasons, I won't be able to do this until Monday.

I'm not sure how you want to proceed with this. Is this an issue that
blocks the packaging process? Regardless if it does, we as ISC will do
our best to fix the problem. I see that most all of the issues you
listed below are in libkea-asiodns. This is a library we have inherited
from (now dead) bind10 project.

As a final thought on this, I was wondering what should we do with the
changes. We'll commit them to our master branch and will release it
eventually in the next 1.1.0 release, which is planned sometime during
late spring/early summer. Waiting for the release is not a viable
option. You could keep the changes in kea-1.0.0-debian.tar.gz. Our git
repo is public on github, so maybe doing something like
kea-1.0.0+20160125 would be useful? In any case, I don't have any
preference here and will do whatever works best for you.

Speaking of packages, there are two additional packages that could be
possibly taken into consideration. We do have perfdhcp, which is a
DHCPv4 and DHCPv6 server performance testing tool. It's implementation
independent, so could be used without Kea servers. Also, there's Kea
User's Guide, with is extensive and has around 100 pages of text. This
is one of the Kea advantages over the old ISC DHCP - it's well
documented. If you decide to package it - great. If not, it may be
useful to point it out somewhere that it's available at kea website.

Once you have initial packages that you think are ready for broader
testing, let me know. I will ask good people on kea-dev and kea-users to
test them. There's well over 100 people there. I'm sure many of them are
running Debian and will be willing to help. Obviously, I'll test them
thoroughly myself, too.

Thanks again for doing this. As a happy Debian user since 1999, I'm very
happy that I would be able to help make it a bit better :)

Thanks,
Tomek

> dpkg-shlibdeps: warning: symbol _ZN3isc3dns6OpcodeC1Eh used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol
> _ZN3isc3dns7Message11addQuestionERKNS0_8QuestionE used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol _ZN3isc3dns7Message6setQidEt used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol
> _ZN3isc3dns7Message13setHeaderFlagENS1_10HeaderFlagEb used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol
> _ZN3isc3dns15SectionIteratorIN5boost10shared_ptrINS0_8QuestionD1Ev
> used 

Bug#508428: aptitude: losing automatically installed flag on conflict resolution

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Meelis,

2008-12-11 10:03 Meelis Roos:

Package: aptitude
Version: 0.4.11.11-1
Severity: normal


aptitude has been losing the 'A' flag on several packages recently and I can
see a direct cause for it. The 'A' flag has been lost after aptitudes conflict
resolution. aptitude sees conflicts, I select one solution (like keeping
libgnomefoo-common back) and the the A flag on libgnomefoo-common is lost.


Thanks for the report.

I commited a fix to address this problem, so marking it as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#811430: libjsoncpp-dev: Install jsoncppConfig.cmake to dev package.

[Peter Spiess-Knafl]

Hi Ghis!

I just looked at the upstream source (current and newest one). I
couldn't find any FindModule for JsonCpp. Do you have a reference to it?

On 01/19/2016 10:51 AM, Ghislain Vaillant wrote:
> Hi Peter, thanks for acknowledging the bug.
> 
> Feel free to have a look here for a working example:
> 
> 
> https://anonscm.debian.org/cgit/debian-science/packages/clblas.git/tree/debian
> 
> 
> I have also provided an autopkgtest for building the examples to
> verify that the find modules was installed appropriately. You may
> also want to check clfft, arrayfire... or any other cmake based
> package that I personally maintain if you don't trust my advice.
> 
> FYI, I believe the pkgconfig file should also end-up in a multi-arch
> path (usr/lib//pkgconfig) since it depends on a
> multi-arch enabled variable (libdir). I am happy to file a different
> bug for it if you want.

This is a different bug yes. Thank your for recognizing it.

Greetings
Peter

Bug#812369: rpcbind does not properly provide $portmap needed by /etc/init.d/nis

[Nye Liu]

Package: rpcbind
Version: 0.2.3-0.2
Severity: important

Dear Maintainer,

The new /lib/systemd/system/rpcbind is a mess.

First off:

/etc/init.d/nis depends on $portmap, which leads to two problems

1) rpcbind does not provide $portmap (only rpcbind.target) so nis/ypbind may be
   started before rpcbind

2) even if nis/ypbind is started AFTER rpcbind.target, it does not actually
   mean rpcbind is up (since it apparently takes time to start), causing
   /etc/init.d/nis to fail to launch ypbind properly with:

   Unable to register (YPBINDPROG, YPBINDVERS, udp)

   And then the nis script goes in to bind_wait(), which never completes
   since ypbind was never started in the first place.

Secondly, $STATEDIR/rpcbind.xdr and $STATEDIR/portmap.xdr are no longer
created (thanks, systemd!), leading to:

 rpcbind: xdr_/run/rpcbind/rpcbind.xdr: failed
 rpcbind: xdr_/run/rpcbind/portmap.xdr: failed

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

Kernel: Linux 4.3.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/bash
Init: systemd (via /run/systemd/system)

Versions of packages rpcbind depends on:
ii  init-system-helpers  1.24
ii  initscripts  2.88dsf-59.2
ii  insserv  1.14.0-5
ii  libc62.21-6
ii  libsystemd0  228-4
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20160110

rpcbind recommends no packages.

rpcbind suggests no packages.

-- no debconf information


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#808739: yoshimi: FTBFS: Missing cmGeneratorTarget instance!

[Rob Couto]

In case it helps, here's a patch to apply the same workaround to
1.3.7.1. It's basically the same as the recent commit but with
different line numbers.

-- 
Rob
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index f1cf0d0..c2f82df 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -217,18 +217,6 @@ else(READLINE_FOUND)
 message( FATAL_ERROR "Readline library not found! Please install 
development components (libreadline-dev)" )
 endif(READLINE_FOUND)
 
-set (GuiFluids
-UI/WidgetPDialUI.fl  UI/PresetsUI.fl  UI/EnvelopeUI.fl
-UI/LFOUI.fl  UI/FilterUI.fl  UI/VirKeyboardUI.fl
-UI/ConfigUI.fl  UI/SUBnoteUI.fl  UI/ResonanceUI.fl
-UI/OscilGenUI.fl  UI/ADnoteUI.fl  UI/PADnoteUI.fl
-UI/EffUI.fl  UI/BankUI.fl  UI/PartUI.fl
-UI/MicrotonalUI.fl  UI/MasterUI.flUI/MasterMiscUI.fl
-UI/ParametersUI.fl UI/ConsoleUI.fl
-)
-
-fltk_wrap_ui (yoshimi ${GuiFluids})
-set_source_files_properties (UI/MasterUI.h PROPERTIES GENERATED 1)
 set (YOSHI_INCLUDES ${FLTK_INCLUDE_DIR})
 
 if (BuildForDebug)
@@ -292,6 +280,52 @@ set (MusicIO_sources
 MusicIO/JackAlsaClient.cpp  MusicIO/AlsaJackClient.cpp
 )
 
+set (FlGUI_sources
+WidgetPDialUI.cpp  PresetsUI.cpp  EnvelopeUI.cpp
+LFOUI.cpp  FilterUI.cpp  VirKeyboardUI.cpp
+ConfigUI.cpp  SUBnoteUI.cpp  ResonanceUI.cpp
+OscilGenUI.cpp  ADnoteUI.cpp  PADnoteUI.cpp
+EffUI.cpp  BankUI.cpp  PartUI.cpp
+MicrotonalUI.cpp  MasterUI.cpp MasterMiscUI.cpp
+ParametersUI.cpp ConsoleUI.cpp
+)
+
+# mostly for make clean because cmake doesn't expect 2 files to come from 1 
custom command
+set (FlGUI_headers
+WidgetPDialUI.h  PresetsUI.h  EnvelopeUI.h
+LFOUI.h  FilterUI.h  VirKeyboardUI.h
+ConfigUI.h  SUBnoteUI.h  ResonanceUI.h
+OscilGenUI.h  ADnoteUI.h  PADnoteUI.h
+EffUI.h  BankUI.h  PartUI.h
+MicrotonalUI.h  MasterUI.h MasterMiscUI.h
+ParametersUI.h ConsoleUI.h
+)
+
+# workaround fltk_wrap_ui breakage
+add_custom_command(
+OUTPUT ${FlGUI_sources}
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/WidgetPDialUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/PresetsUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/EnvelopeUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/LFOUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/FilterUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/VirKeyboardUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ConfigUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/SUBnoteUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ResonanceUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/OscilGenUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ADnoteUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/PADnoteUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/EffUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/BankUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/PartUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/MicrotonalUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/MasterUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/MasterMiscUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ParametersUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ConsoleUI.fl
+)
+
 add_definitions (
 -D'YOSHIMI_VERSION="${YOSHIMI_VERSION}"'
 -D'BASE_INSTALL_DIR="${CMAKE_INSTALL_PREFIX}"'
@@ -395,7 +429,7 @@ set (ProgSources
 ${DSP_sources}
 ${Effects_sources}
 ${MusicIO_sources}
-${yoshimi_FLTK_UI_SRCS}
+${FlGUI_sources}
 )
 
 include_directories (AFTER
@@ -486,7 +520,7 @@ install (FILES 
${CMAKE_CURRENT_SOURCE_DIR}/../desktop/yoshimi.appdata.xml
 DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/appdata)
 
 set_directory_properties (PROPERTIES
-ADDITIONAL_MAKE_CLEAN_FILES "${CMAKE_SOURCE_DIR}/*UI.c* 
${CMAKE_SOURCE_DIR}/src/*UI.h"
+ADDITIONAL_MAKE_CLEAN_FILES "${FlGUI_headers}"
 )
 
 add_custom_target (showversion
diff --git a/src/LV2_Plugin/CMakeLists.txt b/src/LV2_Plugin/CMakeLists.txt
index 889f3ce..b512a49 100644
--- a/src/LV2_Plugin/CMakeLists.txt
+++ b/src/LV2_Plugin/CMakeLists.txt
@@ -66,18 +66,52 @@ file (GLOB yoshimi_manifest_ttl
 file (GLOB yoshimi_plugin_ttl
 yoshimi.ttl)
 
-set (GuiFluids
-../UI/WidgetPDialUI.fl  

Bug#812362: jessie-pu: package giflib/4.1.6-11+deb8u1

[Guido Günther]

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

Hi,
I'd like to fix CVE-2015-7555 via jessie-pu since the bug is fixed in
Squeeze LTS and we try to not introduce new security issues when people
upgrade (the Debian security team marked this CVE as no-dsa).

Please find the debdiff attached.
Cheers,
 -- Guido

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

Kernel: Linux 4.1.0-2-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)
diff --git a/debian/changelog b/debian/changelog
index d1fa6ba..d35e960 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+giflib (4.1.6-11+deb8u1) stable-proposed-updates; urgency=medium
+
+  * Non-maintainer upload by the LTS Security Team.
+  * CVE-2015-7555: bail out if Width > SWidth.
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+(Closes: #808704)
+
+ -- Guido Günther   Mon, 18 Jan 2016 17:08:39 +0100
+
 giflib (4.1.6-11) unstable; urgency=low
 
   * Remove Provides: libungif4g.
diff --git a/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
new file mode 100644
index 000..e660bea
--- /dev/null
+++ b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
@@ -0,0 +1,22 @@
+From: "Eric S. Raymond" 
+Date: Tue, 5 Jan 2016 23:01:45 -0500
+Subject: CVE-2015-7555: bail out if Width > SWidth
+
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+---
+ util/giffix.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/util/giffix.c b/util/giffix.c
+index 247305e..408d429 100644
+--- a/util/giffix.c
 b/util/giffix.c
+@@ -137,6 +137,8 @@ int main(int argc, char **argv)
+ 		Height = GifFileIn->Image.Height;
+ 		GifQprintf("\n%s: Image %d at (%d, %d) [%dx%d]: ",
+ 		PROGRAM_NAME, ++ImageNum, Col, Row, Width, Height);
++		if (Width > GifFileIn->SWidth)
++		GIF_EXIT("Image is wider than total");
+ 
+ 		/* Put the image descriptor to out file: */
+ 		if (EGifPutImageDesc(GifFileOut, Col, Row, Width, Height,
diff --git a/debian/patches/series b/debian/patches/series
index 3bcfb21..e297c1f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 02-doc_fixes.patch
 03-spelling_fixes.patch
 04-fprintf_format_error.patch
+CVE-2015-7555-bail-out-if-Width-SWidth.patch

Bug#812363: wheezy-pu: package giflib/4.1.6-10+deb7u1

[Guido Günther]

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

Hi,
I'd like to fix CVE-2015-7555 via wheezy-pu since the bug is fixed in
Squeeze LTS and we try to not introduce new security issues when people
upgrade (the Debian security team marked this CVE as no-dsa).

Please find the debdiff attached.
Cheers,
 -- Guido

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

Kernel: Linux 4.1.0-2-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)
diff --git a/debian/changelog b/debian/changelog
index 727ea97..f728114 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+giflib (4.1.6-10+deb7u1) oldstable-security; urgency=medium
+
+  * Non-maintainer upload by the LTS Security Team.
+  * CVE-2015-7555: bail out if Width > SWidth.
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+(Closes: #808704)
+
+ -- Guido Günther   Fri, 22 Jan 2016 19:03:38 +0100
+
 giflib (4.1.6-10) unstable; urgency=low
 
   * Fixing fprintf issues by YunQiang Su.
diff --git a/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
new file mode 100644
index 000..e660bea
--- /dev/null
+++ b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
@@ -0,0 +1,22 @@
+From: "Eric S. Raymond" 
+Date: Tue, 5 Jan 2016 23:01:45 -0500
+Subject: CVE-2015-7555: bail out if Width > SWidth
+
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+---
+ util/giffix.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/util/giffix.c b/util/giffix.c
+index 247305e..408d429 100644
+--- a/util/giffix.c
 b/util/giffix.c
+@@ -137,6 +137,8 @@ int main(int argc, char **argv)
+ 		Height = GifFileIn->Image.Height;
+ 		GifQprintf("\n%s: Image %d at (%d, %d) [%dx%d]: ",
+ 		PROGRAM_NAME, ++ImageNum, Col, Row, Width, Height);
++		if (Width > GifFileIn->SWidth)
++		GIF_EXIT("Image is wider than total");
+ 
+ 		/* Put the image descriptor to out file: */
+ 		if (EGifPutImageDesc(GifFileOut, Col, Row, Width, Height,
diff --git a/debian/patches/series b/debian/patches/series
index 3bcfb21..e297c1f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 02-doc_fixes.patch
 03-spelling_fixes.patch
 04-fprintf_format_error.patch
+CVE-2015-7555-bail-out-if-Width-SWidth.patch

Bug#811428: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

Hi Salvatore,

I'll get the wheezy-security package built and tested and send an update as 
soon as it's done.

regards,
Lars Tangvald

- Original Message -
From: car...@debian.org
To: robie.ba...@ubuntu.com
Cc: 811...@bugs.debian.org, t...@security.debian.org
Sent: Thursday, January 21, 2016 8:15:30 PM GMT +01:00 Amsterdam / Berlin / 
Bern / Rome / Stockholm / Vienna
Subject: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the 
January 2016 CPU

Hi Robie,

On Thu, Jan 21, 2016 at 09:46:13AM +, Robie Basak wrote:
> Dear Security Team,
> 
> You have asked us to be prompt with helping to prepare security updates
> for you, and we have done so. We have kept the bug updated like you
> asked us last time. The sources are tested and ready. We notified the
> bug as requested, but haven't heard from you. Please let us know how you
> want to coordinate uploading this.

Thanks for preparing an update.

We usually would see a debdiff from the resulting built package (in
case of a new upstream import this can get big, so some autogenerated
files can be filtered out).

We have collected important information for us in advisory preparation
in https://wiki.debian.org/DebianSecurity/AdvisoryCreation especially
relevant from the developers point of view preparing the update
https://wiki.debian.org/DebianSecurity/AdvisoryCreation/SecurityDev .

The changelog itself looks good to me from a quick skim trough. It
addresses all the information we would like to have seen there (CVE
references, bug fixed, reference to Oracle CPU). Thank you.

Important question first: What is the status for the wheezy-security
package for those issues?

Plase make sure for the following: Once you have both, built the
jessie-security one with -sa to include the original orig.tar.gz and
the wheezy-security one explicitly without -sa to not include the orig
source tarball.

Then we need a bit of coordination for the upload order, since
mysql-5.5 is a special case with same source orig.tar.gz for both
wheezy and jessie. Someone of your team with GPG key in the DD keyring
might then upload first the jessie-security one to security-master,
and after it gets accepted there, upload the wheezy-security one.

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#812358: debian-live: Please add gparted

[Devin Trotter]

Donald - I will help you with this as I can if you're willing to take the lead.

-Original Message-
From: Don Raikes [mailto:don.rai...@oracle.com]
Sent: Friday, January 22, 2016 11:21 AM
To: Ben Armstrong ; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

Ben,

I would consider taking on the task of maintaining the necessary files for a 
rescue image.

I haven't looked into what is involved, but if you can point me to some docs I 
will take a look and see if it will fit with my time constraints.

Sincerely,
Donald

-Original Message-
From: Ben Armstrong [mailto:sy...@sanctuary.nslug.ns.ca]
Sent: Friday, January 22, 2016 10:05 AM
To: Christian Hammers; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

On 22/01/16 12:46 PM, Christian Hammers wrote:
> Package: debian-live
> Version: 8.2.0-amd64-xfce-desktop
> Severity: wishlist
>
> Hello
>
> Please add "gparted" to the Debian Live CD.
>
> Live CDs are greate to rescue broken systems or to shrink/enlarge root
> file systems etc. In such cases the graphical approach of gparted
> which automatically resizes the filesystem with the partition is much
> more error safe than the CLI alternatives fdisk or parted. That's
> especially the case for GPT and LVM which are still quite new to some
> people.
>
> The installed size of gparted and its dependency libparted-fs-resize0
> would just be 7 MB.
>

Our desktop live images only contain the desktop, as it would be installed by 
the Debian Installer. While arguably, many different tools would be useful on a 
live utility disk, those are not things that normally come with a Debian 
desktop, so are not included.

The 'rescue' flavour used to exist and contained a number of tools designed for 
rescuing systems. However, that did not contain any desktop. Many excellent 
rescue images do exist that are produced by third parties and which would 
contain both a desktop and gparted. For Debian to have its own 'official' 
rescue image would require someone to do the work of looking after compiling a 
list of 'essential (possibly with GUI) rescue tools' to go on the image. So 
far, despite my repeated calls for help with this, nobody has stepped forward 
to do the work.

Regards,
Ben




This e-mail and any files transmitted with it are the property of Computer 
Services, Inc. and/or its divisions, are confidential, and are intended solely 
for the use of the individual or entity to whom this e-mail is addressed. The 
sender does not accept any responsibility for any loss, disruption or damage to 
your data or computer systems that may occur from content of any sort contained 
in, transmitted with, or added to this e-mail. If you are not a named recipient 
or otherwise have reason to believe that you have received this message in 
error, please notify the sender and delete this message immediately from your 
computer. Any other use, retention, dissemination, forwarding, printing, or 
copying of this e-mail is strictly prohibited.

Bug#812360: RFS: ultracopier/1.2.2.0

[alpha_one_x86]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "Ultracopier" same code as 
Supercopier.
The old mentor don't update it, the dep is Qt 5.4+ no more.
Ultracopier is free and open source software licensed under GPL3 that acts as a 
replacement for files copy dialogs. Main features include: play/pause, speed 
limitation, on-error resume, error/collision management ...

 * Package name: ultracopier
   Version : 1.2.2.0
   Upstream Author : alpha_one_x86 
 * URL : http://ultracopier.first-world.info/
 * License : GPL3
   Section : utils

The easy way to compil from source is via ultracopier-all-in-one-direct.pro, 
the git is:

https://github.com/alphaonex86/Ultracopier

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

https://packages.debian.org/sid/main/ultracopier

More information about Ultracopier/Supercopier can be obtained from 
http://ultracopier.first-world.info/

Changes since the last upload:
http://forum-ultracopier.first-world.info/post2517.html

Regards,

Bug#810820: linux-image-4.3.0-1-amd64: XEN fails after 7 domU's are started with linux-image-4.3.0-1-amd64 (version 4.3.3-5)

[KSB]

Can't find 4.3.3-6 anymore, but can confirm that on 4.3.3-7 problem is gone.
Do I need to make any additional tests?

Kaspars

Bug#812358: debian-live: Please add gparted

[Don Raikes]

Ben,

I would consider taking on the task of maintaining the necessary files for a 
rescue image.

I haven't looked into what is involved, but if you can point me to some docs I 
will take a look and see if it will fit with my time constraints.

Sincerely,
Donald

-Original Message-
From: Ben Armstrong [mailto:sy...@sanctuary.nslug.ns.ca] 
Sent: Friday, January 22, 2016 10:05 AM
To: Christian Hammers; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

On 22/01/16 12:46 PM, Christian Hammers wrote:
> Package: debian-live
> Version: 8.2.0-amd64-xfce-desktop
> Severity: wishlist
>
> Hello
>
> Please add "gparted" to the Debian Live CD.
>
> Live CDs are greate to rescue broken systems or to shrink/enlarge root 
> file systems etc. In such cases the graphical approach of gparted 
> which automatically resizes the filesystem with the partition is much 
> more error safe than the CLI alternatives fdisk or parted. That's 
> especially the case for GPT and LVM which are still quite new to some 
> people.
>
> The installed size of gparted and its dependency libparted-fs-resize0 
> would just be 7 MB.
>

Our desktop live images only contain the desktop, as it would be installed by 
the Debian Installer. While arguably, many different tools would be useful on a 
live utility disk, those are not things that normally come with a Debian 
desktop, so are not included.

The 'rescue' flavour used to exist and contained a number of tools designed for 
rescuing systems. However, that did not contain any desktop. Many excellent 
rescue images do exist that are produced by third parties and which would 
contain both a desktop and gparted. For Debian to have its own 'official' 
rescue image would require someone to do the work of looking after compiling a 
list of 'essential (possibly with GUI) rescue tools' to go on the image. So 
far, despite my repeated calls for help with this, nobody has stepped forward 
to do the work.

Regards,
Ben

Bug#812365: /usr/bin/apt-get: when download of a package list timeouts it is reported as Ign rather than Err

[Michal Suchanek]

Package: apt
Version: 1.0.10.2
Severity: normal
File: /usr/bin/apt-get

Hello,

I was wondering why apt-get update randomly ignores some packages files
and after adding some debug options it turns out that the download times
out and apt reports Ign before the source name.

This is a rather unfortunate way to report download failure.

Timeout should cause Err to be printed just like any other error.

Thanks

Michal

-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (990, 'stable'), (500, 'oldstable'), (171, 
'unstable'), (151, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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)

Versions of packages apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-6
ii  libapt-pkg4.16  1.0.10.2
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-23
ii  libstdc++6  5.2.1-23

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.7.4-1
ii  dpkg-dev1.18.3
ii  python-apt  1.0.1

-- no debconf information

Bug#741894: libtk-img: FTBFS with libopng16

[Gianfranco Costamagna]

Hi, so are you saying this version is incompatible with libpng12?
Cheers
G.

Sent from Yahoo Mail on Android 
 
  On Fri, 22 Jan, 2016 at 19:15, Sergei Golovan wrote:   tags 
741894 + pending
thanks

Hi again!

On Fri, Jan 22, 2016 at 3:37 PM, Gianfranco Costamagna
 wrote:
>
> wonderful!
> please note that the transition might start soon(TM), maybe in a week or two,
> so this bug might become RC soon.

I've prepared the fixed package, but I won't upload it to experimental
because it requires packages from http://libpng.sviech.de/libpng16 to
build. But as long as libpng16-dev will go to sid and libfreetype6-dev
will not require libpng12-dev (via libpng-dev virtual package) I'll
immediately upload the version compatible with libpng16.

Cheers!
-- 
Sergei Golovan
  

Bug#812361: sbuild: provide easy support for sourceful uploads

[Wookey]

Source: sbuild
Severity: wishlist

I always want to do an sbuild build of a package in a clean chroot
before uploading. These days it is best practice to do sourceful
uploads, so having a way to get a foo_version_source.changes at the
end of the build instead of (or as well as) a foo_version_arch.changes
would be very handy.

Currently I do sbuild -s -A to make sure that the source and binary I
upload match. Otherwise it is too easy to make a change in the
unpackaged packages, forget dpkg-buildpackage -S, and then
sbuild-clean-chroot test the previous .dsc

Using -A alone you are likely to upload a binary with the corresponding
source missing and it getting rejected.

So having one run that would test the clean build, and produce the
sourceful-upload changes file that was defintely for the corresponding
source, would be something I'd use as standard workflow.

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

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

Bug#741894: libtk-img: FTBFS with libopng16

[Sergei Golovan]

tags 741894 + pending
thanks

Hi again!

On Fri, Jan 22, 2016 at 3:37 PM, Gianfranco Costamagna
 wrote:
>
> wonderful!
> please note that the transition might start soon(TM), maybe in a week or two,
> so this bug might become RC soon.

I've prepared the fixed package, but I won't upload it to experimental
because it requires packages from http://libpng.sviech.de/libpng16 to
build. But as long as libpng16-dev will go to sid and libfreetype6-dev
will not require libpng12-dev (via libpng-dev virtual package) I'll
immediately upload the version compatible with libpng16.

Cheers!
-- 
Sergei Golovan

Bug#808551: Issue 466016 in chromium: Save Page As proposes to save to ".html"!

[積丹尼 Dan Jacobson]

c> https://code.google.com/p/chromium/issues/detail?id=466016

c> As per the latest message #10 in
c> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808551 this seems to
c> be fixed in latest version

c> Could you please check the same on latest version and update the thread.

I would but the new package was never put into Debian!

Bug#812166: [Pkg-xen-devel] Bug#812166: xen: FTBFS with GCC 6: statement is indented as if...

[Martin Michlmayr]

* Ian Campbell  [2016-01-22 12:51]:
> I have rebuilt the upstream xen source (both development version and 4.6)
> with gcc-6 from experimental:
> 
> $ gcc-6 --version
> gcc-6 (Debian 6-20160117-1) 6.0.0 20160117 (experimental) [trunk revision 
> 232481]
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> and did not come across any issues.

Hmm, strange.  As far as I can tell (based on a really quick look),
various Makefiles define -Werror.  And I see -Wall, too.  -Wall would
pull in the new warning.

Anyway, I guess it doesn't matter since you're fixing the code
indentation anyway.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#576319: [Aptitude-devel] Bug#576319: Bug#576319: aptitude: "Cancel pending actions" erase "h - hold" state

[Manuel A. Fernandez Montecelo]

2016-01-22 15:07 GMT+00:00 Ralf Jung :
>
>>   This is fundamentally unattaintable.  Actions are immediately saved
>>   to several places, including apt and dpkg accessible files, so if you
>>   mark a package for deletion and quit aptitude, "dpkg --pending
>>   --remove" will remove it.  If apt, dpkg or other tools install other
>>   packages in the meantime, or update the available packages, upon
>>   starting aptitude it will re-read the state of the system and will
>>   update things accordingly, removing/invalidating part of the
>>   previously scheduled actions.  So one will be unable to undo some of
>>   the "saved but not performed actions [within aptitude]", because
>>   actions would have been performed outside of aptitude.
>
> I'm not sure I follow. The behavior I would like to see is certainly
> attainable. It can be obtained, for example, as follows (just as a
> sketch, of course, this is not practical):
>
> * Store a list of packages marked as "held"
> * Run the current "Cancel pending actions"
> * Iterate over the stored list, marking every package on it as "held"
>   again
>
> This is entirely local to aptitude, I do not understand how this should
> interact with other tools any more than "Cancel pending actions" already
> does right now.

tl;dr: No, it cannot work properly and interact well with the rest of
the tools without saving the state to places common to other tools at
the time of quitting, not only "local to aptitude".


If one marks a package in aptitude as "held", it has to save it
somewhere (currently to dpkg's database of "hold" packages) so that
dselect or apt or other tools respecting those don't attempt to
install new versions.  This is saved at the same time when one quits
aptitude, because people expect that marking as Hold and
Auto-installed take effect once one quits aptitude or saves the state
in other ways (e.g. after confirming "preview" and before starting
other actions -- removals, or downloads+installations).  I don't know
if all tools respect that yet in all cases, but we've done our bit so
far.  After that point, one cannot "cancel that pending action" --
saving the state makes the action of "set on-hold" as permanent,
having being taken.

Same happens with auto-installed flag, only that this has been going
on since forever (or at least about a decade), not a recent thing like
the holds communicated back to dpkg only in the 0.7 series.

Similar problems *happened* (past, not present) with aptitude not
communicating the status of other actions.  E.g., marking a package to
upgrade in aptitude but not finishing the upgrade and quitting,
removing the package with apt, then firing up aptitude would mark the
package as to be installed.  Many reports about similar sync problems
as well, only addressed in the last few versions.

People expect that all package-management tools in the system
cooperate and don't trip each other.  If aptitude does not save it to
the "common areas" or not at the time of saving the state, people will
start to complain again (as it happened in the past) that actions
selected in aptitude are not respected by other tools, and the other
way around.


That's why the concept of "Cancel pending actions" including scheduled
actions in previous aptitude sessions, doesn't make much sense to me.
The rug can be pulled from below the feet of aptitude by other tools
messing with the system at any time in between invocations, and some
of what aptitude traditionally considered actions (e.g. holds) cannot
be undone.  That's why I said that it's not possible to have good
cooperation with other tools while being able to cancel pending
actions from previous sessions.  And that's why I think that "Cancel
pending actions" only make sense if considering the unsaved state
(i.e., making the previous decisions in this session, *before saving
the state*, be forgotten).


> What I am surprised about is the fact that aptitude treats the "hold"
> bit and the "automatically installed" bit so very different. As a user,
> for me, they are both persistent meta-data that I locally assign to
> packages:
>
> auto-installed = I do not actually want this package itself, please
>   go ahead and remove if it nobody needs it.
> hold = I do not want this package's version to change without manual
>   intervention.
>
> It took me a long time to realize that aptitude, for some (I guess
> historic?) reason, treats "hold" as transient. I do not understand why
> this is done - it makes no sense in my mental model, since transiently
> (i.e., looking at the effect of a single transaction), "hold" and "keep"
> are the same: The transaction *does not* have an effect on this package.

I can only guess that, given the state of the Debian world and the
packaging tools at the time --and probably aptitude was the tool which
introduced the concepts of "hold"--, "hold" was seen as a exceptional
measure to temporarily address problems with packages entering
unstable, and that the natural 

Bug#784523: Bumping severities

[Jean-Francois Dockes]

Lisandro Damián Nicanor Pérez Meyer writes:
 > Control: tag -1 patch
 > 
 > On Friday 22 January 2016 17:20:28 Jean-Francois Dockes wrote:
 > [snip] 
 > > Hi,
 > > 
 > > As far as I know, Recoll builds fine with qt5-webkit > 5.2. Just get rid of
 > > the QMAKE=qmake-qt4 line in the rules.
 > 
 > Indeed, this is true. Thanks Jean-Francois!
 > 
 > I'm attaching a patch to get this done.
 > 
 > I have seen that the latest upload was a NMU agreed with you, please take a 
 > look at the patch and tell me if you want me to upload it.
 > 
 > Thanks in advance!

Hi,

Last week's upload was validated by Kartik Mistry, who is the Debian
package maintainer. I'm the upstream and I see nothing wrong with the
patch, but Kartik should probably be in the loop if he is around.

Cheers,

jf


 > -- 
 > No pienses que estoy loco, es sólo una manera de actuar
 >   De mí - Charly García
 > 
 > Lisandro Damián Nicanor Pérez Meyer
 > http://perezmeyer.com.ar/
 > http://perezmeyer.blogspot.com/
 > 
 > --
 > diff --git a/debian/changelog b/debian/changelog
 > index 1958191..4537a22 100644
 > --- a/debian/changelog
 > +++ b/debian/changelog
 > @@ -1,3 +1,10 @@
 > +recoll (1.21.0-1.2) UNRELEASED; urgency=medium
 > +
 > +  * Non-maintainer upload.
 > +  * Switch to Qt 5 (Closes: #784523).
 > +
 > + -- Lisandro Damián Nicanor Pérez Meyer   Fri, 22 Jan 
 > 2016 13:29:02 -0300
 > +
 >  recoll (1.21.0-1.1) unstable; urgency=medium
 >  
 >* Non-maintainer upload (agreed by maintainer). (Closes: #809478)
 > diff --git a/debian/control b/debian/control
 > index 368f55a..973c6c8 100644
 > --- a/debian/control
 > +++ b/debian/control
 > @@ -7,8 +7,8 @@ Build-Depends: autotools-dev,
 > debhelper (>= 7),
 > dh-python,
 > dpkg-dev (>= 1.16.1~),
 > -   libqt4-dev,
 > -   libqtwebkit-dev,
 > +   qtbase5-dev,
 > +   libqt5webkit5-dev,
 > libx11-dev,
 > libxapian-dev (>= 1.2.0),
 > libz-dev,
 > diff --git a/debian/rules b/debian/rules
 > index 82590ae..2389a87 100755
 > --- a/debian/rules
 > +++ b/debian/rules
 > @@ -17,8 +17,8 @@ LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
 >  
 >  build3vers := $(shell py3versions -sv)
 >  
 > -#build qt4 UI only
 > -export QMAKE=qmake-qt4
 > +#build qt5 UI
 > +export QT_SELECT := qt5
 >  
 >  ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 >  CFLAGS += -O0
 > xapplication/pgp-signature [Click mouse-2 to save to a file]

Bug#784523: Bumping severities

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 22 January 2016 19:32:51 Jean-Francois Dockes wrote:
[snip]
> Hi,
> 
> Last week's upload was validated by Kartik Mistry, who is the Debian
> package maintainer. I'm the upstream and I see nothing wrong with the
> patch, but Kartik should probably be in the loop if he is around.

My bad at not being verbose enough, I was referring to Kartik indeed :)

-- 
No hay preguntas tontas, solo tontos que no preguntan.
 personaje, en un mail del LugFi.

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#812364:

[Ivan Borzenkov]

I build pakage from arch PKGBUILD in
https://launchpad.net/~ivan1986/+archive/ubuntu/ppa

https://launchpad.net/~ivan1986/+archive/ubuntu/ppa/+files/co2mon_2.1.0-4~ubuntu16.04.1~ppa1.dsc

it may have some errors, but it's maybe a good start for create debian
package.
This util may be usefull in Rasbery Pi and other AMR controllers for smart
home

Bug#812287: libetonyek: FTBFS with GCC 6: test suite segfaults

[Martin Michlmayr]

reopen 812287
reassign 812287 gcc-6 6-20160117-1
retitle 812287 test suites segfault / constexpr leaves reference member var 
uninitialized
forwarded 812287 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327
thanks

* Rene Engelhard  [2016-01-22 13:01]:
> That reminds me of
> https://whatofhow.wordpress.com/2016/01/20/gcc-6/

Thanks for tracking that down!  Let's reassign the bug against gcc-6.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#741894: libtk-img: FTBFS with libopng16

[Sergei Golovan]

On Fri, Jan 22, 2016 at 10:18 PM, Gianfranco Costamagna
 wrote:
> Hi, so are you saying this version is incompatible with libpng12?

Yes, that libtk-img will be incompatible with libpng12.

-- 
Sergei Golovan

Bug#759403: lintian: Please publish machine-readable report for all packages

[Niels Thykier]

On Wed, 27 Aug 2014 07:06:11 +0200 Niels Thykier  wrote:
> On 2014-08-27 02:34, intrig...@debian.org wrote:
> > Package: lintian
> > Version: 2.5.25
> > Severity: wishlist
> > 
> > Hi,
> > 
> 
> Hi,
>

Hi,

I believe it is has been easier to hack on html_reports now, in case you
are still interested in working on this.


>> I've given it a try, but was quickly discouraged by the need for
>> a local lab (and mirror?), which I have no experience with.
>> 

These days, you "just" need:

 * a config file
   - /srv/lintian.debian.org/config (will need some modifications)
 * a lintian.log file
   - /srv/lintian.debian.org/logs/lintian.log
 * a harness state cache.
   - /srv/lintian.debian.org/harness-state/state-cache

All three files can be found on lindsay.debian.org at the denoted paths
(I believe you have a log-in there - otherwise let me know and I will
put a copy on people.d.o).

For the given files, you will be needing a lot of RAM (2 GB) without
graphs (even more with graphs).  Memory usage reducing patches will also
be very welcome. :)

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#805762: armory: Click-wrap dialogue appears on first use of package

[Gunnar Wolf]

Riley Baird dijo [Sun, Nov 22, 2015 at 05:53:01PM +1100]:
> Package: armory
> Version: 0.92.3-1+b1
> Severity: normal
> 
> Upon starting armory from the CLI, I get a notice which requires me to tick a
> box saying "I agree to all the terms of the license above" before I can use 
> the
> software. This is annoying, because a wonderful part of using Debian is not
> having to worry about licensing.

It makes you click through (and, I guess, only once). I would not
argue it is too obtrusive, and it does not require "worrying". Debian
has a policy of not deviating whenever possible from upstream for just
"cosmetic" reasons, so if at all, I'd suggest downgrading this bug to
"wishlist" (just shy of closing it :) ).

> However, I think I should point out that (as you can see in the attached
> screenshot), in addition to the AGPLv3, it is stated that "Additionally, as a
> condition of receiving this software for free, you accept all risks associated
> with using it and the developers of Armory will not be held liable for any 
> loss
> of money or bitcoins due to software defects." I am not a lawyer, so I do not
> intend to interpret how the AGPLv3 and this condition interact, and I've
> forwarded this message to debian-legal.

I would see this clause not as an additional condition, but as a
reiteration/emphatization of already existing conditions 15, 16 and 17
of AGPLv3:

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH
YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely
approximates an absolute waiver of all civil liability in
connection with the Program, unless a warranty or assumption of
liability accompanies a copy of the Program in return for a fee.

Bug#803249: needrestart: Restarts services in debconf noninteractive

[Stephen Dowdy]

I believe the Felix is saying that 'needrestart' appears to be unaware of
the common explicit DEBIAN_FRONTEND=noninteractive setting used to indicate
that package management should be non-interactive (and if not, then *I* am)

I will often use 'pdsh' to run forced package updates like so:

$ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2;
DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o
Dpkg::Options::="--force-confold" http://www.ral.ucar.edu/~sdowdy/

Bug#780530: [calendarserver]

[Ximin Luo]

On 20/01/16 18:29, Rahul Amaram wrote:
>> (d) The git history for the debian/wheezy branch of calendarserver is also 
>> messed up - you have version 3.2 committed on top of 5.2.2. It involves a 
>> bit of git magic to fix, which I can do, if you want to avoid the hassle 
>> yourself and you give me access.
>>
>> I've also asked to be added to the calendarserver group on Alioth, so that I 
>> can make these changes myself.
> Feel free to do the changes. Not sure how it got messed up. Thanks.

OK, I've rewritten the history so things make more sense looking at the logs - 
all the "Imported Upstream version" commits are now in the correct linear 
sequence, as well as the "Imported Debian patch" commits, and debian/wheezy 
branches away from the main history at the correct place.

You'll need to update your own repo to point all your local branches to the new 
rewritten history. If it's too messy, you can just clone it again.

For transparency, I've attached the script I used, which is a combination of 
writing .git/info/grafts and git-filter-branch. You can run it on your own 
local old repo, and in theory you should even get the same commit SHA1 objects 
out. (But be careful! This will drop the gpg signatures on some old tags, so be 
careful not to push these back out.)

For reference, here's what you should expect the script to output, twice, to 
check that I didn't backdoor the source :)


debian/3.2+dfsg-4+deb7u1 fe8398cfe0b68277b4c95e116e8d37e6b88f5061
debian/3.2+dfsg-4+deb7u2 fb51628bb376ea59c7650a213a698b9c913f2f08
debian/3.2+dfsg-4+deb7u3 2254a4d52ff2338cf803e04a68656ae22571a668
debian/5.2.2+dfsg-1 612b68e1fc65c75cff8e23e860cd7e9d4e67db78
debian/5.2.2+dfsg-2 a7c22e20c5ca1d7d117f6130fac65c445b685361
debian/5.2+dfsg-1 9ea1e23624d0f0e8415ee4f248e7328c355c1e44
debian/sid 4e10242c8786ed237654dc3badfcae13742881a4
debian/wheezy 2254a4d52ff2338cf803e04a68656ae22571a668
dfsg/3.2+dfsg 1e54e2ea03c6729ae01f55771d1a62d8583d8d37
dfsg/6.2+dfsg 8792d5025eaf7babc5d7e79aca52d22f16f69acb
dfsg/7.0+dfsg 0b8deb3e9e47d68def2ea19699bb5faf88169e8c
dfsg/sid 0b8deb3e9e47d68def2ea19699bb5faf88169e8c
dfsg/wheezy 1e54e2ea03c6729ae01f55771d1a62d8583d8d37
upstream/5.2.2+dfsg c5f692769be97e5757fe6f8ee6082ef70c2386b0
upstream/5.2+dfsg 45caacfffe16dd80e9052b0797f588014de4008b
upstream/6.2 53592e714f2a8ff81f4bc0a6ac6153f703beec4b
upstream/7.0 d7604402e323a79dd8275c313c5b2377a3b35b7c
upstream/sid d7604402e323a79dd8275c313c5b2377a3b35b7c


X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git


rewrite-calendarserver-history.sh
Description: application/shellscript


signature.asc
Description: OpenPGP digital signature

Bug#754478: Enable journald support

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 18 January 2016 03:16:25 Diederik de Haas wrote:
[snip]
> That ML msg references https://codereview.qt-project.org/#/c/89357/ of which
> the current status seems to be 'merged in 5.4'.
> 
> Maybe it's time for the recheck?

That patch was meant for OSX. For what I understand if we enable journald 
support people not using systemd will not get logs, and we need to support 
that use case.

-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

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#442363: ITP: php-db-dataobject -- SQL Builder, Object Interface to Database Tables

[Bhuvan Krishna]

retitle 442363 ITP: php-db-dataobject --  SQL Builder, Object Interface
to Database Tables



signature.asc
Description: OpenPGP digital signature

Bug#768079: [Pkg-zsh-devel] Bug#768079: zsh: fails to configure if /bin is a symlink to /usr/bin

[Axel Beckert]

Hi Sven,

Sven Joachim wrote:
> Personally I think zsh should stop using update-alternatives altogether
> now that zsh-beta is history, but this is for the package maintainers to
> decide.

Indeed, thanks for the reminder. I guess this bug report is a good
reason to implement that now.

I'll probably do an upload of a new release candidate to experimental
soon (like this weekend) and will try to fix this issue with that,
too.

I definitely don't want to upload a fix for this bug to unstable
directly as I assume that there will be unexpected side-effects of
such a change.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#812364: RFP: co2mon - CLI for MasterKit CO2 Monitor

[Ivan Borzenkov]

Package: wnpp
Severity: wishlist

* Package name: co2mon
  Version : 2.1.0
  Upstream Author : Oleg Bulatov 
* URL : https://github.com/dmage/co2mon

* License : GPL
  Programming Lang: C
  Description : CLI for MasterKit CO2 Monitor

Bug#812366: linux-image-3.16.0-4-amd64: Kernel panic due to reading /sys/block/bcache?/bcache/writeback_rate_debug (bch_cached_dev_show)

[Dmitry Yu Okunev]

Package: src:linux
Version: 3.16.7-ckt20-1+deb8u1
Severity: normal
Tags: upstream

Hello.

I experienced a bug in module "bcache" of linux kernel (a reduced photo is 
attached, a less reduced photo you can download from [1]).

[1] 
https://devel.mephi.ru/dyokunev/public/raw/master/debian/bugreport/2016/bcache-panic/photo_kernelbug-bch_cached_dev_show.jpg

The server is in production so I have no ability to repeat the bug and I tried 
to recognize a text on the photo (sorry if there're any typos):

[525996.860864] 880c0010 880c84737630 880c84737d40 
880cbdd4a040
[525996.860943] aOSecaeS 0003 0003 
000a
[525996.861023] Call Trace:
{525996.861067] [] ? dump_stack+0x41/0x51
[525996.861108] [] ? panic+0xc8/0x1fc
[525996.861156] [l ? __bch_cached_dev_show+0x505/0x510 
[bcache]
[525996.861225} [] ? __stack_chk_fail+0x17/0x20
[525996.861269) [] ? __bch_cached_dev_show+0x505/0x510 
[bcache]
[525996.861338] [] ? bch_cached_dev_show+0x2c/0x50 [bcache]
[525996.861386] [] ? sysfs_kf_seq_show+0xc4/0x1e0
[525996.861431] [] ? seq_read+0xe2/0x360
[525996.861475] [] ? vfs_read+0x93/0x170
[525996.861514] [] ? SyS_read+0x42/0xa0
[525996.861555] [] ? page_fault+0x28/0x30
[525996.861598] [] ? system_call_fast_compare_end+0x10/0x15
[525996.861686] Kernel Offset: 0x0 from 0x8100 (relocation range: 
0x8000-0x9ff)
[525996.980293] ---[ end Kernel panic - not syncing: stack-protector: Kernel 
stack is corrupted in: a05ec3e5

I googled the issue and found [2]. Indeed I was reading files 
/sys/block/bcache{0,1,2,3}/bcache/writeback_rate_debug every second for 
debugging purposes. I stopped the processes, reading "writeback_rate_debug" and 
the bug didn't appear again.

[2] http://www.spinics.net/lists/linux-bcache/msg03173.html

Seems the bug is related to vanilla kernel code but Debian has own patches on 
the kernel, so I filled this report.

Best regards, Dmitry,
tel. 8 (495) 788-56-99, ext. 8255.

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=598c2749-c8c2-41ff-ac76-056ea007eb9e ro

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Model information
sys_vendor: Supermicro
product_name: SYS-6028R-WTR
product_version: 0123456789
chassis_vendor: Supermicro
chassis_version: 0123456789
bios_vendor: American Megatrends Inc.
bios_version: 1.0c
board_vendor: Supermicro
board_name: X10DRW-i
board_version: 1.02

** Loaded modules:
fuse
btrfs
xor
raid6_pq
ufs
qnx4
hfsplus
hfs
minix
ntfs
vfat
msdos
fat
jfs
xfs
dm_mod
iscsi_trgt(O)
cpuid
md_mod
drbd
lru_cache
libcrc32c
crc32c_generic
crc32c_intel
nfsd
auth_rpcgss
oid_registry
nfs_acl
lockd
sunrpc
fcoe
libfcoe
libfc
scsi_transport_fc
scsi_tgt
8021q
garp
stp
mrp
llc
mlx4_ib
ib_sa
ib_mad
ib_core
ib_addr
mlx4_en
mlx4_core
vxlan
x86_pkg_temp_thermal
intel_powerclamp
intel_rapl
coretemp
kvm_intel
iTCO_wdt
kvm
iTCO_vendor_support
crc32_pclmul
aesni_intel
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
cryptd
joydev
pcspkr
mei_me
lpc_ich
ioatdma
shpchp
mei
i2c_i801
mfd_core
evdev
wmi
tpm_tis
tpm
ipmi_si
ipmi_msghandler
processor
thermal_sys
acpi_power_meter
acpi_pad
button
ext4
crc16
mbcache
jbd2
hid_generic
usbhid
hid
bcache
sg
sd_mod
crc_t10dif
crct10dif_generic
crct10dif_pclmul
crct10dif_common
ahci
libahci
ehci_pci
igb
i2c_algo_bit
xhci_hcd
ehci_hcd
libata
megaraid_sas
i2c_core
dca
usbcore
ptp
scsi_mod
usb_common
pps_core

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Haswell-E DMI2 [8086:2f00] (rev 
02)
Subsystem: Super Micro Computer Inc Device [15d9:0821]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Haswell-E PCI Express Root Port 1 
[8086:2f02] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 PCI bridge [0604]: Intel Corporation Haswell-E PCI Express Root Port 2 
[8086:2f04] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.2 PCI bridge [0604]: Intel Corporation Haswell-E PCI Express Root Port 

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[KSB]

Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.) 
and seems to be gone at least in 4.3

Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

[Andreas Pflug]

Am 21.01.16 um 17:41 schrieb Jan Beulich:
 On 20.01.16 at 16:01,  wrote:
>> Initially reported to debian
>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here:
>>
>> With AMD Opteron 6xxx processors, half of the memory controllers are
>> missing from /sys/devices/system/edac/mc
>> Checked with single 6120 (dual memory controller) and twin 6344 (2x dual
>> MC), other dual-module CPUs might be affected too.
>>
>> Booting plain Linux (3.2, 3.16, 4.1, 4.3), all memory controllers are
>> listed under /sys/devices/system/edac/mc as expected. Same happens, when
>> Xen 4.1 is used: all MCs present.
>>
>> Starting with Xen 4.4 (Debian Jessie), only mc1 (on the single CPU
>> machine) or mc2/mc3 (dual CPU machine) are present, although the full
>> system memory is accessible. Checked versions were 4.1.4 (Debian
>> Wheezy), 4.4.1 (Jessie) and 4.6.0 (Sid)
> As already indicated by Ian in that bug, you should supply us with
> full kernel and hypervisor logs for both the good and bad cases
> (ideally with the same kernel version use in both runs, so that we
> can exclude kernel behavior differences).
Here are some dmesg excerpts, all performed with Linux 4.1.3.

When booting with Xen 4.1.4:

AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV
:00:18.2 (INTERRUPT)
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 1).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV
:00:19.2 (INTERRUPT)

When booting with Xen 4.4.1:

AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will
not load.
 Either enable ECC checking or force module loading by setting
'ecc_enable_override'.
 (Note that use of the override may cause unknown side effects.)
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 1).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV
:00:19.2 (INTERRUPT)

Apparently Xen4.4 doesn't report the BIOS flag correctly. I added
ecc_enable_override=1 to amd64_edac_mod, and then I get

EDAC MC: Ver: 3.0.0
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will
not load.
EDAC amd64: Forcing ECC on!
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV
:00:18.2 (INTERRUPT)
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 1).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV
:00:19.2 (INTERRUPT)

This restored both MCs, so the BIOS flag seems 

Bug#812311: scilab: Scilab Crash with Basic functions (det and inv matrix)

[Sylvestre Ledru]

severity 812311 normal
thanks

Le 22/01/2016 09:19, Mathieu DAGOIS a écrit :
> Package: scilab
> Version: 5.5.2-2
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
I don't think it is making Scilab unusable.
Scilab contains thousand of functions. Here, it is crashing on your system with 
some functions
and data.
I cannot reproduce the bug. Could you check if the bug still occurs if you 
change the blas implementation used?


By the way, please don't dump a script in the content of the email, the syntax 
was broken.
As attachment, the correct file.

Sylvestre



foo.sci
Description: application/scilab-sci

Bug#811473: systemd: timer with WakeSystem=yes doesn't always start the service it's supposed to trigger

[Christian Pernegger]

Hello again,

I just wanted to document a few further observations & things I tried:

* A dummy timer that just sent me mail every hour (but otherwise configured
identically) managed to wake the system up 20 out of 20 times and did send
mail on 18 of these. Sadly, with the backup.service the track record is
more like fifty-fifty.
* replacing ntpdate with systemd-timesyncd (the whole guarantees monotonic
time thing) does not help

Status after a failed run:
chris@mrmackey:~$ sudo systemctl status backup.service
● backup.service - Pulls configured backups
   Loaded: loaded (/etc/systemd/system/backup.service; static)
   Active: inactive (dead)

chris@mrmackey:~$ sudo systemctl status backup.timer
● backup.timer - Wakes the system up once per day for backups
   Loaded: loaded (/etc/systemd/system/backup.timer; enabled)
   Active: active (waiting) since Don 2016-01-21 13:15:53 CET; 21h ago

chris@mrmackey:~$ sudo systemctl list-timers
NEXT LEFT LAST PASSED
UNIT ACTIVATES
Sam 2016-01-23 03:00:00 CET  16h left n/a  n/a
backup.timer backup.service
Sam 2016-01-23 10:06:21 CET  23h left Don 2016-01-21 13:30:30 CET  20h ago
systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
[...]

Workarounds galore, of course, but I'd still prefer this function to work
as documented.

Regards,
Christian Pernegger



On 19 January 2016 at 10:36, Christian Pernegger 
wrote:

> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
>
>
> Hello,
>
> I'm trying to do the following:
> 1) wake up the system every night at 3 am (using a timer unit with
> WakeSystem=yes)
> 2) pull in backups (using a service triggered by the timer unit)
> 3) send it to sleep again (via logind idle timeout)
>
> See attached files backup.timer and backup.service.
>
> Now, step 1 works, it'll always wake up at 3 am, and sometimes
> backup.service will then run as it should, sometimes it won't.
>
> (For completeness' sake: starting backup.service manually always
> works, as does running it on a timer when the machine is already
> up. Same goes for suspend on idle.)
>
> It might be some kind of timing issue but frankly I've no idea where
> to look. The journal doesn't show anything about the timer unit in any
> case, the service unit does get mentioned only because a sudo session
> is opened for it (only when it actually runs).
>
> Regards,
> Christian Pernegger
>
>
>
> -- Package-specific info:
>
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 systemd depends on:
> ii  acl 2.2.52-2
> ii  adduser 3.113+nmu3
> ii  initscripts 2.88dsf-59
> ii  libacl1 2.2.52-2
> ii  libaudit1   1:2.4-1+b1
> ii  libblkid1   2.25.2-6
> ii  libc6   2.19-18+deb8u1
> ii  libcap2 1:2.24-8
> ii  libcap2-bin 1:2.24-8
> ii  libcryptsetup4  2:1.6.6-5
> ii  libgcrypt20 1.6.3-2
> ii  libkmod218-3
> ii  liblzma55.1.1alpha+20120614-2+b3
> ii  libpam0g1.1.8-3.1
> ii  libselinux1 2.3-2
> ii  libsystemd0 215-17+deb8u2
> ii  mount   2.25.2-6
> ii  sysv-rc 2.88dsf-59
> ii  udev215-17+deb8u2
> ii  util-linux  2.25.2-6
>
> Versions of packages systemd recommends:
> ii  dbus1.8.20-0+deb8u1
> ii  libpam-systemd  215-17+deb8u2
>
> Versions of packages systemd suggests:
> pn  systemd-ui  
>
> -- Configuration Files:
> /etc/systemd/journald.conf changed:
> [Journal]
> Storage=persistent
> Compress=no
>
> /etc/systemd/logind.conf changed:
> [Login]
> IdleAction=suspend
> IdleActionSec=30min
>
>
> -- no debconf information
>

Bug#809840: pymol: diff for NMU version 1.7.2.1-2.2

[Gianfranco Costamagna]

Control: tags 809840 + patch
Control: tags 809840 + pending

Dear maintainer,

I've prepared an NMU for pymol (versioned as 1.7.2.1-2.2) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru pymol-1.7.2.1/debian/changelog pymol-1.7.2.1/debian/changelog
--- pymol-1.7.2.1/debian/changelog  2015-08-22 10:03:36.0 +0200
+++ pymol-1.7.2.1/debian/changelog  2016-01-22 11:05:05.0 +0100
@@ -1,3 +1,11 @@
+pymol (1.7.2.1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-0-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #809840)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:04:44 +0100
+
pymol (1.7.2.1-2.1) unstable; urgency=medium

* Non-maintainer upload.
diff -Nru pymol-1.7.2.1/debian/control pymol-1.7.2.1/debian/control
--- pymol-1.7.2.1/debian/control2015-08-22 10:02:34.0 +0200
+++ pymol-1.7.2.1/debian/control2016-01-22 11:04:41.0 +0100
@@ -7,7 +7,7 @@
freeglut3-dev,
libfreetype6-dev,
libglew1.5-dev,
-   libpng12-0-dev,
+   libpng-dev,
python,
python-dev,
python-numpy,

Bug#810194: mrtg: Please update dependency on libpng-dev

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, the package build-depends on
libpng-dev|libpng12-dev

so I think we don't need to change anything right now.

cheers,

G.

On Thu, 07 Jan 2016 09:47:29 +0100 t...@debian.org wrote:
> Package: mrtg Severity: important User: lib...@packages.debian.org 
> Usertags: libpng16-transition
> 
> Dear mrtg maintainers,
> 
> Currently we are preparing the transition of libpng1.2 to
> libpng1.6. The transition bug is #650601.
> 
> A rebuild of all packages depending on libpng-dev and 
> libpng(3,12,12-0)-dev has been done. The result with buildlogs can
> be found here: https://libpng.sviech.de/
> 
> mrtg builds fine with libpng16, you can see the buildlog here: 
> https://libpng.sviech.de/mrtg.build
> 
> Howver, mrtg (build-)depends an versioned development package 
> libpng12-dev. Please update your (build-)depends to libpng-dev to 
> help in the transition.
> 
> This bug will become RC as soon as the transition starts, as it is 
> planned to remove libpng12.
> 
> Thanks! -- tobi
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWogEAAAoJEPNPCXROn13ZnVEP/j6HFix24xjWjGufkSRehFvn
EaqMCvVwbGrjSthFga8+EKf4Ejq66F5SxPgbXJVvufGfJFTD6NGHHGR/7lLXh5lo
Pg0Q98h9HjtzBRQAri5+tCt0T5zH6WLxCC2xQgC8tuxw4M/2VCMOTlElc45XZDi9
Iam3HZg8YAj3RZljZKO7heHqzlFTe+kb7WBez7rfjoXKvpBntMM8JQ2uDt3wiJ/Y
f62GdZlo0Rgqj/07s6pgPar53Qm1MlfOBs4a8mJlRHUQFZLVipE6EFubef2Oku7E
B5JIJfRvYIZrbU4yOvhrD8M7zrBvn5YDyBpt2ihVBxJkGruhNgKfh3J9HegL81By
D7luRFC7IfZ2PXruMfqDlfKHAUBjatDzY/0+9g44yNcDSdDsS+w3t3/ID3m1ki2E
87fN+GExw1tNNedZCW+oFBVOn/fs3RnK0bOaDQN5btPYdmSwoAmjT8qvfUFbn4v/
RT+rCsTpI+nMGKp43WYO1rTVeUWShU4aAH2T57T44zq34JgP5DEVAOxg2UN2YSwb
9ck63Tl8ytQ3n+USCPbocMKnbmZMjWXNs01mi1+aWJiI00iJQfH/n9B5RynhXz0J
57+qcZo/yHprGY/m3PzomNr8W5lo9i5UMcCVD64CNRFXha7VtHQxq16+JlclKJxC
mUSGGzh3r0KjjyTtPf8q
=ARxO
-END PGP SIGNATURE-

Bug#810189: libgd-perl: diff for NMU version 2.53-2.1

[Gianfranco Costamagna]

Control: tags 810189 + patch
Control: tags 810189 + pending


Dear maintainer,

I've prepared an NMU for libgd-perl (versioned as 2.53-2.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru libgd-perl-2.53/debian/changelog libgd-perl-2.53/debian/changelog
--- libgd-perl-2.53/debian/changelog2015-11-30 11:03:20.0 +0100
+++ libgd-perl-2.53/debian/changelog2016-01-22 11:17:09.0 +0100
@@ -1,3 +1,11 @@
+libgd-perl (2.53-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #810189)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:16:53 +0100
+
libgd-perl (2.53-2) unstable; urgency=medium

[ Vasudev Kamath ]
diff -Nru libgd-perl-2.53/debian/control libgd-perl-2.53/debian/control
--- libgd-perl-2.53/debian/control  2015-11-30 11:02:40.0 +0100
+++ libgd-perl-2.53/debian/control  2016-01-22 11:16:51.0 +0100
@@ -12,7 +12,7 @@
dh-buildinfo,
libgd-dev (>= 2) | libgd2-xpm-dev,
libjpeg-dev,
- libpng12-dev,
+ libpng-dev,
libz-dev,
libfreetype6-dev,
libxpm-dev,

Bug#812156: dbconfig-common: talks about 'apparently missing Depends on dbconfig-pgqsl packages' which does not exist

[Paul Gevers]

Hi Andreas,

On 21-01-16 21:49, Andreas Beckmann wrote:
> No, you didn' get the point of this bug. Please install the package by
> copy+pasting the name from the subject :-)
> 
> Andreas
> 
> PS: Query Structured Language

I saw it the moment I hit send. Point was that the bug title was so long
that it didn't fully show in my e-mail reader layout and I expected the
kind of bug reports as I interpreted the bug.

So maybe next time make the subject slightly shorter and less cryptic :).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#662416: libwmf: diff for NMU version 0.2.8.4-10.5

[Gianfranco Costamagna]

Control: tags 662416 + patch
Control: tags 662416 + pending


Dear maintainer,

I've prepared an NMU for libwmf (versioned as 0.2.8.4-10.5) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru libwmf-0.2.8.4/debian/changelog libwmf-0.2.8.4/debian/changelog
--- libwmf-0.2.8.4/debian/changelog 2015-07-31 09:58:05.0 +0200
+++ libwmf-0.2.8.4/debian/changelog 2016-01-22 11:28:55.0 +0100
@@ -1,3 +1,11 @@
+libwmf (0.2.8.4-10.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #662416)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:28:38 +0100
+
libwmf (0.2.8.4-10.4) unstable; urgency=high

* NMU from the Security Team
diff -Nru libwmf-0.2.8.4/debian/control libwmf-0.2.8.4/debian/control
--- libwmf-0.2.8.4/debian/control   2015-07-31 09:58:05.0 +0200
+++ libwmf-0.2.8.4/debian/control   2016-01-22 11:28:36.0 +0100
@@ -13,7 +13,7 @@
libx11-dev,
libexpat1-dev,
libjpeg-dev,
-   libpng12-dev,
+   libpng-dev,
libgtk2.0-dev (>= 2.21.5),
libgdk-pixbuf2.0-dev (>= 2.21.6)

Bug#812320: weechat-plugins: Please upgrade dep of Tcl to 8.6/latest

[Manuel A. Fernandez Montecelo]

Package: weechat-plugins
Severity: wishlist

Hi,

Thanks for maintaining this package!

It would be great if the dependency could be upgraded to the latest version.
weechat-plugins is the only one pulling libtcl8.5 in my system, and I suspect
that --with such a mature language-- the plugins can work with either version.

Cheers.


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

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

Versions of packages weechat-plugins depends on:
ii  guile-2.0-libs 2.0.11+1-10+b1
ii  libaspell150.60.7~20110707-3+b1
ii  libc6  2.21-6
ii  libgc1c2   1:7.4.2-7.3
ii  libgcc11:5.3.1-6
ii  libgcrypt201.6.4-4
ii  libgmp10   2:6.1.0+dfsg-2
ii  libgnutls-deb0-28  3.3.20-1
ii  liblua5.1-05.1.5-8
ii  libperl5.225.22.1-4
ii  libpython2.7   2.7.11-3
ii  libruby2.2 2.2.3-2
ii  libstdc++6 5.3.1-6
ii  libtcl8.5  8.5.18-3
ii  libv8-3.14.5   3.14.5.8-10
ii  weechat-curses 1.4-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

weechat-plugins recommends no packages.

Versions of packages weechat-plugins suggests:
ii  weechat-scripts  20150820-1

-- no debconf information

Bug#810196: libwebp: Please update dependency on libpng-dev

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, the package already have
libpng-dev | libpng12-dev
so I think there is no need to NMU at this time.

cheers,

G.
On Thu, 07 Jan 2016 09:47:29 +0100 t...@debian.org wrote:
> Package: libwebp Severity: important User:
> lib...@packages.debian.org Usertags: libpng16-transition
> 
> Dear libwebp maintainers,
> 
> Currently we are preparing the transition of libpng1.2 to
> libpng1.6. The transition bug is #650601.
> 
> A rebuild of all packages depending on libpng-dev and 
> libpng(3,12,12-0)-dev has been done. The result with buildlogs can
> be found here: https://libpng.sviech.de/
> 
> libwebp builds fine with libpng16, you can see the buildlog here: 
> https://libpng.sviech.de/libwebp.build
> 
> Howver, libwebp (build-)depends an versioned development package 
> libpng12-dev. Please update your (build-)depends to libpng-dev to 
> help in the transition.
> 
> This bug will become RC as soon as the transition starts, as it is 
> planned to remove libpng12.
> 
> Thanks! -- tobi
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWogYPAAoJEPNPCXROn13ZotIP/2pzbKyGIsSab+25/u+GjYjd
/SBMIfejWhAlozBfy/Qp00N594wnRuDAGAsQnMXUVF7FtZjYud1CcQvDALAtqR/i
0+Hj/P0wSoX20Fs0F2v9dfVeXSKP0sLc9mOT2xAlgbaFgAzG0CfZuFHPIH7rBVbS
R9eFLdwxBDJp/aRyYSg5VLAcDF56hFpigPG5CoE4jRMqxvOClQtzL6U8irnd7LhA
LX12cCHLaZ+R7ggSSE+Ksq+sTgpRAfljMLky8hubliFyNfrdPttYTNU2KXIZbaZH
WeKPYBbpwy8ouPI3xMonr9OTcVTqktiwIBG7S1O3OkRCNl5AVwt94VzsEjX2KDdk
HWldLicswuPWv83gl3/QhdANI7QFLXIimYFcZAnHYnMLcf+UXu7KpkI2X32AapNM
NOOOvu0P9TvIZePu/ynN092xeQE/gautUz4bxsM/hpy0egnrAB9+76yXztkOc9iz
T1aJuTzqNwORy7tQfMaQA46cJiGjziBfWJS12fwHSzu0MsSo8fQexEVM+gQMrQkZ
SXjq6/uJFR/0k25E2c1QYCE00Fpwidt7bJwPqlSwGN6htDdRR75e3K8BmKWeYVQ2
gQA+iI+bo4eADO0yqU7ldZUJN4VSAc4cqCfGVhvcqqwaWc+qd8z+YJSyNZLQb/Re
IyCYCrlLZ+dyl3E8KfD1
=P1ck
-END PGP SIGNATURE-

Bug#756479: [Pkg-nagios-devel] Bug#756479: (no subject)

[Alexander Wirt]

On Fri, 22 Jan 2016, Fabien COELHO wrote:

> 
> Hello Alexander,
> 
> 
> ISTM that you did not answer about my point that the current configuration
> file is misleading, as the 'dont_blame_nrpe' option is ignored but there is
> no warning about that fact in the file nor in the log. If it had been the
> case, I would have lost much less time.
Thats another bug in nrpe. 

> 
> >>The "just compile your own package" is a laughable fix: If I wanted to do
> >>that, I would not use Debian in the first place.
> 
> >Stop complaining,
> 
> You may understand that the decision you took to remove a feature was not a
> good one. This feature already had clear caveats that allow admins to make
> an informed decision, as the grownups they are. Mostly.
It was a good one as people stopped complaining against me for getting their
boxes hacked. My life is a lot easier since then.

> 
> >start maintaining packages.
> 
> I already contribute to several free softwares, although not by maintaining
> Debian packages: I cannot do everything, that is life.
> 
> >It is a shame that all those complainers weren't able to build a "fixed"
> >package.
> 
> I know I (probably) can, but then I have to manage de deployment and so, a
> significant effort which should not have been needed in the first place.

Alex

Bug#743391: silly: diff for NMU version 0.1.0-3.3

[Tobias Frost]

Control: tags 743391 + patch
Control: tags 743391 + pending

Dear maintainer,

(Fixing this also in sid)

I've prepared an NMU for silly (versioned as 0.1.0-3.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

-- 
tobi


Regards.
diff -Nru silly-0.1.0/debian/changelog silly-0.1.0/debian/changelog
--- silly-0.1.0/debian/changelog2015-08-05 06:50:19.0 +0200
+++ silly-0.1.0/debian/changelog2016-01-22 11:44:47.0 +0100
@@ -1,3 +1,10 @@
+silly (0.1.0-3.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with libpng1.6 (Closes: #743391)
+
+ -- Tobias Frost   Fri, 22 Jan 2016 11:42:07 +0100
+
 silly (0.1.0-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru silly-0.1.0/debian/patches/02_libpng16.patch 
silly-0.1.0/debian/patches/02_libpng16.patch
--- silly-0.1.0/debian/patches/02_libpng16.patch1970-01-01 
01:00:00.0 +0100
+++ silly-0.1.0/debian/patches/02_libpng16.patch2016-01-22 
11:46:33.0 +0100
@@ -0,0 +1,10 @@
+--- a/src/loaders/SILLYPNGImageLoader.cpp
 b/src/loaders/SILLYPNGImageLoader.cpp
+@@ -40,6 +40,7 @@
+ #endif
+ 
+ #include "loaders/SILLYPNGImageContext.h" 
++#include 
+ #include 
+ // Start section of namespace SILLY
+ namespace SILLY
diff -Nru silly-0.1.0/debian/patches/series silly-0.1.0/debian/patches/series
--- silly-0.1.0/debian/patches/series   2014-10-28 04:19:49.0 +0100
+++ silly-0.1.0/debian/patches/series   2016-01-22 11:45:23.0 +0100
@@ -1,2 +1,3 @@
 01_SILLYPNGImageLoader.patch
 autoreconf-fixups.patch
+02_libpng16.patch

Bug#812322: silly: Please B-D on libpng-dev, not libpng16-dev

[Tobias Frost]

Source: silly
Version: 0.1.0-4
Severity: wishlist

Hi Muammar,

Thanks for fixing silly for libpng1.6 in experimental.
However, I noticed you B-D onl libpng16-dev, which is not optimal for future 
transitions.
Please just use libpng-dev.

Thanks!

-- 
Tobi

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

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

Bug#642265: gdk-pixbuf: diff for NMU version 2.32.3-1.1

[Gianfranco Costamagna]

Control: tags 642265 + pending


Dear maintainer,

I've prepared an NMU for gdk-pixbuf (versioned as 2.32.3-1.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.


Sorry for NMUing the package, but with my ~30 ongoing NMUs, Tobias
great work, and less than 50 FTBFS the transition seems pretty much
in a good state
(of course we have to wait for -release team, but well, I plan to do
this soon after my work finishes)

Regards.

S


diff -Nru gdk-pixbuf-2.32.3/debian/changelog gdk-pixbuf-2.32.3/debian/changelog
--- gdk-pixbuf-2.32.3/debian/changelog  2015-12-15 17:53:42.0 +0100
+++ gdk-pixbuf-2.32.3/debian/changelog  2016-01-22 11:40:01.0 +0100
@@ -1,3 +1,13 @@
+gdk-pixbuf (2.32.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev runtime-dependency to libpng-dev, to ease libpng
+transition.
+- Change also libpng-dev | libpng12-dev build-dependency to
+  libpng-dev | libpng16-dev (Closes: #642265)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:38:50 +0100
+
gdk-pixbuf (2.32.3-1) unstable; urgency=medium

* New upstream release.

Bug#809166: networking.service does not prevent ifdown with network file systems

[Alkis Georgopoulos]

On 21/01/2016 11:10 μμ, Guus Sliepen wrote:

On Fri, Jan 15, 2016 at 09:14:52AM +0100, Guus Sliepen wrote:

ifupdown 0.8.9 can also mark interfaces with the "no-auto-down" keyword,
which causes those interfaces to be ignored during "ifdown -a". This is
a more explicit way to tell an interface should not be brought down
during shutdown. An example:

auto eth0
no-auto-down eth0

iface eth0 inet dhcp
...

I hope this will help.




Perfect, thanks a lot! :)

Bug#810178: argyll: diff for NMU version 1.8.3+repack-1.1

[Gianfranco Costamagna]

Control: tags 810178 + patch


Dear maintainer,

I've prepared an NMU for argyll (versioned as 1.8.3+repack-1.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru argyll-1.8.3+repack/debian/changelog 
argyll-1.8.3+repack/debian/changelog
--- argyll-1.8.3+repack/debian/changelog2015-11-06 09:16:35.0 
+0100
+++ argyll-1.8.3+repack/debian/changelog2016-01-22 11:58:36.0 
+0100
@@ -1,3 +1,11 @@
+argyll (1.8.3+repack-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #810178)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:58:21 +0100
+
argyll (1.8.3+repack-1) unstable; urgency=medium

* New upstream release.
diff -Nru argyll-1.8.3+repack/debian/control argyll-1.8.3+repack/debian/control
--- argyll-1.8.3+repack/debian/control  2015-09-30 14:44:37.0 +0200
+++ argyll-1.8.3+repack/debian/control  2016-01-22 11:58:16.0 +0100
@@ -10,7 +10,7 @@
jam,
libjpeg-dev,
libssl-dev,
- libpng12-dev,
+ libpng-dev,
libtiff5-dev,
libtool,
libusb-dev,

Bug#741223: [Vmdebootstrap-devel] Bug#741223: Simplified patch

[Neil Williams]

On Fri, 22 Jan 2016 01:06:47 +0530
Sunil Mohan Adapa  wrote:

> Hello,
> 
> The attached patch does the following:
> 
> - Do not pass errors=remount-ro mount flag for btrfs filesystems.
> Btrfs has this behavior by default and does not support the flag.
> 
> - Add test scenario for btrfs.  Check filesystem type and fstab entry.
> 
> - Expand ext4 test to check for expected fstab entry.
> 
> I re-ran all tests and successfully booted an image built with grub.
> The extlinux image had problem booting however.

This is a much improved patch, thank you. I'll do some investigation of
extlinux support this weekend, it doesn't look this patch should be
causing a problem there.

I expect this support to be implemented in the next vmdebootstrap
release, (1.4).

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpGdaZRLYOeM.pgp
Description: OpenPGP digital signature

Bug#812082: Fwd: Bug#812082: rubber: always recompile

[Preuße]

On 21.01.2016 04:50, Sebastian Kapfer wrote:

Hi,

should I package that branch for experimental?

Hilmar

> If you're curious, you can have a look at this branch:
> https://github.com/skapfer/rubber/tree/preview
> 
> This should not recompile all the time, but has received little testing so 
> far.
> Bug reports welcome!
> 
> Cheers,
>   Sebastian
> 
> On Thu, Jan 21, 2016 at 01:34:30AM +0100, Sebastian Kapfer wrote:
>>
>> Hi,
>>
>> Rubber currently is in overcautious mode since the widely distributed 1.1
>> release missed rebuilds in a lot of cases and cause quite some user
>> frustration.  Since then, I've been working on rewriting the dependency 
>> code, a
>> transition which is not quite complete.
>>
>> As a result, one compilation is currently always forced.  We're close to 
>> fixing
>> everything up (BibTeX was a huge mess) - this limitation might well be gone 
>> for
>> the 1.5 release.
>>
>> @Hilmar The linked patch does not fix this.  It just provides more detailed
>> messages.  It's worth applying though, same as the other change since 1.4.
>> Both are harmless fixes unlikely to break something.
>>
>> Cheers
>>   Sebastian
>>
>>
>>
>> On Wed, Jan 20, 2016 at 10:19:05PM +0100, Preuße, Hilmar wrote:
>>> Hallo Sebastian,
>>>
>>> eine gesundes neues Jahr!
>>>
>>> ich habe einen neuen Case rein bekommen. rubber macht einen Rebuild, obwohl 
>>> sich
>>> an den Source-File nicht geändert hat. Ja, in den release Notes steht, daß
>>> rubber derzeit lieber einmal zuviel, als einmal zuwenig compiliert, aber im
>>> aktuellen Fall scheint rubber gar keine Zeitstempel zu prüfen.
>>>
>>> Das würde ich mal als nicht FAD qualifizieren. Hilft mir
>>> https://git.launchpad.net/rubber/patch/?id=8871e6d40213b63668f34bcd148c30a36a79933a
>>> weiter?
>>>
>>> Hilmar
>>> -- 
>>> sigfault
>>
>>> Date: Wed, 20 Jan 2016 12:22:52 +0100
>>> From: "r.ductor" 
>>> To: Debian Bug Tracking System 
>>> Subject: Bug#812082: rubber: always recompile
>>> X-Mailer: reportbug 6.6.5
>>>
>>> Package: rubber
>>> Version: 1.4-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> It is important (for me) to check that the document stack is updated 
>>> without unnecessaryly recompile.
>>>
>>> In previous versions, when the modification time of the dependencies was in 
>>> the correct order,
>>> rubber output "nothing to do for ...".
>>>
>>> This feature seems lost ("running ps2pdf") and rubber seems to recompile 
>>> without necessity. See example below.
>>>
>>> Thanks for your time.
>>> r.
>>>
>>> $ date && ls -lt --time-style=full-iso && rubber -pd -vvv bug 
>>> Wed Jan 20 12:11:33 CET 2016
>>> total 196
>>> -rw-r--r-- 1 anonymous anonymous  21547 2016-01-20 12:10:49.190190490 +0100 
>>> bug.pdf
>>> -rw-r--r-- 1 anonymous anonymous 159509 2016-01-20 12:10:49.090187074 +0100 
>>> bug.ps
>>> -rw-r--r-- 1 anonymous anonymous279 2016-01-20 12:10:49.022184750 +0100 
>>> bug.aux
>>> -rw-r--r-- 1 anonymous anonymous   1096 2016-01-20 12:10:49.022184750 +0100 
>>> bug.dvi
>>> -rw-r--r-- 1 anonymous anonymous   2546 2016-01-20 12:10:49.022184750 +0100 
>>> bug.log
>>> -rw-r--r-- 1 anonymous anonymous463 2016-01-20 12:06:54.590175830 +0100 
>>> bug.tex
>>> This is Rubber version 1.4.
>>> [latex] parsing /home/anonymous/CACCA/bug-rubber/bug.tex
>>> [latex] script module article registered
>>> [latex] end of /home/anonymous/CACCA/bug-rubber/bug.tex
>>> [latex] dependencies: ['bug.aux', 
>>> '/home/anonymous/CACCA/bug-rubber/bug.tex']
>>> [latex] directive: module dvips
>>> [latex] built-in module dvips registered
>>> [latex] directive: module ps2pdf
>>> [latex] built-in module ps2pdf registered
>>> [depend] make bug.pdf -> ['bug.ps']
>>> [depend] make bug.ps -> ['bug.dvi']
>>> [depend] make bug.dvi -> ['bug.aux', 
>>> '/home/anonymous/CACCA/bug-rubber/bug.tex']
>>> [depend] while making bug.dvi: cyclic dependency on bug.aux (pruned)
>>> [latex] building additional files...
>>> compiling bug.tex...
>>> executing: latex \nonstopmode \input{bug.tex}
>>>   with environment: {'TEXINPUTS': '.:.:'}
>>> process 3244 (latex) returned 0
>>> [latex] running post-compilation scripts...
>>> [depend] while making bug.dvi: cyclic dependency on bug.aux (pruned)
>>> [depend] while making bug.dvi: contents of bug.aux unchanged, ignoring mtime
>>> [depend] while making bug.ps: timestamp of dependency bug.dvi changed, 
>>> rebuilding
>>> executing: dvips bug.dvi
>>> process 3246 (dvips) returned 0
>>> [depend] make bug.dvi -> ['bug.aux', 
>>> '/home/anonymous/CACCA/bug-rubber/bug.tex']
>>> [depend] while making bug.dvi: cyclic dependency on bug.aux (pruned)
>>> [depend] while making bug.dvi: contents of bug.aux unchanged, ignoring mtime
>>> [depend] while making bug.pdf: timestamp of dependency bug.ps changed, 
>>> rebuilding
>>> running: ps2pdf bug.ps bug.pdf...
>>> [depend] make bug.ps -> ['bug.dvi']
>>> [depend] make bug.dvi -> ['bug.aux', 
>>> '/home/anonymous/CACCA/bug-rubber/bug.tex']
>>> [depend] while 

Bug#576319: [Aptitude-devel] Bug#576319: Bug#576319: aptitude: "Cancel pending actions" erase "h - hold" state

[Axel Beckert]

Hi,

Ralf Jung wrote:
> > I am going to fix this by making "Cancel pending actions" to reload the
> > cache, which is roughly equivalent to restart the program without
> > exiting and starting again (effectively forgetting all what was marked
> > in this session).
> > 
> > I think that this is more consistent with "Cancel pending actions" as
> > described by the original report and other users, than the previous
> > behaviour -- removing all holds and auto-installed flags of all packages
> > in the system, even if they had not been changed in this session.
> 
> Does this mean that if there is an action stored in the cache, that
> action would not be canceled? I think that would also be confusing.

I agree with Ralf here. Cancel pending actions should also cancel all
scheduled actions which have been scheduled in previous aptitude runs,
too.

I'm though not sure if by "cache" you mean apt's cache (which would
include holds, but not aptitude's scheduled actions) or aptitude's
extended states file (which would include both).

In the latter case, please note that such things happen as

1. Start TUI
2. Schedule some actions
3. gg -> Start downloading files -- this saves the extended states
4. q -> Abort download
5. Cancel pending actions

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#678081: libsvn-perl: Assertion `svn_dirent_is_canonical(base, pool)' failed with SVN::Client

[Vincent Lefevre]

On 2016-01-21 21:19:29 -0500, James McCoy wrote:
> Yes, the wrong data is the non-canonical path '.'.  Nearly all SVN
> functions want to work with a canonical path/URL, so you'll probably
> want to reference the svn_path documentation:
> https://subversion.apache.org/docs/api/latest/svn__path_8h.html#details

OK, I suppose that this was actually a bug in the documentation,
fixed in libsvn-perl 1.9.0-1. This is now described in the
SVN::Client(3perl) man page:

   $path
   This is a path to a file or directory on the local file system.
   Paths need to be canonicalized before being passed into the
   Subversion APIs.  Paths on the local file system are called dirents
   and can be canonicalized by calling
   "SVN::Core::dirent_canonicalize".

but with up to libsvn-perl 1.8.9-2, one has only:

   $path
   This is a path to a file or directory on the local file system.

> > Note: I'm not sure that the program is correct (the SVN::Client
> > man page doesn't have many details),
> 
> The language bindings closely follow the C API, so you're best off just
> referencing that: https://subversion.apache.org/docs/api/latest/

IMHO, the main points must be found in the man page.

> > but even if it isn't, one
> > should never get an assertion failure in Perl.
> 
> Why not?  The library is asserting the contract of its API.  The Perl
> script is violating that contract, so it triggers the assertion.

That's C. In Perl, the user should be protected against undefined
behavior like buffer overflows and so on, and errors should be
reported in one of the Perl ways. This is up to the Perl module
to sanitize the arguments.

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

Bug#812316: request-tracker4 has circular Depends with rt4-fcgi

[Bill Allombert]

Package: rt4-fcgi
Version: 4.2.12-5
Severity: important

Hello Debian Request Tracker Group,

There is a circular dependency between request-tracker4 and rt4-fcgi:

request-tracker4:Depends: rt4-standalone (= 4.2.12-5) | rt4-apache2 (= 
4.2.12-5) | rt4-fcgi (= 4.2.12-5)
rt4-fcgi:Depends: request-tracker4

Circular dependencies are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

In this case, I do not think rt4-fcgi actually need to depend on
request-tracker4.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#812317: [python-botocore] debian/copyright doesn't match upstream license (MIT vs Apache)

[Török Edwin]

Package: python-botocore
Version: 1.3.9-1
Severity: normal

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

debian/copyright for python-botocore-1.3.9 says: License: MIT
The included LICENSE.txt says Apache 2.0.

Here is the upstream commit changing the license:
https://github.com/boto/botocore/commit/c27876601641a6c319e39ddc0b4d206e84719d1c

Please update debian/copyright

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.3.0-0.bpo.1-amd64

Debian Release: 8.2
  600 stable  security.debian.org 
  600 stable  ftp.iasi.roedu.net 
  600 jessie-backports ftp.iasi.roedu.net 
  500 unstableftp.iasi.roedu.net 
  500 testing ftp.iasi.roedu.net 
  500 stable-updates  ftp.iasi.roedu.net 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

-- 
Edwin Török | Co-founder and Lead Developer

Skylable open-source object storage: reliable, fast, secure
http://www.skylable.com

Bug#811219: transition: netcdf

[Sebastiaan Couwenberg]

On 21-01-16 20:17, Sebastiaan Couwenberg wrote:
> On 21-01-16 11:20, Emilio Pozuelo Monfort wrote:
>> On 17/01/16 00:32, Bas Couwenberg wrote:
>>> NetCDF 4.4.0 final has been released and bumps the SOVERSION to 11
>>> accounting for the removed symbols in RC4. Fortunately we only have to
>>> transition netcdf, and not also the C++ & Fortran packages. Only a few
>>> packages FTBFS:
>>>
>>> minc (2.2.00-6) FTBFS, this is the same issue as the for the previous
>>> netcdf transition (#793885), which has been fixed in libminc, but not minc.
>>>
>>> python-scientific (2.9.4-3) FTBFS due to an old issue too (#799195).
>>>
>>> mmtk (2.7.9-1) FTBFS due to #798665, and requires python-scientific.
>>>
>>> These packages are sid-only already, so shouldn't be much of an issue
>>> for this transition.
>>
>> I was waiting for the python3 transition, which is now done. So go ahead.
> 
> Thanks. I've just uploaded netcdf (1:4.4.0-1) to unstable.

netcdf-cxx, netcdf-cxx-legacy, netcdf-fortran & netcdf4-python have
already been rebuilt with netcdf (1:4.4.0-1) on the release architectures.

The transition tracker does still need to be updated to also mark the
packages still depending on the netcdf (1:4.1.3-7.2) from the previous
transitions. Using the attached ben configuration (or the one in the
initial bugreport) will also include gerris, kst, minc & mmtk in the
tracker.

minc & mmtk both FTBFS and are sid-only as noted before.

gerris links to netcdf but the resulting packages don't depend on any
netcdf packages.

kst doesn't detect the new netcdf libraries any more, and disables the
netcdf plugin because of that.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
title = "netcdf";
is_affected = (.build-depends ~ /libnetcdf-dev/)|(.depends ~ 
/libnetcdfc?(7|11)/);
is_good = .depends ~ /libnetcdf11/;
is_bad = .depends ~ /libnetcdfc?7/;
notes = "#811219";

Bug#812318: libsvn-perl: SVN::Core::dirent_canonicalize segfaults on undef

[Vincent Lefevre]

Package: libsvn-perl
Version: 1.9.3-2
Severity: important

$ perl -MSVN::Core -e 'SVN::Core::dirent_canonicalize(undef)'
zsh: segmentation fault (core dumped)  perl -MSVN::Core -e 
'SVN::Core::dirent_canonicalize(undef)'

In case of undef, I suppose that the Perl module should pass the empty
string to the library (for which there are no errors), or return some
other kind of error.

I have not tried other kinds of arguments, but in any case, the
module should make sure that a valid string is passed to the
library.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 libsvn-perl depends on:
ii  libapr1 1.5.2-3
ii  libc6   2.21-6
ii  libsvn1 1.9.3-2
ii  perl5.22.1-4
ii  perl-base [perlapi-5.22.1]  5.22.1-4

libsvn-perl recommends no packages.

libsvn-perl suggests no packages.

-- no debconf information

Bug#810188: ipe: diff for NMU version 7.1.10-1.1

[Gianfranco Costamagna]

Control: tags 810188 + patch
Control: tags 810188 + pending


Dear maintainer,

I've prepared an NMU for ipe (versioned as 7.1.10-1.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru ipe-7.1.10/debian/changelog ipe-7.1.10/debian/changelog
--- ipe-7.1.10/debian/changelog 2015-11-21 18:11:39.0 +0100
+++ ipe-7.1.10/debian/changelog 2016-01-22 11:09:49.0 +0100
@@ -1,3 +1,11 @@
+ipe (7.1.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #810188)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:09:34 +0100
+
ipe (7.1.10-1) unstable; urgency=medium

* New upstream.
diff -Nru ipe-7.1.10/debian/control ipe-7.1.10/debian/control
--- ipe-7.1.10/debian/control   2015-11-21 14:58:27.0 +0100
+++ ipe-7.1.10/debian/control   2016-01-22 11:09:31.0 +0100
@@ -14,7 +14,7 @@
libfreetype6-dev (>= 2.3.9),
libcairo2-dev,
libjpeg8-dev,
-  libpng12-dev,
+  libpng-dev,
liblua5.2-dev,
gsfonts
Build-Conflicts: libipe1-dev

Bug#810172: indigo: diff for NMU version 1.1.12-1.1

[Gianfranco Costamagna]

Control: tags 810172 + patch
Control: tags 810172 + pending


Dear maintainer,

I've prepared an NMU for indigo (versioned as 1.1.12-1.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru indigo-1.1.12/debian/changelog indigo-1.1.12/debian/changelog
--- indigo-1.1.12/debian/changelog  2014-02-11 22:35:37.0 +0100
+++ indigo-1.1.12/debian/changelog  2016-01-22 11:15:06.0 +0100
@@ -1,3 +1,11 @@
+indigo (1.1.12-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #810172)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:14:50 +0100
+
indigo (1.1.12-1) unstable; urgency=low

* New upstream release.
diff -Nru indigo-1.1.12/debian/control indigo-1.1.12/debian/control
--- indigo-1.1.12/debian/control2013-12-29 14:15:32.0 +0100
+++ indigo-1.1.12/debian/control2016-01-22 11:14:48.0 +0100
@@ -11,7 +11,7 @@
libcairo2-dev,
libfreetype6-dev,
libjna-java,
-   libpng12-dev,
+   libpng-dev,
libtinyxml-dev,
python (>= 2.6.6-3~)
Standards-Version: 3.9.5

Bug#756479: [Pkg-nagios-devel] Bug#756479: (no subject)

[Alexander Wirt]

On Fri, 22 Jan 2016, Fabien COELHO wrote:

> 
> Sigh. I've lost 1 hour on this "improvement".
> 
> Please note that there is still a bug: the installed "/etc/nagios/nrpe.cfg"
> configuration file now contains a option which is ignored, but AFAICS there
> is no warning about that fact in the file nor in the log when starting nrpe,
> so people will keep trying to enable it and fail without understanding that
> it is in fact ignored.
> 
> >nrpe has several, not fixable security problems with argument parsing.
> 
> I do believe that.
> 
> >You should not use it at all.
> 
> You do *NOT* know about other people context and balance of risks.
> 
> Debian is for grownups, you do not have to "decide" for us as if we were
> children. I know my risks and benefits, and I can make the decision whether
> to enable arguments or not, you do not have to take this decision for me.
> The option name says it all "dont_blame_nrpe": *MY* responsability, not
> yours.
> 
> >A secure alternative would be to use check_by_ssh.
> 
> I disagree that using check_by_ssh is obviously better, because it means
> allowing a shell access and a private key without password on the server, or
> endless efforts to maintain some ssh-agent somewhere which have their own
> risks... I'm not sure I can see how this is much better than nrpe with
> arguments and IP control, for me this is the same.
> 
> The "just compile your own package" is a laughable fix: If I wanted to do
> that, I would not use Debian in the first place.
Stop complaining, start maintaining packages. It is a shame that all those
complainers weren't able to build a "fixed" package.

Alex

Bug#810186: kodi: diff for NMU version 15.2+dfsg1-1.1

[Gianfranco Costamagna]

Control: tags 810186 + patch
Control: tags 810186 + pending


Dear maintainer,

I've prepared an NMU for kodi (versioned as 15.2+dfsg1-1.1) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru kodi-15.2+dfsg1/debian/changelog kodi-15.2+dfsg1/debian/changelog
--- kodi-15.2+dfsg1/debian/changelog2015-11-06 16:09:00.0 +0100
+++ kodi-15.2+dfsg1/debian/changelog2016-01-22 11:21:15.0 +0100
@@ -1,3 +1,11 @@
+kodi (15.2+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev|libpng-dev build-dependency to the opposite, to
+ease libpng transition. (Closes: #810186)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:20:42 +0100
+
kodi (15.2+dfsg1-1) unstable; urgency=medium

[ Balint Reczey ]
diff -Nru kodi-15.2+dfsg1/debian/control kodi-15.2+dfsg1/debian/control
--- kodi-15.2+dfsg1/debian/control  2015-11-06 16:09:00.0 +0100
+++ kodi-15.2+dfsg1/debian/control  2016-01-22 11:20:39.0 +0100
@@ -73,7 +73,7 @@
libomxil-bellagio-dev [armel armhf mipsel mips],
libpcre3-dev,
libplist-dev,
- libpng12-dev | libpng-dev,
+ libpng-dev | libpng12-dev,
libpostproc-dev (>= 7:2.7.1),
libpulse-dev,
librtmp-dev,

Bug#662465: photoprint: diff for NMU version 0.4.2~pre2-2.4

[Gianfranco Costamagna]

Control: tags -1 patch
Control: tags -1 pending

Dear maintainer,

I've prepared an NMU for photoprint (versioned as 0.4.2~pre2-2.4) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru photoprint-0.4.2~pre2/debian/changelog 
photoprint-0.4.2~pre2/debian/changelog
--- photoprint-0.4.2~pre2/debian/changelog  2014-09-07 20:30:00.0 
+0200
+++ photoprint-0.4.2~pre2/debian/changelog  2016-01-22 11:23:37.0 
+0100
@@ -1,3 +1,11 @@
+photoprint (0.4.2~pre2-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
+transition. (Closes: #810200, Closes: #662465)
+
+ -- Gianfranco Costamagna   Fri, 22 Jan 2016 
11:23:01 +0100
+
photoprint (0.4.2~pre2-2.3) unstable; urgency=medium

* Non-maintainer upload.
diff -Nru photoprint-0.4.2~pre2/debian/control 
photoprint-0.4.2~pre2/debian/control
--- photoprint-0.4.2~pre2/debian/control2014-09-07 20:22:38.0 
+0200
+++ photoprint-0.4.2~pre2/debian/control2016-01-22 11:22:59.0 
+0100
@@ -2,7 +2,7 @@
Section: graphics
Priority: optional
Maintainer: David Stone 
-Build-Depends: debhelper (>= 7), libgtk2.0-dev, liblcms2-dev, libpng12-dev, 
libtiff-dev, libnetpbm10-dev, libgutenprint-dev, chrpath, automake, libtool, 
autopoint
+Build-Depends: debhelper (>= 7), libgtk2.0-dev, liblcms2-dev, libpng-dev, 
libtiff-dev, libnetpbm10-dev, libgutenprint-dev, chrpath, automake, libtool, 
autopoint
Standards-Version: 3.9.2
Homepage: 
http://blackfiveimaging.co.uk/index.php?article=02Software%2F01PhotoPrint

Bug#756479: [Pkg-nagios-devel] Bug#756479: (no subject)

[Fabien COELHO]

Sigh. I've lost 1 hour on this "improvement".

Please note that there is still a bug: the installed 
"/etc/nagios/nrpe.cfg" configuration file now contains a option which is 
ignored, but AFAICS there is no warning about that fact in the file nor in 
the log when starting nrpe, so people will keep trying to enable it and 
fail without understanding that it is in fact ignored.



nrpe has several, not fixable security problems with argument parsing.


I do believe that.


You should not use it at all.


You do *NOT* know about other people context and balance of risks.

Debian is for grownups, you do not have to "decide" for us as if we were 
children. I know my risks and benefits, and I can make the decision 
whether to enable arguments or not, you do not have to take this decision 
for me. The option name says it all "dont_blame_nrpe": *MY* 
responsability, not yours.



A secure alternative would be to use check_by_ssh.


I disagree that using check_by_ssh is obviously better, because it means 
allowing a shell access and a private key without password on the server, 
or endless efforts to maintain some ssh-agent somewhere which have their 
own risks... I'm not sure I can see how this is much better than nrpe with 
arguments and IP control, for me this is the same.


The "just compile your own package" is a laughable fix: If I wanted to do 
that, I would not use Debian in the first place.


--
Fabien.

Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

[Jan Beulich]

>>> On 22.01.16 at 10:09,  wrote:
> When booting with Xen 4.4.1:
> 
> AMD64 EDAC driver v3.4.0
> EDAC amd64: DRAM ECC enabled.
> EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.

I wonder how valid his message is. We actually write this MSR with
all ones during boot.

However, considering involved functions like
nb_mce_bank_enabled_on_node() or node_to_amd_nb() taking
node IDs as inputs, and considering that PV guests (including
Dom0) don't have a topology matching that of the host, I doubt
very much that this driver is even remotely prepared to run
under Xen. It working on Xen 4.1.x would then be by pure
accident.

Jan

Bug#809166: networking.service does not prevent ifdown with network file systems

[Martin Pitt]

Hey Guus,

Guus Sliepen [2016-01-21 22:10 +0100]:
> ifupdown version 0.8.9 will not bring the link down of manual interfaces
> during shutdown (but every "down" and "post-down" keyword is still
> executed).
> 
> ifupdown 0.8.9 can also mark interfaces with the "no-auto-down" keyword,
> which causes those interfaces to be ignored during "ifdown -a".

Great, thanks Guus!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#810206: swfmill: Please update dependency on libpng-dev

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, the package already have libpng-dev | libpng12-dev, so I don't
think there is an issue right now.

cheers,

Gianfranco

On Thu, 07 Jan 2016 10:19:28 +0100 t...@debian.org wrote:
> Package: swfmill Severity: important User:
> lib...@packages.debian.org Usertags: libpng16-transition
> 
> Dear swfmill maintainers,
> 
> Currently we are preparing the transition of libpng1.2 to
> libpng1.6. The transition bug is #650601.
> 
> A rebuild of all packages depending on libpng-dev and 
> libpng(3,12,12-0)-dev has been done. The result with buildlogs can
> be found here: https://libpng.sviech.de/
> 
> swfmill builds fine with libpng16, you can see the buildlog here: 
> https://libpng.sviech.de/swfmill.build
> 
> Howver, swfmill (build-)depends an versioned development package 
> libpng12-dev. Please update your (build-)depends to libpng-dev to 
> help in the transition.
> 
> This bug will become RC as soon as the transition starts, as it is 
> planned to remove libpng12.
> 
> Thanks! -- tobi
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWogukAAoJEPNPCXROn13ZUVUP+wcusoIsLUJ0Z97UbTeHoEcJ
kvRRXc/THdYiv4qsCdyjEdi56V5LD1WsvxYjfjUr9HfFzJi1/zGoG99FBFiyQUIg
WDuVeu1Az5zetHz1ZXy+bUrw2Y0+RwOJKgEGbpFHSNQlBlXSBBIe9iWQmsb/O3wf
+o+knJpWxcZz41AnqmcKkzgApABoVwT47h4cN9xNTPuGYsr/hIg8glin2sPKyVE2
pkHYkzMqoa7J6cIGFEBhGo/YslXMc4PZuo69tVjBjRXOv6QTzWc5c/JUyZAmz4pB
YfIVW0zTVNcnmFKjvCCi05xV9AbL8/FXULkaSvopfDirpVdmsQjlwEz+NWDA9wtD
nJiWhc7UMA2AZLPxfQZkWEAlX2sTpOKbxLjaMirQpYTmBS+08aI+RK4EKs2Y+G7o
RkK95KBtE5ztk60D/bXwJ5zf+m6KH8hJ1C5Dp1tZSdNulEVwFSNUaaqw2FjBuOdW
YgzJaoWZU813Y2cJUzJ7g9d8mipr6XQqLi7lyeW+aw8xh8+ZSTdSBrMwJCHVq+qb
YWwTyesfyxC+JVsKhy2JwD7KZfLdzaPUzaODRU6qng9ZJbdQ/WvhAIrgCrTRnqhh
zraSbpt5LQ4WDdQ+dPwOODyWwsLKJxTgOSk6aSWOooaBrQOjhrT7YeHZg7tu1biM
LmOmZSUe6V9XNJ8OAbYV
=CHiG
-END PGP SIGNATURE-

Bug#808739: yoshimi: FTBFS: Missing cmGeneratorTarget instance!

[Will Godfrey]

We have released yoshimi-1.3.8.2 which has a workaround to avoid this problem
by no longer using fltk_wrap_ui to generate build files.

Please update to this as soon as possible.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.

Bug#812319: wine: FTBFS on amd64 and arm64

[Boris Pek]

Source: wine
Version: 1.8-5
Severity: serious
Justification: fails to build from source


Dear Maintainer,

wine/1.8-5 fails to build on amd64 and arm64:
https://buildd.debian.org/status/fetch.php?pkg=wine=amd64=1.8-5=1453164865
https://buildd.debian.org/status/fetch.php?pkg=wine=arm64=1.8-5=1453168393

wine/1.8-4 is successfully built on them. Unfortunately, you forgot to push
recent commits into git repo, so I could not find the problematic changes
immediately. Maybe I'll look deeply later.

Best regards,
Boris

Bug#809833: xaos: diff for NMU version 3.5+ds1-3.1

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags -1 pending

Hi, I'm uploading right now to deferred/6, please let me know if I
have to delay any longer, or cancel it.

cheers,

Gianfranco

On Wed, 06 Jan 2016 17:25:35 +0100 Tobias Frost  wrote:
> Control: tags 809833 + patch
> 
> Dear maintainer,
> 
> I've prepared a patch for the libpng16. Please check and apply if
> you're happy with it.
> 
> Thanks!
> 
> 
> Regards.
> 
> -- tobi
> 
> diff -Nru xaos-3.5+ds1/debian/changelog
> xaos-3.5+ds1/debian/changelog --- xaos-3.5+ds1/debian/changelog
> 2015-12-08 10:09:59.0 +0100 +++
> xaos-3.5+ds1/debian/changelog 2016-01-06 14:52:06.0 +0100 
> @@ -1,3 +1,10 @@ +xaos (3.5+ds1-3.1) UNRELEASED; urgency=medium + +
> * Non-maintainer upload. +  * Update B-D from libpng3-dev to
> libpng-dev (Closes: 809833) + + -- Tobias Frost 
> Wed, 06 Jan 2016 14:51:30 +0100 + xaos (3.5+ds1-3) unstable;
> urgency=medium
> 
> * Build-Depend on libgsl-dev instead of libgsl0-dev. (Closes:
> #807230) diff -Nru xaos-3.5+ds1/debian/control
> xaos-3.5+ds1/debian/control --- xaos-3.5+ds1/debian/control
> 2015-12-08 10:09:59.0 +0100 +++ xaos-3.5+ds1/debian/control
> 2016-01-06 14:52:22.0 +0100 @@ -1,7 +1,7 @@ Source: xaos 
> Section: graphics Priority: optional -Build-Depends: debhelper (>=
> 7.0.50~), libaa1-dev, libx11-dev, libpng3-dev, zlib1g-dev,
> libxext-dev, x11proto-core-dev, autoconf (>= 2.63), autotools-dev,
> libtool, libgsl-dev +Build-Depends: debhelper (>= 7.0.50~),
> libaa1-dev, libx11-dev, libpng-dev, zlib1g-dev, libxext-dev,
> x11proto-core-dev, autoconf (>= 2.63), autotools-dev, libtool,
> libgsl-dev Maintainer: Debian Games Team
>  Uploaders: Ansgar
> Burchardt  Standards-Version: 3.8.4 diff -Nru
> xaos-3.5+ds1/debian/patches/libpng16.patch
> xaos-3.5+ds1/debian/patches/libpng16.patch ---
> xaos-3.5+ds1/debian/patches/libpng16.patch1970-01-01
> 01:00:00.0 +0100 +++
> xaos-3.5+ds1/debian/patches/libpng16.patch2016-01-06
> 17:16:17.0 +0100 @@ -0,0 +1,146 @@ +--- a/src/util/png.c 
>  b/src/util/png.c +@@ -2,6 +2,8 @@ + #ifndef _plan9_ + #include
>  + #ifdef USE_PNG ++#include  ++#include
>  + #include  + #endif + #include  +@@
> -59,15 +61,48 @@ +png_destroy_write_struct(_ptr, (png_infopp)
> NULL); +  return "No memory to create png info structure"; + }
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWof96AAoJEPNPCXROn13ZpJ4P+gNyNEhgQHTXq2GA92UhSdoa
uMyHU6+CGXK2ZFQompPZ/2nTRi/5MljlwqvmNdgDI27b1V1yTjXa6yy8nDQyaDqW
yz5ByZz27nPWqMnq3Aaa/5sSQ9QjxJE0r0tV2ZQXywdcSLPxKfOFzf18gPgZe8e2
MGpMd9Wf8FgvmDzNoix5oIFBFpdZ/1yiMchiC/4FPSZL1Hxf932I5JAliNAm2JS8
ya+RegZ/7Wo+gPXonBpKRTcNPw/Mj0VxMQALu34o/J6bf3GuCHXCk71zVa9qJ628
UYNyTDsrn8g4BTNiKexpNtwgly9I1T8Ee9tyqrq55XIIb1kmphW1pHaTE8pOPYNG
qigoh4AR3ofPgnX4pKMQ8FsALYqASIp/DZdBuHIScOVwuDkLYq+1NOrArXRasmsX
kRCYMxTW46L19gZ4q7VRdugWHM6PVgLq+uHBFJuJmrSftDBG4jYGYiweQS93znHR
6I1oJcu6Tp4LxBKfEfLmIZE5SxqzNjvBm1wGlF146Hujdu2FaeoKmwoJ1hwAy8t0
I+st19hokPELeUkB1Wgi6uZaQk1DPXyxMcbGGMZrq/iiyTSd+yuSjzOk/1immXvm
0E7ajNBILtTTBfbyjn1VWhr1Lf37Cyv5bLKZgX0qeLpCSQ9xzj9qGchNPClT8W/K
bNqjKK/qZPEi0J1x2jv6
=MxPs
-END PGP SIGNATURE-

Bug#812107: nvidia uvm invalid argument

[Pascal Obry]

Hello Andreas,

> *How* do you load the module?

I'm not loading the module myself actually.

> The correct way would be
>
>   modprobe nvidia-uvm
>
> disregarding any "current" or "legacy-*" in the name.

Ok, same error anyway.

The error is reported by darktable when starting for example. I had
tried to reproduce the error using modprobe to report it without much
needed context.

Are you saying that you do not have this error on your side?

Does:

$ modprobe nvidia-uvm works for you with 346.96?

Regards,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B