Bug#808636: Bug#809733: activemq: FTBFS: package org.apache.kahadb.index does not exist

[Emmanuel Bourg]

Le 09/03/2016 18:06, Markus Koschany a écrit :

> but they apparently stopped tagging new releases some time ago.

I think they migrated the source repository from Subversion to Git, the
GitHub mirror has the latest release tags:

https://github.com/apache/activemq/releases



signature.asc
Description: OpenPGP digital signature

Bug#817547: [Aptitude-devel] Bug#817547: aptitude: Download size miscalculated (not re-calculated?) after an TUI install run

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> At the end I pressed enter where it says "Press Return to continue."
> 
> On top, aptitude says "Disk: +36.9 kBDL: 109 MB/109 MB" despite
> only "sassc" is marked as being installed which needs 36.9 kB disk space if
> installed
> 
> I think these "109MB" are wrong here since just installing sassc surely
> can't cause over 100MB of needed downloads.

If I quit aptitude with "q" + "y" and start it again with "aptitude",
that line only says "Disk: +36.9 kB  DL: 0 B/11.5 kB" which
approximately what I expect.

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#817700: RM: python-django-djapian -- RoQA; Dead upstream

[Olly Betts]

Package: ftp.debian.org
Severity: normal

Quoting myself from: https://bugs.debian.org/755618#17

| On Sun, Jan 03, 2016 at 07:06:03PM +1100, Brian May wrote:
| > # these packages appear to be abandoned upstream, so probably do have
| > # Django 1.7 issues.
| [...] 
| > # 755618 src:python-django-djapian
| > severity 755618 serious
| > # last upstream release 11 Oct 2009
| 
| Sadly djapian seems to go inactive upstream not long after I sponsored
| the package in the first place.
| 
| One of the upstream authors cared enough to migrate the source from
| google code to github around 10 months ago:
| 
| https://github.com/daevaorn/djapian
| 
| But there's been no obvious activity since, and the last commit prior
| to that was 2012-09-01.
| 
| One of the last few commits "Updated runtests.py to support Django 1.4":
| 
| https://github.com/daevaorn/djapian/blob/master/runtests.py
| 
| I don't know how compatible django is over minor version bumps, but it
| seems optimistic to me to expect it still works as-is with django 1.7.
| 
| Popcon score is low and declining:
| 
| https://qa.debian.org/popcon.php?package=python-django-djapian
| 
| (One of those is actually me, presumably from back when I sponsored it).
| 
| I think at this point, either it needs somebody to step forward who
| cares enough to test with django 1.7 and do any work needed to make it
| work, or it should be removed from Debian.
| 
| I'll file an RM bug in a few weeks if there are no volunteers.

The package was removed from testing on 2016-01-19.  I think it's time to
remove it from unstable too.

Cheers,
Olly

Bug#817188: closed by cru...@ucdavis.edu (Michael R. Crusoe) (Bug#817188: fixed in bamtools 2.4.0+dfsg-5)

[Andreas Beckmann]

Control: found -1 2.4.0+dfsg-5

Nope, that didn't work. Wrong version. Use

-Breaks: libbamtools-dev (<< 2.4.0-4)
-Replaces: libbamtools-dev (<< 2.4.0-4)
+Breaks: libbamtools-dev (<< 2.4.0+dfsg-4)
+Replaces: libbamtools-dev (<< 2.4.0+dfsg-4)


Andreas

PS: the git repository doesn't have -5, yet.

Bug#817721: debmirror: Set LANG=C for writing tracefiles

[Joerg Jaspert]

Package: debmirror
Version: 1:2.18+nmu1
Severity: normal

Dear Maintainer,

please adjust tracefile generation to ensure the date line is always run
in LANG=C (or LANG=POSIX), not in whatever locale setting happens to be
around when debmirror is started.

ftpsync, the sync script for official mirrors, uses

LC_ALL=POSIX LANG=POSIX date -u

Thanks.
-- 
bye, Joerg
 HE, we had sex in Debian for many years, yes, before I put a stop
  to it

Bug#817750: Useless in Debian

[David Prévot]

Package: php-smb
Version: 1.0.5-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-smb as used by owncloud, but owncloud is going
away, see #816376. There is a priori little point to ship php-smb in a
Debian stable release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David


signature.asc
Description: PGP signature

Bug#817757: motion: FTBFS on kfreebsd-amd64: #error This header is not available for amd64

[Andreas Beckmann]

Source: motion
Version: 3.2.12+git20140228-8
Severity: important

Hi,

motion FTBFS on kfreebsd-amd64 (but not on kfreebsd-i386), after
the -6 and -7 versions successfully built there:

https://buildd.debian.org/status/fetch.php?pkg=motion=kfreebsd-amd64=3.2.12%2Bgit20140228-8=1453308422

   dh_auto_build -a
make -j1
make[1]: Entering directory '/«BUILDDIR»/motion-3.2.12+git20140228'
Welcome to the setup procedure for Motion, the motion detection daemon! If you 
get
error messages during this procedure, please report them to the mailing list. 
The
Motion Guide contains all information you should need to get Motion up and 
running.
Run "make updateguide" to download the latest version of the Motion Guide.

Version: 3.2.12+git20140228
Platform: FreeBSD

Generating dependencies, please wait...
In file included from video_freebsd.h:21:0,
 from video_freebsd.c:12:
/usr/include/x86_64-kfreebsd-gnu/machine/ioctl_meteor.h:8:3: error: #error This 
header is not available for amd64
 # error This header is not available for amd64
   ^
In file included from video_freebsd.h:22:0,
 from video_freebsd.c:12:
/usr/include/x86_64-kfreebsd-gnu/machine/ioctl_bt848.h:8:3: error: #error This 
header is not available for amd64
 # error This header is not available for amd64
   ^
Makefile:122: recipe for target '.depend' failed
make[1]: *** [.depend] Error 1
make[1]: Leaving directory '/«BUILDDIR»/motion-3.2.12+git20140228'
dh_auto_build: make -j1 returned exit code 2
debian/rules:9: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2


These errors look a bit weird (coming from a header file in an explicit
amd64 directory) and may not be the fault of your package ...

If this problem is not trivially fixable, please request decrufting of
the old binary packages.


Andreas

Bug#808636: Bug#809733: activemq: FTBFS: package org.apache.kahadb.index does not exist

[Markus Koschany]

Am 09.03.2016 um 21:22 schrieb Emmanuel Bourg:
> Le 09/03/2016 18:06, Markus Koschany a écrit :
> 
>> but they apparently stopped tagging new releases some time ago.
> 
> I think they migrated the source repository from Subversion to Git, the
> GitHub mirror has the latest release tags:
> 
> https://github.com/apache/activemq/releases

Thanks. That makes a lot of sense. I think I'll use the github releases
then.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#817756: pulseaudio: load-module module-alsa-sink device=plug:dmixer breaks choosing path-file

[Jakobus Schürz]

Package: pulseaudio
Version: 8.0-1
Severity: normal

Dear Maintainer,

I had for a year a config working on my laptop. I have a asound.conf
which defines a dmixer-device. Pulseaudio uses this dmix-device for
output (so i can play music from a systemwide-mpd simultanious to watching a
video as logged in user).

I also have my own configuration on profile-sets and path-files. Because
plug in and out my headphones mutet the master and my laptop was totally
mutet and didn't get unmutet. 

This all worked until a short time. Since there, plug in or out my
headphones never changed the mute-state from the headphone- and
pcm-mixer.

I found out, when i comment out the line

load-module module-alsa-sink device=plug:dmixer

in /etc/pulse/default.pa, choosing the path works again.
But when i comment this line, i can't hear music from mpd, when the
pulseaudo from the user is playing sound and vice versa. 

So now i can choose hearing all the sounds (from user-pulse and
systemwide mpd) OR plug in and out some headphones, and change soundpath
to headphones or internal speakers... but not both together.

Do you need more information?

Jakob 

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- 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.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.1.0-1
ii  libasound2-plugins1.1.0-1
ii  libc6 2.21-9
ii  libcap2   1:2.24-12
ii  libdbus-1-3   1.10.6-1
ii  libfftw3-single3  3.3.4-2+b1
ii  libgcc1   1:5.3.1-10
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.6-0.1
ii  liborc-0.4-0  1:0.4.24-1
ii  libpulse0 8.0-1
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-10
ii  libsoxr0  0.1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.3.1-10
ii  libsystemd0   229-2
ii  libtdb1   1.3.8-1
ii  libudev1  229-2
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxcb1   1.11.1-1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  9.20160110
ii  pulseaudio-utils  8.0-1
ii  udev  229-2

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  8.0-1
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
ii  paman0.9.4-1+b2
ii  paprefs  0.9.10-2
ii  pavucontrol  3.0-3+b2
ii  pavumeter0.9.3-4+b2

-- Configuration Files:
/etc/pulse/daemon.conf changed:
; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no
 high-priority = yes
 nice-level = -15
 realtime-scheduling = no
 realtime-priority = 9
 exit-idle-time = 20
; scache-idle-time = 20
; dl-search-path = (depends on architecture)
; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa
; log-target = auto
 log-target = journal
; log-level = notice
 log-level = debug
; log-meta = no
; log-time = no
; log-backtrace = 0
; resample-method = speex-float-1
 resample-method = speex-float-10
; enable-remixing = yes
; enable-lfe-remixing = yes
; lfe-crossover-freq = 120
; flat-volumes = yes
; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
 rlimit-nice = 19
; rlimit-rtprio = 9
; rlimit-rttime = 20
; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right
; default-fragments = 4
 default-fragments = 16
; default-fragment-size-msec = 25
 default-fragment-size-msec = 3
; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0

/etc/pulse/default.pa changed:
.nofail
.fail
load-module module-default-device-restore
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module 

Bug#620209: [05389f2] Fix for Bug#620209 committed to git

[Manoj Srivastava]

tags 620209 + pending
thanks
Hi,

 The following change has been committed for this bug by
 Manoj Srivastava  on the branch 
 master at Wed, 9 Mar 2016 13:38:10 -0800.

 The fix will be in the next upload. 
=
[master]: Update with cherry picks from upstream

Updated standards version to 3.9.7. No changes needed.

 Bug fix: "inconsistant description of ifdef directive behavior",
 thanks to Britton Leo Kerin. Cherry picked changes from upstream.
 (Closes: #620209).

Signed-off-by: Manoj Srivastava 
=

Bug#743769: aptitude: Please add a short-form to search by source package name

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Ralf,

2014-04-06 09:37 Ralf Jung:

Package: aptitude
Version: 0.6.10-1
Severity: wishlist

Dear Maintainer,

please add a short form to search by source package name.


Added as ~e, will be present in the new version, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807653: nedit and numeric keypad

[Graham Inggs]

> On 11-12-15 10:44, Orvoine Bertrand wrote:
> > When using NEdit, I am unable to use the numeric keypad to enter numbers no
> > matter whether the numlock is on or off ( with the exception of key "5")
>
> I can confirm this behavior.

I confirm this behaviour in nedit as well.

It doesn't seem to affect all Motif applications though.  I tried
'periodic' from the Motif demos and 'xmgrace' from the grace package.

Bug#817754: Useless in Debian

[David Prévot]

Package: php-google-auth
Version: 0.6-1
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing, and not let it block the PHP 7.0 transition. ]

I recently packaged php-google-auth as used by
php-google-api-php-client, as used by owncloud, but owncloud is going
away, see #816376 (so is php-google-api-php-client, see #817750). There
is a priori little point to ship php-google-auth in a Debian stable
release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David



signature.asc
Description: PGP signature

Bug#815521: openafs dkms module incompatible with Linux 4.4 kernel

[noreply]

OpenAFS users have been working on this bug for several days.

There are reports on the openafs-info mailing list of patches that allow
OpenAFS to work on linux 4.4.x kernels.

Patches should be available soon from upstream.

Bug#817550: libsieve: Removal of debhelper compat 4

[José Luis Tallón]

On 03/09/2016 09:30 PM, ni...@thykier.net wrote:

Source: libsieve
Severity: important
Usertags: compat-4-removal


Sponsor requested.


Hi,

The package libsieve uses debhelper with a compat level of 4,
which is deprecated and scheduled for removal.

  * Please bump the debhelper compat at your earliest convenience.
on the 15th of June.
- Compat 9 is recommended
- Compat 5 is the bare minimum
- If the package has been relying on dh_install being lenient about
  missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1].

  * Compat level 4 will be removed on the first debhelper upload after
the 15th of June.

Bug#812216: RFS suspended until further notice

[Gianfranco Costamagna]

Control: tags -1 moreinfo
Adjusting tags then :)
On Wed, 9 Mar 2016 19:46:00 + Ghislain Vaillant  wrote:
> Just notifying prospective sponsors to refrain for sponsoring this
> package for now until notified otherwise please.
> 
> This package needs further care now that the JUCE is in the archive.
> 
> Cheers,
> Ghislain
> 
> 

Sent from Yahoo Mail on Android

Bug#817748: cups-daemon will not fully install

[info2014]

Package: cups-daemon
Version : cups-daemon_1.7.5-11+deb8u1_amd64.deb
System : amd64: Jessie

Hi, maintainers

The text below is self-evident
###
# apt-get install --reinstall cups-daemon
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 42 not upgraded.
Need to get 0 B/375 kB of archives.
After this operation, 0 B of additional disk space will be used.
Selecting previously unselected package cups-daemon.
(Reading database ... 305047 files and directories currently installed.)
Preparing to unpack .../cups-daemon_1.7.5-11+deb8u1_amd64.deb ...
Failed to stop cups.path: Unit cups.path not loaded.
dpkg: warning: subprocess old pre-removal script returned error exit status 5
dpkg: trying script from the new package instead ...
Failed to stop cups.path: Unit cups.path not loaded.
dpkg: error processing archive 
/var/cache/apt/archives/cups-daemon_1.7.5-11+deb8u1_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 5
/usr/bin/deb-systemd-helper: error: unable to read cups.service
/usr/bin/deb-systemd-helper: error: unable to read cups.socket
/usr/bin/deb-systemd-helper: error: unable to read cups.path
Failed to start cups.path: Unit cups.path failed to load: No such file or 
directory.
Errors were encountered while processing:
 /var/cache/apt/archives/cups-daemon_1.7.5-11+deb8u1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
###

The present system was restored after a motherboard failed. 
There may be some legacy problems from the old system. 

I had a look at 
Debian Bug report logs - #814340
as that seemed closest to this problem. 

I have files in /var/spool/cups

I looked for /lib/systemd/system/cups.path
there was no file, nor cups.service cups.socket 
# find / -name 'cups.path' reports this 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cups.path

And # apt-get install cups-daemon
Reading package lists... Done
Building dependency tree   
Reading state information... Done
cups-daemon is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 42 not upgraded.

regards

richard

Bug#817550: libsieve: Removal of debhelper compat 4

[Niels Thykier]

José Luis Tallón:
> On 03/09/2016 09:30 PM, ni...@thykier.net wrote:
>> Source: libsieve
>> Severity: important
>> Usertags: compat-4-removal
> 
> Sponsor requested.
> 
>> Hi,
>>
>> The package libsieve uses debhelper with a compat level of 4,
>> which is deprecated and scheduled for removal.
>>
>>   * Please bump the debhelper compat at your earliest convenience.
>> on the 15th of June.
>> - Compat 9 is recommended
>> - Compat 5 is the bare minimum
>> - If the package has been relying on dh_install being lenient about
>>   missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1].
>>
>>   * Compat level 4 will be removed on the first debhelper upload after
>> the 15th of June.

Please let me know when and where your patch(ed version) is available
and I will try to find a sponsor for it.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#817760: RM: xicc -- ROM; abandoned upstream

[Ross Burton]

Package: ftp.debian.org
Severity: normal

Only available in unstable and oldstable, abadoned upstream for 8 years,
superceded with modern technology.

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[gregor herrmann]

On Sun, 06 Mar 2016 19:48:37 +0200, Nikos Tsipinakis wrote:

> I am looking for a sponsor for my package "newsbeuter"
> 
> * Package name: newsbeuter
>   Version : 2.9-1
>   Upstream Author : Andreas Krennmair 
> * URL : https://github.com/akrennmair/newsbeuter
> * License : MIT
>   Section : net
> 
> Alternatively, one can download the package with dget using this command:
> 
>dget -x 
> http://mentors.debian.net/debian/pool/main/n/newsbeuter/newsbeuter_2.9-1.dsc

Thanks for your interest in newsbeuter; I like it and use it daily :)
And I was looking forward to a version which needs less memory than
Iceweasel; but for me 2.9 has a massive problem:

The highlighting feature seems to be broken (no idea if this is a
problem in newsbeuter or ncurses; I haven't retried to rebuild 2.8-2
to check). Too show what I mean: I have in my ~/.newsbeuter/config

#v+
# colours
highlight article "^Feed:.+$" yellow black bold
highlight article "^Title:.+$" red black bold
highlight article "^Author:.+$" yellow black bold
highlight article "^Link: " white black bold
highlight article "^Date:.+$" yellow black bold

highlight article "https?://[^][ $)\"]+" cyan black underline
highlight article "?" cyan black
#v-

And the result is --> see attachments.

Maybe you could look into this issue and/or discuss with ak?


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Funny van Dannen: Junge Christen


signature.asc
Description: Digital Signature

Bug#817759: RM: thewidgetfactory -- ROM; abandoned upstream

[Ross Burton]

Package: ftp.debian.org
Severity: normal


The Widget Factory was abandoned upstream a decade ago and for a UI widget
showcase, uses a deprecated and unmaintained toolkit (gtk+2).

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Alexis Murzeau]

2016-03-08 22:48 GMT+01:00 Scott Ashcroft :
> The patch makes no difference.
> Is there anything else I can do to help figure this out?

You can use the kernel command line "earlyprintk=efi,keep". This way
the kernel will print messages to see what's going on (and maybe a
traceback in case of crash).

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Matt Fleming]

On Wed, 09 Mar, at 11:01:18PM, Alexis Murzeau wrote:
> 
> Indeed I get the "Could not reserve range" message, and with a kernel
> v4.3 the physical address 0x1 contains the value 1.
> And this patch works and make a unmodified + this patch 4.4 debian
> kernel boots, nice well found :)
 
Great, thanks for testing.

> However, now a bad page state is reported in dmesg (which doesn't seem
> to affect the kernel to me as a user but might hide something buggy) :
> [0.030096] BUG: Bad page state in process swapper/0  pfn:0
> [0.030100] page:ea00 count:0 mapcount:1 mapping:
>(null) index:0x0
> [0.030102] flags: 0x0()
> 
> The efi_free_boot_services function seems to expect size == 0 to not
> free non reserved memory according to commit 7d68dc3.
> Not sure if this bad page state is related to this patch though, but I
> don't get this with the 4.3 kernel.

Yeah, it's definitely related to my quick and dirty patch. I'll have a
think about how to fix it properly tomorrow morning.

Bug#817764: systraq: missing Depends: make; dpkg hook fails after removal of systraq and make

[Andreas Beckmann]

Package: systraq
Version: 20160303-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed installing your package breaks the
system.

>From the attached log (scroll to the bottom...):

0m36.5s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpFLdccg', 
'apt-get', '-y', 'install', 'systraq=20160303-1']
0m38.2s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following NEW packages will be installed:
systraq
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 439 kB of archives.
  After this operation, 529 kB of additional disk space will be used.
  Get:1 http://ftp.de.debian.org/debian sid/main amd64 systraq all 20160303-1 
[439 kB]
  debconf: delaying package configuration, since apt-utils is not installed
  Fetched 439 kB in 0s (19.5 MB/s)
  Selecting previously unselected package systraq.
  (Reading database ... 
(Reading database ... 9984 files and directories currently installed.)
  Preparing to unpack .../systraq_20160303-1_all.deb ...
  Unpacking systraq (20160303-1) ...
  Setting up systraq (20160303-1) ...
0m38.2s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpFLdccg', 'apt-get', 
'-y', 'install', 'systraq=20160303-1']
0m38.2s INFO: Running scripts post_install
0m38.2s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpFLdccg', 
'tmp/scripts/post_install_exceptions']
0m38.2s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpFLdccg', 
'tmp/scripts/post_install_exceptions']
0m38.2s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpFLdccg', 
'apt-get', 'remove', 'systraq']
0m39.3s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following packages were automatically installed and are no longer 
required:
cron debsums exim4 exim4-base exim4-config exim4-daemon-light filetraq
libdpkg-perl libffi6 libfile-fnmatch-perl libgmp10 libgnutls30 libhogweed4
libidn11 libnettle6 libp11-kit0 libprocps5 libtasn1-6 net-tools procps
  Use 'sudo apt autoremove' to remove them.
  The following packages will be REMOVED:
systraq
  0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
  After this operation, 529 kB disk space will be freed.
  (Reading database ... 
(Reading database ... 10041 files and directories currently installed.)
  Removing systraq (20160303-1) ...
  sh: 1: make: not found
  E: Problem executing scripts DPkg::Post-Invoke 'su -s /bin/sh -c 'test -f 
/etc/systraq/Makefile && make -C /etc/systraq' debian-systraq'
  E: Sub-process returned an error code
0m39.3s DEBUG: Command failed (status=100), but ignoring error: ['chroot', 
'/tmp/piupartss/tmpFLdccg', 'apt-get', 'remove', 'systraq']


There is clearly a dependency on make missing, but I expect that the dpkg
hook will also fail in this sequence:

apt-get install make systraq
apt-get remove systraq  # no purge!
apt-get remove make
apt-get install hello

Yes, it does fail.


cheers,

Andreas


systraq_20160303-1.log.gz
Description: application/gzip

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

[GCS]

On Wed, Mar 9, 2016 at 11:30 PM, Aaron M. Ucko  wrote:
> "László Böszörményi (GCS)"  writes:
> I prefer to follow this whole procedure fairly frequently so that I
> don't have too many reports to file at any one time.
 OK, it just doesn't let the maintainer fix the issue. When I'm about
to upload the fixed package, I get a bugreport from you. Then I have
to update the changelog closing the bugreport and rebuild the package.
:)

> Sorry for the noise.
 No problem, next time I should wait more on you to file the bugreport.

Thanks for watching. Cheers,
Laszlo/GCS

Bug#817767: dovecot-core: unowned files after purge (policy 6.8, 10.8): /etc/dovecot/conf.d/10-ssl.conf

[Andreas Beckmann]

Package: dovecot-core
Version: 1:2.2.21-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

2m11.7s ERROR: FAIL: Package purging left files on system:
  /etc/dovecot/  owned by: dovecot-core
  /etc/dovecot/conf.d/   owned by: dovecot-core
  /etc/dovecot/conf.d/10-ssl.confnot owned


cheers,

Andreas


dovecot-core_1:2.2.21-1.log.gz
Description: application/gzip

Bug#817766: ITP: flask-mongoengine -- Flask-MongoEngine is a Flask extension that provides integration with MongoEngine and WTF model forms.

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: flask-mongoengine
  Version : 0.7.5
  Upstream Author : Ross Lawley 
* URL : http://docs.mongoengine.org/projects/flask-
mongoengine/en/latest/
* License : MIT
  Programming Lang: Python
  Description : A Flask extension that provides integration with
MongoEngine and WTF model forms.


A Flask extension that provides integration with MongoEngine.
It handles connection management for your app.
You can also use WTForms as model forms for your models.

I intend to package both Python 2 and Python 3 modules and maintain them under
the DPMT team

Bug#817767: dovecot-core: unowned files after purge (policy 6.8, 10.8): /etc/dovecot/conf.d/10-ssl.conf

[Jaldhar H. Vyas]

tag 817767 +pending
thanks

On Thu, 10 Mar 2016, Andreas Beckmann wrote:


Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.


From the attached log (scroll to the bottom...):


2m11.7s ERROR: FAIL: Package purging left files on system:
 /etc/dovecot/   owned by: dovecot-core
 /etc/dovecot/conf.d/owned by: dovecot-core
 /etc/dovecot/conf.d/10-ssl.conf not owned



Thanks for the report.  Apollon fixed this in git so it will go into the 
next update.


--
Jaldhar H. Vyas 

Bug#817762: O: png-definitive-guide

[Ross Burton]

Package: wnpp
Severity: normal

This is a very low-maintance package for the official PNG/libpng book.

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

[Aaron M. Ucko]

"László Böszörményi (GCS)"  writes:

>  Yes, seen that and upload is pending.

Great, thanks for the quick fix!

> While not a real issue, but is there any reason why you fire
> bugreports immediately?

Yes, my usual workflow is as follows:

- Run aptitude to update package lists.

- Run a personal script that reports binary packages that are new on
  amd64 and absent on i386, or vice versa.

- Check build.debian.org to rule out false positives (or in some cases
  identify buggy build dependencies).

- File reports.

- Reset aptitude's notion of which packages are new.

I prefer to follow this whole procedure fairly frequently so that I
don't have too many reports to file at any one time.

Sorry for the noise.

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

Bug#817761: RM: smooth-themes -- ROM; abandoned upstream

[Ross Burton]

Package: ftp.debian.org
Severity: normal


Unmaintained theme engines for an unmaintained UI toolkit (GTK+2). Remove 
please.

Bug#817769: problem with include_path

[Ivan Sergio Borgonovo]

Package: php5
Version: 5.6.19+dfsg-1

After upgrade from 5.6.18+dfsg-1 I get:

FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: PHP message: PHP 
Fatal error:  require_once(): Failed opening required 
'Horde/Autoloader/Default.php' 
(include_path='/usr/share/horde/lib:.::/usr/share/pear') in 
/usr/share/horde/lib/core.php on line 49


packages potentially involved are:
php5-fpm
php5-common
php5-cli

I haven't been able to track down which package is actually the culprit.
Gut feeling would point to php5-fpm


thanks


--
Ivan Sergio Borgonovo
http://www.webthatworks.it

Bug#817547: [Aptitude-devel] Bug#817547: aptitude: Download size miscalculated (not re-calculated?) after an TUI install run

[Manuel A. Fernandez Montecelo]

Hi Axel,

2016-03-09 20:58 Axel Beckert:

Hi again,

Axel Beckert wrote:

At the end I pressed enter where it says "Press Return to continue."

On top, aptitude says "Disk: +36.9 kBDL: 109 MB/109 MB" despite
only "sassc" is marked as being installed which needs 36.9 kB disk space if
installed

I think these "109MB" are wrong here since just installing sassc surely
can't cause over 100MB of needed downloads.


If I quit aptitude with "q" + "y" and start it again with "aptitude",
that line only says "Disk: +36.9 kB  DL: 0 B/11.5 kB" which
approximately what I expect.


That's strange.  If the installation is successful, seems to work fine.

Reinstalling packages also produce strange effects, I haven't been able
to find a proper pattern yet.

I think that part of the problem is that the signals when updated the
planned action of the package are not emitted as they should, or at
least as I expected.

Needs more investigation...

--
Manuel A. Fernandez Montecelo 

Bug#817768: pacemaker-common: unowned files after purge (policy 6.8, 10.8): /etc/pacemaker/authkey

[Andreas Beckmann]

Package: pacemaker-common
Version: 1.1.14-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m41.5s ERROR: FAIL: Package purging left files on system:
  /etc/pacemaker/owned by: pacemaker-common
  /etc/pacemaker/authkey not owned


cheers,

Andreas


pacemaker-common_1.1.14-2.log.gz
Description: application/gzip

Bug#817770: ITP: flask-bcrypt -- A Flask extension that provides bcrypt hashing utilities for your application.

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: flask-bcrypt
  Version : 0.7.1
  Upstream Author : Max Countryman 
* URL : http://readthedocs.org/docs/flask-bcrypt/
* License : BSD-3
  Programming Lang: Python
  Description : A Flask extension that provides bcrypt hashing utilities
for your application.

Due to the recent increased prevelance of powerful hardware, such as modern
GPUs, hashes have become increasingly easy to crack. A proactive solution to
this is to use a hash that was designed to be "de-optimized". Bcrypt is such a
hashing facility; unlike hashing algorithms such as MD5 and SHA1, which are
optimized for speed, bcrypt is intentionally structured to be slow.
For sensitive data that must be protected, such as passwords, bcrypt is an
advisable choice.

I plan to maintain this within the DPMT.

Bug#817767: dovecot-core: unowned files after purge (policy 6.8, 10.8): /etc/dovecot/conf.d/10-ssl.conf

[Apollon Oikonomopoulos]

Control: tags -1 pending

Hi Andreas,

On 00:32 Thu 10 Mar , Andreas Beckmann wrote:
> Package: dovecot-core
> Version: 1:2.2.21-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8 (or 10.8):
> 
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails
> 
> Filing this as important as having a piuparts clean archive is a release
> goal since lenny.

Thanks for the report. We have already committed a fix for this in 
git[1], it will be part of the next upload.

Regards,
Apollon

[1] 
https://anonscm.debian.org/git/collab-maint/dovecot.git/commit/?id=d18d05f00f7ef43b6327437eb910a8f6488d418f

Bug#817769: [php-maint] Bug#817769: problem with include_path

[Ondřej Surý]

It seems that your include_path is wrong, as Horde resides in:

/usr/share/php/Horde/Autoloader/Default.php

Doesn't seem to be php5 fault as /usr/share/php is missing from your
include_path and the default include_path is:

include_path = ".:/usr/share/php"

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Thu, Mar 10, 2016, at 00:34, Ivan Sergio Borgonovo wrote:
> Package: php5
> Version: 5.6.19+dfsg-1
> 
> After upgrade from 5.6.18+dfsg-1 I get:
> 
> FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: PHP message: PHP 
> Fatal error:  require_once(): Failed opening required 
> 'Horde/Autoloader/Default.php' 
> (include_path='/usr/share/horde/lib:.::/usr/share/pear') in 
> /usr/share/horde/lib/core.php on line 49
> 
> packages potentially involved are:
> php5-fpm
> php5-common
> php5-cli
> 
> I haven't been able to track down which package is actually the culprit.
> Gut feeling would point to php5-fpm
> 
> 
> thanks
> 
> 
> -- 
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
> 
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint

Bug#817287: ITP: libhttp-headers-actionpack-perl -- HTTP Action, Adventure and Excitement

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libhttp-headers-actionpack-perl
  Version : 0.09
  Upstream Author : Stevan Little 
* URL : https://metacpan.org/pod/HTTP::Headers::ActionPack
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : HTTP Action, Adventure and Excitement

 HTTP::Headers::ActionPack is a module to handle the inflation and
 deflation of complex HTTP header types. In many cases header values are
 simple strings, but in some cases they are complex values with a lot of
 information encoded in them. The goal of this module is to make the
 parsing and analysis of these headers as easy as calling inflate on a
 compatible object.

This package will be maintained in the Debian Perl team.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW4G72AAoJECx8MUbBoAEhG/oQAIGqYHiJ2SsmHdPaNpzix7+k
TVycFQP/014KkseNQFZLk1D2+6aYQd6hlQQ89mGdP0N0BWGfnJdEA8tRZ4lwrxOl
Jukhi2fPv/jieSQQU50n+u91yKFdBbqBC+o8E/0mSHGeLf+UILuw7+LHdBC/6wrM
IQQxJvA77feQxk4OdqHzQhrqo/HFbpVgkvwmbbKd7KwIsWGKsvpZw4xSyZGjkDWD
FxTocdSfmp7xp2zNwWZyZJN7QlW9LMosQEU0V7IBHFdBe7ctGWlhgEfhCqxVeQLL
LG1Zegv6Ffsyid5sq7GjvRqAEMJgeBuka85ko0ruwMS4EMpipyYdfKTs08KpKqsX
hiJnlca6mxQdjAui7UCcn2Tk4IKXDVfzyRmAecZa63tkAl5SCdJaf1zRJIZhXOw4
ZM5nzL0BJ87XeHeY9yoFPQ5/rH2EnaNECTAhRcUe6XEb3cm3NqeD4pD3CHzP4JQY
U8N0d5cvhU+GD099+uAqOiNUd55A4B/TAN2NA9sRXifswSUAjTiA0Wl/W+c4dP7I
VF7YEO34V7hVYem5v6nKy+g2IciQYke9hhinm+e/hIOs5bseDw3MO08Iarnt2Vl+
5+sHDQ+MbXE0OSelwhPhOxd1/vUox2RWqdJCBzOuzxTeDCj+HVBJ9c5SOw+pfYmG
Xvhg7uVRsco1jD/Hd54O
=nKRG
-END PGP SIGNATURE-

Bug#817371: systemd-sysv: circular pre-dependency

[Michael Biebl]

Control: reassign -1 util-linux

Am 09.03.2016 um 20:46 schrieb Bill Allombert:
> Package: systemd-sysv
> Version: 229-2
> Severity: important
> 
> Hello Debian systemd Maintainers,
> 
> There is a circular dependency between systemd-sysv, systemd and util-linux:
> 
> systemd-sysv  :Pre-Depends: systemd
> systemd   :Depends: util-linux (>= 2.27.1)
> util-linux:Depends: systemd-sysv
> 
> Circular pre-dependencies are not supported by dpkg.

This dependency was introduced by util-linux, so I'm reassigning.
I also don't quite understand the alternative dependency on tzdata |
systemd-sysv. That's something Andreas most likely can answer.
That said, the dependency from util-linux on systemd-sysv is
unversioned, so I fail to see the problem? Care to elaborate.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#815919: nmu: tesseract_3.04.01-3 openalpr_2.2.3-1 gimagereader_3.1.2+git368fa8f-1 sikuli_1.0~x~rc3.tesseract3-dfsg1-12

[Jeff Breidenbach]

retitle 815919 nmu: tesseract_3.04.01-4 openalpr_2.2.3-1
gimagereader_3.1.2+git368fa8f-2 sikuli_1.0~x~rc3.tesseract3-dfsg1-12
thanks

There are some good reasons to do this sooner rather than later.

Bug#817286: Simplify testing access for packages on security-master

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: wishlist

This was discussed at one of the past security team meetings, but
there was never a bug for that:

(This is a first high level view, the exact requirements can be hashed
out later.)

It would be great to have a simple (single command) method to simplify
testing security updates. Right now these need to copied manually to
the respective test hosts. If it's not available via apt, this is a
problem for many people since they are unable to find out which binary
packages are installed and how to update them via dpkg.

There should be a method to allow
- publishing a public security issue to a permanent staging repository
  ala jessie-security-staging, which people can keep in their apt source

- publishing an non-public security issue to a protected apt
  repository to simplify testing for members of the security team
  
Cheers,
Moritz

Bug#817204: nm.debian.org: ‘django-housekeeping’ is now in Debian Stretch

[Jonathan Wiltshire]

On Wed, Mar 09, 2016 at 10:27:23AM +1100, Ben Finney wrote:
> The code base's README document gives installation instructions. Those
> instructions specify to get the ‘django-housekeeping’ package from a
> GitHub repository.
> 
> Now that bug#748875 (“ITP: django-housekeeping -- Pluggable
> housekeeping framework for Django sites.”) is resolved, and Debian
> Stretch now has the ‘python-django-housekeeping’ package version
> “1.0-1”, should the installation instructions for ‘nm2’ direct the
> reader to that package?

Only if they are developing on Stretch, I think. Since nono.debian.org is
Jessie, that should be the target for any nm2 development work. Could you
rework your patch to deal with that?

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: Digital signature

Bug#815919: nmu: tesseract_3.04.01-3 openalpr_2.2.3-1 gimagereader_3.1.2+git368fa8f-1 sikuli_1.0~x~rc3.tesseract3-dfsg1-12

[Andreas Beckmann]

Control: retitle -1 nmu: gimagereader_3.1.2+git368fa8f-2 
sikuli_1.0~x~rc3.tesseract3-dfsg1-12

On Thu, 25 Feb 2016 18:50:49 +0100 Andreas Beckmann  wrote:
> The ABI change has been reverted and the transition to
> libtesseract4 has to be undone (#815056).

tesseract and openalpr had source uploads. gimagereader, too, but
picked up the old lib on hurd. So this leaves us with

nmu gimagereader_3.1.2+git368fa8f-2 . hurd-i386 . unstable . -m "Rebuild 
against libtesseract3."
nmu sikuli_1.0~x~rc3.tesseract3-dfsg1-12 . ANY . unstable . -m "Rebuild against 
libtesseract3."


Andreas

Bug#814968: hunspell: diff for NMU version 1.3.3-3.1

[Raúl Benencia]

Hi, 

On Wed, Mar 09, 2016 at 05:43:55PM +0100, Rene Engelhard wrote:
> > I've prepared an NMU with this changes (versioned as 1.3.3-3.1).
> 
> Erm, without givinbg the maintainer the chance to add the fix himself? That's 
> not how
> NMUs are supposed to work.

I'm going to quote the developer reference, section 5.11.1:

| Unless you have an excellent reason not to do so, you must then give some
| time to the maintainer to react (for example, by uploading to the
| DELAYED queue). Here are some recommended values to use for delays:
| 
| (...)
|
| * Upload fixing only release-critical bugs older than 7 days: 2 days

This release-critical bug has been open for more than twenty days, so I
understand that this is how NMUs are supposed to work.

> > As I don't have privileges to upload it to DELAYED, [...]
> 
> I am inclinced to say "thankfully" here.

In hopes of being constructive, would you care to explain why? Section
5.11.3 says:

| Having to wait for a response after you request permission to NMU is
| inefficient, because it costs the NMUer a context switch to come back to
| the issue.

On top of that, section 5.6.2 says:

| It is sometimes useful to upload a package immediately, but to want this
| package to arrive in the archive only a few days later. For example, when
| preparing a Non-Maintainer Upload, you might want to give the maintainer
| a few days to react.

I've used mentors as a replacement of DELAYED in hopes that, if you were
unresponsive for the aforementioned time, another DD could have easily
sponsored the NMU.

Would you care to explain why do you think I shouldn't have hypothetically
used DELAYED in this way?

Thanks in advance,
Rul


signature.asc
Description: PGP signature

Bug#812943: dracut-core: Please make console-setup optional

[Thomas Lange]

> On Wed, 27 Jan 2016 21:34:25 -0300, Felipe Sateler  
> said:

> The module-setup.sh for console setup uses exit instead of return, thus
> making the console-setup module effectively required.

> Please make console-setup optional, and thus lower the dependency on
> console-setup to Recommends or Suggests.
Wouldn't be the proper fix to use return instead of exit? Does this
also fix the problem?

-- 
regards Thomas

Bug#817248: diffoscope 51 not uploaded to pypi

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 09, 2016 at 01:09:17PM +0100, Holger Levsen wrote:
> package: diffoscope
> version: 51
> severity: minor
> x-debbugs-cc: "Zbigniew Jędrzejewski-Szmek" 
> 
> Hi,
> 
> thanks for making us aware of this issue!
> 
> On Mittwoch, 9. März 2016, Zbigniew Jędrzejewski-Szmek wrote:
> > > FYI: I checked why I missed diffscope 49, 50, and 51.
> > > It seems to be a problem with pypi:
> > > https://pypi.python.org/pypi?%3Aaction=search=diffoscope=sear
> > > ch only lists diffoscope 48 as the lastest version. So either somebody
> > > forgot to upload the latest versions there, or it's not displaying them
> > > for some reason.
> > V. 49 is also on pypi, just doesn't show up in the search.
> 
> is there a commandline client to search on pypi? I'd like to setup an 
> automatic test which will notify us, when a new diffoscope upload has been 
> made to Debian, but not to pypi.

Not that I know of, but it should be easy enough to get
https://pypi.python.org/pypi/diffoscope/
and scape for the version (it's in the title of the page).

> Also: who can how upload to pypi?
No idea.

> > Is there a canonical place do download a tarball of the project apart from
> > pypi?
Too bad. It would be nice to enable tarball downloads on anonscm.d.o.

Zbyszek

Bug#815888: nvidia-detect: GF119M [GeForce 610M] nvidia-detect=ok for nvidia-driver . . . not ok

[Luca Boccassi]

On 9 March 2016 at 11:49, Fulano Diego Perez  wrote:
> hi luca,
>
> Luca Boccassi:
>> On 9 March 2016 at 10:05, Fulano Diego Perez  
>> wrote:
>>> hi luca
>>>
>>> Luca Boccassi:
 Control: package -1 nvidia-driver
 Control: tag -1 moreinfo
 Control: severity -1 normal

 On Thu, 2016-02-25 at 23:34 +1100, Fulano Diego Perez wrote:
> Package: nvidia-detect
> Severity: grave
> Justification: renders package unusable
>
>
> _disclaimer_
>
> 1.
> i do not know if the problem lies with nvidia-detect, nvidia-driver and 
> its
> dependencies, or neither
>
> 2.
> this bug report was submitted after removal and revert back to nouveau
>
> 3.
> applies to intel ivy bridge chipset with built-in intel graphics +
> nvidia below
>
>
>
> nvidia-detect recommends nvidia-driver
>
> i then install nvidia-driver, its dependencies and nvidia-xconfig
>
> NB i attempted this ~6 months ago and yesterday, i do not know the affect 
> of
> the recent nvidia updates to xserver and whether nvidia-xconfig is still
> necessary
>
> gdm3 cannot proceed after reboot
>
> please advise any further log provision where necessary:

 Hi,

 It looks like you have a laptop with a switchable Optimus system (610M).
 If that's indeed the case, you cannot just install the nvidia stack, as
 your hardware is wired to use the Intel card to drive the display.

 If you want to use the discrete Nvidia card, you must do so through
 bumblebee. Please install

 bumblebee-nvidia

 Then run:

 sudo update-glx --config glx

 And make sure nvidia/bumblebee is selected, if not pick it.
>>>
>>> done above
>>>

 If the problem persists, please add more information by running:

 reportbug -N 815888
>>>
>>> sorry, this is out ATM, nevertheless...
>>>
 Kind regards,
 Luca Boccassi
>>>
>>> i get the following:
>>>
>>> $ primusrun glxgears
>>> primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)
>>>
>>> $ optirun glxgears
>>> [23162.070642] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)
>>>
>>> ive tried various basic amendments such as
>>>
>>> adding my user to the bumblebee group;
>>>
>>> manually specifying the nvidia option in /etc/bumblebee/bumblebee.conf;
>>>
>>> manually specifying BusID "PCI:1:0:0" in /etc/bumblebee/xorg.conf.nvidia
>>> (from the github FAQ)
>>>
>>> $ lspci | egrep 'VGA|3D'
>>> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
>>> processor Graphics Controller (rev 09)
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce
>>> 610M] (rev a1)
>>>
>>> i admit im stuck
>>
>> Hi,
>>
>> Sorry for your troubles.
>>
>> Unfortunately there's not much I can do without looking at the full
>> system report. If reportbug -N is not working for you, could you
>> please manually attach the output of:
>
> sure makes sense
>
>> reportbug --template nvidia-driver
>
> i enclose
>
> thanks for your help

Hi,

>From the log, it looks like nouveau is being loaded:

2367.838] (II) LoadModule: "nouveau"
[  2367.838] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[  2367.838] (II) Module nouveau: vendor="X.Org Foundation"
[  2367.838] compiled for 1.18.0, module version = 1.0.12
[  2367.838] Module class: X.Org Video Driver
[  2367.838] ABI class: X.Org Video Driver, version 20.0



[  2367.839] (II) NOUVEAU driver Date:   Tue Dec 8 15:52:25 2015 +1000
[  2367.839] (II) NOUVEAU driver for NVIDIA chipset families :
[  2367.839] RIVA TNT(NV04)
[  2367.839] RIVA TNT2   (NV05)
[  2367.840] GeForce 256 (NV10)
[  2367.840] GeForce 2   (NV11, NV15)
[  2367.840] GeForce 4MX (NV17, NV18)
[  2367.840] GeForce 3   (NV20)
[  2367.840] GeForce 4Ti (NV25, NV28)
[  2367.840] GeForce FX  (NV3x)
[  2367.840] GeForce 6   (NV4x)
[  2367.840] GeForce 7   (G7x)
[  2367.840] GeForce 8   (G8x)
[  2367.840] GeForce GTX 200 (NVA0)
[  2367.840] GeForce GTX 400 (NVC0)


Even though the module is blacklisted.

Have you rebooted after installing the nvidia stuff?

To make sure the module configs are parsed and up to date, please run:

sudo depmod
sudo update-initramfs -u

and then reboot and try again.

If the problem persists, please attach /var/log/Xorg.8.log (I'll take
a note to collect that in the reportbug script, it doesn't at the
moment).

Kind regards,
Luca Boccassi

Bug#812783: dpkg: Please use ASAN, UBSAN and bindnow on hardened1-linux-amd64

[Bálint Réczey]

Hi Guillem,

2016-03-09 12:09 GMT+01:00 Guillem Jover :
> Hi!
>
> On Tue, 2016-03-08 at 11:29:04 +0100, Bálint Réczey wrote:
>> 2016-03-08 1:52 GMT+01:00 Guillem Jover :
>> > Actually setting bindnow and PIE would be fine as part of the default
>> > build flags from dpkg, because those do not change the ABI in
>> > principle. And those are the only ones I'd accept from this bug
>> > report, but certainly not the ABI changing ones.
>
>> Do you mean you would be open to setting PIE and maybe bindnow as default
>> flags for a potential new architecture or even for existing ones like amd64?
>> In the latter case would you like to discuss that on debian-devel?
>> I would support such changes and I think we are in time for enabling
>> PIE for Stretch
>> and bindnow for Stretch+1 (maybe Stretch).
>
> Setting PIE and bindnow for the proposed new arch seems fine to me, as
> its main raison d'etre is precisely to be hardened. I don't think
> anything has changed significantly to globally enable these by default
> everywhere though (i.e. performance and potential for breakage, at least).
I think there were significant changes in the open source landscape.
Fedora 23 came out with PIE and bindnow by default:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages#Detailed_Harden_Flags_Description

Lunar also suggested changing pie to opt-out rather than keeping it opt-in:
https://people.debian.org/~lunar/blog/posts/aslr_now/

GCC 6 will add the --enable-default-pie configure option, doko already
pack-ported it to 5.x in unstable and it is already enabled for Ubuntu 390x:
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-5/debian/rules.defs?view=markup#l1204

I think it would be reasonable to follow Fedora and making both PIE
and bindnow opt-in after fixing
most packages which don't build based an archive-wide rebuild test in advance.

Cheers,
Balint

Bug#817253: RM: luatex [all] -- RoQA; transitional package replaced by virtual package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please decruft texlive-bin and remove the obsolete arch:all transitional
package luatex. This is now a virtual package provided by
texlive-binaries (and sufficient for installing the last remaining user:
gregoriotex).


Andreas

Bug#806243: [libminc] Test issues when building on mipsel architecture (#66)

[Andreas Beckmann]

Control: severity -1 important

On Sat, 16 Jan 2016 13:17:15 +0100 Andreas Beckmann  wrote:
> On Sat, 05 Dec 2015 20:56:01 + James Cowgill
>  wrote:
> > Since libminc has never successfully built on mipsel, this bug
> > shouldn't have been serious in the first place (regardless of what was
> > causing it).
> 
> But the minc package (before the split) has built successfully on
> mipsel, so this FTBFS is blocking the transition, since minc-tools is
> missing a current build on mipsel.

The old minc package has been decrufted, so the missing mips*el builds
shouldn't be blocking any longer.


Andreas

Bug#817248: [Reproducible-builds] Bug#817248: diffoscope 51 not uploaded to pypi

[Mattia Rizzolo]

On Wed, Mar 09, 2016 at 12:37:55PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 09, 2016 at 01:09:17PM +0100, Holger Levsen wrote:
> > is there a commandline client to search on pypi? I'd like to setup an 
> > automatic test which will notify us, when a new diffoscope upload has been 
> > made to Debian, but not to pypi.
> 
> Not that I know of, but it should be easy enough to get
> https://pypi.python.org/pypi/diffoscope/
> and scape for the version (it's in the title of the page).

for this, http://pypi.debian.net/diffoscope should be better (it's what
is used in d/watch for python stuff)

> > Also: who can how upload to pypi?
> No idea.
> 
> > > Is there a canonical place do download a tarball of the project apart from
> > > pypi?
> Too bad. It would be nice to enable tarball downloads on anonscm.d.o.

I wonder, why not consider canonical
http://ftp.debian.org/debian/pool/main/d/diffoscope/ (pretty much the
same way src:whois does).  Too sad it doesn't keep historical stuff.

And btw, on alioth.d.o could be enable a project feature where you can
upload stuff and do releases (with announcements), but I personally
really dislike that site for a good bunch of reasons.

I'm not sure, the tarballs in pypi are the same of what we uploaded in
the debian archive?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#528767: Do not reply to the original poster

[Daniel Shahaf]

I just received a bounce message for my last reply:

> :
> 87.230.23.53 does not like recipient.
> Remote host said: 550 SPAM TRAP!! Go away!!
> Giving up on 87.230.23.53.

So:

1. @everyone else: make sure not to CC the original poster, that might
get you blacklisted somewhere...

2. To postmas...@ko-sys.com: please don't use spamtrap addresses in
contexts (in this case, a public mailing list / bug report) where they
may be legitimately replied to.

Best,

Daniel

Bug#814167: lwjgl: (Build-)Depends on OpenJDK 7

[Markus Koschany]

On Tue, 8 Mar 2016 21:36:31 -0500 Michael Gilbert 
wrote:
> > I have switched the build-dependency to default-jdk and changed
> > JAVA_HOME in debian/rules accordingly. However the package FTBFS with
> > OpenJDK 8. I guess packaging the latest upstream release would be the
> > best option.
> 
> 2.9.3 is supposed to support building without ant.  I looked at it a
> while ago, and it isn't quite that simple.
> 
> lwjgl3 is also available, but it has a huge dependency stack with
> almost none of it in Debian yet.
> 
> I have less interest in lwjgl now than I used to, and I may not be
> able to find the time to work on it.
> 
> Best wishes,
> Mike

I had a quick look at lwjgl3. It seems the API has been declared stable
and lwjgl2 will be retired in favor of lwjgl3. I will try to package
version 3. There are no reverse-dependencies for lwjgl, so the risk of
breaking something is for once quite small.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#817248: [Reproducible-builds] Bug#817248: diffoscope 51 not uploaded to pypi

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 09, 2016 at 01:07:13PM +, Mattia Rizzolo wrote:
> http://pypi.debian.net/diffoscope should be better
> http://ftp.debian.org/debian/pool/main/d/diffoscope/
Thanks. Both seem to work indeed (apart from pypi missing some tarballs of 
course).

Zbyszek

Bug#815888: nvidia-detect: GF119M [GeForce 610M] nvidia-detect=ok for nvidia-driver . . . not ok

[Fulano Diego Perez]

hi luca

Luca Boccassi:
> Control: package -1 nvidia-driver
> Control: tag -1 moreinfo
> Control: severity -1 normal
> 
> On Thu, 2016-02-25 at 23:34 +1100, Fulano Diego Perez wrote:
>> Package: nvidia-detect
>> Severity: grave
>> Justification: renders package unusable
>>
>>
>> _disclaimer_
>>
>> 1.
>> i do not know if the problem lies with nvidia-detect, nvidia-driver and its
>> dependencies, or neither
>>
>> 2.
>> this bug report was submitted after removal and revert back to nouveau
>>
>> 3.
>> applies to intel ivy bridge chipset with built-in intel graphics +
>> nvidia below
>>
>>
>>
>> nvidia-detect recommends nvidia-driver
>>
>> i then install nvidia-driver, its dependencies and nvidia-xconfig
>>
>> NB i attempted this ~6 months ago and yesterday, i do not know the affect of
>> the recent nvidia updates to xserver and whether nvidia-xconfig is still
>> necessary
>>
>> gdm3 cannot proceed after reboot
>>
>> please advise any further log provision where necessary:
> 
> Hi,
> 
> It looks like you have a laptop with a switchable Optimus system (610M).
> If that's indeed the case, you cannot just install the nvidia stack, as
> your hardware is wired to use the Intel card to drive the display.
> 
> If you want to use the discrete Nvidia card, you must do so through
> bumblebee. Please install
> 
> bumblebee-nvidia
> 
> Then run:
> 
> sudo update-glx --config glx
> 
> And make sure nvidia/bumblebee is selected, if not pick it.

done above

> 
> If the problem persists, please add more information by running:
> 
> reportbug -N 815888

sorry, this is out ATM, nevertheless...

> Kind regards,
> Luca Boccassi

i get the following:

$ primusrun glxgears
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)

$ optirun glxgears
[23162.070642] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

ive tried various basic amendments such as

adding my user to the bumblebee group;

manually specifying the nvidia option in /etc/bumblebee/bumblebee.conf;

manually specifying BusID "PCI:1:0:0" in /etc/bumblebee/xorg.conf.nvidia
(from the github FAQ)

$ lspci | egrep 'VGA|3D'
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce
610M] (rev a1)

i admit im stuck

Bug#817244: exim4-base: cron noise re environment

[Matthew Vernon]

Package: exim4-base
Version: 4.86.2-2
Severity: normal

Hi,

I now (last few days) get an irritating email every day from anacron,
thus:

/etc/cron.daily/exim4-base:
LOG: MAIN
  WARNING: purging the environment.
 Suggested action: use keep_environment and add_environment.

This is pretty tiresome!

Thanks,

Matthew

-- Package-specific info:
Exim version 4.86_2 #2 built 05-Mar-2016 12:07:31
Copyright (c) University of Cambridge, 1995 - 2015
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2015
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC PRDR 
OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /etc/exim4/exim4.conf
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='local'
dc_other_hostnames='pick.csi.cam.ac.uk'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:pick.csi.cam.ac.uk

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

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: sysvinit (via /sbin/init)

Versions of packages exim4-base depends on:
ii  adduser3.113+nmu3
ii  anacron2.3-23
ii  cron [cron-daemon] 3.0pl1-128
ii  debconf [debconf-2.0]  1.5.58
ii  exim4-config [exim4-config-2]  4.86.2-2
ii  libc6  2.21-9
ii  libdb5.3   5.3.28-11
ii  lsb-base   9.20160110
ii  netbase5.3

Versions of packages exim4-base recommends:
ii  bsd-mailx [mailx] 8.1.2-0.20160123cvs-2
ii  perl-modules-5.22 [perl-modules]  5.22.1-8
ii  psmisc22.21-2.1+b1

Versions of packages exim4-base suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20160123cvs-2
ii  emacs23-lucid [mail-reader]  23.4+1-4
ii  emacs24-lucid [mail-reader]  24.5+1-6+b1
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.25-2
ii  icedove [mail-reader]38.6.0-1
ii  mutt [mail-reader]   1.5.24-1+b1
ii  openssl  1.0.2g-1
pn  spf-tools-perl   
pn  swaks

-- debconf information:
  exim4/purge_spool: false
  exim4-base/drec:

Bug#817190: autopkgtest: doesn't honour T(E)MPDIR

[Martin Pitt]

Control: tag -1 pending

Hello Rene,

Rene Engelhard [2016-03-08 21:54 +0100]:
> adt-run: DBG: sending command to testbed: copydown ./ 
> /tmp/adt-run.Vecb5V/ubtree-./
> 
> /tmp? But I set TMPDIR (and to be sure, TEMPDIR)...

That was an easy one, fixed in

  
http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=3e39ab7a8

Thanks for the report,

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

Bug#812783: dpkg: Please use ASAN, UBSAN and bindnow on hardened1-linux-amd64

[Guillem Jover]

Hi!

On Tue, 2016-03-08 at 11:29:04 +0100, Bálint Réczey wrote:
> 2016-03-08 1:52 GMT+01:00 Guillem Jover :
> > Actually setting bindnow and PIE would be fine as part of the default
> > build flags from dpkg, because those do not change the ABI in
> > principle. And those are the only ones I'd accept from this bug
> > report, but certainly not the ABI changing ones.

> Do you mean you would be open to setting PIE and maybe bindnow as default
> flags for a potential new architecture or even for existing ones like amd64?
> In the latter case would you like to discuss that on debian-devel?
> I would support such changes and I think we are in time for enabling
> PIE for Stretch
> and bindnow for Stretch+1 (maybe Stretch).

Setting PIE and bindnow for the proposed new arch seems fine to me, as
its main raison d'etre is precisely to be hardened. I don't think
anything has changed significantly to globally enable these by default
everywhere though (i.e. performance and potential for breakage, at least).

Thanks,
Guillem

Bug#814276: Non-Free file: src/stdlib/SDL_qsort.c

[Gianfranco Costamagna]

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

Hi Manuel and pkg-sdl maintainers

>   https://hg.libsdl.org/SDL/log/9cec5fe32bca/src/stdlib/SDL_qsort.c

I removed the file from tarball, reimported as dfsg2, copied the file from
https://hg.libsdl.org/SDL/file/a8e53dc3c5a1/src/stdlib/SDL_qsort.c
(the last commit)
extracted as patch, tried to build on amd64 and i386, and everything was good.

I pushed on DebOMatic
http://debomatic-amd64.debian.net/distribution#unstable/libsdl2/2.0.4+dfsg2-1/buildlog
http://debomatic-i386.debian.net/distribution#unstable/libsdl2/2.0.4+dfsg2-1/buildlog

and to me the issue is solved.

I pushed on deferred/2 this one too, let me know if I can speed it up!

cheers,

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#817188: libbamtools-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/libbamtools-dev/html/functions_v.html

[Andreas Beckmann]

On 2016-03-09 10:53, Michael Crusoe wrote:
> I've uploaded a new version though I was unable to replicate the piuparts
> test to verify it. Any guidance on what command I should add to my
> checklist would be appreciated.

That's a special test especially looking for such file overwrite
problems. There are some scripts using DOSE tools to get candidate
package pairs ... so not easily reproducible with standard piuparts tests.


Andreas

Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

[Vincent Lefevre]

Control: reopen -1
Control: found -1 0.7.8-1

On 2016-03-01 18:32:44 +, Manuel A. Fernandez Montecelo wrote:
> 2016-03-01 17:43 Vincent Lefevre:
> > On 2016-03-01 15:02:59 +, Manuel A. Fernandez Montecelo wrote:
> > > 2013-08-31 12:41 Vincent Lefevre:
> > > > When I start "aptitude" (no arguments, curses interface), packages are
> > > > sometimes selected for upgrade by default, for no apparent reason.
> > > > Since this behavior is not documented in the man page, I assume that
> > > > this is a bug.
> > > >
> > > > Such packages are sometimes in a broken state, which is annoying.
> > > 
> > > Has this been happening in recent versions?  I have not experience this
> > > behaviour, at least not in the last few months/years.
> > 
> > I don't think this happened recently. Well, I can't remember,
> > so that I assume that this didn't happen recently.
> 
> I assume that if it starts to happen again you or somebody else will
> report it; so I think that it's better to close this report.

It has just happened again!

The packages selected by default:

iuA libsmbclient   2:4.3.5+dfsg-3   2:4.3.6+dfsg-1
iu  libwbclient0   2:4.3.5+dfsg-3   2:4.3.6+dfsg-1
iuA samba-libs   +28.7 kB  2:4.3.5+dfsg-3   2:4.3.6+dfsg-1

See the attached screenshot.

Before running aptitude, I changed the mirror in /etc/apt/sources.list
due to Hash Sum mismatch errors (reported as Debian bug 817240), and
did "apt-get update". But this is probably not related, if the issue
comes from /var/lib/aptitude/pkgstates, which dates from before the
previous upgrade (see below).

The previous upgrade (from /var/log/aptitude):

Aptitude 0.7.8: log report
Wed, Mar  9 2016 11:16:07 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 42 packages, and remove 0 packages.
346 kB of disk space will be used

[HOLD, DEPENDENCIES] default-jre:amd64 2:1.7-52.1
[HOLD, DEPENDENCIES] default-jre-headless:amd64 2:1.7-52.1
[HOLD] fvwm:amd64 1:2.5.30.ds-1.1+local1
[UPGRADE] clang-3.8:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] clang-3.8-doc:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] firebird2.5-common:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
[UPGRADE] firebird2.5-common-doc:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
[UPGRADE] firebird2.5-server-common:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
[UPGRADE] libclang-common-3.8-dev:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] libclang1-3.8:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] libdebconfclient0:amd64 0.206 -> 0.207
[UPGRADE] libfbclient2:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
[UPGRADE] libfbembed2.5:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
[UPGRADE] libllvm3.8:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] libnspr4:amd64 2:4.11-1 -> 2:4.12-1
[UPGRADE] libopencv-calib3d2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-contrib2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-core2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-features2d2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-flann2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-highgui2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-imgproc2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-legacy2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-ml2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-objdetect2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libopencv-video2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
[UPGRADE] libsmbclient:amd64 2:4.3.5+dfsg-2 -> 2:4.3.5+dfsg-3
[UPGRADE] libwbclient0:amd64 2:4.3.5+dfsg-2 -> 2:4.3.5+dfsg-3
[UPGRADE] llvm-3.8:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] llvm-3.8-dev:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] llvm-3.8-runtime:amd64 1:3.8-1 -> 1:3.8-2
[UPGRADE] mksh:amd64 52b-1 -> 52c-1
[UPGRADE] nano:amd64 2.5.3-1 -> 2.5.3-2
[UPGRADE] openssh-client:amd64 1:7.1p2-2 -> 1:7.2p1-1
[UPGRADE] openssh-server:amd64 1:7.1p2-2 -> 1:7.2p1-1
[UPGRADE] openssh-sftp-server:amd64 1:7.1p2-2 -> 1:7.2p1-1
[UPGRADE] pax:amd64 1:20151013-1 -> 1:20160306-1
[UPGRADE] ruby-domain-name:amd64 0.5.20160216-1 -> 0.5.20160216-2
[UPGRADE] samba-libs:amd64 2:4.3.5+dfsg-2 -> 2:4.3.5+dfsg-3
[UPGRADE] x11-common:amd64 1:7.7+13 -> 1:7.7+14
[UPGRADE] xbase-clients:amd64 1:7.7+13 -> 1:7.7+14
[UPGRADE] xorg:amd64 1:7.7+13 -> 1:7.7+14
[UPGRADE] xserver-xorg:amd64 1:7.7+13 -> 1:7.7+14
[UPGRADE] xserver-xorg-input-all:amd64 1:7.7+13 -> 1:7.7+14
[UPGRADE] xserver-xorg-video-all:amd64 1:7.7+13 -> 1:7.7+14


Log complete.

In /var/log/apt/history.log:

Start-Date: 2016-03-09  11:16:46
Upgrade: xserver-xorg-input-all:amd64 (7.7+13, 7.7+14), xserver-xorg:amd64 
(7.7+13, 7.7+14), llvm-3.8:amd64 (3.8-1, 3.8-2), ruby-domain-name:amd64 
(0.5.20160216-1, 0.5.20160216-2), clang-3.8:amd64 (3.8-1, 3.8-2), 

Bug#817236: schroot: no access to pseudo-terminals in new chroots

[Ansgar Burchardt]

On Wed, 2016-03-09 at 11:41 +0100, Marco d'Itri wrote:
> On Mar 09, Ansgar Burchardt  wrote:
> 
> > in the sbuild profile's fstab. To accommodate old chroots that
> > still
> > have a /dev/ptmx device node, an additional bind mount
> > 
> >   ${chroot}/dev/pts/ptmx   /dev/ptmx   none   rw,bind 0 0
> > 
> > is needed to make sure only the devpts' ptmx device is used. I
> > don't
> > think this can be done via the profile's fstab, but only via a
> > setup
> > script?
> No, a plain bind mount inside the chroot is needed and it can be 
> configured in fstab:
> 
> /dev/pts/ptmx   /dev/ptmx   none   bind 0 0

schroot's fstab differs from the regular fstab:

  The only difference is that the mountpoint path fs_dir is
  relative to the chroot, rather than the root.

An entry like

  /dev/pts/ptmx   /dev/ptmx   none   bind 0 0

thus bind-mounts /dev/pts/ptmx on ${chroot}/dev/ptmx, that is it would
mount the *host's* /dev/pts/ptmx on the chroot's /dev/ptmx. This should
not work.

There doesn't seem a way to specify also the first field relative to
the chroot, thus the likely requirement to handle this in a setup
script.

Ansgar

Bug#817249: liferea keeps animating images even when the window is hidde

[Enrico Zini]

Package: liferea
Version: 1.10.18-1
Severity: normal

Hello,

steps to reproduce:

1. show a post that contains an animated image. Say,
   
http://devopsreactions.tumblr.com/post/137275323038/reviewing-the-interns-commits
2. check top; liferea uses CPU
3. close the liferea window
4. check top; liferea uses CPU just like before
5. show a post that does not contain an animated image, say:
   
http://www.enricozini.org/blog/2016/debian/simple-one-liner-to-save-battery-life-and-reduce-system-latency/
6. close the liferea window
7. check top; liferea is not using CPU

Given that I occasionally need to run my laptop on battery for a long
time, and that its CPU fan is approaching end of life and I would like
it not to spin unless it's really needed, this issue currently means
that I need to take care of clicking somewhere that empties the current
post view in liferea when I'm done reading feeds.

When the window is closed, liferea should really be doing nothing else
than waiting for the next update timers to trigger.


Thank you,

Enrico

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

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

Versions of packages liferea depends on:
ii  dbus-x11 1.10.6-1
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-gtk-3.0   3.18.8-1
ii  gir1.2-peas-1.0  1.16.0-1+b1
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-9
ii  libcairo21.14.6-1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgirepository-1.0-11.46.0-4
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.8-1
ii  libindicate5 0.6.92-2
ii  libjson-glib-1.0-0   1.0.4-2
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpeas-1.0-01.16.0-1+b1
ii  libsoup2.4-1 2.52.2-1
ii  libsqlite3-0 3.10.2-1
ii  libwebkitgtk-3.0-0   2.4.9-3
ii  libxml2  2.9.3+dfsg1-1
ii  libxslt1.1   1.1.28-2.1
ii  liferea-data 1.10.18-1
ii  python-gi3.18.2-2
pn  python:any   

Versions of packages liferea recommends:
ii  gir1.2-gnomekeyring-1.0  3.12.0-1+b1
ii  gnome-icon-theme 3.12.0-1
ii  gnome-keyring3.18.3-1

Versions of packages liferea suggests:
pn  kget 
ii  network-manager  1.1.90-6

-- no debconf information

Bug#744077: nm.debian.org: encoding problems in e-mail headers

[efkin]

On 03/09/2016 12:38 PM, Jakub Wilk wrote:
> * Ben Finney , 2016-03-09, 10:51:
>> On 06-Mar-2016, efkin wrote:
>>> This should fix email headers that were not properly rendered.
>>
>> Thank you, efkin, for making a patch.

Thanks both for quick answering.

>> I think that is addressing the problem in the wrong place.
>>
>> The template tag should not do any encoding. Instead, it should just
>> do template interpolation, and return the Unicode text.
>>
>> Encoding that text for transmission should be done only after the
>> whole message is composed.

I thought about trying to be delicate with the patch and try to refactor
as less code as possible given that these are my first steps towards
contributing in this project.

And at the same time i tried to refactor accordingly to the already
existing code style/logic.

So i thought that it could be a good place to do it.

The problem about moving this operation to
`backend.email.send_notification` or to
`backend.email.template_to_email` for me it relies on coding extra and
unnecesary calls to `email.utils.parseaddr` and `email.utils.formataddr`.

And i understand that a template filter may not be the better place. But
as the `email.utils.formataddr` call was there i thought about the
minimum possible change.

However i could prepare another patch that implements your suggestions
if necessary. Just let me know.

>> So I think the correct solution entails:
>>
>> * In ‘backend.templatetags.nm.formataddr’, remove the ‘encode’ call.
>>
>> * In ‘backend.email.send_notification’, encode all fields of the
>> header (using ‘email.header.Header’ as you suggest).
> 
> No, that wouldn't work:
> 
 email.utils.formataddr((u'Cédric Boutillier', 'bou...@debian.org'))
> u'C\xe9dric Boutillier '
 str(email.header.Header(_))
> '=?utf-8?q?C=C3=A9dric_Boutillier_=3Cboutil=40debian=2Eorg=3E?='
> 
> The result is not a valid address.
> 
> RFC 2047 encoding must be applied only to the display-name part (as it
> was done in the original patch), not the whole address.

Exactly.

bests,

efkin.

Bug#817250: ITP: libapp-cell-perl -- configuration, error-handling, localization, and logging "framework"

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libapp-cell-perl
  Version : 0.219
  Upstream Author : Smithfarm 
* URL : https://metacpan.org/pod/App::CELL
* License : BSD-3-clause
  Programming Lang: Perl
  Description : configuration, error-handling, localization, and logging 
"framework"

 App::CELL is the Configuration, Error-handling, Localization, and
 Logging (CELL) framework for applications written in Perl.
 .
 In the author's experience, applications written for "users" (however
 that term may be defined) frequently need to:
 .
  * be configurable by the user or site administrator
  * handle errors robustly, without hangs and crashes
  * potentially display messages in various languages
  * log various types of messages to syslog
 .
 Since these basic functions seem to work well together, CELL is
 designed to provide them in an integrated, well-documented,
 straightforward, and reusable package.

Package will be maintained in the Debian Perl team.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIbBAEBAgAGBQJW4Br+AAoJECx8MUbBoAEhbk4P93l4yq1Kqzw5U3ml7R2LF54D
NDW/BcvQzqYH1/rvpf0vN+9xYKDszXgasHEgBiHhtgiLfDsFACBsko7epzWVna6p
FSEgK129UJkxuAVniQ83bgGUDxePus+JFzZi9te5JtEZH19Xk0UMf1brLm+zjCUo
e52jGDwaC4+JsqtFmjFdf9ACcnX6CfhE65VgmIKYmOOB0FUj+136WxP01q+M0N6U
l67knGT38VTdyaSaf5WM47AEXJQWjeZaAtTRrViKCJ8MXHpr3+lf0/AT7tee5Ojm
GFDvZBHZjsz7L6SwDPz5cmTxhfh31DUIZOh/6TQGq3aabr4UO0AhcptEdVUsvFLU
wDymeAJMI0OXOe4aV46QyLLLKcy2YuECaQ0G6LNddru/NJZpvLDh70A1oKjt4bWd
6cBrI3p5uGsmeOt6VDy/TPl4EPwkVxi0pT5sU1HKFcR3hZNyaLBZG1UyurFXHcrf
LwTmT1O4OvQWwKnH4ekwwY396kYjMH8/lzvMAJYgzNbv7ThVUlP6MsJRqyqG7f/c
/Whxa6nF1adClEpUx8MLZ2Agt0BWglT1i4NF4hh3xGzPi9XEa4+1W7OfZt3xlMoc
ixzs035kf6cqFY327hrgtI9PkU6bO2O/zQ23kwVW4+wQeLFU14Jootiqq2hXKrPK
bE56/yOdFMQqtollBYQ=
=qEBQ
-END PGP SIGNATURE-

Bug#817251: RM: shinken-mod-webui -- ROM; Obsolete, unmaintained, superseeded by webui2

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove this package.

See also #817161.

Regards

Mathieu Parent

Bug#817252: Objet

[guillaume . b]

Package: firefox

firefox has crashed when i was going to youtube...

root@pc:/home/sylvia# which firefox
/usr/bin/firefox

root@pc:/home/sylvia# type firefox
firefox est /usr/bin/firefox

root@pc:/home/sylvia# dpkg --search /usr/bin/firefox
détournement par iceweasel depuis : /usr/bin/firefox
détournement par iceweasel en : /usr/bin/firefox.real
iceweasel: /usr/bin/firefox

root@pc:/home/sylvia# dpkg --list firefox
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
|
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err:
majuscule=mauvais)
||/ Nom    Version  Architecture
Description
+++-==---=
un  firefox      (aucune description
n'est disponi

root@pc:/home/sylvia# dpkg --status firefox
dpkg-query: le paquet « firefox » n'est pas installé et aucune
information n'est disponible
Utilisez dpkg --info (= dpkg-deb --info) pour examiner les fichiers
archives, et dpkg --contents (= dpkg-deb --contents) pour afficher
leur
contenu.

Here is the message i got from the terminal (lxterminal) when i was
using iceweasel that has been launched from the terminal :

sylvia@pc:~$ firefox

(process:1718): GLib-CRITICAL **: g_slice_set_config: assertion
'sys_page_size == 0' failed
console.error:
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
console.error:
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
Vector smash protection is enabled.
Failed to open VDPAU backend libvdpau_nvidia.so: Ne peut ouvrir le
fichier d'objet partagé: Aucun fichier ou dossier de ce type
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva
error,driver_name=(null)
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva
error,driver_name=(null)
[NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
/tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
1584
[NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
/tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
1584
Erreur de segmentation

sylvia@pc:~$ firefox

(process:1718): GLib-CRITICAL **: g_slice_set_config: assertion
'sys_page_size == 0' failed
consoleerror:
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
console.error:
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
Vector smash protection is enabled.
Failed to open VDPAU backend libvdpau_nvidia.so: Ne peut ouvrir le
fichier d'objet partagé: Aucun fichier ou dossier de ce type
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva
error,driver_name=(null)
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva
error,driver_name=(null)
[NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
/tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
1584
[NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
/tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
1584
Erreur de segmentation
sylvia@pc:~$

Bug#528767: 'The Three Meanings of "Lock"' += svn:sync-lock ?

[Daniel Shahaf]

Concerning the 'The Three Meanings of "Lock"' box:
.

http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html#svn.advanced.locking.meanings
.
Should that box mention svnsync locks as well?

(These are the svn_ra__get_operational_lock() locks that svnsync takes
using the svn:sync-lock revprop, exposed in the UI through the
--disable-locks/--steal-lock options to 'svnsync sync'.  Note 'svnrdump
load' also uses this kind of operational lock.)

Cheers,

Daniel
(Asking because I just ran into an old Debian bug report where a user
looked in svnadmin for how to remove an svn:sync-lock; and `svnadmin
help | grep lock` wouldn't have helped him.)

Bug#817254: pam-ssh-agent-auth: Please upload to unstable

[Balint Reczey]

Package: pam-ssh-agent-auth
Version: 0.10.2-1
Severity: wishlist


Dear Maintainer,

Please upload the package to unstable as it spent enough time in
experimental and have not received new bugs.

I would happily offer sponsorship for the upload if needed.

Cheers,
Balint

Bug#528767: /usr/bin/svnsync: svnsync should propdelete svn:sync-lock on request

[Daniel Shahaf]

[ Replying to an ancient bug.  Sorry for the late response: this must
have slipped through the cracks. ]

Tobias Fünky wrote on Fri, May 15, 2009 at 12:31:22 +0200:
> If svnsync would provide a command, which just fires the above mentioned 
> propdelete and -- more important -- provides documentation of this, it would
> give some benefit to stressed admins. 

As of 1.8, 'svnsync sync' takes a --steal-lock argument which handles
this transparently:

% svnsync h sync
⋮
  --disable-locking: Disable built-in locking.  Use of this option can
 corrupt the mirror unless you ensure that no other
 instance of svnsync is running concurrently.
  --steal-lock : Steal locks as necessary.  Use, with caution,
 if your mirror repository contains stale locks
 and is not being concurrently accessed by another
 svnsync instance.

That said, perhaps the error message you got ("svnsync: Couldn't get
lock on destination repos after 10 attempts") should suggest the
--steal-lock option.

> Most important on this wish item are two lines of documentation at the right 
> place, which is 'svnadmin help'.

I don't think svnsync locks should be documented in svnadmin; they should
be documented in the documentation of svnsync and in this book section:
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html#svn.advanced.locking.meanings

I've followed up on svnbook-dev@ about the latter.

Cheers,

Daniel

Bug#817245: RFS: yamllint/1.2.0-1

[Paul Wise]

On Wed, Mar 9, 2016 at 8:14 PM, Adrien Vergé wrote:
> 2016-03-09 12:43 GMT+01:00 Gianfranco Costamagna:
>> +override_dh_installman:
>> +   dh_installman build/man/yamllint.1
>
> Yes you're right, this is for man page auto-generation.

Probably the upstream build system should also install the manual
page, please do that for the next version.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#817255: cleancss: depends on material in /usr/share/doc

[ydirson]

Package: cleancss
Version: 1.0.12-1
Severity: serious

Removing /usr/share/doc should be allowed, as per policy 12.3.

but:

var packageConfig = 
fs.readFileSync('/usr/share/doc/node-clean-css/package.json');

Bug#817256: kde-standard: KDE print dialog forgets settings

[Harven]

Package: kde-standard
Version: 5:90
Severity: normal

Dear Maintainer,

The KDE print dialog does not remember any changes made to its settings.
This is annoying especially for settings like duplex: The user needs to
remember
for _every_ print action to recheck the duplex printing option in one of the
settings tab.

Reproducible: Always

Steps to Reproduce:
1. Print a document, set duplex to on in the kprinter dialog
2. Print another document on the same printer, find that duplex is off

The bug has been submitted to the kde and opensuse bug tracker a few years ago
but does not seem to be solved in debian.
https://bugs.kde.org/show_bug.cgi?id=180051
https://bugzilla.novell.com/show_bug.cgi?id=552218

There is a patch at the following address
https://bugs.kde.org/show_bug.cgi?id=180051#c29



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

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

Versions of packages kde-standard depends on:
ii  akregator  4:4.14.10-2
ii  ark4:15.08.3-1
ii  dragonplayer   4:15.08.3-1
ii  gwenview   4:15.08.3-1
ii  juk4:15.08.3-1
ii  kaddressbook   4:4.14.10-2
ii  kate   4:15.08.3-1
ii  kcalc  4:15.08.3-1
ii  kde-plasma-desktop 5:90
ii  khelpcenter4:5.4.3-1
ii  kmail  4:4.14.10-2
ii  kmix   4:15.08.1-1
ii  knotes 4:4.14.10-2
ii  kopete 4:15.08.3-1+b1
ii  korganizer 4:4.14.10-2
ii  ksnapshot  4:15.08.0-1
ii  kwalletmanager 4:15.08.3-1
ii  okular 4:15.08.3-1
ii  plasma-dataengines-addons  4:5.4.3-1
ii  plasma-pa  5.4.3-1
ii  plasma-runners-addons  4:5.4.3-1
ii  plasma-wallpapers-addons   4:5.4.3-1
ii  plasma-widgets-addons  4:5.4.3-1
ii  polkit-kde-agent-1 4:5.4.3-1
ii  sweeper4:4.12.2-2

Versions of packages kde-standard recommends:
ii  freespacenotifier  4:4.11.13-2
pn  konq-plugins   
ii  kwin-x11   4:5.4.3-1.1
ii  plasma-nm  4:5.4.3-1

Versions of packages kde-standard suggests:
pn  kde-l10n  
ii  skanlite  1.0-2

-- no debconf information

Bug#796625: clvm+corosync fails to start

[Ulf Norberg]

Package: clvm
Version: 2.02.111-2.2
Followup-For: Bug #796625

Hi,

we run a storage cluster with CLVM+GFS2 and have been hit by this
problem.  LSB service clvm.service gets deleted from the start up
sequence by systemd because of dependency conflicts.  journalctl
shows:

 systemd[1]: Found ordering cycle on basic.target/start
 systemd[1]: Found dependency on sysinit.target/start
 systemd[1]: Found dependency on clvm.service/start
 systemd[1]: Found dependency on corosync.service/start
 systemd[1]: Found dependency on basic.target/start
 systemd[1]: Breaking ordering cycle by deleting job clvm.service/start
 systemd[1]: Job clvm.service/start deleted to break ordering cycle starting
with basic.target/start

The same problem is reported in #788295 (see under "MINUTIAE:").

In the LSB comment header of /etc/init.d/clvm it says:

# Should-Start:  cman corosync openais

but /etc/init.d/corosync (corosync-1.4.6-1.1) is set to start in
runlevels 2-5:

# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6

So, systemd cannot start corosync before clvm.

The systemd unit-files /lib/systemd/system/lvm2-clvmd.service and
/lib/systemd/system/lvm2-cluster-activation.service are installed
by the clvm package, but they are not adapted to debian.  My
solution was to edit these files and copy them to
/etc/systemd/system (included below).  Mask the LSB service
clvm.service:

systemctl mask clvm.service

and enable the systemd service/unit:

systemctl enable lvm2-cluster-activation.service



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/64 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 clvm depends on:
ii  libc6 2.19-18+deb8u3
ii  libcman3  3.1.8-1.2+b1
ii  libconfdb41.4.6-1.1
ii  libcpg4   1.4.6-1.1
ii  libdevmapper-event1.02.1  2:1.02.90-2.2
ii  libdevmapper1.02.12:1.02.90-2.2
ii  libdlm3   3.1.8-1.2+b1
ii  libquorum41.4.6-1.1
ii  libsalck3 1.1.4-4.2
ii  libudev1  215-17+deb8u3
ii  lsb-base  4.1+Debian13+nmu1
ii  lvm2  2.02.111-2.2

Versions of packages clvm recommends:
ii  cman  3.1.8-1.2+b1
ii  corosync  1.4.6-1.1
ii  openais   1.1.4-4.2

clvm suggests no packages.

-- no debconf information

*** /etc/systemd/system/lvm2-clvmd.service
[Unit]
Description=Clustered LVM daemon
Documentation=man:clvmd(8)
After=cman.service corosync.service
Before=remote-fs-pre.target
Requires=network.target cman.service corosync.service
RefuseManualStart=true
RefuseManualStop=true
StopWhenUnneeded=true
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=forking
Environment=CLVMD_OPTS=-T30
EnvironmentFile=-/etc/default/clvm
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
SuccessExitStatus=5
TimeoutStartSec=30
TimeoutStopSec=10
OOMScoreAdjust=-1000




*** /etc/systemd/system/lvm2-cluster-activation.service
[Unit]
Description=Clustered LVM volumes activation service
Requires=lvm2-clvmd.service
After=lvm2-clvmd.service lvm2-cmirrord.service
OnFailure=lvm2-clvmd.service
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=simple
RemainAfterExit=yes
EnvironmentFile=-/etc/default/clvm
ExecStart=/lib/systemd/lvm2-cluster-activation activate
ExecStop=/lib/systemd/lvm2-cluster-activation deactivate
[Unit]
Description=Clustered LVM daemon
Documentation=man:clvmd(8)
After=cman.service corosync.service
Before=remote-fs-pre.target
Requires=network.target cman.service corosync.service
RefuseManualStart=true
RefuseManualStop=true
StopWhenUnneeded=true
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=forking
Environment=CLVMD_OPTS=-T30
EnvironmentFile=-/etc/default/clvm
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
SuccessExitStatus=5
TimeoutStartSec=30
TimeoutStopSec=10
OOMScoreAdjust=-1000
Restart=on-abort
PIDFile=/var/run/clvmd.pid

Bug#815888: nvidia-detect: GF119M [GeForce 610M] nvidia-detect=ok for nvidia-driver . . . not ok

[Fulano Diego Perez]

Luca Boccassi:
> On 9 March 2016 at 11:49, Fulano Diego Perez  
> wrote:
>> hi luca,
>>
>> Luca Boccassi:
>>> On 9 March 2016 at 10:05, Fulano Diego Perez  
>>> wrote:
 hi luca

 Luca Boccassi:
> Control: package -1 nvidia-driver
> Control: tag -1 moreinfo
> Control: severity -1 normal
>
> On Thu, 2016-02-25 at 23:34 +1100, Fulano Diego Perez wrote:
>> Package: nvidia-detect
>> Severity: grave
>> Justification: renders package unusable
>>
>>
>> _disclaimer_
>>
>> 1.
>> i do not know if the problem lies with nvidia-detect, nvidia-driver and 
>> its
>> dependencies, or neither
>>
>> 2.
>> this bug report was submitted after removal and revert back to nouveau
>>
>> 3.
>> applies to intel ivy bridge chipset with built-in intel graphics +
>> nvidia below
>>
>>
>>
>> nvidia-detect recommends nvidia-driver
>>
>> i then install nvidia-driver, its dependencies and nvidia-xconfig
>>
>> NB i attempted this ~6 months ago and yesterday, i do not know the 
>> affect of
>> the recent nvidia updates to xserver and whether nvidia-xconfig is still
>> necessary
>>
>> gdm3 cannot proceed after reboot
>>
>> please advise any further log provision where necessary:
>
> Hi,
>
> It looks like you have a laptop with a switchable Optimus system (610M).
> If that's indeed the case, you cannot just install the nvidia stack, as
> your hardware is wired to use the Intel card to drive the display.
>
> If you want to use the discrete Nvidia card, you must do so through
> bumblebee. Please install
>
> bumblebee-nvidia
>
> Then run:
>
> sudo update-glx --config glx
>
> And make sure nvidia/bumblebee is selected, if not pick it.

 done above

>
> If the problem persists, please add more information by running:
>
> reportbug -N 815888

 sorry, this is out ATM, nevertheless...

> Kind regards,
> Luca Boccassi

 i get the following:

 $ primusrun glxgears
 primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)

 $ optirun glxgears
 [23162.070642] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

 ive tried various basic amendments such as

 adding my user to the bumblebee group;

 manually specifying the nvidia option in /etc/bumblebee/bumblebee.conf;

 manually specifying BusID "PCI:1:0:0" in /etc/bumblebee/xorg.conf.nvidia
 (from the github FAQ)

 $ lspci | egrep 'VGA|3D'
 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
 processor Graphics Controller (rev 09)
 01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce
 610M] (rev a1)

 i admit im stuck
>>>
>>> Hi,
>>>
>>> Sorry for your troubles.
>>>
>>> Unfortunately there's not much I can do without looking at the full
>>> system report. If reportbug -N is not working for you, could you
>>> please manually attach the output of:
>>
>> sure makes sense
>>
>>> reportbug --template nvidia-driver
>>
>> i enclose
>>
>> thanks for your help
> 
> Hi,
> 
>>From the log, it looks like nouveau is being loaded:
> 
> 2367.838] (II) LoadModule: "nouveau"
> [  2367.838] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
> [  2367.838] (II) Module nouveau: vendor="X.Org Foundation"
> [  2367.838] compiled for 1.18.0, module version = 1.0.12
> [  2367.838] Module class: X.Org Video Driver
> [  2367.838] ABI class: X.Org Video Driver, version 20.0
> 
> 
> 
> [  2367.839] (II) NOUVEAU driver Date:   Tue Dec 8 15:52:25 2015 +1000
> [  2367.839] (II) NOUVEAU driver for NVIDIA chipset families :
> [  2367.839] RIVA TNT(NV04)
> [  2367.839] RIVA TNT2   (NV05)
> [  2367.840] GeForce 256 (NV10)
> [  2367.840] GeForce 2   (NV11, NV15)
> [  2367.840] GeForce 4MX (NV17, NV18)
> [  2367.840] GeForce 3   (NV20)
> [  2367.840] GeForce 4Ti (NV25, NV28)
> [  2367.840] GeForce FX  (NV3x)
> [  2367.840] GeForce 6   (NV4x)
> [  2367.840] GeForce 7   (G7x)
> [  2367.840] GeForce 8   (G8x)
> [  2367.840] GeForce GTX 200 (NVA0)
> [  2367.840] GeForce GTX 400 (NVC0)
> 
> 
> Even though the module is blacklisted.
> 
> Have you rebooted after installing the nvidia stuff?

yes, actually ive only come back to this after about 2 weeks

> 
> To make sure the module configs are parsed and up to date, please run:
> 
> sudo depmod
> sudo update-initramfs -u

yep

> 
> and then reboot and try again.

ok, i rebooted

seems not to work again:

$ primusrun glxgears
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)

$ optirun glxgears
[  169.135208] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

[  169.135306] [WARN]The Bumblebee server was not available.
Running synchronized to the vertical 

Bug#817252: Objet

[Mattia Rizzolo]

control: reassign -1 iceweasel

On Wed, Mar 09, 2016 at 02:02:28PM +0100, guillaum...@net2000.ch wrote:
> Package: firefox

the package name is "iceweasel", reassigning appropriately so that the
iceweasel maintainers can see this bug.

> 
> firefox has crashed when i was going to youtube...
> 
> root@pc:/home/sylvia# which firefox
> /usr/bin/firefox
> 
> root@pc:/home/sylvia# type firefox
> firefox est /usr/bin/firefox
> 
> root@pc:/home/sylvia# dpkg --search /usr/bin/firefox
> détournement par iceweasel depuis : /usr/bin/firefox
> détournement par iceweasel en : /usr/bin/firefox.real
> iceweasel: /usr/bin/firefox
> 
> root@pc:/home/sylvia# dpkg --list firefox
> Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
> |
> État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
> |/ Err?=(aucune)/besoin Réinstallation (État,Err:
> majuscule=mauvais)
> ||/ Nom    Version  Architecture
> Description
> +++-==---=
> un  firefox      (aucune description
> n'est disponi
> 
> root@pc:/home/sylvia# dpkg --status firefox
> dpkg-query: le paquet « firefox » n'est pas installé et aucune
> information n'est disponible
> Utilisez dpkg --info (= dpkg-deb --info) pour examiner les fichiers
> archives, et dpkg --contents (= dpkg-deb --contents) pour afficher
> leur
> contenu.
> 
> Here is the message i got from the terminal (lxterminal) when i was
> using iceweasel that has been launched from the terminal :
> 
> sylvia@pc:~$ firefox
> 
> (process:1718): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> console.error:
>   [CustomizableUI]
>   Custom widget with id loop-button does not return a valid node
> console.error:
>   [CustomizableUI]
>   Custom widget with id loop-button does not return a valid node
> Vector smash protection is enabled.
> Failed to open VDPAU backend libvdpau_nvidia.so: Ne peut ouvrir le
> fichier d'objet partagé: Aucun fichier ou dossier de ce type
> libva info: VA-API version 0.36.0
> libva info: va_getDriverName() returns -1
> libva error: va_getDriverName() failed with unknown libva
> error,driver_name=(null)
> libva info: VA-API version 0.36.0
> libva info: va_getDriverName() returns -1
> libva error: va_getDriverName() failed with unknown libva
> error,driver_name=(null)
> [NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
> /tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
> 1584
> [NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
> /tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
> 1584
> Erreur de segmentation
> 
> sylvia@pc:~$ firefox
> 
> (process:1718): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> consoleerror:
>   [CustomizableUI]
>   Custom widget with id loop-button does not return a valid node
> console.error:
>   [CustomizableUI]
>   Custom widget with id loop-button does not return a valid node
> Vector smash protection is enabled.
> Failed to open VDPAU backend libvdpau_nvidia.so: Ne peut ouvrir le
> fichier d'objet partagé: Aucun fichier ou dossier de ce type
> libva info: VA-API version 0.36.0
> libva info: va_getDriverName() returns -1
> libva error: va_getDriverName() failed with unknown libva
> error,driver_name=(null)
> libva info: VA-API version 0.36.0
> libva info: va_getDriverName() returns -1
> libva error: va_getDriverName() failed with unknown libva
> error,driver_name=(null)
> [NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
> /tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
> 1584
> [NPAPI 1788] ###!!! ABORT: Aborting on channel error.: file
> /tmp/buildd/iceweasel-38.6.1esr/ipc/glue/MessageChannel.cpp, line
> 1584
> Erreur de segmentation
> sylvia@pc:~$
> 
> 

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Rostislav Pehlivanov]

Upgrading to the latest libnss3 (3.23) fixes the problem.
Since the bug has been fixed could the maintainers close it?

Thanks

Bug#815888: nvidia-detect: GF119M [GeForce 610M] nvidia-detect=ok for nvidia-driver . . . not ok

[Luca Boccassi]

On 9 March 2016 at 13:42, Fulano Diego Perez  wrote:
>
>
> Luca Boccassi:
>> On 9 March 2016 at 11:49, Fulano Diego Perez  
>> wrote:
>>> hi luca,
>>>
>>> Luca Boccassi:
 On 9 March 2016 at 10:05, Fulano Diego Perez  
 wrote:
> hi luca
>
> Luca Boccassi:
>> Control: package -1 nvidia-driver
>> Control: tag -1 moreinfo
>> Control: severity -1 normal
>>
>> On Thu, 2016-02-25 at 23:34 +1100, Fulano Diego Perez wrote:
>>> Package: nvidia-detect
>>> Severity: grave
>>> Justification: renders package unusable
>>>
>>>
>>> _disclaimer_
>>>
>>> 1.
>>> i do not know if the problem lies with nvidia-detect, nvidia-driver and 
>>> its
>>> dependencies, or neither
>>>
>>> 2.
>>> this bug report was submitted after removal and revert back to nouveau
>>>
>>> 3.
>>> applies to intel ivy bridge chipset with built-in intel graphics +
>>> nvidia below
>>>
>>>
>>>
>>> nvidia-detect recommends nvidia-driver
>>>
>>> i then install nvidia-driver, its dependencies and nvidia-xconfig
>>>
>>> NB i attempted this ~6 months ago and yesterday, i do not know the 
>>> affect of
>>> the recent nvidia updates to xserver and whether nvidia-xconfig is still
>>> necessary
>>>
>>> gdm3 cannot proceed after reboot
>>>
>>> please advise any further log provision where necessary:
>>
>> Hi,
>>
>> It looks like you have a laptop with a switchable Optimus system (610M).
>> If that's indeed the case, you cannot just install the nvidia stack, as
>> your hardware is wired to use the Intel card to drive the display.
>>
>> If you want to use the discrete Nvidia card, you must do so through
>> bumblebee. Please install
>>
>> bumblebee-nvidia
>>
>> Then run:
>>
>> sudo update-glx --config glx
>>
>> And make sure nvidia/bumblebee is selected, if not pick it.
>
> done above
>
>>
>> If the problem persists, please add more information by running:
>>
>> reportbug -N 815888
>
> sorry, this is out ATM, nevertheless...
>
>> Kind regards,
>> Luca Boccassi
>
> i get the following:
>
> $ primusrun glxgears
> primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)
>
> $ optirun glxgears
> [23162.070642] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)
>
> ive tried various basic amendments such as
>
> adding my user to the bumblebee group;
>
> manually specifying the nvidia option in /etc/bumblebee/bumblebee.conf;
>
> manually specifying BusID "PCI:1:0:0" in /etc/bumblebee/xorg.conf.nvidia
> (from the github FAQ)
>
> $ lspci | egrep 'VGA|3D'
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> processor Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce
> 610M] (rev a1)
>
> i admit im stuck

 Hi,

 Sorry for your troubles.

 Unfortunately there's not much I can do without looking at the full
 system report. If reportbug -N is not working for you, could you
 please manually attach the output of:
>>>
>>> sure makes sense
>>>
 reportbug --template nvidia-driver
>>>
>>> i enclose
>>>
>>> thanks for your help
>>
>> Hi,
>>
>>>From the log, it looks like nouveau is being loaded:
>>
>> 2367.838] (II) LoadModule: "nouveau"
>> [  2367.838] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
>> [  2367.838] (II) Module nouveau: vendor="X.Org Foundation"
>> [  2367.838] compiled for 1.18.0, module version = 1.0.12
>> [  2367.838] Module class: X.Org Video Driver
>> [  2367.838] ABI class: X.Org Video Driver, version 20.0
>>
>> 
>>
>> [  2367.839] (II) NOUVEAU driver Date:   Tue Dec 8 15:52:25 2015 +1000
>> [  2367.839] (II) NOUVEAU driver for NVIDIA chipset families :
>> [  2367.839] RIVA TNT(NV04)
>> [  2367.839] RIVA TNT2   (NV05)
>> [  2367.840] GeForce 256 (NV10)
>> [  2367.840] GeForce 2   (NV11, NV15)
>> [  2367.840] GeForce 4MX (NV17, NV18)
>> [  2367.840] GeForce 3   (NV20)
>> [  2367.840] GeForce 4Ti (NV25, NV28)
>> [  2367.840] GeForce FX  (NV3x)
>> [  2367.840] GeForce 6   (NV4x)
>> [  2367.840] GeForce 7   (G7x)
>> [  2367.840] GeForce 8   (G8x)
>> [  2367.840] GeForce GTX 200 (NVA0)
>> [  2367.840] GeForce GTX 400 (NVC0)
>>
>>
>> Even though the module is blacklisted.
>>
>> Have you rebooted after installing the nvidia stuff?
>
> yes, actually ive only come back to this after about 2 weeks
>
>>
>> To make sure the module configs are parsed and up to date, please run:
>>
>> sudo depmod
>> sudo update-initramfs -u
>
> yep
>
>>
>> and then reboot and try again.
>
> ok, i rebooted
>
> seems not to work again:
>
> $ primusrun glxgears
> primus: 

Bug#817257: ants: FTBFS: mixes itk::OptimizerParameters and itk::OptimizerParameters

[Andreas Beckmann]

Source: ants
Version: 2.1.0-4
Severity: serious
Justification: fails to build from source

Hi,

after fixing the B-D to use libdcmtk-dev, ants FTBFS with mixing up
double and float:

[  1%] Building CXX object 
Examples/CMakeFiles/antsUtilities.dir/antsRegistration2DFloat.cxx.o
cd /build/ants-2.1.0/obj-x86_64-linux-gnu/Examples && /usr/bin/c++   
-DITK_IO_FACTORY_REGISTER_MANAGER 
-I/build/ants-2.1.0/obj-x86_64-linux-gnu/Examples 
-I/build/ants-2.1.0/Examples/. -I/build/ants-2.1.0/Examples/../Temporary 
-I/build/ants-2.1.0/Examples/../Tensor 
-I/build/ants-2.1.0/Examples/../GraphTheory 
-I/build/ants-2.1.0/Examples/../ImageSegmentation 
-I/build/ants-2.1.0/Examples/../ImageRegistration 
-I/build/ants-2.1.0/Examples/../Utilities 
-I/build/ants-2.1.0/obj-x86_64-linux-gnu/ITKIOFactoryRegistration 
-I/usr/include/hdf5/serial -I/usr/include/dcmtk/dcmseg 
-I/usr/include/dcmtk/dcmfg -I/usr/include/dcmtk/dcmiod 
-I/usr/include/dcmtk/dcmrt -I/usr/include/dcmtk/dcmpstat 
-I/usr/include/dcmtk/dcmqrdb -I/usr/include/dcmtk/dcmwlm 
-I/usr/include/dcmtk/dcmsign -I/usr/include/dcmtk/dcmsr 
-I/usr/include/dcmtk/dcmnet -I/usr/include/dcmtk/dcmtls 
-I/usr/include/dcmtk/dcmjpls -I/usr/include/dcmtk/dcmjpeg 
-I/usr/include/dcmtk/dcmimage -I/usr/include/dcmtk/dcmimgle 
-I/usr/include/dcmtk/dcmdat
 a -I/usr/include/dcmtk/oflog -I/usr/include/dcmtk/ofstd 
-I/usr/include/dcmtk/config -I/usr/include/x86_64-linux-gnu 
-I/usr/include/gdcm-2.6 -I/usr/include/double-conversion -I/usr/include/ITK-4.9 
 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2   -Wall -Wcast-align -Wdisabled-optimization -Wextra 
-Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow 
-Wunused -Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated 
-Wno-invalid-offsetof -Woverloaded-virtual -Wstrict-null-sentinel -fPIC-o 
CMakeFiles/antsUtilities.dir/antsRegistration2DFloat.cxx.o -c 
/build/ants-2.1.0/Examples/antsRegistration2DFloat.cxx
In file included from 
/build/ants-2.1.0/Examples/itkantsRegistrationHelper.hxx:8:0,
 from 
/build/ants-2.1.0/Examples/itkantsRegistrationHelper.h:1120,
 from 
/build/ants-2.1.0/Examples/antsRegistrationTemplateHeader.h:14,
 from /build/ants-2.1.0/Examples/antsRegistration2DFloat.cxx:1:
/build/ants-2.1.0/Examples/antsRegistrationOptimizerCommandIterationUpdate.h: 
In instantiation of 'void 
ants::antsRegistrationOptimizerCommandIterationUpdate::UpdateFullScaleMetricValue(itk::WeakPointer, 
ants::antsRegistrationOptimizerCommandIterationUpdate::MeasureType&) const [with ParametersValueType = 
float; unsigned int VImageDimension = 2u; TOptimizer = 
itk::GradientDescentOptimizerv4Template; 
ants::antsRegistrationOptimizerCommandIterationUpdate::MeasureType = float]':
/build/ants-2.1.0/Examples/antsRegistrationOptimizerCommandIterationUpdate.h:131:9:
   required from 'void 
ants::antsRegistrationOptimizerCommandIterationUpdate::Execute(const itk::Object*, const 
itk::EventObject&) [with ParametersValueType = float; unsigned int 
VImageDimension = 2u; TOptimizer = 
itk::GradientDescentOptimizerv4Template]'
/build/ants-2.1.0/Examples/antsRegistration2DFloat.cxx:11:1:   required from 
here
/build/ants-2.1.0/Examples/antsRegistrationOptimizerCommandIterationUpdate.h:261:71:
 error: invalid initialization of reference of type 'const ParametersType& {aka 
const itk::OptimizerParameters&}' from expression of type 'const 
FixedParametersType {aka const itk::OptimizerParameters}'
   inputFixedTransform->GetNthTransform(i)->GetFixedParameters();
   ^
/build/ants-2.1.0/Examples/antsRegistrationOptimizerCommandIterationUpdate.h:263:9:
 error: no matching function for call to 'itk::Transform::SetFixedParameters(const ParametersType&)'
 subTransform->SetFixedParameters( fixedImage_fixed_paras );
 ^
In file included from /usr/include/ITK-4.9/itkMatrixOffsetTransformBase.h:24:0,
 from /usr/include/ITK-4.9/itkAffineTransform.h:21,
 from 
/build/ants-2.1.0/Examples/../Utilities/ReadWriteData.h:16,
 from /build/ants-2.1.0/Examples/itkantsRegistrationHelper.h:21,
 from 
/build/ants-2.1.0/Examples/antsRegistrationTemplateHeader.h:14,
 from /build/ants-2.1.0/Examples/antsRegistration2DFloat.cxx:1:
/usr/include/ITK-4.9/itkTransform.h:381:16: note: candidate: void 
itk::Transform::SetFixedParameters(const FixedParametersType&) [with 
TParametersValueType = float; unsigned int NInputDimensions = 2u; unsigned int 
NOutputDimensions = 2u; itk::Transform

Bug#815248: liblcms2: Writes uninitialized strings when writing named colors

[Jérémy Bobbio]

Thomas Weber:
> > When writing named colors, liblcms2 currently writes uninitialized memory
> > when the prefix, suffix, or root color name strings are not
> > 32-characters long (including the NULL terminator). This prevents colord
> > from building reproducibly.
> > 
> > The attached patch will zero the memory before copying the profile
> > strings to ensure a consistent output.
> 
> I am a bit unsure about the fact that you reduced the size of root[33]
> to root[32]. Even if this works out okay in the current code base, such
> a change should be made globally (i.e., _cms_NAMEDCOLORLIST_struct
> should be changed).
> 
> What is your opinion on that?

The spec says the field to be 32 bytes long. Every other instance
of the code uses a 32 bytes long array. And IIRC, only 32 bytes could
ever be copied from the array, so assumed it was a typo while looking at
the code. It should probably be a separate patch…

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#817205: [php-maint] Bug#817205: Unable to load dynamic library '/usr/lib/php/20151012/zlib.so'

[積丹尼 Dan Jacobson]

Yes, it seems the versions on that machine before upgrade were
php-cli:all/unstable 1:7.0+32 uptodate
php-common:all/unstable 1:7.0+32 uptodate
php-doc:all/unstable 20140201-1 uptodate
php-elisp:all/unstable 1.13.5-2 uptodate
php-json:all/unstable 1:7.0+32 uptodate
php7.0-cli:i386/unstable 7.0.3-10 uptodate
php7.0-common:i386/unstable 7.0.3-10 uptodate
php7.0-json:i386/unstable 7.0.3-10 uptodate
php7.0-opcache:i386/unstable 7.0.3-10 uptodate
php7.0-readline:i386/unstable 7.0.3-10 uptodate

Bug#817245: RFS: yamllint/1.2.0-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo.
Hi, I see other changes:

+ python3-sphinx, (ok, this might be under the "build manpage umbrella"


- .
- On Debian systems, the complete text of the GNU General
- Public License version 3 can be found in "/usr/share/common-licenses/GPL-3".


+override_dh_installman:
+   dh_installman build/man/yamllint.1


I prefer a debian/manpages file, but this is just me :)

another issue:
Depends:
python3-yaml,


this should be already taken care with python3:Depends, because yaml
is listed in setup.py -> install_requires.
(please check, I didn't try the above)

the other stuff looks really good to me!

if you can address (some) of the above points, I'll happily sponsor it.

cheers,
Gianfranco

Bug#817247: fatrace: sigsegv on -p option

[Yuriy M. Kaminskiy]

Package: fatrace
Version: 0.11-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

`fatrace -p 1234` dies with SIGSEGV on line 311, as short-option 'p' is 
labeled as flag (instead of option-with-argument), so optarg is NULL. 
Attached trivial patch fixes it.


P.S. this regression was introduced in in 0.10 (rev62), in jessie's 0.9 
it was correct.


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

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

Versions of packages fatrace depends on:
ii  libc6  2.19-18

Versions of packages fatrace recommends:
ii  powertop  2.6.1-1
ii  python3   3.4.2-2

fatrace suggests no packages.

-- no debconf information

Index: fatrace-0.11/fatrace.c
===
--- fatrace-0.11.orig/fatrace.c
+++ fatrace-0.11/fatrace.c
@@ -254,7 +254,7 @@ parse_args (int argc, char** argv)
 };
 
 while (1) {
-c = getopt_long (argc, argv, "C:co:s:tpf:h", long_options, NULL);
+c = getopt_long (argc, argv, "C:co:s:tp:f:h", long_options, NULL);
 
 if (c == -1)
 break;

Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

[Vincent Lefevre]

On 2016-03-09 12:46:04 +0100, Vincent Lefevre wrote:
> I have:
> 
> -rw-r--r-- 1 9536507 2016-03-09 11:15:43 /var/lib/aptitude/pkgstates
> -rw-r--r-- 1 9526471 2016-03-08 09:38:42 /var/lib/aptitude/pkgstates.old
> 
> Note that /var/lib/aptitude/pkgstates dates from before the upgrade.
> Is that correct?

Actually before 20 seconds before beginning of the log report of the
upgrade.

$ grep -B 7 'Upgrade: yes' pkgstates | grep 'Package:' | sort
Package: clang-3.8
Package: clang-3.8-doc
Package: firebird2.5-common
Package: firebird2.5-common-doc
Package: firebird2.5-server-common
Package: libclang-common-3.8-dev
Package: libclang1-3.8
Package: libdebconfclient0
Package: libfbclient2
Package: libfbembed2.5
Package: libllvm3.8
Package: libnspr4
Package: libopencv-calib3d2.4v5
Package: libopencv-contrib2.4v5
Package: libopencv-core2.4v5
Package: libopencv-features2d2.4v5
Package: libopencv-flann2.4v5
Package: libopencv-highgui2.4v5
Package: libopencv-imgproc2.4v5
Package: libopencv-legacy2.4v5
Package: libopencv-ml2.4v5
Package: libopencv-objdetect2.4v5
Package: libopencv-video2.4v5
Package: libsmbclient
Package: libwbclient0
Package: llvm-3.8
Package: llvm-3.8-dev
Package: llvm-3.8-runtime
Package: mksh
Package: nano
Package: openssh-client
Package: openssh-server
Package: openssh-sftp-server
Package: pax
Package: ruby-domain-name
Package: samba-libs
Package: x11-common
Package: xbase-clients
Package: xorg
Package: xserver-xorg
Package: xserver-xorg-input-all
Package: xserver-xorg-video-all

They correspond to the upgraded packages. This seems to be a bug to
still have 'Upgrade: yes' after the upgrade.

Shouldn't aptitude have removed the 'Upgrade: yes' after the upgrade?
(In case of failure, keep only those corresponding to the packages
that couldn't be upgraded.)

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

Bug#691487: column: segfaults with a certain data and column -ets,

[Michael Meskes]

Do you still this segfault with the latest version? I cannot reproduce it at
all and hope you don't see it either.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


signature.asc
Description: PGP signature

Bug#817242: pocketsphinx: FTBFS when built with dpkg-buildpackage -A (failed to create symbolic link)

[Santiago Vila]

Package: src:pocketsphinx
Version: 0.8+5prealpha-1
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep  --with autoreconf,python2
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autoreconf -i
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'

[... snipped ...]

 /bin/mkdir -p 
'/<>/pocketsphinx-0.8+5prealpha/debian/tmp/usr/lib/python2.7/dist-packages/pocketsphinx'
 /usr/bin/install -c -m 644 __init__.py 
'/<>/pocketsphinx-0.8+5prealpha/debian/tmp/usr/lib/python2.7/dist-packages/pocketsphinx'
Byte-compiling python modules...
__init__.py
Byte-compiling python modules (optimized versions) ...
__init__.py
make[6]: Nothing to be done for 'install-data-am'.
make[6]: Leaving directory 
'/<>/pocketsphinx-0.8+5prealpha/swig/python'
make[5]: Leaving directory 
'/<>/pocketsphinx-0.8+5prealpha/swig/python'
make[4]: Leaving directory 
'/<>/pocketsphinx-0.8+5prealpha/swig/python'
make[4]: Entering directory '/<>/pocketsphinx-0.8+5prealpha/swig'
make[5]: Entering directory '/<>/pocketsphinx-0.8+5prealpha/swig'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha/swig'
make[4]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha/swig'
make[3]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha/swig'
make[3]: Entering directory '/<>/pocketsphinx-0.8+5prealpha'
make[4]: Entering directory '/<>/pocketsphinx-0.8+5prealpha'
make[4]: Nothing to be done for 'install-exec-am'.
 /bin/mkdir -p 
'/<>/pocketsphinx-0.8+5prealpha/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
 /usr/bin/install -c -m 644 pocketsphinx.pc 
'/<>/pocketsphinx-0.8+5prealpha/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
make[4]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha'
make[3]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha'
make[2]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha'
for file in $(find debian/tmp/usr/lib/ -name "*.la"); do \
rm $file ; \
done
make[1]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha'
   dh_install -i
   debian/rules override_dh_installdocs
make[1]: Entering directory '/<>/pocketsphinx-0.8+5prealpha'
dh_installdocs
ln -sf /usr/share/javascript/jquery/jquery.js 
debian/pocketsphinx/usr/share/doc/pocketsphinx/html/jquery.js
ln: failed to create symbolic link 
'debian/pocketsphinx/usr/share/doc/pocketsphinx/html/jquery.js': No such file 
or directory
debian/rules:24: recipe for target 'override_dh_installdocs' failed
make[1]: *** [override_dh_installdocs] Error 1
make[1]: Leaving directory '/<>/pocketsphinx-0.8+5prealpha'
debian/rules:7: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

Thanks.

Bug#817236: schroot: no access to pseudo-terminals in new chroots

[Marco d'Itri]

On Mar 09, Ansgar Burchardt  wrote:

> in the sbuild profile's fstab. To accommodate old chroots that still
> have a /dev/ptmx device node, an additional bind mount
> 
>   ${chroot}/dev/pts/ptmx   /dev/ptmx   none   rw,bind 0 0
> 
> is needed to make sure only the devpts' ptmx device is used. I don't
> think this can be done via the profile's fstab, but only via a setup
> script?
No, a plain bind mount inside the chroot is needed and it can be 
configured in fstab:

/dev/pts/ptmx   /dev/ptmx   none   bind 0 0

The bind mount will work anyway even if /dev/pts/ptmx is a symlink.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#817243: gtk3 programs segfault when a third monitor is added with a usb adapter

[coma]

Package: libgtk-3-0
Version: 3.18.8-1

After upgrading the library to version 3.18.8.1 i can no longer run 
GTK3 programs when using a USB to HDMI adapter to add a third monitor.

my usb adapter is a DisplayLink

#lsusb 
Bus 007 Device 008: ID 17e9:4301 DisplayLink 

To activate the third monitor i use xrandr
#xrandr --setprovideroutputsource 1 0
#xrandr --output DVI-I-1 --auto --right-of VGA1

if i turn off the monitor 
#xrandr --output DVI-I-1 --off
the problem does not occur

Downgrade the library to the previous version fixes the problem
dpkg -l | grep libgtk-3
ii libgtk-3-0:amd64   3.18.7-1 amd64
ii libgtk-3-bin 3.18.8-1 amd64 
ii libgtk-3-common 3.18.8-1 
ii libgtk-3-dev:amd64 3.18.8-1 amd64 



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

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/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtk-3-0 depends on:
ii  libatk-bridge2.0-0  2.18.1-2
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.21-9
ii  libcairo-gobject2   1.14.6-1
ii  libcairo2   1.14.6-1
ii  libcolord2  1.2.12-1
ii  libcups22.1.3-3
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.6.3-3
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libglib2.0-02.46.2-3
ii  libgtk-3-common 3.18.8-1
ii  libjson-glib-1.0-0  1.0.4-2
ii  libpango-1.0-0  1.38.1-1
ii  libpangocairo-1.0-0 1.38.1-1
ii  libpangoft2-1.0-0   1.38.1-1
ii  librest-0.7-0   0.7.93-1
ii  libsoup2.4-12.52.2-1
ii  libwayland-client0  1.9.0-1
ii  libwayland-cursor0  1.9.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  11.1.2-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxml2 2.9.3+dfsg1-1
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.5-2

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.18.8-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.26.2-1+b1
ii  librsvg2-common  2.40.11-2

-- no debconf information

Bug#816703: regression: "mv from to" now fails when both are the same file

[Pádraig Brady]

On 06/03/16 19:46, Marc Lehmann wrote:

On Sun, Mar 06, 2016 at 02:06:47PM -0700, Bob Proulx  wrote:

The kernel system call rename(2) returns 0 for SUCCESS.  And yet the
operation definitely did not succeed.


It did - this is how rename must behave according to POSIX.


I find the above result surprising!


Right, which isn't asurprising :)


So why did this appear to work previously with previous versions of
coreutils mv command?  Because 'mv' didn't previously rename(2) the
files at all.


It worked because I reported this as a bug long ago, and it was changed.

POSIX allows three behaviours for mv in this case:

1. silently succeed
2. issue a disgnostic
3. unlink the source

So very old coreutils used 1, then switched to 3, and now switched to 2,
essentially to please apple users (the race condition could be fixed by a
rename/unlink combination).


place.  The utilities should not hide race condition behavior.


It could be done without races by first renaming the source to a third
name for example, one that doesn't conflict with a concurrent mv (bceause
it can't know that name).

Nevertheless, mv needs to do more than one system call to detect this issue,
so the change doesn't save on system calls.

The only way to save systems calls would be to silently ignore3 this case
(which is allowed by posix).


the script author still wants the racy behavior then the script author
can perform the same actions explicitly and get identical behavior.)


(which script author?)

If you refer to me, this has nothing to do with scripts, it#s simply me
dpoing mv commands sometimes, and expecting mv to do be useful on my
Debian GNU/Linux box, without thinbking too much about apple users and
their problems because their filesystem isn't posix-compliant.


Which means it was historical behavior on multiple kernels originally
and standardized specifically for the reason that changing it would
make portable programs impossible.


Nothing a rename3 or renameat2 (which already exists) couldn't improve with a
flag. In fact, renameat2 with RENAME_EXCHANGE can already be useful. and
renameat2 with RENAME_NOREPLACE can be useful to save on syscalls to detect
this case.


I hope this additional information helps understand what is happening.


I'm not sure anybody was unclear about it. The bug was about keeping
the existing behaviour as a useful extension to POSIX. Unsurprising
mv behaviour would certainly be a useful extension, but upstream
apparently decided to sacrifice quality for better non-posixs (apple)
compatibility. Tough game, but so be it. I'll just keep a copy of mv for
personal use, problem solved.

I do disagree with your mail's implicationh that this is a technical issue,
though - it isn't. It's a policy issue - what weighs more, surprising
behaviour on non-posix filesystems vs. rational behaviour on posix
filesystems, and the decision went to support non-posix filesystems.



It's not to appease case retentive file systems.
There is a race between multiple mv calls issuing unlink();
The race must be fixed in the kernel.
I proposed a new flag to renameat() on the kernel mailing list,
to get the kernel to handle it. When/If that becomes available,
mv can safely restore this behaviour.

Pádraig

Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

[Jakub Wilk]

* Arno Töll , 2015-08-21, 11:13:
The fix would be, to raise this Lintian error only if a package depends 
on apache2-bin but not on apache2-api-MMNN.


There's already separate tag for missing apache2-api-* dep:
apache2-module-does-not-depend-on-apache2-api

Should we should drop apache2-module-depends-on-real-apache2-package 
completely?


--
Jakub Wilk

Bug#817245: RFS: yamllint/1.2.0-1

[Adrien Vergé]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: yamllint
  Version : 1.2.0-1
  Upstream Author : Adrien Vergé 
* URL : https://github.com/adrienverge/yamllint
* License : GPL-3+
  Section : devel

It builds those binary packages:

  yamllint   - Linter for YAML files

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

  http://mentors.debian.net/package/yamllint

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

  dget -x 
http://mentors.debian.net/debian/pool/main/y/yamllint/yamllint_1.2.0-1.dsc

Changes since the last upload:

  * Update to new upstream version
  * Build and include man page in package
  * Fix Vcs-* fields in debian/control
  * Fix description-synopsis-starts-with-article lintian warning

Regards,
 Adrien Vergé

Bug#795277: fixed upstream, fixed in debian

[Andreas Henriksson]

Version: 2.31.7-1

Hello.

After this was forwarded upstream it was fixed and the new upstream release
has since made it into Debian (a long time ago already).

Closing this bug now. Fix first appeared in version mentioned above.

Regards,
Andreas Henriksson

Bug#817248: diffoscope 51 not uploaded to pypi

[Holger Levsen]

package: diffoscope
version: 51
severity: minor
x-debbugs-cc: "Zbigniew Jędrzejewski-Szmek" 

Hi,

thanks for making us aware of this issue!

On Mittwoch, 9. März 2016, Zbigniew Jędrzejewski-Szmek wrote:
> > FYI: I checked why I missed diffscope 49, 50, and 51.
> > It seems to be a problem with pypi:
> > https://pypi.python.org/pypi?%3Aaction=search=diffoscope=sear
> > ch only lists diffoscope 48 as the lastest version. So either somebody
> > forgot to upload the latest versions there, or it's not displaying them
> > for some reason.
> V. 49 is also on pypi, just doesn't show up in the search.

is there a commandline client to search on pypi? I'd like to setup an 
automatic test which will notify us, when a new diffoscope upload has been 
made to Debian, but not to pypi.

Also: who can how upload to pypi?
 
> Is there a canonical place do download a tarball of the project apart from
> pypi?

no.


cheers,
Holger


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

Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

[Vincent Lefevre]

Control: retitle -1 aptitude: packages from the previous upgrade are still 
selected for upgrade by default if there is again a new version

I think this title corresponds more precisely to what I could observe.

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

Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

[Thijs Kinkhorst]

Hi,

On Fri, 21 Aug 2015 10:19:06 -0700, Russ Allbery wrote:
> > we agreed that we should change Lintian to accommodate these
> > changes. The fix would be, to raise this Lintian error only if a package
> > depends on apache2-bin but not on apache2-api-MMNN.
>
> Ah, yes, that would work.

So, any update on this issue? The test is still triggered on my package as
at level error with "Severity: serious, Certainty: certain".


Cheers,
Thijs

Bug#817240: mirrors: errors with ftp.fr.debian.org

[Vincent Lefevre]

Package: mirrors
Severity: normal

I get several errors with ftp.fr.debian.org:

# apt-get update
[...]
Err:24 http://ftp.fr.debian.org/debian unstable/main amd64 DEP-11 Metadata 
  Hash Sum mismatch
[...]
Err:31 http://ftp.fr.debian.org/debian unstable/main DEP-11 64x64 Icons
  Hash Sum mismatch
[...]
Err:37 http://ftp.fr.debian.org/debian unstable/non-free amd64 DEP-11 Metadata
  Hash Sum mismatch
[...]
Err:38 http://ftp.fr.debian.org/debian unstable/non-free DEP-11 64x64 Icons
  Hash Sum mismatch
Get:39 http://ftp.fr.debian.org/debian unstable/main Sources 
2016-03-07-1455.48.pdiff [18.7 kB]
24% [39 Sources 14.2 kB/18.7 kB 76%]E: Unpatched file  doesn't exist (anymore)!
Get:40 http://ftp.fr.debian.org/debian unstable/main Sources 
2016-03-07-2055.20.pdiff [10.1 kB]
24% [40 Sources 10.1 kB/10.1 kB 100%]E: Unpatched file  doesn't exist (anymore)!
[...]
E: Unpatched file  doesn't exist (anymore)!
E: Unpatched file  doesn't exist (anymore)!

-- 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)
Foreign Architectures: i386

Kernel: Linux 4.4.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: sysvinit (via /sbin/init)

Bug#817241: ITP: libplack-middleware-logerrors-perl -- map psgi.errors to psgix.logger or other logger

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libplack-middleware-logerrors-perl
  Version : 0.002
  Upstream Author : Karen Etheridge 
* URL : https://metacpan.org/pod/Plack::Middleware::LogErrors
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : map psgi.errors to psgix.logger or other logger

 psgi.errors defaults to stderr in most backends, which results in
 content going somewhere unhelpful like the server console.
 .
 Plack::Middleware::LogErrors simply remaps the psgi.errors stream to
 the psgix.logger stream, or an explicit logger that you provide.
 .
 This is especially handy when used in combination with other
 middlewares such as Plack::Middleware::LogWarn (which diverts Perl
 warnings to psgi.errors); Plack::Middleware::HTTPExceptions (which
 diverts uncaught exceptions to psgi.errors); and
 Plack::Middleware::AccessLog, which defaults to psgi.errors when not
 passed a logger -- which is also automatically applied via plackup (so
 if you provided no --access-log option indicating a filename,
 psgi.errors is used).
 .
 Plack is a set of tools similar to Ruby's Rack or Python's Paste for
 WSGI. It implements the Perl Server Gateway Interface (PSGI) standard
 interface, which allows developers to decouple their web application
 framework from the local web server environment.

Package will be maintained in the Debian Perl team.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW3/rPAAoJECx8MUbBoAEhHeQP/A6Tg3KVBGX88ZySj0G26w4Q
vOZKtd/M+3iqj1MTM2R/4C8tnFyfvl9Xxb2tEW2dyZWWDQcGjKNscWZsdGpR9Y7L
c0ttidh1N6aUBVA0B0aiuZzBD9cp9QAfp+FsKE/zPjkFw4A/DYwJ5ifJrPHWjKLH
gNdvfHVfB8N3oW0Vlu2MiBcna/Iutz6HQdm/TpXxqTvCg9SP5cM1k70D2hyzXFoz
T+SEyB+yuvzYbLvv+VLN+N/iXa8m1gWB8L2y2LlI6r/3cEfl7fjuZlo3wVC9O6Jx
ct9BG0AmZfiEJcNMfzj5CFTJCtFGK+JLtF+3QpbL4JL4d9t1pkw17Q3zvNgiziSs
uIUzxmSIGDvLDpZVFHOzIHO1iQH+m3Ktl5Yj3ShWbJAuF4681GYT4roLZrtGXUfZ
qsW93qjg0qlnKyt+H6vTHyIN3qzC6cPG12kUNGzCNA2nHKPspFNgPxHWQM7Z5dMQ
0MSk1nNUoqzbdQjdvf2sMkziwVv6MT39/kZP7/W7deLKgd14I43Qxr5fZNxk1nZQ
ltjrElt2q/NZVigbpjnAtulc+GSi4s2pjmLmuBYBu2+vadjkoAzZT4EyLJhuAjzu
jhZXrZN3Q0Q17VaTWVXRB3+vSs/R3qOOU8w71wu9HiKe5w5WFERFwqTUQBZe2a/3
UjH8RyGkQChUTlSYUCGz
=K+Qu
-END PGP SIGNATURE-

Bug#816125: libsdl1.2debian: Remove DirectFB dependency

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

Hi Manuel, since this is part of a transition, and I expect it to become RC 
soon, and Ubuntu already had the patch
(and disabled the support long time ago), I took the liberty to fix and upload 
on DELAYED/2

the patch is there
http://anonscm.debian.org/cgit/pkg-sdl/packages/libsdl1.2.git/commit/?id=957aea45da8d0c26c72535d4db5b9790a90e58a5

and a successful build is here
http://debomatic-amd64.debian.net/distribution#unstable/libsdl1.2/1.2.15+dfsg1-2/buildlog

(let me know if I can reschedule to delayed/0)

cheers,

Gianfranco

On Thu, 3 Mar 2016 18:06:44 + "Manuel A. Fernandez Montecelo" 
 wrote:
> Hi Javier,
> 
> 2016-02-27 18:14 Javier Cantero:
> >Package: libsdl1.2debian
> >Version: 1.2.15+dfsg1-2
> >Severity: wishlist
> >
> >Dear Maintainer,
> >
> >Due to the current status of DirectFB (the project seems dead) and also
> >the status of the debian package (currently unfit for release), can I
> >suggest that future releases drop the dependency by not compiling SDL
> >1.2 with DirectFB support?
> >
> >Thank you for your time and consideration.
> 
> I had some hope that we wouldn't have to touch libsdl1.2 much, but the
> migration to libsdl2 is not going as fast as I would like / expect.
> 
> So I guess that it's better to drop this dependency at some point before
> the freeze.
> 
> If this becomes more high priority for some reason, e.g. because of a
> pending RM of libdirectfb, please let us know.
> 
> 
> Cheers.
> -- 
> Manuel A. Fernandez Montecelo 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#817209: ppc64le emulation on i386 is broken

[Ben Hutchings]

On Wed, 2016-03-09 at 08:11 +0300, Michael Tokarev wrote:
> Hello!
> 
> 
> 09.03.2016 04:56, Ben Hutchings wrote:
> > 
> > Package: qemu-user-static
> > Version: 1:2.5+dfsg-5
> > Severity: normal
> > 
> > In addition to bug #813698, I found that most Debian ppc64el binaries
> > go horribly wrong when running on the i386 build of
> > qemu-ppc64le-static even with QEMU_CPU=POWER8.  This seems to be
> > related to system call translation.  The amd64 build seems to be fine.
> I'm afraid i386 host in qemu receives almost no testing for a long time,
> especially for 64bit targets.   Some places in the code use types such
> as int or long to represent 64 bits, incl. syscall translation, or, if
> that's done correctly, fail to translate high bits in host integers.
> 
> Anyway, can you be a bit more specific about the failures?  Maybe some
> simple test cases, something reproducible, because I'm not sure I'll
> find the right bugs when trying to reproduce this :)

Run the first stage of debootstrap, then try running 'ls' using QEMU.
 It usually shows an empty directory list.

> Is 386 host important these days, when almost all x86 machines are
> 64bits-capable and have large address space not easily accessible
> in 32bit mode?

That's your choice to make, but please don't ship broken binaries.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

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

Bug#780940: hdparm freezes the system's start up

[Raphael Hertzog]

Control: severity -1 important

I'm reducing the severity of this bug as there's only person who
claims to have been affected. And it's not a hard lockup, just
taking more time than what we want.

On Thu, 03 Mar 2016, Alex Mestiashvili wrote:
> Dear Víctor,
> do you have a chance to test the new upstream release of hdparm ? it is not
> yet in the Debian distribution, but the source is available here:
> 
>  http://anonscm.debian.org/cgit/collab-maint/hdparm.git
> 
> You will need to clone the repository and build the package.

You probably want to make some package available... otherwise it's hard
for people to test. We can make a release to experimental if needed.

Or you can make packages available from some scratch space that you might
have.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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