Bug#803822: gst-libav1.0: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Sebastian,

On 04.11.2015 21:20, Sebastian Dröge wrote:
> And also forwarded these upstream for review now, thanks again :) I
> hope I find some time to review them myself soonish, but otherwise I'm
> sure someone else will do it soon

What is the status of this?

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

So this issue will become release critical soon.

Best regards,
Andreas

Bug#810282: qt5-default: URL in description gives 404

[Jakob Haufe]

Package: qt5-default
Version: 5.5.1+dfsg-10
Severity: minor

Dear Maintainer,

the description points to [1] which returns 404. Working URL is [2].

Cheers, sur5r

[1] http://pkg-kde.alioth.debian.org/packagingqtstuff.html
[2] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html

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

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

Versions of packages qt5-default depends on:
ii  qtbase5-dev  5.5.1+dfsg-10
ii  qtchooser52-gae5eeef-2

qt5-default recommends no packages.

Versions of packages qt5-default suggests:
ii  qt5-qmake  5.5.1+dfsg-10
ii  qtbase5-dev-tools  5.5.1+dfsg-10

-- no debconf information

Bug#803834: libde265: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803852: paraview: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also there is a new upstream version (5.0.0~RC3) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#803850: tagged as pending

[Andreas Cadhalpun]

Hi Dmitry,

On 08.12.2015 10:05, Dmitry Smirnov wrote:
> tag 803850 pending
> --
> 
> We believe that the bug #803850 you reported has been fixed in the Git
> repository. You can see the commit message below and/or inspect the
> commit contents at:
> 
> 
> http://anonscm.debian.org/cgit/collab-maint/zoneminder.git/diff/?id=b085841
> 
> (This message was generated automatically by
>  'git-post-receive-tag-pending-commitmsg' hook).
> ---
> commit b085841 (HEAD, master)
> Author: Dmitry Smirnov 
> Date:   Tue Dec 8 09:04:19 2015
> 
> FFmpeg 2.9 support (Closes: #803850).
> 
>  Thanks, Andreas Cadhalpun.
> 

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

This bug has been pending for a month now, so it would be nice,
if you could finally upload the fix.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#810286: icewm: Help path is incorrect

[Rosario Maddox]

Package: icewm
Version: 1.3.8-2
Severity: normal

Dear Maintainer,

When user enables Help option in the menu in .icewm/preferences, the
window appears with error:

invalid path: /usr/share/doc/icewm-1.3.8/icewm.html

And help is missing.

The correct path should be something like:

/usr/share/doc/icewm/html/icewm.html


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

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

Versions of packages icewm depends on:
ii  icewm-common1.3.8-2
ii  libc6   2.19-18+deb8u1
ii  libesd0 0.2.41-11
ii  libfontconfig1  2.11.0-6.3
ii  libgcc1 1:4.9.2-10
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libice6 2:1.0.9-1+b1
ii  libsm6  2:1.2.2-1+b1
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxrandr2  2:1.4.2-1+b1
ii  ttf-dejavu-core 2.34-1

icewm recommends no packages.

Versions of packages icewm suggests:
pn  icewm-gnome-support  

-- no debconf information

Bug#803863: survex: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Olly,

On 03.11.2015 06:20, Olly Betts wrote:
> I've fixed this upstream (but without assuming that AV_PIX_FMT_RGB24 is
> present, so as not to break builds that currently work).
> 
> The ffmpeg2.9 transition doesn't even seem to be listed as "planned"
> yet at https://release.debian.org/transitions/ so I'll probably just
> let this naturally flow in with the next upstream release.

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

As there is now a new upstream version (1.2.24) available,
could you please upload it to unstable?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803870: vtk: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or not reenter testing.

Best regards,
Andreas

Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also there is a new upstream version (2.1) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#803836: libquicktime: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803837: lightspark: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Mattia Rizzolo]

On Thu, Jan 07, 2016 at 09:10:32PM +0100, John Paul Adrian Glaubitz wrote:
> Well, I've been receiving multiple bug reports through various lists in the 
> past days from the libpng maintainers which asked people to fix their B-D 
> regarding libpng-dev to prepare for libpng1.6 and setting these bugs as 
> blockers for the transition bug.

note that most (all?) of those bugs are not filed by the maintainer, but
by another developer that seems to care more than him (or just have more
time to take care of this).
furthermore, there are more than one hundred bugs filed to date, and
ISTR not all are filed yet.  Most of those bugs involves code changes
(e.g. FTBFS with libpng1.6), not just swapping build-deps.
Those kind stuff takes several weeks, if not months.
Anyway, NMUs already started, hopefully we will be able to outline the
blockers soon enough.

> And since Stretch is to be frozen on December, 5th, I'm pretty sure 
> transition is going to start in the near future unless you have any more 
> definitive insider information I don't have.
> 

everybody hopes so, me too.
we deleyed this for so many years :(

-- 
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#803835: closed by Bertrand Marc <beberk...@gmail.com> (Bug#803835: fixed in libextractor 1:1.3-3)

[Andreas Cadhalpun]

Hi Bertrand,

On 28.11.2015 17:08, Andreas Cadhalpun wrote:
> On 20.11.2015 12:39, Debian Bug Tracking System wrote:
>>* Add a patch cherry-picked from upstream to fix FTBFS with FFmpeg 2.9
>>  (Closes: #803835).
> 
> Unfortunately this patch fixes only one half of the problem
> (avcodec_*_frame -> av_frame_*), but not the other (PixelFormat -> 
> AVPixelFormat,
> PIX_FMT_* -> AV_PIX_FMT_*).
> 
> For your convenience, I'm attaching a patch for the missing parts.

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Thus please also upload a fix for the remaining issues.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803838: linphone: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also there is a new upstream version (3.9.1) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#810284: yubico-piv-tool: newer upstream release

[Tianon Gravi]

Package: src:yubico-piv-tool
Version: 1.0.3-1
Severity: wishlist

Since 1.0.3, upstream has released both the 1.1 series and 1.2
(currently at 1.2.2) -- any chance of getting something a little newer
in the archive? :)

(Docker's support for yubikeys requires at least 1.1.0, which is why
I'm asking.)

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

Bug#803842: moc: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Elimar,

On 14.11.2015 15:45, Elimar Riesebieter wrote:
> * Andreas Cadhalpun  [2015-11-14 15:21 +0100]:
>> I'm done testing, so you can put them offline.
> 
> Thanks a lot ;-)

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

So please upload a fixed version of moc now.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803843: motion: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Ximin,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

So please upload a fixed version of motion now.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803862: strigi: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#810287: fail2ban: Error in jail.conf configuration file in [roundcube-auth] section

[Dmitry Katsubo]

Package: fail2ban
Version: 0.9.3-1
Severity: minor

The section [roundcube-auth] contains the error for log definition. The line

logpath  = logpath = %(roundcube_errors_log)s

should read as

logpath = %(roundcube_errors_log)s

otherwise it triggers an error:

# /usr/bin/fail2ban-client -x start
ERROR  No file(s) found for glob logpath =
ERROR  Failed during configuration: Have not found any log file for
roundcube-auth jail

Unfortunately, this error trace is not shown in systemd output, which
makes it difficult to resolve the problem using systemctl:

# systemctl status fail2ban.service
..
systemd[1]: fail2ban.service: Service hold-off time over, scheduling
restart.
systemd[1]: Stopped Fail2Ban Service.
systemd[1]: fail2ban.service: Start request repeated too quickly.
systemd[1]: Failed to start Fail2Ban Service.
systemd[1]: fail2ban.service: Unit entered failed state.
systemd[1]: fail2ban.service: Failed with result 'start-limit'.


-- 
With best regards,
Dmitry

Bug#803861: spek: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#810156: scalar of hashes not documented

[積丹尼 Dan Jacobson]

> "NT" == Niko Tyni  writes:

>> perldoc -f scalar makes absolutely no mention of what we see (/) here:
>> $ perl -wle '$h{a}=0; print scalar %h;'
>> 1/8

NT> It doesn't explain what happens when you evaluate an array in scalar
NT> context either, and I don't think it should.

Well at least it has an example.

@counts = ( scalar @a, scalar @b, scalar @c );

NT> However, perldata.pod has this paragraph under "Scalar values":

NT> If you evaluate a hash in scalar context, it returns false if
NT> the hash is empty. If there are any key/value pairs, it returns
NT> true; more precisely, the value returned is a string consisting
NT> of the number of used buckets and the number of allocated buckets,
NT> separated by a slash. This is pretty much useful only to find out
NT> whether Perl's internal hashing algorithm is performing poorly on
NT> your data set. For example, you stick 10,000 things in a hash, but
NT> evaluating %HASH in scalar context reveals "1/16", which means only
NT> one out of sixteen buckets has been touched, and presumably contains
NT> all 10,000 of your items. This isn't supposed to happen. If a tied
NT> hash is evaluated in scalar context, the "SCALAR" method is called
NT> (with a fallback to "FIRSTKEY").

NT> which should be quite enough IMO.

Sounds good. OK

$ perldoc -f scalar|tail -n 4

See perlop for more details on unary operators and the comma
operator.

should also say

See perldata for details on evaluating a hash in scalar contex.

Bug#810218: [Pkg-mpd-maintainers] Bug#810218: mpd fails to open audio device when started by init script

[Florian Schlichting]

Hi Arian,

> I have mpd set up to use alsa and use my desktop user 'arian'. 
> When mpd is started by debian's init script, it is unable to open the alsa 
> device:
> 
> Jan 07 11:42 : alsa_mixer: Failed to read mixer for 'My ALSA Device': failed 
> to attach to default: No such file or directory
> ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
> ALSA lib conf.c:4260:(_snd_config_evaluate) function snd_func_card_driver 
> returned error: No such file or directory
> ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
...

I think you need to set 

group   "audio"

>From mpd.conf:

# This setting specifies the group that MPD will run as. If not specified
# primary group of user specified with "user" setting will be used (if set).
# This is useful if MPD needs to be a member of group such as "audio" to
# have permission to use sound card.
#
#group  "nogroup"


Florian

Bug#803859: sflphone: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or not reenter testing.

Best regards,
Andreas

Bug#605090:

[bancfc]

I've been experimenting with the source package in unstable. There is 
still some security advantages of building the source package such as 
unique RANDSTRUCT values not known publicly: 
https://github.com/Whonix/grsecurity-installer/issues/1#issuecomment-169819722


Installing the build dependencies on Debian stable would upgrade a lot 
of core libs to unstable. Can you consider adding the gcc and other 
build tools Debian stable versions to the package control file?



@Jacob

At the moment we have someone willing to work on expanding the paxrat 
exceptions configuration list. We are also looking at some of the 
prerequisities for Debian packaging and useful  features: 
https://github.com/subgraph/paxrat/issues


Can you please help in getting it packaged in Debian?

Bug#805471: /usr/bin/optirun: optirun fails with "systemd-logind: failed to get session"

[Luca Boccassi]

On Thu, 2016-01-07 at 20:26 +0100, Dariusz Dwornikowski wrote:
> On 19.11.15 11:58:58, Luca Boccassi wrote:
> > On Wed, 2015-11-18 at 15:21 +0100, Giacomo Boffi wrote:
> > > Package: bumblebee
> > > Version: 3.2.1-10
> > > Severity: important
> > > File: /usr/bin/optirun
> > > 
> > > Dear Maintainer,
> > > 
> > > I'm unable to use optirun on my Debian system, eg:
> > > 
> > > $ optirun -vvv xterm
> > > [26394.265933] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
> > > [26394.266265] [DEBUG]optirun version 3.2.1 starting...
> > > 
> > > [26394.266276] [DEBUG]Active configuration:
> > > [26394.266296] [DEBUG] bumblebeed config file: 
> > > /etc/bumblebee/bumblebee.conf
> > > [26394.266301] [DEBUG] X display: :8
> > > [26394.266306] [DEBUG] LD_LIBRARY_PATH:
> > > /usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/nvidia
> > > [26394.266314] [DEBUG] Socket path: /var/run/bumblebee.socket
> > > [26394.266334] [DEBUG] Accel/display bridge: auto
> > > [26394.266339] [DEBUG] VGL Compression: proxy
> > > [26394.266345] [DEBUG] VGLrun extra options:
> > > [26394.266350] [DEBUG] Primus LD Path:
> > > /usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus:/usr/lib32/primus
> > > [26394.266381] [DEBUG]Using auto-detected bridge primus
> > > [26394.300436] [INFO]Response: No - error: [XORG] (EE) systemd-logind:
> > > failed to get session: PID 24963 does not belong to any known session
> > > 
> > > [26394.300460] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)
> > > systemd-logind: failed to get session: PID 24963 does not belong to
> > > any known session
> > > 
> > > [26394.300467] [DEBUG]Socket closed.
> > > [26394.300483] [ERROR]Aborting because fallback start is disabled.
> > > [26394.300489] [DEBUG]Killing all remaining processes.
> > > $
> > > Please tell me if I can submit further info to help solving this problem.
> > 
> > Hi,
> > 
> > What's the output of:
> > 
> > sudo systemctl status bumblebeed
> > 
> > Also, could you please attach your:
> > 
> > /etc/bumblebee/bumblebee.conf
> > 
> 
> 
> I can confirm the same bug. 
> 
> tdi@blackstar:~ $ _ systemctl status bumblebeed
> ● bumblebeed.service - Bumblebee C Daemon
>Loaded: loaded (/lib/systemd/system/bumblebeed.service; enabled; vendor 
> preset: enabled)
>Active: active (running) since czw 2016-01-07 20:11:08 CET; 13min ago
>  Main PID: 4540 (bumblebeed)
>CGroup: /system.slice/bumblebeed.service
>└─4540 /usr/sbin/bumblebeed
> 
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055043] [ERROR][XORG] (EE) 
> /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055087] [ERROR][XORG] (EE) 
> [drm] Failed to open DRM device for pci::01:00.0: -19
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055103] [ERROR][XORG] (EE) 
> No devices detected.
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055115] [ERROR][XORG] (EE)
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055126] [ERROR][XORG] (EE) 
> no screens found(EE)
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055138] [ERROR][XORG] (EE)
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055151] [ERROR][XORG] (EE) 
> Please also check the log file at "/var/log/Xorg.8.log" for additional 
> information.
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055172] [ERROR][XORG] (EE)
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.055182] [ERROR][XORG] (EE) 
> Server terminated with error (1). Closing log file.
> sty 07 20:14:03 blackstar bumblebeed[4540]: [ 1184.058374] [ERROR]X did not 
> start properly

Hi,

This looks like a different error (is the PCI 01 the right device?),
could you please attach the output of:

reportbug --template nvidia-driver

Kind regards,
Luca Boccassi

Bug#810058: /etc/kbd/ contents before upgrading

[積丹尼 Dan Jacobson]

I still had one machine I didn't update yet.
# ls -l /etc/kbd/
-rw-r--r-- 1 root root 2637 2012-04-29  config
-rw-r--r-- 1 root root  170 2012-04-29  remap
# more /etc/kbd/*|sed '/^#/d;/^$/d'
::
/etc/kbd/config
::
BLANK_TIME=30
BLANK_DPMS=off
POWERDOWN_TIME=30
::
/etc/kbd/remap
::
# aptitude install kbd
Preparing to unpack .../archives/kbd_2.0.3-2_i386.deb ...
Unpacking kbd (2.0.3-2) over (2.0.3-1) ...
dpkg: warning: unable to delete old directory '/etc/kbd': Directory not empty
Processing triggers for doc-base (0.10.6) ...
Processing 1 changed doc-base file...
Registering documents with scrollkeeper...
Processing triggers for man-db (2.7.5-1) ...
Setting up kbd (2.0.3-2) ...
Removing obsolete conffile /etc/kbd/config ...
Removing obsolete conffile /etc/kbd/remap ...
Removing obsolete conffile /etc/init.d/kbd ...
#

Bug#803820: goldendict: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803819: gnash: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Gabriele,

On 03.11.2015 18:43, Andreas Cadhalpun wrote:
> On 03.11.2015 00:51, Gabriele Giacone wrote:
>> Thanks for providing patches.
>> Could you please make your changes conditional upon
>> LIBAVCODEC_VERSION_{MAJOR,MINOR} / LIBAVUTIL_VERSION_INT / ... when
>> needed to keep supporting old ffmpeg/libav versions too?
> 
> These changes are compatible with any version since FFmpeg 1.0/Libav 9.
> 
> If you really need compatibility with more ancient versions, the simplest
> way would probably be to define the new names to the old names, e.g.:
> 
> For VideoConverterFfmpeg.cpp:
> #if LIBAVUTIL_VERSION_MAJOR < 52
> #define AVPixelFormat PixelFormat
> #define AV_PIX_FMT_RGB24 PIX_FMT_RGB24
> #define AV_PIX_FMT_YUV444P PIX_FMT_YUV444P
> #define AV_PIX_FMT_YUVJ444P PIX_FMT_YUVJ444P
> #define AV_PIX_FMT_YUV440P PIX_FMT_YUV440P
> #define AV_PIX_FMT_YUVJ440P PIX_FMT_YUVJ440P
> #define AV_PIX_FMT_YUV422P PIX_FMT_YUV422P
> #define AV_PIX_FMT_YUVJ422P PIX_FMT_YUVJ422P
> #define AV_PIX_FMT_YUV420P PIX_FMT_YUV420P
> #define AV_PIX_FMT_YUVJ420P PIX_FMT_YUVJ420P
> #define AV_PIX_FMT_YUV411P PIX_FMT_YUV411P
> #define AV_PIX_FMT_YUV410P PIX_FMT_YUV410P
> #define AV_PIX_FMT_NV12 PIX_FMT_NV12
> #define AV_PIX_FMT_NV21 PIX_FMT_NV21
> #define AV_PIX_FMT_YUYV422 PIX_FMT_YUYV422
> #define AV_PIX_FMT_UYVY422 PIX_FMT_UYVY422
> #define AV_PIX_FMT_UYYVYY411 PIX_FMT_UYYVYY411
> #define AV_PIX_FMT_NONE PIX_FMT_NONE
> #endif
> 
> For VideoDecoderFfmpeg.cpp:
> #if LIBAVUTIL_VERSION_MAJOR < 52
> #define AVPixelFormat PixelFormat
> #define AV_PIX_FMT_RGBA PIX_FMT_RGBA
> #define AV_PIX_FMT_RGB24 PIX_FMT_RGB24
> #define AV_PIX_FMT_NONE PIX_FMT_NONE
> #define AV_PIX_FMT_VAAPI_VLD PIX_FMT_VAAPI_VLD
> #endif

In case this wasn't explicit enough, attached is a patch
that should work also on older versions (untested).

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas
diff --git a/debian/patches/ffmpeg_2.9.patch b/debian/patches/ffmpeg_2.9.patch
new file mode 100644
index 000..2e571b1
--- /dev/null
+++ b/debian/patches/ffmpeg_2.9.patch
@@ -0,0 +1,223 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun 
+Last-Update: <2015-11-03>
+
+--- gnash-0.8.11~git20150419.orig/libmedia/ffmpeg/VideoConverterFfmpeg.cpp
 gnash-0.8.11~git20150419/libmedia/ffmpeg/VideoConverterFfmpeg.cpp
+@@ -26,6 +26,27 @@
+ #include "ffmpegHeaders.h"
+ #include "log.h"
+ 
++#if LIBAVUTIL_VERSION_MAJOR < 52
++#define AVPixelFormat PixelFormat
++#define AV_PIX_FMT_RGB24 PIX_FMT_RGB24
++#define AV_PIX_FMT_YUV444P PIX_FMT_YUV444P
++#define AV_PIX_FMT_YUVJ444P PIX_FMT_YUVJ444P
++#define AV_PIX_FMT_YUV440P PIX_FMT_YUV440P
++#define AV_PIX_FMT_YUVJ440P PIX_FMT_YUVJ440P
++#define AV_PIX_FMT_YUV422P PIX_FMT_YUV422P
++#define AV_PIX_FMT_YUVJ422P PIX_FMT_YUVJ422P
++#define AV_PIX_FMT_YUV420P PIX_FMT_YUV420P
++#define AV_PIX_FMT_YUVJ420P PIX_FMT_YUVJ420P
++#define AV_PIX_FMT_YUV411P PIX_FMT_YUV411P
++#define AV_PIX_FMT_YUV410P PIX_FMT_YUV410P
++#define AV_PIX_FMT_NV12 PIX_FMT_NV12
++#define AV_PIX_FMT_NV21 PIX_FMT_NV21
++#define AV_PIX_FMT_YUYV422 PIX_FMT_YUYV422
++#define AV_PIX_FMT_UYVY422 PIX_FMT_UYVY422
++#define AV_PIX_FMT_UYYVYY411 PIX_FMT_UYYVYY411
++#define AV_PIX_FMT_NONE PIX_FMT_NONE
++#endif
++
+ namespace gnash {
+ namespace media {
+ namespace ffmpeg {
+@@ -57,7 +78,7 @@ private:
+ 
+ // The lookup table in this function is adapted from chroma.c from the VLC
+ // codebase; its license permits distribution under GPLv3 and later.
+-PixelFormat
++AVPixelFormat
+ fourcc_to_ffmpeg(ImgBuf::Type4CC code)
+ {
+ 
+@@ -68,40 +89,40 @@ fourcc_to_ffmpeg(ImgBuf::Type4CC code)
+ static const struct
+ {
+ ImgBuf::Type4CC  fourcc;
+-PixelFormat ffmpegcode;
++AVPixelFormat ffmpegcode;
+ } pixfmt_table[] =
+ {
+ // Planar YUV formats
+-{GNASH_FOURCC('I','4','4','4'), PIX_FMT_YUV444P},
+-{GNASH_FOURCC('J','4','4','4'), PIX_FMT_YUVJ444P},
++{GNASH_FOURCC('I','4','4','4'), AV_PIX_FMT_YUV444P},
++{GNASH_FOURCC('J','4','4','4'), AV_PIX_FMT_YUVJ444P},
+ 
+ #if LIBAVUTIL_VERSION_INT >= ((49<<16)+(5<<8)+0)
+-{GNASH_FOURCC('I','4','4','0'), PIX_FMT_YUV440P},
+-{GNASH_FOURCC('J','4','4','0'), PIX_FMT_YUVJ440P},
++{GNASH_FOURCC('I','4','4','0'), AV_PIX_FMT_YUV440P},
++{GNASH_FOURCC('J','4','4','0'), AV_PIX_FMT_YUVJ440P},
+ #endif
+ 
+-{GNASH_FOURCC('I','4','2','2'), PIX_FMT_YUV422P},
+-{GNASH_FOURCC('J','4','2','2'), PIX_FMT_YUVJ422P},
++{GNASH_FOURCC('I','4','2','2'), AV_PIX_FMT_YUV422P},
++{GNASH_FOURCC('J','4','2','2'), AV_PIX_FMT_YUVJ422P},
+ 
+-{GNASH_FOURCC('I','4','2','0'), PIX_FMT_YUV420P},
+-{GNASH_FOURCC('Y','V','1','2'), PIX_FMT_YUV420P},
+-

Bug#803821: gpac: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#808389: on an XFCE System KDE-Zugangshilfe don't close btw. runs again shortly after close

[Samuel Thibault]

Hello,

Pino Toscano, on Thu 07 Jan 2016 19:51:18 +0100, wrote:
> In data sabato 19 dicembre 2015 13:47:41, Jörg Frings-Fürst ha scritto:
> > Since the last update the "KDE-Zugangshilfe" is running every time.

Uh.

> > Shortly after closing the program is running again.
> 
> Do you have qt-at-spi installed? I guess it has something do with the
> recent change that enabled accessibility by default for Qt4
> applications. Samuel, do you have any hint?

I don't see why it accessibility help should get triggered, there is no
reason why disabled people would need that behavior.

Jörg, you can cross-check whether that's my change which
triggers this behavior by trying to comment the definitions in
/etc/X11/Xsession.d/90qt-a11y

We need to fix that anyway, disabled people really don't want that
either anyway.

Samuel

Bug#803846: opal: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Eugen,

> On 09.11.2015 11:55, Eugen Dedu wrote:
> Thank you for the patch.  We hope to upload a new release of opal in
> 2 months (very very approximately), which includes most if not all of
> your changes, so I prefer to wait a bit.

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Two month have passed now, so I'm wondering what the status
of this bug is:
 * Is the upstream release ready?
 * Do you plan an upload soon?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803844: mplayer: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: tag -1 fixed-upstream

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

As this is already fixed upstream, it would be great if you
could upload a package with the relevant cherry-picked patches.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#801266: libkdecore5: Please make libkdecore5 multiarch

[Samuel Thibault]

Pino Toscano, on Thu 07 Jan 2016 19:44:50 +0100, wrote:
> So I'm setting this bug as wontfix, sorry.

That should be fine, since:

> (I see the latest version of qt-at-spi does not depend on libkdecore5
> anymore, so this bug is left open as reference.)

so qt-at-spi is multiarch-installable. And what's more, libqtgui4 now
recommends it, so that if a user has a 32bit qt4 app, she'll probably
get the 32bit qt-at-spi installed automatically to make it accessible.

Samuel

Bug#803847: opencv: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#807588: libapache2-mod-auth-ntlm-winbind: failed to write NTLMSSP string to helper - wrote 0 bytes

[Olly Betts]

On Thu, Dec 10, 2015 at 04:03:21PM +0100, Olivier Bitsch wrote:
> Dear team,

This package isn't team-maintained.

> I'm currently trying to configure NTLM authentication with Apache and
> Winbind, unfortunately, the system is quite unstable. I used the same
> setup without any problem with Wheezy version. Basically, the
> authentication is working, but sometime, Apache results to a 500 error
> due to winbind fatal error.

I packaged this module as it was being used by one of my clients in a
project, but they've switched to using libapache2-mod-auth-kerb instead,
so I no longer have access to an environment where I can test the
package.

NTLM is also better avoided if you can, as the package description warns:

 If you're considering using this module, you should be aware that NTLM
 isn't regarded as very secure by modern standards - even Microsoft no
 longer recommends its use - and where possible, you probably want to use
 Kerberos with negotiate auth over https instead (see Debian package
 libapache2-mod-auth-kerb).

I was thinking I should either orphan this package or request it be removed
before stretch - mostly I haven't because I'm unsure which makes more sense.
NTLM has security concerns, but AIUI negotiate auth over http (rather than
https) suffers from connection hijack issues, but I don't know how it
compares in overall security terms with NTLM if you aren't able to use
https.

I think I should probably just orphan it (which I've now done), and I can
always do a "RoQA" removal if nobody else wants to pick it up.

Anyway, I'm afraid I'm unlikely to be able to help much with this bug.  The
module is mostly just glue code between apache and the /usr/bin/ntlm_auth
helper in the winbind package - the latter does the actual authentication,
so the problem may lie there.

We did find the authentication was a bit randomly flaky, though I don't
recall if the symptoms matched those you see.

Cheers,
Olly

Bug#810285: O: apache-mod-auth-ntlm-winbind

[Olly Betts]

Package: wnpp
Severity: normal

I originally packaged this module as it was being used by one of my
clients in a project, but they've switched to using
libapache2-mod-auth-kerb instead, so I no longer have access to an
environment where I can test the package, which means I can't usefully
maintain it.

I've been wondering whether to request removal instead of orphaning,
as NTLM is not very secure by modern standards, as the package
description warns:

 If you're considering using this module, you should be aware that NTLM
 isn't regarded as very secure by modern standards - even Microsoft no
 longer recommends its use - and where possible, you probably want to
 use Kerberos with negotiate auth over https instead (see Debian package
 libapache2-mod-auth-kerb).

AIUI negotiate auth over http (rather than https) suffers from
connection hijack issues, but I don't know how it compares in overall
security terms with NTLM if you aren't able to use https.  So I'm going
to just orphan for now.

Cheers,
Olly


signature.asc
Description: PGP signature

Bug#803849: openscenegraph: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Why didn't you include the patch in your last upload?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also there is a new upstream version (3.4.0) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#803867: vdr-plugin-softhddevice: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Do you plan an upload soon?
 * Is upstream already fixed?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803863: survex: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 08.01.2016 00:55, Olly Betts wrote:
> On Fri, Jan 08, 2016 at 12:48:54AM +0100, Andreas Cadhalpun wrote:
>> As there is now a new upstream version (1.2.24) available,
>> could you please upload it to unstable?
> 
> Coincidentally I'm actually just waiting for 1.2.26-1 to build, so
> should be fixed in unstable very soon.

That's great!

Best regards,
Andreas

Bug#803869: vtk6: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: tags -1 pending

Hi Anton,

thanks for uploading a fixed package.
But since it is stuck in the NEW queue, I would have
appreciated to be informed, when you uploaded it.

Best regards,
Andreas

Bug#801973: [Pkg-roundcube-maintainers] Bug#801973: Bug#801973: error 255 on package configuration

[Sandro Knauß]

Hey,

> Yes the path is fully correct.

can you just add some echos in the file  INSTALL_PATH . 'program/include/
clisetup.php' , to get an idea what path is taken?

Regards,

sandro

PS: I get like Vincent errors when sending you an email - how the hell you 
read these mails ?

: host smtp.trashmail.com[136.243.65.157] said: 550
5.1.1 : Recipient address rejected: User unknown 
in
virtual mailbox table (in reply to RCPT TO command)


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

Bug#571136: please remove useless devices from devices.tar.gz

[Marco d'Itri]

On Dec 31, Marco d'Itri  wrote:

> a) submit a patch which rips out of debootstrap all the devices.tar.gz 
>stuff, or
And here it is.

-- 
ciao,
Marco
diff --git a/Makefile b/Makefile
index 1020cbc..0bbb2c0 100644
--- a/Makefile
+++ b/Makefile
@@ -2,17 +2,9 @@
 VERSION := $(shell sed 's/.*(\(.*\)).*/\1/; q' debian/changelog)
 DATE := $(shell sed -n '/^ -- /{s/.*> \(.*\)/\1/p;q;}' debian/changelog)
 
-MAKEDEV ?= /sbin/MAKEDEV
-
-ifeq ($(shell uname),Linux)
-all: devices.tar.gz
-else
 all:
-endif
 
 clean:
-	rm -f devices.tar.gz
-	rm -rf dev
 
 DSDIR=$(DESTDIR)/usr/share/debootstrap
 install:
@@ -26,19 +18,3 @@ install:
 	chown root:root $(DESTDIR)/usr/sbin/debootstrap
 	chmod 0755 $(DESTDIR)/usr/sbin/debootstrap
 
-ifeq ($(shell uname),Linux)
-	install -o root -g root -m 0644 devices.tar.gz $(DSDIR)/
-endif
-
-devices.tar.gz:
-	rm -rf dev
-	mkdir -p dev
-	chown 0:0 dev
-	chmod 755 dev
-	(cd dev && $(MAKEDEV) std ptmx fd consoleonly)
-	tar --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz
-	@if [ "$$(tar tvf devices.tar.gz | wc -l)" -lt 2 ]; then \
-		echo " ** devices.tar.gz is empty!" >&2; \
-		exit 1; \
-	fi
-	rm -rf dev
diff --git a/README b/README
index 5c08e15..b416140 100644
--- a/README
+++ b/README
@@ -20,7 +20,6 @@ First, get the source.
 
 Then as root, in the debootstrap source directory:
 
-make devices.tar.gz
 export DEBOOTSTRAP_DIR=`pwd`
 debootstrap sid sid
 
diff --git a/TODO b/TODO
index e5fde0e..3a86214 100644
--- a/TODO
+++ b/TODO
@@ -7,5 +7,3 @@ Features:
   -- versus command line
   -- support for sources (vs mirrors)
   -- faux-pinning for packages 
-
-  ++ makedev in second stage
diff --git a/debian/changelog b/debian/changelog
index 8a938a3..3a05192 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+debootstrap (1.0.75+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop creating useless device nodes. This allows removing devices.tar.gz,
+and the dependency on makedev. (Closes: #571136)
+
+ -- Marco d'Itri   Fri, 08 Jan 2016 02:02:21 +0100
+
 debootstrap (1.0.75) unstable; urgency=medium
 
   * Stop cleaning KEEP_DEBOOTSTRAP_DIR twice, as spotted by Chris Lamb
diff --git a/debian/control b/debian/control
index 334236b..1f52d1c 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: admin
 Priority: extra
 Maintainer: Debian Install System Team 
 Uploaders: Junichi Uekawa , Colin Watson , Christian Perrier 
-Build-Depends: debhelper (>= 9), makedev (>= 2.3.1-69) [linux-any]
+Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.6
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/debootstrap.git
 Vcs-Git: git://anonscm.debian.org/d-i/debootstrap.git
diff --git a/debian/rules b/debian/rules
index 2e44367..b395ba6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,12 +11,7 @@ endif
 %:
 	dh $@
 
-# need to be root to make devices, so build is done in install target
-override_dh_auto_build:
-
 override_dh_auto_install:
-	dh_auto_build
-	
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/debootstrap
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/debootstrap-udeb
 	
diff --git a/debootstrap b/debootstrap
index 2a959bb..4cea268 100755
--- a/debootstrap
+++ b/debootstrap
@@ -18,8 +18,6 @@ if [ -z "$DEBOOTSTRAP_DIR" ]; then
 	fi
 fi
 
-DEVICES_TARGZ=$DEBOOTSTRAP_DIR/devices.tar.gz
-
 . $DEBOOTSTRAP_DIR/functions
 exec 4>&1
 
@@ -635,7 +633,6 @@ if am_doing_phase first_stage; then
 	if ! am_doing_phase second_stage; then
 		cp "$0" "$TARGET/debootstrap/debootstrap"
 		cp $DEBOOTSTRAP_DIR/functions	 "$TARGET/debootstrap/functions"
-		cp $DEBOOTSTRAP_DIR/devices.tar.gz	 "$TARGET/debootstrap/devices.tar.gz"
 		cp $SCRIPT			 "$TARGET/debootstrap/suite-script"
 		echo "$ARCH"			>"$TARGET/debootstrap/arch"
 		echo "$SUITE"			>"$TARGET/debootstrap/suite"
diff --git a/functions b/functions
index 8bef5e6..c882b3a 100644
--- a/functions
+++ b/functions
@@ -1060,19 +1060,27 @@ setup_devices () {
 	hurd*)
 		setup_devices_hurd ;;
 	*)
-		if [ -e "$DEVICES_TARGZ" ]; then
-			zcat "$DEVICES_TARGZ" | (cd "$TARGET"; tar -xf -)
-		else
-			if [ -e /dev/.devfsd ] ; then
-in_target mount -t devfs devfs /dev
-			else
-error 1 NODEVTGZ "no %s. cannot create devices" "$DEVICES_TARGZ"
-			fi
-		fi
-		;;
+		setup_devices_simple ;;
 	esac
 }
 
+setup_devices_simple () {
+	# The list of devices that can be created in a container comes from
+	# src/core/cgroup.c in the systemd source tree.
+	mknod $TARGET/dev/null		c 1 3
+	mknod $TARGET/dev/zero		c 1 5
+	mknod $TARGET/dev/full		c 1 7
+	mknod $TARGET/dev/random	c 1 8
+	mknod $TARGET/dev/urandom	c 1 9
+	mknod $TARGET/dev/tty		c 5 0
+	mkdir $TARGET/dev/pts/ $TARGET/dev/shm/
+	ln -s pts/ptmx $TARGET/dev/ptmx
+	ln -s /proc/self/fd   $TARGET/dev/fd
+	ln -s /proc/self/fd/0 $TARGET/dev/stdin
+	ln -s /proc/self/fd/1 $TARGET/dev/stdout
+	ln -s /proc/self/fd/2 

Bug#803823: guvcview: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Why didn't you include this patch in your last upload?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#810218: [Pkg-mpd-maintainers] Bug#810218: mpd fails to open audio device when started by init script

[Max Kellermann]

On 2016/01/08 00:47, Florian Schlichting  wrote:
> I think you need to set 
> 
> group   "audio"

If that solves the problem, then Arian's bug report was wrong.

He said the user is in group "audio".  Specifying the group manually
would discard membership in all other supplementary groups, and may
cause problems with file permissions.  I wouldn't do that.

Bug#808293: freeradius stopped working after kernel upgrade

[Ben Hutchings]

On Thu, 2016-01-07 at 16:43 -0500, Sam Hartman wrote:
> control: -1 severity important
> 
> I'm not sure what the best way to avoid freeradius being pulled out of
> jessie is besides dropping the severity.

RC bugs do not cause packages to be removed from a stable release!
Anyway, this bug is no longer assigned to freeradius.

> If tagging it wheezy and bringing the severity back up would work feel
> free to do that.
> Is anyone seeing this with jessie or is this a wheezy-only issue?

It affects all releases using the previous security update to the
kernel, but not the latest security update.  Specifically:

Release  Regressed in        Fixed in
--
squeeze  2.6.32-48squeeze17  2.6.32-48squeeze18
wheezy   3.2.73-2            3.2.73-2+deb7u2
jessie   3.16.7-ckt20-1      3.16.7-ckt20-1+deb8u2

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.

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

Bug#803868: vlc: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 09.11.2015 19:44, Jean-Baptiste Kempf wrote:
> On 09 Nov, Andreas Cadhalpun wrote :
>>> So, if you want a recent ffmpeg with VLC, you need 3.0.
>>
>> Is there an estimated release date for VLC 3.0?
> 
> In a month or two, for freeze.

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

What are the current release plans for VLC 3.0?

Best regards,
Andreas

Bug#799157: gwenview: some menu and print options vanished

[Juha Jäykkä]

Package: gwenview
Version: 4:15.08.3-1
Followup-For: Bug #799157

Just to confirm, this still exists on 4:15.08.3-1. Non-KDE printing works
fine.

Furthermore, it looks like simultaneously with vanishing printing options,
the landscape option stopped working, too: it works on jessie's version using
the same printer queue. The newer gwenview simply prints the long edge of the
parallel to the short edge of the paper, centers it on the paper (both edges)
and scales to maximum size (i.e. short edge size). I did ask gwenview to "fit
to page".

Cheers,
Juha

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

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

Versions of packages gwenview depends on:
ii  libc6   2.21-4
ii  libexiv2-14 0.25-2.1
ii  libgcc1 1:5.3.1-4
ii  libjpeg62-turbo 1:1.4.1-2
ii  libkf5activities5   5.16.0-1
ii  libkf5baloo55.16.0-1
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configgui55.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5filemetadata3 5.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5itemmodels5   5.16.0-1
ii  libkf5itemviews55.16.0-1
ii  libkf5jobwidgets5   5.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiocore5  5.16.0-1
ii  libkf5kiofilewidgets5   5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5notifications55.16.0-1
ii  libkf5parts55.16.0-1
ii  libkf5service-bin   5.16.0-1
ii  libkf5service5  5.16.0-1
ii  libkf5textwidgets5  5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5xmlgui5   5.16.0-1
ii  liblcms2-2  2.6-3+b3
ii  libphonon4qt5-4 4:4.8.3-2
ii  libpng12-0  1.2.54-1
ii  libqt5core5a5.5.1+dfsg-8
ii  libqt5gui5  5.5.1+dfsg-8
ii  libqt5opengl5   5.5.1+dfsg-8
ii  libqt5printsupport5 5.5.1+dfsg-8
ii  libqt5svg5  5.5.1-2
ii  libqt5widgets5  5.5.1+dfsg-8
ii  libqt5x11extras55.5.1-3
ii  libstdc++6  5.3.1-4
ii  libx11-62:1.6.3-1
ii  phonon4qt5  4:4.8.3-2

Versions of packages gwenview recommends:
ii  kamera 4:4.14.2-1+b1
ii  kio-extras 4:15.08.3-1
ii  qt5-image-formats-plugins  5.5.1-2

gwenview suggests no packages.

-- no debconf information

Bug#803882: squeezelite: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Chris,

On 05.11.2015 11:44, Chris Boot wrote:
> On 02/11/15 21:21, Andreas Cadhalpun wrote:
> Thanks very much for the patch. I've pulled it into my master packaging
> branch and I'll push a release in a week or two once I have tested this
> some more.

Two month rather than two weeks later...

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

So please upload a fixed version now.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803863: survex: FTBFS with FFmpeg 2.9

[Olly Betts]

On Fri, Jan 08, 2016 at 12:48:54AM +0100, Andreas Cadhalpun wrote:
> As there is now a new upstream version (1.2.24) available,
> could you please upload it to unstable?

Coincidentally I'm actually just waiting for 1.2.26-1 to build, so
should be fixed in unstable very soon.

Cheers,
Olly

Bug#810291: RFS: emacs-async/1.6-1 [ITP] -- simple library for asynchronous processing in Emacs

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package emacs-async.

* Package name: emacs-async
  Version : 1.6
  Upstream Author : John Wiegley 
* URL : https://github.com/jwiegley/emacs-async
* License : GPL-2+
  Section : lisp

async.el is a module for doing asynchronous processing in Emacs.  The
most common application is to make dired move and rename files
asynchronously i.e. in the background.  Then the user need not wait for
the move or copy to complete before they can use Emacs for other tasks.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/e/emacs-async/emacs-async_1.6-1.dsc

Or build it with gbp:

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/emacs-async
git checkout debian/1.6-1
git verify-tag debian/1.6-1 # if you have my key
gbp buildpackage

Thanks.

Sean Whitton


signature.asc
Description: Digital signature

Bug#804139: bumblebee: after recent xorg + nvidia updates in sid, "Cannot access secondary GPU - error"

[Luca Boccassi]

On Mon, 2016-01-04 at 10:08 +0100, Debian stuff wrote:
> Happy new year, maintainer.
> 
>  
> > When the last upload was made to the repos I had no issues with the
> > latest drivers and the latest Bumblebee on Jessie. I wonder if it
> > might be due to an incompatibility with the newer version of Xorg in
> > Stretch/Sid?
> 
> Those are my suspicions too.

I upgraded the various Xorg packages on my system to the version in Sid
(still a Jessie install as at the moment I cannot upgrade my laptop to
Stretch, nor I can create a new partition), but I cannot reproduce this
problem with neither 340.96-3 nor 352.63-1.

In your reportbug output I can see these lines where we grep
in /etc/modprobe.d files:

/etc/modprobe.d/i915-kms.conf:# PABLO: creo que lo puse para el
bumblebee, pero ahora lo quito para intentar tirar directamente con
nvidia, que no meta el driver de intel y no me cree conflicto
/etc/modprobe.d/pablo-prohibir-intel.conf:# PABLO :evitar que los
drivers de intel entren en conflicto con los de nvidia

Do you have any particular custom blacklists/configurations for the
graphics modules?

Kind regards,
Luca Boccassi

Bug#804139: bumblebee: after recent xorg + nvidia updates in sid, "Cannot access secondary GPU - error"

[Luca Boccassi]

On Fri, 2016-01-01 at 21:17 +, Nohus wrote:
> Luca Boccassi :
> > Meanwhile, could you please send all the nvidia-related details of
> > your system by running:
> > 
> > reportbug --template nvidia-driver
> > 
> > and attaching the result?
> 
> Sure, here is the report: https://paste.nohus.eu/?g9YqEP

The lspci bash snippet is not finding the discrete card, I guess because
it was off when reportbug was run.

Could you please manually turn the card on, check manually which PCI id
it has, and then paste the output of:

lspci -vvnn -s 

Also I see you are using virtualgl, does it make any difference if you
use primus as a bridge instead?

Kind regards,
Luca Boccassi

Bug#810283: jessie: note that armel/iop32x subarch was removed

[Martin Michlmayr]

Package: release-notes

I'd like to add a note in the jessie release-notes that the
armel/iop32x subarch was removed.

I have two questions:
1) Do you think this paragraph should be limited to armel or not?
2) Is there a tag to use for subarchitectures?

Any other comments?

Index: en/whats-new.dbk
===
--- en/whats-new.dbk(revision 11023)
+++ en/whats-new.dbk(working copy)
@@ -106,6 +106,13 @@
 
 
 
+
+On armel, support for the iop32x
+subarchitecture was dropped.  Other armel subarchitectures continue to be supported,
+including ixp4xx, kirkwood, orion and versatile.
+
+
 
 Finally, the Debian ports to the FreeBSD kernel, kfreebsd-amd64 and
 kfreebsd-i386, included as technology previews in Debian 6.0 and Debian 7, are

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#803839: lives: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or not reenter testing.

Best regards,
Andreas

Bug#803866: vcmi: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Johannes,

On 05.11.2015 11:30, Johannes Schauer wrote:
> I already forwarded this upstream as https://github.com/vcmi/vcmi/pull/135

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since this is fixed upstream since a while it would be nice
if you could upload a fixed package to unstable.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803876: yorick-av: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#810287: fail2ban: Error in jail.conf configuration file in [roundcube-auth] section

[Yaroslav Halchenko]

Thanks!

it was fixed upstream awhile back in
d278fbca306d8bdcc5b3ffe34b1cfc3cd8963f0b
I guess we should cook up a new upstream release (0.9.4) and update package in
Debian

Cheers

On Fri, 08 Jan 2016, Dmitry Katsubo wrote:

> Package: fail2ban
> Version: 0.9.3-1
> Severity: minor

> The section [roundcube-auth] contains the error for log definition. The line

> logpath  = logpath = %(roundcube_errors_log)s

> should read as

> logpath = %(roundcube_errors_log)s

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#803872: wxsvg: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also there is a new upstream version (1.5.5) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#803873: xine-lib-1.2: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#717235: proftpd requests the whole passwd database at each login

[Marco d'Itri]

On Sep 17, Marco d'Itri  wrote:

> > After I switched from libnss-ldap to libnss-ldapd I noticed that at 
> > every login proftpd requests the whole content of the passwd database 
> > (i.e. like running "getent passwd).
> > This is evident from the nslcd debugging log ("passwd(all)").
> Are there any news about fixing this?
> This bug prevents using proftpd on systems with a large users database.
Since there has been no reaction from the maintainer in 2.5 years 
I intend to NMU proftpd in the next future and apply the patch in this 
bug. (And also fix #804322).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#810290: ITP: mediawiki -- website engine for collaborative work

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: mediawiki
  Version : 1.25.5
  Upstream Author : MediaWiki developers 
* URL : https://www.mediawiki.org/
* License : GPL-2.0+
  Programming Lang: PHP
  Description : website engine for collaborative work

MediaWiki is a wiki engine (a program for creating a collaboratively
edited website). It is designed to handle heavy websites containing
library-like document collections, and supports user uploads of
images/sounds, multilingual content, TOC autogeneration, ISBN links,
etc.

Moreover, it keeps track of changes, so users can receive
notifications, view diffs and revert edits. This system has many
other features and can easily be extended.

This package was formerly in Debian and removed due to a lack of active
maintainers and updates. I am an active upstream developer who uses
the software.

Bug#803815: fuse-emulator-utils: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Berto,

On 04.11.2015 08:59, Alberto Garcia wrote:
> On Tue, Nov 03, 2015 at 07:40:13PM +0100, Andreas Cadhalpun wrote:
>>> Do you want me to upload the new fuse package now, or shall I
>>> better wait until the new FFMPEG reaches Debian?
>>
>> It would be good if most the packages were ready for ffmpeg 2.9,
>> when it get's released. Thus it would be great if you could upload
>> the new fuse package soon. But there is no hurry yet, so it's also
>> fine if you do it sometime in the coming weeks.
> 
> Upstream said that they're planning to remove the FFmpeg dependency
> for the next release, so let's do it like this:
> 
> - If there's a new upstream version I'll upload it and this patch will
>   not be needed.
> 
> - If FFmpeg 2.9 is ready before that ping me when it's available in sid
>   and I'll immediately upload the fuse package with your patch. I have
>   it ready so I can do it quickly.
> 
> Does that sound good?

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

fuse-emulator-utils upstream has dropped the dependency on FFmpeg,
so maybe you could upload a snapshot now?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803826: info-beamer: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803829: kino: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803833: libavg: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803830: lebiniou: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#769928: ITP: python-instagram -- A Python 2/3 client for the Instagram REST and Search APIs

[Petter Reinholdtsen]

[Jörg Frings-Fürst]
> Package: wnpp
> Severity: wishlist
> 
>   Package name: python-instagram

I would very much like to see this module in Debian, as it is a dependency
of the creepy package I maintain.  Is there anything I can do to help?  I
noticed the request for sponsoring in #770149, but unfortunately too late
as the package has been removed from mentors in the mean time.

I would be happy to sponsor the package into Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#803840: lynkeos.app: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803855: pjproject: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Tzafrir,

On 05.11.2015 07:40, Tzafrir Cohen wrote:
> Thanks. Merged in git and seems to work fine at first glance.

The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

So it would be good, if you could upload a fixed version.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or not reenter testing.

Also there is a new upstream version (2.4.5) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#803858: renpy: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also there is a new upstream version (6.99.8) available, which
could be uploaded together with this patch.

Best regards,
Andreas

Bug#803856: qutecom: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803865: tupi: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#803864: transcode: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: notfound -1 1.1.7-9
Control: found -1 3:1.1.7-9

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past two month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Best regards,
Andreas

Bug#810289: ITP: helm -- Emacs incremental completion and selection narrowing framework

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: helm
  Version : 1.9.1
  Upstream Author : Thierry Volpiatto 
* URL : https://emacs-helm.github.io/helm/
* License : GPL-3
  Programming Lang: Emacs Lisp
  Description : Emacs incremental completion and selection narrowing 
framework

An alternative to Ido, very popular among Emacs users.  Upstream
description:

Helm is incremental completion and selection narrowing framework for
Emacs. It will help steer you in the right direction when you're
looking for stuff in Emacs (like buffers, files, etc).

Helm is a fork of anything.el originally written by Tamas Patrovic and
can be considered to be its successor. Helm sets out to clean up the
legacy code in anything.el and provide a cleaner, leaner and more
modular tool, that's not tied in the trap of backward compatibility.

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

Bug#807853: k3b: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Dear Maintainer,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Since I haven't heard back from you during the past month
I'm wondering what the status of this bug is:
 * Are you aware of the patch I provided?
 * Do you plan an upload soon?
 * Is upstream aware of the problem?

By the way, this issue had already been reported in 2014 (#739312),
when this functionality got removed from Libav.

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.

Also, Pino, as you are regularly uploading this package, please
consider adding yourself as uploader.

Best regards,
Andreas

Bug#810288: ITP: perspective-el -- tagged workspaces in Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: perspective-el
  Version : 1.12
  Upstream Author : Natalie Weizenbaum 
* URL : https://github.com/nex3/perspective-el
* License : GPL-3
  Programming Lang: Emacs Lisp
  Description : tagged workspaces in Emacs

A popular Emacs Lisp extension.  Upstream description:

This package provides tagged workspaces in Emacs, similar to
workspaces in windows managers such as Awesome and XMonad (and
somewhat similar to multiple desktops in Gnome or Spaces in OS X).

perspective.el provides multiple workspaces (or "perspectives") for
each Emacs frame. This makes it easy to work on many separate projects
without getting lost in all the buffers.

Each perspective is composed of a window configuration and a set of
buffers. Switching to a perspective activates its window
configuration, and when in a perspective only its buffers are
available by default.

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

Bug#809209: libsvn_subr-1.so.1: svn: E235000: dirent_uri.c:2335: assertion

[James McCoy]

On Mon, Dec 28, 2015 at 11:27:28AM +0100, Ph. Marek wrote:
> During a run with my automated test suite for FSVS I noticed that some 
> things that previously worked do not any more.
> I can't really give a hard range of SVN versions, but I guess 2 or 3 years 
> ago that wasn't a problem yet ;/

Hmmm.  I tested all the way back to SVN 1.5 and I either get the abort
you're reporting or a failure trying to setup the working copy in order
to run the test.

  $ make BINARY=../src/fsvs TEST_LIST=037\* -C tests
  make: Entering directory '/home/jamessan/src/debian.org/fsvs/fsvs-1.2.6/tests'
  test -d /tmp/fsvs-test-1000 || mkdir -p /tmp/fsvs-test-1000
  test -d /tmp/fsvs-test-1000/waa || mkdir -p /tmp/fsvs-test-1000/waa
  test -d /tmp/fsvs-test-1000/conf || mkdir -p /tmp/fsvs-test-1000/conf
  Preparing default repository.


  An error occurred: Couldn't open a repository (180001)
in url__open_session: 
svn_ra_open("file:///tmp/fsvs-test-1000/repos/trunk"): Unable to connect to a 
repository at URL 'file:///tmp/fsvs-test-1000/repos/trunk'
  make[3]: *** [prepare_wc] Error 2


  An error occurred: Couldn't open a repository (180001)
in url__open_session: 
svn_ra_open("file:///tmp/fsvs-test-1000/repos/trunk"): Unable to connect to a 
repository at URL 'file:///tmp/fsvs-test-1000/repos/trunk'
  make[3]: *** [prepare_wc] Error 2
  make[2]: *** [prepare_wcs] Error 2
  make[1]: *** [prepare_clean] Error 2
  Makefile:166: recipe for target '/tmp/fsvs-test-1000/default-repos.dump' 
failed
  make: *** [/tmp/fsvs-test-1000/default-repos.dump] Error 2
  make: Leaving directory '/home/jamessan/src/debian.org/fsvs/fsvs-1.2.6/tests'

I didn't get a single successful run of the test.

Granted, the abort needs to be fixed, but not being able to run the test
makes it hard to bisect where things broke.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#810293: RFS: perspective-el/1.12-1 [ITP] -- tagged workspaces in Emacs

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package perspective-el.

* Package name: perspective-el
  Version : 1.12
  Upstream Author : Natalie Weizenbaum 
* URL : https://github.com/nex3/perspective-el
* License : GPL-3+
  Section : lisp

A popular Emacs Lisp extension.  Upstream description:

This package provides tagged workspaces in Emacs, similar to
workspaces in windows managers such as Awesome and XMonad (and
somewhat similar to multiple desktops in Gnome or Spaces in OS X).

perspective.el provides multiple workspaces (or "perspectives") for
each Emacs frame. This makes it easy to work on many separate
projects without getting lost in all the buffers.

Each perspective is composed of a window configuration and a set of
buffers. Switching to a perspective activates its window
configuration, and when in a perspective only its buffers are
available by default.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/p/perspective-el/perspective-el_1.12-1.dsc

Or build it with gbp:

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/perspective-el
git checkout debian/1.12-1
git verify-tag debian/1.12-1 # if you have my key
gbp buildpackage

Thanks.

Sean Whitton


signature.asc
Description: Digital signature

Bug#810292: gettext-lint: Only check spellings against installed dictionaries

[Ben Wiederhake]

Package: gettext-lint
Version: 0.4-2.1
Severity: normal

Control: user check-all-the-thi...@packages.debian.org
Control: usertags -1 + false-positive
Control: affects -1 + check-all-the-things
Control: thanks


Dear Maintainer,

currently, there is no sanity check against the list of available dictionaries,
and apparently no limit in the amount of errors produced.

This has the undesired effect that every word for every language (for which I
don't have an appropriate dict installed) is reported as misspelled.

I'd like to suggest a new flag `--no-missing'. When this flag is set and
POFileSpell detects that a dictionary seems to be missing, only output a single
warning for that language, probably along the lines of:

  No dictionary found for language es_AR. You can specify additional
  dicts with the --dict=path/to/dict option.

With this flag, the output can be kept more concise and meaningful.
To reinforce the point: 1 warning among 100 false-positive warnings is useless.

I already reported the file upstream:
https://sourceforge.net/p/gettext-lint/bugs/4/
 but I want a bugreport in the BTS for the usertag.
The repository doesn't seem to have been active in the last 9 years.
Did I pick the correct source?

The source is in src/POFileSpell.in, which has only 216 lines
(195 according to sloccount).

Regards,
Ben Wiederhake

Bug#777791: ball: ftbfs with GCC-5

[Andreas Tille]

Hi Dimitri,

On Sat, Jul 11, 2015 at 08:27:30PM +0100, Dimitri John Ledkov wrote:
> I believe remaining fixes can be cherrypicked from upstream.
> Specifically for clang / c++11 support the remaining bug of code is
> explicitly converted into bool:
> 
> https://github.com/BALL-Project/ball/commit/6700400576521250cbe4f8d201391168eb80e0df.patch

Thanks for this tip.  I tried the patch but other build issues occured.
So I decided to upgrade the packaging git[1] to upstream 1.4.3~beta1 but
now I get:

...
[  4%] Building CXX object CMakeFiles/BALL.dir/source/CONCEPT/composite.o
In file included from 
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.h:1898:0,
 from 
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/hashMap.h:13,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/persistenceManager.h:13,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/timeStamp.h:21,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/composite.h:41,
 from /build/ball-1.4.3~beta1/source/CONCEPT/composite.C:7:
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC: In member function 
'BALL::String& BALL::String::insert(BALL::String::const_iterator, 
std::initializer_list)':
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC:1379:19: error: no 
matching function for call to 
'std::__cxx11::basic_string::insert(BALL::String::const_iterator&, 
std::initializer_list&)'
  str_.insert(p, li);
   ^
In file included from /usr/include/c++/5/string:52:0,
 from /build/ball-1.4.3~beta1/include/BALL/COMMON/debug.h:18,
 from /build/ball-1.4.3~beta1/include/BALL/common.h:16,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/composite.h:9,
 from /build/ball-1.4.3~beta1/source/CONCEPT/composite.C:7:
/usr/include/c++/5/bits/basic_string.h:1230:7: note: candidate: 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::insert(std::__cxx11::  
  basic_string<_CharT, _Traits, _Alloc>::const_iterator, 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT) [with 
_CharT = char; _Traits = std::char_traits; _Alloc = std::
allocator; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator 
= __gnu_cxx::__normal_iterator; 
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*; 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_iterator = 
__gnu_cxx::__normal_iterator   >; 
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer = 
const char*; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = 
longunsigned int]
   insert(const_iterator __p, size_type __n, _CharT __c)
   ^
/usr/include/c++/5/bits/basic_string.h:1230:7: note:   candidate expects 3 
arguments, 2 provided
/usr/include/c++/5/bits/basic_string.h:1274:9: note: candidate: template std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::iterator std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::const_iterator, _InputIterator, _InputIterator) [with _InputIterator = 
_InputIterator;  = ;_CharT 
= char; _Traits = std::char_traits; _Alloc = std::allocator]
 insert(const_iterator __p, _InputIterator __beg, _InputIterator __end)
 ^
/usr/include/c++/5/bits/basic_string.h:1274:9: note:   template argument 
deduction/substitution failed:
In file included from 
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.h:1898:0,
 from 
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/hashMap.h:13,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/persistenceManager.h:13,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/timeStamp.h:21,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/composite.h:41,
 from /build/ball-1.4.3~beta1/source/CONCEPT/composite.C:7:
/build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC:1379:19: note:   
candidate expects 3 arguments, 2 provided
  str_.insert(p, li);
   ^
In file included from /usr/include/c++/5/string:52:0,
 from /build/ball-1.4.3~beta1/include/BALL/COMMON/debug.h:18,
 from /build/ball-1.4.3~beta1/include/BALL/common.h:16,
 from 
/build/ball-1.4.3~beta1/include/BALL/CONCEPT/composite.h:9,
 from /build/ball-1.4.3~beta1/source/CONCEPT/composite.C:7:
/usr/include/c++/5/bits/basic_string.h:1308:7: note: candidate: void 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator, 
std::   initializer_list<_Tp>) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator; 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = 

Bug#648126: simage: diff for NMU version 1.7.1~2c958a6.dfsg-2.1

[Tobias Frost]

Control: tags 648126 + patch
Control: tags 648126 + pending

Dear maintainer,

I've prepared an NMU for simage (versioned as 1.7.1~2c958a6.dfsg-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru simage-1.7.1~2c958a6.dfsg/debian/changelog 
simage-1.7.1~2c958a6.dfsg/debian/changelog
--- simage-1.7.1~2c958a6.dfsg/debian/changelog  2013-10-26 22:10:18.0 
+0200
+++ simage-1.7.1~2c958a6.dfsg/debian/changelog  2016-01-07 13:12:06.0 
+0100
@@ -1,3 +1,10 @@
+simage (1.7.1~2c958a6.dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS for libpng 1.6 (Closes: #648126)
+
+ -- Tobias Frost   Thu, 07 Jan 2016 13:03:46 +0100
+
 simage (1.7.1~2c958a6.dfsg-2) unstable; urgency=low
 
   * [c1de859] Build-depend on libtiff-dev rather than libtiff4-dev.
diff -Nru simage-1.7.1~2c958a6.dfsg/debian/patches/libpng16.patch 
simage-1.7.1~2c958a6.dfsg/debian/patches/libpng16.patch
--- simage-1.7.1~2c958a6.dfsg/debian/patches/libpng16.patch 1970-01-01 
01:00:00.0 +0100
+++ simage-1.7.1~2c958a6.dfsg/debian/patches/libpng16.patch 2016-01-07 
13:12:15.0 +0100
@@ -0,0 +1,17 @@
+Description: Fix FTBFS with changed libpng 1.6 api
+Author: Tobias Frost 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648126
+Last-Update: 2016-01-07
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/simage_png.c
 b/src/simage_png.c
+@@ -342,7 +342,7 @@
+   /* Set error handling.  REQUIRED if you aren't supplying your own
+* error hadnling functions in the png_create_write_struct() call.
+*/
+-  if (setjmp(png_ptr->jmpbuf)) {
++  if (setjmp(png_jmpbuf(png_ptr))) {
+ /* If we get here, we had a problem reading the file */
+ fclose(fp);
+ png_destroy_write_struct(_ptr,  (png_infopp)info_ptr);
diff -Nru simage-1.7.1~2c958a6.dfsg/debian/patches/series 
simage-1.7.1~2c958a6.dfsg/debian/patches/series
--- simage-1.7.1~2c958a6.dfsg/debian/patches/series 2013-10-26 
22:01:20.0 +0200
+++ simage-1.7.1~2c958a6.dfsg/debian/patches/series 2016-01-07 
13:12:19.0 +0100
@@ -1 +1,2 @@
 01_configure-shared-static.patch
+libpng16.patch

Bug#810135: alienblaster does not start

[Gianluca Renzi]

Hello,
as far as I can tell is that if running strace, it seems to looking for an
icon and fails, and then looks for the intro.bmp and it fails with this
error.

Other SDL programs seems to run ok (frozen bubble for instance...)

On Thu, Jan 7, 2016 at 8:47 AM, Markus Koschany  wrote:

> Control: tags -1 unreproducible moreinfo
>
> Am 06.01.2016 um 21:34 schrieb Gianluca Renzi:
> > Package: alienblaster
> > Version: 1.1.0-9
> > Severity: important
> >
> > Dear Maintainer,
> >
> > running alienblaster from a command line shell it leads to an error:
> > ERROR: file ./images/alienblasterintro.bmp does not exist!
> >
> > It seems the splashscreen it is not found...
> >
> > -- System Information:
> > Debian Release: stretch/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (1, 'experimental')
> > Architecture: powerpc (ppc64)
> >
> > Kernel: Linux 4.1.0-2-powerpc64 (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 alienblaster depends on:
> > ii  alienblaster-data  1.1.0-9
> > ii  libc6  2.21-6
> > ii  libgcc11:5.3.1-5
> > ii  libsdl-mixer1.21.2.12-11+b1
> > ii  libsdl1.2debian1.2.15-12
> > ii  libstdc++6 5.3.1-5
> >
> > alienblaster recommends no packages.
> >
> > alienblaster suggests no packages.
> >
> > -- no debconf information
>
> Hello,
>
> I could not reproduce this issue on my computers. The game works as
> expected on amd64 and i386. There were no changes in regard to
> installation paths. It might be related to your powerpc64 architecture
> but I don't own such a system and thus can't reproduce it. If you are
> able to find out more about this issue, please add your information to
> this bug report.
>
> Regards,
>
> Markus
>
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo

Bug#809873: hhvm: FTBFS with libpng16

[Tobias Frost]

Control: repopen -1
Control: retitle -1 "Please update B-D to libpng-dev"

On Tue, 5 Jan 2016 15:25:48 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?=  wrote:
> Version: 3.11.0+dfsg-1
> 
> On Tue, Jan 05, 2016 at 01:35:59AM +0100, Tobias Frost wrote:
> > Am Dienstag, den 05.01.2016, 00:54 +0100 schrieb Moritz
Muehlenhoff:
> > > On Mon, Jan 04, 2016 at 07:58:01PM +0100, t...@debian.org wrote:
> > > > Source: hhvm
> > > > Severity: important
> > > > User: lib...@packages.debian.org
> > > > Usertags: libpng16-transition
> > > > 
> > > > hhvm FTBFS with libpng16, you can see the buildlog here:
> > > > https://libpng.sviech.de/hhvm.build
> > > 
> > > That test run has been made against hhvm 3.2, could you please
retest
> > > this with 
> > > hhvm 3.11 as currently in sid/stretch?
> > > 
> > > Cheers,
> > > Moritz
> > 
> > Rebuild started on sviech.de. The buildlogs are live, so as soon as
the
> > status file "hhvm.SUCCESS / hhvm.FAIL" are there it has finished
> 
> So this is fixed in 3.11, closing the bug (though the test build
didn't complete
> fully for reasons unrelated to libpng)
> 
> Cheers,
> Moritz
> 
> 

Reopening, as it still B-D on libpng12-dev

-- 
tobi

Bug#782074: RFS: ublock/1.1.1+dfsg-1 [ITP] -- general-purpose lightweight ads, malware, trackers blocker

[Gianfranco Costamagna]

Control: noowner -1

Hi, does anybody has any hint about ublock integration in Debian?



I personally don't use chromium too much, and I don't know about the quality of 
the software
too much, not being a chromium team member and packager.

So I'll leave this RFS to somebody with more knowledge than myself, specially 
because having two
active upstream forks is somewhat disturbing to me (I really don't understand 
why maintain two forks
of the same software).

So, I hope somebody will pick this up.

cheers,

G.

Bug#803647: [Pkg-gambas-devel] Bug#803647: Bug#803647: No solution for llvm and gambas (for now)

[José Luis Redrejo Rodríguez]

Only while llvm-3.5 stays in sid, and even for that case it's not a good
policy. We can do it for the good of the users for sometime. Maybe gambas
developer will update the library in the meantime. If you agree I can do
it, if not the only solution is disabling llvm component from being built
in the packaging.

2016-01-07 3:52 GMT+01:00 Ian Haywood :

> On Wed, Jan 6, 2016 at 9:47 PM, Gianfranco Costamagna
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > control: forwarded -1 http://gambaswiki.org/bugtracker/edit?object=BUG.8
> > 35
> >
> > Hi, unfortunately the bug report clearly shows that the features used
> > are not compatible with recent llvm
> >
> > "LLVM 3.6 decided to replace their old JIT API by a new incompatible
> > one, and so broke programs like Gambas that relied on them.
> > There is no solution at the moment."
> >
> > so, since we don't know how to patch, and the component is optional I
> > think I'll leave the current status quo, and maybe disable llvm on
> > gambas if you eventually want to remove it from Debian.
> generally when a project radically changes its API, the old version is
> maintained for
> some time (often years, think python 2.x and the old Linux kernels)
> llvm-3.5 is still an available package in stretch and jessie, wouldn't
> it be possible to have a specific dependency on llvm-3.5, until
> upstream point gb.jit to 3.6?
>
> Ian
>
> ___
> Pkg-gambas-devel mailing list
> pkg-gambas-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gambas-devel
>

Bug#809136: Don't migrate borgbackup to Debian stable

[Danny Edel]

Control: retitle -1 Block borgbackup migration to stable for now

Hello everyone,

I have thought a lot about this situation and I still think that
blocking migration to stable *for now* is the sensible solution.  I do
not want to remove borgbackup from Debian, or keep this blocker alive
indefinitely, just to clarify that.


The "opener" of this ticket was the situation that you cannot connect to
a borgbackup-0.28.0 server with a borgbackup-0.29.0 client or the other
way around.  This alone - as David pointed out - should not normally
qualify for a blocker.

Solving this issue in the way upstream suggests (having a borg-0.28 and
a borg-0.29 command) would require changing installation paths so that
both versions could coexist, and adding versioned binary names.  While
some work, that is not impossible, however it would still need
"backports" of the old client versions to the current Debian sid, which
may get a bit complicated and difficult to maintain.


Now please keep in mind that borgbackup is *a backup software*.  Users
generally trust backup software with their most important data (we keep
saying "make backups" for a reason) and even though the QA department
says they should, most users don't test continually whether they can
actually restore the backup with each new version of the backup software.

I do not know if this is general consensus, but personally I would
expect from any backup software included in Debian stable, that I can
restore my data using the newer version in the next Debian stable.  If a
backup software does not qualify for that criteria, I would expect to be
actively warned (versus requiring me to read the changelog) before I
install/use it.

Borgbackup currently does not meet that standard.  In fact, they state
"Expect that we will break compatibility repeatedly (...) like when
going from 0.x.y to 1.0.0" on their front page in all-caps.  You can
read some discussion about backwards-compatibility in upstream issue #1
on github.

I think it's safe to assume that once borgbackup reaches milestone
1.0.0, they will care a lot about (at least read-only) on-disk backwards
compatibility, and maybe even RPC compatibility between 1.x and 1.y
client/server.  So this would be the time when I personally think it's
ready for Debian stable.


While it could be argued that with the same reasoning it should not be
in Debian at all, I think having the package in unstable is actually
beneficial both to Debian users and upstream development.

I assume that a Debian *unstable* user is aware of the fact that this is
relatively new software, and that a large portion of "unstable" userbase
are developers and early adopters, that are willing to try new things
out and submit helpful bugreports and feature requests.  This kind of
feedback can be very beneficial to upstream, and since those users will
regularly update to the newest version, the backward-compatibility issue
is not as present here.


In essence, my main issue here is keeping up the high quality that users
expect from a Debian stable.  So unless we find some way to ensure users
have read (and acknowledged) a statement about (non-)compatiblity before
they install it, I don't think it should migrate into Debian stable
until upstream starts to make that promise.



This has been a rather long message, but I hope it clarifies the
reasoning why I belive this is a blocker for stable migration.  As
always, discussion is appreciated and maybe someone has an idea or a
solution I have not yet thought of.


Thank you in advance,

- Danny

PS: Please don't CC me in replies, being co-maintainer I am subscribed
to the bug.

Bug#810212: segfaults when using as unison-2.40 to sync with a jessie system

[Enrico Zini]

Package: unison
Version: 2.48.3-1
Severity: important

Hello,

thank you for maintaining unison.

It seems unison is not able to sync to a jessie system anymore:

   $ unison irclogs
   Contacting server...
   Fatal error: Received unexpected header from the server:
expected "Unison 2.48\n" but received "Unison 2.40\n\000\000\000\000\017", 
   which differs at "Unison 2.40".
   This can happen because you have different versions of Unison
   installed on the client and server machines, or because
   your connection is failing and somebody is printing an error
   message, or because your remote login shell is printing
   something itself before starting Unison.
   $ #  
   $ unison-2.40 irclogs
   (�qhrSegmentation fault
   $ # 

I don't quite know what to do at this point; also, there seems to be no
2.48 backport for jessie.

Enrico


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

Kernel: Linux 4.2.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 unison depends on:
ii  libc6  2.21-6

Versions of packages unison recommends:
ii  openssh-client [ssh-client]  1:7.1p1-5

Versions of packages unison suggests:
ii  unison-all  2.48+1

-- no debconf information

Bug#810214: rsyslog: Cannot ratelimit nor discard gnome-session messages with include file

[Joachim H. Kaiser]

Package: rsyslog
Version: 8.4.2-1+deb8u2
Severity: normal

Dear Maintainer,

the gnome-session spams /var/log/{syslog,user.log,messages}.  As a workaround I
tried ratelimiting by specifying "$RepeatedMsgContainsOriginalMsg on" in
/etc/rsyslog.d/local.conf.  It had no effect.

I tried discarding a specific type of message with the line ":msg, contains,
"mutter-WARNING" ~".  No effect.

In desperation, I tried the line ":msg, contains, "gnome-session" ~" but
gnome-session messages still turn up.

Despite my excitement, many thanks to you for maintaining this package.


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

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

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.22
ii  initscripts  2.88dsf-59
ii  libc62.19-18+deb8u2
ii  libestr0 0.1.9-1.1
ii  libjson-c2   0.11-4
ii  liblogging-stdlog0   1.0.4-1
ii  liblognorm1  1.0.1-3
ii  libuuid1 2.25.2-6
ii  lsb-base 4.1+Debian13+nmu1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages rsyslog recommends:
ii  logrotate  3.8.7-1+b1

Versions of packages rsyslog suggests:
ii  rsyslog-doc8.4.1-1
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- no debconf information

Bug#810018: procps: Please (re)consider shipping procps pidof

[Andreas Henriksson]

Hello Craig Small.

Thanks for taking this on and drafting a proposal... I'll throw
in some of my own ideas below in case they're helpful so feel
free to leave out or reword things as you see fit.

Fwiw, in case you want to avoid any potential people out there
who might think you're just beating a dead horse for your own
personal gain feel free to start out with "I've been asked to..."
which should hopefully kill off those ideas from the get-go.

On Thu, Jan 07, 2016 at 09:17:41AM +1100, Craig Small wrote:
[...]
> So, to the actual proposal. I need help especially around the why.
> 
> ===
> What:
> Create a new package procps-base. This uses the existing procps source
> package and just enable building of pidof. procps-base will be an 
> Essential package and only contain pidof.

Short and clear. +1

> 
> Why:

I see what you wrote mainly as a long-term why I'd like to add
a short-term:

Make sure more of the essential utilities in the base of the operating
system comes from active and healthy upstreams.

Also in general I think it's good to make sure we don't /needlessly/
deviate. This means we can benefit from issues discovered in other
distributions and fixed upstream, while at the same time we can be good
free software citizens and bring our own fixes upstream for the benefit
of the entire free software echosystem.
Hopefully pidof is trivial enough that it won't need much fixes though.

> The aim is to make the sysvinit-utils package non-essential. This
> was discussed previously in 2013 [1], however there are some important
> differences between 2013 and now.
>  1) The previous change was due to possible upstream relocations of
>  pidof. This is about Debian package contents.
>  2) In 2013 there were a lot of other programs in sysvinit, in 2016
>  we're down to 4 (pidof, service, fstab-decode, killall5)
> 
> (why change from one essential to the other?)

Why? See above. Otherwise I think this part is good as is. Some minor
ideas:
 - maybe say "longer term plans/ideas..." since I'm not vouching we'll
   be able to actually pull off makintg sysvinit-utils non-essential
   before stretch release.
 - maybe tone down making sysvinit-utils non-essential since I think
   that should be a separate discussion (and more considerations than
   just pidof and service, etc, needs to be taken into consideration).
   Providing procps pidof is a useful idea on its own in my opinion.

> 
> What about the other binaries in sysvinit-utils?
>  pidof - moves to new Essential package procps-base
>  service - moving to init-system-helpers [2]
>  fstab-decode - 2 packages use this (open-iscsi, drbl)
>  killall5 -  2 packages use this (openrc, util-vserver)
> The idea would be those 4 packages would depend on sysvinit-utils.
> pidof is used be far too many packages to have the same treatment.

I've also spent some time on researching the pidof users and the main
user seemed to be direct invokations from init scripts. These could
benefit from being converted to LSB "pidofproc" helper function (which
falls back on executing pidof if available though). I'm not sure the
busy work of fixing all init scripts is worth it though. Personally I'd
rather spend my time on writing native systemd unit files (which will
probably be easier to reuse from other potential future init systems
than LSB init scripts), and I doubt the vocal people who shys away from
anything systemd related is willing to actually step up and help out
with the practical work either. So not sure if it's worth even
mentioning LSB pidofproc... maybe in a short paragraph somewhere.

> 
> What other packages will procps-base depend on?
> libc6 and libprocps5. libprocps would be newly pulled in.

Would likely be good to mention what sysvinit-utils pulls in
for comparison, eg.

In comparison sysvinit-utils pulls in:
libc6, libselinux1, startpar

(Maybe skip mentioning libc6 in both cases.)

> 
> 
> 1: https://lists.debian.org/debian-devel/2013/12/msg00121.html
> 2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805487
> 
> ===
>  - Craig

HTH.

Regards,
Andreas Henriksson

Bug#810135: alienblaster does not start

[Markus Koschany]

Am 07.01.2016 um 09:05 schrieb Gianluca Renzi:
> Hello,
> as far as I can tell is that if running strace, it seems to looking for
> an icon and fails, and then looks for the intro.bmp and it fails with
> this error.

Are you sure that /usr/games is in your PATH? What happens if you change
to ~/.alienblaster and run /usr/games/alienblaster.bin directly? The
icon exists in alienblaster-data, and the symlinks in ~/.alienblaster
should point to the images directory.





signature.asc
Description: OpenPGP digital signature

Bug#810135: alienblaster does not start

[Gianluca Renzi]

On my ubuntu distribution at work:

apt-file search alienblasterintro.bmp
alienblaster-data:
/usr/share/games/alienblaster/images/alienblasterintro.bmp

So it's seems on debian sid/stretch the alienblaster-data is not installed
as dependency. I will check on launch break @ home
.

On Thu, Jan 7, 2016 at 10:23 AM, Markus Koschany  wrote:

> Please always keep the bug report in CC.
>
> Am 07.01.2016 um 10:16 schrieb Gianluca Renzi:
> > apt-file search alienblasterintro.bmp
> > returns no package result.
>
> Running
>
> dpkg -L alienblaster-data | grep alienblasterintro
>
>
> returns
>
> /usr/share/games/alienblaster/images/alienblasterintro.bmp
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo

Bug#810216: letsencrypt: fails to run as unprivileged user

[Debian/GNU]

Package: letsencrypt
Version: 0.1.1-3
Severity: normal

Dear Maintainer,

letsencrypt gives me a hard time when being run as unprivileged user.
i understand that quite a number of operations require supercow powers, but the
error messages are rather cryptic (being generic python exceptions):

$ letsencrypt
An unexpected error occurred:
OSError: [Errno 13] Permission denied: '/etc/letsencrypt'
Please see the logfile 'letsencrypt.log' for more details.
$ cat letsencrypt.log
Traceback (most recent call last):
  File "/usr/bin/letsencrypt", line 9, in 
load_entry_point('letsencrypt==0.1.1', 'console_scripts', 
'letsencrypt')()
  File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1359, in 
main
"--strict-permissions" in cli_args)
  File "/usr/lib/python2.7/dist-packages/letsencrypt/le_util.py", line 103, 
in make_or_verify_dir
os.makedirs(directory, mode)
  File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/etc/letsencrypt'
$ sudo letsencrypt
No installers seem to be present and working on your system; fix that or try
running letsencrypt with the "certonly" command
$ letsencrypt
Traceback (most recent call last):
  File "/usr/bin/letsencrypt", line 9, in 
load_entry_point('letsencrypt==0.1.1', 'console_scripts', 
'letsencrypt')()
  File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1364, in 
main
setup_logging(args, _cli_log_handler, logfile='letsencrypt.log')
  File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1277, in 
setup_logging
args, logfile=logfile, fmt=fmt)
  File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1248, in 
setup_log_file_handler
log_file_path, maxBytes=2 ** 20, backupCount=10)
  File "/usr/lib/python2.7/logging/handlers.py", line 117, in __init__
BaseRotatingHandler.__init__(self, filename, mode, encoding, delay)
  File "/usr/lib/python2.7/logging/handlers.py", line 64, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding, delay)
  File "/usr/lib/python2.7/logging/__init__.py", line 905, in __init__
StreamHandler.__init__(self, self._open())
  File "/usr/lib/python2.7/logging/__init__.py", line 935, in _open
stream = open(self.baseFilename, self.mode)
IOError: [Errno 13] Permission denied: 
'/var/log/letsencrypt/letsencrypt.log'
$

if the letsencrypt binary is only meant to be run as superuser, please move it
from /usr/bin/ to /usr/sbin/ and/or add additional checks whether the user has
the required privileges and provide them with a meaningful error message.

otoh, i guess that some functionality of letsencrypt does not require root
priviliges at all, at least it should not require such privilges (e.g. i don't
see why `letsencrypt plugins` must be run as root).




*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 letsencrypt depends on:
ii  dialog  1.2-20150920-1
ii  python-letsencrypt  0.1.1-3
pn  python:any  

letsencrypt recommends no packages.

Versions of packages letsencrypt suggests:
pn  python-letsencrypt-apache  
ii  python-letsencrypt-doc 0.1.1-3

-- no debconf information

Bug#809665: debian-faq: broken link in the author section

[Joost van Baal-Ilić]

Hi raju,

On Thu, Jan 07, 2016 at 01:27:50AM -0500, Kamaraju Kusumanchi wrote:
> 
> This is Kamaraju S. Kusumanchi, the author mentioned in this bug report.
> Sorry about the broken link.
> 
> I was a graduate student at Cornell University when I wrote that FAQ. The
> website  http://people.cornell.edu/pages/kk288/ is no longer maintained. I
> will check my backups for the original version. If I find it, I will put it
> on my new website http://raju.shoutwiki.com/ . Please give me couple of
> weeks and then may be you can update the link?

Excellent, sure: just reply to this bugreport with the new url and it'll get
fixed eventually.

Bye,

Joost

Bug#804209: wheezy-pu: package fuse-exfat/0.9.7-2+deb7u1

[Sven Hoexter]

On Fri, Jan 01, 2016 at 06:26:22PM +, Adam D. Barratt wrote:

Hi Adam,

> Please go ahead.

Uploaded.

Regards,
S.

Bug#803647: [Pkg-gambas-devel] Bug#803647: Bug#803647: No solution for llvm and gambas (for now)

[Gianfranco Costamagna]

Hi, 


>Only while llvm-3.5 stays in sid, and even for that case it's not a good 
>policy. We can do it for the good of the users for sometime. Maybe gambas 
>developer will >update the library in the meantime. If you agree I can do it, 
>if not the only solution is disabling llvm component from being built in the 
>packaging.

>> so, since we don't know how to patch, and the component is optional I
>> think I'll leave the current status quo, and maybe disable llvm on
>> gambas if you eventually want to remove it from Debian.
>generally when a project radically changes its API, the old version is
>maintained for
>some time (often years, think python 2.x and the old Linux kernels)
>llvm-3.5 is still an available package in stretch and jessie, wouldn't
>it be possible to have a specific dependency on llvm-3.5, until
>upstream point gb.jit to 3.6?
>


this is *exactly* what I did, force the 3.5 dependency in control file and 
rules file.
llvm-3.5-dev [!hurd-any],

and 

./configure --host=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) 
--build=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) 
LLVM_CONFIG=/usr/bin/llvm-config-3.5

the problem actually is that we removed llvm-3.4 only recently because ghc on 
arm* was needing it.

The new ghc 7.10 requires llvm-3.5, but AFAIR it is specially embedded in ghc 
source code.

So the only two reverse-dependency left seems to be gambas3 and pocl.
I'm not sure how long llvm people will continue shipping llvm-3.5 (together 
with 3.6, 3.7, 3.8 and snapshot) because of two reverse dependencies.

I did recently a lot of work in pkg-llvm team (not that lot, but a few uploads) 
and I can say that maintaining 5 different llvm versions means
5 times the work in patching-rebasing, keeping up to date with CVEs.

So, this is what I said before, I kept the llvm binding enabled, but I can't 
promise the llvm Debian maintainer will keep it for Stretch, so
the intent of the mail was: "be prepared, the component (optional) might 
disappear soon".

And upstream seems to put little effort in updating it (AFAIK the man who did 
the work is not available anymore, so there is almost nobody
that has knowledge to work on it).

cheers,

Gianfranco

Bug#810213: Ben: Use https instead of http for external links

[Mehdi Dogguy]

Source: ben
Version: 0.7.0

The documentation as well the templates contain http links. Those should 
use

https instead of http.

Bug#806572: RFS: multimail/0.50~20150922-1 [ITA]

[Tobias Frost]

PS: Another remark regarding bluewave.h -- I did not evaluate if this
license is compatible with the GPL-3.. Another thing to check with
debian-legal.


Hi Robert,

(btw, please configure your MTA to wrap your mails)

On Tue, 05 Jan 2016 18:08:55 -0500 Robert James Clay 
wrote:
> On Tuesday, January 05, 2016 04:27:48 AM Tobias Frost wrote:
> > - Is the patch forwarded to upstream?
>  
> The non vendor specific parts of it, you mean?  I plan to further
> discuss other aspects of it with him, yes...  I have provided him
> with the results of package builds but he hasn't commented...

The Makefile looks buggy to me, not vendor-specific: Hardcoded paths
are bad. But ok, a patch will do it for now. However, please then set
the patch headers appropiately, especially the Forwarded one with (if
available) a link to more information. 
 
> >  
> > - Please B-D on debhelper >=9 not debhelper >=9.0
> > (The versioned depends could even go, as debhelper 9 is already in
since oldstable)
>  
> I take your point about its setting, but I think I'd rather keep
it explicitly noted...

OK

>    
> > - d/rules: Are the lines setting CPPFLAGS and friend really needed?
>  
> As I recall, those were needed to clean up the hardening related
lintian errors.

With debhelper 9 and compat 9 this is no longer needed.

You can cleanup your d/rules even more: This is enough:

#!/usr/bin/make -f

%:
dh $@

Why: 
- the dh_installchangelogs --keep HISTORY is not needed, Debian users
know that they have to look on changelog.gz
- dh_installdocs --link-doc=multimail just adds complexity, saving
maybwe 10k.
- dh_auto_install --destdir=debian/multimail destdir is automatically
figured out by dh_auto_install. 

d/copyright:
- The license is actually GPL-3+ 
- I saw a file with, 1996-1997 Kolossvary Tamas, (d/copyright: 1997
missing)
- John Zero 1996-1997   
- Toth Istwan seems also to have contributed 1997
- Ingo Brueckl is missing
- The color files have certain authors, they should be added.
- Are the years for your contribution right? It says 2013-16 but there
is no changelog entry from after 2009 (beside the latest one)

- bluewave.h... Well, that scares me. Because the license terms say
read "THE BLUE WAVE STRUCTURE DOCUMENTATION".
However, this document does not say that bluewave.h can be distributed,
just that you are allowed to use the structs. 
Beside that (lets assume the header is covered), there is only right of
use, that does not neccessarily include the right for distribution and
the right for modification. (Please ask on debian-legal) 

More General:
Your changelog is quite verbose, that is good, but you do not need to
overdo it -- for example is would be enough to say "Add homepage" or
"New Maintainer".  (as said, not wrong, no need to change, just maybe
something to reduce effort on your side)
However, there are some changes where the "why has this changed" is not
obvious. In this case you should spend a few words on the why, because
the "what" is self-explained by the diff of the package. 
Example here is the line about the Makefile: The reader will not have
an idea why this has been changed, which is very impportant purpose of
a changelog.  

-- 
tobi

Bug#806572: RFS: multimail/0.50~20150922-1 [ITA]

[Tobias Frost]

Hi Robert,

(btw, please configure your MTA to wrap your mails)

On Tue, 05 Jan 2016 18:08:55 -0500 Robert James Clay 
wrote:
> On Tuesday, January 05, 2016 04:27:48 AM Tobias Frost wrote:
> > - Is the patch forwarded to upstream?
> 
>The non vendor specific parts of it, you mean?  I plan to further
> discuss other aspects of it with him, yes...  I have provided him
> with the results of package builds but he hasn't commented...

The Makefile looks buggy to me, not vendor-specific: Hardcoded paths
are bad. But ok, a patch will do it for now. However, please then set
the patch headers appropiately, especially the Forwarded one with (if
available) a link to more information. 
 
> > 
> > - Please B-D on debhelper >=9 not debhelper >=9.0
> > (The versioned depends could even go, as debhelper 9 is already in
since oldstable)
> 
>I take your point about its setting, but I think I'd rather keep
it explicitly noted...

OK

>    
> > - d/rules: Are the lines setting CPPFLAGS and friend really needed?
> 
>As I recall, those were needed to clean up the hardening related
lintian errors.

With debhelper 9 and compat 9 this is no longer needed.

You can cleanup your d/rules even more: This is enough:

#!/usr/bin/make -f

%:
dh $@

Why: 
- the dh_installchangelogs --keep HISTORY is not needed, Debian users
know that they have to look on changelog.gz
- dh_installdocs --link-doc=multimail just adds complexity, saving
maybwe 10k.
- dh_auto_install --destdir=debian/multimail destdir is automatically
figured out by dh_auto_install. 

d/copyright:
- The license is actually GPL-3+ 
- I saw a file with, 1996-1997 Kolossvary Tamas, (d/copyright: 1997
missing)
- John Zero 1996-1997   
- Toth Istwan seems also to have contributed 1997
- Ingo Brueckl is missing
- The color files have certain authors, they should be added.
- Are the years for your contribution right? It says 2013-16 but there
is no changelog entry from after 2009 (beside the latest one)

- bluewave.h... Well, that scares me. Because the license terms say
read "THE BLUE WAVE STRUCTURE DOCUMENTATION".
However, this document does not say that bluewave.h can be distributed,
just that you are allowed to use the structs. 
Beside that (lets assume the header is covered), there is only right of
use, that does not neccessarily include the right for distribution and
the right for modification. (Please ask on debian-legal) 

More General:
Your changelog is quite verbose, that is good, but you do not need to
overdo it -- for example is would be enough to say "Add homepage" or
"New Maintainer".  (as said, not wrong, no need to change, just maybe
something to reduce effort on your side)
However, there are some changes where the "why has this changed" is not
obvious. In this case you should spend a few words on the why, because
the "what" is self-explained by the diff of the package. 
Example here is the line about the Makefile: The reader will not have
an idea why this has been changed, which is very impportant purpose of
a changelog.  

-- 
tobi

Bug#810128: [pkg-boost-devel] Bug#810128: libboost-all-dev: Linking problems with latest 1.58 release

[Dimitri John Ledkov]

Hi,

On 6 January 2016 at 18:52,  wrote:

> Package: libboost-all-dev
> Version: 1.58.0.1
> Severity: important
>
> Dear Maintainer,
>
> linking programs against latest version (1.58.0.1) fails with similar
> messages:
> -
> /bin/sh ../share/genbuild.sh obj/build.h
> g++-4.8 -pthread -Wall -Wextra -Wno-sign-compare -Wno-invalid-offsetof
> -Wno-
>

g++-4.8 in debian is acient compared with boost 1.58 and the two use
different c++ ABI.
g++-4.8 defaults to 98 abi, which was used by boost in debian up to 1.55.
g++-5 and better use c++ 11 abi, and boost 1.58 and better use that too.
You cannot mix & match c++ abis.
Please use a matching compiler & boost libraries... this is not a bug, or
rather a won't fix one.
Why are you using such an ancient compiler in 2016? 4.8 was first released
almost three years ago...

Regards,

Dimitri.



> unused-parameter -Wformat -Wformat-security -g -DBOOST_SPIRIT_THREADSAFE
> -DUSE_IPV6 -I/home/.../git/peerunity/src -I/home/.../git/peerunity/src/obj
> -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all
> -Wstack-protector
> -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -O2 -rdynamic -o peerunityd
> obj/version.o obj/checkpoints.o obj/netbase.o obj/addrman.o obj/crypter.o
> obj/key.o obj/db.o obj/init.o obj/irc.o obj/keystore.o obj/main.o obj/net.o
> obj/protocol.o obj/kernelrecord.o obj/bitcoinrpc.o obj/rpcdump.o
> obj/script.o
> obj/util.o obj/wallet.o obj/walletdb.o obj/noui.o obj/kernel.o
>  -Wl,-Bdynamic
> -l boost_program_options -l boost_system -l boost_filesystem -l
> boost_thread -l
> db_cxx -l ssl -l crypto -l rt -Wl,-Bdynamic -l z -l dl -l pthread
> obj/util.o: In function
>
> `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)':
> /usr/include/boost/program_options/detail/config_file.hpp:161: undefined
> reference to `boost::program_options::to_internal(std::string const&)'
> obj/util.o: In function
>
> `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
> std::set
> const&, bool)':
> /usr/include/boost/program_options/detail/config_file.hpp:145: undefined
> reference to
>
> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set std::less, std::allocator > const&, bool)'
> collect2: error: ld returned 1 exit status
> Makefile:135: recipe for target 'peerunityd' failed
> make: *** [peerunityd] Error 1
> -
>
> It seems that boost was build which "clang" or so which seems to cause the
> problem:
>
> https://github.com/Peerunity/Peerunity/issues/178
>
> Someone there suggest that an ABI change causes this and rebuilding boost
> with
> gcc 5.3 fixed the problem.
>
> Can you please investigate?
>
> Best regards,
> Roland Haeder
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'oldoldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.18.11 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libboost-all-dev depends on:
> ii  libboost-atomic-dev   1.58.0.1
> ii  libboost-chrono-dev   1.58.0.1
> ii  libboost-context-dev  1.58.0.1
> ii  libboost-coroutine-dev1.58.0.1
> ii  libboost-date-time-dev1.58.0.1
> ii  libboost-dev  1.58.0.1
> ii  libboost-exception-dev1.58.0.1
> ii  libboost-filesystem-dev   1.58.0.1
> ii  libboost-graph-dev1.58.0.1
> ii  libboost-graph-parallel-dev   1.58.0.1
> ii  libboost-iostreams-dev1.58.0.1
> ii  libboost-locale-dev   1.58.0.1
> ii  libboost-log-dev  1.58.0.1
> ii  libboost-math-dev 1.58.0.1
> ii  libboost-mpi-dev  1.58.0.1
> ii  libboost-mpi-python-dev   1.58.0.1
> ii  libboost-program-options-dev  1.58.0.1
> ii  libboost-python-dev   1.58.0.1
> ii  libboost-random-dev   1.58.0.1
> ii  libboost-regex-dev1.58.0.1
> ii  libboost-serialization-dev1.58.0.1
> ii  libboost-signals-dev  1.58.0.1
> ii  libboost-system-dev   1.58.0.1
> ii  libboost-test-dev 1.58.0.1
> ii  libboost-thread-dev   1.58.0.1
> ii  libboost-timer-dev1.58.0.1
> ii  libboost-tools-dev1.58.0.1
> ii  libboost-wave-dev 1.58.0.1
>
> libboost-all-dev recommends no packages.
>
> libboost-all-dev suggests no packages.
>
> -- no debconf information
>
> ___
> pkg-boost-devel mailing list
> pkg-boost-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boost-devel
>



-- 
Regards,

Dimitri.

Bug#809603: EMails erased on "mark as spam"

[Ricardo Mones]

Hi Harald,

On Wed, Jan 06, 2016 at 09:22:46PM +0100, Harald Dunkel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 01/02/16 16:43, Ricardo Mones wrote:
> > 
> > Which spam plugin are you using?
> > 
> 
> Bogofilter.

Messages are not deleted by bogofilter using default configuration, just
moved to trash folder.

Things which could to have happened to you:

• messages are in some trash folder but you didn't find them (yet)
  → verify your trash folders.

• you had a folder set but renamed it at some point, and messages are
  now in trash (https://bugs.debian.org/526048)
  → verify your trash folders.

• unintentionally configured the plugin to "Delete spam" instead of
  "Save spam in..."
  → verify Plugins/Bogofilter in preferences.

• you have default Bogofilter configuration but you have "Empty trash on
  exit" checked
  → verify Other/Miscellaneous also in preferences dialog.

Does any of the above help?

regards,
-- 
  Ricardo Mones 
  ~
  bash: ./signature: No such file or directory  /bin/bash



signature.asc
Description: Digital signature